https://gyazo.com/895d8758cfafe6e012263fde6b844317
Drafting the Future CSS
少数化・単純化・秩序化
consensus
agreed
秩序
purpose
Directionの概念について揉めてる
flexはShapeとFlowが一致
ゆえにDirectionを決定
gridはShapeがどちらも取れるのでFlowがDirectionを決定できる
masonryはShapeとflowが一致しない
どちらに基づくかでDirectionの解釈が変わる
Shape
Waterfall
Flow
Brick
https://gyazo.com/3d558c57deeb1d35c0e68f187e0983d6
Chairに断っている理由について
適切な役割があるから断っている
どうやってSpecエディタになったのか
中学〜高校からコントリビュートしている経験
スペックをちゃんと読む
実際の実装と乖離している部分があれば突っ込む
改善案を提案したり、Specを編集してみたり
幅広い人からのレビューが受けられるようになる
リアルワールドのユースケースや実装経験からのフィードバックが欲しい
https://gyazo.com/7a562642867b800f41e0b096215e9fc8
Japanese Layout Task Force
経済合理性の中で何を実装するか決めていく
印象的な話
拡張はどこで管理しているか
実装のない機能は載ってない
https://gyazo.com/bffde86b261756490e169a10a4db3515
i18n WGとCSS WGの連携がうまくいっていない
要件の文書とテストはあるがうまく噛み合ってない
CSS WG「いつ活用したらいいの？」
国際化はアドオンじゃないのは双方同意
i18n要件から設計判断に影響を与える経路がない
子に継承されたときに親子で書字方向が異なっている場合どうなる？ 2020年に論理のまま継承するで結論はでた
結果的にこの結論を物理に変えるようにひっくり返した
この内容は縦書き界隈で大事件になっているかも
物理方向がメインで論理方向は表現レイヤーで吸収されることが事実上きまった
黙っていると困った仕様が入るかもしれない危険性
@int32_t: 提案者が「witingModeは足さずにtextOrientationだけ足して、描画の向きはtransform()で回せばシンプルでは?」という気持ちになっているようです。縦書きにtransform()必須、が嫌な方はコメントした方がいいかも。 i18n WGの話
野心的な仕様の提案
DOM Localization
文書リソースを簡単かつ柔軟に読み込む提案
HTML側でkeyを指定することでローカライズできる
必要な仕様
ICU MessageFormat 2.0
Intl.MessageFormat
Messsage Resourcs
まだまだ決めないといけない仕様はある
影響範囲が大きい
決まってないところもある
これってテンプレートエンジンを作る話にならない？
まずWG作るところだよなって話
Amount Element
ECMA-402の仕様策定のなかにi18n WGのレビューが入る
標準化団体が違っていてもつながっている実感
WGは仕様提案するだけじゃない
仕様以外にも管理しているドキュメントがいろいろある
検索における国際化対応
Agents in Payment
問題
本人性と非改ざん性証拠力の確保
Intent Mandate
ユーザーのハイレベルな決済
Cart Mandate
商品や価格・条件の正確な記録
Payment Mandate
何を任せたのかという内容面の保証は困難
最終的には司法判断になる
解釈基準を具体化できるのか？