I’m finishing the web site design for a client, and as always I discover an IE-bug. This time it is IE 7 that refuses to behave.
This is the test site:
In all other browsers, the menu is positioned correctly, but in IE 7, and only in IE7, it starts above the right edge of the main area. I suspected it had something to do with the positioning of the logo with negative margins partly outside the main area (#side), but when I try to place the logo inside #side, the menu still starts on the right sides.
I am empty of ideas at the moment. Can someone give me a hint?
I’d try adding a haslayout trigger to #navigation – zoom:1 good as always…
Though your page is needlessly complicated given it’s appearance, and has some… structural oddities… that div#navigation for example serving no real purpose, the heading orders don’t make any real sense… you’ve got paragraphs around non-paragraph elements, extra DIV for nothing all over the place… and stating widths in places that to be frank… shouldn’t need widths…
Probably explains why I’m seeing three different layouts in the four major browser engines – and that’s before we talk the accessibility failings of declaring everything in PX.
Though NICE encoding on that background image – normally I’d list that as not viable for web deployment, but in this case that works good and isn’t disastrously large. Besides, I like raspberries.
I would also advise ditching that massive ‘reset reloaded’ nonsense for a bit smaller a reset.
OH!! duh… you’re in quirks mode because you have the XML prolog. Remove this from the file:
<?xml version=“1.0” encoding=“utf-8”?>
It’ll work fine. I would also advise AGAINST sending it as application/xhtml+xml since 1.0 doesn’t support the application extensions anyways, and it screws up in some browsers. text/html is fine, and don’t let any ignorant fool try to tell you that makes it “not be XHTML”…
Just to explain what I mean about all the extra code and problems with the layout, I’m doing a quick rewrite to show what I mean… I’ve already got the markup redone to be structurally sound without any extraneous elements – and to fix the semantics a bit since those images and text below them three across are NOT paragraphs – the text in the footer is NOT a paragraph – semantic markup is not about slapping paragraphs around anything that happens to be text…
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
lang="nn"
xml:lang="nn"
><head>
<meta
http-equiv="Content-Type"
content="text/html; charset=utf-8"
/>
<meta
http-equiv="Content-Language"
content="nn"
/>
<link
type="text/css"
rel="stylesheet"
href="screen.css"
media="screen,projection,tv"
/>
<title>
Melchiorgarden
</title>
</head><body>
<h1>
Melchior<span>garden</span>
<span></span>
</h1>
<ul id="mainMenu">
<li><a href="#">Heim</a></li>
<li><a href="#">Garden</a></li>
<li><a href="#">Gardsbutikk</a></li>
<li><a href="#">Overnatting</a></li>
<li><a href="#">Kontakt</a></li>
<li><a href="#">Booking</a></li>
<li><a href="#">Galleri</a></li>
</ul>
<ul class="selector">
<li lang="nn">
<a href="http://melchiorgarden.no/" title="På norsk">
<img src="img/no.png" alt="Norsk" />
</a>
</li>
<li lang="en">
<a href="http://melchiorgarden/en/" title="In English">
<img src="img/en.png" alt="English" />
</a>
</li>
<li lang="de">
<a href="http://melchiorgarden.no/de/" title="In Deutsch">
<img src="img/de.png" alt="Deutsch" />
</a>
</li>
</ul>
<hr />
<div id="content">
<h2>Velkomne til Melchiorgarden</h2>
<p>
Melchiorgarden er kjend som eige bruk sidan tidleg på 1700-talet. Garden ligg som nummer to frå sjøen på Dalesida i bygda Norddal. Vi driv med geitemjølkproduksjon og bringebærproduksjon og sel eigenproduserte varer frå gardsbutikken. Her er også råd å overnatte i tre nyoppussa rom. <a href="#">Les meir ...</a>
</p>
<ul class="trioPlates">
<li>
<a href="/gardsdrift">
<img
src="img/gard.jpg"
alt="Garden"
width="180" height="246"
/>
Garden
</a>
</li><li>
<a href="/gardsbutikk">
<img
src="img/butikk.jpg"
alt="Gardsbutikk"
width="180" height="246"
/>
Gardsbutikk
</a>
</li><li>
<a href="/overnatting">
<img
src="img/natt.jpg"
alt="Overnatting"
width"180" height="246"
/>
Overnatting
</a>
</li
</ul>
<h3>AKTIVITETAR:</h3>
<p>
Melchiorgarden er kjend som eige bruk sidan tidleg på 1700-talet. Garden ligg som nummer to frå sjøen på Dalesida i bygda Norddal. Vi driv med geitemjølkproduksjon og bringebærproduksjon og sel eigenproduserte varer. <a href="#">Les meir ...</a>
</p>
<!-- #content --></div>
<hr />
<div id="footer">
Melchiorgarden ·
Torunn Ljøen og Petter Melchior, 6214 Norddal ·
Torunn: +47 92626787 ·
Petter: +47 92283477 ·
<a href="mailto:melchiorgarden@melchiorgarden.no">
melchiorgarden@melchiorgarden.no
</a>
<!-- #footer --></div>
</body></html>
Taking it from 5.4k to 2.8k, almost a 50% reduction, and it looks good/sensible without the CSS, meaning screen readers, search engines and people on less capable devices won’t have as many issues with it.
Some other quick observations – TITLE generally shouldn’t go on images; it certainly shouldn’t be there if it’s identical to the alt text – there’s no reason to separate those images/anchors into separate elements… some hover states might make things clearer – and notice I added the LANG attribute to each of the languages; just to make it a bit clearer. LANG can go on any element – very handy.
I’m out for lunch, but when I get back I’ll belt out the CSS I’d be using with that.
Is open for easy access to the bits and pieces. Few minor changes to the markup since I posted above, and I took a few stylistic liberties (like separating out the footer). I didn’t integrate the webfonts – that’s something easy enough for you to add, just wanted to show how to simplify the markup and code. I used CSS3 box-shadows instead of the image backgrounds making it a bit more flexible – IE8 and lower doesn’t get the shadows, OH WELL… added a 1px border just to make the division clearer when the shadows don’t work… looks good back to IE7 with no layout issues… and is functional/usable all the way back to IE 5.5
Opened it up to be semi-fluid and to use dynamic fonts in the content area – that way large font/120dpi users don’t have to dive for the zoom or deal with broken layouts. I also redid the logo image so that it is the size it’s used on the page, so I could move it into the CSS since that’s presentation and to give a central unifying h1… important for CSS off appearance, as well as giving the entire page really good images off graceful degradation as well.
I’ve been away - that’s the reason why I didn’t answer earlier.
You give an interesting answer, and I it’s impressing that you use so much time in answering more than asked for.
I agree with you that the markup should be kept simple. But there are reasons behind my choices, and (some of them, at least) have a purpose.
The divs:
In the end, this will be converted to a template for a CMS. The use of elements and images will not be the same all the time. So all the divs inside the main content area will have the possibility to contain both graphics and text. The output from the text editor in the CMS will also wrap inline elements in the paragraph tag.
But I agree with you: There were some a couple of divs too much – also in my world of divitis. In the navigation section on top - it was a leftover from a previous design.
For me the use of divs also is connected to the flexibility I want to put in the markup so it is easy to change the design later.
Heading tags
I do not agree with you in your way of using the h1 tag to style the logo. In my opinion, the heading tags should be used for content, not for presentational elements, as you do when you style the h1 with the logo as background.
Title attribute
In my world it’s good practice to use the title attribute when images are links. You shouldn’t bother about hove they are used in my test page … it’s just that: a test page.
Image size vs. file size
When working with design, it’s much faster to change the size in the markup then to open the image in Photoshop each time you make a small change. The correct sizes will be applied in the end.
XML prolog
The XML prolog only puts IE 6 in quirks mode, not all browsers, and certainly not modern browsers. On the other side: It may not be necessary as long as there is no XML in the markup. W3C has as far as I know until recently encouraged the use of the XML prolog.
The mystery
Though your answer didn’t really meet my question, it made me rethink and rewrite parts of the css and html, and also remind me that it is important to have an extra eye on accessibility.
But still it’s a mystery why the menu jumped to the right side only in IE 7. And that was my question.
Nah, they trained IE7 to ignore the prologue, only IE6 goes into quirks from that.
The W3C is 10 years behind themselves.
You never needed the XML prologue. It was a suggestion, mostly for if your XML was UTF-16 or weirder (which you’re not sending to a web browser anyway). But XML worked in browsers who parsed XML with or without the prologue. Like a doctype, browsers tend to ignore it. Not sure about other software though.
Your server is conflicting with this content-type. It’s sending an HTTP Header of text/html, which is why your page appears in IE at all. If it really was application/xhtml+xml, IE would instead offer you the possibility to download this “file” with another application (on my work machine it would offer to open with Firefox
The charset you need because your server isn’t sending a charset. If it did, though, it would override your meta tag.
And… why state the page is English, when it’s Norwegian?
You later have the content-language meta tag with the correct language but it’s unknown if all AT actually read that tag, or if that tag is able to override the lang attribute of the HTML tag.
I do not agree with you in your way of using the h1 tag to style the logo. In my opinion, the heading tags should be used for content, not for presentational elements, as you do when you style the h1 with the logo as background.
Yeah the debate on who gets the h1 seems pretty evenly divided in the web world. Do what feels right here.
When working with design, it’s much faster to change the size in the markup then to open the image in Photoshop each time you make a small change. The correct sizes will be applied in the end.
Browsers are worse at resizing images than an image editor. And the larger files you ask us users to download. We managed to make a medium-sized page crawl and scroll choppily in most of our testing browsers on a home-rentals site by having the full-sized images be “thumbnails”, though yes these images were pretty big. Shrinking an image slightly is probably not going to crash the space shuttle and cause world chaos and war, but ideally once you know how big you want your images to be, shrink them in your image editor for the love of your users.
In my world it’s good practice to use the title attribute when images are links.
It’s a terrible practice, but to each his own. Steve Faulkner explains better than any rant of mine. There’s also Jakob Nielsen’s examples of how titles’ tooltips interfere with users being able to read the text of a dropdown, but that’s a different kind of menu. This is one of those things WordPress does by default and makes the accessibility nerds go into rage, lawlz.
If that information is important, try a caption. Those work even if the user doesn’t use a mouse (though there’s a way to display titles with CSS if the user can focus on the element… that’s fun to do sometimes).
But still it’s a mystery why the menu jumped to the right side only in IE 7. And that was my question.
I wish I had my box with IE7 on it, but looking at the code… you set something to position: fixed but didn’t explicitly state where it should go. Most browsers do the right thing and assume left and top, but IE in my experience has needed some extra coordinates, and that might be what’s going on here.
Does it fix itself if you add in “left: 0” to #topp? However I might be thinking of IE6 here… that same home-rental site I mentioned earlier had a fixed-position footer (always a bad idea since users can’t scroll if their screen’s not as wide as the fixed element… but we were stuck with it at the time) and one or some of the IE’s really wanted the whole shebang:
left: 0, bottom: 0, right: 0 and explicit width: 100% was all necessary. Again though this might have really been more for IE6’s benefit, who doesn’t do fixed anyway so I was feeding it position: absolute and often I need explicit left’s and right’s for those in IE6 as well.
But anyway can’t hurt to try it. Being a fixed element, what other elements do or what margins they haven’t shouldn’t be able to affect it at all. Like position: absolute, fixed elements are entirely out of the flow.
Never understood letting CMS output rubbish – probably why I’m not a wordpress fan; also why it’s likely on Roger Johannson’s Lame Excuses
Don’t let the tool force you into doing bad things in the markup for no good reason.
To me headings are about structure for the ENTIRE page; and since by definition a H1 is the parent for ALL other headings on the page (which is why it’s a bad idea to have more than one H1) – in this case you are lucky as the H3 looks like a subsection of the h2 – but if you had say… a news page of multiple equal weight elements, making the first one a H1 (which has become fashionable amongst the SEOtards) would just mean broken heading orders.
The IMAGE is indeed presentation – of the text it has inside it… that is the site title, of which everything on the page is a subsection. as such being presentation it doesn’t belong in the markup in the first place.
Also, take a look at how much better it gracefully degrades with images disabled.
Emphasis mine… If it’s a link, put the title on the LINK – the anchor. though you’ll notice that since I made them one giant anchor, they have the exact same text inside them – and there’s NO reason to put title on a anchor that has identical text inside it. Good rule of thumb, if you need TITLE on an anchor, there’s something wrong with the anchor’s content… if you need title on a image; you’re doing something wrong. (the only exception being when accesskeys comes into the mix, and that’s a Opera specific feature)
If it’s a image going into a IMG tag, that’s content; if you don’t have your content locked down before you start making the layout, you’re probably jumping the gun on making the layout – though that could just be differences in methodologies since again, the fixed width you were designing to is something I would never do to a website in the first place.
It’s also why yours fell apart badly images disabled, CSS disabled, and a host of other graceful degradation failures. You write the markup semantically BEFORE even thinking about layout – you didn’t have that. Paragraphs around non-paragraph elements, presentational image in the markup, title attributes on the wrong elements if you need title, out-of-order links for associated items, design elements that couldn’t handle text resizing or non-px fonts… There was enough wrong a silver-bullet fix would have been more duct-tape and bailing wire than seriously trying to help you… and as much of a fan of Uncle Red as I am, when it comes to the handyman’s secret weapon…
I’ve found differences even in browsers that allegedly don’t… so it’s not an exact science/answer or as simple as that. Hence the so-called “almost-quirks” you’ll find referenced on sites like quirksmode.org – I’ve had it mess up layouts in Gecko too, so…
Wondering where you got that impression from, since it’s in the XHTML compatibility guidelines NOT to include it, and to be optional in the normative part… I’ve not once seen it encouraged anywhere, unless you get into that HTML 5 asshattery.
If it wasn’t quirks, it was probably a haslayout issue, or a positioning bug – honestly what you had for a heading was so complicated I was guessing wildly as to what it was even supposed to look like.
BTW, I like the ‘staircase’ effect on the image links in your new version – though the padding/margin above that area really needs to be decreased. Also those px fonts and fixed width…arrgh.
So remember, if women don’t find you handsome, they should at least find you handy."
It used to be on the recommended doctypes page and I’m not sure when they changed that page but just one day, I went to show someone that page (maybe 6 mos ago?) and then realised the prologue junk was gone. HTML5 I don’t think ever encouraged it.
I don’t think either. The menu is in a position: fixed box, those get automatic Layout don’t they?
Anyway last night I booted up the box with IE7… and it looks the same as Chrome here, so… either audun fixed the problem, or I misunderstood what the problem was (I thought it was that IE7 started the HOME link to the right of the edge of the box called #side).
The menu was rendering pushed about 3/4ths the screen width across – and was causing scrollbars because of it.
Though I was seeing four different layouts in four different engines – hence why I was going “rewrite”. The version currently up has no layout issues across browsers - just accessibility ones.
The error was in the extra and redundant div in the navigation bar - when I removed this div and restyled the menu divs IE7 also rendered the page correctly.
I agree in a lot of the things written in this thread: I will stop using the xml prolog. I will never more use the title attribute where it is not necessary – because of the accessibility issues pointed out on the The Paciello Group Blog, but certainly not because some people don’t like the pop ups in some browsers.
I agree in not using fixed px-sizes on font sizes, and the final design has %.
If some people don’t like fixed widths I have no problems with that.
Listen, you get to a forum like this one and there’ll be a bunch of people willing to tell you all these things and blah blah… just take what makes sense to you and do what you do. It only makes you better, and you don’t have to agree with everything everyone says.
And remember that in the end, it’s YOUR website and despite what you are told here, you are never forced to take our advice. If you disagree with some of our opinions, so be it.
Now that you are done your final design, perhaps you can go to the review section of this website and ask for a review by the Sitepoint members :).
