Open UIによるWeb UI標準化への
アプローチ

ゆめみ×LayerX×サイボウズ3社合同フロントエンドカンファレンス北海道2024後夜祭＠東京
saku🌸 / @sakupi01

saku

🤗
Design Technologist / ex-Web Frontend @Cybozu
Goolgle Developer Expert for Web Technologies

🍏 / ☕ / 🌏 >

❤

🐦 @sakupi01
📝 blog.sakupi01.com
🐙 @sakupi01
🦋 @sakupi01.com

ブラウザネイティブUIの進化へ:

Open UIによるWeb UI標準化への
アプローチ

Available in EN

1. Open UIとは

Open UIの概要

  • W3C Community Groupの一つ

  • 一般的なUIパターンを体系化して汎用的なUIコンポーネントやコントロールを提案、その技術を標準化する提案に取り組んでいる

  • 独自UIを作るにはどうHTML, CSS, JS, Web APIを組み合わせるのが適切なのか決める

    • とはいえ、標準そのものの決定はしないと言ってる

  • 標準を決める具体的なグループ（WHATWG, CSSWG, TC39などなど）向けの推奨事項を作成する

  • 策定された仕様に基づいた内容を各ブラウザに実装（してもらう）

https://open-ui.org/

W3Cには他にもhogehogeみたいなコミュニティグループがある

コントロール： コントロールは、何らかの形でユーザーとのインタラクションを可能にするコンポーネントの一種。 コントロールには、定義された部分に対するエンドユーザーのインタラクションに基づいて、コンポーネントの状態やモデルの遷移を管理するコントローラコードがある。

複合コンポーネント: 多くの場合、他のコンポーネントを含むコンポーネントを作成する必要がある。たとえば、 コントロールは、通常、 コンポーネントと

Open UI発足の背景

  • WHATWGが、多くのWebサイトで見られる最も一般的なパターンをHTML自体で体系化する取り組みに着手（Web 2.0。2004年頃から）

    • その一環で、Web開発者がHTMLを使用するだけでリッチなformを実装できるように

  • その最後の大幅改定後、昨今のWebアプリケーションはより多くの複雑なIFを提供するように

  • 現代のWebアプリケーションに適合したWeb UIの一般的なパターンを提供するために必要な技術を新たに標準化しよう!

様々な独自手法が編み出される

Open UIがやること

  • 標準Webコンポーネント・コントロールの仕様検討＆提案

  • WHATWGやW3Cなどの標準化団体と協力し、HTML、ARIA、CSSなどに実際に仕様を追加

  • Chromium、WebKit、Geckoなどのブラウザエンジンチームと協力し、仕様に基づく機能をブラウザエンジンに実装

- アクセシビリティ, 国際化, プライバシー, セキュリティー, UX, デフォルトスタイル, デフォルトイベント, バリエーション

Open UIにおけるStages

Proposalの策定段階を5つのStageに分けている（Open UI Working Mode）

Stage 目的 入口基準 出口基準 Popover APIでの例
0: Research 調査内容を共有し、アイデアを統合できる状態にする Proposalが出され、Issueが開かれている Champion(そのテーマの責任者)が決まり、歴史的経緯の研究調査とProposalが2人のOpen UI EditorまたはChairによってApproveされる Research: popup and similar top-layer UI #345
1: Editor's Draft Open UI内でコンポーネントのExplainerに合意し、確定させる Usecase、Structure、Property、Behaviorなどをカバーする初期Draftが作成されている 仕様がOpen UI EditorまたはChairによってレビューおよびApproveされる New Approach for Popup #455
2: Community Draft ステークホルダー（WHATWG, ARIA, CSSWG, 他開発者など諸関係者）からのレビューを受け、フィードバックを取り入れる Open UIがEditor's Draftを外部グループや個人からの追加レビューのためにApproveしている ARIA、I18n、プライバシー、WHATWG、CSSWG、ブラウザ実装者、他Web開発者、Library Authorなどのステークホルダーからの承認 New feature proposal: Popover API #7785
3: Recommendation Proposalを最終状態に導く Championがステークホルダーと合意を形成している Web Platformに追加するかどうかの決定。Webコンポーネントが実装されたり、仕様が標準化団体に渡ったりする。適合度テストが行われ、Specが作成される。実装されるがまだExperimentalな状態。 Add popover attribute #8221
4: Finished コンポーネントが実装されたことを示す コンポーネントが安定した実装または仕様を持っている N/A Popover API lands in Baseline

