Refactoring CSS

Next up, we're going to have a speaker whose name you most likely are almost are mispronouncing.

The name looks Spanish, but actually Ana is from Portugal. So it's not Ana Rodriguez, it's Ana Rodriguez.

If I pronounce, I practice that a lot. So it's Ana Rodriguez, not Rodriguez.

And Anna has been through this typical story, which I think most of us have gone through, where you're a teenager, you discover this thing called you source.

You start building some fan sites or a website about something that you like. And this is how Anna got into web development.

She's been developing. She's been working as a front end developer for the last 12 years. So she has a lot of experience with that. And what I really like about Anna is that she also runs her own blog. It's oh, helloanna blog if I'm not mistaken. Yeah.

And related to that, she's also very eager to see you all have a blog. If you don't have one today, she probably will end up cornering you somewhere and then telling you that you should start one. Yeah. Especially after one drink. Like I'll corner you and be like, build your own website right now. It'll be a bit like that, unfortunately. So before we get into all that, first let's hear Anna talk. Anna will be talking about refactoring css. Because we all like refactoring css, right? Maybe Anna can help us ease the pain and make it a more or less painful experience and have some joy of that. Please welcome Anna.

Hi everyone. It's such an honor to be here this afternoon. Thank you so much for spending this afternoon with me. So I'm going to be talking about refactoring css. My name is Anna and I've been working as a front end developer for nearly 13 years and I currently work at Hacktar.

We are an agency that specializes in wagtail cms and we dedicate ourselves to tech for good projects. I love the indie web like Rama said, and my life has gotten much richer ever since I built my personal blog. So when I'm not poking my personal website, I'm probably doing some diy. I recently bought our first family home, an old Victorian home and I've been the project manager, the interior designer and the handy woman in it. And guess what, you're going to be on that journey too because as it got renovated or shall I say refactored, I found very similar struggles.

So let's talk about my recent experiences in refactoring and maintaining css.

This talk came into my head after returning to work following a year of maternity leave two years ago. That year coincided with an explosion of new CSS features that I'm still catching up on even now.

And I was always wondering, what was the latest approach?

How do you build a hero nowadays? What about a card? Oh, the mythical card.

We love cards today. What had the experts written while I was away? Experts are in this room right now.

So I created this overwhelming pressure that I needed to prove that I still had it and that becoming a mother hadn't somehow diminished my technical abilities.

So my return to work became unexpectedly miserable. I was just really terrified of making mistakes, of choosing suboptimal solutions. And the blank canvas that once excited me now just really left me anxious and riddled with decision paralysis. And I'm talking about both CSS and. And a new home. I felt the same when picking colors for my new home. I took weeks to decide because I was really afraid of making the wrong decision. And even though my family reassured that if you picked the wrong color, you could just paint over it, I just really couldn't see that way. And in my mind, getting it wrong meant wasting time and money.

And when I was assigned maintenance tasks or small feature additions to existing projects, I felt a wave of relief.

The scaffolding was already established, and the major decisions had been made so I could make incremental improvements based on new knowledge I had acquired. So these constraints weren't limiting, they were liberating. And I felt the same when looking at my home.

The empty living room with stripped carpets, explosive floorboards, and bare walls terrified me. I was really worried about choosing the wrong color, the wrong flooring, and the wrong placement of electrical outlets and lightning, and it was really a mess.

But in the kitchen, which I had accepted that I couldn't really fully refactor because of time and money, I looked for quick improvements.

For example, I replaced all the cabinet handles to match the existing countertops.

Brad and Ian would love this. They were a bit used, dirty and grimy, and simply replacing them made everything feel brand new. It was just a tiny, small improvement that, to me, made a big difference.

And similarly, when tacking legacy code, I had the baseline for comparison, a tangible measure of improvement. So when I made a change, I could see the before and after, giving me confidence that my work was valuable. And there was something deeply satisfying about this incremental progress that building from scratch couldn't really provide. And maybe psychological.

But this revelation shifted my perspective completely, was prompting signs of like, oh, what a pain to work in this old code base now gets me quite excited because I know I can make it better and I can clearly see the value I'm adding with each change.

So I work in an agency, and many of you might be freelancers, independent developers, or just at other agencies who understand that we're not always building from scratch, whether it's a code base or a bring you home. But even in private teams, you may work on internal tools that have been built over many years. We're not always jumping from project to project, building something brand new with the latest technology, especially getting into the CV driven development.

So yeah, you're not always building from scratch. And I want to make it clear that this talk is not about distinct legacy code bases and that you should be immediately keen to refactor if you inherit one.

And I could wrap up really quickly if I only said, ugh, just implemented this design system and just carry on. But it's not really about that either. And it's particularly not about ignoring budget constraints of small organizations, because it's very easy to say, oh, let's just rebuild this from scratch, because it's not the budget reality, especially in today's economy.

