次世代 Web カンファレンス 2019 開催告知 | blog.jxck.io
Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか?」と「これからどうなっていくのか?」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあっても良いのではないかと考えていました。 今回開催するカンファレンスは、この「議論」だけからなるものです、それ以外のことはしません。 この趣旨に賛同してくださった、各分野のプロフェッショナルに協力頂き、「次世代 Web カンファレンス」として、開催させていただくことになり
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
Clear-Site-Data Header | blog.jxck.io
Intro Clear-Site-Data Header の実装が進んでいる。 このヘッダについて解説する。 Clear-Site-Data 例えばログアウト処理を実施する場合は、レスポンスヘッダで Cookie を無効にするといった形で実現されるだろう。 しかし、最近では Cookie 以外にも多くのストレージがあり、アカウント特有のデータが保存されていることが多い。 local storage session storage indexed db service worker cache api これらを、ログアウト処理の中で各 API を適切に呼び出し、全て確実に削除するのは簡単ではない。 また、 httponly の Cookie や browser cache などは、 JS からの削除もできない。 SPA のように実装されている場合は、その状態を含めて初期化しないと不整合が発生
ResizeObserver による変更検知と Element Query | blog.jxck.io
Intro ResizeObserver の ship が進みつつある。 この仕様の解説および、 ElementQuery / ContainerQuery について解説する。 Resize Observer 1 ResizeObserver ResizeObserver は、最近増えつつある ObserverFamily の 1 つであり、要素のリサイズを検知するインタフェースである。 リサイズを検知したい要素をターゲットに observe() すると、ターゲットと矩形情報が取得できる。 const resizeObserver = new ResizeObserver((entries) => { entries.forEach(({target, contentRect}) => { console.log(target) const {x, y, width, height, to
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
.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 を読
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
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
Google Developer Experts (GDE) になりました | blog.jxck.io
Intro Google の中の人からお声がけ頂き、 Google Developer Experts (GDE) に Web Technologies の Expert として Join することになりました。 GDE GDE は、簡単に言えば Google の技術についての啓蒙などを行う、社外アドボケート的な位置づけである。 https://developers.google.com/experts/ 各自専門領域(Android, GCP etc)があるが、自分はやはり Web Technologies ということになる。 Web に関する多くが標準技術であるため、 Google Developer Experts という名だが、別に Google や Chrome に限った内容を扱うわけではない。 活動 実際に何をするかというと、特に明確なタスクを詰まれるといったわけではないとのこ
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
Intersection Observer を用いた要素出現検出の最適化 | blog.jxck.io
Intro スクロールによる DOM 要素の出現などを効率よく検知するため、新しく Intersection Observer という API が追加された。 この API の使い方と、本サイトへの適用について記す。 要素交差(intersection)の検出 ページをスクロールしていく過程で、特定の DOM が画面に出現したことをフックしたいケースがある。 代表例は 画像の遅延読み込み であり、初期ロードでは画像の取得を行わずスクロールしていく過程で順次取得する手法である。 特に画像の多いページでは表示に必要なリソース取得のみに最適化でき、初期画面表示などでは効果が大きいとされる。 これを実装するのに必要なのは、「 <img> 要素が出現しているかどうか」であるが、本質的には「画面外にあった <img> が viewport と交差したか」を取得することになる。 つまり、 要素出現の取得
AMP HTML 対応 | blog.jxck.io
Intro Google が推奨する仕様である AMP HTML に、このブログを対応した。 言いたいことは色々あるが、とりあえず非常に難しかったため、その対応方法や感想などを残す。 Update 以下の記事が出たので、古かったフォーマットのアップデートと JSON-LD によるメタデータの提供 に対応した。 Google モバイル検索が Accelerated Mobile Pages に対応しました AMP 対応 2016.02 版 Accelerated Mobile Pages ACCELERATED MOBILE PAGES PROJECT タイトルは識別しやすいよう AMP HTML としたが、実際には AMP という仕様(方針)があり、 HTML 以外にも手を入れている。 AMP は、特にモバイル向けに 静的コンテンツ を最適化し、表示を高速化することを目的としている。 実際
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 つ(もしくは少数個)に結合する最適化が主流だ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
