Web Components 元年 v6

meguro.es #29

saku🌸 / @sakupi01

Web Components 元年 v6

2024~2025

Implementations

Declarative Shadow DOM

• 🔥 2024 Newly Available: DSD（Declarative Shadow DOM）
  • Shadow DOMをDeclarativeに作成できるようになった
  • SSR対応へ一歩前進した
• 2024 Newly Available: setHTMLUnsafe, parseHTMLUnsafe
  • 動的にDSDを追加するためのメソッドも生えた

<host-element>
  <template shadowrootmode="open">
    <slot></slot>
  </template>
  <h2>Light content</h2>
</host-element>

Scoped Custom Registries

• 🔥 Prototype: Scoped Custom Registries（Gecko）
  • Shadow RootごとにCustomElementRegistryを持てるように
  • 3rd party製CEとの競合を防ぐ
  • Chromium, WebKitは実装済み

import {OtherElement} from './my-element.js';
// CustomElementRegistry instanceを生成してCEを登録
const registry = new CustomElementRegistry();
registry.define('other-element', OtherElement);
export class MyElement extends HTMLElement {
  constructor() {
    this.attachShadow({mode: 'open', registry});
  }
}

Reference Target for Cross-root ARIA

• 🔥 Experiment: Reference Target for Cross-root ARIA
  • IDREF-IDの参照関係を、Shadow DOMのカプセル化を保ちつつできるように
    • 今までShadow DOMに対してARIA Linkを作れなかった
  • Light DOMとShadow DOM間でARIAが動作するように

<input
  role="combobox"
  aria-controls="fancy-listbox"
  aria-activedescendant="fancy-listbox" />
<fancy-listbox id="fancy-listbox">
  <template
    shadowrootmode="open"
    shadowrootreferencetarget="real-listbox"
    shadowrootreferencetargetmap="aria-activedescendant: option-2"
>
    <div id="real-listbox" role="listbox">
      <div id="option-1" role="option">Option 1</div>
      <div id="option-2" role="option">Option 2</div>
    </div>
  </template>
</fancy-listbox>

Others

• Ship: :has-slotted
  • <slot>がslotされた要素を持っているかどうかを判定するセレクタ
• 🔥 Prototype: ShadowRealm
  • 隔離された独自グローバルが作成可能に

Hot Topics & Discussions

Shadow RootへCSSをDeclarativeにimportしたい①

• 🔥 Declarative CSS Module Scripts
  • JSランドでは（Constructable StyleSheet＋CSS import assertion + adoptedStyleSheets）の合わせ技があるけど、それをDeclarativeにやる方法が欲しい！せっかくDSDできるようになったんだし！

<script type="css-module" specifier="/foo.css">
  #content {
    color: red;
  }
</script>
<script type="css-module" specifier="/bar.css">
  #content {
    font-family: sans-serif;
  }
</script>
<my-element>
  
  <template shadowrootmode="open" adoptedstylesheets="/foo.css, /bar.css">
    
  </template>
</my-element>

Shadow RootへCSSをDeclarativeにimportしたい②

• 🔥 @sheet
  • 複数のStyleSheetをまとめて一つにする方法がほしい（ネイティブバンドル）
  • ついでにStyleSheet毎に読み込めるメカニズムもつけて

@sheet foo {
  div {
    color: red;
  }
}

@sheet bar {
  div {
    font-family: sans-serif;
  }
}

div {
  color: blue;
}

<template shadowrootmode="open">
  <style>
    /* The following two imports should only make a single network request. */
    @import "sheet.css#foo";
    @import "sheet.css#bar";
  </style>
  
</template>

HTMLをimportできるようにしたい

• 🔥 HTML Module Scripts
  • HTML Importsはダメだったけど、HTMLをimportできる仕組みは引き続き欲しい
  • これが来ると、Import Attributes風にHTMLをimportできるようになる
  • 部分的なDeclarative Custom Elementsも可能になる?
  • Declarative CSS Module Scriptsが実現すれば、それの手法を活用して、HMTL Module ScriptsもDeclarativeにできるかも?(ref)

- JSON Module ScriptsはInterop 2025 Focus Areasのひとつ

ビルトイン要素の拡張がしたい

• 🔥 Extendable built-in elements
  • is is GONE.
  • CEでビルトイン要素を拡張可能にする仕組みが欲しい！
    • Proposal: Custom attributes for all elements, enhancements for more complex use cases
    • Extend popovertarget to support custom elements · Issue
    • Proposal: Customized built-in elements via elementInternals.type

Ecosystems & Concept Shifts

Ecosystems & Concept Shifts

The Open UI Design System by Open UIとWeb Components

• 2024/01; A Global Design Systemという概念がBrad Frostにより提唱される
• 2024/03; Bradが、Global Design Systemの概念を、Open UIのChairであるGregらに持ちかける
  • A design system, component library for the web? · Issue #1017 · openui/open-ui
• 2024/11; openui/design-systemが発足する
  • 「WCs製のコンポーネントライブラリ」を成果物の一つとして提供
• ~ Current;
  • 2025 1Qまでに複数コンポーネントをShipすることを目指している。最初はbadge.
    • for more: MVP list of components
  • コンポーネントライブラリがターゲットとするブラウザバージョン（Baseline）決め
    • What's the target browser support?
  • etc, etc...

The Open UI Design System by Open UIとWeb Components

• W3Cのイチ組織で検討された、堅牢で柔軟なWCsライブラリを提供
• 競合する標準の作成はしない
• HTMLと各デザインシステムとのギャップを補完する新しいレイヤーとなる
  • 組織のデザインシステムやOSSのデザインシステムでもなければ、Headless UIと重複するものでもない
• HTMLの拡張レイヤー的な位置付け

