W3C home > Mailing lists > Public > www-style@w3.org > October 2011

[css3-conditional] @supports API, alternate OR syntax

From: Paul Irish <paul.irish@gmail.com>
Date: Mon, 10 Oct 2011 11:09:53 -0700
Message-ID: <CAHSVx=8sOOh=5Wr2cv4eUhT8AzWTdnPybpFF-WR5ujEqEESwiA@mail.gmail.com>
To: www-style@w3.org
@supports will be hugely useful to developers and I'm very pleased with its
syntax (in a stark contrast to the hasFeature API).

However, there is mention in the draft[1] about a potential API. Let me try
to illuminate why one is needed.

Modernizr is a feature detection library used by thousands of developers [2]
to determine support of CSS3 and HTML5 features for each browser without a
useragent sniff.

I maintain it, and while I love working on it I would love more to see it
die off. :)
Most developers use it to detect support of CSS3 features and as a result,
do one of two things:

1) provide alternate styles if either the feature is present or lacking
2) use a javascript polyfill to mimic support of that feature.

The second use case isn't fulfilled well by the current draft, but there is
huge demand judging by the number of polyfills to backfill CSS3
functionality in older browsers. [3]

Providing an API for this would be similar to what's been done for
matchMedia.


Without an API, the workaround is:
* construct a stylesheet
* populate it with some arbitrary style that operates on a uniquely
identifiable element
* create that element
* inject both into the DOM
* test to see if the style succeeded through getComputedStyle
* remove elements from DOM

This is a costly way to understand what the browser already knows.
Therefore, I'd love to see a matchSupports (or an equivalent) API:

    window.matchSupports('(text-overflow: ellipsis)').matches // true




Secondly, on disjunction, I have a concern. I imagine much of the time
authors will be using @supports for new properties, and as such they'll be
vendor prefixed. This is illustrated in a spec example:

@supports ( box-shadow: 2px 2px 2px black ) or
          ( -moz-box-shadow: 2px 2px 2px black ) or
          ( -webkit-box-shadow: 2px 2px 2px black ) or
          ( -o-box-shadow: 2px 2px 2px black ) {
  ...
}

Is it reasonable to assume that multiple rules within a pair of parens mean
the same thing? So, instead, like so...

@supports ( box-shadow: 2px 2px 2px black; -moz-box-shadow: 2px 2px 2px
black; -webkit-box-shadow: 2px 2px 2px black; -o-box-shadow: 2px 2px 2px
black ) {
  ...
}

Without checking the spec, that's how I had assumed things had worked.


To be clear that sugar would be pleasant but certainly not a showstopper,
and I'm most interested in an API. :)

[1] http://dev.w3.org/csswg/css3-conditional/#apis
[2] http://trends.builtwith.com/javascript/Modernizr
[3]
https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills


Thanks,

_
Paul Irish
http://paulirish.com
Received on Monday, 10 October 2011 18:11:01 GMT

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