Re: New CSS library - Garden

[Joel Holdbrooks]

Awesome. Yes, please do!

Also, feel free to suggest ideas for features. I'm focusing on media queries and "&" prefixed selectors this week, but I'd love to see if anyone has good ideas surrounding attribute and child selectors. Right now the best we can do is "input[type=\"text\"]" and "ul > li" which is, well, pretty nasty.

Thanks for trying it out!

On Wednesday, April 10, 2013 12:37:49 PM UTC-7, Dan Neumann wrote:

Good stuff!

I'm using it in my hobby apps while I continue to cut my teeth on Clojure's web development toolkit.

I'll definitely communicate any problems/improvements I spot as I try to scratch my own itch.

[Joel Holdbrooks]

As of today, Garden is officially out of alpha and in to beta!

The library now sports media queries (via meta data) and parent selector references (ie. "&hover"). With these new features it is now possible to build more sophisticated stylesheets bringing us a step closer to having a viable CSS alternative in Clojure.

Over the course of the next few weeks, I plan to continue improving the library by adding "missing" features and functions to make the library as powerful as possible when it's release as 0.1.0 stable.

Now more than ever, I would like to encourage others in the community to reach out with suggestions and code review. This my first "real" Clojure library and after only six months with the language I'm sure it could benefit greatly from both of these things.

[Murtaza Husain]

Joel,

Thanks for the lib. Its great and I plan to use it in my projects.

How does Garden compare to other pre processors such as sass and less ?

Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it?

What is the workflow when using Garden ? If I am using Sass, I would create a .scss file, and the sass daemon would watch over any changes to the file and compile it to .css.

As I understand garden is generating css when called with the fn/macro (css [...]). Would it make sense to have a similar workflow like above; where a leiningen plugin watches for any .garden files and compiles them to .css files ? Or is there a better workflow that I am missing?

Thanks,
Murtaza

[JeremyS]

Hi Murtaza,

the simple way to go is have something like

(def rules1 [...])

(def rules2 [...])

(spit "rules.css" 

  (css (concat rules1 rules2)))

I am not sure about my good use of the library here but I think the idea is there. When you develop with the repo

you can just eval the (spit ...) call when you have changed your rules and voilà !

I hope this helps...

Jeremy.

[Joel Holdbrooks]

Murtaza,

Thanks for having a look at the library. I'll try to answer you questions as best as I can.

How does Garden compare to other pre processors such as sass and less?

There are some similarities with Garden and other CSS preprocessors. I've tried to bring over the ones I found most useful when using them. Nested selectors and declarations, parent selector references, and unit arithmetic are all currently available to stylesheet authors.

The big difference and, in my opinion, the big win is you can build your stylesheets with regular Clojure. This gives you a lot of power and freedom you won't find anywhere else (AFAIK). To name just a few benefits: 

• There's no file parsing or interpretation step. It's just data transformation. 
• There's no need for any sort of special @mixin syntax or macros, you can use Clojure function.
• There's no need for an @include directive thanks to clojure namespaces. This can help you organize your stylesheet in ways (I think) are much cleaner and less surprising than SASS and other preprocessors.
• Thanks to Clojure, Garden (potentially) has clearer syntax than CSS which, if you look closely, can be pretty random in some places.

WIth regard to the third point, if you've ever tried using the SMACSS approach to stylesheet authoring with a preprocessor like SASS, you can end up with an explosion of files and tons of @include directives. It's not fun, it's hard to manage, and it's difficult to see where code is coming from - especially when using 3rd-party libraries.

Also can I use it in my clojurescript projects ? I mean does it have any java lib dependencies that would prevent it?

It does have one small dependency on java.net.URI but I need some time to think about whether or not it would be worth dropping. As far as using it from a ClojureScript project, what sort of use case are you considering?

What is the workflow when using Garden?

My experience using Garden is probably close to others at this point. It's kind of funny in that regard. I'm building a tool and at the same time am learning how to use it. Personally, I create a namespace for my "core" stylesheets and separate namespaces for things like utilities and so forth (ie. (ns me.css (:require [me.css.button :as button])) . Then I have a call to function that compiles and saves the stylesheet at the bottom of the "core" stylesheets. Since I develop with Emacs and nREPL this means all I have to do is reload the file and the CSS is "refreshed".

It isn't the best approach, but Garden is still very young and I haven't thought about how a standardize the build process. But I would definitely be open to any thoughts regarding that. A Leiningen plugin would be awesome!

I hope these answers are helpful. Please continue to experiment with the library and express your thoughts!

Thanks,

Joel 

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xbFU2prTxlY/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Joel

[Clinton Dreisbach]

One interesting thing you could do, given both Garden and
ClojureScript, is package CSS frameworks like Twitter Bootstrap or
Zurb Foundation as a Clojure library. I am sorely tempted to give this
a try.

> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Joel Holdbrooks]

