Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote: 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 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html Apologies, I'd misread [1] and didn't realize it really was talking about projecting the value of an attribute into the content of a slot. (Though I'm confused by the vehemence of your denial here, given that in [2] you said you could imagine that such a feature could be easily added.) What I meant is that we don't want a declarative syntax to filling a slot based with elements based on attribute values of those elements. I'm less concerned about distributing the value of an attribute to a slot based on its attribute name. Regardless, all of this is moot for foreseeable future given we just reached a consensus to focus on an imperative API for v1 on today's F2F. - R. Niwa
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. 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 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. I'm not really seeing the complexity. In particular, I'm not seeing why content-slot/slot is easier than class/select. For all simple cases (class, attribute, tagname) it seems pretty much identical. More complex selectors, like :nth-child(), might make it a bit more difficult (as you have to match your markup to what the superclass is expecting), but that's probably normally okay, and in problematic cases is just because the superclass is being too clever. On the other hand, requiring content-slot in order to place things in anything but the default slot means you have to ugly up your markup quite a bit. It makes current UA-shadow-using elements, such as details, impossible to duplicate, and makes all uses of shadow DOM uglier and more verbose. For example, I think tagname is a very common thing to select on. details uses it, your fingers automatically used it before you corrected your example, a number of Polymer examples use it, etc. Requiring the use of header content-slot=header is adding 20 characters to the element. A shadow-heavy page, such as some of the Polymer examples, would have a relatively large amount of its page weight being paid to this attribute scattered all over the place. As Justin said, this seems to be extremely over-engineering towards make subclass-and-reproject slightly more reliable, to the detriment of every other case. Subclass-and-reproject works just fine with select='' unless the superclass's selector is too complex/specialized to easily satisfy in your subclass's preferred markup; in the common case of a tagname, class name, or attribute name, the two are identical. In return, content-slot makes the common case (just project into some shadow) more verbose for the user, and make some cases, such as the date-range-combo-box illustrated by Daniel earlier in the thread https://gist.github.com/azakus/676590eb4d5b07b94428 impossible. Overall, this feels like an over-optimization for implementation complexity (matching content-slot to slot is easier than matching an element to a selector) without fully considering the cost to the author and user, which is a strong inversion of the priority of constituencies. ~TJ
Re: Proposal for changes to manage Shadow DOM content distribution
On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote: 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 [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html Apologies, I'd misread [1] and didn't realize it really was talking about projecting the value of an attribute into the content of a slot. (Though I'm confused by the vehemence of your denial here, given that in [2] you said you could imagine that such a feature could be easily added.) ~TJ
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
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
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
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
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
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
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
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
Re: Proposal for changes to manage Shadow DOM content distribution
On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 Maybe there could be something like a simple routing scheme for these cases? https://gist.github.com/dglazkov/7d6acd4c205a58054a7c :DG
Re: Proposal for changes to manage Shadow DOM content distribution
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?
Re: Proposal for changes to manage Shadow DOM content distribution
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 mailto: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 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 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html 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
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 https://gist.github.com/azakus/676590eb4d5b07b94428 !-- instance -- date-range-combo-box input type=date content-slot=start!-- (1) -- input type=date content-slot=end!-- (2) -- /date-range-combo-box !— implementation of date-range-combo-box -- template shadow date-combo-box!-- (3) -- !-- How can input[content-slot=start] end up in the content slot=inputElement in the date-combo-box ? -- content slot=start/content /date-combo-box date-combo-box!-- (4) -- content slot=end/content /date-combo-box /shadow /template Am I right in assuming that you want to re-distribute (1) into (3)'s and (2) into (4)'s inputElements? If so, I'd imagine one possible syntax is as follows: template shadow date-combo-box!-- (3) -- content slot=start content-slot=inputElement/content /date-combo-box date-combo-box!-- (4) -- content slot=end content-slot=inputElement/content /date-combo-box /shadow /template Here, the content elements are both creating slots and fulfilling slots. - R. Niwa On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com mailto: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 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 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
Re: Proposal for changes to manage Shadow DOM content distribution
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]. [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 - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 Thanks! On Tue, Apr 21, 2015 at 8:19 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
Re: Proposal for changes to manage Shadow DOM content distribution
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? Cheers, Justin On Tue, Apr 21, 2015 at 9:57 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 !-- instance -- date-range-combo-box input type=date content-slot=start!-- (1) -- input type=date content-slot=end!-- (2) -- /date-range-combo-box !— implementation of date-range-combo-box -- template shadow date-combo-box!-- (3) -- !-- How can input[content-slot=start] end up in the content slot=inputElement in the date-combo-box ? -- content slot=start/content /date-combo-box date-combo-box!-- (4) -- content slot=end/content /date-combo-box /shadow /template Am I right in assuming that you want to re-distribute (1) into (3)'s and (2) into (4)'s inputElements? If so, I'd imagine one possible syntax is as follows: template shadow date-combo-box!-- (3) -- content slot=start content-slot=inputElement/content /date-combo-box date-combo-box!-- (4) -- content slot=end content-slot=inputElement/content /date-combo-box /shadow /template Here, the content elements are both creating slots and fulfilling slots. - R. Niwa On Tue, Apr 21, 2015 at 8:19 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
