Proposed W3C CG - The Extended Web
https://www.w3.org/community/blog/2015/04/19/proposed-group-the-extended-web-community-group/ Since the CG description is free from political stuff, I included it here :-) Most of the things exposed in the system-level (native) APIs of Android, iOS, Windows, etc. could indeed be provided in web-browsers. However, the cost and time that this would take as well as the ever-increasing speed of native OS and related hardware developments make this unrealistic except for a rather modest set of well-scoped APIs. It has also proven to be considerably harder dealing with untrusted web-code than originally thought. The Extended Web CG is about *COMBINING the power of the two worlds* which is a bit nicer than the current Platform War (which like regular wars doesn't really make anybody happy). To achieve that, The Extended Web CG is dedicated developing a *secure link* between the Open [untrusted] Web and the Native [trusted] layer, independently of how the latter is expressed. The current idea is building on an *enhanced version* of Chrome's Native Messaging: http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/ http://blog.chromium.org/2013/10/connecting-chrome-apps-and-extensions.html The single most important feature of Native Messaging is that it offers *a way for third-parties to innovate* in areas ranging from Secure Web-payments to Streaming Media-services as well as one-of-a-kind vendor-specific solutions like Remote Diagnostics for PCs. FWIW, it seems that the core concept (talking securely with a web-page), could, and with relative ease (fingers crossed...), also include mobile devices connected to a web-page through an NFC/Bluetooth(BLE) combo link: https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf A defensive publication has recently been submitted for this proposal. Anders Rundgren convener/firestarter https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015 10:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote: On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html I just wanted to note that a month or two I tried to assume nothing and come up with a bare essentials concept which involved named slots. Is there a proposed a way to project from an attribute value into content or from attribute to attribute..? In other words, if I had x-foo blah=hello . Can I map blah into a slot or identify an attribute value in my template *as* a slot? Not at the moment but I could imagine that such a feature could be easily added. e.g. x-foo blah=hello !-- implementation -- template element=x-foo content attrslot=blah /template - R. Niwa For the record, I'd love to see that discussed as part of a real proposal because I think it's pretty useful - you can see lots of things essentially trying to do custom elements in the wild with a similar need and it honestly seems easier than element based slots technically speaking so it would be a shame to lack it.
RE: Proposal for changes to manage Shadow DOM content distribution
Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context?
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015, at 11:08 PM, Domenic Denicola d...@domenic.me wrote: From: Ryosuke Niwa [mailto:rn...@apple.com] At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. details is such an example, I think? Is the following a correct example of what client code would have to look like for details, under the proposal? details div content-slot=summaryStuff/div div content-slot=main pMore/p pStuff/p /div /details or, if you wanted to avoid the wrapper div, details div content-slot=summaryStuff/div p content-slot=mainMore/p p content-slot=mainStuff/p /details This can just be details div content-slot=summaryStuff/div pMore/p pStuff/p /details if our implementation had something along the line of: template element=details content slot=summary/content content/content /template since we still support unnamed content element as the catch-all insertion point as it is today. I'd rather not do it because it's rather confusing and arbitrary but if we really wanted to, it might be okay to allow element name as a slot-content name. e.g. the above example reduces to: details summaryStuff/summary pMore/p pStuff/p /details That is, each element implicitly defines content-slot attribute with the value set to its element name. - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Cheers, Justin - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
Another technique I've seen used is compound selectors, which could be used to migrate from one selector to another while preserving backwards compatibility, or to provide some nice default distributions that are also accessible via a class or attribute (ie, select=header, .header). Could slots have multiple names to support something like this? On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Cheers, Justin - R. Niwa
[Bug 28539] New: [Shadow]: Typos Spefifies and Speficies
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28539 Bug ID: 28539 Summary: [Shadow]: Typos Spefifies and Speficies Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 In http://w3c.github.io/webcomponents/spec/shadow/#dictionary-shadowrootinit-members Should be Specifies -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
This is literally reinventing Selectors at this point. The solution to we don't think it's worth implementing *all* of Selectors is to define a subset of supported Selectors, not to define a brand new mechanism that's equivalent to selectors but with a new syntax. On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani justinfagn...@google.com wrote: Another technique I've seen used is compound selectors, which could be used to migrate from one selector to another while preserving backwards compatibility, or to provide some nice default distributions that are also accessible via a class or attribute (ie, select=header, .header). Could slots have multiple names to support something like this? On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Cheers, Justin - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 22, 2015, at 3:48 PM, Justin Fagnani justinfagn...@google.com wrote: On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. What are concrete use cases that require such flexibility? Require is a strong word :) but the case I recently experienced was a panel with a header. It always expects one child for the header and the rest for content. There are several ways to do this, and one would be to select the first child into one distribution point and the rest into another. Another way is to use attributes, classes or a specific set of tag names. The key for me here is that you give the custom element author a choice on how to shape their API. I don't think letting authors of each component choose how to select nodes of distributions will increase the inconsistencies between components written by different authors and deteriorate the ergonomics of component users. template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Our point wasn't so much that it's not achievable. With enough hackeries and techniques, we can. The problem is the developer ergonomics of content element with select attribute with common real world use cases. For example, the above code is a lot more verbose and less intuitive than template content slot=header/content content/content content slot=footer/content /template This is true, but it's a trade off for custom element authoring brevity vs custom element use brevity (and authoring expressiveness). I'd personally rather optimize for custom element user ergonomics, and give custom element authors the power to make their elements easy and convenient. Continuing this example I would actually make the selectors more complex because we have these nice semantic elements in html5: template content select=header, .header/content content select=:not(footer, .footer)/content content select=footer, .footer/content /template Which is more work for the CE author, but allows this for the user: my-element headerTitle/header p.../p p.../p footer.../footer /my-element That's a fair point but it is a feature that the user of components needs to explicitly opt-in to use slot-content. That explicit contract ensures the API surface to be limited. Suppose in the version 1 of this component, it only supported header. If the version 2 of this component subsequently added the support for footer, it's unclear whether every existing use of footer element is appropriate for node distribution. This poses a serious challenge for adding new features to your components. In addition, such an explicit contract is a must-have requirement for cross-origin components we (Apple's WebKit team) have been advocating for years now. - R. Niwa
[Bug 28547] New: Remove the support for inherting from builtin subclasses of HTMLElement and SVGElement
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28547 Bug ID: 28547 Summary: Remove the support for inherting from builtin subclasses of HTMLElement and SVGElement Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org See https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements Subclassing existing elements is hard as implementation-wise identity is both object-based and name / namespace based. Therefore subclassing an existing element (currently) requires that the name / namespace does not change. See also DOM: element constructors. A hack was invented to make this work: button is=my-button. That hack is not well liked leaving us two options: We leave this for now and work on this in parallel while stabilizing a smaller subset of custom elements. We block on this and delay even more. (Assuming that not all implementers are suddenly going to be okay with this hack.) However, without this hack accessibility for trivial components is harder as more things have to be done by hand. Another use case had emerged for the is hack: piggy-backing on parser behaviors. For example, extending template for data binding or as a way to specify shadow trees in HTML. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. Oh, interesting. That appears to be a complete non-sequitur, tho, as no one has asked for anything like that. It's *certainly* irrelevant as a response to the text you quoted. I find it decidedly relevant given I'm pointing out that attribute-specified slots Domenic mentioned isn't what you described. Since the only venue in which attribute-specified slots came up are [1], [2], and [3]. We're DEFINITELY NOT interested in filling slots based on values of arbitrary attributes. [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
Ugh, hit send too fast. In the university site example below, the instance should have been written: physics-department-page span content-slot=“headerFaculty/span /physics-department-page –Jan On Apr 22, 2015, at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote: Hi Tab, Thanks for your feedback! A primary motivation for proposing names instead of CSS selectors to control distribution is to enable subclassing. We think it’s important for a subclass to be able to override a base class insertion point. That seems easier to achieve with a name. It lets content insertion points behave like named DOM-valued component parameters that can be overridden by subclasses. To use an example, consider the page template component example at https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates. The image shows a page template for a large university web site. In this example, a base page template class defines a header slot. A university department wants to create a subclass of this template that partially populates some of the base class’ slots. In this case, it may want to add the department name to the header slot, then redefine an insertion point with the name that lets an individual page in that department add additional text to the header. The physics department page template subclass could then write something like this (following the proposal's syntax): template div content-slot=“header” Physics Department content slot=“header”/content /div template If an instance of this page then says physics-department-page headerFaculty/header /physics-department-page then the rendered result shows “Physics Department Faculty” in the base template header. This is analogous to what typical OOP languages enable when a subclass overrides a base class property. In such languages, the subclass simply defines a property with the same name as a base class property. The subclass’ property implementation can invoke the base class property implementation if it wants. The model is fairly easy to understand and implement, because the properties are always identified by name. A similar result could theoretically be achieved with CSS selectors, but the approach feels looser and a bit unwieldy, particularly if there are not rigid conventions about how the content select clauses are written. Assuming it were possible to reproject into a base class’ shadow — and that’s not actually possible today — you’d have to write something like: template shadow div class=“header” Physics Department content select=“.header/content /div /shadow /template So that approach could be made to work, but to me at least, feels harder, especially if the base class is using complex CSS selectors. –Jan On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com mailto:jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com mailto:jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me mailto:d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. Oh, interesting. That appears to be a complete non-sequitur, tho, as no one has asked for anything like that. It's *certainly* irrelevant as a response to the text you quoted. On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com mailto:jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: I don't think defining a slot based on an attribute value is something we'd like to support. That is *literally* what your proposal already is, except limited to only paying attention to the value of the content-slot attribute. Distributing elements based on the value of a single well scoped attribute versus of an arbitrary attribute is A HUGE difference.
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 4:40 PM, Jan Miksovsky jan@component.kitchen wrote: Hi Tab, Thanks for your feedback! A primary motivation for proposing names instead of CSS selectors to control distribution is to enable subclassing. We think it’s important for a subclass to be able to override a base class insertion point. I understand this motivation and think it's a great point that hasn't (yet) received enough attention... But I think we would give up to much user ergonomics in exchange for it under this proposal. I think we can relatively easily add the ability to redirect nodes into distribution points of base classes to the existing system which gives some control to authors on how to select nodes for distribution. That seems easier to achieve with a name. It lets content insertion points behave like named DOM-valued component parameters that can be overridden by subclasses. To use an example, consider the page template component example at https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates. The image shows a page template for a large university web site. In this example, a base page template class defines a header slot. A university department wants to create a subclass of this template that partially populates some of the base class’ slots. In this case, it may want to add the department name to the header slot, then redefine an insertion point with the name that lets an individual page in that department add additional text to the header. The physics department page template subclass could then write something like this (following the proposal's syntax): template div content-slot=“header” Physics Department content slot=“header”/content /div template If an instance of this page then says physics-department-page headerFaculty/header /physics-department-page I know you mistakenly used a header tag rather than content-slot here, but I think it shows my point: this here (using header tags) might be the better API, and I feel that the element author should be able to offer it instead of forcing users to add content-slot attributes everywhere. I think this proposal targets custom element subclassers at the expense of custom element users. Yes, subclassers might need fine-grained control over routing children and distributed nodes into base class distribution points. But should end-users have to use the same API surface for that? For custom elements to be successful we don't just need to appeal to element authors, but in turn to their users. Cheers, Justin then the rendered result shows “Physics Department Faculty” in the base template header. This is analogous to what typical OOP languages enable when a subclass overrides a base class property. In such languages, the subclass simply defines a property with the same name as a base class property. The subclass’ property implementation can invoke the base class property implementation if it wants. The model is fairly easy to understand and implement, because the properties are always identified by name. A similar result could theoretically be achieved with CSS selectors, but the approach feels looser and a bit unwieldy, particularly if there are not rigid conventions about how the content select clauses are written. Assuming it were possible to reproject into a base class’ shadow — and that’s not actually possible today — you’d have to write something like: template shadow div class=“header” Physics Department content select=“.header/content /div /shadow /template So that approach could be made to work, but to me at least, feels harder, especially if the base class is using complex CSS selectors. –Jan On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. Oh, interesting. That appears to be a complete non-sequitur, tho, as no one has asked for anything like that.
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] I don't think defining a slot based on an attribute value is something we'd like to support. That is *literally* what your proposal already is, except limited to only paying attention to the value of the content-slot attribute. ~TJ
[Bug 28541] New: Custom elements should use ES6 class constructor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541 Bug ID: 28541 Summary: Custom elements should use ES6 class constructor Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org As discussed, docuemnt.regsiterElement currently replaces the constructor so that it rips out any static methods defined using the ES6 class syntax. We shouldn't do that. We should preserve the original constructor/class object defiend by the author. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
On 04/22/2015 03:54 PM, Tab Atkins Jr. wrote: On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. Oh, interesting. That appears to be a complete non-sequitur, tho, as no one has asked for anything like that. It's *certainly* irrelevant as a response to the text you quoted. FYI, putting attribute into the (attribute) insertion point is something XBL[1|2] support. https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content#Attribute_Forwarding http://www-archive.mozilla.org/projects/xbl/xbl2.html#forwarding xbl:text isn't used too often, but used anyhow, http://mxr.mozilla.org/mozilla-central/search?string=xbl%3Atext and xbl:inherits is rather common http://mxr.mozilla.org/mozilla-central/search?string=xbl%3Ainheritsfind=findi=filter=^[^\0]*%24hitlimit=tree=mozilla-central in Firefox' UI, which after all is mostly created using various components or bindings (doesn't matter whether the underlying language is XUL or HTML). -Olli
[Bug 28542] New: [Shadow] Replace node distribution mechanism by the named slot proposal
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28542 Bug ID: 28542 Summary: [Shadow] Replace node distribution mechanism by the named slot proposal Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Proposed here: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0184.html https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
Hi Tab, Thanks for your feedback! A primary motivation for proposing names instead of CSS selectors to control distribution is to enable subclassing. We think it’s important for a subclass to be able to override a base class insertion point. That seems easier to achieve with a name. It lets content insertion points behave like named DOM-valued component parameters that can be overridden by subclasses. To use an example, consider the page template component example at https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates https://github.com/w3c/webcomponents/wiki/Shadow-DOM-Design-Constraints-In-Examples#page-templates. The image shows a page template for a large university web site. In this example, a base page template class defines a header slot. A university department wants to create a subclass of this template that partially populates some of the base class’ slots. In this case, it may want to add the department name to the header slot, then redefine an insertion point with the name that lets an individual page in that department add additional text to the header. The physics department page template subclass could then write something like this (following the proposal's syntax): template div content-slot=“header” Physics Department content slot=“header”/content /div template If an instance of this page then says physics-department-page headerFaculty/header /physics-department-page then the rendered result shows “Physics Department Faculty” in the base template header. This is analogous to what typical OOP languages enable when a subclass overrides a base class property. In such languages, the subclass simply defines a property with the same name as a base class property. The subclass’ property implementation can invoke the base class property implementation if it wants. The model is fairly easy to understand and implement, because the properties are always identified by name. A similar result could theoretically be achieved with CSS selectors, but the approach feels looser and a bit unwieldy, particularly if there are not rigid conventions about how the content select clauses are written. Assuming it were possible to reproject into a base class’ shadow — and that’s not actually possible today — you’d have to write something like: template shadow div class=“header” Physics Department content select=“.header/content /div /shadow /template So that approach could be made to work, but to me at least, feels harder, especially if the base class is using complex CSS selectors. –Jan On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. Oh, interesting. That appears to be a complete non-sequitur, tho, as no one has asked for anything like that. It's *certainly* irrelevant as a response to the text you quoted. On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: I don't think defining a slot based on an attribute value is something we'd like to support. That is *literally* what your proposal already is, except limited to only paying attention to the value of the content-slot attribute. Distributing elements based on the value of a single well scoped attribute versus of an arbitrary attribute is A HUGE difference. Interesting. Why? And why do you think the difference is significant enough to justify such a limitation? You seem to be okay with distributing elements based on the *name* of an arbitrary attribute; can you justify why that is so much better than using the value that you're willing to allow it, but not the other? ~TJ
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
For the comparison, I've re-written the examples by using shadow as function syntax. https://gist.github.com/hayatoito/f2df8e10cb8cc551f80c Can I assume that both have the same power, fundamentally? (Please ignore that power of the CSS selector here ;) If both approaches have the (almost) equivalent power, I guess the technical difficulties to implement these features don't differ so much. If we could implement the new proposal, I think we could implement shadow as function too. On Wed, Apr 22, 2015 at 3:56 PM Dimitri Glazkov dglaz...@google.com wrote: FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan proposal. It reduces the implementation complexity: all of the selector-checking logic in http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria is replaced with (what effectively is) a map lookup. While some loss of flexibility is a cost, I think it's worth considering this trade-off, especially if it is a sticking point for implementers who are looking to reduce the overall cost of Shadow DOM implementation. In fact, if we reach cross-vendor agreement and decide to go with the slot-based approach, we probably should avoid adding extra sugar around element names and attribute values as slot indicators, and instead double down on developing a good imperative API that overcomes the loss of flexibility. :DG
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: I don't think defining a slot based on an attribute value is something we'd like to support. That is *literally* what your proposal already is, except limited to only paying attention to the value of the content-slot attribute. Distributing elements based on the value of a single well scoped attribute versus of an arbitrary attribute is A HUGE difference. [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. What are concrete use cases that require such flexibility? Require is a strong word :) but the case I recently experienced was a panel with a header. It always expects one child for the header and the rest for content. There are several ways to do this, and one would be to select the first child into one distribution point and the rest into another. Another way is to use attributes, classes or a specific set of tag names. The key for me here is that you give the custom element author a choice on how to shape their API. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Our point wasn't so much that it's not achievable. With enough hackeries and techniques, we can. The problem is the developer ergonomics of content element with select attribute with common real world use cases. For example, the above code is a lot more verbose and less intuitive than template content slot=header/content content/content content slot=footer/content /template This is true, but it's a trade off for custom element *authoring* brevity vs custom element *use* brevity (and authoring expressiveness). I'd personally rather optimize for custom element user ergonomics, and give custom element authors the power to make their elements easy and convenient. Continuing this example I would actually make the selectors more complex because we have these nice semantic elements in html5: template content select=header, .header/content content select=:not(footer, .footer)/content content select=footer, .footer/content /template Which is more work for the CE author, but allows this for the user: my-element headerTitle/header p.../p p.../p footer.../footer /my-element Cheers, Justin - R. Niwa
[Bug 28545] New: Declarative syntax for custom elements
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28545 Bug ID: 28545 Summary: Declarative syntax for custom elements Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org See https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html At some point (perhaps post-V1), there should be a convenient declarative syntax that combines script and a template to define a custom element. JavaScript frameworks on top of web components provide something like this. Perhaps with field experience we can make a standardized common syntax. Specifically, such a syntax needs to be compatible with an isolated cross-origin component. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
I don't think defining a slot based on an attribute value is something we'd like to support. On Apr 22, 2015, at 10:21 AM, Justin Fagnani justinfagn...@google.com wrote: Another technique I've seen used is compound selectors, which could be used to migrate from one selector to another while preserving backwards compatibility, or to provide some nice default distributions that are also accessible via a class or attribute (ie, select=header, .header). Could slots have multiple names to support something like this? On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Cheers, Justin - R. Niwa
RE: Proposal for changes to manage Shadow DOM content distribution
I like that the light-side DOM elements must opt-in to being redistributed. While appearing at first like a hindrance, it does ensure that elements can't be arbitrarily re-distributed without their consent. If you imagine allowing redistribution into a cross-origin shadow dom, then it becomes somewhat more important to be a bit more cautious (or at least declarative). I like the cooperative symmetry. I also like the idea of being able to drop the multiple shadow trees requirement. Can this still be accomplished if select= is not used? I'm still grokking the details... From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, April 22, 2015 2:37 PM To: Justin Fagnani Cc: Daniel Freedman; WebApps WG; Edward O'Connor; Jan Miksovsky Subject: Re: Proposal for changes to manage Shadow DOM content distribution On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.commailto:justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.commailto:rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.commailto:justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. What are concrete use cases that require such flexibility? [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Our point wasn't so much that it's not achievable. With enough hackeries and techniques, we can. The problem is the developer ergonomics of content element with select attribute with common real world use cases. For example, the above code is a lot more verbose and less intuitive than template content slot=header/content content/content content slot=footer/content /template - R. Niwa
[Bug 28543] New: Custom elements should call user defined constructor synchronously
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28543 Bug ID: 28543 Summary: Custom elements should call user defined constructor synchronously Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0731.html We should make the custom element's constructor be called synchrnously instead of at the end of the micro-task since that's not consistent with builtin elements and exposes unconstructed elements in some cases; e.g. immediately after cloning or setting innerHTML. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28544] New: Custom elements should not upgrade elements by setting prototype
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544 Bug ID: 28544 Summary: Custom elements should not upgrade elements by setting prototype Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: rn...@webkit.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Discussed here: https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0158.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0083.html We shouldn't support upgrading of existing elements since it leaves the corresponding DOM objects with a wrong identity. This is also not a normal programming model. Even with ES6 modules, we don't create a dummy modules while modules are loading and later automatically replace them under the foot. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. What are concrete use cases that require such flexibility? [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Our point wasn't so much that it's not achievable. With enough hackeries and techniques, we can. The problem is the developer ergonomics of content element with select attribute with common real world use cases. For example, the above code is a lot more verbose and less intuitive than template content slot=header/content content/content content slot=footer/content /template - R. Niwa
[Bug 28546] New: document.registerElement should take a template as an argument
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28546
Bug ID: 28546
Summary: document.registerElement should take a template as an
argument
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: rn...@webkit.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0794.html
Given that many important/natural use cases of custom elements involve shadow
DOM, can we add a flag to auto-create shadow DOM for custom elements?
In particular, can we add template as the third argument to document.register
so that when a custom element is instantiated, the specified template is
automatically closed and inserted into a shadow DOM of the custom element.
e.g. using ES6 class syntax:
template id=myButtonTemplate
buttonHi!/button
/template
script
class MyButton extends HTMLElement {
...
}
document.registerElement('my-button', MyButton, myButtonTemplate);
/script
Given that the shadow DOM specification is relatively stable if we constrain
ourselves to only custom elements (i.e. ignoring all builtin elements), adding
this mechanism will allow us to move the custom elements and shadow DOM
specifications forward without risking to expose the general API for attaching
shadow DOM to the Web.
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: Proposal for changes to manage Shadow DOM content distribution
FWIW, we're working to implement what we call named blocks in Ember.js and believe this proposal aligns very closely to what our users have been asking us to build for them. - Erik On Wednesday, April 22, 2015, Tab Atkins Jr. jackalm...@gmail.com wrote: This is literally reinventing Selectors at this point. The solution to we don't think it's worth implementing *all* of Selectors is to define a subset of supported Selectors, not to define a brand new mechanism that's equivalent to selectors but with a new syntax. On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani justinfagn...@google.com javascript:; wrote: Another technique I've seen used is compound selectors, which could be used to migrate from one selector to another while preserving backwards compatibility, or to provide some nice default distributions that are also accessible via a class or attribute (ie, select=header, .header). Could slots have multiple names to support something like this? On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani justinfagn...@google.com javascript:; wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com javascript:; wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com javascript:; wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. I personally would like to see more power, especially positional selectors. Some components would be better off selecting their first child, rather than requiring a class. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec Point 4 is interesting, because unless I'm missing something (which could be!) it's incorrect. You can create selectors with :not() that exclude the content selectors that come after in document order. I would rewrite the example as: template content select=.header/content content select=:not(.footer)/content content select=.footer/content /template Cheers, Justin - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth helping implementers avoid the complexity of implementing CSS selector matching in this context? I don't think mapping an attribute value to a slot is achievable with a content element with select attribute. content select=[my-attr='the slot value'] No. That's not what I'm talking here. I'm talking about putting the attribute value into the insertion point in [1] [2] [3], not distributing an element based on an attribute value. Oh, interesting. That appears to be a complete non-sequitur, tho, as no one has asked for anything like that. It's *certainly* irrelevant as a response to the text you quoted. On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: I don't think defining a slot based on an attribute value is something we'd like to support. That is *literally* what your proposal already is, except limited to only paying attention to the value of the content-slot attribute. Distributing elements based on the value of a single well scoped attribute versus of an arbitrary attribute is A HUGE difference. Interesting. Why? And why do you think the difference is significant enough to justify such a limitation? You seem to be okay with distributing elements based on the *name* of an arbitrary attribute; can you justify why that is so much better than using the value that you're willing to allow it, but not the other? ~TJ
Re: Proposal for changes to manage Shadow DOM content distribution
FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan proposal. It reduces the implementation complexity: all of the selector-checking logic in http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria is replaced with (what effectively is) a map lookup. While some loss of flexibility is a cost, I think it's worth considering this trade-off, especially if it is a sticking point for implementers who are looking to reduce the overall cost of Shadow DOM implementation. In fact, if we reach cross-vendor agreement and decide to go with the slot-based approach, we probably should avoid adding extra sugar around element names and attribute values as slot indicators, and instead double down on developing a good imperative API that overcomes the loss of flexibility. :DG
