I’m intimately familiar with the ways that CSS is constraint based and not necessarily imperative, see:

http://infrequently.org/12/cassowary-js-refactor/demos/css/canvas-renderer.html

https://github.com/slightlyoff/cassowary-js-refactor

It’s not possible to use simple solvers for CSS without multi-step to accommodate line layout as you need to solve and constrain in multiple dimensions simultaneously, but I digress.

Back to the main issue: I’m not suggesting that we need to describe CSS as an imperative system — my (as yet unsuccessful) work with constraint solvers is expressly designed to give the WG a tool they can use to stop muddling around in the pseudo-imperative end of the pool and instead prototype features in the constraints directly.

I am instead suggesting that the areas in which we expose APIs, we need to act as though whatever implementation is “down there” has been written in JS. For declarative features with no API, this is a no-op, but we both know that situation doesn’t last forever. The implementation might, indeed, bottom out at a constraint solver! That’s great, and doesn’t change what I’m advocating for.

Now obviously you can do an imperative implementation of a constraint model, but doing that with a specification overconstrains (pun intended) your implementation strategies, because back-solving from an imperative description to a constraint model without introducing bugs is rocket science.

In fact, I’d go so far as to say that constraint-model descriptions are vastly superior to imperative ones when they’re possible: they lend themselves more to parallel algorithms, they allow a variety of implementation strategies, and they’re often much easier to understand.

Now of course for things like DOM tree manipulation, where there really is a lot of imperative stuff going on your suggestion makes sense. But even there, things like “update layout state” are really more described in terms of constraints, not explicit imperative algorithms.

Only Javascript can satisfy the hunger for new features for them. But Javascript cannot do much without APIs, and so: +1 to your article.

@michael, that’s a good illustration – programming in css is harder and clunkier, than programming in assembler. Today people want augmented reality, and browsers/specs give them rounded corners and hgroup tag.

WebRTC, WebComponents, JS DOM Bindings and better cache/storage mechanisms. This will open a new chapter in Web’s timeline.

Not sure it defeats the argument per say, but I’ll need to keep it in mind in future.

http://eli.fox-epste.in/rule110-full.html