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

Jerry Baker wrote:
> 
> Although I might be ignorant of some other purpose of which I haven't 
> thought, why can't named anchors be specifically excluded from :hover 
> and :active?

bz already answered this I believe.

> I'm probably preaching to the choir, but having a:hover and a:active 
> match named anchors seems as silly as allowing HTML comments to have 
> :hover and :active states. The two elements are identical in behavior 
> from the perspective of end users.

Not strictly true. It's entirely possible to surround some text with an 
<a name="">foo</a> - in fact, if it wasn't, this whole discussion would 
be moot because there'd be no pixel-space to hover over, and the hover 
state couldn't be activated. If it were possible to declare in XML/SGML 
that <a name> must be #EMPTY but <a href> doesn't have to be, then that 
would solve the problem too: <a name="">foo</a> would be treated as a 
badly-formed fragment with an empty <a> tag, then the text "foo", then a 
syntax error that would be ignored. And the hover state on the empty "a" 
could never be triggered. Unfortunately I don't think XML does allow 
that kind of element declaration.

What *did* occur to me though is that it would be possible for the 
default user-agent stylesheet to workaround these issues. For example:

a:not(:link):hover, a:not(:link):active {
   font: initial;
   background-color: initial;
   color: initial;
   list-style-item: initial;
}

Those are pretty much the only properties I can imagine that would get 
changed on :hover. And since "initial" for these is mostly "inherit", it 
wouldn't overwrite any styles the author did specify, unless they 
explicitly specified them in a way that would match <a name="">. I'm 
sure there are some obscure circumstances where it would be undesirable, 
but they're nowhere near as common as having a:hover specified in legacy 
documents.

You could solve the problem even more thoroughly by providing a 
mechanism in CSS for specifying "the value that would be obtained for 
this other selector" - eg:
a:not(:link):hover {
   font: equiv(a:not(:link));
}
Note though that implementing something like "equiv()" in the general 
case would be extremely difficult because you could create loops, or 
specify selectors that ambiguously matched lots of things. Another 
approach would be like this:
a:not(:link):hover {
   font: as-if-not(:hover);
}
which would probably be easier to implement, but almost as hard to 
specify the general-case behavior of. I also can't think of a way to 
specify that for *all* properties without explicitly enumerating all of 
them, within the general syntax and abstraction of CSS.

Stuart.

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

Received on Friday, 26 July 2002 11:27:10 UTC