画像最適化戦略 Lazy Loading 編 | blog.jxck.io
Intro 長らく議論されてきた <img> や <iframe> における Lazyload について、仕様と実装が動きを見せている。 ここでは、特に画像 <img> に注目し、 Lazyloading の議論の変遷を踏まえた上で現状を解説する。 画像最適化シリーズ第 5 回目のエントリである。 画像最適化戦略 PNG/JPEG 編 画像最適化戦略 Picture 編 画像最適化戦略 WebP 編 画像最適化戦略 SVG/Font 編 > 画像最適化戦略 Lazy Loading 編 Lazyloading 画像や iframe の埋め込みは、読み込むサイズも大きく、処理が同期であるため、レンダリングのボトルネックになりやすく、それらが多いページでは初期表示の遅延の原因となることが多くあった。 特に縦に長いページでは、最初にユーザが見えている領域 (Above the Fold) では表
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
安全な文字列であると型で検証する 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
Cache Digest と HTTP2 Server Push の現状 | blog.jxck.io
Intro httpbis のチェアである mnot から、 Cache Digest についての現状確認が ML に投稿された。 もしこのまま反応がなければ、 Cache Digest は終わり、対ブラウザキャッシュの Server Push は現実的ではなくなる。 Update mozilla standard position に RFP を上げたところ「実装はしないが仕様については non-harmful」となりそうだ。 PFP: Cache Digest Issue #131 mozilla/standards-positions HTTP2 Push HTTP2 の仕様策定時に盛り込まれた新機能として、 Server Push があった。 これは、例えば RPC 的な用途で双方向性のある通信を可能にした。 Web においては、リクエストが来る前にレスポンスを返しキャッシュに入れ
prefers-color-scheme を用いた Dark Mode 対応と User Preference Media Features | blog.jxck.io
Intro macOS Mojava は OS レベルで Dark Mode に対応した。 しかし、 Web コンテンツは依然として白背景黒文字ベースのデザインが多く、結果ブラウザの中だけ眩しいという問題がある。 Safari TP69 では、これにメディアクエリで対応するための prefers-color-scheme が実装された。 これを用いた DarkMode 対応と、本ブログの DarkMode 対応、および策定中の User Preference Media Features について解説する。 Update 画像の対応について追記した Code Block の対応について追記した 2019/1 に Chrome の Intents が出された。 Intent to Implement: Media Queries: prefers-color-scheme feature I
Monthly Web の作り方 2018 年版 | blog.jxck.io
Intro 筆者がやっている Podcast である mozaic.fm の中で、 Monthly Web という月ごとの Web の動向をまとめる回をやっている。 未だに落ち着いたとはいえないが、 2017 年 7 月に初めてから 1 年続けたので、結果として現状どうなっているかをログに残す。 Monthly Web mozaic.fm は、 Web について「今何が起こっているのか」「これからどうなっていくのか」を議論するための Podcast である。 そこでは、ゲストをお呼びし、特定のテーマについて議論をするということを行ってきた。 しかし、このテーマの設定と消化よりもよほど早い勢いで、多くの重大なトピックが日々生まれており、その大局的な流れを扱うことはできないかずっと考えていた。 通常回が「縦を深く掘る」議論であるとすれば、「横の流れを繋ぐ」部分の議論を行うことができれば、議論す
Element.toggleAttribute | blog.jxck.io
Intro 非常にシンプルかつミッシングピースだった Element.toggleAttribute という仕様が提案された。 最近になって各ブラウザが一斉に実装を進め、リリースに向けたアナウンスが出始めている。 この仕様について解説する。 Boolean Attributes Boolean Attribute とは、属性の存在によって真偽となる属性である。 https://html.spec.whatwg.org/#boolean-attribute 例えば button の disabled を例にとるとこうなる。 button を disabled にする場合は、仕様上は以下の 3 つの書き方がある。 <!-- 属性のみを書く --> <button id=target disabled>toggle target</button> <!-- 値を empty string にする
Web Authentication API で FIDO U2F(YubiKey) 認証 | blog.jxck.io
Intro Web Authentication(WebAuthN) API の策定と実装が進んでいる。 これを用いると、 FIDO(Fast IDentity Online) U2F(Universal Second Factor) 認証が可能になる。 今回は YubiKey 認証の実装を通じて、ブラウザ API の呼び出しと、サーバ側で必要な処理について解説する。 https://w3c.github.io/webauthn/ DEMO 動作するデモを以下に用意した。 https://labs.jxck.io/webauthentication/fido-u2f/ YubiKey での動作のみ確認している。 コードは以下にあり、今回の解説もここから抜粋している。 (あくまで API の流れを解説するためのものであるため、飛ばした処理もあり、本番利用に耐えうるものではない。) https
Layered APIs と High Level API の標準化指針 | blog.jxck.io
Intro Extensible Web Manifest 以降、標準化作業は Low Level API にフォーカスし、一定の成果が出ている。 そこで、これらをベースとし、よりアプリレイヤの需要を満たすための High Level API をどう標準化するか、という点について指針が提案された。 基本は、 Low Level API を元に Polyfill を作り、そこからのフィードバックにより策定を進めるという方針だ。 合わせて ES Modules の Import を用いて、 polyfill とネイティブ実装をスムーズに切り替える拡張が提案されている。 本記事では Layered APIs (LAPIs) と呼ばれる、この一連の枠組みについて解説する。 また、同等の話を 東京 Node 学園 #tng30 で行った資料は以下である。 Web over Layered APIs
Safari による User-Agent 固定化と Web における Feature Detection | blog.jxck.io
Update 2018/3/1 : Safari 11.0.3 の UA を追記 2018/4/16: Safari 11.1 の UA を追記 2018/5/1 : OS のバージョンは固定されなくなった件を追記 2 月に方針が変更され、 OS のバージョンは固定されなくなった。 このため、 iOS のバージョンアップにより発生するバグなどを回避する道は残されたことになる。 一方 Webkit のバージョンは(予定では 605.1.15 に)固定されることになりそうだ。詳細は、以下を参照。 Safari の UA 文字列が固定されて固定されなくなったおはなし - fragmentary Intro 少し前に Safari Technology Preview 46 がリリースされた。 Service Worker のアナウンスに目がそちらに盗まれている一方、しれっと以下の一文がある。 F
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
ブラウザで適当なランダム文字列 | blog.jxck.io
Intro テストや仮実装で、適当なランダム文字列が欲しい場合に便利なスニペット。 random string DEMO // with random btoa(Math.random()) // => MC44NzEwODQwMjA1NDA2MTE4 // with crypto btoa(crypto.getRandomValues(new Uint8Array(16))) // => MjQ2LDE0NSwxNzAsMjQ0LDY4LDg3LDMzLDE0NiwxNzcsNjAsMTUyLDE3MSwxNTAsMTcsMTA4LDEwNA== // base64 has `=` remove them btoa(Math.random()).replace(/=/g, "") // => MC45NTM0NTM2OTY3MTc5MDY0 // lower case btoa(Math
.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 を読
Service Worker の Navigation Preload による表示遅延回避 | blog.jxck.io
Intro Service Worker で Fetch を Proxy する場合、 Fetch 発生時に SW が起動していなければ、その起動を待つ必要が出る。 そして、この SW の起動には無視できない時間がかかる場合があった。 これを改善する Navigation Preload について解説する。 SW Bootup SW が onfetch をハンドルし、キャッシュから Response を返す場合は、ネットワーク I/O をせずに画面をレンダリングできる。 しかし、 SW が onfetch をフックしていてもなお、実際にネットワークにリクエストを投げる場合は少なくない。 この場合、もしページのコントローラとなっている SW が起動していない場合は、 onfetch ハンドラを実行するために、 SW の起動を待つ必要が出てくる。 SW の起動には、もちろん実行環境によるところが
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
