W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Shadow tree style isolation primitive

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 5 Feb 2015 10:20:46 +1100
Message-ID: <CAAWBYDA-cqQeA8dPSc3O5+2rhkRCKJvr6wubTwuFerzPg07Mtw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC