SVG 2 – 15 September 2015 TopContentsPreviousNextElementsAttributesProperties

Chapter 14: Scripting and Interactivity

Contents

14.1. Introduction

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:

14.2. Complete list of supported events

SVG 2 Requirement: Support anchor change events.
Resolution: SVG 2 will consider adding HTML document wide events (including hashchange) apply to SVG documents where they make sense.
Purpose: To allow authors to use the same set of event listener attributes on a root SVG element that they can on an HTML body or root element.
Owner: Cameron (ACTION-3278)
SVG 2 Requirement: Have event listener attributes on an appropriate interface.
Resolution: SVG 2 will move all events listener attributes to Element, in accordance with the similar move in HTML.
Purpose: To align with HTML.
Owner: Cameron (ACTION-3283)
SVG 2 Requirement: Introduce evt as an alias to event in event handlers.
Resolution: We decide to resolve ISSUE-2176 by introducing evt as an alias to event in event handlers.
Purpose: To align with HTML.
Owner: Cameron (ACTION-3093)
SVG 2 Requirement: Support drag & drop functionality.
Resolution: SVG 2 may require drag & drop functionality, and we'll investigate HTML5's functionality for that.
Purpose: To allow easier drag & drop in SVG, and to align with HTML.
Owner: Erik (ACTION-3328)

The following aspects of SVG are affected by events:

There should be a note here saying we have changed some of the event names since SVG 1.1. Don't repeat events that are already in DOM Events or HTML, instead just reference those specs for the list of events to support.

The following table lists all of the events which are recognized and supported in SVG. The Event name in the first column is the name to use within SVG's animation elements to define the events which can start or end animations. The DOM3 Event name in the second column is the name to use when defining DOM 3 event listeners ([DOM3EVENTS], section 4.3).

Requirements in the table on whether an event of a given type bubbles or is cancelable apply only to events that are created and dispatched by the user agent. Events of those types created from script using the createEvent method on the Document interface can be made to bubble or be cancelable with the initEvent method.

Event name and description DOM3 Event name Event category Event attribute name

focus

Occurs when an element receives focus. The focus must be given to the element before the dispatch of this event type.

(same) FocusEvent onfocus

focusin

Occurs when an element is about to receive focus.

(same) FocusEvent onfocusin

focusout

Occurs when an element is about to lose focus. The event must be dispatched to before the element loses focus. The element must be the element which is about to lose focus

(same) FocusEvent onfocusout

blur

Occurs when an element loses focus. The focus must be taken from the element before the dispatch of this event type.

(same) FocusEvent onblur

keydown

Occurs when a key is pressed down. The keydown event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system.

(same) KeyboardEvent onkeydown

keyup

A user agent must dispatch this event when a key is released. The keyup event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system.

(same) KeyboardEvent onkeyup

click

Occurs when the pointing device button is clicked over an element or when the pointer is otherwise activated in a manner that simulates such an action. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: mousedown, mouseup, click. If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition.

(same) MouseEvent onclick

mousedown

Occurs when the pointing device button is pressed over an element.

(same) MouseEvent onmousedown

mouseup

Occurs when the pointing device button is released over an element.

(same) MouseEvent onmouseup

mouseover

Occurs when the pointing device is moved onto an element.

(same) MouseEvent onmouseover

mousemove

Occurs when the pointing device is moved while it is over an element.

(same) MouseEvent onmousemove

mouseout

Occurs when the pointing device is moved away from an element.

(same) MouseEvent onmouseout

load

The load event is dispatched only to structurally external elements and to the Window, when the corresponding external resources have finished loading. Note that due to it's relationship with Window the load event on svg elements is only dispatched when all resources in the document have been completely loaded.

The load event and the error event on structurally external elements are mutually exclusive, only one of these events must be dispatched when processing the element in question.

load events do not bubble and are not cancelable.

In previous SVG specifications the load event was called SVGLoad and could be dispatched immediately after parsing an element but before the related resource(s) were fully loaded.

(same) none onload

unload

Only applicable to outermost svg elements. The unload event occurs when the DOM implementation removes a document from a window or frame.

unload events do not bubble and are not cancelable.

(same) none onunload

abort

The abort event occurs when page loading is stopped before an element has been allowed to load completely.

abort events bubble but are not cancelable.

(same) none onabort

error

The error event occurs when a structurally external element does not load properly or when an error occurs during script execution.

error events bubble but are not cancelable.

(same) none onerror

resize

Occurs when a document view is being resized. This event is only applicable to outermost svg elements and is dispatched after the resize operation has taken place. The target of the event is the svg element.

resize events do not bubble and are not cancelable.

The term 'document view' is not defined, raised in this www-svg thread. Should probably be linked to CSSOM View, and/or be clarified that it is mostly intended for standalone svg documents. The issue applies to the 'scroll' and 'SVGZoom' events as well.

(same) none onresize

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 currentTranslate property available on SVGSVGElement interface. This event is only applicable to outermost svg elements and is dispatched after the shift modification has taken place. The target of the event is the svg element.

scroll events bubble only when dispatched to the document, and are not cancelable.

(same) none onscroll

SVGZoom

Occurs when the zoom level of a document view is being changed, either through a direct user interaction or any change to the currentScale property available on SVGSVGElement interface. This event is only applicable to outermost svg elements and is dispatched after the zoom level modification has taken place. The target of the event is the svg element.

SVGZoom events bubble but are not cancelable.

none none onzoom

beginEvent

Occurs when an animation element begins. For details, see the description of Interface TimeEvent in the SMIL Animation specification.

none none onbegin

endEvent

Occurs when an animation element ends. For details, see the description of Interface TimeEvent in the SMIL Animation specification.

none none onend

repeatEvent

Occurs when an animation element repeats. It is raised each time the element repeats, after the first iteration. For details, see the description of Interface TimeEvent in the SMIL Animation specification.

none none onrepeat

Details on the parameters passed to event listeners for the event types for UI Events can be found in the ([ DOM3EVENTS]) and ([UIEVENTS]) specifications where the keybard event definition in UIEVENTS takes precedence over that in DOM3EVENTS. For other event types, the parameters passed to event listeners are described elsewhere in this specification.

Likewise, event-value timing specifiers used in animation element begin and end attributes are resolved to concrete times only in response to "bubbling" and "at target" phase events dispatched to the relevant element.

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

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

For each pointer event, the SVG user agent determines the target element of a given pointer event. The target element is the topmost graphics element whose relevant graphical content is under the pointer 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 graphic element can be the target element 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 cannot be the target of pointer events.

If a target element for the pointer event exists, then the event is dispatched to that element according to the normal event flow ([DOM3EVENTS], section 1.2). For shadow trees created by the use element or via script, the event must follow the Shadow DOM event dispatching algorithm [SHADOWDOM]

If a target element for the pointer event does not exist, then the event is ignored.

14.5. Hit-testing and processing order for user interface events

hit-testing
The process of determining whether a pointer intersects a given graphics element. Hit-testing is used in determining which element to dispatch a mouse event to, which might be done in response to the user moving the pointing device, or by changes in the position, shape and other attributes of elements in the document. Hit-testing is also known as hit detection or picking. See also the definition of the ‘pointer-events’ property.

There are two distinct aspects of pointer-device interaction with an element or area:

  1. hit-testing, to determine if a pointer event (such as a mouse movement or mouse click) occurred within the interaction area of an element, and the subsequent DOM event flow;
  2. functional processing of actions associated with any relevant element.

14.5.1. Hit-testing

Determining whether a pointer event results in a positive hit-test depends upon the position of the pointer, the size and shape of the graphics element, and the computed value of the ‘pointer-events’ property on the element. The definition of the ‘pointer-events’ property below describes the exact region that is sensitive to pointer events for a given type of graphics element.

