CSS, Sass, and Playwriting with Miriam Suzanne

EPISODE 44 [EPISODE]

[00:00:09] AC: Hey, everybody. Welcome to Enjoy the Vue. I’m Ari, and today on our panel, we have Tessa.

[00:00:14] T: Hello.

[00:00:15] AC: Ben.

[00:00:18] BH: Hello.

[00:00:19] MS: Nice delay. We have to live in a delay now, by the way.

[00:00:25] T: Make a note, Ben.

[00:00:27] BH: Yes.

[00:00:29] AC: And our special guest for this episode is Miriam Suzanne. Miriam, would you like to introduce yourself?

[00:00:35] MS: Sure. I’m Miriam. I do a lot of CSS-y stuff. I don’t know, is there anything else you need to know?

[00:00:45] AC: How can I be as cool as you?

[00:00:48] MS: You already are way cooler.

[00:00:49] B: So, Miriam, when it comes to see CSS and Sass, I know you've done a ton with grids and those kinds of things. So, when it comes to people who aren't as familiar with, especially those who are near the CSS, whether it’s because they kind of primarily have a JavaScript background, what do you recommend like people tend to get started from just like a learning perspective?

[00:01:11] MS: That’s a good question. I got started so long ago, I don't know all of the best current resources necessarily, but I think one of the hardest things for people that are coming from other languages is understanding the mental model of CSS and finding somebody that can really express that. It’s solving such an audacious and weird problem, which is graphic design of unknown content on an infinite and unknown canvas, across languages and devices and platforms, and both visual and non-visual media.

This is just absurd. It's absurd what we’re trying to do with CSS, because of that, in every other language we try to sort of isolate an environment and make sure that everything sort of ignores context so that we can control everything, and CSS is just fundamentally the opposite of that. Everything is contextual, everything has to be contextual, there is no isolated environment, your CSS is going to run on smart speakers, as well as screen readers, as well as watches, and 4K widescreen monitors. There's just no isolation of the environment or isolation of functions or variables or anything like that.

So, you have to get your mind around that, sort of, it's a collaboration with browsers and with users, everything is contextual, it's meant to be that way. Browser differences are a feature, your code breaking is a feature. This all sounds just terrible if you’re coming to CSS from JavaScript or something.

I came to it from theatre, so to me it's normal. It's like, “Oh yeah, we have to deal with the environment and we have to do different performances everywhere.” That’s just the way it is. It’s one weird big performance art.

[00:03:07] AC: I actually really like that analogy. That makes sense to me.

[00:03:12] MS: Great. So, I have a video about that on the Mozilla Developer Channel. I think Jen Simmons has lots of videos out there. She is the one that started that Mozilla Developer Channel that I got to work on for six months or so, but if you check out her layout and places like that, she has a lot of good material. Rachel Andrew, Stephanie Eckles, there are lots of people out there putting out good content on how to think about CSS and how to use it. And CSS really does give us the tools to deal with that absurd lack of control.

We have like font stacks where we define fallbacks for things. We have media queries. We have support queries. We have all these different ways to handle resilience, to handle falling apart in a beautiful way, and it’s about sort of learning to manage those and to not try and target every single variable, because we can't. There’s too many of them, but to understand how do we create simple fallbacks for each new thing so that it degrades gracefully even if it degrades quickly?

[00:04:25] BH: Yeah. I really like that concept, of that fact that CSS isn’t really about a mental model, especially the one that you put from a traditional programming language, when you’re like, “Everything's immutable or no side effects and stuff.” It almost seems like heresy to do at the CSS way, but I know for me personally, I came from occasional CSS, so for me, this is how things – it just make sense for me personally as I was doing things. I was like, “I want all these things to get impacted and specificity makes sense.” Because it’s all about context. Context is critical to how CSS works compared to more traditional programming paradigms.

[00:04:59] MS: It’s also responding to the first browser with real style capabilities, would've been like Netscape Navigator.

[00:05:07] BH: I haven’t heard of that in a while.

[00:05:10] MS: There was one before that, PayWay had the first browser with stylesheets but it was only available on a limited system. So, not many people used it, but Viola Browser had stylesheets before. But Netscape Navigator added like the center tag and a multi-call tag, all these tags that got added to the font tag came from Netscape. They added all these styling presentational tags to HTML, and CSS was very much a reaction to that sort of idea and saying like, “What if instead of repeating the same font over and over in every paragraph, we could select “p” for paragraph and then style all of them at once?

So, it really is that like, “Can we do it in as broad strokes as possible?” And then we’ll also add in IDs and whatever, so that we can target very specific things and do little overrides, but it’s a language that’s designed to be quick and efficient in that way. I think those early developers of the language really expected that stylesheets stay short because of it, we wouldn’t get into the situation we’re in now.

[00:06:22] T: It’s kind of funny to here that background because I feel like, with tools like Tachyon and Tailwind, it kind of feels like going back to styling tag-by-tag a little bit.

[00:06:34] MS: Yeah, I agree. I don't really get it.

[00:06:39] AC: Really? Tell me more about that.

[00:06:43] MS: Well, I’m sure there’s something to it because people like it, but I think the main advantage that I could see is just if you really want all of your code to be in one place, then if you really want it to all be tied together like that, so you just look at one thing and you see all the parts. I think people think that it helps avoid the cascade somehow? I don't really understand that. It is still all CSS in the end. It is still all cascading in the end, you're just doing one class at a time instead of one declaration at a time.

So, if you like that, okay, I don't see how I would generate patterns in the same way that I like to, that are reusable everywhere and once you start creating sort of – I mean, all the systems have sort of a way to say, “Okay. Group all these things together and make a shorter class that refers to this whole collection of classes.” And I'm like, “Yeah, that's how CSS works.” You can do that in a CSS file, but I don't know. I haven't played with it a lot. So, I don't want to totally tear it apart. I don't know.

