Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave--sitting down but I'm about to raise my standing desk--Rupert and with me is Chris--in the booth--Coyier. Hey, Chris. How are you?

Chris Coyier: Hey!

Dave: Pardon this.

Chris: I am in the booth. Dave, you deserve it. Let's hear it.

Dave: [Mechanical noise]

Chris: Oh, you're faking that sound.

Dave: Yeah.

Chris: What does it actually sound like? Get it down there. Totally silent. You've got grease in those bearings.

Dave: Oh, yeah. It's Ikea, so you know it's the only quality around here. [Laughter]

Chris: Oh, that's great. We have a guest on the show who has been on many times before. Episode 161, we had Eric Meyer on. Hey, Eric.

Eric Meyer: Hello!

Chris: Hey. We had you on again during our series "How to Think Like a Front-end Developer," which was very useful to me, by the way. I ended up quoting you many times in the talk that I prepared from these podcasts, which I considered research at the time - little did you know. [Laughter]

Thanks for coming on again. Eric is notably the author of a bunch of stuff: CSS: The Definitive Guide a couple of years ago and Design for Real Life a couple of years before that. Really, loads of books. His website, meyerweb.com/eric/books will get you to the books. Just go to the homepage of the site.

Eric is a long-time blogger. In fact, I read a post you recently wrote about blogging. How meta.

Eric: Yeah, the blog about blogging.

Chris: Yeah, 20 years. You have one of those--I don't know--back-end functions that convert a timestamp into how long ago it's been. One of them now says 20 years ago. Wow!

Eric: Yep, and I discovered that I had miscoded it back in the day when I wrote it. It doesn't account for leap years, which, at the time that I wrote it, I was like, "Meh, whatever." I probably didn't even think of it, but I didn't notice it. But now the blog has been around long enough that a post that was exactly 20 years ago today, it would actually say something like 20 years and 5 days ago because--

Chris: Gosh. I wouldn't even dream of writing my own function like that. No way.

Dave: No.

Chris: [Laughter] That's great, though. But that's what we had to do back in 1850, right?

Eric: Yeah.

Chris: [Laughter] And Eric is notably one of the founders of a very long-running and very high-quality conference, An Event Apart, which is about to kick off for 2020, so we're doing this show in, I guess, anticipation of the 2020 run of An Event Apart. Yeah?

Eric: Yep. Yep, yep. Let's see. As we record this, we've got, I think, a couple of months until the first show.

Chris: Yeah, Washington kicks it off, then Seattle, I think.

Eric: Yep.

Chris: Dave, you're going to be in Seattle, right?

Dave: I'm in Seattle. I'll be in Seattle. Come join me in Seattle. I'm looking forward to it.

What I like about An Event Apart, because you all do multiple a year and I like that you call it a tour. I really do. It's very, like -- I think a couple of other conferences kind of do that too. I love that attitude of, like, "We're packing up the trucks, all the sound equipment, and the projectors and we're going to do a tour." I like it.

It has headliners and then people like me who get up there and talk. It's great. [Laughter] It's very charitable.

Eric: Dave, we're all headliners.

Dave: Okay. Okay.

Eric: You may have noticed in the agenda; there's no keynote. Some talks might feel more keynote-y than others, but it's not one of those things where these people are keynoting and then we have these other people. That's not how it's structured. Every talk should be keynote-worthy.

Dave: Did you all change the format this year? I feel like I heard rumors you were going to do the bigger events with three days of speakers.

Eric: Yep.

Dave: Is that what's going on this year?

Eric: They are all three days now.

Dave: Oh, my gosh. That's a lot of content. That's great.

Eric: Yeah, it is. [Laughter]

[Laughter]

Eric: Yeah, not every lineup is the same.

Chris: It's not two days in a workshop. It's three days, period, of all talks.

Eric: Yeah. Right.

Chris: Yeah.

Eric: Right. Yeah, and not every lineup is the same, so different cities, different mixes of people. There are some people like me and Jeffrey who speak at every one of them.

Chris: Mm-hmm.

Eric: Yeah, we did have one year--it's been many years ago now--where we literally just had the same lineup the whole year. Actually, we called it the Monsters of Rock tour.

[Laughter]

Eric: It sort of felt like--like you were saying, Dave--it was, you know, pack up all the vans and the stage rigging and go onto the next city. We find that it's better if we mix it up from show to show.

Dave: Well, and you don't have to hire managers to manage talent in disagreements and all those things that happen on the road.

Eric: Bulls with brown M&Ms. Bulls without brown M&Ms, excuse me.

Dave: [Laughter] My wife was in a band and she did tours. Her label wanted her to tour 200 days a year and I think she found out that she was just like, "That's not what I want to do. I don't like sitting in a van for 200 days a year."

Eric: Right.

Dave: The conference seems a little bit different. You go to a nice hotel in a nice city, so there you go.

Eric: You only have to tour like six days a year.

Dave: There you go.

Eric: Or something like that.

Chris: That sounds like an 82% chance they're going to have a cheese quesadilla on the in-room menu.

[Laughter]

Dave: Available 24 hours a day.

[Laughter]

Chris: You're dang right. Yeah, that's on the late-late menu.

Well, we'll circle back to An Event Apart. There's a lot to talk about there with so many -- we've mentioned this before, but AEA has broken a lot of ground in big industry-defining things happening on stage. It'll be fun to guess at, perhaps, some of those things or, if not that, at least what are the themes that are happening there. Let's percolate on that for a little bit, but we'll take a break and talk about--I don't know--general stuff that's happening kind of in the world of front-end technology, to some degree.

In fact, I asked you the last time you were on the show about the term "front-end developer." You know? It was like, now that's locked in stuff, but it kind of always has been a term, at least to some degree. Maybe it was a weird way to put it 20 years ago, but at least it kind of made sense even then. Now the ship has sailed.

Anyway, what's happening in it that is relevant to talk about? I know one thing I think about in association with you is that Subgrid shipped, right? There's the curveball I'm going to throw. Yeah, at least in Firefox. I believe only in Firefox. Nobody else has -- yeah, so far. I don't follow so closely of internal discussions of other browsers and how close and/or excited they are about it, although I see a lot of that. When a new feature gets mentioned, it's often mentioned in conjunction with what the other browsers' excitement level is about it. They'll say, "No word from Safari."

Eric: Right. [Laughter]

Chris: Yeah, something like that. Anyway, it's kind of here and I've read some interesting tutorials in which that it can be used in a progressive enhancement kind of way that you don't have to -- if you have Subgrid available, you can just use it and won't necessarily have to mean that you can't use Grid at all if you don't, if you're not using it, which kind of blew my mind a little bit. Anyway, do you have any--?

You even -- your blogpost notably called it "essential," it was so important to you. Are you kind of clapping a little bit now that we at least have one implementation?

Eric: Yeah, actually. The interesting thing about having Subgrid in one browser engine and not in, well, Chrome, which is a dominant browser engine at this point in time, means that you can only use it in a progressively enhanced sort of ways. It's difficult to have a design that depends on Subgrid for things to line up.

I'm actually using it, speaking of An Event Apart. We have a schedule comparator, we call it. It's a way to compare schedules so that you can see which talks are the same in these two cities and which talks are unique to these two cities.

It's basically two lists, I think, or ordered lists, but whatever. It's two lists with the speakers, the session titles, and that sort of thing. Then I use Grid to put them next to each other, right? The way that we would have floated the two lists in the past.

Then I'm using Subgrid to make the sessions line up vertically so that if the third session in the left-hand event is taller than the third session on the right hand, they'll match heights. That's what Subgrid will let you do.

Chris: Mm-hmm.

Eric: But if you don't have Subgrid in Chrome, then they just don't line up. It's not a huge deal in this situation. It looks nicer. It looks cleaner in Firefox but it's not like stuff is all over the screen and the association between them is broken. Whereas, if I were doing a catalog page with a bunch of product listings and I wanted all of the prices and the descriptions and the images to all line up so that all of the cards were the same height and everything had this very precise vertical rhythm, I could use it in a progressively enhanced way. But then with everything being different heights, the CTO or the CEO or whatever might say, "This looks like crap! Do it again." Right?

Chris: Yeah. Okay.

Eric: That's where you have to be careful. I would do it in that situation and then have the CEO yell at me just because that's the kind of developer I am. Yeah, so I've actually worked on a couple of layouts recently where I wanted to use Subgrid to have a full bleed background that goes all the way out to the edges of the browser window but the content is confined to a content column.

Dave: Yeah.

Chris: I'm fascinated by this.

Eric: Subgrid would make it trivial, right?

Chris: Okay.

Eric: I could just say, this outer div is 100% wide and the inner article or whatever is associated with the body's parent grid via Subgrid. I couldn't do that. I had to replicate the body grid inside the div. I had to take the same grid definition and apply it to that div or section or whatever it was. These are the ways to get around it, but then that means if I ever want to change the width of that content column, I have six places I have to fix it where, with Subgrid, I would just change it on the body and everything else would just follow.

Chris: Oh, yeah, yeah, yeah.

Eric: Right? I couldn't use Subgrid in production in that situation because, in Chrome, suddenly the content would be 100% wide, filling out the entire browser window, even if the browser window is 4,000 pixels across. Right? That was where I couldn't really use it in a progressively enhanced way. It had to hack my way around the implementation.

Chris: Yeah, despite your brain wanting to do it that way.

Eric: Yeah. I actually prototyped with it. But then at a certain point in the prototyping phase, I was like, okay, we're getting ready for production. I have to replace all these Subgrid calls with these repetitive grid definitions. Then, of course, after that was done, someone decided, the designer decided, "Let's tweak the width of this column a little bit." I was like, "Ugh! I knew he was going to do that."

[Laughter]

Eric: Damn it! But that's how it goes.

Dave: You had that Subgrid in your back pocket. Let's say this year Subgrid rolls out or something.

Eric: Yeah, so in Chrome, from what I hear, and I'm not in any way part of the Chrome team, so I'm only hearing the things that are public and sort of swirling around, is that the Chrome people have been rewriting their layout engine. I think it's called Layout NG, which I take to mean Layout Next Generation.

Chris: I don't know anything about this. What? Chrome is getting weird about--?

Eric: Yeah, and I guess they're doing it in--

Chris: I mean, serious?

Eric: They're doing it in pieces as well, apparently. Again, remember, I'm from the outside.

Chris: Yeah.

Eric: If you're on the Chrome team, listening to this, and gnashing your teeth and tearing out your hair, sorry but this is what the rumors are.

They haven't -- from what I hear, they haven't migrated Grid to this Layout NG, which means they're not doing any work on Grid, apparently, except maybe for critical bug fixes if they're found, and so they're not doing Subgrid until Grid is ported to this new layout paradigm.

Chris: Hmm. The classic thing in development, right? Like, "Oh, we want that, but we have some infrastructural shenanigans to get done first."

Eric: Yeah, so they have these infrastructural shenanigans. Of course, I've been hearing this for quite a while now, so I have to wonder what's taking so long. There's a part of me that's paranoid that the people who work on the Chrome layout engine don't really care that much about the Web or Chrome or layout, and so it's not top priority.

Chris: You never know.

Eric: Right.

Chris: The internal story is always like, "Actually, they left. They got poached."

Eric: Right.

Chris: You know?

Eric: Yeah, or it could easily be, it's not that they don't care. It's that they've been told they have other things to work on first.

Chris: Mm-hmm.

Eric: It's API whatever thing that they have to work on, maybe. Like I say, I don't know. I'm only on the outside looking in and hearing rumors swirling around.

Dave: Yeah. Different companies can manage projects in different ways, but there's the big Fugu initiative, which is like bringing native APIs like a contact picker or something like that to the Web, which would be very cool. In theory, you could get a texting app based on your contact book or something--I don't know--with Twilio as a back-end or something. That would be pretty cool.

Fugu has this big list of like 104 different APIs they want to write, which you've got to think, like, "Wow, that's a huge backlog, a huge undertaking. When does the other stuff happen?"

I'd be kind of curious to get your pulse on where things like HTML and CSS are going in light of all these kind of big, "make the Web like native" initiatives going on.

Eric: Um… Yeah, I mean where they're going. HTML and CSS, I don't feel like there's a lot that comes out of that. All that native API stuff, a lot of DOM and JavaScript work happening, which there's at least one Web-based thing that I've written for myself that I would love to access the gyroscope in my phone so that I can get, like, its current angle or whatever. Maybe that's available now. I haven't looked recently.

You know, being able to check the battery status or whatever could be very useful, but it does make it feel like HTML and CSS are getting not as much attention. Things like, "We shipped Grid," and now not that much is shipping in HTML and CSS from Chrome. It does make it feel like it's been put on the backburner.

This happens. There was a whole period where HTML and CSS were on every browser's backburner. Then for a while, they weren't and a whole lot of stuff came out: Flexbox, Grid, a lot of other things in that same point, variables, custom properties if you want the official term, all that stuff that came out over--gees, at this point I guess it's been--the last decade. Whereas, the decade before that was kind of stagnant. [Laughter]

Dave: Yeah. Yeah, for sure. Even last night, I rolled out some type changes on my website, just a few little nudges, but it took a whole evening. I was surprised Chrome doesn't have text underlying offset and text-decoration thickness and all those kind of new, play with borders or play with text underline sort of tools, toys. Chrome doesn't have those. It has, you can set text-decoration color but none of the other fun stuff works.

I was really surprised by that because I always tend to think of Chrome as the bleeding-edge on CSS or whatever, but now I open Firefox when I'm messing with variable fonts. I opened it for variable fonts. I opened it for text-decoration stuff. I opened it for--oh, shoot--something else. Even just the grid inspector and stuff like that, I'm relying on Firefox for all my bleeding-edge CSS stuff I'm toying with, or Subgrid even.

[Banjo music starts]

Chris: Hey, this episode is sponsored by WordPress.com. You know WordPress.com. They're the hosted variety of WordPress. You can just go to WordPress.com and spin up a site.

Now, the two highest plans are business and e-commerce. They have some additional features. They're not that expensive. The business plan starts at $25 a month. E-commerce is $45. It has a new feature, both of these plans, which power users are going to enjoy.

One of the reasons that you might not pick WordPress.com, at least in my mind in the past was, well, what if I want to hack on my theme or install plugins and stuff? Now, you've been able to install plugins for a little while. I know that's also somewhat of a secret feature, to me, I guess, on WordPress.com. You can do that.

Now, you just straight up have SFTP access and straight-up database access. They'll just give you SFTP credentials. You can use your SFTP client--I just did it this morning--to log into your WordPress.com site and you have access to the Webroot there. You can install a new theme that you bought somewhere else or that you created yourself - whatever. Throw it right in the themes folder and activate it like you would on any other WordPress site. The same thing with plugins. You just have access.

One of the use cases for this is to kind of mass upload a bunch of image assets if you need to work that way because you're moving a site or something like that. It's all available to you. You can use it just to tinker or you can use it hardcore like have your own local development environment for your WordPress site and deploy to WordPress.com.

Pretty powerful stuff there. Pretty cool feature. Brand new this December, so check it out.

[Banjo music stops]

Chris: It's funny how different developers care about different things and how they have to -- you know, it's easy for us to be like, "HTML needs to evolve faster," which I couldn't agree with more, for the record. It seems so exciting. I feel like, when an HTML thing changes, it affects everybody. It's just kind of a big deal.

I think in news this week is Chrome 80 went stable. You look at a blogpost that's like, "What's new in Chrome 80?" You go up the list and, as somebody who are total browser people, like I think all of us are, I go up in this checklist and I'm like, "I don't know. Maybe 10%, I feel like I care about," which is just weird.

It's like, "Now there's a change to Web workers and the fact that they can use ES 6 modules now." That seems good, like, "High five. Cool."

There's a new API for, like, the contact picker, so you can pop up some native UI that could pull, "Eric Meyer, Cleveland, Ohio," and grab it. It would fill some -- that seems like a good idea, but I don't know much about it. I'm not building an app that could super use that.

It looks like it auto-upgrades non-secure content to HTTPS by trying to rewrite the URL. That's kind of awesome. Good. Obviously, there's nothing in here that's like, "Detailed summary element now more accessible," or something. Those type of releases are few and far between.

Eric: Yeah, the work that's happened in Firefox recently, and by recently I mean in the last year to two years, on the front-end and front-end tools, there's been some stellar stuff and it's interesting. For example, the underlying thickness and underlying offset or, sorry, text-decoration. No, it's underlying offset.

Chris: We can change the color and distance and stuff with it.

Eric: Decoration thickness.

Chris: Yeah, I use the crap out of that.

Dave: Underlying offset, decoration thickness.

Eric: Right.

Dave: And decoration color. Yeah.

Eric: Right, but it's actually underlying offset because you can't offset, for example, a strikethrough decoration.

Chris: Yeah.

Eric: (Indiscernible)

Dave: Oh, interesting.

Chris: That's right.

Eric: Yeah, anyway, so the underlying offset and the decoration thickness apparently were done by one of Mozilla's interns.

Dave: Oh, really?

Eric: An intern just worked on it, just did it.

Chris: That's nice.

Eric: And did the text-decoration skip ink--

Chris: Yeah?

Dave: mm-hmm.

Eric: Whatever it is that affects how it skips to senders and things like that. Yeah, it was done by an intern. Basically, they said, "Do this," and the intern did it.

I haven't heard things like that coming out of Chrome. Like you say, yeah, they did text-decoration color and that's, okay, cool. But the thickness and the offset are not supported by Chrome. There's--I don't know--maybe it'll ship in the next version or maybe they haven't worked on it. Subgrid feels the same.

Chrome's dev tools, so far as I can tell from a front-end sort of designer perspective, haven't really changed. Not that they're bad. They just haven't changed res. I think, Chris, you were saying the Firefox -- Dave, you were saying the Firefox Grid Inspector is there and now it supports Subgrid. It'll show you Subgrid stuff. Just recently, I had a situation where I couldn't figure out why the styles on my links were being ignored, partially ignored by Firefox because I was using HSLA on visited links.

Chris: Oh.

Dave: Hmm.