Note that the svg element is not a graphics element, and in a Conforming SVG Stand-Alone File a outermost svg element will never be the target of pointer events, though events can bubble to this element. If a pointer event does not result in a positive hit-test on a graphics element, then it should evoke any user-agent-specific window behavior, such as a presenting a context menu or controls to allow zooming and panning of an SVG document fragment.

This specification does not define the behavior of pointer events on the outermost svg element for SVG images which are embedded by reference or inclusion within another document, e.g., whether the outermost svg element embedded in an HTML document intercepts mouse click events; future specifications may define this behavior, but for the purpose of this specification, the behavior is implementation-specific.

14.5.2. Event processing

An element which is the target of a user interface event may have particular interaction behaviors, depending upon the type of element and whether it has explicit associated interactions, such as scripted event listeners, CSS pseudo-classes matches, or declarative animations with event-based timing. The algorithm and order for processing user interface events for a given target element, after dispatching the DOM event, is as follows:

  1. If an event handler registered on this element invokes the preventDefault() DOM method, then no further processing for this element is performed, and the event follows the event dispatch and DOM event flow processing as described in DOM Level 3 Events [DOM3EVENTS] (or its successor);
  2. If the element has an associated title or description, such as a title element, and the user agent supports the display of such information (e.g. via a tooltip or status-bar message), that information should be displayed, as appropriate to the type of pointer event;
  3. If the element matches any relevant dynamic pseudo-class selectors appropriate to the type of pointer event, such as :hover, :active, or :focus as described in [CSS21], section 5.11, then the relevant class properties are applied;
  4. If the element and the event type are associated with the activation or cancelation of declarative animation though the use of event-value timing specifiers, any corresponding instance times must be resolved, and any conseqential actions of this instance time resolution (such as immediately starting or stopping the animation) must be performed;
  5. If the element is a hyperlink (e.g., it is a descendant element of an a element), and the pointer event is of a type that activates that hyperlink (e.g. via a mouse click), and if the hyperlink traversal changes the context of the content (e.g. opens a different document, or moves the pointer away from this element by moving to another part of the same document), then no further processing for this element is performed;
  6. If the element is a text content element, and the event type is one which the user agent recognizes as part of a text-selection operation (e.g., a mouse click and drag, or a double-click), then the text selection algorithm is performed;
  7. If the event type is one which the user agent associates with the evocation of special user-interface controls (e.g., a right-click or command-click evoking a context menu), the user agent should evoke such user-agent-specific behavior, such as presenting a context menu or controls to allow zooming and panning of an SVG document fragment.

14.6. The ‘pointer-events’ property

In different circumstances, authors may want to control under what conditions particular graphic elements 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 graphical elements underneath the given element will become the target of pointer events.

The effects of masking and clipping differ with respect to pointer events. A clip path is a geometric boundary, and a given point is clearly either inside or outside that boundary; thus, pointer events must be captured normally over the rendered areas of a clipped element, but must not be captured over the clipped areas, as described in the definition of clipping paths. By contrast, a mask is not a binary transition, but a pixel operation, and different behavior for fully transparent and almost-but-not-fully-transparent may be confusingly arbitrary; as a consequence, for elements with a mask applied, pointer events must still be captured even in areas where the mask goes to zero opacity. If an author wishes to achieve an effect where the transparent parts of a mask allow pointer events to pass to an element below, a combination of masking and clipping may be used.

The ‘filter’ property has no effect on pointer events processing, and must in this context be treated as if the ‘filter’ wasn't specified.

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 rectangle 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 rectangle to be the target element of pointer events.

The ‘pointer-events’ property specifies under what circumstances a given element can be the target element for a pointer event. It affects the circumstances under which the following are processed:

