Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document specifies WICD Core 1.0, a device independent Compound Document profile based on XHTML, CSS and SVG.
Compound Document is the W3C term for a document that combines multiple formats.
WICD stands for Web Integration Compound Document and is based on the idea of integrating existing markup language formats in preference to inventing new markup.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The Compound Document Formats Working Group explicitly requests comments on this specification. Please send them to public-cdf@w3.org. This list is archived and acceptance of this archiving policy is requested automatically upon first post. To subscribe to this list send an email to public-cdf-request@w3.org with the word subscribe in the subject line.
This document has been produced by the Compound Document Formats Working Group as part of the Rich Web Client Activity within the W3C Interaction Domain.
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
Per section 4 of the W3C Patent Policy, Working Group participants have 150 days from the title page date of this document to exclude essential claims from the W3C RF licensing requirements with respect to this document series. Exclusions are with respect to the exclusion reference document, defined by the W3C Patent Policy to be the latest version of a document in this series that is published no later than 90 days after the title page date of this document.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
1 Introduction
1.1 Scope of this
Specification
1.2 Related
Specifications
1.3 Relationship to
Referenced Specifications
2 Root, Parent and Child
Documents
2.1 Referencing Child
Documents
3 Scalable Child
Elements
3.1 Supported
Scalable Child Element Formats
3.2 Scalable Child
Element Use Cases
3.3 Scalable Child Element Layout
4 Other Child Element
Formats
5 Hyperlinking
5.1 Link
Activation
6 Focus Handling
6.1 Focus
Modes
6.2 Focus Event triggered
Child Element Animations
6.3 Focus
Navigation Models
7 Font Support
7.1 System
Fonts
7.2 Font
Naming
7.3 Font
Sharing
8 Content Encoding, Packaging and
Transferring
8.1 Content
Encoding
8.2 Content
Packaging
9 Synchronization Support
9.1 Temporal
Synchronization of Media
9.2 Timeline Initialization
9.3 Play Animations while Document is
loading
10 Events
10.1 XHTML Event Attributes
10.2 Attaching
Events to WICD Documents
11 Intended Layout
11.1 Media
Queries
11.2 Style
sheet being provided for specific agent classes
11.3 No style
sheet being provided to handheld agents
11.4 Switching
off mousepointer emulation for handheld content
A Definitions
B Conformance
C References
D Authoring Guidelines
(Non-Normative)
E Acknowledgements
(Non-Normative)
F Changes Log (Non-Normative)
(This section is informative)
This document defines a Web Integration Compound Document (WICD) Core, which is based upon the Compound Document by Reference Framework 1.0 (CDRF) and serves as a foundation for the creation of rich multimedia content profiles and describes rules for combining Extensible Hypertext Markup Language (XHTML), Cascading Style Sheets (CSS), and Scalable Child Element formats, such as Scalable Vector Graphics (SVG) in a non device specific manner.
(This section is informative)
The image below shows the relation between the WICD and CDRF specifications.
CDRF describes generic rules and behavior for combining sets of standalone XML formats.
NOTE: The Compound Document Framework is language-independent. While it is clearly meant to serve as the basis for integrating W3C's family of XML formats within its Interaction Domain (e.g., CSS, MathML, SMIL, SVG, VoiceXML, XForms, XHTML, XSL) with each other, it can also be used to integrate non-W3C formats with W3C formats or integrate non-W3C formats with other non-W3C formats.
The WICD Mobile 1.0 profile is designed to enable rich multimedia content on mobile handset devices. It may also be appropriate for other handheld devices. However, WICD Mobile addresses the special requirements of mass-market, single-handed operated devices and enables publishers to target these type of devices without having to evaluate the user agent identification string. In this profile, child documents are embedded by reference (CDRF = Compound Document by Reference Framework).
WICD Mobile 1.0 builds upon WICD Core 1.0.
The WICD Full 1.0 profile is designed to enable rich multimedia content on desktop-type agents. It may also be appropriate for high capability handheld devices with a pointing device. In this profile, child documents are embedded by reference (CDRF).
WICD Full 1.0 builds upon WICD Core 1.0.
This document may contain clarifications, refinements, or specific implementation examples of content specified in referenced documents. Should there be a conflict with any text in this document and the referenced document, then the referenced document is the normative reference.
A document that references other documents is a parent document. A root document is the topmost parent document. A document is a child document, if it is referenced by other documents. A child document can be a parent document at the same time.
Any profile, conforming to WICD Core 1.0, must support XHTML as root document.
Different WICD profiles may support different versions of XHTML. Later versions of WICD Core may define additional root document formats.
In XHTML, there are many elements (like object, img, iframe) that are used to reference child documents. In a similar way, child documents can be referenced from CSS declarations.
Any profile, conforming to WICD Core 1.0, must support the XHTML <object> element as a means of referencing Scalable Child Elements.
Scalable Child Elements appear as rectangular objects, which in their normal presentation, can always fit the screen or destination box, because they are scalable and usually meant to be viewed as a whole. Scalable Child Elements can be documents (e.g. SVG). They can also be non-documents (have a binary format or be applications).
Any profile, conforming to WICD Core 1.0, must support SVG documents as Scalable Child Element format.
Later versions of WICD Core may mandate additional formats. Different WICD profiles may support different versions of SVG.Scalable Child Elements can be referenced from a parent document as foreground objects, as background images or as overlay objects.
Any Scalable Child Element format must support these three use cases: Scalable Foreground Child Elements, Scalable Background Image and Scalable Overlay Objects (Sprites).
Scalable Foreground Child Elements are referenced using the XHTML <object> element. They appear on the main XHTML layer, just like bitmap images.
User agents must support Scalable Foreground Child Elements, which may be animating, interactive and may have embedded links.
The following example shows how a SVG document is referenced from a XHTML document:
<object data="icon.svg" type="image/svg+xml" width="100%" />
Using a param element with name="render", the document author can specify whether a frozen, static, or dynamic rendering is desired. The terms static and dynamic have the same meaning as in SVG. The term frozen implies a single conversion to a raster image. Dynamic rendering is the default behavior. The value of the param element is case sensitive. Unrecognized param values shall be treated as default values. If more than one "render" parameter is provided for an element, then only the last one shall be used.
Authors are encouraged to set the render param whenever referencing multiple non-animating child objects. This may allow user agents to implement performance and memory optimizations. For example, the storage space used by an SVG image might be reclaimed after a frozen rendering has been performed.
An <object> element <param> child element with name="render" and value="dynamic" shall result in a dynamic rendering. Links shall be activatable. Animations shall play, if the timeline has started. Modifications made by script shall update the rendering. The rendering shall also update, if the size of the rendering area changes.
An <object> element <param> child element with name="render" and value="static" shall result in a static rendering. Links shall not be activatable. Animations shall not play. Modifications made by script shall update the rendering. The rendering shall also update, if the size of the rendering area changes.
An <object> element <param> child element with name="render" and value="frozen" shall result in a one-time static rendering to a raster image. Links shall be not be activatable. Animations shall not play. Modifications made by script shall update the rendering. The rendering shall also update, if the size of the rendering area changes.
The default value for <param name="render"> is "dynamic".
Example:
<object data="icon.svg" type="image/svg+xml" width="100%" > <param name="render" value="static" /> <object>
For SVG child objects, the document time used for rendering a frozen or static image shall be that given by the SVG 'snapshotTime' attribute. If no 'snapshotTime' is present in the animation, a document time of zero (0) must be used. Other Scalable Child Element formats may use a similar mechanism. Scalable Child Elements lacking such capability should use a time of zero (0) for still-image rendering.
User agents must support Scalable Child Elements (e.g. SVG's) to be used as CSS background images.
Agents may support declarative animated background images. A Scalable Child Element, used as a background image, will not provide support for scripting and interaction, such as zooming, panning, linking and user interaction events. Authors should only provide non-animating or non-interactive animating content for use as a background image. If supported, a 'snapshotTime' should be authored. Agents that do not support animated background images, may generate a still-image presentation of the provided object. A still-image presentation of an animating object may be generated per description in 3.2.1.1 Still-Image Rendering, by using the "render/static" functionality.
The following example shows how a SVG document is placed on the XHTML background, using the CSS background-image attribute:
Use of background-image:
<html>
<body style="background-image:url(background.svg);background-attachment:fixed">
<p>This in foreground</p>
</body>
</html>
The following example will set an SVG image background.svg as a fixed, non-repeating (i.e. not tiled) non-scrolling ('pinned') background, using the individual properties:
Pinned background:
body {
background-color: white;
background-image: url(background.svg);
background-repeat: no-repeat;
background-attachment: fixed;
background-position: center center
}
or using the shorthand :
Pinned background, shorthand:
body { background: white url(background.svg) no-repeat fixed center center }
If background.svg has its width and height set in px, then this is well-defined. If the default is declared (width="100%" height="100%"), then it will display as large as possible, where the background area to be be covered is treated as a viewport.
WICD user agents must support content layering using CSS absolute positioning in x, y and z order. This will detach a child element from the main XHTML layer and create a new transparent layer.
WICD user agents must make all visible and focusable points in the XHTML layer and the positioned Overlay Object reachable and activatable.
WICD user agents must support transparency for Overlay Objects.
Scalable Overlay Objects referred to from the XHTML page may be put in front of, or behind, the default XHTML layer.
Any transparent areas in the Overlay Object and in the XHTML root document must allow the layer behind to be visible.
A detailed description of the stacking level for different layers can be found in Appendix E in the [CSS21] specification.
Example:
.svg-sprite
{
position: absolute;
left: 0;
top: 0;
width: 100%;
border: 0px;
}
<body>
<div>
<object class="svg-sprite" data="sprite.svg" type="image/svg+xml" />
<p>Hello 1</p>
<object data="foo.svg" type="image/svg+xml" width="100" height="50" />
<p>Hello 2</p>
</div>
</body>
User agents must support interactivity in overlay elements.
User agents must support overlay images with embedded links.
Scalable Child Elements are referenced by using width and/or height attributes with values relative to their destination box (which may be the full available rendering area (canvas) of the user agent or maybe a table cell). In case the Scalable Child Element has it's own fixed aspect ratio, it is enough to provide only one size attribute value (width -or- height) of the object element (through CSS or directly in XHTML), when referencing it.
[CSS21] contains a detailed description of the required Visual formatting model.
If only one size attribute value is provided, a fixed aspect ratio child element will get 'rightsized' proportionally, by being scaled to fit into the destination box.
Example:
<object data="icon.svg" type="image/svg+xml" width="100%" />
The following illustration shows how a square, scalable element with a fixed aspect ratio, has being scaled into an available area with a requested width of 100%.
The following illustration shows, how two scalable elements with fixed aspect ratio, have been scaled into an available area, both with a requested width of 100%.
When an embedded child document fragment (such as SVG) specifies its horizontal width and omits a height specification, then the actual extent of the image is defined by the content within it. On placing such an image into a user agent, the viewport is usually a window on a 'galley' view of the entire document. In such cases, the element should float to the top of the available galley as no height is specified. This is shown in the illustrations above. Where the aspect ratio rules for the embedded graphic force the width to be less than the user agents window width, the image should be centered horizontally (see 'Leftover Margins' below). If the dominant text layout direction is vertical text, the aforementioned rules should be adapted to the different layout flow direction in the case of 'height' being the only sizing specification.
Rendering scalable, but fixed aspect-ratio content into a fixed-sized destination area will often result in leftover margins. In case of SVG child documents: When the viewbox and the resulting viewport do not have the same aspect ratio, and preserveAspectRatio is not set to 'none' (the default being 'xMidyMid') some space is left in between the borders of the viewbox and that of the viewport.
The following illustration shows, how a square, scalable element, with a fixed aspect ratio, has been scaled into an available area (destination box) with a requested width of 100%. Because the viewport has a wider aspect ratio than the child object's viewBox, the viewport and viewBox cannot align exactly. Assuming the SVG content's root 'svg' element has 'preserveAspectRatio' of 'xMidYMid meet' (the default value), the child element's viewport will gain the width and height of the destination box, but the width and height of the resulting viewbox will be equal to the height of the available area.
Leftover margins will appear to the left and right of the child element's viewbox.
The following illustration shows, how a square, scalable element, with a fixed aspect ratio, is being scaled into an available area with a requested height of 100%. Because the viewport has a taller aspect ratio than the child object's viewBox, the viewport and viewBox cannot align exactly. Assuming the SVG content's root 'svg' element has 'preserveAspectRatio' of 'xMidYMid meet' (the default value), the child element's viewport will gain the width and height of the destination box, but the width and height of the resulting viewbox will be equal to the width of the available area.
Leftover margins will appear above and below the child element's viewbox.
The child content must render the entire viewport, including any leftover margins.
In the absence of a background color or image on the element that established the viewport (abbr html:object or svg:svg) it's background is transparent. In order to maximize the visual quality of the content, the parent document should be visible through the leftovers (as well as through the child content itself where it is transparent).
A defined background applies to the entire viewport (including the leftovers) so that content that spills outside of the viewbox into the leftovers is still on the correct background.
Any UI event, such as a mouse click, that hits the leftover areas, is dispatched in the same manner as UI events over non-leftover areas (i.e., to the child document)
(This section is informative)
The rendering of a WICD document may result in an overlap of content, originating from different namespaces, for example, an SVG graphic on top of some XHTML. Some user agents may provide monolithic implementations for all namespaces, whilst others may render each namespace by a separate block of executable code. For example, by providing a so-called 'plug-in' interface for each renderer.
In the case where an existing XHTML implementation is to be extended via the addition of a namespace supporting transparency (such as SVG) it is possible to provide a combined output using alpha-compositing by allowing the SVG implementation access to the output of the XHTML rendering. This would assume the XHTML base layer is opaque and the SVG layer on top would be responsible for retrieving the rendered output pixel data from the XHTML renderer and combining it with the SVG to support SVG layering on top of the XHTML. Such an approach removes the need to add any transparency support to an existing XHTML implementation whilst adding support for transparency support when new namespaces are added.
Such an approach to supporting a foreground transparency layer can be easily implemented given access to the result of rendering output of an existing implementation. In order to support such a feature, the XHTML implementation would need to notify a plugin that its rendering is complete.
If animation were supported in XHTML, then it would also be a requirement that the plugin is notified every time a change occurs in the rendered output. Such a change would most likely require an off-screen buffer to be used in order to 'double-buffer' so as to avoid flicker.
Transparency in foreground Scalable Child Elements should be supported when rendered over XHTML background content.
Transparency in Scalable Child Elements should be supported when a foreground Scalable Child Element is rendered over a background Scalable Child Element.
Any audio or video format supported by the user agent must also be supported for use with the <audio> and <video> elements in SVG and the <object> element in XHTML.
WICD compliant agents should support seamless hyperlinking originating from any of the supported document formats to all supported content types. If it is possible to link from XHTML to some other supported content type (for example: XHTML linking to RSS, Java or multimedia content), then it should also be possible to link to the same content types from any other supported document format which supports hyperlinking (for example: SVG linking to RSS, Java or multimedia content).
If linking from XHTML to any of the supported content types will result in content type specific treatment, then linking to that same format from any other supported document format (such as from SVG) should result in the same content type specific treatment. If a WICD compliant agent supports linking from XHTML to URI schemes other than http:// (for examples wtai://, tel://, mailto://, etc.), then these URI schemes should also be supported, when linked-to from any of the other supported document formats that support hyperlinking (such as from SVG).
All URI schemes, supported for hyperlinking and the related functionality, should be supported, independent of the originating document format.
(This section is informative)
Link activation behavior for hyperlinks within a child object is defined by the child object's relevant language specification. For example, if the parent document is XHTML and the child object is SVG, then the SVG specification defines the behavior for what happens when a hyperlink within the SVG object is activated.
Nested hyperlinks are more complicated. The following illustrates nested hyperlinks. Suppose the parent document is XHTML as follows:
<!-- parent.html --> <html:a href="LargeMap.html"> <html:object type="image/svg+xml" data="child.svg" /> </html:a>
And the child SVG document contains the following:
<!-- child.svg --> <svg:a xlink:href="DetailedCountyMap.html"> <svg:text>county map</svg:text> </svg:a>
The <svg:text> element is surrounded by two hyperlinks: a near one defined within the same SVG file and a farther one defined within the parent XHTML file. Nested hyperlinks for Compound Documents are processed in a manner consistent with the following model:
The implication is that the behavior of nested hyperlinks depends on how the hyperlink is activated. Here are some examples which illustrate common possibilities:
(This section is informative)
Since the child document's language specification defines hyperlinking behavior, here are recommendations for language specifications for languages which might be used as child documents within the context of Compound Documents:
If specifications provide a mechanism for hyperlinking they must also define a way to target specific frames. In addition it must be defined how the current document can be replaced (the document the link is defined in), the parent document and the root document.
Relevant language specifications should include a mechanism for defining the possible targets for the hyperlink. For example, the HTML4 specification includes a 'target' attribute on the 'html:a' element which supports targets of _blank, _self, _parent, _top and <frametarget> (see http://www.w3.org/TR/html401/types.html#type-frame-target). The SVG Tiny 1.2 specification also supports a 'target' attribute on the 'svg:a' element with the same list of possible values, except with the addition of an "_replace" keyword (see http://www.w3.org/TR/SVGMobile12/linking.html#AElementTargetAttribute). The WebCGM specification also supports targets of _blank, _self, _parent, _top, _replace and <frametarget> (see http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_2_2).
NOTE: The keyword _self does not mean the same in SVG as it does in HTML. In HTML it replaces the current document and in SVG it replaces the parent document.
Relevant language specifications should provide a clear definition of the behavior of the "_self" keyword. For SVG and WebCGM, when there is a parent HTML document which references an SVG or WebCGM graphic via html:object, the "_self" keyword causes the HTML document to be replaced by the linked content. However, when a parent HTML document references a child HTML document via html:object or html:iframe, some HTML browsers implement the "_self" keyword, so that only the child HTML document is replaced. Because of this, relevant language specifications should be clear about UA behavior in response to the "_self" keyword. One strategy to consider: if the primary usage scenario falls under the category of "replaced element" (see http://www.w3.org/TR/REC-CSS2/conform.html#replaced-element), as is the case with SVG, then defining "_self" to replace the parent document is appropriate.
For language specifications such as SVG which define "_self" to replace the parent document, it might be appropriate to support a "_replace" feature similar to what exists in SVG Tiny 1.2 and WebCGM. This feature causes a hyperlink to replace the child document only and to leave parents and other ancestor documents unchanged. (For example, if an SVG document is referenced by a parent HTML document via an 'html:object' element, and if the SVG document has an 'svg:a' element with target="_replace", then when that hyperlink is activated, the SVG document gets replaced but there are no changes within the parent HTML document.)
Sometimes in industry practice a plugin user agent is used to handle certain types of child documents. For example, plugins might handle SVG or MathML child documents. In these scenarios the plugin may only be able to handle particular formats via the "_replace" keyword. (For example, a MathML plugin might be able to handle only MathML content.) Because of this, relevant language specifications, that support "_replace" (or alternative syntax for the same feature), should clearly specify requirements, when "_replace" references content of the same type and content of other types. (For example, only content of the same type can be referenced with "_replace", or any type can be referenced with "_replace", but then error-processing must be defined for unknown or unsupported content.)
(This section is informative)
One potential area of ambiguity in the context of Compound Document is the meaning of the "_self" and "_parent" keywords. (See HTML4's definition at http://www.w3.org/TR/html401/types.html#type-frame-target and SVG Tiny 1.2's definition at http://www.w3.org/TR/SVGMobile12/linking.html#AElementTargetAttribute). For example, suppose a parent XHTML document references a child SVG document via an 'html:object' element and suppose the SVG document has an 'svg:a' element with target="_self". The SVG Tiny 1.2 specification says that "_self" causes both the XHTML parent frame and the child SVG to be replaced when the hyperlink is activated.
However, there are potential ambiguities if the parent language format supports its own particular notions of nested regions (e.g., frames, panes or sub-documents). It is strongly recommended that relevant language specifications clearly define how its own nested region features relate to the hyperlinking keywords _self, _parent, and _top.
WICD compliant user agents must provide the ability for users with a keyboard or joystick input device (and without a pointing device), to navigate to any focusable element in the root document and all of its descendants.
The language specifications that are used with this framework define what elements are focusable. For example, focusable items in an SVG document are defined by the SVG 1.2 focusable attribute [SVGMobile12, Element focus].
In XHTML, <object> elements are, by default, focusable. However, authors can remove such elements from the tabbing order, by setting the element's tabindex attribute to "-1". This may be useful, if selected <object> elements, for instance non interactive SVG images, are not supposed to participate in the focus traversal.
<object data="static-icon.svg" type="image/svg+xml" width="50%" tabindex="-1" />
In some situations, a user agent may allow the user to navigate focus to child elements which would not normally be selectable. For instance, a user agent may allow a user to navigate focus to a PNG image for the purposes of saving the image. Normally, however, a user agent should support the author's intent and not make any extra child elements focusable.
This section defines two modes of child element focusability.
By using the <object> element's child <param> element with the attribute name="focusable", the author of the parent document can specify whether "flat" or "hierarchical" focusability is desired for a child.
If more than one "focusable" parameter is provided for an element, then only the last one shall be used. Unrecognized param values shall be ignored.
The default focus mode is "hierarchical".
Authors use <param name="focusable" value="flat" />, to make focusable elements of the child become direct participants of the parents focus traversal. Access keys, defined by child documents, will not become accessible to the user, if they are also defined by the parent or by some other child element.
<object data="multifocus.svg" type="image/svg+xml" width="50%"> <param name="focusable" value="flat" /> </object>
Authors use <param name="focusable" value="hierarchical" /> to select hierarchical (activatable) focus handling for a referenced child. A user, navigating to such a child element, will have the option to activate it, or to move on, to the next focusable element. Activating the child, will provide the user with access to the child's interactivity, it's focusable elements, such as embedded links and it's access keys. The user must deactivate an activated child element, in order to gain access to the parents focus traversal again.
<object data="interactive.svg" type="image/svg+xml" width="50%"> <param name="focusable" value="hierarchical" /> </object>
Some types of child content will have to be "hierarchical", to properly function in the context of a Compound Document. Trying to make such child content become part of the parents "flat" focus navigation, may result in situations, where a user, using a keyboard or joystick input device, may get trapped inside a child element, with no ability to leave it again. This may happen, if the child content consumes some (or all) key events, used by the user agent focus traversal management. For instance, if key events are handled by script (or maybe by Java code). Or, for example, when the child content enables zoom and pan functionality. A parent document author may also choose to make a child element "hierarchical" for other, more practical reasons. For instance, when the child has too many focusable sub elements, for the parent document to be comfortably usable.
An example of focus event triggered animations is the implementation of scalable buttons which render their own visual feedback. Such buttons are allowed to contain animation, but no interaction. They will provide a scalable alternative to the use of images as the source of links that can be traversed.
Focus events are enabled for each child content by setting the "animation" object element parameter:
<object data="focus-button.svg" type="image/svg+xml"> <param name="animation" value="onfocusevent" /> </object>
With the "animation" parameter set to "onfocusevent",
the child content must render the first frame for time zero (0).
If the root element does not have focus, then the root element must then be paused at time zero(0).
Upon receiving focus, the root element is resumed.
Upon losing focus, the root element is paused.
The default animation mode is "none".
The following SVG example applies to declarative animation:
<svg id="SVGRoot">
...
<rect ... >
<animate begin="SVGRoot.focusin" ... />
<animate begin="SVGRoot.focusout" ... />
</rect>
...
</svg>
The following XHTML code makes use of focus events in order to implement SVG child document rendered focus animations on multiple anchor elements. The user agents default focus outline is disabled using CSS.
<style type="text/css">
a.svglink:focus { outline: none }
</style>
<object type="image/svg+xml" data="header.svg" /> <!-- defaults to 'play' -->
<a href="foo1.html" class="svglink">
<object type="image/svg+xml" data="foo1.svg">
<param name="animation" value="onfocusevent" />
</object>
</a>
<a href="foo2.html" class="svglink">
<object type="image/svg+xml" data="foo2.svg">
<param name="animation" value="onfocusevent" />
</object>
</a>
The 'focusin'-animation does not timeout and may loop any number of times.
The 'focusout'-animation should be limited to one second.
The 'focusout'-animation must not loop.
(This section is informative)
This section describes several focus navigation models. Device specific WICD profiles may reference this section and may require implementation of one of the focus navigation models.
Focus Navigation can be one dimensional (linear focus ring). And on devices with a multidirectional input device (like a joystick), focus navigation can also be two dimensional (spatial).
In addition, focus navigation in a Compound Document can be hierarchical (6.1.2 Hierarchical Focus) or flat (6.1.1 Flat Focus). This results in four alternative focus navigation models:
The different models are described below. Several illustrations show how focus may travel from the first focusable element in a parent document ("XHTML Link 1") to the last focusable element ("XHTML Link 8"). There is always at least one path traveling through all focusable elements of a Compound Document. In case of two dimensional focus navigation, there may be multiple ways to navigate from the first focusable element to the last.
Desktop agents, tablet's and PDA's usually allow navigation of a web document using a pointing device (mouse or stylus). Additionally, on desktop agents, the tab key can be used to navigate over focusable elements. Here, all focusable elements of a single Web document are chained in one linear path, based on the order of occurrence in the source document. This creates the so-called focus navigation ring, where advancing over the last focusable element brings the focus back to the first focusable element.
In the example shown above, the XHTML parent document contains it's own focusable elements, as well as one SVG child element with focusable sub elements. Focus navigation starts from "XHTML Link 1". All focusable elements of the parent XHTML document are included in one, linear focus traversal path. The child is made accessible as one single focusable element, initially. It's focusable sub elements are not flattened into the parent document. The child needs to be manually activated by the user, for it's focusable sub elements to become accessible. An activated child has to be deactivated, for the focus to be brought back up to the level of the parent XHTML document. Deactivating a child element will make the SVG child element gain focus again as a whole. Advancing the focus further will then move focus to "XHTML Link 5".
In this 2nd model, focusable elements of a child are flattened into the focus traversal path of the parent.
As shown in the above illustration, focus moves directly from "XHTML Link 4" to "SVG Link 1". Flattened child elements do not get focused as a whole. No manual activation of a child element is required. Infact, content authors may make it impossible for users to visually detect any borders between the parent document and flattened child elements.
In this 3rd model, focus can travel freely in any direction as long as there is another focusable element. The next focusable elements are always calculated, after a focus advance event is triggered by the user. This must be done in realtime, because scripts and animations may change presentation and location of focusable elements at any time. However, child elements do get focused as a whole and will need to be activated, for their sub elements to become accessible.
In this model, focus navigation events may also be used to scroll the document. This is needed when the user agent implements scrolling functionality for documents that cannot be fully displayed.
In the illustration aboce, there are multiple ways of navigating through the Compound Document. Focus may travel from "XHTML Link 1" to "XHTML Link 3". But it may also travel from "XHTML Link 1" to "XHTML Link 2". Focus traversal does not relate to the order of focusable elements in the source documents. Instead, focus traversal relates to the rendered location of neighboring focusable elements.
This model is a combination of the two previous models. Focus can travel freely in any direction and focusable child elements may be flattened into the focus traversal path of the parent. A child with flattened elements does not get focused as a whole. It does therefore not need to be activated by the user.
The illustration above only shows one of many ways focus may travel through a Compound Document. Here, focus travels from "XHTML Link 1" down to "XHTML Link 3" and further down to "SVG Link 1". Child element activation is not required. Another movement down will move the focus directly to "SVG Link 3". The user can now move right to "SVG Link 4" and then down again, to "XHTML Link 6" and "XHTML Link 8".
The Current Focus Point Algorithm can be used to implement two dimensional focus traversal. It is given, as an example implementation guideline. It allows for natural traversal over randomly arranged focusable elements in a WICD document, using a multidirection input device (i.e., joystick).
The following illustration shows a complex WICD document, with twentyfive focusable elements of different shape and size.
Current Focus Points are not shown to the user. They mark invisible coordinates on visited, focusable elements. These coordinates represent entry points, where traversal from a previous focusable element to the current focusable element has taken place. The following illustration shows a cutout of the above example. It shows the otherwise invisible Focus Points (1,2,3), as they are created, when a user navigates over focusable elements C -> D -> E.
When the user navigates to the right from element 'D', the Current Focus Point Algorithm calculates the next visible, focusable element to the right of the current Focus Point ('2', which was attached to element 'D' on focus entry from element 'C'). Element 'E' is found as a result and a Focus Point ('3') is attached to it. Element 'E' will now gain focus from element 'D'.
The following illustration highlights another cutout from the original example.
This cutout shows how focus travels along the following elements: K -> L -> K -> M -> L -> M -> N -> L -> N -> O. Ten Focus Points are created during this process. (Actually, Focus Points 1,2,3 are created on the same horicontal axis. The same is true for 4,5,6 and 7,8,9,10.)
One important characteristic of the Current Focus Point Algorithm is shown above: when leaving element 'L' going down, the focus always travels back to the element ('K','M' or 'N') from which element 'L' was before entered.
The Current Focus Point is always used as a starting point for the 6.3.5.1 Distance Function calculation towards neighboring focusable elements. The Current Focus Point Algorithm consists of three phases:
The distance function takes into account the following metrics:
The distance function (df) is:
df = dotDist + dx + dy + 2 * (xdisplacement + ydisplacement) - sqrt(Overlap)
Standalone components or renderers, such as SVG engines, do not always provide a default system font.
In the context of WICD Core, however, user agents must at least provide one default system font (including a missing glyph, AKA 'Replacement Character', Unicode notation U+FFFD) to all components, such as browsers, SVG engines and other renderers. If there isn't enough information in the font to display a particular character, then the missing glyph is used.
Whatever I18N support a WICD implementation provides should not be worse than that of the platform on which it is running.
WICD Core specification cannot mandate any particular font, nor a specific font technology. But it mandates the availability of at least one default font, available to all renderers. This allows content providers to print text in any component (or renderer), as simply as in XHTML.
The default system font(s) may be bitmap or vector based. Ideally, the same default system font(s) are made available for all components.
The following SVG sample markup must generate visible text:
<svg xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 250 50"
baseProfile="tiny" version="1.2">
<text x="20" y="20" font-size="30" fill="#000">Fahrvergnuegen</text>
</svg>
In both XHTML (using CSS) and SVG, font selection is done by the font-family property as described in CSS [CSS21].
In desktop usage, authors frequently choose fonts that they know are installed by default on particular platforms.
On mobile:
Conforming WICD Core 1.0 content should specify serif, sans-serif, or monospaced (three of the 'generic font families') as the last item in the list of font family names.
In SVG, named fonts, or subsets of fonts, can be supplied along with the content. This ensures that the desired look and feel is preserved regardless of the fonts available on a particular platform.
Content (XHTML, SVG, CSS, script, etc) may be compressed with gzip [RFC 1952] or deflate [RFC 1951]. Conforming WICD viewers must correctly support gzip-encoded and deflate-encoded content.
If they support HTTP/1.1, they must support these encodings according to the HTTP/1.1 specification [RFC2616]; in particular, the client must specify with an "Accept-Encoding:" request header [HTTP-ACCEPT-ENCODING] which of the encodings it accepts, including at a minimum gzip and deflate, and then decompress any gzip-encoded and deflate-encoded data streams.
If the content is compressed with gzip or deflate, conforming WICD aware servers must indicate this with the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate.
Multipart/related packaging should be supported by all agents implementing any WICD Profile. These agents will advertise "multipart/related" capability with their HTTP request accept headers.
MIME implementations must in general treat unrecognized subtypes of "multipart" as being equivalent to Multipart/mixed. Agents supporting the WICD Profile are therefore expected to support both, related and mixed.
Implementations preceding this specification may support only Multipart/mixed. These agents advertise "multipart/mixed" with their HTTP request accept headers.
WICD documents may have various animating objects like SVG images, videos, audio streams, and animating images. Therefore, there is a need to define how the various media elements are synchronised when presented on a screen or audio device.
Document formats conforming to WICD Core must use the Timing and Synchronization model defined in the SMIL specification.
The document begin for WICD documents is when the complete host document has been loaded by the user agent.
The document end for WICD documents is when the associated application exits or switches context to another document.
The elements which support timing are all those that reference timed media. In the case of an XHTML root document, the 'object' element supports timing.
Unless defined otherwise, the root document executes all timed children in parallel, following the semantics of the SMIL 'par' element. In other words, the root document of WICD has an implicit value for the SMIL 'timeContainer' attribute of 'par'.
Other profiles of WICD may allow the 'timeContainer' attribute.
Using a param element with name="timeline", the document author can specify whether the timeline on a Scalable Child Element is started. This is useful for conserving system resources when multiple Scalable Child Element are used, and only animate in certain situations. Using scripting, the animations on individual children can be started and stopped by changing the value attribute.
A param element with name="timeline" and value="disable" shall prevent the timeline of the Scalable Child Element from starting or, if already started, shall stop it. Thus, animations will not play.
A param element with name="timeline" and value="enable" shall allow the timeline of the Scalable Child Element to start. Thus, for dynamic rendering, animations will play. If previously stopped, the timeline shall reset and re-start.
If there is no param element with name="timeline", the timeline of the Scalable Child Element shall start. Thus, for dynamic rendering, animations will play.
Only dynamic renderings can have their timeline started and stopped. Frozen and static renderings have no timeline and thus cannot be started and stopped.
A param element with name="render" and value="frozen" or value="static" shall result in a rendering which is not dynamic and thus, animations shall not play even if a param element with name="timeline" has a value="enable".
The behavior of playing animations while loading a document is dependent on the capabilities of the root namespace of the document.
XML documents may use a parse first and then process model where the entire DOM is built and then handed to the user agent for processing, or may use a parse and process in parallel model where the document is processed immediately by the user agent.
When loading more than one animation during document load, synchronization of animations may be desirable. However XHTML has no inherent capability of providing this synchronization and XHTML eventing cannot guarantee synchronization of animations while the document is loading.
SVG and SVG Tiny do have synchronization capabilities that can be used when these namespaces are the root of a child document. The timeline for synchronization occurs when the first child document capable of synchronization begins. For example, an XHTML document has a referenced child SVG Tiny document whose timeline begins when the user agent begins processing the referenced child document which may animate a progress load bar while the rest of the composite document loads.
In WICD Core, HTML's event attributes (e.g., onclick and onload) map to equivalent DOM3 Events features. Each event attribute represents the creation and registration of an EventListener. The corresponding element represents the EventTarget. For these event listeners, useCapture is set to false. If the attribute representing the event listener is changed, this corresponds to the removal of the previously registered EventListener and the registration of a new one. The relative order of event listeners due to HTML event attributes versus other event listeners is not defined.
The following defines the mapping from HTML event attributes to corresponding DOM3 events:
Need to coordinate with HTML and DOM groups.
]For WICD documents where in one language the focus event in
[http://www.w3.org/2001/xml-events] is used and
DOMFocusIn is used in the other, authors have to take
note of the fact, that directly after the focus event is
dispatched, the DOMFocusIn event is dispatched, but
not the other way around. Equivalent for blur and
DOMFocusOut.
Conforming content should use the DOMFocusIn and
DOMFocusOut events.
Conforming content should attach event listeners either via the
DOM addEventListenerNS method or (for SVG content) XML
Events.
Note: The CDF WG expects this section to be removed in future versions and instead reference the [DOM Level 3 Events] specification [http://www.w3.org/TR/DOM-Level-3-Events/] once it reaches a stable maturity level.
Conforming WICD user agents must implement Media Queries [MQ].
Due to the wide range of devices that may support WICD, it is crucial for content authors to be able to provide CSS that fits best for each device that the content authors target. For instance, if the content authors want to deliver WICD content for devices that have different screen aspect ratio, [MQ] allows different style sheets to be applied to allow scalable content to be fitted based on the devices' aspect ratio, e.g. depending on the orientation of the screen, the content can be authored in a way that scalable content fits 100% vertically or horizontally.
A user agent that discovers a CSS style sheet, provided for its own device class (either by media attribute - for instance set to "handheld" - or by a Media Query expression), should assume the content was created with specific properties "in mind". The agent is then expected to deactivate any custom adaptation techniques (for example rendering wide screen content on a narrow screen) and display the intended layout "as is".
(This section is informative)
A handheld user agent should also not activate special content adaptation techniques for the narrow screen, if documents, which do not contain a style sheet reference for the "handheld" media type, do not require such treatment. Such documents should be rendered as is.
The terms used in this document are specified in Compound Document by Reference Framework 1.0.
This specification defines conformance for several classes of products:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (see ). However, for readability, these words do not appear in all uppercase letters in this specification.
At times, this specification recommends good practice for authors and user agents. These recommendations are not normative and conformance with this specification does not depend on their realization. These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording.
Profile Conformance
Any profile, conforming to WICD Core 1.0, must support XHTML as root document.
Any profile, conforming to WICD Core 1.0, must support the XHTML <object> element as means to reference Scalable Child Elements.
Any profile, conforming to WICD Core 1.0, must support SVG documents as Scalable Child Element format.
User Agent Conformance
Multiple SVG child documents may be referenced from the same XHTML document.
Multiple SVG child documents may animate in parallel.
Any Scalable Child Element format must support these three use cases: Scalable Foreground Child Elements, Scalable Background Image and Scalable Overlay Objects (Sprites).
Scalable Foreground Child Elements are referenced using the XHTML <object> element. They appear on the main XHTML layer, just like bitmap images.
User agents must support multiple Scalable Foreground Child Elements, which may be animating, interactive and may have embedded links.
An <object> element <param> child element with name="render" and value="dynamic" shall result in a dynamic rendering. Links shall be activatable. Animations shall play, if the timeline has started. Modifications made by script shall update the rendering. If the rendering area changes size, the rendering shall update.
An <object> element <param> child element with name="render" and value="static" shall result in a static rendering. Links shall not be activatable. Animations shall not play. Modifications made by script shall not update the rendering. If the rendering area changes size, the rendering shall update.
An <object> element <param> child element with name="render" and value="frozen" shall result in a one-time static rendering to a raster image. Links shall be not be activatable. Animations shall not play. Modifications made by script shall not update the rendering. If the rendering area changes size, the rendering shall not update.
The default value for <param name="render"> is "dynamic".
For SVG child objects, the document time used for rendering a frozen or static image shall be that given by the SVG 'snapshotTime' attribute. If no 'snapshotTime' is present in the animation, a document time of zero (0) must be used. Other Scalable Child Element formats may use a similar mechanism. Scalable Child Elements lacking such capability should use a time of zero (0) for still-image rendering.
If background.svg has width and height in px, then this is well-defined. If it is the default (width="100%" height="100%") then it will display, as large as will fit, where the background area to cover is seen as a viewport.
WICD user agents must support content layering using CSS absolute positioning in x, y and z order. This will detach a child element from main XHTML layer and create a new transparent layer.
WICD user agents must make all visible and focusable points in the XHTML layer and the positioned Overlay Object reachable and activatable.
WICD user agents must support transparency for Overlay Objects.
Scalable Overlay Elements, referred to from the XHTML page, may be put in front of, or behind, the default XHTML layer.
Any transparent areas in the Overlay Object and in XHTML root documents must make the layer behind visible.
User agents must support interactivity in overlay elements.
User agents must support overlay images with embedded links.
If only one size attribute value is provided, when referencing a Scalable Child Element, a fixed aspect ratio child element will get 'rightsized' proportionally, by being scaled to fit into the destination box.
The child content must render the entire viewport, including any leftover margins.
In the absence of a background color or image on the element that established the viewport (abbr html:object or svg:svg) it's background is transparent. This is in order to maximize the visual quality of content the parent document should be visible through the leftovers (as well as through the child content itself where it is transparent).
A defined background applies to the entire viewport (including the leftovers) so that content that spills outside of the viewbox into the leftovers is still on the correct background.
Any UI event, such as a mouse click, that hits on the leftover areas, is dispatched in the same manner as UI events over non-leftover areas (i.e., to the child document)
Transparency in foreground Scalable Child Elements should be supported when rendered over XHTML background content.
Transparency in Scalable Child Elements should be supported when a foreground Scalable Child Element is rendered over a background Scalable Child Element.
Transparency in foreground bitmap images must be supported when rendered over non-animating background content.
Transparency in foreground bitmap images should be supported when rendered over animating background content.
Any audio or video format supported by the user agent must also be supported to be used with the <audio> and <video> elements in SVG and the <object> element in XHTML.
WICD compliant agents should support seamless hyperlinking originating from any of the supported document formats to all supported content types. If it is possible to link from XHTML to some other supported content type (for example: XHTML linking to RSS, Java or multimedia content), then it should also be possible to link to the same content types from any other supported document format which supports hyperlinking (for example: SVG linking to RSS, Java or multimedia content).
If linking from XHTML to any of the supported content types will result in content type specific treatment, then linking to that same format from any other supported document format (such as from SVG) should result in the same content type specific treatment. If a WICD compliant agent supports linking from XHTML to URI schemes other than http:// (for examples wtai://, tel://, mailto://, etc.), then these URI schemes should also be supported, when linked-to from any of the other supported document formats that support hyperlinking (such as from SVG).
All URI schemes, supported for hyperlinking and the related functionality, should be supported, independent of the originating document format.
User agents must provide a way for the end user to navigate to each focusable element within the root document and its descendants.
The language specifications that are used with this framework define what elements are focusable. For example, focusable items in an SVG document are defined by the SVG 1.2 focusable attribute [SVGMobile12, Element focus].
In XHTML, <object> elements are, by default, focusable. However, authors can remove such elements from the tabbing order, by setting the element's tabindex attribute to "-1". This may be useful, if selected <object> elements, for instance non interactive SVG images, are not supposed to participate in the focus traversal.
By using the <object> element's child <param> element with the attribute name="focusable", the author of the parent document can specify whether "flat" or "hierarchical" focusability is desired for a child.
If more than one "focusable" parameter is provided for an element, then only the last one shall be used. Unrecognized param values shall be ignored.
The default focus mode is "hierarchical".
Authors use <param name="focusable" value="flat" />, to make focusable elements of the child become direct participants of the parents focus traversal. Access keys, defined by child documents, will not become accessible to the user, if they are also defined by the parent or by some other child element.
Authors use <param name="focusable" value="hierarchical" /> to select hierarchical (activatable) focus handling for a referenced child. A user, navigating to such a child element, will have the option to activate it, or to move on, to the next focusable element. Activating the child, will provide the user with access to the child's interactivity, it's focusable elements, such as embedded links and it's access keys. The user must deactivate an activated child element, in order to gain access to the parents focus traversal again.
Focus events are enabled for each child content by setting the "animation" object element parameter:
With the "animation" parameter set to "onfocusevent", the child content must render the first frame for time zero (0)
If the root element does not have focus, the root element must then be paused at time zero(0).
Upon receiving focus, the root element is resumed.
Upon losing focus, the root element is paused.
The default animation mode is "none".
The 'focusin'-animation does not timeout and may loop any number of times.
The 'focusout'-animation should be limited to one second.
The 'focusout'-animation must not loop.
In the context of WICD Core, user agents must at least provide one default system font (including a missing glyph, AKA 'Replacement Character', Unicode notation U+FFFD) to all components, such as browsers, SVG engines and other renderers. If there isn't enough information in the font to display a particular character, then the missing glyph is used.
Whatever I18N support a WICD implementation provides should not be worse than that of the platform on which it is running.
In both XHTML (using CSS) and SVG, font selection is done by the font-family property as described in CSS [CSS21].
Conforming WICD Core 1.0 content should specify serif, sans-serif, or monospaced (three of the 'generic font families') as the last item in the list of font family names.
Content (XHTML, SVG, CSS, script, etc) may be compressed with gzip [RFC 1952] or deflate [RFC 1951]. Conforming WICD viewers must correctly support gzip-encoded and deflate-encoded content.
If they support HTTP/1.1, they must support these encodings according to the HTTP/1.1 specification [RFC2616]; in particular, the client must specify with an "Accept-Encoding:" request header [HTTP-ACCEPT-ENCODING] with those encodings that it accepts, including at minimum gzip and deflate, and then decompress any gzip-encoded and deflate-encoded data streams.
If the content is compressed with gzip or deflate, conforming WICD aware servers must indicate this with the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate.
Multipart/related packaging should be supported by all agents implementing any WICD Profile. These agents will advertise "multipart/related" capability with their HTTP request accept headers.
MIME implementations must in general treat unrecognized subtypes of "multipart" as being equivalent to Multipart/mixed. Agents supporting the WICD Profile are therefore expected to support both, related and mixed.
Document formats conforming to WICD Core must use the Timing and Synchronization model defined in the SMIL specification.
The document begin for WICD documents is when the complete host document has been loaded by the user agent.
The document end for WICD documents is when the associated application exits or switches context to another document.
The elements which support timing are all those that reference timed media. In the case of an XHTML root document, the 'object' element supports timing.
Unless defined otherwise, the root document executes all timed children in parallel, following the semantics of the SMIL 'par' element. In other words, the root document of WICD has an implicit value for the SMIL 'timeContainer' attribute of 'par'.
An <object> element param element with name="timeline" and value="disable" shall prevent the timeline of the Scalable Child Element from starting or, if already started, shall stop it. Thus, animations will not play.
An <object> element param element with name="timeline" and value="enable" shall allow the timeline of the Scalable Child Element to start. Thus, for dynamic rendering, animations will play. If previously stopped, the timeline shall reset and re-start.
If there is no param element with name="timeline", the timeline of the Scalable Child Element shall start. Thus, for dynamic rendering, animations will play.
A param element with name="render" and value="frozen" or value="static" shall result in a rendering which is not dynamic and thus, animations shall not play even if a param element with name="timeline" has a value="enable".
Conforming WICD user agents must implement Media Queries [MQ].
A user agent, that discovers a CSS style sheet, provided for it's own device class, is expected to deactivate any custom adaptation techniques.
WICD Core 1.0 allows authors to use XHTML, CSS, and SVG together in a defined way. WICD Core defines basic principles that all comformant content and user agents must apply. However, exact language versions and capabilities are defined in profiles. Content authors are encouraged to see the profiles for guaranteeing use of right feature set.
More guidelines can be found from Mobile Web Best Practices 1.0.
The editors would like to thank the contributors: