Proposal: Hack Free CSS with the @unsupported Directive

Re:Proposal: Hack Free CSS with the @unsupported Directive by audionerd on Monday October 19, 2009 @10:54AM (#890156)

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

[ Parent | on HN ]

Re:Proposal: Hack Free CSS with the @unsupported Directive by chriseppstein on Monday October 19, 2009 @11:14AM (#890205)

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

[ Parent | on HN ]

Re:Proposal: Hack Free CSS with the @unsupported Directive by audionerd on Monday October 19, 2009 @11:40AM (#890266)

Yeah, 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".

[ Parent | on HN ]