新卒1年目がTPACに参加したことをきっかけにMDNのWeb APIを全部読んでみた。

Transcript

1. 新卒1年目がTPACに参加したこと をきっかけにMDNのWeb APIを 全部読んでみた。 2026.05.09 kuracchi 1
2. kuracchi • 2025年：サイボウズ入社 • 現在：開発本部 kintone(開発) アプリ設定チーム プロダクトエンジニア 自己紹介 2
3. 3 01 02 03 新卒1年目でTPACに参加 今日紹介する5つのWeb API 終わりに P04 P15 P55 目 次
4. 新卒1年目でTPACに参加 4
5. Web標準化団体であるW3Cが行っている国際的な標準化会議 HTMLやCSS、JavaScript、Web APIなどWebの仕様を議論 TPACについて 5 新卒1年目でTPACに参加
6. Web Applications Working Group クライアントサイドのWebアプリの仕様を策定 Cascading Style Sheets (CSS) Working Group CSSの開発と維持管理を行う たくさんのWorking Groupがあり、それぞれのミッションに向けて活動 Working Group単位で担当領域の議論をする 6 新卒1年目でTPACに参加
7. TPACでは世界中のエンジニアがWeb標準について議論していた 7 新卒1年目でTPACに参加 Internationalization Working Group の議論の様子
8. 私はオンラインだったため、Zoomで議論に参加 主にWeb APIの仕様や課題について検討し、 意見がある場合は任意のタイミングで話すことが可能 参加しているメンバーは積極的に意見を出し合っており、 対象のWeb APIに関しての知識も相当深いものだと感じた 私はWeb Applications Working Groupに参加 8 新卒1年目でTPACに参加
9. UI Eventの仕様書のメンテナンス 20年以上の歴史を持つ仕様だが、編集者不在で維持が困難 Web Share APIの代替テキストのサポート 画像共有時にタイトルはオプションで指定可能だが、altが欠けている IndexedDBのテスト DBの破損と復旧した時や数GBの大規模データベースにおけるテストが不足 どんな議論がされていたのか 9 新卒1年目でTPACに参加
10. 仕事で関わっている分野であるのに分からないことばかりで悔しかった 英語で議論されていたが、日本語だったとしても意見は出来なかった 自分がWebに対して受動的だったということを痛感した TPACに参加して感じたこと 10 新卒1年目でTPACに参加
11. TPACに参加する前 • Web標準は何処かの偉い人が決めている • エンジニアの責務は技術力を磨き、ドメイン知識をつけて、 長期的に良いプロダクトを開発すること TPACに参加して自分に起きた変化 11 新卒1年目でTPACに参加
12. TPACに参加した後 • Web標準は世界中のエンジニアが向き合って考えている • エンジニアの責務として長期的に良いプロダクトを開発するために、 Webの仕様を主体的に考えることも必要 TPACに参加して自分に起きた変化 12 新卒1年目でTPACに参加
13. Webは私たちエンジニアが作っていくもの 13 新卒1年目でTPACに参加 TPACの参加ブログの抜粋
14. Web標準について知識がなかったので、まずは知るところから始めた TPACに参加して興味が湧いたWeb APIを調べてみることに →「MDNのWeb APIを全部読んでみた」の始まり 「TPACに参加して良い経験が出来た」で終わらせない 14 新卒1年目でTPACに参加
15. 本日紹介する5つのWeb API 15
16. • View Transition API • Popover API • Battery Status API • HTML Sanitizer API • Trusted Types API 本日紹介する5つのWeb API 16 本日紹介する5つのWeb API
17. View Transition API 17
18. View Transitionはページを移動する際にユーザーの認知負荷を減らしたり、 読み込み待ちの知覚時間を短縮する DOMの変更と遷移アニメーションをより簡単に実装する方法を提供 18 View Transition API
19. View Transition APIの実装例 19 View Transition API startViewTransition() を記述するのみ
20. View Transition APIの遷移アニメーションの実装例 20 View Transition API 遷移前→遷移後 のアニメーションを設定
21. View Transition APIを利用してスライドショーを実装 21 View Transition API
22. • DOMの変更と遷移アニメーションをより簡単に実装する方法を提供 • View Transitionはユーザーの認知負荷を減らし、読み込み待ちを減らす • 遷移前の状態のスナップショットを保持して、遷移後の状態へアニメーション を用いて遷移 View Transition APIのまとめ 22 View Transition API
23. Popover API 23
24. ポップオーバーコンテンツを表示するための仕組みを提供 24 Popover API WebページのTop layerにコンテンツを表示
25. viewportの幅と高さ全体にわたり、ウェブに表示される他のすべてのレイヤー の最上位に位置する固有のレイヤーのこと Top layerとは 25 Popover API ポップオーバー ページのコンテンツ かぶさる
26. HTML属性を用いて宣言的に制御可能 26 Popover API popoverTarget属性に表示する コンテンツのidを設定 表示するコンテンツに popover属性を設定
27. モーダルと非モーダルという定義があり、Popoverは非モーダル モーダルを使いたい場合は<dialog>を使う方が適切 <dialog>との使い分け 27 Popover API 表示されている間も 他の要素を選択可能 表示されている間は 他の要素を選択不可能
28. ポップオーバーとその制御元がpopoverTarget属性で関連付けられると、 キーボードや支援技術で操作可能になる • ポップオーバーが表示されるとキーボードフォーカスナビゲーションの 順序が更新される • スクリーンリーダーなどの支援技術がポップオーバーと制御元の関係を 理解するために”aria-details”および”area-expanded”が設定される ポップオーバーのアクセシビリティ機能 28 Popover API
29. • WebページのTop layerにコンテンツを表示 • モーダルと非モーダルという概念があり、popoverは非モーダル • ポップオーバーとその制御元がpopoverTarget属性で関連付けられると、 キーボードや支援技術で操作可能になる Popover APIのまとめ 29 Popover API
30. Battery Status API 30
31. バッテリーが消費された時にアプリのリソース使用状況を調整したり、 データを失わないためにバッテリーが切れる前に変更点を保存する処理が可能 充電量に関する情報の取得や充電状態が変化を通知する仕組みを提供 31 Battery Status API
32. 新たなフィンガープリンティングの可能性がある ユーザーエージェントは情報の高精度な測定値を公開してはならない 32 Battery Status API
33. ウェブサイトが特定の情報を収集し組み合わせることで、 特定のブラウザやユーザーを識別する手法 例：フィンガープリントの要素 • ブラウザーのバージョン • タイムゾーンや推奨される言語 • ブラウザーの設定の状態 フィンガープリンティングとは 33 Battery Status API
34. Chrome 103以降、BatteryManagerインターフェースは セキュアコンテキストでのみ利用可能 ユーザーエージェントは情報の高精度な測定値を公開してはならない 34 Battery Status API
35. 認証と機密性の一定の最低基準を満たしている Window や Worker のこと 機能をアクセス制限すべき理由 • ユーザーのプライバシーを侵害する • ユーザーのコンピューターに対して低水準のアクセス権限を得る • ユーザーの認証情報のようなデータへのアクセス権限を得る セキュアコンテキストとは 35 Battery Status API
36. Firefoxでは実装されていたが、 フィンガープリンティングの可能性があると考えられ削除された Battery Status API being Removed from Firefox due to Privacy Concerns ブラウザ側の判断でAPIを削除することもあるため、 ベンダー側の動向も追う必要がある Firefoxでは実装を取り下げる表明がされた 36 Battery Status API
37. • 充電量に関する情報の取得や充電状態が変化を通知する仕組みを提供 • フィンガープリンティングの可能性があるため、ユーザーエージェントは 情報の高精度な測定値を公開してはならない • FireFoxでは実装されていたが、フィンガープリンティングの可能性がある と考えられ削除された Battery Status APIのまとめ 37 Battery Status API
38. HTML Sanitizer API 38
39. XSS対策として、DOMに挿入する際に不要なHTMLを削除するメソッドを提供 HTML文字列を受け取りDOMに挿入する際に不要なHTMLエンティティを除去 39 HTML Sanitizer API setHTML()で HTMLをサニタイズ
40. デフォルトのSanitize設定は以下の項目が削除される 1. XSSに対して安全ではないとされているもの（<script>, <iframe>） 2. クリックジャッキング、なりすまし、その他の攻撃に 悪用される可能性のある項目（<button>） 3. コメントおよびdata-*属性 Sanitizeオブジェクトのデフォルト設定 40 HTML Sanitizer API
41. Sanitizerオブジェクトで許可するHTMLエンティティを指定 41 HTML Sanitizer API 許可するHTML を指定
42. Sanitizerオブジェクトで除去するHTMLエンティティを指定 42 HTML Sanitizer API 除去するHTML を指定
43. BaselineではないがChrome、Edge、Firefoxでは実装されている 43 HTML Sanitizer API
44. Baseline（互換性）とは 44 HTML Sanitizer API Baselineの機能は、現在の安定したブラウザで新たに利用可能になったか、 あるいは長期にわたる継続的なサポートにより広く利用になった機能
45. • 信頼出来ないHTMLを挿入してJavaScriptを実行するXSS対策として、 DOMに挿入する際に不要なHTMLを削除するメソッドを提供 • Sanitizeオブジェクトで許可、除去するHTMLエンティティを指定 • BaselineではないがChrome、Edge、Firefoxでは実装されている HTML Sanitizer APIのまとめ 45 HTML Sanitizer API
46. Trusted Types API 46
47. 変換関数を指定したpolicyを作成してサニタイズ 入力されたデータが指定した関数を通過済みなのかを保証 47 Trusted Types API Policyで指定した 関数でサニタイズ サニタイズの policyを作成
48. policyを作成してサニタイズ可能だが強制ではない 信頼された型が常に渡されるように強制するにはCSPを記述する CSPを利用して信頼された型であることを保証 48 Trusted Types API
49. セキュリティの脅威となるリスクを防止、最小限に抑える機能 CSPの主な用途は、文書を読み込むことを許可するリソース、 特にJavaScriptのリソースを制御すること 主に、XSS攻撃に対する防御として使用される CSP(コンテンツセキュリティポリシー)とは 49 Trusted Types API
50. policyを作成してサニタイズ可能だが強制ではない 信頼された型が常に渡されるように強制するにはCSPを記述する CSPを利用して信頼された型であることを保証 50 Trusted Types API
51. ReactでTrusted Typesが利用可能になった 51 Trusted Types API
52. 以前はDOM APIに渡す前に文字列変換(‘’ + value)をしていた 52 Trusted Types API
53. 値をそのまま渡すようになったため、TrustedTypesの検証が可能になった 53 Trusted Types API
54. • 入力されたデータが開発者が指定した関数を通過済みなのかを保証 • 変換関数を指定したpolicyを作成してサニタイズ • CSPを利用して信頼された型であることを保証 • ReactでTrusted Typesが利用可能 Trusted Types APIのまとめ 54 Trusted Types API
55. 終わりに 55
56. 今回紹介したWeb APIはほんの一部 • View Transition API • Popover API • Battery Status API • HTML Sanitizer API • Trusted Types API Web APIは100個以上あり、実務に活用出来るものはたくさんある 本日紹介したWeb API 56 終わりに
57. 2025年の12月1日から12月25日までWeb APIに関する記事を投稿 Web APIを学習するために1か月間アドカレを行う 57 終わりに
58. 知らない用語がたくさんあり、Web APIの前に用語の理解に時間がかかった • CSP • Baseline • Secure Context Web APIを学習する中で大変だったこと 58 終わりに
59. OSSにContributeした経験がなかったため、 経験者である先輩や同期に分からないことを聞き、PRを作成 日本語訳のTypoを見つけてMDNにContribute 59 終わりに
60. JavaScriptの仕様がまとめられているECMA262を担当 月1でECMA262についての記事を執筆 60 終わりに
61. • MDNへContribute • ECMA262の動向について記事を執筆 TPACに参加したことでWebを作っていく側に意識が変わった 61 終わりに
62. より良いプロダクトを提供するために、技術力やドメイン知識だけでなく、 Webを作っていく側の意識を持って、エンジニアの責務を果たしていきたい Webは私たちエンジニアが作っていくもの 62 終わりに
63. ©️ Cybozu, Inc. 63