CSS 条件付き規則モジュール レベル3

1. 導入

1.1. 背景

このセクションは規範的なものではありません。

[CSS21] は条件付きグループ規則の一種である @media 規則を定義しており、その中にはスタイル規則のみ（他の @規則は不可）を許可しています。@media 規則は、メディア固有のスタイルシートを実現するための機能を提供しますが、これは @import や link などのスタイルシート連携機能でも提供されています。@media 規則内の内容に対する制限は、その有用性を低下させていました。@規則を含むCSS機能をメディア固有スタイルシートで利用する場合、著者はメディアごとに別のスタイルシートを使わざるを得ませんでした。

本仕様は、条件付きグループ規則内の内容のルールを拡張し、他の @規則も許可することで、著者が@規則を含むCSS機能とメディア固有スタイルシートを1つのスタイルシート内で組み合わせて利用できるようにします。

さらに本仕様では、著者やユーザーの要件に対応するため、もう1種類の条件付きグループ規則 @supports も定義しています。

@supports 規則は、CSSプロパティや値の実装サポートに基づいてCSSを条件付けることを可能にします。この規則により、著者は新しいCSS機能を使いやすくなり、それらの機能をサポートしない実装に対しても適切なフォールバックを容易に提供できます。特に新しいレイアウト機構を提供するCSS機能や、プロパティサポートに基づいて一連の関連スタイルを条件付けたい場合に重要です。

1.2. モジュールの相互作用

このモジュールは、@media 規則機能を [CSS21] セクション7.2.1で定義された内容を置き換え・拡張し、さらに [MEDIAQUERIES-4] セクション1で非規範的に行われていた修正を取り込みます。

2. 条件付きグループ規則の処理

本仕様では、いくつかのCSSat-規則（条件付きグループ規則と呼ばれる）を定義し、それらは条件と一群のCSSルールを関連付けます。これらの異なる規則は様々な種類の条件を判定できますが、条件が真のとき／偽のときに内容がどう扱われるかについて共通の挙動を持っています。

@media print {
  /* 印刷時にナビゲーションコントロールを非表示にする */
  #navigation { display: none }
}

各条件付きグループ規則は「条件」を持ち、その条件は常に真または偽に評価されます。条件が真のとき、CSSプロセッサは必ずグループ規則内のルールを、あたかもグループ規則の位置にあるかのように適用しなければなりません。条件が偽のとき、CSSプロセッサは絶対にグループ規則内のルールを適用してはなりません。条件の現在の状態はCSSオブジェクトモデルには影響せず、グループ規則の内容は常にその内部にとどまります。

つまり、複数の条件付きグループ規則がネストしている場合、両方の条件が真のときのみ、その中のルールが適用されます。

@media print { /* 規則 (1) */
  /* 印刷時にナビゲーションコントロールを非表示にする */
  #navigation { display: none }
  @media (max-width: 12cm) { /* 規則 (2) */
    /* 狭いページ幅で印刷する場合はノートをフロー内に保つ */
    .note { float: none }
  }
}

条件付きグループ規則の条件が変化した場合、CSSプロセッサは、プロパティ定義により値の寿命を超えて計算値の効果が持続するもの（[CSS3-TRANSITIONS] や [CSS3-ANIMATIONS] の一部プロパティなど）を除き、ルールが今適用されるかされなくなったかを必ず反映しなければなりません。

3. 条件付きグループ規則の内容

すべての条件付きグループ規則は、ブロック内で<rule-list>をとるように定義されており、スタイルシートのトップレベルで通常許可されていて、他に制限されていない任意の規則を許可します。 （例えば、@import規則はスタイルシートの実際の先頭でのみ有効なので、他の規則の中では無効です。）

<rule-list> 内の無効または未知の規則は無効と見なされ無視されますが、条件付きグループ規則自体は無効になりません。

条件付きグループ規則で使用される名前空間プレフィックスは、必ず宣言されていなければならず、そうでない場合は無効となります。

