Re: a:hover and a:active and named anchors

Jerry Baker wrote:
> 
> I think you are misunderstanding me. I am well aware that named anchors 
> can contain text. I wasn't saying that :hover for them was silly because 
> they were empty, but because they are invisible, non-structural, and 
> unusuable to the end user. In the end user's world, they don't exist. 
> Much like a comment.

I'd say they're more like a <span>, in that they surround text but have 
no (user-visible) functionality of their own. Of course, <span> can be 
styled.

> A named anchor is a unique kind of tag in that it 
> is nothing more than the recipient of an event in a manner of speaking. 
> It doesn't orginate events, it doesn't have any effect on how a document 
> is structured, and, except for this silly behavior, it doesn't have 
> anything to do with the layout of a document.

All of these things apply to <span> also, and there's no reason <span> 
shouldn't accept :hover. The problem lies in two places:

1) HTML stupidly decided to use the same tag for two different things - 
link targets and links themselves - and distinguishing between the two 
requires looking at an attribute.
2) CSS1 did not define any way to look at an attribute value or any 
other way to specialcase the behavior of <a>s that are links and <a>s 
that are not. Thus web authors got into the habit of writing stylesheets 
that styled <a> in general, rather than say ":link" that was added 
later. I don't even know how :hover ever started to be a problem in this 
context, since :link was added at the same time as :hover and so 
:link:hover should have been the right thing to do from the start. But 
it didn't work out that way for some reason (poor advocacy? poor browser 
support?).

You'll note that both of these problems are *historical* problems, 
rather than problems that exist right now. <a name> is deprecated and 
CSS2 provided the :link pseudo. Thus, all of these problems only apply 
when dealing with code written by people who either don't *know* the 
right thing to do, who (for browser-support reasons perhaps) *can't* do 
the right thing, or who perhaps wrote the code 5 years ago before there 
*was* a right thing to do and have no intention of going through all 
their 5-year-old code and cleaning it up.

The aim is to find a way to solve the problem for legacy code without 
compromising the ability for authors working *now* to do clever tricks 
with :hover, and without specialcasing <a name> in a specification that 
otherwise barely even mentions HTML itself.

I've given a few proposed solutions in this thread. I don't like any of 
them very much, but I'm still hoping that somebody will come up with a 
good solution. A good solution IMHO would meet the following requirements:

- No special-casing of particular elements in particular doctypes or 
namespaces.
- Legacy code written as a:hover or a:active would apply only to <a 
href> and not <a name> (or more precisely, only to a:link).
- Future code could use :hover (and possibly :active, although I'm less 
sure about that because it's meaning isn't clear - does it mean "while 
the mouse button is depressed while over that element"?) to refer to any 
element without concern for whether it's one of a particular set of 
"supported" elements. This must even include <a name>, and ideally would 
include the ability to do this without any special extra work.
- Makes it *easier* for authors to use the new way than the old way. You 
could persuade people to go from a:not([name]) to a:link if you had 
occasion to need to, but you can't persuade people to go from a:hover to 
a:link:hover. Not even if there's a clear benefit. History, 
unfortunately, proves this. And "easier" is measured in terms of 
intuitiveness as well as character count - "hover" counts as easier than 
"hov".
- Makes it easy to write code that works correctly on old browsers, 
while still using new features (eg hover on generic elements) on new 
browsers. This rules out having an at-rule that forces the new behavior 
(although that was also ruled out by the previous requirement).

About the only thing I can think of that even comes close to meeting all 
these requirements is a new pseudoclass that behaves like ":hover" 
*ought* to behave, and also is less characters to type than "hover" is 
and is *more* intuitively associated with what "hover" does than the 
word "hover" is. Even then it'll be hard to persuade people to type 
:link:newword instead of a:hover - especially with the extra colon.

Since I can't think of any such word, and since even thinking of such a 
word is no guarantee that the solution would really meet all my 
criteria, I'm forced to conclude that the problem is unsolvable in any 
way that I'd consider "good", and keep looking for "acceptable hacks" 
like I've been tossing out in other subthreads.

Stuart.

-- 
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/

Received on Friday, 26 July 2002 12:49:59 UTC