Re: Base Template (Was Re: Minimum viable custom elements)

2015-02-13 Thread Jan Miksovsky
Dimitri: Okay, I can follow up with Ryosuke. I’m happy to share our thoughts 
and needs for subclassing components.

Anne/Steve: I’d originally indicated that this technique couldn't be applied to 
extending native HTML elements. Since the two of your seemed interested in 
that, I spent some time tinkering with the idea, and it turns out that this 
technique can be made to work for that situation. I’ve posted a quick demo 
(http://janmiksovsky.github.io/base-template/extendButton.html 
http://janmiksovsky.github.io/base-template/extendButton.html) showing 
subclassing of a standard HTML button element. This works best under native 
Shadow DOM. Under polyfilled Shadow DOM, base class styles can’t (yet?) be 
inherited.

Anyway, I mention this in case it opens up some ideas. Thanks for the 
inspiration!

Re: Base Template (Was Re: Minimum viable custom elements)

2015-02-12 Thread Dimitri Glazkov
Ryosuke, Jan,

It might be useful for you two folks to work through Jan's Shadow DOM
composition/inheritance insight (use cases?) together and see how they
could be resolved without having multiple shadow roots per element. I would
love to take advantage of all the work you both have done thinking about
this problem separately.

:DG

On Thu, Feb 12, 2015 at 9:46 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 12, 2015, at 4:50 AM, Steve Faulkner faulkner.st...@gmail.com
 wrote:


 On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote:

 which is a very different problem from what you want to solve, no?


 The problem I think needs solving for minimum viable custom elements is
 reducing reliance on bolt-on accessibility. From the example provided
 http://janmiksovsky.github.io/base-template/ it appears that in this
 instance it does achieve that end.

 I don't know whether this will extend to other UI controls or whether it
 is a practical solution, which is why I brought it to the list for
 discussion.


 Again, this proposal or subclassing problem is nothing to do with custom
 elements but all do with shadow DOM.

 Ironically, I've pointed out the exact same problem explained in this page
 last April and proposed to change the way shadow DOM works to solve it:
 https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html

 - R. Niwa




Re: Minimum viable custom elements

2015-02-12 Thread Anne van Kesteren
On Thu, Feb 12, 2015 at 11:33 AM, Steve Faulkner
faulkner.st...@gmail.com wrote:
 this turned up today:
 A possible solution for web component subclasses
 https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses

 needs people who actually understand this stuff to critique ;-)

Well, it starts by saying [I]s it possible to define HTML custom
element subclasses that can fill in base class insertion points?
which is a very different problem from what you want to solve, no?
Under limitations it says As written, this technique cannot be used
to subclass standard HTML elements. which makes that even more clear.


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-02-12 Thread Steve Faulkner
this turned up today:
A possible solution for web component subclasses
https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses

needs people who actually understand this stuff to critique ;-)

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 14 January 2015 at 14:45, Anne van Kesteren ann...@annevk.nl wrote:

 I've been trying to think of the smallest setup that adds value, can
 get broad agreement, and is therefore hopefully interoperable fast.

 * ES6-style class syntax to declare the imperative constructor.
 * No subclassing of normal elements for now.
 * registerElement() to enable declarative syntax and createElement().
 * Parsing of declarative syntax invokes the registered constructor
 synchronously.
 * Existing lifecycle callbacks plus those agreed (copying, adopting).

 Notably this does not address upgrading. I think we can defer
 upgrading as it can be implemented in script fairly easily. You await
 for the imperative constructors to load and DOMContentLoaded at which
 point you traverse the tree and invoke replace() on those elements you
 want to upgrade. Ideally at some point we find a declarative solution
 for this, perhaps something like HTML modules, but shipping a v1 of
 custom elements in multiple browsers should not have to wait for that.

 It also does not address subclassing normal elements. Again, while
 that seems desirable the current ideas are not attractive long term
 solutions. Punting on it in order to ship a v1 available everywhere
 seems preferable.


 --
 https://annevankesteren.nl/




Re: Minimum viable custom elements

2015-02-12 Thread Steve Faulkner
On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote:

 which is a very different problem from what you want to solve, no?


The problem I think needs solving for minimum viable custom elements is
reducing reliance on bolt-on accessibility. From the example provided
http://janmiksovsky.github.io/base-template/ it appears that in this
instance it does achieve that end.

I don't know whether this will extend to other UI controls or whether it is
a practical solution, which is why I brought it to the list for discussion.

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/


Base Template (Was Re: Minimum viable custom elements)

2015-02-12 Thread Ryosuke Niwa

 On Feb 12, 2015, at 4:50 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
 
 
 On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl 
 mailto:ann...@annevk.nl wrote:
 which is a very different problem from what you want to solve, no?
 
 The problem I think needs solving for minimum viable custom elements is 
 reducing reliance on bolt-on accessibility. From the example provided 
 http://janmiksovsky.github.io/base-template/ 
 http://janmiksovsky.github.io/base-template/ it appears that in this 
 instance it does achieve that end.
 
 I don't know whether this will extend to other UI controls or whether it is a 
 practical solution, which is why I brought it to the list for discussion.

Again, this proposal or subclassing problem is nothing to do with custom 
elements but all do with shadow DOM.

Ironically, I've pointed out the exact same problem explained in this page last 
April and proposed to change the way shadow DOM works to solve it:
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html 
https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html

- R. Niwa



Re: Minimum viable custom elements

2015-02-05 Thread Chris Bateman
As an example I made a simple input-based Custom Element which prevents
alphabetic input, and dropped it in an very simple Ember app.

Here's the version with a subclassed input:
http://jsbin.com/mevemu/1/edit?html,output

And the version with an input nested in a custom element:
http://jsbin.com/hepuvif/1/edit?html,output. The custom element adds an
input if one wasn't provided in the markup.

Click the Show button to inject the CE. The CE is registered at the top,
and the template (where it's included) is at the bottom.

Note that the 2nd version isn't completely functional because Ember isn't
expecting to update a value based on an attribute - but this is something
that Ember can solve (they've stated intent to support Web Components).


So - it was extra code to map the input's value to the custom element (and
I didn't do a very robust job of it) - but I'll let you draw your own
conclusions. In my opinion - it's definitely not as ideal as the subclass -
but maybe it's not prohibitive either.


** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you
add the is= attribute to an element that's already been created. Ember
builds up its templates into document fragments - so the input failed to
upgrade in Chrome. This doesn't happen with the polyfill, however, so I got
around the issue by forcing the polyfill to override the native
document.registerElement.


Chris



On Wed, Feb 4, 2015 at 1:15 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com 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

2015-02-05 Thread Erik Bryn
Thanks for the mentioning the Ember issue Chris :) I've filed it here:
https://github.com/tildeio/htmlbars/issues/288

On Thu, Feb 5, 2015 at 7:13 AM, Chris Bateman chrisb...@gmail.com wrote:
 As an example I made a simple input-based Custom Element which prevents
 alphabetic input, and dropped it in an very simple Ember app.

 Here's the version with a subclassed input:
 http://jsbin.com/mevemu/1/edit?html,output

 And the version with an input nested in a custom
 element:http://jsbin.com/hepuvif/1/edit?html,output. The custom element adds
 an input if one wasn't provided in the markup.

 Click the Show button to inject the CE. The CE is registered at the top,
 and the template (where it's included) is at the bottom.

 Note that the 2nd version isn't completely functional because Ember isn't
 expecting to update a value based on an attribute - but this is something
 that Ember can solve (they've stated intent to support Web Components).


 So - it was extra code to map the input's value to the custom element (and I
 didn't do a very robust job of it) - but I'll let you draw your own
 conclusions. In my opinion - it's definitely not as ideal as the subclass -
 but maybe it's not prohibitive either.


 ** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you add
 the is= attribute to an element that's already been created. Ember builds up
 its templates into document fragments - so the input failed to upgrade in
 Chrome. This doesn't happen with the polyfill, however, so I got around the
 issue by forcing the polyfill to override the native
 document.registerElement.


 Chris



 On Wed, Feb 4, 2015 at 1:15 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com 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

2015-02-04 Thread Ryosuke Niwa

 On Feb 4, 2015, at 7:59 AM, Domenic Denicola d...@domenic.me wrote:
 
 In IRC Anne and I were briefly discussing how type= is the is= of Web 
 Applications 1.0. That is, input type=date is similar to img is=x-gif 
 or similar---it has a reasonable fallback behavior, but in reality it is a 
 completely different control than the local name indicates.
 
 For input type 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 input type= in favor of control is= 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 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 rn...@apple.com wrote:

 See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
 https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
 first.
 On Feb 4, 2015, at 6:43 AM, Chris Bateman chrisb...@gmail.com 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:
 
  - input is=my-custom-formatter
  - input class=my-custom-formatter and a page-level listener
  - input class=my-custom-formatter and call a function after it's 
 injected
 Or my-custom-formatterinput/my-custom-formatter.  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 
 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.
 
 input type=text is=my-custom-formatter
 
 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 rn...@apple.com wrote:

 my-custom-formatterinput/my-custom-formatter


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 canvas to host a checkbox, as an
experiment:
http://codepen.io/stevef/pen/OPxvZX

note: am not saying canvas 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 http://www.w3.org/html/wg/drafts/html/master/


Re: Minimum viable custom elements

2015-02-04 Thread Ryosuke Niwa
See https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0435.html 
first.

 On Feb 4, 2015, at 6:43 AM, Chris Bateman chrisb...@gmail.com 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:
 
  - input is=my-custom-formatter
  - input class=my-custom-formatter and a page-level listener
  - input class=my-custom-formatter and call a function after it's injected

Or my-custom-formatterinput/my-custom-formatter.  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 
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.
 
 input type=text is=my-custom-formatter
 
 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 Brian Kardell
On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:

 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
 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:

 input is=x-foo

 x-fooinput/x-foo

 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

 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox

 or as a slightly contrived example,

 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider

 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
So a web page author would write
x-slider min=-100 ... etc.

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

On Wed, Feb 4, 2015 at 11:14 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote:

 On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote:


 On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com
 wrote:

 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
 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:

 input is=x-foo

 x-fooinput/x-foo

 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

 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox

 or as a slightly contrived example,

 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider

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

 On Feb 4, 2015, at 11:26 AM, Alice Boxhall aboxh...@google.com wrote:
 
 So a web page author would write
 x-slider min=-100 ... etc.
 
 and then the custom element would sprout an input type=range ...etc with 
 the attribute values copied across?

No. The page author would write x-sliderinput min=-100 …/x-slider.

- R. Niwa




Re: Minimum viable custom elements

2015-02-04 Thread Ryosuke Niwa

 On Feb 4, 2015, at 10:54 AM, Alice Boxhall aboxh...@google.com wrote:
 
 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com 
 mailto:bkard...@gmail.com wrote:
 
 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 
 mailto:chrisb...@gmail.com 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:
  
 input is=x-foo
 
 x-fooinput/x-foo
 
 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
 
 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox
 
 or as a slightly contrived example,
 
 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider
 
 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:

x-checkboxinput type=checkbox checked=true/x-checkbox
x-sliderinput type=range min=-100 max=100 value=0 
step=5/x-slider

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

 On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com 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

2015-02-04 Thread Brian Kardell
On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 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:

input is=x-foo

x-fooinput/x-foo

seems like barely a ternseness savings worth discussing.



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


Re: Minimum viable custom elements

2015-02-04 Thread Ryosuke Niwa

 On Feb 4, 2015, at 9:05 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
 
 On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 my-custom-formatterinput/my-custom-formatter
 
 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 canvas to host a checkbox, as an 
 experiment:
 http://codepen.io/stevef/pen/OPxvZX http://codepen.io/stevef/pen/OPxvZX
 
 note: am not saying canvas 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 chrisb...@gmail.com 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 Alice Boxhall
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote:



 On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:

 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
 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:

 input is=x-foo

 x-fooinput/x-foo

 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

 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox

 or as a slightly contrived example,

 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider

 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 Steve Faulkner
On 4 February 2015 at 19:05, Alice Boxhall aboxh...@google.com 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

label
x-checkbox
input type=checkbox checked=true
/x-checkbox
sign up
/label

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/


Re: Minimum viable custom elements

2015-02-04 Thread Ryosuke Niwa

 On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote:
 
 On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com 
 mailto:bkard...@gmail.com wrote:
 
 On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com 
 mailto:aboxh...@google.com wrote:
 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com wrote:
 
 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com 
 mailto:bkard...@gmail.com wrote:
 
 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com 
 mailto:chrisb...@gmail.com 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:
  
 input is=x-foo
 
 x-fooinput/x-foo
 
 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
 
 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox
 
 or as a slightly contrived example,
 
 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider
 
 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 bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:
 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
 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:

 input is=x-foo

 x-fooinput/x-foo

 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

 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox

 or as a slightly contrived example,

 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider

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

 - input is=my-custom-formatter
 - input class=my-custom-formatter and a page-level listener
 - input class=my-custom-formatter 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 time is=relative-time 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.


input type=text is=my-custom-formatter

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 rn...@apple.com wrote:


 On Feb 3, 2015, at 7:13 AM, Chris Bateman chrisb...@gmail.com 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 textarea 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-04 Thread Anne van Kesteren
On Wed, Feb 4, 2015 at 3:43 PM, Chris Bateman chrisb...@gmail.com wrote:
 An better example of both A and B (than my previous hypothetical) might be
 GitHub's time is=relative-time 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 relative-time.

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

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

For input type 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 input type= in favor of control is= or 
something). But those seem pretty speculative.



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 textarea 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 rn...@apple.com wrote:


 On Jan 31, 2015, at 10:40 AM, Chris Bateman chrisb...@gmail.com wrote:

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

 input is=number-input decimals=2

 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-03 Thread Ryosuke Niwa

 On Feb 3, 2015, at 7:13 AM, Chris Bateman chrisb...@gmail.com 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 textarea 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-02 Thread Anne van Kesteren
On Sat, Jan 31, 2015 at 10:41 PM, Elliott Sprehn espr...@chromium.org wrote:
 The animation is a custom element called paper-ripple, 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-02-02 Thread Anne van Kesteren
On Sat, Jan 31, 2015 at 7:40 PM, Chris Bateman chrisb...@gmail.com wrote:
 The -webkit-appreance CSS is definitely another issue, so here's an example
 with just JS behavior:

 input is=number-input decimals=2

The way to do this, FWIW, is input type=number step=0.01 and solve
the styling issue.


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-02-02 Thread Ryosuke Niwa

 On Jan 31, 2015, at 10:40 AM, Chris Bateman chrisb...@gmail.com wrote:
 
 The -webkit-appreance CSS is definitely another issue, so here's an example 
 with just JS behavior:
 
 input is=number-input decimals=2
 
 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 
 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-01-31 Thread Anne van Kesteren
On Sat, Jan 31, 2015 at 5:58 AM, fantasai fantasai.li...@inkedblade.net 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 tan...@cs.stanford.edu 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 aboxh...@google.com 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 Anne van Kesteren
On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
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.)


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-01-30 Thread Ryosuke Niwa

 On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com wrote:
 
 On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren ann...@annevk.nl 
 mailto:ann...@annevk.nl wrote:
 On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
 faulkner.st...@gmail.com 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 
  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 
 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 
 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-styleindex-type=tkeywords=appearancesearch=Search
 
https://www.w3.org/Search/Mail/Public/search?type-index=www-styleindex-type=tkeywords=appearancesearch=Search
https://lists.w3.org/Archives/Public/www-style/2014Jul/0334.html 
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 fantasai

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



On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com 
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-styleindex-type=tkeywords=appearancesearch=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 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 fantasai.li...@inkedblade.net wrote:
 On 01/30/2015 07:54 PM, Ryosuke Niwa wrote:


 On Jan 30, 2015, at 10:22 AM, Alice Boxhall aboxh...@google.com
 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-styleindex-type=tkeywords=appearancesearch=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 Bruce Lawson
On 29 January 2015 at 19:48, Ryosuke Niwa rn...@apple.com 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 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 http://www.paciellogroup.com/blog/2014/08/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:
button is=”my-super-button”
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 ann...@annevk.nl wrote:

 On Fri, Jan 16, 2015 at 5:45 PM, Steve Faulkner
 faulkner.st...@gmail.com 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
  divs 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-29 Thread Bruce Lawson
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com 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
input type=radio is=luscious-radio 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 Dimitri Glazkov
One additional point, unrelated to accessibility: is also enables
piggybacking to special parser behavior of existing elements. For example,
I can extend template or link.

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 bru...@opera.com wrote:

 On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
 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
 input type=radio is=luscious-radio 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
faulkner.st...@gmail.com 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 my-element 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 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 http://www.w3.org/html/wg/drafts/html/master/

On 29 January 2015 at 15:37, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner
 faulkner.st...@gmail.com 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 my-element 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 Elliott Sprehn
On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote:



 On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote:

 On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
 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
 input type=radio is=luscious-radio 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
 super-button '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 iframe is=button 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 iframe
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 paper-buton instead of paper-button.

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

- E


Re: Minimum viable custom elements

2015-01-29 Thread Brian Kardell
On Thu, Jan 29, 2015 at 1:50 PM, Elliott Sprehn espr...@chromium.org
wrote:



 On Fri, Jan 30, 2015 at 3:52 AM, Brian Kardell bkard...@gmail.com wrote:



 On Thu, Jan 29, 2015 at 10:33 AM, Bruce Lawson bru...@opera.com wrote:

 On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com
 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
 input type=radio is=luscious-radio 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
 super-button '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 iframe is=button 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 iframe
 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 paper-buton instead of paper-button.

 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 iframe
 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 button is=iframe 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 iframe class=facebook-button?  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 Bruce Lawson
On 29 January 2015 at 19:09, Brian Kardell bkard...@gmail.com 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 button but input type=date
is=fab-calendar ; input type=range is=rotary-knob; input
type=checkbox is=woot-checkbox !-- OMG the checkmark spills
outside the box and it's in corporate magenta and indigo! --

All of these degrade very nicely and work even when JS isn't present,
whereas woot-checkbox and fab-calendar don't.

I'd also very much like to do nav is=glorious-accordian 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 img alt from the
platform.
b



Re: Minimum viable custom elements

2015-01-29 Thread Ryosuke Niwa

 On Jan 29, 2015, at 7:52 AM, Steve Faulkner faulkner.st...@gmail.com wrote:
 On 29 January 2015 at 15:37, Anne van Kesteren ann...@annevk.nl 
 mailto:ann...@annevk.nl 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 Brian Kardell
On Thu, Jan 29, 2015 at 2:43 PM, Bruce Lawson bru...@opera.com 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-19 Thread Anne van Kesteren
On Fri, Jan 16, 2015 at 8:06 PM, Domenic Denicola d...@domenic.me 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 dglaz...@google.com wrote:
 On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa rn...@apple.com wrote:
 
 On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com 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 Steve Faulkner
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 http://www.w3.org/html/wg/drafts/html/master/

On 15 January 2015 at 23:33, Edward O'Connor eocon...@apple.com 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:

 div role=heading aria-level=7Cuora amboinensis, the southeast Asian box
 turtle/div

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

 ted-h7Cuora amboinensis, the southeast Asian box turtle/ted-h7

 This is just as accessible as the div 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:

 h1 is=ted-h7Cuora amboinensis, the southeast Asian box turtle/h1

 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 h1. h1 is at
 least a heading, if not one of the right level. But in such a browser
 the div 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 h1's implicit heading level:

 h1 is=ted-h7 aria-level=7Cuora amboinensis, the southeast Asian box
 turtle/h1

 I guess this is OK, but seeing aria-level=7 on and h1 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-16 Thread Steve Faulkner
On 16 January 2015 at 10:25, Steve Faulkner faulkner.st...@gmail.com
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 http://www.w3.org/html/wg/drafts/html/master/


Re: Minimum viable custom elements

2015-01-16 Thread Anne van Kesteren
On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner
faulkner.st...@gmail.com 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 div abuse to mean button. 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

2015-01-16 Thread Anne van Kesteren
On Thu, Jan 15, 2015 at 8:18 PM, Dimitri Glazkov dglaz...@google.com 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

2015-01-16 Thread Steve Faulkner
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
divs with fancy names.



--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 16 January 2015 at 13:16, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner
 faulkner.st...@gmail.com 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 div abuse to mean button. 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

2015-01-16 Thread Anne van Kesteren
On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa rn...@apple.com 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

2015-01-16 Thread Ryosuke Niwa

 On Jan 16, 2015, at 9:58 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 On Fri, Jan 16, 2015 at 2:29 AM, Ryosuke Niwa rn...@apple.com 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

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 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com 
 mailto:rn...@apple.com 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 Dimitri Glazkov
On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote:
 On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com 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-15 Thread Dimitri Glazkov
No argument that callbacks are also a useful new addition.

:DG


Re: Minimum viable custom elements

2015-01-15 Thread Anne van Kesteren
On Wed, Jan 14, 2015 at 9:25 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 14, 2015, at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
 * Existing lifecycle callbacks plus those agreed (copying, adopting).

 Could you give us pointers for a proposed definition of these two callbacks 
 if there is any?

I added a short description here:

  https://wiki.whatwg.org/wiki/CustomElements#Additional_lifecycle_callbacks

These would basically cover these extension points that the DOM
already offers and that HTML (and perhaps SVG) makes use of:

  https://dom.spec.whatwg.org/#concept-node-adopt-ext
  https://dom.spec.whatwg.org/#concept-node-clone-ext


 It also does not address subclassing normal elements. Again, while
 that seems desirable the current ideas are not attractive long term
 solutions. Punting on it in order to ship a v1 available everywhere
 seems preferable.

 I can't be enthusiastic enough to support this motion since that's more or 
 less what I've been saying for the past six months or so.

I hope that we are iterating to a subset that everyone is happy with.
It would be great to get custom elements in all browsers. As far as I
can tell the main sticking point is still how exactly we map markup to
objects:

  https://wiki.whatwg.org/wiki/CustomElements#Upgrading


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-01-15 Thread Kenneth Rohde Christiansen
Anne, maybe you could write on the wiki what the current Web Components
implementation in Chrome is using. That would make it a bit easier to
follow for people who didn't follow all of the discussion so far.

Kenneth

On Thu Jan 15 2015 at 5:05:35 PM Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com
 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.
 
  And if I walk the tree anyway, what's the point of custom elements in the
  first place? One of the key features (at least, to me) of custom elements
  was being able to harness the HTML Parser to instantiate your object
 tree.
  If that's not going happen consistently, then I am not sure custom
 elements
  are worth the trouble. IOW, if you're walking the tree, just do the work
 of
  callbacks as you encounter dash-separated elements.

 My rationale is this:

 * Unlike you I think lifecycle callbacks are the main selling point of
 a custom element. They give you access to hooks that normal elements
 have but are not otherwise exposed.
 * 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.
 * Upgrading can be added, but moving from Brain transplants to a more
 normal working constructor would be impossible after the fact.

 Now, given the discussion so far, it does seem that synchronous or
 almost-synchronous constructors have a number of hard issues and it's
 not entirely clear to me anymore those are worth pushing over Brain
 transplant or Dummy replacement, using the terminology from:

   https://wiki.whatwg.org/wiki/CustomElements#Upgrading


 --
 https://annevankesteren.nl/




Re: Minimum viable custom elements

2015-01-15 Thread Anne van Kesteren
On Wed, Jan 14, 2015 at 9:52 PM, Dimitri Glazkov dglaz...@google.com 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.

 And if I walk the tree anyway, what's the point of custom elements in the
 first place? One of the key features (at least, to me) of custom elements
 was being able to harness the HTML Parser to instantiate your object tree.
 If that's not going happen consistently, then I am not sure custom elements
 are worth the trouble. IOW, if you're walking the tree, just do the work of
 callbacks as you encounter dash-separated elements.

My rationale is this:

* Unlike you I think lifecycle callbacks are the main selling point of
a custom element. They give you access to hooks that normal elements
have but are not otherwise exposed.
* 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.
* Upgrading can be added, but moving from Brain transplants to a more
normal working constructor would be impossible after the fact.

Now, given the discussion so far, it does seem that synchronous or
almost-synchronous constructors have a number of hard issues and it's
not entirely clear to me anymore those are worth pushing over Brain
transplant or Dummy replacement, using the terminology from:

  https://wiki.whatwg.org/wiki/CustomElements#Upgrading


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-01-15 Thread Anne van Kesteren
On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
 Anne, maybe you could write on the wiki what the current Web Components
 implementation in Chrome is using. That would make it a bit easier to follow
 for people who didn't follow all of the discussion so far.

I updated the page to point this out where it wasn't necessarily
obvious (and ended up adding a row to the table):

  https://wiki.whatwg.org/wiki/CustomElements

(I also gave Brain transplant an alternative name Dmitry as he
made it look rather elegant :-))


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-01-15 Thread Kenneth Rohde Christiansen
Thanks, this is very useful!

On Thu Jan 15 2015 at 5:40:02 PM Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Jan 15, 2015 at 5:12 PM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:
  Anne, maybe you could write on the wiki what the current Web Components
  implementation in Chrome is using. That would make it a bit easier to
 follow
  for people who didn't follow all of the discussion so far.

 I updated the page to point this out where it wasn't necessarily
 obvious (and ended up adding a row to the table):

   https://wiki.whatwg.org/wiki/CustomElements

 (I also gave Brain transplant an alternative name Dmitry as he
 made it look rather elegant :-))


 --
 https://annevankesteren.nl/



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

2015-01-15 Thread Tab Atkins Jr.
On Thu, Jan 15, 2015 at 12:27 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com 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

2015-01-15 Thread Dimitri Glazkov
On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren ann...@annevk.nl 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

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

2015-01-15 Thread Domenic Denicola
Steve's concerns are best illustrated with a more complicated element like 
button. He did a great pull request to the custom elements spec that 
contrasts all the work you have to do with taco-button vs. button 
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 
custom-p as a paragraph, while it will happily do so for p 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:

div role=heading aria-level=7Cuora amboinensis, the southeast Asian box 
turtle/div

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

ted-h7Cuora amboinensis, the southeast Asian box turtle/ted-h7

This is just as accessible as the div 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:

