Compound Document Framework 1.0 and WICD 1.0 Profiles

2.3.1 Specialized DOM access

Many languages define specialized DOM APIs. The W3C has defined an HTML DOM which extends the Core DOM and provides various convenience APIs for interacting with HTML documents. Similarly, the SVG language defines an SVG DOM which extends Core DOM.

Compound document profiles must specify whether the specialized DOM APIs that are defined within the component languages are supported.

Note: Although not required for compliance with the Compound Document Framework, it is strongly recommended that compound document profiles support all specialized DOM APIs that are supported in the component languages.

2.3.2 Cross Namespace DOM Boundaries

A compound document consists of a number of conceptually isolated documents whose interaction points are at specific DOM nodes.

For the purposes of scripting, CSS cascading and so forth each document may be considered to map to its own isolated DOM.

In the compound document case it may be desirable to provide a mechanism by which a parent document may gain access to a child document DOM. It may also be desirable to provide a mechanism by which the child document may gain access to the parent DOM.

One unknown is whether a child document may gain access to a sibling DOM as this may raise security issues.

2.3.3 Child to Parent DOM Access

The following applies to CDR only.

As there is currently no way of accessing the parent document, this specification introduces the ReferencedDocument interface. The ReferencedDocument interface must be implemented on all objects implementing the Document interface defined in DOM Level 3 Core. [DOM3Core]

IDL Definition:

interface ReferencedDocument {
  readonly attribute Element referencingElement;
};

The referencingElement attribute must represent the element node used for including the current document in the parent document. If access to the parent document is disabled or there is no parent document the attribute must be null.

2.3.4 Parent to Child DOM Access

The following applies to CDR only.

DOM Level 2 HTML defined a way for several elements to access the child document using the contentDocument attribute. [DOM2HTML] This specification defines a generic EmbeddingElement interface. Objects implementing the Element interface defined in DOM Level 3 Core must also implement the EmbeddingElement interface. [DOM3Core]

IDL Definition:

interface EmbeddingElement {
  readonly attribute Document contentDocument;
};

The contentDocument attribute must represent the child document. If access to the child document is disabled or there is no child document the attribute must be null.

2.4.1 Event Propagation in a Compound Document

Events propagate from a child component up to it's parent.

There are four different cases how event flow through references can happen.

1. Object with external content <object src="file" />
2. Object with inlined content <object><content /></object>
3. Referenced image content <img src="file" /> (special case of 1)
4. Directly inlined content <content /> (special case of 2)

Each case should behave in a same way. There should not be any behavioural differences on how the content is referenced.

2.4.2 Event-Related Legacy Markup

In order to claim conformance to this Compound Documents Framework, a compound document profile must define how all of its event-related language constructs and scripting constructs map to corresponding DOM3 event facilities, unless DOM3 events has already defined the mapping. In particular:

• For each event construct within supported languages, the profile must define the event's namespace and local name, what phases it supports (capture, target, bubble), whether it is cancellable, and the name of the DOM interface for its event structure (e.g., events.dom.w3c.org::UIEvent).

• Any events that are defined to be equivalent to a corresponding event from DOM3 Events must have compatible behavior, such as the phases supported, cancellability and propagation across parent/child compound document boundaries. For example, for a "click" event from language A to be equivalent to the DOM3 "click" event, it also must be cancellable since DOM3 "click" is cancellable.

• The profile must define how to map language features for event listeners, event handlers, and event targets into corresponding DOM3 Events facilities.

2.5.1 Child Documents

(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:

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

Relevant language specification 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 such 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 but 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 only the 'html:object' element 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 specification 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.)

2.5.2 Parent Documents

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

2.5.3 Single-threaded access to compound document DOM

The framework assumes a single-threaded execution model for accessing the compound document's object model via the DOM. As a result, during the time when one script or event handler executes against the DOM, no other script or event handler can access the DOM.

NOTE: This does not preclude multiple execution threads, such as asynchronous downloading of image files or custom logic that operates on other (non-DOM) data structures. It simply precludes multiple scripts or handlers from operating on the DOM at the same time.

2.6.1 Referencing elements

In Compound Document Framework 1.0, embedding media and other objects is done by using the existing elements in the host languages rather than by extending them with new markup. In XHTML documents, the <object> element will be used to reference XML document types. In SVG documents, the <foreignObject> element is used. In SMIL, the ref element should be used.

2.6.2 Declarative Child Object Parameters

