This advice is script centric, needs to consider custom elements' role

[prushforth]

I think this finding needs to consider the means to standardize new elements in HTML, especially that of Customized built-in elements as 'speculative polyfills'.

For example, the Maps for HTML Community Group has built a speculative polyfill of new functionality for the <map> element, which appears to follow the advice of this finding, because it uses 'namespaces', and doesn't squat on the

Being a customised built-in element makes it a speculative polyfill. This (role) isn't acknowledged by the finding. Autonomous custom elements might or might not be speculative polyfills. It would be up to the elements' authors to declare them as such.

Which brings up another point: why, given the almost self-declaring nature as 'speculative polyfills' of elements bearing the "is" attribute, why would it not be a good idea to allow autonomous custom elements to use "is", as an alternative syntax to hyphenated element names? That is, why could previously unknown element not extend HTMLElement, if it carries the "is" attribute to distinguish it?

In that way, for example, the <picture is="picture-fill"> element speculative polyfill could have been implemented as a (previously unknown) autonomous custom element and in consequence would not present a risk to the eventual standard. In fact, popularity of which speculative polyfill for a given syntax could influence what gets standardized.

As browser makers in some cases seem to be backing away from customized built-in elements, I think the architectural role of custom elements in general needs to be considered (by the TAG), especially since we need a standard way to create speculative polyfills, to help the standards process, as acknowledged by this finding!

That's my beef, thanks for listening. Thanks to Brian Kardell also for patiently debating with me until I was able to clearly understand and articulate (perhaps not clearly enough, please let me know) what I've mentioned here.

[prushforth]

I've updated/merged this issue to fix typos made on my phone and fix the formatting. Thanks for your consideration. /cc @bkardell

[prushforth]

unclosing. I'll let you guys / ladies do that when you see fit.

[bkardell]

This was discussed briefly as part of a breakout on the polyfills finding at TPAC 2017. Relevant minutes at https://pad.w3ctag.org/p/2017-tpac-polyfills.md

I believe there was some consensus to improve the guidance in this area a little bit and also to have WICG incorporate this into general guidance for polyfill development there (cc @yoavweiss).

I believe that what I heard remained consistent with my understanding that if you are talking about proposing a new built-in, that is a speculative polyfill and existing Custom Elements patterns already take this into account and are what you should do (example <x-thingr>). If it should turn out that thingr gets uptake and passes the 'tipping point' then you could maybe turn that into what we'd traditionally call simply "a polyfill". How to accomplish this could probably use an example or some advice since there isn't a built in, self-evident thing that enforces some bit of that like there is with customElements.

The other thing to discuss some more is, ..I guess?... the topic of this bug itself which has to do with how to propose additional features to an existing built-in and if/how this is different. I suppose it would be helpful to imagine that we had this advice when additional HTML input types included in 'HTML 5' were proposed, how would we have liked that to have been handled at both stages (speculatively, and past the tipping point)? I think that this is a red herring for a number of reasons, but I believe that is basically the ask and it's not an uncommon question from developers.

[triblondon]

What Brian said.

But also... I think it's reasonable for us to add a point to our design principles to advise about when it's appropriate to create a polyfill as part of spec development and what considerations should go into that, linking to the polyfill finding. I'll raise an issue for that, and I'd welcome a specific suggestion (PR?) for how we could modify the polyfill finding to better address polyfilling elements.

[prushforth]

@bkardell and @triblondon

I believe that what I heard remained consistent with my understanding that if you are talking about proposing a new built-in, that is a speculative polyfill and existing Custom Elements patterns already take this into account and are what you should do (example <x-thingr>).

I get that this matches effectively the existing advice for speculative polyfills, but I guess what I'm asking is "is this the right answer for the Web standards process?". I also guess that part of how to answer that is to ask "What if everyone did this?", but possibly refined for the Web to "What if Google or Apple did this?". In that light, the answer is already before us: AMP, and IMHO AMP amounts to a fork of HTML, so I've got to ask you, the TAG, if you think that is good for the Web standards process or more generally, the Web?

If you think it is, maybe you could put that in the finding too. I personally would like to see a standard crafted for custom elements that is designed to help re-direct (at least some of the ) energy expended on forking HTML into providing useful feedback into the standards process. I could see a speculative polyfill of a <thingr is="x-thingr"> helping: it could encourage building of web platform tests for example, which I believe is one of the main reasons for building speculative polyfills in the first place.

But all the aforementioned is sort of "what if", because the above discussion about non-existent elements doesn't reflect the standard as it is written today except to say that <x-thingr> is about the best we can do at present.

Given that the standard, with 3 out of 4 browser vendors agreeing to the spec (isn't that a tipping point?), describes customized built-in elements as being essentially better than autonomous custom elements for reasons, isn't it kind of a TAG level thing to either help get that fourth vendor on board or say why the fourth browser is actually correct and what can be done about it? That said, I think a PR on my part is premature, because it appears from discussions, or lack thereof, that the customized built-in elements are the elephant in the room. I will submit a PR if you think it has a chance of being accepted.

I was hoping that the TAG face to face might have been an opportunity for you to address the elephant (customized built-ins), but it appears to not have been the case. I was re-reading some vintage Alex Russell over lunch and I'll close with a couple of quotes from him:

The network is our bottleneck and markup is our lingua-franca. To deny these facts is to design for failure.

Any place where you cannot draw a line from browser-provided behavior from a tag to the JS API which describes it is magical. The job of Web API designers is first to introduce new power through markup and second to banish magic, replacing it with understanding.

Since HTML, DOM, and CSS aren’t Turing-complete, they naturally belong at a “higher level” in the web platform stack.

This point has not been made enough or loudly enough, and this finding is an example of that. The end game of JavaScript APIs isn't to make more APIs, its to standardize more HTML, DOM and CSS and get rid of the magic.

Whenever we add something to HTML, CSS, etc., it always comes with some sort of API. Now, that could be a good API, or it could be an obtuse turn around the parser after some terrible string concatenation.

I’m claiming that you get better APIs when you design your imperative explanation of the declarative stuff — which you MUST do for specs to be sane — in JS.

I would use Alex's arguments to make the case that Web Components should be the vehicle to get us from the JavaScript into the HTML, CSS and DOM that we need, and they should be designed to tilt the field towards standards, not to forking the Web. I was under the impression that they were going in that direction, but that vision is fading for me at least.

That is all. Thanks for listening.

[prushforth]

I am closing this, as I believe @kenchris did more or less what I was asking for. Thank you!

https://www.w3.org/2001/tag/doc/webcomponents-design-guidelines/