[Bug 28652] New: [Shadow] Need Document.deepActiveElement
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28652 Bug ID: 28652 Summary: [Shadow] Need Document.deepActiveElement Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ko...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org According to the current spec, http://w3c.github.io/webcomponents/spec/shadow/#active-element Document.activeElement returns adjusted element, i.e. when the real focused element is within a shadow tree, it returns the top-most shadow host in the Document treescope. The real focused element can be retrieved by recursively applying .activeElement against shadowRoots on the way, but it may be convenient to have a way to directly retrieve the element from Document. One use case is for accessibility plugins; when a web app is provided as one custom element (e.g. topeka-app at https://polymer-topeka.appspot.com/), Document.activeElement always points to topeka-app, which does not make much sense for accessibility plugins. It may be also necessary to have another type of event than focus, which fires when Document.activeElement changes. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] How about let's go with slots?
On Fri, May 15, 2015 at 4:58 PM, Scott Miles sjmi...@google.com wrote: Polymer really wants Shadow DOM natively, and we think the `slot` proposal can work, so maybe let's avoid blocking on design of an imperative API (which we still should make in the long run). As our entire stack is built on Web Components, the Polymer team is highly motivated to assist browser implementers come to agreement on a Shadow DOM specification. Specifically, as authors of the `webcomponents-js` polyfills, and more than one Shadow DOM shim, we are keenly aware of how difficult Shadow DOM is to simulate without true native support. I believe we are in general agreement with the implementers that an imperative API, especially one that cleanly explains platform behavior, is an ideal end point for Shadow DOM distribution. However, as has been discussed at length, it’s likely that a proper imperative API is blocked on other still-to-mature technologies. For this reason, we would like for the working group to focus on writing the spec for the declarative `slot` proposal [1]. We're happy to participate in the process. [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points It sounds like we are no longer in disagreement on the F. Slots Proposal item from the April 2015 Meeting ( https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting), so we don't need to block it on the C. The imperative distribution API item. Given that all vendors agreed that C can wait until v2, we could just focus on concretizing the slots proposal and then put a lid on Shadow DOM v1. What do you think, folks? :DG
Re: [webcomponents] How about let's go with slots?
On May 18, 2015, at 11:18 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, May 15, 2015 at 4:58 PM, Scott Miles sjmi...@google.com wrote: Polymer really wants Shadow DOM natively, and we think the `slot` proposal can work, so maybe let's avoid blocking on design of an imperative API (which we still should make in the long run). As our entire stack is built on Web Components, the Polymer team is highly motivated to assist browser implementers come to agreement on a Shadow DOM specification. Specifically, as authors of the `webcomponents-js` polyfills, and more than one Shadow DOM shim, we are keenly aware of how difficult Shadow DOM is to simulate without true native support. I believe we are in general agreement with the implementers that an imperative API, especially one that cleanly explains platform behavior, is an ideal end point for Shadow DOM distribution. However, as has been discussed at length, it’s likely that a proper imperative API is blocked on other still-to-mature technologies. For this reason, we would like for the working group to focus on writing the spec for the declarative `slot` proposal [1]. We're happy to participate in the process. [1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points It sounds like we are no longer in disagreement on the F. Slots Proposal item from the April 2015 Meeting (https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting), so we don't need to block it on the C. The imperative distribution API item. Given that all vendors agreed that C can wait until v2, we could just focus on concretizing the slots proposal and then put a lid on Shadow DOM v1. What do you think, folks? We (Apple) support focusing on the slot proposal and deferring the imperative API to v2 or at least not blocking the discussion for the named slots. - R. Niwa
RE: [webcomponents] How about let's go with slots?
From: Dimitri Glazkov [mailto:dglaz...@google.com] What do you think, folks? Was there a writeup that explained how slots did not have the same performance/timing problems as select=? I remember Alex and I were pretty convinced they did at the F2F, but I think you became convinced they did not ... did anyone capture that? My only other contribution is that I sincerely hope we can use tag names instead of the content-slot attribute, i.e. dropdown instead of div content-slot=dropdown. Although slots cannot fully emulate native elements in this manner (e.g. select/optgroup/option), they would at least get syntactically closer, and would in some cases match up (e.g. details/summary). I think it would be a shame to start proliferating markup in the div content-slot=dropdown vein if we eventually want to get to a place where shadow DOM can be used to emulate native elements, which do not use this pattern.
Re: [webcomponents] How about let's go with slots?
I assume you mean to have tag names in addition to content-slot, and not as opposed to content-slot? On Mon, May 18, 2015 at 3:45 PM, Domenic Denicola d...@domenic.me wrote: From: Dimitri Glazkov [mailto:dglaz...@google.com] What do you think, folks? Was there a writeup that explained how slots did not have the same performance/timing problems as select=? I remember Alex and I were pretty convinced they did at the F2F, but I think you became convinced they did not ... did anyone capture that? My only other contribution is that I sincerely hope we can use tag names instead of the content-slot attribute, i.e. dropdown instead of div content-slot=dropdown. Although slots cannot fully emulate native elements in this manner (e.g. select/optgroup/option), they would at least get syntactically closer, and would in some cases match up (e.g. details/summary). I think it would be a shame to start proliferating markup in the div content-slot=dropdown vein if we eventually want to get to a place where shadow DOM can be used to emulate native elements, which do not use this pattern.
Re: [webcomponents] How about let's go with slots?
Pardon my question if this has been discussed elsewhere, but it's not clear from my reading of the slots proposal whether they would be allowed to target elements that are not direct children of the component. I believe the with the `select` attribute this was implicitly required because only compound selectors were supported (i.e. no child or descendent combinators) [1]. Would named slots be able to target elements farther down in the tree? [1] http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:48 PM, Hayato Ito hay...@chromium.org wrote: My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. content select=xxx == slot select=xxx 2. select + content-slot 3. content-slot I was assuming that content-slot is one of required parts in the Multiple Templates proposal and Imperative APIs. Both, Multiple Templates and Imperative APIs are deferred to v2. There is still no convincing proposal about how these are interacted in the future. Those were never conjoined that much. Slots and multiple templates are part of the same proposal, but they are largely independent pieces. As for slots being a prerequisite for imperative APIs, I only remember it being mentioned in the sense that any flavor of declarative API should be implementable by the imperative API. I'd like to see a concrete proposal which explains all together in v2. For v1, I don't see any strong reason to replace the current select. Is the situation where no other vendors are willing to implement the current select not a strong reason? I am not fan of bedding something which is unclear. Could someone summarize the pros and cons of content-slot, compared to select? For me, cons are much bigger than pros in v1. I don't want to miss anything. That's a good request. I'll work on the comparison, including Domenic's request to outline the constant-timeliness. :DG
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 12:06 PM Dimitri Glazkov dglaz...@google.com wrote: On Mon, May 18, 2015 at 6:48 PM, Hayato Ito hay...@chromium.org wrote: My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. content select=xxx == slot select=xxx 2. select + content-slot 3. content-slot I was assuming that content-slot is one of required parts in the Multiple Templates proposal and Imperative APIs. Both, Multiple Templates and Imperative APIs are deferred to v2. There is still no convincing proposal about how these are interacted in the future. Those were never conjoined that much. Slots and multiple templates are part of the same proposal, but they are largely independent pieces. As for slots being a prerequisite for imperative APIs, I only remember it being mentioned in the sense that any flavor of declarative API should be implementable by the imperative API. I'd like to see a concrete proposal which explains all together in v2. For v1, I don't see any strong reason to replace the current select. Is the situation where no other vendors are willing to implement the current select not a strong reason? Agreed. I am not fan of bedding something which is unclear. Could someone summarize the pros and cons of content-slot, compared to select? For me, cons are much bigger than pros in v1. I don't want to miss anything. That's a good request. I'll work on the comparison, including Domenic's request to outline the constant-timeliness. Thank you! I'm afraid that we don't have enough discussion about the pros and cons between select nodes using a selector and select nodes by a fixed id using attribute. I'd like to make sure that everyone understand the pros and cons for both as a separated topic from Imperative APIs and Multiple Templates so that we can do the best judgement. :DG
Re: [webcomponents] How about let's go with slots?
I think we can learn something from existing programming languages. For example, I like Python's way to handle function's parameters. That enables us to select: - By Position - By Keyword - *args (Grab unused positional arguments) - *kwds* (Grap unused keyword arguments) I think this is over-engineering for us. But this might be interesting to us as a reference. On Tue, May 19, 2015 at 12:54 PM Hayato Ito hay...@chromium.org wrote: I think the problem we have to solve is: Problem: Given that we have a list of nodes, what's the best way to select nodes from the list? We can give any *hint* to the nodes beforehand if we wish. Is this a correct problem statement? I think we don't have to limit our answers to this problem by the current select and the content-slot. Any better ideas can be acceptable, I think. The hint we can use is: - tag name - id attribute - class attribute - any other attributes. (Okay to have a dedicated attribute, such as 'content-slot') - The position of the node in the list - Other status, such as :focused (in CSS's terminology) - Anything else? I think the current content select has been there in the spec for a long time. No one hasn't spent much time on thinking a replacement of it until recently. I hope that this discussion might be a good opportunity to get an agreement between us. On Tue, May 19, 2015 at 12:23 PM Dimitri Glazkov dglaz...@google.com wrote: On Mon, May 18, 2015 at 8:18 PM, Hayato Ito hay...@chromium.org wrote: Thank you! I'm afraid that we don't have enough discussion about the pros and cons between select nodes using a selector and select nodes by a fixed id using attribute. BTW, here's one bit of research I'd done: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md :DG
Re: [webcomponents] How about let's go with slots?
I think the problem we have to solve is: Problem: Given that we have a list of nodes, what's the best way to select nodes from the list? We can give any *hint* to the nodes beforehand if we wish. Is this a correct problem statement? I think we don't have to limit our answers to this problem by the current select and the content-slot. Any better ideas can be acceptable, I think. The hint we can use is: - tag name - id attribute - class attribute - any other attributes. (Okay to have a dedicated attribute, such as 'content-slot') - The position of the node in the list - Other status, such as :focused (in CSS's terminology) - Anything else? I think the current content select has been there in the spec for a long time. No one hasn't spent much time on thinking a replacement of it until recently. I hope that this discussion might be a good opportunity to get an agreement between us. On Tue, May 19, 2015 at 12:23 PM Dimitri Glazkov dglaz...@google.com wrote: On Mon, May 18, 2015 at 8:18 PM, Hayato Ito hay...@chromium.org wrote: Thank you! I'm afraid that we don't have enough discussion about the pros and cons between select nodes using a selector and select nodes by a fixed id using attribute. BTW, here's one bit of research I'd done: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md :DG
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 8:18 PM, Hayato Ito hay...@chromium.org wrote: Thank you! I'm afraid that we don't have enough discussion about the pros and cons between select nodes using a selector and select nodes by a fixed id using attribute. BTW, here's one bit of research I'd done: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md :DG
Re: [webcomponents] How about let's go with slots?
I'd like this API to stay simple for v1 and support only named slots and not tag names. I believe we can explain what details does with the imperative API in v2. On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani justinfagn...@google.com wrote: On Mon, May 18, 2015 at 4:58 PM, Philip Walton phi...@philipwalton.com wrote: Pardon my question if this has been discussed elsewhere, but it's not clear from my reading of the slots proposal whether they would be allowed to target elements that are not direct children of the component. I believe the with the `select` attribute this was implicitly required because only compound selectors were supported (i.e. no child or descendent combinators) [1]. I think the actually issue is that you might have fights over who gets to redistribute an element. Given my-el-1 my-el-2 div content-slot=foo/div /my-el-2 /my-el-1 If both my-el-1 and my-el-2 have foo slots, who wins? What if the winner by whatever rules adds a clashing slot name in a future update? I mentioned in this in Imperative API thread, but I think the least surprising way forward for distributing non-children is to allow nodes to cooperate on distribution, so a element could send its distributed nodes to an ancestor: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html Would named slots be able to target elements farther down in the tree? [1] http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select
[admin] Getting notification about WebApp's web-platform-tests activity?
Hi All, Dom has a tool that could be used to notify one of WebApps' mail lists when a wg-webapps label is applied to something (f.ex an Issue or PR) in the web-platform-tests repo. Is this something we want to use? If yes, which list? public-webapps-github seems like the closest match but I public-webapps could also be used (and if that resulted in too much e-mail we could revisit the list). (I suppose other options would be to resurrect public-webapps-testsuite or create a new list.) WDYT? -Thanks, AB Forwarded Message Subject:Per-WG notification of pull requests Resent-Date:Mon, 18 May 2015 14:43:50 + Resent-From:public-test-in...@w3.org Date: Mon, 18 May 2015 16:43:01 +0200 From: Dominique Hazael-Massieux d...@w3.org To: public-test-in...@w3.org Hi, I maintain a tool that some groups use to mirror part of their github activity to a mailing list: https://github.com/dontcallmedom/github-notify-ml/ I've recently tweaked that tool to make it capable of filtering based on label, and furthered tweaked this today to make it possible to be notified when a given issue or pull request gets labeled with a particular label. When applied to web-platform-tests, this makes it possible to notify a mailing list when a given pull request gets automatically labeled with its WG label. I've applied this to the WebRTC Working Group: https://lists.w3.org/Archives/Public/public-webrtc-testsuite/2015May/0001.html If you belong to other groups who would like a similar set up, please get in touch. I'm also interested in ideas as to where that option should be documented. Dom
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola d...@domenic.me wrote: In case it wasn't clear, named slots vs. tag names is purely a bikeshed color (but an important one, in the syntax is UI sense). None of the details of how the proposal works change at all. They're not equivalent, because any element can have the right content-slot value, but with tag names, only one (or maybe N) names would be supported. If you already knew that but still prefer content-slot attributes, then I guess we just disagree. But it wasn't clear. I greatly prefer select, but this is a compromise to enable progress. From: Elliott Sprehn Sent: Monday, May 18, 21:03 Subject: Re: [webcomponents] How about let's go with slots? To: Justin Fagnani Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov, Scott Miles, Ryosuke Niwa, Edward O'Connor, Anne van Kesteren, Travis Leithead, Maciej Stachowiak, Arron Eicholz, Alex Russell, public-webapps I'd like this API to stay simple for v1 and support only named slots and not tag names. I believe we can explain what details does with the imperative API in v2. On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani justinfagn...@google.com wrote: On Mon, May 18, 2015 at 4:58 PM, Philip Walton phi...@philipwalton.com wrote: Pardon my question if this has been discussed elsewhere, but it's not clear from my reading of the slots proposal whether they would be allowed to target elements that are not direct children of the component. I believe the with the `select` attribute this was implicitly required because only compound selectors were supported (i.e. no child or descendent combinators) [1]. I think the actually issue is that you might have fights over who gets to redistribute an element. Given my-el-1 my-el-2 div content-slot=foo/div /my-el-2 /my-el-1 If both my-el-1 and my-el-2 have foo slots, who wins? What if the winner by whatever rules adds a clashing slot name in a future update? I mentioned in this in Imperative API thread, but I think the least surprising way forward for distributing non-children is to allow nodes to cooperate on distribution, so a element could send its distributed nodes to an ancestor: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html Would named slots be able to target elements farther down in the tree? [1] http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:34 PM, Domenic Denicola d...@domenic.me wrote: From: Justin Fagnani [mailto:justinfagn...@google.com] They're not equivalent, because any element can have the right content-slot value, but with tag names, only one (or maybe N) names would be supported. Hmm, I don't understand, and fear we might be talking past each other. Can you give an example where content-slot works but tag names do not? For example https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points gets translated from combo-box icon/icon dropdown … Choices go here … /dropdown /combo-box Your stated sentence doesn't make much sense to me; you can have multiple elements with the same tag name. Literally, just take any example you can write x content-slot=y ... /x and replace those with y and /y. Given the widget ui-collapsible that expects a ui-collapsible-header in the content model, with slots I can write: ui-collapsible my-header-v1 slot=ui-collapsible-header ... /... /ui-collapsible ui-collapsible my-header-v2 slot=ui-collapsible-header ... /... /ui-collapsible within the same application. It also means the library can ship with an implementation of the header widget, but you can replace it with your own. This is identical to the common usage today in polymer apps where you annotate your own element with classes. There's no restriction on the type of the input. With tag names I must write: ui-collapsible ui-collapsible-header ... /... /ui-collapsible which means I can't replace the header with any widget I choose, I must use that custom element. This is identical to using a tag name with content select and it restricts the type of input. There's no way to have both an implementation in the library and one in your application, or multiple implementations. - E
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 4:58 PM, Philip Walton phi...@philipwalton.com wrote: Pardon my question if this has been discussed elsewhere, but it's not clear from my reading of the slots proposal whether they would be allowed to target elements that are not direct children of the component. I believe the with the `select` attribute this was implicitly required because only compound selectors were supported (i.e. no child or descendent combinators) [1]. I think the actually issue is that you might have fights over who gets to redistribute an element. Given my-el-1 my-el-2 div content-slot=foo/div /my-el-2 /my-el-1 If both my-el-1 and my-el-2 have foo slots, who wins? What if the winner by whatever rules adds a clashing slot name in a future update? I mentioned in this in Imperative API thread, but I think the least surprising way forward for distributing non-children is to allow nodes to cooperate on distribution, so a element could send its distributed nodes to an ancestor: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html Would named slots be able to target elements farther down in the tree? [1] http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select
Re: [webcomponents] How about let's go with slots?
My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. content select=xxx == slot select=xxx 2. select + content-slot 3. content-slot I was assuming that content-slot is one of required parts in the Multiple Templates proposal and Imperative APIs. Both, Multiple Templates and Imperative APIs are deferred to v2. There is still no convincing proposal about how these are interacted in the future. I'd like to see a concrete proposal which explains all together in v2. For v1, I don't see any strong reason to replace the current select. I am not fan of bedding something which is unclear. Could someone summarize the pros and cons of content-slot, compared to select? For me, cons are much bigger than pros in v1. I don't want to miss anything. On Tue, May 19, 2015 at 10:37 AM Domenic Denicola d...@domenic.me wrote: From: Justin Fagnani [mailto:justinfagn...@google.com] They're not equivalent, because any element can have the right content-slot value, but with tag names, only one (or maybe N) names would be supported. Hmm, I don't understand, and fear we might be talking past each other. Can you give an example where content-slot works but tag names do not? For example https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points gets translated from combo-box icon/icon dropdown … Choices go here … /dropdown /combo-box Your stated sentence doesn't make much sense to me; you can have multiple elements with the same tag name. Literally, just take any example you can write x content-slot=y ... /x and replace those with y and /y.
RE: [webcomponents] How about let's go with slots?
I was thinking opposed. I don’t see any reason to invent two ways to do the same thing. If we do support content-slot then I think we should allow detailsdiv content-slot=summary.../div.../details and a few others.
Re: [webcomponents] How about let's go with slots?
In case it wasn't clear, named slots vs. tag names is purely a bikeshed color (but an important one, in the syntax is UI sense). None of the details of how the proposal works change at all. If you already knew that but still prefer content-slot attributes, then I guess we just disagree. But it wasn't clear. From: Elliott Sprehn Sent: Monday, May 18, 21:03 Subject: Re: [webcomponents] How about let's go with slots? To: Justin Fagnani Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov, Scott Miles, Ryosuke Niwa, Edward O'Connor, Anne van Kesteren, Travis Leithead, Maciej Stachowiak, Arron Eicholz, Alex Russell, public-webapps I'd like this API to stay simple for v1 and support only named slots and not tag names. I believe we can explain what details does with the imperative API in v2. On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani justinfagn...@google.commailto:justinfagn...@google.com wrote: On Mon, May 18, 2015 at 4:58 PM, Philip Walton phi...@philipwalton.commailto:phi...@philipwalton.com wrote: Pardon my question if this has been discussed elsewhere, but it's not clear from my reading of the slots proposal whether they would be allowed to target elements that are not direct children of the component. I believe the with the `select` attribute this was implicitly required because only compound selectors were supported (i.e. no child or descendent combinators) [1]. I think the actually issue is that you might have fights over who gets to redistribute an element. Given my-el-1 my-el-2 div content-slot=foo/div /my-el-2 /my-el-1 If both my-el-1 and my-el-2 have foo slots, who wins? What if the winner by whatever rules adds a clashing slot name in a future update? I mentioned in this in Imperative API thread, but I think the least surprising way forward for distributing non-children is to allow nodes to cooperate on distribution, so a element could send its distributed nodes to an ancestor: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0325.html Would named slots be able to target elements farther down in the tree? [1] http://w3c.github.io/webcomponents/spec/shadow/#dfn-content-element-select
Re: [webcomponents] How about let's go with slots?
Like we pointed out in the previous thread, adding enough special cases to slots leads to select. At this point we're much more interested in agreeing on something rather than nothing. On Mon, May 18, 2015 at 3:58 PM, Domenic Denicola d...@domenic.me wrote: I was thinking opposed. I don’t see any reason to invent two ways to do the same thing. If we do support content-slot then I think we should allow detailsdiv content-slot=summary.../div.../details and a few others.
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:24 PM, Justin Fagnani justinfagn...@google.com wrote: On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola d...@domenic.me wrote: In case it wasn't clear, named slots vs. tag names is purely a bikeshed color (but an important one, in the syntax is UI sense). None of the details of how the proposal works change at all. They're not equivalent, because any element can have the right content-slot value, but with tag names, only one (or maybe N) names would be supported. Indeed they're not the same, and supporting both requires coming up with a syntax to allow both when doing reprojection or selection which rapidly converges on @select. We should only support a single selection type for v1, either tag names or content-slot. If you already knew that but still prefer content-slot attributes, then I guess we just disagree. But it wasn't clear. I'm saying we should pick a single kind, not both. Our customers should decide which one. (btw the platform doesn't use dashes in attribute names, so this is either slot or contentslot when we add it, I'd suggest slot). - E