The reality of CSS maintenance is that it often just works without requiring a lot of attention. And CSS has evolved significantly in recent years and I mean, we spent the last two days being amused about the most recent features and proposals. But website built eight or nine years ago won't be using this and it still works.

So legacy CSS can reveal undocumented product decisions.

When you inherit projects built by someone else, whether you're an agency or freelancer or just joining a team, you have to do a lot of figuring it out. And we all want to live in a perfect world where everything is documented and there's a design system and a special dedicated team for said design system. But the reality is it's not like that. And more often than not that the code that is live, it's your documentation. And it'll probably have special considerations for user needs, like specific features or specific accessibility concerns, which means that the product fundamentally has a need to work for a specific group of people, which should be the default regardless. And that probably isn't explicitly written anywhere. An example we quite often forget about, at least I thought about it until yesterday, is the print style sheets. So thank you Rachel, for bringing it up. At Hacktar, we work with a lot of charities that provide support for a variety of illnesses. So imagine a website that informs people about a certain illness and provides recipes for meals to manage such conditions, so people will often want to print those.

We also deal with a need for printing helpful notes or questions to take to doctor's appointments, like questionnaire results for being a risk of certain illnesses. And in projects with high team turnover, the moment someone leaves and somebody else joins, they'll have a brand new vision that will clash with what currently exists. Very small organizations may not have sophisticated documentation systems that because they're typically overstretched, overworked, and have zero money I took this photo in our loft when we removed the old carpet. The builders left some documentation. Danger. Well, definitely danger, but maybe pipes, who knows? The code is often the only place where developers document their technical constraints that they faced, so it's not usual to find comments saying sorry or explaining unexpected bugs, browser quirks and their fixes. So I remember looking at one project that had specific comments apologizing and saying this was a solution due to the lack of time. And we've all been there. We've all been in a situation where time constraints and simply being human made us come up with solutions that worked for the time we had. And yeah, we all want to hand over the best code in the world, but it's not always possible.

So what motivates a CSS refactoring normally as a consequence of performance or accessibility? Sprints, because these have measurable before and after results due to brand redesigns or visual identity changes that don't necessarily mean that you need to rebuild the website from scratch.

Sometimes some tools, especially if you're using CSS and js, will actually get discontinued and you're stuck. And when adding new features, you may start to find problems like inheriting unexpected styles.

When I think about a CSS refactor, more often than not I think about projects that we inherited that where adding new features became really painful and time consuming. So I'm mostly going to focus on that one.

If you think you ever swept something underneath the rug, like some questionable cold or whatever, don't worry. Whoever lived in my house put a whole fuse box underneath the stairs. So that was the legacy I had to deal with and rewire a whole house. So wow. Oh my God, why would anybody do this? Are the words you'll likely hear when tackling legacy issues. In my house, I happen 90% of the time a contractor came over to give me a quote. They look around, they assess the situation, and I know I'm about to have a very bad time when I hear those words.

When I inherit a code base built by someone else, I go through a general high level audit to see what I'm dealing with. In the past I've definitely said something like that, but thankfully I've grown out of that attitude.

Styles cascade and interact in complex ways that aren't immediately obvious. The visual nature of CSS means that problems are very likely context dependent. What you perceive as a flaw might just be your opinion.

And remember, you're not fixing something broken, it's working already.

And that's what makes issues difficult to identify More often than not. When I approach a CSS audit, I forget about the shiny thing everybody talks about. I have to forget about it design system, because if it exists, the majority of the time it hasn't been updated since the original design sign off and build. The good news is that nowadays it's common to inherit a code base that doesn't really stray too much from the pattern we used to see. And even for small organizations with large websites, you'll almost always find a main file that imports a bunch of components, base variables, utilities and things like that.

So the structure doesn't normally stray too much from this pattern.

Which is why after a while you're just looking at code that seems sensitive and it becomes really hard to spot issues. And when you have zero documentation or style guides, you may need to start by figuring out how many different components exist, what features make up the website, and if you have files like hero cards, footer, navigation, banner, css, whatever, you get a sense of how many components you might be dealing with, hopefully.

And nowadays I can spot a few glaring issues a bit more quickly, like multiple selectors to fix specificity issues. In this case, this code base was constantly overwriting styles set at a very high level for a heading too.

I was recently looking at a code base with lots of supports for CSS grid, which immediately gave me a timeline of when the code might have been built. I mean, we had no git history, which by the way this happens, you can literally be sent a whole code base without git history.

Grid has been baselined for a very long time and this means that there's a lot of cleanup and if we don't do it, we must pay special attention to where we're adding new code.

I still find IE11 targets too. I know with that particular example being in sas by the way, this tells me that conversations need to be had about browser support and testing.

And if you keep finding that inside many components there's a margin or a padding being reset, it may mean that something on a higher level has go wrong or is no longer suitable and is now constantly being reset instead of tackling the issue at the source.

