Transcript

Dave: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about Web design and front-end development. I'm Dave Rupert. With me is Chris Coyier.

Chris: Hey! We have a special for you. We have Jen Simmons. Hey, Jen.

Jen: Hello!

Chris: Hey. I guess, a long time friend of the show, in the first year the show existed back in Episode 48, which is forever ago on this show.

Jen: I know.

Chris: And, in Episode #262, you were back to talk Grid. I think that's probably still a super-hot topic, and so we'd probably get into some of that stuff. But, you're at Mozilla now, right?

Jen: Yeah.

Chris: I think you maybe were just starting there then, but now it's been -- it feels like it's been a while, a couple of years, maybe.

Jen: I've been there three years now, like three years and a week or something, two weeks.

Chris: Oh, nice. Did they send you a little watch or something?

Jen: No, they didn't!

[Laughter]

Chris: Ugh! Sorry.

Jen: Uh, yeah. No. No. Yeah, it's good. I like it. I like it at Mozilla. I like being -- my job title there, Designer/Developer Advocate, it's really pretty -- it's a great--

Chris: Yeah. I think people associate you at Mozilla now, at least I do, and are just in awe of all the work you do. It seems like you're being highly effective as whatever your role is there exactly, letting people know what's possible.

[Laughter]

Jen: Well, thanks.

Chris: I get emails from you once in a while about, "Hey, Firefox is doing this cool thing." I'm like, "Oh, thanks. Good to know, actually, you know." I feel like the world doesn't keep me abreast well enough, dang it!

[Laughter]

Chris: If there's some technology you think I should know about, please email me and tell me. But, one of those recent ones was, "Hey, Firefox," what is it, "62, 63 rolling out soon," which kind of had a lot of stuff.

Jen: Yeah. Firefox 62 just came out yesterday. As we're recording this, it was yesterday. You know, sometimes it takes a day or two for each browser to update, so it's coming out right now.

Chris: Yeah.

Jen: Yeah, it felt like there was a while where there wasn't really a lot of new, exciting CSS coming out. All of a sudden, Chrome is. Chrome has the same shipping schedule as Firefox, and so Chrome just came out with some new CSS, and Firefox just came out with some new CSS.

Chris: Yeah.

Jen: It's always fun to be like, "Yay! New tools!"

Chris: Right, like I don't cover every single release of every single browser thing at CSS-Tricks because it's usually a little bit interesting, but not particularly CSS-y. But, back-to-back, both Chrome and Firefox had some pretty CSS-y releases, so that was nice. Well, what's the big stuff in Firefox?

Jen: Yeah, so we just shipped CSS Shapes, finally, like--I don't know--four years after everybody else. [Laughter] But, what it means is that folks who want to use CSS Shapes, there's more reason now than ever to go ahead and use it. I think that I've heard a lot of people over the last several years say, "Well, I would use it, but it's not in every browser," which is sort of silly because you could totally use it even if it's not in every browser. It's still not in every browser. But, it is now in Firefox, so Firefox supports shape outside and shape margin, and it lets you--

Chris: Shape margin?

Jen: You can float something like classically imagine an image, but you could also float a block code or something else, a block of color, and then flow the content around it. You float the first thing, and then you flow the rest of the content around it. Typically, you're floating an image, and you're flowing text. But, rather than having that text flow in a box, like in a rectangular shape, you can have it flow in a circle or flow in any sort of polygon, any shape you might make with a polygon or an ellipse. It's kind of cool.

Chris: Yeah, and it's a cool look. It's one of those things where it's like, "Oh, wow, the Web can do that?" You know.

Jen: Yeah.

Chris: We weren't able to do that before, so it has a very unique looking thing, with really no big sacrifice, right? It doesn't really hurt accessibility unless you, I guess, make it hard to read in some way.

Jen: Right.

Chris: But, not semantically. And, it just looks cool, so that's a nice one. You, I remember, years ago had labs, your labs thing that had all kinds of demos of different ways that you could do that, and it made for a great -- it makes for a great kind of progressive enhancement talking point because it's one of those things where you're like, "Oh, big deal. It doesn't wrap in a circle? So, what, you know?"

Jen: Right. I've shipped it on the Web Ahead website--I don't know--four or five years ago. Yeah, the places where shapes works, it wraps around the circles because each of the pictures of a person is in a circle. You get this kind of nice circular bio going around the outside of the circle of the picture of the person.

Chris: Yeah.

Jen: Then, in the other browsers, it was just sort of this square shape, which I actually ended up with a layout that I never would have come up with if CSS Shapes hadn't existed. Even if I removed the CSS Shape property and just had the kind of lollypop rectangular stairsteppy thing that I had created, I realized, oh, even just imagining the possibilities broke me out of a rut that maybe I would have just done a layout like everybody else does for their bios.

Chris: Yeah. I remember there used to be kind of a tricky way you could do it by floating 50 boxes all of different widths on top of each other.

[Laughter]

Chris: That was kind of a fun little hack.

Jen: Yeah, or like--I don't know--back in the fixed width days. I guess you could wrap each line of text in a span and then put like a different length margin on that span. But, you had to, like, pray that the type would never touch the sides.

Chris: Now, that really is affecting semantics and possibly accessibility--

Jen: Yes!

Chris: --because of the weird--

Jen: It's terrible, but back when CSS was new, we had all these ideas, and we were excited. We were like, hey, let's do this awesome thing. How would you do it? Oh, we can't do that. Now, here we are--

Dave: Responsive wrecked all that too.

Jen: Yeah, and responsive wrecked all of that, for sure. Now, here we are ten years later, you can totally do it, and people are like, "Nah, I don't want to."

Chris: Yeah, it's trendier now just to do rectangles.

Dave: I think the big news here is the Firefox dev tools for the shapes is amazing. I know you--

Jen: Thanks. Yes.

Dave: --advised on that. It is. It's the best. It actually makes the feature usable.

Chris: Well, if you're going to do this, you can't -- it's hard to do without some kind of help because you can't just invent coordinates in your brain.

Dave: Polygon paths. Like, oh, yeah, I'll just riff and do a polygon from memory.

Chris: Yeah, not happening.

Jen: Yeah, that's really the theory behind all of the new dev tools that we're making. It's under a little umbrella called design tools inside the Firefox dev tools, these tools for CSS. The CSS Grid Inspector is the first one. Now, we have a Shape Path Editor, which lets you edit shape paths, which are a thing in CSS that you use both for CSS Shapes and you use them for clip path.

If you're using clip path to clip what's showing, you're taking, basically, the box that is the content, and you're clipping it to not be a rectangle. You're clipping it to be smaller, and you're making it be some sort of polygon. It's so impossible to do that without a tool, and I wanted us to have one. I wanted the industry to have a tool where you could just really easily, quickly, just as easy as the color picker, basically. You go find the property that you've written the clip path for the shape outside, and there's this little icon as if, when you say color, and there's a little color palate icon.

Chris: Yeah.

Jen: Here you say, "Clip path," and there's this little icon of a tiny path. You click it, and it changes what's going on on the webpage. It brings up this tool, and you can grab and drag it. You can click. I think it's command-click. There's a keyboard shortcut too, and you can switch it into a different mode. You can mess around with it and figure it out.

Chris: It's right on the page.

Jen: Yeah.

Chris: It's not like an approximation of it or whatever. It's like an overlay on top of what you're doing. As you move the points around, you're watching the text reflow into position and all that stuff. It really does make this possible in a way that it isn't otherwise.

