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

Re: [css3-conditional] feature queries

From: Alan Gresley <alan@css-class.com>
Date: Wed, 15 Jun 2011 15:20:45 +1000
Message-ID: <4DF8412D.3020601@css-class.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: www-style@w3.org
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) { ... }

       or

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


Agree.


>>  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
http://css-3d.org/
http://css-class.com/
Received on Wednesday, 15 June 2011 05:21:14 GMT

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