Ana Rodrigues

In recent years, updates in CSS have given us many exciting possibilities for creating modern, dynamic web experiences. Yet, for many developers, the day-to-day reality often involves working within the constraints of legacy codebases.

In her talk, Ana will explore practical strategies for navigating the challenges of maintaining and modernising legacy CSS. Is refactoring an option? What are the pros and cons of this? How do we approach stakeholders? And if refactoring is not an option, how do we prioritise and initiate changes, measure improvements and quick wins? Ana will share lessons from past experiences and look forward to what’s ahead.

Transcription

(Applause)

Hi!

So I’m going to be talking about maintaining and modernizing and refactoring CSS and other stories, which is probably what you end up doing if you don’t get the core right.

My name is Anna. I’ve been working as a front-end developer for at least 13 years. Been coding for more than half of my life. And I’m currently a hacker. We are an agency that specializes in Wactel CMS, and we dedicate ourselves to Tech for Good projects.

And I love the IndieWeb. I’m wearing a pin. I have stickers after. I love people of stickers, so come find me to get IndieWebCamp stickers. Did you attend IndieWebCamp last weekend?

Nice one. So I missed it, but I lived the spirit of it. I love the IndieWeb community, and my life has completely changed because of my personal blog.(...) And if Sasha’s talk got you inspired to create and share on the web, come and chat with me and all the other IndieWeb folks that are in the audience. We have so many ways to tell you how to get on that journey.

And when I’m not working on my personal website, I’m probably doing some DIY. And we recently bought our family home, an old Victorian home, and I’ve been the project manager, the interior designer, and the handywoman in it.(...) And guess what? So I’m going to be taking you on that journey too, as it got renovated, or shall I say, refactored, because I did find similar struggles with the CSS world.

So I’m going to talk about my recent experiences in it, and this talk came to my head following a year of maternity leave. I went back to work, and that year coincided with an explosion of CSS features that I’m still catching up even now.(...) And I was always wondering, what is the latest approach? How do you build a hero nowadays? What about our cars? And what had the experts written while I was away? And 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 skills.(...) So my return to work was quite miserable.(...) I was terrified of making mistakes. I was so afraid of choosing suboptimal solutions. And the blank canvas that once excited me now riddled me with this anxiety and decision paralysis. And I’m talking about both CSS and a new home, because I felt the same when picking colors from a new home. I took weeks to decide because I was so afraid of making the wrong decision. And my family reassured me that it’s okay if you’ve got the wrong color, if you don’t like it, just paint over it. But in my head, getting it wrong meant wasting time and money.

But when I was assigned maintenance tasks or small feature additions to existing projects at work, I felt a wave of relief.(...) The scaffolding was already established, and the major decisions had already been made by someone else, not me. So I could make incremental improvements based on your knowledge that I acquired, and these constraints were limiting. They were liberating to me. And I felt the same when looking at my home. The empty living room with stripped carpets, the exposed floorboards and bare walls were terrifying me. I was so worried about choosing the wrong color, the wrong floor, the wrong placement of electrical outlets, and lighting. It was a mess.

But in the kitchen, which I had accepted that I couldn’t 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. Yeah, terrible photo, I know. I was not thinking about the aesthetics when this was taken.

But, you know, the old handles were quite grimy and dirty, and just replacing them made everything feel a bit brand new, and it was a small improvement that, to me, made a big difference.

It’s similar when taking legacy code. I had the baseline for comparison, a tangible measure of improvement, and when I made a change, I could see the before and after, and that was giving me confidence that my work was valuable. And there was something quite satisfying about this incremental progress that building from scratch was not really giving me.(...) And maybe it’s psychological, maybe it’s all in my head, but this revelation shifted my perspective completely because before I would be like, “I want to paint to work in this old codebase,” I was actually getting excited about it because I knew I could make it better. And I could clearly see the value I was adding with each change.

