Confusing title. I thought this is about, you know, Shadow DOM (<a href="http://www.w3.org/TR/shadow-dom/" rel="nofollow">http://www.w3.org/TR/shadow-dom/</a>).
At least for the layout issues, I believe with Grid Style Sheets[0] we have a solution. Use it for structure, CSS for "texture", React for UI and you have yourself a better web stack, today.<p>[0] <a href="http://gridstylesheets.org" rel="nofollow">http://gridstylesheets.org</a>
I'm a bit confused by the potshots taken at React. React is a library for building components. The fact those components render down to DOM nodes is incidental. In fact the documentation[1] hints at other possibilities, like rendering to canvas elements or native iOS views.<p>1: <a href="http://facebook.github.io/react/blog/2013/06/05/why-react.html" rel="nofollow">http://facebook.github.io/react/blog/2013/06/05/why-react.ht...</a>
There's some good points in here, but they are hidden amongst the rambling text. This could be a much stronger call to action if it weren't also a laundry list of the authors pet peeves.<p>Edit: the complaints about needlessly cascading styles and mixed styles defined by properties that are "only meaningful in some combinations" really resonate with me. I'd love to see him explore this in more depth.
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.
We need the possibility of strict separation of content and presentation and a powerful layout system. Something that removes all the clutter and mind juggling from the current process of developing websites and something that allows for robust wysiwyg editors (like Adobe InDesign).<p>All we want is putting text, shapes and pictures at certain dynamic positions on a screen. That is why I would propose a layout system that is based on positioning guides (straight or curved guide lines or shapes) rather than a box model. It would work like this: Given a set of initial guides which describe the screen shape one can define new guides which depend on the position of other guides. To define a vertical line at the center of the screen one would write: (defgd my-guide (between screen.left screen.right) (h-pos 50%)). Then one could place an object at a position along that line: (defobj my-object (anchor center) (guide my-guide) (pos (/ (- screen.bottom screen.top) 2)) (content "Hello" (class bold "World!")) (class headline1) (wrap-at screen.left screen.right) (padding 10px)). Instead of spelling out a content string one could, of course, refer to a variable which is stored in a separate resource. Furthermore, it would be helpful to have something like guide generators which can produce grids or arbitrary other shapes based on a given function (e.g. for tables and positions of other repetitive or self similar page elements).
And this is why web sucks at UI development and I enjoy doing native UI instead, every time I am allowed to.<p>It should never have gotten further than a document format.<p>Right now it sucks compared to where we could have been with proper UI layout markup and not the actual Frankenstein model of HTML/CSS/JavaScript, write once debug everywhere.
Some very convincing points about the flaws of CSS, but I'm still not sure what a better system would look like, and how realistic implementing that system would be.<p>Maybe the solution will come from new preprocessors (or existing ones like Sass) which will make it possible to write CSS in a completely different way without requiring browser vendors to adapt. Kind of like what CoffeeScript is to JavaScript.
I found the title a little unfortunate since "Shadow DOM" already means something specific in this space, namely <a href="http://www.w3.org/TR/shadow-dom/" rel="nofollow">http://www.w3.org/TR/shadow-dom/</a>
> And which is easier: defining a hairy new category of pseudo-elements like :first-letter and :first-line… or just telling people to wrap their first letter in a span if they really want to make it giant?<p>Maybe I misunderstand but I definitely prefer :first-letter than having to wrap it dynamically. I don't see why anyone would prefer the latter.
I don't really agree with this critique. HTML defines the structure and content, CSS defines the style and appearance, and JS defines the behavior. The model is clear and even somewhat elegant.<p>Yes there is overlap, that is inevitable. Yes, you can always make it ugly and there are old vestigial features that you probably shouldn't use. These standards have a long, complicated history, but the end result is surprisingly consistent.<p>The different layouts in CSS (inline, block...) are powerful tools once you get used to them. They solve the problem of reconciling different layout models that are useful in different situations. And that's one hell of a problem that won't go away, even in alternate utopias. In fact most of the complaints here are just about practical solutions to inevitable problems.
I do both native development for windows and web development, and believe me, I'll take HTML/CSS/JS any day. IMO, the box model is extremely conducive to pushing you in the right direction for a clean layout, and maybe CSS is unwieldy because you shouldn't be using that many styles; i.e. it was meant to make coming up with a unique style for each button on your site a burden. I did web development as a kid using tables back when that was the way good looking sites were made, and believe me, this model is better, not because of what it enables, but because of what it inhibits.
Entirely valid complaints.<p>The question is if CSS+HTML+JS can make the leap to convincing near-native-UI somehow (I'm also dubious, but it's possible; something built using canvas and webgl in a manner very much like what pixi.js is currently doing; with all the 'responsiveness' of a native application, and barely using html/css at all seems possible).<p>...or if people will just continue the current trend towards native applications to replace generic multi-platform websites.
This website is unreadable in Internet Explorer 11 - animated GIF as fullscreen page background.<p>Screenshot: <a href="http://s30.postimg.org/y8tm1yyc1/website_fail.png" rel="nofollow">http://s30.postimg.org/y8tm1yyc1/website_fail.png</a>