Re: [cssom] Element size/positioning information

Le Mer 13 avril 2011 10:27, Tab Atkins Jr. a écrit :
> 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.
>

Tab,

I thought you forgot or left out Opera in your previous sentence.


>
>>  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.


I am reposting my explanation:

>> If you want
>> to listen to mouse events on the kth ancestor of an element, then you
>> would register an event listener for that (kth ancestor) element. There
>> is no serious difficulty with what you say and want to do.


I still think you do not need to do those calculations (ie get mouse
coordinate relative to an identified element within the containment
hierarchy, then with using clientX/Y and subtracting the element's
position). Events are dispatched (trickle down and bubble up), travel
within the containment hierarchy. They are not cancelled unless you
programmatically cancel the propagation; so the properties should always
be retrievable.

"
Capturing
    The process by which an event can be handled by one of the event's
target's ancestors before being handled by the event's target.
Bubbling
    The process by which an event propagates upward through its ancestors
after being handled by the event's target.
"
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-overview-terminology

"
currentTarget of type EventTarget, readonly
    Used to indicate the EventTarget whose EventListeners are currently
being processed. This is particularly useful during capturing and
bubbling.
eventPhase of type unsigned short, readonly
    Used to indicate which phase of event flow is currently being evaluated.
target of type EventTarget, readonly
    Used to indicate the EventTarget to which the event was originally
dispatched.
"
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-interface

A simple interactive demo may empirically settle this issue.



>>> 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.

I merely mentioned the property names.

> In fact, I specifically
> said, elsewhere in the email, that clientX/Y already serve this
> purpose, they just have a horrible name.

Bad name? Maybe. It may be a bit late now to rename those properties. They
have been in use since IE4 and they are listed in (WD) DOM 3 events.

Anyway, what do you suggest instead?

viewportX/viewportY  ?

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Wednesday, 13 April 2011 23:06:42 UTC