FAQ
Nobel Clojurians,

I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
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)

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dan Neumann at Apr 10, 2013 at 7:43 pm
    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.


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Apr 11, 2013 at 12:15 am
    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.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Apr 22, 2013 at 9:12 pm
    As of today, Garden is officially out of alpha and in to beta!

    The library now sports media queries<https://github.com/noprompt/garden#media-queries>(via meta data) and parent
    selector references<https://github.com/noprompt/garden#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.

    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*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Apr 22, 2013 at 9:12 pm
    As of today, Garden is officially out of alpha and in to beta!

    The library now sports media queries<https://github.com/noprompt/garden#media-queries> (via
    meta data) and parent selector references<https://github.com/noprompt/garden#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.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Murtaza Husain at Apr 25, 2013 at 1:44 am
    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

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

    The library now sports media queries<https://github.com/noprompt/garden#media-queries> (via
    meta data) and parent selector references<https://github.com/noprompt/garden#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.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • JeremyS at Apr 25, 2013 at 1:17 pm
    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.
    On Thursday, April 25, 2013 3:44:25 AM UTC+2, Murtaza Husain wrote:

    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

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

    The library now sports media queries<https://github.com/noprompt/garden#media-queries> (via
    meta data) and parent selector references<https://github.com/noprompt/garden#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.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Apr 25, 2013 at 10:12 pm
    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

    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain wrote:

    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

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

    The library now sports media queries<https://github.com/noprompt/garden#media-queries> (via
    meta data) and parent selector references<https://github.com/noprompt/garden#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.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --

    Joel

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Clinton Dreisbach at Apr 25, 2013 at 10:27 pm
    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.
    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

    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.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.

    For more options, visit https://groups.google.com/groups/opt_out.



    --

    Joel

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Apr 25, 2013 at 11:01 pm
    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.

    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach wrote:

    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.
    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

    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.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.

    For more options, visit https://groups.google.com/groups/opt_out.



    --

    Joel

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --

    Joel

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • JeremyS at Jun 18, 2013 at 11:41 am
    Hi Joel,

    I have a quick and dirty implementation of a 960-ish grid system<https://github.com/JeremS/cljss-grid>using a DSL similar to garden If you want to take a look.


    On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:

    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.


    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach <cli...@dreisbach.us<javascript:>
    wrote:
    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.

    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks <cjhold...@gmail.com<javascript:>>
    wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    <murtaza...@sevenolives.com <javascript:>> wrote:
    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

    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.
    --
    --
    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<javascript:>
    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 <javascript:>
    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 <javascript:>.

    For more options, visit https://groups.google.com/groups/opt_out.



    --

    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<javascript:>
    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 <javascript:>
    For more options, visit this group at
    http://groups.google.com/group/clojure?hl=en
    ---
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    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<javascript:>
    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 <javascript:>
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --

    Joel
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Jun 19, 2013 at 6:54 am
    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.
    On Jun 18, 2013, at 4:41 AM, JeremyS wrote:

    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.



    On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:
    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.


    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach wrote:
    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.
    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

    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.
    --
    --
    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

    --
    --
    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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+u...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    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

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • JeremyS at Jun 19, 2013 at 11:14 am
    Hi Joel,

    Thank for the interest ! You can also take a look at some code have done
    around css unit types there <https://github.com/JeremS/units>. 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<https://github.com/jolby/colors>
    )
    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 <http://unsemantic.com> 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 !
    On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:

    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.

    On Jun 18, 2013, at 4:41 AM, JeremyS <jschof...@gmail.com <javascript:>>
    wrote:

    Hi Joel,

    I have a quick and dirty implementation of a 960-ish grid system<https://github.com/JeremS/cljss-grid>using a DSL similar to garden If you want to take a look.


    On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:

    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.

    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach wrote:

    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.

    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks <cjhold...@gmail.com>
    wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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

    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks wrote:

    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.
    --
    --
    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

    --
    --
    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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+u...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    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
    --
    --
    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 <javascript:>
    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 <javascript:>
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Jens at Jun 26, 2013 at 12:42 pm
    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:
    Hi Joel,

    Thank for the interest ! You can also take a look at some code have done
    around css unit types there <https://github.com/JeremS/units>. 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<https://github.com/jolby/colors>
    )
    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 <http://unsemantic.com> 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 !
    On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:

    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.

    On Jun 18, 2013, at 4:41 AM, JeremyS wrote:

    Hi Joel,

    I have a quick and dirty implementation of a 960-ish grid system<https://github.com/JeremS/cljss-grid>using a DSL similar to garden If you want to take a look.


    On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:

    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.

    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach wrote:

    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.

    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks <cjhold...@gmail.com>
    wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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


    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks
    wrote:
    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.
    --
    --
    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

    --
    --
    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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+u...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    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
    --
    --
    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.



    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Jun 27, 2013 at 3:51 am
    Cool. I haven't seen this one before. Since it was fairly simple I
    reimplemented it in Clojure with Garden. *Here's the gist.*<https://gist.github.com/noprompt/5873715>

    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*<https://github.com/twigkit/semantic.gs/blob/master/stylesheets/scss/grid.scss#L63>.
    There are a few refactorings and nearly all of it is documented in a
    literate programming style.
    On Wednesday, June 26, 2013 5:41:56 AM UTC-7, Rob Jens wrote:

    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:
    Hi Joel,

    Thank for the interest ! You can also take a look at some code have done
    around css unit types there <https://github.com/JeremS/units>. 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<https://github.com/jolby/colors>
    )
    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 <http://unsemantic.com> 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 !
    On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:

    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.

    On Jun 18, 2013, at 4:41 AM, JeremyS wrote:

    Hi Joel,

    I have a quick and dirty implementation of a 960-ish grid system<https://github.com/JeremS/cljss-grid>using a DSL similar to garden If you want to take a look.


    On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:

    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.


    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach <cli...@dreisbach.us
    wrote:
    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.

    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks <cjhold...@gmail.com>
    wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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


    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks
    wrote:
    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.
    --
    --
    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

    --
    --
    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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+u...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    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
    --
    --
    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.



    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Jens at Jun 27, 2013 at 5:30 pm
    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:
    Cool. I haven't seen this one before. Since it was fairly simple I
    reimplemented it in Clojure with Garden. *Here's the gist.*<https://gist.github.com/noprompt/5873715>

    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*<https://github.com/twigkit/semantic.gs/blob/master/stylesheets/scss/grid.scss#L63>.
    There are a few refactorings and nearly all of it is documented in a
    literate programming style.
    On Wednesday, June 26, 2013 5:41:56 AM UTC-7, Rob Jens wrote:

    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:
    Hi Joel,

    Thank for the interest ! You can also take a look at some code have done
    around css unit types there <https://github.com/JeremS/units>. 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<https://github.com/jolby/colors>
    )
    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 <http://unsemantic.com> 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 !
    On Wednesday, June 19, 2013 8:54:48 AM UTC+2, Joel Holdbrooks wrote:

    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.

    On Jun 18, 2013, at 4:41 AM, JeremyS wrote:

    Hi Joel,

    I have a quick and dirty implementation of a 960-ish grid system<https://github.com/JeremS/cljss-grid>using a DSL similar to garden If you want to take a look.


    On Friday, April 26, 2013 1:01:44 AM UTC+2, Joel Holdbrooks wrote:

    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.


    On Thu, Apr 25, 2013 at 3:27 PM, Clinton Dreisbach <
    cli...@dreisbach.us> wrote:
    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.

    On Thu, Apr 25, 2013 at 6:12 PM, Joel Holdbrooks <cjhold...@gmail.com>
    wrote:
    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


    On Wed, Apr 24, 2013 at 6:44 PM, Murtaza Husain
    wrote:
    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


    On Tuesday, April 23, 2013 2:42:55 AM UTC+5:30, Joel Holdbrooks
    wrote:
    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.
    --
    --
    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

    --
    --
    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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+u...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    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
    --
    --
    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.



    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Jun 26, 2013 at 6:25 pm
    Garden 0.1.0-beta5 is now available! The newest version includes functions
    for working with *color* <https://github.com/noprompt/garden#color> and
    performing generic *arithmetic*<https://github.com/noprompt/garden#arithemetic>(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 <https://github.com/noprompt/garden>* 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*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Jens at Jun 27, 2013 at 5:41 pm
    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:
    Nobel Clojurians,

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Jens at Jun 27, 2013 at 6:09 pm
    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



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

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Jul 2, 2013 at 6:25 pm
    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*<https://github.com/noprompt/garden/blob/master/dev/data_readers.clj>.
    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

    On Thu, Jun 27, 2013 at 11:09 AM, Rob Jens wrote:

    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



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

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --

    Joel

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steven Degutis at Jul 6, 2013 at 1:58 pm
    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<https://github.com/noprompt/garden/issues/5#issuecomment-19848873>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

    On Tue, Apr 9, 2013 at 2:58 PM, Joel Holdbrooks wrote:

    Nobel Clojurians,

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steven Degutis at Jul 6, 2013 at 2:59 pm
    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

    On Sat, Jul 6, 2013 at 8:58 AM, Steven Degutis wrote:

    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<https://github.com/noprompt/garden/issues/5#issuecomment-19848873>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

    On Tue, Apr 9, 2013 at 2:58 PM, Joel Holdbrooks wrote:

    Nobel Clojurians,

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Jul 7, 2013 at 1:52 am
    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
    On Jul 6, 2013, at 6:58 AM, Steven Degutis wrote:

    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


    On Tue, Apr 9, 2013 at 2:58 PM, 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)


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steven Degutis at Jul 7, 2013 at 2:41 am
    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

    On Sat, Jul 6, 2013 at 8:52 PM, Joel Holdbrooks wrote:

    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*<https://github.com/noprompt/garden/blob/master/src/garden/stylesheet/pseudo_classes.clj>
    .

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

    Thanks,

    Joel

    On Jul 6, 2013, at 6:58 AM, Steven Degutis wrote:

    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<https://github.com/noprompt/garden/issues/5#issuecomment-19848873>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

    On Tue, Apr 9, 2013 at 2:58 PM, Joel Holdbrooks wrote:

    Nobel Clojurians,

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.

    For more options, visit https://groups.google.com/groups/opt_out.




    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joel Holdbrooks at Jul 7, 2013 at 4:40 am
    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
    On Jul 6, 2013, at 7:41 PM, Steven Degutis wrote:

    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


    On Sat, Jul 6, 2013 at 8:52 PM, Joel Holdbrooks wrote:
    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
    On Jul 6, 2013, at 6:58 AM, Steven Degutis wrote:

    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


    On Tue, Apr 9, 2013 at 2:58 PM, 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)


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.

    For more options, visit https://groups.google.com/groups/opt_out.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steven Degutis at Jul 7, 2013 at 2:46 pm

    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<http://rubyonrails.org/>abstractions were settled on too early.
    So I try to always
    take <https://gist.github.com/evanescence/5833792>
    pains<https://gist.github.com/evanescence/5811570>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

    On Sat, Jul 6, 2013 at 11:40 PM, Joel Holdbrooks wrote:

    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*<https://gist.github.com/noprompt/5873715> but
    there's also some interest in ideas surrounding grid systems.

    Thanks,

    Joel

    On Jul 6, 2013, at 7:41 PM, Steven Degutis wrote:

    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

    On Sat, Jul 6, 2013 at 8:52 PM, Joel Holdbrooks wrote:

    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*<https://github.com/noprompt/garden/blob/master/src/garden/stylesheet/pseudo_classes.clj>
    .

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

    Thanks,

    Joel

    On Jul 6, 2013, at 6:58 AM, Steven Degutis wrote:

    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<https://github.com/noprompt/garden/issues/5#issuecomment-19848873>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

    On Tue, Apr 9, 2013 at 2:58 PM, Joel Holdbrooks wrote:

    Nobel Clojurians,

    I am pleased to announce the alpha version of *Garden*<https://github.com/noprompt/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* <https://github.com/noprompt/garden>.
    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)


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google
    Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.

    For more options, visit https://groups.google.com/groups/opt_out.





    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups
    "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clojure@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+unsubscribe@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 the Google Groups "Clojure" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupclojure @
categoriesclojure
postedApr 9, '13 at 8:02p
activeJul 7, '13 at 2:46p
posts26
users8
websiteclojure.org
irc#clojure

People

Translate

site design / logo © 2022 Grokbase