302011 - getAttribute("transform") does not return the original string

Status: RESOLVED DUPLICATE of bug 477996

(Core :: SVG, defect)

Description

[Holger Will]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050713 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050713 Firefox/1.0+

suppose you have this element:
<rect transfrom="scale(2)" ... />
then doing 

element.getAttribute("transform") 

will returns "scale(2, 2)"

Reproducible: Always

Steps to Reproduce:
1.element: <rect transfrom="scale(2)" ... />
2.result = element.getAttribute("transform") 
3.alert(result)

Actual Results:  
alert shows "scale(2, 2)"


Expected Results:  
getAttribute should return the DOMString, in this case "scale(2)"

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is impossible in general, since parts of the transform can be manipulated via the DOM and the attribute needs to match those...

In other words, this is exactly the issue that inline style has.

Comment 2

[Jonathan Watt [:jwatt]]

I'd go with Hixie and argue that we could/should store the exact attribute string as specified in the markup until some DOM manipulation changes it.

Note (to self as much as to anyone else): From an email sent by Thomas Deweese to svg-developers:

From the section entitled Interface Attr:

    The attribute's effective value is determined as follows:
    if this attribute has been explicitly assigned any value,
    that value is the attribute's effective value;

Later in same section:

    Because the DOM Core is not aware of attribute types, it
    treats all attribute values as simple strings, even if the
    DTD or schema declares them as having tokenized types.

In the section on Element for 'setAttribute':

    setAttribute
        Adds a new attribute. If an attribute with that name is
        already present in the element, its value is changed to
        be that of the value parameter. This value is a simple
        string; it is not parsed as it is being set. So any markup
        (such as syntax to be recognized as an entity reference)
        is treated as literal text, and needs to be appropriately
        escaped by the implementation when it is written out.

In short an Attribute value must be treated as a "simple string" in a compliant DOM 2 implementation.

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: testcase

Comment 4

[Jonathan Watt [:jwatt]]

So given the pressure we have on memory use, I no longer believe in holding around the original attribute string and the condensed (parsed) version.

What we could do to help matters is quite easily hold the data on the transform telling us if the 'scale' had one or two arguments. nsSVGTransform::GetValueString even seems to have a little code for determining this (it checks for a value of zero on sy - which could have been specified in the markup, so that doesn't seem like a great way to do it anyway), but at some point it seems to have been broken, perhaps by the refactoring to introduce nsSVGTransformListParser.cpp. We could alternatively set one of the other (unused) components of the matrix to a magic value, or else we could have special SVG_TRANSFORM_SCALE_1 and SVG_TRANSFORM_SCALE_2 values we hide from script. Or something else.

We should do the same for the other transform types of course.

Also note we probably want to completely refactor the transform code to get rid of the SVGTransform and SVGMatrix stuff and make them DOM tearoffs.