Eric: It wasn't doing the opacity and I couldn't figure it out, and so I moved the Opacity to the Opacity property and that's when Firefox told me. It gave me a little popup. It gave me a little--

Chris: Yeah. This is a security concern.

Eric: Sorry. Let me back it up. Right, basically, opacity, 0.1 or whatever was grayed out and there's a little eye. I hovered over the eye and it gave me a popup that said, "Opacity can't be changed on visited links because of security restrictions." Basically, privacy concerns.

I was like, "Oh, my god. Yes! How did I forget that?" Well, I did forget it. Firefox did not. Firefox was perfectly happy to remind me, and so I was able to adjust from there.

Chris: That's huge … stuff.

Eric: Things like that -- yeah.

Chris: Huge fan.

Eric: It really is. You know sometimes I'll get the, "Why isn't this aligning properly? Why is this not vertically centering?" Because CSS, now vertical centering is trivial. [Laughter] All the jokes about how you can't vertically center in CSS just don't make sense to me anymore, really.

Chris: It's been old for a long time.

Eric: That's all I remember but, anyway, I'll go into the inspector and it'll be like align item center is grayed out. There's a little thing that says, "This isn't being applied because this is not a flex item."

Dave: Yeah.

Eric: Oh, right. I did have to do that, didn't I? Oops. Right? All that stuff is so good. Now, the people I know who do tons of JavaScript still swear by Chrome for JavaScript debugging, that whole environment.

Dave: Mm-hmm.

Eric: I don't do heavy-duty JavaScript and I don't do heavy-duty stack tracing and debugging or whatever the breakpoints watch expressions, but I have done a little bit in Firefox. It didn't seem bad to me, but that's been sort of the distinction I've seen is that people who do tons of JavaScript, still Firefox doesn't feel right to them whereas people who do lots of design layout, that sort of thing, a lot of them are moving to Firefox and really enjoying it.

Dave: This seems very relevant to the conversation now. Eric, I know you've lived through and/or participated in some browser wars in your past. [Laughter] You fought on the frontlines of the great browser wars of IE 6. I wonder if what we're talking about is just a perfect example of why browser diversity matters.

I think we all can agree, oh, it'd be nice to have less rendering engines to care about, but then now we're talking kind of like cultures. Mozilla is just like, "Oh, we're just going to make dev tools really great for CSS. We're just going to do it," and that's kind of cool. That's really helpful, actually. I don't know. I'd love to hear your thoughts.

Eric: I guess I don't agree that it would be nice to have fewer rendering engines to worry about because, the thing is, imagine if we had one rendering engine and it was Chrome. We'll just pick the one that clearly has the most market share at this point in time.

Text-decoration thickness, text underlying offset, those just wouldn't exist at all. There would be no example for us to look at and say, "Oh, this would be cool if it were in more browsers."

Dave: Mm-hmm.

Eric: I was sad when Microsoft Edge moved from their own rendering engine to Chromium. I understand that it made sense to them and I'm not here to tell them they made the wrong decision because I don't know their constraints, I don't know their goals, that sort of thing.

It's always easy to say, "Oh, this design is crap. I could have done it better." Right, but you never know what the internal pressures are. This is a similar kind of thing. I'm not here to say that they were wrong, but it still makes me sad.

Dave: Mm-hmm.

Eric: Because I think that a minimum of three engines is very helpful to the diversity and the health of the Web. Having two engines, which is effectively what we have now, we have Chromium and we have Gecko or whatever. In order for any standards feature to advance, it has to be interoperable in two engines. Well, we only have two.

Dave: Yeah.

Eric: When we had three or four, there could be two engines that supported a thing and maybe the other one or two didn't, but that could still move forward in the standards track. Let's pretend that Edge stayed Edge and didn't move to Chromium. If Edge and Firefox did text-decoration offset or text-decoration thickness, whatever, that could become part of a full standard.

Now you have to get, effectively, everyone to agree to it. Some people would say, "Well, that's good because then we don't have any incompatibilities, but to those of us who are all in on progressive enhancement, that's actually not as good, in my opinion. It does make me a little sad. I would like to see more engines.

Writing a browser engine these days is not like it used to be. I'm fully aware. That's a huge undertaking. But I still wish it were there. I still wish that were a thing.

Dave: Yeah. You know I'm thinking we have WebKit, but that's very, very akin to Blink in some ways.

Eric: Right.

Dave: But kind of taking a broader perspective, we're kind of stuck with a duopoly, you know, Republicans/Democrats, Coke/Pepsi. You only get two choices.

[Laughter]

Dave: And good luck with yourself. There's no Dr. Pepper right now. [Laughter] Dr. Pepper doesn't exist in the current ecosystem, and so I think there is -- on mobile, it's either WebKit or Chromium, and that's sort of your choices. On desktop, yeah, it's mostly Blink and Gecko but, yeah, after that it's pretty slim pickings. You know maybe Safari has 1% or 2% desktop share.

Eric: Mm-hmm.

Dave: Yeah. Yeah.

Eric: Yeah, and mobile is even worse because, in a lot of cases -- well, on the Apple, on iOS devices, everything is mobile Safari, mobile WebKit, whatever you want to call it. There are no other engines.

Dave: Yeah, that's a weird monopoly inside of a platform. Yeah.

Eric: Yeah, which I dislike on principle, but that is how it is.

Dave: Have you considered growing a big mustache and riding a horse around like Teddy Roosevelt, the union buster style or monopoly buster? [Laughter] Is that what it was?

Eric: Oh, if only I could.

Dave: Okay.

Chris: Have we made ourselves sad. [Laughter]

Dave: Well, it gets -- there are cool features. I mean I think that's the problem. There are cool features, but I don't see -- I don't know the velocity of when they're going to show up or when do I get this and when do my text-decorations go everywhere?

Eric: I mean the nice thing, of course, is that you have progressive enhancement. I just deployed a design yesterday for parts of An Event Apart where the designer, Mike Pick, said, "Oh, yeah. Let's do some stuff with the text-decoration where, when you hover over links, the decoration animates to be thicker," right? It doesn't just pop thicker. It really smoothly animates from one pixel to three pixels or whatever.

Dave: Mm-hmm.

