[ink] InkML, DOM3 Events, and SVG

Hi, InkML WG-

I'm very interested in exploring how InkML can work with other 
technologies in the W3C, particularly the ones commonly implemented in 
multiple browsers.

As you know, SVG is becoming more widely implemented, and I could see a 
formulation of InkML as a set of namespaced attributes in a subset of 
SVG, which would leverage implementation momentum, authoring tools, and 
user familiarity.  It would be rendered in SVG-capable UAs just as 
normal SVG.

But a more meaningful way for InkML to be implemented in desktop 
browsers is for the browser to support the InkML-specific events 
("channels") themselves, in real-time.  Perhaps the way forward here is 
to integrate some aspects of InkML into a new specification that is 
DOM-centric, or to put them into a future version of DOM itself?

One of the more obvious ways to do this is to simply recast certain 
channels as events types and their attributes (for the purposes of 
realtime DOM interaction in this proposed spec).  For example, there 
would be 'penup' and 'pendown' (and possibly 'penmove') event types. 
These would be modeled on MouseEvents, and would derive from them.  The 
existing Mouse event types are 'click', 'dblclick', 'mousedown', 
'mouseup', 'mouseover', 'mousemove', and 'mouseout'.

The behavior of the 'pendown' event type seems most analogous to the 
'mouseover' event type, though it seems it can also be 'mousedown', 
'click', or 'dblclick' in some contexts.

The 'penup' event type doesn't seems to have a direct match, though it 
would effectively fire a 'mouseout' event.  What other behavior would be 
expected?  Perhaps 'mouseup', when the 'pendown' event took on the 
aspect of 'mousedown' or 'click'?

The 'penmove' event type seems to map directly to the 'mousemove' event 
type; I don't personally see much value in reduplicating that event 
type, and would suggest that we simply use 'mousemove' instead.

In DOM3 Events, the MouseEvent has the attributes 'screenX', 'screenY', 
'clientX', 'clientY', 'ctrlKey', 'shiftKey', 'altKey', 'metaKey', 
'button', and 'relatedTarget'; to these, we could add 'force' and the 
various aspects of 'pentilt' (that's a little more troublesome, since it 
seems to have a complex type).  These would, by necessity, be attributes 
on all Mouse events, even those that aren't the result of a pen/tablet 
input device.

The 'brushchange' stuff strikes me as better dealt with as a custom 
event, since it would depend more directly on the composing environment. 
  Not all devices, not all applications, and not all 'host languages' 
will have this functionality, and it may mean different things in 
different contexts.  But this is just my initial reaction.  I don't know 
how likely it is for browser implementors to want such an event, while I 
see a much more clear story for the other event types and attributes.

The question would then become, how applicable would these events be to 
the InkML spec (and its implementors and users) and to the EMMA 
framework?  How can we minimize the risk of future incompatibilities? 
We'll have to talk a bit more about this to make sure that we would be 
making a compatible model with the InkML spec.

I think there is a compelling case to be made for pen/tablet input in 
browsers, since almost every laptop has a potential input device... the 
touchpad.  I realize that not each of these has the full complement of 
"ink" functionality (pressure sensitivity, for example), but some of 
them will.  And, of course, there are all the Wacom tablets and the like 
(I have one myself).

I look forward to hearing your feedback.

[1] http://www.w3.org/TR/DOM-Level-3-Events

Regards- -Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Thursday, 17 January 2008 11:14:25 UTC