Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This specification defines a simple mechanism to visually and logically connect two elements, as for an abstract graph. It introduces new elements, connector and point, and describes both the appearance and behavior of these elements, specifically in terms of rendering and navigation.
Although originally designed for use in SVG, some aspects of this specification are defined in XML and are accessed via presentation properties, and therefore could be used in other environments, such as HTML styled with CSS and XSL:FO. This module is intended for implementation by SVG 1.1 or SVG Tiny 1.2 user agents as a compatible extension of those specifications, and will be incorporated into the SVG 2.0 specification.
This document defines the markup used by SVG Connector. There is an accompanying primer document that lists the ways SVG Connector may be used.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
Warning! This specification is still a proposal in early Editor's Draft state, and is not yet ready for public comments. Subsequent drafts will include contact information for review comments.
There is an accompanying SVG Connector 1.0, Part 1: Primer that lists the ways SVG Connector may be used.
This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain.
The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.
Publication of this document does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a work in progress.
This draft of SVG Connector introduces new Connector syntax and markup for the SVG language. One of the goals is that this specification can be re-used more easily by other specifications that want to have advanced Connector features. This specification introduces syntax that may not be backwards compatible with older SVG User Agents, and the use of this syntax should be accompanied by a fallback using the 'switch' element.
The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to www-svg@w3.org. Please include some kind of keyword that identifies the area of the specification the comment is referring to in the subject line of your message (e.g "Section X.Y - Foo attribute values" or "Connector Functionality"). If you have comments on multiple areas of this document, then it is probably best to split those comments into multiple messages.
The public are welcome to comment on any aspect in this document, but there are a few areas in which the SVG Working Group are explicitly requesting feedback. These areas are noted in place within this document. There is also a specific area related to the specification that is listed here:
This specification defines a simple mechanism to visually and logically connect two elements, for such use cases as flow charts, circuit diagrams, org charts, or any kind of node-edge graph. It includes the ability to automatically draw and update the connector line as a straight line along the shortest path between the elements, or to allow the shape of the connector to be defined using the syntax of the path element. It also introduces the point element, which may be used as a connection point within shape definitions or a routing point for the connector element.
This specification also describes the manner in which the connector element establishes an implicit navigation relationship between connected elements.
Finally, this specification defines several new values for the role attribute and provides guidance for other use of metadata, to facilitate transformation to and from graph description languages.
Note that even though this specification references parts of SVG 1.1 and SVG Tiny 1.2 it does not require a complete implementation of those specifications.
This document is normative, except where otherwise indicated.
This document contains explicit conformance criteria that overlap with some RNG definitions in requirements. If there is any conflict between the two, the explicit conformance criteria are the definitive reference.
This specification concentrates on the visual and behavioral treatment of graphs and graph-like features, rather than the semantic or topological characteristics of graphs. It is not within the scope of this specification to provide any automatic graph layout algorithms, or any edge routing beyond the simple cases described in the algorithm found in Automatic Connector Rendering. Other specifications may define advanced SVG layout which can be used with this specification, and future versions of this specification may provide more powerful edge routing, contingent on feedback from authors and implementers.
While the title and desc elements allow human-readable text descriptions of edges and nodes, there is no special facility in this specification for the visual labeling of nodes and edges, either in semantic terms or positionally. Textul elements, including the textPath elements, may be used instead.
This specification does not define a generic graph description language, though most common features of graphs can be represented using this functionality. Instead, it defines the appearance and behavior of concepts found in many graph formats, which may also be used in a non-graph and quasi-graph manner.
There are minimal semantics defined for expressing complex features of graphs, with no formal treatment of hyperedges, hierarchical graphs, or nested graphs, and no provision to express graph characteristics such as planarity, connectedness, completeness, or Euler or Hamiltonian paths or circuits. However, the native SVG metadata features described in SVG Tiny 1.2, in combination with such metadata formats as RDFa, may be used to express more complex relationships.
The connectors, points, and metadata features of SVG are designed to allow easy transformation to and from graph definition and exchange languages, including:
Below is an example of a purely semantic graph, stripped of any specific graphical representation. Note that because the empty 'g' elements do not render and have no positional characteristics, the 'connector' elements will not render; if these groups were filled with shapes, however, a conforming user agent would draw would draw lines between the centroids of those shapes. The use of SVG as a purely semantic graph description exchange format is strongly discouraged, since users expect to see visual output when viewing an SVG file; all SVG files should include graphical content, even if that content is only 'circle' or 'text' elements.
<svg xmlns="http://www.w3.org/2000/svg" role="graph" directed="false">
<title>K3,3 Graph</title>
<desc>
The famous non-planar basic graph: a complete bipartite graph of six vertices,
three of which connect to each of the other three
</desc>
<g role="node" id="n-1" />
<g role="node" id="n-2" />
<g role="node" id="n-3" />
<g role="node" id="n-4" />
<g role="node" id="n-5" />
<g role="node" id="n-6" />
<connector role="edge" n1="#n-1" n2="#n-4" />
<connector role="edge" n1="#n-1" n2="#n-5" />
<connector role="edge" n1="#n-1" n2="#n-6" />
<connector role="edge" n1="#n-2" n2="#n-4" />
<connector role="edge" n1="#n-2" n2="#n-5" />
<connector role="edge" n1="#n-2" n2="#n-6" />
<connector role="edge" n1="#n-3" n2="#n-4" />
<connector role="edge" n1="#n-3" n2="#n-5" />
<connector role="edge" n1="#n-3" n2="#n-6" />
</svg>
Connectors may be used in many applications, not all of which are necessarily intuitive:
The following stylistic conventions are followed in this specification:
'This is a keyword or value'
This is a link to a definition in the glossary
This is a note.
This is a warning. It is used on security notes.
This is an example.
This is a feature at risk, which is likely to be removed from the specification.
This is a proposed new feature.
@@ This is an open issue.
Feedback on features at risk, new features, and open issues is especially appreciated.
In addition, certain terms are used in this specification with particular meanings. The term "implementation" applies to a browser, authoring tool, or other user agent that implements this specification, while an author is a person who writes script or code that takes advantage of the interfaces, methods, attributes, events, and other features described in this specification in order to make Web applications, and a user is the person who uses those Web applications in an implementation.
Within this specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. However, for readability, these words do not necessarily appear in uppercase in this specification.
The role attribute may be used to provide additional semantics to an element, particularly for use in converting or transforming from SVG into another graph format. This specification defines several new role values to allow explicit notation of elements for ease of metadata transformations and analysis, but the use of these role values is not necessary for connector functionality. Note: This specification does not define any specific functionality for these role values in the SVG context.
graphThis role value indicates that the container element is the root of a graph. A graph in this sense is an abstract mathematical representation of a set of objects in which some pairs of the objects (nodes) may be connected by links (edges).
An element with this role attribute value which is the child of another element with the graph role attribute value must be interpreted as a nested graph (also referred to as a sub-graph). A document with nested graphs is referred to a hierarchical graph.
nodeThis role value indicates that the element is a node (or vertex or point) of a graph. A graph node represents an object, which is normally connected to another object by an edge; it may also be thought of as the point at which two or more edges meet or intersect.
In the case of elements joined by connector elements, the node role may be inferred, but elements intended to be nodes which are not referents of a connector element may not enjoy the same role inference, especially in scenarios where graph content is mixed with other graphical content, such as UI controls.
Note that an element with the node role value may also have the graph role value, if it is a container element which contains a nested graph.
edgeThis role value indicates that the element is an edge (or line or arc) of a graph. An edge is a link between two objects (nodes) in a graph. An arc is specifically a directed edge.
A connector element may be implicitly assumed to be a edge. The edge role indicates a link between two nodes only; for an edge which connects more than two nodes, the hyperedge role value should be used.
portThis role value indicates that the element is a port on a node of a graph. A port is a logical or positional point of connection within a node. For a flowchart, this may be the midpoint of a polygon side or the corners of a shape, and for a circuit, this may be an input or output socket or the legs on a chip. One node may have many ports defined, with different positions and characteristics.
A point element as a child of a node element (that is, an element with a role attribute value of node or a referent of a connector element) may be implicitly assumed to be a port.
When used with other, more specific supplementary roles (not defined in this specification), a the role of a port may be used to determine which of several ports a connector element will join to; see the definitions for connector and point elements, and Automatic Connector Rendering.
hyperedgeThis role value indicates that the element is an edge of a graph which joins multiple nodes. An edge is a link between three or more objects (nodes) in a graph. For an edge which connects only two nodes, the edge role value should be used.
SVG does not define any behavior for hyperedges, nor any semantic means to relate one connector element with this role value to another as a multi-segment hyperedge; other roles or classes, or other forms of metadata, may be used for this purpose as appropriate.
Connectors represent a visual or logical connection between two elements, which may be styled with a stroke to illustrate the connection between elements, or hidden and used only for its navigational or logical aspects. In terms of graph theory, the target elements are vertices and connector elements are edges.
The outline of a connector may be styled in the same manner as the path element, but unlike the path element, a connector must not be filled, even in the case where it defines a closed shape. The stroking effects are defined in Filling, Stroking and Paint Servers in SVG Tiny 1.2.
A connector is either described using the explicit syntax of the path element, or is generated automatically using the implicit relationship between the indicated elements as modified by any child point elements of the connector element or of the target shapes.
This section describes the syntax and behavior for SVG connectors. Various implementation notes for SVG connectors can be found in 'connector' element implementation notes.
A connector is defined in SVG using the 'connector' element.
<define name='connector'>
<element name='connector'>
<ref name='connector.AT'/>
<zeroOrMore><ref name='shapeCommon.CM'/></zeroOrMore>
</element>
</define>
<define name='connector.AT' combine='interleave'>
<ref name='svg.N1N2.attr'/>
<ref name='svg.ShapeCommon.attr'/>
<ref name='svg.D.attr'/>
<optional>
<ref name='svg.Directed.attr'/>
<ref name='svg.N1portN2port.attr'/>
<attribute name='connectorLength' svg:animatable='true' svg:inheritable='false'>
<ref name='Number.datatype'/>
</attribute>
</optional>
</define>
Attribute definitions:
An IRI reference to an element within an SVG document, which represents the visual and semantic starting point of a connection. An invalid IRI reference is an unsupported value. An empty attribute value (n1="") disables rendering of the element. The lacuna value is the empty string.
Animatable: yes.
An IRI reference to an element within an SVG document, which represents the visual and semantic ending point of a connection. An invalid IRI reference is an unsupported value. An empty attribute value (n2="") disables rendering of the element. The lacuna value is the empty string.
Animatable: yes.
An indicator for selecting a point element which is a child of the element indicated in the n1 attribute, as either an IRI reference to an id attribute value, or a string corresponding to a role attribute value. If an appropriate point element exists which matches the value of this attribute, that point shall serve as a candidate for the terminus of the connector stroke for that target element, in a manner described in the Automatic Connector Rendering algorithm. If this attribute is omitted, or if it does not match the value of an id or role attribute which is a child of the target element, the terminus of the connector stroke for that target element must be the centroid. The lacuna value is the empty string.
Animatable: yes.
An indicator for selecting a point element which is a child of the element indicated in the n2 attribute, as either an IRI reference to an id attribute value, or a string corresponding to a role attribute value. If an appropriate point element exists which matches the value of this attribute, that point shall serve as a candidate for the terminus of the connector stroke for that target element, in a manner described in the Automatic Connector Rendering algorithm. If this attribute is omitted, or if it does not match the value of an id or role attribute which is a child of the target element, the terminus of the connector stroke for that target element must be the centroid. The lacuna value is the empty string.
Animatable: yes.
A boolean value for indicating whether the connector is directed, i.e. whether it is a one-way connection. If the value of this attribute is "true", then . Note that the value of this attribute does not automatically render an arrow or directional indicator on the connector element; the author must still provide a suitable graphical shape with the right positioning and orientation properties and apply it to the connector element via the marker-end property. The lacuna value is "false".
Animatable: yes.
The definition of the stroke of a connector. See Connector data. An empty attribute value (d="") or missing attribute automates the rendering of the element according to the algorithm in Automatic Connector Rendering. The lacuna value is the empty string.
Animatable: yes, but see restrictions described in Animating connector data.
The authoring length of the connector, in user units. This value is used to calibrate the user agent's own distance-along-a-path calculations with that of the author. The user agent shall scale all distance-along-a-path computations by the ratio of 'pathLength' to the user agent's own computed value for total connector length. 'pathLength' potentially affects calculations for motion animation and various stroke operations.
A negative value is an unsupported value.
Animatable: yes.
See attribute definition for description.
Animatable: yes.
See definition.
When the d attribute is not specified, the user agent must render the connector element as a line of one or more segments between the elements indicated by the n1 and n2 attributes, passing through the point element children of the connector element in document order, and with the terminus of each end of the connector at the appropriate point of the target elements.
The target elements of a connector are those elements indicated by the n1 and n2 attributes of the connector element. By default, an automatically-generated connector terminates at the centroid of a target element. Markers on the connector, such as arrowheads, may be obscured by the target element if the target element is later in document order than the connector; authors may generically position markers along the connector using the marker element's refX and refX attributes to prevent them from being obscured, though this may leave artifacts of the connector stroke between the end of the marker and the target element.
A more sophisticated and visually clear method for indicating the terminus of the connector is to provide connection points on the target shape in the form of point elements. One or more point elements may be declared as child nodes of the target elements; point child elements are used by the user agent as Each of these point elements may have an id attribute and role attribute which can be used to
'none', the element is not rendered. Note that the logical connection established by the element still exists, and must be exposed to the user as a navigation option, described below.'none'. Automatic rendering must not be done, even if the connector does not intersect with one or either of the target elements.@@ describe what happens for 'use' elements with child 'point' elements
@@ provide an API to get the start and end points (coordinates and point element) of the automatic connector?
@@ add '@r' or '@attraction' to the 'point' element for use in rounded corners on connectors?
@@ add '@autoclip' to marker to trim the stroke past the end of the marker?
Interpolated connector data animation is only possible when each normalized connector data specification within an animation specification has exactly the same list of connector data commands as the 'd' attribute after normalization. This means that each connector data specification and the 'd' attribute would have the exact same list of commands if normalized as defined in Connector Normalization. If an animation is specified and the list of connector data commands is not the same, then the animation specification must be ignored as unsupported. The animation engine shall interpolate each parameter to each connector data command separately based upon the attributes on the given animation element.
Non-interpolated (i.e. calcMode="discrete") connector data animation is always possible.
A connector is defined by including a 'connector' element which contains a 'd' attribute, where the 'd' attribute contains the moveto, line, curve (both cubic and quadratic Béziers) and closeconnector instructions.
Warning! This section is a placeholder for reference, and is not part of the connectors spec.
When a 'use' references another element which is another 'use' or whose content contains a 'use' element, then the deep cloning approach described above is recursive. However, a set of references that directly or indirectly reference a element to create a circular dependency is an error, as described in the References section.
<define name='use'>
<element name='use'>
<ref name='use.AT'/>
<ref name='use.CM'/>
</element>
</define>
<define name='use.AT' combine='interleave'>
<ref name='svg.Properties.attr'/>
<ref name='svg.FocusHighlight.attr'/>
<ref name='svg.Core.attr'/>
<ref name='svg.Conditional.attr'/>
<ref name='svg.Transform.attr'/>
<ref name='svg.XLinkEmbed.attr'/>
<ref name='svg.Focus.attr'/>
<ref name='svg.External.attr'/>
<ref name='svg.XY.attr'/>
</define>
<define name='use.CM'>
<zeroOrMore>
<choice>
<ref name='svg.Desc.group'/>
<ref name='svg.Animate.group'/>
<ref name='svg.Handler.group'/>
</choice>
</zeroOrMore>
</define>
Attribute definitions:
The x-axis coordinate of one corner of the rectangular region into which the referenced element is placed.
The lacuna value is '0'.
Animatable: yes.
The y-axis coordinate of one corner of the rectangular region into which the referenced element is placed.
The lacuna value is '0'.
Animatable: yes.
An IRI reference to an element/fragment within an SVG document. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.
Animatable: yes.
See attribute definition for description.
Animatable: yes.
See definition.
The 'point' element defines a point based on a vertical and a horizontal coordinate, within the current user coordinate system.
The 'point' element simply defines a mathematical point, without width or height, and thus does not itself render, regardless of any styling applied to it. However, if the ‘marker’ property is specified on the 'point' element, the marker will render, and will be affected by any styling applied to the 'point' element, if applicable. For example, if the ‘marker’ element indicated by the ‘marker’ property has a ‘markerUnits’ attribute value of 'strokeWidth', the value of the ‘stroke-width’ attribute on the 'point' element will affect the rendering of the marker as if it were also applied to the 'point' element. @@ should we allow the author to control the orientation, as well? Should it be yoked to the orientation at the same point on the parent shape (I think this is too complicated)?
This element is intended to serve as a reference point for calculations, orientation, or animations, or for use in direct conjunction with other elements. It may be declared as a child of any other element, or directly in the root. When declared as a child of a rendering element, any marker instances for the 'point' element will be drawn on top of the parent element, in document order.
In the context of the connector element, as described in
<define name='point'>
<element name='point'>
<ref name='point.AT'/>
<zeroOrMore><ref name='shapeCommon.CM'/></zeroOrMore>
</element>
</define>
<define name='point.AT' combine='interleave'>
<ref name='svg.ShapeCommon.attr'/>
<ref name='svg.XY.attr'/>
</define>
Attribute definitions:
The x-axis coordinate of the point. The lacuna value is '0'.
Animatable: yes.
The y-axis coordinate of the point. The lacuna value is '0'.
Animatable: yes.
See attribute definition for description.
Animatable: yes.
See definition.
Example point01 consists of a 'point' element which is a child of another element, and styled with a marker.
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100%" height="100%" viewBox="0 0 200 150">
<title>Point Marker</title>
<desc>Example point01: An illustration of a marker on a 'point' element
which is a child of another element.</desc>
<defs>
<marker id="dot"
viewBox="0 0 10 10" refX="5" refY="5"
markerUnits="strokeWidth"
markerWidth="5" markerHeight="5"
orient="auto">
<circle cx="5" cy="5" r="2.5" fill="cornflowerblue" stroke="blue" />
</marker>
</defs>
<polygon id="decision" points="100,50 150,75 100,100 50,75" stroke="black" fill="gray">
<point x="100" y="50" stroke-width="2" marker="url(#dot)"/>
</polygon>
</svg>
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:
Defines if an element can get keyboard focus (i.e. receive keyboard events) and be a target for field-to-field navigation actions. (Note: in some environments, field-to-field navigation can be accomplished with the tab key.)
The attribute value can be one of the following:
The lacuna value. Equivalent to 'false', except that it must be treated like 'true' for the following cases:
The 'a' element.
Text content block elements with 'editable' set to 'simple'.
Elements that are the target of an animation whose begin or end lists include an eventbase timing specifier triggered by the following user interface events: DOMFocusIn, DOMFocusOut, DOMActivate.
Elements that have an event listener registered on one of the following user interface events: DOMFocusIn,
DOMFocusOut, DOMActivate.
Informative note: Event listeners for the listed events can be added to elements that are the 'target' or 'observer' of a 'listener' element, the parent element of a 'handler' element if it has an 'ev:event' attribute as well as by using script.
Animatable: yes.
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 is '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:
The SVG user agent must not navigate to an element which has display="none". (An element which has display="none" is not focusable.)
The SVG user agent must allow navigation to elements which are not visible (i.e. which has a 100% transparency or which is hidden by another element).
The SVG user agent must allow navigation to elements which are located outside of the current viewport. In this case it is recommended that the SVG user agent should change the current viewport so that the focused element becomes visible.
SVG's flattened notion of field navigation shall extend to referenced content and shadow trees as follows:
Focusable elements within the content referenced by a 'use' element participate in field navigation operations using the flattened focus model. (Note: If a referenced group contains a focusable element, and that group is referenced by two 'use' elements, then the document will have two separate focusable fields, not just one.)
If an 'animation' element references an SVG document, then all of the focusable fields defined within the referenced SVG document participate in field navigation operations using the flattened focus model.
Focus navigation shall behave as specified:
When the document is loaded the focus is first offered to the SVG user agent.
Once the SVG user agent releases focus, then focus passes to the entity that first matches the following criteria:
If the focus is held by an element in the document, then the next element in navigation order shall be the entity that first matches the following criteria:
If the focus is held by an element in the document, then the previous element in navigation order shall be the entity that first matches the following criteria:
For stand-alone SVG documents, the SVG 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 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.
Attribute definitions:
Specifies the next element (when using 'nav-next') or previous element (when using 'nav-prev') in the focus ring.
The attribute value for 'nav-next' and 'nav-prev' can be one of the following:
Animatable: yes.
Each of these eight attributes specifies an element to receive focus when navigating in a particular direction. For each of the attributes, the direction for which an element is being specified for navigation is suggested by the name of the attribute. The following table lists these directions explicitly:
| Attribute name | Direction |
|---|---|
| 'nav-up' | ↑ upward |
| 'nav-up-right' | ↗ up-and-rightward |
| 'nav-right' | → rightward |
| 'nav-down-right' | ↘ down-and-rightward |
| 'nav-down' | ↓ downward |
| 'nav-down-left' | ↙ down-and-leftward |
| 'nav-left' | ← leftward |
| 'nav-up-left' | ↖ up-and-leftward |
The value for each of these attributes can be one of the following:
Animatable: yes.
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.2" baseProfile="tiny"
viewBox="0 0 220 40">
<title>Media Channel Navigation User Interface</title>
<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:
Whenever the focus is located on a program which is at the beginning of the timeline of a given channel, there are 3 options when the user wants to go to the previous focusable item (i.e., the user presses the "Reverse-Tab" key on most desktop computers):
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.
Whenever the focus is located on a program which is at the end of the timeline of a given channel, there are 2 options when the user wants to go to the next focusable item (i.e., the user presses the "Tab" key on most desktop computers):
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.
Whenever the focus is located on "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 user agent because there is no more focusable element in the document order.
On a device which provides a 4-way navigation system (i.e. a joystick for instance), here are the interesting behaviors:
Whenever the focus is located at the beginning of the timeline of a given channel, when the user wants to go "Left", focus remains on the same element because both element 'g' with id="Chan1Prog1" and element 'g' with id="Chan2Prog1" have nav-left="self".
Whenever the focus is located on "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 user agent should change the current viewport so that the new focused element becomes visible.
 |
 |