One time I had to find a class called accordiontitle and I was quite confused when the search returned nothing. So what was done here is that again using Sass was to store the current parent selector called accordion in a variable called root, and later on the root variable can be used when nested. And that kind of avoids hard coding class names which okay, I'm sure this technique is really helpful in some scenarios, but I personally kind of prioritize readability and easier developer experience than this type of optimization. But what I learned here was that in this project in particular, finding CSS by searching by its class name was going to be an uncertain task, and that's why it's communicating to me. And there's other bits you may pick up on, like outdated layout approaches that can be replaced with modern CSS features only if they're a problem Performance Improvements Accessibility Concerns this has been brought up throughout the last two days, but Sarah's talk from last year covers a lot of accessibility improvements that can be done on css. For example, filling the content with text with an alt text like as mentioned these past few days. And another thing you'll notice as you scroll through the code is media queries and responsive behaviors that add layers of complexity that aren't immediately visible. But they're also incredible documentation because you'll often see things like if on I'll call it mobile view, but I mean like a smaller resolution. If on a smaller resolution, don't show this thing, particularly using like a display none or something.

And that's product documentation that may not exist anywhere else in the code.

You'll also spot on, maybe potentially spot some unused styles or identify duplicates or near duplicates that can be merged.

Sorry. In the UK when you buy or sell a house, a surveyor is normally involved and they love this little device and it's the bane of my existence. It's called a moisture reader and it's one of the things I truly hate the most. They audit your walls and check for damp. But beware, the same device will produce different values whether it's tested during summer or during winter. And sure, if you do have a case of water damage it will shout fine, but it may also shout if your wall is fine. Anyways, during your own CSS audits you might be thinking about automated testing or automated tools to be part of your audit and data gathering. And the topic of CSS refactor isn't new and throughout the years we've had some tools come and go, but I'll share some that are active and maintained that I personally find quite helpful.

This is Project Wallace, the creator of it is actually here.

So Project Wallace is a free tool that can be used in your browser or your cli and it does what it says in the package. It tells you what it thinks about the complexity, specificity, performance, et cetera of your css.

So hi, well done. I like it very much. The other one that I like a lot is CSS stats. It's also quite a fun one, but also it includes the spacing resets which is something like I mentioned just before, it's something I particularly look at and by having a number, even if it's like a high level estimation, it gives me an overview of how much of Big U it might be.

They also include like specificity graphs, but most of them do Anyways, In Chrome Devtools there's a simpler overview of your css.

I've had some shaky experiments with it, but I like that since it is integrated in the browser, with one click I can check the elements that are using the things mentioned and it includes things like colors, fonts, unused declarations, and media queries. I'm using my personal website as a test for this one and also in Chrome you can have a quick look at the coverage tool that returns an Overview of unused JavaScript and CSS on a loaded page.

And I agree with Chris on this. The idea of finding unused CSS is a whole chore, but looks like you can even go a bit further and bulk find unused CSS and JavaScript with puppeteer for example.

But then again it's a chore. When trying this out on my blog it tells me that 64% 8 of my CSS is in use on the homepage, which yeah, it's true. The code above that is highlighted in red is actually related to my guestbook, which indeed is not on my homepage. So my personal website is small enough that I might find some time to do some time extra to do something about it. But maybe on my spare time, who knows, maybe it's not the end of the world in Firefox. I quite like this view in the Style Editor where it lists all the rules found in the CSS loaded. By looking at my own website I immediately spotted two that I think I should review and update eventually. Again, not the end of the world for this one, but when I use it the same tool on a real website it tells a more complex story and this may be necessary complexity or a sign that the designs were quite strict and fluid layouts were not applied there. Well, definitely not smart layouts. By the way, like we learned from Ahmad's amazing talk, there's nothing smart going on here. And different brains process information differently the same website by using different tools.

Chrome compiles the same media queries together, while Project Wallace gives it the options to sort by view the source order or sort by count or sort by alphabetical order. So it's pretty much up to you and what scratches your itch basically.

And when you run a CSS automated audit, the high numbers in reports can seem alarming, but they just actually might be completely appropriate for your project.

If an audit tool flags that you have more than 100 different colors without understanding the context or purpose of those colors, it doesn't give me a lot of useful information. You might be dealing with a website like an online shop that needs catalog all these different colors, or it might also bring up colors using SVGs which again are unlikely that you necessarily to be known about. So these raw statistics don't actually capture the nuance, may not not always capture the nuance of intentional design decisions. And even assuming that specificity, oh my God, specificity data is useful. Let's just forget about these tools cannot distinguish between necessary complexity and technical debt.

So sometimes you need complexity to override third party libraries that you have no control over like cookie banners or chatbots.

And yes, yeah, that does happen every day.

So after you feel like you've got a sense of the code base you're dealing with and you have a high level notes of technical bits that you think think that need attention, it's time to consider next steps.

I would start by documenting low hanging technical debt in tickets, particularly accessibility and performance issues that are really obvious.

Label the quick wins for momentum, but also quick wins allow anybody in the team to pick up, especially if you onboard new team members.

It's a great way to get people to work on those if they have time and start by asking questions. You can ask questions about browser support, roadmap, any other known problems and document them.

But bear in mind more often than not you may be dealing with someone who's also new to that project and they don't know answers to any of these.

So throughout these days many exciting things have been shared and it can be quite easy to forget about them. So if something got you excited and it will be perfect for existing or future projects, make it visible to everyone. That's my advice. You can spin your own baseline status and make it part of your toolkit. Google recently announced a handy tool called Baseline Checker which should help you to be even more specific to your project by allowing you to upload the analytics.

And this is great for me because the websites we usually work on have very specific demographic demographics and people may use older devices. So many of the things I see all the time being released I can't really use them for a long time.

So once I realized the quote to do up all the rooms was more than I could afford, I was forced to scale back.

I decided not to work in the kitchen and the bathrooms, they were clean, they were function and it could wait.

And my contractor told me something, you should wait anyway.

Live in it and find the pain points and then you'll know what you want, what isn't working, and what works for your family and for your routine.

Low hanging fruit and glaring issues are great motivators to start conversations and to feel motivated to improve the code. But like we know, CSS just works and it'll take some time to fully grasp how much impact the legacy code base is having on the developer experience until you actually have to work on it. And this may take a while, which is ideal if you're not a freelancer or a consultant brought into work within a time frame. But some projects may only have a couple of hours assigned every month, so you don't have a lot of experience in it, but a bit like a therapy session. Ask yourself a few questions and document them. What is causing me to take longer to add or change a new feature? What normally comes back as a bug after we work on this code base? What do I dread to touch? Could anyone arrive to this project and make this change and is it a real problem or it's just not done to my taste and you have to be really honest on this one.

So I thought I'd share some real life examples of pain points I've recently experienced. Whenever we add a new feature that allows some rich text to be added via the cms, the utility class the project currently uses adds extra margins to the container as as to all the paragraphs. This means that lots has to be reset every time in new features, especially if only one paragraph of text is added or the new spacing guidelines are very different from the existing ones in the code base. Whenever we add a new feature, it inherits the existing spacing and we have to overwrite it to match the new designs.

Or for example, the same template is being reused for multiple differently styled cards and we have to go deep in specificity.

Hey, nailed. Takes more time to make sure we're changing the correct thing. Or for example, there's a lot of unnecessary code. Nearly all the code is written inside some supports which are now baseline. Whenever we make changes to that code, we need to pay extra attention to where we are adding it.

So because of that, once you've got your pain points down, we need to talk to product and we need to discuss how to talk to our product people. And they want to know why they should give you the time and money to make these changes. And it can't be just for your own vanity.

Now I'm going to use product owner or product people, but this means whoever calls the shots on what's being worked on next and whatever their role may be called.

I love this quote by Gerry Reads. She's amazing. It says actual design systems return of investment, scalability, collaboration, speed, cohesive brand. You can't guess how much money your design system saved you. But product people like that though they love a number. In other words, decrease time for implementing new features, reduce regression bugs when making style changes, improve consistency in the user base, improve consistency in the code base for better developer onboarding and clear documentation Component organization so you need to make a business case. Product people are tasked with delivering experiences that make money, or at least don't lose money.

We need to connect refactoring to specific business problems being solved, and we must demonstrate how technical debt creates real business impact and document the before and after developer experience.

Unfortunately, not just metrics like reduced file size or faster loading times. Because yes, these improvements are great, but if your website is primarily visited by people on fast desktop connections, they won't make a significant business impact. And you need to highlight specific pain points that generally need addressing. So if I tell a product person, if I do a CSS refactor, I'm going to prevent all the future issues. But can you really? Can you promise that? Can you make that promise?

How do you measure it? The same challenge applies to improvement and ability. So when you enhance the code base for the developer experience, the value takes time to materialize. Basically, it's rarely immediate because the following task could have been easy to do regardless if the code has been refactored or not. So there is no metrics there, and organization and structural benefits take time to appear. A knowledge transfer and documentation value is quite difficult to quantify, so you might create documentation primarily for yourself, but it's a significant time and money investment that will probably not yield obvious rewards. And I Love this blog post. It's so funny because it's unfortunately very relatable. If a bug fix isn't tied to a specific requirement or feature, it gets labeled as tech debt and shoved to the bottom of the backlog. And let's be honest, tech debt is corporate speak for we'll deal with this never.

Never. It's true.

So the big question is, can you convince the product owner of a fairly dormant website to be refactored?

