W3C home > Mailing lists > Public > www-style@w3.org > July 2002

a:hover and a:active and named anchors

From: Jerry Baker <jerrybaker@attbi.com>
Date: Thu, 25 Jul 2002 14:39:13 -0600
Message-ID: <3D4061F1.901@attbi.com>
To: www-style@w3.org

Forgive me if this has been visited before. A cursory search of the 
archives turned up some fragmented discussion of the issue, but I did 
not see anything that looked like a comprehensive discussion of the topic.

The Case Against :hover and :active For All Elements (or Named Anchors)

The current CSS2 specification, and the current CSS3 "selectors" module, 
allow any element to have the :hover and :active property. That any 
element may have the :hover and :active properties applied to it has 
some consequences that were likely unintended when the specification was 
written. One effect that is likely to be the most common, and 
unexpected, is that named anchors are put into the :hover and :active 
states by user agents when the page author has assigned a:hover and 
a:active rules to his/her page. The CSS1 specification, and conforming 
authoring tools and user agents, have led to a historic use of a:hover 
and a:active to assign attributes to link elements (HREF). That CSS2 and 
CSS3 will now change the expected behavior will change the expected 
behavior of any page that uses these pseudo-classes with the intention 
that they only apply to actual href links.

The :hover state is a useful tool to provide visual indication to the 
user that an element accepts input from a pointing device such as a 
mouse, and the :active state is useful for indicating that a particular 
element is currently in the activation state. These visual indications 
are naturally intuitive to the user. That the pointing device activates 
an element (and :hover and :active are visual activations) naturally 
suggests to the user that the activated element accepts some sort of 
input from that pointing device. These properties are natural and 
logical cousins to the outline property applied to elements that will 
accept input as one uses the TAB key to navigate through a document, and 
to the "hand" that appears when a pointing device is placed over a link. 
Both the outline property and the "hand" cursor serve as visual 
indications to the user that some element accepts, or is going to 
accept, input.

One could argue that it is possible to set the outline property or the 
cursor property on elements that are not able to receive input. That 
argument is fundamentally different than the argument I am making 
against :hover and :active. To specify that a hand cursor appear over an 
element that does not accept input, and the same for the outline 
property, requires that the CSS author explicityly do so and be 
conscious of what is going to happen as a result. In the case of a:hover 
and a:active applying to named anchors, historical context will give the 
CSS author an expectation that is contrary to what will happen.

Although a strict interpretation of the a:hover and a:active rule would 
have them apply to <a name="name"> elements, it can be very effectively 
argued that they should not apply. Named anchors are a special cased of 
anchors that are both invisible to the user, and do not accept any user 
input whatsoever. They serve only as a position indicator for user 
agents, and have no bearing on the presentation or structure of a 
document. To the user, in effect, they do not exist. What ever could be 
the possible reason for needing, or wanting, a:hover and a:active to 
apply to named anchors?

Allowing elements that do not accept user input to have the :hover and 
:active states will negate any usefulness that these properties have had 
in the past in indicating the ability of an element to accept user 
input. Instead, the user of a CSS2 and/or CSS3 compliant user agent will 
quickly learn that :hover and :active states are not a reliable 
indicator of an element's ability to accept their input.


There are two potential solutions that are both logical and reasonable:

1) Specifically exclude named anchors from :hover and :active states.

2) Require that an element be able to accept input from a pointing 
device before allowing it to have :hover and :active states.
Received on Thursday, 25 July 2002 16:39:15 UTC

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