 Awesome. Hello everyone again. Thank you for joining us for this excellent session with Michelle Schulp on the future of themes designing for the block editor and beyond. Michelle, whenever you're ready please take it away. Sure sounds good. Well, hi everyone thanks for spending whatever part of the day this is for you with me for an hour or so I hope to be able to talk about a lot of stuff. You know, brief intro about me so I've been doing designing and building WordPress interfaces I think I first poked open WordPress a little bit in 2010 and now I am a theme developer so that's kind of fun. And I am here because I mean as a theme developer, I am really passionate about theme design, especially since that's my background that's what I went to school for. So I really want to talk to all of you about where theme design is at now I know that there's been a lot of changes in the last few years and where that's kind of going and how design and development and all of this stuff like fits together. So I want to go forward with WordPress. But before I talk about the future themes. I want to do a quick trip into the past to review how we got here so we can more clearly see where we're going. For most of the history of WordPress themes were cohesive templates that were generally separate from the content. And that was the whole point right. Because if you put your content in the database that means that you could update it without editing code it was a lot better than static HTML. In these days basically we had our theme, which was in charge of the look and feel and structure. We had our content which was our words and also our images and media. And then we had plugins which would introduce functionality and this was kind of the, the paradigm of WordPress for a really long time. So during that time, a theme designer was basically the design dictator is what I want to say because theme designer was kind of in control a lot of things they could tell you how color typography spacing branding would be used they would be creating all of the layouts headers footers sidebars custom page templates page layouts, and they would be dictating exactly where content would be used within the layouts and which content needs to be where so theme designers had a lot of control in the early days of WordPress. But as you know time went on websites began to have to do more right like we started out with posts and pages, but then suddenly sites were becoming stores they were becoming sales funnels. They were becoming membership sites social networks event hubs learning centers communities. There's a lot of stuff going on and as a result. We really needed to be able to evolve as content changed. So we started seeing things like landing pages and other bespoke content needs kind of like micro sites within a site. We had more complex functionality needs like I really want to be able to display these specific posts or these specific products or these testimonials or these users. We had a lot of a lot of gap in between like what we wanted to do and how many options we had we didn't really have any options for creating these layouts without knowing code. And so that wound up with a lot of end user frustration because they can't make what they believe to be simple changes and they were kind of starting to feel like developers might be gatekeepers who are kind of preventing them from being able to do cool stuff. A lot of solutions were tried. As a result of all this stuff we're trying to find a way to manage these complex content and design needs. Now each solution had its strengths and weaknesses and people fell into specific camps of which thing they liked pretty strongly. But part of the problem here is that there were so many solutions that the WordPress content editing experience became divided, you know, you edit one WordPress site and it's kind of completely different from editing another WordPress site depending on which of these solutions they adopted. And there was no really unified WordPress experience anymore. So cloud based editing was introduced as a way to unify the editing experience for multiple use cases and provide a visual and procedural set of standards for all these different needs. They wanted to make the content editing experience also more closely resemble how the content was going to look because if you recall. When you're looking at maybe custom fields or maybe some of the more complicated page builders or a short code based solution. You're editing content in all these different places and it didn't really look anything like what the front end was going to look like until you like hit preview and looked at it right. So that's why the block editor was created. And the first phase of this was the introduction of this block editor which has been available in core for content editing for over four years. And it's not perfect and everybody has a lot of opinions about it one way or the other. It has undergone a lot of changes in that time to make it more stable, more usable and more intuitive. And I want to kind of talk about all the stuff that's happened here. I gave this talk at this last word camp us and I have updated it with some of the things that have happened since then. But a lot of things that happened basically since the last time that everybody had been together right so currently. Wordpress is in the middle of what they call phase two, which centers around the full site editing feature so phase one was introducing the block editor within the content and now we're in full site editing and editing content everywhere. There's been eight major releases since 2020 and three new themes have been created two of which are full site editing themes. Lots of different things have been introduced. So we have more core blocks including site level blocks which are blocks that help you build the site, not just the content. We have a whole lot of block styling options typography color spacing all sorts of stuff. The widget areas have been converted to blocks and also navigation has been converted to blocks as one of the major site level blocks. We also saw the introduction of block patterns which was the ability to be able to kind of create and serve predefined groups of existing blocks together in order to streamline building you know it's kind of a pain to have to build like a specific set of columns every single time so why not build a pattern and save it and let people use it. The query loop block was introduced which is extremely powerful because it enabled and users to create loops and display custom content. We've also introduced the block directory and the pattern directory so people can more easily find the block or pattern they're looking for. And we've also got block locking, which provides some more control for being able to choose what people can and can't edit. We also saw the introduction of the theme.json and this new kind of global style variable paradigm and I'm going to talk about the theme.json a lot. They, you know, full site editing obviously was introduced, which supports HTML templates a whole new way of building templates and WordPress. And in the most recent release, it even includes being able to support some full site editing within a classic themes you don't have to refactor your entire theme to start taking advantage of some of the templates. So if you want to learn more about where WordPress is headed. This is the link to that I do have a link also at the end of this presentation to all of the slides so you can reference any of the links or resources that I show you but this is if you want to know more about where WordPress is headed. So the question I kind of want to think about now is you know what is the purpose of a modern WordPress theme. For the average end user, modern themes are far from the mysterious black box that they used to be where you just input content and a beautiful custom layout comes out the other side. It's also far from the days where you needed to have a very detailed or over overbuilt page builder system, or a lot of custom plugins, just to create content layouts like columns or groups or landing pages. Nowadays with full site editing it's even possible for all the theme templates you provide to be overwritten with new ones being built directly within the editor without ever touching code. So in that case, what is the role of a theme designer, if themes can be just overwritten without code and and we're not really dictating exactly how the content is going to be what is what is the point of us I, I want to know that's what I do for a living. Well I propose that the new role of a theme designer is known as a creative curator. We still care very deeply about brand and aesthetics and communication, but our methods and our audience have changed. So our job as a creative curator is to provide a thorough set of thoroughly thoughtfully curated opinions patterns styles layouts and templates that function as suggestions for the end user to be able to build their content off of. We are providing the rules that govern all present and future styling and layout decisions within the theme. Global global styles, styling the core blocks, creating rules for how different elements within layouts interact with each other, and also kind of helping our end user build good pages that make sense and are on brand. We have the power to decide how to curate the content building experience to enable guided creativity, which means we're not just designing the experience for the website visitor we're designing the experience for the content creators as well. Some questions we might ask you know, do we need full site editing. Do we have to support everything that comes with WordPress do how much control do we want to give the, the content editor over changing the look and feel of the site. These are things we'll be thinking about. There we go. I know how to use PowerPoint. All right. So as creative curators, we can extend and enhance the block editing experience by providing additional styles patterns and controls for existing blocks. So we're thinking about things like, do we want to create any special pre built patterns or pre populated blocks, should these be available. Do you want to extend any of the core blocks with any custom styles, do we want to provide multiple sets of styles. Are we including any other custom styles that support specific third party plugins. So our job isn't really about creating a pixel perfect solution anymore, but we're really just creating a comprehensive design system where many future solutions can flourish. And the questions we're asking ourselves is, how will design decisions impact our current content, and how will our design decisions impact any future content. So a little bit about design systems. A design system is a collection of reusable components, guided by clear standards that can be assembled together to build any number of applications. And design systems are kind of a powerful tool that a lot of different small and large companies use to be able to say, no matter what it is that we're putting out there everything is going to be cohesive and everything is going to be on brand. One of my favorite methods for creating design systems as atomic design which was created by Brad Frost. And you can think of atomic design if you haven't heard of it by now is kind of like chemistry. We're going from the least complex to the most complex. We're going from the smallest to the largest, we're going from the most general to the most specific. I want you to know exactly what this means by now I've got a little animation here that kind of shows how it works. So there's an atom that a molecule, and then an organism, and then a template, and then a page I'll speak to each of these individually right but I'll show it again so very some simple elements they combine together, they make a bigger element, they make a big whole layout and then the layout gets populated with content. And that's not by talking about atoms now in chemistry atoms and the smallest building block you may have seen the periodic table of the elements. Well this is the periodic table of HTML elements because this is what we're talking about when we're talking about atoms we're talking about stuff, the smallest building blocks right so you're heading or your div or your input right, but also things like colors or typography or other utilities. So for example here, you know an image, a heading, a button, an input, a paragraph, a link. These are all examples of atoms now they don't really do very much right they're just kind of sitting there being what they are right. But just like in the real world when you put atoms together, you create molecules and that's again here you're combining HTML elements together in specific useful ways. So what are some examples, maybe an image with a caption, or a collection of links or a list or forms or breadcrumbs, a heading with a link on it, a paragraph with a heading these are getting a little more interesting we're still not quite able to do anything with them but we're starting to recognize that these are bits of content coming together. Next up we're getting into biology here because all of these molecules come together and they form organisms. And one thing that an organism can do is action right organisms can do something and that's what organisms let you do in a design system. So as we combine molecules together, we're going to start to recognize these as some of these block level elements right. So these are a little bit more complex and they're usually also like a contained unit of content so what's an example here. So it's a, a list of posts, or it's several like a gallery of images with captions or it's an entire form with a submit button. These are some really great examples of different kinds of organisms. There are also headers and footers are a great example of organisms you know this is an example of a header that has several different combinations of things each one is its own organism. So when you combine these block level elements together we're abandoning the the chemistry and biology metaphor these are templates. So when you put lots of block level elements together, they become layouts. And these are repeatable combinations of organisms you're hearing a lot about repetition about reuse about building up right. These are entire content stories. So, for example, you know you have a header page title paragraphs and a form with a sidebar with a bunch of posts in it and then a footer. Or you have a header and a hero image with a big like call to action text and then like a gallery of some posts and then a post list and then another sidebar with some other posts and a footer right. You can see that some of these elements are being reused in a couple of places the header and the footer are the same. The sidebar is the same but it's in different different spots, but these are different layouts. And then we have pages and pages we should know about this from classic wordpress right a page uses is a template that has specific content in it right. So you know you take your layout and you put real pictures in it and in real text and it becomes a page and multiple pages can use the same template right that's kind of the appeal of a content management system we don't have to build a custom page for every single page we can reuse templates, which we're using blocks which are then reusing you know all of our elements so how has the move towards block based content and full site editing made WordPress theme design more atomic that's what I want to talk about next. So before getting into the specific details about atomic design with WordPress I want to give a little bit of broader context about the structure of themes. I want to talk a little bit about the makeup of a traditional which might be known as a hybrid PHP theme versus a full site editing theme now they're starting to blur the lines a little bit as they're starting to introduce more full site editing features for classic themes but you know as a designer I want to kind of draw attention to the types of templates that you're going to see. So in a standard themes standard themes were built built off PHP so you had PHP templates that followed the template hierarchy. These could be all kind of the standard templates you could have custom post type block templates that was kind of newer. You can have template parts which are like parts that you can pull into your templates that are reusable. And then you are also able to use a theme.json in a standard or hybrid theme. And then in a full site editing theme so full site editing themes, you do have a couple of PHP files, you know for your functions but everything else are these like special HTML templates that are full of block markup. So your templates your template parts your patterns all of that stuff is all within HTML templates. You can also use PHP templates. I think I have an extra there we go that was just added within full site editing as well as you can start using full set editing templates within a classic theme PHP templates won't be editable in the full site editor but if you need to do some very custom kind of uploading and everything else can be full site editing that might be a good choice. But anyway I'm just kind of trying to make you aware of like these are the things that that exists these are the things that we're going to be talking about. And I'm mostly going to be talking about styling themes because that's a lot of the stuff that theme designers and developers have to think about. So I want to bring your attention to style dot CSS and editor style dot CSS. So both of them are required in order for the front end to match the editor style dot CSS is the one that's in queue for the end user it styles the website editor style that CSS is in queues in the editor and it styles the block editor. You can use these on that your own if you're not using theme dot JSON or you can use them to supplement theme dot JSON in places where it doesn't quite hit all the styles you need. And theme dot JSON. So this is a JSON file, and it generates styles and CSS variables for your site. So these styles and variables are loaded in both the front end and the editor without any extra effort from you. You can use this on its own or you can use it alongside your style dot CSS, and it is responsible for most of the styles in full site editing I say most, because not not quite every nuance is still able to be done within a JSON file but a lot of things are and I'll talk kind of about how I feel about that. And now I kind of want to talk about. All right, we've talked about atomic design we've talked about all these WordPress things how do we match one up to the other. So we have our options which I would call settings it's kind of like a pre Adam it's its own thing. So we have editor settings and block options. We have the components which are atoms are molecules and our organisms these are basically the, the blocks that you're going to see within the content or within the site editor. And then we have our templates which are page and post content and full site views, and then we actually have the pages where we're actually rendering this content out on the front end. You want to mention the examples I'm showing. They are a couple months old and they do have the Gutenberg plugin enabled so I'm not sure how they look in regards to like what WordPress core has, but I like to keep track of where things are going so on my personal development site I install the Gutenberg plugin just so that I know kind of what design decisions are being made and what's going to break and see what new features are coming out. Okay, so if there's any questions again feel free to put them in the chat I'm kind of talking a lot. It's okay if you just want to listen that's great but I'll be I'll try to answer anything as we go but I'm going to start going through this list of settings and I'm going to talk a little bit about what's involved in a theme. So first of all, with our settings, we have our settings that are in theme.json so this stuff kind of replaced a good deal of add theme support. So if you, if you used to like build like classic themes. This also determines which controls a user is going to have in the editor. And I kind of listed a whole bunch of the controls here so there's color controls like the color picker gradients etc. There's typography controls like font size font family etc. Border control size radius color spacing controls like margin padding and gap. So as a designer it's important to kind of consider which elements we want our content editor to customize, and how we want to control some of those things. So I provide an example here of what it looks like when everything's enabled or everything's set to true. And then when only a couple of things are set to true so you can see, this is the paragraph block it's the exact same block it's a core block, but here in my theme Jason I have changed what's available for my, my content editor to customize what's helping me being able to kind of curate what decisions I think they should be making. We also have block settings. And these are things we can do to kind of extend the user interface for existing blocks by creating additional styles or settings for the content editor. It reduces the need to have to build a new custom block all the time. And it will gracefully degrade to the original settings if the theme is changed right so you could create custom block styles and that's something that I'm showing in this example here I created a couple of custom styles. I did these in PHP but you can also do these in JavaScript in JavaScript you can also unregister existing block styles. These things are styled in your CSS, and you can also create other custom block controls that would be within JavaScript if you're if you're planning on writing JavaScript is a whole another conversation. So next we're going to get into the theme that Jason variables I see there's a question about multiple palettes I actually am going to talk about that a little bit later so I'll, I will come back to that question. And, alright, so I'm going to. And oh the question is atomic design being recommended and used by WordPress currently so atomic design I would say isn't a specific like framework of building anything it's more of like a framework for how to think about doing the design, you can kind of execute on it in any way that you want. I kind of just use it as a thinking framework right but what I'm doing when I'm building for WordPress as I'm kind of thinking about all of this stuff. Alright, so anyway, Adams are our most basic elements right you can't get simpler than Adams so what are these things, things like color typography layout and spacing are determined in your theme that Jason. They have. Okay, I have like a very tiny screen so I'm going to zoom this in so I can see it great. So, theme dot Jason generates CSS variables, which show up with this kind of layout so it's WP dash dash preset dash dash whatever category dash dash whatever slug. So for example, it could be WP preset color, color name. That's an example. Some of the ones that theme Jason supports by default are color like palettes gradients or duo tone typography like what are your font sizes what are your font families. Layout regular and wide size what are they, and then what are the units for your spacing these are some of the preset variables. And again if we've enabled these on in the previous settings that's what our content creator can use. We can also create kind of as many custom variables as we want so there's a specific set of preset variables. There's a really great list of all of that stuff at full site editing calm, but we can also create as many custom variables as we want and we could do none or we could create a bunch. I really like using the custom variables and theme that Jason for both full set editing and hybrid themes because you're basically creating a single source of truth for your values. And then you can reference them either other places in theme that Jason or another CSS file so you're kind of preventing duplicate work. So fonts can stay like as authentic to your your theme that Jason is possible. And as more and more of these things become supported as part of the defaults and we can move them out of our custom settings or we can just reference our custom settings and our default settings font sizing. I believe can be done in multiple units I think we can actually set units as like which units are going to be available as one of our settings. So there's several different units that could be available for almost anything. So in addition to generating these variables and don't worry I see there's a lot of other questions and I'm, I'll be able to like get to them as we get to that point in the theme so I'm not, I'm not ignoring you a promise. Okay, other things besides variables that theme.json creates is also it will generate CSS styles for specific blocks and blocks elements so that's under the styles section. Again this is a really brief overview of theme.json just to kind of show you what it looks like. I really don't expect you to be able to like write all of it as soon as you've watched this presentation but hopefully you'll be like oh I've seen that before and you'll be able to kind of look it up and find more information later. So, theme.json can generate CSS styles for specific blocks and block elements, these are styles not variables it actually creates styles that will show on the front end and the back end. And that is stuff like for your buttons for your captions for your headings for your links. So these aren't specific. These ones aren't specific blocks it you can also do styles for specific blocks which I will talk about a little bit later. So we've talked about atoms which again are your most basic HTML elements and your settings and your colors and your typography. Now we go up to molecules so molecules are putting atoms together to create more complex things. Some of these are also like the very simple blocks you'll actually see in the block editor. You'll see stuff like your quotes and your lists your buttons and forms embeds post elements like your author your meta your comment site navigation elements like logos taglines menus you're going to start to see some of these like simple blocks in the content editor and in full editing. And this, I would say is where we're starting to look at the theme that Jason block style so this is where we can actually write styles for the core headline block or the core paragraph block or, you know, any number of things and we can actually override our default styles with more specific styles like sure I want my h1 to look like this but you know if it's a core heading block I actually want it to look like this. And that's how the specificity works if you're familiar with CSS specificity. Then we get into organisms organisms are more complex blocks. These are blocks that are built out of many other blocks. And these are definitely things like the layout blocks which I would include groups columns and rows because you're putting lots of blocks together. You're putting mixed media blocks like the galleries or your cover image, or your media and text block widget blocks are usually complex blocks your query blocks certainly are complex blocks there's a lot of stuff going on in there, comment blocks are complex blocks. So these are you're taking all these other blocks putting them together and kind of this big meta block and that would be an organism. So the example of an organism is a template part, both full site editing and PHP have template parts in different ways. I kind of just showed an example of my code of footer template part from my PHP theme that I've built. The template parts are used if you want to kind of reuse the same thing over and over so that might be a header or a footer, or maybe it's your archive post content do your single post content or whatever reusable template parts. Full site editing also has template parts. And it has a whole section in the site editor this is the, the current interface for it. Gutenberg plugin now is actually playing with a little bit of a different interface for this layout which is really fun. The template parts are editable fully within the full site editor if you have a full site editing theme. I would also say that block patterns are an organism so block patterns are a commonly used group of core custom blocks that can be preconfigured and inserted all at once. You can use register block pattern in PHP, you can define them within JavaScript or if you have a full site. I don't know if that one's actually defined in JavaScript anyway, I know you can do it in PHP and in the full site editing theme, you can put them inside just a patterns folder and they'll show up. These things show up in the patterns tab when you're inserting a block, and you can tag them you can make them searchable you can put categories on them. But basically these are things that either you can provide as the theme developer, or you can find patterns in the pattern directory. There was a question up here about adding things to the theme like custom patterns. So my thought on patterns is I include my patterns in the theme if I'm only using core blocks in them. Oh, I just went one slide too far so I was kind of trying to think about that I am. I prefer to have plugins be adding new content and a pattern once it's put on the page. It's just made of blocks it doesn't go away. So it might not be available in the pattern searching thing anymore but it doesn't break anything on my page if I change themes. Now you might want to, you know, register them in a plugin because you want anyone in any theme to be able to use your pattern and that's totally fine too. But I think if a pattern is made up of core blocks that won't go away. It's fine to put them in the theme, but you could also put them in a plugin and I could see an argument for that as well. But I think, as with anything, if you are creating something where deactivating your theme or changing themes would break your content. You probably shouldn't put that thing in the theme you should put it in a plugin so I just wanted to address that thought that was in the chat reusable blocks are also an organism. I know that there's some confusion about reusable blocks versus, you know, template parts versus patterns versus all these things reusable blocks were kind of like an early stage thing that was put into the block editor, and it was basically a block that is saved as a custom post type, and everywhere you put that block, the content will be exactly the same so if you update the content in one place, it will update the content anywhere. I mean, it's different than a pattern because a pattern. Once you put it on the page it's own thing. It's a little bit different than a template part. I mean, it's, it is but it isn't. I think every usable blocks is something that actually really belongs within the content and a template part is something that kind of belongs outside the content maybe in the full site but it is a little confusing but just so you know that's that shows up also in your block inserter if you have any and these are some really creatively named reusable blocks that I made for this demo. And if I put it somewhere it's pretty good for like calls to action and stuff that need to be reused. All right, then we have templates and I know templates we're starting to get confusing because now we've, we've lost the metaphor. But templates should be something that we're very familiar with as WordPress people, because WordPress has been using templates since the beginning, and both full site editing and traditional themes follow the template hierarchy. There are in with PHP templates we also have post type block templates post type block templates are. You can use PHP to define what blocks show up on a post type when you open it for the first time so if you've if you've ever used something like the events calendar for example and you open up an event and and the and the block editors enabled for it. There's a bunch of blocks already on the page. That is predefined block templates they're kind of useful if you know that your event is always going to have to have you know a date and this and this instead of using custom fields, you put blocks on the page. You also have traditional theme templates you know page templates different PHP templates. The page templates can be used in full site editing theme by being added to the templates folder so again here's an example of PHP templates where they are what they are in a traditional theme. Then we have full site editing templates and full site editing templates, follow the same template hierarchy. So we have our core templates like single archive page and etc. So when you go to edit them you'll see that they also include just like a PHP template does the header and the footer and anything else that's on the page not just the content which is really cool. Because you can customize your header and footer on a, you know per template view if you want to if that's useful. There are certain post types that shouldn't have the same header as other things like creating a microsite within a site kind of neat. You can create any of these custom or you can assemble these out of full site editing template parts. So these are those templates that exist in the full site editor and there's also ways to add new templates it'll kind of detect all the different post types that you have registered and see if you want to create templates for those if there aren't any already. And question here. If you edit with the CMS after you create the full site editing templates it will add the code to your template to full site editing so now actually kind of fun. It doesn't do that your template code stays exactly the same and it basically creates. Oh gosh I don't actually know the how it works but it basically saves. In your in your data, a new version of the thing which means that you can always revert or erase your edited changes and it'll just go back to the one that's in the theme. The most important thing is it's not overwriting your theme. And if I had edited it in, you'd see a little blue dot here. Next to this icon, and it would indicate that I have. I have changed it I have changes that are not reflected in the theme itself and I'll have a little menu of like whether I should revert it or keep it. So that's kind of how that works. So then we have you know our pages, and these are you know when we're creating content in the block editor using blocks and patterns, and also all the different views rented within the site, you know using these full site editing templates and template parts so all sorts of different things pages aren't just pages anymore it's not just the content. It's also the entire page with the header and everything else. So thank you so yes it's a it saves them as a post type called WP template I I thought that that was a post type you know that would make sense I knew it was in the database somewhere thank you Sally that's very helpful. So your template parts and your templates are saved in the database as a custom post type, which is why you can edit them that's that's great. I promised I would talk a little bit about style variations and custom global styles. So I just kind of wanted to mention, you can provide multiple JSON files within a single theme. And if you save them in the styles folder. So to enable your content editor to switch between different theme styles within the dashboard and the 2023 theme did this. And so you can go kind of look at how that one is set up. I believe that for the other custom styles like your alternate styles you don't even have to define every single thing I think you just have to define the things that are different someone feel free to correct me if I'm wrong. For example, this, this is a really great option if you're doing commercial or variable themes right I wouldn't necessarily say that if you're building a bespoke theme for a client that they are going to want this. But really great if you're trying to sell a theme or you're trying to build a variable theme so this is what that looks like. This is in the site editor in the styles panel. This is a might be a slightly older version of what it looks like I have Gutenberg enabled so I can never tell again what's in core and what's not yet but here was an example of being able to pick a different style and it will like preview your site in that style. So that's how that works you put you put your alternate JSON files in your styles folder in a full set editing theme, and then they should be available. So I wanted to talk a little bit because I've talked about how great all of this is and I also know there's a ton of concerns and considerations that come with full set editing and thinking about how to design for full set editing and how to design for. You know, all these things that are kind of going to break maybe now the technology that's powering this isn't exactly bleeding edge technology I mean you know react and stuff has been around for a while. But this still is not the most widely adopted form of the word press interface right and a lot of it is still officially in beta or like not in beta but it's still kind of in beta right. So there's some stuff we have to be thinking about as we're designing for this. Many elements of the block editor and full set editing are still in flux. That's anywhere from like what the CSS class names are to or how core blocks are styled to different experimental API is that they're working on to you know how they're defining layout stuff. And I kind of just want to present a series of questions that don't really have answers yet, but I believe that theme authors are going to be thinking about them in the near future. How do we address breaking changes there's going to be breaking changes right so what are we what are we thinking about. We're thinking about how do we know when to use a new feature right when should we use it. How are we how are we going to keep an eye on updates and new best practices because it seems like it's changing really frequently like I had to update things just between word camp us and now because stuff changed. So we provide ongoing supporter updates if we choose to use these new features right we're taking on a lot more responsibility as theme designers choosing to adopt newer technology. Where and how should we be defining our styles I talked about several different things I talked about theme Jason I talked about style that CSS I talked about, you know different alternate styles like I talked about full set editing and how it works I talked about how do they work like, should we be using theme.json or style that CSS for any given style. What do we do about the core styles do we keep them do we D register them are we replacing them what are the, what are the consequences of that. How do we deal deal with all the different like issues of specificity with all these very opinionated styles that core and plugins and everything are introducing. I mean, these issues have been around for a little while but still stuff we have to think about. So question our themes supposed to be unique or standardized, right. If we're mixing content and design really closely what happens when the theme changes, right. How do we address incompatible style issues, and how do we address style compatibility with any third style third party blocks and plugins that we're adding to our theme right so how do we do that. So how long is the theme supposed to last right you know it was pretty clear in the past that like a theme was your design, and when you wanted a new design, you've got or you built a new or you had someone build a new theme. Are we going to be changing themes anymore, or are we just going to be changing options and layouts within the theme. Are we just going to, I don't know keep the theme but like load a new JSON file and blocks and patterns and just keep going is that how we're going to do it are we going to rebuild all our templates in the full set editor and never change our theme again, or are we going to get new themes, I don't know. And then like the big question you know how do we learn all of this new theme technology goodness. I mean, if you've been doing WordPress for a while and that was your primary way of doing development you know now suddenly we've got this like specialized template markup we have JSON, if you want to do any custom blocks you got to start working with react. And if you want to do any of that you're going to need some like compiling and build tools which if you haven't had any experience with that yet that's a whole nother thing to learn. Although some things like create block make it pretty easy if you have a little bit of familiarity with the terminal. It'll it took care of a lot of it I made my first block in the time since since word camp us I'm very excited about that. Also like because we're working now with a lot of compiled code, the code that kind of like ships to your site, you know you can't. You're reading it anymore, although you can go and get hub and read all the the source JavaScript if you want to and there's also like a script debug that you can use to be able to see the unminified versions of of scripts, but it's a little bit harder than it used to be we could just like open up the PHP file and like type some stuff in it and like see what happens right. But you know, Sally said in the chat like if you don't want stuff to change all the time tech is a terrible field to be in. That's very true, you know the only constant is change and and here we are. And it's really cool that we have resources like this where we're all getting together and trying to teach each other how this stuff works right I'm really happy about that. So the key takeaway here, themed about design might be evolving it might be changing from what it used to be, but it's still a crucial part of the WordPress ecosystem and so you know let's help people build creative content. I have a slide here again, this will be shared that has resources about design systems and also resources about the block editor special plug for full set editing calm I think that's my favorite resource right now. If you want to talk to me for any reason here's how you get in touch. I'm on Twitter. I'm pretty easy to find everywhere. And yeah that's that I'll leave this up in case people have anything. I'll see if there's any questions that I specifically missed or if anybody has any questions right now feel free to bring them up. Yeah I do think you did a great job of covering folks questions but yeah. Please share more if you wanted anything clarified folks. Sure. Oh I'll go back to Brandon said and I said I would answer this so this was the multiple palette thing right here. So this is where you can have multiple JSON files, and you put them in the styles folder, and then in your full site editing, like style selector that's where you can pick the different styles and the 2023 theme is doing this. So if you want to see how that works, and how they set it up you can just get the 2023 theme and take a look at that so that I know that one was specifically asked. I see the question was like having a single JSON file with multiple palettes for use. I haven't seen that yet that would be really fun though wouldn't it. I think it's probably just like, maybe you can do some stuff with kind of like man see there's so much I wish we could do like I want to be able to like set specific. Yeah, set specific colors or set specific headings or set specific things on like a per post type basis or a per block basis in more of a way than we can but I feel like that's the kind of stuff that's going to be coming in the future. I mean, other stuff that I wish we could have is better responsive controls I know a lot of people are asking for that. I'm doing a lot of that inside my CSS right now just kind of like overriding the opinions that the site comes with but I will be really excited if we have more responsive controls in the future. I know I know a lot of people are asking for it so I can't imagine it will be too long until it shows up. Especially with, I think the navigation block is like one of the ones that people are really into and also one that I saw was like we have a mobile a tablet and a desktop preview, but we don't have any way of customizing what happens in those things so fun to see it maybe the next time I give this talk that'll exist who knows. Anything else. This is the part that's always awkward when I'm alone in my office. I think questions are pretty mean dying down a bit. But y'all, thank you so so much for coming out and showing your support for Michelle and this amazing topic I loved all of the engagement. Maybe we can get you back again in the future, Michelle looks like we, we want to keep talking about this involvement of design principles and themes within WordPress. You killed it. You killed it. We'll be sharing the recording. And yes, we will be sharing the recording will be sharing a link to the slides for everyone to reference late.