W3C home > Mailing lists > Public > www-style@w3.org > January 2013

[css3-conditional] @supports all

From: Nicholas Shanks <nickshanks@nickshanks.com>
Date: Fri, 25 Jan 2013 13:27:34 +0000
Message-ID: <CA+hEJVUfAL1F6jiUrcvV1qZmwFN0VXSZihkRhtx-ie+KmSpKfA@mail.gmail.com>
To: www-style list <www-style@w3.org>
I would like to propose an additional keyword for @supports, "all".
When this is specified, all properties within the at-rule must be supported.

for example:

@supports all {
    body { color: white; background-color: black; }
}

is shorthand for:

@supports (color:white) and (background-color:black) {
    body { color: white; background-color: black; }
}

There is one caveat with this: This shorthand could not be used in
conjunction with multiple vendor prefixes.


The consideration which led to me suggesting the above was this: authors
may assume that all properties are implemented but one, and so only test
for that one, but in reality a UA might implement that but not another.
Consider:

@supports (background-color:black) {
    body { color: white; background-color: black; }
}

The author has assumed that all UAs support (color:white), and that
background-color is the funky new property which is only supported by a few
UAs.
Now along comes a UA which supports (background-color:black) but not
(color:white). What happens? The conditional will pass and the website will
break (e.g. black text on a black background)!
It will become far too tedious to duplicate all the CSS code into the
conditional linking them with "and", especially as the block may have many
many rules, which is why I suggest a single, simple keyword, "all".
It might also be worth pointing out that this is not related to the
property "all", as in @supports (all:default) {...}



It is also obvious that @supports can be used to filter rules by client,
without having to load secondary stylesheets via conditional
comments/ua-sniffing/css hacks:

@supports (*-ms-accelerator:true) {*
*    /* general rules for internet explorer ... */*
*}*

This may lead to fragile web code, but I don't see how it can be avoided.
Perhaps advice could be given in the spec that this is not a good idea.

-- 
Nicholas.
Received on Friday, 25 January 2013 13:28:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT