Re: [WICG/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

amn left a comment (WICG/webcomponents#509)

Isn't support for `is` vs. absense, a case of false dichotomy? I mean, I could annotate a `template` element in an alternative way, e.g. using the `data-is` below just to illustrate the point:

```html
<template data-is="fancy-template">
    Still doesn't render during parsing, so we're good.
</template>
```

No support for `is` needed and spares the collective for feature-begging `$VENDOR` to implement `is` etc, allowing your favourite rockstar developer crew to ship Unicorn Framework 1.0 that effectively does the equivalent of what I've understood `is` helps accomplish while the following still applies:

1. Since a well-defined HTML element is used as-is, with `template` being the case above, the semantics and parsing etc, all function as desired (by advocates of support for `is`)

2. Because the element is annotated in some manner expected by the [third-party] Unicorn Framework 1.0 (which happens to absolve `$VENDOR` like Apple from implementation responsibility altogether, what with these things taking years anyway), the framework can be expected to boot-strap all functionality that `is` allows, with _client-side scripting_, just as with `is` -- so parity there, in terms of browser support required otherwise; I mean install a `MutationObserver` and add behaviour to `template` elements annotated with `data-is` accordingly

A third-party support will allow far leaner time-to-market times at the expense of standardisation of interfaces between frameworks that want to give you the same feature (`data-is` vs `data-extends` etc), and spare Apple, Google and Microsoft from implementing things (Microsoft famously abandoned their own browser engine because they literally couldn't afford one -- apparently their capacity to implement things isn't nearly as unlimited as some would assume). Post-release development would also likely be accelerated vs. in-browser code -- in the browser it's a high risk development environment because it potentially affects _every_ page, unlike Unicorn Framework Alpha that has X pages using it vs. Y pages using Unicorn Framework Beta from a different rockstar developer crew and so on.

Anyway, is my false dichotomy argument bogus? In short, I argue that while `is` _may_ be a nice-to-have, which makes its implementation attractive specifically in-browser, it's not the case that without it equivalent functionality is impossible (merely requires third-party support or roll-out-your-own).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/509#issuecomment-5645501087
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/509/5645501087@github.com>