Re: [Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

I implemented custom elements in Chrome (twice.) This looks reasonable to me. The exact timing of createdCallback and constructor running, and errors around element creation, are different. If authors stick to the restrictions of custom elements "v1" they should be fine, because th

[Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

elementClass { // constructor() is used in v1 Custom Elements instead of // createdCallback() as in v0. constructor() { super() // If the following is true, then we know the user should be using // `document.registerElement

Re: [custom-elements] Prefix x- for custom elements like data- attributes

w it is forward parsable... But they haven't had a way to be useful. Custom elements, make them useful, but put them in a compelling box that allow us to add anything that isn't dasherized. That was a long long long way in the making, I can't honestly see it being undone in an even stricter fashi

Re: [custom-elements] Prefix x- for custom elements like data- attributes

h 'data-' so we can > define easily new standard attribute names ('aria-*' or everything > except for 'data-*'.) We already have a similar restriction - custom elements names must *contain* a dash. ~TJ

[custom-elements] Prefix x- for custom elements like data- attributes

It would be good to restrict custom element's name to start with like 'x-' for the future standards. User-defined custom attributes; data attributes are also restricted its name to start with 'data-' so we can define easily new standard attribute names ('aria-*' or everything except for

Re: [Custom Elements] Not requiring hyphens in names.

On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren wrote: > On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote: > > I really believe that we should be allowed to name our elements with any > > name we wish, and that they should override native elements (that

Re: [Custom Elements] Not requiring hyphens in names.

On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote: > I really believe that we should be allowed to name our elements with any > name we wish, and that they should override native elements (that is future > proof), and that overriding should be on some type of encapsulated basis

Re: [Custom Elements] Not requiring hyphens in names.

;> > That means we lose the lingua franca that HTML provides; two >> > independent libraries can't ever depend on the core HTML elements, >> > because the other library might have overridden some of them. >> >> Based on my idea of registering elements on a

Re: [Custom Elements] Not requiring hyphens in names.

r library might have overridden some of them. > > Based on my idea of registering elements on a per-shadow-root basis > ( > https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440 > ), > then libraries could use any native or custom elements that the

Re: [Custom Elements] Not requiring hyphens in names.

ased on my idea of registering elements on a per-shadow-root basis (https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440), then libraries could use any native or custom elements that they want within their shadow roots. Shadow roots would provide encapsulation, and elemen

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea <trus...@gmail.com> wrote: > What if custom Elements simply override existing ones then? > > ```js > shadowRoot.registerElement('div', MyElement) > ``` That means we lose the lingua franca that HTML provides; two independent librar

Re: [Custom Elements] Not requiring hyphens in names.

What if custom Elements simply override existing ones then? ```js shadowRoot.registerElement('div', MyElement) ``` If overriding native elements was documented, it'd be fine. By default, a blank document or shadow root has no elements registered, so would use the native DIV. But, why not let

Re: [Custom Elements] Not requiring hyphens in names.

I personal don't mind the hyphenation requirement for custom elements. Tab Atkins brings up a great point about ensuring that new elements will be able to be added to spec without worry of name conflicts with existing custom elements on the page. It's much more future proof, in my opinion. On Wed

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea <trus...@gmail.com> wrote: > I personally don't like this limitation. I think Custom Elements would > be better if we could create elements that have > , with the possible exception that we can't override the > native elements.

[Custom Elements] Not requiring hyphens in names.

I personally don't like this limitation. I think Custom Elements would be better if we could create elements that have , with the possible exception that we can't override the native elements. Based on my previous email about registering elements on shadow roots, I think being able to choose

Re: [Custom Elements] They are globals.

. TLDR - ShadowDOM could be the encapsulation of HTML to Custom Elements as JSX is the encapsulation of HTML to React Components (in a morphed way, as obviously the mechanics are different). Here's what a small component might look like: ```js // --- HandyForm.js import AwesomeButton from './AwesomeB

Re: [Custom Elements] They are globals.

> On Apr 11, 2016, at 2:29 PM, /#!/JoePea <trus...@gmail.com> 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 roo

Re: [Custom Elements] They are globals.

as it is with React (due to React's aforementioned encapsulation and use of the JavaScript scopefor it's "HTML elements"), maybe the Custom Element API can take advantage of ShadowDOM instead of documents? What if custom elements can be registered on a shadow-root basis, so that the author o

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 <rn...@apple.com> 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 sp

RE: [Custom Elements] They are globals.

. Custom elements' `` is completely unlike that. In that case, `x-foo` is a tag name, and a full participant in the DOM tree structure. It affects CSS selector matching, APIs like querySelector and getElementsByTagName, and more. It's not just a div. As Ryosuke notes, it's very hard to imagine how

Re: [Custom Elements] They are globals.

> On Apr 11, 2016, at 9:02 AM, /#!/JoePea <trus...@gmail.com> 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,

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 <trus...@gmail.com&

[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

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

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

[Custom Elements] Extension of arbitrary elements at runtime.

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 won't work. It'd be nice if a Custom Element definition could

RE: [Web Components] Editor for Custom Elements

From: Philippe Le Hegaret [mailto:p...@w3.org] > But I hope you realize that coming in the W3C community, working with them > for while, and then take things away to continue the work elsewhere is > received as not working in good faith with the W3C community. This is not a > judgment of

Re: [Web Components] Editor for Custom Elements

much enjoyed working with the W3C community on the w3c/webcomponents issue tracker, and think the collaboration there has been a success. It was a very helpful "incubation phase" for custom elements. I do believe that the W3C community enjoyed working with you as well. I cer

RE: [Web Components] Editor for Custom Elements

munity on the w3c/webcomponents issue tracker, and think the collaboration there has been a success. It was a very helpful "incubation phase" for custom elements. Now that the incubation is largely complete, they can graduate to the HTML and DOM Standards, like was done with before. I in

Re: [Web Components] Editor for Custom Elements

On Wed, Apr 6, 2016 at 9:17 PM, Léonie Watson <t...@tink.uk> wrote: > Which means we're looking for someone (or more than one someone) to edit > Custom Elements. Web Components are a key part of the Web Platform, so it's > an interesting time to be part of the group working on

[Web Components] Editor for Custom Elements

Hello WP, We're looking for a new editor for the Custom Elements spec [1]. Dimitri Glazkov has stepped down as editor and will be greatly missed in the role. Thank you for all your hard work Dimitri, you helped make Custom Elements happen and it's very much appreciated. Domenic Denicola briefly

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

> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn wrote: > > > > On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa wrote: >> >> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn wrote: >> > >> > >> > >> > On Fri, Feb 26, 2016 at 3:09 PM,

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

On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa wrote: > > > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn > wrote: > > > > > > > > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote: > >> > >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn

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

> On Feb 26, 2016, at 3:22 PM, Elliott Sprehn wrote: > > > > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote: >> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn wrote: >> > >> > Can you give a code example of how this

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

On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote: > > > 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

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

;rn...@apple.com> wrote: > >> 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 li

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

; 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 DOM operation such >> as Range.extractC

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

his change, event listeners that call custom elements' methods would > end up seeing inconsistent states during compound DOM operation such as > Range.extractContents and editing operations, and we would like to avoid that > as much as possible. These are the events we wanted to try and de

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

> On Feb 22, 2016, at 10:46 PM, Ryosuke Niwa 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 construction stack per

[custom-elements] Steps inside HTMLElement's constructor

er element definition to allow construction of other custom elements inside a custom element's constructor. Without such a stack per element definition, we would end up walking through entries in the stack to find the "right" entry. Implementors are free to take such an approach to minim

[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

Notes from Custom Elements meeting

Available at https://www.w3.org/2016/01/25-webapps-minutes.html Text version: Web Platform - Custom Elements 25 Jan 2016 See also: [2]IRC log [2] http://www.w3.org/2016/01/25-webapps-irc Attendees Present Domenic_Denicola, Takayoshi_Kochi, LÃ

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: Apple's feedback for custom elements

Random comments inline (other people from Mozilla may have different opinions) On 01/24/2016 10:01 AM, Ryosuke Niwa wrote: Hi all, Here's WebKit team's feedback for custom elements. == Constructor vs createdCallback == We would like to use constructor instead of created callback

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

:rn...@apple.com>>: > >> > >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile > >> > <cha...@yandex-team.ru <mailto:cha...@yandex-team.ru>> wrote: > >> > > >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie N

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

On Wed, 06 Jan 2016 11:59:55 +0100, Takayoshi Kochi (河内 隆仁) wrote: On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa wrote: > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) > > Is there any option to attend this remotely (telcon or

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

AM, Chaals McCathie Nevile <cha...@yandex-team.ru> >> > wrote: >> > >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile >> > <cha...@yandex-team.ru> wrote: >> > >> >> we are trying to shift the date of the Custom Eleme

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

015年12月9日(水) 10:26 Ryosuke Niwa <rn...@apple.com>: > >> > >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile < > cha...@yandex-team.ru> wrote: > >> > > >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile < > cha...@

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

1000, Chaals McCathie Nevile < > cha...@yandex-team.ru> wrote: > > > >> we are trying to shift the date of the Custom Elements meeting to *25* > Jan, from the previously proposed date of 29th. > >> > >> We are currently looking for a host in the Bay area - o

RE: Custom elements contentious bits

xactly web components makes it easy enough to have mutually agreeing > "enough" implementations of things.  For example, I currently have a few > custom elements for which I have both a "native" definition and an angular > directive so that designers I know who write HTM

Re: Custom elements contentious bits

On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote: > A bit ago Jan put together an initial draft of the "contentious bits" for > custom elements, in preparation for our January F2F. Today I went through and > expanded on the issues he put

Re: Custom elements contentious bits

On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola <d...@domenic.me> wrote: > > A bit ago Jan put together an initial draft of the "contentious bits" > for custom elements, in prepar

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

On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile <cha...@yandex-team.ru> wrote: we are trying to shift the date of the Custom Elements meeting to *25* Jan, from the previously proposed date of 29th. We are currently looking for a host in the Bay area - offers grat

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 <cha...@yandex-team.ru> > wrote: > > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile > <cha...@yandex-team.ru> wrote: > >> we are trying to shift the date of the Custom Elements meeting

Custom Elements meeting will be 25th Jan (not 29th)

Dear all, we are trying to shift the date of the Custom Elements meeting to *25* Jan, from the previously proposed date of 29th. We are currently looking for a host in the Bay area - offers gratefully received. If you plan to attend, please add your name to the meeting page: <ht

Re: Custom elements contentious bits

s bits" for > custom elements, in preparation for our January F2F. Today I went through > and expanded on the issues he put together, with the result at > https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits. > It morphed into a kind of agenda for the meeting, cont

Re: Custom elements backing swap proposal

On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn <espr...@chromium.org> > wrote: > > > > I've been thinking about ways to make custom elements violate the > consistency principle l

Re: Custom elements backing swap proposal

> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn <espr...@chromium.org> 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 l

Custom elements backing swap proposal

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 in person. Can we setup a custom element discussion later in the year? The current

RE: Custom elements Constructor-Dmitry baseline proposal

From: Maciej Stachowiak [mailto:m...@apple.com] On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote: - Parser-created custom elements and upgraded custom elements will have their constructor and attributeChange callbacks called at a time when all their children

Re: Custom elements Constructor-Dmitry baseline proposal

-blzlm_skvYTCFFrks=Fqq6RL3oe2zmH8pGykh6XfqVC6LYMZILABlqZPRGG74e= I’ve written up in some detail what I consider to be the current state-of-the-art in custom elements proposals. That is, if we take the current spec, and modify it in ways that everyone agrees are good ideas, we end up

Re: Custom elements Constructor-Dmitry baseline proposal

Thank you for writing this up. Would be interesting to hear what Maciej and Ryosuke think. On Tue, Aug 18, 2015 at 12:19 AM, Domenic Denicola d...@domenic.me wrote: - Use symbols instead of strings for custom element callbacks. So the way this is done is that they are publicly available on the

Custom elements Constructor-Dmitry baseline proposal

In https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Constructor-Dmitry.md I’ve written up in some detail what I consider to be the current state-of-the-art in custom elements proposals. That is, if we take the current spec, and modify it in ways that everyone agrees are good ideas

RE: Apple's updated feedback on Custom Elements and Shadow DOM

From: Maciej Stachowiak [mailto:m...@apple.com] Does that sound right to you? If so, it is not much more appealing than prototype swizzling to us, since our biggest concern is allowing natural use of ES6 classes. Got it, thanks. So it really does sound like it comes down to class XFoo

Apple's updated feedback on Custom Elements and Shadow DOM

A while back we sent a consolidated pile of feedback on the Web Components family of specs. In preparation for tomorrow's F2F, here is an update on our positions. We've also changed the bugzilla links to point to relevant github issues instead. We're only covering Custom Elements (the main

RE: Apple's updated feedback on Custom Elements and Shadow DOM

Thanks very much for your feedback Maciej! I know we'll be talking a lot more tomorrow, but one point in particular confused me: From: Maciej Stachowiak [mailto:m...@apple.com] 4. Specifically, we don't really like the Optional Upgrades, Optional Constructors proposal (seems like it's the

Re: Apple's updated feedback on Custom Elements and Shadow DOM

On Jul 20, 2015, at 10:29 PM, Domenic Denicola d...@domenic.me wrote: Thanks very much for your feedback Maciej! I know we'll be talking a lot more tomorrow, but one point in particular confused me: From: Maciej Stachowiak [mailto:m...@apple.com] 4. Specifically, we don't really like

RE-SENDING [Apple's updated feedback on Custom Elements and Shadow DOM]

on Custom Elements and Shadow DOM A while back we sent a consolidated pile of feedback on the Web Components family of specs. In preparation for tomorrow's F2F, here is an update on our positions. We've also changed the bugzilla links to point to relevant github issues instead. We're only

Re: Two new custom elements ideas

If the main draw of wanting custom constructors is to be able to interface with other custom elements that may not have been upgraded, maybe we could skip the custom constructor and all of its attached concerns altogether by adding some sort of 'elementUpgraded' event to the document

Re: The key custom elements question: custom constructors?

On Fri, Jul 17, 2015 at 4:15 PM, Domenic Denicola d...@domenic.me wrote: From: Anne van Kesteren [mailto:ann...@annevk.nl] It fails atomically, based on the definition of innerHTML. What if that 512 KiB of HTML contains img src=foo.png? Following definitions, I assume we fire off the network

RE: The key custom elements question: custom constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] // What about document.body.innerHTML = [512 KiB of normal HTML] x-foo/x-foo; // ? does the HTML make it in, or does the operation fail atomically, or something else? It fails atomically, based on the definition of innerHTML. What if

Re: The key custom elements question: custom constructors?

On Fri, Jul 17, 2015 at 5:47 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/17/15 10:38 AM, Anne van Kesteren wrote: If I look at update the image data step 6 it seems it might be fetched at a later point? Yes, but in practice the fetch will go ahead, no? There's nothing to prevent it from

Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 10:36 PM, Domenic Denicola d...@domenic.me wrote: I have a related question: what happens if the constructor throws? Right, this is the kind of thing we need to figure out. !DOCTYPE html script use strict; window.throwingMode = true; class XFoo extends

Re: The key custom elements question: custom constructors?

On 7/17/15 12:05 PM, Anne van Kesteren wrote: True, but either way this doesn't seem like a problem. You can create a DocumentFragment, insert a new img, and then let it be GC'd, today. Sure. In practice it won't get GC'd until the load completes, which is sucky, but that's life. -Boris

Re: The key custom elements question: custom constructors?

On 7/17/15 10:38 AM, Anne van Kesteren wrote: If I look at update the image data step 6 it seems it might be fetched at a later point? Yes, but in practice the fetch will go ahead, no? There's nothing to prevent it from happening, so it's going to happen once you reach a stable state...

alternate view on constructors for custom elements

the custom elements previous design with the use of constructors. Basically, I think it should still be a two-stage creation model: 1. Native [internal] element is created with appropriate tag name, attributes, etc. 2. JS constructor is called and provided the instance (as 'this') #1

RE: alternate view on constructors for custom elements

to rationalize the custom elements previous design with the use of constructors. Basically, I think it should still be a two-stage creation model: 1. Native [internal] element is created with appropriate tag name, attributes, etc. 2. JS constructor is called and provided the instance

Re: alternate view on constructors for custom elements

On 7/17/15 2:03 PM, Travis Leithead wrote: Something magical happens here. The use of super() is supposed to call the constructor of the HTMLElement class—but that’s not a normal JS class. It doesn’t have a defined constructor() method Sure, but neither does Array. What super() actually does

Two new custom elements ideas

Hi all, Over the last few days I’ve worked on two new potential ideas for custom elements, hoping to shake things up with new possibilities. These are both largely geared around how we react to the key custom elements question [1]. https://github.com/w3c/webcomponents/blob/gh-pages/proposals

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: alternate view on constructors for custom elements

From: Travis Leithead [mailto:travis.leith...@microsoft.com] if super() is absolutely required for a constructor in a class that extends something, is there a requirement about when in the constructor method it be invoked? Must it always be the first call? Can it be later on, say at the end

RE: alternate view on constructors for custom elements

From: Domenic Denicola [mailto:d...@domenic.me] From: Travis Leithead [mailto:travis.leith...@microsoft.com] Something magical happens here. The use of super() is supposed to call the constructor of the HTMLElement class—but that’s not a normal JS class. It doesn’t have a defined

Re: The key custom elements question: custom constructors?

On 07/16/2015 08:30 AM, Domenic Denicola wrote: From: Travis Leithead [mailto:travis.leith...@microsoft.com] I've discussed this issue with some of Edge's key parser developers. Awesome; thank you for doing that! I believe to be the most straightforward approach that most closely matches

Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 6:49 PM, Domenic Denicola d...@domenic.me wrote: Even if it can be specced/implemented, should it? I.e., why would this be OK where MutationEvents are not? Apart from the verbosity and performance issues with mutation events, I think the main problem with mutation

Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 6:03 PM, Domenic Denicola d...@domenic.me wrote: Ah OK, thanks. Is there any way to get a consensus from Mozilla as a whole, preferably ahead of the F2F? I think the problem is that nobody has yet tried to figure out what invariants that would break and how we could

RE: The key custom elements question: custom constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] I think the problem is that nobody has yet tried to figure out what invariants that would break and how we could solve them. I'm not too worried about the parser as it already has script synchronization, but cloneNode(), ranges, and editing,

RE: The key custom elements question: custom constructors?

From: Olli Pettay [mailto:o...@pettay.fi] That is too strongly said, at least if you refer to my email (where I expressed my opinions, but as usually, others from Mozilla may have different opinions). I said I'd prefer if we could avoid that [Running author code during cloneNode(true)].

RE: The key custom elements question: custom constructors?

to implement. Right, but that's not actually possible with custom constructors. In particular, you need to insert the elements into the tree *after* calling out to author code that constructs them. What you mention is more like the currently-specced custom elements lifecycle callback approach

RE: The key custom elements question: custom constructors?

- From: Domenic Denicola [mailto:d...@domenic.me] Sent: Wednesday, July 15, 2015 20:45 To: public-webapps Subject: The key custom elements question: custom constructors? Hi all, Ahead of next week's F2F, I'm trying to pull together some clarifying and stage-setting materials, proposals

Re: The key custom elements question: custom constructors?

On Thu, Jul 16, 2015 at 9:49 AM, Domenic Denicola d...@domenic.me wrote: From: Anne van Kesteren [mailto:ann...@annevk.nl] I think the problem is that nobody has yet tried to figure out what invariants that would break and how we could solve them. I'm not too worried about the parser as it

Re: The key custom elements question: custom constructors?

is more like the currently-specced custom elements lifecycle callback approach. Or am I misunderstanding? No, that is a good point. The constructor callback does indeed need to happen between an element is created and the element is inserted. I think though that in this case it might be possible

RE: The key custom elements question: custom constructors?

-pattern that he'd like to avoid. He is a strong supporter of the proto-swizzle technique that happens later with retro-active upgrades to previously-seen custom elements. I am sympathetic to this concern, but have my own reservations about the proto-swizzle technique. -Original Message- From

Re: The key custom elements question: custom constructors?

custom elements to have custom constructors, then those must run in order to create properly-allocated instances of those elements; there is simply no other way to create those objects. You can shuffle the timing around a bit: e.g., while cloning a tree, you could either run the constructors

Re: Custom Elements: createdCallback cloning

clone documents, which print preview on linux and Windows and printing use) If one needs a special DOM tree for printing, beforeprint event should be used to modify the DOM. Sure, but you'd lose some stuff, e.g. canvas, and presumably custom elements if they require copying some state, due

Re: Custom Elements: createdCallback cloning

, actually. Private state is allocated for DOM wrappers in Chromium today (like Gecko), including Custom Elements; it's not a problem. DOM wrapper creation is controlled by the UA, which can arrange for allocating the slots. Sure, but this assumes elements will be backed by something other than

Re: Custom Elements: createdCallback cloning

and Windows and printing use) If one needs a special DOM tree for printing, beforeprint event should be used to modify the DOM. Sure, but you'd lose some stuff, e.g. canvas, and presumably custom elements if they require copying some state, due to the cloning. (Unless it's doing more than just

Re: Custom Elements: createdCallback cloning

(like Gecko), including Custom Elements; it's not a problem. DOM wrapper creation is controlled by the UA, which can arrange for allocating the slots. Sure, but this assumes elements will be backed by something other than JavaScript forever. Or at the very least that custom elements will always

Re: Custom Elements: createdCallback cloning

existing elements in terms of Custom Elements, you need private state. - Progressive Enhancement. The author can write more things in markup and present them while loading definitions asynchronously. Unlike progressive enhancement by finding and replacing nodes in the tree, prototype swizzling

Re: Custom Elements: createdCallback cloning

guess that depends on what you want to enable. If you want to recreate existing elements in terms of Custom Elements, you need private state. 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, actually

  1   2   3   4   5   6   7   >