Re: [Custom Elements] They are globals.

> On Apr 11, 2016, at 2:29 PM, /#!/JoePea wrote: > > What if custom elements can be registered on a shadow-root basis, so > that the author of a Custom Element (one that isn't registered by > default) can register a bunch of elements that it's shadow root will > use, passing

Re: [Custom Elements] They are globals.

> On Apr 11, 2016, at 9:02 AM, /#!/JoePea wrote: > > Is it possible to take an approach more similar to React where Custom > Elements aren't registered in a global pool? What if two libraries we'd like > to use define elements of the same name, and we wish to import these

Re: [Custom Elements] More ES6-like API

That's exactly what we're doing. The latest spec uses ES6 class constructor to define custom elements. See an example below this section in DOM spec: https://dom.spec.whatwg.org/#concept-element-custom-element-state - R. Niwa > On Apr 10, 2016, at 7:58 PM, /#!/JoePea wrote:

Re: Telecon / meeting on first week of April for Web Components

> On Mar 23, 2016, at 6:04 AM, Chaals McCathie Nevile > wrote: > > On Tue, 22 Mar 2016 04:17:07 +0100, Hayato Ito wrote: > >> Either option is okay to me. I'll attend the meeting from Tokyo. > > I'll attend from Europe. Is there a preferred day,

Re: Telecon / meeting on first week of April for Web Components

For people participating from Tokyo and Europe, would you prefer having it in early morning or late evening? Because Bay Area, Tokyo, and Europe are almost uniformly distributed across the timezone, our time slots are limited:

Re: Meeting for selection API at TPAC?

> On Mar 16, 2016, at 12:46 PM, Chaals McCathie Nevile <cha...@yandex-team.ru> > wrote: > > On Wed, 16 Mar 2016 16:42:07 +0100, Ryosuke Niwa <rn...@apple.com> wrote: > >> Thanks for the rely. >> >> Léonie & Chaals, could we allocate a time slot

Re: Meeting for selection API at TPAC?

adow DOM > 2. Multiple Range support > 3. Resolution of open issues towards FPWD > > - yosi > > 2016年3月15日(火) 9:21 Ryosuke Niwa <rn...@apple.com <mailto:rn...@apple.com>>: > Hi all, > > Is there any interest in discussing selection API at TPAC? > > T

Meeting for selection API at TPAC?

Hi all, Is there any interest in discussing selection API at TPAC? There are 32 open issues on Github at the moment: https://github.com/w3c/selection-api/issues - R. Niwa

Telecon / meeting on first week of April for Web Components

Hi all, We've been making a good progress on shadow DOM and custom elements API but there seems to be a lot of open questions still. I've asked a couple of people involved in the discussion, and there seems to be an interest for having another tele-conference or an in-person meeting. Can we

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn <espr...@chromium.org> wrote: > > > > On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa <rn...@apple.com> wrote: >> >> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn <espr...@chromium.org> wrote: >

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

> On Feb 26, 2016, at 3:22 PM, Elliott Sprehn <espr...@chromium.org> wrote: > > > > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa <rn...@apple.com> wrote: >> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn <espr...@chromium.org> wro

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

> On Feb 24, 2016, at 9:06 PM, Elliott Sprehn wrote: > > Can you give a code example of how this happens? For example, execCommand('Delete') would result in sequentially deleting nodes as needed. During this compound operation, unload events may fire on iframes that got

Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

> On Feb 23, 2016, at 1:16 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa <rn...@apple.com> wrote: >> Hi, >> >> We propose to change the lifecycle callback to be fired both before invoking >>

Re: [custom-elements] Steps inside HTMLElement's constructor

> On Feb 22, 2016, at 10:46 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > Here are steps to construct a custom element as agreed during Jan F2F as I > promised to write down [1] [2]: There's a very appealing alternative to this, which doesn't involve having a element cons

[custom-elements] Steps inside HTMLElement's constructor

Hi all, Here are steps to construct a custom element as agreed during Jan F2F as I promised to write down [1] [2]: Modify http://w3c.github.io/webcomponents/spec/custom/#dfn-element-definition as follows: The element definition describes a custom element and consists of: * custom element

Re: TPAC 2016 - meetings

I'd like to attend Web Perf WG's meeting so it would be ideal if any meetings held for Web Apps WG didn't overlap with those of Web Perf WG's. > On Feb 10, 2016, at 4:34 AM, Chaals McCathie Nevile > wrote: > > Dear all, > > as you probably know, the W3C will hold its

[custom-elements] Invoking lifecycle callbacks before invoking author scripts

Hi, We propose to change the lifecycle callback to be fired both before invoking author scripts (e.g. for dispatching events) and before returning to author scripts. Without this change, event listeners that call custom elements' methods would end up seeing inconsistent states during compound

Apple's feedback for custom elements

Hi all, Here's WebKit team's feedback for custom elements. == Constructor vs createdCallback == We would like to use constructor instead of created callback. https://github.com/w3c/webcomponents/issues/139 At the meeting, we should discuss what happens when a constructor throws during

Re: [UIEvents] Keydown/keyup events during composition

> On Jan 11, 2016, at 8:26 PM, Masayuki Nakano wrote: > > As far as I know, Gecko doesn't dispatch keydown nor keyup event for IME > unaware applications because JS changes something at keydown or keyup event > handler causes forcibly committing composition that may

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

Re: [Editing] [DOM] Adding static range API

> On Jan 9, 2016, at 6:25 PM, Olli Pettay wrote: > > Hard to judge this proposal before seeing an API using StaticRange objects. > > One thing though, if apps were to create an undo stack of their own, they > could easily have their own Range-like API implemented in JS. So if

[selection-api] onselectstart/onselectionchange attributes

Hi, It looks like browsers don't agree on where `onselectstart` and `onselectionchange` IDL attributes should be defined: https://github.com/w3c/selection-api/issues/54 https://github.com/w3c/selection-api/issues/60 In particular, Blink/WebKit/Trident all defines onselectstart/onselectionchange

Re: time at TPAC other than Wednesday?

> On Jan 9, 2016, at 4:11 PM, Chaals McCathie Nevile <cha...@yandex-team.ru> > wrote: > > On Sat, 09 Jan 2016 23:20:27 +0300, Ryosuke Niwa <rn...@apple.com> wrote: > >> >>> On Jan 8, 2016, at 7:12 PM, Johannes Wilm <johan...@fiduswriter.org>

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

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

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,

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

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

  1   2   3   4   5   6   >