Transcript

Dave Rupert: What you explained in 2 minutes, we took a good 30 to explain wrong with the wrong property value too.

[Banjo music]

MANTRA: Just Build Websites!

Dave: 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 am Dave--embarrassed it took so long to get our guest on--Rupert and with me is Chris--also embarrassed--Coyier.

[Laughter]

Dave: Hey.

Chris Coyier: Yeah.

Dave: How's it going, Chris?

Chris: I'm doing pretty well. I feel like I listened to the last few episodes and some of it was me [coughing], "Hello. Welcome to the show." That's over now. Can you tell my smooth, beautiful voice? I feel good. I look good. [Sniffles] Anyway--

Dave: Okay, because I have your radio voice from last week is not infecting my lungs. We're back from JAMstack Conf. That was….

Chris: Oh, yeah. We could talk about that a little bit. More importantly, we have a special guest on, Miriam Suzanne. Hi, Miriam.

Miriam Suzanne: Hello. Good to be here.

Chris: It has been too long. Yeah. Yeah, only because I feel like I've known you forever.

Miriam: Yeah.

Chris: I remember -- like, I know how this podcast is supposed to start. We're supposed to be like, "How is Suzy these days?" [Crazy laughter]

[Laughter]

Chris: You know. Whatever. If that feels like an inside joke to people, Suzy is a grid framework for Sass that Miriam has been -- I don't know. I feel like I've seen your hilarious style of conference talk where you're like, "Don't use my thing." We can get into that another time.

We know each other from way back at this point, at least half a decade ago where we were in Colorado somewhere.

Miriam: Mm-hmm.

Chris: This was before you had kind of fully name transitioned to Miriam, I think, and there was some kind of name conflicts with--

Miriam: Yeah, yes. Yes, at Dev Conference there was.

Chris: Yeah.

Miriam: That was good times.

Chris: Yeah. Yeah, it had something to do with another famous CSS nerd. But whatever. That was fun back in the Sass days, and we all kind of lived through that. I wonder. Maybe it is interesting to start there. What's your care-ometer about Sass lately? It seems like it's fairly high still. You just wrote an article for our site, CSS-Tricks, that was about some kind of new Sass features, so you stay pretty involved, right?

Miriam: Yeah, I've been getting more involved, actually, lately, with this new release and what's coming next. I think part of that is trying to figure out -- I mean it seems like Sass is no longer the cool kid in some ways. It's not what everybody is talking about, but it's still assumed in a lot of cases. A lot of people still use it. It's sort of an assumed part of a stack.

Dave: Yeah, it's almost like you get it for free now, right? It's kind of in everything. It's in Angular. It's in Vue.

Miriam: Right, and then there's been a lot of people bad talking it or, like, "Well, we don't need it now that we've got CSS modules or some post CSS plugin that does half of the features," whatever this person considers most important.

I feel like there are some pieces being left out of that conversation. To me, in particular, for design systems, Sass is the only language we have around that can store design tokens and know what they mean. A lot of people are storing tokens in YAML, JSON, or something like that and everything is a string. To me, that doesn't make sense. Colors should be colors. Strings should be strings. Numbers should have units on them, those units should be meaningful, and the language should know how to manipulate them. I look around and Sass is sort of the only language that can do all of that. I think it could be solving a problem for people that they don't know it could be solving for them.

Dave: That's a good point. It's like the design token ideas you have, JSON or YAML, a central repository for colors or fonts or however far you want to extend that. Then you need something to consume that. CSS cannot consume YAML.

Miriam: Right.

Dave: Sass is like, "Sure. Import it. Let's figure it out." [Laughter] Then it'll generate variables off of that.

Chris: Can it really? Sass can import YAML, kind of?

Miriam: Well, not directly, but you could -- there are various systems to go either direction. We actually have one that exports Sass to JSON. We start in the Sass and then we export that to JSON so that--

Chris: Oh, nice.

Miriam: --we have that data then somewhere else. But once it hits the JSON, it's just strings again because that's all JSON can do.

Chris: Yeah. Fair enough.

Miriam: In our Sass, we have actual numbers with actual units and we can do unit math.

Chris: Yeah, so it's easier in Sass and you make Sass the source of truth.

Miriam: Exactly.

Chris: I feel like design tokens is a great -- I feel like what a great term. It's really like getting in people's heads. You might have been doing it already. You might be like, "Oh, yeah, we have those," which, wherever you build your UIs, you have, like Dave said, a bunch of fonts, a bunch of colors, a bunch of spacings, a bunch of whatever it is. Is it fair that you'd only call them a design token if there are multiple targets? You know, like if you need to then -- because you're trying to rein in your iOS app with your Web app, so you make a tokens file that serves both of them or is it kind of like it doesn't matter?

Miriam: I don't know. I use tokens even if there's just one app being generated from it. I think it sort of refers globally to all of the design configuration, the pieces that we're going to need to build the design system, even if that design system is only building one app from there.

I think, though, the multiple destinations thing is part of what people go with YAML or JSON. It feels more universal, not Web-focused, and that is true. Sass is a CSS superset. It's very much Web-focused.

Chris: You run OddBird, yeah?

Miriam: Yeah.

Chris: That's the day job.

Miriam: That's what I do.

Chris: You build stuff. [Laughter]

Miriam: Yeah, we do. We do client work and a lot of open source work. It's a real mix of design systems and architecture, training and workshops, sort of helping teams do architectural front-end, get your front-end organized. Get a design system in place. Get a component library.

We're systems thinkers, generally, so we like doing that work. Then also full builds of custom apps. Start from scratch. Build out a product.

Chris: Yeah.

Dave: Do you see a big need for just somebody making a plan for their CSS and front-end? Is that kind of a big, common problem?

Miriam: Yeah, I think often it's people that, the first time around, they had to go for speed. You end up with something that had some features quickly but doesn't really scale, isn't easy to build on. That's where we'll come in and help rearchitect it so you can actually keep moving forward and not have to rebuild every two years.

