Post pobrano z: An Introduction to the `fr` CSS unit

With all the excitement around CSS Grid, I haven’t seen as much talk about the new fr CSS length unit (here’s the spec). And now that browser support is rapidly improving for this feature, I think this is the time to explore how it can be used in conjunction with our fancy new layout engine because there are a number of benefits when using it; more legible and maintainable code being the primary reasons for making the switch.

To get started, let’s take a look at how we’d typically think of building a grid in CSS. In the example below, we’re creating a four column grid where each column has an equal width:

<div class="grid">
  <div class="column"></div>
  <div class="column"></div>
  <div class="column"></div>
  <div class="column"></div>
</div>

.grid {
  display: grid;
  grid-template-columns: repeat(4, 25%);
  grid-column-gap: 10px;
}

See the Pen CSS-Tricks: Grid Example 1 by Robin Rendle (@robinrendle) on CodePen.

If you’ve never seen that repeat() function after the grid-template-columns property then let me introduce you to one of the neatest features of CSS Grid! It’s a shorthand, essentially, allow us to more succinctly describe repeating values. We could have written grid-template-columns: 25% 25% 25% 25%; instead, but it’s cleaner using repeat(), particularly when you have more verbose widths (like a minmax() expression).

The syntax is essentially this:

repeat(number of columns/rows, the column width we want);

There are actually a couple of issues with what we’ve done so far, though.

First, in order to use this neat CSS function, we had to do a tiny bit of math. We had to think to ourselves what is the total width of the grid (100%) divided by the number of columns we want (4), which brings us to 25%. In this instance, the math is pretty darn easy so we don’t have to worry about it but in more complex examples we can completely avoid doing the math and let the browser figure that out for us. We do have calc() available to us, so we could have done repeat(4, calc(100% / 4), but even that’s a little weird, and there is another problem anyway…

The second issue is a problem with overflow. Because we’ve set each column to 25% and a grid-column-gap to 10px then that pushes grid element wider than 100%. It isn’t how you’d expect things to work from just looking at the code above but that’s how percentages work. What we’re really saying with the code above is „set each column to 25% the width of the viewport and have a 10px gap between them.” It’s a subtle difference, but it causes a big issue with layout.

We’ve inadvertently caused some horizontal scrolling here:

See the Pen CSS-Tricks: Grid Example 1 by Robin Rendle (@robinrendle) on CodePen.

This is where the fr unit can help us.

The fr unit (a „fraction”) can be used when defining grids like any other CSS length such as %, px or em. Let’s quickly refactor the code above to use this peculiar new value:

.grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-column-gap: 10px;
}

See the Pen CSS-Tricks: Grid Example 1b by Robin Rendle (@robinrendle) on CodePen.

That will look just the same as the example above because in this instance we’re setting each of our four columns to one fraction (which happens to be 1/4 or 25%). But! There’s no overflow on the x-axis anymore because setting each column to 1fr takes that 10px into account automatically and subtracts it from the total width available for each column.

Why the heck should I learn how to use this fancy new CSS length if I can mostly stick to the units like percent or pixels, you wonder? Well, let’s dig into a more complex CSS Grid example to explain why fr is a better alternative. In a new example, let’s say we want our navigation on the left followed by a twelve column grid which should look like this:

This is a pretty typical scenario for a lot of UIs and so using the fr unit prevents us from either making a separate grid div or fumbling about with calc. Because if we didn’t use fr in the example above then we’d somehow have to figure out the following:

the width of each column = ((width of viewport - width of nav) / number of columns) * 1%

That’s possible for sure, it’s just awfully painful to read, and if we changed the width of the nav then we’d have to do that dumb calculation all over again. Instead, the fr unit tidies all of that up into a super readable line of code:

.grid {
  display: grid;
  grid-template-columns: 250px repeat(12, 1fr);
  grid-column-gap: 10px;
}

See the Pen CSS-Tricks: Grid Example 2 by Robin Rendle (@robinrendle) on CodePen.

