For example, it makes sense to have a native @support CSS rule checking for things like border-box support.
But what about detecting features that are separate from rendering? Should @support check for geolocation?
If not, where does that test live - javascript (modernizr, yepnope)? Is separating tests based on type of feature a good thing? If so, how should the interactions between display and feature be intelligently managed? If not, is CSS, Javascript, or some other layer the appropriate place to consolidate tests?
Testing for non-rendering concerns in CSS doesn't make any sense to me, and I'm afraid our future will be HTML markup full of classes namespaced by concern, managed by javascript & feature detection. It's an evolution, but hardly elegant. (class="js-toggle function-geolocation structure-list typography-chrome")
>>The ‘@supports’ rule is a conditional group rule whose condition tests whether the user agent supports CSS property:value pairs.
Source - http://dev.w3.org/csswg/css3-conditional/#at-supports
So, no. @supports will check for css rules, and nothing else.
That would just be silly.
My point is only that the alternatives aren't all that less silly, at least from an actually-building-and-maintaining perspective.
I'm not confident if that made sense, but basically I'm concerned that we're (re)creating a personally oft-encountered tension where the individuals that best understand a complex syntax are the least able to create anything aesthetically-pleasing, let alone usable, from it...