Jen: Yep, and this idea for this tool first came from Razvan Caliman when he was working at Adobe over there with Alan Stearns and a couple other folks on this Web platform team that Adobe had several years ago. I think they wrote the spec for CSS Shapes. I know they were working on the spec for regions, and they were working on these different kinds of specs that would allow people to do the kinds of graphic design treatments that you can do in InDesign or Illustrator or in these graphic design programs that people use, these Adobe products. They wanted to help get some of that stuff onto the Web, so they got these specs going, and they were advocating for these things. Razvan had made a tool very similar to the tool that we just shipped that is a Chrome plugin.

And so, I was standing on stage and telling people, "Hey, go look at this cool Chrome plugin," like--I don't know--four or five years ago, before I joined Mozilla. And, every time, people's mouths would just drop open. People were so excited about it. And, it really helped teach what's possible with shapes and clip path, too.

Chris: It's funny. I wonder why they never put it in Chrome dev. I know it's just a different company with different priorities and stuff, but it seems like it's four years old and loads of people love it. Just take it.

Jen: Well, and the great thing about being able to put it straight into the browser is that then, as the browser team, we got people who implemented CSS Shapes to create an API. We got people who, when we built the Grid Inspector, the folks who implemented Grid, or one of the other engineers, created an API so that the engineer, Gabe Long, who worked on the Grid Inspector, he could tap into.

There are just things that you can do when it's baked straight into the browser that you can't do when it's a plugin. Like the user experience design on the plugin, I had talked to Razvan years ago. I was like, "Why is it over here in this weird tab? It would be way better if it was this little icon right in line." He's like, "I know! I would love to do that, but I can't."

Chris: But, it's just not possible for some reason?

Jen: Yeah. But, now, Razvan works at Firefox. He works on this team, the designer tools team, so he helped finish the Shape Path Editor and got to do some of the stuff that he hadn't got to do before and make it way better.

Chris: What's your flow when you do it and you get it just right in dev tool? I feel like some people have this very exotic workflow where they've opened dev tools, and they've somehow mapped their dev tools so that when you make edits to the sources in dev tools, it can save it back out to disk. But, I feel like the people I know who do that are few and far between. Most of us use--

Dave: All members of the Chrome team.

[Laughter]

Jen: Yeah, they, like, hack their browser personally. I don't know. Something. Yeah.

Dave: Yeah.

Chris: Yeah. It is a very cool workflow, but I feel like most of us don't do that because most of us, for one thing, we're working in some kind of preprocessor language or something anyway that doesn't really jive with that particularly well. Maybe I'm wrong about that. Most of us have to find some way to copy and paste to what we've changed from dev tools back over to our source. I wonder how much you all think about that.

Jen: A lot.

Chris: Do you?

Jen: A lot. Yeah. There are other folks on the team who have been pushing for that quite hard because there is this way in which--I don't know--it feels like the old school people are like--and maybe I'm in this camp--"Well, this is just how it works. You open up your code editor, you open up your browser, you open up dev tools, and then you only make a few changes in dev tools. You keep track of them in your head, and then you just copy/paste everything back into the code editor. What's wrong with that? That's how you do it, right?"

Chris: Yeah, because we've been doing it for so many years.

Jen: Right.

Chris: But, I wonder if there's just little stuff like right-clicking. You know I use things like let's say you want to grab a little piece of HTML. You right-click it, and you say, "Copy outer HTML," or something, and it gives you that whole thing. But, what if, in CSS, you could click and say, like, "Copy this value," or, "Copy this key-value pair," or, "Copy this whole rule set"?

Jen: Well, part of it is, as we've gotten deeper into thinking about the dev tools as a design tool and figuring out the CSS as you go, and you might really want to go way down a path and try not just 2 or 3 adjustments, but try 30, 40, 50. What if you want to be able to take those and send them to somebody else in an email or in a chat?

Chris: Mm-hmm.

Jen: Have them open up their browser and see what you are seeing without it being a whole--

Chris: I feel like I saw some little service that did that just the other day.

Jen: Well--

Chris: You're talking about in the browser.

Jen: Yeah, but we're working on all those things. This team, the dev tools team, is talking about all of those things. Of course, because you've got to start small and iterate, we're going to start out with a way to keep track of the changes that you've made. If you've made a whole bunch of changes in CSS that you can just keep track of them. I forget what the very first scope is. A bit like if you're using some sort of word processor and you're editing an article with other people. It keeps track of the changes that have been made. You can look and see what's going on.

Yeah, like Git keeps track of changes. That would be the first step. Later, have a way to export them, so you could kind of email somebody a file, and they could run it. That team is definitely thinking about all of those different possibilities.

Chris: It feels like you've dipped your toes already because there's this whole scratchpad thing that feels aligned with that a little bit.

Jen: Yeah. I don't know if we've shipped anything yet. I should know more about where they are on this. But, Firefox Nightly is always a great place to go. You can grab it. Just search for Firefox Nightly or nightly.mozilla.org is a shortcut to get to the download page because anything that's coming, like track changes, will be implemented in Nightly.

Chris: Do you kind of prefer? Is Nightly even ahead of the developer version of Firefox?

Jen: Yeah. So, dev edition and beta are one version ahead. Firefox just shipped 62, which means dev edition and beta, Firefox beta--

Chris: 63.

Jen: --both switched to 63, and Nightly switched to 64.

Chris: Okay. If you really want the super cutting edge, it's Nightly.

Jen: Yeah. Then the other thing that Nightly has is stuff that it's not like everything in Nightly will come out in 64. It's more like 64 and beyond is in Nightly.

Chris: Yeah.

Jen: If there are things that are going to take four or five cycles to build, then they're in Nightly until they're actually ready to, as they say, get on the train, to get on the train to go to beta and then go to regular. Something like track changes, also, you can go to about:config, and there's this giant list of stuff that's half built. You can kind of like turn it on in your own browser.

That's what we did with Grid for a long time. Oh, if you go to about:config in Firefox, you can search for the word "grid." You can find it. You can turn it on. Subgrids will be there soon. It's not there yet, but maybe in the next month people could turn on subgrid and try out subgrid and see if they like it or not. It will be half broken for a while in all that stuff.

Chris: Yeah, that's a good one. I know there was so much pushback in the early days. Even some people that maybe have gone so far and said, "You shouldn't have shipped grid without subgrid." I guess I might disagree with that at this point because, obviously, Grid has been super successful and useful to a lot of us, even without subgrid. But, now that subgrid is here, I guess that makes everybody happy.

It took me a minute to even wrap my head around it because I was like, I think when people say the word "subgrid," what comes to your mind is, well, you can put a grid inside of another grid. You're like, you can already do that. You don't need subgrid to do that.

Jen: Right. Right.

Chris: But, subgrid is this way of sharing grid lines or something.

Jen: Yeah. Subgrid, it's so that you can put one grid inside of another grid, then the inner grid could get some kind of sizing based on the content that's in it or whatever. That sizing that's happening will affect the outer grid. Maybe there's more than one in their grid, and the sizing from one of the inner grids will affect the outer grid, and then the outer grid sizing will affect the other inner grid sizing.

Chris: They affect each other in a way that wasn't -- right.

Jen: Right, because right now the way that you definitely want to use Grid and Flexbox and just regular old flow content and multicolumn is that you're going to nest. You nest these things inside of each other. Everything is nested inside of something inside of something inside of something.

Chris: Mm-hmm.

Jen: You're going to nest grids. The question is, once we have subgrid in all the browsers and we're ready to use it, it'll be like, oh, do you want to have the nested grids affect each other when it comes to sizing information, or do you want them to ignore each other and just do their own thing when it comes to sizing? Both will be super useful.

