Re: Custom Elements: is=""

[Dominic Cooney]

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 mentioned?
> >>
> >> Push
> >
> > because browsers that don't know about web components wouldn't pay any
> attention to , and render "Push" as plain text.
> >
> > Of course! I should have thought of that.
>
> That's not entirely true.  If the implementation of my-button, let us call
> it MyButtonElement had the prototype that extends HTMLButtonElement, then
> the browser can set role=button just fine.


Excuse the intrusion, but I'm slightly confused by at least one point.
Maybe you could help me clear it up. It's related to what you term "the
implementation of my-button". What is that? Is it something defined by the
web author (how?) or the user agent?

Sincerely,

Dominic

Re: Custom Elements: is=""

[Ryosuke Niwa]

> 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 components wouldn't pay any 
> attention to , and render "Push" as plain text.
> 
> Of course! I should have thought of that.

That's not entirely true.  If the implementation of my-button, let us call it 
MyButtonElement had the prototype that extends HTMLButtonElement, then the 
browser can set role=button just fine.

> On Jun 13, 2015, at 5:41 PM, Patrick H. Lauke  wrote:
> 
> 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 web components will fall back to
>>  with > this-is-made-much-more-marvellous-by="my-button"> (or whatever)
> 
> However, this fallback will only really be useful for very simple cases, 
> where web components have been used to jazz up what essentially is still the 
> element that was extended. And, I would posit, any scripting that was done to 
> act on the all-singing, all-dancing new web component button (if it does 
> anything more than a regular button) would not work for the fallback. Unless 
> it's really just using web components for fancy styling (for instance having 
> a "material design" button that essentially still works just like a button) - 
> in which case, it makes more sense to work on stylability of standard 
> elements.


Precisely!  I've been saying that for the last two years.  It's so nice & 
refreshing to hear someone making the same argument :)  And we (Apple) would 
love to solve the stylability issue of form elements.

- R. Niwa

Re: Custom Elements: is=""

[Mark Giffin]

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 about web components, the biggest disappointment 
for me was learning that if I wanted to base my new custom element on a 
native element like , I could no longer have a custom tag name. 
So instead of having , I had to use the funky and awkward 
. I realize there are good reasons for this, but 
it's very disappointing because it "broke" my idea of custom elements. I 
created a pull request for this in the Drawbacks section of the summary doc.


Mark

Re: Custom Elements: is=""

[Erik Isaksen]

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 naming goes, an 'extends' attribute with a prototype path seems
to be the most intuitive for me. Using element names in the naming
conventions to define inheritance is limiting. Eventually we would want to
be able to support extending other custom elements (whether this happens in
v1 or v2).

Custom elements can have long names. For the most part I have seen elements
with 2-3 hyphenated words but it is possible to have elements that are like
'crazy-long-awesome-button-thing' so extending this without an attribute
reference might look like
'' where
'my-fabulous-button' is the new element namespace. Although this is a
problem with 'is' or 'extends' as well, it is more intuitive to have some
attribute reference to denote a change rather than a a long concatenated
element name. On a side note, developers suck at naming generally speaking.


On Mon, Jun 15, 2015 at 5:07 AM, Léonie Watson 
wrote:

> 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 our energies we're currently expending
> debating this into styling standard elements - which is currently being
> considered http://dev.w3.org/csswg/css-forms/
>
> Will leaving is= (or whatever we call it) in situ create backward
> compatibility problems later on if/when it changes?
>
> That aside, concentrating efforts on styling native HTML elements makes a
> lot of sense.
>
>
> Léonie
>
> --
> Léonie Watson - Senior accessibility engineer
> @LeonieWatson @PacielloGroup PacielloGroup.com
>
>
>
>
>


-- 



*Erik Isaksen *


*Google Developer Expert HTML5
*

*The Web Platform Podcast  Show Host*

*ReadTheSource.io  Co-Host*


*nevra...@gmail.com *
*@eisaksen    *

*The Web Platform Podcast Links*

Twitter - https://twitter.com/thewebplatform

Google Plus - https://plus.google.com/u/0/106965203807974584370

Stream/Web -http://thewebplatform.libsyn.com/

Facebook - https://www.facebook.com/thewebplatform

iTunes -
https://itunes.apple.com/us/podcast/the-web-platform-podcast/id899384794?mt=2

Stitcher - http://www.stitcher.com/podcast/the-web-platform-podcast

YouTube (not all episodes available)  -
https://www.youtube.com/channel/UCjz3j22CyBpy6Qk5SL6UwcQ

RSS - http://thewebplatform.libsyn.com/rss

Github - https://github.com/thewebplatform


*Read The Source: Open Source Companion Live Screencast*

Twitter - http://hangouts.readthesource.io/

Google Plus - https://plus.google.com/105627089988168968277/

Youtube - https://www.youtube.com/channel/UCVqD-Rd1nMmvbvf-AvQvgZw

Github - https://github.com/readthesource

RSS - http://hangouts.readthesource.io/index.xml

RE: Custom Elements: is=""

[Léonie Watson]

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 our energies we're currently expending debating 
this into styling standard elements - which is currently being considered 
http://dev.w3.org/csswg/css-forms/

Will leaving is= (or whatever we call it) in situ create backward compatibility 
problems later on if/when it changes? 

That aside, concentrating efforts on styling native HTML elements makes a lot 
of sense.


Léonie

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

Re: Custom Elements: is=""

[Anne van Kesteren]

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 energies we're currently
> expending debating this into styling standard elements - which is
> currently being considered http://dev.w3.org/csswg/css-forms/

Why should we standardize a stopgap?


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Bruce Lawson]

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 standard elements - which is
currently being considered http://dev.w3.org/csswg/css-forms/

b

Re: Custom Elements: is=""

[Tobie Langel]

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

[Patrick H. Lauke]

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 web components will fall back to
 with  (or whatever)


However, this fallback will only really be useful for very simple cases, 
where web components have been used to jazz up what essentially is still 
the element that was extended. And, I would posit, any scripting that 
was done to act on the all-singing, all-dancing new web component button 
(if it does anything more than a regular button) would not work for the 
fallback. Unless it's really just using web components for fancy styling 
(for instance having a "material design" button that essentially still 
works just like a button) - in which case, it makes more sense to work 
on stylability of standard elements.


P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

RE: Custom Elements: is=""

[Léonie Watson]

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.

Of course! I should have thought of that.

Léonie.


-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

Re: Custom Elements: is=""

[Alice Boxhall]

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 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 future
> folk.
>
> For example, Domenic started such a doc for another custom elements
> contentious bit:
> https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.
> Please help break the cycle of re-discovery :)
>
> :DG<
>
>

Re: Custom Elements: is=""

[Dimitri Glazkov]

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

For example, Domenic started such a doc for another custom elements
contentious bit:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.
Please help break the cycle of re-discovery :)

:DG<

Re: Custom Elements: is=""

[Bruce Lawson]

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  (or whatever)

b

RE: Custom Elements: is=""

[Léonie Watson]

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

I think the problem with this would be that it still turns the expected X 
extends Y convention on its head? It also appears as though the attributes 
relate to  rather than the element indicated in the extendedby= 
attribute.

Léonie.

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Custom Elements: is=""

[Léonie Watson]

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 [1].

[...]

So in summary it's ugly, has a high cognitive load, doesn't express the 
developers intent (actually even expresses the opposite), is hard to spot when 
reading code, and is error prone.

Hope this helps. :)

It does, thank you.

At the risk of asking the obvious question, why not use the extends= syntax you 
mentioned?

Push

