Popular posts

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!

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.