Localization isn’t done yet. For now, you can just install a new “style” of control that does what you need and install it as a UI control and select that style for the control in your form

Using a more advanced and localized control is the eventual full solution

I see, alright that'll do. Thanks!

yes, via the :css part of the components

“preferred” is a tough question, IMO

right, I think better to say "I prefer it", hehe, I love the css isolation I get with fulcro and garden, so I like it, but Tony is right, if you don't like it, totally fine to don't use too

Here’s how I look at it: If you’d like your component to have css that is name-munged so it does not conflict with other css libs, then it is a convenient way to do it. Ultimately, that is really all the lib does: namespaces the css classes to the component in question. It’s perfectly reasonable to hand-write small app customizations in a simple css file (or use sass/less/etc) or a theme for semantic ui, etc.

So, a library author that is trying to make exported and reusable controls for Fulcro might choose to do component-localized css just to make it easier to pull into your app.

but I personally do not use the feature on my own apps 🙂

(I hate writing css, so I lean very heavily on pre-written libs of css that I can theme)

and for minor tweaks I just use :style

thanks all

I’m hoping to lean heavily on a css framework and have very minimal custom css 🤞

I've been happy using emotion css-in-js with fulcro: https://dvingo.github.io/cljs-emotion/#!/dv.cljs_emotion.devcards

for me the major pain-point in dynamic CSS (fulcro-garden-css & :style) is that it’s hard to apply a build pipeline to it: autoprefixing & minification depending on prod/dev env also hard to do complex styles which span multiple components i’m mostly using TailwindCSS + classic CSS files with PostCSS for reusable components and complex stuff, rarely fulcro-garden-css (mostly for custom grids & custom at-media breakpoints)