W3C home > Mailing lists > Public > www-svg@w3.org > January 2002

Re: ISSUE: clientX and clientY coordinates in DOM MouseEvents

From: Chris Lilley <chris@w3.org>
Date: Fri, 11 Jan 2002 16:58:28 +0100
Message-ID: <5073309052.20020111165828@w3.org>
To: Dean Jackson <dean@w3.org>
CC: www-svg@w3.org, Thierry Kormann <tkormann@ilog.fr>, www-dom@w3.org
On Friday, January 11, 2002, 12:20:43 PM, Dean wrote:

DJ> ----- Forwarded message from Thierry Kormann <tkormann@ilog.fr> -----


DJ> [A]

DJ> Ask the DOM WG to errate the DOM Level 2 Events module and change the DOM
DJ> Level 3 Events module saying something like:

DJ> clientX - The horizontal coordinate at which the event occured relative to
DJ> coordinate system of the EventTarget.

DJ> clientY - The horizontal coordinate at which the event occured relative to
DJ> coordinate system of the EventTarget.

DJ> Advantage: that will not break any existing SVG content and should work with
DJ> all existing XML applications that have only one coordinate system: the user 
DJ> agent area's one.

I agree that this is the best approach. Its an example where loose
language seemed ok because there was only one coordinate system. But,
given we have multiple ones, its a pain and this clarification (not
really a change) would be the best solution.

DJ> Note: Some extra work will be necessary if both informations are needed (mouse
DJ> coordinates in the EventTarget's coordinate system and in the user agent's
DJ> area coordinate system) and I believe that both are usefull.

Yes but we already know that there are problems when moving over a
rendering context boundary.  How would you propose making both sets of
information available 9I guess the missing set would be relative to
the root element coordinate system, or would that be any named
elements coordinate system?

DJ> [B]

DJ> Add an errata to the SVG1.0 spec explaining that clientX and clientY have the
DJ> same behavior than in the DOM specification (and that will break existing SVG
DJ> content using clientX and clientY - that's to say, most of the dynamic SVG
DJ> content using scripting).

That seems like a backwards step. It breaks lots of stuff while not
really helping non-SVG DOM usage any. And the first proposal did not
break non-SVG Dom usage. So I prefer the first solution.

DJ> ----- End forwarded message -----
 Chris                            mailto:chris@w3.org
Received on Friday, 11 January 2002 10:58:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:52 UTC