Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Shadow DOMとCSSの現状
Search
uhyo
February 27, 2024
Technology
11
8.2k
Shadow DOMとCSSの現状
2024-02-27 DOMDOMトークス #1
uhyo
February 27, 2024
Tweet
Share
More Decks by uhyo
See All by uhyo
意外と難しいGraphQLのスカラー型
uhyo
5
640
RSCの時代にReactとフレームワークの境界を探る
uhyo
12
3.9k
知られざるprops命名の慣習 アクション編
uhyo
12
3.1k
libsyncrpcってなに?
uhyo
0
690
Next.jsと状態管理のプラクティス
uhyo
7
13k
10ヶ月かけてstyled-components v4からv5にアップデートした話
uhyo
5
650
更新系と状態
uhyo
9
3.8k
React 19アップデートのために必要なこと
uhyo
8
2.7k
color-scheme: light dark; を完全に理解する
uhyo
8
730
Other Decks in Technology
See All in Technology
AI ReadyなData PlatformとしてのAutonomous Databaseアップデート
oracle4engineer
PRO
0
170
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
3
330
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
0
250
GA technologiesでのAI-Readyの取り組み@DataOps Night
yuto16
0
260
多様な事業ドメインのクリエイターへ 価値を届けるための営みについて
massyuu
0
110
Shirankedo NOCで見えてきたeduroam/OpenRoaming運用ノウハウと課題 - BAKUCHIKU BANBAN #2
marokiki
0
130
組織観点からIAM Identity CenterとIAMの設計を考える
nrinetcom
PRO
1
170
Where will it converge?
ibknadedeji
0
170
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
250
関係性が駆動するアジャイル──GPTに人格を与えたら、対話を通してふりかえりを習慣化できた話
mhlyc
0
130
VCC 2025 Write-up
bata_24
0
180
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
The Language of Interfaces
destraynor
162
25k
Docker and Python
trallard
46
3.6k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Transcript
Shadow DOMとCSSの現状 2024-02-27 DOMDOMトークス #1
発表者紹介 uhyo 株式会社カオナビ フロントエンドエンジニア 普段はTypeScriptとかReactをやっている。 好きなDOM仕様はDOM3 Load & Save (昔のOperaにだけ実装されてたやつ)
最近のDOMDOMニュース 2024年2⽉、Firefox 123がリリース。 Declarative Shadow DOMのサポートが追加され、 すべてのモダンブラウザでサポートが完了。
Declarative Shadow DOM復習 従来はJavaScriptのElement#attachShadowを 使わなければshadow rootを⽣成できなかった。 template要素のshadowrootmode属性を使うこと で、HTMLだけでshadow rootを⽣成できる。
Declarative Shadow DOM復習
DOMDOMクイズ こうするとshadow root を⽣成できる? (JSでtemplate要素を⽣ 成してdivに追加)
DOMDOMクイズ 答え: できない 理由: Declarative Shadow Root はHTMLパーサーの機能だから (どういう意味か調べてみよう!) ※innerHTMLとかでパーサーを起動してもできない
(allowDeclarativeShadowRootsフラグで制御されているため)
Shadow DOMとCSS Shadow DOMの⽤途はいろいろあるが、個⼈的に はCSSのスコーピングを重要視。 •Shadow DOMの外で宣⾔されたスタイルは 中の要素に適⽤されない •逆も同様 (::partの話は今⽇は省略)
CSSのスコーピング Shadow Treeの中に適⽤ されるスタイルは同じ Shadow Treeの中で宣⾔する 必要がある。 利点: spanみたいな セレクタを雑に使える
(クラス名とかに頼る機会が減る)
@scopeとの⽐較 CSS Cascading and Inheritance Level 6で定義さ れた@scopeもスコーピングができる。 上限と下限を指定できる。
@scopeとの⽐較 (1) UIライブラリと組み合わせる場合、 @scopeだと下限の設定に難がある。 children内にはスタイルを適⽤ したくない場合はどうすれば…… (Reactの例)
@scopeとの⽐較 (1) Shadow DOMはこのようなケースが得意。 Shadow tree内のstyleで宣⾔ されたスタイルは<slot>に 当てはめられたツリーには 適⽤されない
@scopeとの⽐較 (2) 親から .parent-component > div > div > button
みたいなセレクタで攻撃された場合…… @scope: 防御できない Shadow DOM: 防御できる 「やろうと思えばできちゃう」を防げるのは優秀。
余談: 昔作ったやつ これからのCSS in JSはShadow DOM ベースに違いない!! と思い、 2020年に作ったCSS in
JSライブラリ (もちろん流⾏らず) https://github.com/uhyo/castella
余談:昔作ったやつ CSSはマークアップと密結合している という考えから、HTMLとCSSのセッ トで1つのコンポーネントを定義。 HTMLはShadow DOMに⼊る。 (これがあるべき姿では? とはずっと思っている)
問題: リセットCSS 最近はリセットCSSを使うことが多い。 Shadow DOMの中にリセットCSSを適⽤するため には、Shadow DOMの中から読み込む必要がある。
問題: リセットCSS これコンポーネントごと に読み込んで⼤丈夫なの?
実際にやってみた 複数のshadow treeの中から <link rel=“stylesheet” href=“reset.css”> でCSSファイルを読み込む場合と読み込まない 場合で、ページのメモリ使⽤量の差を計測。 ブラウザ: Firefox
123.0, Google Chrome 121.0.6167.185 ソースコード: https://github.com/uhyo/domdom-talks-1
実際にやってみた 0 50 100 150 200 250 10000 20000 30000
40000 50000 メモリ増加量 (MB) コンポーネント数 <link> (Firefox) <link> (Chrome) +33% +74〜132%
実際にやってみた 0 50 100 150 200 250 10000 20000 30000
40000 50000 メモリ増加量 (MB) コンポーネント数 <link> (Firefox) <link> (Chrome) <link>の量に対して線型にメモリ使⽤量 が増加、割合としては⼀定に +33% +74〜132%
グラフの注意点 Google Chromeのメモリ使⽤量は計測しても全然安定 しなかったので参考記録です。 Firefoxの+33%という数字はlink要素の追加以外にも CSS量の増加による影響をすべて含んだものです。
オーバーヘッドが⼤きい…… 同じリセットCSSを全部のコンポーネントに適⽤ したいだけなのに、コンポーネントの数が増える ほどメモリ使⽤量も増えるのは嬉しくない。 (コンポーネント数に⽐例するオーバーヘッドはある程度は 避けられないが) ※ reset.cssにリクエストが⾶ぶのはさすがに1回
救世主!? adoptedStyleSheets adoptedStyleSheetsを使うことで、複数の shadow tree間で同じCSSStyleSheet インスタンスを共有することができる。
adoptedStyleSheetsのメモリ使⽤量 0 50 100 150 200 250 10000 20000 30000
40000 50000 メモリ増加量 (MB) コンポーネント数 <link> (Firefox) <link> (Chrome) adoptedStyleSheets (Firefox) adoptedStyleSheets (Chrome) +38%
0 50 100 150 200 250 10000 20000 30000 40000
50000 メモリ増加量 (MB) コンポーネント数 adoptedStyleSheetsのメモリ使⽤量 Firefoxは逆にちょっと増えてる…… Chromeはよくわからんけど減ってはいる。 +38%
adoptedStyleSheets所感 よく分かんないけどChromeではメモリ使⽤量 減ってそう。 何でFirefoxのオーバーヘッド増えたの? Safariは謎(この資料をWindowsで作ったので) Declarative Shadow DOMでは対応していない のは⾟い。
次の希望: Declarative CSS Module Scripts adoptedStyleSheetsに相当する処理を JavaScriptを使わずに書けるようにしたいという 議論も存在する。 2023年4⽉のミーティングの結論は “Present
members of WCCG reach consensus: discuss this further with implementers.” https://github.com/WICG/webcomponents/issues/939
次の希望2: Declarative Custom Elements 似たような問題意識に対して、 “I think we should solve
declarative custom elements instead.” との⾒解を⽰すメンバーもいる。 その名の通り、customElements.register相当 のことをマークアップからできるようにする。 https://github.com/whatwg/html/issues/9962
WebComponents元年 Declarative Shadow DOMの サポートも出揃い、2023年からの WebComponents元年v4も佳境と なった。 しかし、Shadow DOMとCSS関連 が良い形におさまるにはまだ時間が
かかりそうだ。 https://www.docswell.com/s/jxck/5246NN- 1st-year-of-webcomponents-v4 参考: When the 1st year of Web Components era come true https://www.docswell.com/s/araya/ZQ8P9E-2024-01-25-202509
まとめ Declarative Shadow DOMのサポートにより、 Shadow DOMベースのCSS in JSもSSRできる ようになった。 しかし、最終形態ではなく次の議論もこれから。
WebComponents 元年v5 まだかな?