- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 5 Feb 2015 10:20:46 +1100
- To: Olli Pettay <olli@pettay.fi>
- Cc: Brian Kardell <bkardell@gmail.com>, Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay <olli@pettay.fi> wrote: > Why do we need shadow DOM (or something similar) at all if we expose it > easily to the outside world. > One could even now just require that elements in "components" in a web page > have class="component", and then > .component could be used as >>>. Sure, it would require :not(.component) > usage too. > And from DOM APIs side one could easily implement filtering for the contents > of "components" using small script libraries. Aa;erlhas;dlgpasodifapsldikjf; I keep hearing this kind of sentiment pop up, and I'm like, have you ever done serious webdev? I know a lot of browser devs haven't, and I don't know if you have or not, but this is the sort of thing that is plain as day if you have. You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs obsolete. Shadow DOM is precisely that composition helper right now. In most contexts, you can't ever touch something inside of shadow DOM unless you're doing it on purpose, so there's no way to "friendly fire" (as Brian puts it). Stronger isolation does solve some problems, sure. But trying to imply that those are the only problems we need to solve, because they're the only problems related to "explaining the current DOM", shows a serious lack of insight into the types of problems experienced by webdevs today, when developing complex webapps. There is no naming scheme that accomplishes this. There is no amount of discipline that will help. Devs are humans, and webpages are very complicated multi-party computer programs, and helping people organize and manage that complexity is an enormous win. Existing Shadow DOM composition is a tailored solution to that. If it looks complex, it's because the platform is complex, and so there's a lot of interface to deal with. Its core, though, is just "what if this piece of the document was hidden from the rest of the document by default", and you can't cut away much of Shadow DOM without losing that entirely. ------------- Separate-but-related rant: And like, the sort of mindset that can just throw out "Sure, it would require :not(.component) usage too." like it was just some simple thing, easy to implement and do, is amazing. You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors, and need to do it for EVERY COMPONENT. Heck, to do it correctly, you have to do in on EVERY COMPOUND SELECTOR *within* each selector. It's optimizing in the exact wrong direction; you have to explicitly say every time that you don't want to match against a finite set of components; missing it once, or adding a new component that you haven't expressed in your giant-list-of-exclusions-on-every-selector-in-your-page, means you've got a potential styling bug. I, just, man. What. I'm unclear how to have a productive discussion when this is entertained as a serious suggestion. ~TJ
Received on Wednesday, 4 February 2015 23:21:35 UTC