-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interfaces for web components #725
Comments
The problem with "true subclassing" of builtins is that browsers are architected around local name checks, not class (brand) checks. So if you have |
@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. |
@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. |
As an alterantive to |
Closing this per my comments. Let me know if there's something I missed. |
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:
custom-header
element which is accepted by, for example crawlers as a header element.The text was updated successfully, but these errors were encountered: