- From: <bugzilla@jessica.w3.org>
- Date: Sun, 16 Nov 2014 05:11:17 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973 Dimitri Glazkov <dglazkov@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |deepak.sa@samsung.com --- Comment #4 from Dimitri Glazkov <dglazkov@chromium.org> --- (In reply to Anne from comment #3) > This is a difference between authoring conformance and what is actually > allowed per createElement, and the HTML parser et al. > > There's no silver bullet here as I explained in another thread, unless we > actually want to change createElement() and createElementNS() in > implementations. > > (I'm not sure what Document:isValidName() is. But if it's what > createElement() requires, that is not matched by the HTML parser already...) Yup. Document::isValidName is the check from https://dom.spec.whatwg.org/#dom-document-createelement et al. I think I am starting to understand this. The http://w3c.github.io/webcomponents/spec/custom/#dfn-custom-element-type check in http://w3c.github.io/webcomponents/spec/custom/#dfn-definition-construction-algorithm is not a subset of the check in https://dom.spec.whatwg.org/#dom-document-createelement. And that is okay, because XML. IOW, you can indeed register an element with a name that createElement will not be able to digest. And that is okay. Right? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 16 November 2014 05:11:19 UTC