IE7 blank page if using font-face

[thasmo]

Hello!

When using a font-face CSS definition, selectivizr has a bug which results in IE7 not showing any page elements. It seems like they're invisible.

The following CSS is triggering the bug:

@font-face {
font-family: 'Colaborate-Thin';
src: url('colaborate-thin.eot');
src: url('colaborate-thin.eot?iefix') format('eot'),
url('colaborate-thin.woff') format('woff'),
url('colaborate-thin.ttf') format('truetype'),
url('colaborate-thin.svg#webfont8nzqAfDm') format('svg');
}

It seems it has to do something with the functions
parseStyleSheet() or resolveUrl(), but I'm not sure.

Regards,
Thasmo

[thasmo]

K, can't reproduce this anymore. Probably 1.0.3b fixed this already.

[ryfy]

I can reproduce the exact same thing with 1.0.3b and it's not just IE7 for me. IE8 as well. @thasmo try clearing your cache and reloading the page and it'll likely turn "invisible" again. Problem seems to only be on initial load before stylesheet is cached.

[FlyingDR]

Here is some more details about this problem that I dig during my attempts to find out a reason of blank screen in IE8:

• Problem is available in both 1.0.2 and 1.0.3b
• Problem is available in IE8 (IE7 was not tested), but IE9 in IE8 mode is not affected
• Problem is caused by existence of @font-face directive in CSS with at least one "src" property
• It doesn't matter if font is in EOT format or something else
• Font existence doesn't matter
• Usage of declared font in CSS rules doesn't matter
• Existence of PIE doesn't matter
• Page contents doesn't matter
• Simplest case to reproduce the problem is to run browser and type URL before loading anything else (means there should be no some site as home page).
• Looking in IE developer tools shows that BODY have "height: 0" and it may be the reason of invisible page
• In a case of the problem page itself is loaded, all related files are loaded too, DOM is constructed and page elements are in place (e.g. it is possible to find and click links, find input fields and so on)
• No JS errors are available when problem occurs
• Existence of other JS scripts (e.g. jQuery and its plugins) doesn't matter
• Problem doesn't depend on used JS framework (tried latest versions of jQuery, MooTools, Prototype and Dojo)
• BODY {zoom: 1;} doesn't fix the problem
• Problem only occurs if font declaration is in external stylesheet

Also I found a way to workaround this problem until it will (hopefully) be fixed in code: Moving @font-face declarations directly into HTML page solves the problem of blank screen

[kevinkneifel]

I used the solution suggested above (@font-face declarations in the HTML head) and it seems to have corrected the issue for me as well. I am using 1.0.3b and was serving fonts from a separate stylesheet.

[mjcampagna]

Also experiencing this issue with real IE8 (not IE9 in IE8 dev mode) and 1.0.3b. Hoping to see this fixed in the next build.

Thanks,
Matt

[natedillon]

I'm having this issue right now, but only with IE8. I'm using selectivizr with Drupal, and the problem only happens when I use Drupal's "Aggregate JavaScript files" feature. The only fix I've found is moving the @font-face styles to the head as mentioned above.

[rickard2]

I can also confirm this bug and that the workaround fixes it for me. Tested with IE8 on Windows XP, Vista and Windows 2003 server.

[rphair]

I have also confirmed this bug, on a CMS running a soup of Javascript: Modernizr, Repond.js, Selectivizr, Mootools (for Joomla) and jQuery (for MBP3.0).

Symptom the same on all Windows XP machines with IE8 that we could get our hands on: on http://cosd.com IE8 would crash whenever reloading the page: the screen would freeze and smear the content vertically if the scrollbar was used, or display solid white if in the middle of redrawing the page or responding to a change in screen width.

I tried disabling every one of the above javascripts, and some in groups. I also tried the working versions distributed together on http://selectivizr.com/tests/respond/ and back-revved versions working together on other sites. Nothing worked until we moved the @font-face rules into the <head>... thank you for not closing this issue!

Since then I've realised the working sites I saw that use custom fonts are using Google Web Fonts style sheets which are not evaluated due to selectivizr's cross-domain restriction. That would be another workaround I think: to host a font stylesheet on a related domain (like the web designer's).

For now we think the <head> workaround is cleaner but still hope this problem will be fixed soon. The win for us would be in our mobile CMS designs, to which this workaround adds about 600 uncacheable bytes that have to be reloaded with every page click. Nevertheless I am cheering selectivizr and the developer for having made our responsive design possible in the first place; we are already deeply in your debt.

[rctneil]

I too hope this can be fixed.

[ghost]

I'm also pretty keen to see this fixed. I'm using the head workaround for now but am also concerned about how much extra weight this is adding in terms of un-cached CSS as well as how it's affecting workflow (not being able to declare @font-face in existing stylesheets / Sass partials).

[zeorin]

Also an issue for me. Please fix :)

[doits]

got this problem too, even in IE8. fix seems to work.

[jglovier]

We are having this issue (or a similar variant) in IE7. Doesn't happen when testing on IE8 for us, but happens on IE7 only, until Selectivizr is removed.

The reason I say it may be a similar variant because what happens for our team most of the time is that the page loads with the fonts rendered as normal, but after a few seconds the page flashes blank, then re-renders without the fonts using only the local fallback fonts.

Also, the repo we are working on is using a font-face service like Typekit (but not Typekit), rather than straight local CSS font-face calls, FWIW.

[michaelthorne]

Just had the same issue. 1.0.3 didn't help, so I'm still declaring my font face in a block before my linked stylesheets and selectivizr include.

Great plugin, but disappointing that this issue is occurring in IE8.

[adamwaite]

Same issue here.

[JeroenDelbroek]

I'm having the same issue in IE8 with the Omega 4 theme for Drupal. It uses the selectivizr v1.0.3b version.

[tymn]

I'm also using the Omega 4 theme for Drupal and having the same issue in IE7 and 8.

[jakob-e]

In order to prevent @font-faces to disappear on ie8 (please die soon)
I found that if using respond.js - selectivizr.1.0.3b must be included before.
Also CSS and JS aggregation settings can cause problems.

<!--[if lt IE 9]>
<script src="js/selectivizr.1.0.3b.js"></script>
<script src="js/respond.js"></script>
<![endif]-->

[ghost]

Loading all web fonts via JS rather than CSS seems to side step this bug entirely.

For any Drupal folks reading this thread, see my comment here for a more detailed solution (it's in the Omega theme issue queue but can apply to any theme, Drupal 6, 7 or 8):

https://drupal.org/node/2083203#comment-7862697

For a tidy, CMS agnostic approach to loading web fonts from various sources via JS, see this library:

https://github.com/typekit/webfontloader

[jarodtaylor]

So, I guess this bug was just abandoned all together. I still get this screen in IE7 and IE8 when using @font-face. We're using 1.0.3b.

[bensaufley]

It looks like everybody else got this fixed by using inline styles in the head, but that didn't solve it for me (using 1.0.3b). This may be because I included the google font stylesheets in a [if gte IE 9 | !IE] block for compliant browsers? But Google serves different content to different browsers - I didn't have the option of embedding all possible browsers' content into an inline style.

The only thing that stopped the white screen from appearing at times was removing Selectivizr altogether.

[tiroxis]

confirm

getStyleSheets called in ContentLoad - work for me ( if cache empty also work )

[ghost]

Reading around the referenced issue posted by AlxMedia above it seems that this may only be an issue when viewing IE8 via developer tools and not necessarily an issue when viewing a site in "native" IE8. Can anyone else confirm this to be the case? I thought I'd tested this but it's been a while and currently don't have access to native IE8.

[joeyhoer]

I can confirm that native IE8 in Windows XP does suffer from the issue, but I believe it to be related to @import not @font-face, at least in my case. My @import was using an unquoted URL; quoting the URL seemed to resolve the issue.

[OlofFredriksson]

Had same problem as described in earlier comments, but managed to fix this to have the font includes directly in the html page.

[kamranayub]

We just ran into this issue. Interesting fix @joeyhoer, we didn't try that. We had font-face directives in a LESS file, so it was all included into a master LESS.

We fixed it as well by moving those declarations outside into the <head> of the layout.

@dixhuit we were having regular business users (non developers) running into the blank page in their IE8, on Windows 7 machines. I ran into it myself several times. It was especially bad for people that were farther away from our data center, like South Africa or other remote locations.