Intro showModalDialog() は今から考えれば、確かにひどい API だった。 しかし、何か Modal を開き、ユーザにインタラクションをさせ、閉じたらそこで入力された値や選択された結果を取得し、処理を進めたいユースケース自体は、規約への同意取得や、 Cookie バナー、ログインなど多々ある。 そういった場面では、ライブラリなどを用いて実装する必要があったが、 Modal を実装するのは実際にはそんなに簡単ではなかった。 Modal, Dialog, Modal Dialog 最初に、用語を少し整理しておこう。 Modal Dialog Modal Dialog non-Modal Dialog Dialog とは、そもそも「対話」という意味であり、 UI の文脈では入力や選択を求める「対話的な UI」のことを指す。 既に実装されている alert(), confir

Intro Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。 ブラウザエンジンとは ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。 ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。 ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。 その上に、例えばタブ

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio

Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を

Intro JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。 document.cookie document.cookie は、ブラウザの API における代表的な技術的負債の一つと言える。 HTML Standard https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie 基本的な使い方は以下だ。 document.cookie = "a=b" console.log(document.cookie) // a=b まず、この API の問題を振り返る。 同期 API 最も深刻なのは、 I/O を伴いながら、同期 API として定義されているところだ。 この API は古くから実装されているため、I/O は非同期

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 OpenAI の API を用いて、長年の課題だった文書校正を VSCode 上で実現するプラグインを修作したところ、思った以上の成果だった。 文章校正と誤字脱字検出 執筆を補助するツールは多々開発されているが、基本は形態素解析を用いた品詞分析の延長で行うものが多かった。 よくある「助詞の連続」、「漢字の開き閉じ」、「一文の長さ」などは、ある程度の精度で検出可能ではあるが、結局執筆時に一番検出して欲しいのは「誤字脱字」だ。 文体をどんなに揃えたところで、誤字脱字があるとやはりクオリティが低く感じるし、そこさえ抑えられていれば、他のスタイル統一は訓練である程度なんとかなる。 英語のスペルチェックはかなり進んでいるが、日本語においてはそこまで革新的なものが見当たらない。あらゆるツールを試したが、結局満足のいく精度が出る誤字脱字検出は「Word の校正機能」しかなかった。 そこで筆者

Intro SPA の隆盛で進化したフロントエンドライブラリによって生み出された「コンポーネント」という資産は、それを View 層の最小単位として扱うエコシステムにその重心をずらした。 近年の Web 開発は、虫食いのテンプレートエンジンにデータをはめ込む方式から、デザインシステムにカタログされたコンポーネント群に、 API から取得したステートを流し込み、それらを「いつ、どこで、どう」レンダリングするかという課題への最適解を、各位が模索するフェーズとなっている。 コンポーネントを敷き詰めるコンテナ側の設計は、 Flexbox および Grid の登場によるレイアウトの進化が手助けしたところも多いにある。しかし、「ページ」を前提に設計された CSS は、「コンポーネント」を前提にした設計に移行するうえで、ミッシングピースが多かった。 現在、提案/実装が進んでいる CSS の新機能群には、

Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命

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

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

Intro <img> や <picture> で srcset に複数の画像を指定することで、デバイスに応じて適切な解像度の画像を提供することができる。 この画像が、どういった条件で選択されるのかを頭では勝手に理解していたつもりだが、理解とは違う挙動があったため、仕様と実装を確認した。 その記録を記す。なお、先に言うがどのブラウザも 仕様に準拠して 実装されている。 srcset attribute まず以下のようなコードを考える。 <style> body { margin: 0; } </style> <body> <img id=hero_image src=320x240.png srcset=" 320x240.png 320w, 640x480.png 640w, 800x600.png 800w, 1024x768.png 1024w, 1280x960.png 1280w

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

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

Intro ページ内の特定の位置へのスクロールは、 URL フラグメントと HTML の ID 属性を用いて行われていた。 しかし、 ID を持たない要素へのスクロールというユースケースをカバーするために、フラグメントの拡張仕様が提案されている。 Chrome がフラグ付きで実装しているため、この仕様の特徴について解説する。 id 属性とフラグメント 従来の仕様では、 HTML 内にある ID 属性を URL フラグメントに付与することで、その要素まで自動でスクロールするという仕様になっていた。 https://html.spec.whatwg.org/multipage/browsing-the-web.html#try-to-scroll-to-the-fragment https://html.spec.whatwg.org/multipage/browsing-the-web.ht

Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI