Skip to content

Commit

Permalink
[e] (0) Add a history section.
Browse files Browse the repository at this point in the history 
git-svn-id: http://svn.whatwg.org/webapps@2077 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
@Hixie
Hixie committed Aug 18, 2008
1 parent 3600068 commit 7359db9
Show file tree
Hide file tree
Showing 2 changed files with 110 additions and 41 deletions.
116 changes: 75 additions & 41 deletions index
View file
Original file line number Diff line number Diff line change
Expand Up @@ -244,35 +244,37 @@

<li><a href="#scope"><span class=secno>1.2 </span>Scope</a>

<li><a href="#relationships"><span class=secno>1.3 </span>Relationships
<li><a href="#history0"><span class=secno>1.3 </span>History</a>

<li><a href="#relationships"><span class=secno>1.4 </span>Relationships
to other specifications</a>
<ul class=toc>
<li><a href="#relationship"><span class=secno>1.3.1
<li><a href="#relationship"><span class=secno>1.4.1
</span>Relationship to HTML 4.01 and DOM2 HTML</a>

<li><a href="#relationship0"><span class=secno>1.3.2
<li><a href="#relationship0"><span class=secno>1.4.2
</span>Relationship to XHTML 1.x</a>

<li><a href="#relationship1"><span class=secno>1.3.3
<li><a href="#relationship1"><span class=secno>1.4.3
</span>Relationship to XHTML2</a>

<li><a href="#relationship2"><span class=secno>1.3.4
<li><a href="#relationship2"><span class=secno>1.4.4
</span>Relationship to Web Forms 2.0 and XForms</a>

<li><a href="#relationship3"><span class=secno>1.3.5
<li><a href="#relationship3"><span class=secno>1.4.5
</span>Relationship to XUL, Flash, Silverlight, and other proprietary
UI languages</a>
</ul>

<li><a href="#html-vs"><span class=secno>1.4 </span>HTML vs XHTML</a>
<li><a href="#html-vs"><span class=secno>1.5 </span>HTML vs XHTML</a>

<li><a href="#structure"><span class=secno>1.5 </span>Structure of this
<li><a href="#structure"><span class=secno>1.6 </span>Structure of this
specification</a>
<ul class=toc>
<li><a href="#how-to"><span class=secno>1.5.1 </span>How to read this
<li><a href="#how-to"><span class=secno>1.6.1 </span>How to read this
specification</a>

<li><a href="#typographic"><span class=secno>1.5.2 </span>Typographic
<li><a href="#typographic"><span class=secno>1.6.2 </span>Typographic
conventions</a>
</ul>
</ul>
Expand Down Expand Up @@ -1415,7 +1417,7 @@
<li><a href="#scroll-to-fragid"><span class=secno>5.9.8
</span>Navigating to a fragment identifier</a>

<li><a href="#history0"><span class=secno>5.9.9 </span>History
<li><a href="#history1"><span class=secno>5.9.9 </span>History
traversal</a>

<li><a href="#closing"><span class=secno>5.9.10 </span>Closing a
Expand Down Expand Up @@ -2230,10 +2232,42 @@
solutions for such sophisticated applications (for example the Mac OS X
Core APIs) are even further ahead.

<h3 id=relationships><span class=secno>1.3 </span>Relationships to other
<h3 id=history0><span class=secno>1.3 </span>History</h3>

<p>Work on HTML5 originally started in late 2003, as a proof of concept to
show that it was possible to extend HTML4's forms to provide many of the
features that XForms 1.0 introduced, without requiring browsers to
implementing rendering engines that were incompatible with existing HTML
Web pages. At this early stage, while the draft was already publicly
available, and input was already being solicited from all sources, the
specification was only under Opera Software's copyright.

<p>In early 2004, some of the principles that underly this effort, as well
as an early draft proposal covering just forms-related features, were
presented to the W3C jointly by Mozilla and Opera at a workshop discussing
the future of Web Applications on the Web. The proposal was rejected on
the grounds that the proposal conflicted with the previously chosen
direction for the Web's evolution.

<p>Shortly thereafter, Apple, Mozilla, and Opera jointly announced their
intent to continue working on the effort. A public mailing list was
created, and the drafts were moved to the WHATWG site. The copyright was
subsequently amended to be jointly owned by all three vendors, and to
allow reuse of the specifications.

<p>In 2006, the W3C expressed interest in the specification, and created a
working group chartered to work with the WHATWG on the 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><span class=secno>1.4 </span>Relationships to other
specifications</h3>

<h4 id=relationship><span class=secno>1.3.1 </span>Relationship to HTML
<h4 id=relationship><span class=secno>1.4.1 </span>Relationship to HTML
4.01 and DOM2 HTML</h4>

<p><em>This section is non-normative.</em>
Expand All @@ -2245,7 +2279,7 @@
backwards-compatibility is retained. <a href="#refsHTML4">[HTML4]</a> <a
href="#refsDOM2HTML">[DOM2HTML]</a>

<h4 id=relationship0><span class=secno>1.3.2 </span>Relationship to XHTML
<h4 id=relationship0><span class=secno>1.4.2 </span>Relationship to XHTML
1.x</h4>

<p><em>This section is non-normative.</em>
Expand All @@ -2266,7 +2300,7 @@
those who do need such a mechanism are encouraged to continue using the
XHTML 1.1 line of specifications.

<h4 id=relationship1><span class=secno>1.3.3 </span>Relationship to XHTML2</h4>
<h4 id=relationship1><span class=secno>1.4.3 </span>Relationship to XHTML2</h4>

<p><em>This section is non-normative.</em>

Expand All @@ -2287,7 +2321,7 @@
<p>XHTML2 and this specification use different namespaces and therefore can
both be implemented in the same XML processor.

<h4 id=relationship2><span class=secno>1.3.4 </span>Relationship to Web
<h4 id=relationship2><span class=secno>1.4.4 </span>Relationship to Web
Forms 2.0 and XForms</h4>

<p><em>This section is non-normative.</em>
Expand All @@ -2303,7 +2337,7 @@
in the Web Forms 2.0 draft will apply to this specification. <a
href="#refsXForms">[XForms]</a>

<h4 id=relationship3><span class=secno>1.3.5 </span>Relationship to XUL,
<h4 id=relationship3><span class=secno>1.4.5 </span>Relationship to XUL,
Flash, Silverlight, and other proprietary UI languages</h4>

<p><em>This section is non-normative.</em>
Expand All @@ -2313,7 +2347,7 @@
language, HTML provides for a solution to the same problems without the
risk of vendor lock-in.

<h3 id=html-vs><span class=secno>1.4 </span>HTML vs XHTML</h3>
<h3 id=html-vs><span class=secno>1.5 </span>HTML vs XHTML</h3>

<p><em>This section is non-normative.</em>

Expand Down Expand Up @@ -2351,7 +2385,7 @@
that contain the string "<code title="">--&gt;</code>" can be represented
in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth.

<h3 id=structure><span class=secno>1.5 </span>Structure of this
<h3 id=structure><span class=secno>1.6 </span>Structure of this
specification</h3>

<p><em>This section is non-normative.</em>
Expand Down Expand Up @@ -2410,14 +2444,14 @@
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><span class=secno>1.5.1 </span>How to read this specification</h4>
<h4 id=how-to><span class=secno>1.6.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><span class=secno>1.5.2 </span>Typographic conventions</h4>
<h4 id=typographic><span class=secno>1.6.2 </span>Typographic conventions</h4>

<p>This is a definition, requirement, or explanation.

Expand Down Expand Up @@ -8946,7 +8980,7 @@ http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20HTML%3E%0
<li>Remove all the entries in the <a href="#browsing1">browsing
context</a>'s <a href="#session">session history</a> after the <a
href="#current1">current entry</a> in its <code>Document</code>'s
<code><a href="#history2">History</a></code> object
<code><a href="#history3">History</a></code> object

<li>Remove any earlier entries that share the same <code>Document</code>