Eric: Which Chrome doesn't do, but one day it could. Right? I don't have to change anything to make that happen. It just starts working, hopefully, at some point.

The same thing with the Subgrid on that schedule comparison tool is that if Chrome ships Subgrid in Chrome 85, let's say, suddenly, all that stuff just starts lining up, which is really nice. Admittedly, it can be a little frustrating there at times when I'm like, "Ugh, I can't use this because it would cause a much worse user experience for some people, even though I really want to." But that's the medium we work in. It's a fluid medium, always - always. Fluid and fluid along multiple dimensions, right? It's fluid in that there are multiple rendering engines. It's fluid in that the browser window can be a different size on desktop just because that's the size that the window was dragged to. It can be a different viewport because there are eleven million Androids, each of which has a slightly different pixel size for the screen. Like that, right?

Dave: Mm-hmm.

Eric: There's no such thing. We used to say, "There is no fold." There is no resolution. Once upon a time, you could pretty much assume that all of the sites, all of the monitors that were going to view your website were 640x480. That was as high as monitors got, typically. But we're way past that now.

Dave: Yeah.

Eric: You know. You know that's why progressive enhancement feels, in a way, natural to me because it's also fluid, right? But it's fluid across time. It's the, this will work in a certain way in this given browser. It won't have everything. But if that browser develops further then, in the future, these things will then just become available to users of that browser.

[Banjo music starts]

Chris: This episode of ShopTalk Show was brought to you in part by Netlify. Maybe you already know Netlify because it kicks butt. That might be a reason you know Netlify.

I don't know. I guess the default way I think of Netlify is, I have a site--whatever--some kind of website, a simple site that maybe I use a static site generator on. Maybe I don't. Maybe it's just flat files. Maybe I'm building it with a headless CMS or I'm building it in some kind of JAMstack style or some kind of front-end JavaScript-focused style. There are lots of different sites you can build.

I have a repo for it on GitHub or GitLab or any other Git repo place. I need it to be deployed. I need to send it up to the Internet, a production-worthy site. A super-fast, CDN-backed, beautiful deployment system, that's what I need. I don't want to write my own deployment and I don't want to use third-party tools for deployment. I want my host and my deployment to be together.

Maybe you don't even think in that way because you didn't even know it was possible. That's Netlify. I've got this repo. I want to deploy it. You know how I deploy it? I push to master. That's all I need to do and your site it up. It's great. I use it for everything I possibly can because I just love Netlify.

It's also so affordable, which is great. A lot of times you're just below the free tier and you can just use Netlify for free. There are just a few things they charge for.

Here's a brand new thing on Netlify that they just announced at JAMstack London is Netlify Analytics. That's one of the things that costs a few bucks. You want to turn on analytics for your site, it's $9 a month, which is trivial for the good information that you get for it. It's amazing because, first of all, if you didn't have any analytics on your site before, you turn on analytics and you'll have your historical analytics too because it's based on server logs. They have the server logs anyway and they can kind of parse them and get the data together for your Netlify site, so it's incredible. The day that you turn it on, you have tons of data about the usage of your site.

Server logs is the best possible way to do analytics. You don't even have to care how it works. The point is, it's not slowing down your site for any reason because there's no client-side JavaScript at all that's tracking anything. It's all handled after the fact and analyzed after the fact. Nothing can block it, which is kind of nice.

I bet--I don't know--maybe every single person listening to this runs an adblocker of some kind and a lot of them have flipped on blocking Google stuff like Google Analytics, like just don't let it run at all. Google Analytics is the big player on the block and now that data is totally missing from that analytics. That's a big deal. People that just turn JavaScript off for any reason aren't tracked in that way. This data will be way more accurate. This is the most accurate analytics you can possibly have for a site because of how they've done it.

Anyway, it's great. It just feels really Netlify-y. You get good data from it for any reason you'd want to use analytics. Just check it out, Netlify Analytics. Good job, team. Love it.

[Banjo music stops]

Chris: You ever get feedback or have discussions about the giant screen size thing of today? It's not as common but, certainly, a lot of people have really super large monitors, myself included.

Eric: Yeah.

Chris: This is anecdotally and, personally, I don't almost ever have a browser window open that covers the whole entire thing. The screen is just too big for that. Websites, generally, aren't built to take advantage of that space. At some point, most designs just kind of give up and have a bunch of white space on the left and the right or the right or the left or something. I wonder what expectations are. Are user expectations that stuff is generally kind of centered in that area or are they like, "No, just hug the left"? If you make the wrong choice, are you going to hear about it? [Laughter]

Eric: Yeah, well, most designs that I've seen, practically every design I can think of that constrains the content to a certain width centers it. I can't think of one that hugs one side or the other. My guess is that if there was a site that did that they probably would care about it.

Chris: I think I did it on accident once or kind of like, "Why does this even matter?" or maybe like the header takes advantage of the space but the content doesn't, so it felt nice to line up the content to the logo. But it's like, no, no, people did not--

Eric: Yeah, what I am seeing a bit more is the full bleed thing we talked about earlier where there's a section in the middle of the page that has a black background instead of a white background, right? The black is supposed to spread all the way out to the edges of the browser window even though that center column stops it 75 characters or whatever line length was set as a maximum, which Grid makes super easy with things like min-max and that kind of thing.

Chris: This one has been in my head since we talked about Subgrid and the stretchy thing. Let's say whether you used it on the body or not, but you have some element that is an edge-to-edge browser and you're using display grid on it. Perhaps the reason you're using display grid on it is because you want to have kind of an easier opportunity to let certain elements go edge-to-edge browser window, but not all of it because line length, like you just mentioned, is a huge consideration. Your website is pretty much unreadable if you add a really long line length. Your eyes just cross. It's like, "No."

Okay, and a lot of times you just let the container deal with that, not necessarily P max with 500, although I'm not opposed to that sometimes. Sometimes I like to just grab the element and do it. What you want to do is, let's say it's an article tag. It's display grid and you did three columns, which is essentially like padding on the left, padding on the right, and then actually where you want to put the content in the middle. You were kind of saying Subgrid can be kind of good at that because you can maybe set that up on a higher level element and then, on the lower element, just be like, "Just inherit these grid lines and put stuff in that middle column."

