SAFARI not registering a:hover

HTML & CSS
1

I came across this by accident. At first I thought it may be conflict in rules but I made the following test ( with both strict and transitional doc types):

a:hover{display: block;background: pink; color:red}

<ul id=“nav”>
<li><a href=“#”>Home</a></li>
<li><a href=“#”>About</a></li>
<li><a href=“#”>Clients</a></li>
<li><a href=“#”>Contact Us</a></li>
</ul>

An Safari was the only browser that did not turn each anchor into a block element, with a pink bg and red text color. ( yes in fact, Safari ignored all declaration made in the {}). Adding a new rule a{display:block} fixes everything!

so my question is: is this a bug in safari, or is it that you cant change teh display mode of an anchor when hovered and all other browsers are being generous?

2

Hi,
As your code stands right now your anchors are changing display values on hover. That is never a good idea.

As you may already know anchors are inline elements by default and that is the mode they are in with your code when they are not in the :hover state.

You would be better off to set them as blocks to begin with.

a {display: block; background:#FFF; color:#000}
a:hover{background: pink; color:red}
3

Ray,
you are right… but I was concerned aboput the concept of changing display modes on pseudoclasses.

if you used li:hover{display:none} safari would not recognize that rule either ( yeah, it’s kind of useless since it would cause a weird blinking effect. ) But that why my question is if it’s not only UNWISE but IMPOSINBLE to change display: modes on :hover in some browsers or if it is part of standard CSS behaviour?

4

Hi,
It’s not impossible, and css does allow it. Your not going to find anything in the specs that will say that changing display values should be supported as normal behavior. I would see that as a gray area that browsers can render as they see fit.

As you noticed FF was ok with it where Safari was not, that is the reason why it is not recommended.

I was playing around with some more scenarios and found some other strange behavior in Safari.

Safari is ok with this when the display value changes via li:hover - (still not recommended)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>demo</title>

<style type="text/css">

[B]a[/B] {[COLOR=Blue]display:inline;[/COLOR] background:lime;}
[B]li:hover a[/B] {[COLOR=Blue]display:block;[/COLOR]background:pink; color:red}

</style>

</head>
<body>

<ul id="nav">
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Clients</a></li>
    <li><a href="#">Contact Us</a></li>
</ul>

</body>
</html>

This throws Safari in an endless page load after an intial hover -

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>demo</title>

<style type="text/css">

[B][COLOR=Black]a[/COLOR][/B] {[COLOR=Blue]display:none;[/COLOR]}

[B]li:hover a[/B] {[COLOR=Blue]display:block;[/COLOR]background:pink; color:red}

</style>

</head>
<body>

<ul id="nav">
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Clients</a></li>
    <li><a href="#">Contact Us</a></li>
</ul>

</body>
</html>
5

After reading through The dynamic pseudo-classes: in the CSS2.1 specs I find this -

CSS does not define which elements may be in the above states, or how the states are entered and left.
 Scripting may change whether elements react to user events or not, and different devices and UAs may have different ways of pointing to, or activating elements.

CSS 2.1 does not define if the parent of an element that is ‘:active’ or ‘:hover’ is also in that state.

User agents are not required to reflow a currently displayed document due to pseudo-class transitions.

6

Ray,
yeah, I notice that safari WILL obey the rule if its not directly. Which is why I came to the same conclusion the issue was not about changing the display mode but about the pseudo class. which is… odd. I shall tack it up to vendor prerogative. Blast!

BTW,
it’s funny that you it should not be recommended to change display values, because, with the eception of going from inline to block it is essentially the same basic process which is commonly used for a drop downs and symilar effects ( going from display:none to display :block)

7

I think the issue is mainly that re-flowing the page on hover is not normally a good effect because all the content on the page may jump and as pointed out by Ray the specs say browsers don’t have to reflow anyway.

Safari does seem to have bugs with hover though as documented in the Sitepoint reference here.

I’m not keen on phrases like “User agents are not required to reflow” because that just leaves it open to interpretation and you get descrepancies like those shown above.

8

Hi,
Most of us around here do not recommend using that for dropdowns either. There are accessibility issues when doing that, screenreaders are not able to tab through the links of the sub ul.

Whether it is a dropdown or any other element that is revealed on hover it can be hidden off screen with a large negative margin and then revealed on hover with margin:0;

By doing that along with setting it as position:absolute; the sub ul does not push others around since it is removed from the flow.