Discussion: Should we migrate from Stylus, and to what?

[mattico]

I've seen this brought up a number of times, most recently in #610. #351 mentions it in passing. I want to start this discussion, and hopefully build a consensus so that I can work on the migration soon.

As far as I can tell, this is what we use stylus for:

• Variables like sidebar-width and content-max-width
• Variables and unquote for themes
• Convenience features like nested selectors and arithmetic without calc()
• Automatic vendor prefixing with Nib

Option 1: SASS

Unlike Stylus, there is a C library for SASS, and corresponding Rust bindings. This would be a good path to eliminate our node dependency. SASS has many of the same features as Stylus, so it should be a relatively easy transition.

Option 2: CSS with Variables

CSS has native support for variables now. Support for it is very good, with the notable exceptions of IE, old Android Browser, and Samsung Internet 4. While this surpasses the requirements listed in the Rust browser support RFC, I think its worthwhile to put a bit of effort into supporting IE11 at least, with a conditional comment solution.

This solution is missing some of the convenience features offered by the preprocessors. Personally, I don't find those features particularly useful. I find them a bit frustrating, in fact, if I have to look up what they mean.

The next thing to consider is vendor prefixes. Browsers are moving away from using these, but they can still matter for the time being. I scanned through the prefixed properties in book.css to determine how useful autoprefixing tools are for us. I found two cases where prefixes are necessary if we limit the scope to browsers that already support CSS variables:

1. Safari requires position: sticky to be prefixed. It's only used for #menu-bar.
2. Certain proprietary features like -webkit-scrollbar-thumb don't exist without their prefix (and don't benefit from autoprefixing tools)

Based on this, I don't think that autoprefixing tools are necessary if we adopt standard CSS.

---

While migrating to CSS would be more difficult, it's the better option in my opinion. It removes a build step and a dependency. It also removes the confusion for users and contributors who don't notice that book.css isn't the real source for styling. It also makes it easy for users to write themes in CSS while still taking advantage of our defined variables.

[Michael-F-Bryan]

@mattico I like the idea of removing our node dependency and the current regenerate-css feature hack for rebuilding CSS.

I don't have a lot of experience doing frontend programming, but from what I can tell SASS is a lot more popular than Stylus. That said, if all we're really using Stylus for is variables and vendor prefixes, it doesn't sound like we're gaining much over raw CSS. That means using SASS is also probably going to be overkill for our needs.

How difficult would it be to migrate from Stylus to CSS? We'd also probably want to write down how styling is typically done so people wanting to create their own styles (something that's been requested several times) can do so.

[mattico]

How difficult would it be to migrate from Stylus to CSS?

About this difficult: mattico@5d35a1f. Pretty much find-and-replace, copy-paste, semicolon.

The hard part is then getting all those files into the binary. We should be able to just remove all the @imports and concatenate them into a single file. But we have to do that before building for include_bytes to work, so it would have to happen in the build script. And now we're not that different from just using scss-rs in the build script...

Another option would be to merge some css files together so we have <5, which is more manageable. This would make it easy to edit the theme without needing any build step at all.

[mattico]

I tried out the second option, and I actually like it a lot. We don't actually have that much CSS - the biggest file is only 368 lines. If I hadn't screwed up some CSS somewhere while furiously copypasting this would be basically done.

[ehuss]

I think this is essentially done by #743.