This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20973 - [Custom]: Restrict custom elements to NCName
Summary: [Custom]: Restrict custom elements to NCName
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14968
  Show dependency treegraph
 
Reported: 2013-02-12 11:04 UTC by Anne
Modified: 2015-07-06 08:17 UTC (History)
2 users (show)

See Also:


Attachments

Description Anne 2013-02-12 11:04:57 UTC
"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 Dimitri Glazkov 2013-02-12 19:17:24 UTC
https://dvcs.w3.org/hg/webcomponents/rev/248ae0e2880f
Comment 2 Dimitri Glazkov 2014-11-14 20:43:39 UTC
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 Anne 2014-11-15 11:59:05 UTC
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 Dimitri Glazkov 2014-11-16 05:11:17 UTC
(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 Anne 2014-11-16 08:46:48 UTC
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 Dimitri Glazkov 2014-11-16 16:30:11 UTC
(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 Deepak Singla 2014-11-17 04:33:07 UTC
(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 Deepak Singla 2014-11-17 05:10:28 UTC
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 Anne 2014-11-17 08:08:39 UTC
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 Deepak Singla 2014-11-20 10:09:16 UTC
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 Anne 2014-11-20 11:17:59 UTC
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 Deepak Singla 2014-11-20 12:16:28 UTC
(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 Anne 2014-11-20 12:46:35 UTC
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 Deepak Singla 2014-11-24 11:10:17 UTC
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 Anne 2014-11-24 17:00:25 UTC
(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.
Comment 16 Hayato Ito 2015-07-06 08:17:40 UTC
Moved to https://github.com/w3c/webcomponents/issues/177