index.html 131 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>WICD Core 1.0</title><style type="text/css">
code           { font-family: monospace; }

.scrap td { background-color: #d5dee3;}
        table.scrap {margin-bottom: 1em }
div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}


                    .discontinued {
                      background: #ff4500;
                      color: white;
                      padding: 0.5em;
                    }

                    .discontinued a {
                      color: yellow;
                    }
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" /><link rel="alternate stylesheet" type="text/css" href="assertions.css" title="List of assertions" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
<h1><a name="title" id="title"></a>WICD Core 1.0</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group Note 19 August 2010</h2><dl><dt>This version:</dt><dd>
      <a href="http://www.w3.org/TR/2010/NOTE-WICD-20100819/">http://www.w3.org/TR/2010/NOTE-WICD-20100819/</a>
    </dd><dt>Latest version:</dt><dd>
      <a href="http://www.w3.org/TR/WICD/">http://www.w3.org/TR/WICD/</a>
    </dd><dt>Previous version:</dt><dd>
      <a href="http://www.w3.org/TR/2007/CR-WICD-20070718/">http://www.w3.org/TR/2007/CR-WICD-20070718/</a>
    </dd><dt>Editors:</dt><dd>Timur Mehrvarz, Vodafone Group Services Limited</dd><dd>Lasse Pajunen, Nokia</dd><dd>Julien Quint, DAISY Consortium</dd><dd>Daniel Appelquist, Vodafone Group Services Limited</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr /><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>
        This document specifies WICD Core 1.0, a device independent
        <em>Compound Document</em> profile based on XHTML, CSS and SVG.
		  </p><p>
        <em>Compound Document</em> is the W3C term for a document that combines
        multiple formats.
		  </p><p>
        WICD stands for <em>Web Integration Compound Document</em>
        and is based on the idea of integrating existing markup language formats
        in preference to inventing new markup.
		  </p></div>


      <div>
        <h2><a name="status" id="status"></a>Status of this Document</h2>
          <p class="discontinued">This document has been <strong>discontinued</strong> as part of the closure of the <a href="http://www.w3.org/2004/CDF/">Compound Document Formats Working Group</a>.</p>
      </div>


		  <div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
    1.1 <a href="#scope">Scope of this Specification</a><br />
    1.2 <a href="#related">Related Specifications</a><br />
    1.3 <a href="#relationship">Relationship to Referenced Specifications</a><br />
2 <a href="#root-document">Root, Parent and Child Documents</a><br />
    2.1 <a href="#referencing-child-documents">Referencing Child Documents</a><br />
3 <a href="#scalable-child-formats">Scalable Child Content</a><br />
    3.1 <a href="#supported-formats">Scalable Child Content Formats</a><br />
    3.2 <a href="#child-objects">Scalable Child Content Use Cases</a><br />
    3.3 <a href="#scalable-child-layout">Scalable Child Content Layout</a><br />
4 <a href="#other-child-formats">Other Child Content Formats</a><br />
    4.1 <a href="#doc-raster">Raster formats</a><br />
    4.2 <a href="#doc-audio">Audio formats</a><br />
    4.3 <a href="#doc-spec-video">Video formats</a><br />
    4.4 <a href="#doc-accessibility-guidelines">Child content accessibility guidelines</a><br />
5 <a href="#hyperlinking">Hyperlinking</a><br />
    5.1 <a href="#link-activation">Link Activation</a><br />
6 <a href="#focus-handling">Focus Handling</a><br />
    6.1 <a href="#focus-modes">Focus Modes</a><br />
    6.2 <a href="#focus-navigation">Focus Navigation</a><br />
    6.3 <a href="#focus-event-triggered-child-animations">Focus Event triggered Child Content Animations</a><br />
7 <a href="#framework-font-support">Font Support</a><br />
    7.1 <a href="#system-fonts">System Fonts</a><br />
    7.2 <a href="#font-naming">Font Naming</a><br />
    7.3 <a href="#font-sharing">Font Sharing</a><br />
8 <a href="#encoding">Content Encoding</a><br />
9 <a href="#synchronization">Synchronization Support</a><br />
    9.1 <a href="#temporal-sync">Temporal Synchronization of Media</a><br />
    9.2 <a href="#timeline-initialization">Timeline Initialization</a><br />
    9.3 <a href="#play-animations-while-loading">Play Animations while Document is loading</a><br />
10 <a href="#intended-layout">Intended Layout</a><br />
    10.1 <a href="#media-queries">Media Queries</a><br />
    10.2 <a href="#intended-layout-1">Style sheet being provided for specific agent classes</a><br />
    10.3 <a href="#intended-layout-2">No style sheet being provided to handheld agents</a><br />
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#definitions">Definitions</a><br />
B <a href="#param-elements">Object &lt;param&gt; attributes defined in WICD Core</a><br />
C <a href="#conformance">Conformance</a><br />
D <a href="#references">References</a><br />
    D.1 <a href="#refsNormative">Normative</a><br />
    D.2 <a href="#refsInformative">Informative</a><br />
E <a href="#acknowledgements">Acknowledgements</a> (Non-Normative)<br />
F <a href="#changes-log">Changes Log</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2><div class="div2">
<h3><a name="scope" id="scope"></a>1.1 Scope of this Specification</h3><p>(This section is informative)</p><p>
This Web Integration Compound Document (WICD) Core specification describes
rules for combining Extensible Hypertext Markup Language (XHTML), Cascading Style Sheets (CSS), and Scalable Child Content formats, such as Scalable Vector Graphics (SVG), in a device independent manner.
WICD Core 1.0 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.
        </p></div><div class="div2">
<h3><a name="related" id="related"></a>1.2 Related Specifications</h3><p>(This section is informative)</p><p>The image below shows the relation between CDF and WICD specifications.</p><img src="wicd-related2.png" alt="Shows the relation between CDF and WICD specifications" /><dl><dt class="label">CDRF - Compound Document by Reference Framework</dt><dd><p>
                <a href="http://www.w3.org/TR/CDR/">CDRF</a>
                describes generic rules and behavior for combining
                sets of standalone XML formats.
              </p><p>
                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.
              </p></dd><dt class="label">WICD Mobile 1.0</dt><dd><p>
                The <a href="http://www.w3.org/TR/WICDMobile/">WICD Mobile 1.0</a> 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).
              </p><p>
                WICD Mobile 1.0 builds upon WICD Core 1.0.
              </p></dd><dt class="label">WICD Full 1.0</dt><dd><p>
                The <a href="http://www.w3.org/TR/WICDFull/">WICD Full 1.0</a> 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).
              </p><p>
                WICD Full 1.0 builds upon WICD Mobile 1.0.
              </p></dd></dl></div><div class="div2">
<h3><a name="relationship" id="relationship"></a>1.3 Relationship to Referenced Specifications</h3><p>
          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.
        </p></div></div><div class="div1">
<h2><a name="root-document" id="root-document"></a>2 Root, Parent and Child Documents</h2><p>
        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.
      </p><div class="cdf-assert">
<p>        Any profile, conforming to WICD Core 1.0, must support XHTML as root document.</p>
      </div><div class="div2">
<h3><a name="referencing-child-documents" id="referencing-child-documents"></a>2.1 Referencing Child Documents</h3><p>
          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.
        </p><div class="cdf-assert">
          <p>Any profile, conforming to WICD Core 1.0,
          must support the XHTML &lt;object&gt; element as a means of referencing Scalable Child Content.</p>
        </div></div></div><div class="div1">
<h2><a name="scalable-child-formats" id="scalable-child-formats"></a>3 Scalable Child Content</h2><p>
          Scalable Child Content appears 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 Content can have a Document object model (e.g. SVG).
          It can also be native content (have a binary format or be
          applications).
        </p><div class="div2">
<h3><a name="supported-formats" id="supported-formats"></a>3.1 Scalable Child Content Formats</h3><div class="cdf-assert">
<p>              Any profile, conforming to WICD Core 1.0, must support SVG documents as a Scalable Child Content format.
</p>            </div><p>Later versions of WICD Core may mandate additional formats.
            Different WICD profiles may support different versions of SVG.
          </p><div class="div3">
<h4><a name="svg-child-object" id="svg-child-object"></a>3.1.1 SVG</h4><div class="cdf-assert">
              <p>Multiple SVG child documents may be referenced from the same parent document.</p></div><div class="cdf-assert">
              <p>Multiple SVG child documents may animate in parallel.</p></div></div></div><div class="div2">
<h3><a name="child-objects" id="child-objects"></a>3.2 Scalable Child Content Use Cases</h3><p>
            Scalable Child Content can be referenced from a parent document as
            foreground objects, as background images or as overlay objects.
          </p><div class="cdf-assert">
            <p>Any Scalable Child Content format must support these three use
            cases: Scalable Foreground Child Content, Scalable Background
            Image and Scalable Overlay Objects (Sprites).</p>
          </div><div class="div3">
<h4><a name="scalable-icons" id="scalable-icons"></a>3.2.1 Scalable Foreground Child Content</h4><div class="cdf-assert">
              <p>Scalable Foreground Child Content is referenced using the XHTML
              &lt;object&gt; element. It appears on the main XHTML layer, just
              like raster images.</p>
            </div><div class="cdf-assert">
              <p>User agents must support Scalable Foreground Child Content,
              which may be animating, interactive and may have embedded links.</p>
            </div><p>
              The following example shows how a SVG document is referenced from a XHTML document:
            </p><div class="exampleInner"><pre>&lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
  "http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd"&gt;
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;
  &lt;head&gt;
    &lt;title&gt;static render example&lt;/title&gt;
  &lt;/head&gt;
  &lt;body&gt;
    &lt;object data="icon.svg" type="image/svg+xml" width="100%"&gt;
      &lt;param name="render" value="static" /&gt;
    &lt;/object&gt;
  &lt;/body&gt;
&lt;/html&gt;</pre></div><div class="div4">
<h5><a name="still-image-rendering" id="still-image-rendering"></a>3.2.1.1 Still-Image Rendering</h5><p>
               Using a XHTML 1.1 <a href="#xhtml11">[XHTML™ 1.1 - Module-based XHTML]</a>
               <a href="http://www.w3.org/TR/html4/struct/objects.html#h-13.3.2">param element</a>
               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.
              </p><p>
                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, a grid of icons can be rendered as frozen with a script setting the focused icon to dynamic.
              </p><div class="cdf-assert"> <p>An &lt;object&gt; element &lt;param&gt; 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.</p>
              </div><div class="cdf-assert"><p> An &lt;object&gt; element &lt;param&gt; child element with
                name="render" and value="static" shall result in a static rendering. Links shall 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.</p>
              </div><div class="cdf-assert"> <p>An &lt;object&gt; element &lt;param&gt; child element with
                name="render" and value="frozen" shall result in a static rendering to a raster
                image. Links shall not be activatable. Animations shall not play.
                Scripts in the SVG are disabled, but scripts outside of the SVG may
                still affect the DOM tree and must result in the SVG being updated. The rendering shall also update, if the size of the rendering area changes.</p>
              </div><div class="cdf-assert">
                <p>If not specified in the content, the behavior
                  is as if &lt;param name="render"  value="dynamic"&gt;
                  had been specified.</p>
              </div><p>
                The terms "static" and "dynamic" are defined in the
                <a href="http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers">Conformance section</a> of the <a href="#SVGMobile12">[Scalable Vector Graphics (SVG) Tiny 1.2 Specification]</a>.
              </p><p>Example:</p><div class="exampleInner"><pre>&lt;object data="icon.svg" type="image/svg+xml" width="100%" &gt;
  &lt;param name="render" value="static" /&gt;
  &lt;object&gt;</pre></div><div class="cdf-assert">
    <p>For accessibility, a conformant WICD user agent must, at user option,
       provide a means to override author settings of this parameter.
This ensures that users can
       a) mask unwanted distractions or b) interact with SVG
interactive elements that would
       be masked by a 'frozen' rendering.
       See <a href="#hyperlinking"><b>5 Hyperlinking</b></a> and
       <a href="#focus-handling"><b>6 Focus Handling</b></a>.</p>
</div><div class="cdf-assert"><p>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 Content formats may use a similar mechanism.
                Scalable Child Content lacking such capability should use a time of
                zero (0) for still-image rendering.</p>
              </div></div></div><div class="div3">
<h4><a name="scalable-background-image" id="scalable-background-image"></a>3.2.2 Scalable Background Image</h4><div class="cdf-assert">
                <p>User agents must support Scalable Child Content (e.g. SVG)
                to be used as CSS background images.</p>
              </div><p>
              Agents may support declarative animated background images.
              Scalable Child Content, 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. For SVG content, a snapshotTime should be provided if the optimal time for a static rendering is not zero seconds. For other formats, if there is a similar feature, it should be used.


              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 <a href="#still-image-rendering"><b>3.2.1.1 Still-Image Rendering</b></a>,
              by using name="render" value="frozen".
            </p><p>
              The following example shows how a SVG document is placed
              on the XHTML background, using the CSS background-image
              attribute:
            </p><p>Use of background-image:</p><div class="exampleInner"><pre>&lt;html&gt;
  &lt;body style="background-image:url(background.svg);background-attachment:fixed"&gt;
    &lt;p&gt;This in foreground&lt;/p&gt;
  &lt;/body&gt;
&lt;/html&gt;</pre></div><p>
              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:
            </p><p>Pinned background:</p><div class="exampleInner"><pre>body {
  background-color: white;
  background-image: url(background.svg);
  background-repeat: no-repeat;
  background-attachment: fixed;
  background-position: center center
}</pre></div><p>
              or using the shorthand:
            </p><p>Pinned background, shorthand:</p><div class="exampleInner"><pre>body { background: white url(background.svg) no-repeat fixed center center }</pre></div><div class="cdf-assert"><p>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.</p>
            </div></div><div class="div3">
<h4><a name="scalable-overlay-object" id="scalable-overlay-object"></a>3.2.3 Scalable Overlay Objects (Sprites)</h4><div class="cdf-assert">
            <p>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.</p>
            </div><div class="cdf-assert">
            <p>WICD user agents must make all visible and focusable points in the XHTML layer and
            the positioned Overlay Object reachable and activatable.</p>
            </div><div class="cdf-assert">
            <p>WICD user agents must support transparency for Overlay Objects.</p>
            </div><div class="cdf-assert">
            <p>Scalable Overlay Objects, referred to from the XHTML, page may be put in front of, or
            behind, the default XHTML layer.</p>
            </div><div class="cdf-assert">
            <p>Any transparent areas in the Overlay Object and in the XHTML root document must
            allow the layer behind to be visible.</p>
            </div><p>
            A detailed description of the stacking level for different layers can be
            found in
            <a href="http://www.w3.org/TR/CSS21/zindex.html">Appendix E</a>
            in the <a href="#CSS21">[Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification]</a> specification.
            </p><p>Example:</p><div class="exampleInner"><pre>.svg-sprite
{
    position: absolute;
    left: 0;
    top: 0;
    width: 100%;
    border: 0px;
}

&lt;body&gt;
  &lt;div&gt;
    &lt;object class="svg-sprite" data="sprite.svg" type="image/svg+xml" /&gt;
    &lt;p&gt;Hello 1&lt;/p&gt;
    &lt;object data="foo.svg" type="image/svg+xml" width="100" height="50" /&gt;
    &lt;p&gt;Hello 2&lt;/p&gt;
  &lt;/div&gt;
&lt;/body&gt;</pre></div><div class="cdf-assert">
              <p>User agents must support interactivity in overlay elements.</p></div><div class="cdf-assert">
              <p>User agents must support overlay images with embedded links.</p></div></div></div><div class="div2">
<h3><a name="scalable-child-layout" id="scalable-child-layout"></a>3.3 Scalable Child Content Layout</h3><div class="div3">
<h4><a name="rightsizing" id="rightsizing"></a>3.3.1 Rightsizing</h4><p>
            Scalable Child Content is referenced by using width
            and/or height attributes with values relative to the 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 Content has its 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.
          </p><p>
            <a href="#CSS21">[Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification]</a> contains a detailed description of the required
            <a href="http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width">Visual formatting model - Inline, replaced elements</a>.
          </p><div class="div4">
<h5><a name="rightsizing-inf" id="rightsizing-inf"></a>3.3.1.1 Rightsizing Behavior</h5><p>(This section is informative)</p><div class="cdf-assert">
              <p>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.</p>
            </div><p>
              Rightsizing example:
            </p><div class="exampleInner"><pre>&lt;object data="icon.svg" type="image/svg+xml" width="100%" /&gt;
</pre></div><p>
              The following illustration shows how a square, scalable element
              with a fixed aspect ratio, has been scaled into an
              available area with a requested width of 100%.
            </p><img src="wicd-no-leftovers.png" alt="Shows how an SVG diagram is scaled into an available area" /><p>
              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%.
            </p><img src="wicd-no-leftovers2.png" alt="Shows how two SVG diagrams are scaled into an available area" /><p>
              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, then 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.
            </p></div></div><div class="div3">
<h4><a name="leftovers" id="leftovers"></a>3.3.2 Leftover Margins</h4><p>
            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.
          </p><p>
            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.
          </p><p>
            Leftover margins will appear to the left and right of the child element's viewbox.
          </p><img src="wicd-leftovers.png" alt="Shows how an SVG diagram is scaled into an available area with leftover margins" /><p>
            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.
          </p><p>
            Leftover margins will appear above and below the child element's viewbox.
          </p><img src="wicd-leftovers2.png" alt="Shows how an SVG diagram is scaled into an available area with leftover margins" /><div class="cdf-assert">
              <p>When rendering scalable, but fixed aspect-ratio content
              into a fixed-sized destination box, the child content must render
              the entire viewport, including any leftover margins.</p>
            </div><div class="cdf-assert"><p>In the absence of a background color or image on the element that
            established the viewport (for example html:object or svg:svg) its
            background is transparent.
            In order to maximize the visual quality
            of the content, the parent document must be visible through the leftovers (as
            well as through the child content itself where it is transparent).</p></div><div class="cdf-assert"><p>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.</p></div><div class="cdf-assert"><p>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)</p>
            </div></div><div class="div3">
<h4><a name="transparency" id="transparency"></a>3.3.3 Transparency</h4><div class="div4">
<h5><a name="transparency-intro" id="transparency-intro"></a>3.3.3.1 Introduction</h5><p>(This section is informative)</p><p>
              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.
            </p><p>
              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.
            </p><p>
              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.
            </p></div><div class="div4">
<h5><a name="transparency-requirements" id="transparency-requirements"></a>3.3.3.2 Transparency requirements</h5><div class="cdf-assert">
                <p>Transparency must be supported.</p>
              </div></div></div></div></div><div class="div1">
<h2><a name="other-child-formats" id="other-child-formats"></a>4 Other Child Content Formats</h2><div class="div2">
<h3><a name="doc-raster" id="doc-raster"></a>4.1 Raster formats</h3><div class="cdf-assert">
            <p>The viewer must support <a href="http://www.w3.org/TR/SVGMobile12/jpeg.html">JPEG/JFIF</a> <a href="#SVGMobile12">[Scalable Vector Graphics (SVG) Tiny 1.2 Specification]</a>, PNG <a href="#PNG">[Portable Network Graphics (PNG) Specification (Second Edition)]</a> and GIF 89a
          (non-interlaced, non-transparent, non-animated) raster
          image formats. Other image formats may be supported in addition.
          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.</p>
        </div></div><div class="div2">
<h3><a name="doc-audio" id="doc-audio"></a>4.2 Audio formats</h3><p>
          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.
        </p><div class="cdf-assert">
            <p>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). </p>
          </div><div class="cdf-assert">
            <p>In conforming WICD 1.0 content, audio referenced from an XHTML object
            element must have a width and height of zero.</p>
          </div><p>
          In SVG, starting, stopping or changing the volume may be triggered by user
          interaction or animations.
        </p><p>
          No audio format is mandated in WICD profiles.</p><div class="cdf-assert">
            <p>Any audio format supported by the device must also be supported for use
            with the &lt;audio&gt; element in SVG and &lt;object&gt; element in XHTML. </p>
          </div></div><div class="div2">
<h3><a name="doc-spec-video" id="doc-spec-video"></a>4.3 Video formats</h3><p>
          Video may be incorporated into WICD 1.0 content in several
          ways. It may be linked to from an XHTML object element,
          or an SVG video element.
        </p><div class="cdf-assert">
          <p>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).</p>
        </div><p>
          In SVG, starting, pausing, rewinding or stopping video
          may be triggered by user interaction or by animations.
        </p><p>
          No video format is mandated in WICD profiles. </p><div class="cdf-assert">
            <p>Any video format supported by the device must also be supported
            for use with the &lt;video&gt; element in SVG and &lt;object&gt; element in XHTML.</p>
          </div></div><div class="div2">
<h3><a name="doc-accessibility-guidelines" id="doc-accessibility-guidelines"></a>4.4 Child content accessibility guidelines</h3><p>
          For accessibility, conforming WICD Core 1.0 user agents must
          provide the option of pausing, rewinding, or stopping
          video. See <a href="http://www.w3.org/TR/UAAG/guidelines.html#tech-configure-multimedia">section 3.2</a> of <a href="#UAAG10">[User Agent Accessibility Guidelines 1.0]</a>.
        </p><p>
          For accessibility, conforming WICD Core 1.0 user agents must allow the
          user to slow the presentation rate of rendered audio and animation
          content (including video and animated images). See <a href="http://www.w3.org/TR/UAAG/guidelines.html#tech-slow-multimedia">section 4.4</a> of <a href="#UAAG10">[User Agent Accessibility Guidelines 1.0]</a>.
        </p><p>
          For accessibility, conforming WICD Core 1.0 user agents must allow the
          user to stop, pause, and resume rendered audio and animation content
          (including video and animated images) that last three or more seconds
          at their default playback rate. They must also allow the user to
          navigate efficiently within rendered audio and animations (including
          video and animated images) that last three or more seconds at their
          default playback rate. See <a href="http://www.w3.org/TR/UAAG/guidelines.html#tech-control-multimedia">section 4.5</a> of <a href="#UAAG10">[User Agent Accessibility Guidelines 1.0]</a>.
        </p></div></div><div class="div1">
<h2><a name="hyperlinking" id="hyperlinking"></a>5 Hyperlinking</h2><div class="cdf-assert">
        <p>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).</p>
      </div><div class="cdf-assert">
       <p>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).</p>
      </div><div class="cdf-assert">
      <p>All URI schemes, supported for hyperlinking and the related
functionality, should be supported, independent of the originating
document format.</p>
      </div><div class="cdf-assert">
        <p>When linking from XHTML to SVG, as well as from SVG to XHTML the user
        agent should stay the same.</p>
      </div><div class="div2">
<h3><a name="link-activation" id="link-activation"></a>5.1 Link Activation</h3><p>(This section is informative)</p><p>
          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.
        </p><ul><li><p>Link activation behavior for hyperlinks
            within a parent object is defined by the parent
            object's relevant language specification.</p></li><li><p>Link activation behavior for hyperlinks within
            a child object is defined by the child object's
            relevant language specification.</p></li></ul><p>
          Nested hyperlinks are more complicated. The following illustrates nested hyperlinks. Suppose the parent document is XHTML as follows:
        </p><div class="exampleInner"><pre>&lt;!-- parent.html --&gt;
&lt;html:a href="LargeMap.html"&gt;
  &lt;html:object type="image/svg+xml" data="child.svg" /&gt;
&lt;/html:a&gt;</pre></div><p>
          And the child SVG document contains the following:
        </p><div class="exampleInner"><pre>&lt;!-- child.svg --&gt;
&lt;svg:a xlink:href="DetailedCountyMap.html"&gt;
  &lt;svg:text&gt;county map&lt;/svg:text&gt;
&lt;/svg:a&gt;</pre></div><p>
          The &lt;svg:text&gt; 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:
        </p><ul><li><p>hyperlink-related event processing is compatible with the
            DOM3 Event model. Thus, an event such as a mouse click or a
            keyboard action which maps to DOMActivate will participate in
            capture, target and bubble phases according to the DOM3 Event
            specification.</p></li><li><p>elements which define hyperlinks (e.g., the &lt;html:a&gt; and &lt;svg:a&gt;
            elements) define implicit DOMActivate event listeners for the target
            and bubble phases (i.e., the useCapture parameter on the implicit
            addEventListenerNS() call is false), with a default action to
            execute a hyperlink to the identified resource.</p></li><li><p>the target element for pointer device events is established
            by first determining the most deeply nested child document which
            has content that intersects with the geometric (x,y) location
            of the event. Within the child document, the target element
            is chosen following the rules defined within the child
            document's language specification. (For example, the SVG
            specification says that the target element for pointer
            events generally is the topmost element on the canvas.)</p></li></ul><p>
          The implication is that the behavior of nested hyperlinks depends on how the hyperlink is activated. Here are some examples which illustrate common possibilities:
        </p><ul><li><p>Suppose the user gives focus to an &lt;html:a&gt; within the
            parent XHTML document above and then hits the "Enter" key to
            activate that link. In the example above, the &lt;html:a&gt;
            element is the event target. This would cause execution of
            the hyperlink to "LargeMap.html".</p></li><li><p>Suppose the user gives focus to an &lt;svg:a&gt; within
            the child SVG document and then hits the "Enter" key to
            activate that link. In the example above, the &lt;svg:a&gt;
            element is the event target. This would cause execution
            of the hyperlink to "DetailedCountyMap.html".</p></li><li><p>Suppose the user uses a mouse or other pointer
            device to click on the word "county map" in the above
            example. Because this pointing device event occurs over
            geometry controlled by both the parent XHTML and child SVG
            documents, and because the SVG document is the most deeply
            nested, then the target element will be chosen according
            to the rules in the SVG specification. In the example above,
            this will cause the &lt;svg:text&gt; element to be the
            event target. The &lt;svg:a&gt; element will receive the
            event after bubbling from the &lt;svg:text&gt; element,
            which will cause a hyperlink to "DetailedCountyMap.html".</p></li></ul><div class="div3">
<h4><a name="child-documents" id="child-documents"></a>5.1.1 Child Documents</h4><p>
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:
          </p><p>
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.
          </p><p>
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 &lt;frametarget&gt; (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 &lt;frametarget&gt; (see http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_2_2).
          </p><p>
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.
          </p><p>
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 User Agent 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.
          </p><p>
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.)
          </p><p>
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.)
          </p></div><div class="div3">
<h4><a name="parent-documents" id="parent-documents"></a>5.1.2 Parent Documents</h4><p>
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.
          </p><p>
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.
          </p></div></div></div><div class="div1">
<h2><a name="focus-handling" id="focus-handling"></a>6 Focus Handling</h2><div class="cdf-assert">
<p>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. </p>
      </div><div class="cdf-assert">
<p>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
          <a href="http://www.w3.org/TR/SVGMobile12/interact.html#focus">[SVGMobile12, Element focus]</a>.</p>
      </div><div class="cdf-assert">
      <p>
        In XHTML, &lt;object&gt; elements are, by default, focusable and participate in the focus traversal. However, conforming WICD user agents must remove child content from the focus traversal, if the &lt;object&gt; element's child &lt;param&gt; element is set to the attribute name="focusable" and the attribute value="skip".
      </p>

<div class="exampleInner"><pre>&lt;object data="static-icon.svg" type="image/svg+xml" width="50%" &gt;
  &lt;param name="focusable" value="skip" /&gt;
&lt;/object&gt;
</pre></div>
      </div><p>
        In some situations, like in a user activatable mode for making all
        non interactive elements focusable, a user agent may still allow the user to
        focus on a child element which was originally removed from focus traversal.

        For instance, a user agent may allow a user to focus on a static
        SVG image for the purpose of saving it or interacting with it in
        other ways.
      </p><div class="div2">
<h3><a name="focus-modes" id="focus-modes"></a>6.1 Focus Modes</h3><p>
This section defines two modes of child element focusability.
        </p><div class="cdf-assert">
        <p>By using the &lt;object&gt; element's child &lt;param&gt; element
        with the attribute name="focusable", the author of the parent
        document can specify whether "flat" or "hierarchical" focusability
        is desired for a child.</p>
        </div><div class="cdf-assert">
          <p>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. </p>
        </div><div class="cdf-assert">
          <p>The default focus mode depends on the User Agent. If a specific
          behavior is desired the content author must specify which focus mode
          to use.</p>
        </div><div class="div3">
<h4><a name="activatable-focus" id="activatable-focus"></a>6.1.1 Hierarchical Child Focus</h4><div class="cdf-assert">
            <p>Authors use &lt;param name="focusable" value="hierarchical" /&gt;
            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 and its
            focusable elements, such as embedded links and its access
            keys. The user must deactivate an activated child element,
            in order to gain access to the parents focus traversal again.</p>
          </div><div class="exampleInner"><pre>&lt;object data="interactive.svg" type="image/svg+xml" width="80%"&gt;
  &lt;param name="focusable" value="hierarchical" /&gt;
&lt;/object&gt;</pre></div><p>Hierarichal Focus Handling:</p><img src="activatable-focus.png" alt="Shows Hierarchical Focus Mode" /></div><div class="div3">
<h4><a name="flat-focus" id="flat-focus"></a>6.1.2 Flattened Child Focus</h4><div class="cdf-assert">
            <p>Authors use &lt;param name="focusable" value="flat" /&gt;,
            to make focusable elements of the child become direct
            participants of the parents focus traversal. Access keys,
            defined by child documents, may not become accessible
            to the user, if they are also defined by the parent or
            by other child element.</p>
          </div><div class="exampleInner"><pre>&lt;object data="multifocus.svg" type="image/svg+xml" width="80%"&gt;
  &lt;param name="focusable" value="flat" /&gt;
&lt;/object&gt;</pre></div><img src="flat-focus.png" alt="Shows Flat Focus Mode" /><p>
            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, 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.
          </p></div></div><div class="div2">
<h3><a name="focus-navigation" id="focus-navigation"></a>6.2 Focus Navigation</h3><div class="div3">
<h4><a name="focus-navigation-models" id="focus-navigation-models"></a>6.2.1 Focus Navigation Models</h4><p>
This section describes several focus navigation models. WICD Core does not mandate a specific focus navigation model. But device-specific WICD profiles should define which focus navigation models are required. WICD profiles may require at least one of the following navigation models.</p><p>
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).
</p><p>
In addition, focus navigation in a Compound Document can be hierarchical (<a href="#activatable-focus"><b>6.1.1 Hierarchical Child Focus</b></a>) or flat (<a href="#flat-focus"><b>6.1.2 Flattened Child Focus</b></a>).

This results in at least four possible focus navigation models:
</p><ul><li><p>One dimensional focus navigation with hierarchical child elements</p></li><li><p>One dimensional focus navigation with flattened elements</p></li><li><p>Two dimensional focus navigation with hierarchical child elements</p></li><li><p>Two dimensional focus navigation with flattened child elements</p></li></ul><p>
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.
</p><div class="div4">
<h5><a name="focus-traversal-hier" id="focus-traversal-hier"></a>6.2.1.1 One Dimensional Focus Navigation with Hierarchical Child Content</h5><p>
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.
</p><img src="nav-1dim-hierarchical.png" alt="One Dimensional Focus Navigation with Hierarchical Child Content" /><p>
In the example shown above, the XHTML parent document contains its 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. Its focusable sub elements are not flattened into the parent document. The child needs to be manually activated by the user, for its 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".
</p></div><div class="div4">
<h5><a name="one-dim-focus-traversal-flat" id="one-dim-focus-traversal-flat"></a>6.2.1.2 One Dimensional Focus Navigation with Flattened Child Content</h5><p>
In this second model, focusable elements of a child are flattened into the focus traversal path of the parent.
</p><img src="nav-1dim-flat.png" alt="One Dimensional Focus Navigation with Flattened Child Content" /><p>
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.
</p></div><div class="div4">
<h5><a name="two-dim-focus-traversal-hier" id="two-dim-focus-traversal-hier"></a>6.2.1.3 Two Dimensional Focus Navigation with Hierarchical Child Content</h5><p>
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.
</p><p>
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.
</p><img src="nav-2dim-hierarchical.png" alt="Two Dimensional Focus Navigation with Hierarchical Child Content" /><p>
In the illustration above, 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.
</p></div><div class="div4">
<h5><a name="two-dim-focus-traversal-flat" id="two-dim-focus-traversal-flat"></a>6.2.1.4 Two Dimensional Focus Navigation with Flattened Child Content</h5><p>
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.
</p><img src="nav-2dim-flat.png" alt="Two Dimensional Focus Navigation with Flattened Child Content" /><p>
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".
</p></div></div><div class="div3">
<h4><a name="current-focus-point-algorithm" id="current-focus-point-algorithm"></a>6.2.2 Current Focus Point Algorithm</h4><p>(This section is informative)</p><p>
The Current Focus Point Algorithm can be used to implement two dimensional focus traversal. It allows for natural traversal over randomly arranged focusable elements, using a multidirection input device (i.e., joystick).
</p><p>
The following illustration shows a complex WICD document, with twenty-five focusable elements of different shape and size.
</p><img src="CurrentFocusPointAlgorithm.png" alt="Current Focus Point Algorithm 1" /><p>
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 -&gt; D -&gt; E.
</p><img src="CurrentFocusPointAlgorithm2.png" alt="Current Focus Point Algorithm 2" /><p>
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'.
</p><p>
The following illustration highlights another cutout  from the original example.
</p><img src="CurrentFocusPointAlgorithm3.png" alt="Current Focus Point Algorithm 2" /><p>
This cutout shows how focus travels along the following elements: K -&gt; L -&gt; K -&gt; M -&gt; L -&gt; M -&gt; N -&gt; L -&gt; N -&gt; O. Ten Focus Points are created during this process. (Actually, Focus Points 1,2,3 are created on the same horizontal axis. The same is true for 4,5,6 and 7,8,9,10.)
</p><p>
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.
</p><p>
The Current Focus Point is always used as a starting point for the <a href="#nav-distance-fkt"><b>6.2.2.1 Distance Function</b></a> calculation towards neighboring focusable elements. The Current Focus Point Algorithm consists of three phases:
</p><ul><li><p>Phase 1: All focusable elements are searched from the
          direction of the navigation. The search includes content that is
          currently visible in that direction and content that becomes
          visible if the viewport changes.
        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 the viewport changes.</p></li><li><p>Phase 2: A new location for the current focus point is
          calculated based on the Euclidian distance between the current
          focus point and each focusable element, direction of navigation, etc.
        The current focus point is moved in 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 the
          <a href="#nav-distance-fkt"><b>6.2.2.1 Distance Function</b></a>. </p><p>The distance function takes the location of the current focus point and the locations and shapes of
available focusable content in the area. It then calculates the most suitable location for the point
movement. The distance function enables the selection of close focusable elements in cases where a
more unintuitive selection would otherwise be made.</p></li><li><p>Phase 3: If the focus point moves to another element,
          focused element is changed accordingly.</p></li></ul><div class="div4">
<h5><a name="nav-distance-fkt" id="nav-distance-fkt"></a>6.2.2.1 Distance Function</h5><p>
The distance function takes into account the following metrics:
</p><ul><li><p>The Euclidian distance (dotDist) between the current focus
          point position and its potential position in each of the
          candidates determined in phase 1. If the two positions have the
          same coordinate on the axis orthogonal to the navigation
          direction, dotDist is forced to 0 in order to favor elements
          in direction of navigation.</p></li><li><p>The absolute distance (dx or dy) on the navigation axis
          between the opposing edges of the currently focused element and
          each of candidates determined in phase 1.</p></li><li><p>The absolute distance (xdisplacement or ydisplacement) on
          the axis orthogonal to the navigation axis between the opposing
          edges of currently focused element and each of candidates
          determined in phase 1. When dx (dy) != 0, xdisplacement
          (ydisplacement) = 0. These values are used to compensate for
          the situations where an element is close on the navigation
          axis, but very far on the orthogonal axis. In such a case,
          it is more natural to navigate to another element, which
          may be further away on the navigation axis, but approximately
          on the same level on the other axis.</p></li><li><p>The overlap (Overlap) between the opposing edges of currently focused element and each of candidates determined in phase 1. Elements are rewarded for having high overlap with the currently focused element.
        To prevent the longer boxes from always winning the focus over
        shorter boxes when longer boxes are partially outside of viewport,
          the visible width has been set as an upper limit for the overlap.</p></li></ul><p>
The distance function (df) is:
</p><div class="exampleInner"><pre>df = dotDist + dx + dy + 2 * (xdisplacement + ydisplacement) - sqrt(Overlap)</pre></div></div></div></div><div class="div2">
<h3><a name="focus-event-triggered-child-animations" id="focus-event-triggered-child-animations"></a>6.3 Focus Event triggered Child Content Animations</h3><p>
            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.
          </p><div class="cdf-assert">
            <p>Focus events are enabled for each child content by setting the "focusanimation"
            object param element.</p>
          </div><div class="exampleInner"><pre>&lt;object data="focus-button.svg" type="image/svg+xml"&gt;
  &lt;param name="focusanimation" value="onfocusevent" /&gt;
&lt;/object&gt;
</pre></div><p>
            With the "focusanimation" parameter set to "onfocusevent",
          </p><div class="cdf-assert"><p>the child content must be rendered as a static image, using the SVG 'snapshotTime' attribute (as described under <a href="#still-image-rendering"><b>3.2.1.1 Still-Image Rendering</b></a>).</p></div><div class="cdf-assert"><p>If the child content does not have focus, it behaves like a static image.</p></div><div class="cdf-assert"><p>Upon receiving focus, the root element shall be resumed.</p></div><div class="cdf-assert"><p>Upon losing focus, all focusout animations of the child content are allowed to finish. By focusout animation, we mean all animations, that were triggered by a focusout event and all the animation elements they trigger in their turn. The focusout event has finished its active duration, when the last animation has finished its active duration. Then the root element is paused and its rendering becomes static.</p></div><div class="cdf-assert"><p>
          The default "focusanimation" mode is "none".
          </p></div><p>The following SVG example applies to declarative animation:</p><div class="exampleInner"><pre>&lt;svg id="SVGRoot"&gt;
  ...
  &lt;rect ... &gt;
    &lt;animate begin="SVGRoot.focusin" ... /&gt;
    &lt;animate begin="SVGRoot.focusout" ... /&gt;
  &lt;/rect&gt;
  ...
&lt;/svg&gt;
</pre></div><p>
            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.
          </p><div class="exampleInner"><pre>&lt;style type="text/css"&gt;
  a.svglink:focus { outline: none }
&lt;/style&gt;

&lt;object type="image/svg+xml" data="header.svg" /&gt;  &lt;!-- defaults to 'play' --&gt;

&lt;a href="foo1.html" class="svglink"&gt;
  &lt;object type="image/svg+xml" data="foo1.svg"&gt;
    &lt;param name="focusanimation" value="onfocusevent" /&gt;
  &lt;/object&gt;
&lt;/a&gt;

&lt;a href="foo2.html" class="svglink"&gt;
  &lt;object type="image/svg+xml" data="foo2.svg"&gt;
    &lt;param name="focusanimation" value="onfocusevent" /&gt;
  &lt;/object&gt;
&lt;/a&gt;
</pre></div><p>
            Authors should take note of the following:
          </p><div class="cdf-assert"><p>The 'focusin'-animation does not timeout and may loop any number of times.</p></div><div class="cdf-assert"><p>The 'focusout'-animation should be limited to one second.</p></div><div class="cdf-assert"><p>The 'focusout'-animation must not loop.</p></div></div></div><div class="div1">
<h2><a name="framework-font-support" id="framework-font-support"></a>7 Font Support</h2><div class="div2">
<h3><a name="system-fonts" id="system-fonts"></a>7.1 System Fonts</h3><p>
            Standalone components or renderers, such as SVG engines, do not always provide a default system font.
          </p><div class="cdf-assert"><p>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.</p></div><div class="cdf-assert"><p>
          Whatever I18N support a WICD implementation provides should not
          be worse than that of the platform on which it is running.
          </p></div><p>
            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.
          </p><p>
            The default system font(s) may be raster or vector based.
            Ideally, the same default system font(s) are made available
            for all components.
          </p><div class="cdf-assert"><p>
          The following SVG sample markup must generate visible text:
          </p></div><div class="exampleInner"><pre>&lt;svg xmlns="http://www.w3.org/2000/svg"
        viewBox="0 0 250 50"
        baseProfile="tiny" version="1.2"&gt;
  &lt;text x="20" y="20" font-size="30" fill="#000"&gt;Fahrvergnuegen&lt;/text&gt;
&lt;/svg&gt;
</pre></div><p>
          </p></div><div class="div2">
<h3><a name="font-naming" id="font-naming"></a>7.2 Font Naming</h3><div class="cdf-assert"><p>
            In both XHTML (using CSS) and SVG, font selection is done by the
            font-family property as described in CSS <a href="#CSS21">[Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification]</a>.
          </p></div><p>
            In desktop usage, authors frequently choose fonts that they know are
            installed by default on particular platforms.
          </p><p>
            On mobile:
          </p><ul><li><p>there are typically fewer fonts available, perhaps only one</p></li><li><p>the fonts are unlikely to have the same names as desktop platforms</p></li></ul><div class="cdf-assert"><p>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.</p></div><p>
            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.
          </p></div><div class="div2">
<h3><a name="font-sharing" id="font-sharing"></a>7.3 Font Sharing</h3><p>
            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.
          </p></div></div><div class="div1">
<h2><a name="encoding" id="encoding"></a>8 Content Encoding</h2><div class="cdf-assert"><p>Content (XHTML, SVG, CSS, script, etc) may be compressed with
          gzip <a href="#rfc1952">[IETF RFC 1952]</a> or deflate <a href="#rfc1951">[IETF RFC 1951]</a>. Conforming WICD viewers must
        correctly support gzip-encoded and deflate-encoded content.</p></div><div class="cdf-assert"><p>If they support HTTP/1.1, they must support these encodings according
          to the HTTP/1.1 specification <a href="#rfc2616">[IETF RFC 2616]</a>; in particular, the client
        must specify with an "Accept-Encoding:" request header
        (section 14.4 of <a href="#rfc2616">[IETF RFC 2616]</a>)
        which of the encodings it accepts, including at a
        minimum gzip and deflate, and then decompress any gzip-encoded
        and deflate-encoded data streams.
        </p></div><p>
          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.
        </p></div><div class="div1">
<h2><a name="synchronization" id="synchronization"></a>9 Synchronization Support</h2><div class="div2">
<h3><a name="temporal-sync" id="temporal-sync"></a>9.1 Temporal Synchronization of Media</h3><p>
            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.
          </p><div class="cdf-assert"><p>
             Document formats conforming to WICD Core must use the
             Timing and Synchronization model defined in the
             <a href="http://www.w3.org/TR/SMIL/smil-timing.html">SMIL
                 specification.</a>
          </p></div><div class="cdf-assert"><p>
             The document begin for WICD documents is when the
             <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-load">load event</a> is dispatched on the root document.
          </p></div><div class="cdf-assert"><p>
             The document end for WICD documents is when the
             <a href="http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-unload">unload event</a> is dispatched on the root document.
          </p></div><div class="cdf-assert"><p>
             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.
          </p></div><div class="cdf-assert"><p>
             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'.
          </p></div><p>
             Other profiles
             of WICD may allow the 'timeContainer' attribute.
          </p></div><div class="div2">
