Although it still feels a lot like an anti pattern (mixing shadow dom and runtime utility classes) we felt the need to do this as well.
Our solution to the runtime dep was to adopt a global (inline) stylesheets (i.e. tailwind) into a components own constructable stylesheets. Doing so, all global utility classes become available in the components shadow dom.
Component css files (imported via roll-up, build using postcss/tailwind) are adopted into the same constructable stylesheet.
Although being debatable this idea ended up in our component stack that we use in production for a couple of years now.
We did not perf test this feature very good and we'll have a look into this in the next weeks but the status quo is documented here.
Would be great to hear some thoughts on this topic in general.
Is this anti pattern or not? Which one is the way to go (build vs. runtime) or should we all rely more on css properties for "style sharing / interfacing" !?
I think both paths are as valid as each other. I'd personally prefer a build-time solution as I have a very static set of styles I use, so if i know about them at build-time i may as well do the heavy lifting there. There are use cases where you want to dynamically generate/use these styles though, in which case a run time solution is nicer.
Your solution is interesting, pretty much is where i ended up when trying to throw together one using existing tooling. I also made a rollup plugin which replaces css templates inline with their processed equivalents and strips unused css at the same time. Both seem to be the way to go if wanting this at build time.
I think the ultimate build-time solution would be that CSS modules land in browsers, so we can just process a regular css file and import it natively into our modules.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Although it still feels a lot like an anti pattern (mixing shadow dom and runtime utility classes) we felt the need to do this as well.
Our solution to the runtime dep was to adopt a global (inline) stylesheets (i.e. tailwind) into a components own constructable stylesheets. Doing so, all global utility classes become available in the components shadow dom.
Component css files (imported via roll-up, build using postcss/tailwind) are adopted into the same constructable stylesheet.
Although being debatable this idea ended up in our component stack that we use in production for a couple of years now.
We did not perf test this feature very good and we'll have a look into this in the next weeks but the status quo is documented here.
github.com/webtides/element-js/blo...
And code:
github.com/webtides/element-js/blo...
Would be great to hear some thoughts on this topic in general.
Is this anti pattern or not? Which one is the way to go (build vs. runtime) or should we all rely more on css properties for "style sharing / interfacing" !?
I think both paths are as valid as each other. I'd personally prefer a build-time solution as I have a very static set of styles I use, so if i know about them at build-time i may as well do the heavy lifting there. There are use cases where you want to dynamically generate/use these styles though, in which case a run time solution is nicer.
Your solution is interesting, pretty much is where i ended up when trying to throw together one using existing tooling. I also made a rollup plugin which replaces css templates inline with their processed equivalents and strips unused css at the same time. Both seem to be the way to go if wanting this at build time.
I think the ultimate build-time solution would be that CSS modules land in browsers, so we can just process a regular css file and import it natively into our modules.