- From: David Dailey <ddailey@zoominternet.net>
- Date: Tue, 20 May 2014 09:31:02 -0400
- To: "'Dirk Schulze'" <dschulze@adobe.com>, "'Jeremie Patonnier'" <jeremie.patonnier@gmail.com>
- Cc: "'Tavmjong Bah'" <tav.w3c@gmail.com>, "'SVG public list'" <www-svg@w3.org>
My stance on this is, no doubt, highly predictable. Ease of use of a spec by authors is a fundamental concern. Though, clearly, implementers and writers of the spec need it too;) Dirk writes: "SVG should not be a monolithic document but describe the core of SVG. Just as the HTML spec does for HTML. Special casing every property in SVG itself however is not a solution IMO. It is a huge burden to track all changes on other specs for the editors as well. " As I observe many things (both SVG and HTML) that used to work across browsers begin to crumble as HTML5 and CSS exert their influence, merely having examples of what is *supposed* to happen in SVG might help those who are more interested in CSS than in SVG stay honest and remember whence their origins emanate, I think. The fancy parts of SVG (filters, animate, masking, use and replicate, transforms, etc.) are of primary utility for those interested in geometry as semantics, not to those for whom hypertext is the fundamental metaphor of communication. Using HTML's crazy Tower of Babel as an example of how specs should be developed, maintained, and thence propagated into incompatible implementations, does not, to me, seem to be model for anything admirable! I am suspicious that part of that incompatibility is by design, in hopes not of having interoperability, but rather in hopes of having a single Darwinian survivor in a new round of browser wars. As I say, my perspective here is probably predictable, but hopefully charming nonetheless;) Regards David
Received on Tuesday, 20 May 2014 13:31:36 UTC