|
Before element "Chan1Prog2" receives focus |
After element "Chan1Prog2" receives focus (UA scrolls automatically) |
On element 'g' with id="Chan2Prog1", there is a value nav-right="auto". This value is the default one for navigation attributes and therefore the behavior is the same as if no 'nav-right' attribute was defined. This value 'auto' means that it's up to the SVG user agent to choose which focusable element should receive focus when the user wants to go 'right'.
Automated highlighting upon focus can be specified using the 'focusHighlight' attribute. This hint indicates whether the SVG user agent should highlight an element on focus. The highlighting method is implementation dependent and the SVG user agent should pick a method that works well for varying content. This attribute is available on all graphical and container elements.
Specifies whether a SVG user agent should highlight an element on focus.
The attribute value can be one of the following:
The lacuna value. This indicates that the element should be highlighted on focus. The highlighting method is left up to the SVG user agent.
The SVG user agent should not highlight this element on focus.
Animatable: no.
<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink='http://www.w3.org/1999/xlink'
version="1.2" baseProfile="tiny" viewBox="0 0 210 80">
<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:
Highlight of the focus on the first two textual links is left up to the SVG user agent (underline the text, highlight of the bounding box, change color of the text, ...) since the lacuna value is focusHighlight="auto". This text may have been retrieved from a database where there may be no notion of graphical styling or no way to know in advance the kind of focusable elements it contains, therefore the author doesn't handle focus highlight on that part of the document.
Highlight of the focus on the two graphical buttons is designed by the author and therefore the SVG user agent doesn't need to highlight it as well. Therefore, focusHighlight="none" is used to disable the default focus highlight behavior.
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 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 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
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" && evt.target.id == "myRectNewDisplayAnim")
{
myRect1.setTrait("nav-right", "url(#myRectNew)");
myRect3.setTrait("nav-left", "url(#myRectNew)");
}
else if (evt.type == "endEvent" && evt.target.id == "myRectNewDisplayAnim")
{
myRect1.setTrait("nav-right", "url(#myRect2)");
myRect3.setTrait("nav-left", "url(#myRect2)");
}
]]></handler>
</svg>
The schema for SVG Connector 1.0 is written in RelaxNG [RelaxNG], a namespace-aware schema language that uses the datatypes from XML Schema Part 2 [Schema2]. This allows namespaces and modularity to be much more naturally expressed than using DTD syntax. The RelaxNG schema for SVG Filter 1.2 may be imported by other RelaxNG schemas, or combined with other schemas in other languages into a multi-namespace, multi-grammar schema using Namespace-based Validation Dispatching Language [NVDL].
Unlike a DTD, the schema used for validation is not hardcoded into the document instance. There is no equivalent to the DOCTYPE declaration. Simply point your editor or other validation tool to the IRI of the schema (or your local cached copy, as you prefer).
The RNG is under construction, and only the individual RNG snippets are available at this time. They have not yet been integrated into a functional schema. The individual RNG files are available here.
The following interfaces are defined below: RandomInterface.
The RandomInterface interface corresponds to the 'RandomInterface' element.
interface RandomInterface : SVGElement {
readonly attribute InterfaceString foo;
};
The editors would like to acknowledge and thank the following people for substantive aid with this specification: Andrew Shellshear, David Dailey, Cyril Concolato, Erik Dahlström, Jonathan Watt, Anthony Grasso, Chris Lilley.