第32回 W3C CSS Module 仕様書もくもく会@東京

2018年8月2日著

7月31日に第32回 W3C CSS Module 仕様書もくもく会@東京に参加した覚え書き。会場は前回と同じ株式会社to-R（お邪魔させていただきありがとうございます）。今回のお題はCSS Values and Units Module Level 3 日本語訳、個人的にはすごく難解に感じました。おかげで分からない記述が多数......なので、本当はちゃんと調べたり少しでも咀嚼してから覚え書きしたかったけど、それを待ってしまうと来週に持ち越しそうなので、取り急ぎ感想とか気付き事項：

非終端はプロパティと同じ名前を共有しない: 非終端（non-terminals）という表現がまず難解。非端末名（non-terminal name）についても同様。
並置コンポーネント: Juxtaposing componentsの訳なんですが、これは固有名詞的なものなのか、そうでないのか、ちょっと分かりませんでした。
ユーザーエージェントは、少なくとも20回の繰り返しのコンポーネントをサポートしなければならない: 20回、という数字は何に由来するのか？
リテラルに出現: 何となくもっと分かりやすく訳せそうな気がしますが、意訳になってしまいそうな予感。
プロパティ値で位置的に多義のキーワードを構文解析する場合、<custom-ident>生成規則は、実現されない生成規則がその生成規則を要求することができない場合にのみ、キーワードを要求することができる。: ......やばい全然わからない。
美的またはその他の理由で、複数行にわたって文字列を分割することは可能: 美的、というのがなんか面白いなと思いました（原文はfor aesthetic or other reasons）。
資源位置表示
url()の値が（url("")またはurl()のような）空文字列である場合、urlは（url about:invalidが解決するものと同類な）無効なリソースに解決しなければならない。: あまり解決した風に聞こえない面白さがあります。
ホスト文書を再要求する過剰なトラフィックを回避: url()値を空にすることが、なぜホスト文書を再要求することに繋がるか、が分かりませんでした。
ウェブプラットフォーム上でのリンクは空のURLを許可し、よってCSSはハイパーリンクを制御するためのいくつかの機能を獲得する場合、この制限はこれらのコンテキストで緩和することができる。: ......やばい全然わからない。パート2
ユーザーエージェントは、合理的で有用な範囲と精度をサポートすべき: そういえば、例えば小数点以下何桁まで数値を指定するのが制作者とUA双方にとって有意義か、あまり真面目に考えていなかったような。
整数の最初の桁は、符号を示す-または+を先行させてもよい: プラスって付けても良かったんですね（付けたことはない）。
0長さ: 個人的には「長さ0」とした方がわかりやすい気がします。
負の長さの値をサポートできない場合、値をサポート可能な最も近い値に変換: ......それはつまりゼロなのだろうか的な疑問が湧きました。
exは"x"を含まないフォントに対しても定義される: 面白いですね。まぁ確かに定義できないと困るんでしょうけど。
事前測定: かっこいい（が、よくわからない）。
初期包含ブロックの大きさは、ビューポートのスクロールバーの存在によって影響されないことに注意する: スクロールバーの仕様がプラットフォーム固有であることを踏まえ、その影響を除外するように意図されているのでしょうか？
固定単位: これ定義がない？
印刷媒体と同様の高解像度デバイスの場合、固定単位は標準的な物理単位の1つ（インチ、センチメートルなど）となるべきである。低解像度のデバイスおよび独自の視聴距離を伴うデバイスの場合、固定単位は代わりにピクセル単位が推奨される。そのようなデバイスの場合、画素単位で最適な参照画素を近似するデバイスピクセルの整数を参照することを推奨する。: ......やばい全然わからない。パート3
この変更は、あまりにも多くの既存のコンテンツが96dpiの仮定に依存するために行われた。この前提を壊すことはコンテンツを壊すことになる。: これすごく重要な気がします。
グラディアン。ゴンまたはグラードとしても知られる。円の1周は400グラディアン: そんな単位は初耳でした。
ユーザーエージェントは、少なくとも20項のcalc()式をサポートしなければならない。: 再び登場した20というUAへの要求数値。Slackの方で質問した結果、[css3-values] required ranges for values from Kang-Hao (Kenny) Lu on 2012-04-17 (www-style@w3.org from April 2012)に関連する記述が見受けられ、どうもcalc()をいち早く実装していたIEの動作仕様が影響した結果らしい、ということが判明。
解析時間範囲チェック: Parse-time range-checkingの訳ですが、範囲チェック、と解析時間、の係り受けをどう解釈すれば良いのか分からず。
閉じた（開いていない）の間隔として許容値を定義するためにcalc()を受け入れるすべてのコンテキストを要求する。: ......やばい全然わからない。パート4
意図的である式は、それが可能なCSSを使って見栄え用の言語の書式を記述できるようにするためでなく、CSSにセマンティックデータを考慮できるようにするため: ......やばい全然わからない。パート5
首尾よく<color>として解釈される: 首尾よく、って訳良いなぁと思い原文は何なんだろうと確認したらsuccessfullyでした。なるほど。
現在、attr()式は、別の属性にフォールバックすることはできない。CSSの将来のバージョンでは、attr()拡張する方向になるだろう。: あまり拡張されすぎると、アクセシビリティを欠いた実装を助長してしまいそうな気がしなくもないです。
URL必要な場合に使用することができるが: URLの直後に「が」が抜けてる印象→momdoポイントゲットだぜ
無効（そして必要に応じて無視）: 無効と無視ってどう違うのか？と思い原文を確認したところinvalid (and ignore as appropriate)とあって、つまり状態とそれに対するアクションという理解をしました。
接頭辞変異形: 原文はprefixed variant。これはどう解釈すれば良いのか......接頭辞つきのもの全般を指していると解釈して良いのかどうか。