[curveship]

Thank you! I thought I was the only one who felt this way. I truly do not understand why Google feels that application composition should happen at the presentation layer rather than the code layer, particularly when the presentation layer is as weakly typed as HTML. This was tried and failed in the very first round of server-side web frameworks back in the mid-late 90s. More recently, the complexity of Angular's transclusion logic should have clued them in that this is an unwieldy idea.

I agree that some kind of style scoping construct would be a good addition, and far simpler than ShadowDOM. Simple namespacing would be a good start. It would be a more elegant solution to the kludgy class prefixing that has become common (".my-component-foo", ".my-component-bar", etc.)

[cromwellian]

Well, for one thing, div-soups are hard to read, create deeply nested DOMs, and lack semantics or transparency. If you're trying to preserve the nature of the web, which is transparent, indexable data, one where "View Source" actually has some use to you, then having a big ball of JS instantiate everything is very opaque.

[curveship]

The phrase "div-soup" makes me reach for my revolver. It seems to be a straw man that means "Either you're for Web Components or you're for the worst of web engineering."

- How does ShadowDOM (or Web Components more generally) make your DOM shallower? It's still the same box model. Deeply nested DOM structures are usually the result of engineers who don't understand the box model and so over-decorate their DOMs with more markup than is semantically or functionally necessary. Nothing in ShadowDOM (or, again, Web Components) changes this.

- Are custom elements really more transparent than divs? If "View Source" shows <div><div><div>...</div></div></div>, do you really gain much if it shows <custom-element-you've-never-heard-of-with-unknown-semantics><another-custom-element><and-another>...</etc></etc></etc>? Proponents of Web Components seem to imagine that once you can define your own elements, you'll magically become a better engineer, giving your elements nice, clear semantics and cleanly orthogonal functionality. If people didn't do that with the existing HTML, why will custom elements change them? At least with divs, I can be reasonably sure that I'm looking at a block element. Custom elements, I got nuthin'. They're not transparent. They're a black box.

- Finally (and more importantly), we already solved the "div-soup" problem. It was called XHTML. Custom elements in encapsulated namespaces! Composable libraries of semantically-meaningful markup! How's that working out today? It's not.

TL;DR: a common presentation DTD is the strength of the web, not its weakness. Attempts to endow web applications with stronger composition/encapsulation should not be directed at the DOM layer but at the CSS and JS layers above and below it.

[cromwellian]

1. Shadow DOM scopes down what CSS selectors can match, so deep structures can hide elements from expensive CSS rules.

2. Custom Elements promote a declarative approach to development, as opposed to having JS render everything.

3. XHTML was not the same as Shadow DOM/Custom Elements. XHTML allowed produce custom DSL variants of XHTML, but you still ended up having to implement them in native code as trying to polyfill SVG for example would be horrendously inefficient.

4. The weakness of the web is the lack of composeability due to lack of encapsulation. Shit leaks, and leaks all over the page. Some third party JS widget can be completely fucked up by CSS in your page and vice versa.

A further weakness is precisely the move to presentation style markup. Modern web apps are using the document almost as if it were a PostScript environment, and frankly, that sucks. We are seeing an explosion of "single page apps" that store their data in private data silos, and fetch them via XHRs, rendering into a div-soup.

The strength of the web was publishing information in a form that a URL represented the knowledge. Now the URL merely represents a <script> tag that then fires off network requires to download data and display after the fact. Search engines have had to deal with this new world by making crawlers effectively execute URLs. I find this to be a sad state of effects, because whether you agree or not, the effect is to diminish the transparency of information.

You give me an HTML page, and I can discover lots of content in the static DOM itself, and I can trace links from that document to other sources of information. You give me a SinglePageApp div-soup app that fetches most of its content via XHR? I can't do jack with that until I execute it. The URL-as-resource has become URL-as-executable-code.

IMHO, the Web needs less Javascript, not more.

[godojo]

Both are needed! Javascript is great for portability of apps that would otherwise be done in a native environment (you wouldn't want to index these anyway). Isn't there a standard mime type to execute js directly in browsers? There should if not. If you care about being searchable and having designs that are readable on a variety of devices, powerful and degradable markup is very useful.

[malandrew]

Or search engines could use URLs with a custom browser that man-in-the-middles XHR and WebSockets to effectively crawl APIs, since the APIs theoretically are semantic by default.

execute url, index all XHR and websocket data, follow next link and repeat.

[ajanuary]

> If "View Source" shows <div><div><div>...</div></div></div>, do you really gain much if it shows <custom-element-you've-never-heard-of-with-unknown-semantics><another-custom-element><and-another>...</etc></etc></etc>?

You can extend the semantics of existing elements so you'd actually have <div is="custom-element-with-some-unknown-semantics-but-its-still-mostly-a-div">. Unextended tags are for when nothing in the existing HTML spec mirrors the base semantics you want.

Of course nothing stops people who did bad things before from doing bad things in the future, but it doesn't make tag soup worse.