Show Notes

This episode is made possible thanks to my sponsors, help me continue to make contributions to the web by sponsoring my work.

Socials

You can follow Mia on Bluesky: @mia.codes or Mastodon: @mia@front-end.social

You can follow Lola on Bluesky: lolaodelola.bsky .social and Mastodon: mastodon.social/@lolaodelola

Episode Links

• MDN Cascade Layers Tutorial
• MDN Cascade Layers Documentation
• Cascade Layers Specification
• The Web and the Digital Divide Talk
• Dokeli
• CSS Fails
• Odd Bird
• Odd Bird Open Collective

Transcript

[00:00:04] Welcome to this month's What the spec. In this episode, I'm joined by Miriam, Suzanne, and we talk about the history of CSS cascade layers and how the cascade communicates power. Before that, though, I just wanna say a massive thank you to everybody who listened to the last episode. It did even better than episode one.

[00:00:24] If you haven't heard the last two episodes, add them to your queue and go back to them when you're finished with this one. This show is made possible by the generosity of listeners like yourself. I couldn't do this without you. If you'd like to donate, visit give.lolaslab.co. Thank you, now onto the episode.

[00:00:47] Lola: So today we have Miriam, Suzanne joining us. She is the a CSS extraordinaire. I was gonna say the CSS extraordinaire, but I don't think that would be fair.

[00:00:59] Mia: No.

[00:01:01] Lola: She's a CSS extraordinaire and she is going to be talking to us today about, hopefully a bunch of things, but primarily cascade layers, which I'm super excited to get into. Miriam, how are you?

[00:01:14] Mia: Oh, I'm doing okay. Thanks so much for having me. It's great to be here.

[00:01:19] Lola: Yeah, thank you for joining me. Uh, and just for listeners, um, Miriam hasn't actually heard any of the episodes that have come out before this because they haven't come out yet. So I'm very grateful for her and also everybody else who comes on the podcast without hearing, uh, previous episodes. Hopefully they're good.

[00:01:39] Mia: I'm real excited to hear them.

[00:01:41] Lola: Cool. So before we get into, cascades and like the technical stuff, it'll be really good to know more about you. And I kind of wanted to avoid having you retell your origin story again. I've heard a few different podcasts and

[00:02:00] talks where you've gone into things and I, I don't doubt that you will retell some bits, but I did wanna come at this from a different angle.

[00:02:07] So I know that you got into standards and spec writing because you were, creating a bunch of tutorials for Jen Simmons. Uh, and that's also how I got into standards. I got into standards also through education, like through the teaching aspects of it. And I wanted to know from your perspective, how has , teaching coding CSS helped you in developing web standards and specifications?

[00:02:36] Mia: Yeah, that's interesting. There's several of us in the CSS working group that have that background. Um, I mean, Jen Simmons is also in there and, uh, and several others, um, who do a lot of teaching and it comes up fairly regularly, even in group discussions of, uh, when we're considering different approaches to solving a

[00:03:00] problem, we'll often talk about how teachable the, the solution is,

[00:03:06] Lola: Yeah.

[00:03:07] Mia: how teachable the different options are.

[00:03:09] Um, which is, yeah, I haven't really thought about before that. That's maybe a strange way to approach it. But, um, I think it is helpful because we want people to be able to pick things up easily , when new features come out.

[00:03:26] Lola: yeah. That makes sense. I guess like as well, when it comes to thinking about how to write, something that's highly technical in a way that people can understand as easy as possible without also losing the technical detail as well.

[00:03:44] Mia: right. That's true. That's true. Yeah. And I think there's something about, um, like if, if you can teach it easily, hopefully also it's readable, like the, the,

[00:04:00] the code. Yeah. Somebody can come along later and understand it.

[00:04:05] Lola: It's interesting because, um, earlier, uh, this year in March we had the tag face-to-face in Paris, and as part of that we had a developer meetup and there was somebody there whose name I've forgotten unfortunately, but he used to be heavily involved in the W3C and I, I think he did serve on TAG for a period of time.

[00:04:27] And he noted that it seems that the W3C is moving in a direction that wants to be more inclusive to developers. Where earlier on it was understood that the primary audience of these documents are implementers that is browsers, um, and maybe other kinds of implementers as well, but not developers as a primary audience.

[00:04:52] And it seems that that is shifting and I think the CSS working group is a good example of where we see a lot of

[00:05:00] web developer input and participation, and I wonder if that's also related into how these specs are, the kind of angle, as you mentioned, like quite a few people come from a teaching education background, and I wonder if that contributes to making both the working group and the specifications a bit more accessible compared to other working group documents.

[00:05:26] Mia: Yeah, I imagine that's related, but it's interesting um, a lot of the pressure for that is from fantasai,

[00:05:33] Lola: Yeah.

[00:05:34] Mia: who, uh, her background is mainly, she went directly into specs and implementation.

[00:05:42] Lola: Yeah.

[00:05:44] Mia: and she occasionally gives talks or something, but I don't think teaching is her main thing, but she is.

[00:05:50] She is adamant, uh, and, and really helpful in, uh, onboarding new people who are starting to write CSS

[00:06:00] specifications. Um, but I think that's great that she has, she has an eye for that and a concern about that, uh, about making sure that specs are written for authors to read. Um,

[00:06:13] Lola: I think that's really, really good. Um, and I, I guess I do have a question then about the kind of process that new people coming into the CSS working group go through. Um, for working groups I've joined, it's really just a trial by fire, but in a nice way. Uh, there isn't like an official process or an official, like this is how things work.

[00:06:37] You kind of attend the meetings and get the hang of it. Um, and of course you can ask for help, but help isn't always, it's not always obvious that you can ask for help, I should say. Right. Like, if you ask for help, somebody will definitely help you. But I think for new people, it's not always clear that you can do that.

[00:06:54] And so in your experience, how was the ramping up,

[00:07:00] uh, into contributing specifications, especially having come from not doing that at all into like creating, being an editor of several?

[00:07:13] Mia: Yeah. Um, it was terrifying, um, uh, because I did think of specs as something that are mostly about implementers when I was starting to work on it from the outside, that's what I assumed a spec was. And I have no experience working on a browser engine so I, I felt very unqualified, to do it. And I don't know how it got to be that, the other, the other authors on Cascade, and I don't actually remember right now who all is authors on which specs or editors but, you know, Florian was very excited to help and Elika was very excited to help, and Tab Atkins has been helpful.

[00:08:00] Um, and I don't know if I reached out for that help or if people were just sort of interested in, in offering it, um, or interested in that spec in particular.

[00:08:14] And the first spec that I worked on was Cascade Layers uh, and there was clearly sort of an excitement in the group about it um, and so that might have helped, uh, that other people were

[00:08:29] Lola: Wanted to do it. Yeah.

[00:08:31] Mia: And the initial proposal was very vague. I wrote up the initial proposal for it and I hadn't spent any time solving the problem.

[00:08:39] I just said, here's a problem I see, I think, I think we could do something in this direction. Um, and so that also left it very open to lots of people jumping in and, um, and I'm glad my first spec went that way,

[00:08:56] Lola: that's like the ideal way.

[00:08:58] Mia: Yeah, it meant I had a

[00:09:00] real team to work with and, uh, didn't feel so alone on it.

[00:09:04] Lola: I think that is, definitely the ideal way of, contributing Something can go, especially as you came into without a solution or like a concrete solution, but rather it was like, this is a thing I see and how can we, what can we do about this thing that I see.

[00:09:23] Mia: Right.

[00:09:24] Lola: Yeah, I, I, that's a really interesting way to approach things because I think typically the assumption is that when you are making a proposal, you are coming with a solution.

[00:09:36] You're saying, this is the problem and this is my proposed solution. What do you think about this solution?

[00:09:42] Mia: Yeah. And I guess, you know, in some ways I was gesturing in the direction of a solution. I sort of said, I think, I think we can learn from the way that cascade origins work. I think there's something we can, uh, we can mimic there. Um, but I didn't have a syntax or,

[00:10:00] or any of the details worked out. So yeah, there's sort of like a, a, I don't know, a line that you walk there of like, gesturing towards a way that we can do something, but without having it all solved, coming in.

[00:10:16] Lola: Yeah. So speaking of Cascade, I think that's like a really nice, uh, segue into the main topic today. Um, and I'm going to ask a question that is very rudimentary, and this is just so that our listeners are on the same page. What is the cascade in CSS?

[00:10:37] Mia: Uh, good question. Um, yeah. So, uh, early browsers had styles, um, but they all came from the browser or then users could set some preferences, so they came from the browser and the user, whoever's surfing, but they didn't have author styles and there was sort of this

[00:11:00] problem when when Mosaic added images, frankly, without asking anybody, um, where suddenly author styles were possible if you put everything inside of images, uh, and that was seen as really dangerous, uh, we're gonna lose everything that makes the web, I don't know, uh, controllable by the user, uh, adaptive to different contexts. If we lose everything that's special about this medium and we just start sending, I think Hokum Lee who, uh, proposed CSS said there was a real danger of the web becoming a fax machine, where we just send, send pictures back and forth.

[00:11:41] Lola: Yeah,

[00:11:43] Mia: So there's sort of a race to figure out how are we gonna allow authors to provide styles, but in a way that will still work on, you know, some screens don't have different colors, some computers don't have different fonts.

[00:12:00] Uh, different screens are different sizes, we don't know what size they are. So how are we going to allow authors to provide some styling but in a way that the browser can override and adapt to a, a system and the user can set their preferences and make the font bigger when they need to, or whatever else.

[00:12:22] Um, and the cascade was a way of solving that problem. And the way that term is first used in the first proposal is just that we're going to allow users, authors, and browsers to all provide style sheets , and that means we'll get a list of styles, a list of style sheets or, a cascade , we get a cascade of styles.

[00:12:50] But then the problem is if we can all style the same things, we have to

[00:12:55] Lola: who, who has the power? Yeah.

[00:12:57] Mia: who has the power. Exactly. So what we call the

[00:13:00] cascade now is the algorithm for determining which style applies when there's conflicts.

[00:13:07] Lola: Mm

[00:13:07] Mia: Uh, and there are seven plus steps, uh, seven or eight, I don't remember, um, in that algorithm.

[00:13:16] And then sort of internal steps inside of those. Uh, it's this whole, whole process for determining a winner when we have conflicts.

[00:13:25] Lola: Thank you for that. And just so folks listening know, CSS stands for Cascade Style Sheet. So the CSS language is based around the cascade.

[00:13:38] Mia: Right. Sort of in my mind, it's why this proposal wins. There's something like 15 proposals you can go look at that are still on the W3C website for how we, how we might style the web. Um, and the cascade is really what stands out about this proposal.

[00:13:57] Lola: I think it's interesting that we came

[00:14:00] from a place of we don't want to allow, um, authors slash uh, web developers power to style because we wanna make sure the user maintains that power and always has that power. And now we're in a position where it seems like, and this is, this is just from my perspective, where it seems like the web developer has the most power, and I guess the browser to a certain extent in terms of styling. Um, and in terms of determining how a user sees something, to the point where sometimes it's difficult for users to define how they want to see the webpage.

[00:14:44] Mia: Yeah. Yes, I agree completely. And I think, you know, there's different parts to that. Part of it is that, um, the web over time has become the main way that we do business. Uh,

[00:15:00] and, uh, users being able to override your brand is not considered standard business practice.

[00:15:08] Lola: Yeah.

[00:15:09] Mia: Um, that's not something companies are generally looking

[00:15:12] Lola: They don't want that. No.

[00:15:13] Mia: Yeah. So, uh, we've got all these big companies sort of driving a lot of features on the web and driving a lot of what web design is today. Um, and that's not always the priority they're looking at.

[00:15:28] Lola: Yeah, it's so funny because I think most web users probably wouldn't even know they could define how-- when I first started learning to code, um, I did a bootcamp and I think on the very first day or one of the early days, our, like instructor made us go into the dev tools and completely like rewrite Facebook's logo or something, or like change their background and that blew my mind. I was like, oh my God.

[00:15:57] Mia: That a good assignment, I love that.

[00:15:59] Lola: Yeah. I

[00:16:00] was like, oh my goodness, I didn't realize I had all this power. Like, I didn't realize I could do this, right? And I could make Facebook say my name instead of Facebook, and now the brand colors are pink and purple and blue is nowhere to be seen, you know, you know, so, uh, I, I think even the fact that many don't know that this is something that's possible is in and of itself a consequence of, as you said, like the web being more for business now, you know, it pays, it's beneficial to, um, the powers that be that we don't know, the ignorance is beneficial.

[00:16:43] Mia: Yeah. Yeah. And I would say there is also some sort of increased complexity and like, like it's not that it would be an easy problem to solve because sort of the initial proposals assume that everybody, the styles you're providing are for

[00:17:00] like links. So we can all select links and say what styles we want but now websites don't just have a link style they have a, uh, a featured link and uh, you know, and every site has their own different things on the page that they're styling in unique ways. Um, and so it's a little harder to think, how would I, as a user say, this is what I think links should look like even though you're doing 15 different things with links.

[00:17:31] Uh, how , how can I provide styles that are gonna make sense on your site? And I think there would be ways to solve that problem if people considered it more of a priority but it has gotten more complicated, so I understand also why browsers have maybe not wanted to lean into solving that.

[00:17:50] Lola: The web in general has gotten more, significantly more complicated since its inception so definitely not trying to,

[00:18:00] uh, make it sound as easy as possible, 'because even when we think about, you know, accessibility considerations and just ensuring that, um, you know, people can zoom in a text to as big as they need it, um, even that in and of itself is, can be contentious, you know. It can be more complicated than we realize, it shouldn't be, but it can be.

[00:18:27] But just to bring things back to the cascade then, so you mentioned that this is kind of like a way of, um, saying, okay, everyone can define a style and it runs in a cascade, and then the cascade then is like an order of priority, right?

[00:18:43] So in, in it being a cascade, the thing at the bottom takes precedence. So if you define a style at the top of the cascade, it will get overwritten if it's redefined somewhere later in the cascade.

[00:18:59] Mia: Yeah, that's,

[00:19:00] uh, the final step of the cascade and sort of the last tie-breaker, um, if you want to think of it that way, it's the simplest one because there's always one answer.

[00:19:08] In every other step of the cascade, you might still get several conflicting things that are all from the same origin or from the same layer, from, have the same specificity, but at the end, there will always be one thing that came last.

[00:19:23] Lola: Yeah.

[00:19:24] Mia: Uh, and so it, it works as a final step to say, this is the winner.

[00:19:29] Lola: And so Cascade Layers then is different from the Cascade as we've been talking about it. The Cascade, as we've been talking about it, has been essentially the CSS language but Cascade Layers is something different within CSS. And so what problem was Cascade Layers trying to solve? Um, and then we can go into what it actually is.

[00:19:52] Mia: Right. So the steps of the cascade, uh, it starts with origin. It starts with does the style come from the user or the browser or the

[00:20:00] author and there's some complexity there around importance, which we can get into. But, um, then, uh, there's a few other steps related to like context and inline styles, but we get to specificity and that's sort of the one that a lot of authors think of as the cascade 'cause it's the place where we have the most control, where we can say, I'm using an ID selector, or I'm using a class selector and these have different specificity.

[00:20:28] Lola: Yeah.

[00:20:28] Mia: so I have some say in what overrides what without relying only on the order of things, uh, which is I think a clever idea but there's a few issues there.

[00:20:42] It's sort of two things are being linked, how we select things, how we name things, and also how important those things are. And so we get into this problem where we have to name things in a way that expresses their importance so

[00:21:00] that sort of linked heuristic can be difficult. And then there's this issue where IDs were only supposed to use once, on a page.

[00:21:09] So those aren't very flexible and tag names are created for us, until recently, now we can create our own custom elements, but so those weren't very flexible. So really all that we had was classes and attributes where we had a lot of flexibility, and so we saw this sort of like naming conventions that were very strict and very strict about how many classes and attributes you could use and how exactly to use them.

