I’d be fine with @feature, or maybe @processes (which conveys what the browser is doing better than @parses, IMO).

Unfortunately for web developers, there’s no way for a browser to reliably know how well it supports a given feature, so we’ll never (or should never) have a rule for 100% support. What @support is testing is whether the browser thinks it knows what it’s doing with the CSS rule, and that’s probably the best we can get.


@media all and (max-width: 30em) {
@supports (overflow: scroll) {
.items {
width: 100%;
overflow: scroll;
}
.items .item-list {
width: 600%;
}
.items .item {
width: 15%;
}
}
}


I’m saying that those are the conditions under which I’d gladly make regular use of such a construct.

And to clear up an ambiguity — I’m not saying the privilege would go to a vendor that supports the whole MODULE, just to the vendor that implements the property as spec’d and utilized by the stylist.

In other news, writing software is hard. Film at 11.

This is an optional extension to the existing CSS spec, which simply conditionally applies the stuff in it. this would still work as usual.

body {
color: black;
}

CSS has fault-tolerance at its core. If a browser doesn’t support `color:black`, the rule just won’t be applied. It’s just like using Modernizr, but with finer precision and it *will* be more accurate.

@Sean – this doesn’t restrict WG at all… if anything it gives them more power to change things. A change in a spec? Fine – I can just do:

@supports (feature:oldsyntax) {
// Styles for old syntax
}
@supports (feature:newsyntax) {
// Styles for new syntax
}

@paulirish gave the following example:

@supports not ( display: flexbox ) {
body { width: 100%; height: 100%; background: white; color: black; }
#navigation { width: 25%; }
#article { width: 75%; }
}

but what if color:black is not supported on some (wierd) browser? [and being “@supports complient” if you test for @supports (color:black) it would actually fail.

So should this be:

@supports ( (not (display: flexbox)) and (width:100%) and (height:100%) and (background:white) and (color:black) .... ) {
body { width: 100%; height: 100%; background: white; color: black; }
#navigation { width: 25%; }
#article { width: 75%; }
}


It feels odd that you have to spell out everything that you want to do…

Maybe any @supports statement should also imply support to any mentioned property:value combination in the applyed rules ?

I understand the reasoning claiming that that this would make browsers accountable for actually supporting what they claim to support,
but at the same time it would mean that it makes it easier for them to relase “half-backed” versions as long as they properly state that they are indeed “half-backed”.

I’m not sure how @supports is an improvement on the current landscape.

@supports gives browser & device vendors the ability to say “Hey, we made this cool new thing, but it doesn’t support position:fixed at this time” and accurately expose that sudden lack of support to websites in a proper, clean fashion.

Is it too late for the existing examples of pos:fixed or overflow:hidden? Sure. But better to start late than never. This facilitates better behavior going forward, which is what spec development is all about.

@supports is, again, way more explicit than anything else.

I’m still not convinced of this. Given today’s implementation, how would either of these hold up?

@supports (position: fixed) { … }
@supports (overflow: hidden) { … }

Given the number of hacks/polyfills we need to implement these two properties effectively, I’m not sure how @supports is an improvement on the current landscape. It feels like codified inaccuracy, especially since the “usable level of support” is left to the implementing UAs.

I’m not down on the idea of moving CSS feature detection out of JavaScript, mind. Honestly, @supports would be a huge, huge improvement over, say, the first half of this position: fixed polyfill. But anything beyond that feels like it should be backed by conformance testing, or we’ll be back where we started.

And I can just imagine what will happen when something that’s already recognized with @supports in multiple browsers is found to be flawed and in need of change. Does the WG (and browser vendors) decide to break deployed sites, come up with some other syntax, or just ignore the problem? “We have customers!” will once again ring forth, is my guess.

As for what I propose as an alternative, well, you’ve already heard it: call feature detection what it really is. You just happen to dislike the idea, which is fine. I didn’t actually expect this to be a popular point of view.

…And as you imply, the definition of “usable” needs to be changed to “complies fully with the Recommendation at Level 3 or higher.” 

There are two problems with this definition.

1) There aren’t enough people writing test suites. There are rarely cross-vendor test suites for new features and so we can’t evaluate well the conformance of an implementation
2) Nobody would pass. For more mature test suites, 100% conformance rarely happens. See http://samples.msdn.microsoft.com/ietestcenter/ as evidence that “stable” css3 features rarely pass these suites.

Not throwing a fit about encountering background-size: cover; is a very implicit promise that it works. But it doesn’t necessarily.

@supports (background-size: cover) {…} is a much more explicit promise.