- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 13 Apr 2011 10:27:22 -0700
- To: www-style@gtalbot.org
- Cc: www-style list <www-style@w3.org>
2011/4/12 "Gérard Talbot" <www-style@gtalbot.org>: > Le Mar 12 avril 2011 17:31, Tab Atkins Jr. a écrit : >> Now, the mouse part of the discussion. >> >> Currently, there is one interoperable bit of location information >> returned by mouse events - the position relative to the viewport. >> Unfortunately, it's exposed via the unintuitive name of 'clientX' and >> 'clientY'. >> >> Some browsers expose other information - IE and Webkit expose >> offsetX/Y which is relative to the element itself > > I have said that Opera 9+ also supports offsetX/Y in one of my previous > email. I didn't say otherwise. > and still get >> coordinates relative to a chosen element (for example, if you're >> drawing into a canvas, and want to still track the mouse when it's >> outside the canvas), then you have to switch back to using clientX/Y >> and subtracting the element's own position. > > No. Yes. There is no way to listen for a mouse event on an element's ancestor, and then get mouse coordinate relative to that element, without using clientX/Y and subtracting the element's position. >> All told, there appear to be three pieces of information that we want to >> expose: >> >> 1. Mouse coordinates relative to the viewport. > > clientX/Y (also x/y according to CSSOM) Nowhere did I claim that these don't work. In fact, I specifically said, elsewhere in the email, that clientX/Y already serve this purpose, they just have a horrible name. >> 2. Mouse coordinates relative to an element's layout box(es) > > By layout boxes, you mean offsetWidth/offsetHeight or you mean > clientWidth/clientHeight? You want to include or exclude borders? All of the above, plus more. My email makes this clear. ~TJ
Received on Wednesday, 13 April 2011 17:29:47 UTC