Touch Input for IE10 and Metro style Apps

The Web is more interactive, fun, and immersive when sites work well with new input devices and touch screens. The Windows Developer Preview introduces support for handling touch and pen input in your sites and apps. Developers can now ensure their sites work well with touch and build powerful new experiences that make the most of advanced input such as multi-touch and gestures. You can see this in action on the IE Test Drive site in the new and updated demos Touch Effects, Lasso Birds, and Flying Images.

Handling touch-first input without compromising mouse

“Windows 8” Metro style IE and applications bring a first-in-class touch experience to Windows and does so without sacrificing other forms of input. Developers can build sites and apps with that same touch-first experience.

This starts with basic input handling. In IE10 and Metro style apps, developers can write to a more abstract form of input, called a “Pointer.” A Pointer can be any point of contact on the screen made by a mouse cursor, pen, finger, or multiple fingers. This model makes it easy to write sites and apps that work well no matter what hardware the user has. Similar to our approach for hardware acceleration, the experience gets better with better hardware yet the APIs developers write to are hardware agnostic.

Pointer events encapsulate input from touch, pen, and mouse making it easy to build experiences that are hardware independent.
Pointer events encapsulate input from touch, pen, and mouse making it easy to build experiences that are hardware independent.

The events for capturing generic pointer input look a lot like those for mouse: MSPointerDown, MSPointerMove, MSPointerUp, MSPointerOver, MSPointerOut, etc.

Pointer events provide all the usual properties expected in mouse events (client X/Y coordinates, target element, button states, etc.) in addition to new properties for other forms of input: pressure, contact geometry, tilt, etc. So developers can easily write to pointer events and their apps just work no matter what input hardware is being used.

Sometimes, developers do want to provide different experiences for touch input. For that, pointer events also indicate the type of input (touch, pen, or mouse) via the event.pointerType property.

Here’s a primitive paint application slightly modified from that included in the Pointer and gesture events page:


#drawSurface {

-ms-touch-action: none; /* Disable touch behaviors, like pan and zoom */




<canvas id="drawSurface" width="500px" height="500px" style="border: 1px solid black;"></canvas>



var canvas = document.getElementById("drawSurface");

var context = canvas.getContext("2d");

context.fillStyle = "rgba(255, 0, 0, 0.5)";

canvas.addEventListener("MSPointerMove", paint, false);


