subject:"RE\: Minimum viable custom elements"


> On Feb 4, 2015, at 11:26 AM, Alice Boxhall  wrote:
> 
> So a web page author would write
> 
> 
> and then the custom element would sprout an  with 
> the attribute values copied across?

No. The page author would write .

- R. Niwa

Re: Minimum viable custom elements

2015-02-04 Thread Steve Faulkner

On 4 February 2015 at 19:05, Alice Boxhall  wrote:

> So then how do we treat it as "fallback content" i.e. un-rendered, while
> allowing it to be accessible to to the AT layer?


I suggest as in the working canvas example i provided, it not only be
exposed AT but also to keyboard interaction, and that the content inside
can be targeted for relationships such as





sign up


--

Regards

SteveF
HTML 5.1

Re: Minimum viable custom elements

2015-02-04 Thread Alice Boxhall

So a web page author would write


and then the custom element would sprout an 
with the attribute values copied across? Then the web page author knows
nothing about the  element, so if they want to programmatically the
value of the custom element, they'd modify an attribute on it, rather than
the , right? So you'd have to keep them in sync regardless.

On Wed, Feb 4, 2015 at 11:14 AM, Ryosuke Niwa  wrote:

>
> On Feb 4, 2015, at 11:05 AM, Alice Boxhall  wrote:
>
> On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell  wrote:
>
>>
>> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall 
>> wrote:
>>
>>> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>>>

 On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
 wrote:

> Yeah, I had noted in that post that wrapping a native element with a
> custom element was an option - only drawback is that the markup isn't as
> terse (which is generally advertised as one of the selling points of 
> Custom
> Elements). But that doesn't seem like a deal breaker to me, if subclassing
> needs to be postponed.
>
> Chris
>
>
 As I pointed out ealier:

 

 

 seems like barely a ternseness savings worth discussing.


 Indeed.  Also, authors are used to the idea of including a fallback
 content inside an element after canvas and object elements and this fits
 well with their mental model.

>>>
>>> I'm just trying to get my head around this pattern. In this example,
>>> does the web page author or the custom element developer embed the input?
>>> And who is responsible for syncing the relevant attributes across? In
>>> reality, isn't this going to look more like
>>>
>>> 
>>> 
>>> 
>>>
>>> or as a slightly contrived example,
>>>
>>> 
>>> 
>>> 
>>>
>>> Or does the custom element get its state from the embedded element?
>>>
>>
>> the custom element uses its contents as input and, in the simplest sense,
>> just moves it or maps it during creation... In a more complicated world
>> with something more like shadow dom (a separate topic) it might be
>> 'projected'
>>
>
> It seems like it would have to be in the light DOM for things like labels,
> forms etc to work. So then how do we treat it as "fallback content" i.e.
> un-rendered, while allowing it to be accessible to to the AT layer?
>
>
> Since it's a fallback content, it would certainly be in the regular DOM
> even if we had shadow DOM.  FYI, this whole thread doesn't assume or
> preclude the existence of shadow DOM.  It is the responsibility for custom
> form elements users to put regular input elements inside them.
>
> - R. Niwa
>
>

Re: Minimum viable custom elements

> On Feb 4, 2015, at 11:11 AM, Chris Bateman  wrote:
> 
> Ugh, I forgot about that. Without subclassing -  terseness is a very minor 
> drawback, but remapping the interface is a big pain.

Could you give us a concrete use case in which remapping the interface is 
necessary or hard/impossible to do?

- R. Niwa

Re: Minimum viable custom elements


> On Feb 4, 2015, at 11:05 AM, Alice Boxhall  wrote:
> 
> On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell  > wrote:
> 
> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  > wrote:
> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  > wrote:
> 
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell > > wrote:
>> 
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman > > wrote:
>> Yeah, I had noted in that post that wrapping a native element with a custom 
>> element was an option - only drawback is that the markup isn't as terse 
>> (which is generally advertised as one of the selling points of Custom 
>> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
>> needs to be postponed.
>> 
>> Chris
>> 
>>  
>> As I pointed out ealier:
>>  
>> 
>> 
>> 
>> 
>> seems like barely a ternseness savings worth discussing.
> 
> Indeed.  Also, authors are used to the idea of including a fallback content 
> inside an element after canvas and object elements and this fits well with 
> their mental model.
> 
> I'm just trying to get my head around this pattern. In this example, does the 
> web page author or the custom element developer embed the input? And who is 
> responsible for syncing the relevant attributes across? In reality, isn't 
> this going to look more like
> 
> 
> 
> 
> 
> or as a slightly contrived example,
> 
> 
> 
> 
> 
> Or does the custom element get its state from the embedded element?
> 
> the custom element uses its contents as input and, in the simplest sense, 
> just moves it or maps it during creation... In a more complicated world with 
> something more like shadow dom (a separate topic) it might be 'projected'
> 
> It seems like it would have to be in the light DOM for things like labels, 
> forms etc to work. So then how do we treat it as "fallback content" i.e. 
> un-rendered, while allowing it to be accessible to to the AT layer?


Since it's a fallback content, it would certainly be in the regular DOM even if 
we had shadow DOM.  FYI, this whole thread doesn't assume or preclude the 
existence of shadow DOM.  It is the responsibility for custom form elements 
users to put regular input elements inside them.

- R. Niwa

Re: Minimum viable custom elements

2015-02-04 Thread Chris Bateman

Ugh, I forgot about that. Without subclassing -  terseness is a very minor 
drawback, but remapping the interface is a big pain.

On Wed, Feb 4, 2015 at 1:01 PM, Brian Kardell  wrote:

> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:
>> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>>
>>>
>>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>>
>>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>>> wrote:
>>>
 Yeah, I had noted in that post that wrapping a native element with a
 custom element was an option - only drawback is that the markup isn't as
 terse (which is generally advertised as one of the selling points of Custom
 Elements). But that doesn't seem like a deal breaker to me, if subclassing
 needs to be postponed.

 Chris


>>> As I pointed out ealier:
>>>
>>> 
>>>
>>> 
>>>
>>> seems like barely a ternseness savings worth discussing.
>>>
>>>
>>> Indeed.  Also, authors are used to the idea of including a fallback
>>> content inside an element after canvas and object elements and this fits
>>> well with their mental model.
>>>
>>
>> I'm just trying to get my head around this pattern. In this example, does
>> the web page author or the custom element developer embed the input? And
>> who is responsible for syncing the relevant attributes across? In reality,
>> isn't this going to look more like
>>
>> 
>> 
>> 
>>
>> or as a slightly contrived example,
>>
>> 
>> 
>> 
>>
>> Or does the custom element get its state from the embedded element?
>>
> the custom element uses its contents as input and, in the simplest sense,
> just moves it or maps it during creation... In a more complicated world
> with something more like shadow dom (a separate topic) it might be
> 'projected'
> -- 
> Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements


> On Feb 4, 2015, at 10:54 AM, Alice Boxhall  wrote:
> 
> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  > wrote:
> 
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell > > wrote:
>> 
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman > > wrote:
>> Yeah, I had noted in that post that wrapping a native element with a custom 
>> element was an option - only drawback is that the markup isn't as terse 
>> (which is generally advertised as one of the selling points of Custom 
>> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
>> needs to be postponed.
>> 
>> Chris
>> 
>>  
>> As I pointed out ealier:
>>  
>> 
>> 
>> 
>> 
>> seems like barely a ternseness savings worth discussing.
> 
> Indeed.  Also, authors are used to the idea of including a fallback content 
> inside an element after canvas and object elements and this fits well with 
> their mental model.
> 
> I'm just trying to get my head around this pattern. In this example, does the 
> web page author or the custom element developer embed the input? And who is 
> responsible for syncing the relevant attributes across? In reality, isn't 
> this going to look more like
> 
> 
> 
> 
> 
> or as a slightly contrived example,
> 
> 
> 
> 
> 
> Or does the custom element get its state from the embedded element?


I'd imagine that the better approach is for the custom element to pull values 
out of the fallback element so:




This is similar to how "picture" element sometimes uses the attribute values of 
the containing "img" element to choose the right image to show.

- R. Niwa

Re: Minimum viable custom elements

2015-02-04 Thread Alice Boxhall

On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell  wrote:

>
>
> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:
>
>> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>>
>>>
>>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>>
>>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>>> wrote:
>>>
 Yeah, I had noted in that post that wrapping a native element with a
 custom element was an option - only drawback is that the markup isn't as
 terse (which is generally advertised as one of the selling points of Custom
 Elements). But that doesn't seem like a deal breaker to me, if subclassing
 needs to be postponed.

 Chris


>>> As I pointed out ealier:
>>>
>>> 
>>>
>>> 
>>>
>>> seems like barely a ternseness savings worth discussing.
>>>
>>>
>>> Indeed.  Also, authors are used to the idea of including a fallback
>>> content inside an element after canvas and object elements and this fits
>>> well with their mental model.
>>>
>>
>> I'm just trying to get my head around this pattern. In this example, does
>> the web page author or the custom element developer embed the input? And
>> who is responsible for syncing the relevant attributes across? In reality,
>> isn't this going to look more like
>>
>> 
>> 
>> 
>>
>> or as a slightly contrived example,
>>
>> 
>> 
>> 
>>
>> Or does the custom element get its state from the embedded element?
>>
>
> the custom element uses its contents as input and, in the simplest sense,
> just moves it or maps it during creation... In a more complicated world
> with something more like shadow dom (a separate topic) it might be
> 'projected'
>

It seems like it would have to be in the light DOM for things like labels,
forms etc to work. So then how do we treat it as "fallback content" i.e.
un-rendered, while allowing it to be accessible to to the AT layer?

Re: Minimum viable custom elements

2015-02-04 Thread Brian Kardell

On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall  wrote:

> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:
>
>>
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>>
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
>> wrote:
>>
>>> Yeah, I had noted in that post that wrapping a native element with a
>>> custom element was an option - only drawback is that the markup isn't as
>>> terse (which is generally advertised as one of the selling points of Custom
>>> Elements). But that doesn't seem like a deal breaker to me, if subclassing
>>> needs to be postponed.
>>>
>>> Chris
>>>
>>>
>> As I pointed out ealier:
>>
>> 
>>
>> 
>>
>> seems like barely a ternseness savings worth discussing.
>>
>>
>> Indeed.  Also, authors are used to the idea of including a fallback
>> content inside an element after canvas and object elements and this fits
>> well with their mental model.
>>
>
> I'm just trying to get my head around this pattern. In this example, does
> the web page author or the custom element developer embed the input? And
> who is responsible for syncing the relevant attributes across? In reality,
> isn't this going to look more like
>
> 
> 
> 
>
> or as a slightly contrived example,
>
> 
> 
> 
>
> Or does the custom element get its state from the embedded element?
>

the custom element uses its contents as input and, in the simplest sense,
just moves it or maps it during creation... In a more complicated world
with something more like shadow dom (a separate topic) it might be
'projected'

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

2015-02-04 Thread Alice Boxhall

On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa  wrote:

>
> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
>
> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman 
> wrote:
>
>> Yeah, I had noted in that post that wrapping a native element with a
>> custom element was an option - only drawback is that the markup isn't as
>> terse (which is generally advertised as one of the selling points of Custom
>> Elements). But that doesn't seem like a deal breaker to me, if subclassing
>> needs to be postponed.
>>
>> Chris
>>
>>
> As I pointed out ealier:
>
> 
>
> 
>
> seems like barely a ternseness savings worth discussing.
>
>
> Indeed.  Also, authors are used to the idea of including a fallback
> content inside an element after canvas and object elements and this fits
> well with their mental model.
>

I'm just trying to get my head around this pattern. In this example, does
the web page author or the custom element developer embed the input? And
who is responsible for syncing the relevant attributes across? In reality,
isn't this going to look more like

or as a slightly contrived example,

Or does the custom element get its state from the embedded element?

Re: Minimum viable custom elements


> On Feb 4, 2015, at 10:12 AM, Brian Kardell  wrote:
> 
> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman  > wrote:
> Yeah, I had noted in that post that wrapping a native element with a custom 
> element was an option - only drawback is that the markup isn't as terse 
> (which is generally advertised as one of the selling points of Custom 
> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
> needs to be postponed.
> 
> Chris
> 
>  
> As I pointed out ealier:
>  
> 
> 
> 
> 
> seems like barely a ternseness savings worth discussing.

Indeed.  Also, authors are used to the idea of including a fallback content 
inside an element after canvas and object elements and this fits well with 
their mental model.

- R. Niwa

Re: Minimum viable custom elements


> On Feb 4, 2015, at 9:05 AM, Steve Faulkner  wrote:
> 
> On 4 February 2015 at 16:51, Ryosuke Niwa  > wrote:
> 
> 
> I think if this worked. i.e. hid the styling and allowed styling over top, 
> while allowing access to the input functionality would be a good solution for 
> the many many instances of native controls being remade as custom controls 
> simply to be able to control style.
> 
> I made a simple example of using  to host a checkbox, as an 
> experiment:
> http://codepen.io/stevef/pen/OPxvZX 
> 
> note: am not saying  is a solution, like is= it provides the ability 
> to make use of built in features of native controls. which is the outcome I 
> would like to see baked into web components.


Right.  As I mentioned earlier, shadow DOM or decorator is what provides the 
styling-over-top capability.  And I assure you, Anne and everyone else at each 
browser vendor is interested in solving that problem.

> On Feb 4, 2015, at 9:41 AM, Chris Bateman  wrote:
> 
> Yeah, I had noted in that post that wrapping a native element with a custom 
> element was an option - only drawback is that the markup isn't as terse 
> (which is generally advertised as one of the selling points of Custom 
> Elements). But that doesn't seem like a deal breaker to me, if subclassing 
> needs to be postponed.

Great to hear!  We should make sure custom elements accommodates this 
composition pattern then.

- R. Niwa

Re: Minimum viable custom elements

2015-02-04 Thread Brian Kardell

On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman  wrote:

> Yeah, I had noted in that post that wrapping a native element with a
> custom element was an option - only drawback is that the markup isn't as
> terse (which is generally advertised as one of the selling points of Custom
> Elements). But that doesn't seem like a deal breaker to me, if subclassing
> needs to be postponed.
>
> Chris
>
>
As I pointed out ealier:





seems like barely a ternseness savings worth discussing.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

2015-02-04 Thread Chris Bateman

Yeah, I had noted in that post that wrapping a native element with a custom 
element was an option - only drawback is that the markup isn't as terse (which 
is generally advertised as one of the selling points of Custom Elements). But 
that doesn't seem like a deal breaker to me, if subclassing needs to be 
postponed.




Chris

On Wed, Feb 4, 2015 at 10:51 AM, Ryosuke Niwa  wrote:

> See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
>  
> first.
>> On Feb 4, 2015, at 6:43 AM, Chris Bateman  wrote:
>> 
>> Assuming a situation where a native element – with custom functionality – is 
>> dynamically injected into the page, the basic options I can think of are:
>> 
>>  - 
>>  -  and a page-level listener
>>  -  and call a function after it's 
>> injected
> Or .  Note that the author 
> of the custom element can force the markup to have an input element inside by 
> making the element not function when there isn't one on the contrary to what 
> you said in 
> https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0410.html 
>   
> Since custom elements aren't supported by all browsers initially, authors 
> have to implement the fallback anyway.
>> I'm not certain having two different mechanisms, namely "type" and "is" 
>> attributes, to specify the type of an input an element expects is a 
>> desirable approach.
>> 
>> 
>> 
>> I certainly can't speak to your perspective on this, and you may be right. 
>> An input's probably not be the best example for making is="" look good. 
>> Regardless, I have to trust that devs are smart enough to figure out what's 
>> going on here, and set it up properly.
> I'd say that line of thought could be dangerous in that once we say we should 
> trust devs to the right thing, we may just say devs should do the right thing 
> for accessibility for themselves.  Since the point of Web components is to 
> improve developer ergonomics, I don't think we should assume developers to be 
> particularly "smart" or "experienced".  We want to make the Web a place where 
> everyone can start writing great apps without knowing some weird quirks of 
> the platform.
> - R. Niwa

Re: Minimum viable custom elements

2015-02-04 Thread Steve Faulkner

On 4 February 2015 at 16:51, Ryosuke Niwa  wrote:

> 
>

I think if this worked. i.e. hid the styling and allowed styling over top,
while allowing access to the input functionality would be a good solution
for the many many instances of native controls being remade as custom
controls simply to be able to control style.

I made a simple example of using  to host a checkbox, as an
experiment:
http://codepen.io/stevef/pen/OPxvZX

note: am not saying  is a solution, like is= it provides the
ability to make use of built in features of native controls. which is the
outcome I would like to see baked into web components.
--

Regards

SteveF
HTML 5.1

Re: Minimum viable custom elements

See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 

first.

> On Feb 4, 2015, at 6:43 AM, Chris Bateman  wrote:
> 
> Assuming a situation where a native element – with custom functionality – is 
> dynamically injected into the page, the basic options I can think of are:
> 
>  - 
>  -  and a page-level listener
>  -  and call a function after it's injected

Or .  Note that the author of 
the custom element can force the markup to have an input element inside by 
making the element not function when there isn't one on the contrary to what 
you said in 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0410.html 

Since custom elements aren't supported by all browsers initially, authors have 
to implement the fallback anyway.

> I'm not certain having two different mechanisms, namely "type" and "is" 
> attributes, to specify the type of an input an element expects is a desirable 
> approach.
> 
> 
> 
> I certainly can't speak to your perspective on this, and you may be right. An 
> input's probably not be the best example for making is="" look good. 
> Regardless, I have to trust that devs are smart enough to figure out what's 
> going on here, and set it up properly.

I'd say that line of thought could be dangerous in that once we say we should 
trust devs to the right thing, we may just say devs should do the right thing 
for accessibility for themselves.  Since the point of Web components is to 
improve developer ergonomics, I don't think we should assume developers to be 
particularly "smart" or "experienced".  We want to make the Web a place where 
everyone can start writing great apps without knowing some weird quirks of the 
platform.

- R. Niwa

Re: Minimum viable custom elements

> On Feb 4, 2015, at 7:59 AM, Domenic Denicola  wrote:
> 
> In IRC Anne and I were briefly discussing how type="" is the is="" of Web 
> Applications 1.0. That is,  is similar to  
> or similar---it has a reasonable fallback behavior, but in reality it is a 
> completely different control than the local name indicates.
> 
> For  this is accomplished with an ever-growing base class with an 
> internal mode switch that makes its various properties/methods meaningful, 
> whereas for is="" you get a tidier inheritance hierarchy with the applicable 
> properties and methods confined to the specific element and not impacting all 
> others with the same local name. I.e., is="" is type="" done right.

While disallowing the type of an element to be changed after the fact as done 
in "is" attribute is a step forward, it's not the only problem "type" attribute 
poses.  The biggest problem with "type" attribute is not that it shares the 
same interface across all types but that it violates the fundamental design 
principle of SGML/XML languages: the name of an element uniquely identifies its 
semantics.

> The fact that type="" exists and doesn't fit with the is="" paradigm is 
> unfortunate. But I don't think we'd be better off trying to somehow 
> generalize the type="" paradigm, or pretend it is any good.

I agree "type" attribute is bad but that doesn't make "is" attribute any better.

> What is our advice to authors, then---they should modify 
> HTMLImgElement.prototype with x-gif-related properties and methods, that only 
> work if type="x-gif" is present? That seems to be the road that this thread 
> is heading down.

This is precisely why we shouldn't be introducing "is" attribute.  Changing the 
interface of an element based on a pretense of an attribute is extremely weird. 
 That's like a class changing its concrete class at runtime based on the value 
of its member variable.

> You could imagine plans to try to rationalize type="" on top of is="" (or, 
> perhaps better, deprecate  in favor of  or 
> something). But those seem pretty speculative.

"is" can't rationalize "type" because Web compatibility requires that authors 
can change "type" at any time.

- R. Niwa

RE: Minimum viable custom elements

2015-02-04 Thread Domenic Denicola

I hope others can address the question of why custom element callbacks are 
useful, and meet the bar of being a feature we should add to the web platform 
(with all the UA-coordination that requires). I just wanted to interject into 
this  discussion.

In IRC Anne and I were briefly discussing how type="" is the is="" of Web 
Applications 1.0. That is,  is similar to  
or similar---it has a reasonable fallback behavior, but in reality it is a 
completely different control than the local name indicates.

For  this is accomplished with an ever-growing base class with an 
internal mode switch that makes its various properties/methods meaningful, 
whereas for is="" you get a tidier inheritance hierarchy with the applicable 
properties and methods confined to the specific element and not impacting all 
others with the same local name. I.e., is="" is type="" done right.

The fact that type="" exists and doesn't fit with the is="" paradigm is 
unfortunate. But I don't think we'd be better off trying to somehow generalize 
the type="" paradigm, or pretend it is any good. What is our advice to authors, 
then---they should modify HTMLImgElement.prototype with x-gif-related 
properties and methods, that only work if type="x-gif" is present? That seems 
to be the road that this thread is heading down.

You could imagine plans to try to rationalize type="" on top of is="" (or, 
perhaps better, deprecate  in favor of  or 
something). But those seem pretty speculative.

Re: Minimum viable custom elements

2015-02-04 Thread Anne van Kesteren

On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman  wrote:
> An better example of both A and B (than my previous hypothetical) might be
> GitHub's  extension:
> https://github.com/github/time-elements/.

FWIW, I do want subclassing of builtins to work. Maybe not necessarily
at first, but definitely down the line. I just think it would be much
better if that could be .

A problem with this is styling. It seems
https://tabatkins.github.io/specs/css-extend-rule/ offers a way out
there:

  relative-time { @extend time }

Another problem are the logic checks in the implementation, typically
branched on localName. There's two solutions for these:

1. Change localName identity checks with "ignore global instanceof" checks.

2. Reimplement the various features elements have (focus, form
submission, a11y) as protocols that can be inherited.

Although 1) is fairly expensive as bz said various times so far, it's
probably more doable than 2) short term.

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-02-04 Thread Chris Bateman

