Against touch events...

Hi,

this may seem like heresy, but...

TL;DR: We should be reluctant to include touch events, and the use cases  
for each touch event should be clearly specified and agreed as a minimum  
condition for that event being required.

Or in more detail...

Applications obviously need to be able to get user input. Different  
applications need different kinds of input. Currently, core-mob requires  
support for orientation events and touch events, presumably because it  
assumes that touchscreen devices are the relevant target although that  
assumption is not stated in the document anywhere. It doesn't require  
other kinds of input. But if this document is going to be taken seriously,  
it is encouraging application developers to rely on the things in ring-0,  
and therefore encouraging implementors to support those things.

As a browser maker who wants to ensure that web apps work on the browser  
wherever it is found, having touch events as an "agreed" part of the  
infrastructure means that we should expect developers to use them. Which  
means that when someone tries to use a "long-tail" app on the TV, it will  
fail unless the TV supports touch events (an app that isn't "long tail"  
probably has a working TV version - or at least will in a couple of years  
or so). If applications don't work, it is common to blame the browser. In  
any case, a rational user wants the application to work, whoever is "at  
fault". Either way, the clear incentive for the browser is to make the app  
work.

By "long tail app" I mean something that isn't made by a large company  
with top-quality developers and the ability to revise it twice a week, but  
something slapped together at minimal cost for a client who will not  
maintain it properly, but will nevertheless keep publishing it. (The same  
sort of app that should avoid using prefixed anything since they're  
breaking the assumption that is required for prefixing not to be harmful).  
There are a lot of these - the giants of the Web are probably not even a  
majority of content used (this is based on some research I am not at  
liberty to publish, and can be challenged, but I don't think it is  
sufficiently wrong to be irrelevant). So while this group is looking at  
what is needed to make the Web support the "100 most popular"  
applications, we need to be careful not to destroy the support of the  
millions of others it already supports.

Which brings me back to touch events. These are *slightly* different from  
mouse events which we already have on most smartphone platforms. For a  
very broad definition of smartphone that covers a lot of what is used in  
the real world, including the more limited base of Android/iOS we are  
working with here. The important question is whether they are different  
enough to justify asking for them to be everywhere.

I suggest that they aren't. Providing marginally different events that do  
almost the same thing is a poor approach to helping developers. We're  
encouraging them to complicate the platform they want to work on, by  
assuming touch events (only). This in turn means that browsers who think  
this exercise is worthwhile will have to implement touch events everywhere  
- and figure out what to do so the developers who don't also take into  
account mouse events don't set up compatibility problems with the  
developers who do assume mouse events exist (which is the vastly more  
common case).

As I stated at the beginning, the case for being able to handle input is  
pretty clear. The question is whether we are doing anyone real favours by  
promoting touch events as a core part of the platform, or whether the mess  
it makes in the overall web platform means we will be sorry if we get what  
we ask for.

Note that the same could also apply to orientation events - but in that  
case at least there is relatively little legacy problem where they will  
compete with and complicate some other well-established development  
technique.

(As an aside I am astounded, given the popularity of text for things like  
twitter, and passing messages and comments through various networks, not  
to mention more mundane things like document creation which are important  
for mobiles outside the "rich web" ("Rich Web Applications" was meant to  
refer to the capabilities they offered, not the entry price for users to  
play), that we don't require any text input capability, but I will write  
that up seperately.)

cheers

Chaals

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Monday, 23 April 2012 13:12:51 UTC