This was previously discussed at length in the other bug tracker, and it's explained in the spec in the sentence above that:

Customized built-in elements require a distinct syntax from autonomous custom elements because user agents and other software key off an element's local name in order to identify the element's semantics and behaviour. That is, the concept of customized built-in elements building on top of existing behaviour depends crucially on the extended elements retaining their original local name.

@domenic That quote that you referred to makes me think exactly the same thing as I just wrote:

The necessary info for the HTML engine to upgrade that element properly is right there, in { extends: "button" }. I do believe there's some way to make this work (as there always is with software, because we make it, it is ours, we make software do what we want, and this is absolutely true without me having to read a single line of browser source code to know it), and that is="" is not required and can be completely removed from the spec because it seems like a hack to some limitation that can be solved somehow else (I don't know what that "somehow" is specifically, but I do know that the "somehow" exists because there's always some way to modify software to make it behave how we want within the limitations of current hardware where current hardware is not imposing any limitation on this feature).

You're pointing to something that exists in a spec, but I'm saying it doesn't have to be that way, specs can be modified. There is a solution (I don't know what that solution is specifically yet, but I know that the hardware on any computer that runs a browser nowadays isn't a limitation, and the only limitation is in the software we write, which can be modified). I simply can't understand why an HTML engine must need <button is="super-button"> (besides the fact that current algorithms require that) when clearly there's a JavaScript way to make the HTML engine understand that <super-button> means the same as <button is="super-button"> due to the fact we're defining that in the call to customElement.define.

