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

On Mon, Oct 10, 2011 at 19:09, Paul Irish <paul.irish@gmail.com> wrote:

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

The primary reason for matchMedia to return a MediaQueryList object is that
media queries can change while the page is active, and thus provides
listeners for it.  Considering an engine's support for certain CSS
properties is unlikely to change during a page's execution, a simpler API
may be more appropriate.

window.supportsStyle('width: 1fr');

Going even further, part of the parsing step could be circumvented by
accepting two arguments, the property name and the value:

window.supportsStyle('width', '1fr');

Neither would not support checking multiple property-value pairs at once,
but it reduces complexity significantly.


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

How would you differentiate between "or" and "and"? One may want to check
for:

@supports (box-shadow: 0 0 0 0 red) and (box-shadow: 0 0 0 0 red inset) {}

Best,
Peter

[1] http://www.w3.org/TR/2011/WD-cssom-view-20110804/#mediaquerylist

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
>