Hey guys,
Really stupid question here…working on this site . For some reason IE decides to not treat the position:relative attribute on the #header ul tag normally. Is there anyway I can fix this bug without using conditional comments? Much thanks in advance!
Thanks,
Eric Huang
I am still unsure as to why you would like to lose the #header div completely? I am not trying to question your suggestions, I just don’t understand 100%.
I didn’t really see it doing much, and wherever you can combine elements, you want to do that as it reduces code and code complexity. I see a lot of this:
(inside body, #container div)
<div id="top">
<div id="header">
<div id="logo">
<h1 id="title"><a href="home"><img src="logo.png" alt="logo"></a></h1>
</div>
<div id="menuHolder">
<ul class="menuList">
<li><a href="home">Home</a></li>
... rest of page navigation...
</ul>
</div>
<div id="line"></div>
</div>
</div>
Having the logo as the h1 is questionable, esp without any actual title text in it (the alt text of the image, if it didn’t say “logo” might have been ok though), but the above is completely legal code. No validator will complain about it, and it will work in all browsers.
The CSS for it would likely also work, depending. There’s usually multiple ways of making the same look, but as you build web pages you start finding certain things make something break in someone (usually IE) so you start coding in a certain way that you know is friendly to all browsers. Anyway, you could do that with the above code, and have it work.
It’s just verbose, and makes maintenance more complex than necessary and could help introduce bugs that would have a harder time making their way into this:
(inside #container div)
<h1>Michigan State University <a href="home"> </a></h1><!--some Gilder-Levin image replacement here-->
<ul id="menu">
<li><a href="home">Home</a></li>
...rest of page navigation...
</ul>
...rest of the page...
Until CSS3 gets fully adopted by currently-used browsers, you won’t be able to avoid multiple containers when you want multiple background images, but in those cases those containers are known as “sandbags”. They exist pretty much only for that reason (holding images or borders).
Given that my audience for this website is extremely limited (no blind people, only people living in this dorm/on campus) do I really need to worry about screen readers?
My opinion is, writing for them is so easy, it doesn’t matter. But, to answer your question, if a blind student were to join (we’ve got a member here at SitePoint who is fully blind and has been in first a large college and recently switched to a smaller one as he switched majors) you (or whoever’s maintaining after you) would have to rewrite everything, which means unnecessary work (which is bad… good programmers are Lazy and Laziness in this case is a virtue). And it’s not like the blind are the only ones who will want actual content to read. Real text can be highlighted and copied. Real text can be made larger in a browser (images can be zoomed, but not all browsers zoom). And as I briefly mentioned earlier, not everyone is surfing with an excellent graphical desktop browser either, or use a mouse.
I’m not going to harp too much on it, and you may not consider yourself a professional web developer (maybe you’re just helping out the school because you have web skills), but I did feel it was my duty to point those things out, partially because as a computer user I’m very easily frustrated by sites I run into, which fuels my dogmatic evangelism for web standards and accessibility and all that. Above all, though, it should never be more work to write code that is valid and accessible, so I feel education vs ignorance is the only good reason why bad or inaccessible code even exists anyway.
Your code looks familiar. Is it based on Paul O’Brien’s? He wrote that trick with #outer and then a 100% background image who is actually an HTML image.
Oh, so all I really had to do was add a space in the css!? Jeez.
Did that fix it? Lawlz. Now you know why every developer hates IE. It’s not like we’re all a bunch of open-source-loving long-hairs who are Hatin’ the Man (M$). It really is a POS browser. We have some hope for IE9 though.
Okay, that’s some good feedback. I am still unsure as to why you would like to lose the #header div completely? I am not trying to question your suggestions, I just don’t understand 100%.
Given that my audience for this website is extremely limited (no blind people, only people living in this dorm/on campus) do I really need to worry about screen readers?
But your definitely right. I coded this really quickly without much though, cutting it down would probably help out everything. Oh, so all I really had to do was add a space in the css!? Jeez.
Having difficultly seeing what the problem is. Only thing I notice is that the Home menu option is not appearing in IE. This seems to be down to IE not using the background style for the selector .home a. The only difference I can see between it and, for example, the selector .history a is the lack of a space after the closing round bracket of the url.
This is a known IE bug. You can’t do stuff like background: url(somepng)left top… there needs to be a space between ) and “left”.
It doesn’t line up at all in my Firefox either.
I would see how margins could do the job better than positioning, and I would make the background images… background images. I’m not really even sure why you have background images on that menu. Do you really need whatever that font is on the menu?
Your whole setup is very much image-centric. Without images, your page is empty (with CSS on).
This is your page’s total content:
*
*
*
*
*
*
*
*
*
*
*
*
*
Copyright © 2010 Carroll Hall
Designed and developed by (you)
That’s not a good thing. Any blind students/staff at this school? What about search engines? Do the kids like to hook up their laptops or phones to some slow/busy wi-fi connection? Without images being able to load, there’s nothing for anyone to read.
As a developer, I see what I can do with the content first (so first the content, and then see where I can get with just margins, floats, background-colours… and then images on top of that).
You could possibly rid yourself of #header entirely. I know it’s offsetting the negative top margin of the whole page for the sticky footer, but you can also do those the other way:
(pseudo-code)
<html>
<body>
<outer>
<container/>
<footer/>
</outer>
</body>
</html>
html, body {
height: 100%;
}
#outer {
min-height: 100%;
}
#container {
width: 960px;
margin: 0 auto;
padding-bottom: 50px; /or a bit more, room for footer/
}
…
#footer {
position: relative;
width: 960px;
height: 50px;
margin: -50px auto 0;
}
Something like that would mean your top area could just be padded on the top by #container, leaving the menu nothing more than a menu. The ul can hold a single background image and you could then choose how you want to do the logo link.
Or for that matter, the convention of being able to click on the logo to get home makes little sense here, since the link right next to the logo is called HOME. However you could still do it.
For the menu itself, you don’t need the server to be asked several times for multiple button images. You can use a sprite instead.
There are a few ways to have your anchor text be actual anchor text (for search engines, for a user with a screen reader, for anyone without CSS or using a text browser or really bad model mobile phone).
One popular way is called Gilder-Levin. You’d add empty spans inside the anchors and manually position a different part of the background image for each span.
Or you could set the image as part of the background of the ul (merge the two images) with the hover/focus state sticking out the bottom. Overflow: hidden on the ul hides that part of the image. The anchors could be absolutely positioned over each word you see in the image (or just floated with set widths), and also call the same image (but just the part with the hover/focus state using background-position) to cover up that little part. The text itself could be wrapped in spans and hidden under the ul using z-index. There are multiple ways.
What’s important is that if images are off, there’s a contrasting background colour for the text, and the text that Does Stuff (like links) give some sort of feedback on hover and focus (don’t forget laptop users who don’t use a trackball). Your images can always cover up “ugly” feedback styles, while being useful for those without the images (again, tho, I’m not sure what’s special about the font in the images, but I’m assuming you’re definitely keeping them anyway).
Since your image called #bg is fixed positioning, it doesn’t matter where in source it is… so I’d put it last. The rest of the page can load and anyone with a crappy connection or some device that just can’t handle that giant image will have everything else loaded… those people can hit “stop” if they need to. Requests generally go in order of source.
I know I didn’t answer your specific question about why IE7 isn’t right (I don’t get anything lining up in any of my browsers actually) but I strongly urge you to try another approach with fewer elements, fewer individual images and then whenever you DO use positioning, try to keep it local (within some single particular element like the ul).
Also, don’t forget your title tag… some people leave it for last, then forget. Google “Untitled Document” to see how often people never get around to adding it back in later : )
