The authors complaints - essentially that HTML+CSS are messy and unhandy - resonate with me. Of course, it's not surprising these things are crufty - html is ancient, and clearly wasn't designed for today's world; and the same holds for CSS. But just because the author mentions something that's true doesn't mean his conclusions make sense. His solutions sound good, but they're really superficial and hide mistakes at least as bad as those html+css make today.<p>There are two fundamental ways to improve the dom layout model's cruft: By cleaning up weird legacy issues, and by fundamentally changing the way it works (i.e. introducing new layout models, or splitting styling from layout etc.)<p>I think it's important to realize that removing cruft is virtually impossible. The cleanliness we seek to simplify our lives in making new things simply isn't as valuable as support for old things. Legacy matters; it's unhandy, but it's also valuable.<p>So let's make the realistic assumption that the DOM of today isn't going away. You can't clean it up; you can only add things that work more easiliy, and perhaps discourage old, confusing behavior. That means thinking about and settling on what this new behavior should be.<p>The author's idea of splitting layout from styling simply won't work the way he expects it to. He suggests styling text nodes i.e. via `table text` and not have typography related styles on tables themselves. Sounds neat, but this won't work with today's CSS inheritance rules. If both `table text` and `bold text` were to match, css chooses the more specific (disambiguating by css order) rule. That's really not what you wanted to have happen though - just because bold was defined first in css doesn't mean it's less important. Here, we want specificy in order of DOM ancestry, not selector specificity. In essence, CSS already does the split he imagines - most typography related properties inherit, others generally do not.<p>I'm not convinced that the OP's article really has anything insight worth mentioning. Sure, there's lots of legacy, but clearly we can't just dump that. Other improvements are possibly, but he doesn't make a clear case for any specific, clearly better alternative.