Real World CSS: Always Interesting, Occasionally Hilarious

Okay, hi, I'm Brian Cardell, I'm a developer advocate at Egalia.

And I'm Eric Meyer, also a developer advocate at Egalia.

Welcome to Egalia Chats, where we have guests today.

Bart Venemann, please introduce yourself and what listeners know.

What is your up to?

I am Bart, I'm a developer from the Netherlands,

and I focus mostly on analyzing CSS.

I have a website called Project Wallace.

That's where most people probably know me from.

I do a lot of CSS analysis in various ways,

looking mostly static analysis,

looking at CSS from different angles.

Yeah, and that's been my game for at least the last 14, 15 years.

As a SOC project, because I have a full-time job.

But as a hobby, that's what I've been doing.

I mean, CSS is a hobby.

It can be a lot of fun.

Even CSS analysis.

Okay, before we get started, I just have a question.

Why did you call it Project Wallace?

Yeah, that's a tricky one.

Because I felt I had to come up with a name in a very beginning

and people were calling their site projects project, whatever.

I think Project X was a thing at the time back then.

And I really liked the Artman studios thing with Wallace and Grommet

and the Clay animation stuff.

Yeah, that's also the vibe I'm going for,

with funky, funny sort of feedback on your CSS.

That really hasn't worked out, but the name stuck.

Yeah, I wondered if it was a reference.

I love it.

And so when you say CSS analysis,

what level of CSS analysis are we talking?

The thing I'm mostly looking for is the stuff

that not a lot of folks are looking at.

We tend to do analysis on a profile basis using style in

or maybe some other tools.

But what I want to know is a holistic view of my CSS

as we ship it to our users.

What is the CSS that our users download?

And what is in there?

One file may contain, I don't know, seven unique colors.

And it's the best CSS that exists for that specific component.

And then when everything gets bundled and shipped to our users

and then I know third party plugins are also shipped to our users.

And they use slightly different colors because we didn't apply

to rebranding their font sizes are off.

Like this holistic view is what interests me most.

So from your latest sort of state of real world CSS user

article, you were looking at 100,000 websites.

Is that generally the scale at which project wallets operates?

Or does it also operate it like much smaller scales?

Oh yeah, good question.

Yeah, it never does that.

It always operates at a single website or usually mostly

a single page level.

Like you go to project wallets.com, you enter one URL

and that's what it tries to scrape and do analysis on.

Okay.

So the yeah, so this is a selection was was a different beast.

I'm also a big fan of looking at the data of the web and the health of the web

and what authors are doing with the web.

And I think it was maybe 2018 or 2019 was the first year

that they did the web almanac.

And that year I edited the markup chapter.

And I think there hadn't been a markup analysis in I can't remember

but like maybe 20 years at that point, something like that.

And it's amazing because you know, we're here writing standards

and we're talking about what people do and what people want.

And we don't have anything looking back at that to say,

how is it successful?

How is it not successful?

And so we've been involved with that for until it sort of changed

in I think 2023 or 2024.

But Eric wrote the CSS chapter in 2021.

It hasn't we haven't had one in a while because the sort of methodology

and people involved and everything changed.

But there are like interesting like how do you choose which 100,000 sites

or million sites or billion sites, you know, or 3.8 billion sites

or whatever it currently is in the archive.

Like it's a really, really large number.

And then what do you do with that data?

Is full of interesting questions.

I've learned anyway.

So yeah, I'm curious to start with like how did you choose the 100,000 URLs?

Are they from the archive data set?

Are they Alexa top URLs?

It is the first 100,000 websites

from the majestic million list.

And I came upon that list because

Erfith Ring from Project Wallach used to be based on the CSS tree library,

which is an insanely good standards-based spec compliant CSS parser.

It's been maintained by one dude for a long time.

And it's an amazing library.

And he used to...

I saw him...

He has a script somewhere where he uses this majestic million list

to download a lot of websites and then test if his parser actually works.

So I figured, well, that must be a pretty representative list

then to use for whatever I'm going to do.

Because when I started, I didn't...

I had sort of an idea of what I wanted to do.

Yeah, first I needed a lot of data.

And what did you find?

Well, like, what was the thing that really stood out for you that you found?

One of the biggest things for me is

that looking at adoption of modern-ish CSS

made me feel both really old.

Because I also included information about baseline status

for several of the features listed in there,

like layer being available, baseline available for how many years.

This stuff all still feels new to me

and seeing container queries used in almost 10% of websites.

Wow, that was something...

Yeah.

...adoption rates are insane.

Most of them I did not expect.

Yeah, because of the data set and everything,

it has some, I think, some of the sort of similar,

sort of like biases in the data set

that you're talking specifically about, like, public pages, right?

So not something that you could log into,

which is, you know, a lot of what we use is what you log into.

And what you're analyzing is it also, like, the home page?

It's the home page and the home page only.

Yeah.

So I say this all the time,

like, we have modified the HP Archive to do, like,

it tries to look for, I believe the way it works,

is like, the largest link in the page

in terms of, like, what it would render visually.

And it sort of clicks that and follows one link

to find another page to measure.

So it's not just the home page, you know,

because I say all the time that, like,

maybe Apple's home page is not anything like

the rest of Apple, you know what I mean?

Or like, Google.com,

is it really representative of Google?

I don't know.

You know, it's Google.com is definitely not one input box, you know what I mean?

Like, I think it's really, really useful,

but you have to also, like, take it with a particular grain of salt, right?

One of the things that I also noticed is that, like,

you say adoption rates are very high.

What I've found is that when adoption rates go up really,

really quickly, it's very frequently common cause

and not, like, everybody rushing to adopt it individually

because, you know, those millions of sites,

they're, most of them are probably mostly chucking along.

They're not being, like, constantly rewritten all the time, right?

So they get an upgrade to a WordPress theme or something like that.

WordPress theme is like, yeah, container queries.

That's going to make my life so much easier and they, you know, they replace it.

So you get, like, all of a sudden, you know, eight percent of people,

it just spikes, like it jumps up when you look at the data.

And so that stuff is also really interesting to me.

I'm wondering, like, do you have any plans or have you thought about tracking it over time somehow?

Years ago, project walls.com used to be a website where you could log in

and then analyze one or more URLs over time.

And that was really intensely useful because I had all sorts of graphs

with how file size changed and how many colors were changing and that sort of stuff.

And that is something I want to do for the CSS selection that I wrote.

I want to be able to do comparisons year over year because that's when it starts to become really useful.

If the fundamental metrics are still the same because otherwise it's just comparing apples to oranges.

So that's not going to make sense.

So my first goal was to get this one out the door and have something out there.

Just struggle for this year is going to be how will I compare newer data to the older data.

One of the things that jumps out that everybody likes about these reports,

I mean, it's not just like when you write them, when I write them, when anybody writes them,

is like, you know, the two newslines that you usually find

or that there was like one 90 percent of websites fall into this category.

What's that number?

Like that's a super useful number.

And then there's also like what's the most extreme outlier, right?

So you have like a bunch of really extreme outliers in here.

And I'm wondering like, do you go look at them?

Like do you actually go boy, that can't be right.

You know, like let me go look at what are they doing, you know?

Oh, oh yeah.

So there was one example where I was going through, I think the top 10 websites in terms of CSS

shipped to the user.

Because of my initial analysis, there was, there was a small book and I reported something incorrectly

and I placed a correction in the report afterwards.

So I did my due diligence and checked, did some, some probing for like the top 10 to see what was happening.

And there was this insane website for a bank somewhere in Africa that shipped 50 megabytes plus of CSS.

And they were an eco bank.

The eco wasn't their brand name.

I almost, I almost fell off my chair, laughing, but also like, oh man, you can't make this up.

I regularly look at the markup data.

I have a thing that tracks the markup data monthly through like in collaboration with the HP archive.

And as I track it, I even when we wrote the reports, I noticed like a bunch of things that you could identify

that were outliers, you know, like, man, this is way, way too big.

Or another thing that I look for, I don't know if you look for, you would find this interesting.

Maybe is like things that are parsing errors that are, you know, probable typos.

It's shocking in the markup landscape, how many typos there are.

Like, I mean, it's just because, you know, if you miss type something, it winds up as a span and chances are it's going to be styled just fine, whatever, you know.

So, yeah, it's really interesting.

What the typos are and encoding problems and things like that.

Do you do any kind of analysis like that?

And I've wondered, do you think that people might find it useful like as a service where you could sign up for this?

And, you know, maybe once a month or on demand, we go check your site and then, you know, you sign up with a Webmaster.

Remember Webmasters?

You sign up with the ad man of your website Webmaster.

And we send you an email and we go, hey, but you have like done some really not great things.

Maybe you want to go check that out.

I think that would be a really useful service.

What do you think?

This was the, I just mentioned the project wall has had this, this where you think where you could log in and track your site over time.

The goal back then was to like indeed have thresholds for like number of importance or whatever.

But the thing you just said really triggered me because we tend to look at our CSS like on a component level on and when you look at it holistically and everything is out there.

And there's a special section in the CSS selection that I wrote specifically for all the typos that we have for the use of importance.

And it was so funny like there's so many wrong ones in there, like in proteins and important.

And you don't, you don't see that all the time unless you look at your CSS like coming into the browser of a user and then looking at it.

I think having some sort of service that looks at your CSS and that's able to highlight these sort of things.

If I had all the time in the world, I would probably do that.

Yeah, if I had all the time in the world and a nice startup budget, I think I would build a service that did this for your, you know, your HTML, your JavaScript.

You know, did checks on what, what's your loading performance? What's your, in fact, web hosting companies should just offer this web hosting companies, somebody sponsor, start giving a big endowment to make it happen.

Yeah, there are several companies out there like like all these these PHP tracking services and there's companies like sonar cube and stuff who keep track on whatever you're doing.

And but most of them don't seem to really pay a lot of attention to the CSS, which I think is a missed opportunity.

I think Project Wallace's packages here could really, really help you out finding weird stuff.

Yeah, I'm going to, I'm going to coast sign on someone should give you basically the web, whatever the web's version of a MacArthur genius grant is to pursue this for a year or two or three or whatever.

Making the thing.

So, one of the things that I thought was interesting in here is like, you know, one of the things that I would think would be sort of a preference such a service would allow you to set as a webmaster.

Do you care about this sort of thing is like, are you shipping comments in your CSS?

You know, you might think, well, who cares, but am I reading your table right in here saying that like 90% of sites are shipping like 11.4 K of comments.

Yeah, apparently that's that's what happens.

That I mean, that's kind of a lot of comments that you don't need to be sending.

Absolutely, but I don't know because there is also a part of me that thinks, you know, coming from Eric and I or you're at least we learned the web from each other, you know, like view sources, a super powerful tool.

Yeah.

So comments in that respect are actually kind of nice.

But they're not necessary and that you have one example that as you say in the thing, there's always an outline one website managed to send eight megabytes of comments to their users.

Like every webmaster should want to know that, right? Like I mean, if your CSS file is eight megabytes shouldn't you get like, I don't know.

But I think every cloud hosting company should should like you have made in a probably egregious error like you probably didn't want to do this like you can click here to not tell you again, but otherwise we're going to pester you and say this is really probably not what you wanted to do.

Yeah, please show your webmaster license and we're going to refocus for at least three months until you've learned CSS police on the way.

Yeah, exactly. Well, and and that's I've been struggling with should I include all these outliers in the CSS selection, because it's I don't want to be judgmental and I've I've had several people ask me like, who has this be a very big website in who ships, whatever comments, whatever.

I don't really care. That's that's not what this is about. I just like the thing was also meant to be a bit of a light harder way to look at the state of things, things I could probably not do in the web almanac, but I can do because this is my own website and put a twist on it.

