[MUSIC]

I am Tracy Rotton.

I'm taupecat on Twitter GitHub, Instagram, Facebook except I'm never on Facebook.

But pretty much taupecat everywhere on the internet.

I am lead web developer for RP3 agency.

We are a full service advertising agency that's located in Bethesda, Maryland.

Personally, I have been building websites for 20 years now.

I built my first website in 1994 way back before it

was ever called a front-end developer or anything like that.

I'm a big fan of WordPress I contributed to

the last two WordPress default themes and hope to continue to do so in the future.

I've been building responsive websites since 2011.

After the Boston Globe site we launched, I read Ethan Marcutt's book on the subject.

And it completely changed my philosophy on what a website should be and

how a website should be built.

And, everything I do nowadays is responsive.

And I began using Sass about a year after that, when I realized that doing

things the vanilla CSS way was a bad best practice.

It was, it was a bad practice to do that.

There are so many tools that CSS preprocessors.

Can give you to leverage your skills as a developer, that,

I just couldn't ignore it any more.

Now, every project I do involves using Sass.

So, I'm gonna tell you a little story about my days before I got

into using Sass.

My first responsive design project was contracting at

a company that redesigned the Robert Wood Johnson Foundation website.

A team of two developers,

including myself, spent three months working on the site.

We used Vanilla CSS and we used a lot and lot of This guy to

calculate everything that we needed to calculate in terms of percentages.

And ems and all these other relatives units that you begin to

become accustomed to when you're building responsive sites.

What we ended up with was an 80K mega CSS file.

That was just completely unmanageable and horrible to kinda have to deal with.

When you have to back and change font sizes or change colors or font stacks or

anything like that.

It was a total nightmare.

I mean, take a look at things like this.

We had to keep calculating these values in the calculator, copying and pasting them.

Putting in the comments how we got to these numbers.

And I decided, never again.

[LAUGH].

There has definitely got to be a better way.

Fast forward two years.

RP3 agency redesigned the Norfolk Southern Corporate website last year and

we did things a little differently this time.

First of all we used Sass.

Together with that we used Compass which is kinda an ad on to Sass and

we had some very specific reasons why we were using it.

Over the course of time, I can see myself repeating some of

the processes that that we were using over and over again.

So I sorta build of home-grown re,

response to the Sass library, which you can still find on my GitHub account.

And we put the whole thing together using CodeKit.

Now, one of the reasons we use Compass.

If Sass does not have a configuration file of its own, but Compass does.

So when you have a team of developers and

there are three developers in the Norfolk Southern redesign.

You wanna have as many things that you can commit in supervision control and

share amongst your team as possible.

CodeKit has since allowed you to create configuration files in that way,

but at the time it didn't.

So, using Compass was one of the ways we achieved that objective.

But, it still fell apart in other ways when dealing with JavaScript and etc.

That, that we couldn't commit.

So we also figured there had to be a better way than CodeKit to do that.

So that's the prologue.

Now, it's worth at this point to kinda just

review what is involved in responsive design.

According to Ethan Marcotte's seminal work on the subject there's three basic rules.

Fluid layouts.

You don't wanna define anything in hard pixels, hard values,

things that are inflexible.

You wanna keep things relatively based and percentage based.

Flexible images and media.

Now there's actually two parts of this.

The first is keeping your images in their containers.

And letting them grow and expand or

contract as the needs of the viewport dictate.

And then there's also the retina or high DPI issues when you're dealing with

retina Macbook Pros, or iPhone 4s or high DPI Android devices, etc.

And then the third tenant of responsive design is using CSS3 media queries.

And what these give you is,

when a certain condition is met according to the viewport.

Than a certain set of CSS rules will kick into gear

at that point and not at other points.

So those are the basics of responsive designs.

Now, some of the basics of SASS can work very well with this.

CSS is not a programming language.

But SASS can give you some tools that can be

very much more like a programming languages like JAVA script of PHP.

Including things like variables.

Functions which ideally will do one thing and then return a result.

Mixins which are a lot like functions except

that it's gonna return CSS to you based on the information that you give it.

And media query bubbling.

And we're gonna get really in to showing you how media query bubbling is gonna make