And I work in an agency, and many of you might be freelancers or other agencies that you know were not always building something brand new from scratch.

And even in product teams, you may work on internal tools built many, many years ago, and you’re not always jumping from project to project or building something brand new with the latest technology giving in to the CV-driven development. But it’s also very unlikely that you’re building a new home from scratch.(...) And I want to make clear that this talk is not about dismissing legacy codebases and that you should be immediately keen to refactor what you inherit one. And I could wrap up really quickly if I just said, “Oh, just implement the design system.” That’s a new cool thing. But it’s not really about that either because we can’t ignore budget constraints of smaller organizations, especially right now in this economy.

The reality of CSS maintenance is that it often just works. And without requiring a lot of attention,(...) CSS has evolved significantly in the last couple of years, but the website built eight or nine years ago won’t be using these cool things, and it still works.

And legacy CSS can reveal undocumented project decisions.

When you inherit projects built by someone else, whether you’re in an agency or a 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 dedicated team for said design system, but the reality is very often different. And more often than not, the code that is live is your documentation.

It may have special considerations for user needs, like specific features or specific accessibility concerns that probably aren’t explicitly documented anywhere else.

And an example we quite often forget about is print style sheets. At Hacktor, we work with a lot of charities that provide support for a variety of illnesses. And so imagine a website that informs people about people with a certain illness and it provides recipes that help manage such condition. And people often will want to print those, or they may want to print helpful notes and questions to stick to a doctor’s appointment because of their own anxiety.(...) And these are things that we often forget about.

Projects with height and turnover, the moment someone leads and someone else joins, they’ll have a brand new vision that will clash with what currently exists. And very small organizations may not have the sufficient documentation systems because they’re typically overstretched, underfunded, overworked, and have zero money.

I took this photo in our loft when we removed the old carpet. The builders left some documentation behind. It says “Danger!” So it’s very helpful and reassuring and stuff. But it could be maybe pipes? I don’t know. You tell me. I didn’t find it. I just put carpet on top and I just carried on. So the code is often the only place where developers document technical constraints that they face. And it’s not unusual to find comments saying like, “Sorry” or explaining unexpected bugs, or a particular browser quirk that has been fixed and they leave a little comment behind. And we’ve all been there. We all want to hand over the best code.(...) But time constraints and life just means that we’ve all been in those situations that that’s not possible. And we came up with solutions that worked with the circumstances we had at the time.

So what motivates CSS refactoring? It’s typically a consequence of performance or accessibility sprints because these are measurable before and after results due to brand redesigns or visual identity changes that don’t necessarily require building a website from scratch sometimes. Sometimes some tools, especially CSS and JS, they get discontinued and then you’re stuck.

Or when adding new features, you may start finding problems like inherited unexpected styles. And when I think about a CSS refactor, I think about some projects that we inherited where adding new features became incredibly painful and time consuming. So I’m mostly going to be focusing on this one.

Terrifying thought if you know what that is. But if that important that you want added to your code keeps you up at night, don’t worry because someone put a fuse box underneath my staircase and I only found out when I got the keys and had given all my money away. So when I inherit a code base built by someone else, I go through a really high level audit to see what I’m dealing with.

Stalska’s case and interacting complex ways are only immediately obvious. And the visual nature of CSS means that problems are very likely context dependent.

What you perceive as a flaw might actually 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.

So more often than not, when I approach a CSS audit, I have to forget about the shiny design system that everybody talks about because if it exists, the majority of the time it hasn’t been updated since it was designed, signed off and built.

And the good news is that nowadays many code bases don’t stray too much from this structure that you’re probably used to seeing. And even for small organizations with large websites, you’ll often find a main file that imports a bunch of components, base variables, utilities and things like that.

And because it doesn’t stray too much from this pattern many times, after a while you’re just looking at things that just seem sensible and really hard to spot issues just like you’re looking, scrolling through. And when you have zero documentation or style guides, you probably have to start by figuring out how many different components exist on the website and if you have files like heroes, cards or navigation, it gives you a sense of how many components you might be dealing with.

But nowadays I can spot a few glaring issues a bit more quickly.(...) Multiple selectors fix specificity issues is one example. In this case, this code base was constantly overwriting styles set at a very high level for a heading 2.

I was recently looking at a code base with lots of support for CSS Grid which immediately gave me a timeline of when that code might have been built.

We have no good history, by the way. Sometimes you just get a zip file with the code. It happens. And you can get a sense of it, but Grid has been baseline for a long time, which means there’s a lot of cleanup to do. And if we don’t, we have to pay special attention where we’re adding new code in. And I also still find 9-11 targets too. I know, 2025.

This particular example is in SAS, by the way, but 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 gone wrong or is no longer suitable and is now constantly being reset instead of tackling the issue at source.

One time I had to find a class called “accordion_title”.

And I was confused when the search returned zero, nothing. I was like, I know what I’m looking at. I know it exists.

So what was done here using SAS is that they stored the current parent selector accordion in a variable called root.

And later on the root variable can be used when nested in a voice hard-corded class names. And now I’m pretty sure this technique is really helpful in some scenarios, but I personally prioritize readability and easier developer experience and also onboarding of junior developers than this type of optimization.

So what I learned here in this project in particular, I can’t rely on the search results being inaccurate.

So if this is a technique that makes your life easier, by all means do what works for your team, but consider leaving comments that could show the possible outputs so that people can... so that it’s at least findable via search.

And there’s other things like, you know, the other things you may pick up on is like outdated layout approaches that just can be replaced with modern CSS features. But to be honest, only if there are problems,

performance improvements is quite likely that things like font display will not apply at all, especially if it’s like quite a few years old, cold base. This allows text to appear with a fallback font whilst the font loads or fails to load.

Or accessibility concerns. For example, elements hidden visibly, they’re also accidentally removed from the accessibility tree. This is a mistake that people often make,(...) and it’s something that once you have a look at the code base, you can easily spot those issues.

Even opportunities to implement the new alt text for CSS generated content. Sarah Sweden gave a super detailed talk about accessibility in CSS at CSS Day last year, including QR codes where I kept to link to those.

Another thing you’ll notice as you scroll through your code is media queries and responsive behaviors that add layers of complexity that are not immediately visible. These are also incredible documentation because you’ll often see things like, “Oh, if you’re in a small resolution, don’t show this thing.” That’s product documentation that may not exist anywhere else in the code.

And, you know, the usual unused or duplicated styles.

So, in the UK,

when you buy or sell a house, the surveyor is normally involved, and they love this little device. This is the bane of my existence.

This is called a “moisture reader” and it’s caused me more problems in my life than CSS.

But,(...) you know, they use this little thing to audit your walls and to check if there’s damp. But beware, you know, it will shout at you even if it’s fine or if there’s a problem. But if you do have a case of water damage, it will be accurate. But it may also be everything might be just fine.

But, yeah, this brings me to automatic audit tools.

During your own CSS audits, you might think about using automated tools as part of your audit and data gathering. The topic of CSS refactoring isn’t new, and throughout the years, we have tools come and go. So, I’m going to bring some of them that are still active and maintained as of today. And you might find them quite helpful. So, Project Wallace is a free tool that runs in your browser or in your CLI.

And it does what it says in the package, really. It just tells you what it thinks about the complexity, specificity, performance of your CSS.

CSS stats is also a good one.(...) And this one was the first one that I saw, including spacing resets, check, which, as I mentioned before, it’s something I personally look at.

And having a big number gives me an overview of how much of a big issue it is. Since I’ve done this talk, Project Wallace also implemented the spacing resets. So, that’s my only contribution to the CSS world as of today.