Name: pointer-events
Value: bounding-box | visiblePainted | visibleFill | visibleStroke | visible | painted | fill | stroke | all | none
Initial: visiblePainted
Applies to: container elements, graphics elements and text content child elements
Inherited: yes
Percentages: N/A
Media: visual
Computed value: as specified
Animatable: yes
bounding-box
The given element must be a target element for pointer events when the pointer is over the bounding box of the element.
visiblePainted
The given element can be the target element for pointer events when the ‘visibility’ property is set to visible and when the pointer is over a "painted" area. The pointer is over a painted area if it is over the interior (i.e., fill) of the element and the ‘fill’ property has an actual value other than none or it is over the perimeter (i.e., stroke) of the element and the ‘stroke’ property is set to a value other than none.
visibleFill
The given element can be the target element for pointer events when the ‘visibility’ property is set to visible and when the pointer is over the interior (i.e., fill) of the element. The value of the ‘fill’ property does not affect event processing.
visibleStroke
The given element can be the target element for pointer events when the ‘visibility’ property is set to visible and when the pointer is over the perimeter (i.e., stroke) of the element. The value of the ‘stroke’ property does not affect event processing.
visible
The given element can be the target element for pointer events when the ‘visibility’ property is set to visible and the pointer is over either the interior (i.e., fill) or the perimeter (i.e., stroke) of the element. The values of the ‘fill’ and ‘stroke’ do not affect event processing.
painted
The given element can be the target element for pointer events when the pointer is over a "painted" area. The pointer is over a painted area if it is over the interior (i.e., fill) of the element and the ‘fill’ property has an actual value other than none or it is over the perimeter (i.e., stroke) of the element and the ‘stroke’ property has an actual value other than none. The value of the ‘visibility’ property does not affect event processing.
fill
The given element can be the target element for pointer events when the pointer is over the interior (i.e., fill) of the element. The values of the ‘fill’ and ‘visibility’ properties do not affect event processing.
stroke
The given element can be the target element for pointer events when the pointer is over the perimeter (i.e., stroke) of the element. The values of the ‘stroke’ and ‘visibility’ properties do not affect event processing.
all
The given element can be the target element for pointer events whenever the pointer is over either the interior (i.e., fill) or the perimeter (i.e., stroke) of the element. The values of the ‘fill’, ‘stroke’ and ‘visibility’ properties do not affect event processing.
none
The given element does not receive pointer events.

For text elements, hit-testing is performed on a character cell basis:

For raster images, hit-testing is either 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 basis (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event):

Note that for raster images, the values of properties ‘opacity’, ‘fill-opacity’, ‘stroke-opacity’, ‘fill’ and ‘stroke’ do not affect event processing.

14.7. Magnification and panning