I wish I had the time and resources to read the Chromium source in order to point to an actual solution (someone else can write the spec, as I'm not even good at reading those), but in the meantime, I'm 100% sure a backwards-compatible programmatic solution exists.

Yes, everything is Turing machines and everything can be implemented. However, there are real-world constraints---both in implementation complexity and in ecosystem impact---that make it not desirable.

Some things are complex to implement, but this particular change doesn't seem to be. :]

Would you mind kindly pointing to the complexity and impact that make it non-desirable?

Is it because if the element isn't registered (i.e. with JS turned off) that the browser won't know to at least render a fallback <button>? I think that's perfectly fine, because without JS the app probably won't work anyways, and I'm willing to bet that most people who will write JavaScript-based Custom Elements won't care if the app doesn't work with JS turned off. The Nike website doesn't work with JS turned off, and they care. Most people won't care. Developers who do care can just as easily use <noscript> and place a <button> in there, which makes much more semantic sense anyway.

What other reason might there be?

When someone who comes from React tries to learn Custom Elements for the first time (which is more likely to happen than someone learning Custom Elements first due to the mere fact that specs are hard to read compared to things like React docs, unfortunately, because specs are meant for implementers, and the actual usage docs if any are sometimes limited or hard to find), they'll face these weird things like the redundant is="" form of extension and globally-registered custom elements that are not registered on a per-component basis.

This is what classes are for, and in the case of the HTML engine where multiple types of elements may share the same interface (which is probably a partial cause to any current problems) the third argument to customElements.define is there to clarify things. The is="" attribute is simply redundant and out of place from an outter API perspective (which may matter more than whatever extra implementation complexity there may be) because we already specify the extension in the define() call.

I'd take this further and propose that every single built in element should have a single unique associated class, and therefore ES2015 class extension would be the only required form of extension definition.

Just in case, let me point out we must currently specify an extension three whole times. For example, to extend a button:

class MyButton extends HTMLButtonElement {} // 1
customElements.define('my-button', MyButton, { extends: 'button' }) // 2

<button is="my-button"></button> <!-- 3 -->

That's three times we've needed to specify that we're extending something, just to extend one thing. Doesn't this strike you as a bad idea from an end-user perspective?

It should ideally just be this, assuming that there is a one-to-one relationship between built-in elements and JS classes:

class MyButton extends HTMLButtonElement {} // 1
customElements.define('my-button', MyButton)

<my-button></my-button>

I get what you're saying about complexities and real-world world constraints, but I think "breaking the web" might actually fix the web in the long run. There can be an API cleansing, and websites may have to specify that the new breaking-API is to be used by supplying an HTTP header. Previous behavior can be supported for a matter of years and finally dropped, the new API becoming default at that time. Sites that don't update within a matter of years probably aren't cared for anyways.

I'm just arguing for a better web overall, and breaking changes are sometimes necessary. It seems I may be arguing for this forever though. Unless I am an employee at a browser vendor, I'm not sure my end-user viewpoints matter much. The least I can do is share them.

The problem here is that UA internally checks local name e.g. element.localName == aTag to do various things, and all of that code needs to be updated to account for the fact there could be an intense of HTMLAnchorElement whose local name is not a.

Now I'm going to re-iterate that Apple objects to extending subclasses of HTMLElement using is= as currently spec'ed for various reasons we've stated in the past and this feature won't be supported in WebKit.

The problem here is that UA internally checks local name e.g. element.localName == aTag to do various things, and all of that code needs to be updated to account for the fact there could be an intense of HTMLAnchorElement whose local name is not a.

I think that relying on element tag names might be a bad idea, especially if we give users ability to scope elements on a per-shadow-root basis (now that's a good idea!). If we can allow end users of a custom element to assign any name they wish to that custom element used within the user's component (within the user's component's inner shadow tree), then we can avoid the global mess that window.customElements will be when an app gets large and when people widely adopt Web Components (wide adoption is one of the goals here).

In React (by contrast) the creator of a component never decides what the name of that component will be in the end user's inner tree. The end user has full control over the name of an imported component thanks to ES6 Modules. We can encourage a similar concept by introducing a per-shadow-root custom element registration feature.

If we can map names to classes without collision and without two names assigned to the same class (i.e. without elements like <q> and <blockquote> sharing the same class), then we should be able to use instanceof instead of checking tag names, and element inheritance can be based solely on ES6 class extension, as it should be (rather than having the extra is="" feature). The change that would be needed here would be to ensure that the native elements map to separate leaf classes so it's possible to tell a <q> element apart from a <blockquote> element with instanceof and therefore encouraging that sort of checking over tag names.

This API is still v0 in practice, so I think there's room for modification even if v1 is on the verge of coming out.

Apple objects to extending subclasses of HTMLElement using is=

I think Webkit not implementing is="" may be a great thing.

If we continue with globally registered elements, it will be inevitable that some two components in an app will have a name collision, and that the developer of that app will attempt to fix the problem by modifying the source of one custom element (possibly requiring forking of an NPM module, pushing to a new git repo, publishing a new module, etc, time consuming things) just to change the name of that element; it'd be a pain and can introduce unexpected errors if parts of the modified code are relying on the old tag names.

TLDR, if we put more care into the JavaScript aspects of an element (f.e. choosing which class represents an element, which is already happening in v1) then we'll have a more solid Web Component design, and we can drop is="". It will also require fixing things like the <q>/<blockquote> problem.

@domenic Can you describe the "ecosystem impact" that you might know of?

I am referring to the various tools which key on local name, including JavaScript frameworks, HTML preprocessors and postprocessors, HTML conformance checkers, and so on.

I think I know what you mean. For example, search engines read the tag names from the markup in order to detect what type of content and how to render it in the search results. This point may be moot because today it completely possible to use a root <app> component with a closed shadow root. In this case a search engine might only ever see

<html>
    <head>
        <title>foo</title>
    </head>
    <body>
        <app></app>
    </body>
</html>

That's functionally equivalent to an app with no shadow roots and made entirely of randomly named elements:

<html>
    <head>
        <title>foo</title>
    </head>
    <body>
        <asf>
            <oiur>
                ...
            </oiur>
            <urvcc>
                ...
            </urvcc>
        </asf>
    </body>
</html>

Based on that, I don't think it's necessary to keep element names.

I imagine a couple remedies:

1. Allowing both forms and let users decide which to use: <button is="awesome-button"> or <awesome-button> and let users decide which to use as they so wish.
2. Allowing overriding of native elements (which pairs well with the idea of per-shadow-root element registrations as in "hey, let me define what a <p> element is within my component that has no paragraphs."). Then <button> could behave like <awesome-button>, and search engines or other tools would be able to receive the same semantic meaning. This idea only works if the elements are in Light DOM.

Remedy 1 is what we have consensus on.

I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later.

It’s important to note that a lot of elements are implemented partially (or completely) with CSS. So, in order to support this and allow user agents to continue to implement elements like they do today, a new CSS pseudo-class would be needed: :subtypeof(button)

a new CSS pseudo-class would be needed: :subtypeof(button)

Not really. The point of the is= approach is that since you have a button, that already matches CSS selectors for button. If you want to match a specific subtype you can do button[is=broken-button] …

@chaals right. You would need the pseudo-class if using a custom element that extends a native button could be done like <awesome-button> instead of <button is="awesome-button">.

Also, like @trusktr said, if this and whatwg/html#896 become a thing, I think it’ll be possible to remove altogether the extends property from the options argument. We would then write customElements.define("awesome-button", class extends HTMLButtonElement{}, {}), which I really like.

Offering this as an alternative to the current way of defining extending native elements — allowing user agent developers and authors to choose which they want to use — is the best solution in my opinion. As @trusktr said, “I think ‘breaking the web’ might actually fix the web in the long run”.

(@Zambonifofex it's generally not clear to me what you mean when you say "this", which makes it hard to engage)

As @trusktr said, “I think ‘breaking the web’ might actually fix the web in the long run”.

I've tried breaking the Web, at the turn of the century when it was smaller, to do something that would have been really useful. It failed. For pretty much the reasons given by people who say "you can't break the web".

Although user agent developers are less reluctant to break things than they were a decade ago, they're still very reluctant, and I believe with very good reason.

I think a strategy reliant on breaking the Web to fix it is generally a non-starter, even if the alternatives are far more painful.

For what it's worth, I agree with @rniwa's characterisation - we have an agreement that we won't write is= out right now, but I don't see a strong consensus behind it. (Although as an individual I'm one of those who think it's pretty much indispensable to making this stuff work).

@chaals

(@Zambonifofex it's generally not clear to me what you mean when you say "this", which makes it hard to engage)

When I say “this” I mean “this issue”; the suggestion made by @trusktr in the first comment of this thread.

But, honestly, — not that I’d be able to know, as I’ve never touched any browser’s code — I think that this would be a much easier change to make for user agent developers than you guys are making it out to be.

I mean, sure, it could be slightly annoying to go and change all of the checks for the tag name to something else, but would it be actually hard?

The is="" API can be confusing. For example (in current v0 API):

<my-el></my-el>

class MyEl extends HTMLElement { /*... */ }
MyEl.extends = 'div'
document.registerElement('my-el', MyEl)

// ...

document.querySelector('my-el') instanceof MyEl // true or false?

That API does not reflect the current custom elements API.

We should make the result of instanceof be obvious. I think this could be better in v1 (without is="" and without options.extends):

<my-el></my-el>

class MyEl extends HTMLDivElement { /*... */ }
customElements.define('my-el', MyEl)

// ...

document.querySelector('my-el') instanceof MyEl // true!

I forgot this line too, in the previous comment:

document.querySelector('my-el') instanceof HTMLDivElement // also true!

(@domenic I'm still using v0 in Chrome)

@rniwa

there could be an intense of HTMLAnchorElement whose local name is not a.

I think you meant "instance" instead of "intense"? This seems to be the reason why is="" exists, making it possible to create new elements that extend from elements that inherit from the same class, but that possibly have new behavior added to them in their definitions along with differing nodeNames. This is also the reason for the {extends: "element-name"} (I am calling it options.extends), which effectively accomplishes the same thing. I feel like this may be an anti-pattern considering that we now have ES6 classes for describing extension.

I am against both of those methods of defining extension, as I believe encouraging ES6 Classes as the the tool for defining extension will reduce room for confusion.

Perhaps existing native elements should be re-worked so that any differences they have should rather be described (explained) by using class extension, and not using those other two methods (is="" and options.extends). An example of native elements that are defined with the same interface/class but with different nodeNames are q and blockquote which share the HTMLQuoteElement interface. We should attempt to describe the difference (if any) between these elements with class extension rather than is="" combined with options.extends. If there is no difference except for nodeName, then if they are both instanceof the same class that is fine too as long as the behavior for both elements is entirely defined in the shared class, and not by other means.

FWIW, we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.

@rniwa if you could enumerate a couple of these “various reasons” or link to some previous discussion on this subject that lead to this conclusion, it’d be appreciated.

@rniwa I second @Zambonifofex, would love to know the rational behind this. In the case of needing features exclusive to native elements, how would someone use these features on a custom element without extending it?

An example my company is dealing with is replicating the sizing of a native img element, so far we haven't found any cross browser way to replicate the way it sizes, therefore having an element extension, so right now using is, is the only way to achieve this.

@bedeoverend I don’t think they are against extending native elements, they are simply against classes extending subclasses of HTMLElement. So you would still be able to extend native elements using the extends property of the customElements.define method. What would be illegal is the class passed to the method to extend a subclass of HTMLElement.

We won't be supporting extends either.

One fundamental problem is that subclassing a subclass of HTMLInputElement or HTMLImageElement often leads to a violation of the Liskov substitution principle over time. Because they're builtin elements, they're very likely to be extended in the future. Imagine that we had this feature supported before type=date was added. Then your subclass of HTMLInputElement must also support type=date in order to satisfy the substitution principle. Similarly, imagine we had added this feature before srcset was added to HTMLImageElement and you wrote a subclass of HTMLImageElement. Then not supporting srcset results in the violation of the principle again.

In addition, none of the builtin elements are designed to be subclassed, and in fact, we don't have builtin subclasses of HTMLElement that are also builtins. This limits the usefulness of any sort of subclassing. Furthermore, we don't have any hooks for the processing models and internal states of builtin elements such as the dirtiness of HTMLImageElement's value and when and how HTMLInputElement picks the appropriate image.

Finally, the whole design of is= is a hack, and it would harm the long term health of the Web platform.

FWIW, we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.

One fundamental problem is that subclassing a subclass of HTMLInputElement or HTMLImageElement often leads to a violation of the Liskov substitution principle over time.

@rniwa True, which is why we should avoid subclassing when we can, but I think it's needed in order to fix the mistake that was made with q and blockquote. Otherwise, how does the web manifesto explain the difference between <q> and <blockquote>? I.e. How would the customElements.define() calls for q and blockquote differ in order to theoretically satisfy the web manifesto?

Maybe we would need to reserve HTMLQuoteElement for the q tag, and make a new HTMLBlockQuoteElement for the blockquote element, both of which extend from HTMLElement. I can see how that would be one way to satisfy the web manifesto and remain closer to Liskov's substitution principle.

Yeah, there has been a discussion about that for q and blockquote. A more likely consensus is to introduce two subclasses of HTMLQuoteElement, e.g. HTMLInlineQuoteElement and HTMLBlockQuoteElement and have q and blockquote each use it. It's a bit more hairly story for h1 through h6, which seems to require an introduction of six subclasses of HTMLHeadingElement from HTMLH1Element through HTMLH6Element.

I believe that would be totally fine along with agreement that subclassing in general is better avoided when possible. Nothing's perfect, but having those new subclasses for end-webdevs to extend from is already better than is=""+options.extends.

having those new subclasses for end-webdevs to extend from is already better than is=""+options.extends.

While I can agree is="" is not perfect---perhaps even "a hack", although IMO a pretty reasonable one---I think this opinion is just wrong. Web devs and users both benefit greatly from the ability to extend built-in elements, and is="" is the most practical solution so far. That is why the consensus was to keep is="" in the spec and let implementations decide its fate: because it allows developers to write less code and get more correct behavior, and because it helps users---especially disabled users---interact with web pages in a more predictable and easy manner.

You can talk about how you dislike the technical aspects of is="" as a solution, but I think it's very unfair to say that omitting is="" is better for webdevs (or even "end-webdevs", although I'm not sure what those are).

I've built web components for many years and talk with a lot of web developers regularly about them. I'd like to look at this question from their perspective. Devs don't care about implementation challenges or diving into the weeds.

We need to keep customized built-in elements. CE v1 is not a spec without a way to extend existing HTML elements. My talk at the Progressive Web App Summit highlights some of the reasons why it's important to keep:

• is="" is 100% progressive enhancement!
• Utilize built-in a11y features of the element. This is one of the primary reasons to keep it. I've seen far too many devs build custom elements that miss out on basic a11y...forget it altogether 👎.
• More DRY. One gains native features for free (keyboard behavior, imperative API, and styling). Even recreating all the benefits of <button> requires way too much code.
• Autonomous elements don't have the black magic that native elements have (e.g. creating an element that participates in <form> is painful). Same with extending other types of children.
• Existing tools understand built-in elements
• Existing CSS theming libraries work better with it
• In Polymer, folks really love the extended helpers (<template is="dom-repeat">, <template is="dom-if">,`. They're easy to reason about, declarative, and simple to use. You know exactly what you're getting.
• I talk to a lot of web developers. They don't mind is="".
• No other component library gives you all ^ for free.

Whether is="" is the way to extend elements or not doesn't matter to much. But we definitely need a solution rather than no solution and currently, that's is="". Personally, I see nothing wrong with is="". It's worked great for the last couple of years in Chrome's v0 implementation. It's been implemented in a browser and proven. There may be edge cases with subclassing certain elements, but TBH, I haven't seen many (any?) developers run into them.

Ultimately, developers have to write less code with is="". That's huge. Extensions bring more reuse and keep best practices to our platform. Not less. Let's not remove such a useful feature.

@domenic

Web devs and users both benefit greatly from the ability to extend built-in elements, and is="" is the most practical solution so far. That is why the consensus was to keep is="" in the spec and let implementations decide its fate: because it allows developers to write less code and get more correct behavior, and because it helps users---especially disabled users---interact with web pages in a more predictable and easy manner.

That’d hopefully still be the case if is="custom-button" gets removed in favor of <custom-button>.

I don't get why people keep making claims that is= improves accessibility. It simply doesn't except the very simple scenario in which the entire UI of the builtin form control is preserved (e.g. just adding JS methods).

In reality, a lot of custom form controls exist on the web for the sole purpose of customizing appearances against their builtin counterparts. Unfortunately, as soon as you've attached shadow root on a builtin element which is not even supported in shadow DOM v1, there is no accessibility benefit from using is= because UA can't determine how elements in a shadow tree corresponds to what UI actions without explicit annotations by the author.

is@ is critical for supporting reasonable AX for links. We tried to replicate the subtle focus and keyboard behavior of <a> with a custom element for quite a while before giving up and doing <a is="...">. Nesting a link inside an element breaks styling since my-link:visited etc. stop working.

I could be convinced that we don't need to allow subclassing input, but I think links are super important. Note also that developers have been using template with is@ very successfully over the past 3 years.

Fwiw we also hope to introduce a unique class per tagName, so we would add all six classes for headers etc. It makes the platform make much more sense. :)

My 2 cents, FWIW, <a is=""></a> or <img is=""> confuses nobody about the intent, <shena-nigans></shena-nigans> is a complete wonder of what the heck is that tag about.

Crawlers, old and new users, browsers themselves before they load non blocking async info about the custom elements, just to name few that benefits from is

It also shipped 3 years ago and it worked de-facto pretty well on real-world production sites.

I'm not sure why this bug is still opened or still considered as something to be changed.
AFAIK not a single developer I've talked to said it was confusing (I also gave a talk about this)

Whatever happens here, platform consistency should be considered highly important. If all browsers but WebKit support is, anyone with a valid use-case for using it will have to not use it, or remove Safari from their browser support matrix. There are good reasons for both sides of the argument, but I think there should be some compromise.

WebKit works well through this polyfill of v0 that will eventually be upgraded to support v1 as soon as it's stable (I don't want to repeat the effort for something not final yet)

Best of all, you can IE8 or even IE5 this page and always see where's your business.
That's just a tiny demo of how powerful is the is attribute.

http://webreflection.github.io/document-register-element/test/examples/x-map.html

You can disable everything you want, you gonna see what the map is supposed to show anyway
( ok, not if you're using a text only browser ¯_(ツ)_/¯ )

@rniwa if it's been proved it works and scale well, I am not sure why WebKit would avoid it at all costs.

The result might be some nasty user-land overwrite/interception in order to make it work in there too (like a polyfill would do).

Moreover, the argument about violating the Liskov substitution principle doesn't feel appropriate for the Web environment. The entire global scope/context can be polluted (and it is) dozens of times by all libraries out there, with or without a namespace.

That doesn't prevent standard bodies to implement MyLibrary or fetch if that's an appropriate name for a new feature, isn't it?
Of course, modules partially solve this but polyfills will still do feature detections and pollute globally.

As summary: in a parallel universe where developers couldn't change the environment your point would be more than valid, but I think that's not really how the real-Web-world moved forward for the last 20 years.

If every other vendor agreed, please consider to follow this de-facto need and pragmatic solution for the sake of the Web, thank you.

@WebReflection

I'm not sure why this bug is still opened or still considered as something to be changed.

Well, since no‐one else seems to agree with me and @trusktr, I think I’m fine with this being closed. I still don’t like is, but I can live with it.

@Zambonifofex the DOM is old and not perfect, neither is the is attribute as solution. However, it solves everything every native HTMLElement has solved during the last 25 years without any need to reinvent the wheel. Moreover, it doesn't require O(n^2) amount of nodes (named custom elements plus eventually native links/input/whatever inside) and also it makes it possible to better integrate with the Web platform.

An example over every other, is the bloody tr that cannot be wrapped around a custom-tr element because it will break and table are still the best, semantic, accessible way to display tabular data.

TL;DR nobody likes is but whoever worked with it will admit is the most pragmatic, easy-peasy, cross platform friendly and working solution we have so that every developer moved forward building great stuff based on such attribute.

The previous x-img tag goes even further, using CSS like img[is=x-map], x-map {} to have common styles for before and after the upgrade which replaces the image with something else that has nothing to do with an image (it's a Leaflet canvas/iframe/different-world)

Why not closing this chapter and move forward then, since there are no equivalent solutions that either work or that have been even proposed?

So please, let's implement is and move forward the Web. Thank you!

FWIW, we're going to iterate our opinion that we're not going to implement is attribute in WebKit.

That's very unfortunate.

@paulkinlan wrote a great piece on platform inconsistencies recently, "The Lumpy Web".

• Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
• We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
• Developers should raise more issues to keep browser vendors accountable when there are differences

I hope this inconsistency doesn't become detrimental to the adoption of Custom elements.

The thing is, Apple has been objecting to this feature from the get go, and the only reason it remains in the spec is because Google kept objecting to it being removed from the spec.

The fact of matter is, we only agreed to keep it in the spec to wait until the feature becomes at-risk at CR stage so that it can be removed.

It's extremely frustrating for you to then make arguments to implement this feature after the fact. We've had this discussion before, and nothing has changed. So why do you think keep making the same arguments would change anything?

'cause we're all thinking, reasonable, people and Custom elements with is attribute have been already adopted and not only by Google and Chrome.

It's extremely frustrating for you to then make arguments to implement this feature after the fact.

Sorry, I don't mean to minimize previous spec discussions. There are a ton of historical conversations that have taken place outside this bug...over many many years! It's hard to follow Webkit's full reasoning without that reasoning being documented here. Would be nice to have a summary on this bug.

I think what you're seeing now is feedback from the actual dev community. Web developers don't participate in spec discussions. Github bugs makes things more approachable.

Feedback from stakeholders - developers, toolmakers, end users, etc - is valuable. I'm grateful that people have provided it in a constructive and polite manner, because attacking individuals isn't helpful.

There doesn't seem to be new information here. There are people who think is= is a bad idea, and people who think it is worthwhile. I think we should close the discussion, and let the W3C Process operate.

@rniwa isn't unique in opposing is=. He is a thoughtful intelligent person who disagrees with the apparent majority of the 10 participants in this discussion.

Apple is not unique as an organisation in opposing the attribute.

At the same time, there are many who think it is a good idea. Personally I agree with @WebReflection that it is of limited, but real value and we are better off having it than not. As chair, that doesn't mean I can impose it.

The attribute is in there for now, with supporters and detractors. Given the obvious lack of consensus to either keep or remove it, the W3C Process includes testing whether there is a likelihood of interoperable implementation which will probably boil down to looking at actual implementation. Nobody is obliged to implement, we will look at what the market does.

Apple (and others who share their dislike for is=) know how to suggest that something is removed from a specification on technical grounds, and have said clearly before that they don't intend to support this. Others have said they do.

The Web doesn't develop in lock step because it isn't imposed by a single actor, and overall that seems to be a strength. It is quite reasonable in a market for some players to decide not to implement something. It is unfortunate that this produces inconsistency at the bleeding edge, but it also gives us great power to let innovations come from anywhere instead of only market-dominating players being able to do it for us.

Our process enables this deliberately, for reasons beyond the above. One of them is to make sure our work is not illegal anti-competitive industry collusion. That's important to a lot of companies who are important in this area. Anyone who wants to go further down that topic, which is beyond the scope of the Working Group, can buy me a beer and lecture me or let me lecture them. But please, not here.

An alternative to is="" could be custom attributes. @rniwa mentioned mixins and this would be a form of that (maybe you had something else in mind). I think it solves the issues that people on boths sides have, and could have a very similar API to custom elements. Something like:

class FooBarAttr {
  attachedCallback() {
    console.log('was created for first time');
  }

  changedCallback(newValue, oldValue) {
    console.log('it changed');
  }
}

customAttributes.define('foo-bar', FooBarAttr);

This would be super simple to polyfill with MutationObservers as well.

@rniwa A solution to this element.localName == aTag is easily, hack that. Create internally two elements, linked in properties(css and javascript), is really hard to implement that? Ok performance is not excelent but is really more slow than actual "is" implementation? Perdon if this is bullshit

@matthewp

If you haven’t already, maybe you should create a new issue thread asking for this. It sounds like an excellent idea that’d get more attention if it was in its own thread.

@matthewp @Zambonifofex

I believe attributes should be on a per-custom-element basis, otherwise globally registered attributes will get messy quickly. Many custom elements may depend on values of attributes with the same name (I.e. name clashing can become a nasty problem).

In native HTML, style="" is common across many elements, if not all. This type of thing should happen through extension. If my custom element has special behavior based on a foo="" attribute, and you extend it to make your own custom element, then your element will inherit that attribute behavior. Likewise, we can explain the style attribute the same way due to the fact that custom elements can inherit it from HTMLElement (I think that is where style behavior is defined?).

@trusktr

What about being able to define both global attributes and attributes on specific elements?

customAttributes.define("foo-bar", HTMLElement, FooBarAttr); // Global attribute
customAttributes.define("foo-baz", MyElement, FooBazAttr); // Element‐specific attribute

Still, I like to encourage the practice of pseudo‐namespaces. That is, when writing a library, named, say, “my library”, instead of having a fancy-button element, have a my_library-fancy_button element. Similar thing with attributes.

I would like to put my small feedback as a web-developer and would like to add another point to @ebidel 's list why is is important for my team and our products (custom elements).

It simplifies and optimizes not just styling, accessibility but also parsing.

We've created a number of vanilla CEs that extends <template> (far away from Google, Polymer, and their templating magic). The most important thing here is the inertness of element, which we cannot implement by ourselves . Probably, we can get it by just extend HTMLTemplateElement but it still will not solve the problem completely.
Before element definition is (lazily) loaded <our-template>...</our-template> will render ....

Removal of is (or equivalent/Custom Attributes) will require CE users to write <our-template><template>...</template></our-template>. Which not only look redundant and counter-intuitive, require more code on CE user side, as well as on CE dev side (as mentioned above), but what's most important <our-template> will still take part in regular rendering (could get styled, etc.) until it's definition is loaded.

This is just a reminder that my V1 polyfill forces is="native" feature in browsers that don't support it, and it uses it natively where available.

I think we, developers, will find a way to implement is="native" feature in a way or another; I just wish they (browser vendors) will stop pushing back instead of understanding its use cases that are simply or practically impossible to reproduce otherwise.

template, tr, body, and even html are just few examples of what we're missing as extending possibility for the whole Web platform, present and future.

@tomalec or just <our-template></our-template> is not removal of is= but deprecate, like all other features on web. Actually polymer use template with <template is="dom-repeat">, if is= turn optional allow that <dom-repeat>

There's been a lot of argument here about why some people like is="" and others don't, but I'd like to hear constructive suggestions from the anti-is side of how we can extend custom elements without using is while preserving all of the functionality of the native element and compatibility with browsers that don't support custom elements at all.

Consider this custom element:

<a is="fancy-anchor" href="/something">Fancy Anchor</a>

If is="" isn't an option, I'm assuming that the element would look like this:

<fancy-anchor href="/something">Fancy Anchor</fancy-anchor>

If that's the case, how does one implement it so all of the following are true?

• A screen reader can always recognize that it is a link to another page
• Clicking on the link opens /something when JavaScript is disabled
• fancy-anchors can be focused using the tab key in IE8
• The script that defines fancy anchor can be loaded asynchronously
• A search engine will be able to tell that there is a link to /something on that page.

@richardkazuomiller You have MutationObservers at your disposal, so you can mimic everything is gives you in normal JavaScript unless you depend on synchronous callbacks. So you don't need to create a <fancy-anchor> element but rather can use a data-fancy-anchor attribute on a normal anchor, use mutation observers to know when the element is connected/disconnected and when attributes change.

@matthewp That defeats the whole purpose of having custom elements and introduces a whole other set of issues. The whole point is that once a custom element is implemented it can be created anywhere and treated the same as any other element. If upgrading the <a> to a fancy anchor depends on a MutationObserver, that means they will never be upgraded until they're inserted into the observer's target. If we need it to be upgraded it before it's inserted into the DOM we need to call some other function every time we want to create a fancy anchor, which means more code that doesn't follow a standard, probably more dependencies, and we're back where we started.

We at least all agree that being able to create a subclass of a native element – with or without is= – is a good idea right?

@richardkazuomiller Webkit is opposed to subclassing native element subclasses outright, see comment from @rniwa above (#509 (comment))

Oh, I misunderstood subclasses of native element subclasses to mean subclasses of user-defined subclasses. My mistake.

So I guess the answer to my (admittedly mostly rhetorical) questions really are "don't use custom elements". That's worse than I thought. In that case I'd like to rebut some of the points made by the anti-is side, from my point of view as a developer.

The is="" API can be confusing

I've never heard of anyone who found it confusing. The intent of it is clear. Besides, if we bikeshedded every confusing part of the web until everything was perfect we wouldn't have browsers at all.

subclassing ... often leads to a violation of the Liskov substitution principle

Things breaking because of an update to a superclass's implementation happens is a fact of life. It should be avoided wherever possible, but eliminating subclassing altogether is not the answer. The possibility of a hypothetical input type being added is not worth throwing away all the possible custom input types developers could be making. Don't throw the baby out with the bathwater

none of the builtin elements are designed to be subclassed

I can say from experience that whether they were designed for it or not, subclassing native elements works very well. While there may be limitations when extending inputs, for example, it's easy to work within those limitations.

I don't get why people keep making claims that is= improves accessibility. It simply doesn't except the very simple scenario in which the entire UI of the builtin form control is preserved (e.g. just adding JS methods).

I think you're assuming that preserving the builtin UI isn't exactly what a lot of devs are doing. Look at Polymer's iron-input. No crazy shadow DOM stuff, just key bindings and a validator but that alone is very powerful. I've extended HTMLInputElement in my own applications to build things that are very complex, but thanks to custom elements I can just add is="whatever-input" to another input so they are also portable.

One might suggest that instead of extending native elements, we should create some kind of wrapper or bind events when the document loads or something, but custom elements v1 works with elements created with document.createElement, appended to another element as HTML, rendered as the HTML in the first request streams in, or any other way elements get created, without requiring any extra JS. If WebKit decides not to implement is=, thereby making progressively enhanced native elements impossible and forcing developers to write more code, people are just going to keep using the polyfill.

I'm just a lowly webdev, so while I have opinions about the big-picture future-of-the-platform stuff, I'll leave that to you folks. I hope you'll consider my perspective when implementing (or not implementing) the spec.

I would really like to have the ability to use the unreproducible features of native elements in custom ones. I don't really mind if that's through inheritance or some other "mixin" approach.

Beyond even accessibility, which to me seems to be the biggest reason to want this, there are things like <datalist> which (in browsers that support it, hint hint) will produce a dropdown menu that overflows the browser window. Clearly no (sane) web dev is going to attempt to rebuild that from the ground up. I would love to be able to extend <datalist> to have custom matching routines, for example. Of course, I'd also love it if the native element was in Webkit in the first place ;)

The problem with <datalist> is that it's really not extensible. The existing implementations aren't fabulous - but they are so close, and could be made amazing with just a few extra touches.

The same thing applies with the venerable <select> too - especially on mobile platforms. There are interactions there that are simply not possible with a purely custom element - and not even possible (or at least straightforward) with custom elements that wrap / utilise the native ones inside. The fact that we web devs can't simply use those powerful native capabilities without recreating them from scratch, or hacking around with composing them, is a real shame for the web.

As I said, I'd be fine with mixins instead of inheritance - has any effort been put into specifying that? Would it mean I could still get all the unreproducible behaviours, of let's say a <select> tag, and add my own implementation pieces?

FWIW, since "yurak is working on this", I guess all we have to do is wait that Firefox and Edge would follow and keep polyfilling WebKit (hopefully not forever).

This is a page to check builtin extend status.

_{This is the same page using my polyfill.}

Suppose I'm using for example <app-drawer> or <chat-app> in my app. At this point is there any point to me considering the is syntax?

I'm not trying to argue for or against it, just trying to understand the When it is of interest part better.

@oleersoy I don't think so. is is supposed to customize/extend built-in elements, so you could use their parsing, accessibility features, etc. even before your element is upgraded. For example: <input is="spaceship-coordinates">, <template is="enhanced-template">.

So I just want to confirm that if I'm using <app-drawer then there is no point in using the capabilities of is because the <app-drawer> element is not something that is amenable to progressive enhancement?

In other words there is no point in doing is="spaceship-coordinates", because even though that part could fall back to a normal input field for browsers that don't understand what the is is for, the <app-drawer> element would completely break, so essentially the app would be an airplane with the wings missing?

@oleersoy the is="enriched-element" has different use cases than <custom-element>. If you want to have exactly same native behaviour and extend it on top, you need the is attribute through the builtins extend way. There are no valid and universally compatible alternatives to this approach, so it's a matter of when rather than if these are needed.

template, th, tr, body, head, html are just few examples where you simply cannot use a custom tag with same/needed element inside because the result would be breaking for the surrounding HTML or the page itself.

a, button, input, iframe, form are, on the other hand, things well handled and known by browsers and bring in a lot of things automatically. In these cases you can wrap these native builtins around through redundant, not needed, verbose HTML, or create them at runtime (and once) on connectedCallback losing completely graceful enhancement.

A canvas-3d could be created with both approaches, but if you put a canvas inside a canvas-3d you are still in redundant-land but it's not such big deal since canvas is not much accessible
anyway. Everything else with builtins special meanings is problematic to reimplement.

Last, but not least, if you have a custom element that doesn't need to extend any special functionality beside what HTMLElement provides already, you'd go with the regular extend through the tag name and basic definition.

Most of the time, that's all you need but as you can see, developers can, and will, use Custom Elements in various ways.

I hope I've clarified most common use cases.

@WebReflection Those are some great examples (^_^)

@oleersoy To add to the previous comment, <app-drawer> wouldn't necessarily break in browsers that don't support custom elements if it's implemented in the right way. You should check out this video of how to make a progressively enhanced accordion custom element by the Chrome Dev team (more links below). Try looking at it (in Chrome) with and without JavaScript. It's just a demo so it doesn't go as far as checking for custom element support in browsers other than Chrome, but you can get the idea.

The reason an <app-drawer> doesn't need is="something" is because it doesn't need to fall back to a particular element type. When is= is not used, a custom element will just fall back to a plain HTMLElement and it will work, because all of the browsers will display an element with any tag name. Luckily, that's been in the spec since long before custom elements have been a thing and will work regardless of the fate of is=.

Chrome Developers Supercharged - Accordion
Source code from the video
The final product

So I'm trying to make my question really simple because I'd like a straightforward answer. If this cannot be answered in terms of yes or no please let me know why.

Again I'm asking whether the minute I add the Polymer <app-drawer opened></app-drawer> to my app, it effectively obsoletes previous work done to make a progressively enhanced app?

BTW - I'm saying Polymer specifically because I prefer not get into "Well if it was implemented this way theory". If we expend enough effort we can do anything. Just ask the Microsoft team that tried to integrate the browser into the desktop.

@oleersoy The approach I suggested will work with Polymer's app-drawer. Just use CSS to make the app-drawer show its contents before it's upgraded and remove those styles if Polymer is available. You can probably get more specific and helpful answers about a particular Polymer element if you open an issue on that element's repository.

@richardkazuomiller Thanks that seems reasonable. What if the <app-drawer> uses the shadow-dom - will it continue to render and work as expected, given that we override the css used to display the element initially? @rniwa IIUC seems to be saying that any custom element that uses the shadow dom will terminate the progressive enhancement capability afforded to us by is?

If you're using an autonomous custom element (i.e. not using is attribute in your code), all of that is irrelevant. Regardless of whether app-drawer uses shadow DOM or not, it functions as expected.

Regardless of whether app-drawer uses shadow DOM or not, it functions as expected.

Not necessarily true for custom elements in general. Try using ShadowDOM with the A-Frame Custom Elements that are available at http://aframe.io, and you'll see that they won't work as expected (jsfiddles). A-Frame (and any other Custom Element libraries used for constructing custom render trees) need to be able to construct an internal representation of the final flat tree which is the result of composed shadow trees, and then the internal representation of the flat tree can be used (for example) to render a scene in WebGL or Canvas 2D.

Not necessarily true for custom elements in general. Try using ShadowDOM with the A-Frame Custom Elements that are available at http://aframe.io, and you'll see that they won't work as expected (jsfiddles).

That's pretty orthogonal to what we're discussing here. That's just a limitation on the current shadow DOM API.

@oleersoy Custom elements go through an upgrade process, which means PE is a built-in feature of the API. Consume components under the assumption that JS may never run. Then, sometime in the future JS does run, registers the elements. Boom. You're progressively enhancing that markup.

This article and my presentation the PWA summit earlier this year discusses the notion of "progressively enhanced markup". Video.

@ebidel just saw your comment now. Huge fan of your articles! I'll amend my comment a bit in light of yours.

OK - Let me reboot my simple scenario and limit it to custom elements and javascript in general.

SIDE NOTE

My background and primary reason for looking at all the specs is that I think custom elements and the shadow dom are fantastic tools for simplifying my apps, and my gut feeling is that anytime I create an element that does something beyond just special effects, the app will break given that the custom element API is not supported / The element upgrade has not yet kicked in. I'll illustrate what I mean.

END SIDE NOTE

So suppose I wrote an app consisting of two custom elements <custom-broadcast> and <custom-receiver> that talk to each other. The <custom-broadcast> elements sends messages on a configurable attribute channel and <custom-receiver> receives them on a configurable attribute channel.

I could also have a FancyButton configured as <button is="fancy-button">Broadcast</button>. When I click the button it will tell the <custom-broadcast message="Cubs win!!!" channel="1"> element to start broadcasting Cubs win!! and the <custom-receiver channel="1"> will just log that to the console.

So I load this app in a browser that does not support custom elements or will not upgrade them for some reason. The FancyButton falls back to a normal not so fancy button, and when clicked nothing works.

So to me it seems as if I want an app that works well on all browsers, then I'm better off with a non custom element approach, but if I want to go bleeding edge and throw some users with dusty browsers under the bus then I would choose custom elements.

In other words I simply don't see what advantage is is offering?

Right, that was one of the arguments we (WebKit team) made to argue against is. Progressive enhancement based on is sounds nice in theory but in practice, any app that relies on JS / DOM "enhancements" made by customized builtin code would break.

Similarly, anytime a shadow root is attached on a builtin element, we can't simply assume the ARIA role of the underlying element. For example, imagine input's type=date didn't exist and we were building it as a customized builtin element. Then by attaching a shadow root on input (which is not even allowed in shadow DOM API at the moment), and introducing controls for changing months, etc... in the shadow tree, we're effectively rewriting the semantics that need to be communicated with the assistive technology. So, in practice, user agents would need to use the flat tree to construct the accessibility tree anyway except all but the simplest of the simplest case.

If your app breaks because a certain API is not available, you're doing progressive enhancement wrong.

The argument that a feature doesn't have any advantages because it might break in old browsers could be made about literally any new browser feature and if we accepted that we'd never make anything new.

As for the shadow DOM stuff, I honestly don't think that has anything to do with is. Attaching a shadow root to a builtin element might introduce complexity, but as a few people have said already, there are many use cases for custom elements that don't have anything to do with shadow DOM. This has already been proven by the fact that custom elements are already being used in production when shadow DOM is still only in Chrome. Shadow DOM and custom elements are often used together, but discussions about the two should be kept separate.

@oleersoy in that scenario no, fancy-button wouldn't offer progressive enhancement because you're not progressively enhancing a button, you're giving it core functionality that your app is broken without.

There are lots of good examples of progressive enhancement enabled by extended builtins (eg: iron-input mentioned above). An example from our own work - we're building a wc content management library, and by extending builtins we can render content to elements before upgrading with editing behaviours, and therefore support legacy browsers, pre-rendering, etc. Without extension this becomes infinitely harder.

Also prog enhancement is only one (admittedly very important) upside of type extension. Another is inheriting unreplicable native behaviours (eg: template, anchor, button, img, html, etc). We've found that the 'just wrap the element' hack often falls short (eg: wrapped templates existing in doc flow, losing 1:1 interop with native elements). Given, this could be provided with mixins rather than is, but then you lose the prog enhancement benefits.

If your app breaks because a certain API is not available, you're doing progressive enhancement wrong.

So how would I progressively enhance my very simple app the right way?

The argument that a feature doesn't have any advantages because it might break in old browsers could be made about literally any new browser feature and if we accepted that we'd never make anything new.

That's not the argument I'm making. The first thing I try to do when convincing someone that a feature has clear advantages in terms of:

• Improving developer productivity
• Improving code maintainability
• Improving runtime efficiency and speed
• Reducing delivery time
• Improving user experience
• And in general just making overall components of the solution simpler

Is to come up with a really simple example that shows how it does this across the board. I think custom elements, shadow dom, etc. all do this and they are complete no brainers. However I personally don't see a application development scenario where the is feature is like "YES!!!! - Hallujah finally we have this feature!!!".

I provided a very simple application scenario that illustrates my thinking. If @richardkazuomiller and @seaneking could come up with an equally simple scenario that illustrates what you are saying and causes us all to realize that the benefit of implementing is across browsers is a great thing, then that would be super helpful.

If I'm telling a team to consider progressive enhancement and specifically to use the is capability I need solid ammo, and right now I don't have any. In other words I cannot lead a team and say "If you see this scenario or this scenario or this scenario, then use the is capability" to do progressive enhancement. And by scenario I mean a simple example like the one I provided so that my team members have something concrete to go by / reference.

@oleersoy in that scenario no, fancy-button wouldn't offer progressive enhancement

I think the point of progressive enhancement is that it's progressive. From what @ebidel is saying there are two ways of looking at it. One is that the API for using a component is simply not there so that the component falls back to a more lightweight way of operating. It still works, just not with all the bells and whistles we would like. In the other scenario, the API / native capability is there but the the browser or script has not had a chance to upgrade the element yet.

So in this case it's not that the button is not offering PE. It offers it because of how it is declared <button is="fancy-button">.

because you're not progressively enhancing a button

That's true because that's up to the runtime (Although I have tried progressively enhancing a few things, but my wife always objects, so I've mostly given up).

you're giving it core functionality that your app is broken without.

I think what you are saying is precisely what I'm trying to illustrate. I have a button that can be progressively enhanced and two custom elements that form the entire app. If those custom elements don't work, the app is broken. So why then use custom elements at all? We are assuming that the is capability is generally going to be blended with the usage of custom elements right? Otherwise why have it in the v1 spec?

Also prog enhancement is only one (admittedly very important) upside of type extension. Another is inheriting unreplicable native behaviours (eg: template, anchor, button, img, html, etc).

This I totally agree with. I almost tattooed "Just wrap the element" on my forehead once, before getting more smarterer. I would love to see one example that uses custom elements in a minimal and realistic app that demonstrates how is is better than just extending and creating a <fancy-button> using a more minimal API that excludes the is capability.

Again if there is one way to do it, and we say that we can also do it this way, then there should be some significant advantage over the next 4 years to doing it both ways. Otherwise we are just introducing more stuff to learn about and make decisions with and possibly further complicate a already fairly advanced set of tools with a fairly steep learning curve that we use to produce awesome things and this does does not just waste our time, but the time of millions of developers, maintainers, product managers, and investors.

So how would I progressively enhance my very simple app the right way?

I think discussing that is out of the scope of this issue.

I provided a very simple application scenario that illustrates my thinking. If @richardkazuomiller and @seaneking could come up with an equally simple scenario that illustrates what you are saying and causes us all to realize that the benefit of implementing is across browsers is a great thing, then that would be super helpful.

See the example in my previous comment

I think discussing that is out of the scope of this issue.

Of coarse why would the practical application of the technology you are recommending be in the scope of the issue?

See the example in my previous comment

I have not seen a single example that makes sense in an application context. If you think that one component makes an application and progressively enhancing a single component in a vacuum is a great reason to ask millions of developers and product managers to understand this topic then good luck convincing Apple and MS. "Here guys this is going to useful to you 0.0000000001% if the time. Bon appetit!!".

@oleersoy

So I load this app in a browser that does not support custom elements or will not upgrade them for some reason. The FancyButton falls back to a normal not so fancy button, and when clicked nothing works.

Your example, a specific use case that ignores all other already discussed in here, relies heavily on JS regardless the usage of the is attribute.

So, if your question is if you should use a polyfill or not, that covers also the is attribute like dre does, then you are the only one that can answer such question: are your target browsers already spec-compliants? Then don't, otherwise go agead and use a poly based on features detection 'till that day.

I have not seen a single example that makes sense in an application context.

This is a good old example from V0 era that shows just one of the huge amount of benefits of the is attribute. It's a cross map and it works down to IE8 and Android 2 or iOS 5 (and BB7, webOS, etc)

Somebody took that example saying "you could've just used a wrapper element" but that would be meaningless and redundant on the layout, and it might cause gotchas on IE8 side which is incompatible with randomly named elements (and CSS).

The curent polyfill now fallbacks to V0 but it brings in V1 as much as it can (there are parts of V1 that cannot be polyfilled these days) and your specific use case would be covered too.

Somebody went further away with the map element using layers and much more, still Custom Elements only: https://customelements.io/Maps4HTML/Web-Map-Custom-Element/

Last, but not least, I've used Custom Elements for years now and never together with ShadowDOM due greediness of the old polyfill with WeakMaps that were breaking all over.
That doesn't meen ShadowDOM is bad or anything, it's actually pretty amazing, but it's absolutely complementary with Custom Elements, not mandatory at all.

relies heavily on JS regardless the usage of the is attribute.

So what is the minimum amount of that JS that you would like the broadcasting example to contain in order to make it work well with the isattribute?

So, if your question is if you should use a polyfill or not

Where in the simple broadcasting example I provided did I ask that?

This is a good old example from V0 era that shows just one of the huge amount of benefits of the is attribute. It's a cross map and it works down to IE8 and Android 2 or iOS 5 (and BB7, webOS, etc)

What's the benefit? Specifically what is the is attribute doing that if it were not present you could not do?

It's already a custom element x-map - so it has to be upgraded in order to work ... so how is the is attribute even relevant? It's supposed to be used on non custom elements like <button>, etc. right?)

Last, but not least, I've used Custom Elements for years now and never together with ShadowDOM due greediness of the old polyfill with WeakMaps that were breaking all over.
That doesn't meen ShadowDOM is bad or anything, it's actually pretty amazing, but it's absolutely complementary with Custom Elements, not mandatory at all.

I looked at your x-map repository and it's obvious that you are a very talented developer, so I'm really hoping that you can come up with something that overcomes our doubts about the value of the is attribute. If you can rearchitect the simple broadcasting example I provided to somehow work well and provide value using the is element according to some of the criteria I have outlined above that would be really great.

your demo example does not work without JS and unless you have a live editable version of it I'm not sure what you are asking for but I have a counter question: how would you create a fancy-button without is?

The fact you don't consider all examples already described like template or even html does not mean these don't exist: it's you ignoring them and thinking only about your use case.

That one, I am afraid, I cannot fix.

your demo example does not work without JS

Neither do custom elements.

The fact you don't consider all examples already described like template or even html

Why would you want to PE the html tag? Or more importantly how many developers want to PE the html tag and when do they want to do this?

The is might be useful in certain cases. Sort like a nail and a 2X4 could be useful on an oil platform. The dude's on the platform might be like "Umm....What are you doing with that 2X4?

That one, I am afraid, I cannot fix.

I know. And that is what the core argument should be about. I'm guessing 99.9999% of developers are going to be looking at exactly this scenario. So should we add to the developer learning curve with is to support 0.00001% of use cases?

And if it's really easy to handle those cases with what we already now, then why is the is even in the spec?