Feature Queries Follow-Up

Back in February (eons ago in internet time), I brainstormed a possible alternative to vendor prefixes I called feature queries. After receiving a collective “meh” from my close collaborators, I assumed the idea was a misfire. Perhaps it was too verbose, too repetitive, or maybe it missed the point entirely. I accepted the concept’s shortcomings and moved on.

So imagine my surprise when I saw Stuff and Nonsense link to a Chris Mills post titled “Native CSS feature detection via the @supports rule.” A brief excerpt:

This article looks at the CSS @supports rule, part of the CSS3 Conditional Rules Module Level 3, which provides a perfect mechanism for selectively applying CSS based on feature support.

Here’s how this “perfect mechanism” works:

@supports (display:flex) {
    section { display: flex }
@supports not (display:flex) {
    section { float: left }

Looks familiar, right? I got the name wrong, my query syntax was shorter (but less straightforward) and I failed to consider operators (as detailed in the aforelinked post), but otherwise my “feature queries” came surprisingly close to the real thing.

To be clear, I’m not saying my post inspired the contents of the W3C’s working draft for this module. That would be presumptuous.

What I am saying is that I clearly possess a very specific kind of clairvoyance. With that in mind, I’d like to make a few more CSS “proposals”…

  • A new value for the font-smoothing property, use-common-sense-to-render-predictably.

  • The pill: red rule, which would specify that targeted elements are ready to face the painful truth of reality. (Default value would be blue to avoid freeing users of outdated browsers.)

  • The @pizza mechanism would reward designer-developers for well-written styles with delicious, piping-hot pizza delivered right to their door.

Your move, W3C.