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 they're more

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

On Mon, Apr 25, 2016 at 1:06 PM, Bang Seongbeom wrote: > 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

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

On Mon, Apr 25, 2016 at 10:06 AM, Bang Seongbeom wrote: > 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

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.

Thanks for the link! ​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 (for example, override within a shadow root and it

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

Just FYI, the idea of allowing non-hyphen elements if they contain non-ASCII characters which probably won't collide with future HTML elements was posted in the discussion: https://github.com/w3c/webcomponents/issues/239#issuecomment-190603674 On Fri, Apr 15, 2016 at 7:01 AM, /#!/JoePea

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

On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. wrote: > 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

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

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea 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 libraries can't ever depend

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

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

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea 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. This would prevent

Re: [Custom Elements] They are globals.

On Mon, Apr 11, 2016 at 4:44 PM, Ryosuke Niwa wrote: > You'd have to instead write it as "new SomeClass(this.shadowRoot)" and then > (1) needs to be modified as: `super(..arguments)` to pass the argument along > to the HTMLElement constructor. For sure, similar to the examples

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

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

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

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.

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

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:

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

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

Can you give a code example of how this happens? On Feb 24, 2016 8:30 PM, "Ryosuke Niwa" wrote: > > > On Feb 23, 2016, at 1:16 AM, Anne van Kesteren wrote: > > > > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa wrote: > >> Hi, > >> > >> We

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

> On Feb 23, 2016, at 1:16 AM, Anne van Kesteren wrote: > > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa wrote: >> Hi, >> >> We propose to change the lifecycle callback to be fired both before invoking >> author scripts (e.g. for dispatching events) and

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

On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa 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 listeners that

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

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

Hi Kochi, and all, The remote participation information of the 25th Jan Web Components meeting is available: https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md#logistics - VoIP: Join WebEx

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)

> On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) wrote: > > Is there any option to attend this remotely (telcon or video conference)? > > 2015年12月9日(水) 10:26 Ryosuke Niwa : >> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile

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

On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa wrote: > > > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) > wrote: > > > > Is there any option to attend this remotely (telcon or video conference)? > > > > 2015年12月9日(水) 10:26 Ryosuke Niwa

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

Is there any option to attend this remotely (telcon or video conference)? 2015年12月9日(水) 10:26 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 < >

RE: Custom elements contentious bits

From: Brian Kardell [mailto:bkard...@gmail.com] > I'd really like to understand where things really are with async/sync/almost > sync - does anyone have more notes or would they be willing to provide more > exlpanation?  I've read the linked contentious bit and I'm still not sure > that I

Re: Custom elements contentious bits

On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola 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 together, with the result at >

Re: Custom elements contentious bits

On Thu, Dec 10, 2015 at 3:23 PM, Anne van Kesteren wrote: > On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola 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

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

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 > wrote: > > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile > wrote: > >> we are trying to shift the date of the Custom Elements meeting to *25* Jan, >> from the previously

Re: Custom elements contentious bits

Domenic, Closed shadow DOM and its impact on test automation and auditing is also a very important issue. --Dylan On Wed, Nov 25, 2015 at 3:16 PM, Domenic Denicola wrote: > Hi all, > > A bit ago Jan put together an initial draft of the "contentious bits" for > custom

Re: Custom elements backing swap proposal

On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa wrote: > > > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn > wrote: > > > > I've been thinking about ways to make custom elements violate the > consistency principle less often and had a pretty awesome idea

Re: Custom elements backing swap proposal

> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn 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 like to discuss this idea

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 and

Re: Custom elements Constructor-Dmitry baseline proposal

On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote: In

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

Re: Custom Elements: createdCallback cloning

On 07/13/2015 09:22 AM, Anne van Kesteren wrote: On Sun, Jul 12, 2015 at 9:32 PM, Olli Pettay o...@pettay.fi wrote: Well, this printing case would just clone the final flattened tree without the original document knowing any cloning happened. (scripts aren't suppose to run in Gecko's static

Re: Custom Elements: createdCallback cloning

On Jul 12, 2015, at 11:30 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com wrote: 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,

Re: Custom Elements: createdCallback cloning

On Sun, Jul 12, 2015 at 9:32 PM, Olli Pettay o...@pettay.fi wrote: Well, this printing case would just clone the final flattened tree without the original document knowing any cloning happened. (scripts aren't suppose to run in Gecko's static clone documents, which print preview on linux and

Re: Custom Elements: createdCallback cloning

On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney domin...@google.com wrote: 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. Private state is allocated for DOM wrappers in Chromium today

Re: Custom Elements: createdCallback cloning

On 07/12/2015 08:09 PM, Anne van Kesteren wrote: On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com wrote: I think the most important question here, though, is not constructors or prototype swizzling. I guess that depends on what you want to enable. If you want to recreate

Re: Custom Elements: createdCallback cloning

On Mon, Jul 13, 2015 at 4:32 AM, Olli Pettay o...@pettay.fi wrote: On 07/12/2015 08:09 PM, Anne van Kesteren wrote: On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com wrote: I think the most important question here, though, is not constructors or prototype swizzling. I

Re: Custom Elements: createdCallback cloning

On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney domin...@google.com wrote: I think the most important question here, though, is not constructors or prototype swizzling. I guess that depends on what you want to enable. If you want to recreate existing elements in terms of Custom Elements, you

Re: Custom Elements: createdCallback cloning

On Thu, Jul 2, 2015 at 4:05 PM, Anne van Kesteren ann...@annevk.nl wrote: In the interest of moving forward I tried to more seriously consider Dmitry's approach. Based on es-discussion discussion https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors it seems likely new

Re: Custom Elements: is=

On Thu, Jul 2, 2015 at 3:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote: From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

On 6 Jul, 2015, at 5:18 pm, Hayato Ito hay...@google.com wrote: I've finished the migration. All 141 bugs have been migrated [1]. I'll triage the migrated bugs manually later. I'm sorry that public-webapps@ has received the mass flood of bugspam mail again this time. That's

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

I've finished the migration. All 141 bugs have been migrated [1]. I'll triage the migrated bugs manually later. I'm sorry that public-webapps@ has received the mass flood of bugspam mail again this time. That's unintentional. The lesson for for the future: We need to change also the setting of

Re: Custom Elements: is=

On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote: From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com wrote: Thank you. I appreciate that. Then, let me migrate all open bugs of 'Component Model'. I think that include also HTML Imports bugs in addition to Custom Elements bugs. When I finish, I'll announce that. SGTM. Please go

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

Thank you. I appreciate that. Then, let me migrate all open bugs of 'Component Model'. I think that include also HTML Imports bugs in addition to Custom Elements bugs. When I finish, I'll announce that. On Tue, Jun 30, 2015 at 11:21 PM Xiaoqian Wu xiaoq...@w3.org wrote: Hi Hayato,

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

Hi Hayato, public-webapps has been removed from the default CC list of ‘Component Model’. Please let us know when you finish migrating and we will recover this component ASAP. Thanks. — xiaoqian On 29 Jun, 2015, at 10:42 pm, Arthur Barstow art.bars...@gmail.com wrote: Yves, Xiaoqian,

[admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

Yves, Xiaoqian, Mike - would one of you please do as Hayato requests below (and then notify him so he can move the Custom Elements bugs to Github)? -Thanks, ArtB On 6/25/15 2:49 AM, Hayato Ito wrote: I am thinking about migrating Custom Element bugs[1] to Web Components GitHub Issues [2], as

Re: Custom Elements: is=

On 6/12/2015 11:19 PM, Anne van Kesteren wrote: On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson lwat...@paciellogroup.com wrote: Is there a succinct explanation of why the is= syntax is disliked? Rather than button is=my-button/button you want my-button/my-button that just gets all

Re: Custom Elements: is=

I agree with Anne. A stopgap could hinder cross browser development significantly (with regards to backwards compatibility browser needs of clients). Does it gain enough for us to justify one? I am just joining the conversation now so please correct me if I missed something on 'is'. As far as

Re: Custom Elements: is=

On Mon, Jun 15, 2015 at 10:45 AM, Bruce Lawson bru...@opera.com wrote: On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a

Re: Custom Elements: is=

On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a stopgap for v1, and put our energies we're currently expending debating this

RE: Custom Elements: is=

From: Bruce Lawson [mailto:bru...@opera.com] Sent: 15 June 2015 09:46 On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a

Re: Custom Elements: is=

On Sat, Jun 13, 2015, at 18:52, Alice Boxhall wrote: Doc in progress at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md Sent a pull request your way[1]. --tobie --- [1]: https://github.com/w3c/webcomponents/pull/117

Re: Custom Elements: is=

On 13/06/2015 16:33, Bruce Lawson wrote: On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention

RE: Custom Elements: is=

From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web

RE: Custom Elements: is=

From: Tobie Langel [mailto:to...@codespeaks.com] Sent: 12 June 2015 21:26 On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote: Is there a succinct explanation of why the is= syntax is disliked? The info on the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax issue

RE: Custom Elements: is=

From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 14:57 Subject: Re: Custom Elements: is= On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote: I'm also concerned developers will mistakenly write: my-button is=button As it is much closer in form to what

Re: Custom Elements: is=

On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote: I'm also concerned developers will mistakenly write: my-button is=button As it is much closer in form to what they want to achieve (see the extend=parent syntax I wrote earlier). That's true (and I've done exactly this

Re: Custom Elements: is=

On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson lwat...@paciellogroup.com wrote: Is there a succinct explanation of why the is= syntax is disliked? Rather than button is=my-button/button you want my-button/my-button that just gets all the button goodness through composition/inheritance.

Re: Custom Elements: is=

Folks, I agree with Anne that we've been having a somewhat circular re-discovery of the pros/cons here. I believe that the best way to address this is to capture all of these points in one doc -- this would be a just a little extra work for the current participants, but super awesome for the

Re: Custom Elements: is=

On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention to my-button, and render Push as plain

Re: Custom Elements: is=

Doc in progress at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md On Sat, Jun 13, 2015 at 8:50 AM, Dimitri Glazkov dglaz...@google.com wrote: Folks, I agree with Anne that we've been having a somewhat circular re-discovery of the pros/cons here. I believe

Re: Custom Elements: is=

On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote: Is there a succinct explanation of why the is= syntax is disliked? The info on the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax issue [1]. Esthetics aside, the main issue it is takes the concept of inheritance

Re: Custom Elements: is=

We also have an extension of form which collects values from both native and custom inputs. On Thu, Jun 11, 2015 at 1:41 PM, Joshua Peek j...@joshpeek.com wrote: GitHub has been using tag extensions in a few places for progressive enhancement. Form and button elements have been the most useful

RE: Custom Elements: is=

Is there a succinct explanation of why the is= syntax is disliked? The info on the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax issue [1]. Léonie. [1] https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements -- Léonie Watson - Senior

Re: Custom Elements: is=

GitHub has been using tag extensions in a few places for progressive enhancement. Form and button elements have been the most useful things to extend the behavior of. is= syntax aside, I do agree extending complex native element prototypes in general has alot of associated undefined behavior. If

Re: Custom Elements: is=

On Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani justinfagn...@google.com wrote: And I'm still concerned that removing is= would severely harm the cases where you need access to special parsing behavior like template and style. With synchronous constructors you could imagine setting the parsing

Re: Custom Elements: is=

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if

Re: Custom Elements: is=

On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com wrote: - In the time between v1 and v2 (however long that ends up being) we are left without any way to solve this problem, assuming we don't come up with something else for v1. If developers start using custom elements where

Re: Custom Elements: is=

On Jun 9, 2015 8:45 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both

Re: Custom Elements: is=

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com wrote: - In the time between v1 and v2 (however long that ends up being) we are left without any way to solve this problem, assuming we don't come up

Re: Custom Elements: is=

Did anyone have any further thoughts on this? My concerns haven't changed. On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote: On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com

Re: Custom Elements: is=

On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote: Did anyone have any further thoughts on this? My concerns haven't changed. Nothing new. On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall

Re: Custom Elements: is=

On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote: Did anyone have any further thoughts on this? My concerns haven't changed. Nothing new. On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote: On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren

Re: Custom Elements: is=

And I'm still concerned that removing is= would severely harm the cases where you need access to special parsing behavior like template and style. On Mon, Jun 8, 2015 at 2:16 PM, Alice Boxhall aboxh...@google.com wrote: Did anyone have any further thoughts on this? My concerns haven't changed.

Re: Custom Elements: is=

On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com mailto:aboxh...@google.com wrote: Web developers are already

Re: Custom Elements: is=

On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote: Web developers

Re: Custom Elements: is=

On Jun 8, 2015, at 4:37 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote: On

Re: Custom Elements: is=

: Monday, June 8, 2015 5:58 PM To: Alice Boxhall Cc: Anne van Kesteren; Léonie Watson; WebApps WG Subject: Re: Custom Elements: is= On Jun 8, 2015, at 4:37 PM, Alice Boxhall aboxh...@google.com wrote: On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jun 8, 2015, at 3:23 PM

Re: Custom Elements: is=

On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com wrote: I definitely acknowledge is= may not be the ideal solution to the latter problem - it definitely has some holes in it, especially when you start

Re: Custom Elements: insert/remove callbacks

On 5/9/15 12:40 PM, Anne van Kesteren wrote: So that seems clearly wrong (in the specification)... Are descendants notified in tree order? In Gecko, yes. Note that running script during these insert/remove notifications is not OK, so anything that needs to run script has to do it later (for

Re: Custom Elements: insert/remove callbacks

On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) To be clear, ours is also

Re: Custom Elements: insert/remove callbacks

On May 9, 2015 9:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 2:50 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node

Re: Custom Elements: insert/remove callbacks

On Thu, May 7, 2015 at 10:56 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote: That actually seems pretty similar to what we have, ours is in

RE: Custom Elements: is=

The 'is' attribute is only a declarative marker; it's the indicator that the native element has a [potential] custom prototype and hierarchy, right? I don't mean to drudge up past history and decisions already laid to rest, but if subclassing native elements is a good compromise until we get to

  1   2   3   >