Dave: Do you use any--? I'm going to go for it. [Laughter] Do you use anything like Bootstrap for Foundation or prescribe frameworks? I imagine the answer is no, but I'm going to just ask it anyway.

[Laughter]

Dave: Do you use any tools like Pattern Lab or Fractal or something like or Storybook to kind of organize it or is it just purely…?

Miriam: Yeah. What's interesting about agency work is that we end up using a lot of these things even if we wouldn't necessarily recommend them because we'll come in and we'll often have to just work with the stack that's in place. We don't get to replace it entirely. We're just saying, "How are we going to clean this up and make it well architected?" That means we run into Bootstrap quite a bit, although I don't think we've ever put it into a project because it's not necessarily the way we work. Tools like Bootstrap, Storybook, various things like that we'll use if they're there, if they're what the company wants.

Chris: Isn't Bootstrap kind of an early--? Would a Bootstrap fan person who has used it a lot and maybe customizes it a lot say, "Well, if you're a fan of design tokens, it's a little weird that you're not a fan of Bootstrap," which feels like Bootstrap is pretty all-in on the -- here's a big ass file--

Dave: Yeah, there's about 130 of them.

[Laughter]

Miriam: Yeah, well, I'm also a big fan of building just what you need.

Chris: Mm-hmm.

Miriam: Bootstrap tends to give you the kitchen sink whether you need it or not. It comes in with a lot of opinions that aren't necessarily right for your app and then you spend a lot of time overriding their opinions and that's where things get messy.

We try to help figure out as much as possible. How can we just pull in what we need from Bootstrap? Whenever we're overriding, can we not have these layers of overrides?

Dave: Isn't the argument always like, "Oh, you comment that out," and then all of a sudden you don't have tabs or whatever? Is that your experience? To me, it always seems a smidge naive. I don't know.

Miriam: Yeah.

Dave: Is that your experience?

Miriam: I don't know if I understand the question exactly, but I think there is something there. It really depends how you pull it in. Bootstrap has all these different ways of using it. We tend to push people towards the Sass approach because then you can just import the pieces you want and be a little bit more organized about it, be a little more controlled about what it's doing in your code. I think the real problems are where you get to, like, well, Bootstrap has a high specificity rule that creates this tab and now I want the tab to be slightly different so I'm going to hit bang-important on everything and that's the only way to override Bootstrap.

[Banjo music]

Chris Enns: This episode is brought to you by Backlog. Backlog is the all in one project and code management tool development teams have been waiting for. With project management, bug tracking, wikis, and get rolled into one easy to use platform, Backlog provides the powerful features development teams need under a clean UI that anyone can use.

Easily onboard your whole team and start working on tasks in minutes. Additional features like ANT and burndown charts make it easy to manage projects. Mobile apps keep your team connected, and their simple pricing scales with you, so you can stop worrying about per-user charges.

You can build your next project with Backlog. Get a 30-day obligation-free trial at Backlog.com/ShopTalk or follow the link in your show notes or your podcast player right now. Our thanks to Backlog for sponsoring this episode. Keep all your projects organized with Backlog.

[Banjo music]

Chris: I want to ask both of you about this because this has been peppered into my mind and I feel a little unqualified to write about it but I'm going to do it anyway. I guess that's what men do. Sorry about that, the Internet.

Dave: That's called blogging, Chris.

[Laughter]

Chris: Yeah. Oy.

[Laughter]

Chris: But I get questions about this, so I feel like there's some need to address it and I've been thinking about it for years. It's the whole thing of unused CSS. Let all of your opinions start to flow into your brain about unused CSS. Part of it, like it or not, is highly Bootstrap related because one of the ways that you can use Bootstrap is just to use it all, just to grab the precompiled version of it. I feel like in Bootstrap 3 there was kind of a builder where you could say, "I want this, this, this, this, and this." I think you could even use to do that with jQuery for a minute. There've been apps in the past that help you download just what you need and you have to put a little thinking behind it but at least then, theoretically, it's pared down to what you don't need. Maybe less and less common these days because we're told, "Don't worry. Tree shaking. It's in there. Just don't worry about it."

Maybe tree shaking for CSS isn't there yet as well as it is in JavaScript land. We're told that because you go to a site and you open up Chrome. Now it's got this coverage tab. I don't know. Maybe other dev tools have a coverage tab now too. The answer to that is probably complicated, but you click around your app or at least look at some pages of it and it'll tell you, "84% of your CSS is unused," and you're extremely worried because CSS is in the head and is render-blocking. It's like, holy cow. If I could cut the size of the CSS in a quarter, that would be incredible performance and, because I read Tech News, I see that there's about nine tools that promise to remove my unused CSS from my app and they all kind of work in different, interesting ways.

I have this Bootstrap site. I'm told that 84% of my CSS is unused. Where do I just get this information and just make it part of my build? I don't know. What do I do? I feel like there are people that have this information and then don't know what the next step is. I'm not sure what the next step is either and I don't trust it as far as I could throw it, but that's the opinionated part of it.

Dave: 94.8% of the Git Bootstrap website is unused CSS.

Miriam: [Laughter]

Chris: There you go. Miriam, what do you think about all that?

Miriam: I think it's hard. We can't really do tree shaking the way we would want to in CSS. I don't know that there is a solution to that in the same way that there is for some other languages because CSS sort of doesn't exist until it's with HTML. We have no idea what's going to be used until we apply it to some HTML.

Then if we're writing CSS for an entire app, we can't look at one page and shake the tree for that one page because that's not also a full picture of what's actually used in your app. Even a single page app, we're changing what's on that page all the time. Are you going to run through every single state to see what was used? I don't know.

Chris: Yeah, that's tough, right?

Miriam: Do you have some CSS that's handling a fallback that you're going to need in a different browser? That's unused in the browser you're testing in. How are you going to check all those things? I don't know if there's a way to do it automated that's really reliable. I would be skeptical of any tool that tells me what CSS is unused, which is not helpful.

[Laughter]

Dave: I always think in systems, too. You mentioned systems thinking. When you build a site, you're like, well, the idea here is they're going to go through five pages or something. Here's the flow, and so I am doing a little bit of eager loading to get all this, but I'm hoping it's under 20 kilobytes or something. I want a little bit of loading, preloading so that the rest of the experience is flawless and paints as fast as possible, is already processed, and things like that.

Chris: Yeah. You have some unused CSS on purpose because that means, when it does eventually get used, it's already ready to rock and roll.

Dave: Yeah. Always my favorite example is, every unused CSS tool is going to be like, ugh, you have table and TD defined. Don't have that. It's like, of course, I don't on the home page.

Miriam: [Laughter]

Chris: Right.

Dave: There's a WYSIWYG you see on the CMS and someone is going to use….

Chris: Somebody is going to do it, yeah.

Miriam: Right. Right.

Chris: You've got to check every URL of the site. That data might actually be in a database, not in templates. I think some of the pushback from this would be like, "Well, don't worry. We're going to look at every single template in your project and every single JavaScript file." Some of these projects are so "dumb on purpose" that they'll tokenize every word of every template in every JavaScript file. They're not even looking for class names on purpose or just any word at all and they tokenize the whole list of everything they find and then compare it against every selector that they find in then CSS. If there's no match there then it's like, "Look, we really tried here. You can't possibly be adding a class in JavaScript in some one-off state that doesn't match this class because we looked at everything."

Now, they can't look at third party JavaScript and so there are even some cases there. I like what Miriam said about different browser scenarios. I'm not sure how that would play into it. That gets complicated. Then to throw another wild card into this, there are all these Tailwind people. We've had Adam on the show and people that like the CSS that's just like--I don't know--just use a million class names in your thing and then load the CSS file. You can kind of tree shake from there. If it's not in the HTML then I didn't use it, so only load that CSS. I know I just threw a bunch of wildcards in the wild here but it makes the story so complicated.

Miriam: Yeah. I think it gets to a bigger problem which is that people want CSS to work like other programming languages. When it doesn't, we go, "Oh, I learned that languages should work this way. If it doesn't, it must be bad or it must not be working right. We need to fix it. We need some tooling around it that makes it work right."

I think it fundamentally misses some of the point of CSS and how CSS was designed. It was fundamentally designed to be contextual and to let browsers make decisions for us. That's the opposite of trying to isolate functions and make sure that everything runs exactly the same no matter what context it's in.

CSS is fundamentally not that and never going to be that because of what it has to do on the Web, which is to fall apart gracefully in a million different scenarios. It cannot be isolated. When we try to make it be like other languages, we're just going to get frustrated.

Chris: That makes me think of -- I think maybe the subtext of that was some CSS and JS stuff. If you go down that road that, in a sense, makes it a little more tree shakable because you can analyze what's happening a little better from the JavaScript side, which might be a plus in that scenario. If you're really concerned about unused CSS, that's yet another way that you could approach the thing.

Miriam: I guess I always think, if we're worried about CSS performance, have we removed all the JPEGs and massive JavaScript frameworks first? Those are blocking more. I have people regularly concerned about me using the universal selector, the star selector. Isn't that bad performance? I'm like, "You have a JPEG that's massive at the top of your page. Why are you worried about the universal selector? They're not even comparable. [Laughter]

Chris: No, and even that story is so complicated because it could be argued that an image isn't render-blocking and CSS is. Eh, I could see how that's important. But you know I'm on your side here.

[Laughter]

Chris: The easy wins that you're not doing are substantial, in a way, and there are so many of them. Yeah, then selector performance is a different type of perf than how big your CSS is.

Miriam: Right.

Dave: Mm-hmm.

Chris: It's an even more irrelevant one, so this story is complicated too. I don't know. I almost -- not that I long for the simpler days, but none of these conversations come easy, do they?

Miriam: No.

Dave: For me, it almost doesn't make sense to add 30K of JavaScript to solve a 6K of CSS problem. You know what I mean? Maybe those numbers are totally wrong and made up. They are. But piling more work onto the main thread to solve a little bit of extra download, it's like--

Miriam: Well, and also there are advantages. Browser engines rendering of CSS is actually pretty optimized in ways that we can't because browser engines know things we don't know. They have all the context. In some cases, browser engines can solve these problems better than we can. I always feel like taking it away from the browser engine and trying to solve it on our thread and then pass the solution back to a browser engine is going to be worse than just letting the browser engine solve it.

Chris: Yeah, right.

Dave: If I can have a real time story from this week, clamp and min and max are starting to hit browsers. I took my old jQuery plugin, FitText, and rewrote it in just clamp as all I need and you pass a min, whatever, medium.

Chris: Yeah, and that's FitText, but it's kind of the same philosophy for responsive typography too, right?

Dave: Yeah, it's the same.

Chris: Like a scale between this size and that size with a clamp. You could just do it now…. Min, we get, right? You pass the two parameters. Is it just two parameters or can you pass X parameters? That'd be kind of cool.

Dave: Min is two, I think.

Chris: It takes the smaller of the two, so that's obvious. Max takes two, back to the obvious. How does clamp work?

Dave: You pass it, min, like 12 pixels or 16 pixels.

Chris: Yeah.

Dave: Then a scaling value like 10VW.

Chris: Seriously? There's a programmatic middle value?

Dave: Yeah.

Chris: Fancy.

Dave: Whatever value you want that to be, it could be some weird calc statement if you want. Then there's a max. It's cool because all this crud I was doing in JavaScript, occasionally, is now just, "Later. Bye." This is a one-liner in CSS. It's very cool and now CSS is doing it faster, like Miriam was saying. It's way more performant. I'm not measuring on resize. I haven't bound a resize. I'm not measuring the parent every time it resizes, which causes a layout recalculation. It's just instant and so it's very cool.

Miriam: I need to play with that. That sounds cool.

Chris: It's just the kind of thing you've been doing videos about lately, right?

Miriam: Yeah, exactly. I should do one on that.

Chris: Some of the things you mentioned, it seems like there are bits in there from your, "Why is CSS so weird?" video, which really, really blew up and everybody was sharing that around the other day. It's a wonderful one, right? Your point there is some of that. CSS exists in their weird space, right?

