TC39 に新設された Stage 2.7 について | blog.jxck.io
Intro TC39 の Stage 2 と Stage 3 の間に、新たに Stage 2.7 が追加された。 これはなんだろうと思った人が、検索で辿りつけるよう、その経緯と目的をまとめる。 TC39 Stages TC39 は、 ECMAScript (つまりまあ JS) の新機能を議論する Task Group だ。 ここでは、比較的自由に新機能の提案がなされ、定期的に行われるミーティングでの議論や、実装からのフィードバックを経て、 Stage が上がっていく仕組みをとっている。 旧来の Stage は 0~4 まであった。ざっくり言うと以下のようなものだ。
Apple によるブラウザエンジン規制の緩和 | blog.jxck.io
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 を用いる必要が
3PCA 9 日目: DNT | blog.jxck.io
Intro このエントリは、 3rd Party Cookie Advent Calendar の 9 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回は、 P3P の後に提案され、非常に似たコンセプトかつ最近まで使われていた DNT について解説する。 Do Not Track List 6 日目に、トラッキングからのオプトアウト方法は、基本的に三種類あるという話をした。 オプトアウトを示す Cookie を保存し、それを送られた広告ネットワークはトラッキングしない トラッキングしている業者のリストを作り、それをブラウザなどに読み込んで設定する ユーザの意図をなんらかの方法で表明する(ブラウザからオ
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
3PCA 7 日目: Cookie2 | blog.jxck.io
Intro このエントリは、 3rd Party Cookie Advent Calendar の 7 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここからは第二幕、人類と 3rd Party Cookie の闘いの歴史を見ていく。 「歴史の話はいらない、早くコードを見せろ」と思っている読者の気持ちもわかるが、残念ながら背景がわかってないとまともな闘いはできないだろう。 Cookie2 この話は、すでに別のエントリで詳細に書いたが、このアドベントカレンダーに併せて要点のみを抜粋する。 Cookie2 とは何か | blog.jxck.io https://blog.jxck.io/entries/20
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
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
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
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
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
URL バーの表示の変遷 | blog.jxck.io
Intro ついに URL バーから EV 証明書の組織表示が消されるアナウンスが、 Chrome から発表された。 思えば、 URL バーの見た目も、だいぶ変わってきたように思う。 URL バーの表示の変遷を一度まとめておく。 URL バーの再現 本当なら古いブラウザのスクショを集めたいところだったが、これは非常に難しい。ネットで色々落ちてるものをかき集めても、ライセンスや解像度や表示されている URL などを考えると、使い勝手は決して良くない。 試しに古い Chromium をビルドしてみたが、一定より古いものはうまく開くことすらできなかった。開くことができたバージョンもあったが、どうやらそれだけでは当時の URL バーの UI までは再現されないようだ。 そこで、実物のスクショはあきらめ「一般的な URL バーのイメージ」を書いた図で、おおまかな変遷を辿る。あくまで架空の図であること
IETF RFC における ABNF と Parsing Algorithm の関係 | blog.jxck.io
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 が
技術書籍をシンタックスハイライトする話 | blog.jxck.io
Intro 「連載するけど、代わりにコードはハイライトさせてほしい」 それが Web+DB Press 編集長に俺が出した条件だった。 技術書籍のシンタックスハイライト エンジニアは普段から、エディタ上でも、リポジトリ上でも、ブログ上でも、何かしらハイライトされたコードを見ている。 そんなエンジニアに向けて書かれた技術書籍でありながら、書籍のコードがハイライトされているのはみたことがない。 「技術書籍がシンタックスハイライトされてないのは、出版社の怠慢だ」 と、割と本気で思っていた。そして、今でも思っている。 特にページを跨ぐような長いサンプルコードを、単色で印刷されても、正直読む気になれない。 白黒だからしょうがないと思われているかもしれないが、白黒だとしても、文字の太さ、濃淡、フォントの微妙な使いわけなどで、かなり見やすくすることができる。 今はやっていないが、このブログでも、印刷用の
OpenAI API を用いた文書校正(誤字脱字検出) | blog.jxck.io
Intro OpenAI の API を用いて、長年の課題だった文書校正を VSCode 上で実現するプラグインを修作したところ、思った以上の成果だった。 文章校正と誤字脱字検出 執筆を補助するツールは多々開発されているが、基本は形態素解析を用いた品詞分析の延長で行うものが多かった。 よくある「助詞の連続」、「漢字の開き閉じ」、「一文の長さ」などは、ある程度の精度で検出可能ではあるが、結局執筆時に一番検出して欲しいのは「誤字脱字」だ。 文体をどんなに揃えたところで、誤字脱字があるとやはりクオリティが低く感じるし、そこさえ抑えられていれば、他のスタイル統一は訓練である程度なんとかなる。 英語のスペルチェックはかなり進んでいるが、日本語においてはそこまで革新的なものが見当たらない。あらゆるツールを試したが、結局満足のいく精度が出る誤字脱字検出は「Word の校正機能」しかなかった。 そこで筆者
誇りを被った仕様の針に意図を通す | blog.jxck.io
Intro Interop 2022 の目覚ましい成果の一つとして :has() の存在がある。 これまでの CSS の限界を突破する、革新的な仕様であり、多くの開発者が期待を寄せる機能の一つだろう。 こうした仕様策定の裏には、必ずと言って良いほど互換性の問題がつきまとい、時にそれはそこまでの作業の蓄積を無に帰すレベルで影響を与える場合がある。 一方それらは Web 開発者が使う時点では解決されており、基本的に気にされることはない。 だからといって、気にする必要がないわけではない。ということを象徴する事件が、今回も裏で起こっていた。 jQuery と :has() :has() は、従来の CSS Selector の常識を変え、子の状態を元に親をクエリすることが可能となった。親から子を見る場合と比べて探索範囲が爆発的に増えるため、非常に実装が難しいとされていた。 Igalia の詳細な調
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 な読み込みが可能なリソースでは、その読み込みが安全かどうかは別途確認する必要がある。 そこで、リソースをメモリ上に展開するためだけの、攻撃用途くらいしかあり得ないようなリソース読み込みをブロックする対
次世代 CSS 仕様が与えるコンポーネント時代の Web への影響 | blog.jxck.io
Intro SPA の隆盛で進化したフロントエンドライブラリによって生み出された「コンポーネント」という資産は、それを View 層の最小単位として扱うエコシステムにその重心をずらした。 近年の Web 開発は、虫食いのテンプレートエンジンにデータをはめ込む方式から、デザインシステムにカタログされたコンポーネント群に、 API から取得したステートを流し込み、それらを「いつ、どこで、どう」レンダリングするかという課題への最適解を、各位が模索するフェーズとなっている。 コンポーネントを敷き詰めるコンテナ側の設計は、 Flexbox および Grid の登場によるレイアウトの進化が手助けしたところも多いにある。しかし、「ページ」を前提に設計された CSS は、「コンポーネント」を前提にした設計に移行するうえで、ミッシングピースが多かった。 現在、提案/実装が進んでいる CSS の新機能群には、
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 の収録が倍に増えたこともあるので、多少はそれに甘えた気がするが、来年からは目標の月一本のペースに戻したい。 また、今年はあまりこのサイ
XMLHttpRequest とはなんだったのか | blog.jxck.io
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
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
JavaScript のメディアタイプと RFC 9239 | blog.jxck.io
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
Navigation API による「JS での画面遷移」と SPA の改善 | blog.jxck.io
Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、 History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
