#16175 closed enhancement (fixed)
Windows Phone 8 support
Reported by: | Eric Durocher | Owned by: | Eric Durocher |
---|---|---|---|
Priority: | high | Milestone: | 1.9 |
Component: | DojoX Mobile | Version: | 1.8.1 |
Keywords: | Cc: | cjolif, bill, Evan, dylan | |
Blocked By: | Blocking: |
Description
Dojo Mobile must support Windows Phone 8 devices. This includes making the necessary tests/fixes in the code, and a new theme.
Attachments (30)
Change History (113)
comment:1 Changed 8 years ago by
Milestone: | tbd → 1.9 |
---|
comment:2 Changed 8 years ago by
Priority: | undecided → high |
---|---|
Type: | defect → enhancement |
comment:3 Changed 8 years ago by
comment:4 Changed 8 years ago by
Yes, absolutely, this ticket represents several subtasks, mainly:
- abstract webkit-specific code into more general CSS3 code (CSS3 property names, different gradient syntaxes, etc)
- abstract touch support to include the new IE10 pointer event handling
- new WP8 theme
For now work has started on item 1.
comment:5 Changed 8 years ago by
This patch (big one! in 3 parts) essentially implements task 1: Dojo Mobile does not run any more in "compat" mode on IE10, instead it uses the browser's support for CSS3 properties (transforms, transitions, animations, etc). This includes:
- code refactoring to replace all occurrences of webkitXyz prefixed properties in the code by calls to a new _css3 module that adds the right prefix (webkit, or nothing on IE10).
- other code refactorings, mainly support for rounded corner masks that use -webkitMaskImage on webkit which has not equivalent in IE10 (I used SVG shapes for this).
- refactoring of all themes CSS to include both -webkit- prefixed and non-prefixed versions of CSS3 properties. This is done using LESS: the new common/css3.less file contains the LESS functions that insert both variants, and (almost) all existing -webkit- properties in the CSS have been replaced by these calls. Some CSS files that were not generated by LESS also had -webkit- properties (common/domButtons and common/transitions), so new LESS files have been added for these.
- The css3.less file also has functions to generate the different gradient syntaxes between webkit and IE10.
Note that I used LESS 1.4.0 to generate the CSS, because I needed the percentage function which was not supported in the version of LESS that was previously used. This explains some formatting differences in the resulting CSS that are not directly related to my changes (mainly newlines between multiple classes in selectors, and "black" replaced by "#000000"). Also, the indentation of .css files in common/domButtons and common/transitions has changed because they are now generated.
Of course the CSS are now bigger because they contain webkit and IE10 variants of properties. I compared the built (i.e. all CSS concatenated) versions of iphone.css and android.css, the size increase is roughly from 100k to 130k. I think this is still acceptable, but we could also document how to regenerate the CSS without IE10 support for users who want to optimize the themes for webkit only (or for IE10 only). For this, we could provide webkit-only and IE10-only versions of css3.less.
comment:6 Changed 8 years ago by
Updated scrollable.js with support for keyframes (different methods to manipulate rules on IE).
comment:7 Changed 8 years ago by
Looks like a good improvement.
Can you put those dojox/mobile/sniff changes into dojo/sniff instead? They apply to desktop too.
Where is this _css3.js module? Seems like you forgot it from the patch?
Also, out of curiousity, what is the less % feature that you are talking about?
comment:8 Changed 8 years ago by
Thanks for the feedback.
Yes there is another ticket (#15827) to merge dojox/mobile/sniff into dojo/sniff, but I will do that other one separately to avoid mixing things up...
dojox/mobile/_css3.js is the first file in part3 of the patch.
The percent function converts e.g. a 0.5 value into "50%", useful to generate different gradient syntaxes: webkit uses 0..1 positions for color stops, whereas IE10 use percent values (maybe clearer to look at css3.less for examples...)
comment:9 Changed 8 years ago by
I agree that merging dojox/mobile/sniff into dojo/sniff is a separate task. But, about the new has() flags you are adding: "css3" and "svg": They don't belong in dojox/mobile/sniff, or dojo/sniff either, since they are about features, not about sniffing which browser the user is running. Probably, dojo/has.js is the right place.
Actually, I don't understand what the "css3" flag is supposed to mean. Each modern browser has varying levels of support for CSS3 (see http://css3test.com/), so how can you have a boolean flag that says that CSS3 is/isn't supported? Also, it's disappointing to see that supposed feature test based on browser version instead of a true feature test.
About _css3.js, it's fragile how you are determining the CSS property names. As time goes on, webkit will start supporting standard names and later desupport the -webkit prefix. This may be on a property by property basis, rather than all at once. So I think it's best to do the tests like kgf did in [30098] to determine each property name, rather than making assumptions based on the browser.
As a side note, all of this name mapping should really be handled in dojo/dom-style, so that instead of doing:
elem.style[css3.name("transform")] = "translate3d(0px,1px,0px)";
you could do:
domStyle.set(elem, "transform", "translate3d(0px,1px,0px)")
I guess that's outside the scope of this patch though.
comment:10 Changed 8 years ago by
Cc: | cjolif added |
---|
comment:11 Changed 8 years ago by
Bill I understand your comments. I agree that has("css3") is not a good name, it was just something easy and short for now. What that means really is has("enough-css3-support-for-dojox-mobile"): transitions and animations mainly. I am not sure this should go to dojo/has since I don't think this is something that can be useful to other modules. Has("svg") could go there though (if useful).
About feature testing (both on what is actually supported and prefixes), I agree in principle, I'll look into this. I am not sure though that it is feasible/reasonable to feature-test everything (do we really want code that waits for a transition to be performed or not?).
comment:12 Changed 8 years ago by
OK, I thought for feature testing it would just be checking if a certain attribute exists ("transition" in node.style or something like that). I certainly agree you don't want a feature test that actually does an animation.
comment:13 Changed 8 years ago by
PS: http://perfectionkills.com/feature-testing-css-properties/ or http://modernizr.com/docs/ may be useful for inspiration.
comment:14 Changed 8 years ago by
New version of the patch taking into account Bill's comments:
- dojox/mobile/_css3.js now does feature testing rather than just has("wekbit"). Note that only the 'webkit' prefix is tested as explained in the comment, but this is indeed cleaner and can be extended if necessary.
- dojox/mobile/sniff.js now also tests CSS3 animation support using feature testing, and the has flag is renamed into has("css3-animations").
comment:15 Changed 8 years ago by
_css3 module should probably be moved to dojox/css3 to benefit to dojox/css3/transition as well which should also be upgraded to work on IE10. See #16497.
Changed 8 years ago by
Attachment: | mobile_ie10_css_part1.patch added |
---|
First patch: support for IE10 CSS properties (ie. non -webkit- prefixed) - part 1/3 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | mobile_ie10_css_part2.patch added |
---|
First patch: support for IE10 CSS properties (ie. non -webkit- prefixed) - part 2/3 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | mobile_ie10_css_part3.patch added |
---|
First patch: support for IE10 CSS properties (ie. non -webkit- prefixed) - part 3/3 - Eric Durocher (IBM, CCLA)
comment:16 Changed 8 years ago by
New patch:
- resolved conflicts due to recent commits (bidi)
- fixed typo in some CSS (wekbit->webkit)
- code optimizations in _css3.js (thanks bill)
Changed 8 years ago by
Attachment: | mobile_ie10_pageTurningUtils.patch added |
---|
IE10 support for pageTurningUtils - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | css3.js.patch added |
---|
Fix for non-CSS3 browsers - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | mobile_ie10_ToolBarButton.patch added |
---|
Fixed bug in ToolBarButton? on IE < 10 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | mobile_ie10_IconContainer_misc.patch added |
---|
More CSS related changes for IconContainer? + others - Eric Durocher (IBM, CCLA)
comment:31 Changed 8 years ago by
When applying mobile_ie10_IconContainer_misc.patch, the following file must deleted: dojox/mobile/themes/common/IconContainer_keyframes.css
comment:32 follow-up: 33 Changed 8 years ago by
Cc: | bill Evan dylan added |
---|
Uploaded a first patch for IE10 touch support. This has not been tested yet on an actual touch device, so not ready for commit yet, but this is a first opportunity for feedback. The patch contains the following changes:
- Extend the has("touch") test by testing navigator.msMaxTouchPoints as recommended here: http://msdn.microsoft.com/en-us/library/ie/hh673557%28v=vs.85%29.aspx#Feature_detection.
- Make sure all touch event listeners in dojox/mobile are added using the dojo/touch module. This was mostly the case already, there were just a few code pieces that used e.g. has("touch")?"touchstart":"mousedown", they have been replaced by touch.press etc. Note that some places used "touchmove" instead of touch.move on purpose, because of the slight differences between touch.move and the native "touchmove", more details below.
- Enhanced dojo/touch.js to support the new MSPointer* events fired by IE10. The basic idea is: if MSPointer events are supported (detected using navigator.msPointerEnabled), then we connect to them (regardless of whether the device is touch-enabled or not), otherwise we do as before, i.e. connect to either mouse or touch, depending on has("touch"). This is consistent with MS's approach to unify mouse and touch events.
- The code in the first if(hasTouch){...} test should not be necessary with MSPointer, since MSPointerOver and MSPointerOut events are fired natively. Also, the synthetic touch.move event is not needed since MSPointerMove events are always fired with a target set to the node that is under the finger/pointer (unless the pointer has been captured). Of course all this has to be confirmed on an actual touch device.
- I added a new touch.moveNative event type. The existing touch.move had the drawback that stopPropagation() does not work because the event is actually listened to on the document. Some dojox/mobile code needs stopPropagation() to work for move events (and target is not used), so touch.moveNative can be used instead in thoses cases. I hope the doc explains the differences clearly enough.
- Finally updated the test_touch.html test case (which fires explicit "touchstart" etc events, must fire MSPointerDown etc. events instead on IE10).
This works for mouse events in IE10 on a Windows 8 desktop virtual machine, where navigator.msPointerEnabled is true (but without touch support -> navigator.msMaxTouchPoints is undefined). MSPointer events are actually fired and correctly handled for mouse events. This should be a good start given MS's claim that mouse and touch events should be handled in a unified way, but of course the next step is to run this on a touch-enabled device (either simulated or an actual phone/tablet), no doubt more problems will arise...
Feedback very welcome!
comment:33 follow-up: 34 Changed 8 years ago by
Replying to edurocher:
Uploaded a first patch for IE10 touch support. This has not been tested yet on an actual touch device, so not ready for commit yet, but this is a first opportunity for feedback.
Thanks for working on that, it's definitely an important feature. It looks like your patch was done before my recent touch.js check in though? I can't apply it cleanly.
The patch contains the following changes:
- Extend the has("touch") test by testing navigator.msMaxTouchPoints as recommended here: http://msdn.microsoft.com/en-us/library/ie/hh673557%28v=vs.85%29.aspx#Feature_detection.
Actually, I already checked in that change under a different ticket.
- Enhanced dojo/touch.js to support the new MSPointer* events fired by IE10. The basic idea is: if MSPointer events are supported (detected using navigator.msPointerEnabled), then we connect to them (regardless of whether the device is touch-enabled or not), otherwise we do as before, i.e. connect to either mouse or touch, depending on has("touch"). This is consistent with MS's approach to unify mouse and touch events.
Makes sense. When I read about Microsoft's model I was impressed, because it seems like they did it the right way, i.e. they natively solved the problem that dojo.touch is trying to solve. So in other words, I think the modifications to dojo.touch that you are describing make sense.
- The code in the first if(hasTouch){...} test should not be necessary with MSPointer, since MSPointerOver and MSPointerOut events are fired natively. Also, the synthetic touch.move event is not needed since MSPointerMove events are always fired with a target set to the node that is under the finger/pointer (unless the pointer has been captured). Of course all this has to be confirmed on an actual touch device.
Agreed. (Again, compliments to Microsoft.)
- I added a new touch.moveNative event type. The existing touch.move had the drawback that stopPropagation() does not work because the event is actually listened to on the document. Some dojox/mobile code needs stopPropagation() to work for move events (and target is not used), so touch.moveNative can be used instead in thoses cases. I hope the doc explains the differences clearly enough.
Interesting. I didn't expect anyone to be calling stopPropagation() or preventDefault() on touch.move/"touchmove"/"mousemove", but I apparently I was wrong. Given this revelation, maybe we should just fix touch.move to work "right":
If (for webkit environments) we replace
on(win.doc, "touchmove", function(evt){ ... } );
with
win.doc.addEventListener("touchmove", function(evt){ // all the old code ... // fire synthetic touchmove event on the correct node on.emit(newNode, "dojotouchmove", ...); }, true);
and then rewrite touch.move as a listener on dojotouchmove, similar to how we listen to dojotouchover etc.?
We should test to make sure that it's not too slow, since it doubles the number of events.
comment:34 Changed 8 years ago by
Replying to bill:
It looks like your patch was done before my recent touch.js check in though? I can't apply it cleanly.
Right... I just uploaded a new version of the patch based on this morning's trunk.
But, I don't think your patch to support both mouse and touch works well unfortunately, I already had reports saying that some dojox/mobile widgets now fire events twice. It seems that the "more than 30ms later" test is not robust enough (you use the current date so it will depend on how long the touch handler takes to execute right? Plus, I am afraid the delay varies a lot among devices...) I will attach a simple test case.
- Extend the has("touch") test[...]
Actually, I already checked in that change under a different ticket.
OK, the new patch does not modify dojo/has any more.
About touch.move/touch.moveNative, yes that might be a solution... I am keeping as is for now, let's sort the problem above first maybe?
Changed 8 years ago by
Attachment: | test_clicks.html added |
---|
Test case for duplicate clicks, put in dojox/mobile/tests and run on a touch device.
comment:35 Changed 8 years ago by
I see. Would it be enough to change the limit to (for example) 500ms?
comment:39 Changed 8 years ago by
FYI, I filed #16624 so we can hopefully get this _css3.js functionality rolled into dojo/dom-style.
comment:41 Changed 8 years ago by
@edurocher - Are you/Christophe going to check in mobile_ie10_touch.patch? Or should I do it? I'd like to get it in so we can do #16438.
comment:42 Changed 8 years ago by
@bill, I could finally test touch events on a WP8 emulator and did some changes, mainly adding msTouchAction: none styles to some widgets to prevent browser scrolling. There are still problems with the mobile Slider widget, I am working on this but I don't expect this will impact dojo/touch.js so we can commit this and I will do another patch for Slider.
comment:43 Changed 8 years ago by
OK. Oh, I forgot, the only thing is that I'm skeptical moveNative belongs in dojo/touch, since the dojo/touch module is for normalizing behavior across all browsers. I think it makes sense to refactor has touch.move works, so that you can call stopPropogation(), and actually it may be faster than before. I'll attach a modified version of your patch, see if it works for you.
Changed 8 years ago by
Attachment: | stoppableTouchMove.patch added |
---|
rearchitect touch.move so you can call stopPropgation(). but i'm not getting a lot of touch.move events on iPad, not sure why.
comment:44 follow-up: 45 Changed 8 years ago by
I think you don't see a lot of moves because you fire dojotouchmove only if the hoveredNode has changed. If you move the emit call outside of the test it works better.
I am still verifying that this works when preventDefault() is called.
comment:45 Changed 8 years ago by
Replying to edurocher:
I think you don't see a lot of moves because you fire dojotouchmove only if the hoveredNode has changed. If you move the emit call outside of the test it works better.
Ah thanks, of course you are right.
I am still verifying that this works when preventDefault() is called.
Well I wasn't expecting preventDefault() to work; I thought you needed stopPropagation() to work (see comment:33). Maybe the synthetic event could have a preventDefault() method that called evt.preventDefault() on the native touchmove event, but I don't know if that would work or not.
comment:46 Changed 8 years ago by
Yes sorry I did mean stopPropagation(), not preventDefault()... ;) Anyway it works with your patch, once corrected as in the comment above. Maybe we could add the preventDefault redirection too, but I do not reproduce any problem without it.
Changed 8 years ago by
Attachment: | stoppableTouchMove.2.patch added |
---|
MSPointer support in dojo/touch + rearchitect touch.move so you can call stopPropgation() (fixed) - bill+ Eric Durocher (IBM, CCLA)
comment:47 Changed 8 years ago by
OK so I attached new versions of the patches:
- mobile_ie10_touch.patch now contains only dojox/mobile changes for IE10 touch support,
- stoppableTouchMove.2.patch contains MSPointer support + bill's new stoppable touch.move implementation + my fixes (emit dojotouchmove even is target did not change, extra comma removed from test).
comment:48 Changed 8 years ago by
Thanks. But now that I think about it, don't we need preventDefault() to work in order to stop page scrolling while doing DnD etc.?
comment:49 Changed 8 years ago by
It seems that preventing the initial touchstart is usually enough to stop page scrolling, but I would not swear this works on all mobile browsers uniformly, so yes it may be safer to redirect preventDefault.
Changed 8 years ago by
Attachment: | mobile_ie10_touch.patch added |
---|
MSPointer (unified mouse/touch) support for IE10 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | IconContainer_css_holodark.patch added |
---|
Forgot to regenerate the holodark IconContainer?.css in previous IconContainer? patch - Eric Durocher (IBM, CCLA)
comment:53 Changed 8 years ago by
Status: | new → assigned |
---|
Changed 8 years ago by
Attachment: | ie10_click.patch added |
---|
Fix error when clicking in scrollable views or Switch widgets on IE10 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | ie10_EditableListMixin.patch added |
---|
Fix item dragging in editable lsits on IE10 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | ie10-mobile-gallery.patch added |
---|
Augment or adapt mobileGallery CSS for IE10 - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | sniff_windowsphone.patch added |
---|
Windows Phone detection in dojo/sniff - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | WindowsThemeForDojoPatches.zip added |
---|
Windows Phone theme patches for Dojo. Includes patch for DojoX (+ requied images) and patch for Mobile Gallery demo
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileJS.patch added |
---|
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileCSS.patch added |
---|
Changed 8 years ago by
Attachment: | WindowsThemeImages.zip added |
---|
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileTests.patch added |
---|
Changed 8 years ago by
Attachment: | WindowsThemeForDojoMobileGalleryDemo.patch added |
---|
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileJS.2.patch added |
---|
Original patch by Sergey Grebnov, minor changes by Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | mobileGalery_buttons_css.patch added |
---|
Mobile gallery: fix selected state of back button in "Shapes" tab of Buttons view - Eric Durocher (IBM, CCLA)
Changed 8 years ago by
Attachment: | viewportSizeFix.patch added |
---|
Viewport size fix to solve unwanted zoom on some WP8 phones (Lumia 920) - Adrian Vasiliu (IBM, CCLA)
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileIssueFixes.patch added |
---|
Sergey Grebnov (CLA)
comment:69 Changed 8 years ago by
WindowsThemeForDojoXMobileIssueFixes.patch fixes the following
- test_DatePicker.html: DatePicker? is cropped in portrait
- test_EdgeToEdgeList-editable-sv.html: The heading overlap the list when scrolling
- test_GridLayout-2cols.html and others: Clipped on the right
- test_Slider.html: removed background image for vertical slider knob
- Custom SpinWheel?: “separator” slots do not appear at all, or appear as a gray bar
- Date Spinner: the invalid days (such as Feb 30 etc.) show-up ungrayed.
- dijit/Calendar: selected items are not visible
- Heading: Letters such as ‘g’ and ‘y’ are clipped at the bottom.
- ToggleButton?: the delay between switching from 'selected' to 'checked' state
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileDOHTestFixes.patch added |
---|
Fixes Windows measurement issues. Sergey Grebnov (CLA)
comment:70 Changed 8 years ago by
Hi Sergey, Thanks again for these patches. Concerning WindowsThemeForDojoXMobileDOHTestFixes.patch: in most tests, when some measurements are different for IE10 than IE9, this is correctly handled by introducing a distinct <value>IE10 variable. With one exception: dojox/mobile/tests/doh/button/ButtonTests.html where the values of BUTTON_WIDTH_IE and BUTTON_HEIGHT_IE have been modified to match IE10 thus now breaking the test (with WindowsPhone theme) on IE9. Just tell whether you fix it or we should fix it on our side.
comment:71 Changed 8 years ago by
Hi Adrian, actually I modified existing BUTTON_WIDTH_IE and BUTTON_HEIGHT_IE variables deliberately because they previously had the same value as non-IE default value (BUTTON_HEIGHT, BUTTON_WIDTH), so I thought they could be used to store IE10 specific values, and standard values will work for IE9. Also I tested this case in IE10 in IE9 compatibility mode and the test passed successfully. But if I missed something and it breaks the test on a real IE9, I think it would be faster if you modify the test by yourselves.
BTW. WP theme officially supports IE10 only so I'm not sure we should test it on IE9.
comment:72 follow-up: 73 Changed 8 years ago by
Okay, I'll do the adjustment, no problem. In my test on the real IE9 it did fail. (Update: in the meantime I realized that for some reason my IE ran in quirks doc mode. In IE9 doc mode it doesn't fail... Sorry. However this is still puzzling me, because in the past we had 100% success on IE9, I guess in IE9 doc mode... and now it still succeeds despite the values that have been modified... Anyway...)
As far as know, the idea is that we only support IE10 officially, but as long as it doesn't cost much to get something work in other browsers, it is welcome.
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileFontSizeReducing.patch added |
---|
Reduces theme font sizes. Sergey Grebnov (CLA)
comment:75 Changed 8 years ago by
About the above commit: it corresponds to the merge of Sergey's last three patches (thanks!), with a few minor formatting changes plus a style rule removed from ScrollablePane.css/less as a quick fix for a regression found at testing.
Changed 8 years ago by
Attachment: | WindowsThemeForDojoXMobileIssueFixesPart2.patch added |
---|
Sergey Grebnov (CLA)
comment:78 Changed 8 years ago by
WindowsThemeForDojoXMobileIssueFixesPart2.patch fixes the following
- ToggleButton?: the checked mark still appears initially, and stays for ever while the background correctly switches from white to black and vice-versa when touching the toggle.
- test_Slider.html: the label “20” at the right side of the horiz. slider is partially covered by the slider
- test_Opener-ActionSheet?-async.html: The opener layout is totally broken.
- test_Calendar-lazy-prog.html: The cancel button is too small (text clipped).
- test_Opener-ColorPalette?(-lazy).html: The last line of colors is smaller than others.
- test_Opener_RoundSelectList-async.html: List items overlap the Done button.
- test_Overlay.html: Broken rendering.
- test_ScrollablePane-demo.html: Clipped on the right.
- test_SimpleDialog.html: Radio buttons are not correctly highlighted when selected.
- test_SwapView-demo.html: Clipped on the right.
- test_Switch.html: Bad layout but switches are correct.
- test_ValuePicker-1slot.html: Text is clipped on the right.
- test_Accordion-demo.html: In “Fixed’” mode, the “Dojo” panel is rendered outside of the rounded white border and it’s text content is not visible. If the “Dojo” panel is not the one selected, its title is also below the white border. The content of the “ScrollableView?” panel is not rendered with a left margin of padding and a white vertical line on the left as the other panels. In “Multi” and “Single” mode, the text content of the “Dojo” panel is not visible, and the content of the “ScrollableView?” panel is not rendered with a left margin of padding and a white vertical line on the left as the other panels.
Changed 8 years ago by
Attachment: | ImprovedFixForComboBoxOnW7.patch added |
---|
The fix improves the test of MSGesture support for ComboBox? control. Sergey Grebnov (CLA)
comment:83 Changed 8 years ago by
(In the meantime, the patch above has been transferred to #17157).
I've been asked a few times about this. Do we have a plan in place for this? Adding support for touch and gesture events looks like we'll need to work through http://msdn.microsoft.com/en-us/library/ie/jj553857%28v=vs.85%29.aspx at a minimum.