A CSS media query is a stupid way to implement this functionality. Unlike something like window size or display orientation which can and does change dynamically as a user is browsing, the user's preference for light or dark color schemes is usually consistent. Inline CSS media queries require the entire stylesheet source for each possible variation to be sent to and parsed by the browser when rendering the page, whether they are used or not. This increases bloat, but is an acceptable trade-off for something like display orientation, because the user might switch from horizontal to vertical and back again whilst actually reading the already-loaded page. Therefore, it makes sense to have sent both stylesheet variations to the browser. By contrast, (pun intended), sending a light and a dark variation is almost certainly going to result in half of the CSS that is sent never being used.

More significantly, we offer far in excess of just two themes on the exoticsilicon.com websites, to give users an even finer-grained choice of pages that are brightly colored, have muted color, are slightly dark, very dark, monochrome, and more. This can not be implemented with the overly simple and fundamentally limited prefers-color-scheme media query alone. We could, theoretically, create a special theme that incorporated two of our existing themes, a light and a dark one, and use the media query to select between them, and then if the user switched to a specific theme, only serve that one without the media query and it's associated bloat. However, that would still hurt performance for users who are browsing with cookies disabled, as they can't select an alternative theme, and in any case it goes against our principles to support a standard that we think has been badly implemented, thereby encouraging it's further use.

A far more sensible way to have implemented an indication of the user's preference for a light or dark color scheme in a web browser would have been an HTTP header with this information, which could be parsed by the server and allow appropriate content to be delivered. Note that a dark color scheme doesn't just mean inverting the color of the text and the background! To do it correctly may well require any graphical resources on the page to be changed, too. Not a challenge for static graphic content, and in some cases you might even be able to handle that case with semi-transparent dark color overlays, or css filters. This would avoid serving an entire alternative set of images which could easily run into several megabytes of data, although this approach wouldn't allow complete flexibility over the design. The situation is more complicated for video, though. Imagine a live video stream of educational material, divided equally between video of the lecturer and slides or a virtual whiteboard where textual content is being presented. The video of the lecturer would remain unchanged between light and dark versions, but ideally we would like to invert the whiteboard material for the dark color scheme. Handling this entirely on the client side would mean having the client choose one of two possible live streams, as the server has not been informed of the user's preference. If the streaming is customised for the individual connection in other ways, such as adjusting for the client's currently available bandwidth, or adding a unique waterwark to discourage further distribution, this means preparing an entire second video stream on the server which may go unused. By handling everything server-side, this problem doesn't exist.

In summary: the prefers-color-scheme css media query is too limited in scope, and too inefficient for our needs. It suffers from being implemented entirely on the client-side without sending the same information for parsing by the server.