In some cases SVG stores attribute value as nsISVGValue objects. Need to check whether nsISVGValue stores the original value or whether it is needed that those attributes keep their original value.

bug 302011 and bug 307283 are probably related. bug 302011 comment 2 has some useful quotes although jwatt changes his mind later on in that bug.

Yeah, we store parsed versions of the attributes for efficiency reasons, and given the number of very large SVG files out there, I think it's undesirable to take the memory hit of keeping around the original strings (along with white space formatting etc.) as well. I think it's rarely useful, and we can fix up "scale(2)" turning into "scale(2, 2)" etc. in other ways. CC'ing Chris and Doug for their input. I believe SVG Mobile 1.2 decided against requiring implementations to maintain the original values.

And FWIW the HTML case problems covered by bug 433533 aren't relevant in SVG since the attributes are case sensitive anyway.

JWatt, that's correct. Having to keep around the original strings and whatever combination of whitespace etc they used is unnecessary overhead, which unfortunately DOM 2 requires. DOM 3 allows an optional normalization step. SVGT 1.2 states that an SVG implementation will perform that step, so the semantic values are preserved but the exact string is not. This is specifically to enable implementations to store attribute values in a compact way. This does of course have an impact on CSS selectors, which allow matching on the string value of attributes; I would have preferred to see attribute selectors matching on a typed value rather than a string, which would be more robust.

Per comment 2 we'd rather use less memory.

This sounds like a direct violation of invariants of the DOM. I don't think this can be WONTFIXED without coordination on www-dom@w3.org.

We're not going to keep the parsed value and the original string around as that would mean we'd be using twice the memory in the DOM. We've already had a response from w3c in comment 4.

Except Chris is wrong and not an authoritative source on the DOM. As editor of the DOM specification, I think I am.

The focus on all UAs is to use less memory and improve performance. This runs counter to that so I really only see disadvantages here. Is there some big advantage I've missed here that outweighs all the downsides?

(In reply to Robert Longson from comment #7) > We're not going to keep the parsed value and the original string around as > that would mean we'd be using twice the memory in the DOM. We've already had > a response from w3c in comment 4. About what DOM3 requires. We don't implement DOM3.

What you're missing is that this violates the DOM. And that now x == getAttribute(y) is no longer true for setAttribute(y, x) given any strings x and y. There are many areas where we could reduce footprint and improve performance if we decided to violate specification invariants. However, if we decide to do so, we need to have a discussion about that with other vendors first.