It's funny you should bring that up! I've actually been working on extracting the grid system from Bootstrap and modular scale from Foundation. But it's mostly been tinkering.

  I am sorely tempted to give this a try.

Please do! If I come up with something I'll be sure to share a Gist.

[JeremyS]

Hi Joel,

I have a quick and dirty implementation of a 960-ish grid system using a DSL similar to garden If you want to take a look.

[Joel Holdbrooks]

Jeremy,

Looks good. I've been tinkering with grid systems on and off for the past month or so. Have you thought of trying your hand at porting something like the Foundation or Gumby grid system?

One thing I've discovered, and you might try this with your 960 implementation, is that using higher order functions can be very handy for building them out. For example, a make-grid function which accepts a map of configuration options and returns a function which takes a column number and optional parameters for, say, push and pull. It's a nice way to package things up.

I'm close to wrapping up a small colors framework for Garden which will be available in the next beta (hopefully it won't be in beta much longer). When I take it out of beta it'll probably include a Clojure flavored implementation of either the grid system that ships with Bootstrap or Foundation (including the mobile parts).

On the side I've been taking of advantage of Clojure to create a new concept for a layout system. It's based on the font-size/line-height ratio and allows for the construction of stylesheets such that the grid system and typography are harmonious. IOW it's a fat pain in the ass, but I don't think I could even fathom the idea of doing it in Sass.

TL;DR you have Clojure at your disposal! Though we're SOL on some very nice Sass libraries, we can potentially do more and at a higher level!

Thanks for sharing! It's inspiring.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xbFU2prTxlY/unsubscribe.

[JeremyS]

Hi Joel,

Thank for the interest ! You can also take a look at some code have done around css unit types there. It's got arithmetic for 

units and a namespace dedicated to colors. In it you'll find conversions between rgb en hsl (that I have taken from the color library)

and the implementation of SASS color helpers. May be you could adapt my library to garden. From what I have seen Garden uses

protocols to compile different types into css and every unit (including colors) I define is a record. So you might be able to extend my library with Garden protocols and use it in garden without much effort. I'd be glad to see that !

About higher order function I have thought about that and went back, my first approach made for to complicated function (complected even). With the actual implementation I can just define stuff like:

(def grid {}) ; grid spec with column, gutter...

(def width (partial grid/witdh grid))

(def push (partial grid/push grid))

and then :

(def side-style [:#side (width 4) 

                                (push 1)])

for a side element spanning onto 4 columns and pushed off 1.

Regarding more advanced systems like Foundation I haven't spent much time trying to implement them with my DSL.

To do so I need to up my CSS game because I am not yet well versed into the art of responsive design and it will take me

a bit of time wrapping my head around the media queries involved. If I try to got responsive, I might probably study 

the Unsemantic system from the creator of the 960 one I think.

Good luck with your work and don't hesitate on browsing my github, right now most of the projects are oriented around CSS and there 

might be some ideas there who knows ! 

[Rob Jens]

Hey Jeremy,

You might be interested, in case you hadn't heard of it yet, of the Semantic Grid (http://semantic.gs) probably in particular their Stylus version https://github.com/twigkit/semantic.gs/blob/master/stylesheets/styl/grid.styl but depending on your taste/clarity might also wish to check out their grid in Sass/SCSS. 

Its math is quite elegant and simple.

Cheers,

Rob

Op woensdag 19 juni 2013 13:14:03 UTC+2 schreef JeremyS het volgende:

[Joel Holdbrooks]

Garden 0.1.0-beta5 is now available! The newest version includes functions for working with color and performing generic arithmetic (ie. operators for transparently adding numbers and units or numbers and colors). All of the familiar Sass color functions have been added to the library along with some new functions for generating triads, tetrads, and other sets of colors. Essentially (almost) anything you can do with Sass colors you can do in Garden just as conveniently. There are a few small tweaks that need to be addressed around color transparency which will be addressed in the near future. Check out the updated README at the project home page for more information.

The library is getting closer to being a viable alternative to other CSS preprocessors (at least in my opinion). It's a slow burn but eventually it'll get there!

Thanks to everyone for remaining interested in the project and please continue to give me feedback.

On Tuesday, April 9, 2013 12:58:50 PM UTC-7, Joel Holdbrooks wrote:

Nobel Clojurians,

