HTML Standard Tracker

Filter

File a bug

SVNBugCommentTime (UTC)
49399239Include some advice on how to do experimental non-standard attributes.2010-04-01 23:20
@@ -2110,84 +2110,181 @@ a.setAttribute('href', 'http://example.com/'); // change the content attribute d
   features assume that those languages and protocols are in use.</p>
 
   <p class="note">This specification might have certain additional
   requirements on character encodings, image formats, audio formats,
   and video formats in the respective sections.</p>
 
   </div>
 
 
 
+  <h4>Extensibility</h4>
+
+  <p>HTML has a wide number of extensibility mechanisms that can be
+  used for adding semantics in a safe manner:</p>
+
+  <ul>
+
+   <li>Authors can use the <code title="attr-class">class</code>
+   attribute to extend elements, effectively creating their own
+   elements, while using the most applicable existing "real" HTML
+   element, so that browsers and other tools that don't know of the
+   extension can still support it somewhat well. This is the tack used
+   by Microformats, for example.</li>
+
+   <li>Authors can include data for inline client-side scripts or
+   server-side site-wide scripts to process using the <code
+   title="attr-data-*">data-*=""</code> attributes. These are
+   guaranteed to never be touched by browsers, and allow scripts to
+   include data on HTML elements that scripts can then look for and
+   process.</li>
+
+   <li>Authors can use the <code title="meta">&lt;meta name=""
+   content=""></code> mechanism to include page-wide metadata by
+   registering <span title="concept-meta-extensions">extensions to the
+   predefined set of metadata names</span>.</li>
+
+   <li>Authors can use the <code
+   title="attr-hyperlink-rel">rel=""</code> mechanism to annotate
+   links with specific meanings by registering <Span
+   title="concept-rel-extensions"> extensions to the predefined set of
+   link types</span>. This is also used by Microformats.</li>
+
+   <li>Authors can embed raw data using the <code
+   title="script">&lt;script type=""></code> mechanism with a custom
+   type, for further handling by a inline or server-side scripts.</li>
+
+   <li>Authors can create <span title="plugin">plugins</span> and
+   invoke them using the <code>embed</code> element. This is how Flash
+   works.</li>
+
+   <li>Authors can extend APIs using the JavaScript prototyping
+   mechanism. This is widely used by script libraries, for
+   instance.</li>
+
+   <li>Authors can use the microdata feature (the <code
+   title="attr-item">item=""</code> and <code
+   title="attr-itemprop">itemprop=""</code> attributes) to embed
+   nested name-value pairs of data to be shared with other
+   applications and sites.</li>
+
+  </ul>
+
   <div class="impl">
 
-  <h4>Extensibility</h4>
+  <hr>
+
+  <p>Vendor-specific proprietary user agent extensions to this
+  specification are strongly discouraged. Documents must not use such
+  extensions, as doing so reduces interoperability and fragments the
+  user base, allowing only users of specific user agents to access the
+  content in question.</p>
 
