

Proposal: Hack Free CSS with the @unsupported Directive - chriseppstein
http://chriseppstein.github.com/blog/2009/10/19/css-unsupported-directive/

======
generalk
I simply can't stand it when someone's solution to a problem is "I know, I'll
put the code inside a comment!"

Now, as a human looking at a syntax highlighted source file, my parsing is
broken. All the differently-colored comments that I _should_ be able to ignore
suddenly have to be scanned because they might affect runtime somehow, and
certainly any machine-based parser gets unnecessarily more complex.

~~~
chriseppstein
Your syntax highlighter can be trained to understand that syntax and not color
it like a comment.

~~~
generalk
Well, sure, that takes care of the symptom but not the underlying issue:
comments shouldn't affect runtime! To put it differently, if I remove all
comments from a source file, the compiled/interpreted result should be 100%
the same. If it isn't, something's wrong.

~~~
chriseppstein
In this case, the something wrong is that the specification didn't have the
foresight to create a syntax robust enough to support actually upgrading the
spec for real users. Discarding unrecognized syntax is a nice, robust
behavior, but it doesn't cut it.

------
audionerd
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-...](http://thinkweb2.com/projects/prototype/feature-testing-css-
properties/)

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

~~~
audionerd
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".

------
pohl
I don't know...can we really trust all browser vendors to only claim
@supported for a given feature when it's genuinely compliant, including all
edge cases?

~~~
wvenable
Or, as it historically been the case, a browser vendor implements the feature
(so it's "supported") but they do it wrong.

As much as people hate to hear it, the only real solution is some kind of
browser-version tagging. If it wasn't for Microsoft's browsers supporting
browser-specific conditional comments, we'd have a much harder time writing
standards-compliant web pages that work the same for every browser.

~~~
chriseppstein
Using hacks to work around bugs, is tolerable, perhaps. But for the common
case where a feature is only partially implemented across a swath of browsers,
I think feature inspection works great. It won't be a panacea, but it will be
a step in the right direction.

------
thwarted
How many CSS hacks are necessary because a browser acknowledges support for
something or doesn't support something versus having a totally broken
implementation of something? In otherwords, this wouldn't fix at all being
able to conditionnally choose CSS for IE's busted hasLayout oddity, nor would
it allow non-hacky CSS to work around different box models, because we didn't
even have names for these things when they were discovered and parsing bugs
were discovered to allow some browsers to see the rules and others not to.

------
alabut
You can already do this with the Modernizr javascript library, it works just
like the blog post described:

<http://modernizr.com/>

It's a good approach - target only supported features through CSS inheritance.
It's what I used to make my first commercial site with HTML5 and CSS3:

<http://theprbootcamp.com> (happening this Thursday in SF)

It was great, it made certain visual effects completely painless and degrades
to a very similar but more square layout in IE6. It's not that you can't do
rounded corners, dropshadows, multiple background images, gradients or have an
IE6-friendly site design w/o it, it's just a giant time saver - I whipped
together that site in less than a day - and the markup came out way cleaner.

No need to wait for the W3C to make a proposal or browser makers to integrate
it, and you could remove the javascript if they ever come around.

------
puffythefish
This would be nice, but it's not really feasible since it requires the browser
vendor to implement a feature for backwards compatibility (kind of an
oxymoron, isn't it?)

~~~
eli
Or it's just forward-thinking to the point where every browser in use is
already on CSS3 and we're trying to decide what CSS4 features to use in our
sites...

------
misterbwong
This is what I've been doing and it has worked relatively well.

    
    
      <!--[if lte IE 7]>
         <body class="ie67">
      <![endif]-->
      <!--[if !IE]>-->
      <body>
      <!--<![endif]-->
    

This allows me to target IE6/7 with the .ie67 class

~~~
jamesbritt
How do you validate your markup like that?

