W3C home > Mailing lists > Public > www-style@w3.org > August 2012

CSS feature detection queries

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Wed, 22 Aug 2012 07:30:40 +0200
Message-ID: <CAOxFTczRVycTz016k_U18wro1n0Snjn67PE9iiRs1G9TcMyoXw@mail.gmail.com>
To: WWW Style <www-style@w3.org>
Hello all,

I've recently found myself thinking about situations in which some
kind of ‘feature detection’ for CSS browser support might be necessary
(see later for details on such motivations). I've googled for relevant
threads on this mailing list, but it seems to me that the main
proposals that have been made on related topics have been focused on
_browser_ detection. I'm extremely wary of approaches based on the
user agent name or version, remembering how laziness from web
developers and incorrect UA detection in Javascript has crippled the
browsing experience of users of minoriry-share browsers such as
Opera), so I agree with everybody that has rejected such proposals.

Browser detection is generally used for two things in Javascript:
working around bugs in specific implementation, and 'feature
detection'. In the latter case, browser detection is the _wrong_ way
to go, and the smart javascript author knows that the correct way to
do feature detection is to _actually check for the feature_ before
usage (hence the typical cascades of ifs that are found for
XMLHttpRequest support or even just the switch for event listener
handling). And this is what, IMO, should be added to CSS. Of course,
feature detection still doesn't allow working around implementation
bugs, but that's not what I'm interested in. What I care about is
obtaining sensible layouts depending on supported CSS features.

Now, why do I think such a thing might be necessary? it is my
understanding that the preferred approach to support multiple browsers
which may have a varying degree of support for CSS features are
graceful degradation and progressive enhancement, the idea behind
which is to write styles in such a way that

(1) lack of support for a given feature still makes a usable layout possible and
(2) more sophisticated rules are declared later in CSS, so that they
may override the less sophisticated rules which will be used by the
browsers that do not support the more features in the more
sophisticated rules.

and I believe that this is one of the most powerful side-effects of
the Cascading nature of CSS, which can generally be deployed quite
well.

However, these approaches only work when the fall-back from the more
to the less sophisticated features, and when other property values do
_not_ change due to the presence (or absence) of the other effect.

The simplest example of such a thing I can think of is give by
text-shadow, where you may want to use a distinct color and
background-color when text-shadow is not available, and the same color
and background-color when text-shadow is available (relying on
text-shadow to outline the text or to achieve an inset or outset
effect).

The necessity for property value changes that go all over the
stylesheet depending on whether the features are available or not
grows with the upcoming layout power of things such as columns,
flexbox and newer box sizing values.

Consider for example following situation: I have a document whose main
#container contains a number of DIVs, each with a long stream of text.
I don't want to have loooooooooooooong lines, so I clip the inner DIVs
width at 32em and place as many as possible of them side by side
(display: inline-block).
However, with columns, I could have the DIVs remain block elements
(display: block), un-limit their width maybe limit their height and
put columns in them instead. Very different layout, and the transition
between the two is not a simple matter of falling back to the previous
value for individual properties, because the values are
interconnected.

So I believe that some kind of feature detection _is_ needed in CSS.
I'm not going into details about the _syntax_ though, although it's
quite obvious IMO that it should follow the @media query syntax. It
could be done with a new keyword, such as

@feature columns { /* CSS for when columns are available */ }

or we could abuse the @media keyword itself

@media (feature: 'columns') { ... }

or even something more subtle such as detecting if a given declaration
would be considered valid or not (might also be useful to have
something that trips in case of some browser bugs):

@media (accepts: 'width: fit-content') { ... }

or whatever. The specifics can be discussed assuming the need for
in-CSS feature detection is acknowledge.

Thoughs?

-- 
Giuseppe "Oblomov" Bilotta
Received on Wednesday, 22 August 2012 05:31:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT