Shadow DOM: state of the distribution API

2015-05-06 Thread Anne van Kesteren
It seems we have three contenders for the distribution API. 1) Synchronous, no flattening of content. A host element's shadow tree has a set of slots each exposed as a single content element to the outside. Host elements nested inside that shadow tree can only reuse slots from the outermost host

Re: Permissions API vs local APIs

2015-05-06 Thread Erik Isaksen
Jonas has a good idea in extending the Perms API. This reduces extra work and simplifies a lot On Tuesday, May 5, 2015, Mike West mk...@google.com wrote: On Tue, May 5, 2015 at 2:54 PM, Jonas Sicking jo...@sicking.cc javascript:_e(%7B%7D,'cvml','jo...@sicking.cc'); wrote: On Mon, May 4, 2015

Custom Elements: insert/remove callbacks

2015-05-06 Thread Anne van Kesteren
Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements This has come up before, but it came up again at the Extensible Web Summit so raising hopefully for the last time. The DOM has insert/remove primitives for nodes. Custom Elements uses insertion into a document

Custom Elements: is=

2015-05-06 Thread Anne van Kesteren
Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements I think we reached rough consensus at the Extensible Web Summit that is= does not do much, even for accessibility. Accessibility is something we need to tackle low-level by figuring out how builtin elements work:

Custom Elements: Upgrade et al

2015-05-06 Thread Anne van Kesteren
Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements I think the most pragmatic way forward here is accepting that constructing and upgrading need not be tied. Synchronous constructors map most closely to what browsers do today for builtin elements and open up the

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Dimitri Glazkov
On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote: It seems we have three contenders for the distribution API. 1) Synchronous, no flattening of content. A host element's shadow tree has a set of slots each exposed as a single content element to the outside. Host

Re: Custom Elements: insert/remove callbacks

2015-05-06 Thread Dimitri Glazkov
On Wed, May 6, 2015 at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote: Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements This has come up before, but it came up again at the Extensible Web Summit so raising hopefully for the last time. The DOM has

RE: Custom Elements: is=

2015-05-06 Thread Léonie Watson
From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: 06 May 2015 15:25 Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements I think we reached rough consensus at the Extensible Web Summit that is= does not do much, even for accessibility. Accessibility is

Re: :host pseudo-class

2015-05-06 Thread Tab Atkins Jr.
On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 8:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: It's certainly no weirder, imo, than having a pseudo-element that doesn't actually live in any element's pseudo-tree, but instead just lives in

Re: Permissions API vs local APIs

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 7:05 PM, Miguel Garcia migu...@chromium.org wrote: Is there a timeline for the permission API in Mozilla? It shouldn't be much work to add this. The main problem I see is the list of open issues with the specification. -- https://annevankesteren.nl/

Re: Custom Elements: Upgrade et al

