The Web Ahead: Episode 36 Transcript

TWA36.html

<dl>
<dt>Jen</dt>
<dd><p>This is <i>The Web Ahead</i>, a weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons and this is episode 36. I want to first say thanks to the sponsors today, <a href="http://cssdevconf.com/">CSS Dev Conference</a> and <a href="http://incontrolconference.com/">In Control Conference</a>. I'll talk more about those later in the show.</p>
<p>Today we're going to talk about Sass, Compass and CSS preprocessing: Some of the tools that becoming really popular lately for writing better CSS more quickly, writing more complicated CSS more quickly. I've started using Sass on nearly all the projects I work on. I resisted it for a while and finally jumped in so I thought it would be a great topic for the show, and I wanted <a href="http://scottkellum.com/">Scott Kellum</a> to join me. There are a lot of Sass experts out there who are doing amazing things but Scott is one of them who's really jumped out at me. He works over at <a href="http://www.voxmedia.com/">Vox Media</a> these days in New York and he's a web designer who also knows how to do great development. Hi Scott!</p>
</dd>

<dt>Scott</dt>
<dd>Hey! Great to be on, Jen.</dd>

<dt>Jen</dt>
<dd>So tell us first about Sass. For people who when they hear the word Sass, think Software As A Service, what is Sass when we're talking about CSS?</dd>

<dt>Scott</dt>
<time>[00:01:25]</time>
<dd>Sass stands for <i>"Sassy CSS"</i> or <i>"Syntactically Awesome Style Sheets"</i> and it is a preprocessor, so it's kind of a meta language on top of CSS itself. You're just kind of plugging in more tools to write CSS a little bit more efficiently. I like to think of it as a good text editor, it adds a lot of great tools to your workflow, but in the end your just writing flat text. A text editor adds some tools like syntax highlighting and find-and-replace functionality. Sass goes a long way in adding variable functionality, a lot of loops to your stylesheets to enable you to write a little bit more efficiently.</dd>

<dt>Jen</dt>
<dd>
So there's a couple of different way to set things up but basically, rather than writing a file with the name.css, like <strong>styles.css</strong>, you make a file with a <strong>.scss</strong> extension or <strong>.sass</strong> and we can talk about the difference but most people use scss. You write all your stuff in there, hit a button or save and you have something running in the background that's looking all the time to see what you're doing and it makes your CSS file for you. So basically you're writing in this higher level language and it creates the normal regular CSS file, and this CSS file is what the website uses. On the projects I've been on, typically we end up uploading all of it. There's different ways to do the workflow and we can talk about that too, but basically it all gets uploaded to the repo, so the Sass files everyone is writing are shared for developers on the team. So it's there on the server, but when somebody goes to the website itself they don't touch any of the Sass files, what they're doing is downloading the CSS just like normal. Human beings don't make the CSS file, magical robots make the CSS file.</dd>

<dt>Scott</dt>
<dd>
[Laughs] Yeah that's right. At work we don't write CSS or commit CSS to our repositories. We have our app itself build those out for us, so when it gets uploaded to the server the app itself starts building those files and we don't touch CSS at all. That's one way to do it, but you can also compile locally and that's what a lot of people do and actually what I prefer. I like to have my CSS file open in a window next to me just so that I know what's going on - what sort of things that Sass is doing to make that CSS file.</dd>

<aside class="pull-quote">At work we don't write CSS or commit CSS to our repositories. We have our app itself build those out for us, so when it gets uploaded to the server the app itself starts building those files and we don't touch CSS at all.</aside>

<dt>Jen</dt>
<dd>
Yeah, this is where it gets interesting. So you're writing CSS but you're writing it in a Sass file, and also we should say there's another program called Less which is very similar and some people prefer using Less instead of Sass, you can write normal CSS which is a nice thing. If you've not learned any of the special Sassy things yet but you already know CSS, it feels like the minimum participation if you want to switch over to this way of doing things is that you have to at least figure out the workflow. You have to understand that the Sass file, which you are supposed to edit and not the CSS file directly, is monitored by something running in the background or on the server to process it. You have to sort of shift your brain to have your projects rearranged a little bit. Once you've done that you can then just open up the Sass file and write normal CSS. That's why I like using a .scss file instead of a .sass file, because you can just write regular CSS with all the curly brackets and everything. Then later you can learn Sass bit by bit and figure out how to use variables, mixins and all the different powerful tools that are out there but you don't have to learn it all at once. You don't have to throw everything out and start over, it's like a gentle ramp.</dd>

