New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IE7 blank page if using font-face #30

Open
thasmo opened this Issue Mar 2, 2012 · 26 comments

Comments

Projects
None yet
@thasmo

thasmo commented Mar 2, 2012

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

This comment has been minimized.

Show comment
Hide comment
@thasmo

thasmo Mar 19, 2012

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

thasmo commented Mar 19, 2012

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

@thasmo thasmo closed this Mar 19, 2012

@ryfy

This comment has been minimized.

Show comment
Hide comment
@ryfy

ryfy Apr 6, 2012

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.

ryfy commented Apr 6, 2012

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

This comment has been minimized.

Show comment
Hide comment
@FlyingDR

FlyingDR Apr 27, 2012

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

FlyingDR commented Apr 27, 2012

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

@keithclark keithclark reopened this May 10, 2012

@kevinkneifel

This comment has been minimized.

Show comment
Hide comment
@kevinkneifel

kevinkneifel Jul 16, 2012

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.

kevinkneifel commented Jul 16, 2012

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

This comment has been minimized.

Show comment
Hide comment
@mjcampagna

mjcampagna Jul 26, 2012

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

mjcampagna commented Jul 26, 2012

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

This comment has been minimized.

Show comment
Hide comment
@natedillon

natedillon Aug 20, 2012

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.

natedillon commented Aug 20, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rickard2

rickard2 Oct 2, 2012

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.

rickard2 commented Oct 2, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rphair

rphair Oct 23, 2012

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.

rphair commented Oct 23, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rctneil

rctneil Jan 25, 2013

I too hope this can be fixed.

rctneil commented Jan 25, 2013

I too hope this can be fixed.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 5, 2013

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).

ghost commented Feb 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@zeorin

zeorin Feb 12, 2013

Also an issue for me. Please fix :)

zeorin commented Feb 12, 2013

Also an issue for me. Please fix :)

@doits

This comment has been minimized.

Show comment
Hide comment
@doits

doits Mar 28, 2013

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

doits commented Mar 28, 2013

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

@jglovier

This comment has been minimized.

Show comment
Hide comment
@jglovier

jglovier Apr 4, 2013

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.

jglovier commented Apr 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@michaelthorne

michaelthorne May 31, 2013

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.

michaelthorne commented May 31, 2013

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

This comment has been minimized.

Show comment
Hide comment
@adamwaite

adamwaite Aug 16, 2013

Same issue here.

adamwaite commented Aug 16, 2013

Same issue here.

@JeroenDelbroek

This comment has been minimized.

Show comment
Hide comment
@JeroenDelbroek

JeroenDelbroek Sep 8, 2013

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

JeroenDelbroek commented Sep 8, 2013

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

@tymn

This comment has been minimized.

Show comment
Hide comment
@tymn

tymn Sep 9, 2013

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

tymn commented Sep 9, 2013

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

@jakob-e

This comment has been minimized.

Show comment
Hide comment
@jakob-e

jakob-e Sep 10, 2013

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]-->

jakob-e commented Sep 10, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 15, 2013

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

ghost commented Sep 15, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jarodtaylor

jarodtaylor Dec 18, 2013

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.

jarodtaylor commented Dec 18, 2013

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

This comment has been minimized.

Show comment
Hide comment
@bensaufley

bensaufley Dec 30, 2013

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.

bensaufley commented Dec 30, 2013

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

This comment has been minimized.

Show comment
Hide comment
@tiroxis

tiroxis Feb 7, 2014

confirm

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

tiroxis commented Feb 7, 2014

confirm

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 8, 2014

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.

ghost commented Feb 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@joeyhoer

joeyhoer Feb 17, 2014

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.

joeyhoer commented Feb 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@OlofFredriksson

OlofFredriksson Feb 27, 2014

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

OlofFredriksson commented Feb 27, 2014

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

@kamranayub

This comment has been minimized.

Show comment
Hide comment
@kamranayub

kamranayub Apr 23, 2014

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.

kamranayub commented Apr 23, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment