This blog post (slightly annoying page there) (and that's not my blog by the way) describes a bizarre bug I ran into yesterday in Internet Explorer 8 only. The bug involves .EOT web fonts and <iframe> elements.
I haven't extensively researched the exact trigger for the bug, but it's basically the case that a page using a web font that loads content into an <iframe> such that the frame also uses a web font becomes "defaced" by the browser. The previously-OK text rendered with the web font suddenly shifts to awful-looking Arial or something else, sort-of on its own. Sometimes it flips back, only to degrade again on random user interactions like mouse moves.
That blog post has an example. To clarify, it's the containing page that gets messed up, not the page in the <iframe> (at least, that's the case so far in my experience).
Has anybody found a better workaround than what's suggested in that blog, which is to force a "reload" of the CSS <link> element from whence the @font-face declarations come? (I could do that but it'd be a minor pain, plus it would force me to move my font setup out of my document <head> which if I recall is a performance issue; I'll have to scrounge around and find that tidbit again.)
edit — update
OK here's a test page. Here's the main (container) page:
<!DOCTYPE html>
<html>
<head>
<style id='font_style'>
@font-face {
font-family: 'bold-display';
src: url('DejaVuSans-Bold.eot');
}
</style>
<style>
.fancy { font-family: bold-display, "franklin gothic medium", "verdana", sans-serif; font-size: 32px; }
iframe { width: 500px; height: 200px; }
#floater {
position: absolute;
top: 100px; left: 100px;
display: none;
}
#floater.showing {
display: block;
}
</style>
<script>
function load() {
var frame = document.createElement('iframe'),
floater = document.getElementById('floater'),
target = document.getElementById('target');
frame.src = 'frame.html';
target.appendChild(frame);
floater.className += 'showing';
}
function unload() {
var floater = document.getElementById('floater'),
target = document.getElementById('target');
target.innerHTML = '';
floater.className = floater.className.replace(/\bshowing\b/g, '');
}
</script>
</head>
<body>
<div class='fancy'>Hello World</div>
<button type='button' onclick='load()'>Click Me</button>
<div id='floater'>
<div id='target'></div>
<button type='button' onclick='unload()'>Close</button>
</body>
</html>
The frame page has the same @font-face and a dummy message.
The problem appears to have something to do with using the loaded fonts with a list of more than one alternate font. I (for no good reason) had tossed in a couple of similar more-common fonts in my "font-family" values. When I dropped them back to:
.title { font-family: bold-display, sans-serif; }
then the problem went away (or at least it seems to have gone away so far).
Thanks to those who've helped out. To @albert, add an answer summarizing what you tried and I'll upvote you :-)
@font-facestuff. I could try to make a sample, but it's tricky because the bug is, well, a bug. (There's really no doubt that this is a browser bug; it's totally obvious if you see it.) – AgraphiaClick MethenClosedoes nothing, but clickingClick Metwice hides it on the page and it causes it to loose the font declaration. I'll look into this more. – BlackburnClick Me, and the entire<iframe>is not within the browser window, it will not load the font in the<iframe>and it will unload it on reload. It obviously has to do with how they paint the page regarding<iframe>'s – Blackburnclick meagain after the font has been unloaded seems to cause the page to reload the font into the dom. There might be a solution buried in that fact. – Blackburn