It may be necessary to transfer parameters declaratively to a referenced child object. Compound Document profiles may define specific parameters/values for this purpose. Two examples:

<object type="..." data="...">
  <param name="param1" value="true" /><param name="param2" value="123" />
</object>

<svg xmlns="http://www.w3.org/2000/svg">
    <foreignObject>
        <metadata>
           param=value;
           param=value
        </metadata>
    </foreignObject>
</svg>

2.6.3 Focusable Child Objects

Child objects are by default not focusable.

For child objects to become focusable, one of the following must apply:

• The child object is wrapped by an anchor element.

• The child object advertises itself as being focusable. Either because it is activatable as a whole, or because it has embedded links.

In SVG, elements advertise that they are focussable using the focussable attribute.

In many cases referenced content can provide additional functionality. For example an embedded SVG graphic may provide the ability to zoom and pan within its viewport. In the compound document case it may be desirable to restrict child-specific functionality to preserve the authors intent.

Should object specific functionality be desired, the object may become a focus target by wrapping the object within an anchor element.

If a referenced object contains focus elements and the parent document wraps the referenced object with an anchor the result is that focus navigation behaviour needs definition. Should a pointing device be used, one possibility is that hit-testing on the content of the referenced object result in focus on targets in the child where the pointing device successfully intersects such a child object target, whilst applying focus to the entire child object should hit-testing fail to intersect targets in the child.

Focus activation in the case of referenced objects is discussed in detail in section 3.5 Focus Support.

3.2.1 Scalable Foreground Icon Object

Scalable foreground icon objects are embedded using the XHTML <object> element and appear on the main XHTML layer, just like bitmap objects.

The following example shows how a SVG object is displayed as part of the XHTML document:

SVG referenced from XHTML:

<object data="icon.svg" type="image/svg+xml" width="100" height="100" />

User agents must support scalable icon objects which may be animating, interactive or may include embedded links.

3.2.2 Scalable Background Image

Non-animating scalable images (SVG) must be supported for CSS background images. Conformant content must not include animated background (SVG) images. A scalable background image will not provide support for interaction, such as zooming, panning, linking and user interaction events.

The relevant SVG conformance requirement http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers says: "If the user agent includes an XHTML or SMIL viewing capability, then a Conforming SVG Viewer must support resources of MIME type "image/svg+xml" wherever raster image external resources can be used, such as in the XHTML 'img' element.

The following example shows how a SVG object is placed on the XHTML background, using the CSS background-image attribute:

Use of background-image:

<html>
  <body style="background-image:url(noanim.svg);background-attachment:fixed">
    <p>This in foreground</p>  
  </body>
</html>

The following example will set an svg image noanim.svg as a fixed, non-repeating (ie, not tiled) non-scrolling ('pinned') background, using the individual properties:

Pinned background:

