Submitted by Chris Shattuck on Tue, 2016-04-26 07:30
Hola ladies and gents!
A happy Tuesday to you. This week BuildAModule is gracing your inboxes with yet another installment in Front End Development. This week we continue looking at what the term "Mobile-First" means and then - since we've completed the process of sorting out our content into syntactically correct chunks - we start fine-tuning our CSS to match the look of our mockup AND add responsiveness, starting with the footer.
And why is this exciting? Because if you've been watching this series from the beginning, you've finally reached a level of sophistication in FED that allows us to add responsive design considerations without heads exploding!
Oh, and one of my favorite videos in this series is coming out this week, which discusses the "Fixed Breakpoint" versus "Expand the browser until it looks like s***" approaches to responsive design. For a long time I've been wanting to explain the two approaches and discuss the merits of each. This week I can check that one off my bucket list.
If the front end material has been new to you, I hope you've had a chance to apply some of what you're learning to your work. If you haven't, consider moving forward on an idea you've had for a a web project and incorporate some of these concepts. The quicker you can apply what you're learning, the stronger the techniques and concepts will stick.
For those of you in the northern hemisphere, I hope you're enjoying spring. It's such a beautiful... beautiful ... aAAAA CHO!!!!!
Even when the constraints of our project mean that we can't take a mobile-first approach to design or strategy, we can still take a mobile-first approach with our CSS. Here we explain exactly what that means (hint: it has something to do with "min-width" vs. "max-width."
There are two common approaches to coding a responsive site based on mockups. The first is beginning with mockups for specific breakpoints - most commonly for phones, tablets and desktops - and using those fixed breakpoints throughout your CSS. The next is to code for a single size, and then either expand or contract the browser until things start to look out of place, at which point you add breakpoints for specific elements. Here we walk through these two approaches and the benefits to each.
Before we can start to code the CSS for our site, we have to think about what we want the site to actually do when the browser size is different. Here we explore our options for getting the footer to fit in the browser window regardless of its size.
Floats can be very useful for layout out elements in a flexible way that will adjust to variations in browser size. Here we use the "float" property to get a flexible three-column layout going in our footer.
Sometimes it seems like it would make sense to adjust the order of elements in our HTML in order to make them easier to lay out, but it's important to consider the implications for accessibility if we re-order our content in a way that doesn't make sense.
Having worked through the CSS needed to get our footer content into a single column, we make the changes permanent and conditional by moving the style changes to breakpoints in our SASS. If this is your first time seeing breakpoints affect your layout, you'll really enjoy seeing this in action.
In previous videos, we added breakpoints to collapse our footer elements into a single column, and in this video we complete the process of making our footer fluid by adding a breakpoint to our navigation that makes it span the browser, whatever width it is.
When you have a desktop-based mockup, it's conceptually easier to begin coding the desktop version and then add smaller variation breakpoints later. However, there are some benefits in adjusting the CSS code to load mobile CSS first, and then add in the desktop version, and in this video we do just that.
In the mockup of our icon boxes, the icon rests half-in, half-out of the actual content box. Here we explore a couple of approaches to bumping that icon out of the box and then centering it to whatever the width of the box might be.
Earlier in the series we discussed the implication of using relative units for width, and how doing so can sometimes break a layout. In this video we explain how there are exceptions to the rule and how we might code our icon boxes to adjust nicely to a flexible width and height.
As we built out the CSS for our icon boxes, we were just playing with pixels in the browser to get things to look right. However, the final values we want in our SASS have relationships with other values, and where we can, it makes sense to make these relationships explicit with simple equations.