What we’re doing here is setting a fixed width in pixels for the first column and then creating twelve separate columns which are set at one „fraction of the free space” (literally how the spec phrases it). But there’s no crazy calculations or anything! It’s super readable and if the width of that left nav changes then the width of our columns on the right will adjust themselves automatically.

With just a little bit of legwork we’ve made our interface more maintainable for the future and we’ve ensured that our code is more legible for the next developers that are coming up behind us.

Information from other folks

Some of the fun and power of the fr unit comes from mixing it with other units. Imagine a fixed sidebar and main content area that takes up the rest of the space: grid-template-columns: 200px 1fr; easy!

Here’s an example from Alligator.io showing mixed units nicely:

---

Rachel Andrew has a video specifically about fr:

---

Anna Monus has a very good article on fr.

---

Yay for the fr unit!

---

An Introduction to the `fr` CSS unit is a post from CSS-Tricks

Post pobrano z: A Little Example of Data Massaging

I’m not sure if „data massaging” is a real thing, but that’s how I think of what I’m about to describe.

Dave and I were thinking about a bit of a redesign for ShopTalk Show. Fresh coat of paint kinda thing. Always nice to do that from time to time. But we wanted to start from the inside out this time. It didn’t sound very appealing to design around the data that we had. We wanted to work with cleaner data. We needed to massage the data that we had, so that it would open up more design possibilities.

We had fallen into the classic WordPress trap

Which is… just dumping everything into the default content area:

We used Markdown, which I think is smart, but still was a pile of rather unstructured content. An example:

If that content was structured entirely differently every time (like a blog post probably would be), that would be fine. But it wasn’t. Each show has that same structure.

It’s not WordPress’ fault

We just didn’t structure the data correctly. You can mess that up in any CMS.

To be fair, it probably took quite a while to fall into a steady structure. It’s hard to set up data from day one when you don’t know what that structure is going to be. Speaking of which…

The structure we needed

This is what one podcast episode needs as far as structured data:

• Title of episode
• Description of episode
• Featured image of episode
• MP3
  • URL
  • Running Time
  • Size in Bytes
• A list of topics in the show with time stamps
• A list of links
• Optional: Guest(s)
  • Guest Name
  • Guest URL
  • Guest Twitter
  • Guest Bio
  • Guest Photo
• Optional: Advertiser(s)
  • Advertiser Name
  • Advertiser URL
  • Advertiser Text
  • Advertiser Timestamp
• Optional: Job Mention(s)
  • Job Company
  • Job Title
  • Job URL
  • Job Description
• Optional: Transcript

Even that’s not perfect

For example: we hand-number the episodes as part of the title, which means when we need that number individually we’re doing string manipulation in the templates, which feels a bit janky.

Another example: guests aren’t a programmatic construct to themselves. A guest isn’t its own database record with an ID. Which means if a guest appears on multiple shows, that’s duplicated data. Plus, it doesn’t give us the ability to „display all shows with Rebecca Murphey” very easily, which is something we discussed wanting. There is probably some way to program out way out of this in the future, we’re thinking.

Fortunately, that structure is easy to express in Advanced Custom Fields

Once you know what you need, ACF makes it pretty easy to build that out and apply it to whatever kind of page type you need to.

I’m aware that other CMS’s encourage this kind of structuring by default. Cool. I think that’s smart. You should be very proud of yourself for choosing YourFavoriteCMS.

In ACF, our „Field Group” ended up like this:

We needed „Repeater” fields for data like guests, where there is a structure that needs to repeat any number of times. That’s a PRO feature of ACF, which seems like a genius move on their part.

Let the data massaging begin

Unfortunately, now that we had the correct structure, it doesn’t mean that all the old data just instantly popped into place. There are a couple of ways we could have gone about this…

We could have split the design of show pages by date. If it was an old show, dump out the content like we always have. If it’s a new show, use the nice data format. That feels like an even bigger mess than what we had, though.

We could have tried to program our way out of it. Perhaps some scripts we could run that would parse the old data, make intelligent guesses about what content should be ported to the new structure, and run it. Definitely, a non-trivial thing to write. Even if we could have written it, it may have taken more time than just moving the data by hand.

