Future proofing with CSS next?

[JayPanoz]

We’re already using PostCSS to ease the setup (concat files, stylelint, etc.) so I was wondering if implementers would be OK using CSS Next to “Use tomorrow’s CSS syntax, today.”

Benefits:

• Readium CSS would be “future-proof” i.e. at some point in the future, CSS next processing won’t be needed anymore (current features are sync’d with upcoming specs);
• Takes care of CSS variables → static representation;
• Would make Readium CSS a lot more readable (thinking about :not(), matches, custom media queries, media query ranges, etc.);
• fallbacks would be easier to manage;
• nesting and mixins (like pre-processors).

Caveats:

• major caveat is we’ll have a “dependency” (but dist, as opposed to src, could be used to get around this issue);
• implementers might not be used to the upcoming specs (and their syntax);
• same for contributors.

So, worst case scenario, that could become a barrier to entry. However, we’re likely to use it to make styles more readable. To sum things up, we could use it sporadically, to improve authoring a little bit, and skip the more complex features.

[JayPanoz]

For the sake of objectivity, here is a CSS-Tricks article discussing important issues related to that.

[JayPanoz]

Given CSS Next is just a set of postcss plugin, let’s close this issue. Implementers can indeed choose the tools they want to use so I prefer not to impose this one, given the few benefits it could bring compared to a custom config.