"Mapped attributes"

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

"Mapped attributes"

Boris Zbarsky
I was talking with jwatt today about the mapped attributes stuff in SVG
(mMappedAttributes, not what the rest of Gecko calls "mapped attributes").  As I
understand it, we have the following situation:

1)  Associated to every SVG node there are some objects.
2)  These objects have properties.
3)  Changes to these properties affect the rendering of the SVG and what
     GetAttr() returns.
4)  SetAttr should affect the values of the properties (and the rendering).

I was wondering what sort of actions are typically taken when the object
properties change.  Do these actions depend on which exact property of which
exact object changed, or on which underlying attribute changed?

For comparison, this setup sounds a lot like what happens with HTML inline
style.  What we do there is that changes to the style object just notify that
the style attribute changed.  This triggers a style reresolve, which picks up
the new style.  Which exact CSS properties in the inline style changed is not
relevant to this process, since in the end we need to do a style reresolve no
matter what.

Could a setup like this work for SVG?  Or would it be too expensive?

-Boris
_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

Jonathan Watt-2
Hi Boris,

Boris Zbarsky wrote:
> I was talking with jwatt today about the mapped attributes stuff in SVG
> (mMappedAttributes, not what the rest of Gecko calls "mapped
> attributes").  As I understand it, we have the following situation:
>
> 1)  Associated to every SVG node there are some objects.
> 2)  These objects have properties.
> 3)  Changes to these properties affect the rendering of the SVG and what
>     GetAttr() returns.
> 4)  SetAttr should affect the values of the properties (and the rendering).

Another description:

1) Many SVG element attributes have an associated DOM object tree that is
    an alternative representation of the attribute.
2) Changes to the properties of the objects in this DOM object trees will
    result in a change in the value of the corresponding attribute
    (what GetAttr returns), and visa versa (i.e. SetAttr will change the
    value of the properties in the associated DOM object tree).
3) Naturally either way of making the change will have the same effect -
    usually a change in the rendering (depending on what attribute is
    changed).

If that isn't clear, consider the following element:

   <rect ... transform="translate(10,0) scale(1,2)" />

the following script could be applied to it.

   // get some values
   rect.getAttribute('transform'); // == "translate(10,0) scale(1,2)"
   rect.transform.baseVal.getItem(0).matrix.e; // == 10
   rect.transform.baseVal.getItem(1).matrix.d; // == 2

   // set some values
   rect.transform.baseVal.getItem(0).matrix.f = 10;
   rect.transform.baseVal.getItem(1).matrix.a = 2;

   // get the new *changed* attribute value
   rect.getAttribute('transform'); // == "translate(10,10) scale(2,2)"

> I was wondering what sort of actions are typically taken when the object
> properties change.  Do these actions depend on which exact property of
> which exact object changed, or on which underlying attribute changed?

I think the latter. I'm not aware of any cases where actions depend on the exact
property of an object. I think we only have to care that the "underlying" DOM
object tree corresponding to the attribute changed in some way. Not which
property it was. I could be wrong, but I doubt it.

To give you a feel for what SVG attributes map to DOM properties, here's a list
of the attributes we currently map.

-----------------------------------------
<circle>
   cx, cy, r
<ellipse>
   cx, cy, rx, ry
<foreignObject>
   x, y, width, height
<elements implementing SVGGraphicElement>
   transform
<line>
   x1, y1, x2, y2
<path>
   d
<polygon>
   points
<polyline>
   points
<rect>
   x, y, width, height, rx, ry
<svg>
   x, y, width, height, viewBox, preserveAspectRatio, zoomAndPan
<image>
   x, y, width, height, xlink:href, preserveAspectRatio
<tspan>
   x, y, dx, dy
<text>
   x, y, dx, dy
<style>
   class
<script>
   xlink:href
<elements implementing SVGGradient>
   gradientUnits, gradientTransform, spreadMethod, xlink:href
<linearGradient>
   x1, y1, x2, y2
<radialGradient>
   cx, cy, r, fx, fy
<stop>
   offset
<symbol>
   viewBox, preserveAspectRatio
<use>
   x, y, width, height, xlink:href
<marker>
   refX, refY, markerWidth, markerHeight, markerUnits,
   orient (multi-prop), viewBox, preserveAspectRatio
<clipPath>
   clipPathUnits
<textPath>
   startOffset, method, spacing, xlink:href
<filter>
   filterUnits, primitiveUnits, x, y, width, height, result,
   filterRes (multi-prop)
<all feXxx filter elements>
   x, y, width, height, result
<feGaussianBlur>
   in, stdDeviation (multi-prop)
<feComponentTransfer>
   in
<feComponentTransferFunction>
   type, tableValues, slope, intercept, amplitude, exponent, offset
<feMergeNode>
   in
<feOffset>
   in, dx, dy
<pattern>
   patternUnits, patternContentUnits, patternTransform, x, y,
   width, height, xlink:href, preserveAspectRatio
