- From: Chris Lilley <chris@w3.org>
- Date: Tue, 29 Nov 2005 19:00:10 +0100
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Jon Ferraiolo <jonf@adobe.com>, www-svg@w3.org
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 CG
Received on Tuesday, 29 November 2005 18:00:17 UTC