thou shalt not hack…
… 
but hacking browsers can be such great fun.
A routine visit to the W3C CSS Validator produced the following message:
… which should make my face turn as red as the background on that message.
Well, once I had checked what the honorable validator reported as errors,
it only made me smile. Results were exactly as expected.
All 57 errors reported were intentional, non‐valid, browser‐targeting hacks. These hacks will stay until I no longer see the need for them. That is: when the browsers they target become irrelevant. What comes after that is anybody's guess.
There are actually more than one hundred additional hacks in stylesheets behind this site. That the validator can't find them doesn't make these hacks more valid, or less potent in the browsers they are aimed at.
Hacking browsers can be great fun, as a relief from boredom if nothing else. Routinely having to work around bugs and hack individual browsers in order to make my design‐ideas show up somewhat as intended across browser‐land, is anything but fun though.
There should be no reason to target individual, reasonably new, browsers in order to serve them different commands aimed at reaching the same goal. I have no problems coming up with real‐world cases where such targeting is necessary though, and no browser gets an “all clear” from me.
any browser … yeah, right
No matter what browser you use today, and tomorrow, its ability to combine
high numbers of simple command-code fragments in an orderly manner and turn them
into somewhat flawless products – web pages, will be limited.
You can't combine “this” with “that” and expect it to work in a particular browser. In another browser what combinations that work and which don't will differ, but there will always be limitations in how complex combinations browsers can handle.
Some of these limitations will end up being “standardized”, simply because good solutions can't be established. Other limitations will just “hang around”, because no‐one can be bothered with looking into and potentially solve them.
Loads of limitations are left in by design as new browser versions are released, either because other factors or features are prioritized, or because browser vendors compete. And, once web designers in their thousands start relying on particular behavior in browsers, it becomes harder to introduce improvements.
The old saying: “if it ain't broke don't fix it”, is, and will always be, a pretty solid hinder to positive development in any field.
We will have to live with the incomplete and varying handling of standardized CSS in browsers, and the need to include valid and non‐valid hacks and workarounds in order to get browsers somewhat in line, for a long time.
I easily predict that these limitations and whatever problems they cause, will last for as long as there are CSS capable browsers. Replacing them with something else is unlikely to improve the situation.
relaxed approach
All my designs take into account browsers ability to modify design details to suit individual end users, and ability to deliver content in an unobstructed manner is stress‐tested across a reasonably wide range of browser settings on various devices.
There is always room for improvements, and some are introduced now and then. Overall I am reasonably happy with how my designs perform as of today though.
I have never seen the point in adjusting designs to make it easy on browsers. Browsers that can't deliver when served slightly complex standard code and don't react well to reasonably simple targeted workarounds for their deficiencies, either have to be fixed or ignored.
Another irrelevant factor is what other web designers may think about my designs and what's behind them, except of course when I specifically ask for their opinions on something. Web designers do naturally tend to look at “everything web” as designers, which in my opinion for the most part is pretty uninteresting when designing for end users.
Visitor experience is all that really matters. As long as my designs function well in reasonably new and capable browsers, and carry content in an orderly manner to end users that want access to it, all is well.
sincerely 
Weeki Wachee 01.mar.2013
14.mar.2014 - minor revisions
last rev: 14.mar.2014
side notes.
knowhow
Hacking browsers without knowing all about the bugs and limitations one is hacking in workarounds for, is usually a recipe for disasters. It is a pity that so many front-end coders hack browsers first, and then later, maybe much later, discover that they got it all wrong.
Borrowing ideas from others who are not involved in ones own work, does help, but only so much. Better invest time on some in‐depth research of your own. Maybe best to start by reading and dissecting W3C CSS standards, as they for the most part describe quite well what browsers are supposed to do when served correct code.
I have done my research, so when I add browser hacks it is because few if any acceptable options exist, and the risk for future problems caused by inserted hacks is small to non‐existent.
validity
Valid or non‐valid is pretty irrelevant when it comes to CSS hacks – at best a question about semantics. What matters is that hacks should only be inserted when absolutely necessary, and then in such forms that they are reasonably future‐safe.
The simplest way to ensure “future‐safety” is to use well‐tested version targeting hacks, and only target older browser versions still in widespread use. Leave new browser versions alone no matter what.
On my personal sites, like this one, I do go further than necessary, and include surplus hacks and workarounds for both old and new browsers as part of ongoing research. All to increase my knowledge related to what works and what doesn't work in browsers, and hone my hacking skills for when they become necessary.
code to standards
Should not be necessary to mention that one should always start by coding to W3C CSS standards, and then, if deemed necessary, correct rendering and behavior in the most wildly deviating browser by adding the safest workarounds and/or hacks available.
A pixel off here and there does not necessitate browser hacking. Better to hack the designer/coder if a design is that tight and/or weak.
And, NO, W3C standards are not rules or laws that we have to obey no
matter what. It just makes sense to test out what can be done and how it is
expected to work in accordance with W3C standards, before going wild and
complain about browsers not doing what we want them to.
don't trust browsers
Never trust any browser to get it right, unless and until you have checked that it renders in accordance with standards. Otherwise you risk using the wrong browser as reference.
CSS standard parts only become recommendations when at least two browsers render and behave close enough for comfort, so finding working references should not be all that hard – any two browsers that agree on something may by chance or design have gotten it right.