Sass and modx workflow

Just wondering if anyone can share how they incorporate sass with modx project. Currently I just edit the css in a static resource, but will like to take advantage of variables, shorter syntax etc of sass. [ed. note: g5604 last edited this post 10 years, 2 months ago.]

Ooh, the names tortured me in the beginning: Sass, Scass, Compass, Sussy, Jane, Bingo, Haml, Ruby, Dime...

I pooh-poohed sass and haml for the longest until it dawned on me that it is actually pointless to do the grunt work while your computer has a price tag going off the roof. The Computer is your slave, use it as such! It is important to know how to do the grunt work though, because Sass and the others could disappear tomorrow; if that happens I'd just go back to my perfectly ordered .css file that Sass did for me before it vanished.

I don't let the server process my sass, everything is local for me, just as before. I think there is even a MODx extra that can process Sass. But I don't care for unnecessary dependencies.

Within SublimeText2, I have created a build system that activates ruby sass gem which validates and combines my little pieces of sass files. It also minifies the final output, Styles.css.
Since I end up using only one .css file for all screen modes (I don't mind that at all) I have:

_base.sass //has all my reusable variables, it is imported by all the other sass files. It includes Sussy and Compass.
+ desktop.scss // for the 700px+ screen
+ mobile.scss // for the smaller screen
+ styles.scss //this fellow includes/imports all the above files, it is the main file

I am terribly happy with my setup.

If I alter, say _base.scss or Sass file in that directory, and hit Ctrl+S, SublimeText knows to rebuild Styles.scss, and output Styles.css.
I have Styles.css always open, and so I just right click on its tab, and 'upload to server' ...and bingo!

I never have to see my site's css again, only the sweet strict logic of Sass with all its nesting, vendor prefixes and what not.
Of course during development, I turn off minify, so I can the better play with Chrome's Inspect Element.

If I have had a drunken stupor of imagination, and my sass/css lines are less than beautiful in structure, I hit SassBeautify in SublimeText.

Sussy for layout fluidity is pretty, and Compass, a life saver!.

So I say, go Sass!

thank you, very helpful!

PhpStorm also has integrated Sass/Scss/Less and Compass support with automatic updating: http://www.jetbrains.com/phpstorm/webhelp/working-with-sass-and-scss-in-compass-projects.html

I use a boilerplate to get any web based project up and running (and of course they are all with MODX). NeatPages asks you a few questions about how you want to set up your project, and then builds it for you.
http://neatpag.es

It'll ask you things like if you want to use Sass or LESS, if you'd like to include dependencies like html5 boilerplate, fontawesome, foundation5 etc and some author related information.

Since NeatPages is a grunt-init template, it does require being set up with Grunt
http://24ways.org/2013/grunt-is-not-weird-and-hard/

The setup I use is very similar to what we use for MODX Revolution
https://github.com/modxcms/revolution/tree/develop/_build/templates/default#grunt-commands

So, I like to have a _build folder where my gruntfile and Sass files go. Depending on the project, I'll put those files in a _build/template/mytemplate subdirectory to support theming down the line. So the idea is any files that don't need to be uploaded to your website live within _build. Your Sass can compile from something like _build/main.scss to _build/main.css and be minified to _build/main.min.css.

I don't think I have added SFTP features to NeatPages yet, but that is something I really like to do with MODX sites so you can do things like


to upload your files easily.

Quote from: donshakespeare at Feb 18, 2014, 11:16 PM

Ooh, the names tortured me in the beginning: Sass, Scass, Compass, Sussy, Jane, Bingo, Haml, Ruby, Dime...

Yes, they are a lot to keep track of no doubt. Especially once you get into all the npm modules available through Grunt.

Sass (there is no such thing as SASS btw, yes the spelling is confusing) is the original syntax, and SCSS is a new and improved syntax in version 3. For me, I can't live without @extend and silent classes, so I really enjoy the SCSS syntax.
http://thesassway.com/editorial/sass-vs-scss-which-syntax-is-better

Sass 3.3 isn't final yet, but if you run the pre-release you can use the new fancy source-maps which let you use the Developer Tools to see where your styles come from in the original Sass files, not just the ambiguous CSS.

We've established a workflow over the past year or so that includes:

SASS (scss w/ compass).
GIT (we use beanstalk for it auto sftp deployment feature).
Up to 3x MODX deployments for each site at any given time, local, staging, and live.

We use codekit (a Mac App) to compile sass and minifiy js but you could use grunt instead instead for a platform agnostic approach.

We do all the pre-processing of SASS file locally and then the compiled are deployed to the staging or live deployments using git and beanstalk.

The secret sauce here is ElementHelper which lets us version controlled static file for just about every element that we'd ever want to modify inside MODX.

We have our own modx boilerplate at https://github.com/dashmedia/dashing that we use as a starting point along with our own costom MODX pre-installed extras and settings to suit our projects.

The hardest part for us is re-syncing databases and re-running setup every now and then if there have been substantial content changes on the live deployment between development rounds.

All together the first few hours of a new project are taken care of immediately, and using SASS along with local and remote versions of the same website is a breeze.

Quote from: dinocorn at Feb 20, 2014, 02:56 AM

Quote from: donshakespeare at Feb 18, 2014, 11:16 PM

Ooh, the names tortured me in the beginning: Sass, Scass, Compass, Sussy, Jane, Bingo, Haml, Ruby, Dime...

Yes, they are a lot to keep track of no doubt. Especially once you get into all the npm modules available through Grunt.

Sass (there is no such thing as SASS btw, yes the spelling is confusing) is the original syntax, and SCSS is a new and improved syntax in version 3. For me, I can't live without @extend and silent classes, so I really enjoy the SCSS syntax.
http://thesassway.com/editorial/sass-vs-scss-which-syntax-is-better

Sass 3.3 isn't final yet, but if you run the pre-release you can use the new fancy source-maps which let you use the Developer Tools to see where your styles come from in the original Sass files, not just the ambiguous CSS.

sudo gem install sass --pre

Source maps are the bomb.

Just a follow up to this. Here my first attempt at a new modx workflow (using modx cloud instead of local)

1) Write css in normal text editor (textWrangler)
2) Scout does the conversion from sass to minified css
3) Transmit is used to mount the site as a drive, which is then set as the output destination in scout
4) Livereload is used to refresh the live site site on save

The end result is I can write sass in my normal text editor, hit save and the site is automatically updated in the browser window. Huzzah!

Just realised scout can not work the same way for javascript. Can anyone recommend a different app that could combine and minify JS as well as sass?