My usual tactic for creating a roller image is clashing with my display inline option for some reason. I need a fresh idea on how to approach this:
48px x 200px
I need each div, li, a, etc to be 24px wide with overflow hidden (to hide the hover side of image) and set to inline right up against the others.
first off, pretend all those other tags don’t even exist - the ONLY tag you need for this is your anchor, maybe a span inside it. Set the LI to display:inline and pretend they don’t exist, get rid of any extra unnecessary DIV bull… SIMPLIFY! Honestly, trying to style the LI as anything but display:inline is probably 99.99% of your problem. Take rayzur’s example, stop trying to float the LI and set them display:inline. (well, except he’s nesting the spans instead of sandbagging so it still shows nothing images off)
Put the image as the background on the anchor, set the anchor to inline-block (and the two -moz equivalents) and set your dimensions, end of problem.
Though I would consider adding a span inside the anchor, putting text in the anchor so images off there’s something meaningful there, and then absolute position the span over the text - gilder-levin… Then you can make the span twice as wide and move the span instead of the background… This would let you use one image for all your hover items without the headaches of declaring/calculating the background-positions twice… (unhovered and hovered).
I did something like that just recently in another thread on a rewrite for someone:
http://www.cutcodedown.com/for_others/kp606/template.html
using this image, which is pretty similar to what you are trying to do:
The spans are double width, the anchor chopping off half. That way I only have to declare background-position once, and only have to trap “a:hover span” instead of “.home a:hover span”,“.students a:hover span” etc, etc.
In a few minutes if I have time I’ll toss together an example.
Doesn’t work in Opera or IE here. Apears to work in FF and Webkit though god only knows why since z-index should inherit off the parent element.
Well, that and last time I checked z-index:-1; doesn’t work properly in IE or Opera - sometimes being ignored, sometimes not.
In any case, it’s got the ‘jumping LI height’ problem in 7… which is why unless you are going to be having a dropdown menu attempts to style LI should be avoided at all costs.
Yes, your right! I forgot to put the width on the LI in my first post. 
Looking at your example:
I like the way you set the whitespace between the letters in the span and forcing them to word wrap. I’m going to borrow that one if you don’t mind. 
I have put together another version that uses floats for everything, even the “b” element. I am able to do away with the extra element that your example uses. You are using a “span” and a “b”.
It does come at a small cost to IE6 though since I am using li:hover b to change the BG color on my text element when images are disabled. IE6 will not get a BG color changing on hover but the anchor and replacement text is still functional.
See how this holds up for you!
Sprite Nav with Vertical Replacement Text
It works fine for me in all my browsers and I am using a single sprite image also.
#mainMenu span - the span just gets set to display:block and has padding added to push the text down a bit, and force it to word-wrap each letter. Lets us play with the positioning a bit while avoiding trying to declare width and padding at the same time (always a recipe for disaster)
It’s just a disaster in IE5 with the broken box model. There is no sense in catering to that browser anymore. I set a width and padding on my “b” to force the word wrap. I set a width because I floated it.
Take rayzur’s example, stop trying to float the LI and set them display:inline. (well, except he’s nesting the spans instead of sandbagging so it still shows nothing images off)
Well, with images off it works for me. Did you even try it or are you just speaking from a guess.
The widths are only necessary on the inner element when the outer element has a width of course. Otherwise if they are both widthless then it should be ok. (Apart from the right float in a left float bug (or the expanding float bug) as mentioned in the recent quiz :)).
I’m not actually sure to which specific example we are looking at now as I arrived here late 
IE7 can be a real pain in the ass about LI… you float their contents you get the staircase effect; you trip haslayout it has no effect while zoomfix often does, while other times using zoom causes more problems than it solves.
That is why we float the LI and anchors, it kills the staircase bug and whitespace bugs in dropdowns.
Setting the LI to display:inline tends to solve most of those issues, but leads you to the fact that you can’t position content reliably inside inline-level elements since their position is not calculated. (by the specification) meaning that fix is useless if you are going to have dropdown menus.
That’s why I use Inline-Block when I am not using a float. The only time I use display:inline on an LI is when it is just a simple list and the anchor needs no special attention.
I meant IE7.
IE7 can be a real pain in the ass about LI… you float their contents you get the staircase effect; you trip haslayout it has no effect while zoomfix often does, while other times using zoom causes more problems than it solves. LI can magically double in height for no good reason.
Setting the LI to display:inline tends to solve most of those issues, but leads you to the fact that you can’t position content reliably inside inline-level elements since their position is not calculated. (by the specification) meaning that fix is useless if you are going to have dropdown menus.
Which is where the train-wreck of:
li {
display:-moz-inline-block;
display:-moz-inline-box;
display:inline-block;
display:inline !ie;
}
Comes into play… but at least it works.
In any case, it’s got the ‘jumping LI height’ problem in 7… which is why unless you are going to be having a dropdown menu attempts to style LI should be avoided at all costs.
Okay, I see what you mean now. If I sandbag it like you mentioned then I don’t need to get into negative z-index.
>> ‘jumping LI height’ problem in 7…
7 what? IE7, Opera7
… and THANK YOU for explaining the missing bit of information on that… though it doesn’t explain why if I try his example I see the staircase in IE7. In a VM, native 7 under XP, and no it’s not set to LF/120. Oh wait, he didn’t set a width - well there’s your problem…
Though setting a width is rarely something I would want to do on either the LI or the A (though in this case the A was a must) - so that’s not exactly a great answer… a better answer would be “display:inline !ie;” since that basically gives you inline-block’s behavior in IE anyways… IF you want inline-block’s behavior.
But it seems like you guys use a LOT of code that on my machine is just plain broken across multiple browsers - using techniques I wouldn’t even be LOOKING AT in the first place.
Uhm, floating both is usually what CAUSES it last I checked.
That or floating the content while leaving it display:block; - BOTH usually cause it without a lot of extra chicanery. NEVER seen adding float to the LI do anything but cause even more issues than it solves.
NEVER seen adding float to the LI do anything but cause even more issues than it solves.
Floating the list and the anchor always kills the whitespace bug and I use it all the time. The only drawback is that you then have to define widths which is a pain where padding and borders are concerned and you also have to make sure that clearing issues are taking care of just like you would with any float.
Setting the list to display:inline works in most simple cases (but not in Stommes recent drop down thread where the only solution was to float the list and the anchor) but then you lose the extra security of the haslayout fix that float imposes and you also lose the ability to have the current menu item not being an anchor without having to add extra mark-up - not to mention losing the value of one extra hook in the mark up.
All in all I recommend floating both for a full-proof solution but I accept in some cases there may be alternatives.
Ah ok -thanks
(Increasingly I’m spending more time working around gecko’s shortcomings since they’re less well documented than IE)
And nowhere as easy to hack for.
Behavioral fix for IE6 - background-color will often render larger than the line-height when padding is unset, just as border-bottom will sometimes fail to render on inline-level elements.
All of them I have in there are because they’ve caused a headache at one point or another. Some of them are NOT even for what margin/padding actually is supposed to do… take DIV - which setting margin:0 prevents earlier gecko versions from treating SCRIPT tags next to DIV as block-level containers. (damned If I know why).
Way to go IE and Gecko being Nyetscapes sweetly retarded cousin. (Increasingly I’m spending more time working around gecko’s shortcomings since they’re less well documented than IE)
Hi Ray,
Yes word-wrap:break-word was only introduced in opera 10.5 unfortunately.
I don’t even see why the <div> element is in there considering it has absolutely no browser defaults (in any browser) by default 
May I ask why do this
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
margin:0;
padding:0;
Who knows? Of all those elements being listed where padding is set to 0, only a few even have it: ul, ol, and in Firefox th and td have 1px padding (which you don’t see 99% of the time… I get hit with it doing calendars with small td’s). No inlines have default padding that I’ve seen.
as opposed to simply
* {margin:0;padding:0;}
Hi Kyle,
That is the universal selector and it grabs every single element in the document that has a default margin/ padding on it and zeros them out. The problem with using it is that it can be harmful on form elements, when form elements are zeroed out it is impossible to reapply them in most cases.
The first example is just grouping specific elements together and zeroing them out. The form element is included but that is just the form container, not the inner form elements such as inputs.
There is a dedicated thread that you might find useful as it goes into much detail about the subject.
CSS Resest
Where do we actually use * { margin:0; padding:0;}
Wow, this really evolved and I learned serveral new things.
Yes, we went off into some different topics
We apologize for hijacking your thread, one thing led to another through various comments in our posts. We try not to take member’s threads off topic but it happened in this case because there was only one reply back from you. I think we may be done now, you never know though.
It SHOULD if the float is cleared appear next to the first one. CLEAR should NOT be overriding margin’s behavior.
The specs state this:
Clearance is introduced as spacing above the margin-top of an element. It is used to push the element vertically (typically downward), past the float.
That means that whatever the margin top of an element is then space will be added above that until the element is pushed past the float. I believe typically that browsers effectively increase the margin-top to achieve this effect although it may be done by some other internal means. The net effect is the same and the element must clear the float.
If we reverse your example and apply a positive margin to the cleared element then it doesn’t move anywhere either (except in buggy IE6).
.float {
float:right;
width:200px;
height:100px;
background:#0F0;
text-align:center;
}
.clear {
clear:both;
width:200px;
height:100px;
[B]margin-top:50px;[/B]
background:#1AF;
text-align:center;
}
This is the fact that the margin-top has already been increased by the browser to clear the float and if you set it to margin-top:50px then that will have no effect because it already effectively has a margin-top of 100px (the height of the floated element). Only when the margin-top is greater than 100px will it take effect.
I’m not saying either behaviour is desirable but just the way that it works (in most browsers)