<dt>Scott</dt>
<dd>
The beauty of CSS is that it's a declarative language and I really love that about it. It's so simple, you're essentially saying something like "This table is red" or "The background of this div is red" and starting out on that base level, nothing really changes. In Sass you are able to say "red" is a specific shade of red and then call that throughout your stylesheet, so you're able to extend the language itself. But yeah, you can copy and paste normal CSS, I often go out there and copy things like <a href="https://necolas.github.io/normalize.css/">Normalize</a>. A lot of tools are maintained and developed in CSS itself so you can copy and paste that into what's called a partial and not have to worry about that. It's really nice that scss is just a pure superset of Sass, you can drag and drop CSS itself into it and it works perfectly.</dd>

<dt>Jen</dt>
<dd>
So the reason you want to do this is so that you can use the fancy Sass stuff, so what are some of your favorite Sass tools or features? You said Sass lets you write more succinct code, more complex code, use variables and then it runs and outputs regular CSS. In your example you said you can define a color variable like "blue" with a hexadecimal and then just use "blue" all over your stylesheet, and when someone comes in and says "Oh let's make that blue a little bit darker"...</dd>

<dt>Scott</dt>
<dd>
Yeah or maybe they don't want it to be blue, so it's important to name your variables so they are slightly more semantic. So what is the relationship of this color to your stylesheet? Is it the primary color, is it the secondary color? That way you can kind of abstract that other level and use "primary" throughout your stylesheet instead of "blue" because a lot of times the client comes to you and says they don't like blue at all. So you if you used "blue" you might as well find and replace the hexadecimal number throughout your stylesheets.</dd>

<dt>Jen</dt>
<dd>
So you would put primary everywhere where you'd normally put a color value, $primary, and then at the very top or in a separate file you put primary will be this particular shade of blue, and then next year if they want it to be red you can just change that one place where you have the hexadecimal number for blue, you can put the hexadecimal or RGB number for red. That way when it goes to pull that variable, it's pretty quick and it just swaps them all out.</dd>

<dt>Scott</dt>
<dd>
And that's why you're seeing a lot of these master frameworks like Bootstrap and Zurb Foundation written in these preprocessors because these variables and this logic behind CSS allows you to write extremely flexible code that can adapt to any project. Say you want different column widths, you can define column widths with a variable and the math just does everything in the background. It still follows the same CSS rules but you can sort of make things a lot more flexible to adapt to anything. So instead of 960 pixels wide, it can be a variable number wide and you can adapt this huge library of code to almost any project.</dd>

<aside class="pull-quote">Say you want different column widths, you can define column widths with a variable and the math just does everything in the background.</aside>

<dt>Jen</dt>
<dd>
<time>[00:10:33]</time>
<p>Yeah. To me layout CSS is some of the hardest CSS to write, even before responsive web design. For accessibility and for search ability - you know, Google induced reasons - you want to have all your main content at the top of your source order in your HTML. Then you have like 2 columns in your design, so your put your first column and your second column one after the other. Now in responsive, you definitely want to do it that way because that's then your skinny width, your default for print stylesheets - that <strong>is</strong> the order of the content.</p> 

<p>But to do, say, an old-school blog layout with that source order you end up wanting your first column to be on the left, your second column to be on the right and your main content to be in the middle. You can do that, John Albin Wilkins has written some really great code that I've used for years where you can totally do that by doing some floats, negative margins and you kind of do these tricks where you put your main content up in the left corner and you put your sidebar right next to it on the right and use negative margins to suck the sidebar that was on the right all the way to the left and then shove the main content into the middle so that you get the visual layout you want with the source order that you want. But the code for that is complicated.</p> 

<p>John's code is in an open source library so I would download it and use it but he would have a default of like a 200 pixel column and I would often find I needed it to be like 250. Well the math for that to go through and change the 200 to 250 would be easy in one place, but the negative margin that's the total of <em>this</em> column plus <em>this</em> column, minus <em>this</em> gutter... It would take me and hour and a half maybe to sit there and redo his code with a lot of trial and error. He's recently switched that to Sass so now when you download it, instead of having to redo the formulas and redo the math, there's just a variable that says <i>How wide do you want the main column and the two sidebars?</i> and you just change that number in one place, then Sass does all the math to just output the correct values. It takes about one minute instead of an hour and a half, then I can change it 2, 3, 4, 5 times, designing in the browser, playing around. Maybe I'll think <i>I don't want 250, maybe 220 or 225.</i> Or maybe I don't want fixed-width, I'm gonna do percents now so let me do this percent or that percent. It gets rid of a stuff that's a waste of time like doing all this math for a complicated layout.</p>

