Intro HPKE (Hybrid Public Key Encryption) が RFC 9180 として公開された。 RFC 9180: Hybrid Public Key Encryption https://www.rfc-editor.org/rfc/rfc9180.html HPKE は、公開鍵暗号方式と共通鍵暗号方式を組み合わせて(ハイブリッド)任意の平文を暗号化するための、汎用的な枠組みとして標準化されている。 この仕様は、多くのユースケースが想定されており、 RFC になる前から ECH (Encrypted Client Hello), MLS (Message Layer Security), OHTTP (Oblivious HTTP) など、さまざまな仕様から採用を検討されている。 本サイトで書く予定の他の記事でも HPKE は頻出する予定であり、今後より多く

Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field

Intro 長いこと作業が行われていた JavaScript の MIME タイプについての作業が完了し、 RFC 9239 として公開された。 これにより、推奨される MIME タイプが text/javascript に統一されることになった。 かつて推奨されていた application/javascript ではなくなった経緯などを踏まえ、解説する。 JavaScript MIME Types HTTP で Response する際に指定する Content-Type は、その内容がなんであるかを Client に Indicate し、適切な処理を促すために使用される。 例えば HTML が text/html であったりするように、 JS も内容はテキストなので text/javascript が自然に思える。 しかし、例えば MS が実装していた JS 互換の JScript

Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、 History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方

Intro 本ブログは Markdown で原稿を書き、それを HTML に変換して表示している。このとき、 CSS を用いて Markdown のシンタックスに似せた Style を適用している。例えば以下のように h2::before に content: '##' を指定するといった具合だ。 しかし、これまで <table> だけはうまく Markdown 記法を再現する CSS が書けないでいた。 そこで、周りの CSS 強者に実現できないか聞いてみたところ、@shqld, @araya, @yoshiko 達の協力を得て、かなりの完成度にすることができた。実現方法を記録する。 Before 実現したいのは以下のような記法だ。 | file type | size | ratio | |:----------|-----:|------:| | .webp | 9474 | 100

Intro 本サイトを HTTP3 対応し、Alt-Svc ヘッダおよび DNS HTTPS Resource Record によってそれをアドバタイズする構成を適用した。 色々ハマったので作業のログを記す。 HTTP3 on h2o Fastly の数々の発表からも h2o が HTTP3 に対応していることは自明だが、その設定方法がドキュメントに記載されておらず、なかなか設定方法がわからずにいた。先日、たまたま当該 issue の中で、設定ファイルサンプルの中にコメントアウトされたフラグがあることを教えてもらい、これをたよりに HTTP3 化を進めることができた。 したがって、ここから記す内容はドキュメントやリリースノートの内容ではないため、将来的に全然違う方法になるかもしれない点には注意が必要だ。なお、最近はリリース自体がないため master をビルドしてデプロイしている。 h2o

Intro 本サイトの PNG/JPEG で提供している画像については、よりサイズが小さくなりやすい AVIF 形式を提供し、対応ブラウザに配信するようにした。 フォーマットを出し分けるため、画像の指定は <picture> 要素を用いて対応した。 画像最適化シリーズ第 6 回目のエントリである。 画像最適化戦略 PNG/JPEG 編 画像最適化戦略 Picture 編 画像最適化戦略 WebP 編 画像最適化戦略 SVG/Font 編 画像最適化戦略 Lazy Loading 編 > 画像最適化戦略 AVIF 編 AVIF AVIF は、ロイヤリティフリーなコーデックを目指して AOMedia が開発した AV1 を、画像に転用したものだ。 AV1 Image File Format の略とされ、 AV1 の I フレームを静止画として表示するイメージだ。 Chrome 85, Fire

Intro 例年通り 2021 年を振り返る。 blog 13 本書いた。 Web のセマンティクスにおける Push と Pull 自作 Markdown プロセッサベースの blog.jxck.io v2 リリース ABNF Parser の実装 Private Relay と IP Blindness による Fingerprint 対策 mouseover 中に表示される DOM のデバッグ Cross Origin iframe からの alert/confirm/prompt 呼び出しの無効化 本サイトの AMP 提供の停止とここまでの振り返り Non AMP SXG による Prefetch 対応と AMP 提供の停止 IE11 サポート終了の歴史 Public Suffix List の用途と今起こっている問題について Web Font のメトリクス上書きによる CLS の

Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro

Intro 本サイトは自作の Markdown ビルダを使っていたが、色々と気に食わない部分があったのでフルスクラッチで作り直し、それにともなってサイトの刷新を実施した。 必要だった要件や、意思決定を作業ログとして記す。 Markdown 本サイトは、一般に使われている Markdown -> HTML の変換結果では要件を満たせないため、最も都合の良い AST を吐く Kramdown のパーサから AST だけを取得し、それを Traverser でカスタマイズしてから自前でシリアライズしていた。 その実装を、微修正を繰り返しながら、継ぎ足し継ぎ足しで 5 年くらいイジってきたので、そろそろ自分がブログを書く上での要件も固まっており、記事中の Markdown のスタイルも固定してきた。 一方、 Kramdown の実装が原因でどうしてもワークアラウンドが必要だった部分に、フラストレー

Intro IETF の RFC では ABNF 形式の表現がよく使われ、たまに実装することがある。 しかし、実装するたびに前のコードを引っ張り出して思い出す、を繰り返しているので、自分用にメモとしてやり方をまとめる。 完全に我流であり、目的は「その ABNF が正しいかを確認すること」なので、高速化や効率的を求める実用実装とは目的が違う点は先に言っておく。 ABNF パーサ 筆者が直近で書いた RFC 8941: Structured Field Values for HTTP を例にする。 例えば、ヘッダが複数の値をリスト形式で取る場合 Example-List: sugar, tea, rum これを ABNF で表現するとこうなる。 sf-list = list-member *( OWS "," OWS list-member ) list-member = sf-item /

Intro iOS15 がリリースされたため、 Private Relay のベータを試すことができた。 このようなサービスが提供されるようになった背景を踏まえ、挙動を簡単に確認しつつ、解説する。 背景 そもそも、なぜこのようなサービスが出てきたのかを理解するには、現在のインターネットが抱える問題の背景を理解する必要がある。 特に Web において問題になっている「トラッキング」を防ぐために、法的な規制や業界団体の自主規制による対策は長いこと行われてきたが、それでも看過できないインシデントなどが目立ったために、 Apple の ITP を皮切りに 3rd Party Cookie の制限が始まった。 ここで重要なのは、「本来防ぎたいのは 3rd party Cookie という技術ではなく Tracking というユースケースだ」という点だ。 この前提が伝わっていない場合、トラッキングのユ

Update 2024-03-30: Chrome 123 から "Emulate a focused page" が追加された。 これを用いれば良いため、以降の全ての方式は古くなった。 Apply other effects: enable automatic dark theme, emulate focus, and more https://developer.chrome.com/docs/devtools/rendering/apply-effects#emulate_a_focused_page マウスが乗ってないと出ない UI も、そこに Tab などでフォーカスを移し、その状態で Dev Tools の "Emulate a focused page" を有効にすれば良い。 Intro 先日、後輩が「mouseover 中にしか表示されない DOM のデバッグ」に手こずっ

しかし、実際に M92 がリリースされてからは、この機能が壊れたことによる影響が多数報告されていたため、実装者が想定していた以上に影響はあったといえるだろう。 他のブラウザの反応 実際にロールアウトしたのが Chrome/Edge であったため、いつものように「また Google が勝手にやっている」と思う人もいるようだが、実際には他のブラウザも Positive を表明している。 Firefox: https://github.com/whatwg/html/issues/5407#issuecomment-606417807 Safari: https://github.com/whatwg/html/issues/5407#issuecomment-760574422 また、この合意が取れているため、既に仕様にもマージされている。 Add early return to JS dia

Intro 前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。 これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。 その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。 ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期

Intro 本サイトを (Non AMP) SXG に対応した。 これにより、 Google のモバイル検索では、結果を表示した時点でこのサイトの SXG が Prefetch され、結果を選択したら Cache から素早く表示されつつ、 アドレスバーにも本サイトのものとして表示される。 この、 Non AMP SXG 対応にあたって、本サイトの AMP の提供も停止することになった。 移行の作業ログと、関連する流れについて記す。 (Non AMP) SXG SXG については過去に解説した。 WebPackaging の Signed HTTP Exchanges 本サイトでは AMP SXG に対応しており、 Google Search からの AMP ページへの遷移には SXG が取得され、本サイトのドメインが表示される。 AMP SXG 対応 今年の 4 月に、 AMP だけでなく

Intro IE11 が役目を終えていく流れを記録として残す。特に MS からのアナウンスや、それに準じた各サービスの反応、特に IE サポート終了アナウンスをまとめることで、 IE11 というブラウザがどのように終了していったのかのを記録することを目的とする。 もともとは Google Docs にまとめていたものである。 日付はアナウンスの公開日 サポート終了日ではない サポート終了日も書いておけばよかったけど今からやり直す気力はない、、 赤字 は MS 関連もしくはサポート終了の影響が大きそうなアナウンス Windows における IE11 自体のサポート終了については以下を参照 https://www.atmarkit.co.jp/ait/articles/1503/11/news134.html できればある程度の結論が出るまでこのエントリを更新していきたい 追加リクエスト 本エ

Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ

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

Intro IETF が策定する HTTP の仕様が更新されようとしている。 ここには、 Cache の仕様も含まれており、そのなかで must-understand という Cache-Control のディレクティブが追加されている。 このディレクティブが追加された経緯と仕様について解説する。 Cache と Status Code RFC7234 では、新しいステータスコードを策定する際に、キャッシュに関して以下のように書かれている。 The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached if the response they occur in has explicit freshnes