On Tuesday, November 29, 2005, 6:47:54 PM, Boris wrote: BZ> Chris Lilley wrote: >> The intent is that CSS units MUST be supported for width and height on >> <svg> and MUST NOT be supported elsewhere. BZ> This seems to me to place an undue burden on implementations that DO BZ> have support for CSS -- instead of using the same code for both sets BZ> of attributes, they are now forced to write separate code to handle BZ> the two. How many overlapping sets of attributes are we talking about here? BZ> Also, since CSS-less implementations still have to handle units for BZ> width/height on <svg>, I don't see how their life becomes any BZ> easier... In fact, they have to have two separate codepaths instead BZ> of just one, which seems unfortunate to me if they're trying to BZ> minimize codesize. BZ> In short, from my point of view as an implementor I see no benefits BZ> to this approach and lots of drawbacks. BZ> What am I missing? Well, I could invite you to try implementing SVG where fixed, real-world units like mm and in can be mixed with lengths in a coordinate system, and then try to implement a nested transformation coordinate system. But people already tried that early in the 1.0 timeframe. Feedback from those implementors was that it made the code extremely complex, slow, produced non-intuitive results, and was very rarely exercised (since the entire point is to make scalable graphics; graphics that are semi-scalable are more complex) so was more likely to be buggy. In the real world, the number of times that someone wants to make a rounded rectangle that is scalable except that the y-radius of the rounded corder is 2em is very small. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CGReceived on Tuesday, 29 November 2005 18:00:17 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 September 2006 18:11:42 GMT