サイボウズでプロダクトエンジニアをしている daiki です。
前編では、TPACに参加した一部のメンバーによる振り返り動画をお届けしました。
後編では、参加メンバーそれぞれの視点から、TPACとはどんな場だったのか、何を見て何を感じたのかを綴ってもらいました。
Web標準は「どこかから降ってくるもの」ではなく「みんなで作るもの」
-- gorohash
お恥ずかしながら、今回参加した他のメンバーと違って常日頃からWeb標準関連の動きを事細かにキャッチアップできているわけではないため、初めてのTPAC参加は全てが新鮮な体験でした。
世の中にはW3Cを含め標準化団体というものがいくつか存在し、それらがWebの標準仕様を策定しているということは当然知っていました。でもそれは画面の向こうの世界の話であって、率直に言うと自分にとっては手の届かないどこかで決まったものをキャッチアップして、ただ受け入れて、わからなければMDNで調べる、というだけのものでした。
今回TPACに参加して、まず当然ながら確かに人と人とが話し合ってWeb標準というものを作り上げているということを実感しました。TPAC全体では500名以上が参加しているものの、5日間×十数並列でミーティングが開催されているため、多くの議論は高々20〜30人によって進められます。今では数十億人が利用するWebのルールが、その一部とはいえ、ちょっとした会議室に収まる程度の人数で決められていることに驚きました。自分の手の届かないどこかで決まるもの、ではなく、ここにいる人たちと議論を交わせば自分の意見も反映できるのだということを実感しました。ただしそれは決して簡単なことではなく、既存仕様や実際のユースケース、それらを取り巻く環境に対する深い理解、そして相手の意見を聞き自分の意見を伝えるだけの英語力が必要であることも痛感しました。
今回は日本での開催ということもあって多くの日本人参加者がいましたが、Webという巨大なエコシステムに関わる人数からすれば極々わずかです。そのエコシステムの中で生きる一人としてWeb標準にどのような貢献ができるのか、考え始めるきっかけになりました。
WCAGの国際化対応
-- mehm8128
WCAG 2.2 and non-Latin languagesというbreakoutsで日本人の方が「WCAG 2.2って欧米中心で、CJK言語が適切に扱われていないよね」といくつかの提案をしたのを皮切りに、他のいくつかのミーティングでもCJK対応やルビの話題があったのが、最も印象的でした。議論の結果、達成基準の追加までは実現しなかったものの、failure techniqueが追加される流れになったり、さらなる調査が次のステップとして設定されたりしました。 詳細は僕のブログ記事をご覧ください。
今年6月の欧州アクセシビリティ法の施行のように国レベルでWCAGをアクセシビリティの基準にしていたり、日本だと法律まではいかなくともWCAGがJIS規格になって各企業でJIS規格に沿った試験が行われ、それが企業ホームページにアクセシビリティ方針として掲載されていたりと、WCAGがアクセシビリティの基準になることが多いです。しかし、その基準が本当に妥当なものなのかというのを気にしている人は多くないし、気にしている人でも実際にW3C側に改善の提案する人はほとんどいないと思います。
そこで日頃からWCAGの動向を注視し、今回のように日本語が十分に考慮されていないものを見つけたら自分たちで改善の提案をしていったり、日本語に関する問題に限らず様々なフィードバックをしていきたいし、そういうことができるということをWebアクセシビリティに関わる全ての人に知ってもらいたいです。
ブラウザからのデータ外部送信を防ぐ仕組み
-- JJ
Web Application Security Working GroupのMeetingに参加した際、特に印象に残ったのがConnection Allowlistsという提案です。従来のContent Security Policy (CSP) が外部からの悪意あるスクリプトの注入を防ぐ一方で、内部からのデータ外部送信を十分に防げていないという課題を背景にしています。Connection Allowlistsは、リクエストを送信できるエンドポイントをシンプルなURLパターンのリストで制御することで、XSSなどのスクリプト実行によるブラウザからのデータ漏洩を防ぐことを目指しています。
CSPは多機能であり、設定が複雑になる都合上、設定ミス等による回避テクニックも多く存在しています。攻撃者はデータの窃取を目的とするケースが多いため、データの外部送信自体を防ぐ機構としてのConnection Allowlistsの提案には共感できるものがありました。実際には実現可能性の話や既存の仕組みとの兼ね合いの話など様々な考慮事項がありますが、このような仕組みが提案されていることを嬉しく思いました。
私は普段からWeb標準の動向を細かく追えているわけではないため、こうした新しい提案がどのように生まれ、どのようなプロセスで議論されていくのかを具体的に知れていませんでした。そのため、理想的な仕組みを提案としてまとめ、TPACのMeetingで議題として取り上げられるという流れを実際に目にすることができ、とても良い経験になりました。
DOM Localization と地道な国際化
-- Saji
今回の TPAC で印象に残っている議論の一つが DOM Localization です。これは ICU MessageFormat の策定や Intl.MessageFormat の Champion を行なっている Eemeli さんによる提案で、「CSS のように文言リソースファイルを読み込み、DOM で読み込んだリソースを表示できるようにする」という壮大なものです。現段階では CSS 同様 link 要素で文言リソースファイルを指定し、各 HTML の属性値から文言を指定することで要素内に文言が転換されるような構想となっており、一つ一つの文言は ICU MessageFormat を利用します。ICU MessageFormat 自体、単なるプレイスホルダー機能だけでなく関数の呼び出しや変数宣言、match 構文、マークアップ記法など強力な機能を持っており、それらが HTML/JS/CSS の機能と統合して実現されれば国際化における表現力は大きく向上することが見込まれます。一方でその分考慮する点や協調しなければ関連仕様が多く、文言リソースファイルの形式や要素への指定方法、マークアップ記法の扱いなど決まっていない部分も多い提案ではあります。
TPAC 開催中も Breakiout Session 内や最終日の i18n / WHATWG / A11y のジョイントミーティングでそれぞれの専門家が懸念や考慮事項を出していたのがとても印象的でした。全体として考慮すべき点は多く上がったものの、反対意見は見られず継続して議論し WG などの新設を目指すといったことも言われていたので今後の動向も楽しみです。
またこれは個人的な話にはなりますが、 ICU MessageFormat や Intl.MessageFormat に関しては以前から注目して追ったりブログに書いたりしていたので、提案者である Eemeli さんに今まで感じていた疑問点や国際化を進める上での難しさを直接聞けたことは変え難い経験となりました。
このように壮大な計画が議題に上がる一方で、i18n WG のセッションでは細かい仕様やドキュメントの修正についての議論が活発に行われていました。参加メンバーの世界各国の言語に関する知識や関連する仕様の知識の深さから多くの考慮事項が上がり、それらを踏まえて細かく仕様やドキュメントを改善していく様子は想像していたよりもずっと地道で、メンバーの国際化にかける思いで成り立っているものでした。
議題の中には「ルビの読み上げの問題」や「(今や世界の標準語になっている)文字化けという言葉の定義」など、日本語話者にとって馴染み深く当事者である議論もあり、国際化は決して人ごとではないという意識と今後は国際化に興味を持つものとして貢献をしていきたいと強く思わされました。
予算策定者としてTPACへの参加の意義を見出せた
-- sakito
私がTPACに参加した目的の1つは、予算策定者として「メンバーのTPAC参加に意味があるのか」を判断する材料を得ることでした。サイボウズは2025年にW3Cへ加入し、全メンバーが初めてTPACに参加します。今年は日本開催のため今後は海外開催と比べて参加コストは比較的少ないですが、今後海外での参加を見越したコストとリターンの想定も必要になります。
この予算を今後も承認し会社に説明するには、現地でメンバーが感じる雰囲気や、現場でしか得られない感覚を自分も体験する必要がありました。
結果として、TPACへの参加は意味があると実感できました。現地に行ってよかったです。参加前は「ブラウザを作っているわけでもなく、仕様に直接関与していない企業がTPACに参加する意味はあるのだろうか」と疑問に思っていました。しかし、実際に参加してみて、仕様を考えている人たちがアプリケーション開発者（仕様を使う人たち）の声を大切にしていることに気づきました。
私もデザインについて考えているとき、HTMLやCSS、DOMにこんな機能があればいいのにと思うことがあります。デザインシステムを作っているときも、Reactなどのフレームワークに縛られず、標準的な仕組みであるWeb Componentsを使うべきだと思いつつ、まだ使いづらいなと受け身な姿勢でした。今回のTPACの議論を通じて、アプリケーション開発者として声を届ける大切さ、仕様への身近さを感じることができました。
たとえば、デザインシステムを作っている企業、Web Componentsを検討・実践している企業は日本にもたくさんあります。そうした企業が仕様にフィードバックすることで、Web全体をよくしていくことができます。その声を届けることはアプリケーション開発企業としても重要であり、企業として参加する価値があると思います。
メンバーからは、参加することでWebに関するスキルや新しい視点を得られたという声も聞くことができました。また、現地でのランチやディナー、休憩時間にTPAC参加者とさまざまな議論をする場面も多くありました。そこで話した内容に影響を受けたメンバーもいます。
参加してみて、開催前の懐疑的な状態から、日本で開催されるのであれば1度は参加したほうがいいという感想に変わりました。海外開催となると人数は厳しくなりますが、TPACに参加することをモチベーションに、日々のキャッチアップや仕様に対する向き合い方も変わってきそうです。
今回、初参加にも関わらずTPACを100%楽しむことができました。それはサイボウズ社員をW3CやTPACに繋ぐ協力をしてくれたJxckさんのおかげでもあります。mozaic.fmというPodcastを通じてプライベートでお付き合いがあり、Webにまつわることに詳しく、過去にもTPACに参加したことがある経験を業務委託としてお手伝いしていただきました。W3Cの加入や次回TPACの参加についてサイボウズ以外からも協力してくれるとのことなので、ぜひお声掛けください（sakito宛でも大丈夫です）。
使っている Web API の裏側を知れた
-- daiki
Web Applications Working Group のミーティングを聴講し、Service Worker や Push API など、サイボウズ製品でも使っている Web API がどんな議論のもとで標準化されているのか直接学びました。
印象的だったのは、App Shell パターンの高速化をめぐる議論です。App Shell は Service Worker が最小限の UI を返し、コンテンツを後で JavaScript で読み込む手法ですが、仕組み上 Service Worker の起動がナビゲーションのオーバーヘッドになります。そこで提案されていたのが、Static Routing API に「Synthetic Response」を追加し、Service Worker の起動をバイパスしてナビゲーションコミットを早めようというアプローチでした。提案者の宍戸さんにも少し話を伺ったところ、「ミリ秒単位で早くなれば万々歳」と語っていたのが印象的で、逆に unload イベントのようにナビゲーションが遅くなる仕組みは廃止したいという話をしていました。高速化を極限まで追求しているのに、実装次第でその努力が簡単に消えてしまう現実があるからです。
ほかにも、Service Worker の登録・更新時に CSP をどのタイミングで適用するべきか、といった仕様の曖昧な部分を明確化する議論が続き、普段使っている API もまだ発展途上であることを実感しました。
さらに、こうした仕様策定が GitHub の Issue を起点に完全にオープンな場で進められていることも印象的でした。会議自体もクローズドな雰囲気ではなく、全員がマイクを持って自己紹介する場面もあり、聴講者でも議論に加われる空気がありました。Issue から Spec や議事録を辿ると、API の歴史や課題、今後の方向性を読み取れるという発見もありました。
今後は新しい Web API を採用する際、MDN に書かれた結果だけを追うのではなく、その仕様がどんな議論を経て形作られたのか、ブラウザ実装がどの段階にあるのか、どこへ向かおうとしているのかを踏まえて判断できるようになりたいと思います。今回の TPAC 参加は、その入口に立てた貴重な経験でした。
IndexedDBのテストに関する検討事項
-- くらっち
Web Application Working Groupの議論で印象に残ったのはindexedDBの仕様に関する議論です。GB単位のデータをindexedDBで保存しているアプリケーションで、何らかの理由で1つの値が失われた場合、DB全体が不良なのか単一の値が不良なのかを判別できるのかなど、様々な観点からケースを洗い出して議論を行っていました。
各ブラウザでは、DBの破損や復旧、大規模なDBのテストなどはブラウザによって異なるものと推測されています。現在、分かっているものだとGB単位のテストファイルを作成するのではなく、10MBのテストファイルを生成して、制限を10MBに設定するなどです。ブラウザ間で共通のテスト手法を確立することで、より良い品質保証が可能になると期待しています。
TPACに参加するまでは、Webアプリケーションを開発する上で「この仕様だと技術的に実現出来ない」は仕方ないことだと考えていましたが、それは違いました。理由としては、Web標準に対して議論ができる場所があるからです。エンジニアとしてプロダクトをより良くする、長期的に使えるものにするためにWeb標準を考える良い機会になりました。
Web Authentication WGでWebを感じた
-- elmetal
認証クライアントの実装は何回かやったことはあるものの、実装に必要な部分を読んだだけで特に認証の標準を読み込んでいたわけではありませんでした。
認証の領域について知識不足を予想しながら参加しましたが、単に技術的な仕様の知識不足以上に知らないことがたくさんあったと感じました。
多くの議論は具体的なユースケースを起点として、何をすると後方互換性を失わずに新しいユースケースに対応できるかが話されていて、こうした活動の積み重ねで今のWebができあがってきたと肉体的な感覚を伴って理解できました。Webの歴史を紡いだ文章を読んだ経験はありましたが、まさにそこに書かれていたことが行われていると実感しました。
具体的に今対応できていないユースケースに従って、現状の仕様と照らし合わせて不足や不整合がないか確認しながら仕様を策定する場を実際に経験できたことはとても良い経験でした。
仕様策定の議論に求められるのは、私たちの「声」
-- saku
今回の TPAC では、議論の「裏側を知る」ことを個人テーマに掲げて参加しました。
議論は基本的に minutes が取られ、誰でもオンラインで閲覧できます。しかし、minutes は書記が手動で取った議論の要点メモに過ぎません。
minutes に書かれないリアルな場の雰囲気、議論の主導者が普段考えていることや大切にしていること。標準化の「裏」を知り、話者の「中身」を知ることこそが、オフライン参加最大の価値だと思っていました。今回、直に話してその洞察を得ることができたため、その辺りを中心にレポートします。
白熱した議論が示した「使いやすさ」への執念
CSS Masonry Layout では、item-flow プロパティが導入され、それによって Masonry レイアウトを制御できることになっています。しかし、その item-flow の column & row の値が、Masonry 全体の「形」を表すのか、はたまた item の「流れ」を表すかについては解釈が分かれるところです。
この issue については前々から Working Group 内で議論が続いており、WebKit Blog からフィードバックも募られていました。そのため、かなり意見が対立するだろうことを個人的に踏んでいたトピックでした。
そして TPAC では、かなり緊張感のある応酬が交わされることになります。
Tab Atkins: 「もし waterfall レイアウトで row を使うなら Formal Objection する」
Tim Nguyen: 「もしそうならこっちだって Formal Objection する！」
Miriam Suzanne: 「対話したいと言ったのに Formal Objection なの？自分たちには議論権限がないの？」
このようなやり取りの結果、最終的には、議長の Alan Stearns から「Formal Objection を投げ合うのは不適切で生産的じゃない」という注意が入るまでになりました。その後、fantasai が即興デモで折衷案を提案しましたが、Tab と意見が対立します。
特筆すべきは、ここでの主題は実装可能性や互換性ではなかったことです。
標準化しても、使ってもらえなければ意味がない。だから、広く認知され、正しく使ってもらえるような仕様決めに、激しい対立も相当なリソースを割くことも厭わない。そんな姿勢を生身で感じた瞬間として、この議論は非常に記憶に残っています。
fantasai が伝えてくれた「私たちに求められているもの」
それをさらに直接的に伝えてくれたのが、fantasai でした。fantasai は約 30 年に渡り CSS のスペックエディタをしている人物です。そんな彼女と、この TPAC で直接話す機会を得ることができました。
CSS には大量の仕様があります。一方、その仕様のエディタをしているのは、fantasai 含め数えられるほどの人数しかいません。それなら、もちろん仕様を書いてくれる人が欲しいのではと思い、「どんな仕様なら手伝えそうか」を聞くつもりでした。
しかし、fantasai からもらった回答は、私の想定とは違うものでした。
TPAC では、エンジン実装側や Web のプリンシパル文脈、互換性に関する議論ももちろん交わされます。しかし、それと同程度、いやそれ以上に「この場合はどうなる？」というユースケースの話がなされていたように思います。そういった実に細かなユースケースに対する合意の積み重ねから、Web の仕様は地道に形作られていく。その感覚は、この TPAC で身をもって実感していました。
そして、そういったフィードバックを専門とするのは、エンジンの実装者や仕様のエディタではありません。プロダクトを作り、デザインシステムを作り、フレームワークを作り、 この議論の成果物を利用している、私たちです。
そんなある種「稀有な立場」からのフィードバックをとてもありがたいと思っており、そういう人がもっと増えることを願っている、と fantasai は伝えてくれました。
- 「この Ana Tudor のコメントのようなものは、とてもありがたい」と伝えてくれた
標準化の舞台に必要なのは、私たちの思う仕様やブラウザエンジンに関する崇高な知識だけではありません。
私たちが思う以上に求められているのは、私たち自身の「声」だということ。そして、私たちの「声」を取り込むために、莫大なリソースが惜しみなく注がれていること。そしてそれが Web を創り上げているということ。それを強く感じた TPAC 初参加でした。
終わりに
W3C の VP, Technical Strategy である Philippe Le Hégaret さんへのインタビュー記事も公開しています。ぜひこちらもご覧ください。