<p>So you've done things that are similar to that but way, way more complicated with some great layouts. Can you talk about that?</p>   
</dd>

<dt>Scott</dt>
<dd>
<p>Yeah I can, but first of all even in basic responsive web design, in Ethan Marcotte's book there are a few pages about calculating percentages of things based on pixels. Reading that knowing Sass, I was like <i>why don't you just write a function for this and be done with it?</i> So yeah, it really simplifies all the calculations. I'm working on a grid framework called <a href="https://github.com/scottkellum/Singularity">Singularity</a> which is a grid framework that supports asymmetric grids so the first column doesn't have to be the same width and the second column or the third column. We are using John Albin's grid code in the back of that, and it's been a lot of fun to figure out how to deal with these complex calculations and what I love about Sass is that a lot of times people pull out calculators to do things or go to websites to build gradients and grids, so why not just have that built into your CSS and you can just test that on the fly, in the browser itself? So yeah, Singularity is kind of the culmination of a few of my projects. I worked on Modular Scale, which is just a modular scale calculator based on some of Tim Brown's writing to calculate ratios between different measurements and I wanted to figure out how to build a grid system out of it. So how do we build a grid system out of the golden ratio and how does that change across columns? Figuring out the language to describe this was very difficult and complex. Building on top of these different components, it was really fun to piece this puzzle together and create this complex grid system. 

<p>You know for the most part grids are equal columns, so you have 12 column grids, 6 column grids. But to do something that is not equal columns, it could be 3 columns across but all the columns have different measurements. It both increases complexity but it also simplifies things for the designer a lot of times because we aren't always using 12 columns across, these are a lot of columns to deal with but if we're only thinking in 3 columns - if the layout only needs to have so much, then simplifies things in one way. Creating the mathematics around this was a lot of fun to deal with. </dd>

<aside class="pull-quote">What I love about Sass is that a lot of times people pull out calculators to do things or go to websites to build gradients and grids, so why not just have that built into your CSS and you can just test that on the fly in the browser itself?</aside>


<dt>Jen</dt>
<dd>
<time>[00:16:45]</time>
<p>Mark Boulton has talked a lot about grid systems and using grid systems that are not equal columns, using something like the golden ratio. He was on <a href="http://5by5.tv/webahead/9"><em>episode 9 of The Web Ahead</em></a> if people want to go back and listen to that. <a href="https://gridsetapp.com/">Gridset</a> is a new tool that Mark Boulton has put out at gridsetapp.com where people can use this visual tool on their website to drag columns around and play with different ratios instead of having columns be all equal width or having an even number of columns. Kind of evolving past that and saying <i>what if you have a 5 column grid combined with a 7 column grid?</i> or combined with a different ratio, really complicated stuff.</p> 

<p>What I like about Singularity, although I feel like I still need to wrap my head around it and understand how exactly to quickly use the power of what's there, but it feels like all the creative interesting possibilities you could do with all these much more complicated grids where you basically just fill out a form. It's basically a main page where you're defining all the variables and then you can just hit refresh and look at your design and see what's happening, and then go back and adjust the variables and look again. You guys did all the super complicated layout snazziness and we can just ignore that and say <i>thank you very much!</i> and just use this tool.</p>
</dd>

<dt>Scott</dt>
<dd>
Yeah absolutely. The goal is to make as easy to use as possible and they're essentially WYSIWYG tools for real websites. 'What You See Is What You Get' isn't really the case any more, it's responsive web design - things scale. Photoshop doesn't always work to visualize your websites. So making tools better for designing in the browser is incredibly important now that websites change to wherever they're displayed. So you can make a quick change and view that on your iPad, iPhone or wherever and you get to see the change immediately and that's really powerful.  
</dd>
<aside class="pull-quote"><em>What You See Is What You Get</em> isn't really the case any more, it's responsive web design - things scale.</aside>