Chris: Yeah, well, I can't wait for the layout-land videos.

Jen: Yeah.

[Laughter]

Jen: I can't wait until it lands at Nightly, so I can start playing with it. I think there are a bunch of us who are just kind of waiting to see is it really going to do what we're imagining it does. How is it going to feel? It's like prototyping something. Once you have it in your hands, it's always a little different than how you imagined it.

Dave: One browser always has to go first and, I guess, run it up the flagpole and see what everyone thinks of it.

Jen: Yeah, and I think this time it's going to be Firefox. I think we're ahead of Agalia on this. Agalia, of course, will be implementing it on behalf of Chrome and Safari.

Chris: Hmm.

Jen: I haven't talked to the Edge folks, so I don't know where they're at. Maybe they're working on it too. I don't know.

Dave: But, it doesn't stop there. The variable fonts inspector in Firefox here, the new one, is awesome and probably will change how we all interact with fonts in our Web inspectors.

Jen: Yes! Thank you, Dave Rupert, for keeping us on track.

[Laughter]

Jen: The other thing that shipped in Firefox 62 that's the big news for CSS is variable font support. Variable font, for folks who maybe aren't clear on what they are, is, with Web fonts, you can pick a font and it's awesome. You put it on the page, and it can be the size that you tell it to be. If you want to have a condensed version and a really super wide version, you want to have a really thin and a really thick, bold version, then you can have 4 fonts, 8 fonts, or 12 fonts. Sometimes the font family will have quite a few different fonts in that family. But, we all know from using Web fonts that you can't really use 12 fonts in a family on the website because then you're asking people to download way too much information.

Variable fonts is a way. It's like an update to the open type specification so that it's a new ability for fonts. It's not a different format for fonts. It's still going to be WOFF or WOFF2. It's still going to be open type, you know, like a font. But, it's a new superpower that fonts can have.

Basically, instead of having really thin font and then a different font that's really bold, you can have one font that has an axis for weight, like it's a continuum. At one end of the continuum it's really thin, and at the other end of the continuum it's really thick, really bold. Then you can sort of pick.

CSS, you'd write font-weight:100, 200, 300, up to 900. I always kind of wondered, why is it 400 and 500? Why? You can't write 497.

Chris: What about 420? Mm-hmm.

Jen: But, with variable fonts, it's exactly how it works. It's almost like they reserved all those extra numbers for us for now. [Laughter]

Chris: Yeah.

Jen: Now, you can say 427, and it means something. Then you can say 456, and it means something slightly different. You can adjust. You could sit there with your typography and adjust and adjust and adjust and adjust. There are a whole bunch of cool websites that you can find fonts. You can play with fonts. Axis -Practice is probably one of the most well-known because it came out either first or it was one of the first.

V-Fonts is a great site that you can find them. They're trying to basically catalog all of the new Web fonts that are out there that have these axes in them.

Chris: I've seen these, and they're fun because not only do they show you what the font looks like, but they have all these sliders and stuff that allow you to play with those things.

Jen: Yeah.

Chris: But, that's what you're moving into the browser, which is significant. Right?

Jen: Yep, because my experience with, say, even just trying to pick a font, like trying to pick. You go to the website for--I don't know--Typekit or Google fonts, or you go to some website that has a whole bunch of fonts, and you play around with them. They have a chance to change the sample text or a change, maybe, to change a little bit of how the font looks. You pick one, and you think, "Ah, this is it. This is perfect. I love this font." Then you put it on your real website with your real content with other kinds of parts of the design, and you're like, "That doesn't look anything like I thought it was going to."

Chris: Hmm.

Jen: I have found myself struggling with that for years as a designer, kind of like realizing that looking at a font or evaluating it or picking, adjusting it, changing the color, the size, or whatever, on a third-party website does not get you the same results as sitting there and doing it on your real website for real in the browser. Even something like Photoshop is different. You can pick and pick and pick choices until you think you've got it perfect, but Photoshop doesn't render fonts the same way that the Web does. There's nothing like actually getting into a real Web browser with your real content and your real branding and your real everything and perfecting the choices that you're making.

Jen: When I saw variable fonts coming, and I saw how excited people were and how popular it was going to be very quickly, I finally started learning about open type features, which I had kind of not learned about CSS level 3….

Chris: Those are things like ligatures and swatches and things like that, right?

Jen: Yeah, and which do you have currently? Does it work or not? All these little details, I had just kind of never gotten into. It seems like one of those things that was on my list, like, someday I'll go learn that stuff, but I don't know. I don't get it. There's something missing.

This January, I dove deep into all of that stuff and came back up and was like, "Oh, yeah. The reason people don't really understand how to use open type features is that it's like a big box of mystery, and it's really hard to know what's going on." I wanted all of that into a font tool, so the very first version of the font tool, which isn't in Firefox yet. It's coming out in Firefox 63, in October; I think it's October 25th or somewhere around there. But, you can use it today in Nightly. You probably could use it today in dev edition, although I might suggest using Nightly because, if there are any updates or changes that we need to make, it will happen in Nightly immediately, where it will take six weeks for them to land in dev edition.

But, there's a whole font panel. The font panel has been there quite a long time, but we basically ripped out what was there and put in a brand new font panel. The new font panel has all of these different sliders for variable axes. Whether they are the registered axes, the sort of official axes that a font might have like weight or stretch, which uses the font weight CSS property or the font-stretch CSS property.

Chris: Yeah, I was going to say these variable font things can be anything, right?

Jen: Yeah.

Chris: But, there are some "official" ones because we have font weight in CSS already. It's not mandatory that somebody making a variable font makes theirs font weight ready.

Jen: Right.

Chris: But, it's probably pretty common.

Jen: It's common, so that's the variable font axes people. There are the people who are on the committee to decide what the registers axes are. There are five right now. There'll be more later, probably.

Chris: Mm-hmm.

Jen: They're basically just trying to say, "Hey, if everybody is going to have some sort of a weight axis, let's make it official, and let's map it to a real CSS property like font weight." If somebody wants to make one that's, like, more cowbell, less cowbell, well, that's not an official….

Chris: Right. There's one that's like how many leaves or how much blood dripping off of this font do I want.

Jen: Right.

Dave: Yeah.

Jen: Right.

Dave: Oozy. Ooze factor, I think.

Jen: Right, so those are not ever going to be official. Then you use the property that's font variation settings. You use this kind of secret four-digit code that you need to know. That's another reason to use something like the Firefox Font Editor Tool because, if you don't know what those codes are, you don't know what the axes, like what axes are available.

Chris: Crazily, there's no way to find out. You just can't find out unless you use some kind of tool to suss it out for you.

Jen: Exactly.

Dave: Or, you're on the font foundry's webpage, like….

Chris: Yeah, they have it documented.

Dave: …all the open type features.

Jen: Or, when you download a font from a font foundry, if that's how you, in fact, bought the font, it came with a PDF.

Dave: No, I pirated it from font….

[Laughter]

Dave: This is 2018.

Jen: It's funny to me, though. I'm like, "Oh, those PDFs have incredibly valuable information in there," because they'll tell you what kind of stylistic alternatives they have or what kind of options for numerals or caps or something they have. I just never knew that before. Like, oh, you should read the manual that came with the font.

Dave: Yeah, but you wouldn't know that. You don't know. Like tools are toys, you almost would say, that you have available that you can play with and kind of mess around with your font.

