20973 2013-02-12 11:04:57 +0000 [Custom]: Restrict custom elements to NCName 2015-07-06 08:17:40 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED P2 normal --- 14968 1 annevk dglazkov deepak.sa dominicc public-webapps-bugzilla oldest_to_newest 82980 0 annevk 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. 83021 1 dglazkov 2013-02-12 19:17:24 +0000 https://dvcs.w3.org/hg/webcomponents/rev/248ae0e2880f 114948 2 dglazkov 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? 114966 3 annevk 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...) 114974 4 dglazkov 2014-11-16 05:11:17 +0000 (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? 114975 5 annevk 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. 114977 6 dglazkov 2014-11-16 16:30:11 +0000 (In reply to Anne from comment #5) > 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. 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? 114981 7 deepak.sa 2014-11-17 04:33:07 +0000 (In reply to Dimitri Glazkov from comment #6) > (In reply to Anne from comment #5) > > 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. > > 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? Yeah, I would be like to see this issue through. 114982 8 deepak.sa 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? 114986 9 annevk 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. 115197 10 deepak.sa 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 ? 115204 11 annevk 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(). 115215 12 deepak.sa 2014-11-20 12:16:28 +0000 (In reply to Anne from comment #11) > 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(). So, we have to define a new rule set which only allows predefined tags/attributes of html? 115217 13 annevk 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. 115376 14 deepak.sa 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. 115398 15 annevk 2014-11-24 17:00:25 +0000 (In reply to Deepak Singla from comment #14) > 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? 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. 121756 16 hayato 2015-07-06 08:17:40 +0000 Moved to https://github.com/w3c/webcomponents/issues/177