<h3><a name="timeline-initialization" id="timeline-initialization"></a>9.2 Timeline Initialization</h3><p> Using a param element with name="timeline", the document author
            can specify whether the timeline on Scalable Child Content is
          started. This is useful for conserving system resources when
          multiple Scalable Children 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.
          </p><div class="cdf-assert"><p> A param element with
          name="timeline" and value="disable" shall prevent the timeline of
          the Scalable Child Content from starting or, if already started,
          shall stop it. Thus, animations will not play. </p></div><div class="cdf-assert"><p> A param element with
          name="timeline" and value="enable" shall allow the timeline of the
          Scalable Child Content to start. Thus, for dynamic rendering,
          animations will play. If previously stopped, the timeline shall
          reset and re-start. </p></div><div class="cdf-assert"><p> If there is no param element with
          name="timeline", the timeline of the Scalable Child Content shall
          start. Thus, for dynamic rendering, animations will play.
          </p></div><div class="div3">
<h4><a name="id4506664" id="id4506664"></a>9.2.1 Interaction with the 'render' param</h4><p>Only dynamic renderings can have their timeline started and
            stopped. Frozen and static renderings have no timeline and thus
            cannot be started and stopped.</p><div class="cdf-assert"><p> 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". </p></div></div></div><div class="div2">
<h3><a name="play-animations-while-loading" id="play-animations-while-loading"></a>9.3 Play Animations while Document is loading</h3><p>
            The behavior of playing animations while loading a document is
            dependent on the capabilities of the root namespace
            of the document.
          </p><p>
            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.
          </p><p>
            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.
          </p><p>
            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.
          </p></div></div><div class="div1">
<h2><a name="intended-layout" id="intended-layout"></a>10 Intended Layout</h2><div class="div2">
<h3><a name="media-queries" id="media-queries"></a>10.1 Media Queries</h3><div class="cdf-assert"><p>
          Conforming WICD user agents must implement Media Queries <a href="#mq">[Media Queries]</a>.
        </p></div><p>
          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, <a href="#mq">[Media Queries]</a> allows different style sheets to


          be applied to allow scalable content to be fitted based on the
          devices' aspect ratio, <em>e.g.</em> depending on the orientation of
          the screen, the content can be authored in a way that scalable
          content fits 100% vertically or horizontally.
        </p></div><div class="div2">
<h3><a name="intended-layout-1" id="intended-layout-1"></a>10.2 Style sheet being provided for specific agent classes</h3><p>
          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".
        </p></div><div class="div2">
<h3><a name="intended-layout-2" id="intended-layout-2"></a>10.3 No style sheet being provided to handheld agents</h3><p>(This section is informative)</p><p>
          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.
        </p></div></div></div><div class="back"><div class="div1">
<h2><a name="definitions" id="definitions"></a>A Definitions</h2><p>The terms used in this document are specified in
      <a href="http://www.w3.org/TR/CDR/#definitions">Compound Document by Reference Framework 1.0</a>.</p></div><div class="div1">
<h2><a name="param-elements" id="param-elements"></a>B Object &lt;param&gt; attributes defined in WICD Core</h2><p>
        The param attribute with the name "render" and the values "dynamic", "frozen" and "static" are specified
        in <a href="#scalable-icons"><b>3.2.1 Scalable Foreground Child Content</b></a>.
      </p><p>
        The param attribute with the name "focusable" and the values "hierarchical", "flat" and "skip" are specified
        in <a href="#focus-handling"><b>6 Focus Handling</b></a>.
      </p><p>
        The param attribute with the name "focusanimation" and the values "none" and "onfocusevent" are
        specified in <a href="#focus-event-triggered-child-animations"><b>6.3 Focus Event triggered Child Content Animations</b></a>.
      </p><p>
        The param attribute with the name "timeline" and the values "enable" and "disable" are specified in <a href="#timeline-initialization"><b>9.2 Timeline Initialization</b></a>.
      </p></div><div class="div1">
<h2><a name="conformance" id="conformance"></a>C Conformance</h2><p>
      	This specification defines conformance for several classes of products:
      </p><ul><li><p>Profiles</p></li><li><p>User agents</p></li></ul><p>
        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 <a href="#rfc2119">[IETF RFC 2119]</a>. However, for readability,
        these words do not appear in all uppercase letters in this
        specification.
      </p><p>
        All sections are normative unless they
        are marked with "(This section is Informative)".
      </p><p>
        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.
      </p><p>
        Profile Conformance
      </p><ol class="enumar"><li><p>
            Any profile, conforming to WICD Core 1.0, must support XHTML as root document.
          </p></li><li><p>
            Any profile, conforming to WICD Core 1.0, must support the XHTML &lt;object&gt; element as means to reference Scalable Child Content.
          </p></li><li><p>
            Any profile, conforming to WICD Core 1.0,
            must support SVG documents as Scalable Child Content format.
          </p></li></ol><p>
        User Agent Conformance
      </p><ol class="enumar"><li><p>
            Multiple SVG child documents may be referenced from the same XHTML document.
          </p></li><li><p>
            Multiple SVG child documents may animate in parallel.
          </p></li><li><p>
            Any Scalable Child Content format must support these three use cases: Scalable Foreground Child Content, Scalable Background Image and Scalable Overlay Objects (Sprites).
          </p></li><li><p>
            Scalable Foreground Child Content is referenced using the XHTML
            &lt;object&gt; element. It appears on the main XHTML layer, just like
            raster images.
          </p></li><li><p>
            User agents must support multiple Scalable Foreground Children,
            which may be animating, interactive and may have embedded links.          </p></li><li><p>
            An &lt;object&gt; element &lt;param&gt; 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.
          </p></li><li><p>
            An &lt;object&gt; element &lt;param&gt; child element with
            name="render" and value="static" static rendering. Links shall 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.
          </p></li><li><p>
            An &lt;object&gt; element &lt;param&gt; child element with
            name="render" and value="frozen" shall result in a one-time static rendering to a raster
            image. Links shall not be activatable. Animations shall not play.
            Modifications made by script shall not update the rendering. The rendering
            shall also not update, if the size of the rendering area changes.
            The original SVG, once rendered, may be discarded by the client.
          </p></li><li><p>
            The default value for &lt;param name="render"&gt; is "dynamic".
          </p></li><li><p>
            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 Content formats may use a similar mechanism.
            Scalable Child Content lacking such capability should use a time of
            zero (0) for still-image rendering.
          </p></li><li><p>
            User agents must support Scalable Child Content (e.g. SVG)
            to be used as CSS background images.
          </p></li><li><p>
            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.
          </p></li><li><p>
            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.
          </p></li><li><p>
            WICD user agents must make all visible and focusable points in the XHTML layer and
            the positioned Overlay Object reachable and activatable.
          </p></li><li><p>
            WICD user agents must support transparency for Overlay Objects.
          </p></li><li><p>
            Scalable Overlay Elements, referred to from the XHTML page, may be put in front of, or
            behind, the default XHTML layer.
          </p></li><li><p>
            Any transparent areas in the Overlay Object and in XHTML root documents must
            make the layer behind visible.
          </p></li><li><p>
            User agents must support interactivity in overlay elements.
          </p></li><li><p>
            User agents must support overlay images with embedded links.
          </p></li><li><p>
            If only one size attribute value is provided, when referencing Scalable Child Content, a fixed aspect ratio
            child element will get 'rightsized' proportionally, by being scaled
            to fit into the destination box.
          </p></li><li><p>
            When rendering scalable, but fixed aspect-ratio content
            into a fixed-sized destination box, the child content must render the entire viewport, including any leftover margins.
          </p></li><li><p>
            In the absence of a background color or image on the element that
            established the viewport (abbr html:object or svg:svg) its
            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).
          </p></li><li><p>
            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.
          </p></li><li><p>
            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)
          </p></li><li><p>
            When rendering any content over non-animated content, transparency must be supported.
            Otherwise transparency should be supported.
          </p></li><li><p>
            The viewer must support <a href="http://www.w3.org/TR/SVGMobile12/jpeg.html">JPEG/JFIF</a> <a href="#SVGMobile12">[Scalable Vector Graphics (SVG) Tiny 1.2 Specification]</a>, PNG <a href="#PNG">[Portable Network Graphics (PNG) Specification (Second Edition)]</a> and GIF 89a
          (non-interlaced, non-transparent, non-animated) raster
          image formats. Other image formats may be supported in addition.

          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.
          </p></li><li><p>
            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).
          </p></li><li><p>
            In conforming WICD 1.0 content, audio referenced from an XHTML
            object element must have a width and height of zero.
          </p></li><li><p>
            Any audio format supported by the device must also be supported
            for use with the &lt;audio&gt; element in SVG and &lt;object&gt; element
            in XHTML.
          </p></li><li><p>
            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).
          </p></li><li><p>
            Any video format supported by the device must also be supported
            for use with the &lt;video&gt; element in SVG and &lt;object&gt; element
            in XHTML.
          </p></li><li><p>
        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).
          </p></li><li><p>
       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).
          </p></li><li><p>
      All URI schemes, supported for hyperlinking and the related
functionality, should be supported, independent of the originating
document format.
          </p></li><li><p>
            When linking from XHTML to SVG, as well as from SVG to XHTML the
            user agent should stay the same.
          </p></li><li><p>
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.
          </p></li><li><p>
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
          <a href="http://www.w3.org/TR/SVGMobile12/interact.html#focus">[SVGMobile12, Element focus]</a>.
          </p></li><li><p>
        In XHTML, &lt;object&gt; elements are, by default, focusable and participate in the focus traversal. However, conforming WICD user agents must remove child content from the focus traversal, if the &lt;object&gt; element's child &lt;param&gt; element is set to the attribute name="focusable" and the attribute value="skip".

          </p></li><li><p>
        By using the &lt;object&gt; element's child &lt;param&gt; element with the attribute name="focusable", the author of the parent document can specify whether "flat" or "hierarchical" focusability is desired for a child.
          </p></li><li><p>
          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.
          </p></li><li><p>
        The default focus mode is "hierarchical".
          </p></li><li><p>
            Authors use &lt;param name="focusable" value="flat" /&gt;, 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.
          </p></li><li><p>
            Authors use &lt;param name="focusable" value="hierarchical" /&gt; 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, its focusable elements, such as embedded links and its access keys. The user must deactivate an activated child element, in order to gain access to the parents focus traversal again.
          </p></li><li><p>
            Focus events are enabled for each child content by setting the "focusanimation"
            object element parameter.
          </p></li><li><p>
            With the "focusanimation" parameter set to "onfocusevent",

            the child content must be rendered as a static image, using the SVG 'snapshotTime' attribute (as described under <a href="#still-image-rendering"><b>3.2.1.1 Still-Image Rendering</b></a>).
          </p></li><li><p>

            If the child content does not have focus, it behaves like a static image.
          </p></li><li><p>
            Upon receiving focus, the root element shall be resumed.
          </p></li><li><p>

            Upon losing focus, all focusout animations of the child content are allowed to finish. By focusout animation, we mean all animations, that were triggered by a focusout event and all the animation elements they trigger in their turn. The focusout event has finished its active duration, when the last animation has finished its active duration. Then the root element is paused and it's rendering becomes static.
          </p></li><li><p>
            The default "focusanimation" mode is "none".
          </p></li><li><p>
            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.
          </p></li><li><p>
            Whatever I18N support a WICD implementation provides should not
            be worse than that of the platform on which it is running.
          </p></li><li><p>