Miriam: Right. Yeah, it's solving a very strange problem, which is, even a problem that Tim Berners-Lee on the first website ever said, "We'll never be able to solve this."

Chris: [Light laughter]

Dave: Wow.

Miriam: He says on that website, "We'll never be able to do things like fonts and colors, for example, because they rely too much on device capability."

Chris: The client.

Miriam: And, "We can't rely on device capability when we're on the Web." To the point where the team at CERN, they had their first browser, which was a graphic interface and then they were like, "Oh, we need to prove the point. We'll make a second browser that has no graphic interface and is just text and works on a terminal anywhere to prove that we really mean it. There's no design on the Web."

Dave: Hmm.

Miriam: Then CSS has to come in and solve that problem. What does it mean to design for a medium that maybe has no screen? It's a weird problem to solve.

Chris: His point wasn't, or whoever was involved with that statement and sentence, wasn't that you shouldn't suggest what color or font something would be. Just don't count on it?

Miriam: Well, at that point, it was very contentious between those. At first, there was no way to even suggest and a lot of people felt like that was right and that's the way it should be. Browsers should make all the decisions about presentation. At that point, the language is also much simpler. It's like 16 tags or something and you're not allowed to nest them. I don't think divs were around. It was like you have paragraphs, headings, and lists. What do you need to style those for? The browser will figure it out and you're okay.

There's even a great conversation that's like, somebody being like, "How come my list has a space above it on this browser and not on that one? How do I change that? It seems like a bug. Can I fix it?"

The response is, "No, you're screwed. That's how we built it. That's how we want it."

What happens is, around '93, '94, browsers are starting to add proprietary ways to style things because everybody wants it. Users want it and authors want it. Everybody wants the Web to be more interesting and work better, so browsers are starting to add either to HTML like a center tag, a font tag, and a color tag, or their own style sheet syntax.

Finally, everybody is like, "Okay. We have to do this. We have to solve this problem."

Chris: Mm-hmm.

Miriam: Then there are a bunch of different proposals that you can read through. They're all on the W3 website.

Dave: Was there one that's good?

[Laughter]

Dave: The alternate timeline CSS?

Miriam: No, no. The one that's good is called "Cascading HTML style sheets."

Dave: Oh, wow.

Miriam: In a couple revisions, HTML gets dropped because it should apply to any XML or SGML language.

Chris: Hmm.

Miriam: It becomes CSS. You can look through the others.

Chris: That didn't quite happen, did it?

Miriam: They're quite fascinating. There are a lot of interesting ideas.

Dave: I think -- anyway, whenever somebody is like, "Oh, CSS is so broken," and it's like, "All right. Let's hear what you've got," you know.

[Laughter]

Dave: [Indiscernible]

[Laughter]

Dave: At some point, you're going to come up -- like it's designed, more or less, right? You have to describe how something is and key-value -- a system of key-value pairs seems pretty strong in how to describe a design. I think you had said it in your video, but these properties, key-values we write, end up kind of just being suggestions to the browser that it can kind of just be like, "I don't understand that one."

Miriam: That's very clear in all the first proposals. There's one great one that says, "We need a way to send," and then all caps, "HINTS AND SUGGESTIONS TO THE BROWSER."

Chris: Uhhh…

Miriam: All of the proposals talk about, how are we going to balance a device setting some defaults that are going to make every site readable and then users setting preferences that are going to make it usable for them, like larger font size or whatever it is, and then authors providing suggestions and hints around their intent, what they mean for it to look like? Then, on top of that, we have to have users be able to say, "No, but I mean it. The font has to be big," so bang-important. Then the browser has to come in at the end and say, "Yeah, but I can't do that," and come up with some other way to solve the problem.

We've got these layers that, like, the browser gets first and last say. The user gets second and second to last. Then the authors, we're in the middle saying what we would like, please.

Dave: Mm-hmm. Yeah, I think it was from -- what's that guy's name -- Dave something. "The Web is Ruined and I Ruined It," or whatever, the guy who wrote all the table layout books in the early days. He's finally coming around to CSS, I think.

Chris: Now?! Right now?

Dave: Well, no. In, like, '99 or something like that.

[Laughter]

Chris: No, I mean the coming around part. But, yeah. Tell me.

Dave: I think he finally came around after just a lot of standards battles. One interesting thing, I think he just realized, okay, the user has to have ultimate control. If you put that in that like a design constraint, the cascade part, which everyone hates--that's the worst part of CSS is the C, you know--that when you put the constraint that the user has ultimate control and rights over their experience, I feel like the cascade is almost the only design solution that works.

Miriam: Right.

Dave: It's a rubric where it goes, whatever, the original rule, then important, and then whatever the user says. The buck stops there.

I'm enjoying you going through these histories, specs, and stuff like that for these properties and whatever. I don't think people, at face value, understand the history of it and how CSS is designed to give the user ultimate control. The benefits there are dyslexic fonts.

Miriam: Right.

Dave: I mean, shoot, you're not going to code that.

[Laughter]

Dave: Somebody else -- some user is going to come in and say, "I need this," or large scale or high contrast mode.

Miriam: Mm-hmm.

Dave: Stuff like that, we don't even consider part of CSS or the browser. All this stuff really matters. Even browser zoom is probably the most hostile example of that. It's like, "Oh, no one zooms past 150%."

Miriam: [Laughter]

Dave: It's like, yeah, you do if your eyesight doesn't work. You zoom as far up until you can see stuff.

Miriam: Yeah, my eyesight works and I zoom a lot of sites because the text is too small and I want to see it. I want it easier to read, or I'll hit reader mode and I'll take out all of your styles and replace them with a new browser default.

Chris: I only read in Palatino.

[Laughter]

Dave: Yeah. Yeah, star font face fantasy.

Chris: I'm fascinated by the "CSS is broken" people. Even that is extremely new.

This is just a guess that -- here's one fact. It's so, so crazy successful, CSS, it's unbelievable how many sites use it on the Internet as part of their….

Dave: Hundred percent. It's even more popular than WordPress.

Chris: Yeah, really.

[Laughter]

Chris: It's so popular. Even jQuery. Unbelievable. It's a big part of people's business strategy, for sure.

To have it not be criticizable is stupid too. Of course, there are problems with it that we can talk about. But to just be like, "Oh, this is a terrible language," you kind of can't say that. it's like to walk into a room and be like, "Amazon is a terrible business model." You're like, "Yeah, but they just don't because they're kicking ass." They can have problems with how they treat employees or what it's doing to the world or their political influence and all kinds of interesting things to talk about there, but you kind of can't argue with the success of something, its influence, or what's happening out there.

Also, a lot of us have built websites and had lots of problems and steppingstones on our journey to success in the things that we're building and the least of our problems has been CSS. I have much bigger problems with getting somebody to care about what I'm doing. If there's some little problem with CSS, then it's just like, oh, that was weird but here's a fix, and then you fix it. There are more important things to do today. You know?

Miriam: I love when people tell me that CSS is broken; I generally send them to the CSS working group site of CSS mistakes. I'm like, "Yeah, here's the list."

Chris: Yeah.

Miriam: There are 25 items or whatever.

Chris: Yep. All are true. Yeah.

Dave: I came across that this week and I just love it. I love that there's a list.

Chris: Yeah.

Dave: It's just 30 bullet points of, like, oops.

Chris: I've read through that many, many times.

[Laughter]

Chris: It's very honest. I love it.

Miriam: Yeah, I like the one that's super simple, but I don't know exactly what it means. It just says, "Table layout should be sane."

Dave: Yeah. Yeah.

Miriam: I'm like, that sounds reasonable.

[Laughter]

Dave: Yep, instead of whatever it is. That's so weird.

Chris: Oh, my gosh. I just tried to Google for it because I thought, for sure, the official list of CSS mistakes that the working group admits to making would come up fairly high for CSS mistakes. No, it's all clickbait.

Miriam: [Laughter]

Dave: Oh.

Chris: Oh.

Dave: You should SEO that with CSS-Tricks.

Chris: I have a new idea for a show. Let's go through every one of these clickbait articles.

Miriam: I know. Oh, I've been meaning to do a talk of everything that was proposed in CSS3 and never implemented.

Chris: Ooh! Juicy.

Miriam: Like what do we have--

Dave: Go on. Spill the tea.

[Laughter]

Miriam: What do we have specs for but has never been built? There are some interesting ones.

Dave: Yes, yes, yes.

Miriam: The one that first drew my attention was the attribute function that we can use in generated content.

Chris: Oh, yeah, that one.

Miriam: We can say--

Dave: Yeah, like adder. Yeah.

Miriam: Yeah, in the spec.

Chris: But pull it as a unit, a unit-ed unit instead of string.

Miriam: Yeah. In the spec, you can say -- you can use it anywhere, not just in contents, and you can say what type of info it should be. It should be a number. It should be a pixel number, specifically. Yeah, there is so much power in that and we don't have it.

Chris: We were at a bar the other night, Dave and I, in San Francisco. It's been long enough since CSS3 -- or maybe I just had a few beers enough is another way to put it -- that we were like, "What even was CSS3?" Now when I hear it, the only thing that goes through my brain is, like, "Ugh. We don't talk that way anymore." [Laughter] Whatever.

Miriam: Yeah, yeah. [Laughter]

Chris: You see, "Learn HTML 5 and CSS3," you just immediately roll your eyes like that's some old stuff.

Dave: Oh, you're not on CSS3? Oh, man. Oh, man.

Chris: Yeah, and I was like, what even was it? I remember at the time it was very -- people applauded it for being very well defined to be like, oh, this was important. It was almost like a marketing movement for the Web that says, "Oh, the Web doesn't suck anymore. Here you go." I was trying to remember what it even was.

Miriam: Yeah. Border radius, that's all I remember.

Chris: Yeah!

Dave: Border radius. See! Yeah.

Chris: That was my first one too, and then I was like, but was that first or was that firmly CSS3? I don't know.

Miriam: That was CSS3, but I don't--

Chris: I started to doubt myself.

Miriam: I don't know what else was. [Laughter]

Dave: [Laughter] That's it.

Chris: Danny was there and he was like, "Box shadow." I was like, "Yes! Box shadow. That was the one."

Dave: Yes!

Miriam: Oh, no, I saw the other day, media queries were CSS3.

Chris: Ohh…

Dave: Oh, yeah, technically, yeah.

Chris: Well, that's a big deal then, obviously.

Dave: Well, those didn't pan out.

[Laughter]

Miriam: Media queries are also in that first CSS proposal from Halcon Lee.

Chris: Really?!

Dave: Really?!

Miriam: Yeah, there are some really cool ones. There is a media query on the age of the document.

Chris: Awesome.

Dave: Oh, okay.

Miriam: In his example, he turns the page yellow if it's more than three days old and I love that. I want it.

Dave: Oh, my God. We've talked about that for eight years on this show.

Chris: Yeah! Remember we had that to put a span around all the letters and make them start to fall down the page or something or look like old newsprint or whatever, which is….

Miriam: Yeah, that's awesome.

Chris: Clearly -- yeah. That's just jokey but, at the same time, we do stuff. Like at CodePen, if there's a blog post that's over two years, we'll put a big warning at the top of it that just says, "Hey, this is old." It's not a media query. It happens at the database level, but that actually manifests itself. If you don't see a date on a blogpost article, I'm like, [cringing]. You know. [Laughter]

Miriam: It's really a very important thing. Why don't we have a media query for it? The answer is probably because that's easier to handle on the server.

Chris: You just lie. Yeah, probably.

Miriam: Or in the JavaScript. It knows the age of the document better than CSS does or the browser does or something.

Chris: Oh, it is fascinating stuff, though. Yeah, CSS is weird, right?

Miriam: Yeah, it's weird.

Chris: The infinite unknown canvas I stole from you.

Miriam: Yeah, I mean we don't know where our designs are going, so how would we even conceivably design for that? It's an audacious idea.

[Banjo music]

Chris Enns: This episode is brought to you by CloudBees Rollout. CloudBees Rollout is where developers come to ship changes at will. When you have a solution to manage feature flags at scale, you're empowered to continuously and intelligently roll out changes as soon as they are code complete on any platform, even mobile. Decouple development from code releases for real-time change control, rollback only the changes you want, toggle features, and use multivariate flags for A/B testing and nix misbehaving features with a kill switch.

Check out the 14-day free trial and experience how CloudBees Rollout can help you rock every release. Follow the link in the show notes or in your podcast player right now or visit Rollout.io. Our thanks to CloudBees Rollout for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: New stuff, too, we can do just because it's timely and this show has a date stamp on it, certainly. People are curious about subgrid, I think. You have a couple videos on that. It's a little -- grid is a little mind-bending by itself. I think it's Git-able, you know.

Miriam: Mm-hmm.

Chris: The mental model of it isn't too bad. You lay out some horizontal rules and some vertical rules. You place stuff between or let the browser place stuff between it, which is where it kind of gets a little weird, and how those things stretch and morph is a little mind-bending. But maybe approximately doubles in mind-bending-ness with subgrid. Ise that fair?

Miriam: Yeah, that's definitely fair. It's a little bit hard to describe to people how it's different from just nesting grids. Because you immediately think, well, I can just have a grid and then I can nest that grid. That's sort of what we've done historically with grid systems, right? You could do that with Suzy, so is it the same thing? It's not and it's because grid takes information from the grid elements, the things that are laid out on the grid. That information is passed back into how the grid is laid out. We need to pass -- we've got children and then we've got grandchildren. We need to be able to have grandchildren pass their information up the chain to the grid so that they are taken into account in laying out the grid.

Chris: Oh, that's an interesting mental model. You think of it as the grandchildren passing its information up to the grid.

Miriam: Yeah.

Chris: Which I'm sure is more correct, and I probably have this wrong, but is another possible way to think about it that it's the parent grid passes down its grid line information to the--?

Miriam: It does do that, but that's what starts to get confused with just nesting the grid because that feels the same. If the grid is already defined and I just need to pass it down, I can just do grid inherit and I get that. What subgrid does is it also lets the grandchildren be like, "But I want to be bigger," and pass that information back up.

It does go both ways, but that's the part that sort of makes it special. It means that cousins, I guess, cousins can layout together and speak to each other on the same grid.

Chris: Yeah, cousins would be in different trees of the DOM.

Miriam: Right.

Chris: They can participate on the same grid in a way that they wouldn't otherwise been able to. I like that I'm bigger because, if you're a cousin, you're trapped in your parent's tree and it's a way to express, like, "No, I want to literally," probably quite literally," be on a larger portion of the grid than I'm otherwise able to be." Wow. That's hard to mouth blog.

Miriam: [Laughter]

Dave: I like the grandchildren/cousin.

Chris: Yeah, that's good.

Dave: Which is why we need a nearest cousin selector in JavaScript.

[Laughter]

Chris: I mean another way to think about it is, I had this post ages ago about flattening markup for the sake of grid because it's like the second you need an unordered list you're like, "Oh, too bad. All those OIs can't participate on the grid anymore," just because semantically you had to have a UL wrapper around it. That's just one level. Now imagine five levels deep because you're trying to do right, good markup that makes sense for everybody. It probably is even harder in React land where there are fricken divs all over the place. [Laughter] At least now you can--

Miriam: Yeah, exactly. That also gets at why display contents isn't the same thing because it also allows you to layout and style the parent on the grid. If we're talking about the parent as the grid container itself and then the child, you can lay it out on the grid. Then you can also lay the grandchildren out on the grid. If you use display contents, you sort of lose that middle layer and you can't style it. Say you're doing a card layout. You couldn't just do display contents on the card because then you lose that outline of the card or whatever.

Chris: Yeah. Right, right.

Miriam: You can't just remove that card from the DOM. You can't just flatten and take it out. You need that card to hold the things inside of it even if you want the things inside of it to lay out on the grid. Subgrid also gives you that.

Chris: There might have been another possibility at some point. Display contents is cool sometimes but you just described why it's not cool in this circumstance. Another route forward might have been some other version, I guess, of display, although it makes me puke in my mouth to say that a little bit because display is so overloaded with responsibility already.

Miriam: Right.

Chris: To let's have another display value that does another weird thing but would be a little bit like display contents but without losing its semantic value or accessibility information.

Miriam: Really, in that case, it's not even about the semantic value or the accessibility. It's like, I still need to be able to lay it out. I still need to be able to put a card style on it.

Chris: Yeah, it's a background.

Miriam: It needs to be there and display contents makes it go away.

Chris: Yeah.

Miriam: I think display contents is the right solution to your React divs. They should just go away.

Chris: Oh, right.

Miriam: Display contents can do that.

Chris: I wasn't meaning that to crap on React, but I'm saying … use just a router or something that has no DOM meaning at all.

Miriam: Yeah, any of the frameworks.

Chris: But it has to express itself as a div for who knows what reason, for DOM manipulation reasons, and sometimes that's a big deal because you have a selector that needs to go through it, so you have to update the selector to account for this routing div. You're like, um… don't love that. But you don't if you just, like, contents it. Well, I guess you kind of do at the selector level but, at the styling level, it's kind of a better option. Ew. That sucked to mouth blog too. Sorry.

Miriam: [Laughter]

Dave: [Laughter] What other complicated things can we explain?

[Laughter]

Miriam: Well, I was just listening to you--

Dave: Big notation.

Miriam: --try to figure out revert versus inherit versus initial for….

Dave: Oh, it was tough.

Chris: Did you listen to us try to explain what you…?

Miriam: I did. I did. It was fun.

Dave: Yeah, that was tough.

Chris: We spent 30 minutes trying to explain what you were -- obviously, the answer was, watch the video and listen to somebody who knows what they're talking about.

