WHATWG Wiki - User contributions [en]

Testsuite

2016-01-18T17:33:26Z

Jgraham: Update testsuite page.

Tests for WHATWG specifications are maintained in the [http://github.com/w3c/web-platform-tests web-platform-tests] repository, along with those for many other web-platform features, including all those maintained by W3C (except, for historical reasons, CSS).

Tests are contributed by community members, including implementers. In general specification editors are not responsible for maintaining tests along with the specification, due to the excess burden of work this would create. Therefore different specifications are accompanied by testsuites of varying breadth and depth.

In order to contribute tests to the testsuite for a WHATWG specification, follow the instructions on [http://testthewebforward.org/docs/ Test the Web Forward].

== Old lists of tests that maybe have not been ported to web platform tests? ==

People should prune this list...

* [[Test cases]]
* [http://www.whatwg.org/html5 The specification] has links to test in the status boxes.
* [http://samples.msdn.microsoft.com/ietestcenter/ IE's tests]
* [http://trac.webkit.org/browser/trunk/LayoutTests (Some of?) WebKit's tests]
* [http://mxr.mozilla.org/mozilla-central/find?string=test_.*%28html|svg%29%24&tree=mozilla-central&hint= Some of Mozilla's mochitests]
** [[Testsuite/Mozilla]]
* [http://mxr.mozilla.org/mozilla-central/find?string=reftest.list Some of Mozilla's reftests]
* [http://philip.html5.org/tests/canvas/suite/tests/ Philip's canvas tests]
* [http://hixie.ch/tests/adhoc/html/ Hixie's ad-hoc tests]
* [http://lachy.id.au/dev/markup/tests/html5/ Lachlan's tests]
* [http://hg.gsnedders.com/php-html-5-direct/file/tip/tests/numbersTest gsnedders' number parsing tests]
* [http://simon.html5.org/test/html/ zcorpan's tests]
* [http://mathias.html5.org/tests/ Mathias’s tests]
* [http://hsivonen.iki.fi/test/moz/video-selection/ hsivonen's video tests]
* [http://www.w3.org/DOM/Test/ Document Object Model (DOM) Conformance Test Suites]
* [http://dev.w3.org/2006/webapi/WindowTestSuite/ Window test suite]

Forking

2011-05-02T08:58:34Z

Jgraham:

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]]. For our purposes, forking means the ability for a third party to redistribute modified versions of the specification without the permission of the copyright holders. Standard licenses that permit forking include [http://creativecommons.org/choose/zero/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

More specifically, this page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]
* [http://html4all.org/HTMLDraft.html HTML 4.1]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Modularization ==

[http://www.w3.org/TR/xhtml-modularization/ XHTML Modularization] has the goal of "providing a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms". Although this is not technically a fork (in the sense that it does not imply taking the W3C spec text and rewriting portions of it), the ability to create new HTML-derived specs that add or replace functionality carries many of the same risks that are brought up in the context of forking.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government would not be bound by copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (c.f. China).
** Whether the W3C allows forking or not, and even if we grant that a license could stop this, this scenario could already happen because the entire HTML spec is already under a liberal license at the WHATWG.

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Forking

2011-05-02T08:49:26Z

Jgraham: /* Other forks */

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]]. For our purposes, forking means the ability for a third party to redistribute modified versions of the specification without the permission of the copyright holders. Standard licenses that permit forking include [http://creativecommons.org/choose/zero/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

More specifically, this page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]
* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]
* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]
* [http://html4all.org/HTMLDraft.html HTML 4.1]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government would not be bound by copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (c.f. China).
** Whether the W3C allows forking or not, and even if we grant that a license could stop this, this scenario could already happen because the entire HTML spec is already under a liberal license at the WHATWG.

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Testsuite/Requirements

2011-02-15T08:20:05Z

Jgraham: Created page with '= HTML Testsuite Requirements = == Improved Test Runner == The current test runner is optimised mainly for manual tests. An in-browser test runner that deals automatically with...'

= HTML Testsuite Requirements =

== Improved Test Runner ==

The current test runner is optimised mainly for manual tests. An in-browser test runner that deals automatically with the results of javascript tests is essential. It should also deal with self-describing reftests and manual tests in a sane way.

=== Requirements ===

* Produces a machine-readable report in some format (could be current XML or some other possibly non-XML format).

* Loads tests automatically based on test manifest files containing metadata about test uri, type, etc.

* Allows all or a subset of tests to be run

* Hooks into testharness to extract the results of the javascript tests without human intervention

* Allows reftests to be run by humans e.g. by allowing user to flick between test view and ref view to spot differences (automatic running of reftests will require browser-specific code and is explicitly out of scope)

* Allows manual tests to be run by humans

=== Possible considerations ===

* Tests that require a top level browsing context

== Annotation of Spec ==

In order to know which areas of the spec are well tested and hence have a sense for (an upper bound on) the completeness of the testsuite as well as the areas where it would be most profitable to direct new testing effort, it would be beneficial to produce an annotated version of the spec documenting tests that cover given requirements.

== Requirements ==

* Map each test onto a piece of spec

* Fine grained definition of "piece"; some sections are long and contain many normative requirements so paragraph-level is probably the minimum useful level

* Good behaviour in the face of spec modifications, deletions, insertions and rearragements.

ParserIssues

2010-06-11T08:08:00Z

Jgraham:

== Filed bugs ==

* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659 Initial U+0000 should not set frameset-ok to "not ok"
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 Steps for handling end tags in the "in foreign" mode get stuck in an infinite loop
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581 Steps for handling end tags in the "in foreign" mode may compare the name of an already-popped node
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <nowiki><p></nowiki>
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843 <nowiki>Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines</nowiki>
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9910 <nowiki><basefont> and <bgsound> should not break out of 'in head', should be treated as a void elements within <head></nowiki>

== Possible other issues ==

* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?
* To enable the parser to decide whether a given script can call document.write() (for optimizing speculative parsing), it is necessary for the execution properties of the script as seen at start tag to remain constant until the end tag is parsed. This can be achieved by freezing the effective values for the src, defer and async attributes when a parser-inserted script is inserted to the tree. There's no non-racy way for a script to detect this when the script comes from the network stream, so this is OK. However, if the parser implements the same script execution logic for the network stream case and the document.write case in the same way, there is a non-racy way to detect the implementation details in the document.write() case. For an implementation that does speculative off-the-main-thread parsing, it is a developer time-consuming theoretical purity exercise to make the document.write() case correct per spec. OTOH, if the spec enshrines the freezing behavior as correct, it'll be a developer time-consuming theoretical purity exercise for implementations that don't have the kind of speculative parsing that needs the freezing.
* Having <nowiki>-- ></nowiki> terminate comments breaks CNN Money https://bugzilla.mozilla.org/show_bug.cgi?id=570309

ParserIssues

2010-06-02T13:40:52Z

Jgraham:

== Filed bugs ==

* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659 Initial U+0000 should not set frameset-ok to "not ok"
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 Steps for handling end tags in the "in foreign" mode get stuck in an infinite loop
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581 Steps for handling end tags in the "in foreign" mode may compare the name of an already-popped node
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <nowiki><p></nowiki>
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements

== Possible other issues ==

* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?
* To enable the parser to decide whether a given script can call document.write() (for optimizing speculative parsing), it is necessary for the execution properties of the script as seen at start tag to remain constant until the end tag is parsed. This can be achieved by freezing the effective values for the src, defer and async attributes when a parser-inserted script is inserted to the tree. There's no non-racy way for a script to detect this when the script comes from the network stream, so this is OK. However, if the parser implements the same script execution logic for the network stream case and the document.write case in the same way, there is a non-racy way to detect the implementation details in the document.write() case. For an implementation that does speculative off-the-main-thread parsing, it is a developer time-consuming theoretical purity exercise to make the document.write() case correct per spec. OTOH, if the spec enshrines the freezing behavior as correct, it'll be a developer time-consuming theoretical purity exercise for implementations that don't have the kind of speculative parsing that needs the freezing.

ParserIssues

2010-06-02T13:40:28Z

Jgraham:

== Filed bugs ==

* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659 Initial U+0000 should not set frameset-ok to "not ok"
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 Steps for handling end tags in the "in foreign" mode get stuck in an infinite loop
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581 Steps for handling end tags in the "in foreign" mode may compare the name of an already-popped node
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <p>
* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements

== Possible other issues ==

* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?
* To enable the parser to decide whether a given script can call document.write() (for optimizing speculative parsing), it is necessary for the execution properties of the script as seen at start tag to remain constant until the end tag is parsed. This can be achieved by freezing the effective values for the src, defer and async attributes when a parser-inserted script is inserted to the tree. There's no non-racy way for a script to detect this when the script comes from the network stream, so this is OK. However, if the parser implements the same script execution logic for the network stream case and the document.write case in the same way, there is a non-racy way to detect the implementation details in the document.write() case. For an implementation that does speculative off-the-main-thread parsing, it is a developer time-consuming theoretical purity exercise to make the document.write() case correct per spec. OTOH, if the spec enshrines the freezing behavior as correct, it'll be a developer time-consuming theoretical purity exercise for implementations that don't have the kind of speculative parsing that needs the freezing.

ParserIssues

2010-05-31T10:48:01Z

Jgraham: Created page with '== Filed bugs == * http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659 Initial U+0000 should not set frameset-ok to "not ok" * http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 ...'

Web ECMAScript

2009-08-13T13:31:23Z

Jgraham: /* RegExp */

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== RegExp ==

After a regexp is executed the RegExp constructor object has properties $1...$9 which are assigned the values of the first 9 match groups from the previous regexp. (more detail here)

DecimalEscapes in CharacterRanges all behave like \0 rather than throwing syntax errors i.e. /[\1-Z]/ will match any character with a codepoint between 0 and 90.

== Date ==

=== 15.9.4.3 Date.UTC ===

When called with fewer than 2 arguments Date.UTC must return NaN.

== Global scope ==

ES5 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Eval ==

Use of eval not called "eval". Shoud work but implementations differ on the scope (Spidermonkey first tries global and then local if the object as not found globally, JScript uses local scope, others use global scope), may not have strong compat requirements

eval.apply(this, code) should work but scope again varies when "this" is not the global object

eval.apply({}, code) should throw EvalError

== Date Parsing ==

TODO:This is a mess

== HTML comments ==

" followed by anything except new lines and finally followed by another "-->", or (2) one or two lines that start with just whitespace and comments and consist of just "-->". --> at the end of the last line of the script causes the line to be ignored unless the "-->" occurs within a comment. The last non-whitespace line of the script is ignored if it ends with "-->" and doesn't contain "//" or "", and <em>optionally</em> followed by anything except new lines and finally followed by another "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line. The last non-whitespace line of the script is ignored if it ends with "-->" and doesn't contain "//" (but not in eval).

In SpiderMonkey, "-->" on any line that starts with just whitespace and comments is treated as a line comment (same as //). (Also, ;version=1.6, 1.7 or 1.8 or ;e4x=1 enables E4X  comments.)

In Nitro and V8, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).

== Property Enumeration ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

== Object Properties ==

All objects have a mutable __proto__ property that is a reference to the prototype of the object. Note that ES5 defines that objects with extensible:false must not have their prototype mutated. In the case that setting an objects __proto__ would cause a prototype chain to become cyclic, the setter must fail and throw Error().

== Getters and Setters ==

* __lookupGetter__
* __lookupSetter__
* __defineGetter__
* __defineSetter__

Web ECMAScript

2009-06-22T09:31:41Z

Jgraham:

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== RegExp ==

After a regep is executed the RegExp constructor object has properties $1...$9 which are assigned the values of the first 9 match groups from the previous regexp. (more detail here)

== Date ==

=== 15.9.4.3 Date.UTC ===

When called with fewer than 2 arguments Date.UTC must return NaN.

== Global scope ==

ES3.1 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Eval ==

Use of eval not called "eval". Shoud work but implementations differ on the scope (Spidermonkey first tries global and then local if the object as not found globally, JScript uses local scope, others use global scope), may not have strong compat requirements

eval.apply(this, code) should work but scope again varies when "this" is not the global object

eval.apply({}, code) should throw EvalError

== Date Parsing ==

TODO:This is a mess

== HTML comments ==

" followed by anything except new lines and finally followed by another "-->", or (2) one or two lines that start with just whitespace and comments and consist of just "-->". --> at the end of the last line of the script causes the line to be ignored unless the "-->" occurs within a comment. The last non-whitespace line of the script is ignored if it ends with "-->" and doesn't contain "//" or "", and <em>optionally</em> followed by anything except new lines and finally followed by another "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line. The last non-whitespace line of the script is ignored if it ends with "-->" and doesn't contain "//" (but not in eval).

In SpiderMonkey, "-->" on any line that starts with just whitespace and comments is treated as a line comment (same as //). (Also, ;version=1.6, 1.7 or 1.8 or ;e4x=1 enables E4X  comments.)

In Nitro and V8, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).

== Property Enumeration ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

== Object Properties ==

All objects have a mutable __proto__ property that is a reference to the prototype of the object. Note that ES5 defines that objects with extensible:false must not have their prototype mutated. In the case that setting an objects __proto__ would cause a prototype chain to become cyclic, the setter must fail and throw Error().

== Getters and Setters ==

* __lookupGetter__
* __lookupSetter__
* __defineGetter__
* __defineSetter__

Web ECMAScript

2009-06-05T13:44:51Z

Jgraham: /* HTML comments */

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== RegExp ==

After a regep is executed the RegExp constructor object has properties $1...$9 which are assigned the values of the first 9 match groups from the previous regexp. (more detail here)

== Date ==

=== 15.9.4.3 Date.UTC ===

When called with fewer than 2 arguments Date.UTC must return NaN.

== Global scope ==

ES3.1 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Eval ==

Use of eval not called "eval". Shoud work but implementations differ on the scope (Spidermonkey first tries global and then local if the object as not found globally, JScript uses local scope, others use global scope), may not have strong compat requirements

eval.apply(this, code) should work but scope again varies when "this" is not the global object

eval.apply({}, code) should throw EvalError

== Date Parsing ==

TODO:This is a mess

== HTML comments ==

" followed by anything except new lines and finally followed by another "-->", or (2) one or two lines that start with just whitespace and comments and consist of just "-->". --> at the end of the last line of the script causes the line to be ignored unless the "-->" occurs within a comment.

In Futhark, the following is ignored if it is at the end of the script (i.e. just followed by whitespace lines): a line that starts with just whitespace and comments and consists of "-->", and <em>optionally</em> followed by anything except new lines and finally followed by another "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line.

In SpiderMonkey, "-->" on any line that starts with just whitespace and comments is treated as a line comment (same as //). (Also, ;version=1.6, 1.7 or 1.8 or ;e4x=1 enables E4X  comments.)

In Nitro and V8, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).

== Stuff that needs a home ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

Parser tests

2009-06-02T20:08:42Z

Jgraham: /* Tree Construction Tests */

=Parser Tests=

This page documents the unit-test format(s) being used for implementations of the HTML5 parsing spec. The aim is to produce implementation-independent, self-describing tests that can be shared between any groups working on these technologies.

==Tokenizer Tests==
The test format is [http://www.json.org/ JSON]. This has the advantage that the syntax allows backward-compatible extensions to the tests and the disadvantage that it is relatively verbose.

===Basic Structure===

{"tests": [

{"description":"Test description",
"input":"input_string",
"output":[expected_output_tokens]},
"contentModelFlags":[content_model_flags],
"lastStartTag":last_start_tag,
"ignoreErrorOrder":ignore_error_order
]}

<tt>description</tt>, <tt>input</tt> and <tt>output</tt> are always present. The other values are optional.

<tt>input_string</tt> is a string literal containing the input string to pass to the tokenizer.

<tt>expected_output_tokens</tt> is a list of tokens, ordered with the first produced by the tokenizer the first (leftmost) in the list. The list must mach the '''complete''' list of tokens that the tokenizer should produce. Valid tokens are:

["DOCTYPE", name, public_id, system_id, correctness]
["StartTag", name, {attributes}'', true'']
["StartTag", name, {attributes}]
["EndTag", name]
["Comment", data]
["Character", data]
"ParseError"

<tt>public_id</tt> and <tt>system_id</tt> are either strings or <tt>null</tt>. <tt>correctness</tt> is either <tt>true</tt> or <tt>false</tt>; <tt>true</tt> corresponds to the force-quirks flag being false, and vice-versa.

When the self-closing flag is set, the <tt>StartTag</tt> array has <tt>true</tt> as its fourth entry. When the flag is not set, the array has only three entries for backwards compatibility.

<tt>content_model_flags</tt> is a list of strings from the set:
PCDATA
RCDATA
CDATA
PLAINTEXT
The test case applies when the tokenizer begins with its content model flag set to any of those values. If <tt>content_model_flags</tt> is omitted, it defaults to <tt>["PCDATA"]</tt>.

<tt>last_start_tag</tt> is a lowercase string that should be used as "the tag name of the last start tag token emitted" in the tokenizer algorithm. If it is omitted, it is treated as if "no start tag token has ever been emitted by this instance of the tokeniser".

<tt>ignore_error_order</tt> is a boolean value indicating that the order of <tt>ParseError</tt> tokens relative to other tokens in the output stream is unimportant, and implementations should ignore such differences between their output and <tt>expected_output_tokens</tt>. (This is used for errors emitted by the input stream preprocessing stage, since it is useful to test that code but it is undefined when the errors occur). If it is omitted, it defaults to <tt>false</tt>.

Multiple tests per file are allowed simply by adding more objects to the "tests" list.

All adjacent character tokens are coalesced into a single <tt>["Character", data]</tt> token.

=== Open Issues ===
* Is the format too verbose?
* Do we want to allow the test to pass if only a subset of the actual tokens emitted matches the expected_output_tokens list?

==Tree Construction Tests==

Each file containing tree construction tests consists of any number of tests separated by two newlines (LF) and a single newline before the end of the file. For instance:

<pre>[TEST]LF
LF
[TEST]LF
LF
[TEST]LF</pre>

Where [TEST] is the following format:

Each test must begin with a string "#data" followed by a newline (LF). All subsequent lines until a line that says "#errors" are the test data and must be passed to the system being tested unchanged, except with the final newline (on the last line) removed.

Then there must be a line that says "#errors". It must be followed by one line per parse error that a conformant checker would return. It doesn't matter what those lines are, although they can't be "#document-fragment", "#document", or empty, the only thing that matters is that there be the right number of parse errors.

Then there *may* be a line that says "#document-fragment", which must be followed by a newline (LF), followed by a string of characters that indicates the context element, followed by a newline (LF). If this line is present the "#data" must be parsed using the HTML fragment parsing algorithm with the context element as context.

Then there must be a line that says "#document", which must be followed by a dump of the tree of the parsed DOM. Each node must be represented by a single line. Each line must start with "| ", followed by two spaces per parent node that the node has before the root document node.
* Element nodes must be represented by a "<tt><</tt>" then the ''tag name string'' "<tt>></tt>", and all the attributes must be given, sorted lexicographically by UTF-16 code unit according to their ''attribute name string'', on subsequent nodes, as if they were children of the element node.
* Attribute nodes must have the ''attribute name string'', then an "=" sign, then the attribute value in double quotes (").
* Text nodes must be the string, in double quotes. Newlines aren't escaped.
* Comments must be "<tt><</tt>" then "<tt>!-- </tt>" then the data then "<tt> --></tt>".
* DOCTYPEs must be "<tt><!DOCTYPE </tt>" then the name then if either of the system id or public id is non-empty a space, public id in double-quotes, another space an the system id in double-quotes, and then in any case "<tt>></tt>".

The ''tag name string'' is the local name prefixed by a namespace designator. For the HTML namespace, the namespace designator is the empty string, i.e. there's no prefix. For the SVG namespace, the namespace designator is "svg ". For the MathML namespace, the namespace designator is "math ".

The ''attribute name string'' is the local name prefixed by a namespace designator. For no namespace, the namespace designator is the empty string, i.e. there's no prefix. For the XLink namespace, the namespace designator is "xlink ". For the XML namespace, the namespace designator is "xml ". For the XMLNS namespace, the namespace designator is "xmlns ". Note the difference between "xlink:href" which is an attribute in no namespace with the local name "xlink:href" and "xlink href" which is an attribute in the xlink namespace with the local name "href".

If there is also a "#document-fragment" the bit following "#document" must be a representation of the HTML fragment serialization for the context element given by "#document-fragment".

For example:
<pre>
#data
<p>One<p>Two
#errors
3: Missing document type declaration
#document
| <html>
| <head>
| <body>
| <p>
| "One"
| <p>
| "Two"
</pre>

Tests can be found here: http://html5lib.googlecode.com/svn/trunk/testdata/tree-construction/

=== Open Issues ===
* should relax the order constraint?

Web ECMAScript

2009-05-19T09:50:48Z

Jgraham:

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== RegExp ==

After a regep is executed the RegExp constructor object has properties $1...$9 which are assigned the values of the first 9 match groups from the previous regexp. (more detail here)

== Date ==

=== 15.9.4.3 Date.UTC ===

When called with fewer than 2 arguments Date.UTC must return NaN.

== Global scope ==

ES3.1 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Eval ==

Use of eval not called "eval". Shoud work but implementations differ on the scope (Spidermonkey first tries global and then local if the object as not found globally, JScript uses local scope, others use global scope), may not have strong compat requirements

eval.apply(this, code) should work but scope again varies when "this" is not the global object

eval.apply({}, code) should throw EvalError

== Date Parsing ==

TODO:This is a mess

== HTML comments ==

" followed by anything except new lines and finally followed by another "-->", or (2) one or two lines that start with just whitespace and comments and consist of just "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line.

In Futhark, the following is ignored if it is at the end of the script (i.e. just followed by whitespace lines): a line that starts with just whitespace and comments and consists of "-->", and <em>optionally</em> followed by anything except new lines and finally followed by another "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line.

In SpiderMonkey, "-->" on any line that starts with just whitespace and comments is treated as a line comment (same as //). (Also, ;version=1.6, 1.7 or 1.8 or ;e4x=1 enables E4X  comments.)

In Nitro and V8, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).

== Stuff that needs a home ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

Web ECMAScript

2009-05-05T09:47:50Z

Jgraham: Magic regexp variables

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== RegExp ==

After a regep is executed the RegExp constructor object has properties $1...$9 which are assigned the values of the first 9 match groups from the previous regexp. (more detail here)

== Global scope ==

ES3.1 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Eval ==

Use of eval not called "eval". Shoud work but implementations differ on the scope (Spidermonkey first tries global and then local if the object as not found globally, JScript uses local scope, others use global scope), may not have strong compat requirements

eval.apply(this, code) should work but scope again varies when "this" is not the global object

eval.apply({}, code) should throw EvalError

== Date Parsing ==

TODO:This is a mess

== HTML comments ==

" followed by anything except new lines and finally followed by another "-->", or (2) one or two lines that start with just whitespace and comments and consist of just "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line.

In Futhark, the following is ignored if it is at the end of the script (i.e. just followed by whitespace lines): a line that starts with just whitespace and comments and consists of "-->", and <em>optionally</em> followed by anything except new lines and finally followed by another "-->". Moreover, a script can end with an open multiline comment if it ends with "-->" on the same line.

In SpiderMonkey, "-->" on any line that starts with just whitespace and comments is treated as a line comment (same as //). (Also, ;version=1.6, 1.7 or 1.8 or ;e4x=1 enables E4X  comments.)

In Nitro and V8, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).

== Stuff that needs a home ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

Web ECMAScript

2009-04-26T16:23:59Z

Jgraham: --> used as a comment start

Web ECMAScript

2009-04-17T10:18:31Z

Jgraham:

= Web ECMAScript =

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== Global scope ==

ES3.1 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Eval ==

Use of eval not called "eval". Shoud work but implementations differ on the scope (Spidermonkey first tries global and then local if the object as not found globally, JScript uses local scope, others use global scope), may not have strong compat requirements

eval.apply(this, code) should work but scope again varies when "this" is not the global object

eval.apply({}, code) should throw EvalError

== Date Parsing ==

TODO:This is a mess

== Stuff that needs a home ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

Web ECMAScript

2009-04-17T10:04:02Z

Jgraham:

= Web ECMAScript =

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== Identifiers ==

(this is very rough)

Identifiers containing escape sequences are not equivalent to fully unescaped identifiers in the case that, after fully unescaping identifier, it is a ReservedWord. In particular it is possible to create Identifiers that unescape to a reserved word so long as at least one character is fully escaped. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead) but it need not be the same character(s) as that originally used to create the identifier.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("b", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link(href) ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== Global scope ==

ES3.1 claims the global scope "this" is the same as the global object, which is not always true in HTML5.

== Stuff that needs a home ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

Web ECMAScript

2009-04-16T10:23:20Z

Jgraham:

= Web ECMAScript =

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
#otherwise return "<" + tag_name + " " + attribute_name "=" "\"" + attribute_value + "\"" ">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

# Let content be ToString(this)
# Let n be ToString(name)
# Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

# Let content be ToString(this)
# Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

# Let content be ToString(this)
# Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

# Let content be ToString(this)
# Return ToHTMLTag("bold", content)

=== String.prototype.fixed() ===

# Let content be ToString(this)
# Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

# Let content be ToString(this)
# Let attribute_value be ToString(color)
# Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

# Let content be ToString(this)
# Let attribute_value be ToString(size)
# Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

# Let content be ToString(this)
# Return ToHTMLTag("i", content)

=== String.prototype.link ===

# Let content be ToString(this)
# Let attribute_value be ToString(href)
# Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

# Let content be ToString(this)
# Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

# Let content be ToString(this)
# Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

# Let content be ToString(this)
# Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

# Let content be ToString(this)
# Return ToHTMLTag("sup", content)

== Stuff that needs a home ==

Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant)

Web ECMAScript

2009-04-16T10:05:11Z

Jgraham:

Web ECMAScript

2009-04-16T09:56:40Z

Jgraham: Start page for ECMAScript things needed on the web

= Web ECMAScript =

This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.

== 15.5.4 Properties of the String Prototype Object ==

Several extra methods are found on String.prototype for wrapping text in HTML elements (these are all generic; the this value need not be a String object):

Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):
if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"
otherwise return "<" + tag_name + " " + attribute_name "=" "\"" + attribute_value + "\"" ">" + content + "</" + tag_name + ">"

=== String.prototype.anchor(name) ===

1. Let content be ToString(this)
2. Let n be ToString(name)
3. Return ToHTMLTag("a", content, "name", n)

=== String.prototype.big() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("big", content)

=== String.prototype.blink() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("blink", content)

=== String.prototype.bold() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("bold", content)

=== String.prototype.fixed() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("tt", content)

=== String.prototype.fontcolor(color) ===

1. Let content be ToString(this)
2. Let attribute_value be ToString(color)
3. Return ToHTMLTag("font", content, "color", attribute_value)

=== String.prototype.fontsize(size) ===

1. Let content be ToString(this)
2. Let attribute_value be ToString(size)
3. Return ToHTMLTag("font", content, "size", attribute_value)

=== String.prototype.italics() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("i", content)

=== String.prototype.link ===

1. Let content be ToString(this)
2. Let attribute_value be ToString(href)
3. Return ToHTMLTag("a", content, "href", attribute_value)

=== String.prototype.small() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("small", content)

=== String.prototype.strike() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("strike", content)

=== String.prototype.sub() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("sub", content)

=== String.prototype.sup() ===

1. Let content be ToString(this)
2. Return ToHTMLTag("sup", content)

Presentations

2007-08-24T15:19:01Z

Jgraham: Add my BarCamb presentation

These are the known presentations related to the WHATWG and/or HTML5.

* [http://hixie.ch/advocacy/whatwg-presentation/ Proposing extensions to HTML4 and the DOM] by [[User:Hixie|Ian Hickson]]
* [http://lachy.id.au/dev/presentation/future-of-html/ The Future of HTML] by [[User:Lachlan_Hunt|Lachlan Hunt]] (Presented 2007-01-25)
* [http://simonwillison.net/2007/talks/oxford-html5/ What the heck is HTML 5?] by [[User:SimonW|Simon Willison]] (Presented 2007-04-11)
* [http://lists.w3.org/Archives/Public/www-archive/2007Apr/att-0036/html5.xml Evolving the Web: HTML5] by [[User:Annevk|Anne van Kesteren]] (Presented 2007-04-17 at QUT)
* [http://lists.w3.org/Archives/Public/www-archive/2007May/att-0063/html5-short.xml Evolving the Web: HTML5 (XTech 2007 edition)] by [[User:Annevk|Anne van Kesteren]] (Presented 2007-05-17 at XTech 2007)
* [http://2007.xtech.org/public/asset/attachment/83 Implementing an HTML5 conformance checker using XML tools] by Henri Sivonen (Presented 2007-05-18 at XTech 2007)
* [http://blog.whatwg.org/html5-geekmeet How HTML5 can be used today] by [[User:zcorpan|Simon Pieters]] (Presented 2007-05-23)
* [http://lists.w3.org/Archives/Public/www-archive/2007May/att-0087/html5.htm HTML5: Incremental Improvements to the Web] by [[User:Annevk|Anne van Kesteren]] (Presented 2007-05-31 at reboot 9.0)
* [http://edward.oconnor.cx/2007/BarCamp-San-Diego/ What to expect from HTML5] by [[User:EdwardOConnor|Edward O'Connor]] (Presented 2007-06-03 at BarCamp San Diego)
* [http://lachy.id.au/dev/presentation/developing-with-html5/Developing%20with%20HTML5.ppt Developing with HTML5] by [[User:Lachlan_Hunt|Lachlan Hunt]] (Presented 2007-08-03)
* [http://james.html5.org/presentations/barcamb.pdf HTML 5: The Next Generation of Markup on The Web] by: [[User:jgraham|James Graham]] (Presented 2007-08-24 at BarCamp Cambridge)

HTML5Lib

2006-12-25T00:30:45Z

Jgraham: /* Profiling on web-apps.htm */

= HTML5Lib =

[http://code.google.com/p/html5lib/ HTML5Lib] is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokenizer and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

== SVN ==
Please commit often with sort of detailed descriptions of what you did. If you want to make sure you're not going to redo work talk to people on #whatwg.

== General ==

In comments "XXX" indicates something that has yet to be done. Something might be wrong, has not yet been written and other things in that general direction.

In comments "AT" indicates that the comment documents an alternate implementation technique or strategy.

== HTMLTokenizer ==

The tokenizer is controlled by a single HTMLTokenizer class stored in tokenizer.py at the moment. You initialize the HTMLTokenizer with a stream argument that holds an HTMLInputStream. You can iterate over the object created to get tokens back.

Currently tokens are objects, they will become dicts.

=== Interface ===

The parser needs to change the self.contentModelFlag attribute which affects how certain states are handled.

=== Issues ===
* Use of if statements in the states may be suboptimal (but we should time this)

== HTMLParser ==

=== Profiling on web-apps.htm ===

I did some profiling on web-apps.htm which is a rather large document. Based on that I already changed a number of things which speed us up a bit. Below are some things to consider for future revisions:

* utils.MethodDispatcher is invoked way too often. By pre declaring some of it in InBody I managed to decrease the amount of invocatoins by over 24.000, but InBody.__init__ is invoked about 7000 times for web-apps.htm so that amount could be higher. Not sure how to put them somewhere else though. First thing I tried was HTMLParser but references get all messed up then...
- We should be able to store a single instance of each InsertionMode rather than creating a new one every time the mode switches. Hopefully we have been disiplined enough not to keep any state in those classes so the change should be painless.

* 713194 calls to __contains__ in sets.py makes us slow. Takes about 1.0x CPU seconds.
- I've just switched to the built-in sets type. hopefully this will help a bit [[User:Jgraham|Jgraham]] 00:30, 25 December 2006 (UTC)

* 440382 calls to char in tokenizer.py is the runner up with 0.8x CPU seconds.

* dataState in tokenizer.py with 0.7 CPU seconds is next.

* __iter__ in tokenizer.py with 0.59x CPU seconds...

* Creation of all node objects in web-apps takes .57x CPU seconds.

* etc.

== Testcases ==
Testcases are under the /tests directory. They require [http://cheeseshop.python.org/pypi/simplejson simplejson]. New code should not be checked in if it regresses previously functional unit tests. Ideally new features should be accompanied by new unit tests for those features. Documentation of the test format is available at [[Parser_tests]].

[[Category:Implementations]]

HTML5Lib

2006-12-25T00:13:49Z

Jgraham: /* Profiling on web-apps.htm */

= HTML5Lib =

[http://code.google.com/p/html5lib/ HTML5Lib] is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokenizer and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

== SVN ==
Please commit often with sort of detailed descriptions of what you did. If you want to make sure you're not going to redo work talk to people on #whatwg.

== General ==

In comments "XXX" indicates something that has yet to be done. Something might be wrong, has not yet been written and other things in that general direction.

In comments "AT" indicates that the comment documents an alternate implementation technique or strategy.

== HTMLTokenizer ==

The tokenizer is controlled by a single HTMLTokenizer class stored in tokenizer.py at the moment. You initialize the HTMLTokenizer with a stream argument that holds an HTMLInputStream. You can iterate over the object created to get tokens back.

Currently tokens are objects, they will become dicts.

=== Interface ===

The parser needs to change the self.contentModelFlag attribute which affects how certain states are handled.

=== Issues ===
* Use of if statements in the states may be suboptimal (but we should time this)

== HTMLParser ==

=== Profiling on web-apps.htm ===

I did some profiling on web-apps.htm which is a rather large document. Based on that I already changed a number of things which speed us up a bit. Below are some things to consider for future revisions:

* utils.MethodDispatcher is invoked way too often. By pre declaring some of it in InBody I managed to decrease the amount of invocatoins by over 24.000, but InBody.__init__ is invoked about 7000 times for web-apps.htm so that amount could be higher. Not sure how to put them somewhere else though. First thing I tried was HTMLParser but references get all messed up then...
- We should be able to store a single instance of each InsertionMode rather than creating a new one every time the mode switches. Hopefully we have been disiplined enough not to keep any state in those classes so the change should be painless.

* 713194 calls to __contains__ in sets.py makes us slow. Takes about 1.0x CPU seconds. We need to switch to built-in sets on python >=2.4 This should not be a difficult change.

* 440382 calls to char in tokenizer.py is the runner up with 0.8x CPU seconds.

* dataState in tokenizer.py with 0.7 CPU seconds is next.

* __iter__ in tokenizer.py with 0.59x CPU seconds...

* Creation of all node objects in web-apps takes .57x CPU seconds.

* etc.

== Testcases ==
Testcases are under the /tests directory. They require [http://cheeseshop.python.org/pypi/simplejson simplejson]. New code should not be checked in if it regresses previously functional unit tests. Ideally new features should be accompanied by new unit tests for those features. Documentation of the test format is available at [[Parser_tests]].

[[Category:Implementations]]

HTML5Lib

2006-12-25T00:06:06Z

Jgraham: /* Testcases */

= HTML5Lib =

[http://code.google.com/p/html5lib/ HTML5Lib] is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokenizer and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

== SVN ==
Please commit often with sort of detailed descriptions of what you did. If you want to make sure you're not going to redo work talk to people on #whatwg.

== General ==

In comments "XXX" indicates something that has yet to be done. Something might be wrong, has not yet been written and other things in that general direction.

In comments "AT" indicates that the comment documents an alternate implementation technique or strategy.

== HTMLTokenizer ==

The tokenizer is controlled by a single HTMLTokenizer class stored in tokenizer.py at the moment. You initialize the HTMLTokenizer with a stream argument that holds an HTMLInputStream. You can iterate over the object created to get tokens back.

Currently tokens are objects, they will become dicts.

=== Interface ===

The parser needs to change the self.contentModelFlag attribute which affects how certain states are handled.

=== Issues ===
* Use of if statements in the states may be suboptimal (but we should time this)

== HTMLParser ==

=== Profiling on web-apps.htm ===

I did some profiling on web-apps.htm which is a rather large document. Based on that I already changed a number of things which speed us up a bit. Below are some things to consider for future revisions:

* utils.MethodDispatcher is invoked way too often. By pre declaring some of it in InBody I managed to decrease the amount of invocatoins by over 24.000, but InBody.__init__ is invoked about 7000 times for web-apps.htm so that amount could be higher. Not sure how to put them somewhere else though. First thing I tried was HTMLParser but references get all messed up then...

* 713194 calls to __contains__ in sets.py makes us slow. Takes about 1.0x CPU seconds.

* 440382 calls to char in tokenizer.py is the runner up with 0.8x CPU seconds.

* dataState in tokenizer.py with 0.7 CPU seconds is next.

* __iter_ in tokenizer.py with 0.59x CPU seconds...

* Creation of all node objects in web-apps takes .57x CPU seconds.

* etc.

== Testcases ==
Testcases are under the /tests directory. They require [http://cheeseshop.python.org/pypi/simplejson simplejson]. New code should not be checked in if it regresses previously functional unit tests. Ideally new features should be accompanied by new unit tests for those features. Documentation of the test format is available at [[Parser_tests]].

[[Category:Implementations]]

Parser tests

2006-12-11T14:29:57Z

Jgraham: typos

HTML5Lib

2006-12-09T22:39:39Z

Jgraham: Move testcases bit

HTML5Lib

2006-12-09T22:36:54Z

Jgraham: Add note about testcases

Parser tests

2006-12-09T22:25:52Z

Jgraham: Create tokenizer testcase documentation

HTML5Lib

2006-12-03T00:53:29Z

Jgraham:

=HTML5Lib=

HTML5Lib is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokenizer and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

== Important Note ==
'''Do not contribute material to this page unless you are happy for it to be released under the terms of the MIT license rather than the usual GFDL'''

==Project Page==
[http://code.google.com/p/html5lib/ Google code project page]

==Design Issues==

===Tokenizer===

The tokenizer is controlled by a single Tokenizer class. It emits tokens which are subclasses of the Token class. At some level it needs to be possible to store information about the token being emitted as the tree builder sometimes need to reprocess a token, however there may be some opportunity to economize here.

====Interface====
getToken - return the next token.

====Description====
The current tokenizer state is stored in the state attribute. Each state corresponds to a single method on the Tokenizer object. The states attributes maps state names to methods.

Occasionally, parsing will result in characters being read multiple times from the stream. Therefore a queue is used to buffer characters that have been read from the file but need to be reprocessed (do we need to buffer multiple characters? Will support for a trailing slash change this?).

During processing, any unfinished tokens are held in the token attribute and finished tokens in the tokenQueue.

====Issues====
* Should keep track of line+col number for error reporting
* Use of if statements in the states may be suboptimal (but we should time this)

[[Category:Implementations]]

==Idea on how it can work together==

There's an HTMLParser class you can invoke with an object. What this object is can be decided later. File object, string, URI, etc. The newly created HTMLParser object then instantiates an HTMLTokenizer with itself as argument and the object. The HTMLTokenizer then invokes does things like parser.emitStartTagToken(name, ...) etc.

OK I've created a callback branch in svn with work in this direction. I don't know if it is going to work better or not... --[[User:Jgraham|Jgraham]] 00:53, 3 December 2006 (UTC)

HTML5Lib

2006-12-03T00:00:46Z

Jgraham: Copyright notice

HTML5Lib

2006-12-02T18:51:43Z

Jgraham: /* Description */

=HTML5Lib=

HTML5Lib is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokeniser and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

==Project Page==
[http://code.google.com/p/html5lib/ Google code project page]

==Design Issues==

===Tokeniser===

The tokeniser is controlled by a single Tokeniser class. It emits tokens which are subclasses of the Token class. At some level it needs to be possible to store information about the token being emitted as the tree builder sometimes need to reprocess a token, however there may be some opportunity to economize here.

====Interface====
getToken - return the next token.

====Description====
The current tokeniser state is stored in the state attribute. Each state corresponds to a single method on the Tokeniser object. The states attributes maps state names to methods.

Occasionally, parsing will result in characters being read multiple times from the stream. Therefore a queue is used to buffer characters that have been read from the file but need to be reprocessed (do we need to buffer multiple characters? Will support for a trailing slash change this?).

During processing, any unfinished tokens are held in the token attribute and finished tokens in the tokenQueue.

====Issues====
* Should keep track of line+col number for error reporting
* Use of if statements in the states may be suboptimal (but we should time this)

[[Category:Implementations]]

HTML5Lib

2006-12-02T18:28:55Z

Jgraham: readd category

=HTML5Lib=

HTML5Lib is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokeniser and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

==Project Page==
[http://code.google.com/p/html5lib/ Google code project page]

==Design Issues==

===Tokeniser===

The tokeniser is controlled by a single Tokeniser class. It emits tokens which are subclasses of the Token class. At some level it needs to be possible to store information about the token being emitted as the tree builder sometimes need to reprocess a token, however there may be some opportunity to economize here.

====Interface====
getToken - return the next token.

====Description====
The current tokeniser state is stored in the tokenQueue. Each state corresponds to a single method on the Tokeniser object. The states attributes maps state names to methods.
Occasionally, parsing will result in characters being read multiple times from the stream. Therefore a queue is used to buffer characters that have been read from the file but need to be reprocessed (do we need to buffer multiple characters? Will support for a trailing slash change this?).
During processing, any unfinished tokens are held in the token attribute and finished tokens in the tokenQueue.

====Issues====
* Should keep track of line+col number for error reporting
* Use of if statements in the states may be suboptimal (but we should time this)

[[Category:Implementations]]

HTML5Lib

2006-12-02T18:27:24Z

Jgraham: Description of tokeniser

=HTML5Lib=

HTML5Lib is a project to create a Python-based implementation of various parts of the WHATWG spec, in particular, a tokeniser and parser. It is '''not''' an offical WHATWG project, however we plan to use this wiki to document and discuss the library design. The code is avaliable under an open-source MIT license.

==Project Page==
[http://code.google.com/p/html5lib/ Google code project page]

==Design Issues==

===Tokeniser===

The tokeniser is controlled by a single Tokeniser class. It emits tokens which are subclasses of the Token class. At some level it needs to be possible to store information about the token being emitted as the tree builder sometimes need to reprocess a token, however there may be some opportunity to economize here.

====Interface====
getToken - return the next token.

====Description====
The current tokeniser state is stored in the tokenQueue. Each state corresponds to a single method on the Tokeniser object. The states attributes maps state names to methods.
Occasionally, parsing will result in characters being read multiple times from the stream. Therefore a queue is used to buffer characters that have been read from the file but need to be reprocessed (do we need to buffer multiple characters? Will support for a trailing slash change this?).
During processing, any unfinished tokens are held in the token attribute and finished tokens in the tokenQueue.

====Issues====
* Should keep track of line+col number for error reporting
* Use of if statements in the states may be suboptimal (but we should time this)

HTML5Lib

2006-12-02T17:25:42Z

Jgraham: Initial page creation

Implementations

2006-12-02T17:19:46Z

Jgraham: Start implementations page

This page documents implementations of various WHATWG specs

==Web Browsers==

==Libraries==
* [[HTML5Lib]]

Main Page

2006-12-02T17:17:29Z

Jgraham: Add implementations page

Welcome to the WHATWG Wiki. Before you begin, please read the [[WHATWG Wiki:Contribution Guidelines|Contribution Guidelines]].

==Purpose==
The purpose of the WHATWG Wiki is to create a place for WHATWG contributors to post and compile their own proposals and ideas regarding WHATWG specifications. The specifications themselves will not be available for editing via this wiki. However, ideas you post here may find their way into current and future WHATWG specifications.

== Feature Proposals ==

See [[Feature Proposals]].

==WHATWG Specifications==
* [[Web Forms 2.0]]
* [[Web Applications 1.0]]
* [[Web Controls 1.0]]

==Implementations==
See [[Implementations]].

==Communicating with the community==
The WHATWG community has four main channels of communication:
* [http://www.whatwg.org/mailing-list The mailing list]
* [http://blog.whatwg.org/ The blog]
* [http://wiki.whatwg.org/ This wiki]
* [[IRC]]

Image Caption

2006-11-16T18:27:35Z

Jgraham: reword text on assitive technologies

Image caption are often found on the web, but there is no standard markup for this.

== Problem Description ==
Currently, most people use either a table, custom class names, or simply put the image inside a paragraph, each option either conveying a wrong meaning or being ambiguous with the rest of the content.

An interesting analysis has been done on the subject by Dan Cederholm in one of his SimpleQuiz. [http://www.simplebits.com/notebook/2004/01/20/sqxi_conclusion.html His conclusion]:

<blockquote>So in this case, I might choose option A -- because visually it shows the relationship between the items better than the others. But I suppose this is bad semantics. Or maybe just another case where we don't have the 'perfect' set of defined elements for this (very) specific job.</blockquote>

And his option A was:
<pre>
<p><img scr="..."><br />
Caption Text</p>
</pre>

In other word, he could not figure out anything good using current elements available in HTML, and, as most people do, had to create his own solution.

Setting a standard for such things -- an explicit association between the caption and the illustration -- would help image search engines, it could enable the automatic creation of a figure index for a page. The fact that image captions should be treated differently to body text (they are not in the main flow of the document) suggests this element could be important for figure handling by assistive tools allowing e.g. aural browsers to skip captions except on explicit user request.

== Proposed Solutions ==

=== <figure> with <caption> ===
A <figure> element contains illustrative content for the current section. It can contain a <caption> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

<pre>
<table>
<tr><td>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</td></tr>
</table>
</pre>

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when figure captions end up at the top (or the bottom) of the enclosing table.

==== Implementation ====
Parsing changes in this section could be hard to implement is the <caption> element's legacy within <table>. So it is uncertain

Putting aside the parsing problem, there's not much else to implement for visual browsers. A good display model that could be used to display figures is already available in CSS 2.1:

<pre>
figure { display: table; }
caption { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the caption either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the caption's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
The syntax is pretty straightforward to use. "figure" and "caption" are commonly used terms to designate exactly this feature in the print world. It should be a natural choice to authors that wonder how to markup their images.

This markup won't work however if an author wants the caption to be elsewhere in the document. (In this proposal, <caption> is pinned to the figure's content.) It does not seem a common use case however.

=== <figure> with <legend> ===
A <figure> element contains illustrative content for the current section. It can contain a <legend> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<legend>Caption Text</legend>
<img src="...">
</figure>
</pre>

==== Processing Model ====
:''To be completed''

==== Limitations ====
:''To be completed''

==== Implementation ====
A good display model that could be used to display figures is already available in CSS 2.1, the table model. A default stylesheet could look like this:

<pre>
figure { display: table; }
figure legend { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the figure legend either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the legend's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
"figure" and "legend" are commonly used terms in the print world, so their use could prove natural to authors. It is most likely that authors that need a markup for their figure will chose this one if it is sanctioned in a standard.

This markup won't work if an author wants the caption to be elsewhere in the document. (In this proposal, <legend> is pinned to the figure's content.) It does not seem a common use case however.

== Usage ==
:''Some evidence is there that this feature is desparately needed on the web.''