The following SVG sample markup must generate visible text:
&lt;svg xmlns="http://www.w3.org/2000/svg"
        viewBox="0 0 250 50"
        baseProfile="tiny" version="1.2"&gt;
  &lt;text x="20" y="20" font-size="30" fill="#000"&gt;Fahrvergnuegen&lt;/text&gt;
&lt;/svg&gt;
          </p></li><li><p>
            In both XHTML (using CSS) and SVG, font selection is done by the
            font-family property as described in CSS <a href="#CSS21">[Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification]</a>.
          </p></li><li><p>
            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.
          </p></li><li><p>
            Content (XHTML, SVG, CSS, script, etc) may be compressed with
            gzip <a href="#rfc1952">[IETF RFC 1952]</a> or deflate <a href="#rfc1951">[IETF RFC 1951]</a>. Conforming WICD viewers must
            correctly support gzip-encoded and deflate-encoded content.
          </p></li><li><p>
            If they support HTTP/1.1, they must support these encodings according
            to the HTTP/1.1 specification <a href="#rfc2616">[IETF RFC 2616]</a>; in particular, the client
            must specify with an "Accept-Encoding:" request header
            (section 14.4 of <a href="#rfc2616">[IETF RFC 2616]</a>) with those encodings that it accepts,
            including at minimum gzip and deflate, and then decompress any
            gzip-encoded and deflate-encoded data streams.
          </p></li><li><p>
            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.
          </p></li><li><p>
            Document formats conforming to WICD Core must use the
            Timing and Synchronization model defined in the
            SMIL specification.
          </p></li><li><p>
             The document begin for WICD documents is when the
             complete host document has been loaded by the user agent.
          </p></li><li><p>
             The document end for WICD documents is when the
             associated application exits or switches context to another document.
          </p></li><li><p>
             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.
          </p></li><li><p>
             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'.
          </p></li><li><p>
            An &lt;object&gt; element param element with
            name="timeline" and value="disable" shall prevent the timeline of
            the Scalable Child Content from starting or, if already started,
            shall stop it. Thus, animations will not play.
          </p></li><li><p>
            An &lt;object&gt; element param element with
            name="timeline" and value="enable" shall allow the timeline of the
            Scalable Child Content to start. Thus, for dynamic rendering,
            animations will play. If previously stopped, the timeline shall
            reset and re-start.
          </p></li><li><p>
            If there is no param element with
            name="timeline", the timeline of the Scalable Child Content shall
            start. Thus, for dynamic rendering, animations will play.
          </p></li><li><p>
            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".
          </p></li><li><p>
            Conforming WICD user agents must implement Media Queries <a href="#mq">[Media Queries]</a>.
          </p></li><li><p>
            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".
          </p></li></ol></div><div class="div1">
<h2><a name="references" id="references"></a>D References</h2><div class="div2">
<h3><a name="refsNormative" id="refsNormative"></a>D.1 Normative</h3><dl><dt class="label"><a name="REC-xml" id="REC-xml"></a>Extensible Markup Language (XML) 1.0 (Fourth Edition)</dt><dd>
            <a href="http://www.w3.org/TR/xml"><cite>
              Extensible Markup Language (XML) 1.0 (Fourth Edition)
            </cite></a>
            , C. M. Sperberg-McQueen, Eve Maler, Tim Bray,
            <em>et al.</em>
            , Editors. World Wide Web Consortium, 16 August 2006. This version
            is http://www.w3.org/TR/2006/REC-xml-20060816. The
            <a href="http://www.w3.org/TR/xml">latest version</a>
            is available at http://www.w3.org/TR/xml.
          </dd><dt class="label"><a name="REC-xml-names" id="REC-xml-names"></a>Namespaces in XML 1.0 (Second Edition)</dt><dd>
            <a href="http://www.w3.org/TR/xml-names"><cite>
              Namespaces in XML 1.0 (Second Edition)
            </cite></a>
            , Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin,
            Editors. World Wide Web Consortium, 16 Aug 2006. This version is
            http://www.w3.org/TR/2006/REC-xml-names-20060816. The
            <a href="http://www.w3.org/TR/xml-names">latest version</a>
            is available at http://www.w3.org/TR/xml-names.
          </dd><dt class="label"><a name="xml11" id="xml11"></a>Extensible Markup Language (XML) 1.1 (Second Edition)</dt><dd>
            <a href="http://www.w3.org/TR/xml11"><cite>
              Extensible Markup Language (XML) 1.1 (Second Edition)
            </cite></a>
            , Eve Maler, John Cowan, Jean Paoli,
            <em>et al.</em>
            , Editors. World Wide Web Consortium, 16 Aug 2006. This version
            is http://www.w3.org/TR/2006/REC-xml11-20060816. The
            <a href="http://www.w3.org/TR/xml11">latest version</a>
            is available at http://www.w3.org/TR/xml11.
          </dd><dt class="label"><a name="xml-names11" id="xml-names11"></a>Namespaces in XML 1.1 (Second Edition)</dt><dd>
            <a href="http://www.w3.org/TR/xml-names11"><cite>
              Namespaces in XML 1.1 (Second Edition)
            </cite></a>
            , Andrew Layman, Dave Hollander, Richard Tobin, and Tim Bray,
            Editors. World Wide Web Consortium, 16 Aug 2006. This version is
            http://www.w3.org/TR/2006/REC-xml-names11-20060816. The
            <a href="http://www.w3.org/TR/xml-names11">latest version</a>
            is available at http://www.w3.org/TR/xml-names11.
          </dd><dt class="label"><a name="DOM-Level-3-Core" id="DOM-Level-3-Core"></a>Document Object Model (DOM) Level 3 Core Specification</dt><dd>
            <a href="http://www.w3.org/TR/DOM-Level-3-Core/"><cite>
              Document Object Model (DOM) Level 3 Core Specification
            </cite></a>
            , Jonathan Robie, Steve Byrne, Philippe Le Hégaret,
            <em>et al.</em>
            , Editors. World Wide Web Consortium, 07 Apr 2004. This version
            is http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407. The
            <a href="http://www.w3.org/TR/DOM-Level-3-Core/">
              latest version
            </a>
            is available at http://www.w3.org/TR/DOM-Level-3-Core/.
          </dd><dt class="label"><a name="DOM-Level-3-Events" id="DOM-Level-3-Events"></a>Document Object Model (DOM) Level 3 Events Specification</dt><dd>
            <a href="http://www.w3.org/TR/DOM-Level-3-Events/"><cite>
              Document Object Model (DOM) Level 3 Events Specification
            </cite></a>
            , Tom Pixley and Philippe Le Hégaret, Editors. World Wide Web
            Consortium, 13 Apr 2006. This version is
            http://www.w3.org/TR/2006/WD-DOM-Level-3-Events-20060413. The
            <a href="http://www.w3.org/TR/DOM-Level-3-Events/">
              latest version
            </a>
            is available at http://www.w3.org/TR/DOM-Level-3-Events/.
          </dd><dt class="label"><a name="DOM-Level-2-HTML" id="DOM-Level-2-HTML"></a>Document Object Model (DOM) Level 2 HTML Specification</dt><dd>
            <a href="http://www.w3.org/TR/DOM-Level-2-HTML/"><cite>
              Document Object Model (DOM) Level 2 HTML Specification
            </cite></a>
            , Johnny Stenback, Philippe Le Hégaret, and Arnaud Le Hors,
            Editors. World Wide Web Consortium, 09 Jan 2003. This version is
            http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030107. The
            <a href="http://www.w3.org/TR/DOM-Level-2-HTML/">
              latest version
            </a>
            is available at http://www.w3.org/TR/DOM-Level-2-HTML/.
          </dd><dt class="label"><a name="CSS21" id="CSS21"></a>Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification</dt><dd>
            <a href="http://www.w3.org/TR/CSS21"><cite>
              Cascading Style Sheets, level 2 revision 1 CSS 2.1
              Specification
            </cite></a>
            , Håkon Wium Lie, Tantek Çelik, Bert Bos, and Ian Hickson,
            Editors. World Wide Web Consortium, 06 Nov 2006. This version is
            http://www.w3.org/TR/2006/WD-CSS21-20061106. The
            <a href="http://www.w3.org/TR/CSS21">latest version</a>
            is available at http://www.w3.org/TR/CSS21.
          </dd><dt class="label"><a name="css3-mediaqueries" id="css3-mediaqueries"></a>Media Queries</dt><dd>
            <a href="http://www.w3.org/TR/css3-mediaqueries/"><cite>
              Media Queries
            </cite></a>
            , Håkon Wium Lie, Tantek Çelik, and Daniel Glazman, Editors.
            World Wide Web Consortium, 08 Jul 2002. This version is
            http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708. The
            <a href="http://www.w3.org/TR/css3-mediaqueries/">
              latest version
            </a>
            is available at http://www.w3.org/TR/css3-mediaqueries/.
          </dd><dt class="label"><a name="xhtml11" id="xhtml11"></a>XHTML™ 1.1 - Module-based XHTML</dt><dd>
            <a href="http://www.w3.org/TR/xhtml11/"><cite>
              XHTML™ 1.1 - Module-based XHTML
            </cite></a>
            , Murray Altheim and Shane McCarron, Editors. World Wide Web
            Consortium, 31 May 2001. This version is
            http://www.w3.org/TR/2001/REC-xhtml11-20010531. The
            <a href="http://www.w3.org/TR/xhtml11/">latest version</a>
            is available at http://www.w3.org/TR/xhtml11/.
          </dd><dt class="label"><a name="PNG" id="PNG"></a>Portable Network Graphics (PNG) Specification (Second Edition)</dt><dd>
            <a href="http://www.w3.org/TR/PNG"><cite>
              Portable Network Graphics (PNG) Specification (Second
              Edition)
            </cite></a>
            , David Duce, Editor. World Wide Web Consortium, 10 Nov 2003.
            This version is http://www.w3.org/TR/2003/REC-PNG-20031110. The
            <a href="http://www.w3.org/TR/PNG">latest version</a>
            is available at http://www.w3.org/TR/PNG.
          </dd><dt class="label"><a name="xml-events" id="xml-events"></a>XML Events</dt><dd>
            <a href="http://www.w3.org/TR/xml-events"><cite>
              XML Events
            </cite></a>
            , T. V. Raman, Steven Pemberton, and Shane McCarron, Editors.
            World Wide Web Consortium, 14 Oct 2003. This version is
            http://www.w3.org/TR/2003/REC-xml-events-20031014. The
            <a href="http://www.w3.org/TR/xml-events">latest version</a>
            is available at http://www.w3.org/TR/xml-events.
          </dd><dt class="label"><a name="SMIL2" id="SMIL2"></a>Synchronized Multimedia Integration Language (SMIL 2.1)</dt><dd>
            <a href="http://www.w3.org/TR/SMIL2/"><cite>
              Synchronized Multimedia Integration Language (SMIL 2.1)
            </cite></a>
            , Dick Bulterman <em>et al.</em>, Editors.
            World Wide Web Consortium, 13 Dec 2005. This version is
            http://www.w3.org/TR/2005/REC-SMIL2-20051213/. The
            <a href="http://www.w3.org/TR/SMIL2/">latest version</a>
            is available at http://www.w3.org/TR/SMIL2/.
          </dd><dt class="label"><a name="SVGMobile12" id="SVGMobile12"></a>Scalable Vector Graphics (SVG) Tiny 1.2 Specification</dt><dd>
            <a href="http://www.w3.org/TR/SVGMobile12/"><cite>
              Scalable Vector Graphics (SVG) Tiny 1.2 Specification
            </cite></a>
            Ola Andersson, Robin Berjon, Erik Dahlström, Andrew Emmons, Jon Ferraiolo,
            Vincent Hardy, Scott Hayman, Dean Jackson, Chris Lilley, Andreas Neumann,
            Craig Northway, Antoine Quint, Nandini Ramani, Doug Schepers, and
            Andrew Shellshear, Editors. World Wide Web Consortium, 10 Aug 2006.
            This version is http://www.w3.org/TR/2006/CR-SVGMobile12-20060810/.
            The <a href="http://www.w3.org/TR/SVGMobile12/">latest version</a>
            is available at http://www.w3.org/TR/SVGMobile12/.
          </dd><dt class="label"><a name="CDR" id="CDR"></a>Compound Document by Reference Framework 1.0</dt><dd>
            <a href="http://www.w3.org/TR/CDR/"><cite>
              Compound Document by Reference Framework 1.0
            </cite></a>
            , Timur Mehrvarz, Daniel Appelquist, Lasse Pajunen, and Julien Quint,
            Editors.
            World Wide Web Consortium, 22 Nov 2006. This version is
            http://www.w3.org/TR/2006/WD-CDR-20061122/. The
            <a href="http://www.w3.org/TR/CDR/">latest version</a>
            is available at http://www.w3.org/TR/CDR/.
          </dd><dt class="label"><a name="WAI-WEBCONTENT" id="WAI-WEBCONTENT"></a>Web Content Accessibility Guidelines 1.0</dt><dd>
            <a href="http://www.w3.org/TR/WAI-WEBCONTENT"><cite>
              Web Content Accessibility Guidelines 1.0
            </cite></a>
            , Wendy Chisholm, Gregg Vanderheiden, and Ian Jacobs, Editors.
            World Wide Web Consortium, 05 May 1999. This version is
            http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/. The
            <a href="http://www.w3.org/TR/WAI-WEBCONTENT">latest version</a>
            is available at http://www.w3.org/TR/WAI-WEBCONTENT.
          </dd><dt class="label"><a name="ecmascript-language" id="ecmascript-language"></a>ECMAScript Language Specification 3rd Edition</dt><dd>
            <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm"><cite>
              ECMAScript Language Specification 3rd Edition
            </cite></a>
            , European Computer Manufacturers Association,
            December 1999. Also available as ISO/IEC 16262:2002
          </dd><dt class="label"><a name="scriptingmediatypes" id="scriptingmediatypes"></a>Scripting Media Types</dt><dd>
            <a href="http://www.ietf.org/rfc/rfc4329.txt"><cite>
              Scripting Media Types
            </cite></a>
            , IETF RFC 4329, April 2006
          </dd><dt class="label"><a name="mq" id="mq"></a>Media Queries</dt><dd>
            <a href="http://www.w3.org/TR/css3-mediaqueries/"><cite>Media Queries</cite></a>, Håkon Wium Lie,
              Tantek Çelik and Daniel Glazman, editors. W3C Candidate Recommendation, 8 July 2002.
          </dd><dt class="label"><a name="rfc1951" id="rfc1951"></a>IETF RFC 1951</dt><dd>
            <a href="http://www.ietf.org/rfc/rfc1951.txt"><cite>DEFLATE Compressed Data Format
              Specification version 1.3</cite></a>, IETF, May 1996.
          </dd><dt class="label"><a name="rfc1952" id="rfc1952"></a>IETF RFC 1952</dt><dd>
            <a href="http://www.ietf.org/rfc/rfc1952.txt"><cite>GZIP file format specification
              version 4.3</cite></a>, IETF, May 1996.
          </dd><dt class="label"><a name="rfc2119" id="rfc2119"></a>IETF RFC 2119</dt><dd>
            <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in
              RFCs to Indicate Requirement Levels</cite></a>, IETF, March 1997.
          </dd><dt class="label"><a name="rfc2616" id="rfc2616"></a>IETF RFC 2616</dt><dd>
            <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol -- HTTP/1.1</cite></a>, IETF, June 1999.
          </dd></dl></div><div class="div2">
