Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov <dglazkov@google.com> wrote:
>> Hi folks!
>>
>> While you are all having good TPAC fun, I thought I would bring this
>> bug to your attention:
>>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562
>>
>> There's been several comments from developers about the fact that
>> Shadow DOM encapsulation is _too_ well-sealed for various long tail,
>> but important use cases
>
> What are these use cases? I did not seem them in the bug.
>
> <http://w3cmemes.tumblr.com/post/34633601085/grumpy-old-maciej-has-a-question-about-your-spec>

For example, being able to re-render the page manually via DOM
inspection and custom <canvas> painting code.  Google Feedback does
this, for example.  If shadows are only exposed when the component
author thinks about it, and then only by convention, this means that
most components will be un-renderable by tools like this.

For the public/private part at least, this is just a switching of the
defaults.  There was no good *reason* to be private by default, we
just took the shortest path to *allowing* privacy and the default fell
out of that.  As a general rule, we should favor being public over
being private unless there's a good privacy or security reason to be
private.  So, I don't think we need strong use-cases here, since we're
not having to make a compat argument, and the new model adds minimal
complexity.


>> 1) There's a 3-position switch on each shadow DOM subtree: public,
>> private, isolated.
>
> Is there any special behavior associated with these three settings besides what is in the other numbered points?

I don't think so, no.  Public/private is just a matter of exposing or
nulling some references.  "Isolated" is obviously not well-defined in
this email, but the implications are relatively straightforward - it's
like a cross-domain iframe.  (Which is, in fact, exactly how existing
"components" hack in some isolation/security.)


>> 2) There's a mechanism in place to flip this switch (specifics TBD)
>
> Who gets to flip the switch? Can a "private" subtree still be accessed via the element it is attached to by simply marking it "public"? That would make "private" useless if so. It seems like whoever creates the shadow DOM should be able to make it "private" in an irreversible way. Without knowing the mechanism it's hard to judge if that is the case.
>
> In cases where a browser implementation provides a built-in shadow DOM, it seems particularly necessary to make it irreversibly private.

The idea so far is that the switch is just set at shadow creation
time, and can't be changed.


>> 6) The "isolated" setting essentially means that there's a new
>> document and scripting context for this shadow subtree (specifics
>> TBD). Watch https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509 for progress.
>
> That seems like a whole separate feature - perhaps we should figure out "private" vs "public" first. It would be good to know the use cases for this feature over using "private" or something like seamless iframes.

Yeah, sure.  It's useful to bring up at the same time, though, because
there are some decent use-cases that sound at first blush like they
should be "private", but really want even stronger security/isolation
constraints.

An existing example, iirc, is the Google +1 button widget.  Every
single +1 includes an <iframe> so it can do some secure scripting
without the page being able to reach in and fiddle with things.

Flipping it around, isolation also serves as a great way for the
*page* to protect itself from the *component*.  There are tons of
components that have absolutely no need to interact with the outside
page, so sealing them off loses you nothing and gains you peace of
mind when worrying about whether you should include some random
plugins you found on your favorite component library site.

~TJ

Received on Thursday, 1 November 2012 11:42:34 UTC