Re: Scope of :hover

John Lewis wrote:

> Ernest wrote on Tuesday, June 3, 2003 at 7:06:54 PM:
> 
> > I presume that the intention is to provide a mechanism whereby it is
> > easy to determine which row and column a cell belongs to. However,
> > how does the use of :hover to do this achieve this when the page is
> > printed and interactive pseudo-classes such as :hover are not
> > available?
> 
> It doesn't. Nor does it do so for links or any other type of element.

Which was my point, I was asking a rhetorical question there.

> I think applying *:hover to only certain elements in inconsistent. For
> example, why not let authors use :link:hover if that's what they mean?
> In this fashion, two behaviors are possible. Saying :hover applies
> only to certain elements means that applying it to other elements is
> impossible. That sucks, especially now that certain browsers (Mozilla,
> Opera, others?) have given CSS authors a taste of what's possible.

I'll grant that given how :hover has tended to be implemented, it may 
be necessary to use some other pseudo-class to achieve the needed 
capability to address only interactive elements.  

> I like what Opera 7 did. Since some authors think :hover only applies
> to links, probably because that's how Win IE behaves, Opera made it so
> the :hover selector applies only to links, while the *:hover selector
> applies to everything, and tr:hover applies to tr elements. This is
> perhaps sacreligous, but it works well in the real world. Knowledgable
> authors can be sure to use *:hover instead of :hover if that's what
> they mean, and people who have no idea what they're doing can continue
> to use :hover without problems.
> 
> It's inconsistent, maybe a little confusing, and I'm sure there's at
> least one document it messes up, but for the most part it works. If
> CSS is going to say what :hover does and doesn't apply to, I think
> behavior similar to Opera's should be considered.

I don't know the specifics of Opera, but IIRC, Mozilla only makes a
distinction between :hover an d*:hover in quirks mode for just the
reasons that you've mentioned.

Using :link,:visited to indicate links is fine, (indeed preferable to 
the use of :hover by itself no matter how one interprets :hover) but 
there are other types of interactivity besides hyperlinks. If :hover 
(or some other pseduo-class) is not usable to indicate elements that 
are interactive (of which links are only one type of interactivity) 
then an author or user can't provide certain default styling such as a 
change in color, or providion of an outline, or whatever to indicate 
that a user can interact with it.  Even full knowledge of the elements 
and attributes used in markup to indicate that the elements are 
interactive is insufficient, since the interactivity of an element 
could be affected by whether a scripting language is enabled, whether 
the script is parsable or even whether a script is attached to the 
element via a mechanism other than an attribute.  No alternate group of 
selectors is sufficient for the purpose.  Whether this ability is 
called :hover or not, it is desirable to have it available.  

Perhaps an :event(x) pseudo-class to indicate that the element does 
something in response to event x would suffice.  :event(click):hover 
could be used for rules that apply to an element which has the pointer 
over it, and has an event listener for the click event.

Received on Tuesday, 3 June 2003 22:05:21 UTC