Re: 2D Transforms Update

Am Freitag, 1. Oktober 2010 geschrieben:
> 2010/10/1 Dr. Olaf Hoffmann <>:
> > c) Does an animated transformation (or animation of the content of
> > a property transformed element) have any influence on the
> > transform-origin 50% 50% - could be very funny and frustrating for
> > authors to get wild moves of the initial value due to changes of the
> > bounding box ;o)
> > What happens, if the element (sometimes) has not boundingBox,
> > for example a rotating line or another object, scaled one dimension
> > to zero?
> > To say that the intial value becomes 0 is not necessarily useful for
> > one dimensional objects, for them there is a need now to define
> > a boundingBox for transform-origin's initial value.
> A line has a bounding box, even if one dimension of the box is 0, and
> percentages are well defined and predictable even when the dimension
> they're referring to is 0.

Well, due to 7.11 there are at least some problems for such a boundingBox
'Then, coordinate (0,0) in the new user coordinate system is mapped to the 
(minx,miny) corner of the tight bounding box within the user coordinate 
system of the applicable element and coordinate (1,1) in the new user 
coordinate system is mapped to the (maxx,maxy) corner of the tight bounding 
box of the applicable element. In most situations, the following 
transformation matrix produces the correct effect:
[ (maxx-minx) 0 0 (maxy-miny) minx miny ]

Therefore for ObjectBoundingBox is mentioned in the last paragraph of
the section:
"Keyword objectBoundingBox should not be used when the geometry of the 
applicable element has no width or no height, such as the case of a 
horizontal or vertical line, even when the line has actual thickness when 
viewed due to having a non-zero stroke width since stroke width is ignored 
for bounding box calculations. When the geometry of the applicable element 
has no width or height and objectBoundingBox is specified, then the given 
effect (e.g., a gradient or a filter) will be ignored."

For this and for other reasons paint servers like gradients have a fallback
in the notation.

If the 2D transform draft means another boundingBox, this should be
noted - or even better to adjust this a little bit to cover this case better
without ignoring it - what can be a problem for the initial value.

> > d) Some transformation functions (section 'Transformation Functions')
> > have values like <angle> or <translation-value>.
> > Does it imply additional unit identifiers in SVG or in CSS?
> > For example for CSS angle is currently (CSS2.0 or CSS3 draft,
> > not available at all in the referenced CSS2.1) only available
> > for aural style sheets and requires a unit - I assume that the transform
> > property will be applicable not just for aural style sheets in the future
> > and hopefully the angles will not be normalised if applied to rotations,
> > as currently required in CSS.
> In CSS3 the <angle> value is defined by CSS3 Values & Units.  It
> definitely isn't just an aural-specific unit.
> The definition of <angle> will indeed be changed to not automatically
> normalize, based on previous discussion in the CSS group.

The draft vom 2006 notes:
"3.4.5. Angles

Angle values (denoted by <angle> in the text) are used with aural cascading 
style sheets. 

Their format is a <number> immediately followed by an angle unit identifier. 

Angle unit identifiers are: 
deg: degrees 
grad: grads 
rad: radians 
turn: turns 

Angle values should be normalized to the range 0-360deg by the user agent. For 
example, -10deg and 350deg are equivalent. 

For example, a right angle is '90deg' or '100grad' or '1.570796326794897rad'.

I think there is no newer. 
Because obviously parts of 2D/3D transforms are already implemented,
it is either time to update die CSS draft for units or at least to add a note
to the 2D/3D draft, what the intented future meaning is.
Else, for every new draft for 2D/3D transform one has to remind the
editor, that this is either undefined or not applicable or not useful ...

But if the problem is already known in the CSS group (what I assumed
due to previous discussions, but until it is done, one can never be sure,
that this is not forgotten), one just has to remind about the missing part 
in  current drafts depending on this, not to discuss this anymore ;o)


Received on Friday, 1 October 2010 17:00:23 UTC