Expand Down Expand Up @@ -31967,7 +32001,7 @@ never reset. This is nice and consistent.)
readonly attribute <a href="#window">Window</a> <a href="#self" title=dom-self>self</a>;
attribute DOMString <a href="#name9" title=dom-name>name</a>;
[PutForwards=href] readonly attribute <a href="#location2">Location</a> <a href="#location0" title=dom-document-location>location</a>;
readonly attribute <a href="#history2">History</a> <a href="#history1" title=dom-history>history</a>;
readonly attribute <a href="#history3">History</a> <a href="#history2" title=dom-history>history</a>;
readonly attribute <a href="#undomanager">UndoManager</a> <a href="#undomanager0" title=dom-undoManager>undoManager</a>;
<a href="#selection1">Selection</a> <a href="#getselection" title=dom-getSelection>getSelection</a>();

Expand Down Expand Up @@ -35849,24 +35883,24 @@ style/default.css</pre>
href="#browsing1">browsing context</a> is its <dfn id=session>session
history</dfn>.

<p><code><a href="#history2">History</a></code> objects provide a
<p><code><a href="#history3">History</a></code> objects provide a
representation of the pages in the session history of <a href="#browsing1"
title="browsing context">browsing contexts</a>. Each browsing context has
a distinct session history.

<p>Each <code>Document</code> object in a browsing context's session
history is associated with a unique instance of the <code><a
href="#history2">History</a></code> object, although they all must model
href="#history3">History</a></code> object, although they all must model
the same underlying session history.

<p>The <dfn id=history1 title=dom-history><code>history</code></dfn>
<p>The <dfn id=history2 title=dom-history><code>history</code></dfn>
attribute of the <code><a href="#window">Window</a></code> interface must
return the object implementing the <code><a
href="#history2">History</a></code> interface for that <code><a
href="#history3">History</a></code> interface for that <code><a
href="#window">Window</a></code> object's <a href="#active">active
document</a>.

<p><code><a href="#history2">History</a></code> objects represent their <a
<p><code><a href="#history3">History</a></code> objects represent their <a
href="#browsing1">browsing context</a>'s session history as a flat list of
<a href="#session0" title="session history entry">session history
entries</a>. Each <dfn id=session0>session history entry</dfn> consists of
Expand Down Expand Up @@ -35949,9 +35983,9 @@ style/default.css</pre>
object then no entries are removed.

<h4 id=the-history><span class=secno>5.8.2 </span>The <code><a
href="#history2">History</a></code> interface</h4>
href="#history3">History</a></code> interface</h4>

