W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 01 Nov 2012 09:37:17 +0100
Cc: public-webapps <public-webapps@w3.org>
Message-id: <DE8C18D8-976C-419D-B921-6E6BDEB3280B@apple.com>
To: Dimitri Glazkov <dglazkov@google.com>

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>

> In other words, the information that could be accessible (no security concerns, for example) is not. One has to use
> hacks to get at the truth.



> 
> Here's a simple strawman (copied from bug for easy reading):
> 
> 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?

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


> 
> 3) the element.shadowRoot property points to the top of the tree
> stack, or null if the subtree at the top is in "private" or
> "isolated" setting.
> 
> 4) <shadow>.olderSubtree points to the older subtree in the stack or
> null if the older subtree is in "private" or "isolated" setting.
> 
> 5) ShadowRoot.host points to the shadow host or null, if the subtree
> is in "private" or "isolated" setting.
> 
> 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.

Cheers,
Maciej
Received on Thursday, 1 November 2012 08:37:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT