additions...

…web design…

it's “just data”…

One must not forget that web designs end up as “just data” that is transferred over the web when someone asks for a document, and that there's no real substance anywhere. The data is used to create or recreate a representation of the original at the receiving end, and end-users have control over a lot more transformation-power than any copymachine can provide.

Web designers should keep in mind that most end-users are most often more interested in content than design, so if the design gets in the way it may be dumped overboard. All end-users have that power, regardless of which browser or other software they use.

Any and all documents released on the web will be viewed, used and abused on at least a few thousand different combinations of browsers, Operating Systems and screens – not to mention all browser-options and user-preferences they'll be exposed to. Not a single document will survive all those combinations in pixel-perfect shape, so web designers and clients better get used to that thought.

Many documents will even be stripped partly or completely naked, transformed, and fed to end-users in forms few visual designers and clients can imagine, and those documents have to survive there too. Only real web-art will survive all that and still deliver its content in a meaningful way, and it certainly isn't because someone has hacked it to death during the design-process – probably quite the contrary.

Design solutions built on standards and balanced through thorough testing across browser-land, tend to survive just about everything a document can be exposed to on the world wide web – not just visually.

noncooperative browsers…

So, we're focusing on the visual apect of web design, and one or more browsers are not cooperating well enough for someone's visual taste. I'd be surprised if they all did, so that's as good a place to start as any.

ask basic questions:

1. Is there a real problem, something seriously broken, or is it just a minor visual deviation?
2. Is markup valid and otherwise in accordance with a relevant standard? Has anyone checked?
3. Can lack of validity in markup and/or CSS cause the problem? Has anyone checked?
4. Do designer and/or front-end developer know what they're doing? After all; we're talking web design here and not any other design-form.

Ok, so that sounds pretty basic (and maybe even a bit rude), but only when we're convinced we know the answers to those questions can we go on to the next step.

show caution:

1. Make sure it is a specific browser that's at fault, and not the designer and/or front-end developer. Test in all major browsers, and maybe a few more.
2. Look for alternative solutions in the HTML and CSS specs and around on trustworthy discussion-lists and fora. There's always more than one way to reach a design-goal.
3. Hacking should always be the very, very, last option.
4. One should only hack already dead browsers for real, and only when a problem is so huge that it is absolutely unavoidable.

That's the short-list, and I'm sure cautious developers will come up with many more reasons not to hack. Cautious developers don't really need a list of reasons though.

standards have no room for error…

Those who know what they're doing can achieve a lot without hacking. They probably also know what a narrow path they have to follow if they must introduce hacks. Yes, browser-specific hacks may be necessary, but chosing a somewhat safe route and keeping the number of hacks at an absolute minimum is a must if a web-design should stand the test of time, upgraded standards and new browser versions.

The following quote is deliberately taken out of its HTML 5 context, but it does say pretty clearly what web standards are all about.

We don't add extra features for people doing it the wrong way. They're in the wrong, and what's left is error handling.
—Ian Hickson – public-html@w3.org

One can read that as a warning to old-school front-end developers to clean up their act a bit if they want to “stay in class”. That includes quitting the habit of serving sloppy code to browsers and thereafter hack them to death when they don't comply.

Actually: browsers “error handling” could be used quite effective – if only those browsers agreed on how to handle errors. The fact is though, browsers are neither good nor reliable when it comes to error handling, so it makes sense not to challenge them too much in that field.

progressive enhancement doesn't always work either:

Handling of standards arent't that great across browser-land either, and even those web developers, like myself, who follow the “progressive enhancement” path by feeding browsers what the best of them can handle and expect the weaker ones to ignore what they can't handle, will run into problems.

Browsers still mess up on standard-parts they don't support, instead of following the decade-old rule of ignoring and just drop unsupported features. Having had a decade to fix the “ignore what you don't understand” part one might think browser-developers should have gotten it right by now, but I'm afraid they still need more time.

who is causing browser-failure…

Answer: nearly all cross-browser problems today's front-end developers and/or web designers experience, can be avoided by serving all browsers correct and complete markup and CSS tailored for the case at hand. Thus, nearly all browser-failures are caused by the front-end developer and/or web designer on the job.

There's a huge difference in saying that “I want my code to work in all browsers” and saying that “I want to serve all browsers code that works”. The former is a clear sign of stupidity, and that approach can never work. The latter signals a common sense approach, which will bring nearly all browsers close enough for comfort in nearly all cases.

Bringing all graphical browsers' visual rendering “identical down to the last pixel”, is an impossible goal. One can not even bring them to render an “all graphics document” perfectly identical. Get over it.

The term “close enough for comfort” means a web design appears identical across browser-land, and that one will have to compare in detail to see those unavoidable differences. Designers hung up on minute details should stay away from the web, as they have misunderstood the media to begin with and are destined to fail – every time.

Only when a single browser amongst the many fails so badly that we really have no choice, can it be seen as legitimate to hack that browser back in line with the others. Just remember that as of today – year 2008; if the failing browser is called anything but Internet Explorer then it probably isn't worth the effort to hack it.

Failures in non-IE browsers are most likely caused by the front-end developers and/or web designers themselves, so it makes sense to make attempts at fixing the problems at that end first. If it can't be fixed there, then it is better not to hack. Instead, file a bug report so the browser developers can fix the problem at their end. Better make sure it is a genuine browser-bug first though.

which hacks shall we use today…

Answer: hacks that are already completely broken and targeted at dead browsers, are somewhat safe to use now.
The logic behind this is that it is safe to hack the already dead browsers, as long as we're sure the living will not be affected.

safe – targeting IE7 and older win versions:

• the @import hack is extremely safe by now, as it creates a perfect and reliable branching. This hack in itself can never backfire.
  • IE7, IE6 & IE5.x/win get it wrong and will load the CSS file exclusively targeted at them.
  • All major browsers, including IE8, get it right and load the proper CSS file.

  Yes, I think IE7 has long since past into the “dead and stable” group. That IE7 falls for an old hack targeting only that group, proves me right beyond any doubt.

safe – targeting IE6 and older win and Mac versions:

• the “* html” (star html) hack has become extremely safe by now.
  • IE6, IE5.x, and all IE/win in quirks mode, read it.
  • All major browsers, and IE7 and later versions in standards mode, ignores it.

safe – targeting IE/Mac:

• the “crazy comment” hack has become extremely safe by now.
  

  /*\*//*/
  …IE Mac styles here…
  /**/ 
  

  • All browsers except IE/Mac (and NN4) ignore what's in that comment.

That's really all there is to it, as all hacks pointed at other browsers are extremely unsafe to use, and should only be applied when, and where, it doesn't matter if a hack works or not. That kinds of nullify the purpose of hacking, doesn't it?

Now, have a look at my reasoning…

yes, it is safe to hack dead browsers:

The reason for limiting hacking only to old, obsolete and already dead browsers, is of course that they are stable – dead. Nothing will ever change in them, so we can hack the dead until there is not a single one left on a computer anywhere.

The reason for only using hacks that are already broken, is that a few of those – especially the ones listed above, rely on such senseless browser-bugs in one branch of browsers that they will never be made to work in newer browsers. These hacks are also so widespread as hacks that CSS spec-writers will never introduce anything like them in the specs since they'll cause widespread breakage by doing so.

no, it is never safe to hack live browsers:

Once we start hacking frequently updated browsers, we're in deep trouble. Any attempt at hacking a live browser; like Firefox, Safari, Opera, Konqueror and others, is destined to fail with the arrival of new versions.

Live browsers are upgraded quite regularly in order to improve security, rendering, add or change features, and to fix bugs. What on earth are we going to do if/when a new browser version changes how it handles the part we hacked previous versions for? Our hack may still work in a new version, but it will probably do more harm than good if the bug it's supposed to fix is gone.

Unless one has time to sit around and just wait to see what breaks in the next version of every browser, and then spend time on fixing ones own “fixes” in a backwards secure way every time they break, one should leave those hacks out from the beginning. There are no future-proof hacks.

no, we can't trust any browser or spec:

We may also have hacked the wrong browser, as it may end up being the one we thought was wrong that is proven right and in accordance with specs. The other browsers will then hopefully sooner rather than later make changes to line up their implementations with the same spec and existing implementations. This has happened before and it is likely to happen again.

Not even standards are cast in bronze. Specs and implementations exist side by side, but they are not always in sync. Over time someone will try to sync them by either make changes to implementations or by making changes to the specs – or both. The upgrade from CSS 2 to CSS 2.1 is one such attempt at syncing specs with implementations, and not all browsers have caught up with all the changes yet.

hacking for fun and knowledge…

Yes, I do hack every single browser-engine and version I can get up on my screens, but I hack them only for fun and because I want to keep track of what has changed since previous versions. It really doesn't matter if one of my hacks break in a new browser version since my designs and layouts won't be negatively affected.

Only minor and design-wise pretty unimportant variations are introduced through these fun-hacks, and most visitors won't notice if they don't know what to look for. Perfect!

I use this entire site to test browsers, and hack them all so I can study the changes and improvements in standards support introduced in new versions. This constant testing provides me with loads of information about how to design reliable and hack-free and make it all work across browser-land.

I think all serious front-end developers and/or web designers should perform their very own testing of browsers, quite regularly. We all have our own design-methods and personal quirks and preferences, which mean we can't really trust browsers' and other developers' documentation of what works and what doesn't – especially in the latest browser versions.

There are simply too many valid ways to combine markup, style and script etc. to document how they all work across browser-land, so what works for one developer may not even make sense to another. Plenty of space for personal touches on the internet, so we can all have a go at it – preferably without introducing too many browser-hacks.

sincerely 

Hageland 21.oct.2008
last rev: 19.nov.2008