But until and before we have that or however you want to think about that, one of the ways to do it was to say, like, article and then direct descendant selector, like the right pointy thing in CSS, like only direct children star, so get everything and put all that stuff in that middle column. That way you have the opportunity to then override that selector on a per-element basis and say, "Oh, but not you. You, you should span all three columns or the first two or the second two or something." You have some kind of cool editorial control. I think Rachel Andrew has kind of a cool post about this on Smashing Magazine, but I feel like that was kind of emerging as a pattern.

I don't hate it, but something feels weird to me about that selector where you have to just select everything and put yourselves in that middle column. It doesn't feel as sturdy to me somehow as an actual container.

Eric: Yeah, I see where you're coming from. The thing that makes that -- well, so if you do that, if you have an article and it's got an H3 and a bunch of paragraphs and an unordered list and maybe a table of data or whatever. You say, "Okay, for this article, all of the direct children should be in this center column." Then they all become grid items, right? Which means there's no margin collapsing. Suddenly, your paragraphs are 2M apart instead of 1M because the margins aren't collapsing over each other anymore. You have to work around that.

It's like, oh, okay, so I'm going to say all of my elements have no top margin but they all have a bottom margin to keep them away from each other. I think that's where the feeling of fragility comes in is that you end up having to fiddle with all these little things that browsers usually take care of for you.

Chris: Mm-hmm.

Eric: Because all of those paragraphs became like their own individual grid items. What most people do is….

Chris: It really does have some implications, right?

Eric: Yeah, it does. Yeah. What a lot of people do, and what I've done in this situation, is inside of that article, you immediately have a div. Instead of an outer wrapper, now you have an inner wrapper. That div is the thing that you put in the center column and then everything inside of it -- then that div inside the article becomes the single grid item. Everything inside it is just normal flow.

But if you do that and you don't have Subgrid, then you can't do that thing you were talking about where you take just one element and put it on the side because it's inside that grid item and it doesn't have access to those other grid lines unless there's Subgrid. But if you have Subgrid, so you even need that wrapper div? We're still figuring this stuff out.

Chris: Yeah, that's what it feels like. These patterns aren't -- like now that we have this, this pattern is totally shaken out.

Eric: Mm-hmm.

Chris: It's like, well, maybe not.

Eric: Oh, yeah. We have no idea what the best ways to use Grid are, the best practices.

Chris: Yeah.

Eric: Best practices maybe not even the right word. The various good practices because Grid has so much power and so much flexibility in it that we don't have to think in terms of columns, necessarily. We kind of do at the moment. Subgrid would help us break out of that, but we don't even have to. Grid makes it easy for elements to just overlap each other a little bit.

Most people listening to this probably just recoiled in horror. It's like, "Oh, my god! You don't have things overlap because you have no way to predict what might get covered up." But with Grid, actually, if you work at it, you can make it so that elements overlap a little bit visually but there's no content coverup problems.

Should we be doing that? Are there situations where that makes sense? Is that a good idea? I don't know. We all think it's a bad idea because the layout tools we've had to date made it a bad idea. If you use negative margins to pull things over each other, then you were taking risks and possibly upsetting other parts of your layout. Grid does away with a lot of those considerations. Not all of them, but a lot of them.

Jen Simmons has been talking about this for a few years now. We don't know even good ways to use Grid yet let alone the best ways. We're still trying to figure that out and a lot of Grid right now is making our old fragile layout constructions more robust, which is absolutely a thing that we should be doing. But the creativity and the layout and the ways of combining things and having things relate to each other in ways that we're not used to, we haven't really figured that out yet.

Chris: I think that's 100% true. Things just take time and interesting patterns emerge. For example, this isn't as high-minded as that, but I feel like you alluded to it at one point. Correct me if I'm wrong. You, maybe on some site at some time, put display grid on the body element itself because you were like, "I don't know. The whole thing is a grid. Why not?"

Eric: Mm-hmm.

Chris: I did that once on a production site and it was totally a problem because we got support tickets from people where weird layout things were happening on the site and it turned out to be because browser extensions sometimes put stuff inside the body tag. I could write back a support ticket that's like, "You did that!" This is a paid product. You can't do that.

It just turns out, this is similar to React, right? React -- oh, god. I'm so sorry, Eric. You don't use the body element. You pick a div and then you attach it to the div just so it's a fresh element. No screwing around here. In the same kind of vein, just make a div ID page or something.

Eric: Mm-hmm.

Chris: Then put display grid on that. The natural abilities of a div is that it just fills the full width and it stretches. It behaves just like the body anyway. But because it's this internal div, browser extensions aren't targeting. It just feels safer.

Eric: Hmm.

Chris: I'd say, as a best practice, that might be one.

Eric: Mm-hmm.

Chris: You know?

Eric: Yeah.

Chris: Old-timers are like, "Eh, don't use a div if you don't have to." Well, this is a circumstance where, if you're determining a best practice, I'd say that it is one because it just prevents little weird problems, you know.

Eric: There you go. That's an excellent example of the stuff that we're figuring out. I had never considered that, so thank you for bringing that up. That's really a useful thing to consider.

Chris: In new territory, have you seen some of the--? Maybe I'm the only one fascinated by this. It's been percolating for a little bit and PPK brought it up again, which made a whole little storm around it. We're all aware of CSS 3. CSS 3 happened.

Eric: Hmm.

Chris: I'd wager it was kind of a good thing for the industry but also people that are, in a sense, trying to make money on the industry too, like people who perhaps run conferences or sell online training. It became this marketing banner that we all flew. Because it existed, it almost, in some people's mind, was like, "Okay, well, when is CSS 4?"

The messaging right after CSS 3 dropped is, "Don't hold your breath. That's not a thing. This is a one-time deal, people." Or at least it was for the most part. Still, that's a harder message to sell than the really clean, like, "CSS 3 is here! It's so cool! There's a lot to learn!"

Eric: Hmm.

Chris: It started to drum up a little bit because I think there's some thirst for how good CSS 3 was for us. Why can't we pull that lever again?

Eric: Hmm.

Chris: I'm curious if you have any thoughts about it all.

