Events in SVG - chapter 13

[note on re-send: as will Will's comments, please consider this 
material, it reflects a shared concern
of the PF WG but has not been discussed in detail.  _Mea culpa_ that 
this got left out of the
"collected comments."  -Al ]

-- original from Chaals:

I think this needs a major kick.

Although they have the activate event, I couldn't find any mmention 
of it in the discussion and examples. I think that we should object 
strongly to the current chapter as is.

The following big extract is, I think, problematics.

[[[

13.3 User interface events

On user agents which support interactivity, it is common for authors 
to define SVG documents such that they are responsive to user 
interface events. Among the set of possible user events are pointer 
events, keyboard events, and document events.

In response to user interface (UI) events, the author might start an 
animation, perform a hyperlink to another Web page, highlight part of 
the document (e.g. change the color of the graphics elements which 
are under the pointer), initiate a "roll-over" (e.g., cause some 
previously hidden graphics elements to appear near the pointer) or 
launch a script which communicates with a remote database.

For all UI event-related features defined as part of the SVG language 
via XML Events or animation, the event model corresponds to the event 
bubbling model described in DOM2 [DOM2-EVBUBBLE]. The event capture 
model from DOM2 is not supported.

13.4 Pointer events

User interface events that occur because of user actions performed on 
a pointer device are called pointer events.

Many systems support pointer devices such as a mouse or trackball. On 
systems which use a mouse, pointer events consist of actions such as 
mouse movements and mouse clicks. On systems with a different pointer 
device, the pointing device often emulates the behavior of the mouse 
by providing a mechanism for equivalent user actions, such as a 
button to press which is equivalent to a mouse click.

]]]

Many pointer devices do not behave in the same way as a mouse - in 
particular small devices often do NOT have a cursor which can be 
moved randomly around the screen, either relying on an element by 
element navigation, or a pen-type device which is inactive except 
when it is directly placed on an element. In particular this means 
that the concept of rollovers, common in HTML where people are 
expected to be moving around with either the mouse  or the keyboard, 
is a lot less useful and so is a poor example.

Neither a pen, nor a voice activation system, have and obvious 
equivalent to mousedown, and these things are handled in different 
ways according to the functionality required.

The activate event should be more clearly identified as the event 
triggered by mouse clicks, pen taps, etc, as  a default.

in the same chapter, 13.7 "Magnifying and Panning" includes

[[[
The 'svg' element in an SVG document fragment has attribute 
zoomAndPan, which takes the possible values of disable and magnify, 
with the default being magnify.

If disable, the user agent shall disable any magnification and 
panning controls and not allow the user to magnify or pan on the 
given document fragment.
]]]

This should include a note that some user agents and some system 
software (such as Opera, Mac Operating systems, and the X Window 
system) allows magnification and panning for accessibility reasons, 
and these must not be disabled. (Which makes me question the point of 
the section...)

Finally, there is the question of navigating around "active elements"

[[[
13.8.1 The focusable attribute

In many cases, such as text editing, the user is required to place 
focus on a particular element, ensuring that input events, such as 
keyboard input, are sent to that element.

All renderable elements can be focusable, including both container 
elements and graphics elements,. It is possible for a focusable 
container element to have focusable descendants.
]]]

The first and second paragraphs simply do not go well together. And 
the first paragraph does not fit with accessibility. Focusable should 
be applied to any event that has interactive behaviour, and it should 
be automatically on (according to the rules used - elements which 
have display:none are, sensibly, unable to receive focus), allowing 
users to navigate to all such elements.

Cheers

Chaals

-- 
Charles McCathieNevile                              chaals@opera.com
          hablo español - je parle français - jeg lærer norsk
   Here's one we prepared earlier:   http://www.opera.com/download

Received on Saturday, 28 May 2005 16:18:55 UTC