Miriam: Yeah, you need a "phone a friend" option.

Chris: Yeah.

[Laughter]

Dave: What you explained in 2 minutes, we took a good 30 to explain wrong with the wrong property values too.

Chris: How did we do at the end? Did you get all the way to the end? Did we get it, finally, or not really?

Miriam: Yeah, yeah, mostly. I mean I think once you got it, you were sometimes saying "reset."

Dave: Yeah.

Chris: Oh, no.

Miriam: I think it ended up right there. I think you got it in the end.

Chris: What's the correct one? Revert. Revert is the actual value?

Miriam: Revert.

Chris: Yeah.

Miriam: Yeah, revert. Yeah.

Dave: I did see somebody on Twitter. I think it was Simi Vitas who does a lot of standard stuff. They were just kind of trying to like -- you know when people kind of -- I guess devil's advocate is not the right term but it was just like, what are the use cases? I think you had some good use cases like a button, for instance, when you do display. Sorry. I messed it up already. Frick! All unset. The button goes back to looking like text, right?

Miriam: Mm-hmm.

Dave: But all reset, the button goes back to….

Chris: Unset only works on the all value, though, too.

Dave: Revert. [Laughter]

Chris: Revert.

[Laughter]

Dave: Okay, all revert goes back to looking like a button.

Miriam: Right.

Chris: You can do all revert?

Miriam: Oh, yeah.

Chris: Oh….

Miriam: Actually, it's kind of fun. If you want to see sort of the spec default, if you want to take a website and put it on the spec default no matter what has been set; star selector, all, initial will take you to the spec default.

Chris: Yeah.

Miriam: Then if you hit bang-important, you'll override most of the styles on the site. You can very quickly see what is the spec default for everything on this page. Then if you change initial to revert, you'll see--

Chris: UA styles.

Miriam: --what is the -- yeah, UA styles.

Chris: That's a great little trick. Love that. Because otherwise what would you have done? You'd have to go find all the CSS files in that template in dev and just remove them temporarily or something, which you may not even have the power to do. I'm not even sure how you'd do it at the dev tools level. If you go into the head and just delete the link style sheet in the head, does it do that too? Maybe?

Miriam: Yeah. Also, I know in Firefox you get the edit styles tab and you can go in there. It'll show you where all the styles are coming from. You could delete them there.

Chris: Yeah. Yeah, that's true. This is definitely the fastest way, just a little chunkeroony in there.

Miriam: Yeah, I don't know if it's actually useful. Do you have to do that often? I don't know but I like it.

Chris: Well, people pay lip service to it anyway, like, "I always look at my site without CSS to see that it's semantically perfect."

Miriam: Oh, that's true.

Dave: That's actually one of the best ways to find accessibility errors real quick. It still is. It's weird because, whatever, we're so post turning off styles and turning off JavaScript now in this modern era, but it's still actually a really good way to be like, "Oh, yeah. Okay. That doesn't look like a button. That's just a text." Buttons should look like buttons.

I guess, do you see any other instances? I think the button for revert, display revert was pretty, like -- I don't know. It made sense to me because that's what I expect. Are there other examples where you're like, "Here's where I might see myself applying revert"?

Miriam: Well, I think if there is any reason that I would be applying initial, likely revert is more often what I really want because display initial is always going to take me to inline and that just doesn't make sense. I want display to go back to the default display for this element, not to the default display for the display property in the spec. So, I don't know how often you're using initial, but--

Chris: I just searched my whole code base for it and there are zero results, but I feel like revert, because it's more useful, might now that I know about what it actually does and the fact that it's more useful, especially with display values. Display is the clutch thing for it, I think, because the UA sets a bunch of useful display values for things that are sensible for what type of element it is and display initial just wipes that away, right?

Miriam: Yeah. You take a table that you've styled some other way and you want to take it back to a table. You can just say, "Display revert," and move back to table land.

Chris: You know what always gets me is on list items because I always set it back to block and then it's wrong because it's really display list item, which is [scoffs].

Miriam: Yeah, of if you're using multi-value display property is display block list item, so you're right on both. [Laughter]

Chris: Oh, I see because now we're talking two value display properties. Should we get into that? How much time do we have?

Miriam: List item is actually a third, so you can do three value.

Chris: Oh, right.

Miriam: You can do display, block grid, list item.

Chris: Ohhh… I don't know how to process that. Do I love that? [Laughter]

Dave: I did do display, block, and line, does it just vomit and spin around in circles or what?

Chris: Probably.

Miriam: Yeah, I think that would be an error because block and inline are both part of the outer value.

Dave: Yeah.

Chris: Oh, is that how you think of it, outer and inner?

Miriam: Yeah, outer, inner, and then list item is its own toggle.

Chris: Okay. Oh, I don't like list item.

Miriam: The outer value is, like, how do I layout in the flow? Then the inner value is, what layout system am I using for my children?

Chris: Okay, which is--?

Miriam: Grid, Flex, Cable, or flow. flow, we can now say explicitly.

Chris: Oh, and it's not flow root. It's just flow now?

Miriam: Well, so we have both. flow root says this should clear floats and it should act like a layout root. flow is just another … default.

Chris: It's what you automatically get?

Miriam: Yeah.

Chris: Okay, so you'd probably just omit flow because flow is weird and knew, but it just means what we've already said? Wow!

Miriam: Yeah, I mean it could be useful if, like, say you had something set to grid and you want to set it back. You can set it to flow. It's nice to have that as an explicit option.

Chris: Mm-hmm.

Miriam: Even if we're not using it a lot of the time.

Chris: Fascinating related thing to this real quick is that, let's say it was grid and then you set it to flow. There's all this stuff, I think, for maybe a new CSS developer mindset that they'd get confused about. What about all that grid template columns and all that stuff? What happens to it?

Miriam: Poof.

Chris: The answer is, yeah, it poofs, right? But some dev tools wouldn't tell you that it poofed, but that's kind of a new thing in Firefox, right? It will quite literally tell you that it poofed.

