While I do, win7 XP under VirtualBox. It does NOT appear in “MultipleIE” or IE8’s compat mode – just part of why I trust neither. Fixed height trigger fixes it.
That’s the code from your most recent post… IE7, WinXP. STAIRCASE, caused BY the float!
Yes we have, and, well…
FLOATING the LI is what CAUSES it, height being the FIX for the staircase effect on floated LI.
Simple, when the element cannot be trusted to behave properly, particularly cross browser – hence the need for SPAN inside LEGEND and the occasional DIV around fieldsets when you have more than one fieldset… In the same way I’d be using extra spans inside the anchors.
Your latest code there being a perfect example of something I likely would never deploy… Why? Hover states.
-
Your version you’d have to hover on the LI if you want both images to shift.
-
You then could not trap :active or :focus for keyboard nav.
-
that code DOES staircase in IE7 here.
-
if trying to use overlapping sliding-doors on both sides, you couldn’t do transparency properly.
-
need for something like csshover3.htc for legacy IE when you shouldn’t need to.
There’s a reason I’d use a sandbag span instead of using nested elements. You missed the finer point of my statements – I object to extra elements that serve NO purpose… like 99% of the DIV people wrap UL’s in; sandbag elements are much more predictable and problem free so sometimes you do end up resorting to them… at least until border-image becomes real world deployable some decade or so from now.
It’s like that omitting the line-height metric and style/weight that we’ve gone around and around on in the past too, which ends up with the whole property ignored in 5.5, gives 20px in IE6 for christmas only knows what reason, and of course since it’s px metric fonts thanks to FF being a retard it ends up 1px taller than it does in the rest of the browsers, which is why if you’re going to use px fonts, use px line-height! (Gotta love how FF treats 18.2 as 19 or 18 randomly depending on how far from the top of the window it’s rendered!)
We keep going around on it because what you are saying is NOT even close to what it does here…
Oh, and you’re waiting to declare the font-size and line-height causes Opera on large fonts/120dpi to make the LI taller than the anchors.
It’s why for markup I’d be using the sandbag spans:
<ul id="mainMenu">
<li class="current"><a href="#">Home<span></span></a></li>
<li><a href="#">Partner Profiles<span></span></a></li>
<li><a href="#">Photos<span></span></a></li>
<li><a href="#">Careers<span></span></a></li>
<li><a href="#">Client Base<span></span></a></li>
<li><a href="#">News<span></span></a></li>
<li><a href="#">Contact<span></span></a></li>
<li><a href="#">Sitemap<span></span></a></li>
</ul>
Oh noes, not twelve extra bytes per line!?! (file that alongside the white-space stripping nonsense)
Since then you could do your hover states in all browsers without scripting assistance, can do transparency without whatever you put on the LI showing through, set the LI to inline so you don’t have to worry about the IE7 staircase CAUSED by float on LI, (Float is not the fix, it’s the CAUSE), and trap for keyboard navigators thanks to the :active and :focus states of the anchor.
It’s also nice because you can use the exact same markup to switch to gilder-levin if a re-theme requires full images instead of images as a background.
Which ends up something like this:
http://www.cutcodedown.com/for_others/designer/template.html
using a single image for both sides and all three states:
http://www.cutcodedown.com/for_others/designer/images/mainMenu.png
While keeping the CSS
http://www.cutcodedown.com/for_others/designer/screen.css
Reasonably simple despite the addition of state handler code.
… and working IE 5.0 through 9 Beta, FF 2 and 3, Opera 9.6 or newer, and the latest flavors each of Safari and Chrome.
Which your example code does not do here, giving me about six different appearances across that slate of browsers.
