Re: Against touch events...

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
is.


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."

Cheers,
-Brian


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
>
>