WesTrying out a variant of "UI as a function of state" where I store state in "data" attributes on the component root and then my CSS is peppered with selectors based on those attributes.
Why? Because I'm trying to find a good way to write an SSR'd web component that hydrates on the client without declarative shadow dom. Don't get me wrong, I wish I could use shadow DOM, but when I have 100 components on the page all repeating the same CSS in the DSD template I don't love it.
I tried using the LIT plugin for @11ty but that outputs too much DSD for components that get repeated on the page, so that's why I'm playing with my own version of "put a bunch of state in the top-level component attributes and let CSS do any conditional rendering"
westbrook@goulet @11ty Were you able to prove out that at ship time the repeated DSD was causing performance issues? Some implementors maintain that compression tooling is enough to alleviate that issue, but they'd likely be swayed by data/reason in the form of lived experience as we look to have better APIs like Declarative CSS Module Scripts and, hopefully, (Declarative) HTML Module Scripts.
@westbrook @11ty Great question, I did not measure anything, mostly going off my own feels - when I look at the DOM tree it felt wrong. Need to measure.
@goulet @11ty Vibes are as important as "realities", up to a point, so if you've got vibes that play out, I've love to hear them! If not, it'll also be useful learning for #webComponents devs as a whole. Thanks a million in advance!