- From: Chris Lilley <chris@w3.org>
- Date: Fri, 11 Jan 2002 16:58:28 +0100
- 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> RECOMMENDATION: 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