StagesはTC39のStagesと同様の概念

実際、厳密にstage自体の運用はされてないみたいだけど、Open UIの提案がどんな流れでshipまで進むのかの指標として

2. Open UIのこれまでの取り組み

たくさんのコントロールやAPIが提案されていますが、ここでは実際にOpen UIの提案によって実現された/されなかったコントロールの例を見ていきます

実現された提案の例

e.g. Popover API（Baseline 2024 Newly available!）

  • 任意の要素にpopover属性を付与することで宣言的に Popover できる
    • 任意の要素をTopLayer に表示し、 Light Dismiss で閉じることもできる
    • 開閉がJSのみならずpopovertargetで実現可能に
<button popovertarget="mypopover">Toggle Popover</button>
<div id="mypopover" popover>This is the popover content</div>

Popover API (Explainer)

It’s difficult to track relative positioning because a popover is outside of the document flow. But there are use cases where we want to “anchor” our popup to another element, especially when you think about tooltips, alerts, etc… So how can we do this? → The anchoring API

実現されつつある提案の例

e.g. Customizable Select Element: <select>（Stage3）

  • 柔軟にカスタマイズ可能な<select>要素を提供予定

  • Customizable Select Elementの変遷

※ Chrome 129+ (Canary) の Experimental Web Platform features を有効にすることで利用可能（demo by @una）

Customizable Select Element (Explainer)

現状の``を実装する必要がある ネイティブのフォームコントロールと比較してパフォーマンス、アクセシビリティなどの観点で劣る

=== 現状のSelectからの改良点: 1. カスタマイズ可能性 2. 任意のコンテンツを埋め込める 3. 選択オプション 4. カスタマイズ可能なボタン 5. カスタマイズ可能なオプション 6. カスタマイズ可能なデータリスト ===

listboxはスタイル可能な要素を拡張することで、HTMLの一貫性を保ったままにできる

大規模なHTMLパーサの変更が必要でshipに時間がかかりそう： 要素に対してappearance:noneを使用することで、スタイルのカスタマイズが可能になる。さらに、appearance:baseのような新しい値を追加することで、開発者がより簡単にスタイルを適用できるようにする。また、スタイリングの柔軟性を持たせるために、要素のパーサーを変更し、新しい子要素（例：

実現されなかった提案の例

e.g. <skeleton>要素/skeleton ARIA role

  • Skeletonのコンポーネント化/ARIA roleの提案が存在していたが見送られた

    • お見送り理由①: SkeletonはUIパターンではなく、UXパターン

    • お見送り理由②: 多様なUI要素に適用可能であり、一般化されたUIとして定義するのに適さない

    • → skeletonを表現するARIA roleの提案（Skeleton Aria Role #169）

    • お見送り理由③: 既存のARIA属性（aria-busy、aria-live、aria-hidden）で十分に対応可能であり、新しいARIA roleを追加することで開発者やユーザーに学習負担を強いる（[OPEN UI] Skeleton aria role proposal #1317）

marked as stale - [Skeleton] Add component proposal #139

3. まとめ

  • Open UIは、標準Webコンポーネント/コントロールの仕様検討＆提案を行っている
  • Popover APIやCustomizable Select ElementなどはOpen UIの提案によって実現された（つつある）新しいコントロールたち！
  • 独自のデザインシステムを構築するときにも役立つ内容の提案がたくさん！
  • これからのWeb UIを決定づける提案がまだまだたくさんあって、目が離せない✨

ご清聴ありがとうございました！