Yeah, I noticed very quickly you had a very informal tone in writing the report. I mean, you have these percentile charts, which are just very hard data, but then not just in these sort of aside comments, but also in the main text, it just it reads like just talk into a person rather than this is our formal report that must be written in corporate neutral.

And I appreciated that quite a bit. That's how I try to do my stuff when when possible, but yeah, every time I hit one of those outlier boxes, I always mapped it to the spiders meme like the average number of spiders.

So, you know, the spider spiders George was an outlier and should not have been included. So I would like hit this one website managed to send me make a bites of comments to the users was like comments George was an outlier and should not have been included in the data set.

But I think that those are fine. I also very much support your decision not to name and shame, just, you know, there here is like the biggest number that we got in this category.

Somebody had over 150,000 at rules on a single page, which almost seems impossible. And yet it's in there. And nobody needs to let's all go and laugh at a specific site or person like that's just that's not

useful. But it's doesn't tell us anything in particular about the state of the web that somebody had eight megabytes of comments. No, you know, there's always going to be these outliers. Either somebody just had a lot of comments or somebody forgot to close a comment. And so shipped an entire style sheet that was just a comment.

Like who knows, but just by saying somebody had eight megabytes of comments that sort of makes people stop and think, how do you even get there, which reports like this, I think, should always to some extent prompt to the reader to think through

like, how did that happen? How did we get to that point? And ideally they do it for multiple things, right, they look at it, maybe one of these percentile charts and say, how do we even get into that state as a whole industry?

And how could I maybe avoid being the outline of one of these reports?

Yeah, I think that's the distinction that I was looking for there too, because I also don't think it's a great idea to kind of like publicly name and shame people because a lot of times these are, you know, mistakes and everybody makes mistakes, you know, I think for me, when I look at some of these, you know, I work on a bunch of websites. And when I see some mistake on there in not now, but, you know, in my past, my first reaction was oh god, I hope it's not me, right?

Like, you know, mistakes happen, you know, like some of these are really some silly, you know, some silly thing that made it out into production.

And maybe it's like concatenating more style sheets into one thing than it needs to.

Or all kinds of things. So, so I always thought, you know, like, if we're able to monitor these things, that's why I say like it would be really interesting to let people know, you know, as a service that those things are happening because I think everybody wants to do the right thing, you know, I mean, it's the same with accessibility, right?

Like, nobody sets out to make their website inaccessible, like, but sometimes it's difficult.

And if we find ways to make it easy by offering service or something like that, I think that could be really helpful.

Yeah, everyone has different constraints, being time simply bandwidth or hardware or whatever, there's always pretty much always a reason why these sort of things happen.

There's a note somewhere in the CSS selection for a media query being nested 37 levels.

I tried to track that one down and it was just somewhat press plugin where someone had entered could enter custom CSS and they forgot to close the media query.

Yeah.

That's where you get mayhem.

So, one of the things that I really like in CSS is specificity.

So, I think it's cool that CSS is a rules engine because like we don't have that many rules engines that are just like available to programmers, you know, like most of the things that we do are just a lot more sort of imperative and less like here's bunch of rules.

And, you know, here we have for styling and it's really cool, but the way we do it is specificity.

And I think like a lot of people don't really even totally understand it.

And we also now have like lots of tools that let us like nest things and put things together.

And I've seen at companies I worked for in the past, like some pretty complex selectors.

You have one in here that says like there is one website shipping selector is up to I don't even know what is this number.

I mean, it's huge.

Like it's the class is way off the charts.

Like the browser can't even deal with that.

Like it maxes out.

Right.

Yeah, it's the way I would read it is 146 1546 159.

This is actually why originally it was proposed to use dashes to separate the specificity levels rather than commas.

But commas caught on.

I guess because the comma key is closer to the space bar.

Not sure.

Yeah, because otherwise you see people saying things like in the notice, those Brahms Vandam taught us that specificity goes up to 255 255 255.

But it looks like it's 255,255,255 because of the commas separation.

That's a very good point actually.

But 146 1546 1559.

That means 1546 class level selector parts.