It follows the expected X extends Y convention, and makes it reasonably clear 
what the attributes have been applied to I think.

Léonie.

Re: Custom Elements: is=""

[Bruce Lawson]

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?

b

Re: Custom Elements: is=""

[Tobie Langel]

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
developers are familiar with and stands it on its head.

The idea with inheritance is that you build a new object and it happens
to inherit from another one, so for example:



makes a lot of sense. Clearly, you're building a new element that
extends the capabilities of the existing button object. With the is=
syntax, however, what it is you're doing isn't clear at all:



What's the message here? Oh this is just a button. Oh wait no it's not,
it's a my-button. But does it actually inherit from button? Mmm. Not
clear from the syntax. 

Further more, what about when you add a bunch of extra attributes in
there:



It becomes hard to spot that this element isn't actually a traditional
button. Things get easily lost when scanning code. 

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

So in summary it's ugly, has a high cognitive load, doesn't express the
developers intent (actually even expresses the opposite), is hard to
spot when reading code, and is error prone.

Hope this helps. :)

--tobie

Re: Custom Elements: is=""

[Anne van Kesteren]

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 something we should fix in the design of .
That is="" can make certain hacks a little simpler is nice, but that's
not enough to justify standardizing it. I have the feeling we're going
in circles though, since the arguments on both sides have been made
repeatedly for the past x years.


-- 
https://annevankesteren.nl/

RE: Custom Elements: is=""

[Léonie Watson]

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

@LeonieWatson @PacielloGroup PacielloGroup.com

 

 

 

Re: Custom Elements: is=""

[Justin Fagnani]

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 extend the behavior of. "is=" syntax aside, I do agree extending
> complex native element prototypes in general has alot of associated
> undefined behavior. If "is=" is going to be dropped, we'll probably
> revert back to annotating these elements with special class names or
> data- attributes and avoid custom elements for these use cases.
>
> On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall  wrote:
> >
> > 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 v1. If developers start using custom elements where
> >> > they
> >> > would previously have used a native element, this could well result
> in a
> >> > regression in accessibility for the web as a whole for this period,
> and
> >> > we
> >> > will be stuck with the legacy of code written during this period for
> >> > much
> >> > longer as well.
> >>
> >> I don't see how it is a regression compared to the current situation.
> >
> >
> > Exactly: this describes the current situation, which I think is
> > unsatisfactory.
> >
> >> > - I realise that to some extent developers already aren't using native
> >> > elements, in part because of the styling issues we've discussed which
> >> > also
> >> > affect is=. My concern here is that custom elements will further
> >> > legitimise
> >> > this habit, which we've been making some recent progress in changing -
> >> > we
> >> > stand to backslide on that effort. Having is= would allow us to roll
> it
> >> > into
> >> > the "use native elements where possible" message rather than diluting
> it
> >> > with "unless you're using a custom element in which case here's a
> >> > checklist
> >> > which you're not going to look at of everything it should do" until we
> >> > come
> >> > up with an alternative.
> >>
> >> Most examples of custom elements to date are not actually with is="",
> >> simply because custom tag names are much more appealing. The
> >> ergonomics don't back up the message.
> >
> >
> > Polymer have a whole suite of elements which use is=:
> > https://elements.polymer-project.org/browse?package=gold-elements
> >
> > When you refer to "ergonomics", are you talking purely about the syntax?
> Or
> > about the set of issues involved in using native elements compared to
> (lower
> > case c) custom elements: essentially, whether or not you're ceding some
> > control over styling and behaviour to the browser?
> >
> >> > - 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
> >> > come up with something for v2, it will be even longer before it
> becomes
> >> > mainstream (and as I mentioned earlier we will still be stuck with
> code
> >> > written to v1 for much longer again).
> >>
> >> I don't see how it will be longer. is="" is not getting acceptance
> >> as-is. So all this would result in is not getting custom elements
> >> across browsers until v2 is done.
> >
> >
> > I think Dimitri responded to this better than I could.
> >
> >>
> >> > Here's where we differ, because:
> >> > - I don't think it's a wart. I've given this a great deal of thought
> and
> >> > I
> >> > keep ending up back at the current syntax when I try to think of
> >> > reasonable
> >> > alternatives, even assuming we could magically fix all the
> >> > implementation
> >> > issues with any alternative proposal.
> >>
> >> I think if we figured out how the behavior of current elements is
> >> composed and how to address the styling problem we'd be much closer to
> >> an agreement. And I think everyone agrees those need to be solved, so
> >> I'm a bit lost as to why we don't focus on those.
> >
> >
> > I agree that those problems need to be solved (in particular, the styling
> > issue also comes into play when using is=), but I think that these are
> > multiple pieces of the same puzzle.
> >
> > The primitives are critical for creating novel types of elements, which
> > won't be able to benefit from type extensions in any case. Styling is
> > critical for getting people to use native elements with or without type
> > extensions.
> >
> > Allowing developers to extend native types means that users benefit from
> not
> > relying on custom element developers who just want to create a button
> with
> > some fancy rendering (beyond what can be achieved using CSS alone), or
> > custom behaviour, r

Re: Custom Elements: is=""

[Joshua Peek]

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 "is=" is going to be dropped, we'll probably
revert back to annotating these elements with special class names or
data- attributes and avoid custom elements for these use cases.

On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall  wrote:
>
> 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 v1. If developers start using custom elements where
>> > they
>> > would previously have used a native element, this could well result in a
>> > regression in accessibility for the web as a whole for this period, and
>> > we
>> > will be stuck with the legacy of code written during this period for
>> > much
>> > longer as well.
>>
>> I don't see how it is a regression compared to the current situation.
>
>
> Exactly: this describes the current situation, which I think is
> unsatisfactory.
>
>> > - I realise that to some extent developers already aren't using native
>> > elements, in part because of the styling issues we've discussed which
>> > also
>> > affect is=. My concern here is that custom elements will further
>> > legitimise
>> > this habit, which we've been making some recent progress in changing -
>> > we
>> > stand to backslide on that effort. Having is= would allow us to roll it
>> > into
>> > the "use native elements where possible" message rather than diluting it
>> > with "unless you're using a custom element in which case here's a
>> > checklist
>> > which you're not going to look at of everything it should do" until we
>> > come
>> > up with an alternative.
>>
>> Most examples of custom elements to date are not actually with is="",
>> simply because custom tag names are much more appealing. The
>> ergonomics don't back up the message.
>
>
> Polymer have a whole suite of elements which use is=:
> https://elements.polymer-project.org/browse?package=gold-elements
>
> When you refer to "ergonomics", are you talking purely about the syntax? Or
> about the set of issues involved in using native elements compared to (lower
> case c) custom elements: essentially, whether or not you're ceding some
> control over styling and behaviour to the browser?
>
>> > - 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
>> > come up with something for v2, it will be even longer before it becomes
>> > mainstream (and as I mentioned earlier we will still be stuck with code
>> > written to v1 for much longer again).
>>
>> I don't see how it will be longer. is="" is not getting acceptance
>> as-is. So all this would result in is not getting custom elements
>> across browsers until v2 is done.
>
>
> I think Dimitri responded to this better than I could.
>
>>
>> > Here's where we differ, because:
>> > - I don't think it's a wart. I've given this a great deal of thought and
>> > I
>> > keep ending up back at the current syntax when I try to think of
>> > reasonable
>> > alternatives, even assuming we could magically fix all the
>> > implementation
>> > issues with any alternative proposal.
>>
>> I think if we figured out how the behavior of current elements is
>> composed and how to address the styling problem we'd be much closer to
>> an agreement. And I think everyone agrees those need to be solved, so
>> I'm a bit lost as to why we don't focus on those.
>
>
> I agree that those problems need to be solved (in particular, the styling
> issue also comes into play when using is=), but I think that these are
> multiple pieces of the same puzzle.
>
> The primitives are critical for creating novel types of elements, which
> won't be able to benefit from type extensions in any case. Styling is
> critical for getting people to use native elements with or without type
> extensions.
>
> Allowing developers to extend native types means that users benefit from not
> relying on custom element developers who just want to create a button with
> some fancy rendering (beyond what can be achieved using CSS alone), or
> custom behaviour, remembering to re-implement all of the accessibility
> affordances which are built in to an HTML button. It also means that
> developers benefit from not having to do the extra legwork for
> accessibility.
>
> We see time after time after time that accessibility is fighting an uphill
> battle because it isn't on developers' radars as a priority for v1. This
> causes constant regressions