h1 is=ted-h7Cuora amboinensis, the southeast Asian box turtle/h1

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 h1. h1 is at least a 
heading, if not one of the right level. But in such a browser the div 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 h1's implicit heading level:

h1 is=ted-h7 aria-level=7Cuora amboinensis, the southeast Asian box 
turtle/h1

I guess this is OK, but seeing aria-level=7 on and h1 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:

div role=heading aria-level=7Cuora amboinensis, the southeast Asian box 
turtle/div

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

ted-h7Cuora amboinensis, the southeast Asian box turtle/ted-h7

This is just as accessible as the div 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:

h1 is=ted-h7Cuora amboinensis, the southeast Asian box turtle/h1

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 h1. h1 is at
least a heading, if not one of the right level. But in such a browser
the div 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 h1's implicit heading level:

h1 is=ted-h7 aria-level=7Cuora amboinensis, the southeast Asian box 
turtle/h1

I guess this is OK, but seeing aria-level=7 on and h1 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 Ryosuke Niwa

 On Jan 15, 2015, at 11:28 AM, Domenic Denicola d...@domenic.me 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 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 Brian Kardell
On Thu, Jan 15, 2015 at 6:43 PM, Domenic Denicola d...@domenic.me wrote:

 Steve's concerns are best illustrated with a more complicated element like
 button. He did a great pull request to the custom elements spec that
 contrasts all the work you have to do with taco-button vs. button
 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
 custom-p as a paragraph, while it will happily do so for p
 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:

 div role=heading aria-level=7Cuora amboinensis, the southeast Asian box
 turtle/div

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

 ted-h7Cuora amboinensis, the southeast Asian box turtle/ted-h7

 This is just as accessible as the div 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:

 h1 is=ted-h7Cuora amboinensis, the southeast Asian box turtle/h1

 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 h1. h1 is at
 least a heading, if not one of the right level. But in such a browser the
 div 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 h1's implicit heading level:

 h1 is=ted-h7 aria-level=7Cuora amboinensis, the southeast Asian box
 turtle/h1

 I guess this is OK, but seeing aria-level=7 on and h1 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 Ryosuke Niwa

 On Jan 15, 2015, at 3:17 PM, Domenic Denicola d...@domenic.me 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 Ryosuke Niwa

 On Jan 14, 2015, at 12:52 PM, Dimitri Glazkov dglaz...@google.com 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

2015-01-15 Thread Ryosuke Niwa

 On Jan 15, 2015, at 11:47 AM, Brian Kardell bkard...@gmail.com 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-14 Thread Dimitri Glazkov
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.

And if I walk the tree anyway, what's the point of custom elements in the
first place? One of the key features (at least, to me) of custom elements
was being able to harness the HTML Parser to instantiate your object tree.
If that's not going happen consistently, then I am not sure custom elements
are worth the trouble. IOW, if you're walking the tree, just do the work of
callbacks as you encounter dash-separated elements.

:DG


Re: Minimum viable custom elements

2015-01-14 Thread Dimitri Glazkov
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579

On Wed, Jan 14, 2015 at 11:11 AM, Domenic Denicola d...@domenic.me wrote:

 From: Erik Arvidsson [mailto:a...@google.com]

  I'm not sure how that is speced but in Blink we have an extended IDL
 attribute called CustomElementCallbacks which means that we are going to
 call the pending callbacks after the method/setter.

 If I recall this is how Anne and others were saying that it *should* be
 specced, but the spec itself is a bit more vague, leaving it as

  When transitioning back from the user agent code to script, pop the
 element queue from the processing stack and invoke callbacks in that queue.



Re: Minimum viable custom elements

2015-01-14 Thread Ryosuke Niwa

 On Jan 14, 2015, at 12:25 PM, Domenic Denicola d...@domenic.me wrote:
 
 From: Ryosuke Niwa [mailto:rn...@apple.com] 
 
 Let me restate the problem using an example.  Suppose we're parsing 
 my-element/my-elementmy-other-element/my-other-element.
 
 Once the HTML is parsed, the DOM tree is constructed with two DOM elements.  
 Now we call the constructors on those elements.  Without loss of generality, 
 let's assume we're doing this in the tree order.
 
 We call the constructor of my-element first. However, inside this 
 constructor, you can access this.nextSibling after calling super().  What's 
 nextSibling in this case? An uninitialized my-other-element.
 
 Thanks, that is very helpful. And I'd guess that with the current spec, it's 
 an uninitialized my-other-element in the sense that its createdCallback has 
 not been called, even though its constructor (which does nothing beside the 
 normal HTMLElement/HTMLUnknownElement stuff) has indeed been called.

