On Thu, Nov 8, 2012 at 9:48 AM, Maciej Stachowiak <m...@apple.com> wrote: > > On Nov 6, 2012, at 3:29 PM, Dimitri Glazkov <dglaz...@google.com> wrote: > >> On Thu, Nov 1, 2012 at 8:39 AM, Tab Atkins Jr. <jackalm...@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 > > > > >