<pre class=idl>interface <dfn id=history2>History</dfn> {
<pre class=idl>interface <dfn id=history3>History</dfn> {
readonly attribute long <a href="#length9" title=dom-history-length>length</a>;
void <a href="#godelta" title=dom-history-go>go</a>(in long delta);
void <a href="#go" title=dom-history-go-0>go</a>();
Expand All @@ -35963,7 +35997,7 @@ style/default.css</pre>
};</pre>

<p>The <dfn id=length9 title=dom-history-length><code>length</code></dfn>
attribute of the <code><a href="#history2">History</a></code> interface
attribute of the <code><a href="#history3">History</a></code> interface
must return the number of entries in this <a href="#session">session
history</a>.

Expand Down Expand Up @@ -35996,7 +36030,7 @@ style/default.css</pre>
title=dom-window><a href="#window0">window</a></code> objects.

<p>Some of the other members of the <code><a
href="#history2">History</a></code> interface are defined in terms of the
href="#history3">History</a></code> interface are defined in terms of the
<code title=dom-history-go><a href="#godelta">go()</a></code> method, as
follows:

Expand Down Expand Up @@ -36191,7 +36225,7 @@ style/default.css</pre>
address</span>, and allow the <a href="#current1">current entry</a> of the
<a href="#browsing1">browsing context</a>'s session history to be changed,
by adding or replacing entries in the <code title=dom-history><a
href="#history1">history</a></code> object.
href="#history2">history</a></code> object.

<pre class=idl>interface <dfn id=location2>Location</dfn> {
readonly attribute DOMString <a href="#href5" title=dom-location-href>href</a>;
Expand Down Expand Up @@ -36314,21 +36348,21 @@ user reload must be equivalent to .reload()

<p><em>This section is non-normative.</em>

<p>The <code><a href="#history2">History</a></code> interface is not meant
<p>The <code><a href="#history3">History</a></code> interface is not meant
to place restrictions on how implementations represent the session history
to the user.

<p>For example, session history could be implemented in a tree-like manner,
with each page having multiple "forward" pages. This specification doesn't
define how the linear list of pages in the <code title=dom-history><a
href="#history1">history</a></code> object are derived from the actual
href="#history2">history</a></code> object are derived from the actual
session history as seen from the user's perspective.

<p>Similarly, a page containing two <code><a
href="#iframe">iframe</a></code>s has a <code title=dom-history><a
href="#history1">history</a></code> object distinct from the <code><a
href="#history2">history</a></code> object distinct from the <code><a
href="#iframe">iframe</a></code>s' <code title=dom-history><a
href="#history1">history</a></code> objects, despite the fact that typical
href="#history2">history</a></code> objects, despite the fact that typical
Web browsers present the user with just one "Back" button, with a session
history that interleaves the navigation of the two inner frames and the
outer page.
Expand Down Expand Up @@ -36668,15 +36702,15 @@ user reload must be equivalent to .reload()
<p>Remove all the entries after the <a href="#current1">current
entry</a> in the <a href="#browsing1">browsing context</a>'s
<code>Document</code> object's <code><a
href="#history2">History</a></code> object.</p>
href="#history3">History</a></code> object.</p>

<p class=note>This <a href="#history-notes">doesn't necessarily have
to affect</a><!--XXX change to auto-xref?--> the user agent's user
interface.</p>

<li>
<p>Append a new entry at the end of the <code><a
href="#history2">History</a></code> object representing the new
href="#history3">History</a></code> object representing the new
resource and its <code>Document</code> object and related state.

<li>
Expand Down Expand Up @@ -37000,7 +37034,7 @@ user reload must be equivalent to .reload()
an element; otherwise there is no <i>target element</i>. <a
href="#refsSELECTORS">[SELECTORS]</a>

<h4 id=history0><span class=secno>5.9.9 </span>History traversal</h4>
<h4 id=history1><span class=secno>5.9.9 </span>History traversal</h4>

<p>When a user agent is required to <dfn id=traverse>traverse the
history</dfn> to a <i>specified entry</i>, the user agent must act as
Expand All @@ -37021,7 +37055,7 @@ user reload must be equivalent to .reload()
<li>
<p>If appropriate, update the <a href="#current1">current entry</a> in
the <a href="#browsing1">browsing context</a>'s <code>Document</code>
object's <code><a href="#history2">History</a></code> object to reflect
object's <code><a href="#history3">History</a></code> object to reflect
any state that the user agent wishes to persist.</p>

<p class=example>For example, some user agents might want to persist the
Expand Down
35 changes: 35 additions & 0 deletions source
View file
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,41 @@
ahead.</p>


<h3>History</h3>

<p>Work on HTML5 originally started in late 2003, as a proof of
concept to show that it was possible to extend HTML4's forms to
provide many of the features that XForms 1.0 introduced, without
requiring browsers to implementing rendering engines that were
incompatible with existing HTML Web pages. At this early stage,
while the draft was already publicly available, and input was
already being solicited from all sources, the specification was
only under Opera Software's copyright.</p>

<p>In early 2004, some of the principles that underly this effort,
as well as an early draft proposal covering just forms-related
features, were presented to the W3C jointly by Mozilla and Opera at
a workshop discussing the future of Web Applications on the Web. The
proposal was rejected on the grounds that the proposal conflicted
with the previously chosen direction for the Web's evolution.</p>

<p>Shortly thereafter, Apple, Mozilla, and Opera jointly announced
their intent to continue working on the effort. A public mailing
list was created, and the drafts were moved to the WHATWG site. The
copyright was subsequently amended to be jointly owned by all three
vendors, and to allow reuse of the specifications.</p>

<p>In 2006, the W3C expressed interest in the specification, and
created a working group chartered to work with the WHATWG on the
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>

<p>Since then, both groups have been working together.</p>



<h3>Relationships to other specifications</h3>

<h4>Relationship to HTML 4.01 and DOM2 HTML</h4>
Expand Down

0 comments on commit 7359db9

Please sign in to comment.