Re: [components] Isolated Imports and Foreign Custom Elements

On May 1, 2015, at 4:35 PM, Domenic Denicola wrote: >> alert(weirdArray.__proto__ == localArray.__proto__) > > This alerts false in IE, Firefox, and Chrome. > That is what I'd expect it to do. (It does the same in Safari). I guess I didn't explain why I put this line in, so for clarity: thi

RE: [components] Isolated Imports and Foreign Custom Elements

> alert(weirdArray.__proto__ == localArray.__proto__) This alerts false in IE, Firefox, and Chrome.

Re: [components] Isolated Imports and Foreign Custom Elements

> On May 1, 2015, at 9:47 AM, Anne van Kesteren wrote: > > On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak wrote: >> I wrote up a proposal (with input and advice from Ryosuke Niwa) on a >> possible way to extend Web Components to support fully isolated components: >> >> https://github.com/w

Re: [components] Isolated Imports and Foreign Custom Elements

Your proposal seems conceptually very similar to mine. I guess that’s a good sign! It seems the biggest difference is the foreign registration hook - whether it’s done at class registration time (registerElement) or done at import time. The reasons I did not go with class registration time are

Observers added to Performance

Webperf landed earlier this week a proposal [1] to add observers of performance entries: [[ The |PerformanceObserver| interface can be used to observe the Performance Timeline

PSA: Martin Thomson joins Push API Editor team

Hi All, We are pleased to announce Mozilla's Martin Thomson has agreed to be a co-Editor of the Push API spec . Eduardo and Bryan are no longer able to continue as active editors and we thank them for their past contributions and we hope their active particip

RE: [components] Isolated Imports and Foreign Custom Elements

If you take a look at [1], we extend the custom elements registration mechanism so that the constructor is still available in the hosting global, yet the implementation is defined in the isolated environment. An approach to solving this might address another concern I have... I've been thinking

Re: Shadow DOM Imperative API proposal #1 vs

Thanks Wilson and Anne! One interesting thing I noticed is that the algo relies on candidate.distributedNodes already being correctly populated by the nesting shadow tree. Does that mean that we'd need to ensure the correct order of invoking distribution among the nesting trees? Or maybe mutation

[Bug 28591] New: [Shadow]: Figure out a good replacement for /deep/ in testing scenarios

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28591 Bug ID: 28591 Summary: [Shadow]: Figure out a good replacement for /deep/ in testing scenarios Product: WebAppsWG Version: unspecified Hardware: PC OS: Al

Re: [components] Isolated Imports and Foreign Custom Elements

On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak wrote: > I wrote up a proposal (with input and advice from Ryosuke Niwa) on a > possible way to extend Web Components to support fully isolated components: > > https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal > > I welcome comme

Re: Inheritance Model for Shadow DOM Revisited

On Fri, May 1, 2015 at 10:36 AM, Ryosuke Niwa wrote: >> On May 1, 2015, at 1:04 AM, Anne van Kesteren wrote: >> This is where you directly access superclass' ShadowRoot I assume and >> modify things? > > In the named slot approach, these overridable parts will be exposed to > subclasses as an ov

Shadow DOM Imperative API proposal #1 vs

Wilson Page attempted to implement (with microtask observers as a timing solution for the time being) to see whether that proposal was workable: https://gist.github.com/wilsonpage/d5520bd8d22327633e33 Compared to how is implemented in #2 this looks rather jarring and we're not even sure wheth

Re: Inheritance Model for Shadow DOM Revisited

> On May 1, 2015, at 1:04 AM, Anne van Kesteren wrote: > > On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa 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 by its own content - e.g. g

Re: Inheritance Model for Shadow DOM Revisited

On Thu, Apr 30, 2015 at 11:35 PM, Ryosuke Niwa 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 by its own content - e.g. grab the > device context and draw everything by yourself. So th