I want to display 3 blocks of content (teaser-images w/ text) in a straight line across the page.
I looked at Veerle’s blog which has a similar layout (try and guess what I’m talking about - the top navigation)…the way that she does it is with a UL.
Is this how I should do it?
Thanks.
~TehYoyo
Because it’s technically a list of items, an unordered list is a reasonable option, yes. But personally, I think a series of divs is just as appropriate in a case like this. See which looks better with CSS off. To me, the div option is cleaner in that respect.
She has it, link you say in a unordered list like this…
#nav ul {
text-align: left;
width: 976px;
}
#nav ul li {
display: inline;
float: left;
height: 75px;
margin: 0;
padding: 0;
}
Which does work, but as ralph said above, it’s a list and should therefore be a block, not inline.
I agree on using Div’s
It depends, and that’s a very fairy-waffle-flop-politician “depends”.
I’d use a list if it really is a three-step process, as a lot of sites have that.
"It’s easy, just three simple steps!
That makes sense as a list.
However when I did the front of scooterverzekeren.com, I decided not to use a list but three divs, because while there kinda is an order with those actions, they are not absolute: someone can start with the 2nd option (just buy an insurance policy) and skip the “get a quote” option that’s #1. Or maybe you came to the site and you already have a policy? Then go directly to #3 (report damage).
So even though logically a person would 1. get a quote and then if they’re happy 2. buy a policy and then after they wreck their scooter do 3. report damage, but realistically it was more sensible to offer three, somewhat-independent choices, thus three divs.
Now, looking at the veerle blog, an unordered list seems also okay. Like, “here’s a list of stuff I do” (list). That’s also okay, I think.
And btw they are inline-block. This allows them to stay centered even at smaller screen resolutions, although I do think there’s a width where they look pretty stupid. I probably should have forced them to stack straight down under a certain width, but I didn’t want 500 different @ media queries… more HTTP requests didn’t seem worth it
oh but inline-block on blocks no worky worky on FF2 engines if you are still supporting those
Stomme,firefox 2 may not support display:inline-block but it does support display:-moz-inline-box. Does the same thing really :).
Ryan: nope. Or, not beyond a simple case:
There’s -moz-inline-box and -moz-inline-block, and they are both different in horrible ways (especially if you thought you wanted to do something like Gilder-Levin with them… one allows a rel-po’d block-to-inline-block but then can’t remember where to put the abso-po’d kid, the other can but then you lose inline-blockness and instead you get a dimensionless inline…). But both of them are extra retarded if your blocks-to-inline-blocks have inside them more blocks. FF2 hates block children of inline-blocks, and this means to get around that you’ll have to add more children and make them inlines and their children inline-blocks etc until all the block children (and their children, and their children’s children) are taken care of.
Because of that, I actually didn’t even add the -moz-inline-block/box to scooterverzekeren, because the way the text stacked up over itself made it unreadable… as it is now, everyone hugs the left side of the page but at least is readable 
Hmm, well it’s still worth a shot…I did not know about the issues you mentioned but it still could be feasible to use depending on his layout.
If all the children inside the blocks-to-inline-block are inlines, you’re cool. So you can -moz-inline-block/box some li’s if they just have text in them. Add some <Hx> and some <p>s tho and now it’ll get all uppitty
I have three boxes that are able to stand on their own, separately. It’s not a list, I just want them inline.
~TehYoyo
Note: I skipped over your 2nd post, Stomme poes…was there anything important that would be easy for me to understand?
Unless you want to know about the history of how FF2 supports “fake” inline-block, don’t bother trying to understand what she said ;). I had to reread it a few times, so many uses of “inline” and “block” lol.
You have a few reasonable choices available, such as float, display:inline-block or display: table-cell. Of these three three, float is most reliable, but more and more I’m using inline-block, now that I care not a whit about Firefox2, IE7 etc.
[ot]
It was like Drupal code man, class=“block clear block-block clear-block…”[/ot]
Ralph: IE6 and 7 obey pretty well on my inline-block setup.
I’ve lost track of what that is.
Ie 6 and 7 are fine as long as you set them to display inline first.
Yep, that one I’m familiar with. Not sure if that was what poes was referring to.
I dont know why you dont just use FLOAT… but
have you considered this… if you absolutely need “inline-blockiness”
.element {
display:-moz-inline-stack;/* for older moz*/
display:inline-block; /* for newer and compliant UAs*/
}
within a conditional comment for IElte7:
.element{
display:inline-block; /* for newer and compliant UAs*/
zoom:1;
display:inline;
}
or you could use a * hack to add the IE part, but we hate hacks here… so.
Hope that helps
I suppose floating would be just floating (as normal) and then spacing with margins?
~TehYoyo
Yes indeed.
Great. Thanks for the help.
~TehYoyo
@Dreseden: I tried inline-stack too on my setup (scooterverzekeren.com) and there was no good response. I had tried ALL the -moz display properties I could find over at Mozilla before finally deciding that FF2/K-Meleon users were just going to have to suck it up and read text aligned totally to the left of the page
On my portfolio, I set some divs to inline-block (and -moz-inline-block) which was okay until I needed to abso-po an h2 inside. Because -moz-inline-block (unlike -moz-inline-box!) cannot keep track of inline-blocks as positioned ancestors, the h2 was totally in retardation space. I unhappily decided to hack that with
/*The following attempts to make FF2/K-Meleon readable. If it breaks later Firefoxes then remove*/
/*FF2 display: inline-block like display: inline can't support abso-po'd children*/
h2, x:-moz-any-link {
position: static;
}
/*FF3+ can*/
h2, x:-moz-any-link, x:default {
position: absolute;
}
So, FF2 can haz inline-block divs but the h2 remains static, while FF3+ gets a positionined h2. Meh. These same hacks were on the same mozilla page as the inline-stack etc stuff. All testing was done in K-Meleon in case there were differences among the FF2 engine.
TehYoyo: only reason I used inline-block instead of floating, really, was because I wanted my blocks to be centered. With inline-block, the parent of the divs can haz text-align: center and they’ll magically center. To do this with floats, you’ll have to have a parent wrap the floats and be about as wide as the floats are and margin: 0 auto’d to center. This is totally fine if your page is fixed width, but mine was a responsive design and had to keep things centered even if the floats/blocks had to drop down underneath each other. With a fixed-width centered container holding floats, you’ll necessarily get a scrollbar.