W3C home > Mailing lists > Public > www-style@w3.org > October 2008

Re: Selectors

From: David Hyatt <hyatt@apple.com>
Date: Thu, 16 Oct 2008 14:10:26 -0500
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: Anne van Kesteren <annevk@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <C5DB8902-7796-4753-8308-CCC26D5499B5@apple.com>

In WebKit, :hover is hierarchical (and effectively DOM-based).  We  
determine what element is hit, and then that element and all ancestors  
up the DOM tree are considered to be in :hover.  The same is true  
for :active.  It doesn't matter if the ancestor doesn't happen to  
spatially contain the child (and why should it... consider wanting to  
highlight a hierarchical menu when you're browsing around in a popped  
up submenu).

I honestly do not think we (Apple) can change this behavior.  It's  
fundamental to WebKit apps on OS X that our :hover/:active work this  
way and has been for years.


On Oct 16, 2008, at 10:27 AM, Daniel Glazman wrote:

> Anne van Kesteren wrote:
>> On Thu, 16 Oct 2008 15:55:35 +0200, Daniel Glazman <daniel.glazman@disruptive-innovations.com 
>> > wrote:
>>>     * Does :hover apply to parent of hovered element if that element
>>>       is positioned "outside" of its parent?
>> Seems that :hover should rely on hit testing just like mouse  
>> events. Not sure why it matters where an element is positioned.
> That's exactly why it is an issue !
> Imagine an element having a sub-element positioned outside of its
> parent. IF :hover works like a mouse event, then it bubbles from the
> original target to the parent. But the mouse event occured OUTSIDE of
> the box of the parent, which is not easy to understand from a CSS
> author's perspective since he/she is not manipulating a mouse event in
> a DOM but a pointer hovering some elements in a window...
> </Daniel>
Received on Thursday, 16 October 2008 19:11:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:40 UTC