This page is generated by Joomla CMS (curse em), so I don’t know the width of the menu, the client may change the menu items. I didn’t notice that Matthew said that, but I generally try to avoid non-supported methods, I guess it’s about time to re draw the border on what to include in my development practice. Since we dropped IE6 support I can use inline-block.
If you use display: inline-block, you’d put that on the li’s and the ul parent would have text-align: center.
So here you could get away with not-floating the ul and giving it a 100% width (or something else to trigger Haslayout).
However IE7 doesn’t really support inline-block, but you can pretty much fake it with telling just IE7 (so, in your IE7 css sheet)
theUL li {
display: inline;
}
Basically, if you take someone who’s naturally a block (like a li) and set it to inline-block, IE less than 8 then has to see (later) that element set to display: inline. Then, what do you know, it makes the element look and act like original inline-block. Since you call the IE7 css sheet after the main sheets, that should work.
(note: the above is still true even though your stylesheet sets all li’s to display: inline earlier… IE still needs you to state it later! For IE<8, display: inline-block triggers haslayout alone)
Everyone else you support should just support it out of the box.
But it makes a lot of sense, directions is not really styling, so thanks a lot for the advice on that.
Yup, language direction isn’t styling, and either the link from Robert or some other W3C page mentions specifically Hebrew in an example and states “do not use CSS, such as floats, to change the order of the text”. This way, user agents who understand Hebrew are not reliant on the stylesheet to get the correct order. Also, smarter browsers (and no, IE7 isn’t one) can properly set up the page when the direction is set… like scrollbars and whatnot.
Re the CSS: it looks like you’re dealing with a template (which you are, Joomla!), so I can’t really properly b*tch about CSS for those because I believe they have way more markup than necessary, which makes CSS way more complicated than necessary. Something you just have to live with so long as you are using a CMS like that. And so long as it’s not making maintenance impossible or slowing your site down, it’s fine.
I’m not a fan of the ginormous resets, but that’s a personal opinion. Especially when I see lots of elements that likely don’t even exist on the page, or who are getting things zero’d that they don’t even have (for example, inline elements in general do not have any default margins or padding or borders anyway… so why waste parser time zeroing them out?). But, that’s just me and it won’t break anything the way you have it now.
On a table, if you already have border-collapse set to collapse, you don’t usually need to mention border-spacing (unless you want something other than 0). Mostly because, border-spacing I believe needs border-collapse to be set to “separate” anyway.
a img {border: 0;} <– bah, just set all images to border: 0. And be darn careful with that outline: 0. If an image is in a focusable anchor, what are you using to make sure keyboarders know they have landed on that clickable image?
body{
color:#fff;
font: normal normal normal 13px Tahoma, Geneva, “Kalimati”, sans-serif;
}
Whenever I’m trying to add a weirdo font, I’ll go ahead and put it first… it’s unlikely for anyone to have it installed, but if they do, but also have Tahoma or Geneva (way more popularly installed) your funky font still won’t appear because the browser takes the first one it can render anyway. Not even you will see the funky font, because assuming you have a Windows machine, you’re seeing Tahoma anyway. Which, btw, is a smallish font. I’d set it a bit larger myself, but that’s me : )
Also, the normal normal normal is usually unneeded (unless you’ve set all those things to something else earlier in your stylesheet??).
I also (again, personally) find it easier to find my styles for a particular element when everything is all together in one section and also if it generally goes in the order of the HTML (so body and wrapper stuff first, then header stuff, then menu stuff, etc…). Of course, eventually when you get to the middle each page may have different things, but I group them together as well. Then I find it later using my text editor’s search function (in vi I just type /thewordI’mlookingfor which works pretty well).
I’m also not a big fan of display: none in dropdown menus. I want that information available to me even if I’m using JAWS or some other screen reader (I suppose you could avoid this entirely if clicking on the main-link-item brought you to a page with all the sub-menu’s links anyway though). I like the off-screen method myself… tho I’ve never tried that with a page that could be served in both directions.
And, finally, I like having just one stylesheet mostly. I have started using a mobile/basic and then a desktop on top version, and of course there’s a print version, but my main desktop/screen css isn’t broken down into different sheets.
However this being Joomla! there’s probably a reason for it.
So anyway read the above as just my opinion, as someone who does NOT use Joomla! but writes everything by hand. And use the CSS validator to catch any actual syntax errors if you’re worried about that. There’s something called Dust-Me that can catch repeated styles, but I’ve never used it.
