SASS or LESS? Or something else entirely?

I haven’t dabbled with any CSS preprocessors yet but that is on my learning roadmap. Do you prefer SASS over LESS or vice versa (or any other tools) and why? Also, how does it fit in with your Pinegrow workflow?

@Beemerang I prefer SASS over LESS but that is probably because when I first started looking at them for whatever reason SASS just seemed to fit my way of thinking and I’ve never bothered to look at LESS since. I use Coda for a lot of my CSS and when combined with CodeKit it does a fantastic job of handling SASS.

So for example if I’m working in Pinegrow and using the Foundation framework I have the option of creating a semantic grid by doing something like what’s suggested in this article from Zurb.

Oh brilliant, I’ve been looking for information on how to use Coda with SASS and Codekit, thank you!

I never used either one until Pinegrow. I like Less now that I understand what it does. :wink:

1 Like

I need to look into this - its on my list for the new year!

http://sass-lang.com/guide

Also found this website http://www.sassmeister.com/about - a SASS playground, exciting lol!

1 Like

I guess it was SASS I was thinking of, whichever one that lets you use variables. I like it for testing but I am not so sure how resource intensive it is in a real working environment because then another level of process has to be done to replace all those variables with the real values. If it was baked into the browsers ok but it isn’t or we wouldn’t have to install stuff to the site. If there was a way to replace those variables for the live site version I would like that. That’s me though.

I didn’t even know you could use variables in CSS until Pinegrow, I thought it was something it did then I discovered it was one of those two things SASS, LESS that does it… SASS I guess, LESS I am not sure is it sort of like Emmet for CSS?

The name gives impression you can write Less code and get same result but I really don’t like using anything that has to do processing to get the end result, like converting variables to the real value before displaying. I do too much of that stuff in PHP dynamically prepare content or get it from databases etc… I am getting to the point of mind that the fewer processing steps that needs to be done the better, can’t improve page load time either all these preprocessors.

1 Like

I skimmed the SASS Guide and apparently it does generate a CSS file once you are done for the live site. This is only for development work. In that case, this is interesting but I think from some of the examples can make people sloppy too many shortcuts and things you can’t really do with actual CSS so if you want to learn CSS and you don’t know it, I would stay clear of these preprocessors. That is if you are actually trying to learn the real thing, these preprocessors will teach you bad habits that will get you pulling your hair out if you were writing CSS straight.

LESS/SASS is compiled into a css file and isn’t used in the finished website. It is essentially a more efficient way to write css with the added advantage of helping to structure css better.

Some good info can be found here:



I particularly like the Inception Rule: don’t go more than four levels deep.

2 Likes

I’m heavily influenced by Chris Coyier - and therefor mine is SASS.

Unfortunately it’s not yet supported in PGD (2.9 at the day of writing). I wonder how it will be implement in V3 - but am excited about. So currently, only the LESS guys could tell us something about a proper workflow.

As already mentioned as well, LESS and SASS are CSS3 extensions - requiring to be compiled into (browser interpretable) native CSS. For this I use the one and only CodeKit.

It could be probably mentioned (just for adding some confusion), that it is the framework making SASS (or LESS) more powerful. Mine is COMPASS, but there are certainly others available.

All this is currently “workflow(ed)” entirely OFF Pinegrow.

Oh yes - I can’t really write SASS. It’s more a “copy and paste” kinda thing. And often enough it takes me three times longer than writing CSS - but hey, that’s the game.

Cheers

Thomas

1 Like

A small addition:

We Mac users are keen on CodeKit for compiling, concatenate and compress all our project stuff. But what about the WIN/Linux guys? Recently I stumbled upon Prepos as being described as an alternative.

Cheers

Thomas

1 Like

If you are talking about SASS it is built into Pinegrow, it is what allows you to use Variables in your CSS within PG.

I did not know what that was or how it did it until recently though but yeah, SASS and LESS are both in Pinegrow. If you look at the installation directory in the folders somewhere there you will find all the sources for Less, Sass, JQuery and others. Pinegrow uses it all in some way.

I hope it is giving you features and capability that you can’t do just writing CSS yourself, if the trade off isn’t there to my mind it is a waste of time.

Hm - there are in total two opportunities:

Either it is me or you!

I certainly start with me not understanding the SASS way properly. What I do is this way http://docs.pinegrow.com/editing/designer-feedback-working-pinegrow-external-applications

(Focusing on point 2 substituting Atom by Brackets).

Or in other words:

One of the big advantage of working SASS/Compass is, that you split a huge single.css into smaller parts of .scsss files. This let you focus working on exactly one task - rather than seeking for the correct place somewhere in a huge css file. This in all theory should sound like a should be able to hook those single SASS files to Pinegrow, being able to directly work on them.

When I say that some things are taking me longer, it might be true (on the first view). But later you benefit from this because it’s much easier. Currently I’m building my own grid-system. It is called theFlexGrid and I’m pretty proud on it. It could even end in my own Framework.

And the simple fact of automatic browser-vendor prefixing (as an example) makes it worth to work in SASS/Compass framework cause you can even write CSS and benefit from all those magics behind.

Cheers

Thomas

I have never really used either one but when I write my CSS I tend to break it into sections and put each section, unless it is few lines into a new file and just load up the section file I am working on. There are also bookmarks but I haven’t figured that one out yet.

Then I merge them into a main file and minimize the code.

How? Manually or by @import? And how do you minimize?

Cheers

Thomas

Here’s an interesting video about using Foundation+SASS and the settings file.

There are minify plugins for Brackets and Notepad++ as well as trailing space plugins that allow you to remove extra spaces from both sides of a line, this allows to manually minify and join lines which sometimes I have to for some code if minify plugins screw something up. All you are doing is compacting it all down to one line but sometimes JS for instance stops working so I have to manually do it. There are also online minifiers but I don’t really trust they aren’t stealing my code.

Splitting sections of CSS I create completely new css files and just include them into the page as you normally do. This allows to manually change precedence order for further testing say to see what happens if one sections is above or below another and how that changes the look of the page if at all. I don’t use @import.

When I am done I merge them back into the main CSS sheet and done. I only do that though if I have a REALLY long CSS style. I do split into separate files if there is not a common aspect being styled.

I look at it in this way, if you have styles that are styling aspects of pages that are only on certain pages and not common to the whole site then those should be split into a different sheet. If you have CSS that are not or rarely triggered, split them off to a new file and only include the file when those styles are needed. Eliminates clutter and simplify your css, makes the page maybe load faster and makes it easier to read the css when changes are made later.

I personally don’t see any difference in @import and including in the top of the page so I don’t ever use that method…