5 ms·

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 an

by emn13 13y ago

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. 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.) 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. 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. 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. 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.

3rd3 13y ago
> "I think it's important to realize that removing cruft is virtually impossible." With a browser from 1995 probably 95% of the popular websites are not usable. Truth is that backwards compatibility mostly reaches only a couple of revisions into the past as it’s the case with the web standards. And given how easy it is nowerdays to update a system, I wonder why it is not considered to make a clean cut and introduce a modern standard. The standards will simply co-exist for a couple of years until the new standard reaches a critical usage share.
- emn13 13y ago
  The issue isn't whether old browsers can display new content, it's whether new browsers can display old content (or even old content mixed into new content). If a new standard were to replace the old one, it would mean losing access to use swathes of the internet. Just look at how hard comparatively trivial upgrades of IPv6 or HTTP v2 are - and there you merely need to deal with ultimately replaceable machines - upgrading content formats just isn't easy. Sure, as a webdev it's nice to focus on the shiny new stuff, but I'm under no illusions that the old stuff is going away any time soon.
  - 3rd3 13y ago
    Couldn't one simply leave a DOM renderer or converter in web browsers?
    - emn13 13y ago
      Sure. That's basically the extend, not replace strategy. Then you can choose various ways to extend. * You could pick a completely different approach, and define interop points. This tends to have a steep learning curve. E.g. python interops with C very well, yet most people nevertheless avoid interop. * You could define the old system in terms of the new system or vice versa. That way, you eventually have clear path to use only one system completely. However, it also means you need to at least support all the various crufty bits you may not otherwise care about. It's also not easy to learn. * You could just extend the old system. You don't get to clean things up by hiding them behind interop or a layer of translation, but at least the learning curve isn't so bad - you only touch what you want. That last bit is the basically the strategy that wins. Adding a new system is just such a pain unless it entire replaces the old system (which is almost impossible in practice if only for reasons of momentum), that it's really hard to go half way. Also, don't forget that "mere" interop is far from trivial since it's not just CSS, but also javascript's interaction with DOM+CSS that you'd need to emulate/interop with. So that leaves us with things like flexbox: new techniques, but integrated into what we have rather than side-by-side with complex interop.

by emn13 13y ago

3rd3 13y ago

> "I think it's important to realize that removing cruft is virtually impossible." With a browser from 1995 probably 95% of the popular websites are not usable. Truth is that backwards compatibility mostly reaches only a couple of revisions into the past as it’s the case with the web standards. And given how easy it is nowerdays to update a system, I wonder why it is not considered to make a clean cut and introduce a modern standard. The standards will simply co-exist for a couple of years until the new standard reaches a critical usage share.

emn13 13y ago
The issue isn't whether old browsers can display new content, it's whether new browsers can display old content (or even old content mixed into new content). If a new standard were to replace the old one, it would mean losing access to use swathes of the internet. Just look at how hard comparatively trivial upgrades of IPv6 or HTTP v2 are - and there you merely need to deal with ultimately replaceable machines - upgrading content formats just isn't easy. Sure, as a webdev it's nice to focus on the shiny new stuff, but I'm under no illusions that the old stuff is going away any time soon.
- 3rd3 13y ago
  Couldn't one simply leave a DOM renderer or converter in web browsers?
  - emn13 13y ago
    Sure. That's basically the extend, not replace strategy. Then you can choose various ways to extend. * You could pick a completely different approach, and define interop points. This tends to have a steep learning curve. E.g. python interops with C very well, yet most people nevertheless avoid interop. * You could define the old system in terms of the new system or vice versa. That way, you eventually have clear path to use only one system completely. However, it also means you need to at least support all the various crufty bits you may not otherwise care about. It's also not easy to learn. * You could just extend the old system. You don't get to clean things up by hiding them behind interop or a layer of translation, but at least the learning curve isn't so bad - you only touch what you want. That last bit is the basically the strategy that wins. Adding a new system is just such a pain unless it entire replaces the old system (which is almost impossible in practice if only for reasons of momentum), that it's really hard to go half way. Also, don't forget that "mere" interop is far from trivial since it's not just CSS, but also javascript's interaction with DOM+CSS that you'd need to emulate/interop with. So that leaves us with things like flexbox: new techniques, but integrated into what we have rather than side-by-side with complex interop.