Miriam: Yeah, it'll be like this doesn't apply here.

Chris: Yeah, I guess that's it. That's the whole story.

[Laughter]

Miriam: It's the whole story.

Chris: It's grayed out and we'll tell you why it's grayed out. That's probably my least favorite UI/UX thing in the world is when something is grayed out and it doesn't tell you why.

Miriam: Oh, and it doesn't say. Yeah.

Chris: Yeah.

Dave: Hmm. Coming full circle--

Chris: Let's do it.

Dave: What if it's appearance or WebKit appearance?

Miriam: Oh.

Dave: Does Firefox gray that out and say, "WebKit appearance isn't real," and it's like, whoa? Whoa! But on iPhone it is.

Miriam: Well, it's different for things that the browser doesn't understand. That would be considered invalid syntax if it doesn't know it.

Dave: Okay.

Miriam: Then it would put a line through it and say, "We don't know the syntax."

Dave: Okay.

Miriam: If it's not used or not applied for some reason because this is the wrong place to use it, it'll gray it out and give you a little icon you can hover over that says why.

Dave: Okay. See, that's more useful because I was going back to a new CSS thing. It's like, well, I used that in IE, zoom:1. That's what I used.

Miriam: But that's also a thing that I'll use intentionally for fallbacks like this value does apply for a browser that doesn't understand grid or something. I'll have values in there that are just for floating and they're ignored by newer browsers but they'll still be used by an older browser. The fact that it's unused where I'm looking at it right now doesn't always mean it's worthless.

Chris: That's very interesting. Maybe that's one of the -- I could see the CSS haters of the world thinking that's odd too or the fact that CSS has no error state. There's no moment at which CSS stops reading a file because it has encountered an error.

Miriam: That's the entire way that the Web is forward and backward compatible. That's the fundamentals of making it work into the future and into the past.

Dave: CSS has error states. It's border one pix red.

Miriam: [Laughter]

Dave: I don't know why people keep saying this. [Laughter]

Chris: Well, it kind of does have one because there are some pretty extreme things you can do. You miss one closing curly bracket and it screws up until it finds the next closing curly bracket, sort of kind of. I think that's basically how it works.

Dave: Yeah.

Chris: You can lose a whole chunk of a thing without understanding why exactly.

Miriam: But that doesn't stop rendering ever.

Dave: Forget to close the media query.

Chris: No, right.

Miriam: Rendering never stops because of that error.

Chris: No, but JavaScript doesn't behave that way, right?

Dave: Well, in JavaScript, technically, you can forget semicolons and that's just fine. You can forget semicolons and whatever, curly braces sometimes.

Chris: Once in a while I'm shocked by little things like that that seem so fundamental, although I shouldn't be because I think I have a pretty good -- I don't know. It's been a long time where I've tried to write articles from somewhat of a beginner perspective, but sometimes it still blows my mind. Adam Argyle on Twitter from Chrome does interesting little pulls from time-to-time. He'll show a little block of CSS. You know how you can omit the last semicolon on the last key-value pair in a block or whatever.

Miriam: Mm-hmm.

Chris: Is this value? Most people are like, "No, that is not value." You're like, "Really? I thought that was just like a thing that we all knew for some reason." But clearly we don't, so I hope I'm not losing my edge of understanding what people don't understand. We've all got to remember; nobody understands anything. [Laughter]

Miriam: Yeah, well, or at least, nobody understands everything.

Chris: Yeah, there you go.

Miriam: Whatever you say, it might be old news to somebody but it's new to somebody else, so say it anyway.

Chris: Ah, that's the perfect place to end this, I think.

Dave: All right. Well, thank you, Miriam, for coming on the show. We should do it again because you're a fountain of knowledge and we appreciate that. For people who aren't following you and giving you money, how can they do that?

Miriam: You can go to OddBird.net for my company if you want to give us money and have us do work for you. We'll do that part too.

[Laughter]

Dave: It's not just a bank account.

Miriam: Then I'm at @mirisuzanne on Twitter.

Chris: That is OddBird.net.

Dave: Then the Mozilla developer channel, I'll just read out the URL here: YouTube.com/channel/UCh5 -- no, I'll stop.

[Laughter]

Miriam: I think YouTube.com/MozillaDeveloper will get you there.

Dave: See, that's much easier than the one I have showing up. Anyway, it's a really good channel. I enjoy what you all are doing there.

Miriam: Oh, thanks.

Dave: Okay. 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, just like this company.

Chris: Hey, ShopTalk Show listeners. There is a job available I want to tell you about. The place is called Tock, which is awesome. It's like software that you run in restaurants. You picture, like, "Oh, but isn't that software bad?" Yeah, that's kind of the point, I think.

Tock is like software for helping run a restaurant that's good instead of bad. [Laughter] It's the premise, you know, like these chefs opened it that are these great chefs and seeing all the massive amounts of money walking out the door just on the reservation side of dealing with it. It's kind of fascinating stuff.

Their job is a senior UI designer helping bring ideas for the software to life, so you have teammates that are also product designers you're exploring solutions, figuring out features and produce improvements, building prototypes, getting user feedback, and just making the thing better, which is great. You are, if you're good for this role -- first, it's in Chicago, a cool city. You're a strong, individual contributor. You're doing the work too, but you have strong leadership skills as well. This is a senior role, and so there's ambiguity with it. You enjoy exploring, figuring things out what's this project going to be. You're a problem solver. You've got high standards. You are into the data.

Then you write in HTML, CSS, JavaScript. Of course, you are. You're into new tools, like, what are you going to prototype in? Are you going to use Figma, XD, or are you going to go crazy and use some After Effects and get fancy with it? Are you going to be exploring things like Framer?

You're business-minded. This is a senior role here, so you're bringing yourself to it, exploring tools, exploring possibilities, and making this thing happen. Again, the company is called Tock. It's ExploreTock.com. We'll have a link to the job posting in there in Chicago, Illinois. Go get it, ShopTalk Show listeners. Go get it.

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

Chris: Oh, ShopTalkShow.com.