I am pleased to announce the alpha version of Garden, a new library for writing CSS in Clojure.

The project weds the best ideas from Hiccup, gaka, and cssgen and aims to provide a clean and conventional way to author stylesheets without being too simple or too complex.

Currently the list of notable features include:

• Nestable rules
• Nestable declarations (this my change)
• A builtin set of tools for working with CSS unit values
• Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
• Output formatting options

What's planned for the near future:

• The ability to use Clojure meta as a media query
• A builtin set of tools for working with CSS color values
• & selector syntax for nested rules 

For those of you who are interested in this sort of thing, please have a look at the project's repository. There is still quite a bit of ground to do cover and any help/criticism/contribution would be greatly appreciated.

Please feel free to offer suggestions, ask questions, open issues, or send pull requests. I would love nothing more than to see this library succeed where other's have not. 

Truly,

Joel Holdbrooks (aka noprompt)

[Joel Holdbrooks]

Cool. I haven't seen this one before. Since it was fairly simple I reimplemented it in Clojure with Garden. Here's the gist.

I took a functional approach using higher order functions. It could be a little cleaner but then again the arithmetic isn't all on one 168 character line either. There are a few refactorings and nearly all of it is documented in a literate programming style.

[Rob Jens]

Hey Joel thanks for that!

I actually started work on translating the semantic grid to Clojure, it's just that I didn't finish as about half-way I kept the sense we could a bit more with Clojure.

What the semantic grid does it just does is to use the float left and display block properties and sets the width of those dynamically based on the required (if any) minimum or fixed size. It's nice start and I like it because mainly it is much cleaner, yet I imagine a Clojure framework would also allow for another, second case, which is far more popular. Most grid systems use explicit class names (like column-1 or column-one etc) which are just in their main stylesheet. We could, for people who like this solution, just generate these.

Also I wonder if perhaps this is an interesting approach: http://www.problem.se/labs/gridcalc/ as in, to calculate possible outcomes etc. 

Something along those lines in a very naive fashion