Precisely.

- R. Niwa


RE: Minimum viable custom elements

2015-01-14 Thread Domenic Denicola
From: Erik Arvidsson [mailto:a...@google.com] 

 I'm not sure how that is speced but in Blink we have an extended IDL 
 attribute called CustomElementCallbacks which means that we are going to call 
 the pending callbacks after the method/setter.

If I recall this is how Anne and others were saying that it *should* be 
specced, but the spec itself is a bit more vague, leaving it as

 When transitioning back from the user agent code to script, pop the element 
 queue from the processing stack and invoke callbacks in that queue.


Re: Minimum viable custom elements

2015-01-14 Thread Ryosuke Niwa

 On Jan 14, 2015, at 10:41 AM, Domenic Denicola d...@domenic.me wrote:
 
 From: Ryosuke Niwa [mailto:rn...@apple.com] 
 
 See Boris' responses in another thread [1] and [2].  Jonas outlined how this 
 could work in the same thread [3]
 
 Thanks for the references. But avoiding this problem is exactly what Arv and 
 I were talking about.
 
 The mechanism that createdCallback (and all other custom element callbacks) 
 operate via is to batch up all user code after the parser, but before 
 returning control to script. So in the example of setting innerHTML then 
 reading it on the next line, you let the parser run, *then* run the 
 constructors, then run the next line.
 
 Again, I might be missing something, but if you just do 
 s/createdCallback/constructor in the existing spec, I think you get what 
 we're describing.

