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):
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?
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?
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)
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.
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)
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.
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.
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.