- From: poot <cvsmail@w3.org>
- Date: Wed, 29 Apr 2009 10:45:40 +0900 (JST)
- To: public-html-diffs@w3.org
Design notes. (whatwg r3017)
1.8.1 How to read this specification
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#how-to-read-this-specification
5.8.3.2 Writing cache manifests
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#writing-cache-manifests
1.4 History
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#history-0
willful violations
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#willful-violation
1.8 Structure of this specification
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#structure-of-this-specification
misinterpreted for compatibility
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#misinterpreted-for-compatibility
1.7 HTML vs XHTML
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#html-vs-xhtml
<host-specific>
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#url-host-specific
1.5.2 Compliance with other specifications
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#compliance-with-other-specifications
1.6.3 Relationship to XHTML2 and XForms
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#relationship-to-xhtml2-and-xforms
algorithm for extracting an encoding from a Content-Type
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#algorithm-for-extracting-an-encoding-from-a-content-type
2.2.1 Dependencies
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#dependencies
Constructing the form data set. For each element field in controls, in tree order, run the following substeps: If any of the following conditions are met, then skip these substeps for this element: The field element has a datalist element ancestor. The field element is disabled. The field element is a button but it is not submitter. The field element is an input element whose type attribute is in the Checkbox state and whose checkedness is false. The field element is an input element whose type attribute is in the Radio Button state and whose checkedness is false. The field element is an input element whose type attribute is in the File Upload state but the control does not have any files selected. The field element is an object element that is not using a plugin. Otherwise, process field as follows: Let type be the value of the type DOM attribute of field. If the field element is an input element whose type attribute is in the Image Button state, then run these further nested substeps: If the field elementhas an name attribute specified and value is not the empty string, let name be that value followed by a single U+002E FULL STOP (.) character. Otherwise, let name be the empty string. Let namex be the string consisting of the concatenation of name and a single U+0078 LATIN SMALL LETTER X (x) character. Let namey be the string consisting of the concatenation of name and a single U+0079 LATIN SMALL LETTER Y (y) character. The field element is submitter, and before this algorithm was invoked the user indicated a coordinate. Let x be the x-component of the coordinate selected by the user, and let y be the y-component of the coordinate selected by the user. Append an entry in the form data set with the name namex, the value x, and the type type. Append an entry in the form data set with the name namey and the value y, and the type type. Skip the remaining substeps for this element: if there are any more elements in controls, return to the top of the constructing the form data set step, otherwise, jump to the nex step in the overall form submission algorithm. If the field element does not have a name attribute specified, or its name attribute's value is the empty string, skip these substeps for this element: if there are any more elements in controls, return to the top of the constructing the form data set step, otherwise, jump to the next step in the overall form submission algorithm. Let name be the value of the field element's name attribute. If the field element is a select element, then for each option element in the select element whose selectedness is true, append an entry in the form data set with the name as the name, the value of the option element as the value, and type as the type. Otherwise, if the field element is an input element whose type attribute is in the Checkbox state or the Radio Button state, then run these further nested substeps: If the field element has a value attribute specified, then let value be the value of that attribute; otherwise, let value be the string "on". Append an entry in te form data set with name as the name, value as the value, and type as the type. Otherwise, if the field element is an input element whose type attribute is in the File Upload state, then for each file selected in the input element, append an entry in the form data set with the name as the name, the file (consisting of the name, the type, and the body) as the value, and type as the type. Otherwise, if the field element is an object element: try to obtain a form submission value from the plugin, and if that is successful, append an entry in the form data set with name as the name, the returned form submission value as the value, and the string "object" as the type. Otherwise, append an entry in the form data set with name as the name, the value of the field element as the value, and type as the type.
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#constructing-form-data-set
1.8.2 Typographic conventions
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#typographic-conventions
1.5 Design notes
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#design-notes
URL character encoding
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#url-character-encoding
1.6.2 Relationship to XHTML 1.x
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#relationship-to-xhtml-1.x
script's global object
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#script-s-global-object
1.6 Relationships to other specifications
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#relationships-to-other-specifications
1.5.1 Serializability of script execution
http://people.w3.org/mike/diffs/html5/spec/Overview.1.2180.html#serializability-of-script-execution
http://people.w3.org/mike/diffs/html5/spec/Overview.diff.html
http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.2179&r2=1.2180&f=h
http://html5.org/tools/web-apps-tracker?from=3016&to=3017
===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.2179
retrieving revision 1.2180
diff -u -d -r1.2179 -r1.2180
--- Overview.html 29 Apr 2009 00:32:40 -0000 1.2179
+++ Overview.html 29 Apr 2009 01:44:06 -0000 1.2180
@@ -268,16 +268,20 @@
<li><a href="#audience"><span class="secno">1.2 </span>Audience</a></li>
<li><a href="#scope"><span class="secno">1.3 </span>Scope</a></li>
<li><a href="#history-0"><span class="secno">1.4 </span>History</a></li>
- <li><a href="#relationships-to-other-specifications"><span class="secno">1.5 </span>Relationships to other specifications</a>
+ <li><a href="#design-notes"><span class="secno">1.5 </span>Design notes</a>
<ol>
- <li><a href="#relationship-to-html-4.01-and-dom2-html"><span class="secno">1.5.1 </span>Relationship to HTML 4.01 and DOM2 HTML</a></li>
- <li><a href="#relationship-to-xhtml-1.x"><span class="secno">1.5.2 </span>Relationship to XHTML 1.x</a></li>
- <li><a href="#relationship-to-xhtml2-and-xforms"><span class="secno">1.5.3 </span>Relationship to XHTML2 and XForms</a></ol></li>
- <li><a href="#html-vs-xhtml"><span class="secno">1.6 </span>HTML vs XHTML</a></li>
- <li><a href="#structure-of-this-specification"><span class="secno">1.7 </span>Structure of this specification</a>
+ <li><a href="#serializability-of-script-execution"><span class="secno">1.5.1 </span>Serializability of script execution</a></li>
+ <li><a href="#compliance-with-other-specifications"><span class="secno">1.5.2 </span>Compliance with other specifications</a></ol></li>
+ <li><a href="#relationships-to-other-specifications"><span class="secno">1.6 </span>Relationships to other specifications</a>
<ol>
- <li><a href="#how-to-read-this-specification"><span class="secno">1.7.1 </span>How to read this specification</a></li>
- <li><a href="#typographic-conventions"><span class="secno">1.7.2 </span>Typographic conventions</a></ol></ol></li>
+ <li><a href="#relationship-to-html-4.01-and-dom2-html"><span class="secno">1.6.1 </span>Relationship to HTML 4.01 and DOM2 HTML</a></li>
+ <li><a href="#relationship-to-xhtml-1.x"><span class="secno">1.6.2 </span>Relationship to XHTML 1.x</a></li>
+ <li><a href="#relationship-to-xhtml2-and-xforms"><span class="secno">1.6.3 </span>Relationship to XHTML2 and XForms</a></ol></li>
+ <li><a href="#html-vs-xhtml"><span class="secno">1.7 </span>HTML vs XHTML</a></li>
+ <li><a href="#structure-of-this-specification"><span class="secno">1.8 </span>Structure of this specification</a>
+ <ol>
+ <li><a href="#how-to-read-this-specification"><span class="secno">1.8.1 </span>How to read this specification</a></li>
+ <li><a href="#typographic-conventions"><span class="secno">1.8.2 </span>Typographic conventions</a></ol></ol></li>
<li><a href="#infrastructure"><span class="secno">2 </span>Common infrastructure</a>
<ol>
<li><a href="#terminology"><span class="secno">2.1 </span>Terminology</a>
@@ -1163,11 +1167,33 @@
development of the HTML5 specifications. The working group opened in
2007. Apple, Mozilla, and Opera allowed the W3C to publish the
specifications under the W3C copyright, while keeping versions with
- the less restrictive license on the WHATWG site.<p>Since then, both groups have been working together.<h3 id="relationships-to-other-specifications"><span class="secno">1.5 </span>Relationships to other specifications</h3><h4 id="relationship-to-html-4.01-and-dom2-html"><span class="secno">1.5.1 </span>Relationship to HTML 4.01 and DOM2 HTML</h4><p><em>This section is non-normative.</em><p>This specification represents a new version of HTML4, along with
+ the less restrictive license on the WHATWG site.<p>Since then, both groups have been working together.<h3 id="design-notes"><span class="secno">1.5 </span>Design notes</h3><p><em>This section is non-normative.</em><p>It must be admitted that many aspects of HTML appear at first
+ glance to be nonsensical and inconsistent.<p>HTML, its supporting DOM APIs, as well as many of its supporting
+ technologies, have been developed over a period of several decades
+ by a wide array of people with different priorities who, in many
+ cases, did not know of each other's existence.<p>Features have thus arisen from many sources, and have not always
+ been designed in especially consistent ways. Furthermore, because of
+ the unique characteristics of the Web, implementation bugs have
+ often become de-facto, and now de-jure, standards, as content is
+ often unintentionally written in ways that rely on them before they
+ can be fixed.<p>Despite all this, efforts have been made to adhere to certain
+ design goals. These are described in the next few subsections.<h4 id="serializability-of-script-execution"><span class="secno">1.5.1 </span>Serializability of script execution</h4><p><em>This section is non-normative.</em><p>To avoid exposing Web authors to the complexities of
+ multithreading, the HTML and DOM APIs are designed such that no
+ script can ever detect the simultaneous execution of other
+ scripts. Even with <span title="Worker">workers</span>, the intent
+ is that the behavior of implementations can be thought of as
+ completely serialising the execution of all scripts in all <a href="#browsing-context" title="browsing context">browsing contexts</a>.<p class="note">The <code title="dom-navigator-GetStorageUpdates"><a href="#dom-navigator-getstorageupdates">navigator.getStorageUpdates()</a></code>
+ method, in this model, is equivalent to allowing other scripts to
+ run while the calling script is blocked.<h4 id="compliance-with-other-specifications"><span class="secno">1.5.2 </span>Compliance with other specifications</h4><p><em>This section is non-normative.</em><p>HTML5 interacts with and relies on a wide variety of other
+ specifications. In certain circumstances, unfortunately, the desire
+ to be compatible with legacy content has led to HTML5 violating the
+ requirements of these other specifications. Whenever this has
+ occured, the transgressions have been noted as "<dfn id="willful-violation" title="willful
+ violation">willful violations</dfn>".<h3 id="relationships-to-other-specifications"><span class="secno">1.6 </span>Relationships to other specifications</h3><h4 id="relationship-to-html-4.01-and-dom2-html"><span class="secno">1.6.1 </span>Relationship to HTML 4.01 and DOM2 HTML</h4><p><em>This section is non-normative.</em><p>This specification represents a new version of HTML4, along with
a new version of the associated DOM2 HTML API. Migration from HTML4
to the format and APIs described in this specification should in
most cases be straightforward, as care has been taken to ensure that
- backwards-compatibility is retained. <a href="#references">[HTML4]</a> <a href="#references">[DOM2HTML]</a><h4 id="relationship-to-xhtml-1.x"><span class="secno">1.5.2 </span>Relationship to XHTML 1.x</h4><p><em>This section is non-normative.</em><p>This specification is intended to replace XHTML 1.0 as the
+ backwards-compatibility is retained. <a href="#references">[HTML4]</a> <a href="#references">[DOM2HTML]</a><h4 id="relationship-to-xhtml-1.x"><span class="secno">1.6.2 </span>Relationship to XHTML 1.x</h4><p><em>This section is non-normative.</em><p>This specification is intended to replace XHTML 1.0 as the
normative definition of the XML serialization of the HTML
vocabulary. <a href="#references">[XHTML10]</a><p>While this specification updates the semantics and requirements
of the vocabulary defined by XHTML Modularization 1.1 and used by
@@ -1177,7 +1203,7 @@
replacement for them. <a href="#references">[XHTMLMOD]</a> <a href="#references">[XHTML11]</a><p>Thus, authors and implementors who do not need such a
modularization scheme can consider this specification a replacement
for XHTML 1.x, but those who do need such a mechanism are encouraged
- to continue using the XHTML 1.1 line of specifications.<h4 id="relationship-to-xhtml2-and-xforms"><span class="secno">1.5.3 </span>Relationship to XHTML2 and XForms</h4><p><em>This section is non-normative.</em><p>XHTML2 defines a new vocabulary with features for hyperlinks,
+ to continue using the XHTML 1.1 line of specifications.<h4 id="relationship-to-xhtml2-and-xforms"><span class="secno">1.6.3 </span>Relationship to XHTML2 and XForms</h4><p><em>This section is non-normative.</em><p>XHTML2 defines a new vocabulary with features for hyperlinks,
multimedia content, annotating document edits, rich metadata,
declarative interactive forms, and describing the semantics of human
literary works such as poems and scientific papers. <a href="#references">[XHTML2]</a><p>XForms similarly defines a new vocabulary with features for
@@ -1189,7 +1215,7 @@
strategy games, and the like.<p><em>This</em> specification aims to extend HTML so that it is
also suitable in these contexts.<p>XHTML2, XForms, and this specification all use different
namespaces and therefore can all be implemented in the same XML
- processor.<h3 id="html-vs-xhtml"><span class="secno">1.6 </span>HTML vs XHTML</h3><p><em>This section is non-normative.</em><p>This specification defines an abstract language for describing
+ processor.<h3 id="html-vs-xhtml"><span class="secno">1.7 </span>HTML vs XHTML</h3><p><em>This section is non-normative.</em><p>This specification defines an abstract language for describing
documents and applications, and some APIs for interacting with
in-memory representations of resources that use this language.<p>The in-memory representation is known as "DOM5 HTML", or "the
DOM" for short.<p>There are various concrete syntaxes that can be used to transmit
@@ -1211,7 +1237,7 @@
feature can be represented using "HTML5", but cannot be represented
with "XHTML5" and "DOM5 HTML". Comments that contain the string
"<code title="">--></code>" can be represented in "DOM5 HTML" but
- not in "HTML5" and "XHTML5". And so forth.<h3 id="structure-of-this-specification"><span class="secno">1.7 </span>Structure of this specification</h3><p><em>This section is non-normative.</em><p>This specification is divided into the following major
+ not in "HTML5" and "XHTML5". And so forth.<h3 id="structure-of-this-specification"><span class="secno">1.8 </span>Structure of this specification</h3><p><em>This section is non-normative.</em><p>This specification is divided into the following major
sections:<dl><dt><a href="#infrastructure">Common Infrastructure</a></dt>
<dd>The conformance classes, algorithms, definitions, and the
@@ -1265,11 +1291,11 @@
</dl><p>There are also a couple of appendices, defining <a href="#rendering">rendering rules</a> for Web browsers and listing
<a href="#no">areas that are out of scope</a> for this
- specification.<h4 id="how-to-read-this-specification"><span class="secno">1.7.1 </span>How to read this specification</h4><p>This specification should be read like all other specifications.
+ specification.<h4 id="how-to-read-this-specification"><span class="secno">1.8.1 </span>How to read this specification</h4><p>This specification should be read like all other specifications.
First, it should be read cover-to-cover, multiple times. Then, it
should be read backwards at least once. Then it should be read by
picking random sections from the contents list and following all the
- cross-references.<h4 id="typographic-conventions"><span class="secno">1.7.2 </span>Typographic conventions</h4><p>This is a definition, requirement, or explanation.<p class="note">This is a note.<p class="example">This is an example.<p class="XXX">This is an open issue.<p class="warning">This is a warning.<pre class="idl">interface <dfn title="">Example</dfn> {
+ cross-references.<h4 id="typographic-conventions"><span class="secno">1.8.2 </span>Typographic conventions</h4><p>This is a definition, requirement, or explanation.<p class="note">This is a note.<p class="example">This is an example.<p class="XXX">This is an open issue.<p class="warning">This is a warning.<pre class="idl">interface <dfn title="">Example</dfn> {
// this is an IDL definition
};</pre><dl class="domintro"><dt><var title="">variable</var> = <var title="">object</var> . <code title="">method</code>( [ <var title="">optionalArgument</var> ] )</dt>
@@ -1707,8 +1733,8 @@
rather than the official term ECMAScript, since the term
JavaScript is more widely known. Similarly, the MIME type used to
refer to JavaScript in this specification is <code title="">text/javascript</code>, since that is the most commonly
- used type, despite it being an officially obsoleted type according
- to RFC 4329. <!--willful violation--> <a href="#references">[RFC4329]</a></p>
+ used type, <a href="#willful-violation" title="willful violation">despite it being an
+ officially obsoleted type</a> according to RFC 4329. <a href="#references">[RFC4329]</a></p>
</dd>
@@ -3845,8 +3871,8 @@
manner distinct from the precise technical meaning it is given in
RFC 3986. Readers familiar with that RFC will find it easier to read
<em>this</em> specification if they pretend the term "URL" as used
- herein is really called something else altogether. This is a willful
- violation of RFC 3986. <a href="#references">RFC3986</a></p>
+ herein is really called something else altogether. This is a <a href="#willful-violation">willful
+ violation</a> of RFC 3986. <a href="#references">RFC3986</a></p>
</div><div class="impl">
@@ -3972,7 +3998,7 @@
</ol><!-- XXX we might want to define "server-based naming authority",
it's not clear RFC3986 does a good job of defining that anymore
- (earlier URI specs did) --><p class="note">These parsing rules are a willful violation of RFC
+ (earlier URI specs did) --><p class="note">These parsing rules are a <a href="#willful-violation">willful violation</a> of RFC
3986 and RFC 3987 to handle legacy content. <a href="#references">RFC3986</a> <a href="#references">RFC3987</a></p>
</div><div class="impl">
@@ -4645,7 +4671,7 @@
</dl></li>
- </ol><p class="note">The above algorithm is a willful violation of the
+ </ol><p class="note">The above algorithm is a <a href="#willful-violation">willful violation</a> of the
HTTP specification. <a href="#references">[HTTP]</a></p>
@@ -5240,7 +5266,7 @@
<tr><td> x-x-big5 <td> Big5 <td>
<a href="#references">[BIG5]</a> <!-- XXX ? -->
</table><p class="note">The requirement to treat certain encodings as other
- encodings according to the table above is a willful violation of the
+ encodings according to the table above is a <a href="#willful-violation">willful violation</a> of the
W3C Character Model specification. <a href="#references">[CHARMOD]</a></p>
<hr><p>User agents must not support the CESU-8, UTF-7, BOCU-1 and SCSU
@@ -31273,7 +31299,7 @@
<p>If <var title="">action</var> is the empty string, let <var title="">action</var> be <a href="#the-document-s-address">the document's address</a>.</p>
- <p class="note">This step is a willful violation of RFC 3986. <a href="#references">[RFC3986]</a></p>
+ <p class="note">This step is a <a href="#willful-violation">willful violation</a> of RFC 3986. <a href="#references">[RFC3986]</a></p>
<!-- Don't ask me why. But that's what IE does. It even treats
action="" differently from action=" " or action="#" (the latter
@@ -37066,7 +37092,7 @@
<code><a href="#window">Window</a></code> object, then in JavaScript, the <code title="">this</code> keyword in the global scope must return the
<code><a href="#window">Window</a></code> object's <code><a href="#windowproxy">WindowProxy</a></code> object.</p>
- <p class="note">This is a willful violation of the JavaScript
+ <p class="note">This is a <a href="#willful-violation">willful violation</a> of the JavaScript
specification current at the time of writing (ECMAScript edition
3). <a href="#references">[ECMA262]</a></p>
@@ -38930,7 +38956,8 @@
encoded using UTF-8. Data in application cache manifests is
line-based. Newlines must be represented by U+000A LINE FEED (LF)
characters, U+000D CARRIAGE RETURN (CR) characters, or U+000D
- CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs.<p class="note">This is a willful double violation of RFC2046. <a href="#references">[RFC2046]</a><p>The first line of an application cache manifest must consist of
+ CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs.<p class="note">This is a <a href="#willful-violation" title="willful violation">willful
+ double violation</a> of RFC2046. <a href="#references">[RFC2046]</a><p>The first line of an application cache manifest must consist of
the string "CACHE", a single U+0020 SPACE character, the string
"MANIFEST", and either a U+0020 SPACE character, a U+0009 CHARACTER
TABULATION (tab) character, a U+000A LINE FEED (LF) character, or a
Received on Wednesday, 29 April 2009 01:46:18 UTC