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

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

[Bug 24106] 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=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.

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 element type or else it wo

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

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 a

[Custom Elements] They are globals.

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 r

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: > > It'd be nice i

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 via > `import` and n

RE: [Custom Elements] They are globals.

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. Custom

Re: [Custom Elements] More ES6-like API

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: > https://dom.spec.whatwg.org/

Re: [Custom Elements] They are globals.

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 the

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 constructors that th

Re: [service worker] f2f meeting notes, next meeting details

Hello, here are the day 1 meeting notes from the service worker F2F. The attendees are CC'd if there are any corrections that need to be made or if anyone has any questions or concerns that they would like to raise. = Service Worker F2F April 11, 2016 A