The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension.

[trusktr]

The is="" API can be confusing, and awkward. For example (in current v1 API):

inheritance currently has to be specified three times:

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

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

But, I believe it could be better:

inheritance specified once, easier non-awkward API:

class MyButton extends HTMLButtonElement {} // 1st and only time
customElements.define('my-button', MyButton)
<my-button></my-button>

But, there's problems that the is="" attribute solves, like making it easy to specify that a <tr> element is actually a my-row element, without tripping up legacy parser behavior (among other problems). So, after discussing in this issue, I've implemented an idea in #727:

mixin-like "element behaviors", without extending builtins

The idea uses a has="" attribute to apply more than one behavior/functionality to an element (is="" can only apply a single behavior/functionality to an element), using lifecycle methods similar to Custom Elements.

For example:

// define behaviors
elementBehaviors.define('foo', class { // no inheritance necessary
  connectedCallback(el) { ... }
  disconnectedCallback(el) { ... }
  static get observedAttributes() { return ['some-attribute'] }
  attributeChangedCallback(el, attr, oldVal, newVal) { ... }
})
elementBehaviors.define('bar', class { ... })
elementBehaviors.define('baz', class { ... })

<!-- apply any number of behaviors to any number of elements: -->
<div has="bar baz"></div>
<table>
  <tr has="foo baz" some-attribute="lorem"></tr> <!-- yay! -->
</table>
<button has="bar foo" some-attribute="ipsum"></button>
<input has="foo bar baz" some-attribute="dolor"></input>

In a variety of cases, this has advantages over Custom Elements (with and without is="" and):

1. No problems with parsing (f.e. the table/tr example)
2. No inheritance, just simple classes
3. Works alongside Custom Elements (even if they use is=""!)
4. "element behaviors" is similar to "entity components" (but the word "component" is already used in Web Components and many other web frameworks, so "behaviors" was a better fit).
5. Lastly, "element behaviors" makes it easier to augment existing HTML applications without having to change the tags in an HTML document.

See #727 for more details.

---

Original Post:

The spec says:

Trying to use a customized built-in element as an autonomous custom element will not work; that is, <plastic-button>Click me?</plastic-button> will simply create an HTMLElement with no special behaviour.

But, in my mind, that's just what the spec says, but not that it has to be that way. Why has it been decided for it to be that way?

I believe that we can specify this type of information in the customElement.define() call rather than in the markup. For example, that very same document shows this example:

customElements.define("plastic-button", PlasticButton, { extends: "button" });

Obviously, plastic-button extends button as defined right there in that call to define(), so why do we need a redundant is="" attribute to be applied onto button? I think the following HTML and JavaScript is much nicer:

<!-- before: <button is="plastic-button">Click me</button> -->
<plastic-button>Click me</plastic-button>

// before: const plasticButton = document.createElement("button", { is: "plastic-button" });
const plasticButton = document.createElement("plastic-button");

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).

[richardkazuomiller]

@oleersoy If you think this is a waste of time, you don't have to participate. If you don't find this feature useful, you don't have to use it. We're trying to come to an agreement about whether or not inheritance is a good idea for the web and how to move forward one way or another. If you want to provide an alternative to is or why you think inheritance is a bad idea, you're welcome to do that, but please do not diminish other people's hard work. As @WebReflection said, many people here have devoted a lot of time to this. The people working on this feature have invited developers to join the discussion but they have no obligation to do so and could just as easily decide to ignore us if we don't talk to each other in a civil and productive manner.

[richardkazuomiller]

Let me try asking a broader question.

Inheritance makes a lot of things possible on other platforms that will never be possible without the web without is= or a better alternative. The fact that subclassing a UIImageView on iOS, ImageView on Android, or any other UI object works is one of the reasons native apps are doing way better than the web on mobile because integrating compatible code from different sources is much easier. The ability to extend existing classes allows us to build upon existing tools in a way that makes them interchangeable anywhere its parent class is used, but that's not possible on the web yet. I think the web's future will be brighter with the semantics of a class hierarchy.

We already know that wrapping builtins doesn't always work. Mixins don't always work either and introduce complexity and compatibility issues. The semantics of builtin elements provide accessibility features that are either impossible or too difficult to implement from scratch. Knowing all of that, the best solution I can think of is builtin element subclasses.

The most compelling argument I've heard from the anti-is people is that the builtin elements were not designed to be subclassed. That's a fair point, but it sounds like a fixable problem to me and is has already proven to work pretty well so far with the v0 and v1 polyfills. I think the benefits of inheritance far outweigh the potential cost of fixing issues that might come up.

If subclassing builtin elements is not an option, how else is the web going to catch up with the other platforms?

[EduardoRFS]

@richardkazuomiller Subclassing, without ìs=, extending classes and on definition of element, is defined on registerElement "extends", not need is=, but is REALLY more easy to implement(on browser) using is= is the point on topic, as rniwa said

is= work, but is not the best solution, without is= remove redudant code

[richardkazuomiller]

@EduardoRFS is= is not perfect, but without something in the markup that defines what a custom element's superclass is, progressive enhancement and a lot of a11y are broken. In my first comment I pointed out five things that is= solves that can't be solved with JavaScript.

The other example @tomalec provided of a subclass of <template> would also not work with a solution that depends on JavaScript because a browser that has JavaScript disabled would render the element's contents which a template is not supposed to do. The browser needs to know that <our-template></our-template> is an instance of HTMLTemplateElement before JavaScript runs. <template is="our-template"></template> is the only way solution that fulfills that requirement we've heard so far.

[oleersoy]

@oleersoy If you think this is a waste of time, you don't have to participate. If you don't find this feature useful, you don't have to use it.

Sigh - Dude - At least just quote what I said and why I said it and try to pick it apart to some degree. I keep telling you that it's not about me and you and you keep telling me it's about us. It's groundhog day on stereoids.

We're trying to come to an agreement about whether or not inheritance is a good idea for the web and how to move forward one way or another.

This is the request for feedback:

Note: Some browsers have expressed distaste for implementing the is="" syntax. This is unfortunate for accessibility and progressive enhancement. If you think extending native HTML elements is useful, voice your thoughts on Github.

If you want to provide an alternative to is or why you think inheritance is a bad idea, you're welcome to do that

Thanks that's very nice of you to offer that :). Do you maybe have a few scripted comments for me that you would like me to add?

but please do not diminish other people's hard work.

It's a lot of hard work and 99% of it is absolutely brilliant. Just remove the is part of the spec and it's perfect. And saying that is not diminishing everyone's hard work. All the brilliant work that has been put into this will be much more appreciated my all if you just dump the is part of the spec.

I think the web's future will be brighter with the semantics of a class hierarchy.

I totally agree. I think you should subclass button to create a FancyButton. I only disagree with the usage of is. In other words I think it should always be <fancy-button> and never <button is="FancyButton">

As a matter of fact there were a few comments also saying that subclassing is a bad idea due to the Liskov substitution principle, which I think does a disservice to this discussion because it's too abstract a notion. If there ever was a great case for inheritance this has to be it.

I'm making a very simple argument. My HP laptop has a DVD drive in it right now. I never use. I'm sure some people use it once in a while, but the need for it is rapidly disappearing. The is part of the spec is the spec's DVD drive.

Keep the subclassing. I love the sub classing. The sub classing is brilliant. Just get rid of stuff like <button is="FancyButton"> because that does not add any value. Being able to extend button and use a <fancy-button> does.

As @WebReflection said, many people here have devoted a lot of time to this. The people working on this feature have invited developers to join the discussion but they have no obligation to do so and could just as easily decide to ignore us if we don't talk to each other in a civil and productive manner.

OK - Everyone take a 10 minute timeout. No Ipad!

[EduardoRFS]

@richardkazuomiller @oleersoy is the perfect idea, make both work, if browser have javascript disabled not work, but if use <fancy-button> when Javascript is executed, upgrade him to a instance of button, actually WebComponents need Javascript, but in future with <element> is possible to upgrade <fancy-button> without run Javascript

[richardkazuomiller]