Chris: You know what I find interesting for the desktop people, like, maybe if you open that PDF up in Illustrator, I'm not sure how that font gets embedded or whatever, but I know that there are variable font tools shipping in the Adobe suite now too. It's not quite the same, as Jen was saying, as working in the browser, which I couldn't agree with more. But, still, you know, some people have a workflow in which you're working with a designer or whatever.

Jen: Yeah.

Chris: It's nice that those designers can produce things using those variable fonts, using the same type of sliders and tools that we'll have available.

Jen: Yeah. Variable fonts don't just work on the Web. They work everywhere. You might be using a variable font to do an illustration in InDesign and then to do the magazine layout in InDesign and illustration in Illustrator, and then you're going to use them on the website, right? That's part of the idea is that, yeah, we need tools everywhere.

It's really interesting. Fonts are so much more complicated than I would have realized. The more we dig into what it takes to build these tools, the more confused the team even becomes and the more we're like, "Oh, my God. This is so hard," because it's not just CSS. It's also the font file and understanding what's happening with the font file and whether it's succeeding or failing, and also the operating system of the computer.

Dave: Yeah.

Jen: Variable fonts in Firefox and in Safari both only work in Mac OS 10.13 and above. If your Mac is running an operating system from the year before last, then you don't see the variable fonts.

Chris: Wow. It's that low level of how it needs to--

Jen: Yeah.

Chris: Yeah. Hmm.

Dave: Yeah.

Chris: Well, I'll say, if this variable font stuff is making you very excited and you don't listen to every episode of ShopTalk Show but want to hear a lot more, Episode 296 with Jason Pamental goes way into that and even 314 when we talked to Tim Brown about flexible type stuff. Variable fonts come up, so those two would be good episodes to listen to.

Jen: Yep. Jason just wrote a big guide for us, a variable font guide on MDN.

Chris: Wonderful.

Jen: There's a brand new, a whole thing on MDN about how they work and stuff. Yeah.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you by Jetpack, that WordPress plugin that brings a whole bunch of power to your WordPress install. Here's one of the, like, overall categories of things that it can do for your site. One is kind of like protect it. For example, you can just flip a switch and then you'll get email notifications if your site goes down, which is a dang nice thing to know, and, of course, when it comes back up again. If there's any problem with your site, you don't have to wait for a user to find out or whatever. You can get notified of that thing.

Perhaps more importantly, though, depending on which Jetpack subscription you get, it connects with a service called VaultPress from Automattic as well, which backs up your site, the theme files, all the files that run WordPress and the database and your media files. It's absolutely everything from your site, so it's totally safe. If anything were to happen to it or if you were to even screw up your site in some way, you have backups of it. That's such a fantastic thing, and you can kind of trust them to do it well.

What's cool about VaultPress is that it kind of works both ways. You can restore from it as well, so it's like if something were to go wrong with your site, you could roll back on the same server, which is kind of cool, but it's kind of a fun, tricky little thing. You can use it to move servers as well because you can restore from a backup on VaultPress on, like, another installation of WordPress. I think that's kind of cool is that it's back up for you, but you can use that backup to restore to another location. It's kind of a cool way to move a site if you need to.

That's just a few of the things that Jetpack can do. I find it tremendously worthwhile on all my WordPress sites because of all that and all of the other stuff that it just. It just makes it kind of one of those no-brainer plugins for me. Check them out. Good-bye.

Chris: Okay, so we talked a bit about grid and subgrid and shape path stuff and variable fonts. There's just a lot happening on the Web. I feel like it's been your message for possibly a number of years now that all this stuff is kind of giving birth, perhaps, to a new era of Web design.

Jen: I definitely believe that. That's the conference talk that I'm giving this year at An Event Apart and other conferences is, this is the fourth year or, actually, the fifth year, the fourth talk that I've written kind of going deep dive into layout. I feel like now that Grid has shipped and now that we've had some time to really start to use it and start to figure out, we kind of can see the whole landscape that we have at the moment.

Rachel Andrew has been talking about a lot of this stuff, too, and focusing on sizing and understanding sizing and understanding flow. I realized we really have to go back and learn what does it mean to not use any layout method at all. Why is it that things are the size that they are when they're just in a flow layout?

Chris: Yeah.

Jen: Putting all those pieces together, for the first year of learning Grid, I was very much of the mindset that this is really awesome. It's responsive Web design plus. It's just like responsive Web design way easier, done better.

Then the deeper and deeper I dug, the more I started to realize that I don't think that this is responsive Web design layout better. I think that this is actually a whole new era in what's possible in layout. I think that partly because I've been doing CSS since the beginning, and I've been making websites since before CSS existed. We've gone through these eras before where tables for layout was new at one point. Then it went away because we decided that using Flash was better. That went away because we decided that doing Fluid with floated layouts was better and fixed width layouts and all those blog layouts that we were doing.

We've gone through these different moments, these eras, usually around four to six years long. I think responsive Web design is actually the longest we've had so far because it was actually all of eight years where we sort of said to each other, like, "Oh, what's the best practice? "Do it like this." "Oh, what should our wireframes look like?" "Oh, they're going to look kind of like this."

I think we've struggled to find a way to do layout because we haven't really had real layout tools, and so we've been trying one hack after another after another, and each hack has been sequentially better than the ones that came before it, but we're still struggling with these hacks. I think that we've compromised our design ideas and our graphic design, you know, like what we might want to do with graphic design because the technology just couldn't do it.

I think, at this point, it's sort of the dynamic between what's possible and what we want. We don't have this kind of tension anymore or not to the same degree of, like, oh, I want to do this amazing graphic design thing. But, if I did that, then the site would be inaccessible. Or, if I did that, then the site would be -- the content would be so screwed up we couldn't use it again if we redesign later.

The dynamic, the way the things affect each other has just changed so drastically with CSS Grid showing up that I dared to stand on stage at An Event Apart this April or this whole year and say, "I think the ideas about layout that were so dominant in the responsive Web design era are actually over, and I think we need a new name. I think we need to stick a flag in the ground and declare a new era so that we can really understand how different it is. Then we can talk about the new choices and have words for them and be able to explain them to each other." I'm proposing that we use the name "intrinsic Web design."

Chris: It might be that. Maybe it's more complicated than this, but maybe if you just were to -- even if you were to use CSS Grid to set it up, but if all you were going to do is set percentage, width, columns, and then maybe change the meta-media query, that's maybe still responsive design.

Jen: Yeah.

Chris: But, in this new world, if you were to say, "Well, I'm going to set up a grid," but the grid, some of these columns are just going to be based on the size of content within it. If I change the font-stretch property on a font, it might push that a little wider just naturally because it has some kind of auto-calculatedness to it.

Then there's something over here that's fixed. There's something over here that has a fraction of what's left. There's something over here that can go this small, but not any smaller, and this big but not any bigger. We're thinking about the way that we set up grids in a more, I guess -- I don't know. It's tempting to say "complicated" because that's what it is.

Jen: It is more complicated but, also, I think it is much more like we're programming a layout algorithm rather than telling the browser where to put everything. It's almost like programming a miniature artificial intelligence engine for layout for the page that you're building instead of, "Put this here. Put that there. Make this this wide. Make this that wide." It can be that. It doesn't have to be.

The thing that, to me, the biggest difference between responsive and intrinsic Web design is that, in responsive, let's say you have five columns wide and, at some point, you're going to make it four or six or whatever. Let's say, at a certain screen size, you have five columns wide. All five of those columns, they're not real, for one, but they're pretend columns. The pretend columns are all set in percent. And so, as you adjust the width of the browser window, everything gets bigger the same amount as everything else, and everything gets smaller the same amount as everything else.

