Kevin Powell makes wonderful content. I am saddened by the negative responses here. This article is a great intro for the absolute beginner to dip their toes into CSS.
I've been writing CSS for 25 years and still I bookmarked this link. Unless you're a masochist and keep up to date with frontend dev, there is always something new to learn. I didn't know about the `color-scheme` attribute - saves me a lot of work! Never heard of `margin-inline` either.
I don't get the hate. I'm spinning up a portfolio site and I want to keep it as minimalist as possible. This kind of styling is exactly what I need, since I'm not trying to apply as a frontend web dev. Make it look reasonable on mobile and desktop.
> While this is really handy, it is a best practice to allow users to manually toggle the color-scheme as well. Some people prefer a dark system theme, but light website themes, and vice-versa.
It can make sense for a theme selector that works on the server, since you can serve specific HTML when building the page. However, if using a JavaScript-based solution that fetches the theme preference from localStorage, I find this almost always results in a "flashbang" in dark mode, as the retrieval is slower than the first browser paint.
I've been implementing (and recommending) pure CSS-based theming to avoid this problem. Users seem much happier with them, and I haven't heard anybody ask for a theme switcher. We just respect their existing preference. However, I can see this being a problem if you offer multiple color schemes (beyond just light and dark).
I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.
I do think an interesting approach would be a browser extension that lets you override the prefers-color-scheme property on a per-domain basis, similar to the toggle in dev tools.
> if using a JavaScript-based solution that fetches the theme preference from localStorage, I find this almost always results in a "flashbang" in dark mode, as the retrieval is slower than the first browser paint.
Not if you blockingly inline the three lines of JavaScript with a good old script tag right in the HTML.
> Your setting preference is saved with web browsers’ localStorage instead of cookies to help avoid needing “Accept Cookies” notes.
I'm not aware of the specifics of regulations in other parts of the world, but this distinction is irrelevant for the EU ePrivacy directive: a) it was never about cookies only, and b) purely functional cookies that record user preferences do not need explicit consent.
From [0]:
> 34,35 Storage of information in the sense of Article 5(3) ePD refers to placing information on a physical electronic storage medium that is part of a user or subscriber’s terminal equipment [..] this includes making use of established protocols such as browser cookie storage as well as customized software, regardless of who created or installed the protocols or software on the terminal equipment.
> 43 This might also be the case for web browsers that process information stored or generated information [sic] inside the device (such as cookies, local storage, WebSQL, or even information provided by the users themselves). The use of such information by an application would not be subject to Article 5(3) ePD as long as the information does not leave the device
Sorry to say, but your site does flashbang when navigating pages in dark mode. It would also be good if it inherited its initial state from the user preference, rather than requiring a manual adjustment.
I’ve never tried it but the first thing that comes to mind is to use a service worker. The service worker would append a parameter to the initial request to indicate what theme is set in local storage. Then the initial response can use that as the default theme.
You might be surprised how little there is to know. There are basically three strategies: 1. set your light theme color variables in :root and your dark theme colors in `@media (prefers-color-scheme: dark) { :root { ... } }` 2. use the newish `--var: light-dark(light-value, dark-value)` syntax with `:root { color-scheme: light dark; }` 3. use a class on the body to determine whether to apply light or dark variables (can be used in combination with the above to default to user’s current theme while letting javascript toggle the theme by toggling the class)
If you're just concerned about light vs dark, then this article (which was posted to HN) does an auto/light/dark toggle button without javascript, and it shows using CSS variables for your colors: https://lyra.horse/blog/2025/08/you-dont-need-js/
Well if it's my site I want to give users choice between 2 styles.
I remember Firefox used to have an option in the menu for selecting alternative stylesheets, multiple ones not just light and dark, I think it was a standard from CSS, but only Firefox had a way to select them through the UI, for other browsers you had to use Javascript to make a selector.
> I do think an interesting approach would be a browser extension that lets you override the prefers-color-scheme property on a per-domain basis, similar to the toggle in dev tools.
Presumably, most users wanting flashbang-less browsing experience use Dark Reader extension or similarly radical solutions.
The sad truth is that the user preferences and per-site persistence for stuff like this should always have been browser's responsibility to begin with: just the same way like the font-size/page zoom already is, and likewise some (blatantly limited) security settings. (Bitterly) amusing fact is that there was (and still is) concept of "alternate stylesheets" from the beginning of CSS (still part of the spec [0], no support outside Gecko), that also fade into obsolescence for it's lack of persistence. So to this days, Firefox, for example, has View → Page Style menu, where user can choose alternate stylesheet but the choice is not preserved across navigations, so is pretty useless on its own.
Similarly userstyles: specifications dictate there is like CSS origin level and how they should behave and that all "user agents" are supposed to give user a way to enter the cascade this way, but does not give any official way how to scope individual recipes to concrete origins. That's what the unofficial `@-moz-document` extension was that, and briefly had a chance to be formalised [1]. But I digress.
(Likewise all the "European" cookies banners: tragic example of regulation applied on the wrong level. Instead of putting users in charge with help of their "user agents": implicitly blocking pretty much everything and using permissions system that actually would have a chance to be more than "pinky promise we will not track you if you don't click this toggle inside our banner". But I digress even more, sorry.)
> I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.
At this point, when browsers do not support per-site user preference for that natively, pragmatic (most robust) way would be to respond with properly set HTML payload straight away. There is even specified HTTP header for this, so once adopted in browsers, we could even ditch HTTP cookies [2] for the persistence, but it seems quite demanding on the server (IIUC negotiating these "Client Hints" takes extra initial request round-trip).
Pragmatically, I guess having early running JS in the HEAD that ensures the proper color-scheme is set on the root not and only proper stylesheets load should pretty much prevent most flashbangs, provided the relevant bit would arrive early enough from the server. I think there does not exist any good no-JS-no-Cookie (or any JS-less persistence) solution that supports navigations, sadly.
Firefox does have a global setting to override the System setting if you want system dark but webpages light, for instance.
Most browsers also support per-page overrides, but the only consistent place to find it is Dev Tools, which is a shame.
I think browsers decided to invest in "Reader Mode" as a UX over more direct control of user styles and page styles, and I'm not always sure that is the correct choice, but I can understand how it seems the simpler "one-button" choice.
Sad that the state of affairs is that "offering a light and dark mode" is seen as a best practice for user choice in web styling. Oh, thank you, web developer, for letting me choose between two color schemes! Meanwhile, I can choose my desktop window colors, text colors, fonts, text size, down to the individual element, and have been able to do this since at least the 90s. If I want yellow comic sans on purple window backgrounds, I can have it. But not on a web page! How far we have regressed when it comes to user preferences and honoring them.
Weird, I’m offended by the opposite end of this. Why am I “theming” websites? What, is this MySpace? I want the professional paid/trained developer to design the site. If it’s light, I expect there to be good reasons for it. If not, ditto.
I feel the same way about salads in restaurants—I don’t want to have to slice produce, add dressing, and toss my own salad at the table without a bowl or proper utensils. I want the professionals who I am paying to prepare my meal to handle that. If I have problems with any of the ingredients, or some desire for unreasonable quantities of dressing, then I can make requests. Serving me a plate of neatly partitioned ingredients strikes me as an insane thing to do…I suppose unless it comes with fondue or I have signed up for some hibachi nonsense to make my dinner more “interactive”.
I have fully lost the thread, apologies, carry on.
OP's way of thinking is correct and better than all of the self-centered and callous replies I've seen here - y'all are the REASON we have to do things like, e.g. onerous ADA compliance measures and similar fights for user rights.
The ideal web would give the option of better separating form and function when possible. I'm well aware that this is an old set of values from another time, but today they're more important than ever, not just aesthetically, but with reference to ability and power and dare I say, freedom.
You seem to take offense at the idea that you have to read something that someone else designed. How do you cope with books, magazines, presentations, signs, menus in restaurants, etc?
Calling this a “sad state of affairs” is pretty dramatic. You have to gaze upon things that aren’t in your preferred colors, oh my!
This is way too old school for me (and I've been developing with JS/CSS since 1997 and HTML since ... before that. On my site I just use prefers-color-scheme and have a toggle to switch light/dark it if the user wants, persisting the choice locally. I detect Dark Reader and honor the user's choice with that.
What would you do if you had the option to choose any font of your choosing? What color for the headers? The background of the buttons? Should you be able to define the border radius? The CSS transitions? All of CSS?
You can do that. There are extension for that.
I don't think this is a concern for the vast majority of users.
The aspects you mentioned are part of a theme. The light and dark settings control the visual scheme, which is entirely different.
It is ludicrous to expect every web page to give the user control over individual theme elements. If you want such level of control, you can override them yourself with a custom style sheet.
So the strongly worded argument is just because on one locale of an unsupported proprietary system, which renders their entire desktop and applications with an abysmal font, you might get your website rendered with an abysmal font?
What if you get a terrible font choice on the standard `font-family: sans-serif`? Should all my visitors have to download 100 KB of external fonts because Microsoft are inept?
Meh, for my personal website, I'll keep using system-ui.
The issue is broader than that. The article's addendum points out that both Bootstrap and GitHub removed system-ui from their font stack, and another comment in this subthread mentions that Bluesky has done the same. In each case there's a link to comments and/or a PR which gives reasons.
Bootstrap later added it back, but in the PR discussion it was pointed out that this is still an issue on Chinese and Korean Windows, at least.
> Meh, for my personal website, I'll keep using system-ui.
Well sure, but in that case you could also use your own personal language that no-one else knows.
Ironically, that page does not render well on Chrome/Windows, at ~1920x2160 (that's half a 27" 3840x2160 monitor), with an excessive empty margin on the left pushing the book list to the right, causing a horizontal scrollbar, which when scrolled to its rightmost causes the right side of the website to scroll and leave an awkward empty space.
I guess this says something about the evolution of web standards.
CSS reset stylesheets are just the first step towards unmaintainable 'add to' stylesheets, laced with the word 'important' everywhere.
I think it is best to take the Kevin Powell approach, as per the article, where you will be leaning in on browser defaults. Clearly you have to do your cross-browser and cross-platform testing, however, after almost two decades of everything coming with a CSS reset lurking in the stylesheets somewhere and mountains of cruft on top (remember frameworks), it is so liberating to get rid of the lot and to use the modern CSS tools such as CSS Grid and CSS variables.
Nowadays CSS is my favourite 'LEGO set' and I love the creative opportunities. This contrasts with the olden days where I hated the hacks based on hacks that was CSS. I have gone from practically drowning despite wearing armbands to being able to effortlessly glide through the water. CSS reset is one of those 'armbands' and it takes courage to go without such things. Same goes for those awful CSS pre-processor things.
I have this vague memory of a blog where someone went through various CSS resets, and came to the conclusion that margins and paddings made up something like 90%+ of the differences between browsers. Apparently only "* { margin: 0; padding: 0; }" gets you most of the way there and the larger CSS reset stylesheets were so big because they included unnecessary stuff, rarely-used elements, or even added the creator's preferences instead of just being a reset.
I've recently chosen plain CSS for a project at work. Haven't got that far yet as it's been mostly backend work so far but for what had been done it's been good. I'm just a bit worried that it's going to look wrong in different browsers but I guess I'll burn that bridge when I get to it. Luckily I don't think there's going to be any safari users.
I’ve seen this one a few times and something about it doesn’t agree with my eye. It’s somehow in the weird awkward zone of not old enough to truly feel simple and functional, but not new enough to look modern minimal/clean. Might just be the font also, but I don’t find it very easy to read. Could just be me though.
I mean, it's a reset, not a complete style. You're supposed to apply your styles on top (well, underneath, as styles cascade; but hopefully you know what i meant).
Something similar to plain text can be created with the <pre> tag in HTML if you like to add metadata to your page.
Make sure to linewrap on your prefered 50-70ch limit for our reading pleasure, otherwise I will be adding the style="width:70ch" locally to your body tag.
Also, if the name had been two words, it would need to be quoted, right?
e.g. this wouldn't work either?
font-family: Times New Roman;
Edit: Well this and just "times" does work fine, which makes me wonder if it's been special cased due to being an older font, or if the matching is very permissive.
yknow what's also cool is specifying the font you want, so your website looks the way you want it to. This is generally referred to as "design" and, while considered an antipattern among people who entirely spurn aesthetics, it has something like a 3000 year history of getting people to engage with your content, assuming you have some.
Or you can leave the default so that the reader gets the font they want, because they are the one reading it so it doesn't really matter what the author thinks looks good unless it is somehow relevant to the text.
Like, this is a clever enough way to play golf and find an average that works between major browsers and come out with something that should generally be legible. "Look great" is a bit of hyperbole, because it'll always look like shit. Legible shit, probably.
What are good static site generators (SSGs) to create a simple minimalist academic-like website?
It seems Astro or Hugo (potentially with Tailwind to customize CSS) are good options. Astro felt more complex than needed, on the other hand, writing html/css manually doesn’t work well either (predefined layouts and easy to use style customization options would be needed). I couldn’t find a suitable Astro theme either (most themes seem to be made for companies, or needlessly fancy, and a few for individual blogs).
In the process of figuring this out, I was surprised how complicated designing a website has become. There are so many frameworks, components, integrations and significant dependancies that I wondered how web developers keep up in this ecosystem.
This actually might be the "correct" solution these days. Pre-LLMs I wrote myself a python script to that converts markdown to html with custom headers and footers and rest of the junk, but today I would for sure give LLM a go first and see if what it produces.
I use github pages with jekyll. It took a bit of time to make a custom theme and setup the custom domain, but its really simple now to just add markdown file and push to github.
No need for a SSG. Just copy something like this: https://thebestmotherfucking.website and make every page by hand like you are some 80 year old greybeard.
For what most people are doing with static site generators (blogging) going "raw" HTML is honestly not a bad choice. Most usage of Markdown is just to avoid writing tags. It's not a whole lot more work to write `<em>foo</em>` instead of `_foo_`.
HTML was meant to be hand-authored, not a compilation target. It's like if people forgot you can still cook rice without a rice cooker.
Yeah, I got fed up with all the dependencies and processes and workflows and configurations and just manually made my site like it's 2004, just hand-written HTML+CSS+JS. As long as it's a small personal site, this is very robust and there is no constant churn and deprecations and change for the sake of change.
I experimented with customizing a flat page by writing HTML and CSS manually, with some help from LLMs. Using this approach, it’s possible to create something resembling the website you linked.
The result is decent, though the organization of the long page could be improved. In my view, a good personal website would include space for a photo, name, and affiliation, along with a simple menu for sections like biography, publication, projects, with a professional style (font and colors), but no more complex.
The publication page could have a style for presenting papers in a clean well-formatted list. That may require a theme that comes with a layout and a degree of customization and novelty.
A lot of themes I looked into are not quite professional.
Readit News
It can make sense for a theme selector that works on the server, since you can serve specific HTML when building the page. However, if using a JavaScript-based solution that fetches the theme preference from localStorage, I find this almost always results in a "flashbang" in dark mode, as the retrieval is slower than the first browser paint.
I've been implementing (and recommending) pure CSS-based theming to avoid this problem. Users seem much happier with them, and I haven't heard anybody ask for a theme switcher. We just respect their existing preference. However, I can see this being a problem if you offer multiple color schemes (beyond just light and dark).
I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.
I do think an interesting approach would be a browser extension that lets you override the prefers-color-scheme property on a per-domain basis, similar to the toggle in dev tools.
Not if you blockingly inline the three lines of JavaScript with a good old script tag right in the HTML.
That way you will have a flash, but if the user set dark mode on their browser/DE, they'll flash in dark, not light.
Or, alternatively, you can always make it flash in dark. I never heard about anybody being annoyed by a dark flash.
I'm not aware of the specifics of regulations in other parts of the world, but this distinction is irrelevant for the EU ePrivacy directive: a) it was never about cookies only, and b) purely functional cookies that record user preferences do not need explicit consent.
From [0]:
> 34,35 Storage of information in the sense of Article 5(3) ePD refers to placing information on a physical electronic storage medium that is part of a user or subscriber’s terminal equipment [..] this includes making use of established protocols such as browser cookie storage as well as customized software, regardless of who created or installed the protocols or software on the terminal equipment.
> 43 This might also be the case for web browsers that process information stored or generated information [sic] inside the device (such as cookies, local storage, WebSQL, or even information provided by the users themselves). The use of such information by an application would not be subject to Article 5(3) ePD as long as the information does not leave the device
https://www.edpb.europa.eu/our-work-tools/documents/public-c...
Thank you for illustrating the fact that the phrase "best practice" means nothing, and is little more than a synonym for "I heard this somewhere."
I remember Firefox used to have an option in the menu for selecting alternative stylesheets, multiple ones not just light and dark, I think it was a standard from CSS, but only Firefox had a way to select them through the UI, for other browsers you had to use Javascript to make a selector.
Presumably, most users wanting flashbang-less browsing experience use Dark Reader extension or similarly radical solutions.
The sad truth is that the user preferences and per-site persistence for stuff like this should always have been browser's responsibility to begin with: just the same way like the font-size/page zoom already is, and likewise some (blatantly limited) security settings. (Bitterly) amusing fact is that there was (and still is) concept of "alternate stylesheets" from the beginning of CSS (still part of the spec [0], no support outside Gecko), that also fade into obsolescence for it's lack of persistence. So to this days, Firefox, for example, has View → Page Style menu, where user can choose alternate stylesheet but the choice is not preserved across navigations, so is pretty useless on its own.
Similarly userstyles: specifications dictate there is like CSS origin level and how they should behave and that all "user agents" are supposed to give user a way to enter the cascade this way, but does not give any official way how to scope individual recipes to concrete origins. That's what the unofficial `@-moz-document` extension was that, and briefly had a chance to be formalised [1]. But I digress.
(Likewise all the "European" cookies banners: tragic example of regulation applied on the wrong level. Instead of putting users in charge with help of their "user agents": implicitly blocking pretty much everything and using permissions system that actually would have a chance to be more than "pinky promise we will not track you if you don't click this toggle inside our banner". But I digress even more, sorry.)
> I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.
At this point, when browsers do not support per-site user preference for that natively, pragmatic (most robust) way would be to respond with properly set HTML payload straight away. There is even specified HTTP header for this, so once adopted in browsers, we could even ditch HTTP cookies [2] for the persistence, but it seems quite demanding on the server (IIUC negotiating these "Client Hints" takes extra initial request round-trip).
Pragmatically, I guess having early running JS in the HEAD that ensures the proper color-scheme is set on the root not and only proper stylesheets load should pretty much prevent most flashbangs, provided the relevant bit would arrive early enough from the server. I think there does not exist any good no-JS-no-Cookie (or any JS-less persistence) solution that supports navigations, sadly.
[0] https://html.spec.whatwg.org/multipage/links.html#rel-altern...
[1] https://www.w3.org/TR/2012/WD-css3-conditional-20121213/#cha...
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
Most browsers also support per-page overrides, but the only consistent place to find it is Dev Tools, which is a shame.
I think browsers decided to invest in "Reader Mode" as a UX over more direct control of user styles and page styles, and I'm not always sure that is the correct choice, but I can understand how it seems the simpler "one-button" choice.
I feel the same way about salads in restaurants—I don’t want to have to slice produce, add dressing, and toss my own salad at the table without a bowl or proper utensils. I want the professionals who I am paying to prepare my meal to handle that. If I have problems with any of the ingredients, or some desire for unreasonable quantities of dressing, then I can make requests. Serving me a plate of neatly partitioned ingredients strikes me as an insane thing to do…I suppose unless it comes with fondue or I have signed up for some hibachi nonsense to make my dinner more “interactive”.
I have fully lost the thread, apologies, carry on.
The ideal web would give the option of better separating form and function when possible. I'm well aware that this is an old set of values from another time, but today they're more important than ever, not just aesthetically, but with reference to ability and power and dare I say, freedom.
Calling this a “sad state of affairs” is pretty dramatic. You have to gaze upon things that aren’t in your preferred colors, oh my!
What would you do if you had the option to choose any font of your choosing? What color for the headers? The background of the buttons? Should you be able to define the border radius? The CSS transitions? All of CSS?
You can do that. There are extension for that.
I don't think this is a concern for the vast majority of users.
It is ludicrous to expect every web page to give the user control over individual theme elements. If you want such level of control, you can override them yourself with a custom style sheet.
https://infinnie.github.io/blog/2017/systemui.html
https://github.com/twbs/bootstrap/pull/22377/files
but it's back in the current one:
https://github.com/twbs/bootstrap/blob/main/scss/_variables....
This PR to Bluesky has more recent discussion about it and offers workarounds:
https://github.com/bluesky-social/social-app/pull/6139
What if you get a terrible font choice on the standard `font-family: sans-serif`? Should all my visitors have to download 100 KB of external fonts because Microsoft are inept?
Meh, for my personal website, I'll keep using system-ui.
Bootstrap later added it back, but in the PR discussion it was pointed out that this is still an issue on Chinese and Korean Windows, at least.
> Meh, for my personal website, I'll keep using system-ui.
Well sure, but in that case you could also use your own personal language that no-one else knows.
Cash money
I wouldn’t have made any sense of the CSS box model without him back in 2002.
https://meyerweb.com/eric/books/
I guess this says something about the evolution of web standards.
I think it is best to take the Kevin Powell approach, as per the article, where you will be leaning in on browser defaults. Clearly you have to do your cross-browser and cross-platform testing, however, after almost two decades of everything coming with a CSS reset lurking in the stylesheets somewhere and mountains of cruft on top (remember frameworks), it is so liberating to get rid of the lot and to use the modern CSS tools such as CSS Grid and CSS variables.
Nowadays CSS is my favourite 'LEGO set' and I love the creative opportunities. This contrasts with the olden days where I hated the hacks based on hacks that was CSS. I have gone from practically drowning despite wearing armbands to being able to effortlessly glide through the water. CSS reset is one of those 'armbands' and it takes courage to go without such things. Same goes for those awful CSS pre-processor things.
Something similar to plain text can be created with the <pre> tag in HTML if you like to add metadata to your page.
Make sure to linewrap on your prefered 50-70ch limit for our reading pleasure, otherwise I will be adding the style="width:70ch" locally to your body tag.
e.g. this wouldn't work either?
Edit: Well this and just "times" does work fine, which makes me wonder if it's been special cased due to being an older font, or if the matching is very permissive.This is generally referred to as "what pretty much everyone else thinks about your stupid font".
(i collect a lot of these design advice. more: https://github.com/swyxio/spark-joy/)
It seems Astro or Hugo (potentially with Tailwind to customize CSS) are good options. Astro felt more complex than needed, on the other hand, writing html/css manually doesn’t work well either (predefined layouts and easy to use style customization options would be needed). I couldn’t find a suitable Astro theme either (most themes seem to be made for companies, or needlessly fancy, and a few for individual blogs).
In the process of figuring this out, I was surprised how complicated designing a website has become. There are so many frameworks, components, integrations and significant dependancies that I wondered how web developers keep up in this ecosystem.
Sounds like you would enjoy https://mastrojs.github.io – a _minimal_ Astro alternative.
We could not hope that everything would remain simple. Thanks for all the open standards and frameworks that we don't have to license.
And yes, it is a paralysis of choice.
https://github.com/loldot/loldot.github.io
[0] https://11ty.dev/
[1] https://getzola.org/
I personally liked Astro's approach to "Components", less glue more "just writing html/md". That is of course a learning curve on its own.
HTML was meant to be hand-authored, not a compilation target. It's like if people forgot you can still cook rice without a rice cooker.
The result is decent, though the organization of the long page could be improved. In my view, a good personal website would include space for a photo, name, and affiliation, along with a simple menu for sections like biography, publication, projects, with a professional style (font and colors), but no more complex. The publication page could have a style for presenting papers in a clean well-formatted list. That may require a theme that comes with a layout and a degree of customization and novelty.
A lot of themes I looked into are not quite professional.
If anything good is left outside the temples of Facebook, etc, it's not much, and I'm embarrassed.