@oleersoy

Do you maybe have a few scripted comments for me that you would like me to add?

I don't know what you mean by this.

Just get rid of stuff like because that does not add any value. Being able to extend button and use a does.

You're entitled to the opinion that using is with a button is not useful, but is= is still the only way to create a subclass of HTMLTemplateElement that works when it's added to the DOM before the subclass definition is loaded. This was pointed out by @tomalec a while ago and is also true for other element types.

Right now, inheritance without is= is impossible. If you can provide a better alternative that enables creating subclasses of all builtin elements, you will have solved the problem. Since you've made it clear that you don't like is=, I think it would be good to move forward now, possibly by suggesting an alternative.

OK - Everyone take a 10 minute timeout. No Ipad!

Flippant remarks like this are not helpful.

[tomalec]

@oleersoy as you have asked for demos, code and use cases - here you have real code, demos and examples for just one of many use cases for is https://github.com/Juicy/imported-template (plus https://github.com/Juicy/juicy-html)

Here you have an article with rationale, why I find such element useful http://starcounter.io/html-partialsincludes-webcomponents-way/

This single custom element is being used for 3 years now, for somewhat around 2 yrs it's used on production by many companies.

No they don't and that's why you can't produce a single case where they actually do.

I know in person at least 20 developers from 4 different companies who uses that element. That's why, please don't say so.

As it was mentioned many times above, such use case is not achievable without is (or something conceptually similar). <imported-template>blah</imported-template> would be simply rendered as a block element, and that is something we should avoid.

If anybody knows better alternative to implement that, I'd would be more than happy to hear it.

[oleersoy]

You're entitled to the opinion that using is

Thanks for letting me know that I'm entitled to my opinion. That was very helpful.

with a button is not useful, but is= is still the only way to create a subclass of HTMLTemplateElement that works

What do you mean by works. Do you have demo?

when it's added to the DOM before the subclass definition is loaded.

So the subclass, which is the actual implementation of what we are trying to run, but has not yet been loaded, works?

Right now, inheritance without is= is impossible.

How do you explain that this works then:

Javascript

customElements.define('fancy-drawer', FancyDrawer);

HTML

<fancy-drawer></fancy-drawer>

possibly by suggesting an alternative

See above.

[pete-otaqui]

There is a lot aggressive agreement going on here.

The most basic point - which is where I think most people, outside of WebKit devs, seem to agree - is that we want an ability to use and build on top of the un-replicable behaviours of some native HTML Elements.

The rest of the arguments - which cases are useful / possible; the syntax (is=""); whether it should be inheritance or composition; etc. - are all fine but really aren't worth getting worked up about while there are browser vendors not intending to implement any way of achieving the core premise.

[oleersoy]

@tomalec thanks for pointing out the article and the demos. I really enjoyed reading the article - sincerely.

This is the part I don't get. We are saying that we need <template is="juicy-template">. But before we can use that we need to import web-components-light and the corresponding component implementation for juicy-template. So if we need to import both of these to get <template is="juicy-template"> to upgrade, then why not just specify <template is="juicy-template"> as <juicy-template>?. To me it seems that they are the same thing post importing the needed dependencies to get either case to run?

[ghost]

@oleersoy

You need to know it’s a template during parsing. A script may execute after the juicy-template has been parsed, and its children have been put into the DOM.

[oleersoy]

OK - Got it. Fair enough. Thanks.

[oleersoy]

Is there something that you can do with juicy-template that you cannot do with a web component?

[ghost]

@oleersoy

By the way, I agree that is looks horrifying, and is very counter‐intuitive. Everyone agrees it’s a hack. In fact, you’ll see me arguing against them, the same way you are, earlier in this thread. Maybe if we did everything from scratch, we wouldn’t need is, but as it stands, it’s very necessary. Besides being useful for the progressive enhancement: if I have a button type="submit" is="my-button" it will act like a regular submit button if either the browser doesn’t support custom elements, or if the user has JavaScript disabled.

Is there something that you can do with juicy-template that you cannot do with a web component?

