 Okay, can everybody hear me? All right. So hi, as Adam said, I'm Helen Ho-Sun-D. I'm here today to talk to you about what it's like to drive what's essentially an extra legacy part of a really large open-source software project, which would be the core admin CSS of WordPress. I think we've heard a lot today about specific tools, how we can use them, how they work, especially this morning. But I'm gonna be focusing really on the philosophy of the why we do these things, why we use these tools, to what end we use them. This talk title is totally a joke. WordPress has only been around since 2003. It's already in the 2000s. According to Jen Schiffer though, WordPress has been around since 1998. So we'll go with it. And this is Jen's sub-mediuming me. It's in there, I promise. Again, I'm from the best part of this metro area, Jersey City. I used to live in Manhattan. I'm a New Yorker by birth, but I like Jersey City. That's my second shout-out to Jen. She's like hidden in there, and a little emoji woman. So I'm the director of platform experience of this web agency called TenUp. We do a lot of really cool things with WordPress. TenUp is really awesome, and we got to sponsor a diversity scholarship today. So if you wanna talk to me about that, that's cool too. And again, I'm one of the lead developers for WordPress. There's six of us. This is something I'm really lucky to get paid to do full-time through the agency. I've been contributing to WordPress for about four years now. A lot of it has been CSS and markup, although I also do things in PHP, like caching and queries and that kind of stuff, and a little bit of JavaScript. I just got promoted to being a lead developer earlier this year, and it's been just a huge honor for me, and it also basically means I've peaked already. So, developing WordPress, really, it's an amazing experience. It's just incredible to get to work on it. It powers 24% of the web, or at least the top 10 million sites, as counted by W3Techs. So whatever that represents to you, but 24% of that. It's a really well-established 12-year-old project with a lot of contributors, and we're always actively encouraging new ones. We focus on users and usability first, as well as providing developers with all the tools that they need, or at least some of the tools that they need, by being flexible and extensible as software. Developing WordPress is also terrifying. It powers a quarter of the friggin' internet. It's a 12-year-old project, which on the internet is pretty old at this point. We have lots of contributors, and we are always taking on new ones. We focus on users and their usability and what they think that they want, or what they actually want, and also developers and the things that they want from a flexible and extensible system. So the decision-making that we make when it comes to developing core and the directions that we take, they're heavily informed by some core philosophies that we have. They're philosophies designed for the majority and working out of the box. It's also informed by our mission of democratizing publishing. It's really easy to look at WordPress and think, oh my God, you guys are not using any hip or cool CSS or there's really old garbage in there or whatever. But there are people out there who can't use the latest and greatest browser, and often it's because they can't. And they have every bit as much of a right to publishing online as anybody else. We don't punish them for not having the latest and greatest tools available to them, and that's spreading this ability to publish to those people. The other interesting thing about having that really large and diverse user base is that we actually frequently serve as an entry point into the concepts of web development. I messed with the web back in your aim profile and Geocities and DHTML days, and I even made it through to Blogger's first redesign, like Dano, if anybody remembers that. Then I took a pretty long break and I studied classical music instead. I became a pianist and it was fun and it was awesome and it made me a better person and programmer even. And then by the time I came back around, which was about 2008, WordPress was an established thing. So somebody mentioned it to me and I was like, oh, that sounds cool. So I set up a blog using WordPress and as it goes with anybody who sort of knows stuff about the web and what they want things to look like, I started messing with my theme. And through messing with my theme, I started learning about CSS, which wasn't really a thing when I stopped doing the web thing, and some PHP. So it wasn't, I wasn't writing like great CSS or PHP, I was probably writing terrible CSS and PHP, but it doesn't really matter. What matters is that this ubiquitous piece of software and at the time budding browser developer tools, which now are pretty solid web inspectors, they showed me that this was something that I could pursue, that I had options for what I could do in life. It can be really great to teach your users about like more dense topics, how to use all these fancy tools that we're always using all the time, but there's also a huge value in continuing to support being able to just jump in to the basics of OpenWeb and encourage them to learn about what it's like to do web development, that it's even a thing that exists, like not necessarily that it has to be a thing that they want to do, but just that it's a thing that exists and maybe they might become web developers, maybe they might make their way into contributing to open source software. So you can think of us as sort of like a gateway drug to your open source projects. We also develop with a commitment to backwards compatibility, which is in the name of user trust. When you have a complex ecosystem of extensions like plugins and themes, it's really important that users are not punished for updating just because we couldn't take a moment as developers like stub out the function instead of removing it completely. And this actually affects their CSS too, where developers have decided to use some piece of CSS and we don't just remove it completely because it could totally break a user's site, at least visually. But there are times where CSS backcompat actually is more than just like a little bit of visual breakage. So for example, at the end of our last release cycle, 4.2, we had added a Z-index to this menu wrapper and in the admin to handle the over scroll thing in Safari which had like visual glitches, surprise. So it turns out that plugins out there in the WordPress ecosystem of like our 30,000 something plugins, for some reason, decided that they should apply a Z-index to the items within this menu wrapper. And sometimes that Z-index was lower than the one that we had defined for that wrapper, which meant that all of the stuff inside your admin menu, like all of those links were inaccessible. So now they're recovered by this wrapper's background. And that's what I call a lockout and that's an actual breakage caused by CSS where a user can't navigate anywhere in their admin, they can't get to their plugins or their themes from within the UI to be able to turn off the thing that has caused this problem. They can go in over FTP, but that's not for everybody. So I took the time to really dig into this, like what is the Z-index for? What is it really fixing? And it turns out that all Safari cares about is that you have a positive number, that we didn't actually have to have this really high Z-index that related to other items in that admin menu, that's actually not what we needed. All we needed was for it to be one, and then it was safe. We didn't conflict the plugins anymore. So, where does WordPress even come from anyway? It was forked from a project known as B2Cathalog in 2003. So if you're wondering why we're like GPL B2 plus, because B2 was, and so we have to be. From B2, we inherited its admin CSS in the form of a file called B2.CSS, and that was their admin CSS. This was renamed WPadmin.CSS in revision 313, and for reference we're almost at 33,000 now, so it's a really long time ago. We actually still have this WPadmin.CSS file today, and it's still the full style sheet for the admin. It's just been moved around a couple of times. It's gone through a bunch of design iterations in 2.0, 2.5, 2.7, 3.2, all of which were before I contributed to WordPress, and then most recently in 3.8. The CSS has also been iterated upon, just like the design, with a lot of the selectors staying the same or just being built up over time. So as you can imagine, after more than 12 years, if you count inheriting B2's CSS, this is kind of a mess. If you're squeamish about CSS, you might want to like not look at the next slide. I'm not kidding, actually. So this is the kind of thing we have today. I don't know how much you can really read it through the room, but they're like crazy overqualified selectors. Totally unnecessary duplication up here. No explanation for why I need to set the float to none and the border to none on, I don't know what the submit is. Is that a button? Is it a paragraph? Is it a box? I don't actually know what this is. It's not document at all. I mean, this is, I copy pasted this out. I think actually it's a screenshot. I didn't even copy paste. It's a screenshot of our current CSS. So I can actually see how all of this happened, right? So these duplicate widths at the top probably came from somebody reviewing a diff file which doesn't give you all of the context of everything that's around it. So the reviewer didn't see that this person had duplicated what was there and might not have checked the CSS file before committing it. Or maybe it happened somewhere else along the way. Some kind of decoration maybe exists on this submit class thing somewhere else in the admin and then we overwrite it without explaining why we're overwriting it here. And then the selectors probably just built up over time because we really, really, really, really, really needed to override a min width. It's really weird. I actually have no idea what any of this is for. Now I'm gonna go review it. So in the middle of all of that design iteration, during 3.3, like literally the week before I started actively contributing, all of the various CSS files that had kind of been created over time were merged into one giant WP admin CSS file. We were having some problems with dependencies and loads. So we have a system of dependencies for scripts and styles in WordPress and it's served through this concatenator, this PHP concatenator. So we were having problems with dependencies being loaded differently and so the cascade was getting broken sometimes and because it's being loaded through a concatenator it was never being cached anywhere because it was different basically on every single screen. So for my first few years of contributing in WordPress we had this one enormous CSS file for the admin. We had a couple of override files for things like right to left and color schemes. And then eventually we hit about 14,000 lines in this one file. Since all of you are presumably really into CSS I think you're probably feeling about like this right now which is how I feel like all the time. It's fine, I mean if it were perfect I wouldn't have a job so it is what it is. But how do we get out of this mess that we haven't purposefully created but that we have today? When it comes to WordPress we started with tools and tooling. We introduced build tools using grunt as a task runner in 3.7 and we continue to use them and expand them today as we work on 4.3 currently. In 3.8 we introduced a preprocessor to help us better manage the different color schemes that are bundled for the admin which are really just color variables. And then also in 3.8 we began generating right to left style sheets using CSS Janus although now we're using RTL CSS because CSS Janus isn't being maintained anymore because WordPress can be used in any number of languages some of which are right to left. Then in 3.9 we also added auto-prefixer to handle browser prefixes. All of these things that I just listed were solving our existing problems and they were existing problems of scale and people time. There were only a small number of people who were hand maintaining color schemes are right to left, mostly me. Leading to a lot of really last minute scrambles as bugs were discovered. Nobody had thought about right to left in this new feature that we had just merged. And we occasionally had to do full suites for browser prefixes in case something had been missed as things were added or something had become totally defunct. Remember KHTML prefix? So in 3.9 I buckled down and I sat down in front of my computer for two weeks restructuring CSS files to move us into position to take further steps. So with the help of some very patient fellow contributors of mine we first merged the default color scheme into the giant WP admin CSS style sheet. Up until this point a separate color scheme was always loaded for all users and it was really easy to miss things because like border style and border width would be in the WP admin CSS file and then the border color would be in the color scheme file. And then this new color scheme generation process now didn't include or import actually of the default color scheme and then defined override. So they became true overrides and that made having a separate default color scheme file totally useless. So we merged it in and this actually made our CSS significantly easier to read and patch. I think actually reduced lines of code because we could use more shorthand. So from that point we then re-split WP admin CSS now into 13 files. If you think about we have 14,000 lines of CSS it's still a lot of lines per file, whatever. But each one of these files represents a substantial focus area of the admin whether that's common styles or forms. We have a separate style sheet that has rules that have been added for specific locales. So it's like languages that have really long strings and we really need to make accommodations for those that we can't generalize. But unlike the pre 3.3 era of split files or separate files, the minified WP admin CSS file that's typically used by production sites it actually stayed the same. It's only in development environments that the 13 separate files are loaded. And we accomplished this by taking advantage of the way a tool works not by using a separate tool just to deal with that but taking advantage of something that we were already using which is the clean CSS part of CSS min. So the CSS minification includes this clean CSS. So what clean CSS does as part of it is it will inline any CSS files that are brought in using an app import statement. So our WP admin.css of today looks like this. It just doesn't add import of those 13 files and that's what that looks like. So then in production environments our build tool then inlines all of that and minifies it and so people still get their one large minified file. And this actually works out really well for people who are doing things like inspecting CSS because browser dev tools already know how to handle import statements. We don't have to worry about source maps and that sort of thing. They know, but it's in this other file and it makes it a lot easier to deal with. Each of these files then also is flipped for right to left and then combined and minified also for right to left. So after all of that work which when I did the split that was a 216,000 line chain set with a slick Rick inspired commit message but our CSS actually just looks the same, right? Like I did all this work, but it just looks the same. So now do you do. I think we start by documenting what we have and creating a pattern library. Our plan is to use inline documentation to generate a pattern library eventually but right now we're starting small and we're manually making a few guide pages because we need to see what our needs actually are before we settle on a tool, right? We don't want our tool to inform, you know, to define I guess I should say our direction but rather what our needs are helps us define what the tool should be. So we need to settle on a documentation standard and a parsing tool and that will come as we figure out those things that we need. There are a lot of really specific styles right now as you saw a lot of our CSS really genuinely looks like that. So this documentation effort will be a moving target. It's just how it's gonna be. But through further steps then we can take this pattern library that is the documentation of what we have and then we can turn the pieces of it that we see recurring into reusable UI components. Establishing these components enables us to provide developers with the resources that they need to build consistent and usable interfaces in their extensions since we typically think user first that's enabling users to have this usable consistent experience but it also serves as a base for automated testing. So we have lots of grand ideas for testing but the most important piece for us is visual regression testing, visual diffs. Each piece in the pattern library will have a screenshot that's committed to the test suite and each run of the test suite will see what's changed between your working copy and the central repository itself. So if you're testing somebody's patch you can see if something's changed. If you're working on a patch you can see if you've created adverse effects. So not only does this help us catch mistakes as reviewers but it helps contributors feel more confident about their patches. When I talk to people today about what holds them back from contributing the number one thing besides time because that's what happens to all of us but the number one technical thing is that they're afraid that the CSS that they're changing has effects that they didn't catch because it's so weird and huge and windy and we don't know what else is it changing in the admin and that's something that I think that visual regression testing would ease quite a bit. We actually, really exciting for me was pushing to get this done before this talk. So in the past week we've got it running as a proof of concept. So we're using a plugin to experiment with pattern library approaches and within that same plugin we're testing out visual regression testing if we're using fantasy assess for that right now and that's really exciting for me. So after that or alongside that really comes naming and cleaning. When it comes to naming things we want to name things in ways that communicate intent to developers like state naming or classes that are specific to JavaScript use that shouldn't be used in a styling context that kind of thing. We have often found ourselves locked into names or not being able to use selectors or even consciously breaking some small number of plugins because they've used a selector that we didn't originally intend for the purpose that they've now used it for and without a solid defined naming convention that says these are the selectors that are used in this context and these are selectors that are used in that context that don't do that for X thing. We can't blame them. We can't be like, well it's your fault. It's actually our fault for not having been purposeful about our naming in the first place. Our current state of naming conventions in CSS is basically we're still painting the bike shed. If you haven't heard that term, you should look it up. I think I guess it's pretty common talking about just endless debates about small things, painting the bike shed for everybody to participate. So I think we've picked a few final swatches or something but I anticipate a lot of lively conversations as we figure out what works best for us as a project and also the larger developer ecosystem who really could do whatever they want but they tend to like to follow sort of like a central community standard. Then we can utilize all of our testing, tooling, the guidelines and then we can clean up the CSS that we have file by file. So once we have the basic things in place and have that tooling in place to help with the cleanup effort, we'll look at things like winters, automated property ordering, I think like CSS comb and things like that do that. Even accessibility checks, just checking for contrast between foreground color and background color. Other types of front end testing like acceptance testing, that sort of thing that we talked about earlier and even performance metric tracking, checking out our time to render, how things are handled on scroll. This gets more into total front end performance as opposed to like just the CSS itself but also how our selectors doing, how much are we doing in these files. I think we'll likely actually move away from using a preprocessor in the form of SAS right now to handle our color schemes and we'll probably move to something like CSS Next and post-CSS and use CSS variable spec so that when we get to that future, we're ready. It's not because like preprocessors are like a bad thing. A lot of it is because we are really just using it for color variables, which is a ridiculous way to have to include a preprocessor for that. But it also just sort of doesn't align with like our current state as a project and our CSS. And it doesn't really align with our expectations of prospective contributors. Our more modern JavaScript, like our media library uses backbone. We use Browserify to build our JavaScript for the media files. And that's because we expect contributors to that area to have experience with those types of tools because it's more complicated, it's more modern. But we don't have that same expectation for contributors to CSS. And really, CSS is one of the first places people can feel comfortable making small changes to. We also always have to be evaluating those tools that we use. So like I mentioned, CSS Janus stopped being maintained and so we moved to RTL CSS. I think like the most common CSS linter that was out there stopped being maintained. So now we have to think about what we can use today. So we think a lot about how they're maintained, how we relate as open source projects. We have to test the output of some of these libraries. So we also test minified files. So we test our development files and we test minified files because sometimes things happen between them. We have to make sure that a given library, a given tool is still useful to us. And then we have to be evaluating what else we might need because the web is constantly changing. So as Run DMC said, it's tricky. There are many moving parts and many unknowns for us. Our contributors who we value so much are people with people things to do with their time. And the vast majority of them are volunteering that time. Our past few releases, like including the I led 4.0, they've counted nearly 300 unique contributors a piece. Some of them shared between releases. It's still 300 unique contributors per release. So when you have a lot of those volunteers, it's really important to give them specific tasks so that they can efficiently use their time and feel like they've accomplished a really specific thing with that time that they are donating to you. Some people work really well with just having sort of a general vague direction, you know, like take charge and take the range and go, but it's definitely not the majority. In fact, I think it's a very small minority of people who are comfortable with just sort of going with a vague direction. It can be really frustrating to work on efforts like the one that I've outlined here because things don't always visibly change to give you that sense of like gratification and hey, look, this is what I worked on. This is the difference that I made in WordPress. And in fact, since a huge part of our goal is to clean up while maintaining at least some amount of backwards compatibility with what exists, little to nothing actually will probably change visibly in our production software except for the code itself. So there are a lot of things that can shape the future of WordPress contributors, different features, that sort of thing. So they're things like the JSON REST API that are in development. I'm helping lead a Fields API initiative which that's on sort of a PHP side but also JavaScript templating and how we handle forms of JavaScript and then the UI for forms and how Fields are used in different contexts around an admin or elsewhere. Responsive images as we've talked about today and so on. I'm really excited about all of those things. Generally I am and as a lead developer it's sort of my job to be excited about them I guess. When I combine all of those things that I've been working on for the past several years and combine that with what motivates me the most in software which is user experience of both your end users and your developer users. This really long and intense roadmap for CSS which could take another few years and I'm comfortable with that. But what that roadmap does and what it enables is my future of WordPress. Thank you.