[Webkit-unassigned] [Bug 17779] New: SVG 1.1 Errata demands "SVG JavaScript Liveness" support

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=17779

           Summary: SVG 1.1 Errata demands "SVG JavaScript Liveness" support
           Product: WebKit
           Version: 525+ (Nightly build)
          Platform: Macintosh
               URL: http://www.w3.org/2003/01/REC-SVG11-20030114-
                    errata#mention-live-values
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: SVG
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: zimmermann at kde.org
                CC: eric at webkit.org, oliver at apple.com


SVG Errata states: "All SVG DOM objects that directly correspond to an
attribute, e.g. the SVGAnimatedLength 'ry' in an SVGRectElement, are live. This
means that any changes made to the attribute are immediately reflected in the
corresponding SVG DOM object." (see linked URL)

This makes sense, and way need to find a proper way to fix this bug.
HTML handles these cases in an easy & fast approach. HTML properties who equal
to HTML attributes that get exposed to JS always operate (or return) simple POD
types like String, long etc.

So HTML*Element classes don't actually store String/long etc values in the
implementation, but forward calls ie. to setAlign(const String& align) to it's
corresponding HTML DOM methods (setAttribute(HTMLNames::alignAttr. ...))

Accessing HTML*Element's properties works by forwarding to getAttribute().

In contrary SVG*classes containing animated SVG properties do store these types
(mostly non-POD-Types, like SVGLength, SVGTransform, etc.) as member variables.
This creates the problem that the string result of
getAttribute(someSVGAttribute) is not equal to the current values exposed to
SVG DOM (someElement.someSVGAttribute.baseVal....)

As you can see the fast HTML approach only works if you operate on POD types.
For SVG a more sophisticated solution is needed. Proposing following concept:

Add a new method to the SVG ANIMATED_PROPERTY_DECLARATIONS macros: "virtual
void synchronize##UpperProperty();" and maintain a boolean state wheter the
attribute has been changed via SVG DOM.

Add a new function "virtual AtomicString svgAnimatedPropertyAsString(const
QualifiedName&) const " to SVGElement, that has to be implemented by all
SVG*Element classes which define animated properties.

The idea is that everytime JS getAttribute() calls are invoked for SVGElements,
each SVG*Element will ask it's animated properties to synchronize their
"Attribute*" string value with the internal representation as SVG DOM Object.

For example, SVGRectElement::synchronizeX(), will call
SVGRectElement::svgAnimatedPropertyAsString(SVGNames::xAttr) to convert the
internal "SVGAnimatedLength* m_x" object to a "String", and will update it in
the element's NamedAttrMap. The call to getAttribute("x") will always be in
sync with the result of someRect.x.baseVal.value.

Of course this updating procedure in the NamedAttrMap, only needs to be done in
case the internal SVG DOM was modified, this is tracked by a boolean variable
in every SVG*Animated*Element class. In case it's not modified,
synchronize##UpperProperty() won't do anything.

Calls to setAttribute() already modify the corresponding SVG DOM in trunk, as
setAttribute("x") (to stay with the example above) call
SVGRectElement::parseMappedAttribute, which in turn calls setXBaseValue() which
in fact updates the SVG DOM. It's just the SVG DOM -> XML DOM synchronization
that hasn't been implemented yet.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.