[webcomponents] [Custom]: Restrict custom elements to NCName (bugzilla: 20973) (#177)

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)
> 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?

----

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)
> 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?

----

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)
> (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.

----

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)

> 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?

----

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)
> 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.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/177