(defn make-columns
  "Creates a range of column sizes."
  [width columns gutter]
  (let [rng (map #(px %) (range 0 width columns))]
    (doall (interpose (px gutter) rng))))

;; => (0px 10px 60px 10px 120px 10px 180px 10px 240px 10px 300px 10px 360px 10px 420px 10px 480px 10px 540px 10px 600px 10px 660px 10px 720px 10px 780px 10px 840px 10px 900px 10px 960px 10px 1020px) 

There could even be a grid protocol and fluid, responsive, fixed, mobile, etc be implementations of it, or multi-methods, or maybe its an overkill. Also semanticgs doesn't know min/max on column/gutter sizes nor does it distinguish between an outer margin and gutter. With gutter its the question if you count it as 1 value to use or split in two, that 20px is really 10 and 10. Those are some considerations people might forever argue about. Personally I don't need it this fine grained but some might I guess. (some image overlay though, that could be really nice since a lot of designers still hand in photoshop illustrations that developers need to fit in.

Any thoughts?

Some links btw:

http://hugogiraudel.com/2013/04/04/css-grid-layout/ - the future of CSS will be in a W3C spec but don't hold your breath

http://gridpak.com/ 

http://www.gridsystemgenerator.com/gs01.php - generates also indented cells

Op donderdag 27 juni 2013 05:51:22 UTC+2 schreef Joel Holdbrooks het volgende:

[Rob Jens]

Btw, again, thanks for the work done! I would have written some more myself, or brainstorm a bit further but I'm really neck high in work for customers plus big meeting tomorrow so short of time.

Anyway, do you plan on incorporating a grid framework/concept in Garden, or keep this a snippet like it is?

Cheers,

Rob

Op dinsdag 9 april 2013 21:58:50 UTC+2 schreef Joel Holdbrooks het volgende:

[Rob Jens]

P.p.s. the pound signs are causing reader errors (e.g. #px) in LightTable so I changed those plus additionally added a little Jetty

https://gist.github.com/clojens/5878804

Cheers

[Joel Holdbrooks]

Rob,

Sorry for the late reply. I've been a bit distracted the past few days. I'll try to address your thoughts as best I can.

There could even be a grid protocol and fluid, responsive, fixed, mobile, etc be implementations of it, or multi-methods, or maybe its an overkill.

I don't think this is overkill. At the very least it's probably worth exploring. While I was "translating" the semantic grid SCSS code to Clojure, protocols did cross my mind. As I noted in the code comments there are a handful of "core" functions you see in virtually every grid system; well, in virtually every grid system I've ever seen. My instincts lead me to believe experimenting with protocols would be a step in the right direction.

... image overlay ... that could be really nice since a lot of designers still hand in photoshop illustrations that developers need to fit in

We have the JVM at our disposal. I'm fairly certain this could be a simple task although I'm not certain where one would start (probably Google).

Do you plan on incorporating a grid framework/concept in Garden?

Yes, but I'm waiting until Garden is no longer in beta (which should only be for another month or so). If you, or anyone reading this, would like to share gists/concepts for a grid framework that would definitely help keep the ball rolling. My main focus right now is making sure I've covered the most important topics (ie. color, units, comments, compilation) so people can feel confident and productive - especially if they're coming from Sass or another alt-css language. 

...the pound signs are causing reader errors...

That's because I was using data_readers.clj. Have a look here. I would definitely encourage anyone using Garden to employee this approach.

Regarding the new CSS grid spec and not holding my breath. I won't. It'll probably be at least a year or two before we see something solidified and even longer before it's a viable option. It's a good idea but it still needs a ton of work.

Anyhow, thanks for sharing your ideas! I look forward to hearing more from you.

Joel

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xbFU2prTxlY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Joel

[Steven Degutis]

So far, I really like Garden.

There's one thing though that's making it difficult. It's hard to see that nested rules are nested.

;; hard to see nesting
[:footer {:color "red"
          :background-color "blue"}
 [:a {:color "green"}]]

;; much easier
(:footer {:color "red"
          :background-color "blue"}
         [:a {:color "green"}])

(That's a bad example because it's so short. In the real world, much longer and deeper-nested rules show it clearer.)

Technically I'm using emacs with clojure-mode.el, which indents vectors by only 1 char. But I don't think that's the problem. Normally it's good to indent them by only 1 char, but there's no way to differentiate between [:some [:random :data]], which should be indented like that, and a vector of garden-rules which should be indented more obviously. So I don't think this is something that changing our editors/plugins will fix.

One solution is to use defrule more often. But if I have 3 elements with 3 children each, and each child has 3 children, that's already 27 defrules I have to stick above it. That'll get pretty unruly quick.

So I was thinking of just using a dummy macro like this:

(defmacro rule [& body] `[~@body])

(def footer
  (rule :footer {:color "red"
                 :background-color "blue"}
        (rule :a {:color "green"})))

But you can imagine my discomfort at writing/using a macro just to make indentation easier.

Are there any better solutions to this?

-Steven

You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Steven Degutis]

Oh, two more things.

First, it would be really cool to have a tool to convert CSS to GardenCSS. Michał Marczyk suggested using Instaparse with the CSS3 grammar, which sounds like a really easy way to make this happen. Unfortunately I don't have the time or skill to do it, but if anyone else does, it sounds like too cool an idea to pass up!

Also, I have gotten into the habit of defining CSS rules like { margin: 0px; margin-top: 0px; } because I can never remember the order of {margin: a b c d}. But this won't work in Garden, because maps have no order, and this trick relies totally on ordering. So it's something to watch out for if you have the same habit.

-Steven

[Joel Holdbrooks]

Hi Steven,

I know that readability is a bit of an issue for some people. Unfortunately there isn't much I can do other than point folks to the defrule macro and some of the other suggestions I've made. As I work with the Garden I see problem areas too and am working to find solutions that will make using the library more palatable.

Speaking of defrule, and correct me if I'm missing something, but I think you might be a bit confused about it's nature. You should think of defrule as a way to create selector functions. I'll admit this was bad naming on my part and I'll probably make an alias called defselector. Those "selectors"  can be as generic or precise as you like and possess the same semantics as normal vector based Garden code but are more flexible (since they are functions). Also, they should give you the indentation you are looking for.

(defrule a :a)
(defrule footer :footer)

(footer {:color "red"
         :background-color "blue"}
        (a {:color "green"}))

"But if I have 3 elements with 3 children each, and each child has 3 children, that's already 27 defrules I have to stick above it. That'll get pretty unruly quick."

Only if you have 27 distinct elements that you have no intention of ever reusing. Observe:

;; These forms are all semantically equivalent.

(footer {:color "red"
         :background-color "blue"}
        (a {:color "green"}))

[:footer {:color "red"
          :background-color "blue"}

 (a {:color "green"})]

(footer {:color "red"

         :background-color "blue"}
        [:a {:color "green"}])

;; This works too.  

(defrule h1 :h1)
(defrule hover "&:hover")

(footer
 (h1 {:font-weight "normal"}
     (hover {:font-weight "bold"}))
 (a {:text-decoration "none"}
    (hover {:text-decoration "underline"})))

To make life easier I will add all known HTML selectors (via defrule) and make some tweaks to it's behavior today. As of this moment most of the pseudo classes have been implemented here.

I hope this helps clear things up. Again, if I'm not understanding you correctly, please let me know.

Thanks,

Joel

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xbFU2prTxlY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Steven Degutis]

Right, I understand how defrule works. But I actually do have 27 [i.e. O(n)] distinct rules, so it's not a feasible solution.

Because when I write CSS, I only style domain-specific class names (.cart, .license), never mentioning the elements they just so happen to use at the moment (h1, p, a). This lets me change the implementation quickly and easily. And it makes it easier to write for other devices/sizes.

So really I only use defrule for the pseudo-selectors you just linked to (hover, active, nth-child). Besides that I really have no use for it.

And abstracting really feels like it shouldn't be used to solve the problem of indentation. Besides, like Dan Neumann mentioned in that Github Issue, abstracting anything in my stylesheet too early can lead to wrong abstractions that are difficult to revert. So right now I define an entire section (header, footer, cart) as one big nested vector, nothing extracted. Sure, I'll probably clean it up later, but only after I have more pages and can see more patterns emerging clearly.

Although, I have abstracted one thing which I hope will turn out useful:

(def clearfix
  [:&
   [:&:after {:clear "both"}]
   [:&:before
    :&:after {:display "table" :content "''"}]])

Then you can embed it as a rule anywhere that you need to clear some floats:

[:.some-container-with-floats clearfix]

But as for indentation, so far I'm liking the "rule" macro more and more. I admit it's weird that it just vector-izes its arguments, and does nothing else. But the fact that it's a function call fixes the indentation problem wonderfully.

I think it should be part of the garden lib, really. Although lately I've renamed it to "%" so my eyes aren't drawn to the wrong thing when I'm skimming my rules. It was "!" for a while but that was weirder thanks to it being right after a long skinny parenthese. But either way, these all make nested rules much easier to visually scan.

Anyway I really love using Garden. Thanks for writing it!

I've been experimenting with some ways of integrating it with compojure for some Rails4-like "asset-pipelining" (whatever that means), and it works really well but the API is still a little raw. But if I come up with anything good I'll try to share it.

-Steven

[Joel Holdbrooks]

Cool. I'm glad you like the library. Thanks for sharing your kind words and thoughts. :)

"I admit it's weird that it just vector-izes its arguments, and does nothing else."

In that case I don't think you need a macro, just alias rule to vector and you'll achieve the same end.

"I think it should be part of the garden lib..."

I don't think there would be any harm in adding this as an alias;  I tend to do a similar thing aliasing styles to list. 

"And abstracting really feels like it shouldn't be used to solve the problem of indentation."

That's definitely not the only reason why defrule was added but it could be used to address that problem which is why I brought it up. The beautiful thing about programming stylesheets in Clojure is that we can come up with whatever abstractions/techniques we like without being tied down by syntax. There's a lot of potential there for some interesting ideas.

"I've been experimenting with some ways of integrating it with compojure for some Rails4-like "asset-pipelining"..."

Some people are definitely looking for this. If you come up with something, even a simple gist, please share it. I'm still loading/compiling stylesheets manually. :P

Oh, I don't know if you saw this gist but there's also some interest in ideas surrounding grid systems.

Thanks,

Joel

[Steven Degutis]

The beautiful thing about programming stylesheets in Clojure is that we can come up with whatever abstractions/techniques we like without being tied down by syntax. There's a lot of potential there for some interesting ideas.

In the past I've been bitten hard because the wrong abstractions were settled on too early. So I try to always take pains to make sure I either don't use any abstractions, or make absolutely sure they'll last a very long time without going past their expiration date too quickly. So while I'm sure we'll need some more abstractions, I think it's important to let them evolve naturally rather than jumping to them too quickly and without enough data.

Some people are definitely looking for this. If you come up with something, even a simple gist, please share it. I'm still loading/compiling stylesheets manually. :P

(def home-style
  {:css (css garden-code)
   :path (format "/css/home-%s.css" (md5 compiled-css))
   :route (GET path [] (valid-request-with compiled-css))})

Then, in my hiccup I just use (:path home-style), and in my routes I have (:route home-style). This makes the html file smaller, and lets CDNs and browsers cache the css with full confidence since it's content-hashed. Plus this way it's compiled only once, before any routes are requested.

Oh, I don't know if you saw this gist but there's also some interest in ideas surrounding grid systems.

Neat, thanks. I may have to borrow ideas from that.

-Steven