[Bug 28652] New: [Shadow] Need Document.deepActiveElement

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

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

[admin] Getting notification about WebApp's web-platform-tests activity?

2015-05-18 Thread Arthur Barstow
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

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

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

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
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

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