3 ms·
In the meantime, one could use JavaScript to detect a browser's capabilities, and add a flag via a class on the body or html element. For instance, with jQuery
by audionerd 17y ago
In the meantime, one could use JavaScript to detect a browser's capabilities, and add a flag via a class on the body or html element.
For instance, with jQuery and a getStyleProperty helper[1]:
if (typeof getStyleProperty('borderRadius') != 'string') {
$('body').addClass('unsupported-border-radius');
}
... then in the CSS:
body.unsupported-border-radius {
... alternate code goes here ...
}
[1] http://thinkweb2.com/projects/prototype/feature-testing-css-properties/ http://thinkweb2.com/projects/prototype/feature-testing-css-...
- chriseppstein 17y agoThis is a decent work-around. There's two reasons why it's an inferior solution: 1. It slows down rendering or causes a potentially huge reflow when the feature support classes are added. 2. The specificity of body.unsupported-border-radius .box is greater than the original rule, and this is going to cause issues with the rule ordering.
- audionerd 17y agoYeah, definitely on #1 -- it's a performance hassle. re: #2, a higher level of specificity acts like a ham-fisted override when the original rule you prefer can't be applied. that seems the right order of precedence to me. EDIT: i see what you mean now. an @unsupported attribute as you describe acts like an either-or. the javascript solution i'm talking about cascades like a "this-and-also-this".