I'm seeing some non-standard behavior between devides when on desktop mode in mobile browsers. Encouraging people to load up DaniWeb from your mobile device, and then click the 'Desktop View' link in the footer, and post a screenshot of anything that looks off. Much obliged!

Dani AI

Generated

Short summary: the visible "flash" happens because the site initially renders the mobile CSS and later the JavaScript override switches to the desktop layout. noticed the flicker and confirmed the override is JS-driven. Two practical ways to remove the flash are listed below, with trade-offs and a small, safe example.

Server-side preference (best UX)

  • On the Desktop View link set an explicit preference (cookie or server-side session).
  • When the next request arrives the server reads that preference and renders the desktop template/CSS directly. This removes the flash entirely and avoids brittle UA sniffing. Use this when possible.

Head-inline detection (works without server changes)

  • Place a very small inline script at the start of <head> (before CSS links). It reads a persistent flag (cookie/localStorage) and adds a class to <html> so CSS can render the desired layout immediately.
  • Keep the script tiny to avoid blocking, and follow with CSS that uses the class to switch layouts.

Example (insert the first script before any stylesheet, and wire the desktop link to set the preference):

<script>
(function(){
  try {
    if (localStorage.getItem('dw_view') === 'desktop') {
      document.documentElement.className += ' desktop-override';
    }
  } catch(e){}
})();
</script>
/* after stylesheets: */
html.desktop-override .mobile-layout { display: none; }
html.desktop-override .desktop-layout { display: block; }

Click handler (set preference and reload):

// run when the "Desktop View" link is activated
localStorage.setItem('dw_view','desktop');
location.reload();

Troubleshooting tips

  • Use DevTools device emulation with CPU/network throttling and inspect the waterfall to see when the inline script runs relative to CSS.
  • Avoid hiding the whole body until JS runs (creates a blank page).
  • Prefer server-side rendering for first-load UX and cache/HTTP Vary handling if content depends on cookies.

Recommended Answers

All 4 Replies

The only strange behavior I see is that at page load, it first comes up as the mobile design, then 1/10 of a second later (a flicker), it displays as the mobile-desktop view.

Aside from that, I'm loving it so far.

The only strange behavior I see is that at page load, it first comes up as the mobile design, then 1/10 of a second later (a flicker), it displays as the mobile-desktop view.

That's by design. We override the native mobile design via javascript, so the flicker happens when the page finishes downloading and the javascript is given a chance to execute.

Actually, on second thought, you just gave me an idea. I think I might have a way around that.

Gah, that just broke stuff! I'll give it another go later or tomorrow.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.