So either class names or attribute selectors or elements or more likely a massive combination of them.

That's just amazing.

I like this one up and it is ridiculous.

I wanted to share it, but it's hard to redact because there was a lot of brand specific class names in there because I really wanted to share it.

That's what I was just saying is like put it up as a guest.

And just point to it and be like, here is the selector.

Here's how we got there.

But it was also really easy to spot that there was some CSS pre-processing going on there.

I think a lot of the anti-patterns that we see in the CSS selection order, the outliers that we see are CSS pre-processing anti-patterns like using what was it says extends using that a lot.

And that's how you end up with over a thousand selectors to do margin pixels margin left and pixels.

That's amazing.

That is one from all the websites that I've analyzed in the last couple of years.

Like the ones I've seen with my own eyes just doing one at a time, not the 100,000 at the same time.

That's one of the most common problems.

Harry Roberts wrote about it and says extend is a bad idea like years ago.

But this also shows that not a lot of websites are updated very frequently as she said Brian because this happens on so many websites and so many levels.

I'm curious going back to this theme of like mistakes happen and could we let people know, did you reach out to them? Did you make an effort to reach out to whoever it was and let them know that they had this problem?

Because when we were doing the markup chapter initially, I kept sending back to Rick Viscomi who was providing the data to me and saying that no, the data still is not can't be right.

Like it can't just okay, I need URLs like I need actual URLs to see where this these are being tracked because here you have like 10,000 websites having the same exact 72 character typo.

You know, I mean like it can't be and then when I look at them, there was all as a service for card dealerships and it just so happened that I knew somebody who worked at that company.

I knew somebody who knew somebody who worked at that company and so I was able to reach out to them and they fixed it like, you know, so fast like that day they fixed it, you know, for 10,000 websites.

And like I say, you know, people don't want to make mistakes and I don't know that shaming them is the best way to keep them from making mistakes, but letting them know is for sure useful.

It's a very compelling idea and I've thought about this because one of the outliers I found was a Dutch website and I'm Dutch myself.

So that sort of felt like, well, I could go down that route and try to try to help them out.

But then it's never as easy as one single email and you have to go through several support channels probably.

And I was putting the article live so I didn't really feel like like doing that.

And because it's my, it's still it's a pretty big side project, but it is a side project.

So yeah, I really wanted my energy to go elsewhere.

Yeah, no, no fault in that.

It would be so nice to have a standardized way to communicate those kinds of things, you know, to be able to say, okay, for this website.

Here's here's where you send in your report of your markup is bought or your JavaScript is failing.

Yeah, and CSS is really a problem for us in that way that it is so forgiving.

Like you make a spelling mistake or syntax error and the engine just ignores it and tries to move on to the next part that works.

So much easier to let CSS mistakes slip by, whereas JavaScript will yell at you for a thousand reasons.

And your e-commerce website is broken.

No one complains where your CSS is broken unless the whole website is in style, which rarely happens, which it does, but not always.

Or if you can't click the buy button for some reason, which is usually JavaScript, but not always.

Sometimes it is the CSS.

Can I, can I lobby you for some future data, maybe?

I would be interested in one of the, you know, pet projects of mine that's gone off her decade plus is markup.

And I'm very curious what custom elements people are using.

You know, looking through where people are styling tags that contain a dash would be an interesting data point for me.

Oh, that's a very good one because right after the CSS selection went out, I added extra analysis to the CSS analyzer to look at a host in what was it slotted.

So there are two elements to include those for next year, but that's an interesting point.

Yeah, definitely go and do that.

And then there is a list of sort of like, I mean, there are several lists.

So I have like a super list of anything that anybody could reasonably have considered a standard tag at one time.

There isn't complete agreement on that like no, there's no spec that says these are the standard tags and they they have changed over time.

So anyway, there's, you know, something like 140, 150 elements, but, you know, when we check in the H the archive, we have to stop checking after like 10,000 because there are just so many.

And let like lots and lots and lots of them are non recognized, but dash right elements.

Right.

