https://wiki.whatwg.org/api.php?action=feedcontributions&user=Ms2ger&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-29T05:12:17ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=W3C&diff=10309W3C2019-06-25T08:47:03Z<p>Ms2ger: </p>
<hr />
<div>Some issues with the W3C. Not really exhaustive.<br />
<br />
* Restrictive copyright<br />
* Forks rather than cooperates<br />
* Main publications on TR/ are stale and cause confusion<br />
** https://bugzilla.mozilla.org/show_bug.cgi?id=688878#c6<br />
** https://bugzilla.mozilla.org/show_bug.cgi?id=505115#c141<br />
** http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1207.html<br />
** https://critic.hoppipolla.co.uk/showcomment?chain=1232<br />
** http://lists.w3.org/Archives/Public/public-w3process/2014Sep/0081.html<br />
** https://github.com/emscripten-core/emscripten/pull/8849#issuecomment-505263102<br />
** ?? many versions of canvas<br />
* Has a Process that can [https://groups.google.com/d/msg/mozilla.dev.platform/BnY1261cNJo/ItsnSsi36QQJ lead to working groups doing bad testing] (just be able to meet W3C process requirements for transitioning from Candidate Recommendation to final W3C Recommendation, and the test suite cannot be living when the rules are strictly applied)<br />
* CSS modularization (When designing the Fullscreen/<dialog> stacking model, the lack of a living standard spec for CSS that represented the current cutting edge status meant that features of CSS that were may have been overridden by one spec (e.g. CSS regions) were used by the proposal, without the implications being understood. (Specifically, it was suggested that CSS regions redefined how the containing block mechanism works; in general, without knowing what all the relevant specs are, there is no way to be sure that no other spec does in fact modify some underlying concept.))<br />
<br />
<br />
== History ==<br />
<br />
=== Pre-WHATWG ===<br />
<br />
In December 1997, HTML 4.0 was published as a W3C Recommendation. In February 1998, XML 1.0 is published as a W3C Recommendation. The same year, the W3C held a workshop about [https://www.w3.org/MarkUp/future/ Shaping the Future of HTML]:<br />
<br />
<blockquote><br />
Is HTML 4.0 the last HTML? Does XML mean the end of HTML? Has W3C given up on HTML?<br />
<br />
[...]<br />
<br />
In discussions, it was agreed that further extending HTML 4.0 would be difficult, as would converting 4.0 to be an XML application. The proposed way to break free of these restrictions is to make a fresh start with the next generation of HTML based upon a suite of XML tag-sets.<br />
</blockquote><br />
<br />
[https://www.w3.org/TR/1998/WD-html-in-xml-19981205/ Reformulating HTML as XML] was published as a Working Draft in December 1998, and later became known as XHTML 1.0.<br />
<br />
Separately, the W3C worked on a new version of web forms, called [http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830 XHTML Extended Forms] (August 1999), later renamed to XForms, which was by design not backwards compatible with HTML forms. The introduction of the draft says:<br />
<br />
<blockquote><br />
After careful consideration, the HTML Working Group has decided that the goals for the next generation of forms are incompatible with preserving backwards compatibility with browsers designed for earlier versions of HTML. It is our objective to provide a clean new forms model (“XHTML Extended Forms”) based on a set of well-defined requirements. The requirements described in this document are based on experience with a very broad spectrum of form applications.<br />
</blockquote><br />
<br />
In April 1999, the W3C published a Working Draft of [https://www.w3.org/TR/1999/xhtml-modularization-19990406/ Modularization of XHTML], later known as XHTML 1.1, which didn’t introduce new features, but split the DTD into modules for the purpose of enabling subsetting and extending XHTML.<br />
<br />
In August 2002, the W3C published a Working Draft of [https://www.w3.org/TR/2002/WD-xhtml2-20020805/ XHTML 2.0], which says in its introduction:<br />
<br />
<blockquote><br />
XHTML 2 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions.<br />
</blockquote><br />
<br />
The direction at the W3C at the time was thus to not work on HTML, but instead focus on new markup languages (XForms and XHTML 2.0) that are explicitly not backwards compatible with HTML or even XHTML 1.x.<br />
<br />
=== WHATWG is formed ===<br />
<br />
In June 2004, the W3C held a workshop on [https://www.w3.org/2004/04/webapps-cdf-ws/ Web Applications and Compound Documents], where Mozilla and Opera proposed to extend HTML in a backwards compatible way. What happened here is well explained in Henri Sivonen’s Master’s Thesis [https://hsivonen.fi/thesis/html5-conformance-checker#position-paper An HTML5 Conformance Checker]:<br />
<br />
<blockquote><br />
==== The Mozilla/Opera Joint Position Paper ====<br />
<br />
The balance of power in the W3C had shifted from traditional desktop browser vendors to various other interest groups such as makers of software for mobile walled gardens and developers of “rich client” technologies that could be deployed on intranets but that were not used by the general public on the Web. This had led to a situation where the focus was more on the “Semantic Web”, “Web Services” and “Mobile Web” than on what is usually considered “the Web”. As a result, the development of the Web itself had been neglected.<br />
<br />
In June 2004, the W3C held a workshop on Web Applications and Compound Documents. The Mozilla Foundation and Opera Software – the two most active browser vendors in the W3C at the time – submitted a joint position paper noting the “rising threat of single-vendor solutions” and calling for seven principles to be followed in the design of Web Applications Technologies. (At the time Microsoft – a notable browser vendor itself – was pushing a single-vendor solution code named Avalon and Apple was catching up having entered the market only recently.)<br />
<br />
The first one of the seven principles in the Mozilla/Opera position paper was “Backwards compatibility, clear migration path”. The transition from HTML 4 to XHTML 1.0 had not worked out smoothly as discussed earlier. In addition, XForms, the W3C’s successor for HTML forms, did not provide backwards compatibility or a clear migration path. Moreover, the HTML working group was working on XHTML 2.0, which was designed to be incompatible with XHTML 1.x, even though the transition to XHTML 1.x served as application/xhtml+xml was not complete.<br />
<br />
The position paper called for well-defined error handling – something that had never been addressed for HTML. The paper took a position in favor of graceful recovery (as in CSS) and against the Draconian error policy of XML.<br />
<br />
The paper called for every feature to be backed by a practical use case and for the specification process to be open. This was in contrast with including features that are “nice to have” and making decisions on the W3C’s member-only mailing lists.<br />
<br />
The paper took a position against device-specific profiles. This was in direct contrast with the Modularization of XHTML as well as mobile profiles of other W3C deliverables such as Scalable Vector Graphics (SVG). The paper also took a position more favorable to scripting (JavaScript in practice) than what has been the general line in the W3C.<br />
<br />
[...]<br />
<br />
==== The WHATWG is Formed ====<br />
<br />
The proposal presented by Opera Software and the Mozilla Foundation was not well received at the W3C. At the end of the second day of the workshop, a poll was held on the topic of the joint position paper: whether the W3C should develop extensions to HTML, CSS and the DOM as proposed. Of the 51 attendees of the workshop, 8 voted in favor of the motion and 11 voted against. When the motion was slightly reformulated, 14 voted against.<br />
<br />
Two days after the vote at the workshop, The Web Hypertext Applications Technology Working Group (WHATWG) and its public mailing list were publicly announced. The group was described as “a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties”. The stated intent was creating specifications for implementation in “mass-market Web browsers, in particular Safari, Mozilla, and Opera”.<br />
<br />
The initial (invite-only) membership of the WHATWG consisted of individuals affiliated with Apple, Mozilla and Opera Software. (Ian Hickson, the editor of the WHATWG specifications, later moved to Google.) However, in the view of the Web held by the WHATWG, there is also a fourth mass-market browser: Microsoft’s Internet Explorer – the leader in market share. Microsoft has not been participating in the WHATWG despite having been invited. The publicly stated reason was that the WHATWG lacked a patent policy. Dean Edwards, a Internet Explorer expert not affiliated with Microsoft, joined the WHATWG later.<br />
<br />
Even though the group of WHATWG members is invite-only, anyone is allowed to join the WHATWG mailing list and contribute technically, which makes the process open. [...]<br />
</blockquote><br />
<br />
The formation of the WHATWG was a turning point for HTML. Mozilla, Opera and Apple were interested in working together to extend HTML but had to do so outside the W3C.<br />
<br />
The two main WHATWG specifications were [https://whatwg.org/specs/web-apps/2005-09-01/ Web Applications 1.0] and [https://whatwg.org/specs/web-forms/2004-06-27-call-for-comments/ Web Forms 2.0]. An earlier version of Web Forms 2.0 was called [http://www.hixie.ch/specs/html/forms/xforms-basic-1 Proposed XHTML Module: XForms Basic]; it was, essentially, taking features of XForms and making them backwards compatible with HTML 4. Web Forms 2.0 was later folded into the Web Applications 1.0 specification, which was later [https://github.com/whatwg/html/commit/c03d221023f2ee75ca0db70751a404e236256372 renamed to HTML5] (May 2007), and [https://blog.whatwg.org/html-is-the-new-html5 again later to just HTML] (January 2011).<br />
<br />
=== New W3C HTML WG ===<br />
<br />
The W3C took note that browser vendors were ignoring their work on XForms and XHTML 2.0 and were instead focusing on implementing the WHATWG proposals. In October 2006, Tim Berners-Lee wrote in his blog post [http://dig.csail.mit.edu/breadcrumbs/node/166 Reinventing HTML]:<br />
<br />
<blockquote><br />
Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work... The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML.<br />
</blockquote><br />
<br />
In November 2006, Ian Hickson [http://lists.w3.org/Archives/Public/www-archive/2006Nov/0045.html proposed a charter] for the new HTML Working Group on the www-archive mailing list:<br />
<br />
<blockquote><br />
<br />
==== Mission ====<br />
<br />
This group will continue the evolution of HTML by maintaining, and producing incremental revisions to, the HTML, XHTML, and DOM HTML languages and APIs.<br />
<br />
[...]<br />
<br />
==== Relationship to the WHAT Working Group ====<br />
<br />
The Working Group is expected to work in collaboration with the WHATWG to produce identical specifications, preferably by having the same editor. This collaboration may cease if the two communities do not agree on technical matters.<br />
</blockquote><br />
<br />
In March 2007, the new [https://www.w3.org/2007/03/HTML-WG-charter.html HTML Working Group is chartered]. The charter reads:<br />
<br />
<blockquote><br />
The mission of the HTML Working Group, part of the HTML Activity, is to continue the evolution of HTML (including classic HTML and XML syntaxes).<br />
<br />
[...]<br />
<br />
This group will maintain and produce incremental revisions to the HTML specification, which includes the series of specifications previously published as XHTML version 1. Both XML and 'classic HTML' syntaxes will be produced.<br />
</blockquote><br />
<br />
In May 2007, the WHATWG specification is renamed to HTML5, and the W3C also publishes HTML5 that is identical from the table of contents onward. Ian Hickson was editor of both specifications.<br />
<br />
In January 2008, a [https://www.w3.org/TR/2008/WD-html5-20080122/ First Public Working Draft of HTML5] is published.<br />
<br />
In the years to come, the W3C HTML working group made decisions that the WHATWG disagreed with, which resulted in the two specifications deverging. The W3C also favored publishing multiple separate specifications, e.g. the canvas 2d context and Web Workers were their own specifications at the W3C, while the WHATWG favored a single big kitchensink specification.<br />
The WHATWG HTML standard says in its [https://html.spec.whatwg.org/multipage/introduction.html#history-2 History] section:<br />
<br />
<blockquote><br />
For a number of years, both groups then worked together. In 2011, however, the groups came to the conclusion that they had different goals: the W3C wanted to publish a "finished" version of "HTML5", while the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification rather than freezing it in a state with known problems, and adding new features as needed to evolve the platform.<br />
<br />
Since then, the WHATWG has been working on this specification (amongst others), and the W3C has been copying fixes made by the WHATWG into their fork of the document (which also has other changes).<br />
</blockquote><br />
<br />
=== Forking ===<br />
<br />
This is an extract of an e-mail sent in the context of complaining about the W3C forking the 2D Canvas part of the HTML spec. The observation was that while the fork of the WHATWG version meant the W3C was publishing one redundant copy, the situation just within the W3C was actually a lot worse:<br />
<br />
<pre>Here's the list of all the 2D Context API specs I could find at the<br />
W3C as of March 4th 2014:<br />
<br />
• http://dev.w3.org/2006/canvas-api/canvas-2d-api.html<br />
• http://www.w3.org/TR/2008/WD-html5-20080122/#the-2d<br />
• http://www.w3.org/TR/2008/WD-html5-20080610/the-canvas.html#the-2d<br />
• http://www.w3.org/TR/2009/WD-html5-20090212/the-canvas-element.html#the-2d-context<br />
• http://www.w3.org/TR/2009/WD-html5-20090423/the-canvas-element.html#the-2d-context<br />
• http://www.w3.org/TR/2009/WD-html5-20090825/the-canvas-element.html#the-2d-context<br />
• http://www.w3.org/TR/2010/WD-2dcontext-20100304/<br />
• http://www.w3.org/TR/2010/WD-2dcontext-20100624/<br />
• http://www.w3.org/TR/2010/WD-2dcontext-20101019/<br />
• http://www.w3.org/TR/2011/WD-2dcontext-20110113/<br />
• http://www.w3.org/TR/2011/WD-2dcontext-20110405/<br />
• http://www.w3.org/TR/2011/WD-2dcontext-20110525/<br />
• http://www.w3.org/TR/2012/CR-2dcontext-20121217/<br />
• http://www.w3.org/TR/2012/WD-2dcontext-20120329/<br />
• http://www.w3.org/TR/2012/WD-2dcontext-20121025/<br />
• http://www.w3.org/TR/2012/WD-2dcontext2-20121217/<br />
• http://www.w3.org/TR/2013/CR-2dcontext-20130806/<br />
• http://www.w3.org/TR/2013/WD-2dcontext2-20130528/<br />
• http://www.w3.org/TR/2013/WD-2dcontext2-20131029/<br />
• http://dev.w3.org/html5/canvas-extensions/<br />
• http://dev.w3.org/html5/2dcontext-LC/<br />
• http://dev.w3.org/html5/2dcontext/<br />
• http://www.w3.org/TR/2dcontext/<br />
• http://www.w3.org/TR/2dcontext2/<br />
• http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/<br />
• http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/<br />
• http://www.w3.org/html/wg/drafts/2dcontext/master/<br />
<br />
Note that the first one has "2006" in the URL, is undated, says<br />
copyright "2004", and references a draft from 2009. So the dates in<br />
the URLs aren't very useful in determining whether they're up to date<br />
or not. Then, notice the bottom seven, all of which seem to have some<br />
claim to being the "latest" version. Four of them are dated March 4th<br />
2014 (today)!<br />
<br />
I actually couldn't tell you which version an implementor should look<br />
at to get the latest information if they wanted a W3C reference. They<br />
contradict each other (e.g. different methods are differently named<br />
even amongst the various editors' drafts -- and that's not even<br />
comparing them to the WHATWG spec, it's the W3C specs that contradict<br />
each other here). Also, they all seem to be missing cross-references<br />
to key terms (e.g. what does "fully decodable" mean? It's underlined,<br />
indicating it's a link, but it isn't actually a link).</pre><br />
<br />
<br />
In April 2014, Ian Hickson sends an [https://lists.w3.org/Archives/Public/www-archive/2014Apr/0034.html email] to the www-archive mailing list with the subject “Re: W3C vs WHATWG specs”, partially quoted below.<br />
<br />
<blockquote><br />
The W3C says "Forking a specification imposes high costs, and is therefore not recommended" (http://www.w3.org/2013/09/html-faq).<br />
But then they do it. Over and over again.<br />
<br />
[...]<br />
<br />
In the case of the WHATWG specifications, the licenses allow broad re-use, so that implementors can copy-and-paste text into their comment blocks, so that tutorial writers can copy-and-paste text into their documentation, so that experiments we haven't considered can spring up without inhibition, and so that, if the WHATWG stops being a good steward (like the W3C stopped being a good steward in the early 2000s), the next group of spec editors doesn't have to start from scratch.<br />
<br />
However, forking and competing? That's not why the spec is reusable. It's plagiarism. Yes, I use that word intentionally. Taking someone else's work or ideas and passing them off as one's own.<br />
</blockquote><br />
<br />
=== W3C HTML5 Recommendation ===<br />
<br />
In October 2014, [https://www.w3.org/blog/news/archives/4167 HTML5 is published as a W3C Recommendation].<br />
<br />
In October 2015, work on HTML at the W3C moved to the Web Platform Working Group; the HTML Working Group charter was not renewed.<br />
<br />
In January 2016, Anne van Kesteren, one of the editors of the WHATWG HTML standard, [https://annevankesteren.nl/2016/01/film-at-11 writes on his blog]:<br />
<br />
<blockquote><br />
The W3C has forked the HTML Standard for the <i>n</i>th time. As always, it is pretty disastrous:<br />
<br />
* Erased all Git history of the document.<br />
* Did not document how they transformed the document. Issues of mismatches have already been reported and it will likely be a long time, if ever, before all bugs due to this process are uncovered, since it was not open.<br />
* Did not discuss plans with the wider community.<br />
* Did not discuss plans with the folks they were forking from.<br />
* Did not even discuss plans with the members of the W3C Web Platform Working Group.<br />
* Erased the acknowledgments section.<br />
* Erased the copyright and licensing information and replaced it with their own.<br />
<br />
So far this fork has been soundly ignored by the HTML community, which is as expected and desired. We hesitated to post this since we did not want to bring undeserved attention to the fork. But we wanted to make the situation clear to the web standards community, which might otherwise be getting the wrong message. Thus, proceed as before: the standards with green stylesheets are the up-to-date ones that should be used by implementers and developers, and referred to by other standards. They are where work on crucial bugfixes such as setting the correct flags for <code>&lt;img></code> fetches and exciting new features such as <code>&lt;script type=module></code> will take place.<br />
<br />
If there are blockers preventing your organization from working with the WHATWG, feel free to reach out to us for help in resolving the matter. Deficient forks are not the answer.<br />
<br />
— The editors of the HTML Standard<br />
</blockquote><br />
<br />
The W3C continued to work on their fork. In November 2016, [https://www.w3.org/blog/news/archives/5932 HTML 5.1 reaches W3C Recommendation]. In December 2017, [https://www.w3.org/blog/news/archives/6696 HTML 5.2 reaches W3C Recommendation].<br />
<br />
=== WHATWG IPR Policy ===<br />
<br />
Also in December 2017, [https://blog.whatwg.org/working-mode-changes the WHATWG gained a patent policy]:<br />
<br />
<blockquote><br />
The WHATWG has been going great since it began in 2004, but without participation from all the browser engine implementers, was only partially meeting its goals. Over the last year, engineers and attorneys from the organizations behind Blink, Edge, Gecko, and WebKit have worked together to find a way forward that works for all the stakeholders.<br />
<br />
==== What’s happening? ====<br />
<br />
The organizations behind the four major integrated browser engines — Apple, Google, Microsoft, and Mozilla — have developed an Intellectual Property Rights (IPR) Policy and governance structure for the WHATWG. This enables more people to collaborate on Living Standards.<br />
</blockquote><br />
<br />
The W3C [https://www.w3.org/blog/2017/12/whatwg-working-mode-changes/ reacted] to this as follows:<br />
<br />
<blockquote><br />
Earlier today, the WHATWG announced a new organization structure. W3C is flattered that WHATWG has adopted many shared features that are extremely positive for the web community. Among the features of the revised organization (some of which have happened prior to this announcement) that I think are excellent are:<br />
<br />
* A Royalty-Free patent policy aligned with the W3C Patent Policy<br />
* The notion of having a Review Draft (which the WHATWG is using for their patent commitments)<br />
* The notion that features only go into the Living Standards if they have multiple implementation commitments and tests<br />
* Continued partnership between W3C and WHATWG on testing<br />
* Permissive specification licensing with attribution (CC-BY)<br />
* A code of conduct<br />
<br />
The new WHATWG Steering Group invited me to meet with them earlier this month. They shared their motivation for their new structure. Both organizations are motivated to build a stronger partnership between WHATWG and W3C, and the Steering Group and W3C plan to work on this. We welcome and look forward to that conversation.<br />
</blockquote><br />
<br />
In May 2018, the W3C held their annual Advisory Committee meeting, where the relationship with the WHATWG was discussed. In the blog post [https://www.w3.org/blog/2018/06/w3c-strategic-highlights-for-spring-2018-and-advisory-committee-meeting/ W3C strategic highlights for spring 2018 and Advisory Committee meeting], Jeff Jaffe reports:<br />
<br />
<blockquote><br />
<br />
==== Our partnership with WHATWG ====<br />
<br />
W3C management shared a proposal for a joint workmode with WHATWG on HTML, that was developed with the WHATWG Steering Group, and seeks to organize a partnership that has had ebbs and flows over a period of more than a decade. A set of terms were developed, but W3C management had not had an opportunity to socialize it, or get feedback, reaction, and support. A large number of people came to the microphone with diverse viewpoints. There was general support for the overall direction, but quite a few important suggestions about how to make the proposal even better were made and need to be further developed before broader socialization.<br />
</blockquote><br />
<br />
In July 2018, a [https://github.com/whatwg/html/pull/3843 Review Draft of the WHATWG HTML standard] is published, which is the first time the WHATWG provides patent protection for the HTML standard. Patent protection has been one of the stated reasons why the W3C have forked WHATWG standards.<br />
<br />
[[Category:Spec_coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs/todo&diff=10050Specs/todo2016-03-15T09:05:58Z<p>Ms2ger: Update</p>
<hr />
<div>There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch, post on the WHATWG mailing list or say something on [[IRC]].<br />
<br />
== Platform ==<br />
<br />
* [https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html HTML Editing APIs]<br />
* multipart/form-data<br />
* SVG<br />
* APNG (other image formats too maybe?)<br />
* [[Wikipedia:Robots.txt|robots.txt]]<br />
* A specification that defines how XML maps to DOM Core. (This could be in DOM Parsing and Serialization or HTML if XML does not get updated.)<br />
* X-Frames-Options (make part of CSP?)<br />
* HTTP (error handling in particular, might become less of an issue if we're successful in removing it in favor of HTTPS)<br />
<br />
== APIs ==<br />
<br />
* User Interaction Events (onclick, onkeypress, etc).<br />
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus<br />
** setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]<br />
** [http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1719 selectstart] (WebKit/IE)<br />
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html<br />
* The console.* API.<br />
** https://github.com/DeveloperToolsWG/console-object<br />
** http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694<br />
** http://www.w3.org/mid/d7be01cb7077$4dd45010$e97cf030$@gmail.com<br />
** http://sideshowbarker.github.com/console-spec/]<br />
* [[DOM XPath]]<br />
* [[DOM XSLTProcessor]]<br />
<br />
== CSS ==<br />
<br />
There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:<br />
* Hit Testing (see http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html)<br />
* Form control styling (see [https://github.com/domenic/html-as-custom-elements HTML as Custom Elements])<br />
* Table Layout<br />
** http://dbaron.org/css/intrinsic/<br />
** http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm<br />
** https://drafts.csswg.org/css-tables-3/<br />
* Replaced Content<br />
** http://dev.w3.org/csswg/css3-content/ (Do we still want this or is the component model sufficient?)<br />
* an imperative model of box-tree construction<br />
<br />
== Registries ==<br />
<br />
Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:<br />
<br />
* MIME types<br />
* URL schemes<br />
<br />
It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).<br />
<br />
See also: [[Registries]]<br />
<br />
== Miscellaneous ==<br />
* an API to do syntax highlighting on &lt;textarea>, &lt;pre>, and contenteditable sections would be highly popular with Web developers (ack Ryan Johnson). (This would probably best be done as some sort of output filter at the CSS level, rather than anything HTML-specific.)<br />
* Animated [[GIF]]s need a spec that, in particular, specifies how to handle timings (not all browsers honor all values, so we should specify what needs to be honored exactly)<br />
* Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/20101101063413.bf1d8102.eric@bisonsystems.net)<br />
* <del>innerText and</del> outerText, if browsers don't remove them entirely<br />
** http://perfectionkills.com/the-poor-misunderstood-innerText/<br />
** https://github.com/whatwg/html/issues/465<br />
* data URLs<br />
** https://simonsapin.github.io/data-urls/<br />
<br />
== Other stuff ==<br />
<br />
http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has a description of some sections that needed editing in 2008 and how much work they would be.<br />
<br />
Some notes from the HTML5 spec about things that need doing:<br />
<br />
* a way to show icons for file types e.g. http://www.gadgetopia.com/2004/05/04/FileIconTag.html (this should probably be a function for the 'content', 'background-image' and 'list-style-image' properties in CSS)<br />
** Maybe something like moz-icon://? http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0255.html, http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html<br />
<br />
[[Category:Spec coordination|*]]<br />
[[Category:Specification editing]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Testsuite&diff=10047Testsuite2016-02-29T16:17:48Z<p>Ms2ger: </p>
<hr />
<div>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).<br />
<br />
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.<br />
<br />
In order to contribute tests to the testsuite for a WHATWG specification, follow the instructions on [http://testthewebforward.org/docs/ Test the Web Forward].<br />
<br />
== Old lists of tests that maybe have not been ported to web platform tests? ==<br />
<br />
People should prune this list...<br />
<br />
* [[Test cases]]<br />
* [http://samples.msdn.microsoft.com/ietestcenter/ IE's tests]<br />
* [http://trac.webkit.org/browser/trunk/LayoutTests (Some of?) WebKit's tests]<br />
* [http://mxr.mozilla.org/mozilla-central/find?string=test_.*%28html|svg%29%24&tree=mozilla-central&hint= Some of Mozilla's mochitests]<br />
** [[Testsuite/Mozilla]]<br />
* [http://mxr.mozilla.org/mozilla-central/find?string=reftest.list Some of Mozilla's reftests]<br />
* [http://philip.html5.org/tests/canvas/suite/tests/ Philip's canvas tests]<br />
* [http://hixie.ch/tests/adhoc/html/ Hixie's ad-hoc tests]<br />
* [http://lachy.id.au/dev/markup/tests/html5/ Lachlan's tests]<br />
* [http://hg.gsnedders.com/php-html-5-direct/file/tip/tests/numbersTest gsnedders' number parsing tests]<br />
* [http://simon.html5.org/test/html/ zcorpan's tests]<br />
* [http://mathias.html5.org/tests/ Mathias’s tests]<br />
* [http://hsivonen.iki.fi/test/moz/video-selection/ hsivonen's video tests]<br />
* [http://www.w3.org/DOM/Test/ Document Object Model (DOM) Conformance Test Suites]<br />
* <del>[https://dev.w3.org/cvsweb/2006/webapi/WindowTestSuite/ Window test suite]</del> all checked and submitted ―[[User:Ms2ger|Ms2ger]] ([[User talk:Ms2ger|talk]]) 16:17, 29 February 2016 (UTC)</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Anolis&diff=10042Anolis2016-02-25T09:51:36Z<p>Ms2ger: </p>
<hr />
<div>'''Anolis is no longer maintained. Please use [https://github.com/tabatkins/bikeshed/ bikeshed] instead.'''<br />
<br />
Anolis is a tool to generate specification-like documents out of simple HTML.<br />
<br />
* http://pimpmyspec.net/<br />
* http://hg.hoppipolla.co.uk/ -- jgraham's work<br />
* http://bitbucket.org/ms2ger/anolis -- used by most WHATWG standards, the latest version<br />
<br />
== Setting up ms2ger/anolis ==<br />
<br />
* Install http://bitbucket.org/ms2ger/anolis:<br />
hg clone http://bitbucket.org/ms2ger/anolis<br />
cd anolis && sudo python setup.py install<br />
* install lxml using whatever package manager is appropriate for your OS/environment; for example, one of the following:<br />
sudo easy_install lxml<br />
sudo port install py27-lxml<br />
sudo apt-get install python-lxml<br />
brew install libxml<br />
* install cssselect using whatever package manager is appropriate for your OS/environment; for example, one of the following:<br />
sudo easy_install cssselect<br />
sudo port install py27-cssselect<br />
sudo apt-get install python-cssselect<br />
* install html5lib:<br />
sudo easy_install html5lib<br />
<br />
== Troubleshooting ==<br />
<br />
=== No targets specified ===<br />
If you try to "make" and get a message like:<pre>make: *** No targets specified and no makefile found. Stop.</pre><br />
Then you're likely trying to do a <kbd>make</kbd> in the wrong directory.<br />
<br />
Solution: <br />
# Change your current directory to the parent of the item you're trying to make, <br />
# Verify that there is a "Makefile" in that directory, <br />
# Try again<br />
<br />
=== No rule to make xref ===<br />
If you try to "make" and get a message like:<pre>make: *** No rule to make target `../xref', needed by `Overview.html'. Stop.</pre><br />
Then you're likely missing the "xref" repository.<br />
<br />
Solution:<br />
# Clone the "xref" repository into a directory that is a sibling of the directory you're working in.<br />
# Try again<br />
<br />
=== No such option xref ===<br />
If you try to "make" and get a message like:<pre>anolis: error: no such option: --xref</pre><br />
Then your Anolis is likely out of date.<br />
<br />
Solution:<br />
# Update your Anolis respository<br />
# Update your install of the "anolis" tool, e.g. in "/usr/local/bin/anolis"<br />
# Try again<br />
<br />
=== No module named lxml ===<br />
If you try to "make" and get a message like:<pre>ImportError: No module named lxml</pre><br />
Then you're missing the lxml library.<br />
<br />
Solution:<br />
# Install lxml per the above instructions, e.g. <kbd><pre> sudo easy_install lxml</pre></kbd><br />
# Try again<br />
<br />
=== Connection reset by peer ===<br />
If you're trying to install lxml and get an error message like: <br />
<pre>Downloading http://lxml.de/files/lxml-3.1.2.tgz<br />
error: Connection reset by peer</pre><br />
Then the network you're on may be problematic.<br />
<br />
Solution:<br />
# Switch to a different network (e.g. a mifi)<br />
# Try again<br />
<br />
=== TypeError Item in from list not a string ===<br />
If you try to "make" and get messages like:<br />
<pre><br />
Traceback (most recent call last):<br />
File "/usr/local/bin/anolis", line 325, in <module><br />
main()<br />
File "/usr/local/bin/anolis", line 69, in main<br />
tree = generator.fromFile(input, **kwargs)<br />
File "/Library/Python/2.7/site-packages/anolislib/generator.py", line 90, in fromFile<br />
process(tree, processes, **kwargs)<br />
File "/Library/Python/2.7/site-packages/anolislib/generator.py", line 38, in process<br />
locals(), [process], -1),<br />
TypeError: Item in ``from list'' not a string<br />
make: *** [Overview.html] Error 1<br />
</pre><br />
Then ... (no idea)<br />
<br />
Solution:<br />
* TBD<br />
<br />
Workaround:<br />
# Give up on locally installed Anolis<br />
# Commit your Overview.src.html as is, noting in the commit message that the Overview.html was not updated<br />
# Use the http://anolis.hoppipolla.co.uk/aquarium.py web service<br />
# Submit the raw.github.com "raw file" URL of the Overview.src.html you just committed<br />
# Save the result over the Overview.html in the same directory as the Overview.src.html<br />
# Commit it with message "sync with Overview.src.html - used anolis.hoppipolla.co.uk/aquarium.py" <br />
<br />
<br />
[[Category:Spec coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=NavigatorCores&diff=9583NavigatorCores2014-05-09T16:37:47Z<p>Ms2ger: Ms2ger moved page NavigatorCores to Navigator HW Concurrency: Requested by eligrey</p>
<hr />
<div>#REDIRECT [[Navigator HW Concurrency]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Navigator_HW_Concurrency&diff=9582Navigator HW Concurrency2014-05-09T16:37:46Z<p>Ms2ger: Ms2ger moved page NavigatorCores to Navigator HW Concurrency: Requested by eligrey</p>
<hr />
<div>Proposed navigator.hardwareConcurrency API for smarter Worker pool allocation in parallel applications<br />
<br />
== Abstract ==<br />
<br />
This specification defines an API for reading the system's total number of logical processors available to the user agent.<br />
<br />
The intended use for the API is to help developers make informed decisions regarding the size of their worker threadpools to perform parallel algorithms.<br />
<br />
Developers can easily take advantage of this in existing parallel applications implemented with web workers by replacing code that does <code>workers = #</code> with <code>workers = navigator.hardwareConcurrency || #</code> in order to split up parallel tasks between every logical core. The OS or UA scheduler will handle balancing the load of these threads with everything else on the system.<br />
<br />
Currently, highly parallel algorithms must prompt the user for how many cores they have, but many users don't know this information or understand where to get it. Giving users control over thread count can also cause issues where the user thinks the highest option is best. For example, this can result in 32 threads being run on a user's dual core laptop.<br />
<br />
== Example use cases ==<br />
<br />
* Image processing in online photo editors is highly parallelizable but often hardcoded to a specific worker count. For example, [http://www.sitepoint.com/using-web-workers-to-improve-image-manipulation-performance/ this recent blog post] on image processing with worker threads in JavaScript suggests hardcoding the worker count to 4. All the author has to do to is replace the 4 with <code>navigator.hardwareConcurrency || 4</code> to increase performance in computers with more cores.<br />
<br />
* Using LZMA2 in JavaScript with as many cores as possible to compress data faster without having to prompt the user for their core count.<br />
<br />
* Physics engines for WebGL games: Many physics engines are highly parallelizable, but currently there is no method to determine how many threads to use without prompting the user for their core count.<br />
<br />
* Running realtime object/face/movement/etc. detection algorithms efficiently on webcam input or video file input, without prompting the user for their core count.<br />
<br />
* Multithreaded silent OCR: A current attempt at automatic silent OCR is http://projectnaptha.com/ (single-threaded). If Project Naptha is ever going to use the multithreaded Ocrad mode to increase performance, it must currently prompt the user for a core count. This defeats the purpose of a silent background processing script by interrupting the user with a prompt.<br />
<br />
* Anything else highly parallelizable, such as raytracer webapps like http://tech.pusherhq.com/demo/raytracer_workers<br />
<br />
== API ==<br />
<br />
On getting, the <code>hardwareConcurrency</code> property should return the number of logical processors available to the user agent. For example on OS X this should be equivalent to running sysctl -n hw.availcpu<br />
<br />
The number must be >= 1.<br />
<br />
'''WebIDL'''<br />
<pre><br />
[NoInterfaceObject, Exposed=Window,Worker]<br />
interface NavigatorCPU {<br />
readonly attribute unsigned long hardwareConcurrency;<br />
};<br />
<br />
Navigator implements NavigatorCPU;<br />
WorkerNavigator implements NavigatorCPU;<br />
</pre><br />
<br />
== Privacy considerations ==<br />
<br />
The user agent MAY report fewer than the number of actual logical cores to reduce the efficacy of fingerprinting.<br />
<br />
The total number of cores available to the user agent can already be approximated with high accuracy given enough time using the polyfill in the appendix on a system with low to moderate system load. Chrome also exposes it through PNaCl.<br />
<br />
== Appendix ==<br />
<br />
An open source O(log n) (in the number of cores) polyfill in JavaScript can be found at:<br />
<br />
:https://github.com/oftn/core-estimator<br />
<br />
The polyfill works by running a timing attack on the measured runtime of a worker threadpool that is resized according to a binary search and statistical analysis results until performance no longer increases with the number of threads.<br />
<br />
The [https://github.com/oftn/core-estimator/blob/cc56e924e450554d4f4c7e1d42e53a42a7633bb2/core-estimator.js#L16-L20 default configuration] is tuned for medium accuracy in order to finish the estimation in a timely manner. If you care about accuracy more than runtime length, increase the workload as you see fit.<br />
<br />
[[Category:Proposals]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=W3C&diff=9432W3C2014-01-14T08:27:30Z<p>Ms2ger: </p>
<hr />
<div>This is a list of cases where publication of specs on the TR/ page hurt.<br />
<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=688878<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=505115#c141<br />
* When designing the Fullscreen/<dialog> stacking model, the lack of a living standard spec for CSS that represented the current cutting edge status meant that features of CSS that were may have been overridden by one spec (e.g. CSS regions) were used by the proposal, without the implications being understood. (Specifically, it was suggested that CSS regions redefined how the containing block mechanism works; in general, without knowing what all the relevant specs are, there is no way to be sure that no other spec does in fact modify some underlying concept.)<br />
* http://www.w3.org/mid/4F695058.8040105@mit.edu<br />
* https://critic.hoppipolla.co.uk/showcomment?chain=1232</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs/advice&diff=9117Specs/advice2013-05-09T07:04:28Z<p>Ms2ger: added Category:Specification editing using HotCat</p>
<hr />
<div>* Bureaucracy is opt-in. You don't have to do any of the bureaucracy involved in the W3C process if you don't want to, regardless of what other people will say. (e.g. Hixie, as editor of the HTML spec and others at the W3C, does not do any of the non-productive bureaucracy of going through the TR process.)<br />
<br />
* The only thing that truly matters is getting documentation that defines what implementations are to do in order for multiple independent vendors to reach interoperability without having to reverse-engineer each other.<br />
<br />
* Think of specifications as being software. The programming language is English, and the compilers are engineers (and the compile times are high, the compiler tends to have its own opinions about what you are programming, and it talks back to you, but that's just a detail).<br />
<br />
* Just like with real software, you have to have clear statements. Think of "must" as the equivalent of an imperative statement in code. Think of defining terms as being like defining constants or functions in code. Think of *everything else* as being like comments. This means that if you don't have a "must" statement somewhere requiring something, then it's not required! It also means that if you have _two_ "must" statements requiring the same thing, it's like requiring it twice. See also http://ln.hixie.ch/?start=1140242962&count=1<br />
<br />
* The specification has to match reality. If there are multiple implementations that do something and the spec says something else, the spec is wrong.<br />
<br />
-- <br />
Ian Hickson<br />
<br />
[[Category:Specification editing]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs/todo&diff=9116Specs/todo2013-05-09T07:02:17Z<p>Ms2ger: added Category:Specification editing using HotCat</p>
<hr />
<div>There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch, post on the WHATWG mailing list or say something on [[IRC]].<br />
<br />
See also: [[Specs|Specs with editors]], [[Howto spec]].<br />
<br />
== Platform ==<br />
<br />
* A specification that defines how XML maps to DOM Core. (I think this should be in DOM Parsing and Serialization. Well really in XML.)<br />
* X-Frames-Options (seems this is going into CSP)<br />
* multipart/form-data<br />
* HTTP (error handling in particular)<br />
* APNG (other image formats too maybe?)<br />
* HTML editing: the spec is quite mature, but needs more work<br />
<br />
== APIs ==<br />
<br />
* User Interaction Events (onclick, onkeypress, etc).<br />
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus<br />
** setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]<br />
** [http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1719 selectstart] (WebKit/IE)<br />
* An API for cryptography, to generate keys and the like<br />
* The console.* API. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694] [http://www.w3.org/mid/d7be01cb7077$4dd45010$e97cf030$@gmail.com] [http://sideshowbarker.github.com/console-spec/]<br />
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html<br />
* [[DOM XPath]]<br />
<br />
== CSS ==<br />
<br />
There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:<br />
* Table Layout<br />
** http://dbaron.org/css/intrinsic/<br />
** http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm<br />
* Replaced Content<br />
** http://dev.w3.org/csswg/css3-content/ (Do we still want this or is the component model sufficient?)<br />
* an imperative model of box-tree construction<br />
* hit testing per http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html<br />
<br />
== Registries ==<br />
<br />
Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:<br />
<br />
* MIME types<br />
* Schemes<br />
<br />
It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).<br />
<br />
See also: [[Registries]]<br />
<br />
== MISC ==<br />
* an API to do syntax highlighting on &lt;textarea>, &lt;pre>, and contenteditable sections would be highly popular with Web developers (ack Ryan Johnson). (This would probably best be done as some sort of output filter at the CSS level, rather than anything HTML-specific.)<br />
* Animated GIFs need a spec that, in particular, specifies how to handle timings (not all browsers honour all values, so we should specify what needs to be honoured exactly)<br />
** GIF87a: [http://web.archive.org/web/20100929230301/http://www.etsimo.uniovi.es/gifanim/gif87a.txt Text] (Stanford) / [http://www.w3.org/Graphics/GIF/spec-gif87.txt Text] (W3C)<br />
** GIF89a: [http://www.w3.org/Graphics/GIF/spec-gif89a.txt Text] / [http://odur.let.rug.nl/~kleiweg/gif/GIF89a.html HTML]<br />
** [http://www.matthewflickinger.com/lab/whatsinagif/ What's in a GIF]<br />
** [http://odur.let.rug.nl/~kleiweg/gif/netscape.html GIF Application Extension: NETSCAPE2.0]<br />
** [http://www.theimage.com/animation/toc/toc.html Gifology: Understanding GIF Files & GIF Animation]<br />
** [http://web.archive.org/web/20100929231133/http://www.etsimo.uniovi.es/gifanim/gifabout.htm All About GIF89a]<br />
* Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/20101101063413.bf1d8102.eric@bisonsystems.net)<br />
* innerText and outerText, if browsers don't remove them entirely<br />
<br />
== Other stuff ==<br />
<br />
http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has a description of some sections that needed editing in 2008 and how much work they would be.<br />
<br />
Some notes from the HTML5 spec about things that need doing:<br />
<br />
* support access Array element via () instead of [] (IEism) https://bugzilla.mozilla.org/show_bug.cgi?id=289876<br />
* Need to say that NodeList's items are enumerable, so that... for (var x in myNodeList) { } ...works. (ack Dethe Elza)<br />
* a way to show icons for file types e.g. http://www.gadgetopia.com/2004/05/04/FileIconTag.html (this should probably be a function for the 'content', 'background-image' and 'list-style-image' properties in CSS)<br />
** Maybe something like moz-icon://? http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0255.html, http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html<br />
<br />
[[Category:Spec_coordination]]<br />
[[Category:Specification editing]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs/howto&diff=9115Specs/howto2013-05-09T06:59:54Z<p>Ms2ger: added Category:Specification editing using HotCat</p>
<hr />
<div>== About this document ==<br />
<br />
This document explains basic guidelines for writing a specification for the web platform. [http://www.whatwg.org/C HTML] and [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM] among others follow these guidelines. You are encouraged to study those specifications and follow the patterns and style they establish.<br />
<br />
See also [[Advice for people writing specs]].<br />
<br />
== Audience ==<br />
<br />
This document focuses primarily on specifications aimed at browser implementors. The content of these specifications focuses on API calls that browsers implement and the required browser behavior under all possible cases. Specifications for user interface design and for authored content are not addressed here.<br />
<br />
== Organization ==<br />
<br />
Each specification includes these top-level sections:<br />
<br />
* '''Introduction''' — Gives an overview of the technology defined.<br />
* '''Conformance''' — References [http://tools.ietf.org/html/rfc2119 RFC 2119] and/or explains how conformance is determined in this specification. Lists the conformance classes that apply to this specification. See http://www.w3.org/TR/qaframe-spec/<br />
* '''Terminology''' — Defines where the terms in the specification originate from and sometimes provides a few novel definitions that do not fit within the main prose of the specification.<br />
* &hellip; content &hellip;<br />
* '''References'''<br />
* '''Acknowledgments'''<br />
<br />
See e.g. [http://dev.w3.org/2006/webapi/progress/ Progress Events] and [http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ XMLHttpRequest].<br />
<br />
== Content ==<br />
<br />
Content in a specification falls into two general categories: ''normative'' and ''informative''. ''Normative'' content includes the requirements and definitions and uses verbs such as ''must'', ''should'', and ''may''. Refer to [http://tools.ietf.org/html/rfc2119 RFC 2119] for their definitions. If a normative statement uses the verb ''must'' (and applies to UAs), the browser implementor should be able to write a test case for it. (If it is not possible to write a test case for the statement, do not use the word ''must''.) The verb "may" merely grants permission and is used rarely. Do not use "may not". Normal lowercase is preferred for readability.<br />
<br />
''Informative'' content is everything that is not normative. Informative (non-normative) content includes diagrams and code examples&mdash;very useful content, but supportive in nature to the actual browser requirements. Informative content must not include RFC 2119 keywords (use words like "can" or "is" instead).<br />
<br />
See also Hixie's blog post on the subject: http://ln.hixie.ch/?start=1140242962&count=1<br />
<br />
=== Definitions ===<br />
<br />
Elements, attributes, members of an object, algorithms, are all marked up using the <code>dfn</code> element. The <code>title</code> attribute of the element or its contents if there is no such attribute represents the name used for cross references. These are the conventions:<br />
<br />
* '''Interfaces:''' InterfaceName; e.g. <code>interface <dfn>Document</dfn> { &hellip;</code><br />
* '''Interface members:''' dom-InterfaceName-attributeOrMethodName; e.g. the <code><dfn title=dom-Document-URL><code>URL&lt;/code></dfn></code> attribute must &hellip;<br />
* '''Events:''' event-eventname<br />
* '''Elements:''' elementname<br />
* '''Attributes:''' attr-elementname-attributename<br />
* '''Concepts:''' concept-word; e.g. <code>&lt;dfn title=concept-node>node&lt;/dfn></code><br />
<br />
You reference a definition using either the <code>span</code> or <code>code</code> element. [[Anolis]] takes care of linking back to the definition.<br />
<br />
=== IDL ===<br />
<br />
The structure of an API is defined using [http://dev.w3.org/2006/webapi/WebIDL/ Web IDL]. An interface can be defined as follows:<br />
<br />
&lt;pre class=idl>interface &lt;dfn>ProcessingInstruction&lt;/dfn> : &lt;span>Node&lt;/span> {<br />
readonly attribute DOMString &lt;span title=dom-ProcessingInstruction-target>target&lt;/span>;<br />
attribute DOMString &lt;span title=dom-ProcessingInstruction-data>data&lt;/span>;<br />
};&lt;/pre><br />
<br />
(See also [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#processinginstruction <code>ProcessingInstruction</code>] in DOM Core.)<br />
<br />
The interface members are described both in a non-normative and a normative way. Non-normatively using a <code>&lt;dl class=domintro></code> construct. Normatively as described in the following sections.<br />
<br />
===Defining an attribute===<br />
<br />
A readonly attribute is defined as follows:<br />
<br />
The &lt;dfn>&lt;code>novel&lt;/code>&lt;/dfn> attribute must return "&lt;code>Hear the Wind Sing&lt;/code>".<br />
<br />
An attribute whose value can be set is typically defined as two distinct definitions:<br />
<br />
The &lt;dfn>&lt;code>pinball&lt;/code>&lt;/dfn> attribute must return its value. Initially its value must be null.<br />
<br />
Setting the &lt;code>pinball&lt;/code> attribute must set its value to the given value.<br />
<br />
Sometimes it gets a little bit more complicated and you need to use steps:<br />
<br />
&lt;p>Setting the &lt;code>pinball&lt;/code> attribute must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>If the &lt;span>readonly flag&lt;/span> is set, terminate these steps.<br />
&lt;li>&lt;p>Set the attribute to the given value.<br />
&lt;/ol><br />
<br />
Keep this in mind:<br />
<br />
* Include requirements for setting the attribute to ''any'' value, not just to valid values. For example, an attribute that requires a float value must also prescribe what the browser does when the value is set to values of Infinity, zero, or NaN (not a number), unless that is already defined by IDL.<br />
<br />
* You can omit the "must" statement here for each step (as in the example above) if your conformance section says it is implied. The HTML spec, for example, says in its conformance section that "Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm".<br />
<br />
===Defining a method===<br />
<br />
Defining a simple method can be done as follows:<br />
<br />
The &lt;dfn>&lt;code>timesTwo(&lt;var>num&lt;/var>)&lt;/code>&lt;/dfn> method must return &lt;var>num&lt;/var> &times; 2.<br />
<br />
If the method is more complicated (or you feel like being more verbose) a list of steps can be used instead:<br />
<br />
&lt;p>The &lt;dfn>&lt;code>add(&lt;var>num1&lt;/var>, &lt;var>num2&lt;/var>)&lt;/code>&lt;/dfn> method must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>Let &lt;var>result&lt;/var> be &lt;var>num1&lt;/var> + &lt;var>num2&lt;/var>.<br />
&lt;li>&lt;p>Return &lt;var>result&lt;/var>.<br />
&lt;/ol><br />
<br />
Using steps helps implementors and QA making sure they have covered all the requirements.<br />
<br />
===Dealing with exceptions===<br />
<br />
Sometimes a method needs to throw an exception:<br />
<br />
&lt;p>The &lt;dfn>&lt;code>isCuteAnimal(&lt;var>animal&lt;/var>)&lt;/code>&lt;/dfn> method must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>If &lt;var>animal&lt;/var> is not "&lt;code>cat&lt;/code>",<br />
&lt;span data-anolis-spec=dom title=concept-throw>throw&lt;/span> an "&lt;code>UnknownAnimalError&lt;/code>" exception<br />
and terminate these steps.<br />
<br />
It is important to state whether the algorithm should be terminate when the exception is thrown or not; in some cases, an algorithm will continue even after an exception is thrown (e.g. to do some cleanup).<br />
<br />
===Events===<br />
<br />
Just dispatching an event is rather trivial:<br />
<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=dom>Fire an event&lt;/span> named &lt;code>tralala&lt;/code><br />
at the &lt;span data-anolis-spec=dom title=concept-document>document&lt;/span>.<br />
<br />
However, often the situation is more complicated. Events may need to be dispatched from within a [http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task task] (see asynchronous below), listeners for the event can change the environment, events may need their own event object (to expose certain attributes), etc.<br />
<br />
====Asynchronous events====<br />
<br />
In certain circumstances the method returns "early", but the algorithm keeps going. This is done to ensure that the user interface does not lock up while running potentially expensive operations:<br />
<br />
&lt;li>&lt;p>Return, but continue running these steps asynchronouusly.<br />
&lt;li>&lt;p>Let &lt;var>visible&lt;/var> be the number of cute animals in the user's surroundings.<br />
&lt;li>&lt;p>If &lt;var>visible&lt;/var> is zero, terminate these steps.<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=html>Queue&lt;/span> a &lt;span data-anolis-spec=html>task&lt;/span><br />
to &lt;span data-anolis-spec=dom>fire an event&lt;/span> named &lt;code>spotted&lt;/code> at the<br />
&lt;span>context object&lt;/span>.<br />
<br />
To still let the developer know of the effects of the method an event has to be dispatched. This is done using the "fire an event" concept from the DOM. As it cannot be dispatched synchronously since it happens in an operation running asynchronously from JavaScript's perspective, the event loop has to be used (queuing a task).<br />
<br />
===="Cancelable" events====<br />
<br />
Certain events are dispatched as part of an operation and allow the developer to choose whether to continue running the operation. These are often referred to as "cancelable events" (although actually the operation is cancelable). You can integrate these as follows:<br />
<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=dom>Fire an event&lt;/span> named &lt;code>hanginthere&lt;/code> <br />
at the &lt;span>context object&lt;/span>.<br />
&lt;li>&lt;p>If the event's &lt;span>canceled flag&lt;/span> is set, terminate these steps.<br />
&lt;li>&lt;p>&hellip; eat all the things &hellip;<br />
<br />
====Events implementing their own interface====<br />
<br />
Often events are not just about notification, but also carry additional information. To make that work you will need to define your own event interface.<br />
<br />
&lt;pre class=idl>[Constructor(DOMString &lt;var>type&lt;/var>, optional &lt;span>PonyEventInit&lt;/span> &lt;var>eventInitDict&lt;/var>)]<br />
interface &lt;dfn>PonyEvent&lt;/dfn> : &lt;span data-anolis-spec=dom>Event&lt;/span> {<br />
readonly attribute DOMString &lt;span title=dom-PonyEvent-hairColor>hairColor&lt;/span>;<br />
};<br />
<br />
dictionary &lt;dfn>PonyEventInit&lt;/dfn> {<br />
DOMString hairColor;<br />
};&lt;/pre><br />
<br />
&lt;p>The &lt;dfn title=dom-PonyEvent-hairColor>&lt;code>hairColor&lt;/code>&lt;/dfn> attribute must<br />
return the value it was initialized to. When an <br />
&lt;span data-anolis-spec=dom title=concept-event>event&lt;/span> is created it must be<br />
initialized to "&lt;code>rainbow&lt;/code>".<br />
<br />
Defining the constructor is "magically" taken care of by the [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events constructing events] chapter of DOM. Dispatching an event implementing its own interface requires a bit more wording as well. See the [http://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html#concept-event-fire-progress "fire a progress event named e"] for an example.<br />
<br />
====Event handler attributes====<br />
<br />
HTML defines [http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#events event handlers]. Introducing these on objects upon which events are dispatched is common practice. Excluding markup, the IDL for adding a "colorchange" event's handler would be:<br />
<br />
attribute EventHandler oncolorchange;<br />
<br />
In prose you use the following language (replacing "Pony" with the name of the interface and "colorchange" with the name of the event):<br />
<br />
&lt;p>The following are the &lt;span data-anolis-spec=html>event handlers&lt;/span> (and their corresponding <br />
&lt;span data-anolis-spec=html title="event handler event type">event handler event types&lt;/span>) that must <br />
be supported on objects implementing the &lt;code>Pony&lt;/code> interface:<br />
<br />
&lt;table><br />
&lt;thead><br />
&lt;tr><br />
&lt;th>&lt;span data-anolis-spec=html title="event handler">event handler&lt;/span><br />
&lt;th>&lt;span data-anolis-spec=html>event handler event type&lt;/span><br />
&lt;tbody><br />
&lt;tr><br />
&lt;td>&lt;dfn title="event-colorchange">&lt;code>oncolorchange&lt;/code>&lt;/dfn><br />
&lt;td>&lt;code>colorchange&lt;/code><br />
&hellip;<br />
<br />
===Callbacks===<br />
<br />
&lt;p>The &lt;dfn>&lt;code>getInspiration(&lt;var>callback&lt;/var>)&lt;/code>&lt;/dfn> method must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>Return, but continue running these steps asynchronously.<br />
&lt;li>&lt;p>Let &lt;var>result&lt;/var> be the result of running &lt;span>magic&lt;/span>.<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=html>Queue&lt;/span> a &lt;span data-anolis-spec=html>task&lt;/span><br />
to invoke &lt;var>callback&lt;/var> with &lt;var>result&lt;/var> as argument and &lt;span>context object&lt;/span><br />
as &lt;span>callback this value&lt;/span>.<br />
<br />
Note that here we define the object the method was invoked upon as the [http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-this-value callback this value]. If you want the callback object itself to the this value you do not have to specify it, as that is the default.<br />
<br />
When dealing with the event loop (task queuing) the task source also needs to be clear. See &lt;canvas>'s [http://www.whatwg.org/C#dom-canvas-toblob toBlob()] method for an example.<br />
<br />
== References ==<br />
<br />
The following references provide useful information about specification writing and tools to aid the process of writing and producing a specification.<br />
<br />
* '''Language and terminology:''' [http://www.ietf.org/rfc/rfc2119.txt RFC2119]. This document explains when and why to use those spec'y verbs like ''must'', ''may'', and ''should''.<br />
* '''Interface definitions:''' [http://dev.w3.org/2006/webapi/WebIDL/ Web IDL]. This document defines an interface definition language (IDL) that is useful for describing interfaces intended to be implemented in web browsers. It defines how to write the IDL blocks, how to overload methods, and the basics of common JavaScript bindings. This standard format helps to streamline the definitions for common script objects and allows the spec to focus on defining the unique aspects of the requirements.<br />
* '''Formatting tool: '''[[Anolis]]. This irreverently named tool defines special markup elements that are processed by a Python script that adds the proper spec numbering, cross references, and table of contents. It's magic! [http://hg.gsnedders.com/anolis/raw-file/tip/example.src.html This page] demonstrates use of the prescribed markup elements.<br />
* '''Also useful:''' [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]. It's always good to keep the Big Picture in mind.<br />
<br />
== More ==<br />
<br />
Here are some links to sources that might be helpful in expanding the above:<br />
<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032361.html<br />
<br />
== Legacy DOM-style ==<br />
<br />
The old DOM specifications had a particular style of defining methods and attributes that is strongly discouraged (the separation of method definition from arguments, exceptions, and return value). Unfortunately ReSpec.js uses this style by default (consider using [[Anolis]]). E.g. the [http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-adoptNode <code>adoptNode()</code> method] in DOM Level 3 Core does not define which exception would be thrown first and more importantently it is not clear at all what the processing model is as you have to piece it together from various independent pieces of information. Therefore please follow the patterns outlined above as demonstrated by the [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-adoptnode <code>adoptNode()</code> method] in DOM.<br />
<br />
[[Category:Specification editing]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_XPath&diff=9062DOM XPath2013-03-06T18:12:37Z<p>Ms2ger: Add some more</p>
<hr />
<div>If someone ever decides to write down DOM XPath (i.e. a proper version of the [http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html DOM3XPath note]), take this into account:<br />
<br />
* Integrate the XPath part of the section [http://www.whatwg.org/C#interactions-with-xpath-and-xslt Interactions with XPath and XSLT] from HTML.<br />
* Make it clear that contrary to XPath 1.0 multiple Text nodes can indeed be returned, even if they are siblings. The DOM is not the XML InfoSet. (As is the case in WebKit and Gecko today.)<br />
* Simplifications: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0310.html<br />
* Exceptions: https://bugzilla.mozilla.org/show_bug.cgi?id=743888<br />
<br />
== WebIDL interfaces ==<br />
<pre><br />
interface XPathResult {<br />
const unsigned short ANY_TYPE = 0;<br />
const unsigned short NUMBER_TYPE = 1;<br />
const unsigned short STRING_TYPE = 2;<br />
const unsigned short BOOLEAN_TYPE = 3;<br />
const unsigned short UNORDERED_NODE_ITERATOR_TYPE = 4;<br />
const unsigned short ORDERED_NODE_ITERATOR_TYPE = 5;<br />
const unsigned short UNORDERED_NODE_SNAPSHOT_TYPE = 6;<br />
const unsigned short ORDERED_NODE_SNAPSHOT_TYPE = 7;<br />
const unsigned short ANY_UNORDERED_NODE_TYPE = 8;<br />
const unsigned short FIRST_ORDERED_NODE_TYPE = 9;<br />
<br />
readonly attribute unsigned short resultType;<br />
readonly attribute unrestricted double numberValue;<br />
// Maybe "DOMString?".<br />
readonly attribute DOMString stringValue;<br />
readonly attribute boolean booleanValue;<br />
readonly attribute Node singleNodeValue;<br />
readonly attribute boolean invalidIteratorState;<br />
readonly attribute unsigned long snapshotLength;<br />
Node? iterateNext();<br />
Node? snapshotItem(unsigned long index);<br />
};<br />
<br />
[Constructor]<br />
interface XPathEvaluator {<br />
XPathExpression createExpression(DOMString expression, <br />
XPathNSResolver? resolver);<br />
XPathNSResolver createNSResolver(Node? nodeResolver);<br />
XPathResult evaluate(DOMString expression, <br />
Node? contextNode, <br />
XPathNSResolver? resolver, <br />
unsigned short type, <br />
object? result);<br />
};<br />
Document implements XPathEvaluator;<br />
</pre><br />
<br />
Indeed, you can both construct this object and access its methods on Document. Isn't the world wonderful?<br />
<br />
[[Category:Spec coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_XPath&diff=8848DOM XPath2012-11-29T08:48:00Z<p>Ms2ger: Make stuff nullable</p>
<hr />
<div>If someone ever decides to write down DOM XPath (i.e. a proper version of the [http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html DOM3XPath note]), take this into account:<br />
<br />
* Integrate the XPath part of the section [http://www.whatwg.org/C#interactions-with-xpath-and-xslt Interactions with XPath and XSLT] from HTML.<br />
* Make it clear that contrary to XPath 1.0 multiple Text nodes can indeed be returned, even if they are siblings. The DOM is not the XML InfoSet. (As is the case in WebKit and Gecko today.)<br />
* Simplifications: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0310.html<br />
* Exceptions: https://bugzilla.mozilla.org/show_bug.cgi?id=743888<br />
<br />
== WebIDL interfaces ==<br />
<pre><br />
[Constructor]<br />
interface XPathEvaluator {<br />
XPathExpression createExpression(DOMString expression, <br />
XPathNSResolver? resolver);<br />
XPathNSResolver createNSResolver(Node? nodeResolver);<br />
object evaluate(DOMString expression, <br />
Node? contextNode, <br />
XPathNSResolver? resolver, <br />
unsigned short type, <br />
object? result);<br />
};<br />
Document implements XPathEvaluator;<br />
</pre><br />
<br />
Indeed, you can both construct this object and access its methods on Document. Isn't the world wonderful?<br />
<br />
[[Category:Spec coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_XPath&diff=8502DOM XPath2012-09-22T13:56:02Z<p>Ms2ger: Add interface for XPathEvaluator, in particular for the constructor</p>
<hr />
<div>If someone ever decides to write down DOM XPath (i.e. a proper version of the [http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html DOM3XPath note]), take this into account:<br />
<br />
* Integrate the XPath part of the section [http://www.whatwg.org/C#interactions-with-xpath-and-xslt Interactions with XPath and XSLT] from HTML.<br />
* Make it clear that contrary to XPath 1.0 multiple Text nodes can indeed be returned, even if they are siblings. The DOM is not the XML InfoSet. (As is the case in WebKit and Gecko today.)<br />
* Simplifications: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0310.html<br />
* Exceptions: https://bugzilla.mozilla.org/show_bug.cgi?id=743888<br />
<br />
== WebIDL interfaces ==<br />
<pre><br />
[Constructor]<br />
interface XPathEvaluator {<br />
XPathExpression createExpression(DOMString expression, <br />
XPathNSResolver resolver);<br />
XPathNSResolver createNSResolver(Node nodeResolver);<br />
object evaluate(DOMString expression, <br />
Node contextNode, <br />
XPathNSResolver resolver, <br />
unsigned short type, <br />
object result);<br />
};<br />
</pre><br />
<br />
[[Category:Spec coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_XPath&diff=8096DOM XPath2012-04-10T09:16:03Z<p>Ms2ger: Add pointers</p>
<hr />
<div>If someone ever decides to write down DOM XPath (i.e. a proper version of the [http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html DOM3XPath note]), take this into account:<br />
<br />
* Integrate the XPath part of the section [http://www.whatwg.org/C#interactions-with-xpath-and-xslt Interactions with XPath and XSLT] from HTML.<br />
* Make it clear that contrary to XPath 1.0 multiple Text nodes can indeed be returned, even if they are siblings. The DOM is not the XML InfoSet. (As is the case in WebKit and Gecko today.)<br />
* Simplifications: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0310.html<br />
* Exceptions: https://bugzilla.mozilla.org/show_bug.cgi?id=743888<br />
<br />
[[Category:Spec coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_features&diff=8094DOM features2012-04-06T10:29:21Z<p>Ms2ger: Add more Gecko</p>
<hr />
<div>{| class=wikitable<br />
|-<br />
! Feature || Version || Specification || IE8 || Gecko || WebKit || Presto<br />
|-<br />
| XML || 1.0 || Web DOM Core || N || Y || Y || ?<br />
|-<br />
| XML || 2.0 || Web DOM Core || N || Y || Y || ?<br />
|-<br />
| Core || 1.0 || || N || N || Y || ?<br />
|-<br />
| Core || 2.0 || Web DOM Core || N || Y || Y || ?<br />
|-<br />
| HTML || 1.0 || HTML || Y || Y || Y || ?<br />
|-<br />
| HTML || 2.0 || HTML || N || Y || Y || ?<br />
|-<br />
| XHTML || 1.0 || HTML || N || N || Y || ?<br />
|-<br />
| XHTML || 2.0 || HTML || N || Y || Y || ?<br />
|-<br />
| Views || 2.0 || DOM2VIEWS || N || Y || Y || ?<br />
|-<br />
| StyleSheets || 2.0 || DOM2STYLE || N || Y || Y || ?<br />
|-<br />
| CSS || 2.0 || DOM2STYLE || N || Y || Y || ?<br />
|-<br />
| CSS2 || 2.0 || DOM2STYLE || N || Y || Y || ?<br />
|-<br />
| Events || 2.0 || DOM3EVENTS || N || Y || Y || ?<br />
|-<br />
| Events || 3.0 || DOM3EVENTS || N || N || N || ?<br />
|-<br />
| Events.* || 3.0 || DOM3EVENTS || N || N || N || ?<br />
|-<br />
| UIEvents || 2.0 || DOM2EVENTS || N || Y || Y || ?<br />
|-<br />
| MouseEvents || 2.0 || DOM2EVENTS || N || Y || Y || ?<br />
|-<br />
| MutationEvents || 2.0 || DOM2EVENTS || N || N || Y || ?<br />
|-<br />
| HTMLEvents || 2.0 || DOM2EVENTS || N || Y || Y || ?<br />
|-<br />
| MouseScrollEvents || 2.0 || || N || Y || N || ?<br />
|-<br />
| Range || 2.0 || DOM2T-RANGE || N || Y || Y || ?<br />
|-<br />
| Traversal || 2.0 || DOM2T-RANGE || N || N || Y || ?<br />
|-<br />
| XPath || 3.0 || DOM3XPATH (N) || N || Y || Y || ?<br />
|-<br />
| TextEvents || 3.0 || ? || N || N || Y || ?<br />
|-<br />
| Selectors-API || 1.0 || Selector API || N || N || N || ?<br />
|-<br />
| SVGEvents || 1.0 || || ? || Y || ? || ?<br />
|-<br />
| SVGEvents || 1.1 || || ? || Y || ? || ?<br />
|-<br />
| SVGZoomEvents || 1.0 || || ? || Y || ? || ?<br />
|-<br />
| SVGZoomEvents || 1.1 || || ? || Y || ? || ?<br />
|-<br />
| TimeControl || 1.0 || || ? || Y || ? || ?<br />
|-<br />
| colspan=7 class=XXX | SVG & SMIL URL / reverse URLS: see http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGFeaturesList.h<br />
|}<br />
<br />
[[Category:Registries]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Crypto&diff=8077Crypto2012-03-27T14:55:59Z<p>Ms2ger: Add link</p>
<hr />
<div>'''The specification for the <code>window.crypto</code> API can now be found [https://dvcs.w3.org/hg/domcrypt/raw-file/tip/Overview.html at the W3C].'''<br />
<br />
==Overview==<br />
<br />
This document describes a proposal for the window.crypto API.<br />
<br />
==Definitions==<br />
<br />
===Cryptographically Random Values===<br />
<br />
A <b id=concept-cryptographically-random-values title=concept-cryptographically-random-values>cryptographically random value</b> is a value generated from a cryptographically strong pseudo-random number generator seeded with truly random values. In practice, implementations should generate cryptographically random values using well-established cryptographic pseudo-random number generators, such as RC4, seeded with high-quality entropy, such as from an operating-system entropy source (e.g., ''/dev/urandom''). This document provides no lower-bound on the information theoretic entropy present in cryptographically random values, but implementations should make a best effort to provide as much entropy as practicable.<br />
<br />
==Interface <code title>Crypto</code>==<br />
<br />
<pre>interface Crypto {<br />
ArrayBufferView getRandomValues(in ArrayBufferView array);<br />
};<br />
<br />
partial interface Window {<br />
readonly attribute Crypto crypto;<br />
};</pre><br />
<br />
The <b id=dom-Crypto-getRandomValues title=dom-Crypto-getRandomValues><code>getRandomValues(<var>array</var>)</code></b> must run the following steps:<br />
# <var>array</var> is an [http://www.khronos.org/registry/typedarray/specs/latest/#6 ArrayBufferView]. If <var>array</var> is not of an integer type (i.e., Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, or Uint32Array), [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw throw] a [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#typemismatcherror TypeMismatchError] and abort these steps.<br />
# If <var>array</var>'s length is greater than 65536, [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw throw] a [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#quotaexceedederror QuotaExceededError] and abort these steps.<br />
# Overwrite all elements of <var>array</var> with [[#concept-cryptographically-random-values|cryptographically random values]] of the appropriate type.<br />
# Return <var>array</var>.<br />
<br />
[[Category:Proposals]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Web_ECMAScript&diff=7821Web ECMAScript2011-12-07T18:47:26Z<p>Ms2ger: /* Date */ Add todo</p>
<hr />
<div>This page is for documenting the differences between the ES5 draft and the requirements for ECMAScript implementations in web browsers.<br />
<br />
== Identifiers ==<br />
<br />
(this is very rough)<br />
<br />
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.<br />
<br />
== 15.5.4 Properties of the String Prototype Object ==<br />
<br />
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):<br />
<br />
Algorithm ToHTMLTag(tag_name, content, attribute_name, attribute_value):<br />
#if attribute_name is undefined return "<" + tag_name + ">" + content + "</" + tag_name + ">"<br />
#otherwise return "<" + tag_name + " " + attribute_name + "=\"" + attribute_value + "\">" + content + "</" + tag_name + ">"<br />
<br />
=== String.prototype.anchor(name) ===<br />
<br />
# Let content be ToString(this)<br />
# Let attribute_value be ToString(name)<br />
# Return ToHTMLTag("a", content, "name", attribute_value)<br />
<br />
=== String.prototype.big() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("big", content)<br />
<br />
=== String.prototype.blink() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("blink", content)<br />
<br />
=== String.prototype.bold() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("b", content)<br />
<br />
=== String.prototype.fixed() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("tt", content)<br />
<br />
=== String.prototype.fontcolor(color) ===<br />
<br />
# Let content be ToString(this)<br />
# Let attribute_value be ToString(color)<br />
# Return ToHTMLTag("font", content, "color", attribute_value)<br />
<br />
=== String.prototype.fontsize(size) ===<br />
<br />
# Let content be ToString(this)<br />
# Let attribute_value be ToString(size)<br />
# Return ToHTMLTag("font", content, "size", attribute_value)<br />
<br />
=== String.prototype.italics() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("i", content)<br />
<br />
=== String.prototype.link(href) ===<br />
<br />
# Let content be ToString(this)<br />
# Let attribute_value be ToString(href)<br />
# Return ToHTMLTag("a", content, "href", attribute_value)<br />
<br />
=== String.prototype.small() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("small", content)<br />
<br />
=== String.prototype.strike() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("strike", content)<br />
<br />
=== String.prototype.sub() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("sub", content)<br />
<br />
=== String.prototype.sup() ===<br />
<br />
# Let content be ToString(this)<br />
# Return ToHTMLTag("sup", content)<br />
<br />
== RegExp ==<br />
<br />
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)<br />
<br />
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.<br />
<br />
RegExp.prototype.compile changes the regexp in place. In Carakan/Nitro/V8 the method returns undefined; in SpiderMonkey it returns the regexp object.<br />
<br />
== Date ==<br />
<br />
=== 15.9.4.3 Date.UTC ===<br />
<br />
When called with fewer than 2 arguments Date.UTC must return NaN.<br />
<br />
=== toString ===<br />
<br />
TODO<br />
<br />
== Global scope ==<br />
<br />
ES5 claims the global scope "this" is the same as the global object, which is not always true in HTML5.<br />
<br />
== Eval ==<br />
<br />
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<br />
<br />
eval.apply(this, code) should work but scope again varies when "this" is not the global object<br />
<br />
eval.apply({}, code) should throw EvalError<br />
<br />
=== Eval and Global Scopes ===<br />
<br />
See: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/030798.html<br />
<br />
== Date Parsing ==<br />
<br />
TODO:This is a mess<br />
<br />
== HTML comments ==<br />
<br />
&lt;!-- is a line comment (same as //)<br />
<br />
In JScript, the following are ignored if they are at the end of the script (i.e. just followed by whitespace lines): either (1) a line that starts with just whitespace and comments and consists of "-->" 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 "&lt;!--" (but not in eval).<br />
<br />
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 &lt;!-- --> comments.)<br />
<br />
In Carakan, Nitro and V8, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).<br />
<br />
TODO: test Chakra.<br />
<br />
== Property Enumeration ==<br />
<br />
Enumeration of objects is in insertion order (but host property order compared to user defined property order does not seem to be significant). Property order seems to survive the use of "delete" (i.e. removing then readding a property doesn't change its position), at least in Chrome and Firefox.<br />
<br />
== Object Properties ==<br />
<br />
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().<br />
<br />
== Getters and Setters ==<br />
<br />
* __lookupGetter__<br />
* __lookupSetter__<br />
* __defineGetter__<br />
* __defineSetter__<br />
<br />
== foo.arguments ==<br />
<br />
TODO http://www.w3.org/mid/4B02C72B.6020106@opera.com<br />
<br />
== Also see ==<br />
<br />
* http://kangax.github.com/es5-compat-table/non-standard/<br />
<br />
[[Category:Spec_coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Testsuite&diff=7674Testsuite2011-11-15T14:31:05Z<p>Ms2ger: Add some links to W3C WG test suites</p>
<hr />
<div>Existing tests URI: http://dev.w3.org/html5/tests/<br />
<br />
== Requirements ==<br />
<br />
* Each test needs a "reviewed" marker of some sort<br />
* It must be easy to find tests where the spec has changed under them<br />
* The barrier to contribution must be as low as possible<br />
* Testcases should have somewhat stable URIs<br />
* If test can be done using JavaScript preferably require it to be in JavaScript so engines can be more efficiently tested (i.e. automated).<br />
* It must be easy to review tests<br />
* Standardize a test format?<br />
<br />
== Non-requirements ==<br />
<br />
* There does not need to be a single consistent test harness for the whole of HTML5. (When sections can be tested in isolation, each section should use a test harness that is suited to that section's testing requirements. E.g. there is little value in fitting canvas tests and parser tests into the same framework, and it may add a lot of complexity.)<br />
<br />
== Format proposal ==<br />
<br />
See http://omocha.w3.org/wiki/newformat for a format proposal that should meet most of these requirements. That format is based on the Mozilla Mochitest format for running JavaScript based client-side tests which can be run automatically.<br />
<br />
== Existing tests ==<br />
* [[Test cases]]<br />
* [http://www.whatwg.org/html5 The specification] has links to test in the status boxes.<br />
* [http://samples.msdn.microsoft.com/ietestcenter/ IE's tests]<br />
* [http://tc.labs.opera.com/html/ Opera's tests]<br />
* [http://trac.webkit.org/browser/trunk/LayoutTests (Some of?) WebKit's tests]<br />
* [http://mxr.mozilla.org/mozilla-central/find?string=test_.*%28html|svg%29%24&tree=mozilla-central&hint= Some of Mozilla's mochitests]<br />
** [[Testsuite/Mozilla]]<br />
* [http://mxr.mozilla.org/mozilla-central/find?string=reftest.list Some of Mozilla's reftests]<br />
* [http://philip.html5.org/tests/canvas/suite/tests/ Philip's canvas tests]<br />
* [http://hixie.ch/tests/adhoc/html/ Hixie's ad-hoc tests]<br />
* [http://lachy.id.au/dev/markup/tests/html5/ Lachlan's tests]<br />
* [http://hg.gsnedders.com/php-html-5-direct/file/tip/tests/numbersTest gsnedders' number parsing tests]<br />
* [http://simon.html5.org/test/html/ zcorpan's tests]<br />
* [http://code.google.com/p/html5lib/source/browse/testdata html5lib tests]<br />
* [http://hsivonen.iki.fi/test/moz/video-selection/ hsivonen's video tests]<br />
* [http://www.w3.org/DOM/Test/ Document Object Model (DOM) Conformance Test Suites]<br />
* [http://dev.w3.org/2006/webapi/WindowTestSuite/ Window test suite]<br />
<br />
=== W3C ===<br />
* [http://dev.w3.org/geo/api/test-suite/ Geolocation]<br />
* [http://dvcs.w3.org/hg/webapps WebApps WG]<br />
* [http://dvcs.w3.org/hg/html HTML WG]<br />
* [http://hg.csswg.org/test CSS WG]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Crypto&diff=7291Crypto2011-10-12T19:52:49Z<p>Ms2ger: Throw an exception for overlarge arrays, as discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=440046</p>
<hr />
<div>==Overview==<br />
<br />
This document describes a proposal for the window.crypto API.<br />
<br />
==Definitions==<br />
<br />
===Cryptographically Random Values===<br />
<br />
A <b id=concept-cryptographically-random-values title=concept-cryptographically-random-values>cryptographically random value</b> is a value generated from a cryptographically strong pseudo-random number generator seeded with truly random values. In practice, implementations should generate cryptographically random values using well-established cryptographic pseudo-random number generators, such as RC4, seeded with high-quality entropy, such as from an operating-system entropy source (e.g., ''/dev/urandom''). This document provides no lower-bound on the information theoretic entropy present in cryptographically random values, but implementations should make a best effort to provide as much entropy as practicable.<br />
<br />
==Interface <code title>Crypto</code>==<br />
<br />
<pre>interface Crypto {<br />
void getRandomValues(in ArrayBufferView array);<br />
};<br />
<br />
partial interface Window {<br />
readonly attribute Crypto crypto;<br />
};</pre><br />
<br />
The <b id=dom-Crypto-getRandomValues title=dom-Crypto-getRandomValues><code>getRandomValues(<var>array</var>)</code></b> must run the following steps:<br />
# <var>array</var> is an [http://www.khronos.org/registry/typedarray/specs/latest/#6 ArrayBufferView]. If <var>array</var> is not of an integer type (i.e., Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, or Uint32Array), [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw throw] a [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#typemismatcherror TypeMismatchError] and abort these steps.<br />
# If <var>array</var>'s length is greater than 65536, [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw throw] a [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#quotaexceedederror QuotaExceededError] and abort these steps.<br />
# Overwrite all elements of <var>array</var> with [[#concept-cryptographically-random-values|cryptographically random values]] of the appropriate type.<br />
<br />
[[Category:Proposals]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=W3C&diff=7153W3C2011-09-26T19:16:07Z<p>Ms2ger: Created page with 'This is a list of cases where publication of specs at TR/ hurt. * https://bugzilla.mozilla.org/show_bug.cgi?id=688878 * https://bugzilla.mozilla.org/show_bug.cgi?id=505115#c141'</p>
<hr />
<div>This is a list of cases where publication of specs at TR/ hurt.<br />
<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=688878<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=505115#c141</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Component_Model&diff=7152Component Model2011-09-26T19:15:50Z<p>Ms2ger: Fix links, syntax, typos</p>
<hr />
<div>Here's a good starting point for learning about the [https://github.com/dglazkov/component-model component model spec], which is being developed by applying a [[Component_Model_Methodology | defined methodology]].<br />
<br />
=Introduction=<br />
<br />
The '''Component Model''' introduces comprehensive support for creating DOM elements. [[Component_Model_Use_Cases | Examples]] include layout managers, combinations of Dojo and jQuery widgets, isolated widgets, such as Like/+1 buttons, and built-in HTML elements themselves. Reflecting on the experience of Mozilla's XBL and Microsoft Internet Explorer's HTML components, the Component Model formalizes the concept of loosely coupled, coherent units of [[Behavior Attachment | behavior]] in the [http://www.w3.org/wiki/Open_Web_Platform Web platform]. The functionality goals of the Component Model resemble the goals of [http://dev.w3.org/2006/xbl2/ XBL2]; unlike XBL2, the Component Model seeks to be more incremental and modular while leveraging and integrating with new technologies.<br />
<br />
Related links:<br />
* [[Behavior_Attachment | Behavior Attachment]] -- a general overview of the behavior attachment problem<br />
* [[Component_Model_Methodology | Component Model Methodology]]<br />
* [[Component_Model_Use_Cases | Component Model Use Cases]]<br />
* [https://github.com/dglazkov/component-model Component Model Spec on Github]<br />
* [http://dglazkov.github.com/component-model/ Component Model Spec Snapshot on Github Pages]<br />
<br />
=Properties=<br />
<br />
The component model aims to satisfy several key properties. These properties were extracted from the [[Component_Model_Use_Cases | use cases]]. This section explains component model basics by studying each property.<br />
<br />
==Extensibility==<br />
<br />
The component model enables creation of new types of DOM elements by allowing the use of existing DOM elements in JavaScript prototype chain. For example, here's how you would create a new sub-type of HTMLElement:<br />
<code><br />
<pre><br />
function LayoutManagerPanel() {<br />
HTMLElement.call(this);<br />
}<br />
<br />
LayoutManagerPanel.prototype = Object.create(HTMLElement.prototype);<br />
<br />
// ...<br />
<br />
// 1) Will not be able to add instances of LayoutManagerPanel to document without this call.<br />
// 2) First parameter specifies the tagName of the element being registered and must be a string prefixed with "x-".<br />
Element.register("x-layout-manager-panel", LayoutManagerPanel);<br />
<br />
// ...<br />
<br />
var panel = new LayoutManagerPanel();<br />
document.body.appendChild(panel);<br />
// or<br />
document.body.innerHTML = "<x-layout-manager-panel></x-layout-manager-panel>";<br />
</pre><br />
</code><br />
<br />
The resulting <code>panel</code> instance is a Javascript object that is a valid DOM element, which can be added to the DOM tree. You can then extend this object using standard Javascript prototype inheritance.<br />
<br />
Required Building Blocks:<br />
* [[#Constructable_DOM_Types | Constructable DOM Types]]<br />
* [[#Registering_Elements | Registering Elements]]<br />
<br />
==Consistency==<br />
<br />
Because components are just DOM objects, they inherently share the same traversal and manipulation APIs, as defined by the [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM4]. The authors of components can extend these APIs by adding custom methods and properties on DOM objects, using standard JavaScript inheritance:<br />
<code><br />
<pre><br />
Widget.prototype = Object.create(HTMLElement.prototype, {<br />
update: {<br />
value: function() { /* ... */ }<br />
},<br />
value: {<br />
get: function() { /* ... */ },<br />
set: function() { /* ... */ }<br />
},<br />
// ...<br />
});<br />
</pre><br />
</code><br />
The common API surface and the ability to extend it serves as a natural API boundary for framework authors, enabling interoperability.<br />
<br />
Required Building Blocks:<br />
* [[#Constructable_DOM_Types | Constructable DOM Types]]<br />
<br />
==Encapsulation==<br />
Encapsulation refers to ability of the component to hide its implementation details and state from the document. To enable hiding of the implementation details, the component model provides a way to build a DOM tree that is not accessible from the document DOM tree, but is rendered as part of the document. This DOM tree, associated with the component is the [http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ shadow DOM]. The boundary between the document DOM tree and shadow DOM tree provides complete encapsulation, and ensures that:<br />
* no shadow DOM tree nodes cross this boundary during event dispatch;<br />
* document DOM tree has no access to nodes in the shadow DOM tree.<br />
<br />
Additionally, the boundary serves as a convenient style application lever, giving the component a choice of letting (or not letting) document CSS affect the shadow DOM tree.<br />
<br />
Every DOM element instance may only have (or ''host'') one shadow DOM tree. A shadow tree is instantiated by creating an instance of the <code>ShadowRoot</code> object, which takes a reference to the hosting element as a parameter. Attempting to create more than one instance for the same element throws an exception:<br />
<br />
<code><br />
<pre><br />
function LayoutManagerPanel() {<br />
HTMLElement.call(this);<br />
var shadow = new ShadowRoot(this);<br />
var shadow2 = new ShadowRoot(this); // throws an exception.<br />
// ...<br />
}<br />
</pre><br />
</code><br />
<br />
Required Building Blocks:<br />
* [[#Shadow_DOM | Shadow DOM]]<br />
<br />
==Composability==<br />
<br />
Being DOM objects, components fit naturally into the document DOM tree and support all of its composition properties. In addition, the <code>content</code> element allows controlling interaction between shadow and document DOM trees. A <code>content</code> element specifies places where immediate document tree children of the component are rendered ''inside'' the shadow tree.<br />
<br />
There can be more than one <code>content</code> element in the shadow tree. The <code>includes</code> attribute provides a convenient way to sort element's children by CSS selector. For example, a <code>DockLayoutPanel</code> component could be used like this in the document DOM tree:<br />
<code><br />
<pre><br />
&lt;x-dock-layout-panel&gt;<br />
&lt;h1 class=&quot;north&quot;&gt;On Gardens&lt;/h1&gt;<br />
&lt;ul class=&quot;west&quot;&gt;<br />
&lt;li&gt;Automatic Gardens&lt;/li&gt;<br />
&lt;li&gt;Gardening on minefields&lt;/li&gt;<br />
&lt;/ul&gt;<br />
&lt;p&gt;I love gardening.&lt;/p&gt;<br />
&lt;div class=&quot;south&quot;&gt;Written by Chauncey Gardiner.&lt;/div&gt;<br />
&lt;/x-dock-layout-panel&gt;<br />
</pre><br />
</code><br />
Provided that its shadow DOM tree looks like this:<br />
<code><br />
<pre><br />
&lt;#shadow-root&gt;<br />
&lt;div class=&quot;north&quot;&gt;<br />
&lt;content includes=&quot;.north&quot;&gt;<br />
&lt;/div&gt;<br />
&lt;div&gt;<br />
&lt;div class=&quot;west&quot;&gt;<br />
&lt;content includes=&quot;.west&quot;&gt;<br />
&lt;/div&gt;<br />
&lt;div class=&quot;east&quot;&gt;<br />
&lt;content&gt;<br />
&lt;/div&gt;<br />
&lt;/div&gt;<br />
&lt;div class=&quot;south&quot;&gt;<br />
&lt;content includes=&quot;.south&quot;&gt;<br />
&lt;/div&gt;<br />
&lt;#shadow-root&gt;<br />
</pre><br />
</code><br />
The document DOM tree children on of <code>x-dock-layout-panel</code> will be rendered as if composed from this tree:<br />
<code><br />
<pre><br />
&lt;x-dock-layout-panel&gt;<br />
&lt;div class=&quot;north&quot;&gt;<br />
&lt;h1 class=&quot;north&quot;&gt;On Gardens&lt;/h1&gt;<br />
&lt;/div&gt;<br />
&lt;div&gt;<br />
&lt;div class=&quot;west&quot;&gt;<br />
&lt;ul class=&quot;west&quot;&gt;<br />
&lt;li&gt;Automatic Gardens&lt;/li&gt;<br />
&lt;li&gt;Gardening on minefields&lt;/li&gt;<br />
&lt;/ul&gt;<br />
&lt;/div&gt;<br />
&lt;div class=&quot;east&quot;&gt;<br />
&lt;p&gt;I love gardening.&lt;/p&gt;<br />
&lt;/div&gt;<br />
&lt;/div&gt;<br />
&lt;div class=&quot;south&quot;&gt;<br />
&lt;div class=&quot;south&quot;&gt;Written by Avid Gardener.&lt;/div&gt;<br />
&lt;/div&gt;<br />
&lt;/x-dock-layout-panel&gt;<br />
</pre><br />
</code><br />
<br />
Required Building Blocks:<br />
* [[#Content_Element | Content Element]]<br />
<br />
==Desugaring==<br />
The component model also explains pretty well how the native HTML elements are built and dispels some of the magic associated with the "DOM object vs. JavaScript object" juxtaposition.<br />
<br />
Allowing DOM elements to participate in the JavaScript inheritance chain makes DOM elements more approachable and easier to work with.<br />
<br />
Complex DOM elements that are rendered with more than one CSS box (and aren't specified in terms of CSS, like [http://dev.w3.org/csswg/css3-lists/ lists]) are just components that have shadow DOM. Coincidentally, this also explains why you can't add shadow DOM subtrees to <code>input</code> or <code>details</code> elements -- their <code>ShadowRoot</code>s are claimed by <code>HTMLInputElement</code> and <code>HTMLDetailsElement</code> constructors, respectively.<br />
<br />
Required Building Blocks:<br />
* [[#Shadow_DOM | Shadow DOM]]<br />
* [[#Content_Element | Content Element]]<br />
<br />
==Performance==<br />
Considering the way Web works, the component model must allow decoupling of the instantiation and the declaration of the components in order to provide reasonable performance characteristics. It's an unfortunate, but necessary requirement. In other words, we must be able to handle situations where a component instance is created before it is declared. Here's an simple example:<br />
<br />
<code><br />
<pre><br />
// somewhere in view.js<br />
...<br />
document.body.innerHTML = '<div class="awesome"><x-layout><x-spring-panel>...</x-spring-panel></x-layout>';<br />
<br />
...<br />
// somewhere in layout.js<br />
Element.register('x-layout', Layout);<br />
Element.register('x-spring-panel', SpringPanel);<br />
</pre><br />
</code><br />
<br />
In this situation, there is no room for error: <code>view.js</code> ''must'' wait for <code>layout.js</code> to load before executing. You can't load <code>layout.js</code> lazily or in any different order, since it defines the components that are used in <code>view.js</code>. Given that asynchronous, deferred or lazy-loading of script are all common performance techniques in today's Web, we must do better than block or throw an exception in such cases.<br />
<br />
The component model offers this solution:<br />
<br />
When an unknown DOM element with an "x-"-prefixed <code>tagName</code> is encountered, we put a placeholder <code>HTMLUnknownElement</code> instance in its place. As soon as the element is defined, all placeholder instances are replaced ([http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode Document.renameNode]) with the new, proper DOM element.<br />
<br />
Required Building Blocks:<br />
* [[#Registering_Elements | Registering Elements]]<br />
<br />
== Confinement ==<br />
Confinement refers to the document protecting its implementation details and state from the component and can be viewed as the inverse of [[#Encapsulation | encapsulation]].<br />
<br />
Required Building Blocks:<br />
* [[#Confinement_Primitives | Confinement Primitives]]<br />
<br />
=Building Blocks=<br />
<br />
The component model is comprised of the following building blocks.<br />
<br />
==Shadow DOM==<br />
<br />
Any DOM element can host a shadow DOM subtree. The shadow DOM subtree originates at <code>ShadowRoot</code>, which is coupled the hosting element at the time of its construction. You don't need any other building blocks in order to take advantage of the shadow DOM:<br />
<code><br />
<pre><br />
var element = document.createElement("div");<br />
var shadow = new ShadowRoot(element);<br />
shadow.appendChild(document.createElement("p")).textContent = "weee!!';<br />
</pre><br />
</code><br />
<br />
A <code>ShadowRoot</code> instance is a [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-node Node], and acts as the root of the element's shadow DOM subtree. The <code>ShadowRoot</code> itself is never rendered, nor has styles. In this regard, it's similar to the [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-documentfragment DocumentFragment]. It has two properties:<br />
* <code>applyAuthorSheets</code>, which is either '''true''' (that is, apply author style sheets from the document), or '''false''' (don't);<br />
* <code>shadowHost</code>, which points to the hosting element.<br />
<br />
==Content Element==<br />
<br />
The <code>content</code> element is used with [[#Shadow_DOM | Shadow DOM]] and provides a mechanism for distributing hosting element's children inside of its shadow subtree. To preserve the [[#Encapsulation | encapsulation]] property, the <code>content</code> elements act as insertion points and do not leak any information about hosting element's children to the shadow DOM subtree or vise versa.<br />
<br />
==Constructable DOM Types==<br />
The inability to construct DOM element using <code>new</code> (with some exceptions) or use them in the prototype inheritance chain had confounded many Web developers since the beginning of DOM. This building block intends to rectify at least the latter by allowing <code>HTMLElement.call</code> invocation and thus enabling creation of JavaScript objects with DOM elements in the prototype chain.<br />
<br />
==Registering Elements==<br />
Working in conjunction with [[#Constructable_DOM_Types | Constructable DOM Types]], this building block makes the list of valid markup tag names extensible by exposing <code>Element.register</code>:<br />
<code><br />
<pre><br />
partial interface Element {<br />
static void register(in String tagName, in Function constructor);<br />
}<br />
</pre><br />
</code><br />
<br />
It is possible to envisage a milder (though less elegant) version of element registration by keeping DOM element construction magical (thus decoupling it from [[#Constructable_DOM_Types | Constructable DOM Types]]) and making <code>Element.register</code> use a callback, rather than <code>constructor</code> as parameter. The callback would be invoked with an already-constructed DOM object with the specified <code>tagName</code>, leaving the work of setting up properties on this object to the callback.<br />
<br />
==Confinement Primitives==<br />
<br />
The API surface of the component model lends itself well to proper confinement. Here's an approach that could be used to provide it (very early brainstorming):<br />
<br />
* Confinement is not tied to the component model. Instead, it's a new twist on the method of loading scripts. A script could be loaded as usual or it could be ''confined'', or loaded into its own context.<br />
<br />
* When confined, a script has its own global and document objects. These objects only reveal some safe limited subset of the actual document objects. Think of it as a same-origin iframe with restrictions on document and window.<br />
<br />
* You can communicate with the main document using <code>window.postMessage</code>.<br />
<br />
* The confined document DOM tree is always empty. Attempting to insert into it throws exceptions.<br />
<br />
* ... except when you append to elements in shadow DOM. That's right, you can do <code>Element.register</code> and <code>new ShadowRoot</code> in the confined document.<br />
<br />
* Whenever you register an element, it registers ''in the main document'' as well. Creating an instance of a component from an confined document produces a functional DOM element shell that proxies to the actual element in the confined document.<br />
<br />
Proposed API: introduce a new <code>confined</code> attribute to the <code>script</code> element. Presence of this attribute triggers loading scripts in the confined context.<br />
<br />
Confinement of script execution could be useful outside of the component model and also could be related to [https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html Content Security Policy].<br />
<br />
* [[Component_Model_Isolation_Brainstorming | Isolation Brainstorm]]<br />
<br />
=Building Blocks Use Case Coverage=<br />
<br />
Here's a list of building blocks, tabulated against the [[Component_Model_Use_Cases | use cases]] and approximate percentage of satisfying them:<br />
<br />
{| cellpadding="10" cellspacing="0" style="border-collapse: collapse;"<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
! align="left" | Building Block<br />
! align="left" | [[Component_Model_Use_Cases#Layout_Manager | Layout Manager]]<br />
! align="left" | [[Component_Model_Use_Cases#Widget_Mix-and-Match | Mix-and-Match]]<br />
! align="left" | [[Component_Model_Use_Cases#Rendering_Form_Controls_with_SVG | SVG Controls]]<br />
! align="left" | [[Component_Model_Use_Cases#Contacts_Widget | Contacts Widget]]<br />
! align="left" | [[Component_Model_Use_Cases#Like.2F.2B1_Button | Like/+1 Button]]<br />
! align="left" | [[Component_Model_Use_Cases#Media_Controls_For_The_Video_Element | Media Controls for the Video Element]]<br />
! align="left" | [[Component_Model_Use_Cases#Details.2FSummary_Elements | Details/Summary Element]]<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
| [[Component_Model#Shadow_DOM | Shadow DOM]]<br />
| 25%<br />
| -<br />
| 34%<br />
| 100%<br />
| 25%<br />
| 100%<br />
| 50%<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
| [[Component_Model#Content_Element | Content Element]]<br />
| 25%<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
| 50%<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
| [[Component_Model#Constructable_DOM_Types | Constructable DOM Types]]<br />
| 25%<br />
| 50%<br />
| 33%<br />
| -<br />
| 25%<br />
| -<br />
| -<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
| [[Component_Model#Registering_Elements | Registering Elements]]<br />
| 25%<br />
| 50%<br />
| 33%<br />
| -<br />
| 25%<br />
| -<br />
| -<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
| [[Component_Model#Confinement_Primitives | Confinement Primitives]]<br />
| -<br />
| -<br />
| -<br />
| -<br />
| 25%<br />
| -<br />
| -<br />
|}<br />
<br />
=Comparison With Existing Specs and Implementations=<br />
<br />
Here's a brief overview of existing similar specifications and implementations:<br />
* [http://msdn.microsoft.com/en-us/library/ms531018(v=vs.85).aspx HTML Components] is a [http://windows.microsoft.com/en-US/internet-explorer/products/ie/home Microsoft Internet Explorer]-specific method of creating custom DOM elements. Also see [http://www.w3.org/TR/NOTE-HTMLComponents HTML Components Note] (implemented in IE5+).<br />
* [http://www.w3.org/TR/2001/NOTE-xbl-20010223/ XBL], currently implemented in Mozilla.<br />
* [http://dev.w3.org/2006/xbl2/ XBL2], the ancestral spec of the Component Model, and a revision of XBL.<br />
<br />
Here's a handy overview of how each of these specs satisfies the component model [[#Properties | properties]]:<br />
<br />
{| cellpadding="10" cellspacing="0" style="border-collapse: collapse;"<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
! align="left" width="12%" | Spec/Implementation<br />
! align="left" width="12%" | [[#Extensibility | Extensibility]]<br />
! align="left" width="12%" | [[#Consistency | Consistency]]<br />
! align="left" width="12%" | [[#Encapsulation | Encapsulation]]<br />
! align="left" width="12%" | [[#Composability | Composability]]<br />
! align="left" width="12%" | [[#Desugaring | Desugaring]]<br />
! align="left" width="12%" | [[#Performance | Performance]]<br />
! align="left" width="12%" | [[#Confinement | Confinement]]<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
! align="left" | HTML Components<br />
| '''No'''. Components are magic, inextensible objects.<br />
| '''Almost'''. Implementation provides ways to add properties, methods, events to element API, and the components are ''almost'' DOM elements. However, custom tags don't support all properties of a DOM element.<br />
| '''Not much'''. There are some provisions for event encapsulation, nothing else.<br />
| '''Not much'''. No provisions for handling document children vs. component-defined children.<br />
| '''No'''.<br />
| '''Not sure'''.<br />
| '''No'''.<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
! align="left" | XBL<br />
| '''No'''. The mechanism for extending bindings is entirely independent of DOM type or Javascript extensibility.<br />
| '''Yes-ish'''. Bindings can override properties on the DOM element, although the mechanism is highly unnatural (XML declarations).<br />
| '''Yes'''? Hard to say looking at TR note.<br />
| '''Yes'''<br />
| '''Yes'''. Some HTML elements in Gecko are implemented using it.<br />
| '''Not sure'''.<br />
| '''No'''.<br />
|- valign="top" style="border-bottom: 1px solid LightGray;"<br />
! align="left" | XBL2<br />
| '''No'''. Same as XBL.<br />
| '''No'''. Bindings are discouraged from establishing an API surface on a bound element.<br />
| '''Yes'''.<br />
| '''Yes'''.<br />
| '''No'''. The spec didn't intend to describe how native elements are built.<br />
| '''Somewhat'''. The lifecycle of a binding is well-defined and initialization stages are well-decoupled. However, there is no way to build a binding imperatively without loading a binding document.<br />
| '''No'''.<br />
|}<br />
<br />
The key differences between XBL2 and the Component Model are:<br />
* The Component Model fully embraces the [[Behavior_Attachment#Behavior_Attachment_Methods | element behavior attachment]] by allowing creation of new types of DOM elements within a document. This is something Web Framework developers always wanted and repeatedly try to do with parallel object hierarchies. Eliminating ephemerality of the attachment simplifies and clarifies how things work conceptually -- there is no longer a place for "spooky action at a distance", caused by a change of a random CSS selector or even removing an element from the tree.<br />
* The Component Model is strongly biased toward reusing existing bits of the platform and well-established techniques instead of inventing new ones. For instance, instead of bindings inheritance, we rely on prototype inheritance. Instead of endeavoring to solve the incredibly complex, yet dubious problem of multiple bindings or shadow DOM trees, we simply suggest composition.<br />
* The Component Model strives to add capabilities in layers (see [[#Building_Blocks | building blocks]]), each able to function on its own. The omnibus nature of XBL2 removes opportunities for layering, particularly as element identity, life cycle, and scripting are concerned. Perhaps this could be repaired somehow, but Component Model solves these issues without further complicating an already large, difficult to understand spec.<br />
<br />
[[Category:Proposals]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Crypto&diff=6932Crypto2011-08-18T12:14:15Z<p>Ms2ger: Make this read like a spec, update to modern IDL syntax, and fix header levels</p>
<hr />
<div>==Overview==<br />
<br />
This document describes a proposal for the window.crypto API.<br />
<br />
==Definitions==<br />
<br />
===Cryptographically Random Values===<br />
<br />
A <b id=concept-cryptographically-random-values title=concept-cryptographically-random-values>cryptographically random value</b> is a value generated from a cryptographically strong pseudo-random number generator seeded with truly random values. In practice, implementations should generate cryptographically random values using well-established cryptographic pseudo-random number generators, such as RC4, seeded with high-quality entropy, such as from an operating-system entropy source (e.g., ''/dev/urandom''). This document provides no lower-bound on the information theoretic entropy present in cryptographically random values, but implementations should make a best effort to provide as much entropy as practicable.<br />
<br />
==Interface==<br />
<br />
<pre><br />
interface Crypto {<br />
void getRandomValues(in ArrayBufferView array);<br />
};<br />
<br />
partial interface Window {<br />
readonly attribute Crypto crypto;<br />
};<br />
</pre><br />
<br />
==Methods==<br />
<br />
===getRandomValues===<br />
<br />
The <b id=dom-Crypto-getRandomValues title=dom-Crypto-getRandomValues><code>getRandomValues(<var>array</var>)</code></b> must run the following steps:<br />
# <var>array</var> is an [http://www.khronos.org/registry/typedarray/specs/latest/#6 ArrayBufferView]. If <var>array</var> is not of an integer type (i.e., Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, or Uint32Array), throw a [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-type_mismatch_err TYPE_MISMATCH_ERR] and abort these steps.<br />
# Overwrite all elements of <var>array</var> with [[#concept-cryptographically-random-values|cryptographically random values]] of the appropriate type.<br />
<br />
[[Category:Proposals]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs/todo&diff=6368Specs/todo2011-04-14T21:35:33Z<p>Ms2ger: +/-</p>
<hr />
<div>There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch, post on the WHATWG mailing list or say something on [[IRC]].<br />
<br />
See also: [[Specs|Specs with editors]]<br />
<br />
== How to edit a spec ==<br />
<br />
We have [[How to write a spec|some documentation on how to write a spec]] that could help if you want to help out.<br />
<br />
== Specs to edit ==<br />
<br />
=== DOM ===<br />
<br />
* A rewrite of DOM2 Traversal.<br />
* A specification that defines how XML maps to DOM Core<br />
* User Interaction Events (onclick, onkeypress, etc).<br />
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus<br />
* An API for cryptography, to generate keys and the like<br />
* The console.* API. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694] [http://www.w3.org/mid/d7be01cb7077$4dd45010$e97cf030$@gmail.com] [http://sideshowbarker.github.com/console-spec/]<br />
* setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]<br />
<br />
=== CSS ===<br />
<br />
There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:<br />
* CSS Animation<br />
* CSS Gradients<br />
* [http://dev.w3.org/csswg/cssom/ CSSOM]<br />
** CSSOM needs to define how Link:, <?xml-stylesheet?>, <link rel=stylesheet>, and <style> interact with the fetching algorithm, the event loop, and the parsers from HTML5.<br />
** CSSOM should have a mechanism for taking elements full-screen<br />
** it has been proposed that CSSOM have a mechanism for keeping track of when expensive-to-compute areas of the document (e.g. a canvas) are actually being rendered.<br />
*** Add a pair of events that fire when an element is hidden and unhidden<br />
*** Add a pair of events that fire when an element is scrolled into and out of the view<br />
* <?xml-stylesheet?> could do with a rewrite for integration with CSSOM; do 'load' and 'error' events fire on it?<br />
<br />
=== Registries ===<br />
<br />
Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:<br />
<br />
* Encodings: [[Web Encodings]]<br />
* MIME types<br />
* Schemes<br />
<br />
It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).<br />
<br />
See also: [[Registries]]<br />
<br />
=== MISC ===<br />
* an API to do syntax highlighting on &lt;textarea>, &lt;pre>, and contenteditable sections would be highly popular with Web developers (ack Ryan Johnson). (This would probably best be done as some sort of output filter at the CSS level, rather than anything HTML-specific.)<br />
* JS changes: [[Web ECMAScript]]<br />
* Animated GIFs need a spec that, in particular, specifies how to handle timings (not all browsers honour all values, so we should specify what needs to be honoured exactly)<br />
* Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/20101101063413.bf1d8102.eric@bisonsystems.net)<br />
<br />
== See also ==<br />
<br />
* http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html (a description of some sections that needed editing in 2008 and how much work they would be)<br />
<br />
== Other stuff ==<br />
<br />
Some notes from the HTML5 spec about things that need doing:<br />
<br />
* support access Array element via () instead of [] (IEism) https://bugzilla.mozilla.org/show_bug.cgi?id=289876<br />
* Need to say that NodeList's items are enumerable, so that... for (var x in myNodeList) { } ...works. (ack Dethe Elza)<br />
* a way to show icons for file types e.g. http://www.gadgetopia.com/2004/05/04/FileIconTag.html (this should probably be a function for the 'content', 'background-image' and 'list-style-image' properties in CSS)<br />
** Maybe something like moz-icon://? http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0255.html, http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html<br />
<br />
[[Category:Spec_coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Category:Registries&diff=6361Category:Registries2011-04-13T08:49:05Z<p>Ms2ger: Created</p>
<hr />
<div>A set of registries for the Web Platform is hosted on the WHATWG Wiki. These include registries for HTML, the DOM, and alternatives to IANA registries.<br />
<br />
These registries have not yet been set up:<br />
<br />
* [[Registry-HTTP-headers]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=URL_schemes&diff=6360URL schemes2011-04-13T08:48:54Z<p>Ms2ger: Create</p>
<hr />
<div>* [https://github.com/josephholsten/about-uri-scheme/raw/master/draft-holsten-about-uri-scheme-07.txt about:]<br />
* [http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme javascript:]<br />
* [http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol ws: & wss:]<br />
* Many more. See [http://en.wikipedia.org/wiki/URI_scheme Wikipedia]<br />
<br />
[[Category:Registries]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs&diff=6261Specs2011-02-22T17:54:34Z<p>Ms2ger: /* Media-Specific Layer */ +execCommand</p>
<hr />
<div>This wiki page lists all the specifications that a Web browser is likely to implement.<br />
<br />
For each spec, link the spec's title to the most up to date draft (typically the editor's draft, for specs written in public; for specs written in secret, the latest published working draft), followed by a comma separated list of links in parentheses, named "feedback" for links to the current pending feedback, "discussion" for a link to the archives of the main relevant mailing list or to a page describing relevant mailing lists, "bugs" for a link to a bug system query showing the current open bugs. For specifications that are published in multiple forms, link to the most complete version (e.g. link to the one-page complete.html WHATWG spec rather than all the split-out W3C drafts).<br />
<br />
See also: [[Companion specifications|Specs without editors]]<br />
<br />
== Network Layer ==<br />
* [http://tools.ietf.org/wg/httpbis/ HTTP]<br />
** [http://tools.ietf.org/html/draft-ietf-websec-mime-sniff Media Type Sniffing]<br />
** [http://tools.ietf.org/html/draft-ietf-httpstate-cookie Cookies]<br />
* [http://tools.ietf.org/html/rfc0959 FTP]<br />
* [http://tools.ietf.org/html/rfc5246 TLS]<br />
* [http://tools.ietf.org/html/draft-ietf-websec-origin Origin]<br />
<br />
== Infrastructure ==<br />
<br />
* [http://www.unicode.org/versions/Unicode6.0.0/ Unicode]<br />
* [http://dev.w3.org/2006/webapi/WebIDL/ WebIDL]<br />
* [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM Core] ([http://lists.w3.org/Archives/Public/public-webapps/ discussion])<br />
* [http://www.w3.org/TR/xml/ XML]<br />
* [http://www.w3.org/TR/xml-names/ XMLNS]<br />
* [http://www.w3.org/TR/xmlbase/ <code>xml:base</code>] ([http://lists.w3.org/Archives/Public/www-xml-linking-comments/ discussion])<br />
<br />
== Media-Independent Features ==<br />
<br />
* [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] ([http://www.whatwg.org/issues/ feedback], [http://www.whatwg.org/mailing-list discussion], [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=ian%40hixie.ch&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Last+Changed&field0-0-0=noop&type0-0-0=noop&value0-0-0= bugs])<br />
* [http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization]<br />
* [http://html5.org/specs/dom-range.html DOM Range] ([http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&amp;component=DOM%20Range&amp;resolution=--- bugs])<br />
* [http://monet.nag.co.uk/~dpc/draft-spec/ MathML] ([http://lists.w3.org/Archives/Public/www-math/ discussion])<br />
* [http://dev.w3.org/2006/webapi/clipops/clipops.html Clipboard] (cut/copy/paste; [http://lists.w3.org/Archives/Public/public-webapps/ discussion])<br />
* [http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ XMLHttpRequest]<br />
* ECMAScript<br />
** [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html Typed Arrays] (aka <code>ArrayBuffer</code>)<br />
<br />
== Media-Specific Layer ==<br />
<br />
* [http://www.w3.org/TR/CSS21/ CSS] ([http://lists.w3.org/Archives/Public/www-style/latest discussion])<br />
** [http://dev.w3.org/csswg/css3-color/ CSS Color]<br />
** [http://dev.w3.org/csswg/cssom/ CSSOM]<br />
** [http://dev.w3.org/csswg/cssom-view/ CSSOM View]<br />
* [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF]<br />
* [http://www.w3.org/TR/PNG/ PNG]<br />
* [http://www.w3.org/TR/SVG/ SVG]<br />
* [http://people.mozilla.org/~cmccormack/anim-timing/Overview.html Timing control for script-based animations] ([irc://irc.freenode.net/whatwg discussion])<br />
* [http://aryeh.name/spec/editcommands/editcommands.html execCommand]<br />
* [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html WebGL]<br />
<br />
[[Category:Spec_coordination]]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=FAQ&diff=6186FAQ2011-02-05T20:58:02Z<p>Ms2ger: /* How will anything be deprecated and removed if there are no version numbers? */ Missing negative</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard. The WHATWG also works on Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events, and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.<br />
<br />
If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== Is there a process for removing bad ideas from a specification? ===<br />
<br />
There are several processes by which we trim weeds from the specifications.<br />
<br />
* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.<br />
<br />
* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.<br />
<br />
* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.<br />
<br />
Removing features is a critical part of spec development.<br />
<br />
=== Is there a process for adding new features to a specification? ===<br />
<br />
The process is rather informal, but basically boils down to this:<br />
# Research the use cases and requirements by discussing the issue with authors and implementors.<br />
# Come up with a clear description of the problem that needs to be solved.<br />
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.<br />
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.<br />
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.<br />
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.<br />
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.<br />
<br />
If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.<br />
<br />
Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.<br />
<br />
=== What does "Living Standard" mean? ===<br />
<br />
The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.<br />
<br />
Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.<br />
<br />
=== “Living specification” sounds like a draft that may and will change at any moment and is probably not even complete at any moment of time... ===<br />
<br />
That's exactly what it is. However, the specification does not change arbitrarily: we are extremely careful! As parts of the specification mature, and implementations ship, we stop making changes to those sections for all but the most critical of reasons, such as security problems. The specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation.<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
=== Don’t browsers need a target to work their implementations towards, even if it’s a snapshot that is essentially arbitrary? ===<br />
<br />
In practice, implementations all followed the latest specs draft anyway, not the latest snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.<br />
<br />
=== When will it be safe to attempt to implement the spec based solely on the formal specification statements in the spec? === <br />
<br />
It's never truly safe; for example, if you tried to implement HTML4 according to the HTML4 specification you wouldn't have an implementation compatible with HTML4-era documents. However, if you're able to deal with minor changes, like security updates, errata-level changes, etc, then you can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In general, though, we would strongly recommend taking part in the development effort. There's a [http://www.whatwg.org/mailing-list#imps mailing list for implementors] which can help.<br />
<br />
=== How do we know what to use, without having some sort of snapshot that browsers can aim at and developers can evaluate? ===<br />
<br />
The same way you do ''with'' snapshots. Browser vendors don't look at the last snapshot, they look at the ever-progressing latest text anyway.<br />
<br />
No browser ever implemented all of HTML4, for example, even in the years after it was a formal Recommendation. Nor did they wait til they had done all of HTML3.2 before working on implementing HTML4. They all picked and chose the bits they thought were useful. With the Living Standard approach, we can also update the specification at the same time to remove the bits they all agree are useless, and to add new features that they think we should add (before they go off and invent their own solutions!).<br />
<br />
=== Isn’t the whole point of a specification to establish fixed point of reference so that all parties implementing the standard can ensure they have a common baseline of compatibility? ===<br />
<br />
No, the point of a specification is to provide an accurate description of what all the parties should implement. When an error is found in this description, it's better to fix it than to leave it.<br />
<br />
HTML4 provides an example of this. HTML4 says the default value for the "media" attribute is "screen", even though it was long ago realised that this made no sense and the default should be "all". The browsers all implement it as "all". A snapshot with a known bug is not as useful as a living standard.<br />
<br />
=== The large Web industry with many browsers and even more producers of web pages needs to evolve in reasonably consistent steps for ubiquity and interoperability, so we need snapshots ===<br />
<br />
It's true that "the large Web industry with many<br />
browsers and even more producers of web pages needs to evolve in<br />
reasonably consistent steps for ubiquity and interoperability". However, unchanging snapshots of specifications<br />
do nothing to help with this. The implementations usually follow the<br />
drafts, not the snapshots, and in the exceptions where they don't, they<br />
end up ''failing to interoperate''.<br />
<br />
Consider what would happen if a Web browser vendor decided to implement<br />
HTML4 instead of the latest state of the HTML Living Standard. That vendor would have &lt;link><br />
elements with the wrong media="" attribute default, which would break<br />
printing of most of the Web. That vendor would misparse &lt;p>&lt;table>, which<br />
would result in blank lines in numerous unexpected places. That vendor<br />
would find that pages that styled empty paragraphs would fail to render as<br />
expected. That vendor would find that millions of pages would be<br />
unparseable due to not assuming a default encoding. That vendor would find<br />
that 0.2% of pages were missing images due to HTML4 not requiring the<br />
&lt;image>/&lt;img> aliasing. That vendor would, in short, find that the<br />
spec was not an accurate description of the Web, and would either fail in<br />
the market place (due to lack of interoperability), or would go seeking<br />
the latest spec, the living standard, which would dramatically improve their interoperability<br />
with legacy content and existing browsers.<br />
<br />
Snapshots harm interoperability, they don't help it.<br />
<br />
=== How about support in browsers for previous versions of this “living” HTML standard? ===<br />
<br />
Browsers only need to implement the latest spec, and they will be compatible with the bulk of legacy content. That is an underlying principle of the entire WHATWG effort.<br />
<br />
To clarify, browsers today don't implement separate modes for HTML2, HTML3.2, and HTML4. They just implement one version of HTML, and it works with everything (we call this "backwards compatibility"). This is the same model followed by the HTML specification; that's why it defines the browser requirements for lots of old features that aren't allowed anymore. For example, the "font" element is no longer conforming (authors aren't supposed to use it in their pages), but the spec still defines how it works, so that old pages keep working.<br />
<br />
=== Will future browsers have any idea what older HTML documents mean? ===<br />
<br />
Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.<br />
<br />
One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this.<br />
<br />
=== This means you will only able to add to a spec, not redefine it. ===<br />
<br />
Yes. That's been a guiding principle for the WHATWG since its founding. It's even in our [http://www.whatwg.org/charter charter].<br />
<br />
=== How can web developers know which features are safe to use? ===<br />
<br />
See "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".<br />
<br />
=== Browsers can currently say they implement HTML 4.01 and most know what to expect. ===<br />
<br />
Actually, that really isn't what happens in practice. Browsers do not implement specifications atomically, one spec at a time. They pick and chose features from the specs as they see fit. For example, back in the day, browsers implemented the absolute positioning parts of CSS2, but not 'display:run-in', but they still claimed to implement CSS2, and they already had parts of CSS3 implemented too, but not any part of a complete CSS3 module. Browsers claim to implement HTML4, but didn't implement all of it. Browsers moved on to HTML4 features before they had done all of HTML 3.2. And so on.<br />
<br />
Plus, there's the problem of bugs. Different browsers have different bugs, and nothing in the spec's version can tell you what bugs the browser has.<br />
<br />
Thus, in practice, you really can't tell what is implemented based on what version of what spec the vendor's marketing department claims to support. So not having a version number doesn't hurt. If anything, it helps, by removing a potentially bogus point of comparison — it means you have to compare browsers on what they really do (with a test suite), not on what version they claim to support.<br />
<br />
=== How are developers to determine when certain parts of their pages will become invalid? ===<br />
<br />
It shouldn't matter if and when old pages become invalid.<br />
<br />
Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week!<br />
<br />
=== How will anything be deprecated and removed if there are no version numbers? ===<br />
<br />
Not having version numbers doesn't stop us from removing features. We do that regularly, as described above in "[[FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F|Is there a process for removing bad ideas from a specification?]]". See also the "obsolete features" section in the HTML standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html<br />
<br />
=== Will HTML become a bloated unimplementable mess as old features pile up if there are no version numbers? ===<br />
<br />
No. We endeavour to not make HTML unimplementable — if it can't be implemented, there's not much point having a spec! Indeed, making HTML implementable is the main goal of the specification. Certainly HTML will continue to become complicated over time, but that is unrelated to whether we have version numbers or not.<br />
<br />
=== Will HTML become an unusable mess as features are removed and old valid documents suddenly become invalid, if there are no version numbers? ===<br />
<br />
No.<br />
<br />
Features being invalid doesn't make them stop working — browsers are required to support old features. Even things like "inindex", framesets, "font", and so forth are still defined in the HTML specification, even though they're not to be used by authors. Old documents become invalid all the time, for example HTML 3.2 documents that use the "font" element were not valid HTML4 Strict documents, since it made "font" invalid (for good reasons, e.g. it tends to lead to authoring practices that harm accessibility). So even if we continue to make certain features invalid, it does not make HTML an "unusable mess".<br />
<br />
=== If you do not publish snapshots every now and again, you are Orwellian in your recognition of the role the mistakes of the past play into the present and the future. ===<br />
<br />
''No really, someone [http://blog.whatwg.org/html-is-the-new-html5#comment-42288 said that] on our blog.''<br />
<br />
The specification text is kept in version control and not forgotten; in fact, version control archeology is often used as part of the spec's development to figure out when things changed, why they changed, and so forth. This is significantly more helpful than arbitrarily dated snapshots, which in practice aren't studied in the same way since they don't give as detailed an answer. With version control, you can narrow down changes to discussions that happened on a particular day or even hour, with snapshots you are often limited to a resolution of months or years, depending on how often you publish the snapshots.<br />
<br />
You can see the version control repository for the WHATWG specifications at http://html5.org/tools/web-apps-tracker (Web interface) or http://svn.whatwg.org/webapps/ (SVN interface).<br />
Every revision, however minor, is checked in separately. As of the time of this writing (January 2011), the repository has over 5700 revisions already.<br />
<br />
(Another way of looking at it is that we have a new snapshot with every change! Publish early, publish often, as they say.)<br />
<br />
== HTML5 ==<br />
<br />
=== What is HTML5? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is the main focus of the WHATWG community. HTML5 is a snapshot of HTML, which is being worked on by the WHATWG community and also the W3C HTML Working Group.<br />
<br />
HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec.<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne is maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the spec? ===<br />
<br />
All active work at WHATWG is gathered in Web Applications 1.0. It is available as [http://www.whatwg.org/specs/web-apps/current-work/complete.html single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
The WHATWG HTML standard is a subset containing only the HTML-specific material. It is available as [http://www.whatwg.org/specs/web-apps/current-work/ single-page]<br />
and '''[http://whatwg.org/html multi-page]''', as well as in PDF [http://www.whatwg.org/specs/web-apps/current-work/html-a4.pdf A4] and<br />
[http://www.whatwg.org/specs/web-apps/current-work/html-letter.pdf Letter].<br />
<br />
The W3C HTML5 specification is a subset of the WHATWG HTML standard, containing only some of the more stable features.<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! WHATWG Specifications <br> (and sections therein)<br />
! Section links for <br> Web Applications 1.0<br />
! W3C/IETF Specifications<br />
|-<br />
! HTML5 only (excluding newer features)<br />
| n/a<br />
| n/a<br />
| [http://dev.w3.org/html5/spec/Overview.html Single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! HTML (including newer features)<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]<br />
| Everything not listed below!<br />
| <br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/microdata.html Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/the-canvas-element.html#2dcontext 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! Communications - Cross-document messaging<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html#web-messaging Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (HTML WG)<br />
|-<br />
! Communications - Channel messaging<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers specification]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| only in WA1<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| only in WA1<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/network.html Web Sockets API]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| only in WA1<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|-<br />
! WebVTT<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#webvtt-0 In WHATWG HTML] and informally as [http://www.whatwg.org/specs/web-apps/current-work/webvtt.html WebVTT]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#webvtt-0 WebVTT]<br />
|<br />
|}<br />
<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
=== Are there versions of the specification aimed specifically at authors/implementors? ===<br />
<br />
Not yet, but check back soon, we're working on this.<br />
<br />
In the meantime, the WHATWG HTML specification (including the multipage version) can be customized to either hide or emphasize user-agent-specific material. The mode can be selected using radio buttons at the top right of those documents.<br />
<br />
It is also possible to toggle the mode by changing the URL, here is an example for the multipage WHATWG HTML specification:<br />
<br />
* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete<br />
* Author view (hiding the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author<br />
* Implementor view (highlighting the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight<br />
<br />
=== When will we be able to start using these new features? ===<br />
<br />
You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:<br />
<br />
* http://diveintohtml5.org/<br />
* http://caniuse.com/<br />
* http://HTML-5.com/<br />
<br />
If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is no longer working specifically on HTML5, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".<br />
<br />
Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. &lt;canvas&gt;). But other sections are still being actively worked on and changed regularly, or not even written yet.<br />
<br />
'''You can see annotations in the margins showing the estimated stability of each section.'''<br />
<br />
The possible states are:<br />
<br />
* ''Idea; yet to be specified'' -- the section is a placeholder.<br />
* ''First draft'' -- An early stage.<br />
* ''Working draft'' -- An early stage, but more mature than just "first draft".<br />
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.<br />
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.<br />
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it&#8217;s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.<br />
<br />
There are also two special states:<br />
<br />
* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback. (This state is not used often.)<br />
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.<br />
<br />
The point to all this is that you shouldn&#8217;t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.<br />
<br />
=== What's this I hear about 2022? ===<br />
<br />
Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now. For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you&#8217;ll begin to understand why the time frame seems so long.<br />
<br />
Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.<br />
<br />
=== What about Microsoft and Internet Explorer? === <br />
<br />
Microsoft has already started implementing parts of HTML5 in IE8 and is adding more to IE9.<br />
<br />
HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.<br />
<br />
=== Is design rationale documented? ===<br />
<br />
Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.<br />
<br />
For a few cases that someone did take the time document, the information can be found at the following locations:<br />
<br />
* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend]] or another ''mini-header'' element.<br />
<br />
Also see ''HTML feature proposals'' below.<br />
<br />
== HTML syntax issues ==<br />
<br />
=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? === <br />
<br />
Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''<br />
<br />
=== What will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be extended to support years and years+months, but this is awaiting implementation experience with what is already specified.)<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account — and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.<br />
<br />
The W3C HTML Working Group has an escalation process that in some cases results in a decision being made that differs from the editor's original decision on a topic. So far, whenever this has happened the WHATWG has gone along with the W3C's request; nothing of especially big importance has been changed in this manner so far (it's mostly been editorial issues or mostly minor technical issues). In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]<br />
<br />
== Mailing List ==<br />
<br />
=== Should I top-post or reply inline? ===<br />
<br />
'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.<br />
<br />
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs&diff=5761Specs2011-01-12T09:01:06Z<p>Ms2ger: /* Media-Specific Layer */ +requestAnimationFrame</p>
<hr />
<div>This wiki page lists all the specifications that a Web browser is likely to implement.<br />
<br />
For each spec, link the spec's title to the most up to date draft (typically the editor's draft, for specs written in public; for specs written in secret, the latest published working draft), followed by a comma separated list of links in parentheses, named "feedback" for links to the current pending feedback, "discussion" for a link to the archives of the main relevant mailing list or to a page describing relevant mailing lists, "bugs" for a link to a bug system query showing the current open bugs. For specifications that are published in multiple forms, link to the most complete version (e.g. link to the one-page complete.html WHATWG spec rather than all the split-out W3C drafts).<br />
<br />
See also: [[Companion specifications|Specs without editors]]<br />
<br />
== Network Layer ==<br />
* [http://tools.ietf.org/wg/httpbis/ HTTP]<br />
* [http://tools.ietf.org/html/rfc0959 FTP]<br />
* [http://tools.ietf.org/html/rfc5246 TLS]<br />
* [http://tools.ietf.org/html/draft-ietf-httpstate-cookie Cookies]<br />
* [http://tools.ietf.org/html/draft-ietf-websec-origin Origin]<br />
<br />
== Infrastructure ==<br />
<br />
* Unicode<br />
* WebIDL<br />
* [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM Core] ([http://lists.w3.org/Archives/Public/public-webapps/ discussion])<br />
* [http://www.w3.org/TR/xml/ XML]<br />
* [http://www.w3.org/TR/xml-names/ XMLNS]<br />
* [http://www.w3.org/TR/xmlbase/ <code>xml:base</code>] ([http://lists.w3.org/Archives/Public/www-xml-linking-comments/ discussion])<br />
<br />
== Media-Independent Features ==<br />
<br />
* [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] ([http://www.whatwg.org/issues/ feedback], [http://www.whatwg.org/mailing-list discussion], [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=ian%40hixie.ch&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Last+Changed&field0-0-0=noop&type0-0-0=noop&value0-0-0= bugs])<br />
* [http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization]<br />
* [http://html5.org/specs/dom-range.html DOM Range] ([http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&amp;component=DOM%20Range&amp;resolution=--- bugs])<br />
* [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html WebGL]<br />
* [http://monet.nag.co.uk/~dpc/draft-spec/ MathML] ([http://lists.w3.org/Archives/Public/www-math/ discussion])<br />
* Clipboard ([http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/att-1067/cbapispec.html temp draft])<br />
<br />
== Media-Specific Layer ==<br />
<br />
* [http://www.w3.org/TR/CSS21/ CSS] ([http://lists.w3.org/Archives/Public/www-style/latest discussion])<br />
** [http://dev.w3.org/csswg/css3-color/ CSS Color]<br />
* [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF]<br />
* [http://www.w3.org/TR/PNG/ PNG]<br />
* [http://www.w3.org/TR/SVG/ SVG]<br />
* [http://people.mozilla.org/~cmccormack/anim-timing/Overview.html Timing control for script-based animations] ([irc://irc.freenode.net/whatwg discussion])</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Web_Encodings&diff=5744Web Encodings2011-01-06T13:34:15Z<p>Ms2ger: /* Encodings */ Add link</p>
<hr />
<div>Attempt at fixing the Web encoding problem.<br />
<br />
== Goals ==<br />
<br />
* Document existing practices by describing for each browser <br />
** The list of supported encodings.<br />
** The list of supported labels for those encodings.<br />
** The matching algorithm for labels.<br />
* Converge the various used algorithms by<br />
** Defining a list of encodings everyone has to support. Browsers must not support more encodings than on that list.<br />
** Defining a list of supported labels for those encodings. Browsers must not support more labels than on that list.<br />
** Defining the matching algorithm. (HTML5 has been updated with a better one now.)<br />
* Get the new rules implemented<br />
<br />
Documenting more exactly the encoding (Unicode stream + encoding -> byte stream) and decoding (byte stream + encoding -> Unicode stream) algorithms for each encoding and getting that implemented interoperably would also be great.<br />
<br />
== Current Implementations ==<br />
<br />
Does this differ per platform? Opera might differ a bit on Mac.<br />
<br />
=== Data ===<br />
<br />
Integrate this awesome data somehow:<br />
<br />
* http://coq.no/character-tables/mime/en<br />
* http://coq.no/character-tables/mime/iso-2022/en<br />
* http://coq.no/character-tables/mime/euc/en<br />
* http://coq.no/character-tables/mime/locale-specific/en<br />
<br />
=== Opera ===<br />
<br />
==== Matching ====<br />
<br />
UTS22 and strips leading x characters. (For now, plan is to switch to removing leading and trailing whitespace and ASCII case-insensitive matching afterwards in the future.)<br />
<br />
==== Encodings ====<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
!colspan=2| Encoding<br />
!| Labels<br />
!| Decoded As<br />
!| Notes<br />
|-<br />
|-<br />
|style="text-align:center"| 7-bit<br />
| us-ascii<br />
| ansix341968, ansix341986, ascii, cp367, csascii, csinvariant, csiso646basic1983, ibm367, invariant, iso646basic1983, iso646irv1991, iso646us, isoir6, ref, us, usascii<br />
| windows-1252<br />
|<br />
|-<br />
|style="text-align:center"| DOS<br />
| ibm866<br />
| 866, cp866, csibm866, ibm866<br />
|<br />
|<br />
|-<br />
|rowspan=16 style="text-align:center"|ISO<br />
| iso-8859-1<br />
| cp819, csisolatin1, ibm819, iso88591, iso885911987, isoir100, l1, latin1<br />
| windows-1252<br />
|<br />
|-<br />
| iso-8859-2<br />
| csisolatin2, iso88592, iso885921987, isoir101, l2, latin2<br />
|<br />
|<br />
|-<br />
| iso-8859-3<br />
| csisolatin3, iso88593, iso885931988, isoir109, l3, latin3<br />
|<br />
|<br />
|-<br />
| iso-8859-4<br />
| csisolatin4, iso88594, iso885941988, isoir110, l4, latin4<br />
|<br />
|<br />
|-<br />
| iso-8859-5<br />
| csisolatincyrillic, cyrillic, iso88595, iso885951988, isoir144<br />
|<br />
|<br />
|-<br />
| iso-8859-6<br />
| arabic, asmo708, csiso88596e, csisolatinarabic, ecma114, iso88596, iso885961987, iso88596e, isoir127<br />
|<br />
|<br />
|-<br />
| iso-8859-6-i<br />
| csiso88596i, iso88596i<br />
|<br />
|<br />
|-<br />
| iso-8859-7<br />
| csisolatingreek, ecma118, elot928, greek, greek8, iso88597, iso885971987, isoir126<br />
|<br />
|<br />
|-<br />
| iso-8859-8<br />
| csiso88598e, csisolatinhebrew, hebrew, iso88598, iso885981988, iso88598e, isoir138, visual<br />
|<br />
|<br />
|-<br />
| iso-8859-8-i<br />
| csiso88598i, iso88598i<br />
|<br />
|<br />
|-<br />
| iso-8859-9<br />
| csisolatin5, iso88599, iso885991989, isoir148, l5, latin5<br />
|<br />
|<br />
|-<br />
| iso-8859-10<br />
| csisolatin6, iso885910, iso8859101992, isoir157, l6, latin6<br />
|<br />
|<br />
|-<br />
| iso-8859-13<br />
| iso885913<br />
|<br />
|<br />
|-<br />
| iso-8859-14<br />
| iso885914, iso8859141998, isoceltic, isoir199, l8, latin8<br />
|<br />
|<br />
|-<br />
| iso-8859-15<br />
| iso885915, latin9<br />
|<br />
|<br />
|-<br />
| iso-8859-16<br />
| iso885916, iso8859162001, isoir226, l10, latin10<br />
|<br />
|<br />
|-<br />
|rowspan=11 style="text-align:center"|Win<br />
| iso-8859-11<br />
| iso885911, tis620, tis6202533, windows874<br />
|<br />
| Actually implemented as windows-874<br />
|-<br />
| windows-1250<br />
| cp1250, microsoftcp1250, windows1250<br />
|<br />
|<br />
|-<br />
| windows-1251<br />
| cp1251, microsoftcp1251, windows1251<br />
|<br />
|<br />
|-<br />
| windows-1252<br />
| cp1252, microsoftcp1252, windows1252<br />
|<br />
|<br />
|-<br />
| windows-1253<br />
| cp1253, microsoftcp1253, windows1253<br />
|<br />
|<br />
|-<br />
| windows-1254<br />
| cp1254, microsoftcp1254, windows1254<br />
|<br />
|<br />
|-<br />
| windows-1255<br />
| cp1255, microsoftcp1255, windows1255<br />
|<br />
|<br />
|-<br />
| windows-1256<br />
| cp1256, microsoftcp1256, windows1256<br />
|<br />
|<br />
|-<br />
| windows-1257<br />
| cp1257, microsoftcp1257, windows1257<br />
|<br />
|<br />
|-<br />
| windows-1258<br />
| cp1258, microsoftcp1258, windows1258<br />
|<br />
|<br />
|-<br />
| windows-sami-2<br />
| samiws2, windowssami2, ws2<br />
|<br />
|<br />
|-<br />
|rowspan=5 style="text-align:center"|Mac<br />
| macintosh<br />
| csmacintosh, mac, macintosh, macroman<br />
|<br />
| Likely disabled.<br />
|-<br />
| x-mac-ce<br />
| macce<br />
|<br />
| Likely disabled.<br />
|-<br />
| x-mac-cyrillic<br />
| maccyrillic<br />
|<br />
| Likely disabled.<br />
|-<br />
| x-mac-greek<br />
| macgreek<br />
|<br />
| Likely disabled.<br />
|-<br />
| x-mac-turkish<br />
| macturkish<br />
|<br />
| Likely disabled.<br />
|-<br />
|rowspan=5 style="text-align:center"|Misc.<br />
| koi8-r<br />
| cskoi8r, koi8r<br />
|<br />
|<br />
|-<br />
| koi8-u<br />
| koi8u<br />
|<br />
|<br />
|-<br />
| tcvn<br />
| tcvn, viettcvn<br />
|<br />
|<br />
|-<br />
| viscii<br />
| csviscii, viscii<br />
|<br />
|<br />
|-<br />
| x-vps<br />
| vps<br />
|<br />
|<br />
|-<br />
|rowspan=13 style="font-size:200%; line-height:100%; text-align:center"|中<br>日<br>韓<br />
| big5<br />
| big5, cnbig5, csbig5<br />
|<br />
|<br />
|-<br />
| big5-hkscs<br />
| big5hkscs<br />
|<br />
|<br />
|-<br />
| euc-jp<br />
| cseucpkdfmtjapanese, eucjp, extendedunixcodepackedformatforjapanese<br />
|<br />
|<br />
|-<br />
| euc-kr<br />
| cseuckr, csksc56011987, euckr, isoir149, korean, ksc5601, ksc56011987, ksc56011989, windows949<br />
|<br />
|<br />
|-<br />
| euc-tw<br />
| euctw<br />
|<br />
|<br />
|-<br />
| gb18030<br />
| gb18030<br />
|<br />
|<br />
|-<br />
| gbk<br />
| chinese, cngb, cp936, csgb2312, csiso58gb231280, euccn, gb2312, gb231280, gbk, isoir58, ms936, windows936<br />
|<br />
|<br />
|-<br />
| hz-gb-2312<br />
| hzgb2312<br />
|<br />
|<br />
|-<br />
| iso-2022-cn<br />
| iso2022cn<br />
|<br />
|<br />
|-<br />
| iso-2022-jp<br />
| csiso2022jp, iso2022jp<br />
|<br />
|<br />
|-<br />
| iso-2022-jp-1<br />
| iso2022jp1<br />
|<br />
|<br />
|-<br />
| iso-2022-kr<br />
| csiso2022kr, iso2022kr<br />
|<br />
|<br />
|-<br />
| shift_jis<br />
| cp932, csshiftjis, cswindows31j, ms932, mskanji, shiftjis, sjis, windows31j<br />
|<br />
|<br />
|-<br />
|rowspan=4 style="font-size:200%; text-align:center"|�<br />
| utf-16<br />
| csunicode, csunicode11, csunicodeascii, iso10646j1, iso10646ucs2, iso10646ucsbasic, utf16<br />
|<br />
|<br />
|-<br />
| utf-16be<br />
| utf16be<br />
|<br />
|<br />
|-<br />
| utf-16le<br />
| utf16le<br />
|<br />
|<br />
|-<br />
| utf-8<br />
| utf8<br />
|<br />
|<br />
|}<br />
<br />
=== Firefox ===<br />
<br />
==== Matching ====<br />
<br />
ASCII lowercasing.<br />
<br />
==== Encodings ====<br />
See https://wiki.mozilla.org/I18n:Charset_Aliases<br />
<br />
{| class=wikitable<br />
|-<br />
!colspan=2| Encoding<br />
! Labels<br />
! Decoded As<br />
! Notes<br />
|-<br />
|style="text-align:center"| 7-bit<br />
| us-ascii<br />
| 646, ansi_x3.4-1968, ascii, us-ascii<br />
| windows-1252<br />
|<br />
|-<br />
|rowspan=8 style="text-align:center"| DOS<br />
| IBM850<br />
| 850, cp850, csIBM850, ibm850<br />
|<br />
| csIBM850 not recognised.<br />
|-<br />
| IBM852<br />
| 852, cp852, csIBM852, ibm852<br />
|<br />
| csIBM852 not recognised.<br />
|-<br />
| IBM855<br />
| 855, cp855, csIBM855, ibm855<br />
|<br />
| csIBM855 not recognised.<br />
|-<br />
| IBM857<br />
| 857, cp857, csIBM857, ibm857<br />
|<br />
| csIBM857 not recognised.<br />
|-<br />
| IBM862<br />
| 862, cp862, csIBM862, ibm862<br />
|<br />
| csIBM862 not recognised.<br />
|-<br />
| IBM864<br />
| 864, cp864, csIBM864, ibm-864, ibm864<br />
|<br />
| csIBM864 not recognised.<br />
|-<br />
| IBM864i<br />
| 864i, cp864i, csibm864i, ibm-864i, ibm864i<br />
|<br />
|<br />
|-<br />
| IBM866<br />
| 866, cp-866, cp866, csIBM866, ibm866<br />
|<br />
| csIBM866 not recognised.<br />
|-<br />
|rowspan=19 style="text-align:center"|ISO<br />
| ISO-8859-1<br />
| cp819, csisolatin1, ibm819, iso-8859-1, iso-ir-100, iso8859-1, iso88591, iso_8859-1, l1, latin1<br />
| windows-1252<br />
|<br />
|-<br />
| ISO-8859-2<br />
| csisolatin2, iso-8859-2, iso-ir-101, iso8859-2, iso88592, iso_8859-2, l2, latin2<br />
|<br />
|<br />
|-<br />
| ISO-8859-3<br />
| csisolatin3, iso-8859-3, iso-ir-109, iso8859-3, iso88593, iso_8859-3, l3, latin3<br />
|<br />
|<br />
|-<br />
| ISO-8859-4<br />
| csisolatin4, iso-8859-4, iso-ir-110, iso8859-4, iso88594, iso_8859-4, l4, latin4<br />
|<br />
|<br />
|-<br />
| ISO-8859-5<br />
| csisolatincyrillic, cyrillic, iso-8859-5, iso-ir-144, iso8859-5, iso88595, iso_8859-5<br />
|<br />
|<br />
|-<br />
| ISO-8859-6<br />
| arabic, asmo-708, csisolatinarabic, ecma-114, iso-8859-6, iso-ir-127, iso8859-6, iso88596, iso_8859-6<br />
|<br />
|<br />
|-<br />
| ISO-8859-6-E<br />
| csiso88596e, iso-8859-6-e<br />
|<br />
|<br />
|-<br />
| ISO-8859-6-I<br />
| csiso88596i, iso-8859-6-i<br />
|<br />
|<br />
|-<br />
| ISO-8859-7<br />
| csisolatingreek, ecma-118, elot_928, greek, greek8, iso-8859-7, iso-ir-126, iso8859-7, iso88597, iso_8859-7, sun_eu_greek<br />
|<br />
|<br />
|-<br />
| ISO-8859-8<br />
| csisolatinhebrew, hebrew, iso-8859-8, iso-ir-138, iso8859-8, iso88598, iso_8859-8, visual<br />
|<br />
|<br />
|-<br />
| ISO-8859-8-E<br />
| csiso88598e, iso-8859-8-e<br />
|<br />
|<br />
|-<br />
| ISO-8859-8-I<br />
| csiso88598i, iso-8859-8-i, iso-8859-8i<br />
|<br />
|<br />
|-<br />
| ISO-8859-9<br />
| csisolatin5, iso-8859-9, iso-ir-148, iso8859-9, iso88599, iso_8859-9, l5, latin5<br />
|<br />
|<br />
|-<br />
| ISO-8859-10<br />
| csisolatin6, iso-8859-10, iso-ir-157, iso8859-10, iso885910, l6, latin6<br />
|<br />
|<br />
|-<br />
| ISO-8859-11<br />
| iso-8859-11, iso8859-11, iso885911<br />
| windows-874<br />
|<br />
|-<br />
| ISO-8859-13<br />
| iso-8859-13, iso8859-13, iso885913<br />
|<br />
|<br />
|-<br />
| ISO-8859-14<br />
| iso-8859-14, iso8859-14, iso885914<br />
|<br />
|<br />
|-<br />
| ISO-8859-15<br />
| iso-8859-15, iso8859-15, iso885915, iso_8859-15<br />
|<br />
|<br />
|-<br />
| ISO-8859-16<br />
| iso-8859-16<br />
|<br />
|<br />
|-<br />
|rowspan=10 style="text-align:center"|Win<br />
| windows-874<br />
| ibm874, windows-874<br />
|<br />
|<br />
|-<br />
| windows-1250<br />
| cp1250, windows-1250, x-cp1250<br />
|<br />
|<br />
|-<br />
| windows-1251<br />
| ansi-1251, cp1251, windows-1251, x-cp1251<br />
|<br />
|<br />
|-<br />
| windows-1252<br />
| cp1252, windows-1252, x-cp1252<br />
|<br />
|<br />
|-<br />
| windows-1253<br />
| cp1253, windows-1253, x-cp1253<br />
|<br />
|<br />
|-<br />
| windows-1254<br />
| cp1254, windows-1254, x-cp1254<br />
|<br />
|<br />
|-<br />
| windows-1255<br />
| cp1255, windows-1255, x-cp1255<br />
|<br />
|<br />
|-<br />
| windows-1256<br />
| cp1256, windows-1256, x-cp1256<br />
|<br />
|<br />
|-<br />
| windows-1257<br />
| cp1257, windows-1257, x-cp1257<br />
|<br />
|<br />
|-<br />
| windows-1258<br />
| cp1258, windows-1258, x-cp1258<br />
|<br />
|<br />
|-<br />
|rowspan=15 style="text-align:center"|Mac<br />
| x-mac-arabic<br />
| x-mac-arabic<br />
|<br />
|<br />
|-<br />
| x-mac-ce<br />
| x-mac-ce<br />
|<br />
|<br />
|-<br />
| x-mac-croatian<br />
| x-mac-croatian<br />
|<br />
|<br />
|-<br />
| x-mac-cyrillic<br />
| x-mac-cyrillic<br />
|<br />
|<br />
|-<br />
| x-mac-devanagari<br />
| x-mac-devanagari<br />
|<br />
|<br />
|-<br />
| x-mac-farsi<br />
| x-mac-farsi<br />
|<br />
|<br />
|-<br />
| x-mac-greek<br />
| x-mac-greek<br />
|<br />
|<br />
|-<br />
| x-mac-gujarati<br />
| x-mac-gujarati<br />
|<br />
|<br />
|-<br />
| x-mac-gurmukhi<br />
| x-mac-gurmukhi<br />
|<br />
|<br />
|-<br />
| x-mac-hebrew<br />
| x-mac-hebrew<br />
|<br />
|<br />
|-<br />
| x-mac-icelandic<br />
| x-mac-icelandic<br />
|<br />
|<br />
|-<br />
| x-mac-roman<br />
| csMacintosh, mac, macintosh, x-mac-roman<br />
|<br />
| csMacintosh not recognised.<br />
|-<br />
| x-mac-romanian<br />
| x-mac-romanian<br />
|<br />
|<br />
|-<br />
| x-mac-turkish<br />
| x-mac-turkish<br />
|<br />
|<br />
|-<br />
| x-mac-ukrainian<br />
| x-mac-ukrainian<br />
|<br />
|<br />
|-<br />
|rowspan=11 style="text-align:center"|Misc.<br />
| armscii-8<br />
| armscii-8<br />
|<br />
|<br />
|-<br />
| GEOSTD8<br />
| geostd8<br />
|<br />
| Does not seem to work.<br />
|-<br />
| ISO-IR-111<br />
| csiso111ecmacyrillic, ecma-cyrillic, iso-ir-111<br />
|<br />
|<br />
|-<br />
| KOI8-R<br />
| koi8-r<br />
|<br />
|<br />
|-<br />
| KOI8-U<br />
| koi8-u<br />
|<br />
|<br />
|-<br />
| T.61-8bit<br />
| csiso103t618bit, iso-ir-103, t.61, t.61-8bit<br />
|<br />
|<br />
|-<br />
| TIS-620<br />
| tis-620, tis620<br />
| windows-874<br />
|<br />
|-<br />
| VISCII<br />
| csviscii, viscii<br />
|<br />
|<br />
|-<br />
| x-user-defined<br />
| x-user-defined<br />
|<br />
|<br />
|-<br />
| x-viet-tcvn5712<br />
| x-viet-tcvn5712<br />
|<br />
|<br />
|-<br />
| x-viet-vps<br />
| x-viet-vps<br />
|<br />
|<br />
|-<br />
|rowspan=16 style="font-size:200%; line-height:100%; text-align:center"|中<br>日<br>韓<br />
| Big5<br />
| big5, csbig5, x-x-big5, zh_tw-big5<br />
|<br />
|<br />
|-<br />
| Big5-HKSCS<br />
| big5-hkscs<br />
|<br />
|<br />
|-<br />
| EUC-JP<br />
| cseucjpkdfmtjapanese, euc-jp, x-euc-jp<br />
|<br />
|<br />
|-<br />
| EUC-KR<br />
| 5601, csksc56011987, csueckr, euc-kr, iso-ir-149, korean, ks_c_5601-1989, ksc5601, ksc_5601<br />
| x-windows-949<br />
| This converter is assymetric. In ToUnicode direction, it is generous and acts as Windows-949. It also supports 8-byte sequences for 8,822 Hangul syllables not encoded as precomposed forms in KS X 1001. In FromUnicode direction, it is strict and generate 8-byte sequences for those 8,822 Hangul syllables instead of 2-byte sequences in windows-949. <br />
|-<br />
| gb18030<br />
| gb18030<br />
|<br />
|<br />
|-<br />
| GB2312<br />
| chinese, csgb2312, csiso58gb231280, gb2312, gb_2312, gb_2312-80, iso-ir-58, zh_cn.euc<br />
| x-gbk<br />
|<br />
|-<br />
| HZ-GB-2312<br />
| hz-gb-2312<br />
|<br />
|<br />
|-<br />
| ISO-2022-CN<br />
| iso-2022-cn, iso-2022-cn-ext<br />
|<br />
|<br />
|-<br />
| ISO-2022-JP<br />
| csiso2022jp, csiso2022jp2, iso-2022-jp, iso-2022-jp-2<br />
|<br />
|<br />
|-<br />
| ISO-2022-KR<br />
| csiso2022kr, iso-2022-kr<br />
|<br />
|<br />
|-<br />
| Shift_JIS<br />
| csshiftjis, ms_kanji, shift-jis, shift_jis, windows-31j, x-sjis<br />
|<br />
|<br />
|-<br />
| windows-936<br />
| windows-936<br />
|<br />
|<br />
|-<br />
| x-euc-tw<br />
| cns11643, x-euc-tw, zh_tw-euc<br />
|<br />
|<br />
|-<br />
| x-gbk<br />
| gbk, x-gbk<br />
|<br />
|<br />
|-<br />
| x-johab<br />
| x-johab<br />
|<br />
|<br />
|-<br />
| x-windows-949<br />
| ks_c_5601-1987, x-windows-949<br />
|<br />
|<br />
|-<br />
|rowspan=9 style="font-size:200%; text-align:center"|�<br />
| UTF-16<br />
| utf-16<br />
|<br />
| Recognized as BE or LE by BOM or byte sniffing<br />
|-<br />
| UTF-16BE<br />
| csunicode, csunicode11, csunicodeascii, csunicodelatin1, iso-10646, iso-10646-j-1, iso-10646-ucs-2, iso-10646-ucs-basic, iso-10646-unicode-latin1, utf-16be, x-iso-10646-ucs-2-be<br />
|<br />
|<br />
|-<br />
| UTF-16LE<br />
| utf-16le, x-iso-10646-ucs-2-le<br />
|<br />
|<br />
|-<br />
| UTF-32<br />
| utf-32<br />
|<br />
| Recognized as BE or LE by BOM or byte sniffing<br />
|-<br />
| UTF-32BE<br />
| iso-10646-ucs-4, utf-32be, x-iso-10646-ucs-4-be<br />
|<br />
|<br />
|-<br />
| UTF-32LE<br />
| utf-32le, x-iso-10646-ucs-4-le<br />
|<br />
|<br />
|-<br />
| UTF-7<br />
| csunicode11utf7, unicode-1-1-utf-7, unicode-2-0-utf-7, utf-7, x-unicode-2-0-utf-7<br />
|<br />
|<br />
|-<br />
| UTF-8<br />
| unicode-1-1-utf-8, utf-8, utf8<br />
|<br />
|<br />
|-<br />
| x-imap4-modified-utf7<br />
| x-imap4-modified-utf7<br />
|<br />
|<br />
|}<br />
<br />
Table generated from <http://mxr.mozilla.org/mozilla1.9.1/source/intl/uconv/src/charsetalias.properties> (corresponds to Firefox 3.5.2).<br />
<br />
Aliases (used for parsing, apparently not for serialisation) are scattered around in a large number of files; cf. <http://mxr.mozilla.org/firefox/source/intl/uconv/ucvlatin/nsISO885911ToUnicode.cpp> for the mapping from ISO-8859-11 to windows-874.<br />
<br />
8-bit encodings (excluding UTFs, CJK encodings and T.61) tested using <http://coq.no/X/charset5/tests8bit.html> (fail/pass should not be taken too seriously yet, especially not for more obscure encodings), Firefox version 3.5.1, OS X.<br />
<br />
'''Bugs:''' Filed <https://bugzilla.mozilla.org/show_bug.cgi?id=512060> for the labels marked 'not recognised' in the table above since the lack of support for these is clearly accidental rather than deliberate (though it seems to suggest that these particular labels are not particularly widely used). In most other cases, research and deliberation will be needed to distinguish between bugs and features.<br />
<br />
=== Internet Explorer ===<br />
<br />
==== Matching ====<br />
<br />
Strips leading and trailing whitespace and then does ASCII(?) case-insensitive matching. (Matches HTML5.)<br />
<br />
==== Encodings ====<br />
<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
!colspan=2| Encoding<br />
!| Labels<br />
!| Decoded As<br />
!| Notes<br />
|-<br />
|rowspan=5 style="text-align:center"|7-bit<br />
| us-ascii<br />
| ansi_x3.4-1968, ansi_x3.4-1986, ascii, cp367, csascii, ibm367, iso-ir-6, iso646-us, iso_646.irv:1991, us, us-ascii<br />
|<br />
| (code page: 20127)<br />
|-<br />
| x-ia5<br />
| irv, x-ia5<br />
|<br />
| (code page: 20105) Most significant bit ignored.<br />
|-<br />
| x-ia5-german<br />
| din_66003, german, x-ia5-german<br />
|<br />
| (code page: 20106) Most significant bit ignored.<br />
|-<br />
| x-ia5-norwegian<br />
| norwegian, ns_4551-1, x-ia5-norwegian<br />
|<br />
| (code page: 20108) Most significant bit ignored. Actually decoded as NS 4551-2, not NS 4551-1.<br />
|-<br />
| x-ia5-swedish<br />
| sen_850200_b, swedish, x-ia5-swedish<br />
|<br />
| (code page: 20107) Most significant bit ignored. Actually decoded as SEN 85 02 00 Annex C, not SEN 85 02 00 Annex B.<br />
|-<br />
|rowspan=17 style="text-align:center"|DOS<br />
| cp866<br />
| cp866, ibm866<br />
|<br />
| (code page: 866)<br />
|-<br />
| dos-720<br />
| dos-720<br />
|<br />
| (code page: 720)<br />
|-<br />
| dos-862<br />
| cp862, dos-862, ibm862<br />
|<br />
| (code page: 862)<br />
|-<br />
| ibm00858<br />
| ccsid00858, cp00858, cp858, ibm00858, pc-multilingual-850+euro<br />
|<br />
| (code page: 858)<br />
|-<br />
| ibm437<br />
| 437, cp437, cspc8codepage437, ibm437<br />
|<br />
| (code page: 437)<br />
|-<br />
| ibm737<br />
| ibm737<br />
|<br />
| (code page: 737)<br />
|-<br />
| ibm775<br />
| ibm775<br />
|<br />
| (code page: 775)<br />
|-<br />
| ibm850<br />
| cp850, ibm850<br />
|<br />
| (code page: 850)<br />
|-<br />
| ibm852<br />
| cp852, ibm852<br />
|<br />
| (code page: 852)<br />
|-<br />
| ibm855<br />
| cp855, ibm855<br />
|<br />
| (code page: 855)<br />
|-<br />
| ibm857<br />
| cp857, ibm857<br />
|<br />
| (code page: 857)<br />
|-<br />
| ibm860<br />
| cp860, ibm860<br />
|<br />
| (code page: 860)<br />
|-<br />
| ibm861<br />
| cp861, ibm861<br />
|<br />
| (code page: 861)<br />
|-<br />
| ibm863<br />
| cp863, ibm863<br />
|<br />
| (code page: 863)<br />
|-<br />
| ibm864<br />
| cp864, ibm864<br />
|<br />
| (code page: 864)<br />
|-<br />
| ibm865<br />
| cp865, ibm865<br />
|<br />
| (code page: 865)<br />
|-<br />
| ibm869<br />
| cp869, ibm869<br />
|<br />
| (code page: 869)<br />
|-<br />
|rowspan=12 style="text-align:center"|ISO<br />
| iso-8859-1<br />
| cp819, csisolatin1, ibm819, iso-8859-1, iso-ir-100, iso8859-1, iso_8859-1, iso_8859-1:1987, l1, latin1<br />
| windows-1252<br />
| (code page: 28591)<br />
|-<br />
| iso-8859-2<br />
| csisolatin2, iso-8859-2, iso-ir-101, iso8859-2, iso_8859-2, iso_8859-2:1987, l2, latin2<br />
|<br />
| (code page: 28592)<br />
|-<br />
| iso-8859-3<br />
| csisolatin3, iso-8859-3, iso-ir-109, iso_8859-3, iso_8859-3:1988, l3, latin3<br />
|<br />
| (code page: 28593)<br />
|-<br />
| iso-8859-4<br />
| csisolatin4, iso-8859-4, iso-ir-110, iso_8859-4, iso_8859-4:1988, l4, latin4<br />
|<br />
| (code page: 28594)<br />
|-<br />
| iso-8859-5<br />
| csisolatincyrillic, cyrillic, iso-8859-5, iso-ir-144, iso_8859-5, iso_8859-5:1988<br />
|<br />
| (code page: 28595)<br />
|-<br />
| iso-8859-6<br />
| arabic, csisolatinarabic, ecma-114, iso-8859-6, iso-ir-127, iso_8859-6, iso_8859-6:1987<br />
|<br />
| (code page: 28596)<br />
|-<br />
| iso-8859-7<br />
| csisolatingreek, ecma-118, elot_928, greek, greek8, iso-8859-7, iso-ir-126, iso_8859-7, iso_8859-7:1987<br />
|<br />
| (code page: 28597)<br />
|-<br />
| iso-8859-8<br />
| csisolatinhebrew, hebrew, iso-8859-8, iso-8859-8 visual, iso-ir-138, iso_8859-8, iso_8859-8:1988, logical, visual<br />
| windows-1254<br />
| (code page: 28598)<br />
|-<br />
| iso-8859-8-i<br />
| iso-8859-8-i<br />
|<br />
| (code page: 38598)<br />
|-<br />
| iso-8859-9<br />
| csisolatin5, iso-8859-9, iso-ir-148, iso_8859-9, iso_8859-9:1989, l5, latin5<br />
|<br />
| (code page: 28599)<br />
|-<br />
| iso-8859-13<br />
| iso-8859-13<br />
|<br />
| (code page: 28603)<br />
|-<br />
| iso-8859-15<br />
| csisolatin9, iso-8859-15, iso_8859-15, l9, latin9<br />
|<br />
| (code page: 28605)<br />
|-<br />
|rowspan=10 style="text-align:center"|Win<br />
| windows-874<br />
| dos-874, iso-8859-11, tis-620, windows-874<br />
|<br />
| (code page: 874)<br />
|-<br />
| windows-1250<br />
| windows-1250, x-cp1250<br />
|<br />
| (code page: 1250)<br />
|-<br />
| windows-1251<br />
| windows-1251, x-cp1251<br />
|<br />
| (code page: 1251)<br />
|-<br />
| windows-1252<br />
| windows-1252, x-ansi<br />
|<br />
| (code page: 1252)<br />
|-<br />
| windows-1253<br />
| windows-1253<br />
|<br />
| (code page: 1253)<br />
|-<br />
| windows-1254<br />
| windows-1254<br />
|<br />
| (code page: 1254)<br />
|-<br />
| windows-1255<br />
| windows-1255<br />
|<br />
| (code page: 1255)<br />
|-<br />
| windows-1256<br />
| cp1256, windows-1256<br />
|<br />
| (code page: 1256)<br />
|-<br />
| windows-1257<br />
| windows-1257<br />
|<br />
| (code page: 1257)<br />
|-<br />
| windows-1258<br />
| windows-1258<br />
|<br />
| (code page: 1258)<br />
|-<br />
|rowspan=12 style="text-align:center"|Mac<br />
| macintosh<br />
| macintosh<br />
|<br />
| (code page: 10000)<br />
|-<br />
| x-mac-arabic<br />
| x-mac-arabic<br />
|<br />
| (code page: 10004)<br />
|-<br />
| x-mac-ce<br />
| x-mac-ce<br />
|<br />
| (code page: 10029)<br />
|-<br />
| x-mac-croatian<br />
| x-mac-croatian<br />
|<br />
| (code page: 10082)<br />
|-<br />
| x-mac-cyrillic<br />
| x-mac-cyrillic<br />
|<br />
| (code page: 10007)<br />
|-<br />
| x-mac-greek<br />
| x-mac-greek<br />
|<br />
| (code page: 10006)<br />
|-<br />
| x-mac-hebrew<br />
| x-mac-hebrew<br />
|<br />
| (code page: 10005)<br />
|-<br />
| x-mac-icelandic<br />
| x-mac-icelandic<br />
|<br />
| (code page: 10079)<br />
|-<br />
| x-mac-romanian<br />
| x-mac-romanian<br />
|<br />
| (code page: 10010)<br />
|-<br />
| x-mac-thai<br />
| x-mac-thai<br />
|<br />
| (code page: 10021)<br />
|-<br />
| x-mac-turkish<br />
| x-mac-turkish<br />
|<br />
| (code page: 10081)<br />
|-<br />
| x-mac-ukrainian<br />
| x-mac-ukrainian<br />
|<br />
| (code page: 10017)<br />
|-<br />
|rowspan=16 style="text-align:center"|Misc.<br />
| asmo-708<br />
| asmo-708<br />
|<br />
| (code page: 708)<br />
|-<br />
| koi8-r<br />
| cskoi8r, koi, koi8, koi8-r, koi8r<br />
|<br />
| (code page: 20866)<br />
|-<br />
| koi8-u<br />
| koi8-ru, koi8-u<br />
|<br />
| (code page: 21866)<br />
|-<br />
| x-cp20261<br />
| x-cp20261<br />
|<br />
| (code page: 20261) T.61 / ISO/IEC_6937<br />
|-<br />
| x-cp20269<br />
| x-cp20269<br />
|<br />
| (code page: 20269) T.61 / ISO/IEC_6937 (non-combining accents?)<br />
|-<br />
| x-europa<br />
| x-europa<br />
|<br />
| (code page: 29001) What is this?<br />
|-<br />
| x-iscii-as<br />
| x-iscii-as<br />
|<br />
| (code page: 57006)<br />
|-<br />
| x-iscii-be<br />
| x-iscii-be<br />
|<br />
| (code page: 57003)<br />
|-<br />
| x-iscii-de<br />
| x-iscii-de<br />
|<br />
| (code page: 57002)<br />
|-<br />
| x-iscii-gu<br />
| x-iscii-gu<br />
|<br />
| (code page: 57010)<br />
|-<br />
| x-iscii-ka<br />
| x-iscii-ka<br />
|<br />
| (code page: 57008)<br />
|-<br />
| x-iscii-ma<br />
| x-iscii-ma<br />
|<br />
| (code page: 57009)<br />
|-<br />
| x-iscii-or<br />
| x-iscii-or<br />
|<br />
| (code page: 57007)<br />
|-<br />
| x-iscii-pa<br />
| x-iscii-pa<br />
|<br />
| (code page: 57011)<br />
|-<br />
| x-iscii-ta<br />
| x-iscii-ta<br />
|<br />
| (code page: 57004)<br />
|-<br />
| x-iscii-te<br />
| x-iscii-te<br />
|<br />
| (code page: 57005)<br />
|-<br />
|rowspan=27 style="font-size:200%; line-height:100%; text-align:center"|中<br>日<br>韓<br />
| big5<br />
| big5, big5-hkscs, cn-big5, csbig5, x-x-big5<br />
|<br />
| (code page: 950)<br />
|-<br />
| csiso2022jp<br />
| csiso2022jp<br />
|<br />
| (code page: 50221)<br />
|-<br />
| euc-cn<br />
| euc-cn, x-euc-cn<br />
|<br />
| (code page: 51936)<br />
|-<br />
| euc-jp<br />
| cseucpkdfmtjapanese, euc-jp, extended_unix_code_packed_format_for_japanese, iso-2022-jpeuc, x-euc, x-euc-jp<br />
|<br />
| (code page: 51932)<br />
|-<br />
| euc-kr<br />
| cseuckr, euc-kr, iso-2022-kr-8, iso-2022-kr-8bit<br />
|<br />
| (code page: 51949)<br />
|-<br />
| gb18030<br />
| gb18030<br />
|<br />
| (code page: 54936)<br />
|-<br />
| gb2312<br />
| chinese, cn-gb, csgb2312, csgb231280, csiso58gb231280, gb2312, gb2312-80, gb231280, gbk, gb_2312-80, iso-ir-58<br />
|<br />
| (code page: 936) GBK superset. The "gb2312-80" label does not seem to work in IE8.<br />
|-<br />
| hz-gb-2312<br />
| hz-gb-2312<br />
|<br />
| (code page: 52936)<br />
|-<br />
| iso-2022-jp<br />
| iso-2022-jp<br />
|<br />
| (code page: 50220)<br />
|-<br />
| iso-2022-kr<br />
| csiso2022kr, iso-2022-kr, iso-2022-kr-7, iso-2022-kr-7bit<br />
|<br />
| (code page: 50225)<br />
|-<br />
| johab<br />
| johab<br />
|<br />
| (code page: 1361)<br />
|-<br />
| ks_c_5601-1987<br />
| csksc56011987, iso-ir-149, korean, ks-c-5601, ks-c5601, ksc5601, ksc_5601, ks_c_5601, ks_c_5601-1987, ks_c_5601-1989, ks_c_5601_1987<br />
|<br />
| (code page: 949) EUC-KR superset<br />
|-<br />
| shift_jis<br />
| csshiftjis, cswindows31j, ms_kanji, shift-jis, shift_jis, sjis, windows-31j, x-ms-cp932, x-sjis<br />
|<br />
| (code page: 932)<br />
|-<br />
| x-chinese-cns<br />
| x-chinese-cns<br />
|<br />
| (code page: 20000) EUC-TW<br />
|-<br />
| x-chinese-eten<br />
| x-chinese-eten<br />
|<br />
| (code page: 20002) Other encoding of the Taiwanese CNS character set.<br />
|-<br />
| x-cp20001<br />
| x-cp20001<br />
|<br />
| (code page: 20001) TW (not tested)<br />
|-<br />
| x-cp20003<br />
| x-cp20003<br />
|<br />
| (code page: 20003) TW (not tested)<br />
|-<br />
| x-cp20004<br />
| x-cp20004<br />
|<br />
| (code page: 20004) TW (not tested)<br />
|-<br />
| x-cp20005<br />
| x-cp20005<br />
|<br />
| (code page: 20005) TW (not tested)<br />
|-<br />
| x-mac-chinesesimp<br />
| x-mac-chinesesimp<br />
|<br />
| (code page: 10008) EUC-CN superset. Handled as plain ENC-CN?<br />
|-<br />
| x-mac-chinesetrad<br />
| x-mac-chinesetrad<br />
|<br />
| (code page: 10002) Big5 superset.<br />
|-<br />
| x-mac-japanese<br />
| x-mac-japanese<br />
|<br />
| (code page: 10001) Shift_JIS superset. Handled as Windows Shift_JIS?<br />
|-<br />
| x-mac-korean<br />
| x-mac-korean<br />
|<br />
| (code page: 10003) EUC-KR superset. Handled as plain EUC-KR?<br />
|-<br />
| x-cp20936<br />
| x-cp20936<br />
|<br />
| (code page: 20936) EUC-CN (not the GBK superset)<br />
|-<br />
| x-cp20949<br />
| x-cp20949<br />
|<br />
| (code page: 20949) EUC-KR (not the Windows superset)<br />
|-<br />
| x-cp50227<br />
| x-cp50227<br />
|<br />
| (code page: 50227) GBK, including at least some Windows extensions.<br />
|-<br />
| (???)<br />
| x-cp50229<br />
|<br />
| (code page: 50229) ISO-2022-CN subset? Includes GB 2312-80 (CN) and CNS 11643-1992 Plane 1 (TW).<br />
|-<br />
|rowspan=4 style="font-size:200%; text-align:center"|�<br />
| unicodefffe<br />
| unicodefffe, utf-16be<br />
|<br />
| (code page: 1201) UTF-16BE<br />
|-<br />
| utf-16<br />
| iso-10646-ucs-2, ucs-2, unicode, utf-16, utf-16le<br />
|<br />
| (code page: 1200) UTF-16LE. UCS-2 is not(!) taken to mean UTF-16.<br />
|-<br />
| utf-7<br />
| csunicode11utf7, unicode-1-1-utf-7, unicode-2-0-utf-7, utf-7, x-unicode-1-1-utf-7, x-unicode-2-0-utf-7<br />
|<br />
| (code page: 65000)<br />
|-<br />
| utf-8<br />
| unicode-1-1-utf-8, unicode-2-0-utf-8, utf-8, x-unicode-1-1-utf-8, x-unicode-2-0-utf-8<br />
|<br />
| (code page: 65001)<br />
|-<br />
|rowspan=35 style="text-align:center"|EBC<br>DIC<br />
| cp875<br />
| cp875<br />
|<br />
| (code page: 875) EBCDIC Greece<br />
|-<br />
| cp1025<br />
| cp1025<br />
|<br />
| (code page: 21025) EBCDIC Cyrilllic Multilingual<br />
|-<br />
| ibm-thai<br />
| csibmthai, ibm-thai<br />
|<br />
| (code page: 20838) EBCDIC Thailand<br />
|-<br />
| ibm00924<br />
| ccsid00924, cp00924, ebcdic-latin9--euro, ibm00924<br />
|<br />
| (code page: 20924) EBCDIC Latin 9<br />
|-<br />
| ibm01047<br />
| ibm01047<br />
|<br />
| (code page: 1047) EBCDIC Latin 1/Open Systems<br />
|-<br />
| ibm01140<br />
| ccsid01140, cp01140, ebcdic-us-37+euro, ibm01140<br />
|<br />
| (code page: 1140) EBCDIC USA, Canada, etc. ECECP<br />
|-<br />
| ibm01141<br />
| ccsid01141, cp01141, ebcdic-de-273+euro, ibm01141<br />
|<br />
| (code page: 1141) EBCDIC Austria, Germany ECECP<br />
|-<br />
| ibm01142<br />
| ccsid01142, cp01142, ebcdic-dk-277+euro, ebcdic-no-277+euro, ibm01142<br />
|<br />
| (code page: 1142) EBCDIC Denmark, Norway ECECP<br />
|-<br />
| ibm01143<br />
| ccsid01143, cp01143, ebcdic-fi-278+euro, ebcdic-se-278+euro, ibm01143<br />
|<br />
| (code page: 1143) EBCDIC Finland, Sweden ECECP<br />
|-<br />
| ibm01144<br />
| ccsid01144, cp01144, ebcdic-it-280+euro, ibm01144<br />
|<br />
| (code page: 1144) EBCDIC Italy ECECP<br />
|-<br />
| ibm01145<br />
| ccsid01145, cp01145, ebcdic-es-284+euro, ibm01145<br />
|<br />
| (code page: 1145) EBCDIC Spain, Latin America (Spanish)<br />
|-<br />
| ibm01146<br />
| ccsid01146, cp01146, ebcdic-gb-285+euro, ibm01146<br />
|<br />
| (code page: 1146) EBCDIC UK ECECP<br />
|-<br />
| ibm01147<br />
| ccsid01147, cp01147, ebcdic-fr-297+euro, ibm01147<br />
|<br />
| (code page: 1147) EBCDIC France ECECP<br />
|-<br />
| ibm01148<br />
| ccsid01148, cp01148, ebcdic-international-500+euro, ibm01148<br />
|<br />
| (code page: 1148) EBCDIC International ECECP<br />
|-<br />
| ibm01149<br />
| ccsid01149, cp01149, ebcdic-is-871+euro, ibm01149<br />
|<br />
| (code page: 1149) EBCDIC Iceland ECECP<br />
|-<br />
| ibm037<br />
| cp037, csibm037, ebcdic-cp-ca, ebcdic-cp-nl, ebcdic-cp-us, ebcdic-cp-wt, ibm037<br />
|<br />
| (code page: 37) EBCDIC USA/Canada - CECP<br />
|-<br />
| ibm1026<br />
| cp1026, csibm1026, ibm1026<br />
|<br />
| (code page: 1026) EBCDIC Latin #5 - Turkey<br />
|-<br />
| ibm273<br />
| cp273, csibm273, ibm273<br />
|<br />
| (code page: 20273) EBCDIC Germany F.R./Austria - CECP<br />
|-<br />
| ibm277<br />
| csibm277, ebcdic-cp-dk, ebcdic-cp-no, ibm277<br />
|<br />
| (code page: 20277) EBCDIC Denmark, Norway - CECP<br />
|-<br />
| ibm278<br />
| cp278, csibm278, ebcdic-cp-fi, ebcdic-cp-se, ibm278<br />
|<br />
| (code page: 20278) EBCDIC Finland, Sweden - CECP<br />
|-<br />
| ibm280<br />
| cp280, csibm280, ebcdic-cp-it, ibm280<br />
|<br />
| (code page: 20280) EBCDIC Italy - CECP<br />
|-<br />
| ibm284<br />
| cp284, csibm284, ebcdic-cp-es, ibm284<br />
|<br />
| (code page: 20284) EBCDIC Spain/Latin America - CECP<br />
|-<br />
| ibm285<br />
| cp285, csibm285, ebcdic-cp-gb, ibm285<br />
|<br />
| (code page: 20285) EBCDIC United Kingdom - CECP<br />
|-<br />
| ibm290<br />
| cp290, csibm290, ebcdic-jp-kana, ibm290<br />
|<br />
| (code page: 20290) EBCDIC Japanese (Katakana) Extended. Katakana replace lowercase EBCDIC.<br />
|-<br />
| ibm297<br />
| cp297, csibm297, ebcdic-cp-fr, ibm297<br />
|<br />
| (code page: 20297) EBCDIC France - CECP<br />
|-<br />
| ibm420<br />
| cp420, csibm420, ebcdic-cp-ar1, ibm420<br />
|<br />
| (code page: 20420) EBCDIC Arabic Bilingual<br />
|-<br />
| ibm423<br />
| cp423, csibm423, ebcdic-cp-gr, ibm423<br />
|<br />
| (code page: 20423) EBCDIC Greece - 183<br />
|-<br />
| ibm424<br />
| cp424, csibm424, ebcdic-cp-he, ibm424<br />
|<br />
| (code page: 20424) EBCDIC Israel (Hebrew)<br />
|-<br />
| ibm500<br />
| cp500, csibm500, ebcdic-cp-be, ebcdic-cp-ch, ibm500<br />
|<br />
| (code page: 500) EBCDIC International #5<br />
|-<br />
| ibm870<br />
| cp870, csibm870, ebcdic-cp-roece, ebcdic-cp-yu, ibm870<br />
|<br />
| (code page: 870) EBCDIC Latin 2, Multilingual<br />
|-<br />
| ibm871<br />
| cp871, csibm871, ebcdic-cp-is, ibm871<br />
|<br />
| (code page: 20871) EBCDIC Iceland<br />
|-<br />
| ibm880<br />
| cp880, csibm880, ebcdic-cyrillic, ibm880<br />
|<br />
| (code page: 20880) EBCDIC Cyrillic, Multilingual<br />
|-<br />
| ibm905<br />
| cp905, csibm905, ebcdic-cp-tr, ibm905<br />
|<br />
| (code page: 20905) EBCDIC Latin 3<br />
|-<br />
| x-ebcdic-koreanextended<br />
| x-ebcdic-koreanextended<br />
|<br />
| (code page: 20833) EBCDIC Korean (some variant)<br />
|-<br />
| (???)<br />
| x-cp21027<br />
|<br />
| (code page: 21027) EBCDIC Japanese (some variant). Certain EBCDIC letters/digits decoded incorrectly.<br />
|-<br />
|rowspan=6 style="text-align:center"|¿···?<br />
| (???)<br />
| cp930<br />
|<br />
| (code page: 50930) JAPAN MIX EBCDIC? Appears to be ASCII-compatible...<br />
|-<br />
| (???)<br />
| cp933<br />
|<br />
| (code page: 50933) KOREA MIX EBCDIC? Appears to be ASCII-compatible...<br />
|-<br />
| (???)<br />
| cp935<br />
|<br />
| (code page: 50935) S-CHINESE MIX EBCDIC? Appears to be ASCII-compatible...<br />
|-<br />
| (???)<br />
| cp937<br />
|<br />
| (code page: 50937) T-CHINESE MIX EBCDIC? Appears to be ASCII-compatible...<br />
|-<br />
| (???)<br />
| cp939<br />
|<br />
| (code page: 50939) JAPAN MIX EBCDIC? Appears to be ASCII-compatible...<br />
|-<br />
| (???)<br />
| x-ebcdic-japaneseanduscanada<br />
|<br />
| (code page: 50931) EBCDIC? Appears to be ASCII-compatible...<br />
|-<br />
|}<br />
<br />
All EBCDIC encodings contain the letters A–Z, a–z and the digits 0–9 in EBCDIC positions (unless there is a note in the table saying otherwise).<br />
<br />
==== Data ====<br />
<br />
Source for the encodings and labels data: http://lists.w3.org/Archives/Public/public-html-comments/2009Sep/att-0050/ie.encodings.txt<br />
<br />
Labels and code pages .NET supports: http://blogs.msdn.com/shawnste/archive/2009/08/18/alternate-encoding-names-recognized-by-net-ie.aspx (there should be few, if any, differences with the above)<br />
<br />
Different data for encodings and labels IE supports (might be more accurate): http://html5.org/temp/2009/ie-encodings.htm (original: http://web.archive.org/web/20080204211015/http://www.hitachi-to.co.jp/prod/prod_2/inter/emk/help/TextEncoder/CodePage.htm)<br />
<br />
=== Safari ===<br />
<br />
==== Matching ====<br />
<br />
UTS22<br />
<br />
==== Encodings ====<br />
<br />
FIXME<br />
<br />
==== Data ====<br />
<br />
Based on discussion with Maciej (Apple) archived here: http://krijnhoetmer.nl/irc-logs/whatwg/20090909#l-110<br />
<br />
Safari uses the system version of ICU on Mac (4.0 for Snow Leopard, 3.6 for Leopard and 3.2 for Tiger) and in addition supports TEC on Mac for encodings that are not in ICU. (Unclear how much of TEC is enabled.)<br />
<br />
On Windows Safari ships with ICU 4.0<br />
<br />
<hr><br />
<br />
According to webkit/WebCore/platform/text/TextCodecICU.cpp, WebKit now uses ICU <http://site.icu-project.org/> with additional aliases (webkit/WebCore/platform/text/TextCodecICU.cpp), additional encodings (webkit/WebCore/platform/text/mac/mac-encodings.txt) possibly implemented using TECM at least on the Mac, a list of official IANA labels (webkit/WebCore/platform/text/mac/character-sets.txt) and probably a few more which I have not noticed.<br />
<br />
ICU 4.2’s icu/source/data/mappings/convrtrs.txt or <http://demo.icu-project.org/icu-bin/convexp> lists encodings and labels not supported in Safari 4.0 on Leopard, and webkit/WebCore/platform/text/TextCodecICU.cpp mentions that Tiger included ICU 3.2.<br />
<br />
See also: http://trac.webkit.org/browser/trunk/WebCore/platform/text<br />
<br />
=== Chrome ===<br />
<br />
Similar to Safari with some customizations in ICU alias tables. Chrome 3.0 has ICU 3.8 plus customizations for EUC-JP (to match IE/Firefox). For EUC-KR and GBK, we use different mapping tables than used by Safari (which just uses ICU's default tables for them). ISO-8859-16 is also added.<br />
<br />
Chrome trunk uses ICU 4.2.<br />
<br />
== Thoughts ==<br />
<br />
===Anne===<br />
If it can be agreed upon that all non-UTF-8 and non-UTF-16 encodings are legacy encodings I personally would not mind advocating that we should drop support for US-ASCII and ISO-8859-1 completely in favor of Windows-1252 (and do the same for similar situations). I.e. that US-ASCII and ISO-8859-1 labels simply map to Windows-1252. This should simplify code a little bit as well.<br />
<br />
I also think that we should ban UTF-7, UTF-32 and all EBCDIC encodings. This is already mostly done by HTML5.<br />
<br />
<hr><br />
<br />
I wonder if we can standardize (document to start with) the encoding detection algorithm. The list of encodings is fixed. The list of legacy pages is also fairly fixed. The detection algorithms in browsers should be fairly stable. Certainly looks possible.<br />
<br />
===E-mails===<br />
WHATWG got these e-mails that we should make sure to cover as part of this:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021207.html<br />
* http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/023208.html<br />
<br />
===Spec notes===<br />
<br />
This is what the spec used to say about encodings:<br />
<br />
<pre><br />
<p>In addition, user agents must support the aliases given in the<br />
following table for every character encoding they support, so that<br />
labels from the first column are treated as equivalent to the labels<br />
given in the corresponding cell from the second column on the same<br />
row.</p><br />
<br />
<table><br />
<caption>Additional character encoding aliases</caption><br />
<thead><br />
<tr> <th> Alias <th> Corresponding encoding <th> References<br />
<tbody><br />
<tr> <td> x-sjis <td> windows-31J <td><br />
<a href="#refsSHIFTJIS">[SHIFTJIS]</a><br />
<a href="#refsWIN31J">[WIN31J]</a><br />
<tr> <td> windows-932 <td> windows-31J <td><br />
<a href="#refsWIN31J">[WIN31J]</a><br />
<tr> <td> x-x-big5 <td> Big5 <td><br />
<a href="#refsBIG5">[BIG5]</a><br />
</tbody><br />
</table><br />
</pre><br />
<br />
===ICU in Chrome and Safari===<br />
Giving a link to or actually including the info on what Safari and Chrome support would be nice. It seems like this would be at least a subset, but it sounds like more may have been added from the text above.<br />
<br />
http://demo.icu-project.org/icu-bin/convexp</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs&diff=5703Specs2010-12-30T19:30:03Z<p>Ms2ger: /* Network Layer */</p>
<hr />
<div>This wiki page lists all the specifications that a Web browser is likely to implement.<br />
<br />
For each spec, link the spec's title to the most up to date draft (typically the editor's draft, for specs written in public; for specs written in secret, the latest published working draft), followed by a comma separated list of links in parentheses, named "feedback" for links to the current pending feedback, "discussion" for a link to the archives of the main relevant mailing list or to a page describing relevant mailing lists, "bugs" for a link to a bug system query showing the current open bugs. For specifications that are published in multiple forms, link to the most complete version (e.g. link to the one-page complete.html WHATWG spec rather than all the split-out W3C drafts).<br />
<br />
== Network Layer ==<br />
* [http://tools.ietf.org/wg/httpbis/ HTTP]<br />
* [http://tools.ietf.org/html/rfc0959 FTP]<br />
* [http://tools.ietf.org/html/rfc5246 TLS]<br />
* [http://tools.ietf.org/html/draft-ietf-httpstate-cookie Cookies]<br />
* [http://tools.ietf.org/html/draft-ietf-websec-origin Origin]<br />
<br />
== Media-Independent Layer ==<br />
<br />
* Unicode<br />
* [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM Core] ([http://lists.w3.org/Archives/Public/public-webapps/ discussion])<br />
* [http://www.w3.org/TR/2006/REC-xml-20060816/ XML 1.0 4th ed.]<br />
* [http://www.w3.org/TR/2006/REC-xml-names-20060816/ XMLNS 1.0 2nd ed.]<br />
* [http://www.w3.org/TR/xmlbase/ <code>xml:base</code>] ([http://lists.w3.org/Archives/Public/www-xml-linking-comments/ feedback])<br />
* [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] ([http://www.whatwg.org/issues/ feedback], [http://www.whatwg.org/mailing-list discussion], [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=ian%40hixie.ch&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Last+Changed&field0-0-0=noop&type0-0-0=noop&value0-0-0= bugs])<br />
* [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html WebGL]<br />
* [http://html5.org/specs/dom-range.html DOM Range] ([http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&amp;component=DOM%20Range&amp;resolution=--- bugs])<br />
* [http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization]<br />
* [http://monet.nag.co.uk/~dpc/draft-spec/ MathML] ([http://www.w3.org/TR/MathML/ TR], [http://lists.w3.org/Archives/Public/www-math/ discussion])<br />
<br />
== Media-Specific Layer ==<br />
<br />
* [http://www.w3.org/TR/CSS21/ CSS] ([http://lists.w3.org/Archives/Public/www-style/latest discussion])<br />
** [http://dev.w3.org/csswg/css3-color/ CSS Color]<br />
* [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF]<br />
* [http://www.w3.org/TR/PNG/ PNG]<br />
* [http://www.w3.org/TR/SVG/ SVG]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs&diff=5702Specs2010-12-30T15:48:45Z<p>Ms2ger: /* Media-Independent Layer */ XML and Math</p>
<hr />
<div>This wiki page lists all the specifications that a Web browser is likely to implement.<br />
<br />
For each spec, link the spec's title to the most up to date draft (typically the editor's draft, for specs written in public; for specs written in secret, the latest published working draft), followed by a comma separated list of links in parentheses, named "feedback" for links to the current pending feedback, "discussion" for a link to the archives of the main relevant mailing list or to a page describing relevant mailing lists, "bugs" for a link to a bug system query showing the current open bugs. For specifications that are published in multiple forms, link to the most complete version (e.g. link to the one-page complete.html WHATWG spec rather than all the split-out W3C drafts).<br />
<br />
== Network Layer ==<br />
<br />
* [http://tools.ietf.org/wg/httpbis/ HTTP]<br />
* [http://www.ietf.org/rfc/rfc0959.txt FTP]<br />
* [http://tools.ietf.org/rfc/rfc5246.txt TLS]<br />
* [http://tools.ietf.org/html/draft-ietf-httpstate-cookie Cookies]<br />
<br />
== Media-Independent Layer ==<br />
<br />
* Unicode<br />
* [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM Core] ([http://lists.w3.org/Archives/Public/public-webapps/ discussion])<br />
* [http://www.w3.org/TR/2006/REC-xml-20060816/ XML 1.0 4th ed.]<br />
* [http://www.w3.org/TR/2006/REC-xml-names-20060816/ XMLNS 1.0 2nd ed.]<br />
* [http://www.w3.org/TR/xmlbase/ <code>xml:base</code>] ([http://lists.w3.org/Archives/Public/www-xml-linking-comments/ feedback])<br />
* [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] ([http://www.whatwg.org/issues/ feedback], [http://www.whatwg.org/mailing-list discussion], [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=ian%40hixie.ch&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Last+Changed&field0-0-0=noop&type0-0-0=noop&value0-0-0= bugs])<br />
* [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html WebGL]<br />
* [http://html5.org/specs/dom-range.html DOM Range] ([http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&amp;component=DOM%20Range&amp;resolution=--- bugs])<br />
* [http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization]<br />
* [http://monet.nag.co.uk/~dpc/draft-spec/ MathML] ([http://www.w3.org/TR/MathML/ TR], [http://lists.w3.org/Archives/Public/www-math/ discussion])<br />
<br />
== Media-Specific Layer ==<br />
<br />
* [http://www.w3.org/TR/CSS21/ CSS] ([http://lists.w3.org/Archives/Public/www-style/latest discussion])<br />
** [http://dev.w3.org/csswg/css3-color/ CSS Color]<br />
* [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF]<br />
* [http://www.w3.org/TR/PNG/ PNG]<br />
* [http://www.w3.org/TR/SVG/ SVG]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs&diff=5700Specs2010-12-30T13:22:45Z<p>Ms2ger: toot</p>
<hr />
<div>This wiki page lists all the specifications that a Web browser is likely to implement.<br />
<br />
For each spec, link the spec's title to the most up to date draft (typically the editor's draft, for specs written in public; for specs written in secret, the latest published working draft), followed by a comma separated list of links in parentheses, named "feedback" for links to the current pending feedback, "discussion" for a link to the archives of the main relevant mailing list or to a page describing relevant mailing lists, "bugs" for a link to a bug system query showing the current open bugs. For specifications that are published in multiple forms, link to the most complete version (e.g. link to the one-page complete.html WHATWG spec rather than all the split-out W3C drafts).<br />
<br />
== Network Layer ==<br />
<br />
* [http://tools.ietf.org/wg/httpbis/ HTTP]<br />
* [http://www.ietf.org/rfc/rfc0959.txt FTP]<br />
* [http://tools.ietf.org/rfc/rfc5246.txt TLS]<br />
* [http://tools.ietf.org/html/draft-ietf-httpstate-cookie Cookies]<br />
<br />
== Media-Independent Layer ==<br />
<br />
* Unicode<br />
* [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM Core] ([http://lists.w3.org/Archives/Public/public-webapps/ discussion])<br />
* [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] ([http://www.whatwg.org/issues/ feedback], [http://www.whatwg.org/mailing-list discussion], [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=ian%40hixie.ch&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Last+Changed&field0-0-0=noop&type0-0-0=noop&value0-0-0= bugs])<br />
* [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html WebGL]<br />
* [http://html5.org/specs/dom-range.html DOM Range] ([http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&amp;component=DOM%20Range&amp;resolution=--- bugs])<br />
* [http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization]<br />
<br />
== Media-Specific Layer ==<br />
<br />
* [http://www.w3.org/TR/CSS21/ CSS] ([http://lists.w3.org/Archives/Public/www-style/latest discussion])<br />
** [http://dev.w3.org/csswg/css3-color/ CSS Color]<br />
* [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF]<br />
* [http://www.w3.org/TR/PNG/ PNG]<br />
* [http://www.w3.org/TR/SVG/ SVG]</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_features&diff=5576DOM features2010-11-04T12:54:59Z<p>Ms2ger: Update</p>
<hr />
<div>{| class=wikitable<br />
|-<br />
! Feature || Version || Specification || IE8 || Gecko || WebKit || Presto<br />
|-<br />
| XML || 1.0 || Web DOM Core || N || Y || Y || ?<br />
|-<br />
| XML || 2.0 || Web DOM Core || N || Y || Y || ?<br />
|-<br />
| Core || 1.0 || || N || N || Y || ?<br />
|-<br />
| Core || 2.0 || Web DOM Core || N || Y || Y || ?<br />
|-<br />
| HTML || 1.0 || HTML || Y || Y || Y || ?<br />
|-<br />
| HTML || 2.0 || HTML || N || Y || Y || ?<br />
|-<br />
| XHTML || 1.0 || HTML || N || N || Y || ?<br />
|-<br />
| XHTML || 2.0 || HTML || N || Y || Y || ?<br />
|-<br />
| Views || 2.0 || DOM2VIEWS || N || Y || Y || ?<br />
|-<br />
| StyleSheets || 2.0 || DOM2STYLE || N || Y || Y || ?<br />
|-<br />
| CSS || 2.0 || DOM2STYLE || N || Y || Y || ?<br />
|-<br />
| CSS2 || 2.0 || DOM2STYLE || N || Y || Y || ?<br />
|-<br />
| Events || 2.0 || DOM3EVENTS || N || Y || Y || ?<br />
|-<br />
| Events || 3.0 || DOM3EVENTS || N || N || N || ?<br />
|-<br />
| Events.* || 3.0 || DOM3EVENTS || N || N || N || ?<br />
|-<br />
| UIEvents || 2.0 || DOM2EVENTS || N || Y || Y || ?<br />
|-<br />
| MouseEvents || 2.0 || DOM2EVENTS || N || Y || Y || ?<br />
|-<br />
| MutationEvents || 2.0 || DOM2EVENTS || N || N || Y || ?<br />
|-<br />
| HTMLEvents || 2.0 || DOM2EVENTS || N || Y || Y || ?<br />
|-<br />
| MouseScrollEvents || 2.0 || || N || Y || N || ?<br />
|-<br />
| Range || 2.0 || DOM2T-RANGE || N || Y || Y || ?<br />
|-<br />
| Traversal || 2.0 || DOM2T-RANGE || N || N || Y || ?<br />
|-<br />
| XPath || 3.0 || DOM3XPATH (N) || N || Y || Y || ?<br />
|-<br />
| TextEvents || 3.0 || ? || N || N || Y || ?<br />
|-<br />
| Selectors-API || 1.0 || Selector API || N || N || N || ?<br />
|-<br />
| colspan=7 class=XXX | SVG & SMIL<br />
|}</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_features&diff=5570DOM features2010-11-03T10:15:03Z<p>Ms2ger: Update</p>
<hr />
<div>{| class=wikitable<br />
|-<br />
! Feature || Version || Specification || Trident || Gecko || WebKit || Presto<br />
|-<br />
| XML || 1.0 || Web DOM Core || ? || Y || Y || ?<br />
|-<br />
| XML || 2.0 || Web DOM Core || ? || Y || Y || ?<br />
|-<br />
| Core || 1.0 || || ? || N || Y || ?<br />
|-<br />
| Core || 2.0 || Web DOM Core || ? || Y || Y || ?<br />
|-<br />
| HTML || 1.0 || HTML || ? || Y || Y || ?<br />
|-<br />
| HTML || 2.0 || HTML || ? || Y || Y || ?<br />
|-<br />
| XHTML || 1.0 || HTML || ? || N || Y || ?<br />
|-<br />
| XHTML || 2.0 || HTML || ? || Y || Y || ?<br />
|-<br />
| Views || 2.0 || DOM2VIEWS || ? || Y || Y || ?<br />
|-<br />
| StyleSheets || 2.0 || DOM2STYLE || ? || Y || Y || ?<br />
|-<br />
| CSS || 2.0 || DOM2STYLE || ? || Y || Y || ?<br />
|-<br />
| CSS2 || 2.0 || DOM2STYLE || ? || Y || Y || ?<br />
|-<br />
| Events || 2.0 || DOM3EVENTS || ? || Y || Y || ?<br />
|-<br />
| Events || 3.0 || DOM3EVENTS || ? || N || N || ?<br />
|-<br />
| Events.* || 3.0 || DOM3EVENTS || ? || N || N || ?<br />
|-<br />
| UIEvents || 2.0 || DOM2EVENTS || ? || Y || Y || ?<br />
|-<br />
| MouseEvents || 2.0 || DOM2EVENTS || ? || Y || Y || ?<br />
|-<br />
| MutationEvents || 2.0 || DOM2EVENTS || ? || N || Y || ?<br />
|-<br />
| HTMLEvents || 2.0 || DOM2EVENTS || ? || Y || Y || ?<br />
|-<br />
| MouseScrollEvents || 2.0 || || ? || Y || N || ?<br />
|-<br />
| Range || 2.0 || DOM2T-RANGE || ? || Y || Y || ?<br />
|-<br />
| Traversal || 2.0 || DOM2T-RANGE || ? || N || Y || ?<br />
|-<br />
| XPath || 3.0 || DOM3XPATH (N) || ? || Y || Y || ?<br />
|-<br />
| TextEvents || 3.0 || ? || ? || N || Y || ?<br />
|-<br />
| Selectors-API || 1.0 || Selector API || ? || N || N || ?<br />
|-<br />
| colspan=7 class=XXX | SVG & SMIL<br />
|}</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=DOM_features&diff=5569DOM features2010-11-03T09:47:42Z<p>Ms2ger: Create page</p>
<hr />
<div>{| class=wikitable<br />
|-<br />
! Feature || Version || Specification || Trident || Gecko || WebKit || Presto<br />
|-<br />
| XML || 1.0 || Web DOM Core || ? || Y || ? || ?<br />
|-<br />
| XML || 2.0 || Web DOM Core || ? || Y || ? || ?<br />
|-<br />
| Core || 1.0 || || ? || N || Y || ?<br />
|-<br />
| Core || 2.0 || Web DOM Core || ? || Y || ? || ?<br />
|-<br />
| HTML || 1.0 || HTML || ? || Y || ? || ?<br />
|-<br />
| HTML || 2.0 || HTML || ? || Y || ? || ?<br />
|-<br />
| XHTML || 1.0 || HTML || ? || N || ? || ?<br />
|-<br />
| XHTML || 2.0 || HTML || ? || Y || ? || ?<br />
|-<br />
| Views || 2.0 || DOM2VIEWS || ? || Y || ? || ?<br />
|-<br />
| StyleSheets || 2.0 || DOM2STYLE || ? || Y || ? || ?<br />
|-<br />
| CSS || 2.0 || DOM2STYLE || ? || Y || ? || ?<br />
|-<br />
| CSS2 || 2.0 || DOM2STYLE || ? || Y || ? || ?<br />
|-<br />
| Events || 2.0 || DOM3EVENTS || ? || Y || ? || ?<br />
|-<br />
| Events || 3.0 || DOM3EVENTS || ? || N || ? || ?<br />
|-<br />
| Events.* || 3.0 || DOM3EVENTS || ? || N || ? || ?<br />
|-<br />
| UIEvents || 2.0 || DOM2EVENTS || ? || Y || ? || ?<br />
|-<br />
| MouseEvents || 2.0 || DOM2EVENTS || ? || Y || ? || ?<br />
|-<br />
| MutationEvents || 2.0 || DOM2EVENTS || ? || N || ? || ?<br />
|-<br />
| HTMLEvents || 2.0 || DOM2EVENTS || ? || Y || ? || ?<br />
|-<br />
| MouseScrollEvents || 2.0 || || ? || Y || ? || ?<br />
|-<br />
| Range || 2.0 || DOM2RANGE || ? || Y || ? || ?<br />
|-<br />
| XPath || 3.0 || DOM3XPATH (N) || ? || Y || ? || ?<br />
|-<br />
| colspan=7 class=XXX | SVG & SMIL<br />
|}</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Exception_Codes&diff=5532Exception Codes2010-10-24T09:42:32Z<p>Ms2ger: Drop <datagrid> entirely for now.</p>
<hr />
<div>== DOMException ==<br />
<br />
The exceptions in this category are all bound to the DOMException or LSException interfaces.<br />
<br />
;[http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception Web DOM Core]<br />
: 1 INDEX_SIZE_ERR<br />
: 2 DOMSTRING_SIZE_ERR<br />
: 3 HIERARCHY_REQUEST_ERR<br />
: 4 WRONG_DOCUMENT_ERR<br />
: 5 INVALID_CHARACTER_ERR<br />
: 6 NO_DATA_ALLOWED_ERR<br />
: 7 NO_MODIFICATION_ALLOWED_ERR<br />
: 8 NOT_FOUND_ERR<br />
: 9 NOT_SUPPORTED_ERR<br />
: 10 INUSE_ATTRIBUTE_ERR<br />
: 11 INVALID_STATE_ERR<br />
: 12 SYNTAX_ERR<br />
: 13 INVALID_MODIFICATION_ERR<br />
: 14 NAMESPACE_ERR<br />
: 15 INVALID_ACCESS_ERR<br />
: 16 VALIDATION_ERR<br />
: 17 TYPE_MISMATCH_ERR<br />
: 18 SECURITY_ERR<br />
: 19 NETWORK_ERR<br />
: 20 ABORT_ERR<br />
: 21 URL_MISMATCH_ERR<br />
: 22 QUOTA_EXCEEDED_ERR<br />
: 23 TIMEOUT-ERR<br />
: 24 NOT_READABLE_ERR<br />
: 25 DATA_CLONE_ERR<br />
: 26 ENCODING_ERR<br />
;[http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSException DOM3LS] (should be obsolete; do not implement)<br />
: 81 PARSE_ERR<br />
: 82 SERIALISE_ERR<br />
<br />
== EventException ==<br />
<br />
DOM3 Events defines exceptions 0 and 1: http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventException<br />
<br />
== RangeException ==<br />
DOM Range defines exceptions 1 and 2: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#RangeException</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Exception_Codes&diff=5516Exception Codes2010-10-09T12:43:59Z<p>Ms2ger: Web DOM Core</p>
<hr />
<div>== DOMException ==<br />
<br />
The exceptions in this category are all bound to the DOMException or LSException interfaces.<br />
<br />
;[http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception Web DOM Core]<br />
: 1 INDEX_SIZE_ERR<br />
: 2 DOMSTRING_SIZE_ERR<br />
: 3 HIERARCHY_REQUEST_ERR<br />
: 4 WRONG_DOCUMENT_ERR<br />
: 5 INVALID_CHARACTER_ERR<br />
: 6 NO_DATA_ALLOWED_ERR<br />
: 7 NO_MODIFICATION_ALLOWED_ERR<br />
: 8 NOT_FOUND_ERR<br />
: 9 NOT_SUPPORTED_ERR<br />
: 10 INUSE_ATTRIBUTE_ERR<br />
: 11 INVALID_STATE_ERR<br />
: 12 SYNTAX_ERR<br />
: 13 INVALID_MODIFICATION_ERR<br />
: 14 NAMESPACE_ERR<br />
: 15 INVALID_ACCESS_ERR<br />
: 16 VALIDATION_ERR<br />
: 17 TYPE_MISMATCH_ERR<br />
: 18 SECURITY_ERR<br />
: 19 NETWORK_ERR<br />
: 20 ABORT_ERR<br />
: 21 URL_MISMATCH_ERR<br />
: 22 QUOTA_EXCEEDED_ERR<br />
: 23 TIMEOUT-ERR<br />
: 24 NOT_READABLE_ERR<br />
: 25 DATA_CLONE_ERR<br />
: 26 ENCODING_ERR<br />
<!--v2DATAGRID: 27 DATAGRID_MODEL_ERR--><br />
;[http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSException DOM3LS] (should be obsolete; do not implement)<br />
: 81 PARSE_ERR<br />
: 82 SERIALISE_ERR<br />
<br />
== EventException ==<br />
<br />
DOM3 Events defines exceptions 0 and 1: http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventException<br />
<br />
== RangeException ==<br />
DOM Range defines exceptions 1 and 2: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#RangeException</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Testsuite/Mozilla&diff=5486Testsuite/Mozilla2010-09-12T15:58:53Z<p>Ms2ger: +</p>
<hr />
<div>This is a list of Mozilla tests that would be useful in the testsuite.<br />
<br />
{{mxr|content/base/test/test_bug357450.js}}<br />
{{mxr|content/base/test/test_bug505783.html}}<br />
{{mxr|content/base/test/test_classList.html}}<br />
{{mxr|content/html/content/reftests/href-attr-removal-restyles.html}}<br />
{{mxr|content/html/content/test/test_bug694.html}}<br />
{{mxr|content/html/content/test/test_bug405242.html}}<br />
{{mxr|content/html/content/test/test_bug518122.html}}<br />
{{mxr|content/html/content/test/test_bug519987.html}}<br />
{{mxr|content/html/content/test/test_bug547850.html}}<br />
{{mxr|content/html/content/test/test_bug549475.html}}<br />
{{mxr|content/html/content/test/test_bug593689.html}}<br />
{{mxr|content/html/content/test/test_formSubmission.html}}<br />
{{mxr|content/html/content/test/test_formSubmission2.html}}<br />
{{mxr|content/html/document/test/test_bug340017.xhtml}}<br />
{{mxr|content/html/document/test/test_bug478251.html}}<br />
{{mxr|content/media/test/test_constants.html}}<br />
{{mxr|dom/tests/mochitest/whatwg/}}</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Testsuite/Mozilla&diff=5425Testsuite/Mozilla2010-08-24T11:31:42Z<p>Ms2ger: +</p>
<hr />
<div>This is a list of Mozilla tests that would be useful in the testsuite.<br />
<br />
{{mxr|content/base/test/test_bug357450.js}}<br />
{{mxr|content/base/test/test_bug505783.html}}<br />
{{mxr|content/base/test/test_classList.html}}<br />
{{mxr|content/html/content/reftests/href-attr-removal-restyles.html}}<br />
{{mxr|content/html/content/test/test_bug694.html}}<br />
{{mxr|content/html/content/test/test_bug405242.html}}<br />
{{mxr|content/html/content/test/test_bug518122.html}}<br />
{{mxr|content/html/content/test/test_bug519987.html}}<br />
{{mxr|content/html/content/test/test_bug547850.html}}<br />
{{mxr|content/html/content/test/test_bug549475.html}}<br />
{{mxr|content/html/content/test/test_formSubmission.html}}<br />
{{mxr|content/html/content/test/test_formSubmission2.html}}<br />
{{mxr|content/html/document/test/test_bug340017.xhtml}}<br />
{{mxr|content/html/document/test/test_bug478251.html}}<br />
{{mxr|content/media/test/test_constants.html}}<br />
{{mxr|dom/tests/mochitest/whatwg/}}</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=IDL_attributes&diff=5367IDL attributes2010-08-15T12:22:29Z<p>Ms2ger: +spec bug for img.lowsrc</p>
<hr />
<div>== <code>HTMLImageElement</code> ==<br />
{| class=wikitable<br />
|-<br />
!<br />
! HTML<br />
! Gecko<br />
! WebKit<br />
! Opera<br />
! IE<br />
|-<br />
! <code> attribute DOMString alt;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString src;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString useMap;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute boolean isMap;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long width;</code><br />
| y<br />
| y<ref name="long">As <code>long</code></ref><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long height;</code><br />
| y<br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute unsigned long naturalWidth;</code><br />
| y<br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute unsigned long naturalHeight;</code><br />
| y<br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute boolean complete;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString name;</code><br />
| y<ref name="obsolete">Obsolete</ref><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString align;</code><br />
| y<ref name="obsolete"/><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString border;</code><br />
| y<ref name="obsolete"/><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long hspace;</code><br />
| y<ref name="obsolete"/><br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString longDesc;</code><br />
| y<ref name="obsolete"/><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long vspace;</code><br />
| y<ref name="obsolete"/><br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString lowsrc;</code><br />
| n<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=10341</ref><br />
| y<br />
| y<br />
| y<br />
| ?<br />
|-<br />
! <code> readonly attribute long x;</code><br />
| n<br />
| y<ref name="img-xy">https://bugzilla.mozilla.org/show_bug.cgi?id=587021</ref><br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute long x;</code><br />
| n<br />
| y<ref name="img-xy"/><br />
| y<br />
| ?<br />
| ?<br />
|}<br />
<br />
== Notes ==<br />
<references/></div>Ms2gerhttps://wiki.whatwg.org/index.php?title=IDL_attributes&diff=5366IDL attributes2010-08-15T12:17:04Z<p>Ms2ger: Document IDL attributes and the UAs supporting them</p>
<hr />
<div>== <code>HTMLImageElement</code> ==<br />
{| class=wikitable<br />
|-<br />
!<br />
! HTML<br />
! Gecko<br />
! WebKit<br />
! Opera<br />
! IE<br />
|-<br />
! <code> attribute DOMString alt;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString src;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString useMap;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute boolean isMap;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long width;</code><br />
| y<br />
| y<ref name="long">As <code>long</code></ref><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long height;</code><br />
| y<br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute unsigned long naturalWidth;</code><br />
| y<br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute unsigned long naturalHeight;</code><br />
| y<br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute boolean complete;</code><br />
| y<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString name;</code><br />
| y<ref name="obsolete">Obsolete</ref><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString align;</code><br />
| y<ref name="obsolete"/><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString border;</code><br />
| y<ref name="obsolete"/><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long hspace;</code><br />
| y<ref name="obsolete"/><br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString longDesc;</code><br />
| y<ref name="obsolete"/><br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute unsigned long vspace;</code><br />
| y<ref name="obsolete"/><br />
| y<ref name="long"/><br />
| y<ref name="long"/><br />
| ?<br />
| ?<br />
|-<br />
! <code> attribute DOMString lowsrc;</code><br />
| n<br />
| y<br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute long x;</code><br />
| n<br />
| y<ref name="img-xy">https://bugzilla.mozilla.org/show_bug.cgi?id=587021</ref><br />
| y<br />
| ?<br />
| ?<br />
|-<br />
! <code> readonly attribute long x;</code><br />
| n<br />
| y<ref name="img-xy"/><br />
| y<br />
| ?<br />
| ?<br />
|}<br />
<br />
== Notes ==<br />
<references/></div>Ms2gerhttps://wiki.whatwg.org/index.php?title=FAQ&diff=5261FAQ2010-08-08T18:21:26Z<p>Ms2ger: /* What are the various versions of the spec? */ +WebSRT</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.<br />
<br />
If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== Is there a process for removing bad ideas from a specification? ===<br />
<br />
There are several processes by which we trim weeds from the specifications.<br />
<br />
* On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.<br />
<br />
* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.<br />
<br />
* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.<br />
<br />
Removing features is a critical part of spec development.<br />
<br />
=== Is there a process for adding new features to a specification? ===<br />
<br />
The process is rather informal, but basically boils down to this:<br />
# Research the use cases and requirements by discussing the issue with authors and implementors.<br />
# Come up with a clear description of the problem that needs to be solved.<br />
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.<br />
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.<br />
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.<br />
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.<br />
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.<br />
<br />
If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.<br />
<br />
Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.<br />
<br />
== HTML5 ==<br />
<br />
=== What is HTML5? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec.<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking tool]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
* Non-editorial changes get broadcast on the WHATWG Twitter feed: http://twitter.com/WHATWG<br />
<br />
* All changes that affect the W3C copy of the spec get broadcast on the HTML5 Twitter feed: http://twitter.com/HTML5<br />
<br />
* The latest changes are visible in coloured diff form: http://whatwg.org/specs/web-apps/current-work/index-diff<br />
<br />
<br />
=== What are the various versions of the spec? ===<br />
<br />
All active work at WHATWG is gathered in the (very large) [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] document.<br />
<br />
WHATWG HTML is a subset containing only the HTML-specific material. It is available as [http://www.whatwg.org/specs/web-apps/current-work/ single-page]<br />
and '''[http://whatwg.org/html multi-page]''', as well as in PDF [http://www.whatwg.org/specs/web-apps/current-work/html5-a4.pdf A4] and<br />
[http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf Letter].<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! WHATWG Specifications <br> (and sections therein)<br />
! Section links for <br> Web Applications 1.0<br />
! W3C/IETF Specifications<br />
|-<br />
! HTML5 only (excluding newer features)<br />
|<br />
|<br />
| [http://dev.w3.org/html5/spec/Overview.html Single-page], [http://dev.w3.org/html5/spec/spec.html Multi-page] (HTMLWG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/Overview.html Microdata] (HTMLWG)<br />
|-<br />
! 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-2d-context In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-2d-context 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/Overview.html 2D Context] (HTMLWG)<br />
|-<br />
! Communications - Cross-document messaging<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#crossDocumentMessages Cross-document messaging]<br />
| [http://dev.w3.org/html5/postmsg/Overview.html#crossDocumentMessages Communications] (HTMLWG)<br />
|-<br />
! Communications - Channel messaging<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging In WHATWG HTML]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#channel-messaging Channel messaging]<br />
| [http://dev.w3.org/html5/postmsg/Overview.html#channel-messaging Communications] (HTMLWG)<br />
|-<br />
! Device Element<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices In WHATWG HTML] <br /> (note: not in Last Call for HTML5)<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices Device] <br /> see also [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2009-September/000333.html]<br />
| [http://dev.w3.org/html5/html-device/ HTML Device] (HTMLWG) <br /> see also [http://wiki.whatwg.org/index.php?title=Video_accessibility&oldid=4875#Proposed_Solutions]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers specification]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#workers Web Workers]<br />
| [http://dev.w3.org/html5/workers/Overview.html Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
|<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#webstorage Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
|<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#network Web Sockets API]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Web Sockets Protocol<br />
|<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#websocket-protocol Web Sockets Protocol]<br />
| [http://www.whatwg.org/specs/web-socket-protocol/ The Web Socket Protocol] (IETF)<br />
|-<br />
! Server-Sent Events<br />
|<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|-<br />
! Web SQL Database (stalled)<br />
|<br />
|<br />
| [http://dev.w3.org/html5/webdatabase/ Web SQL Database] (WebApps WG)<br />
|-<br />
! WebSRT<br />
| [http://www.whatwg.org/specs/web-apps/current-work/websrt.html WebSRT]<br />
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#websrt-0 WebSRT]<br />
|<br />
|}<br />
<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
=== Are there versions of the specification aimed specifically at authors/implementors? ===<br />
<br />
There are no standalone author or implementor specifications. However, the WHATWG HTML and the HTML5 specifications (and their multipage versions) can be customized to either hide or emphasize user-agent-specific material. The mode can be selected using radio buttons at the top right of those documents.<br />
<br />
It is also possible to toggle the mode by changing the URL, here is an example for the multipage WHATWG HTML specification:<br />
<br />
* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete<br />
* Author view (hiding the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author<br />
* Implementor view (highlighting the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight<br />
<br />
=== When will we be able to start using these new features? ===<br />
<br />
You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites that might help you work out what you can use in the meantime:<br />
<br />
* http://diveintohtml5.org/<br />
<br />
If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, them remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]<br />
<br />
It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. &lt;canvas&gt;). But other sections are still being actively worked on and changed regularly, or not even written yet.<br />
<br />
'''You can see annotations in the margins showing the estimated stability of each section.'''<br />
<br />
The possible states are:<br />
<br />
* ''Idea; yet to be specified'' -- the section is a placeholder.<br />
* ''First draft'' -- An early stage.<br />
* ''Working draft'' -- An early stage, but more mature than just "first draft".<br />
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.<br />
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.<br />
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it&#8217;s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.<br />
<br />
There are also two special states:<br />
<br />
* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.<br />
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.<br />
<br />
The point to all this is that you shouldn&#8217;t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.<br />
<br />
It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.<br />
<br />
For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you&#8217;ll begin to understand why the time frame seems so long.<br />
<br />
(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)<br />
<br />
=== What about Microsoft and Internet Explorer? === <br />
<br />
Microsoft has already started implementing parts of HTML5 in IE8.<br />
<br />
HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.<br />
<br />
=== Is design rationale documented? ===<br />
<br />
Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.<br />
<br />
For a few cases that someone did take the time document, the information can be found at the following locations:<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend]]—or another ''mini-header'' element.<br />
<br />
Also see HTML5 feature proposals below.<br />
<br />
== HTML5 syntax issues ==<br />
<br />
=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? === <br />
<br />
Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''<br />
<br />
=== What will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
=== How are pre-HTML5 documents parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML5 validator].<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML5 use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.<br />
<br />
HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa. <br />
<br />
If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does HTML5 legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML5 feature proposals ==<br />
<br />
=== HTML5 should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML5 should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <legend> elements:<br />
<br />
<pre><br />
<figure><br />
<legend>Apples</legend><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML5 should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML5 should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
<strong>Note:</strong> research and opinions are being gathered that support the use of the &lt;cite> element to markup the names of speakers (e.g. for quotations). Please contribute yours:<br />
* [[Cite_element#examples_in_the_wild|cite element: examples in the wild of speakers marked up with cite]]<br />
* [[Cite_element#opinions|cite element: opinions on use of cite to markup names of speakers]]<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]<br />
<br />
== Web Workers ==<br />
<br />
Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.<br />
<br />
== Mailing List ==<br />
<br />
=== Should I top-post or reply inline? ===<br />
<br />
Please reply inline or make the reply self-contained.<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.<br />
<br />
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.<br />
H</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Testsuite/Mozilla&diff=5096Testsuite/Mozilla2010-07-22T10:06:43Z<p>Ms2ger: Add</p>
<hr />
<div>This is a list of Mozilla tests that would be useful in the testsuite.<br />
<br />
{{mxr|content/base/test/test_bug357450.js}}<br />
{{mxr|content/base/test/test_bug505783.html}}<br />
{{mxr|content/base/test/test_classList.html}}<br />
{{mxr|content/html/content/reftests/href-attr-removal-restyles.html}}<br />
{{mxr|content/html/content/test/test_bug694.html}}<br />
{{mxr|content/html/content/test/test_bug405242.html}}<br />
{{mxr|content/html/content/test/test_bug518122.html}}<br />
{{mxr|content/html/content/test/test_bug519987.html}}<br />
{{mxr|content/html/content/test/test_bug547850.html}}<br />
{{mxr|content/html/content/test/test_bug549475.html}}<br />
{{mxr|content/html/content/test/test_formSubmission.html}}<br />
{{mxr|content/html/content/test/test_formSubmission2.html}}<br />
{{mxr|content/html/document/test/test_bug340017.xhtml}}<br />
{{mxr|content/html/document/test/test_bug478251.html}}<br />
{{mxr|dom/tests/mochitest/whatwg/}}</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Rationale&diff=5035Rationale2010-07-12T15:54:41Z<p>Ms2ger: /* HTML parsing */ Add</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
5. "It isn't just browsers" - explain why sometimes elements and features are needed even when browsers won't use them. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can.<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such browser vendors already have veto power - by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
power that we grant browsers, it's a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> It is is now in the HTML5 spec as a method of stopping all further html token parsing. It lacks an end tag and just emits the rest of the page as plain text. It throws a parse error upon reaching the end of the document as it is not considered a valid element (and it is missing an end-tag).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. The meter element represents a scalar measurement within a known range, such as storage quota usage, a relative popularity rating or relevance indicator. The control allows for the indication of high and low ranges, or minimum, maximum and optimal levels.<br />
<br />
The progress element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload). Progress elmements can also be in the indeterminate state, indicating that something is in progress, but it's completion progress is unknown.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the work "cute" should be highlighted or marked in some way. This could be used for search terms on the page or alterations to an original text.<br />
<br />
=== IMG tag & alt text ===<br />
On certain types of pages adding alt text is impossible (like sites that the user could upload images but does not supply a description). Because of this the alt attribute is optional <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
The text area defaults to soft wrapping of the text area. The attribute @wrap can have one of the following values: soft, hard, or off.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>If the Document is not set to quirks mode, and the stack of open elements has a p element in scope, then act as if an end tag with the tag name "p" had been seen.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
There is no advert tag because if users had an easy method of plainly disabling all ads from downloading or appearing content authors would cease to use the tag.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
Part of the problem is that browser vendors will be economical with the truth. Marketing people always have an over-optimistic view of the compliance of their product, and will always give themselves the benefit of the doubt in borderline cases. Also, changing the compliance statement, to remove false claims that are exposed, is likely to a very low priority for the developers.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Open_issues&diff=4930Open issues2010-06-22T16:45:45Z<p>Ms2ger: Done, done and done</p>
<hr />
<div>There are quite a few places in HTML5 that have issue boxes. This page lists the remaining items that are not yet included into the main specification properly:<br />
<br />
* <del>Ruby (http://www.w3.org/TR/ruby/)</del><br />
* <del>Rendering</del><br />
* <del>Forms (Web Forms 2.0)</del><br />
<br />
If enough experience is gained on time the following features will be looked at as well:<br />
<br />
* <del>SVG and MathML support in the HTML syntax</del><br />
* Extensibility in HTML<br />
<br />
There are several other features considered for future versions of HTML:<br />
<br />
* <del>ECMAScript Threading API (based on Google Gears WorkerPool)</del><br />
* <del>API for 3D immediate mode graphics</del></div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Specs/todo&diff=4914Specs/todo2010-06-05T16:57:49Z<p>Ms2ger: Flexbox is being edited; Add link</p>
<hr />
<div>There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch or post on the WHATWG mailing list or say something on the #whatwg IRC channel on Freenode.<br />
<br />
== How to edit a spec ==<br />
<br />
We have [[How to write a spec|some documentation on how to write a spec]] that could help if you want to help out.<br />
<br />
== Specs to edit ==<br />
<br />
=== DOM ===<br />
<br />
* Web DOM Core is looking for an editor (http://simon.html5.org/specs/web-dom-core)<br />
** should document.documentURI really exist? be readonly?<br />
* A rewrite of DOM2 Traversal.<br />
* A rewrite of DOM2 Range.<br />
** including much more detail<br />
** including de-facto features, e.g. [https://developer.mozilla.org/en/DOM/range.createContextualFragment createContextualFragment()]<br />
* User Interaction Events (onclick, onkeypress, etc).<br />
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus<br />
* [http://developer.mozilla.org/En/DOM/Window.atob window.atob]<br />
* [http://developer.mozilla.org/En/DOM/Window.btoa window.btoa]<br />
* XMLSerializer()<br />
* DOMParser()<br />
* An API for cryptography, to generate keys and the like<br />
<br />
=== CSS ===<br />
<br />
There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:<br />
* CSS Animation<br />
* CSS Gradients<br />
* [http://dev.w3.org/csswg/cssom/ CSSOM]<br />
** CSSOM needs to define how Link:, <?xml-stylesheet?>, <link rel=stylesheet>, and <style> interact with the fetching algorithm, the event loop, and the parsers from HTML5.<br />
** CSSOM should have a mechanism for taking elements full-screen<br />
** it has been proposed that CSSOM have a mechanism for keeping track of when expensive-to-compute areas of the document (e.g. a canvas) are actually being rendered.<br />
*** Add a pair of events that fire when an element is hidden and unhidden<br />
*** Add a pair of events that fire when an element is scrolled into and out of the view<br />
* <?xml-stylesheet?> could do with a rewrite for integration with CSSOM; do 'load' and 'error' events fire on it?<br />
<br />
=== Registries ===<br />
<br />
Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:<br />
<br />
* Encodings: http://wiki.whatwg.org/wiki/Web_Encodings<br />
* MIME types<br />
* Schemes<br />
<br />
It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).<br />
<br />
=== MISC ===<br />
* an API to do syntax highlighting on &lt;textarea>, &lt;pre>, and contenteditable sections would be highly popular with Web developers (ack Ryan Johnson). (This would probably best be done as some sort of output filter at the CSS level, rather than anything HTML-specific.)<br />
* JS changes: http://wiki.whatwg.org/wiki/Web_ECMAScript<br />
<br />
== See also ==<br />
<br />
* http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html (a description of some sections that needed editing in 2008 and how much work they would be)<br />
<br />
== Other stuff ==<br />
<br />
Some notes from the HTML5 spec about things that need doing:<br />
<br />
* support access Array element via () instead of [] (IEism) https://bugzilla.mozilla.org/show_bug.cgi?id=289876<br />
* Need to say that NodeList's items are enumerable, so that... for (var x in myNodeList) { } ...works. (ack Dethe Elza)<br />
* a way to show icons for file types e.g. http://www.gadgetopia.com/2004/05/04/FileIconTag.html (this should probably be a function for the 'content', 'background-image' and 'list-style-image' properties in CSS)<br />
** Maybe something like moz-icon://? http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0255.html, http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=RelExtensions&diff=4894RelExtensions2010-05-13T08:08:40Z<p>Ms2ger: Note "extension"</p>
<hr />
<div>This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it. Note that rel tokens are ASCII-lowercase before comparison against canonical value, so the canonical values should be listed without uppercase ASCII letters.<br />
<br />
{| class=wikitable<br />
|-<br />
! rowspan=2 | Keyword<br />
! colspan=2 | Effect on...<br />
! rowspan=2 | Brief description<br />
! rowspan=2 | Link to more details<br />
! rowspan=2 | Synonyms<br />
! rowspan=2 | Status<br />
|- <br />
! link<br />
! a and area<br />
|-<br />
| accessibility<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains accessibility information for the linking document.<br />
| [http://www.brucelawson.co.uk/2009/rel-accessibility/ Bruce Lawson]<br />
| <br />
| Proposal<br />
|-<br />
| acquaintance<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| ajax<br />
| not allowed<br />
| hyperlink<br />
| The link is controlled through javascript, and will load the page linked to though an ajax interface. Without javascript, it should behave as a normal "a" tag, and content change is done server side.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| alternate<br />
|colspan=6| See HTML5<br />
|-<br />
| archives<br />
|colspan=6| See HTML5<br />
|-<br />
| author<br />
|colspan=6| See HTML5<br />
|-<br />
| bookmark<br />
|colspan=6| See HTML5<br />
|-<br />
| canonical<br />
| hyperlink<br />
| not allowed<br />
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter.<br />
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-domain<br />
| external resource<br />
| not allowed<br />
| More than one domain may have largely similar or identical content but only one of the domains should be indexed for search engines. E.g., a company may have short and long domain names for the same content.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-first<br />
| external resource<br />
| hyperlink<br />
| Where the canonical value should point to a group of pages, but the link can point to only one page, the group of pages can be clarified by choosing the first page in the group and assigning the URL for this rel link.<br />
For security against traffic theft, rev must be meaningless.<br /><br />
This is only shorthand for providing two link elements, one on the noncanonical page to a "canonical" page and the other on the canonical page to the "first" page of the group.<br />
Where the group of pages corresponds to a subdirectory and a canonical URL value can point to the subdirectory resulting in a user arriving at the subdirectory's index page which is part of the group, this shorthand is unnecessary and one rel="canonical" will suffice.<br />
| [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-human<br />
| external resource<br />
| hyperlink<br />
| Pages about a person across many websites can be associated based on name, nationality, birthplace, dates of birth and death, when flourished, and other identifiers.<br />
Search engines could more consistently aggregate same-person pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681 W3C Bug 7681]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-organization<br />
| external resource<br />
| hyperlink<br />
| Pages about an organization across many websites can be associated based on name, headquarters site, and other identifiers.<br />
Search engines could more consistently aggregate same-organization pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7682 W3C Bug 7682]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-wwwnone<br />
| external resource<br />
| hyperlink<br />
| Both bare and www-prefixed domain names usually direct to the same site. Especially when external links to a site vary in the form used, search engine indexing concentrated on only one domain form may raise its credibility. The rel value is the form preferred for indexing, e.g., rel="http://example.net". Nothing to the right of the top-level domain is needed.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| chapter<br />
| hyperlink<br />
| hyperlink<br />
| Target document is a subdocument of the current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| section, subsection, appendix<br />
| Proposal<br />
|-<br />
| child<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a child of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-resident<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives in the same residence as the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-worker<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a co-worker of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| colleague<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a colleague of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contact<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a contact<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contributor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| crush<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| date<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a date (i.e. is dating the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| details<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document contains additional (or complete) details about the current document (for example, a "read more..." hyperlink on a blog page that leads to the full posting).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| dns-prefetch<br />
| external resource<br />
| not allowed<br />
| Force the DNS lookup of specific hostnames.<br />
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla DNS Prefetching], <br />[http://dev.chromium.org/developers/design-documents/dns-prefetching Chromium DNS Prefetching]<br />
| <br />
| Proposal<br />
|-<br />
| edit<br />
| hyperlink<br />
| hyperlink<br />
| Target document is an editable version of the current document.<br />
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]<br />
| <br />
| Proposal<br />
|-<br />
| edituri<br />
| hyperlink<br />
| not allowed<br />
| a link to an RSD file describing how to edit the given page.<br />
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]<br />
| <br />
| Proposal<br />
|-<br />
| enclosure<br />
| hyperlink<br />
| hyperlink<br />
| the destination of the hyperlink is intended to be downloaded and cached.<br />
| [http://microformats.org/wiki/rel-enclosure rel-enclosure]<br />
| <br />
| Proposal<br />
|-<br />
| enlarged<br />
| not allowed<br />
| hyperlink<br />
| For anchors that have one child image element, indicates that the linked document is an image file which is the same as the child image element of the link except a larger size (dimensions).<br />
| [http://dvdgoss.wordpress.com/2010/04/26/the-case-for-relenlarge-in-html5/ David Goss]<br />
| <br />
| Proposal<br />
|-<br />
| external<br />
|colspan=6| See HTML5<br />
|-<br />
| extension<br />
| hyperlink<br />
| hyperlink<br />
| Browser extension<br />
| [http://mozillalabs.com/jetpack/2010/05/12/indexing-and-auto-detecting-browser-extensions-on-the-web/ Mozilla Labs]<br />
| <br />
| Accepted<br />
|-<br />
| first<br />
|colspan=6| See HTML5<br />
|-<br />
| friend<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a friend<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| glossary<br />
| hyperlink<br />
| hyperlink<br />
| Target document provides definitions for words in current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| <br />
| Proposal<br />
|-<br />
| help<br />
|colspan=6| See HTML5<br />
|-<br />
| hub<br />
| hyperlink<br />
| not allowed<br />
| Indicates a URL which implements both sides of the PubSubHubbub protocol.<br />
| [http://code.google.com/p/pubsubhubbub/ PubSubHubbub]<br />
| <br />
| Proposal<br />
|-<br />
| i18nrules<br />
| hyperlink<br />
| not allowed<br />
| Target document provides ITS (Internationalization tag Set) rules for processing the current document.<br />
| [http://www.w3.org/TR/its/ ITS]<br />
| <br />
| Proposal<br />
|-<br />
| icon<br />
|colspan=6| See HTML5<br />
|-<br />
| index<br />
|colspan=6| See HTML5<br />
|-<br />
| jump<br />
| not allowed<br />
| hyperlink<br />
| Indicates a same page jump from the current fragment to another fragment. (E.g. sometimes online newspapers insert direct text saying "article continues below the image/advert" - they could instead use "jump" link. Ultimately, it indicates a page internal link.)<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| kin<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is part of the extended family of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| lang-alt-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in an alternative language. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| lang-orig-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in the language the document was originally written in. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| last<br />
|colspan=6| See HTML5<br />
|-<br />
| license<br />
|colspan=6| See HTML5<br />
|-<br />
| logout<br />
| external resource<br />
| not allowed<br />
| The linked document provides a resource for the UA to request when all currently open documents of the same "group" are closed (to facilitate logging out the current user).<br />
| [[LogoutRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| me<br />
| hyperlink<br />
| hyperlink<br />
| the referenced document represents the same person as does the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| met<br />
| hyperlink<br />
| hyperlink<br />
| this person has met the referenced person<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| muse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person inspires the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| neighbor<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives nearby the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| next<br />
|colspan=6| See HTML5<br />
|-<br />
| next-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately following archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| nofollow<br />
|colspan=6| See HTML5<br />
|-<br />
| noreferrer<br />
|colspan=6| See HTML5<br />
|-<br />
| noprefetch<br />
| external resource<br />
| hyperlink<br />
| Denies prefetching (not fetching) as a cost-control option for website owners, especially where pages are dynamic, leading to prefetching of wrong and useless pages.<br /><br />
The link provides a per-page denial whereas a and area provide a per-element denial.<br /><br />
For link, attributes rel="noprefetch" denies prefetching of the page at the href URL and rev="noprefetch" denies prefetching of the page bearing the link.<br /><br />
For a and area, rel is as above and rev is meaningless.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 W3C Bug 7918]<br />
| <br />
| Proposal<br />
|-<br />
| note<br />
| not allowed<br />
| hyperlink<br />
| An in-page or out-page jump to a footnote. This encompasses ''note'', ''footnote'', ''endnote'', and ''sidenote''.<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| openid.delegate<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid.server<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.local_id<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.provider<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication endpoint<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| parent<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a parent of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| payment<br />
| hyperlink<br />
| hyperlink<br />
| A URI where payment is accepted.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations]<br />
| <br />
| Proposal<br />
|-<br />
| pgpkey<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.<br />
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]<br />
| <br />
| Proposal<br />
|-<br />
| pingback<br />
|colspan=6| See HTML5<br />
|-<br />
| prefetch<br />
|colspan=6| See HTML5<br />
|-<br />
| prev<br />
|colspan=6| See HTML5<br />
|-<br />
| prev-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately preceding archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| print<br />
| external resource<br />
| hyperlink<br />
| The referenced document is recommended for printing, even though the referent document is capable of being printed and both documents are of the same type, medium, and language. A typical case is where content spread over multiple pages is also available on a single page that is more convenient to print.<br />
This is semantically more specific than "canonical" and "alternate". Where type, medium, and/or language differ, consider "alternate"; where any of them differ but the purpose is printing, consider applying both values.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7645 W3C Bug 7645]<br />
| <br />
| Proposal<br />
|-<br />
| profile<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link is a metadata profile for the current document<br />
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles], <br />[http://www.w3.org/2003/g/glean-profile Example of profile in a-elements]<br />
| <br />
| Proposal<br />
|-<br />
| related<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link identifies a resource related to the current document<br />
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]<br />
| <br />
| Proposal<br />
|-<br />
| resource-package<br />
| external resource<br />
| not allowed<br />
| The linked document is a zipped resource package<br />
| [http://limi.net/articles/resource-packages/ Resource Packages]<br />
| <br />
| Proposal<br />
|-<br />
| reviewer<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.<br />
| [http://wiki.csswg.org/test/css2.1/format#reviewer]<br />
| <br />
| Proposal<br />
|-<br />
| script<br />
| not allowed<br />
| not allowed<br />
| Was proposed to replace &lt;script>. Use &lt;script> instead.<br />
| none<br />
| <br />
| Rejected<br />
|-<br />
| search<br />
|colspan=6| See HTML5<br />
|-<br />
| self<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to a resource equivalent to the containing element.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc4287 RFC4287]<br />
| <br />
| Proposal<br />
|-<br />
| service<br />
| external resource<br />
| not allowed<br />
| Points to a resource describing a service API<br />
| [[ServiceRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| shortlink<br />
| hyperlink<br />
| hyperlink<br />
| Identifies a shorter form of the URL for the current document, provided by the document owner.<br />
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]<br />
| <br />
| Proposal<br />
|-<br />
| sibling<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a sibling of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| sidebar<br />
|colspan=6| See HTML5<br />
|-<br />
| spouse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a spouse of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| statechart<br />
| external resource<br />
| not allowed<br />
| A reference to an SCXML document that controls the application-flow of the current HTML document<br />
| [http://www.w3.org/TR/scxml/ SCXML]<br />
|<br />
| Proposal<br />
|-<br />
| stylesheet<br />
|colspan=6| See HTML5<br />
|-<br />
| sweetheart<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be their sweetheart<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| tag<br />
|colspan=6| See HTML5<br />
|-<br />
| technicalauthor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| timesheet<br />
| external resource<br />
| not allowed<br />
| SMIL Timesheet<br />
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]<br />
| <br />
| Proposal<br />
|-<br />
| translatedfrom<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email that has been translation source for the current document. It also indicates that the current document is a translation and not an original work.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| translator<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page. It also indicates that the current page is a translation of an other document, which should be linked through a rel="translatedfrom".<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| up<br />
|colspan=6| See HTML5<br />
|-<br />
| us<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document represents the same organisation as does the current document [cf rel-me]<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| webmaster<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) available for requests about the content of the page.<br />
| <br />
| maintainer<br />
| Proposal<br />
|-<br />
| widget<br />
| hyperlink<br />
| hyperlink<br />
| Points to a widget.<br />
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]<br />
| <br />
| Proposal<br />
|-<br />
| wlwmanifest<br />
| hyperlink<br />
| not allowed<br />
| A link to a manifest for Windows Live Writer.<br />
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]<br />
| <br />
| Proposal<br />
|}<br />
<br />
The "Effect on... link" column must either say "not allowed" if the rel value is not allowed on &lt;link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.<br />
<br />
The "Effect on... a and area" column must either say "not allowed" or "hyperlink".<br />
<br />
For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".<br />
<br />
For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification]. See also [http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=Rationale&diff=4873Rationale2010-05-08T18:39:45Z<p>Ms2ger: Add note</p>
<hr />
<div>This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such browser vendors already have veto power - by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> It is is now in the HTML5 spec as a method of stopping all further html token parsing. It lacks an end tag and just emits the rest of the page as plain text. It throws a parse error upon reaching the end of the document as it is not considered a valid element (and it is missing an end-tag).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hixie</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. The meter element represents a scalar measurement within a known range, such as storage quota usage, a relative popularity rating or relevance indicator. The control allows for the indication of high and low ranges, or minimum, maximum and optimal levels.<br />
<br />
The progress element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload). Progress elmements can also be in the indeterminate state, indicating that something is in progress, but it's completion progress is unknown.<br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, U, EM, and STRONG ===<br />
-- temporary stub --<br />
<br />
== Notes ==<br />
* <code>&lt;meta http-equiv=content-language></code>: http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html<br />
<br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
<br />
== References ==<br />
<references/></div>Ms2gerhttps://wiki.whatwg.org/index.php?title=RelExtensions&diff=4516RelExtensions2010-04-14T16:57:07Z<p>Ms2ger: Wikitable</p>
<hr />
<div>This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it. Note that rel tokens are ASCII-lowercase before comparison against canonical value, so the canonical values should be listed without uppercase ASCII letters.<br />
<br />
{| class=wikitable<br />
|-<br />
! rowspan=2 | Keyword<br />
! colspan=2 | Effect on...<br />
! rowspan=2 | Brief description<br />
! rowspan=2 | Link to more details<br />
! rowspan=2 | Synonyms<br />
! rowspan=2 | Status<br />
|- <br />
! link<br />
! a and area<br />
|-<br />
| accessibility<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains accessibility information for the linking document.<br />
| [http://www.brucelawson.co.uk/2009/rel-accessibility/ Bruce Lawson]<br />
| <br />
| Proposal<br />
|-<br />
| acquaintance<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| ajax<br />
| not allowed<br />
| hyperlink<br />
| The link is controlled through javascript, and will load the page linked to though an ajax interface. Without javascript, it should behave as a normal "a" tag, and content change is done server side.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| alternate<br />
|colspan=6| See HTML5<br />
|-<br />
| archives<br />
|colspan=6| See HTML5<br />
|-<br />
| author<br />
|colspan=6| See HTML5<br />
|-<br />
| bookmark<br />
|colspan=6| See HTML5<br />
|-<br />
| canonical<br />
| hyperlink<br />
| not allowed<br />
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter.<br />
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-domain<br />
| external resource<br />
| not allowed<br />
| More than one domain may have largely similar or identical content but only one of the domains should be indexed for search engines. E.g., a company may have short and long domain names for the same content.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-first<br />
| external resource<br />
| hyperlink<br />
| Where the canonical value should point to a group of pages, but the link can point to only one page, the group of pages can be clarified by choosing the first page in the group and assigning the URL for this rel link.<br />
For security against traffic theft, rev must be meaningless.<br /><br />
This is only shorthand for providing two link elements, one on the noncanonical page to a "canonical" page and the other on the canonical page to the "first" page of the group.<br />
Where the group of pages corresponds to a subdirectory and a canonical URL value can point to the subdirectory resulting in a user arriving at the subdirectory's index page which is part of the group, this shorthand is unnecessary and one rel="canonical" will suffice.<br />
| [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-human<br />
| external resource<br />
| hyperlink<br />
| Pages about a person across many websites can be associated based on name, nationality, birthplace, dates of birth and death, when flourished, and other identifiers.<br />
Search engines could more consistently aggregate same-person pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681 W3C Bug 7681]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-organization<br />
| external resource<br />
| hyperlink<br />
| Pages about an organization across many websites can be associated based on name, headquarters site, and other identifiers.<br />
Search engines could more consistently aggregate same-organization pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7682 W3C Bug 7682]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-wwwnone<br />
| external resource<br />
| hyperlink<br />
| Both bare and www-prefixed domain names usually direct to the same site. Especially when external links to a site vary in the form used, search engine indexing concentrated on only one domain form may raise its credibility. The rel value is the form preferred for indexing, e.g., rel="http://example.net". Nothing to the right of the top-level domain is needed.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| chapter<br />
| hyperlink<br />
| hyperlink<br />
| Target document is a subdocument of the current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| section, subsection, appendix<br />
| Proposal<br />
|-<br />
| child<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a child of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-resident<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives in the same residence as the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-worker<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a co-worker of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| colleague<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a colleague of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contact<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a contact<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contributor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| crush<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| date<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a date (i.e. is dating the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| details<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document contains additional (or complete) details about the current document (for example, a "read more..." hyperlink on a blog page that leads to the full posting).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| dns-prefetch<br />
| external resource<br />
| not allowed<br />
| Force the DNS lookup of specific hostnames.<br />
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla DNS Prefetching], <br />[http://dev.chromium.org/developers/design-documents/dns-prefetching Chromium DNS Prefetching]<br />
| <br />
| Proposal<br />
|-<br />
| edit<br />
| hyperlink<br />
| hyperlink<br />
| Target document is an editable version of the current document.<br />
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]<br />
| <br />
| Proposal<br />
|-<br />
| edituri<br />
| hyperlink<br />
| not allowed<br />
| a link to an RSD file describing how to edit the given page.<br />
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]<br />
| <br />
| Proposal<br />
|-<br />
| enclosure<br />
| hyperlink<br />
| hyperlink<br />
| the destination of the hyperlink is intended to be downloaded and cached.<br />
| [http://microformats.org/wiki/rel-enclosure rel-enclosure]<br />
| <br />
| Proposal<br />
|-<br />
| external<br />
|colspan=6| See HTML5<br />
|-<br />
| first<br />
|colspan=6| See HTML5<br />
|-<br />
| friend<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a friend<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| glossary<br />
| hyperlink<br />
| hyperlink<br />
| Target document provides definitions for words in current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| <br />
| Proposal<br />
|-<br />
| help<br />
|colspan=6| See HTML5<br />
|-<br />
| hub<br />
| hyperlink<br />
| not allowed<br />
| Indicates a URL which implements both sides of the PubSubHubbub protocol.<br />
| [http://code.google.com/p/pubsubhubbub/ PubSubHubbub]<br />
| <br />
| Proposal<br />
|-<br />
| i18nrules<br />
| hyperlink<br />
| not allowed<br />
| Target document provides ITS (Internationalization tag Set) rules for processing the current document.<br />
| [http://www.w3.org/TR/its/ ITS]<br />
| <br />
| Proposal<br />
|-<br />
| icon<br />
|colspan=6| See HTML5<br />
|-<br />
| index<br />
|colspan=6| See HTML5<br />
|-<br />
| jump<br />
| not allowed<br />
| hyperlink<br />
| Indicates a same page jump from the current fragment to another fragment. (E.g. sometimes online newspapers insert direct text saying "article continues below the image/advert" - they could instead use "jump" link. Ultimately, it indicates a page internal link.)<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| kin<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is part of the extended family of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| lang-alt-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in an alternative language. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| lang-orig-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in the language the document was originally written in. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| last<br />
|colspan=6| See HTML5<br />
|-<br />
| license<br />
|colspan=6| See HTML5<br />
|-<br />
| logout<br />
| external resource<br />
| not allowed<br />
| The linked document provides a resource for the UA to request when all currently open documents of the same "group" are closed (to facilitate logging out the current user).<br />
| [[LogoutRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| me<br />
| hyperlink<br />
| hyperlink<br />
| the referenced document represents the same person as does the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| met<br />
| hyperlink<br />
| hyperlink<br />
| this person has met the referenced person<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| muse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person inspires the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| neighbor<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives nearby the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| next<br />
|colspan=6| See HTML5<br />
|-<br />
| next-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately following archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| nofollow<br />
|colspan=6| See HTML5<br />
|-<br />
| noreferrer<br />
|colspan=6| See HTML5<br />
|-<br />
| noprefetch<br />
| external resource<br />
| hyperlink<br />
| Denies prefetching (not fetching) as a cost-control option for website owners, especially where pages are dynamic, leading to prefetching of wrong and useless pages.<br /><br />
The link provides a per-page denial whereas a and area provide a per-element denial.<br /><br />
For link, attributes rel="noprefetch" denies prefetching of the page at the href URL and rev="noprefetch" denies prefetching of the page bearing the link.<br /><br />
For a and area, rel is as above and rev is meaningless.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 W3C Bug 7918]<br />
| <br />
| Proposal<br />
|-<br />
| note<br />
| not allowed<br />
| hyperlink<br />
| An in-page or out-page jump to a footnote. This encompasses ''note'', ''footnote'', ''endnote'', and ''sidenote''.<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| openid.delegate<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid.server<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.local_id<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.provider<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication endpoint<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| parent<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a parent of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| payment<br />
| hyperlink<br />
| hyperlink<br />
| A URI where payment is accepted.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations]<br />
| <br />
| Proposal<br />
|-<br />
| pgpkey<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.<br />
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]<br />
| <br />
| Proposal<br />
|-<br />
| pingback<br />
|colspan=6| See HTML5<br />
|-<br />
| prefetch<br />
|colspan=6| See HTML5<br />
|-<br />
| prev<br />
|colspan=6| See HTML5<br />
|-<br />
| prev-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately preceding archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| print<br />
| external resource<br />
| hyperlink<br />
| The referenced document is recommended for printing, even though the referent document is capable of being printed and both documents are of the same type, medium, and language. A typical case is where content spread over multiple pages is also available on a single page that is more convenient to print.<br />
This is semantically more specific than "canonical" and "alternate". Where type, medium, and/or language differ, consider "alternate"; where any of them differ but the purpose is printing, consider applying both values.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7645 W3C Bug 7645]<br />
| <br />
| Proposal<br />
|-<br />
| profile<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link is a metadata profile for the current document<br />
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles], <br />[http://www.w3.org/2003/g/glean-profile Example of profile in a-elements]<br />
| <br />
| Proposal<br />
|-<br />
| related<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link identifies a resource related to the current document<br />
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]<br />
| <br />
| Proposal<br />
|-<br />
| resource-package<br />
| external resource<br />
| not allowed<br />
| The linked document is a zipped resource package<br />
| [http://limi.net/articles/resource-packages/ Resource Packages]<br />
| <br />
| Proposal<br />
|-<br />
| reviewer<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.<br />
| [http://wiki.csswg.org/test/css2.1/format#reviewer]<br />
| <br />
| Proposal<br />
|-<br />
| script<br />
| not allowed<br />
| not allowed<br />
| Was proposed to replace &lt;script>. Use &lt;script> instead.<br />
| none<br />
| <br />
| Rejected<br />
|-<br />
| search<br />
|colspan=6| See HTML5<br />
|-<br />
| self<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to a resource equivalent to the containing element.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc4287 RFC4287]<br />
| <br />
| Proposal<br />
|-<br />
| service<br />
| external resource<br />
| not allowed<br />
| Points to a resource describing a service API<br />
| [[ServiceRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| shortlink<br />
| hyperlink<br />
| hyperlink<br />
| Identifies a shorter form of the URL for the current document, provided by the document owner.<br />
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]<br />
| <br />
| Proposal<br />
|-<br />
| sibling<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a sibling of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| sidebar<br />
|colspan=6| See HTML5<br />
|-<br />
| spouse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a spouse of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| statechart<br />
| external resource<br />
| not allowed<br />
| A reference to an SCXML document that controls the application-flow of the current HTML document<br />
| [http://www.w3.org/TR/scxml/ SCXML]<br />
|<br />
| Proposal<br />
|-<br />
| stylesheet<br />
|colspan=6| See HTML5<br />
|-<br />
| sweetheart<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be their sweetheart<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| tag<br />
|colspan=6| See HTML5<br />
|-<br />
| technicalauthor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| timesheet<br />
| external resource<br />
| not allowed<br />
| SMIL Timesheet<br />
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]<br />
| <br />
| Proposal<br />
|-<br />
| translatedfrom<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email that has been translation source for the current document. It also indicates that the current document is a translation and not an original work.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| translator<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page. It also indicates that the current page is a translation of an other document, which should be linked through a rel="translatedfrom".<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| up<br />
|colspan=6| See HTML5<br />
|-<br />
| webmaster<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) available for requests about the content of the page.<br />
| <br />
| maintainer<br />
| Proposal<br />
|-<br />
| widget<br />
| hyperlink<br />
| hyperlink<br />
| Points to a widget.<br />
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]<br />
| <br />
| Proposal<br />
|-<br />
| wlwmanifest<br />
| hyperlink<br />
| not allowed<br />
| A link to a manifest for Windows Live Writer.<br />
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]<br />
| <br />
| Proposal<br />
|}<br />
<br />
The "Effect on... link" column must either say "not allowed" if the rel value is not allowed on &lt;link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.<br />
<br />
The "Effect on... a and area" column must either say "not allowed" or "hyperlink".<br />
<br />
For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".<br />
<br />
For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification]. See also [http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].</div>Ms2gerhttps://wiki.whatwg.org/index.php?title=RelExtensions&diff=4515RelExtensions2010-04-14T16:54:43Z<p>Ms2ger: Remove feed</p>
<hr />
<div>This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it. Note that rel tokens are ASCII-lowercase before comparison against canonical value, so the canonical values should be listed without uppercase ASCII letters.<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
! rowspan=2 | Keyword<br />
! colspan=2 | Effect on...<br />
! rowspan=2 | Brief description<br />
! rowspan=2 | Link to more details<br />
! rowspan=2 | Synonyms<br />
! rowspan=2 | Status<br />
|- <br />
! link<br />
! a and area<br />
|-<br />
| accessibility<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains accessibility information for the linking document.<br />
| [http://www.brucelawson.co.uk/2009/rel-accessibility/ Bruce Lawson]<br />
| <br />
| Proposal<br />
|-<br />
| acquaintance<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| ajax<br />
| not allowed<br />
| hyperlink<br />
| The link is controlled through javascript, and will load the page linked to though an ajax interface. Without javascript, it should behave as a normal "a" tag, and content change is done server side.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| alternate<br />
|colspan=6| See HTML5<br />
|-<br />
| archives<br />
|colspan=6| See HTML5<br />
|-<br />
| author<br />
|colspan=6| See HTML5<br />
|-<br />
| bookmark<br />
|colspan=6| See HTML5<br />
|-<br />
| canonical<br />
| hyperlink<br />
| not allowed<br />
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter.<br />
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-domain<br />
| external resource<br />
| not allowed<br />
| More than one domain may have largely similar or identical content but only one of the domains should be indexed for search engines. E.g., a company may have short and long domain names for the same content.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-first<br />
| external resource<br />
| hyperlink<br />
| Where the canonical value should point to a group of pages, but the link can point to only one page, the group of pages can be clarified by choosing the first page in the group and assigning the URL for this rel link.<br />
For security against traffic theft, rev must be meaningless.<br /><br />
This is only shorthand for providing two link elements, one on the noncanonical page to a "canonical" page and the other on the canonical page to the "first" page of the group.<br />
Where the group of pages corresponds to a subdirectory and a canonical URL value can point to the subdirectory resulting in a user arriving at the subdirectory's index page which is part of the group, this shorthand is unnecessary and one rel="canonical" will suffice.<br />
| [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-human<br />
| external resource<br />
| hyperlink<br />
| Pages about a person across many websites can be associated based on name, nationality, birthplace, dates of birth and death, when flourished, and other identifiers.<br />
Search engines could more consistently aggregate same-person pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681 W3C Bug 7681]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-organization<br />
| external resource<br />
| hyperlink<br />
| Pages about an organization across many websites can be associated based on name, headquarters site, and other identifiers.<br />
Search engines could more consistently aggregate same-organization pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7682 W3C Bug 7682]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-wwwnone<br />
| external resource<br />
| hyperlink<br />
| Both bare and www-prefixed domain names usually direct to the same site. Especially when external links to a site vary in the form used, search engine indexing concentrated on only one domain form may raise its credibility. The rel value is the form preferred for indexing, e.g., rel="http://example.net". Nothing to the right of the top-level domain is needed.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| chapter<br />
| hyperlink<br />
| hyperlink<br />
| Target document is a subdocument of the current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| section, subsection, appendix<br />
| Proposal<br />
|-<br />
| child<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a child of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-resident<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives in the same residence as the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-worker<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a co-worker of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| colleague<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a colleague of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contact<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a contact<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contributor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| crush<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| date<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a date (i.e. is dating the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| details<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document contains additional (or complete) details about the current document (for example, a "read more..." hyperlink on a blog page that leads to the full posting).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| dns-prefetch<br />
| external resource<br />
| not allowed<br />
| Force the DNS lookup of specific hostnames.<br />
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla DNS Prefetching], <br />[http://dev.chromium.org/developers/design-documents/dns-prefetching Chromium DNS Prefetching]<br />
| <br />
| Proposal<br />
|-<br />
| edit<br />
| hyperlink<br />
| hyperlink<br />
| Target document is an editable version of the current document.<br />
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]<br />
| <br />
| Proposal<br />
|-<br />
| edituri<br />
| hyperlink<br />
| not allowed<br />
| a link to an RSD file describing how to edit the given page.<br />
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]<br />
| <br />
| Proposal<br />
|-<br />
| enclosure<br />
| hyperlink<br />
| hyperlink<br />
| the destination of the hyperlink is intended to be downloaded and cached.<br />
| [http://microformats.org/wiki/rel-enclosure rel-enclosure]<br />
| <br />
| Proposal<br />
|-<br />
| external<br />
|colspan=6| See HTML5<br />
|-<br />
| first<br />
|colspan=6| See HTML5<br />
|-<br />
| friend<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a friend<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| glossary<br />
| hyperlink<br />
| hyperlink<br />
| Target document provides definitions for words in current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| <br />
| Proposal<br />
|-<br />
| help<br />
|colspan=6| See HTML5<br />
|-<br />
| hub<br />
| hyperlink<br />
| not allowed<br />
| Indicates a URL which implements both sides of the PubSubHubbub protocol.<br />
| [http://code.google.com/p/pubsubhubbub/ PubSubHubbub]<br />
| <br />
| Proposal<br />
|-<br />
| i18nrules<br />
| hyperlink<br />
| not allowed<br />
| Target document provides ITS (Internationalization tag Set) rules for processing the current document.<br />
| [http://www.w3.org/TR/its/ ITS]<br />
| <br />
| Proposal<br />
|-<br />
| icon<br />
|colspan=6| See HTML5<br />
|-<br />
| index<br />
|colspan=6| See HTML5<br />
|-<br />
| jump<br />
| not allowed<br />
| hyperlink<br />
| Indicates a same page jump from the current fragment to another fragment. (E.g. sometimes online newspapers insert direct text saying "article continues below the image/advert" - they could instead use "jump" link. Ultimately, it indicates a page internal link.)<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| kin<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is part of the extended family of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| lang-alt-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in an alternative language. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| lang-orig-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in the language the document was originally written in. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| last<br />
|colspan=6| See HTML5<br />
|-<br />
| license<br />
|colspan=6| See HTML5<br />
|-<br />
| logout<br />
| external resource<br />
| not allowed<br />
| The linked document provides a resource for the UA to request when all currently open documents of the same "group" are closed (to facilitate logging out the current user).<br />
| [[LogoutRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| me<br />
| hyperlink<br />
| hyperlink<br />
| the referenced document represents the same person as does the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| met<br />
| hyperlink<br />
| hyperlink<br />
| this person has met the referenced person<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| muse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person inspires the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| neighbor<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives nearby the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| next<br />
|colspan=6| See HTML5<br />
|-<br />
| next-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately following archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| nofollow<br />
|colspan=6| See HTML5<br />
|-<br />
| noreferrer<br />
|colspan=6| See HTML5<br />
|-<br />
| noprefetch<br />
| external resource<br />
| hyperlink<br />
| Denies prefetching (not fetching) as a cost-control option for website owners, especially where pages are dynamic, leading to prefetching of wrong and useless pages.<br /><br />
The link provides a per-page denial whereas a and area provide a per-element denial.<br /><br />
For link, attributes rel="noprefetch" denies prefetching of the page at the href URL and rev="noprefetch" denies prefetching of the page bearing the link.<br /><br />
For a and area, rel is as above and rev is meaningless.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 W3C Bug 7918]<br />
| <br />
| Proposal<br />
|-<br />
| note<br />
| not allowed<br />
| hyperlink<br />
| An in-page or out-page jump to a footnote. This encompasses ''note'', ''footnote'', ''endnote'', and ''sidenote''.<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| openid.delegate<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid.server<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.local_id<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.provider<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication endpoint<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| parent<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a parent of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| payment<br />
| hyperlink<br />
| hyperlink<br />
| A URI where payment is accepted.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations]<br />
| <br />
| Proposal<br />
|-<br />
| pgpkey<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.<br />
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]<br />
| <br />
| Proposal<br />
|-<br />
| pingback<br />
|colspan=6| See HTML5<br />
|-<br />
| prefetch<br />
|colspan=6| See HTML5<br />
|-<br />
| prev<br />
|colspan=6| See HTML5<br />
|-<br />
| prev-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately preceding archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| print<br />
| external resource<br />
| hyperlink<br />
| The referenced document is recommended for printing, even though the referent document is capable of being printed and both documents are of the same type, medium, and language. A typical case is where content spread over multiple pages is also available on a single page that is more convenient to print.<br />
This is semantically more specific than "canonical" and "alternate". Where type, medium, and/or language differ, consider "alternate"; where any of them differ but the purpose is printing, consider applying both values.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7645 W3C Bug 7645]<br />
| <br />
| Proposal<br />
|-<br />
| profile<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link is a metadata profile for the current document<br />
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles], <br />[http://www.w3.org/2003/g/glean-profile Example of profile in a-elements]<br />
| <br />
| Proposal<br />
|-<br />
| related<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link identifies a resource related to the current document<br />
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]<br />
| <br />
| Proposal<br />
|-<br />
| resource-package<br />
| external resource<br />
| not allowed<br />
| The linked document is a zipped resource package<br />
| [http://limi.net/articles/resource-packages/ Resource Packages]<br />
| <br />
| Proposal<br />
|-<br />
| reviewer<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.<br />
| [http://wiki.csswg.org/test/css2.1/format#reviewer]<br />
| <br />
| Proposal<br />
|-<br />
| script<br />
| not allowed<br />
| not allowed<br />
| Was proposed to replace &lt;script>. Use &lt;script> instead.<br />
| none<br />
| <br />
| Rejected<br />
|-<br />
| search<br />
|colspan=6| See HTML5<br />
|-<br />
| self<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to a resource equivalent to the containing element.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc4287 RFC4287]<br />
| <br />
| Proposal<br />
|-<br />
| service<br />
| external resource<br />
| not allowed<br />
| Points to a resource describing a service API<br />
| [[ServiceRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| shortlink<br />
| hyperlink<br />
| hyperlink<br />
| Identifies a shorter form of the URL for the current document, provided by the document owner.<br />
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]<br />
| <br />
| Proposal<br />
|-<br />
| sibling<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a sibling of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| sidebar<br />
|colspan=6| See HTML5<br />
|-<br />
| spouse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a spouse of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| statechart<br />
| external resource<br />
| not allowed<br />
| A reference to an SCXML document that controls the application-flow of the current HTML document<br />
| [http://www.w3.org/TR/scxml/ SCXML]<br />
|<br />
| Proposal<br />
|-<br />
| stylesheet<br />
|colspan=6| See HTML5<br />
|-<br />
| sweetheart<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be their sweetheart<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| tag<br />
|colspan=6| See HTML5<br />
|-<br />
| technicalauthor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| timesheet<br />
| external resource<br />
| not allowed<br />
| SMIL Timesheet<br />
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]<br />
| <br />
| Proposal<br />
|-<br />
| translatedfrom<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email that has been translation source for the current document. It also indicates that the current document is a translation and not an original work.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| translator<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page. It also indicates that the current page is a translation of an other document, which should be linked through a rel="translatedfrom".<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| up<br />
|colspan=6| See HTML5<br />
|-<br />
| webmaster<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) available for requests about the content of the page.<br />
| <br />
| maintainer<br />
| Proposal<br />
|-<br />
| widget<br />
| hyperlink<br />
| hyperlink<br />
| Points to a widget.<br />
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]<br />
| <br />
| Proposal<br />
|-<br />
| wlwmanifest<br />
| hyperlink<br />
| not allowed<br />
| A link to a manifest for Windows Live Writer.<br />
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]<br />
| <br />
| Proposal<br />
|}<br />
<br />
The "Effect on... link" column must either say "not allowed" if the rel value is not allowed on &lt;link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.<br />
<br />
The "Effect on... a and area" column must either say "not allowed" or "hyperlink".<br />
<br />
For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".<br />
<br />
For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification]. See also [http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].</div>Ms2ger