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 27228 - Inconsistency in characters allowed in attribute names between setAttribute and HTML syntax specs
Summary: Inconsistency in characters allowed in attribute names between setAttribute a...
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-03 23:52 UTC by Igor Minar
Modified: 2017-04-26 16:50 UTC (History)
13 users (show)

See Also:

Attachments

Description Igor Minar 2014-11-03 23:52:23 UTC 
According to http://www.w3.org/TR/html5/syntax.html#attributes-0 and http://www.w3.org/TR/html5/syntax.html#attribute-name-state non-ascii characters like "[", "]", "(", ")" and "?" are valid characters for attribute names.

However, according to https://dom.spec.whatwg.org/#dom-element-setattribute setAttribute allows only attribute names that contain ascii characters.

This means that while <div [foo]="bar"> is properly parsed by all browsers that I tried (Chrome, FF, Safari, IE), trying to set attributes via DOM apis throws an exception in all of these browsers.

There is a workaround for this (http://jsperf.com/specialsetattribute) that comes with a performance hit.

It would be great to have the setAttribute spec match the html syntax spec, so that we don't need to be working around the more restrictive DOM spec and taking a perf hit.

The real-world usecase for this usage is DOM-based templating systems like those used by Angular and Polymer. Polymer already uses <my-component hidden?="{{exp}}"></> (note the "?" after hidden), and Angular is considering using <my-component [hidden]="exp"></> syntax for our next generation templating. The use of attribute name and "odd" characters is exactly what we need to build a templating language on top of HTML and DOM that will work well with Web Components.
Comment 1 Glenn Adams 2014-11-04 00:25:05 UTC 
(In reply to Igor Minar from comment #0)
> According to http://www.w3.org/TR/html5/syntax.html#attributes-0 and
> http://www.w3.org/TR/html5/syntax.html#attribute-name-state non-ascii
> characters like "[", "]", "(", ")" and "?" are valid characters for
> attribute names.

"[", "]", "(", ")" and "?" *ARE* ASCII characters; all Unicode code points from 0x00 through 0x7F are ASCII characters. [1]

[1] http://en.wikipedia.org/wiki/ASCII
[2] http://www.unicode.org/charts/PDF/U0000.pdf
Comment 2 Igor Minar 2014-11-04 00:35:39 UTC 
Glenn, you are right. That was an imprecision on my part. The character set for setAttribute is defined as http://www.w3.org/TR/xml/#NT-NameChar which is a doesn't match the character set defined in the html syntax spec.
Comment 3 Anne 2014-11-04 08:34:47 UTC 
This has the same issue as bug 24271. We would need browsers to risk web compatibility.

Dmitry, is Chrome willing to be a guinea pig?
Comment 4 Dimitri Glazkov 2014-11-04 21:36:34 UTC 
(In reply to Anne from comment #3)
> This has the same issue as bug 24271. We would need browsers to risk web
> compatibility.
> 
> Dmitry, is Chrome willing to be a guinea pig?

It might be good to bring this up on blink-dev and take the temperature. I wonder how we could pre-emptively measure the impact of this?
Comment 5 Anne 2014-11-04 21:47:23 UTC 
I don't know. I'm not particularly concerned by the mismatch myself. I'm happy for someone to take this on though.
Comment 6 Anne 2015-08-03 10:48:38 UTC 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/YyqxpIPU-0E/dXg0JBRVBwAJ

Leaving this open until that thread concluded something one way or another or enough time expired that indicates nobody is really interested in taking the lead here.
Comment 7 Joe Gregorio 2015-08-03 11:54:06 UTC 
For my own edification, won't that workaround stop working when browsers move to DOM 4 and Attr no longer inherits from Node and thus cloneNode() is no longer available?
Comment 8 Anne 2016-03-14 13:05:03 UTC 
Joe, yeah, though it seems unlikely we'll be able to cut the tie between Attr and Node. See https://github.com/whatwg/dom/issues/102 for details.

Closing this since nothing actionable came out of this and nobody seems keen on running experiments. Sorry Igor.
Comment 9 Domenic Denicola 2017-04-26 16:50:09 UTC 
This is getting a new attempt at https://github.com/whatwg/dom/pull/449, with Chrome helping measure things per https://bugs.chromium.org/p/chromium/issues/detail?id=648179.