Eric: Yeah. I go back and forth because I understand why there isn't a single monolithic spec anymore. But at the same time, the working group, the CSS working group does occasionally produce what they call snapshots, which are, basically, here is the state of CSS at this moment. Let's say the end of 2019. I don't think they produced a snapshot in 2019, but just for example's sake, right? They could say these are the CSS modules that were at for recommendation status at the end of 2019. That's CSS 2019.

Chris: Yep.

Eric: Just as an example. That could happen.

Chris: We don't say CSS 2019 yet. It's not a thing yet.

Eric: Right, or you could call it CSS 4 or whatever. But it's not a thing the working group has been inclined to do and I'm not sure. I understand PPK's argument and I have some sympathy for it. But I've gone back and forth. I feel like if the working group thought there was utility that they probably would have done it. But it's easy to bury things that haven't actually been thought about under that assumption. [Laughter] Right?

You say, "Well, those are smart people. Surely, they would have done this if there were utility," and it might be that it just never occurred to them because they have so many other things they have to think about. I certainly don't think it would hurt to do that, to say at the end of 2019, "Hey, this is CSS 4. This is what's in it," right? What's in it would be the things that are widely and interoperability supported.

I don't think that would cause problems. It would mean someone would have to dedicate themselves to compiling that and being the shepherd of all of that. I'm not sure who that would be.

Chris: I don't know either. No matter what we decide, it doesn't seem like it's going to happen, probably, because there's too much hemming and hawing about it. Whereas, I think if you're going to do it, you've got to come out like guns blazing with a plan. Then everybody rallies or doesn't rally around that plan. But the fact that now there's so much Google Guice being built around the word CSS 4 that links to articles that are like, "Hmm. Should we do this?" [Laughter] Like, "Uh-oh, we wrecked it. Sorry."

I like the snapshots idea, though, because it doesn't require any rallying. They're already being done. They already exist and the working group, as far as I know, and this is brand new information to me. I'm hearing it from you, but I also heard it from Amelia Bellamy-Royds, who pointed it out to me that these snapshots exist and that there's a desire to get one done in the first half of this year. That's a landing page then.

Unfortunately, the last snapshot was kind of a while ago and the page is terribly boring. It looks like a spec page. It's useless. Nobody cares about that. The right people do, or whatever, but there's no marketing that's going to happen behind these snapshot pages that exist.

My general advice was, like, you can leave that page as it is but maybe if there is budget or desire, if the right people care, hire a content strategist and a designer or something. Put them together and be like, "Make us a microsite that brings life."

Dave: Paravel.

[Laughter]

Chris: Yeah, that brings life to this and will agree on the term, CSS 2019. Why don't we just copy what JavaScript does? It seems they have some success with that. Build this beautiful thing that's like, these are where the specs are right now. Then you can sell courses around it and workshops and stuff. That's just a hot take, you know.

Dave: We've got to keep Wes Bos in play, Chris.

[Laughter]

Eric: It needs a little zip. We need some pep. Make the logo bigger.

[Laughter]

Eric: Anyway--

Chris: I don't know.

Dave: I'm a fan of this plan. I want it. Yeah, sometimes I do consider buying my way under the CSS working group. [Laughter] But then, it's a lot of travel, so I don't want to do that.

Chris: Yeah.

Dave: Major, major thank you to everyone who does do that.

Chris: I'm jealous of it sometimes because of the people that I know that go and then I see their writing, even right after it happened, but even long-term. It feels like their understanding of CSS and what's happening with it is so much deeper than mine. I'm like, oh, but I'm supposed to -- I feel like--

Dave: Yeah….

Chris: I happen to have a Twitter handle that suggests that I might have that understanding but I don't.

[Laughter]

Dave: But, yeah, maybe we should do it, Chris. Then you and I, hanging out in Tokyo or wherever they do the meetings, and we'll just CSS it up and offer our dumb opinions.

[Laughter]

Dave: This will be great.

Chris: Chris and Dave go to Tokyo.

Dave: Yeah, for CSS.

Chris: Yeah, maybe someday. We'll just wait for our kids to graduate high school and let's do it.

Dave: Well, cool. Eric, we are getting close to running out of time here. I was kind of curious what AEA, as we kind of said, breaks ground somewhat regularly on big ideas like RWD and you're kind of designing for emotional events and things like that, keeping all that in consideration. What are things that you're kind of seeing, themes growing at AEA? Are there going to be any hot talks this year that we need to look out for?

Eric: All of them. They're all hot talks, Dave, of course, including yours.

Dave: [Laughter] It is mostly because I make the thermostat -- I set it to like 95.

Eric: There you go. Perfect. Yeah, I mean I feel like there are a few. I don't want to get too far out in front of my skates, skis, or whatever that term is. There's a lot of interest in multi-modal design. What I mean by multi-modal is, does your site or app or whatever also work on Google Home and Alexa or Echo, or whatever the heck it's called? We're not used to thinking of designing for voice interface as design, but it is and it's becoming slowly more relevant. We've had multiple people say that they're interested in that.

It's not so much designing for Google Home. It's being aware that yet another axis of fluidity with the Web is that not all experiences are visual now, right? It used to be that we would say, well, people who are blind use screen readers or whatever. Well, Google Home is possibly the world's most popular screen reader at this point in the same way that Google is the world's most content consuming blind user.

Dave: Yeah. Not to interrupt you, but I have a friend who works for the Texas School for the Blind and Visually Impaired. He was saying -- he's looking for education apps for his kids who are visually impaired. They've settled on setting up an Echo in the classroom with a math app, math learning skill. That's the best way for these kids to learn because none of the educational apps are accessible. [Laughter]

Eric: Right.

Dave: So, the easiest way to teach these kids math is to have an Alexa teach them math, which is very, very interesting to me and, also, a damning failure on the education app system. Man, what an interesting -- like, it's a very valuable thing. It opened my eyes to how valuable it can be.

Eric: Yeah, absolutely. That's a thing we're seeing. There's also -- I'm not sure if this is quite a trend but there's a feeling of reconsidering a lot of the fundamental truths that we've all sort of accepted, so things like everything has to be really fast. Not always. Right? Some things actually shouldn't be fast.

Jeffrey Zelman talked about that last year. I think we have some talks -- well, I know we have some talks along similar lines this year. Gerry McGovern has talked about it in his own way. I think he said this. If he didn't, this is something he absolutely would say. If the results you're giving your users are crap, it doesn't do any good to give them crap faster. [Laughter] Right? Sometimes it's the slowdown and help them get the right thing.

Chris: It does sound very much like Gerry.

Eric: Doesn't it? [Laughter] I think maybe Jeffrey said that and it just sounded very much like Gerry - at any rate.

Chris: It's always nice that he ends it, though, because of all the stuff we talk about, like if you have ever heard me give any talk ever in the history of any talk I've ever given, I'm probably talking about some nerdy, technical thing for the most part. That's because I like that stuff. I just think it's really fun and I probably will do that forever.

But in the comparison to the stuff that Jerry talks about, it literally doesn't matter. Nothing I've ever said matters at all compared to anything he says because he's saying these big, fundamental truths like you should put something on the Internet that people actually care about and it solves their needs.

Eric: Right.

Chris: Well, who cares if you use SVG or PNG to do that? It just doesn't matter. I care a little bit because I'm just a nerd and I like focusing on those small details, but they are details.

Eric: Right. But someone has to worry about the details. [Laughter]

Chris: Yeah.

Eric: Otherwise the Web would just be pages that were great big PNGs.

Chris: Right.

Eric: Or JPEGs or whatever. Yeah, so there's room for both. That's why we have both--

Chris: Right.

Eric: --at AEA, honestly, is that we like the little nerdy closed-end talks. I love those. But we also like to have the sort of bigger picture, you know, are you thinking about all of this in the right way? Because you have to have that bigger picture in order to know whether you need an SVG or a PNG. Right? Yeah.

The other thing, I think there's definitely a stronger consideration of ethics, which maybe fits in with the things we were just saying. Also, sort of pausing a little bit to take stock of how we got to where we are and what that could tell us about moving forward. My talk is a little bit about that this year.

Chris: Okay. Yeah, that's good. Certainly, not knowing about the past is just kind of bad news, and it seems to be more clear more and more. I hate to always throw -- I don't want to sound like I'm throwing JavaScript people under the bus because I don't really believe that and I use every modern, fancy framework thing there is, so I'm on that side if there are sides, which there isn't but, you know, just for context here. You just see it more and more.

You see somebody do a div instead of a button or you realize that there isn't a form validation in HTML, so you use some big, exotic framework to do it, not realizing that you can kind of get what you're doing for free, depending on what it is, or you don't know that there are different types of input, so you reinvent the wheel to create a new type of input. A lot of this stuff, this feels to some of us really like elementary knowledge about the base level of the Web, which is HTML. It's not there and really exotic things are happening in its place.

What I don't want to sound like is that I'm like, "Oh, just totally ignore all of CSS and JS because there's a lower-level technology that handles that," because I don't believe that either. I'm fairly progressive in that thinking. There are a lot of people that are solving a lot of interesting problems for their organizations using those tools, so I'm not trying to discount it but I just mean when you can use something that solves the exact same problem that you get for free from browsers with zero technical debt and incredible performance, you should at least know about it. I don't know if that's the vibe of your talk, but if you know some of the -- even calling it history doesn't feel right. That's not history. It's now.

Eric: Yeah, well, that's actually one of the points of the talk is that when we say this is a thing that will happen in the '90s, most of that is still happening now, right? It's still there. It's still supported. It's one of the remarkable things about the Web, really, when you think about how many programming languages just break stuff that was in previous versions of the programming language. You upgrade from PHP 5 to 7 or whatever and, suddenly, the functions you used in PHP 5 aren't supported anymore. They just don't work or they work differently. Programming languages do that. The Web doesn't.

Chris: Yeah.

Eric: It's really remarkable. I think it's one of its core strengths and it's a point I will make in my talk. Not the only point, but one of them. But it really is remarkable.

But on the flip side, sometimes it feels like we sometimes say, "Well, that's not history. The Web is not old enough for history. The Web is 30 years old. There's enough time for history."

Chris: Yeah.

Eric: Kids who were born the same time as the Web have graduated college and gotten married and had kids and some of their kids are already in school.

Chris: So, it is history.

Eric: That's long enough.

Chris: [Laughter] That's plenty, plenty long enough.

Eric: Yeah.

Chris: Yeah.

Eric: Yeah, that's more than a generation.

Chris: Especially something that scoots along so fast.

Eric: Mm-hmm.

Chris: Okay. Well, that's that. Please attend AEA and AR, sponsors of the show this year. But we're saying that as attendees and speakers and people who have been and enjoy it.

Dave: I'm looking forward to it and, if I don't see Gerry once a year, my soul starts disappearing. So, I'm looking forward to it. Thank you, Eric, for coming on. We always appreciate it. For people who aren't following you and giving you money or attending your conferences, how can they do that?

Eric: Well, they can find me at meyerweb.com. That's not a way to give me money, but you can see my stuff there. I'm also @meyerweb on Twitter and most social networks that I'm on. Don't look for me on Instagram. Sorry, I'm not there.

Then aneventapart.com is the website for the conference where I guess you can give the company money, which is sort of like giving me money. Really, the reason you would come there is to level up your skills and learn not only what's happening now but what's coming next.

Dave: You're in how many cities this year?

Eric: Six.

Dave: Six. There you go.

Eric: Our first time in Minneapolis in a decade--

Dave: Oh, there you go.

Eric: --is happening this year.

Dave: All right.

Eric: Hey, Minneapolis! Although it's in the summer, it's not at the same time as the State Fair, so you don't have to choose.

Chris: [Laughter]

Dave: [Laughter] Important decisions.

Chris: Oh, everybody knows the best state fair is in Wisconsin anyway. What's up!

Eric: [Cough, laughter]

Dave: Whoa!

Eric: That was Chris.

Dave: We may get flagged.

Eric: Chris said that.

Dave: Flagged, flagged….

[Laughter]

Dave: Whoa! Okay. Well, thank you. Thanks again, Eric. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you got anything else you'd like to say?

Chris: Ooh, ShopTalkShow.com.