W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

Re: ISSUE: clientX and clientY coordinates in DOM MouseEvents

From: Thierry Kormann <tkormann@ilog.fr>
Date: Fri, 11 Jan 2002 12:36:26 -0500 (EST)
Message-Id: <200201111736.g0BHaF919441@quokka.inria.fr>
To: Christophe Jolif <cjolif@ilog.fr>
Cc: w3c-svg-wg@w3.org, w3c-dom-wg@w3.org
On Friday 11 January 2002 18:20, Christophe Jolif wrote:

> > The DOM specification clearly says that whatever the EventTarget is,
> > clientX and clientY must be relative to the user agent drawing area.
> > Having the correct behavior for both SVG and DOM is only possible in a
> > plugin environment (two separate DOM tree - two different user agent).

> we can easily understand the "nearest" 'svg' element in that sentence
> and not the "outermost" as it is not explicitely stated. The sentence
> below in the spec (which is an error by the way as there is no
> relatedNode attribute that I know on MouseEvent in DOM Level 2 only a
> relatedTarget but which has already a usefull meaning for mouseout/over)
> is more explicit: "relatedNode is the corresponding outermost 'svg'
> element.". So maybe forgotten the "outermost" is just a typo...

You are right. outermost is probably missing and I forgot to mention that 
relatedNode should be relatedTarget.

> > [A]
> >
> > Ask the DOM WG to errate the DOM Level 2 Events module and change the DOM
> > Level 3 Events module saying something like:
> >
> > clientX - The horizontal coordinate at which the event occured relative
> > to coordinate system of the EventTarget.
> >
> > clientY - The horizontal coordinate at which the event occured relative
> > to coordinate system of the EventTarget.
> Maybe "coordinate system of the EventTarget" wording is a not very clear
> (at least for SVG context) because it sounds to me as if it was the
> current (user) coordinate system for the target and not the (outermost?)
> viewport coordinate system of the target.

I agree.

> > [B]
> >
> > Add an errata to the SVG1.0 spec explaining that clientX and clientY have
> > the same behavior than in the DOM specification (and that will break
> > existing SVG content using clientX and clientY - that's to say, most of
> > the dynamic SVG content using scripting).
> I doubt it will break a lot of content because there's not a lot of
> multi-namespace SVG content out there at the time!

If SVG provides the same definition that DOM 2, clientX and clientY will be 
relative to the coordinate system of the ''plugin window'' (not the 

> Does it means something for all DOM implementations? Can't we inherit
> form DOM MouseEvent and add the fields we need?

The goal of the DOM WG is to provide generic APIs. They may be interested 
(and they are, I am sure :) in such a mecanism.

Received on Monday, 21 January 2002 12:39:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:09 UTC