Yep, apparently it's solely the new MS touch/pointer API which is missing. Which is kinda weird considering they submitted their pointer API to the W3C as an alternative to Apple's touch events, it's not going to help their case if they don't bother implementing it themselves.
I guess their own API changed between Windows 7 and 8. After all, Touch was more of an afterthought than a really integrated feature of the OS in Windows 7 and they're too lazy to backport the Pointer API to Windows 7's API.
They did, but the Pointer API is a browser API, not an OS API (supposedly anyway, since they proposed it for W3C standardization), and one of its purported advantages over the current standard (Apple's touch events) is that they're "pointer-agnostic" so instead of having mouse events, touch events, and some sort of hack to back-support mouse events on touch devices, it's all supposed to mostly work on all devices.
So they should be able to implement their API on win7, since they're suggesting others can (and should) do it on pretty much every OS out there.
There aren't a lot of Windows 7 touch devices, and the ones that do exist have proprietary drivers since Win7 doesn't support touch. It doesn't make sense for Microsoft to spend a lot of time back-porting the whole touch system to Win7 and then pleading with OEMs to provide touch drivers there as well. Even assuming they were able to do both of those successfully, you'd be stuck using touch with Win7 desktop apps unless they back-ported Metro to Win7 as well.
Doesn't make a lot of sense once you write it all out.
Windows 8 has a new set of touch APIs (including on desktop). The Windows 7 touch APIs are still there for compatibility. They'd have to either port the web touch stuff to the old native APIs or port the new native touch APIs to Windows 7, and I guess there's not enough Windows 7 touch interest to bother.
> There aren't a lot of Windows 7 touch devices, and the ones that do exist have proprietary drivers since Win7 doesn't support touch.
The problem with this explanation is that the purported advantage of the Pointer API over apple's touch API is it being "pointer-agnostic", it's supposed to unify mouse, fingers, stylus, etc... events into a single coherent one. So implementing it on non-touch devices (which isn't the case of Win7 anyway) would very much support its integration.
IE10 behaviour differs between Windows 8 Metro and Desktop. If you're on metro, websites that use flash for certain things (e.g., our web site uses it for image zoom, video and audio file previews.) We have to submit to Microsoft for whitelisting, or more hopefully we can finally convince our business to let us switch to HTML5 but that will require reprocessing hundreds of thousands of videos and audio files that are huge.
FYI Flash no longer needs videos in an FLV container. If you use h.264 video in an MP4 container that can be directly played by Flash, Internet Explorer, Chrome, Safari, Android, and iOS. You still may have to reprocess legacy videos but going forward you wont have to maintain different versions of videos depending on platform if you use an MP4 container and h.264 video.
13 comments
[ 4.0 ms ] story [ 45.7 ms ] threadSo they should be able to implement their API on win7, since they're suggesting others can (and should) do it on pretty much every OS out there.
Doesn't make a lot of sense once you write it all out.
The problem with this explanation is that the purported advantage of the Pointer API over apple's touch API is it being "pointer-agnostic", it's supposed to unify mouse, fingers, stylus, etc... events into a single coherent one. So implementing it on non-touch devices (which isn't the case of Win7 anyway) would very much support its integration.