[00:21:40] And in some ways they were trying to get away from the cascade and create a new way of setting priorities or, uh, something based on, uh, based on naming conventions, but that's fragile, it only works if everybody on the team agrees to use the same system and you don't use any third party

[00:22:00] tools that have a different system.

[00:22:01] Lola: Yeah.

[00:22:03] Mia: So my proposal was that we needed something, where you could more explicitly just say, what should override what, without it being tied to names or anything else. So cascade layers is that, it's just saying I have lower layers and higher layers, I want some things to override other things, and I want to say that explicitly so that there's no confusion, with it being just coming out of my naming convention,

[00:22:31] Lola: Right. And so where are the layers defined? Who defines the layers? Can I, as a web developer just say, cascade root? And that's a layer or the layers defined in the spec.

[00:22:47] Mia: You define your layers and the browsers could define layers within their styles, the users, if you're using a browser that still lets you apply user styles, you could define layers within yours.

[00:23:00] Um, and authors can define layers in our styles for a site. Uh, and yeah, we can give them any name we want, we can even not name them. Um, I would say usually you want to give them a name that lets you know what you're doing and refer back to it. But it is possible to create anonymous layers and then they just stack in the order that they appear.

[00:23:24] Lola: It really is leveraging, sorry to cut you, I just wanna be clear that it really is leveraging the cascade. Then it really has nothing to do with the naming of the thing, if I say something is named root, that doesn't really mean anything to the computer. It just means something to me as the developer.

[00:23:43] Mia: Exactly. So you're just naming the layers for your own use and then they, they stack in the order that they appear, and when you name a layer, you can sort of add things back to it. So you can introduce it early and then you can add things to it later.

[00:23:58] Lola: Right.

[00:23:59] Mia: so there's some

[00:24:00] flexibility you get from that.

[00:24:02] But yeah, it's all, the idea was something that is completely flexible just for our use, just to be expressive about priorities of things in the cascade, so we're not relying solely on specificity for that.

[00:24:17] Lola: and I guess like a possible use case I can see for this because, so I haven't coded, uh, professionally in a very long time, and so anything I write code for now is so small. It's, it's just like, you know, a personal site or, you know, it is just so small. I haven't done corporate coding in ages, and so sometimes the complexity of these things eludes me because I'm like, why? Why would you even wanna do that? Well, yeah, I only have like two css, two CSS files in my whole site. Like, it's not for me. But in terms of like, I, I know you code and program professionally,

[00:25:00] that's what you do at Odd Bird. And so in what, and obviously, you know, redact anything that you feel needs to be redacted, but in what, um, real world situations, have cascade layers been useful for you?

[00:25:15] Mia: Yeah, I mean, there is a certain extent to which, like we have over 20 years writing CSS internalized other workarounds and so part of the fun is once we start using layers, we can start reconsidering old hacks. Um, like, uh, I now am happy to use IDs again. Uh, ID selectors because I can put them in a layer and I can still have other things override them.

[00:25:47] Um, and yeah, and I feel excited that I can relearn specificity the way it was intended because now I don't have to rely on it solely across a huge

[00:26:00] project. But I think there are some, there are some most obvious use cases. Um, anybody using a tool like Bootstrap, uh, you sometimes need it to override your, you have maybe some default styles and then you need bootstrap to override those.

[00:26:18] But then you also need to some things to override bootstrap. Um, and that's extra complicated because you're not on the bootstrap team, determining how they write their selectors and so layers give you the ability to say, okay, import, bootstrap, but import it into this layer. Um, and then I'm gonna have layers that are lower than that and layers that are higher than that.

[00:26:42] And so I can now more easily collaborate with third party tools that I'm not working on. But then I think that's also useful inside of a team. If we say we have a design system that's being used across three

[00:27:00] products, um, and, or, or even just one, but the design system is somewhat separate from the project, so it's sort of like, it's not third party code, but it's also not first. I don't know if that's second person or what. Yeah. Um, But yeah, where we've got different parts of a system, and I think even when I'm just working on a site from scratch for a client, those parts of the system will emerge where first we'll be setting up sort of typographic defaults or something.

[00:27:32] Um, and we'll want to capture those in a base layer and say, yeah, these, we want them to apply across the page, but we're gonna override them quite often in specific cases and then we'll put another layer on top of that that's sort of the theming layer. Um, and then sometimes there will be another layer on top of that that's like component specific styles that should, um, override the theme in some ways or something.

[00:27:57] Um, so we'll sort of build

[00:28:00] up from the base for a project.

[00:28:03] Lola: I can definitely see how this makes things more flexible the bootstrap example, yeah, that kind of really made things click for me because, uh, I've definitely felt that pain of like, you need bootstrap, but you also need to override bootstrap, but you only need to override bootstrap in these situations and in these contexts.

[00:28:23] And it gets complicated, but I can also see this being get getting quite complex quite quickly. And so do you have any kind of like, I don't know, um, how do you prevent things getting away from you basically?

[00:28:43] Mia: Yeah. Uh, one of the things that I recommend, and there was a big concern about like, we don't wanna recreate Z Index here, right? Um, which is one of the reasons that we have meaningful names or like you get to name them what makes sense to you. But one of the things that I

[00:29:00] recommend for using Layers is to, there's a, there's a statement version of the rule where you just introduce layer names in order, um, and you're not putting any code inside of them yet.

[00:29:12] Um, so you can say @layer and then just a list of names and I highly recommend doing that in one place, that is the first CSS you have. And often we will even put that directly inside of an HTML template, we will add a style tag in the head and we'll just, that's the whole thing in that style tag is just that list of layers.

[00:29:38] Uh, something where everybody knows where to go look, and that list shows you what order the layers come in and which ones are defined, um, and you can always refer back to it. I find that a really useful approach to not get lost in them.

[00:29:55] Lola: Yeah, I think that makes sense to me. So just to switch

[00:30:00] gears slightly, um, we were speaking earlier about the kind of, um, the changes in power over time when it comes to who has authority in determining how things are displayed. Um, HTML is all about just presenting things to the user. It's about, this is a piece of text, you need to see it.

[00:30:27] CSS is about making that text legible. It's about sometimes making it pretty, um, it's about, you know, it's about the styling of the text, right? Rather than displaying of the text. Um, and as you mentioned, there are instances where the user should be able to say how they want this and uh, in other instances, maybe they shouldn't, I don't know, maybe there's an argument for that. I

[00:31:00] think there probably is an argument for that. Um, and in the past this was, well I say in the past, it's still now, this was done with importance. You mentioned bootstrap, part of the reason why Bootstrap can override or like have precedence in many people's code bases is because there's a bunch of important flags in Bootstrap.

[00:31:20] Well, I dunno if this is still true now, but when I was using Bootstrap, it was like a bunch of exclamation point importance. And just for those who are listening, could you explain what importance is? And why it is.

[00:31:35] Mia: Yeah. And importance is often misunderstood even by people who have been writing CSS for 20 years. I mean, until I went and looked at the spec, I didn't, I was wrong about what importance was. But it, uh, the way people think of it is that it just increases your specificity, it makes things more specific and then they

[00:32:00] win.

[00:32:00] Um, and that's not quite technically accurate, although in our little worlds dealing with specificity, it feels right. Um, but importance exists to balance the power between authors and users and browsers. So the way it works is browsers provide their styles first, they're in the browser origin, so we never have specificity conflicts with them because we're coming from a different origin and specificity is compared after origins are compared. Um, so the browser goes first and they provide some defaults. Um, if you remove all the browser defaults, you get one big block of text that shows everything, including the head of your document, any style elements in there, the title element, but all of it shows up, everything is display in line by default, and that is one big block of text. Uh,

[00:33:00] then the browsers provide sort of baseline readability, breaking things out, adding display block to things, adding display hidden to some things that are, that shouldn't be visible. Um, they do that baseline, then user styles are applied on top of the browser.

[00:33:17] So the user can say, make the default font size bigger, a few things like that. They override the browser and then we come along and we override everybody, uh, as authors, which isn't right. I mean, that feels backwards. If you read the or initial proposal, uh, it, everything says that users should have the final word.

[00:33:40] Lola: Yeah.

[00:33:41] Mia: Everyone agrees on that. So this feels weird, but it's where then importance gets added. And in the initial proposal, importance was a percentage, you could say, um, 50% important or, uh, 75% important. It was a very strange

[00:34:00] mechanism. You would get a weighted average of the results. So if you wanted blue and I wanted red and you, and the percentages were, you know, uh, 50 50, we would get a purple.

[00:34:13] Lola: Oh wow.

[00:34:14] Mia: so, uh, not surprised that that never happened,

[00:34:19] Lola: So nobody gets what they want.

[00:34:21] Mia: Exactly, uh, the purple no one asked for. Um, I mean, immediately somebody wrote back and said, okay, but what if you want yellow on blue and I want blue on yellow? Are we just gonna get green on green? This doesn't seem theme.

[00:34:36] Lola: Yeah.

[00:34:38] Mia: So yeah, that's not what we got.

[00:34:40] But so what importance does is it says it's therefore lower origins to say some things are not overrideable. Uh, so what happens is we get a, a reversed set of origins, the important origins,

[00:35:00] so it goes the browser normal styles, the user normal styles, the author normal styles. Then in reverse order, the author important styles, the user important styles and the browser important styles.

[00:35:14] Lola: Hmm.

[00:35:14] Mia: Um, and even now. So if you look at browser styles, they do use importance. They use it for things that we just think aren't allowed in CSS, but they're technically allowed. Uh, the browser has just said we can't override them on this. Um, and even browsers that provide sort of a graphic interface, a form for setting your user preferences, they often have a little checkbox, um, that says, uh, you know, do or don't allow the website to override this.

[00:35:50] Lola: Mm

[00:35:51] Mia: And that's basically just setting importance, um, from the user and then, and then they win over us. So it's really

[00:36:00] there for this interaction between origins. Um, but then if we're not thinking about the other origins, we're just thinking about our styles, they are more powerful than our normal styles, so we start to use them that way.

[00:36:16] Lola: Yeah.

[00:36:18] Mia: which doesn't hurt anybody necessarily, but it's this, uh, sort of on or off, um, brute force approach.

[00:36:29] Lola: Yeah. And I, I know that when I was, when I was coding more professionally, it was discouraged to use importance. Um, mainly because you, you are working on code bases that are so big that you really don't know what the consequence of having that bang importance does even within the, the code base you're working in, um, talkless of when you wanna start talking about across origins, right.

[00:36:59] Um.

[00:36:59] Mia:

[00:37:00] Mm-hmm.

[00:37:01] Lola: I do think it's interesting that this is really a tool for origins to kind of decide what gets shown to the user and not really for web developers to decide what gets- does that make sense?

