Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Thu, Nov 8, 2012 at 9:48 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Nov 6, 2012, at 3:29 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
>
>> On Thu, Nov 1, 2012 at 8:39 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>
>>>>>>> 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.
>>>>
>>>> What are the advantages to using an isolated component for the +1 button instead if an iframe, or a private component containing an iframe?
>>>
>>> I'm not 100% sure (Dimitri can answer better), but I think it's
>>> because we can do a somewhat more lightweight isolation than what a
>>> full iframe provides.
>>>
>>> IIRC, several of our use-cases *really* want all of the instances of a
>>> given component to use the same scripting context, because there's
>>> going to be a lot of them, and they all need the same simple data;
>>> they'd gain no benefit from being fully separate and paying the cost
>>> of a thousand unique scripting contexts.
>
> Is that the semantics "isolated" would have? All instances of the same component are in the same scripting context, but one separate from the page? I assumed that "new
> document and scripting context for this shadow subtree" would mean there's a new one per instance, and the document plus the scripting context is most of the cost of an iframe.
>
>>
>> Yup. The typical example that the Google+ people point out to me is
>> techcrunch.com. The count of iframes had gotten so high that it
>> affected performance to the point where the crunchmasters had to fake
>> the buttons (and reveal them on hover, which is tangential to the
>> story and may or may not have been the wisest choice).
>>
>> With isolated shadow trees, the number of scripting contexts would
>> equal then number of button-makers, and offer additional opportunities
>> like sharing styles among instances.
>
> OK, it wasn't clear that the separate document and scripting context for isolated components would be per unique component, rather than per-instance. That does seem like a meaningfully different behavior.
>
>
>
>>
>>>
>>>> One thing that makes me nervous about the"isolated" idea, is thata scripting context is normally bound one-to-one to either a browsing context or a worker; and having multiple scripting contexts per browsing context seems like it could be tricky to implement and may have security risks. But I don't have any more concrete objection at this time.
>>>
>>> I think that Workers or something very much like them is a productive
>>> direction to look in for the isolated components, actually.
>
> Wouldn't that require making the DOM and UI event dispatch threadsafe (which are likely not very practical things to do)?
>
>>>
>>>>> 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.
>>>>
>>>> Would the page be able to choose to make a component isolated without the cooperation of the component? Or alternately load components in such a way that only isolated ones would succeed?
>>>
>>> I think we'd like that, but haven't thought it through very hard yet.
>>
>> Isolation as a problem is something that's often considered in design
>> discussions (hence it being brought up here), but it's in a distant
>> future in relation to actual progress of the spec. If there were
>> Shadow DOM L2, that would a nice place to start.
>
> Maybe it should be set aside from this public vs private discussion for now then.

Sure thing. I realize now it was a distraction in this discussion.

>
> If it may be desirable to force isolated from the outside, then that makes it substantially different from the public vs private distinction, which should be completely under the control of the component. There's not much point to discussing isolated without having a handle on this aspect of its design.
>
> Regards,
> Maciej
>
>
>
>
>

Received on Thursday, 8 November 2012 17:54:52 UTC