Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Layers of Confusion


Minor correction: HTML+CSS3 is indeed Turing Complete. Here is an implementation of Rule 110:
Wow, that's immensely clever. The sibling + universal selector trick for the wrap-around is amazing.

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

by alex at
The link in the last comment was stripped:

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

I think Ian himself does not understand that HTML is not "just HTML" anymore. CSS and HTML are extremely limited. Browser vendors cannot implement all features that millions (yes, this is not a typo) of developers demand.

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.

by c69 at
Hey Boris,

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.

by alex at
There's a fundamental assumption here that the declarative stuff must then proceed to be specified in an imperative manner. But that's simply not true. Large parts of CSS are instead specified in terms of a constraint model.

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.

by Boris at