Re: Custom Elements: is=""

On Thu, Jul 2, 2015 at 3:59 PM, Ryosuke Niwa wrote: > > > On Jun 13, 2015, at 4:49 PM, Léonie Watson > wrote: > > > > From: Bruce Lawson [mailto:bru...@opera.com] > > Sent: 13 June 2015 16:34 > > > > On 13 June 2015 at 15:30, Léonie Watson > wrote: > >> why not use the extends= syntax you menti

Re: Custom Elements: is=""

> On Jun 13, 2015, at 4:49 PM, Léonie Watson wrote: > > From: Bruce Lawson [mailto:bru...@opera.com] > Sent: 13 June 2015 16:34 > > On 13 June 2015 at 15:30, Léonie Watson wrote: >> why not use the extends= syntax you mentioned? >> >> Push > > because browsers that don't know about web comp

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 wrote: Is there a succinct explanation of why the is= syntax is disliked? Rather than you want that just gets all the goodness through composition/inheritance. When I first learned abo

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 na

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

Re: Custom Elements: is=""

On Mon, Jun 15, 2015 at 10:45 AM, Bruce Lawson wrote: > On 14 June 2015 at 01:41, Patrick H. Lauke 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 energi

Re: Custom Elements: is=""

On 14 June 2015 at 01:41, Patrick H. Lauke 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 into styling standar

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 wrote: why not use the extends= syntax you mentioned? Push because browsers that don't know about web components wouldn't pay any attention to , and render "Push" as plain text. Browsers that don't know about

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 wrote: > why not use the extends= syntax you mentioned? > > Push because browsers that don't know about web components wouldn't pay any attention to , and render "Push" as plain text.

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

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 futur

Re: Custom Elements: is=""

On 13 June 2015 at 15:30, Léonie Watson wrote: > why not use the extends= syntax you mentioned? > > Push because browsers that don't know about web components wouldn't pay any attention to , and render "Push" as plain text. Browsers that don't know about web components will fall back to with

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 wrote: > I'm also concerned developers will mistakenly write: > > > > As it is much closer in form to what

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 iss

Re: Custom Elements: is=""

On 12 June 2015 at 21:26, Tobie Langel wrote: > I'm also concerned developers will mistakenly write: > > > > 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 myself). But wouldn't solve that

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 inheritanc

Re: Custom Elements: is=""

On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson wrote: > Is there a succinct explanation of why the is= syntax is disliked? Rather than you want that just gets all the goodness through composition/inheritance. Also the fact that you need to be able to submit custom elements is someth

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 ac

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 wrote: > GitHub has been using tag extensions in a few places for progressive > enhancement. Form and button elements have been the most useful things > to ext

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 Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren wrote: > On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall > 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

Re: Custom Elements: is=""

On Jun 9, 2015 8:45 AM, "Dimitri Glazkov" wrote: > > On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren 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

Re: Custom Elements: is=""

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren 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 we > do >

Re: Custom Elements: is=""

On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall 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 they > would previ

Re: Custom Elements: is=""

On Mon, Jun 8, 2015 at 11:48 PM, Justin Fagnani wrote: > And I'm still concerned that removing is= would severely harm the cases > where you need access to special parsing behavior like and >

Re: Custom Elements: is=""

_ From: Ryosuke Niwa Sent: 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 wrote: > > > > On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niw

Re: Custom Elements: is=""

> On Jun 8, 2015, at 4:37 PM, Alice Boxhall wrote: > > > > On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa wrote: >> >>> On Jun 8, 2015, at 3:23 PM, Alice Boxhall wrote: >>> >>> On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa wrote: > On Jun 8, 2015, at 2:16 PM, Alice Boxhall wrote:

Re: Custom Elements: is=""

On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa wrote: > > On Jun 8, 2015, at 3:23 PM, Alice Boxhall wrote: > > On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa wrote: > >> >> > On Jun 8, 2015, at 2:16 PM, Alice Boxhall wrote: >> Web developers are already writing their own "custom elements" as a bun

Re: Custom Elements: is=""

> On Jun 8, 2015, at 3:23 PM, Alice Boxhall wrote: > > On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa > wrote: >> >> > On Jun 8, 2015, at 2:16 PM, Alice Boxhall > > > wrote: >> Web developers are already writing their own "custom elements" as a

