サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「かわいい」
blog.jxck.io
Intro ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。 あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。 また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意 Tooltip 今回は、 Menu の実装を考えてみる。 GitHub でいうとこの部分だ。 元となるボタンによって表示され、このボタンからの相対位置で調整されるため Anchor Positioning を活用することになる。非常に良くある実装パターンだ。 HTML の仕様にも、類似の実装が Example として掲載されている。 6.12 The popover attribute https://html.spec.whatwg.org/multipage/popover.html#the-popover-attrib
Intro ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。 あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。 また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意 Toast 次は、 Popover の源流にもなった、画面端にメッセージを表示するいわゆる Toast UI について考えてみる。想定するのは以下のようなものだ。 メッセージの性質によって、色やアイコンのスタイルを変えられ、同時に複数積み上げて表示できるといった仕様が一般的だ。 HTML 基本は <div popover> となる。また、複数のメッセージがあった場合に、他のが表示されても消えないよう、 manual を指定する。 <div popover="manual"> </div> もし内容のレイアウトで Flex や
Intro ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。 あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。 また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意 Cookie バナー 次は、「Cookie 利用への同意」いわゆる Cookie バナーの UI について考えてみる。想定するのは以下のようなものだ。 前回の規約への同意と異なり、このバナーは画面表示時から右下に表示され、同意か拒否を選択するまで表示し続ける。つまり、表示中は他の操作をブロックしたりはしない。 つまり Dialog ではあるが Modal ではないため、 show() する前提で実装を考えていく。 HTML HTML の注意点は、前回の規約と大きくは変わらない。 まず、最初から表示しておくため open 属性
Intro ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。 あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。 また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意 規約への同意 まずは、「規約への同意」の UI について考えてみる。想定するのは以下のようなものだ。 見ての通り、この規約に同意しないと先に進むことができない、ブロックを伴う UI であるため Modal Dialog として実装するのが妥当だろう。 どのようなきっかけで表示されるかはわからないため、 JS から showModal() する前提で実装を考えていく。 HTML まず、基本的な HTML 要素を並べてみよう。(<dialog> と関係ない部分は簡略化) 要件はいろいろあるだろうが、最低限以下の 2 つを必須とす
Intro ついに <toast> -> <popup> -> popup -> popover として、要素から属性になり名前も決まった。 とはいえ実装は popup とそんなに変わらないので、 popup でやっていた Origin Trials を継続しながら、徐々に実装を進めていくフェーズが 2022/12 くらいの話だ。 Intent to extend Origin Trial: Popover API https://groups.google.com/a/chromium.org/g/blink-dev/c/kZXexHhH7EA/m/UmQYwGW3DAAJ しかし、 popover を実用するには足りていない議論があった、それが Animation だ。 Display and content-visibility animations <dialog> や popov
Intro このあたりから、まだ議論中の話が多いため、今後変わる可能性が高い点に注意。 popup が紆余曲折を経て popover 属性になり、 2023/3 に Safari が TP166 で実装した。そのまま Safari 17 に入ることを 2023/6 の WWDC で発表したあたりから、 popover の実装は各ブラウザで一気に話が進む。 Release Notes for Safari Technology Preview 166 https://webkit.org/blog/13964/release-notes-for-safari-technology-preview-166/ News from WWDC23: WebKit Features in Safari 17 beta https://webkit.org/blog/14205/news-from-ww
Intro ここまでで <dialog> 要素が標準化され、 Modal/non-Modal な Dialog がネイティブで出せるようになった。 今まで自前で実装していた z-index の指定や、フォーカスの管理、非活性化、キーボードでの処理、スタイルなども、細かい仕様がほぼ標準によってカバーされた。 Top Layer inert :modal / ::backdrop CloseWatcher Focusable Scrollers etc しかし、 <dialog> はあくまで「ユーザのインタラクションを求める」という用途で使うものであり、 role=dialog ではない、例えばちょっとしたメッセージの通知などに使うものではない。 そこで、これらの資産を活用し、より汎用的な UI を標準化しようという話が、 <dialog> の標準化の裏で並行して行われた。 Toast 最初の
Intro 前回までは <dialog> が標準化されるまでの経緯と、 API の概要や関連仕様を解説した。 今回は <dialog> の API としての使い方について、具体的に解説していく。 各要素の使用 open 属性 <dialog> は、デフォルトでは不可視(display: none)な要素となっている。 open 属性が付くと表示される。 <dialog open> <div> <h1>Hello Dialog</h1> </div> </dialog> show()/showModal() しかし、基本的に <dialog> は動的に出てくるため、JS で開くことになるだろう。しかし、 open 属性を動的に付けるのではなく、 show()/showModal() を用いるのが基本だ。 document.querySelector("button.show").addEve
Intro showModalDialog() は今から考えれば、確かにひどい API だった。 しかし、何か Modal を開き、ユーザにインタラクションをさせ、閉じたらそこで入力された値や選択された結果を取得し、処理を進めたいユースケース自体は、規約への同意取得や、 Cookie バナー、ログインなど多々ある。 そういった場面では、ライブラリなどを用いて実装する必要があったが、 Modal を実装するのは実際にはそんなに簡単ではなかった。 Modal, Dialog, Modal Dialog 最初に、用語を少し整理しておこう。 Modal Dialog Modal Dialog non-Modal Dialog Dialog とは、そもそも「対話」という意味であり、 UI の文脈では入力や選択を求める「対話的な UI」のことを指す。 既に実装されている alert(), confir
Intro HTML の <dialog> 要素と、 popover 属性、および関連する様々な仕様が標準化され、実装が進められている。 Open UI を中心に進められているこれらの改善は、多くのサイトで共通したユースケースがありながら、長らくミッシングピースとなっていた重要な機能だ。 もし今、同等のユースケースを自前で実装しているのであれば、適切な仕様を用いた実装に刷新することで、従来はほぼ不可能だった UX を提供できるようになる。 今回から、数回の連載形式で、これらの仕様がどのように標準化され、我々開発者はこれをどのように使っていくべきなのかについて解説する。 showModalDialog Modal や Dialog と言われる UI の歴史は Web においても古く、ブラウザでは IE4 くらいのころに独自実装された window.showModalDialog() が最初に
Intro 2024/9/7 に、 Web Developer Conference を開催した。 Web Developer Conference 2024 開催告知 #wdc2024 | blog.jxck.io https://blog.jxck.io/entries/2024-06-12/web-dev-conf-2024.html Connpass https://web-study.connpass.com/event/321711/ Togetter https://togetter.com/li/2430964 WDC2024 「Web 開発に関わることならなんでも可」という 40 分セッションと、「1 人 1 分 1 枚で Web 標準を紹介する」という 1 分 LT のカンファレンスとして開催した。 それ以外の余計なことを全くしない、いつも通りの省力開催で行った。 配信
Intro このエントリは、 3rd Party Cookie Advent Calendar の 29 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 先日、 Google より Privacy Sandbox の方針転換について発表があった。 本当は、まだ記事を書くには情報が足りていないため、あまり書く気はなかったが、今後出てくる発表に備えて経緯をまとめるために、「何がまだ分かっていないか」の現状を書いておくことにする。 Privacy Sandbox の方針転換 問題の記事は 2024/07/22 に公開された以下だ。 A new path for Privacy Sandbox on the we
Intro Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。 ブラウザエンジンとは ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。 ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。 ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。 その上に、例えばタブ
Intro 9/7 開催予定の Web Developer Conference 2024 では、 「1 分 de Web 標準」という LT 大会を予定しています。 CFP も募集中ですが、(筆者の周り以外では)聞き馴染みのないやり方だと思うので、この LT のやり方を解説します。 プロポーザル | Web Developer Conference 2024 - fortee.jp https://fortee.jp/web-dev-conf-2024/proposal/all 1 分 de Web 標準 「Web 標準」な何らかのトピックについて、 1 人 1 ページ 1 分で LT するというものです。 Slide スライドはこちらで用意する Google Slides を共有し、そこに割り当てられた 1 ページのみを使えます。 その 1 ページは、マスターで振るページ番号以外は、ど
Intro Chrome 126 で筆者が実装した URL.parse が Ship された。 Chromium にコントリビュートしたことは何回かあったが、単体機能を Ship したのは初めてだった。 invalid URL の処理 new URL() によって、文字列の URL をパースすることができるようになって久しいが、この API は invalid な場合に例外を投げる。 例外処理をするよりも、先に URL としてパース可能かどうかを知るための URL.canParse() が提案され、先に実装が進んだ。 URL.canParse(str) // boolean しかし、これでは二回パースが必要になるため無駄が多い。 if (URL.canParse(str)) { // 1 回目のパース return new URL(str) // 2 回目のパース } そこで、失敗したら
CFP CFP の募集には fortee を使ってみようと思います。まだ慣れてないので色々と失敗すると思いますが、多めにみてください。(参加募集は fortee ではなく、慣れてる connpass を使う予定です) また、採択は fortee のプロポーサルのスターを第一基準にするので、聞きたいのはスターしてください。(なので、多分応募は早い方が有利です) プロポーザル | Web Developer Conference 2024 - fortee.jp https://fortee.jp/web-dev-conf-2024/proposal/all 募集は Session と LT の 2 枠です。 Session 40 分枠 x 12 Web 開発に関わることならなんでも可 終わったら感想戦会場に移動、そこで QA CFP を Fortee で募集 基本は Fortee のスター数
Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛
Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
Intro Chromium にコントリビュートするためには、ソースコードを理解する以外にも、もろもろ必要な周辺知識がある。 ドキュメントはかなり整備されている方ではあるが、そのドキュメントにたどり着くのが難しい場合もある。 レビュアーなどが親切に教えてくれるものをローカルにメモしているが、それも散らばってきたため、ここにまとめることにする。 まずは初期状態で公開するが、どんどん更新していき、長くなっても分割しないで追記を繰り返そうと考えている。 関連サイト 始めて取り組もうとすると、まずどこを見ればわからないところから始まる。 似たようないくつかのサイトがあり、使い分けがされているからだ。 code search https://source.chromium.org/chromium/chromium/src コードをインタラクティブに検索するためのサイト Workspace 風の U
Intro 2014 年 3 月に開始した mozaic.fm が、気づいたら 10 周年を迎えた。 これを機に、 10 周年記念イベントとして、初のオフラインイベントをゲンロンカフェで開催した。 Podcast でのみ告知し、当日まで情報制限をかけていたにもかかわらず、チケットもグッズも無事完売することができた。 イベントを振り返りつつログを残す。 10 周年記念イベント mozaic.fm は 2014 年 3 月に配信を開始したが、これまで一度もイベントのようなことをやってこなかった。 2022 年 8 月の ep100 を記念して、一度くらいはオフラインイベントをやってみるかという計画があったが、コロナ禍であったためキャンセルになった。 今回は、そのリベンジも兼ね、リスナーのみに向けたイベントとして開催した。 当日の模様は録音し、一部を mozaic.fm で公開している。 ep1
Intro Promise.withResolvers() は、 Stage 4 であり ES2024 の候補となった。 すでにブラウザでの実装も進んでいるため、その活用方法を解説する。 イベントの Promise 化 JS では、非同期処理 API は長らくイベントリスナベースで定義され、それを組み合わせるフロー制御で処理されてきた。 しかし、 Promise が定義されて以降は、標準 API も Promise を返すようになり、 async/await によって処理されるのが一般的になってきた。 結果、イベントリスナベースの API を Promise 化するような場面も増えた。 例えば以下のようなものだ。 async function request() { return new Promise((resolve, reject) => { document.querySelect
Intro TC39 の Stage 2 と Stage 3 の間に、新たに Stage 2.7 が追加された。 これは何だろうと思った人が検索で辿り着けるよう、その経緯と目的をまとめる。 TC39 Stages TC39 は、 ECMAScript (つまりまあ JS) の新機能を議論する Task Group だ。 ここでは、比較的自由に新機能の提案がなされ、定期的に行われるミーティングでの議論や、実装からのフィードバックを経て、 Stage が上がっていく仕組みをとっている。 旧来の Stage は 0~4 まであった。ざっくり言うと以下のようなものだ。
Intro 以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。 Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。 筆者が公開情報を読んで解釈したものなので、内容は保証しない。 前提 iOS/iPadOS に入れられるブラウザには、 WebKit を用いる必要が
Intro 2023 年の Web 技術を振り返る試験として、「Web 技術年末試験 2023」を実施した。 その問題と想定解答、平均点などを公開する。 Web 技術年末試験 この試験は、「去年の Web にはどんな変化があったか」「どんな新しい技術が出てきたか」などを、試験形式で振り返るコンテンツを作ってみたことに端を発している。 2022 年はこれを狭い範囲で実施したが、思った以上に評判が良かったため、2023 年は受験者を一般募集してみることにした。 試験形式であるため点数は出るが、目的は「今年はこんなことがあった」を振り返ることや、「こんなことがあったのは知らなかった」という取りこぼしに気づく機会になることである。 解答用紙/想定回答 [解答用紙]: Web 技術年末試験 2023 https://docs.google.com/document/d/1jdN0NsM-PAnYRl
Intro 例年通り 2023 年を振り返る。 blog 今年書いたのは全部で 43 本。今年はアドベントカレンダーを一人でやったため、過去最高のエントリ数になった。 Entry ブログは 15 本書いた。 2023-01-07: 次世代 CSS 仕様が与えるコンポーネント時代の Web への影響 2023-02-28: 誇りを被った仕様の針に意図を通す 2023-03-24: OpenAI API を用いた文書校正(誤字脱字検出) 2023-05-02: 技術書籍をシンタックスハイライトする話 2023-05-17: IETF RFC における ABNF と Parsing Algorithm の関係 2023-05-28: URL バーの表示の変遷 2023-06-01: AbortSignal.any(), AbortSignal.timeout(), そして addEvnetLis
Intro このエントリは、 3rd Party Cookie Advent Calendar の最終日である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie ここまで、 3rd Party Cookie との 30 年に渡る戦いと、 ITP 以降それが Deprecation されるに至った流れ、そして Privacy Sandbox の API について解説してきた。 最終日は、ここまでを踏まえて、来年以降の Web がどうなっていくのかを考えていく。 「Web 史上最大の破壊的変更」の意味 筆者はこのアドベントカレンダーの最初に、これを「Web 史上最大の破壊的変更」と言って始めた。 Web で破壊的変更と言え
Intro このエントリは、 3rd Party Cookie Advent Calendar の 27 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今日は、散々壊れるユースケースとして解説してきた「認証連携」をカバーする FedCM について解説する。 Federated Credential Management 認証連携 あるサイト(RP)の認証を別のサイト(IDP)の認証で行いたい場合、両者の連携は 3rd Party Cookie で行われてきた。 例えば、 RP に IDP を <iframe> で埋め込み、 IDP に対するログイン済みの Cookie があれば、その情報を JS で R
次のページ
このページを最初にブックマークしてみませんか?
『Index | blog.jxck.io』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く