Interfaces for web components

[TitanNano]

We read a lot that Safari is not going to implement the is="" attribute and therefore we are not going to be able to inherit from built-in elements.
None the less, we are desperately in need of being able to communicate to HTML parsers that our elements behaves like one of the built in elements, for example a form control.

Has it ever been considered to introduce an like="input" attribute?
This would tell the HTML parser that the custom element is supposed to be treated like an element that implements the input-element-interface.
It's then up to the custom element author to implement all the features of the interface and in return browsers would treat it as an input element.

Our use-cases for this currently are:

1. Being able to create an custom-header element which is accepted by, for example crawlers as a header element.
2. Create form controls which are picked up by the built-in form element and are treated just like other form controls.

[annevk]

The problem with "true subclassing" of builtins is that browsers are architected around local name checks, not class (brand) checks. So if you have custom-input, most of the code in browsers (this includes default stylesheets, which don't even have a way to match based on class) will not see it as input, which defeats the entire point. That's why the is="" hack is there, as it preserves the local name. But that's also why it's a hack, to work around a faulty architecture.

[TitanNano]

@annevk So if I would do something like this, browsers would treat my element as an input?

class TestElement extends HTMLElement {
    get localName() { return 'input'; }

    constructor() {
        super();
    }
}

Any HTML analyzer would still complain though, because they don't accept my element.

I don't know if it's even desired to have browser stylesheets pick up custom elements since they mostly come with their own stylesheet and there is barley any website which uses the built in styles for any of their elements.

[annevk]

@TitanNano no, browsers don't consult JavaScript when doing selector matching or any of these checks really (that would also prevent doing some of that work in parallel). There's a private slot that's being consulted.

[trusktr]

As an alterantive to is="", something like Element Behaviors could do the trick.

[annevk]

Closing this per my comments. Let me know if there's something I missed.