your life much easier, as we go on.

You could say the response of web design and SASS are a perfect fit for each other.

So let's take a look and

see how SASS is actually going to help us with our responsive development.

When you start working with responsive design,

the first thing that you kind of get very familiar with is the responsive formula.

And this simply put is what do I

want this element to be in terms of the context that it is.

And the result that you're gonna get is usually gonna be a percentage,

although it can also be some other relative unit like em.

And for that SASS has a perfect tool built right in called the percentage function.

And all you have to do is write out this percentage.

You give it that target that you want, you tell it that context, you divide it,

that's what the slash is for.

And it's going to give you a unit list number, and return it as a percentage.

So, in this example, I have a standard two column layout.

Where I've got 585 pixel is my target.

Inside a 960 pixel canvas, that's my context.

Same thing with the side bar, where my con, where my target is 350 pixels and

my context is still 960 still.

So, if I run that Sass through the pre-processor,

the resulting CSS I get is is 60.9375 for our main content.

And 36.45833 and you can imagine that those threes go on forever and

I didn't have to use That guy to get it.

Better yet, my code is now self-documenting.

I don't have to go back and on every line and say what I did.

Because it's right there in the S, in the Sass for

every other developer on my team to see.

[BLANK_AUDIO]

The next step of responsive design is flexible images and media.

But you know what we're gonna come back to that, save that one for later.

Media query bubbling.

This is what makes Sass rock and

when I first started using CSS preprocessors I started with less.

And then when to a Drupal conference, or Drupal camp.

And was talked into using Sass by Mason Wendell.

Mostly because at the time Sass had media query bubbling, but Less did not.

Less there has it, but I stuck with SASS anyway.

So we're going to take a look at three different examples of how we

can use media query bubbling.

And the first is the very basic, bare bones.

This is straight out of the box.

So take a sidebar.

Normally in a, if we're working in a mobile-first kinda situation,

we're going to find that it's not gonna have any floats.

It's not gonna have a defined width.

The width will be 100% of the view port, etc, the container.

And for our sidebar, we're gonna have certain properties that are gonna be

global no matter what the viewport size.

In this case, the background color and the font size are never going to change.

So, but we could, we could put our media query

inside our sidebar declaration so then when it hits a certain breakpoint size.

Then we're gonna apply the flow,

then we're gonna apply the width in terms of a percentage.

And we're already using that percentage formula that's Sass comes with.

But we still had to go back into our calculator as

we can see from the comments to determine our em unit.

Because we want to express our break points in terms of ems.

So that was kind of a pain.

But, whatever?

We, we come up with valid CSS right here, where our sidebars declare.

Then we have our media query, which is bubbled up now,

and contains our sidebar at floating em width at 43.125.

So that's the very basic principles of using media query bubbling.

But we can do better than that.

So here's the next example.

If you want to level up your media query bubbling.

So every browser has a default context.

It assumes that fonts are going to be a certain size, and

usually that size is 16 pixels.

Unless the, the user of the, the browser has changed.

And so we're gonna define a variable that says, assume,

16 pixels is our default browser context unless we say otherwise.

Then next I'm gonna write a function.

And that function is going to do one thing.

It's going to take the target that I feed it and the context that I feed it.

And if I don't feed it a context,

it's going to assume that it's that default browser context.

And that's going to return that part of that value to me in em.

So target, divided by context, times 1 em to get that em unit.

And then whenever I run that function, I am going to get that answer.

So I am going to run that function on the very next line.

And beyond that, I'm gonna define this break point into a variable so

that I can reuse it.

Now variables are great for

response in design because when you're dealing with media queries.

That you're gonna be repeating throughout your code, it's very easy for

one developer on your team to maybe misjudge the break point.

It said it's 680 instead of 690.

Or, maybe somebody just transposed a digit.

When you're using a variable, everybody's gonna use the same value, and

you don't have to worry.

That's one less error that is gonna crop up in your CSS, as you go on.

Aside from that, maybe the break points are gonna change.

Maybe 690 is not gonna cut it for the design after it's gone through

a couple revisions and you need to change it.

Well if you do it here in the variable, you're changing it once and

it's applying through the entire CSS.

