> That is, to Spolsky's credit, the point of HTML being completely layout free is supposed to be the compelling feature.
Except that it isn't. If you want to do anything entirely non-trivial, you have to annotate your HTML with classes and ids, and then hook into this using a complicated declarative language. But, at this point, there is no abstraction gain from
<div class="floating_figure">...</div>
over
floating_figure(...)
Functions are fine abstractions and nothing stops you from providing different implementations for different situations, and these implementations can again use abstractions to deal with a variety of output devices. Nothing here requires you to define layout specifics as part of the document [1].
Moreover, not all the world is just plain sequential text. There are mathematical formulas and syntax diagrams, for example. math.stackexchange.com falls back to Javascript (via MathJax) in order to display formulas; and Lout provides an excellent example of how one can specify the spatial relationships of syntax diagrams [2] while still abstracting over the implementation details (Lout is another functional layout/typesetting language).
[1] Of course, in practice, the world is never so clean, and you can rarely ignore layout constraints entirely; anyone who has ever written a paper containing a non-trivial mathematical formula knows that.
> But, at this point, there is no abstraction gain from
> <div class="floating_figure">...</div>
> over floating_figure(...)
There is no abstraction gain, because you are using a presentational class name.
It should not be "floating_figure", "big_red_text" or anything of the kind.
What it could probably be is "feynman_diagram" or something simmilar describing what's so special about this particular element, not the looks or placement of it.
And then it is up to your CSS to decide should it be floated, fixed, or hidden altogateher.
I said that was the point. Not that it succeeded at it. I fully acknowledge that it is broken all the time. However, if you want a loose control over the visual characteristics of a paragraph with some images, than the base html and css for floats gets the job done. Want columns? Yeah, you're screwed.
Seriously, most of the headaches from css come from trying to get it to do things that were not goals for the designers of the language. This is not a bad thing. But to believe that a turing complete language would have been a panacea is dangerous. And likely wrong.
Except that it isn't. If you want to do anything entirely non-trivial, you have to annotate your HTML with classes and ids, and then hook into this using a complicated declarative language. But, at this point, there is no abstraction gain from
over Functions are fine abstractions and nothing stops you from providing different implementations for different situations, and these implementations can again use abstractions to deal with a variety of output devices. Nothing here requires you to define layout specifics as part of the document [1].Moreover, not all the world is just plain sequential text. There are mathematical formulas and syntax diagrams, for example. math.stackexchange.com falls back to Javascript (via MathJax) in order to display formulas; and Lout provides an excellent example of how one can specify the spatial relationships of syntax diagrams [2] while still abstracting over the implementation details (Lout is another functional layout/typesetting language).
[1] Of course, in practice, the world is never so clean, and you can rarely ignore layout constraints entirely; anyone who has ever written a paper containing a non-trivial mathematical formula knows that.
[2] http://i.imgur.com/huD07xc.png