Intro Chrome で Compression Dictionary Transport の Experiment が行われている。 Intent to Experiment: Compression dictionary transport with Shared Brotli https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E この提案の仕様および本サイトへの適用について解説する。 brotli の Dictionary 圧縮方式は、基本的に「同じ値が出てきたら、それらをまとめて小さく表現する」という方式が中心となる。 # 繰り返しを数値で表現する場合 from: aaaabbbbb to: a4b5 この方式は、対象としたデータの中で、如何に効率よく「同じ値」を見つけるかが肝となる。例えば以下の例

Intro 最近 AbortSignal.any() が提案され、急速に実装が進んでいる。 すでに定義されている AbortSignal.timeout() や addEventListener() への Signal なども含め、非同期処理の中断を実装する際の API はかなり整備されてきた。 これら API のモチベーションと設計を中心にまとめる。 Abort 後のリソース解放 AbortSignal によって、非同期処理のキャンセルが可能になった。例として、 Server 上での Fetch のタイムアウトの例を考えよう。 app.get("/entries", async (req, res) => { const perRequestController = new AbortController() const perRequestSignal = perRequestCont

Intro WebFont を読み込む際に、取得完了までのラグを、システムが持つフォールバックフォントで代替する場合がある。 このとき、フォールバックフォントと読み込んだ Web フォントで、高さに関する情報が異なる場合、 Layout Shift が発生してしまう。 これを防ぐ方法として、 CSS からフォントメトリクスの上書きを行う仕様の提案が行われているため、本サイトへの適用を目指し検証を行った。 なお、この仕様は Layout Shift ではなく、単純にテキストレイアウトスタイル用途での利用も考えられるが、そこはスコープ外としている。 Font metrics override これらの値を @font-face で指定する。 @font-face { font-family: "helvetica-override"; src: local("Helvetica"); asce

Token が文字列とは別に定義されているため、実装する言語によっては設計に悩む(JS 実装では Symbol を使っている)。 Parameter Parameter は Item に付与できるメタデータだ。 例えば以下は String の "abc" に対してパラメータを 2 つ付与している。 // "abc";a=1;b=2 { "value": "abc", "params": { "a": 1, "b": 2 } } データ表現には基本的に Key/Value/Metadata の 3 つがあることが望ましい。 例えば XML/HTML のようなフォーマットは Attribute がメタデータを担うが、これを再現可能になる。 <p id="foo" class="bar">hello</p> // p="hello world";id="foo";class="bar" { "p

Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって

Intro WebBundle を用いてサブリソースのみを Bundle する、 Subresource Bundle の策定と実装が進んでいる。 これを用いると、複数サブリソースの取得を一回の fetch で行うことができ、 RTT を減らしつつも個別に取得したかのようにキャッシュを制御できる。 現時点での仕様と実装を解説する。 Intent to Prototype: Subresource loading with Web Bundles Subresource Bundling WebBundle の初期の仕様は、 HTML を頂点としたページ全体をまとめる方向で始まった。 WebBundle によるコンテンツの結合と WebPackaging | blog.jxck.io これをサブリソース(JS, CSS, Img etc)に対して利用できるようにする仕様だ。 HTML 自体は

Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う

Intro WebTransport の Quic 実装である QuicTransport の開発が Chrome で行われている。 Chrome で Origin Trials が開始されたので仕様と実装を解説する。 QuicTransport WebTransport については 以前解説した が、位置づけとしてはこうだ。 WebTransport QuicTransport Http3Transport 今回入ったのは、 WebTransport の通信レイヤとして QUIC を用いた QuicTransport という位置づけになる。 IETF で WebTransport over QUIC としてバインディングの仕様が策定され、 WICG でブラウザ API が策定されている。 draft-vvv-webtransport-quic-00 - WebTransport over

Intro Origin は Web におけるセキュリティモデルの一つとして、コンテンツ間の Communication に関する境界を定義し、リソースを保護してきた。 しかし、 Spectre の発覚以降、 Communication に関する制限だけではなく Isolation によるメモリレベルでのアクセス制御が必要となった。 そこで現在作業されているのが、 CORB, CORP, COEP, COOP といった仕様群であり、これは Web におけるセキュリティモデルの更新作業と見ることができる。 概要と現状について解説する。 DEMO & Resources 量が多いため、動作する DEMO と関連リソースは、ページ下部にまとめてある。 CORS による Cross Origin Communication の制限 CORS は、平たく言えば、リソース提供元(サーバ)が、クライアン

Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る

Intro Web サービスにおいては通常、 Web サーバから取得できるアクセスログやエラーログを取得し解析する基盤を保有するだろう。 しかし、 Web サーバから取得できる情報だけでは、ブラウザで何が起こったのかを知るのは限界がある。 今回は、ブラウザ内で起こったことを知るための Reporting API と、その Report の収集について解説する。 Notice 本記事の大半は 1 年以上前に書いたものだが、そのころは仕様も実装もまだまだ落ち着きが無かった。 仕様 report-uri から report-to への移行期 JFV の採用への不安 実装 ディレクティブの実装がバラバラ ReportingObserver では取れるが default group に自動では飛ばない(未実装) ReportingObserver で取った report が JSON Seriali

Intro 依存コンテンツを 1 つにまとめて配信する WebBundle の仕様策定と実装が進んでいる。 これは Signed HTTP Exchange と合わせて WebPackaging を実現するための仕様であり、組み合わせれば WebBundle に対して署名することでコンテンツの配信を通信と分けて考えることができる。 Signed HTTP Exchange に比べると格段に簡単な仕様なので、現状のフォーマットと挙動について解説する。 draft-yasskin-wpack-bundled-exchanges-latest WebBundle かつて Bundled HTTP Exchanges と呼ばれていた仕様であり、複数のコンテンツを 1 つにまとめ、配信することができる。 例えば index.html とそれが依存する css/js/favicon etc を 1 つ

Alternatives 結局 WebSocket が TCP に縛られていなければ良いのではという点に注目すると、 WebSocket over HTTP/3 が実現できれば HoLB などの問題は解決しそうだ。 しかし、仮にそこに複数のストリームを束ねようとしても、 WS の特徴上ストリームごとに 1RTT のハンドシェイクが必要となる。また、サーバから Stream を開始することができない(本当にそれが必要なのかは疑問だが)という問題があげられている。 また、 WebRTC の文脈で進んでいる RTCQuicTransport が、非常にというかあるケースではほぼ同じことを提供することになる点が指摘される。(策定者も同じ) これもやはり、 WebRTC が P2P 前提の仕様でスタートした点と Client-Server ユースケースとの乖離をベースに説明されており、すでに RTC

Intro JS における null/undefined の扱い改善するための 2 つの機能が提案されている。 Nullish Coalescing Operator (stage 3) Optional Chaining Operator (stage 3) いずれも Stage 3 に進み、実装も始まっているので、現時点での解説を行う。 Nullish Coalescing 対象が null/undefined だった場合にデフォルト値を返したいといった場合を考える。 function main(option) { option.param = option.param || 'default' } main({param : 'hello'}) しかし、この場合は null/undefined 以外にも param が 0, false, '' など falsy な値の場合も上書きさ

Intro React や lit-html などにより、 DOM 操作の抽象化に加えて最適化が提供されることが一般的となった。 見方を変えれば、本来ブラウザがやるような最適化を、ライブラリが肩代わりしていると捉えることもできる。 これは、現在の標準 API には、規模が大きく処理が複雑なアプリケーションを開発する際に、足りてないものがあると考えることが可能だ。 課題の 1 つとして「DOM 操作が同期処理である」という点に着目し、 Async DOM という文脈でいくつかの提案が行われた。 今回は、その提案の 1 つであり Chrome で実装が進んでいる Display Locking について現状を解説する。 現状の DOM 操作の課題 まず、以下のような処理を考える。 body.appendChild($div) この処理が JS の途中で出現すれば、その瞬間 Window にある

Intro 2019/4/28 - 5/1 の 4 日間で、 mozaic bootcamp 2019 というひたすら Web 技術を叩き込むイベントを開催した。 その内容やモチベーションについては、以下で話している。 ep48 Monthly Web 201901 | mozaic.fm このイベントの概要と目的について記録する。 概要 Web に限らず、初学者を対象とした書籍, イベント, 動画, 研修など、最初のステップを踏むためのコンテンツは幸いなことに充実してきている。 一方、そうしたコンテンツを修め、基礎的な部分をある程度理解した人が、次のステップに進むためのコンテンツは途端に減り、どうすればより成長できるのかで悩む時期があるように感じている(筆者がそうだった)。 自分でなんとかするしか無いといえばそうだが、そうした迷える中級者に対しても、もう少しできることがあるのではないかと

Intro httpbis のチェアである mnot から、 Cache Digest についての現状確認が ML に投稿された。 もしこのまま反応がなければ、 Cache Digest は終わり、対ブラウザキャッシュの Server Push は現実的ではなくなる。 Update mozilla standard position に RFP を上げたところ「実装はしないが仕様については non-harmful」となりそうだ。 PFP: Cache Digest Issue #131 mozilla/standards-positions HTTP2 Push HTTP2 の仕様策定時に盛り込まれた新機能として、 Server Push があった。 これは、例えば RPC 的な用途で双方向性のある通信を可能にした。 Web においては、リクエストが来る前にレスポンスを返しキャッシュに入れ

Intro macOS Mojava は OS レベルで Dark Mode に対応した。 しかし、 Web コンテンツは依然として白背景黒文字ベースのデザインが多く、結果ブラウザの中だけ眩しいという問題がある。 Safari TP69 では、これにメディアクエリで対応するための prefers-color-scheme が実装された。 これを用いた DarkMode 対応と、本ブログの DarkMode 対応、および策定中の User Preference Media Features について解説する。 Update 画像の対応について追記した Code Block の対応について追記した 2019/1 に Chrome の Intents が出された。 Intent to Implement: Media Queries: prefers-color-scheme feature I

Intro WebPackaging は以下の 3 つの仕様を組み合わせたユースケースである。 Signed HTTP Exchanges: Signing (コンテンツに署名する) Bundled HTTP Exchanges: Bundling (コンテンツを 1 つにまとめる) Loading Signed Exchanges: Loading (そのコンテンツをロードする) 本エントリでは、各仕様を Signing/Bundling/Loading と記す。 現状、 Signing および Loading の仕様策定が進んでおり、 Chrome は Experimental な実装を行っている。 全体的に仕様が大きく、今後も変更される可能性が高いため、今回は実装が進んでいる Signing に絞り、ユースケース、仕様、および本ブログへの適用を中心に解説する。 Signing (Si

Intro ブラウザの機能を制限する Feature Policy の実装が進みつつある。 Feature Policy は、ブラウザが持つ機能について選択的に許可/制限を行う API だ。 AMP のように特定の機能を制限する目的にも使えるが、クロスオリジン iframe に対する権限移譲のための API としても使用される。 Feature Policy のモチベーションおよび適用方法について、類似する CSP や iframe sandbox と合わせて解説する。 なお、今回解説する内容は、まだブラウザの実装に反映されていない部分があるため、注意されたい。 Motivation まず Feature Policy のモチベーションとして、 機能の制限 と 権限の移譲 という二つのニーズを解説する。 機能の制限 パフォーマンスやセキュリティの観点から、実装はあるが、使用する上で制限を設