That’s a very ironic link to post in this topic considering the article is completely unreadable due to the flawed layout.
Today I decided to make my site more SEO friendly and hopefully render faster. The header and top Google Adsense were both moved to below the footer and positioned using absolute. This worked first time with very little tweaking.
Testing the result in IE Explorer, Firefox, Opera they result looked the same. The discrepancy in Google Chrome was huge and took quite some time to make match the output. The problem was using Ems and Google Chrome font was far different to the other three browsers.
Eventually managed to get all four browsers to look the same by changing all EMs to px. Would you believe the difference was 13 pixels, must be due to Triskaidekaphobia and especially because today is not a good day for programming mostly due to Friggatriskaidekaphobia and/or Paraskevidekatriaphobia 
Just remembered Safari and fortunately the output is fine.
It worked on my browser 
which browser you on?
I use Opera nearly exclusively. Others only for testing.
FirFox9 on Linux - and I get the same scrambled mess Imaginekitty is seeing.
Must be built for IE. 
o rly?
i use IE exclusively, and it looks perfect
but that’s because i browse with my zoom permanently set at 125%
at 100%, it’s the same dog’s breakfast as the screenshot you posted
and why do i browse with my zoom permanently set at 125%?
because almost all web sites have futzed around with font sizes, and i can’t read them
Ah, this topic again…
As I’ve said a billion times by now, if you’re using PX on your CONTENT, /FAIL/ at web design by shooting yourself in the foot on accessibility - JUST like fixed width layouts, JUST like endless javascript for nothing, JUST like slapping classes on everything for not reason, JUST like omitting half the tags you should be using or using the flat out wrong tags
Now, PX for fonts DOES have it’s uses – image interactions are a perfect example of this and only really an issue with the idiotic “sweetly retarded cousin to Nyetscape 4” text-only zooming that even Firefox doesn’t default to anymore… if used on things like your main heading where you’re pushing 16px or bigger, or on a menu you’re probably ok – so long as you remember 12px is minimum if you are all-caps in a large sans-serif font, 14px is ideal sans-serif, and 16px is bare minimum with serifs…
But for content headings and the content themselves, if you aren’t using %/EM, you’ve shoved the accessibility of your design so far down your own throat a client would have to take off your boots to wring your neck. If your design makes the user dive for the zoom, you’ve already failed and made a potential one-hit wonder, or worse bounce-city!
As always, the actual accessibility concept of %/EM hasn’t even been mentioned in this thread – people talking about zoom instead of browser and/or OS default font size, on which 100% is based and on which px is not. I have my computer set to 8514/Large Fonts/120dpi/Medium Fonts – that’s Win 3.0, 3.1 through ME, 2K/XP and Win7 respectively – what that boils down to is that EVERY application assumes the default text is to be 20px instead of 16px. If you write the page with %/EM, in Opera and IE it will pick this up automatically! I’ve owned phones that defaulted to 72dpi, the old *nix X11 default is 75dpi… NOT EVERY DEVICE ASSUMES 96 DPI – no matter how many webkit coders claim otherwise.
Of course, I’ve been running that setting SINCE 1989, as I’ve been running 1024x768 or higher on my workstations since then – LONG before we had font-smoothing the only way to get smoother text was to run a higher resolution and up the font-size. Windows has provided this functionality since version 3.0
It’s why fixed width layouts are a steaming pile of fail, content elements that can’t adjust their height to fit when the text gets bigger and wraps are generally NOT viable for web deployment resulting in broken layouts for users like myself, and on the whole is a significant part of what’s WRONG with so much of what people have been sleazing out and calling websites the past decade. It is somewhat ironic that we’ve been given all these tools and recommendations and standards for making more accessible websites, but on the whole with the endless javascript bloat thanks to idiotic frameworks, massively bloated “but I can do it in photoshop” idiocy, and people in general still having their heads wedged up 1997’s backside pages are less accessible today than they were ten years ago!
Just look at webmail for proof of that.
Well, you’ve got a LONG ways to go – I’d probably toss the HTML and start over since you’ve got non-semantic markup, missing HALF the elements you should have (fieldset, label, thead), endless classes you don’t need (day_header for example), presentational class use, vague class names… there’s a saying I use – CSS is only as good as the markup it’s applied to…
Much less the lack of text explaining what it is visitors are even looking at – meaning no actual content for search engines to deal with… one URL for all pages, over-reliance on javascript and content loaded via AJAX meaning search engines will NEVER see it (and inability to tab-browse it)… you get the idea.
<a href='javascript:void(0);' onclick="window.open('http://johns-jokes.com/popup/Three-hard-to-find-Valentine-cards.html', '_blank', 'width=800,height=600,scrollbars=yes,status=yes,resizable=yes,screenx=200,screeny=100');" title="Three hard to find Valentine cards">
I mean that really reeks of “Accessibility, what’s that?”
I agree with you on a lot but this one makes no sense to me. You say many good things, albeit in a purposely unnecessarily abrasive way, but fixed vs. variable width is a preference not a rule. Either is acceptable, accessibly our otherwise.
No, it isn’t, because the MOMENT you do fixed width, SOMEBODY is getting left out. See the ENDLESS 1024 width websites that are uselessly on my netbook or tablet, a crappy little stripe on my desktop full screen, and if you try to zoom because they used px metric fonts when running half-screen width ends up JUST as broken as it is on a small display because it’s not a fluid layout able to adjust to content resizing.
It’s a miserable failure at web design and is part of why width is in BOTH versions of the WCAG.
It may be a preference, but it’s a STUPID one that results in broken inaccessible garbage websites that forget the entire point of the Internet and HTML… it’s also why on a number of sites that have content I want but layouts I can’t use I just turn off CSS or throw one of Opera’s in-built accessibility user CSS at it.
Which works to a varying degree depending on how much people paid attention to semantic markup, proper use of heading tags, and whether an image is content or presentation.
It’s also why when it comes to mobile people usually end up completely lost on how to do it or list six to ten media queries to do the job of two to four of them. Of course, I also find fluid EASIER to design for than fixed since everything just auto-adjusts to fit… NEVER understood the people who claim fixed is easier; but I imagine it’s part of the whole “draw a pretty picture in photoshop before you even have markup of the content” nonsense – which is 99% of what’s WRONG with site development today resulting in sites that are very pretty, but ultimately USELESS to visitors.
Part of why I’ve become such a big advocate of semi-fluid – kills the only LEGITIMATE complaint about fluid width; lines being too long.
#pageWrapper {
margin:0 auto;
min-width:752px; /* pick up smaller with media query and script assist */
max-width:68em; /* adjust as appropriate for the content being displayed... I don't usually go past 72em */
width:95%; /* give a little space to show background all pretty */
}
* html #pageWrapper {
width:752px; { legacy IE users get crappy fixed width, OH WELL }
}
Of course using, as the comment says, media queries to adjust the layout for narrower widths by killing off multi-columns, adjusting menu layout, etc…
Fixed width screen only? /FAIL/. Even harder fail when you go back and try to target mobile… or legacy… or in many cases where the “But I can di it in Photoshop” nonsense comes into play, actually plugging in the real content in an accessible manner.
I don’t like fixed width layouts because I claimed they are easier or fit a design. I’ve never made such claims.
My claim is that fixed widths are more readable. Fluid layout with a mile long line of text is tiring and annoying. I don’t want four inch high text necessary to use the width.
Which is where semi-fluid with a max-width in EM’s comes into play – that way it can scale down for people on tiny displays, auto adjust to the content, while still not causing the problem of excessively long lines on large displays. Basically if you’re getting mile-wide lines, you’re doing fluid all wrong. Also taller line-heights can help make things clearer… but the real money meat is using min-width and max-width.
Since a large font/120dpi user like myself will find that ~960px width uselessly small in even a two column layout if you use dynamic fonts. Even just switching to EM’s for elastic width would be an improvement over declaring a px fixed width – but semi-fluid is where the gold is as it’s best of everything. Dynamically adjust to smaller displays, easier to target for even narrower display when you go to media queries, max-width to prevent lines from being too long – win/win/win. It’s made of win.
While fixed width is the worst of everything.
Actually, let’s use as an example my crappy little homepage.
http://www.deathshadow.com/
I’ve not given it the mobile media queries yet (it’s on my to-do list), but for now let’s just talk what it has – semi-fluid with %/em fonts.
min-width:768px – so it won’t go so narrow the layout gets broken or plate images won’t fit.
max-width:72em – I set font-size:85% on body, so that’s basically 980px max width for ‘normal’ / 96dpi users, Large font/120dpi users get 1224px max-width… which after the 17em sidebar works out to around 18-20 words per line average… entirely acceptable for normal reading.
That’s the sauce right there. It even has the advantage over fixed width in that until the min-width is wider than screen-width, zooming in will auto-adjust to keep the content on screen… so if you were at 96dpi on a 1920-wide display, you could zoom in around 250% before the layout ends up wider than screen width… Try that with a 976px fixed width.
The 768 min-width also meaning it works beautifully on smarter phones (like iPhone/iPad/IPod Touch / larger screen droids) who are basically designed for 800 width layouts – while not screwing over desktop users as that narrow a width would.
Whether you use fixed width, fluid widths or some kind of hybrid of the two boils down to your target audience.
If my target audience is wide screen users then that is what I will base my markup and styling on. In that case, I couldn’t give a continetal razoo if some user has to spend an extra 1-2 seconds scrolling across their small screen. I couldn’t justify wasting extra time catering for visitors I’m not even targeting.
Ok, ds60, I get that. And I see your points. I guess I just don’t have the same aversion to fixed width when done properly. I see pros and cons to both.
Improperly done both suck.
I do think the web design community is in a bubble and often times I don’t like the confines.
Besides what’s the difference now that we’re using media queries? Who cares if you need extras to work a fixed width? What’s that to the end user? Nothing.
Max makes good points as well.
My personal preference for using, not designing, is exactly 742px for a reading column. It’s exactly right for default text size, one down and two up. That’s a good enough test for robustness in my opinion.
Which is basically missing the point of HTML… device independence ring a bell? Target audience is people?
It’s the whole REASON TBL made HTML in the first place?
Of course it is 
, but show me where it says I, or anyone for that matter 
, must cater for everyone
If you think I must wate time catering for people I am not even targeting then you are totally wrong.
What exactly do you mean by that – it’s the second or third time I’ve seen you say that in relationship to sizes and I’m not sure on the relationship to the topic.
But you bring up a good point in terms of default text size – which has a very important counterpoint; not all users want or are set to the default text size, which is why px is /FAIL/ for width… assuming by ‘default’ you mean 16px that most 96dpi set browsers use, I’d suggest setting it to 46.5em - which will net you 930px for users like myself – the so called “elastic” layout that adjusts itself to font size. Large font users like myself would find 742px giving me 10 words or less per line and possibly broken layout if you declare fonts properly as %/em… or would just skip to some other site if you used px across the board – or complain that we have to use custom user.css to override your design into something actually usable. My content column in the fluid layout ends up max-width of 734px at 96dpi, though that might be a bit wide for your tastes given the 14px equivalent 85%… but entirely manageable. The more important part is it actually having accessibility to a whole host of targets for little or no extra effort if you just design that way from the start.
Most important point you make though is done improperly both suck – I’ve just never seen a fixed px width layout that didn’t suck.
Though my opion of fixed vs. fluid ends up real-world more akin to my views on science… to paraphrase Asimov: “It’s not so much that I believe fluid layout developers are right, as I am that fixed layout developers are wrong.”