W3C home > Mailing lists > Public > www-svg@w3.org > April 2006

RE: [SVGMobile12] event aliasing

From: Jon Ferraiolo <jonf@adobe.com>
Date: Mon, 3 Apr 2006 14:29:06 -0700
Message-ID: <6ECA24BE410D994496A2AE995367C5C8917E86@namail3.corp.adobe.com>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: <www-svg@w3.org>


I think you will agree that just because the SVG WG breaks compatibility with the past in one area as justification for breaking it in another. Regarding the changes for gradients, I was not aware that there were incompatible changes and, if you are correct, then I would really like to know why such incompatible changes were made, *especially* if there is actual content that relies on the old behavior.

Jon


-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] 
Sent: Monday, April 03, 2006 2:19 PM
To: Jon Ferraiolo
Cc: www-svg@w3.org
Subject: Re: [SVGMobile12] event aliasing

* Jon Ferraiolo wrote:
>I think it is a dangerous precedent for existing approved specifications
>to be changed gratuitously because a small collection of people are not
>aware of implementations that might or might not support a given feature
>within that specification.

SVG 1.1 is very unclear about which event targets can receive focus, it
just hints at text selection. Which event names to use here isn't clear
to me either, I already gave an example for how the specification con-
tradicts itself. Activation is tricky in similar ways. There is not a
single correct test for this in the test suite. So if there is content
that actually relies on this, it's pretty whacky and does not work at
all in a broad range of implementations. Making this change would just
acknowledge that, and implementations that have to support this anyway
due to compatibility concerns could just dispatch the three additional
events.

Let's compare this to changes the SVG Working Group already agreed to
make. For example, the default values for x1/x2/y1/y2 on linearGradient
with userSpaceOnUse are well-defined (though incorrectly specified in
the current SVG Tiny 1.2 draft) but completely different in SVG 1.1 and
SVG Tiny 1.2; this is a feature that enjoys widespread support, there
is actual content that relies on this, and there is no simple way for
concerned implementers to implement both behaviors at the same time.

What precedent does that set? In comparison?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Monday, 3 April 2006 21:29:57 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:34 GMT