How much does minifying matter? How many meta tags for social media do you need? How does it feel moving to Redux? What's the easiest possible grid framework? What is Style Guide Driven Development? 

From the blog

✻  Grid frameworks are certainly useful in a number of situations, but Chris takes a look at whether we can instead come up with our own simple grid solution with flexbox:
…it’s not required that you reach for a grid framework to build a grid. You can do it! This is also not to say that flexbox is trivially easy and you'll never have any problems.
A flexbox-based grid might be this easy:

.flex-grid {
  display: flex;
}
.col {
  flex: 1;
}


✻ In Essential Meta Tags for Social Media, Adam Coti untangles the confusing jumble of meta tags that need to be placed in the <head> of a webpage in order to display rich previews across services such as Twitter, Facebook and Slack. Spoiler: you can get away with only about 5. Adam also guides us through the process of using a validator in order to make sure that we’re presenting the right information to the right service.

✻ Brandon Smith explores how to avoid layout shifting, which is an annoying bug in a great number of websites where your scroll position is moved thanks to content being loaded in via Ajax. Here’s a tiny example:
 

✻ Nick Berens writes about his experience in developing Atomic Docs, a nifty style guide generator and component manager. Nick also describes what “styleguide driven development” is and how it can help both design and development teams work more efficiently together:

Style guides have encouraged our designers and junior developers to build pages and views quickly without having a deep understanding of HTML/CSS/JS. And since each component is isolated, it makes it easier to understand the code that created it.
 

✻ Chris gives us an update of everything that’s been going on with the CSS-Tricks community in the latest Chronicle XXVII.


What we’ve been reading, listening and watching

Scott Jehl wrote about the thinking behind Snapper, a carousel that uses CSS snap points. It also employs JavaScript to “create a broadly-functional snap-points carousel”: 
... if you're going to use a carousel, it had better work great. For years, we've been improving our own Responsive Carousel to meet the needs of our client projects, and it still serves us well (particularly when we want more of a crossfading slideshow effect). Recently however, we started looking into a new web standard which is specifically designed to handle the sidescrolling carousel pattern. That new standard is CSS Snap Points, and it extends the functionality of CSS "overflow" scrolling regions to be able to "snap" to particular points in their scrolling span.
And Viljami Salminen wrote about typography for user interfaces:
Every word and letter in an interface matters. Good writing is good design. Text is ultimately interface, and it’s us, the designers, who are the copywriters shaping this information.
A note from the archives

Minification and Gzipping our assets are essential to reducing the file sizes and reducing the network bottleneck between our content and our users. A while back Chris wrote about the differences between these two techniques and ways to get started:
These are both things that you do to assets on your website (things like .css files and .js files). They are both things that reduce the size of the file, making it more efficient in crossing the network between servers and browsers. As in, good for performance. The network is the speed bottleneck of the web and reducing file size helps.
But these two things are distinctly different. If you didn't already know that, it's worth understanding
Another spoiler: Gzipping is way more important, but you might as well do both, and caching trumps them both.

 The Differences Between Minifcation and Gzipping 
 
What have you learnt this week?

Chris Coyier: I've been working in React and Redux lately. It's such a stark difference from the wild west of "do whatever you want and hopefully things stay organized" JavaScript I'm used to. For example, I was implementing a modal the other day and it went something like this:
  1. I'll start with the JSX... lemme make a component.
  2. At the very least, this modal will have state concerning if it's open or not, so let me mock that state out in initialState.
  3. The component is going to need to know about and effect that state, so I should make a container file that can handle all that state passing and such.
  4. There is a button to open/close this modal, that should probably be it's own component, especially since the modal itself will probably have to live near the root of the document (for z-index reasons) and the button will be nested a few containers deep.
  5. This is Redux, where state is affected by dispatching actions. So let me make a new action type that passes along the correct payload and all that.
  6. The actual state changing work is done by the action calling a reducer, so I'll find all the right places to define and integrate new reducer functions
  7. This isn't the first modal, so I'll need to make sure existing modal functions know about this new modal. So for instance, when an action is dispatched to close all modals, this one is closed too.
  8. Tests should be written to ensure the correct data, in the correct formats, is being passed around.
All in all, maybe 10-12 files are touched to implement a fairly simple modal without much functionality of it's own. Just like JSX, it can feel like OH GOD WHY. But that feeling is starting to fade and be replaced by a sense that this is how things should be. It's not the wild west anymore. This giant block of all-controlling state, which prescriptive ways of interacting with it, ensure that everyone and everything is on the same page. And while some of this upfront development is more difficult, later work actually becomes easier as you tap into existing state and actions.



Until next time!
Team CSS-Tricks
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list