W3C home > Mailing lists > Public > www-svg@w3.org > July 2014

Re: Status of connectors for SVG2

From: Juergen Roethig <roethig@dhbw-karlsruhe.de>
Date: Fri, 11 Jul 2014 09:52:05 +0200
Message-ID: <53BF97A5.3080301@dhbw-karlsruhe.de>
To: <www-svg@w3.org>
Hello world,

Doug Schepers wrote:
> 
> I understand that you're not proposing breaking changes with old syntax. 
> When I said "backwards compatibility", I meant compatibility with older 
> UAs, not with older content. I don't think it's advisable to make 
> dramatic changes to existing elements.

Once again - what's the "dramatic change" in the "existing elements"? 
That you would be allowed to use an additional syntax for denominating 
the coordinates of a single point in the coordinate system? Old files 
will not use that new syntax, and old browser will not be able to 
interpret new files with the new syntax. But old browsers will even be 
able to interpret new files which just use the old syntax and not the 
new one. And new browsers will interpret files with old and new syntax, 
of course. And the "new syntax" is not intended to replace the "old 
syntax", it is just an additional opportunity of giving point 
coordinates. Usually, the new syntax and the old syntax will be mixed in 
new files, since it might be silly to use a "refpoint" for a coordinate 
pair which is just used once in the SVG file.

And about the new syntax, one might discuss, of course, how it should 
look like: It might even be of the form "url(#refid)" which is not new 
at all. Instead, this would form just a new usecase for an existing 
syntax in existing attributes of existing elements at places, where that 
syntax was not allowed, before.

All in all, I do not see any compatibility problem. Well, one of course: 
Old UAs will not be able to interpret the new features (the "new 
syntax") in new files, but this is a usual problem ... to solve this, 
implementers would either need a crystal ball and already implement in 
their browsers all the features which might come up in the future, or 
there must not be any new features at all in future implementations.

And regarding the lack of implementers' support: Is it a categorical 
"must" that features need to be implemented in any browsers before 
making them a proposal/draft/recommendation? Instead, it might be a 
motivation for the browser vendors to implement the feature if it is 
already specified. The former method of specification reminds me of the 
"good old times" of the "good friends" MS and NS implementing all those 
nice features, just in order to have them finally "standardized" ...

Regards,

Juergen Roethig
Received on Friday, 11 July 2014 07:53:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:37 UTC