Slide from a presentation given at 2011 Design for Drupal in Boston about two popular CSS extensions and Compass with a focus on how they integrate in Drupal environment. The goal is to present and overview of Sass and LESS in order to drive front-end developers to abandon plain old CSS. Compass is talked about as the reason to use Sass over LESS.
8. There’s reason to try out both Sass and Less. For
some people, the syntax and new ideas in Less are
most important. For others, the power and maturity
of Sass are better. Hopefully as time goes on, both
projects will continue to learn from each other and
grow to serve the needs of CSS designers as well as
possible.
Nathan Weizenbaum
http://nex-3.com/posts/83-sass-and-less
9. http://www.flickr.com/photos/kayveeinc/2540019625/
LESS Sass
• Appeared in 2009 • More mature; appeared in
2007
• Doesn’t have as much
operation based logic • Run as standalone Ruby
gem or through Compass
• Implemented in various
languages: Ruby, .NET, • Supports CSS style and
Python, PHP, JS indent based
• CSS like style of writing
• drupal.org/project/less
module in PHP
14. framework |ˈfrāmˌwərk|
noun
an essential supporting structure of a building, vehicle, or object
a basic structure underlying a system, concept, or text
http://www.flickr.com/photos/15708236@N07/2757970155/
17. • Yes, there is a module for that: drupal.org/project/compass
• Compass App: compass.handlino.com $7
• Free if you compile from Git
• 30% of proceeds go to United Mitochondrial Disease
Foundation
18. gem update --system
gem install compass
compass version
compass create path/to/project
cd path/to/project
compass watch
19. # Set this to the root of your project
when deployed:
http_path = "/"
css_dir = "css"
sass_dir = "sass"
images_dir = "images"
javascripts_dir = "js"
stylesheets[all][] = css/voxful.css
stylesheets[all][] = css/screen.css
20. • Library of reusable patterns
• Mixins
• Import files: core or just what you need
• Extremely well documented: http://
compass-style.org/reference/compass/
21. CSS3 Mixins
• define at top of style sheet:
• import “compass/css3”
• only include css3 properties you need
• import “compass/css3/border-radius”
• for the browsers you want
• $experimental-support-for-opera: false
$experimental-support-for-khtml: false
28. Resources
• Sass & Compass
• http://blog.derekperez.com/
• http://sass-lang.com/
• http://nex-3.com/
• Kicking Ass + Taking Names with Sass and Compass: http://vimeo.com/24278115
• LESS
• http://lesscss.org/
• LESSPHP: http://leafo.net/lessphp/docs/
• Grid for LESS: http://designshack.co.uk/articles/css/introducing-the-less-css-grid
• LESS + 960 + Zen: http://drupal.org/sandbox/szantog/1101840
• If you start out using LESS and want to change: http://nex-3.com/posts/100-convert-less-to-scss
Editor's Notes
\n
I started out writing custom HTML and CSS. Very lucky to work under a Front-End ninja and have been immersed in standards since early on. 3 years ago I made the switch to Drupal. Sat in one of these rooms and rejoiced when I heard MortenDK talk on Mothership. \n\nNow I tend to believe that what Drupal outputs isn’t so bad,\nThat change comes from within—get involved with initiatives, core etc\n\nRecently have found fun and solace with Compass and SASS\n
Presentation makes a couple assumptions: \n1. You write semantic markup\n2. You care about your front-end. If you are here, you do care. \n\n How many have heard of LESS, SASS, Compass?\n How many use/actively use LESS, SASS, Compass?\n Anyone using SASS standalone?\n How many were in Ken’s talk yesterday? Mason’s talk today?\n\n\n\n\n\n\n
Let’s get started...\n\n1. First I’m going to talk about limitations CSS\n2. Then I’ll give an introduction to LESS and SASS, two of the more popular tools that have arisen to solve some of CSS shortcomings\n3. I’m going to talk about Compass framework\n4. Lastly, leave you with some tips and ideas for what you can do know (closing remarks)\n\n\n\n\n\n
Does anyone know what this building is? \n\nThis is the centre pompidou. Its exposed skeleton of brightly colored tubes for mechanical systems. The building puts the inside on the outside. \n\nThe Centre was designed by the Italian architect Renzo Piano, the British architect couple Richard Rogersand Su Rogers, \nIn 2007 Rogers' won thePritzker Prize in 2007,\n\nThe New York Times noted that the design of the Centre "turned the architecture world upside down" and that "Mr. Rogers earned a reputation as a high-tech iconoclast with the completion of the 1977 Pompidou Centre, The Pritzker jury said the Pompidou "revolutionized museums, transforming what had once been elite monuments into popular places of social and cultural exchange, woven into the heart of the city."[2]\n\nBut the cost of maintaining this building....\n\nRe-painting is constantly required on the trademark green water pipes, blue air pipes and red lifts and escalators.\nThe Pompidou Centre's futuristic design has led to spiralling maintenance costs. Re-painting is constantly required on the trademark green water pipes, blue air pipes and red lifts and escalators. Because architects Renzo Piano and Richard Rogers opted to place its insides – pipes and escalators – on the outside, "the building is one huge draught, it isn't airtight and it consumes enormous amounts of energy", said Stephane Viale, the building and security director.\n\n\nhttp://www.telegraph.co.uk/news/worldnews/1541291/Pompidou-looks-to-China-to-cover-its-bills.html\n
CSS is the language that brings beauty to the web. Remember the days without it? The maintenance was still hell. But like beautiful buildings, there is a cost. \n\nAnybody who’s built a website of any size knows how quickly CSS can get out of hand. \n\nBLOATED: Style sheets can grow bloated and lengthy, making it difficult to find things, introducing redundancy and producing an end product that makes code maintenance tedious. \n\nFLAT: like the inability to set variables or to perform operations, mean that we inevitably end up repeating the same pieces of styling in different places. Not good for following best practices—in this case, sticking to DRY (don’t repeat yourself) for less code and easier maintenance.\n\n\nNO CLEAR WAY TO ORGANIZE: We try to adopt conventions such as: \nTry to break out code into separate css files, like Zen, but just end up with too too many files, an unmanageable folder structure. A friend once told me that he wasn’t sure where to put things so he just put in it layout-fixed. \n\nCSS posed a problem and the new solution is CSS Extensions\n
Enter CSS extensions or metalanguages \n\nCreated to address the problems of CSS these languages, or meta-languages, as they are often called, add dynamic behavior to CSS\n\nSCSS is an API for parsing and manipulating W3C Cascading Style Sheets in the Scheme programming language. Although the majority of the W3C recommendation is devoted to the proper rendering of documents styled with CSS, SCSS concerns itself only with the formal structure of the style sheet itself – in other words, SCSS doesn't render anything! You can however, combine SCSS with the XML parser of your choice (SCSS integrates particularly well with SDOM: http://www.nongnu.org/sdom/) to obtain style information about your XML documents so that they may be rendered correctly\n
Before I go on this quote from the creator of SASS lang....\n\nAll to often we want one solution, the one size fits all, but that isn’t alway the case, nor should it be. In fact, this quote from the creator of SASS really sums it up well...\n\nYesterday in his Keynote Dries talked said “design is probably more important than engineering”. i’m glad he used the word probably. I think that they are both equally as important. Together they form a relationship. And relationships are never easy. LESS and SASS are engineered, coded, to serve the needs of designers, to help us perform our jobs even better. Truly a great symbiotic relationship. @TODO-IF: find a slide that demonstrates relationship\n\nIn his talk yesterday, Dries repeatedly stated that “Design is probably more important Engineering”. I’m glad he he used the word probably because the truth is that they go hand in hand. \n\nSCSS, SASS, LESS, COMPASS have been engineered and they help make design better. But behind the magic are engineers. In effect, these tools are great indication of what happens as we start to work together, talk and figure out how we can each help each other and make our lives easier and better. Which ultimately will make our output better.\n\nFor the next couple slides I’m going to talk about LESS and SASS side by side because I think it is the easiest way to show their differences and similarities. Also, when I speak of SASS it applies to SCSS, unless otherwise indicated\n\n@TODO: Adjust this based on what comes out of the Mason’s session\n\n@TODO: demo all three versions? \n\n\n
I worked on one less project because I was working with a team that didn’t know about these meta languages and SASS 3.1 was available yet\n\nApparently the PHP version is out of date...LESS was re-written and PHP adopted certain versions of the language. I learned from Ken, and those that were at his talk, that it hasn’t implemented any of the new updates. I’m okay with the JS version...I mean, so much about our experience on the web is JS driven. Also, there are ways that can serve up CSS if no JS detected and Newest incarnation, LESS 4, completely rebuilt in JS\nPros and Cons but if HTML 5 it will cache the generated CSS on local storage\nAlso...any may get some kick-back but: JS is everywhere.\n\n
variables need little explanation\n\nthis is number one reasons to turn to CSS extension language...how many times do you repeat a color? or a border style? or a height or a width?\n
The real power of mixins comes when you pass them arguments. Arguments are declared as a parenthesized, comma-separated list of variables. Each of those variables is assigned a value each time the mixin is used.\nMixin arguments can also be given default values just like you’d declare them normally. Then the user of the mixin can choose not to pass that argument and it will be assigned the default value.\nLess also has namespaces\nSometimes, you may want to group your variables or mixins, for organizational purposes, or just to offer some encapsulation. You can do this pretty intuitively in LESS—say you want to bundle some mixins and variables under #bundle, for later re-use, or for distributing: \n
\n
Okay, does everything make sense up to now? \n\nLESS and SASS can stand alone and on their own they help address many of CSS shortcomings outlined earlier. \n\nBut...\n\nThe real power of the extensions comes when used in conjunction with framework because you don’t have to write all the mixins\n\n\n\n\n
Compass is really the deciding factor\n\nCompass is a pluggable framework\n\nCompass comes with SASS => install Compass, installs SASS\n\nCompass = why I work with SASS over LESS\n\nOn their own, SASS and LESS will allow you to create your own stylesheet framework but with Compass you can plug into a wealth of CSS grid frameworks\n\nhttp://compass-style.org/help/\n
If you are on a Mac, you are lucky. Ruby comes with Mac. http://www.ruby-lang.org/en/downloads/\nTo check what version ruby -v\n
Don’t be afraid of the command line\n\nThe command line is much faster and easier\n\nAnd! It will show you if you have any compiling errors (@TODO take a screen shot)\n\n@TODO: shot of config.rb file. \nYou will need to make some changes. by default css gets compiled to /stylesheets and js to /javascripts. change those values and good to go\n\nSpecify the files in your .info file, referenced from CSS files\n\nIn effect, your SASS or LESS files are only touched when working locally. I commit mine. I suggest you do. Best practice to, even if you just work alone\n\n\n
Mason tried the App...didn’t work but...\n
but seriously...I tried the module, I tried the install directions and I was pulling out my hair. And then I remembered that Jacine set it up and I googled Jacine compass and came across the most helpful tweet\n\n\n\n\n
Compass can run alongside any theme. there are efforts to integrate it into other themes, but it can run alone. This is an example from compass running alongside Basic. My new basetheme of choice is skewing towards tao because of its aggressive drupal resets\n\nYou can see that you are good to go by looking at you theme. Notice that all the .scss files are compiled into /css by default ruby puts styles in /stylesheets and js in /javascripts\n
compass provides you with helpers, in form of Mixins \n\nMixins are like little recipes...you can write them...or go with what’s there or extend them\n\ndocumentation is a joy\n\n\n
browser specific code is bloated\n\ncompass provides an easy way to include all css3 properties. \n\nimport all or just the ones you need \nand for just the browsers you need to support\ncode hides from opera and konquerer\n
grids are all the rage\n\nthe confines breathe freedom to designs\n\nwe sacrificed having to include purely presentational classes in our tpl files for the convenience of grid\n\nbut it was/is still limiting...what if you want to target a selector that doesn’t have a file? can’t easily re-use the grid within styles\n\ndepending on time, pull up the documentation\n\ntapping into compass = cookbook. only getting bigger\nwhat if compass turns into feature server? ability for users to serve up mixins and other users to include them\n
basic example\n\nblueprint has liquid layout. this just shows how we no longer need to put any presentational classes in our markup\n
What is the value of all of this?\n\nIt is easy to cast yet another tool aside, especially with the overhead, to the common sigh: “I don’t have enough time” or “Too much overhead”\n\n\n\n\n\n\n
But the truth is...This is the armor for the front-end warrior. \n\nWearing it will keep you alive and afloat longer\n\n
Front end development is very individualistic\n\n
but with these tools there are limitations and we need to know how to pick out the not so great from the right otherwise we could just make a bigger mess\n\nand that only comes with good solid planning. none of these new extensions take that away. in fact, they demand more of it. \n\nit is daunting. it takes time. and eventually you will develop your own style. in closing my tips: \n\n1. Plan plan plan plan. the front-end need architects too\n\n2. start out basic: variables are a great way to re-use common pieces of your code\n\n3. DRY: refactor over time. look for areas where you are repeating yourself and try to make it reusable with mixins\n\n\nLESS and SASS will not solve your problem. In fact, they could very well make it worse. \n Will not magically fix the problem\n Only as good as you know its limitations and how and when to turn to it\n Tools solve first problem well, but the second...\n\n@TODO: picture of blueprint\nhttp://www.flickr.com/photos/wscullin/3770015991/\nhttp://www.flickr.com/photos/46469150@N02/4301962126/in/photostream/\nhttp://www.flickr.com/photos/mytudut/5188623949/sizes/l/in/photostream/\n