[00:37:19] Mia: Yeah, it does. And the other, the way that I think about it is it's, it's intended to be defensive, not offensive. Um, if that distinction makes sense, it's intended to say some of the styles that I'm writing are so important, you shouldn't be able to override them later. Um, and so it's not a way to override things that are already there.

[00:37:45] It's a way to defend

[00:37:47] Lola: Prevent, yeah.

[00:37:48] Mia: prevent them from being overridden later.

[00:37:51] Lola: Yeah.

[00:37:52] Mia: Um, and so we used importance in the same way in layers where something coming from a lower layer, if it's

[00:38:00] marked as important, will override important things in higher layers.

[00:38:04] Lola: Yeah.

[00:38:05] Mia: First, when things are marked as important, they reverse.

[00:38:08] And again, that's so that you get this defensive technique, so you can say in a reset, you can say, the hidden attribute, for example, should always be hidden. So I'm gonna put displaying important and then future layers aren't accidentally gonna override that, some things are important and worth defending.

[00:38:30] Um, and so hopefully layers both mean we use importance less because we have a, another tool for expressing what should override what, and that we can use it more for what we intended. Um, we can start thinking of it in that defensive way and say it is allowed if we're using it correctly.

[00:38:56] Uh, we don't have to be all or nothing about it.

[00:38:59] Lola: This

[00:39:00] seems like, um, a mindset shift though. Like, so this seems like really recontexturizing, recontexturizing? Recontextualizing, um, how we think about importance if we are thinking of it more as a protective mechanism. The example of hidden is an, is a great one, um, where we never, we hopefully never want hidden to be visible.

[00:39:25] And so setting it at the point of definition as important, this should always be hidden rather than an example that I've seen before, like, you know, you set a color of an element to be red and then later you wanna change it to be blue and you wanna make sure it's always blue. So you put importance on the blue, uh, instead of changing the red 'cause you dunno what the repercussions of, you know, all of these things.

[00:39:52] I, I I think that's like a, a kind of like sh shift in philosophy, right?

[00:39:58] Mia: Mm-hmm.

[00:39:59] Lola:

[00:40:00] And that's more than just using cascade layers. That's like really understanding what cascade layers are for and how to really utilize them in a way that allows you to, um, like box elements together and say at the base level, these are the elements I want defined and how I want to define them.

[00:40:23] And that may change at other layers. Um, and then, yeah, just using the importance as the protective thing. That's so cool.

[00:40:34] Mia: Yeah. Um, and I really like, I, I mean thinking as a teacher, I like when new features make us learn how the language has always worked. Um, I don't, I don't know if that's good.

[00:40:48] Lola: I think it depends.

[00:40:49] Mia: from a but I like it when we get a new feature that makes us go, oh, that's what importance is for, um, that's how the language

[00:41:00] works. I always enjoy that.

[00:41:02] Lola: There's a W3C design principle, which is that, you know, you wanna not make it easy to do the bad thing

[00:41:10] Mia: Mm-hmm.

[00:41:10] Lola: you know, and I think this is a really good example of making it easy to do the good thing and the, the intended thing, you know, the thing that this is how importance was defined and we're hopefully shifting back to that.

[00:41:25] Mia: right. Yeah. So hopefully people are willing to learn that and make the mental shift.

[00:41:32] Lola: Yeah. I hope so. I think, I think web development is, um, weird sometimes because you never really know how people are gonna use your thing. You create a thing and you know, and I guess it's not just web development, it's you create a thing that's intended for people to use and you only ever know if it's successful when the people start using it and if they use it as intended.

[00:41:58] And sometimes they

[00:42:00] don't, and sometimes that's good that they don't, but sometimes that's bad that they don't.

[00:42:04] Mia: Yeah. a terrifying thing working on specs

[00:42:09] Lola: yeah,

[00:42:10] Mia: you think you, you, you think you've worked out all the issues, but you don't know until people use it,

[00:42:16] Lola: you really don't. And I think that's a good thing about specs though, is that they are living documents, so they're iterative, right? Like just because you've written this and published it and it's a standard, doesn't mean that it's finished. It just means that this is what it is right now.

[00:42:35] And depending on how people use it, depending on if people even understand it, depending on what new problems it introduces, you go back and iterate on the spec and make it better and better and better.

[00:42:50] Mia: Hopefully. And then sometimes you find out that there's, uh, backwards compatibility issues and you're stuck with it forever.

[00:42:59] Lola: I

[00:43:00] recently did a, a talk at the, um, there was a W3C AC meeting this week actually, and I did a talk on, uh, the Web and the Digital Divide, and it was basically me going through a bunch of things that should never have been specs and released into the wild, and also go through how, you know, they, they were changed and implement and sometimes changed, sometimes not changed.

[00:43:24] Like autoplay is still a thing, you can still do autoplay, but you shouldn't, you know, and there's advice on how, if you're gonna do autoplay, this is how you should do it, you know, and things of that nature. So yeah, it is definitely not a just take everything out that doesn't work all the time, but sometimes it is a take it out like this is not working.

[00:43:46] Yeah. Cool. Thank you so much. I think we are gonna go into the next section of our, um, podcast right after this break.

[00:43:58] I hope you're enjoying the show,

[00:44:00] and if you are, don't forget to like and subscribe on your favorite podcast platform and share in your social networks. Thank you. Now back to the show.

[00:44:12] Lovely. We're back from our break. Um, and this is the part of the podcast where we play a game, Patch Notes From the Future and this game we answer, I say we, but it's really you answer three questions, one browser feature or web API that you'd bring back from the past, one current feature that you wish never existed or that you would change or an invented feature and it can be real or absurd that you'd create if you could. Um, so let's start with number one, one browser feature, or web API that you bring back from the past.

[00:44:46] Mia: Yeah, I mean there's so much in the sort of early web that's all about these ideas of user control and um, and competing styles and so it's hard to pick just one. I mean,

[00:45:00] the percentage importance, like, I think it's absurd and also I love it, I want that, but also, you know, the, the first browser was an editor and in some ways you could say that browsers are still editor.

[00:45:11] I mean, you talked about that assignment where you had to go in and edit Facebook. Um, but I just love those things. Um, alternate style sheets. Do you remember alternate style sheets?

[00:45:24] Lola: I am gonna say no because, uh, I'm gonna say it's before my time.

[00:45:28] Mia: Great. Um, I think you can still do them in some browsers, but you can set a style sheet to be an alternate. And then there used to be a little dropdown menu where you could choose which style sheet to use. Um, and that might still be in some browsers, but people aren't doing it anymore in the way that we used to as sort of a Zen Garden thing.

[00:45:50] I want that to come back in popularity. Uh, I want us all providing alternate style sheets for our sites.

[00:45:57] Lola: When I was, uh, coming up,

[00:46:00] like in secondary school, I think I, I spoke about this on another episode, we had, um, Piczo, which was like, this is before MySpace and before what we now consider like social media, but it was a kind of social media. It was like a website that you shared with your friends and you would also see your friends' websites and that was kind of it. But you got to design the website and it was a lot of shining things, blinking things, moving things, things playing. It was, it was very chaotic. Um, but it was, you know, you got to create it. And from what I remember, it wasn't like, you know, heavy coding. I, if I'm honest with you, I don't actually remember writing any code.

[00:46:49] It was literally like, you know, you pick your background color, you

[00:46:51] Mia: Mm-hmm.

[00:46:52] Lola: your display font, and all of this kind of stuff and it really did feel creative, it was like a creative

[00:47:00] expression, but also like, yeah, this is how I want to present on the web. You know, this is my space, these are a list of my friends' spaces.

[00:47:10] And you know, and this was like when I was 13.

[00:47:14] Mia: That's so cool. And I know so many people learned web design through like adding CSS in the little box in MySpace or having a Geocity site. And, you know, and there's a lot that I don't want back about MySpace, but I, I do wish we had those sort of like quick ways in for people to have their own sites.

[00:47:40] Lola: Yeah, even on the editability of the web, um, a colleague of mine who's also on TAG Sarven, um, he, runs a projects called Dokeli and it's basically that like you go on a webpage and you can edit, you can annotate, you can highlight,

[00:47:57] Mia: Oh, okay.

[00:47:59] Lola:

[00:48:00] you can make notes and you know, have a collection of pages that you've annotated and noted.

[00:48:07] And it's all in the browser. It's not an app this is, you know, it, it's happening in the browser and he, he is a very big proponent of that version of the web, right?

[00:48:17] Like of actually using the web in a way it was intended, I don't think it was the only way, but it was one of the ways it was intended to be used, right? And it really does put power in back into the user's hands.

[00:48:32] Mia: yeah. And, you know, um, we can think of that as a really fun feature and it is also the core of accessibility. Um, that's, you know, we can do a lot of, I don't know, providing accessibility features, but at the core, if people can make the website, if people can make the web their own and determine how they interact with the web, that's the most powerful accessibility feature,

[00:49:00] uh, we can have.

[00:49:01] Um, I. You interact with it the way you want to interact with it,

[00:49:06] Lola: Yeah. Yeah, I definitely, I definitely agree. Um, and I think part of that too is, is users knowing that they can, you know, I think that's a big part of it. Um, and also I think there's a lot of, you know, mysticism around coding and, and all of this. And, you know, people thinking it's this, it's not that it's not complicated, it is complicated, but it's knowable

[00:49:32] you know, it's not this mysterious, unknowable thing. You can definitely, that average person can know this thing, you

[00:49:38] Mia: Yes.

[00:49:40] Lola: Um, cool. So the second question is one current feature that you wish never existed or that you would change?

[00:49:48] Mia: Yeah. Hmm. Um. I mean, this always makes me think of, there is a, a page on the CSS working group wiki

[00:50:00] of the list of mistakes in CSS. Um, so I could send people that link, there's a lot in there.

[00:50:09] One that's been on my mind recently is I wish, uh, I wish we had done logical dimensions instead of physical to start with.

[00:50:20] Um, I wish right from the start we had talked about the inline axis and the block axis, the inline size and the block size. These things that move in relation to writing modes, um, instead of starting with top, right, bottom, left. Uh, so I wish we had done that differently.

[00:50:39] Lola: In your mind, how does that change things? How does thinking of things in inline and block versus top left, right, bottom shift things?

[00:50:49] Mia: Yeah. Uh, I mean, one of the biggest quick wins is internationalization. So, um, more and more browsers are now

[00:51:00] offering to translate a website for you. If I land on a website that's not in English, I always get a little popup that asks if I would like it translated. Um, but different languages are written in different directions, some of them top to bottom, right to left, all sorts of different things. And by writing our websites using logical directions, we can very quickly flip things around for a different language and get a lot of wins out of that. Uh, without, like, I don't provide translations built in on my website, I don't know a lot of languages, and I don't have time to, uh, translate every blog post, but I can write it so that it's ready to be translated, and that doesn't even take me extra time. I'm just using a different property name. So,

[00:51:49] Lola: Yeah.

[00:51:50] Mia: um, yeah, I wish that had been the default from the beginning.

[00:51:54] Lola: That makes sense to me. And finally, an invented feature, real or

[00:52:00] absurd, that you'd create if you could. And I guess it could be something that you haven't, you have created as well. I, I won't make it too difficult for you.

[00:52:09] Mia: Yeah. Yeah. I mean, it's, it's too, it's almost too easy though if I just sort of list the specs I'm working on. Um, I don't want to, that feels like cheating. I think I, I always think about what I wish browsers would provide. When we think about where has the web become complex in ways that make user preferences and user styles more difficult?

[00:52:36] Part of it is that sites are more different from each other, so it doesn't make quite as much sense to set a universal thing and have it apply to every site I go to. Um, but to me what I would want then is an easy way to land on a site and say, no, this font isn't readable for me, swap it out. No I need the text size

[00:53:00] to be bigger, but I don't want to just zoom everything, I just want the text size to be bigger, and I, maybe I don't need all of the fonts or all of the text on the page to be bigger, I only need this. I want an ability to go into a site and make some adjustments, um, and have the browser remember those adjustments. I think also browsers would be a great place to have the tools for starting to get online yourself, um, to, to, and some of it that's in there if you know where to look in the developer tools. But yeah, browsers would have a lot of potential to provide that sort of GeoCities, MySpace, here's how to get started, here's how to get yourself on the web, maybe an ability to follow other people. I mean, I guess Vivaldi has RSS feeds built in, but it's a little bit funny the way they do it, like adds it to your email, which I find a little weird, but

[00:53:58] Lola: okay. I haven't, I,

[00:54:00] I literally just downloaded Vivaldi this week, um, to experiment with, 'cause I currently use Arc and so I wanted to experiment with Vivaldi a bit 'cause I know they've got notes in the browser, um, which Arc used to have and they took away 'cause they wanna focus on AI now, I guess

[00:54:16] Mia: Right.

[00:54:18] Lola: um, but Vivaldi's got the notes, so I've been experimenting a bit with that.

[00:54:23] I haven't used their RSS feed yet though.

[00:54:27] Mia: Yeah. I, I found the way that they do RSS feeds a little confusing, but I like that they have them in there. Um, I think Vivaldi is one of the ones that's the most, the closest to sort of what I'm imagining of, uh, putting all these features together. Um, I like what they're doing.

[00:54:45] Lola: Yeah, so do I. Um, yeah, Vivaldi seem cool, um, yeah, I think that's such a good idea though of like having the browser be the introduction to getting yourself on the web,

[00:55:00] you know, um, instead of, well, in addition to other resources that are currently out there. Right. But like, if you downloaded your browser and the first page you saw was, Hey, do you wanna, do you want a website?

[00:55:14] Um, you

[00:55:14] Mia: Yeah.

[00:55:16] Lola: download this HTML and it's just, you know, bare bones, HTML with a head and a body and, you know, you follow some instructions and you just upload it back to the browser and it does some magic for you behind the scenes, uploads to the server and gives you a link and it's like, this is your webpage.

[00:55:37] Mia: It sounds like you're working on it already, so, uh, please let me know when this ships

[00:55:44] Lola: I literally have my first, mentoring session to contribute to browsers tomorrow. So I think I'm still a while yet before I'm like, you know, building whole browsers that like, allow people to just make their own websites from the get go.

[00:56:00] I think I've got a few years.

[00:56:02] Mia: Sure. All right. Well, I can wait, but let me know when you get there.

[00:56:07] Lola: Thank you so much for, uh, joining me today, Miriam. This has been a lovely conversation. Where can the people find you? Where can the people support you? How can the people support you?

[00:56:18] Mia: Yeah. Um, you can find me at oddbird.dev. Uh, that's the team that I work with every day. Uh, and there's various ways to support us there. I mean, we do client work, so if you need help with a website, uh, or a web application, um, whatever you're working on, uh, we can probably help out. Um, I also, I have a workshop coming up, uh, at the end of April, um,

[00:56:46] Lola: This is, this episode is probably gonna go out in June, so it

[00:56:50] Mia: Great. I don't have a workshop. I have a workshop that happened already. I mean, I, I always have workshops coming up. Uh, so that's something, if you're interested in learning

[00:57:00] CSS, um, there's gonna be workshops and courses. Um, and also, um, I'm an invited expert in the W3C, which means it's an unpaid position.

[00:57:11] Uh, and so always looking for support there. If you like the features that I'm working on or want to support independent contributors to W3C, um, donate to Lola first and then come on over. We have an open collective, uh, if you wanna support our work there.

[00:57:30] Lola: And I'll be putting links for everything Miriam just said in the description, in the show notes. So you'll be able to see that stuff. And I do wanna reiterate, it's really, really important to support independent, um, experts and invited experts to the W3C. Um, Miriam in particular has contributed a lot.

[00:57:50] So, you know, that work couldn't happen without the generosity of others, um, and the support from others. Thank you again,

[00:58:00] Miriam. This has been lovely. And listeners like, share, subscribe I think you can do that on the podcast platforms. Um, and all of the good stuff. Leave good reviews. If you enjoyed this, leave a review.

[00:58:13] If you didn't enjoy it. Do not leave a review. Um, thank you.

[00:58:19] Mia: Thank you.