body {
  background-color: white;
  background-image: url(noanim.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(noanim.svg) no-repeat fixed center center }

If noanim.svg has width and height in px, then this is well defined. If it is (the default) 100% 100% then it will display, as large as will fit, where the background area to cover is seen as a viewport.

3.2.3 Scalable Overlay Object (Sprite)

CSS absolute positioning may be used to detach a child object from main XHTML layer in order to create a new transparent layer.

SVG using absolute positioning:

.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 interactive overlay images.

User agents must support overlay images with embedded links.

3.3.1 SVG

An obvious scalable child object format is SVG.

Multiple SVG child objects may be referenced from the same XHTML document.

Multiple SVG child objects may animate in parallel.

It may be necessary to transfer parameters declaratively to a SVG child document. The following is a list of possible parameters/values:

<param name="animation" value="play" /> (default setting)

The child object may animate all the time. focusin/focusout/activate events will be handled at any time.

<param name="animation" value="stop" />

The child object will only render the first frame for time zero (0) and then suspend animation indefinitely.

This may be used for SVG objects that are non-animating to allow the user agent for performance and memory optimizations.

3.3.2 Audio

Audio specific capabilities will be defined in the devicespecific profile.

3.3.3 Video

Video specific capabilities will be defined in the devicespecific profile.

3.4.1 Rightsizing

Scalable child objects allow the creation of truly screen size independent content and layout in XHTML.

For this purpose, scalable child objetcs 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 object has it's own fixed aspect ratio, it is meaningful to provide only one size attribute value (width -or- height) of the XHTML object element, when referencing it. The child object will then get 'rightsized' proportionally.

Example:

<object data="icon.svg" type="image/svg+xml" width="100%" />

The following illustration shows, how a square, scalable object, 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 objects with fixed aspect ratio, are being scaled into an available area, both with a requested width of 100%.

The final dimensions of the scalable child object are determined by the following rules:

a. If the object element has width and/or height attributes set (through CSS or directly in XHTML), these values will be used.

b. Else, if the child object has it's own (intrinsic) width and/or height values set, these values will be used.

c. Else, the child object will be rendered into the full available region (destination box), made available by the outer container.

By setting only one of the XHTML object-element size attributes (width or height), the intrinsic size of the child object will be overridden.

When an embedded child object (such as SVG) specifies its horizontal width and omits a height specification, then the actual extent of the image is defined by the objects within it. On placing such an image into a UA, the viewport is usually a window on a 'galley' view of the entire document. In such cases, the object 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 UA 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.

3.4.2 Leftover Margins

Rendering scalable, but fixed aspect-ratio content into a fixed-sized destination area will often result in non filled margins. In case of SVG child objects: 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 object, 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 object 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 objects viewbox.

The following illustration shows, how a square, scalable object, 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 object 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 objects viewbox.

The child object must render any leftover margins.

Child document transparency composite onto the parent document transparency.

In the absence of a background colour 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 document 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.

3.4.3 Transparency

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 such as 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.

3.5.1 One Dimensional Focus Navigation (Linear, Focus Ring)

(This section is informative)

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 objects. Here, all focusable objects of a single Web document are chained in one linear path, based on the order of accurence 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.

3.5.2 Two Dimensional Focus Navigation (Graphical, Joystick)

(This section is informative)

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 graphical focus navigation come into effect, when a web document needs to be operated with a joystick device.

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 object in the source document.

The graphical foucs 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. Therefor, 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 objects. The first focusable object is located inside the SVG child document. The 2nd image shows focusable objects in both parent and child. The positioning of the focusable objects requires focus traversal to go through the child document.

Example 2: The image below shows again two WICD documents. The focusable objects in both documents are identical. But the rendered location of the child document differs in both examples. This results in 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 object to the next.

3.5.2.1 Alternative 1: Flat Graphical Focus Navigation

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 object. This 'current focus point' can be visualized to indicate the position inside the currently focused object (using a UI component such as a pointer or some other type of icon). It can also be presented by highlighting visual objects around the current focus point. The current focus point is used as a starting location for calculating a distance function towards the other focusable objects when navigating.

When user navigates (e.g. presses navigation input controls), the current focus point is moved and a different object 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 objects of different size. The arrows in the upper right in the following image show how focus traversal always moves back from the 'Attitude' object to the originating object.

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

Phase 1. At first, focusable objects 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 object or it may move it out of the current focusable object. Then, the current focus point movement is adjusted by distance function. The distance function takes 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 objects in cases where more unintuitive selection would otherwise be made.

Phase 3. Finally, there is a check that when focus point moves to another object, focused object is changed accordingly.

<html>
    <body>
       <a id="h_link1">...</a>
       <object id="obj1" href="svg.svg" />
       <a id="h_link2">...</a>
    </body>
</html>

<svg focusable="auto">
    <a id="s_link1">....</a>
    <a id="s_link2">...</a>
    <a id="s_link3">...</a>
</svg>

3.5.3 Focus Event triggered Child Object Animations

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 object 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 object 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 object rendered focus animations on multiple anchor objects. The UA's 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 is not timewise limited and may loop any number of times.

The 'focusout'-animation should be limited to one second.

The 'focusout'-animation must not loop.

3.6.1 System Fonts

Standalone components or renderers, such as SVG engines, do not always provide a default system font.

In the context of WICD Core, however, UA's must at least provide one default system font (including a missing glyph) to all components, such as browsers, SVG engines and other renderers.

If there isn't info 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 ...>
  <text x="20" y="20" font-size="medium" fill="#000">Fahrvergnuegen*</text>
</svg>

3.6.2 Font Naming

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 must 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:

• there are typically less fonts available, perhaps only one
• the fonts are unlikely to have the same names as desktop platforms

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.

3.6.3 Font Sharing

Sharing of fonts between the SVG and XHTML renderers, while allowed by the respective specifications, is not required by WICD 1.0. It may be required by a later WICD specification.

3.7.1 Content Encoding

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 servers must indicate this with the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate.

3.7.2 Content Packaging

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

3.8.1 Temporal Synchronisation of Media

User Agents must allow synchronization of referenced media via events. Events that correspond to the following actions must be available in the containing document:

• playback has started
• playback has paused
• playback has stopped

Similarly, the User Agent must allow the containing document to control the playback of referenced media using at least the following actions:

• start playback
• pause playback
• stop playback

Note: This technique is not optimal. The more appropriate way to achieve temporal synchronization is using the SMIL synchronization attributes. However, these are not available in this profile. Another technique is to reference all the media elements from a single SVG file.

3.8.2 Play Animations while Document is loading

The behavior of playing animations while loading a document is dependent on the capabilities of the root namespace of the document.

For example, HTML starts processing the document immediately using a parse and process in parallel model. While XML can use a parse first then process model where the entire DOM is built and then handed to the application, or can also the parse and process in parallel model.

When loading more than one animation during document load synchronization of animations may be desirable. However, HTML and XHMTL have no inherent capability to provide this synchronization HTML and XHTML eventing cannot guarantee synchronization of animations while the document is loading.

SVG, SVGT, and SMIL have synchronization capabilities that can be used when these namespaces are the root or enclosing schema of a document.

3.8.3 Caching Directives

Agents must obey HTTP caching directives which are carried along with each referenced document.

3.9.1 XHTML legacy event attributes

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:

• onload - {" http://www.w3.org/2001/xml-events", "load"}
• onunload - {" http://www.w3.org/2001/xml-events", "unload"}
• onclick - {" http://www.w3.org/2001/xml-events", "click"}
• ondblclick - {" http://www.w3.org/2001/xml-events", "click"}, except event handler returns if UIEvent.detail < 2
• onmousedown - {" http://www.w3.org/2001/xml-events", "mousedown"}
• onmouseup - {" http://www.w3.org/2001/xml-events", "mouseup"}
• onmouseover - {" http://www.w3.org/2001/xml-events", "mouseover"}
• onmousemove - {" http://www.w3.org/2001/xml-events", "mousemove"}
• onmouseout - {" http://www.w3.org/2001/xml-events", "mouseout"}
• onfocus - {" http://www.w3.org/2001/xml-events", "focus"}
• onblur - {" http://www.w3.org/2001/xml-events", "blur"}
• onkeypress - [HTML defines as a combination of key down and key up. Need to coordinate with HTML and DOM groups.]
• onkeydown - {" http://www.w3.org/2001/xml-events", "keydown"}
• onkeyup - {" http://www.w3.org/2001/xml-events", "keyup"}
• onsubmit - {" http://www.w3.org/2001/xml-events", "submit"}
• onreset - {" http://www.w3.org/2001/xml-events", "reset"}
• onselect - {" http://www.w3.org/2001/xml-events", "select"}
• onchange - {" http://www.w3.org/2001/xml-events", "change"}

3.9.2 Attaching Events to WICD documents

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

4.2.1 Root document: XHTML [?]

[XHTMLMP12] “XHTML Mobile Profile 1.2” (PDF)

[XHTMLMP11] “XHTML Mobile Profile 1.1” (PDF)

[XHTMLBasic XHTML Basic. W3C Recommendation 19th December 2000

4.2.2 ECMAScript 3rd Edition Compact Profile

Conformant Multimedia Mobile Profile user agents must support ECMAScript 3rd Edition as a scripting language. The media type must be application/ecmascript.

Consider: V2_1-20040816-C/OMA-WAP-ESMP-V1_0-20040709-C (PDF)

4.2.3 DOM

ToDo: ...

Consider: V2_1-20040816-C/OMA-WAP-ESMP-V1_0-20040709-C (PDF)

Consider: Document Object Model (DOM) Level 3 Core Specification

Consider: Document Object Model (DOM) Level 3 Events Specification

4.2.4 CSS Mobile Profile 1.0 / Wireless

CSS Mobile Profile 1.0 (W3C Candidate Recommendation 25 July 2002)

[Wireless Profile CSS 1.1] (PDF) OMA Candidate Version 1.1 – 09 Jun 2004

Note: Rightsizing is now specified in CSS 2.1 (?) - but not yet available in mobile/wireless CSS.

4.2.5 SVG Tiny 1.2

http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/

4.2.6 Bitmap formats

The viewer must support JPEG/JFIF [JPEG][JFIF] and PNG [PNG] raster image formats. Other image formats may be supported in addition. For JPEG, the subset defined in [SVG12] shall be supported. For PNG, all color types and bit depths shall be supported, gamma correction shall be supported, and any alpha or transparency information shall be used to composite the image onto the background.

4.2.7 Audio formats

Audio may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG audio element, or indirectly from an SVG video element where the video includes audio.

In XHTML, there are no timing elements. Thus, audio will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link). In conforming WICD 1.0 content, audio referenced from an XHTML object element must have width and height of zero.

In SVG, audio may be triggered by user interaction or by animations to start, stop, or change volume.

For accessibility, conforming WICD 1.0 user agents must profile the option of switching off audio. [UAAG].

No audio format is mandated in this profile. Any audio format supported by the device must also be supported to be used with the <audio> element in SVG and <object> element in XHTML.

4.2.8 Video formats

Video may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG video element.

In XHTML, there are no timing elements. Thus, video will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link).

