On the podcast today we have Mark Root-Wiley.
He’s on the podcast today to talk about why he thinks that it would be useful for WordPress to adopt some CSS standards.
Over the years, as WordPress has evolved, the way that you implemented CSS was very much left to the individual user, themer or developer. You could do what you like, and that worked very well, after all, we all have preferred ways of doing things.
Now however, the reach of WordPress has outgrown those early roots and some 40+ percent of websites are using it. Projects that were built by one agency are often taken over by another. Users are often swapping themes to reflect their brand. Extra work is created for those inheriting sites as they try to unpick the way that the CSS is built and implemented.
Mark thinks that it’s time for WordPress to lay out some simple standards which are easy to understand, and if they became universal, would save us a lot of time and head scratching.
He’s not proposing anything radical, just some basic advice for the most commonly used CSS, and it’s quite a compelling idea which would need a lot of community buy-in, and possibly some top-down approval if it were to move forwards.
It’s very much the kernel of an idea at present, but thought provoking nonetheless.
[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox has a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, creating standards for WordPress’s CSS.
If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy and paste that URL into most podcast players.
If you have a topic that you’d like us to feature on the podcast well, I’m very keen to hear from you, and hopefully get you all your idea featured on the show. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the contact form there.
Before we start, I thought that I’d let you know that there won’t be an episode of the podcast next week. This is because I’m hoping to be going to WordCamp Europe. I’ll be there with my microphone, recording episodes for the coming weeks. If you’re going to be there too, it would be lovely to meet up.
So on the podcast today we have Mark Root-Wiley. Mark builds WordPress websites for nonprofits in Seattle, Washington with a focus on accessibility and usability. He’s a long time WordPress community member in Seattle and has previously helped organize WordPress Seattle meetups and WordCamp Seattle speakers.
He maintains NonprofitWP. A free guide for people building WordPress websites for their nonprofits. And has a few free plugins available on wordpress.org.
He’s on the podcast today to talk about why he thinks that it would be useful for WordPress to adopt some CSS standards. Over the years as WordPress’s evolved, the way that you implemented CSS was very much left to the individual user, themer or developer. You can do what you like, and that worked very well. After all, we all have preferred ways of doing things.
Now, however, the reach of WordPress has outgrown those early roots and some 40 plus percent of websites are using it. Projects that were built by one agency are often taken over by another. Users are often swapping themes to reflect their brand. Extra work is created for those inheriting sites. As they try to unpick the way that the CSS is built and implemented.
Mark thinks that it’s time for WordPress to lay out some simple standards, which are easy to understand, and if they became universal would save us a lot of time and head scratching.
He’s not proposing anything radical. Just some basic advice for the most commonly used CSS. And it’s quite a compelling idea, which would need a lot of community buy-in, and possibly some top-down approval if it were to move forwards. It’s very much the kernel of an idea at present, but thought provoking, nonetheless.
If you’re interested in finding out more, you can find all the links in the show notes by heading over to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.
And so without further delay, I bring you Mark Root-Wiley.
I am joined on the podcast today by Mark Root-Wiley. Hello Mark.
[00:04:02] Mark Root-Wiley: Hello. Thanks for having me.
[00:04:04] Nathan Wrigley: You are really, really welcome. I always like to begin the podcast with a bit of orientation. I think it’s very important that the audience gets to know a little bit about our guests. Who they are, what their journey with WordPress is and so on.
So although the question is a little bit generic, I’m going to ask it anyway. Please, just give us a little bit of a history about yourself specifically in relation to your WordPress journey.
[00:04:28] Mark Root-Wiley: Awesome. Yes, let’s see. It’s been a pretty long one at this point. I am a child of the web almost. So, even back in the middle grades, I was learning to make websites. And so, it’s always been my hobby and my passion. And so when I, when I went off to college and got a degree in sociology, of course, that was much less employable than web work.
So, I looked around at all the systems and I had some jobs and internships where I was working with Joomla and Drupal. And so of course I ended up landing on WordPress. So since 2010, I’ve been here in Seattle, Washington where I build WordPress websites specifically for nonprofits most of the time, and so, my journey has really been that about serving clients, building custom themes doing some custom plugin work, but really like, deep in the world of WordPress for well over a decade now. And, I got to say, I love it and I’m not considering going anywhere anytime soon.
[00:05:19] Nathan Wrigley: Oh, that’s excellent news. Now the topic under discussion today is going to be CSS and in particular, we’re going to reference right at the beginning, an article, which was published by Justin Tadlock on February 22nd on the WP Tavern website. And it was called the case for a shared CSS toolkit in WordPress.
And we’re going to get into the nuts and the bolts of that in a moment because Mark, I think it’s fair to say, would like to see some kind of overhaul in the way that WordPress handles CSS. And as I say, we’ll get into what that means in a moment. But Mark, I know that you may not be able to lay out the history of CSS in WordPress perfectly for us, but clearly you believe there’s a problem.
I’m just wondering if you could give us any insight that you’ve got into the way that the legacy of CSS in WordPress has meant that we’ve got a problem where we are right now. What has been going on and where are we at now?
[00:06:15] Mark Root-Wiley: It’s such an interesting question, and I think if I had to boil it down to just one sentence answer, you know, it’d probably be there used to not be very much CSS in WordPress and now there’s a whole lot more. To really expand upon that, I think what has happened is, you know, it used to be that WordPress really only had a little bit of front-end markup that it would put out. There were things, HTML for menus, HTML for the search form, HTML for widgets and themers just sort of applied their own CSS to that.
Maybe in some limited cases, WordPress had a little bit of CSS that they were adding to the front, but really very little. And with the block editor, we saw the project looking to really empower users to be able to control much more design of the sites they build, through the WordPress editor interface.
And if you want to give people more control over the design, you’re going to be, at the end of the day, you have to do that with CSS. CSS is the language we use to make design on the web. And so it has just become much, much more complicated. And I think all software, you know, to some extent, right, it’s always evolving, but I think in our world of open source, that development process can be much messier and much more organic. And I think that that can be a benefit sometimes. But I think that maybe this is one of those instances where, right now there’s a lot of different ways for accomplishing, you know, similar types of CSS on the front end. Certain blocks handle their CSS in different ways.
And I think we’re just seeing that, you know, it’s been what, three or four years now of the block editor and there still isn’t really a strong opinion of sort of, this is the way that the block editor handles CSS and that has made it really hard for, people in my chair. I’m trying to make themes that are going to work every time I hit the update button on WordPress.
There’s just more complex CSS. There’s more of it. It’s done in varied ways. With more code comes more complexity and, it’s time to try to bring some order to that complexity.
[00:08:20] Nathan Wrigley: So it’s a case of the project being older than it was 15 years ago. There’s more that’s been added on top. It’s like a layer cake. We’ve had update after update, after update and things have been added in and fiddled with. We’ve had complete turnarounds in the way the interface has been put together and so on Gutenberg and all of those kinds of things.
And, essentially we’ve now got something which you, I think it’s fair to say, you would like to have a bit of a reset. You’d like us to rethink the way that the CSS is handled. And you’ve got some ideas around that.
Could you give me, before we get into the weeds of it, could you give me examples of pain points that you believe need solving? And you can be as specific as you like, you could describe a particular website that you built and a particular moment where you realized, ah, there’s things that I wish were different. So pain points that illustrate well what the problem is.
[00:09:12] Mark Root-Wiley: Yeah, that is such a, such a good question. I think that in some ways, the WordPress 5.9 release gave us a brief set of examples that I think made things hard for a lot of us themers. What probably looked like fairly small changes to for instance, the HTML and CSS of the cover block.
There was I think one class that was removed from buttons that told you about the orientation of the buttons, how they were vertically aligned. But when that was removed, suddenly all these themes that had written CSS styles where they needed to know the alignment of buttons on their site, they just stopped working because that class had been removed.
So rather than even really an overhaul, I think it’s a lot more about refining the practices and making a public commitment to, in the future, we are going to include classes in all of these circumstances, so that you can rely on them.
We are going to output all of our CSS rules with a certain specificity. It’s time for the CSS to sort of be better, organized, more consistent, and just communicated better. Which is not really an issue of code, it’s more matter of having standards for the project. If anything that’s really what I am hoping to see.
[00:10:24] Nathan Wrigley: You’re not the first person to suggest that this would be a good idea. It feels in the article, at least anyway, you, you make the point that you are standing on the shoulders of giants, really. And do you just want to give a shout out to some of the people who in the past have elucidated what it is that you’re trying to do? There’s several of them, but I think it might be nice to give them some credit along the way.
[00:10:46] Mark Root-Wiley: Absolutely. Yes. I completely agree. I hoped that when I wrote my big blog post, this proposal that I know we’re going to talk about. What I see as one of the strengths is that there’s very little original thought in it. It’s really trying to bring together all these other great ideas from other people.
I think it goes back to, and I think you can still find it, the theme user experience standards, or TUX that came from Automattic’s theme team. And I think they have an example we should talk about in a little while. So, I owe a lot to them. Rich Tabor, I think about two years ago had some really awesome posts about what it would mean if we could standardize how we named font sizes, how we named colors and how we handle spacing and WordPress.
I think that’s a critical thing that we really do want to make happen. That’s something that I would love to see. And then, I think if you’re just tooling around on GitHub and following, you know, people who are filing issues and the Gutenberg repository, or writing about it. I certainly think Matias, one of the lead developers of the Gutenberg project has written really, really smart stuff about CSS.
And there were also I think, a couple of like small folks I want to give shout outs to. Louis herons on Github, talked about having a theme block contract. Things that themers can count on for blocks, making that contract. I love that phrase. I think that is super important. And I think also, uh, Andrew on ocean has written about needing different layers of CSS. And I really liked that idea too.
[00:12:11] Nathan Wrigley: Well, thank you. Hopefully, they’ll be listening in and they’ll acknowledge your acknowledgement, which is nice. So the idea really is you want there to be some sort of overarching structure. You want there to be some sort of consistency in the way that things are handled, and that WordPress Core would make moves towards that.
Now this is probably something that you’re going to have an opinion on, but there are out there already, all sorts of different ways of handling CSS. Frameworks, and what have you, you know. Just off the top of my head written a couple of down here, you know, you’ve got CSS Grid and Bootstrap and so on, but I’m pretty sure that that’s possibly not the approach you want us to go down. You don’t want to bolt those into WordPress Core?
[00:12:52] Mark Root-Wiley: Definitely not. Yeah. I think that WordPress has never taken a really strong position on like, this is how your theme code has to be written, and if you’re going to pull in an entire CSS framework like Bootstrap or Tailwind, that’s way more opinionated. That would be very limiting to anyone who didn’t want to do things that way.
So, I think, when I sat down and really thought about like, what is it that I as a themer want. What it was is really baseline standardization more about just making sure that all block HTML and block CSS are done in a similar way. So that they’re, they’re sharing styles, they’re sharing CSS classes.
I think that there is also a ton of power if we can just standardize key styles that every site is going to need. So colors and font sizes. The amount of space between elements, things like that. But certainly not going as far as something like Bootstrap where there’s, gosh, sliders and drop down menus and modal dialogues and all those things.
It’s not at all about that. It’s really, I think the word I really settled on is it’s, it’s a toolkit. It’s providing more tools that all theme developers, all plug in developers, we can all use and share, but we still get to choose how we use them and how much we use them. So that, if we want to play nicely together, you know, those tools are available, but we can still choose to do things in our own way where it makes sense.
[00:14:18] Nathan Wrigley: We mentioned at the start that there was a WP Tavern article, which in turn was written because of something that you wrote and I’m going to include everything that we talk about today as far as possible in the show notes. But if you wish to pause this podcast and go and read Mark’s piece, it’s called standardized design tokens and CSS for a consistent, customizable and interoperable WordPress future.
You’re going to find that over at There’s no, no hyphens or anything like that. It’s just M R W web.com. That outlines everything that Mark is talking about. And so that really frames the conversation that we’re going to have from this moment on.
Now you mentioned that you wanted some sort of standardization. Presumably if that’s the case, you believe that the standardization at the moment is lacking. It’s messed up. It’s a muddle for people to create things. Everybody’s using their own different ways of doing things. Just kind of outline the specific problems about fragmentation versus standardization. What is it that you’re trying to overcome? What are the problems in Core that we’ve got at the moment? Things that need amending. Things that possibly need creating or uncreating?
[00:15:35] Mark Root-Wiley: Yeah. I’m going to answer your question and I think I want to like start us maybe five years in the future and then walk backwards to get there. in five years, I think we’re going to see a lot of sites that were built with the early years of the block editor.
Like now suddenly they’re needing to move to new themes. And so what does that look like? And, right now what we have are a lot of what I think of as kind of in the moment decisions that have been made. Both by the themer and the editor. Let’s take the theme or example first.
So, the block editor from day one has always allowed themers to define named font sizes, right? So, they can call them whatever they want. A lot of themers have something like small, medium, large, extra large, I know. Justin Tadlock on the Tavern posted his extensively researched list of font size names that he likes. Definitely worth a read for anyone who hasn’t seen that.
But I think the critical thing is that you can call them whatever you want. You can call them broccoli, apple, bicycle. You can call them seven forty, two ninety six, even if that has nothing to do with their sizes. And so what this means is that if we’re going to switch to a new theme in the future, if we switched to a theme that uses different names, all those font size settings that were set on the last version of the site are just gone. There is no bridge.
And so if we could agree to some like naming schemes, whether it is small through large, or even just 0 1, 2, 3, 4, 5, 6, 7. Now, when you move from one theme to another, you’re going to inherit, the choices that were made by the editors of the site, and be able to keep content as intact as possible. And right now I think the systems that the block editor is giving us are not really encouraging that consistency.
And it hasn’t really bitten us yet. The problems I think are coming. And so when I talk about portability of content. That’s what I’m talking about is how, what happens when we move from one theme to another. And I think that when you make that process smoother, it’s because you have good standards and that’s going to benefit everybody, working all the time.
[00:17:41] Nathan Wrigley: So the idea then is that things would become more standard and hopefully the community as a whole would adopt some standards.
Now, although we haven’t discussed this in our conversation prior to clicking record, I’m curious about your thoughts about this. Do you have any expectation that this would be something that would be, if you like, top down, in other words, would this be something which you would like to just be reflected in documentation?
And it’s a thing that you could use, or are you looking for a framework for CSS where really there are standards, which must be adhered to. In other words, you don’t really get to choose. If you want to be a WordPress theme in the repository, then you must do it in such and such a way. And over time, you mentioned five years in the future, we slowly encourage people to become the writers of CSS in that way.
[00:18:38] Mark Root-Wiley: That is such a tough question. I think that I guess I’ll say a few different things. I mean, I think that whenever possible, it’s better to use carrots than sticks. And I think that, right now in fact, I think the theme dot json standard is a great one where, if you’re building, what we’re now starting to think of is like classic themes.
Like you can use the theme dot json it’s on, it’s up to you and you also get like a ton of benefits by doing it. So I think that if we had standards like this, there would just be tremendous benefits to anyone who uses them, because themes would sort of work more similarly and even, there would be ways where plugins could suddenly sort of start referencing theme styles.
I would like to think that maybe this could bubble up, and be, you know, a community standard that people want to buy in, but aren’t forced to buy into. At the same time, I don’t know what it’s going to take to get this moving. Standardizing semantic names is something, we could talk about it forever.
And so I know that I personally, like I put out, in my blog post, a bunch of suggestions for the names. I thought really long and hard about them. I have my reasons. And honestly, like if someone said, nope, we’re going to use this really weird naming scheme that I don’t really care for anyway, I would use it in a heartbeat. I think having standards is more important than the specific names of them are. And so I do think that, there could be some room for some top-down decision-making here. As long as it’s a fairly simple thing, and we’re not going to punish people for not using it.
In WordPress land, you know, maybe that means we’re going to maybe throw some errors on occasion if you’re not using, some warnings, excuse me, not errors warnings. But no errors, nothing’s going to actually quit working.
[00:20:21] Nathan Wrigley: You mentioned in the piece that there are some recent issues They were obviously some kind of catalysts for you, where you thought, okay, these kinds of things are happening and it makes it pretty obvious that we need to rethink this. I’m just going to read them out, and maybe this will give some context to somebody listening to this.
You say to quote, recent issues make the need for a consistent, transparent approach, clear. Classes that were previously present and used by theme authors have been removed in favor of inline styles. Okay, we’ll get onto why that’s bad. Inline styles are redundant, hard to override and remove valuable selectors for theme authors. New instances of important, let’s just say that, CSS rules catch theme authors by surprise. Markup changes to Core blocks were only announced after the fact.
Now, I don’t know if you want to take all four of those or just riff on generally why you think these are the core things which need to be addressed, but yeah, there’s obviously something in there that sparked your interest and made you want to create this framework, if you like. Let’s just talk about that for a minute. Have you got something to say around that? What is it that you’ve found problematic?
[00:21:27] Mark Root-Wiley: I certainly have things to say. I suspect that honestly, maybe it was just random, how many, how many issues in 5.9 there were that sort of just got my goat as it were. I think that this is maybe one of the areas where there has already been a little bit of movement actually, which is wonderful. So yesterday, was this day when sort of all the dev notes for WordPress 6.0 showed up on the make.wordpress.org/core blog, and it included a lot of announcements about some changes to things, that are coming in WordPress 6.0. And I think that that advanced notice, already feels like, maybe some of what I’ve been saying has been heard and, and that, that is really great to see.
So, you know, there’s going to be some changes to like how images get aligned, the quote blocks CSS, some changes around the group block in the block editor. And, I’m really happy to see that communication. So I do think that some of these smaller things were addressed, but I also think that the fact that some classes disappeared and some markup changed and nobody knew about it, and like important CSS got added. If you ever want to like really get a bunch of people worked up about CSS, just start talking about important.
I think the fact that those all happened at once, I think more than any one specific issue, it just felt like, okay, there’s a lot of people changing a lot of things all at the same time and there’s no cohesive vision for we’re trying to take CSS in WordPress.
[00:22:47] Nathan Wrigley: Yeah. So essentially you want there to be far less surprises in the way that things are released and also to have some cohesive framework that everybody can dip into and everybody understands because it’s been well-documented and everybody can buy into it. As you said, carrot, not stick, because it just makes sense.
The article on the WP Tavern website had a very large amount of commentary on it. More so than anything I’ve seen in quite a while, to be honest, a lot of praise for the idea of what you’re doing. A lot of people saying, yes, we need this, we need this right now. And to develop it a little bit further, you are, you’re keen to get involved in a semantic approach.
Now that might not be obvious to everybody. So what does that mean? What is it you hope would come out of this? We may have a different vocabulary, in use in the end, but the idea is that we’re going to be substituting words or not as the case may be. So talk to us a little bit about that.
[00:23:43] Mark Root-Wiley: Yeah. I when I’m talking about semantics here, it’s really about can we establish shared meanings for some naming conventions within our CSS? So, back to the font size example earlier, if we can all agree that every time we name our font sizes, we’re going to call them small, medium, and large.
And every time we create our color palettes, we’re going to start with a primary color and a secondary color and maybe an accent color. Having that shared meaning, that’s what semantics are, is going to just provide so many benefits, and it’s also going to speed things up.
There’s going to be less mental overhead, fewer decisions that themers have to make. There’s just tons of value there. Thinking back I had mentioned that the theme user experience standards were maybe the best spiritual forbearer to this kind of point of the proposal. One of the things they recommended is when you’re naming your menu positions to call them menu one, menu two, menu three, menu four. Maybe that’s not what I would have chosen, but I started doing it and I’ve done it ever since.
And what it means is that any time I switched one of my themes to another themes that uses that same menu naming convention, like, the same main menu just popped up in the header, right where I would want it to be without me having to update any settings at all, just because, our themes knew how to talk to each other.
So it’s really about, can we make our themes and plugins talk to each other better and, ironically or, or appropriately, I think that just means we all need to do a bit more communication together in the project.
[00:25:10] Nathan Wrigley: Let’s get into weeds of the areas you think ought to be covered off, with some kind of framework. I keep using the word framework. I hope that’s okay. So for example, you mentioned fonts and you mentioned that the fonts might have things like small, medium, large, and that could probably extend up and down.
But also there’s obviously other things in CSS that we would like to cover. So before we get into nomenclature of what those things might be, let’s just talk about the things that you want to cover aside from fonts. What other things do you think are so essential that we need to have a standard that everybody just understands?
[00:25:47] Mark Root-Wiley: Great question. So in terms of those kinds of like standard things that we should name, I think beyond font sizes, including font weights, because if you’ve ever used a font, you know, that some have nine or now in infinite number of weights. So we need a way to sort of have a standardized font scale. Colors and gradients I had mentioned.
And again, that’s something where WordPress already lets us name our colors and gradients. So let’s just agree to always call them the same things. I think font families. So what are you using for your copy versus what you’re using for your heading? And then I would love to also see maybe some border widths, and probably the biggest one that I am most excited about is let’s agree on one or a few named scales for spacing.
So the space between blocks in a post, also the space between columns. The space between a gallery. If we can all agree on those names, then we can have a gallery with small space, a gallery with large space. And that’s just always going to look good from theme to theme, even though those values are going to be different and up to the themer.
[00:26:53] Nathan Wrigley: So aside from the fact that you would like to take into account things like font sizes and weights, colors, gradients, font, families, borders, spacing gaps, and so on columns and what have you. There would obviously need to be things that are associated with those, and you, you mentioned font sizes, small, medium, and large. Do you have some sort of insight into how far each of these go? Let’s for example take font sizes or weights? Well, let’s go for font sizes just for illustrative purposes.
How far would you like to take that, and do you have a system for making it so that it can be extendable indefinitely? So an example might be, one dash large or something like that, or XL large or something like that. Just give us a flavor of how far that scale would go down as well as up.
[00:27:39] Mark Root-Wiley: Yeah, that’s a good question. So I think, if it were up to me, if I were making a top-down decision, I think I would just pick a scale of numbers. Either, you know, starting at zero or going up, or maybe even centered around zero with positive and negative numbers. I like the fact that you don’t need to know English to use a scale like that, and it is infinitely scalable.
I think the other scaling systems that a lot of people really like is what’s often called a t-shirt sizing. So instead of small, medium and large, we would just have S M and L. And the nice thing about that one is you can infinitely go in either direction.
So XL, XXL, XXXL. It gets a little silly after a while, but you can do it. Some people like to say like three XL instead of XXXL. And you can do the same with XS, extra small. I will say that I think that when it comes to what WordPress should be standardizing, I don’t think it makes sense for us to say that every theme needs to have a 15 point scale for font sizes.
Some themes are gonna want three or five and that will be fine. I like to think of, of the 80 20 rule. 80% of needs out in the world can be satisfied by only 20% of the possible names in this case, that we could come up with.
So I think that for something like font sizes, a seven point scale, maybe would probably meet everybody’s needs in terms of switching from site to site, and keeping things looking pretty good. Again, to go back to sort of like why I like to think of this as a tool kit. I wouldn’t want to ever say that themes can only have seven font sizes. Right. It would just be that if they want more than that, they’re on their own to go figure that out.
I will say that I did, I did a lot of thinking about this even after my blog post. And there’s, there’s a demo I put together that was showing how maybe we could even have a way of having really big scales that could kind of shift down to only a three point scale, or maybe you want to have a five point scale, but it skipped 0.4. I think there’s some clever things you can do with CSS custom properties that could allow that to happen. So you can find that demo in the blog blog post.
[00:29:38] Nathan Wrigley: Yeah. I ran that demo. That was really useful to look at that. But let’s move on to colors and much, much more constrained there. You just want a handful really unlike font sizes, which there’s definitely more scope with colors. You just want a few basic standards that will satisfy most websites I guess?
[00:29:56] Mark Root-Wiley: I think that’s right. And I think that the more colors that we defined, probably the more disagreement there would be. What purpose does the fifth most important color in your palette have versus what purpose does the primary or secondary colors have in your palette?
And so I think that, especially for colors, I think it’s the best example where if you had a bunch of standards, they probably wouldn’t actually be that useful. So let’s just, let’s keep it simple, right? Let’s not, over-complicate this. Let’s make as few things we all need to agree on as possible. So hopefully we can actually agree on them and move forward.
[00:30:28] Nathan Wrigley: The font weights and the font size is obviously really dramatically changed the way a website looks. And if you switch from theme to theme and those get messed up, it really can look remarkably different. And you mentioned spacing, so gaps and columns and padding and margin and all that.
Again, it can really catastrophic effect things. What was a very small space can become a gigantic gulf, given a change in theme and so on, and so I was just wondered let’s ask the basic question again. What kind of constraints are you placing on that? How many different things do you think you need regarding spacing and gaps and all of that? Are we looking at dozens of different options or just three or four?
[00:31:06] Mark Root-Wiley: My first thought was, we probably only need maybe five, and I think that that probably would be about enough. If someone wants to do a few more than that, that would be fine. I think that spacing is maybe a really good example of the other key reason why I would love to see themes like shifting to these scales, because right now, for the most part, when an editor wants to change the spacing, of something in their posts, they can, you know, set a specific margin value or a specific padding value.
They can say, I want the top margin of this image to be 24 pixels. And they’re making that decision based on how their content looks in that moment, on their screen with that specific theme. Let’s say design trends again in five years are like really into white space. Maybe that 24 pixels is going to look super tiny all of a sudden. So if we can allow editors instead of having to pick a number and on the next page, they forget that they entered 24. And so they entered 20. And like now there’s just chaotic numbers all over the place. If we just say like, well, at the top of this image, I want to have a large margin.
Now, when they move to their next theme, it’s going to be not 24 pixels, it’s going to be whatever that is in the next theme. It’s always going to look cohesive. And so I think it’s really important to point out that it’s not just about standardizing the scales for theme developers, but I think if we provide these scales as options for customizing post content, we’re going to see editors just having to like not think so specifically, and that’s actually going to enable them to be more consistent, both in the moment and in the future, when they need to sort of switch their design.
[00:32:43] Nathan Wrigley: In a sense, you’ve read my mind because my next question was really about that because obviously your doing this for a living, you can probably come up with some naming system, some framework that works for you, and just keep executing that over and over again. But, that’s not the world. We live in the world where you’ll probably take over a website in a few years’ time that somebody else built, and it will be littered with CSS classes and CSS styling, specific to that exact one little thing on that one page and how on earth did that happen?
But it did. And so you need to go back and unpick all of the problems. So there’s that. The developers amongst us have probably figured out a system for themselves over the years, and they’ve got something which works. But when you swap a website, when you go and take on somebody else’s work, the fact that there’s consistency and stability in the naming of things would really help.
But then you mentioned the bit, which I thought was really interesting, about the non-technical users and having things in easy to understand, non-technical language that somebody can just get a hold on and okay. All right. It would appear that that thing, okay, might not be the most obvious name in the world, but right, it does that. And it seems to do that consistently over the site. That just makes sense for end users.
You described them as editors, but it could be anybody touching the website who has the capability to edit things. They, they really don’t want to get involved with CSS. In fact, that’s probably their worst nightmare that they need to think about CSS. They just want a handful of things, easy to understand. A minimal array of choices. The styling decisions were made months ago, and I’m just happy to stick with them.
[00:34:17] Mark Root-Wiley: You probably described that bit better I ever could. And, I think it really gets to this, there are lots of strong feelings about, is WordPress maybe becoming more like a site builder? Is it forgetting about being a content management system?
I truly believe that I think it can be both. And I also think that a lot of the work, especially around full site editing right now, like it has that more site builder mindset. And so I do think it’s important to remember that not every person with a WordPress site wants that super, super, super fine-grained control.
You’re right. I work with folks that just, they are busy professionals in nonprofits in particular. A lot of the organizations I have, you know, whoever is updating the website that is a teeny tiny part of their job. It’s probably not even in their job description at all sometimes.
They don’t want to be thinking about pixels or ems or if they don’t even know what MSR right. Can’t I just have some large space. That’s all I want, right. And so I think that not only are there these like huge technical advantages behind the scenes, but I really do want to just call out that I think this could actually like, just bring some simplicity to the editor and like help people make good decisions without constraining them.
[00:35:25] Nathan Wrigley: It also provides some kind of muscle memory options as well, in that if you have been working with a WordPress website, let’s say you’re working for company A over here, and you’ve been working with a WordPress website, and you go to interview for another job and they say, have you any experience with WordPress website?
Yeah, that’s fine. I can do that. Then you don’t need to relearn it over on this site though. That thing does. Okay, that wasn’t quite expecting that. That’s a lot bigger than I thought. It makes the whole process of editors moving from one website to another easier as well. So it just seems like a bit of a win-win.
Now having said all of that, we’re 15 years plus into the project. Everybody in the comments on the Tavern article seemed to think this was a cracking idea. You seem to think it’s a cracking idea, the likes of Rich Tabor, they think it’s a cracking idea. And yet here we are talking about it as an idea.
What’s holding us back? What is stopping this gaining momentum if it’s such a sensible idea? Are we, is the project too limited in time? Are we concentrating on other things? You may not have the answers, but you may have some intuitions.
[00:36:33] Mark Root-Wiley: I guess I would start with, this is, you know, a little off the cuff, just a theory, but I do think that the block editor is written in JavaScript. And so the amount of JavaScript in the WordPress project in the last few years has just exploded.
To be really clear, that’s fine. You couldn’t build the block editor without that level of JavaScript. But I do think it means that a ton of the development is done. When people are thinking in terms of JavaScript, and I will say that, one thing that I’ve looked for and I don’t really feel like I’ve seen a lot of, is people sort of starting with, like, what do we want the output to look like? What is the ideal HTML and CSS to allow a user to select the margins of their images, you know, how do we want to handle that? And then build the interface that’s going to enable that.
It feels like it’s sort of working the opposite way. If we’re worried about what is the settings interface going to look like? And then like, we’ll figure out what the code, to make it actually work on the front end is going to be last. I do think that maybe working backwards a little bit more frequent. What CSS do we want, and now how are we going to make sure that it can be created in a sensible way? I wonder if that would help, because at least to me looking, somewhat from the outside, it doesn’t seem like folks are working that way.
And now having said all of that, I think it’s mostly a people and a communication problem. And I think that’s just harder than tech problems, right? Give someone an infinite amount of time and by themselves they could build the block editor on their own, but they certainly could not organize an entire community to agree on what to call font sizes.
That just requires folks coming together. And honestly like making compromises and, and trying to think about what’s best for the community and not just best for themselves. I think that’s really hard. I think we can do it. I think things like that have happened in the past. I do think that’s the fundamental issue and so I don’t, I don’t know exactly what’s needed though.
Again, that’s why I do wonder, could someone maybe make a, a bit of an executive decision on this one and, and just try to say this is happening and we’re going to be taking comments for this long, and then we’re going to make a decision and roll with it because we think the advantages to having a system are bigger than the disadvantages to any sort of, in the weeds decision that might make it through.
[00:38:47] Nathan Wrigley: I wonder if it’s because CSS, of all of the different parts of WordPress. The HTML and the CSS bits, they’re the easy building blocks, aren’t they? They’re the bits that a lot of people can get hold of really quickly. And with a quick flick through some kind of 1 0 1 tutorial, you can get yourself up and running with the basics of font sizing and padding and margins and, and quickly gain an understanding of it.
And so everybody’s been left to their own devices on that. The theme may very well take care of all of that, of all of that for you. And you may need to adjust absolutely nothing. You’re entirely happy with the theme and you don’t dabble. But if on that one particular occasion, you just wished to change that one particular thing you want the, I, don’t know, the, the heading to be slightly bigger, you just fiddle about and locate the CSS for that and modify it, add something to a style sheet, so on. And it’s fairly straightforward and it can be done by more or less anybody on their own, but it doesn’t require any consistency. Naming what you like so long as it works.
But your approach is, is slightly different. And yeah, it feels as if maybe it’s not got the momentum at the moment, but it feels like, you know, maybe with things like this happening, your initiative happening, people talking about it more, maybe somebody could take this on. And as you say, maybe at some point it does need somebody on high to make a decision executively and say, okay, we’re going to concentrate on this and it’s going to become important. But I don’t know that any of that is in the roadmap right now. So you may need to keep banging the gong for a little bit longer I think.
[00:40:23] Mark Root-Wiley: I actually, you know, I, I played a lot of percussion growing up, so I love banging a good gong. One thing I noticed is, you mentioned the number of comments on the Tavern post, I certainly got a few comments on my blog post and I published a, sort of a Github issue that the sister of the blog post and it got a lot of comments and, and I do think people are listening.
I’m not sure what’s required to sort of get some action steps. But, I will say that, what really made me think that, yes, I, I do think people are listening at this moment is there was a blog post, at this point, I think about a month ago, on the make wordpress.org/core blog called core styles and theme customization, the next steps.
The gist of that post is basically like here’s a bunch of links to get hub issues, please go read them and leave your feedback. The speed of change in an open source project is never going to be what we want it to be. And I really do try to always remember that when I’m feeling impatient, which is certainly why I wrote this whole thing.
But I do think that, it is important for folks to always be paying attention, always be sharing their mind, because I do think, at some point, especially if a lot of us keep talking about this, like some decisions will get made. And so, you know, make sure if you’re interested in this, make sure to go leave some comments on, on these issues and keep bumping them up so people can see that they are high priority for a lot of us in the community. I know it’s not just me.
[00:41:42] Nathan Wrigley: Yeah, it was quite interesting. The article that you mentioned, the core styles and theme customization, the next steps I was highlighting the bits that were basic replications of everything that you were saying. And quite a lot of the article got highlighted. Let’s put it that way. So it would seem that, on some level, there is movement here and people are definitely in agreement with you.
Do you have any insight into how this might get revved up and get more interest attached to it? In other words, are you willing to put your best foot forward and become somebody in the vanguard? Like I said, banging the gong. Or do you find that there’s probably a better way of, have you got any insights into where people could go if they agree with you and want to get involved to make this happen?
[00:42:25] Mark Root-Wiley: Gosh, it takes everyone in the community weighing in, I think that. One thing I’ll say is that, you know, I tried to get a lot of people to review my blog post and, even gives me advice on like, how should I publish it and who should I let know about this?
Cause I think that if it’s just me it’s ineffective. It does need to be a community. And so, you know, I would say I would love to see other people sharing their own proposals even. I don’t know. I don’t even know if you want to include this part, I don’t think it can just be me.
I it’s pretty silly actually. I published this blog post and then 24 hours later, we had a new baby. I definitely had to fall off the face of the earth and disappear for a while, but I was so thrilled to see other people, saying like, yeah, this is awesome. And here’s the couple of things I have to add.
[00:43:08] Nathan Wrigley: There’s a whole lot towards the end of the article where you outline the different problems that your solution may solve. I won’t list them all now, but all of it kind of makes common sense to me. One can only hope that the ideas that you’ve suggested go forwards and that people, as a community, can coalesce and come up with an idea.
And as you said, you’re not bound to any one particular way of doing it. It’s just the mere idea of standardizing things, whether it be named this or that is not important, it would just be nice to have some standard documented that everybody can adhere to and therefore make it a lot easier for all of us to make websites, whether we’re building them for clients or we’re just editing and tweaking them ourselves.
One of the concerns that we may have is the stability of WordPress CSS in the future. And I know that you have possible concerns that in the future, for example, Gutenberg blocks, there’s no requirement for the CSS, the classes, and so on to be the same today as it will be tomorrow or indeed yesterday.
So in other words, is that a problem, do you think? Is there any problem of consistency where let’s say that you build something and you ship It, and it goes out to your client. It’s using blocks, but suddenly unbeknownst to you, the blocks CSS classes all get modified, perhaps ever so slightly, but enough to break things. Is that a concern that you have?
[00:44:36] Mark Root-Wiley: It really is. And I think that this is one of the biggest things I sort of learned from this intense period of engagement I’ve been having with the project is that, in discussing this with other people and really closely going through, uh, lots and lots of issues and the Gutenberg Github repository. I found some core development team members really saying that they viewed the HTML markup and the classes and how the CSS has written as essentially like non-public, which is to say you can’t count on this stuff not changing in the future.
That was really shocking to me. And I think for a couple of reasons, I mean, th the first is that, you know, that’s never how it’s been in WordPress in the past. The HTML for the comment forum, the HTML for the search forum, like those weren’t always seen as, you can count on this, there are ways to change it if you need to, but if we’re going to change this stuff, it’s going to be a huge deal and you’ll hear about it in advance, and we’re really gonna try to avoid that.
And so it felt like, uh, that was a departure from how things had previously been. And also as I’m someone who I think follows the project, like more closely than average, even though I, you know, I’m certainly not like a day-to-day contributor, or anything, but this was huge news to me as someone who’s been working with the block editor for years now.
At least to me, I don’t even really know that it’s reasonable to just say that like, well, here’s a bunch of HTML and CSS. Themers I know you have like your job to do and you need to make changes to this, but like, you can’t count on it. That doesn’t really seem fair.
And I certainly don’t think people are really aware of that. They’re not going to go in and one day, you know, completely change the image block or the block quote block drastically. I don’t really think they mean we’re going to just completely change everything. But I do think it just highlights the need again, to really spend some time focusing on what is the HTML that can serve as best going forward. So we don’t need to change it.
What are the CSS classes and the ways of handling CSS styles that we want to commit to now so that we can all just know what’s coming in the future. And so that when there are changes made, they are a big deal, and people are given lots of advance warning and they can, they can react.
And so I think I’m seeing more advanced warning in WordPress 6.0, which is awesome. It’s time to have that conversation about how can we just reduce the number of times we need to make big changes like that. Cause people are going to style HTML, no matter what.
[00:46:58] Nathan Wrigley: Yeah. I wonder if it’s a product of the fact that the block editor is now basically a conduit to put in lots and lots of little components. So you might have a paragraph block and you might have a, an image block or a cover block or whatever it might be. You’ve got all of these different blocks and the functionality of that is not yet a hundred percent certain. In other words, aspects of it could change. And so I wonder if them communicating CSS will change is a product of that. They’re just not sure exactly what those blocks will look like in a few years time. And if they become radically different, maybe the functionality changes. Let’s hope it doesn’t. I’m sure it won’t, but if it did, some of the CSS may need to change. I don’t know.
[00:47:42] Mark Root-Wiley: I think you’re right on the money there. I mean, the block editor is so much more powerful and I want to be really clear that like, that’s awesome. Like the folks I work with generally, like love that they can do more complex things like columns, or like finally putting text on top of an image for the cover block.
Those are good things. And we had to have a more complex system to make that possible. So I’m not against the complexity, but I just think it’s really important that the folks who are building the product, don’t forget about those of us in the real world who, you know, have to make things work every day. And we have, we have new sites we’re constantly working on, the impact of even what can seem like a really tiny change can be really big.
To bring it all back around, I really do think that if we can have just a few more standards and right, if we can have that kind of contract between themes and blocks, I think we can reduce the amount of times that those kinds of changes happen.
I totally acknowledge that they’re going to have to happen every once in a while. If we want to have this like big, nice thing, we’re going to have to put up with probably more changes. Cause there’s more things that can change, but, let’s really, let’s take a minute and figure out how we can make that as infrequent unpainful as possible.
[00:48:51] Nathan Wrigley: Yeah. It’s interesting your language there. You described it as a big, nice thing. And in a sense it’s a big, nice thing made up of lots of smaller little nice things. Each of those little nice things is completely independent. And you may not use those on your website, but you may.
And if there’s modifications made to the CSS classes and what have you, the downstream effect could be pretty catastrophic. You know, if you’ve just built 50 websites and they’re all using the exact same block and some tiny little change affects you 50 times, that’s suddenly created a lot of work for you that potentially was not even thought about elsewhere.
[00:49:27] Mark Root-Wiley: It has. In some extreme cases, this is maybe the reason why some people are often building custom blocks that really they could just be using the core block, but I’ve, I’ve at least anecdotally heard that folks do that sometimes because they know that their block isn’t going to change, even if they don’t want to have to take the time to build it.
[00:49:44] Nathan Wrigley: If people Mark wants to find you. They want to actually reach out to you. You may wish to share a Twitter handle or a website or an email address. Totally up to you. Yeah, any place that you could be found if people are inspired to join you?
[00:49:58] Mark Root-Wiley: Yes. I am M R W web pretty much everywhere. So that’s, uh, MRW web with two W’s, uh, I’m MRW web.com. I’m M R W web on GitHub and Twitter and in the WordPress Slack and Post Status Slack. All these other places. I have a highly Googleable namee. If you want to come find me, I would love to hear from you I’m. I am not that hard to find.
[00:50:23] Nathan Wrigley: Well, Mark, thank you very much for being on the podcast today. I really appreciate.
[00:50:28] Mark Root-Wiley: Thanks so much for having me. This was a blast Nathan. Great, great questions. I got to say.
May 27, 2022
Listen to 
Robert Rowley