And I mean, I can share actually my article on that and maybe just read it and see if it sparks anything in you for other interesting.

Oh, yeah, please do.

Yeah, look at that data.

And I feel like some of the CSS is uniquely vulnerable to runaway outliers because of the heavy use of preprocessors.

So sort of just not think about how far you've down you've nested something.

And then the preprocessor expands it out into this massive thing. I mean, we have native nested CSS.

It's not necessarily sort of universal, but it's supported in I think all the browsers.

And so we might start seeing this more natively.

But I just I wonder sometimes if the heavy reliance on preprocessors has inflated the CSS that we shipped to users more than would have been in case otherwise.

Yeah, I think that's the case for many of the the anti patterns that I that I spot preprocessors seem to be are the incorrect use of a preprocessor seems to be the cause.

Whether it's extends it's sometimes it's use of mixing the same like the same block of declarations and maybe selectors is coming back every time.

I hope that I can include the use of CSS mixings and functions like native functions into the report for next year.

But I think it's still being specced. I think maybe prototype, but that's sure.

I'll follow up to some of the observations that we talked about about like the biases and how things are constructed.

And also this thing about markup and custom elements. And I wonder like I wonder if analyzing CSS from the home page is actually probably more valuable in a way than analyzing the actual markup on the home page.

Because frequently we'll send CSS for things way deeper in the site like even things that you have to be logged in for, you know what I mean.

So we could know more about the kind of markup that you're using deeper in the site by looking at the CSS probably than just looking at the markup for the home page.

Is this like is your data public like is this an open source project like is there a way for me to plug into this data or.

So the analyzer that analyzes the CSS public scraper the script that downloads the CSS from a given URL that once public it's listed in the article.

But the actual data isn't isn't public because because I messed up and it's quite a lot.

So pretty early in the process of scraping 100,000 sites, I noticed that my hard drive was filling up quite quickly.

So I started ignoring some parts of data that I deeply, deeply regret now because I don't have analysis on what colors are used most most often.

And what is the most useful size and stuff like that.

So that's a very very big mistake on my end.

So the data itself is a public I've tried to link up the source data to all the to all the graphs were wherever useful.

So the scrapers public the analyzer's public so you could probably reproduce the report.

I'm very sure we can get this added as a custom metric to the HP archive.

I know some of the people there Barry can probably help get it as a fun fact this morning I started discussions with Barry Pollard.

Because I wanted to know and I've seen that the HP archive uses rework CSS to parse the CSS.

And one of my goals because I listed I was listed as the author for the web almanac chapter for last year 2025.

It didn't go through because I thought we didn't have enough data analyzed to write a proper chapter.

But so I got in contact with Barry and he gave me some really helpful pointers as to how the HP archive analyzes CSS.

So last night I set out to figure out what parts for us being used to to analyze the CSS and it's rework CSS with some changes in it.

So I'm still trying to figure out what exactly.

But from what I can tell it does not handle the more modern CSS stuff like that layer and container queries really well.

So I've raised the question of how useful is the data in the in the HP archive for this moment if we miss out on a lot of the lot of the details.

Yeah, and that's a it's like an evolving thing.

So before 2018, if you wanted like the HP archive just stored strings like it just stored the sort of like the horror archive string of what was downloaded.

And if you wanted to know what elements were used, you would do a reg X search on strings, which is like expensive and as you know, not really how parsers work at all.

So like you would get results of that kind of vaguely look like that, but they're not actually elements or they're not actually rules because they're commented out or whatever, right.

I think in 2018, I helped add a custom metric that plugs into the actual browser's parser. So it actually uses the parsed result to collect that data.

And then in 2021, I think what year did Leah do it? Do you remember Leah and Rachel did it?

Yeah, that year she added she added those proper parser and custom metrics.

You know, there's definitely room for if there's a better parser that we should use totally can do it if we need to add new custom metrics totally can do it.

So yeah, I'd encourage you to keep talking to Barry.

Yeah, I still want to do I still want to help out with writing the web almanac CSS chapter because this whole this whole thing for project wall is to write a CSS selection article started out with me.

