@tony.kay The om-css snapshot seems awesome. Surprised by the fast fix in om-next multi-method. but then saw that you fixed it 🙂

Seems to work in advanced mode apart from a really strange issue. 😞

If in the server I add a om.next then it affects the cljs advanced build for some reason 😞

The easiest way to replicate it is just to add [om.next :as om] in the require of the (ns user of user.clj

then when i do lein clean && lein cljsbuild once release I get the html without the class just <li> and the <style id="my-css"></style> is empty.

@claudiu you mean in Ssr?

not really. Just adding it in dev.clj messes with the clojurescript build.

Managed to replicate it in the cookbook example, just by importing in .clj om next. If I remove the import the production build works just fine.

Hey @claudiu and other Untangled/om-css users out there. I am currently working with the new version of this library and i'm facing some issues that i would like to improve. Would love to hear your thoughts and suggestions on this. First of, local css-rules and global css-rules are now separated by different protocols. But there are some cases where you would want to add additional css-rules to a classname, for example when you are using an another external component. So what i basically mean is that you have some cases where you want to prevent a keyword to be localised even though it is defined somewhere nested in your local-rules. My suggestion would be to prefix those keywords with a $. Second, multiple classnames now have to be defined like this: {:className (str classA " " classB " " (when condition classC))} I think it would be nice to have a helper function that takes any amount of classnames and merges them together. {:className (css/merge-classnames classA classB (when condition classC))}

@claudiu that is rather strange…no ideas on my end

that should not even be on the classpath during a release build

@timovanderkamp I agree with (1). On (2): I like the idea (though ppl have prob written their own, it won’t hurt to include one). The name is the primary thing. Something shorter would be nice.

what abt & and such?

what other garden -> CSS notations should we be worried about?

probably should go through the docs and explore what we’re going to run into. Or, we can add them as people run into them. The latter makes the library a bit more frustrating.

I've looked at the garden selectors to check what would be a problem atm. At a quick look it would not be possible yet to use the CSS combiners and the special selector &.

The CSS combiners are +, - and >

[:.a {..} [:+.b {..}]] -> .a { .. } .a + .b { .. }

What doesn't work atm is that [:+.b {..}] won't be transformed to [:+.namespace_Component__b {..}], as it should be

same goes for all the CSS combiners

so as you discover those, throw up issues on github

glad to merge PRs as rapidly as anyone wants to address them

I’m betting one generalization that scans for the set of these like #{"+" ">" ...} will get us a long way

yes exactly, we are currently only transforming keywords that start with :.