[00:07:57] AC: You don’t want to be a hater.

[00:07:58] MS: Yeah. But it doesn't interest me. I don't see much gain from it.

[00:08:04] BH: I think for me, Tailwind in the times that I’ve used it is sort of like – this won’t get the perfect analogy for the listeners, but it’s like the typescript to the CSS world in a sense that, I think it provides some structure for people who don’t have that mental model of CSS. So, that instead of people who don’t understand things like rhythmic typescale and progressive grid systems, developers aren’t randomly adding random padding to their box sizing and that sort of thing.

So, what Tailwind, I think, does well is give teams a structured way to go. If I do px-8, that means padding on the x axis and do eight units on whatever that rhythmic scale is. I think in that regard, it gives teams that safety. But I think to your point, there are plenty of times that by the time the way Tailwind writes display flex, which by the way is like @flex. I was like, “I might as well just write display flex. This is much faster” Rather than the Tailwind utility class.

I feel like there are some pieces of it that are useful, so it doesn’t to your point take away the fact that you still need to learn the CSS.

[00:09:13] MS: Right. And actually, that was one of things that I learned quickly with developing Sass tools, because, by their nature, Sass tools are a leaky abstraction. They’re just an abstraction over CSS and what the browser sees is still the CSS, and CSS still is designed to be contextual and fall apart in these interesting ways. People would come to Sass tools sort of hoping that it would be a workaround for that. It would get them around the complexity of CSS. And that just meant that I ended up, in the issues for my projects, answering more CSS questions than Sass questions, because I’d have to explain how the underlying CSS works and that there's not really any way for us to change that, we’re just providing some shortcuts to write it.

[00:10:06] AC: So, what approach to design systems do you personally take and tell us why?

[00:10:13] MS: There’s what I like to do when I have full control and then there's what we actually do for different clients. It can vary quite dramatically because people are working in different tech stacks and actually have different needs on different teams. I think design systems have to very much be – there are processes as much as there is a product and they have to be built around how the team works.

We work in a very CSS-out sort of way or Sass-out sort of way, so we have a tool that lets us take structured content from Sass, Sass maps, which are like objects in JavaScript or something, and we can actually export them to JSON. So, we can manage everything in Sass and then export the results to JSON, and then we use an extended version of Sass doc to – we call it Herman. We named it Herman, and Herman can generate documentation from – it knows our map syntax and just generate the docs from that.

So, that's the approach we often use. I mean, that has a little bit of a weakness once you get into PrintDocument, like a view component, because the question I think with all of those tools that sort of automate documentation from something is how do you combine well, taking information from different environments, from CSS, from view HTML, whatever, and combine them all together? I don't think anybody has solved that well yet. I don't think we have and I don't think anybody else has either. There's lots of tools that do one part of it well, so things like Storybook and there are various of those. That’s the one, clients are often on when we show up and help them work on it.

They often capture the component well but don't do as good of a job with capturing global styles. They are better at the framework part and ours is better at the global styles part. Nobody has solved both of those at once yet, that I've seen. So, we end up sort of mixing and matching depending on the client and what their process looks like. The thing that I love about Sass for capturing design tokens, as Gina calls them, they’re like atoms of a design system, colors, and fonts. Sass understands what they are and that's not true of the language like JSON or YAML, which is how a lot of the other systems store that data. They’ll force everything to be a string, so you store your colors as a string, and your store your fonts as a strong, and your sizes as strings. But Sass knows what colors are and how to manipulate them. Sass knows what lengths are, and how units interact, and how to convert between them.

So, you can actually do a lot more. I think of that is like, if we’re obsessed with types and typescript sort of things, or we have all these types, why are we storing our styles in a way where we just treat everything as a string and we remove all the types? That doesn’t make sense to me. So, I love that Sass lets me actually manage these different types and then I can export the results to JSON, just for style guide generator, but where I'm actually working with it, I have all this knowledge of design types, colors, sizes, things like that.

[00:13:55] BH: Yeah, I love that. So, you’re talking about view component. So, I’m curious to get your take on the fact that, with view, unlike, CSS and JS was like the big hot thing. But we try to abstract it a bit further with scope styles in CSS modules. I’d love to hear your thoughts on those approaches to trying to manage styles across applications?

[00:14:18] MS: Scoping is a weird thing that lots of people have been trying to solve in different ways and that the W3C is also thinking about the CSS working group trying to think like, “Can we make this part of the language somehow?” And I think View Solution is pretty clever and actually similar to what a lot of the tools are doing. Sort of the problem is CSS describes well like this ancestor relationship, like something is inside of something, but anywhere inside of and the idea of scope styles is we want to create some sense of ownership.

So, not only is this link inside of the nav component, but this link is a nav link. It is part of that component. It's owned by that component and we need some way to select it specifically not just as a link inside of, but as a link that is owned by. And the View Solution, while automated behind-the-scenes, is actually very simple to do manually as well. It's just everything inside of this component gets the same class added to it or attribute added to it, and then we select everything with that attribute added to the selector. Pretty straightforward.

[00:15:29] T: The View Solution we’re talking about when styles are scoped, right?

[00:15:33] MS: Right. I think that’s a real problem that exists on the web, but it’s also a problem that’s exacerbated by the way that frameworks work, which is to say, normally, when I'm writing CSS, the order of my styles matters quite a bit in making sure that when I'm combining components and patterns to compose something more interesting out of them, I control the order of those styles and what is overwriting what based on the order. When frameworks load these styles, because they're all fragmented, there's not a specific order that they load in. So, I can't use the order of my code to express what should override what, and so it becomes even more important inside of a framework to be explicit about what belongs to what.

