blog.jxck.io
Jxck
tag:blog.jxck.io,2016:feed
2016-01-28T18:30:02Z
3PCA 30 日目: 2024 年の 3rd Party Cookie まとめ
tag:blog.jxck.io,2016:entry://2024-12-12
2024-12-12T00:00:00Z
このエントリは、2023 年の 3rd Party Cookie Advent Calendar の 30 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookieこのアドベントカレンダーを開始した 2023 年末の時点では、2024 年(つまり今年)の年始に Chrome による 1% Deprecate が始まり、2024 年をかけてその範囲を広げ、今頃は Post 3rd Party Cookie の世界が訪れている見通しだった。しかし、その予定は大きく変更され、これからどうなるのかも不透明だ。つまり、この話は 2025 年も継続することになってしまったため、2024 年の現状を一旦まとめておくこととする。
Dialog と Popover #12
tag:blog.jxck.io,2016:entry://2024-11-14
2024-11-14T00:00:00Z
Toast 相当を実装する場合、時間が経ったら自動で消えるタイムアウトを設定することがないだろうか?今回 Popover の一連を調べる中であった、これが WCAG 違反だという議論を紹介する。
Dialog と Popover #11
tag:blog.jxck.io,2016:entry://2024-11-01
2024-11-01T00:00:00Z
今回考えたいのは、GitHub の Issue や User アイコンをマウスでホバーすると、Issue の詳細や User Profile が表示されるアレだ。挙動としては想像通り、対象要素に Anchoring した <div popover> を表示し、中に好きなようにコンテンツを入れれば良い。ただし、UI のセマンティクスに関しては、複数の議論が行われており、方針もいくつか考えられる。今回は、それらの現状を整理しつつ、考えうる選択肢をいくつか提示する。その中で要件に合わせて何を選ぶかは実装者に委ねたい。
Dialog と Popover #10
tag:blog.jxck.io,2016:entry://2024-10-22
2024-10-22T00:00:00Z
ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意
Dialog と Popover #9
tag:blog.jxck.io,2016:entry://2024-10-16
2024-10-16T00:00:00Z
ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意
Dialog と Popover #8
tag:blog.jxck.io,2016:entry://2024-10-11
2024-10-11T00:00:00Z
ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意
Dialog と Popover #7
tag:blog.jxck.io,2016:entry://2024-10-10
2024-10-10T00:00:00Z
ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意
Dialog と Popover #6
tag:blog.jxck.io,2016:entry://2024-10-03
2024-10-03T00:00:00Z
ついに <toast> -> <popup> -> popup -> popover として、要素から属性になり名前も決まった。とはいえ実装は popup とそんなに変わらないので、popup でやっていた Origin Trials を継続しながら、徐々に実装を進めていくフェーズが 2022/12 くらいの話だ。Intent to extend Origin Trial: Popover APIhttps://groups.google.com/a/chromium.org/g/blink-dev/c/kZXexHhH7EA/m/UmQYwGW3DAAJしかし、popover を実用するには足りていない議論があった。それが Animation だ。
Dialog と Popover #5
tag:blog.jxck.io,2016:entry://2024-10-02
2024-10-02T00:00:00Z
このあたりから、まだ議論中の話が多いため、今後変わる可能性が高い点に注意。popup が紆余曲折を経て popover 属性になり、2023/3 に Safari が TP166 で実装した。そのまま Safari 17 に入ることを 2023/6 の WWDC で発表したあたりから、popover の実装は各ブラウザで一気に話が進む。Release Notes for Safari Technology Preview 166https://webkit.org/blog/13964/release-notes-for-safari-technology-preview-166/News from WWDC23: WebKit Features in Safari 17 betahttps://webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/そして、2024/4 ごろに発表された Baseline 2024 に popover がエントリしたことで、2024 年は全ブラウザで互換性を高めていくことに合意し、作業を進めていくことになる。俗に言う「元年」というやつと言えるだろう。Popover API lands in Baselinehttps://web.dev/blog/popover-api今回は、この popover の議論と、仕様が完成していくまでをまとめる。
Dialog と Popover #4
tag:blog.jxck.io,2016:entry://2024-09-30
2024-09-30T00:00:00Z
ここまでで <dialog> 要素が標準化され、Modal/non-Modal な Dialog がネイティブで出せるようになった。今まで自前で実装していた z-index の指定や、フォーカスの管理、非活性化、キーボードでの処理、スタイルなども、細かい仕様がほぼ標準によってカバーされた。Top Layerinert:modal / ::backdropCloseWatcherFocusable Scrollersetcしかし、<dialog> はあくまで「ユーザのインタラクションを求める」という用途で使うものであり、role=dialog ではない、例えばちょっとしたメッセージの通知などに使うものではない。そこで、これらの資産を活用し、より汎用的な UI を標準化しようという話が、<dialog> の標準化の裏で並行して行われた。
Dialog と Popover #3
tag:blog.jxck.io,2016:entry://2024-09-27
2024-09-27T00:00:00Z
前回までは <dialog> が標準化されるまでの経緯と、API の概要や関連仕様を解説した。今回は <dialog> の API としての使い方について、具体的に解説していく。
Dialog と Popover #2
tag:blog.jxck.io,2016:entry://2024-09-26
2024-09-26T00:00:00Z
showModalDialog() は今から考えれば、確かにひどい API だった。しかし、何か Modal を開き、ユーザにインタラクションをさせ、閉じたらそこで入力された値や選択された結果を取得し、処理を進めたいユースケース自体は、規約への同意取得や、Cookie バナー、ログインなど多々ある。そういった場面では、ライブラリなどを用いて実装する必要があったが、Modal を実装するのは実際にはそんなに簡単ではなかった。
Dialog と Popover #1
tag:blog.jxck.io,2016:entry://2024-09-25
2024-09-25T00:00:00Z
HTML の <dialog> 要素と、popover 属性、および関連する様々な仕様が標準化され、実装が進められている。Open UI を中心に進められているこれらの改善は、多くのサイトで共通したユースケースがありながら、長らくミッシングピースとなっていた重要な機能だ。もし今、同等のユースケースを自前で実装しているのであれば、適切な仕様を用いた実装に刷新することで、従来はほぼ不可能だった UX を提供できるようになる。今回から、数回の連載形式で、これらの仕様がどのように標準化され、我々開発者はこれをどのように使っていくべきなのかについて解説する。
Web Developer Conference 2024 開催後記 #wdc2024
tag:blog.jxck.io,2016:entry://2024-09-09
2024-09-09T00:00:00Z
2024/9/7 に、Web Developer Conference を開催した。Web Developer Conference 2024 開催告知 #wdc2024 | blog.jxck.iohttps://blog.jxck.io/entries/2024-06-12/web-dev-conf-2024.htmlConnpasshttps://web-study.connpass.com/event/321711/Togetterhttps://togetter.com/li/2430964
3PCA 29 日目: Privacy Sandbox の方針転換は何を意味するか
tag:blog.jxck.io,2016:entry://2024-07-31
2024-07-31T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 29 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie先日、Google より Privacy Sandbox の方針転換について発表があった。本当は、まだ記事を書くには情報が足りていないため、あまり書く気はなかったが、今後出てくる発表に備えて経緯をまとめるために、「何がまだ分かっていないか」の現状を書いておくことにする。
なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待
tag:blog.jxck.io,2016:entry://2024-07-05
2024-07-05T00:00:00Z
Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。Ladybirdhttps://ladybird.org/これがいかに価値のある取り組みなのか、Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。
「1 分 de Web 標準」のやり方 at Web Developer Conference 2024 #wdc2024
tag:blog.jxck.io,2016:entry://2024-06-26
2024-06-26T00:00:00Z
9/7 開催予定の Web Developer Conference 2024 では、「1 分 de Web 標準」という LT 大会を予定しています。CFP も募集中ですが、(筆者の周り以外では)聞き馴染みのないやり方だと思うので、この LT のやり方を解説します。プロポーザル | Web Developer Conference 2024 - fortee.jphttps://fortee.jp/web-dev-conf-2024/proposal/all
URL.parse を Chromium で Ship するまで
tag:blog.jxck.io,2016:entry://2024-06-14
2024-06-14T00:00:00Z
Chrome 126 で筆者が実装した URL.parse が Ship された。Chromium にコントリビュートしたことは何回かあったが、単体機能を Ship したのは初めてだった。
Web Developer Conference 2024 開催告知 #wdc2024
tag:blog.jxck.io,2016:entry://2024-06-12
2024-06-12T00:00:00Z
夏に Web 開発周りの話をするカンファレンスをやります。参加は Connpass で募集しています。Web Developer Conference 2024 - connpasshttps://web-study.connpass.com/event/321711/Session と LT の募集を fortee で今日から開始したので応募を待ってます。Web Developer Conference 2024 - fortee.jphttps://fortee.jp/web-dev-conf-2024
Reverse HTTP Transport が描く新しい Web サービスデプロイ構成
tag:blog.jxck.io,2016:entry://2024-05-10
2024-05-10T00:00:00Z
IETF の httpbis で、Reverse HTTP Transport という仕様が提案されている。Reverse HTTP Transporthttps://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.htmlこの仕様は、Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。
Referrer-Policy の制限を強めると安全になるという誤解
tag:blog.jxck.io,2016:entry://2024-05-07
2024-05-07T00:00:00Z
Referrer-Policy は、送信される Referer の値を制御することが可能だ。このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか?前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.iohttps://blog.jxck.io/entries/2024-04-26/csrf.html
令和時代の API 実装のベースプラクティスと CSRF 対策
tag:blog.jxck.io,2016:entry://2024-04-26
2024-04-26T00:00:00Z
CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。
RFC の URL はどのドメインで貼るのが良いか
tag:blog.jxck.io,2016:entry://2024-03-27
2024-03-27T00:00:00Z
IETF の RFC は、いくつかの場所で同じものが公開されている。どの URL が最適なのか、という話。結論は www.rfc-editor.org だ。
Chromium にコントリビュートするための周辺知識
tag:blog.jxck.io,2016:entry://2024-03-26
2024-03-26T00:00:00Z
Chromium にコントリビュートするためには、ソースコードを理解する以外にも、もろもろ必要な周辺知識がある。ドキュメントはかなり整備されている方ではあるが、そのドキュメントにたどり着くのが難しい場合もある。レビュアーなどが親切に教えてくれるものをローカルにメモしているが、それも散らばってきたため、ここにまとめることにする。まずは初期状態で公開するが、どんどん更新していき、長くなっても分割しないで追記を繰り返そうと考えている。
mozaic.fm 10 周年記念イベント開催後記
tag:blog.jxck.io,2016:entry://2024-03-13
2024-03-13T00:00:00Z
2014 年 3 月に開始した mozaic.fm が、気づいたら 10 周年を迎えた。これを機に、10 周年記念イベントとして、初のオフラインイベントをゲンロンカフェで開催した。Podcast でのみ告知し、当日まで情報制限をかけていたにもかかわらず、チケットもグッズも無事完売することができた。イベントを振り返りつつログを残す。
Promise.withResolvers によるイベントの Promise 化
tag:blog.jxck.io,2016:entry://2024-02-10
2024-02-10T00:00:00Z
Promise.withResolvers() は、Stage 4 であり ES2024 の候補となった。すでにブラウザでの実装も進んでいるため、その活用方法を解説する。
TC39 に新設された Stage 2.7 について
tag:blog.jxck.io,2016:entry://2024-02-06
2024-02-06T00:00:00Z
TC39 の Stage 2 と Stage 3 の間に、新たに Stage 2.7 が追加された。これは何だろうと思った人が検索で辿り着けるよう、その経緯と目的をまとめる。
Apple によるブラウザエンジン規制の緩和
tag:blog.jxck.io,2016:entry://2024-01-28
2024-01-28T00:00:00Z
以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。Apple announces changes to iOS, Safari, and the App Store in the European Union - Applehttps://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。筆者が公開情報を読んで解釈したものなので、内容は保証しない。
Web 技術年末試験 2023 講評 #web_exam2023
tag:blog.jxck.io,2016:entry://2024-01-23
2024-01-23T00:00:00Z
2023 年の Web 技術を振り返る試験として、「Web 技術年末試験 2023」を実施した。その問題と想定解答、平均点などを公開する。
2023 年を振り返る
tag:blog.jxck.io,2016:entry://2023-12-31
2023-12-31T00:00:00Z
例年通り 2023 年を振り返る。
3PCA 最終日: 3rd Party Cookie 亡き後の Web はどうなるか?
tag:blog.jxck.io,2016:entry://2023-12-30
2023-12-30T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の最終日である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookieここまで、3rd Party Cookie との 30 年にわたる戦いと、ITP 以降それが Deprecation されるに至った流れ、そして Privacy Sandbox の API について解説してきた。最終日は、ここまでを踏まえて、来年以降の Web がどうなっていくのかを考えていく。
3PCA 27 日目: FedCM
tag:blog.jxck.io,2016:entry://2023-12-29
2023-12-29T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 27 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は、散々壊れるユースケースとして解説してきた「認証連携」をカバーする FedCM について解説する。
3PCA 26 日目: Related Website Sets
tag:blog.jxck.io,2016:entry://2023-12-28
2023-12-28T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 26 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日からは、Privacy Sandbox の「広告」以外の API を解説していく。
3PCA 25 日目: Measurement
tag:blog.jxck.io,2016:entry://2023-12-27
2023-12-27T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 25 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は、広告の測定について解説する。
3PCA 24 日目: Retargeting
tag:blog.jxck.io,2016:entry://2023-12-26
2023-12-26T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 24 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日はリターゲティングをカバーする Protected Audience API について解説する。
3PCA 23 日目: Interest Based Advertising
tag:blog.jxck.io,2016:entry://2023-12-25
2023-12-25T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 23 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今回からは、Privacy Sandbox の API を、ジャンルごとに分けて概要を解説していく。個々の API は非常に複雑であり、また今後も細かい点が変わっていくだろう。どうせガッツリ使うのであれば、仕様を読む必要があるため、ここでは「何がしたいのか」「何ができるのか」に絞って解説する。
3PCA 22 日目: Privacy Sandbox
tag:blog.jxck.io,2016:entry://2023-12-24
2023-12-24T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 22 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日からいよいよ Privacy Sandbox の話に入っていく。
「議論だけ」のカンファレンスの作り方
tag:blog.jxck.io,2016:entry://2023-12-23
2023-12-23T00:00:00Z
「議論だけ」のカンファレンスを、長いこと開催してきた。個人的には好きなので、他にもあったらいいと思っているが、そういうカンファレンスは他に見ない。カンファレンス自体を、筆者のような個人が手弁当でやれるのは、もう最後かもしれないと今回ひしひしと感じたので、これまでどうやってきたのかを残しておくことにする。
次世代 Web カンファレンス 2023 開催後記
tag:blog.jxck.io,2016:entry://2023-12-22
2023-12-22T00:00:00Z
2023/12/16(土) に、以下で告知した「次世代 Web カンファレンス」を開催した。次世代 Web カンファレンス 2023 開催告知 | blog.jxck.iohttps://blog.jxck.io/entries/2023-11-16/next-web-conf-2023.html次世代 Web カンファレンス 2023 - connpasshttps://nextwebconf.connpass.com/event/300174/
3PCA 21 日目: SameSite Cookie
tag:blog.jxck.io,2016:entry://2023-12-21
2023-12-21T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 21 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookieGoogle が 3rd Party Cookie を Deprecate していく方針を発表してから、最初に始めたのが SameSite Lax by Default だった。これが何のために行われたのかを解説する。
3PCA 20 日目: 3rd Party Cookie Deprecation
tag:blog.jxck.io,2016:entry://2023-12-20
2023-12-20T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 20 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookieここまで ITP について見てきたが、これはあくまで Safari が独断で行っていたことだ。それに対して、他が追従するかどうかはブラウザ次第だっただろう。では、他のブラウザはどのような反応をしたか。この反応には、その時の情勢も鑑みる必要がある。
3PCA 19 日目: Super Cookie
tag:blog.jxck.io,2016:entry://2023-12-19
2023-12-19T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 19 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は Super Cookie の解説をする。迂回手段ゾーンとしては、最後に紹介する手法だ。
3PCA 18 日目: Cloaking
tag:blog.jxck.io,2016:entry://2023-12-18
2023-12-18T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 18 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は、ITP の迂回で注目された Cloaking について解説する。
3PCA 17 日目: Fingerprinting
tag:blog.jxck.io,2016:entry://2023-12-17
2023-12-17T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 17 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は、Cookie に頼らない Tracking 手段としての、Fingerprinting について解説する。
3PCA 16 日目: Bounce Tracking
tag:blog.jxck.io,2016:entry://2023-12-16
2023-12-16T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 16 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は 3rd Party Cookie の迂回としてトラッキングに用いられた、Bounce Tracking について解説する。
3PCA 15 日目: Work Around
tag:blog.jxck.io,2016:entry://2023-12-15
2023-12-15T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 15 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今回は ITP が始まったことで試行された、迂回方法について見ていく。
3PCA 14 日目: Partitioning
tag:blog.jxck.io,2016:entry://2023-12-14
2023-12-14T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 14 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今日は Safari, Firefox で導入され、その後 Chrome によって標準化されつつある、Partitioning という概念を解説する。
3PCA 13 日目: ITP
tag:blog.jxck.io,2016:entry://2023-12-13
2023-12-13T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 13 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie
3PCA 12 日目: 終わりの始まり
tag:blog.jxck.io,2016:entry://2023-12-12
2023-12-12T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 12 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie
3PCA 11 日目: Cookie Banner
tag:blog.jxck.io,2016:entry://2023-12-11
2023-12-11T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 11 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie前回は、各国で法律が整備されていった流れや、主な法律の特徴を解説した。しかし、法律はあくまで法律であり仕様ではないため、「どう実装するべきか」は各サービスに委ねられている(ガイドラインなどはあるが)。多くの場合、これを Web の実装に落とし込むと、いわゆる「Cookie バナー」相当になるわけだ。今回は、実世界でどのようなバナーが提供されているのかを見ていく。
3PCA 10 日目: なぜ Cookie には同意が必要なのか?
tag:blog.jxck.io,2016:entry://2023-12-10
2023-12-10T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 10 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今回は、この話をする上で避けては通れない、規制や法律について触れておく。しかし、筆者はあくまでエンジニアであり、この分野は専門外だ。内容については、素人が適当に書いており、信頼性は AI 以下だと思って読んでほしい。
3PCA 9 日目: DNT
tag:blog.jxck.io,2016:entry://2023-12-09
2023-12-09T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 9 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今回は、P3P の後に提案され、非常に似たコンセプトで、かつ最近まで使われていた DNT について解説する。
3PCA 8 日目: P3P
tag:blog.jxck.io,2016:entry://2023-12-08
2023-12-08T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 8 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie今回は、Cookie2 が失敗した後に、別のアプローチでこの課題に挑んだ P3P を解説する。
3PCA 7 日目: Cookie2
tag:blog.jxck.io,2016:entry://2023-12-07
2023-12-07T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 7 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookieここからは第二幕、人類と 3rd Party Cookie の闘いの歴史を見ていく。「歴史の話はいらない、早くコードを見せろ」と思っている読者の気持ちもわかるが、残念ながら背景がわかっていないとまともな闘いはできないだろう。
3PCA 6 日目: トラッキングの問題
tag:blog.jxck.io,2016:entry://2023-12-06
2023-12-06T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 6 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie前回は、3rd Party Cookie にはネガティブ/ポジティブを含め、さまざまなユースケースがあるという解説をした。では、なぜ 3rd Party Cookie は今「問題」になっているのだろうか?
3PCA 5 日目: 認証の連携
tag:blog.jxck.io,2016:entry://2023-12-05
2023-12-05T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 5 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie前回は、3rd Party Cookie を使った広告のリターゲティングの仕組みを解説した。「あの気持ち悪い広告の正体は 3rd Party Cookie だったのか」と思った人もいるかもしれない。そんな諸悪の根源である 3rd Party Cookie など「さっさと無効にしてしまえばいいのでは?」と思うかもしれないが、それは簡単なことではない。なぜなら、3rd Party Cookie のユースケースは、ネガティブなものだけではないからだ。その一例として、今回は認証連携のユースケースを解説する。
3PCA 4 日目: 3rd Party Cookie の正体
tag:blog.jxck.io,2016:entry://2023-12-04
2023-12-04T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 4 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie前回は「サブリソースにまで Cookie が送られて何が嬉しいのか」という話だった。今回はそのユースケースについて考えていく。
3PCA 3 日目: 自動で送られる Cookie
tag:blog.jxck.io,2016:entry://2023-12-03
2023-12-03T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 3 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie前回は「Cookie は 区別 と 識別 の用途があり、区別 だけのユースケースもある」という解説をした。今回も、もう少し Cookie の性質を振り返っていく。
3PCA 2 日目: Cookie による区別と識別
tag:blog.jxck.io,2016:entry://2023-12-02
2023-12-02T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 2 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie
3PCA 1 日目: 3rd Party Cookie Advent Calendar Agenda
tag:blog.jxck.io,2016:entry://2023-12-01
2023-12-01T00:00:00Z
このエントリは、3rd Party Cookie Advent Calendar の 1 日目である。3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiitahttps://qiita.com/advent-calendar/2023/3rd-party-cookie
なぜ HTML の form は PUT / DELETE をサポートしないのか?
tag:blog.jxck.io,2016:entry://2023-11-27
2023-11-27T00:00:00Z
10 年ほど前に同じことを調べたことがある。なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codeshttps://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。この問題についてあらためて記す。
次世代 Web カンファレンス 2023 開催告知
tag:blog.jxck.io,2016:entry://2023-11-16
2023-11-16T00:00:00Z
2023/12/16(土) に、3 回目となる「次世代 Web カンファレンス」を開催します。次世代 Web カンファレンス 2023 - connpass名称: 次世代 Web カンファレンス 2023日時: 2023/12/16(土) 11:00-20:00場所: サイボウズ参加費: 無料配信: なしアーカイブ: 未定懇親会: なし入場規制: ありハッシュタグ(全体): #nwc_all
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ
tag:blog.jxck.io,2016:entry://2023-11-05
2023-11-05T00:00:00Z
こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。
Cookie2 とは何か
tag:blog.jxck.io,2016:entry://2023-08-19
2023-08-19T00:00:00Z
タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。
Compression Dictionary Transport (Shared Brotli) によるコンテンツ圧縮の最適化
tag:blog.jxck.io,2016:entry://2023-07-29
2023-07-29T00:00:00Z
Chrome で Compression Dictionary Transport の Experiment が行われている。Intent to Experiment: Compression dictionary transport with Shared Brotlihttps://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72Eこの提案の仕様および本サイトへの適用について解説する。
Cookie Store API による document.cookie の改善
tag:blog.jxck.io,2016:entry://2023-06-18
2023-06-18T00:00:00Z
JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。
AbortSignal.any(), AbortSignal.timeout(), そして addEventListener() の Signal
tag:blog.jxck.io,2016:entry://2023-06-01
2023-06-01T00:00:00Z
最近 AbortSignal.any() が提案され、急速に実装が進んでいる。すでに定義されている AbortSignal.timeout() や addEventListener() への Signal なども含め、非同期処理の中断を実装する際の API はかなり整備されてきた。これら API のモチベーションと設計を中心にまとめる。
URL バーの表示の変遷
tag:blog.jxck.io,2016:entry://2023-05-28
2023-05-28T00:00:00Z
ついに URL バーから EV 証明書の組織表示が消されるアナウンスが、Chrome から発表された。思えば、URL バーの見た目も、だいぶ変わってきたように思う。URL バーの表示の変遷を一度まとめておく。
IETF RFC における ABNF と Parsing Algorithm の関係
tag:blog.jxck.io,2016:entry://2023-05-17
2023-05-17T00:00:00Z
HTTPBis では、RFC 8941: Structured Field Values (以下 SFV) の更新作業が行われている。RFC 8941: Structured Field Values for HTTPhttps://www.rfc-editor.org/rfc/rfc8941.html機能面では Date 型が追加されるという点が大きいが、個人的にはその裏で行われるもっと興味深い議論に注目したい。それは、「RFC における ABNF の立ち位置」に関するものだ。
技術書籍をシンタックスハイライトする話
tag:blog.jxck.io,2016:entry://2023-05-02
2023-05-02T00:00:00Z
「連載するけど、代わりにコードはハイライトさせてほしい」それが Web+DB Press 編集長に俺が出した条件だった。
OpenAI API を用いた文書校正(誤字脱字検出)
tag:blog.jxck.io,2016:entry://2023-03-24
2023-03-24T00:00:00Z
OpenAI の API を用いて、長年の課題だった文書校正を VSCode 上で実現するプラグインを修作したところ、思った以上の成果だった。
誇りを被った仕様の針に意図を通す
tag:blog.jxck.io,2016:entry://2023-02-28
2023-02-28T00:00:00Z
Interop 2022 の目覚ましい成果の一つとして :has() の存在がある。これまでの CSS の限界を突破する、革新的な仕様であり、多くの開発者が期待を寄せる機能の一つだろう。こうした仕様策定の裏には、必ずと言って良いほど互換性の問題がつきまとい、時にそれはそこまでの作業の蓄積を無に帰すレベルで影響を与える場合がある。一方それらは Web 開発者が使う時点では解決されており、基本的に気にされることはない。だからといって、気にする必要がないわけではない。ということを象徴する事件が、今回も裏で起こっていた。
次世代 CSS 仕様が与えるコンポーネント時代の Web への影響
tag:blog.jxck.io,2016:entry://2023-01-07
2023-01-07T00:00:00Z
SPA の隆盛で進化したフロントエンドライブラリによって生み出された「コンポーネント」という資産は、それを View 層の最小単位として扱うエコシステムにその重心をずらした。近年の Web 開発は、虫食いのテンプレートエンジンにデータをはめ込む方式から、デザインシステムにカタログされたコンポーネント群に、API から取得したステートを流し込み、それらを「いつ、どこで、どう」レンダリングするかという課題への最適解を、各位が模索するフェーズとなっている。コンポーネントを敷き詰めるコンテナ側の設計は、Flexbox および Grid の登場によるレイアウトの進化が手助けしたところも多いにある。しかし、「ページ」を前提に設計された CSS は、「コンポーネント」を前提にした設計に移行するうえで、ミッシングピースが多かった。現在、提案/実装が進んでいる CSS の新機能群には、この「コンポーネントベースの Web 開発」に大いに影響を与えるポテンシャルを持つものが多い。今回は、2023 年の予習として、それらの仕様を「開発スタイルに与えうる影響」の側面から俯瞰し妄想したものをメモに残す。
2022 年を振り返る
tag:blog.jxck.io,2016:entry://2022-12-31
2022-12-31T00:00:00Z
例年通り 2022 年を振り返る。
CORB から ORB へ
tag:blog.jxck.io,2016:entry://2022-10-25
2022-10-25T00:00:00Z
CORB (Cross Origin Read Blocking) が Fetch の仕様から消え、後継の ORB (Opaque Response Blocking) が策定作業中である。ここでどのような変更が起こっているのかを調査し、記録する。
XMLHttpRequest とはなんだったのか
tag:blog.jxck.io,2016:entry://2022-09-30
2022-09-30T00:00:00Z
Fetch API の実装が広まり、IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。
HPKE とは何か
tag:blog.jxck.io,2016:entry://2022-08-25
2022-08-25T00:00:00Z
HPKE (Hybrid Public Key Encryption) が RFC 9180 として公開された。RFC 9180: Hybrid Public Key Encryptionhttps://www.rfc-editor.org/rfc/rfc9180.htmlHPKE は、公開鍵暗号方式と共通鍵暗号方式を組み合わせて(ハイブリッド)任意の平文を暗号化するための、汎用的な枠組みとして標準化されている。この仕様は、多くのユースケースが想定されており、RFC になる前から ECH (Encrypted Client Hello), MLS (Message Layer Security), OHTTP (Oblivious HTTP) など、さまざまな仕様から採用を検討されている。本サイトで書く予定の他の記事でも HPKE は頻出する予定であり、今後より多くの場面でこの仕様を見ることになると思われるため、一度この仕様の概観について解説する。(筆者は暗号の専門家ではないため、解釈や語彙使用の間違いがあるかもしれない。)
HTTP 関連 RFC が大量に出た話と 3 行まとめ
tag:blog.jxck.io,2016:entry://2022-06-16
2022-06-16T00:00:00Z
2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。RFC 9110: HTTP SemanticsRFC 9111: HTTP CachingRFC 9112: HTTP/1.1RFC 9113: HTTP/2RFC 9114: HTTP/3RFC 9163: Expect-CT Extension for HTTPRFC 9204: QPACK: Field Compression for HTTP/3RFC 9205: Building Protocols with HTTPRFC 9209: The Proxy-Status HTTP Response Header FieldRFC 9211: The Cache-Status HTTP Response Header FieldRFC 9213: Targeted HTTP Cache ControlRFC 9218: Extensible Prioritization Scheme for HTTPRFC 9220: Bootstrapping WebSockets with HTTP/3RFC 9230: Oblivious DNS over HTTPSいったい何が起こっているのか、それぞれの経緯と開発者が知っておいた方がいいこと、そうでもないことを解説する。
JavaScript のメディアタイプと RFC 9239
tag:blog.jxck.io,2016:entry://2022-05-31
2022-05-31T00:00:00Z
長いこと作業が行われていた JavaScript の MIME タイプについての作業が完了し、RFC 9239 として公開された。これにより、推奨される MIME タイプが text/javascript に統一されることになった。かつて推奨されていた application/javascript ではなくなった経緯などを踏まえ、解説する。
Navigation API による「JS での画面遷移」と SPA の改善
tag:blog.jxck.io,2016:entry://2022-04-22
2022-04-22T00:00:00Z
従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。これは、History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。この API の目的と仕様を解説しつつ、実装のメモを残す。
Markdown の Table 記法を CSS で実現する
tag:blog.jxck.io,2016:entry://2022-03-06
2022-03-06T00:00:00Z
本ブログは Markdown で原稿を書き、それを HTML に変換して表示している。このとき、CSS を用いて Markdown のシンタックスに似せた Style を適用している。例えば以下のように h2::before に content: '##' を指定するといった具合だ。しかし、これまで <table> だけはうまく Markdown 記法を再現する CSS が書けないでいた。そこで、周りの CSS 強者に実現できないか聞いてみたところ、@shqld, @araya, @yoshiko 達の協力を得て、かなりの完成度にすることができた。実現方法を記録する。
サイトの HTTP3 化と DNS HTTPS RR および Alt-Svc Header によるアドバタイズ
tag:blog.jxck.io,2016:entry://2022-02-05
2022-02-05T00:00:00Z
本サイトを HTTP3 対応し、Alt-Svc ヘッダおよび DNS HTTPS Resource Record によってそれをアドバタイズする構成を適用した。色々ハマったので作業のログを記す。
画像最適化戦略 AVIF 編
tag:blog.jxck.io,2016:entry://2022-01-07
2022-01-07T00:00:00Z
本サイトの PNG/JPEG で提供している画像については、よりサイズが小さくなりやすい AVIF 形式を提供し、対応ブラウザに配信するようにした。フォーマットを出し分けるため、画像の指定は <picture> 要素を用いて対応した。画像最適化シリーズ第 6 回目のエントリである。画像最適化戦略 PNG/JPEG 編画像最適化戦略 Picture 編画像最適化戦略 WebP 編画像最適化戦略 SVG/Font 編画像最適化戦略 Lazy Loading 編> 画像最適化戦略 AVIF 編
2021 年をふりかえる
tag:blog.jxck.io,2016:entry://2021-12-28
2021-12-28T00:00:00Z
例年通り 2021 年を振り返る。
Web のセマンティクスにおける Push と Pull
tag:blog.jxck.io,2016:entry://2021-12-08
2021-12-08T00:00:00Z
筆者は、Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。「自分は今 Push で実装しているのか、Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。(本エントリでの Ossification は、一般に言われている Protocol Ossification よりも、もう少し広義に捉えていることに注意)抽象的な話が続くため、なるべく具体例を交えて解説を試みる。
自作 Markdown プロセッサベースの blog.jxck.io v2 リリース
tag:blog.jxck.io,2016:entry://2021-11-30
2021-11-30T00:00:00Z
本サイトは自作の Markdown ビルダを使っていたが、色々と気に食わない部分があったのでフルスクラッチで作り直し、それにともなってサイトの刷新を実施した。必要だった要件や、意思決定を作業ログとして記す。
ABNF Parser の実装
tag:blog.jxck.io,2016:entry://2021-10-21
2021-10-21T00:00:00Z
IETF の RFC では ABNF 形式の表現がよく使われ、たまに実装することがある。しかし、実装するたびに前のコードを引っ張り出して思い出す、を繰り返しているので、自分用にメモとしてやり方をまとめる。完全に我流であり、目的は「その ABNF が正しいかを確認すること」なので、高速化や効率的を求める実用実装とは目的が違う点は先に言っておく。
Private Relay と IP Blindness による Fingerprint 対策
tag:blog.jxck.io,2016:entry://2021-09-22
2021-09-22T00:00:00Z
iOS15 がリリースされたため、Private Relay のベータを試すことができた。このようなサービスが提供されるようになった背景を踏まえ、挙動を簡単に確認しつつ、解説する。
mouseover 中に表示される DOM のデバッグ
tag:blog.jxck.io,2016:entry://2021-08-20
2021-08-20T00:00:00Z
先日、後輩が「mouseover 中にしか表示されない DOM のデバッグ」に手こずっていたのを見て、たまには小ネタもということで、いくつかのテクニックを紹介する。実際には、発生しているイベントを制御するというテクニックなので、応用すると色々使えるだろう。
Cross Origin iframe からの alert/confirm/prompt 呼び出しの無効化
tag:blog.jxck.io,2016:entry://2021-08-02
2021-08-02T00:00:00Z
直近で話題になっている Chrome の挙動変更についてまとめた。Reverse OT による延命はあるが、もともとが「セキュリティ的な理由でできなくする」のが目的のため、OT 期間中に修正が必要そうであることを先に述べておく。なお、これはあくまで筆者が調べた結果に基づいた見解であるため、該当する開発者は常に公式のアナウンスなどに注意し、最新の情報を踏まえて自身で判断すべきである。
本サイトの AMP 提供の停止とここまでの振り返り
tag:blog.jxck.io,2016:entry://2021-06-26
2021-06-26T00:00:00Z
前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期待しないで欲しい。
Non AMP SXG による Prefetch 対応と AMP 提供の停止
tag:blog.jxck.io,2016:entry://2021-05-28
2021-05-28T00:00:00Z
本サイトを (Non AMP) SXG に対応した。これにより、Google のモバイル検索では、結果を表示した時点でこのサイトの SXG が Prefetch され、結果を選択したら Cache から素早く表示されつつ、アドレスバーにも本サイトのものとして表示される。この、Non AMP SXG 対応にあたって、本サイトの AMP の提供も停止することになった。移行の作業ログと、関連する流れについて記す。
IE11 サポート終了の歴史
tag:blog.jxck.io,2016:entry://2021-05-11
2021-05-11T00:00:00Z
IE11 が役目を終えていく流れを記録として残す。特に MS からのアナウンスや、それに準じた各サービスの反応、特に IE サポート終了アナウンスをまとめることで、IE11 というブラウザがどのように終了していったのかのを記録することを目的とする。もともとは Google Docs にまとめていたものである。日付はアナウンスの公開日サポート終了日ではないサポート終了日も書いておけばよかったけど今からやり直す気力はない、、赤字 は MS 関連もしくはサポート終了の影響が大きそうなアナウンスWindows における IE11 自体のサポート終了については以下を参照https://www.atmarkit.co.jp/ait/articles/1503/11/news134.htmlできればある程度の結論が出るまでこのエントリを更新していきたい
Public Suffix List の用途と今起こっている問題について
tag:blog.jxck.io,2016:entry://2021-04-21
2021-04-21T00:00:00Z
Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。最近、このリストへの追加リクエストがあとを絶たず、問題になっている。そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。
Web Font のメトリクス上書きによる CLS の改善
tag:blog.jxck.io,2016:entry://2021-02-25
2021-02-25T00:00:00Z
WebFont を読み込む際に、取得完了までのラグを、システムが持つフォールバックフォントで代替する場合がある。このとき、フォールバックフォントと読み込んだ Web フォントで、高さに関する情報が異なる場合、Layout Shift が発生してしまう。これを防ぐ方法として、CSS からフォントメトリクスの上書きを行う仕様の提案が行われているため、本サイトへの適用を目指し検証を行った。なお、この仕様は Layout Shift ではなく、単純にテキストレイアウトスタイル用途での利用も考えられるが、そこはスコープ外としている。
Cache-Control: must-understand ディレクティブとは何か
tag:blog.jxck.io,2016:entry://2021-02-12
2021-02-12T00:00:00Z
IETF が策定する HTTP の仕様が更新されようとしている。ここには、Cache の仕様も含まれており、そのなかで must-understand という Cache-Control のディレクティブが追加されている。このディレクティブが追加された経緯と仕様について解説する。
Structured Field Values による Header Field の構造化
tag:blog.jxck.io,2016:entry://2021-01-31
2021-01-31T00:00:00Z
HTTP Header の値を構造化する Structued Field Values の仕様が RFC になった。RFC 8941: Structured Field Values for HTTPこの仕様の詳細について、筆者の実装を交えて解説する。
2020 年をふりかえる
tag:blog.jxck.io,2016:entry://2020-12-31
2020-12-31T00:00:00Z
例年通り 2020 年を振り返る。
AMP SXG 対応
tag:blog.jxck.io,2016:entry://2020-12-25
2020-12-25T00:00:00Z
本サイトを AMP SXG に対応した。その作業ログを記す。
CSS Layout API で Masonry Layout
tag:blog.jxck.io,2016:entry://2020-12-03
2020-12-03T00:00:00Z
Pinterest でおなじみの Masonry Layout を CSS の標準にする作業と実装が進んでいる。以下のように画像を敷き詰めるタイルレイアウトのことを Masonry (石工やレンガ造りの意味らしい) Layout という。上の例の場合は、Height が不揃いの画像を並べる上で、左から敷き詰め、折り返したら既にある画像の高さに合わせて二列目が始まるというロジックになる。これを実現するには、割と複雑な CSS を書く必要があり、様々なサイトで CSS ライブラリや、Grid などを用いて再現する方法が紹介されている。これをそのまま CSS の標準にする作業が Layout API の文脈で行われており、既に一部が(主に Firefox で)実装されている。仕様は以下だ。CSS Grid Layout Module Level 3https://drafts.csswg.org/css-grid-3/従来の CSS Grid は、縦横が揃った Grid を展開し、そこに対して要素を割り当てるのが基本だが、それでは縦が揃わないため Masonry は実現できない。そこで、grid-template-rows / grid-template-columns へ masonry を追加し、これを指定すると Masonry レイアウトが実現できるようになる。省略すると grid: masonry / ${column} になるため、column に repeat などを指定すれば Pinterest のようなレイアウトが実現できる。3 列の Masonry Layout は以下だ。<style>.grid { display: inline-grid; grid: masonry / repeat(3, auto); border: 1px solid; gap: 1vw; masonry-auto-flow: pack; width: 32vw;}img { width: 10vw;}</style><div class=masonry> <img> <img> <img> ...</div>敷き詰めるためのアルゴリズムは仕様で決まっている。https://drafts.csswg.org/css-grid-3/#masonry-layout-algorithmデフォルトでは、敷き詰める際に一番余白が空いているところに画像が挿入される。これを制御するプロパティとして masonry-auto-flow が定義されており、next にすると画像の HTML 上での出現順に積み上げるようにすることもできる。masonry-auto-flow: pack;masonry-auto-flow: next;他の値もあるがまだ定義が明示されていないようだ。このあたりのアルゴリズムは要件によって多様だと思われるため、仕様の策定とともに変わる可能性は高いだろう。https://drafts.csswg.org/css-grid-3/#masonry-auto-flow
Web 技術の調査方法
tag:blog.jxck.io,2016:entry://2020-11-19
2020-11-19T00:00:00Z
「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。スコープとしては、ライブラリ、ツール、フレームワークなどではなく、Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。
Puppeteer で静的サイトの Font Subsetting
tag:blog.jxck.io,2016:entry://2020-09-07
2020-09-07T00:00:00Z
Web Font のサブセット化を Font Weight に応じて作り分けるとともに、それを Puppeteer を用いて生成するように変更した。
WebCodecs と WebTransport でビデオチャット
tag:blog.jxck.io,2016:entry://2020-09-01
2020-09-01T00:00:00Z
ブラウザの持つ Video/Audio コーデック実装へアクセスする API として WebCodecs の仕様策定と実装が進んでいる。これにより、映像や音声の変換などといったユースケースへの応用も可能だ。本来なら WebCodecs 単体の API について解説するところだが、筆者がこの API を待っていた理由であるところの「WebRTC の代替」としての WebCodecs/WebTransport の応用に注目し、背景も踏まえて解説する。
img の srcset 指定時に選択される画像
tag:blog.jxck.io,2016:entry://2020-08-15
2020-08-15T00:00:00Z
<img> や <picture> で srcset に複数の画像を指定することで、デバイスに応じて適切な解像度の画像を提供することができる。この画像が、どういった条件で選択されるのかを頭では勝手に理解していたつもりだが、理解とは違う挙動があったため、仕様と実装を確認した。その記録を記す。なお、先に言うがどのブラウザも 仕様に準拠して 実装されている。
Webbundle によるサブリソース取得の最適化
tag:blog.jxck.io,2016:entry://2020-07-26
2020-07-26T00:00:00Z
WebBundle を用いてサブリソースのみを Bundle する、Subresource Bundle の策定と実装が進んでいる。これを用いると、複数サブリソースの取得を一回の fetch で行うことができ、RTT を減らしつつも個別に取得したかのようにキャッシュを制御できる。現時点での仕様と実装を解説する。Intent to Prototype: Subresource loading with Web Bundles
ローカル開発環境の https 化
tag:blog.jxck.io,2016:entry://2020-06-29
2020-06-29T00:00:00Z
Web の https 化が進み、それに伴って https を前提とする API も増えてきた。そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。特に推奨するつもりはない。
QuicTransport によるアプリケーションレイヤでの QUIC 活用
tag:blog.jxck.io,2016:entry://2020-06-09
2020-06-09T00:00:00Z
WebTransport の Quic 実装である QuicTransport の開発が Chrome で行われている。Chrome で Origin Trials が開始されたので仕様と実装を解説する。
Site Isolation 及び Web のセキュリティモデルの更新
tag:blog.jxck.io,2016:entry://2020-05-22
2020-05-22T00:00:00Z
Origin は Web におけるセキュリティモデルの一つとして、コンテンツ間の Communication に関する境界を定義し、リソースを保護してきた。しかし、Spectre の発覚以降、Communication に関する制限だけではなく Isolation によるメモリレベルでのアクセス制御が必要となった。そこで現在作業されているのが、CORB, CORP, COEP, COOP といった仕様群であり、これは Web におけるセキュリティモデルの更新作業と見ることができる。概要と現状について解説する。
mozaic.fm v3 リリースと Podcast の PWA 化
tag:blog.jxck.io,2016:entry://2020-05-06
2020-05-06T00:00:00Z
mozaic.fm をリニューアルし v3 としてリリースした。今回の更新は以下のような変更/修正を実施している。PWA 化before install promptBackground FetchPeriodic Background SyncContent Index APIBadging APIPlayer UI の刷新Pure WebcomponentsMedia Session APIWAI-ARIAPortal PreviewScreen Wake LockSecurityCSP v3 (not Report-Only)Cross Origin Resource PolicyCross Origin Opener PolicyCross Origin Embedder PolicyExpect-CTNELReferrer Policyその他Transpile LessScroll To Text Fragment SearchSpotifyWIPTemplate InstantiationHTML ModulesDocument PolicySilent PushWASM ID3SXG実施したモチベーションおよび、実施内容について記す。先に言っておくが、実装も仕様も全く安定してないものを、エミュレータだけでエスパー実装しているので、実機で動く保証もなく、しょっちゅう壊れる。サイトが壊れて聴けなかったらご愛用の Podcast アプリで聞いてほしい。
Periodic Background Sync 及び Web を Install するということ
tag:blog.jxck.io,2016:entry://2020-04-23
2020-04-23T00:00:00Z
メールクライアントや RSS リーダーのようなユースケースを PWA で実装する場合、バックグラウンドで定期的にタスクを実行したいケースがある。このユースケースに特化した API として提案されているのが、Periodic Background Sync(PBS) だ。しかし、この API を取り巻く議論は「Web にアプリのような API を持ち込む上での難しさ」を物語っている。この API が Web において正当化できるかどうかは、Project Fugu に代表される Application Capabilities を Web に持ち込む場合の試金石になりそうだ。現時点での、仕様、実装、議論について解説する。
Scroll to Text Fragment を用いたサイト内検索の実装
tag:blog.jxck.io,2016:entry://2020-03-27
2020-03-27T00:00:00Z
Scroll to Text Fragment のユースケースとして、本サイトにサイト内検索を実装した。
牧歌的 Cookie の終焉
tag:blog.jxck.io,2016:entry://2020-02-25
2020-02-25T00:00:00Z
Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。そんな Cookie が今どう使われ、3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。
3rd Party Cookie 調査のための Web 広告導入
tag:blog.jxck.io,2016:entry://2020-01-31
2020-01-31T00:00:00Z
昨今、特に広告サービスを中心に 3rd Party Cookie を用いたトラッキングについての議論が多く行われている。Safari による ITP や、Chrome による Privacy Sandbox への移行など、技術的な変化も著しい。こうした技術の変遷を観測し、調査検証を行うために、これまで避けていた Web 広告を本サイトに導入することにした。
Service Worker の Background Fetch によるメディアのキャッシュ
tag:blog.jxck.io,2016:entry://2020-01-24
2020-01-24T00:00:00Z
Podcast を PWA 対応するために、待望だった機能の 1 つが Background Fetch だ。これにより、通常 Range Request で取得するような、大きなファイルを事前にダウンロードしておくことができるようになる。この API と、Service Worker およびブラウザにおける Range Request/Partial Response の扱いについて記す。
ブラウザで何が起こっているのかを知る Reporting API と ReportingObserver
tag:blog.jxck.io,2016:entry://2020-01-18
2020-01-18T00:00:00Z
Web サービスにおいては通常、Web サーバから取得できるアクセスログやエラーログを取得し解析する基盤を保有するだろう。しかし、Web サーバから取得できる情報だけでは、ブラウザで何が起こったのかを知るのは限界がある。今回は、ブラウザ内で起こったことを知るための Reporting API と、その Report の収集について解説する。
2019 年をふりかえる
tag:blog.jxck.io,2016:entry://2019-12-28
2019-12-28T00:00:00Z
例年通り 2019 年を振り返る
WebBundle によるコンテンツの結合と WebPackaging
tag:blog.jxck.io,2016:entry://2019-11-12
2019-11-12T00:00:00Z
依存コンテンツを 1 つにまとめて配信する WebBundle の仕様策定と実装が進んでいる。これは Signed HTTP Exchange と合わせて WebPackaging を実現するための仕様であり、組み合わせれば WebBundle に対して署名することでコンテンツの配信を通信と分けて考えることができる。Signed HTTP Exchange に比べると格段に簡単な仕様なので、現状のフォーマットと挙動について解説する。draft-yasskin-wpack-bundled-exchanges-latest
Intel NUC で自宅 Ubuntu 開発環境構築と SSH Port Forwarding によるアクセス
tag:blog.jxck.io,2016:entry://2019-11-03
2019-11-03T00:00:00Z
家では Mac を使っていたが、やはり Ubuntu 開発環境を作ることにした。前々から気になっていた Intel NUC をベースに Ubuntu 環境を構築。また、外出時もアクセスできるように SSH Port Forwarding を使って、固定 IP の無い家に外からアクセスできるようにした。備忘録を兼ねて記す。
Scroll To Text Fragment と :~:text
tag:blog.jxck.io,2016:entry://2019-10-16
2019-10-16T00:00:00Z
ページ内の特定の位置へのスクロールは、URL フラグメントと HTML の ID 属性を用いて行われていた。しかし、ID を持たない要素へのスクロールというユースケースをカバーするために、フラグメントの拡張仕様が提案されている。Chrome がフラグ付きで実装しているため、この仕様の特徴について解説する。
Noto Sans Hinted と font-feature-settings: 'palt'
tag:blog.jxck.io,2016:entry://2019-10-13
2019-10-13T00:00:00Z
Noto Sans のサブセット生成を見なおし、Noto Sans Hinted から pyftsubset で生成し、ついでに font-feature-settings を有効にした。作業と検証の記録を兼ねて、実施結果を記す。
Promise.allSettled と Promise.any
tag:blog.jxck.io,2016:entry://2019-08-20
2019-08-20T00:00:00Z
Promise.allSettled() と Promise.any() の仕様策定が進んでいる。両者は近いレイヤの仕様では有るが、作業の進捗には差がある。Promise.allSettled は Stage 4 であり、Chrome や Safari TP には実装もされているPromise.any は Stage 2 であり、実装はまだないここでは、これらがあると何が嬉しいのかを Promise.all(), Promise.race() の特徴を踏まえて解説する。
WebTransport と WebCodecs そして Web はどこまで "ゲーム化" するか
tag:blog.jxck.io,2016:entry://2019-08-18
2019-08-18T00:00:00Z
Transport として HTTP over TCP を基本としていた Web のあり方は大きく代わり、転送するメディアも HTML だけに止まらなくなってきた。その対角線上にあるユースケースとして、UDP でバイナリデータを双方向にやり取りする「ゲーム」があるだろう。WebSocket/MSE/WebRTC/WASM など、Web で Game を行うためのパーツは徐々に揃いつつあり、過去に比べればだいぶ状況は改善してきていると言える。しかし、できることが増えればこそ、それぞれのパーツの不足する部分が浮き彫りになる。WebTransport と WebCodecs は、主にそんな Web Game の需要から「本当に必要としているもの」を再考した結果をまとめた提案と言えるだろう。これが、単に Web Game 開発の需要を満たすだけで終わるものか、ゲーム以外の Web の開発にどこまで影響を及ぼすか。現状の仕様の提案とそのモチベーションを元に、考察していく。
Nullish Coalescing と Optional Chaining
tag:blog.jxck.io,2016:entry://2019-08-14
2019-08-14T00:00:00Z
JS における null/undefined の扱い改善するための 2 つの機能が提案されている。Nullish Coalescing Operator (stage 3)Optional Chaining Operator (stage 3)いずれも Stage 3 に進み、実装も始まっているので、現時点での解説を行う。
Display Locking によるレンダリングの最適化と Async DOM
tag:blog.jxck.io,2016:entry://2019-06-16
2019-06-16T00:00:00Z
React や lit-html などにより、DOM 操作の抽象化に加えて最適化が提供されることが一般的となった。見方を変えれば、本来ブラウザがやるような最適化を、ライブラリが肩代わりしていると捉えることもできる。これは、現在の標準 API には、規模が大きく処理が複雑なアプリケーションを開発する際に、足りてないものがあると考えることが可能だ。課題の 1 つとして「DOM 操作が同期処理である」という点に着目し、Async DOM という文脈でいくつかの提案が行われた。今回は、その提案の 1 つであり Chrome で実装が進んでいる Display Locking について現状を解説する。
画像最適化戦略 Lazy Loading 編
tag:blog.jxck.io,2016:entry://2019-05-20
2019-05-20T00:00:00Z
長らく議論されてきた <img> や <iframe> における Lazyload について、仕様と実装が動きを見せている。ここでは、特に画像 <img> に注目し、Lazyloading の議論の変遷を踏まえた上で現状を解説する。画像最適化シリーズ第 5 回目のエントリである。画像最適化戦略 PNG/JPEG 編画像最適化戦略 Picture 編画像最適化戦略 WebP 編画像最適化戦略 SVG/Font 編> 画像最適化戦略 Lazy Loading 編
mozaic bootcamp 2019
tag:blog.jxck.io,2016:entry://2019-05-12
2019-05-12T00:00:00Z
2019/4/28 - 5/1 の 4 日間で、mozaic bootcamp 2019 というひたすら Web 技術を叩き込むイベントを開催した。その内容やモチベーションについては、以下で話している。ep48 Monthly Web 201901 | mozaic.fmこのイベントの概要と目的について記録する。
Web における技術の解釈とエコシステムによる合意形成プロセスについて
tag:blog.jxck.io,2016:entry://2019-04-26
2019-04-26T00:00:00Z
「ユーザが意図する挙動」とは何か。技術的に可能であるが「やらない方が良いこと」は、誰がどう決めるのか。Web には仕様、実装、デプロイ、そしてユーザの利用とフィードバックによって、そうした合意がゆるやかに形成されていく仕組みがあると筆者は考えている。しかし、これは明文化されているわけでもなく、その全体像を把握するのは一般には難しいだろう。今回は、ちょうど何度目かの議論が再発している ping 属性を例に、この合意形成の概観について解説を試みる。
Private Class Field の導入に伴う JS の構文拡張
tag:blog.jxck.io,2016:entry://2019-03-14
2019-03-14T00:00:00Z
ECMAScript の Private Class Field の仕様策定と各ブラウザの実装が進んでいる。これにより、従来の JS にはなかった Class の Private フィールドが使えるようになる。提案されている構文や、挙動について解説する。
安全な文字列であると型で検証する Trusted Types について
tag:blog.jxck.io,2016:entry://2019-01-27
2019-01-27T00:00:00Z
脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。WICG/trusted-typesIntent to Experiment: Trusted Types
Cache Digest と HTTP2 Server Push の現状
tag:blog.jxck.io,2016:entry://2019-01-19
2019-01-19T00:00:00Z
httpbis のチェアである mnot から、Cache Digest についての現状確認が ML に投稿された。もしこのまま反応がなければ、Cache Digest は終わり、対ブラウザキャッシュの Server Push は現実的ではなくなる。
次世代 Web カンファレンス 2019 開催後記
tag:blog.jxck.io,2016:entry://2019-01-15
2019-01-15T00:00:00Z
2019/1/13(日) に、以下で告知した「次世代 Web カンファレンス」を開催した。次世代 Web カンファレンス 2019 開催告知 | blog.jxck.io前日に初雪が観測されて心配したが、天気にも恵まれ、開催趣旨の通り予定していたセッションを全て終えることができた。次世代 Web カンファレンス - connpass各セッションはこれから録画を見るが、登壇者達に聞いた感触としては、概ね熱い議論ができていたようなので、場を設けた価値はあったと思う。録画や togetter はすでに上がっている。
2018 年をふりかえる
tag:blog.jxck.io,2016:entry://2018-12-31
2018-12-31T00:00:00Z
例年通り 2018 年を振り返る
WebPackaging の Signed HTTP Exchanges
tag:blog.jxck.io,2016:entry://2018-12-01
2018-12-01T00:00:00Z
WebPackaging は以下の 3 つの仕様を組み合わせたユースケースである。Signed HTTP Exchanges: Signing (コンテンツに署名する)Bundled HTTP Exchanges: Bundling (コンテンツを 1 つにまとめる)Loading Signed Exchanges: Loading (そのコンテンツをロードする)本エントリでは、各仕様を Signing/Bundling/Loading と記す。現状、Signing および Loading の仕様策定が進んでおり、Chrome は Experimental な実装を行っている。全体的に仕様が大きく、今後も変更される可能性が高いため、今回は実装が進んでいる Signing に絞り、ユースケース、仕様、および本ブログへの適用を中心に解説する。
prefers-color-scheme を用いた Dark Mode 対応と User Preference Media Features
tag:blog.jxck.io,2016:entry://2018-11-10
2018-11-10T00:00:00Z
macOS Mojava は OS レベルで Dark Mode に対応した。しかし、Web コンテンツは依然として白背景黒文字ベースのデザインが多く、結果ブラウザの中だけ眩しいという問題がある。Safari TP69 では、これにメディアクエリで対応するための prefers-color-scheme が実装された。これを用いた DarkMode 対応と、本ブログの DarkMode 対応、および策定中の User Preference Media Features について解説する。
Cookie の性質を利用した攻撃と Same Site Cookie の効果
tag:blog.jxck.io,2016:entry://2018-10-26
2018-10-26T00:00:00Z
Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。
Referrer-Policy によるリファラ制御
tag:blog.jxck.io,2016:entry://2018-10-08
2018-10-08T00:00:00Z
リファラはリンクなどでページを遷移する際に、遷移元の URL をリクエストの Referer ヘッダに載せる仕様である。この付与はブラウザが自動で行うため、場合によっては非公開として扱っている URL が意図せず漏れることがある。この挙動を制御することができる、Referrer-Policy ヘッダについて解説する。
次世代 Web カンファレンス 2019 開催告知
tag:blog.jxck.io,2016:entry://2018-09-15
2018-09-15T00:00:00Z
2019/1/13(日) に、「次世代 Web カンファレンス」を開催します。名称次世代 Web カンファレンス日時2019/1/13(日) 9:00-17:30場所法政大学富士見ゲート 4F 401, 402, 403後援法政大学情報科学部配信Youtube募集Connpass参加費無料(参考) 2015 年実施のログは以下です。bloghttp://jxck.hatenablog.com/entry/next-web-conf-2915connpasshttps://nextwebconf.connpass.com/event/19699/録画405, 406, 407
Clear-Site-Data Header
tag:blog.jxck.io,2016:entry://2018-07-24
2018-07-24T00:00:00Z
Clear-Site-Data Header の実装が進んでいる。このヘッダについて解説する。
Element.toggleAttribute
tag:blog.jxck.io,2016:entry://2018-07-20
2018-07-20T00:00:00Z
非常にシンプルかつミッシングピースだった Element.toggleAttribute という仕様が提案された。最近になって各ブラウザが一斉に実装を進め、リリースに向けたアナウンスが出始めている。この仕様について解説する。
Monthly Web の作り方 2018 年版
tag:blog.jxck.io,2016:entry://2018-07-18
2018-07-18T00:00:00Z
筆者がやっている Podcast である mozaic.fm の中で、Monthly Web という月ごとの Web の動向をまとめる回をやっている。未だに落ち着いたとはいえないが、2017 年 7 月に初めてから 1 年続けたので、結果として現状どうなっているかをログに残す。
Web Authentication API で FIDO U2F(YubiKey) 認証
tag:blog.jxck.io,2016:entry://2018-05-15
2018-05-15T00:00:00Z
Web Authentication(WebAuthN) API の策定と実装が進んでいる。これを用いると、FIDO(Fast IDentity Online) U2F(Universal Second Factor) 認証が可能になる。今回は YubiKey 認証の実装を通じて、ブラウザ API の呼び出しと、サーバ側で必要な処理について解説する。https://w3c.github.io/webauthn/
Layered APIs と High Level API の標準化指針
tag:blog.jxck.io,2016:entry://2018-05-01
2018-05-01T00:00:00Z
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
Linux で出力を別の shell に pts 経由で表示する
tag:blog.jxck.io,2016:entry://2018-04-30
2018-04-30T00:00:00Z
tmux, screen, terminal のタブなど、shell を複数起動する方法はいくつかある。Linux では、pts を経由すれば、ある shell の出力を簡単に別の shell で表示することができる。これを応用すると、簡易ダッシュボードを作り色々便利に使うことができる。
Certificate Transparency の仕組みと HPKP から Expect-CT への移行
tag:blog.jxck.io,2016:entry://2018-03-27
2018-03-27T00:00:00Z
本サイトは HPKP (public-key-pins-report-only) に対応していた。しかし、HPKP はその運用性の問題などもあり、Chrome はすでに deprecate するアナウンスを出している。代替の仕様として、Certificate Transparency (CT) のエコシステムと、それを利用する Expect-CT の策定/実装が進んでいる。CT エコシステムの概要、Log の登録/検証、HPKP から Expect-CT への移行などについて解説する。
Feature Policy による Permission Delegation
tag:blog.jxck.io,2016:entry://2018-03-08
2018-03-08T00:00:00Z
ブラウザの機能を制限する Feature Policy の実装が進みつつある。Feature Policy は、ブラウザが持つ機能について選択的に許可/制限を行う API だ。AMP のように特定の機能を制限する目的にも使えるが、クロスオリジン iframe に対する権限移譲のための API としても使用される。Feature Policy のモチベーションおよび適用方法について、類似する CSP や iframe sandbox と合わせて解説する。なお、今回解説する内容は、まだブラウザの実装に反映されていない部分があるため、注意されたい。
WebFont の WOFF2 対応によるサイズ最適化
tag:blog.jxck.io,2016:entry://2018-02-13
2018-02-13T00:00:00Z
Safari 10.0 から WOFF2 がサポートされており、これをもって IE 以外のメジャーブラウザではサポートが揃いつつある。本サイトは WOFF 形式での Web Font を提供しているが、WOFF2 形式では WOFF よりも 12% 程度圧縮率が高いため、本サイトでも WOFF2 に移行することとした。フォーマット変更による効果について解説する。
Safari による User-Agent 固定化と Web における Feature Detection
tag:blog.jxck.io,2016:entry://2018-01-17
2018-01-17T00:00:00Z
少し前に Safari Technology Preview 46 がリリースされた。Service Worker のアナウンスに目がそちらに盗まれている一方、しれっと以下の一文がある。Froze the user-agent string to reduce web compatibility risk and to prevent its use for fingerprinting--- Release Notes for Safari Technology Preview 46すぐには無理だろうと思ったが、TP47 でもこれを打ち消すアナウンスはなかったため、これを取り上げることにした。TP はあくまで Preview であり、これが このままリリースされるとは限らない 点に注意したい。今回は、これがそのままリリースされた場合の影響について考察するため、現在の User-Agent の使われ方を解説する。
Apple の AOM 加盟と AV1 への期待
tag:blog.jxck.io,2016:entry://2018-01-15
2018-01-15T00:00:00Z
Apple が Alliance for Open Media に加盟したという報道があった。もし、このまま Safari が AV1 をサポートするまで至れば、WebRTC のコーデック戦争に一旦の落ち着きが出ると思われる。Apple joins alliance to shrink your online videos - CNETこの動向について解説する。
record to map in Erlang
tag:blog.jxck.io,2016:entry://2018-01-14
2018-01-14T00:00:00Z
Record を Map に変換するだけのマクロ
Form で submit されたデータの収集と FormData & URLSearchParams
tag:blog.jxck.io,2016:entry://2018-01-13
2018-01-13T00:00:00Z
<form> の onsubmit をフックして、入力された値を <input> から集めて送るといった処理はよくある。このとき、submit されたデータの収拾方法はいくつかある。submit に限らず、そのイベントに付随する情報は、基本的にイベントオブジェクトに内包されている。Form を例に、イベントオブジェクトを意識したコーディングについて解説する。
Bookmarklet という一番身近な自動化技術
tag:blog.jxck.io,2016:entry://2018-01-12
2018-01-12T00:00:00Z
「毎回やるなら bookmarklet にでもすれば?」と言ったら、後輩が「そんな便利なことできたんですね、知りませんでした」と言っていた。そんな時代にこそ、今更だれも解説しないであろう、bookmarklet という技術についてもう一度書いておく。
SDP の Unified Plan と Plan B
tag:blog.jxck.io,2016:entry://2018-01-05
2018-01-05T00:00:00Z
新年早々、Blink Dev で Unified Plan の Intent to Implement という嬉しい知らせが届いた。Intent to Implement: WebRTC Unified Plan SDPSDP の互換性についてインパクトの大きいこの変更について簡単に解説する。
2017 年を振り返る
tag:blog.jxck.io,2016:entry://2017-12-31
2017-12-31T00:00:00Z
例年通り、今年を振り返る。
ResizeObserver による変更検知と Element Query
tag:blog.jxck.io,2016:entry://2017-12-30
2017-12-30T00:00:00Z
ResizeObserver の ship が進みつつある。この仕様の解説および、ElementQuery / ContainerQuery について解説する。Resize Observer 1
WHATWG の IPR Policy と Governance Structure
tag:blog.jxck.io,2016:entry://2017-12-12
2017-12-12T00:00:00Z
WHATWG が IPR Policy と Governance Structure についての更新を発表した。おおまかな流れと、これによって引き起されそうな変化について解説する。
Font Display プロパティを用いた FOIT/FOUT 最適化
tag:blog.jxck.io,2016:entry://2017-12-06
2017-12-06T00:00:00Z
Web Font 読み込み中の HTML 表示については、ブラウザデフォルトの挙動に依存していた。フォントファイルサイズが大きい場合は、FOIT/FOUT の問題が顕著になり、JS を用いた回避策が利用されることも多かった。これを解決するため、CSS に font-display プロパティが作成され、実装が進んでいる。各プロパティの違いと挙動、そして本サイトへの適用について解説する。
Houdini Paint API
tag:blog.jxck.io,2016:entry://2017-10-31
2017-10-31T00:00:00Z
Houdini で議論されている CSS Paint API が Chrome Canary で flag 付きで実装されている。デモの実装を通して、関連仕様を含めた以下の 4 つのドラフトを解説する。CSS Painting API Level 1CSS Properties and Values API Level 1CSS Typed OM Level 1Worklets Level 1
CSS Rhythmic Sizing で Vertical Rhythm
tag:blog.jxck.io,2016:entry://2017-10-09
2017-10-09T00:00:00Z
タイポグラフィに関連したデザイン手法の 1 つに Vertical Rhythm がある。そして、現在 CSS でそれを簡単に実現するための CSS Rhythmic Sizing という仕様が提案されている。Chrome にフラグ付きで実装されたこの仕様を用いて、本サイトへの適用を行ったので、解説する。CSS Rhythmic Sizing
予約済みドメイン (.example, .localhost, .test) について
tag:blog.jxck.io,2016:entry://2017-09-27
2017-09-27T00:00:00Z
特別なドメインとして予約され、特定の用途で使用可能なドメインとして、.example .localhost .test などがある。localhost の Draft や、gTLD である .dev が Chrome で Preload HSTS になったなどの動きを踏まえ、これらの意味や用途を解説する。
ブラウザで適当なランダム文字列
tag:blog.jxck.io,2016:entry://2017-09-26
2017-09-26T00:00:00Z
テストや仮実装で、適当なランダム文字列が欲しい場合に便利なスニペット。
Foreign Fetch が削除されそうな理由と Cookie の double keying
tag:blog.jxck.io,2016:entry://2017-09-19
2017-09-19T00:00:00Z
以前、本ブログでも紹介した Foreign Fetch が、仕様から削除される方向で進んでいる。Foreign Fetch による Micro Service Workers | blog.jxck.ioこれは、Safari などが進めている Cookie の double keying が影響しているらしいので、現状についてまとめる。
Brotli を用いた静的コンテンツ配信最適化と Accept-Encoding: br について
tag:blog.jxck.io,2016:entry://2017-08-19
2017-08-19T00:00:00Z
High Sierra に乗る Safari 11 で Brotli 対応がされるということで、メジャーブラウザの Brotli 対応が概ね揃うことになる。そこで、本サイトも Brotli による静的コンテンツ配信に対応した。
.mjs とは何か、またはモジュールベース JS とエコシステムの今後
tag:blog.jxck.io,2016:entry://2017-08-15
2017-08-15T00:00:00Z
長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、.mjs という拡張子が採択された。この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。
Promise.prototype.finally
tag:blog.jxck.io,2016:entry://2017-08-10
2017-08-10T00:00:00Z
Promise.prototype.finally の仕様が TC39 stage 3 となり、Safari TP37 で先行実装が入った。tc39/proposal-promise-finally
Service Worker の Navigation Preload による表示遅延回避
tag:blog.jxck.io,2016:entry://2017-08-05
2017-08-05T00:00:00Z
Service Worker で Fetch を Proxy する場合、Fetch 発生時に SW が起動していなければ、その起動を待つ必要が出る。そして、この SW の起動には無視できない時間がかかる場合があった。これを改善する Navigation Preload について解説する。
Fetch の中断と Promise のキャンセル方法の標準化
tag:blog.jxck.io,2016:entry://2017-07-19
2017-07-19T00:00:00Z
XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。これは、fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。最近、やっと話が前進したので、ここまでの経過を解説する。
ネットワーク中立性について #NetNeutrality
tag:blog.jxck.io,2016:entry://2017-07-14
2017-07-14T00:00:00Z
US では #NetNeutrality について話題になっている一方、日本ではさほど話題になってないように思う。インターネットを基盤としている Web 開発者にとっても、いつまで他人事でいられるか怪しい。事態そのものがあまり知られてないかもと思い、決して精通しているわけではないが紹介する。
EventTarget の継承可能化による EventEmitter の代替
tag:blog.jxck.io,2016:entry://2017-07-10
2017-07-10T00:00:00Z
念願 だった EventTarget の constructible/subclassable が DOM の仕様にマージされた。これにより、いわゆる EventEmitter のブラウザ移植が不要になることが期待される。Allow constructing and subclassing EventTarget
ES Modules への橋渡しとしての nomodule 属性
tag:blog.jxck.io,2016:entry://2017-06-21
2017-06-21T00:00:00Z
ブラウザにおける新機能の利用においては、非対応ブラウザの考慮も必要となる。ES Modules の利用においても、いかに非対応ブラウザでフォールバックの手段を提供するかが課題となっていた。今回は、Modules の対応/非対応を切り分けるための仕様である nomodule 属性を解説する。
Web Budget API と Web に導入されつつある Budget と Cost の概念
tag:blog.jxck.io,2016:entry://2017-06-12
2017-06-12T00:00:00Z
PWA の普及により、バックグラウンド処理をいかに制限するかといった課題が生まれた。その対策として、バックグラウンド処理における Budget と Cost の概念が提案され、それを扱う Budget API の策定が進んでいる。基本概念と現時点での API 外観について解説する。
Safari 11.0 will support WebRTC
tag:blog.jxck.io,2016:entry://2017-06-06
2017-06-06T00:00:00Z
Safari 11 のアップデートに、待望だった WebRTC がリストされた。
WebRTC 1.0 に向けたロードマップ
tag:blog.jxck.io,2016:entry://2017-05-22
2017-05-22T00:00:00Z
Google の Product Manager である Huib Kleinhout が、disscuss-webrtc の ML に以下のような投稿をした。Completing WebRTC 1.0WebRTC 1.0 を年内に終わらせるためのロードマップ(Chrome の改善を含む)を提示している。このロードマップに期待を寄せ、簡単に現状を振り返りつつ紹介する。
gen_fsm から gen_statem へ
tag:blog.jxck.io,2016:entry://2017-05-18
2017-05-18T00:00:00Z
Erlang/OTP 19 から、gen_fsm の後継として gen_statem が導入された。OTP の内部でも ssl などはすでに gen_statem に移行している。このビヘイビアの概要について記す。gen_statem APIgen_statem Behaviorすでにかなり安定はしているが、軽微といえども非互換な変更が OTP 20 以降に発生する可能性があることがドキュメントに言及されている。本記事は 19 時点での API ドキュメントをベースにしている。
Web Share API
tag:blog.jxck.io,2016:entry://2017-05-10
2017-05-10T00:00:00Z
Web Share API が Origin Trials を卒業したという知らせが届いた。コンテンツを他のサービスなどと連携するこの API について紹介する。
JavaScript における文字コードと「文字数」の数え方
tag:blog.jxck.io,2016:entry://2017-03-02
2017-03-02T00:00:00Z
textarea などに入力された文字数を、JS で数えたい場合がある。ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。
Monthly Web 2017/02
tag:blog.jxck.io,2016:entry://2017-02-21
2017-02-21T00:00:00Z
今月の Web メモ
Polyfill のあり方と Web の進化と協調するためのガイドライン
tag:blog.jxck.io,2016:entry://2017-02-17
2017-02-17T00:00:00Z
W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。Polyfills and the evolution of the WebPolyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。今回はこの内容を元に、Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。
CSP Report 収集と実レポートの考察
tag:blog.jxck.io,2016:entry://2017-02-13
2017-02-13T00:00:00Z
このブログで CSP レポートの収集を開始してもうすぐ 1 年になる。現状、対象ドメイン内で <input> は一切提供しておらず、大半が静的に生成されたページであるが、この条件でも、かなり多くのレポートが集まった。今回は、収集した実際のレポートを例に、攻撃ではないと思われるレポートとしてどういったものが送られて来たかを中心に、その内容やレポーティングサーバ、CSP の運用に関する現時点の考察についてまとめる。
Monthly Web 2017/01
tag:blog.jxck.io,2016:entry://2017-01-27
2017-01-27T00:00:00Z
月一メモ
mixed contents 対応を促進する CSP ディレクティブ
tag:blog.jxck.io,2016:entry://2017-01-10
2017-01-10T00:00:00Z
HTTPS 移行の問題点の一つに、mixed contents への対応がある。逆に mixed contents の発生を恐れ、HTTPS に移行できないサービスもあるだろう。本エントリでは mixed contents の正しい理解と、その検出や解消に利用できる可能性のある、CSP の Upgrade-Insecure-Request および、Block-All-Mixed-Contents を解説する。
2016 年を振り返る
tag:blog.jxck.io,2016:entry://2016-12-31
2016-12-31T00:00:00Z
例年通り、今年を振り返る。
HTTP の新しいステータスコード 103 Early Hints
tag:blog.jxck.io,2016:entry://2016-12-16
2016-12-16T00:00:00Z
これは、http2 Advent Calendar 2016 の 16 日目の記事である。HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。いったい何のために必要なのか、どういうメリットが考えられるかを解説する。
Foreign Fetch による Micro Service Workers
tag:blog.jxck.io,2016:entry://2016-12-12
2016-12-12T00:00:00Z
Service Worker に Foreign Fetch という機能が提案されている。この機能があるとクロスオリジンへの fetch をフックできる Service Worker を、その対象オリジンから提供できるようになる。一体どういう仕組みなのか、これによって何が可能になるのかについて、デモを交えて記す。
Link rel=serviceworker ヘッダによる API やアセットの Offline 対応
tag:blog.jxck.io,2016:entry://2016-12-11
2016-12-11T00:00:00Z
Service Worker を登録する方法は現状 3 つある。HTML meta タグでの追加ならば、Service Worker を追加するためだけの JS であれば不要になる。HTTP ヘッダでの追加ならば、HTML を持たない API にも Service Worker を追加した対応が可能である。次の記事で foreign fetch について解説する予定であるため、その前提知識として本機能を分離し紹介する。
Node v7 で入った WHATWG URL 実装について
tag:blog.jxck.io,2016:entry://2016-10-27
2016-10-27T00:00:00Z
Node v7.0.0 が公開され、今回のリリースで WHATWG URL の実装が Experimental として入った。既に標準で含まれていた url module との違いや、URL API などについて解説する。
Web 標準化のフィードバックサイクルを円滑にする Origin Trials について
tag:blog.jxck.io,2016:entry://2016-09-29
2016-09-29T00:00:00Z
ブラウザに追加される新しい機能に対して、Vender Prefix の代替となる Origin Trials の導入が徐々に始まっている。今回は、これまでの Vender Prefix の問題点と、代替として提案された Origin Trials のデザインや導入方法などについて記す。
Google Developer Experts (GDE) になりました
tag:blog.jxck.io,2016:entry://2016-08-30
2016-08-30T00:00:00Z
Google の中の人からお声がけ頂き、Google Developer Experts (GDE) に Web Technologies の Expert として Join することになりました。
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版
tag:blog.jxck.io,2016:entry://2016-08-22
2016-08-22T00:00:00Z
「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。これは、WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。WebSocket が出てきた当初と比べて、Web を取り巻く状況は変わったが、変わってないところもある。念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、ここで、もう一度現状について、把握している範囲で解説しておく。
SQL でファイル検索するコマンド selects を書いた話
tag:blog.jxck.io,2016:entry://2016-08-05
2016-08-05T00:00:00Z
UNIX コマンドを SQL で抽出できるツール qq を作った。 というエントリを読んで、そういえば似たようなものを作ってたなと思い出した。自分の dotfiles の中にある、便利コマンド集の中にある selects についてである。このコマンドは SQL という検索を記述的に表現する共通言語をファイル検索に応用し、Ruby の動的言語として表現力を使って実装したものといえる。その実装方法と実行例などについて記す。
Fetch での Stream を用いたプログレス取得とキャンセル
tag:blog.jxck.io,2016:entry://2016-07-21
2016-07-21T00:00:00Z
WHATWG が定義する Fetch API は、出たばかりの仕様では、途中でのキャンセルや、プログレスイベントの取得が含まれていなかった。しかし、後の更新で fetch 結果の Response Body が WHATWG Stream API を実装することになったため、現在の仕様ではプログレスを取ることもキャンセルをすることも可能となっている。今回は、こうした API のアップデートについて記す。
Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化
tag:blog.jxck.io,2016:entry://2016-07-12
2016-07-12T00:00:00Z
ブラウザはリロード時に、max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。このヘッダの効果と、本サイトへの適用について記す。
Intersection Observer を用いた要素出現検出の最適化
tag:blog.jxck.io,2016:entry://2016-06-25
2016-06-25T00:00:00Z
スクロールによる DOM 要素の出現などを効率よく検知するため、新しく Intersection Observer という API が追加された。この API の使い方と、本サイトへの適用について記す。
mozaic.fm の v2 のリリースと Podcast の実装と移行
tag:blog.jxck.io,2016:entry://2016-06-20
2016-06-20T00:00:00Z
mozaic.fm をリニューアルし、v2 としてリリースした。今回の更新のモチベーションは大きく分けて 2 つある。tumblr を捨てたかったfeedburner を捨てたかったこれによる breaking change 含む変更の内容と、実装のメモを記す。
リンクのへの rel=noopener 付与による Tabnabbing 対策
tag:blog.jxck.io,2016:entry://2016-06-12
2016-06-12T00:00:00Z
本サイト以下全ての target=_blank 付きのリンクに rel="noopener noreferrer" の付与を実施した。このプロパティの意味と、これが無い場合のフィッシング詐欺攻撃の可能性について解説する。
Passive Event Listeners によるスクロールの改善
tag:blog.jxck.io,2016:entry://2016-06-09
2016-06-09T00:00:00Z
DOM のイベントリスナの仕様に Passive Event Listeners というオプションが追加された。このオプションは、主にモバイルなどでのスクロールの詰まり(Scroll Junk) を解決するために導入されたものである。今回は、この仕様が解決する問題と、本サイトへの適用を解説する。Passive Event Listeners Spec
中級者向け Service Worker Tutorial
tag:blog.jxck.io,2016:entry://2016-04-24
2016-04-24T00:00:00Z
Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。しかし、Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。なお、Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。TODO になっている動画は、そのうち撮って追加します。
Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新
tag:blog.jxck.io,2016:entry://2016-04-16
2016-04-16T00:00:00Z
システムにおいてキャッシュの設計は永遠の課題であり、Web のパフォーマンスにおいても非常に重要である。Web では、HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。このヘッダの概要と、本サイトへの適用を解説する。
HTTP Strict Transport Security(HSTS) 対応
tag:blog.jxck.io,2016:entry://2016-04-11
2016-04-11T00:00:00Z
本サイトにて HTTP Strict Transport Security (HSTS) を有効化した。includeSubdomains を用いた *.jxck.io 全体への適用および、ブラウザへの Preload 登録も検討したが、本サイトの特性上それは見送った。導入に必要な設定や、注意点についてまとめる。
Public Key Pinning for HTTP(HPKP) 対応と report-uri.io でのレポート収集
tag:blog.jxck.io,2016:entry://2016-04-09
2016-04-09T00:00:00Z
本サイトにて Public Key Pinning for HTTP を有効化した。CSP 同様、まずは Report-Only を設定し、HPKP Report についても、report-uri.io を用いて収集することにした。導入に必要な設定や、注意点についてまとめる。なお、本サイトへの導入はあくまで 実験 である。運用や影響も踏まえると、一般サービスへの安易な導入は推奨しない。また、本来は HSTS と併用することが推奨されている。(必須ではない)そちらも追って対応する予定である。
Content Security Policy(CSP) 対応と report-uri.io でのレポート収集
tag:blog.jxck.io,2016:entry://2016-03-30
2016-03-30T00:00:00Z
本サイトにて Content Security Policy を有効化した。まずは Report Only にて導入し、段階的にポリシーとコンテンツを修正していく方針をとる。CSP Report については、report-uri.io を用いて収集することにした。導入に必要な設定や、注意点についてまとめる。
画像最適化戦略 SVG/Font 編
tag:blog.jxck.io,2016:entry://2016-03-27
2016-03-27T00:00:00Z
本サイトで使用している UI アイコン系の画像を、ギリギリまで最適化した手書き SVG に置き換えた(ただしソースは 観賞用 なので、インデントは残す)。また、装飾に画像ではなく CSS の contents を利用することで、ローカルフォントデータを利用し、画像転送を減らす工夫にも言及する。画像最適化シリーズ第 4 回目のエントリである。画像最適化戦略 PNG/JPEG 編画像最適化戦略 Picture 編画像最適化戦略 WebP 編> 画像最適化戦略 SVG/Font 編画像最適化戦略 Lazy Loading 編
画像最適化戦略 WebP 編
tag:blog.jxck.io,2016:entry://2016-03-26
2016-03-26T00:00:00Z
本サイトの PNG/JPEG で提供している画像については、よりサイズが小さくなりやすい WebP 形式を提供し、対応ブラウザに配布するようにした。フォーマットを出し分けるため、画像の指定は <picture> 要素を用いて対応した。画像最適化シリーズ第 3 回目のエントリである。画像最適化戦略 PNG/JPEG 編画像最適化戦略 Picture 編> 画像最適化戦略 WebP 編画像最適化戦略 SVG/Font 編画像最適化戦略 Lazy Loading 編
画像最適化戦略 Picture 編
tag:blog.jxck.io,2016:entry://2016-03-25
2016-03-25T00:00:00Z
本サイトで使用している PNG/JPEG 画像を、対応デバイスと、Device Pixel Ratio に対して最適なサイズで出し分けるために、<picture> 要素を適用した。画像最適化シリーズ第 2 回目のエントリである。画像最適化戦略 PNG/JPEG 編> 画像最適化戦略 Picture 編画像最適化戦略 WebP 編画像最適化戦略 SVG/Font 編画像最適化戦略 Lazy Loading 編
画像最適化戦略 PNG/JPEG 編
tag:blog.jxck.io,2016:entry://2016-03-24
2016-03-24T00:00:00Z
本サイトで使用している PNG/JPEG 画像に対し、メタデータ削除、減色、リサイズなど基本的な最適化処理の適用戦略と、その方法および結果について。画像最適化シリーズ第 1 回目のエントリである。> 画像最適化戦略 PNG/JPEG 編画像最適化戦略 Picture 編画像最適化戦略 WebP 編画像最適化戦略 SVG/Font 編画像最適化戦略 Lazy Loading 編
Noto Sans の Web Font 対応とサブセットによる最適化
tag:blog.jxck.io,2016:entry://2016-03-14
2016-03-14T00:00:00Z
このサイトのフォントに Web Font を適用することにした。フォントには Google と Adobe が協同で開発した Noto Sans CJK JP を採用した。また、このサイトでは使用しないだろう文字を削除したサブセットを作ることで、フォントサイズを最適化した。
Preload を用いたリソースプリローディングの最適化
tag:blog.jxck.io,2016:entry://2016-03-04
2016-03-04T00:00:00Z
Preload を指定する <link rel=preload> の仕様が公開されており、現在 Chrome Canary に実装されている。この仕様のモチベーションについて、Chrome 開発者の Yoav Weiss 氏のブログも公開された。今回は、この仕様の特徴と用途を解説し、本サイトへの適用について検討する。W3C Preload SpecIntent to Ship: <link rel=preload>Preload: What Is It Good For?
JSON-LD と Open Graph で構造化メタデータ対応
tag:blog.jxck.io,2016:entry://2016-02-26
2016-02-26T00:00:00Z
本サイトのメタ情報を整理するため、HTML のメタタグの整理、JSON-LD による schema.org 対応、Facebook, Twitter を主とした Open Graph 対応を実施した。これにより、既に AMP 対応していた本サイトが、Google のモバイル検索でキャッシュの対象となる(クロール待ち)。
zopfli で静的コンテンツの gzip 配信と Content/Transfer-Encoding について
tag:blog.jxck.io,2016:entry://2016-02-17
2016-02-17T00:00:00Z
HTTP では Accept-Encoding と Content-Encoding でのネゴシエーションにより、gz などで圧縮したコンテンツを転送することができる。本サイトでは zopfli を用いて gzip 形式の配信に対応した。
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について
tag:blog.jxck.io,2016:entry://2016-02-15
2016-02-15T00:00:00Z
Chrome が予定している <link rel=stylesheet> の挙動の変更について、Google Chrome チームの Jake が、興味深いブログを上げている。The future of loading CSSこの内容は、単に Chrome に対する変更だけではなく、HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。今回は、この内容を意訳+補足解説し、本サイトに適用していく。
Resource Hints API でリソースの投機的取得
tag:blog.jxck.io,2016:entry://2016-02-11
2016-02-11T00:00:00Z
Resource Hints とは現在提案されている以下のドラフトであり、ブラウザに「次に必要となるリソースを教える」ことで、投機的な取得を行う API 群である。https://w3c.github.io/resource-hints/主に以下がある。dns-prefetchpreconnectprefetchprerender今回は本サイトでこれを適用した話。
Atom の RSS Feed 対応
tag:blog.jxck.io,2016:entry://2016-02-09
2016-02-09T00:00:00Z
このブログの Atom feed を吐くようにした。右上の feed アイコン から登録できる。
h2o で https/2 のデプロイと設定
tag:blog.jxck.io,2016:entry://2016-02-08
2016-02-08T00:00:00Z
土台がだいたいできたので、このサイトを h2o にデプロイした話。
AMP HTML 対応
tag:blog.jxck.io,2016:entry://2016-02-01
2016-02-01T00:00:00Z
Google が推奨する仕様である AMP HTML に、このブログを対応した。言いたいことは色々あるが、とりあえず非常に難しかったため、その対応方法や感想などを残す。
HTML の省略によるサイズ最適化
tag:blog.jxck.io,2016:entry://2016-01-28
2016-01-28T00:00:00Z
本サイト blog.jxck.io 以下については、Markdown から静的ファイルを生成するスタイルで作成している。この変換時に以前から思っていた HTML の最適化 を実施することにした。しかし、md->html 変換時にそれをできるツールが見当たらないため、Markdown の AST から HTML を構築する過程で、省略を施すスクリプトを自作した。ただし、ソースはあくまで観賞用なので、インデントやコメントは残している。チューニングではなく単なる実験としてサイト全体にこれを適用し、その結果を記す。
Blog を移転しました
tag:blog.jxck.io,2016:entry://2016-01-27
2016-01-27T00:00:00Z
長いこと はてな blog をメインにし、他にも Qiita や Tumblr を使って色々書いて来たが、そろそろ自分のドメインに全部集約していこうかと思う。