Let me restate the problem using an example.  Suppose we're parsing 
my-element/my-elementmy-other-element/my-other-element.

Once the HTML is parsed, the DOM tree is constructed with two DOM elements.  
Now we call the constructors on those elements.  Without loss of generality, 
let's assume we're doing this in the tree order.

We call the constructor of my-element first. However, inside this constructor, 
you can access this.nextSibling after calling super().  What's nextSibling in 
this case? An uninitialized my-other-element.

The only way around this would be constructing the tree (or connecting 
elements) only after constructors are called.  This is not how createdCallbacks 
are called.

- R. Niwa




RE: Minimum viable custom elements

2015-01-14 Thread Domenic Denicola
From: Ryosuke Niwa [mailto:rn...@apple.com] 

 Let me restate the problem using an example.  Suppose we're parsing 
 my-element/my-elementmy-other-element/my-other-element.

 Once the HTML is parsed, the DOM tree is constructed with two DOM elements.  
 Now we call the constructors on those elements.  Without loss of generality, 
 let's assume we're doing this in the tree order.

 We call the constructor of my-element first. However, inside this 
 constructor, you can access this.nextSibling after calling super().  What's 
 nextSibling in this case? An uninitialized my-other-element.

Thanks, that is very helpful. And I'd guess that with the current spec, it's an 
uninitialized my-other-element in the sense that its createdCallback has not 
been called, even though its constructor (which does nothing beside the normal 
HTMLElement/HTMLUnknownElement stuff) has indeed been called.



Re: Minimum viable custom elements

