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

Re: [D3E] Comments

From: Sean Hogan <shogun70@westnet.com.au>
Date: Mon, 01 Feb 2010 10:48:11 +1100
Message-ID: <4B6616BB.2070403@westnet.com.au>
To: Olli@pettay.fi
CC: Olli Pettay <Olli.Pettay@helsinki.fi>, "www-dom@w3.org" <www-dom@w3.org>, Doug Schepers <schepers@w3.org>, Travis Leithead <travil@microsoft.com>
On 1/02/10 5:21 AM, Olli Pettay wrote:
> Hi all,
>
> here are few comments about the latest editor's draft
>
>
> 1.2
> - "complete set of character values and key names in the Key Values Set"
>   Does browser need to support all the key values? In practice a
>   browser running on OSX may not ever dispatch an event which has key
>   'Win'. Or is it enough if script creates the event and initializes the
>   right values?
>

A browser on OSX could dispatch an event with key "Win" if the event was 
created by script.
Although that's probably irrelevant.
Certainly a conforming UA must provide the correct values when a key is 
pressed.

>
> 4.2
> - Why should custom event be non-trusted, if the UA implementation
>   decides to dispatch an event implementing it.
>

Agreed. I think browser extensions would be the main source of trusted 
custom events.

> 5.2.3.1
> - Needs review from SVG WG, or perhaps nx/ny could be moved to
>   the whatever-spec SVG/CSS taskforce will have.
>   (I don't recall now what we agreed)
>
> I think there should be a new chapter started after
> 5.2.3.2 but before the definition of 'click'.
>
> mouseenter and mouseleave
> - They still need to be defined more precisely.

I think they are supposed to match IE behavior.

>   When mouse is moved for body element to
> <h1><h2><h3>foobar</h3></h2></h1> will there be
>   3 mouseenter events dispatched?

That isn't valid HTML. But assuming that it is...

It depends. If the mouse move directly to h3 - without moving over h1 or 
h2 - then there will be only one event.
This could happen if h3 is positioned absolutely (or relatively, or 
floated, etc) or even if the border of h3 coincides with the border of 
h1 and h2 (which it would if margins, borders and paddings are all zero).

>   And when mouse is again moved to body, will there
>   be 3 mouseleave events?
>   If the DOM tree is very deep, the will lots of events,
>   though not sure I case about that.

There will be the same number of events as for mouseover, mouseout.

> - "Note: This is the event type equivalent of the CSS :hover
>    pseudo-class [CSS2]. See also the mouseleave event type."
>   Not sure about this. :hover is sort-of a state.
>   mouseenter and -leave aren't.
>   :hover and mouseenter/leave do have something in common,
>   but saying "equivalent" is perhaps too strong.
>

Agreed.

mouseenter (when it occurs) is synchronized with the start of the CSS 
:hover pseudo-class, mouseleave with the end.

However, the :hover state for an element is not always preceded by a 
mouseenter event on the element.
Referring back to the previous example <h1><h2><h3>foobar</h3></h2></h1> 
(which isn't valid, but assuming that it is):
Say h3 is positioned absolutely, so that the mouse could move to it 
without moving over h1 or h2.
There would be a mouseenter event on h3, but not on h1 or h2.
Yet all of h3, h1 and h2 would be in the :hover state.

The CSS :hover state is the natural lead-in to explaining mouseenter / 
mouseleave, but when you get into the details you realize they are not 
directly related. It might be better not to mention CSS :hover in the 
specification - leave it for tutorials.
Received on Sunday, 31 January 2010 23:48:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT