Re: [webcomponents] How about let's go with slots?
On Fri, May 22, 2015 at 7:47 AM, Ryosuke Niwa wrote: > > > On May 21, 2015, at 11:33 PM, Wilson Page wrote: > > > > From experience building components for Firefox OS I think the 'default > slot' pattern will fulfill most of our use-cases. This means we won't have > to burden our component users by requiring them to add `slot="foo"` all > over the place. > > Could you clarify what you're referring to by "'default slot' pattern"? > https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md#definitions >> 'Default slot' > > Is it fair to say that if this declarative API lands in V1, it's > unlikely we'll see imperative API in V2? Have we not exhausted all the > options? > > At F2F, basically all browser vendors have agreed that we eventually want > the imperative API, and we (Apple) are certainly interested in the > imperative API being included in v2. > Wasn't there talk that declarative before imperative might make imperative more difficult/impossible? > - R. Niwa > >
Re: [webcomponents] How about let's go with slots?
> On May 21, 2015, at 11:33 PM, Wilson Page wrote: > > From experience building components for Firefox OS I think the 'default slot' > pattern will fulfill most of our use-cases. This means we won't have to > burden our component users by requiring them to add `slot="foo"` all over the > place. Could you clarify what you're referring to by "'default slot' pattern"? > Is it fair to say that if this declarative API lands in V1, it's unlikely > we'll see imperative API in V2? Have we not exhausted all the options? At F2F, basically all browser vendors have agreed that we eventually want the imperative API, and we (Apple) are certainly interested in the imperative API being included in v2. - R. Niwa
Re: [webcomponents] How about let's go with slots?
>From experience building components for Firefox OS I think the 'default slot' pattern will fulfill most of our use-cases. This means we won't have to burden our component users by requiring them to add `slot="foo"` all over the place. Is it fair to say that if this declarative API lands in V1, it's unlikely we'll see imperative API in V2? Have we not exhausted all the options? On Thu, May 21, 2015 at 6:45 PM, Dimitri Glazkov wrote: > > > On Thu, May 21, 2015 at 10:22 AM, Travis Leithead < > travis.leith...@microsoft.com> wrote: > >> This works for me too. >> >> And I like the proposed new bikeshed-ed names Anne suggests below. >> > > SG. Started a proposal stub here: > https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md > > :DG< > > >> >> -Original Message- >> From: Anne van Kesteren [mailto:ann...@annevk.nl] >> Sent: Wednesday, May 20, 2015 9:10 PM >> To: Dimitri Glazkov >> Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej >> Stachowiak; Arron Eicholz; public-webapps >> Subject: Re: [webcomponents] How about let's go with slots? >> >> On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov >> wrote: >> > 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? >> >> This probably works for Mozilla. It would be good to see the proposed >> processing model and its implications for an eventual imperative API. >> It's somewhat troubling we don't agree on synchronous vs >> when-layout-or-event-dispatch-happens. >> >> Also, I suggest we bikeshed the markup in the direction of >> slot=some-slot-name and rather than >> content-slot=some-slot-name and . >> >> >> -- >> https://annevankesteren.nl/ >> > >
Re: [webcomponents] How about let's go with slots?
On Thu, May 21, 2015 at 10:22 AM, Travis Leithead < travis.leith...@microsoft.com> wrote: > This works for me too. > > And I like the proposed new bikeshed-ed names Anne suggests below. > SG. Started a proposal stub here: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Slots-Proposal.md :DG< > > -Original Message- > From: Anne van Kesteren [mailto:ann...@annevk.nl] > Sent: Wednesday, May 20, 2015 9:10 PM > To: Dimitri Glazkov > Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej > Stachowiak; Arron Eicholz; public-webapps > Subject: Re: [webcomponents] How about let's go with slots? > > On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov > wrote: > > 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? > > This probably works for Mozilla. It would be good to see the proposed > processing model and its implications for an eventual imperative API. > It's somewhat troubling we don't agree on synchronous vs > when-layout-or-event-dispatch-happens. > > Also, I suggest we bikeshed the markup in the direction of > slot=some-slot-name and rather than > content-slot=some-slot-name and . > > > -- > https://annevankesteren.nl/ >
RE: [webcomponents] How about let's go with slots?
This works for me too. And I like the proposed new bikeshed-ed names Anne suggests below. -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: Wednesday, May 20, 2015 9:10 PM To: Dimitri Glazkov Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej Stachowiak; Arron Eicholz; public-webapps Subject: Re: [webcomponents] How about let's go with slots? On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov wrote: > 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? This probably works for Mozilla. It would be good to see the proposed processing model and its implications for an eventual imperative API. It's somewhat troubling we don't agree on synchronous vs when-layout-or-event-dispatch-happens. Also, I suggest we bikeshed the markup in the direction of slot=some-slot-name and rather than content-slot=some-slot-name and . -- https://annevankesteren.nl/
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov wrote: > 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? This probably works for Mozilla. It would be good to see the proposed processing model and its implications for an eventual imperative API. It's somewhat troubling we don't agree on synchronous vs when-layout-or-event-dispatch-happens. Also, I suggest we bikeshed the markup in the direction of slot=some-slot-name and rather than content-slot=some-slot-name and . -- https://annevankesteren.nl/
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola wrote: > From: Elliott Sprehn [mailto:espr...@chromium.org] > > > Given the widget that expects a ui-collapsible-header > in the content model, with slots I can write: > > > > > > ... > > > > > > > > ... > > > > > > 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. > > I see. Thanks for explaining. > > I think this model you cite Polymer using is different from what HTML > normally does, which is why it was confusing to me. In HTML the "insertion > point tags" (e.g. or or ) act as dumb containers. > This was reinforced by the examples in the proposal, which use content-slot=""> with the div being a clear dumb container. You cannot > replace them with your own choice of container and have things still work. > is actually just a layout mode, you can make anything a list item by doing display: list-item. There's no special content model for . and are examples of selection based on tag name. In general these "dumb containers" have proven harmful though because they insert extra boxes around your content and are not configurable which are annoying for authors. They're the reason we keep coming back to trying to figure out how to customize instead of just letting you replace it with your own widget we tell to layout/paint at a specific size like other platforms would. ex. Authors don't like the disclosure triangle that inserts and want to change it. They'd much rather do and do whatever they want instead. - E
RE: [webcomponents] How about let's go with slots?
From: Dimitri Glazkov [mailto:dglaz...@google.com] > Not sure what you mean by "Polymer model". I was referring to Elliot's "This is identical to the common usage today in polymer apps where you annotate your own element with classes." > When we have custom elements, the assumption of dumb containers simply goes > out of the window. I don't think it has to, as I showed in my message.
Re: [webcomponents] How about let's go with slots?
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola wrote: > > I think this model you cite Polymer using is different from what HTML > normally does, which is why it was confusing to me. In HTML the "insertion > point tags" (e.g. or or ) act as dumb containers. > This was reinforced by the examples in the proposal, which use content-slot=""> with the div being a clear dumb container. You cannot > replace them with your own choice of container and have things still work. > Not sure what you mean by "Polymer model". When we have custom elements, the assumption of dumb containers simply goes out of the window. :DG<
RE: [webcomponents] How about let's go with slots?
From: Elliott Sprehn [mailto:espr...@chromium.org] > Given the widget that expects a ui-collapsible-header in the > content model, with slots I can write: > > > ... > > > > ... > > > 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. I see. Thanks for explaining. I think this model you cite Polymer using is different from what HTML normally does, which is why it was confusing to me. In HTML the "insertion point tags" (e.g. or or ) act as dumb containers. This was reinforced by the examples in the proposal, which use with the div being a clear dumb container. You cannot replace them with your own choice of container and have things still work. As such, I think it would make more sense to write if we were trying to match HTML. This would be easier to refactor later, e.g. to Header for Foo https://example.com/help-for-foo";>(?) However, I understand how this departs from the Polymer/select="" model now. Polymer/select="" allows anything to stand in and be distributed to the appropriate destination location, whereas HTML only allows certain tag names. I am not sure which the original proposal from Jan, Ryosuke, and Ted *intended*, although I agree that as presented it leans toward Polymer/select="".
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 8:54 PM, Hayato Ito wrote: > > 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? > Another potential hint is element class/type/instanceof. I can see a situation where I'd want to "select" any element that is an `instanceof` HTMLButtonElement. Or if a third-party library creates an element that "selects" , it may want to allow the selection of subclasses of that element but not other arbitrary elements.
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 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 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 > wrote: > >> On Mon, May 18, 2015 at 8:18 PM, Hayato Ito 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 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 wrote: > On Mon, May 18, 2015 at 8:18 PM, Hayato Ito 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 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 Tue, May 19, 2015 at 12:06 PM Dimitri Glazkov wrote: > On Mon, May 18, 2015 at 6:48 PM, Hayato Ito wrote: > >> My preference in v1: >> >> 1. select (strongly preferred). okay to rename it if we have a better >> name. e.g. ==> >> 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?
On Mon, May 18, 2015 at 6:48 PM, Hayato Ito wrote: > My preference in v1: > > 1. select (strongly preferred). okay to rename it if we have a better > name. e.g. ==> > 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 Mon, May 18, 2015 at 6:34 PM, Domenic Denicola 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 > > > > > … Choices go here … > > > > 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 ... and replace those with and . > Given the widget that expects a ui-collapsible-header in the content model, with slots I can write: ... ... 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: ... 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 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?
My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. ==> 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 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 > > > > > … Choices go here … > > > > 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 ... and replace those with and . > >
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:24 PM, Justin Fagnani wrote: > > > On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola 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
RE: [webcomponents] How about let's go with slots?
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 … Choices go here … 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 ... and replace those with and .
Re: [webcomponents] How about let's go with slots?
On Mon, May 18, 2015 at 6:13 PM, Domenic Denicola 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 does with the > imperative API in v2. > > On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani > wrote: > > On Mon, May 18, 2015 at 4:58 PM, Philip Walton > 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 > > > > > > > > > > > > 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?
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 does with the imperative API in v2. On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani mailto:justinfagn...@google.com>> wrote: On Mon, May 18, 2015 at 4:58 PM, Philip Walton mailto: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 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?
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 does with the imperative API in v2. On Mon, May 18, 2015 at 5:11 PM, Justin Fagnani wrote: > > > On Mon, May 18, 2015 at 4:58 PM, Philip Walton > 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 > > > > > > > > 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 4:58 PM, Philip Walton 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 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?
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?
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 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 content-slot="summary">.. and a few others. > >
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 .. and a few others.
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 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. instead of content-slot="dropdown">. Although slots cannot fully emulate native > elements in this manner (e.g. //), they would at > least get syntactically closer, and would in some cases match up (e.g. > /). I think it would be a shame to start proliferating > markup in the 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?
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. instead of . Although slots cannot fully emulate native elements in this manner (e.g. //), they would at least get syntactically closer, and would in some cases match up (e.g. /). I think it would be a shame to start proliferating markup in the 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?
> On May 18, 2015, at 11:18 AM, Dimitri Glazkov wrote: > > On Fri, May 15, 2015 at 4:58 PM, Scott Miles 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?
On Fri, May 15, 2015 at 4:58 PM, Scott Miles 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?
With respect to Dimitri's *unpacking* notion, we think it can work. In most cases today the redistribution tree is not large; however, if there were a lot of final destination points in that tree, unpacking would be cumbersome because you need to define a slot at every level for every final destination point from that level's perspective. We'd like the working group to explore some short hand syntax for this scenario. The one hypothetical use case we came up with that would be problematic for *unpacking* is dynamic creation of insertion points. This would require dynamic unpacking and that seems pretty ugly since you'd have to break encapsulation to do this. However, the use cases that one can imagine for dynamic insertion points would be better solved by an imperative distribution api anyway and are generally advanced enough that v2 seems ok for them. On Fri, May 15, 2015 at 5:55 PM, Dimitri Glazkov wrote: > > > On Fri, May 15, 2015 at 5:45 PM, Scott Miles wrote: > >> >> How does it work for redistribution >> >> We've done some investigation and think it can work. >> > > Note that distributions work just fine with slots. The only thing that > doesn't is partial redistributions, and we haven't been able to find a > scenario that's a blocker: > https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md > > Please, if you can think of one, let's look at it. > > :DG< >
Re: [webcomponents] How about let's go with slots?
On Fri, May 15, 2015 at 5:45 PM, Scott Miles wrote: > >> How does it work for redistribution > > We've done some investigation and think it can work. > Note that distributions work just fine with slots. The only thing that doesn't is partial redistributions, and we haven't been able to find a scenario that's a blocker: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md Please, if you can think of one, let's look at it. :DG<
Re: [webcomponents] How about let's go with slots?
>> How does it work for redistribution We've done some investigation and think it can work. >> and the other downsides that have been brought up? We have to tackle these deliberately, but mostly we think there is room for consensus. >> You're okay with the "required to plaster content-slot='foo' all over your page" requirement? Me personally, this is the least palatable part of the `slot` proposal. But if after all the discussion is over, if the consensus is that the pros outweigh the cons, then yeah it's not blocking from my perspective. For sure, I'd at least like a shorter attribute name than `content-slot`, but seems like that bikeshedding can wait until later. ;) Scott On Fri, May 15, 2015 at 5:24 PM, Tab Atkins Jr. wrote: > On Fri, May 15, 2015 at 4:58 PM, Scott Miles 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). > > How does it work for redistribution, and the other downsides that have > been brought up? Are you saying that those cases just aren't > important enough to be blocking at the moment? > > You're okay with the "required to plaster content-slot='foo' all over > your page" requirement? > > ~TJ >
Re: [webcomponents] How about let's go with slots?
On Fri, May 15, 2015 at 4:58 PM, Scott Miles 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). How does it work for redistribution, and the other downsides that have been brought up? Are you saying that those cases just aren't important enough to be blocking at the moment? You're okay with the "required to plaster content-slot='foo' all over your page" requirement? ~TJ
[webcomponents] How about let's go with slots?
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
