- From: Patrick Doyle <p.r.doyle@gmail.com>
- Date: Wed, 28 Dec 2005 12:34:50 -0500
- To: www-svg@w3.org
Hello, I have some questions for those of you in the know. I'm sure these issues have been addressed already on this list, but I had a look in the archives and had a hard time finding anything that addressed these issues specifically. I'd appreciate it if anyone could point me toward answers for these questions... 1. Paths It seems unfortunate that paths are not specified in XML, but rather in a mini-language contained in the "d" attribute. I fear that makes them unavailable to the DOM, so (for instance) XSLT could not translate paths. The justification given is file size, but that seems a poor reason to subvert the XML language. Those concerned with file size can use compression; surely, these days, any device capable of processing SVG can also handle at least zip compression? 2. Path lengths The effects of path length specifications seem somewhat ill-defined, but I may have simply misunderstood. The wording of section 8.4 seems to imply that the user agent is entitled to presume that the path length specified in an SVG file will be similar to the one computed by the user agent, with the former more precise than the latter. Why not let the author specify any length he wants? Why have the user agent compute path lengths at all? (Unless, of course, they are not specified in the file.) 3. Animation The "animate" elements seem inelegant to me. I was hoping animation would be accomplished by some syntax like <rect x="(t lt 10)?t:10" y="3" width="4" height="5">, with an expression for the x value in terms of time t in seconds. This particular expressions says that when t is less than 10, x=t, and afterward, x=10. (Ok, this may not be the ideal syntax, but you get the idea.) Was this kind of approach considered? Do the "animate" elements have an advantage over this approach? Thanks, -- Patrick Doyle p.r.doyle@gmail.com
Received on Friday, 30 December 2005 08:12:42 UTC