 So please give it up for the end of the day. All right. Thank you. So I know it's the last talk of the day, but are you all ready for about three hours of CSS? Yes. OK. All right. No, seriously, I have way too many slides. I'm sorry. But I couldn't resist putting a lot of links to resources or talks I saw recently to just throw them all in the slides. So if anybody is interested, they'll probably be online somewhere after this talk, and you can go through them manually and try all the other stuff out. So yeah, learn CSS deeply. I thought it was kind of appropriate since a couple of years. I think it's the first talk with this title, if not, I'm sorry. About me, I'm Vera. I work quite a while with WordPress now, I think since 15 years or something, tinkered with HTML the first time in late 90s. So I know the font tag, flash, and I've used a lot of importance in my life. But why talk about CSS? Why now? Why have a talk at a WordCamp about CSS? Well, these are really exciting times. CSS is evolving at light speed really, really rapidly, and we kind of need it to. But also sometimes CSS feels a little bit like an afterthought. I don't know why, because when I check just any regular website and I turn off JavaScript, and then I turn off CSS, and then I really don't get it. It's kind of a huge big thing, like everything I put it in the content, like how we consume the web, kind of important, not really an afterthought. Another example, just another Dutch website, I thought the name was quite appropriate. Just a beautiful designed website, no JavaScript, no CSS. But why talk about CSS now at a WordCamp? Like in the past year, past years maybe, sometimes it felt like there wasn't that much love for CSS in maybe all the Gutenberg discussions or like full site editing. It's really kind of important. You see it everywhere. It's embedded everywhere. But how are we supposed to handle it? What are the new best practices? It was kind of a limbo because I was working, trying to find my way with how can I cope, how can I deal with the editor. I'm really kind of a big fan, because I really think components-based editor for the open web is like a huge big deal, and we kind of need it. But then you see like, okay, I made my first team. I used block editor for it. Everything is like really native HTML, sorry, native WordPress as intended. Then the HTML output is changing. Kind of a problem, kind of things broke because, yeah, I use Google block to align some stuff in it. I use Flexbox. But when they add an inner container, it breaks. Actually, we really needed that inner container, but it wasn't in there in the first time around. So there were already a lot of websites going live with other, with changing HTML. Yet again, two years later, I guess, cover block totally refactored. Might, you might have encountered some issues with it. But then some more, changing classes. Why would you change class names? I mean, changing from the top one, WP block buttons. I thought it was something I could count on. Is content justification center? Yeah, sounds reasonable to me to use it and to keep using it. And then suddenly, I'm a bit lost. I forgot it was it 5.8 or 5.9. In the core release, they just disappeared and they went to something like Givrish because the block editor was outputting all the CSS dynamically. It's like really cool thing to do. But then again, I wrote some custom CSS on top of it because I thought I could count on this content justification center and really a lot of other classes, they just disappeared. So okay, the WP block buttons, it stayed, but all the modification classes, they were gone. I wasn't the only one having that struggle. You saw things like this on GitHub. Is it really a constant fight? Backwards compatibility was such a big promise in WordPress. It's really one of the main reasons I stuck with WordPress for such a long time. And now I get it if you're in such, yeah, it's changing heavily. I get it and we need it to change maybe, but if I can't count on the backwards compatibility then maybe I have a bit of a problem. Can I still create with WordPress whatever I want to create just like I used to do? And then I encountered like this one, I think here February and I was like, oh my God, now I'm lost. If you have quotes like in general, it should be up to Gutenberg to add all the CSS for these things, we aim to absorb all the CSS via Team JSON. I'm like, maybe, maybe it's possible, but I don't really see it. I'm used to having a lot more fun with CSS and like nitty gritty and stuff. Can we really put it all into a JSON file and then not have all the WordPress websites just look alike? Okay, I have to admit a little disclaimer. There was a lot of rumble in the jungle the past year, especially with the 5.8, 5.9 stuff, but like Mark Root-Wiley, he wrote a blog post, called out for, okay, we need a standardized system, we need an API we can count on, not like classes we weren't intended to count on, we need a team contract, how can we build upon it? What can we trust? What might change in the near future? So a lot of people are talking about it. I was like, okay, this is curious. It's going, I'm only a small web developer, I'm having a hard time keeping really track with all of this. It's so much discussion, so many GitHub tickets, so much things changing. It's getting to be, it's going to be quite some interesting times and I really love this discussion is going on. Maybe we need all the attention we can get. Another disclaimer was like, maybe if we're in such, in the midst of a transition, this big, maybe it's kind of normal that sometimes we feel lost because we're still all looking for the new best practices. We haven't settled on them yet. We're still in the midst of the discussion maybe. So I was like, okay, I'm with all those questions, a bit of frustrations, I see some hope. I know a lot of things are evolving in CSS, things we really can use within a block editor and full site editing. So what do we do to handle this? You just go to a camp. WordPress Camp Europe was along the way, we bought the tickets. Nope, a friend of mine decided to get married and I really managed, we couldn't resist. So no WordPress Camp Europe. Instead, the day we found out we couldn't go to WordPress Camp Europe, we bought the tickets for CSS days. It's quite expensive conference and I wanted to go to it for four years, but it always clashed with WordPress Camp Europe. So the weekend after we went to CSS days, two days only about CSS. And I was so invigorated when we came back. I saw all the, by the way, they have YouTube playlists. So all the talks are just on YouTube, go and watch them, take some popcorn, set yourself a weekend aside. Go ahead. When we came home, I saw the cover speakers was prolonged and I was like, okay, we need some CSS at the WordPress Camp. So we're going to talk CSS. These are really fascinating times and I really think we can use all the CSS love and attention we need, we can get. Okay, so now I need to drink some water. And I haven't put the glass away. No, seriously. I really need to drink some. So this was kind of intro runs. Things are really evolving and really evolving rapidly. As I see it, but it's only a personal viewpoint. The depth of Internet Explorer 11 has something to do with it. Just, I mean, maybe a lot of you have already ditched Internet support for Internet Explorer 11 like years ago. I couldn't because some of my clients are like one, two years ago, they had still like 10% of their users coming from Internet Explorer 11. So the block editor in WordPress core couldn't dump Internet Explorer either. Last year in May, finally the official blog post, WordPress is going to drop support. Officially in June, only June this year, Internet Explorer is proclaimed officially dead. So we now can use and can trust on things to work with Flexbox, with Grid. CSS, firewalls, custom properties, Steam, JSON relies on it. So before WordPress decided to drop Internet Explorer 11, there was no possibility to use Steam, JSON, with cross browser compatibility. Sorry. Okay, Minimax and especially the clamp function, aspect ratio, object fit, scroll snap phone. You see, if you can see all Internet Explorer having the red box, not supported, or an orange box on the can I use data. If you see now at MDNs, if you look up a feature and you see the browser compatibility chart, there's no more red Internet Explorer level. We can just go full throttle ahead. And then on top of it, like I think it was 2020, MDN did a big browser developer research. They asked like, okay, what are really the pain points for you to do your job? As a result of the study, so they decided to work together. Browsers, browser vendors working together to get cross browser compatibility as high as possible for some focus key points. Since then, position sticky aspect ratio, you can really use it, you can trust on it. Before there was like, okay, one browser supports sticky, in this way, the other browser supports sticky. In another way, in 2022, like this year, we have the interop projects. Even browser vendors, again, working together on a couple of focus areas, quite a lot of focus areas. And they try to get all the test results for each focus area to 100% by the end of the year. If they succeed, this means that by the end of the year, we can quite trustworthy use things like cascade layers, containment, sub grid, things that will all be quite some fun if you see it in context of full site editing and the block editor, things we might need to go the one step further. If you want to know more about all the focus areas they're working on now and what the status is, check out the slides of Brahmas. He gave a talk at Frontiers last week in Utrecht. He was trying to list all of them and show some funky stuff. He also did a talk about the new cascade layer at CSS days, so check that one out as well. But also, so things Internet Explorer did, things really happening in CSS like usable stuff, browser compatible new features coming up quite soon are ready for use and in WordPress, WordPress is evolving rapidly as well. So team JSON and global sales, like global sales, you can set a lot of choices like your font size and stuff through the admin if you're using a full site editing theme. But team JSON, you can all see them or write them out as settings and you can also use a theme JSON in your classic PHP theme if you like, as long as you use a block editor of course because otherwise it's no use. The team JSON, if you work with that, you can already deploy it right now in any theme. You can set the default custom properties, you need, you can add all your own properties you like to use in your own extra CSS source for your theme. And as a really handy tool, you also control the editor UI via team JSON. Sorry, Karolina Neymar, she has a really good course on full site editing. Just go and check out her lessons if you really wanna know all of it and have some good examples. So I'm trying, let me check right now. I'm going fast enough, good. Any questions so far? Time for another drink then. So I wanted to list out some more practical examples like things we're already using right now within a block editor, things you might be using in the near future or on your next projects. I'll start off with a little bit more explanation about team JSON. Who has used team JSON before or has played with it? Just to have an idea. Okay, I have to admit for me it's a kind of new thing. Just started playing around with it, but it's really quite enthusiastic. I mean, I feel like it's really, really promising. It's much more than I had anticipated before. It's quite handy to work with as well. And I'm using it now in combination with my extra CSS sauce on top of it. And it works really well in combination because of the extended use of the custom properties. Like the CSS variables, I'll come back to them a little bit later, but you can just pass along all the values you want and need from the CSS that WordPress will spit out. Through the settings of the... WordPress will pass the team JSON and will output all the properties as CSS. But you can also reuse all the custom properties you defined here in your own custom theme. Because beforehand, yeah, when I first started a new project, I always started with defining all your settings before custom properties, maybe with sauce variables. Now just custom properties in the root. Now that's just gone in my own team, in my own CSS because it's already there in the team JSON. So it's just another JSON file. It sits in the root of your team and it shows all properties and settings. And you can go nesting, you can define all the settings needed for your editor. So like add team support color pallets, you don't need it anymore in your PHP, you just define your color pallets in the team JSON and the CSS is okay. And also the UI of the editor will be using it. So all the team supports are replaced now with the team JSON, maybe not all, I'm not sure, but a lot of them for sure. So, okay, well outputs, okay, both in FSE and non-FSE teams, I think it's really kind of important because I was always thinking it's only useful within the real full-site editing teams until someone pointed out for no, okay, you can use it in PHP teams as well or more classic teams. And it's only then I started to look into it because I was not, because having had the issues with a broken HTML before I was kind of not really enthusiastic to dive right into full-site editing on production sites right now. This is a nice crossover. Sorry. So if you want to, yeah, I have no example of whole team JSON because it's kind of getting big. I think in the past slide at the links, you have the way team of which table, if I'm correct. If you download that team and check out the team JSON over there, it's quite compact, it's very readable, and then you can start playing out with it. So if it's the first test with team JSON, don't begin with a really huge one, just check out with the other full-site editing sites, but maybe use one like way or the other team of which table. So like here, these are all the settings for the colors. You can say, okay, custom color picker? Nope, I don't want it. They can't use it in the editor. You won't see the color picker. You can choose background color, text color. That's okay for me. Default pallets are the standard colors Gutenberg has. Nope, I don't want them. I don't want no gradients, no due tones, nothing of that sort. I will just have my own color pallets and I start defining my colors. Like the same as you did in the team support, PHP, you have a slug, you have a color code, and you have the name you see in the editor. The UI in the editor is just this. You can see whatever they can do, but they can't set gradients, they can't set their own color-picked colors. If you allow all the color form, you just set everything to true and they have all the nitty-gritty combined with your color pallet, of course, with your own pallet added up. So really control the UI through the team JSON because you could do it before, but with JavaScript filters and stuff, if I'm correct. Now it's just one place to control a lot of things. All the colors, you get all CSS variables. CSS variables because some properties is the same thing. It's just a variable declared in the root or in the body of your CSS file, like really on quite a very high level. Then you can just use and reuse these properties, these variables somewhere else in your CSS. You can even overwrite them because it's just, they follow the cascade as well, like a lot of other things. Because of the team JSON, you also get the WP blocks styles generating all the needed color styles for your primary, your secondary color and there are you already using the custom properties set in the body tag before. But you can also use those properties yourself in your own code. Mark, why are you using the important one, of course? Yeah. Okay. That was one thing. Because with the important tag, you can slash everything in the head. I really, really don't like the important tag and there were a lot of GitHub discussions about important. How do you call it then? If you add important to the CSS? No, it should not be used. Quite correct. Then this one, I maybe get it because if a user defines this color in the editor, whatever CSS you wrote, maybe you have to give them that color. But you get into trouble if you want to have a hover effect on a button and it has a secondary color with an important tag and you want to change the color on the hover you can't you have to use important tool. The better method is to extend your class like. Yeah. A dip point, something like that, or body. Yeah. Then you start the specificity worse. Because you can take an element, an element, the order of your CSS. Ordering is better than this. Everything is better than using important, I guess. So important is like smashing each other on the head. Now, I'm more important, you're more important. No, I'm more, more important. I mean, it's endless. Especially if you want to have maybe some fine CSS transitions on hovers or maybe changing SVGs embedded in your block buttons or whatever. This is really a pain in the ass. So it is what Gutenberg prints out right now. I don't think it's fun, but there were more importance that are already gone. So this is kind of the thing, I mean, what we're working it right now. Okay. Here is a link to the rich table theme. Also Carolina's course for every information, and especially the docs for the team JSON thing, then you can see in the docs whatever settings you can define. It's a user allowed to add custom padding for a block, for example. You can set it through team JSON. You can set it per block, you can set it on a general level. Some things I feel are still in the works, it's transitioning, but then the promise is really good. But to check out whatever things you can define using the team JSON, you get a long way actually customizing your editor experience. So the custom properties I added to can I use right on top for the next slides. It's a use extensively in team JSON, as we saw. You can add your own custom properties to team JSON too and they will be outputted as well. You can reuse the core and custom properties in any extra CSS you need. Like for example, I wanted to have setting, I wanted to have some sizes for my gaps. Like to control the spacing throughout my theme, the default block spacings uses get out of the box. So I defined some gaps and they will be outputted like dash-gap-tiny and I can use them wherever I want. I can also for the typography, I wanted to add some line-hate settings as well, and I get them as well in the base of my CSS to be used wherever I need them in a later point on my team. You can also reuse them or play along. I mean WordPress does something like every important text has primary color, color dash, preset color primary. I thought it was sometimes if you want to play with hovers and you don't want all clients, I mean are you able to set hover color right now on button blocks? I don't think so. So maybe you, what? Okay, but then you're not in core yet, but this isn't good work? Yes. All right, cool. Because setting hover colors on links, on buttons, it's also really serious stuff. So for now, I was like, okay, WordPress also always have the different color variables, but actually I want to do something with the current color of that button, and I want to swap it to background or whatever. So I just declare my own custom properties on the level of has primary color, my current color becomes the WordPress custom property, and in my hover CSS I can just use, okay, so the text color becomes the background color, and I also with an important, of course I am white for the text color, okay, accessibility wise we come back to it later, I am more important because I have to get over the text color set in Gutenberg. But whatever, you can play along with it, you can inherit, you can also calculate with custom properties, you can use a calc function with it. I needed like this tiny little thingy, a designer provided on a preview block, okay, nice it's an SVG with two circles in them, both have a different color, I use like SVG definition list sprites in my code, but then it has to have a hover animation, so they have to change color. I always use current color as a fill color in my SVG codes, but then now I have two colors, and I only in CSS I can only use one current color, but it's the one SVG, I just say, okay, the one circle has a fill with this CSS property, as the custom property, the other one has another one, and in my CSS I just set them like, okay, normally these variables have the value of the color primary and color secondary, if the preview block is in a hover state, okay, the values of my custom properties, they change and I get the animation, which only one SVG in one thing, okay. Clamp, as we saw with that I11, we can all use clamp, we can use it for fluid typography, also for fluid grits in the future, fluid gaps, whatever you want, clamp takes, you have three values, so you have the minimum size, you have the maximum size, and in the middle you're trying to get a viewport with related size, the browser will try to clamp onto between those minimum and maximum values, so this is just one set of CSS, I don't use any media queries to change the font size, I just use a clamp in my font size definition, you don't have to calculate it yourself, like the mid thingy, it's no fun, but you have tools online to help you out with it. In Team Jason you can just write it out, okay, you can discuss when do we still need a fallback for really cross browser stuff, or is it okay to just use it this way, but this will work. In your Team Jason, I have defined my font sizes using the clamp, in my editor I just gets the names of my font sizes, I get everything printed out in my CSS, and it just works without having to change anything for all of different levels, I mean this one is coming soon, sorry, switching to color contrast, I can set the hovers on the button, okay, if I change the background color to the current color, or the regular text color, but how do I know I still have enough contrast for my text, if I put my text white, because maybe they had chosen a yellow text color on whatever a black background, my code from before, it won't be very readable if I have the yellow background with the white text on the button link. But maybe in the future, wouldn't it be nice if you can do just something like this? Then maybe the hover thingy is a bit of soft, or maybe in the future they can choose their own hover colors, but then we might be using something like this as a default, as a fallback. If it's already in Team Jason, I suppose you can always write this one, color contrast in Team Jason as well, because as I understood in your Team Jason, you can use any valid CSS you like, you can just drop it in there as a value. So you can't use it right now, not yet, but it wasn't interrupts 22, so officially normally, we might be able to use it by the end of the year or the beginning of next year. So we have the background color, I'm using the current color, my former text color for it, and as the new text color, I want something that, okay, this is my background color, and I have a list of other colors like white, black, maybe the primary color, and I want one, okay, browser, go and choose me, a text color that has a highest contrast ratio to this background color. Okay, fixed one line, and it will cater most of the things, it might be a good default, and then if you like to fine-tune some more, you're always able to. Color mix might be a fun thing to use, also coming soon-ish. Maybe have some color palettes with all hues in it, might be nice. You can also use, so you ask the browsers in a color space to mix two colors and you can also set a percentage of how much of one color a browser should use for the end results. It's quite some fun, you can also, of course, of course you can use custom properties within. So you only have to define your primary color hex code once, and all the other things might be calculated upon them. It might become something like this, because whenever it gets to be valid CSS cross-browser, we can just add a color, things like that. I think my time, how am I? Okay, so a couple of things. Okay, I won't get too deep it in, but container queries, it's like some kind of media queries, but then you decide on things changing based on the width of the browser window. But maybe if we want to use something in the footer full width, but whenever I want this thing to be in the sidebar, for example, yeah, my viewport is still that large, that big. So I get something like, okay, these are all the default thing. I get something like this, it's no fun because it's like, okay, I won't put the columns underneath each other, because the viewport is so wide. It's wide enough. But with container queries, you could define a container like the sidebars, you can say, and you can, yeah, it's really exact same syntax, nearly the same syntax as media queries. You might be getting this without having to change anything around it. Scroll snap phone, I wanted to add it. You can really use this right now. Go and check some really fun stuff that our girls has demoed. Yes, CSS days, I'm sorry. But the demo at the Netlify app, you can play around with all the different things. Actually, if you play around with it, you'll see we really needed it to create app-like thingies, like so swipe to the right to delete or pull to refresh, feels really, really native. Just CSS, no JavaScript needed. You can use it in combination with the section observer, little bit of JavaScript to have really nice page flows. Subgrates, nested blocks, groups blocks, align white, align full problems. I saw WordPress, kind of true them out for the nested blocks, but maybe we can still use full width, or white widths for nested blocks too. But then we would need something like this. Maybe end of the year, beginning next year, keep an eye on it. It will really change some things. And this one, I'm really sorry if I'm out of time, but really wanted to show this one at layer. It's not full browser compatible yet. But when it's compatible, I really, really hope it will solve all of the important stuff. Because then you can just put all CSS in different layers, within one style sheet, within throughout the website. CSS, the browser will just go like, okay, the first layer they encounter has the lowest priority, and it adds up. Like we're used from CSS, it's most of the time the same principle. But then you could do something like, okay, block styles, you go first, but my team namespace, my team styles, they go after so they have a higher priority. We don't need important anymore because, but then we can still, if it's, I'm sorry, if the block editor has something like, okay, but we really need important styles for something because the user is king. Of course, they can add another one and make sure it's always in cute last. But then if I really, really know what I'm doing, I could still trash it out. I don't know, it's a good idea, whatever. But I think it is meant to solve a lot of the important issues, and we had a few the past year. So I think this one will be a fun thing as well. So I think a lot is happening, a lot of stuff that can be really fun right now, but also in the near future or in the near, or how Gutenberg and full site editing will evolve. So that's why I wanted to talk about CSS. Thank you, and fine end of the day. Thank you. Thank you. Thank you.