So the rest of this illustration here is fairly sim, similar.

So we still are setting are min width but we're using a variable now.

And the resulting CSS shows us our sidebar with our global properties.

And then the sidebar with the media query triggering it.

But you know what, we're in New Orleans, we're going to kick it up one more notch.

So this is kinda the Jedi master way of dealing with, media query bubbling.

And I see Chris Coyer sitting in the back.

And I'm gonna give all props to him because this is his mama bear,

papa bear, baby bear method, using media queries.

So I still have the default browser context.

Just like I did on the last slide.

I still have my function, just like I did on the last slide.

I still have my breakpoint at medium.

But now, I have a new thing.

I have a mix-in.

I'm calling this mix-in BP for breakpoint.

And I'm gonna seed a key word.

And then my mix in is gonna use a little bit of logic.

Remember, CSS doesn't have logic, which means it's not a programming language.

But SASS does.

So we can use that logic to test for our keyword.

And in this case, if our keyword is medium, then we're gonna

use that medium break point and return the content that's in there.

So, here we go again with our sidebar and it's global properties.

And then our mix in this time being called with the include directive and

the CSS that we want to, to pass to it.

Now you might be thinking this is a whole lot of typing than we

did the first time around but we realize this is all just setup.

Right here.

The real payoff is that this is a lot less typing, and a lot less error prone.

Because now you're using keywords again,

and keeping things more consistent throughout your entire code.

So, here again is your finished CSS.

We have our sidebar with it's global properties, and

we have our media query with the sidebar that's floating.

And if you haven't noticed by now,

all of these three examples led up to the exact same CSS.

So that is media query bubbling.

Now, media queries can be used to set resolutions for your images.

And remember I said we were gonna talk about that later.

A lot of times your images for responsiveness are gonna be

handled through things like the picture element, and stuff like that.

But when you're using background images, and you want to use them in CSS.

And you want to have versions for your re, re, normal resolution versus your s,

higher resolution, this is probably one of the best practice.

Media queries that do that, now I don;t know about you, but

I don't want to have to type that a 100 times in project.

I don't want to have to meet that media query in a dark alley late at night.

So, if I created a mix-in, that and I'm going to call this one [COUGH] High-DPI,

then it's gong to write all of that for me then if best practices change.

Then we only have one place to change it.

Because, I mean, who knows, we have iPhone 6 and

6 Plus, they're even higher than High-DPI.

It's just craziness inside.

Now, I can hear you guys thinking.

Isn't repeating all these media queries over and

over instead of having them in one shot going to blow up my CSS.

Well, maybe, but no, not really.

First of all, best practices again say that your browser, or

your web server, should be sending G-zipped CSS to your browser.

And your browser's going G, Z, un, un-G-zip it, excuse me.

And parse it out.

So when you G-zip something, it's gonna take repeated.

Strings and crunch them into teeny tiny little bytes.

So that's gonna do most of the negating of that problem for you.

Second of all, if you're using JavaScript task runners like Grunt or Gulp.

There are actually plugins that will rewrite your code,

a CSS post-processor, if you will.

And it's going to combine all of your media queries into one shot and

remove that limitation for you.

So moving on to the next thing about Sass.

Now extend directive is not particularly useful solely for

responsive design, but it's got a few caveats that you should be aware of.

Now I like to use placeholder-selectors.

If you use classes in CSS of course they start with a dot.

If you use IDs in CSS which you shouldn't but,

okay, some people do, they start with a hash.

Well, a selector that starts with a percentage sign is a placeholder-selector.

And basically, this is Sass's way of saying that this selector should not exist

on its own, but only be referred to in, but using the extend directive.

And it's a, really kind of an ingenious idea, the extend.

In that it aggregates code around common property.

So, take this example.

I love using placeholder selectors to get rid of non-semantic, but

necessary classes like clearfix.

I hate having clearfix, you know, written in my mark, it doesn't belong there.

So, instead, I created clearfix place-holder selector,.

And I give it, in this case, the Nicolas Gallagher Micro Clearfix.

And then I can call it in my site header and

my site footer that I want those elements to be clearfixed.

So here's the resulting CSS.

That percentage slide in Clearfix goes away, and

