- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 11 Mar 2010 14:15:10 -0800
- To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
- CC: Doug Schepers <schepers@w3.org>, public-webapps@w3.org
Here's a round-up of public apis: Mozilla Gesture API (targeting DOM): https://developer.mozilla.org/En/DOM/Mouse_gesture_events Wacom Pen API (targeting MXML/ActionScript): http://mini-developer.wacom.eu/DevGuide.mvc/ShowArticles/1/0 Apple Multi-Touch API (targeting HTML 5): http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html Both Apple and Wacom put forward useful HTML attributes: "ontouch* ongesture*" from Apple, "onpen*" from Wacom. Mozilla introduces a some properties and implementation examples, Apple introduces a Mouse Event bundle and Wacom introduces a device API. Mouse events have several easily accessible flags to work with (ctrl, shift, and a button int). The gestures proposed in these public APIs are quite generic, they can be implemented with standard mouse wheel events. They are already compatible: current browsers can use any one of these APIs, with any number of input hardware and combination: be it keyboard-only, limited mouse, or a touch screen, provided they support attachEvent or addEventListener and event dispatching. Not covered in the above is glyph recognition. I recommend an "onglyph*" event object. Some pertinent event paths include: keypress/keydown, and onchange form events and the dataTransfer interface, copy/paste. These event attributes are well defined and publicized: touch, gesture, pen, glyph, They improve web accessibility standards and their presence does not disrupt non-supporting applications. SULLIVAN, BRYAN L (ATTCINW) wrote: > OK, I agree, let's see a draft horse first, then later we can decide if it was worth dressing it up for the cart. > > On the main (or more useful) point perhaps, I think the distinction between a device's internal features, its peripherals as attached features, and more abstracted (even remote) resources is still very blurry between Webapps and DAP. For example, DAP is considering whether to represent device API's (called "device" here only because in some instances the resource provider might be local to the device) using an abstracted RESTful model ("Powerbox") that I have asserted fits better in the Web API work in Webapps, because it's more aligned with the RESTful model of remote resource access over HTTP. And here we have consideration of screen input and mouse events, which are resources of the host device, at least when attached to it. > > I'd like to see some clearer distinction between the charters on these points. > > Thanks, > Bryan Sullivan | AT&T > > -----Original Message----- > From: Doug Schepers [mailto:schepers@w3.org] > Sent: Thursday, March 04, 2010 7:08 AM > To: SULLIVAN, BRYAN L (ATTCINW) > Cc: Charles Pritchard; public-webapps@w3.org > Subject: Re: Event handlers - Pointer Devices > > Hi, Bryan- > > SULLIVAN, BRYAN L (ATTCINW) wrote (on 3/4/10 9:15 AM): > >> This might be better discussed by the DAP group, as it's clearly a >> "device API" topic. >> > > By that definition, a mouse would be a device. :) This work belongs in > the WebApps WG, and it is explicitly mentioned in our charter, to be > taken up during our next charter period. > > DAP is not focused on user-input devices, more on things like cameras, > calendars, etc. available on the local device. > > > >> Also it would be interesting to hear from Apple and Wacom (without >> unnecessary details at this point), what areas of touch interface >> capabilities would be problematic for W3C to create API's for, from an >> IPR perspective (i.e. that would probably result in exclusions)... this >> concern is driven e.g. by the current touch-related issue between Apple >> and HTC. >> > > This is putting the cart before the horse. It's not appropriate to > discuss IPR at this point, since we don't even have a draft spec (by > design). Once we have a draft of the spec, participants who have IPR > can have their legal team look at it and chime in at that point (though > this may take place in Member space, since they may wish to do so under > the legal framework of W3C Member confidentiality). > > I am concerned that it may not be fruitful, and may be > counterproductive, for us to start speculating on this list about IPR. > Let's keep the discussion on technical matters, please. > > However, use cases and requirements would be appropriate to discuss, and > this should help frame a successful outcome for this spec. > > [1] http://www.w3.org/2009/05/DeviceAPICharter > > Regards- > -Doug Schepers > W3C Team Contact, SVG and WebApps WGs >
Received on Thursday, 11 March 2010 22:16:45 UTC