Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
Puppeteer で静的サイトの Font Subsetting | blog.jxck.io
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 両
img の srcset 指定時に選択される画像 | blog.jxck.io
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
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Site Isolation 及び Web のセキュリティモデルの更新 | blog.jxck.io
Intro Origin は Web におけるセキュリティモデルの一つとして、コンテンツ間の Communication に関する境界を定義し、リソースを保護してきた。 しかし、 Spectre の発覚以降、 Communication に関する制限だけではなく Isolation によるメモリレベルでのアクセス制御が必要となった。 そこで現在作業されているのが、 CORB, CORP, COEP, COOP といった仕様群であり、これは Web におけるセキュリティモデルの更新作業と見ることができる。 概要と現状について解説する。 DEMO & Resources 量が多いため、動作する DEMO と関連リソースは、ページ下部にまとめてある。 CORS による Cross Origin Communication の制限 CORS は、平たく言えば、リソース提供元(サーバ)が、クライアン
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
mozaic.fm v3 リリースと Podcast の PWA 化 | blog.jxck.io
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
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() などで行う
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
3rd Party Cookie 調査のための Web 広告導入 | blog.jxck.io
Intro 昨今、特に広告サービスを中心に 3rd Party Cookie を用いたトラッキングについての議論が多く行われている。 Safari による ITP や、 Chrome による Privacy Sandbox への移行など、技術的な変化も著しい。 こうした技術の変遷を観測し、調査検証を行うために、これまで避けていた Web 広告を本サイトに導入することにした。 Motivation 本サイトは、様々な Web に関する技術を調査し、実際に試すためにサイト自体に適用しながらそれを記事にまとめるという目的で運用してきた。 様々な技術を試したり、そのパフォーマンスやセキュリティへの影響を評価する上で、一般的なサイトの構成とかけ離れていれば、あまり意味をなさない。 そのため、本サイトでは以下のように、別に必要はない機能やサービスをあえて導入している。 AMP AMP より Origi
ブラウザで何が起こっているのかを知る Reporting API と ReportingObserver | blog.jxck.io
Intro Web サービスにおいては通常、 Web サーバから取得できるアクセスログやエラーログを取得し解析する基盤を保有するだろう。 しかし、 Web サーバから取得できる情報だけでは、ブラウザで何が起こったのかを知るのは限界がある。 今回は、ブラウザ内で起こったことを知るための Reporting API と、その Report の収集について解説する。 Notice 本記事の大半は 1 年以上前に書いたものだが、そのころは仕様も実装もまだまだ落ち着きが無かった。 仕様 report-uri から report-to への移行期 JFV の採用への不安 実装 ディレクティブの実装がバラバラ ReportingObserver では取れるが default group に自動では飛ばない(未実装) ReportingObserver で取った report が JSON Seriali
WebTransport と WebCodecs そして Web はどこまで "ゲーム化" するか | blog.jxck.io
Alternatives 結局 WebSocket が TCP に縛られていなければ良いのではという点に注目すると、 WebSocket over HTTP/3 が実現できれば HoLB などの問題は解決しそうだ。 しかし、仮にそこに複数のストリームを束ねようとしても、 WS の特徴上ストリームごとに 1RTT のハンドシェイクが必要となる。また、サーバから Stream を開始することができない(本当にそれが必要なのかは疑問だが)という問題があげられている。 また、 WebRTC の文脈で進んでいる RTCQuicTransport が、非常にというかあるケースではほぼ同じことを提供することになる点が指摘される。(策定者も同じ) これもやはり、 WebRTC が P2P 前提の仕様でスタートした点と Client-Server ユースケースとの乖離をベースに説明されており、すでに RTC
Nullish Coalescing と Optional Chaining | blog.jxck.io
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 な値の場合も上書きさ
Web における技術の解釈とエコシステムによる合意形成プロセスについて | blog.jxck.io
Intro 「ユーザが意図する挙動」とは何か。技術的に可能であるが「やらない方が良いこと」は、誰がどう決めるのか。 Web には仕様、実装、デプロイ、そしてユーザの利用とフィードバックによって、そうした合意がゆるやかに形成されていく仕組みがあると筆者は考えている。 しかし、これは明文化されているわけでもなく、その全体像を把握するのは一般には難しいだろう。 今回は、ちょうど何度目かの議論が再発している ping 属性を例に、この合意形成の概観について解説を試みる。 リンクの ping 属性 <a> には ping という属性があり、以下のように URL を指定する。 <a href=https:example.com ping=/path/to/report>example.com</a> HTML Standard - ping Attribute このリンクは、クリックすると https
Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io
Intro ECMAScript の Private Class Field の仕様策定と各ブラウザの実装が進んでいる。 これにより、従来の JS にはなかった Class の Private フィールドが使えるようになる。 提案されている構文や、挙動について解説する。 Class Field Declaration まず前提として、現状の Class の フィールドはコンストラクタで定義する必要がある。 例えば count フィールドを持つ Counter クラスを定義した場合、以下のようになる。 class Counter { constructor() { this.count = 0 } increment() { this.count ++ } display() { console.log(this.count) } } const c = new Counter() c.in
.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 を読
安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scri
Font Display プロパティを用いた FOIT/FOUT 最適化 | blog.jxck.io
Update この検証から 2 年程のちに、 First Paint/First Contentful Paint を重視するため、全ての display プロパティは swap に統一した。 その他 WebFont に関連する検証は web font タグにまとまっている。 Intro Web Font 読み込み中の HTML 表示については、ブラウザデフォルトの挙動に依存していた。 フォントファイルサイズが大きい場合は、 FOIT/FOUT の問題が顕著になり、 JS を用いた回避策が利用されることも多かった。 これを解決するため、 CSS に font-display プロパティが作成され、実装が進んでいる。 各プロパティの違いと挙動、そして本サイトへの適用について解説する。 Loading Web Font Web Font は、特に日本語のように文字数が多い場合、ファイルが大きく
次世代 Web カンファレンス 2019 開催告知 | blog.jxck.io
Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか?」と「これからどうなっていくのか?」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあっても良いのではないかと考えていました。 今回開催するカンファレンスは、この「議論」だけからなるものです、それ以外のことはしません。 この趣旨に賛同してくださった、各分野のプロフェッショナルに協力頂き、「次世代 Web カンファレンス」として、開催させていただくことになり
Intersection Observer を用いた要素出現検出の最適化 | blog.jxck.io
Intro スクロールによる DOM 要素の出現などを効率よく検知するため、新しく Intersection Observer という API が追加された。 この API の使い方と、本サイトへの適用について記す。 要素交差(intersection)の検出 ページをスクロールしていく過程で、特定の DOM が画面に出現したことをフックしたいケースがある。 代表例は 画像の遅延読み込み であり、初期ロードでは画像の取得を行わずスクロールしていく過程で順次取得する手法である。 特に画像の多いページでは表示に必要なリソース取得のみに最適化でき、初期画面表示などでは効果が大きいとされる。 これを実装するのに必要なのは、「 <img> 要素が出現しているかどうか」であるが、本質的には「画面外にあった <img> が viewport と交差したか」を取得することになる。 つまり、 要素出現の取得
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