Probably not. And they will ask you, how do we get the money back from investing your time doing this? Can you answer that?

Probably not either, but there's hope.

What they really actually want to know is how does this mitigate risk?

And mitigate risk can sound something like if we don't do this, this very annoying thing can happen and it will delay many other things. This is a rare occurrence with css, but if you have specific pain points, this is the time to explain them.

Now let's imagine a time in the future where carousels with CSS are baseline and a fully accessible feature. And then you've got a website that every once in a while gets new features added and has a maintenance budget. That website actually has some carousels all over it. The content editors can add one to every page if they wish to do so via the cms. But the carousel was built many, many years ago with the help of a third party library.

And this is you. You love the craft, you thrive on doing the best you can and you find yourself itching to go back and improve things as you learn. But it's on your personal website and we all got bills to pay. If you work for an agency, trust me, they do not want you to work for free. And if you work in a product team also, again, trust me, the product person has a lot of other things they would rather you work on. So how could this conversation go?

Let's try it. Hey, so you know how we use those carousels on the website? You know, I think we should replace them with CSS carousels. Here's an example and the product person will likely ask you so what's wrong with the current implementation? And you may go, it works, but it's using a third party library and it's always good to delete some code and remove reliance on JavaScript.

I personally think that's a great argument. They would win me over if I was a po. Good thing I'm not.

This is the opportunity to mitigate risk of third party fallout.

They will ask you, is a third party library still being supported and you have to be honest. So you're going to be like maybe. Well I could just kind of check the repo and has been up there for a while, so I guess there isn't a need to.

They'll likely say something like well, I'm not sure if that's where we should be focusing right now since it works, but it is the opportunity to mitigate risk of a third party fallout. Context dependent of course, but what happens is this third party stops being maintained. What if it's bought by another company? What if suddenly gets a pricing plan? What if suddenly gets random NPM packages injected into it and suddenly your code is full of malware or whatever. This is an opportunity to have conversations and educate people about it.

But I want to isn't going to cut it. I wish it did.

But if they entertain the idea they might actually ask a few more things.

They could be like these are examples of questions to be prepared to answer if you want to make a case for product regardless of what feature you're keen to refactor. Imagine are we limited with how it looks like? Is the UX improved?

Does it feel more native? Does it unlock brand new features?

Can we reproduce the exact same design?

Let's try again. Hey bestie, so I learned about this web feature and now that it's safe to implement, I think we should use it on this component we have on our website. We've been pretty good with accessibility overall and refactoring this component to use something that we know is accessible will increase our confidence. I agree, but sometimes a good selling point can be if we do this, imagine we can make a website go from 90% successful to 100% accessible. Again, wild numbers I know, but bear with me.

However, this may not be a convincing argument if the website isn't really accessible in the first place and only this feature would be. So again, this is a cultural problem, but it may be the upsell specifically a number that the product people can also back themselves with to use as justification. So you'll be potentially mitigating the risk of accessibility standards increasing.

Let's try again. Maybe this one doesn't work out. So this is where this is like last minute plan to back them into a corner I think.

Hey, so since we have some hours per sprint for personal development, I learned about this web feature at CSS day and now that it's safe to implement, I think we should use it on this component we have on our website. I would like to spend my time this upcoming Sprint experimenting with this. You may work somewhere that allows you to spend some time on personal development or projects that are work related. I mean, if your employer is paying for you to be here, you've got to go back and implement what you've learned. This is part of the job.

But then you can also go by addressing the pain points. And this is a shorter version of how I would lay out the issues. But don't be shy to go in debt on examples. Hey, so we have a lot of CSS inside supports to cater for IE11 users. This makes changes really time consuming and prone to errors. Is IE11 a browser we have to support? And they may get back to you and say something like hey, so I had a look and it looks like we haven't had a single visitor using IE11 in the past six months. Let's remove it then. And then they say the worst thing ever. We need a time estimate. Hate it.

Good question. Let me think about it and get back to you. It's happening in a lot of features and we'll also need to test them all. Again, said the wrong thing here, right? Let me know when you have a time estimate.

But it looks like it might be a while until we have time in a sprint to book that amount of work. So we love a big refactor and we feel so special when we see the big numbers on that files Change tab on GitHub. I get it, a pull request, but the world doesn't spin around us. And those big changes also imply big testing.

So this may also be a pro and this may also be a project that only gets a few allocated hours per month. So it's not really feasible.

So let's get back to it. Let's go back and try and a suggestion might actually come from the product person. All right, so in that case, instead of doing in one go, let's attach that work to when we're working on those features so that testing is included instead of doing a general regression testing. And that's a great idea. Changes that need a big general regression testing impact everyone. Not just you, but qa. Product people releases everyone. So increase the chances of getting your refactor approved by product by suggesting it to be aligned with planned feature development.

And who knows, maybe holiday periods, slow business periods or new team member onboarding.

