Re: Shadow tree style isolation primitive

> On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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.

That sounds rather demeaning and insulting [1].  public-webapps, or a mailing list of any W3C working group, isn't an appropriate forum to rant.

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

While I agree those are problems worth solving, let us recognize and respect that different participates of the working group care about different use cases and are interested in solving different set of problems.

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

However, the use case we're talking here is multiple teams working on a single website potentially stepping on each other's toes; implying the enormous size of the entity working on the website.  I have a hard time imagining that any organization of that scale to not have a sever-side or pre-deployment build step for the website at which point they can add a preprocessing step to modify all selectors.  e.g. even a website I worked on with only four other people had a build step before we could deploy it.

[1] http://www.w3.org/Consortium/cepc/

- R. Niwa

Received on Wednesday, 4 February 2015 23:57:19 UTC