Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/12/13 7:11 PM, Scott González wrote: It's been a while since I looked at this spec, what are the ways in which you can get access? You mean in the hidden case? For example, overriding Node.prototype.appendChild with your own function such that any time script in the component calls appendChild you end up getting a reference to the parent and the new child. Or overriding Array.prototype.* so that any time script in the component tries to use jquery stuff you can see all the things it's sticking into arrays. I can probably come up with a bunch of other examples if you want. In the non-hidden case, I believe .shadowRoot is how you get access. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 13, 2013 at 11:00 AM, Boris Zbarsky bzbar...@mit.edu wrote: In the non-hidden case, I believe .shadowRoot is how you get access. I meant in the non-hidden case. The name should make sense in terms of accessing this property. exposeRoot, hideRoot, publicRoot? Re-reading Dimitri's email, in his description he kept saying non-traversable, and then goes on to suggest names. Were there objections to traversable/non-traversable? It seems like that was the natural way to describe it during discussion. On a related note, most of the suggestions have a negative context (such that enabling takes something away), as opposed to a positive context (such that disabled takes something away). Is there a proposed API for this? I'm assuming this would be exposed via JS, not HTML, so it would be fine for the API to have a positive context and the developer would set the value to false to turn off the default behavior of exposing the root. I don't have a strong opinion either way, it just stuck out that everyone was using a negative context. If this would be exposed via an HTML attribute, then the negative context makes sense.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Quick update: we had a really productive lunch with a bunch of Mozilla and Google peeps (cc'd) After mulling this whole thing over, we're decided keep shadow trees traversable with a special provision for built-in HTML elements (UA shadow trees) to be non-traversable, per spec. We reached this conclusion after conducting a thought exercise of trying to gain entry into an imaginary private shadow tree, which exists in the same scripting context as the document, just using existing Web platform API -- as you may guess, it's not that difficult. However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. We couldn't come up with a good name for this mode. Private conveys false expectations of being any sort of security primitive. Hidden is unclear in purpose. Get-Off-My-Lawn is perfect, but a touch too wordy. We will also pursue, as a second phase of Shadow DOM spec, a way to create shadow trees that exist in a separate scripting context and a separate document, but render as part of the main document. These will provide the necessary security guarantees and finally bring the candy trees and unicorns to the Web platform. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Tue, Mar 12, 2013 at 2:19 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Quick update: we had a really productive lunch with a bunch of Mozilla and Google peeps (cc'd) After mulling this whole thing over, we're decided keep shadow trees traversable with a special provision for built-in HTML elements (UA shadow trees) to be non-traversable, per spec. We reached this conclusion after conducting a thought exercise of trying to gain entry into an imaginary private shadow tree, which exists in the same scripting context as the document, just using existing Web platform API -- as you may guess, it's not that difficult. However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. We couldn't come up with a good name for this mode. Private conveys false expectations of being any sort of security primitive. Hidden is unclear in purpose. Get-Off-My-Lawn is perfect, but a touch too wordy. We will also pursue, as a second phase of Shadow DOM spec, a way to create shadow trees that exist in a separate scripting context and a separate document, but render as part of the main document. These will provide the necessary security guarantees and finally bring the candy trees and unicorns to the Web platform. This is exactly what I had hoped for, so yay! Everything sounds good to me. I don't have any good naming suggestions, but think hidden isn't too bad. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. To be clear, what this mode does is turn off the simple way of getting the shadow tree. It does not promise that someone can't get at the shadow tree via various non-obvious methods, because in practice such promises are empty as long as script inside the component runs against the web page global. The question is how to name this. Hidden seems to promise too much to me. Perhaps obfuscated? Veiled? -Boris P.S. Tempting as it is, RedWithGreenPolkadots is probably not an OK name for this bikeshed.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. To be clear, what this mode does is turn off the simple way of getting the shadow tree. It does not promise that someone can't get at the shadow tree via various non-obvious methods, because in practice such promises are empty as long as script inside the component runs against the web page global. The question is how to name this. Hidden seems to promise too much to me. Perhaps obfuscated? Veiled? -Boris P.S. Tempting as it is, RedWithGreenPolkadots is probably not an OK name for this bikeshed. Apologies in advance for adding to the bikeshedding protected (mostly private, but you can get around it) shielded (the shield can be lowered) gated (the gate can be opened) fenced (most fences have an opening) Or bleenish-grue, if we're going with color names. Alan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
What about obscured, opaque, invisible, or restricted? On Tue, Mar 12, 2013 at 3:34 PM, Alan Stearns stea...@adobe.com wrote: On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. To be clear, what this mode does is turn off the simple way of getting the shadow tree. It does not promise that someone can't get at the shadow tree via various non-obvious methods, because in practice such promises are empty as long as script inside the component runs against the web page global. The question is how to name this. Hidden seems to promise too much to me. Perhaps obfuscated? Veiled? -Boris P.S. Tempting as it is, RedWithGreenPolkadots is probably not an OK name for this bikeshed. Apologies in advance for adding to the bikeshedding protected (mostly private, but you can get around it) shielded (the shield can be lowered) gated (the gate can be opened) fenced (most fences have an opening) Or bleenish-grue, if we're going with color names. Alan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
It's been a while since I looked at this spec, what are the ways in which you can get access? It seems like a name such as traversable could work well. On Tue, Mar 12, 2013 at 6:47 PM, Daniel Buchner dan...@mozilla.com wrote: What about obscured, opaque, invisible, or restricted? On Tue, Mar 12, 2013 at 3:34 PM, Alan Stearns stea...@adobe.com wrote: On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. To be clear, what this mode does is turn off the simple way of getting the shadow tree. It does not promise that someone can't get at the shadow tree via various non-obvious methods, because in practice such promises are empty as long as script inside the component runs against the web page global. The question is how to name this. Hidden seems to promise too much to me. Perhaps obfuscated? Veiled? -Boris P.S. Tempting as it is, RedWithGreenPolkadots is probably not an OK name for this bikeshed. Apologies in advance for adding to the bikeshedding protected (mostly private, but you can get around it) shielded (the shield can be lowered) gated (the gate can be opened) fenced (most fences have an opening) Or bleenish-grue, if we're going with color names. Alan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
I agree with Scott; notraverse, something along those lines. Glad to hear about the wide consensus on the overall effort. On Mar 12, 2013, at 4:11 PM, Scott González scott.gonza...@gmail.com wrote: It's been a while since I looked at this spec, what are the ways in which you can get access? It seems like a name such as traversable could work well. On Tue, Mar 12, 2013 at 6:47 PM, Daniel Buchner dan...@mozilla.com wrote: What about obscured, opaque, invisible, or restricted? On Tue, Mar 12, 2013 at 3:34 PM, Alan Stearns stea...@adobe.com wrote: On 3/12/13 2:41 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a KEEP OUT sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's shadow tree stack. To be clear, what this mode does is turn off the simple way of getting the shadow tree. It does not promise that someone can't get at the shadow tree via various non-obvious methods, because in practice such promises are empty as long as script inside the component runs against the web page global. The question is how to name this. Hidden seems to promise too much to me. Perhaps obfuscated? Veiled? -Boris P.S. Tempting as it is, RedWithGreenPolkadots is probably not an OK name for this bikeshed. Apologies in advance for adding to the bikeshedding protected (mostly private, but you can get around it) shielded (the shield can be lowered) gated (the gate can be opened) fenced (most fences have an opening) Or bleenish-grue, if we're going with color names. Alan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Mar 7, 2013 at 2:02 PM, Boris Zbarsky bzbar...@mit.edu But you want to continue linking to the version hosted on the Disqus server instead of hosting it yourself and modifying as desired, presumably? Because if you're hosting yourself you can certainly just make a slight modification to opt into not hiding the implementation if you want, right? Yeah, I actually do want to use their copy. It's similar to monkey-patching and I'd argue less fragile than making my own copy that is destined to always be stale. I use a Chrome plugin for GMail called GMelius that does something similar, it just tweaks parts of the Gmail UI.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Fri, Mar 8, 2013 at 12:03 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 7.3.2013 19:54, Scott González wrote: Who is killing anything? Hi, given http://lists.w3.org/Archives/**Public/public-webapps/** 2013JanMar/0676.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0676.html I've misunderstood your point as advocating against Shadow altogether. Ok, good to know that this was mostly just a miscommunication. 2nd is is practical: not having to care about the internals, so I do not break it by accident from outside. If the only way to work with internals is by explicit request for internals and then working with them, but without the ability to breach the barrier accidentally, without the explicit request directly on the shadow host, this concern is satisfied and yes, there will be no clashes except for control naming. My understanding is that you have to explicitly ask to walk into the shadow, so this wouldn't happen accidentally. Can someone please confirm or deny this?
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Fwiw, I'm still following this thread, but so far Scott G. has been saying everything I would say (good on ya, brother :P). My understanding is that you have to explicitly ask to walk into the shadow, so this wouldn't happen accidentally. Can someone please confirm or deny this? Confirmed. The encapsulation barriers are there to prevent you from stumbling into shadow. On Fri, Mar 8, 2013 at 12:14 PM, Scott González scott.gonza...@gmail.comwrote: On Fri, Mar 8, 2013 at 12:03 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 7.3.2013 19:54, Scott González wrote: Who is killing anything? Hi, given http://lists.w3.org/Archives/**Public/public-webapps/** 2013JanMar/0676.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0676.html I've misunderstood your point as advocating against Shadow altogether. Ok, good to know that this was mostly just a miscommunication. 2nd is is practical: not having to care about the internals, so I do not break it by accident from outside. If the only way to work with internals is by explicit request for internals and then working with them, but without the ability to breach the barrier accidentally, without the explicit request directly on the shadow host, this concern is satisfied and yes, there will be no clashes except for control naming. My understanding is that you have to explicitly ask to walk into the shadow, so this wouldn't happen accidentally. Can someone please confirm or deny this?
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say exposing internals here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) Not exposing internals by default, with a way to opt into exposing. I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals. And what do you feel the pros are of whichever one you're talking about compared to the items after it on the list, just so we're on the same page? In terms of web components, I'm not sure I (or anyone else on the jQuery team) have too strong of an opinion on the default. However, I can say that I find it extremely annoying that I can't reach into the Shadow DOM for new input types and just kill everything. I want input type=date to render as input type=text because native HTML will likely never be as flexible as custom JS components. Obviously I'd prefer a standard, and web components are supposed to solve this. But in the meantime, we're provided with useful semantics and validation that go unused if you want the flexibility of a JS date picker. As someone building JS components, I see the benefit of having the internals exposed to me so I can do as I please. I also recognize the pain of maintaining code that reaches into internals. As someone who cares about the future of the web, I see the very real danger of this becoming widespread and ending up in the situation Boris wants us to avoid.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/7/13 11:51 AM, Scott González wrote: I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals. Yes, but you explicitly said there are pros to exposing the internals. I'd like to understand what those pros are in your context, and whether they're explicitly tied the fact that externals are always exposed (which you're forced into right now) or whether the pros are just to do with the _ability_ to expose internals as desired. That is, what are the specific pros? In terms of web components, I'm not sure I (or anyone else on the jQuery team) have too strong of an opinion on the default. However, I can say that I find it extremely annoying that I can't reach into the Shadow DOM for new input types and just kill everything. Chances are that behavior would remain for the foreseeable future even if page-provided components expose their internals, from what I understand... So that's a somewhat orthogonal discussion, sadly. :( -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Mar 7, 2013 at 8:55 AM, Boris Zbarsky bzbar...@mit.edu wrote: Chances are that behavior would remain for the foreseeable future even if page-provided components expose their internals, from what I understand... So that's a somewhat orthogonal discussion, sadly. :( I agree, it's very unlikely the UA shadow trees will ever be public. However, Shadow DOM (the spec) does allow you to completely override the UA shadow tree by just creating a new shadow tree on top of it. Current implementation in WebKit is not yet quite there, but I hope it will be soon. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 7.3.2013 19:08, Scott González wrote: This just seems like a big rant. may seem a bit harsh, but I'm trying to compress my point of view, it's not like we can have hours long discussion about pros and cons. i mean no harm :) Your questions about things like should scripts use closures are just derailing the conversation. I'm honestly not sure it's worth replying to any of your points. But to clarify some points I think are relevant: You are right, because someone is trying to kill important (from my point of view) technology: being able to actually create reusable UI libraries. You may think we have those, we do not... Againg from my experience from other languages... I have approx. 200 controls installed in my Delphy from approx. 12 vendors. I can use them in any combination... seamlessly, without caring how are those written (unless pig wrote them). You cannot do that on Web, don't get me wrong I admire jQuery, it's like the alphabet of JS programming. But regardless of how clever people work on it, it's not self contained, it leaks where? in DOM/CSS and it collides. It's not possible to expose potions of a DOM. So, if you want any customization at the DOM level, it's all or nothing. You can't expect to expose a JS API on top of a web component that is small and nice to work with and provide the flexibility of having control over the DOM. You can document that your web component provides some hierarchical structure and uses classes in a specific way. Then users can make modifications, for example, injecting additional markup, without breaking the structure or semantics of the existing web component. I'm not advocating for total anarchy. But that is exactly my point. I do not want to expose the whole DOM and then make programmer read tons of docs. about internals because they leak. I cannot imagine to have app using 50 different controls/component from 4 vendors and having to figure out how to make them not clash If it's safe to modify DOM, I make it public. If it's not, than it is not, then do not touch it. As for the input type="date" example: This isn't arbitrary 3rd party scripts coming and crippling your DOM in unexpected ways. This is you as the developer of the site saying the native experience is too limiting and then opting in to a different UI. This is also not global, change the world behavior, this is on a per-element basis. well... if the 3rd party control is not fitting to your scenario, don't use it, or rewrite it (if you have the permission). My JS example may seem like distraction to you, but it's actually the same point here yet again. If you find JS class that is almost there, you have 3 choices: rewrite it, throw it away and find another or write your own. Yes, you are the developer of the site, so you can choose what you want/can use. It's not mandatory for you to use input[type="date"] containing shadow. Pick another, write your own. If it's wrong technology for you, do not use it. But why killing it altogether for anyone? Because someone else wrote something you cannot modify? B. On Thu, Mar 7, 2013 at 12:55 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 7.3.2013 17:51, Scott González wrote: On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say "exposing internals" here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) Not exposing internals by default, with a way to opt into exposing. I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Mar 7, 2013 at 1:37 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Your questions about things like should scripts use closures are just derailing the conversation. I'm honestly not sure it's worth replying to any of your points. But to clarify some points I think are relevant: You are right, because someone is trying to kill important (from my point of view) technology: being able to actually create reusable UI libraries. We're talking about a default value, not what functionality is or isn't available. I don't see who is trying to kill your important technologies. But regardless of how clever people work on it, it's not self contained, it leaks where? in DOM/CSS and it collides. This is the nature of the web. There does not exist technology that prevents this. We're discussing that technology right now. But specifically, we're only discussing the default behavior: Do we default to how the web has always worked or do we break tradition? It's not possible to expose potions of a DOM. So, if you want any customization at the DOM level, it's all or nothing. You can't expect to expose a JS API on top of a web component that is small and nice to work with and provide the flexibility of having control over the DOM. You can document that your web component provides some hierarchical structure and uses classes in a specific way. Then users can make modifications, for example, injecting additional markup, without breaking the structure or semantics of the existing web component. I'm not advocating for total anarchy. But that is exactly my point. I do not want to expose the whole DOM and then make programmer read tons of docs. about internals because they leak. So don't. Opt-in to having your DOM be private. I cannot imagine to have app using 50 different controls/component from 4 vendors and having to figure out how to make them not clash Why are they clashing? Web components are self-contained. The only collisions that would exist are either 2 vendors creating the same custom name or a script that isn't even a web component reaching into a web component. The former is impossible to avoid, the latter is what we're discussing (usefulness of being able to dive into a shadow root. If it's safe to modify DOM, I make it public. If it's not, than it is not, then do not touch it. Again, this is all or nothing. If you want it private, you can do that. Nobody is saying this shouldn't be an option. As for the input type=date example: This isn't arbitrary 3rd party scripts coming and crippling your DOM in unexpected ways. This is you as the developer of the site saying the native experience is too limiting and then opting in to a different UI. This is also not global, change the world behavior, this is on a per-element basis. well... if the 3rd party control is not fitting to your scenario, don't use it, or rewrite it (if you have the permission). Again, you're completely missing the point. I WANT the 3rd party control, but I also want the semantics of input type=date. Today it's one or the other. In the future, web components will allow you to have both (as explained by Dimitri). My JS example may seem like distraction to you, but it's actually the same point here yet again. If you find JS class that is almost there, you have 3 choices: rewrite it, throw it away and find another or write your own. Those options suck. Seriously. By the way, option 1 and option 3 are the same. Yes, you are the developer of the site, so you can choose what you want/can use. It's not mandatory for you to use input[type=date] containing shadow. Pick another, write your own. Again, the web platform is providing functionality which I cannot use then. We need to empower developers to leverage the technology built into browsers. I should probably take the time to dig through the archives and find threads about why making everything a black box sucks for web developers. If it's wrong technology for you, do not use it. But why killing it altogether for anyone? Because someone else wrote something you cannot modify? Who is killing anything?
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
scott.gonza...@gmail.com wrote: As for the input type=date example: This isn't arbitrary 3rd party scripts coming and crippling your DOM in unexpected ways. This is you as the developer of the site saying the native experience is too limiting and then opting in to a different UI. This is also not global, change the world behavior, this is on a per-element basis. Something like this is an example of where judicious breaking of the seals can make a big difference. It would be a shame if all sorts of useful components were trapped in opaque boxes with no way for the enclosing pages to enhance or examine them. That seems counter to what the web has been about since its inception, awesome stuff that forms the kernel of all sorts of innovative mashups. Another example, let's say Disqus created a webcomponent to show discussions related to content. I want to use that on my page but enhance it with a bozo/spam filter, fully understanding that it will require knowledge of Disqus webcomponent internals. Yes it may break. But my alternative is to make a feature request to Disqus, hope they approve, and wait for an implementation if it's even *possible*. For example, I may be using information only I have to do the filtering, and I don't want to share it with Disqus. So sure, put up a big warning that says CAUTION: The edges of this sign are sharp! but don't prevent people from getting to the internals of webcomponents at all. That puts the web at the mercy of the implementer almost as surely as closed source does.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Mar 7, 2013 at 9:55 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: ... I do not mean to sound cocky here, but I'd really like to know how many people here are used to languages that can separate internals and externals, because if you are simply not used to it, you simply cannot see the benefits and all goes to I'm used to play with internals of controls, I think you'll find everyone in this discussion has used a wide variety of systems from XUL to Cocoa to Swing to MFC and many more. I think it's important to note that all these native platforms support walking the hierarchy as well. Cocoa has [NSView subviews], Windows has FindWindowEx/EnumChildWindows, Swing has getComponents(), ... I'm struggling to think of a widely used UI platform that _doesn't_ give you access. Sure, there's encapsulation, Shadow DOM that has too, but they all still give you an accessor to get down into the components. ... From my JS/HTML control experience? * I want all my tables to look certain way - boom jQury datepicker brokes down, tinyMCE brokes down * I want all my tables to have and option for exporting data - boom jQury datepicker brokes down, tinyMCE brokes down * I switch from content-box to border-box - pretty much every 3rd party control breaks down * I want to autogenerate table of contents (page menu links) from headings in the article, f*ck, some stupid plugin gets involved that's like the last week experience ... Private shadows are not necessary to address any if the issues you cite. Indeed all of these issues are already fixed with the current design by way of scoped styles, resetting style inheritance, and shadows being separate trees you don't accidentally fall into. I think this is really the compelling argument. We solved the major issues already, and none of the other very successful platforms (ex. Cocoa, Android, etc.) needs to be so heavy handed as to prevent you from walking the tree if you choose. - E
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/7/13 1:54 PM, Scott González wrote: We're talking about a default value, not what functionality is or isn't available. We're talking about both, in general. Until this conversation started at least one implementor was planning to ship exposed-by-default with no way to not expose, as far as I can tell. I _think_, but am not sure, that this is no longer in the plans. At least I hope so. There's been no definitive statement. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/7/13 1:54 PM, Dave Methvin wrote: Another example, let's say Disqus created a webcomponent to show discussions related to content. I want to use that on my page but enhance it with a bozo/spam filter, fully understanding that it will require knowledge of Disqus webcomponent internals. But you want to continue linking to the version hosted on the Disqus server instead of hosting it yourself and modifying as desired, presumably? Because if you're hosting yourself you can certainly just make a slight modification to opt into not hiding the implementation if you want, right? -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Mar 7, 2013 at 11:00 AM, Boris Zbarsky bzbar...@mit.edu wrote: We're talking about both, in general. Until this conversation started at least one implementor was planning to ship exposed-by-default with no way to not expose, as far as I can tell. I _think_, but am not sure, that this is no longer in the plans. At least I hope so. There's been no definitive statement. Chrome is indeed shipping a prefixed implementation of exposed-by-default shadow trees as of M25: http://jsfiddle.net/h5S9V/ Please don't let this stop the discussion. Prefixed implementations are meant to be experiments, unless they stick around for too long. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 7.3.2013 19:54, Scott González wrote: Who is killing anything? Hi, given http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0676.html I've misunderstood your point as advocating against Shadow altogether. My concerns are twosome: 1st one is ideological: you do not touch internals, it's not good practice, but I appreciate the fact, that good practice is not a dogma and from time to time is good thing to break it. 2nd is is practical: not having to care about the internals, so I do not break it by accident from outside. If the only way to work with internals is by explicit request for internals and then working with them, but without the ability to breach the barrier accidentally, without the explicit request directly on the shadow host, this concern is satisfied and yes, there will be no clashes except for control naming. Brona
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan mrb...@gmail.com wrote: On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com wrote: Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. This doesn't have to be the case. Shadows can be private by default with a well defined and consistent API to override the default. So, here's a quick strawman: 1) add an optional parameter to createShadowRoot to indicate whether the shadow tree will be public or private (default TBD) 2) when a shadow tree is private, the corresponding HTMLElement.shadowRoot and HTMLShadowElement.olderShadowRoot return either a) the next older public tree root or b) null if older tree doesn't exist, effectively skipping from the private shadow tree over to the next older public tree. WDYT? If this is okay with everyone, we can focus on debating the default parameter value. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
So the two camps in the this argument seem to be arguing largely philosophical views. It's clear that Mozilla has experienced pain via plugins having access to browser internals. I'm curious if jQuery or others have experienced feeling restricted because apps are depending on internals by way of having access to them via monkey-patching It seems to me like if public-by-default was a design mistake on the web, it'd be pretty clearly in evidence already. Is it? On Tue, Feb 26, 2013 at 1:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/26/13 3:56 PM, Dominic Cooney wrote: One more thought occurs to me: It is easier to add public shadows in a subsequent revision of the spec than it is to take public shadows away. Yes, indeed. That's one of the main reasons I'd like it to be the initial default... I would certainly be completely against shipping anything that does not provide private shadows at all, of course. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 1:12 PM, Rafael Weinstein rafa...@google.com wrote: I'm curious if jQuery or others have experienced feeling restricted because apps are depending on internals by way of having access to them via monkey-patching This is unfortunately a very real pain for jQuery. On the flip side, exposing the internals is hugely beneficial. Boris' concerns are legitimate, but we feel the pros of exposing internals outweigh the cons.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say exposing internals here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) Not exposing internals by default, with a way to opt into exposing. ? And what do you feel the pros are of whichever one you're talking about compared to the items after it on the list, just so we're on the same page? -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 6.3.2013 18:50, Dimitri Glazkov wrote: On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan mrb...@gmail.com mailto:mrb...@gmail.com wrote: On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com mailto:a...@google.com wrote: Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. This doesn't have to be the case. Shadows can be private by default with a well defined and consistent API to override the default. So, here's a quick strawman: 1) add an optional parameter to createShadowRoot to indicate whether the shadow tree will be public or private (default TBD) 2) when a shadow tree is private, the corresponding HTMLElement.shadowRoot and HTMLShadowElement.olderShadowRoot return either a) the next older public tree root or b) null if older tree doesn't exist, effectively skipping from the private shadow tree over to the next older public tree. WDYT? If this is okay with everyone, we can focus on debating the default parameter value. :DG Frankly from my perspective, which would be default (public or private) is no issue at all, just pick one, could not care less. Discussion on this mater (as long as we agree on the point that the value is Boolean :) ) seems like a waste of time to me. Thou I would go for private as default if default option is chosen. The best solution would be to not go with default at all, make it nice explicit parameter (mandatory), but that may conflict with existing usage (?). For my controls I'll go with global option for all controls: full private for release, probably public for development (for testing, how the control behave, it may be useful to have access to its internals). B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 6.3.2013 21:00, Boris Zbarsky wrote: On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say exposing internals here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) Not exposing internals by default, with a way to opt into exposing. ? And what do you feel the pros are of whichever one you're talking about compared to the items after it on the list, just so we're on the same page? -Boris What does the exposing internals means anyway? Does it mean that there are no boundaries at all and e.g. document.querySelector can access internal? Or does it mean that you can access internals only by explicitly asking for existing shadowRoot of element and than work with it? B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 10:12 AM, Rafael Weinstein rafa...@google.com wrote: It seems to me like if public-by-default was a design mistake on the web, it'd be pretty clearly in evidence already. Is it? This might depend who you ask. I know from experience that public-by-default has bitten XBL1-implemented HTML elements really badly (leading to tons of security bugs until we (Mozilla) figured out how to lock them down). We've invested many hours of time avoiding a different problem with our audio and video controls (also implemented in XBL1) where we explicitly had to avoid exposing the guts of the implementation of the control to prevent page authors from using the non-standard internal API instead of the public one. Outside of those cases, I've personally been bitten in other languages and contexts where private state was exposed publicly on an API which made what should have been a simple bug fix take days or weeks to track down all of the (ab)users of the easier API. This is a classic problem in computer science and there's a reason that it's taught in many CS 101 courses. I don't have any specific anecdotes on the web, but they simply must exist. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 2:26 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: What does the exposing internals means anyway? Does it mean that there are no boundaries at all and e.g. document.querySelector can access internal? Or does it mean that you can access internals only by explicitly asking for existing shadowRoot of element and than work with it? I've always taken exposing internals to mean providing an API to access the shadow DOM of a component. I don't think that anybody is arguing that shadow elements should appear in queries on the bound document. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Tue, Feb 26, 2013 at 2:51 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Mon, Feb 25, 2013 at 9:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/25/13 12:33 PM, Tab Atkins Jr. wrote: If a script is explicitly looking inside the shadows of unknown controls and checking their contents (and then failing when the unknown control has different contents than whatever it expected), something is *messed up* with that script. I can 100% guarantee to you that such scripts will get written, will be popular, and will prevent control authors from changing their implementations while preserving the API... FWIW, I was most ambivalent about this change. I welcome more discussion. I know Elliott and Dominic had the strongest opinions on this. I think that shadows should be private. My main concern has been well represented by Boris; basically, if shadows are not private by default, it is too easy for pages to come to depend on the internal details of components, which reduces the value of Web Components. My thinking on this issue has evolved slightly. These points might be useful to consider; I did not see them covered elsewhere in this thread yet: There are a set of use cases, for example Readability, AdBlock, accessibility tools and debugging tools, that should have access to shadows. These use cases are mostly handled by browser extensions (or integration into the browser in the case of debugging tools or Readability in Safari.) As such, I don’t think these use cases are persuasive arguments for making shadows public; extensions can have a special means of access. I think it is preferable to chose to make shadows public, or to make them private, to having a mode that components can opt into. Although the default provided by the spec is important, early adopters are also important in shaping practice. There is apparently strong conviction on both sides of the argument. If shadows are public by default, there is no serious obstacle to making them private on an ad-hoc basis; if shadows are private by default, there is no serious obstacle to making them public on an ad-hoc basis. Maybe the spec should include non-normative commentary to make web component authors aware of this choice, and then the market/Darwinian process/etc. will decide. If shadows are public by default, it would be nice for web component authors who want private shadows to get them in a way that is reasonably efficient and is not disruptive in the presence of multiple shadows. It would be nice if there was at least one high-quality JavaScript library that came into wide use for this. If shadows are private by default, it would be nice for web component authors who want public shadows to get them in a way that is consistent and interoperable especially in the presence of multiple shadows. It would be nice if there was at least one high-quality JavaScript library that came into wide use for this. Dominic
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney domin...@chromium.org wrote: Although the default provided by the spec is important, early adopters are also important in shaping practice. There is apparently strong conviction on both sides of the argument. If shadows are public by default, there is no serious obstacle to making them private on an ad-hoc basis; if shadows are private by default, there is no serious obstacle to making them public on an ad-hoc basis. Maybe the spec should include non-normative commentary to make web component authors aware of this choice, and then the market/Darwinian process/etc. will decide. An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public on an ad-hoc basis, there's no way for tools to reliably access the public shadows. This was a problem earlier in the spec, when it was in exactly that state - you got handed your shadow root explicitly, and could, if you wanted, assign it to a public property on your own. That meant, though, that you could assign it to *any* property, so tools couldn't predict where to look. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/26/13 1:57 PM, Tab Atkins Jr. wrote: An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public on an ad-hoc basis I think ad-hoc in this case means per-component, not ad-hoc method of exposing. The method of exposing should be standardized no matter what; I think we agree on that. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. On Feb 26, 2013 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney domin...@chromium.org wrote: Although the default provided by the spec is important, early adopters are also important in shaping practice. There is apparently strong conviction on both sides of the argument. If shadows are public by default, there is no serious obstacle to making them private on an ad-hoc basis; if shadows are private by default, there is no serious obstacle to making them public on an ad-hoc basis. Maybe the spec should include non-normative commentary to make web component authors aware of this choice, and then the market/Darwinian process/etc. will decide. An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public on an ad-hoc basis, there's no way for tools to reliably access the public shadows. This was a problem earlier in the spec, when it was in exactly that state - you got handed your shadow root explicitly, and could, if you wanted, assign it to a public property on your own. That meant, though, that you could assign it to *any* property, so tools couldn't predict where to look. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Feb 27, 2013 at 4:05 AM, Erik Arvidsson a...@google.com wrote: Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. See below. On Feb 26, 2013 1:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Feb 26, 2013 at 10:44 AM, Dominic Cooney domin...@chromium.org wrote: Although the default provided by the spec is important, early adopters are also important in shaping practice. There is apparently strong conviction on both sides of the argument. If shadows are public by default, there is no serious obstacle to making them private on an ad-hoc basis; if shadows are private by default, there is no serious obstacle to making them public on an ad-hoc basis. Maybe the spec should include non-normative commentary to make web component authors aware of this choice, and then the market/Darwinian process/etc. will decide. An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public on an ad-hoc basis, there's no way for tools to reliably access the public shadows. Yes, that is what I intended to insinuate in this sentence: “If shadows are private by default, it would be nice for web component authors who want public shadows to get them in a way that is consistent and interoperable especially in the presence of multiple shadows.” This was a problem earlier in the spec, when it was in exactly that state - you got handed your shadow root explicitly, and could, if you wanted, assign it to a public property on your own. That meant, though, that you could assign it to *any* property, so tools couldn't predict where to look.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Feb 27, 2013 at 4:03 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/26/13 1:57 PM, Tab Atkins Jr. wrote: An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public on an ad-hoc basis I think ad-hoc in this case means per-component, not ad-hoc method of exposing. The method of exposing should be standardized no matter what; I think we agree on that. -Boris Yes, by “ad-hoc” I meant “per-component.” If shadows are private by default, maybe it makes sense for the spec to have commentary about how shadows should be exposed by scripts that want to expose them. Alternatively, if shadows are public by default, maybe the spec should have commentary about not breaking multiple shadows if scripts want to hide them. (I think there are performance downsides to having public shadow DOM and hiding it with script, but it probably does not make sense for spec commentary to venture there.) One more thought occurs to me: It is easier to add public shadows in a subsequent revision of the spec than it is to take public shadows away. Provided the message that Shadow DOM does not provide meaningful security guarantees is understood, we could consider private Shadow DOM a conservative initial design.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/26/13 3:56 PM, Dominic Cooney wrote: One more thought occurs to me: It is easier to add public shadows in a subsequent revision of the spec than it is to take public shadows away. Yes, indeed. That's one of the main reasons I'd like it to be the initial default... I would certainly be completely against shipping anything that does not provide private shadows at all, of course. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com wrote: Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. This doesn't have to be the case. Shadows can be private by default with a well defined and consistent API to override the default. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/25/13 12:11 AM, Tab Atkins Jr. wrote: We've gone back and forth. It seems that allowing monkeypatching by default is the better choice, as most uses aren't security conscious Tab, could you please read and respond to what Blake actually wrote? He didn't mention the word security at all. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 22.2.2013 3:33, Blake Kaplan wrote: Hello everybody, I'm coming into this conversation late, but wanted to add my thoughts. As has been pointed out in this thread, the web has traditionally been very open and malleable. JavaScript has very few readonly properties, doesn't generally throw exceptions instead guessing or returning bogus values. Making shadow trees hidden clearly goes against this idiom and, by definition, limits what pages will be able to do with external libraries built using shadow DOMs. Even given this downside, though, I think that it's a mistake to make shadow trees accessible to the bound document by default. One of the most important features for frameworks is the ability to provide an encapsulated API. Without that, it becomes extremely difficult to fix bugs or add features to the framework without risking breaking downstream clients. Shadow DOMs are one of a host of features being designed and implemented that make HTML + CSS + JavaScript usable for programming in the wild and it feels like an oversight to make the default imitate the bad ol' days of monkey patching and low to no encapsulation. Finally, reading through the thread, it seems like one of the main use-cases for open-by-default is features like Google Feedback. From my point of view, it seems like features like that need to be considered from the beginning of a site's design. So if a site wants to have something like GF and also use web components and shadow DOMs, then the designers of the components should have to explicitly set the bit that says let other people poke at my internals. I don't think that this one use-case needs to trump the good programming practices of every other library. -- Blake Kaplan I'd like to second that, shadow DOM is explicitly designed not to be accessible from outside, to stay consistent, to be sure that nothing gets broken by altering the internals of Shadow DOM control/widget. I'd like to be able to create controls in the future and give those controls to users to place them anywhere. I do not want to hear our site is broken, because something else on our page was checking if there's a DIV there and you changed it to SECTION, you suck!, internals of the controls should stay internals of the control. You are effectively crippling half of the advantage of Shadow DOM: the ability do whatever I want to do inside the control as long as I expose the same API between versions. So if this is going to be breached, there should be a way for control authors to decide, whether they want to opt for this traversing or not... BTW looking at mail From: Elliott Sprehn espr...@gmail.com Date: Thu, 8 Nov 2012 01:45:16 -0800 Traversable shadows are a requirement for a number of things like: - Generic page level libraries and polyfills that need to transform DOM nodes - Generic event handling libraries (ex. Pointer events) - Creating screenshots of the page by rendering every node to a canvas (ex. Google Feedback) - Creating awesome bookmarklets like Readability Maybe I'm coming too late to this discussion, but how did everyone missed those first 2 points? Is this actually a suggestion that someone/something should be able not only read my DOM but alter it as well? So what is the point of Shadow DOM then? B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Mon, Feb 25, 2013 at 7:53 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: I'd like to second that, shadow DOM is explicitly designed not to be accessible from outside, to stay consistent, to be sure that nothing gets broken by altering the internals of Shadow DOM control/widget. I'd like to be able to create controls in the future and give those controls to users to place them anywhere. I do not want to hear our site is broken, because something else on our page was checking if there's a DIV there and you changed it to SECTION, you suck!, internals of the controls should stay internals of the control. You are effectively crippling half of the advantage of Shadow DOM: the ability do whatever I want to do inside the control as long as I expose the same API between versions. If a script is explicitly looking inside the shadows of unknown controls and checking their contents (and then failing when the unknown control has different contents than whatever it expected), something is *messed up* with that script. You don't just accidentally see the insides of shadows. All the traditional movement and search APIs skip them. I don't think this is a realistic fear (not to say it won't happen somewhere, sometime - the web is big, and people tile the possibility space, including all the bad ideas). So if this is going to be breached, there should be a way for control authors to decide, whether they want to opt for this traversing or not... There is. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Mon, Feb 25, 2013 at 6:21 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/25/13 12:11 AM, Tab Atkins Jr. wrote: We've gone back and forth. It seems that allowing monkeypatching by default is the better choice, as most uses aren't security conscious Tab, could you please read and respond to what Blake actually wrote? He didn't mention the word security at all. True, but that's often something that comes up. Sorry for implying that was the only concern Blake had. Still, though, the private by default impulse is nearly always wrong, and contrary to a lot of patterns on the web. As I alluded to, and Elliot explicitly said in the 2012 email that Bronislav quotes, the current status quo, where shadow DOM is hidden from everything unless you're explicitly looking for it, is necessary for *lots* of useful and completely benign things. Because of this, hiding the shadow is *not* something that's obviously good, and I argue that it should rarely be necessary in the first place. If you want high integrity (not security - this is a much broader concept), it's expensive. This is always true, because low-integrity things are *useful*, and people often try to reach for high-integrity without thinking through its downsides. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 25.2.2013 18:33, Tab Atkins Jr. wrote: On Mon, Feb 25, 2013 at 7:53 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: I'd like to second that, shadow DOM is explicitly designed not to be accessible from outside, to stay consistent, to be sure that nothing gets broken by altering the internals of Shadow DOM control/widget. I'd like to be able to create controls in the future and give those controls to users to place them anywhere. I do not want to hear "our site is broken, because something else on our page was checking if there's a DIV there and you changed it to SECTION, you suck!", internals of the controls should stay internals of the control. You are effectively crippling half of the advantage of Shadow DOM: the ability do whatever I want to do inside the control as long as I expose the same API between versions. If a script is explicitly looking inside the shadows of unknown controls and checking their contents (and then failing when the unknown control has different contents than whatever it expected), something is *messed up* with that script. You don't just accidentally see the insides of shadows. All the traditional movement and search APIs skip them. I don't think this is a realistic fear (not to say it won't happen somewhere, sometime - the web is big, and people tile the possibility space, including all the bad ideas). No, I did not mean bug in browser, I ment making shadow traversable so shadow internals can be reached from outside... and someone can be counting on it. So if this is going to be breached, there should be a way for control authors to decide, whether they want to opt for this traversing or not... There is. ~TJ -- s pozdravem Bronislav Klučka http://www.bauglir.com bronislav.klu...@bauglir.com * webové aplikace * software na zakázku
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/25/13 12:33 PM, Tab Atkins Jr. wrote: If a script is explicitly looking inside the shadows of unknown controls and checking their contents (and then failing when the unknown control has different contents than whatever it expected), something is *messed up* with that script. I can 100% guarantee to you that such scripts will get written, will be popular, and will prevent control authors from changing their implementations while preserving the API... -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/25/13 12:38 PM, Tab Atkins Jr. wrote: Still, though, the private by default impulse is nearly always wrong That's an interesting claim. Do you think that C++ classes should be public by default? (Binary patching that can mess even with private members notwithstanding for now) and contrary to a lot of patterns on the web This is at least partly a historical artifact of two things: 1) The web was not originally designed for serious application development. 2) There is no way to do private by default right now, really. There are some things you can try to do with closures and whatnot, but the shared global makes even those not exactly private. the current status quo, where shadow DOM is hidden from everything unless you're explicitly looking for it, is necessary for *lots* of useful and completely benign things. I think we may have different definitions of benign... If you want high integrity (not security - this is a much broader concept), it's expensive. This is always true, because low-integrity things are *useful*, and people often try to reach for high-integrity without thinking through its downsides. I can assure you that I have thought through the downsides of high-integrity and low-integrity components, both. Furthermore, we at Mozilla have a lot of implementation experience with the low-integrity version. It's been a constant battle against people monkeypatching things in ways that totally fail if you change the implementation at all, and I'm not sure why we should impose such a battle on component developers by default. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
I agree with Tab 100% on this. You cannot accidentally stumble into ShadowDOM. You have to actively take that step. For one thing, I suggest that most of the time, the component code is shipping w/your application, you are not depending on some resource that will simply be upgraded out from under you. For another thing, if I decide it's necessary to monkey-patch some third-party code that's I'm using in my application, I'm generally pretty upset if that code is privatized. It makes that unpleasant work much harder. I need to ship ASAP, and maintenance concerns are secondary. Either way the last thing I'm going to do is wily-nily update that code and then blame the developer that my monkey-patch broke. Yes, someone could complain in that scenario, but they have no leg to stand on. Boris says the above has been a big problem at Mozilla. This confuses me. Do developer's not know that monkey-patching clearly private code is bad for their maintenance? I don't see how this can be the library vendor's problem (unless maybe it's an auto-update situation). I suppose there is a moral hazard argument: if we make it possible, people will overdo it. This is probably true, but IMO it's akin to saying chefs should only use butter knives because they could cut themselves on the sharp kind. Lastly, only a subset of possible upgrades actually are transparent, not affecting public API or behavior. Intersect that set of updates with monkey-patchers who can't live without the update, and you are talking about a relatively small affected class. Scott On Mon, Feb 25, 2013 at 9:54 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/25/13 12:38 PM, Tab Atkins Jr. wrote: Still, though, the private by default impulse is nearly always wrong That's an interesting claim. Do you think that C++ classes should be public by default? (Binary patching that can mess even with private members notwithstanding for now) and contrary to a lot of patterns on the web This is at least partly a historical artifact of two things: 1) The web was not originally designed for serious application development. 2) There is no way to do private by default right now, really. There are some things you can try to do with closures and whatnot, but the shared global makes even those not exactly private. the current status quo, where shadow DOM is hidden from everything unless you're explicitly looking for it, is necessary for *lots* of useful and completely benign things. I think we may have different definitions of benign... If you want high integrity (not security - this is a much broader concept), it's expensive. This is always true, because low-integrity things are *useful*, and people often try to reach for high-integrity without thinking through its downsides. I can assure you that I have thought through the downsides of high-integrity and low-integrity components, both. Furthermore, we at Mozilla have a lot of implementation experience with the low-integrity version. It's been a constant battle against people monkeypatching things in ways that totally fail if you change the implementation at all, and I'm not sure why we should impose such a battle on component developers by default. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 25.2.2013 18:38, Tab Atkins Jr. wrote: On Mon, Feb 25, 2013 at 6:21 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/25/13 12:11 AM, Tab Atkins Jr. wrote: We've gone back and forth. It seems that allowing monkeypatching by default is the better choice, as most uses aren't security conscious Tab, could you please read and respond to what Blake actually wrote? He didn't mention the word security at all. True, but that's often something that comes up. Sorry for implying that was the only concern Blake had. Still, though, the private by default impulse is nearly always wrong, and contrary to a lot of patterns on the web. As I alluded to, and Elliot explicitly said in the 2012 email that Bronislav quotes, the current status quo, where shadow DOM is hidden from everything unless you're explicitly looking for it, is necessary for *lots* of useful and completely benign things. Because of this, hiding the shadow is *not* something that's obviously good, and I argue that it should rarely be necessary in the first place. If you want high integrity (not security - this is a much broader concept), it's expensive. This is always true, because low-integrity things are *useful*, and people often try to reach for high-integrity without thinking through its downsides. ~TJ My opinion of course... but you wrong on so many levels... I'm originally desktop applications programmer (still doing some), and private by default is the best policy (actually it's protected, but there's no such concept in HTML and no such thing in JS yet), it is contrary to lot of patters on web (given JS and DOM sharing space over all document regardless of origin), but this is serious flaw of the design, not a pro, it's con. Sure I can say please not change the internals of that DOM it may change in the future, do not count on existence of some node in that DOM, it may change in the future but again, what is the point of Shadow than? Yes, high integrity is expensive, so what? That is not an argument at all. It's a choice... do I need it? I'll use Shadow DOM, is it pointless for the result? I will not use it... We are not making anything mandatory. Shadow DOM is the way hi to create actual blackbox control/component/widget as it's normal and beneficiary in other languages. This is always true, because low-integrity things are *useful*, and people often try to reach for high-integrity without thinking through its downsides. Generalization excusing poor decisions of programmers? How about those, who can make good one? But to argue your original point: keeping the smallest amount of point application can connect to control/component/widget blackbox is the best way how to ensure continuous, long time, functionality without breaking everything else. Because you are keeping the boundaries sharp. When you have e.g. Delhi control, you know the contract between the original author and you. Having HTML+JS+CSS mess you know nothing at all. I do recognize the history of the web, and I'm fine with making access policy to Shadow DOM more granular as long as I'm able to actually say I do not want you to see anything other that I choose to expose in any way. B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/25/13 1:15 PM, Scott Miles wrote: You cannot accidentally stumble into ShadowDOM. You have to actively take that step. Sure. We all know this. I'm not sure why this strawman keeps getting argued. For one thing, I suggest that most of the time, the component code is shipping w/your application, you are not depending on some resource that will simply be upgraded out from under you. your application? The problem is when things that are poking at the internals of the components aren't part of your application. I suggest you have a look at things like Optimizely for examples of the sort of invasive monkey-patching going on right now. For another thing, if I decide it's necessary to monkey-patch some third-party code that's I'm using in my application, I'm generally pretty upset if that code is privatized. It makes that unpleasant work much harder. I need to ship ASAP, and maintenance concerns are secondary. Sure. Is this situation more common than browser extensions or ad scripts that monkeypatch things? Either way the last thing I'm going to do is wily-nily update that code and then blame the developer that my monkey-patch broke. Yes, someone could complain in that scenario, but they have no leg to stand on. I'm sorry, but this is hilarious. People complain in this scenario all the time, and whether they have a leg to stand on is simply a function of their market penetration. Boris says the above has been a big problem at Mozilla. With extensions monkey-patching XBL bindings, for example, yes. This confuses me. Do developer's not know that monkey-patching clearly private code is bad for their maintenance? No, they don't. See your comments about need to ship ASAP above. Most people don't even bother to think about the maintainence problems their introduce; they just figure if anything changes they'll shout loudly for it to unchange. For example, a common monkeypatching technique I've seen is grabbing a function exported by the component, calling toString on it, doing some regexp search/replace on that string and then doing new Function() with the result and sticking it back on the component. And people get outraged if this breaks because the toString of the function changed in any way. I don't see how this can be the library vendor's problem It becomes the library vendor's problem as soon as the set of things that depend on the monkeypatching has enough market share. I suppose there is a moral hazard argument: if we make it possible, people will overdo it. Indeed. This is probably true, but IMO it's akin to saying chefs should only use butter knives because they could cut themselves on the sharp kind. No, more like saying that the kind of knife the chef is using shouldn't be forced depend on where they got their tomatoes from, so when the chef develops RSI they can use a more ergonomic knife to cut the tomatoes. Lastly, only a subset of possible upgrades actually are transparent, not affecting public API or behavior. Intersect that set of updates with monkey-patchers who can't live without the update, and you are talking about a relatively small affected class. Do you have actual numbers to back this up? In my experience the affected class is actually pretty large, because monkey-patching behavior is very common and changing the source of functions, say, without changing their public API is not that rare either. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 25.2.2013 19:15, Scott Miles wrote: I agree with Tab 100% on this. You cannot accidentally stumble into ShadowDOM. You have to actively take that step. Sure, someone can actively take step to access my shadow DOM, thou I explicitly made it shadow and in next version of the control things will break. For one thing, I suggest that most of the time, the component code is shipping w/your application, you are not depending on some resource that will simply be upgraded out from under you. Sure, but as a desktop programmer I cannot tell how many times over the last decade I have upgraded my applications including 3rd party controls... And all I have to do is to check the points whee my app touches the controls... Not caring about the rest, because the rest cannot be broken (well, can, under extreme circumstances) For another thing, if I decide it's necessary to monkey-patch some third-party code that's I'm using in my application, I'm generally pretty upset if that code is privatized. It makes that unpleasant work much harder. I need to ship ASAP, and maintenance concerns are secondary. Assuming of course you can legally do that... privacy of 3rd party control has nothing to do with monkey-patchif you have the code... sure you cannot do that from outside of the control, but that makes no difference (the problem with private clause is inheritance, protected is better choice) I suppose there is a moral hazard argument: if we make it possible, people will overdo it. This is probably true, but IMO it's akin to saying chefs should only use butter knives because they could cut themselves on the sharp kind. Again, do we have to go with one choice here? Either or? Can we go with options when creating Shadow dom? Lastly, only a subset of possible upgrades actually are transparent, not affecting public API or behavior. Intersect that set of updates with monkey-patchers who can't live without the update, and you are talking about a relatively small affected class. Well.. yours upgrades maybe... Scott B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Don't we have a situation where people can simply take your source and change it regardless (barring legal imperatives, which are orthogonal in my view)? Given Boris' arguments, Big Marketshare can simply always mess up his project and blame me and it's my fault. I don't accept it. Btw, If Big Marketshare is so powerful, why haven't we already fixed whatever thing he is monkey patching? Also, Optimizely, et al, doesn't simply appear at random. Again, seems like your argument is that some developer or user may take wanton stet X to break my stuff, and I must prevent it or it's my fault. re: forced depend on where they got their tomatoes from and You cannot accidentally stumble into ShadowDOM The reason the latter keeps being mentioned is because of statements like the former. Nobody is forcing anybody to break encapsulation. Seems to me the demarcation is very clear. And all I have to do is to check the points whee my app touches the controls Yes, transparent upgrades are great. No argument here. But If you had monkey-patched your libraries, you wouldn't have this ability. You didn't, so life is good. Can we go with options when creating Shadow dom? My understanding is that we have this option and are only talking about what would be the default. Lastly, my point about upgrade statistics is only that the intersection of the two sets is generally going to be smaller than the union of them. I should not have qualified that difference. To be clear, the intersection I posed included monkey-patchers that require the update, not simply monkey-patchers. On Mon, Feb 25, 2013 at 10:37 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 25.2.2013 19:15, Scott Miles wrote: I agree with Tab 100% on this. You cannot accidentally stumble into ShadowDOM. You have to actively take that step. Sure, someone can actively take step to access my shadow DOM, thou I explicitly made it shadow and in next version of the control things will break. For one thing, I suggest that most of the time, the component code is shipping w/your application, you are not depending on some resource that will simply be upgraded out from under you. Sure, but as a desktop programmer I cannot tell how many times over the last decade I have upgraded my applications including 3rd party controls... And all I have to do is to check the points whee my app touches the controls... Not caring about the rest, because the rest cannot be broken (well, can, under extreme circumstances) For another thing, if I decide it's necessary to monkey-patch some third-party code that's I'm using in my application, I'm generally pretty upset if that code is privatized. It makes that unpleasant work much harder. I need to ship ASAP, and maintenance concerns are secondary. Assuming of course you can legally do that... privacy of 3rd party control has nothing to do with monkey-patchif you have the code... sure you cannot do that from outside of the control, but that makes no difference (the problem with private clause is inheritance, protected is better choice) I suppose there is a moral hazard argument: if we make it possible, people will overdo it. This is probably true, but IMO it's akin to saying chefs should only use butter knives because they could cut themselves on the sharp kind. Again, do we have to go with one choice here? Either or? Can we go with options when creating Shadow dom? Lastly, only a subset of possible upgrades actually are transparent, not affecting public API or behavior. Intersect that set of updates with monkey-patchers who can't live without the update, and you are talking about a relatively small affected class. Well.. yours upgrades maybe... Scott B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Can we go with options when creating Shadow dom? My understanding is that we have this option and are only talking about what would be the default. Bronislav correctly pointed out to me that this is a fact not in evidence. We have discussed 'isolate' option, but it's not in any spec that we can find (yet). On Mon, Feb 25, 2013 at 10:52 AM, Scott Miles sjmi...@google.com wrote: Don't we have a situation where people can simply take your source and change it regardless (barring legal imperatives, which are orthogonal in my view)? Given Boris' arguments, Big Marketshare can simply always mess up his project and blame me and it's my fault. I don't accept it. Btw, If Big Marketshare is so powerful, why haven't we already fixed whatever thing he is monkey patching? Also, Optimizely, et al, doesn't simply appear at random. Again, seems like your argument is that some developer or user may take wanton stet X to break my stuff, and I must prevent it or it's my fault. re: forced depend on where they got their tomatoes from and You cannot accidentally stumble into ShadowDOM The reason the latter keeps being mentioned is because of statements like the former. Nobody is forcing anybody to break encapsulation. Seems to me the demarcation is very clear. And all I have to do is to check the points whee my app touches the controls Yes, transparent upgrades are great. No argument here. But If you had monkey-patched your libraries, you wouldn't have this ability. You didn't, so life is good. Can we go with options when creating Shadow dom? My understanding is that we have this option and are only talking about what would be the default. Lastly, my point about upgrade statistics is only that the intersection of the two sets is generally going to be smaller than the union of them. I should not have qualified that difference. To be clear, the intersection I posed included monkey-patchers that require the update, not simply monkey-patchers. On Mon, Feb 25, 2013 at 10:37 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 25.2.2013 19:15, Scott Miles wrote: I agree with Tab 100% on this. You cannot accidentally stumble into ShadowDOM. You have to actively take that step. Sure, someone can actively take step to access my shadow DOM, thou I explicitly made it shadow and in next version of the control things will break. For one thing, I suggest that most of the time, the component code is shipping w/your application, you are not depending on some resource that will simply be upgraded out from under you. Sure, but as a desktop programmer I cannot tell how many times over the last decade I have upgraded my applications including 3rd party controls... And all I have to do is to check the points whee my app touches the controls... Not caring about the rest, because the rest cannot be broken (well, can, under extreme circumstances) For another thing, if I decide it's necessary to monkey-patch some third-party code that's I'm using in my application, I'm generally pretty upset if that code is privatized. It makes that unpleasant work much harder. I need to ship ASAP, and maintenance concerns are secondary. Assuming of course you can legally do that... privacy of 3rd party control has nothing to do with monkey-patchif you have the code... sure you cannot do that from outside of the control, but that makes no difference (the problem with private clause is inheritance, protected is better choice) I suppose there is a moral hazard argument: if we make it possible, people will overdo it. This is probably true, but IMO it's akin to saying chefs should only use butter knives because they could cut themselves on the sharp kind. Again, do we have to go with one choice here? Either or? Can we go with options when creating Shadow dom? Lastly, only a subset of possible upgrades actually are transparent, not affecting public API or behavior. Intersect that set of updates with monkey-patchers who can't live without the update, and you are talking about a relatively small affected class. Well.. yours upgrades maybe... Scott B.
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/25/13 1:52 PM, Scott Miles wrote: Given Boris' arguments, Big Marketshare can simply always mess up his project and blame me and it's my fault. Scott, That's how it often works in the court of public opinion, yes. Your employer is not immune to this behavior. I don't accept it. That's nice. So what? Btw, If Big Marketshare is so powerful, why haven't we already fixed whatever thing he is monkey patching? Because he hasn't bothered to tell us about it; just monkeypatched and shipped (not least because he didn't want to wait for us to fix it). Again, your employer is not immune to this behavior. Also, Optimizely, et al, doesn't simply appear at random. Sure. They get included by the page, but the page may not realize what all they then go and mess with. Again, seems like your argument is that some developer or user may take wanton stet X to break my stuff, and I must prevent it or it's my fault. I think you're trying to paint this black-or-white in a way that seems more about arguing strawmen than addressing the problem. When something breaks in app A due to a change in component B, the problem could be fixed in B, in A, neither, or both. What happens in practice typically depends on the specifics of the change an the specifics of who A and B are, what contracts they have signed, and how much market power they have. You may not like this. _I_ don't like it. But it's reality. re: forced depend on where they got their tomatoes from and You cannot accidentally stumble into ShadowDOM The reason the latter keeps being mentioned is because of statements like the former. Nobody is forcing anybody to break encapsulation. Seems to me the demarcation is very clear. My point is that people will break encapsulation without being forced to. A lot. At least that's what my implementation experience with XBL leads me to believe. Lastly, my point about upgrade statistics is only that the intersection of the two sets is generally going to be smaller than the union of them. Sure. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Mon, Feb 25, 2013 at 11:30 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/25/13 1:52 PM, Scott Miles wrote: Given Boris' arguments, Big Marketshare can simply always mess up his project and blame me and it's my fault. Scott, That's how it often works in the court of public opinion, yes. Your employer is not immune to this behavior. I don't accept it. That's nice. So what? Btw, If Big Marketshare is so powerful, why haven't we already fixed whatever thing he is monkey patching? Because he hasn't bothered to tell us about it; just monkeypatched and shipped (not least because he didn't want to wait for us to fix it). Again, your employer is not immune to this behavior. The good part is that in this forum I get to argue my own opinion, which I would say is that of a (single) web developer. Also, Optimizely, et al, doesn't simply appear at random. Sure. They get included by the page, but the page may not realize what all they then go and mess with. Again, seems like your argument is that some developer or user may take wanton stet X to break my stuff, and I must prevent it or it's my fault. I think you're trying to paint this black-or-white in a way that seems more about arguing strawmen than addressing the problem. When something breaks in app A due to a change in component B, the problem could be fixed in B, in A, neither, or both. What happens in practice typically depends on the specifics of the change an the specifics of who A and B are, what contracts they have signed, and how much market power they have. You may not like this. _I_ don't like it. But it's reality. Ironically, I was trying to argue that these things are on a spectrum and that it is in fact not black and white. Often the argument is, with isolation, maintenance is free! and the alternative is chaos. Seems like we both agree this is not true. re: forced depend on where they got their tomatoes from and You cannot accidentally stumble into ShadowDOM The reason the latter keeps being mentioned is because of statements like the former. Nobody is forcing anybody to break encapsulation. Seems to me the demarcation is very clear. My point is that people will break encapsulation without being forced to. A lot. At least that's what my implementation experience with XBL leads me to believe. This is the moral hazard argument, which is completely worth discussing. Because it's about human nature, I believe there is no objective right answer, but my position as a developer is that I'm annoyed when tools prevent me from doing something I need to do because somebody else might hurt themselves doing it. Lastly, my point about upgrade statistics is only that the intersection of the two sets is generally going to be smaller than the union of them. Sure. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 2/25/13 2:43 PM, Scott Miles wrote: The good part is that in this forum I get to argue my own opinion, which I would say is that of a (single) web developer. Fair. ;) Ironically, I was trying to argue that these things are on a spectrum and that it is in fact not black and white. Often the argument is, with isolation, maintenance is free! and the alternative is chaos. Seems like we both agree this is not true. Indeed. Isolation typically reduces the cost of maintenance, but of course does not make it free. This is the moral hazard argument, which is completely worth discussing. Because it's about human nature, I believe there is no objective right answer, but my position as a developer is that I'm annoyed when tools prevent me from doing something I need to do because somebody else might hurt themselves doing it. I sympathize with that position, for sure. All I can offer, again, is that in our experience this particular issue is a significant problem in practice -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Hello everybody, I'm coming into this conversation late, but wanted to add my thoughts. As has been pointed out in this thread, the web has traditionally been very open and malleable. JavaScript has very few readonly properties, doesn't generally throw exceptions instead guessing or returning bogus values. Making shadow trees hidden clearly goes against this idiom and, by definition, limits what pages will be able to do with external libraries built using shadow DOMs. Even given this downside, though, I think that it's a mistake to make shadow trees accessible to the bound document by default. One of the most important features for frameworks is the ability to provide an encapsulated API. Without that, it becomes extremely difficult to fix bugs or add features to the framework without risking breaking downstream clients. Shadow DOMs are one of a host of features being designed and implemented that make HTML + CSS + JavaScript usable for programming in the wild and it feels like an oversight to make the default imitate the bad ol' days of monkey patching and low to no encapsulation. Finally, reading through the thread, it seems like one of the main use-cases for open-by-default is features like Google Feedback. From my point of view, it seems like features like that need to be considered from the beginning of a site's design. So if a site wants to have something like GF and also use web components and shadow DOMs, then the designers of the components should have to explicitly set the bit that says let other people poke at my internals. I don't think that this one use-case needs to trump the good programming practices of every other library. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Feb 21, 2013 at 6:33 PM, Blake Kaplan mrb...@gmail.com wrote: Hello everybody, I'm coming into this conversation late, but wanted to add my thoughts. As has been pointed out in this thread, the web has traditionally been very open and malleable. JavaScript has very few readonly properties, doesn't generally throw exceptions instead guessing or returning bogus values. Making shadow trees hidden clearly goes against this idiom and, by definition, limits what pages will be able to do with external libraries built using shadow DOMs. Even given this downside, though, I think that it's a mistake to make shadow trees accessible to the bound document by default. One of the most important features for frameworks is the ability to provide an encapsulated API. Without that, it becomes extremely difficult to fix bugs or add features to the framework without risking breaking downstream clients. Shadow DOMs are one of a host of features being designed and implemented that make HTML + CSS + JavaScript usable for programming in the wild and it feels like an oversight to make the default imitate the bad ol' days of monkey patching and low to no encapsulation. Finally, reading through the thread, it seems like one of the main use-cases for open-by-default is features like Google Feedback. From my point of view, it seems like features like that need to be considered from the beginning of a site's design. So if a site wants to have something like GF and also use web components and shadow DOMs, then the designers of the components should have to explicitly set the bit that says let other people poke at my internals. I don't think that this one use-case needs to trump the good programming practices of every other library. We've gone back and forth. It seems that allowing monkeypatching by default is the better choice, as most uses aren't security conscious, they just want the encapsulation benefits. If you are doing something security-conscious, you'd better be thinking about it a bit, and it's trivial to hide your shadow then. Google Feedback is merely one particular example of a whole class of things that *do* want to know the real DOM of the page, and which are fine to allow by default. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Nov 29, 2012, at 12:24 PM, Elliott Sprehn espr...@gmail.com wrote: On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections. Can you explain the use case for wanting private shadows that are not isolated? I still don't entirely buy the use cases for making shadow dom contents public. But I thought the rough consensus in the earlier discussion was to support both modes, not to support public components only. Regards, Maciej
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections. Can you explain the use case for wanting private shadows that are not isolated? - E
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
As of http://dvcs.w3.org/hg/webcomponents/rev/0714c60f265d, there's now an API to traverse the shadow trees: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#api-shadow-aware-shadow-root http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#api-html-shadow-element-older-shadow-root Please let me know if I goofed anything up. File bugs or yell at me. :DG On Fri, Nov 9, 2012 at 10:17 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/8/12 9:28 AM, Elliott Sprehn wrote: If you're worried about malicious attacks on your widget, shadows being private is not enough. You need a whole new scripting context. Er... yes, you do. Do widgets not get that? If not, that's pretty broken... Having a separate scripting context is certainly useful for a certain class of widgets (see Like/+1 button discussion). That's why we have this whole notion of the isolated shadow trees. This is also a fundamental requirement for enabling UA controls to be built with script (I _just_ had a discussion with a fellow WebKit engineer who asked for that). However, for a large class of use cases, mostly represented by the libraries/frameworks, the separate scripting context is an unnecessary barrier. Libraries like bootstrap, quickui, and x-tags are eager to start using shadow DOM to delineate lightweight, purely functional boundaries between composable bits in the same document. For these developers, where things like: a) examining (and sometimes modifying), say a currently selected tab in an tab manager; b) having a central state stored in the document; c) nesting and reusing bits across different libraries; are all expected and counted upon. Adding a scripting context boundary here is just a WTF! stumbling block. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections. - Maciej On Nov 28, 2012, at 1:17 PM, Dimitri Glazkov dglaz...@chromium.org wrote: As of http://dvcs.w3.org/hg/webcomponents/rev/0714c60f265d, there's now an API to traverse the shadow trees: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#api-shadow-aware-shadow-root http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#api-html-shadow-element-older-shadow-root Please let me know if I goofed anything up. File bugs or yell at me. :DG On Fri, Nov 9, 2012 at 10:17 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/8/12 9:28 AM, Elliott Sprehn wrote: If you're worried about malicious attacks on your widget, shadows being private is not enough. You need a whole new scripting context. Er... yes, you do. Do widgets not get that? If not, that's pretty broken... Having a separate scripting context is certainly useful for a certain class of widgets (see Like/+1 button discussion). That's why we have this whole notion of the isolated shadow trees. This is also a fundamental requirement for enabling UA controls to be built with script (I _just_ had a discussion with a fellow WebKit engineer who asked for that). However, for a large class of use cases, mostly represented by the libraries/frameworks, the separate scripting context is an unnecessary barrier. Libraries like bootstrap, quickui, and x-tags are eager to start using shadow DOM to delineate lightweight, purely functional boundaries between composable bits in the same document. For these developers, where things like: a) examining (and sometimes modifying), say a currently selected tab in an tab manager; b) having a central state stored in the document; c) nesting and reusing bits across different libraries; are all expected and counted upon. Adding a scripting context boundary here is just a WTF! stumbling block. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Nov 28, 2012 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Does this support the previously discussed mechanism of allowing either public or private components? I'm not able to tell from the referenced sections. There's no private flag in place yet, I filed the bug to make sure I don't forget about it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 In regard to isolation, I just explicitly state that any shadow trees supplied by UAs mustn't be accessible using this API for the moment. This should be enough to tide us over until we tackle isolation in L2. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 8, 2012 at 9:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/8/12 9:28 AM, Elliott Sprehn wrote: If you're worried about malicious attacks on your widget, shadows being private is not enough. You need a whole new scripting context. Er... yes, you do. Do widgets not get that? If not, that's pretty broken... Having a separate scripting context is certainly useful for a certain class of widgets (see Like/+1 button discussion). That's why we have this whole notion of the isolated shadow trees. This is also a fundamental requirement for enabling UA controls to be built with script (I _just_ had a discussion with a fellow WebKit engineer who asked for that). However, for a large class of use cases, mostly represented by the libraries/frameworks, the separate scripting context is an unnecessary barrier. Libraries like bootstrap, quickui, and x-tags are eager to start using shadow DOM to delineate lightweight, purely functional boundaries between composable bits in the same document. For these developers, where things like: a) examining (and sometimes modifying), say a currently selected tab in an tab manager; b) having a central state stored in the document; c) nesting and reusing bits across different libraries; are all expected and counted upon. Adding a scripting context boundary here is just a WTF! stumbling block. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Traversable shadows are a requirement for a number of things like: - Generic page level libraries and polyfills that need to transform DOM nodes - Generic event handling libraries (ex. Pointer events) - Creating screenshots of the page by rendering every node to a canvas (ex. Google Feedback) - Creating awesome bookmarklets like Readability In our discussions with widget authors we'd either end up making shadows exposed by convention on almost all widget libraries under a common name as authors expect to be able to drop in libraries, polyfills and tools like Feedback, or we'd end up with awful hacks like overriding ShadowRoot or document.createElement. querySelector and friends will still stop at these boundaries, so you would never accidentally fall down into a ShadowRoot. That means that I doubt you'll get widgets being broken as Boris suggests because people aren't going to accidentally modify the inside of your widget. I'd also hate to prevent future innovation like Google Feedback which has turned out to be a critical component for Google product success. I can't share specific numbers, but it's had a very high impact and being able to be dropped into existing pages and just work was fundamental to that. While perhaps we can eventually solve that use case better, who knows what future ideas people will come up with. - E On Tue, Nov 6, 2012 at 3:44 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Thu, Nov 1, 2012 at 9:02 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/1/12 7:41 AM, Tab Atkins Jr. wrote: There was no good *reason* to be private by default Yes, there was. It makes it much simpler to author non-buggy components. Most component authors don't really contemplate how their code will behave if someone violates the invariants they're depending on in their shadow DOMs. We've run into this again and again with XBL. So pretty much any component that has a shadow DOM people can mess with but doesn't explicitly consider that it can happen is likely to be very broken. Depending on what exactly it does, the brokenness can be more or less benign, ranging from doesn't render right to leaks private user data to the world. As a general rule, we should favor being public over being private unless there's a good privacy or security reason to be private. As a general rule we should be making it as easy as possible to write non-buggy code, while still allowing flexibility. In my opinion. This has been my concern as well. The story that made me sway is the elementFromPoint story. It goes like this: we had an engineer come by and ask to add elementFromPoint to ShadowRoot API. ... this is a short story with a happy ending (https://www.w3.org/Bugs/Public/show_bug.cgi?id=18912), since ShadowRoot hasn't shipped anywhere yet. However, imagine all browsers ship Shadow DOM (oh glorious time), and there's a new cool DOM thing that we haven't thought of yet. Without ability to get into shadow trees and polyfill, we'll quickly see people throw nasty hacks at the problem, like they always do (see one that Dominic suggested here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15409#c5). And that seems like a bad smell. I am both excited and terrified. Excited, because discovering Angelina Farro's talk (http://www.youtube.com/watch?v=JNjnv-Gcpnw) makes me realize that this Web Components thing is starting to catch on. Terrified, because we gotta get this right. The Web is traditionally very monkey-patchey and pliable and our strides to make the boundaries hard will just breed perversion. Anyhow. Elliott has made several passionate arguments for travsersable shadow trees in person. Maybe he'll have a chance to chime in here. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: ... 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. As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into canvas without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things? We don't handle visited link coloring as there's no way to get that from JS. For images we proxy all images and do the actual drawing to the canvas in a nested iframe that's on the same domain as the proxy. For cross domain iframes we have a JS API that the frame can include that handles a special postMessage which serializes the entire page and then unserializes on the other side for rendering. Thankfully this case is extremely rare unlike web components where it turns out you end up with almost the entire page down in some component or another (ex. x-panel, x-conversation-view …). This of course requires you to have control of the cross origin page. For an architectural overview of Google Feedback's JS HTML rendering engine you can look at this presentation, slides 6 and 10 explain the image proxy: http://www.elliottsprehn.com/preso/fluentconf/ - E
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 11/8/12 1:45 AM, Elliott Sprehn wrote: That means that I doubt you'll get widgets being broken as Boris suggests because people aren't going to accidentally modify the inside of your widget. The problems start when people _maliciously_ modify the inside of your widget. Again, with XBL you don't get to accidentally modify the insides of anonymous content (shadow) trees. But there were all sorts of attack scenarious where people could modify them at all. I'd also hate to prevent future innovation like Google Feedback which has turned out to be a critical component for Google product success. I would like to understand more here. How does preventing touching the shadow tree by default prevent something like Google Feedback? -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 8, 2012 at 8:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/8/12 1:45 AM, Elliott Sprehn wrote:
That means that I
doubt you'll get widgets being broken as Boris suggests because people
aren't going to accidentally modify the inside of your widget.
The problems start when people _maliciously_ modify the inside of your
widget. Again, with XBL you don't get to accidentally modify the insides
of anonymous content (shadow) trees. But there were all sorts of attack
scenarious where people could modify them at all.
If you're worried about malicious attacks on your widget, shadows being
private is not enough. You need a whole new scripting context. I can
override all the String and Array methods, DOM prototype methods,
document.createElement, document.implementation methods, MutationObserver
etc. or even the ShadowRoot constructor with the current API and still
likely capture the inside of your component. This is JavaScript after all.
:)
You're much better off using a public shadow and then putting your whole
widget in a cross domain iframe to get a new scripting context instead of
depending on the false security of a private shadow.
I'd also hate to prevent future innovation like Google Feedback which
has turned out to be a critical component for Google product success.
I would like to understand more here. How does preventing touching the
shadow tree by default prevent something like Google Feedback?
Google Feedback is an HTML rendering engine written in JS. To render the
document you need access to every DOM node so you can draw it to a canvas.
In the world of web components much, or often all, of your web application
ends up inside of a component. We can imagine Gmail is something like:
x-toolbar/x-toolbar
x-panel
x-label-sidebar/x-label-sidebar
x-conversation/x-conversation
/x-panel
Google Feedback would be unnable to access the private shadow tree where
the actual content of the page is so your screenshot would be blank.
Today Google Feedback just works on most pages on the web and can be
activated through a bookmarklet on any website, even ones that Google does
not control. In the future this wouldn't be possible if shadows were
private by default and authors didn't consider all future library and
widget integrations.
For more information about Google Feedback see my recent architecture
presentation:
http://elliottsprehn.com/preso/fluentconf/
Another example is Readability:
http://www.readability.com/bookmarklets
Once the articles on news websites are actually just x-news-article
articleId={bindingForArticleId}/x-news-article and load from the model
into their shadow they become hidden from bookmarklets that wish to
traverse down into them making future innovations like Readbility difficult
without super hacks.
- E
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
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 theisolated 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. 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
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
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 theisolated 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
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Nov 8, 2012, at 2:15 AM, Elliott Sprehn espr...@gmail.com wrote: On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: ... 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. As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into canvas without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things? We don't handle visited link coloring as there's no way to get that from JS. For images we proxy all images and do the actual drawing to the canvas in a nested iframe that's on the same domain as the proxy. For cross domain iframes we have a JS API that the frame can include that handles a special postMessage which serializes the entire page and then unserializes on the other side for rendering. Thankfully this case is extremely rare unlike web components where it turns out you end up with almost the entire page down in some component or another (ex. x-panel, x-conversation-view …). This of course requires you to have control of the cross origin page. For an architectural overview of Google Feedback's JS HTML rendering engine you can look at this presentation, slides 6 and 10 explain the image proxy: http://www.elliottsprehn.com/preso/fluentconf/ Are these types of workarounds adequate for the web components case? If not, why not? Regards, Maciej
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 8, 2012 at 9:55 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 8, 2012, at 2:15 AM, Elliott Sprehn espr...@gmail.com wrote: On Thu, Nov 1, 2012 at 6:43 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: 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. As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into canvas without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things? We don't handle visited link coloring as there's no way to get that from JS. For images we proxy all images and do the actual drawing to the canvas in a nested iframe that's on the same domain as the proxy. For cross domain iframes we have a JS API that the frame can include that handles a special postMessage which serializes the entire page and then unserializes on the other side for rendering. Thankfully this case is extremely rare unlike web components where it turns out you end up with almost the entire page down in some component or another (ex. x-panel, x-conversation-view …). This of course requires you to have control of the cross origin page. For an architectural overview of Google Feedback's JS HTML rendering engine you can look at this presentation, slides 6 and 10 explain the image proxy: http://www.elliottsprehn.com/preso/fluentconf/ Are these types of workarounds adequate for the web components case? If not, why not? No, it should be very obvious that you can't do similar workarounds. The inability to detect history state is largely unimportant. It's a trivial loss for most use-cases in this area. The workaround for the crossorigin security issue (by proxying images) is completely inapplicable for Components. With an image, you have all the information you need right there at the DOM level - you grab the URL, run a server-side proxy, and you're done. That's the entire content of the image. There is obviously nothing similar for components with hidden shadows. ~TJ
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 11/8/12 9:28 AM, Elliott Sprehn wrote: If you're worried about malicious attacks on your widget, shadows being private is not enough. You need a whole new scripting context. Er... yes, you do. Do widgets not get that? If not, that's pretty broken... Google Feedback is an HTML rendering engine written in JS. To render the document you need access to every DOM node so you can draw it to a canvas. I see. It'll still break with things like images and whatnot if you want to extract the data from that canvas (in general, modulo CORS etc), but yes, I can see how not being able to get inside components is a problem. I wonder whether making access to the insides of components work based on same-origin restrictions + CORS makes sense. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 1, 2012 at 8:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 1, 2012 at 2:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@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. As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into canvas without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things? 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. I don't enough of the context to follow this. Right now there's no good general mechanism for a component exposing its guts, other than by convention, right? It seems like adding a general mechanism to do so is a good idea, but it could work with either default or with no default at all and requiring authors to specify explicitly. I think specifying either way explicitly would be best. JS lets you have public properties in an object, or private properties (effectively) in a closure, so both options are available and neither is default. It's your choice whether to use encapsulation. I am not sure we need to specifically nudge web developers away from encapsulation. I'm fine with specifying explicitly too. The case we're trying to avoid is authors getting (unneeded) privacy by default, just because they did the easiest thing and didn't think too hard about it. The analogy with JS is somewhat telling - it's harder and less convenient to make private (closure) variables in JS. Even when we add Symbols to the language, it'll still be easier to just use normal (public) properties. 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. 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
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 1, 2012 at 9:02 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/1/12 7:41 AM, Tab Atkins Jr. wrote: There was no good *reason* to be private by default Yes, there was. It makes it much simpler to author non-buggy components. Most component authors don't really contemplate how their code will behave if someone violates the invariants they're depending on in their shadow DOMs. We've run into this again and again with XBL. So pretty much any component that has a shadow DOM people can mess with but doesn't explicitly consider that it can happen is likely to be very broken. Depending on what exactly it does, the brokenness can be more or less benign, ranging from doesn't render right to leaks private user data to the world. As a general rule, we should favor being public over being private unless there's a good privacy or security reason to be private. As a general rule we should be making it as easy as possible to write non-buggy code, while still allowing flexibility. In my opinion. This has been my concern as well. The story that made me sway is the elementFromPoint story. It goes like this: we had an engineer come by and ask to add elementFromPoint to ShadowRoot API. ... this is a short story with a happy ending (https://www.w3.org/Bugs/Public/show_bug.cgi?id=18912), since ShadowRoot hasn't shipped anywhere yet. However, imagine all browsers ship Shadow DOM (oh glorious time), and there's a new cool DOM thing that we haven't thought of yet. Without ability to get into shadow trees and polyfill, we'll quickly see people throw nasty hacks at the problem, like they always do (see one that Dominic suggested here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15409#c5). And that seems like a bad smell. I am both excited and terrified. Excited, because discovering Angelina Farro's talk (http://www.youtube.com/watch?v=JNjnv-Gcpnw) makes me realize that this Web Components thing is starting to catch on. Terrified, because we gotta get this right. The Web is traditionally very monkey-patchey and pliable and our strides to make the boundaries hard will just breed perversion. Anyhow. Elliott has made several passionate arguments for travsersable shadow trees in person. Maybe he'll have a chance to chime in here. :DG
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@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
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@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
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@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. As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into canvas without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things? 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. I don't enough of the context to follow this. Right now there's no good general mechanism for a component exposing its guts, other than by convention, right? It seems like adding a general mechanism to do so is a good idea, but it could work with either default or with no default at all and requiring authors to specify explicitly. I think specifying either way explicitly would be best. JS lets you have public properties in an object, or private properties (effectively) in a closure, so both options are available and neither is default. It's your choice whether to use encapsulation. I am not sure we need to specifically nudge web developers away from encapsulation. 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. That seems workable. 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? One thing that makes me nervous about theisolated 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
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On 11/1/12 7:41 AM, Tab Atkins Jr. wrote: There was no good *reason* to be private by default Yes, there was. It makes it much simpler to author non-buggy components. Most component authors don't really contemplate how their code will behave if someone violates the invariants they're depending on in their shadow DOMs. We've run into this again and again with XBL. So pretty much any component that has a shadow DOM people can mess with but doesn't explicitly consider that it can happen is likely to be very broken. Depending on what exactly it does, the brokenness can be more or less benign, ranging from doesn't render right to leaks private user data to the world. As a general rule, we should favor being public over being private unless there's a good privacy or security reason to be private. As a general rule we should be making it as easy as possible to write non-buggy code, while still allowing flexibility. In my opinion. -Boris
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Nov 1, 2012 at 2:43 PM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Nov 1, 2012 at 9:37 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 1, 2012, at 12:02 AM, Dimitri Glazkov dglaz...@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. As Adam Barth often points out, in general it's not safe to paint pieces of a webpage into canvas without security/privacy risk. How does Google Feedback deal with non-same-origin images or videos or iframes, or with visited link coloring, to cite a few examples? Does it just not handle those things? 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. I don't enough of the context to follow this. Right now there's no good general mechanism for a component exposing its guts, other than by convention, right? It seems like adding a general mechanism to do so is a good idea, but it could work with either default or with no default at all and requiring authors to specify explicitly. I think specifying either way explicitly would be best. JS lets you have public properties in an object, or private properties (effectively) in a closure, so both options are available and neither is default. It's your choice whether to use encapsulation. I am not sure we need to specifically nudge web developers away from encapsulation. I'm fine with specifying explicitly too. The case we're trying to avoid is authors getting (unneeded) privacy by default, just because they did the easiest thing and didn't think too hard about it. The analogy with JS is somewhat telling - it's harder and less convenient to make private (closure) variables in JS. Even when we add Symbols to the language, it'll still be easier to just use normal (public) properties. 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. One thing that makes me nervous about theisolated 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. Flipping it
[webcomponents]: Making Shadow DOM Subtrees Traversable
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. 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. 2) There's a mechanism in place to flip this switch (specifics TBD) 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. Comment here or on bug. :DG