Product people prefer refactors to rebuilds. It's a known thing and you can speed your approval by preparing your arguments. Is there metrics to track CSS related bugs reaching user acceptance testing? Have you documented development roadblocks or slowness due to the need of a refactor. Can you demonstrate how the current CSS impacts the feature development? Has this been documented to the product team before? Do you have visibility of the product roadmap? If so, are there upcoming features that might be affected or actually benefit if you do this work? Are you able to share how the lack of a refactor impacts your time estimates? Would it improve predictability, which allows product people to plan with more confidence? They love that. By the way, this is a quote that stayed with me from the book called how to Make Sense of Any Mess by above Abby Covert don't procrastinate.

Messes only grow with time. You can easily make excuses and hold off on doing something until the conditions are right or things seem stable.

Perfection is impossible, but progress is it can be quite intimidating to approach product team as someone who has experience working in an enormous company with hundreds of developers where only some voices were heard. It can be a frustrating experience too, so so don't be discouraged to document your opinions and your knowledge and share them. And those people might actually just be your teammates, a team leader, an engineering manager, et cetera. So you've waited. You figured out what are the pain points, what is a priority from a developer perspective, and you've got the green light from your product owner to carry on and do the work. So here are some bits that I've kept in mind recently.

Harry Roberts wrote and gave some talks about css refactors nearly 10 years ago, and they still hold on to their practicality.

Harry calls them the refactoring tunnels, and the idea is to refactor by component or by feature in isolation, keep a temporary file to allow overrides of the newly refactored component, and then delete those overrides once you tackle the higher level utilities that are causing the need for those overrides.

A temporary file can be called something sensible like overrides or defend or slayer, whatever you want to call it, which is what they suggest and whatever you want to feel like anyways.

But this is the most helpful and hopeful route to tackle a big CSS refactoring in one go.

But taking that advice in mind, going component by component, feature by feature, let's think about improvements that can be done on one component level.

Let's bring up the cards again. Again, popular today, I'm the first one to admit that I still get caught up on naming things and then regretting it, and my brain is sometimes on autopilot and I may take the designs a little bit too literally so it wouldn't be unusual in my daily work to build a typical card block. And from the designs you can see that there's a card style of latest articles, some events and a card for team members. Great. Some shared styles. So you may go with the approach of breaking them into two and then you deliver the website and it's beautiful, it's glorious. It has a team page, it's perfect.

But then the website is live and bam.

Yeah, that person card. Turns out that fit other needs that weren't really specified. Turns out they also wanted add cards for sponsoring and adopting and they use the person card. Why on the cms it's not really clear. It's a person card, it's just a card. Why would they so think about how a feature will evolve. There it is. Josh.

It's exactly what Josh says in his talk. How do we keep going wrong roundabouts and APIs regardless of the reason why a refactor is being done, use that opportunity to make your life easier in the future and it's a great idea. I particularly love this example that Josh shared at the time. Booleans can restrict restrict you once you need to go beyond the true or false. So they go. It's such a great example. Instead of going for a dark mode true, you can use a new instead and have a theme and list the themes you are actually using.

So once we figure out to name things we can go one step forward.

And personally I like to move on from the idea of using the class property as the only way to represent the state of an object and this can also depend to be honest, this depends on the project you're working on. But what about I figured how about I start using a data type to see the type of card it is. It could be an event, it could be a person, it could be a sponsor and I'm not limited then and I can add more or a better example, a progress bar.

Styling based on the value of the data attributes makes your life easier when updating the status of something via JavaScript and removes the need to add or remove classes. Keith's circle goes in depth on why they also think this approach is quite reasonable. It's a lovely article and I really recommend reading it. If we go back to the CARS example, the article includes the following example which I quite like and I quote.

Attribute selectors like attribute tilde value allow you to treat the value as if you were a list and this can be useful when you want flexibility in styling parts of a component such as applying a style to one or more border slides. I actually learned this from this article in particular that you may list the styles with the tilde value and then when you use the data border collapse you can add more than one value. It's great.

I know we've been going on and on about logical properties in the last few days, but trust me, it's for a good reason. It's time to embrace logical properties because translations are here to stay. People are adding more and more automated translations to their websites every day. So next time you touch any component and you're using a padding or margin, use that opportunity to change them.

My big advice is do maintenance every time you work on a component as testing will be included. If you got a small task to a component, take that opportunity to give specificity issues Some love Nested classes give us visual hierarchy Nested classes give us a visual hierarchy that is really satisfying to our brains, but they're actually not needed if the elements have their own class and you're not really overriding something in particular.

So every time you go back to a file and change it, even if it's not feature related, it's time to do maintenance regardless of why you're on that file. If a component is being fully tested because of a small change, increase the time estimate just a tiny bit just to take care of that probably small CSS file. And this is also the time to move on from pixels to rams, use font clamp.

You may even be able to delete media queries. They are just setting font sizes and just move on and come to 2025 and use logical properties, et cetera. So what about automated testing? Right?

So I think we've moved beyond the era of pixel perfect design to fluid adapted designs that respond to the user's needs, devices and accessibility preferences. And this is a challenge as well for traditional automated visual regression testing because even with thresholds this may not be the best use of resources unless you have a very specific product that needs this. And in my personal experience individual component testing is the best.

So imagine a faulty boiler, a faulty tap, a grimy cupboard, handles and a drafty window being components of your website that eventually got some love and sit tightly with everything else.

And sure, around the edges some extra love is needed, but the pain points were fixed. In the end of the day it's about progress, not perfection.

Writing tidy and non chaotic CSS is a skill.

A skill that I have to work on every day. A skill that you can work on by going back and mending and not just Building brand new from scratch. A lot of loud people think that using a framework removes the need to work on a skill. But you're only adding risk rather than mitigating. And you probably already have enough risks by trying to do an NPM install in the first place for your build process. So honestly, CSS simply works. Use it. It's there.

Thank you.

Thank you, Anna. Please join me at the cozy table.

Pick the easy ones.

You have a guest book on your website.

You have a guest book on your website. I saw some options. I was like, oh, I should check it more properly. And yes, but you have a modern guest book. Like back in the day we had three inputs, like your name, your email, maybe your website. Yeah, that's it. And then the message. But now it's webmentions. It can be.

You can do whatever you want. Your personal website. Yeah, play with it.

Experiment with things. Have your own website. I saw by the way, that you have two URLs. I know, but they all go to the same place.

Okay, okay, okay. This is a really fun story. It's not fun at all.

I realized that I had a phase that I didn't want to use my last name online. So I was on Pinterest and I saw this inspire, this influencers being like, oh, hello something. And I thought, okay, I'll use my first name on that. And then I realized that means something else. I only learned last year that it means something else. That is not nice. So I've slowly, I'm slowly going to try to move on from it. It's a whole thing.

But yeah, I have a few URLs that I being very. That I'm hoarding. Who else is guilty of hoarding domain names? See side projects related or we should find a lot of time, everyone, each and every one of us to finish those things.

I love how you said what you perceive as a flaw might just be your opinion.

I think that is one of the mistakes that we often make. Somebody shows you a piece of code and you open up a demo and you try to find, oh, they did this wrong or they did that wrong. But in the end, the end result was there. And some choices have been made in the past and it works. CSS is great. It just works and it works.

That said, how do you feel like we are coming into this time where we see a lot of folks just asking some bot to give an answer like, hey, center me the label and then it will spit out apps, pause it top 50% left 50% and then transform it back.

Yeah, sorry, I'm just trying to.

Yeah, but that. That might be linked in a historical thing. Right. Like you mentioned with the code, with i11 include.

It's like it's a relic from the past. It's a relic. It's.

How do I feel about it? I.

I try to think about what problems is it causing? Is it inaccessible?

Is it causing problems? Those are the first questions I need to ask myself because I don't deal with. I don't work in product. I work with charities that can barely afford to hire developers to maintain their website. So the way I look at code and when I have to do maintenance, I also have to be very specific on what am I prioritizing. Is this something? Is this for their accessibility? Is it for safety? Anyway, those are the things I look at most. Yeah. Sometimes we're going to see something that is not how I would do it. But is it causing any harm? If it's not, probably it's not the priority right now. You just mentioned the chairs that you work for. We were discussing this before your talk and you mentioned that you have a more realistic angle sometimes to web development. It's. I used to work in a company that had hundreds of developers. We had the fanciest CI pipeline thing you'll ever see with all the automated testings. It's a big investment.

They had to hire people just to maintain the pipeline.

It's not realistic for the majority of the websites.

Someone yesterday was mentioning their dentist websites, like, yeah, your dentist is not going to have a CI. They're not. It's not realistic.

They're going to have a very. A website that works and does the job.

And most of the times I have to forget about the fanciness of many things and many things will just have to be experiments on my own personal website if I want to. But they're not realistic, they're not part of the day job. And I think that's quite realistic for many people who don't work in big companies or websites that don't make a lot of money. Yeah, that's it. If they make a lot of money, they're really afraid of breaking the pipeline or breaking a test or something. Yeah. We have a question from the audience. Gautier, I might be misinterpreting your question. It has to do about the vertical slicing about refactoring something on the website and then injecting it into related feature tickets. The question is, how do you prevent a refactor being partially implemented and then new features showing refactor behaviors.

I don't understand. It depends on the feature. It depends.

It really depends on the feature. You have to make a commitment.

And this is about communication as well. For example, I have. One of the things we have is a card that is quite problematic because that card has become a beast. We have to accept that we're going to refactor it and we're going to do our best not to have anything leak to other things. But there may be a small moment that you. You have to live with a mess for a while.