Assuming a situation where a native element – with custom functionality –
is dynamically injected into the page, the basic options I can think of are:

 - 
 -  and a page-level listener
 -  and call a function after it's
injected

Option 3 is really cumbersome, in my opinion. Option 2 could work, except
for A. when I want to execute some functionality right away, and B. when
the native element won't be sending events to hook onto.

An better example of both A and B (than my previous hypothetical) might be
GitHub's  extension:
https://github.com/github/time-elements/.


I'm not certain having two different mechanisms, namely "type" and "is"
> attributes, to specify the type of an input an element expects is a
> desirable approach.




I certainly can't speak to your perspective on this, and you may be right.
An input's probably not be the best example for making is="" look good.
Regardless, I have to trust that devs are smart enough to figure out what's
going on here, and set it up properly.

Chris



On Tue, Feb 3, 2015 at 2:04 PM, Ryosuke Niwa  wrote:

>
> On Feb 3, 2015, at 7:13 AM, Chris Bateman  wrote:
>
> Why don't we just make all input elements support these new attributes
>> we're adding?
>
>
> In my opinion, I'd say because you can't possibly cover every case - what
> about doing the same kind of formatting for social security numbers, credit
> card numbers, phone numbers, or who knows what else? How about other kinds
> of functionality - like a  that automatically resizes itself?
>
>
> That sounds like a slightly different use case. Social security number,
> credit card number, etc… seems like a different input type to me while
> "numerals" or "radix" attributes are extra configurations/options each
> input type may respect.  While I agree allowing author defined input types
> will be useful, I'm not certain having two different mechanisms, namely
> "type" and "is" attributes, to specify the type of an input an element
> expects is a desirable approach.
>
> What kind of initializations does it have to do?
>
>
> Yes, probably just adding a listener in this case – which you certainly
> could handle with event delegation. But maybe someone might want to simply
> execute some functionality when the element is created or attached. An
> input that automatically populates itself with a random number. An awful,
> contrived example for sure - but it wouldn't be possible with delegation
> alone.
>
> Again - simply wanted to make the point that devs do add functionality to
> native elements - so it might be handy to have custom element callbacks to
> assist with it.
>
>
> That sounds rather hypothetical to me.  I would like to know a concrete
> use case in which the initialization of an author defined input type or an
> input configuration/option is impossible or too cumbersome to be
> implemented using existing API.
>
> Adding a new feature to the Web platform incurs an inherently higher cost
> because multiple vendors have to coordinate, and removing or changing the
> behavior of a feature is virtually impossible.
>
> - R. Niwa
>
>

Re: Minimum viable custom elements

2015-02-03 Thread Ryosuke Niwa

> On Feb 3, 2015, at 7:13 AM, Chris Bateman  wrote:
> 
> Why don't we just make all input elements support these new attributes we're 
> adding?
> 
> In my opinion, I'd say because you can't possibly cover every case - what 
> about doing the same kind of formatting for social security numbers, credit 
> card numbers, phone numbers, or who knows what else? How about other kinds of 
> functionality - like a  that automatically resizes itself?

That sounds like a slightly different use case. Social security number, credit 
card number, etc… seems like a different input type to me while "numerals" or 
"radix" attributes are extra configurations/options each input type may 
respect.  While I agree allowing author defined input types will be useful, I'm 
not certain having two different mechanisms, namely "type" and "is" attributes, 
to specify the type of an input an element expects is a desirable approach.

> What kind of initializations does it have to do? 
> 
> Yes, probably just adding a listener in this case – which you certainly could 
> handle with event delegation. But maybe someone might want to simply execute 
> some functionality when the element is created or attached. An input that 
> automatically populates itself with a random number. An awful, contrived 
> example for sure - but it wouldn't be possible with delegation alone.
> 
> Again - simply wanted to make the point that devs do add functionality to 
> native elements - so it might be handy to have custom element callbacks to 
> assist with it.

That sounds rather hypothetical to me.  I would like to know a concrete use 
case in which the initialization of an author defined input type or an input 
configuration/option is impossible or too cumbersome to be implemented using 
existing API.

Adding a new feature to the Web platform incurs an inherently higher cost 
because multiple vendors have to coordinate, and removing or changing the 
behavior of a feature is virtually impossible.

- R. Niwa

Re: Minimum viable custom elements

2015-02-03 Thread Chris Bateman

>
> Why don't we just make all input elements support these new attributes
> we're adding?


In my opinion, I'd say because you can't possibly cover every case - what
about doing the same kind of formatting for social security numbers, credit
card numbers, phone numbers, or who knows what else? How about other kinds
of functionality - like a  that automatically resizes itself?

What kind of initializations does it have to do?


Yes, probably just adding a listener in this case – which you certainly
could handle with event delegation. But maybe someone might want to simply
execute some functionality when the element is created or attached. An
input that automatically populates itself with a random number. An awful,
contrived example for sure - but it wouldn't be possible with delegation
alone.

Again - simply wanted to make the point that devs do add functionality to
native elements - so it might be handy to have custom element callbacks to
assist with it.

Chris



On Mon, Feb 2, 2015 at 9:40 PM, Ryosuke Niwa  wrote:

>
> On Jan 31, 2015, at 10:40 AM, Chris Bateman  wrote:
>
> The -webkit-appreance CSS is definitely another issue, so here's an
> example with just JS behavior:
>
> 
>
> This component would only allow numeric input, and insert decimals,
> commas, etc. Let's just assume that devs want to do this kind of thing.
> Here's an example I found of a such behavior:
> http://opensource.teamdf.com/number/examples/demo-as-you-type.html
>
>
> Thanks for a great use case.  I think this is a problem we should solve
> one way or another but I’m not convinced custom elements is the best
> solution for the problem at hand.
>
> If we accept that being able to specify the number of decimal points is a
> valid use case, I hope we can all agree that being able to specify the
> radix or the base of the number is also a valid use case.  Suppose we
> authors should be able to specify this with attribute "radix" where its
> value is any natural number between 1 and 15.  If we follow the school of
> thought in your proposal, then we would either add
> is="number-with-radix-input" (case A) or make "number-input" support both
> support "decimals" and "radix" attributes (case B).
>
> Case A: In this case, we quickly run into a combinatorial explosion.  As
> we add k new attributes to support, we would need 2^k elements in order to
> support every combination.  But this is silly because it's okay for authors
> to not use attributes supported by an element.  This brings us to case B.
>
> Case B: If we accept that we should create a single element that supports
> all extensions, then why do we use "is" attribute at all?  Why don't we
> just make all input elements support these new attributes we're adding?
>
> The best thing you get from using a Custom Element here is the component's
> ability to automatically initialize (and destroy) itself. If it's inserted
> into the page dynamically (via AJAX, templates in a SPA, or whatever), it
> just sets itself up.
>
>
> What kind of initializations does it have to do?  It seems like all the
> component has to do is to listen to the event listener, in addition to
> potentially sanitizing the value  if the original value had more than two
> decimal points.
>
> If JS fails, you've still got an input. It was succinct and easy to set
> up. And if the app wants to get or set the value, it just does it the same
> way it always interfaces with an input.
>
>
> Indeed the fallback scenario is very interesting here but again, it seems
> like there is no reason to use "is" attribute at all.  We can just extend
> all input elements by attaching event listeners, etc...
>
> - R. Niwa
>
>