It's so obvious that we didn't even really notice that that's how it works. It's just how it works. You have five columns. They're always getting bigger or smaller at the same rate as each other as the window gets bigger and smaller. But, with intrinsic Web design, to keep it a little bit simple for a moment, if you defined a few of your columns and FR units and you defined other columns using min/max, as you open and close the window or make it wider or narrower, probably the FR units would grow in strength while the min/max ones stay the same until you get to a certain smallness. You squish it down, and then the min/max ones start changing size while the FR unit ones stay the same.

When I first saw that, I was like, "What in the world is going on?" I didn't know that was going to happen. I just was coding lots of weird demos and, like, throwing things at the wall and seeing what happened. I was like, "What the heck?! Why is it?!" It's because of the way that an FR unit is defined, because of the way that min/max is defined. Then you also have auto, and you can make things.

Chris: So, it is spec'd out. This isn't going to hurt us across browser. It's pretty consistent.

Jen: Oh, it's completely consistent. It's totally spec'd. I just hadn't read or memorized the grid auto placement or the grid sizing algorithm.

Chris: It's tough to do over a podcast, but can we do the order? What's the most dominant thing? What will move first when you re-change some things?

Jen: Let's set aside auto width stuff because auto width stuff makes it all--

Chris: Auto is weird?

Jen: Auto is weird. Auto depends completely on the size of the content that's inside it. That's super hard to explain, so let's just leave that aside. Pretend we don't have auto, but we have FR. We have a min/max. We have a fixed width.

I should read the algorithm to be able to tell you what the browser is thinking. This might be -- I don't know that. I don't know the algorithm, but what I do know from the front-end developer point of view is, of course, the fixed width one is going to be whatever size that you told it to be.

Chris: Yeah.

Jen: Maybe you said 200 pixels. Maybe you said 12M, which actually gets calculated to a pixel size. Or, maybe you said 20%, which also gets calculated to a pixel side.

Chris: You were saying percentages are a form of fixed width.

Jen: Percentages are actually a form of fixed width, at least especially from the point of view of the browser because it's like a known length. You're giving it a fixed length, which depends on the width of the window or the container block, actually. It depends on the size of the containing block. It's going to calculate, oh, you're supposed to be 50% of your containing block. Well, your containing block is 600 pixels, so that means you're 300 pixels.

Dave: Especially on, like, a phone. That's easy to imagine 100% of the width of the phone. Okay. I know that.

Jen: Right.

Dave: The browser just--

Jen: Viewport units were the same way, too. If you say, "I want you to be 12 viewport units," VH or VW. If you say, "Fifty VW," then that's like a pixel. It's calculated down to a pixel number, right? You've got these different ones that are kind of like set numbers. Those get set first. Then, the min/max one, basically, min/max, you say, "Min, max, open parenthesis, number." Maybe there's a comma. I don't remember. This is terrible. I don't remember. Then the second number, and then close parentheses. I think there is a comma.

You're basically saying, "I don't want it to be any smaller than the first number, and I don't want it to be any bigger than the second number." It will try to be as big as it can be, but it might not get all the way there. If it doesn't, then it will make sure that it's never smaller than the smallest size. But, that kind of has a medium rankish thing.

Then the FR units, FR units will take up all the extra space. If you calculate all the known width things to be the widths that they should be, and then you make the min/max one be max, then the FR unit one will get whatever else is around. That's what the FR stands for is fraction of available space leftover, a little bit like Flexbox, although it's not the same, but a little bit.

If you have four 1FR columns, then the browser looks at, okay, well, how much more stuff do we have? How much more space do we have? Okay, let's give one-quarter of each of the extra space to those four 1FR unit things.

Chris: This is so fascinating.

Jen: But, the cool thing, one of the awesome, one of the best things that I love about even if you just want to do only FR units.

Chris: Right.

Jen: If you do 12 1FR unit width columns and you have nothing else going on, then it's going to act an awful lot like responsive Web design because those four columns are going to shrink and grow at the same rate, so that's cool. There's nothing wrong with that. Right?

Chris: Right.

Jen: You don't have to use these superpowers. I just want people to know that they could.

Chris: I love this. It's so cool.

Jen: But, still, it's different than using percent because, with a percent, let's say there's a photo in each one of those columns and the photo, for some weird reason, is 100 pixels wide. Every one of those is 100-pixel wide photo and they don't have any percent CSS on them. They're just set to 100 pixels.

If it's all percent, then you can stretch all the way out and there'll be less extra space. But then, when you squish all the way down, the columns will be, if they're--I don't know--12.5%, they'll be 12.5% of the containing block. If the containing block is too small, then all those images will start overlapping with each other. Right? They'll stick out. You'll have overflow problems.

Chris: Mm-hmm.

Jen: But, FR unit columns never shrink smaller than the min-content size of the content that's inside of them, so those 12 1FR columns will grow and shrink. They'll look remarkably like percent size columns, but then when you squish them all the way down and you get to the point where, I guess, it's 12 100-width photos, it will stop, and it won't squish anymore. It will never get smaller. The whole thing will overflow out the side of the container.

Chris: Which kind of sounds bad, but it's kind of desirable.

Jen: It's really awesome. It's basically like a protection against that mug graphic that everybody has where it says, "CSS is awesome," and the word "awesome" is sticking out of the box."

Chris: Yeah.

Jen: It's like if that box were sized with the 1FR unit, then that word "awesome" would always fit.

Chris: Mm-hmm.

Dave: You solved the coffee mug problem?

Jen: We solved the coffee mug problem.

[Laughter]

Chris: I put together a little thing here. This is fascinating. Okay, let's say there are four columns, and I know this can get way more interesting and complicated, but display grid and then you're setting up the columns. My first one is 1FR.

Jen: Yeah.

Chris: My second one is min/max 50 pixels and 100 pixels.

Jen: Okay.

Chris: My third one is 20%.

Jen: Yeah.

Chris: The last one is auto, and I know that's a complicated thing.

Jen: We can talk about auto, but yeah, I want to talk about list first.

Dave: Which div gets to New York first?

[Laughter]

Jen: Well, actually, auto. Auto will probably hog up all the space first.

Chris: Well, I only put the letter A in it, so it's definitely not doing that.

Jen: No, then it will go to min-content size, which is the width size.

Chris: Really, really quite narrow in this case.

Jen: Yes.

Chris: But, they all have the letter A in them, which I know isn't the best use, but that's just the way it is.

Jen: There's nothing wrong with that. We're going to keep talking down this example, but I just want to interject that part of why I think people don't necessarily understand this thing about Grid and also don't really understand Flexbox is that so much of the time we don't actually put real content into the demos or the things, those experiments.

Chris: Right.

Jen: Without real content, a lot of the dynamic that could happen won't actually show up. If you actually put four paragraphs of text in that auto container--

Chris: Yeah, well, let's talk about that.

Jen: --it will act completely differently than if you just put the word A in there.

Chris: So differently if you put nothing in there.

Jen: Or, if you say, just leave it blank, right?

Chris: Yeah.

Jen: Like, sometimes people will make demos where, like, every item in their flex or grid is just a color block, which is cool. That's fine. But, if you take a color block, the min-content size of a color block is zero, so it will just squish all the way down to nothing. Some of the stuff around, like, "Well, how does it behave?" totally depends on what's inside of it.

Chris: Right. We know images are weird as they're loading and all kinds of stuff. But, anyway, in this particular example, because this is just such a cool way to look at this with just the letter A in them, the 1FR one, the very first column is the one that shrinks first. All the rest of the three of them just stay the way that they are because fraction is just taking -- I guess that makes some kind of logical sense, right?

