HTML Standard Tracker

Diff (omit for latest revision)
Filter

Short URL: http://html5.org/r/4939

File a bug

SVNBugCommentTime (UTC)
49399239Include some advice on how to do experimental non-standard attributes.2010-04-01 23:20
Index: source
===================================================================
--- source	(revision 4938)
+++ source	(revision 4939)
@@ -2117,27 +2117,124 @@
 
 
 
+  <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 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 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>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
@@ -2151,16 +2248,6 @@
 
   </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,
@@ -2181,6 +2268,16 @@
   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>
 
 

|