- From: Juergen Roethig <roethig@dhbw-karlsruhe.de>
- Date: Fri, 11 Jul 2014 09:52:05 +0200
- 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