Re: Case-Sensitivity & SVG-in-HTML5

Hi Mike,

Thanks for following up. Yes, it seems this is the fix that should be implemented in WebKit. There are many contributors to WebKit but indeed, nobody has taken this bug on so far (still unassigned). We'll evaluate if this is something we can address at Adobe (we need to scope and prioritize the work).

Kind regards,

From: Mike Bostock <<>>
Date: Tue, 13 Mar 2012 04:42:50 -0700
To: Adobe Systems <<>>
Cc: Dirk Schulze <<>>, "<>" <<>>
Subject: Re: Case-Sensitivity & SVG-in-HTML5

Bumping this to see if there's any update regarding selectors for
SVG's camelCase elements. The bug I filed against WebKit has
languished, I think in part because the desired fix was unclear?

If I understand correctly, the desired fix is that
querySelectorAll("clipPath") (and querySelector and
getElementsByTagName) should match <svg:clipPath> elements, but that
querySelectorAll("clippath") should not, even if the SVG is embedded
in an HTML document.

If someone of Great Influence™ could comment on the above bug and help
instigate forward progress, that would be much appreciated!


On Mon, Oct 31, 2011 at 6:21 PM, Vincent Hardy <<>> wrote:

@mike: thanks for having sent the description.

Looking at the test case you have on different browsers, I see that IE 10
returns 'textpath' and 'textPath' (so it treats the inline SVG as HTML
elements) and FireFox seems to be doing the right thing in the version I
look at (version 6.0 only returns a match on 'textPath' but not on

It seems to me that there are two possible avenues:

a. get the browser implementations to implement the specs. as they are
(Dirk's references). That would mean getting a WebKit fix and reporting the
issue with IE (the IE issue is less of a problem because you can get the
elements, where the WebKit bug is really limiting).

b. if an other behavior is desired, it should be brought up with the DOM
Core group, as Dirk suggests.


From: Dirk Schulze <<>>
Date: Mon, 31 Oct 2011 09:50:04 -0700
To: Mike Bostock <<>>
Cc: "<>" <<>>
Subject: Re: Case-Sensitivity & SVG-in-HTML5

Like described on the webkit bug report, the current DOM specification just
expects HTML elements to be case insensitive [1]. SVG elements are not in
the HTML namespace and therefor should be case sensitive:

Element nodes in the HTML namespace whose local name is localName converted
to ASCII lowercase.
Element nodes, not in the HTML namespace, whose local name is localName.

This is an implementation problem of WebKit and Opera (at least the last
time I tested Opera Next with HTML5 parser) that this doesn't work for camel
case local names. Firefox on the other side did not implement it correctly
either, since elements can be lowercase and uppercase there. This problem
does only occur on HTML5 and not on XHTML, since XHTML is case sensitive as
well and the behavior is clear. If you want elements of all namespaces to be
case insensitive for HTML documents, you should send the request to the DOM
WG (and maybe whatwg mailing list), since it does not only affect SVG.



Am 28.10.2011 um 19:50 schrieb Mike Bostock:

Vincent asked me to send a summary of the case-sensitivity problem
with SVG-in-HTML; I brought this up at SVG Open last week. This bug
occurs when attempting to select camelCase elements via JavaScript,
either using the Selectors API or getElementsByTagName.

The problem is trivial to reproduce: if you have an element with a
camelCase local name, such as an SVGTextPathElement, it is impossible
to select that element by tag name using querySelector,
querySelectorAll, or getElementsByTagName.

Test case here:

This bug affects other case-sensitive namespaces as well, such as
MathML. You can still select these elements using an alternative
means, such as by class or wildcard.

The WebKit bug is here:

This bug does not occur on Firefox; you can select using a
case-matching selector, such as "textPath".

Personally, I would prefer for the selectors to be case-insensitive if
the containing document is case-insensitive (HTML5 doctype, in this
case). Or even everything to be case-insensitive in this case, which
differs from the proposal. [1] But at the least it should be possible
to select if your selector is case-matching.



Received on Tuesday, 13 March 2012 15:00:16 UTC