In Chrome DevTools, there’s a simpler overview of your CSS. I’ve had some shaky experiments with this still. But I like it that since it is integrated in the browser, with one click, I can check which elements are using the things mentioned. And it includes things like colors, fonts, unused declarations, and mid-queries.(...) Also in Chrome, you can have a quick look at the coverage tool that returns an overview of unused JavaScript and CSS.

But it looks like you can go a bit further. You could use something like Puppeteer to bulk-find and go through pages and find all these things. When I try this out on my blog, it tells me that 64%

of my CSS isn’t used on my own page, which is true.

The code above relates to my guest book, which, yes, is not available on my homepage. But my website is now an emergency service, so you’ll have to wait until I have time, which is never.

In Firefox, I like this view in the style editor where all the app rules are found in the CSS loaded. And by looking at my own website, I immediately spot a tool that I could use some review and update. Again, who knows, never. But when I use the same tool on a real website, my website is real, my blog is real, but you know what I mean. It’s a client website. This tells me a more complex story. This may be necessary complexity or a sign that the designs were strict and fluid layouts were not applied here. It goes on for a long time. You can see it says, “Yeah, I have to sort that”.

And this made necessary complexity, yeah, and that designs were quite strict.

Different brains process information differently. The same website by using different tools. Chrome compiles the repeated mid-equeries together, while Project Wireless gives you options to sort it by source order, sort by count, or sort alphabetically. Same information, different brains. We all process this information completely differently.

So when you run a CSS automated audit, the high numbers in reports can seem quite alarming, but actually, they just might be completely appropriate for your project. If an audit tool flags that you have 100 different colors in your CSS without understanding the context of it, or the purpose of them, it’s not really useful information because you might be dealing with a website that has to catalog products with lots of colors, and you have to just present all those colors in your code.(...) And it also may bring up colors using SVGs, which again is unlikely necessary for you to know about.

And these raw statistics don’t capture the nuance of intentional design decisions. Even assuming that specificity data is useful, the tools cannot distinguish between necessary complexity and technical debt. For example, because you might need complexity to override these cursed, horrible third-party libraries that we have no control over, like cookie banners or chatbots. So, after you feel like you’ve got a sense of the code base you’re dealing with, and you have a high-level node, so like technical bits that need attention, let’s consider practical next steps.

Document low-hanging technical debt in tickets, label the quick wins for momentum, and ask questions. You can ask questions about browser support, road map, known problems, and document them.

Every day someone shares something cool with CSS, something cool done with CSS features that are very recent,

and if something got you really excited and you would be perfect for an existing or future project, just make it visible to everyone in your team.(...) Spin your own baseline status and add things that you cannot wait for them to be baselined so that you can use them. And make this part of your toolkit. Google recently announced a handy tool called Baseline Checker, which should help you be even more specific to your project as it allows you to upload the analytics. So, based on the analytics of your website, you may be able to tailor which baseline you should be targeting at, and it keeps you a bit safe not to go too experimental with it. One of my baseline wish lists is text box trim, but it’s not on Firefox yet, but it’s one that is actually safe to use.

So, once I realized that the quote to do up all the rooms was a bit more than I could afford, I had to scale back. And I decided not to work on kitchen and bathrooms, and they were clean and functional, you could wait, and my contractor told me something quite interesting.

You should wait anyways, live in it and find the pain points, and you’ll know what you want, what isn’t working, and what works for you. So, low-hanging fruits and glaring issues are really great motivators to start conversations and to feel motivated to touch with CSS and work on it, but like we know, CSS just works, and it will take some time to actually fully grasp how much impact this legacy codebase is having in your developer experience until you actually work on it. It will take a while, which is great if you are not brought in on purpose to work on that, but, or if you don’t have to work within a timeframe. And we have to do a bit of a therapy session here. You have to ask yourself a few questions and document them.(...) What’s causing me to take longer to make a change or add a new feature? What normally comes back as a bug after we work in this codebase? What do I dread to touch?(...) Could anyone arrive to this project and make this change?

Is it a real problem or is it just not done to my taste?

So, I thought I’d share some real-life examples of pain points I’ve recently experienced. This is example number one. 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 well as to all the paragraphs. This means that lots has to be resett every time a new feature, especially if only one paragraph of text is added.

Another example could be a new spacing guideline. The new spacing guidelines are very different from the existing ones in the codebase. Sometimes people want to keep both.(...) Whenever we add a new feature, it inherits the existing spacing and we have to override it to match the new designs.

Another example could be the same template is being reused from multiple differently styled cars, so we have to go in deep in specificity. It takes time to make sure we’re changing the correct thing.

And the last example is that there’s just a lot of unnecessary code. Nearly all the code is written inside some supports, which are now baseline. Whenever we make a change to that code, we need to pay extra attention to where we’re adding it.

And we need to discuss how to talk to product people because they want to know why they should give you the time and money to make these changes. And it can’t just be for your own vanity. Now, I’m going to use product owner or product people, but this means whoever calls a shot on what’s being worked on next and whatever their role name is called.

And I love this quote from Jerry Reed. This was on a talk about design systems, but, you know, which says, “Actual design systems return on investment is scalability, collaboration, speed, cohesive brand. You can’t guess how much money your design system saved you, but product people like that, though.” 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 documentable for a natural developer experience.

So it’s not just metrics like reduced file size or faster loading times because those improvements are great. But if your website is primarily visited by people in a fast desktop connection, it’s not going to make a significant business impact anyways.

You need to highlight specific pain points that generally need addressing.

And when you enhance the code base for your own developer experience, the value takes a lot of time to materialize, and it’s rarely immediate because subsequent tasks could have been just easy tasks or quick tasks regardless if the code has been changed or not.

You might create documentation primarily for yourself, making a significant time invested that is not going to yield the results, especially in charities and organizations that are very tight in budget. They can’t justify giving you the money so that you have a nicer time working.

I love this blog post.

It’s such a big description of what it’s like to work these days. 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, which is also how I deal with my blog.

So can you convince the product owner to refactor a dormant website? Probably not.

Because 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 what they also want to know is how does this mitigate risk? And risk can sound like if we don’t do this, this very annoying thing can happen and it will delay many other things. Now, rare occurrence with CSS, but if you have specific development pain points, this is the time to explain them.

So let’s imagine a time in the future where carousels with CSS are baseline and fully accessible.

And then you’ve got a website that like every once in a while gets new features out and it has a maintenance budget. And that website actually has some carousels all over it. The content editors can add one to every page if they want to via the CMS. But that 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 more. But it’s not your personal website. You can’t do that.(...) And we all got bills to pay. If you work in an agency, they do not want you to work for free. If you work in a product team, trust me, your product owner has a lot of other things in the backlog that is on their priority list. So how could this conversation go?

Let’s try.

Hey, so you know about these, you know how we use these carousels on the website? I think we should replace it with CSS carousels. Here’s an example.

And they reply with what’s wrong with the current implementation.

It works. It is true. It works. But, you know, it’s using a third party library and it’s always good to delete some code and remove reliance on JavaScript.(...) Again, this would work on me. I’ll immediately say yes.

But that’s not what’s going to happen.

Is a third party library still being supported?

Maybe. I mean, I just checked the repo. It hasn’t been updated in a while, but I guess there isn’t a reason to.(...) Well, then I’m not sure if that’s where we should be focusing now since it works. This is a realistic example because this is the opportunity to mitigate the risk of a third party fallout. Content dependence, of course, but what happens is a third party stops being maintained. What if it’s bought? What if it suddenly changes its pricing plan? And what if it starts injecting unwanted code?

That’s not going to cut it.(...) It doesn’t work like that.

Let’s try again. They might entertain the idea. They might ask a few more things.

And these are questions that you have to be prepared to answer regardless of the case you want to make with product.

Are we limited with how it looks like? Is UX improved? Does it feel more native? Does it unlock new features? Can we reproduce the exact same design?