is instead replaced by the site header declarations, in valid CSS.

And then site header gets written again for the properties that are unique to it.

As does site footer.

But herein lies the rub.

Cuz what Sass is doing is r, kinda rearranging your code,

there's a problem using extend directive with media queries.

If you try to write a media query and

put your extend directive inside the media query, Sass is gonna yell at you.

It doesn't like that, it'll return an error.

You can't do that.

Now, for most things it's not that big a deal.

I mean, after all, you can clear fix an element that's not floating.

It's just not gonna do anything so you're not really losing anything.

But if there's something that you really, really need to use.

Extend for and you really, really needed to use it in a media query then why not

put the media query in side the place holder selector?

You want to do this?

You want to put media queries inside your place holder selector.

Sure, go for it, it's awesome.

So those are kinda what's native to Sass that you can use to

help you with your CSS and responsive design.

But there's some libraries out there that can really kinda take this to

the next level.

So we're gonna talk about two of them.

The first is a grid system called Susy.

And I say it's a grid system, but that's kinda misleading.

Because actually really what it is, is it's math, and it's doing the math for

you so that you don't have to.

So what do I mean by this, well let's go to the demo.

So here we have our demo,

we have our two elements here that are sitting on top of each other.

No matter what the configuration they're just going to be

sitting on top of each other.

And so, I want to use Susy to kinda create a grid system for me.

Now I'm using Susy as a Ruby gem and I'm using it with Compass.

You don't have to use it with Compass, I've just found this easier to do.

So I'm requiring Susy right here.

So here is my CSS.

I'm going to import Susy, not because Susy's a Ruby gem,

it's sitting outside my project.

I don't have to keep it in revision control.

I don't have to let it pollute my project code.

It's sitting off the to the side, minding it's own business.

Ready for me to have it to do what it needs to do whenever I need it.

So, I am going to define the setting that I want to Susy to work with.

In this case, I want 12 columns.

Let me bump this up a little bit.

I want my gutters to each be one quarter the width of a column.

So again, we are talking about relationships between items and

not anything that's hard pixels.

Although I actually can use hard pixels if you want.

We're gonna set our container size.

And again, I'm using that em function that I wrote a few slides back to

say that my container is gonna be 1280 pixels expressed in em's.

And I'm gonna want to output everything as a flow,

which is what you traditionally think of when using grid systems.

So, now I have some CSS here, if I just uncomment it.

I have a wrapper class.

Okay, not everything can be purely semantic,

so there are a few things we're gonna have to live with.

Not a perfect world.

I want my main column to be eight pi,

eight columns wide in that 12 column grid system.

And I want my sidebar to be four columns, and, and

it's going to be the last element on the page.

So make the adjustments there.

Get rid of any right margin, etc.

So when I save all that, and I reload.

Now I have a perfect two column grid.

If I want to change the values, maybe I want to make it six, and six.

I just need to do that.

Save. There we go.

Now what if I want to add a third column?

Well, Susy makes it very easy, there's a minimum amount of effort I have to do.

So, now we know that we have three columns, so

I'm gonna keep the main column at six, but I'm gonna cut this down to three.

Of course, not both sidebars can be the last element on the page.

So we're gonna get rid of that and just say the last child in this dom is last,

and we're gonna give it that last mix in.

Refresh, and now we have our three columns.

And it took all of what, ten seconds.

So that's that demo.

Now, Susy can get even more powerful than this.

So a lot of times when we're working with a CMS, for

example, I work a lot with WordPress.

You don't know exactly how much content is gonna give, be given back to you,

when you're using that.

It's up to many many factors.

So, here I have three elements, but maybe I'm gonna have many many more than that.

So here is a gallery, this is, of items, now you can also be using images,

etc, whatever.

But, you know,

if you notice, I only have the one wrapper class, I don't have row classes.

So how is this working exactly?

Well, here it is, the gallery mix in with Susy.

And basically it's gonna use a different method called isolate to

kinda do some special things.

It's not, it's gonna reduce the amount of margins that are defined.

To reduce the problems that you have with

browsers not rendering number of pixels correctly.

And its also going to,

the gallery mixins also going to kinda calculate where my floats need to clear.