Or… we could move the data by hand. So that’s what we ended up doing. Or rather, we hired someone to move the data for us. Thanks Max! Max Kohler was our data massager.

Hand moving really seemed like the way to go. It’s essentially data entry work, but required a little thought and decision making (hence „massaging”), so it’s the perfect sort of job to either do yourself or find someone who could use some extra hours.

Design is a lot easier with clean and structured data

With all the data nicely cleaned up, I was able to spit it out in a much more consistent and structured way in the design itself:

This latest design of ShopTalk Show is no masterpiece, but now that all this structural work is done, the next design we should be able to focus more on aesthetics and, perhaps, the more fun parts of visual design.

---

A Little Example of Data Massaging is a post from CSS-Tricks

Post pobrano z: CSS-Tricks Chronicle XXXI

All the latest happenings! As I like to do, I round up a bunch of things that have happened in the past few months around here on this site, over at CodePen and ShopTalk, and other sites where I got to be a guest or was involved somehow. There has been some big releases, some redesigns, and a bunch of guest podcasts.

---

I got to be a guest on Relative Paths with Mark Phoenix and Ben Hutchings. It was episode 47 and the topic was dogmatism, a topic I weighed in on earlier with my post My Increasing Wariness of Dogmatism.

---

The biggest release ever on CodePen is CodePen Projects. It hasn’t even been out three months yet! As opposed to Pens on CodePen, Projects gives you an editor that is more of a full-on IDE with your own file system.

---

I was a guest on Eric Siu’s podcast Growth Everywhere, Episode 196 where we talk numbers and growth stuff. (Fair warning on the link: it’s pretty pop-up heavy.)

---

I also had a lot of fun on the Email Design Podcast, Episode 60, where I got to chat with Kevin Mandeville and Jason Rodriguez specifically about email stuff. That’s not something I get to talk about much, but I actually find myself doing quite a bit lately with email, and it’s a very weird world that somehow feels completely different than „normal” front-end development.

---

I have moved back home to Milwaukee, after spending the last 7 months in Miami. Bittersweet! Farewell, friends old and new in Miami. Hello, friends old and new in Milwaukee.

---

We’re less than a month away from the 10 year anniversary of CSS-Tricks! We’ll definitely do something. No rooftop party or anything, but definitely come see what we got on July 4th.

---

I redesigned my personal site. It’s nothing special to look at, but I think it’s going to serve my needs very well. The new site needed to clearly show: this is who I am, this is what I do, this is where I exist other places on the web, and most importantly, these are the things I want you to do.

The most fun little bit is the radio buttons by the bio area, which allow you to customize the length, first person or third, and what format it’s in.

---

ShopTalk also has a brand new website. Also designed and implemented by me, so, brace yourselves for utilitarian. This one was driven by backend data. I think I’ll write about that soon.

We recently did a podcast called On Podcasting where I got to chat with Chris Enns about podcasting equipment. I figured it was about time to get some advice and update my gear. I bet if you factor in all the ShopTalk, CodePen Radio, guest appearances, and videos I’ve recorded, I’m around 1,000 episodes of stuff. Probably about time I have some decent gear. I pulled the trigger on the major upgrade. I’ll have to post about that soon as well.

---

My public speaking schedule for the rest of the year is:

• June 16, 2017, CSS Day, Amsterdam, NL
• August 7-9, 2017, That Conference, Wisconsin Dells, WI
• August 17, 2017, Build Right: Maker Series, Dayton, Ohio
• August 28-30, 2017, An Event Apart, Chicago, IL
• September 25-26, 2017, Web Unleashed, Toronto, Canada
• October 9-11, 2017, CSS Dev Conf, New Orleans, LA
• October 12-13, 2017, Profitable Developer Bootcamp, Milwaukee, WI
• October 17–18, 2017, Smashing Conf Barcelona, Spain
• October 30-November 1, 2017, An Event Apart, San Francisco, CA
• December 11-13, 2017, An Event Apart, Denver, CO

---

CSS-Tricks Chronicle XXXI is a post from CSS-Tricks