jQuery .html() returns strange results in IE after other bindings
This article originally addressed jQuery 1.3.1. See below for results in jQuery 1.4 (18 January 2010)
When I’m testing work done with jQuery in Internet Explorer, I’m normally a karmic cow. I wonder if Mr Resig and friends ever thought about their specific contribution to world peace.
Indeed with jQuery, you can almost forget about the bad old days. At least until something comes along like it did this morning, when I hit a situation using .html().
Using .html() to return elements with bound events
If we use jQuery to bind events to an element and then take a look at the DOM, Internet Explorer may well return unexpected results. Here’s the code:
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
//<![CDATA[
$(document).ready(function(){
$('#countries li a').click(function(){alert('clicked!');})
alert($('#countries').html());
});
//]]>
</script>
...
<ol id="countries">
<li id="cty-1"><a href="#">Algeria</a></li>
<li id="cty-2"><a href="#">Argentina</a></li>
<li id="cty-3"><a href="#">Australia</a></li>
<li id="cty-4"><a href="#">Belarus</a></li>
<li id="cty-5"><a href="#">Brazil</a></li>
<li id="cty-6"><a href="#">Canada</a></li>
<li id="cty-7"><a href="#">Chile</a></li>
</ol>
Consider the result from Firefox below. Predictable isn’t it?
Now look at Internet Explorer 7 and notice the junk that’s found its way in there:
Results for IE7 + jQuery 1.4
It’s like Sizzle just ate a bag of shell-on peanuts in your taxicab. The behaviour has been described briefly by Matthew Pennell.
It’s only a problem if for some reason you need clean, well-formed XHTML.
Don’t depend on .html() for well-formed XML snippets
For example if – like me – you were using XHTML from the page as a dataset for use in a dynamic Flash object (via progressive enhancement) then that could be a problem: Flash balks at this stuff in IE.
Moral of the story: check your code
My quick fix was to change the order of business. I simply did my jQuery event binding after the data had been sent. A hard lesson learned, then, in view of the amount of time I spent tearing my hair out, but an important one nonetheless.
Comments
9 responses so far to jQuery .html() returns strange results in IE after other bindings
Why not give me your comments?
See also:
Progressive enhancement and Flash: no longer a pact with the Devil
For me, Flash development pretty much dropped off the radar in 2004. Jakob Nielsen famously killed the idea of Flash as the be-all and end-all of websites and suddenly, like ...
- Originally published: 17 Feb 2009 in Technical
IE7 only: float bug on elements with italic, background properties
Setting font-style:italic in your CSS for elements in the vicinity of a floated element can actually trigger a float bug in Internet Explorer 7. This is only a problem, so far ...
- Originally published: 13 Jul 2009 in Technical
Testing CSS for print media: we need a Print Preview for developers!
Source: Wikimedia Commons The virtues of @media print have been explained elsewhere, best of all by Eric Meyer in his seminal A List Apart article Going to Print, whose original publish ...
- Originally published: 15 Jun 2009 in Technical
Web Standards
I’m currently two-thirds through Jeffrey Zeldman’s “Designing with Web Standards”. It was published only a couple of years ago (a long time in Web world, of course) and it’s interesting to ...
- Originally published: 17 Oct 2005 in Technical
Only on the Internet
Some things just wouldn’t work offline, would they? Wikipedia would be no different to the Encyclopedia Britannica (actually without the key differentiator of connectivity, Wikipedia would have little going for it, ...
- Originally published: 27 Jul 2006 in Technology
Who is that guy?
Hello you. I'm Mike Padgett and I work in the technology sector as an Information Designer.
I also enjoy travel, concerts, films and walking.
I'm based in Brussels, Belgium. My current favourite Belgian beer is St Feuillien Brune.
February 17th, 2009 at 17:52
This has been fixed and it’s in jQuery 1.3.2 (which should be released very soon here).
February 18th, 2009 at 9:50
Well, how about that! If you ever get tired of web development, John, you’ll have a great career in international diplomacy.
March 2nd, 2009 at 20:04
There are still issues with 1.3.2.
Now I see a lot of sizset=”" sizcache=”" messages. I don’t even think this has to do with event assignment but simple use of selectors.
March 26th, 2009 at 21:47
i’m getting the exact same thing in IE using .html() “sizset= sizcache=” what is the deal?
March 26th, 2009 at 22:47
Hi Scott,
Well, John says it’s sorted…
http://dev.jquery.com/ticket/4282
… and Brian says not. I haven’t yet tested 1.3.2 myself with the example above. Have you?
April 2nd, 2009 at 22:07
i am also receiving this same problem in ie that the other scott is getting… i am using 1.3.2.. it’s not fixed. any other word on this?
April 3rd, 2009 at 11:46
Hmm, I think what we have here is that, though the precise details in my example and the dev-ticket quoted in #5 are different, the general issue is the same and it isn’t resolved as yet.
June 29th, 2009 at 11:10
This problem still occurs in jquery v1.3.2 by my knowledge.
September 24th, 2009 at 13:03
Well – I got this “sizset= /sizcache=”-bug too. But it is a little bit different to the descriped bug by Mike. Here the sizzler still doesn’t clean up, but the reason is clear:
just invalid html (I didn’t close a span-tag)
Safari and Firefox closed this tag correct and the ‘not so error tolerant’ IE messed up.
So I suggest you to check your code if this “sizset=”-Bug still appears in IE.
best regards,
Jurik
PS: For the hopeless ones – try to code a jQuery plugin that closes your tags if not closed in IE ;)