Re: Minimum viable custom elements

2015-02-02 Thread Ryosuke Niwa

> On Jan 31, 2015, at 10:40 AM, Chris Bateman  wrote:
> 
> The -webkit-appreance CSS is definitely another issue, so here's an example 
> with just JS behavior:
> 
> 
> 
> This component would only allow numeric input, and insert decimals, commas, 
> etc. Let's just assume that devs want to do this kind of thing. Here's an 
> example I found of a such behavior: 
> http://opensource.teamdf.com/number/examples/demo-as-you-type.html 
> 
Thanks for a great use case.  I think this is a problem we should solve one way 
or another but I’m not convinced custom elements is the best solution for the 
problem at hand.

If we accept that being able to specify the number of decimal points is a valid 
use case, I hope we can all agree that being able to specify the radix or the 
base of the number is also a valid use case.  Suppose we authors should be able 
to specify this with attribute "radix" where its value is any natural number 
between 1 and 15.  If we follow the school of thought in your proposal, then we 
would either add is="number-with-radix-input" (case A) or make "number-input" 
support both support "decimals" and "radix" attributes (case B).

Case A: In this case, we quickly run into a combinatorial explosion.  As we add 
k new attributes to support, we would need 2^k elements in order to support 
every combination.  But this is silly because it's okay for authors to not use 
attributes supported by an element.  This brings us to case B.

Case B: If we accept that we should create a single element that supports all 
extensions, then why do we use "is" attribute at all?  Why don't we just make 
all input elements support these new attributes we're adding?

> The best thing you get from using a Custom Element here is the component's 
> ability to automatically initialize (and destroy) itself. If it's inserted 
> into the page dynamically (via AJAX, templates in a SPA, or whatever), it 
> just sets itself up.

What kind of initializations does it have to do?  It seems like all the 
component has to do is to listen to the event listener, in addition to 
potentially sanitizing the value  if the original value had more than two 
decimal points.

> If JS fails, you've still got an input. It was succinct and easy to set up. 
> And if the app wants to get or set the value, it just does it the same way it 
> always interfaces with an input.

Indeed the fallback scenario is very interesting here but again, it seems like 
there is no reason to use "is" attribute at all.  We can just extend all input 
elements by attaching event listeners, etc...

- R. Niwa

Re: Minimum viable custom elements

2015-02-02 Thread Chris Bateman

The -webkit-appreance CSS is definitely another issue, so here's an example
with just JS behavior:

This component would only allow numeric input, and insert decimals, commas,
etc. Let's just assume that devs want to do this kind of thing. Here's an
example I found of a such behavior:
http://opensource.teamdf.com/number/examples/demo-as-you-type.html

The best thing you get from using a Custom Element here is the component's
ability to automatically initialize (and destroy) itself. If it's inserted
into the page dynamically (via AJAX, templates in a SPA, or whatever), it
just sets itself up. If JS fails, you've still got an input. It was
succinct and easy to set up. And if the app wants to get or set the value,
it just does it the same way it always interfaces with an input.

Alternative 1: no Custom Element:

The downside here is that there's no automatic initialization/destruction.
Which is ok if the element is never dynamically inserted, but not so great
when it is - you're going to have to call a function to initialize it.

Alternative 2: regular Custom Element:

When this thing initializes, let's say it adds a native  as a child
(or in a shadow root), so that it doesn't have to manually add all the
necessary accessibility items Steve has pointed out. Of course, you get
nothing if JS fails. As a backup, you could certainly ask page authors to
add the  themselves - but that's starting to defeat the goal of
having simple declarative custom elements (if that is indeed a goal). Maybe
it wouldn't be the end of the world though:

Brian also mentioned the possibility of server-side rendering of the
createdCallback, but that certainly won't be feasible for everyone's
server-side environments.

Additionally - you'll need to create an API on the  so the
app can get and set the value. Of course you'd be doing this anyhow with
any regular Custom Element - but it'd be nice to skip if you could.

Anyhow - point is just that I see value in the ability to add Custom
Element callbacks to native elements. Thanks for all your work on
everything here!

Chris Bateman

On Fri, Jan 30, 2015 at 10:46 AM, Anne van Kesteren 
wrote:

> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
>  wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html
> > (which has been referenced several times in this thread, but no one has
> > critiqued to my knowledge) all of the above are evident, while at the
> same
> > time appearing to overcome the issue of standard control fugliness
>
> The only way it overcomes that is by relying on a proprietary
> extension called -webkit-appearance that is not standardized and does
> not work reliably across browsers. Furthermore, it's not at all clear
> to me why that example needs custom elements to begin with. If we
> assume this proprietary extension exists, we can just do this:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
>
> Which is much much simpler and requires none of the HTML imports,
> shadow tree, and all that script. It's also fully accessible and
> backwards compatible to the same extent. And shows that the real
> tidbit here is -webkit-appearance and not custom elements at all.
>
> (For identical styling you need to move the background-image line into
> a distinct input:checked selector block. I messed up a bit with copy
> and pasting.)
>
>
> --
> https://annevankesteren.nl/
>
>

Re: Minimum viable custom elements

2015-02-02 Thread Chris Bateman

That does not prevent the entering of alphabetic characters, does not add
commas, and does not format to a precise number of decimals . Maybe you'd
argue that these things shouldn't be done - but I'd think the existence of
multiple libraries that do these things demonstrates that it's a valid need.

On Mon, Feb 2, 2015 at 4:36 AM, Anne van Kesteren  wrote:

> On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman 
> wrote:
> > The -webkit-appreance CSS is definitely another issue, so here's an
> example
> > with just JS behavior:
> >
> > 
>
> The way to do this, FWIW, is  and solve
> the styling issue.
>
>
> --
> https://annevankesteren.nl/
>

Re: Minimum viable custom elements

2015-02-02 Thread Alice Boxhall

On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren  wrote:

> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
>  wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html
> > (which has been referenced several times in this thread, but no one has
> > critiqued to my knowledge) all of the above are evident, while at the
> same
> > time appearing to overcome the issue of standard control fugliness
>
> The only way it overcomes that is by relying on a proprietary
> extension called -webkit-appearance that is not standardized and does
> not work reliably across browsers. Furthermore, it's not at all clear
> to me why that example needs custom elements to begin with. If we
> assume this proprietary extension exists, we can just do this:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
>
> Which is much much simpler and requires none of the HTML imports,
> shadow tree, and all that script. It's also fully accessible and
> backwards compatible to the same extent. And shows that the real
> tidbit here is -webkit-appearance and not custom elements at all.
>
> (For identical styling you need to move the background-image line into
> a distinct input:checked selector block. I messed up a bit with copy
> and pasting.)
>

Sure, that works for this example (which was created in a huge rush at the
last minute before a talk, like probably 90% of my productive work), but I
don't believe it wouldn't work for
http://www.polymer-project.org/components/paper-radio-button/demo.htmlwhich
has a fancy animation for changing states.

So, I naively ask, what's stopping us from standardising something like
-webkit-appearance: none? I think that a bunch of the most common
accessibility issues we see today come from people (quite justifiably)
re-implementing standard HTML elements in order to get the styling they
need - with or without using Custom Elements.

Re: Minimum viable custom elements

2015-02-02 Thread Alice Boxhall

On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren  wrote:

> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
>  wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html
> > (which has been referenced several times in this thread, but no one has
> > critiqued to my knowledge) all of the above are evident, while at the
> same
> > time appearing to overcome the issue of standard control fugliness
>
> The only way it overcomes that is by relying on a proprietary
> extension called -webkit-appearance that is not standardized and does
> not work reliably across browsers. Furthermore, it's not at all clear
> to me why that example needs custom elements to begin with. If we
> assume this proprietary extension exists, we can just do this:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
>
> Which is much much simpler and requires none of the HTML imports,
> shadow tree, and all that script. It's also fully accessible and
> backwards compatible to the same extent. And shows that the real
> tidbit here is -webkit-appearance and not custom elements at all.
>
> (For identical styling you need to move the background-image line into
> a distinct input:checked selector block. I messed up a bit with copy
> and pasting.)


Sure, that works for this example (which was created in a huge rush at the
last minute before a talk, like probably 90% of my productive work), but I
don't believe it wouldn't work for
http://www.polymer-project.org/components/paper-radio-button/demo.html
which has a fancy animation for changing states.

So, I naively ask, what's stopping us from standardising something like
-webkit-appearance: none? I think that a bunch of the most common
accessibility issues we see today come from people (quite justifiably)
re-implementing standard HTML elements in order to get the styling they
need - with or without using Custom Elements.

Re: Minimum viable custom elements

2015-02-02 Thread Anne van Kesteren

On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman  wrote:
> The -webkit-appreance CSS is definitely another issue, so here's an example
> with just JS behavior:
>
> 

The way to do this, FWIW, is  and solve
the styling issue.


-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-02-02 Thread Anne van Kesteren

On Sat, Jan 31, 2015 at 10:41 PM, Elliott Sprehn  wrote:
> The animation is a custom element called , where do you see it
> using -webkit-tap-highlight-color?

The initial page uses that. Ryosuke's reply to this particular demo is
a lot more on topic. It's not using is="". (Use of proprietary CSS
features still seems bad though.)

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-31 Thread Elliott Sprehn

On Sat, Jan 31, 2015 at 7:47 PM, Anne van Kesteren  wrote:

> On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall 
> wrote:
> > Sure, that works for this example (which was created in a huge rush at
> the
> > last minute before a talk, like probably 90% of my productive work), but
> I
> > don't believe it wouldn't work for
> > http://www.polymer-project.org/components/paper-radio-button/demo.html
> which
> > has a fancy animation for changing states.
>
> That example seems to depend on another proprietary extension:
> -webkit-tap-highlight-color. I can't find anything else that would be
> responsible for the effect.
>
>
The animation is a custom element called , where do you see
it using -webkit-tap-highlight-color?


>
> > So, I naively ask, what's stopping us from standardising something like
> > -webkit-appearance: none?
>
> Someone has to put in the work.
>
>
> --
> https://annevankesteren.nl/
>
>

Re: Minimum viable custom elements

2015-01-31 Thread Anne van Kesteren

On Sat, Jan 31, 2015 at 5:58 AM, fantasai  wrote:
> -webkit-appearance: none isn't a proprietary extension, it's a prefixed
> version of something that was once in a standards-track document. It
> got removed because there were serious design problems with the original
> idea, but some values stuck around.

I don't see how that makes it any less proprietary. Unless some body
is standardizing '-webkit-appearance', prefix et al, my point stands.


-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-31 Thread Anne van Kesteren

On Sat, Jan 31, 2015 at 8:25 AM, Tantek Çelik  wrote:
> I'm tracking the state of requests for 'appearance' here:
>
> https://wiki.csswg.org/spec/css4-ui#appearance
>
> Feel free to directly edit that wiki page and add more concrete data /
> research that you think will help make a decision in terms of design
> etc.
>
> For now, there is insufficient data to show anyhing of any reasonable
> interop for this property, hence it is still postponed at best.

I suspect the main reason for that to be that the specification is not
detailed enough and there not being a test suite. Have you checked
with implementers?


-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-31 Thread Anne van Kesteren

On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall  wrote:
> Sure, that works for this example (which was created in a huge rush at the
> last minute before a talk, like probably 90% of my productive work), but I
> don't believe it wouldn't work for
> http://www.polymer-project.org/components/paper-radio-button/demo.html which
> has a fancy animation for changing states.

That example seems to depend on another proprietary extension:
-webkit-tap-highlight-color. I can't find anything else that would be
responsible for the effect.


> So, I naively ask, what's stopping us from standardising something like
> -webkit-appearance: none?

Someone has to put in the work.


-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-30 Thread Tantek Çelik

I'm tracking the state of requests for 'appearance' here:

https://wiki.csswg.org/spec/css4-ui#appearance

Feel free to directly edit that wiki page and add more concrete data /
research that you think will help make a decision in terms of design
etc.

For now, there is insufficient data to show anyhing of any reasonable
interop for this property, hence it is still postponed at best.

Thanks,

Tantek

tags: [css-ui] [css3-ui] [cssui]



On Fri, Jan 30, 2015 at 8:58 PM, fantasai  wrote:
> On 01/30/2015 07:54 PM, Ryosuke Niwa wrote:
>>
>>
>>> On Jan 30, 2015, at 10:22 AM, Alice Boxhall >> > wrote:
>>>
>>> The only way it overcomes that is by relying on a proprietary
>>> extension called -webkit-appearance that is not standardized and does
>>> not work reliably across browsers. Furthermore, it's not at all clear
>>> to me why that example needs custom elements to begin with. If we
>>> assume this proprietary extension exists, we can just do this:
>>>
>>> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397
>
> [...]
>>>
>>> So, I naively ask, what's stopping us from standardising something like
>>> -webkit-appearance: none? I think that a bunch of
>>> the most common accessibility issues we see today come from people (quite
>>> justifiably) re-implementing standard HTML
>>> elements in order to get the styling they need - with or without using
>>> Custom Elements.
>
>
> -webkit-appearance: none isn't a proprietary extension, it's a prefixed
> version of something that was once in a standards-track document. It
> got removed because there were serious design problems with the original
> idea, but some values stuck around.
>
>> Indeed.  It would be really useful to solve this problem either with a CSS
>> property like -webkit-appearance or decorator.
>>   Perhaps Tantek or Fantasai could enlighten us.
>>
>> Relevant URLs:
>>
>> https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search
>> https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html
>> https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
>> https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html
>
>
> I think you caught the important points right there.
>
> Tantek and Florian are actively working on updating the CSS3 UI
> draft right now, so this might come up at the CSSWG f2f in a
> couple weeks.
>
> ~fantasai

