要約

  • W3Cが2011年9月1日に公開したCSS Conditional Rulesの最初の作業草案は、プロパティと値への対応を条件に規則のまとまりを適用する@supportsを導入した。2012年の草案はその文法を発展させた。
  • 2013年4月4日の勧告候補はnot、and、orの組み合わせを説明する。2022年1月13日の勧告候補スナップショットは、実用的な対応のある宣言を構文エラーとして捨てずに受け入れることを、判定の中心に置いた。

ブラウザーには以前から気の利いた振る舞いがあった。知らないCSSの宣言に出会えば、それを飛ばして次へ進める。装飾の一つなら、それで穏やかに済むことも多い。だが新しい配置は、一つの宣言だけで完成しない。列幅や順序や余白が連れ立って働く。机だけ引っ越して扉が前の場所に残ったら、編集室は奇妙な迷路になる。

2011年9月1日のW3C最初の公開作業草案は、その一式を受け持てるかブラウザーに聞く方法を示した。@supportsは、特定のプロパティと値を処理できるかという条件の中に規則をまとめる。肯定の答えには新しい配置を、別の答えには代替の配置を渡せる。初期草案には@documentもあったが、2013年の勧告候補で主役として残ったのはこの機能確認だった。

質問は@supports (display: flex)のように書く。ブラウザーの名前や発売年から能力を占うより、必要な宣言を直接尋ねる。2012年9月11日の作業草案は、否定を表すnot、複数の条件をそろえるand、どちらかを認めるorの文法を整えた。面接官は応募者に「何でもできますか」と聞くのではなく、その仕事に必要な資格を指定できる。

2013年4月4日の勧告候補にある例では、柔軟な配置の規則を肯定側にまとめ、従来の幅を使う規則をnot側に置く。後者の幅が前者にも紛れ込めば、新しい配置を邪魔しうると文書は指摘する。条件は飾りの札ではない。関連する部品を一緒に採用し、一緒に外すための仕切りである。

では、面接でいう「できます」の意味は何か。2013年の文書は、宣言を解析エラーとして捨てずに受け入れることと、その値を実用的な水準で扱えることを結び付けた。2022年1月13日の勧告候補スナップショットは、スタイル規則内の宣言を受け入れるかという形で明確に述べる。見知らぬ宣言をただ読み飛ばす方法では、配置を支える一群の規則を同じ判断の下に置けなかった。

この返事は、読者が目にする画面そのものの評価ではない。W3Cは高コントラストの設定が表示色を変える例を挙げる。ブラウザーはcolorに対応していても、読者の設定によって見える色は変わる。カスケードや周囲の規則も結果に加わる。志願者が資格を持っていることと、与えた仕事の仕上がりは別の話だ。編集者は完成したページを見なければならない。

代替配置を余り物の寄せ集めにすると、面接をした意味が薄れる。@supports not (...)側にも、読める順序と適切な幅と動く案内が要る。肯定側にも実際の記事を流し込み、見出しや表が窮屈にならないか確かめたい。規則の束を選ぶ仕組みは、二つの束の中身を上手に設計して初めて役に立つ。

2013年のW3CによるBert BosのWWW2013講義では、条件が実際のページで動いた。公開デモは最初に六つの文章を隠し、display: flexへの対応、その否定、orを使う組み合わせなどに応じて該当する文章を見せる。小さなページを開くだけで、ブラウザーの返事が表示の選択につながる。記事全体の配置を仕上げる仕事は、この実験の先にある。

2011年の最初の公開草案、2012年の作業草案、2013年の勧告候補、2022年の勧告候補スナップショット。四つの段階は、質問の文法と回答の意味を追う手掛かりになる。CSSがブラウザーへ面接を申し込めるようになったあとも、誌面を組む責任は人の側に残った。採用通知だけで良い記事面は出来上がらない。