<dt>Jen</dt>
<dd>
Yeah so I think to keep the brain on design and how things feel, look and behave: I think one of the reasons people don't like desiging in the browser is that's it's hard to go back and forth between a programming and mathematical brain, troubleshooting and figuring out how to do something in code, and then switching to the more artistic, visual design and thinking about the people who will use your site and not the robots that will use your code. I find a person is usually in one mode or the other and I think that having the right tools like Singularity is just another example of when you can put your brain in design mode, keep it there and have the tools take care of things for you. That said, Singularity is not a clicky-click tool. You still need to know how Sass works and be able to grok how Singularity is set up, and know which variables do what so you can change them.
</dd>

<dt>Scott</dt>
<dd>
Yeah absolutely. It's still incredibly complex and still in development, and I'm currently busy on another project. Some Richards is working on currently so I'll get back to it in like a month. The goal is to make complex things as easy as possible but it's still not going to be as easy as drag-and-drop. If you want drag-and-drop I highly recommend Gridset. The idea is to let you do this in the browser with Sass and there are a number of advantages. The tools are completely abstracted, so if you want just the width of something you can call in the function itself and insert that. Or maybe you want the border to align with your grid. You can do that with singularity because you have tools that go all the way down to whatever's calculating specific measurement. It's complex, there is a lot to it but it also allows you to easily grab a highly specific thing and do something with it.
</dd>

<dt>Jen</dt>
<dd>
<time>[00:22:05]</time>
Yeah it seems really powerful. Another thing you worked on is <a href="https://github.com/ericam/susy">Susy</a> which is a grid layout tool but everything is equal columns, so if someone just wants to do in 960 grid style layout responsibly with Sass, this is a more simple library not as powerful but easier to understand.
</dd>

<dt>Scott</dt>
<dd>
Yeah I didn't actually work on Susy, that was Eric Meyer. Not the CSS Reset Eric Meyer but the other Eric Meyer. Estoril incredible job with Susy, great for creating equal column grids. It's pretty much the de facto grid system for Sass and <a href="http://compass-style.org/">Compass</a>. 
</dd>

<dt>Jen</dt>
<dd>
One of the big differences that interesting to me about this is if you download 960 grid, then you download a CSS file and tuck it away. Then you have to add classes to containers, divs, asides or articles in order to trigger that CSS. To say something like this column gets G4 omega classes because that tells it what it's going to do as far as the layout goes. Sometimes that's really tough and some people don't want to put classes like that on their HTML code and it feel like it's dirty hack. Some people using content management systems where it's really hard to put classes on things, especially perhaps small things that are in the layout. So it could be hours and hours of work hard classes to everything! Using Sass, instead of writing custom layout code let me go and find the class that already there and the ID that's already there or the article was already there, you use something to drill down and get to it. You know, CSS selectors. Instead of doing that and writing custom layout code, you do that and then call Sass function. So you get all the benefit of writing your own CSS custom to target the HTML you already have, but you also get the benefit of not having to write the code yourself.
</dd>

<dt>Scott</dt>
<dd>
<p>It's really interesting how object oriented CSS works in the responsive world. A lot of the problems with object oriented CSS are starting to show because you know if you put a width of seven columns on a div or anything, it doesn't really mean much when you get to certain sizes. You can say at a breakpoint it's this certain width, then you start sort of stacking a number of the layout classes onto an object but there not really doing the same thing although not doing anything at certain breakpoints. That's one of the faults of CSS itself.</p>

<p>Sass has something called extend and Nicole Sullivan the creator of Object-Oriented CSS has actually pushed for this as well where you can create these things called silent selectors. So you do a percentage and then say, a grid width of three, and then you can call that from within other objects. So say you want your aside or article markup to be a certain width at certain breakpoints, you can apply these objects throughout the cascade instead of the HTML itself. Mixins are really good for this, extend is a little broken in Sass just because it's not existent in CSS. Sass has been really pushing for extend within CSS and really pushing CSS in general. The ability to create semantic markup that can adapt is really great in Sass.</p>
</dd>

<dt>Jen</dt>
<dd>
<time>[00:27:39]</time>
So what are some of the things that sass does that you've fallen completely in love with?
</dd>

