RE: Fwd: Re: ISSUE: clientX and clientY coordinates in DOM MouseE vents

The messages popping out of time warp makes me concerned that the issue
might still be muddled somewhere.  The following summarizes my understanding
of the issue.

In the initial message,
http://lists.w3.org/Archives/Public/www-svg/2002Jan/0018.html

>The DOM Level 2 specification defines two attributes clientX and clientY
for
>MouseEvents. According to the DOM Level 2 specification, those coordinates
are
>relative to the DOM Implementation's client area.

>The SVG specification has changed this definition and the clientX and
clientY
>attributes represents viewport coordinates for the coresponding svg
element.

From http://www.w3.org/TR/SVG/svgdom.html#RelationShipWithDOM2Events

"clientX and clientY parameters for mouse events represent viewport
coordinates for the corresponding 'svg' element. relatedNode is the
corresponding outermost 'svg' element."

As mentioned in
http://lists.w3.org/Archives/Public/www-svg/2002Jan/0027.html, there appears
to be an "outermost" missing in the first sentence.
 

>According to the SVG spec, if a mouse event occured on B or C, clientX and
>clientY should be relative to the viewport ([0, 0] [10000, 10000]) and this
is
>not what the DOM spec says.

Adobe SVG Viewer does not interpret "viewport coordinates" as the user
coordinate space for children of the outermost <svg> element and it not
affected viewBox attribute, but as the device coordinates of the SVG
plug-ins window.  This can be demonstrated by the SVG sample in
http://lists.w3.org/Archives/Public/www-svg/2002Jan/0028.html  Though the
viewBox is "0 0 10000 10000", the values of clientX and clientY are pixel
values.

Changing implementations so that clientX and clientY would be in the user
coordinates established by the outermost <svg> element would disrupt all
existing SVG content that monitor mouse position.

If "viewport coordinates" are the device coordinates used to render the SVG
content (which is the currently implemented interpretation), then the only
time that the SVG and DOM Events would conflict over the appropriate value
of clientX and clientY is when the document element is not <svg>.  Since SVG
encapsulated in other user interface namespaces (XHTML) is still
experimental at best, dropping the clause in appending B5 and synchronizing
SVG's definition with DOM Events would break no existing content.

The beneficial affects of this change would be that eventual mixed XHTML/SVG
content would see continuous values of clientX and clientY and not see a
catastrophic change of values as the mouse transitioned from XHTML to SVG
content.

The downside of the change would be that (without help from the
implementation), it would not be tractable to converter clientX and clientY
to equivalent coordinates in any SVG user coordinates, since it would have
to predict where the XHTML layout would put the SVG content.  This was
apparently the motivation behind tying clientX and clientY to the outermost
SVG elements device coordinates, since then it would be tractable to convert
clientX and clientY to SVG user coordinates under some limited conditions.

If SVG 1.1 DOM could provide method or methods that allow clientX and
clientY to be converted to user coordinates, that would eliminate the
motivation for the deviation from the generic DOM Events definition and
would also eliminate a significant amount of boilerplate code and document
constraints that are necessary to convert clientX and clientY to user
coordinates.  Also, it would allow SVG content to respond to events over
XHTML content.

My recommendations would be to:

1. Issue an errata revoking the sentence is Appendix B5 (or drop it in SVG
1.1).  This should have no affect on existing SVG content and viewers since
it should only affect intermixed XHTML and SVG content.

2. Add an:

SVGPoint convertClientXY(double x, double y)

or similar to SVGElement in SVG 1.1.  The returned point would be in user
coordinates before any transformations established by the element.

3. Be cautious with the term "viewport coordinates" in the recommendation
since it may be confused by the similarity with the user coordinate space
established by "viewBox".

4. Be cautious with the term "real world" units.  In coords.html it is used
to indicate display or device units.  With an engineering or cartographic
mindset, you would interpret "real world" units as the distance between
roads or the length of a piece of pipe represented by a particular mark on a
piece of paper or a display.

Received on Tuesday, 22 January 2002 15:50:53 UTC