Re: Minimum viable custom elements

2015-01-30 Thread fantasai

On 01/30/2015 07:54 PM, Ryosuke Niwa wrote:

On Jan 30, 2015, at 10:22 AM, Alice Boxhall mailto:aboxh...@google.com>> wrote:

The only way it overcomes that is by relying on a proprietary
extension called -webkit-appearance that is not standardized and does
not work reliably across browsers. Furthermore, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397

[...]

So, I naively ask, what's stopping us from standardising something like
-webkit-appearance: none? I think that a bunch of
the most common accessibility issues we see today come from people (quite
justifiably) re-implementing standard HTML
elements in order to get the styling they need - with or without using Custom
Elements.

-webkit-appearance: none isn't a proprietary extension, it's a prefixed
version of something that was once in a standards-track document. It
got removed because there were serious design problems with the original
idea, but some values stuck around.

Indeed. It would be really useful to solve this problem either with a CSS
property like -webkit-appearance or decorator.
Perhaps Tantek or Fantasai could enlighten us.

Relevant URLs:
https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search
https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html
https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html

I think you caught the important points right there.

Tantek and Florian are actively working on updating the CSS3 UI
draft right now, so this might come up at the CSSWG f2f in a
couple weeks.

~fantasai

Re: Minimum viable custom elements

2015-01-30 Thread Ryosuke Niwa


> On Jan 30, 2015, at 10:22 AM, Alice Boxhall  wrote:
> 
> On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren  > wrote:
> On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
> mailto:faulkner.st...@gmail.com>> wrote:
> > In this radio and checkbox example (view in chrome)
> > https://rawgit.com/alice/web-components-demos/master/index.html 
> > 
> > (which has been referenced several times in this thread, but no one has
> > critiqued to my knowledge) all of the above are evident, while at the same
> > time appearing to overcome the issue of standard control fugliness
> 
> The only way it overcomes that is by relying on a proprietary
> extension called -webkit-appearance that is not standardized and does
> not work reliably across browsers. Furthermore, it's not at all clear
> to me why that example needs custom elements to begin with. If we
> assume this proprietary extension exists, we can just do this:
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397 
> 
> 
> Which is much much simpler and requires none of the HTML imports,
> shadow tree, and all that script. It's also fully accessible and
> backwards compatible to the same extent. And shows that the real
> tidbit here is -webkit-appearance and not custom elements at all.
> 
> (For identical styling you need to move the background-image line into
> a distinct input:checked selector block. I messed up a bit with copy
> and pasting.)
> 
> Sure, that works for this example (which was created in a huge rush at the 
> last minute before a talk, like probably 90% of my productive work), but I 
> don't believe it wouldn't work for 
> http://www.polymer-project.org/components/paper-radio-button/demo.html 
>  
> which has a fancy animation for changing states.

It doesn’t but how does custom elements solve that problem?  This example 
doesn’t even seem to use “is” and manually sets ARIA attributes.  Could you 
clarify exactly which accessibility issues custom elements would solve in this 
example?

> So, I naively ask, what's stopping us from standardising something like 
> -webkit-appearance: none? I think that a bunch of the most common 
> accessibility issues we see today come from people (quite justifiably) 
> re-implementing standard HTML elements in order to get the styling they need 
> - with or without using Custom Elements.

Indeed.  It would be really useful to solve this problem either with a CSS 
property like -webkit-appearance or decorator.  Perhaps Tantek or Fantasai 
could enlighten us.

Relevant URLs:
https://www.w3.org/Search/Mail/Public/search?type-index=www-style&index-type=t&keywords=appearance&search=Search
 

https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html 

https://lists.w3.org/Archives/Public/www-style/2014Feb/0459.html
https://lists.w3.org/Archives/Public/www-style/2013Feb/0625.html

- R. Niwa

Re: Minimum viable custom elements

2015-01-30 Thread Ryosuke Niwa

> On Jan 30, 2015, at 1:02 AM, Bruce Lawson  wrote:
> 
> On 29 January 2015 at 19:48, Ryosuke Niwa  wrote:
>> And we have a proposal to do both of these things: decorators [1]
> 
> yes, indeed. What is the status of decorators? Last I looked, it had
> been removed from the "web components" umbrella, so I thought it had
> been sent to a farm upstate, but I haven't been following its progress
> particularly closely.

I think it got removed because we couldn’t figure out the life-cycle story.  
Since decorators are bound by CSS, they need to be instantiated at the time of 
style resolution, which is highly implementation dependent.

- R. Niwa

Re: Minimum viable custom elements

2015-01-30 Thread Anne van Kesteren

On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
 wrote:
> In this radio and checkbox example (view in chrome)
> https://rawgit.com/alice/web-components-demos/master/index.html
> (which has been referenced several times in this thread, but no one has
> critiqued to my knowledge) all of the above are evident, while at the same
> time appearing to overcome the issue of standard control fugliness

The only way it overcomes that is by relying on a proprietary
extension called -webkit-appearance that is not standardized and does
not work reliably across browsers. Furthermore, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397

Which is much much simpler and requires none of the HTML imports,
shadow tree, and all that script. It's also fully accessible and
backwards compatible to the same extent. And shows that the real
tidbit here is -webkit-appearance and not custom elements at all.

(For identical styling you need to move the background-image line into
a distinct input:checked selector block. I messed up a bit with copy
and pasting.)

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-30 Thread Steve Faulkner

I am not championing is= as the answer to all the worlds ills, but it does
provide *examples* of built in features that I believe are critical to
robust accessibility support in web components:

which are:
roles/state and property mapping from existing attributes (disabled,
required etc)
platform/browser standard interaction behaviours (keyboard etc)
ability to provide an accessible name, and  elements (that are
labelable) using standard HTML

In this radio and checkbox example (view in chrome)
https://rawgit.com/alice/web-components-demos/master/index.html
(which has been referenced several times in this thread, but no one has
critiqued to my knowledge) all of the above are evident, while at the same
time appearing to overcome the issue of standard control fugliness

If there are better ways to achieve the built in features which support
robust accessibility I am all for it. ,

--

Regards

SteveF
HTML 5.1 

On 29 January 2015 at 19:48, Ryosuke Niwa  wrote:

>
> On Jan 29, 2015, at 7:52 AM, Steve Faulkner 
> wrote:
> On 29 January 2015 at 15:37, Anne van Kesteren  wrote:
>
>  I don't have enough technical understanding to know what is viable or not,
>>>  you and others are saying that the current accessibility feature support
>>> baked in to custom elements spec via is= is not acceptable
>>>
>>> That seems rather disingenuous.
>>
>
> where am I being disingenuous?
>
> I don't understand how the various pieces are pulled together to make an
> element work in browsers to an extent to be able to offer possible
> technical solutions. If I did I would.
>
>
> I think there is a bit of miscommunication here.
>
> Correct me if I'm wrong but I think you're trying to fix the problem of
> Web developers writing their own UI widgets and components and they're
> often inaccessible because they didn't set ARIA roles right, etc…
>
> If that's the problem you're trying to solve here, then what you need is
> shadow DOM, not custom elements.  As someone who cares about accessibility
> deeply, I want to solve this problem too.  However, like Anne pointed out
> in earlier threads, authors aren't going to start using custom elements to
> implement those fancy UI widgets currently implemented via div's and span's
> using is=~ attribute since custom elements doesn't provide any mechanism to
> change the appearance of a builtin element.  Shadow DOM, on the other hand,
> is one proposed mechanism to replace the appearance of a builtin element by
> way of replacing the contents of the element via a shadow tree.  Now, if
> we're using shadow DOM to change the appearance of a builtin element, then
> choosing which appearance to use in the HTML markup via a content attribute
> is a layering violation.  We should be doing that in CSS instead.  And we
> have a proposal to do both of these things: decorators [1]
>
> One more thing.  I would really like if we could stop making claims such
> as web components as currently spec'ed magically improves accessibility
> because it's doing a huge disservice to the future of the Web
> accessibility.  They don't.  Far from it.  I've pointed out numerous issues
> with them over the last couple of years but none of them have been
> adequately addressed.
>
> [1]
> https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html#decorator-section
>
> - R. Niwa
>
>

Re: Minimum viable custom elements

2015-01-30 Thread Bruce Lawson

On 29 January 2015 at 19:48, Ryosuke Niwa  wrote:
>  And we have a proposal to do both of these things: decorators [1]

yes, indeed. What is the status of decorators? Last I looked, it had
been removed from the "web components" umbrella, so I thought it had
been sent to a farm upstate, but I haven't been following its progress
particularly closely.

>
> One more thing.  I would really like if we could stop making claims such as
> web components as currently spec'ed magically improves accessibility because
> it's doing a huge disservice to the future of the Web accessibility.

I'm not certain anyone has made the claim that anything's "magically
improved" ...

They
> don't.  Far from it.  I've pointed out numerous issues with them over the
> last couple of years but none of them have been adequately addressed.

could you provide a pointer to them, please?

bruce

Re: Minimum viable custom elements

2015-01-29 Thread Brian Kardell

On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson  wrote:
[snip]


> "a really first-class fallback option if you don't support JS" is
> vital for the quarter of a billion people who use Opera Mini and the
> 100 million people who use the Nokia proxy browser. Fallback rather
> than non-functional pages is vital for the people who don't use latest
> greatest Chromium or Gecko browsers.
>
> b
>

But in the context of custom elements (not shadow dom) these should be able
to do 'createdCallback' etc on the server... I can't really see any reason
why they couldn't/wouldn't.

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

2015-01-29 Thread Ryosuke Niwa

> On Jan 29, 2015, at 7:52 AM, Steve Faulkner  wrote:
> On 29 January 2015 at 15:37, Anne van Kesteren  > wrote:
>  I don't have enough technical understanding to know what is viable or not,
>  you and others are saying that the current accessibility feature support
> baked in to custom elements spec via is= is not acceptable
> 
> That seems rather disingenuous.
> 
> where am I being disingenuous? 
> 
> I don't understand how the various pieces are pulled together to make an 
> element work in browsers to an extent to be able to offer possible technical 
> solutions. If I did I would.

I think there is a bit of miscommunication here.

Correct me if I'm wrong but I think you're trying to fix the problem of Web 
developers writing their own UI widgets and components and they're often 
inaccessible because they didn't set ARIA roles right, etc…

If that's the problem you're trying to solve here, then what you need is shadow 
DOM, not custom elements.  As someone who cares about accessibility deeply, I 
want to solve this problem too.  However, like Anne pointed out in earlier 
threads, authors aren't going to start using custom elements to implement those 
fancy UI widgets currently implemented via div's and span's using is=~ 
attribute since custom elements doesn't provide any mechanism to change the 
appearance of a builtin element.  Shadow DOM, on the other hand, is one 
proposed mechanism to replace the appearance of a builtin element by way of 
replacing the contents of the element via a shadow tree.  Now, if we're using 
shadow DOM to change the appearance of a builtin element, then choosing which 
appearance to use in the HTML markup via a content attribute is a layering 
violation.  We should be doing that in CSS instead.  And we have a proposal to 
do both of these things: decorators [1]

One more thing.  I would really like if we could stop making claims such as web 
components as currently spec'ed magically improves accessibility because it's 
doing a huge disservice to the future of the Web accessibility.  They don't.  
Far from it.  I've pointed out numerous issues with them over the last couple 
of years but none of them have been adequately addressed.

[1] 
https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html#decorator-section

- R. Niwa

Re: Minimum viable custom elements

2015-01-29 Thread Bruce Lawson

On 29 January 2015 at 19:09, Brian Kardell  wrote:
> composition actually seems to let you express something equally good without
> ambiguity more easily except insofar as giving you a really first-class
> fallback option if you don't support JS, but... I'm having a really hard
> time imagining more than 3-4 cases  where that's really a useful thing.

