Re: Mozilla and the Shadow DOM
This is an interesting approach that didn't occur to me! Similar to Anne's concerns, this would require you to have more knowledge of the internals of the super-class component. If you own both components then this is fine. Also if this means we can remove a complex piece from the spec to help reach consensus, great! :) Wilson On Thu, Apr 16, 2015 at 1:41 AM, Elliott Sprehn espr...@chromium.org wrote: On Wed, Apr 15, 2015 at 6:30 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren ann...@annevk.nl wrote: * Multiple shadow roots. We'd like to retain this feature. Although it has complexity, we've heard from both Firefox UI and Firefox OS application developers that the moment your library gets sophisticated, you want this for extensibility. I was asked to provide a use case for our stance. One that we've found with Firefox OS is custom dialogs, quoting Wilson Page: # I have an x-dialog component. It takes care of transitioning # in and out of the viewport and appropriate styling contained # elements (h1, button, p). # # I want to be able to extend this component to produce # x-dialog-alert. In this case extending the prototype alone # isn't enough, I need to also be able to extend the markup # and styling of x-dialog. # # At the point of creation x-dialog-alert can add a second # ShadowRoot that allows it to compose its own content # inside that of the 'old' x-dialog ShadowRoot. Without this # x-dialog-alert would have to duplicate all the markup, style # and interaction code again. I don't think you need to duplicate anything. The super class can still fill in the original shadow root, then the subclass can modify it. This is the same concept of the prototype inheritance, your methods will shadow the super class methods, but you can just call them and then extend the behavior. This is also the reason the created and attached callbacks are on the prototype. So you can call super and use the parent behavior by shared protocol. - E
Re: Mozilla and the Shadow DOM
On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com wrote: This is an interesting approach that didn't occur to me! Similar to Anne's concerns, this would require you to have more knowledge of the internals of the super-class component. If you own both components then this is fine. Yes, the main problem here is the degree of separation between creator and consumer of the base component. The higher the degree, the less inclined the creator will be to expose innards of the shadow tree to the consumer. Multiple shadow roots solves the same problem as shadow trees (provides a composition contract), but along the inheritance chain. For example, multiple shadow roots make sense: * if you are a maker of UI library that's strongly rooted in inheritance and intend to for your base components to be used directly; * if you are hoping to inherit from components with closed shadow trees. Also if this means we can remove a complex piece from the spec to help reach consensus, great! :) Whatever it takes. :DG
Re: Mozilla and the Shadow DOM
Updated https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446 with the latest, to keep the history in bug. :DG On Thu, Apr 16, 2015 at 7:52 AM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com wrote: This is an interesting approach that didn't occur to me! Similar to Anne's concerns, this would require you to have more knowledge of the internals of the super-class component. If you own both components then this is fine. Yes, the main problem here is the degree of separation between creator and consumer of the base component. The higher the degree, the less inclined the creator will be to expose innards of the shadow tree to the consumer. Multiple shadow roots solves the same problem as shadow trees (provides a composition contract), but along the inheritance chain. For example, multiple shadow roots make sense: * if you are a maker of UI library that's strongly rooted in inheritance and intend to for your base components to be used directly; * if you are hoping to inherit from components with closed shadow trees. Also if this means we can remove a complex piece from the spec to help reach consensus, great! :) Whatever it takes. :DG
Re: Mozilla and the Shadow DOM
On Wed, Apr 8, 2015 at 8:17 AM, Anne van Kesteren ann...@annevk.nl wrote: * Multiple shadow roots. We'd like to retain this feature. Although it has complexity, we've heard from both Firefox UI and Firefox OS application developers that the moment your library gets sophisticated, you want this for extensibility. I was asked to provide a use case for our stance. One that we've found with Firefox OS is custom dialogs, quoting Wilson Page: # I have an x-dialog component. It takes care of transitioning # in and out of the viewport and appropriate styling contained # elements (h1, button, p). # # I want to be able to extend this component to produce # x-dialog-alert. In this case extending the prototype alone # isn't enough, I need to also be able to extend the markup # and styling of x-dialog. # # At the point of creation x-dialog-alert can add a second # ShadowRoot that allows it to compose its own content # inside that of the 'old' x-dialog ShadowRoot. Without this # x-dialog-alert would have to duplicate all the markup, style # and interaction code again. -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
On Thu, Apr 16, 2015 at 2:41 AM, Elliott Sprehn espr...@chromium.org wrote: I don't think you need to duplicate anything. The super class can still fill in the original shadow root, then the subclass can modify it. This is the same concept of the prototype inheritance, your methods will shadow the super class methods, but you can just call them and then extend the behavior. In this case the subclass would have to poke into the superclass' shadow DOM. If at any point those writing the superclass decide to change the structure of that DOM they might end up breaking a subclass they had no knowledge of. Allowing insertion of the whole shadow DOM allows for changes that have fewer side effects. Having said that, if your comment means that Google is no longer interested in keeping this, we can probably be persuaded to keep this out of a cross-browser v1 of shadow DOM. -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. This seems like something we can fix by bug triage. Both Hayato and I periodically garden the bug tree ( https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978hide_resolved=1 ). The process works as follows: 1) The bug tree is broken by categories of work, with each category being a meta bug (title prefixed with [meta]). 2) As new bugs are filed, they end up at the bottom of the tree 3) Periodically, we triage these bugs at the bottom and mark them as blocking meta bugs. 4) Those meta bugs that no longer have blocking bugs are closed as fixed. To make it easier for you to track Mozilla-related bugs, we need to create a meta bug, like I did a while back for custom elements: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20684hide_resolved=0 Here's the new bug for Shadow DOM: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28491. I started added things I know as blocking to it, please feel free to add those that I missed. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 I am sure Polymer folks will be super-happy to help. Let's continue discussion on your bug. :DG
Re: Mozilla and the Shadow DOM
Just to close the loop, filed https://github.com/webcomponents/webcomponentsjs/issues/289 to track the specific Polymer web component polyfill blocker. On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 The linked bug is simply incorrect. Polymer depends on webcomponentsjs ( https://github.com/webcomponents/webcomponentsjs) for browsers without all the Web Components specs, but each part is feature detected, with separate checks for Custom Elements, HTML Imports, and ShadowDOM, as well as HTML Template, constructable URL, and MutationObserver Chrome did not implement and ship all the specs at once, so Polymer has had to feature detect from the start. -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
!-- Whoops, my draft got cut off. -- We found some timing issues with polyfill HTML Imports and native Custom Elements in Chrome that made us force the Custom Elements polyfill when HTML Imports is polyfilled. I don't remember the specifics, but I filed the github issue to either track down and resolve the issues, or provide a flag to override this behavior for Mozilla to use in testing. Sorry for the grumbly note, we've tried very hard to make sure Polymer !== Web Components in public discourse to keep people from conflating the two. On Tue, Apr 14, 2015 at 12:29 PM, Daniel Freedman dfre...@google.com wrote: Just to close the loop, filed https://github.com/webcomponents/webcomponentsjs/issues/289 to track the specific Polymer web component polyfill blocker. On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 The linked bug is simply incorrect. Polymer depends on webcomponentsjs ( https://github.com/webcomponents/webcomponentsjs) for browsers without all the Web Components specs, but each part is feature detected, with separate checks for Custom Elements, HTML Imports, and ShadowDOM, as well as HTML Template, constructable URL, and MutationObserver Chrome did not implement and ship all the specs at once, so Polymer has had to feature detect from the start. -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach is that with Shadow DOM (and maybe Web Components in general) there's a lot of open bugs. Of those bugs it's not at all clear which the editors plan on addressing. Which makes it harder to plan for us. Also, a point that I forgot to make in my initial email is that Polymer makes it rather hard for us to ship any part of Web Components without all the other parts (and in the manner that Chrome implemented the features): https://bugzilla.mozilla.org/show_bug.cgi?id=1107662 -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
On Wed, Apr 8, 2015 at 9:56 AM, Hayato Ito hay...@chromium.org wrote: At the same time, however, I still have a concern, Do developers really need such a fine-grained control? Is it too early optimization, isn't? There has been pretty clear feedback from e.g. Ember that not exposing the primitives but rather a package of primitives is what stopped them from adopting the technology. And this is a recurring theme whenever we package various features together. It's why https://extensiblewebmanifesto.org/ was written up. And although that has been cited as support for Web Components, it seems quite clear in hindsight that the initial Web Components proposal did not go far enough. For example, in the past, event.path() filtered out a node if it's in an (open) shadow tree, however, I changed it because developers gave us the feedback that they want to see a node even if it's in a shadow tree. Right, which is why I think we should not have event retargeting by default. It makes sense for closed and future isolated trees, but not for open. Also making event.path and event.target use a different model is reminiscent of the originalTarget hack from XBL. -- https://annevankesteren.nl/
Re: Mozilla and the Shadow DOM
Anne, Thank you for sharing. I'm feeling that we might want to divide each feature provided by ShadowDOM into more fine-grained opt-in/opt-out features, if developers want it. At the same time, however, I still have a concern, Do developers really need such a fine-grained control? Is it too early optimization, isn't? I don't have a strong opinion on this. I'd like to hear more feedbacks from web developers who is making real world UI, like Firefox UI, Firefox OS and so on. Currently, most of the features are *hard-coded* in the spec and users can't customize at all. The concept of Closed Shadow Trees is the first way to customize the feature set, however it still provides a pre-defined features set. In summary: (You might want to see the following in monospaced font) Open Closed Event Retargeting for a node in: xx Deny DOM access, such as element.shadowRoot(), into shadow trees: x CSS property values inherits into: xx CSS selector doesn't piece into shadow trees: xx Special Shadow DOM CSS selector doesn't piece into shadow trees: x Filtering a node in event.path() if they are in: x (This is not spec-ed yet) Filtering a node in element.getDestinationInsertionPoints() if they are in: x ..and so on For example, in the past, event.path() filtered out a node if it's in an (open) shadow tree, however, I changed it because developers gave us the feedback that they want to see a node even if it's in a shadow tree. I expect that the same thing would happen again. It might be difficult for us to provide a pre-defined set of features which satisfies all requirements. Currently, we're going to have two pre-defined sets, open and closed. Can this two sets satisfy all requirements? I'm not sure. Other comments inlined, On Wed, Apr 8, 2015 at 3:20 PM Anne van Kesteren ann...@annevk.nl wrote: We have done some brainstorming internally around what we want out of Shadow DOM and components in general, between those working on Gaia (Firefox OS applications) and those working on Platform (Gecko). We hope to be able to discuss this at the meeting later this month and also at the Extensible Web Summit that precedes it. And of course on this list, happy to answer any questions. For custom elements https://wiki.whatwg.org/wiki/Custom_Elements is still an accurate summary of where we are at. For shadow DOM I wrote this summary: * Layout containment. We hope that evolving http://dev.w3.org/csswg/css-containment/ further could allow for some interesting optimizations and hopefully something akin to element queries or a resize event down the road. (This is basically a feature of iframe that components lack.) * Declarative shadow DOM. Mostly for performance it would be nice if the composed tree could be serialized and cached. That way first render only requires HTML and CSS with JavaScript kicking in at the end. We reasoned it might not be too hard to add something like shadowroot given our experience with template. The only difference would be that shadowroot itself would also not be appended to the tree and that the DocumentFragment nee ShadowRoot is associated with its parent. I agree. Declarative shadow DOM is a really nice feature. That would make my life easier. I don't need to write JS to construct a tree of trees in writing a test casually. What's more important is that we can serialize/deserialize a tree of trees by declarative syntax. For example, unless custom elements are used, users can't copy and paste a piece of the page which uses Shadow DOM. Users will lose Shadow DOM through copy/paste. * Isolated shadow DOM. This is the idea of having a DOM worker so that instead of ten iframes with ten globals you can have one global with ten somethings. This would give applications more parallelization opportunities and would hopefully enable a large number of companies from moving away of the practice of using cross-origin script with all its security implications. * Imperative distribution (C). Distribution can already be observed in many ways through events and selectors. As a first step we should probably define more precisely when it happens in terms of the event loop. And then make it imperative. (I was a bit surprised with the thread that seemed to conclude at https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0423.html as Ryosuke's proposal seemed like a good minimal API to do this.) * Making event retargeting opt-in/out (D). I think opt-in (or only with isolated) would be better and perhaps if the API needs to change anyway we can do that, but we could probably live with opt-out as well. When you use shadow DOM to compose, global reasoning about state and events is a fairly established pattern that we should enable. * Closed-but-no-sigar (B, E). We're not sure about closed shadow DOM. With composition/layout you want scripts to be able to go in and out. (See also event
