Submitted by Chris Shattuck on Tue, 2016-04-12 08:30
At the risk of becoming too predictable, this week I'm releasing another 20 videos in the Front End Development collection. This week's videos wrap up our effort to style a Flexslider carousel using CSS and SASS, and then we get to dive into something I've been looking forward to covering for years now...
Being a little late to hop on the bandwagon of responsive design coverage has its advantages. As we progress through the next videos, you'll get to see how we can use an additional layer of tools including SASS plugins, Bower components and automation tools like Grunt to make it a lot more possible to build something once and progressively refactor it over time as needs change. Learning what I needed to in order to make these videos changed I worked in an essential, really positive way, and I hope many of you will make similar strides.
I also wanted to say thanks to all of you readers / watchers out there who help make the work I do meaningful. Without you, I would be lost.
In some recent videos we explored how to create columns of content by using the "float" CSS property. However, when dealing with a set of floated items that are separated into groups, we need to use some particular CSS to adjust how they're positioned in relation to one another.
Throughout this series, we've used a process where we've made changes to CSS code in the browser, and then we copy that code over to our CSS files later. In this video we explain why it's a good idea to start in the browser and then make those changes permanently later.
As we go through the process of moving some of our CSS to our SASS files, we have to consider if it makes sense to use relative or absolute units for the elements in our snippets. Earlier we discussed the benefits of using relative units when it comes to accessibility, but now we're starting to also have to take our layout into consideration.
Because we've consistently been using relative units for many of our elements, we can easily test a change in browser font size by editing the size of our font in the "html" tag selector. This is also a handy way to adjust the size of your entire site for different scenarios with media queries.
Once we've figured out what CSS properties in our snippet code to make relative, and which to keep absolute, we now have a good example to draw from when later deciding when it makes sense to absolute or relative units for an element.
Earlier in the series we adjusted the previous and next navigation icons for Flexslider, and in this video we do the same thing, but with the added benefit of being able to leverage Font Awesome for the icons.
Earlier we covered how "absolute" positioning works. What we didn't mention was that using absolute positioning unlocks the ability to also use the "left" and "right" CSS properties to move an element around based on where it would normally be. Here we demonstrate how to use those properties.
Styling a hover state in the browser can be a real challenge until you know this trick, since you can't hover over an element and modify it's CSS in the browser at the same time. However, Chrome DevTools (and other browser development tools) lets you turn on the hover state even when you're not hovering, allowing you to easily modify the CSS.
Hey, if you've been following along with this series from the beginning, you deserve a huge congratulations. We just completed rendering all of the elements on our page into HTML and CSS, and that's huge. Now, we just need to get it all laid out.
Before responsive design, there were a couple schools of thought when it came to laying out sites: keep the site the same size regardless of the browser size, or shrink and grow it to fit the browser window. Here we summarize the benefits and downsides to each.
As we mentioned earlier in this series, building and maintaining a separate mobile site to complement a desktop site greatly increases the amount of work you have to do. Here we summarize the problems with this approach.
With our project, we have a mockup for a desktop-based site and we need to use our front end skill set to translate this to other browser sizes. However, some projects will start with different mockups for different sizes or no mockup at all. Here we discuss the different ways a project might start and why there are these variations.
When it comes to design, "mobile first" means focusing on the mobile version of a design first, and then scaling up, instead of the other way around. In this video we discuss why this approach makes so much sense.