2015-01-14 Thread Ryosuke Niwa

 On Jan 14, 2015, at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 I've been trying to think of the smallest setup that adds value, can
 get broad agreement, and is therefore hopefully interoperable fast.
 
 * ES6-style class syntax to declare the imperative constructor.
 * No subclassing of normal elements for now.
 * registerElement() to enable declarative syntax and createElement().
 * Parsing of declarative syntax invokes the registered constructor
 synchronously.

We support the proposals above.

 * Existing lifecycle callbacks plus those agreed (copying, adopting).

Could you give us pointers for a proposed definition of these two callbacks if 
there is any?

 Notably this does not address upgrading. I think we can defer
 upgrading as it can be implemented in script fairly easily. You await
 for the imperative constructors to load and DOMContentLoaded at which
 point you traverse the tree and invoke replace() on those elements you
 want to upgrade.

Of course, this doesn't quite work for custom elements used in shadow DOM if we 
assume shadow DOMs share the custom element registry with its document but this 
isn't a terribly interesting point in the world where neither feature is 
implemented across browsers because we can't agree on anything.

 It also does not address subclassing normal elements. Again, while
 that seems desirable the current ideas are not attractive long term
 solutions. Punting on it in order to ship a v1 available everywhere
 seems preferable.

I can't be enthusiastic enough to support this motion since that's more or less 
what I've been saying for the past six months or so.

- R. Niwa



Re: Minimum viable custom elements

2015-01-14 Thread Boris Zbarsky

On 1/14/15 9:45 AM, Anne van Kesteren wrote:

* No subclassing of normal elements for now.


You mean subclassing anything more specific than HTMLElement/SVGElement, 
yes?  Presumably we still want subclassing of HTMLElement and maybe 
SVGElement?



* Parsing of declarative syntax invokes the registered constructor
synchronously.


I would like to understand what this means, exactly.  For example, what 
is the proposed behavior of document.write() in the declarative constructor?


This part of the proposal really worries me in terms of implementation 
complexity, for what it's worth.


-Boris



RE: Minimum viable custom elements

2015-01-14 Thread Domenic Denicola
From: Anne van Kesteren [mailto:ann...@annevk.nl] 

 Could you explain how this works in more detail?

I haven't checked, but my impression was we could just use the same processing 
model the current spec uses for createdCallback, and use the constructor 
instead.



Re: Minimum viable custom elements

2015-01-14 Thread Steve Faulkner
On 14 January 2015 at 14:45, Anne van Kesteren ann...@annevk.nl wrote:

 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.

[1] http://w3c.github.io/webcomponents/spec/custom/#semantics

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/


Re: Minimum viable custom elements

2015-01-14 Thread Anne van Kesteren
On Wed, Jan 14, 2015 at 4:28 PM, Erik Arvidsson a...@google.com wrote:
 I don't see why it has to be done synchronously? We can do what we do
 it today and do it synchronously-ish, that is before any user script
 (script element) is executed. That way the parser does not have to be
 stalled by user script until user script would run anyway.

Could you explain how this works in more detail? E.g. what would the
processing model be for something like this (assuming a registry
entry):

  script
   document.write(my-div)
   alert(document.querySelector(my-div))
  /script


-- 
https://annevankesteren.nl/



Re: Minimum viable custom elements

2015-01-14 Thread Ryosuke Niwa

On Jan 14, 2015, at 9:50 AM, Domenic Denicola d...@domenic.me wrote:

 From: Anne van Kesteren [mailto:ann...@annevk.nl] 
 
 Could you explain how this works in more detail?
 
 I haven't checked, but my impression was we could just use the same 
 processing model the current spec uses for createdCallback, and use the 
 constructor instead.

See Boris' responses in another thread [1] and [2].  Jonas outlined how this 
could work in the same thread [3]

The basic problem is that the DOM tree had already been constructed at that 
point, and you'll be able to access other uninitialized nodes via DOM APIs such 
as firstChild inside a custom element's constructor.

Now, ES classes have evolved quite a bit since the last we discussed this.  
It's possible letting scripts access uninitialized objects is okay; we'll 
simply throw ReferenceError as it would be done when this is accessed before 
the root base class' constructor is called inside a subclass' constructor [4].

[1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0816.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0818.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0098.html
[4] 
https://github.com/tc39/ecma262/blob/master/workingdocs/ES6-super-construct%3Dproposal.md

- R. Niwa




RE: Minimum viable custom elements

2015-01-14 Thread Domenic Denicola
From: Ryosuke Niwa [mailto:rn...@apple.com] 

 See Boris' responses in another thread [1] and [2].  Jonas outlined how this 
 could work in the same thread [3]

Thanks for the references. But avoiding this problem is exactly what Arv and I 
were talking about.

The mechanism that createdCallback (and all other custom element callbacks) 
operate via is to batch up all user code after the parser, but before returning 
control to script. So in the example of setting innerHTML then reading it on 
the next line, you let the parser run, *then* run the constructors, then run 
the next line.

Again, I might be missing something, but if you just do 
s/createdCallback/constructor in the existing spec, I think you get what we're 
describing.