I am currently designing a site, which I just realized using google analytics that over 75% of visitors are using IE6. When I tested how the site appeared in IE6 the layout is messed up, the navigation moves to the far right and the main content gets pushed down leaving a huge white space on the left. Site - www.womens-health-clinic.co.uk To Test in IE6 - http://ipinfo.info/netrenderer/index.php I've tried putting "display: inline;" inside the navigation css code and the main content code but that hasn't made any difference. Also is there a way that the site can detect what version of internet explorer a visitor is using and prompt them with a warning to update their webbrowser or use another.
You could use javascript to issue you a warning, but people who are using ie6 aren't likely to upgrade because of a notice on your site. You should use a conditional stylesheet that is used only for ie6 visitors that corrects your display issues. Something like this in your head: <!--[if lte IE 6]> <link href="css/menu_ie6.css" rel="stylesheet" type="text/css" /> <![endif]--> You then create a second stylesheet that will correct the ie6 issues.
I would suggest downloading ietester and then working with the ie6 css file to correct whatever issues you are having. http://www.my-debugbar.com/wiki/IETester/HomePage
1) do NOT fall for that IE conditional comment and separate stylesheet nonsense. 2) Your layout is also broken here in Opera, IE7 and IE8, mostly because the design uses a bunch of fixed height containers with fixed height images and DYNAMIC fonts, so it's going to be broken on ALL large font/120dpi systems. 3) Tables for layout, presentational markup, non-breaking spaces inside paragraph tags instead of just using padding, nonsensical heading orders, clearing breaks/div's, images for text with no fallback content, and a nasty case of classitus means it would be a miracle trying to narrow down just exactly what is breaking. Given I'm seeing four different appearances in four different browsers here, it looks like it's all breaking. Though at least you have VALID markup. As I tell many people, it would be faster to chuck it and start over clean with semantic markup and separation of presentation from content than it would be to try and throw endless silver bullet fixes at it. Between axing the tables, cleaning up the markup, opening up the subsections to actually scale to their contents, and in general just bringing the markup into THIS century is enough to say it's faster to pretend the code for the existing page doesn't exist, and start over clean.
Wow thanks for your reply, I'm a newbie to css this is actually my first attempt at making a css site from scratch. I guess I will have to go back and just use dreamweaver's templates if thats any better? Those seem to not be affected by the IE bugs =/ I have a few questions (pretty much everything) regarding your post if you don't mind answering. Are you saying not to use the "<--[IF IE]>" command? What is the best practice, I have noticed that the dreamweaver template use this. From data I have collected my visitors or IE6, IE8 and Firefox, the amount of visitors that use other browsers is less than 3% so my energy will be aimed on those using IE6,8 and Firefox. When I checked the site using IE7 it looked fine, pretty much exactly like firefox. What do you use to test browser compatability? Why is fixed height images a bad thing? And "dynamic fonts" this is where the site tells the browser what font to use correct? I've set it to verdana, why is this a bad thing? I'm a beginner so this really has just flown over my head lol. I've only used tables for that one section on the main page, and for the email form, mainly because thats how the software creates the forms. I'm not too concerned with perfection here, if 1 or 2 pixels are out of place in different browsers I can live with that for the time being. What did you mean by "non-breaking spaces inside paragraph tags instead of just using padding" and "nonsensical heading orders". "Clearing break/divs" - from what I've just googled it seems that anything that I want to place next to each other I should just use SPAN instead. Is this what you are talking about? "images for text with no fallback content" - I'm not quite sure what you are saying here, are you refering to the header, where I have the "home, clinics, and contact" buttons? Could you explain more by what you meant by "no fall back content"? "nasty case of classitus" - Yeh I would agree, it was getting kind of confusing for me keeping track of what each class was for. I know I've over complicated things. Any suggestions how to avoid this trap again? I have found a workframe called CSS Blueprint, do you know it? Thanks again for your advice!
The most problems are coming because IE does not treat the CSS boxes in the normal way in fact the opposite. The way out is to use the margins and set up padding (and border) to 0. It has also problems with the default fontsizes so the best is to define your fontsizes for p,..... Also set ut everything explicitely for the body and html balises and do not use tables for display.
I have removed the table in the main content box. I have defined the font size for P aswell. I will see what happens when I alter the margins. thanks
Has valid strict doctype with nothing before it, IE6/newer is not in quirks mode so the box model issues should NOT be a concern - unless you still give a **** about IE 5.x... so basically that has NOTHING to do with what's going on here. The ONLY thing you can learn from dreamweaver is how not to build a website. My advice, stay away from that steaming pile of manure. If this is your first CSS from scratch then you actually did really well all things considered, you just have not gone far enough down the path in terms of semantic markup, separation of presentation from content, and accessability norms - which stands to reason since the number of tutorials or books on the subject can be counted on one hand, with the majority of resources being a decade behind how it's supposed to work. The only stupid question is one you already know the answer to. The best practice is to use code you can send to all browsers. MOST of the quirks you need to correct for in IE6 or 7 tends to fall into three categories: Haslayout IE will incorrectly render positioning of elements as a layout changes during load. Tripping haslayout (easiest ways being giving an element height, width or zoom) fixes those - simple fix safe to send to all browsers, so you don't have to bloat out your markup with it. Double Margins IE6/earlier will often double the margins on a float. Floats are inherently display:block and no browser will obey display:inline on a float - but for some reason display:inline trips something in earlier versions of IE that fixes the margin doubling. Missing Properties A lot of really useful CSS2 or CSS3 properties are just outright missing, or handled incorrectly. For the missing ones like min-width or min-height, you can use 'expressions' - javascript in your CSS, to implement them. While 'invalid CSS' so long as you know WHY it's invalid you can ignore the error. As I've said several places invalid CSS is pretty much going to happen, the rules of CSS even allow for it... But there is no excuse for invalid markup. For the handful of instances where it's incorrectly handled, the problem is most always IE6/earlier so I use the '* html' hack to handle the corrections (height for min-height for example). This gets it out of the markup saving bandwidth - the same CSS file across multiple pages on a website is cached, markup is not, so anything you can move out of the markup to the CSS is a good thing - the real reason I hate seeing that <!--[IF lte IE7]--> malarkey. That's a big mistake given that FF is over 30% of potential users worldwide and has according to some numbers broken 50% penetration in europe. Also if your page isn't working right in those browsers, what makes you think you can trust your user numbers for it? Of COURSE they are low. I test in IE 5.5, 6, 7 & 8, FF 2 & 3, Opera 9.64 and 10 Beta, and the latest iterations of Safari and Chrome. All those browsers are free, you can usually find a way to run all of them (I'm on win7 RC right now, so I run 5.5, 6 & 7 inside Sun VirtualBox) on most any platform, even if you have to run a VM to do so. The images themselves aren't a bad thing if used properly, but a fixed height BACKGROUND image will break if you combine it with dynamic fonts, becuase large font/120dpi windows users will have the text blow past the bottom of your images since for them, dynamic fonts (font size attribute in markup or %/em/pt sizes in CSS) are automatically 20% larger. Your page is built around elements of a fixed height, so on large font machines your layout is broken. This is why you see websites with a lot of tiled backgrounds and not a whole lot of sites using fixed backgrounds with fixed-height elements. This is what your page looks like on my machine in Opera, IE 6 & 7 are similarly plagued by the font size issue. incorrect. Dynamic fonts refers to the metric in which you declare your font sizes - dynamic fonts (%/em when based on default, or pt) automatically enlarge 20% on large font/120 dpi systems. This is a good thing since it gives end users with higher resolutions displays legible sized fonts, while it also gives people with poor vision the option to have JUST the text auto-enlarge... So you want that... A lot of designers sleaze out and use px sized fonts for everything, which is an accessability /FAIL/ unless you are doing things like 24px or larger. The trick is to use PX where you HAVE to for image interactions (menus or behind glider-levin image replacemnents are a great example of this) and %/EM for all 'content' on a page. Oh, on the subject of fonts, your default sizes are too small even WITH the auto-enlarge being well below accessability minimums. 75% of default or 12px is the smallest one should consider going, and I get twitchy below 85%/14px. I have to zoom in another 30-40% to make the page legible for me. Given your target audience is women in the fall of life, absurdly undersized fonts are not exactly something that should be on the menu. Don't feel bad, it's a lot to digest, and we've all been there. What software would that be? A lot of off the shelf software generates markup I'd not consider suitable for wiping with, so you may need some tweaking there. Properly made forms tend to have these things called FIELDSETS, LEGENDS and LABELS. There are a lot of improperly made forms out there - net result being an accessability /FAIL/ for people using screen readers or other alternative devices. Multiple places in the markup there's <p>&nbnsp;</p> - yet I see no double-spacing on any of the paragraphs. Those should be removed and either padding or margin set at the bottom of each paragraph. I actually like to put 0.5em padding the whole way around my paragraphs instead of margins - spaces out nice and even from the edges and gives you 1EM (slightly under the line-height) between paragraphs. Basically it's a bunch of wasted markup for what should be a line of CSS. Heading tags (H1, H2, H3, etc) are some of the most misunderstood and improperly used tags out there. Headings in a document should 'fan out' like a tree giving structure to the content. There are some simple rules to using headings... 1) If you use a lower level heading (h5 for example) it should be a subsections of the heading before it (a h4). It is improper to 'skip' heading levels. People screw this up all the time by using H5's as headings in their sidebar for example - not only skipping a whole bunch of heading levels resulting in a document structure that makes no grammatical sense, but meaning it's a subsection of whatever heading preceeds it which is most often NOT the case. 2) Every page should have at least ONE H1, and no more than one H1... and all other headings on the page should be SUBSECTIONS of that H1... This is why I tend to use the H1 for my site title/logo, since rarely do I have any other heading elements that would fit the bill. Some SEO experts will make comparison to a newspaper saying the big most important headline on the first page should be the H1 - this is pure nonsense since that would make every other headline on the page subsections of the first. Ehh.. no. "K-5 gets new school" would not be a subsection of "MAYOR CAUGHT TAKING MILLION DOLLAR BRIBE" - at least you hope not. What they miss is that every 'page' of the paper has the title of the paper atop it - that's your h1. All that is different is how it looks - looks? That's presenation, presentation has NO PLACE IN MODERN MARKUP. No, what I am referring to are things like this: <br clear="both" /> - which the site had yesterday, I'm not seeing them now. A similar bit of sillyness is the so called 'clearfix'... It's used to clean up float behaviors and has not been neccessary since in standards compliant browsers all you have to do is set an overflow state on the parent element (or float with 100% width) and for IE6/earlier trip haslayout. Two lines of CSS is always better than adding ANYTHING to the markup. Not just those buttons, but the contact info in the header, the site title, etc. There's a technique called 'glider-levin' image replacement that allows you to put an image OVER actual text. The advantages to that approach is you get fallback text for search engines, data scrapers, screen readers, or just for people visiting with images off - like people still on metered plans or dialup - don't let people pack you full of shit and say "everyone has broadband" - tell that to the people in upstate NH, VT and western ME, or the Dakota's, where 33.6 is a GOOD day... or the folks down in Oz or places in the midwest were sure, they have broadband, but they use over a certain amount and they get billed extra for it. Images like that are a presentational affectation of the text... Presentation? That goes in the CSS not the markup. Fallback content goes hand in hand with another term 'graceful degredation' - not every visitor (even using IE) is going to have every 'ain't it neat' feature turned on. The two terms refer to how well a site handles it when certain things are turned off. Semantic Markup would mean that when CSS is turned off, the site is presented in a simple outline format becuase the right tags were used for the right elements (headings for headings, paragraphs for flow text, img with alt text for content images, presentational images like borders NOT in the markup) and the wrong tags are not used anywhere (tables for layout, div's instead of fieldsets, div, span or B instead of headings, etc, etc). It also means that the page is still usable with javascript disabled (not a concern for your page I don't think) or even something as simple as the user turning images off. The Opera browser includes a quick and easy way to see how well a site handles stuff disabled, View > style > User mode. When we do this on your site we get the nice lists for the lists, the 'box_' elements aren't too bad (though I think the anchors should be inside H2's) - but you have no site name, the contact information (also an image) is nowhere to be found, etc, etc. The big trick is to 'group' like elements, that's what DIV's are supposed to be FOR. Take your .news class that you use ten times in a row. I would either add a wrapping DIV called 'news' and target the H4 (which should proabably be a H2) and P tags off that - or since that is all that is inside #lowercolumn, you have a perfectly good hook right there. "#lowerColumn P" and "#lowerColumn h4" letting you axe every iteration of class="news". You find yourself declaring the same class more than once in a row inside an already named container, get rid of the classes and target off that container. THAT SAID, I do have to say it's refreshing to see someone using classnames that say WHAT the elements are. Too often you see pages with classnames like "Left" or "bold" - defeating the entire POINT of using CSS in the first place. You'll often see things like: <ul> <li class="menuItem"><a href="#" class="menuItem">Item 1</a></li> <li class="menuItem"><a href="#" class="menuItem">Item 2</a></li> <li class="menuItem"><a href="#" class="menuItem">Item 3</a></li> <li class="menuItem"><a href="#" class="menuItem">Item 4</a></li> <li class="menuItem"><a href="#" class="menuItem">Item 5</a></li> </ul> Code (markup): If they are all the same and have a common parent container, what do you need the class for? <ul id="mainMenu"> <li><a href="#">Item 1</li> <li><a href="#">Item 2</li> <li><a href="#">Item 3</li> <li><a href="#">Item 4</li> <li><a href="#">Item 5</li> </ul> Code (markup): functionally identical and a heck of a lot less markup. You just target "#mainMenu li" instead of "li.menuItem" and "#mainMenu a" instead of "a.menuItem". The only reason to include a class in a group of like elements is for ones that are different, if they are all the same, target off the tag by way of it's parent. You may find my 'good code, bad code' post from some time back helpful as well since it covers that and a whole slew of other common mistakes and covers my approach to coding a website - an approach that lets me do in an hour what many people struggle for weeks with... The approach is called 'content first minimalist semantic markup'. Lemme just say this about CSS frameworks - USUALLY much like what I just said about presentational classes and ID's they defeat the entire POINT of using CSS - that being to get presentation out of the markup. They rely on applying presentational classes to the markup meaning to restyle the page you have to edit the markup - net change zero. As such, BluePrint, YAML, YUI, Grid360, and all the other 'frameworks' are complete trash I would not recommend to anyone. Most of the time people use them it ends up as much if not more work as just working from scratch - so why not just learn to do it right from the start? To me it's just another sleazy shortcut.
Okay I figured out what was wrong, I was recreating the site bit by bit trying find what exact breaks the page. Realized its the 5 boxes I have underneth the header, it must be something to do with the font the boxes would have slighlty different heights, each if their wasn't enough space underneth the box for the vertical navigation DIV, it the navigation div would be moved to the shortest box which happens to be the last box labelled quicklinks. I created a DIV to enclose all 5 boxes and the problem disappeared However... another bug has surfaced. I have no idea why it is doing this. see image below