Skip to content
Permalink
Browse files

[e] (0) Drop in some 'Extensibility' text from WF2.

git-svn-id: http://svn.whatwg.org/webapps@3120 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information...
Hixie committed May 24, 2009
1 parent d557cbe commit 3e2bc64a6931e9fff417cd7f796c4c3693a23c95
Showing with 86 additions and 3 deletions.
  1. +43 −2 index
  2. +43 −1 source
45 index
@@ -236,7 +236,8 @@
<li><a href=#dependencies><span class=secno>2.2.1 </span>Dependencies</a></li>
<li><a href=#features-defined-in-other-specifications><span class=secno>2.2.2 </span>Features defined in other specifications</a></li>
<li><a href=#common-conformance-requirements-for-apis-exposed-to-javascript><span class=secno>2.2.3 </span>Common conformance requirements for APIs exposed to
JavaScript</a></ol></li>
JavaScript</a></li>
<li><a href=#extensibility><span class=secno>2.2.4 </span>Extensibility</a></ol></li>
<li><a href=#case-sensitivity-and-string-comparison><span class=secno>2.3 </span>Case-sensitivity and string comparison</a></li>
<li><a href=#common-microsyntaxes><span class=secno>2.4 </span>Common microsyntaxes</a>
<ol>
@@ -2087,6 +2088,47 @@
</div>


<div class=impl>

<h4 id=extensibility><span class=secno>2.2.4 </span>Extensibility</h4>

<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 markup extensions are needed, they should be done using XML,
with elements or attributes from custom namespaces. If 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 does not contradict nor cause the non-conformance of
functionality defined in the specification.</p> <!-- thanks to QA
Framework -->

<div class=example>

<p>For example, while strongly discouraged to do so, an
implementation "Foo Browser" could add a new DOM 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><a href=#dom-form-elements>elements</a></code>
array would be in violation of the above requirement, as it would
violate the definition of <code title=dom-form-elements><a href=#dom-form-elements>elements</a></code> given in this
specification.</p>

</div>

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

</div>



<h3 id=case-sensitivity-and-string-comparison><span class=secno>2.3 </span>Case-sensitivity and string comparison</h3>

<p>This specification defines several comparison operators for
</ol></div>



<h3 id=interactive-elements><span class=secno>4.11 </span>Interactive elements</h3>

<h4 id=the-details-element><span class=secno>4.11.1 </span>The <dfn><code>details</code></dfn> element</h4>
44 source
@@ -1086,6 +1086,49 @@
</div>


<div class="impl">

<h4>Extensibility</h4>

<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 markup extensions are needed, they should be done using XML,
with elements or attributes from custom namespaces. If 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 does not contradict nor cause the non-conformance of
functionality defined in the specification.</p> <!-- thanks to QA
Framework -->

<div class="example">

<p>For example, while strongly discouraged to do so, an
implementation "Foo Browser" could add a new DOM 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>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>

</div>



<h3>Case-sensitivity and string comparison</h3>

<p>This specification defines several comparison operators for
</div>



<h3 id="interactive-elements">Interactive elements</h3>

<h4>The <dfn><code>details</code></dfn> element</h4>

0 comments on commit 3e2bc64

Please sign in to comment.
You can’t perform that action at this time.