Re: Custom Elements: is=""

[Alice Boxhall]

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 v1. If developers start using custom elements where
> they
> > would previously have used a native element, this could well result in a
> > regression in accessibility for the web as a whole for this period, and
> we
> > will be stuck with the legacy of code written during this period for much
> > longer as well.
>
> I don't see how it is a regression compared to the current situation.
>

Exactly: this describes the current situation, which I think is
unsatisfactory.

> - I realise that to some extent developers already aren't using native
> > elements, in part because of the styling issues we've discussed which
> also
> > affect is=. My concern here is that custom elements will further
> legitimise
> > this habit, which we've been making some recent progress in changing - we
> > stand to backslide on that effort. Having is= would allow us to roll it
> into
> > the "use native elements where possible" message rather than diluting it
> > with "unless you're using a custom element in which case here's a
> checklist
> > which you're not going to look at of everything it should do" until we
> come
> > up with an alternative.
>
> Most examples of custom elements to date are not actually with is="",
> simply because custom tag names are much more appealing. The
> ergonomics don't back up the message.
>

Polymer have a whole suite of elements which use is=:
https://elements.polymer-project.org/browse?package=gold-elements

When you refer to "ergonomics", are you talking purely about the syntax? Or
about the set of issues involved in using native elements compared to
(lower case c) custom elements: essentially, whether or not you're ceding
some control over styling and behaviour to the browser?

> - 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
> > come up with something for v2, it will be even longer before it becomes
> > mainstream (and as I mentioned earlier we will still be stuck with code
> > written to v1 for much longer again).
>
> I don't see how it will be longer. is="" is not getting acceptance
> as-is. So all this would result in is not getting custom elements
> across browsers until v2 is done.


I think Dimitri responded to this better than I could.


> > Here's where we differ, because:
> > - I don't think it's a wart. I've given this a great deal of thought and
> I
> > keep ending up back at the current syntax when I try to think of
> reasonable
> > alternatives, even assuming we could magically fix all the implementation
> > issues with any alternative proposal.
>
> I think if we figured out how the behavior of current elements is
> composed and how to address the styling problem we'd be much closer to
> an agreement. And I think everyone agrees those need to be solved, so
> I'm a bit lost as to why we don't focus on those.
>

I agree that those problems need to be solved (in particular, the styling
issue also comes into play when using is=), but I think that these are
multiple pieces of the same puzzle.

The primitives are critical for creating novel types of elements, which
won't be able to benefit from type extensions in any case. Styling is
critical for getting people to use native elements with or without type
extensions.

Allowing developers to extend native types means that *users* benefit from
not relying on custom element developers who just want to create a button
with some fancy rendering (beyond what can be achieved using CSS alone), or
custom behaviour, remembering to re-implement all of the accessibility
affordances which are built in to an HTML button. It also means that
*developers* benefit from not having to do the extra legwork for
accessibility.

We see time after time after time that accessibility is fighting an uphill
battle because it isn't on developers' radars as a priority for v1. This
causes constant regressions in functionality for people who rely on
assistive technology. The promise of the HTML platform is that it should be
accessible if we use the native elements as they were designed to be used.
Part of my day job is helping make sure that the browser I work on upholds
its part of that bargain.

You could argue that what we need is a way to wrap *all* of the
accessibility affordances of a button into a mix-in object; I really don't
see a much more efficient way to do that than extending a button element,
either in terms of creating the spec or in terms of using the object.

> - I don't think shipping in one browser is "nothing". People (both
> framework
> > authors and web page authors) are al

Re: Custom Elements: is=""

[Justin Fagnani]

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 (partly as a consequence) developers, so even if
we do
>> > come up with something for v2, it will be even longer before it becomes
>> > mainstream (and as I mentioned earlier we will still be stuck with code
>> > written to v1 for much longer again).
>>
>> I don't see how it will be longer. is="" is not getting acceptance
>> as-is. So all this would result in is not getting custom elements
>> across browsers until v2 is done.
>
>
> I sort of assumes that the reason for this discussion is to get everyone
on the same page regarding type extension and hope to arrive at better
acceptance.
>
> Arguing that something isn't getting acceptance when the purpose of
discussion is attempting to gain the said acceptance seems a bit circular.
>
> Other than that, please do continue this conversation! :)

I'll also note that a large fraction of Polymer elements and Polymer using
pages, thus a large fraction of existing custom elements and use, uses is=,
via  and 

Re: Custom Elements: is=""

[Dimitri Glazkov]

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
> > come up with something for v2, it will be even longer before it becomes
> > mainstream (and as I mentioned earlier we will still be stuck with code
> > written to v1 for much longer again).
>
> I don't see how it will be longer. is="" is not getting acceptance
> as-is. So all this would result in is not getting custom elements
> across browsers until v2 is done.
>

I sort of assumes that the reason for this discussion is to get everyone on
the same page regarding type extension and hope to arrive at better
acceptance.

Arguing that something isn't getting acceptance when the purpose of
discussion is attempting to gain the said acceptance seems a bit circular.

Other than that, please do continue this conversation! :)

:DG<

Re: Custom Elements: is=""

[Anne van Kesteren]

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 previously have used a native element, this could well result in a
> regression in accessibility for the web as a whole for this period, and we
> will be stuck with the legacy of code written during this period for much
> longer as well.

I don't see how it is a regression compared to the current situation.


> - I realise that to some extent developers already aren't using native
> elements, in part because of the styling issues we've discussed which also
> affect is=. My concern here is that custom elements will further legitimise
> this habit, which we've been making some recent progress in changing - we
> stand to backslide on that effort. Having is= would allow us to roll it into
> the "use native elements where possible" message rather than diluting it
> with "unless you're using a custom element in which case here's a checklist
> which you're not going to look at of everything it should do" until we come
> up with an alternative.

Most examples of custom elements to date are not actually with is="",
simply because custom tag names are much more appealing. The
ergonomics don't back up the message.


> - 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
> come up with something for v2, it will be even longer before it becomes
> mainstream (and as I mentioned earlier we will still be stuck with code
> written to v1 for much longer again).

I don't see how it will be longer. is="" is not getting acceptance
as-is. So all this would result in is not getting custom elements
across browsers until v2 is done.


> Here's where we differ, because:
> - I don't think it's a wart. I've given this a great deal of thought and I
> keep ending up back at the current syntax when I try to think of reasonable
> alternatives, even assuming we could magically fix all the implementation
> issues with any alternative proposal.

I think if we figured out how the behavior of current elements is
composed and how to address the styling problem we'd be much closer to
an agreement. And I think everyone agrees those need to be solved, so
I'm a bit lost as to why we don't focus on those.


> - I don't think shipping in one browser is "nothing". People (both framework
> authors and web page authors) are already writing code using is=.

Well, I disagree. E.g. Microsoft had a ton of features shipping in
Internet Explorer 5.0 that were used and never ended up as-is (or at
all) in other browsers. In the long run it's pretty close to
"nothing".


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Anne van Kesteren]

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

[Travis Leithead]

My current understanding of "is=" is a request for an implementation to 
"plug-in" a native element's backing behavior under a custom element name. This 
feature would otherwise not be available without is=, as custom elements are 
always generic by design.

As Dimitri has noted in the past, I think this feature nicely solves some 
accessibility gaps in the platform. It's not ideal, but I believe it is useful. 
I'm not wedded to the syntax or API for doing this though, and I'd welcome 
suggestions to improve it.


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 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 bunch 
>>>> of nested div's.  How does introducing custom elements make it worse?
>>>
>>> I believe the rest of my comment already addressed this.
>>
>> Sorry, I don't follow.
>>
>>>> >> - I realise that to some extent developers already aren't using native 
>>>> >> elements, in part because of the styling issues we've discussed which 
>>>> >> also affect is=. My concern here is that custom elements will further 
>>>> >> legitimise this habit, which we've been making some recent progress in 
>>>> >> changing - we stand to backslide on that effort. Having is= would allow 
>>>> >> us to roll it into the "use native elements where possible" message 
>>>> >> rather than diluting it with "unless you're using a custom element in 
>>>> >> which case here's a checklist which you're not going to look at of 
>>>> >> everything it should do" until we come up with an alternative.
>>>>
>>>> In the case of stylizing elements, it doesn't really matter if authors 
>>>> attach a shadow DOM on top of a builtin input element or to a div because 
>>>> as soon as the shadow DOM replaces the rendered contents, we can't make 
>>>> assumptions about how to expose that element to AT.
>>>
>>> That's simply not true at all. If someone replaces the rendered content of 
>>> a ``, we know that their intent is to create an element which is 
>>> semantically a button, and may even be rendered as a button in some cases. 
>>> Similarly for `` with a `type` attribute. This is no different to 
>>> using an ARIA role as far as assistive technology is concerned.
>>
>> Perhaps I should have said "we can't _always_ make assumptions about how to 
>> expose that element to AT."
>>
>> Consider creating a date picker in the time we haven't added type=date yet.  
>> Inside the shadow DOM of this color picker may contain various buttons and 
>> controls to move between months and pick a date.  Treating the entire 
>> control as a text field will provide a very poor user experience.
>
> Ah, I see what you're saying now, thanks for clarifying.
>
> In this case, the custom element author can add semantic markup inside Shadow 
> DOM just as the browser does for a date picker currently - no assumptions 
> need to be made, since even in the case of type extensions the Shadow DOM is 
> available to the accessibility tree. I don't think it will ever treat the 
> entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in 
buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set 
(text field) by UA in this case.  I'd say that's exactly the kind of "feature" 
that makes the Web platform annoying.

>> All the use cases I can think of that let UA can safely make assumptions 
>> about the ARIA role of the element involves tweaking the appearance, which 
>> is better served by better styling mechanisms for form controls.
>>
> I don't think it's an either/or question between is= and styling mechanisms 
> for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define 
semantics seems like the worst of the both worlds.

- R. Niwa

Re: Custom Elements: is=""

[Ryosuke Niwa]

> 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:
 Web developers are already writing their own "custom elements" as a bunch 
 of nested div's.  How does introducing custom elements make it worse?
>>> 
>>> I believe the rest of my comment already addressed this.
>> 
>> Sorry, I don't follow.
>> 
 >> - I realise that to some extent developers already aren't using native 
 >> elements, in part because of the styling issues we've discussed which 
 >> also affect is=. My concern here is that custom elements will further 
 >> legitimise this habit, which we've been making some recent progress in 
 >> changing - we stand to backslide on that effort. Having is= would allow 
 >> us to roll it into the "use native elements where possible" message 
 >> rather than diluting it with "unless you're using a custom element in 
 >> which case here's a checklist which you're not going to look at of 
 >> everything it should do" until we come up with an alternative.
 
 In the case of stylizing elements, it doesn't really matter if authors 
 attach a shadow DOM on top of a builtin input element or to a div because 
 as soon as the shadow DOM replaces the rendered contents, we can't make 
 assumptions about how to expose that element to AT.
>>> 
>>> That's simply not true at all. If someone replaces the rendered content of 
>>> a ``, we know that their intent is to create an element which is 
>>> semantically a button, and may even be rendered as a button in some cases. 
>>> Similarly for `` with a `type` attribute. This is no different to 
>>> using an ARIA role as far as assistive technology is concerned.
>> 
>> Perhaps I should have said "we can't _always_ make assumptions about how to 
>> expose that element to AT."
>> 
>> Consider creating a date picker in the time we haven't added type=date yet.  
>> Inside the shadow DOM of this color picker may contain various buttons and 
>> controls to move between months and pick a date.  Treating the entire 
>> control as a text field will provide a very poor user experience.
> 
> Ah, I see what you're saying now, thanks for clarifying.
> 
> In this case, the custom element author can add semantic markup inside Shadow 
> DOM just as the browser does for a date picker currently - no assumptions 
> need to be made, since even in the case of type extensions the Shadow DOM is 
> available to the accessibility tree. I don't think it will ever treat the 
> entire control as a text field.

If you're fine with that, why don't you just let authors just put ARIA role in 
buttons' shadow DOM as well?

It would also mean that the author must override the ARIA role implicitly set 
(text field) by UA in this case.  I'd say that's exactly the kind of "feature" 
that makes the Web platform annoying.

>> All the use cases I can think of that let UA can safely make assumptions 
>> about the ARIA role of the element involves tweaking the appearance, which 
>> is better served by better styling mechanisms for form controls.
>>  
> I don't think it's an either/or question between is= and styling mechanisms 
> for form controls. I actually think we need both.

Why?  Having authors use two completely different mechanisms to define 
semantics seems like the worst of the both worlds.

- R. Niwa

Re: Custom Elements: is=""

[Alice Boxhall]

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 bunch
>> of nested div's.  How does introducing custom elements make it worse?
>>
>
> I believe the rest of my comment already addressed this.
>
>
> Sorry, I don't follow.
>
> >> - I realise that to some extent developers already aren't using native
>> elements, in part because of the styling issues we've discussed which also
>> affect is=. My concern here is that custom elements will further legitimise
>> this habit, which we've been making some recent progress in changing - we
>> stand to backslide on that effort. Having is= would allow us to roll it
>> into the "use native elements where possible" message rather than diluting
>> it with "unless you're using a custom element in which case here's a
>> checklist which you're not going to look at of everything it should do"
>> until we come up with an alternative.
>>
>> In the case of stylizing elements, it doesn't really matter if authors
>> attach a shadow DOM on top of a builtin input element or to a div because
>> as soon as the shadow DOM replaces the rendered contents, we can't make
>> assumptions about how to expose that element to AT.
>>
>
> That's simply not true at all. If someone replaces the rendered content of
> a ``, we know that their intent is to create an element which is
> semantically a button, and may even be rendered as a button in some cases.
> Similarly for `` with a `type` attribute. This is no different to
> using an ARIA role as far as assistive technology is concerned.
>
>
> Perhaps I should have said "we can't _always_ make assumptions about how
> to expose that element to AT."
>
> Consider creating a date picker in the time we haven't added type=date
> yet.  Inside the shadow DOM of this color picker may contain various
> buttons and controls to move between months and pick a date.  Treating the
> entire control as a text field will provide a very poor user experience.
>

