2009/dap/camera Overview.html,1.124,1.125

Update of /sources/public/2009/dap/camera
In directory hutz:/tmp/cvs-serv29810

Modified Files:
	Overview.html 
Log Message:
reformat the source to ~80 chars width, no normative or editorial changes

Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/camera/Overview.html,v
retrieving revision 1.124
retrieving revision 1.125
diff -u -d -r1.124 -r1.125
--- Overview.html	28 Mar 2012 06:38:18 -0000	1.124
+++ Overview.html	11 May 2012 08:19:56 -0000	1.125
@@ -9,14 +9,12 @@
           specStatus:           "WD",
           shortName:            "html-media-capture",
           editors: [
-	            //{name: "Dzung D Tran", company: "Intel"},
-	            {name: "Ilkka Oksanen", company: "Nokia"},
-              //{name: "Ingmar Kliche", company: "Deutsche Telekom"},
+              {name: "Ilkka Oksanen", company: "Nokia"},
               {name: "Dominique Hazaël-Massieux", company: "W3C"}
-		    ],	    
-          publishDate:  "2011-04-14",
+          ],
+          publishDate:          "2011-04-14",
           previousPublishDate:  "2010-09-28",
-          previousMaturity: "WD",
+          previousMaturity:     "WD",
           edDraftURI:           "http://dev.w3.org/2009/dap/camera/",
           // lcEnd: "2009-08-05",
       };
@@ -24,234 +22,339 @@
     <script src='../common/config.js' class='remove'></script>
   </head>
   <body>
-  
+    
     <section id='abstract'>
-      This specification defines HTML form enhancements that provide access to the audio, image and video capture
-      capabilities of the device.  
+      This specification defines HTML form enhancements that provide access to
+      the audio, image and video capture capabilities of the device.
     </section>
-
+    
     <section id="sotd">
-<p>This document is a the first part of the split of the <a href="http://www.w3.org/TR/2010/WD-capture-api-20100401/">previous version</a>
-of this document, focused on the integration of media capture in HTML
-forms based on an extension to the <a href="http://www.w3.org/TR/FileAPI/">FileAPI</a>. The second part of the split focused on programmatic access to the capture devices will be published separately.</p>
-
-<p>The Working Group is looking for feedback on the general approach of
-this new version, and will coordinate with the HTML and Web Applications
-Working Group to ensure the proper progress of this document.</p>
-
-<p>Issues and editors notes in the document highlight some of the points on
-which the group is still working and would particularly like to get
-feedback.</p>
+      <p>
+        This document is a the first part of the split of the
+        <a href="http://www.w3.org/TR/2010/WD-capture-api-20100401/">previous
+        version</a> of this document, focused on the integration of media
+        capture in HTML forms based on an extension to the
+        <a href="http://www.w3.org/TR/FileAPI/">FileAPI</a>. The second part of
+        the split focused on programmatic access to the capture devices will be
+        published separately.
+      </p>
+      <p>
+        The Working Group is looking for feedback on the general approach of
+        this new version, and will coordinate with the HTML and Web
+        Applications Working Group to ensure the proper progress of this
+        document.
+      </p>
+      <p>
+        Issues and editors notes in the document highlight some of the points
+        on which the group is still working and would particularly like to get
+        feedback.
+      </p>
     </section>
-
+    
     <section>