function paint(event) {

context.fillRect(event.offsetX, event.offsetY, 5, 5);



By default, IE10 enables panning and zooming with touch. Sometimes, developers may want to manage panning and zooming in the site itself. In this example, we show how to handle the touch input in your site and not pan/zoom using the style rules overflow:hidden and –ms-content-zooming: none to do exactly that.

Built-in support for multi-touch

Down, moves, and ups fire for each touch contact. So applications like the above paint example support multitouch without any special code. On any pointer event, you can determine the type of device that produced the input:


#foo {

width: 500px;

height: 500px;

background-color: red;

-ms-touch-action: none; /* Disable touch behaviors, like pan and zoom */




<div id="foo"></div>



function handleEvent(event) {

// Change the color of the DIV based on the input device used

switch (event.pointerType) {

case event.MSPOINTER_TYPE_TOUCH: = "blue"; // A touchscreen was used


case event.MSPOINTER_TYPE_PEN: = "green"; // A pen was used


case event.MSPOINTER_TYPE_MOUSE: = "yellow"; // A mouse was used





document.getElementById("foo").addEventListener("MSPointerMove", handleEvent, false);


Advanced gesture input

The Windows Developer Preview also includes support for recognizing higher level gestures with pointers, such as scaling, panning, and rotating. Developers can easily take advantage of these using the MSGestureStart, MSGestureChange, and MSGestureEnd events. For each of these, information about the transform of the gesture is provided (rotation, scale, translation, etc.) that can be applied to your application in many ways, such as CSS Transforms:


html {

overflow: hidden;

-ms-content-zooming: none; /* Disable pan/zoom */


#foo {

background-color: red;

width: 500px;

height: 500px;

-ms-transform-origin: 50%;

-ms-transform-origin: 50%;




<div id=”foo”></div>



function handleEvent(event) { = “scale(“ + event.scale + “)”;



document.getElementById(“foo”).addEventListener(“MSGestureChange”, handleEvent, false);


Feature detection, fallback, and supporting other models

For code that is used across other platforms, IE10 offers simple feature detection for pointer events:

if (window.navigator.msPointerEnabled) {

// the system will fire pointer events


Note: in the current Windows Developer Preview, this property indicates the system supports pointer events for touch or pen input. However, at a future date it will be updated to indicate support for pointer events for mouse, pen, and touch.

Using feature detection, it’s possible to make sites that work well across different input models. Lasso Birds is an example that works well across the Windows 8 Developer Preview, Apple iOS, Google Android, and mouse-only systems. On Windows 8, it uses pointer events to handle all input in a single code path. On other platforms, it uses a combination of mouse events and proprietary touch events to deliver a similar experience.

if (window.navigator.msPointerEnabled) {

elm.addEventListener(“MSPointerDown”, handleInput, false); // Fires for touch, pen, and mouse

} else {

elm.addEventListener(“mousedown”, handleInput, false); // Fires for mouse only


Pointer and gesture events are just one part of our developer model for touch. We’ll talk more about our other touch APIs as well as how Lasso Birds works in future posts.

For more details on pointer events, gesture events, and other touch APIs check out the Pointer and gesture events page. We look forward to seeing the touch experiences you build, and welcome your feedback through Connect.

—Jacob Rossi, Program Manager, Internet Explorer

21 Sept 2012 – Updated code samples to reflect changes made in the IE10 RTM. —Ed.

Comments (62)

  1. Please Clarify says:

    You fully intend to strip out the "MS" prefix on those events before IE10 goes RTM – correct?

    We certainly do not want a repeat of IE-only JavaScript polluting the web with non-standard code.

  2. Peter says:

    Just wondering why the capital MS when other items used a lowercase ms.

  3. Randall says:

    @Please Clarify: I'm starting to think vendor prefixing is the wrong approach for experimental features, but it's going to take more than Microsoft to deal with that.  It's really not the vendor but the *version of the spec* that matters.  pointerEnabledV1 seems saner than msPointerEnabled/webkitPointerEnabled/etc.  If implementations of V1 of the spec differ accidentally, as they will, we're back to quirk detection or browser sniffing, but those are the wages of using not-yet-standard features.

    And I don't think I fully see why Microsoft diverged from the de-facto-standard Android/iOS model — they thought it badly designed?  Patented? — but at this point it's hard to care.  Libraries can paper over the difference; at least IE10 will have the feature.

  4. Gérard Talbot says:

    @Jacob Rossi [MSFT]

    If you aspire to have everyone to follow W3C web standards, then you would make sure your code is impeccable, truly valid, accessible and a model to follow. I suggest and propose to replace:

    <canvas id="drawSurface" width="500px" height="500px" style="border: 1px solid black;"></canvas>


    <canvas id="drawSurface" width="500" height="500" style="border: 1px solid black;">Browser does not support HTML5 Canvas.</canvas>

    width and height only take non-negative integer values; parsing errors will be resolved with width="300" and height="150"


    function handleEvent(event)

    There is a DOM 2 Event method with the same identifier

    I am not sure you can name (reuse the same identifier) a function like you're doing here. For sure, it is not recommendable.


    var currentPointers = event.getPointerList();

    Why not instead/rather



    var currentPointers = event.getPointerList();



    canvas.addEventListener("MSPointerMove", paint, false);

    Why not test, verify the support for such event type *before* registering the event listener?

    ———– = "scale(" + event.scale + ")";

    Are you sure such line should not be instead/rather = "scale(" + event.scale + ")";


    Gérard Talbot

  5. Levi Senft says:

    In the "Advanced gesture input" example you are missing the closing bracket for the html style.

  6. Patrick H. Lauke says:

    shame you didn't opt to use W3C Touch Events…/WD-touch-events-20110913 – unless this new invention of pointer events is to be seen as a super-set, and you'll still allow for authors to just listen out to individual input modalities to provide device-specific optimisations

  7. Jacob Rossi [MSFT] says:

    @Gérard Talbot, Peter, and Levi Senft – thanks for catching the code errors! We've corrected the width/height attributes and the missing brace.

    handleEvent() is not a restricted function name. Rather, it takes on special functionality when it is a property of an object passed as the listener to addEventListener (which is not the case here). DOM L3 Events has a better description of this under the definition of "listener":…/DOM3-Events.html.

    In the multi-touch example, we're just showing Pointer Events. Browsers that don't support pointer events will simply ignore the event registration. So there's no need to verify support. If you support pointer events + other events (mouse events or other models for touch), then you should be sure to feature detect as you suggest and as shown in the examples below it.

    As for "MS" versus "ms",  here's the basic rule of thumb for prefixed APIs in IE:

    * Events and interfaces take the form  MSPrefixedEventName. This is generally based off the way interfaces are named (e.g., HTMLElement). When we remove prefixes, they lose the "MS" and become lowercase like standards-based events.

    * DOM properties take the form "msPropertyName". This is generally based off the standard way properties and methods are throughout the dom (e.g., document.getElementById()).

    So, it's MSPointerDown,, etc.

  8. MyTime1969 says:

    To avoid security problems, whether IE7/IE8/IE9/IE10 in TLS 1.2 support please.

  9. Please Clarify says:

    Can u explain the reason why u folks at Redmond decided to choose such a sh*tty blogging system?

  10. @Patrick H. Lauke says:

    Nice catch !BUT! The freaking document on w3 was published by Opera on same day the IE10 development-preview was released. So be cool! :3)

  11. Same code says:

    The magic words 'Same code' are nowhere on this page.

  12. Gérard Talbot says:

    @Jacob Rossi[MSFT]

    > As for "MS" versus "ms",  (…)

    > (…)

    > So, it's (…), etc.

    Are you very sure about this? Just asking… I ask because when setting property value dynamically in

    Firefox 6.0.2: it's

    Opera 11.51: it's

    Konqueror 4.7: it would definitely be if it was supported

    Safari 5.1 (not tested): it's

    according to


    Gérard Talbot

  13. martensms says:

    I wanted to ask who the guy is that decides how your prefixing in IE/Trident works?

    CSS: MsTransform

    JS: msGestureEnabled

    JS (seems to be only Events): MSGestureChange

    … dude, WTF? Why U No prefix like WebKit and Gecko?

  14. Sindre says:

    I'm also wondering why you didn't use the W3C Touch Events?

  15. mbe says:

    @Sindre: It is an extremely recent working draft, IE10 was bound to have been far along in development and seeded to various partners long before it showed up. It also doesn't actually cover all the functionality that IE10 is offering here, so they would need to extend it either way. Luckily it should be a simple thing to make a very minimal wrapper which gives a W3C Touch Events style API on top of the things Microsoft is offering here.

  16. @Sindre says:

    because w3c sucks!

  17. Brendan says:

    Will you guys have backwards compatibility for IE6??

  18. Virtual PC says:

    So with all this exciting IE10 stuff going on, is there a Virtual PC image ready for us to download and try this out?

    I'd love to provide developer feedback and help find bug (as we know there will be some!) but I don't have a spare PC to install this on just for testing.

    PS Your blog software is still broken – this is my 3rd submission

  19. Virtual PC says:

    GRRR!!!! this is so annoying!… tell you what, here is the code (FREE OF CHARGE!) to fix this blog.

    <input type="submit" value="Post"/>

    Just add it for Pete's sake! – this blog has been broken since George W. Bush was inaugurated in Washington, D.C. for his second term as the 43rd President of the United States!

  20. @Virtual PC says:

    its due to the fact that MS want you to feel the PAIN, that they felt when Apple sold millions of the iProducts. Its the revenge from public. After seeing the progress made to improve the comment system over number of years, I can safely say that the responsible guys @MS are some sort of sociopath.

  21. Xero says:

    ASP.NET 4.5 MVC4  <– WOW. I learned about it during the BUILD 2011 conference.. Can you guys make a sample app with newer version of MVC framework; say "a blogging app"? Yes sure you can!

  22. Patrick H. Lauke says:

    "Nice catch !BUT! The freaking document on w3 was published by Opera on same day the IE10 development-preview was released. So be cool!"

    and the previous version (when it was still in development, still under the mantle of W3C though) was published…oh…aeons ago. so yeh, i'm cool 🙂

  23. deadmeat says:

    Thank you for inventing more useless proprietary APIs.

    In case you don't know, mouse events ARE pointer events which can be used and reused for any kind of pointing device.

  24. Gerben says:

    Is it possible to just use event.preventDefault to disable the panning and zooming? This would allow you for example to prevent padding and zooming only on a canvas element, but leave the rest of the page normal. I'm not a big fan of the CSS option, especially be cause it is more behavior than style.

  25. Xero says:

    Can anyone on earth tell me what does they want to prove with sweep feature's "Also block future messages" option in Hotmail ? What is the difference between blocking and ignoring in Hotmail?

  26. Jacob Rossi [MSFT] says:

    @Virtual PC – Check out a recent post on the Building Windows 8 blog about running the Windows Developer Preview in a virtual environment:…/running-windows-8-developer-preview-in-a-virtual-environment.aspx

    @deadmeat – Most touch supporting browsers (including IE9 and IE10) fire mouse events for touch input as well. This is so that the mouse-based web just works. However, writing to mouse events in order to support all types of input has one big limitation: they'll only fire for the first (primary) touch contact. There can be only one mouse on the screen; therefore for compatibility there can only be mouse events for one touch contact. Writing to pointer events allows you to build sites/apps that use your hardware to its fullest: providing compatibility with touch, pen, and mouse while enabling support for advanced input like multi-touch and gestures.

    @Gerben – Using CSS to declare whether you want panning/zooming is better for performance because the browser can know what it's going to do without executing JavaScript. That being said, the Windows Developer Preview includes support for an API called event.preventManipulation() which can be called on MSPointerDown or MSGestureInit in order to stop panning/zooming. This API is different from preventDefault(), because pointerdowns have other actions associated with them that you might not want to cancel as well.  However, we're evaluating feedback on this API so consider it experimental. Providing feedback via Connect is welcomed and listened to.

  27. Gérard Talbot says:


    we can read:

    function KeyPress(e) {

       var key;    

       if (e.keyCode) {

           key = e.keyCode;

       } else if (document.all) {

           key = e.keyCode;

       } else {

           key = e.charCode;


    The 1st else duplicates the controlled statement. At this point of the code, we may not know what "e" is: the created event object or global variable (it would require more time to verify).

    FYI, if a modifier key (Shift, Ctrl, Alt) key is pressed, then this should not fire a keypress event.


    does/relies on a lot of userAgent string detection/parsing … which is definitely not feature detection.


      // Parse UA string for browser name and version

      if (version = /MSIE (d+.d+)/.exec(navigator.userAgent))

    and so does



    and in

    function applyStyle(element, style)

    Opera (-o-) and Konqueror (-khtml-) were (intentionally?) left out. Why? The code excludes 2 browsers unneedlessly, unjustifiably IMO.

    Also, the last line, IMO, could be

                   if (! {

                       return false;


    and not

                   if (! {

              = "block";



    Prefixing global variables.

    I learned to prefix all my global variables with "gbl" many years ago; e.g. bgrCanvas would become gblBgrCanvas. It helps code review by others, code debugging, code maintenance to do so.


    In function gameLoop()

    innerHTML is inappropriately used. If no HTML code is generated and only an elaborated text is generated, then textContent is preferable.


    HTML 4 and HTML 5 button element (default type) is a submit button but all of IE demos wrongly assume they are command buttons, push buttons.


    <button class="controlbutton" onclick="start(1);">

    should be

    <button type="button" class="controlbutton" onclick="start(1);">


    With more time, I'm sure I could find more code and coding issues.

    Gérard Talbot

  28. @ieblog says:

    How unfortunate is that even the IE10dp is unable to render the SVG fonts with @font-face…/SVGfonts_in_HTML.html

  29. Mario says:

    Add support for .PNG favicon….

  30. Bowser says:

    I hacked Internet Explorer 9.. and windows 8 dev build I might release the source code in 31 days

  31. hAl says:


    Just put you png image in a .ICO container and it will work fine.

  32. MSLover says:

    Youtube says: "WebM Video for Microsoft Internet Explorer 9 (Beta)." just at the bottom of the video player, when rendering on IE9. It should essentially be "WebM Video (Beta) for Microsoft Internet Explorer 9." Sue those mfs on this one!

  33. Gérard Talbot says:

    @hAl and Mario

    PNG file format is an official W3C web standard. All other browsers (Firefox, Opera, Safari, Konqueror, Chrome, Hv3TKHTML, even Netscape 7.x) support PNG favicon:


    IE6, IE7, IE8, IE9 (and IE10?) are the only browsers not supporting <link rel="icon" …>

    I listed/mentioned both issues during the IE8 beta development.

    Gérard Talbot

  34. Jack Pulliam 3rd says:

    Nice job guys

  35. @gerard says:

    I know, but all browsers support .ICO container files and have been doing so for ages.

  36. Monitor says:

    @Gérard Talbot, can you send me the link to the bug report you submitted on

    Also, have you find anything *good* in Internet Explorer development? <- this is because I have observed you r just complaining throughout the journey of development and at no point in time you have appreciate the tons of changes they made available and there are area in which IE is surpassing the other browsers in terms of performance and standard compliance. Do you agree or are you JAFT?

  37. steve_web says:

    @Monitor – I too submitted bugs (during IE7 I believe) a bug regarding png favicon support and I've voted up many of Gérard's bugs when I've validated them as being issues. hAl, Gérard, myself and many others have provided tons of positive feedback as well as constructive criticism regarding bugs in IE.

    I'll confess I'm very happy with the progress thus far (there was a massive amount of bugs that needed fixing since IE6) however there are (as noted above) many, many more bugs that still need fixing.

    What "ticks us off" is when MSFT touts – "use web standards" etc. when IE fails to support many of them or is very, very slow to fix bugs (e.g. 10+ years to fix .innerHTML)

    However to be clear – MSFT has made massive improvements in IE and they are ALL much appreciated!

    (I am going to rant on one thing though – this blog software (particularly the constant failure to save comments!!!!) seriously needs to be fixed ASAP)

  38. Monitor says:

    @steve_web, I am also following up with the connect bug's reports and W3C standards and the development status of other browsers as well. Don't know why they were so lazy in 2007, but for 1 yr, they are complying with almost all the web standards. Almost all the w3c "proposed recommendation" standards have been worked on and also many from the "candidate recommendation". See the reason I can call you a troll is; you are bringing an out of the discussion thing and mixing with the actual matter. What this blog comment posting's short timeout (only when the user is not logged in) has to do with Internet Explorer and Trident development? Just be specific about issues.

    Similarly, if someone is sharing his experience about the good programming practices, you should be thankful. Rather than bashing them because at some website, someone from the same organization haven't used that convention? That's what Gérard is doing. You guys might be suggesting something very useful, but you seem like trolling rather discussing. Just chill, discuss, compare features and standard compliance among the browsers and don't troll. Otherwise, you can hangout on Engadget and similar places..

  39. hart says:

    When will be available ie10pp3 for win7?

  40. alvatrus says:

    It's hard for the French to admit someone has done a good job.

    Gerard has maintained a browser-bug website for years in which he (rightly so) bashes IE but, curiously since IE9, he and many others suddenly stopped pointing out the bug-lists in IE9.

  41. French joke says:

    He is not friend because he is French.. *sigh*

  42. Jesse says:

    Amen to that @hf35! Why the Windows 7 users are punished? Where there is no version of IE10's 3rd preview out? It's being 2 weeks now. Com'on guys. Bring it fast and get feedback from us and make the browser more delightful!

    Thank you for giving us wonderful product!

  43. MetroIE says:

    Please for the love of Almighty, provide us with MetroIE on windows7… Like we have Metro Zune app for PC 🙂

  44. Xero says:

    Please look into this bug report, and press "I can too" if you think its critical:…/v8-benchmark-and-ie10

    @Dev-Team, please improve the performance and incorporate swifter RegEx engine in IE10.

  45. Xero says:

    Please address the performance issues pertaining to the test suites cited in these bug reports:



  46. steve_web says:

    @Monitor – Gérard mentioned a bug that (although its been reported many times on Connect) gets no attention on connect because, well, as also discussed many times here on this blog Connect was a failure.

    The only place that does get attention is right here on the IE blog – and that's why all the bugs are discussed here.

    The problem is that this blog suffers from many of its own issues, the most important of which is that the #1 thing readers want to do on the blog is be able to post comments.  This #1 basic feature of Blogs is completely unreliable on the IE Blog.

    I don't think it is unreasonable to request that this 5 year old bug be fixed… when the fix is as simple as adding a regular HTML submit button, or switching to a blogging platform that actually works – more importantly I can't fathom why community Server hasn't fixed this issue, and pushed MSFT to update to the fixed version – or did they? and MSFT has just stalled on doing anything about it?

    Once again, this comment failed to post – if i hadn't saved it (because I knew the blog would lose it) I would be fuming again like so many others that try to post.

  47. Xero says:

    IETeam, please address the performance issues pertaining to the test suites cited in these bug reports:



    @steve_web, please click "I can too" on connect website. Thanks.

  48. Monitor says:

    @steve_web, incidentally can you send the link to the bug report that you reported on connect? Also, are you Gérard (think about it)?

  49. hAl says:


    Who careabout those issues on artificial performance tests.

    Real world performance of IE is already very good and excellent even on graphics rendering.

    Why bother with those artificial tests created by google which have litte to do with real world scenario's.

    I'd rather have voice control over the browser than 5ms faster rendering on real world pages.

  50. Xero says:

    @hAl, the trident and js engine backing IE10 would also be responsible for rendering those Metro apps which are built using HTML/Javascript. one the other blog, where they are introducing Windows8 and talking about the programming paradigm for desktop-based win8 apps would be supporting HTML5+CSS3 for the enterprise/commercial apps… most of the people would agree that DOM manipulation is one thing which should "atleast" be as efficient as other browsers (and which should NOT be "240 times" slower than safari), because when it comes to commercial apps, user requirements are considered subjective and what YOU considering is the "non-real-world" or "artificial" scenario, can be the very requirement of uncle Sam's metro app — Every real web and Windows 8 developer cares about the performance. There IS a workaround for it by using documentFragmentation (if you happen to know JS a little!), but since Safari execute the same JS code (without fragmentation) in 0.1second, Chorme run it in 0.3second, Firefox 0.8second and IE10 takes 44seconds! that IS a MAJOR difference due to the poor algorithmic implementation while handling those 'CORE JS Functions' in their JS engine; Chakra.

    Btw, what if they really fix this performance issue in beta or RC. Would you still think it's a lame fix? I beleive if person like you is managing a software product, for sure, it cannot be evolved.

  51. Xero says:

    "I'd rather have voice control over the browser than 5ms faster rendering on real world pages".

    My P.S.

    "I'd rather like to see both, the implementation of new standards like voice API AND improve the existing poorly implemented standards in the next build". Thats what guys like the_dees, Real McCoy, Fleet Command and many others are focusing on while submitting the feedback on connect.

  52. @Xero says:

    If the artificial benchmark tests contains 100 or 1000 more DOM manipulations than a Javascript heavy page it has no relation to real world performance. The specific tests you mention by Google and by a google employee likely highlight elements that chrome/webkit is very good in.

    Tests on IE testdirve show of elements that IE is very good in.

    So Xero, are you also on Chrome blogs asking google to match IE performance in IE testdrive performance tests?  

  53. Lewis Robinson says:

    Multilingual Web Addresses display in IE10, please (like Firefox, Opera)

    W3C Link: An Introduction to Multilingual Web Addresses –…/idn-and-iri

  54. @hAl says:

    First of all, you don't have any idea what you are talking about. Artificial benchmark? Are you kidding me?

    No, I don't visit Chrome blogs. I'm an enthusiast and niche user of Microsoft's technologies and products. Personally, I feel Chrome as a crippled (and half baked) browser. There are two tests I mentioned above submitted on the Connect website. One is V8 which is in fact developed by Google and the other one is stress performance test created by a JavaScript developer (not a Google employee). I don't know why you are mixing these two tests and thinking both are created by Google.…/a-dom-manipulation-test-ie-performance…/v8-benchmark-and-ie10

    The reason I mentioned v8 test is because it incorporates RegEx test and there is a significant room for improvement in IE as far as RegEx is concerned. The second one is a stress test for DOM manipulation via JavaScript.  So it's imperative to bring up live example where "REAL WORLD browsers" are performing significantly faster than IE.

    Again, it’s your ignorance to think of it as an artificial scenario. Browser being a most pervasive piece of software and layout-engine being multifaceted service of Windows OS, any kind of real-world scenario is possible and you are just worrying about 1000 iterations? If you ever bother to consider JS something more than validations of HTML form, you would never have said that..

  55. steve_web says:

    @Monitor – to provide you a link I actually went back into connect (had left for ages due to the system issues)

    Of course, the problem is that the 100's of bugs submitted during IE7 phase have all been removed – thus searching for the legacy issues is no longer possible.

    All of that hard work building test cases, examples and voting on bugs has been lost.

    Hence the reason why most developers have stopped using Connect – if you don't treat our input with respect, you won't get it in the future.

    I did manage to find my way back in to review IE8 bugs posted, but the only favicon related bug I could find was this one:…/ie-v8-0-favicon-ico-files-with-transparency-set-render-a-mask-color-pink-on-browser-tabs-where-they-should-be-clear

    There were some PNG bugs too, but those were mostly due to new bugs when scaling images (especially used as sprites)

    (and no, I'm not hAl, I'm definitely me)

  56. Mario says:

    Internet Explorer on the owner of the site told me he has it set to no border in the css but the image still shows the border around it in IE9.. add support for no border in CSS  or just take away support for the border around the imgs

  57. @steve_web says:

    Remember! A troll will always be a troll no matter what kind of treat you offer them..

    Congratulations! the bug which was submitted 39 months ago, and on the basis of which you are trolling against Microsoft and Internet Explorer team as a whole, was fixed — just — 38 months ago. Yes you are not hAl, you are a loser a troll! just saying..

  58. UN Observer says:

    You guys are a bunch of whining jerks.  Got to get out of your Mom's basedment once in a while and learn some social skils.

  59. CSSFriend says:

    Yeah my friend had images set to no borders in the CSS and Internet Explorer showed a border around the images..  My details about my operating system and laptop brand are listed below if that is helpful.

    Brand: Acer

    Operating System: Windows 7 64-bit

    Internet Explorer version: Internet Explorer 9 with all the updates

    Plugins in IE9: Flash, silverlight, windows media player plugin, etc.

    installed addons: None.

  60. steve_web says:

    Thanks Mr. "@steve_web" for trolling so well! Since you have trouble reading, let me help you.

    1.) "searching for the legacy issues is no longer possible" – as in, you can't find those bugs because MSFT has removed all access to them.

    2.) "but the only favicon related bug I could find was this one" – as in, guess what I couldn't find the bug, because it is no longer searchable.

    By definition an Internet Troll only posts to stir up trouble – that I am not, I want the blog to be fixed so we can post property (which is very important considering that Connect doesn't work).  Yes many of the comments on the IE blog are not on topic, but that's likely because there is never a post called: "Hey, guess what, .innerHTML has been broken for years – let us know how many times you've needed to fix production issues due to IE bugs like this one!"

    I'll confess like many on this blog I will comment or complain about the most annoying bugs – that's how the world works… lots of people complain about how bad Vista was… and surprise surprise most of it got fixed in the patch known as "Windows 7"… folks complain enough about iPhone antenna issues… and tada bumpers become free for the device… IE is better because MSFT got serious about fixing the browser, listening to developers and users complain about what was broken and needed fixing.

    As I'm sure I have stated (and have others) if MSFT wants to push out a public bug tracking system that is NOT Connect we'll be more than happy to post bug reports there.

    And yes, this was not my first attempt to post – because well, the IE Blog commenting is broken – maybe after a few hundred more reports someone will step in and insert an input[type=submit] button into the page and fix this blog once and for all.

  61. Rory says:

    What was wrong with the existing touchstart/end/move events?

    I thought you had a new-found commitment to standards, where is the evidence of that?

  62. Feedback from @steve_web on behalf of steve_web to Telligent or Microsoft blog support says:

    If you look into and after 20-30 minutes if u try to post a comment as a guest user (without login) and hit post button, the page will refresh instantly without posting the comment and there is no way to get it back. I guess there is some timeout issue with page postback. Please look into it and rehash the code on both domains. This behavior is independent of the vender and version of browser. Just wait for couple of minutes (say it took you 30 minutes to read the entire post and all the comments) and then post a comment as anonymous…

    OAN, with Windows Team Blog on IE10 dev preview (on Windows8 dev preview), with Browser Mode Internet Explorer 10 (page default on load!) the login session doesn't persist. To reproduce this bug, open in IE10, click Sign in link at top right corner, provide credentials and click sign in button. On the next page the website wouldn't recognize your session. As a workaround, press F12 change the "browser mode" to IE9 and the page will refresh with your handle and SignOut button at the top right corner. Like IE-Team suggested in the good programing practices that we need to check for the feature in browser rather than the vendor and version of user-agent, it seems like some code requires attention. Please forward the bug report to IE team, if the issue is with IE10.

    Please fix these issue.