-----------------------------------------


Some of these attributes map to more than one DOM object tree:

<marker>::orient
   maps to two properties: orientType, orientAngle
<filter>::filterRes
   maps to two properties: filterResX, filterResY
<feGaussianBlur>::stdDeviation
   maps to two properties: stdDeviationX, stdDeviationY

> For comparison, this setup sounds a lot like what happens with HTML
> inline style.  What we do there is that changes to the style object just
> notify that the style attribute changed.  This triggers a style
> reresolve, which picks up the new style.  Which exact CSS properties in
> the inline style changed is not relevant to this process, since in the
> end we need to do a style reresolve no matter what.
>
> Could a setup like this work for SVG?  Or would it be too expensive?

I'm not sure. I need to understand the two existing mechanisms better and think
about this some more.

-Jonathan
_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

Boris Zbarsky
Jonathan Watt wrote:
> I think the latter. I'm not aware of any cases where actions depend on
> the exact property of an object. I think we only have to care that the
> "underlying" DOM object tree corresponding to the attribute changed in
> some way. Not which property it was.

In that case, a setup akin to what we have for inline style for HTML would work
just fine here:  Just store the DOM object tree itself in the attribute value
(as an nsISomething, I guess), and on mutation of the DOM object tree via the
DOM methods call AttributeChanged on the relevant attribute.  On changes to the
attribute via SetAttr, reparse the attribute into the DOM object tree.  On
GetAttr calls, serialize the DOM object tree.

> I'm not sure. I need to understand the two existing mechanisms better
> and think about this some more.

OK.  Let me know.

-Boris
_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

Brian Birtles
While we're talking about this I just want to point out that CSS
properties have the same requirement as SVG attributes with regard to
being able to access the animated and base values independently via
script.

For CSS, getOverrideStyle gets the animated value whilst
getComputedStyle gets the base value.

getOverrideStyle is described at:

http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-DocumentCSS

This is referred to in SMIL Animation at:

http://www.w3.org/TR/smil-animation/#AnimationSandwichModel

In the 8th paragraph in that section.

Brian.

_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

Boris Zbarsky
Brian Birtles wrote:
> For CSS, getOverrideStyle gets the animated value whilst
> getComputedStyle gets the base value.

Why?  Those functions are defined in the DOM Style spec, as you noted, and have
nothing to do with base and animated values as described in SVG.  In particular,
the override style settings affect the computed style.

> getOverrideStyle is described at:
>
> http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-DocumentCSS
>
> This is referred to in SMIL Animation at:
>
> http://www.w3.org/TR/smil-animation/#AnimationSandwichModel
>
> In the 8th paragraph in that section.

The text in that paragraph flatly contradicts the DOM spec's description of
getOverrideStyle.  So you can't implement both specs in the same UA.  Wonderful.

-Boris
_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

Boris Zbarsky
Boris Zbarsky wrote:
> The text in that paragraph flatly contradicts the DOM spec's description
> of getOverrideStyle.  So you can't implement both specs in the same UA.  
> Wonderful.

Actually, that's not true.  And neither is your description of what this text
says.  What it says is that before any animation has happened the base value is
read _once_ with getComputedStyle().  Thereafter, we set the override style to
the animated value (note that this clobbers anyone else's setting of override
style, but that's a minor issue).  This of course might change the computed
style, but we don't care because we never look at it again.

The fact remains that getComputedStyle does not, in general, get the base value.
  Nor does getOverrideStyle, in general, get the animated value -- any script on
the page could also be setting the override style.

-Boris
_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

L. David Baron
In reply to this post by Boris Zbarsky
On Saturday 2005-11-05 00:15 -0600, Boris Zbarsky wrote:

> Brian Birtles wrote:
> >For CSS, getOverrideStyle gets the animated value whilst
> >getComputedStyle gets the base value.
>
> Why?  Those functions are defined in the DOM Style spec, as you noted, and
> have nothing to do with base and animated values as described in SVG.  In
> particular, the override style settings affect the computed style.
>
> >getOverrideStyle is described at:
> >
> >http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-DocumentCSS
> >
> >This is referred to in SMIL Animation at:
> >
> >http://www.w3.org/TR/smil-animation/#AnimationSandwichModel
> >
> >In the 8th paragraph in that section.
>
> The text in that paragraph flatly contradicts the DOM spec's description of
> getOverrideStyle.  So you can't implement both specs in the same UA.  
> Wonderful.
That's what I originally thought.  But actually it doesn't.  It says it
uses getOverrideStyle.  But what it does do is contract the definition
of getComputedStyle, since that's supposed to be affected by the
override style.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "Mapped attributes"

Brian Birtles
In reply to this post by Boris Zbarsky
Sorry for the misleading comments. Clearly I'm out of my depth here.
Thanks for the clarification.

Brian.

_______________________________________________
Mozilla-svg mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-svg