Re: [webcomponents] How about let's go with slots?

2015-05-22 Thread Ryosuke Niwa
On May 21, 2015, at 11:33 PM, Wilson Page wilsonp...@me.com 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

Re: [webcomponents] How about let's go with slots?

2015-05-22 Thread Wilson Page
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 dglaz...@google.com wrote: Given that all vendors agreed

Re: [webcomponents] How about let's go with slots?

2015-05-22 Thread Wilson Page
On Fri, May 22, 2015 at 7:47 AM, Ryosuke Niwa rn...@apple.com wrote: On May 21, 2015, at 11:33 PM, Wilson Page wilsonp...@me.com 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

Re: [webcomponents] How about let's go with slots?

2015-05-21 Thread Dimitri Glazkov
about let's go with slots? On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov dglaz...@google.com 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

RE: [webcomponents] How about let's go with slots?

2015-05-21 Thread 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 dglaz...@google.com wrote: Given that all vendors agreed that C can wait until v2, we could just focus on concretizing the slots proposal

Re: [webcomponents] How about let's go with slots?

2015-05-20 Thread Anne van Kesteren
On Tue, May 19, 2015 at 3:18 AM, Dimitri Glazkov dglaz...@google.com 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

Re: [webcomponents] How about let's go with slots?

2015-05-19 Thread Philip Walton
On Mon, May 18, 2015 at 8:54 PM, Hayato Ito hay...@chromium.org 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

RE: [webcomponents] How about let's go with slots?

2015-05-19 Thread Domenic Denicola
From: Elliott Sprehn [mailto:espr...@chromium.org] 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

Re: [webcomponents] How about let's go with slots?

2015-05-19 Thread Elliott Sprehn
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me wrote: From: Elliott Sprehn [mailto:espr...@chromium.org] 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

Re: [webcomponents] How about let's go with slots?

2015-05-19 Thread Dimitri Glazkov
On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me 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. summary or li or option) act as dumb containers. This was

RE: [webcomponents] How about let's go with slots?

2015-05-19 Thread Domenic Denicola
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Dimitri Glazkov
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Ryosuke Niwa
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

RE: [webcomponents] How about let's go with slots?

2015-05-18 Thread Domenic Denicola
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Daniel Freedman
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Philip Walton
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Dimitri Glazkov
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
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.

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Dimitri Glazkov
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:

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Elliott Sprehn
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Justin Fagnani
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Elliott Sprehn
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Justin Fagnani
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
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.

RE: [webcomponents] How about let's go with slots?

2015-05-18 Thread Domenic Denicola
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?

2015-05-18 Thread Domenic Denicola
. 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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Justin Fagnani
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

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Elliott Sprehn
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

[webcomponents] How about let's go with slots?

2015-05-15 Thread Scott Miles
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

Re: [webcomponents] How about let's go with slots?

2015-05-15 Thread Dimitri Glazkov
On Fri, May 15, 2015 at 5:45 PM, Scott Miles sjmi...@google.com 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

Re: [webcomponents] How about let's go with slots?

2015-05-15 Thread Scott Miles
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

Re: [webcomponents] How about let's go with slots?

2015-05-15 Thread Steve Orvell
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