[Custom]: Restrict custom elements to NCName (bugzilla: 20973) #177
Assignees
Labels
Comments
|
Also see the issue #239. We should resolve this in v1 since restricting the kind of characters allowed in an element name after the fact will be hard if not impossible. |
|
Although older, this is now a duplicate of that issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Title: [Custom]: Restrict custom elements to NCName (bugzilla: 20973)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c0
Anne wrote on 2013-02-12 11:04:57 +0000.
"match the Name production" Effectively HTML elements are restricted to NCName because XML, lets do the same for custom element names, even though allowing :-D and such is kinda fun.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c1
Dimitri Glazkov wrote on 2013-02-12 19:17:24 +0000.
https://dvcs.w3.org/hg/webcomponents/rev/248ae0e2880f
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c2
Dimitri Glazkov wrote on 2014-11-14 20:43:39 +0000.
Anne, it sounds like the NCName and Name productions are only loosely compatible. This leads to all kinds of weird contortions in https://code.google.com/p/chromium/issues/detail?id=325673.
The spirit of the spec is captured by Dominic in https://code.google.com/p/chromium/issues/detail?id=325673#c3, but I think we're failing to do that by switching to NCName.
Do you have any suggestions?
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c3
Anne wrote on 2014-11-15 11:59:05 +0000.
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...)
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c4
Dimitri Glazkov wrote on 2014-11-16 05:11:17 +0000.
(In reply to Anne from comment #3)
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?
comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c5
Anne wrote on 2014-11-16 08:46:48 +0000.
Yeah, it would just be non-conforming to do so. Aligning the various name creation algorithms seems like a huge hassle at this point, though if any implementer is interested in the churn I'd be open to it.
comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c6
Dimitri Glazkov wrote on 2014-11-16 16:30:11 +0000.
(In reply to Anne from comment #5)
Deepak seems to be digging into that. Deepak, are you interested in this problem as a whole or just as a first-blink-bug type of thing?
comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c7
Deepak Singla wrote on 2014-11-17 04:33:07 +0000.
(In reply to Dimitri Glazkov from comment #6)
Yeah, I would be like to see this issue through.
comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c8
Deepak Singla wrote on 2014-11-17 05:10:28 +0000.
How should we proceed with this? Are we going to align all the name creation algorithms? Or just improve in Custom Element's name creation?
comment: 9
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c9
Anne wrote on 2014-11-17 08:08:39 +0000.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=27228#c3 for a way forward. Investigating whether we can make the HTML parser and createElement()/createAttribute() consistent seems like a good first step.
comment: 10
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c10
Deepak Singla wrote on 2014-11-20 10:09:16 +0000.
HTML parser works according to the states. It allows/disallows characters on the basis of the states(Tag name state, End tag open state etc.). It does not take into consideration of validity of that name, and IMHO it should not. HTML parser only coverts them into tokens. Validity has to be checked later. So the HTML parser name validation should not be changed.
So the options remains to change the createElement()'s name production.
Latest edition of createElement()'s (http://www.w3.org/TR/dom/#dom-document-createelement) name production points to 5th edition XML 1.0 (http://www.w3.org/TR/xml/#NT-Name ).
Related to Custom Element: Latest editor's draft of custom element name (http://w3c.github.io/webcomponents/spec/custom/#dfn-custom-element) points to 4th edition NCName : http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName
Shouldn't we change it to 5th edition NCName: http://www.w3.org/TR/xml-names/#NT-NCName ?
comment: 11
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c11
Anne wrote on 2014-11-20 11:17:59 +0000.
Deepak, XML does not define validity for HTML. E.g. "test" is invalid for HTML, yet is allowed by createElement(), createElementNS(), and the HTML parser.
"test:test" is non-well-formed in XML (when namespaces are enabled, as they are), invalid in HTML, yet is allowed by the HTML parser, createElement(), but not createElementNS().
Comment 0 is mostly about restricting the validity to names that can be used by both HTML and XML, but does not put actual constraints in place for the HTML parser, createElement(), and createElementNS().
comment: 12
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c12
Deepak Singla wrote on 2014-11-20 12:16:28 +0000.
(In reply to Anne from comment #11)
So, we have to define a new rule set which only allows predefined tags/attributes of html?
comment: 13
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c13
Anne wrote on 2014-11-20 12:46:35 +0000.
The only somewhat logical thing to do here would be investigating whether we can let createElement()/createElementNS() create the same set of elements that the HTML parser can create.
comment: 14
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c14
Deepak Singla wrote on 2014-11-24 11:10:17 +0000.
In here https://www.w3.org/Bugs/Public/show_bug.cgi?id=24271#c6 you said to experiment with the browser. Can you explain a bit more on that?
As I am relatively inexperienced, can you provide me pointers on how should I investigate about createElement and HTML parser? I have tried characters which gives error in createElement() but passes in HTML parser. But that doesn't provide any useful information that how allowing a particular character breaks the web.
comment: 15
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20973#c15
Anne wrote on 2014-11-24 17:00:25 +0000.
(In reply to Deepak Singla from comment #14)
You would patch the browser to a loser check for createElement() and see if that breaks pages. Before doing that you likely have to investigate how many pages make createElement() calls with the code points you plan on allowing in addition to those that are already allowed to find out if anyone depends on the exception thrown. Most browsers have some kind of instrumentation available for this.
The text was updated successfully, but these errors were encountered: