mastodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance, open to everyone, but mainly English and French speaking.

Administered by:

Server stats:

790
active users

#shadowdom

1 post1 participant0 posts today

I'm in total agreement with this post: gomakethings.com/the-shadow-do - the ability to have a global CSS system is something that has been encouraged for YEARS as a matter of reducing the download footprint, yet shadow dom discourages this.

And there shouldn't be any technical reason why slots should require shadow. take this declared child, move it to that spot in my html structure. It can be (and has been) faked by multiple frameworks including lit, stencil, and JET.

'generic' web components that use internal CSS to define the layout, and then rely on a global css system to be flexible in appearance, is what we web-devs really want.

Logo
gomakethings.comThe Shadow DOM is an antipatternIn my video on building a modern web app with vanilla Web Components, I mentioned that I believe the Shadow DOM is an antipattern when using Web Components. I had a few folks in the comments ask me why. After all, the Shadow DOM is touted as one of the premiere features of working with Web Component. And certain features, like slots, require the Shadow DOM to work. I’ve built a lot of Web Components over the last couple of years, and in my experience, the Shadow DOM creates more problems than it fixes.

New Kitten release

• Now leaves <style> tags within <template> tags alone when collating and normalising the CSS on a page so as not to interfere with scoped styles in declarative shadow DOM.

(Kitten’s Streaming HTML workflow¹ – which uses htmx and WebSockets under the hood – combined with built-in support for slots, etc., in Kitten components² means the use of declarative shadow DOM is mostly useful if you want scoped styles. Ideally, of course, use classes to scope styles to your components and be specific in your CSS selectors in general so as not to pollute elements in your components. Although that’s a bit like saying you should floss everyday. Yeah, we all know we should…) :)

Update: All that said, I’d highly recommend you don’t use Shadow DOM in your Kitten apps. For one thing, htmx’s WebSocket extension doesn’t seem to play well with it. And for another, you really don’t need it and definitely not just to get scoped CSS.

Enjoy!

:kitten:💕

¹ kitten.small-web.org/tutorials
² kitten.small-web.org/tutorials

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:

blog.westbrookjohnson.com/patt

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. 🙇

blog.westbrookjohnson.comI'm feeling so disconnected

This is a re-post since I don't see Keith on here:

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!
github.com/w3c/csswg-drafts/is

GitHub[cssom] Can we lift the restriction on constructed flag for adoptedStylesheets? · Issue #10013 · w3c/csswg-draftsBy keithamus

github.com/w3c/csswg-drafts/is

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!

GitHub[cssom] Can we lift the restriction on constructed flag for adoptedStylesheets? · Issue #10013 · w3c/csswg-draftsBy keithamus
Replied in thread

@Seetee Learning is a particularly personal process, so one API at a time or all at once depends more on you. On the whole, knowing how to leverage each of the #webComponent APIs individually is very important to your overall success in deciding the right solution for any problem.

That said, a lot of my problems ARE solved by focusing my DOM tree for both functionality AND styles via #shadowDOM; easier to reason and share.

What sort of problems are you looking to solve with web components?

Replied in thread

@knowler MDN accepts PRs…

I started working on github.com/Westbrook/axe-core- as a test bed for #ElementInternals usage for ace-core, but maybe more useful at large for these APIs. I accept PRs, too. 🤗

Also, we’re looking to reignite the push for community docs and guides for WCs in discord.gg/KzgaSbGc9q to clarify these sorts of things, as well.

GitHubGitHub - Westbrook/axe-core-element-internals: Tests for accessibility tree equivelency of Element Internals usage.Tests for accessibility tree equivelency of Element Internals usage. - Westbrook/axe-core-element-internals
Replied in thread

@oldcoyote Hopefully, yes!

There's still some back and forth in the TAG design review to work through: github.com/w3ctag/design-revie But, after 3+ years of my active involvement, and 10+ years of various incredibly smart people attempting at this since the very inception of #webComponents and #shadowDOM, the air is tingling with anticipation.

GitHubReference Target · Issue #961 · w3ctag/design-reviewsBy dandclark