You have much longer experience in the issues here, but initially to my eye "that looks expected." At least with what I can see in Milk, the "work" is all done from Javascript in the footer, and relying on JQuery to go back and "update" elements that already existed but did not yet have the attributes required. That arrangement "seems like it must" allow for the potential of "what I didn't want to see" being shown for zero or more time units before "what I wanted to see."Christian 2.0 wrote: Mon Dec 16, 2019 7:24 pm Unfortunately there are some occasional flickering issues that occur between the default being loaded and the cookie being read then applied. In the end I decided against including it in our live products until I could optimise things enough to prevent the flicker.
The same thing happens with some of the "replace my logo image" extensions which rely on a similar arrangement. Let prosilver load as-is initially, and then in the footer execute some JQuery that will replace well-known elements with the desired background and/or image. But for some zero or non-zero length of time, you were looking at the standard prosilver logo image.
I feel like I might understand the "why" of the design recommendations that have us place Javascript at the very end of the page. But this "dark versus light" scenario I described also seems like exactly the time when you would ignore that.
Yes, we don't want to spend any lengthy amount of time parsing or executing Javascript before the document body even loads. But if my intention is to decide "what CSS files should even be included in the
<head>", that feels like a "I must execute at least minimal Javascript in order to make that decision." Which doesn't mean "I have to load JQuery" or anything huge; just enough inline native Javascript to read the cookie value and decide whether I want to document.write( "<link href="{T_THEME_PATH}/dark.css?assets_version={T_ASSETS_VERSION}" rel="stylesheet">" ) or not.Meaning the CSS will be known to the agent before the start of the
<body> tag, same as any other CSS. There is no "period of time in which our decision was not yet in effect / not yet applied to the DOM elements."So what are some of the ramifications I'm perhaps unaware of or not considering in suggesting that approach?
There is plenty of work and other scenarios for which "wait until the page is loaded, then go back and tweak/update elements conditionally" is entirely appropriate, and presumably a more responsive design performance-wise. But when the decision is "what CSS should have been in effect for this entire page load", waiting until the end doesn't seem like the right design. Or more to the point, doesn't seem like the necessary design.