Closed brianloveswords closed 11 years ago
@rossbruniges @k88hudson do you have an opinion about this? Kate, if I recall correctly you're a stylus fan?
less for me - in so much that it's what the rest of Mozilla webdev use.
Of course you can write decent css without it so would mark this task as more of a thing when totally refactoring everything...
On Sunday, September 23, 2012, Brian J Brennan wrote:
@rossbruniges https://github.com/rossbruniges @k88hudsonhttps://github.com/k88hudsondo you have an opinion about this? Kate, if I recall correctly you're a stylus fan?
— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/openbadges/issues/351#issuecomment-8801329.
We use LESS in popcorn and it works pretty well, with a few annoying exceptions, such as:
1 You can't interpolate property names, so
myCoolMixin( prop, val ) {
-webkit-{prop}: val;
}
is only possible in stylus.
2 No real functions, so you also can't do
someClass {
width: grid( 4 );
}
where grid() is a function.
3 No real conditionals, so instead of
myMixin( val )
if ( val > 10 )
//something
else
//something else
you have to write
.myMixin( val ) when ( val > 10 ) {
// something
}
.myMixin( val ) when ( val <= 10 ) {
// something
}
That being said, if you're planning on borrowing/sharing mixins and stuff across projects, might be better to go with LESS.
I find the LESS syntax confusing, and stylus seems a bit more elegant, BUT I don't think that trumps having the shared knowledge of LESS across projects. Plus nobody is saying "Oh god no, not LESS" so I guess it can't be that bad.
@Pomax, are you (relatively) happy with LESS?
I don't like things with syntax that makes my eyes bleed, so I like Stylus more than LESS. I guess it depends on how much we want to rely on it - if it's CSS preprocessing, it doesn't really matter that other people use LESS and we use Stylus. As an anti-traditionalist, that justification just means our organisation is forcing everyone to use LESS forever ;)
If Stylus is nicer to read and has some features we want to make use of, Stylus is a better choice. If it doesn't matter functionality wise, either probably works, and it mostly depends on how much we want to trade off "nice to work with for people who aren't absolutely in love with CSS" vs. "people we can just poke and ask when we get stuck".
(I know, a bit non-committal. I don't like LESS, but not enough to refuse to work with it)
I'm a strong believer that you CAN write good CSS with LESS and work around the syntax being a bit crap. I don't think we've (Mozilla) found that yet but I reckon with a bit of a good planning we can nail it!
Like with all frameworks - you can use it for good/bad, and I reckon that if your stuff is bad enough to make your eyes bleed then you're potentially using it for bad!
definitely; LESS can, ultimately, do the same thing as Stylus of course (it all ends up being compiled to plain CSS anyway before it hits the client. Unless you use the client side library. Which you probably shouldn't, because that'll break in anything that has JS turned off or limited or whatever).
Sounds like we're going with LESS?
(NB: anything that uses @ or $ or var(...) where there is no ambiguity and thus no need for syntactic sugar is eye-bleeding to me =)
On 9/24/2012 12:07 PM, Ross Bruniges wrote:
I'm a strong believer that you CAN write good CSS with LESS and work around the syntax being a bit crap. I don't think we've (Mozilla) found that yet but I reckon with a bit of a good planning we can nail it!
Like with all frameworks - you can use it for good/bad, and I reckon that if your stuff is bad enough to make your eyes bleed then you're potentially using it for bad!
— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/351#issuecomment-8830619.
Sorry @pomax, we're SWITCHING TO PERL!!!
There's more to share than just syntactical knowledge; there are best practices, gotchas, and stuff like build tools. All of that stuff is useful to have access to. Plus the warm fuzzy feeling that you're being a team player. Which I would happily not do if others seemed to regret using LESS, but they don't.
So I'd say we go with LESS and you can say "I told you so" if/when it all blows up in our faces.
On 9/25/2012 3:15 PM, Mike Larsson wrote:
Sorry @Pomax https://github.com/Pomax, we're SWITCHING TO PERL http://perl.plover.com/obfuscated/japh.pl!!!
There's more to share than just syntactical knowledge; there are best practices, gotchas, and stuff like build tools. All of that stuff is useful to have access to. Plus the warm fuzzy feeling that you're being a team player. Which I would happily not do if others seemed to regret using LESS, but they don't.
So I'd say we go with LESS and you can say "I told you so" if/when it all blows up in our faces.
— Reply to this email directly or view it on GitHub https://github.com/mozilla/openbadges/issues/351#issuecomment-8872299.
Oh my god, you so had me at PERL... LESS is acceptable too I guess, but I doubt it'll support $ and @ - and argument-less functions! (no, PERL 6, you don't count, you're not real)
I DECLARE THIS THREAD SUCCESS
(@Pomax and @k88hudson need github avatars)
the moment github allows me to use a picture specifically on github, rather than using gravatar and leaking my identity all over the place, I will set one up! =D
Ahh, unlikely that will happen (the co-founder of github made gravatar).
Oh cool... but also, yeah, that's unlikely to happen then =x
Alongside this would like to hear peoples thoughts about tools like codeKit (which annoyingly I can't currently use but feel like massive productivity boosters)
I tried out LiveReload and ended up not using it very often, although I think a big part of that is that I'm typically just working on my laptop screen and don't have the screen real estate to have my coding window and browser open side-by-side. I like the idea of it still.
Seems like codekit offers more than the live update, too.
Yeah - the big video features one of the less exciting parts of the project. The stuff I like are the image optimisation tools, CSS/JS compilers and auto-linting (because you can never have too many checks for that kinda stuff).
I don't care which one, really, but we should be preprocessing because native CSS is awful.
@stenington, @Pomax I'll leave it to you guys to decide but we should probably pick something by end of day Monday at the latest!