Re: [w3c/webcomponents] Why must the is="" attribute exist? (#509)

@domenic That quote that you referred to makes me think exactly the same thing as I just wrote:

> The necessary info for the HTML engine to upgrade that element properly is right there, in { extends: "button" }. I do believe there's some way to make this work (as there always is with software, because we make it, it is ours, we make software do what we want, and this is absolutely true without me having to read a single line of browser source code to know it), and that is="" is not required and can be completely removed from the spec because it seems like a hack to some limitation that can be solved somehow else (I don't know what that "somehow" is specifically, but I do know that the "somehow" exists because there's always some way to modify software to make it behave how we want within the limitations of current hardware where current hardware is not imposing any limitation on this feature).

You're pointing to something that exists in a spec, but I'm saying it doesn't have to be that way, specs can be modified. There is a solution (I don't know what that solution is specifically yet, but I know that the hardware on any computer that runs a browser nowadays isn't a limitation, and the only limitation is in the software we write, which can be modified). I simply can't understand why an HTML engine must need `<button is="super-button">` (besides the fact that current algorithms require that) when clearly there's a JavaScript way to make the HTML engine understand that `<super-button>` means the same as `<button is="super-button">` due to the fact we're defining that in the call to `customElement.define`.

I wish I had the time and resources to read the Chromium source in order to point to an actual solution, but in the meantime, I'm 100% sure a backwards-compatible solution exists.

---
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-222792785

Received on Tuesday, 31 May 2016 19:23:23 UTC