Attendees chatted about cool new features and handy tips for styling sections in WordPress 6.6. They also swapped stories and ideas on how to handle theme styles with section styles. The group shared their experiences and brainstormed ways to make pattern management and theme building in Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ better. They stressed the need for smoother workflows, more user-friendly options, and greater efficiency, touching on challenges like tweaking block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. styles and setting default ones. They also tossed around some possible solutions, like breaking down partial files, registering block style variations, and using a JSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file to nail down styles for default block variations.
There was also a discussion about the need to be able to set a block style as the default for the content creator, so every time a particular block is added to the canvas the block style is applied automatically. This will help with curation efforts, and streamline’s content creation workflows.
One challenge immediately clear to attendees was that the interface becomes heavily overloaded for users. How do you avoid having all the section styles on every group block?
Currently, the block style variations that power the section styles are limited by the same constraints in theme.json. So they can only be assigned to a block type. Ideas discussed:
One solution for this is to have only a few style variations that are aligned with the color palette of the site, so the buttons say blue, black, white, and gray. And then the user knows that they can apply a different color setting to the pattern and it would change predictably. The code example for such a system is on GitHub.
This leaves the question of how a user would see the style variations when they add patterns, as there are no style variations preview.
Watch the video for a more detailed discussion. Below you can also find a transcript of the recording.
Transcript (via AI)
Computer, you are alright, so I’ll do the introductions again, just briefly. We are here to a hallway hang out on six and section styling and other block style variations. And, yeah, this is going to be, I’m handed over to Justin to kind of kick us off with some remarks and some , ideas, and questions. So in the chat, you can have your , just tell us where you’re from and , if you want to add the questions in the chat. But I think we have a small enough group that you just can unmute and ask your questions, that will be great. We also have here Aaron Robertshaw and Nick Diego and all the phenomenal block theme developers, so take it away. Justin,
All right. So hi everyone. Like usual, let’s try to make this a discussion where everyone can, you know, chime in with your questions, your issues you’ve already ran into. But the first thing I want to know, who has not tried out style, very section styles, or, like some updates to lot style variations in WordPress, 6.6 beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Or we’re at the release candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)., yeah? Or is there anyone who hasn’t, yeah? So we’re all on the same okay? We have one person saying, I do all right, all right. So I think the best thing to do is maybe just do a really brief walkthrough of what we’re talking about. Just okay, we have a couple people who haven’t now, I think that’s the best thing to do. And all right, we do. I do have a blog post. We also have a developer hours where we covered some of this. If we can link those in the chat, someone and Okay, so section styles. This is what we’re saying. This is the new feature, kind of in WordPress, 6.62 style, like an entire section of content. In reality, it’s not much of a new feature as it is an extension of the existing block style variations system. So if you just look at my screen, you see I have, like, this big green, greenish background, green, blue, teal, whatever color that is. And you’ll notice, like, there’s it’s got white colors. And if I just scroll down my page, there’s a whole different color, you know, with a different green and, you know, different and if I keep scrolling, there’s a whole nother section. That’s kind of why it would like text. And if you also notice, like in some of these sections, like my button, colors change depending on what section you’re looking at, and anything nested within the section styles can be you can customize the style of those things too. So what we’re really talking about and with section styles is we’re just talking about the ability to style things in an entire section and the things that are nested within it, whether that’s elements or blocks, and they appear in the UI User interface, just like any other block style variation. So if we quickly look, I can switch to style two, style three, which is not a whole lot different in this thing, but style four is very different. So and if you kind of watch closer, you’ll see like the colors of the buttons and other things may change depending on the style. So we’re we were very much styling nested things and oh, I have zooms in my way on my screen. I’m trying to click. There we go. And these can also be created within your styles folder, your theme. I’ve actually organized these into like style slash block. And this is, for example, section one, and that works just like a theme JSON. There’s a few extra things. You can set multiple block types, and you can set both the title and a slug the slogan. Block types are very new. And then you have your your normal styles property, which you can add css. You can add colors, spacing elements, and you can go down, scrolled a little fast. You can like, specifically target, like a block. How can this case, post title? You cannot add. Settings, which is a question that came up this morning, but you can add styles. So there several other ways that are outlined in the article on how we can, you know, work with the this new system. Like you can still register VHP via php. You can even past, like a themes JSON, like object and PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher. So where we, uh, I feel like that’s just like the really quick, uh, overview of what we’re talking about. Like I said, I want to make sure this is very much a discussion now, of like, What problems have you had? Or what it what have you, especially if you’ve been using this so far,
I have a question to just prompt discussion. Okay, as you’ve been building these, it looks like you’ve, you’ve kind of kept to color for the most part. Are there any kind of heuristics that you when you’re building section styles that you’d like to follow? You know, is it, you know, there’s certain types of styles that you like applying and using in Section styles? Yeah.
Um, so I actually have several examples. The ones I show were primarily color. I think that’s the most the best use case, because color I’m trying to that that tends to be the best use case. Let me look at some other examples where I have run into trouble. So this is, like a grid layout. It’s got pricing cards. This actually has, if you don’t know, this is one section style on the outside. This is one section style for each of these cards. And then there’s one section style for this, like background like this, like where the price is on the card here. Like there’s an entire other section style. But one of the things I ran into is some some of these, like, I have this border on this. I don’t like the border in all situations. So then I start thinking, Should I add, you know, so should my section style to automatically output a border, I don’t know, because it works in some situations. It doesn’t in others. In this case, I kind of cheated a little bit and just added I have a custom CSS Cascading Style Sheets. class has global border that I can, you know, remove. I don’t, I haven’t figured that out. But yes, color is the primary thing I’m using them for. I think that works well across depending on how they’re used. But yeah, so there are situations where I don’t want that border. That’s just a problem I’ve run into and trying to solve that means having to go back from using, you know, a section style, to either using a custom class or actually using, you know, the border controls. My goal is to not ever have to touch these design tools at all. I don’t, I don’t think this. I know. I think it’s okay for users to touch that, but as a theme, we’re talking theme development here. I, I would, I would try to avoid using inline styles at all. There are some situations where you need to, like, I think padding, spacing, things like that are mostly okay, because those are not going to change. Like, for example, I have this screen card here, and I want to, I’m actually looking at the wrong I don’t click on the wrong thing. And so if I change this entire card style, like, my spacing is not going to change, right? I don’t need it to change, because this is one layout. So I think it’s okay to like style this card and like, if you wanted to come in and add, you know, whatever spacing on certain sections. And I think your fonts are usually okay. There may be situations where you want to style fonts for specific section styles, and I’ve done that as well. I think I have an example if we look so I use section styles also for things like my, I have a new mouse I’m using, so I’m I can scroll really fast, sorry. Like this is a section style, this little post byline here, or you might call it post meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., or Dateline or something in your theme. So. The thing is that I don’t really care so much about colors. I care more about fonts. And there are situations where I will style, you know, nested, nested blocks for that. So this is using my meta style. I’d use that for comment like in the comment as well, for like the Comment author, but not in this particular theme. I don’t have it, but, and one I have where I have styled the like the specific author block. I think the use there’s just so many, there are so many use cases to cover. You can literally do anything you want to. And that’s kind of a double edged sword. What, what should you do and what you should not do? I would start with this new feature, starting with colors, just seeing what you can do, like with a background color and a foreground color or text color, and seeing how that affects, you know, other elements. So if we go back and look at section one for my theme, at least. So I started here. I started with, you know, custom background, custom color text. I also have some spacing that I can probably remove now. But then I thought, Oh, my captions in my main theme JSON are styled differently. Oh, I need to, like, I just use current color. And I’ve done that a lot, but there are situations you need to make sure to test everything, like, test your captions, test your citations, headings, of course, test your links and what their color should be. And then you’ll want to test blocks so it can get complicated very fast, just with colors alone. And so that’s when I say, start there, and then, like, make adjustments based on what your specific project needs. Alright. Would we have anything going on the chat or we have questions? Oh, what Justin said? Let’s see from Brian.
Well, I have a question. So when you go back and to one of the other ones, I see kind of six or seven or eight different styles in there. Are there really all different styles? Do you? Did you just kind of put them all in the style variations, and they’ll they’re all for all blocks or, or they’re all three container blocks, or, okay, also for others, yes,
so that’s a good question. In this situation. What you see on the group here? These are almost all what I would consider section styles. They are on container type blocks, like I have a I have them on a few I know some people probably wouldn’t recommend putting them on the query block, but generally on Container blocks, like, you know, group column, you know, columns, maybe media and text for Section styles and so all of these are for those sorts of block, container type blocks. And I’ve been trying to cut back. It would be nice for the theme I’m building. I’ve also been building previous to this feature. So I’m also, you see a lot of these. There’s probably some situations where I can get rid of some of these, and I have gotten rid of some. Like, I have one just for selling, like, the archive page header, like, so if you click on Justin Tadlock, you know, this is a style, but theoretically, I could probably just make that like, you know, this style too, which is very similar, you know, this got the same gray, you know, that’s one thing I could do. But I could also leave them separately. If I wanted to style them separately. That’s a project level decision. But I also think to really take advantage of this for like, from a UX User experience user perspective, it would probably help to cut back as much as you can on like these options, I feel like this, like, what is this? 12345, 10 options, that’s quite a bit, that’s a little bit of a choice overload.
Yeah, yeah.
I think Carolina has a similar question. So there’s, how do you avoid having all the section styles on every pro block?
And, yeah,
yeah, that’s my like, I wish I could have, I don’t know how to avoid that be I wish I could, like, remove this archive header, remove the site footer and site header, because they’re not needed, except for in very specific situations. And the reason I have those. Are because there’s no other mechanism and core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to style these, these, like these, pretty common sections and themes through theme JSON, other than, you know, maybe like some custom properties or stuff like block style variations are the best way to style those, those sections that are kind of one offs, like archive, header, site footer, site header. There’s a very much one off things. They don’t really need to be style variations, but there’s no I haven’t found a more ideal way of styling them without custom CSS and so on.
I just had an idea, yeah, because you know how with like patterns, you can do like inserter false or inserter hidden, so you can have a pattern that’s like part of the theme, but not represented in the UI. One of the things that I’ve done a ton with block styles is basically create the class. And this is not, this is not with section styles. This is just being CSS. Basically have, like, hidden, quote, unquote block styles that are only handled by the the style by the the class. Maybe it’s a terrible idea, but it’d be interesting if you could do a block or section style, or block style variation that was, like, hidden from the UI. So, like, the class could still be added, you could still register and theme by JSON, not theme of JSON, but in a JSON file, but it was just hidden from the UI. That’d be kind of interesting.
Yeah, I love it. We need a ticket Created for both bug reports and feature development on the bug tracker. right now. So, yeah, I mean, I have use cases for that sort of thing. And I mean, we’re seeing those use cases that work, and, you know, in real time here, like the archive header and like my site footer, like, say, site footer on this theme is like, got this grayish, you know? And I want that. I also want users to be able to style that, like, just change it to you if they want. So I don’t know I would like this for that. So let’s, let’s make a note of that for we need a ticket on maybe hidden blocks. Or, you know, it doesn’t necessarily need to be hidden block style variations. At least, needs to be some way to style things custom through theme, like a theme JSON, or, you know, that similar mechanism for whether that’s hidden or or just some other like, you know, property Within theme JSON or something. Yeah, great idea. Nick, I Yes, all right, looking at the chat a little bit, but yeah, use the hidden classes. Works already, and that does, yeah, you can use hidden classes. And I do a little bit of that, trying to think like I will add, one thing I do is, like custom properties, you know, under in theme J sign, you can add, like, I even have things handling, like custom elements, because, you know, core doesn’t, you know, I can’t style inline code, you know, through theme JSON, so I can do that. And that creates a, you know, custom class. And I could show you the custom class really quickly, so base elements, so scroll up and look for my code section. So in that creates, like these custom classes. I mean custom properties, I mean, and you could do that with class custom classes as well, so that, you know, all of these are generating the, you know, custom properties that are used in mycs style sheet. That’s kind of like a one way to get around some of those limitations. And I could very well do that with like, the archive header and site header and so on. And I have, and I’ve done those that way, until I moved them over to like, the like we have the section styles now. So I’ve moved like archive, archive header, site footer and site header over to this newer system, if that makes sense to everyone. All right,
so Aaron also mentioned that there is has been some discussion on defining a scope property in the theme JSON parcels that might allow filtering the context of the section styles, and I think that will be a really good, standardized way. But Erin, would you have by any chance the GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ discussion for that?
I would need to go digging for that one. Yeah. I. Can,
I think it was just hoping that you maybe have it just in front of you so
but what I can share there was the the general thinking was that to bring it in line with, like our templates and patterns, etc, that we could just sort of indicate more generally the context that a variation might actually apply. So it’s not a complete, powerful filtering mechanism, but it would be the next step or the next iteration, to build upon this feature,
to dovetail on that briefly, we do have the filter I’m putting in the chat. We do have the filter used for other things that allows you to, like, conditionally display block supports based on context. Like, you could have a button block that only shows specific color palette went inside of a group, or something like that. That’d be kind of cool. Like, if you had, like, if you knew that a group was inside of a cover block, that group would only have a certain set of blue section styles or whatever, using the context of based on where that block was, just as some prior art sharing that of a filter, but that’d be cool.
Yeah? Brian Gardner, what do you have?
Oh, that’s a loaded question,
yeah. Why did you raise your hand
so that I can personally ask Aaron to make sure that slashing thing can get pushed into RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). three. No, my encouragement, based on the way, more hours than I probably should have spent working on this, and several conversations with people who are even present on this call, is that Inception can happen very quickly with this, and that the at least, for me, from a product perspective, I’m trying to, like, narrow the scope at the beginning and just use it for one sort of application. Because you could just open this up and, like, you know, have a section style for this and the color stuff, like, all of a sudden it gets really confusing fast. And so for those who are exploring, I would just say to temper, like, the scope of your initial use of it until two things, one, you understand it better, but also more things get developed, and there’s more sort of support beyond just the 6.6 release, because there’s more coming from what I understand in terms of, you know, creating possible GUIs for like, editing the content of These styles through the dashboard, versus like code. So, yeah,
it’s a good point. Yes, so before Carolina, there’s also Tammy had the suggestion, so just bring them up to parity with patterns. I think Could you elaborate on that a bit
that was relating to when Nick was saying about the ability to hide and stuff. I was way, way ago, so I think Carolina’s probably in this time frame, rather than in the back show. Yeah,
sorry, I didn’t get to all right? Karina, so
this is a more of a wish list item. I would like to be able to quickly change my patterns, instead of having one red and one blue pattern, whether they’re synced or not, actually going to have to be synced the very day. And I would just click the button instead of going into having to edit the original pattern, for example, to change the colors in two or three locations. So it’s not only about checking whether this style is on a group, it’s inside a cover block. I want my whole section to be complete in a pattern, bottom part, but patterns first.
Yeah, Brian, you said you could speak to that.
Yeah. So thankfully, the Fourth of July holiday has afforded me some days to play with this. So I have updated my powder theme to essentially powder has always shipped with two different versions of patterns, white on black, black on white. So it’s made it very easy to work within a design system, to just wrap every pattern in a group. And my goal, even though I still may not do this, my goal, was to half the number of patterns and just basically apply section one, two or three to the pattern, and it would control it top to bottom. I don’t love the I love the simplicity of shipping half the code. But what I don’t like is that users don’t see that inside of like the pattern explorer, so there’s no way to show like every pattern I’ve got created, headers, footers, call to actions could essentially be four different flavors, right? White, black, gray and purple. I can insert a pattern and in one button, just as the video I showed, just change the whole pattern into the way I wanted to. But the users don’t see that when they go to add the pattern into the thing. So there’s a little bit of an education that says, add the pattern and then change the color, as opposed to seeing four different colors of each version in the pattern. Explore. Or and the only way to do that is to ship four times the amount of code, which isn’t ideal, but it also, from the marketing perspective, might be more appealing. So you kind of have that, that wrestling. But I’ve, you know, wrap everything in a in a group, and I’ve limited all of my section styles to just the group block. Like, my intent is to just say, this is basically a pattern Color Changer. Like, I don’t you know what I mean. So, yeah,
yeah, I’ve seen some of Brian’s use cases too. So, yeah, yeah, I don’t like the idea of shipping patterns that are basically the same code with just like one little aspect change, and then it does cramp the UI a little bit. I think, yeah, we do need some workflows in core, like with around how like themers are using this feature. And we’ll get more feedback, I’m sure. So definitely open tickets, you know, Gutenberg tickets around, like, your ideas and stuff, so we can, you know, talk them through, and then I have other people come through. I think that’s this an implementation problem, but we can, but the more like Gutenberg itself and core can, like, take care of, help us out there to be with the great Carolina you’re back up.
This is more about the reflection on you source, not being able to see the style the preview. So when you when you’re in the editor, you have your style buttons. You hover over the button, the preview is not good enough. And I believe there’s a suggestion to even remove the preview, which I’m against, because this is also one of my my pet peeves. However, you say that in English, pet peeves text in the button is not enough, right? I can’t fit my description for the style name on my button, and I can’t name them, style one, style two, style three, because it’s not enough context. It doesn’t tell anyone what style one is, unless you really you add it and then you have to go in and do it or whatever, because the preview doesn’t work, and if you add it again, you have to do these extra steps. So I would really like to see that part improve.
Yeah, plus one, yeah. Yeah. So it’s actually my comments basically mirror what Carolina just mentioned. I think that the I’m interested in how users, once things like powder go out in the world, in the world, and other examples, whether like, even in the in the upcoming 2025, theme that might include this functionality, like how users react React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to it, because it’s not that many themes use style variations, block style variations, like 2024, is a handful. Like, there’s like the asterisk for headings, and, you know, there’s like a list style. But like this concept of like, changing entire sections, changing the color of them from a user perspective, is very new. And so, like, the default is like, Okay, you go to the color, you change your background color, you change it, you know, you click through all the things and you update it that way. So I think this is a very new thing, not only from a theme development perspective, from a user perspective, and without improvements to the preview or the presentation of block styles. I’m curious how users are going to receive this and actually use it, and maybe things like powder, a great example. I think I like what Brian did with his naming convention, because the names are tied to the names of the colors in the color palette. So at least there’s a little bit of a mental model there where you can kind of tie, oh, oh, this is primary. Maybe that relates to color. Okay, you know. Okay, click primer. But I don’t like UI where it’s like, choose your own adventure. You just kind of are clicking things to figure out what they do. In the little experience that I have, like users are very reticent to click on something that they don’t know what’s going to change and so, and because these are such impactful changes, where you know, changing the visual esthetic of the entire section, new users might without having more context around what the button does, might be reticent to actually end up using the feature. So I think that there’s in future iterations and improvements to how block styles are visually displayed, I think would definitely go a long way in making the feature more user friendly. Yeah. So,
alright, yeah, agreed. Tammy,
yeah. For me, I think it, I don’t know if storybooks the answer or style, but storybook as but for me, it’s about stopping seeing it as a side panel that has things in, and start seeing it as theme design system. And because the problem of scaling of our interface, I go back to this problem is solved outside of WordPress in design systems. So if you want to see a different component and difference, it works in design systems. So it’s not a problem that hasn’t been solved outside our space, and it’s a language that has already been solved. So it’s about, probably, it definitely is about our interface changes, and it’s definitely about having a changing of the each component, and then talking like that, the theme component, and people knowing that they can change that each time. That is also part of that. I think, rather than seeing it at this side, I cheerfully would like both the preview and the block styles. I don’t think either those work for me. User Testing. I’ve seen so many people just I don’t think the previous solves it. I don’t think the buttons solve it. That whole thing be working. I honestly think it is more browse the styles as they are, pick them in a more like book format and design system, because that’s what has worked into time and more it. But I’m open to any hair brain schemes we want to have in between that. So yeah, but I do think it’s that like being able to see the thing and see it changing, and see that it’s got different changes. Could even just be that point one. See that it’s got like, four styles. You know, those little things like, this thing has four style changes. Boom. This thing has three style changes. Little, little things like that. We can start trying and see what people adapt to, I think, is really curious, but we start thinking more in the systems, and start being invested, like, the theme just ships with a couple of things, because that’s what we’re building, which I think is super fun.
Yeah, awesome. Do you want you want to go ahead and share Brian or,
yeah, if you all don’t mind, this is just more a demonstration of this, just in, like, the real world, because I know that, you know, Justin, you shared your kind of interpretation of it. And I think we’re all going to have different interpretations and executions. And I think sometimes seeing this in action actually, like, oh, okay, you know, because we could talk about it, we could read articles that show you how to do it. But I think until you connect those dots and see this in the real world, that’s why I wanted to share. So I’m just gonna that’s cool. So this is my theme, and using, I’m leveraging the tailwind color system inside of my theme. And so there’s 22 different variations, each one like that mirror up with the tailwind color. So I kind of am working within colors and shades, but in terms of the patterns themselves. So this sort of section is all wrapped in one group, and that group, as I click over here, has the base style. You can see it’s just basically the black on white. Now I have let me just do this really quick, but you can see, inside of every single variation. There’s there’s white, black, and then sort of three different shades of purple, and then what’s called a neutral. And so there’s corresponding, as Nick mentioned, I’ve created four different styles, one called base, which is what we see. And if you click contrast, then it just automatically knows how to change everything. And I’m using a lot of current color here. And then if you click on primary, then it becomes purple, and then neutral, and so on. Now to go a little more further, using kind of the button aspect of this, this is kind of similar where, if you click that, then the text changes to whites. But then you go here you can’t leave the button purple. So in this one, I change it to white, so you can start to see, hey, this is, you know, and then neutral is just like the lighter gray, so it’s very much like basin. So all my JSON files are very, very basic. Let me just, I’ll do this just for the sake of demons or not demonstrating, but, so I’ll drop this link after I’m done here. I don’t want to take up too much time, but this is basically the four different JSON files that are inside of powder. This is this has not shipped yet, so I’m waiting on 6.6 but the slugs are named 1234, so that the kind of aim towards a little bit of interoperability. But the UI part of it is for the user, right? Contrast, primary and neutral. So this is kind of just how I’ve chosen to at least explore it as it relates to the work that I’m doing.
Definitely, and I want to touch on it, because we talked about it a bit here as like naming. There is a ticket. There are two, as I mentioned earlier, there were two different like you seen in my demo. I had style one, style two, style three, and so I would not actually name those that way and like something that’s going to be in front of users. It would be something like what Brian has, base, contrast, primary, secondary, whatever your system is, but under the hood, the slug. So far, we’ve mostly agreed, I think, on like using section one, section two, section three. That way the this user can use, say, 2025 and then switch to your theme in those no matter what the title is, the slug is the same. And you know, they’ll be able to switch themes. Maybe we’ll straighten up some of the issues from the past with slugs and going forward, at least with, you know, these section of styles. But, yeah, don’t. Do not follow my example. Style one, style two, style three. I think that’s a horrible way to name things. That’s just for example. All right, anyone, like any issues folks running into so far, I have some I can share, but I want to hear from everyone else. Aaron,
this wasn’t so much an issue, but more perhaps a way of thinking. When you approach crafting your CSS, you’re not going to throw the kitchen sink When using the WYSIWYG (What You See Is What You Get) editor in WordPress, you can expand the capabilities to allow more options. This expanded area is called the "Kitchen Sink." at a single class or start nesting it deeply and then try and reuse that over and over, or nesting those classes within other classes, because you get conflicts naturally. These variations and section styles are just a set of CSS classes and styles. So the same things you would try to avoid when handcrafting CSS, avoid those same pitfalls when you’re thinking about these and when you’re crafting these section styles, if you think of them from the perspective as that they can be nested within each other or themself, then that’ll start to jog or see the thoughts about what styles might conflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. and which ones you do need to consider, like links and buttons were mentioned before headings as well as another good example. So I just wanted to throw that out there, because I think that was sort of when I was crafting all of these test cases while implementing it that really helped, sort of just get things happening faster, and it became a lot smoother after that. So
I definitely agree keep those things in mind as you’re building them. Uh, Nick, yeah, I just had
this is kind of an open question. So because section styles are kind of a unique case of just block style variations, because they show up in the same UI, we run into the long standing issue of not being able to combine block style variations because they’re just CSS classes, right? And so I think that it poses an interesting situation where, if you are a theme developer, and you’ve already created style block, style variations for blocks, let’s say a group block. I think Brian, you had one that was shadow or something, and it adds, like, a unique style variation to the group block, and then you start implementing section styles, you start to get section styles feel like a very different thing than block style variations, even though they are kind of the same thing. So, and again, this is just something to I’ve had to think about, how do we handle that? You know, in future, WordPress releases an answer for it, but it is something that is interesting to think about. On that note. Real quick, I can jump in and I my daily pitch to get group blocks to support shadows. The only reason why I have that as a block style, so you have it as a block style, which means in the CSS, there’s a is style, dash, Shadow, or whatever the class is. Now, when it becomes an option, and I’ve already done this as well, when it becomes an actual option, when a block supports that, in other words, when group supports shadow, I will pull the UI part of that so users no longer. Get confused. I really don’t want to have like, a mixture of like, some like styles that do this one thing and then, like my four other ones. I really want to just protect that space just for those four, at least with the group block, and so I can pull that but if you leave the CSS class anybody who’s used it to date, and you could still actually use that class as well through, you know, additional CSS. So my hope is to, like, remove things, but also leave support for them, so anybody using them already to date, don’t all of a sudden, like, have that style gone and so. But I think these conversations where we talk about these things, and we do things like get on calls and pitch for group block shadows and have a bunch of people shake their heads and say, Yes, we should do that. Like, is helpful, because then those who are making those decisions or contributing that code realize that it’s an important thing for us to to ship so that we can, as users and distributors of, you know, products that are built on WordPress can get excited about and then make it a better user experience. So I like these calls, and I just Just one quick thing there. I just think that, like, yeah, we removed the shadow because you it will be in core eventually. But like, if you have, like, a really complicated block style that does stuff that theme dot JSON or JSON files just don’t support, like, you need custom CSS. You have a custom style, but you want to use that in conjunction with style variation. Block, style block, sorry, Section styles, you really can’t. And I think that there’s a good reason why you can’t, but I don’t know it, just it makes it the, at least the UI portion of it feel strange to me. So just something to think about in future iterations.
Yeah, I think to building, I mean, basically what Nick was saying, just said a little bit differently, is that we don’t have a way to create custom utility classes. We have, I mean, lot style variations I don’t really consider as like these smaller utility things that you can mix and match. We do have some utility things like, you know, custom, you know, font presets, spacing presets and so on. But we can’t add custom things, like, before shadow is there that we could not say. We could do something like Brian has done, like, you know, is style shadow, but we had to use the block style variation system to do that. I don’t think that’s to me that’s not always been the best use case, because there’s little one off things. You always end up wanting to mix them with other little one off things. And whereas I see like block style variations is more like you’re styling an entire component, um, instead of like a simple utility. So there’s like, two different use cases that people have used the things for, and they kind of compete. They don’t go well together, um, so, yeah, I’ve been anti like mixing, being able to choose multiple block style, block styles at once, just because it’s it’s going to able to break other use case, it would break some use cases, and it’d be great for for some so we were just kind of missing some system in court there. I feel like I don’t know what that might look like, concerns of UI and so on, but we do need, maybe we need, a new ticket that explores that. All right. Come on, folks of who tested any other things you’ve run into, tips, tricks or issues. All right, I can go back and share like something I think I touched on what Aaron was sharing.
I would want to ask Jessica, you have done a lot of explorations of the section styles and and you also are one of them. You have all your questions in the outreach channel. Did you get all your questions answered there? Or, because that’s very helpful to kind of put them asynchronous in the outreach channel. But I just want to make sure now that we have all the theme developers here. Did you get your questions answered satisfactorily?
Oh, what’s the point that? So yes, I get, got them answered, but like to the point of where I have to make a decision for the product, which is not to include them in a next update, and instead wait, because it will, it would be a bit troublesome for the backwards compatibility. So. So internally, we decided not to really push this forward yet, so probably maybe for in like half a year, or maybe a year, that would make sense. It’s but it has more to do with like this, bumping up the minimum requirement to 6.6 so you cannot ship any more updates to to your customers that are not, not specifically just for the 6.6 updates. So yeah, so that’s where I also like cut off the testing at this point, because, mean, there’s no much, not a good use case right now for an existing product with a user base pushing this forward at the spot.
And the reason is because all the section signs on a theme version, a theme JSON version three, that only comes with WordPress 6.6 and lower versions WordPress 6.5 and so on. They are not having those theme versions three in there, so you can’t use those things. Yeah,
can I just clarify something there? So the section styles themselves, the extensions of block style variations don’t rely on the version three of the theme, dot JSON schema, you can still use them without that. So effectively, you should be able to use the section styles with Gutenberg or 6.6 so will Gutenberg supports two prior versions of WordPress, so that should sort of be the minimum requirement that you’d need to leverage this feature.
Yeah, but then, in IDEA world, you wouldn’t need a Gutenberg plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party at that point, and you cannot force your customers to update to 6.6 ideally they should, but there are lots of use cases where it’s not possible or not wanted for whatever reason, and that’s where we are kind of stuck in, because if you put the theme to require 6.6 as minimum, it’s like you cannot ship any further updates. That’s the major problem at this point. Yep,
I’m reading. Brian cords has a question, and I’m not entirely sure. I’m trying to make sure I understand this. Is there support to add a block style JSON file that would define the styles for default variation of a block. The idea being, I could skip the using theme JSON for individual block styles completely. I mean, you don’t have to have you use theme JSON for block styles. You can just register them via php. I don’t know if that answers like you can just register them and via PHP, and if you need to add custom CSS elsewhere, you can do that. I’m sure you I’m sure Brian already knows that. So I feel like I’m missing something in the question
real quick. And I think I’m getting the question, Brian, let me just drop this and see if this is what you’re talking about. So in the spirit of having sections that needed to be white inside, like on a pricing table that had a black background, I needed to be able to set something to white, which is effectively the default, right? I actually created a style called base that is basically the white background with the black text, so that I could use that inside of other places. Because if I didn’t, what would happen is it would just inherit the outer one and, like, it would just be like a transparent, like, like group, like, if you think of like a card inside of a pricing table. And so you need, I needed a way to set that white. So I created a style called base, which means, technically, I don’t need the styles that are inside of that to be in theme JSON, because there’s no i No need for that. I don’t That was the question that you were asking. At least, at least, that’s maybe how I interpreted it. But,
yeah, I can clarify the question too, if that’s helpful. Um, I think that’s a perfect example. The cover block is another example where the default of the cover block is a little opinionated. It comes with changing your text color or something like that. So it would be amazing if I could just make if I could just style my cover block, my button, my out these things as those, like kind of partial JSON files, and not even go into theme JSON, because theme JSON is so big and unwieldy. But now I have this nice folder where I can have little separate files for all of my default, you know, basically the default block style variation, like a button, is another example where it’s a little opinionated. It would be great to style that, but not have to do it in theme JSON. I could use it in these partials. So I know that’s a bit outside of the scope of, like, the concept of the block style variations, but I’m just wondering, can you. Override default styles, or set a variation to be default using just the folder structure, not registering it in PHP,
not a current Not at the moment, yeah,
this kind of gets back to like, the question of like, could you have a structure? Again, I think that people have examples of this, like coded examples of this, where you basically take the theme dot json file and you can, like, break the whole thing out so you can have individual files for all the different blocks and, you know, styles and settings or whatever. So basically you take your, like, destructuring theme dome JSON into separate files, and then there’s, like, a compiler that compiles it into a full theme dome JSON file. I’ve seen a few examples of that. I’m not, I don’t have the mount hand, but I do think that would be a really cool way, because I feel like, at least for me, when I was doing like, per block style sheets, back when we couldn’t do as much in thing. But Jason, it’s very handy because you have all your different blocks broken out. Like, from like, a developer perspective, it’s very nice to have everything broken out. You’re not dealing with one massive file. But file. So I don’t know that’d be cool to see in the future.
In the short term, you can filter the theme dot JSON data. And so effectively, we take those partial files and we copy it into the relevant sections of the overall theme dot JSON file. So by the time it gets to the style generation, there are no partials anymore. So you could do the same thing that we’re doing with the other partials, but instead of them being inserted under the variations key, you’re inserting it under the block type, and you’d go from there. So it wouldn’t take much to jump to that?
Would there be a potential? Because if you register a block style variation, there is an is default argument when you registered in PHP? Is there eventually an idea that there would be a parity between the two different methods before I, like, make some janky work around, like Nick’s describing, which we have actually done with the partials and stuff, and you kind of regret, you regret going too far from court with that stuff.
Honestly, this is the first that I’m considering that default variation or style. So I think what we need there is a GitHub issue. We can thrash it out, and we’ll all settle on the best path forward from there. So I can’t answer that one straight away, sorry. Okay,
I’m over here. Just wanting to play around with that idea now, yeah, just break everything down and to partial files and get rid of my 2500 or whatever line, theme, JSON, this at least 2000
All right, coming up, we have five more minutes. So I think we have one last question that we could answer collectively, if anybody wants to raise their hands and we’ll have a comment
about things I
I’ll reflect a little bit on the lengthy theme, Jason. It’s a slight kind of side quest, but one of the things I’ve noticed is each release my theme, Jason is getting shorter, and I love that, because we’re getting more things, either in the UI or we’re getting more things that I don’t have to do lengthy custom things in the theme Jason. So I guess my point here is, if you find yourself creating giant theme Jason’s and maybe think about how the features that you’re using in there could be more compact, or could be a function or something like that. That’s one thing that I’m reflecting about on, like, how much customer stuff Am I putting in there? How could it be made into issues? So I think there’s also something in there of, like, what are we putting in there? But I personally try and not use CSS. I try and only put it in there, which is a whole me problem, I guess so much. Just
a reflection on that. I
guess I have a quick question for Aaron, since you’re here. So what is next? Is there anything on the roadmap for that you can speak to for 6.7 with regards to Section styles and kind of the this area of work.
Um, I probably can’t make specific promises on what will be in 6.7 but I can certainly speak to what the next steps are. So at the moment, in global styles, you’ll see in the UI, you’re only able to configure the variations top level style. So what’s applied to the block that you’ve assigned the section style, block style variation to? We need to find a way to allow configuration of those inner elements and those inner blocks. And it sort of is a nod to the no code. Editing of or creation of themes, or just provides quicker, easier ways to make those tweaks. So the catch there is, we could continue this drill down paradigm that we’ve got in that global styles, but once you start going to block types, to variations, to inner blocks or elements, and it keeps going down further and further. Now you get lost and you don’t know where you are, so we’ve got to solve that UX issue before we can go too far. There other things that were going to be explored were the composability of these section styles. So it’s already come up in this discussion whether we can mix and match, but obviously there’s a big can of worms there, like the order that you would apply these variations would completely change the results if there were overlapping or conflicting styles. So how do you flag that, avoid that, manage that? So there’s a lot to come out of that. So I think the first step is sort of consolidation of what we’ve got learn the lessons from 6.6 and that might inform the highest impact areas that we can enhance. But I would like to see some of those gaps closed in the UI, at least, so that you can get the job done there and we can improve it and move forward from there. I know there were some enhancements that were shelved during the process of getting to the point we’re at now. For the UI, whether we parse out color only variations and move those into the Color panel and typography only section, Styles would be moved under the typography panel, those sorts of things, and we can then provide different previews or cards that might reflect that better. So you’ll know the styles cards in the site editor that have sort of the color palette to it, or the typography these sorts of things. So we might be able to leverage those UI elements to just provide better visual cues as to what you’re actually looking at. So to your point earlier about randomly clicking and trying and that pick your own adventure, I think was the term you used. So to sort of avoid a little bit of that you can see a number of cards or pills on the UI, and you know that you’re looking for the blue one and it looks blue, or you’re looking for a serif font, well it’s reflected. So I think those sorts of improvements would really make a big difference. But there’s always more power, more flexibility that we can add, refine it. Yes, and then there’s a proposal about updating how we handle the global styles post type, and that unlocks a whole new world of possibilities there too. So with so much possibility, it’s a little hard to say what to watch out for next, because there’s a lot that could happen so exciting times there for sure.
Yeah, bigger. Thank you trying to tell with and you’re on mute. I’m
on mute. Yeah. Thank you so much, but you could go and close out the session as well. I just wanted to say thank you so much for being here and contributing to it, and it was a great discussion. And, yeah, what is the next thing that you want to discuss on a hallway hangout? Yeah, some people say, Okay, this is a good thing to do. So what would be your next topic? That’s all my question. You don’t have to answer. Now think about it, and we’ll talk about it in the outreach channel on the Ripper slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Well, thanks everyone, and thank also Brian Gardner for sharing his Justin. Aaron Nick and everybody else Carolina. Have a wonderful evening, afternoon, morning and good night, Aaron, you’ll see you later. Bye, bye, bye.
Transcribed by https://otter.ai
