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.

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

@generalk You're right, I sure wish there was a better way. Do you have one?

Also, you could decide to not use this particular aspect of the syntax if it offends you, could you not? Those of us who have to support ie6 for the next three years, do not have that luxury.

For the record, I probably will have to support IE6 for the next few years, so I don't have any luxuries here either.

If we're just proposing new ideas, suppose we create a new tag to link CSS3 documents to HTML documents? <stylesheet>, perhaps. Newer browsers know what to do with it, while older browsers ignore it. This is just off the top of my head, of course, I haven't thoroughly studied this problem.

I don't mean any personal offense, I just don't like the idea of putting code in comments.

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.

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.

By this syntax they aren't comments anymore.

The fact that Javascript works inside of SGML comments inside a <script> tag continues to annoy me, more than a decade later.

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?

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.

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.

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

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.

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

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.

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.

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?)

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

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

How do you validate your markup like that?