So if I change the gallery and I'm going to have three columns for each element.

So now each column has, or each item has three columns.

Like that. And that's all I had to do.

And it's calculating where the breaks need to go.

And so I've reduced the amount of non-somatic markup.

And I'm reducing amount of effort that I need to get these threads, and

they're all aligned beautifully.

So I mentioned floats versus isolate.

Really it's kinda you know floats are what you're used to.

The isolate instead of defining it's

right margin it's defining it's right margin as negative 100%.

And again, this is because different browsers kinda treat like

what happens like midway through a pixel differently.

And so this kinda solves that problem in a couple ways, one of which is, like,

reducing the amount of times you've defined that.

again, all these slides are on GitHub.

And you can go and look at it and there's a link to the article that explains it.

And Susy uses this method to kinda, make things like gallery possible.

So that's so that's some of what Susy can do.

It, it can also do asymmetrical grids.

It can make sure that, if you instead of having evenly number of columns

that are evenly sized, perhaps you want 25%, 50% and 25%.

Well, Susy can do that too.

You just have to define that in the settings.

You can also define different grids for different pages.

So, one page has a three column grid and the other page has an eight column grid.

Well, you could do a 24 column grid.

Or you could just have two different grid systems for

two different pages in your project.

It's all just a few settings away.

So the other library I want to talk about is Breakpoint because grid systems,

as fluid as they are, will only get us so far.

Breakpoint gives us mix ins that are similar to the Jedi master method that I

showed you before.

It assumes that everything that you do is going to be based on

min-width that's a mobile first approach.

But if you have a desktop down approach then you can specify that as well.

You could even give it a range so if something kicks in as 400 pixels and

ends at 800 pixels just give it those two values.

And it's going to know that you mean that range.

And it, you can also tell it what screen resolution, for

those High-DPI images that you wanted.

And then you're gonna that breakpoint as well for your retina screens.

So let's take a look at some more demos.

So here is our responsive grid that we looked at before.

It's nice and fluid.

But when you get down to being 400 pixels wide it's kinda ridiculous and

we don't really want that.

So we want to build in a break point.

This will only kick in at a certain point.

So just as I did before, I import break point.

I'm using a Ruby gem again.

And I'm saying my first break point is gonna be 480 pixels and

maybe I'll have another break point at 760.

I'm gonna set this variable break point to ems to be true because I

want to express all my break points in terms of ems.

And so now I go down here.

Let me uncomment.

My medium break point.

[BLANK_AUDIO]

And so now when we start out at our lowest break point there's no floating going on.

And as I drag the browser out.

We have floating going on.

So maybe I want to invoke that larger break point.

[BLANK_AUDIO]

And I think I am just not reaching it with the, there we go.

But we have a slight problem here.

[BLANK_AUDIO]

I see what I did wrong.

[BLANK_AUDIO]

Okay.

[BLANK_AUDIO]

Anyway.

So, you see how basically it works, right there.

Now you can do the same for the gallery approach as well.

So, here I have no floating going on.

But I go in to my break point.

Comment a few things out.

I have my gallery.

Let that run.

[SOUND] And now here I have a nice, neat gallery

that acts differently at different break points.

And if it's just a few little mix ins, and break point and

Susy did all the rest of the work.

And we never once had to go to That guy.

So yeah, break point and Susy together are very powerful tools.

As I said, you can do screen resolution media queries and it,

Susy actually integrates pretty well with break point.

Here you have a mix in for Susy that, where you give it the break point value

that you want, and then you give it the columns that you want.

And it will go ahead and do all the break point work for you.

So that's reducing the amount of code that you have to type even further.

So this is all good.

It's great for modern Evergreen browsers but

there are still those browsers out there, [COUGH] IE.

That haven't really caught up with the whole media query bandwagon.

So, sometimes we still have to deal with them.

Hopefully you don't but if you did.

We got you covered there.

So there are a few options that you have when you're dealing

with non-media query supporting browsers.

The first is you can give them the mobile view,

which essentially means you're ignoring the problem.

Now I actually think this is a perfectly valid approach but

your client might not agree.

So what else can you do?

Well, you can use something like respond.js.

