CODEWITHSUNDEEP
cssinternet-explorerfont-face
WHITECOLOR
WHITECOLOR

Reputation: 26140

IE 10, 11 iframe and fontface in external css

I'm loading external css with link in iframe.

css contains @font-faces

@font-face {
    font-family: "MyFont";
    font-weight: normal;
    font-style: normal;
    src: url('/assets/fonts/myFont.woff');
}

and fonts are applied in all browsers except IE 10, 11 (I'm not intrested in below). The css itself is loaded (other rules are applied in IE too) but @font-faces not.

If I emped font face with hardcore style tag, it works.

<style>
@font-face {
    font-family: "MyFont";
    font-weight: normal;
    font-style: normal;
    src: url('/assets/fonts/myFont.woff');
}
</style>

Maybe some one found a way to fix this for external css resource?

Upvotes: 0

Views: 2122

Answers (3)

Julian Dormon
Julian Dormon

Reputation: 1779

We had the almost the exact same problem. We were using Google's Webfont loader to load css fonts in both the parent and in the iFrame.

The iFrame was cross-domain so we couldn't use the iFrame method built-in to the Webfont api. The iFrame was responsible for loading it's own fonts.

The Webfont loader also provides callbacks for when a font is successfully loaded or not. What we found using IE (specifically version 11) loading the Debugging Tool AFTER the page load, was that the font loader was placing an inactive class on the HTML tag, which means the font did not successfully. If we ran the debugger before the page load, the fonts would magically load as expected and the web font loader would put the Active class on the HTML element, indicating a successful load.

What was stranger still, is when we tried to write the error to the console when a font failed, nothing would happen - never figured out what the issue was with that.

After doing plenty of research, we were able to replicate good behavior if we hard-coded the @FontFace declarations in our page's, head, just as the author of this question did. But since our service has no idea what fonts our users will be using, there is no way hard-coding styles was an option.

In the end, it seems to be some kind of caching bug, since the font loader worked while the debugger was running (apparently IE uses different caching rules while debugging - good idea, NOT). We tried setting No Cache metatags to no avail.

Anyway, the only viable answer I found was here: IE8 web font iframe bug workarounds Specifically unloading and reloading your stylesheets:

var sheets = document.styleSheets;
for(var s = 0, slen = sheets.length; s < slen; s++) {
  sheets[s].disabled = true;
  sheets[s].disabled = false;
}

I hope this helps some other poor coder who has yet again been suckered by the incompetent team over at IE.

Upvotes: 1

WHITECOLOR
WHITECOLOR

Reputation: 26140

Well I believe its a bug in IE and the only workaround is to hardwire css in tag id iframe document's head.

Upvotes: 1

Jaykumar Patel
Jaykumar Patel

Reputation: 27614

You must add your type font with EOT extension font, because IE support Embedded OpenType (EOT) file (.eot or .ote format).

If you do not have .eot or .ote file, convert font in this url everythingfont.

Correct font format,

 <style type="text/css" >
   @font-face {
    font-family: 'Sri-TSCRegular';
    src: url('sri-tsc-webfont.eot');
    src: url('sri-tsc-webfont.eot?#iefix') format('embedded-opentype'),
         url('sri-tsc-webfont.woff') format('woff'),
         url('sri-tsc-webfont.ttf') format('truetype'),
         url('sri-tsc-webfont.svg#Sri-TSCRegular') format('svg');
    font-weight: normal;
    font-style: normal;
   }
   body { font-family: "Sri-TSCRegular", serif }
  </style>

Hope this help you.

Upvotes: 3

Related Questions