-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Output differences between regular REPL and Light Table #12
Comments
No.
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
You could clone the repo, checkout the |
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.
#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
|
Since I've got some free time this evening and feel the pressure's on I'm working more on
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 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
If you're on the ;; 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 ;; 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. |
Dude, you're doing a great job.
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 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.
|
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;}"
Yes I'm familiar with it but I've never used it in practice.
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:
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. |
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
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 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). |
On a whole different note, I thought you might appreciate the last few functions of the |
Hey guys, I hope one of you has an idea where the following discrepancy could be coming from since I really don't think I've seen this much diff between LT and regular REPL output so my first stop would be here I guess.
update: Ok so I narrowed this down a bit more
file:
compiler.clj
The problem is that since LT has another writer hooked up, or at least me thinks that is, so I need to resolve meta from vars like
(meta #'first)
but I'm not sure, keep digging for now.The text was updated successfully, but these errors were encountered: