In that it was dropped as part of a thread that you might have otherwise been uninterested in, sharing this again to start your Thursday:
https://blog.westbrookjohnson.com/patterns/i-am-feeling-so-disconnected/
Catch up on some techniques for managing connection time work in a custom element. There's even reasons for using shadow DOM hidden in there.
Thanks @nachtfunke for starting the convo on this and @zachleat for challenging a toot into a full on blog dump.
@zachleat @nachtfunke I'm not saying this is because I didn't get you anything for your birthday, but I'm also not saying it isn't because of that...
https://blog.westbrookjohnson.com/patterns/i-am-feeling-so-disconnected/
https://github.com/w3c/csswg-drafts/issues/10013#issuecomment-2627222385
Call to action for #WebComponent / #ShadowDOM fans: I've added an experimental flag to Firefox lifting the restriction on adoptedStyleSheets, meaning shadowroots can adopt `link.sheet` or `style.sheet`.
Please try this out, and let me know if you encounter issues!
I think #CSS vars are good enough for bridging styles from a page into it's #webComponents' #shadowDOM
I’ve never had stress around putting all my #CSS for all of my #webComponent in their #shadowDOM… ask me anything.
#RiotJS で #WebComponents なサンプル作りを昨夜試して、色々 riotjs/custom-elements のバグっぽい挙動も報告できたので良かったんだけど、#WebComponents の属性値に基本テキストしか渡せないのは、やはり感覚的にはちょっと不便に感じる時あるな…props バケツリレーすればとりあえずなんとかなるかなみたいになっちゃってる自分が良くないかもなので別のパターンを学ぶ良いきっかけかもしれないけど。
#CSS が外部に伝搬しない #shadowDOM は使い方次第ではすごい強力な気はしている。
#WebComponentsb の template の書きづらさは Riot みたいなコンポーネントベースのフレームワークを使って解決するほうがよさそうだなと思ってるけど、標準技術の中でもう少し柔軟に書けるようになる予定とかないんだろうか…構造がある程度複雑になると、フレームワーク使わずにやろうとすると #HTML 側に template で書いておいて #JS 側から getElementById するみたいなやり方しか自分は思いついてないんだけど、できればコンポーネントはコンポーネントとして別ファイル化したいし… #PHP とかフロント以外のところでコンポーネント用の template を分けておけばいいのかもしれないけどなんかそれもなあとか考え事をしながら人間ドックに向かっている朝。
Hrm. #viewTransitions and #shadowDOM …discuss.
Small declarative web-component for loading fonts in Shadow DOM, especially useful for components that want to load an icon using a font library!
https://github.com/JRJurman/use-font
Admittedly, it is so tiny, that you could just copy-paste the code for most projects, but it is a good reference point for anyone looking for something similar!
Using #DeclarativeShadowDOM to render placeholder content that gets replaced later as the #HTML #streams in with no #JavaScript!
https://lamplightdev.com/blog/2024/01/10/streaming-html-out-of-order-without-javascript/
This is an interesting technique, but it has limitations in that you can't close the #customElement until you've loaded the content.
Good reason to avoid ShadowDOM: "it breaks html forms"
Bad reason: "I like global CSS"
I'm of the opinion that the #cascade was a mistake, for the same reason that #OOP was a mistake; #inheritance is too implicit. How much time have we wasted with things like #CSS resets, !important, #BEM, etc just faffing about with #specificity trying to make styles apply? For what? A few bytes of duplication?
> Global CSS doesn’t bleed into the shadow DOM (which is the point), but that means that your design system can now no longer benefit from having a global CSS file or take advantage of the cascade.
> Each item is its own discreet thing, so you’re repeating your styles a lot more across each one with shared design aspects.
This feels kinda strawmanny to me. Multiple ShadowDOMs can include the same CSS file.
“HTML Web Components” are an antipattern if our goal is to create custom *HTML* elements like what we find in *HTML*.
https://knowler.dev/blog/html-web-components-are-an-antipattern
Hmm I'm wondering if declarative Shadow DOM in Web Components would open the path to new patterns of making nicer without-JS-fallback than with <noscript> elements
But some experiment gonna be… as always… for some other days
Have you ever wished the Shadow DOM had greater styling flexibility? Come share your story so we can fix that.
https://github.com/w3c/webcomponents-cg/discussions/92
(Please share for reach, thanks!)
#WebComponents #ShadowDOM #CSS #HTML #WebDev
これやっぱり自分が確認できる現存のサイトで見てる限り、#Webcomponents の #ShadowDOM であること自体は別に #Google のクロールにはさほど有利な影響はないような気がする。
というかそれを確認しててむしろもっと驚いたのは、#RiotJS のインプラウザコンパイル(プリコンパイルなしで compiler 含む JS を読み込んでブラウザ側で .riot ファイルを #JavaScript にコンパイルしてからマウントする方法)でマウントした要素もちゃんとクロールされてたこと
#Google では #WebComponents の #ShadowDOM がちゃんとレンダリングされた状態でクロールされるっていう記事だけど、#Google はもともと #JavaScript をある程度は実行してくれるからという話じゃないのかなこれ。
Web標準の #WebComponents だからよりクロールされやすいみたいなことが起きてるのかどうかはこれ読むだけだとまだわからない気がする…
昔 #RiotJS で作ったコンポーネントも展開された状態でクロールされてたし、 #JS の処理の重さによっても変わりそう… #Google のクローラーがそこまで長い時間 #JS を実行してくれるわけもなさそうだし…
https://dev.to/stuffbreaker/seo-and-web-components-2023-edition-3l6i
Developers think about styling the shadow DOM upside down: they approach it from a DOM/inheritance perspective instead of a cascade perspective.