SVG content can be interactive (i.e., responsive to user-initiated events) by utilizing the following features in the SVG language:
This chapter describes:
Related information can be found in other chapters:
The following aspects of SVG are affected by events:
The following table lists all of the events which must be recognized and supported in SVG. The 'description' column describes the required conditions for the event to occur.
Event |
Description | uDOM interface | |||
---|---|---|---|---|---|
DOMFocusIn |
Occurs when an element receives focus. See the DOM 2 Events definition of DOMFocusIn ([ DOM2EVENTS ], section 1.6.1). |
focusin | Yes | No | UIEvent |
DOMFocusOut |
Occurs when an element loses focus. See the DOM 2 Events definition of DOMFocusOut ([ DOM2EVENTS ], section 1.6.1). |
focusout | Yes | No | UIEvent |
DOMActivate |
Occurs when an element is activated, for instance, through a
mouse click or a keypress. See the DOM 2 Events definition of DOMActivate ([ DOM2EVENTS ], section 1.6.1). |
activate | Yes | Yes | UIEvent |
click |
Occurs when the pointing device button is clicked over an
element. A click is defined as a mousedown and mouseup over the
same screen location. The sequence of these events is:
See the DOM 2 Events definition of click ([ DOM2EVENTS ], section 1.6.2). |
click | Yes | Yes | MouseEvent |
mousedown |
Occurs when the pointing device button is pressed over an
element. See the DOM 2 Events definition of mousedown ([ DOM2EVENTS ], section 1.6.2). |
mousedown | Yes | Yes | MouseEvent |
mouseup |
Occurs when the pointing device button is released over an
element. See the DOM 2 Events definition of mouseup ([ DOM2EVENTS ], section 1.6.2). |
mouseup | Yes | Yes | MouseEvent |
mouseover |
Occurs when the pointing device is moved onto an element.
See the DOM 2 Events definition of mouseover ([ DOM2EVENTS ], section 1.6.2). |
mouseover | Yes | Yes | MouseEvent |
mousemove |
Occurs when the pointing device is moved while it is over an
element. See the DOM 2 Events definition of mousemove ([ DOM2EVENTS ], section 1.6.2). |
mousemove | Yes | Yes | MouseEvent |
mouseout |
Occurs when the pointing device is moved away from an element.
See the DOM 2 Events definition of mouseout ([ DOM2EVENTS ], section 1.6.2). |
mouseout | Yes | Yes | MouseEvent |
mousewheel |
Occurs when a rotational input device has been activated. See the description of the MouseWheelEvent event for details. |
none | Yes | Yes | MouseWheelEvent |
textInput |
One or more characters have been entered. See the Text events section below for details. |
none | Yes | Yes | TextEvent |
keydown |
A key is pressed down. See the |
none | Yes | Yes | KeyboardEvent |
keyup |
A key is released. See the |
none | Yes | Yes | KeyboardEvent |
load |
The event is triggered at the point at which the user agent
finishes loading the element and any dependent resources (such as
images, style sheets, or scripts). In the case the element
references a script, the event will be raised only after an attempt
to interpret the script has been made. Dependent resources that
fail to load will not prevent this event from firing if the element
that referenced them is still |
load | No | No | Event |
SVGLoad |
This event is deprecated and is for backwards compatibility
only, see notes below.
The This event |
none | No | No | Event |
resize |
Occurs when a document view is being resized. This event is only
applicable to 'svg' elements and is dispatched after
the resize operation has taken place. The target of the event is
the 'svg' element. |
resize | Yes | No | Event |
SVGResize |
This event is deprecated and is for backwards compatibility
only, see notes below. This
event |
none | Yes | No | Event |
scroll |
Occurs when a document view is being shifted along the X or Y or
both axis, either through a direct user interaction or any change
on the |
scroll | Yes | No | Event |
SVGScroll |
This event is deprecated and is for backwards compatibility
only, see notes below. This
event |
none | Yes | No | Event |
SVGZoom |
Occurs when the zoom level of a document view is being changed,
either through a direct user interaction or any change to the
|
zoom | No | No | Event |
SVGRotate |
Occurs when the rotation of a document view is being changed,
either through a direct user interaction or any change to the
|
rotate | No | No | Event |
beginEvent |
Occurs when a See the
|
beginEvent | Yes | No | TimeEvent |
endEvent |
Occurs when a See the
|
endEvent | Yes | No | TimeEvent |
repeatEvent |
Occurs when a See the
|
Yes | |||
A load operation has begun. See the description of the ProgressEvent interface for details on this event. |
none | No | ProgressEvent | ||
Progress has occurred in loading a given resource. See the description of the ProgressEvent interface for details on this event. |
none | No | ProgressEvent | ||
A load operation has completed. See the description of the ProgressEvent interface for details on this event. |
none | No | ProgressEvent | ||
SVGTimer |
Occurs when the specified timer interval has elapsed for a
timer. This event is triggered only by 'running' timers in the
current global execution context of the SVG document (i.e. for
timers which have been instantiated via the SVGGlobal interface and started via the
See the |
No | No |
Note that
in order to unify event names with other W3C languages, specifications, SVG Tiny 1.2 deprecates some of the SVG 1.1 event
names. types. (The term "deprecate" in this case means
that user agents which are compatible with both SVG 1.1 and SVG
Tiny 1.2 must support both the old
deprecated event names and the new event names. Content creators
who are making content that targets SVG Tiny 1.2 should use the new event names, types, not the
deprecated event names.) Here are the
specifics: types.)
Specifically:
"SVGLoad"
event is
deprecated in favor of "load"
"SVGResize"
event
is deprecated in favor of "resize"
"SVGScroll"
event
is deprecated in favor of "scroll"
Details on the parameters
values of attributes on the event
object passed to event listeners for the event types
from DOM3 defined
in DOM Level 2 Events can be found in the DOM3 description for that
event in that specification. For other event types, the
parameters passed to event listeners
values of the attributes are are
described elsewhere in this specification.
On SVG User Agents 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.
The following example shows the use of a
DOMActivate
event to
trigger an ECMAScript event handler:
<?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 a DOMActivate 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 DOMActivate event --> <circle cx="300" cy="225" r="100" fill="red"> <handler type="application/ecmascript" ev:event="DOMActivate"> 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>
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.
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, trackball, stylus or joypad. 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.
One difference between stylus-based pointers and mouse-based
pointers is that for a mouse, the cursor always has a position; for
a stylus which may be lifted, the cursor may only have a position
when the stylus is tapped on the screen. Thus, content which
assumes that all pointer devices will generate mouseover
and mouseout
events will not work on
all devices.
User interface events that occur because of user actions that
generate text are called text events. They are usually generated by
a keyboard, but can also be generated by a different input method
such as an IME (for Japanese text, for example), by speech input,
etc. DOM 3 Text Events only requires
that The event is dispatched
whenever a string of Unicode characters is returned, making it sent to
the document and is thus independent of the input device
or method used.
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 (full-size) keyboard.
User interface events that occur because of user actions that
generate key presses (as opposed to text - — for example,
function keys, key presses for a game, etc) etc.) are called
key events.
DOM Level 2 Events defines the event flow model ([ DOM2EVENTS ], section 1.2), which defines three phases in which event listeners in the document are triggered: capture ,at target and bubbling .An SVG Tiny 1.2 user agent is not required to support the capture phase of the event flow model. If the capture phase is not supported:
Registering an event listener for the
capture phase by passing true
for the
useCapture parameter
of
EventTarget::addEventListener()
will result in that listener never being triggered.
Since there is no way with the SVG uDOM to determine whether a
listener has been registered on a node or not, such calls to
EventTarget::addEventListener()
can be ignored.
Registering an event listener for the capture phase by specifying phase="capture" on a 'listener' will result in an event listener being registered for the at target and default phases, since a value of 'capture' will be ignored, resulting in the default value of 'default' being used. Conforming SVG documents must use 'default' as the value of the 'phase' attribute if it is specified.
Any keydown
event
that corresponds to an accessKey-value in an animation timing specifier list will never cause
any appropriate listeners to be triggered, since, as described in
the definition of the accessKey-value syntax, the SVG user agent behaves as if stopPropagation()
and preventDefault()
had been invoked on the event object in the capture
phase.
For each pointer event, text event or key event, the SVG
User Agent user
agent determines the target object of a
given event. The target object must be the topmost
graphics element or SVGElementInstance object whose relevant
graphical content is under the pointer (for pointer events) or has
focus (for text and key events) at the time of the event. (See
property 'pointer-events' for a description of how to
determine whether an element's relevant graphical content is under
the pointer, and thus in which circumstances that graphics
element can be the target object for a pointer event.)
When an element is not displayed (i.e., when the 'display' property on that element or one of
its ancestors has a value of none
), that element must not be the target of pointer events. If the
user agent cannot find a graphics
element or SVGElementInstance object to be the
target object (e.g., the pointer event occurs over the viewport
background), then the user agent must set the target object to be
the rootmost svg 'svg' element .
The decision on whether to dispatch the event to the target object or to one of the target elements ancestors shall depend on the following:
When If
an event bubbling is defined to
bubble [
DOM3Events ([ DOM2EVENTS ] is
active, ], section 1.2.3),
bubbling occurs up to all direct ancestors of the target object.
Descendant elements receive events before their ancestors. Thus, if
a 'path' element is a child of a 'g'
element and they both have event listeners for click
events, then the event will
be dispatched to the 'path' element before the 'g'
element.
After an event is initially dispatched to a particular element, unless an appropriate action has been taken to prevent further processing, the event must be passed to the appropriate event handlers (if any) for that element's ancestors (in the case of event bubbling) for further processing.
The processing order for user interface events shall be as follows:
The use element creates shadow content which can be the target of user interface events.
User interface events within the shadow content shall participate in the processing of user interface events in the same manner as if the shadow content were part of the main document. In other words, if shadow content contains a graphics element that renders above other content at the current pointer location, then it represents the topmost graphics element and will receive the pointer events before other elements. In this case, the user interface events bubble up through the target's ancestors, and then across the document border into the referencing element, and then through the ancestors of the referencing element. This process continues as necessary if there are multiple levels of nested shadow trees.
In different circumstances, authors may want to control under what circumstances particular graphics element can become the target of pointer events. For example, the author might want a given element to receive pointer events only when the pointer is over the stroked perimeter of a given shape. In other cases, the author might want a given element to ignore pointer events under all circumstances so that graphics elements underneath the given element will become the target of pointer events.
For example, suppose a 'circle' with a 'stroke' of red (i.e., the outline is solid red) and a 'fill' of none (i.e., the interior is not painted) is rendered directly on top of a 'rect' with a 'fill' of blue . The author might want the 'circle' to be the target of pointer events only when the pointer is over the perimeter of the 'circle' . When the pointer is over the interior of the 'circle' , the author might want the underlying 'rect' to be the target element of pointer events.
The 'pointer-events' property specifies under what circumstances a given graphics element can be the target element for a pointer event. It affects the circumstances under which the following are processed:
Value: | boundingBox | visiblePainted | visibleFill | visibleStroke |
visible | painted | fill | stroke | all | none | inherit |
Initial: | visiblePainted |
Applies to: | graphics elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual |
Animatable : | yes |
Computed value: | Specified value, except inherit |
For text elements, hit detection shall be performed on a character cell basis:
For raster images, hit detection shall either be performed on a whole-image basis (i.e., the rectangular area for the image is one of the determinants for whether the image receives the event) or on a per-pixel basic (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event). The following rules must be adhered to:
Note that for raster images, the values of properties 'fill-opacity' , 'stroke-opacity' , 'fill' and 'stroke' do not effect event processing.
Magnification represents a complete, uniform transformation on
an SVG document fragment , where the magnify
operation scales all graphical elements by the same amount. A
magnify operation has the effect of a supplemental scale and
translate transformation placed at the rootmost level on the
SVG document fragment (i.e. outside the
rootmost svg 'svg' element ).
Panning represents a translation (i.e., a shift) transformation on an SVG document fragment in response to a user interface action.
SVG
User Agents user
agents that operate in interaction-capable user
environments are required to support the ability to magnify and
pan.
Attribute definition:
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 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.
Attribute definition:
DOMFocusIn
,
DOMFocusOut
, DOMActivate
DOMFocusIn
, DOMFocusOut
, DOMActivate
System-dependent input facilities (e.g., the tab key on most desktop computers) should be supported to allow navigation between elements that can obtain focus (i.e. elements for which the value of the 'focusable' attribute evaluates to "true").
The document has the concept of a focus ring, which is the order in which elements obtain focus. By default the focus ring shall be obtained using document order. All focusable elements must be part of the default focus ring. A document's focus ring includes any focusable objects within shadow trees for 'use' elements. The focus attributes may be used to modify the default focus ring.
The SVG language supports a flattened notion of field navigation between focusable elements where an author may define field navigation between any two focusable elements defined within a given SVG document without regard to document hierarchy. For example:
<rect xml:id="r1" focusable="true".../> <g xml:id="g1" focusable="true"> <circle xml:id="c1" focusable="true".../> </g>
In the above example, the author may specify field-to-field navigation such the user can navigate directly from any of the three elements. Thus, assuming a desktop computer which uses the tab key for field navigation, the author may specify focus navigation order such that the tab key takes the user from 'r1' to 'c1' to 'g1'.
When navigating to an element that is not visible on the canvas the following rules shall apply:
display='none'
. (An element which
has display='none'
is not focusable.)SVG's flattened notion of field navigation shall extend to referenced content and shadow trees as follows:
Focus navigation shall behave as specified:
For stand-alone SVG documents, the SVG
User Agent user
agent must always have a currently focused object.
If focus is not held by any object in the document tree, the
SVG
User Agent user
agent must give focus to the SVGDocument object.
For SVG documents which are referenced by a non-SVG host document (e.g., XHTML), the SVG document may participate within the host document's focus ring, which would allow direct navigation from an SVG focusable element onto a focusable element within the host document. Other compound document specifications may define supplemental SVG focus navigation rules for situations when SVG content is used as a component within a compound document.
User agents should provide a mechanism for a user to escape from a focus ring. When the user activates this mechanism, the user agent should change focus to the user agent, sending the appropriate focusout event to the element currently in focus.
Navigation order can be specified using the ten navigation attributes defined below.
The 'nav-next' attribute specifies the next element in the focus ring.
Attribute definition:
The 'nav-prev' attribute specifies the previous element in the focus ring.
Attribute definition:
The 'nav-up' attribute specifies the element to be focused if a navigation in the upward direction is triggered.
Attribute definition:
The 'nav-up-right' attribute specifies the element to be focused if a navigation in the upward-rightward direction is triggered.
Attribute definition:
The 'nav-right' attribute specifies the element to be focused if a navigation in the rightward direction is triggered.
Attribute definition:
The 'nav-down-right' attribute specifies the element to be focused if a navigation in the downward-rightward direction is triggered.
Attribute definition:
The 'nav-down' attribute specifies the element to be focused if a navigation in the downward direction is triggered.
Attribute definition:
The 'nav-down-left' attribute specifies the element to be focused if a navigation in the downward-leftward direction is triggered.
Attribute definition:
The 'nav-left' attribute specifies the element to be focused if a navigation in the leftward direction is triggered.
Attribute definition:
The 'nav-up-left' attribute specifies the element to be focused if a navigation in the upward-leftward direction is triggered.
Attribute definition:
<?xml version="1.0"?> <svg viewBox="0 0 220 40" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny"> <desc>An example which illustrates the use of nav-* attributes</desc> <!-- List of available channels --> <rect x="0" y="0" width="100" height="20" fill="#fb0" stroke="#000" stroke-width="2" /> <text x="50" y="13" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >Channel 1</text> <rect x="0" y="20" width="100" height="20" fill="#fb0" stroke="#000" stroke-width="2" /> <text x="50" y="33" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >Channel 2</text> <rect x="0" y="40" width="100" height="20" fill="#fb0" stroke="#000" stroke-width="2" /> <text x="50" y="53" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >Channel 3</text> <!-- List of programs for channel nb 1 --> <g xml:id="Chan1Prog1" focusable="true" nav-left="self" nav-right="url(#Chan1Prog2)" nav-up="self" nav-down="url(#Chan2Prog1)"> <rect x="100" y="0" width="100" height="20" fill="#fd0" stroke="#000" stroke-width="2"> <set attributeName="fill" begin="Chan1Prog1.focusin" end="Chan1Prog1.focusout" to="#fa0"/> </rect> <text x="150" y="13" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >Weather</text> </g> <g xml:id="Chan1Prog2" focusable="true" nav-left="url(#Chan1Prog1)" nav-right="url(#Chan1Prog3)" nav-up="self" nav-down="auto"> <rect x="200" y="0" width="120" height="20" fill="#fd0" stroke="#000" stroke-width="2"> <set attributeName="fill" begin="Chan1Prog2.focusin" end="Chan1Prog2.focusout" to="#fa0"/> </rect> <text x="260" y="13" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >The news</text> </g> <g xml:id="Chan1Prog3" focusable="true" nav-left="url(#Chan1Prog2)" nav-right="self" nav-up="self" nav-down="auto" nav-next="self"> <rect x="320" y="0" width="120" height="20" fill="#fd0" stroke="#000" stroke-width="2"> <set attributeName="fill" begin="Chan1Prog3.focusin" end="Chan1Prog3.focusout" to="#fa0"/> </rect> <text x="380" y="13" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >Football</text> </g> <!-- List of programs for channel nb 2 --> <g xml:id="Chan2Prog1" focusable="true" nav-left="self" nav-right="auto" nav-up="url(#Chan1Prog1)" nav-down="auto" nav-prev="url(#Chan1Prog1)" nav-next="auto"> <rect x="100" y="20" width="150" height="20" fill="#fd0" stroke="#000" stroke-width="2"> <set attributeName="fill" begin="Chan2Prog1.focusin" end="Chan2Prog1.focusout" to="#fa0"/> </rect> <text x="175" y="33" font-size="8" font-family="Arial Black" fill="#fff" text-anchor="middle" >Long Movie</text> </g> </svg>
This example illustrates how it is possible for an author to control the focus order between several focusable elements displayed on the canvas .
On a device which provides a 2-way navigation system (a TAB mechanism for instance), here are the interesting behaviors:
Here, in this example, for channel 2, because there is nav-prev="url(#Chan1Prog1)" attribute in element 'g' with id="Chan2Prog1" , option 1 will be applied.
In order to apply option 2, we could have set nav-prev="url(#Chan1Prog3)" instead.
In order to apply option 3, we could have set nav-prev="self" instead.
Here, in this example, for channel 1, because there is nav-next="self" attribute in element 'g' with id="Chan1Prog3" , option 2 will be applied.
In order to apply option 1, we could have set nav-next="url(#Chan2Prog1)" instead.
"Chan2Prog1"
container, if the user wants to go to the next focusable element,
the concept of a focus ring will apply because of value
nav-next="auto" . Here, according
to the focus ring navigation rules, focus will be offered to the
SVG
On a device which provides a 4-way navigation system (i.e. a joystick for instance), here are the interesting behaviors:
"Chan1Prog1"
container, if the user wants to go 'Right', the focus will be put
on container element "Chan1Prog2"
because of the
nav-right="url(#Chan1Prog2)" value.
But, because some part of "Chan1Prog2"
bounding box is
outside of the current viewport , the SVG
Before element
"Chan1Prog2" receives focus |
After element
"Chan1Prog2" receives focus (UA scrolls
automatically) |
Automated highlighting upon focus can be specified using the
'focusHighlight' attribute. This hint
indicates whether the SVG
User Agent user
agent should highlight an element on focus. The
highlighting method is implementation dependent and the SVG
User Agent user
agent should pick a method that works well for
varying content. This attribute is available on all graphical and
container elements.
<?xml version="1.0"?> <svg viewBox="0 0 210 80" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny"> <desc>An example which illustrates the use of focusHighlight attribute</desc> <text x="5" y="10">Do you want to validate transaction ?</text> <text x="5" y="25">You may read <a xlink:href="http://www.example.org/pay" >this</a> and <a xlink:href="http://www.example.org/infos">that</a> </text> <a xml:id="ValidateButton" transform="translate(5,40)" focusHighlight="none" xlink:href="validate.htm"> <rect x="0" y="0" width="90" height="20" fill="#0f0" stroke="#000" stroke-width="2"> <set attributeName="fill" begin="ValidateButton.focusin" end="ValidateButton.focusout" to="#0a0"/> </rect> <text x="45" y="13" font-size="8" font-family="Arial Black" fill="#000" text-anchor="middle">Validate</text> </a> <a xml:id="AbortButton" transform="translate(100,40)" focusHighlight="none" xlink:href="abort.htm"> <rect x="0" y="0" width="90" height="20" fill="#f00" stroke="#000" stroke-width="2"> <set attributeName="fill" begin="AbortButton.focusin" end="AbortButton.focusout" to="#a00"/> </rect> <text x="45" y="13" font-size="8" font-family="Arial Black" fill="#000" text-anchor="middle">Abort</text> </a> </svg>
In the above SVG example:
When the user agent gives an element focus it receives a
DOMFocusIn
event which has
the new focused object as the event target and a DOMFocusOut
event which has the
previously focused object as the event target.
The SVGSVGElement interface has a setFocus
method that puts the focus on the requested object. Calling
setFocus
with an element that is not focusable causes focus to stay on the
currently focused object.
The SVGSVGElement interface has a moveFocus(short
motionType)
which moves current focus to a different
object based on the value of motionType
.
SVG
User Agents user
agents which support pointer devices such as a
mouse must allow users to put focus onto focusable elements. For
example, it should be possible to click on a focusable element in
order to give focus.
Empty text fields in SVG theoretically take up no space, but
they have a point or zero-width line segment that represents the
location of the empty text field. SVG
User Agents user
agents should allow users with pointer devices to
put focus into empty text fields by initiating a select action
(e.g., a mouse click) at the location of the empty text field.
An author may change the field navigation order from a script by
using the setTrait
method to change the current value of nav-* navigation
attributes on a given element (see Example below).
<?xml version="1.0"?> <svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" xmlns:ev="http://www.w3.org/2001/xml-events"> <desc>An example of how to change the navigation order from script by changing nav-* attribute values. In this example, "myRect2" disappears between 10 and 20 sec and is replaced by the "myRectNew" rectangle during this period. Consequently, the navigation order must be changed accordingly during this period and we must re-established initial order after 20s.</desc> <rect xml:id="myRect1" x="10" y="20" width="100" height="50" fill="red" focusable="true" nav-right="url(#myRect2)"> <set begin="focusin" end="focusout" attributeName="fill" to="purple"/> </rect> <rect xml:id="myRect2" x="120" y="20" width="100" height="50" fill="red" focusable="true" nav-right="url(#myRect3)" nav-left="url(#myRect1)"> <set begin="focusin" end="focusout" attributeName="fill" to="purple"/> <set begin="0" end="10" attributeName="display" to="inline"/> <set begin="10" end="20" attributeName="display" to="none"/> <set begin="20" attributeName="display" to="inline"/> </rect> <rect xml:id="myRect3" x="230" y="20" width="100" height="50" fill="red" focusable="true" nav-left="url(#myRect2)"> <set begin="focusin" end="focusout" attributeName="fill" to="purple"/> </rect> <rect xml:id="myRectNew" x="120" y="20" width="100" height="50" fill="blue" focusable="true" nav-right="url(#myRect3)" nav-left="url(#myRect1)" display="none" > <set xml:id="myRectNewFillAnim" begin="focusin" end="focusout" attributeName="fill" to="black"/> <set xml:id="myRectNewDisplayAnim" begin="10" end="20" attributeName="display" to="inline"/> </rect> <!-- register a listener for myRectNew.beginEvent event --> <ev:listener event="beginEvent" observer="myRectNew" handler="#myAnimationHandler" /> <ev:listener event="endEvent" observer="myRectNew" handler="#myAnimationHandler" /> <!-- handler which is called when myRect2 is replaced by myRectNew --> <handler xml:id="myAnimationHandler" type="application/ecmascript"><![CDATA[ var myRect1 = document.getElementById("myRect1"); var myRect3 = document.getElementById("myRect3"); if (evt.type == "beginEvent" &