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!!!!!
What "mobile first" means in terms of CSS New! (This one's FREE!)
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."
Now that we understand what "mobile first" means, we can look at what ways we can use a mobile-first approach in our project.
Comparing fixed breakpoints to the "expand until it looks bad" responsive design approaches New! (This one's FREE!)
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.
To begin with, we're going to code our CSS for desktop first, since that's the kind of mockup we have. Later, we'll convert it over to a mobile-first approach.
In order to lay out groups of elements, we'll need to add some container elements so we can style them separately. In this video we wrap the footer elements that need a container.
When we added our wrapper elements, it changed how one of our CSS child selectors worked. In this video we troubleshoot the issue and re-align our selectors to work with our new wrapper elements.
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.
How moving around markup for layout can be an accessibility issue New! (This one's FREE!)
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.
Here we adjust some stubborn spacing in our footer with a bit of negative margin.
In this video we work through the changes that need to be made to our footer CSS to collapse it down to a single column.
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.
Moving onto the next section we want to add responsiveness to, we think about how we'd want the icon boxes in the "qualities" section to adapt to smaller browser sizes.
As we work through the changes we need to make to our CSS, we realize that some of the changes we want to make are common for all of the stacked hero sections, so we adjust the CSS accordingly.
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.
Now that we have the layout of the icons squared away in our icon boxes, we move onto look at the adjustments we need to make to bring the text of the icon boxes in line.
When it makes sense to use relative units for width, and moving our CSS to our SASS files New! (This one's FREE!)
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.