-    <h2>Introduction</h2>
-
-    <p>The HTML Form Based Media Capturing specification defines a new
-    interface for media files, a new parameter for the accept attribute of the HTML input element in file upload state, and recommendations for
-    providing optimized access to the microphone and camera of a
-    hosting device.</p> 
-
-    <p>Providing streaming access to these capabilities is outside of the scope of this specification.</p>
-    <p class="note">The Working Group is investigating the opportunity to specify streaming access via the <a href="http://dev.w3.org/html5/html-device/">proposed <code>&lt;device&gt;</code> element</a>.</p>
+      <h2>Introduction</h2>
+      <p>
+        The HTML Form Based Media Capturing specification defines a new
+        interface for media files, a new parameter for the accept attribute of
+        the HTML input element in file upload state, and recommendations for
+        providing optimized access to the microphone and camera of a
+        hosting device.
+      </p>
+      <p>
+        Providing streaming access to these capabilities is outside of the
+        scope of this specification.
+      </p>
+      <div class="note">
+        The Working Group is investigating the opportunity to specify streaming
+        access via the <a href="http://dev.w3.org/html5/html-device/">proposed
+        <code>&lt;device&gt;</code> element</a>.
+      </div>
     </section>
 
     <section id="conformance">
       <p>
-        This specification defines conformance criteria that apply to a single product: the <dfn>user agent</dfn> that implements the
-        interfaces that it contains.
+        This specification defines conformance criteria that apply to a single
+        product: the <dfn>user agent</dfn> that implements the interfaces that
+        it contains.
       </p>
       <p>
-
-        Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent
-        with the ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]], as this specification uses that specification and
-        terminology.
+        Implementations that use ECMAScript to implement the APIs defined in
+        this specification must implement them in a manner consistent with the
+        ECMAScript Bindings defined in the Web IDL specification [[!WEBIDL]],
+        as this specification uses that specification and terminology.
       </p>
-
     </section>
 
     <section id="security">
-    <h2>Security and Privacy Considerations</h2>
-    <p>This specification builds upon the security and privacy protections provided by the [[!HTML5]] <code>&lt;input type="file"&gt;</code> and the [[!FILE-API]] specifications; in particular, it is expected that any offer to start capturing content from the user’s device would require a specific user interaction on an HTML element that is entirely controlled by the user agent.</p>
-
-    <p>In addition to the requirements already highlighted in the [[!HTML5]] and [[!FILE-API]] specifications, implementors should take care of additional leakage of privacy-sensitive data from captured media. For instance, embedding the user’s location in a captured media metadata (e.g. EXIF) might transmit more private data than the user might be expecting.</p>
-
+      <h2>Security and Privacy Considerations</h2>
+      <p>
+        This specification builds upon the security and privacy protections
+        provided by the [[!HTML5]] <code>&lt;input type="file"&gt;</code> and
+        the [[!FILE-API]] specifications; in particular, it is expected that
+        any offer to start capturing content from the user’s device would
+        require a specific user interaction on an HTML element that is entirely
+        controlled by the user agent.
+      </p>
+      
+      <p>
+        In addition to the requirements already highlighted in the [[!HTML5]]
+        and [[!FILE-API]] specifications, implementors should take care of
+        additional leakage of privacy-sensitive data from captured media. For
+        instance, embedding the user’s location in a captured media metadata
+        (e.g. EXIF) might transmit more private data than the user might be
+        expecting.
+      </p>
     </section>