<h3><a name="refsInformative" id="refsInformative"></a>D.2 Informative</h3><dl><dt class="label"><a name="html401" id="html401"></a>HTML 4.01 Specification</dt><dd>
            <a href="http://www.w3.org/TR/html401"><cite>
              HTML 4.01 Specification
            </cite></a>
            , David Raggett, Arnaud Le Hors, and Ian Jacobs, Editors. World
            Wide Web Consortium, 24 Dec 1999. This version is
            http://www.w3.org/TR/1999/REC-html401-19991224. The
            <a href="http://www.w3.org/TR/html401">latest version</a>
            is available at http://www.w3.org/TR/html401.
          </dd><dt class="label"><a name="REC-WebCGM" id="REC-WebCGM"></a>WebCGM 1.0 Second Release</dt><dd>
            <a href="http://www.w3.org/TR/REC-WebCGM"><cite>
              WebCGM 1.0 Second Release
            </cite></a>
            , Lofton Henderson, Roy Platon, Dieter Weidenbrueck,
            <em>et al.</em>
            , Editors. World Wide Web Consortium, 17 Dec 2001. This version
            is http://www.w3.org/TR/2001/REC-WebCGM-20011217/. The
            <a href="http://www.w3.org/TR/REC-WebCGM">latest version</a>
            is available at http://www.w3.org/TR/REC-WebCGM.
          </dd><dt class="label"><a name="MathML2" id="MathML2"></a>Mathematical Markup Language (MathML) Version 2.0 (Second Edition)</dt><dd>
            <a href="http://www.w3.org/TR/MathML2/"><cite>
              Mathematical Markup Language (MathML) Version 2.0 (Second
              Edition)
            </cite></a>
            , David Carlisle, Patrick Ion, Robert Miner, and Nico Poppelier,
            Editors. World Wide Web Consortium, 21 Oct 2003. This version is
            http://www.w3.org/TR/2003/REC-MathML2-20031021/. The
            <a href="http://www.w3.org/TR/MathML2/">latest version</a>
            is available at http://www.w3.org/TR/MathML2/.
          </dd><dt class="label"><a name="voicexml20" id="voicexml20"></a>Voice Extensible Markup Language (VoiceXML) Version 2.0</dt><dd>
            <a href="http://www.w3.org/TR/voicexml20"><cite>
              Voice Extensible Markup Language (VoiceXML) Version 2.0
            </cite></a>
            , Jim Ferrans, Bruce Lucas, Ken Rehor,
            <em>et al.</em>
            , Editors. World Wide Web Consortium, 16 Mar 2004. This version
            is http://www.w3.org/TR/2004/REC-voicexml20-20040316/. The
            <a href="http://www.w3.org/TR/voicexml20">latest version</a>
            is available at http://www.w3.org/TR/voicexml20.
          </dd><dt class="label"><a name="webarch" id="webarch"></a>Architecture of the World Wide Web, Volume One</dt><dd>
            <a href="http://www.w3.org/TR/webarch/"><cite>
              Architecture of the World Wide Web, Volume One
            </cite></a>
            , Norman Walsh and Ian Jacobs, Editors. World Wide Web
            Consortium, 15 Dec 2004. This version is
            http://www.w3.org/TR/2004/REC-webarch-20041215/. The
            <a href="http://www.w3.org/TR/webarch/">latest version</a>
            is available at http://www.w3.org/TR/webarch/.
          </dd><dt class="label"><a name="CDRReqs" id="CDRReqs"></a>Compound Document by Reference Use Cases and Requirements Version 1.0</dt><dd>
            <a href="http://www.w3.org/TR/CDRReqs/"><cite>
              Compound Document by Reference Use Cases and Requirements
              Version 1.0
            </cite></a>
            , Daniel Appelquist, Timur Mehrvarz, and Antoine Quint, Editors.
            World Wide Web Consortium, 19 Dec 2005. This version is
            http://www.w3.org/TR/2005/NOTE-CDRReqs-20051219/. The
            <a href="http://www.w3.org/TR/CDRReqs/">latest version</a>
            is available at http://www.w3.org/TR/CDRReqs/.
          </dd><dt class="label"><a name="WICDFull" id="WICDFull"></a>WICD Full 1.0</dt><dd>
            <a href="http://www.w3.org/TR/WICDFull/"><cite>
              WICD Full 1.0
            </cite></a>
            , Timur Mehrvarz, Daniel Appelquist, Lasse Pajunen, and Julien Quint,
            Editors.
            World Wide Web Consortium, 22 Nov 2006. This version is
            http://www.w3.org/TR/2006/WD-WICDFull-20061122/. The
            <a href="http://www.w3.org/TR/WICDFull/">latest version</a>
            is available at http://www.w3.org/TR/WICDFull/.
          </dd><dt class="label"><a name="WICDMobile" id="WICDMobile"></a>WICD Mobile 1.0</dt><dd>
            <a href="http://www.w3.org/TR/WICDMobile/"><cite>
              WICD Mobile 1.0
            </cite></a>
            , Timur Mehrvarz, Daniel Appelquist, Lasse Pajunen, and Julien Quint,
            Editors.
            World Wide Web Consortium, 22 Nov 2006. This version is
            http://www.w3.org/TR/2006/WD-WICDMobile-20061122/. The
            <a href="http://www.w3.org/TR/WICDMobile/">latest version</a>
            is available at http://www.w3.org/TR/WICDMobile/.
          </dd><dt class="label"><a name="ATAG10" id="ATAG10"></a>Authoring Tool Accessibility Guidelines 1.0</dt><dd>
            <a href="http://www.w3.org/TR/ATAG10"><cite>
              Authoring Tool Accessibility Guidelines 1.0
            </cite></a>
            , Ian Jacobs, Jutta Treviranus, Charles McCathieNevile, and Jan
            Richards, Editors. World Wide Web Consortium, 03 Feb 2000. This
            version is http://www.w3.org/TR/2000/REC-ATAG10-20000203. The
            <a href="http://www.w3.org/TR/ATAG10">latest version</a>
            is available at http://www.w3.org/TR/ATAG10.
          </dd><dt class="label"><a name="UAAG10" id="UAAG10"></a>User Agent Accessibility Guidelines 1.0</dt><dd>
            <a href="http://www.w3.org/TR/UAAG10/"><cite>
              User Agent Accessibility Guidelines 1.0
            </cite></a>
            , Jon Gunderson, Eric Hansen, and Ian Jacobs, Editors. World
            Wide Web Consortium, 17 Dec 2002. This version is
            http://www.w3.org/TR/2002/REC-UAAG10-20021217/. The
            <a href="http://www.w3.org/TR/UAAG10/">latest version</a>
            is available at http://www.w3.org/TR/UAAG10/.
          </dd><dt class="label"><a name="mobile-bp" id="mobile-bp"></a>Mobile Web Best Practices 1.0</dt><dd>
            <a href="http://www.w3.org/TR/mobile-bp/"><cite>
              Mobile Web Best Practices 1.0
            </cite></a>
            , Charles McCathieNevile and Jo Rabin, Editors. World Wide Web
            Consortium, 2 Nov 2006. This version is
            http://www.w3.org/TR/2006/PR-mobile-bp-20061102/. The
            <a href="http://www.w3.org/TR/mobile-bp/">latest version</a>
            is available at http://www.w3.org/TR/mobile-bp/.
          </dd><dt class="label"><a name="xhtmlmp-svgt" id="xhtmlmp-svgt"></a>XHTMLMP+SVGT</dt><dd>
            <a href="http://lab.vodafone.com/public/XHTMLMP-SVGT-Recommendations.html"><cite>
              XHTMLMP+SVGT
            </cite></a>
            Combined Markup for Mobile Browsing - Recommended Practice. Vodafone Group.
          </dd><dt class="label"><a name="idlsyntax" id="idlsyntax"></a>OMG IDL Syntax and Semantics</dt><dd>
            <a href="http://www.omg.org/technology/documents/formal/corba_2.htm"><cite>
              OMG IDL Syntax and Semantics
            </cite></a>
            , defined in The Common Object Request Broker: Architecture and Specification, version 2, Object Management Group.
          </dd></dl></div></div><div class="div1">
<h2><a name="acknowledgements" id="acknowledgements"></a>E Acknowledgements (Non-Normative)</h2><p>The editors would like to thank the contributors:</p><ul><li><p>Ola Andersson, Ikivo</p></li><li><p>Daniel Appelquist, Vodafone</p></li><li><p>Mark Baker, Research in Motion, Limited, (formerly) Justsystem</p></li><li><p>L. David Baron, The Mozilla Foundation</p></li><li><p>Robin Berjon, Expway</p></li><li><p>Kurt Cagle, Mercurial Communications Inc.</p></li><li><p>Cyril Concolato, Groupe des Écoles des Télécommunications (GET)</p></li><li><p>Erik Dahlström, Opera Software</p></li><li><p>Alex Danilo, W3C Invited Experts</p></li><li><p>Jean-Claude Dufourd, Streamezzo</p></li><li><p>Andrew Emmons, Bitflash Division of Open Text</p></li><li><p>Hae Seok Lee, Infraware</p></li><li><p>Torkel Hambraeus, Ikivo</p></li><li><p>Vincent Hardy (Previous Working Group Chair), Sun Microsystems, Inc.</p></li><li><p>Takanari Hayama, Vodafone</p></li><li><p>Scott Hayman, Research In Motion Limited</p></li><li><p>Ian Hickson, (formerly) Opera Software</p></li><li><p>Masayasu Ishikawa, (Working Group Team Contact) W3C</p></li><li><p>Dean Jackson (previous Working Group Team Contact), W3C</p></li><li><p>Kevin Kelly (Working Group Chair), IBM</p></li><li><p>Anne van Kesteren, Opera Software</p></li><li><p>Rhys Lewis, Volantis</p></li><li><p>Chris Lilley, W3C</p></li><li><p>Lars-Gunnar Lundgren, Obigo</p></li><li><p>Vincent Mahe, France Telecom</p></li><li><p>Charles McCathieNevile, Opera Software</p></li><li><p>Timur Mehrvarz, Vodafone</p></li><li><p>Kunio Ohno, Justsystems Corporation</p></li><li><p>Lasse Pajunen, Nokia</p></li><li><p>Lars Piepel, Vodafone</p></li><li><p>Antoine Quint, Fuchsia Design</p></li><li><p>Julien Quint, DAISY Consortium</p></li><li><p>Nandini Ramani, Sun Microsystems, Inc.</p></li><li><p>Seung Chul Yeh, Infraware</p></li><li><p>Svante Schubert, Sun Microsystems, Inc.</p></li><li><p>Bradley Sipes, Ikivo</p></li><li><p>Steve Speicher, IBM</p></li><li><p>Peter Stark, Sony Ericsson</p></li><li><p>Petri Vuorimaa, Helsinki University of Technology</p></li><li><p>Daniel Zucker, ACCESS Co., Ltd.</p></li></ul></div><div class="div1">
<h2><a name="changes-log" id="changes-log"></a>F Changes Log (Non-Normative)</h2><dl><dt class="label">2007-07-01</dt><dd><ul><li><p>
                Prepeared CR state. (TM)
              </p></li><li><p>
                Fixed document-internal linking. (Converted from "[reference to "xxx" removed since]" to "specref ref="rightsizing-inf"") (TM)
              </p></li></ul></dd><dt class="label">2007-04-26</dt><dd><ul><li><p>Updated the link to CSS21 "Visual formatting model" under <a href="#rightsizing"><b>3.3.1 Rightsizing</b></a> to point to newly modified section "Inline, replaced elements". (TM)</p></li><li><p>Moved text about <a href="#rightsizing-inf"><b>3.3.1.1 Rightsizing Behavior</b></a> into a new *Informative* section. (TM)</p></li></ul></dd><dt class="label">2007-04-16</dt><dd><ul><li><p>Updated status of the document to CR. (TM)</p></li><li><p>
                Outcommented changelog entries before 22. December 2006. (TM)
              </p></li></ul></dd><dt class="label">2007-03-31</dt><dd><ul><li><p>Split <a href="#references"><b>D References</b></a> into Normative and Informative. (TM)</p></li><li><p>Using author list, sorted by last name. (TM)</p></li></ul></dd><dt class="label">2007-03-14</dt><dd><ul><li><p>Fixed typos. (JQ)</p></li><li><p>Removed expansion of abbreviation CDRF in description of WICD Mobile. (JQ)</p></li><li><p>Updated wording for render with value="frozen" in <a href="#still-image-rendering"><b>3.2.1.1 Still-Image Rendering</b></a>. (JQ)</p></li><li><p>Updated wording for "snapshotTime" in <a href="#child-objects"><b>3.2 Scalable Child Content Use Cases</b></a>. (JQ)</p></li><li><p>Changed "render/static" to "name='render' value='frozen'"
                in <a href="#child-objects"><b>3.2 Scalable Child Content Use Cases</b></a>. (JQ)</p></li><li><p>Changed sample caption to "rightsizing example" and fixed typos in <a href="#rightsizing"><b>3.3.1 Rightsizing</b></a>. (JQ)</p></li><li><p>Changed "the parent document should be visible through the leftovers..." to "must be visible." in <a href="#leftovers"><b>3.3.2 Leftover Margins</b></a>. (JQ)</p></li><li><p>Removed "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." from <a href="#transparency-intro"><b>3.3.3.1 Introduction</b></a>. (JQ)</p></li><li><p>Changed <a href="#transparency-requirements"><b>3.3.3.2 Transparency requirements</b></a> to "transparency must be supported." (JQ)</p></li><li><p>Added caption (in real text) to figure in <a href="#activatable-focus"><b>6.1.1 Hierarchical Child Focus</b></a>. (JQ)</p></li><li><p>Changed "The default focus mode is 'hierarchical'" to "The default focus mode depends on the User Agent. If a specific behavior is desired the content author must specify which focus mode to use." in <a href="#focus-modes"><b>6.1 Focus Modes</b></a>. (JQ)</p></li><li><p>Added "All sections are normative unless they are marked with '(This section is Informative)'" in <a href="#conformance"><b>C Conformance</b></a>. (JQ)</p></li><li><p>Updated text on load event in <a href="#temporal-sync"><b>9.1 Temporal Synchronization of Media</b></a> and changed "switched contents" to unload event. (JQ)</p></li></ul></dd><dt class="label">2007-03-05</dt><dd><ul><li><p>Modified text on "time zero(0)" and "snapshotTime" under <a href="#focus-event-triggered-child-animations"><b>6.3 Focus Event triggered Child Content Animations</b></a> based on Eric Dahlström's comments (TM).</p></li></ul></dd><dt class="label">2007-03-04</dt><dd><ul><li><p>Modified text on "focusout events" under <a href="#focus-event-triggered-child-animations"><b>6.3 Focus Event triggered Child Content Animations</b></a> based on Eric Dahlström's comments (TM).</p></li></ul></dd><dt class="label">2007-02-28</dt><dd><ul><li><p>
                Changed the order of sub-sections under "6 Focus Handling", by swapping 6.2 and 6.3 (TM).
              </p></li><li><p>
                Removed outcommented text (TM).
              </p></li></ul></dd><dt class="label">2007-02-27</dt><dd><ul><li><p>
                Marked focusin/focusout conventions as authors guides under <a href="#focus-event-triggered-child-animations"><b>6.3 Focus Event triggered Child Content Animations</b></a> based on Eric Dahlström's comments (TM).
              </p></li><li><p>Modified text on "losing focus" under <a href="#focus-event-triggered-child-animations"><b>6.3 Focus Event triggered Child Content Animations</b></a> based on Eric Dahlström's finding (TM).</p></li></ul></dd><dt class="label">2007-02-19</dt><dd><ul><li><p>Modified text on "non interactive elements made focusable" under <a href="#focus-handling"><b>6 Focus Handling</b></a> (TM)</p></li></ul></dd><dt class="label">2007-02-06</dt><dd><ul><li><p>Modified text and removed informative statement under <a href="#focus-navigation"><b>6.2 Focus Navigation</b></a> based on Steve's wording (TM)</p></li></ul></dd><dt class="label">2007-02-05</dt><dd><ul><li><p>Added normative statement under <a href="#focus-navigation"><b>6.2 Focus Navigation</b></a> based on Steve's wording (TM)</p></li></ul></dd><dt class="label">2007-02-01</dt><dd><ul><li><p>Modified definition of param "render/static" and param "render/frozen" under <a href="#still-image-rendering"><b>3.2.1.1 Still-Image Rendering</b></a> based on Chris's wording (TM)</p></li></ul></dd></dl></div></div></body></html>