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.
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:
<style>
#drawSurface {
-ms-touch-action: none; /* Disable touch behaviors, like pan and zoom */
}
</style>
<canvas id="drawSurface" width="500px" height="500px" style="border: 1px solid black;"></canvas>
<script>
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);
}
</script>
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:
<style>
#foo {
width: 500px;
height: 500px;
background-color: red;
-ms-touch-action: none; /* Disable touch behaviors, like pan and zoom */
}
</style>
<div id="foo"></div>
<script>
function handleEvent(event) {
// Change the color of the DIV based on the input device used
switch (event.pointerType) {
case event.MSPOINTER_TYPE_TOUCH:
event.target.style.backgroundColor = "blue"; // A touchscreen was used
break;
case event.MSPOINTER_TYPE_PEN:
event.target.style.backgroundColor = "green"; // A pen was used
break;
case event.MSPOINTER_TYPE_MOUSE:
event.target.style.backgroundColor = "yellow"; // A mouse was used
break;
}
}
document.getElementById("foo").addEventListener("MSPointerMove", handleEvent, false);
</script>
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:
<style>
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%;
}
</style>
<div id="foo"></div>
<script>
function handleEvent(event) {
event.target.style.msTransform = "scale(" + event.scale + ")";
}
document.getElementById("foo").addEventListener("MSGestureChange", handleEvent, false);
</script>
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
Anonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
Just wondering why the capital MS when other items used a lowercase ms.Anonymous
September 20, 2011
@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.Anonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
In the "Advanced gesture input" example you are missing the closing bracket for the html style.Anonymous
September 20, 2011
shame you didn't opt to use W3C Touch Events www.w3.org/.../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 optimisationsAnonymous
September 20, 2011
@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": dev.w3.org/.../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, element.style.msTransform, etc.
Anonymous
September 20, 2011
To avoid security problems, whether IE7/IE8/IE9/IE10 in TLS 1.2 support please.Anonymous
September 20, 2011
Can u explain the reason why u folks at Redmond decided to choose such a sh*tty blogging system?Anonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
The magic words 'Same code' are nowhere on this page.Anonymous
September 20, 2011
@Jacob Rossi[MSFT] > As for "MS" versus "ms", (...) > (...) > So, it's (...) element.style.msTransform, etc. Are you very sure about this? Just asking... I ask because when setting property value dynamically in Firefox 6.0.2: it's element.style.MozTransform Opera 11.51: it's element.style.OTransform Konqueror 4.7: it would definitely be element.style.KhtmlTransform if it was supported Safari 5.1 (not tested): it's element.style.webkitTransform according to //developer.apple.com/library/safari/#documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Transforms/Transforms.html%23//apple_ref/doc/uid/TP40008032-CH5-SW21 Gérard TalbotAnonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
I'm also wondering why you didn't use the W3C Touch Events?Anonymous
September 20, 2011
@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.Anonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
Will you guys have backwards compatibility for IE6??Anonymous
September 20, 2011
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 submissionAnonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
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.Anonymous
September 20, 2011
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!Anonymous
September 20, 2011
The comment has been removedAnonymous
September 20, 2011
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.Anonymous
September 21, 2011
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.Anonymous
September 21, 2011
Can anyone on earth tell me what does they want to prove with sweep feature's "Also block future messages" option in Hotmail windowslivehelp.com/thread.aspx ? What is the difference between blocking and ignoring in Hotmail?Anonymous
September 21, 2011
@Virtual PC - Check out a recent post on the Building Windows 8 blog about running the Windows Developer Preview in a virtual environment: blogs.msdn.com/.../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.Anonymous
September 21, 2011
The comment has been removedAnonymous
September 21, 2011
How unfortunate is that even the IE10dp is unable to render the SVG fonts with @font-face devfiles.myopera.com/.../SVGfonts_in_HTML.htmlAnonymous
September 21, 2011
Add support for .PNG favicon....Anonymous
September 21, 2011
I hacked Internet Explorer 9.. and windows 8 dev build I might release the source code in 31 daysAnonymous
September 22, 2011
@Mario Just put you png image in a .ICO container and it will work fine.Anonymous
September 22, 2011
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!Anonymous
September 22, 2011
@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: ://en.wikipedia.org/wiki/Favicon#File_format_support 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 TalbotAnonymous
September 22, 2011
Nice job guysAnonymous
September 22, 2011
I know, but all browsers support .ICO container files and have been doing so for ages.Anonymous
September 23, 2011
@Gérard Talbot, can you send me the link to the bug report you submitted on connect.microsoft.com? 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?Anonymous
September 23, 2011
@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)Anonymous
September 23, 2011
@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..Anonymous
September 23, 2011
When will be available ie10pp3 for win7?Anonymous
September 23, 2011
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.Anonymous
September 23, 2011
He is not friend because he is French.. sighAnonymous
September 23, 2011
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!Anonymous
September 23, 2011
The comment has been removedAnonymous
September 23, 2011
Please look into this bug report, and press "I can too" if you think its critical: connect.microsoft.com/.../v8-benchmark-and-ie10 @Dev-Team, please improve the performance and incorporate swifter RegEx engine in IE10.Anonymous
September 23, 2011
Please address the performance issues pertaining to the test suites cited in these bug reports:
- connect.microsoft.com/.../v8-benchmark-and-ie10
- connect.microsoft.com/.../a-dom-manipulation-test-ie-performance
Anonymous
September 24, 2011
@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.Anonymous
September 24, 2011
IETeam, please address the performance issues pertaining to the test suites cited in these bug reports:
- connect.microsoft.com/.../v8-benchmark-and-ie10
- connect.microsoft.com/.../a-dom-manipulation-test-ie-performance @steve_web, please click "I can too" on connect website. Thanks.
Anonymous
September 24, 2011
@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)?Anonymous
September 24, 2011
@Xero 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.Anonymous
September 25, 2011
The comment has been removedAnonymous
September 25, 2011
"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.Anonymous
September 25, 2011
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?Anonymous
September 25, 2011
Multilingual Web Addresses display in IE10, please (like Firefox, Opera) W3C Link: An Introduction to Multilingual Web Addresses - www.w3.org/.../idn-and-iriAnonymous
September 26, 2011
The comment has been removedAnonymous
September 26, 2011
@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: connect.microsoft.com/.../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)Anonymous
September 26, 2011
Internet Explorer on rocketsnail.com 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 imgsAnonymous
September 26, 2011
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..Anonymous
September 26, 2011
The comment has been removedAnonymous
September 26, 2011
The comment has been removedAnonymous
September 27, 2011
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.Anonymous
September 29, 2011
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?Anonymous
October 01, 2011
If you look into blogs.msdn.com/ie 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 windowsteamblog.com 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.