So, I always feel like it's solving a problem that I didn't have before, but when I'm using View, I use them regularly. I use scope styles all the time. I try to put as much as I can in the global styles because I feel like CSS is designed that way where we’re supposed to do as much as we can, as broadly as possible. But then, once I'm styling components, I'll do it all scoped because I've got that sorter problem and I don't want to deal with it, and I think View Solution is great for that. So, I don't mind it too much, but I do think it's solving a problem it created.

[00:17:05] BH: That is an excellent thought. I never even thought of it that way.

[00:17:10] AC: I had a problem where, even though like, allegedly, styles aren’t supposed to leak out of a CSS module, but it turns out if you have a cyclical dependency, you have a confirmation component that has button components, custom button components inside of it, but also the confirmation can be inside of the button component. You can create some really interesting problems, because it’s called the child and parent.

[00:17:48] MS: Wow. That sounds –

[00:17:46] AC: It took me a long time to figure out, but just by being a very specific direct child of only gets this color, that solved it. I was so frustrated by it.

[00:17:57] T: This reminds me of our Scoped Slots episode.

[00:18:00] AC: Yeah. Inception.

[00:18:05] T: Speaking of manual and automatic scoping, if I may get spicy for a bit, I would be curious to hear more about common scoping or other CSS patterns, maybe popular ones that you strongly disagree with, as well as maybe patterns or paradigms that you think don’t get enough attention?

[00:18:26] MS: I think one of the things that happened is in the push for everything to be modular, we forget the way that CSS has to be contextual. And actually, when I think about context, I think also about the way colors look different in different contexts. All those visual tricks where you take the same square and you put it in two different places and you see how different the color looks?

[00:18:55] T: This is that dress meme with the black and gold or whatever?

[00:18:58] MS: Sure. The dress meme is perfect. But all visuals are contextual and so that's like another layer of needing to think about context for everything. But part of that move included lots of what I would see as overreactions, which, like, super strict BEM. I like the ideas that BEM has. I like thinking about blocks and elements that are owned by those blocks. I mean, that’s that ownership relationship we were talking about, and then states of things. I think those are really good concepts to be thinking about, but they've taken this – we have selector specificity for a reason and it's a useful tool in our toolbox, and if we flatten everything down to a single class and then we load those in random order because we’re using a framework, we’re sort of just making this problem worse and worse by trying to avoid some of the potential pitfalls of the cascade and specificity, we end up just throwing out the whole thing and then frustrated that we don't have any tools to manage what overrides what.

Actually, we just threw away those tools. We can use them. We can use IDs, they are a little limited by the fact that they can only be used once on the page, so that's not great, but we can combine classes and that increases specificity and that's intentional. We want things that are more specific to override things that are more broadly applied. So, we can actually use selectors as they were intended, to reflect what we mean rather than flattening them all out, because somehow if we flatten them all, the cascade goes away or something.

That sort of answered the question. There is at least that sense of flattening the cascade, trying to get rid of the cascade, I think that's one that bothers me. Generally, it's things like that. It's when people put out strict rules that are sort of like, "Throw away this entire section of CSS. Don't ever use IDs. Don't ever nest your classes.” I start to think, “Okay. You're taking this language that was designed to work one way and you’re throwing away half the tools the language gives you to use it.”

[00:21:20] T: But I don’t like the tools. Make it stop.

[00:21:26] MS: I’m on it.

[00:21:30] BH: So, Miriam, I know that you recently started working on CSS spec work, which, for those of us who don't know what that is, is helping to define specifications around how the how technology is supposed to work. Think the default APIs that ship with the feature and the browser.

[00:21:44] MS: Yeah, I’m just getting started, so I'm figuring that out. I mean, these languages that we work with, the web is very much new. I mean ’89, ‘90, that's when HTML first came out. CSS was proposed in ‘94 and then sort of had a full implementation around 2000. I mean, these are new languages and still under active development.

I sent a proposal, and this actually relates to this conversation, I felt like the problem is that things are too narrow like we’re not only is BEM forcing us or asking us to use like a single class for everything, but it's hard to jump up to IDs, because they can only be used once on a page, and it's hard to go down to element selectors, because we want to use them in semantic ways and that makes him a little bit less reliable for styling beyond real basic defaults. So, we end up sort of in the classes and attributes entirely. And then our need to be specific about selecting something is so intricately tied with how – I mean, that specificity thing is clever and also sometimes it gets in the way, sometimes you want to select something very specifically but still have to be default, and you can see that. If you look at browser styles, you can dig into Firefox’s browser styles that they're implementing and they have all these big long selectors that had a right border on a specific table element, and they don't need to worry about it being so specific because it's a browser style, we override those really easily.

And I thought, “Wouldn't it be nice if we could create those layers ourselves, to say, even though this is specific, I wanted in my base styles layer and I want everything else to be able to override it easily, and I want to be able to use bootstrap or something, but I want to be able to override anything in it really easily without having IDs or whatever I'm doing to override some decision that they've made that I want different.”

So, I filed an issue on the CSS working group, GitHub, saying, “What if we could create our own layers and be more explicit about them and not only have selectors to control that layering?” And they liked the idea and they invited me to join the working group so that I could write [inaudible 00:24:24].

So, now, I’m trying to figure out how to write that spec and I’ve been working with spec writers who – I have just looked up two for years and are now working with me to help figure out what this would look like. But it’s something where we would be to say, sort of like media blocks, media query blocks or something, where we’re just able to create layers and say, “Component styles override general patterns, which override defaults, and let’s slot bootstrap into this global patterns layer, or between default and global patterns,” and we can then put overrides in another layer and have a little bit more control over what overrides what.

