Intro 昨今、特に広告サービスを中心に 3rd Party Cookie を用いたトラッキングについての議論が多く行われている。 Safari による ITP や、 Chrome による Privacy Sandbox への移行など、技術的な変化も著しい。 こうした技術の変遷を観測し、調査検証を行うために、これまで避けていた Web 広告を本サイトに導入することにした。 Motivation 本サイトは、様々な Web に関する技術を調査し、実際に試すためにサイト自体に適用しながらそれを記事にまとめるという目的で運用してきた。 様々な技術を試したり、そのパフォーマンスやセキュリティへの影響を評価する上で、一般的なサイトの構成とかけ離れていれば、あまり意味をなさない。 そのため、本サイトでは以下のように、別に必要はない機能やサービスをあえて導入している。 AMP AMP より Origi
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 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 回目のパース } そこで、失敗したら
Intro 本サイトは自作の Markdown ビルダを使っていたが、色々と気に食わない部分があったのでフルスクラッチで作り直し、それにともなってサイトの刷新を実施した。 必要だった要件や、意思決定を作業ログとして記す。 Markdown 本サイトは、一般に使われている Markdown -> HTML の変換結果では要件を満たせないため、最も都合の良い AST を吐く Kramdown のパーサから AST だけを取得し、それを Traverser でカスタマイズしてから自前でシリアライズしていた。 その実装を、微修正を繰り返しながら、継ぎ足し継ぎ足しで 5 年くらいイジってきたので、そろそろ自分がブログを書く上での要件も固まっており、記事中の Markdown のスタイルも固定してきた。 一方、 Kramdown の実装が原因でどうしてもワークアラウンドが必要だった部分に、フラストレー
Intro mozaic.fm をリニューアルし v3 としてリリースした。 今回の更新は以下のような変更/修正を実施している。 PWA 化 before install prompt Background Fetch Periodic Background Sync Content Index API Badging API Player UI の刷新 Pure Webcomponents Media Session API WAI-ARIA Portal Preview Screen Wake Lock Security CSP v3 (not Report-Only) Cross Origin Resource Policy Cross Origin Opener Policy Cross Origin Embedder Policy Expect-CT NEL Referrer P
Intro WebFont を読み込む際に、取得完了までのラグを、システムが持つフォールバックフォントで代替する場合がある。 このとき、フォールバックフォントと読み込んだ Web フォントで、高さに関する情報が異なる場合、 Layout Shift が発生してしまう。 これを防ぐ方法として、 CSS からフォントメトリクスの上書きを行う仕様の提案が行われているため、本サイトへの適用を目指し検証を行った。 なお、この仕様は Layout Shift ではなく、単純にテキストレイアウトスタイル用途での利用も考えられるが、そこはスコープ外としている。 Font metrics override これらの値を @font-face で指定する。 @font-face { font-family: "helvetica-override"; src: local("Helvetica"); asce
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 本ブログは Markdown で原稿を書き、それを HTML に変換して表示している。このとき、 CSS を用いて Markdown のシンタックスに似せた Style を適用している。例えば以下のように h2::before に content: '##' を指定するといった具合だ。 しかし、これまで <table> だけはうまく Markdown 記法を再現する CSS が書けないでいた。 そこで、周りの CSS 強者に実現できないか聞いてみたところ、@shqld, @araya, @yoshiko 達の協力を得て、かなりの完成度にすることができた。実現方法を記録する。 Before 実現したいのは以下のような記法だ。 | file type | size | ratio | |:----------|-----:|------:| | .webp | 9474 | 100
Intro 2023 年の Web 技術を振り返る試験として、「Web 技術年末試験 2023」を実施した。 その問題と想定解答、平均点などを公開する。 Web 技術年末試験 この試験は、「去年の Web にはどんな変化があったか」「どんな新しい技術が出てきたか」などを、試験形式で振り返るコンテンツを作ってみたことに端を発している。 2022 年はこれを狭い範囲で実施したが、思った以上に評判が良かったため、 2023 は受験者を一般募集してみることにした。 試験形式であるため点数は出るが、目的は「今年はこんなことがあった」を振り返ることや、「こんなことがあったのは知らなかった」という取りこぼしに気づく機会になることである。 解答用紙/想定回答 [解答用紙]: Web 技術年末試験 2023 https://docs.google.com/document/d/1jdN0NsM-PAnYRl
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 な値の場合も上書きさ
Structured Field Values による Header Field の構造化 | blog.jxck.io
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
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 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
CORB から ORB へ | blog.jxck.io
Intro CORB (Cross Origin Read Blocking) が Fetch の仕様から消え、後継の ORB (Opaque Response Blocking) が策定作業中である。 ここでどのような変更が起こっているのかを調査し、記録する。 CORB CORB はもともと、 Spectre に端を発する Site Isolation の走りとして始まった。 Spectre のサイドチャネル対策のためには、本来アクセスできてはならない Cross Origin のリソースが、同一のプロセスに展開されることを防ぐ必要がある。 CORS で行われるなら良いが、 no-cors な読み込みが可能なリソースでは、その読み込みが安全かどうかは別途確認する必要がある。 そこで、リソースをメモリ上に展開するためだけの、攻撃用途くらいしかあり得ないようなリソース読み込みをブロックする対
Intro Pinterest でおなじみの Masonry Layout を CSS の標準にする作業と実装が進んでいる。 Masonry Layout 以下のように画像を敷き詰めるタイルレイアウトのことを Masonry (石工やレンガ造りの意味らしい) Layout という。 上の例の場合は、 Height が不揃いの画像を並べる上で、左から敷き詰め、折り返したら既にある画像の高さに合わせて二列目が始まるというロジックになる。 これを実現するには、割と複雑な CSS を書く必要があり、様々なサイトで CSS ライブラリや、 Grid などを用いて再現する方法が紹介されている。 これをそのまま CSS の標準にする作業が Layout API の文脈で行われており、既に一部が(主に Firefox で)実装されている。 grid: masonry; 仕様は以下だ。 CSS Grid L
Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H
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 TC39 の Stage 2 と Stage 3 の間に、新たに Stage 2.7 が追加された。 これはなんだろうと思った人が、検索で辿りつけるよう、その経緯と目的をまとめる。 TC39 Stages TC39 は、 ECMAScript (つまりまあ JS) の新機能を議論する Task Group だ。 ここでは、比較的自由に新機能の提案がなされ、定期的に行われるミーティングでの議論や、実装からのフィードバックを経て、 Stage が上がっていく仕組みをとっている。 旧来の Stage は 0~4 まであった。ざっくり言うと以下のようなものだ。
Periodic Background Sync 及び Web を Install するということ | blog.jxck.io
Intro メールクライアントや RSS リーダーのようなユースケースを PWA で実装する場合、バックグラウンドで定期的にタスクを実行したいケースがある。 このユースケースに特化した API として提案されているのが、 Periodic Background Sync(PBS) だ。 しかし、この API を取り巻く議論は「Web にアプリのような API を持ち込む上での難しさ」を物語っている。 この API が Web において正当化できるかどうかは、 Project Fugu に代表される Application Capabilities を Web に持ち込む場合の試金石になりそうだ。 現時点での、仕様、実装、議論について解説する。 Periodic Background Sync Web で定期的なタスクを実行する場合、タブが開いていれば setInterval() などで行う
Compression Dictionary Transport (Shared Brotli) によるコンテンツ圧縮の最適化 | blog.jxck.io
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 この方式は、対象としたデータの中で、如何に効率よく「同じ値」を見つけるかが肝となる。例えば以下の例
3PCA 1 日目: 3rd Party Cookie Advent Calendar Agenda | blog.jxck.io
Intro このエントリは、 3rd Party Cookie Advent Calendar の 1 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie Agenda 2024 年は、いよいよ 3rd Party Cookie の Deprecation が本格的に開始される。 これは端的に言えば「Web の歴史上最大の破壊的変更」と思って差し支えない。 一方、そのインパクトに対してエコシステム側に万全の準備が整っているかというと、決してそうとは言えない。 そもそも事態を認識していない人もいれば、大した影響を想定していない人もいるだろう。 「3rd Party Cookie が使えないなら、代わりに何か別の
AbortSignal.any(), AbortSignal.timeout(), そして addEvnetListener() の Signal | blog.jxck.io
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 ブラウザの持つ Video/Audio コーデック実装へアクセスする API として WebCodecs の仕様策定と実装が進んでいる。 これにより、映像や音声の変換などといったユースケースへの応用も可能だ。 本来なら WebCodecs 単体の API について解説するところだが、筆者がこの API を待っていた理由であるところの「WebRTC の代替」としての WebCodecs/WebTransport の応用に注目し、背景も踏まえて解説する。 WebRTC WebRTC は UDP 上に DTLS で交換した鍵を用いて、 RTP を SRTP で流し、そのシグナリングに SDP を、ホールパンチに ICE(STUN/TURN) を用いることで、 P2P ビデオチャットといったユースケースを可能にした API だ。 しかし、最初から「P2P ビデオチャット」というユースケ
Intro 「議論だけ」のカンファレンスを、長いこと開催してきた。 個人的には好きなので、他にもあったらいいと思っているが、そういうカンファレンスは他に見ない。 カンファレンス自体を、筆者のような個人が手弁当でやれるのは、もう最後かもしれないと今回ひしひしと感じたので、これまでどうやってきたのかを残しておくことにする。 「議論」だけ 特に日本では、勉強会やカンファレンスは、「スライドの発表会」形式として定着している。 これは、絞られたテーマについて、まとまった形で聴くことができ、資料も後で共有できる点でメリットはある。 しかし、全部がそうである必要はないのでは? とずっと思っていた。 特に懇親会では、雑に集まって、雑に議論が始まり、雑に盛り上がって、勉強になる上に単純に楽しいという経験をした人も少なくないと思う。 スライドで発表する場合は、スライドに収まる話しか出てこない。 30 分しか枠
Intro Scroll to Text Fragment のユースケースとして、本サイトにサイト内検索を実装した。 Scroll to Text Fragment Scroll to Text Fragment(以下 S2TF) は Chrome 80 で Ship され、 Finch で展開されている。 まだ降りてきてない場合は、 Flag による有効化が必要だ。 詳細は以前このブログでも書いている。 Scroll To Text Fragment と :~:text | blog.jxck.io この機能の使い道の一つとして、検索結果の Deep Link への適用があると考え、 PoC として実装した。 検索結果への適用 このサイトを CSP というキーワードで検索した場合を考える。 検索対象は、記事の本文とすると、例えば以下の一文がヒットする。 Feature Policy のモ
Service Worker の Background Fetch によるメディアのキャッシュ | blog.jxck.io
Intro Podcast を PWA 対応するために、待望だった機能の 1 つが Background Fetch だ。 これにより、通常 Range Request で取得するような、大きなファイルを事前にダウンロードしておくことができるようになる。 この API と、 Service Worker およびブラウザにおける Range Request/Partial Response の扱いについて記す。 background fetch Podcast は大きな音声ファイルがメインコンテンツとなる。 PWA のキャッシュ戦略典型例としては install 時に全てキャッシュする request 発生時にキャッシュする といった方法がある。 しかし、この方法は一般的な Podcast としては少し使いにくい。 install 時に全てのファイルをキャッシするのは現実的ではない requ
Intro HTTPBis では、 RFC 8941: Structured Field Values (以下 SFV) の更新作業が行われている。 RFC 8941: Structured Field Values for HTTP https://www.rfc-editor.org/rfc/rfc8941.html 機能面では Date 型が追加されるという点が大きいが、個人的にはその裏で行われるもっと興味深い議論に注目したい。 それは、「RFC における ABNF の立ち位置」に関するものだ。 ABNF と Parsing Algorithm SFV は、簡単に言えば HTTP Field Value のための構造化フォーマットで、 JSON がそのまま使えなかったことに対する代替仕様だ。よって、基本的には目的となる構造体と文字列フォーマット間の Encode / Decode が
画像最適化戦略 AVIF 編 | blog.jxck.io
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
3PCA 8 日目: P3P | blog.jxck.io
Intro このエントリは、3rd Party Cookie Advent Calendar の 8 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回は、Cookie2 が失敗した後に、別のアプローチでこの課題に挑んだ P3P を解説する。 P3P (Platform for Privacy Preferences) P3P は W3C では 1997 年頃から作業が始まり、2002 年に 1.0 が Recommendation になっている。 The Platform for Privacy Preferences 1.0 (P3P1.0) Specification (w3.org) https
Intro このエントリは、 3rd Party Cookie Advent Calendar の 3 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は 「Cookie は 区別 と 識別 の用途があり、 区別 だけのユースケースもある」という解説をした。 今回も、もう少し Cookie の性質を振り返っていく。 保存したドメインに自動で送り返す ブラウザは Set-Cookie してきたサイトを覚えておき、そのサイトにアクセスするたびに Cookie ヘッダで自動で送り返すという話だった。 例として、EC サイトにログインし Cookie が振られた場面を考える。 POST /login HTTP
Intro このエントリは、 3rd Party Cookie Advent Calendar の 19 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は Super Cookie の解説をする。迂回手段ゾーンとしては、最後に紹介する手法だ。 Super Cookie Super Cookie は、最初筆者も非常に驚いた、トラッカーの執念を感じる手法だ。 まず前提として、ブラウザのどこかに情報を保存でき、それがある程度の期間永続化され、かつ自動的に取得できるようなものであれば、トラッキングに応用が効く。 そこで目がつけられたのが HSTS (HTTP Strict Transport Securit
Noto Sans Hinted と font-feature-settings: 'palt' | blog.jxck.io
Intro Noto Sans のサブセット生成を見なおし、 Noto Sans Hinted から pyftsubset で生成し、ついでに font-feature-settings を有効にした。 作業と検証の記録を兼ねて、実施結果を記す。 fonttools これまで、フォントのサブセットの生成には以下の 2 つのツールを使用していた。 サブセットフォントメーカー WOFF コンバータ しかし、 macOS を Catalina にあげたところ、これらが起動できなくなり、フォントが生成できなくなった。 これまで GUI で行なっていたが、せっかくなので自動化するために、代替コマンドを探し、プロセスを組んだ。 いくつかツールがあるが、今回は fonttools に同梱された pyftsubset を採用することとした。 fonttools/fonttools pyftsubset こ
Intro 2014 年 3 月に開始した mozaic.fm が、気づいたら 10 周年を迎えた。 これを機に、 10 周年記念イベントとして、初のオフラインイベントをゲンロンカフェで開催した。 Podcast でのみ告知し、当日まで情報制限をかけていたにもかかわらず、チケットもグッズも無事完売することができた。 イベントを振り返りつつログを残す。 10 周年記念イベント mozaic.fm は 2014 年 3 月に配信を開始したが、これまで一度もイベントのようなことをやってこなかった。 2022 年 8 月の ep100 を記念して、一度くらいはオフラインイベントをやってみるかという計画があったが、コロナ禍であったためキャンセルになった。 今回は、そのリベンジも兼ね、リスナーのみに向けたイベントとして開催した。 当日の模様は録音し、一部を mozaic.fm で公開している。 ep1
AMP SXG 対応 | blog.jxck.io
Intro 本サイトを AMP SXG に対応した。その作業ログを記す。 AMP SXG AMP は、大きく AMP HTML と AMP Cache からなる。 AMP HTML 自体は、ルールに則って作った HTML でしかない。しかし、 Google のクローラが取得すると、 Google が管理する AMP Cache の CDN に保存される。 そして、モバイルの Google 検索で、稲妻マークが出た検索結果をクリックすると、自分のサーバにリクエストが来るのではなく、 Google の AMP Cache にリクエストが行き、そこに保存された AMP HTML が返されている。 したがって、 AMP ページを表示すると、その URL バーが Google の URL になり、その仕組自体が色々と物議を呼んだりした。 Google は AMP に SXG を組み合わせることで、
Intro このエントリは、 3rd Party Cookie Advent Calendar の 21 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie Google が 3rd Party Cookie を Deprecate していく方針を発表してから、最初に始めたのが SameSite Lax by Default だった。 これが何のために行われたのかを解説する。 eTLD+1 とは SameSite とは「eTLD+1 が同じ」という説明になる。これを理解するには eTLD を理解する必要がある。 例として example.com ドメインを持ち、そこに以下のような Cookie を付与するとこ
Intro Promise.withResolvers() は、 Stage 4 であり ES2024 の候補となった。 すでにブラウザでの実装も進んでいるため、その活用方法を解説する。 イベントの Promise 化 JS では、非同期処理 API は長らくイベントリスナベースで定義され、それを組み合わせるフロー制御で処理されてきた。 しかし、 Promise が定義されて以降は、標準 API も Promise を返すようになり、 async/await によって処理されるのが一般的になってきた。 結果、イベントリスナベースの API を Promise 化するような場面も増えた。 例えば以下のようなものだ。 async function request() { return new Promise((resolve, reject) => { document.querySelect
2019 年をふりかえる | blog.jxck.io
Intro 例年通り 2019 年を振り返る blog 今年は 15 本書いた。 毎月書く、というなんとなくの目標があったが、やっぱり書けるときは書けるし、書けないときは書けないので、途中からあまり気にしないようにした。 書く習慣自体は付いてるので、逆により自由に、必要なときに必要なものを書けるようになったと思う。 また、ブログの自体のコードや機能改善も色々行っており、かつてブログ中で解説した内容をどう更新するのかもそろそろ考える必要がある。 今が量と質のバランスが割と取れていると思うので、来年もこのくらいのペースを維持していきたい。 mozaic.fm Monthly(11) + Yearly(1) + 通常回(3) = 15 本公開した。 Monthly も開始から 2 年以上経ち、全体の流れを追うための起点としてかなり充実してきたと思う。 まとめ方もだいぶ落ち着いてきて、取捨選択もう
Intro このエントリは、 3rd Party Cookie Advent Calendar の 11 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 前回は、各国で法律が整備されていった流れや、主な法律の特徴を解説した。 しかし、法律はあくまで法律であり仕様ではないため、「どう実装するべきか」は各サービスに委ねられている(ガイドラインなどはあるが)。 多くの場合これを Web の実装に落とし込むと、いわゆる「Cookie バナー」相当になるわけだ。 今回は、実世界でどのようなバナーが提供されているのかを見ていく。 Cookie Banner "Cookie Banner", "Cookie Notic
2022 年を振り返る | blog.jxck.io
Intro 例年通り 2022 年を振り返る。 blog 今年は 10 本書いた。 CORB から ORB へ XMLHttpRequest とはなんだったのか HPKE とは何か HTTP 関連 RFC が大量に出た話と 3 行まとめ JavaScript のメディアタイプと RFC 9239 Navigation API による「JS での画面遷移」と SPA の改善 Markdown の Table 記法を CSS で実現する サイトの HTTP3 化と DNS HTTPS RR および Alt-Svc Header によるアドバタイズ 画像最適化戦略 AVIF 編 少し Blog を書く時間を取れてなかったところがある。 今年は mozaic.fm の収録が倍に増えたこともあるので、多少はそれに甘えた気がするが、来年からは目標の月一本のペースに戻したい。 また、今年はあまりこのサイ
ABNF Parser の実装 | blog.jxck.io
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 /
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
3rd Party Cookie 調査のための Web 広告導入 | blog.jxck.io
Non AMP SXG による Prefetch 対応と AMP 提供の停止 | blog.jxck.io
URL.parse を Chromium で Ship するまで | blog.jxck.io
自作 Markdown プロセッサベースの blog.jxck.io v2 リリース | blog.jxck.io
mozaic.fm v3 リリースと Podcast の PWA 化 | blog.jxck.io
Web Font のメトリクス上書きによる CLS の改善 | blog.jxck.io
Webbundle によるサブリソース取得の最適化 | blog.jxck.io
Markdown の Table 記法を CSS で実現する | blog.jxck.io
Web 技術年末試験 2023 講評 #web_exam2023 | blog.jxck.io
Nullish Coalescing と Optional Chaining | blog.jxck.io
Web Developer Conference 2024 開催告知 #wdc2024 | blog.jxck.io
Cache-Control: must-understand ディレクティブとは何か | blog.jxck.io
CSS Layout API で Masonry Layout | blog.jxck.io
Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
QuicTransport によるアプリケーションレイヤでの QUIC 活用 | blog.jxck.io
TC39 に新設された Stage 2.7 について | blog.jxck.io
WebCodecs と WebTransport でビデオチャット | blog.jxck.io
「議論だけ」のカンファレンスの作り方 | blog.jxck.io
Scroll to Text Fragment を用いたサイト内検索の実装 | blog.jxck.io
IETF RFC における ABNF と Parsing Algorithm の関係 | blog.jxck.io
3PCA 3 日目: 自動で送られる Cookie | blog.jxck.io
3PCA 19 日目: Super Cookie | blog.jxck.io
mozaic.fm 10 周年記念イベント開催後記 | blog.jxck.io
3PCA 21 日目: SameSite Cookie | blog.jxck.io
Promise.withResolvers によるイベントの Promise 化 | blog.jxck.io
3PCA 11 日目: Cookie Banner | blog.jxck.io