<dt>Scott</dt>
<dd>
[Laughs] I'm a huge fan of functions, just writing to tons and tons of code to write small values is amazing. I spend way too much time writing things that normal calculator could do in an instant, but I find it's a lot of fun to have complex tools within the browser to write things. The color math in Sass itself is a lot of fun. I've created Color Schemer which is another Compass extension that lets you enter a primary color and tell it to generate complimentary color schemes and it will populate your stylesheet based around certain color schemes. So the functions built into Sass really make designing in the browser breeze.
</dd>

<aside class="sponsor-break">
<dt>Jen</dt>
<dd>
We should tell people about Compass, but before we do that let me jump in here with our sponsor. CSS Dev Conference is coming up in Hawaii - December 5th in Honolulu. There's a bunch of speakers, really smart and well known industry people like Chris Coyer, Paul Irish, Dan Cederholm, Brad Frost and many others and they're going to talk about CSS all day, and talk about things like Sass and responsive web design. There's going to be a session on navigation and responsive web design, how to do good navigation with CSS. Tons of cool stuff. There's also another conference called the In Control conference which is right before the CSS Dev Conference. In Control is December 3rd and 4th, CSS Dev is December 5th, so if you go all the way out to Honolulu you might want to check out both conferences and see if you want to sign up for both of them. I believe there's a package ticket that you can get to go to both. The In Control conference is about web content and also CSS/HTML 5 and everything mixed together, like what is it we are doing these days with websites, what's coming in the future. Check them both out, you can go to cssdevconf.com and the In Control conference is incontrolconference.com and there's a discount for listeners of The Web Ahead if you use the coupon code 'AlohaAhead' you can get $100 off either conference or the combo ticket. Go check out their website and read about the sessions and speakers and consider it as a favor to me to go check them out. They've been big, big supporters of the show for a while now and I'm really impressed with the way their putting their conferences together, the people that they have and the topics that they're talking about. They're right on the money as far as what's going on these days with regards to the future of the web. So thanks again to Environments For Humans.
</dd>
</aside>

<dt>Scott</dt>
<dd>
And it's in Hawaii in December?
</dd>

<dt>Jen</dt>
<dd>
It's in Hawaii in December, yeah!
</dd>

<dt>Scott</dt>
<dd>
I'm going to both so I'm excited.
</dd>

<dt>Jen</dt>
<dd>
Yeah a lot of the people who have been on <em>The Web Ahead</em> are going so if you want to meet our guests in person and ask them questions, see what they are talking about since you only get to hear them on The Web Ahead and sometimes it's easier to understand these things be seeing them in person then this is a great way to do that.

So Compass...
</dd>

<dt>Scott</dt>
<dd>
<time>[0:32:47]</time>
Compass is a meta-framework for Sass. Basically what that means is that it's a toolset for building your Sass frameworks and it has a number of tools built into it like vendor prefixing, and pretty much most of the image replacements and all the tools that us web developers need in our workflows. It also allows us to build frameworks within it and create extensions of our own to add to this library. It's basically like populating your own personal code library of little snippets. We all collect snippets of code over time and Compass allows us to store and utilize that a lot easier. I didn't use Compass for maybe the first one and half years of using Sass, I just used straight up Sass, and Sam Richard - one of the guys who works on a lot of the open source projects with me - says that if you aren't using Compass, you're probably rewriting Compass and it's very true you know. I was rewriting a lot of the vendor prefixing, I was rewriting pretty much every tool in Compass. I just kinda jumped on board and started a few projects and it's a great tool for getting up and running with anything. Most of the big frameworks now are Compass frameworks so all you need to do to start it is include a gem, it's all Ruby based but don't let that scare you, it's pretty much just the same learning curve as Sass. To get that up and running makes it incredibly easy to work with other people's code to create your own code library on top of this meta-framework of Compass.
</dd>

<dt>Jen</dt>
<dd>
Yeah. I mean you clearly understand what's going on under the hood. I just know that Sass is the skeleton and Compass is a bunch of stuff that other people have made that makes things more better [laughs] and that's all I need to know. But it's true there are many things that are possible when you're using Compass and Sass together that Sass alone just doesn't do. So for example, instead of writing border-radius and then writing 4 3 or 4 5 vendor prefixes before you write the final normal border-radius in your CSS, you can just say @include border-radius(5px); just that one line and it will expand that out to all the vendor prefixes. At first I was like "I already memorized all the prefixes, I don't need a tool like that." and for something like border-radius that's probably true, but for something like linear gradients however, I did not memorize that. Some of the vendor prefixes are changing. The syntax is written one way and then it changes again. I don't want to keep up with that, I don't want to relearn it. That's where I started think OK I'm just going to use Compass and then I don't have to keep up with the changes in the vendor prefixes and now that I'm doing it, I'm like yeah, I don't know why I was going to do all that extra work for myself.
</dd>

