

Sniff my browser: The Modernizr inadequacy - garethr
http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-modernizr-inadequacy/

======
JoelSutherland
I have mixed feelings on Modernizr...but this post seems to be filled with a
number of weak points.

First, the Modernizr file ends in ".js" I don't think anybody is fooled about
how it works and what its consequences are.

Second, the advocated method of stying your site with Modernizr is to first
make it look good assuming no "advanced features" exist and then progressively
enhance. This ensures that the failure of Modernizr to load will leave you
with what you started with. Given that the Modernizr classes are added to the
root of your document this claim seems impossible:

"However, it also means there is a significant loss in the overall structure
of specificity within your stylesheets, which could easily cascade unintended
effects through to other elements."

Finally his core argument is that Modernizr violates the separation of
concerns in front-end web development. This is true and something that you
have to be willing to accept to use it.

His proposed alternatives are strange however. He suggests server-side browser
sniffing, a bad idea as the article itself explains. Alternatively he suggests
using CSS cascading, but this is a bit of a tautology since this is the
problem Modernizr was designed to solve.

My personal opinion is that Modernizr is a bit of a kludge, but often the
least ugly option available.

~~~
skrebbel
> Second, the advocated method of stying your site with Modernizr is to first
> make it look good assuming no "advanced features" exist and then
> progressively enhance. This ensures that the failure of Modernizr to load
> will leave you with what you started with.

I think the big problem and why separation of concerns matters is that people
don't design a site once and then let it be. Most frontend developers maintain
already existing sites, across new features, new browser versions and new end
user expectations. You can't apply that "advocated method" there, or at least
you can't do so equally well.

I guess that simply disabling Modernizr when adding new design elements until
things are good enough, and then enabling it for the "advanced features" could
be a work around. I've yet to see such a disciplined workflow somewhere,
however.

Nevertheless, I agree with you that it's the least ugly option available.
Maybe making it easier for a developer to temporarily disable modernizr helps
styling with the "prefer good styling with no advanced features" approach.

------
bruce511
There is this constant tug-of-war going on for developers. On the one hand we
want to provide the best possible experience to the end-user, and on the other
hand we want to include as many people as possible.

The two forces are in competition with each other though, because very often
the largest group of people are running older technology.

We can broadly divide the potential user base into 3 groups. Those "ahead"
with a cutting-edge browser, those with a "modern browser" and those "left
behind". Today we'd consider IE6 users and Windows Mobile 6 users as "left
behind". We'd consider HTML5 in a late-version of Chrome to be "ahead". Not
surprisingly though the vast majority of people are in the middle.

The key question seems to be "Is JavaScript in the mainstream?". I think the
answer to that is yes. Even IE6 has Ajaxian capable JavaScript. So therefore
is the user-experience, of the many, improved by using JavaScript, to the
point where the "few" are sacrificed? In my opinion, yes.

Certainly the user experience is improved immensely with the use of
JavaScript. The question then becomes whether it is better to service say 95%
( _) of the market really well, or 100% of the market in a mediocre fashion? I
would argue that the market does not reward mediocrity - and the 5% you have
gained are the least likely to appreciate your effort anyway.

(_) pick whichever number here you prefer.

Take an average hotel website for example? It's certainly all-inclusive, but
at the same time is horribly unusable. It has evolved since 1995, and it's
still as awful as it was then. Does a hotel gain 5% more occupancy for making
it all inclusive, or do they lose more than 5% for having a horrible
interface?

Personally I don't believe any site is "all inclusive". Those primitive enough
to include the bottom end, are too dull for the folk on the top end. So the
real question becomes, would you rather have the top, or bottom demographic?

Bearing in mind that for the vast majority the decision to not have JavaScript
support is completely their own?

Now of course every site has different considerations. But in my opinion the
starting point for the discussion is "how much is that 5% worth?"

Will Modernizr make everyone happy all the time? Well, no. Then again, nothing
will.

------
jsdalton
Yeah, basically there _is_ one shortcoming of the "Modernizr approach" to
front-end development -- namely that you will end up treating clients who have
JS disabled as though their browsers do not support a number of CSS features.

So with the old browser sniffing way, your Firefox 4 user will still get the
shiny buttons and rounded corners even if he has no JS. With Modernizr, he'll
(at best) get the watered down IE6 version with flat buttons and sharp
corners, etc. At worst, if you're not doing progressive enhancement right and
you've based critical functionality on one of the injected classes, you might
cause some real problems for this user.

I guess I just see this as a limitation of Modernizr, and not a reason to
throw out the baby with the bath water. I still love it and use it in all of
my projects.

~~~
paulirish
(modernizr lead developer here)

Something this article brings up and that you touch on is: coupling your use
of CSS3 to JavaScript being enabled.

