[10] CSS では構文解析の方法が仕様により定められており、どのようなバイト列、文字列であってもそれが CSS スタイルシートとしてどう解釈されるべきかが明確になっています。
[41] CSSにおける文字コード参照。
[5] css-syntax ではいくつかの入口点 (構文解析器の動作開始点) を定義しています。
[35] css-syntax には parse something according to a CSS grammar という手順が定義されており >>34、他の仕様書から CSS 系の文字列の構文解析を行う際に呼び出されます >>36。入力は文字列、字句の列、 component value の列のいずれかです。出力は構文に依存する構文解析結果か、 失敗かのいずれかです。この手順が呼び出されると、 >>21 により構文解析し、 その結果得られた component value を指定された文法により処理します。
[7] CSSOM へは sheet
属性からアクセスできますが、 HTML DOM とは異なり読み込み途中の状態にはアクセスできないようです。
[8] スタイルシートには style sheet ready フラグ <http://www.whatwg.org/specs/web-apps/current-work/#styling> があり、適用の準備ができるまではこのフラグが未設定になっています。具体的にどの時点で準備ができたといえるのか明確にはなっていませんが、 普通に考えれば構文解析が完了してブラウザー内部のデータ構造となり、カスケーディングの対象となったり、 CSSOM のオブジェクトとして利用可能になったりした時点でしょう。
[9] 通常のスタイルシートの場合、 style sheet ready フラグが設定されるまではスクリプトの実行がブロックされます。
代替スタイルシートではブロックされません。 (WinIE10 では代替スタイルシートでもブロックされます。)
なのでスクリプトから CSSOM にアクセスしようとしても、完全な CSSOM が返されるか、
null
が返されるかのどちらかのようです。
[12] CSS1 と CSS2、さらに 2000年代までの CSS3 (css3-syntax) では Flex と Yacc により形式的に構文が記述されていましたが、参考であり、また様々な制約から不正確でした。 規定としては英語で構文および前方互換構文解析規則が説明されており、また各特性の値は専用の文法記述方法が用いられていました。
[14] このように構文と構文解析に関する規定が詳細に説明されているだけでも当時としては十分先進的ではありましたが、
Flex によって記述された字句化とよりマクロな構文の対応関係が不明瞭で <an+b>
のような災厄をもたらしたり、前方互換構文解析規則の細部が不明確であったりというような問題を抱えていました。
[2] 2012年の春になって、ようやく css3-syntax で HTML5 仕様風の字句化器と木構築器からなる状態機械として構文解析の挙動が明確に記述されるようになりました。
[3] tabatkins/css-parser ( ( 版)) <https://github.com/tabatkins/css-parser>
[39] Minutes Sydney F2F 2015-02-08 Part I: CSS Parser (Dael Jackson 著, 版) <https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0008.html>
[42] 1422951 - Add a CSS-parsing WebExtensions API () <https://bugzilla.mozilla.org/show_bug.cgi?id=1422951>
[43] Clarify the definition of addColorStop() (Ms2ger著, ) <https://github.com/whatwg/html/commit/cc508ebd8427dd561ed2dc3d5d9a45a967fccf71>
[44] Clarify the definition of addColorStop by Ms2ger · Pull Request #3308 · whatwg/html () <https://github.com/whatwg/html/pull/3308>