Re: @media and browsers conditional statments

On Mon, Aug 11, 2008 at 1:28 AM, Alan Gresley <alan@css-class.com> wrote:
> I do believe that we should really nut out the problems in CSS2.1 with the
> support of many test cases and work on how to implement CSS3 by the rules of
> progressive enhancement.

Except that:

1) There will always be some bugs, possibly in some cases obscure.
It's not reasonable to expect browser authors to disable a feature
when a hard-to-fix and largely minor issue is uncovered at the
eleventh hour, or even well past it.  That attitude isn't followed
with CSS 2.1 or HTML 4 to this day, even in the best browsers.
Firefox, Opera, Safari, etc. all have various bugs in HTML4 or CSS2.1
support (even in the things they support in those standards) that are
acknowledged but are not major enough to block releases.  Why do you
think this will be any different for CSS3, or for that matter any
computer program anywhere ever?

2) Even if progressive enhancement is used perfectly, authors will
want to use new features before they fully sacrifice support for older
browsers.  In some cases, say with new selectors or single properties,
CSS's cascading nature and rules for error handling already make this
work very nicely.  But if you want to condition the value of property
X on whether support for property Y is present, which is necessary for
using any nontrivial new feature, that's not possible.  You either
have to use JavaScript (slows down loading, doesn't work as reliably,
and introduces all the issues people are trying to avoid anyway) or
give up either the new feature or support for the old browser.

Of course, (2) could be solved by introducing @media
supports-property(...) or whatever.  This would of course lead to
things that look like

@media supports-property(-moz-border-radius) and not
supports-property(border-radius) { /* Fx2 */

(similar things could be done without resorting to vendor-specific
properties).  So if you do this you may as well allow explicit UA
sniffing as well, since people are going to come up with really
reliable lists of rule sets very quickly and you're just making their
code uglier.

Official support for UA sniffing also gives a nice opportunity for the
standard to give a big blaring warning to be careful about using it
and clearly explain alternatives and pitfalls in a single place.  As
others have said, probably all the cookbook sites will regurgitate
this advice, at least if it's at all realistic.

> We have arrived at this point in time without the
> need of browser sniffing and spoofing into CSS so I don't think that we have
> to go down that road now.

I am far from the most experienced CSS author here.  Probably you have
much more experience than I do.  But my mind boggles at the claim that
we don't use browser sniffing in CSS.  How many complicated
stylesheets that support IE6 don't use bunches of * html hacks?  Even
if we optimistically assume that no browser as bad as IE6 will come
along anytime soon, people have given examples of where they've had to
hack around more standards-compliant browsers too (e.g., Firefox not
supporting inline-block until Fx3).

Received on Monday, 11 August 2008 14:15:02 UTC