Ah, I see what you're saying now, thanks for clarifying.

In this case, the custom element author can add semantic markup inside
Shadow DOM just as the browser does for a date picker currently - no
assumptions need to be made, since even in the case of type extensions the
Shadow DOM is available to the accessibility tree. I don't think it will
ever treat the entire control as a text field.


> All the use cases I can think of that let UA can safely make assumptions
> about the ARIA role of the element involves tweaking the appearance, which
> is better served by better styling mechanisms for form controls.
>

I don't think it's an either/or question between is= and styling mechanisms
for form controls. I actually think we need both.

> >>> The way I look at this is that currently you have nothing, since only
>> >>> Chrome ships this. There's a chance to get three more browsers if you
>> >>> make some concessions on the warts. And then hopefully we can iterate
>> >>> from there in a more cooperative fashion.
>> >>
>> >> Here's where we differ, because:
>> >> - I don't think it's a wart. I've given this a great deal of thought
>> and I keep ending up back at the current syntax when I try to think of
>> reasonable alternatives, even assuming we could magically fix all the
>> implementation issues with any alternative proposal.
>>
>> FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly)
>> spec'ed.
>>
>
> Any chance you could go into more detail on that? What exactly is it you
> dislike about it?
>
>
> See our replies on the topic on public-webapps.  I don't have a time to
> collect all our replies or restate all the problems we have with is=
> syntax.  (Perhaps I should put up a document somewhere to reference since
> someone brings up the same question every six months or so, and I'm getting
> sick and tried to even say that I don't have a time to re-iterate the same
> points over and over...)
>

If you did have time to put together such a document at some point, it
would be much appreciated!

I do absolutely realise that it's important to address the existing
concerns, but I've been having a really hard time trying to figure out
exactly what those are. (It's also unfortunately really difficult to search
for 'is=' when search engines strip out punctuation from search terms.)

> >> - I don't think shipping in one browser is "nothing". People (both
>> framework authors and web page authors) are already writing code using is=.
>>
>> Some developers are always going to use a feature only implemented by a
>> single browser (ActiveX in Trident, NaCl in Chrome, current web components
>> implementation in Chrome). In fact, why would any browser vendor ship a
>> feature that's not going to be used by anyone? However, that doesn't mean
>> the feature will be stan

Re: Custom Elements: is=""

[Ryosuke Niwa]

> 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 bunch of 
>> nested div's.  How does introducing custom elements make it worse?
> 
> I believe the rest of my comment already addressed this.

Sorry, I don't follow.

>> >> - I realise that to some extent developers already aren't using native 
>> >> elements, in part because of the styling issues we've discussed which 
>> >> also affect is=. My concern here is that custom elements will further 
>> >> legitimise this habit, which we've been making some recent progress in 
>> >> changing - we stand to backslide on that effort. Having is= would allow 
>> >> us to roll it into the "use native elements where possible" message 
>> >> rather than diluting it with "unless you're using a custom element in 
>> >> which case here's a checklist which you're not going to look at of 
>> >> everything it should do" until we come up with an alternative.
>> 
>> In the case of stylizing elements, it doesn't really matter if authors 
>> attach a shadow DOM on top of a builtin input element or to a div because as 
>> soon as the shadow DOM replaces the rendered contents, we can't make 
>> assumptions about how to expose that element to AT.
> 
> That's simply not true at all. If someone replaces the rendered content of a 
> ``, we know that their intent is to create an element which is 
> semantically a button, and may even be rendered as a button in some cases. 
> Similarly for `` with a `type` attribute. This is no different to 
> using an ARIA role as far as assistive technology is concerned.

Perhaps I should have said "we can't _always_ make assumptions about how to 
expose that element to AT."

Consider creating a date picker in the time we haven't added type=date yet.  
Inside the shadow DOM of this color picker may contain various buttons and 
controls to move between months and pick a date.  Treating the entire control 
as a text field will provide a very poor user experience.

All the use cases I can think of that let UA can safely make assumptions about 
the ARIA role of the element involves tweaking the appearance, which is better 
served by better styling mechanisms for form controls.


> >>> The way I look at this is that currently you have nothing, since only
> >>> Chrome ships this. There's a chance to get three more browsers if you
> >>> make some concessions on the warts. And then hopefully we can iterate
> >>> from there in a more cooperative fashion.
> >>
> >> Here's where we differ, because:
> >> - I don't think it's a wart. I've given this a great deal of thought and I 
> >> keep ending up back at the current syntax when I try to think of 
> >> reasonable alternatives, even assuming we could magically fix all the 
> >> implementation issues with any alternative proposal.
> 
> FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) 
> spec'ed.
> 
> Any chance you could go into more detail on that? What exactly is it you 
> dislike about it?

See our replies on the topic on public-webapps.  I don't have a time to collect 
all our replies or restate all the problems we have with is= syntax.  (Perhaps 
I should put up a document somewhere to reference since someone brings up the 
same question every six months or so, and I'm getting sick and tried to even 
say that I don't have a time to re-iterate the same points over and over...)

>> >> - I don't think shipping in one browser is "nothing". People (both 
>> >> framework authors and web page authors) are already writing code using 
>> >> is=.
>> 
>> Some developers are always going to use a feature only implemented by a 
>> single browser (ActiveX in Trident, NaCl in Chrome, current web components 
>> implementation in Chrome). In fact, why would any browser vendor ship a 
>> feature that's not going to be used by anyone? However, that doesn't mean 
>> the feature will be standardized or adopted by other browser vendors.
> 
> No, but unlike the first two examples, this is a proposed web standard.

Well, not everything people propose as a standard becomes a standard.  When a 
proposed standard is rejected, however, people tend to come up with an 
alternative proposal to address those issues.  As far as is= syntax is 
concerned, I haven't heard of any proposals to "fix" it so as to address 
everyone's concerns.

If you're really passionate about this feature, I suggest you can go dig all 
the discussions we've had in the last three years and see if you can resolve 
all the concerns raised by various participants of the working group.  Now, 
some of those concerns we and others have raised may not be relevant, and they 
may have changed their positions and opinions on matters.  Regardless, I don't 
think keep saying you like (or that you think we ne

Re: Custom Elements: is=""

[Alice Boxhall]

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 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 to things - but I think it does have
> potential.
> >>> > I'd really like to be convinced that we either have a reasonable
> alternative
> >>> > solution, or that it's not worth worrying about.
> >>>
> >>> I think it is worth worrying about, but I don't think it's worth
> >>> holding up a minimal v1 of Custom Elements for. The way to get
> >>> agreement among all parties is to do less. And then take baby steps
> >>> from.
> >>
> >> I can definitely see that logic.
> >>
> >> My concerns with this in practice are:
> >>
> >> - 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 previously have used a native element, this could well result in
> a regression in accessibility for the web as a whole for this period, and
> we will be stuck with the legacy of code written during this period for
> much longer as well.
>
> Web developers are already writing their own "custom elements" as a bunch
> of nested div's.  How does introducing custom elements make it worse?
>

I believe the rest of my comment already addressed this.


> The argument that it'll make things worse between v1 and v2 is moot
> because we haven't agreed on anything. is= syntax may never be realized due
> to various issues associated with it.
>

This was in response to Anne's suggestion to "take baby steps". If this is
going to happen at all, I believe it needs to happen in V1 rather than
later, for the reasons I outlined.


> >> - I realise that to some extent developers already aren't using native
> elements, in part because of the styling issues we've discussed which also
> affect is=. My concern here is that custom elements will further legitimise
> this habit, which we've been making some recent progress in changing - we
> stand to backslide on that effort. Having is= would allow us to roll it
> into the "use native elements where possible" message rather than diluting
> it with "unless you're using a custom element in which case here's a
> checklist which you're not going to look at of everything it should do"
> until we come up with an alternative.
>
> In the case of stylizing elements, it doesn't really matter if authors
> attach a shadow DOM on top of a builtin input element or to a div because
> as soon as the shadow DOM replaces the rendered contents, we can't make
> assumptions about how to expose that element to AT.
>

That's simply not true at all. If someone replaces the rendered content of
a ``, we know that their intent is to create an element which is
semantically a button, and may even be rendered as a button in some cases.
Similarly for `` with a `type` attribute. This is no different to
using an ARIA role as far as assistive technology is concerned.


> >>> The way I look at this is that currently you have nothing, since only
> >>> Chrome ships this. There's a chance to get three more browsers if you
> >>> make some concessions on the warts. And then hopefully we can iterate
> >>> from there in a more cooperative fashion.
> >>
> >> Here's where we differ, because:
> >> - I don't think it's a wart. I've given this a great deal of thought
> and I keep ending up back at the current syntax when I try to think of
> reasonable alternatives, even assuming we could magically fix all the
> implementation issues with any alternative proposal.
>
> FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly)
> spec'ed.
>

