Hacker News Reader

Comment by jsdalton | Hacker News Reader

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.

View on HN

(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. :)

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.

Reply on news.ycombinator.com