I'm thinking of all the HTML elements that people feel compelled to
recreate with div soup and JS  (some of this is because the CSS hooks
don't exist, but I doubt we could ever define all conceivable CSS
hooks, but that's another story).

 The canonical example is  but  ; ;  

All of these degrade very nicely and work even when JS isn't present,
whereas  and  don't.

I'd also very much like to do  etc.

"a really first-class fallback option if you don't support JS" is
vital for the quarter of a billion people who use Opera Mini and the
100 million people who use the Nokia proxy browser. Fallback rather
than non-functional pages is vital for the people who don't use latest
greatest Chromium or Gecko browsers.

Sure, not everyone will do this. But not everyone puts alt text on
images; that's not an argument for removing  from the
platform.
b

Re: Minimum viable custom elements

2015-01-29 Thread Brian Kardell

On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn 
wrote:

>
>
> On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell  wrote:
>
>>
>>
>> On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson  wrote:
>>
>>> On 29 January 2015 at 14:54, Steve Faulkner 
>>> wrote:
>>> > I think being able to extend existing elements has potential value to
>>> > developers far beyond accessibility (it just so happens that
>>> accessibility
>>> > is helped a lot by re-use of existing HTML features.)
>>>
>>> I agree with everything Steve has said about accessibility. Extending
>>> existing elements also gives us progressive enhancement potential.
>>>
>>> Try https://rawgit.com/alice/web-components-demos/master/index.html in
>>> Safari or IE. The second column isn't functional because it's using
>>> brand new custom elements. The first column loses the web componenty
>>> sparkles but remains functional because it extends existing HTML
>>> elements.
>>>
>>> There's a similar story with Opera Mini, which is used by at least
>>> 250m people (and another potential 100m transitioning on Microsoft
>>> feature phones) because of its proxy architecture.
>>>
>>> Like Steve, I've no particularly affection (or enmity) towards the
>>>  syntax. But I'd like to know,
>>> if it's dropped, how progressive enhancement can be achieved so we
>>> don't lock out users of browsers that don't have web components
>>> capabilities, JavaScript disabled or proxy browsers. If there is a
>>> concrete plan, please point me to it. If there isn't, it's
>>> irresponsible to drop a method that we can see working in the example
>>> above with nothing else to replace it.
>>>
>>> I also have a niggling worry that this may affect the uptake of web
>>> components. When I led a dev team for a large UK legal site, there's
>>> absolutely no way we could have used a technology that was
>>> non-functional in older/proxy browsers.
>>>
>>> bruce
>>>
>>>
>> Humor me for a moment while I recap some historical arguments/play
>> devil's advocate here.
>>
>> One conceptual problem I've always had with the is="" form is that it
>> adds some amount of ambiguity for authors and makes it plausible to author
>> non-sense.  It's similar to the problem of aria being "bolt on" with mix
>> and match attributes.  With the imperative form of extending you wind up
>> with a tag name that definitely is defined as subclassing something
>> " 'inherits' from HTMLButtonElement and I'll explain how it's
>> different".  With the declarative attribute form you basically have to
>> manage 3 things: ANY tag, the base class and the final definition.  This
>> means it's possible to do things like  which likely
>> won't work.  Further, you can then proceed to define something which is
>> clearly none-of-the-above.
>>
>
> The is@ only works on the element you defined it to apply to, so  is="button"> does nothing unless the element "button" was registered as a
> type extension to "iframe". I don't see that as any more error prone than
> writing  instead of .
>
> In other words, if there are 350 elements in HTML - in 349 you could say
is="button" and it would do nothing.  This isn't possible with the pure tag
form, it either is or isn't the tag.  This is all I described - ambiguity
for authors and ability to author nonsense.  Maybe it is 'benign' nonsense
but it's nonsense and potentially frustrating in a way that misspelling a
tag isn't IMO.


> Also fwiw most "share" buttons on the web are actually iframes, so  is="facebook-button"> makes total sense.
>

youre somewhat locked into thinking that because it's how we've dealt with
things, don't you think?  I mean  might conceptually
work too, but we know that they're iframes for SOP/isolation reasons.  That
said, what exactly would you add to your custom element facebook-button
that adds value then?  ... Like... what could you legitimately do with that
that you couldn't do with ?  Would it
actually submit a form in *your* page, would your focus act the same, etc?
I'm asking for real because I think the use-cases are on the small end of
limited

I'm not saying it's better or worse, I'm actually trying to take the devils
advocate position here because there might be something beneath it worth
thinking about...  It does seem that composition actually seems to let you
express something equally good without ambiguity more easily except insofar
as giving you a really first-class fallback option if you don't support JS,
but... I'm having a really hard time imagining more than 3-4 cases  where
that's really a useful thing.



> - E
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

2015-01-29 Thread Elliott Sprehn

On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell  wrote:

>
>
> On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson  wrote:
>
>> On 29 January 2015 at 14:54, Steve Faulkner 
>> wrote:
>> > I think being able to extend existing elements has potential value to
>> > developers far beyond accessibility (it just so happens that
>> accessibility
>> > is helped a lot by re-use of existing HTML features.)
>>
>> I agree with everything Steve has said about accessibility. Extending
>> existing elements also gives us progressive enhancement potential.
>>
>> Try https://rawgit.com/alice/web-components-demos/master/index.html in
>> Safari or IE. The second column isn't functional because it's using
>> brand new custom elements. The first column loses the web componenty
>> sparkles but remains functional because it extends existing HTML
>> elements.
>>
>> There's a similar story with Opera Mini, which is used by at least
>> 250m people (and another potential 100m transitioning on Microsoft
>> feature phones) because of its proxy architecture.
>>
>> Like Steve, I've no particularly affection (or enmity) towards the
>>  syntax. But I'd like to know,
>> if it's dropped, how progressive enhancement can be achieved so we
>> don't lock out users of browsers that don't have web components
>> capabilities, JavaScript disabled or proxy browsers. If there is a
>> concrete plan, please point me to it. If there isn't, it's
>> irresponsible to drop a method that we can see working in the example
>> above with nothing else to replace it.
>>
>> I also have a niggling worry that this may affect the uptake of web
>> components. When I led a dev team for a large UK legal site, there's
>> absolutely no way we could have used a technology that was
>> non-functional in older/proxy browsers.
>>
>> bruce
>>
>>
> Humor me for a moment while I recap some historical arguments/play devil's
> advocate here.
>
> One conceptual problem I've always had with the is="" form is that it adds
> some amount of ambiguity for authors and makes it plausible to author
> non-sense.  It's similar to the problem of aria being "bolt on" with mix
> and match attributes.  With the imperative form of extending you wind up
> with a tag name that definitely is defined as subclassing something
> " 'inherits' from HTMLButtonElement and I'll explain how it's
> different".  With the declarative attribute form you basically have to
> manage 3 things: ANY tag, the base class and the final definition.  This
> means it's possible to do things like  which likely
> won't work.  Further, you can then proceed to define something which is
> clearly none-of-the-above.
>

The is@ only works on the element you defined it to apply to, so  does nothing unless the element "button" was registered as a
type extension to "iframe". I don't see that as any more error prone than
writing  instead of .

Also fwiw most "share" buttons on the web are actually iframes, so  makes total sense.

- E

Re: Minimum viable custom elements

2015-01-29 Thread Brian Kardell

On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson  wrote:

> On 29 January 2015 at 14:54, Steve Faulkner 
> wrote:
> > I think being able to extend existing elements has potential value to
> > developers far beyond accessibility (it just so happens that
> accessibility
> > is helped a lot by re-use of existing HTML features.)
>
> I agree with everything Steve has said about accessibility. Extending
> existing elements also gives us progressive enhancement potential.
>
> Try https://rawgit.com/alice/web-components-demos/master/index.html in
> Safari or IE. The second column isn't functional because it's using
> brand new custom elements. The first column loses the web componenty
> sparkles but remains functional because it extends existing HTML
> elements.
>
> There's a similar story with Opera Mini, which is used by at least
> 250m people (and another potential 100m transitioning on Microsoft
> feature phones) because of its proxy architecture.
>
> Like Steve, I've no particularly affection (or enmity) towards the
>  syntax. But I'd like to know,
> if it's dropped, how progressive enhancement can be achieved so we
> don't lock out users of browsers that don't have web components
> capabilities, JavaScript disabled or proxy browsers. If there is a
> concrete plan, please point me to it. If there isn't, it's
> irresponsible to drop a method that we can see working in the example
> above with nothing else to replace it.
>
> I also have a niggling worry that this may affect the uptake of web
> components. When I led a dev team for a large UK legal site, there's
> absolutely no way we could have used a technology that was
> non-functional in older/proxy browsers.
>
> bruce
>
>
Humor me for a moment while I recap some historical arguments/play devil's
advocate here.

One conceptual problem I've always had with the is="" form is that it adds
some amount of ambiguity for authors and makes it plausible to author
non-sense.  It's similar to the problem of aria being "bolt on" with mix
and match attributes.  With the imperative form of extending you wind up
with a tag name that definitely is defined as subclassing something
" 'inherits' from HTMLButtonElement and I'll explain how it's
different".  With the declarative attribute form you basically have to
manage 3 things: ANY tag, the base class and the final definition.  This
means it's possible to do things like  which likely
won't work.  Further, you can then proceed to define something which is
clearly none-of-the-above.

With the imperative form you can pretty clearly grok it and avoid a class
of errors which you couldn't otherwise.  Still, getting this right in
implementation is actually really hard and, as such, will require a lot of
debate - similarly, because it's kind of 'mix in' oriented (that is, what
you have is 'features of a button which are, unfortunately potentially
based on complicated DOM which isn't a button) it's still further
complicated to figure out the right thing to base off of... Only in a
vanishingly small number of cases like the oft repeated 'custom button' is
this not the case, but even there you can imagine that if you really need
to extend a button, you're asking for 'more than a button' and it might get
swampy.

Let's imagine you have none of that though and you want a custom button
which involves some dom that isn't just 'button'.  How would you write it?
Most likely through composition - that is, it would likely -contain- a
button.  This is considerably simpler and in many ways more intuitive and
it has approximately the same accessibility benefit as far as I can tell.
It's probably not 'the best we can do' but it might not be a bad start if
we had to start there.

With regard to 'what about if you have javascript turned off' - again,
there are a class of problems where there are easy to employ patterns and a
class of problems where that is just not the case and can't be.  I think we
have to be very cautious about that.  If you have a custom element with a
src="" attribute, for example, the best you are going to be able to do is
graceful degradation with the stuff kinda already built into HTML - things
like noscript and unknown element stuff.  As for pre-renderers, what I've
described isn't so complicated that I think pre-renderers can't get it
right, but maybe I am misunderstanding.

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Re: Minimum viable custom elements

2015-01-29 Thread Steve Faulkner

>
>  I don't have enough technical understanding to know what is viable or not,
>>  you and others are saying that the current accessibility feature support
>> baked in to custom elements spec via is= is not acceptable
>>
>> That seems rather disingenuous.
>

where am I being disingenuous?

I don't understand how the various pieces are pulled together to make an
element work in browsers to an extent to be able to offer possible
technical solutions. If I did I would.


--

Regards

SteveF
HTML 5.1 

On 29 January 2015 at 15:37, Anne van Kesteren  wrote:

> On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
>  wrote:
> > I don't have enough technical understanding to know what is viable or
> not,
> > you and others are saying that the current accessibility feature support
> > baked in to custom elements spec via is= is not acceptable
>
> That seems rather disingenuous. I have said these things:
>
> 1) Compared to  the is="" construct is a hack that is
> unlikely to be attractive to those building libraries. Existing
> libraries seem to support this.
>
> 2) As long as the styling problem for form controls remains unsolved,
> making some form of automatic prototype mutation work for them is not
> going to get them adoption.
>
> Others have already explained how turning 1) around is hard as
> browsers, specifications, and stylesheets branch on local name rather
> than instance checks. 2) is even harder and has always been the real
> problem.
>
>
> --
> https://annevankesteren.nl/
>

Re: Minimum viable custom elements

2015-01-29 Thread Dimitri Glazkov

One additional point, unrelated to accessibility: "is" also enables
piggybacking to special parser behavior of existing elements. For example,
I can extend  or .

Here are some examples:

http://jsbin.com/xuheb/3/edit?html,output

https://blog.polymer-project.org/howto/2014/09/11/template-is-autobinding/

:DG<

On Thu, Jan 29, 2015 at 7:33 AM, Bruce Lawson  wrote:

> On 29 January 2015 at 14:54, Steve Faulkner 
> wrote:
> > I think being able to extend existing elements has potential value to
> > developers far beyond accessibility (it just so happens that
> accessibility
> > is helped a lot by re-use of existing HTML features.)
>
> I agree with everything Steve has said about accessibility. Extending
> existing elements also gives us progressive enhancement potential.
>
> Try https://rawgit.com/alice/web-components-demos/master/index.html in
> Safari or IE. The second column isn't functional because it's using
> brand new custom elements. The first column loses the web componenty
> sparkles but remains functional because it extends existing HTML
> elements.
>
> There's a similar story with Opera Mini, which is used by at least
> 250m people (and another potential 100m transitioning on Microsoft
> feature phones) because of its proxy architecture.
>
> Like Steve, I've no particularly affection (or enmity) towards the
>  syntax. But I'd like to know,
> if it's dropped, how progressive enhancement can be achieved so we
> don't lock out users of browsers that don't have web components
> capabilities, JavaScript disabled or proxy browsers. If there is a
> concrete plan, please point me to it. If there isn't, it's
> irresponsible to drop a method that we can see working in the example
> above with nothing else to replace it.
>
> I also have a niggling worry that this may affect the uptake of web
> components. When I led a dev team for a large UK legal site, there's
> absolutely no way we could have used a technology that was
> non-functional in older/proxy browsers.
>
> bruce
>
>

Re: Minimum viable custom elements

2015-01-29 Thread Anne van Kesteren

On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
 wrote:
> I don't have enough technical understanding to know what is viable or not,
> you and others are saying that the current accessibility feature support
> baked in to custom elements spec via is= is not acceptable

That seems rather disingenuous. I have said these things:

1) Compared to  the is="" construct is a hack that is
unlikely to be attractive to those building libraries. Existing
libraries seem to support this.

2) As long as the styling problem for form controls remains unsolved,
making some form of automatic prototype mutation work for them is not
going to get them adoption.

Others have already explained how turning 1) around is hard as
browsers, specifications, and stylesheets branch on local name rather
than instance checks. 2) is even harder and has always been the real
problem.

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-29 Thread Bruce Lawson

On 29 January 2015 at 14:54, Steve Faulkner  wrote:
> I think being able to extend existing elements has potential value to
> developers far beyond accessibility (it just so happens that  accessibility
> is helped a lot by re-use of existing HTML features.)

I agree with everything Steve has said about accessibility. Extending
existing elements also gives us progressive enhancement potential.

Try https://rawgit.com/alice/web-components-demos/master/index.html in
Safari or IE. The second column isn't functional because it's using
brand new custom elements. The first column loses the web componenty
sparkles but remains functional because it extends existing HTML
elements.

There's a similar story with Opera Mini, which is used by at least
250m people (and another potential 100m transitioning on Microsoft
feature phones) because of its proxy architecture.

Like Steve, I've no particularly affection (or enmity) towards the
 syntax. But I'd like to know,
if it's dropped, how progressive enhancement can be achieved so we
don't lock out users of browsers that don't have web components
capabilities, JavaScript disabled or proxy browsers. If there is a
concrete plan, please point me to it. If there isn't, it's
irresponsible to drop a method that we can see working in the example
above with nothing else to replace it.

I also have a niggling worry that this may affect the uptake of web
components. When I led a dev team for a large UK legal site, there's
absolutely no way we could have used a technology that was
non-functional in older/proxy browsers.

bruce

Re: Minimum viable custom elements

2015-01-29 Thread Steve Faulkner

Anne wrote:

> but do you see a viable way to get there?
>

I don't have enough technical understanding to know what is viable or not,
you and others are saying that the current accessibility feature support
baked in to custom elements spec via is= is not acceptable

To recap

What is= provides:
A way for developers take advantage of the built in roles,states and
properties of existing HTML elements without having to add ARIA to reflect
the acc properties and scripting to emulate behaviours (see what ARIA does
not do )
For example. putting aria-disabled=true on a button does not make the
element disabled like the ‘disabled’ attribute does (removes from tab order
etc), it just sets the disabled state flag in accessibility APIs.

So being able to do:

means that devs can take advantage of built-in focus and keyboard handling
and built in states and properties (all of which have acc built-in where
needed) -

for example button related attributes.

autofocus - Automatically focus the form control when the page is loaded
disabled - Whether the form control is disabled
form - Associates the control with a form element
formaction - URL to use for form submission
formenctype - Form data set encoding type to use for form submission
formmethod - HTTP method to use for form submission
formnovalidate - Bypass form control validation for form submission
formtarget - Browsing context for form submission
menu - Specifies the element's designated pop-up menu
name - Name of form control to use for form submission and in the
form.elements API
type - Type of button
value - Value to be used for form submission

I think being able to extend existing elements has potential value to
developers far beyond accessibility (it just so happens that  accessibility
is helped a lot by re-use of existing HTML features.)

I am not married to the is= method, but am very concerned that custom
elements without some useful method to leverage existing HTML features will
make the accessibility support story for this new technology bleak and as
much as I love ARIA it is accessibility that must be bolted on by the
developer which is unfortunately prone to error and often left off.

--

Regards

SteveF

On 16 January 2015 at 16:52, Anne van Kesteren  wrote:

> On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner
>  wrote:
> > I have not suggested is= as the method that must be implemented (I have
> not
> > demanded anything), what I have tried to suggest is that minimum viable
> > custom elements with all accessibility as bolt-on is a poor solution by
> > design.  From an acc view it means custom elements are nothing more than
> > s with fancy names.
>
> Sure, I hope everyone understands that,

> Again, I think that unless we solve the styling problem for
> native elements, we're not going to see them adopted, not even if you
> can subclass them (and proper subclassing without the is="" hack is
> another hard problem, as explained).
>
>
> --
> https://annevankesteren.nl/
>

Re: Minimum viable custom elements

2015-01-19 Thread Anne van Kesteren

On Fri, Jan 16, 2015 at 8:06 PM, Domenic Denicola  wrote:
> From: Ryosuke Niwa [mailto:rn...@apple.com]
>> However, nobody has suggested a design that satisfies both of our 
>> requirements: using ES6 constructor for element initialization
>
> Could you say more about why this is a requirement?

I would be interested to hear about this too. I created a gist
comparing the Jonas and Dmitry proposals and as far as I can tell both
have drawbacks that make them not exactly clean or explain the
platform fully:

  https://gist.github.com/annevk/cd58b3e45f399672004a

It seems clear we'll have to accept some oddity in order to enable
custom elements. The Dmitry proposal seems to have the advantage in
that it creates the tree in the same manner and that there's a
plausible strategy for retrofitting normal elements to match its
design.

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

2015-01-17 Thread Ryosuke Niwa

On Jan 16, 2015, at 4:07 PM, Dimitri Glazkov  wrote:
> On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa  wrote:
> 
>> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov  wrote:
>> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa  wrote:
>> When an author imports a ES6 module, we don't create a fake object which 
>> gets resolved later by rewriting its prototype.
>> 
>> These are two completely different things, right? In one situation, you are 
>> dealing with HTML Parser and blocking thereof. In another, there's no such 
>> concern. 
> 
> How are they different at all?  I have a hard time understanding how 
> differentiating DOM objects from other ES6 builtins will fit your stated 
> design goal to explain the Web platform.
> 
> ... because DOM objects are not the ES6 built-ins?
> 
> If we are implementing the HTML parser as well as the entire DOM in 
> JavaScript, why wouldn't we just use constructors to create DOM nodes?
> 
> I feel like we're walking in circles at this point.

Indeed.

> It's pretty safe to say that we're years away from being able to implement 
> HTML parser and the entire DOM in JS. Even then, time-shifted callbacks (or 
> similar write-barrier-style abstraction) still make sense. The JS that 
> implements the parser or DOM may desire to run the custom elements JS code 
> only in certain places (see Mutation Events -> Mutation Observers).

If implementations are so desired, they could certainly do that.  There is 
nothing that prevents from UAs to run any scripts at any timing as long as the 
observed behavior is interoperable.  For example, an implementation could 
construct a queue of nodes as a form of a detached DOM tree, and then call 
constructors on those objects after manually detaching them; the noes could be 
inserted again once the elements are "constructed".  Such an approach allows 
implementing Jonas' proposal with very small set of changes to existing HTML 
parser implementations.

> Let me repeat and extend what I said earlier in the thread. In the world 
> where we have non-blocking scripts and HTML parser that yields, upgrades are 
> a performance/ergonomics primitive.
> 
> With upgrades, the non-blocking script could execute during a yield, register 
> elements, and keep on going. The chunk of html that was parsed previously 
> will upgrade, and the chunk that hasn't yet parsed will start queueing 
> callbacks. The developer does not need to care about the timing of 
> registration. From their perspective, the order of callbacks will be the same.

Unless I'm missing something, scripts that use JavaScript APIs exposed by those 
custom elements cannot run until those custom elements are "upgraded".  Again, 
this is not a problem that should be solved for only custom elements.  This is 
a generic script and resource dependency problem for which an extensive list of 
use cases have been identified: 
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html

> Without upgrades, you as a developer are highly incentivized to reduce the 
> amount of html after your non-blocking script, because you need to wait until 
> the doc parsed completely until you can sensibly run the script.

There are a lot of high profile websites that run scripts prior to the document 
has finished parsing.  Furthermore, if that were already the case, how does 
introducing the mechanism for elements to asynchronously upgrade help authors 
at all?  If anything, it adds another dimension to the already complex problem 
space developers have to face today.

> This is what's happening today, as evidenced by most frameworks moving away 
> from using HTML Parser as anything but script bootstrapping device, and 
> relying on imperative tree construction. And in that world, upgrades are 
> useless -- but so is HTML. And eventually, DOM.

Correlation doesn't imply causation.  The way I see it, a lot of Web apps are 
using the HTML parser as a bootstrapping mechanism today because they need to 
get data out of JSON they fetched out of services instead of embedded in HTML.  
Also, if the needs of developers obsolete HTML and DOM, then so be it.  Perhaps 
the future of the Web apps is a bundle of ES6 modules.

- R. Niwa

Re: Minimum viable custom elements

2015-01-16 Thread Dimitri Glazkov

On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa  wrote:

>
> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov  wrote:
> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa  wrote:
>>
>> When an author imports a ES6 module, we don't create a fake object which
>> gets resolved later by rewriting its prototype.
>>
>
> These are two completely different things, right? In one situation, you
> are dealing with HTML Parser and blocking thereof. In another, there's no
> such concern.
>
>
> How are they different at all?  I have a hard time understanding how
> differentiating DOM objects from other ES6 builtins will fit your stated
> design goal to explain the Web platform.
>

... because DOM objects are not the ES6 built-ins?

>
> If we are implementing the HTML parser as well as the entire DOM in
> JavaScript, why wouldn't we just use constructors to create DOM nodes?
>

I feel like we're walking in circles at this point.

It's pretty safe to say that we're years away from being able to implement
HTML parser and the entire DOM in JS. Even then, time-shifted callbacks (or
similar write-barrier-style abstraction) still make sense. The JS that
implements the parser or DOM may desire to run the custom elements JS code
only in certain places (see Mutation Events -> Mutation Observers).

>
> If your concern is that it would block the rendering of the page,
>

No, it is not.

>
> If your concern is that authors must wait until other scripts that define
> custom elements are loaded even after DOMContentLoaded is fired,
>

No, it is not.

Let me repeat and extend what I said earlier in the thread. In the world
where we have non-blocking scripts and HTML parser that yields, upgrades
are a performance/ergonomics primitive.

With upgrades, the non-blocking script could execute during a yield,
register elements, and keep on going. The chunk of html that was parsed
previously will upgrade, and the chunk that hasn't yet parsed will start
queueing callbacks. The developer does not need to care about the timing of
registration. From their perspective, the order of callbacks will be the
same.

Without upgrades, you as a developer are highly incentivized to reduce the
amount of html after your non-blocking script, because you need to wait
until the doc parsed completely until you can sensibly run the script.

This is what's happening today, as evidenced by most frameworks moving away
from using HTML Parser as anything but script bootstrapping device, and
relying on imperative tree construction. And in that world, upgrades are
useless -- but so is HTML. And eventually, DOM.

:DG<

Re: Minimum viable custom elements

2015-01-16 Thread Ryosuke Niwa

> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov  wrote:
> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa  > wrote:
> When an author imports a ES6 module, we don't create a fake object which gets 
> resolved later by rewriting its prototype.
> 
> These are two completely different things, right? In one situation, you are 
> dealing with HTML Parser and blocking thereof. In another, there's no such 
> concern. 

How are they different at all?  I have a hard time understanding how 
differentiating DOM objects from other ES6 builtins will fit your stated design 
goal to explain the Web platform.

If we are implementing the HTML parser as well as the entire DOM in JavaScript, 
why wouldn't we just use constructors to create DOM nodes?

If your concern is that it would block the rendering of the page, then we can 
create a fake element that then gets later replaced.  Any script that needs to 
store the reference or attach event listeners could simply wait until custom 
elements dependencies are resolved or observe DOM mutations in the document.  
After all, if authors are storing node references or attaching event listeners 
prior to DOMContentLoaded, then they must, by definition, need to deal with 
HTML parsers adding more nodes.

If your concern is that authors must wait until other scripts that define 
custom elements are loaded even after DOMContentLoaded is fired, then I'd say 
that's not a problem UA should be solving only for custom elements.  This 
problem exists for any set of mutually dependent asynchronously loaded scripts 
of at least size two or greater.  This is a problem Hixie is trying solve to 
with "needs" attribute in his propsal to solve the script/resource dependency 
problem [1].

[1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0012.html

- R. Niwa

RE: Minimum viable custom elements

2015-01-16 Thread Domenic Denicola

From: Ryosuke Niwa [mailto:rn...@apple.com] 

> However, nobody has suggested a design that satisfies both of our 
> requirements: using ES6 constructor for element initialization

Hi Ryosuke,

Could you say more about why this is a requirement? In particular, why you 
require that developers type

```js
class MyElement extends HTMLElement {
  constructor(htmlElementConstructorOptions, ...extraArgs) {
super(htmlElementConstructorOptions);
// initialization code here, potentially using extraArgs for non-parser 
cases
  }
}
```

instead of them typing

```js
class MyElement extends HTMLElement {
  [Element.create](...extraArgs) {
// initialization code here, potentially using extraArgs for non-parser 
cases
  }
}
```

? This kind of inversion-of-control pattern is, as I've tried to point out, 
fairly common in UI frameworks and in programming in general. "Don't call me, 
I'll call you" is the catchphrase, explained in 
https://en.wikipedia.org/wiki/Hollywood_principle. As the article says:

> It is a useful paradigm that assists in the development of code with high 
> cohesion and low coupling that is easier to debug, maintain and test. ... 
> Most beginners are first introduced to programming from a diametrically 
> opposed viewpoint. ... [But] It would be much more elegant if the programmer 
> could concentrate on the application [...] and leave the parts common to 
> every application to something else.

If this is a formal objection-level complaint, I'm motivated to understand why 
you guys don't think this software engineering best-practice applies to custom 
elements. It seems like a textbook example of where inversion-of-control 
applies.

(BTW I really recommend that Wikipedia article as reading for anyone 
interested; it ties together in one place a lot of wisdom about object-oriented 
design that I've had to absorb in bits and pieces throughout the years. I wish 
I'd seen it earlier.)

Re: Minimum viable custom elements

2015-01-16 Thread Ryosuke Niwa

> On Jan 16, 2015, at 9:43 AM, Steve Faulkner  wrote:
> 
> 
> On 16 January 2015 at 16:52, Anne van Kesteren  > wrote:
>  Again, I think that unless we solve the styling problem for
> native elements, we're not going to see them adopted, not even if you
> can subclass them (and proper subclassing without the is="" hack is
> another hard problem, as explained).
> 
> The demo i pointed to previously by Alice Boxhall from Google appears to 
> overcome the styling of checkboxes/radio buttons issue
> https://rawgit.com/alice/web-components-demos/master/index.html 
>   (view in 
> chrome)

That demo seems to work because the only thing it's doing is changing the 
appearance of radio buttons and checkboxes.  But this approach poses some 
implementation challenges for us (WebKit/Safari) because we need to ignore the 
"rendered" (what's displayed on screen) content and follow the underlying DOM.

Imagine someone had put two radio buttons inside the shadow DOM of a radio 
button.  Now, we might say that's non-sensical but my point is that authors 
could do that since there's nothing that prevents them from doing it.  In that 
case, should we expose a single underlying radio button to AT or should we 
expose two radio buttons as shown on the screen?

It's possible we can specify some well defined behavior - e.g. we could say 
that we use underlying DOM element's accessibility role in the absence of any 
explicit or implicit aria roles in its shadow DOM.  But at that point, we don't 
even need to use is="" attribute.  Since UAs would know which element inherits 
from what element, we could use that information to implement such a behavior.

- R. Niwa

Re: Minimum viable custom elements

2015-01-16 Thread Ryosuke Niwa

> On Jan 16, 2015, at 9:58 AM, Anne van Kesteren  wrote:
> 
> On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa  wrote:
>> And I'm suggesting to do the same (picking the simplest design) in HTML 
>> custom elements by only supporting synchronous definition of elements, and 
>> letting authors and frameworks decide how to "upgrade" existing elements if 
>> they want to.
> 
> That seems to put us at an impasse. I get the impression this scenario
> is important to Google and their two-stage constructor design
> addresses it. To convince them it sounds like they need to see at
> least a plausible strategy for custom elements v2 that addresses this.

I get that.  However, nobody has suggested a design that satisfies both of our 
requirements: using ES6 constructor for element initialization while supporting 
asynchronous definitions of custom elements.

> At which point we're back to something like "dummy replacement" with
> its problems. Or perhaps something like "HTML modules", where you
> import a whole swath of (custom) elements at once.

Or we could simply set the prototype.  That has a bunch of problems we've 
discussed but given that's what Google has spec'ed and shipped in their 
browser, I have a hard time believing that it would be an issue for them.  So 
we could simply do that if such an approach proves to be popular among 
developers.  We can simply add something like "upgraded" callback for that 
purpose.  In other words, use ES6 constructor for custom element creations 
within the parser and for "new MyCustomElement" and provide a separate 
lifecycle callback if the author chooses to "upgrade" existing elements that 
are already in the document.

- R. Niwa

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa  wrote:
> And I'm suggesting to do the same (picking the simplest design) in HTML 
> custom elements by only supporting synchronous definition of elements, and 
> letting authors and frameworks decide how to "upgrade" existing elements if 
> they want to.

That seems to put us at an impasse. I get the impression this scenario
is important to Google and their two-stage constructor design
addresses it. To convince them it sounds like they need to see at
least a plausible strategy for custom elements v2 that addresses this.
At which point we're back to something like "dummy replacement" with
its problems. Or perhaps something like "HTML modules", where you
import a whole swath of (custom) elements at once.

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

On 16 January 2015 at 16:52, Anne van Kesteren  wrote:

>  Again, I think that unless we solve the styling problem for
> native elements, we're not going to see them adopted, not even if you
> can subclass them (and proper subclassing without the is="" hack is
> another hard problem, as explained).
>

The demo i pointed to previously by Alice Boxhall from Google appears to
overcome the styling of checkboxes/radio buttons issue
https://rawgit.com/alice/web-components-demos/master/index.html  (view in
chrome)

but do you see a viable way to get there?


I don't have the technical understanding to see any way of getting there
;-)
--

Regards

SteveF
HTML 5.1

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner
 wrote:
> I have not suggested is= as the method that must be implemented (I have not
> demanded anything), what I have tried to suggest is that minimum viable
> custom elements with all accessibility as bolt-on is a poor solution by
> design.  From an acc view it means custom elements are nothing more than
> s with fancy names.

Sure, I hope everyone understands that, but do you see a viable way to
get there? Again, I think that unless we solve the styling problem for
native elements, we're not going to see them adopted, not even if you
can subclass them (and proper subclassing without the is="" hack is
another hard problem, as explained).

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

Hi Anne,

I have not suggested is= as the method that must be implemented (I have not
demanded anything), what I have tried to suggest is that minimum viable
custom elements with all accessibility as bolt-on is a poor solution by
design.  From an acc view it means custom elements are nothing more than
s with fancy names.



--

Regards

SteveF
HTML 5.1 

On 16 January 2015 at 13:16, Anne van Kesteren  wrote:

> On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner
>  wrote:
> > With custom tags everything must be bolted on, with type extensions this
> is
> > not the case.
>
> I don't disagree with this, but is="" solves none of the problems of
> why developers moved away from native elements in the first place. As
> long as styling native form controls is a problem, is="" is not going
> to help us. In other words, is="" is not what is going to make Gmail
> stop its  abuse to mean . is="" solves none of the
> problems for which ARIA was invented as a workaround.
>
> Furthermore, is="" has considerably worse developer ergonomics
> compared to custom elements making it unlikely to be used much.
>
>
> > It may be that it is too hard to implement type extensions (i freely
> admit
> > much of the discussion on this thread is over my head), but I do not
> think
> > that it should be dismissed out of hand or that the consideration should
> > characterised as "longdesc mark II" ;-)
>
> is="" is not that hard. What is hard is making subclassing native
> elements work with good developer ergonomics. Making the markup of a
> subclass of HTMLButtonElement just as elegant as a subclass of
> HTMLElement is.
>
>
> --
> https://annevankesteren.nl/
>

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 8:18 PM, Dimitri Glazkov  wrote:
> Why is "Not having identity at creation-time is currently a mismatch with
> the rest of the platform" a problem? Why does it all have to be consistent
> across the board? Are there any other platform objects that are created by
> HTML parser or a similar device?