Any chance you could go into more detail on that? What exactly is it you
dislike about it?


> >> - I don't think shipping in one browser is "nothing". People (both
> framework authors and web page authors) are already writing code using is=.
>
> Some developers are always going to use a feature only implemented by a
> single browser (ActiveX in Trident, NaCl in Chrome, current web components
> implementation in Chrome). In fact, why would any browser vendor ship a
> feature that's not going to be used by anyone? However, that doesn't mean
> the feature will be standardized or adopted by other browser vendors.
>

No, but unlike the first two examples, this is a proposed web standard.

Thanks,

Alice

Re: Custom Elements: is=""

[Ryosuke Niwa]

> 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, 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 to be convinced that we either have a reasonable 
>>> > alternative
>>> > solution, or that it's not worth worrying about.
>>> 
>>> I think it is worth worrying about, but I don't think it's worth
>>> holding up a minimal v1 of Custom Elements for. The way to get
>>> agreement among all parties is to do less. And then take baby steps
>>> from.
>> 
>> I can definitely see that logic.
>> 
>> My concerns with this in practice are:
>> 
>> - 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 previously have used a native element, this could well result in a 
>> regression in accessibility for the web as a whole for this period, and we 
>> will be stuck with the legacy of code written during this period for much 
>> longer as well.

Web developers are already writing their own "custom elements" as a bunch of 
nested div's.  How does introducing custom elements make it worse?

The argument that it'll make things worse between v1 and v2 is moot because we 
haven't agreed on anything. is= syntax may never be realized due to various 
issues associated with it.

>> - I realise that to some extent developers already aren't using native 
>> elements, in part because of the styling issues we've discussed which also 
>> affect is=. My concern here is that custom elements will further legitimise 
>> this habit, which we've been making some recent progress in changing - we 
>> stand to backslide on that effort. Having is= would allow us to roll it into 
>> the "use native elements where possible" message rather than diluting it 
>> with "unless you're using a custom element in which case here's a checklist 
>> which you're not going to look at of everything it should do" until we come 
>> up with an alternative.

In the case of stylizing elements, it doesn't really matter if authors attach a 
shadow DOM on top of a builtin input element or to a div because as soon as the 
shadow DOM replaces the rendered contents, we can't make assumptions about how 
to expose that element to AT.

>>> The way I look at this is that currently you have nothing, since only
>>> Chrome ships this. There's a chance to get three more browsers if you
>>> make some concessions on the warts. And then hopefully we can iterate
>>> from there in a more cooperative fashion.
>> 
>> Here's where we differ, because:
>> - I don't think it's a wart. I've given this a great deal of thought and I 
>> keep ending up back at the current syntax when I try to think of reasonable 
>> alternatives, even assuming we could magically fix all the implementation 
>> issues with any alternative proposal.

FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly) 
spec'ed.

>> - I don't think shipping in one browser is "nothing". People (both framework 
>> authors and web page authors) are already writing code using is=.

Some developers are always going to use a feature only implemented by a single 
browser (ActiveX in Trident, NaCl in Chrome, current web components 
implementation in Chrome). In fact, why would any browser vendor ship a feature 
that's not going to be used by anyone? However, that doesn't mean the feature 
will be standardized or adopted by other browser vendors.

- R. Niwa

Re: Custom Elements: is=""

[Justin Fagnani]

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

[Alice Boxhall]

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 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 to be convinced that we either have a reasonable
>> alternative
>> > solution, or that it's not worth worrying about.
>>
>> I think it is worth worrying about, but I don't think it's worth
>> holding up a minimal v1 of Custom Elements for. The way to get
>> agreement among all parties is to do less. And then take baby steps
>> from.
>>
>
> I can definitely see that logic.
>
> My concerns with this in practice are:
>
> - 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 previously have used a native element, this could well result in a
> regression in accessibility for the web as a whole for this period, and we
> will be stuck with the legacy of code written during this period for much
> longer as well.
>
> - I realise that to some extent developers already aren't using native
> elements, in part because of the styling issues we've discussed which also
> affect is=. My concern here is that custom elements will further legitimise
> this habit, which we've been making some recent progress in changing - we
> stand to backslide on that effort. Having is= would allow us to roll it
> into the "use native elements where possible" message rather than diluting
> it with "unless you're using a custom element in which case here's a
> checklist which you're not going to look at of everything it should do"
> until we come up with an alternative.
>
> - 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
> come up with something for v2, it will be even longer before it becomes
> mainstream (and as I mentioned earlier we will still be stuck with code
> written to v1 for much longer again).
>
>
>> The way I look at this is that currently you have nothing, since only
>> Chrome ships this. There's a chance to get three more browsers if you
>> make some concessions on the warts. And then hopefully we can iterate
>> from there in a more cooperative fashion.
>>
>
> Here's where we differ, because:
> - I don't think it's a wart. I've given this a great deal of thought and I
> keep ending up back at the current syntax when I try to think of reasonable
> alternatives, even assuming we could magically fix all the implementation
> issues with any alternative proposal.
> - I don't think shipping in one browser is "nothing". People (both
> framework authors and web page authors) are already writing code using is=.
>
>
>> (The thread Steve shared about ARIA seemed like an equivalent effort
>> by the way, to expose some of the semantics of native elements through
>> simple attributes.)
>>
>
> Thanks for the pointer - I followed up on that thread with some thoughts
> on that proposal.
>

Re: Custom Elements: is=""

[Alice Boxhall]

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 to things - but I think it does have
> potential.
> > I'd really like to be convinced that we either have a reasonable
> alternative
> > solution, or that it's not worth worrying about.
>
> I think it is worth worrying about, but I don't think it's worth
> holding up a minimal v1 of Custom Elements for. The way to get
> agreement among all parties is to do less. And then take baby steps
> from.
>

I can definitely see that logic.

My concerns with this in practice are:

- 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 previously have used a native element, this could well result in a
regression in accessibility for the web as a whole for this period, and we
will be stuck with the legacy of code written during this period for much
longer as well.