I want this to exist.

I really want and that started out with me volunteering for the web almanac because I want this data to be available.

I want this to exist in the world and it's been so long since we had a last edition. So that's where started off and I'm still trying to now start discussions for how are we going to get it on.

Get it to work for this year because I still want the web almanac to happen. I'd rather have the web almanac than something specifically for project wall is because that's fun.

And I can do funky stuff there with my own tone of voice, which is in front of its own way, but I think the web almanac has more authority and means more to more people.

I mean, it's nice to have a sort of central place where we get together and do it in with a certain level over your and verifiable methodology year after year.

I just want to say like I thank you for doing this regardless of where you did it. It's an amazing amount of work.

All of it is volunteer as well like all of the work for the almanac is volunteer or you know paid like a galley paid for us to contribute when we did it.

They paid for our time and I assume Google pays its employees who contribute and so on.

You know, but for a lot of a lot of people, this is like volunteer hours.

And it's as you can probably attest. It's like not a small amount of hours.

So I just want to say thank you for the thank you for the free labor and the research sharing it.

Very, very cool.

100% yeah.

Is there anything else that you would like from project wallets like would you are you looking for other people to be involved help you are you looking for ways to create some kind of service out of it?

Are you looking for ways to yeah, what's your vision for project wallets at this point?

The main thing for project wallets is for me to scratch my own itch and that itch usually changes every day.

So my goal is actually to be really honest is to keep it a side project so that I can work on it whenever I have appetite and energy.

That also means that it's it's mostly me and I've never tried to look for collaborators to work together on things because that means that I would have to work on wallets in times when I don't really want to.

There's times in the year where I were very low on energy and I just rather go outside and sit in the sun and don't want to be responsible for someone else.

That's yeah, so it's a side project and my goal is to to look at CSS from as many different angles as I can last year.

I figured out how to do just one example I figured out how to do how to collect CSS code coverage from my existing playwright tests that I have for project wallets.com.

So my whole website is covered with automated Atlas browser testing so why not collect CSS coverage data while you're doing that and then doing analysis on that found several issues with that but I can now look at my CSS and see exactly which lines of CSS are not covered in any of my tests I was able to delete some of my CSS because of that as well.

Which is the thing I don't think many of our developers get to do so yeah that I mean that was just I wanted to know if it's possible and it is I don't know so yeah I guess yeah that's what I want to do for project wallets just look at it from different different angles try try different things.

Some things are horrendous failure and never make a two productions some things are fun like to see as a selection and people are about it and that's very cool.

Yeah one of the things that I wonder about is if there's like some missing shared architecture for some of this stuff the infrastructure you know like I think the search engines have this like common crawl that they that they used that they share that is like all the metadata so that everybody's not.

Crawling the same content they have a kind of all pre indexed and all that kind of stuff I don't know about that very deeply but I wonder there seems to be a lot of people who have some itch in this area and like for all of us to you know write something that scrapes sites and fills up our hard drive and solve all the same problems over and over again seems like.

Like it would I would feel a lot less itchy I think if we could offload some of the harder parts into some common infrastructure and I don't know what that looks like but just a just a thought if there's I don't know that that has anything to do with project wallets other than would you agree there might be a easier way than you having to actually scrape all these sites.

I would be so happy yeah to to not let an old MacBook run for days and days on and rebooting it from time to time hoping the hard drive won't crash yeah to do to do fun like article on CSS analysis will be really great if that that wouldn't have been a worry.

Eric anything else do you want to know I think the well I mean we could talk for hours but I think before we go bar working people find you online and support what you do.

I am faint amount dot death on blue sky and I'm on project wallets dot com but you don't actually see me there but do give it a visit.

Would you mind spelling your handle for the sort of non Dutch folks.

Oh yeah sure that's fee and me and there you go.

All right thanks part for joining us this is a really enjoyable conversation I'm glad we got to connect and keep scratching your itches and sharing when you can because it's great stuff yeah thanks.

Thanks very much guys.