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

the progress easily in one place. I'm not fan of the discussion being scattered. :) https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl wrote: On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote

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

On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote: In today's F2F, I've got an action item to come up with a concrete workable proposal for imperative API. I had a great chat about this afterwards

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

On Apr 25, 2015, at 9:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote: In today's F2F, I've got an action item to come up with a concrete workable proposal for imperative API. I had a great chat about this afterwards

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

On Apr 25, 2015, at 1:17 PM, Olli Pettay o...@pettay.fi wrote: On 04/25/2015 09:28 AM, Anne van Kesteren wrote: On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote: In today's F2F, I've got an action item to come up with a concrete workable proposal for imperative API. I

Proposal for changes to manage Shadow DOM content distribution

Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote: On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance

Re: Proposal for changes to manage Shadow DOM content distribution

/template Here, the content elements are both creating slots and fulfilling slots. - R. Niwa On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 21, 2015, at 11:08 PM, Domenic Denicola d...@domenic.me wrote: From: Ryosuke Niwa [mailto:rn...@apple.com] At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1

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

Just to clarity, I obviously haven't had a time to discuss this with my colleagues so I don't know which one (or something else entirely) we (Apple) end up endorsing/opposing at the end. On Apr 25, 2015, at 12:14 AM, Ryosuke Niwa rn...@apple.com wrote: Hi all, In today's F2F, I've got

[Shadow DOM] Use Cases for Selective Redistributions

Hi, Could someone give me a concrete use cases for node redistributions where the second and subsequent insertion points need to redistribute a subset of nodes that have been redistributed to an insertion point in an earlier shadow DOM? Maybe someone at Google working on Polymer would have

Imperative API for Node Distribution in Shadow DOM (Revisited)

Hi all, In today's F2F, I've got an action item to come up with a concrete workable proposal for imperative API. I had a great chat about this afterwards with various people who attended F2F and here's a summary. I'll continue to work with Dimitri Erik to work out details in the coming

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa rn...@apple.com wrote: I find it decidedly relevant given I'm pointing out that attribute-specified slots Domenic mentioned isn't what you described. Since the only venue

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 22, 2015, at 3:48 PM, Justin Fagnani justinfagn...@google.com wrote: On Wed, Apr 22, 2015 at 2:37 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: On Tue

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 22, 2015, at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 22, 2015, at 2:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 22, 2015 at 2:29 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 22, 2015, at 8:52 AM, Domenic Denicola d...@domenic.me wrote: Between content-slot-specified slots, attribute-specified slots, element-named

Re: Proposal for changes to manage Shadow DOM content distribution

...@google.com mailto:justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote: I do want the ability

Re: Proposal for changes to manage Shadow DOM content distribution

On Apr 22, 2015, at 10:16 AM, Justin Fagnani justinfagn...@google.com wrote: On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com mailto:justinfagn...@google.com wrote

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

On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote: IMO

Re: Inheritance Model for Shadow DOM Revisited

On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows well

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

I've updated the gist to reflect the discussion so far: https://gist.github.com/rniwa/2f14588926e1a11c65d3 https://gist.github.com/rniwa/2f14588926e1a11c65d3 Please leave a comment if I missed anything. - R. Niwa

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

On Apr 28, 2015, at 1:04 PM, Elliott Sprehn espr...@chromium.org wrote: A distribute callback means running script any time we update distribution, which is inside the style update phase (or event path computation phase, ...) which is not a location we can run script. That's not what

Re: Inheritance Model for Shadow DOM Revisited

On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote: Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which shadow as function can't support, but content slot can support. - there are use cases which shadow as function can

Re: Inheritance Model for Shadow DOM Revisited

On Apr 30, 2015, at 1:47 AM, Hayato Ito hay...@chromium.org wrote: Thanks, let me update my understanding: - There is no use cases which shadow as function can't support, but content slot can support. - The purpose of the proposal is to remove an *extra* syntax. There is no other

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

On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org wrote: I think Polymer folks will answer the use case of re-distribution. So let me just show a good analogy so that every one can understand intuitively what re-distribution *means*. Let me use a pseudo language and define

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

On Apr 27, 2015, at 1:45 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com mailto:sorv...@google.com wrote: Here's a minimal and hopefully simple proposal that we can flesh out if this seems like an interesting api direction

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

On Apr 26, 2015, at 11:05 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote: One major drawback of this API is computing insertionList is expensive because we'd have to either (where n is the number of nodes in the shadow DOM

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

On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com wrote: Here's a minimal and hopefully simple proposal that we can flesh out if this seems like an interesting api direction: https://gist.github.com/sorvell/e201c25ec39480be66aa

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

