Ask anything to Sass Team

View other answers to this thread
Tommy Hodgins's photo

A lot of the newer features people are experimenting with in CSS are client-side only, and can't be compiled, predicted, or rendered in advance. Do you foresee the need (or popularity) of client-side re-processors in addition to preprocessors? What new features could client-side re-processed Sass include that aren't possible to support in its current form as a preprocessor today?

Hampton Catlin's photo

Fantastic question!

Hell yes this is going to be a thing (sort of). In fact, things like calc() and CSS variables and browser-based-units (em, etc) are already doing this kind of thing.

I don't think the right mental model is 're-processed' though. I think the right way to think of it is the Javascript execution environment will be deeply intwined and communicating with the current styles and styling rules. Right now, there is communication mostly moderated by the DOM. CSS => DOM <=> JS... I think the new model will include a full two-way conversation between CSS and JS, including manipulation and response.

For instance, wouldn't it be cool to implement a JS-based constraint system? Imagine if you could say body { display: constraint-based; } and it would trigger whole new CSS properties and layout behaviours!

Chris Eppstein's photo

CSS optimization is very hard to do outside of the context of a document -- but it's not clear how it would work client side as dynamic changes occur. Like a JIT, you'd need to know when you've violated your optimization assumptions and deoptimize.

In general, I see atomic css as being very fast for browsers to match against, but lacking the ergonomics I crave. I'd like to see tooling bridge this gap, but my sense is that it has to be done at build time with template awareness/rewriting and requiring hints for dynamic changes.