[Bug 24106] FKA: No defined way to get keyboard focus into and out of a shadow DOM component

2016-04-11 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24106 Bug 24106 depends on bug 23870, which changed state. Bug 23870 Summary: FKA: No defined way to get keyboard focus into and out of a shadow DOM component https://www.w3.org/Bugs/Public/show_bug.cgi?id=23870 What|Removed

Re: [Custom Elements] Extension of arbitrary elements at runtime.

2016-04-11 Thread Brian Kardell
On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea wrote: > The is="" attribute lets one specify that some element is actually an > extended version of that element. > > But, in order for this to work, the Custom Element definition has to > deliberately extend that same basic

Re: [Custom Elements] They are globals.

2016-04-11 Thread Ryosuke Niwa
> 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

[Custom Elements] They are globals.

2016-04-11 Thread /#!/JoePea
Hello, 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 via `import` and not modify the source code of our dependencies? I don't

[Bug 9514] [Selection] Specify Selection.modify()

2016-04-11 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=9514 Ryosuke Niwa changed: What|Removed |Added Status|ASSIGNED|RESOLVED

Re: [Custom Elements] More ES6-like API

2016-04-11 Thread /#!/JoePea
Thanks Ryosuke! That's looking a lot better. /#!/JoePea On Mon, Apr 11, 2016 at 10:28 AM, Ryosuke Niwa wrote: > 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: >

Re: [Custom Elements] They are globals.

2016-04-11 Thread Ryosuke Niwa
> 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] They are globals.

2016-04-11 Thread Domenic Denicola
I think you are being misled by a superficial similarity with React's JSX. JSX's `` desugars to `React.createElement(Foo)`, which creates a `` element with some of its behavior derived from the `Foo` class, found in JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.

Re: [Custom Elements] More ES6-like API

2016-04-11 Thread Ryosuke Niwa
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: [Custom Elements] Extension of arbitrary elements at runtime.

2016-04-11 Thread /#!/JoePea
Hello Brian The purpose of the motor-scene and motor-node elements is that they will be easy to apply 3D transforms to (and WebGL soon), with easing for example. I suppose a better approach for augmenting and existing DOM could be to simply apply the transforms via selectors instead of trying to

Re: [Custom Elements] They are globals.

2016-04-11 Thread /#!/JoePea
I get what you mean about the behaviors defined from classes that exist in the scope, in React. The really great thing about React is the ability to compose a class by using multiple classes to return the render spec. One of React's strong-points at a high level is it offers encapsulation where