I'm a huge proponent of dark color schemes! Aside from causing less eye strain due to emitting less blue light, dark pixels drain less battery life...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Wouldn't it be easiest (and most widely supported) to just insert a bit of blocking javascript at the start of the page that optionally adds a class to the
<body>element?That would still cause a flicker as described above. The header would enable the server to generate the appropriate static content so there's no client-side blocking.
How so?
For the blocking javascript to run (via
<script>tag) the browser needs to load the HTML for the page. This HTML won't have a theme initially applied to it, so the page could switch from light to dark after this script runs.Yea but that's the point of the javascript block; apply the theme as the page is loading, how would that still cause any flickering?
The JS doesn't run until the page is loaded. Here's an example.
...are you sure you don't want to double-check that before making that statement in public? I really recommend doing that.
No need to be snarky. Feel free to share a codesandbox demonstrating a blocking client-side script that doesn't flicker.
I am not familiar with how codesandbox does its loading, so I'm not going to go tinkering with that. For a simple index.html that you can just throw on a localhost and try it out:
Yes, that contrived example will load quickly enough to not have a noticeable flicker. But inlining logic directly inside a script tag isn't a good practice, nor is it always possible. If you pull that out into a file and load it via
srcyou will notice a flicker, which is what the codesandbox example I shared demonstrates.So your point is that an inline script won't work because it won't work anymore if you don't inline it? Do I need to explain how that doesn't make any sense?
As for inlining a script being "bad practice", I couldn't care less. People have been using tools to inline critical CSS for ages (or even doing it manually) so the same could be done for JS. Inline critical JS snippets that need to be there instantly, then put everything less important in its own file.
And again, I don't know how exactly codesandbox loads its content, so I can't really comment on any results you're getting with it. But if the results don't align with using a small localhost HTTP server, I'll trust the actual server setup before the sandbox.
Developers nowadays are running wild while talking about "best pratice" and "anti-pattern" makes me reconsider my basic HTML skill everyday. To summarize, there is no such thing that exists. Everything comes with their own advantages/disadvantages, why do we bother to make things become more complicated, just add a simple tag at the begin of the body and it will be loaded before the whole thing. How slow it could be to load this tiny script? Maybe 0.0001 second or even less?
document.documentElement.classList.add('dark');Yep. If you want to be really fancy, you can even use that script to set up some simple loading spinner so the page loads more nicely. All in all you'd end up with maybe 10 lines or so.
@darkwiiplayer This tone of bullying and gatekeeping is neither helpful to the author nor those reading this conversation. I know this is like a year later, but I'd really encourage some self reflection about how inappropriate and unprofessional this was. We should strive to be a welcoming and helpful community. If we have knowledge someone else lacks, we should present it tactfully so it's apparent our goal is to teach. If your approach involves mocking your students for being stupid, then you quite frankly should not participate.
Coming back to the conversation at hand, I'd like to teach the next folks who landed here about what I learned (or relearned, really, I've been away from traditional JS for too long.)
The spec tells us that inline
<script>elements are render blocking, and are executed to completion before resuming the HTML parser.If you're like me, you may have forgotten this after becoming accustomed to modules and modern frameworks. My mental model shifted to assuming all client-side scripts were executed after rendering, which is the typical case nowadays. But this rings a bell when I recall the old days of listening for the
DOMContentLoadedevent or jQuery's$.ready()So if you ended up here from Google, here's the takeaway - the request headers are still exciting, but they may not be necessary to avoid that flicker or FOUC. Remember, render-blocking is not evil, it's just a performance factor to be aware of.
But, to @bryce's point, it may not be possible if you're bound by your framework. For example, I'm using Next.js and the earliest their
<Script>component allows the execution is theirstrategy="beforeInteractive"attribute, but even though it executes before Next scripts and hydration, it's still deferred until after the first paint. I'm still working on a workaround, but I'm considering ye olde open-source contribution to request a "beforeParser" strategy.In my case, I want to load the proper favicon based on the user's dark mode preference, but it's worth noting that if you're just trying to apply the proper styles, you can use some variation of the following CSS:
If you think calling someone a gatekeeping bully for getting a bit too snarky several months ago is gonna make them more receptive to your criticism or do anything to improve the climate of a platform, then maybe you have just as much reason to reflect.
Regarding the actual topic of the discussion,
This part here is really important. It may not be as relevant in a world of frameworks, but inlining JavaScript into the HTML makes it execute as the document is parsed, blocking this process. This is generally not what developers want, but for small snippets of "critical" logic, this property of inline JS can be very useful, as in the example of changing a theme before the whole page has loaded. With some luck, the script might even apply the necessary changes before the actual stylesheet is even loaded (unless that is also inlined)
What's important to note here is that an inlined script cannot access DOM nodes that haven't been reached yet:
Perhaps, hard to say, but I felt compelled to reassure future readers that they don't have to feel stupid for missing this. I'm not calling you names, I'm calling you out. I've been called out before too. We're both better than that.
Credit where credit is due, you reminded me of this behavior I had long since forgotten about after more than 6 years without using
DOMContentLoaded.Safari uses webkit. Safari will get this header really close to the time it is released in webkit.