SVG element names should not mix camelCase and lowercase notations

[jarek-foksa]

I don't understand why elements introduced by SVG 2 such as <solidcolor> and <meshrow> are defined with lowercase names while the remaining elements such as <linearGradient> and <radialGradient> keep using camelCase names.

For consistency and backward compatibility I would define all elements using camelCase notation, with a notice that lowercase names are valid when HTML serialization is used.

element.nodeName, element.tagName and element.localName are already behaving inconsistently with HTML and SVG elements and changing their behaviour would break content. Therefore, I would introduce a new element.name DOM property that would show camelCase names for elements parsed with XML parser and lowercase names for elements parsed with HTML parser (including SVG elements inside HTML).

[AmeliaBR]

The new names were switched to all lowercase based on requests from implementers. The problem comes with the HTML parser, which needs to keep a special whitelist of which elements should not be converted to lowercase as it parses, or as CSS selectors match, or the DOM query selector methods, and so on. To avoid increasing overhead, we were asked to avoid any new mixed-case element names or attributes. The name changes were agreed to in February 2015.

Of course, as you note, changing existing names would break content, so the existing mixed case names will stay.

I'd have to look into the different rules for the *name DOM properties. I'm pretty sure at least one of them should already return the canonical name for all elements, but I'm not certain.

[jarek-foksa]

@AmeliaBR Thanks for providing some more insight into this issue.

There are already over 30 elements with camelCase names in SVG 1.1, would adding just 4 more (<solidColor>, <hatchPath>, <meshRow>, <meshPatch>) really add significant overhead to the parser?

The inconsistency here is striking. For new elements, I guess the best compromise between consistency and performance would be to use single-word names and resort to multi-word camelCase names only when absolutely necesarry.

After some more research, element.localName seems to work consistently for both HTML and SVG, so please ignore that part of my previous post.

[tabatkins]

It's not that any single addition is a significant overhead. It's that changing the parser is expensive, in many senses of the word, whether the change is tiny or large. We try to limit the changes that we make to those that are necessary, and preferably one-shot - SVG element names are neither of those, as you can just spell the names differently, and SVG is expected to continue to grow and evolve over time.

(And it does turn out that these names are expensive; the list needs to get invoked by a lot of hot code in various places of several bits of tech, and as it grows it gets worse.)

[prlbr]

Would it be feasible to change all element and attribute names to lowercase in SVG2, but allow the camelCase version as synonym for those ones that were previously defined to be camelCase? That would save backwards compatibility and would make it easier for authors in the future who don't have to remember when to use camelCase and when to use lowercase – they could always use the latter.

Admittedly, I hardly know anything about SVG/HTML parsers, but if I understood correctly that overhead is caused because browsers need to maintain a list of when not to convert element names to lowercase, then wouldn't changing all element/attribute names to lowercase remove that overhead? Browsers could convert them, because the lowercase version would then be valid and work, wouldn't it?

[AmeliaBR]

@prlbr

The HTML parser automatically corrects all case errors. So you can use whichever case you want, and it will convert it to the canonical version as it parses. However, DOM methods for scripting are all case sensitive, as is the XML parser used by stand-alone SVG files. So we do need to define canonical casing, and we can't change existing casing without breaking backwards compatibility for scripts.

[nikosandronikos]

Closing this issue since this has largely been settled and further input will come via the request for comments on the meshgradient definition.