legibility first…
aim for an overall positive user experience.
Legibility comes first when designing web sites, or at least it should. After all, if end-users can't read and/or make sense of what a web page tries to convey, the rest of what's on that page does not really matter much. Only when the content gets through and basic functionality is good, does a design as such play a higher role.
In my opinion: the only way to assure legibility is to design important parts – content (mainly text) – with good contrast and legibility in mind, and let those few who think it is too much (or too little) light/contrast/whatever adjust their own hardware/software to their liking.
Of course; there are designers who may get nervous breakdowns just thinking about not being able to balance text and surroundings with just the “right” shapes, colors and shades. They may of course have it their way if/when no harm is done, but if design reduces end-users' access to content and overall experience, the designer's mental stability is not a good argument for not improving the design for end-users.
design considerations.
For designers to make assumptions about how visitors' screens, browsers, glasses and whatever are used and/or adjusted at the user-end, doesn't really make much sense. Too wide spread in equipment, settings and knowledge amongst web users. The fact that they can adjust things to their liking – if they know or bother to learn how, is all that matters.
On average screen devices are set too bright when they leave the
shops – bright screens sell better in bright‐light settings in
shops and warehouses. Over time they go less bright and with less contrast.
Color‐balance is all over the place from the start, and usually does not get better over time. Users may also set colors fairly strange, to something that works for them but maybe no-one else. In short: it is an awful mess out there.
Trying to figure out which end-user equipment/settings mix to design for, has as much chance to hit right as to take an agnostic stand and not bother about the whole “spread” issue. I choose to ignore the issue since there is nothing I can do to fix things at the user-end.
Any screen that is adjusted somewhat neutral on color balance, and half-way between medium and max for light and contrast intensity in a normal light‐setting, is as good as any other screen for quality control of web design processes. (I sometimes test across 10 screens, and although they're all adjusted fairly well they are all slightly different.)
problem: lack of standards support.
The ideal is to let browsers do the heavy lifting, so we won't have to rely on old‐school image clip‐and‐splice design methods. Browsers are slowly becoming the artistic tools we want and need, but lack of full and reliable standards support in some browsers is still a serious hindrance.
For instance: the headlines you see on screens do not look the same in IE9 and IE8, compared to what shows up in somewhat new versions of Firefox, Chrome, Safari and Opera.
IE9 does not support text-shadow, while the others do and have for a long time. So, I had to hack IE9 to make it render near‐black headlines, as the near‐white headlines the other browsers get are near invisible without text-shadow.
IE8 and older wasn't a problem, as they do not support enough CSS to try to render the near‐white headlines in the first place – blocked by @media‐queries.
The four major non-IE browsers differ slightly in how
they render text-shadows on these headlines – see examples in addendum. That is as expected, and not so much
variation that it bothers me. And, most important, legibility does not suffer in
any of them.
Legibility in IE9 does not suffer either, but it sure does
not render those headlines the way I designed them.
Some designers may let IE9's lack of support limit their design options here, and make all browsers render a reduced variant that IE9 can handle. Some may add more or less complex workarounds to make IE9 render something that is a bit closer to that of the other browsers.
I personally would not dream of compromising an otherwise well‐working design for the sake of one weak browser – any browser, and there are no good workarounds for missing text-shadows in Microsoft's arsenal. Thus, IE9 is left with showing its own weakness, while the other browsers render an uncompromised version of my design.
For completeness: on this site non-IE browsers also get a few corrections for deviating or failing standards support, but leaving them uncorrected would not be noticed by many or have a negative impact on end-users' experience – it is just the designer who likes to play with “pixel‐perfection”…
what, nothing about font-size?
Well, if unreadbly small text is a design‐requirement, you may as
well shoot the designer. Not much hope for legibility then, OK?
Enough of that nonsense.
Makes more sense to check up on screen‐resolutions and
sizes, and make sure not everything goes out 
the window – gets messed up – just because end-users have devices
with screen‐resolutions and/or sizes that differ from what the
designer/coder design on and for.
For every evolutionary turn in electronics, some new gadgets appear on the market. If browser/software/hardware vendors do their job there should not be any problems, but we can't trust them to work for the common good while they are busy trying to increase marketshares.
Rapid progress in the field of web‐capable devices comes at a price, in that we constantly have to upgrade our knowledge so we can include new units and gadgets in our design plans.
Trends have to come and go at a fairly rapid phase, or else the market slows to a crawl. Market economy dictates everything, so chances are that what you design for today may be obsolete and have few at the receiving‐end tomorrow.
The best thing one can say about progress is that there will be no end to it. Hopefully there will also come some good along with it from time to time, like improved legibility by default as a result of increased resolution on screens.
sincerely 
Hageland 30.jun.2012
last rev: 02.jul.2012
side notes.
no carbon copies.
It is good that browsers' rendering of details varies – within limits of course. People who easily get hung up on details get something to choose between then, and quarrel about if they so choose.
There are, and probably always will be, quite lively discussions on various forum about rendering details in browsers. Sometimes these discussions result in changes being made in how a browser handles this and that, and then the discussions can go on about whether changes was for the better or worse.
Consensus about anything is hard to reach in any field, and browsers and how they work, render, behave – or not, and the effects of well‐designed and well‐coded – or not, on end-user experience, are open for sometimes quite fierce debates amongst professionals and large groups of semi‐professionals and plain amateurs, and will be for ages.
If some form of consensus is reached on anything, it is likely because those
who disagree have grown tired of arguing. Next thing that happens is often that
everyone sort of forget the entire issue, so in the end it often doesn't matter
much what they reached consensus on.
Fun.
I am just happy that there are at least some slight differences between browsers, and equally glad that there are so many ways to design and code web sites. Suitable combinations can then be found for everyone interested in such matters.
user experience.
Most end-users simply have the best experience when whatever gets presented on a web site appears and function well in the browser they have and are used to. They are not interested in, and maybe not even aware of, the fact that appearance and behavior of some details are slightly different in another browser.
“If it works it works, and if it doesn't work it
doesn't”
, and beyond that there isn't much focus on anything but the
content or whatever each visitor came for.
As simple as it sounds, that is as it should be, as it would be damn hard to get anything through on the world wide web if most end-users spent most of their time on‐line weighing design details back and forth for every web page/site they visited.
We all know users “go blind” to unwanted distractions, and go straight for whatever they came for. Whether distractions are designed in or part of marketing – adds etc, seems to make little difference. So we may as well leave out distractions, and let content take main stage.
too much non‐standards support?
Everyone and their dog is on the web these days, and all want everything to work their way. What little standards support there is, gets over‐shadowed by wishes for support for all sorts of crappy code.
Browsers are good at error‐handling. Maybe too good, as too often coders get used to getting away with being sloppy, and get mad at a browser if it occasionally won't render all the crap as they expect.
More error‐handling is being defined along with HTML5, so
should be room for lots more crap released in the years to come. I am not
so sure if it is a good idea to correct all the crap, but what do
I know…
trying to improve code‐quality.
Code validity – 100% standards adherence – is in itself not very
important to me. No problem coding an awful mess totally based on standards, and
technically as valid as can be…
“…even a monkey can do that!”
My idea of good coding is: valid code in accordance with chosen standards, and as lean and free of redundant elements as it makes sense to have it without imposing serious limitations on responsiveness – ability to be styled to adapt to various media requirements.
From time to time I add support for new HTML5 elements and
functionality in HTMLTidy. Regardless of improved error‐handling in
browsers, good, clean and standard compliant code always works best –
especially in standards compliant browsers.
So, I try to clean up my own act, and not bother too much with what others do unless useful ideas can be gathered. In the long run I think that attitude will work best – for me at least.
freedom to design.
Despite my preference for clear and simple – user oriented – web design, an awful amount of details go into my designs. As long as it doesn't interfere with content delivery I may tune details to kingdom come, and I definitely want freedom to design.
I usually design with a high degree of margin pull/push and element overlap, in the flow. Browsers won't always allow me to do what I want with perfectly minimalistic source code, and CSS methods that may solve my design problems are years away from being implemented across browser‐land.
Thus, at times I have to give in and add extra containers to what would otherwise be lean and from a programmer's point of view “near‐perfect” source code. From what I have studied of HTML5 so far, the need for extra containers in special cases won't go away.
Some proposed CSS3/4 fragments – extended use of generated content for instance – look promising. Wonder how many years it will take through the process to get cross‐browser support.
