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

My point is that HTML and JS are not the same language, so HTML doesn't owe any conceptual tip of the hat to JS. In that light, is quite natural for HTML authors.

Maybe but it brings up a question. Why not just do <my-button>? It's shorter. It's more DRY.

How is it more DRY?  And are you arguing that character count matters here?

It's an element. HTML developers know what elements are. We don't have to explain what the is is for and it offers a cleaner and simpler development path than the indirection brought up by is.

Yes it’s an element, in a namespace.  It will stay in that namespace forever.  That’s a choice you make when you begin development: is this meant as an iteration of the platform, or does it belong to my organization? <button> is in the HTML namespace, where it too will stay. It belongs to the Web.  If you are designing at that scale, you want to start with <button> and iterate on it, chances are.

The other question becomes when do we do <my-button> and when do we do <button is="my-button">?

See above.

I get that with is we still get a button, but that button has to do something. With is does something it interacts with other things. If we are using is we are introducing a fork in the development approach.

Custom Elements are intended to a) take the pressure of browser makers to decide how to evolve the Web through prollyfills  b) allow component development for organizations.  At least that’s how I understand them (see Extensible Web Manifesto etc.)

b) is covered quite nicely by <my-button>.

a) is covered very well by <button is=”my-button”>

When I think about “no JavaScript”, there are really two cases that matter, I think:

First, JS fails due to network conditions, or bad programming or whatever. <my-button> will wrap what it wraps I guess.  But <button is=my-button> will still be a button, subject to CSS.

The second, and more important situation IMHO, is in the future.  Let’s say <button is=”my-button”> has become wildly successful and is implemented on Alexa’s top 10000 Websites.  Browser devs decide to support whatever extension to <button> that my-button type extension provides *natively*. They can simply see is=”my-button” and upgrade that element right on the spot.  For browsers which don’t yet support it, the my-button JavaScript definition takes over – polyfills it.  If some browsers don’t support is=my-button this future can’t exist, we’re stuck with <my-button>s everywhere on the web in a JavaScript-only future.

If the API that comes with <my-button> has not loaded then the development approach needed for a satisfying customer experience is completely different. Now we need two people to screw in the lightbulb. We have to write more design documentation. We have to write more tests. Etc. Etc. Etc.

Not advocating two implementations.  Pick one and go with it.


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