In SVG, video may be triggered by user interaction or by animations to start, pause, rewind, or stop.

For accessibility, conforming WICD 1.0 user agents must provide the option of pausing, rewinding, or stopping video.

No video format is mandated in this profile. Any video format supported by the device must also be supported to be used with the <video> element in SVG and <object> element in XHTML.

4.2.9 Other formats

(tbd)

4.3.1 MIME Type

Documents authored for WICD Mobile should be associated with the "..." mime type.

Still TBD, awaiting Appendix D feedback (G Media Type Options).

4.3.2 DOCTYPE

ToDo: ...

Still TBD, awaiting Appendix D feedback (G Media Type Options).

4.3.3 User Agent Identification

User agents supporting WICD content are supposed to send an HTTP accept header including the WICD MIME type.

Still TBD, awaiting Appendix D feedback (G Media Type Options).

4.3.4 Filename extension

The prefered filename extension for WICD Mobile content is ".wicd".

Still TBD, awaiting Appendix D feedback (G Media Type Options).

5.2.1 Root document: XHTML

XHTML 1.1 - Module-based XHTML

5.2.2 ECMAScript 3rd Edition

Conformant WICD Desktop user agents must support ECMAScript 3rd Edition as a scripting language. The media type must be application/ecmascript.

5.2.3 DOM

Document Object Model (DOM) Level 3 Core Specification

Document Object Model (DOM) Level 3 Events Specification

5.2.4 CSS 2.1

5.2.5 SVG 1.2 Full

5.2.6 Bitmap formats

The viewer must support JPEG/JFIF [JPEG][JFIF] and PNG [PNG] raster image formats. Other image formats may be supported in addition. For JPEG, the subset defined in [SVG12] shall be supported. For PNG, all color types and bit depths shall be supported, gamma correction shall be supported, and any alpha or transparency information shall be used to composite the image onto the background.

5.2.7 Audio formats

Audio may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG audio element, or indirectly from an SVG video element where the video includes audio.

In XHTML, there are no timing elements. Thus, audio will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link). In conforming WICD 1.0 content, audio referenced from an XHTML object element must have width and height of zero.

In SVG, audio may be triggered by user interaction or by animations to start, stop, or change volume.

For accessibility, conforming WICD 1.0 user agents must profile the option of switching off audio. [UAAG].

Some audio formats may be mandated in this profile. Any audio format supported by the device must also be supported to be used with the <audio> element in SVG and <object> element in XHTML.

5.2.8 Video formats

Video may be incorporated into WICD 1.0 content in several ways. It may be pointed to from an XHTML object element, or an SVG video element.

In XHTML, there are no timing elements. Thus, video will play from the time the document is loaded until the time the document is unloaded (eg, replaced by another document as a result of following a link).

In SVG, video may be triggered by user interaction or by animations to start, pause, rewind, or stop.

For accessibility, conforming WICD 1.0 user agents must provide the option of pausing, rewinding, or stopping video.

Some video formats may be mandated in this profile. Any video format supported by the device must also be supported to be used with the <video> element in SVG and <object> element in XHTML.

5.2.9 Other formats

(tbd)

5.3.1 MIME Type

Documents authored for any of the WICD profiles should be associated with the "..." mime type.

Still TBD, awaiting Appendix D feedback (G Media Type Options).

5.3.2 DOCTYPE

ToDo: ...

Still TBD, awaiting Appendix D feedback (G Media Type Options).

5.3.3 User Agent Identification

User agents supporting WICD content are supposed to send an HTTP accept header including the WICD MIME type.

Still TBD, awaiting Appendix D feedback (G Media Type Options).

5.3.4 Filename extension

The prefered filename extension for WICD content is ".wicd".

Still TBD, awaiting Appendix D feedback (G Media Type Options).