Domenic explained how we could potentially reconcile this, but just to be clear.

Whenever the browser platform deviates from the norm (e.g. Java-esque
DOM API), there's considerable frustration in the community. And it is
long-lasting. E.g. I still get complaints about APIs I'm maintaining
the standard for that are now fifteen years old. (And I didn't even
design!)

That tells me that developer ergonomics are important and what we
deploy will last a long time. Assuming we deploy it across browsers.

Now if the dominant subclass pattern is not a two-stage process with a
custom upgrade method the DOM will continue to be odd. We may have to
accept this, but I have the feeling that the alternatives have not
been given due consideration. I think we owe it to Yehuda and Ryosuke
and others to carefully weigh the alternatives.

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner
 wrote:
> With custom tags everything must be bolted on, with type extensions this is
> not the case.

I don't disagree with this, but is="" solves none of the problems of
why developers moved away from native elements in the first place. As
long as styling native form controls is a problem, is="" is not going
to help us. In other words, is="" is not what is going to make Gmail
stop its  abuse to mean . is="" solves none of the
problems for which ARIA was invented as a workaround.

Furthermore, is="" has considerably worse developer ergonomics
compared to custom elements making it unlikely to be used much.

> It may be that it is too hard to implement type extensions (i freely admit
> much of the discussion on this thread is over my head), but I do not think
> that it should be dismissed out of hand or that the consideration should
> characterised as "longdesc mark II" ;-)

is="" is not that hard. What is hard is making subclassing native
elements work with good developer ergonomics. Making the markup of a
subclass of HTMLButtonElement just as elegant as a subclass of
HTMLElement is.

-- 
https://annevankesteren.nl/

Re: Minimum viable custom elements

On 16 January 2015 at 10:25, Steve Faulkner 
wrote:

> https://rawgit.com/alice/web-components-demos/master/index.html


apologies, this demo needs chrome to illustrate it working well.

--

Regards

SteveF
HTML 5.1

Re: Minimum viable custom elements

hi ted,

I think others have responded to your question, but wanted to chip in.
I agree that for non interactive elements the usefulness of type extensions
is limited, but not useless.
For example: An experiment subclassing footer [5] and one implementing the
HTML5 outline algorithm [6]

There has been a popular mantra in regards to web accessibility support and
the benefits of native HTML

"built in is better than bolt on"

See the First rule of ARIA [1]

With custom tags everything must be bolted on, with type extensions this is
not the case.

In order to make custom interactive elements accessible and usable by
people with disabilities, there are a lot of hoops developers must jump
through. [3] I think reducing this burden on the developer is a worthwhile
technical design consideration for Custom Element implementation in
browsers.

See the Custom Elements Semantics section of the Custom Elements spec [2]
and the recent article by Bruce Lawson
'On the accessibility of web components. Again'. [4] which includes a link
to an example of a input type radio type extension [7]. Another example is
a disclosure button type extension [8].

It may be that it is too hard to implement type extensions (i freely admit
much of the discussion on this thread is over my head), but I do not think
that it should be dismissed out of hand or that the consideration should
characterised as "longdesc mark II" ;-)


[1] http://w3c.github.io/aria-in-html/#first-rule-of-aria-use
[2] http://w3c.github.io/webcomponents/spec/custom/#semantics
[3]
http://w3c.github.io/aria-in-html/#custom-control-accessible-development-checklist
[4]
http://www.brucelawson.co.uk/2014/on-the-accessibility-of-web-components-again/
[5] https://github.com/ThePacielloGroup/w3c-footnote
[6] http://thepaciellogroup.github.io/html5-h/demo-fallback.html
[7] https://rawgit.com/alice/web-components-demos/master/index.html
[8] https://github.com/ThePacielloGroup/disclosure-button


--

Regards

SteveF
HTML 5.1 

On 15 January 2015 at 23:33, Edward O'Connor  wrote:

> Hi all,
>
> Steve wrote:
>
> >> [I]t also does not address subclassing normal elements. Again, while
> >> that seems desirable
> >
> > Given that subclassing normal elements is the easiest and most robust
> > method (for developers) of implementing semantics[1] and interaction
> > support necessary for accessibility I would suggest it is undesirable
> > to punt on it.
>
> Apologies in advance, Steve, if I'm missing something obvious. I
> probably am.
>
> I've been writing an article about turtles and I've gotten to the point
> that six levels of headings aren't enough. I want to use a seventh-level
> heading element in this article, but HTML only has h1–6. Currently,
> without custom elements, I can do this:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> Suppose instead that TedHaitchSeven is a subclass of HTMLElement and
> I've registered it as . In its constructor or createdCallback or
> whatever, I add appropriate role and aria-level attributes. Now I can
> write this:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> This is just as accessible as the  was, but is considerably more
> straightforward to use. So yay custom elements!
>
> If I wanted to use is="" to do this, I guess I could write:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> How is this easier? How is this more robust?
>
> I think maybe you could say this is more robust (if not easier) because,
> in a browser with JavaScript disabled, AT would see an .  is at
> least a heading, if not one of the right level. But in such a browser
> the  example above is even better, because AT would see both that
> the element is a heading and it would also see the correct level.
>
> OK, so let's work around the wrong-heading-level-when-JS-is-disabled
> problem by explicitly overriding 's implicit heading level:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> I guess this is OK, but seeing aria-level=7 on and  rubs me the
> wrong way even if it's not technically wrong, and I don't see how this
> is easier or more robust than the other options.
>
>
> Thanks,
> Ted
>
>

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa  wrote:

>
> > On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov 
> wrote:
> >
> > FWIW, I think that element upgrade is sort of fundamental to the
> usefulness of custom elements. In a world where most scripts are
> non-blocking (that's hopefully the modern world we should aim for), I'll
> effectively expect to walk the tree anyway.
>
> Allowing loading scripts asynchronously, including ones that define custom
> elements, is one thing; automatically resolving script dependencies for
> custom elements is another.


What are the "script dependencies for custom elements" here?


> When an author imports a ES6 module, we don't create a fake object which
> gets resolved later by rewriting its prototype.
>

These are two completely different things, right? In one situation, you are
dealing with HTML Parser and blocking thereof. In another, there's no such
concern.

:DG<

Re: Minimum viable custom elements

> On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov  wrote:
> 
> FWIW, I think that element upgrade is sort of fundamental to the usefulness 
> of custom elements. In a world where most scripts are non-blocking (that's 
> hopefully the modern world we should aim for), I'll effectively expect to 
> walk the tree anyway.

Allowing loading scripts asynchronously, including ones that define custom 
elements, is one thing; automatically resolving script dependencies for custom 
elements is another.  When an author imports a ES6 module, we don't create a 
fake object which gets resolved later by rewriting its prototype.

Even if we were to agree this is desirable, I don't think we're ready to bake 
the exact mechanism by which such asynchronous custom elements upgrades happens 
in the browser since the introduction of ES6 models is likely rewriting the 
landscape of how authors load external dependencies soon.

Of course, I'm sympathetic to the view that we should make upgrading easier; 
e.g. by exposing the list of event listeners attached on an element so that 
replacing/cloning an element will be easier.

- R. Niwa

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 5:29 PM, Ryosuke Niwa  wrote:

>
> The only reason you need to have the two-stage setup is because you want
> to support asynchronous upgrading of elements.  As we have repeatedly
> stated in the past, we don't support a design that involves upgrading
> elements after the element construction if it meant that we can't use ES6
> constructor in the non-upgrade case.  We'll submit a formal objection if
> necessary.
>

Could you summarize the reasons behind such a strong position?

:DG<

Re: Minimum viable custom elements

> On Jan 15, 2015, at 3:17 PM, Domenic Denicola  wrote:
> 
> From: Ryosuke Niwa [mailto:rn...@apple.com] 
> 
>> If ES6 classes' constructor doesn't fundamentally work with custom elements, 
>> then why don't we change the design of ES6 classes.
> 
> We would essentially be saying that the design of ES6 classes should be built 
> to support one particular construction pattern (two-stage construction), over 
> any others. Why not design it to support three-stage construction? There are 
> surely libraries that have more than two phases of boot-up.
> 
> One way to think about it is that there is a "base constructor" for all 
> classes (corresponding, in spec language, to the definition of 
> [[Construct]]), that in the newest TC39 design does the simplest thing 
> possible. The DOM needs a more complicated setup. Shouldn't that be the DOM's 
> responsibility to encode into *its* base constructor?

No, DOM doesn't require two-stage construction any more than a regular builtin 
objects in ES6.

The only reason you need to have the two-stage setup is because you want to 
support asynchronous upgrading of elements.  As we have repeatedly stated in 
the past, we don't support a design that involves upgrading elements after the 
element construction if it meant that we can't use ES6 constructor in the 
non-upgrade case.  We'll submit a formal objection if necessary.

>> Saying that TC39 doesn't have a time is like saying we can't make a spec 
>> change because WG has already decided to move the spec into REC by the end 
>> of the year in W3C.
> 
> That, I certainly agree with. Any process reasons brought up are bogus. But 
> the technical arguments for "the simplest base constructor possible" in the 
> language are pretty sound. They're in fact reasons that motivated TC39 to go 
> into a last-minute redesign marathon over the holiday weeks, to get *away* 
> from the more complicated "base constructor" that contained a two-stage 
> allocation/initialization split.

That's fine.  And I'm suggesting to do the same (picking the simplest design) 
in HTML custom elements by only supporting synchronous definition of elements, 
and letting authors and frameworks decide how to "upgrade" existing elements if 
they want to.

- R. Niwa

Re: Minimum viable custom elements

2015-01-15 Thread Brian Kardell

On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola  wrote:

> Steve's concerns are best illustrated with a more complicated element like
> . He did a great pull request to the custom elements spec that
> contrasts all the work you have to do with  vs.  is="tequila-button">:
>
> https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example vs.
> https://w3c.github.io/webcomponents/spec/custom/#type-extension-example
>
> The summary is that you *can* duplicate *some* of the semantics and
> accessibility properties of a built-in element when doing custom tags, but
> it's quite arduous. (And, it has minor undesirable side effects, such as
> new DOM attributes which can be overwritten, whereas native role semantics
> are baked in.)
>
> Additionally, in some cases you *can't* duplicate the semantics and
> accessibility:
>
>
> https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md#incomplete-mitigation-strategies
>
> An easy example is that you can never get a screen reader to announce
>  as a paragraph, while it will happily do so for  is="custom-p">. This is because there is no ARIA role for paragraphs that
> you could set in the createdCallback of your CustomP.
>
> However, this second point is IMO just a gap in the capabilities of ARIA
> that should be addressed. If we could assume it will be addressed on the
> same timeline as custom elements being implemented (seems ... not
> impossible), that still leaves the concern about having to duplicate all
> the functionality of a button, e.g. keyboard support, focus support,
> reaction to the presence/absence of the disabled attribute, etc.
>
> -Original Message-
> From: Edward O'Connor [mailto:eocon...@apple.com]
> Sent: Thursday, January 15, 2015 18:33
> To: WebApps WG
> Subject: Re: Minimum viable custom elements
>
> Hi all,
>
> Steve wrote:
>
> >> [I]t also does not address subclassing normal elements. Again, while
> >> that seems desirable
> >
> > Given that subclassing normal elements is the easiest and most robust
> > method (for developers) of implementing semantics[1] and interaction
> > support necessary for accessibility I would suggest it is undesirable
> > to punt on it.
>
> Apologies in advance, Steve, if I'm missing something obvious. I probably
> am.
>
> I've been writing an article about turtles and I've gotten to the point
> that six levels of headings aren't enough. I want to use a seventh-level
> heading element in this article, but HTML only has h1–6. Currently, without
> custom elements, I can do this:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> Suppose instead that TedHaitchSeven is a subclass of HTMLElement and I've
> registered it as . In its constructor or createdCallback or
> whatever, I add appropriate role and aria-level attributes. Now I can write
> this:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> This is just as accessible as the  was, but is considerably more
> straightforward to use. So yay custom elements!
>
> If I wanted to use is="" to do this, I guess I could write:
>
> Cuora amboinensis, the southeast Asian box turtle
>
> How is this easier? How is this more robust?
>
> I think maybe you could say this is more robust (if not easier) because,
> in a browser with JavaScript disabled, AT would see an .  is at
> least a heading, if not one of the right level. But in such a browser the
>  example above is even better, because AT would see both that the
> element is a heading and it would also see the correct level.
>
> OK, so let's work around the wrong-heading-level-when-JS-is-disabled
> problem by explicitly overriding 's implicit heading level:
>
> Cuora amboinensis, the southeast Asian box
> turtle
>
> I guess this is OK, but seeing aria-level=7 on and  rubs me the wrong
> way even if it's not technically wrong, and I don't see how this is easier
> or more robust than the other options.
>
>
> Thanks,
> Ted
>
>

