On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa <rn...@apple.com> wrote:
> On Feb 14, 2014, at 5:17 PM, Alex Russell <slightly...@google.com> wrote: > > On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa <rn...@apple.com> wrote: > >> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn <espr...@chromium.org> wrote: >> >> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> >>> On 2/14/14 5:31 PM, Jonas Sicking wrote: >>> >>>> Also, I think that the Type 2 encapsulation has the same >>>> characteristics. If the component author does things perfectly and >>>> doesn't depend on any outside code >>>> >>> >>> And never invokes any DOM methods on the nodes in the component's >>> anonymous content. Which is a pretty strong restriction; I'm having a bit >>> of trouble thinking of a useful component with this property. >>> >>> >> I think my biggest issue with Type-2 is that unlike the languages cited >> for providing "private" it's trying to mimic it provides no backdoor for >> tools and frameworks to get at private state and at the same time it >> doesn't add any security benefits. >> >> >> Except that JavaScript doesn’t have “private”. >> > > Right, it only has the stronger form (closures) > > > I don’t think we have the stronger form in that using any builtin objects > and their functions would result in leaking information inside the closure. > > Ruby, Python, Java, C# and almost all other modern languages that >> provide a private facility for interfaces (as advocated by the Type-2 >> design) provide a backdoor through reflection to get at the variables and >> methods anyway. This allowed innovation like AOP, dependency injection, >> convention based frameworks and more. >> >> So if we provide Type-2 I'd argue we _must_ provide some kind of escape >> hatch to still get into the ShadowRoot from script. I'm fine providing some >> kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot >> property from the Element makes no sense. >> >> >> I don’t see how the above two sentences lead to a consolation that we >> must provide an escape hatch to get shadow root from script given that such >> an escape hatch already exists if the component authors end up using >> builtin DOM functions. >> > > It's the difference between using "legit" methods and "hacking around the > platform". If it's desirable to allow continued access in these situations, > why isn't .shadowRoot an acceptable speed bump? > > > The point is that it’s NOT ALWAYS desirable to allow continued access. We > saying that components should have a choice. > > If it's not desirable, isn't the ability to get around the restriction *at > all* a bug to be fixed (arguing, implicitly, that we should be > investigating stronger primitives that Maciej and I were discussing to > enable Type 4)? > > > Are you also arguing that we should “fix” closures so that you can safely > call builtin objects and their methods without leaking information? If > not, I don’t see why we need to fix this problem only for web components. > > We all agree it's not a security boundary and you can go through great >> lengths to get into the ShadowRoot if you really wanted, all we've done by >> not exposing it is make sure that users include some crazy >> jquery-make-shadows-visible.js library so they can build tools like Google >> Feedback or use a new framework or polyfill. >> >> >> I don’t think Google Feedback is a compelling use case since all >> components on Google properties could simply expose “shadow” property >> themselves. >> > > So you've written off the massive coordination costs of adding a uniform > to all code across all of Google and, on that basis, have suggested there > isn't really a problem? ISTM that it would be a multi-month (year?) project > to go patch every project in google3 and then wait for them to all deploy > new code. > > > On the other hand, Google representatives have previously argued that > adding template instantiation mechanism into browser isn’t helping anyone, > because framework authors would figure that out better than we can. > > I have a hard time understanding why anyone would come to conclusion that > forcing every single web components that use template to have: > > > this.createShadowRoot().appendChild(document.importNode(template.contents)); > I don't understand how this pertains to encapsulation. Could you elaborate? > > is any less desirable than having components that want to expose > shadowRoot to write: > > this.shadowRoot = createShadowRoot(); > The other hand of this argument is that components that wish to lock themselves down could write: this.shadowRoot = undefined; Of course, this does would not change the outcome of the Shadow Selector spec, which is why a flag for createShadowRoot or something would be necessary to configure the CSS engine (unless you're ok with having the existence of a property on some DOM object control CSS parsing rules). (Also your example would not handle multiple shadow roots correctly, here's one that would) var sr = this.shadowRoot; var newSr = this.createShadowRoot(); newSr.olderShadowRoot = sr; newSr.appendChild(document.importNode(template.content)) > > Since you have preciously claimed that instantiating a template element >> may not be a common pattern for custom elements / web components, I have a >> hard time accepting the claim that you’re certain accessing shadow root is >> a common coding pattern. >> > > Surely as the person asking for the more restricted form, the onus falls to > *you* to make the argument that the added restrictions show their value. > > > I don’t think it’s fair to say that we’re asking for the more restricted > form since Apple has never agreed to support the more open form (Type I > encapsulation) in the first place. > I don't understand this point, can you elaborate? It certainly seems like you are asking for a form of ShadowDOM encapsulation that is more restrictive than the already defined Type 1. > > - R. Niwa > >