Well, I’m not sure about juicy-template, but Polymer has “if”s and loops. They could have done <dom-if><template> instead of <template is="dom-if">, but that looks ugly, and feels very unnatural.

[oleersoy]

By the way, I agree that is looks horrifying, and is very counter‐intuitive. Everyone agree it’s a hack.

Whooohh - For a seconds there I was starting to worry that I was just drinking too much espresso in the morning :).

Maybe if we did everything from scratch, we wouldn’t need is, but as it stands, it’s very necessary. Besides being useful for the progressive enhancement: if I have a button type="submit" is="my-button" it will act like a regular submit button if either the browser doesn’t support custom elements, or if the user has JavaScript disabled.

Great points. Polymer and web-components-lite support the usage of is. If people like it and want to use it, great. Some people like the fat arrow, some people like coffeescript, etc. and obviously they free to use all these tools.

I'm fine with is being used a tool / a component of a framework / syntactic sugar. I just don't think that is should be in the spec because it's the type of thing that when browser vendors can't agree on one simple thing, it's likely to have repercussions down the line that slow down progress for the rest of us.

[tomalec]

@oleersoy Once again, here you have something you can do with is="my-template" that you cannot achieve with regular <my-template> http://jsbin.com/hagena/3/edit?html,output

@Zambonifofex

Well, I’m not sure about juicy-template, but Polymer has “if”s and loops. They could have done <dom-if><template> instead of <template is="dom-if"> but that looks ugly, and feels very unnatural.

They did so in 2.x, even though it confused quite many developers, produced new bugs, etc ;) AFAIK, they did so just to set their users free from polyfill

I does not only look ugly, and unnatural. First of all, it does not solve the entire problem. Still, you end up with <dom-if> element in your tree, which is not inert, which is rendered as any other <span> - and that is something I try avoid. Needless to mention how messy, bug-prone and performance-expensive is proper 1-1 binding of parent and children, and making sure no external mutation to those elements breaks your functionality.

[tomalec]

BTW, with is you can use your custom element inside table, tr, tbody, select,...., like

<table>
    <template is"my-template">

, but for sure you cannot use <my-element>

<table>
    <my-template>
        <template>

As template is script-supporting element while my-template is not. (spec)

[oleersoy]

@tomalec thanks for sharing the snippets. I appreciate that. Is there something that devs can achieve with less effort or better syntax that they cannot achieve with custom elements in general?

In other words I should invest my time in examining both custom elements and custom element templates, because custom element templates add this ____ feature that we simply cannot get with custom elements?

At first glance when I see this:

<table>
    <my-template>
        <template>

My gut tells me that I could arrive at the same point with:

    <my-component>

Possibly with the same or less effort. If I am right then I would prefer that someone handed me the latter from a maintenance point of view (Just my preference, it does not mean it's the right or only way), since I'm already familiar with web components / custom elements.

But there could be a reason why:

    <my-component>

Is not going to work?

[ghost]

@oleersoy

ahem

[oleersoy]

Hehe - OK - I got that but that just looks like a timing / sequence detail to me. So we have chosen to use a HTMLTemplate subclass instead of an HTMLElement subclass and this is a good thing because __?

Video elements don't get used inside the head element. Should subclasses of the template element be used in the body? And even if the answer is yes because ___, does it provide a better API, lead to a more maintainable app, speed up delivery time, etc. beyond what HTMLElement subclasses can provide?

[richardkazuomiller]

@oleersoy Coincidentally, Polymer's most recent open issue is this exact thing: https://github.com/Polymer/polymer/issues/4135

[ghost]

@oleersoy

We need to be able to use template because of its inertness. As I’ve already mentioned, examples of that include Polymer’s dom-if and dom-repeat.

Even then, that’s not the only benefit of using is. Its progressive enhancement is also very important (what if the browser doesn’t support custom elements, or if the user has Javascript disabled?).

It’s bothersome that is is the best we have, I agree with you on that — I also see it as a hack —, but it is.

[oleersoy]

@richardkazuomiller if that recent issue points us in a direction of a postulate that we cannot violate, which means we basically have to have is then you have a great argument. It's better though if you illustrate the core of the argument in simple understandable terms.

[ghost]

@oleersoy

This doesn’t work (my-element goes before the table in the DOM):

<table>
    <my-element>

This does:

<table>
    <template is="my-element">

[oleersoy]

We need to be able to use template because of its inertness. As I’ve already mentioned, examples of that include Polymer’s dom-if and dom-repeat.

We could take the view that it's better not to conflate the template with dom-if and dom-repeat.

[oleersoy]

Do you mean my-element goes first? If so why not do this?

<my-element>
<table>

[ghost]

No, I want it to go inside the table. But if I write it like that, the parser puts it before the table.

[oleersoy]

It sounds like you are saying that you want it to go inside the table and then when the code is run it puts something outside the table...we can do this with the HTMLElement API right?

[richardkazuomiller]

@oleersoy No. The parser will only allow certain types of elements inside of a table. You can't just put whatever custom tag you want in a table so we need to use a template. https://www.html5rocks.com/en/tutorials/webcomponents/template/

[oleersoy]

OK so we can use the template to get around the restriction - got it. I'm still wondering whether it is a good idea to soup up the template API to do more work vs. allowing dedicated elements to do it?

[WebReflection]

I'm still wondering whether it is a good idea to soup up the template API to do more work vs. allowing dedicated elements to do it?

I think you should stop using template or decide to never extend it natively in any of your projects.

Same goes for buttons, forms, maps, tables, and every other example previously described multiple times in intent and problems caused by not having an is like mechanism.

It's clear you don't want is to happen but it looks like you are also not capable to propose concrete alternatives that work like a native extend would, or like Custom Elements worked until now, and for the last 2+ years.

Yes, you don't need to do that, and it's very good for you because you don't have to use it or to wait for it to happen everywhere: lucky you, I'm almost envious!

So, thank you for your contribution to this discussion, but please stop telling us we're all doing it wrong and it's possible without is, because we all agreed on the fact it's not perfect but so isn't the entirety of the HTML specification, and that's legacy we don't want to break, but also the only legacy we can use to improve the current Web as a platform.

That legacy worked well so far but it's going to be stuck forever if we cannot enhance it, do you understand this is a problem in both the short and long term?

As alternative, we have 3rd parts frameworks that circumvent Web limits, meaning in my opinion that the Web, as platform, failed to keep it up, encouraging every possible sort of hack on JS side (developers will do that if necessary, it already happened in the past) instead of gracefully enhancing itself like it has done for many years, adding special elements or attributes when needed (imagine a conversation like "we don't need draggable attribute" or "we don't need checked and disabled")

HTML Elements are different, and these have a meaning in certain context that cannot be simply replaced by regular HTMLElement.

It's like being in ECMAScript 3 era where everyone hacked native constructors prototypes because it wasn't possible, and it took forever to make it possible, to simply extend Array or String and others.

The current Custom Elements have the same limitation but not everything, metaphorically speaking, is an Object with a generic object role.

As summary: we should stop wasting time saying there are no use cases for is or nobody uses it, because evidence demonstrated the contrary. We can agree to disagree then and, hopefully, move on.

For future reference, these are all the non HTMLElement classes you think nobody should be able to natively extend. You said you care about the future of this platform? Then you should care about what's being discussed in here as "least ugly but working option we have to move forward".

HTMLAnchorElement
HTMLAppletElement
HTMLAreaElement
HTMLAttachmentElement
HTMLAudioElement
HTMLBRElement
HTMLBaseElement
HTMLBodyElement
HTMLButtonElement
HTMLCanvasElement
HTMLContentElement
HTMLDListElement
HTMLDataElement
HTMLDataListElement
HTMLDetailsElement
HTMLDialogElement
HTMLDirectoryElement
HTMLDivElement
HTMLDocument
HTMLEmbedElement
HTMLFieldSetElement
HTMLFontElement
HTMLFormElement
HTMLFrameElement
HTMLFrameSetElement
HTMLHRElement
HTMLHeadElement
HTMLHeadingElement
HTMLHtmlElement
HTMLIFrameElement
HTMLImageElement
HTMLInputElement
HTMLKeygenElement
HTMLLIElement
HTMLLabelElement
HTMLLegendElement
HTMLLinkElement
HTMLMapElement
HTMLMarqueeElement
HTMLMediaElement
HTMLMenuElement
HTMLMenuItemElement
HTMLMetaElement
HTMLMeterElement
HTMLModElement
HTMLOListElement
HTMLObjectElement
HTMLOptGroupElement
HTMLOptionElement
HTMLOutputElement
HTMLParagraphElement
HTMLParamElement
HTMLPictureElement
HTMLPreElement
HTMLProgressElement
HTMLQuoteElement
HTMLScriptElement
HTMLSelectElement
HTMLShadowElement
HTMLSlotElement
HTMLSourceElement
HTMLSpanElement
HTMLStyleElement
HTMLTableCaptionElement
HTMLTableCellElement
HTMLTableColElement
HTMLTableElement
HTMLTableRowElement
HTMLTableSectionElement
HTMLTemplateElement
HTMLTextAreaElement
HTMLTimeElement
HTMLTitleElement
HTMLTrackElement
HTMLUListElement
HTMLUnknownElement
HTMLVideoElement
Audio
Document
DocumentFragment
DocumentType
Element
Image
Option
ProcessingInstruction
ShadowRoot
XMLDocument

Thanks for your collaboration.

[noopole]

 Cobol doesn't use the "is" syntax. I think it's a sign.

[oleersoy]

And I thought I was drinking too much espresso. Anyways if you want to comment on something I said feel free to paste quote it.

[trusktr]

I never thought so much about "interpreting" vs "writing with":

The is="" attribute might be better when a human or machine interprets or reads HTML as it gives more context about the underlying implementation and provides progressive enhancement, but class-names-as-tag-names may be nicer when writing and using HTML APIs where knowledge of the given element's API and its inheritance is already known from the JavaScript side.

[oleersoy]

Be careful. You don't want to point out anything that might be interpreted as being anti is. @WebReflection will rant until your comment is buried 15000 lines up.

[chaals]

@oleersoy that comment is an example of being rude, which is not constructive. Please don't.

[oleersoy]

So you consider stonewalling every request for detail and spamming the thread with accusations as being polite?

[chaals]

No. Although I see a number of arguments are presented to you in detail, so I find your characterisation of "stonewalling" unconvincing.

I had already asked people to work harder on being polite, and your message does not even attempt to address an issue.

There are some valuable thoughts being exchanged, including yours. I repeat my request to everyone to stick to a polite and respectful continuation of that discussion if there is more to add.

[oleersoy]

No. Although I see a number of arguments are presented to you in detail, so I find your characterisation of "stonewalling" unconvincing.

If you look up a few lines you'll see this:

OK so we can use the template to get around the restriction - got it. I'm still wondering whether it is a good idea to soup up the template API to do more work vs. allowing dedicated elements to do it?

That's me asking a simple unopinionated question. I have my view, but If I'm wrong it won't be the first time.

Then that's followed by .... you know what I mean. And what follows does not attempt to explore that question in any detail. That's what I mean by stone walling.

I repeat my request to everyone to stick to a polite and respectful continuation of that discussion if there is more to add.

I think that's a great idea and we will all have a much better time here if we check our opinions at the door and stick to simple examples.

[tvvignesh]

I dont know what happened to me but I had the patience today to read this entire thread.

Having is="" is better because:

1) It provides progressive enhancement and compatibility (Apple and Firefox dont intend to support them now and maybe in future)

2) It allows the search engines to understand the type of element (It will become difficult for the search engines to understand extended custom elements. Mutation Observers is not an option as well)

3) It allows the javascript disabled browsers to use the webcomponents (since it can use the native functionality that time)

4) Less code and can use the existing native implementation of the platform for the elements

5) Along with all this, it also gives good readability doing tells that I am defining a custom element named FancyElement extending button but doing does not tell me that it is of button type unless I see the element definition.

Don't worry about the future input/other type of elements getting sub classed since the pros keeping sub-classes is more than the cons.

PS: These are personal views only. May differ.

[ghost]

I only think that if I have fancy-button customized built‐in element that extends button, I should be able to instantiate it via document.createElement("fancy-button"), rather than document.createElement("button", {is: "fancy-button"}).

[WebReflection]

@Zambonifofex to be honest, I agree with you, the extend way is clunky right now, but apparently the best we have so far.

For instance, I do believe custom built-ins should be extensible just by class

class MyButton extends HTMLButtonElement {}

why would anyone need to further explicitly say extends: "button" is out of my understanding.

However, like I've said before, the whole Web platform is full of shenanigans, yet we are here today in all its glorious success!

Yet another use case for is

After building Mozilla positron, and reading their most basic example:

I've realized the awkward usage of a well known bad practice as document.write is could also be gracefully enhanced for every user and browser, in a backward compatible way, with or without JS, through custom built-ins:

