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
> 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
> plac
; -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-we
ak; 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 &quo
thead; 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 "
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
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 app
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 con
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 exampl
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 heade
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"
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-engi
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
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/w3
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 assum
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 T
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 under
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"
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 prop
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
fer 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,
&g
t 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
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
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 th
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 co
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 i
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.
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
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
> 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
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 Compone
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
destin
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
sc
>> 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
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 ot
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 imp
36 matches
Mail list logo