Which will actually make your browser responsive by doing a whole lot of

JavaScript in the background.

But, as you might imagine, that's going to put a lot of load on your browser, and

be slow and affect performance.

So, maybe that's not the best option, either.

The third options, what we're gonna talk about, is using Modernizr.

Which will detect whether your browser supports media queries, and

pairing that with break point.

So, here I have the demo, from earlier.

And if I go and look at this on IE 8 right here.

Well of course, I'm not seeing any break points.

Of course, because IE 8 is old.

So what can we do about that?

Well, we can go back here and uncomment these two lines where I

set break point no-query fallbacks, I want that to be true.

And I want a browser that doesn't support media queries to look like my

media breakpoint.

So if I do that here, and

uncomment myself here.

Let Gulp run.

[BLANK_AUDIO]

And then reload.

Now, well, it kinda looks like my medium break point, but again, IE is old.

Doesn't understand last child selector.

So we do have to go back and deal with them.

Now there's selectivizer.

Or you can just give it that non-semantic last class that

we've basically been trying to avoid this whole talk.

And I changed this.

Presto-chango.

And it's just not going to work for me is it?

>> You commented out.

>> Their we go.

Now, it just took Gulp a few seconds to run.

So there we have our break point.

Now it doesn't look like this because this is our large break point and

we set it to decide at that it is going to use our medium break point.

But that's a value judgment that you can make in conjunction with your

designers and your clients.

As to what break point you want to serve to legacy browsers like that.

So, I also talked about briefly before about combining media queries, and

we can do that here.

I've been running this whole demo using Gulp.

So, taking a quick look at my main CSS that it's compiling,

if I go through and look for my media queries.

I'm going to see a lot of the same media queries repeated over and over and

over again.

And we already talked about how that might not be as big of a problem as you think,

but if you're really concerned about micro optimization,.

Then you can use that Gulp plugin called combined media queries.

Now I'm gonna run things again.

And it's gonna create a new CSS file for me called main.cmq.

And if I look for my media queries here, I'm gonna find exactly two.

It's rewritten my CSS so that they're all kinda congregated together.

I go back in here and

I'm now going to use that CMQ1 instead of the normal one I've been working with.

And there is no change.

It's the same thing.

So, it's kinda experimental.

There are bugs on, with it.

So use it as your own, at your own risk.

But, if you're really concerned about, kinda squeezing every

last k you can out of your CSS file, then that might be a big tool to use.

So, that's pretty much where we've gotten to.

now, we just redesigned our agency website.

It launched last week.

And the tools that we used to do that were of course Sass,

Compass, Susy, and Breakpoint, to kinda put it all together.

And credit to Sam Richard for teaching me the phrase,

presentation driven development, cuz that's entirely what this was.

And we used Gulp to put it all together.

Gulp again, same thing with Grunt,

other task runners gives you this configuration file.

That lets every developer on your team work on the same page and

keeps the guess work out of what the settings are.

So, I could throw a whole bunch of resources at you for

learning more about responsive web development.

Or I can just point you to Brad Fross, excellent, This Is Responsive library.

Pretty much if it's about responsive design, it's here, and

this is a great place to get started with that.

Now to learn more about SASS.

You can go to SASS's web site for all the documentation.

The Sass Way is a great web site with tutorials in both beginner, and

mid, intermediate, and advanced techniques.

Sache is another great resource.

And SassBites, if you see Micah around here go say hi.

He's, he runs a great podcast called SassBites.

With video tutorials, etc.

On how to use SASS.

And Breakpoint and Susy, also.

And a few articles that are very much on point.

Building web layouts easily with Susy was a guest post on CSS tricks last month.

Excellent article about getting started using Susy layouts.

And managing responsive break points with Sass on Sitepoint.

Sitepoint has a lot of great articles about Sass.

Mostly by Hugo Giraudel, and I'm sorry I'm massacring his name.

But he writes extensively on Sass, and it's a great resource to follow.

So, thank you so much for, for coming.

Again if you like this talk you can vote for it in Chris's text voting system.

And I want to give props to a few of the people in real life in

the community who have contributed to this presentation.

And CSS DefCon for having me.

That's it.

[APPLAUSE]