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
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() などで行う
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 にする
Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
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
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 においてこの仕様の一部が使
Node v7 で入った WHATWG URL 実装について | blog.jxck.io
Intro Node v7.0.0 が公開され、今回のリリースで WHATWG URL の実装が Experimental として入った。 既に標準で含まれていた url module との違いや、 URL API などについて解説する。 WHATWG URL URL は非常によく使われる、 Web において重要なフォーマットの一つだ。 ものによっては一見シンプルに見えるかもしれないが、その仕様はそれなりに大きい。 しかし、これまで DOM/JS はこれをパースする専用の API を持っていなかったため、例えば <input type=text> に入力された URL 文字列のパースは、片手間な正規表現で行われることも少なくなかった。 同様に、動的生成されるクエリやハッシュなどを URL に含める場面でも、やはり文字列操作による構築が行われてきた。 片手間な正規表現や文字列処理が、 URL
Fetch での Stream を用いたプログレス取得とキャンセル | blog.jxck.io
Intro WHATWG が定義する Fetch API は、出たばかりの仕様では、途中でのキャンセルや、プログレスイベントの取得が含まれていなかった。 しかし、後の更新で fetch 結果の Response Body が WHATWG Stream API を実装することになったため、現在の仕様ではプログレスを取ることもキャンセルをすることも可能となっている。 今回は、こうした API のアップデートについて記す。 Update 最初の公開時には、以下のように書いていた。 「XHR ではできるが Fetch ではできない」ことが、仕様上は無くなったことを意味する。 しかし、現時点で仕様としてまだ出来ないことがあることが判明した。 Upload の Progress これに伴い、記事の一部を修正した。 Fetch 最新の Fetch の仕様は以下で確認できる。 Fetch Spec 仕様
Intersection Observer を用いた要素出現検出の最適化 | blog.jxck.io
Intro スクロールによる DOM 要素の出現などを効率よく検知するため、新しく Intersection Observer という API が追加された。 この API の使い方と、本サイトへの適用について記す。 要素交差(intersection)の検出 ページをスクロールしていく過程で、特定の DOM が画面に出現したことをフックしたいケースがある。 代表例は 画像の遅延読み込み であり、初期ロードでは画像の取得を行わずスクロールしていく過程で順次取得する手法である。 特に画像の多いページでは表示に必要なリソース取得のみに最適化でき、初期画面表示などでは効果が大きいとされる。 これを実装するのに必要なのは、「 <img> 要素が出現しているかどうか」であるが、本質的には「画面外にあった <img> が viewport と交差したか」を取得することになる。 つまり、 要素出現の取得
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
