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 を用いる必要が
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
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 のサブドメインを販売しているレ
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
Houdini Paint API | blog.jxck.io
Intro Houdini で議論されている CSS Paint API が Chrome Canary で flag 付きで実装されている。 デモの実装を通して、関連仕様を含めた以下の 4 つのドラフトを解説する。 CSS Painting API Level 1 CSS Properties and Values API Level 1 CSS Typed OM Level 1 Worklets Level 1 CSS Paint API CSS Paint API は、特定の領域に対して任意の描画を行うことができる仕様である。 CSS Painting API Level 1 例えば、これまで border は、仕様に定義されたいくつかの種類の style から選び、無いものは画像で代替するのが基本だった。 CSS Paint API は用意した領域に対し、画像ではなく Canvas
CSS Rhythmic Sizing で Vertical Rhythm | blog.jxck.io
Intro タイポグラフィに関連したデザイン手法の 1 つに Vertical Rhythm がある。 そして、現在 CSS でそれを簡単に実現するための CSS Rhythmic Sizing という仕様が提案されている。 Chrome にフラグ付きで実装されたこの仕様を用いて、本サイトへの適用を行ったので、解説する。 CSS Rhythmic Sizing CSS Rhythmic Sizing 筆者はタイポグラフィやデザインには疎く、 Vertical Rhythm についてもよく知らなかった。 しかし、 Chrome でこの仕様を実装している Koji Ishii さんに API を紹介してもらい、色々学ぶ機会があった。 本仕様はまだブラウザ間でも合意が取りきれていない部分があるらしく、ユースケースやフィードバックを集めている段階とのことだったので、 トライアルとして、本サイトへの
.mjs とは何か、またはモジュールベース JS とエコシステムの今後 | blog.jxck.io
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
EventTarget の継承可能化による EventEmitter の代替 | blog.jxck.io
Intro 念願 だった EventTarget の constructible/subclassable が DOM の仕様にマージされた。 これにより、いわゆる EventEmitter のブラウザ移植が不要になることが期待される。 Allow constructing and subclassing EventTarget Update Chrome Canary 64 で実装が確認できたため、 DEMO を追加した。 EventTarget EventTarget には addEventListener, removeEventListener, dispatchEvent が定義されている。 これは、ブラウザが内部で生成する Event や、任意に生成された CustomEvent を発火/補足するために利用される。 callback = console.log.bind(con
ES Modules への橋渡しとしての nomodule 属性 | blog.jxck.io
Intro ブラウザにおける新機能の利用においては、非対応ブラウザの考慮も必要となる。 ES Modules の利用においても、いかに非対応ブラウザでフォールバックの手段を提供するかが課題となっていた。 今回は、 Modules の対応/非対応を切り分けるための仕様である nomodule 属性を解説する。 script type module classic script (module ではない JS) は、 <script> で指定すると、取得解析しそのまま実行される。 type は省略されることが多いが、その場合 text/javascript と解釈されている。 <script type=text/javascript src=bundle.js></script> 一方、 module script (module として実装された JS) は、 import/export の
Web Budget API と Web に導入されつつある Budget と Cost の概念 | blog.jxck.io
Intro PWA の普及により、バックグラウンド処理をいかに制限するかといった課題が生まれた。 その対策として、バックグラウンド処理における Budget と Cost の概念が提案され、それを扱う Budget API の策定が進んでいる。 基本概念と現時点での API 外観について解説する。 Update 提案されて以降長いことアップデートがなかったが、 Mozilla Standard Position をリクエストしたところ、仕様が消えていたことがわかった。 https://github.com/mozilla/standards-positions/issues/73#issuecomment-373681407 元のリポジトリに Issue で現状を問い合わせたところ、結局開発者からの支持が得られず、 Obsolete されたとのこと。 blink-dev では Intent
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、 Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、 Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、 Web における Breaking Change (Break the Web)、具体的には W
Web 標準化のフィードバックサイクルを円滑にする Origin Trials について | blog.jxck.io
Intro ブラウザに追加される新しい機能に対して、 Vender Prefix の代替となる Origin Trials の導入が徐々に始まっている。 今回は、これまでの Vender Prefix の問題点と、代替として提案された Origin Trials のデザインや導入方法などについて記す。 Avoid Breaking the Web Web が壊れることは、避けねばならない。 Web に関する、特にブラウザが実装するような機能については、その仕様や実装を変更することにより、既存の資産の挙動が壊れることがある。 これを Breaking the Web といい、プロトコルにしても API にしても、標準化団体やブラウザベンダなどは、これを避けることを念頭に置いて作業を行っている。(セキュリティ的な理由など、例外は多く有る。) 一方で、新しく提案される仕様はフィードバックを集めな
中級者向け Service Worker Tutorial | blog.jxck.io
Intro Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。 しかし、 Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。 そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。 なお、 Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。 思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。 TODO になっている動画は、そのうち撮って追加します。 List claim controllerchange updatefound
Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
Noto Sans の Web Font 対応とサブセットによる最適化 | blog.jxck.io
Intro このサイトのフォントに Web Font を適用することにした。 フォントには Google と Adobe が協同で開発した Noto Sans CJK JP を採用した。 また、このサイトでは使用しないだろう文字を削除したサブセットを作ることで、フォントサイズを最適化した。 フォントサイズの最適化 Noto font は、そもそも豆腐(フォントがなかった場合に代替表示される四角)が出ないように(No-豆腐)することをコンセプトにしているため、フォントの網羅率は非常に高い。 そのため Web Font として利用する場合は、全体だとサイズが大きすぎるため、言語毎に提供されるフォントセットの中から、必要なフォントのみを適用することになる。 本サイトでは、 ASCII 、記号、日本語のフォントを用いる。 しかし、特に網羅された漢字の中には、日常では使わない文字が多々ある。 加えて
Preload を用いたリソースプリローディングの最適化 | blog.jxck.io
Intro Preload を指定する <link rel=preload> の仕様が公開されており、現在 Chrome Canary に実装されている。 この仕様のモチベーションについて、 Chrome 開発者の Yoav Weiss 氏のブログも公開された。 今回は、この仕様の特徴と用途を解説し、本サイトへの適用について検討する。 W3C Preload Spec Intent to Ship: <link rel=preload> Preload: What Is It Good For? Preload Preload はリソースのローディングを最適化することを目的に策定された仕様である。 link 属性ファミリーで、最適化に用いられる値としては、以前書いた Resource Hints 系 と近いが、仕様としては別になっている。 また、既に HTTP2 においてこの仕様の一部が使
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
