barisaydinoglu
Document real world reasons to use Detectizr
While most developers know that feature detection is the best course of action, it would make sense to document actual incidents that require Detectizr.
One such issue that comes to mind is Safari 6.0 crashing if a calc() and transition style are used on the same element.
It would make sense to create an up to date wiki page with known issues that only userAgent sniffing can cope with.
Is this issue about the link below? https://bugs.webkit.org/show_bug.cgi?id=100568
Yes, this is the issue. Safari 6.1 doesn't have the issue but 6.0 and 6.0.5 do.
Here's another one I'm doing: Disabling heavy CSS animations (like full-page transforms) on mobile devices because their poor little GPUs just can't take it, and I'd rather have no animation than a choppy one. Feature detection doesn't work for me because mobile browsers technically do support animations.
@dallonf Theoretically that can be handled by media queries rather than device detection. The smaller the screen, the less animations they get.
I like to apply CSS hover states only on desktop browsers to avoid the double-tap-to-click scenario, like so .desktop &:hover { different: style; }
The reason I feel this is a superior approach to .no-touch &:hover or just media queries is that 1) tablets are large enough to get desktop layout in landscape mode, and 2) fancy 15" laptops with touch screens now exist, and I want those users to have hover states.
I also use it to disable heavy scripts like @dallonf, especially in javascript. Whereas desktops might check the viewport width to determine whether the function should continue, the whole kerfuffle can be avoided by not initializing the script if (!Modernizr.desktop)
