A few people have mentioned this sort of thing and I would be interested in seeing what people come up with. Personally I haven't made time to seriously look at it. @gf3 had the idea to plug Garden into Dieter which, at first blush, seems to be a good idea in terms of what I think people are interested in. If you come up with something, please share it!

Personally, I would avoid using a special *.garden format as I don't think it's going to add anything more than an extension. Garden isn't a format. It's not Sass or Less. It's Clojure. 😄

Although it may seem barbaric this is how I literally use Garden:

(ns foo.stylesheets.screen
  (:require [garden.core :refer [css]]
            [garden.units :refer [px em]]
            [garden.def :refer [defrule]]))

(defrule body :body)

(def sans-serif
  '[helvetica arial sans-serif])

(def screen-css
  (css {:output-to (io/resource "public/css/screen.css")
        :pretty-print? false
        :vendors ["moz" "webkit"]}

    [:*, :*:after, :*:before
     ^:prefix
     {:box-sizing "border-box"}]

    (body 
     {:font {:family sans-serif
             :size (px 16)
             :line-height (em 1.5)}})))

I then manually reload the namespace in Emacs with something like eval-buffer. I understand that this can be a bit of a turn off for some people but it's worked fine for me so this is why I haven't investigated the space much.

All this rambling aside:

I can help you with it if you want.

Please do! Cause I probably should upgrade my workflow WRT Garden. 😆

from garden.

This is typically how I work in development mode which is pretty similar to @noprompt's solution, it doesn't write any files though.

Example: compojure routes and garden stylesheets.

This is where I think Dieter would really come in handy, allowing you to work dynamically in development and compile your styles into static assets in production.

from garden.

Thank you for responses. Approach with compiling css through dieter is interesting but complicated for now. I'll try to create plugin for compiling garden to css for now. I don't want to introduce any new format. I was thinking about plain clj files where all expressions that are evaluated to objects extending CSSRenderer will be converted to css and written to final file. Something like this:

(def font-inactive-color "#888")

[:#navigation 

  [:.tab-button {
    :color font-inactive-color
    :font-size "25px"}]

  [:.tab-button:hover {
    :cursor "pointer"
    :border-bottom-color font-inactive-color}]]

[:.filtering 
  [:a {
    :color font-inactive-color }]]

All functions from garden.* namespaces will be imported implicitly so no (use) or (require :refer) is needed.

Is it ok with you?

from garden.

@nbeloglazov Sorry if I misunderstood what you were saying initially regarding the format.

I was thinking about plain clj files where all expressions that are evaluated to objects extending CSSRenderer will be converted to css and written to final file.

This is probably not the route you'd want to head in right now as the CSSRenderer protocol is not in a position where I would advocate people writing code against it.

All functions from garden.* namespaces will be imported implicitly so no (use) or (require :refer) is needed.

That sounds nice until you actually want that control. Also what if you need break your stylesheet code into separate namespaces, load code at the REPL, or use a library?

Maybe a better idea would be to use configuration similar to lein-cljsbuild.

(defproject foo "0.1.0-SNAPSHOT"
  :plugins [[lein-garden "0.1.0"]]
  :garden {:builds [{;; Stylesheet identifier (optional).
                     :id "screen"
                     ;; Where to look for stylesheets (optional).
                     :source-paths ["src/garden"]
                     ;; Which stylesheet to compile.
                     :stylesheet foo.stylesheets/screen
                     ;; Options to hand off to `garden.core/css` (optional).
                     :compiler {:output-to "resources/public/css/screen.css"
                                :vendors ["moz" "webkit"]
                                :pretty-print? false}}]})

Then you could run something like lein garden auto screen (to automatically compile screen.css) or lein garden auto (to automatically compile all stylesheets). This would avoid the problems I mentioned above while providing a simple solution to automatic compilation.

from garden.

@nbeloglazov, @gf3 I've started work on this here.

from garden.

:\ I've also started work on this here
As user I want it to be similar to css and sass in a way that it's just files with styles. It can be as simple as few vectors without any variables or function invocations like simple.clj or more complex like complex.clj.
And I don't want to specify every stylesheet to compile in project.clj. I may have plenty of stylesheets and I think they all should be compiled automatically without specifying each of them.

from garden.

@nbeloglazov This is definitely unfortunate! 😆

As user I want it to be similar to css and sass in a way that it's just files with styles.

I understood your rational earlier and find it ironic. One of the biggest reasons I wrote Garden in the first place was to get away from the style of stylesheet programming CSS and Sass encourage! And here you've effectively recreated sass --watch. You might as well add the .garden extension!

It can be as simple as few vectors without any variables or function invocations like simple.clj or more complex like complex.clj.

Sure, I get it. If that's the workflow you like then by all means continue working in that direction. I'm sure there will be others that would prefer to approach too.

And I don't want to specify every stylesheet to compile in project.clj.

I do.

Control is far more valuable than ease-of-use. Honestly, it's really not that hard to write a build configuration and the explicit nature of it is a good thing.

I may have plenty of stylesheets and I think they all should be compiled automatically without specifying each of them.

Then use your version of the plugin.

Since we're obviously at a disagreement and have both done work on a plugin, I would prefer it if you left your version of the plugin namespaced on Clojars as you have it now. As the author of Garden, I will maintain the "official" version plugin-in since it is more likely I will keep it up-to-date and current.

from garden.

Ok. I didn't know that:

One of the biggest reasons I wrote Garden in the first place was to get away from the style of stylesheet programming CSS and Sass encourage!

Could you elaborate on this? What problem CSS and SASS styles creates that you want to avoid? Or what crucial benefits you get by avoiding it?

As I see crucial difference in our approaches is that in my approach it compiles all files automatically and in your each stylesheet must be specified separately and thus can be controlled differently. How about adding feature to compile all stylesheets in your plugin? By specifying source path where to look for stylesheets. Or you strictly against such feature?

Personally I'm not excited to have counter-official plugin that does almost same that official.

from garden.

Could you elaborate on this? What problem CSS and SASS styles creates that you want to avoid? Or what crucial benefits you get by avoiding it?

Namespaces. Real namespaces! I know that Sass is planning to address this issue in future though. In fact, I've even proposed syntax for it. This is extremely important when you begin to write very large stylesheets and libraries. Clojure's namespaces make managing large Garden stylesheets very easy.

The other thing I wanted was solid tools for abstraction which, to be honest, is pretty weak in Sass when compared to what you have in Clojure. (I'm not saying Sass is weak in general though).

Some other immediate but maybe not obvious benefits to using Garden instead of Sass are:

• You can interactively develop and test your stylesheet code in either a Clojure or ClojureScript REPL and with clojure.test.
• You can share Garden code between the server and client (think cljx and goog.cssom).
• Garden is simply Clojure data in the Hiccup format which has all sorts of interesting implications.
• Your stylesheet code can use information directly from other code in your application.
• Laser fast compile times.

How about adding feature to compile all stylesheets in your plugin?

Unless you specify which build to compile (ie. lein garden once screen) all builds are compiled. The behavior is exactly like lein cljsbuild. The only thing that is required to be in a build is the :stylesheet parameter which you can think of like lein-ring's :init parameter.

Personally I'm not excited to have counter-official plugin that does almost same that official.

Nor am I but that's what's nice about open source. 😄

from garden.

Sorry if I came off as rude. It's not my intention. If you have any further suggestions or ideas please share them here.

from garden.