<dt>Scott</dt>
<dd>
Yeah it's incredibly easy to use and another great aspect of it is if you are creating your markup for an app, so maybe you don't need all the vendor prefixes and you only need webkit because you're storing it inside of an iOS app, you can quickly remove support for everything apart from webkit with just one variable and generate that code for an app so it's a little bit leaner and more specific. You don't have to re-go through everything and remove out all this code, you can sort of tailor that really easy for whatever path you're going down. 
</dd>

<dt>Jen</dt>
<dd>
Nice. Or you could do that and then realize for some reason you're going to push that same code to the web so you need to add the prefixes back in, so you just change the one variable and you're done instead of having to do the tedious work of replacing them. I mean the whole idea is about getting rid of the tedious stuff.
</dd>

<dt>Scott</dt>
<dd>
Yeah, one of Sass' taglines is 'it makes CSS fun again' and there is a lot of tedious stuff. You know, vendor prefixes is part of it, but there's also polyfills; there's polyfill support for IE, and Compass itself includes Internet Explorer Pie which does a lot of the polyfilling for things like gradients and drop shadows. So there's tons of stuff that Compass does and we haven't even mentioned spriting yet, and spriting is yet another tedious thing that a lot of front-end developers deal with where they have to chop up images and combine them together into one large sprite file and Compass can manage this on its own. You just have to include a sprite file, you have a folder of all your single seperate files, you call on it and it sort of combines it into one massive sprite file and measures everythin out for you. So something that again was incredibly tedious is just done, you just call in the file as a sprite and it's there. Those HTTP requests are combined into one sprite file without you having to even worry about it.
</dd>

<dt>Jen</dt>
<dd>
Yeah that's one of the things that I feel like it's not really possible, it shouldn't really work - it seems so magical! We've all wasted so many hours sitting there being like "oh my gosh, I have to add one more sprite to this for one more set of rounded corners." To be able to then have robots do that, where you just toss all the originals into a folder and just let Compass deal with it and have all the advantages of using a sprite like you said, only one HTTP request instead of fifteen for all your fifteen little icons on the page, just have one file that has all the icons in it and you don't have to do any of the work for that. Then you have no reason to not be doing sprites.
</dd>

<dt>Scott</dt>
<dd>
Yeah absolutely.
</dd>

<dt>Jen</dt>
<dd>
The other thing that I feel like at first you think you can do all this by hand with CSS so why would I bother - it feels like we hit that note every once in a while with computer code, we think we already have that down and we don't need something more powerful - but then we slowly adopt the more powerful thing and then the old thing we used to do just disappears and in the extra available hours, our effort that's freed up by not having to do the old thing manually, something new can happen. Something that you would never be willing to do now becomes quite possible, and I feel like that's what Sass is doing for us. Sass and Less both, but Less doesn't do a lot of these things, it can only do some of what we've talked about in a different syntax and it's a separate world. One example is vertical rhythm in typography. In the past clients could show up or a designer could ask for everything to be lined up vertically and you're like "uh, this is the web..." [laugs] "why do you think this is print? No!"
</dd>

<dt>Scott</dt>
<dd>
There are plenty of ways to do it, you just need a calculator and a lot of time to do it.
</dd>

<dt>Jen</dt>
<dd>
<p>Richard Rutter, who was on <a href="http://5by5.tv/webahead/30">Episode 30</a> talking about typography, wrote this article where he very clearly layed out how to do vertical rhythm. He explained how you can do vertical rhythm in CSS but you have to do a lot of math and you've got to be super, super careful about never just jumping and quickly tweaking a margin here and a line height there, you have to everything based on ratios and lock your ratios in and stick to that. Clearly it's going to take a lot of time and people generally don't have that much time. It's a 24 Ways article, <em>How to Compose a Vertical Rhythm</em>.</p> 

