Output differences between regular REPL and Light Table about garden HOT 8 CLOSED

Is that @media to be expected?

No.

The whole line/column thing makes me think this is a meta-data issue.

It is. In your case I'm guessing the extra meta data is coming from LightTable but I could be wrong. The good news is this is patched for v1.0.0 here. Even though treating raw meta data as a media query in the context of a stylesheet is a nice convenience, it can (obviously) blow up in your face. Like it's doing here.

v1.0.0 will require media query information be explicitly contained within :media key value. Unfortunately, I won't be able to get it out for a few more weeks since I'm extremely busy and haven't had a chance to finish working on it.

You could clone the repo, checkout the v1.0.0 branch, bump the version in project.clj, and do a lein install. If you do that be aware there is are some breaking changes notably around property values. {:foo [1 2 3]} now means foo: 1 2 3 and {:foo [[1 2] 3]} means foo: 1 2, 3).

from garden.

Joel,

Sweet, thanks. It won't be much of a problem, I can do a local maven install from the JAR like you said, so I'll go an do that. Great response time btw...

update: Yup that fixes it, last line

Now I'm a happy camper again :)

Cheers.

Rob

from garden.

@noprompt

• Is there anything you want me to do perhaps that is laying around? I'm redoing some customer CSS in Clojure, I assume normalization isn't built-in yet? Or do you already reset to sane defaults / have some preamble for CSS final rendering going on?

I should probably check the source some more, I'll probably add some stuff for myself I might find useful depending on what is/isn't there but I figured if you have any prio's/task I could look at them in the meanwhile.

• Also, I figure since they didn't got mentioned, no support for things like these yet?

#element {  
    background: -moz-linear-gradient(black, white); /* FF 3.6+ */  
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #000000), color-stop(100%, #ffffff)); /* Safari 4+, Chrome 2+ */  
    background: -webkit-linear-gradient(black, white); /* Safari 5.1+, Chrome 10+ */  
    background: -o-linear-gradient(black, white); /* Opera 11.10 */  
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#000000', endColorstr='#ffffff'); /* IE6 & IE7 */  
    -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr='#000000', endColorstr='#ffffff')"; /* IE8+ */  
    background: linear-gradient(black, white); /* the standard */  
}  

Meaning the (black,white) form in particular I assume isn't around yet.

1. Although arbitrarily done self, I assume also no (margin) or (padding) like functions that combine them into 1? I mean like {:margin [10 10 10 10]} cause that seems to print the wrong stuff.

from garden.

Since I've got some free time this evening and feel the pressure's on I'm working more on v1.0.0. 😄 The current state of the v1.0.0 branch (6682d9a) is in a bit of a half-baked state, but I should be pushing some new stuff within the next couple hours.

Also, I figure since they didn't got mentioned, no support for things like these yet?

Not directly, but I'll try to make that sort of thing easier. For example the current (unpushed) work I'm doing would allow you to write

(import 'garden.types.CSSFunction)

(let [cssfn (fn [fn-name]
              (fn [& args]
                (CSSFunction. fn-name args)))
      -moz-linear-gradient (cssfn "-moz-linear-gradient")
      -webkit-linear-gradient (cssfn "-webkit-linear-gradient")
      -o-linear-gradient (cssfn "-o-linear-gradient")
      linear-gradient (cssfn "linear-gradient")
      color-stop (cssfn "color-stop")]
  (css
    {:output-style :expanded}
    [:#element
     {:background #{(-moz-linear-gradient :black :white)
                    (-webkit-linear-gradient :linear
                                             [:left :top]
                                             [:left :bottom]
                                             (color-stop "0%" "#000000")
                                             (color-stop "100%" "#ffffff"))
                    (-webkit-linear-gradient :black :white)
                    (-o-linear-gradient :black :white)
                    (linear-gradient :black :white)}}]))

and give you

#element {
  background: -o-linear-gradient(black, white);
  background: -moz-linear-gradient(black, white);
  background: linear-gradient(black, white);
  background: -webkit-linear-gradient(black, white);
  background: -webkit-linear-gradient(linear, left top, left bottom, color-stop(0%, #000000), color-stop(100%, #ffffff));
}

This could definitely be touched up but some nice things have been added like the use of sets to describe multiple background attributes in one go.

I don't plan to attempt the suggestions in #3 because that would lead to a long list of potential issues. Instead I would prefer a separate library compatible with v1.x.x once it's released.

Although arbitrarily done self, I assume also no (margin) or (padding) like functions that combine them into 1? I mean like {:margin [10 10 10 10]} cause that seems to print the wrong stuff.

If you're on the v1.0.0 branch and try something like (css {:margin [10 10 10 10]}) you'll get back the empty string. There are some reasons for this I will explain once I've rounded out some of the rough edges I've created. 😄 Also, note the breaking change I mentioned above.

;; Old style
user> (css [:div {:margin [10 10 10 10]}])
"div{margin:10 10 10 10}"

;; New style
user> (css [:div {:margin [[10 10 10 10]]}])
"div{margin:10 10 10 10}"

The motivation for this change can be seen in the following example.

;; Old style
user> (css [:x {:foo [[10 10] 10]}])
"x{foo:10, 10 10}"

This is a problem. What you now must do to fix this is wrap it with another [] pair.

;; Old style
user> (css [:x {:foo [[[10 10] 10]]})
"x{foo:10 10, 10}"

Now, we have what we want but it's extremely noisy and very hard to write wrappers for.

Anyhow, I'm going to continue working on garden this evening and see if I can't get an RC out soon.

from garden.

Dude, you're doing a great job.

Anyhow, I'm going to continue working on garden this evening and see if I can't get an RC out soon.

No need to rush things for me though. By all means. Either way, I can pretty much do anything myself already, especially if I'd use backtick to syntax-quote my forms, it's really not so much an issue as I was interested in your ideas and how/what parts of the CSS you wanted to develop further in garden.

So perhaps a few additional remarks I found this morning, before I head off to the dentist for 1.5 hours of fun:

I noticed there is no mentioning of the direct descendant selector > got it up and coming too? This particular CSS really requires it (but I should probably fix/refactor it instead)

Do you know the Stylus library? It is a JS-based style preprocessor like Sass or SCSS but a tad more powerful and expressive (and more bugs!). If not: really you need to because it has a lot of ideas done quite nicely.

• One such item is vendor prefixes which just works like this in 9/10 cases I guess (some have a slightly different pattern). http://learnboost.github.io/stylus/docs/interpolation.html This because I noticed you didn't have vendor pre-fixes abstracted anywhere.
• In case you hadn't seen this baby yet: https://github.com/brandonbloom/backtick. I'm gonna have a sweet time generating symbols for my CSS those parts I can easily template out, I'm still pondering how I should have it work with hiccup but this'll prove nice playtime to help me figure that out. I guess it all depends on what you find workable for you though, like I said some regular vars and functions can really already clean up your styles nicely.

from garden.

I noticed there is no mentioning of the direct descendant selector > got it up and coming too? This particular CSS really requires it (but I should probably fix/refactor it instead)

Direct descendants are one of those weird ones I haven't really hacked on because they're still possible to achieve. Here are a few examples:

user> (css [:h1 [:&>a {:font-weight "bold"}]])
"h1>a{font-weight:bold;}"
user> (css [:h1 ["& > a" {:font-weight "bold"}]])
"h1 > a{font-weight:bold;}"
user> (css [:h1 [:> [:a {:font-weight "bold"}]]])
"h1 > a{font-weight:bold;}"
user> (css ["h1 >" [:a {:font-weight "bold"}]])
"h1 > a{font-weight:bold;}"
user> (css ["h1 > a" {:font-weight "bold"}])
"h1 > a{font-weight:bold;}"

Do you know the Stylus library?

Yes I'm familiar with it but I've never used it in practice.

If not: really you need to because it has a lot of ideas done quite nicely.

It certainly does. Here is a translation of the examples:

Stylus:

vendor(prop, args)
    -webkit-{prop} args
    -moz-{prop} args
    {prop} args

Clojure:

;; No need for interpolation! Just use a nested map! (This is already possible in beta.)
(defn vendor [prop args]
  {:-webkit {prop args}
   :-moz {prop args}
   prop args})

Stylus:

border-radius()
    vendor('border-radius', arguments)

box-shadow()
    vendor('box-shadow', arguments)

Clojure:

;; Can Stylus curry? I'm not sure but I doubt it!
(def border-radius (partial vendor "border-radius"))
(def box-shadow (partial vendor "box-shadow"))

Stylus:

button
    border-radius 1px 2px / 3px 4px

Clojure:

;; OK Stylus sort of wins here. :)
(css {:output-style :expanded}
      [:button
       (border-radius [[(px 1) (px 2) "/" (px 3) (px 4)]])])

Result:

button {
  border-radius: 1px 2px / 3px 4px;
  -moz-border-radius: 1px 2px / 3px 4px;
  -webkit-border-radius: 1px 2px / 3px 4px;
}

Stylus:

table
  for row in 1 2 3 4 5
    tr:nth-child({row})
      height: 10px * row

Clojure:

(css {:output-style :expanded}
  [:table
   (for [row (range 1 6)]
     [(format "tr::nth-child(%d)" row)
      {:height (px (* 10 row))}])])

;; Or

(require '[garden.stylesheet.pseudo-classes :refer [nth-child]]
         '[garden.units :refer [px*]])

(css {:output-style :expanded}
  [:table
   (for [row (range 1 6)]
     [:tr
      (nth-child row
        {:height (px* 10 row)})])])

Result:

table tr::nth-child(1) {
  height: 10px;
}

table tr::nth-child(2) {
  height: 20px;
}

table tr::nth-child(3) {
  height: 30px;
}

table tr::nth-child(4) {
  height: 40px;
}

table tr::nth-child(5) {
  height: 50px;
}

Even if it's not always as concise as Stylus (by default) the real win for us is Clojure. That alone affords us a tremendous amount of power not possible in any CSS preprocessor. Which is why something like backtick - and thanks for sharing it - would be awesome in conjunction with Garden.

from garden.

Ah, I missed a bracket in trying out the direct descendants. These seem fine to me so I get why you hadn't looked at them yet. Might be worth a mention in the README but seems fine for the rest.

I have to be honest, after digging in a bit more on the vendor prefix world, seems like the stylus way is far from ideal (I knew that) in the sense that it, and any 'generic' function for that matter is not going to match the real world out there: http://peter.sh/experiments/vendor-prefixed-css-property-overview/

Those are the kind of things that always make me think: how strict should we be? With the browser and HTML being extremely fault tolerant, CSS though is far less lenient when it goes to keeping the cascading flow going should something block the pipeline. But as far as I know things like -o-border-radius and other browser specific hellish items might not work or serve no function perhaps for those people, but they won't get in your way either. Its near impossible to fully implement all those things without doing some heavy defensive coding or taking away the liberty of say Gardens users, by restricting to only allow for certain properties, or elements and such, if only because they keep changing this stuff all the time, vendors do what they want, standards are near impossible to reach (if any) within acceptable time-frames and so on.

I guess that all was needed to say that I can conclude that I'm happy with what we've got and internet is a very messy place some of it often better left untouched (by the mind or hand).

p.s. thanks for the illustrations!

p.p.s

;; Can Stylus curry? I'm not sure but I doubt it!

Well its possible sure, although not done at the moment by many people:

function curry (fn, scope) {
    var scope = scope || window;
    var args = [];
    for (var i=2, len = arguments.length; i < len; ++i) {
        args.push(arguments[i]);
    };
    return function() {
        fn.apply(scope, args);
    };
}

But the problem really is, as always, with stylus is that hides complexity to an extent much further than others like LESS or SCSS do. Also the number of issues for the project was large 200+ at the time I think (also means it popular I guess) but TJ had 100+ projects running which was problematic to the least. My focus however was not on that aspect of technical implementations (it's a complicated mess in the back, stylus), more so on the elegance/ease of use of the expressions. Of course we (Clojure) will damn near always pwn any language out there :)

Anyway, more and more these things (to me at least) seem like a philosophical question more than anything else: "Do we want to try and prevent to user from making any mistakes?" If we follow the Clojure philosophy, you might be tempted to say Yes! to an extent we will do our best to prevent people from making mistakes but should it be applied here or there, project maintainers/authors should decide of course. That is, with regards to possible (in)valid vendor prefixes you see solutions like http://prefixmycss.com/ which do seem to hold internal reference of which vendors use which prefixes (the -o- missing here, -ms- also if you evaluate the default CSS the text box has).

Oh well. I don't have the illusion anyone will change the world we live in any day soon and as such, everyone has to take their own responsibility as well. Language/protocol fault-tolerance (HTML/CSS) can't really be an excuse for not doing the right thing like making stuff up such as vendor prefixes that don't exists.

If, how strict, where and to what extent these things should be applied/enforced (this goes for pretty much everything that has a finite set of options in css/whatever project) I always find hard to judge - being an INTP that is not my strong side really - but also, since it's not my project. Hence the reason of my inquiries now and then.

Thanks for your time at least to provide me with some answers, I know that is something we all tend to struggle with and find having too little (time).

from garden.

On a whole different note, I thought you might appreciate the last few functions of the core.clj file and the palettes function in palettes.clj. They're pretty neat and could complement the current color functions in garden possibly. https://github.com/andypayne/tinter/tree/master/src/tinter

from garden.