Pointer Events and Cornerstone

[Scott Poulin]

From an email conversation with Chris Hafey (creator of this terrific library).

Given some of the issues with touch devices and IE that folks are experiencing, one possibility is replacing Cornerstone's current mouse/touch implementation using Hammer.js with pointer events. There seems to be some momentum in this regard, given that Google has donated its work to date on a polyfill to the jQuery foundation, meaning it may make it into a future version of jQuery, with https://github.com/jquery/PEP available in the meantime.  There is also https://handjs.codeplex.com/, which seems to have better browser support (IE9 specifically), and doesn't require the touch-action attribute. It would certainly make the whole library's event handling a lot easier to manage.

There's a possibility that I might be able to take some of that effort on, but wanted to get the community's feeling on which route to go for the polyfill, until such time as browser support is more or less universal.

Thanks!

[Chris Hafey]

A few things:
1) I am still a little confused about what the IE11 issue is.  I am using standard jQuery events which should work with IE11.  I can't imagine Microsoft breaking that for any reason.  The examples also work fine for me on Win7/IE11 so something doesn't seem right

2) A few months back I decided to add jQuery as a dependency since everyone knows/uses it and I am hoping it can provide an abstraction over any browser specific issues.  At the time, my main browser specific issue was custom events (IE does something weird), but this pointer/mouse event issue is another example of something I am hoping jQuery will fix for us.  I know that google submitted the pointer event polyfill to jQuery, but I am not sure what the status is (integrated, separate or ?).  Hopefully they will integrate it into jQuery core so we can use it by simply upgrading to the latest version.

3) Cornerstone is designed to support different input mechanisms.  We can add a pointer even input source and allow users of the library to use it instead of the mouse input one if they want.  So we don't have to replace, just add.

4) I have mixed feelings on adding support for IE9.  On one hand, I am fairly certain it is possible to support it without too much work and I know that would allow cornerstone to be used on more systems today.  On the other hand, I would rather not have to keep testing/support IE9 since it may not be relevant too much longer.  Upgrading from IE9 to a newer version of IE seems to be fairly painless (unlike going from IE7/IE8 to IE9 was) and many people are rolling out IE11 today.  IE 10+ is considered an evergreen browser which means it will automatically update itself.  By not supporting IE9, we can just focus on making sure cornerstone works with the latest and greatest browser versions which should keep the code cleaner and also allow us to use newer features.

Chris

[Scott Poulin]

Finally getting back to this...

1. I looked at http://rawgit.com/chafey/cornerstoneTools/master/examples/allImageTools/index.html in IE11 and indeed it does work.  The difference I see is that it's not using Hammer.  I'm gonna try using the tools etc. versions from that page, with no Hammer, and see where I end up.  Will update in the next week or so.

2 & 3. So maybe pointer events aren't necessary at all... assuming Cornerstone can see a touchstart as a clck, the only really 'touchy' thing that would be nice to have (that I can think of right now) is pinch zooming.

4. Agree 1000%.  I only mentioned it because there are a couple large hospital organizations near me that are still officially using IE8 (!).  I guess if the doctors start complaining because they can't use cool web techologies they might be incented to finally upgrade.

[Chris Hafey]

Regarding IE8, please see the cornerstone FAQ:

Why does this library require HTML5 canvas when IE8 is the main browser used in healthcare?

The fact that IE8 is the most popular commonly used web browser in healthcare right now is a temporary situation. It is expected that 50% of the industry will have HTML5 based web browsers deployed by the end of 2015 and 90% by 2017. The library made a tradeoff to focus on the future platform to keep the code base simple and avoid compromises related to older browser technology. Note that it may be possible to get this library to work on IE8 using excanvas but I haven't tried it yet.

[Scott Poulin]

Here's what I found so far with regards IE 11 (and I suppose 10 but haven't tried it yet):

If you remove touch events, I think cornerstoneTools.touchInput.enable(), then all the tools work in IE, but then you lose touch devices.  The mouse event handlers don't deal with touch events at all (which I guess makes sense).

With touch support, the drawing tools (ellipse, rectangle, angle, point sample) don't work in IE.  Those same tools don't seem to work in touch devices regardless.

Will dig in more when I'm able.