- From: Chris Lilley <chris@w3.org>
- Date: Fri, 15 Apr 2005 23:52:35 +0200
- To: www-svg@w3.org
- Message-ID: <1386071543.20050415235235@w3.org>
This is a forwarded message From: Andrew Girow <andrewgirow@yahoo.com> To: Chris Lilley <chris@w3.org> Date: Monday, April 4, 2005, 10:11:02 AM Subject: [SVGT12 Comment] Comments from Andrew Girow ===8<==============Original message text=============== Hello Chris, Thank you for your answers. Still I dont feel comfortable with the Color Traits and I think it is a design problem. Thanks again, Andrew Girow http://www.tinyline.com --- Chris Lilley <chris@w3.org> wrote: > On Wednesday, September 1, 2004, 5:31:03 PM, Andrew > Girow wrote: > > AG> From: andrewgirow <andrewgirow@yahoo.com> > AG> To: SVG-Mobile@yahoogroups.com > AG> Date: Wednesday, September 1, 2004, 5:00:04 PM > AG> Subject: [SVG-Mobile] SVG Tiny 1.2 DOM Feedback > and Questions > > AG> While checking/ implementing SVG Tiny 1.2 DOM > AG> I got several questions: > > Hello Andrew, > > The SVG Working Group thanks you for your review of > the SVG Tiny 1.2 > Last Call specification draft. The group has > reviewed you comments and > has the following responses. > > AG> 1. THE COLOR TRAITS > AG> In the A.2.6 Attribute and Property Access is > written "Trait is the > AG> typed value (e.g., a number, not just a string) > that gets assigned > AG> through an XML attribute" > > AG> The set trait for color uses two functions > instead of one: > > AG> setRGBColorTrait [null | SVGRGBColor] > AG> setTrait(none | currentColor | inherit) > > AG> I see here a problem for application programmers > who are not experts > AG> in SVG. Why there are two functions for the same > type? > > AG> The get trait for color uses just one function: > getRGBColorTrait. > AG> So, there is no way to know that the given > PathElement, for example, > AG> uses the `currentColor' of the parent > GroupElement. > > AG> The get trait also does not allow to know that > the PathElement fill > AG> attribute is inherited from the parent > GroupElement. > > AG> If the getRGBColorTrait returns null. What it is > suppose to mean: > AG> none, currentColor or inherit? > > AG> The set and get traits must be consistent. If > the program sets the > AG> fill attribute to `currentColor' it must be a > way later on to check > AG> if this attribute equals to the `currentColor'. > AG> As I understand the whole idea behind traits is > to provide strongly > AG> typed access to SVG attributes. In a case of > color we have two types > AG> instead of one! > > 1. The Color Traits. > > The group has carefully considered different > alternatives to get and set > trait values and feels that the solution it selected > (use of typed > methods for reading and writing trait values) is the > best trade-off > considering the constraints. This is reflected in > the latest work done > on the uDOM specification and the SVG 1.2 Full > Working Draft that was > referenced from the SVG Tiny 1.2 specification that > you reviewed did not > reflect these latest changes. > > With the latest changes, typed methods are used to > set values of a > specific type. So, for example, if the user wants to > set a blue color on > an element, it will use the setRGBColorTrait method > with an SVGRGBColor > value parameter. Null values are _always_ disallowed > as trait values. If > special values are needed (such as 'none', 'inherit' > or 'currentColor'), > the values are considered to be string values and > set through the > setTrait() method. > > When reading a trait, the user gets the _computed_ > value. In the case of > a color, the returned value is an SVGRGBColor > instance or null in case > the computed value is 'none'. The SVG WG realizes > the handling of 'none' > is asymetrical but the various options were > considered (like allowing > null in setRGBColor or throwing an exception in > getRGBColor if the value > was none) and the group feels the current design is > the most natural for > developers which can do common operations on colors > without much > specific knowledge of SVG. > > > AG> 2. SVGSVGElement > > AG> In the SVGSVGElement there is a new attribute > that could not be found > AG> in the previous versions of SVG DOM. > > AG> attribute float currentRotate; // raises > (DOMException) on setting > > AG> The question is how this parameter applied to > the current > AG> transformation matrix? > AG> Does it go after the currentTranslate of before? > What are the order > AG> of operations now for the current transform? Do > we need this at all? > AG> I mean that there is no explanation why it is in > the DOM now. > > 2. SVGSVGElement. > > The documentation on currentRotate has been updated > to precisely define > what it means and its relation with the currentScale > and > currentTranslate members. The latest documentation > says: > > > User Agent Transforms > > The DOM attributes currentScale, currentRotate and > currentTranslate are > combined to form user agent transformation which is > applied at the > outermost level on the SVG document (i.e., outside > the outermost 'svg' > element) if "magnification" is enabled (i.e., > zoomAndPan attribute is > set to "magnify"). Their values can potentialy be > modified through > user-agent specific UI. User agent transformation > can be obtained by > multiplying matrix > > [currentScale 0 currentTranslate.x] > [cos(currentRotate) -sin(currentRotate 0] > [ 0 currentScale currentTranslate.y] by > [sin(currentRotate) cos(currentRotate) 0] > [ 0 0 1 ] > [ 0 0 1] > > > i.e. (translate, then scale, then rotate the > coordinate system). The > reference point for scale and rotate operations is > the origin (0, 0). > > Please let us know if you do not find these answers > satisfactory. > > > -- > Chris Lilley mailto:chris@w3.org > Chair, W3C SVG Working Group > W3C Graphics Activity Lead > > __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com ===8<===========End of original message text=========== Forwarded; sender is not subscribed to www-svg, original message bounced. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead
Attachments
- message/rfc822 attachment: 1.eml
Received on Friday, 15 April 2005 21:52:36 UTC