W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: Against touch events...

From: Charles McCathieNevile <chaals@opera.com>
Date: Mon, 23 Apr 2012 21:32:49 +0200
To: "Brian Blakely" <anewpage.media@gmail.com>
Cc: "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <op.wc8gkzwawxe0ny@widsith-3.local>
On Mon, 23 Apr 2012 16:32:44 +0200, Brian Blakely  
<anewpage.media@gmail.com> wrote:

> Hi Charles,
>
> Because Level 0 paints a picture of the mainstream mobile web today, it's
> probably a good idea to include touch events.

I think that would make sense if they are necessary. I am struggling to  
find the case where they are though, and hoping somone can actually  
explain it. Otherwise I don't think we are doing ourselves, or the web, a  
favour by insisting on them given that mouse events are already so heavily  
baked into the infrastructure and requirements.

> The glaring omission here is *mouse events*.  In regards to a long-tail  
> app (new phrase to me; kudos), unconventional UAs on hardware without a
> mouse have long-included a "virtual" cursor and keyboard to be  
> compatible.
>  Therefore, applications that support mice are safe, and we need to make
> sure that new implementors don't omit these events – however unlikely  
> that is.

Right.

> As an aside, the Web is famously terrible at interacting with hardware.

Yes.

>  Just as camera/microphone and gamepad support should, by all rights,  
> have been commonplace in UAs since 2006, the modern Web will probably
> still be scrambling to support eye-twitch events for wearable displays
> for years after they go widespread.

No doubt. Unless someone figures out that basically you can map them to  
existing events, and that allows people to go right on using their apps on  
the new hardware.

> The rule of thumb on hardware APIs should be "take everything you can  
> get."

No, IMHO the rule should be "don't use it if you can get away with it". Or  
as TimBL used to say "use the least powerful tool that will do the job,  
because it is likely to be far more reusable, more compatible, and  
probably better maintained".

cheers

> On Mon, Apr 23, 2012 at 9:12 AM, Charles McCathieNevile  
> <chaals@opera.com>wrote:
>
>> 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
>>
>>


-- 
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 19:33:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC