The question becomes what version of IE… though that’s just the tip of the iceberg; different OS have different font renderers, and this can cause massive cross-browser headaches – not all OS default to the same font-size, so if you’re using %/EM fonts you need to test what happens when the size dynamically/automatically gets enlarged. (which is the entire REASON for using %/em or even PT instead of PX, so that it does automatically enlarge without diving for the zoom).
The only cross-browser checkers you need don’t cost a thing. It’s called the browsers; install them. IE9 can kind-of emulate down to IE7 through it’s developer tools, though I would suggest installing several different IE and OS versions inside virtual machines. For example my workstation runs Windows 7 on which I test the latest of FF, Opera, Safari, Chrome and IE, but inside Oracle VirtualBox I have a Linux install for testing FF and Opera on that platform, a Windows XP install for testing IE 7, and a Windows 2000 install for IE6, and a Win98 install for IE 5.5 – so I can see each of them in their ‘native’ environment. You could probably use Tredosoft’s multipleIE under XP to test 7/6/5 on one platform… an XP license key isn’t that hard to find these days, just ask around if anyone has a busted laptop with a key on the bottom.
Remember, alt-tab, F5 is your friend.
While it is a VERY important step, it’s a small one at best. There are hundreds of thousands of websites out there which are invalid, but render just fine; just try validating Facebook or Amazon some time. It’s a good starting point and CAN cause your pages to not work, but it’s no guarantee. PARTICULARLY CSS, since invalid CSS is often MORE likely to work than valid – thanks to many of the hacks, bugfixes and vendor proprietary values you often need to pull off cross browser compatibility.
There is no real excuse for invalid HTML – there are MANY legitimate reasons to have invalid CSS. While many of them are IE specific (haslayout triggers, zoomfix, filters, behaviors) others (-moz, -webkit) are needed if you want to start using CSS3 (and even some CSS2) values. (which unlike HTML 5 I see little wrong with trying to use now – older browsers don’t get rounded corners, box-shadows and text-shadows, OH WELL!)
Which comes down to why I advocate writing your ENTIRE content (or a reasonable facsimile) using semantic HTML in a logical document structure before you even THINK about applying style or layout to it. A few standard containers like an outer div for width constraint (and to allow inline-level elements to be valid markup across the whole page), a content/sidebar/columnwrapping/footer set of div, etc can typically go in during the first pass since they’re fairly predictable; after-which there’s often little that needs to be added to the page’s HTML as styling is applied. (the occasional sandbag DIV or SPAN being about it).
Then comes applying the layout, and this is where things get tricky and you start worrying about cross-browser behaviors. I typically code the CSS in a top-down manner testing as each major section (DIV#pageWrapper, H1, UL#MainMenu, etc) has it’s CSS applied. Code a section, alt-tab to each browser and F5 to refresh. Testing as you go top-down means you don’t run into the folly of coding an entire page and then going “Why doesn’t it work in fill_in_the_blank” – since quite often bugs that show up when the enitre page is done can be caused by flawed methodologies you can’t even track down or fix by the time you’ve finished it – it’s why quite often my advice on fixing a page is “throw it out and start over” – because it will often take more time to track down major rendering issues and then come up with a solution than it would to rewrite it from scratch WITHOUT those problems.
There are also a number of things that people do in design that, well… I consider “not viable for web deployment”… one of the classics, and what was causing issues on your page here, is declaring a fixed height or not clearing a float on the assumption the content won’t change size. Again as above the entire reason for using %/em is so that the content can change size – and content areas themselves are often edited, changing their size. You were adding a list of prices to a floated side column, without the float cleared, behind a image you were allowing to repeat when it probably shouldn’t… so on large font/120dpi systems where the fonts end up 25% larger, the content column was taller showing the image repeat (looking broken though it wasn’t really), and the sidebar ended up taller than that overlapping the footer. Ends up a double-whammy over something simple; clear floats and don’t repeat an image that doesn’t look good repeated should it show up. If you went back in a year and decided to add a paragraph or two to the content area or remove a section from the sidebar, the layout would have caused the same headaches that were showing up on large font systems.
That’s something else to keep in mind – another reason to keep layouts flexible and adjusting to content is most successful websites have content that’s in flux and always fresh/new to keep people coming back; might not entirely apply to a photography site but who knows in a year or so what you want to do. Allowing all your content areas to expand at the very least on height means when you go back to add/remove later, the page won’t break or require major rewrites. Fixed height elements (which your PSD jockeys get mahogany over) and failure to clear floats can really work against that… which is why fixed height areas and image interactions behind text areas should be kept to a minimum.
Another common mistake is trusting the line-height when you change your font size, and constantly stating font sizes over and over again on the content areas. Line-heights are VERY unpredictable – some people still claim that if you omit the metric (for example: line-height:1.5;) it will inherit properly, in my experience as a large font/120dpi user, that’s 100% bullcookies. My rule of thumb is state your metric (%/em, etc), and if you change your font size, change or restate the line-height to match. given the number of characters involved in saying both font-size and line-height, I end up using the entire condensed property to be 100% sure of everything being set.
font:normal 85%/150% arial,helvetica,sans-serif;
Typically I’ll put something like that on BODY then allow all the content areas to just use that – instead of stating it on every paragraph or content area. It means less saying ‘font-size’ as the only times you have to restate the size is when it’s DIFFERENT – which really the only places it should be different is on headings, areas with fixed image interactions (like the H1/logo), areas that can break at your min-width when the font enlarges (menus) or areas that you HAVE to fix the height of (sticky footers).
I’ve got a demo I wrote years ago that show how different font metrics and how line-heights don’t inherit quite right.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html
Pay particular attention to the “medium/default side-by-side” section, and the line-height demo below that in the “Further research” section – showing how a 200% line-height doesn’t inherit to the same value. (using a circular logic test).
It also helps to keep in mind that not all fonts you declare are going to be available everywhere, and different font faces at the same declared size can vary wildly in how big they render. A couple months ago I tossed together a simple image to show that in action – with both the normal size and the large font/120dpi defaults.
Compare Verdana to Trebuchet for example – those are both 100%/16px small/20px large, yet they’re not only different in width, the heights don’t match either. Compare franklin gothic to dejavu serif… You get on a mac or linux machine that doesn’t have the font you were designing to in windows, fixed width and height areas can break…
It’s also why I’m not a fan of fixed widths – on top of them usually being too wide for my netbook and uselessly small on my desktop, when the content auto-resizes there’s no room for it. That’s the beauty of keeping as much as possible on the page fluid – no matter what happens it’s less likely to break than an inflexible fixed layout.
… and it also plays to the entire PURPOSE of HTML as set out by TBL from day one – delivering content to a myriad of devices regardless of their capabilities; a concept lost on the people vomiting up fixed width layouts with EVERYTHING declared in PX – using a single PSD and 96 dpi desktop screen as their only concern. That right there is the biggest /FAIL/ at web development there is… and yet somehow it’s become standard practice for the people who think their l33t r0xx0r photoshop sk1llz have anything to do with designing for Internet deployment.
It’s a lot to keep track of – and at the start it can all seem very daunting, but that’s part of why it’s called work, and not “happy happy fun time”… It’s also why there are so many sleazy fly by night scam artists pretending to be experts in the industry just so they can sell a book or seats at a lecture; and why your major successful websites don’t have all the goofy pretty crap you see on alleged “bleeding edge design” websites.
In fact, I can’t think of a single major successful website that uses 'bleeding edge design"… I can think of a lot of also-ran failures though. There’s a reason you don’t see the really elaborate and fancy layouts on pages people actually use; typically only seeing them on personal pages of graphic artists, small businesses who were led down the garden path by someone not qualified to give them a site in the first place, or corporate websites where their Internet presence is more of an afterthought. (the last of those being ruled by the flashtards – see most video game websites or sites for things like non-delivery fast food – USELESS inaccessible websites that are more expense than investment for the company).
Of course, that’s just talking coding and layout – we haven’t even TALKED accessibility yet. Color Contrasts, padding content away from edges… there’s always something more.
in other words the layout breaks down in certain browsers. Originally I tested it in Safari, IE & Firefox thinking that would be good enough but it seems ive been mistaken
), meaning that even valid code may break if the browser is a dud.