[00:25:12] T: So, until that spec becomes a reality, I'm curious to hear more about how, when you’re trying to debug something, you peel back the layers? Because, for example, there’s this one style that’s been haunting me for a month now, where I have a height set on dev to 48 pixels, but sometimes, it’s set to 44 pixels or something. And if I check the computer properties it says, “Oh, yeah, the 44 pixels is coming from the spot where you set the height to 48 pixels.” And so, I’m like, “Where do you go in a case like that?” Or if you have any googling tricks, how do you Google? Because, so many times I just type in height or like width, and that’s a silly thing to do, but other than tacking CSS on at the end, how do you problem solve when you run into bugs like that?

[00:26:03] MS: I mean, sometimes they are hard to find. I would say Firefox gives the best tooling for digging into that that I've seen, although I think Chrome tools have a fair amount there. I've been using Firefox more recently, but yeah, there can be weird differences between computed and what you said, because CSS is weird and designed for the browser to make decisions for you and try to guess what you were thinking.

I don't know. I mean, it's hard to say without looking at specific instances, but digging into the dev tools and the browser, and then going and looking up the property, often those sorts of differences are specific to either the property or if you're using a replaced element, like a form control, like a range slider, or something that the browser is doing a lot of work replacing your tag with a bigger chunk of something, those are where you’re going find it.

I would also go into, I think, in most browser dev tools you can turn on “show me the browser styles” and they get added to when you're inspecting an element and you're looking at all the list of rules where things come from. You can also see the ones that they are applying and sometimes they are not what you expect, and sometimes they are having an impact on something else that you set. So, all these are turned on, just so that I’m seeing everything that’s being applied to the element, not just what I’ve explicitly said. I don’t have a fix for searching. Searching is just hard.

[00:27:40] T: Maybe it would be more efficient if I just said, “This is working this way.” And then I’ll let the Internet correct me.

[00:27:46] MS: Put it on Twitter.

[00:27:48] AC: Nailed it.

[00:27:52] T: So, then, I guess moving my question to a less specific question, because going back to your point about the way frameworks interact with CSS. For example, a lot of times I feel like I’m in a situation where I’m like, “Okay, this one thing needs to be flexed, and its parent, and its grandparent, and its great grandparent, and so on don’t need to be flexed, but we’re using Tachyon. So, we’ve just reflexively put flex on everything.” So, I’m taking everything out, and it’s not behaving the way that I want, but then I feel like I don’t really have a sophisticated enough or maybe experienced enough mental model of how all of these things are combining and working together?

Miriam, I feel like you have a very elaborate mental model of how CSS works and how it all architects together. So, I was wondering if you could talk a little bit more about how you think of the layers of CSS and also how somebody can gain a better understanding of that, if that makes sense?

[00:28:53] MS: I think the layout model is, in some ways, what catches people the most, and the different layout models. Part of it is that, again, they are designed for the browser to make positive decisions for you, because unlike InDesign, where we can go back in and change it if we get a call from the client and they say, “Okay. I want it to be 3 x 5 now instead of 3 x 6.” We can just go back to InDesign and change that. But when somebody loads our site on a device that’s smaller, they don't call us up and have us redesign it for that.

So, the browser is having to make a lot of those decisions for us and all of these models are sort of around giving the browser a few guidelines, a few hints, a few constraints, and each model has a slightly different way of doing that, and all of it with a sense that we don't know the content inside of something either, right? So, not only do we not know the screen size, we don't know the content. So, some access has to be flexible and sort of unknown and that actually causes a little bit of a problem in all of the layout models because what is 100% height? And I think this is a classic place where people get stuck confused, the browser doesn't know what you mean by 100% height when height is the axis that's flexible, unless the parent has an explicit height on it.

So, there's this sort of, in the DOM, some things have to be taken from the parent if they’re going to mean anything for the child. Flexbox and Grid give us interesting ways to play with that back and forth, but it's always a thing to keep in mind when we’re using especially things like percentages that are relative to a parent. If the parent is getting its size from the child, and the child is trying to get its size from the parent, we’ve got a loop, and the browser can’t figure anything out.

That’s often where things break. It’s that trying to put 100% percent height when the parent doesn't have a height and there is no 100% to use. That’s the first place I look every time somebody has that sort of a problem. And then Flexbox and Grid, they build on normal flow. So, normal flow is what allows it to – in InDesign, if something overflows, you get a little plus in UI, I don’t know. What do you do with it? The box doesn't move for you, but the box doesn’t change sizes for you, and in CSS and HTML we have normal flow, which is actually a layout system that we just didn't really talk about because it was sort of like the air we breathe. But normal flow is we get block, and we get in line, and then we get this weird combination of in-line block, where it’s in line for the parent context and block for the child context.

So, normal flow is making a lot of decisions for us and has some of those complications with like 100% height, things like that, and Flexbox and Grid are both using the box alignment model, which is a new spec that hasn't been applied to normal flow yet, but should be, and describes all these things like justification, and alignment, that we get to use with Flexbox and Grid that are pretty cool. Where we get stretch, which sort of does that 100% height that we wanted, a line item stretch, and it’s just like fill the space, make room for the content, and then fill the space.

So, the box alignment, that's a thing to understand. Box alignment is what solves this. Everybody talks about how vertical centering was so hard or something, box alignment is what solves that completely and makes it go away. And then Flexbox and Grid rely on it and give us these concepts of content and items. So, the content being the box around everything and items being the individual pieces. Flexbox is designed for the individual items to converse with each other and figure out a way to share this space, sort of a very inside-out model, so you figure it out, here's some guidelines for figuring out, how to share space based on your sizes, flex in these ways to it figure out.

