https://dvcs.w3.org/hg/webcomponents/rev/248ae0e2880f

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?

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

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

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.

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

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

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?

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.

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 ?

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

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

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.

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.

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

Moved to https://github.com/w3c/webcomponents/issues/177