On Apr 27, 2015, at 2:38 PM, Hayato Ito hay...@chromium.org wrote: On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org mailto:hay...@chromium.org wrote: I think Polymer folks

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

On Apr 27, 2015, at 3:15 PM, Steve Orvell sorv...@google.com wrote: IMO, the appeal of this proposal is that it's a small change to the current spec and avoids changing user expectations about the state of the dom and can explain the two declarative proposals for distribution. It seems

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

On Apr 27, 2015, at 4:41 PM, Steve Orvell sorv...@google.com wrote: Again, the timing was deferred in [1] and [2] so it really depends on when each component decides to distribute. I want to be able to create an element x-foo that acts like other dom elements. This element uses Shadow

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

On Apr 27, 2015, at 3:31 PM, Hayato Ito hay...@chromium.org wrote: I think there are a lot of user operations where distribution must be updated before returning the meaningful result synchronously. Unless distribution result is correctly updated, users would take the dirty result.

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

On Apr 27, 2015, at 5:43 PM, Steve Orvell sorv...@google.com wrote: That might be an acceptable mode of operations. If you wanted to synchronously update your insertion points, rely on custom element's lifecycle callbacks and you can only support direct children for distribution.

Inheritance Model for Shadow DOM Revisited

Note: Our current consensus is to defer this until v2. On Apr 27, 2015, at 9:09 PM, Hayato Ito hay...@chromium.org wrote: For the record, I, as a spec editor, still think Shadow Root hosts yet another Shadow Root is the best idea among all ideas I've ever seen, with a shadow as function,

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

On Apr 27, 2015, at 7:32 PM, Steve Orvell sorv...@google.com wrote: Perhaps we need to make childrenChanged optionally get called when attributes of child nodes are changed just like the way you can configure mutation observers to optionally monitor attribute changes. Wow, let me

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

On Apr 27, 2015, at 12:25 AM, Justin Fagnani justinfagn...@google.com wrote: On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote: If we wanted to allow non-direct child descendent (e.g. grand child

Re: Why is querySelector much slower?

On Apr 27, 2015, at 7:04 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang curvedm...@gmail.com wrote: Intuitively, querySelector('.class') only needs to find the first matching node, whereas getElementsByClassName('.class')[0] needs to find all matching

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

On Apr 30, 2015, at 5:12 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote: The other thing I would like to explore is what an API would look like that does the subclassing as well. For the slot approach, we can model

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

On Apr 30, 2015, at 5:12 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa rn...@apple.com wrote: I’m writing any kind of component that creates a shadow DOM, I’d just keep references to all my insertion points instead of querying them each time I

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

On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's not necessarily problematic, OK. So the claim that the current

Re: Inheritance Model for Shadow DOM Revisited

On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants

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

On Apr 30, 2015, at 9:25 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa rn...@apple.com wrote: ... The return value of (2) is the same in either case. There is no observable difference. No interop issue. Please file a bug for the spec

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

On Apr 30, 2015, at 9:01 PM, Hayato Ito hay...@chromium.org wrote: Thanks, however, we're talking about https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html. Ah, I think there was some miscommunication there. I don't think anyone is claiming that the current spec

Re: Inheritance Model for Shadow DOM Revisited

On Apr 30, 2015, at 2:44 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 2:29 PM, Brian Kardell bkard...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:00 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue

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

On Apr 30, 2015, at 8:17 PM, Hayato Ito hay...@chromium.org wrote: On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result

Re: Inheritance Model for Shadow DOM Revisited

On Apr 30, 2015, at 4:43 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote: The problem with shadow as function is that the superclass implicitly selects nodes based on a CSS selector so unless the nodes a subclass wants

Re: Inheritance Model for Shadow DOM Revisited

On May 1, 2015, at 1:04 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa rn...@apple.com wrote: To start off, I can think of three major ways by which subclass wants to interact with its superclass: 1. Replace what superclass shows entirely

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

On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov dglaz...@google.com wrote: On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: One thing that worries me about the `distribute` callback approach (a.k.a

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

On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote: I've updated the gist to reflect the discussion so far: https://gist.github.com/rniwa/2f14588926e1a11c65d3 Please leave a comment if I missed

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

On Apr 29, 2015, at 5:12 PM, Justin Fagnani justinfagn...@google.com wrote: Here's one case of redistribution: https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122 Any time you see content inside a custom element it's potentially redistribution. Here there's on

Re: Inheritance Model for Shadow DOM Revisited

On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced it once in the spec (and implemented

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

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 Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote

Re: Custom Elements: Upgrade et al

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

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)

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

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=

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: Imperative API for Node Distribution in Shadow DOM (Revisited)

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 4

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

On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org wrote: We can solve this problem by running the distribution code in a separate scripting context with a restricted (distribution specific) API as is

Re: Custom Elements: Upgrade et al

On May 6, 2015, at 9:48 PM, Anne van Kesteren ann...@annevk.nl wrote: 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

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

On May 6, 2015, at 11:10 PM, Elliott Sprehn espr...@chromium.org wrote: On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote: I'm saying: - Composed tree is related with CSS. - Node distribution

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

On May 7, 2015, at 7:20 PM, Hayato Ito hay...@chromium.org wrote: Ryosuke, could you file a bug for the spec if you find an uncomfortable part in the spec? I want to understand exactly what you are trying to improve. I don't think there is any issue with the spec per se. What Anne and I

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

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: Custom Elements: is=

On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote: Did anyone have any further thoughts on this? My concerns haven't changed. Nothing new. On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote: On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren

Re: Custom Elements: is=

On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com mailto:aboxh...@google.com wrote: Web developers are already

Re: Custom Elements: is=

On Jun 8, 2015, at 4:37 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote

Re: [ime-api] [blink-dev] Removing IME API code from Blink

On May 27, 2015, at 11:46 AM, Travis Leithead travis.leith...@microsoft.com wrote: I believed the use-cases for avoiding UI clashes between site-driven auto-complete lists and IME auto-complete boxes is still a valid use case, and I think the spec is still valid to try to push to

Re: Components F2F

On Jun 30, 2015, at 2:55 AM, Anne van Kesteren ann...@annevk.nl wrote: Can someone update https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting with a bit more information? I hear it might be in Mountain View? Is Google hosting this meeting as well? Alternatively, would other

Re: Custom Elements: is=

On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote: From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button

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

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

Copying multi-range selection

Hi all, We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range

Re: alternate view on constructors for custom elements

On Jul 17, 2015, at 1:14 PM, Travis Leithead travis.leith...@microsoft.com wrote: From: Domenic Denicola [mailto:d...@domenic.me] window.XFoo = document.registerElement(‘x-foo’, XFooStartup); Why is XFoo different from XFooStartup? If I define a method in XFooStartup, does it exist

Re: Custom Elements: createdCallback cloning

On Jul 12, 2015, at 11:30 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com wrote: Yes. I am trying to interpret this in the context of the esdiscuss thread you linked. I'm not sure I understand the problem with private state,

Shadow DOM and SVG use elements

Hi all, What should happen when a SVG use element references an element (or its ancestor) with a shadow root? Should the use element show the composed tree underneath it or ignore shadow DOM altogether? I'm a little inclined towards the former (uses the composed tree). - R. Niwa

Re: Custom elements backing swap proposal

> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn wrote: > > I've been thinking about ways to make custom elements violate the consistency > principle less often and had a pretty awesome idea recently. > > Unfortunately I won't be at TPAC, but I'd like to discuss this idea

Re: [Web Components] proposing a f2f...

> > On Oct 29, 2015, at 9:47 AM, Chris Wilson wrote: > > Or host in Seattle. :) > > On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead > wrote: >> I would prefer a late January date so as to allow me to arrange travel. >> Otherwise, I’m happy

Re: [web components] proposed meetings: 15 dec / 29 jan

> On Nov 13, 2015, at 8:08 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa <rn...@apple.com> wrote: >> What outstanding problems are you thinking of? > > Again, not I, but Hayato Ito raised these. I just happen

Re: [web components] proposed meetings: 15 dec / 29 jan

> On Nov 13, 2015, at 3:07 AM, Anne van Kesteren wrote: > > On Fri, Nov 13, 2015 at 11:32 AM, Chaals McCathie Nevile > wrote: >> Our proposal is to look for a host on 15 December on the West Coast, for a >> meeting primarily focused on Shadow DOM, and

Re: TPAC Topic: Using ES2015 Modules in HTML

> On Oct 16, 2015, at 2:45 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa <rn...@apple.com> wrote: >> Can we discuss how we can integrate ES2015 modules into HTML on Tuesday, >> October 27th at TPAC? > >

TPAC Topic: Using ES2015 Modules in HTML

Hi all, Can we discuss how we can integrate ES2015 modules into HTML on Tuesday, October 27th at TPAC? Both Gecko and WebKit are basically done implementing ES6 module supports in their respective JavaScript engines but blocked on http://whatwg.github.io/loader/

Re: PSA: publish WD of "WebIDL Level 1"

> On Aug 7, 2015, at 9:27 AM, Anne van Kesteren wrote: > > On Fri, Aug 7, 2015 at 6:23 PM, Travis Leithead > wrote: >> This is, at a minimum, incremental goodness. It's better than leaving the >> prior L1 published document around--which

Re: Shadow DOM spec for v1 is ready to be reviewed

Thanks for the update! > On Aug 27, 2015, at 11:33 PM, Hayato Ito wrote: > > Let me post a quick update for the Shadow DOM spec: > https://w3c.github.io/webcomponents/spec/shadow/ >

Re: Tests for new shadow DOM API

I think many of them are still relevant. The key problem I have at the moment is that I can't tell which ones are relevant and which ones aren't. So I wanted to create a new directory and migrate or delete the existing tests over time. > On Sep 3, 2015, at 1:19 PM, Travis Leithead

Re: PSA: publish WD of "WebIDL Level 1"

> On Sep 1, 2015, at 7:27 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Tue, Sep 1, 2015 at 4:23 PM, Ryosuke Niwa <rn...@apple.com> wrote: >> I think you’re missing the point. The point of these documentation is to >> know exactly what the patch author

Re: PSA: publish WD of "WebIDL Level 1"

> On Aug 31, 2015, at 8:51 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Tue, Sep 1, 2015 at 2:33 AM, Ryosuke Niwa <rn...@apple.com> wrote: >> Let's say we implement some feature based on Web IDL published as of today. >> I'm going to refer that

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

> On Sep 29, 2015, at 8:19 AM, Alan Stearns <stea...@adobe.com> wrote: > > On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" > <rn...@apple.com> wrote: > > Chaals, Art, > > Do you have a time preference for this? We’ve got one vot

Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

Hi, Attending the recent meeting for shadow DOM styling [1] convinced me to join CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG on this topic during TPAC to iron out the details. Can we have a joint meeting (of one or two hours) on Monday (10/26) or Tuesday

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

> On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile > wrote: > > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile > wrote: > >> we are trying to shift the date of the Custom Elements meeting to *25* Jan, >> from the previously

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) <ko...@google.com> wrote: > > Is there any option to attend this remotely (telcon or video conference)? > > 2015年12月9日(水) 10:26 Ryosuke Niwa <rn...@apple.com>: >> >> > On Dec 8, 2015, at 2:55

Re: time at TPAC other than Wednesday?

> On Jan 9, 2016, at 12:20 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > >> On Jan 8, 2016, at 7:12 PM, Johannes Wilm <johan...@fiduswriter.org> wrote: >> >> On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin <gl...@microsoft.com> wrote: >>&

Re: time at TPAC other than Wednesday?

> On Jan 9, 2016, at 6:18 AM, Florian Rivoal wrote: > >> On Jan 9, 2016, at 11:49, Grisha Lyukshin wrote: >> >> Hello Johannes, >> >> I was the one to organize the meeting. To make things clear, this was an ad >> hoc meeting with the intent for the

Re: time at TPAC other than Wednesday?

> On Jan 8, 2016, at 7:12 PM, Johannes Wilm wrote: > > On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin wrote: >> Hello Johannes, >> >> I was the one to organize the meeting. To make things clear, this was an ad >> hoc meeting with the intent

[UIEvents] [Editing] Ordering of composition events and beforeinput

Hi, This is a feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. First off, we found out that there are behavior inconsistencies between browsers with respect to composition events. WebKit,

[UIEvents] Firing composition events for dead keys

Hi all, This is another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. We found out that all major browsers (Chrome, Firefox, and Safari) fire composition events for dead keys on Mac but

[UIEvents] [Editing] Moving input/beforeinput events into UI events

Hi all, This is another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. As we discussed various aspects of composition events and beforeinput/input events, it became apparent that we want

[UIEvents] Keydown/keyup events during composition

Hi all, This is another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. We've been informed that Gecko/Firefox does not fire keydown/keyup events during input method composition for each

[Editing] Adding `dataTransfer` to `InputEvent` interface

Hi, This is yet another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. It came to our attention that `beforeinput` event fired for paste would need to expose HTML (or images, etc...)

[Editing] [DOM] Adding static range API

Hi, This is yet another feedback from multiple browser vendors (Apple, Google, Microsoft) that got together in Redmond last Thursday to discuss editing API and related events. For editing APIs, it's desirable to have a variant of Range that is immutable. For example, if apps were to create

Re: [UIEvents] Firing composition events for dead keys

> On Jan 9, 2016, at 6:33 PM, Olli Pettay <o...@pettay.fi> wrote: > > On 01/10/2016 01:14 AM, Ryosuke Niwa wrote: >> Hi all, >> >> This is another feedback from multiple browser vendors (Apple, Google, >> Microsoft) that got together in Redmo

<    1   2   3   4   5   6   >