Copyright © 2005 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/.
This is the 19 December 2005 Last Call Working Draft of the WICD Core. 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.
The deadline for Last Call comments is 27 January 2006.
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 Documents
2 Root Document Format
3 Scalable Child Elements
3.1 Supported Scalable Child Element Formats
3.1.1 SVG
3.2 Scalable Child Element Use Cases
3.2.1 Scalable Foreground Child Elements
3.2.2 Scalable Background Image
3.2.3 Scalable Overlay Objects (Sprites)
3.3 Scalable Child Element Layout
3.3.1 Rightsizing
3.3.2 Leftover Margins
3.3.3 Transparency
4 Other Child Element Formats
5 Hyperlinking
6 Focus Support
6.1 Focusable Child Elements
6.2 Focus Event triggered Child Element Animations
6.3 Focus Navigation
6.3.1 Two Dimensional Focus Navigation (Flat, Graphical, Joystick)
6.3.2 One Dimensional Focus Navigation (Linear, Focus Ring, Tab)
7 Font Support
7.1 System Fonts
7.2 Font Naming
7.3 Font Sharing
8 Content Packaging, Encoding and Transferring
8.1 Content Encoding
8.2 Content Packaging
9 Synchronization Support
9.1 Temporal Synchronization of Media
9.2 Timeline Initialization
9.2.1 Interaction with the 'render' param
9.3 Play Animations while Document is loading
10 Events
10.1 XHTML Legacy Event Attributes
10.2 Attaching Events to WICD Documents
11 Media Queries
A Definitions
B Conformance
C References
D Authoring Guidelines (Non-Normative)
E Acknowledgements (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 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) and SVG Tiny in a non device specific manner.
Profiles based on WICD Core support presentation of rich multimedia content as having the following characteristics:
Graphically rich content, possibly including animated background image.
Content author/provider has exact control of the presentation, including fonts, layout, color, etc.
Layout adaptation: layout can be based upon device characteristics - screen size, color depth, resolution, orientation.
Navigation (forward/backwards tab, up/down/left/right, accesskey, pointer, voice), graphical menus, interactivity and animations.
Graphical menu systems where items have an animated action when focused on.
Portable user interface.
Presentation can be customized to reflect a brand or user's personality.
Skinnable user interface: the ability to use animations and interactivity as a user interface "skin" or template around other content.
Rich content for different contexts.
Dynamic content: documents that are generated on the fly or which change over time
Interaction with mixed content, for example interacting with all the parts (graphics, text, images, audio, video, voice and multimodal interaction) of the mixed document.
Content adaptation, such as when a portal delivers a mixed document with varying capabilities (textual content and interactive animated content, for example) to a user which has been aggregated from multiple rich content sources.
Many of the requirements herein are related to this definition. XHTML and SVG have been chosen according to analysis of existing specifications and their applicability to rich multimedia content.
(This section is informative)
The image below shows the relation between WICD and CDF documents.
CDR 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, one-hand operation devices and enables publishers to target these type of devices without having to evaluate user agent identification string. In this profile, child documents are embedded by reference (CDR = Compound Document by Reference).
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 (CDR).
WICD Full 1.0 builds upon WICD Core 1.0.
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.
Scalable Child Elements appear as rectangular objects, which in their normal presentation, fit the screen, because they are scalable and usually ment to be looked at 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).
WICD Core 1.0 mandates one specific Scalable Child Element format: SVG. 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 must support these three use cases.
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.
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 made.
A param 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.
A param 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.
A param 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.
<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 animated background images. A Scalable Child Element as background image will not provide support for interaction, such as zooming, panning, linking and user interaction events. Authors should only provide non-animating or non-interactive animating content for use as 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 (the order is then significant):
Pinned background, shorthand:
body { background: white url(background.svg) no-repeat fixed center center }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 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 XHTML root documents must make the layer behind 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.
The use of absolute positioning often involves assumptions on the screen size. The WICD authoring guides will encourage the use of positioning relative to the screen size.
Scalable Child Elements allows for the creation of screen resolution independent content.
For this purpose, 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, is being scaled into an available area with a requested width of 100%.
The following illustration shows, how two scalable elements with fixed aspect ratio, are being 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, is being scaled into an available area (destination box) with a requested width of 100%. However, this request cannot be completely fulfilled, because the height of the resulting viewport would rise above the height of the available destination area. As a result, 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.
Visible 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%. However, this request cannot be completely fulfilled, because the width of the resulting viewport would rise above the width of the available destination area. As a result, 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.
Visible leftover margins will appear above and below the child element's viewbox.
The child element must render any leftover margins.
Child content transparency composite onto the parent document transparency.
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, goes straight to the document that contains the element that established that viewport.
No additional features (not currently available with SVG and CSS) are required. The current set of features is sufficient to cater to the use cases that we have.(This section is informative)
The rendered results of a WICD document may result in 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 provide rendering for each namespace in 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 combine 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 in the XHTML was supported, then it would also be required to notify the plugin every time a change in the rendered output occured. Such a change would most likely require an off-screen buffer to be used in order to 'double-buffer' so as to avoid flicker.
Given access to the rendered output of an XHTML implementation, foreground Scalable Child Elements over XHTML background using transparency on the foreground element must be supported.
Given that transparency information for the output of the background element may be unavailable, foreground Scalable Child Element over background scalable child element requiring transparency on the background and foreground elements may be supported.
Any audio or video format supported by the device must also be supported to be used with the <audio> and <video> elements in SVG and the <object> element in XHTML.
If it is possible to link from XHTML to Format-X, it should also be possible to link from any other supported format to Format-X.
WICD compliant agents should support seamless hyperlinking between any of the supported formats.
If linking from XHTML to Format-X will invoke content type specific treatment on arrival, then linking from any Scalable Child Element to Format-X should result in the same treatment. (Examples for this are special content handlers for RSS, Java, content download.)
Any content type supported by the user agent, when linked-to originating from XHTML, should also be supported by linking-to originating from any other supported format.
If a WICD compliant agent supports linking from XHTML to URI schemes other than http:// (for examples wtai:// and pcast://), then these URI schemes should also be supported, when linked-to from any other supported format.
All URI schemes, supported for hyperlinking and the related functionality, should be supported, independent of the content format.
User agents must provide a way for the end user to navigate to each focusable element within the root document and its descendants.
Which elements qualify as focusable elements must be defined by this specification or by the profiles that are built upon this specification.Child elements must be treated like bitmap images, and should, by default, not be focusable.
This means that there needs to be a reason like a specified element or attribute to make some parts of the document focusable. The referencing alone is not a valid reason.
For a child element to become focusable, it must advertise itself as being focusable.
Advertising focusable property depends on the used namespace. For example in XHTML, this can be done using an anchor element. In a similar way in SVG, elements advertise that they are focusable by setting the focusable attribute [SVGMobile12] or by using embedded links.
A user agent may enable some content to become focusable based on use context.
In situations where a user agent provides some additional functionality, it may enable more content to be focusable than what is specified by the author. For example, this may happen in selecting images for saving when there are no other means to do it. Another example of this case is making child elements focusable in order to enable a user to scroll its content. However, this is only applicable for extended features. Normally, a user agent should support the author's intent and not make other content focusable.
A focusable property can be used to trigger additional functionality in a user agent.
One often used function for focusable content is a link navigation. In many cases, user agent can provide additional functionality for content. For example, an embedded SVG graphic may provide the ability to zoom and pan within its viewport.
A navigation anchor around the element should not trigger additional content dependent features.
Child-specific functionality should be restricted to preserve the author's intent. Should element specific functionality be desired, the element must advertise itself as being focusable or implicity made focusable by a user agent.
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 a specific object element parameter:
<object type="image/svg+xml" data="focus-button.svg"> <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 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)
In a WICD document, the focusable items, i.e. items which can form part of a focus traversal, are defined by the respective document types being combined. For example, focusable items in an SVG document are defined by the SVG 1.2 focusable attribute [SVGMobile12, Element focus].
Vendors of handset devices that do not provide a pointing input device are encouraged to implement this model of a two dimensional, flat graphical focus navigation.
Mobile handset devices in general don't provide a pointing device. On these type of devices, the joystick must replace mouse or stylus, cursor keys, tab keys and page up/down keys. The benefits of the flat graphical focus navigation come into effect, when a web document needs to be operated with a joystick device.
In this model a union of all focusable elements within each component of a compound document is presented as a so-called flattened set. All focusable elements in a compound document act equivalently and are used without any dependency based on which component document they were defined in. Therefore, all focusable elements in child documents are used in the same way as focusable elements in a parent document.
Two dimensional, graphical focus navigation is not based on the concept of a linear focus ring. The traversal order is not related to the position of a focusable element in the source document.
The graphical focus navigation always needs to consider the current state of the rendered document. For example, scripts and animations may change the document's presentation at any time. Therefore, any focus navigation action is calculated at the moment, when the user interacts with the document.
The following examples show specific navigation issues with WICD documents.
Example 1: The images below show two similar WICD documents. The 1st image shows a WICD document with a parent document, that does not have any focusable elements. The first focusable element is located inside the SVG child document. The 2nd image shows focusable elements in both parent and child. The positioning of the focusable elements requires focus traversal to go through the child document.
Example 2: The image below shows again two WICD documents. The focusable elements in both documents are identical. But the rendered location of the child document differs in both examples. This results in a highly different focus traversal. The arrows in both images show just one of many ways a user can navigate through these WICD documents.
Example 3: The image below shows one WICD document with two child documents. The issue here is, that Link-4 of SVG-1 is positioned just above Link-1 of SVG-2. Ideally, the agent will allow the user to navigate directly from one child element to the next.
The main idea of the flat graphical focus navigation is the concept of an invisible 'current focus point' inside the page and inside the currently focused element. This 'current focus point' can be visualized to indicate the position inside the currently focused element (using a UI component such as a pointer or some other type of icon). It can also be presented by highlighting visual elements around the current focus point. The current focus point is used as a starting location for calculating a distance function towards the other focusable elements when navigating.
When the user navigates (e.g. presses navigation input controls), the current focus point is moved and a different element receives focus. The focus point movement depends on current movement direction and available focusable content in that direction.
The concept of the invisible current focus point enables a very natural navigation behavior between focusable elements of different size. The arrows in the upper right in the following image show how focus traversal always moves back from the 'Attitude' element to the originating element.
The focus navigation algorithm consists of three phases: finding candidates for focus movements, calculating and adjusting movement based on a distance function, and moving the current focus point with possibly changing focusable element.
Phase 1. At first, focusable elements are searched from the direction of navigation. The search includes content that is currently visible in that direction and content that becomes visible if viewport changes.
Phase 2. At second, the current focus point is moved to the direction of navigation. This movement may keep the point within the current focusable element or it may move it out of the current focusable element. Then, the current focus point movement is adjusted by distance the function. The distance function takes the location of current focus point, and locations and shapes of available focusable content in the area, and calculates most suitable location for the point movement. The distance function enables selection of near focusable elements in cases where more unintuitive selection would otherwise be made.
Phase 3. Finally, there is a check that when focus point moves to another element, focused element is changed accordingly.
The distance function takes into account the following metrics:
The distance function (df) is:
df = dotDist + dx + dy + 2 * (xdisplacement + ydisplacement) - sqrt(Overlap)
Desktop agents, tablet's and PDA's usually allow navigation of a web document using a pointing device (mouse or stylus). On desktop agents, the tab-key can be used additionally, 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.
XHTML and SVG have methods for linear one dimensional focus traversal. XHTML provides a default traversal order, and allows it to be changed with the use of tabindex attribute within one XHTML document. SVG's provides the focusNext and focusPrev elements which may be used to provide similar functionality within an SVG document. However, neither of these methods can be used when XHTML and SVG are combined. Therefore in the case of a WICD document by reference, combining XHTML with SVG, some alternate form of navigation is required.
When navigating an XHTML document it is possible to assign so-called access keys to links in order to provide a 'hot-key' navigation ability. It is unclear how such access keys work in the case of a referenced XHTML document containing access keys. Similarly if multiple parts of a WICD document contained access keys, should the user agent provide access key navigation into the child document or restrict it to the parent document only.
Specifications which provide an accesskey mechanism (e.g. HTML accesskey attribute) should be considered as identifying parts of the document that are important. The identified key itself is a hint - the user agent may change the particular activation method (e.g. a telephone may reassign keys to numbers, or to the softkeys, another user agent may provide a single point of activation and a rapid-access list which identifies the keys assigned) and is responsible for clarifying which elements have this quick access.
Using a combination key will likely provoke conflicts with other user agent or system functionalities (e.g. alt + the hinted key) is NOT recommended.
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, so that content providers can print text in any component (or render), as simple, 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, which takes a list of font family names. (This is combined with other properties such as font-weight to select a specific font face). The family names should match exactly - Times will not match Tymes or 'New Times'.
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] 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 must 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 it 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 to provide 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:
(This section is informative)
For WICD documents where in one language the legacy focus
event in the http://www.w3.org/2001/xml-events is used and in
the other the DOMFocusIn in the same namespace authors have to
take note of the fact that the directly after the focus event
is dispatched the DOMFocusIn event is dispatched but not the
other way around. Equivalent for blur and DOMFocusOut.
Authors are thus advised to use the DOMFocusIn and DOMFocusOut events.
Authors are encouraged to attach event listeners either via the DOM addEventListenerNS method or (for SVG content) XML Events.
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.
Document Conformance
In conformant content, SVG is referenced from XHTML using Object tag.
In conformant content, XHTML's Object and SVG's Audio and Video tags can be used to reference audio and video content.
User Agent Conformance
Conformant user agent must support multiple animating SVG images with embedded links that is referenced from XHTML.
Conformant user agent must support Scalable Child Elements as foreground objects, as background images and as overlays objects..
Conformant user agent must provide a mechanism to move focus to all focusable elements.
Profile Conformance
Conformant profile must support XHTML as root document format.
Conformant profile must support SVG as referenced document format.
Conformant profile must support CSS as style language.
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: