Re: [css3-conditional] feature queries

On 15/06/2011 2:49 PM, Boris Zbarsky wrote:
> On 6/15/11 12:36 AM, Alan Gresley wrote:
>> Can you give examples of current and possible future properties and/or
>> values
> There are currently proposed new values for background-image (e.g.
> gradients, image(), etc), position/display, every single property that
> takes lengths (calc()). That's off the top of my head after about 5
> second of thought.

True but can these also be done by just querying the support of just a 
value? For me, @supports would be more powerful if instead of just 
property value pairs, something more like this.

@supports-transform (rotate()) { ... }

@supports-transform (rotateX()) { ... }

@supports-perspective { ... }

@supports-animation (iteration-delay) { ... }


@supports-animation-iteration-delay () { ... }

This way, you don't have to repeat the property over and over but at the 
same time, this is possible.

@supports ( property: value ) { ... }

>> but keeping in mind that support for @supports is currently not
>> present and such support may come after certain properties and values
>> are un-prefixed and interoperable?
> Why does that matter, unless you think CSS development is likely to stop
> entirely in the near future?

It matters since the possible uses are wildly changing. Just think, how 
would you query for '/' in a background shorthand or something like $ or &?

>> I agree with this point but why should browsers continue to lie?
> Because when asked whether 'display' is supported it's a lot easier to
> say 'yes' than to say 'no' if you support all but one value of the
> property.

@supports-display (?) { ... }

@supports-display (?, ?) { ... }

> More to the point, if you (an implementor) support _all_ the values for
> 'display' at some point and return 'yes' as a result and then a new
> value is added in some CSS module that you don't support yet, you won't
> start returning 'no' for 'display' support, right?

I totally agree but please see above.

> So any system that tests for support for support on a per-property basis
> completely falls down when new values are added to properties.... which
> is happening all the time.


>>  From my authoring perspective, my main issue has been support of
> background-size
>> (either the background-property or in background shorthand).
> Those are actually separate questions, no? A UA can easily support
> background-size on its own but not in the background shorthand... which
> you can't detect without being able to ask whether the 'background'
> property accepts syntax including a size. Note that obviously all UAs
> will claim to support the 'background' property if you just ask them
> whether they support it. So even to answer your second question you need
> property/value pair support tests.
> -Boris

It is a separate question but this is how authors have for year 
successfully dealt with coding CSS when a browser does not support 
something. Some just take a simpler route and just exploit a browser 
parsing bug.

Alan Gresley

Received on Wednesday, 15 June 2011 05:21:14 UTC