TL;DR

there are 90% of benefits having the is mechanism, and 10% of vendors problems figuring out how to implement it as right as possible, but not perfectly, since we all know it's not.

[oleersoy]

why would anyone need to further explicitly say extends: "button" is out of my understanding.

That's exactly how all developers that understand the importance DRY code will react when they first see it.

However, like I've said before, the whole Web platform is full of shenanigans, yet we are here today in all its glorious success!

Because we keep iterating on it to make it easier to work with (Less is more) and more performant.

Yet another use case for is

Why not just make a <inline-write>process.version.node</inline-write> element that extends an HTMLSpanElement (if needed) resulting in <span>process.version.node evaluated</span>?

[WebReflection]

because it's not the same. My example won't show or do anything if JS is disabledand will put content in the exact place on demand but without synchronous document mutations. On top of that, it would work even for chunks injected asynchronously. It basically replaces document.write.

[oleersoy]

My example won't show or do anything if JS is disabled

Isn't the whole app broken in this case?

will put content in the exact place on demand

For that you need javascript and you can do that with a custom element

without synchronous document mutations

The browser uses an event loop. All document mutations are synchronous.

On top of that, it would work even for chunks injected asynchronously.

You can do push notifications in a custom element.

[WebReflection]

Once again, my example does exactly what document.write would do, without breaking the document inline and synchronously. You cannot reproduce my example with other elements, it's similar case of a tempalte one. script is a special element and it cannot be replaced with any other, this is a fact.

<script is="ruby-runtime"></script> could be another case, and <script is="webgl-sharder" type="x-shader/x-fragment"></script> another one too.

script has been used for ages already for valid reasons and its transparency. If you'd like to learn more about how script is special, you can start from here: https://www.w3.org/TR/html5/scripting-1.html#the-script-element

Best Regards

[oleersoy]

Here's how I understand the sequence of events that have to happen in order for this to work. 1) First the custom element polyfill has to load 2) The custom element definition has to load 3) The browser has to upgrade the <script is="document-write"> elements 4) Then connect the elements triggering the connectedCallback event 5) The custom element code evaluates the js and creates the corresponding text node

In that sequence it does not matter whether the element is a <inline-write> element or a script element that gets upgraded to a document-write element. The connectedCallback event code is the same in each case.

[WebReflection]

Once again, any other element would behave differently from a script one.

There's literally nothing else I need to add to my example.

Other cases I have mentioned such <script is="x-sharder" type="x-shader/x-fragment"></script> keep being ignored. We can't have a regular conversation if we pick only the convenient part of it and I've already stated my intention contribute in not closing this thread.

Best Regards

[oleersoy]

I'm only addressing the example demo you've displayed, because that's something we can all see the code for. I've also said that we can do this with a <inline-write> element. So my question is why do it differently, because I believe in the premise that the is syntax really is confusing or not that it's confusing but it's less clear and will lead to solutions that are really hacks built on top of a hack.

The other examples I can't comment on because there's no nor markup displayed. If you say with <script is="x-sharder" type="x-shader/x-fragment"> contained within this context the end result is _____, then I can actually comment on it.

BTW I think we are both having a pretty good discussion here.