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