🎄Open UI Advent Calendar: Day 23 / Global Design System Part1, 🎄Open UI Advent Calendar: Day 24 / Global Design System Part2

Web Awesome by Font AwesomeとWeb Components

• 2024/04; Web Awesome
  • ShoelaceというFont Awesome製のWeb Componentsライブラリの後継が立ち上がる
• 2024/09; TAGのLea Verou, 11tyのZach Leathermanが参画
  • 標準側へのエスカレーションやOSS/リアルワールドユーザからのFBを発展させる体制が整っていそう
• 現状OSSではなく、ソースコードを公開しない営利目的のプロジェクト
  • W3C管轄で非営利のThe Open UI Design Systemとの明確な差分の一つ
• W3Cじゃないけど、The Open UI Design Systemと似たような思想で似たようなことをやっていきそう
  • The Open UI Design Systemとの連携は？
  • 開発速度や認知でOpen UIとどう変わってくるのか？
  • そもそも目指すところの差分はあるのか？
• 2025年初頭にローンチ予定

Ecosystems & Concept Shifts

1. WCs primarily benefit from
Generalizable Elements

... because they're interoperable and painful.

• 一般性とWCsの旨みは比例。WCsを使うのは簡単だが、作るのは簡単じゃない
  • 技術的にはもちろんだが、一般性が増すほど厳格なSpecやテストが必要になる
• 消費者が多い一般性の高い要素に対するWCsの作成は、トレードオフとして許容範囲
  • WCs消費者が作成者の量を凌駕する場合、WCsが効果的に使われているとも言える
• 極端な例だと、ネイティブ要素がC++で実装されてても誰も何も言わない

• それならブラウザネイティブ要素にしてしまえばいいのでは？
  • 標準化は意図して低速
    • Selectの拡張に「5年」かかった。拡張したい要素はまだまだある
  • 標準化前段で高速なイテレーションを回すレイヤーが必要
    • それが発展して標準化に貢献できる可能性もある
  • そのレイヤー（Generalizable Elements）にこそ、WCsが使われるべき

→ リソースが無限にあるなら、HTML要素として存在しても問題ない要素に対してWCsは効果的

2. Web Components don’t do everything Framework Components do

... so, stop fighting each other and comparing!

Frameworks vs Web Components ... なのか？

• エコシステム(FW)は新しい方法論をtry-and-errorする場。FWが標準の進化を促進してきた場面も多い
  • jQuery→document.querySelector()、SaSS→CSS Custom Properties、JSX→Tagged template literals、Preact→Signals
• Component-Based Frameworks→WCs
• WCsはFWが担うこと全てをやるわけではない&標準がエコシステム（try-and-errorの場）のやること全てを担うことは不可能。WCsはFWからの移行先ではない
  • importしてきたものを、templateで複製し、SDをattachして、CEとしてdefineしたものを使い回す以上のことをFWはやる
  • WCsはその過程を手助けする手法を提供する
  • なので、FWとWCsは互いに補完し合う関係にあるべき
• ただ、FWがWCsと互換性があるわけではない
  • FWは元からWebの機能に追従できるように設計されているとは限らない
• エコシステムと標準は 逆らう 手を取り合うことで前に進んできた。WCsに至ってもそうあるべき
  • Support For Custom Elements – React v19

→ WCsはReactでもなければ、Svelteでもなく、Vueのコンポーネントでもない。

JSX vs Web Components ... なのか？

• JSXの解決したいこととWCsの解決したいことは根本的に違う
  • WCs: 十分にGeneralで、消費者 >>> 作成者 になるコンポーネント/要素に対して効力がある
  • JSX: WCsがカバーしない領域で、（WCsを利用しつつ）機能する
  • WCsを用いて開発することは頻繁に起こり得るが、WCsを開発することは一部に限定されていて良い
  • 「JSX over WCs || WCs over JSX」ではなく、 「WCs in JSX」という構図が望ましい

→ WCsはJSXの代替にならない/なることを意図されてデザインされていないし、その逆も然り

Wrap Up

2024年のWeb Componentsの評価

今年の評価ですが、

• 低レベルAPIを揃える議論で大きな進捗を見せることができました
  • まだまだ「difficult→easy」ではなく、WCsの利用を「impossible→possible」にする機能をそろえる段階
• これまでに例を見なかった、WCsを取り巻く環境の変化を見ることができました
  • Open UI, Web Awesomeなど
  • そこから浮き彫りになる、WCsの概念やユースケースの確立

2025年のWeb Componentsに期待すること

• 引き続き、低レベルAPIの整備を頑張ってほしいです
  • リアクティブなTemplatingの進捗に期待
    • DOM Parts, JavaScript templating API
  • 外部からスタイルを適用可能にするオプションがあると、WCsの利用範囲がもっと広がりそう
    • open-stylable, ::theme, exposing shadow tree
  • そうしてやっと、FWのコンパイルターゲットになり得る未来が見える
• WCsを取り巻くエコシステムが標準化にどう拍車をかけるのか、WCsのユースケースやカバー領域がどう定義づけられていくのか

来年は元年v1（2016）から10年

Appendix

• 2024 TPAC planning · Issue #1065 · WICG/webcomponents
• 2025 Q1 Face-to-face · Issue #1083 · WICG/webcomponents
• Declarative CSS Module Scripts · Issue #939 · WICG/webcomponents
• What’s Next for a Global Design System | Brad Frost
• The Future of Shoelace
• Making the Web more Awesome — for everyone • Lea Verou
• 11ty is joining Font Awesome — Eleventy
• Web Components Are Not the Future
• Web Components Are Not the Future — They’re the Present
• React v19 – React
• How Microsoft Edge Is Replacing React With Web Components - The New Stack