> > 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 <cjholdbro...@gmail.com>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 <sbdegu...@gmail.com> 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 <cjholdbro...@gmail.com>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 <sbdegu...@gmail.com> 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 >> <cjholdbro...@gmail.com>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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