So let’s try again.

So I learned about this web feature and now that it’s safe to implement, I think we should use it a lot.

But theiac Gimmea is theher connectivity up and down asset signs for certain products and can be done in the third party. So at the level of owned development or where it’s said, they love a number.

This will be help mitigating the risk of accessibility standards increasing.

And we can try again. You may work somewhere that allows you to have some time on personal development or projects that are work-related. So since we’ve got some hours per sprint for personal development, and I learned about this web feature now that it is 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.

If your employer is paying for your ticket for you to be here today, going back and having time to implement the things you learn is part of the job.

But let’s address other pain points this time.

Hello, hi, we have got a lot of CSS inside supports to cater for IE11 users.(...) This makes changes really time consuming and prone to errors. Is IE11 still a browser with support?

Hi, yes. So I have 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, I hate this. We need a time estimate.

Right.

Good question. Let me think about it and get back to you. And this is happening in a lot of features, and we also need to test them all.(...) See, we love a really big refactor.(...) And we feel really special when we see all these big numbers on the files change tab on GitHub. The world doesn’t spin around as front-end developers, and big changes also imply big testing.

And this may also be a project that only gets a few allocated hours per month. So they will say, let me know when you have a time estimate. But it might be a while until we have time in the sprint to book that amount of work.

But the initiative might also come from product itself, because changes that need a big general regression testing impact everyone. So we can increase our chances of getting our request approved to be done if it aligns with planned feature development. Or who knows, holidays, period, slow business. In this case, they suggest themselves. 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.

Product people prefer refactors to rebuilds, and you can speed your approval by preparing your arguments. Is there metrics to track CSS-related bugs reaching UAT?(...) Have you documented development roadblocks and slowness due to the needle refactor? Can you demonstrate how the current CSS impacts 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 benefit from this refactor? Are you able to share how the lack of a refactor impacts your time estimates? Because would it improve predictability, which allows product people to plan with more confidence?

And don’t procrastinate. This is a lovely book, How to Make a Sense of Any Mess by Abby Covert.(...) Don’t procrastinate. Messes only grow with time. You can easily make excuses and hold off doing something until the conditions are right or things seem stable. Perfection is impossible, but progress is. And it can be intimidating to approach the product team. As someone who has experienced working with an enormous company with hundreds of developers that only some voices are heard, it can be a frustrating experience too. And don’t be discouraged to document your opinions and your knowledge and share them. And instead of a product owner, those people might actually be your teammates, a team leader, or an engineering manager.

So you’ve waited. You’ve figured out where the pain points and a priority from a developer perspective are. And you got the green light from a product owner to carry on and do the work.(...) And here are some bits I’ve kept in mind recently.

Harry Roberts wrote and gave some talks about CSF refactors nearly 10 years ago. And they still hold on to their truth and their practicality. Harry calls them the refactoring tunnels. And the idea is to refactor by component or feature in isolation and keep a temporary CSS 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. The temporary file can be called what it seems sensible to you. And this is the most helpful and hopeful route to tackle a big CSS refactor in one go.

But let’s think about improvements that can be done on any component level.

I’m the first to admit that I still get caught up on naming things and then regretting it. That’s the pain of my existence as a front-end developer.(...) My brain gets on autopilot. And I sometimes take the designs literally. And it wouldn’t be unusual for my daily work to build a typical card blog.(...) And from the designs, you can see that there’s a card with styles of the latest articles or another card for team members, a card for a person, a card for events.(...) And they’ll have some shared styles. So you may go with the approach of breaking them into two or three or more and call one to card events, card person, and carry on. And then you deliver the website with some content. And you have an example. There’s the team, a card, a person, Anna. And it’s glorious and beautiful. And the website is live. And then the content editors get access to it.

And then it’s no longer a card person.(...) The person card is no longer a person card. And it turns out it fit other needs they never specified. That they probably didn’t even know at the time they needed it. And suddenly, card person doesn’t make a lot of sense there.

