Re: Events in SVG - chapter 13

Hello www-svg,

Charles wrote:

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

We accept that we did not have an activate event example, so we added
one right there:

<p id="ActivateExample">The following example shows the use
of an activate event to
      trigger an ECMAScript event handler:</p>

The example is one you wrote:

<?xml version="1.0" encoding="UTF-8"?>
<svg width="6cm" height="5cm" viewBox="0 0 600 500" xmlns="http://www.w3.org/2000/svg" version="1.2"
    baseProfile="tiny" xmlns:ev="http://www.w3.org/2001/xml-events">
    <desc>Example: invoke an ECMAScript function from an activate event </desc>
    <!-- ECMAScript to change the radius -->
    <script type="application/ecmascript">
        <![CDATA[
     function change(evt) {
       var circle = evt.target;
       var currentRadius = circle.getFloatTrait("r");
       if (currentRadius == 100)
         circle.setFloatTrait("r", currentRadius*2);
       else
         circle.setFloatTrait("r", currentRadius*0.5);
     }
   ]]>
    </script>
    <!-- Act on each activate event -->
    <circle cx="300" cy="225" r="100" fill="red">
        <handler type="application/ecmascript" ev:event="activate"> change(evt); </handler>
    </circle>
    <text x="300" y="480" font-family="Verdana" font-size="35" text-anchor="middle"> Activate the
        circle to change its size </text>
</svg>
    

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

Yes. We agree and have identified it more as the default. We also have a
note in the spec:

  Note: The W3C's Web Content Accessibility Guidelines (WCAG) advise
  content creators to create device-independent content; in particular,
  content should not require that the user has access to a pointer
  device.

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

We agree and have added text to that effect:

    <p>The <span class="element-name">'svg'</span> element in an SVG
    document fragment has attribute <span
    class="attr-name">zoomAndPan</span>, which takes the possible values
    of <em>disable</em> and <em>magnify</em>, with the default being
    <em>magnify</em>. This is intended for applications where SVG is
    used for both the content and for the user interface, eg a mapping
    application. The default zoom might move critical user interface
    components from view, confusing the user; disabling the default zoom
    and pan while providing zoom and pan controls for a smaller content
    area would give a better user experience.</p>

    <p>If <em>disable</em>, the user agent shall in its default
    interaction mode disable any magnification and panning controls and
    not allow the user to magnify or pan on the given document fragment.
    The user agent may provide another mode which continues to allow
    zoom and pan at user option.</p>

    <p>If <em>magnify</em>, in environments that support user
    interactivity, the user agent shall provide controls to allow the
    user to perform a "magnify" operation on the document fragment.</p>


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

We have changed this to say

  All renderable elements are required to be able to accept focus if
  specified by the author, including container elements (except 'defs'),
  graphics elements, 'tspan' and 'foreignObject'. A focusable container
  element may contain focusable descendants.

Please let us know very shortly if this response does not resolve your
comments.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 6 December 2005 02:33:24 UTC