Sass/SCSS support

[holly-hacker]

With the Sass language you can write way cleaner code that is easier to manage than vanilla CSS. It was never present in Stylish, and I was surprised to see that none of the Stylish forks supported it either.

Implementing it should be pretty straight-forward. The user would write Sass or scss code in the CodeMirror editor, and on save it will compile the code and store both the Sass/scss code and the compiled css (so it won't have to be compiled on every injection, or on-the-fly, for performance reasons).

The sass.js library is licensed under the MIT license so there should be no licensing issues either.

[tophf]

If someone builds stylint.min.js properly (there should be no extra code like fs/buffer/whatever), we can add it to Stylus. I'm not familiar with browserify or npm in general so my patience ran out after 5 minutes of fiddling. The initial attempt produced a 120kB minified js, which is ok.

[Xeevis]

I don't see a reason why extension should have anything beside simple text editor for quick edits. You can easily develop in SASS or any other other language in editor of your choice (that supports it).

For example Visual Studio Code with extensions can set you up with SASS linter, formatter, highlighting, autocomplete, snippets and of course compiler that can generate css on save. Then you just open this CSS in browser with Stylus installed, hit install style if not already and tick "Live Reload". Then you can code in SASS in fully featured editor and see changes immediately applied on save.

You can then publish resulting CSS file as you normally would anywhere you want,

[eight04]

why extension should have anything beside simple text editor for quick edits.

We support these preprocessors in order to implement usercss styles. See the wiki for more information: https://github.com/openstyles/stylus/wiki/UserCSS

[dmrickey]

+1 for Sass support. It would make some of this way easier for complex pages with nested styles

[tophf]

The only theoretically possible solutions are:

1. compile SASS as a WebAssembly module, and if it's really small and fast, it can be included in Stylus.
2. write a separate utility that runs SASS in node.js and communicates with Stylus via nativeMessaging.
3. allow other extensions to extend Stylus via externally_connectable messaging.

All of these are doable, there's just no one interested enough to bother.

[traverseda]

It's a huge library (minified sass.js is 3.2MB), which is only beneficial to a small percentage of Stylus users, so we won't include it in the extension.

@tophf What? Why does an extra couple MB matter in this context? Allowing users to customize userscripts by editing a few variables at the top would be very useful.

[tophf]

@traverseda because 99.9% of users don't need it. As for variables, you can already do that, see our wiki, by using LESS or stylus-lang syntax.

[traverseda]

You don't really know if users "need" it or not. 99.9% of users don't need something like stylus, the reason it exists is because it can make it easier for power users to customize their experiences.

SCSS is ostensibly easier to write, and it lets you do things like define variables at the top of the file so end users and customize user styles they've downloaded. It's a powerful feature that makes it a lot easier for end users to customize their own experiences, which is ultimately the goal of stylus.

[narcolepticinsomniac]

so end users and customize user styles they've downloaded

Like this?

[traverseda]

Yep, that looks like the solutions.

For people seeing this issue going forward please note that stylus supports/prefers their own preprocessor and less over scss, but there is a preprocessor available.

[tophf]

99.9% is close enough, I don't need to really know the exact number, I'm just being reasonable based on the fact we already offer preprocessors with a convenient UI to configure the variables, as well as an ability to edit files with the external editor that supports SASS/SCSS so the rest 0.01% who really need it can write in that syntax and feed the output to our extension.

[traverseda]

I agree, it wasn't clear to me using the extension or reading through this thread that LESS/variables were properly supported. My apologies.

[apollolux]

I have a question. Why does the site for this extension say "[Feature] Sass/SCSS support" in the Features section and even links to this issue if there isn't actually built-in Sass/SCSS support (if I understand correctly after reading through this thread)?

[Mottie]

Hi @apollolux! I think you might have mis-read that. Please share a link if it does exist so we can correct it.

This extension only supports LESS & Stylus language. We don't have support for SASS because the stand-alone version is over 3 MB in size, which is almost 3x larger than this extension.

[apollolux]

The page at https://add0n.com/stylus.html in the "Features" section at the top has a "load requested features from GitHub" link which includes this (probably sources from the 'enhancement' label). "Requested features" inside a "Features" section is probably a slight bit misleading and would better serve in its own explicitly called out section or folded into the FAQs segued from a question like "I would like to see X in Stylus..." or something.

[traverseda]

Well let's fix that by getting this issue closed.

WontFix, the existing css variable/preprocessor system should be good enough.

[narcolepticinsomniac]

"Requested features" inside a "Features" section is probably a slight bit misleading

There's a dividing line, not to mention, if I see "requested features" being pulled from Github, I assume that means these issues are still open and therefore probably not implemented.

Well let's fix that by getting this issue closed... WontFix

I don't consider this is a WontFix. There's reasonable ways to accomplish this, so if anybody is willing to put in the effort, they're welcome to. Obviously, it hasn't been a high priority to anybody so far, but maybe it will be to someone who comes along.

[traverseda]

I don't consider this is a WontFix. There's reasonable ways to accomplish this, so if anybody is willing to put in the effort, they're welcome to.

That's really not how you came across. The "it's a huge library at 3.2MB" with no guidelines on what a reasonable size is really makes it seem like this just isn't going to happen.

If you'd be willing to accept third-party pull requests for this I think you really need to outline exactly what your requirements are. I'm surprised that "use nodejs and native messaging" is even a part of that list honestly. That really doesn't seem like a reasonable solution compared to just adding 3.2MB to the project.

[tophf]

We should probably just lock this thread (maybe also hide/delete most comments) since people don't want to read anything above the first/last few comments. As for a reasonable solution, see this comment, and there were probably more above that, I just don't remember.

[narcolepticinsomniac]

@tophf I guess the 64 thousand dollar question here is, what would be a reasonable size, if someone could manage to pull it off? Then we could lock it and hide irrelevant comments.

[tophf]

The size constraint is only present in one of the proposed solutions - using the built-in WASM module. Hopefully it can become much smaller than the JS library.

[narcolepticinsomniac]

The size constraint is only present in one of the proposed solutions - using the built-in WASM module.

Understood. Seems like the challenge most likely to be accepted though, for whatever reason.

Hopefully it can become much smaller than the JS library.

Yeah, but what'd be a rough estimate of what might fall into the possible/acceptable range. Gotta have a goal, at least.

[tophf]

Stylus extension itself: ~800kB Translated text/messages: ~1150kB

library	size, kB
CodeMirror	900
Stylelint	865
CSSLint	237
Stylus-lang	176
LESS	140

• The only essential library is CodeMirror.
• CSSLint is used to parse the compiled userCSS but we can do it via the built-in CSSStyleSheet parser (or a <style> element's sheet property in the older browsers) by substituting @-moz-document with a numbered @media and restoring later (example). Still, with CSSLint we can deliver meaningful hints and error messages so it's quite useful. It'd be nice if someone extends it to support other CSS syntax flavors (maybe via the plugins we already have for CodeMirror) so we can ditch Stylelint.
• Stylelint is outrageously huge compared to the others and I suspect it's because it still contains a lot of code that's never needed, or its developers just don't care since their target environment is node.js where there is no such concern.

So evidently the reasonable size is 150k - 250k.

[narcolepticinsomniac]

Asked for an estimate, and now there is one. Not sure how realistic it is, but it's a number. If anyone wants to implement any of the suggested solutions, they're welcome to submit a PR. I'll lock this issue and hide most of the irrelevant comments.