Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Asynchronous load doesn't work on IE #171

Closed
millermedeiros opened this Issue · 11 comments

6 participants

@millermedeiros

loading cufón using RequireJS or a simple script injection after DOM ready - document.createElement('script') - breaks cufón on IE 6-8.

it seems that the VML is inserted but it is not displayed properly (used IE8 developer tools to check the DOM).

loading cufon.js using a regular <script> tag solves the problem...

@kvcrawford

I worked around this with YepNope.js's test object and IE conditional tags. Basically, I place jQuery & Cufon in normal <script> tags inside an IE conditional comment, then I load YepNope and test for the presence of jQuery with test: window.jQuery, and use it to load the scripts if needed.

See my answer on Stack Overflow at http://stackoverflow.com/questions/4931190/cufon-loaded-asynchronously-doesnt-render-in-ie/5958067#5958067 or a test page I created at http://epraxadev.com/yepnope/

@millermedeiros

@kvcrawford you are still not loading cufón and jQuery asynchronously for IE <= 8. The main reason why I wanted to load it asynchronously was to be able to update the JavaScript files without having to update the HTML files and this doesn't solve the problem in fact it even increases it since you have to remember to update in 2 different places, I would stick with the extra script tags without using conditional comments at all. cheers.

@kvcrawford

@millermedeiros I'm a little confused, you definitely do not have to update your HTML files when updating Javascript files, even if you use traditional <script> tags. I suppose you mean that you are loading your javascript files from another .js file, rather than in js code inside your <head>? The same thing could be accomplished by including a common header file.

I do think I agree that I might skip the IE testing and use normal <script> tags for jQuery and Cufon, though. Hopefully jQuery will be cached from the Google CDN most of the time anyways, and loading the cufon files blocks the page loading and prevents the flash of non-cufon text.

I guess I just wanted an excuse to play around with YepNope for the first time ;) My cufon files weigh in at 240kb, is that worth all the extra effort to load it asynchronously in compatible browsers?

@millermedeiros

reasons for updating HTML and JS file:

  • upgrading jQuery to a newer version (when loading it from Google CDN the URL is tied to the version)..
  • remove Cufón since the font you are using is also available though @font-face or because it isn't needed anymore.
  • you decide to not use jQuery anymore and switch to something else.
  • need to load something else that needs to be executed before Cufón.
  • etc..

common header files aren't always possible or the best solution.

My recommendation is to load Cufón with a plain script tag until they fix this issue and load fonts after DOMReady using a script loader. If performance is a concern you can also move the <script> tags just before closing the <body> tag, it is a common practice.

PS: your mileage may vary depending on the kind of projects you are working on, having to edit in multiple places would be a maintenance nightmare for the kind of stuff I'm usually coding.

@kvcrawford

Ah forgive me, my brain was moving a little slow this morning, I was thinking of just updating the same .js file without renaming it. Which isn't good practice if you set far-future expires headers for caching :S

Thanks for the link to the blog post...now I get it =P

@artofrawr

Stumbled upon this thread, while trying to figure out why this won't work in IE:

// if @font-face is not supported
$.getScript("cufon-yui.js", function() { 
    $.getScript("cufon.font.js", function () { 
        Cufon.replace('#text');
        Cufon.now();
    }
}

I was trying to execute the above code after missing @font-face support had been detected. Miller's solution of "traditionally" loading Cufon works, but is not optimal because the files are wasted load when @font-face is supported anyways.

This works, but is not preferred:

<script src="cufon-yui.js" type="text/javascript"></script>
<script src="cufon.font.js" type="text/javascript"></script>

<script type="text/javascript">
    // if @font-face is not supported
    Cufon.replace('#text');
    Cufon.now();
</script>
@kvcrawford

@artofrawr

IE supports @font-face. If you only need to use Cufon when @font-face isn't supported, then why don't you use http://yepnopejs.com/ or another resource loader to conditionally load it? It won't matter that IE doesn't support asynchronous loading of cufon, because it will use @font-face instead, and it will never load the cufon files.

@artofrawr

Sorry, my post was misleading.

I am indeed using yepnope (through the Modernizr library) to asynchronously load Cufon when @font-face is not supported. So yes, you're right that it doesn't matter for my particular site, because the browser, where the asynchronous load doesn't work, supports @font-face anyways.

I discovered this issue through a forced "lack of @font-face support" result in the above testing, but I can imagine situations where one would want to purely opt for the asynchronous load of Cufon in which case this would be a problem.

@wturnerharris

I recently came across this problem as well. It would be nice if artofrawr's method worked as that was what I tried. Works flawlessly in firefox.

The reason I need a dynamic load is if the font resource is blocked or cannot be downloaded, then it should fallback to render with cufon. Therefore having cufon load by default is not as nice as only loading it if needed.

@mdumic

This does not work in IE because it does document.write while registering VML engine. (I just fixed that in my project)
Doing document.write in IE after Dom-Ready is a no-no!

After some blame investigation I found that this line was rewritten from document.createStyleSheet (due to "operation aborted" problem?!) few years ago. I would like to submit patch for this but I'm not sure how to test it properly not to introduce a regression.

@sorccu sorccu closed this in 2574bd6
@sorccu
Owner

There is a potential issue in the referenced patch that I have encountered before, but I no longer have any idea what it was. Applied and fixed, if something breaks we'll at least know what the issue was and be able to fix it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.