There is an incorrect way of using Modernizr where you always surround your
use of a CSS3 feature with a `.feature .box` class, which is generally
unnecessary and leads to the issue the author was concerned about.

Modernizr classes are best used in the `.no-feature` case, where you do
something like use background images or another clever CSS use to mimic the
feature or handle the fallback situation. In general I like to code my styles
optimistically though.

I left a comment on the site saying it's hard to address this subtlety of the
"right way" to use Modernizr classes. We're launching a new site very soon and
hope to better document this approach so people don't go down this tricky
road. :)

~~~
spjwebster
_Modernizr classes are best used in the `.no-feature` case, where you do
something like use background images or another clever CSS use to mimic the
feature or handle the fallback situation._

Switching from progressive enhancement (applying styles if you detect a
feature is supported) to graceful degradation (applying styles if you detect
that a feature isn't supported) doesn't solve the underlying problem. In fact,
it makes the situation worse. JS failure with the progressive enhancement
approach means that everyone gets the fallback experience; failure with the
graceful degradation approach means that you're potentially asking a browser
to apply CSS that it doesn't understand and not offering it a fallback.

No matter which way you cut it, having CSS predicated on classes set by
JavaScript creates a dependency where one should not exist. I realise that's
the whole point of Modernizr, but in my opinion it isn't the right way to
solve this problem. Others may not agree, and that's fine, but it's critically
important that developers being encouraged to use Modernizr (or its underlying
techniques) are made aware of the tradeoff they are making and the potential
impact that may have on their users.

------
pkteison
Tl;dr: Entire article is nothing but 'relying on js is bad'.

Author discounts modernized entirely because it only works with javascript.
Suggests you can replace it entirely by tagging your html tag with an ie class
using conditional comments (thereby relying on browser sniffing, after arguing
that browser sniffing is terrible and doomed to fail) and the cascade in
stylesheets.

I'm not convinced this gives a fair shake to the difficulty of getting
graceful degredation right with just the cascade, and any author that says 'x
is bad' then relies on x is clearly presenting an incomplete argument.

~~~
intranation
A clarification: conditional comments are a feature of IE, and thus are stable
and reliable, and aren't technically browser "sniffing", at least in the
traditional sense.

------
poink
This post seems ridiculous. Modernizr is "bad" because it depends on JS, but
the alternative solution suggested is to go back to user agent sniffing and
just do it on the server side. I'd forgive the author for not knowing why user
agent sniffing is a terrible idea, but it was covered in the post itself...

------
ramen
Modernizr does a lot of things, and creating CSS classes to mark the existence
of features is just one of those things. Another thing that Modernizr does is
allow you to style new HTML5 elements like <section>, <header>, etc. - I think
that there is a similar issue here, and I'm really on the fence about it.
Depending on the browser to execute Javascript so that CSS is able to style a
new element seems risky, and for quite a marginal benefit. I guess people are
just trying to make the future happen sooner, but it seems foolish to
introduce an external dependency and scripting requirement just because
<header> looks better than <div class="header">. What do we really gain here
by being more "semantic"? Aren't we just trading reliability for fashion?

~~~
KuraFire
> _I guess people are just trying to make the future happen sooner_

Here’s why: Encouraging people to upgrade from old IEs to newer versions by
making websites generic, mundane (but still accessible) and bland for them is
just about the best thing that you as a web developer can do to help move the
web forward. That and experimenting with the newest technologies as much as
possible and reporting bugs and other feedback to the vendors.

------
toddmorey
I don't think Modernizr causes harm if you _understand and act like_ the
resulting CSS styles are javascript dependent (as you should with any JS-based
progressive enhancement). He's right, though: there are more conditions than
you'd think where javascript may not be available. Make sure to ask yourself
if the effect you want is possible without javascript first (as in the button
example). And always test your pages for usability with javascript turned off.

------
oozcitak
There are only a handful of browsers that doesn't support javascript today
[1]. There also users consciously disabling scripting on their modern browsers
but they don't add up to a significant percent of browser users [2]. The
second argument that an external .js file can fail to load applies to the .css
file as well.

There may be arguments against the modernizr approach, but the ones in the
article are quite weak.

[1]:
[http://en.wikipedia.org/wiki/Comparison_of_web_browsers#Java...](http://en.wikipedia.org/wiki/Comparison_of_web_browsers#JavaScript_support)

[2]: [http://visualrevenue.com/blog/2007/08/eu-and-us-
javascript-d...](http://visualrevenue.com/blog/2007/08/eu-and-us-javascript-
disabled-index.html)

------
c4urself
i can't advise modernizr as _the_ answer to html/css compatibility either,
that being said it's a great tool to get started using html5 css3 until a) a
better tool comes along or b) browser compatibility issues go away ...

