[webkit-dev] pointer events specification - first editors draft

[Maciej Stachowiak]

On Nov 28, 2012, at 8:23 AM, Adam Barth <abarth at webkit.org> wrote:

> It looks like this thread got dropped over Thanksgiving.  (Responses inline.)
> 
> On Thu, Nov 22, 2012 at 1:43 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
>> On Wed, Nov 21, 2012 at 2:42 PM, Rick Byers <rbyers at chromium.org> wrote:
>>> Outside of the design details, are there any thoughts or concerns
>>> about WebKit getting an implementation of pointer events at some
>>> point?
>> 
>> In my opinion, the pointer events spec is a bad idea (at least, in its
>> current state). I think adding it to WebKit would be hurting both the Web
>> and WebKit.
>> 
>> The premise of the specification is that using mouse event and touch events
>> interchangeably is needed. In reality, nobody was really asking for that
>> because it is a terrible idea. You can already easily unify pen, touch and
>> mouse by writing very little JavaScript, but it is only useful in very few
>> cases.
>> 
>> For the common case, where you want to use touch and mouse events
>> differently, the pointer events makes it harder to write correct code. Each
>> event have a set of attributes with different meaning depending on the event
>> type.

I agree with Benjamin's technical concerns about this feature. Combining the very different models of touch and mouse is a bad idea. They are distinct and for anything beyond the trivial, you really need to treat them separately to get a good outcome. The basic premise of pointer events seems to be over-abstraction at the expense of the user experience.

> 
> I'm sympathetic to these concerns, but, unfortunately, I don't see any
> other path that leads to interoperability with Internet Explorer.

In principle, other things being equal, interop with IE would be better than not having it. But other things are not equal. Their proposal is technically unsound.

Further, I do not much of a pragmatic interop concern in this case. IE is so far not very relevant on device classes that generally feature touch UI[*]:
<http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0&qpcustomd=1>. The trajectory of Microsoft's touch-oriented OS efforts does not seem likely to change this trend in the near future.

Clearly Microsoft has looked at this data and decided interop with other browsers in this area is not very important to them, relative to other goals. That's so even with a significant disadvantage in market share and deployed content in the relevant addressable market. Given that, why should IE's interoperability be more important to us than it apparently is to Microsoft?

In conclusion, I do not think interop with IE is more important here than technically correct design. I'd say interop trumps sound design only when there is a mass of deployed content backing up the interoperability need.

Regards,
Maciej


[*] I know that Windows for desktop/laptop machines also supports touchscreens, and some hardware that's primarily meant for keyboard-and-mouse type traditional input also features a touchscreen as a potential extra source of input. But from what I can discern, this is more a neat gimmick than something that is truly compelling to users or something that Web developers are rushing to take advantage of. Content that is specialized for touch UIs is overwhelmingly authors for Android and/or iOS. If I'm wrong on that, then I'd like to see some actual data to the contrary.