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

Re: Against touch events...

From: Brian Blakely <anewpage.media@gmail.com>
Date: Mon, 23 Apr 2012 10:32:44 -0400
Message-ID: <CAJGQg4FSvbztBHX8GQKj5u=L2vcK1TdUd8LSVjg=iaL47u8Byg@mail.gmail.com>
To: Charles McCathieNevile <chaals@opera.com>
Cc: "public-coremob@w3.org" <public-coremob@w3.org>
Hi Charles,

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

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

As an aside, the Web is famously terrible at interacting with hardware.
 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.

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


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
Received on Monday, 23 April 2012 14:33:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:45 UTC