Intro Chrome 126 で筆者が実装した URL.parse が Ship された。 Chromium にコントリビュートしたことは何回かあったが、単体機能を Ship したのは初めてだった。 invalid URL の処理 new URL() によって、文字列の URL をパースすることができるようになって久しいが、この API は invalid な場合に例外を投げる。 例外処理をするよりも、先に URL としてパース可能かどうかを知るための URL.canParse() が提案され、先に実装が進んだ。 URL.canParse(str) // boolean しかし、これでは二回パースが必要になるため無駄が多い。 if (URL.canParse(str)) { // 1 回目のパース return new URL(str) // 2 回目のパース } そこで、失敗したら

CFP CFP の募集には fortee を使ってみようと思います。まだ慣れてないので色々と失敗すると思いますが、多めにみてください。(参加募集は fortee ではなく、慣れてる connpass を使う予定です) また、採択は fortee のプロポーサルのスターを第一基準にするので、聞きたいのはスターしてください。(なので、多分応募は早い方が有利です) プロポーザル | Web Developer Conference 2024 - fortee.jp https://fortee.jp/web-dev-conf-2024/proposal/all 募集は Session と LT の 2 枠です。 Session 40 分枠 x 12 Web 開発に関わることならなんでも可 終わったら感想戦会場に移動、そこで QA CFP を Fortee で募集 基本は Fortee のスター数

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

Intro 以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。 Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。 筆者が公開情報を読んで解釈したものなので、内容は保証しない。 前提 iOS/iPadOS に入れられるブラウザには、 WebKit を用いる必要が

Intro このエントリは、 3rd Party Cookie Advent Calendar の最終日である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここまで、 3rd Party Cookie との 30 年に渡る戦いと、 ITP 以降それが Deprecation されるに至った流れ、そして Privacy Sandbox の API について解説してきた。 最終日は、ここまでを踏まえて、来年以降の Web がどうなっていくのかを考えていく。 「Web 史上最大の破壊的変更」の意味 筆者はこのアドベントカレンダーの最初に、これを「Web 史上最大の破壊的変更」と言って始めた。 Web で破壊的変更と言え

Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont

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 「連載するけど、代わりにコードはハイライトさせてほしい」 それが Web+DB Press 編集長に俺が出した条件だった。 技術書籍のシンタックスハイライト エンジニアは普段から、エディタ上でも、リポジトリ上でも、ブログ上でも、何かしらハイライトされたコードを見ている。 そんなエンジニアに向けて書かれた技術書籍でありながら、書籍のコードがハイライトされているのはみたことがない。 「技術書籍がシンタックスハイライトされてないのは、出版社の怠慢だ」 と、割と本気で思っていた。そして、今でも思っている。 特にページを跨ぐような長いサンプルコードを、単色で印刷されても、正直読む気になれない。 白黒だからしょうがないと思われているかもしれないが、白黒だとしても、文字の太さ、濃淡、フォントの微妙な使いわけなどで、かなり見やすくすることができる。 今はやっていないが、このブログでも、印刷用の

Intro Interop 2022 の目覚ましい成果の一つとして :has() の存在がある。 これまでの CSS の限界を突破する、革新的な仕様であり、多くの開発者が期待を寄せる機能の一つだろう。 こうした仕様策定の裏には、必ずと言って良いほど互換性の問題がつきまとい、時にそれはそこまでの作業の蓄積を無に帰すレベルで影響を与える場合がある。 一方それらは Web 開発者が使う時点では解決されており、基本的に気にされることはない。 だからといって、気にする必要がないわけではない。ということを象徴する事件が、今回も裏で起こっていた。 jQuery と :has() :has() は、従来の CSS Selector の常識を変え、子の状態を元に親をクエリすることが可能となった。親から子を見る場合と比べて探索範囲が爆発的に増えるため、非常に実装が難しいとされていた。 Igalia の詳細な調

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 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 のデバッグ」に手こずっ

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

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

なお IE は(security zone setting をいじらない限り)この問題が発生しないようだ。 引用元: blankshield demo | Reverse tabnabber phishing tabnabbing 上記の挙動を、フィッシング詐欺に利用できることが既に指摘されている。 この手法は Tabnabbing と呼ばれている。 Tabnabbing: A New Type of Phishing Attack Aza on Design Target="_blank" - the most underestimated vulnerability ever この攻撃方法を解説する。 攻撃の概要 https://cgm.example.com (左上) というサービスがあるとし、これは SNS やチームコラボレーション系サービスを想定する。 攻撃者は、このサービスの不

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

Intro Web Font のサブセット化を Font Weight に応じて作り分けるとともに、それを Puppeteer を用いて生成するように変更した。 Web Font の静的サブセット 本サイトで提供している Web Font は当初、文字を事前に選定して生成したものを使っていた。 Noto Sans の Web Font 対応とサブセットによる最適化 当時はコンテンツがなかったが、コンテンツも増えた後は、コンテンツの原稿である markdown ファイルから使用している文字を抽出して生成するように変更していた。 これでおおよそ必要最小限のサイズにすることができていた。 Regular と Bold の最適化 本サイトでは Font Weight として Regular(400) と Bold(700) を提供しているが、これまでは抽出した文字種を Bold/Regular 両

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