Happy Hardware Accelerated Holidays

Here are two new HTML5 experiences you can run in your browser, designed in the spirit of the holiday season and with hardware accelerated HTML5 in mind.

Check out Santa’s Workshop, where the speed of your browser on your PC determines how many elves help pack Santa’s bag for the big night, and how fast they work. We built this experience using HTML5 technologies like integrated SVG graphics and HTML5 audio.

Santa's Workshop demo

See how big of a storm your browser and your PC can kick up with HTML5 Blizzard. Your snowflake score shows you how many falling snowflakes can be animated in real time (60FPS). The more snowflakes you see, the faster your browser and PC. This experience combines HTML5 canvas, SVG, audio, CSS3 and WOFF fonts together to create a winter wonderland.

HTML5 Blizzard demo

Just over a year ago we presented the earliest look at IE9 and how browsing experiences are better through the power of underlying hardware and operating system. Starting in March at MIX 2010, and throughout the year, we demonstrated our approach to bringing full hardware acceleration to the web in IE9. We showed continuing progress with the release of seven platform previews, the IE9 beta, and through samples on the IE test drive site.

We showed how web applications built on the next generation of hardware accelerated HTML5 approach the level of interactivity and performance found in native apps, and we had some fun along the way (as did many partners) – we hope you did as well.

Thank you!

Your participation and feedback is an important part of how we build IE9. Today we want to say thank you to everyone who has downloaded IE9 beta and previews, run the test drives, reported issues on Connect, or submitted feedback through the Send Feedback (alt+X, K) in IE9 beta. We also want to thank the people and groups who make the standards process work, the broad community of web developers, and enthusiastic consumers who work to move the web forward.

From the entire IE team, we wish you a happy hardware accelerated Holiday season, and we look forward to another exciting year on the web in 2011.

Rob Mauceri
Group Program Manager, IE

Comments (82)
  1. Santa says:

    And a Merry Christmas to you, too.

    ( Happy Holidays, tssssch….) <insert appropriate smiley here>

  2. blepore says:

    Sigh. Vista Business box with 2 GB of RAM = an awesome 8 presents/minute and 3 snowflakes. πŸ™

    Still cool. Why is Workshop music sitll playing when I have that tab closed ….

  3. Olivier says:

    "This demo requires ECMAScript 5 properties API support. We recomend you upgrade before proceeding. If you would like, you can try the demo anyway with your current browser by clicking here."

    It's "recoMmend".

  4. Lennie says:

    Not sure who programmed this demo, but it is doing anything special, you don't need to have hardware acceleration for this.

    I tried the demo's in different browsers and the first demo didn't work in IE9 at all. In other browsers atleast one demo didn't load, but the browser didn't have anything to do either. So it seems to have crashed, maybe someone needs to learn how to do things x-browser.

    Maybe the person that created the demo should do more testing. Especially on different machines with different graphics drivers.

    The inline SVG worked best in Firefox 4 Beta, the Javascript performance was best in Google Chrome and IE9 was just confused.

  5. Jace says:

    Merry Christmas! Keep up the good work.

    Find the light of the world:


  6. planetarian says:

    @Jace: cool story bro.

  7. Mike says:

    3 snowflakes in opera, 3 in firefox, IE preview works like a storm (pardon the pun)

    But somehow I don't believe this has anything to do with hardware acceleration. Are these demonstrations contrived to make other browsers look bad, (it crashed in chrome completely!)

  8. Seth [MSFT] says:

    @blepore: Sorry to hear about the audio issue, are you running IE9 Beta? This is a known issue that we saw on a small number of machines with the beta release.

  9. Scuba says:

    Great performance with IE9-P7. I get 11 Elf's and 85 packages/minute and I get 2400 snowflakes.

    Processor Intel(R) Core(TM)2 Duo CPU E7400  @ 2800 Mhz, 2 Core(s), 4GB RAM, Nvidia GT8600

  10. Pankaj Sharma says:

    Great Work By IE Team.IE surely rocks.


  11. blepore says:

    Yup. Version 9.0.7930.16406 if that matters. I didn't try it in the latest platform preview.

    Is there a reason why the betas aren't kept up to the rendering of the previews?

  12. me says:

    works fine here (also 9.0.7930.16406). ~500 Snowflakes on my old and underpowered Latitude D820 (Intel T7200 2GHz, 4GB RAM)

    Compare to: FF and Safari on my buddy's Mac Pro (Dual Quad Xeon 2.8GHz, 8GB RAM) – 3 (in words, "three")

  13. John says:

    I'm using IE9 beta, yet both these demos insisted i was using IE7. Just in case you're wondering, version 9.0.7930.16406. Other that that, I really do like IE9.

  14. Adrian says:


    Perhaps you had compatibility mode turned on?

  15. Steve says:

    I hate to repeat this here but once a post on the IE blog is not the latest post it gets ignored.

    Can someone from Microsoft please make a statement about shutting down the IE6/IE7/IE8/IE9 images at http://www.spoon.net/


    This was **THE** most useful resource for testing multiple versions of IE and the shutdown really ticked developers off!

    As a long time web developer of Enterprise Web Applications I've tried all the options out there to try and simplify testing IE and the lack of realistic options is a royal PITA.

    1.) Multiple IEs – IE8 breaks the functionality of IE6's textboxes – thus its a NO-GO

    2.) IETester – works great until you need to test popup interaction and then it fails – thus a NO-GO

    3.) Virtual PC with timebombed images of IE6, IE7, IE8 – works ok, but the 12Gigs of HD space needed is frustrating when each full image of Windows dies 4 times a year, running a full Windows image is slow and you have to beg for updates because the releases are not co-ordinated and announced well at all – thus its a NO-GO

    4.) IE Super Preview – Last I checked this did not allow full testing of IE user interaction, JavaScript DOM changes, popups etc. – thus its a NO-GO

    5.) Multiple PC's to run multiple versions of windows and IE.  With all the hardware, software, and physical space needed – its a NO-GO

    6.) Spoon.net IEs – They work, they work just like local native apps once running, and there's no hacking of my real local IE install. – the **ONLY** problem with these IE's is that Microsoft shut them down

    Please understand that we (developers) just want something that works.  Testing in multiple versions of IE is a pain to begin with and with IE9 on the horizon it is only getting worse.

    I'm not sure where the issue stands with Spoon, but I would really like a solution worked out fast.


  16. Harold says:

    although the demos are quite neat there is a horrible side-effect of abusing this hardware acceleration.  When I start the snowstorm demo my GPU kicks in and starts crunching… the problem is I have a laptop, and it starts pouring out heat and the fans go into overdrive… after 40 seconds I killed IE as I don't want to cook my hardware thank you very much.

    is there an option to TURN OFF the GPU hardware acceleration? can I just use the improved IE script engine without the GPU abuse?  I realize that it won't be as fast as it could be, but there is no way I'm going to ruin my laptop just so I can play games on the web.

    actually this brings up an interesting question… if I do TURN OFF THE GPU in IE9 will JavaScript run faster than in IE8? or was IE JavaScript performance only improved in IE by hijacking the GPU.



  17. CvP says:

    the blizzard demo doesnt work on chrome 10 unless you resize the window to ~350×350. Then I get ~700 on my processor. I got ~420 on latest minefield and ~1989 on IE9pp7.

  18. Will says:

    CvP even doing that, I only get sound and background image but nothing else.

  19. <strong><a href="blogs.msdn.com/…/happy-hardware-accelerated-holidays.aspx You can disable the GPU acceleration in Internet Options. Go to the Advanced tab and it's the first option.

  20. <b><a href="blogs.msdn.com/…/happy-hardware-accelerated-holidays.aspx You can disable the GPU acceleration in Internet Options. Go to the Advanced tab and it's the first option.

  21. Banta says:

    Merry Christmas and gud job guys !!

  22. Stifu says:

    @Harold: JavaScript is JIT-compiled in IE9, this brings speed improvements that are independent from GPU acceleration. Else it wouldn't do so well on JS benchmarks, many of which do not test graphics-related stuff. In other words, if you turned off GPU acceleration (if possible in IE9, dunno about that), JavaScript would still be much faster than in IE8.

  23. Croft says:

    Merry Christmas from finland! πŸ˜‰ Good job!

  24. Brian says:

    Merry Christmas IE9 team =]. and thanks for all the hard work!

  25. agarvan says:

    I only got 3 snowflakes on my corporate Vista computer from Dell.

  26. Harold says:

    @Bill Gates II – I'm using the latest platform preview which does not contain a tools > internet options menu item – thus no luck πŸ™

    I'm glad to hear that it is an option in the browser though – the only question is will it be disabled by default considering that there isn't any good throttling available for the usage? Or will throttling be added to the final release to ensure that IE9 does not cause hardware damage?

  27. Klimax says:

    IE Beta Snoflakes: ~950

    IE PP: ~2500

    HP Elitebook

  28. Richard Maynard says:

    The audio doesn't work in Firefox 4. The Santa's Workshop page has the audio block as:

    <audio loop="true" autoplay="true">

    <source src="media/song.mp4"/>

    <source src="media/song.ogg"/>


    It is very encouraging to see Microsoft constructively embrace the web and make use of an open audio format (something that should also be done with all video on this blog). Sadly, however, media/song.ogg does not exist on the site and returns a 404.

  29. Richard Maynard says:

    And similarly for HTML5 Blizzard. Its audio block tries to use Audio/HolidayJazz.ogg but HolidayJazz.ogg is missing from the Audio directory. So an upload of song.ogg and HolidayJazz.ogg will fix both issues.

  30. IE8 lover says:

    Happy non customizable holidays!!

  31. Taker says:

    Thanks for developing IE9, but when it done, can you destroy all of the version before on the world???

    (which means IE6, 7, 8)

    You should have some strategy to let IE users to use the latest version, not stay in version 6, 7, 8

    IE6 ,7 8 waste a lot of web developers life.

    thanks again.

  32. Croft says:

    Hello again! πŸ™‚ My results:

    HTML5 Blizzard:

                       Internet Explorer 9 Beta: ~0340

    Internet Explorer Platform Preview 7: ~2040

    Santa's Workshop:

                       Internet Explorer 9 Beta: 09 presents per minute

    Internet Explorer Platform Preview 7: 25 present per minute

    HP Pavilion (2008 series)

    Amazingly, I have never followed this development closely, this is interesting to watch. I love my favorite browser ever more and more … πŸ˜‰

  33. William says:

    Speaking of spec compliance – will IE9 properly enforce the correct method signature for


    and not allow ANY usage of the incorrect and INVALID


    Getting IE to properly follow the specs is the FIRST step in making IE and standards based browser… Something that IE has never been able to claim and still can't in IE9 yet.

  34. William says:

    Er that should be… "…In making IE a standards based browser…"

  35. JM says:

    @William – In IE9, an exception is thrown when using document.createElement with HTML markup.

  36. Jesus says:

    When the IE9 is official releases, it's the time that css4 & html6 release.

  37. Dobby says:

    Why do the elves go on strike after a minute or so?

    The number then gradually drops from 10 to only one.

    This is both in the beta and the PP7, hardware accel. is enabled.

  38. Nick says:

    Just because IE sucks and doesn't support OGG formats doesn't mean that MSFT should create demos that penalize those browsers that do support open formats for the open Web. Way to fail at attempting to implement HTML5!

    Provide the Ogg files or take down the demo as it only shows your contempt for the open Web and the browsers that implemented standards before IE could catch up.

  39. Klimax says:

    Nick,how easy it is to turn it against browsers not supporting mp3 and H264 it makes one wonder why are you posting such illogical comment.

  40. Makaveli says:

    Santa Workshop

    IE 9 Beta 64bit

    21 elves working 240 presents per minute



    Machine Core i7 920 @ 3.6 Ghz + Radeon 4890 + Intel 160GB G2 SSD

  41. Makaveli says:

    Santa Workshop

    IE 9 Beta 64bit

    21 elves working 240 presents per minute



    Machine Core i7 920 @ 3.6 Ghz + Radeon 4890 + Intel 160GB G2 SSD

  42. Dave says:

    I'm glad to see that in IE9, in standards mode that IE correctly throws an exception if you try to use HTML in this method call:

    var foo = document.createElement('<input id="foo_1"/>');

    However the error that shows up in the console points to the WRONG character index (points to 2… the "a" in "var")

    The actual exception instance also contains a collection of 20+ unrelated error constants… Why???? e.g. NO_DATA_ALLOWED_ERR:6, INVALID_MODIFICATION_ERR:13, etc.

    Finally, one of the constants is improperly named: "INUSE_ATTRIBUTE_ERR" (10) should be:  "IN_USE_ATTRIBUTE_ERR" (note the underscore after IN and before USE)

    Now, I'm not sure how big an issue this is, but it isn't very helpful.   The console tab in the IE dev tools indicates that an exception was thrown but not caught… vs. that there was a DOM error (pointing out the exact issue) "SCRIPT5022: Exception thrown and not caught" is about as helpful as saying "woopsie" with no explanation.

    In Firebug (a dev toolbar that IE could only dream of matching) nicely points out:

    "String contains an invalid character" Code 5, and actually prints out the offending line so that you can easily see what the issue actually is.

    on a side note – the holiday demos you added don't work cross-browser because your non-IE resources return 404 errors – please fix.


  43. Dave says:

    Oh one other really annoying thing.  The IE9 preview application has done something funky with scrollable regions (including the main application window) such that they don't work with many trackpad scrollers.  E.g. on any Lenovo trackpad, I can't scroll the main window, or any scrollable area inside the window using the trackpad scroller.  This works fine in any other application in windows – just not the IE preview which is REALLY annoying!  I also had issues on an ACER laptop and I believe a Toshiba? (can't recall the brand)

    Please fix this in the next preview so that we can properly test IE9.

  44. SuperSparky says:

    Once again, total B.S.  Yet, what else is there to expect from MS "comparison" benchmarks?  The "test" only adjusts IF it's IE9.  It first checks browser type and if not IE9, it assigns one elf.  Typical.

  45. Makaveli says:

    Supersparky when I run this in chrome I get 14 elfs working!

    IE9 beta gives me 21 elfs

    Doesn't work in Firefox 3.6 for me cause there is no API support.

  46. electronics says:

    get electronic components from http://www.partinchina.com and http://www.hqew.net

  47. Anonymuos says:

    Dear MS, you have forever lost at least one loyal IE1-8 user because of the dumbed down non customizable UI and your craze for "reduced concepts" as you put it.

  48. deap27m says:

    I reported that most blogger's blogs IE9 work too slowly to Beta, I wish you could provide some support for these sites. Thanks.

  49. Richard Maynard says:

    Ha. I see the audio issue has been "fixed" by removing references to the Vorbis version from the source of Santa's Workshop and HTML5 Blizzard. What a delightful farce. You stay classy, Microsoft.

  50. shawn says:

    Any chance IE9 will support the new "async=false" script property standard that is being proposed by Kyle Simpson, creator of the LABjs script loader?  Firefox and Webkit browsers already have it implemented in their beta versions, and it looks like it could help significantly improve script loading performance in a clean, standards-friendly way.

  51. Jan says:

    When using an accelerator (like the default Google Maps), the adress bar is in edit mode after the Google Maps page has been loaded. This prevents zooming the map directly. This is also a problem for IE8, could you fix this please?

  52. Phil says:

    @Richard Maynard re:"Ha. I see the audio issue has been "fixed" by removing references to the Vorbis version from the source of Santa's Workshop and HTML5 Blizzard. What a delightful farce. You stay classy, Microsoft." – you didn't actually think that Microsoft was going to play fairly did you? Ha! Not likely!

    They've added support for the HTML5 and related features that were so badly missing but they specifically only added the ones they wanted and neglected the ones developers wanted (*cough* forms? geolocation?)

    In the case of Video and Audio, they only added basic support and specifically implemented filetypes that Firefox didn't use to ensure that TRUE HTML5 development across platforms wasn't actually possible. (think XBOX with the HD DVD drive… BlueRay was the obvious choice but MSFT would never back it because Sony PS3 was their direct competitor)

    Now in the tests above… MSFT deliberately didn't include the correct files to ensure x-browser compatibility because they thought it would "look better" if the other browsers couldn't even load the page.  Unfortunately this just threw egg in their face as they first had the tags in it to support other browsers and now they've removed them showing once again that ***Microsoft  is NOT committed to cross-browser HTML5 support*** – they intend, as always to ruin the web by only implementing half of the standards, and turning a blind eye to anything that doesn't directly make their browser look good.

    Well done MS! Try to put a positive PR spin on this blunder… I dare you!

  53. Mac says:

    @Phil: "…implementing half of the standards…"

    You may be under the impression that OGG Vorbis is part of HTML5. That is not the case.

  54. Stanley says:

    @Mac – @Phil wasn't saying that OGG Vorbis was a part of HTML5 – he was merely indicating that because IE only implements "parts" of specs they actually force the developer community to give up on using the full spec to its potential.

    For example in HTML5 there is full programatic read/write access to innerHTML for any element that can contain HTML markup.  Currently IE returns invalid HTML when using the getter and more importantly does not implement the setter at all for a variety of elements: TABLE, THEAD, TBODY, TFOOT, TR, SELECT, OPTGROUP, etc. – Therefore at the moment IE is SOLELY RESPONSIBLE for holding back development across the Web.

    As for supporting OGG Vorbis @Phil touches on why Microsoft has ignored implementing support for these as they are "open" technologies that don't allow for crippling DRM to ruin the user experience.

    The insult to injury is that the demos Microsoft made actually were planning to support all browsers (by providing all audio/video formats) but when they were informed that they hadn't finished it by uploading the alternative content they backtracked and removed the content that would support all browsers.  Shame on you Microsoft!

  55. Klimax says:

    Shame? None at all.

    They might have planned and then decided "not worth it". As for support in other browsers, there are open soure libraries. There are ways in majority of common OSes how to load them if they are installed without them being linked in thus no trouble with licences. (AFAIK:VfW,DirectShow,gstream,…) But then those vendors would have to want. And they don't want for ideological reasons…

    Standard doesn't specify,so MS takes safest route for it (already licensed with patents being cleared or part of lic.) Last time I checked there was awfull lot of sw patent lawsuits.

    MS didn't break anything. (there was nothing to break in the first place – so far) And if OGG (btw I like the format,but don't think its that important yet) or something becomes popular they can add support (unless submarine patents are in waiting…) as with WebM.

    Is there anything else you(all) wish to rant about?

  56. idadidas says:

    IE9 is still beta

  57. mmmmmm says:



  58. Klimax says:

    Nice real-world test for performance is http://store.steampowered.com/ . Unfortunately it reverts back tomorrow at 19:00 CET (GMT+1) . Seems that so far only IE8 is slow unlike IE9. (page animation should be smooth)

  59. Loow says:

    Internet Explorer 9 Release Candidate (RC) due on January 28

    Read more here: http://www.neowin.net/…/965266-internet-explorer-9-release-candidate-rc-due-on-january-28

  60. Loow says:

    Internet Explorer 9 Release Candidate (RC) due on January 28

    Read more here: http://www.neowin.net/…/965266-internet-explorer-9-release-candidate-rc-due-on-january-28

  61. Max says:

    The RSS feed address on your blog is wrong

  62. The Internet says:

    Please, if you really want to have a lasting and positive effect, just leave the browser market and delete all copies of IE world wide.

    Thanks in advance.

  63. Klimax says:

    @"The Internet" : Things would be much better if you would stop interfering with Real Internet and trolling.

    Many thangz.

  64. nicolas says:

    @Klimax you seem to miss the point about the broken web with innerHTML.  It is broken in IE and as long as it remains broken IE9 will absolutely ***NOT*** be HTML5 compliant in the slightest… never mind the missing form stuff and lack of geolocation just to name a few.

    Rumour above has IE9 RC due out at the end of January – if this is so that would be awesome I'd be very glad to see all the things fixed in the latest release to make it a decent browser.  For now, the Platform Preview 6 is NOT adequate enough for the next release as there are too many missing standards and far too many that are still broken.

  65. Klimax says:


    geolocation? For what??? I think you get it on WP7 port of IE. Not to mention it is not part of HTML5.

    Don't know about innerHTML. I'll checkout svn repo to see how it changed and how often – can be further guide to what we might see inΒ΄mplemented beside annouced stuff.

    But what I heard original extending innerHTML  is different from HTML5 which might be compatibility nightmare. (especially with sites still doing bad version check and declairing standard mode)

    BTW:What comment you responded? The one from 10:11 was more joking at troll then anything else…

  66. Don says:

    @klimax – GeoLocation is one of those HTML5 "related" technologies that just makes HTML5 an awesome leap forward from HTML4.  The fact that IE8 didn't support it and IE9 STILL doesn't support it is just sad and makes Microsoft look incompetent.  Its just like how IE is the only major browser in the market that doesn't come with a spell checker in 2011 – that's not just sad – that's a disgusting disgrace.

    I think what was being mentioned about the innerHTML is the fact that it has been broken in IE since it was first added and in HTML5 it is actually part of the specs thus now Microsoft's previous "omission" is now a serious infraction against the HTML5 specs.





    I don't know if internal builds of IE9 have got these issues fixed yet but quite simply IE9 can't legitimately go RTW and not undergo major criticism and dis-satisfaction from the developer community until these issues are resolved.


  67. Klimax says:

    Geolocation last time I checked is mostly useless on regular HW like desktop or notebooks (generally lack GPS or GSM/… for position determining) so IE9 won't need that.

    IE9-WP7 edition is completely different matter as there is at least one method for use.

    As for innerHTML-compatibility with pre-HTML5 otherwise standard compliant webpages using other things like CSS3,SVG and some other parts of HTML5 or ECSMAScript- how do you solve it?

  68. steve says:

    @Klimax: Geolocation works just fine on my laptop and pinpoints me perfectly at my house, my office, my local coffee shop and these airports (that I've tried so far) SFO, YYZ, DFW, EWR on both Chrome and Firefox.  If MS isn't willing to implement it then that's there failure and they'll have to live with the humiliation for the next 2 years.

    Keep in mind that the GeoLocation is also still helpful when precision is lower.  Knowing that the user is in "Dallas" or even "Texas" is still more helpful than not having a clue where in the entire world the user is located.

    I don't know about WP7 – does IE have it there? if so the port should be a piece of cake.

    I'm not sure where you are going with the pre-HTML5 comment regarding innerHTML.  Yes it was broken in IE since day 1, but fixing it in IE9 (even for non-standards mode) shouldn't be an issue because it didn't work before… thus there is no behavior to break… developers didn't use it before on Select and Table elements in IE6, IE7, & IE8 because IE didn't support it at all.  Even if you wanted to be insanely cautious you could have the correct implementation only apply to Standards-Mode thus making HTML5 actually possible.

    Otherwise CSS3, SVG, Canvas, ECMAScript, etc. have nothing to do with MSFT fixing their innerHTML. (the exception being that setting and getting innerHTML is called from JavaScript)

  69. steve says:

    er… I meant "their failure" (tail between legs)

  70. Jace says:


    How was innerHTML broken in IE since "day 1"?

    Microsoft is the inventor of the feature. They designed and implemented it as they chose at the time. Others implemented it and then extended it. If Microsoft had done the same with a similar feature, the ABMer would be up in arms screaming "Microsoft is extending _______!! :-O; they're going to break teh interwebz!!"

    Don't be shy now, tell me, how was it "broken in IE since day 1"? πŸ˜€

  71. steve says:

    @Jace – no problem.  When Microsoft implemented the feature (see here in a blog post by the actual MSFT developer (10years after) http://www.ericvasilik.com/…/code-karma.html )

    As he describes the issue when he himself is bitten by the bug.

    The initial implementation was a hack re-using a chunk of their HTML parser but it came at a cost of having built in limitations that would not allow it to "build" certain fragments of HTML that didn't contain the "entire" nesting. e.g. Table > Tr > Td.

    At the time 1996? (14+/- years ago) this wasn't a huge issue because well, it was new and thus making this setter only available on 90% of the elements was ok.  However over time, when all browsers implemented this, and HTML5 rolled it into the official specs since it made sense to… IE was left out in the cold with their partial implementation.

    As you can digest from Eric's notes – this bug is entirely due to the initial design, that *depends* on other broken code thus for any that say it "works as designed" they're fooling themselves… it actually "works as best as it can within the constraints of a broken implementation" πŸ˜€

    Now we can't blame Eric too much… since he has moved on from Microsoft moons ago however the fact that the IE Team over the last 14+/- years hasn't managed to fix this bug is beyond absurd even in Enterprise Software development timeline scale.

    I've talked with a few folks at Microsoft about this and its a sore spot for sure.  Not a bug they like to admit to, but one they regret has been way too slow in being fixed.

  72. gabrielmorrow says:


    any microsoft offical or any updates on microsofts view of this

  73. steve says:

    Growl!!! the spam filter on this blog is very, very, very annoying!

    It looks like the spam detectors on this blog really don't like hyperlinks! even if they all point to an HTTPS site in Microsoft's own list of sites.

    For the record, here's a few of the bug reports in MS Connect regarding IE's broken innerHTML issues: http://pastebin.com/cs4d1A0F

    hopefully just 1 link will be okay (it wasn't 2 minutes ago, but…) anyway it links to a few (16) different innerHTML bugs filed in Microsoft's Connect DB.

    Most are long standing issues, some are brand new to IE9.

    If this doesn't work I'm going to try a different username and or computer to get around the aggressive filtering.

  74. Klimax says:

    I forgot:

    "Otherwise CSS3, SVG, Canvas, ECMAScript, etc. have nothing to do with MSFT fixing their innerHTML. (the exception being that setting and getting innerHTML is called from JavaScript)"

    Sites might use old behaviour of innerHTML (without proper checking – altough one might hope situation will improve) and CSS3ECSMAScript(5?) together. Try to maintain compatibility with such site and introduce new innerHTML behaviour.

    I hope this is just theoretical thing and nowhere to be seen in practice,but last time I checked too many programmers/webdesigners/webprogrammers are lazy or whatever and such combination exists.

    P.S.:I already wrote one comment on geolocation, but it is nowhere to be seen…

  75. Klimax says:

    Geolocation – currently of same acuracy as IP address. At earlest better adoption of Sandy Bridge(AFAIK has 3G) or other integrated 3G devices.

    But then Compatibility/Upgrade Libraries like PIE will provide similar or same API. Good enough on desktop/notebook. AFAIK WP7-IE doesn't support GeoAPI.

    I would want first HTML5 itself and CSS3 and maybe IndexDB first, less usefull APIs later. And those APIs might be used throughplugins from MS Lab anyway. (Like Websocket/IndexDB)

    Anyway I read that link to Eric Vasilik and seems that what was true back then still remained true today. Backward compatibility… (most probably reason why we didn't heard about HTML5-innerHTML ; still didn't find/finished-testing good way for support of old-broken and new)

    (second try)

  76. the_dees says:

    Since we're speaking about innerHTML / a g a i n / …

    Can someone provide a testcase for this issue? webbugtrack.blogspot.com/…/bug-124-setting-innerhtml-problem-no1.html

    It is often quoted in discussions like this, but the tiny bits of code the website provides do not reproduce for me in any IE version.

    Also, innerHTML is being worked on. Currently, the only two elements it doesn't seem to work on are "html" and "head". Other elements, for example, title, table, select do work now, but are still very buggy.

    However, since work on the issue has begun, I'm pretty sure we'll see a greatly fixed innerHTML implementation in IE9.

  77. Joel says:

    Hi @the_dees I think that bug report you linked was actually fixed in IE8.  I don't have an IE6/IE7 environment handy to verify – I recall years ago encountering this bug so I know it existed.

    as for Table/Tilte/Select working now? well you must have a special build because the last platform preview I have still fails setting these.

    going back up a bit @Klimax I don't see where you are going with the backward compatibility? If a page currently tries to set the .innerHTML of a table in IE6-IE8 it will fail, the user will see nothing onscreen (even though the developer was hoping it would work)

    If IE9 actually supports it, then WooHoo! one less workaround needed to support IE9! As for backward compatibility there's no issue at all – it works!  If the page previously had a workaround for IE to build a DOM piece by piece instead – that would still work. Its a win-win bug fix.  The only "problem" one **might** claim (and this is super, duper weak) is that developers might expect this to work on all browsers all the time from now on.  Not being aware that they have to apply a hack to fix IE7/IE8 browsers to support it too.  However this argument is a horrible one that if taken basically says never upgrade anything ever… massive progress and bug fixes aren't worth minor differences in API's over time.

  78. Jace says:


    Built-in limitations don't equate to bugs. I don't disagree that Microsoft could improve the feature and update it to match what has now come to be a formal spec.

    Also, I actually read the article. You put some things in quotes in your reply that are not found in the article, in the same paragraph you start with "As you can digest from Eric's notes…"

    Are you quoting yourself?

    Aren't we in a position where other vendors improved upon and extended and Microsoft feature, and Microsoft has lagged behind and needs to address it to come to feature parity / full spec implementation?

    I don't see the need to paint things as something they are not/re-write history…


  79. Steve says:

    @Jace – Lets call a spade, a spade if you create a method to set the HTML of any element and it doesn't work on some your implementation is flawed. This isn't a case of "you have to do X before you do Y" odd implementation issue. Its a bug, has been declared a bug by everyone including Microsoft – and in HTML5 not supporting it will most definitely be a bug and IE9 will not be "HTML5 compliant".

    The "quotes" I used in my comments were "air quotes".  Microsoft's classic response to broken implementations for any API of any of their products is: "works as designed". (yes, those are both air quotes and actual quotes)  Saying something "works as designed" is a glorified cop-out for not accepting that a bug is a bug and that it should be fixed. We would all be much happier if they actually stood up and accepted the issue. e.g. "We agree this is a bug in our implementation – however at this time we don't plan to fix this in time to make it into the next release" would it such to read this? you bet, but it at least would be the truth.

    If you had an API method: Thing.addWheels(count); and the Thing subclasses "Car", "Truck", and "Boat" all had an implementation, but the "Boat" didn't actually add any I could accept it.  But the .innerHTML is plain and simple – MSFT just needs to fix it.

    Lets not forget that IE was the only browser that couldn't implement document.getElementById(id) correctly.  Even though the name of the method itself indicated EXACTLY what it was supposed to do.

  80. Jace says:


    Logic fail:

    "Its a bug, has been declared a bug by everyone including Microsoft" then you say:

    "We would all be much happier if they actually stood up and accepted the issue. e.g. "We agree this is a bug in our implementation…"

    Which is it?


    Classic snow-balling/kitchen-sinking arguments. "Lets not forget that IE was the only browser…" What does that have to do with the price of rice in China?

    I asked a very specific question, and watch you dance around the topic. Working as designed can be a cop-out, but you use it as a blanket straw-man where it doesn't fit. The article you linked to specifically explains how it is working as designed and that the design has limitations, period.

    Calling those limitations bugs does nothing other than gloss over facts.

  81. Steve says:

    @Jace not a logic failure. Separate statements with different context. "Its a bug, has been declared a bug by everyone including Microsoft" (other than a few people like yourself, everyone agrees this is a bug, including the MSFT employees I've communicated with and the guy who wrote the code)

    New context: "We would all be much happier if they actually stood up and accepted the issue. e.g. "We agree this is a bug in our implementation…"" – even though we (the development community) all agree it is a bug, and MSFT developers agree, the MS Connect Feedback channel (the only public facing bug-tracking MSFT has) declares all issues it doesn't want to fix (for whatever reason) as "works as designed" which is not a confirmation that it is a bug.  The "works as designed" is a bogus statement in itself because ALL code works as designed.  If I build a Hello World app that doesn't quote the string "Hello World" then my app will fail… but it "works as designed".

    I guess I would appreciate it if Microsoft changed their bug tracking to properly address bugs.  Each issue submitted first needs a flag indicating that the issue as described is "verified" as occurring (e.g. is reproducible).  Then it needs a flag indicating if the issue is a "bug" or a "misunderstanding", etc. e.g. the browser does do something weird, but you passed it a negative integer when it was expecting a positive index… don't do that.

    Then finally it needs a flag indicating what Microsoft's intentions are.  Are they "declining" the bug?, "prioritizing" it?, "accepting" it and targeting it for a given release?, or "postponing" it for a future release.

    Ok, now for what you call snow-balling.  I was merely trying to hammer home a point that this is not the first time that Microsoft has failed to implement something properly then turned around and claimed that it "works as designed". document.getElementById(id) is a classic case of how for multiple releases IE's version of this method did not match the published specs and it was not because the implementation was somehow unclear, ambiguous or needed additional options.  It wasn't until IE8 was released that IE fixed this properly to return the correct element every time (as long as you are in Standards Mode)

    You are correct though. You did ask me a specific (yes/no) question and I didn't answer it with a (yes/no) answer.

    Your question: Are you quoting yourself?

    My answer: No.

    My elaboration: I was using air quotes.

    To ensure that I correctly respond to your last note about how "limitations by design" (air quotes) are not bugs, here goes.

    Definition of "Software Bug" by Wikipedia: en.wikipedia.org/…/Software_bug

    "A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. "

    Does IE produce an incorrect or unexpected (error) or (fault)? YES

    Does IE behave in unintended ways? YES

    Are developers describing this as an (error), a (flaw), a (mistake), a (failure) or a (fault)? YES

    You can argue that **you** personally do not feel it is a bug all you want.  The jury of the "Developer Community at Large" (your peers) were convinced this was a bug years ago.  Failing to make a "global" property/method work on all the "things" it is supposed to is a bug.

    As for me I'm not going to play your Troll game anymore.  If you think that the current implementation of innerHTML in IE is great – perfect.  However if IE9 gets released and the (not-a-bug-according-to-you) isn't fixed, IT WILL BE A BUG IN HTML5 – without exception.

Comments are closed.

Skip to main content