And then Grid is the outside-in approach. It’s the, I have a layout, I want you to fit in it, and I'll respect your content sizes to some degree, but the layout is coming from outside and we’re imposing the layout. Again, people like to have one solution. So, people will sort of make-up rules of, like, Flexbox is more supported so use Flexbox only, or Grid is cooler so use Grid only and we don’t need Flexbox anymore. I think, okay, this is another of those cases where I actually heard somebody say that their teacher had told them never to use floats now that Flexbox is available. And I thought, “Well, that’s just absurd.” Use floats for floating things. Things that need to float.

We have all these different concepts and people tend to want one of them and then use that one to do all the things. Really, CSS, going back to that contextual nature and that browsers making decisions for us, CSS is all about communicating meaningfully to the browser how to make smart decisions for us. So, telling it, this is a flex situation, or this is a grid situation, or this is a float situation is meaningful information that the browser can use to make decisions on our behalf in contexts we haven't thought about.

My key to writing CSS is always try to convey as much information as we can to the browser in small ways. Ems are different from rems are different from pixels. These are types that have meanings, and that the browser uses to establish relationships between things, and if we start to think that they're all the same and we can use them interchangeably, we've lost that meaningfulness of expressing hints and suggestions to the browser about how to be smart on our behalf.

I think I maybe went way off topic there, but hopefully that got a little bit to your question.

[00:35:18] T: Well, speaking of layouts, I’m a bit curious about, with what I feel like is the holy grail of layouts, which isn’t – I think there’s one called the holy grail layout, but I’m thinking more about the masonry layout. I’m curious about why that is a tough one to build. What kind of problems encompass it? Why do people want it so much, and why is it such a difficult thing to achieve?

[00:35:41] BH: Before you answer that, what is the masonry layout for those who might not be familiar with it?

[00:35:46] MS: So, the masonry layout is sort of like multi-columns. You get several columns, but instead of filling them up one column at a time, down the column, down the next column, you fill them up across the columns, and then you stack inside of each. But it’s not a grid, because in a grid everything aligns on both axis, and in the masonry layout, you want everything to slot into place, so they are only aligned on one axis. It’s sort of Grid on one axis, Flexbox on the other axis, is kind of what you're trying to do. There's actually a spec for it now, and Firefox has implemented, in Firefox Nightly, maybe it's made it to other versions of Firefox at this point, I'm not sure. But you can go play with it. Jen Simmons has some really beautiful demos. It's being implemented.

I’d say, one of the hardest things about it – I mean, it’s hard to fake on the web because it’s dealing with so many unknowns, unknown sizes of things and how are you going to slot them into place and you kind of need a built-in tool to get it right without lots of JavaScript moving things around, which is bulky and a bit of a hack.

[00:37:03] AC: I’ve never done that.

[00:37:05] MS: No, I’m sure. From a UX perspective, there's sort of a big problem in that, when you start rearranging things, tab orders get weird and the source order is all over the place and you run into lots of accessibility issues. It’s already possible to create those issues with Grid and Flexbox and the order property, but it’s sort of like built into the masonry layout, is that you’re going to be tabbing across, and then you’re going to jump way down, and then they’re going to jump back up. So, there's a bit of a problem there that I'm not sure has been solved, but, yeah, get other browsers to implement it, and you have masonry basically in grids, and you basically just describe one of your axes as being masonry, and it just works. It's pretty cool and easy and not like loading an entire JavaScript library to figure it out for you.

[00:38:07] AC: See, I just manipulate the content first. I’m just like, “Okay. Split this array and evens here, odds here, evens go in this column, odds go in this column.”

[00:38:16] MS: Clever.

[00:38:18] T: I’m sure nothing funny will happen if I just crop all my content automatically.

[00:38:22] AC: Yeah. That will only work specifically. I have totally have done that, because I was on a situation where I had items that in their default state were all the same height, but then you had the option to have an informational comment slide out from it, and that was when I was like, “Oh, crap. Now what do I do?” You don’t want the other column to go with it, because that just looks weird, because it’s just like a giant empty space. “I’ll just make it so I have two arrays instead of one.” Done. But now, I just realized that there’s huge accessibility issues there, however, I no longer work at that job, so, not my problem.

[00:39:08] MS: Yeah, do whatever and then leave.

[00:39:14] AC: It works.

[00:39:16] MS: Yup.

[00:39:17] T: So, maybe, I’m going even more too general now, but the more we talk about specs, the more I’m curious what exactly CSS is? When you come up with a new spec or when I run CSS, is it made of CSS? How does it work?

[00:39:34] MS: Each browser implements it however they want. So, CSS is just the spec. It's the set of rules for how it should work when you combine these properties with these values, here's what the browser should do with it. The first CSS spec sort of just described the positives, the best-case scenario, and that ended up being a problem in the first CSS spec.

Very quickly, the second specs and on, they’ve been working really hard to describe how it should fail when it doesn’t do what you want, let's make sure that all the browsers are failing in the same way too, that they all break the same, so that that’s predictable. But it really it’s just that set of rules.

[00:40:22] AC: That sounds really hard.

[00:40:23] MS: I agree. Part of the process is browsers implementing it. A spec isn't complete until several browsers have implemented, so that they can work out those bugs because, there's always – I mean, watching the spec process, it's like spec writers put out everything they can think of, all the rules they can think of for how this should work. Browsers start to implement it, and they come back and they say – one of the conversations last year, earlier in the year sometime, was like, what’s the width of the box that’s not rendered? And browsers have to care about that. They have to care about the width of a box that’s not rendered.

