Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 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.

Most browser devs are not webdevs.  This is not an insult nor is it
demeaning.  I've been a member of the W3C for many years, and problems
with browser devs not understanding the issues of real webdevs "on the
ground" have always been rampant.  It's a large part of the reason I
joined the W3C in the first place, so I could help develop CSS specs
that were important for webdevs but being ignored by the browser devs
in the group.

If you find that demeaning, I'm sorry?  It's not something you can
ignore; it's always an elephant in the room when trying to solve
problems that frustrate webdevs.  It really is important to ensure
that browser devs sit down and listen to people with real webdev
experience (such as, for example, Brian Kardell).

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

That's precisely what I'm getting frustrated with - when people make
suggestions that composition isn't important, and people can "just use
better selectors and some discipline" to solve those problems, it
makes it difficult to have productive conversations.  Composition is a
massive problem with today's webapps.  Isolation is a minor problem
that is important for some valuable use-cases, so it shouldn't be
ignored, but neither should it be elevated to the sole important thing
to be discussed here.

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

No, that's not the use-case I'm talking about.  This is a problem with
one person developing one complex webapp.  It's also a problem with
multiple working on a single webapp, which is very common, but that's
not strictly necessary.

And no, putting a preprocessing step that appends N
:not(.foo-component) selectors to every compound selector in your
document is not a realistic approach.  That's a *massive* blowup in
selector size.  Real preprocessors that currently exist would reject
that approach out of hand, as their users would scream bloody murder.

This is not something that can be fixed by tooling and existing primitives.

~TJ

Received on Thursday, 5 February 2015 00:28:06 UTC