RE: Clean-up SVG2 spec

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