Summary

  • The W3C's first public CSS Conditional Rules Working Draft, dated 1 September 2011, introduced @supports as a way to condition a group of CSS rules on the processor's support for a property and value. The 11 September 2012 Working Draft developed that model.
  • The 4 April 2013 Candidate Recommendation specified not, and and or combinations. Its support answer was tied to accepting a declaration with usable implementation, a definition retained in the 13 January 2022 Candidate Recommendation Snapshot. The author still had to design the alternative layout.

The designer wanted a flexible navigation bar. The browser had a résumé that was difficult to read from a distance: it could accept some CSS declarations, ignore others, and sometimes honour a declaration while a reader's settings changed its visible result. Assigning a whole page layout to a single new value without asking any questions was the equivalent of hiring on the strength of a handshake. CSS needed an interview, with the question written down.

CSS already knew how to step around words it did not understand. An unknown property or unsupported value could be ignored while other declarations continued. That quiet resilience was useful for a single color or border. It became less comfortable when a new layout needed several related rules to move together. If one part of the arrangement arrived and another did not, the page might resemble an office where the desks had been moved but the doors had stayed behind.

The W3C's first public Working Draft of CSS Conditional Rules, published on 1 September 2011, proposed a more deliberate conversation. Its @supports rule attached a block of CSS to a question about implementation support for a property and value. The document used a new layout mechanism to explain why grouping mattered: an author could put the styles for the new arrangement together and write a separate arrangement for an implementation that gave the other answer. The draft also explored @document; that branch of the early document did not become the central story of the later 2013 Candidate Recommendation.

The syntax turned the interview into something a stylesheet could carry. A condition such as @supports (display: flex) asks whether the browser supports that declaration. not can put an alternative block behind a negative answer. and can require two qualifications at once; or can accept either of two routes. The 11 September 2012 Working Draft developed this grammar and its examples. The designer could name the exact capability on which a group of layout rules depended, rather than guessing from the browser's name or age.

The Candidate Recommendation of 4 April 2013 made the arrangement clearer. In one example, a support condition encloses the rules for a flexible layout; another condition using not encloses widths for the alternative. The specification notes that the alternative widths could harm the flexible version if both sets were applied together. This is the practical point of the interview. The answer controls the entire outfit, not merely the lapel pin. The author still decides how good each outfit is.

What counts as a yes? The 2013 text describes a processor as supporting a declaration when it accepts the property and value instead of discarding them as a parse error, and requires a usable level of implementation for the value. The 13 January 2022 Candidate Recommendation Snapshot states the test explicitly for a declaration within a style rule. It also explains why merely ignoring unsupported declarations is insufficient when a new layout depends on a family of rules. A qualification check can keep that family together.

The answer has a precise limit. The specification uses a reader's high-contrast preference as an example: the processor can support color even when that preference overrides the visible color. The interview checks support for a declaration; the finished page is affected by the cascade, user settings, surrounding rules and the layout that the author wrote. A browser saying yes to display: flex has answered the question on the card. It has not reviewed the navigation bar's taste in spacing.

This is why a fallback deserves genuine design work. The alternative block in an @supports not (...) branch cannot be a box of leftovers that happens to parse. It needs a workable reading order and usable widths. The positive branch needs inspection too, because the support test selects a set of rules, and those rules must solve the actual page. The browser can truthfully pass an interview and still be handed a poor assignment.

A public W3C tutorial presented by Bert Bos at WWW2013 put the question in front of an audience. Its runnable demonstration started with six hidden status paragraphs and revealed different ones through positive, negative and combined @supports conditions. One condition asked about display: flex; another tested an alternative value, and an or combined choices. The little page made the decision visible without pretending that a support answer designed the rest of a publication for its author.

The dates trace a developing specification, not a sudden global switch. The first public draft was in 2011, another Working Draft in 2012, a Candidate Recommendation in 2013 and a Candidate Recommendation Snapshot in 2022. Those publications define the questions and the intended answers. They do not supply a head count of browsers in any year. The durable change was editorial and technical at once: authors could make a capability decision inside CSS and keep related presentation rules on the same side of that decision.

CSS gave the browser a job interview. The question was narrow enough to answer: will this property and value be accepted with usable support? The stylesheet could then offer the modern layout or the fallback. Hiring the right candidate was only half the work. Somebody still had to design a good page for the candidate to build.