2015-05-06 Thread Ryosuke Niwa
On May 6, 2015, at 8:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 4:59 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me wrote: Can you explain how you envision cloning to work a bit more? Somehow there

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Ryosuke Niwa
On May 6, 2015, at 10:57 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote: 1) Synchronous, no flattening of content. A host element's shadow tree has a set of slots each exposed as a single content element to the outside.

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Ryosuke Niwa
On May 5, 2015, at 10:53 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 3:22 AM, Ryosuke Niwa rn...@apple.com wrote: Where? I have not yet to see a use case for which selective redistribution of nodes (i.e. redistributing only a non-empty strict subset of nodes from

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Ryosuke Niwa
On May 6, 2015, at 2:39 PM, Elliott Sprehn espr...@chromium.org wrote: The 3 proposal is what the houdini effort is already researching for custom style/layout/paint. I don't think it's acceptable to make all usage of Shadow DOM break when used with libraries that read layout information

Re: Custom Elements: is=

2015-05-06 Thread Dimitri Glazkov
It might be good to document these on the wiki? Would be lost otherwise. :DG On Wed, May 6, 2015 at 11:53 AM, Elliott Sprehn espr...@chromium.org wrote: Removing this breaks several use cases of which there's no alternative currently:

Re: Custom Elements: is=

2015-05-06 Thread Ryosuke Niwa
On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote: Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements I think we reached rough consensus at the Extensible Web Summit that is= does not do much, even for accessibility. Accessibility is

Re: Permissions API vs local APIs

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 6:34 PM, Miguel Garcia migu...@chromium.org wrote: Notifications has it (as a property instead of a method which is a pain). Notifications is a special snowflake though since it has a requestPermission() method too which no other API that requires permission (e.g.

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Elliott Sprehn
The 3 proposal is what the houdini effort is already researching for custom style/layout/paint. I don't think it's acceptable to make all usage of Shadow DOM break when used with libraries that read layout information today, ie. offsetTop must work. I also don't think it's acceptable to introduce

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Jonas Sicking
On Wed, May 6, 2015 at 11:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote: Has at-end-of-microtask been debated rather than 1/2? Synchronous always has the downside that the developer has to deal with reentrancy. 1/2 are

Re: Custom Elements: insert/remove callbacks

2015-05-06 Thread Justin Fagnani
On Wed, May 6, 2015 at 8:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov dglaz...@google.com wrote: This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866. The way I remember it, the argument went like this: the most common use case

Re: Custom Elements: is=

2015-05-06 Thread Alice Boxhall
On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 4:46 PM, Léonie Watson lwat...@paciellogroup.com wrote: My understanding is that sub-classing would give us the accessibility inheritance we were hoping is= would provide. Apologies if I've

Re: Permissions API vs local APIs

2015-05-06 Thread Mounir Lamouri
On Wed, 6 May 2015, at 19:07, Doug Turner wrote: On May 6, 2015, at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the permission API as it currently stands is pretty trivial to implement. So I don't see a reason to delay until 2017 or even Q3 2015. If the spec is ready to

Re: Custom Elements: is=

2015-05-06 Thread Elliott Sprehn
Removing this breaks several use cases of which there's no alternative currently: https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-action.html

Re: Permissions API vs local APIs

2015-05-06 Thread Martin Thomson
On 6 May 2015 at 11:07, Doug Turner do...@mozilla.com wrote: On May 6, 2015, at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the permission API as it currently stands is pretty trivial to implement. So I don't see a reason to delay until 2017 or even Q3 2015. If the spec is ready

Re: Permissions API vs local APIs

2015-05-06 Thread Marcos Caceres
On May 6, 2015 at 2:38:06 PM, Mounir Lamouri (mou...@lamouri.fr) wrote: Marcos|Mounir, do you two have any thoughts on this? I agree with Jonas: we should delegate the check to the Permissions API. However, I don't see how I can enforce that if the Push API doesn't want to. I would

[webcomponents]: Minutae -- moved proposals from wiki to /proposals

2015-05-06 Thread Dimitri Glazkov
Folks, To alleviate the limitations of the github wiki (can't submit PRs easily, etc.), we are moving to a slightly different, more streamlined (awesomer!) model: the /proposal directory: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/ It's basically the same as the wiki, but now

Re: Permissions API vs local APIs

2015-05-06 Thread Jonas Sicking
On Wed, May 6, 2015 at 9:00 AM, Doug Turner do...@mozilla.com wrote: The way I would look at this is based on timeframe -- if we're not implementing the Permissions API until 2017 or something, i'd just leave the functionality in the PushAPI spec. If the Permission API is right around the

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Jonas Sicking
On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote: 1) Synchronous, no flattening of content. A host element's shadow tree has a set of slots each exposed as a single content element to the outside. Host elements nested inside that shadow tree can only reuse slots from

Re: Permissions API vs local APIs

2015-05-06 Thread Doug Turner
On May 6, 2015, at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the permission API as it currently stands is pretty trivial to implement. So I don't see a reason to delay until 2017 or even Q3 2015. If the spec is ready to go (what’s anne’s worry), then lets implement it and

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking jo...@sicking.cc wrote: Has at-end-of-microtask been debated rather than 1/2? Synchronous always has the downside that the developer has to deal with reentrancy. 1/2 are triggered by the component author. Synchronous just means that they run within

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Ryosuke Niwa
On May 6, 2015, at 6:18 PM, Hayato Ito hay...@chromium.org wrote: On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa rn...@apple.com wrote: On May 5, 2015, at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote: On May

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Hayato Ito
I'm not saying the event path is not related to a composed tree. I'm saying: - Composed tree is related with CSS. - Node distribution should be considered as a part of style concept. On Thu, May 7, 2015 at 12:54 PM Ryosuke Niwa rn...@apple.com wrote: On May 6, 2015, at 6:18 PM, Hayato Ito

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Hayato Ito
On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa rn...@apple.com wrote: On May 5, 2015, at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote: On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote: On

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Hayato Ito
I'm feeling that there is a misunderstanding about the relation between DOM tree and Composed Tree in this discussion. If you understand the difference, the discussion might be more productive. In short, - Composed Tree DOES NOT replace DOM tree. Most of existing APIs work for DOM tree. Composed

Re: Custom Elements: insert/remove callbacks

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 4:34 PM, Dimitri Glazkov dglaz...@google.com wrote: This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866. The way I remember it, the argument went like this: the most common use case for this callback is to react to element becoming part of the main document

Re: :host pseudo-class

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 4:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 5, 2015 at 10:56 PM, Anne van Kesteren ann...@annevk.nl wrote: And again, from the perspective of the shadow tree, the host element is not part of its normal DOM. The shadow tree is its normal DOM. This is

Re: Custom Elements: is=

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 4:46 PM, Léonie Watson lwat...@paciellogroup.com wrote: My understanding is that sub-classing would give us the accessibility inheritance we were hoping is= would provide. Apologies if I've missed it somewhere obvious, but is there any information/detail about the

Re: Permissions API vs local APIs

2015-05-06 Thread Jonas Sicking
I think mozilla would be fine with taking the permission API as a dependency and implement that at the same time. Implementing the permission API should be fairly trivial for us. But we should verify this with the people actually working on the push API. / Jonas On Wed, May 6, 2015 at 3:13 AM,

Re: Custom Elements: Upgrade et al

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 4:59 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me wrote: Can you explain how you envision cloning to work a bit more? Somehow there will be instances of these elements which are not created by their

Re: Custom Elements: Upgrade et al

2015-05-06 Thread Dimitri Glazkov
On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me wrote: Can you explain how you envision cloning to work a bit more? Somehow there will be instances of these elements which are not created by their constructors? Also, how is it in any way similar to how canvas or input work?

Re: Custom Elements: is=

2015-05-06 Thread Steve Faulkner
On 6 May 2015 at 14:25, Anne van Kesteren ann...@annevk.nl wrote: I think we reached rough consensus at the Extensible Web Summit that is= does not do much, even for accessibility. I agree on one level, it does not do a lot for accessibility because the issue of styling native elements still

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Hayato Ito
I'm wondering how we should estimate the performance impact of these proposals. In the era of Web Components, I expect that one page has 1k Web Components. The page must work without any significant noticeable performance regression, compared to a page which doesn't use Web Components. That's our

Re: Custom Elements: Upgrade et al

2015-05-06 Thread Anne van Kesteren
On Thu, May 7, 2015 at 12:23 AM, Ryosuke Niwa rn...@apple.com wrote: Are you suggesting that cloning my-button will create a new instance of my-button by invoking its constructor? No, I'm saying there would be another primitive operation, similar to the extended structured cloning proposed

Fwd: Making ARIA and native HTML play better together

2015-05-06 Thread Steve Faulkner
Forwarding on as this relates to custom elements which use ARIA to provide semantics -- Regards SteveF -- Forwarded message -- From: Steve Faulkner faulkner.st...@gmail.com Date: 7 May 2015 at 06:42 Subject: Making ARIA and native HTML play better together To: HTMLWG WG

Re: Permissions API vs local APIs

2015-05-06 Thread Anne van Kesteren
On Wed, May 6, 2015 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote: I think Mozilla would be fine with taking the permission API as a dependency and implement that at the same time. Implementing the permission API should be fairly trivial for us. But we should verify this with the people

Re: Permissions API vs local APIs

2015-05-06 Thread Doug Turner
The way I would look at this is based on timeframe — if we’re not implementing the Permissions API until 2017 or something, i’d just leave the functionality in the PushAPI spec. If the Permission API is right around the corner, I would remove it form the PushAPI spec. Do any other APIs have a