- I realise that to some extent developers already aren't using native
elements, in part because of the styling issues we've discussed which also
affect is=. My concern here is that custom elements will further legitimise
this habit, which we've been making some recent progress in changing - we
stand to backslide on that effort. Having is= would allow us to roll it
into the "use native elements where possible" message rather than diluting
it with "unless you're using a custom element in which case here's a
checklist which you're not going to look at of everything it should do"
until we come up with an alternative.

- 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
come up with something for v2, it will be even longer before it becomes
mainstream (and as I mentioned earlier we will still be stuck with code
written to v1 for much longer again).


> The way I look at this is that currently you have nothing, since only
> Chrome ships this. There's a chance to get three more browsers if you
> make some concessions on the warts. And then hopefully we can iterate
> from there in a more cooperative fashion.
>

Here's where we differ, because:
- I don't think it's a wart. I've given this a great deal of thought and I
keep ending up back at the current syntax when I try to think of reasonable
alternatives, even assuming we could magically fix all the implementation
issues with any alternative proposal.
- I don't think shipping in one browser is "nothing". People (both
framework authors and web page authors) are already writing code using is=.


> (The thread Steve shared about ARIA seemed like an equivalent effort
> by the way, to expose some of the semantics of native elements through
> simple attributes.)
>

Thanks for the pointer - I followed up on that thread with some thoughts on
that proposal.

RE: Custom Elements: is=""

[Domenic Denicola]

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 completely borked when it comes to classes and how it 
just treats { prototype } as an options object. I think there is wide agreement 
to fix that.

The solution that maintains the least delta from the current spec is outlined 
in https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0230.html, 
coupled with the work at https://github.com/domenic/element-constructors (see 
especially the registry). You could imagine other solutions that allow 
author-supplied constructors (instead of just inheriting the default behavior 
from HTMLElement and delegating to this.createdCallback() or 
this[Element.create]()) but those require running such author-supplied 
constructors during parsing and during cloning, which has its own issues.

RE: Custom Elements: is=""

[Travis Leithead]

Yes, I think you are understanding correctly, and it appears this would be a 
side-effect ☺. You have the same problem with two implementations of x-button 
though the pool of custom element names is going to be larger.

Do you think this will be a problem in practice?

From: Justin Fagnani [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 native element?

How would you express:

Me
You

-Justin

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead 
mailto: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 already laid to rest, but 
if subclassing native elements is a good compromise until we get to the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

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

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


> On May 6, 2015, at 6:25 AM, Anne van Kesteren 
> mailto:ann...@annevk.nl>> 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
> something we need to tackle low-level by figuring out how builtin
> elements work:
>
>  https://github.com/domenic/html-as-custom-elements
>
> And we need to tackle it high-level by making it easier to style
> builtin elements:
>
>  http://dev.w3.org/csswg/css-forms/
>
> And if the parser functionality provided by is="" is of great value,
> we should consider parsing elements with a hyphen in them differently.
> Similar to how 

Re: Custom Elements: is=""

[Elliott Sprehn]

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 already laid to rest,
> but if subclassing native elements is a good compromise until we get to the
> underlying behaviors that make up native HTML elements, why should we limit
> registerElement to hyphenated custom element names?
>

This doesn't work, the parser needs to allocate the right C++ object
associated with the tag name. There's no way to do upgrades if we allow you
register any tag name you want. It was also disliked by Hixie because it
encourages using up the namespace so then the spec would need to invent
weirder names to work around ones that were already in wide spread use.


>
> In other words, why not simplify by:
> 1. Allow any localName to be used by registerElement. (This would imply
> the HTML namespace by default; we can later add registerElementNS if needed
> :)
> 2.  Drop the 'extends' member from the ElementRegistrationOptions
> dictionary.
>
> With this simplification, serializing elements wouldn't include any sign
> that they are 'customized' in any way (as is done with 'is' today). I don't
> see this as a problem, since web devs today can already do this, but
> without the help of the parser.
>
> 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'.
>

I think this should probably throw if you inherit from the wrong thing.

- E

Re: Custom Elements: is=""

[Justin Fagnani]

On Fri, May 8, 2015 at 1:10 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Yes, I think you are understanding correctly, and it appears this would
> be a side-effect J. You have the same problem with two implementations of
> x-button though the pool of custom element names is going to be larger.
>
>
>
> Do you think this will be a problem in practice?
>

Definitely.

Custom element names will hopefully fall into self-organized namespaces,
for instance the Polymer team is putting out element collections, like
iron-* and paper-* and we very well might 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 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 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 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 the
> underlying behaviors that make up native HTML elements, why should we limit
> registerElement to hyphenated custom element names?
>
> In other words, why not simplify by:
> 1. Allow any localName to be used by registerElement. (This would imply
> the HTML namespace by default; we can later add registerElementNS if needed
> :)
> 2.  Drop the 'extends' member from the ElementRegistrationOptions
> dictionary.
>
> With this simplification, serializing elements wouldn't include any sign
> that they are 'customized' in any way (as is done with 'is' today). I don't
> see this as a problem, since web devs today can already do this, but
> without the help of the parser.
>
> 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'.
>
> If we drop support for 'is' in v1, then we can consider later bringing
> back subclassing in v2 without introducing 'extends' in the
> ElementRegistrationOptions or the 'is' attribute.
>
> If we opt to keep the feature, I'd like to see it simplified as described
> above.
>
> (In general: I'd also like to see a 'constructor' property added
> automatically to the prototype so that you can always get to the native
> constructor function from script even if you don't save the return value of
> registerElement.)
>
>
>
> > 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
> > something we need to tackle low-level by figuring out how builtin
> > elements work:
> >
> >  https://github.com/domenic/html-as-custom-elements
> >
> > And we need to tackle it high-level by making it easier to style
> > builtin elements:
> >
> >  http://dev.w3.org/csswg/css-forms/
> >
> > And if the parser functionality provided by is="" is of great value,
> > we should consider parsing elements with a hyphen in them differently.
> > Similar to how 

Re: Custom Elements: is=""

[Justin Fagnani]

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 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 the
> underlying behaviors that make up native HTML elements, why should we limit
> registerElement to hyphenated custom element names?
>
> In other words, why not simplify by:
> 1. Allow any localName to be used by registerElement. (This would imply
> the HTML namespace by default; we can later add registerElementNS if needed
> :)
> 2.  Drop the 'extends' member from the ElementRegistrationOptions
> dictionary.
>
> With this simplification, serializing elements wouldn't include any sign
> that they are 'customized' in any way (as is done with 'is' today). I don't
> see this as a problem, since web devs today can already do this, but
> without the help of the parser.
>
> 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'.
>
> If we drop support for 'is' in v1, then we can consider later bringing
> back subclassing in v2 without introducing 'extends' in the
> ElementRegistrationOptions or the 'is' attribute.
>
> If we opt to keep the feature, I'd like to see it simplified as described
> above.
>
> (In general: I'd also like to see a 'constructor' property added
> automatically to the prototype so that you can always get to the native
> constructor function from script even if you don't save the return value of
> registerElement.)
>
>
> > 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
> > something we need to tackle low-level by figuring out how builtin
> > elements work:
> >
> >  https://github.com/domenic/html-as-custom-elements
> >
> > And we need to tackle it high-level by making it easier to style
> > builtin elements:
> >
> >  http://dev.w3.org/csswg/css-forms/
> >
> > And if the parser functionality provided by is="" is of great value,
> > we should consider parsing elements with a hyphen in them differently.
> > Similar to how 

RE: Custom Elements: is=""

[Travis Leithead]

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 the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

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

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


> 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 
> something we need to tackle low-level by figuring out how builtin 
> elements work:
> 
>  https://github.com/domenic/html-as-custom-elements
> 
> And we need to tackle it high-level by making it easier to style 
> builtin elements:
> 
>  http://dev.w3.org/csswg/css-forms/
> 
> And if the parser functionality provided by is="" is of great value, 
> we should consider parsing elements with a hyphen in them differently.
> Similar to how 

Re: Custom Elements: is=""

[Anne van Kesteren]

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 to be convinced that we either have a reasonable alternative
> solution, or that it's not worth worrying about.

I think it is worth worrying about, but I don't think it's worth
holding up a minimal v1 of Custom Elements for. The way to get
agreement among all parties is to do less. And then take baby steps
from.

The way I look at this is that currently you have nothing, since only
Chrome ships this. There's a chance to get three more browsers if you
make some concessions on the warts. And then hopefully we can iterate
from there in a more cooperative fashion.

(The thread Steve shared about ARIA seemed like an equivalent effort
by the way, to expose some of the semantics of native elements through
simple attributes.)


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Dimitri Glazkov]

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/chromium_rietveld/new_static/common/cr-action.html
>
> https://chromium.googlesource.com/infra/infra/+/master/appengine/chromium_rietveld/new_static/common/cr-button.html
>
> where you want to hook into the focus, tab navigation, and action behavior
> in the browser. For example links unfocus in some browsers after unclicking
> them. We also don't have a facility to be focusable but not have a tab
> index currently.
>
>
> On Wed, May 6, 2015 at 9:59 AM, Alice Boxhall  wrote:
>
>>
>>
>> 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 there any information/detail about the proposed
>>> sub-classing feature available anywhere?
>>>
>>> It should fall out of figuring out HTML as Custom Elements. Apart from
>>> styling which I think we can solve independently to some extent that's
>>> the big elephant in the room.
>>>
>>
>> As I see it there are two problems which is= could conceivably solve,
>> which seem to be being conflated:
>> - providing access to capabilities which so far only native elements have
>> (roles not captured by ARIA, forms behaviour, etc)
>> - allowing re-use of the bundled complete set of behaviours captured in
>> each element in the platform (what is focusable, what keyboard interactions
>> work, what happens on mobile vs. desktop, what semantic values are exposed
>> - essentially everything required in the HTML specs for that particular
>> element)
>>
>> A solution to the first problem I agree should fall out of the HTML as
>> custom elements effort.
>>
>> The second is the one I'm more concerned about falling off the radar:
>> when using a native , you can be reasonably certain that it will
>> adhere to the HTML spec in behaviour; when using an , you only
>> have the reputation of the custom element vendor to give you any sort of
>> guarantee about behaviour, and it could regress at any time.
>>
>> 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 to be convinced that we either have a reasonable
>> alternative solution, or that it's not worth worrying about.
>>
>
>

