Re: [css3-conditional] feature queries

On 6/15/11 1:20 AM, Alan Gresley wrote:
>> 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?

Yes, of course.

> For me, @supports would be more powerful if instead of just
> property value pairs, something more like this.
>
> @supports-transform (rotate()) { ... }

@supports (transform: rotate(0deg)) {}

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

@supports (animation-iteration-delay: 0s)

> This way, you don't have to repeat the property over and over

So you're trying to optimize for this use case:

   @supports ((display: inline) and (display: block))

by having some sort of syntactic sugar for it?  Or something else?

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

The question is what other things are needed.  I don't quite understand 
what your proposal is.

> It matters since the possible uses are wildly changing. Just think, how
> would you query for '/' in a background shorthand

@supports (background: some-value-with-/-in-it)

> or something like $ or &?

This is indeed unaddressed in the current proposal, but how would you 
use this in practice?

>> 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 (?) { ... }

How is this different from:

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

?

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

I thought we were trying to give them a better option here...

-Boris

Received on Wednesday, 15 June 2011 17:40:49 UTC