Currently, is="" is spec'd to define ways in which a Custom Element can extend from a native element but without having to write the Custom Element's name inside the DOM because it would otherwise break ancient parsing rules and therefore cause unexpected breaking behavior which leads to confusion. See issue #509 detailing the problems with the currently-spec'd behavior.
For example, one of the great uses for is="" is that it solves problems with tables and other elements, where using a custom element the normal way will not work:
<table> <my-tr></my-tr> </table>
because in that example the engine specifically expects a <tr> element, and does not look at the composed tree as a source of truth (like it should).
The current spec allows a solution using the is="" attribute,
<table> <tr is="my-tr"></tr> </table>
so that the table can be parsed and rendered correctly, but this currently requires awkward and confusing inheritance patterns as mentioned in #509.
Here's a very simple proposal that would repurpose is="" (or an attribute with a new name) for allowing developers to attach any number of behaviors ("components") to an Element (originally described in #509 (comment)).
The main idea of that original comment is that we can add any number of behaviors to an element while not being required to extend from the element's original interface/class.
F.e.:
components.define('foo', class {
constructor(el) {
// do something with el
}
disconnectedCallback() {}
// Or similar life cycle methods
})
components.define('lorem', class {
constructor(el) {
// do something with el
}
connectedCallback() {}
attributeChangedCallback() {}
// Or similar life cycle methods
})
<table> <tr is="foo lorem">...</tr> </table>
Note that these "components" do not directly or indirectly extend (and are required not to extend from) Element. (This limitation may need to be further fine-tuned; perhaps they are not allowed to extend from Node? This is just an example.) It wouldn't make sense, for example, for the <tr> to be both HTMLTableRowElement and HTMLButtonElement... or would it? This can be discussed later.
In the example, the foo and lorem components are simple classes that don't inherit from any other class, and using lifecycle hooks similarly to Custom Elements we can still do interesting things with the target element.
We can also attach more than one component to a given element. And components don't need to be exclusively limited to a single type of element like with the current is="" attribute!
As an idea to prevent possible confusion with the existing natively-implemented is="" in some browsers, this attribute might be named something else, f.e. maybe components="", which is nice, but more typing. Maybe comps for short? Etc. is="" is still nicest.
<table> <tr components="foo lorem">...</tr> </table>
is="" is still the nicest because it is short and simple.
IMHO, this new is="" attribute functionality is much more desirable than the currently confusing is="" attribute, and follows the proven approach that well-known libraries (old or new) take today (jQuery, Vue, etc).
tomalec, OvermindDL1, oleersoy, morewry, LasaleFamine and 25 moreelpupi, jesusabarca and MoaathAlattas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4