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

2016-08-22 Thread Dominic Cooney
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?

2016-08-20 Thread /#!/JoePea
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

2016-04-25 Thread Brian Kardell
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

2016-04-25 Thread Tab Atkins Jr.
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

2016-04-25 Thread Bang Seongbeom
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.

2016-04-22 Thread Justin Fagnani
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.

2016-04-22 Thread Anne van Kesteren
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.

2016-04-22 Thread /#!/JoePea
;> > 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.

2016-04-14 Thread Takayoshi Kochi
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.

2016-04-14 Thread /#!/JoePea
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.

2016-04-13 Thread Tab Atkins Jr.
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.

2016-04-13 Thread /#!/JoePea
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.

2016-04-13 Thread Nick Dugger
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.

2016-04-13 Thread Tab Atkins Jr.
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.

2016-04-13 Thread /#!/JoePea
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.

2016-04-12 Thread /#!/JoePea
. 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.

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

2016-04-11 Thread /#!/JoePea
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

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

2016-04-11 Thread Domenic Denicola
. 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.

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

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

[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

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

[Custom Elements] Extension of arbitrary elements at runtime.

2016-04-10 Thread /#!/JoePea
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

2016-04-07 Thread Domenic Denicola
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

2016-04-07 Thread Philippe Le Hegaret
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

2016-04-06 Thread Domenic Denicola
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

2016-04-06 Thread Anne van Kesteren
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

2016-04-06 Thread Léonie Watson
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

2016-02-26 Thread Ryosuke Niwa
> 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

2016-02-26 Thread Elliott Sprehn
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

2016-02-26 Thread Ryosuke Niwa
> 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

2016-02-26 Thread Elliott Sprehn
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

2016-02-26 Thread Ryosuke Niwa
> 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

2016-02-24 Thread Elliott Sprehn
;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

2016-02-24 Thread Ryosuke Niwa
; 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

2016-02-23 Thread Anne van Kesteren
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

2016-02-22 Thread Ryosuke Niwa
> 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

2016-02-22 Thread Ryosuke Niwa
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

2016-02-22 Thread Ryosuke Niwa
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

2016-01-26 Thread Philippe Le Hegaret
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

2016-01-24 Thread Ryosuke Niwa
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

2016-01-24 Thread Olli Pettay
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)

2016-01-19 Thread Xiaoqian Wu
: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)

2016-01-18 Thread Chaals McCathie Nevile
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)

2016-01-06 Thread Ryosuke Niwa
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)

2016-01-06 Thread 河内 隆仁
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)

2016-01-06 Thread 河内 隆仁
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

2015-12-28 Thread Domenic Denicola
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

2015-12-10 Thread Anne van Kesteren
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

2015-12-10 Thread Brian Kardell
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)

2015-12-08 Thread Chaals McCathie Nevile
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)

2015-12-08 Thread Ryosuke Niwa
> 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)

2015-12-07 Thread Chaals McCathie Nevile
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

2015-12-06 Thread Dylan Barrell
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

2015-10-25 Thread Dominic Cooney
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

2015-10-24 Thread Ryosuke Niwa
> 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

2015-10-23 Thread Elliott Sprehn
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

2015-08-21 Thread Domenic Denicola
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

2015-08-21 Thread Maciej Stachowiak
-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

2015-08-18 Thread Anne van Kesteren
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

2015-08-17 Thread Domenic Denicola
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

2015-07-21 Thread Domenic Denicola
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

2015-07-20 Thread Maciej Stachowiak
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

2015-07-20 Thread Domenic Denicola
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

2015-07-20 Thread Maciej Stachowiak
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]

2015-07-20 Thread Michael[tm] Smith
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

2015-07-18 Thread Derek Gray
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?

2015-07-17 Thread Anne van Kesteren
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?

2015-07-17 Thread Domenic Denicola
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?

2015-07-17 Thread Anne van Kesteren
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?

2015-07-17 Thread Anne van Kesteren
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?

2015-07-17 Thread Boris Zbarsky
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?

2015-07-17 Thread Boris Zbarsky
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

2015-07-17 Thread Travis Leithead
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

2015-07-17 Thread Domenic Denicola
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

2015-07-17 Thread Boris Zbarsky
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

2015-07-17 Thread Domenic Denicola
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

2015-07-17 Thread Ryosuke Niwa
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

2015-07-17 Thread Domenic Denicola
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

2015-07-17 Thread Travis Leithead
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?

2015-07-16 Thread Olli Pettay
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?

2015-07-16 Thread Anne van Kesteren
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?

2015-07-16 Thread Anne van Kesteren
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?

2015-07-16 Thread Domenic Denicola
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?

2015-07-16 Thread Domenic Denicola
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?

2015-07-16 Thread Domenic Denicola
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?

2015-07-16 Thread Domenic Denicola
- 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?

2015-07-16 Thread Jonas Sicking
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?

2015-07-16 Thread Jonas Sicking
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?

2015-07-15 Thread Travis Leithead
-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?

2015-07-15 Thread Olli Pettay
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

2015-07-13 Thread Olli Pettay
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

2015-07-13 Thread Ryosuke Niwa
, 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

2015-07-13 Thread Anne van Kesteren
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

2015-07-13 Thread Anne van Kesteren
(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

2015-07-12 Thread Olli Pettay
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

2015-07-12 Thread Dominic Cooney
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   >