I think you really need look no further than HTML as Custom Elements work
to see how difficult it would be to get accessibility right even if we had
good APIs, which, as Domenic pointed out, we really don't.

Anyway, it seems like one of the biggest criticisms we have seen of custom
elements anyone has made has to do with accessibility... It definitely
doesn't seem desirable to make it *harder* to get that right if we can
avoid it, because this could definitely play into the success or failure
story writ large.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

RE: Minimum viable custom elements

2015-01-15 Thread Domenic Denicola

Steve's concerns are best illustrated with a more complicated element like 
. He did a great pull request to the custom elements spec that 
contrasts all the work you have to do with  vs. :

https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example vs. 
https://w3c.github.io/webcomponents/spec/custom/#type-extension-example

The summary is that you *can* duplicate *some* of the semantics and 
accessibility properties of a built-in element when doing custom tags, but it's 
quite arduous. (And, it has minor undesirable side effects, such as new DOM 
attributes which can be overwritten, whereas native role semantics are baked 
in.)

Additionally, in some cases you *can't* duplicate the semantics and 
accessibility:

https://github.com/domenic/html-as-custom-elements/blob/master/docs/accessibility.md#incomplete-mitigation-strategies

An easy example is that you can never get a screen reader to announce 
 as a paragraph, while it will happily do so for . 
This is because there is no ARIA role for paragraphs that you could set in the 
createdCallback of your CustomP.

However, this second point is IMO just a gap in the capabilities of ARIA that 
should be addressed. If we could assume it will be addressed on the same 
timeline as custom elements being implemented (seems ... not impossible), that 
still leaves the concern about having to duplicate all the functionality of a 
button, e.g. keyboard support, focus support, reaction to the presence/absence 
of the disabled attribute, etc.

-Original Message-
From: Edward O'Connor [mailto:eocon...@apple.com] 
Sent: Thursday, January 15, 2015 18:33
To: WebApps WG
Subject: Re: Minimum viable custom elements

Hi all,

Steve wrote:

>> [I]t also does not address subclassing normal elements. Again, while 
>> that seems desirable
>
> Given that subclassing normal elements is the easiest and most robust 
> method (for developers) of implementing semantics[1] and interaction 
> support necessary for accessibility I would suggest it is undesirable 
> to punt on it.

Apologies in advance, Steve, if I'm missing something obvious. I probably am.

I've been writing an article about turtles and I've gotten to the point that 
six levels of headings aren't enough. I want to use a seventh-level heading 
element in this article, but HTML only has h1–6. Currently, without custom 
elements, I can do this:

Cuora amboinensis, the southeast Asian box 
turtle

Suppose instead that TedHaitchSeven is a subclass of HTMLElement and I've 
registered it as . In its constructor or createdCallback or whatever, I 
add appropriate role and aria-level attributes. Now I can write this:

Cuora amboinensis, the southeast Asian box turtle

This is just as accessible as the  was, but is considerably more 
straightforward to use. So yay custom elements!

If I wanted to use is="" to do this, I guess I could write:

Cuora amboinensis, the southeast Asian box turtle

How is this easier? How is this more robust?

I think maybe you could say this is more robust (if not easier) because, in a 
browser with JavaScript disabled, AT would see an .  is at least a 
heading, if not one of the right level. But in such a browser the  example 
above is even better, because AT would see both that the element is a heading 
and it would also see the correct level.

OK, so let's work around the wrong-heading-level-when-JS-is-disabled
problem by explicitly overriding 's implicit heading level:

Cuora amboinensis, the southeast Asian box 
turtle

I guess this is OK, but seeing aria-level=7 on and  rubs me the wrong way 
even if it's not technically wrong, and I don't see how this is easier or more 
robust than the other options.

Thanks,
Ted

Re: Minimum viable custom elements

2015-01-15 Thread Edward O'Connor

Hi all,

Steve wrote:

>> [I]t also does not address subclassing normal elements. Again, while
>> that seems desirable
>
> Given that subclassing normal elements is the easiest and most robust
> method (for developers) of implementing semantics[1] and interaction
> support necessary for accessibility I would suggest it is undesirable
> to punt on it.

Apologies in advance, Steve, if I'm missing something obvious. I
probably am.

I've been writing an article about turtles and I've gotten to the point
that six levels of headings aren't enough. I want to use a seventh-level
heading element in this article, but HTML only has h1–6. Currently,
without custom elements, I can do this:

Cuora amboinensis, the southeast Asian box 
turtle

Suppose instead that TedHaitchSeven is a subclass of HTMLElement and
I've registered it as . In its constructor or createdCallback or
whatever, I add appropriate role and aria-level attributes. Now I can
write this:

Cuora amboinensis, the southeast Asian box turtle

This is just as accessible as the  was, but is considerably more
straightforward to use. So yay custom elements!

If I wanted to use is="" to do this, I guess I could write:

Cuora amboinensis, the southeast Asian box turtle

How is this easier? How is this more robust?

I think maybe you could say this is more robust (if not easier) because,
in a browser with JavaScript disabled, AT would see an .  is at
least a heading, if not one of the right level. But in such a browser
the  example above is even better, because AT would see both that
the element is a heading and it would also see the correct level.

OK, so let's work around the wrong-heading-level-when-JS-is-disabled
problem by explicitly overriding 's implicit heading level:

Cuora amboinensis, the southeast Asian box 
turtle

I guess this is OK, but seeing aria-level=7 on and  rubs me the
wrong way even if it's not technically wrong, and I don't see how this
is easier or more robust than the other options.

Thanks,
Ted

RE: Minimum viable custom elements

2015-01-15 Thread Domenic Denicola

From: Ryosuke Niwa [mailto:rn...@apple.com] 

> Unfortunately for developers, native syntax for inheritance in Stink 2.0 
> cannot be used to subclass views in Odour.

The native syntax for inheritance can definitely be used! You just can't 
override the constructor, since constructing a view is a very delicate 
operation. Instead, you can provide some code that runs during the constructor, 
by overriding a specific method.

I wouldn't call this incompatible, any more than saying that ASP.NET Page 
classes are incompatible with C# classes:

http://www.4guysfromrolla.com/articles/041305-1.aspx

(you define Page_Load instead of the constructor). I imagine I could find many 
other frameworks (perhaps ones written for Stink developers?) where when you 
use a framework and derive from a framework-provided base class, you can't 
override the framework's methods or constructors directly, but instead have to 
override provided hooks.

> If ES6 classes' constructor doesn't fundamentally work with custom elements, 
> then why don't we change the design of ES6 classes.

We would essentially be saying that the design of ES6 classes should be built 
to support one particular construction pattern (two-stage construction), over 
any others. Why not design it to support three-stage construction? There are 
surely libraries that have more than two phases of boot-up.

One way to think about it is that there is a "base constructor" for all classes 
(corresponding, in spec language, to the definition of [[Construct]]), that in 
the newest TC39 design does the simplest thing possible. The DOM needs a more 
complicated setup. Shouldn't that be the DOM's responsibility to encode into 
*its* base constructor?

> Saying that TC39 doesn't have a time is like saying we can't make a spec 
> change because WG has already decided to move the spec into REC by the end of 
> the year in W3C.

That, I certainly agree with. Any process reasons brought up are bogus. But the 
technical arguments for "the simplest base constructor possible" in the 
language are pretty sound. They're in fact reasons that motivated TC39 to go 
into a last-minute redesign marathon over the holiday weeks, to get *away* from 
the more complicated "base constructor" that contained a two-stage 
allocation/initialization split.

Re: Minimum viable custom elements

> On Jan 15, 2015, at 11:28 AM, Domenic Denicola  wrote:
> 
> From: Dimitri Glazkov [mailto:dglaz...@google.com] 
> 
>> Why is "Not having identity at creation-time is currently a mismatch with 
>> the rest of the platform" a problem? Why does it all have to be consistent 
>> across the board? Are there any other platform objects that are created by 
>> HTML parser or a similar device?
> 
> In IRC we've been discussing how I don't think there's actually any 
> (observable) mismatch with the rest of the platform if we are careful.
> 
> In particular, if we make it a rule that when parsing a given fragment, 
> createdCallbacks run in registration order (not, say, in parse order), I 
> think it works. Because then the built-in elements, which are (conceptually) 
> registered first, go through the __proto__-munge + createdCallback() process 
> first. Then, when the createdCallback() for any user-defined elements runs, 
> all existing elements look to be already upgraded.
> 
> If we want createdCallbacks to run in parse order (which does seem probably 
> better, although I'd be curious for concrete arguments why), then the only 
> deviation required between custom and built-in elements is privileging the 
> native elements with some ability to jump to the front the queue. Which seems 
> pretty reasonable given that we already have lots of cases where custom 
> elements do things sorta-async and native elements need to do things more 
> synchronously.

Let's think about this for a minute.

Imagine that a hypothetical technology company Durian which has a popular 
platform called dOS with its own UI framework called Odour coupled with a 
programming language named Stink.  In their exciting annual developer 
conference of the year, Durian introduces Stink 2.0 which supports proper OOP 
as well as a way to subclass a view in Odour.  Developers rejoice for finally 
being able to use constructors, inheritance, etc… and subclass views in their 
applications.  Unfortunately for developers, native syntax for inheritance in 
Stink 2.0 cannot be used to subclass views in Odour.  In order to inherit from 
a view in Odour, Durian explains, developers must use a helper function.  
Developers outrage in despair and yells, "why on the earth did you have to make 
them incompatible?"

I ask the same question.  If ES6 classes' constructor doesn't fundamentally 
work with custom elements, then why don't we change the design of ES6 classes.  
Saying that TC39 doesn't have a time is like saying we can't make a spec change 
because WG has already decided to move the spec into REC by the end of the year 
in W3C.  We shouldn't be making technical decisions like that especially for 
something as fundamental as supporting classes in the Web.

- R. Niwa

Re: Minimum viable custom elements

2015-01-15 Thread Tab Atkins Jr.

On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa  wrote:
>> On Jan 15, 2015, at 11:47 AM, Brian Kardell  wrote:
>> Not to sidetrack the discussion but Steve Faulker made what I think was a 
>> valid observation and I haven't seen a response... Did I miss it?
>
> When and in which thread?  Could you give us a pointer?

Earlier in *this* thread.

~TJ

Re: Minimum viable custom elements


> On Jan 15, 2015, at 11:47 AM, Brian Kardell  wrote:
> 
> Not to sidetrack the discussion but Steve Faulker made what I think was a 
> valid observation and I haven't seen a response... Did I miss it?

When and in which thread?  Could you give us a pointer?

- R. Niwa

Re: Minimum viable custom elements

2015-01-15 Thread Brian Kardell

Not to sidetrack the discussion but Steve Faulker made what I think was a
valid observation and I haven't seen a response... Did I miss it?

RE: Minimum viable custom elements

2015-01-15 Thread Domenic Denicola

From: Dimitri Glazkov [mailto:dglaz...@google.com] 

> Why is "Not having identity at creation-time is currently a mismatch with the 
> rest of the platform" a problem? Why does it all have to be consistent across 
> the board? Are there any other platform objects that are created by HTML 
> parser or a similar device?

In IRC we've been discussing how I don't think there's actually any 
(observable) mismatch with the rest of the platform if we are careful.

In particular, if we make it a rule that when parsing a given fragment, 
createdCallbacks run in registration order (not, say, in parse order), I think 
it works. Because then the built-in elements, which are (conceptually) 
registered first, go through the __proto__-munge + createdCallback() process 
first. Then, when the createdCallback() for any user-defined elements runs, all 
existing elements look to be already upgraded.

If we want createdCallbacks to run in parse order (which does seem probably 
better, although I'd be curious for concrete arguments why), then the only 
deviation required between custom and built-in elements is privileging the 
native elements with some ability to jump to the front the queue. Which seems 
pretty reasonable given that we already have lots of cases where custom 
elements do things sorta-async and native elements need to do things more 
synchronously.

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren  wrote:
>
>
> * I think we could iterate towards a v2 that has an aspect of
> upgrading but perhaps works a bit differently from the current setup.
> E.g. a way to include an entire subtree of custom elements with a
> fallback mechanism of sorts. Or perhaps something inspired by
> JavaScript modules.
>

Why is "Not having identity at creation-time is currently a mismatch with
the rest of the platform" a problem? Why does it all have to be consistent
across the board? Are there any other platform objects that are created by
HTML parser or a similar device?

> * Upgrading can be added, but moving from Brain transplants to a more
> normal working constructor would be impossible after the fact.
>

Why is this a problem? Is this for design purity?

:DG<

Re: Minimum viable custom elements