Jen: It gets all the extra space. When there's lots of space, it gets all the extra space, and it will squish all the way down to its min-content size, which is the width of the character A.

Chris: Letter A, which is weird, but you know.

Jen: Min/max won't start squishing until the 1FR hits min-content size.

Chris: Right. Right, right. The next one to go is -- I'm finding the min/max and the percentage one kind of go at the same time until the minimum hits, and then the percentage one acts alone.

Jen: Right. Yep.

Chris: This is so cool. Just to wrap your mind around this, now you can design a website ready for this weird--

Jen: Yes. That's what's exciting is that once you've played around with them enough, not to master it, but just enough to kind of have a clue, you can start designing with this.

Chris: I would think auto is almost a bad word here because, like you said, okay, I put the letter A in that last column, auto, and it's barely there. It's just there. Then I type; I'll put a Lorem Ipsum paragraph in there, and it absolutely smashes everything to a -- it's a hog.

Jen: It's trying to get to max-content size, so it's like I'm going to just make that one paragraph be on one line, and I'm never going to wrap.

Chris: Never, right.

Jen: It just plugs up all the space.

Chris: Unless I absolutely have to wrap.

Jen: [Laughter] Right. That's just with text, yeah. But you know what's really crazy? You've got your auto, and you've got your min/max. Min/max will stay at max for a long time. But then, all of a sudden, at some point, your min/max and your auto will both be squishing.

Chris: Right.

Jen: I'm like, well, when does that -- when? When is it that the min/max starts squishing? Auto has been squishing the whole time.

Chris: I can get them to both squish. Yeah, yeah, yeah.

Jen: Do you know why? The min/max starts squishing at this magical, whatever time. I don't know. I don't know how the engineers wrote the code to make the browser do this.

Chris: I could even get the percentage and the min/max and the auto to squish at the same time.

Jen: Yes, but the min/max and the auto are dynamic. The algorithm is set up so that they end at the same time. The min/max will hit min at the same time auto hits min content.

Chris: Oh! Wow!

Dave: Hmm.

Jen: Yeah.

Dave: Wow.

Jen: They change at the same rate of change, but they change the beginning of the rate of change and the min/max happens so that they hit their mins at the same time, even though one is a min-content size and the other one is a min size. It's crazy.

Dave: I was just going to say, this is maybe the only episode of ShopTalk Show that absolutely requires a CodePen to fully understand.

Chris: Oh, I got one going here.

Jen: I know.

Chris: I feel like that concept has roots in something like keyframes, I which that weird stuff happens so that they end at the same time.

Jen: Maybe. Yeah.

Chris: There's some precedence there.

Jen: I find myself reaching for the very dusty and faded, I can't remember any more graphs in my head that got there during calculus when I was learning calculus because it has everything to do with rate of change and things not necessarily being a linear rate of change but happening on a curved rate of change.

Dave: Wow.

Jen: Also, if you make one FR, you make columns like this--1FR, 2FR, 3FR, 4FR--and you put a bunch of content in them, they will change at different rates of change from each other. Let's say you make two columns. One is 20% and the other one is 40%. They're going to shrink and grow kind of at the same rate of change. But, if you make two columns and one is 2FR and the other one is 4FR, they're going to change; the rate of change will be different.

Chris: It'll be more rapid for the wider one?

Jen: They will be more rapid for the wider one.

Chris: Hmm.

Dave: Hmm. Interesting. It's like there's logarithmic algebra inside of that.

Chris: There are probably lots of people on earth that will never know this, that it just doesn't really matter. I think it'd maybe unlock some super powers for you if you do know it, but probably not like totally vital.

Dave: This is how to impress on an interview.

[Laughter]

Jen: Well, no, no. I would say this. The number of people who understand the underlying math are small. I could probably name them by name. There's like seven people.

The people who -- front-end developers are not those people. I don't need to understands the mathematical equations underneath this stuff.

Normal people won't ever know that this is happening because they don't grab this outer edge of their browser window and shrink it and grow the width of the browser over and over and over and over again in order to see what a website does. Right? That's been through the whole time with responsive Web design.

The experience of responsive Web design for our customers, for our users is just simply that they open up the website in whatever browser they have at whatever screen size or window size they have, and it fits. It looks nice, and they can do what they came to the website to do, right? That's not changed. There's nothing more exciting about intrinsic Web design than that.

But, in the new world, for the people who are actually designing a layout, especially when you're designing a system of layouts where every page has a different content on it and sometimes you have photo and sometimes you don't have a photo. Sometimes you have a long headline. Sometimes you have a short headline. It's always a little different.

Understanding the difference between using min/max or using FR units or using some of these other choices and understanding what kind of different -- you could actually have two layouts that look pretty different at the exact same browser window width simply because the content is different. Right? You might have -- you work for a big newspaper, and you're putting out -- you build a template, and the template is used on 50 articles over the next year, and you could bring up that template in the same exact size browser window with four different articles and the layout might look pretty different. There's a way in which you can algorithmically program a layout that's going to look really awesome all the time but handle different content and end up with a different layout depending on the content, if that makes sense.

Dave: Yeah. The image example, if you have a bigger image or something in there, it'll shapeshift to that image.

Jen: Right, or you could do it so that the length of the headline sets the width of the image, so that the length of the headline and the width of the image are always the same.

Chris: Mm-hmm.

Jen: When the headline is short, the image is narrow, and when the headline is long, the image is bigger. It'd be really simple.

Chris: Yes.

Jen: We're getting kind of complicated in the explanation, especially because this is an audio podcast trying to convey visual information, but it doesn't have to be complicated.

Chris: Hopefully this isn't derailing, but if you set -- does performance factor into this?

Jen: No.

Chris: Like when it has to calculate, it doesn't really? Grids are fast, period, kind of thing?

Jen: Yeah. That's why it took five years for the CSS working group to nail the specification, which they started doing in 2012, they were done in 2017, because that was a huge question. We're really going to do this? What about speed? Are we going to be able to do this and have it be fast? The answer was yes.

Chris: I feel like Flexbox gets dumped on once in a while. It's not as firm. It's intended to be rather flexible in that way. If you use it for a full page layout, it's still just as wibbly-wobbly as anything else you did, if not more so.

Jen: Yeah.

Chris: It's a little slow for a full page layout.

Jen: Yeah, I can't imagine trying to figure out a full page layout using Flexbox. I would lose my mind.

Dave: What I like about this and your kind of intrinsic design call is, I've done a lot of custom layouts in the past, like very blown out, pixel-perfect things. But, they were kind of just a nightmare to maintain and update. If somebody wants a text change, you fall apart because it didn't scale in the hardcoded values.

The thing with Grid in this kind of intrinsic design stuff is the tools are here. We just need to use them. The syntax couldn't be easier. The grid template columns, we described just a worst case scenario for good template columns, but it is so easy to use and program a grid that not only are grids easy to make, but it's cheap, and you can update it easily and modify it.

You can add another column pretty easily. It's not the end of the world to modify the layout, which I think we were in previously. Up to earlier this year, it was a pain to overhaul a layout, but now it's relatively simple.

Jen: Yeah, I feel like we're all pretty traumatized from having layouts just shred themselves. You'd touch it one too many times and it just falls apart. [Laughter] You do one too many experimental adjustments, you're trying to do something cool, and the layout just completely falls apart.

And so, we've trained ourselves, the designers and the developers, to never take risks, to always think that that cool idea is never going to happen. We can't afford that. Maybe we could engineer it and it would work, but it would only work for this content and it would take us three weeks to do it.

