 All right, welcome welcome. My name is Nick Diego and I'm a developer advocate at WP Engine and you are joining us for another online workshop through the training team for WordPress. Today we're going to be talking all about CSS. I am joined by my co-host Laura and she's going to be keeping an eye on chat and feel free to ask questions throughout the workshop and periodically we'll go through those questions and tackle those. So today, like I said, we're going to be talking about CSS and specifically about CSS and block themes. Now, to make sure we're all in the right place, I'm going to start sharing my screen. So this is what you're attending. This is what you signed up for. So if you're in the wrong place, I apologize. Get ready for a fun conversation about custom CSS. So custom CSS specifically around block themes. Now, let me know in the chat, has everybody tested out the 2023 theme, the brand new theme that came out with 6.1? Hopefully everybody's tried out the 2023 theme. So if you maybe you don't know, but one of the unique things about that theme is that there is no CSS in the theme. None whatsoever. It's kind of like an experiment, not an experiment. It was kind of a proof of concept to show that you can have a WordPress theme that has styling and aesthetic, but with no CSS. Now, that's not necessarily realistic in every scenario when you're building sites for yourself or for clients. And you will often need some amount of custom CSS. So that's what we're going to be talking about today. How do you handle custom CSS that maybe is extra styling that WordPress core can't handle? And how do you apply that appropriately within a block theme? I can see. I want CSS back, yes. So that's a common sentiment and we're going to be talking about that today. Before I dive into the talk, I want to mention a few things. First is what my setup is because I always like you folks watching at home to be able to kind of replicate what I'm doing here. So I have a local installation of WordPress and I'm not running any plugins. I'll deactivate this for a second. So I'm not running any plugins. Now there's a caveat. I'm actually running WordPress 6.2 beta one. The beta one release of 6.2. 6.2 is scheduled to come out at the end of March. The reason I'm using the beta version, which literally came out like 10 minutes ago. So I was really hoping it came out in time for this presentation, which it did, which is awesome. The reason I'm using beta one is I want to showcase some CSS related functionality that's going to be coming with 6.2. Even though it's not quite out yet, you can use it if you're using the Gutenberg plugin, which we see here. And often in these, I use the Gutenberg plugin so that we can use kind of the latest functionality. But now you can just use the beta version of 6.2 very soon. 6.2 will be out the end of March. And this functionality will just be in WordPress core. So I always like to kind of showcase the latest and greatest stuff so that you can get a look at what's coming in the future. Now let's just, and of course I'm running the 2023 theme. So let's start by talking about theme.json and global styles. I want to kind of get a pulse in the room of who here has is, let me rephrase that, who is not familiar with theme.json? Because if you're not, if there are many folks that aren't, I think it's important to kind of do a quick review of it because it really frames the conversation around custom CSS. So is anybody here who's not familiar with theme.json? If you're not, please speak up. It's not that we want everybody to feel comfortable and learn about modern WordPress. So please share if you're not very familiar with theme.json. We have some folks who are not familiar. Wonderful. That means I can talk about theme.json. That means I can wax poetically about theme.json. So I talked about how the 2023 theme doesn't have any custom CSS. That doesn't mean the theme doesn't have styling. So I have the theme installed here. If we look at the front end, you can see that there's green buttons. There's a font. There's some general aesthetic to the theme. It is very basic, but there's some general aesthetic to the theme. And that's actually not provided by CSS directly. What that's provided by is a file called theme.json. And every block theme, and when we talk about a block theme, it's a theme that's built entirely out of blocks, they all have theme.json files. So what I'm going to do is I'm going to hop on over to the theme folder for 2023, and we can take a look at that. So this is the folder for 2023 in my theme directory. And there's this file called theme.json. And when you open up theme.json, it's just a file with a whole bunch of specification for different things. And we'll talk about those things in a second. But there's a bunch of main sections, custom templates, template parts, settings and styles. I could talk forever about theme.json. We won't be able to cover everything about theme.json in this session. So we'll just talk about styles. That being said, in December, I'm going to share a link here. In December, I did a whole presentation on theme.json. So I'm going to drop it here. There's a recording of it. So if you want to go back, oh, Laura already took care of it for me. If you want to go back and check out this video, I'm sorry, what was that? Oh, sorry. That was you. I had the link and I was ready to put it in, but you beat me. Oh, it's interesting. It comes through saying you did it. Anyway, that's Learn Workshop. I was thinking that was Laura. All right, perfect, perfect. So theme.json is a very big topic in talking about each one of these sections, settings, template parts and custom templates. Yet again, a whole discussion in and of itself. And that recording really only is the tip of the iceberg. I don't want to make it sound daunting, but theme.json is kind of a heart of block themes and this new approach to building WordPress. But what we want to talk about right now is styles, the section called styles within theme.json. If we open this up, we can see that it's, let me collapse this a little bit, okay, perfect. So we have a couple different sections inside of styles. We have blocks, color, elements makes it a little bigger. We have blocks, color, elements, spacing and typography. Now, again, we're not going to cover everything in here, but what I want to focus on specifically are color, elements and just a general concept of blocks. So inside of color, we can see that there is background and text, okay. What I'm doing here is I'm specifying what the background color is for my site. So instead of defining that in CSS, you're defining it in this theme.json file. So if we were to change this to red, for example, when I save it, we come back over here and refresh. Now we have a red background on our website. So while we didn't specify CSS, body, background, color, red, but we've done that in a way through theme.json. So once you're comfortable with theme.json and how it all works, you can start changing things much like you would defining CSS variables inside of theme.json. We also have things like elements inside of elements. We have buttons, H1, H2. So if you're very familiar with CSS, I'm sure in style sheets that you've put together in the past, you have a section for what do I want my headings to look like, what do I want my button elements to look like. You're doing the same thing, but you're specifying it not in CSS, but you're doing it in theme.json. What WordPress then does is it compiles that and turns it into CSS on the front end, but you're not actually writing the CSS directly. Now why? Why would you do it this way? Why don't I just write my normal CSS styles? The reason is the entire idea behind the block editor is WordPress comes with a very basic set of styling. Then on top of that, you put your theme that has more styling, but then we are empowering the user on top of that to make changes. You can see here that I have a background color for base and a text color for contrast. These are defined variables, but I can just do this. I can say red. We have a red background. Now when I go into edit the site inside of the site editor, if I'm a user, for example, let's just say that I took the 2023 theme, it comes with a red background. Now I'm in the site editor and I'm a user and I want to make changes to that. Instead of having to write CSS to make those changes, this framework, this theme.json framework empowers the user to make those changes within the UI. I can come over here to edit. I can go to global styles, which is this little circle icon. Then I can go to colors, background. You can see the background is set to red. This red is coming from my theme.json file. Even though the theme is telling me the background is red for the site, as a user, I can come in and change it to pink or orange or whatever I want. If it was written in CSS, we wouldn't have the UI in WordPress to make those changes. That's why we have theme.json. It's to provide an abstraction from CSS so that it's a common language that WordPress can speak, which WordPress has its own kind of base theme.json and the theme has its theme.json and the user has their own styles that sit on top of that. There's a specificity where the user styles override whatever the theme provided. I'll stop there because that's kind of a big concept. What do you got, Laura? We have a couple of questions. Lisa had a question. When creating a child theme of a block theme, is it wise to duplicate the parent theme, theme.json, and add new stuff or start empty and only add the changed or new theme.json stuff? Fantastic question. What she's asking is, if I expanded all of these sections, it's a very long theme.json file. It's 700 lines long. If those are familiar with child themes, the idea is that you have a parent, so in this case it would be 2023, and then you have a child theme that would be based on that parent, and you'd make some modifications in that child theme. Maybe you have some different colors, font, maybe some additional functionality. What is supposed to happen is that the theme.json of the parent is going back to those kind of leveling concept. You have the parent, and then you have the child that sits on top of it, so you don't have to replicate everything in the parent in the child. For example, you could have a very simplified theme.json for the child theme that just defines maybe the background color, your style, color, green, or whatever. You could remove everything else out of the theme.json file in the child, and it would inherit everything in the parent, except for your changes. Now, because it's all the specification within the theme.json is very complicated, I will not lie and say there have been some compatibility issues there. I think we made huge progress there, so I want to say only add what you need in the child theme and remove everything else and rely on the parent, but check it. For some of the sophisticated settings inside the theme.json, there have been some issues, but I think we're in pretty good shape right now. Then to piggyback on that, Silvia was asking, are these changes overwritten when WordPress upgrades? No, so unless you're updating the theme. For example, if I was to change this color red, and then 2023, the theme upgraded, and I downloaded that upgrade, then this would be overwritten. This is a great place for a child theme, where you can have your own child theme that sits on top of 2023. You make your changes in your child. 2023, you can update, change whatever it wants, but your changes remain fixed in the child. But as far as WordPress goes, WordPress will update, and it won't impact your changes in the theme. I don't want to get too far into that discussion because we could have an entire conversation around child themes and all that kind of stuff. But yeah, Catherine suggested the create block theme, so please check that out. That's totally awesome. I use that. And then last question, can one have a child theme for a block based themes? Absolutely. That's what we were just talking about. Thank you, Catherine, as answered that one. Thank you, Catherine. And honestly, the create block theme is a fantastic resource where it will let you, as she mentioned, let you build child themes from something like 2023. Thank you, everyone. All right, so hopefully that loosely explains why Theme.json. It's an abstraction in many ways away from CSS. WordPress then takes the specification in Theme.json and turns it into CSS on the front end. But it's a framework that then allows users to interact with global styles and settings within the interface, the site editor, and the block editor, which, in a harmonious way, allows you to override things in the theme. But there are going to be times when you can't do everything in Theme.json. That's what this conversation is about. Let's stick on Theme.json for a second. We showed you how to change the background, for example, of the entire site. But one of the things that you'll need to do often is style individual blocks in a specific manner. So part of the style section is a block section in Theme.json. So you can see here in 2023, you can open up the folder in 2023, and you'll see all the different blocks that 2023 specifically styles. So for example, we have navigation, you can see we're changing links, we're changing typography. Let's go down to something a little bit more simple, maybe the quote. You can see that quotes in 2023 have a border. They have some spacing, padding, so on and so forth. Theme.json does a ton, but it doesn't do everything. So for example, border. Border you can do width, style, thickness, color, all that kind of stuff. But you can't do everything that you can do in CSS. Now, there's a great reference here. You mind sharing the Theme.json living reference, Laura, when you have a second? So the great reference that we'll share in the chat in a second, which has everything that Theme.json can do. Borders and elements and spacing and whatnot, all the things that it can do. But if you're really familiar with CSS and you want to do some funky things with CSS, you'll notice you can't do everything in the Theme.json. So when I approach theming in a block-based framework, take Theme.json to take it as far as you possibly can. Try and add it. If you need to style border, put it in Theme.json. If you need to style padding and typography, put it in Theme.json. That functionality exists there and it enables all the other functionality that comes with block-themed. So allow you to change that typography, change that padding, margin or whatever. It's a really robust system and I encourage you to use it. But you will run into scenarios where you just can't. And how do you add custom CSS once you've gotten to the point where you have no other option? There's just no way to do it in Theme.json. That's what we're going to talk about right now. So I'm going to come back over here. What I'm going to do is I'm going to clear reset. Oops. I got to turn this back to normal here. Refresh. So now we're back to this basic 2023. So if you're familiar with theming in any way, the most, and I said, you need to add some custom CSS. The thing that's going to jump to mine, I imagine, is why don't you put it in the style.css file that's in every WordPress theme since the beginning of time. And that's a great place to start. So 2023 has a style.css file. Every theme requires a style.css file. 2023 theme has an empty style.css file. It has the theme name, author, kind of the metadata at the top, but it doesn't actually have any styles. But let's say you need some very custom functionality for your theme. Let's evaluate putting it in style.css. So let's, for example, use the, you know, use our, even though we can, even though we can do this in Theme.json, just for the sake of this, we're going to do background color. How about blue violet? So we want the body of our site to have this background color. To make sure we don't have any specificity issues. And this is another reason why when you need to resort to custom CSS, you're going to have to, in a block theme, you're going to have to manipulate it a little bit because WordPress is trying to use Theme.json. It's trying to use styles in Theme.json. And I just showed you how Theme.json you can control the background color. So in this situation, we'll probably need important, I'm just doing it here to make sure we don't run any issues. You'll probably need important to make sure that your custom CSS for body shows up. I'm going to save this and we're going to come back over here and we're going to refresh. And this works because I forgot to, this shouldn't be here. That should not work. Let me refresh. Okay. So we're still white. It didn't work, right? In order to get the styles to show up in the editor on the front end, you need to enqueue the style sheet. 2023 is very unique. Not only does it have an empty style sheet, it actually doesn't have a functions.php file. Now this is a file in most themes that has some core PHP functionality. 2023 is unique. I think it's the first word, public WordPress theme to not have a functions.php file. I added it before this presentation. But if you were to go download 2023, it doesn't have a functions.php file. But if we want to use the theme style sheet to register some custom styles for our theme, we need to enqueue that style sheet. So I've added my styles here. What I've done is I've added a functions.php file. And then I have some standard functions. Now I'm not going to go through too deeply these two functions. If you want to copy them, you can download the 2022 theme, last year's theme. It has the exact same functions in them because that theme does have a style sheet. What we're doing here is we're enqueuing or loading the style sheet on the front end. And we're also loading the style sheet in the editor. And once I've added my function.php file, enqueue the style sheet in both places. We'll save. I'm back over here. We'll refresh. And we have a purple background. And we can look at the front end. And we have a purple on the front end. So the quickest and easiest way for you to add custom styles to a block theme, again, after you've used theme.json to its fullest, is to just use the standard style.css file, enqueue it using the functions, the two functions for the front end and the editor. Let me stop there. Does anybody have questions about that? This is the most basic way to add custom CSS. Yeah, we have a couple of questions that I've marked previously. So Marco asked, can WordPress sync changes done in editor with theme.json? Or you need to export the theme with changes and replace the theme every time? That is a fantastic question. So let me pop over here. So if I am in, I am in the editor. Actually, let me, let me remove this because we're going to, let me just comment this out for a second because we're going to run into some issues there. Let me refresh. Okay, we're in our 2023 theme. Now I'm in global styles and I start making changes. So let's do the backgrounds, make it yellow. When I save this, this is saving to the database. This is actually not overwriting your theme.json file. However, let's just, because we've had so many questions about the create block theme, I'm just going to download it. So it's saving it in a, its own individual folder. When you say it's saving it in the database, it's not overwriting something. It's putting it by itself. It's saving it in the database much like you would save pages and posts. It's saving it in its own place in the database. So if it's not actually updating the files in the theme, however, when you're developing a theme, that's actually a really handy functionality instead of having to, because I think what the commenter is asking is if I'm here in the editor and I want to save my styles and export them, I can do that. I can come up over here to the three little dots, export this. What this will do is we'll take this, the settings in the database, merge them with the theme, and it will export out and updated files. But then the problem there is then you have to put them back into the, it's just, it's kind of a, it works, but it's kind of a challenging process, which is where you can leverage the create block theme. So this tool allows you to, it's a pretty simplistic interface. And let me zoom in here. What it allows you to do, and this is one that I think is, it's, if you're building a theme, you'll use this all the time. You probably won't use this if you're an end user necessarily, but people on this call who are interested in learning about this stuff, you'll probably find it very useful. What this will do is this will take those changes saved in the database and directly overwrite them in your theme, in the theme that's installed. And this saves a ton of time. So again, I don't want to stray too much into this, into this subject, but the create block theme is really handy for making, taking change that you've done inside of the, and global style inside of the site editor and automatically applying them to your theme. It's a really cool thing to check out. Karen, I hope that that also answers your question too. If not, please resubmit it in the chat. Catherine has a question. Is there any downside at all to adding custom CSS in a block theme by getting to, I'm sorry, by getting, by getting to the customizer in a hacky way, or by adding WP admin customizer PHP after the URL? We're going to talk about that in a second. So hold that question. We'll talk about that very soon, because there's actually a very new way in 6.2, which will, you can still do the same thing without doing the hacky customizer thing. Lisa just commented that the functions PHP file is confusing. Dev also agrees with that. Of the functions of PHP file, just in general, how that can work. And using the, the exclamation important in order to. So let me explain this real quick, and then I'll talk about function PHP for a second. So I'm going to save this and this might work. Let's see. Okay, it does not. I mean, I should reset this. The reason that this does not work with, let me just double check that I have everything running. Yep. Okay. The reason that this does not work, and we can inspect the page, I mean, let me go to the front end real quick and we can refresh. Why are we purple? Why are we purple? Okay. Okay. We are purple because of my custom style. Okay. So the reason I did important is because if we look at inspect the page and we look at body, we can see that there's a couple different body colors that are applied, right? We have the one, this is the one that's coming from theme.json. I know this is very small. And then this is the one that's being added by our style sheet. The way that styles are added are sometimes a little bit tricky, especially when you're working with custom CSS. When you're dealing just with theme.json and global styles, it all works. It all works correctly in terms of specificity. Once you start applying custom CSS, you might run into start to run into some specificity issues. So you can see that here. On the front end, our custom CSS is overriding what was in theme.json. Inside of the site editor does not. Now, you can argue this is potentially a bug that needs to be fixed. But I added important just to make sure that we didn't run into this because the specificity inside of the site editor, which we can see here, hopefully, I know this is getting very wonky and I apologize. But if we look at this body class, we should see my purple somewhere. So see how much styling is in here. I'm not sure this is going to be helpful. But basically what's happening inside of the site editor is that theme.json specification for white is overriding the purple. That's why I added it. But remember, you can do background color in theme.json. So this is one of those situations where using custom CSS for something like a background color is really not advised. You want to be putting that theme.json because WordPress is already applying its own background colors. Now, if you're doing something like transitions or animations, well, that's not in core. So you're not going to run into these specificity issues. And that's where custom CSS has value in my opinion. That's where you want to start adding custom CSS for things that you can't already do in theme.json. Because then you inherently won't run into specificity issues because chorus doesn't do that. And your custom CSS is the only thing applying that. A couple of people were asking, and I think I've done this too on a site. Lisa asked, I had added my custom CSS to the additional CSS area. Is that not a good practice? Okay, because we've had a lot of questions about this, let's start talking about additional CSS. So, Ian, you're probably all very familiar with, I believe this will work. So if I do WP admin, I think it's customizer.php. Nope. And then there's always like the plugins that you can do CSS with too. So. Yeah, one second. Does anybody have the URL for like, oh, customize. Oh, gotcha. Okay, not customizer. There we go. Thank you. Okay, so if you, and I think someone asked this earlier, what if you do the hacky thing where you access the customizer, right? This was in WordPress forever. It still is in WordPress. And if you go to additional CSS, you can start adding your CSS here. This works. Great. Many people, myself, relied on this to do little tiny fixes or little additional tweaks, or maybe you install the third-party plugin and you need some custom CSS just to tweak one little thing. I think, Laura, you're talking about adding a poll plugin for a poll. And maybe you want to change the button slightly. Instead of messing with theme files, why don't you just have a little field where you can edit some custom CSS and you're good to go. This was a beloved addition to WordPress. So how do you work with this additional CSS in a way that is harmonious with theme.json and global styles and whatnot? And this is something that people have been requesting forever and is finally getting added to 6.2. So instead of going to customize.php, what you can do now in 6.2 when it comes out is inside of global styles. We're going to click on this little icon here. It's a little hidden because it's pretty advanced functionality to add custom CSS. But you're going to go to these three little dots. Now, I want to caveat. There's no documentation on this right now because it literally came out five minutes ago. But there will be. So don't feel like you need to remember this. There'll be more documentation on this. But you're going to click on these three little dots and it says additional CSS. You will now have a field where you can do additional CSS. So we can do body. There we go. So where I was running into specificity issues before by adding my custom CSS to style that CSS, this additional CSS panel works harmoniously within the whole system. So this is the first iteration. You'll notice that there isn't syntax highlighting yet. And it will be really nice if it opened up in a modal so you can see it a little bit better. But this is the very first implementation of custom CSS within the site editor. I fully expected to continue getting better and better. And yes, Peter is saying it's available in the Gutenberg plugin if you want to test that out. So it's been available in the Gutenberg plugin for a release or two. But now it is officially in the beta one. Another thing. Is there any limitations of the amount of CSS you can add to that customized PHP? No, this is you can pretty much go wild with it. And I think Chris is asking, I expected a semicolon after the green. That is that would be correct. So if you had like the full syntax highlighting of the customizer that we had before, I would probably tell you add your semicolon. I believe if I do things like this, yeah, they're working on adding some more functionality for error notices. So if you write incorrect CSS, this is the first iteration. It will be improved. Is there a limit to what you can add here? Nope. You can just add whatever you need. Assuming you know, for example, let's pretend that you had an example plugin had like a certain CSS selector. I don't know, example title or something. You could add your custom CSS rest right there and it would, you know, it would get applied. So it's very, it's the idea is that it's going to be the same as the customizer additional CSS eventually. One of the things that I think is not working, is not set up to do right now, but it'd be great if you already had CSS inside of your customizer. It would automatically pull that over. I think that would be really nice. So this is the first step and it was tricky because to make it all work within this new framework of theme.json. So it's great to have. We'll see more improvements in the future. But I do want to note one thing that's really cool. So one of the hardest things in writing custom CSS is knowing how to target individual blocks because they each have their own individual CSS selectors and knowing what those are can be kind of challenging. And if you're going to be writing an actual, and we'll talk about an actual style sheet and target blocks directly, you'll need to know those. But there's a cool new functionality inside of the coming in 6.2 and available to test in Gutenberg is per block custom CSS within the interface. So if we come back over here and we go down to blocks, I'm going to go to let's do let's do headings. One of the other cool things in 6.2 is you get this little preview. So any changes that you make will show up in this little preview for in this case headings. But you'll notice now that there's an additional CSS option. So I can come in here. Now the cool thing about this is you don't have to remember what the CSS selector is to target a heading. In this case, the heading is pretty straight forward, but if a specific block with a specific block CSS selector. So what I can do here is I can just do color red. And you can see that the color is now red. And I didn't have to say, you know, H1 H2 or WP dash heading block, you know, so on and so forth. So you can just write straight CSS here. Now there's also a way to this syntax is a little bit wonky and there'll be documentation on it. So I found it a little bit a little confusing at first to work with. But if you do something like this and so folks that are familiar with SAS will probably jump on this pretty quickly. But if I do and hover, I don't know, color blue. What this is saying is that when I hover over it, I want it to be blue. And this should work. Hopefully it does not work. Let's see. You need to save it. No, I'm wondering if this is in Gutenberg. It hasn't made it into six point in the beta yet. I don't want to distract us. But in theory, what you should be able to do is use the and or the ampersand to then target other things like hover, internal elements and whatnot. I don't want to go straight too down and far down that path because it's brand new. But the idea is basically not only can you add global custom CSS, within the site, within the global styles in the site editor, you can also do it at the block level, which is really cool. But I was asking that additional CSS is that stored in the database also? It is. Now, this is I find a little wonky. If you let me show you, I'm going to clear this all out. Delete all this guy. Save. Okay. We're reset to default. This will get saved in the database. But we talked about theme.json. And theme.json powers global styles, site editor, so on and so forth. You can actually specify this CSS in theme.json. I'm not really sure how I feel about it from like a workflow perspective because it's a little tricky to work with if you're a developer and you're trying to develop themes. But let me show you how that works. So I'm going to come over here and we're going to go and we're in our theme.json file. I'm going to collapse blocks. What I can do now is I can add CSS and I can do something like this. I can do body. I don't love it because it's just a string of CSS. But it works. And this is how if you were to export it, export the theme, the styles using the create block plugin, this is how it would export that. So we're going to save this here. And if we come back over, give it a refresh. Now we can see it's red. And when I come over to styles, I go to my additional CSS. And you can see that it has, let me see if I can zoom in here. You can see that it has theme, custom CSS start, theme, custom CSS end. This is pulling it in from theme.json. So just know that that's how it's getting saved and that if you export it, that's where it will end up. It will all be encompassed in theme.json. Writing strings of CSS is pretty challenging. So what I would recommend if I was going to be building a theme and I wanted some little bit of custom CSS, I would do everything inside of the editor. I would write out my CSS here. And then when I'm ready to go, I can export it all. And I get my nice theme.json file. And it's already compiled all that into a string. A little bit challenging to manage. But if you don't want to mess with writing CSS in a file, you just do everything in the site editor. You can see your changes. And then even you're done your export. There's a lot of conversation in the chat. But I know that you want to move on to finish presentations. Yeah, let's see. We got in one place. Yeah. So there's a lot of questions like, okay, well, if you're going to start adding custom CSS all over the place, how do I know where things are and edit things? I mean, there's a lot of conversations around workflow. So my recommendation is to use something like this sparingly for one-off little tweaks, things that you install a third-party plugin, you need to quickly make some changes. Very similar to the way that we... Well, I used the additional CSS in the customizer. It is not a place, I don't think, to basically add a style sheet. You know, write hundreds of lines of CSS. It's really a place to do quick fixes and little things like that. Exactly. I tend to use the customizer for plugin-related style changes. Absolutely. That's the great place for it. Okay, so let's talk about custom CSS in a bit more of a traditional sense, not editing it in the UI, actually writing CSS and directly writing CSS style sheets and then enqueuing them. So when you're working with a block theme, most of the styles that you're going to need are to style blocks. And how you style blocks and the best way to style blocks is, in my opinion, there's really one way of doing that. And that's with per block style sheets. So let me just clear this out real quick. We're going to remove this. Let's give this a little refresh back to the beginning. So a per block style sheet is a style sheet that is only rendered, it's only loaded to the page when the block actually exists on the page. Now, for those that have used SAS or things like that, where you have style sheets that are broken out on a component basis, so instead of having one style.css file and it's just a thousand lines of code, you have individual style sheets for each component of your site. Then there's usually a build process that compiles that into one style sheet or so on and so forth. Because we're working with blocks, you know, everything's a block and a block theme, if a page doesn't have a, I don't know, a forum, I don't know, a query loop block or it doesn't have an image. So there's no images on the page. But you have a bunch of custom styles for images. It'd be really nice if that CSS wasn't loaded to the page because there's no image on the page. You don't need that CSS. That's where we can, and theme.json does that. So when you have all those styles in theme.json, when there isn't a block for the relevant styles that it's generating, it won't load. Now, we want to do the same thing when we're doing custom style sheets. And that's called per block styles, style sheets. Now, there's a really good resource. It's called the WordPress developers blog. It's still in beta. But I don't know when it started, maybe a couple of months ago, and they're generating a ton of great content. And one of them, which I love, is this article by Justin Tadlock called leveraging theme.json and per block styles for more performing themes. And we're actually going to use the examples in this article. So then you can go back and read the article if you want more information or you get stuck on a step if you want to try this at home. So he goes into some great reasons about basically what I talked about, why use theme.json, why leverage theme.json. But in the case where we need something custom, we'd work with per block styles. In his example, he has a per block style for a group block. He wants a group block to have a bit of a unique aesthetic. So what we're going to do is come over here to our theme folder. You can organize things however you want. But what I'm going to do is under assets, I'm going to add a new folder and I'm going to call blocks, move that to assets. All right. So now we have a blocks folder. Inside of here, what I'm going to do is I'm going to start adding a style sheet specifically for the group block. We'll do a new file. We'll do group. Now I put core in front of it just to denote that this is a style sheet for the core group block. This what we're going to show you works for any block. It could be third party, whatever. But in our case, we're just going to target the group block. So this is going to be a specific style sheet that has custom styles for the group block that we only want to load on the page when there is a group block on the page. Now, let's just go ahead and copy this. Actually, I can't copy this, can I? Justin, you didn't include the code in the thing. Okay. So there's another file. There's another article that Justin just also wrote really showcasing Justin today. And that is creating custom block styles. So I'm going to drop that. Actually, Lord, do you mind dropping it? It's the second one, third one to the bottom. So, okay. So this is his article on custom block styles. We'll talk about block styles in a second if we have a chance. But hopefully the code is here for what I want to do. Okay, perfect. All right. Looks like we are... I'm just going to make up the code because I want to use the group block since I just talked about it. But what I'm going to do is I'm going to come over here to this group style sheet. And I know because I've looked this up and I've looked at this article that in order to target a group block, I want to use the selector wp-block-group. Now, every group block in WordPress has this selector. Let's do... I'm really in the background color today, apparently. We'll do background color. Again, we'll do blue violet again. Now, of course, you can add background color directly to a group block, but this is just for example purposes. Now, I want this style sheet to only render when the group block is present on the page. I don't want it to... This is the benefit of putting it over into your generic style sheet, because this style sheet will load all the time. But we only want these styles to load inline when the block actually exists. So what I'm going to do now is I'm going to use the functions.php file. And I think some people ask that the functions.php file is kind of confusing. It is. It's kind of the kitchen sink of PHP functionality. You can put anything in the functions.php file and that's just where you put things in WordPress themes. So we are going to drop more things into the functions.php file to do what we want. Now, the code for how to load these pro-block styles is included in this article. And we can see it here. So I'm just going to copy this over. And we'll talk about what this does. So what this is doing is it's just a function that's being called on the init hook. And inside of that what it's doing is it's saying load the block style for core group, which is the core group block. You need to give it a handle. And normally it's just whatever your theme name is. We could do something like... I think I'm using TT3 for 2023. This can be whatever you want. And then you need to tell WordPress where to look for that style sheet. And you can see here, we're providing the src and the path here for where that style sheet lives. And we put it in assets. We put it in blocks. And we put it into core group, which is exactly what you see here. So all we're doing is we're saying load this block style when it exists, when the block exists on the page. And here's where you go look for that style sheet. So we'll save this. Let me double check. We're still good. Yeah, all good. Now, if I come over to... Let's go to our page here. Just build a purple background. We'll keep going with our purple background here. Actually, we can't go with our purple background because let's see. Oh, the purple background is loaded by our customer. Okay. All right. We want to get rid of that. So you're getting too much custom CSS. Well, I can actually demonstrate it right here. See how these are purple? This is actually due to that per block style sheet. And to prove that, let me come back up up here. We'll change this to blue. Give it a refresh. And we see blue. That's because if we look at our list view, there are groups in here. And we said that whenever there's a group block, set the background color to blue. Again, you don't want to be using this for background color because you can obviously come into group and you can set the background color to whatever you want or use Theme.js to handle this. But this is a quick example of how you can use an individual per block style sheet to render custom CSS. And this is really handy. And this is why I wanted to pull in Justin's article, is when you're working with block styles. So he has some interesting block styles which you're probably familiar with in the editor. And he has one that looks like a hand-drawn image. Well, that's really custom CSS that WordPress will never be able to do in the UI. So what he's done for the image block in this case is he's written a whole bunch of custom CSS specifically for the image block. He's done exactly what we did here, but in this situation, he do it for image. And he's added it here. And he's registered it with a per block style sheet. So whenever there's an image on that page, that style will load and then it can be rendered. I know that was a lot. So does anybody have any questions? CSS everywhere, like a treasure hunt. That's actually a really good point. I've showed a bunch of different ways that you can implement styles. And I want to back up for a second and maybe share how I approach styling and WordPress with block themes specifically. I never place anything almost never. There's a few situations where you need some global resets. Sometimes like what's a good example, for those familiar with box sizing, sometimes you want a global reset for box sizing, you might put that in your style.css file. But basically anything that's completely global, put in your style.css file, like you would any other theme. Leverage theme.json to its maximum. Use it as much as you possibly can. Then once you're done with that, then make use of per block style sheets to provide custom CSS to individual blocks that need some additional customization. At the end of all that, you can use the additional styles within the new additional CSS for little one-off tweaks, little one-off changes that you might need for a third-party plugin and whatnot. And honestly, if you're building a theme for customer or something like that, maybe you add it quickly to make that change. But then what I would do is I'd come back into the theme and update that at some point in the actual CSS. I do want to note that per block style sheets that we see here do work for third-party blocks. So if you are using third-party blocks that aren't core and you want to register some custom CSS, you can use the exact same approach. Inside of the functions file, you just change the name to, oh, I don't know, I know Yoast SEO has a bunch of blocks. You do Yoast and whatever their block name is. And you could register a custom style sheet for that third-party plugin, third-party block, I'm sorry, and it would only load whenever that third-party block was on the page. I'm really just touching the tip of the iceberg on per block style sheet. So I encourage you to go check out the two articles on the developers blog. I don't want to shill my own work, but I do have another article on per block style sheets. If you're using SAS to build themes, you can combine per block style sheets really well with SAS. And you can set the whole thing up. So I have, let me drop that in here. This article also shows you basically the same thing that Justin's article shows you, but then it also has a SAS component on how I would set up a block theme that not only use per block style sheets, but also leverage SAS in that approach. All right, we only have three minutes. Wow. So does anybody have any questions that I can't? So let's see here. There's one from Peter. Does the block styles UI supersede the per block style sheet settings? So I'm assuming when you say block styles UI, let me refresh this, you mean like these block styles? So if I was to change green. So the per block style sheet should override this. But the thing is that in many cases, what I would put in a per block style sheet wouldn't be something that can be controlled with an UI. Of course, you can do that if you like, but it wouldn't be something you control in the UI. Now, I cannot give you a definitive answer that it will always work 100% that way. There's a lot of moving parts we have, you know, per block styles, we have user styles, all sorts of stuff. But if you use the mentality of use theme.json as much as humanly possible and allow users to modify styles as they would like and keep per block styles to custom styles to something very specific that you can't do in the UI, that's kind of the methodology that I approach and everything works pretty well. Dave was asking, does per block style sheets load as individual fields or files on the front end? Okay, that's a great question. So you see this path here? So if you remove path and you just had SRC, it will load as a file. It will enqueue the file. If you do path, which I strongly recommend, he will add it in line. So by adding it in line, you don't benefit from caching per se, as you would with, you know, standard caching, but usually these the styles are very small. And especially if you're using something like SAS to minify those individual style sheets before they're actually in production, the performance is virtually negligible. And this will inline all the styles. So I always like to use path. If you don't use path, it's going to it's going to add an individual actual file for each one of the style sheets. And then Ann says, once you like a block style change that you made, could you save as a reusable block to repeat the style elsewhere? Yeah, so if you're working within, so we're kind of moving away from custom styles a little bit. But if you had a terrible example, let's say that you really like this blue paragraph block and you wanted to reuse it again, you could, let's make it a little bit different. We can make the size bigger, give it a background, right? That's terrible. Give it a background. You can say this is a reusable block like you would normally and use it wherever you want on your site. Now, if you had custom CSS that was targeting the paragraph block, well, it would also target the reusable block because it's also a paragraph block. Reasonable blocks are great. And I think that doing it in such a way where you're copying styling, I think, is pretty cool application of that. But you are reminding me of something that I think is very important. So we're going to do, we're just going to add more information for you guys here. Let me add another paragraph. One of the really cool things, and this isn't custom CSS, but it's styles, one of the cool things in 6.2 and you can test this in the Gutenberg plugin is the ability to copy and paste styles. So you saw here that we have text, we have background, we have size. If I wanted to do the same thing on this paragraph, it's really annoying, right? You got to click, change the color, change the size. I could of course duplicate, but what I want to do is I want to copy these styles to the other paragraph. You can now do that. So if you click on the three little dots, you'll see that it says copy styles. Go down to the next one. Oh, shoot. Okay. I'm glad we ran into this. What should happen is when you paste styles, it will paste the styles. The way clipboards work in browsers, you need to be on a secure browser. I'm in a local install and it's not secure, so I don't have a little lock symbol. So that doesn't work. But if you're on a normal site, normal hosting, that will work. You copy and paste and it will come over. So it's cool if it works. Yes, 100%. You just need to make sure you're on a secure browser and then it will work perfectly. Should work perfectly. All right. I think we're a little bit over time, but does anybody have any last minute questions? Any way to bypass that when doing development? Yes, there is. I use local and if you're in local, there's an SSL trust. You can click trust and you have to approve the certificate. You just have to follow the prompts in local and it will make it secure and then that will work. So I just didn't take the step before this presentation. I apologize, folks, but that's how you do that there. Yeah, I do that when I'm trying to test the site and security and stuff when you have to copy the URL and put it into a third party. They want it secure. So, yeah, clicking on that little trust thing helps with that. Yeah. So one quick question. Sergio is asking if there's no way for WordPress to ignore it. I believe it's actually a browser thing where the clipboard API that handles like clipboard copying and pasting from a security perspective, you just have to be on a secure browser. I don't think it's really a WordPress thing per se. It's more just browsers and clipboards and that sort of thing. So, all right. Well, thank you everybody for coming. I know we covered a lot. So if you have questions, feel free to drop them in the meetup chat or reach out to me on Twitter or, you know, and I really encourage you to check out that WordPress developers blog. There's a lot of great content there and more coming along the way. And as always, give 6.2 beta 1 a try. It just came out today. You can also test out the Gutenberg plugin to try out some of these new features. WordPress 6.2 is coming out, I believe, on the March 28th. So between now and then, it's a time where we find bugs, we find things that work properly and we get them fixed. So if you do find issues and you're comfortable adding them on GitHub to the Gutenberg repository, please do so. If you find a bug and you've never done that before, just ping me and I'll add it. But if you find problems, we'll let somebody in WordPress now because it's the time we really want to test this stuff. We want to make sure it's stable so that we have the best release for 6.2 possible. So again, my name is Nick Diego, developer advocate at WP Engine. Thank you, Laura, for co-hosting. And I hope you all have a great day. Thank you, everyone.