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

[ebidel]

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.

[chaals]

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.

[matthewp]

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.

[EduardoRFS]

@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

[ghost]

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

[trusktr]

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

[ghost]

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

[tomalec]

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.

[WebReflection]

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.

[EduardoRFS]

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

[richardkazuomiller]

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.

[matthewp]

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

[richardkazuomiller]

@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?

[madeleineostoja]

@richardkazuomiller Webkit is opposed to subclassing native element subclasses outright, see comment from @rniwa above (https://github.com/w3c/webcomponents/issues/509#issuecomment-230599443)

[richardkazuomiller]

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.

[pete-otaqui]

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?

[WebReflection]

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

[oleersoy]

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.

[tomalec]

@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">.

[oleersoy]

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?

[WebReflection]

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

[richardkazuomiller]

@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

[oleersoy]

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.

[richardkazuomiller]

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

[oleersoy]

@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?

[rniwa]

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.

[trusktr]

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.

[rniwa]

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.

[ebidel]

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

[oleersoy]

@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?

[rniwa]

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.

[richardkazuomiller]

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.

[madeleineostoja]

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

[oleersoy]

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.

[madeleineostoja]

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

[oleersoy]

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!!".

[WebReflection]

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

[oleersoy]

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.

[WebReflection]

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.

[oleersoy]

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?

[WebReflection]

Your data doesn't reflect this thread since you are basically the only one that keeps saying is has no use cases while everyone else already described use cases. I name template and you ignore it.

I name tr and you ignore it. I can name form and you ignore it. Graceful enhancement means a basic layout works in style and funcitonality even without JS but then you can enrich it through JS.

html is a unique tag and for a singel page app it makes perfect sense to use it as cusom element and enrich capabilities asynchronously as soon as the JS is downloaded in a non blocking way ... but you ignore it.

So I think it's clear there's nothing you are looking for, you just want to keep stating your point of view. Yeah, we got it, you don't have the need for is while the 80% of developers in here do.

Polymer used is for long time and successfully too so you also have production cases to consider ... but you won't, and I'm done here.

[oleersoy]

I name template and you ignore it.

Every time you show me something that is an example of how to go about using is, it's something that does not need to use is. Your x-map example does not need is. You decided to ignore that. So go ahead pimp out template for me. SHOW ME the demo??

I name tr and you ignore it.

Demo?? You can name things all day that does not make a case.

html is a unique tag and for a singel page app it makes perfect sense to use it as cusom element and enrich capabilities asynchronously as soon as the JS is downloaded in a non blocking way ... but you ignore it

Not at all. You can do that perfectly well without is.

So I think it's clear there's nothing you are looking for, you just want to keep stating your point of view.

No - I want the web platform to be as simple as possible to work with and I want rapid progress, and things like this are delaying the party.

Yeah, we got it, you don't have the need for is while the 80% of developers in here do.

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

and I'm done here.

Yes you are because you have nothing of value to add.

[WebReflection]

Once you'll show me a table that works same as the following one avoiding is attribute, I'll start replying because right now all I think is that you are trolling.

<table is="sor-table">
  <tr is="rainbow-row">
    <td is="special-td">how to tr and td without is attribute?</td>
  </tr>
</table>

Once you'll show me a <template is="special-template"></template> that works like a template would, you'll probably have other developers attentions too.

'till then, have a nice day.

[oleersoy]

Once you'll show me a table that works same as the following one avoiding is attribute, I'll start replying because right now all I think is that you are trolling.

Right - pointing out that your x-map demo is not even a candidate for is PE is just trolling.

<table is="sor-table">
  <tr is="rainbow-row">
    <td is="special-td">how to tr and td without is attribute?</td>
  </tr>
</table>

I'll give you this one. How are users going to feel when the row is not a rainbow-row and the td is not special, and the whole table is not sortable? You can do this, but how often is a user going to be in a situation where this is not just a sparrows fart in the middle of Alaska?

Once you'll show me a that works like a template would, you'll probably have other developers attentions too.

I'm pretty sure I have their attention. What does special-template do? It's inert to start with, so users don't know it exists, and once you have javascript anything you can provide utility functions that will do anything you can do within special-template.

[chaals]

People, please don't insult others, assume you know their motives and they don't, or similar, in discussions.

https://www.w3.org/Consortium/cepc/

[WebReflection]

pointing out that your x-map demo is not even a candidate for is PE

the is attribute has been around for years now in V0. I have said it's an old demo but feel free to keep talking about it.

I'll give you this one.

There are other similar cases, specially with nested elements with meanings such LI or DT or PICTURE or others. You'd give me all of them because like I've said already in my first reply to you:

There are no valid and universally compatible alternatives to this approach, so it's a matter of when rather than if these are needed.

Moreover ...

How are users going to feel when the row is not a rainbow-row and the td is not special, and the whole table is not sortable?

They'll have a table with tabular data. This is the graceful enhancement everyone talked about so far in here.

You can do this, but how often is a user going to be in a situation where ...

Every user with a browser that hasn't fully adopted the current specifications, since you said polyfills are not an option for you.

In my case? Nobody, the polyfill has hybrid mode support so that your flavor of <custom-elements> work natively, and those with builtins is and extend work polyfilled.

This is how custom elements worked for the last 2 years, via polyfills, ask AMP HTML team, Skate, Polymer or others how this did go so far, I think pretty well would be the most common answer.

Best Regards

[ebidel]

Plea that everyone remains nice: Even though this issue is closed, it's important that it stays open so other developers can voice opinions on is="" and the discussion can keep going in a central place. Let's not get the thread closed :)

[oleersoy]

the is attribute has been around for years now in V0. I have said it's an old demo but feel free to keep talking about it.

You brought it up. Personally I just came across is now in V1 of the spec. If neither Apple nor MS adopts it, then we all need Polyfills if we want to provide a good user experience and we will probably need that for custom elements for a long time even if they do, which is exactly why we don't need is.

Cheers

[WebReflection]

to some extend, jQuery has somehow "polyfilled" way less perfromant browsers for more than a decade so I'm OK to keep polyfilling 'till they add the feature.

You? Of course you can chose to do whatever you like, and just to be clear, the is attribute is not blocking anyone, it's just in specs.

WebKit already shipped Custom Elements v1 without is, and while Chrome is bringing it in soon, since it's been assigned for a while now, you can see is or not is nobody is really blocked here.

If MS will ship Custom Elements without is and they'll implement later on it's fine for me. Have I mentioned I've used it for years now without any issue whatsoever?

Chose what you need for your business. If you don't need is don't use it but don't come here saying nobody needs it because that's simply a lie and outside reality.

You said you knew about is, and probably Custom Elements, just recently with V1, many here have been using CE for years now so maybe we have reasons to ask other vendors to swallow its imperfections and move on bringing in its awesomeness.

Now I don't think me and you have much more to tell so, have a nice day/evening. Let's keep this thread open for discussions.

[oleersoy]

We are not blocked and we never were but this does waste the time of devs, product managers, maintainers. Collectively that's a lot of time. Recently Google decided to Sunset Chrome Apps for Windows, Linux, and MacOS citing a less than 1% usage statistic. This is going to go the same way.