-  <p>Vendor-specific proprietary extensions to this specification are
-  strongly discouraged. Documents must not use such extensions, as
-  doing so reduces interoperability and fragments the user base,
-  allowing only users of specific user agents to access the content in
-  question.</p>
-
-  <p>If vendor-specific markup extensions are needed, they should be
-  done using XML, with elements or attributes from custom
-  namespaces. If such DOM extensions are needed, the members should be
-  prefixed by vendor-specific strings to prevent clashes with future
-  versions of this specification. Extensions must be defined so that
-  the use of extensions neither contradicts nor causes the
-  non-conformance of functionality defined in the specification.</p>
-  <!-- thanks to QA Framework -->
+  <p>If such extensions are nonetheless needed, e.g. for experimental
+  purposes, then vendors are strongly urged to use one of the
+  following extension mechanisms:</p>
+
+  <p>For markup-level features that can be limited to the XML
+  serialization and need not be supported in the HTML serialization,
+  vendors should use the namespace mechanism to define custom
+  namespaces in which the non-standard elements and attributes are
+  supported.</p>
+
+  <p>For markup-level features that are intended for use with
+  <span>the HTML syntax</span>, extensions should be limited to new
+  attributes of the form "<code title="">_<var
+  title="">vendor</var>-<var title="">feature</var></code>", where
+  <var title="">vendor</var> is a short string that identifies the
+  vendor responsible for the extension, and <var
+  title="">feature</var> is the name of the feature. New element names
+  should not be created. Using attributes for such extensions
+  exclusively allows extensions from multiple vendors to co-exist on
+  the same element, which would not be possible with elements. Using
+  the "<code title="">_<var title="">vendor</var>-<var
+  title="">feature</var></code>" form allows extensions to be made
+  without risk of conflicting with future additions to the
+  specification.</p>
+
+  <div class="example">
+
+   <p>For instance, a browser named "FerretBrowser" could use "ferret"
+   as a vendor prefix, while a browser named "Mellblom Browser" could
+   use "mb". If both of these browsers invented extensions that turned
+   elements into scratch-and-sniff areas, an author experimenting with
+   these features could write:</p>
+
+   <pre>&lt;p>This smells of lemons!
+&lt;span -ferret-smellovision -fetter-smellcode="LEM01"
+      -mb-outputsmell -mb-smell="lemon juice">&lt;/span>&lt;/p></pre>
+
+  </div>
+
+  <p>Attribute names starting with a U+005F LOW LINE character (_) are
+  reserved for user agent use and are guaranteed to never be formally
+  added to the HTML language.</p>
+
+  <p class="note">Pages that use such attributes are by definition
+  non-conforming.</p>
+
+  <p>For DOM extensions, e.g. new methods and IDL attributes, the new
+  members should be prefixed by vendor-specific strings to prevent
+  clashes with future versions of this specification.</p>
+
+  <p>All extensions must be defined so that the use of extensions
+  neither contradicts nor causes the non-conformance of functionality
+  defined in the specification.</p> <!-- thanks to QA Framework -->
 
   <div class="example">
 
    <p>For example, while strongly discouraged from doing so, an
    implementation "Foo Browser" could add a new IDL attribute "<code
    title="">fooTypeTime</code>" to a control's DOM interface that
    returned the time it took the user to select the current value of a
    control (say). On the other hand, defining a new control that
    appears in a form's <code title="dom-form-elements">elements</code>
    array would be in violation of the above requirement, as it would
    violate the definition of <code
    title="dom-form-elements">elements</code> given in this
    specification.</p>
 
   </div>
 
-  <p>When support for a feature is disabled (e.g. as an emergency
-  measure to mitigate a security problem, or to aid in development, or
-  for performance reasons), user agents must act as if they had no
-  support for the feature whatsoever, and as if the feature was not
-  mentioned in this specification. For example, if a particular
-  feature is accessed via an attribute in a Web IDL interface, the
-  attribute itself would be omitted from the objects that implement
-  that interface &mdash; leaving the attribute on the object but
-  making it return null or throw an exception is insufficient.</p>
-
   <hr>
 
   <p>When vendor-neutral extensions to this specification are needed,
   either this specification can be updated accordingly, or an
   extension specification can be written that overrides the
   requirements in this specification. When someone applying this
   specification to their activities decides that they will recognize
   the requirements of such an extension specification, it becomes an
   <dfn title="other applicable specifications">applicable
   specification</dfn> for the purposes of conformance requirements in
   this specification.</p>
   <!-- http://www.w3.org/mid/17E341CD-E790-422C-9F9A-69347EE01CEB@iki.fi -->
 
   <hr>
 
   <p>User agents must treat elements and attributes that they do not
   understand as semantically neutral; leaving them in the DOM (for DOM
   processors), and styling them according to CSS (for CSS processors),
   but not inferring any meaning from them.</p>
 
+  <p>When support for a feature is disabled (e.g. as an emergency
+  measure to mitigate a security problem, or to aid in development, or
+  for performance reasons), user agents must act as if they had no
+  support for the feature whatsoever, and as if the feature was not
+  mentioned in this specification. For example, if a particular
+  feature is accessed via an attribute in a Web IDL interface, the
+  attribute itself would be omitted from the objects that implement
+  that interface &mdash; leaving the attribute on the object but
+  making it return null or throw an exception is insufficient.</p>
+
   </div>
 
 
 
   <h3>Case-sensitivity and string comparison</h3>
 
   <p>Comparing two strings in a <dfn>case-sensitive</dfn> manner means
   comparing them exactly, code point for code point.</p>
 
   <p>Comparing two strings in an <dfn>ASCII case-insensitive</dfn>

|