I actually think this could be a bug in Chrome's implementation of Custom Elements, but I thought I'd open a PR to at least open a discussion on it. If it is indeed a Chrome issue, then of course I don't expect this to be merged — however I couldn't find a related Chrome bug.
The issue:
Whilst in most cases HTML is case insensitive, using Custom Elements v1'scustomElements.define it seems that custom elements are case-sensitive when using document.createElement as shown in the following Fiddle (note: requires Chrome Canary, as customElements.define won't work in Chrome yet).
By adding toLowerCase in virtual-dom's vnode.tagName the connectedCallback function is invoked as expected. Interestingly, in the Fiddle it doesn't matter how the HTML is written (rightfully so), as both <example-node /> and <EXAMPLE-NODE /> are equals, and thus work perfectly.
Coverage remained the same at 97.531% when pulling 1326f2f1aef241233a0b47f946b047aa1ad87457 on Wildhoney:webcomponents-v1-case-sensitivity into 947ecf92b67d25bb693a0f625fa8e90c099887d5 on Matt-Esch:master.
I actually think this could be a bug in Chrome's implementation of Custom Elements, but I thought I'd open a PR to at least open a discussion on it. If it is indeed a Chrome issue, then of course I don't expect this to be merged — however I couldn't find a related Chrome bug.
The issue:
Whilst in most cases HTML is case insensitive, using Custom Elements v1's
customElements.define
it seems that custom elements are case-sensitive when usingdocument.createElement
as shown in the following Fiddle (note: requires Chrome Canary, ascustomElements.define
won't work in Chrome yet).By adding
toLowerCase
invirtual-dom
'svnode.tagName
theconnectedCallback
function is invoked as expected. Interestingly, in the Fiddle it doesn't matter how the HTML is written (rightfully so), as both<example-node />
and<EXAMPLE-NODE />
are equals, and thus work perfectly.Thoughts?