It's like on my last slide, I showed a photo of my kitchen. Yes, like, the walls are still quite manky. They could use some filling, they could use some painting. But it may be that you refactor something to make a feature accessible, safe, easier to go back to and touch again and increment on it. But it may be that you also have to do something less nice to make it work and not leak to other features on the website until you can safely go back and then at that point, then again leave comments for not only your future colleague, but also your future selves. Yes, but also we have to ask ourselves, what is the worst case scenario? Are you going to have like a bigger margin at the end? Is that the end of the world? Sometimes it's about.

Sometimes there is compromise to be made and there's communication to be had.

And I've had situations that I've asked, okay, if I go back and refactor all these refactor, change the values of all these utility values, like spacings, for example, it may be that some feature somewhere on the website actually has some margin art coded. That is the worst consequence. It may be a little uneven until we spot it and go back and fix it. So what is the worst consequence that can happen is something you ask, have to ask yourself if you touch it. But something, you know, styles cascade and something else happens. What is the worst that can happen? Is it an extra spacing? Okay, well, maybe it's not the end of the world, but there is a balance to be had. Josh. I think I know which Josh is asking, which do you enjoy more refactoring a house or css?

Yeah, it's the one, Josh. Yeah, that's a really tough one because I really enjoy refactoring css. It's so much fun to see actually deleting code and, and have and see this before and after and feel really smug about it. But when I find something so cheap in a charity shop and I strip the paint and it's proper wood. Oh, my God.

I think it's like, some sort of common theme. I often see that people who work with computers and, like, in our jobs, we make websites.

And then there's also, like, yeah, I really like chopping down a wall because it's not just an escape myself. Computer hands, they really have to. To do something that's, like, physical. We all want to go to the woods and hide and not look at a screen anymore. Answer quickly.

Can you say specificity a few times in a row? Specificity.

You did it right. You did it right. Perfect. Perfect. Perfect.

Yeah. It's a tough word to pronounce. One of the quotes that you mentioned was one from how to Make Sense of Any Mess.

It was a quote on procrastination. Are you a procrastinator?

Yes. Okay. So am I. Do you have any tips to people here who might also be procrastinators on how they can avoid that or how they can trick themselves into getting productive?

Okay, this is not good advice.

I stopped being a procrastinator ever since I had my daughter because I realized if she's ill, I have to miss work or I have to, like. I'm not able to do things, so I have to, like, maximize the time I have in case something happens. But you can think, like, you could be.

You could have an accident or something. You could think like that. No, no.

This is terrible advice.

I've recently been forced to use the time I have wisely. Otherwise, bad things happen.

Live in fear all the time. Yeah. And we don't. We don't want that. We don't want that. I think one of the tricks that works for me is that I just trick myself into just start creating the new slide deck and put the slides in, and then you'll. Because it links back to the quote that you had at the end, which is like progress, not perfection. Exactly. Yeah. And by tricking yourself into progress, eventually you will get to. It's picking up the momento.

It's like something you have to accept. Mess, Raw, ugly.

Start. And once. Once you have a direct. Well, it's. Starting is all that it takes. And then. Because if you.

It's basically like Also like doing a talk. Like my. My slides.

It's not like they're artists. I think they're pretty. They're all right. These are great. These look amazing. I should have been drawing as well.

But starting is the hardest thing is, like, it's.

The blank covers is really, really scary. But yeah.

Cool. We have another question. From the audience, Subu asked that they have an old code base, lots of floats going on, repeated styles, hard coded font pixel values, color values all over the place, hard coded ones.

They have recommended to product to completely rebuild each component. They tried to refactor it, but the damage was already done. Do you think any kind of messy code can be refactored without replacing it completely with a new CO code base? I think it's possible.

They tried to revive, but the damage was done. Do you think?

Yeah, I really feel like. I feel like Harry Roberts tried to cover that exact scenario.

You can look up these. I'm pretty sure those talks are also on YouTube because he did a tour at the time. I guess it's really about breaking into. Like he says, looking at the light at the end of the tunnel, you have to live with the mess. And that's one of the things he does highlight that you can break into priority. You can break into features, you can build things in isolation, testable. But they have to live with the mess. There's no way around because it's also not. You have to be able to work with what you're effecting, what you're doing, because you can't.

I've worked somewhere that stopped for a whole year to rebuild something from scratch and guess what? Nothing got done. Not even the old website or the new website. Website. That's not business wise. That's not a smart way to go about it. Yeah, baby steps, right? Pick up one component, load up a totally separate CSS file and do your thing with it. Yeah, but also it's definitely.

People struggle to live with something imperfect and that's. Yeah, we have to let go of that.

We have to. That's something we should embrace. Cool.

Solid advice from Anna. Please clap it up for Anna.