Re: Custom Elements: is=""

[Ryosuke Niwa]

> 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
> something we need to tackle low-level by figuring out how builtin
> elements work:
> 
>  https://github.com/domenic/html-as-custom-elements
> 
> And we need to tackle it high-level by making it easier to style
> builtin elements:
> 
>  http://dev.w3.org/csswg/css-forms/
> 
> And if the parser functionality provided by is="" is of great value,
> we should consider parsing elements with a hyphen in them differently.
> Similar to how 

Re: Custom Elements: is=""

[Elliott Sprehn]

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/cr-button.html

where you want to hook into the focus, tab navigation, and action behavior
in the browser. For example links unfocus in some browsers after unclicking
them. We also don't have a facility to be focusable but not have a tab
index currently.


On Wed, May 6, 2015 at 9:59 AM, Alice Boxhall  wrote:

>
>
> 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 there any information/detail about the proposed
>> sub-classing feature available anywhere?
>>
>> It should fall out of figuring out HTML as Custom Elements. Apart from
>> styling which I think we can solve independently to some extent that's
>> the big elephant in the room.
>>
>
> As I see it there are two problems which is= could conceivably solve,
> which seem to be being conflated:
> - providing access to capabilities which so far only native elements have
> (roles not captured by ARIA, forms behaviour, etc)
> - allowing re-use of the bundled complete set of behaviours captured in
> each element in the platform (what is focusable, what keyboard interactions
> work, what happens on mobile vs. desktop, what semantic values are exposed
> - essentially everything required in the HTML specs for that particular
> element)
>
> A solution to the first problem I agree should fall out of the HTML as
> custom elements effort.
>
> The second is the one I'm more concerned about falling off the radar: when
> using a native , you can be reasonably certain that it will adhere
> to the HTML spec in behaviour; when using an , you only have the
> reputation of the custom element vendor to give you any sort of guarantee
> about behaviour, and it could regress at any time.
>
> 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 to be convinced that we either have a reasonable
> alternative solution, or that it's not worth worrying about.
>

Re: Custom Elements: is=""

[Alice Boxhall]

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 there any information/detail about the proposed
> sub-classing feature available anywhere?
>
> It should fall out of figuring out HTML as Custom Elements. Apart from
> styling which I think we can solve independently to some extent that's
> the big elephant in the room.
>

As I see it there are two problems which is= could conceivably solve, which
seem to be being conflated:
- providing access to capabilities which so far only native elements have
(roles not captured by ARIA, forms behaviour, etc)
- allowing re-use of the bundled complete set of behaviours captured in
each element in the platform (what is focusable, what keyboard interactions
work, what happens on mobile vs. desktop, what semantic values are exposed
- essentially everything required in the HTML specs for that particular
element)

A solution to the first problem I agree should fall out of the HTML as
custom elements effort.

The second is the one I'm more concerned about falling off the radar: when
using a native , you can be reasonably certain that it will adhere
to the HTML spec in behaviour; when using an , you only have the
reputation of the custom element vendor to give you any sort of guarantee
about behaviour, and it could regress at any time.

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 to be convinced that we either have a reasonable
alternative solution, or that it's not worth worrying about.

Re: Custom Elements: is=""

[Anne van Kesteren]

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 feature available anywhere?

It should fall out of figuring out HTML as Custom Elements. Apart from
styling which I think we can solve independently to some extent that's
the big elephant in the room.


-- 
https://annevankesteren.nl/

Re: Custom Elements: is=""

[Steve Faulkner]

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 don't quite understand
how sub-classing does not help accessibility, when in the cases of simple
controls that have added custom features, re-using a button or a checkbox
etc rather than buidling it from scratch appears to be useful for
accessibility and other reasons.

note: this is not an argument for is= :-)
--

Regards

SteveF
HTML 5.1 

RE: Custom Elements: is=""

[Léonie Watson]

> 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. Accessibility is something we need
> to tackle low-level by figuring out how builtin elements work:
> 
>   https://github.com/domenic/html-as-custom-elements

If we use ARIA to feed accessibility information into the examples in this 
project, we should end up with some useful blueprints.
 
> And we need to tackle it high-level by making it easier to style builtin
> elements:
> 
>   http://dev.w3.org/csswg/css-forms/
> 
> And if the parser functionality provided by is="" is of great value, we should
> consider parsing elements with a hyphen in them differently.
> Similar to how 

Custom Elements: is=""

[Anne van Kesteren]

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
something we need to tackle low-level by figuring out how builtin
elements work:

  https://github.com/domenic/html-as-custom-elements

And we need to tackle it high-level by making it easier to style
builtin elements:

  http://dev.w3.org/csswg/css-forms/

And if the parser functionality provided by is="" is of great value,
we should consider parsing elements with a hyphen in them differently.
Similar to how