Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Came across this fix for the FOUC. It utilizes the fact that the responsive grid classes are not applied until the very end. In summary it shifts down all the page content, and then when the responsive-grid-* classes are applied it overrides that css. I'm sure there are some optimizations that can be made, but this is a first attempt at it.
/* Fixes the "flash of unstyled content" when loading an Omega theme */
html{background-color:#FFF;}
body.html {
opacity: 0;
opacity: 0.0;
-moz-opacity: 0.0;
filter:alpha(opacity=0);
}
body.html.responsive-layout-mobile, body.html.responsive-layout-normal {opacity: 1;}
Source: https://gist.github.com/1622320
Comment | File | Size | Author |
---|---|---|---|
#11 | 1407000-FOUC-11.patch | 2.45 KB | gilbot |
Comments
Comment #1
Steven Brown CreditAttribution: Steven Brown commentedI'm new to the Omega theme however, I'm not sure what you mean by "flash of unstyled content".
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedIf you use the responsive grid, there's a fraction of a second before the javascript applies the correct class to the body. If you subscribe to the "mobile first" design philosophy, this means until that javascript class is applied, the mobile version of the site appears on your desktop for that fraction of a second. The more CSS and javascript you have on the site, the longer this time segment becomes and the more noticeable.
I've leveraged the way this works by moving all body content down below the "fold," then when that javascript class is added move it back up. This way until that javascript class applies, the content is not visible to the user and the first they see of the site is the correct version for their device.
Comment #3
Steven Brown CreditAttribution: Steven Brown commentedI haven't experienced this issue from Omega out of the box. Are you sure there isn't something that has been added that could be causing this issue? I'll need to test it again. Also what browser are you using?
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedYeah, I work as a Sr Software Engineer for a web development company that has built several D7 sites using the Omega theme. This is an issue we started noticing when moving to the "mobile first" design approach, and is inherent to javascript. There will always be to some extent a lag between download to the javascript parsing, and the larger the site the bigger the issue. For the majority of sites it's been very minimal - but the issue is well documented as are the various approaches. LearningjQuery.com has some interesting ideas to avoid this, as does Webkit.org. It is worth noting however that this mostly applies to "mobile first" responsive design, and doesn't affect your more classic approaches as much.
http://www.learningjquery.com/2008/10/1-way-to-avoid-the-flash-of-unstyl...
http://www.webkit.org/blog/66/the-fouc-problem/
Comment #5
Steven Brown CreditAttribution: Steven Brown commentedI'm not 100% sure if the links you sent are site that do this or not, but if they are I'm not getting the flash issue.
Comment #6
Cellar Door CreditAttribution: Cellar Door commentedFatGuyLaughing - what bryanburkholder is describing is common among mobile first responsive sites. The flash of content is less noticeable on sites in which there is minimal js or css that needs to be applied to the page. What I think this fix does is move the content off the page entirely until is is styled and moved back by the regular omega grid css files which are loaded last. The lag depends on the speed of the device that is parsing the files and what has to be done on the site from them. It's a performance tuning issue and makes the screen look as if it is still "loading" (white screen) but in reality it's styling it off page then moving it back in.
Good reference for larger sites that are experiencing this issue, thanks bryanburkholder!
Himerus/Fubhy - should this be rolled into an alpha stylesheet (reset maybe?) for the next update that way it can solve the issue for those who are experiencing it and for those that aren't there won't be any effect to their current sites?
Comment #7
jerryitt CreditAttribution: jerryitt commentedThere are several ways around this, I believe its only Webkit based browsers that are affected if memory serves. I have done something very similar to this in the past.
I agree with Cellar Door, perhaps this should be rolled into an alpha stylesheet reset for the next update as it is an easy fix?
Comment #8
Steven Brown CreditAttribution: Steven Brown commentedI don't know what the right answer is but this is basically a CSS hack/workaround to make it work. Although this works, it would be nice if we could implement something more concrete.
Comment #8.0
Anonymous (not verified) CreditAttribution: Anonymous commentedModified code to fix issue with IE browsers
Comment #8.1
Anonymous (not verified) CreditAttribution: Anonymous commentedCode fix to prevent WYSIWYG issues.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedSlight change to the original code. Now using opacities instead of margins - better browser performance and no worries about larger screens.
Comment #10
LewisNymanThe problem with this javascript is it runs too late, the resize function is called on window.load, which is long time after the page has been rendered. I played around with the Javascript, calling the resize function in behaviours is still too late to prevent the FOUC.
This function is essentially filling the same role as the Monderizr add class function, it needs to run as early as possible because it affects how the dom is rendered.
Comment #11
gilbot CreditAttribution: gilbot commentedBased on LewisNymans comment, here is a patch which removes the behavior and runs the code without the FOUC
Comment #11.0
gilbot CreditAttribution: gilbot commentedPerformance tweak