The thought of doing this to my company’s rich React-based web app gave me a chuckle. Thanks to WAI-ARIA and lots of careful work, our document structure is quite semantic and well-organized, but...
The thought of doing this to my company’s rich React-based web app gave me a chuckle. Thanks to WAI-ARIA and lots of careful work, our document structure is quite semantic and well-organized, but that doesn’t translate to functioning without CSS.
It did get me thinking about how one would even implement CSS removal in a React context with a library of self-contained components. Just removing a <link> element isn’t going to have much effect on a bunch of CSS-in-JS and dynamically applied inline styles. You might be able to build a stylesheet like this:
*{background:unset!important;border:unset!important;color:unset!important;/* continue for literally every property in the CSS spec… */}
But even that wouldn’t override existing !important declarations in the codebase. Maybe there’s a way to strip those out programmatically, but I can’t think of it right now. Sounds like a headache.
Oh wow, another reason to avoid React at all costs whenever possible. (Never used, tbh.) I would never imagine a website that’s literally impossible to remove the style sheet.
Oh wow, another reason to avoid React at all costs whenever possible. (Never used, tbh.) I would never imagine a website that’s literally impossible to remove the style sheet.
Actually, for the right job, React is pretty good. It's just for the "website as an app" style rather than the "website as a document" style, so it solves very different problems. And also, it...
Actually, for the right job, React is pretty good. It's just for the "website as an app" style rather than the "website as a document" style, so it solves very different problems.
And also, it sadly has a bunch of ways to make a bad react app.
But for building web apps in a modular, reusable way, it's very enjoyable!
I just think, by default, it moves you away from the standard web model rather than towards it.
It does and it took me a while to wrap my head around that. Because for years the common wisdom (or at least the one that was drilled into my head) was to never mix HTML/CSS/JS. Use them all, of...
I just think, by default, it moves you away from the standard web model rather than towards it.
It does and it took me a while to wrap my head around that. Because for years the common wisdom (or at least the one that was drilled into my head) was to never mix HTML/CSS/JS. Use them all, of course, but avoid using inline styles, avoid a mess of <script> tags with complex JS in it, etc.
Then I got into Vue and single-file components. I had all three languages existing in the same file. Felt so gross, but damn was it convenient being able to scope CSS like that. And not having to jump between 3 different files to make a change? LOVED IT.
Then I got into React and we used styled props, which do ultimately turn into traditional CSS classes, but as-written it's very inline-like. And that felt gross, but god was it convenient being able to conditionally apply styles like that.
I think Vue's SFCs are currently my favourite way to write code. They keep your components so clean and organized. While separation of concerns is a nice idea, in reality what that means is a...
I think Vue's SFCs are currently my favourite way to write code. They keep your components so clean and organized. While separation of concerns is a nice idea, in reality what that means is a giant CSS file where people tack the latest thing they need on the bottom and move on. Styles are never cleaned up, so you run the risk of naming conflicts and you're constantly raising global specificity as the project grows.
The realities of modern development are that HTML, CSS, and JS are not separate concerns - they are intimately connected concerns. We use JS functions to write HTML classes to apply CSS styles all the time. These technologies work together, so it makes sense to bring them together. Modern frameworks do a great job of making this possible, while still narrowing the individual scope and scaling well to larger teams.
Well the problem isn't React per se, it's the crazy idea of building a complex, data-driven application with a robust GUI, which renders in a markup language intended for static documents. Tim...
Well the problem isn't React per se, it's the crazy idea of building a complex, data-driven application with a robust GUI, which renders in a markup language intended for static documents. Tim Berners-Lee and Daniel Connolly never dreamed of GPU-enabled dashboards, drag-and-drop widgets, modals, tooltips, or async API queries when they wrote up the humble HTML draft in 1993. We can debate whether all this functionality SHOULD have been shoehorned into it in the first place, but here we are regardless. I don't think most would be willing to give up their Gmail, YouTube, TikTok, Slack and Discord, etc. All of these webapps are in the same boat — it wouldn't be possible to implement them without CSS.
I get where you're coming from, FWIW... I remember the old days of the CSS Zen Garden and I used to advocate for a clean line of separation between content and presentation. I still think it's a great idea for mostly static sites, blogs, etc. But it's not realistic for modern web apps. Composable UI is where it's at! My modern codebases still take care to separate the CSS from the business logic as much as possible, for readability and maintainability, but once those apps are compiled and bundled the resulting code doesn't look very much like something Eric Meyer would've written.
The real Web 3.0 is like what Microsoft did for the Xbox 3 becoming XBox One: A bunch of loosely tethered primary-text sites with download links for anything heftier than a JPG. No more embedded...
The real Web 3.0 is like what Microsoft did for the Xbox 3 becoming XBox One: A bunch of loosely tethered primary-text sites with download links for anything heftier than a JPG. No more embedded executables.
React doesn't require embedded CSS, and can have external CSS just like a vanilla website. React is a tool and embedded styles is just one way to use it.
React doesn't require embedded CSS, and can have external CSS just like a vanilla website. React is a tool and embedded styles is just one way to use it.
I think this, to me, is more of an interesting thought experiment than something I would actively participate in. I remember the days of Flash, when so many people wanted to put so many things...
I think this, to me, is more of an interesting thought experiment than something I would actively participate in.
I remember the days of Flash, when so many people wanted to put so many things into Flash - including entire websites. Even then, it was controversial. The business people and graphic designers tended to support it because it was pretty, drove engagement, you could control all the things and the way the data was presented.
But a lot of folks were against it because it made things nonstandard, harder to use.
I feel that we still have that controversy today. That constant pull between trying to be new, different, exciting, controlling over the data and how people access it — and having useful information that is accessible.
I see awesome experiments on presenting information. I see awesome experiments that break the norms and controls and make things harder to use.
So to me, it's less important to see websites remove CSS, but it's more important to me that this be part of the conversation about information and accessibility.
Does this site I'm working on work on all levels? Is it a fresh, good design that communicates useful information and accomplishes its goal? What will it be like in 20 years? Will it still work? Can google parse it so people can find it? Can people with accessibility issues get the information easily?
So I think this is a valuable project and idea for discussion, even though I won't be participating in the actual event.
In the heyday of Flash we wanted a website to promote and sell through our laser cut stencil business. They implemented it as one giant flash object, including all the commerce, custom design...
In the heyday of Flash we wanted a website to promote and sell through our laser cut stencil business.
They implemented it as one giant flash object, including all the commerce, custom design feature, and standard product catalogue.
Sadly I can't access it anymore because on Wayback it's just a simple page that loads a swf that never got archived. The swf just gets 404 on internet archive on every recorded snapshot :(
That is precisely my argument against these types of technologies. Although I suppose there are other ways to make a site unusuable in the future. And some little things break. But keeping it...
That is precisely my argument against these types of technologies. Although I suppose there are other ways to make a site unusuable in the future. And some little things break. But keeping it towards standards with html/css/js seems like the best way to achieve longevity, for sure.
It's interesting to see that even the CSS Naked Day website is still using CSS on Naked Day which is today. Some of the participating websites mentioned here: css-naked-day.org/2025.html claim to...
It's interesting to see that even the CSS Naked Day website is still using CSS on Naked Day which is today.
Some of the participating websites mentioned here: css-naked-day.org/2025.html claim to be CSS-free but... it still seems like they are using a lot of CSS.
perhaps people are ashamed of being naked just like in real life
Taking a look at many of the other CSS Naked Day participants... Their websites really don't work well without CSS--things which should be at the top are in the middle of the page, etc. Hopefully this helps people think more about their HTML structure but I kinda doubt it.
I've said this before a couple times, but browsers really need to have a less awful default styling. There are millions of Word and Excel documents which get away with default "unstyled" styling but unstyled web pages look abhorrent in comparison. Not all sites use JavaScript but every site uses at least some CSS. I know this is not likely to ever change... but I feel like it is one of the very large reasons why the web largely does not follow the standards that closely. If web documents looked good in no-css mode we might have a lot more "collection of documents" than the "collection of walled gardens" that we have today
I think the most interesting aspect of this is the accessibility implications. Like for screen readers and such. If your website is unusable without CSS (and to an extent JavaScript), then some...
I think the most interesting aspect of this is the accessibility implications. Like for screen readers and such. If your website is unusable without CSS (and to an extent JavaScript), then some work should be done.
If every website worked without CSS, that would enable users (with the help of proper browser settings) to consistently use their preferred color scheme and font without needing extensions to hack apart every site or hope that they properly included settings to properly accommodate your need.
Of course, those kinds of options have been stripped away over time with the rise of the designer-oriented web which became unmanageable with ActiveX, Java, and Flash.
The thought of doing this to my company’s rich React-based web app gave me a chuckle. Thanks to WAI-ARIA and lots of careful work, our document structure is quite semantic and well-organized, but that doesn’t translate to functioning without CSS.
It did get me thinking about how one would even implement CSS removal in a React context with a library of self-contained components. Just removing a
<link>element isn’t going to have much effect on a bunch of CSS-in-JS and dynamically applied inline styles. You might be able to build a stylesheet like this:But even that wouldn’t override existing
!importantdeclarations in the codebase. Maybe there’s a way to strip those out programmatically, but I can’t think of it right now. Sounds like a headache.Oh wow, another reason to avoid React at all costs whenever possible. (Never used, tbh.) I would never imagine a website that’s literally impossible to remove the style sheet.
Actually, for the right job, React is pretty good. It's just for the "website as an app" style rather than the "website as a document" style, so it solves very different problems.
And also, it sadly has a bunch of ways to make a bad react app.
But for building web apps in a modular, reusable way, it's very enjoyable!
I just think, by default, it moves you away from the standard web model rather than towards it.
It does and it took me a while to wrap my head around that. Because for years the common wisdom (or at least the one that was drilled into my head) was to never mix HTML/CSS/JS. Use them all, of course, but avoid using inline styles, avoid a mess of
<script>tags with complex JS in it, etc.Then I got into Vue and single-file components. I had all three languages existing in the same file. Felt so gross, but damn was it convenient being able to scope CSS like that. And not having to jump between 3 different files to make a change? LOVED IT.
Then I got into React and we used styled props, which do ultimately turn into traditional CSS classes, but as-written it's very inline-like. And that felt gross, but god was it convenient being able to conditionally apply styles like that.
I think Vue's SFCs are currently my favourite way to write code. They keep your components so clean and organized. While separation of concerns is a nice idea, in reality what that means is a giant CSS file where people tack the latest thing they need on the bottom and move on. Styles are never cleaned up, so you run the risk of naming conflicts and you're constantly raising global specificity as the project grows.
The realities of modern development are that HTML, CSS, and JS are not separate concerns - they are intimately connected concerns. We use JS functions to write HTML classes to apply CSS styles all the time. These technologies work together, so it makes sense to bring them together. Modern frameworks do a great job of making this possible, while still narrowing the individual scope and scaling well to larger teams.
Well the problem isn't React per se, it's the crazy idea of building a complex, data-driven application with a robust GUI, which renders in a markup language intended for static documents. Tim Berners-Lee and Daniel Connolly never dreamed of GPU-enabled dashboards, drag-and-drop widgets, modals, tooltips, or async API queries when they wrote up the humble HTML draft in 1993. We can debate whether all this functionality SHOULD have been shoehorned into it in the first place, but here we are regardless. I don't think most would be willing to give up their Gmail, YouTube, TikTok, Slack and Discord, etc. All of these webapps are in the same boat — it wouldn't be possible to implement them without CSS.
I get where you're coming from, FWIW... I remember the old days of the CSS Zen Garden and I used to advocate for a clean line of separation between content and presentation. I still think it's a great idea for mostly static sites, blogs, etc. But it's not realistic for modern web apps. Composable UI is where it's at! My modern codebases still take care to separate the CSS from the business logic as much as possible, for readability and maintainability, but once those apps are compiled and bundled the resulting code doesn't look very much like something Eric Meyer would've written.
The real Web 3.0 is like what Microsoft did for the Xbox 3 becoming XBox One: A bunch of loosely tethered primary-text sites with download links for anything heftier than a JPG. No more embedded executables.
The rest of the bloat can stay on Web 2.0.
React doesn't require embedded CSS, and can have external CSS just like a vanilla website. React is a tool and embedded styles is just one way to use it.
I think this, to me, is more of an interesting thought experiment than something I would actively participate in.
I remember the days of Flash, when so many people wanted to put so many things into Flash - including entire websites. Even then, it was controversial. The business people and graphic designers tended to support it because it was pretty, drove engagement, you could control all the things and the way the data was presented.
But a lot of folks were against it because it made things nonstandard, harder to use.
I feel that we still have that controversy today. That constant pull between trying to be new, different, exciting, controlling over the data and how people access it — and having useful information that is accessible.
I see awesome experiments on presenting information. I see awesome experiments that break the norms and controls and make things harder to use.
So to me, it's less important to see websites remove CSS, but it's more important to me that this be part of the conversation about information and accessibility.
Does this site I'm working on work on all levels? Is it a fresh, good design that communicates useful information and accomplishes its goal? What will it be like in 20 years? Will it still work? Can google parse it so people can find it? Can people with accessibility issues get the information easily?
So I think this is a valuable project and idea for discussion, even though I won't be participating in the actual event.
In the heyday of Flash we wanted a website to promote and sell through our laser cut stencil business.
They implemented it as one giant flash object, including all the commerce, custom design feature, and standard product catalogue.
Sadly I can't access it anymore because on Wayback it's just a simple page that loads a swf that never got archived. The swf just gets 404 on internet archive on every recorded snapshot :(
RIP site.
That is precisely my argument against these types of technologies. Although I suppose there are other ways to make a site unusuable in the future. And some little things break. But keeping it towards standards with html/css/js seems like the best way to achieve longevity, for sure.
It's interesting to see that even the CSS Naked Day website is still using CSS on Naked Day which is today.
Some of the participating websites mentioned here: css-naked-day.org/2025.html claim to be CSS-free but... it still seems like they are using a lot of CSS.
perhaps people are ashamed of being naked just like in real life
Taking a look at many of the other CSS Naked Day participants... Their websites really don't work well without CSS--things which should be at the top are in the middle of the page, etc. Hopefully this helps people think more about their HTML structure but I kinda doubt it.
I've said this before a couple times, but browsers really need to have a less awful default styling. There are millions of Word and Excel documents which get away with default "unstyled" styling but unstyled web pages look abhorrent in comparison. Not all sites use JavaScript but every site uses at least some CSS. I know this is not likely to ever change... but I feel like it is one of the very large reasons why the web largely does not follow the standards that closely. If web documents looked good in no-css mode we might have a lot more "collection of documents" than the "collection of walled gardens" that we have today
NSFW but I found this video when searching "CSS naturism" and I find it notable... but it is somewhat the opposite of what I was looking for: https://commons.wikimedia.org/wiki/File:CSS_Naturist.webm
Note that the list is made up of “websites who plan to get naked in 2025!”, so it’s fair to assume some people just forgot about it.
I think the most interesting aspect of this is the accessibility implications. Like for screen readers and such. If your website is unusable without CSS (and to an extent JavaScript), then some work should be done.
If every website worked without CSS, that would enable users (with the help of proper browser settings) to consistently use their preferred color scheme and font without needing extensions to hack apart every site or hope that they properly included settings to properly accommodate your need.
Of course, those kinds of options have been stripped away over time with the rise of the designer-oriented web which became unmanageable with ActiveX, Java, and Flash.