-
-
-  <section id="formaccess">
-    <h2>Capture aware file-select control</h2>
-
-    <p>This section is normative.</p>
-
-    <p class="note">[[!HTML5]] <a href="http://dev.w3.org/html5/spec/number-state.html#file-upload-state">links <code>&lt;input type="file"&gt;</code></a> to the File interface. This specification defines a refined <code>MediaFile</code> interface to be used when the <code>accept</code> attribute take certain values — this will require coordination with the HTML5 Working Group.</p>
-
-    <p>If an input element in the File Upload state [[!HTML5]] contains
-    accept attribute with values <code>image/*</code>,
-    <code>audio/*</code>, or <code>video/*</code>, the user agent can
-    invoke a file picker that allows respectively the user to take a
-    picture, record a sound file, or record a video in addition to
-    selecting an existing file from the file system.</p>
-
-    <p>See the <a href="#uiexamples">User Interface Examples</a> appendix for the illustration.
-
-    <p>In case the user chooses to capture video, audio, or image
-    content, the user agent creates media files on the fly <a href="http://dev.w3.org/html5/spec/number-state.html#file-upload-state">as
-    specified</a> in [[HTML5]].</p>
-
-    <p>If the user selects files of whose MIME types match <code>image/*</code>,
-    <code>audio/*</code>, or <code>video/*</code> (on the filesystem or via a successful media capture), the relevant files in the <code>files</code> attribute [[HTML5]] MUST implement the <code>MediaFile</code> interface.</p>
-
-    <pre class="example sh_html">&lt;input type="file" accept="image/*" id="capture"&gt; </pre>
-</section>
-
-  <section id="captureparam">
-    <h2>The <code>capture</code> attribute</h2>
-
-    <p>This section is normative.</p>
-
-
-    <p>The <code>capture</code> attribute may be added to the <code>input</code> element to provide user agents with a hint of that by the default a file picker should be in media capturing mode.</p>
-
-    <p>The <code>capture</code> attribute is an enumerated attribute that can take one of the following values: <code>camera</code>, <code>camcorder</code>, <code>microphone</code>, <code>filesystem</code> (ASCII case-insensitive). These values indicate which source the file picker interface should preferably present to the user by default. Both the invalid and missing default value are <code>filesystem</code>.</p>
-
-    <p class="issue">What to do if there is no accept attribute? What if the accept attribute is set to a value that the pre-hinted device cannot support? See <a href="http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0013.html">related discussion</a>.</p>
-
-    <dl title="[Supplemental] interface HTMLInputElement" class="idl">
-      <dt>attribute DOMString capture</dt>
-      <dd>One of <code>camera</code>, <code>camcorder</code>, <code>microphone</code>, <code>filesystem</code></dd>
-    </dl>
-
-    <p>For example, the following code indicates that the user is expected to upload an image from the device camera:</p>
-    <pre class="example sh_html">&lt;input type="file" accept="image/*" capture="camera" id="capture"&gt; </pre>
-    <p>A possible rendering of a file picker taking this parameter into account is offered in the <a href="#uiexamples">User Interface Examples appendix</a>.</p>
-</section>
-
-    <section id="api">
-    <h2>WebIDL interfaces</h2>
-
-    <section id="jsexample"><h3>Example</h3>
-      <p>After the user successfully captured or selected an existing media file, the format properties of the file can be retrieved as follow:</p>
-      <pre class="example sh_javascript_dom"><code>var captureInput = document.getElementById('capture');
-// Accessing the file object from the input element with id capture
-var file = captureInput.files[0];
-if (file) {
-  // getting format data asynchronously
-  file.<a href="#widl-MediaFile-getFormatData">getFormatData</a>(displayFormatData, errorHandler);
-}
-
-// success callback when getting format data
-function displayFormatData(formatData) {  
-  var mainType = file.type.split("/")[0]; // "image", "video" or "audio"
-  var mediaDescriptionNode = document.createElement("p");
-  if (mainType === "image") {
-    mediaDescriptionNode.appendChild(document.createTextNode("This is an image of dimensions " + <a href="#widl-MediaFileData-width">formatData.width</a> + "x" + <a href="#widl-MediaFileData-height">formatData.height</a>);
-  } else {
-    mediaDescriptionNode.appendChild(document.createTextNode("Duration: " + <a href="#widl-MediaFileData-duration">formatData.duration</a>  + "s");
-  }
-  captureInput.parentNode.insertBefore(mediaDescriptionNode, captureInput);
-}
-
-// error callback if getting format data fails
-function errorHandler(error) {
-  alert("Couldn’t retrieve format properties for the selected file (error code " + <a href="#widl-MediaFileDataError-code">error.code</a> + ")");
-}
-</code></pre>
-</section>
-
-
-    <section  id="formatdata"><h3><a>MediaFileData</a> interface</h3>
-
-    <p><code>MediaFileData</code> encapsulates format information of a media
-    file.</p>
-
-    <p class="note">The relationship between this <code>MediaFileData</code> interface and the properties made available through the API for Media Resource 1.0 [[MEDIAONT-API]] needs further investigation.</p>
-
-    <dl title="[NoInterfaceObject] interface MediaFileData" class="idl">
-
-      <dt>attribute DOMString codecs</dt>
-      <dd>The type attribute of the Blob interface (inherited from the File interface) is not sufficient to determine the format of the
-      content since it only specifies the container type. The codecs attribute
-      represents the actual format that the audio and video of the content.
-      The codecs attribute MUST conform to the [[!RFC4281]].
-      For example, a valid value for H.263 video and AAC low
-      complexity would be codecs="s263, mp4a.40.2".
-	<p class="note">This <a href="http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0133.html">could be turned into a list of DOMString</a> rather than keeping it as a comma-separated values list; this needs some care with regard to the RFC ref.</p>
-</dd>
-
-      <dt>attribute unsigned long bitrate </dt>
-      <dd>The codecs attribute only specifies the profile and level of the encoded content
-      which doesn't specify the actual bitrate. It only specifies the maximum encoded 
-      bitrate, thus this bitrate attribute is the average bitrate of the content. In the case
-      of an image this attribute has value 0.</dd>
-
-      <dt>attribute unsigned long height </dt>
-      <dd>The height attribute represents height of the image or video
-      in pixels. In the case of a sound clip this attribute has value 0.</dd>
-
-      <dt>attribute unsigned long width </dt>
-      <dd>The width attribute represents width of the image or video
-      in pixels. In the case of a sound clip this attribute has value 0.</dd>
-
-      <dt>attribute float duration </dt>
-      <dd>The duration attribute represents length of the video or sound
-      clip in seconds. In the case of an image this attribute has value 0.</dd>
-    </dl>
-
-    <p class="note">Some of the proposed attributes of the <code>MediaFileData</code> interface could possibly be integrated as parameters of the MIME type, or as MIME options object.</p>
     
+    <section id="formaccess">
+      <h2>Capture aware file-select control</h2>
+      <p>
+        This section is normative.
+      </p>      
+      <div class="note">
+        [[!HTML5]] <a href="http://dev.w3.org/html5/spec/number-state.html#file-upload-state">
+        links <code>&lt;input type="file"&gt;</code></a> to the File interface.
+        This specification defines a refined <code>MediaFile</code> interface
+        to be used when the <code>accept</code> attribute take certain values
+         — this will require coordination with the HTML5 Working Group.
+      </div>
+      <p>
+        If an input element in the File Upload state [[!HTML5]] contains
+        accept attribute with values <code>image/*</code>, <code>audio/*</code>,
+        or <code>video/*</code>, the user agent can invoke a file picker that
+        allows respectively the user to take a picture, record a sound file, or
+        record a video in addition to selecting an existing file from the file
+        system.
+      </p>
+      <p>
+        See the <a href="#uiexamples">User Interface Examples</a> appendix for
+        the illustration.
+      </p>
+      <p>
+        In case the user chooses to capture video, audio, or image content, the
+        user agent creates media files on the fly
+        <a href="http://dev.w3.org/html5/spec/number-state.html#file-upload-state">
+        as specified</a> in [[HTML5]].
+      </p>
+      <p>
+        If the user selects files of whose MIME types match <code>image/*</code>,
+        <code>audio/*</code>, or <code>video/*</code> (on the filesystem or via
+        a successful media capture), the relevant files in the <code>files</code>
+        attribute [[HTML5]] MUST implement the <code>MediaFile</code> interface.
+      </p>
+      <pre class="example sh_html">
+        &lt;input type="file" accept="image/*" id="capture"&gt;
+      </pre>
     </section>
-
-
-    <section id="mediafile"><h3><a>MediaFile</a> interface</h3>
-
-    <p><code>MediaFile</code> encapsulates a single photo, video or sound
-    from the device. It inherits
-    from <code><a href="http://www.w3.org/TR/FileAPI/#dfn-file">File</a></code> [[!FILE-API]].</p>
-
-    <dl title="[NoInterfaceObject] interface MediaFile : File" class="idl">
-
-    <dt>void getFormatData (in MediaFileDataSuccessCallback successCallback,
-                           in optional MediaFileDataErrorCallback errorCallback) </dt>
-
-    <dd>The <code>getFormatData()</code> method takes one or two arguments. When called, it returns immediately and then asynchronously attempts to obtain the format data of the given media file. If the attempt is successful, the <code>successCallback</code> is invoked with a new <code>MediaFileData</code> object, reflecting the format data of the file. If the attempt fails, the <code>errorCallback</code> is invoked with a new MediaFileDataError object, reflecting the reason for the failure.
-    </dd></dl>
+    
+    <section id="captureparam">
+      <h2>The <code>capture</code> attribute</h2>
+      <p>This section is normative.</p>
+      <p>
+        The <code>capture</code> attribute may be added to the <code>input</code>
+        element to provide user agents with a hint of that by the default a
+        file picker should be in media capturing mode.
+      </p>
+      <p>
+        The <code>capture</code> attribute is an enumerated attribute that can
+        take one of the following values: <code>camera</code>, <code>camcorder
+        </code>, <code>microphone</code>, <code>filesystem</code> (ASCII
+        case-insensitive). These values indicate which source the file picker
+        interface should preferably present to the user by default. Both the
+        invalid and missing default value are <code>filesystem</code>.
+      </p>
+      <div class="issue">
+        What to do if there is no accept attribute? What if the accept attribute
+        is set to a value that the pre-hinted device cannot support? See
+        <a href="http://lists.w3.org/Archives/Public/public-device-apis/2011Apr/0013.html">
+        related discussion</a>.
+      </div>
+      <dl title="[Supplemental] interface HTMLInputElement" class="idl">
+        <dt>attribute DOMString capture</dt>
+        <dd>
+          One of <code>camera</code>, <code>camcorder</code>,
+          <code>microphone</code>, <code>filesystem</code>
+        </dd>
+      </dl>
+      <p>
+        For example, the following code indicates that the user is expected to
+        upload an image from the device camera:
+      </p>
+      <pre class="example sh_html">
+        &lt;input type="file" accept="image/*" capture="camera" id="capture"&gt;
+      </pre>
+      <p>
+        A possible rendering of a file picker taking this parameter into
+        account is offered in the <a href="#uiexamples">User Interface Examples
+        appendix</a>.
+      </p>
     </section>
-    <section id="mediafiledatasuccesscallback"><h3><a>MediaFileDataSuccessCallback</a> interface</h3>
-    <dl title="[Callback=FunctionOnly, NoInterfaceObject] interface MediaFileDataSuccessCallback" class="idl">
-      <dt>void onSuccess()</dt>
-      <dd>
-        <dl class='parameters'>
+    
+    <section id="api">
+    <h2>WebIDL interfaces</h2>
+      <section id="jsexample">
+        <h3>Example</h3>
+        <p>
+          After the user successfully captured or selected an existing media
+          file, the format properties of the file can be retrieved as follow:
+        </p>
+        <pre class="example sh_javascript_dom">
+          <code>
+          var captureInput = document.getElementById('capture');
+          // Accessing the file object from the input element with id capture
+          var file = captureInput.files[0];
+          if (file) {
+            // getting format data asynchronously
+            file.<a href="#widl-MediaFile-getFormatData">getFormatData</a>(displayFormatData, errorHandler);
+          }
+          
+          // success callback when getting format data
+          function displayFormatData(formatData) {  
+            var mainType = file.type.split("/")[0]; // "image", "video" or "audio"
+            var mediaDescriptionNode = document.createElement("p");
+            if (mainType === "image") {
+              mediaDescriptionNode.appendChild(document.createTextNode("This is an image of dimensions " +
+              <a href="#widl-MediaFileData-width">formatData.width</a> + "x" + <a href="#widl-MediaFileData-height">formatData.height</a>);
+            } else {
+              mediaDescriptionNode.appendChild(document.createTextNode("Duration: " + <a href="#widl-MediaFileData-duration">formatData.duration</a>  + "s");
+            }
+            captureInput.parentNode.insertBefore(mediaDescriptionNode, captureInput);
+          }
+          
+          // error callback if getting format data fails
+          function errorHandler(error) {
+            alert("Couldn’t retrieve format properties for the selected file (error code " + <a href="#widl-MediaFileDataError-code">error.code</a> + ")");
+          }
+          </code>
+        </pre>
+      </section>
+      <section  id="formatdata"><h3><a>MediaFileData</a> interface</h3>
+        <p>
+          <code>MediaFileData</code> encapsulates format information of a media
+          file.
+        </p>
+        <div class="note">
+          The relationship between this <code>MediaFileData</code> interface
+          and the properties made available through the API for Media Resource
+          1.0 [[MEDIAONT-API]] needs further investigation.
+        </div>
+        <dl title="[NoInterfaceObject] interface MediaFileData" class="idl">
+          <dt>attribute DOMString codecs</dt>
+          <dd>
+            The type attribute of the Blob interface (inherited from the File
+            interface) is not sufficient to determine the format of the content
+            since it only specifies the container type. The codecs attribute
+            represents the actual format that the audio and video of the content.
+            The codecs attribute MUST conform to the [[!RFC4281]]. For example,
+            a valid value for H.263 video and AAC low complexity would be 
+            codecs="s263, mp4a.40.2".
+            <div class="note">
+              This <a href="http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0133.html">
+              could be turned into a list of DOMString</a> rather than keeping
+              it as a comma-separated values list; this needs some care with
+              regard to the RFC ref.
+            </div>
+          </dd>
+          <dt>attribute unsigned long bitrate</dt>
+          <dd>
+            The codecs attribute only specifies the profile and level of the
+            encoded content which doesn't specify the actual bitrate. It only
+            specifies the maximum encoded bitrate, thus this bitrate attribute
+            is the average bitrate of the content. In the case of an image this
+            attribute has value 0.
+          </dd>
+          <dt>attribute unsigned long height</dt>
+          <dd>
+            The height attribute represents height of the image or video in
+            pixels. In the case of a sound clip this attribute has value 0.
+          </dd>
+          <dt>attribute unsigned long width </dt>
+          <dd>
+            The width attribute represents width of the image or video in
+            pixels. In the case of a sound clip this attribute has value 0.
+          </dd>
+          <dt>attribute float duration </dt>
+          <dd>
+            The duration attribute represents length of the video or sound clip
+            in seconds. In the case of an image this attribute has value 0.
+          </dd>
+        </dl>
+        <div class="note">
+          Some of the proposed attributes of the <code>MediaFileData</code>
+          interface could possibly be integrated as parameters of the MIME
+          type, or as MIME options object.
+        </div>
+      </section>
+      <section id="mediafile"><h3><a>MediaFile</a> interface</h3>
+        <p>
+          <code>MediaFile</code> encapsulates a single photo, video or sound
+          from the device. It inherits from <code>
+          <a href="http://www.w3.org/TR/FileAPI/#dfn-file">File</a></code>
+          [[!FILE-API]].
+        </p>
+        <dl title="[NoInterfaceObject] interface MediaFile : File"
+            class="idl">
+          <dt>
+            void getFormatData (in MediaFileDataSuccessCallback successCallback,
+                                in optional MediaFileDataErrorCallback errorCallback)
+          </dt>
+          <dd>
+            The <code>getFormatData()</code> method takes one or two arguments.
+            When called, it returns immediately and then asynchronously attempts
+            to obtain the format data of the given media file. If the attempt is
+            successful, the <code>successCallback</code> is invoked with a new
+            <code>MediaFileData</code> object, reflecting the format data of the
+            file. If the attempt fails, the <code>errorCallback</code> is invoked
+            with a new MediaFileDataError object, reflecting the reason for the
+            failure.
+          </dd>
+        </dl>
+      </section>
+      <section id="mediafiledatasuccesscallback">
+        <h3><a>MediaFileDataSuccessCallback</a> interface</h3>
+        <dl title="[Callback=FunctionOnly, NoInterfaceObject] interface MediaFileDataSuccessCallback"
+            class="idl">
+          <dt>void onSuccess()</dt>
+          <dd>
+            <dl class='parameters'>
               <dt>
                 MediaFileData formatData
               </dt>
               <dd>
-		The MediaFileData object describing the relevant properties of the given media file.
+                The MediaFileData object describing the relevant properties of
+                the given media file.
               </dd>
             </dl>
-
-    </dl>
-    </section>
-    <section id="mediafiledataerrorcallback"><h3><a>MediaFileDataErrorCallback</a> interface</h3>
-    <dl title="[Callback=FunctionOnly, NoInterfaceObject] interface MediaFileDataErrorCallback" class="idl">
-      <dt>void onError()</dt>
-      <dd>
-        <dl class='parameters'>
+          </dd>
+        </dl>
+      </section>
+      <section id="mediafiledataerrorcallback">
+        <h3><a>MediaFileDataErrorCallback</a> interface</h3>
+        <dl title="[Callback=FunctionOnly, NoInterfaceObject] interface MediaFileDataErrorCallback"
+            class="idl">
+          <dt>void onError()</dt>
+          <dd>
+            <dl class='parameters'>
               <dt>
                 MediaFileDataError error
               </dt>
               <dd>
-		The <code>MediaFileDataError</code> object describing the error encountered while retrieving the format data.
+                The <code>MediaFileDataError</code> object describing the error
+                encountered while retrieving the format data.
               </dd>
             </dl>
-
-    </dl>
-    </section>
-    <section id="mediafiledataerror"><h3><a>MediaFileDataError</a> interface</h3>
-<p>The <code>MediaFileDataError</code> interface encapsulates all errors in the retrieval of format data associated with a <code>MediaFile</code> object.</p>
-        <dl
-         title='[NoInterfaceObject] interface MediaFileDataError'
-         class='idl'>
+          </dd>
+        </dl>
+      </section>
+      <section id="mediafiledataerror">
+        <h3><a>MediaFileDataError</a> interface</h3>
+        <p>
+          The <code>MediaFileDataError</code> interface encapsulates all errors
+          in the retrieval of format data associated with a
+          <code>MediaFile</code> object.
+        </p>
+        <dl title='[NoInterfaceObject] interface MediaFileDataError'
+            class='idl'>
           <dt>
             const unsigned short UNKNOWN_ERROR = 0
           </dt>
@@ -264,22 +367,25 @@
           <dd>
             The requested method timed out before it could be completed.
           </dd>
-	  <dt>readonly attribute unsigned short code</dt>
-	  <dd>An error code assigned by an implementation when an error has occurred in retrieving format data.</dd>
-	</dl>
-
+          <dt>readonly attribute unsigned short code</dt>
+          <dd>
+            An error code assigned by an implementation when an error has
+            occurred in retrieving format data.
+          </dd>
+        </dl>
+      </section>
     </section>
-
+    
+    <section class='appendix' id="uiexamples">
+    <h2>User Interface Examples</h2>
+    <p>
+      A media capture file picker might render as:
+    </p>
+    <p>
+      <img alt="A File picker with camera support"
+      src="capture-api-file-picker-concept.png">
+    </p>
   </section>
-
-
-<section class='appendix' id="uiexamples">
-<h2>User Interface Examples</h2>
-
-<p>A media capture file picker might render as:
-
-<p><img alt="A File picker with camera support" src="capture-api-file-picker-concept.png"></p> 
-</section>
-
+  
 </body>
 </html>

Received on Friday, 11 May 2012 08:20:15 UTC