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.
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.
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!
make an account (shiny button)
??? (shiny button?)
profit "
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
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
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
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.
@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.