- 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