Serhii KulykovHey #WebComponents folks! Let's share our experiences with using #CustomElements and #ShadowDOM as the State Of JS 2022 survey is now open.
Vint Prox@kulykov doing web component in vanilla JavaScript, with CSS encapsulated, is a PITA so far. Once there's a need to include reset styles in every custom element with Shadow DOM, you are toast! Already tried with CSS at-import and HTML <link>, but they are just workarounds that rely on baseURI. Can't seriously present it to my client. HTML/CSS Module Imports are not implemented in browsers... So normal webdev environment has a long way to go for buildless.
@vint You might not need to reset CSS in every component. Check out vanilla-colorful for an example of setting only those styles that are really needed:
@kulykov the problem is that not all browsers follow the exact guideline of what should be considered a model start, so solutions like https://elad2412.github.io/the-new-css-reset/ come in to save the day, and I'm basically rambling now about how Shadow DOM makes me do things that are not part of buildless architecture. To begin with, if I had a greenlight on Vite or other build tool for this project, I wouldn't even think about ranting.
@vint Consider using constructable stylesheets, it should be possible without a build tool, you just need a polyfill for Firefox / Safari (for now):
@kulykov well then, I considered it, but another problem arises - in my use case I'll have to mash my reset CSS in JS file under CSSStylesheet.replace. What I tried to say by CSS Module Imports being unsupported is that you can't import contents of CSS file in JS - instead you'll need to hardcode CSS in there. I wouldn't exactly call it clean and interoperable, because then devs will need to install plugin in their IDE that can highlight CSS-in-JS. Plus FOUC (flash of unstyled content).
@vint Yes, we still need to wait until native CSS module scripts feature lands in all browsers (it's Chrome only for now).
@kulykov actually, now that I've got this out in the open with you, along with adoptedStylesheets polyfill I found https://github.com/guybedford/es-module-shims#css-modules, so I hope it'll work out. Thanks for the response!
@vint Right, I totally forgot that es-module-shims already supports this. Glad that you figured it out! Hopefully this improves developer experience a bit.
@kulykov I was reflecting on the process that I imposed on myself, but now it's just back-and-forth. Since there's no HTML Module Imports and splitting #WebComponents to several files is overall silly for my use case, I decided to stick to SFC approach: put styles to CSSStylesheet, use adoptedStyleSheets and HTMLTemplateElement. Only importing reset.css to base component. Makes more sense now!
https://mastodon.social/@vint/109388218674622165
https://mastodon.social/@vint/109388218674622165
@vint Yes, that sounds like a reasonable approach to me (there are some tools that use similar SFC approach).
BTW, looks like you had a problem with Lit related to minified bundle? When using a dev server that supports export conditions, you can use "dev mode".
@kulykov haha, as usual, I wouldn't like to overwhelm them with build and dev server realm, and myself for that matter. 😉 I kind of understand those folks who don't wanna deal with it, because no matter how much you use it, the same black box and MaGiC...
@kulykov ah, I remember interacting with #OpenWC docs, and I wasn't particularly pleased to see marginal focus on how to do things with #LitElement. You can imagine what my thought process was ATM: a lot of Lit talk = vendor lock-in = bye. I'll investigate it better.
@vint This is exactly the reason why #ModernWebDev was extracted into a separate project: Web Dev Server and Web Test Runner are completely framework agnostic (you can even use them with React thanks to esbuild plugin).