Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
[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 3e2bc64
Show file tree
Hide file tree
Showing 2 changed files with 86 additions and 3 deletions.
45 changes: 43 additions & 2 deletions index
Expand Up @@ -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>
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -36542,7 +36584,6 @@ interface <dfn id=htmloptionelement>HTMLOptionElement</dfn> : <a href=#htmleleme
</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>
Expand Down
44 changes: 43 additions & 1 deletion source
Expand Up @@ -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
Expand Down Expand Up @@ -41106,7 +41149,6 @@ interface <dfn>HTMLOptionElement</dfn> : <span>HTMLElement</span> {
</div>



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

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

0 comments on commit 3e2bc64

Please sign in to comment.