Opinions on LESS
Permalink 4 users found helpful
Any LESS users out there?
Would love to hear your opinions on using LESS, In your opinion is it worth using? do the pros, outweigh the cons? do you find yourself using one set of features far more than another? etc etc, anything you feel is good bad or ugly, would like to hear your thoughts.
Would love to hear your opinions on using LESS, In your opinion is it worth using? do the pros, outweigh the cons? do you find yourself using one set of features far more than another? etc etc, anything you feel is good bad or ugly, would like to hear your thoughts.
I've begun using it... and so far I really like it. Has it solved some big, overarching problem I was having with CSS? No. But it does lots of little things that, together, do make coding a bit easier (and, dare I say, more fun?!).
For instance:
- being able to define and use variables for things like a site's primary & secondary colors... while not earth-shattering, IS handy.
- creating mixins for things like the CSS3 stack of browser-specific code needed for creating rounded corners (or gradients) DOES save time... AND being able to pass in different sizes for the radius in each instance IS pretty handy! Plus... when/if we can finally just use the standard code to define this, I'll only need to edit one spot.
- the nature of LESS's structure DOES make my CSS files easier to read/understand (for me, anyway). Nesting selectors like that just works well with the way my brain works, I guess. ;)
But, actually, the thing that has been the biggest help (for me) ISN'T specifically about LESS. In getting started with LESS, I found Codekit (http://incident57.com/codekit/). Codekit understands LESS (and SASS and Stylis and Javascript and Coffeescript). It can be setup so that each time you save a LESS file, Codekit automatically processes it into CSS for you. You can even have it compress/minify it for you so your CSS loads faster.
So... by itself, LESS is cool. I like it. But LESS in combination with CodeKit is wicked... and has made coding in CSS... FUN!
Of course, YMMV!
- John
For instance:
- being able to define and use variables for things like a site's primary & secondary colors... while not earth-shattering, IS handy.
- creating mixins for things like the CSS3 stack of browser-specific code needed for creating rounded corners (or gradients) DOES save time... AND being able to pass in different sizes for the radius in each instance IS pretty handy! Plus... when/if we can finally just use the standard code to define this, I'll only need to edit one spot.
- the nature of LESS's structure DOES make my CSS files easier to read/understand (for me, anyway). Nesting selectors like that just works well with the way my brain works, I guess. ;)
But, actually, the thing that has been the biggest help (for me) ISN'T specifically about LESS. In getting started with LESS, I found Codekit (http://incident57.com/codekit/). Codekit understands LESS (and SASS and Stylis and Javascript and Coffeescript). It can be setup so that each time you save a LESS file, Codekit automatically processes it into CSS for you. You can even have it compress/minify it for you so your CSS loads faster.
So... by itself, LESS is cool. I like it. But LESS in combination with CodeKit is wicked... and has made coding in CSS... FUN!
Of course, YMMV!
- John
Thats great thanks guys, I was leaning towards the opinion that LESS solves a problem I didn't really have, I try to code to DRY principles to begin with, BUT, I guess it never harms to have something that scales nicely even at the beginning of small projects as you never know how they will expand. Codekit also looks very interesting, so in conclusion, think that I may give it a go, as I also work with our in-house boilerplate, and its always evolving and being updated it may just save us some time.
Thanks for the great input.
Thanks for the great input.
Cool. Let us know how it goes... would love to hear about YOUR experiences with LESS/Codekit.
Also... since you're already coding DRY, have you had any exposure/experience with the object-oriented CSS (ooCSS) stuff that Nicole Sullivan is a proponent of? I'd be curious to hear your (or Jordan's or anyone else's) take on it.
I've begun trying to use ooCSS principles (and even some of the template code available on thehttp://www.ooCSS.org website) and really like it. Makes a LOT of things easier to handle. I've started eliminating the use of ID's from my CSS... and only using classes for styling. ID's are used for JS... since JS can target ID's faster than classes.
- John
Also... since you're already coding DRY, have you had any exposure/experience with the object-oriented CSS (ooCSS) stuff that Nicole Sullivan is a proponent of? I'd be curious to hear your (or Jordan's or anyone else's) take on it.
I've begun trying to use ooCSS principles (and even some of the template code available on thehttp://www.ooCSS.org website) and really like it. Makes a LOT of things easier to handle. I've started eliminating the use of ID's from my CSS... and only using classes for styling. ID's are used for JS... since JS can target ID's faster than classes.
- John
I will let you know how I get on, going to download and have a play this week.
I did take a look at oocss when it first came out, I saw a vid of Nicole Sullivan talking about her work with Facebook, IMHO in just looked like some good practice guidelines to me, I was always under the impression that CSS should be used in this way, tearing away universal chunks of code away and storing them in their own class for re-use, to me, was what CSS was all about, keeping things small and agile to use again later, like @Mkly said I am not dismissing it, it was some time ago I looked into it. and a lot of the concepts are watertight, while some I feel may become detrimental, I wouldnt lose sleep if to make life easier I re-declared a few lines of code, or added some float declarations to a container etc, and from what I gather it lacks the dynamic nature of LESS and SASS, no variable declarations and stuff like that, so for me personally dont think it would be worth pursuing.
I do feel @Mkly touched on a very good point, with a lot of Frameworks, Boilerplates, Libraries, coming out on a more or less weekly basis, I do get an ever increasing sense of there being a "Me too" attitude in web development at present, its getting increasingly difficult to sort the wheat from the chaf, some of these things are just surplus to requirement, LESS was one of the things that kept catching my eye, which is why I wanted to get some feedback, if I'm going to spend some time learning new syntax, I need to be sure it will save me some time down the road, will definitely give it a try.
I did take a look at oocss when it first came out, I saw a vid of Nicole Sullivan talking about her work with Facebook, IMHO in just looked like some good practice guidelines to me, I was always under the impression that CSS should be used in this way, tearing away universal chunks of code away and storing them in their own class for re-use, to me, was what CSS was all about, keeping things small and agile to use again later, like @Mkly said I am not dismissing it, it was some time ago I looked into it. and a lot of the concepts are watertight, while some I feel may become detrimental, I wouldnt lose sleep if to make life easier I re-declared a few lines of code, or added some float declarations to a container etc, and from what I gather it lacks the dynamic nature of LESS and SASS, no variable declarations and stuff like that, so for me personally dont think it would be worth pursuing.
I do feel @Mkly touched on a very good point, with a lot of Frameworks, Boilerplates, Libraries, coming out on a more or less weekly basis, I do get an ever increasing sense of there being a "Me too" attitude in web development at present, its getting increasingly difficult to sort the wheat from the chaf, some of these things are just surplus to requirement, LESS was one of the things that kept catching my eye, which is why I wanted to get some feedback, if I'm going to spend some time learning new syntax, I need to be sure it will save me some time down the road, will definitely give it a try.
I second your feeling about the 'me-too' thing going round at the moment.
When I first tried LESS a few months ago I was really impressed, and I still use it on every new project now. For me the simple ability to inherit styles allows for much more logical layout of LESS files, which makes revisiting styles later on to tweak or change something a lot less of a headache - you can immediately see the logic of the styles and work out what it is you need to change.
I combine it with the HOWTO here (http://www.concrete5.org/documentation/how-tos/developers/dynamically-concatenate-minify-gzip-and-server-side-cache-multip/) on minifying and gzipping the files, and what's served up is a lovely block of CSS which is about as small as it's possible to get (assuming your styles are efficient, of course). Couple that with numerous LESS files for each element of the site (compiled together using the above How-to) and you get nice separation of code, which makes my life a lot easier when building a complex site (e.g. a style problem with the nav is going to be in navigation.less; a style in the footer will be in footer.less, etc). This approach feels really clean, logical and efficient to me, and it's been the biggest change in my workflow in several years I'd say (probably since moving from WYSIWYG editors to Notepad++).
When I first tried LESS a few months ago I was really impressed, and I still use it on every new project now. For me the simple ability to inherit styles allows for much more logical layout of LESS files, which makes revisiting styles later on to tweak or change something a lot less of a headache - you can immediately see the logic of the styles and work out what it is you need to change.
I combine it with the HOWTO here (http://www.concrete5.org/documentation/how-tos/developers/dynamically-concatenate-minify-gzip-and-server-side-cache-multip/) on minifying and gzipping the files, and what's served up is a lovely block of CSS which is about as small as it's possible to get (assuming your styles are efficient, of course). Couple that with numerous LESS files for each element of the site (compiled together using the above How-to) and you get nice separation of code, which makes my life a lot easier when building a complex site (e.g. a style problem with the nav is going to be in navigation.less; a style in the footer will be in footer.less, etc). This approach feels really clean, logical and efficient to me, and it's been the biggest change in my workflow in several years I'd say (probably since moving from WYSIWYG editors to Notepad++).
Cool, thanks for your input, I will check out that how-to link, I still havnt had time to have a proper go with LESS yet, hopefully this weekend ;-)
Yay opinions!
Sass is much better in my opinion, but LESS is certainly very good. Either way, once I started using sass a while back coding regular css was annoying and ugly to me. Nesting is a huge benefit for me when I am prototyping as it keeps everything organized as part of my workflow as opposed to in addition to. Same goes for colors, border radius, gradients etc. Again, it stay organized as part of my workflow. This is important imho.
Honestly, if someone can't pick up LESS/Sass in a couple hours, then they probably don't know CSS anyway. It's not very different.
One more bump for Sass is Compass and it's CSS3 X-compatibility library stuff. With all the cross-browser prefix junk this certainly speeds things up if you do a lot of css. Compass is usually overkill for me, but as I'm doing more CSS3 I'm probably going to move over to it.
The line between this stuff is pretty much the same kind of line drawn between ORM people and the "SQL is a DSL" crowd. New School Old School stuff.
Object Oriented CSS really just feels like consultants needing something to blog about and look like they are on the cutting edge.
Anyhow, that's my not even worth two cents.
Sass is much better in my opinion, but LESS is certainly very good. Either way, once I started using sass a while back coding regular css was annoying and ugly to me. Nesting is a huge benefit for me when I am prototyping as it keeps everything organized as part of my workflow as opposed to in addition to. Same goes for colors, border radius, gradients etc. Again, it stay organized as part of my workflow. This is important imho.
Honestly, if someone can't pick up LESS/Sass in a couple hours, then they probably don't know CSS anyway. It's not very different.
One more bump for Sass is Compass and it's CSS3 X-compatibility library stuff. With all the cross-browser prefix junk this certainly speeds things up if you do a lot of css. Compass is usually overkill for me, but as I'm doing more CSS3 I'm probably going to move over to it.
The line between this stuff is pretty much the same kind of line drawn between ORM people and the "SQL is a DSL" crowd. New School Old School stuff.
Object Oriented CSS really just feels like consultants needing something to blog about and look like they are on the cutting edge.
Anyhow, that's my not even worth two cents.
@mkly,
I'm curious... removing Compass from the equation, what do you find better about SASS than LESS?
I'm not doing that much with CSS3, so found that Compass seemed like overkill for me. So I haven't had that as a compelling reason to switch, but I'm wondering if I'm missing something about SASS.
As for ooCSS... you may be right. It could be, outwardly, just a "consultant's label" used to seem "cutting edge". But I've found implementing it to actually be a benefit. Maybe it's because I'm not a particularly advanced CSS coder... and this was my first exposure to DRY development. But, for me anyway, it struck a cord. And I've found the example/template code from the ooCSS.org site to be really cool. Nothing earth shattering... but cool, nonetheless. Grids that are infinitely nestable (not always possible with some grid systems). A modularity to the code that makes it feel more like a logical addition to an MVC architecture. Blah, blah, blah. ;)
Anyway... my <=$0.02, too.
- John
I'm curious... removing Compass from the equation, what do you find better about SASS than LESS?
I'm not doing that much with CSS3, so found that Compass seemed like overkill for me. So I haven't had that as a compelling reason to switch, but I'm wondering if I'm missing something about SASS.
As for ooCSS... you may be right. It could be, outwardly, just a "consultant's label" used to seem "cutting edge". But I've found implementing it to actually be a benefit. Maybe it's because I'm not a particularly advanced CSS coder... and this was my first exposure to DRY development. But, for me anyway, it struck a cord. And I've found the example/template code from the ooCSS.org site to be really cool. Nothing earth shattering... but cool, nonetheless. Grids that are infinitely nestable (not always possible with some grid systems). A modularity to the code that makes it feel more like a logical addition to an MVC architecture. Blah, blah, blah. ;)
Anyway... my <=$0.02, too.
- John
Honestly, Sass and LESS are pretty similar. Sass is just more grown up/has a bigger crowd in my opinion.
http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html...
LESS is just fine and I use it sometimes. I just think Sass and LESS are so similar and Sass can just do more stuff, so what's really the point of using LESS at that point?
The Object Oriented CSS stuff is just fine with me. I'm not bashing on it. It just starts to feel like it's taking things a little too far. You become more skeptical of this stuff when you hang around Rails, but sometimes stuff gets created just to get created. I mean I don't want to open a new can of worms, but I remember when coffeescript came out. I just looked at coffeescript.org front page and it shows how much easier it is to do Array comprehensions... really? You're doing Array comprehensions? I'm not. And if I was I'd probably know javascript well enough that coffeescript would just be annoying. I'm not saying coffeescript sucks, it's just one of those ones that's starts to feel like it's there just cause it's cool or fun. Or makes you look like you're up on the latest jazz in your blog posts. Not really all that useful. Totally just my uneducated opinion though.
Just imho CSS is pretty simple stuff and that stuff starts to feel like someone trying to make something complicated or fancy out of something simple just for the sake of it.
The further reaches of Sass are similarly less than needed, but the don't get in the way, and you don't really need to learn much new stuff to use Sass/LESS.
http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html...
LESS is just fine and I use it sometimes. I just think Sass and LESS are so similar and Sass can just do more stuff, so what's really the point of using LESS at that point?
The Object Oriented CSS stuff is just fine with me. I'm not bashing on it. It just starts to feel like it's taking things a little too far. You become more skeptical of this stuff when you hang around Rails, but sometimes stuff gets created just to get created. I mean I don't want to open a new can of worms, but I remember when coffeescript came out. I just looked at coffeescript.org front page and it shows how much easier it is to do Array comprehensions... really? You're doing Array comprehensions? I'm not. And if I was I'd probably know javascript well enough that coffeescript would just be annoying. I'm not saying coffeescript sucks, it's just one of those ones that's starts to feel like it's there just cause it's cool or fun. Or makes you look like you're up on the latest jazz in your blog posts. Not really all that useful. Totally just my uneducated opinion though.
Just imho CSS is pretty simple stuff and that stuff starts to feel like someone trying to make something complicated or fancy out of something simple just for the sake of it.
The further reaches of Sass are similarly less than needed, but the don't get in the way, and you don't really need to learn much new stuff to use Sass/LESS.
LOL! I get what you mean. I worked in corporate quite a few years back... and the one thing that you could always count on was that consultants would be brought in in order to solve a problem, and would inevitably end up creating MORE problems by just complicating things that seemed so simple before they arrived. ;D
It's quite possible that, if you've got a developer's mind (which I assume you do), that you are a "natural" when it comes to abstracting your CSS classes into logical objects... keeping presentational semantics out of them, etc. I, unfortunately, do NOT have that kind of mind by default. It takes some work, sometimes, to avoid adding a class of "red" to an item that I want to make red... and instead find a more generic/abstracted concept behind it and use that instead... so that, 6 months down the line when the client changes their mind about the color and now ".red" items need to be green, you don't have to sift through your CSS files AND your HTML.
Of course, that "color" example is a pretty basic one. ooCSS can help to streamline your code by distilling your site elements down to their most basic concepts, naming those in non-semantic ways, etc.
If you've got the time, or want to learn more about it, try reading Nicole's blog entry about ooCSS entitled "Our (CSS) Best Practices Are Killing Us" here: http://www.stubbornella.org/content/2011/04/28/our-best-practices-a...
The embedded video of her presentation at Webstock 2011 was pretty eye-opening, too.
But maybe "ooCSS" is just a "label" for the way you're already working your CSS code... so it's unnecessary for you?
It's quite possible that, if you've got a developer's mind (which I assume you do), that you are a "natural" when it comes to abstracting your CSS classes into logical objects... keeping presentational semantics out of them, etc. I, unfortunately, do NOT have that kind of mind by default. It takes some work, sometimes, to avoid adding a class of "red" to an item that I want to make red... and instead find a more generic/abstracted concept behind it and use that instead... so that, 6 months down the line when the client changes their mind about the color and now ".red" items need to be green, you don't have to sift through your CSS files AND your HTML.
Of course, that "color" example is a pretty basic one. ooCSS can help to streamline your code by distilling your site elements down to their most basic concepts, naming those in non-semantic ways, etc.
If you've got the time, or want to learn more about it, try reading Nicole's blog entry about ooCSS entitled "Our (CSS) Best Practices Are Killing Us" here: http://www.stubbornella.org/content/2011/04/28/our-best-practices-a...
The embedded video of her presentation at Webstock 2011 was pretty eye-opening, too.
But maybe "ooCSS" is just a "label" for the way you're already working your CSS code... so it's unnecessary for you?
I remember reading a blog post about that. My opinion was actually "Stakeholder Demands Are Killing Us", but I guess that's another story for another day. ;)
I'm totally not saying it's bad. Seriously, if it helps you then that is awesome. Maybe I was sounding too much like I thought it was BS. I don't. You are correct in that I already do use concepts nav abstractions. I was really just saying the whole "Object Oriented CSS" label and giving it a lot of additional structure. Like MVC really benefits from forced structure and relearning some things, because good old fashion procedural programming and ridiculous 10,000 line function files and massive unreadable index.php files with switch statements were idiotic and painful. And ORMs are great because silly multiple join SQL statements with pivot tables, constraints etc, at least to me, are awkward to write and eye watering to read.
CSS can benefit from best practices, and there are a lot of important ones, but trying to create a whole new paradigm seems imho a little heavy handed. I've seen some CSS files that took a couple minutes to sort out for sure, but I've seen old perl/python/php code that is just pointless to even try to understand or edit cause it's so all over the place.
So ya, I totally think the concepts are good. Just don't get stuck down the hour of googling for the best non-semantic abstraction for unordered list of flower names.
I'm totally not saying it's bad. Seriously, if it helps you then that is awesome. Maybe I was sounding too much like I thought it was BS. I don't. You are correct in that I already do use concepts nav abstractions. I was really just saying the whole "Object Oriented CSS" label and giving it a lot of additional structure. Like MVC really benefits from forced structure and relearning some things, because good old fashion procedural programming and ridiculous 10,000 line function files and massive unreadable index.php files with switch statements were idiotic and painful. And ORMs are great because silly multiple join SQL statements with pivot tables, constraints etc, at least to me, are awkward to write and eye watering to read.
CSS can benefit from best practices, and there are a lot of important ones, but trying to create a whole new paradigm seems imho a little heavy handed. I've seen some CSS files that took a couple minutes to sort out for sure, but I've seen old perl/python/php code that is just pointless to even try to understand or edit cause it's so all over the place.
So ya, I totally think the concepts are good. Just don't get stuck down the hour of googling for the best non-semantic abstraction for unordered list of flower names.
"CSS can benefit from best practices, and there are a lot of important ones, but trying to create a whole new paradigm seems imho a little heavy handed."
I guess I just see ooCSS AS a best practice... NOT as a framework/system that's adding "a lot of additional structure." Actually, when you look at some of the implementation of ooCSS, you can see how it SIMPLIFIES the structure.
And Nicole points out how some of the existing, perceived "best practices" are actually impairing page load times and code maintainability, etc. So I guess it just resonated with me (probably because I was doing some of the things she points out as being problematic and have found ooCSS to be a means of solving). But it's definitely NOT for everyone.
"So ya, I totally think the concepts are good. Just don't get stuck down the hour of googling for the best non-semantic abstraction for unordered list of flower names."
Trust me... I won't! I spend ENOUGH time googling for all sorts of OTHER crap, I don't need to be doing it for that, too! LOL!
And don't get me wrong... I don't mean to be on here proselytizing for ooCSS. I'm by no means an expert... or some kind of ooCSS missionary! I appreciate your input into the conversation. It's FUN to talk about "opinions" and stuff... don't get to do it often on here. ;D
Happy coding!
- John
I guess I just see ooCSS AS a best practice... NOT as a framework/system that's adding "a lot of additional structure." Actually, when you look at some of the implementation of ooCSS, you can see how it SIMPLIFIES the structure.
And Nicole points out how some of the existing, perceived "best practices" are actually impairing page load times and code maintainability, etc. So I guess it just resonated with me (probably because I was doing some of the things she points out as being problematic and have found ooCSS to be a means of solving). But it's definitely NOT for everyone.
"So ya, I totally think the concepts are good. Just don't get stuck down the hour of googling for the best non-semantic abstraction for unordered list of flower names."
Trust me... I won't! I spend ENOUGH time googling for all sorts of OTHER crap, I don't need to be doing it for that, too! LOL!
And don't get me wrong... I don't mean to be on here proselytizing for ooCSS. I'm by no means an expert... or some kind of ooCSS missionary! I appreciate your input into the conversation. It's FUN to talk about "opinions" and stuff... don't get to do it often on here. ;D
Happy coding!
- John
Cool discussion. Here's my less-than-2-cents on ooCSS:
I was excited about it and understood the problems she was trying to solve, but I could not for the life of me figure out what exactly it *is*. I only ever found the slides of her presentation. I'll have to check out that video you linked to sometime.
The one huge takeaway from it that I did understand though is the concept of limiting the scope of styles to just one area. This combined with finally understanding the whole specificity thing and using classes instead of id's all over the place was a huge help in my CSS coding practices (especially in an environment like C5 where you actually have different "objects" in the Nicole-Sullivan-sense -- C5 blocks that users can add to any page).
But I also think since she work(ed?) for Yahoo!, she has a *very* different set of problems to solve than any of us here (that is, we implement a design on one relatively small site, as opposed to coming up with design elements that live across many different sites and "properties").
I was excited about it and understood the problems she was trying to solve, but I could not for the life of me figure out what exactly it *is*. I only ever found the slides of her presentation. I'll have to check out that video you linked to sometime.
The one huge takeaway from it that I did understand though is the concept of limiting the scope of styles to just one area. This combined with finally understanding the whole specificity thing and using classes instead of id's all over the place was a huge help in my CSS coding practices (especially in an environment like C5 where you actually have different "objects" in the Nicole-Sullivan-sense -- C5 blocks that users can add to any page).
But I also think since she work(ed?) for Yahoo!, she has a *very* different set of problems to solve than any of us here (that is, we implement a design on one relatively small site, as opposed to coming up with design elements that live across many different sites and "properties").
Jordan,
Your question about what ooCSS *is* I think strikes at the heart of the confusion about it. Mkly had some of the same issue... seeing ooCSS as a consultant's "label" kind of thing (which isn't really wrong).
I don't think ooCSS *IS* a "thing"... it's an idea, a concept, a methodology. Not really any different than object oriented coding in any other language. What *is* object oriented programming?
They specifically talk about the concepts of ooCSS as being a natural fit for CMS environments... and I can't think of a BETTER fit than C5. Like you said... blocks are natural "objects".
Like you, I had an "ah-hah" moment when hearing about the specificity issues associated with ID's and classes... and having now implemented a classes-only approach to my CSS has definitely helped. No more "!important" declarations to force a style because I can't figure out why it's not taking hold. LOL!
And, true: Nicole is coming at all of this from a very large-scale website perspective. Yahoo. Facebook. Really large, high-traffic websites where a small improvement in page load times can have a significant impact on reducing bandwidth usage, etc. That aspect of it is probably not an issue for most C5 users. But the simplification of code by distilling your site down to a minimal number of "objects" CAN'T be a bad thing, right?
For instance, Nicole talks about having done work with Facebook... and that work had identified that the Facebook website really could be distilled down to a great number of instances of what they ended up terming the "media block" - basically a graphic/video object with text next to it (look at Facebook and you can see it right away). By simplifying both the code and the CSS to re-use this simple block concept, they made HUGE improvements in the speed AND maintainability of the site.
Now, again... this was with FACEBOOK. Small improvements can have dramatic results when you're talking about one of the most visited websites in the country (if not the world). But, still... I think the idea is beneficial on any scale.
Can you function as a CSS coder without any of this? Of course. But is "spaghetti" CSS good? No... probably not as bad as spaghetti PHP or JS code, but still, not ideal. So ooCSS is just one (of many) "best practice" approaches to trying to bring a logical and systematic design principle to it. Like many other "best practices", there's not ONE specific way to do it. It's a mind-set, more than anything else.
I'll step down off my soap-box for the day. ;D
- John
Your question about what ooCSS *is* I think strikes at the heart of the confusion about it. Mkly had some of the same issue... seeing ooCSS as a consultant's "label" kind of thing (which isn't really wrong).
I don't think ooCSS *IS* a "thing"... it's an idea, a concept, a methodology. Not really any different than object oriented coding in any other language. What *is* object oriented programming?
They specifically talk about the concepts of ooCSS as being a natural fit for CMS environments... and I can't think of a BETTER fit than C5. Like you said... blocks are natural "objects".
Like you, I had an "ah-hah" moment when hearing about the specificity issues associated with ID's and classes... and having now implemented a classes-only approach to my CSS has definitely helped. No more "!important" declarations to force a style because I can't figure out why it's not taking hold. LOL!
And, true: Nicole is coming at all of this from a very large-scale website perspective. Yahoo. Facebook. Really large, high-traffic websites where a small improvement in page load times can have a significant impact on reducing bandwidth usage, etc. That aspect of it is probably not an issue for most C5 users. But the simplification of code by distilling your site down to a minimal number of "objects" CAN'T be a bad thing, right?
For instance, Nicole talks about having done work with Facebook... and that work had identified that the Facebook website really could be distilled down to a great number of instances of what they ended up terming the "media block" - basically a graphic/video object with text next to it (look at Facebook and you can see it right away). By simplifying both the code and the CSS to re-use this simple block concept, they made HUGE improvements in the speed AND maintainability of the site.
Now, again... this was with FACEBOOK. Small improvements can have dramatic results when you're talking about one of the most visited websites in the country (if not the world). But, still... I think the idea is beneficial on any scale.
Can you function as a CSS coder without any of this? Of course. But is "spaghetti" CSS good? No... probably not as bad as spaghetti PHP or JS code, but still, not ideal. So ooCSS is just one (of many) "best practice" approaches to trying to bring a logical and systematic design principle to it. Like many other "best practices", there's not ONE specific way to do it. It's a mind-set, more than anything else.
I'll step down off my soap-box for the day. ;D
- John
re: ooCSS -- I think I didn't make my attitude clear -- I *love* the idea of it and was very intrigued by the slides I saw, I just couldn't actually figure out *how* to do it exactly (other than the "use classes not id's" thing). Do you have a tutorial or some detailed walk-through you've found? (I do a lot better with written material than videos).
That's cool, Jordan. I hope my response didn't come across as too preachy... TONE is so hard to convey in black & white! ;D
Other than watching Nicole's video from her presentation at Webstock 2011 that's embedded in the blog post I put the link to earlier... I think the only thing that's helped was the sample code from the ooCSS.org website itself. You can download what's called the "Velocity Download" (named for a conference, I think) and start poking around in the examples.
For me, I had just started using the 960 Grid CSS (I know, late to the game!), when I read about ooCSS and looked at the "grid.css" file included in the example. It's not really that much different from most of the grids out there, but just struck a cord with me. I liked the easy nestability of the grids, without having to use additional classes to deal with gutters/padding on the inner grids, etc. It just worked.
Of course, the sample code is just that. Sample. But it incorporates some of the "best practice" approaches to various coding issues (clearfix, grids, etc), so it's a good starting point.
Hope that helps!
- John
Other than watching Nicole's video from her presentation at Webstock 2011 that's embedded in the blog post I put the link to earlier... I think the only thing that's helped was the sample code from the ooCSS.org website itself. You can download what's called the "Velocity Download" (named for a conference, I think) and start poking around in the examples.
For me, I had just started using the 960 Grid CSS (I know, late to the game!), when I read about ooCSS and looked at the "grid.css" file included in the example. It's not really that much different from most of the grids out there, but just struck a cord with me. I liked the easy nestability of the grids, without having to use additional classes to deal with gutters/padding on the inner grids, etc. It just worked.
Of course, the sample code is just that. Sample. But it incorporates some of the "best practice" approaches to various coding issues (clearfix, grids, etc), so it's a good starting point.
Hope that helps!
- John
For what it's worth, Chris Coyer recently did an article comparing SASS & LESS.
http://css-tricks.com/sass-vs-less/...
I'm pretty comfortable with LESS and a modified version of lessphp ( for adding features which should have been built in like checking all files including the @import's when new versions are available, rather than having to manual compile the LESS code every time you make changes plus other random things like lessphp changing the LESS syntax around which broke a bunch of LESS code for example Twitter Bootstrap won't work with the original lessphp ) ...
Anyways, after reading this article as well as this thread here I'm going to switch to SASS. It clearly has more advantages for one willing to invest in preprocessing their CSS haha
haha not worth two cents but that link to the Chris's article should be
http://css-tricks.com/sass-vs-less/...
I'm pretty comfortable with LESS and a modified version of lessphp ( for adding features which should have been built in like checking all files including the @import's when new versions are available, rather than having to manual compile the LESS code every time you make changes plus other random things like lessphp changing the LESS syntax around which broke a bunch of LESS code for example Twitter Bootstrap won't work with the original lessphp ) ...
Anyways, after reading this article as well as this thread here I'm going to switch to SASS. It clearly has more advantages for one willing to invest in preprocessing their CSS haha
haha not worth two cents but that link to the Chris's article should be
After a lot of experimenting and trial and error, I too have now settled on SASS, it just seemed to click for me. I currently use Codekit which is an amazing programe and handles all the compiling etc.
using SASS sped up my workflow, mixins and variables are a bigger time saver than i anticipated, and as far as organisation goes my CSS has improved a lot.
So far pretty happy with my coding set up.
using SASS sped up my workflow, mixins and variables are a bigger time saver than i anticipated, and as far as organisation goes my CSS has improved a lot.
So far pretty happy with my coding set up.
Hmmm... making me re-think my choice of LESS. I've been using it with Codekit, too. Love that Codekit auto-compiles files as they are changed. And I really like LESS's "CSS-y" syntax. Seems to just click with me. But SASS is sounding pretty darn appealing! ;D
Might have to spend some time re-trying SASS and re-evaluating my choice.
- John
Might have to spend some time re-trying SASS and re-evaluating my choice.
- John
Hey John, I think it was you that mentioned Codekit to me in the first place, when I saw that it supported SASS and LESS I thought I would give them both a try, and although they are very similar, for some strange reason i just gravitated towards SASS more in the end.
My current setup is SASS running through Codekit, with Sublime text 2 as my editor, with the SASS package, working well for me.
-David
My current setup is SASS running through Codekit, with Sublime text 2 as my editor, with the SASS package, working well for me.
-David
Well... if I did, glad you're enjoying it! ;D I'm loving Codekit, myself. Regardless of your CSS-pre-processor-of-choice, Codekit just makes coding better. LOL!
Good to know about your other tool choices, too. I like hearing about what works for other people... I've learned a lot, and found lots of great new tools, that way!
- John
Good to know about your other tool choices, too. I like hearing about what works for other people... I've learned a lot, and found lots of great new tools, that way!
- John
We actually use LESS for concrete5 for version 5.5 onward. This was partially because bootstrap - the ui framework that lots of 5.5 depends on- uses it extensively. I like it a lot. We don't really have a drop in version meaning that in order to use it we have to compile all the files every time we make a change, which is tedious, but the variables and name spacing are really nice.
I would echo Jordan's comments: for most sites, it's not necessary. But once you get to be complex I think it could help quite a bit. Plus I like the fact that you can use multiple includes and lots of comments for documentation, and then compile and minify all that stuff out of the resulting CSS right before you deploy
I would echo Jordan's comments: for most sites, it's not necessary. But once you get to be complex I think it could help quite a bit. Plus I like the fact that you can use multiple includes and lots of comments for documentation, and then compile and minify all that stuff out of the resulting CSS right before you deploy
That's cool to know that C5 is using it in their development environment.
I agree... LESS definitely has the most benefit for complex sites or multi-developer environments. But even us small-scale, single-coder shops can benefit by being able to do more with less. Variables, name spacing, mixins... you name it. It's all quite helpful. Necessary? No. But helpful, nonetheless. It's cool to be able to do more programmatic work in CSS... makes it feel "smarter".
I read that some people are using LESS/SASS to create dynamic grid templates... so they can make simple changes to column widths & gutter sizes and let the framework do the calculations to generate the CSS. Now THAT'S pretty cool! ;D
- John
I agree... LESS definitely has the most benefit for complex sites or multi-developer environments. But even us small-scale, single-coder shops can benefit by being able to do more with less. Variables, name spacing, mixins... you name it. It's all quite helpful. Necessary? No. But helpful, nonetheless. It's cool to be able to do more programmatic work in CSS... makes it feel "smarter".
I read that some people are using LESS/SASS to create dynamic grid templates... so they can make simple changes to column widths & gutter sizes and let the framework do the calculations to generate the CSS. Now THAT'S pretty cool! ;D
- John
Cool, LESS is sounding more and more like a perfect fit for my workflow, I find myself turning to Bootstrap more and more, I have used elements from it in my latest theme, only problem with that is my themes elements look identical to the C5 UI, which I haven't decided whether it's a good thing or not, but that's a different discussion.
Its a shame you have to re-compile every time, must wipe out some of the time you saved using LESS.
Its a shame you have to re-compile every time, must wipe out some of the time you saved using LESS.
Ya sass --watch will probably keep me from ever switching to less.
There is less.app for that but that's OSX gui nonsense, which although a refreshing departure from the typical OSX *nix backbiting, it doesn't run in linux so it's of no use to me and there really isn't much difference between the two in the end.
But if you do run OSX then you may be interested
http://incident57.com/less/
@jordanlev
Check out inuitcss for some fairly easy to digest abstractions and objects(island, media and nav).
There is less.app for that but that's OSX gui nonsense, which although a refreshing departure from the typical OSX *nix backbiting, it doesn't run in linux so it's of no use to me and there really isn't much difference between the two in the end.
But if you do run OSX then you may be interested
http://incident57.com/less/
@jordanlev
Check out inuitcss for some fairly easy to digest abstractions and objects(island, media and nav).
You can compile LESS server-side using node.js, or (my preferred option) lessphp -http://leafo.net/lessphp
Do you have this problem? If you feel like it's really annoying to have to keep pasting the same font or color or whatever styles all over the place, then yes it's worth using. But if you've never thought this was an issue (I've found it's only an issue on really complex designs or really large sites that have MANY different design things going on and many different page types), then no it's not worth it.
This is just my opinion though -- I haven't used it extensively so perhaps someone else who has can speak to some other benefits.