Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sniff my browser: The Modernizr inadequacy

nefariousdesigns.co.uk

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Sniff my browser: The Modernizr inadequacy

#11

Post by skrebbel »

JoelSutherland wrote: post #4

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 M…

> 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.

Re: Sniff my browser: The Modernizr inadequacy

#12

Post by paulirish »

jsdalton wrote: post #5

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 v…

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

Re: Sniff my browser: The Modernizr inadequacy

#14

Post by spjwebster »

paulirish wrote: post #12
jsdalton wrote: post #5

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 v…

(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, w…

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.

Re: Sniff my browser: The Modernizr inadequacy

#15

Post by 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 , , 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 looks better than . What do we really gain here by being more "semantic"? Aren't we just trading reliability for fashion?

Re: Sniff my browser: The Modernizr inadequacy

#16

Post by KuraFire »

ramen wrote: post #15

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 , , 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…

> 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.

Post reply on HN