<p>So Compass has a vertical rhythm plugin as part of it, so if you want to you can define your base font size and base line height, some details about how to handle borders, and boom, it will output everything that will have an effect on vertical rhythm according to the right kind of ratios and amounts of space in order to keep a consistent veritcal rhythm, so that if you took a piece of rule notebook paper and put it behind your web page so you can see the piece of paper with the lines behind your website then every single thing, every box, every line of text would line up along that set of lines. I talked to Richard about that and asked if it was a good idea or whether we should always do things that way and he said maybe, maybe not. But having the possibility, having the possibility it might be, easy might be stretching it...</p>
</dd>

<dt>Scott</dt>
<dd>
It's still not easy but it's within grasp instead of...
</dd>

<dt>Jen</dt>
<dd>
Way out of budget. So if this is going to take like 27 hours, is it worth the budget that your client has to do that? Or maybe it's not a money budget, it's a time budget if it's a voluntary project, but there are still limited resources. This makes it so you can figure it out in a couple of hours instead of a couple of weeks.
</dd>

<dt>Scott</dt>
<dd>
<time>[0:45:17]</time>
Sass amazing for that. You both have this library and everything is kind of broken down a little bit. We haven't talked about partials much, but everything is sort of broken into individual files, you can go to the specific file you're working on and fix that. Especially if you're working in a huge team, you can say "I'm working on the home page, and this specific side bar on that page", you can have an individual file that relates to that part of the page and work on that while other people are working on other parts you don't have to worry about merging this code together. You can maintain a bunch of little parts, the vertical rhythm alone - that's a mixin that's sort of abstracted out into it's own little component - and these components all come together. These little tools, these snippets can all come together and be maintained seperately while being part of a bigger thing, making it much easier to maintain large projects.
</dd>

<dt>Jen</dt>
<dd>
Yeah let's talk about partials. So basically when you make your scss files, and the biggest difference between sass and scss files I know, sass was the original sass file format, is that you remove all the brackets and it looks a lot more like ruby I believe. So people who are used to looking at ruby and are used to a line break and the number of spaces or tabs indenting your code mattering to the code itself, I think there's a handful of people who really love that clean, minimalist look. I think it's harder for people to ramp up, especially if you have a team where a couple of people are Sass experts, a couple of people with some experience and a couple of people who are brand new and are like "Really? Do we have to do this?" You have to have your whole team use it. You can't have half the people using and half not, if the project is using Sass then the whole project is using Sass. I feel like scss gives those people who are new to it a lot easier time than having to worry about indents and line breaks, because for the last hundred million years of CSS those never mattered.
</dd>

<dt>Scott</dt>
<dd>
Yeah, then if you start using sass for a while then go back to scss, you have to start worrying about brackets and semicolons again.
</dd>

<dt>Jen</dt>
<dd>
Right. [laughs] "Why is it broken!?"
</dd>

<dt>Scott</dt>
<dd>
Working at Vox we use scss in-house and I used sass for the two years before that. You know, it's a good change. It's really good to use both. There's pros and cons to either. At Zivtech where my friend Mason Wendell works, they use sass in-house and it's interesting because it actually enforces code style because it's whitespace dependant. So you can dig into any file and you know how things are going to be indented and how people are going to be writing code because that's all enforced by the language. For ramping people up, it's much better to have scss which is sort of the traditional CSS style syntax.
</dd>

<dt>Jen</dt>
<dd>
I think I just love CSS. I've had a long and deep relationship with CSS, I want my brackets and semicolons [laughs]. It's like a romantic attachment.
</dd>

<dt>Scott</dt>
<dd>
If you write it well, it can look much more elegant with the brackets and semicolons. You can space things out and aggregate things together a lot more cleanly.
</dd>

<dt>Jen</dt>
<dd>
Yeah. So it used to be that if you're wrting for a custom content management system or if you're writing for a website that's made up of straight up HTML and CSS files with no CMS, you make one file, probably called styles.css - that's a very popular name, and you put all your code into that one file. And you've got some spaces in there and some returns, some people put an extra bit of whitespace between each declaration and some people don't. Some people put the last closing bracket on the last line of code and some people put it below and there are debates about that. Typically you end up with one file and I remember when I did things that why and frequently the file was 6000 or 10000 lines long right?
</dd>

<dt>Scott</dt>
<dd>
Yeah.
</dd>

<dt>Jen</dt>
<dd>
Then I started working in the world of Drupal where it has a thing in there where you click a button and it takes the CSS and compresses it into a number of stylesheets, it used to be one and now it's four and I don't know why, and for many years I did it the same way. 
</dd>

</dl>