|
|
|
|
|
|
by paulirish
5515 days ago
|
|
|
(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. :) |
|
|
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.