33736 - [ESM/CSS]:hover no longer matches elements with visibility:hidden

Status: RESOLVED INCOMPLETE

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Hixie (not reading bugmail)]

If an element has a value of "hidden" for the "visibility" property, then it
will never match the :hover pseudo-class. 

STEPS TO REPRODUCE
 Bring up this page:
 http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/visible-dynamic.html
 ...and click on a white area of the page. This will show where some big
 elements labelled "1" to "5" are. Hover over those elements, and they should
 become visible. They do not.

This used to work. It might be solved either by bug 12232 or by bug 5693 or by 
both. Assigning to David, since AFAICT you broke it. :-)

NOTE: I am not arguing that they should get mouse click (:active) events -- 
since they are not there, you cannot click on them. However, I _am_ arguing that
they should get mouse over (:hover) events -- as mentioned in bug 5693, I 
believe that _all_ boxes that are under the pointer along with _all_ those 
boxes' ancestors should get the mouse over effects.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I need to think about this a bit... perhaps a change to CSS2 is needed.

Also, could rules like:

foo { visibility: visible; }
foo:hover { visibility: hidden; }

cause infinite loops?

Comment 2

[Hixie (not reading bugmail)]

Only if you say that :hover only applies to visible elements. I would suggest 
that that is yet another reason to let :hover work on everything.

(For the :active case, I would say that :active applies to elements that 
received the mousedown event while being visible, regardless of whether they
are still visible. So 

   bar { visibility: visible; }
   bar:active { visibility: hidden; }

...would make the <bar> disappear while one was clicking on where it _was_.
So like :hover, except with the prerequisite that they received a mousedown
event while visible.)

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ian - I'm beginning to think you're right.  :hover probably should be able to
apply to multiple elements at once (but not according to the document tree) -
and once it does, this could be done.  What this would require is the creation
of a GetFramesForPoint() function, which could work differently from
GetFrameForPoint().  I'm not sure if it would be useful for anything other than
:hover, though.  It would also fix bug 5693 for :hover.  (I think bug 5693
should be fixed differently for :active, along the lines of the CSS3-userint
draft, with more of a document-tree basis).

GetFramesForPoint() would be reasonably easy to write, since it wouldn't have to
work in paint order -- the only frames that would need to override the default
version would be those with additional child lists (nsBlockFrame... are there
others? - perhaps nsAreaFrame so it wouldn't need to be done per-view?)

The mucking about with the event system might be a bit harder (at least for me).

Tom, any thoughts?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, as I pointed out in bug 5693, :hover must deal with ancestry as well. 
Ick...

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ian -

I've been thinking about this a bit more, and I think this may be a bad idea,
and :hover should only deal with ancestry (from the topmost element).  Why?  It
is (now) generally used to indicate that something can be activated.  Therefore,
one wants hover to apply to an element only when clicking on it can activate
it.  If one allows :hover to apply to links that are covered up (partly, or by
something transparent), then they will look clickable when/where they are not.

So maybe :hover should work by ancestry from the element the mouse is over...

Comment 6

[Hixie (not reading bugmail)]

That's a fair argument. The CSS spec would tend to agree with you (it says that
:hover is for when the user "designates" an element).

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm going to assign this to Tom, although I may be interested in working on it
sometime (but I'm not sure).

Comment 8

[Hixie (not reading bugmail)]

I'm beginning to think that as much as this (:hover applying to visibility:
hidden elements) would be nice, it may not be feasible to implement at all.

Imagine a case where you have two <div>s, containing a single <a> link element,
with both DIVs positioned on top of each other, thus making the links overlap.

If :hover applies to visibility:hidden, then the link in the top most layer,
when that layer is hidden, would light up (and then be clickable) when the
user went to click the first link!!!

Yes, I know that ideally the author would use display:none not visibility:hidden
to do that effect, but the fact of life is people are not going to do it that
way, are they. :-/

There is a workaround which means that we can mark this bug INVALID and still 
allow authors to get the effect I originally wanted, BTW: just use -moz-opacity
to decide if an element is visible. Thus instead of using visibility:hidden and
:hover to switch to visibility:visible, we can have opacity:0 and :hover make it
opacity:100. So it is not a lost cause.

So David: Shall we mark this bug INVALID?

If you need a test case to show this problem in action, see
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/link-layers.html

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think there are some valid issues in it... if you want you could dup it 
against bug 5693, but I'd rather split bug 5693 sometime so this bug might be 
the :hover half...

Comment 10

[joki (gone)]

Interesting discussion on this.  Rather than mark it INVALID i'm going to mark 
it LATER.  Slightly different than marking if to the 'Future' milestone though 
mostly the same, meaning not in this release.  It'll still be dependent on 5693 
so we can look at it more.

Comment 11

[Hixie (not reading bugmail)]

joki: reopenning and moving to future. Sorry, but I need this on my radar, and
it took me ages to find it just now. If you don't want to see it, feel free to
reassign it to me for now.

Comment 12

[Hixie (not reading bugmail)]

As per meeting with ChrisD today, taking QA.

Comment 13

[Boris Zbarsky [:bzbarsky]]

so.... have we made any progress on deciding what to do?

Assigning to hixie for ease of finding and because the ball is not in the
implementation court at the moment....

Comment 14

[Hixie (not reading bugmail)]

http://www.w3.org/TR/css3-selectors/#dynamic-pseudos :
# *  The :hover pseudo-class applies while the user designates an element (with 
#    some pointing device), but does not activate it. For example, a visual user 
#    agent could apply this pseudo-class when the cursor (mouse pointer) hovers 
#    over a box generated by the element. 

so... I dunno. The spec seems to say we should do this. I defer to dbaron.

Comment 15

[Greg K.]

Reconfirmed using FizzillaCFM/2002071208. None of the DIVs react to :hover.
Setting All/All.

Comment 16

[Pham]

.

Comment 17

[u597032]

Page no longer active