…an obsolete approach
Separating and targeting browsers by extracting and interpreting their User Agent strings, is a pretty withered and unreliable idea and technique by today's standards.
It became unreliable over a decade ago, when users learned about, and started using, User Agent spoofing to bypass the “include this and exclude that browser” practice quite a few web sites applied back in the twentieth century.
Why some sites still target browsers using this technique, is difficult to understand. Why anyone needs browser detection now is even more in the fog, as all major browsers handle whatever they are served well enough for comfort.
CSS hacking is equally obsolete, but…
Most front‐end coders know by now that “you simply do not hack new browser versions”. That we still see it happen today is something I find very hard to understand.
As browser‐updates take place every few weeks, hacking new browsers to “fix” real or imaginary rendering flaws means whole series of hacks will also have to be gone through and updated every few weeks to make sure they don't affect the wrong browsers, or cause the wrong effect in the right browser.
Such repeated checking and fixing of code behind a site, is a hopeless and pretty nonsensical task. No-one in their right mind would take on such a task, unless browser hacking is what their lives are all about.
On the other hand, hacking old browsers that one simply has to
support for whatever reason, is considered to be perfectly alright by most. And,
whether they admit it or not, all web site developers/coders do insert
CSS hacks and/or build workarounds to make old browsers play ball.
What matters then is that such hacks should never have to be updated as new browser versions arrive, and, preferably, that they can be removed in whole blocks or entire stylesheets when they are not needed anymore.
As of August 2016, support for IE8 and older, is dropped on this site. All stylesheets for them are disconnected.
…qualified CSS hacking does work
Browsers like IE8 – still used by many – simply won't work without tailored styling, as it fails to support half of what more modern browsers handle just fine. To avoid putting limitations on what modern browsers can be served, some form of style‐separation between old and new browsers is necessary.
I do not promote the use of non‐valid hacks, but fact is that carefully crafted non‐valid hacks tend to be most reliable. The less valid and more “backwards” hacks we use to serve old browsers what they need, the less chance there is that today's and future browser versions will ever pick up these styles.
These days I mainly serve all recent browser versions
progressive, agnostic, and
in places somewhat complex
CSS constructions. This is to see how
they react, i.e.
CSS capability testing across entire sites.
Intentionally, this may make different browsers render parts of a design
different, but not where or in such ways that it will seriously hurt my
I continue to play around with
hacking, but apart from utilizing some pretty safe and reliable
CSS hacks to make some quite old and obsolete browsers play ball,
I don't use
CSS hacking to target browsers for anything
browser agnostic at last
As we write spring of 2014, it should not matter which of the new browsers our carefully crafted web designs gets rendered in.
Cross browser styling is the only methodology that makes sense today, and tomorrow.
While performing cross browser testing of my designs, I have of course observed occasional flaws, bugs and regressions. No real show‐stoppers for rendering in browsers released the last year or so though.
I see enough improvements in today's browsers compared to only a year ago, to expect real standards support and cross browser rendering improvements in major browsers built for regular computers, tablets and smartphones in the next twelve months.
That we still will have to “style complete” – add seemingly
property/value pairs for some elements – to make
sure all browsers render the same regardless of how they interpret standards, is
in my opinion not something we have to divide and hack browsers to solve.
29.mar.2014 - modified a paragraph or two.
16.sep.2016 - minor revisions, and added "IE8 gone" note.
22.nov.2017 - replaced 'Browser Targeting' text in side-notes.
last rev: 22.nov.2017
Interpreting User Agent
strings to detect individual browsers, will fail all too easily. Targeting
CSS hacks doesn't really work all that much better in
CSS hacks can be used to target browser engines – in a
broad sense, which is what I sometimes use
CSS hacks for. They
can be useful for targeting old browser versions so they can be served
necessary corrections without disturbing later versions.
For new browsers I use
CSS hacks only for fun, as
for the cat chasing browsers in the picture above. If the cat fails in catching
a new browser, it is really no big deal me thinks.
browser targeting CSS
As can be deducted from my “browser targeting” stylesheet…
/* TARGETING BROWSERS by CSS ----updated medio nov. 2017------
…I don't update those
CSS hacks very often. I don't
have to, as they are carefully selected and constructed to be reliable for
a long time.
The “browser targeting” stylesheet is also only linked in on pages where I need it. Only a limited few of those hacks are made part of the sitewide styling, mainly to control old IE versions.
I have not decided whether or not to update my “browser
targeting” stylesheet for
HTML5. Easy enough to do, but
I can't see what we should need dedicated
CSS hacks for in
browsers that natively support
no CSS Reset
Instead of including any form for
CSS Reset on my sites,
I “style complete” – add whatever is necessary to each
element in the order I use them. Browsers own default styles are excellent
starting points for this technique, and I rely on my own cross browser
checking to make sure all browsers render as intended.
As a typical “style complete” example: declaring
padding on elements if browsers show
alignment deviations, solves the problem in nearly all cases.
vendor specific CSS
A few vendor specific
CSS “packets” are in use on
this site, but I have made sure my design doesn't rely on them. Testing out
experimental features is interesting, and vendor specific
the only method in use up until recently.
I prefer the new “experiment in your own browser” method for testing feature development, that several browser vendors seem to go for – see: chrome://flags and opera://flags.
I hope this method takes hold across the board, as it will eliminate the need
for vendor specific
CSS in our stylesheets.