Not something I had thought about a lot, but then, that sort of thing ends up in the specification so that all browsers agree on the width of the box that’s not rendered.

[00:41:15] T: So, if I write a recipe or something, with one of those long stories about my childhood, and then I give it to the browser, and hope that the browser doesn’t make too many improvisations or ingredient replacements.

[00:41:27] MS: Well, they do tend to improvise in those first drafts and come back and say, “How about we do this?” The first draft of the spec, even once it's been approved by the working group, is never done until browsers have implemented it and said, “Here's all the problems. Here's all the things we’re changing.” And then, if browsers refuse to implement something, they’ll go back and change the spec to match what browsers did, if the browsers can agree, so that in the end, the two agree but it's a back and forth to get there.

[00:42:01] T: I remember hearing Jake Archibald talk about how he thinks that the arguments for set timeout are backwards, the timeout should come first and then the function that you pass it. I’m curious if, in CSS, there are things like that where you feel like it was just implemented intuitively or a wrong way, you would have done it differently?

[00:42:18] MS: Yeah. Actually, Tab and Elica, two of the main spec writers these days, maintain a page of everything that's broken in CSS that they wish they could change and it's a great page. We can link it in the notes here, I’ll go find it. But yeah, it’s a lot of fun to read through all the things they wish were different. Often, you can’t get rid of things, but sometimes, you can sort of replace them and hope that the old version goes away.

One of those is that’s starting to be implemented now but doesn't have broad support yet, is being more clear that display does two things. So, like I mentioned inline block, inline is for how an element acts in its parent context, and then block for how it acts as a parent, the context it creates. So, we’re moving towards a two-value display where we actually set those explicitly. So, flow becomes an option and we can return things. Display block right now would become display block flow, to be explicit, if you want it to be explicit, block would still work and flow would be the default for how it acts internally. But then we can be even – we can start combining them in new ways. We can say, inline list item, or list item flow, or list item grid, start combining how an element behaves in one context in the context that it creates.

So, some of those things are happening slowly. Similarly, we’re getting flow relative margins and padding and things like that, like margin inline start, margin block end, where we’re describing how margins and padding are attached, based on the flow of the document. And then if you changed your document left to right, right to left, all those would switch with it. So, that's a pretty cool thing to – there’s a lot of things like that, maybe we wouldn't have had physical properties in the first place. I don't know, maybe we could have gone straight to flow relative, but having both is maybe cool too, we’ll see.

[00:44:30] T: While we’re talking about CSS bad, I’m curious what is either the worst thing anyone has ever done in CSS or the worst bug everybody has encountered, and then, to balance it out, maybe something that you’re proud of?

[00:44:43] AC: Can it be something I allowed someone else to do and just went with it?

[00:44:47] T: Yeah, totally.

[00:44:49] AC: Float-based layouts everywhere in 2018.

[00:44:53] MS: In 2018?

[00:44:55] AC: Yup.

[00:44:56] MS: Wow. Congratulations.

[00:44:58] AC: Yeah. So, once that person left, it was a lot of refactoring on my part. A lot. But actually, that was really satisfying. Those variables are some of the most satisfying CSS work I’ve ever done, is just converting all the float-based layouts for Grid and or Flexbox, because I’m just like, “Yeah. I’m awesome.”

[00:45:22] T: That’s great. So, it’s both your worst and your best?

[00:45:25] AC: Yes.

[00:45:27] BH: I think my worst CSS stories come from inheriting a freelancer’s design of a WordPress theme and finding out like, I just wanted to change a link color, and I’m not exaggerating, I think it was seven selectors with two IDs in those selectors, and an important I think of this clusterfork. That was unnecessary which is why I agree with Miriam in that, selector should be used in a way to provide context, but then when people just use it as a way to just slack on something, that’s when the architecture just falls apart. I know that’s why specificity is more an art and less of a science. Why some people want those hard and fast rules of everything is flat. Those I do not relish. Don’t think of those memories.

[00:46:14] MS: I think my worst was probably the height of maintaining Susy. I was using it in ways that I'm not proud of. So, Susy was a float-based grid system. I mean, it was basically just there to do all the math of fluid grids, getting the percentages right so you could fit gutters in. Gutters are the problem with fluid grids, that Grid fixes for us and Flexbox now too once that’s implemented everywhere.

I just remember one project we are working on, it was sort of the first really big client we had. I think it was Mozilla we were working for, and we had all these forms that we were laying out, and I like hand coded the layout of each one. Looking back, I’m like, all needed was – there were probably three patterns in there, and I could've named three layouts, and then just slotted my form fields into them and it would've been fine. Instead, each form on each page had its own specific selectors and specific layout, all of them in Susy. And it actually took a couple years later Claudina Sarahe joined our team, and she looked at the way I was using Susy, and she was like, “We don’t need this anymore.” I was like, “Oh. You’re right. We don’t need this.”

There’s actually a thing there of responsive web design taught us to remove all intrinsic sizes and put a percentage on everything, everything is fluid. If you’ve ever heard Jen Simmons talk about intrinsic design, she's trying to push back on that one aspect of responsive. We now have the tools to let things have intrinsic sizes, and work from those intrinsic sizes, using min content, max content, mixing fluid and fixed. We can let images have a fixed size and still make a site fluid around them. We have to learn to sort of put different units back into our work now that we stripped out when we were doing. That was a big part of what Claudina was pointing out, was that I was forcing these grids onto systems that didn't really needed grid. We could just do Flexbox and let the form fields share some space, and if there's always three form fields, they will always share the same space and it's like a grid. We’re fine. We don't need to force it here and that sort of letting go is important.

I went on a tangent again, but the best thing, I think there's one that I always remember, where somebody was trying to do something that looked kind of just impossible and I figured out that, just with a couple media queries, these elements need to flow attached to something at big screens and then attack just something else in small screens in different ways. I don't know. I've just always been proud of the solution I found for them with like a couple media queries to completely change how the layout was working, but look like nothing changed. It gets here and then it moves with this, and then it gets here and it moves with that, and I was like, “Yeah, those are fun.”

Actually, a recent one, similar idea, it's those sorts of things but figuring out that like min/max and fractions move at different times. Jen Simmons talks about that a lot with CSS grids, the min/max expands first. I think it’s auto first, and then min/max, and then fractions. So, you can do these really interesting layouts where first this grows, and then that grows, and then a third thing grows. If you start adding in the actual, the new min and max functions inside of min/max, you can get even more complicated grid, like this grows until it’s half the screen. And then, it keeps growing as half the screen to a certain size and then it stops at a certain point and something else grows instead, and you can do this like without any media queries, get these totally flexible layouts and I played with that for a demo. I was like, “Woah, this is so cool.” And I have not put it in anything, but it’s like one of my proudest.

[00:50:46] T: That’s awesome.

[00:50:48] MS: CSS toys, yeah.

[00:50:47] T: That reminds me of one of your workshops or something, when you were in New York for that conference. I think you’ve mentioned – those are something in my head, I thought. Well, what even as a pixel? And I think it’s a throwaway comment, you just said, “I mean, what even is a pixel?” And then you’re like, “That’s a story for another time.” And I was like, “Oh, no.” Then my mind just spiraled away.

[00:51:07] MS: Yeah, what is a pixel? I don’t know. You can find all the specs that describe all the different meanings of a pixel.

[00:51:17] AC: Well, I think that’s a good philosophical place to start wrapping up.

[00:51:21] T: Yeah, that’s fine. I don’t need to share my worst CSS story, it’s okay, classic –

[00:51:25] BH: No, we want it.

[00:51:28] T: It’s really bad.

[00:51:29] AC: You asked the question, you have to answer it.

[00:51:32] BH: That is true.

[00:51:31] T: So, when I was at the coding school, for a project, my group used this CSS library called Materialize, but we were having a really hard time overwriting the styles and we couldn’t figure out why. But after a few hours of investigating, I finally figured out the problem and it was that they had – actually, maybe it wasn't Materialize, I’m just going hedge in case I’m remembering wrong, but there’s important, everywhere, not consistently but just randomly in certain places, there would be an important.

So, I figured out how to override it, I just had to go into the file and then change the CSS and then commit the changes, and then somebody else will pull down the repo and MPM run, or whatever, because I don’t think Yarn was a thing yet. And everything will go away. So, mysterious. It’s like being a ghost in the shell, or I don’t know. That was really bad. So, that’s probably my worst CSS thing.

[00:52:25] MS: At least you were committing the changes and not just like logging into the production server. Changing it live.

[00:52:35] T: But it’s also possible that we ignored node modules and I wasn’t even committing anything, who knows. And maybe the proudest thing I did was we had this problem where we had – we called them tabs, but they look like pills at the top of the page, and when you select one, it bolds. But when it bolds, it horizontally shifts all the other tabs because its width changes. I looked it up and I saw the solution to use text shadow or something as a border, and it didn’t look amazing, but we didn’t need it to be too bold. So, I fixed it. Although, now, maybe it’s coming out because it looks fuzzy on my boss’ gigantic monitor. But I was really happy that I fixed this tiny thing that nobody noticed or was bothered by except for me.

[00:53:16.0] AC: I’ve literally given up on something like that before, because I was like, “I don’t know how to fix this and the fact that the width is changing is bothering me.” So, we’re just not going to bold it.

[00:53:26] MS: I think the amount of space fonts are the fix. Let’s find a nice amount of space that we can use for our chicklets, whatever we’re calling them.

[00:53:36] AC: Well, some of us have to use Roboto for everything.

[00:53:40] T: That’s just when you don’t have Helvetica free, right?

[00:53:47] AC: Okay, and with that, where can people find you on the internet?

[00:53:51] MS: Oddbird.net or miriamsuzanne.com or the Twitter, @mirisuzanne. I don’t actually like Miri.

[00:54:00] AC: So, don’t do that.

[00:54:04] MS: But Mary Suzanne is my handle. So, you can use it.

[00:54:09] AC: Okay. Well, let’s move on to picks. Ben, you don’t get to go first this week. Tessa?

[00:54:15] T: Okay.

[00:54:17] AC: Steal his picks.

[00:54:22] T: My first pick is that some online friends and acquaintances figured out how to run a local instance of the platform game Among Us remotely. So, Tyranny Siren wrote a little gist if people are interested in trying that out, because their servers are kind of overloaded. So, this is a nice way around that.

For my second, I wanted to recommend Susy, but I was sure that Mia would pick it and I didn’t want to steal that away from her. So, I decided that I wanted to recommend the Mozilla Developer videos that she mentioned earlier. I think I marathoned most of them a couple months ago, and at my last job, I heard so many good things about the Firefox dev tools, but when I opened it, I was like, “Oh, this is scary.” The videos are really fun because they show you some common problems you might want to fix and then they walk you through it with the Firefox dev tools. So, now I use them a lot more comfortably.

And then my third pick is another alumnus from my school, his co-worker made this CSS card game for – I guess, you each get a card with CSS specificity on it, and you had to guess which card trumps the other card, and I haven’t played it yet, because I just saw it. I thought it seems really fun.

[00:55:32] AC: I mean, it sounds like it would make you a much better CSS developer at the end, but I feel like the first few times playing the game, it would be like, “Part A?”

[00:55:45] MS: Here’s a specificity trick. Don’t try to do lots of complex math, adding up all the different parts of the selector. You can look at one column at a time. So, you can just count the number of IDs, and if anything wins, you can ditch everything else.

[00:55:58] AC: Okay.

[00:55:58] MS: They’re in separate layers, so no number of classes will beat an ID and no number of elements will beat a class. So, you can just sort of count one column at a time. How many IDs, if there’s a tie, then we’ll look at classes and attributes. If there’s a tie, we can move on. But you don’t need to like add them all together.

[00:56:22] TS: Also, on that note, a tip I saw from Jonathan Silvestre on Twitter last night was like, in VS code, if you hover over your style, the tooltip tells you the specificity.

[00:56:33] AC: I wished I had figured that one out a lot sooner than I did, but good pro tip.

[00:56:38] T: I don’t know how I would apply those numbers, but I’m glad to know it’s there. I feel reassured.

[00:56:44] AC: Trust me. When you have a specificity problem, you’ll know, and you’ll be looking for anything to help you figure it out. Not that I’ve had that problem, because I’m perfect.

[00:56:59] MS: If you never have specificity problems, you're not really using CSS.

[00:57:03] T: Good. I feel much better now.

[00:57:06.0] AC: All right, Ben, what do you have for us this week?

[00:57:10] BH: Yeah, so I have two picks. One, I know in quarantine, a lot of us are sort of relegated inside. We’re either sitting a lot and so, I don’t about you all, but when the back feels a bit odd or muscle pain. In the past, you might go get a massage or something to like relax at a spa date. So, it’s not really possible with quarantine and COVID, I learned about massage guns. This is the kind of thing you would get at physical therapy, and basically, they’re like percussion where they basically help to loosen up muscles and you can use it on your own.

So, they’re kind of like massage tools, but again, it’s a little bit on the higher end side. But I found that it’s actually super useful for just sort of loosening out that tension. One I would recommend is the Theragun. It’s a little bit pricey, but again, just from a health perspective, what you might pay once you have a back problem and stuff. I think it’s 100% worth it.

[00:57:57] T: Before we go on, just elaborate on like what makes it a gun? Does it like shoot a massage at you?

[00:58:07] BH: Yes. It’s called Theragun, but really, it does the percussive motion where it sort of beats on the muscle, back and forth motion.

[00:58:15] AC: Oscillates?

[00:58:17] BH: Yeah, it oscillates. It’s just like a hammer but it has a rubber piece to it, so it’s not obviously painful and you can change the – okay, we’re moving on from this.

My second pick is a music pick. It’s by Zedd and Jasmine Thompson. It’s a song called Funny. Once you listen to the song, I would totally recommend checking out the music video as well, because music videos in the time of COVID, it’s kind of interesting to see how artists collaborate. So, they do a really cute sort of narrative the two artist and how they kind of put the song together. I totally recommend checking out the video once you’ve listened to the song. And those are my picks for this week.

[00:59:08] T: So, you have to listen to the song first and then watch the video?

[00:59:11] BH: I just think it would give you some context on what the song is about and that way, when you see like the narrative they composed with the video, you can appreciate it a little bit more.

[00:59:20] AC: Okay. All right, Mia, your turn.

[00:59:22] MS: Yeah, I don’t know how many I get, but I have a few – I came in with none. I’ve got a few ideas now. So, Style Stages by Stephanie Eckles is sort of a modern take on the CSS Zen Garden if you remember that back in the day, where she gives you an HTML file and you write any styles you want and there's already a whole lot there but it's a fun exercise if you want to play with CSS and what it can do and you can go look at all of the different stylesheets people have put on the same HTML file.

[00:59:54] T: I feel bad about myself.

[00:59:56] MS: Why is that?

[00:59:57] T: I don’t know. I remember CSS Zen Garden, it’s like, “Oh, I could never do that.” But then I did look at a couple of them and then I was like, “they’re cheating”, but still, I could never do that.

[01:00:07] MS: Well, there’s probably one ugly one in there somewhere, go find that one, feel better by yourself. I don’t know. It’s a fun little playground.

The Layout Land videos by Jen Simmons, I feel like anything I mentioned here today, she probably has an in-depth video series on it and her work is just so great. So, check out Layout Land videos if you want to learn more CSS stuff. My distraction during COVID, one of the distractions that I found helpful, is my partner and I have been trying to learn sign language online and through Bill Vicars’ videos, lifeprint.com. It’s such an interesting language and he's a great teacher, so been spending a lot there. and it’s nice.

The last one that I had was just the world is hard right now and I read Angela Davis, Freedom Is a Constant Struggle and it does such a good job. It came out I think not long after Ferguson and it does such a good job putting all of these movements in the global context, and the generational context, and I think I needed that sort of framework for not just feeling like everything is falling apart. So, I highly recommend it.

It’s also frustrating because things aren't good, but she’s so intersectional and so good at expressing that context. So, if that sort of thing is helpful to you, I highly recommend that book

[01:01:45] AC: Okay. I guess it’s my turn now. My pick this week is a song and if you actually took my advice on one of my picks a couple of few weeks ago, you’ve already this song, because it was in Freak Show, which was the Netflix movie, that’s where I heard it and I just immediately fell in love with this song. It’s called Queen by Perfume Genius. There's a line in it that I just love so much, “no family is safe when I sashay”, just like the mental imagery is just so fantastic with that. So, that’s my pick and that means that that is all for this week's episode.

So, thanks for listening. Until next time, Enjoy the Vue.

[END]