SVG 2 Requirement: Support level of detail control.
Resolution: We will support Level of Detail control in SVG 2.
Purpose: Control visibility of elements based on zoom level (useful, for example, in mapping).
Owner: Doug (no action)
Note: See Tiling and Layering Module for SVG 1.2 Tiny.

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 outermost level on the SVG document fragment (i.e., outside the outermost 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 that operate in interaction-capable user environments are required to support the ability to magnify and pan.

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

If magnify, 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.

If a zoomAndPan attribute is assigned to an inner svg element, the zoomAndPan setting on the inner svg element will have no effect on the SVG user agent.

Animatable: no.

14.8. Cursors

Some interactive display environments provide the ability to modify the appearance of the pointer, which is also known as the cursor. Three types of cursors are available:

The ‘cursor’ property is used to specify which cursor to use. The ‘cursor’ property can be used to reference standard built-in cursors by specifying a keyword such as crosshair or a custom cursor. Custom cursors are referenced via a <url> and can point to either an external resource such as a platform-specific cursor file or to a cursor element, which can be used to define a platform-independent cursor.

14.8.1. The effect of the ‘cursor’ property

See the CSS Basic User Interface Module Level 3 specification for the definition of ‘cursor’. [CSS3UI]

SVG uses the ‘cursor’ property to specify the type of cursor to be displayed for the pointing device when it is over a region of an element that is sensitive to pointer events, according to the value of the ‘pointer-events’ property. SVG extends the definition of ‘cursor’ from the CSS Basic User Interface Module Level 3 specification as follows:

14.8.2. The ‘cursor’ element

The cursor element can be used to define a platform-independent custom cursor. A recommended approach for defining a platform-independent custom cursor is to create a PNG image [PNG] and define a cursor element that references the PNG image and identifies the exact position within the image which is the pointer position (i.e., the hot spot).

The PNG format is recommended because it supports the ability to define a transparency mask via an alpha channel. If a different image format is used, this format should support the definition of a transparency mask (two options: provide an explicit alpha channel or use a particular pixel color to indicate transparency). If the transparency mask can be determined, the mask defines the shape of the cursor; otherwise, the cursor is an opaque rectangle. Typically, the other pixel information (e.g., the R, G and B channels) defines the colors for those parts of the cursor which are not masked out. Note that cursors usually contain at least two colors so that the cursor can be visible over most backgrounds.

cursor
Categories:
None
Content model:
Any number of the following elements, in any order:script
Attributes:
DOM Interfaces:

Attribute definitions:

Name Value Initial value Animatable
x, y <length> 0 yes
The x- and y-coordinates of the position in the cursor's coordinate system which represents the precise position that is being pointed to.
Name Value Initial value Animatable
href URL [URL] (none) yes
A URL reference to the file or element which provides the image of the cursor. Refer to the common handling defined for URL reference attributes and deprecated XLink attributes.

SVG user agents are required to support PNG format images as targets of the href attribute.

<!doctype html>
<body>
  <style>
  body,html { cursor: auto; }
  circle { pointer-events: all; stroke: black; fill: yellow; stroke-width: 4px; }
  circle:hover { fill: blue; }
  svg { width: 200px; height: 200px; }
  text { font: 32px sans-serif; text-anchor: middle; }

  #test1 { cursor: url(cursor.svg) 8 1, auto; }
  #test2 { cursor: url(#cursor), auto; }
  </style>
  <svg id="test1" viewBox="0 0 200 200">
    <circle cx="100" cy="100" r="75"/>
    <text x="100" y="100">SVG<tspan x="100" dy="1em">cursor</tspan></text>
  </svg>
  <svg id="test2" viewBox="0 0 200 200">
    <cursor id="cursor" xlink:href="cursor.png" x="4" y="0"/>
    <circle cx="100" cy="100" r="75" />
    <text x="100" y="100">PNG<tspan x="100" dy="1em">cursor</tspan></text>
  </svg>
</body>

View this example as SVG (SVG-enabled browsers only)

14.9. Focus

This section needs to defer to HTML more rather than duplicate the wording from that spec.

When an element is focused, key events received by the document must be targeted at that element. There may be no element focused; when no element is focused, key events received by the document must be targeted at the Document's root svg element, if there is one. If there is no root element, key events must not be fired.

User agents may track focus for each browsing context or Document individually, or may support only one focused element per top-level browsing context — user agents should follow platform conventions in this regard.

Which elements within a top-level browsing context currently have focus must be independent of whether or not the top-level browsing context itself has the system focus.

When a child browsing context is focused, its browsing conrtext container must also have focus.

When an element is focused, the element matches the CSS :focus pseudo-class.

14.9.1. Sequential focus navigation and the ‘tabindex’ attribute

The tabindex attribute allows the author to control whether and element is focusable. Each element can have a tabindex focus flag set, as defined below. This flag is a factor that contributes towards determining whether an element is focusable, as described in the next section.

If the tabindex attribute is omitted or an invalid <number>

The user agent should follow platform conventions to determine if the element's tabindex focus flag is set and, if so, whether the element can be reached using sequential focus navigation, and if so, what its relative order should be.

An a element that has an href attribute must have the tabindex focus flag set.

If the value is a negative integer

The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.

One valid reason to ignore the requirement that sequential focus navigation not allow the author to lead to the element would be if the user's only mechanism for moving the focus is sequential focus navigation. For instance, a keyboard-only user would be unable to click on a text field with a negative tabindex, so that user's user agent would be well justified in allowing the user to tab to the control regardless.

If the value is a zero

The user agent must set the element's tabindex focus flag, should allow the element to be reached using sequential focus navigation, and should follow platform conventions to determine the element's relative order.

If the value is greater than zero

The user agent must set the element's tabindex focus flag, should allow the element to be reached using sequential focus navigation, and should place the element in the sequential focus navigation order so that it is:

  • before any focusable element whose tabindex attribute has been omitted or whose value, when parsed, returns an error,
  • before any focusable element whose tabindex attribute has a value equal to or less than zero,
  • after any element whose tabindex attribute has a value greater than zero but less than the value of the tabindex attribute on the element,
  • after any element whose tabindex attribute has a value equal to the value of the tabindex attribute on the element but that is earlier in the document in tree order than the element,
  • before any element whose tabindex attribute has a value equal to the value of the tabindex attribute on the element but that is later in the document in tree order than the element, and
  • before any element whose tabindex attribute has a value greater than the value of the tabindex attribute on the element.

An element that has its tabindex focus flag set but does not otherwise have an activation behavior defined has an activation behavior that does nothing.

This means that an element that is only focusable because of its tabindex attribute will fire a click event in response to a non-mouse activation (e.g. hitting the "enter" key while the element is focused).

The tabIndex IDL attribute must reflect the value of the tabindex content attribute.

14.9.1.1. Focus management

Need to decide how will replace some of the links pertainig to "in a document", "Document", and "being rendered". This is dependent on Document work that needs to be added wrt. tabindex. Do we define our own definitions vs. what is in HTML5?

An element is focusable if the user agent's default behavior allows it to be focusable or if the element has its tabindex focus flag set, but only if the element is either being rendered and only if neither the element nor any of its ancestors are inert.

User agents should make the a element focusable as part of their default behavior, unless platform conventions dictate otherwise:

Notwithstanding the above, user agents may make any element or part of an element focusable, especially to aid with accessibility or to better match platform conventions.


The focusing steps for an element are as follows:

  1. If the element is not in a Document, or if the element's Document has no browsing context, or if the element's Document's browsing context has no top-level browsing context, or if the element is not focusable, then abort these steps.

  2. If focusing the element will remove the focus from another element, then run the unfocusing steps for that element.

  3. Make the element the currently focused element in its top-level browsing context.

  4. Fire a simple event named focus at the element.

User agents must synchronously run the focusing steps for an element whenever the user moves the focus to a focusable element.

The unfocusing steps for an element are as follows:

  1. Unfocus the element.

  2. Fire a simple event named focusout at the element.

When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should synchronously run the unfocusing steps for the affected element only.

For example, this might happen because the element is removed from its Document.


An element is being rendered if it is in a Document, either its parent node is itself being rendered or it is the Document node, and it is not explicitly excluded from the rendering using either:

Just being off-screen does not mean the element is not being rendered.


14.10. Event attributes

event attribute
An event attribute always has a name that starts with "on" followed by the name of the event for which it is intended. It specifies some script to run when the event of the given type is dispatched to the element on which the attribute is specified.

The complete list of events that are part of the SVG language and SVG DOM and descriptions of those events is provided in Complete list of supported events.

The contents of event attributes are always interpreted as ECMAScript, as if processed with the media type 'application/ecmascript'. [RFC2046][RFC4329]

14.10.1. Event attribute for the load event

Attribute definitions:

Name Value Initial value Animatable
onload (see below) (none) no
Specifies some script to execute when "bubbling" or "at target" phase listeners for the load event are fired on the element the attribute is specified on. There are no restrictions on the values of this attribute.

14.10.2. Event attributes on graphics and container elements

graphical event attribute
A graphical event attribute is an event attribute that specifies script to run for a particular user interaction event. See Event attributes on graphics and container elements. The graphical event attributes are onfocusin and onfocusout.

Below are the definitions for the graphical event attributes. These can be specified on most graphics elements and container elements. (See the definition for each element to determine whether it can have a graphical event attribute specified on it.)

Note that onload, defined above, is also classified as a graphical event attribute.

Attribute definitions:

Name Value Initial value Animatable
onfocusin, onfocusout, onfocus, onblur, onclick, onkeydown, onkeyup, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout (see below) (none) no
Specifies some script to execute when "bubbling" or "at target" phase listeners for the corresponding event are fired on the element the attribute is specified on. See the Complete list of supported events to determine which event each of these event attributes corresponds to. There are no restrictions on the values of this attribute.

14.10.3. Document-level event attributes

document event attribute
A document event attribute is an event attribute that specifies script to run for a particular document-wide event. The document event attributes are onunload, onabort, onerror, onresize, onscroll and onzoom.

Below are the definitions for the document event attributes. These can be specified only on svg elements.

The conformance class for the 'only-on-<svg> elements' criteria needs to be clarified here (this is for document validation presumably, so perhaps Conforming SVG Document Fragments would be appropriate to mention), the document event attributes should be fine to specify on any element, they just don't do much in all such cases, and it makes sense to not encourage uses where it doesn't have any real meaning. For Conforming Dynamic SVG Viewers: what the document event attributes should do is register an event listener for the event in question.

'onerror' should be available on image, script and elements that load external resources. This is related to issue 2254.

Attribute definitions:

Name Value Initial value Animatable
onunload, onabort, onerror, onresize, onscroll, onzoom (see below) (none) no
Specifies some script to execute when "bubbling" or "at target" phase listeners for the corresponding event are fired on the element the attribute is specified on. See the Complete list of supported events to determine which event each of these event attributes corresponds to. There are no restrictions on the values of this attribute.

14.10.4. Animation event attributes

Below are the definitions for the animation event attributes. These can be specified on the animation elements.

Attribute definitions:

Name Value Initial value Animatable
onbegin, onend, onrepeat (see below) (none) no
Specifies some script to execute when "bubbling" or "at target" phase listeners for the corresponding event are fired on the element the attribute is specified on. See the Complete list of supported events to determine which event each of these event attributes corresponds to. There are no restrictions on the values of this attribute.

14.11. The ‘script’ element

SVG 2 Requirement: Consider allowing async/defer on script.
Resolution: SVG 2 will allow async/defer on ‘script’.
Purpose: To align with HTML.
Owner: Cameron (ACTION-3280)
SVG 2 Requirement: Incorporate SVG Tiny 1.2 script processing model.
Resolution: SVG 2 will define how inline scriptable content will be processed, in a compatible way to HTML5
Purpose: To have consistent script running behavior across HTML and SVG.
Owner: Cameron (ACTION-3282)

A script element is equivalent to the script element in HTML and thus is the place for scripts (e.g., ECMAScript). Any functions defined within any script element have a "global" scope across the entire current document.

Example script01 defines a function circle_click which is called by the onclick event attribute on the circle element. The drawing below on the left is the initial image. The drawing below on the right shows the result after clicking on the circle.

Before attempting to execute the script element the resolved media type value for type must be inspected. If the SVG user agent does not support the scripting language then the script element must not be executed.

  <?xml version="1.0" standalone="no"?>
  <svg width="6cm" height="5cm" viewBox="0 0 600 500"
       xmlns="http://www.w3.org/2000/svg">
    <desc>Example script01 - invoke an ECMAScript function from an onclick event
    </desc>
    <!-- ECMAScript to change the radius with each click -->
    <script type="application/ecmascript"> <![CDATA[
      function circle_click(evt) {
        var circle = evt.target;
        var currentRadius = circle.getAttribute("r");
        if (currentRadius == 100)
          circle.setAttribute("r", currentRadius*2);
        else
          circle.setAttribute("r", currentRadius*0.5);
      }
    ]]> </script>

    <!-- Outline the drawing area with a blue line -->
    <rect x="1" y="1" width="598" height="498" fill="none" stroke="blue"/>

    <!-- Act on each click event -->
    <circle onclick="circle_click(evt)" cx="300" cy="225" r="100"
            fill="red"/>

    <text x="300" y="480"
          font-family="Verdana" font-size="35" text-anchor="middle">

      Click on circle to change its size
    </text>
  </svg>
  
Example script01
Example script01 — invoke an ECMAScript function from an onclick event — before first click Example script01 — invoke an ECMAScript function from an onclick event — after first click

View this example as SVG (SVG-enabled browsers only)

script
Categories:
Structurally external element
Content model:
Any elements or character data.
Attributes:
DOM Interfaces:

Attribute definitions:

Name Value Initial value Animatable
crossorigin [ anonymous | use-credentials ] anonymous yes

The crossorigin attribute is a CORS settings attribute, and unless otherwise specified follows the same processing rules as in html [HTML].

Name Value Initial value Animatable
type (see below) application/ecmascript no
Identifies the scripting language for the given script element. The value must be a valid media type, per Multipurpose Internet Mail Extensions (MIME) Part Two [RFC2046]. If a type is not provided, then the default scripting language assumed is ECMAScript, as if processed with the ‘application/ecmascript’ media type.
Name Value Initial value Animatable
href URL [URL] (none) no
An URL reference to an external resource containing the script code. Refer to the common handling defined for URL reference attributes and deprecated XLink attributes.

To get the referenced resource, do a potentially CORS-enabled fetch of the absolute URL that resulted from the earlier step, with the mode being the current state of the element's crossorigin attribute, the origin being the origin of the script element's Document, and the default origin behaviour set to taint. For origin, the rules defined for the html 'script' element apply the same way to the svg script element.

14.12. DOM interfaces

14.12.1. Interface SVGCursorElement

An SVGCursorElement object represents a cursor element in the DOM.

interface SVGCursorElement : SVGElement {
  [SameObject] readonly attribute SVGAnimatedLength x;
  [SameObject] readonly attribute SVGAnimatedLength y;
};

SVGCursorElement implements SVGURIReference;

The x and y IDL attributes reflect the x and y content attributes.

14.12.2. Interface SVGScriptElement

An SVGScriptElement object represents a script element in the DOM.

interface SVGScriptElement : SVGElement {
  attribute DOMString type;
  attribute DOMString crossOrigin;
};

SVGScriptElement implements SVGURIReference;

The type IDL attribute reflects the type content attribute.

The crossOrigin IDL attribute reflects the crossorigin content attribute, limited to only known values.

14.12.3. Interface SVGZoomEvent

A DOM consumer can use the hasFeature of the DOMImplementation interface to determine whether the SVG zoom event set has been implemented by a DOM implementation. The feature string for this event set is "SVGZoomEvents". This string is also used with the createEvent method.

The zoom event handler occurs before the zoom event is processed. The remainder of the DOM represents the previous state of the document. The document will be updated upon normal return from the event handler.

The UI event type for a zoom event is:

SVGZoom
The zoom event occurs when the user initiates an action which causes the current view of the SVG document fragment to be rescaled. Event handlers are only recognized on svg elements. See SVGZoom event.
interface SVGZoomEvent : UIEvent {
  [SameObject] readonly attribute DOMRectReadOnly zoomRectScreen;
  readonly attribute float previousScale;
  [SameObject] readonly attribute DOMPointReadOnly previousTranslate;
  readonly attribute float newScale;
  [SameObject] readonly attribute DOMPointReadOnly newTranslate;
};

The zoomRectScreen IDL attribute represents the specified zoom rectangle in screen units.

The previousScale and previousTranslate IDL attributes represent the scale factor and translation values from previous zoom operations that was in place before the zoom operation occurred.

The newScale and newTranslate IDL attributes represent the scale factor and translation values that will be in place after the zoom operation has been processed.

When an SVGZoomEvent object is created, it is initialized with values for its zoomRectScreen, previousScale, previousTranslate, newScale and newTranslate members. On getting any of these IDL attributes, the corresponding value the SVGZoomEvent object was initialized with is returend.

SVG 2 – 15 September 2015 TopContentsPreviousNextElementsAttributesProperties