Re: Custom Elements: is=""

On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa wrote: > > > On Jun 8, 2015, at 2:16 PM, Alice Boxhall 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 > wrote: > >> On Thu, May 7, 2015

Re: Custom Elements: is=""

> On Jun 8, 2015, at 2:16 PM, Alice Boxhall 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 wrote: >> On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren wrote: >>> On Wed, May 6, 2015 at 6:59 PM

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 and

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 wrote: > On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren > wrote: > >> On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall >> wrote: >> > I definitely acknowledge is= may not be

Re: Custom Elements: is=""

On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall 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 > > adding author shadow roots

RE: Custom Elements: is=""

From: Travis Leithead [mailto:travis.leith...@microsoft.com] > It always seemed weird to me that 'prototype' of ElementRegistrationOptions > can inherit from anything (including null), and be completely disassociated > from the localName provided in 'extends'. Yes, the current spec is complete

RE: Custom Elements: is=""

[mailto:justinfagn...@google.com] Sent: Friday, May 8, 2015 1:06 PM To: Travis Leithead Cc: Ryosuke Niwa; Anne van Kesteren; WebApps WG Subject: Re: Custom Elements: is="" If I'm understanding your proposal correctly, wouldn't this limit any document to have a single subclass per

Re: Custom Elements: is=""

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > 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

Re: Custom Elements: is=""

ight have both iron-button and paper-button. There would be no chance for that with native element extensions without is="". > > > *From:* Justin Fagnani [mailto:justinfagn...@google.com] > *Sent:* Friday, May 8, 2015 1:06 PM > *To:* Travis Leithead > *Cc:* Ryosuke N

Re: Custom Elements: is=""

If I'm understanding your proposal correctly, wouldn't this limit any document to have a single subclass per native element? How would you express: Me You -Justin On Fri, May 8, 2015 at 12:56 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > The 'is' attribute is only a declarative

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

Re: Custom Elements: is=""

On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall 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 > adding author shadow roots to things - but I think it does have potential. > I'd really like t

Re: Custom Elements: is=""

It might be good to document these on the wiki? Would be lost otherwise. :DG< On Wed, May 6, 2015 at 11:53 AM, Elliott Sprehn wrote: > Removing this breaks several use cases of which there's no alternative > currently: > > > https://chromium.googlesource.com/infra/infra/+/master/appengine/chrom

Re: Custom Elements: is=""

> On May 6, 2015, at 6:25 AM, Anne van Kesteren wrote: > > Open issues are kept track of here: > > https://wiki.whatwg.org/wiki/Custom_Elements > > I think we reached rough consensus at the Extensible Web Summit that > is="" does not do much, even for accessibility. Accessibility is > somethi

Re: Custom Elements: is=""

Removing this breaks several use cases of which there's no alternative currently: https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-action.html https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common

Re: Custom Elements: is=""

On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren wrote: > On Wed, May 6, 2015 at 4:46 PM, Léonie Watson > wrote: > > My understanding is that sub-classing would give us the accessibility > inheritance we were hoping is= would provide. Apologies if I've missed it > somewhere obvious, but is ther

Re: Custom Elements: is=""

On Wed, May 6, 2015 at 4:46 PM, Léonie Watson wrote: > My understanding is that sub-classing would give us the accessibility > inheritance we were hoping is= would provide. Apologies if I've missed it > somewhere obvious, but is there any information/detail about the proposed > sub-classing fea

Re: Custom Elements: is=""

On 6 May 2015 at 14:25, Anne van Kesteren wrote: > I think we reached rough consensus at the Extensible Web Summit that > is="" does not do much, even for accessibility. > I agree on one level, it does not do a lot for accessibility because the issue of styling native elements still remains. I d

RE: Custom Elements: is=""

> From: Anne van Kesteren [mailto:ann...@annevk.nl] > Sent: 06 May 2015 15:25 > Open issues are kept track of here: > > https://wiki.whatwg.org/wiki/Custom_Elements > > I think we reached rough consensus at the Extensible Web Summit that is="" > does not do much, even for accessibility. Accessi