Structured Field Values による Header Field の構造化 | blog.jxck.io
Token が文字列とは別に定義されているため、実装する言語によっては設計に悩む(JS 実装では Symbol を使っている)。 Parameter Parameter は Item に付与できるメタデータだ。 例えば以下は String の "abc" に対してパラメータを 2 つ付与している。 // "abc";a=1;b=2 { "value": "abc", "params": { "a": 1, "b": 2 } } データ表現には基本的に Key/Value/Metadata の 3 つがあることが望ましい。 例えば XML/HTML のようなフォーマットは Attribute がメタデータを担うが、これを再現可能になる。 <p id="foo" class="bar">hello</p> // p="hello world";id="foo";class="bar" { "p
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された 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 を読
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Scroll To Text Fragment と :~:text | blog.jxck.io
Intro ページ内の特定の位置へのスクロールは、 URL フラグメントと HTML の ID 属性を用いて行われていた。 しかし、 ID を持たない要素へのスクロールというユースケースをカバーするために、フラグメントの拡張仕様が提案されている。 Chrome がフラグ付きで実装しているため、この仕様の特徴について解説する。 id 属性とフラグメント 従来の仕様では、 HTML 内にある ID 属性を URL フラグメントに付与することで、その要素まで自動でスクロールするという仕様になっていた。 https://html.spec.whatwg.org/multipage/browsing-the-web.html#try-to-scroll-to-the-fragment https://html.spec.whatwg.org/multipage/browsing-the-web.ht
Scroll to Text Fragment を用いたサイト内検索の実装 | blog.jxck.io
Intro Scroll to Text Fragment のユースケースとして、本サイトにサイト内検索を実装した。 Scroll to Text Fragment Scroll to Text Fragment(以下 S2TF) は Chrome 80 で Ship され、 Finch で展開されている。 まだ降りてきてない場合は、 Flag による有効化が必要だ。 詳細は以前このブログでも書いている。 Scroll To Text Fragment と :~:text | blog.jxck.io この機能の使い道の一つとして、検索結果の Deep Link への適用があると考え、 PoC として実装した。 検索結果への適用 このサイトを CSP というキーワードで検索した場合を考える。 検索対象は、記事の本文とすると、例えば以下の一文がヒットする。 Feature Policy のモ
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
Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
次世代 Web カンファレンス 2019 開催告知 | blog.jxck.io
Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか?」と「これからどうなっていくのか?」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあっても良いのではないかと考えていました。 今回開催するカンファレンスは、この「議論」だけからなるものです、それ以外のことはしません。 この趣旨に賛同してくださった、各分野のプロフェッショナルに協力頂き、「次世代 Web カンファレンス」として、開催させていただくことになり
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
Foreign Fetch が削除されそうな理由と Cookie の double keying | blog.jxck.io
Intro 以前、本ブログでも紹介した Foreign Fetch が、仕様から削除される方向で進んでいる。 Foreign Fetch による Micro Service Workers | blog.jxck.io これは、 Safari などが進めている Cookie の double keying が影響しているらしいので、現状についてまとめる。 Foreign Fetch Foreign Fetch は、簡単に言えば 3rd Party Origin の Service Worker が、その Origin に向けた Fetch をハンドルできるようにするという仕様である。 これによって、 Origin 単位での Service Worker の責務が分離できるため、以下のような設計が期待できた。 サブドメインごとに SW の責務を分離でき、更新などのライフライクルを変えられる
Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
Intersection Observer を用いた要素出現検出の最適化 | blog.jxck.io
Intro スクロールによる DOM 要素の出現などを効率よく検知するため、新しく Intersection Observer という API が追加された。 この API の使い方と、本サイトへの適用について記す。 要素交差(intersection)の検出 ページをスクロールしていく過程で、特定の DOM が画面に出現したことをフックしたいケースがある。 代表例は 画像の遅延読み込み であり、初期ロードでは画像の取得を行わずスクロールしていく過程で順次取得する手法である。 特に画像の多いページでは表示に必要なリソース取得のみに最適化でき、初期画面表示などでは効果が大きいとされる。 これを実装するのに必要なのは、「 <img> 要素が出現しているかどうか」であるが、本質的には「画面外にあった <img> が viewport と交差したか」を取得することになる。 つまり、 要素出現の取得
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
Passive Event Listeners によるスクロールの改善 | blog.jxck.io
Intro DOM のイベントリスナの仕様に Passive Event Listeners というオプションが追加された。 このオプションは、主にモバイルなどでのスクロールの詰まり(Scroll Junk) を解決するために導入されたものである。 今回は、この仕様が解決する問題と、本サイトへの適用を解説する。 Passive Event Listeners Spec Scroll Event の PreventDefault() 画面のスクロールに合わせたインタラクションを実装する場合、 Scroll Event にイベントリスナを登録する。 典型的な例では touchstart や touchend をフックし、その中で DOM の操作などを実施するなどがある。 場合によってはイベントリスナ内で preventDefault() を呼ぶことで、スクロールそのものを止めることもできる。
リンクのへの rel=noopener 付与による Tabnabbing 対策 | blog.jxck.io
なお IE は(security zone setting をいじらない限り)この問題が発生しないようだ。 引用元: blankshield demo | Reverse tabnabber phishing tabnabbing 上記の挙動を、フィッシング詐欺に利用できることが既に指摘されている。 この手法は Tabnabbing と呼ばれている。 Tabnabbing: A New Type of Phishing Attack Aza on Design Target="_blank" - the most underestimated vulnerability ever この攻撃方法を解説する。 攻撃の概要 https://cgm.example.com (左上) というサービスがあるとし、これは SNS やチームコラボレーション系サービスを想定する。 攻撃者は、このサービスの不
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 にしても、標準化団体やブラウザベンダなどは、これを避けることを念頭に置いて作業を行っている。(セキュリティ的な理由など、例外は多く有る。) 一方で、新しく提案される仕様はフィードバックを集めな
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
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
中級者向け Service Worker Tutorial | blog.jxck.io
Intro Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。 しかし、 Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。 そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。 なお、 Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。 思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。 TODO になっている動画は、そのうち撮って追加します。 List claim controllerchange updatefound
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