Now, what I want, what I hope for the industry is a chance to sort of get through that trauma, work it out, and reverse it, and escape it because it's just so different now where you can actually sit there in--I don't know--45 minutes, play around, and just try a whole bunch of things and come out with something that is really dynamic, very robust, not at all fragile, will hold up no matter what kind of content you throw at it, but is more interesting and visually dynamic or something, some expression of the brand, or some expression of the voice and tone of the content that is just stronger than what we've been doing. Which is, what have we been doing? Well, we've been so scared to touch our layouts that we've been downloading Bootstrap or downloading Foundation. We've just been kind of following, like doing paint-by-number stuff, because we just couldn't afford the time to deal with how hard it was to code.

Dave: But now, it's like adding a grid, display grid, and then grid template columns, and maybe grid gap, but it's as easy as setting a border with a border radius.

Jen: Yeah. [Laughter]

Dave: And, we don't hesitate to do that.

Jen: Right.

Dave: Now we can just schmear a custom layout and really easily.

Jen: Yeah, and because of the nature in which things are nested, you don't have to burn down everything you have right now and start over. You can just say, "Oh, well, we're using this way to do layouts that we've been using forever. Let's just add, but I'm going to do a new teaser page and, in the main content column of the new teaser page, I've got to lay out a bunch of images. But, maybe instead of doing a classic layout with that using Bootstrap or whatever is already running, I'm going to ignore what we have already running, and I'm just going to do Grid right here, this little thing right here. I'm going to use Grid," and see what you might come up with and iterate our way there. It's not all or nothing.

Chris: That's such a big deal. Every good technology that's ever come along, it was kind of a requisite that it's possible to sprinkle in or deal with an existing. How much Web design work is on sites that already exist versus greenfield?

Jen: Yeah.

Chris: It must be 95 out of 100 jobs are on existing sites.

Jen: Yeah. No, and I think it's weird. People sometimes have this sort of all or nothing thinking, and so they think, well, we can't use Grid because of whatever, IE, whatever. It's like, but what's the fallback going to be? Maybe you decide not to use Grid on the header because you've done this whole float-based layout for the header, and you might as well just keep it. That's fine. You do need the header to be the same in all the browsers or close to the same. But, what about that teaser card layout? Does the teaser card layout--? Maybe use Grid on the teaser card layout and you decide not to use Grid on the header, and you use Grid on the header in two years or something.

But, people aren't thinking about it that way. They're thinking about either we have permission to use Grid on everything, or we have permission and we don't use Grid on anything because we're scared of it. I think it is about iterating and playing, and I also think it's about, if anything, the thing I'm not hearing people raise as a concern, but I would raise as a concern more, is if we want to do these kinds of more dynamic layouts where the content is dictating the results to a degree and we're programming sort of what happens at the minimum and the maximum and which columns get wider or narrower before or after which other columns.

How do we communicate that if the designers are designing everything in some sort of static way in Figma, Sketch, PDFs, or Photoshop? There are a million tools, but all of them are static. I guess, now, people have the system where they draw three things. They draw a mobile layout, a tablet layout, and a desktop layout.

Chris: Right. That's pretty common, and it kind of does the job, but it definitely doesn't help with this type of level of nuance, for sure.

Jen: Right.

Chris: I think design tooling is trying to catch up with that. Doesn't it seem like it? There are little plugins that are like, "Yeah, install this thing, and now you can anchor your design elements to things so, as they grow and shrink when you change the artboard size, they move along with things, and you can add little rules to what they do," but it feels like a lot of work. I don't know. Then how do you guarantee the person looking at it is dragging it around like you intend them to do? It really is tricky.

Jen: Yeah. I also think that it's so much -- why learn an entire complicated tool that has its own thing when you could just learn CSS and do it in the browser?

Dave: Yeah.

Jen: It just emphasizes for me the need for prototyping.

Chris: That might be -- not to argue, but it's like a little oversimplified. I feel like there is a purpose for design tools that unlock some creativity. While I'm not thinking about CSS, I can think about more bold design decisions and things. But then, the fact that I've limited myself because I'm in this weird tool.

Dave: But then, you ended up at handholding a phone with the app inside of it and then three bullet points arranged with icons horizontally.

Jen: No, I totally agree that there's a time to just imagine. There's a time to scribble on a napkin. There's a time to use a program like Sketch, Figma, or whatever. There's a time.

I believe there's a time for every one of the tools that people use. I don't have a problem with any of them. I think, for me, the question is this handoff where the designer is involved to a certain point and then they hand everything off. Then the front-end developer takes over.

Chris: Yeah.

Jen: There's a way in which most process, most teams make this assumption that static drawings are when the designs are done and then the designer can bail, and the front-end developer is going to take it from there, and the front-end developer is not going to be making any design decisions because the design decisions have already been made. To me, that's not how it actually is going to work unless you want to restrict yourself to what was possible in the world of responsive Web design.

If you want to do any of this stuff that's more dynamic, you can still use the exact same process that you've always used with the exact same toolchain that you've always used. I just want to either acknowledge that the front-end developer is the person who is actually finishing the design of the layout--

Chris: That's so great. That's exactly what's happening. I have some designs right now that are beautifully designed in one static, fixed width.

Jen: Right.

Chris: I'm going to take over and, because this is my project, I'm going to interpret these designs, but bring my -- I'm going to take these ideas that you have, these different column widths that flex into it, and I'm going to make that happen with this design, but that makes me part of a designer too.

Jen: Yeah. Yeah, and that's always been a little bit true, you know, because there you are, the front-end developer, with a PDF, and there's no hover color, and you pick the hover color because you can't send one more email asking people reminding them to send you hover color. Right? That's always been a little bit true where the front-end developer is finishing the design. But, I think that with this kind of layout, it's even more true.

We either are comfortable with that and you hire front-end developers who are really good designers and they finish the layouts, or you get the designer involved so that the front-end developer and the designer are collaborating. Maybe that means you push the front-end development all the way into the first meetings, which a lot of people have talked about over the last eight years where you get the developer in the room early. Maybe it means the designers use Figma and Sketch less, and they use prototyping and CSS more. Maybe that means designers go and learn CSS.

There's a whole range of different choices to be made, and I don't want to say that one is right and the others are wrong because I don't believe that. But, I think what's true is that it doesn't matter what tools you use, and it doesn't matter what names you give to people. The reality is that design happens by a whole bunch of thinking, a whole bunch of sketching, and then a whole bunch of writing stuff with CSS. I would love to see that process of making stuff in CSS be acknowledged as finishing the design because it is. You can't finish; you can't finish the design if you're not actually working in CSS.

Chris: Can that be -- that should be just as good as a phrase as intrinsic design, to me, is finishing the design, but that's what front-end -- there's certain front-end developers who can do that and certain that are very much just like, "Give me the instructions. I will interpret this to the letter," and not use any particular creativity to get it done.

Jen: What's interesting to me is that this is how it used to be back in the days of paste-up with graphic design, before desktop publishing. I worked in a little printshop, and people would come in with their job. Like, here I am. I'm ordering business cards, or I need some letterhead, or I have a brochure.

Here's an event. I have this event coming up. We're going to make a brochure about the event. Here's all the copy, and they would give us typewritten pages. We would retype everything into our phototypesetting machine and typeset the text for them.

They would give us photos, like physical, actual black and white, only black and white photographs on photographic paper, 8x10 usually, and then we would decide where those photos were going to go. We would decide how big the photos were going to end up being. They would usually be, of course in a brochure, much smaller than that big, original 8x10, right?