@namespace x url(http://www.w3.org/1999/xlink);
@supports (content: attr(x|href)) {
  // 何かを行う }

@supports (content: attr(n|tooltip)) {
  // 何かを行う }

4. 条件付きグループ規則の配置

条件付きグループ規則は、スタイル規則が許可される場所（スタイルシートのトップレベルや他の条件付きグループ規則の内部など）で利用できます。 CSSプロセッサは必ずこれらの規則を上記の通り処理しなければなりません。

スタイル規則の後で許可されていないat規則（例：@charset、@import、または@namespace規則）は、条件付きグループ規則の後でも許可されません。そのため、そのように配置された場合は無効となります。

5. メディア固有スタイルシート：@media規則

@media規則は、条件がメディアクエリである条件付きグループ規則です。 その構文は次の通りです：

@media <media-query-list> {
  <rule-list>
}

これは@mediaというatキーワードの後に、（空でもよい）メディアクエリリスト（[MEDIAQUERIES-4]で定義）、そして任意の規則を含むブロックが続きます。 規則の条件はメディアクエリの結果です。

@media screen and (min-width: 35em),
       print and (min-width: 40em) {
  #section_navigation { float: left; width: 10em; }
}

6. 機能クエリ：@supports規則

@supports規則は、ユーザーエージェントがCSSのproperty:valueペアをサポートしているかどうかを判定する条件を持つ条件付きグループ規則です。著者は、機能が利用できる場合は新しい機能を使い、利用できない場合はフォールバックするスタイルシートを書くことができます。 これらのクエリはCSS機能クエリまたは（口語的に）supportsクエリと呼ばれます。

注: CSSには未サポートのプロパティや値を無視するなどの段階的な劣化への既存手段がありますが、特定機能のサポートにスタイル群全体を結びつけたい場合（新しいレイアウトシステムの利用時など）には不十分なことがあります。

@supports規則の条件の構文は、<media-condition>（[MEDIAQUERIES-4]で定義）に似ていますが、「unknown」値のロジックはありません：

• 否定（not）は、新機能スタイルとフォールバックスタイルを（@規則の構文に関する前方互換文法の範囲内で）分離し、互いに上書きしないようにするために必要です。

• かつ（and）は、複数の必須機能を同時に判定するために必要です。

• または（or）は、あるスタイル群に複数の代替機能（特にベンダープレフィックス付きプロパティや値）がある場合に必要です。

したがって、@supports規則の構文は、property:valueペアの判定や、それらの任意の論理積（and）、論理和（or）、否定（not）を記述できます。

@supports規則の構文は次の通りです：

@supports <supports-condition> {
  <rule-list>
}

<supports-condition>は次のように定義されます：

<supports-condition> = not <supports-in-parens>
                     | <supports-in-parens> [ and <supports-in-parens> ]*
                     | <supports-in-parens> [ or <supports-in-parens> ]*
<supports-in-parens> = ( <supports-condition> ) | <supports-feature> | <general-enclosed>
<supports-feature> = <supports-decl>
<supports-decl> = ( <declaration> )

この文法は将来の拡張性のために意図的に緩やかになっています。<general-enclosed>生成規則によって将来的な拡張が大きく許容されます。 上記の文法に従ってパースできない@supports規則（つまり、この緩やかな文法（<general-enclosed>生成規則を含む）に合致しないもの）は無効です。 スタイルシートはこのような規則を使用してはならず、プロセッサはそのような規則（その内容も含む）を無視しなければなりません。

これらの文法用語のそれぞれには、以下のようにブール値の結果が関連付けられています。

<supports-condition>

<supports-in-parens>

結果は子の部分式の結果です。

not <supports-in-parens>

結果は<supports-in-parens>項の否定です。

テスト

Notはsupports条件を否定します。

• at-supports-009.html (ライブテスト) (ソース)
• at-supports-010.html (ライブテスト) (ソース)
• css-supports-016.xht (ライブテスト) (ソース)

---

Notの後には空白が必要です。

• at-supports-014.html (ライブテスト) (ソース)
• css-supports-038.xht (ライブテスト) (ソース)

---

Notは括弧が必要です。

• css-supports-017.xht (ライブテスト) (ソース)
• css-supports-018.xht (ライブテスト) (ソース)

---

<supports-in-parens> [ and <supports-in-parens> ]*

すべての<supports-in-parens>子項目がtrueの場合にtrueとなり、そうでなければfalseとなります。

テスト

and条件はすべての連結条件がtrueの場合のみtrueです。

• at-supports-007.html (ライブテスト) (ソース)
• at-supports-010.html (ライブテスト) (ソース)
• at-supports-012.html (ライブテスト) (ソース)
• css-supports-008.xht (ライブテスト) (ソース)
• css-supports-009.xht (ライブテスト) (ソース)
• css-supports-010.xht (ライブテスト) (ソース)
• css-supports-012.xht (ライブテスト) (ソース)

---

andは括弧が必要です。

• css-supports-019.xht (ライブテスト) (ソース)

---

<supports-in-parens> [ or <supports-in-parens> ]*

すべての<supports-in-parens>子項目がfalseの場合にfalseとなり、そうでなければtrueとなります。

テスト

or条件は連結条件のいずれかがtrueであればtrueです。

• at-supports-008.html (ライブテスト) (ソース)
• at-supports-010.html (ライブテスト) (ソース)
• at-supports-013.html (ライブテスト) (ソース)
• css-supports-006.xht (ライブテスト) (ソース)
• css-supports-007.xht (ライブテスト) (ソース)
• css-supports-011.xht (ライブテスト) (ソース)
• css-supports-021.xht (ライブテスト) (ソース)

---

orの後には空白が必要です。

• at-supports-043.html (ライブテスト) (ソース)
• css-supports-039.xht (ライブテスト) (ソース)

---

orは括弧が必要です。

• css-supports-029.xht (ライブテスト) (ソース)
• css-supports-030.xht (ライブテスト) (ソース)

---

<supports-decl>

UAが括弧内の宣言をサポートしている場合にtrueとなります。

テスト

サポート条件は宣言がサポートされている場合のみtrueです。

• at-supports-001.html (ライブテスト) (ソース)
• at-supports-017.html (ライブテスト) (ソース)
• at-supports-018.html (ライブテスト) (ソース)
• css-supports-001.xht (ライブテスト) (ソース)

---

宣言にセミコロンは含められません。

• at-supports-038.html (ライブテスト) (ソース)
• at-supports-039.html (ライブテスト) (ソース)

---

宣言値は空でもよいです。

• css-supports-022.xht (ライブテスト) (ソース)

---

宣言に無効な!トークンは含められません。

• css-supports-043.xht (ライブテスト) (ソース)
• css-supports-044.xht (ライブテスト) (ソース)
• css-supports-045.xht (ライブテスト) (ソース)

---

<general-enclosed>

結果はfalseです。

著者は自分のスタイルシートで<general-enclosed>を使用してはなりません。これは将来の互換性のためだけに存在し、新しい構文追加が古いユーザーエージェントで<supports-condition>全体の大部分を無効にしないためです。

テスト

認識されないが文法上有効な条件はfalseとなり、無効にはなりません。

• at-supports-015.html (ライブテスト) (ソース)
• at-supports-046.html (ライブテスト) (ソース)
• css-supports-023.xht (ライブテスト) (ソース)
• css-supports-031.xht (ライブテスト) (ソース)
• css-supports-032.xht (ライブテスト) (ソース)
• css-supports-033.xht (ライブテスト) (ソース)
• css-supports-034.xht (ライブテスト) (ソース)
• css-supports-036.xht (ライブテスト) (ソース)
• css-supports-040.xht (ライブテスト) (ソース)
• css-supports-041.xht (ライブテスト) (ソース)
• css-supports-042.xht (ライブテスト) (ソース)
• css-supports-046.xht (ライブテスト) (ソース)

---

括弧/丸括弧はバランスがとれている必要があります

• css-supports-035.xht (ライブテスト) (ソース)

---

@supports規則の条件は、前置部にある<supports-condition>の結果です。

@supports ( display: flex ) {
  body, #navigation, #content { display: flex; }
  #navigation { background: blue; color: white; }
  #article { background: white; color: black; }
}

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

.noticebox {
  border: 1px solid black;
  padding: 1px;
}
@supports ( box-shadow: 0 0 2px black inset ) or
          ( -moz-box-shadow: 0 0 2px black inset ) or
          ( -webkit-box-shadow: 0 0 2px black inset ) or
          ( -o-box-shadow: 0 0 2px black inset ) {
  .noticebox {
    -moz-box-shadow: 0 0 2px black inset;
    -webkit-box-shadow: 0 0 2px black inset;
    -o-box-shadow: 0 0 2px black inset;
    box-shadow: 0 0 2px black inset; /* unprefixed last */
    /* 上の@supports規則より上位にこのルールを上書き */
    border: none;
    padding: 2px;
  }
}

andとorの混同を避けるため、構文では両方とも明示的に指定する必要があります（例えば、カンマや空白でどちらかを表現することはできません）。同様に、優先順位規則による混乱を避けるため、構文上and、or、not演算子をかっこなしで混在させることはできません。

@supports (transition-property: color) or
          (animation-name: foo) and
          (transform: rotate(10deg)) {
  /* ... */
}

@supports ((transition-property: color) or
           (animation-name: foo)) and
          (transform: rotate(10deg)) {
  /* ... */
}

@supports (transition-property: color) or
          ((animation-name: foo) and
           (transform: rotate(10deg))) {
  /* ... */
}

テストされる宣言が式中で唯一の場合は、必ず括弧内に記述しなければなりません。

@supports display: flex {
  /* ... */
}

@supports (display: flex) {
  /* ... */
}

構文上、必要でない場合でも余分な括弧は許可されています。この柔軟性は、（例えば式の一部をコメントアウトする場合など）著者やオーサリングツールにとって有用な場合があります。

@supports ((display: flex)) {
  /* ... */
}

テストされる宣言に末尾の!importantがあっても許可されますが、宣言の有効性には影響しません。

@supports (display: flex !important) {
  /* ... */
}

6.1. サポートの定義

将来の互換性のために、4.1.8節（宣言とプロパティ）は、[CSS21] において無効なプロパティや値の扱いに関するルールを定めています。 仕様を実装していない、または一部しか実装していないCSSプロセッサは、 実装していない、あるいは十分なレベルでサポートしていない値の一部を、 この無効なプロパティ・値の扱いルールに従って無効として扱い、 そのため必ず宣言全体をパースエラーとして破棄しなければなりません。

CSSプロセッサは、宣言（プロパティと値）をサポートしていると見なされるのは、 スタイル規則内でその宣言を（パースエラーとして破棄せずに）受理する場合です。 プロセッサがプロパティと値の両方を十分なレベルで実装していない場合は、 その宣言を受理したり、サポートしていると主張したりしてはなりません。

注: ユーザー設定によって事実上サポートが無効化されているプロパティや値も、この定義では依然としてサポートされていると見なされます。 例えば、ユーザーが色を上書きするハイコントラストモードを有効にしている場合でも、 colorプロパティは その宣言が効果を持たない場合でもサポートされていると見なされます。 一方で、実験的なCSS機能のサポートを有効・無効にするための開発者向け設定は、 このサポートの定義に影響します。

これらのルール（およびそれらの同等性）によって、 著者はフォールバック（[CSS1]での後続宣言による上書きや、本仕様の@supports規則の新しい機能によるもの）を、 実装されている機能に対して正しく使うことができます。これは特に複合値に適用されます。実装は、宣言をサポート済みと見なすためには値のすべての部分を実装していなければならず、それはスタイル規則内でも、@supports規則の宣言条件内でも同様です。

7. API

7.1. CSSRuleインターフェースの拡張

CSSRuleインターフェースは以下のように拡張されます：

partial interface CSSRule {
    const unsigned short SUPPORTS_RULE = 12;
};

7.2. CSSConditionRuleインターフェース

CSSConditionRule インターフェースは、条件と文ブロックからなるすべての「条件付き」at規則を表現します。

[Exposed=Window]
interface CSSConditionRule : CSSGroupingRule {
    readonly attribute CSSOMString conditionText;
};

conditionText 型 CSSOMString

conditionText属性は、その規則の条件を表します。 この条件が何をするかはCSSConditionRuleの派生インターフェースごとに異なるため、 派生インターフェースがこの属性の動作を個別に定義する場合があります （例：下記のCSSMediaRule参照）。 そのような規則固有の動作がない場合、以下のルールが適用されます：

conditionText属性のgetterは、関連付けられた条件をシリアライズした結果を返さなければなりません。

テスト

.conditionTextは条件のシリアライズ結果を返します。

---

7.3. CSSMediaRuleインターフェース

CSSMediaRule インターフェースは@media at規則を表します：

[Exposed=Window]
interface CSSMediaRule : CSSConditionRule {
    [SameObject, PutForwards=mediaText] readonly attribute MediaList media;
    readonly attribute boolean matches;
};

media 型 MediaList 、readonly

media属性は、@media at規則で指定されたメディアクエリリストのMediaList オブジェクトを返さなければなりません。

テスト

.mediaは@media条件に一致するMediaListを返します。

---

matches 型 boolean 、readonly

matches属性は、ルールがドキュメントにアタッチされたスタイルシート内にあり、 そのドキュメントのWindow がこのルールのmedia メディアクエリに一致する場合はtrueを、そうでなければfalseを返します。

テスト

.matchesはメディアクエリに一致し、booleanを返します。

---

conditionText 型 CSSOMString （CSSMediaRule固有のCSSConditionRule属性定義）

conditionText属性（CSSConditionRule親規則で定義）は、 getterでこのルールのmedia.mediaTextの値を返さなければなりません。

テスト

CSSMediaRule.conditionTextの値はmedia.mediaTextの値と一致します。

---

7.4. CSSSupportsRuleインターフェース

CSSSupportsRule インターフェースは@supports規則を表します。

[Exposed=Window]
interface CSSSupportsRule : CSSConditionRule {
  readonly attribute boolean matches;
};

matches 型 boolean 、readonly

matches属性は、 conditionText内に表される CSS機能クエリの評価結果を返します。

テスト

CSSSupportsRule.matchesは機能クエリに一致すればtrueを返します

---

conditionText 型 CSSOMString （CSSSupportsRule固有のCSSConditionRule属性定義）

conditionText属性（CSSConditionRule親規則で定義）は、 getterで指定された条件そのもの（論理的単純化なし）を返さなければなりません。 すなわち、返される条件は、この仕様に準拠した実装（この仕様の<general-enclosed>拡張性機構を含む将来の拡張を実装した場合も含む） で指定条件と同じ結果になるようにしなければなりません。 つまり、トークンストリームの単純化（空白を1つにまとめる・省略可能な箇所では省略する等）は許されますが、 論理的な単純化（不要な括弧の削除や結果による簡略化等）は許されません。

テスト

CSSSupportsRule.conditionTextはトークン単純化を許容します。

---

CSSSupportsRule.conditionTextはそれ以外の単純化は不可です。

---

7.5. CSS名前空間とsupports()関数

CSS 名前空間は、他に適切な場所がない有用なCSS関連関数を保持します。

partial namespace CSS {
  boolean supports(CSSOMString property, CSSOMString value);
  boolean supports(CSSOMString conditionText);
};

supports(CSSOMString property, CSSOMString value) 、booleanを返す

supports(property, value) メソッドがpropertyとvalueの2つの引数で呼び出された時：

1. propertyが、UAがサポートする定義済みCSSプロパティとASCII大文字小文字を区別せずに一致するか、 カスタムプロパティ名文字列であり、かつ valueがそのプロパティの文法に従ってパースできた場合、 trueを返す。

2. それ以外の場合はfalseを返す。

注: プロパティ名に対してCSSエスケープや空白処理は行われないため、 CSS.supports(" width", "5px") はfalseを返す（先頭に空白があるためプロパティ名として一致しない）。

注: !important フラグはプロパティ文法の一部ではなく、valueが無効としてパースされる原因となる。これはelement.style.setProperty()のvalue引数でも同様である。

テスト

CSS.supports(arg1, arg2)はプロパティarg1と値arg2のサポート判定を行います。

---

supports(CSSOMString conditionText) 、booleanを返す

supports(conditionText) メソッドがconditionText引数で呼び出された時：

1. conditionTextをパースし、 <supports-condition>として評価した結果がtrueなら、 trueを返す。

2. それ以外の場合、 conditionTextを括弧でくくってからパースし、 <supports-condition>として評価がtrueなら trueを返す。

3. それ以外の場合はfalseを返す。

conditionText引数内のすべての名前空間は document.querySelector("a|b")と同様に無効と見なされます。

テスト

CSS.supports(arg1)はサポート条件arg1を評価します。

---

CSS.supports(arg1)は括弧を補完します。

• supports-conditionText.html (ライブテスト) (ソース)

---

セキュリティに関する考慮事項

この仕様は新たなセキュリティ上の考慮事項を導入しません。

プライバシーに関する考慮事項

本仕様のさまざまな機能は、主に@media規則、および一部は@supports規則に関連して、ユーザーのハードウェアやソフトウェア、その構成や状態に関する情報をWebコンテンツに提供します。 これらの情報の多くは、この仕様の機能よりも[MEDIAQUERIES-4]の機能を通じて提供されます。 しかし、@supports規則によって、ユーザーのソフトウェアや、特定の機能を有効または無効にする非標準設定で実行されているかどうかに関する追加情報が提供される場合もあります。

これらの情報の大部分は他のAPIからも取得可能ですが、本仕様の機能はこの情報がWeb上で露出する方法のひとつです。

この情報は、集計されることでユーザーのフィンガープリント精度の向上にも利用される可能性があります。

8. 変更点

この仕様は、2022年1月13日候補勧告スナップショット以降、以下の（編集上でない）変更が加えられました：

• supports()が無効なカスタムプロパティ値に対して必ずfalseを返すことを明確化
• Web IDL修正、"bool"は"boolean"であるべきだった
• プロセッサはプロパティと値の両方をサポートしなければならないことを明確化（Issue 8795）
• @mediaおよび@supportsに.matchesを追加（Issue 4240）
• 新しいパースアルゴリズム名とブロック生成名に更新
• readonlyなCSSMediaRule.conditionTextを設定する手順を削除（PR 8796）
• conditionTextをreadonlyに

この仕様は、2020年12月8日候補勧告スナップショット以降、以下の（編集上でない）変更が加えられました：

• プロパティ宣言の破棄がスタイル規則のみに適用されることを明確化、at規則には適用されない
• !importantがプロパティ文法の一部ではないことを明確化
• セキュリティとプライバシーを別々のセクションに分割
• CSS feature queriesおよびsupports queriesという用語を定義し、 @supports規則の条件付き構文を指すことで相互参照性を向上
• CSS feature queriesのブール論理で“unknown”値を削除し、 未認識の構文は“false”と定義（Issue 6175）
• 条件付きグループ規則の配置を明確化（conditional group rules） （Issue 5697）

  条件付きグループ規則は スタイル規則が許可されている場所であればどこでも ( スタイルシートのトップレベル、 およびその内部 さらに 他の条件付きグループ規則の内部 ) で許可されます。 CSSプロセッサはこれらの規則を上記の通り処理しなければなりません。

  スタイル規則の後で許可されていない at- 規則（例：@charset、@import、@namespace）は、条件付きグループ規則の後でも許可されず 。 したがって、スタイルシートはそのような規則を条件付きグループ規則の後に配置してはならず、 CSSプロセッサはそのような規則を無視しなければならない。 ので、そのように配置された場合は無効です。

この仕様は、2013年4月4日候補勧告以降、以下の（編集上でない）変更が加えられました：

• conditionText内の名前空間が無効であることを明確化
• 新しい編集者を追加
• “matches the grammar”の代わりに明示的にparseを呼ぶようにした
• すでにCSSOMで定義されているCSSGroupingRuleの重複を削除
• supports()の説明をアルゴリズム形式に書き換え、 supports(prop, val)形式で登録済みカスタムプロパティの構文を考慮することを明確化
• @supports selectorの定義をcss-conditional-4に移動
• @supportsはもはやリスクありではない
• CSS 2.1文法ではなくCSS Syntax文法を使用するよう書き換え
• CSS InterfaceからWebIDL互換CSS名前空間へ変更
• and、or、notキーワードの前後の空白に関する要件を削除。 Media Queries（および一部ミニマイザーのトークン化の挙動）との互換性維持のため。 ただし、これらのキーワードの後には空白またはコメントが必要（そうでない場合関数開始トークンとして解釈される）。
• supports()メソッドで単純な宣言の場合は暗黙で括弧を補うことを許容、 @import規則のsupports()関数との一貫性のため
• IDLコードのセミコロン漏れを修正
• 他モジュールの変更にあわせてリンク、用語、例コードを更新
• スペル・文法修正
• プライバシー・セキュリティ考慮事項のセクションを追加

謝辞

Tab Atkins、 Arthur Barstow、 Ben Callahan、Tantek Çelik、 Alex Danilo、 Elika Etemad、 Pascal Germroth、Björn Höhrmann、 Paul Irish、 Brad Kemper、Anne van Kesteren、 Vitor Menezes、 Alex Mogilevsky、 Chris Moschini、 James Nurthen、 Simon Pieters、Florian Rivoal、Simon Sapin、 Nicholas Shanks、 Ben Ward、 Zack Weinberg、 Estelle Weyl、 Boris Zbarsky、 そしてwww-styleコミュニティの皆さまのアイデアとフィードバックに感謝します。