Re: [css3-conditional] feature queries

On Tue, Jun 14, 2011 at 10:20 PM, Alan Gresley <alan@css-class.com> wrote:
> 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()) { ... }

These seem to just be testing property-value pairs.


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

These seem to just be testing property names, which we've already said
is not acceptable.

Additionally, none of these allow the support algebra that the current
spec does, where you can use 'or', 'and', and 'not' to test for
combinations of multiple support queries.


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

No, the possible uses it's intended for have been present since the
beginning of CSS, and we expect them to continue to exist as long as
CSS does.

> Just think, how
> would you query for '/' in a background shorthand or something like $ or &?

For the former, just use the / in the value when you test the
'background' property.

The latter two can't be tested, as they're syntax changes.  That's
okay, @supports doesn't have to necessarily hit every possibility.
Those types of changes are very rare in practice.


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

@supports (display:?) {}

What's the difference?


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

This is an argument to not do @supports at all.

Note, though, that many of the newer things we're exploring now (new
layout modes, Regions, etc.) are *not* really amenable to the normal
CSS fallback techniques.  You end up applying substantially different
CSS if they're supported or not.  So @supports is more needed now and
in the near future than anytime before.

~TJ

Received on Wednesday, 15 June 2011 17:30:03 UTC