So think about how a feature will evolve. It’s exactly what Josh Toomet said in his talk, how do we keep going roundabouts and APIs? This was at State of the Browser, which we’ve been seeing slides about. You should definitely go just biased. I don’t know. Regardless of the reason why a refactor is being done, take this opportunity to make your life easier in the future.

I really like this example from that Josh shared, Booleans can restrict you once you need to go beyond the true or false.(...) So we might fall into the thing of dark mode, true or false. But actually, if we think moving on to themes and moving on from restricting ourselves and allows this feature to grow more gracefully.

And once we figure out to name things, we can go one step forward and move on from the idea of using class property as the only way to represent the state of an object. And this can also depend on the project you’re working on. But I’ve been leaning on to data attributes recently to make a difference of what I’m working with.

Or this is a better example, the progress bar. Styling based on the value of the data attribute makes your life easier when updating the status of something via JavaScript and removes the need to add and remove CSS classes. And Keith Circle wrote a fantastic blog post about it. They go into depth on why they think this approach is reasonable.

And if we go back to the cards example, this article also includes the following example which I quite like. And I quote, “attribute selectors like attribute to a 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 style to one or more border size.” So it’s not really restrictive in that sense, which is a really, really great feature.

And you can see this idea applied in the design system. I love that. It’s like the design system. Which is an Norwegian collaboration between agencies to create a common term digital toolbox, as they call it, the design system. And it’s a great--

I’ve had a look at this, and they use data attributes a lot. And you can see practical examples of many components using this.

And it’s time to embrace CSS logical properties, because translations are here to stay. We are getting these more and more in the browser. If we move on from being explicit on right, bottom, left, and tops, and just using the logical properties, it makes our life easier to adapt to other feature work.(...) And there’s more. We can start thinking about replacing media queries with container queries, or removing them completely with CSS functions, like font clamp and more.

If you got a small task in a component, regardless if it is CSS related or not, take that opportunity to give specificity issues some love.(...) Nested classes give us this very neat visual hierarchy in our code editor. But it’s quite satisfying to our brains. But they’re not actually that useful. And they’re probably not needed either, especially if those elements have their own class name.(...) If a feature is being fully tested by default, regardless of what change is made, even if it’s in JavaScript, it should be tested by default.

Increase the time estimate a little bit to include CSS maintenance. And like I said, this is the perfect opportunity when you do that maintenance to apply these modern CSS changes, like moving on from pixels to RAMs, where font sizes are being used, make it more accessible, and do maintenance every time you work on it. Because testing will be included. You get it for free.

In regards to automated testing, especially Visual One, we’ve moved on beyond the arrow of pixel perfect design to fluid adapted designs that respond to the user’s needs, to their devices, and accessibility preferences. And this can be a challenge for some traditional automated visual regression testing. And even with thresholds, it may not be the best use of resources and budget

unless you have a very specific product that needs it. Just you have to go with your gut and what you’re actually working with. And then the visual component testing is going to be my experience the best.

Whatever you do, you have to accept and be comfortable that for a while, it will be a mess that you have to live with.(...) But it will get better. We still call this the manky wall, despite looking pretty neat now. For I would be called the manky wall.

So imagine a faulty boiler, a faulty tap, grimy covered handles, and a drafty window that being components of your website that eventually got some love and has been touched and fixed.(...) And sure, around the edges, some extra love is needed. But the pain points were fixed.(...) It’s all about progress, not perfection.

And writing tidy and non-chaotic CSS is a skill. And it’s a skill that I have to work on every day. And I work on the skill. And you can work on the skill by going back and mending, not by just building brand new from scratch.

And a lot of people think that using a framework removes the need to work on the skill. But you’re only adding risk rather than mitigating. And to be honest, you have already enough risk by trying to run an NPM install after six months.

CSS simply works. Just use it. Thank you.

(Applause)