- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 1 Oct 2010 18:53:07 +0200
- To: public-fx@w3.org
Am Freitag, 1. Oktober 2010 geschrieben: > 2010/10/1 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>: > > 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 http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBoxUnits '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) Olaf
Received on Friday, 1 October 2010 17:00:23 UTC