Maybe they would have a design. They'd bring this piece of paper where they had taken a pen or ink pen and drawn what they want the brochure. "Take the photo and put it here, and then put this title here, and then draw. We want a thin rule line, and then I want this text here." But, they were not design -- you know, they were designing the brochure, but we were the ones actually implementing it.

Chris: Mm-hmm.

Jen: They would come back a week or two later, and we would show them a blue line, which was like we had basically built the whole thing out, and then we would give them a final version that they could approve. If they didn't approve it, they would have to pay us to redo the whole design again. They could reject it if they wanted to, but we were really the ones, and we were not seen as designers. We were seen as, like, a very blue collar industry. I worked in the print shop. There was Bob the printer in the back actually printing things, and I was burning plates. It was a physical production thing. We were producing things.

Now, that job is blurred because, if you designed a brochure, you design it in InDesign, and it looks very much like what you expect when it comes out the other end. You can decide how big you want the text to be or how big you want the image to be, but it does feel a little bit like the Web is sort of mimicking what used to happen in paste-up where, okay, you can drop off that PDF for me and what you think the website is going to look like when it's done, but the distance between what that PDF is doing and what the actual website is going to do is so far that there's a lot of design work that still needs to be done, and so the folks who are maybe not given the job title "Designer" and the ones who are actually finishing that design.

Anyway, it's changing. It's always changing. It feels like it's about to change again, if in fact we take advantage of what we can do with grids.

Chris: It's funny how unsolved it all feels.

Jen: Yeah.

Chris: It's like, gosh, with all these smart people, can't you just figure this out?

Jen: We were just talking about columns. But, actually, everything we just said about columns also works in the row direction. We can define a row with a percent. We can define a row with min/max. We can define a row as auto. We can define a row as a 1FR unit or any FR unit.

Dave: I feel like that's the next frontier. Well, I mean, the next dimension because, just for so long, it's just been like, "Oh, don't mess with verticality because it's just never going to work out."

Jen: Yeah.

Dave: But, no, ho-ho-ho, we can mess with the verticality.

[Laughter]

Jen: Yeah.

Dave: It kind of works out. You're going to need FRs and content to spill out, but wow. We've never controlled it, and so now we can kind of program it. That's very nice.

Jen: Yeah. Yeah, in the past, I guess, really, we didn't have rows, but it would almost be the equivalent of using Grid today, CSS Grid or the other technologies we have and always setting your rows to be auto height. Every row is auto height. It's like, well, but what if you had three rows and they were all 1FR unit? Then that means, at least in the writing mode, in the horizontal writing mode that English is in and much of the Web is in, by definition the FR units are going to be. There's no known size to the height of the container, and so they're not going to distribute extra space in the height of the container, but they're going to look at the content that's in them. They're going to see which one is the tallest, and they're going to make--

Chris: Make the other ones the same as tall?

Jen: Yeah.

Chris: That's awesome.

Jen: If you set them in FR units, yeah.

Chris: Wow! I never really thought of that. I always think of mostly the usefulness is, like, I can set something in another column that might start when something in another column ended. It's kind of useful to have those row lines in place.

Jen: Right.

Chris: But, it's interesting that you can force a height.

Jen: If you do put a height on the containing block, you could say min height 100 VH.

Chris: Yeah.

Jen: Which would say, okay, if there is more content, make this taller. But, if there's less content then fits in the window, then I at least want this grid container to be the size of 100 viewport height units. Then what that will do is it gives you all this sort of white space. You could have rows that are empty and, yet, take up space because there's white space. There could be a percent.

Chris: Because it's min-height, there's no danger.

Jen: Right.

Chris: If you did overflow content, it will just push taller and that's fine.

Jen: Right. We haven't done that either. We've had vertical media queries, but we haven't been able to define space in the vertical direction in the way that you can with Grid.

Chris: It always just felt so dangerous, and it's nice that now we have these options that add possibility without introducing danger.

Jen: Yes. It's very robust. It's totally like that on purpose. Grid came out. Grid was invented. After we understood the problem space, we understood that screens were way different sizes and you can't control the size of the screen. We understood that we're usually programming templates, and you don't know how big or how long the content is.

We understood that, fonts, you don't really know whether people are seeing things in the font that you originally intended or if it's the size that you originally specified. You can't control that, so everything has to be able to grow to hold that amount of content, which is why things like min content and max content and intrinsic and extrinsic sizing become incredibly important. Even though all of those concepts predate grid, they predate Flexbox, they go back to CSS 2 and they're old concepts, but they're things that we never had to really worry about because we couldn't do anything about them anyway.

Now, we can, and now those concepts are actually really useful to understand, understanding overflow, what happens, what your options are to control overflow so that you get what you want, and you don't end up with the word "awesome" sticking out of a box on a mug that you didn't want. It's not that it's just going to magically work perfect all the time. It's more like, oh, now I have four or five options, and I am responsible, as the front-end developer, to make sure that the options that I chose are going to do really well all the time.

Dave: We may need to wrap up for time.

Jen: Yeah. Yeah. [Laughter]

Dave: [Laughter] A ShopTalk listener, they're redoing their homepage on their site, what would be your do this, try this first? What would be that thing to blow out their layout and make it just not the same old boring?

Jen: Yeah, so I think, of course, there's always a balance between finding time to play and learn and shipping things for work that are due next week. Of course, if you have deadlines, you have to make your deadlines. Of course, none of us can find a time machine and inject extra time into the universe. Of course, things are limited. You can only do so much.

But, how do we find ways to grow, play, and learn while shipping for deadlines? Like you said, you're working on your personal home site page. Your own personal website is the perfect chance to mess around because you don't necessarily have a deadline like you do for work.

I am encouraging people to play like crazy, so CodePen is a great place to do it. Just play around and see what happens. I have really enjoyed opening up graphic design books or a magazine or graphic design history books with posters from the past, or anything that's just not Web design stuff. It could be cinema. It could be ideas from cinematography or other media.

Just go, "What would it take for me to translate this poster from 1945 into an intrinsic Web design webpage?" I learn so much by doing that because it seems like, oh, that's going to be easy. I'll just make four columns and three rows. Then I'm like, oh, but should I use FR units? I'm like, well, maybe I should use min/max. Then I'm just like, oh, I don't even know what that is anymore. I have to go look that up. Then there you are looking something up, playing, and learning.

I also have been making all these videos on the YouTube channel layout-land where I walk people through demos or I show people a new CSS property that maybe they haven't had a chance to explore. I have a three-part series that explains FR units, min/max, min content and max content, which we didn't even really talk about, where I have one video on each of those, and I show people exactly what they do. I'll be making many, many, many more videos.

Also, my conference talks from the last three years are going to be out. I think the one from 2017 is coming out today, actually. Check those out. They are packed with ideas of things to play with and try out.

Also, all the experiments that I've done over the last five years are up at labs.jensimmons.com. People can go there. I've tried to put a lot of links to CodePen demos there too. I should go back in and fill in the ones that are missing.

But, of course, you can always use an inspector like, oh, the Firefox Grid Inspector, and dig in just on the page itself and look at how I built things, edit them, and fork them. Try them out yourself.

Dave: Awesome. I think that's good. I definitely recommend the Layout Land and subscribe, so thanks, Jen, so much for coming on. Hopefully, people kind of, yeah, get the bug to create more interesting layouts.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, and favor it up. That's how people find out about the show. Follow us on Twitter at @ShopTalkShow for tons of tweets a month.

And, if you hate your job, head over to ShopTalkShow.com/jobs. Get a brand new one because people want to hire people like you.

Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.