https://wiki.whatwg.org/api.php?action=feedcontributions&user=Zcorpan&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-29T10:30:02ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=W3C&diff=10279W3C2018-09-25T14:49:46Z<p>Zcorpan: /* The WHATWG is Formed */ Omit some no longer relevant text</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 />
** ?? 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>Zcorpanhttps://wiki.whatwg.org/index.php?title=W3C&diff=10278W3C2018-09-25T14:47:38Z<p>Zcorpan: /* The Mozilla/Opera Joint Position Paper */ Omit compound documents and XBL reference</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 />
** ?? 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. The editor acts as a benevolent dictator who writes the specifications taking into account the contributions. The WHATWG members “provide overall guidance”, which means the power to impeach and replace the editor of the specifications.<br />
<br />
Microsoft is not expected to implement the WHATWG specifications in Internet Explorer in the near term. Instead, the implementations of the WHATWG specifications for IE are expected to be built by teams not affiliated with Microsoft using the extensibility mechanisms provided by Microsoft in IE.<br />
<br />
I share the view of the Web that holds WebKit, Presto, Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox and IE, respectively) to be the most important browser engines.<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=W3C&diff=10277W3C2018-09-25T09:45:32Z<p>Zcorpan: Elaborate on testing</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 />
** ?? 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 />
The paper stated two design principles for compound documents (documents that mix different XML vocabularies): “Don’t overuse namespaces” and “Migration path”. The latter was related to the problems with the HTML to XHTML migration discussed above. The position paper was dismissive of schema languages.<br />
<br />
The paper went on to list specific features that a Web application host environment should provide. It made several references to XBL, which has been a very politicized language (but is now on track to become a W3C Recommendation).<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. The editor acts as a benevolent dictator who writes the specifications taking into account the contributions. The WHATWG members “provide overall guidance”, which means the power to impeach and replace the editor of the specifications.<br />
<br />
Microsoft is not expected to implement the WHATWG specifications in Internet Explorer in the near term. Instead, the implementations of the WHATWG specifications for IE are expected to be built by teams not affiliated with Microsoft using the extensibility mechanisms provided by Microsoft in IE.<br />
<br />
I share the view of the Web that holds WebKit, Presto, Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox and IE, respectively) to be the most important browser engines.<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=W3C&diff=10276W3C2018-09-25T08:02:52Z<p>Zcorpan: </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 />
** ?? many versions of canvas<br />
* Has (or had?) a Process that encourages bad testing: https://groups.google.com/d/msg/mozilla.dev.platform/BnY1261cNJo/ItsnSsi36QQJ<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 />
The paper stated two design principles for compound documents (documents that mix different XML vocabularies): “Don’t overuse namespaces” and “Migration path”. The latter was related to the problems with the HTML to XHTML migration discussed above. The position paper was dismissive of schema languages.<br />
<br />
The paper went on to list specific features that a Web application host environment should provide. It made several references to XBL, which has been a very politicized language (but is now on track to become a W3C Recommendation).<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. The editor acts as a benevolent dictator who writes the specifications taking into account the contributions. The WHATWG members “provide overall guidance”, which means the power to impeach and replace the editor of the specifications.<br />
<br />
Microsoft is not expected to implement the WHATWG specifications in Internet Explorer in the near term. Instead, the implementations of the WHATWG specifications for IE are expected to be built by teams not affiliated with Microsoft using the extensibility mechanisms provided by Microsoft in IE.<br />
<br />
I share the view of the Web that holds WebKit, Presto, Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox and IE, respectively) to be the most important browser engines.<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=W3C&diff=10275W3C2018-09-24T18:44:41Z<p>Zcorpan: Testing situation may be different today</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 />
** ?? many versions of canvas<br />
* Has (or had?) a Process that encourages bad testing: https://groups.google.com/d/msg/mozilla.dev.platform/BnY1261cNJo/ItsnSsi36QQJ<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 />
The paper stated two design principles for compound documents (documents that mix different XML vocabularies): “Don’t overuse namespaces” and “Migration path”. The latter was related to the problems with the HTML to XHTML migration discussed above. The position paper was dismissive of schema languages.<br />
<br />
The paper went on to list specific features that a Web application host environment should provide. It made several references to XBL, which has been a very politicized language (but is now on track to become a W3C Recommendation).<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. The editor acts as a benevolent dictator who writes the specifications taking into account the contributions. The WHATWG members “provide overall guidance”, which means the power to impeach and replace the editor of the specifications.<br />
<br />
Microsoft is not expected to implement the WHATWG specifications in Internet Explorer in the near term. Instead, the implementations of the WHATWG specifications for IE are expected to be built by teams not affiliated with Microsoft using the extensibility mechanisms provided by Microsoft in IE.<br />
<br />
I share the view of the Web that holds WebKit, Presto, Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox and IE, respectively) to be the most important browser engines.<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 />
=== Post 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>Zcorpanhttps://wiki.whatwg.org/index.php?title=W3C&diff=10274W3C2018-09-24T18:43:49Z<p>Zcorpan: Include history of W3C and WHATWG</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 />
** ?? many versions of canvas<br />
* Has a Process that encourages bad testing: https://groups.google.com/d/msg/mozilla.dev.platform/BnY1261cNJo/ItsnSsi36QQJ<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 />
The paper stated two design principles for compound documents (documents that mix different XML vocabularies): “Don’t overuse namespaces” and “Migration path”. The latter was related to the problems with the HTML to XHTML migration discussed above. The position paper was dismissive of schema languages.<br />
<br />
The paper went on to list specific features that a Web application host environment should provide. It made several references to XBL, which has been a very politicized language (but is now on track to become a W3C Recommendation).<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. The editor acts as a benevolent dictator who writes the specifications taking into account the contributions. The WHATWG members “provide overall guidance”, which means the power to impeach and replace the editor of the specifications.<br />
<br />
Microsoft is not expected to implement the WHATWG specifications in Internet Explorer in the near term. Instead, the implementations of the WHATWG specifications for IE are expected to be built by teams not affiliated with Microsoft using the extensibility mechanisms provided by Microsoft in IE.<br />
<br />
I share the view of the Web that holds WebKit, Presto, Gecko and Trident (the engines of Safari, Opera, Mozilla/Firefox and IE, respectively) to be the most important browser engines.<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 />
=== Post 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>Zcorpanhttps://wiki.whatwg.org/index.php?title=Who_to_ask_about_stuff&diff=10267Who to ask about stuff2018-02-03T09:50:03Z<p>Zcorpan: </p>
<hr />
<div>This page is intended as a hub for information for spec editors regarding who to contact at various browser vendors and other implementors for various topics.<br />
<br />
== Mozilla ==<br />
<br />
See: [https://wiki.mozilla.org/Modules/Core Module Owners]<br />
<br />
People generally like being cc'ed on bugs for feedback; sicking says he prefers direct e-mail.<br />
<br />
== WebKit ==<br />
<br />
Presumably: [https://webkit.org/team/ WebKit Team]<br />
<br />
== Opera/Chrome ==<br />
<br />
Presumably: https://groups.google.com/a/chromium.org/forum/#!forum/chromium-dev<br />
<br />
== Edge ==<br />
<br />
Contact Travis Leithead <travis.leithead@microsoft.com> for everything; he'll direct your call.<br />
<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=IRC&diff=10237IRC2017-12-12T14:47:35Z<p>Zcorpan: Add a section about bots</p>
<hr />
<div>The Freenode IRC network has a channel called [irc://irc.freenode.net/whatwg #whatwg] where some of the more active WHATWG community members hang out. Feel free to join us!<br />
<br />
Note that if you go to IRC to ask a question, it might take a while to get a reply. It can pay off to stick around for a couple of hours or more.<br />
<br />
If you want to run a bot, let us know. If they are useful, e.g. providing logging facilities, then they are more than welcome.<br />
<br />
== Logs ==<br />
<br />
Logs for the #whatwg channel can be found here:<br />
<br />
* https://freenode.logbot.info/whatwg<br />
* https://krijnhoetmer.nl/irc-logs/ (not updated since 2016-04)<br />
<br />
== Bots ==<br />
<br />
To leave a message to someone who is offline you can do<br />
<br />
botie, inform <nick> [that|to|about] <message><br />
<br />
Source/docs for botie is at https://github.com/w3c/infobot<br />
<br />
== Getting Started with IRC ==<br />
<br />
The simplest way to get started with IRC, if you are not familiar, is by signing up for a free [https://www.irccloud.com/ IRCCloud] account. Once you've done that, you should be logged in to the Freenode server by default. All you'll have to do is join the #whatwg channel. If you tell your browser to use IRCCloud for irc:// links, then just [irc://irc.freenode.net/whatwg clicking this link] should also take you there.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Testsuite&diff=10190Testsuite2017-08-24T12:34:42Z<p>Zcorpan: Update testsuite page, fix redirecting links</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.<br />
<br />
Tests are contributed by community members, including implementers and specification editors. Different specifications are accompanied by testsuites of varying breadth and depth.<br />
<br />
In order to contribute tests to the testsuite for a WHATWG standard, follow the instructions on http://web-platform-tests.org/.<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 />
* [https://trac.webkit.org/browser/trunk/LayoutTests (Some of?) WebKit's tests]<br />
* [[Testsuite/Mozilla]]<br />
* [https://dxr.mozilla.org/mozilla-central/search?q=file%3Areftest.list Some of Mozilla's reftests]<br />
* [https://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 />
* [https://bitbucket.org/gsnedders/php-html-5-direct/src/8c27462f5f410319011f30ce7151ed1d6f17b800/tests/numbersTest?at=default&fileviewer=file-view-default gsnedders' number parsing tests]<br />
* [https://simon.html5.org/test/html/ zcorpan's tests]<br />
* [https://hasather.net/test/html/ David Håsäther's tests]<br />
* [https://mathias.html5.org/tests/ Mathias’s tests]<br />
* [https://hsivonen.com/test/moz/video-selection/ hsivonen's video tests]<br />
* [https://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>Zcorpanhttps://wiki.whatwg.org/index.php?title=Test_cases&diff=10189Test cases2017-08-24T12:23:14Z<p>Zcorpan: Redirect to Testsuite</p>
<hr />
<div>#REDIRECT [[Testsuite]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=What_you_can_do&diff=10188What you can do2017-08-24T12:12:39Z<p>Zcorpan: Fix [GitHub repositories] link (thanks xfq)</p>
<hr />
<div>So you want to take part? You can!<br />
* Review [http://whatwg.org/specs/ the specifications] and [http://whatwg.org/mailing-list#specs send comments]! (See below for details.)<br />
* Write articles for our [http://blog.whatwg.org/ blog].<br />
* Write [[Authoring|tutorials]] for new web developers.<br />
* Maintain the document explaining the [[rationale]] of the decisions behind the spec. (See below for details.)<br />
* Write [[test cases]].<br />
* Write cool demos.<br />
* [[:Category:Implementations|Implement HTML]]!<br />
* Edit one of the many [[Specs todo|companion specifications]] that are lacking editors.<br />
<br />
== Sending feedback ==<br />
The most useful thing would be going through the spec and finding bits that don't make sense. <br />
<br />
https://html.spec.whatwg.org/multipage/<br />
<br />
You can use the link at the bottom (it says "File an issue about the selected text") to submit review comments on the spec. The best review comments are those along the lines of questions you couldn't find the answer to. For example, say you wanted to find out what elements you could put in a &lt;p> element, and you couldn't work it out. Then you would file a bug "I couldn't find the answer to the question 'What elements are allowed inside &lt;p> elements'.".<br />
<br />
'''See also [[Reviewing]].'''<br />
<br />
== A rationale document ==<br />
<br />
It basically would consist of watching the [https://github.com/whatwg GitHub repositories] that are of interest,<br />
asking questions on [[IRC]], and then writing documentation to<br />
explain the thinking behind different parts of the spec on the [[rationale]] page.<br />
<br />
It could be as little work or as much work as you would want it to be. One<br />
could easily imagine this becoming a group effort.<br />
<br />
= How you can improve HTML =<br />
<br />
''This text originated from an article Hixie wrote.''<br />
<br />
Are you trying to do something on the Web that you find you can't do because HTML simply doesn't have a way to do it?<br />
<br />
With your help, we can improve HTML, add a feature to address your problem, and in a few years you'll finally be able to do it!<br />
<br />
Here's how:<br />
<br />
First, write a brief user-centric description of the problem. What are you trying to do? This should be a high-level description. One way to see if you're describing it at a high<br />
enough level is to consider whether your description makes as much sense for a Web developer as it does for, say, a mobile phone native app developer. So if your<br />
description talks about HTML elements or JavaScript or HTTP headers, then it's probably too low level. If it talks about what a user sees, how a user interacts<br />
with a computer or device, or how a user uses a computer or device to create some sort of content or effect some sort of change, then you're on the right path.<br />
If you hear people referring to "use cases", it is to this problem description that they refer. Some of the most useful information you can give is examples of what<br />
people are currently doing to work around the problem (e.g. they're writing native apps instead of Web pages, or they're using Flash or other extensions, etc).<br />
<br />
In particular, your description should not be a solution. Don't propose new elements or attributes, new APIs, new semantics, new features. The time for<br />
discussions of solutions is later.<br />
<br />
Next, do one or more of the following with this description:<br />
<br />
* Discuss the topic on our [[IRC]] channel (#whatwg on Freenode) to see if you've missed anything obvious<br />
* Post it as an issue at http://whatwg.org/newbug<br />
<br />
Participate in any resulting discussions. Post a link to your issue to your own blog or to other social media sites to<br />
encourage others to participate. For best results, I recommend that you avoid creating new places for the discussion to occur (e.g. new mailing lists, wiki<br />
pages, or working groups). Keeping the discussions in existing places ensures that experience participants will see your discussions and will be able to<br />
lend you their experience. The most important part of these discussions is clarifying how common the problem is, what related problems other people have<br />
that could maybe be addressed at the same time, and what work-arounds exist to avoid the problem.<br />
<br />
Ideally, some browser vendors will at this point start commenting on the problem, hopefully saying that they agree that it's a problem. Getting browser vendors <br />
to believe there's a problem is the second best thing that you can do to ensure your problems gets solved. (The best thing that can happen is for browser vendors<br />
to implement a solution. See notes below.) Once you have browser vendors buying-in to the problem's importance, you can start talking about possible solutions.<br />
(You don't have to, though, and there's no guarantee that the solutions you propose will be adopted rather than some other ones.)<br />
<br />
When it comes to updating the standard, see https://whatwg.org/working-mode for what the process is. It boils down to writing a pull request for the standard and<br />
writing test cases, and getting support from implementers.<br />
<br />
You may ask why browser vendors have a prominent role in this process. The answer is simple. The specification is not magical; it cannot force browser vendors to<br />
do anything they don't want to do. If I write something in the spec and they don't implement it, there's nothing we can do: the feature doesn't really exist,<br />
it's just fiction, and we've all wasted our time. To avoid wasting my time, I try to work with the browser vendors to make sure that what I specify is something<br />
they're willing to implement. (It doesn't always work out that way, but then after a while I update the spec to match what they did do, or didn't do, e.g.<br />
removing things that nobody has implemented.)<br />
<br />
If you want to participate in the process in ways other than reporting problems you find with the Web, there are various things you can do: participate in<br />
discussions on GitHub; chat with us on IRC (#whatwg on Freenode); write test cases; write tutorials; review the spec...<br />
The best place to start is to join us on IRC and ask what you can do.<br />
<br />
We also have a FAQ: https://whatwg.org/faq</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Rationale&diff=10187Rationale2017-08-24T08:46:32Z<p>Zcorpan: Update rationale for custom elements</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 />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
In the past, the contents of the spec tended to be determined by browsers&rsquo; <i>de facto</i> feature set. After all, one of the main purposes of the spec is to describe reality (regardless of what the spec editor, members, and contributors think). Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec. That is to say, in the past, browsers tended to dictate what was in the spec, whereas today, it's the converse.<br />
<br />
Thus, the spec must include all already-implemented features . A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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 />
=== It isn&rsquo;t just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won&rsquo;t use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref><br />
<br />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>https://html.spec.whatwg.org//multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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>https://html.spec.whatwg.org//#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><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 [https://html.spec.whatwg.org//multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [https://html.spec.whatwg.org//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 />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [https://html.spec.whatwg.org//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 />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<br />
There is; it is now allowed to use <code>&lt;div></code> in <code>&lt;dl></code>. See https://github.com/whatwg/html/issues/1937<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make custom HTML elements? ===<br />
<br />
It is now allowed, see https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements<br />
<br />
Be aware however that using custom elements when standard elements could have been used make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=Rationale&diff=10186Rationale2017-08-24T08:42:40Z<p>Zcorpan: Fix wiki markup</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 />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
In the past, the contents of the spec tended to be determined by browsers&rsquo; <i>de facto</i> feature set. After all, one of the main purposes of the spec is to describe reality (regardless of what the spec editor, members, and contributors think). Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec. That is to say, in the past, browsers tended to dictate what was in the spec, whereas today, it's the converse.<br />
<br />
Thus, the spec must include all already-implemented features . A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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 />
=== It isn&rsquo;t just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won&rsquo;t use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref><br />
<br />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>https://html.spec.whatwg.org//multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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>https://html.spec.whatwg.org//#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><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 [https://html.spec.whatwg.org//multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [https://html.spec.whatwg.org//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 />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [https://html.spec.whatwg.org//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 />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<br />
There is; it is now allowed to use <code>&lt;div></code> in <code>&lt;dl></code>. See https://github.com/whatwg/html/issues/1937<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make custom HTML elements? ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=Rationale&diff=10185Rationale2017-08-24T08:38:03Z<p>Zcorpan: Update rationale for grouping-type element for dl</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 />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
In the past, the contents of the spec tended to be determined by browsers&rsquo; <i>de facto</i> feature set. After all, one of the main purposes of the spec is to describe reality (regardless of what the spec editor, members, and contributors think). Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec. That is to say, in the past, browsers tended to dictate what was in the spec, whereas today, it's the converse.<br />
<br />
Thus, the spec must include all already-implemented features . A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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 />
=== It isn&rsquo;t just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won&rsquo;t use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref><br />
<br />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>https://html.spec.whatwg.org//multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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>https://html.spec.whatwg.org//#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><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 [https://html.spec.whatwg.org//multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [https://html.spec.whatwg.org//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 />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [https://html.spec.whatwg.org//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 />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<br />
There is; it is now allowed to use `<div>` in `<dl>`. See https://github.com/whatwg/html/issues/1937<br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make custom HTML elements? ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=What_you_can_do&diff=10184What you can do2017-08-24T08:30:04Z<p>Zcorpan: Brush up this page to not be so out of date</p>
<hr />
<div>So you want to take part? You can!<br />
* Review [http://whatwg.org/specs/ the specifications] and [http://whatwg.org/mailing-list#specs send comments]! (See below for details.)<br />
* Write articles for our [http://blog.whatwg.org/ blog].<br />
* Write [[Authoring|tutorials]] for new web developers.<br />
* Maintain the document explaining the [[rationale]] of the decisions behind the spec. (See below for details.)<br />
* Write [[test cases]].<br />
* Write cool demos.<br />
* [[:Category:Implementations|Implement HTML]]!<br />
* Edit one of the many [[Specs todo|companion specifications]] that are lacking editors.<br />
<br />
== Sending feedback ==<br />
The most useful thing would be going through the spec and finding bits that don't make sense. <br />
<br />
https://html.spec.whatwg.org/multipage/<br />
<br />
You can use the link at the bottom (it says "File an issue about the selected text") to submit review comments on the spec. The best review comments are those along the lines of questions you couldn't find the answer to. For example, say you wanted to find out what elements you could put in a &lt;p> element, and you couldn't work it out. Then you would file a bug "I couldn't find the answer to the question 'What elements are allowed inside &lt;p> elements'.".<br />
<br />
'''See also [[Reviewing]].'''<br />
<br />
== A rationale document ==<br />
<br />
It basically would consist of watching the [GitHub repositories](https://github.com/whatwg) that are of interest,<br />
asking questions on [[IRC]], and then writing documentation to<br />
explain the thinking behind different parts of the spec on the [[rationale]] page.<br />
<br />
It could be as little work or as much work as you would want it to be. One<br />
could easily imagine this becoming a group effort.<br />
<br />
= How you can improve HTML =<br />
<br />
''This text originated from an article Hixie wrote.''<br />
<br />
Are you trying to do something on the Web that you find you can't do because HTML simply doesn't have a way to do it?<br />
<br />
With your help, we can improve HTML, add a feature to address your problem, and in a few years you'll finally be able to do it!<br />
<br />
Here's how:<br />
<br />
First, write a brief user-centric description of the problem. What are you trying to do? This should be a high-level description. One way to see if you're describing it at a high<br />
enough level is to consider whether your description makes as much sense for a Web developer as it does for, say, a mobile phone native app developer. So if your<br />
description talks about HTML elements or JavaScript or HTTP headers, then it's probably too low level. If it talks about what a user sees, how a user interacts<br />
with a computer or device, or how a user uses a computer or device to create some sort of content or effect some sort of change, then you're on the right path.<br />
If you hear people referring to "use cases", it is to this problem description that they refer. Some of the most useful information you can give is examples of what<br />
people are currently doing to work around the problem (e.g. they're writing native apps instead of Web pages, or they're using Flash or other extensions, etc).<br />
<br />
In particular, your description should not be a solution. Don't propose new elements or attributes, new APIs, new semantics, new features. The time for<br />
discussions of solutions is later.<br />
<br />
Next, do one or more of the following with this description:<br />
<br />
* Discuss the topic on our [[IRC]] channel (#whatwg on Freenode) to see if you've missed anything obvious<br />
* Post it as an issue at http://whatwg.org/newbug<br />
<br />
Participate in any resulting discussions. Post a link to your issue to your own blog or to other social media sites to<br />
encourage others to participate. For best results, I recommend that you avoid creating new places for the discussion to occur (e.g. new mailing lists, wiki<br />
pages, or working groups). Keeping the discussions in existing places ensures that experience participants will see your discussions and will be able to<br />
lend you their experience. The most important part of these discussions is clarifying how common the problem is, what related problems other people have<br />
that could maybe be addressed at the same time, and what work-arounds exist to avoid the problem.<br />
<br />
Ideally, some browser vendors will at this point start commenting on the problem, hopefully saying that they agree that it's a problem. Getting browser vendors <br />
to believe there's a problem is the second best thing that you can do to ensure your problems gets solved. (The best thing that can happen is for browser vendors<br />
to implement a solution. See notes below.) Once you have browser vendors buying-in to the problem's importance, you can start talking about possible solutions.<br />
(You don't have to, though, and there's no guarantee that the solutions you propose will be adopted rather than some other ones.)<br />
<br />
When it comes to updating the standard, see https://whatwg.org/working-mode for what the process is. It boils down to writing a pull request for the standard and<br />
writing test cases, and getting support from implementers.<br />
<br />
You may ask why browser vendors have a prominent role in this process. The answer is simple. The specification is not magical; it cannot force browser vendors to<br />
do anything they don't want to do. If I write something in the spec and they don't implement it, there's nothing we can do: the feature doesn't really exist,<br />
it's just fiction, and we've all wasted our time. To avoid wasting my time, I try to work with the browser vendors to make sure that what I specify is something<br />
they're willing to implement. (It doesn't always work out that way, but then after a while I update the spec to match what they did do, or didn't do, e.g.<br />
removing things that nobody has implemented.)<br />
<br />
If you want to participate in the process in ways other than reporting problems you find with the Web, there are various things you can do: participate in<br />
discussions on GitHub; chat with us on IRC (#whatwg on Freenode); write test cases; write tutorials; review the spec...<br />
The best place to start is to join us on IRC and ask what you can do.<br />
<br />
We also have a FAQ: https://whatwg.org/faq</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Code_of_Conduct&diff=10169Code of Conduct2017-06-14T11:27:17Z<p>Zcorpan: Move Code of Conduct page to whatwg.org/code-of-conduct</p>
<hr />
<div>{{Moved|https://whatwg.org/code-of-conduct}}</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Template:Moved&diff=10168Template:Moved2017-06-14T11:24:55Z<p>Zcorpan: Created page with "<div style="border: 0.25em solid orange; background: #ffa; padding: 1em; font-size: larger;">This page has moved to {{{1}}}</div>"</p>
<hr />
<div><div style="border: 0.25em solid orange; background: #ffa; padding: 1em; font-size: larger;">This page has moved to {{{1}}}</div></div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MediaWiki:Sidebar&diff=10167MediaWiki:Sidebar2017-06-14T09:52:59Z<p>Zcorpan: </p>
<hr />
<div>* navigation<br />
** mainpage|mainpage<br />
** Special:PopularPages|popularpages<br />
** randompage-url|randompage<br />
** recentchanges-url|recentchanges<br />
* WHATWG<br />
** http://spec.whatwg.org/|Standards<br />
** FAQ|FAQ<br />
** IRC|IRC<br />
** https://whatwg.org/code-of-conduct|Code of Conduct<br />
** GitHub|GitHub<br />
** What you can do|What you can do<br />
** Specs todo|To-do list<br />
** http://www.whatwg.org/mailing-list|Mailing lists<br />
* Registries<br />
** MetaExtensions|<meta name><br />
** PragmaExtensions|<meta http-equiv><br />
** CanvasContexts|canvas.getContext()<br />
** http://microformats.org/wiki/existing-rel-values|rel=""</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10166FAQ2017-06-14T09:50:35Z<p>Zcorpan: /* Is there a Code of Conduct? */</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 />
=== How do you spell and pronounce WHATWG? ===<br />
<br />
It is spelled WHATWG, all uppercase, no spaces. It has various pronunciations: what-wee-gee, what-wig, what-double-you-gee.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/multipage/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://spec.whatwg.org/ a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [https://whatwg.org/code-of-conduct Code of Conduct]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list/GitHub issue discussions? ===<br />
<br />
On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://spec.whatwg.org/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
For references to stable copies of the specifications, some WHATWG specifications follows a process by which each change to the specification (embodied in a commit) triggers the publication of a frozen snapshot of the said specification.<br />
<br />
These snapshots are published as historical references. The WHATWG intends to keep these frozen snapshots available at their published URL permanently.<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://spec.whatwg.org/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 use [https://html.spec.whatwg.org/multipage/scripting.html#custom-elements custom elements].<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 was thought to be a styling problem and should be fixed in CSS. There was no reason to add a grouping element to HTML, as the semantics are already unambiguous without an additional element.<br />
<br />
In October 2016 it became clear that CSS would not fix this in the foreseeable future, HTML was changed to allow &lt;div> as a grouping element in &lt;dl>. See https://github.com/whatwg/html/issues/1937 and https://github.com/whatwg/html/pull/1945<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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)<br />
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=10108MicrosyntaxDescriptions2016-11-14T10:34:29Z<p>Zcorpan: Fix more links</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [https://html.spec.whatwg.org/ WHATWG version of HTML] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [https://html.spec.whatwg.org/multipage/semantics.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki]. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==content-security-policy==<br />
A valid [https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy#Writing_a_policy Content Security Policy].<br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [https://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
== integrity-metadata ==<br />
A whitespace-separated list of values, where each value is consists of one of <code>sha256</code> or <code>sha384</code> or <code>sha512</code>, followed by a hyphen (<code>-</code>), followed by a base64-encoded cryptographic hash.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>. Common non-alphanumeric characters other than <code>! $ & ' ( ) * + - . / : ; = ? @ _ ~</code> generally must be [https://en.wikipedia.org/wiki/Percent-encoding percent-encoded]. For example, the pipe character (<code>|</code>) must be encoded as <code>%7C</code>.<br />
<br />
==language==<br />
An [https://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [https://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [https://html.spec.whatwg.org/multipage/semantics.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a optional <strong>media type</strong> and zero or more expressions that check for the conditions of particular <strong>media features</strong>. A media type is one of the following: <code>all</code>, <code>print</code>, <code>screen</code>, or <code>speech</code>. The following media types are deprecated: <code>braille</code>, <code>embossed</code>, <code>handheld</code>, <code>projection</code>, <code>tty</code>, and <code>tv</code>. For information about valid media features and about the exact syntax of media queries, see the [https://drafts.csswg.org/mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [https://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==sandbox-allow-list==<br />
An unordered set of unique space-separated keywords; the allowed keywords are <code>allow-forms</code>, <code>allow-modals</code>, <code>allow-pointer-lock</code>, <code>allow-popups</code>, <code>allow-popups-to-escape-sandbox</code>, <code>allow-same-origin</code>,<code> allow-scripts</code>, and <code>allow-top-navigation</code>.<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [https://html.spec.whatwg.org/multipage/scripting.html#restrictions-for-contents-of-script-elements Restrictions for contents of script elements].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [https://html.spec.whatwg.org/multipage/scripting.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but <strong>commas must not be used to separate commands</strong>, though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-month-string month], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-date-string date], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-yearless-date-string yearless date], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-time-string time], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-local-date-and-time-string local date and time], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-time-zone-offset-string time-zone offset], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-global-date-and-time-string global date and time], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-week-string week], [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-non-negative-integer non-negative integer], or [https://html.spec.whatwg.org/multipage/infrastructure.html#valid-duration-string duration]. For more information and examples, see the [https://html.spec.whatwg.org/multipage/semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=10107MicrosyntaxDescriptions2016-11-14T10:19:49Z<p>Zcorpan: /* a-rel */ Fix link</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [https://html.spec.whatwg.org/ WHATWG version of HTML] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [https://html.spec.whatwg.org/multipage/semantics.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki]. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==content-security-policy==<br />
A valid [https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy#Writing_a_policy Content Security Policy].<br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [https://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
== integrity-metadata ==<br />
A whitespace-separated list of values, where each value is consists of one of <code>sha256</code> or <code>sha384</code> or <code>sha512</code>, followed by a hyphen (<code>-</code>), followed by a base64-encoded cryptographic hash.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>. Common non-alphanumeric characters other than <code>! $ & ' ( ) * + - . / : ; = ? @ _ ~</code> generally must be [https://en.wikipedia.org/wiki/Percent-encoding percent-encoded]. For example, the pipe character (<code>|</code>) must be encoded as <code>%7C</code>.<br />
<br />
==language==<br />
An [https://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [https://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a optional <strong>media type</strong> and zero or more expressions that check for the conditions of particular <strong>media features</strong>. A media type is one of the following: <code>all</code>, <code>print</code>, <code>screen</code>, or <code>speech</code>. The following media types are deprecated: <code>braille</code>, <code>embossed</code>, <code>handheld</code>, <code>projection</code>, <code>tty</code>, and <code>tv</code>. For information about valid media features and about the exact syntax of media queries, see the [https://drafts.csswg.org/mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [https://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==sandbox-allow-list==<br />
An unordered set of unique space-separated keywords; the allowed keywords are <code>allow-forms</code>, <code>allow-modals</code>, <code>allow-pointer-lock</code>, <code>allow-popups</code>, <code>allow-popups-to-escape-sandbox</code>, <code>allow-same-origin</code>,<code> allow-scripts</code>, and <code>allow-top-navigation</code>.<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#restrictions-for-contents-of-script-elements Restrictions for contents of script elements].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but <strong>commas must not be used to separate commands</strong>, though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-month-string month], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-week-string week], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [https://html.spec.whatwg.org/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10103FAQ2016-11-02T07:33:59Z<p>Zcorpan: /* HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! */</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [[Code of Conduct]]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list/GitHub issue discussions? ===<br />
<br />
On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
For references to stable copies of the specifications, some WHATWG specifications follows a process by which each change to the specification (embodied in a commit) triggers the publication of a frozen snapshot of the said specification.<br />
<br />
These snapshots are published as historical references. The WHATWG intends to keep these frozen snapshots available at their published URL permanently.<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 use [https://html.spec.whatwg.org/multipage/scripting.html#custom-elements custom elements].<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 was thought to be a styling problem and should be fixed in CSS. There was no reason to add a grouping element to HTML, as the semantics are already unambiguous without an additional element.<br />
<br />
In October 2016 it became clear that CSS would not fix this in the foreseeable future, HTML was changed to allow &lt;div> as a grouping element in &lt;dl>. See https://github.com/whatwg/html/issues/1937 and https://github.com/whatwg/html/pull/1945<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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)<br />
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10076FAQ2016-06-22T14:04:30Z<p>Zcorpan: /* HTML should support a way for anyone to invent new elements! */ Mention custom elements</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [[Code of Conduct]]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list/GitHub issue discussions? ===<br />
<br />
On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 use [https://html.spec.whatwg.org/multipage/scripting.html#custom-elements custom elements].<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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)<br />
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10075FAQ2016-06-22T13:58:26Z<p>Zcorpan: /* What is the history of HTML? */ Fix link to HTML spec's history section</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [[Code of Conduct]]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list/GitHub issue discussions? ===<br />
<br />
On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)<br />
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10074FAQ2016-06-22T13:57:00Z<p>Zcorpan: /* What is the history of HTML? */ Link to https://platform.html5.org/history/</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [[Code of Conduct]]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list/GitHub issue discussions? ===<br />
<br />
On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<br />
<br />
=== What is the history of HTML? ===<br />
<br />
Here are some documents that detail the history of HTML:<br />
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])<br />
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)<br />
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10073FAQ2016-06-22T13:50:22Z<p>Zcorpan: /* What happens with WHATWG mailing list discussions? */ Update for discussions at GitHub</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [[Code of Conduct]]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list/GitHub issue discussions? ===<br />
<br />
On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<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 />
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=10072FAQ2016-06-22T13:45:35Z<p>Zcorpan: /* {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? */ Update adding features to reflect GitHub workflow and update the testing situation</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Is there a Code of Conduct? ===<br />
<br />
Yes, see [[Code of Conduct]]. Please read it and respect it.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].<br />
<br />
Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.<br />
<br />
=== What happens with WHATWG mailing list discussions? ===<br />
<br />
On the WHATWG list, the burden is an the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).<br />
<br />
The purpose of debate on the WHATWG list therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the<br />
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of<br />
useful progress, since that isn't input that can help the decision-making process later.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.<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 editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.<br />
<br />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].<br />
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].<br />
<br />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
=== What is the process for translating WHATWG standards? ===<br />
<br />
Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!<br />
<br />
In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.<br />
<br />
Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.<br />
<br />
Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/htmlstandard @htmlstandard]<br />
<br />
* The [https://github.com/whatwg/html/commits/master GitHub commits log]<br />
<br />
* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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 />
=== 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<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 />
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Code_of_Conduct&diff=10040Code of Conduct2016-02-24T14:02:04Z<p>Zcorpan: Remove "vague critisism" per http://logs.glob.uno/?c=freenode%23whatwg&s=24+Feb+2016&e=24+Feb+2016#c986106</p>
<hr />
<div>==Conduct==<br />
<br />
Contact: Ian Hickson (Hixie on [[IRC]], [mailto:ian@hixie.ch ian@hixie.ch] via email) or a member of the community you feel you can trust.<br />
<br />
* We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.<br />
* Please be kind and courteous. There's no need to be mean or rude.<br />
* Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.<br />
* You shall not insult, demean or harass anyone. We interpret the term "harassment" as including the definition in the [http://citizencodeofconduct.org/ Citizen Code of Conduct]; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups.<br />
* This includes private harassment. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please let the contact know immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back.<br />
* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behaviour is not welcome.<br />
* Avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.<br />
<br />
==Moderation==<br />
<br />
These are the policies for upholding the WHATWG Code of Conduct:<br />
<br />
* Remarks that violate the WHATWG Code of Conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed on IRC, but never targeting another user, and never in a hateful manner.)<br />
* Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.<br />
* If you think an action of a moderator was unjustified, please take it up with that moderator, or with a different moderator, in private. Complaints about bans in-channel are not allowed.<br />
* Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others.<br />
<br />
In the WHATWG community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely.<br />
<br />
And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow contributors comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about standards and everything that involves. You will find that people will be eager to assume good intent and forgive as long as you earn their trust.<br />
<br />
Adapted from [https://www.rust-lang.org/conduct.html The Rust Code of Conduct].</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Testsuite&diff=10021Testsuite2016-01-19T07:45:04Z<p>Zcorpan: /* Old lists of tests that maybe have not been ported to web platform tests? */</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 />
* [http://dev.w3.org/2006/webapi/WindowTestSuite/ Window test suite]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=IRC&diff=10003IRC2015-10-20T11:55:51Z<p>Zcorpan: Remove mention of Subversion</p>
<hr />
<div>The Freenode IRC network has a channel called [irc://irc.freenode.net/whatwg #whatwg] where some of the more active WHATWG community members hang out. Feel free to join us!<br />
<br />
If you want to run a bot, let us know. If they are useful, e.g. providing logging facilities, then they are more than welcome.<br />
<br />
== Logs ==<br />
<br />
Logs for the #whatwg channel can be found here:<br />
<br />
* http://krijnhoetmer.nl/irc-logs/whatwg/<br />
* http://logbot.glob.com.au/?c=freenode%23whatwg&s=today<br />
<br />
== People ==<br />
<br />
A list of regulars, sorted by nick, and their normal timezones (winter/summer).<br />
<br />
* {{irc user|Adactio|adactio|+0000/+0100}}<br />
* {{irc user|Annevk|annevk|.../...}}<br />
* {{irc user|Dglazkov|dglazkov|.../...}}<br />
* {{irc user|Domenic|Domenic|-0500/-0400}}<br />
* {{irc user|GPHemsley|GPHemsley|-0500/-0400}}<br />
* {{irc user|Hixie|Hixie|-0800/-0700}}<br />
* {{irc user|EdwardOConnor|hober|-0800/-0700}}<br />
* {{irc user|Jgraham|jgraham|.../...}}<br />
* {{irc user|kennyluck|kennyluck|+0800/+0800}}<br />
* {{irc user|Mathias|matjas|.../...}}<br />
* {{irc user|Ms2ger|Ms2ger|.../...}}<br />
* {{irc user|Mjs|othermaciej|-0800/-0700}}<br />
* {{irc user|ShaneHudson|ShaneHudson|+0000/+0100}}<br />
* {{irc user|Xanthir|tabatkins|-0800/-0700}}<br />
* {{irc user|Tantek|tantek|-0800/-0700}}<br />
* {{irc user|Yuhong|yuhong|-0800/-0700}}<br />
* {{irc user|Wilto|Wilto|.../...}}<br />
* {{irc user|Zcorpan|zcorpan|.../...}}</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Rationale&diff=9899Rationale2015-04-02T07:16:27Z<p>Zcorpan: Fix links to the HTML spec</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 />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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 />
=== It isn&rsquo;t just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won&rsquo;t use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref><br />
<br />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>https://html.spec.whatwg.org//multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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>https://html.spec.whatwg.org//#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><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 [https://html.spec.whatwg.org//multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [https://html.spec.whatwg.org//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 />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [https://html.spec.whatwg.org//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 />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make custom HTML elements? ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=Rationale&diff=9898Rationale2015-04-02T06:59:53Z<p>Zcorpan: /* Already-implemented features */</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 />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
11. Rationale of scoped attribute (see for example http://html5doctor.com/the-scoped-attribute/)<br />
--><br />
This rationale document is supplemental to the WHATWG [http://www.whatwg.org/specs/web-apps/current-work/multipage/ HTML Living Standard] specification. It is a work-in-progress.<br />
<br />
== General Rationale ==<br />
<br />
=== In overall terms, what determines what&rsquo;s in the spec? ===<br />
==== Already-implemented features ====<br />
The contents of the spec is largely determined by what&rsquo;s already been implemented in browsers. Historically, vendors competed with one another by implementing features without regard to any specification. It&rsquo;s a relatively recent phenomenon that vendors compete by their conformance to the spec.<br />
<br />
One of the main purposes of the spec is to describe reality. Thus, the spec must include all already-implemented features regardless of what the spec editor, members, and contributors think. A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.<br />
<br />
==== Member and contributor feedback ====<br />
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.<br />
<br />
=== One vendor, one veto === <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&mdash;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&rsquo;t a power that we grant browsers; it&rsquo;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 />
=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===<br />
Because to get something adopted in a browser, you need to do the following (not always in this order):<br />
<ol><br />
<li>Have someone design the feature.<br />
<li>Have someone write a specification for it.<br />
<li>Have some people write tests for it.<br />
<li>Have one browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have another browser implement it.<br />
<li>Have people document it.<br />
</ol><br />
This is in contrast to &ldquo;everything else,&rdquo; which just needs:<br />
<ol><br />
<li>Someone to implement it.<br />
</ol><br />
<br />
=== Using elements where scripts &ldquo;work&rdquo; ===<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 />
=== It isn&rsquo;t just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won&rsquo;t use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== Experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
=== Versioning the spec ===<br />
Most authors don&rsquo;t care about whether or not an implementation supports an entire, full specification; they just want to know &ldquo;Can I use this feature in this browser?&rdquo; So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref><br />
<br />
<!--=== HTML5 the spec vs HTML5 the buzzword ===<br />
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23299.html<br />
--><br />
=== Modifying existing semantics ===<br />
Some elements have different semantics than what HTML users would expect. Semantic markup isn&rsquo;t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref><br />
<br />
=== What is the purpose of defining elements semantically? ===<br />
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#elements</ref><br />
<br />
Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys <em>meaning</em>, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.<br />
<br />
The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.<br />
<br />
Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for &ldquo;jump to next heading&rdquo; or &ldquo;jump to previous heading&rdquo;. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.<br />
<br />
Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).<br />
<br />
This example has focused on headings, but the same principle applies to all of the semantics in HTML.<br />
<br />
=== Why is it important to stick to the semantics as defined in the spec? ===<br />
Not adhering to the spec&rsquo;s semantics prevents software that assumes and relies on said semantics from correctly processing the document.<br />
<br />
For example, the following document is non-conforming, despite being syntactically correct:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;table&gt;<br />
&lt;tr&gt; &lt;td&gt; My favourite animal is the cat. &lt;/td&gt; &lt;/tr&gt;<br />
&lt;tr&gt;<br />
&lt;td&gt;<br />
&lt;a href="http://example.org/~ernest/"&gt;&lt;cite&gt;Ernest&lt;/cite&gt;&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/td&gt;<br />
&lt;/tr&gt;<br />
&lt;/table&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
&hellip;because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract &ldquo;Ernest&rdquo; as the title of a work, even though it&rsquo;s actually a person&rsquo;s name, not a title.<br />
<br />
A corrected version of this document might be:<br />
<br />
<pre>&lt;!DOCTYPE HTML&gt;<br />
&lt;html lang="en-GB"&gt;<br />
&lt;head&gt; &lt;title&gt; Demonstration &lt;/title&gt; &lt;/head&gt;<br />
&lt;body&gt;<br />
&lt;blockquote&gt;<br />
&lt;p&gt; My favourite animal is the cat. &lt;/p&gt;<br />
&lt;/blockquote&gt;<br />
&lt;p&gt;<br />
—&lt;a href="http://example.org/~ernest/"&gt;Ernest&lt;/a&gt;,<br />
in an essay from 1992<br />
&lt;/p&gt;<br />
&lt;/body&gt;<br />
&lt;/html&gt;</pre><br />
<br />
== Specific Elements ==<br />
=== The DOCTYPE (Document Type Declaration) ===<br />
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.<br />
<br />
=== Document metadata ===<br />
==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====<br />
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====<br />
User agents may want to use the Web application name in UI in preference to the page&rsquo;s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-meta-element</ref><br />
<br />
==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====<br />
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.<br />
<br />
=== Sections ===<br />
==== <code>hgroup</code> and other heading elements ====<br />
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.<br />
<br />
==== <code>header</code> and <code>footer</code> ====<br />
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote><br />
<br />
=== Grouping content ===<br />
==== The <code>blockquote</code> element ====<br />
===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====<br />
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.<br />
<br />
=== Text-level semantics ===<br />
<br />
=== Embedded content ===<br />
<br />
==== On the status of <code>image</code> ====<br />
<br />
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. 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 />
==== The <code>img</code> element and alternate (<code>alt</code>) text ====<br />
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> 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 />
=== Forms ===<br />
<br />
==== <code>textarea</code> ====<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><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
==== <code>meter</code> and <code>progress</code> (are not the same thing) ====<br />
<br />
<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> 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 <code>progress</code> 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). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== Interactive elements ===<br />
<br />
==== <code>details</code> element ====<br />
The <code>details</code> 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, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, 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 />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><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 />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Rejected proposals ==<br />
=== A &ldquo;<code>&lt;comment&gt;</code>&rdquo; element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===<br />
<br />
==== Why isn&rsquo;t there an element for user comments? (e.g., <code>&lt;comment&gt;</code>) ====<br />
There is: <code>article</code>.<br />
<br />
==== But comments are not articles ====<br />
<br />
Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element&rsquo;s semantics, and the element name &ldquo;article&rdquo; isn&rsquo;t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term &ldquo;article&rdquo; is defined broadly in HTML to include any complete or self-contained composition. This includes:<br />
* forum posts<br />
* newspaper articles<br />
* magazine articles<br />
* books<br />
* blog posts<br />
* comment on a forum post<br />
* comment on a newspaper article<br />
* comment on a magazine article<br />
* comment on a blog post<br />
* an embeddable interactive widget<br />
* a post with a photograph on a social network<br />
* a comment on a photograph on a social network<br />
* a specification<br />
* an e-mail<br />
* a reply to an e-mail<br />
Comments are considered articles&mdash;in the HTML sense&mdash;because they are <em>complete</em> compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously <em>related</em> to what they are commenting on, for example, &ldquo;is in response to.&rdquo; This relationship is demonstrated by nesting the comment article inside the article it&rsquo;s responding to).<br />
<br />
==== Surely the comment &ldquo;LOL&rdquo; is not an article? ====<br />
According to the HTML spec, it is. It&rsquo;s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it&rsquo;s commenting on. It&rsquo;s that separateness that makes it an article (in the HTML sense).<br />
<br />
==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====<br />
There&rsquo;s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.<br />
<br />
==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====<br />
No evidence has been put forth to suggest that this is a significant authorship issue.<br />
<br />
==== Why should the spec suggest any one specific method for marking up comments? ====<br />
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:<br />
* programmatically find comments in HTML<br />
* write interoperable style sheets for comments, using the selector <code>article &gt; article</code><br />
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)<br />
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref><br />
<br />
Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.<br />
<br />
=== Why isn&rsquo;t there a dedicated element for advertisements? (e.g., <code>&lt;ad&gt;</code>, or <code>&lt;advert&gt;</code>, or <code>&lt;banner&gt;</code>, or whatever) ===<br />
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:<br />
<br />
<pre>> How should advertisements be marked up?<br />
<br />
It's worth considering that an <advert> element (or <banner> or whatever <br />
you decide to call it) would just cause style rules like advert <br />
{display:none;} to become widespread (e.g. by integration into Adblock <br />
and equivalent). Therefore I can't see this type of markup being used by <br />
most advertisers.</pre><br />
<br />
<pre>> I've joined this list to put forward the argument that there should be<br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
><br />
> These are both extremely common features of many web pages; I would say<br />
> at least as common as "article".<br />
<br />
For <ad>, there's the obvious potential usage of setting<br />
<br />
ad { display: none !important }<br />
<br />
in a user style sheet. I don't think this possibility would make <ad><br />
popular among authors.</pre><br />
<br />
Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:<br />
<br />
<pre>> I've joined this list to put forward the argument that there should be <br />
> elements for <comment> and <ad> included in the HTML5 spec.<br />
<br />
For advertisments, I do not think it makes sense to add an element. In <br />
practice, it would likely not end up being used, since doing so would make <br />
it too easy to hide advertisments.<br />
<br />
However, the <aside> element is a close fit for the semantic, so I would <br />
recommend using that.</pre><br />
<br />
=== Why isn&rsquo;t there a grouping-type element for description lists to represent individual name-value groups (e.g., a &ldquo;<code>dli</code>&rdquo; element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===<br />
<pre>On Sun, 30 Dec 2012, Brian Tremblay wrote:<br />
><br />
> I'm using <dl> markup for a restaurant menu, and have added product<br />
> microdata markup from schema.org. Because items in a <dl> are defined<br />
> implicitly -- <dt> element(s) followed by <dd> element(s) -- there's no<br />
> easy way to scope them individually. What I'm left doing is adding 2 id<br />
> attributes for each menu item, and using itemref:<br />
><br />
> http://tsmchughs.com/test/dessert<br />
<br />
That's one way to do it, yeah.<br />
<br />
<br />
> If we had a <dli> element, to scope each item in a description list, the<br />
> markup needed to add microdata (or microformats) would be much simpler.<br />
><br />
> [...]<br />
><br />
> Therefore, I think we need a <dli> element. This has come up in the<br />
> past. If I understand correctly, the editor has declined, saying that<br />
> the need for <dli> is only to make styling easier, so the problem should<br />
> be solved in css. But I think the problem here is not styling, it's<br />
> creating natural, discrete items in a description list, which might be<br />
> used for styling, or for microdata, or perhaps for other reasons which I<br />
> haven't thought of. Without <dli>, use of <dl> becomes much harder to<br />
> use even though it may be the best markup choice.<br />
<br />
You're right that this is a much better reason for adding a <dl> grouping<br />
element.<br />
<br />
Unfortunately, lack of use cases isn't the only reason we haven't added<br />
it. One of the other reasons is that it would require parser changes. For<br />
example, take this:<br />
<br />
<dl><br />
<di><br />
<dt>a<br />
<dd>b<br />
</di><br />
<di><br />
<dt>c<br />
<dd>d<br />
</di><br />
</dl><br />
<br />
This looks like it should work, but right now it gets parsed as:<br />
<br />
<dl><br />
<di><br />
<dt>a</dt><br />
<dd>b<br />
<di><br />
<dt>c</dt><br />
<dd>d</dd><br />
</di><br />
</dd><br />
</di><br />
</dl><br />
<br />
(Another reason is that it makes the processing model for <dl> more<br />
complicated for tools that want to process groups of items in <dl>s.)<br />
<br />
<br />
Still, you make a very good point, that for microdata, the lack of<br />
grouping here is a more serious issue than styling-system limitations.<br />
<br />
I guess it comes down to a question of how common microdata on <dl> groups<br />
is, vs how painful changing the parser and legacy tools would be. It's<br />
probably a close call (not much usage, but not a huge amount of pain).</pre><br />
<br />
=== Why isn&rsquo;t there a <code>sandbox</code> attribute on the <code>html</code> element? ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done 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 if 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 />
=== Why aren&rsquo;t authors allowed to make custom HTML elements? ===<br />
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
<br />
== Other Pages ==<br />
<br />
* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<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>Zcorpanhttps://wiki.whatwg.org/index.php?title=FAQ&diff=9897FAQ2015-04-02T06:54:48Z<p>Zcorpan: Remove <time> and minlength="" sections, seem no longer relevant</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 Web standards, specifically:<br />
<br />
* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.<br />
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers<br />
* [https://url.spec.whatwg.org/ URLs], including an API for URLs<br />
<br />
...and [https://whatwg.org/specs a number of other specs].<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 />
[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.<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 [https://whatwg.org/mailing-list mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
=== Harassment ===<br />
<br />
The WHATWG has no tolerance for any kind of harassment or abuse. All participants are expected to behave professionally and respectfully at all times. Please immediately report any bad behaviour by anyone on the WHATWG mailing lists, specs, IRC, wiki, or other fora, whether towards you or towards anyone else, including people not actively participating in the WHATWG community, to Ian Hickson, email ian@hixie.ch, or someone else from the community you feel you can trust.<br />
<br />
If you're not sure what consists harassment, the following codes of conduct from other communities are a good guide:<br />
<br />
* http://www.rust-lang.org/conduct<br />
* http://www.w3.org/Consortium/cepc/<br />
* http://www.centerforinquiry.net/pages/policy_on_harassment_at_conferences<br />
<br />
If you're still not sure, refrain from whatever behaviour you're not sure about.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send email to [https://whatwg.org/mailing-list#specs the mailing list] or [https://whatwg.org/newbug file bugs].<br />
<br />
Each specification has a separate editor, who is responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the relevant 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 />
For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.<br />
<br />
This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no e-mails at all. Discussions on that list are summarised and described on the public list, to make sure everyone is kept up to date.<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 [https://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [https://whatwg.org/specs/ relevant spec]; for HTML, that's ian@hixie.ch. All feedback on the HTML spec 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 emailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (Hixie on Freenode for HTML). Requests for priority feedback handling are handled confidentially so other implementers 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 />
=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}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. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)<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 />
=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}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 />
<br />
# Forget about the particular solution you have in mind! Solution time is later!<br />
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html<br />
# Get more people involved. Send your use cases and their requirements to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.<br />
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)<br />
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, again to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!<br />
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).<br />
# Ask the spec's editor to put that solution in the spec. Likely your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.<br />
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.<br />
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.<br />
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).<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 can even start before implementations start being written to the spec. 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 />
=== Should I send new proposed text when I have a suggestion? ===<br />
<br />
Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.<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 />
=== Does that mean the specifications can change at any time? ===<br />
<br />
The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are 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. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What's the patent story for WHATWG standards? ===<br />
<br />
The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.<br />
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.<br />
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]<br />
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It 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 are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
=== What is HTML5? ===<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 [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [https://validator.whatwg.org/ validator].<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.<br />
<br />
(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" 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 />
=== 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; indeed it makes it significantly easier.<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! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of 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: [https://twitter.com/WHATWG @WHATWG] (non-editorial changes only)<br />
<br />
* You may use the online [https://html5.org/tools/web-apps-tracker HTML Standard Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a [https://whatwg.org/mailing-list#commits commit-watchers mailing list] that is notified of every edit.<br />
<br />
* The specification is available in the [https://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.<br />
<br />
The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.<br />
<br />
The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [https://developers.whatwg.org/ developers.whatwg.org]<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.info/<br />
* http://caniuse.com/<br />
* http://html5doctor.com/<br />
* https://developer.mozilla.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, then remove them!<br />
<br />
=== When will HTML5 be finished? ===<br />
<br />
The WHATWG is now using a Living Standard development model, 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, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 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 the WHATWG is aiming for. We now look for 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 started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.<br />
<br />
HTML 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 is the DOCTYPE for modern HTML documents? === <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 [https://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 />
=== Where's the harm in adding— ===<br />
<br />
Every feature we add to the Web platform has a cost:<br />
<br />
* Implementation: someone has to write code for it in each browser<br />
* Testing: someone has to write the tests to check the features is working<br />
* QA: someone has to regularly run the tests to make sure the feature doesn't regress<br />
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features<br />
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so<br />
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature<br />
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.<br />
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain<br />
* Spec writing: someone has to write the spec for the feature and ensure it's maintained<br />
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc<br />
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)<br />
<br />
== WHATWG and the W3C HTML WG ==<br />
<br />
=== Are there plans to merge the groups? ===<br />
<br />
No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.<br />
<br />
On the WHATWG side, Hixie, the editor, reads the feedback sent to both groups and takes all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, Hixie does not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)<br />
<br />
=== Which group has authority in the event of a dispute? ===<br />
<br />
The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.<br />
<br />
=== Isn't it bad that the specs have forked? ===<br />
<br />
Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.<br />
<br />
The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.<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 />
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]<br />
<br />
== Using HTML ==<br />
<br />
=== Do you have any hints on how to use &lt;section> and &lt;article> and so on? ===<br />
<br />
Some hopefully helpful hints:<br />
<br />
* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>, and if it's not in the table of contents and doesn't have an &lt;h1>, it should probably not be a &lt;section>/&lt;article>/&lt;aside>/&lt;nav>.<br />
* You can still use &lt;div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.<br />
* Generally, &lt;section>s should start with an &lt;h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an &lt;h1> would be inappropriate, you probably want &lt;div> rather than &lt;section>.<br />
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using &lt;article>, and each comment could be big enough that it has separate &lt;section>s, and so on.<br />
<br />
== Other specifications ==<br />
<br />
=== What ever happened to...? ===<br />
<br />
The Web Forms 2.0 specification was folded into what is now the HTML specification.<br />
<br />
The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.<br />
<br />
The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.<br />
<br />
== Mailing List ==<br />
<br />
=== +1 ===<br />
<br />
Please note that content-free agreement (such as +1s) have no effect on <br />
the WHATWG list and are therefore discouraged. Editors of specs discussed <br />
in the WHATWG only consider the quality of the arguments presented, and <br />
not the volume of agreement.<br />
<br />
You should therefore only post to the list if you have a substantive new point<br />
to make, for example if you have seen a flaw in an argument presented so far,<br />
or have a new idea to contribute, or have some information that has not yet<br />
been brought to the table.<br />
<br />
=== Making Outlook quote email messages properly ===<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 />
<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 emails 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 email 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 email backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post emails?<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 email.<br />
<br />
Ian wrote:<br />
> Is this a good way to write email?<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.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=9895MicrosyntaxDescriptions2015-04-01T07:52:40Z<p>Zcorpan: /* svg-pathdata */ markup typo</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [https://html.spec.whatwg.org/ WHATWG version of HTML] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki], or must be an absolute URL. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [https://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>.<br />
<br />
==language==<br />
An [https://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [https://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a <strong>media type</strong> and zero or more expressions that check for the conditions of particular <strong>media features</strong>. A media type is one of the following: <code>all</code>, <code>print</code>, <code>screen</code>, or <code>speech</code>. The following media types are deprecated: <code>braille</code>, <code>embossed</code>, <code>handheld</code>, <code>projection</code>, <code>tty</code>, and <code>tv</code>. For information about valid media features and about the exact syntax of media queries, see the [https://drafts.csswg.org/mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [https://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#restrictions-for-contents-of-script-elements Restrictions for contents of script elements].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but <strong>commas must not be used to separate commands</strong>, though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-month-string month], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-week-string week], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [https://html.spec.whatwg.org/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=9894MicrosyntaxDescriptions2015-04-01T07:51:59Z<p>Zcorpan: Markup typo</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [https://html.spec.whatwg.org/ WHATWG version of HTML] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki], or must be an absolute URL. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [https://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>.<br />
<br />
==language==<br />
An [https://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [https://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a <strong>media type</strong> and zero or more expressions that check for the conditions of particular <strong>media features</strong>. A media type is one of the following: <code>all</code>, <code>print</code>, <code>screen</code>, or <code>speech</code>. The following media types are deprecated: <code>braille</code>, <code>embossed</code>, <code>handheld</code>, <code>projection</code>, <code>tty</code>, and <code>tv</code>. For information about valid media features and about the exact syntax of media queries, see the [https://drafts.csswg.org/mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [https://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#restrictions-for-contents-of-script-elements Restrictions for contents of script elements].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but <strong>commas must not be used to separate commands</code>, though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-month-string month], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-week-string week], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [https://html.spec.whatwg.org/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Contexts&diff=9893Contexts2015-03-31T12:58:12Z<p>Zcorpan: /* Context triggers */ Add css-font-loading API</p>
<hr />
<div>== How to use a context ==<br />
<br />
# Identify context.<br />
# Determine whether to fetch resource based on CSP directives and type hint, if any.<br />
# Fetch resource.<br />
# Set no-sniff flag on resource (based on URL), if necessary.<br />
# Handle resource.<br />
# Sniff resource.<br />
# Process and display resource or prompt to download resource, as appropriate.<br />
<br />
== Context types ==<br />
<br />
{| class="wikitable" style="text-align: center;" |<br />
! Context<br />
! Definition<br />
! Used in HTML?<br />
! Used in CSS?<br />
! Scriptable?<br />
! CSP Directive<br />
! Type Hint<br />
! [[MIME Sniffing|Sniffing]] Algorithm<br />
|-<br />
| browsing (navigate)<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/#browsing-context HTML]<br />
| Yes<br />
| No?<br />
| Yes<br />
| <br />
| —<br />
| rowspan="2" | [http://mimesniff.spec.whatwg.org/#mime-type-sniffing-algorithm MIME type sniffing algorithm]<br />
|-<br />
| nested browsing (navigate)<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/#nested-browsing-context HTML]<br />
| Yes<br />
| No?<br />
| Yes<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#frame-src <code>frame-src</code>]<br />
| <br />
|-<br />
| connection<br />
| <br />
| Yes<br />
| No?<br />
| Yes?<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#connect-src <code>connect-src</code>]<br />
| <br />
| <br />
|-<br />
| image<br />
| <br />
| Yes<br />
| Yes<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#img-src <code>img-src</code>]<br />
| <br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-images-specifically rules for sniffing images specifically]<br />
|-<br />
| audio/video<br />
| <br />
| Yes<br />
| No?<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#media-src <code>media-src</code>]<br />
| <br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-audio-and-video-specifically rules for sniffing audio and video specifically]<br />
|-<br />
| plugin<br />
| <br />
| Yes<br />
| No?<br />
| Yes<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#object-src <code>object-src</code>]<br />
| <br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-in-a-plugin-context rules for sniffing in a plugin context]<br />
|-<br />
| style<br />
| <br />
| Yes<br />
| Yes?<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#style-src <code>style-src</code>]<br />
| @<code>type</code> or "<code>text/css</code>"<br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-in-a-style-context rules for sniffing in a style context]<br />
|-<br />
| script<br />
| <br />
| Yes<br />
| No?<br />
| Yes?<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#script-src <code>script-src</code>]<br />
| @<code>type</code> or "<code>text/javascript</code>"<br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-in-a-script-context rules for sniffing in a script context]<br />
|-<br />
| font<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#font-src <code>font-src</code>]<br />
| <code>format()</code><br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-fonts-specifically rules for sniffing fonts specifically]<br />
|-<br />
| text track<br />
| <br />
| Yes<br />
| No<br />
| No<br />
| <br />
| "<code>text/vtt</code>"<br />
| <br />
|-<br />
| cache manifest<br />
| <br />
| Yes<br />
| No<br />
| No<br />
| <br />
| "<code>text/cache-manifest</code>"<br />
| <br />
|}<br />
<br />
== Context triggers ==<br />
<br />
{| class="wikitable" |<br />
! Context<br />
! HTML Triggers<br />
! CSS Triggers<br />
! Other Triggers<br />
|-<br />
! browsing<br />
| <br />
| <br />
| <br />
|-<br />
! nested browsing<br />
| <code>&lt;iframe></code>, <code>&lt;object></code> (sometimes), <code>&lt;frame></code><br />
| <br />
| <br />
|-<br />
! connection<br />
| <br />
| <br />
| EventSource, WebSocket, XMLHttpRequest<br />
|-<br />
! image<br />
| <code>&lt;img></code>, <code>&lt;link rel=icon></code>, <code>&lt;input type=image></code>, <code>&lt;object></code> (sometimes)<br />
| <code>background-image</code><br />
| <br />
|-<br />
! audio/video<br />
| <code>&lt;audio></code>, <code>&lt;video></code><br />
| <br />
| <br />
|-<br />
! plugin<br />
| <code>&lt;embed></code>, <code>&lt;object></code> (sometimes)<br />
| <br />
| <br />
|-<br />
! style<br />
| <code>&lt;link rel=stylesheet></code><br />
| <code>@import</code>?<br />
| <br />
|-<br />
! script<br />
| <code>&lt;script src></code><br />
| <br />
| <br />
|-<br />
! font<br />
| —<br />
| <code>@font-face</code><br />
| FontFace#load(), FontFaceSet#load()<br />
|-<br />
! text track<br />
| <code>&lt;track></code><br />
| —<br />
| <br />
|-<br />
! cache manifest<br />
| <code>&lt;html manifest></code><br />
| —<br />
| <br />
|}<br />
<br />
== Issues ==<br />
<br />
* What about SVG?<br />
* What about XSLT?<br />
* document.load()? (Seems similar enough to connect-src.)<br />
* What about CSS masks?<br />
* What about CSS shapes?<br />
<br />
[[Category:Spec coordination]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Contexts&diff=9892Contexts2015-03-31T12:54:59Z<p>Zcorpan: /* Context types */ plugins are scriptable</p>
<hr />
<div>== How to use a context ==<br />
<br />
# Identify context.<br />
# Determine whether to fetch resource based on CSP directives and type hint, if any.<br />
# Fetch resource.<br />
# Set no-sniff flag on resource (based on URL), if necessary.<br />
# Handle resource.<br />
# Sniff resource.<br />
# Process and display resource or prompt to download resource, as appropriate.<br />
<br />
== Context types ==<br />
<br />
{| class="wikitable" style="text-align: center;" |<br />
! Context<br />
! Definition<br />
! Used in HTML?<br />
! Used in CSS?<br />
! Scriptable?<br />
! CSP Directive<br />
! Type Hint<br />
! [[MIME Sniffing|Sniffing]] Algorithm<br />
|-<br />
| browsing (navigate)<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/#browsing-context HTML]<br />
| Yes<br />
| No?<br />
| Yes<br />
| <br />
| —<br />
| rowspan="2" | [http://mimesniff.spec.whatwg.org/#mime-type-sniffing-algorithm MIME type sniffing algorithm]<br />
|-<br />
| nested browsing (navigate)<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/#nested-browsing-context HTML]<br />
| Yes<br />
| No?<br />
| Yes<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#frame-src <code>frame-src</code>]<br />
| <br />
|-<br />
| connection<br />
| <br />
| Yes<br />
| No?<br />
| Yes?<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#connect-src <code>connect-src</code>]<br />
| <br />
| <br />
|-<br />
| image<br />
| <br />
| Yes<br />
| Yes<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#img-src <code>img-src</code>]<br />
| <br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-images-specifically rules for sniffing images specifically]<br />
|-<br />
| audio/video<br />
| <br />
| Yes<br />
| No?<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#media-src <code>media-src</code>]<br />
| <br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-audio-and-video-specifically rules for sniffing audio and video specifically]<br />
|-<br />
| plugin<br />
| <br />
| Yes<br />
| No?<br />
| Yes<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#object-src <code>object-src</code>]<br />
| <br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-in-a-plugin-context rules for sniffing in a plugin context]<br />
|-<br />
| style<br />
| <br />
| Yes<br />
| Yes?<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#style-src <code>style-src</code>]<br />
| @<code>type</code> or "<code>text/css</code>"<br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-in-a-style-context rules for sniffing in a style context]<br />
|-<br />
| script<br />
| <br />
| Yes<br />
| No?<br />
| Yes?<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#script-src <code>script-src</code>]<br />
| @<code>type</code> or "<code>text/javascript</code>"<br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-in-a-script-context rules for sniffing in a script context]<br />
|-<br />
| font<br />
| <br />
| No<br />
| Yes<br />
| No<br />
| [https://w3c.github.io/webappsec/specs/content-security-policy/#font-src <code>font-src</code>]<br />
| <code>format()</code><br />
| [http://mimesniff.spec.whatwg.org/#rules-for-sniffing-fonts-specifically rules for sniffing fonts specifically]<br />
|-<br />
| text track<br />
| <br />
| Yes<br />
| No<br />
| No<br />
| <br />
| "<code>text/vtt</code>"<br />
| <br />
|-<br />
| cache manifest<br />
| <br />
| Yes<br />
| No<br />
| No<br />
| <br />
| "<code>text/cache-manifest</code>"<br />
| <br />
|}<br />
<br />
== Context triggers ==<br />
<br />
{| class="wikitable" |<br />
! Context<br />
! HTML Triggers<br />
! CSS Triggers<br />
! Other Triggers<br />
|-<br />
! browsing<br />
| <br />
| <br />
| <br />
|-<br />
! nested browsing<br />
| <code>&lt;iframe></code>, <code>&lt;object></code> (sometimes), <code>&lt;frame></code><br />
| <br />
| <br />
|-<br />
! connection<br />
| <br />
| <br />
| EventSource, WebSocket, XMLHttpRequest<br />
|-<br />
! image<br />
| <code>&lt;img></code>, <code>&lt;link rel=icon></code>, <code>&lt;input type=image></code>, <code>&lt;object></code> (sometimes)<br />
| <code>background-image</code><br />
| <br />
|-<br />
! audio/video<br />
| <code>&lt;audio></code>, <code>&lt;video></code><br />
| <br />
| <br />
|-<br />
! plugin<br />
| <code>&lt;embed></code>, <code>&lt;object></code> (sometimes)<br />
| <br />
| <br />
|-<br />
! style<br />
| <code>&lt;link rel=stylesheet></code><br />
| <code>@import</code>?<br />
| <br />
|-<br />
! script<br />
| <code>&lt;script src></code><br />
| <br />
| <br />
|-<br />
! font<br />
| —<br />
| <code>@font-face</code><br />
| <br />
|-<br />
! text track<br />
| <code>&lt;track></code><br />
| —<br />
| <br />
|-<br />
! cache manifest<br />
| <code>&lt;html manifest></code><br />
| —<br />
| <br />
|}<br />
<br />
== Issues ==<br />
<br />
* What about SVG?<br />
* What about XSLT?<br />
* document.load()? (Seems similar enough to connect-src.)<br />
* What about CSS masks?<br />
* What about CSS shapes?<br />
<br />
[[Category:Spec coordination]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=9891MicrosyntaxDescriptions2015-03-30T20:40:49Z<p>Zcorpan: No 5</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [https://html.spec.whatwg.org/ WHATWG version of HTML] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki], or must be an absolute URL. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [https://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>.<br />
<br />
==language==<br />
An [https://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [https://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a <strong>media type</strong> and zero or more expressions that check for the conditions of particular <strong>media features</strong. A media type is one of the following: <code>all</code>, <code>print</code>, <code>screen</code>, or <code>speech</code>. The following media types are deprecated: <code>braille</code>, <code>embossed</code>, <code>handheld</code>, <code>projection</code>, <code>tty</code>, and <code>tv</code>. For information about valid media features and about the exact syntax of media queries, see the [https://drafts.csswg.org/mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [https://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#restrictions-for-contents-of-script-elements Restrictions for contents of script elements].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but <strong>commas must not be used to separate commands</code>, though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-month-string month], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-week-string week], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [https://html.spec.whatwg.org/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=9890MicrosyntaxDescriptions2015-03-30T20:03:54Z<p>Zcorpan: Avoid ''' since it's highlighted in red in v.nu. Also fix prose for MQ</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML5 microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [https://html.spec.whatwg.org/ WHATWG version of HTML 5] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki], or must be an absolute URL. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [https://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>.<br />
<br />
==language==<br />
An [https://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [https://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [https://html.spec.whatwg.org/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a <strong>media type</strong> and zero or more expressions that check for the conditions of particular <strong>media features</strong. A media type is one of the following: <code>all</code>, <code>print</code>, <code>screen</code>, or <code>speech</code>. The following media types are deprecated: <code>braille</code>, <code>embossed</code>, <code>handheld</code>, <code>projection</code>, <code>tty</code>, and <code>tv</code>. For information about valid media features and about the exact syntax of media queries, see the [https://drafts.csswg.org/mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [https://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [https://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [https://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#restrictions-for-contents-of-script-elements Restrictions for contents of script elements].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [https://html.spec.whatwg.org/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but <strong>commas must not be used to separate commands</code>, though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-month-string month], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-date-string date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-week-string week], [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [https://html.spec.whatwg.org/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Band_names&diff=9800Band names2015-01-29T14:03:40Z<p>Zcorpan: https://twitter.com/yoavweiss/status/560740185160163328</p>
<hr />
<div>These are band names collected from #whatwg.<br />
<br />
* Bogus DOM<br />
* The Unpaired Surrogates<br />
* Lone Surrogates<br />
* The Designated Experts<br />
* Spidermonkey and the GC Jitters<br />
* Polyglot Heartbeat<br />
* Extant Web Corpus<br />
* Ambushed by Ambiguity<br />
* Ambiguous Ampersands<br />
* bad value robot<br />
* Abort These Steps<br />
* Shadow Piercing Descendant Combinator<br />
<br />
== Album titles ==<br />
<br />
* User Bang Important Rule<br />
* Polygoat</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=TLS&diff=9705TLS2014-09-24T09:45:58Z<p>Zcorpan: </p>
<hr />
<div>== TLS ==<br />
<br />
* Integrity of content (no tampering possible)<br />
* Protection of end user credentials<br />
* Increased confidentiality (not perfect; domain is leaked, traffic analysis can still tell a great deal)<br />
* Service workers<br />
* [http://www.infoq.com/articles/Web-Sockets-Proxy-Servers Reduced problems with proxy traversal]<br />
* [https://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS Tim Bray on why privacy should be on by default]<br />
* [http://googleonlinesecurity.blogspot.co.uk/2014/08/https-as-ranking-signal_6.html HTTPS is a ranking signal for Google]<br />
* [https://indiewebcamp.com/HTTPS#Why Indie Web Camp on HTTPS]<br />
* [https://konklone.com/post/switch-to-https-now-for-free How to switch to HTTPS for free]<br />
<br />
== HSTS ==<br />
<br />
* [https://annevankesteren.nl/2014/09/tls-hsts TLS: deploy HSTS] TL;DR without HSTS your TLS deployment is not worth much</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MetaExtensions&diff=9689MetaExtensions2014-09-19T07:33:22Z<p>Zcorpan: </p>
<hr />
<div>This page lists the allowed extension values for the name="" attribute of the &lt;meta> element in HTML5. <br />
<br />
You may add your own values to this list, which makes them legal HTML5 metadata names. <br />
<br />
We ask that you:<br />
* '''avoid redundancy''' - if someone has already defined a name that does roughly what you want, please reuse it. <br />
* '''be sure to include ''all'' the items''' [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names required by the spec] ''including a link to a specification'' that specifies the keyword ''as an HTML meta keyword''. If a proposal lacks a specification and a version in a complete specification exists, the latter is to be preferred. <br />
<br />
Note that URL-valued properties must not be registered as meta names but should be registered as [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions rel keywords] instead. <br />
<br />
Also note that changes to this registry will not be reflected in validators in real time. But the validators will get automatically updated with the changes within one week or so.<br />
<br />
== Registered Extensions ==<br />
<br />
{| class="wikitable sortable"<br />
! Keyword<br />
! Brief description<br />
! Link to specification<br />
! Synonyms<br />
! Status<br />
<br />
|-valign="top" <br />
| AGLSTERMS.act<br />
| A specific piece of legislation which requires or drives the creation or provision of the resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.accessibility<br />
| A statement indicating the accessibility characteristics of the resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.accessMode<br />
| Perceptual mode for the resource. <br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.aggregationLevel<br />
| The level of aggregation of the described resource - an 'item' or a 'collection'.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.availability<br />
| How the resource can be obtained or accessed, or contact information. Primarily used for offline resources to provide information on how to obtain physical access to the resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.case<br />
| A specific piece of case law which requires or drives the creation or provision of the resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.category<br />
| The generic type of the resource being described - a 'service', 'document' or 'agency'.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.dateLicensed<br />
| Date a license was applied or became effective.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.documentType<br />
| The form of the described resource where the value of category is‘document’. Document is used in its widest sense and includes resources such as text, images, sound files and software.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.function<br />
| The business function to which the resource relates. Functions are the major units of activity which organisations pursue in order to meet the mission and goals of the organisation.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.isBasisFor<br />
| A related resource that is a performance, production, derivation, translation or interpretation of the described resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.isBasedOn<br />
| A related resource of which the described resource is a performance, production, derivation, translation or interpretation.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.jurisdiction<br />
| The name of the political/administrative entity covered by the described resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.mandate<br />
| A specific legal instrument which requires or drives the creation or provision of the resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.protectiveMarking<br />
| A protective marking applied to the described resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.regulation<br />
| A specific regulation which requires or drives the creation or provision of the resource.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| AGLSTERMS.serviceType<br />
| The form of the described resource where the value of category is ‘service'.<br />
| [http://www.agls.gov.au/pdf/AGLS%20Metadata%20Standard%20Part%202%20Usage%20Guide.PDF AGLS Metadata Usage Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| alexaverifyid<br />
| Used to verify ownership of Alexa Search<br />
| [http://www.alexa.com/faqs/?p=188 Alexa FAQ About this meta attribute Reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| apple-itunes-app<br />
| Promoting Apps with Smart App Banners<br />
| [http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html Safari Web Content Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| apple-mobile-web-app-capable<br />
| Sets whether a web application runs in full-screen mode.<br />
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]<br />
| mobile-web-app-capable (also could maybe be assumed when <code>application-name</code> is set?)<br />
| Proposal<br />
<br />
|-valign="top" <br />
| apple-mobile-web-app-status-bar-style<br />
| Sets the style of the status bar for a web application.<br />
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| apple-touch-fullscreen<br />
| forces iPhone Fullscreen mode, if added to home screen. Not needed anymore.<br />
| No specification yet<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| apple-mobile-web-app-title<br />
| Sets the title of the application when added to the homescreen on iOS6+<br />
| [https://jokenetwork.de/faq/apple/title/ Unofficial Documentation of apple-mobile-web-app-title] - Read more about Apple's web-app's at [https://developer.apple.com/library/safari/documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| application-url<br />
| '''Start URL of web apps in Google Chrome'''<br />
The "application-url" meta tag can be used to specify the start URL of pinned web apps in Google Chrome.<br />
<meta name="application-url" content="https://gmail.com/"><br />
| [http://www.google.com/chrome/intl/en/webmasters-faq.html#customshortcuts Google Chrome Webmaster FAQ] [http://code.google.com/p/chromium/issues/detail?id=40010#c1 Chromium issue response]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| baiduspider<br />
| Synonym of <code>robots</code> for targeting Baidu only.<br />
| [http://www.baidu.com/search/robots_english.html Baidu documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| bitcoin<br />
| a bitcoin-address<br />
| Short documentation (unofficial): [https://jokenetwork.de/faq/bitcoin JokeNetwork's unofficial documentation for bitcoin-metatag], more informations about the Bitcoin-adress: [https://en.bitcoin.it/wiki/Address Bitcoin wiki]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| blazerr-support-identifier<br />
| Used to identify users for JokeNetwork's Blazerr Support-System along with a cookie. Not adapted to the cookie policy of the EU yet. The verification of a user without the use of cookies can be obtained with the meta tag [https://jokenetwork.de/faq/blazerr/ blazerr-support-id-noncookies].<br />
| [https://jokenetwork.de/faq/blazerr/metatags/#blazerr-support-identifier JokeNetwork's Blazerr Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| blazerr-support-id-noncookies<br />
| Used to identify users for JokeNetwork's Blazerr Support-System without a cookie.<br />
| [https://jokenetwork.de/faq/blazerr/metatags/#blazerr-support-id-noncookies JokeNetwork's Blazerr Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| blazerr-ssl<br />
| Decides whether connect via a secure connection or not to JokeNetwork's Blazerr-System. Similar to blazerr-secure.<br><br />
Usage: <code><meta name="blazerr-ssl" content="yes"></code><br />
| [https://jokenetwork.de/faq/blazerr/metatags/#blazerr-ssl JokeNetwork's Blazerr Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| blazerr-secure<br />
| Decides whether connect via a secure connection or not to JokeNetwork's Blazerr-System. Synonym to blazerr-ssl, but only for old browsers such as Internet Explorer 7.<br><br />
Usage: <code><meta name="blazerr-secure" content="yes"></code><br />
| [https://jokenetwork.de/faq/blazerr/metatags/#blazerr-secure JokeNetwork's Blazerr Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| blazerr-seo<br />
| Checks whether Blazerr SEO has been used or not. It contains the user-id and the SEO Version.<br><br />
Usage: <code><meta name="blazerr-seo" content="0001;v0.7"></code><br>0001 is an example for a user id, v0.7 identifies which version of SEO is used (In this case version Beta 7 / 0.7). If you're using Blazerr SEO, you have to include this meta-tag. Otherwise the tool will not work.<br />
| [https://jokenetwork.de/faq/blazerr/metatags/#blazerr-seo JokeNetwork's Blazerr Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| bug.blocked<br />
| Bugzilla dependency tree to which the https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js bug-creation script will add a link.<br />
| [https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js Embedded documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| bug.comment<br />
| Bugzilla comment used by the https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js bug-creation script.<br />
| [https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js Embedded documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| bug.component<br />
| Bugzilla component against which the https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js bug-creation script will create a new bug.<br />
| [https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js Embedded documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| bug.product<br />
| Bugzilla product against which the https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js bug-creation script will create a new bug.<br />
| [https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js Embedded documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| bug.short_desc<br />
| Bugzilla short description used by the https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js bug-creation script.<br />
| [https://dvcs.w3.org/hg/webcomponents/raw-file/default/assets/scripts/bug-assist.js Embedded documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| theme-color<br />
| Indicates a color associated with the web site's theme. Web browsers might use this color to theme their UI to be consistent with the web site's color scheme.<br><br />
Usage: <code><meta name="theme-color" content="papayawhip"></code><br />
| [https://github.com/whatwg/meta-brand-color Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| cfia.gdr.include<br />
| Canadian Food Inspection Agency Guidance Document Repository Page<br />
| Coming soon at [http://www.inspection.gc.ca CFIA website]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| cfia.gdr.program<br />
| Canadian Food Inspection Agency Guidance Document Repository Page Program<br />
| Coming soon at [http://www.inspection.gc.ca CFIA website]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| cfia.gdr.commodity<br />
| Canadian Food Inspection Agency Guidance Document Repository Page Commodity<br />
| Coming soon at [http://www.inspection.gc.ca CFIA website]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| cfia.gdr.activity<br />
| Canadian Food Inspection Agency Guidance Document Repository Page Activity<br />
| Coming soon at [http://www.inspection.gc.ca CFIA website]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| citeseerxbot<br />
| Synonym of <code>robots</code> for targeting CiteSeerX only.<br />
| [http://csxstatic.ist.psu.edu/submit CiteSeerX Submit Documents] <small>'If you do not want your documents crawled by CiteSeerX, please use a robots.txt to disallow our crawler named "citeseerxbot"'</small>, [http://csxstatic.ist.psu.edu/about/crawler CiteSeerX Crawler]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| collection<br />
| To replace the obsolete dc:collection. A collection is described as a group, an aggregation of topics Used to describe the top-level content of XHTML documents. These appear in your META tags showing a group of subject. Website Taxonomy improve classification for search engine analysis and semantic communication with a description language content.<br />
<br />
<meta name="collection" content="MetaExtensions" /><br />
<meta name="subject" content="topics, thesaurus, Meta Tag, header, semantic" /><br />
| [http://www.trucsweb.com/tw/]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| contact<br />
| Defines the vendor's contact information by way of a phone-number (such as the customer support number), an e-mail ID (such as the customer support mail ID) or a physical address (such as the office address or billing address).<br><br />
Usage: <code><meta name="contact" content="+1-555-555-5555 abc@xyz.com '5844 South Oak Street, Chicago, Illinois'"></code><br>or in case of multiple entries:<br><br />
<code><meta name="contact" content="Chicago: +1-555-555-5555 abc@xyz.com '5844 South Oak Street, Chicago, Illinois'; Brookfield: +1-444-444-4444 def@xyz.com '2341 Cherry Lane, Brookfield, Illinois'"></code><br><br />
The content attribute is a space separated string containing the phone-number followed by the e-mail ID and then the address (specified within quotes).<br><br />
For specifying multiple entries a semi-colon separated list of name: value pairs can be defined. The name can be any descriptive tag identifying the given location.<br>Valid phone numbers and mail IDs should be provided by the vendor. The address can either be a string specified within quotes or the latitude and longtitude coordinates.<br />
| [http://arpita.github.io/ContactMetaExtensions/ Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| csrf-param<br />
| Cross-site request forgery protection parameter for Ruby on Rails<br />
| [http://apidock.com/rails/ActionView/Helpers/CsrfHelper/csrf_meta_tag Rails API]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| csrf-token<br />
| Cross-site request forgery protection token for Ruby on Rails<br />
| [http://apidock.com/rails/ActionView/Helpers/CsrfHelper/csrf_meta_tag Rails API]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_anonymiseIP<br />
| Defines anonymiseIP parameter for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_contactCompany<br />
| Defines the contactCompany of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_contactEmail<br />
| Defines the contactEmail of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_contactFirstName<br />
| Defines the contactFirstName of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_contactLastName<br />
| Defines the contactLastName of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_contactName<br />
| Defines the contactName of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_contactTelephone<br />
| Defines the contactTelephone of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_conversionCurrency<br />
| Defines the conversionCurrency of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_conversionId<br />
| Defines the conversionId of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_conversionValue<br />
| Defines the conversionValue of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_goalCurrency<br />
| Defines the goalCurrency of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_goalId<br />
| Defines the goalId of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_goalValue<br />
| Defines the goalValue of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_interactionSelector<br />
| Defines the interactionSelector parameter for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_pageRole<br />
| Defines the role of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_pageTaxonomy<br />
| Defines the taxonomy of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_pageTitle<br />
| Defines the pageTitle of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_pageVersion<br />
| Defines the pageVersion of the page for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_sessionId<br />
| Defines the sessionId parameter for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| da_userId<br />
| Defines the userId parameter for Decibel Insight<br />
| [https://www.decibelinsight.com/assets/Documents/DecibelInsightImplementationGuide.pdf Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.created<br />
| Date of creation of the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-created DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.creator<br />
| An entity primarily responsible for making the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-creator DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| dc.date.issued<br />
| Date of publication for Google News. The format of the content is YYYY-MM-DD or YYYY-MM-DDThh:mm:ssTZD.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element<br />
| [http://www.google.com/support/news_pub/bin/answer.py?answer=93994 Google News documentation]<br />
| <code>dcterms.issued</code> (former <code>&lt;time pubdate&gt;</code> no longer considered due to the abort of <code>@pubdate</code>)<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.dateCopyrighted<br />
| Date of copyright.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-dateCopyrighted DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.dateSubmitted<br />
| Date of submission of the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-dateSubmitted DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.description<br />
| An account of the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-description DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.language<br />
| A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646]. <br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-language DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| Redundant with the <code>lang</code> attribute on the<br />
<code>html</code> element. (Browsers pay attention to the <code>lang</code> attribute but not <code>dc.language</code>)<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.license<br />
| A legal document giving official permission to do something with the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-license DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.mediator<br />
| An entity that mediates access to the resource and for whom the resource is intended or useful.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-mediator DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.medium<br />
| The material or physical carrier of the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-medium DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.modified<br />
| Date on which the resource was changed.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-modified DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.provenance<br />
| A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-provenance DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.publisher<br />
| An entity responsible for making the resource available.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-publisher DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.references<br />
| A related resource that is referenced, cited, or otherwise pointed to by the described resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-references DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.temporal<br />
| Temporal characteristics of the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-temporal DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.title<br />
| A name given to the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-title DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.type<br />
| The nature or genre of the resource. Recommended best practice is to use a controlled vocabulary such as the DCMI Type Vocabulary [DCMITYPE].<br />
To describe the file format, physical medium, or dimensions of the resource, use the Format element.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-type DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dc.valid<br />
| Date (often a range) of validity of a resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dc" href="<nowiki>http://purl.org/dc/elements/1.1/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-valid DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
|-valign="top"<br />
| dcterms.abstract<br />
| A summary of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-abstract DCMI<br />
Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <code>&lt;meta name="description"&gt;</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.accessRights<br />
| Information about who can access the resource or an indication of its security status. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-accessRights DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.accrualMethod<br />
| The method by which items are added to a collection. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualMethod DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.accrualPeriodicity<br />
| The frequency with which items are added to a collection. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualPeriodicity DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.accrualPolicy<br />
| The policy governing the addition of items to a collection. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-accrualPolicy DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.alternative<br />
| An alternative name for the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-alternative DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.audience<br />
| A class of entity for whom the resource is intended or useful. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-audience DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.available<br />
| Date (often a range) that the resource became or will become available. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-available DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.bibliographicCitation<br />
| A bibliographic reference for the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-bibliographicCitation DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML attribute <code>cite</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.collection<br />
| An aggregation of resources. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#dcmitype-Collection DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.conformsTo<br />
| An established standard to which the described resource conforms. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-conformsTo DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.contributor<br />
| An entity responsible for making contributions to the content of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-contributor DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.coverage<br />
| The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-coverage DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.created<br />
| Date of creation of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-created DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.creator<br />
| An entity primarily responsible for making the resource. Examples of a Creator include a person, an organization, or a service. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-creator DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| In some cases redundant with the HTML built-in keyword <code>author</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.date<br />
| A point or period of time associated with an event in the lifecycle of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-date DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.dateAccepted<br />
| Date of acceptance of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-dateAccepted DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.dateCopyrighted<br />
| Date of copyright. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-dateCopyrighted DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.dateSubmitted<br />
| Date of submission of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-dateSubmitted DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.description<br />
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-description DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| HTML built-in keyword <code>description</code> <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.educationLevel<br />
| A class of entity, defined in terms of progression through an educational or training context, for which the described resource is intended. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-educationLevel DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.extent<br />
| The size or duration of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-extent DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.format<br />
| The file format, physical medium, or dimensions of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-format DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| To be limited to dimensions information. File format for the document is to be determined by server. Linked resources can be described by <code>type</code> attribute.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.hasFormat<br />
| A related resource that is substantially the same as the pre-existing described resource, but in another format. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-hasFormat DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.hasPart<br />
| A related resource that is included either physically or logically in the described resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-hasPart DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.hasVersion<br />
| A related resource that is a version, edition, or adaptation of the described resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-hasVersion DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.identifier<br />
| An unambiguous reference to the resource within a given context. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-identifier DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.instructionalMethod<br />
| A process used to engender knowledge, attitudes and skills, that the described resource is designed to support. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-instructionalMethod DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.isFormatOf<br />
| A related resource that is substantially the same as the described resource, but in another format. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-isFormatOf DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.isPartOf<br />
| A related resource in which the described resource is physically or logically included. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-isPartOf DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.isReferencedBy<br />
| A related resource that references, cites, or otherwise points to the described resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-isReferencedBy DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.isReplacedBy<br />
| A related resource that supplants, displaces, or supersedes the described resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-isReplacedBy DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.isRequiredBy<br />
| A related resource that requires the described resource to support its function, delivery, or coherence.<br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-isRequiredBy DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.issued<br />
| Date of formal issuance (e.g., publication) of the resource. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.) <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-issued DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| (former <code>&lt;time pubdate&gt;</code> no longer considered due to the abort of <code>@pubdate</code>)<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.isVersionOf<br />
| A related resource of which the described resource is a version, edition, or adaptation.<br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-isVersionOf DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.language<br />
| A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646]. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-language DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| Redundant with the <code>lang</code> attribute on the <code>html</code> element. (Browsers pay attention to the <code>lang</code> attribute but not <code>dcterms.language</code>)<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.license<br />
| A legal document giving official permission to do something with the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-license DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML <code>&lt;link&gt;</code> element with the keyword <code>"license"</code> as value of the <code>rel</code> attribute.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.mediator<br />
| An entity that mediates access to the resource and for whom the resource is intended or useful. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-mediator DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.medium<br />
| The material or physical carrier of the resource.<br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-medium DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.modified<br />
| Date on which the resource was changed. (DC doesn't spec a date format but the established practice is YYYY-MM-DD.) <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-modified DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.provenance<br />
| A statement for any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-provenance DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.publisher<br />
| An entity responsible for making the resource available. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-publisher DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.references<br />
| A related resource that is referenced, cited, or otherwise pointed to by the described resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-references DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <code>cite</code> attribute on specific quotes, if any.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.relation<br />
| A related resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-relation DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| If the relation comes from an internal reference or quote, <code>dcterms.references</code> should be preferred.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.replaces<br />
| A related resource that is supplanted, displaced, or superseded by the described resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-replaces DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.requires<br />
| A related resource that is required by the described resource to support its function, delivery, or coherence. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-requires DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.rights<br />
| Information about rights held in and over the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-rights DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML <code>&lt;link&gt;</code> element with the keyword <code>"license"</code> as value of the <code>rel</code> attribute, if referring to a legal license format.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.rightsHolder<br />
| A person or organization owning or managing rights over the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-rightsHolder DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.source<br />
| A related resource from which the described resource is derived. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-source DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| The HTML link type keyword "alternate" used with "link" element:<code>rel="alternate" href="URI of related resource"</code> if documents are different versions. Otherwise, <code>cite</code> attribute.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.spatial<br />
| Spatial characteristics of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-spatial DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.subject<br />
| The topic of the resource.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-subject DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| HTML built-in keywords <code>description</code> or <code>keywords</code><br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.tableOfContents<br />
| A list of subunits of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-tableOfContents DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| HTML built-in keywords <code>description</code> or <code>keywords</code>. Otherwise, a <code>details-summary</code> model which would provide user-readable information.<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.temporal<br />
| Temporal characteristics of the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-temporal DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.title<br />
| A name given to the resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-title DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| HTML built-in element <code>title</code> (not to be confused with <code>@title</code> attributes specific to each element)<br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.type<br />
| The nature or genre of the resource.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-type DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| dcterms.valid<br />
| Date (often a range) of validity of a resource. <br />
It must be accompanied by a <code>&lt;link rel="schema.dcterms" href="<nowiki>http://purl.org/dc/terms/</nowiki>"&gt;</code> element.<br />
| [http://dublincore.org/documents/dcmi-terms/#terms-valid DCMI Metadata Terms] mapped according to<br />
[http://dublincore.org/documents/dc-html/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| detectify-verification<br />
| Used by the Detectify web vulnerability scanner as a domain verification key. The Detectify service will only consider the domain authenticated if it contains the "detectify-verification" meta tag, with the content set according to a per-customer token.<br />
| [http://labs.detectify.com/post/85707633296/detectify-validation-specification Documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| designer<br />
| Credits the designer(s) responsible for the visual presentation of a website.<br />
| [https://sites.google.com/site/metadesignerspec/ Documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| entity<br />
| Allows for definitions of XML-style entities for substitution of references (defined as specially-named elements (e.g., use of data element and/or data-* attribute) or script tags) via inclusion of a JavaScript library. Library also supports inclusion of additional meta element entity definitions via iframe documents.<br />
| [https://github.com/brettz9/js-css-entities Documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| EssayDirectory<br />
| Defines a custom description of websites listed in EssayDirectory.<br>Example:<br />
<meta name="EssayDirectory" content="Helping students find legitimate essay services."><br />
| [http://essaydirectory.com/privacy-terms/#EssayDirectory_MetaExtension Documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| fdse-description<br />
| Tag used by FDSE search software, allows different description to be displayed in fdse results to that shown in description<br />
| [http://www.xav.com/scripts/search/help/1013.html]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| fdse-index-as<br />
| Tag used by FDSE search software, allows FDSE to index a page as url described here<br />
| [http://www.xav.com/scripts/search/help/1014.html]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| fdse-keywords<br />
| Tag used by FDSE search software, allows different keywords to be used by FDSE to keywords tag<br />
| [http://www.xav.com/scripts/search/help/1013.html]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| fdse-refresh<br />
| Tag used by FDSE search software, allows FDSE to ignore refresh meta tags<br />
| [http://www.xav.com/scripts/search/help/1013.html]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| fdse-robots<br />
| Tag used by FDSE search software, allows different robots instructions to be sent to FDSE than that sent to other search engines eg: index no index pages for local search<br />
| [http://www.xav.com/scripts/search/help/1013.html]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| gcterms.topicTaxonomy<br />
| Organize resources specifically for taxonomy-based topical browse or search structures on websites (ie: breadcrumbs / website information architecture).<br />
| [http://www.gcpedia.gc.ca/wiki/Metadata_Tools#Metadata_for_Web_Resource_Discovery] Government of Canada, Web Content Management System Metadata Application Profile.<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| google-play-app<br />
| Promoting Apps with Smart App Banners<br />
| [http://jasny.github.io/jquery.smartbanner/] Smart banners for Google Apps <br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
|icas.datetime.long<br />
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of ICAS long date format such as "UCN 12012 M03 Blue ❀ day 333 ❀ IDC zone(UT) t969 tt189". example <meta name="icas.datetime.long" content="UCN 12012 M03 Blue ❀ day 333 ❀ IDC zone(UT) t969 tt189"/><br />
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.<br />
|<br />
|proposal<br />
<br />
|-valign="top"<br />
|icas.datetime.day<br />
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of ICAS day-of-year format such as "2012 day 333 t969".<br />
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.<br />
|<br />
|proposal<br />
<br />
|-valign="top"<br />
|icas.datetime.abbr<br />
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of an ICAS abbreviated format such as "d2M03 t969".<br />
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.<br />
|<br />
|proposal<br />
<br />
|-valign="top"<br />
|icas.datetime<br />
|A point or period of time associated with an event in the lifecycle of the resource represented in terms of an ICAS date and time format of unspecified information density (may include full, long, medium, short, or compressed forms).<br />
|a preliminary specification in the aaticas group on LinkedIn (http://www.linkedin.com/groups/aaticas-4034149). after a period of review, a specification for AAT ICAS meta keywords for HTML(5) will be referenced on an AAT ICAS area of the aatideas.org web site.<br />
|<br />
|proposal<br />
<br />
|-valign="top" <br />
| format-detection<br />
| Enables or disables automatic detection of possible phone numbers in a webpage in Safari on iOS.<br />
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html Apple Safari HTML Reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| fragment<br />
| Opts a webpage into the AJAX crawling scheme when it does not have a "#!" URL. The only valid content value is "!".<br />
<meta name="fragment" content="!"><br />
| [https://developers.google.com/webmasters/ajax-crawling/docs/specification Google Crawable AJAX Specification]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.position<br />
| Geographic position to which the page is related.<br />
<meta name="geo.position" content="48.02682000000001;7.809769999999958"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br />
| icbm (different value syntax)<br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.country<br />
| Case-insensitive ISO 3166-1 alpha-2 code of a country to which the page is related.<br />
<meta name="geo.country" content="de"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>[http://en.wikipedia.org/wiki/ISO_3166-2 ISO-3166-2]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.a1<br />
| National subdivision (state, canton, region, province, prefecture) of civil address to which the page is related. For resources within the US and Canada, corresponds to the common 2-character State/Province codes.<br />
<meta name="geo.a1" content="AB"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.a2<br />
| County, parish, gun (JP), district (IN) of civil address to which the page is related.<br />
<meta name="geo.a2" content="Warwickshire"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.a3<br />
| City, township, shi (JP) of civil address to which the page is related.<br />
<meta name="geo.a3" content="Calgary"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>RFC 4776<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.lmk<br />
| A landmark or vanity address to which the page is related.<br />
<meta name="geo.lmk" content="Auwaldstraße 11, 79110 Freiburg im Breisgau, Deutschland"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.region<br />
| Superseded by either geo.country alone or geo.country plus geo.a1. Name of geographic region to which the page is related. Content is specified by ISO-3166.<br />
<meta name="geo.region" content="DE-BW"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br>[http://en.wikipedia.org/wiki/ISO_3166 ISO-3166]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| geo.placename<br />
| Superseded by geo.lmk. Name of geographic place to which the page is related.<br />
<meta name="geo.placename" content="London, Ontario"><br />
| [http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 IETF Draft]<br>[http://geotags.com/geo/geotags2.html GeoTags.com]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.instruction<br />
| Globrix property information: Property to Buy or Rent<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.price<br />
| Globrix property information: Price for the property<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.postcode<br />
| Globrix property information: Postcode of the property<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.bedrooms<br />
| Globrix property information: Number of bedrooms the property has<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.bathrooms<br />
| Globrix property information: Number of bathrooms the property has<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.type<br />
| Globrix property information: Type of property e.g. 'semi-detatched house'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.condition<br />
| Globrix property information: Condition of the property e.g. 'renovated'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.features<br />
| Globrix property information: Features of the property e.g. 'double glazing'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.outsidespace<br />
| Globrix property information: External features of the property e.g. 'garden'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.parking<br />
| Globrix property information: Parking available for property e.g. 'parking for 2 cars'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.period<br />
| Globrix property information: Period of the property e.g. 'victorian terrace'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.poa<br />
| Globrix property information: If the property price is only available on application<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.tenure<br />
| Globrix property information: The tenure of the property e.g. 'leasehold'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.underoffer<br />
| Globrix property information: Indicates if the property is under offer<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.priceproximity<br />
| Globrix property information: The region of the attached price e.g. 'guide price of'<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.latitude<br />
| Globrix property information: The latitude of the property<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| globrix.longitude<br />
| Globrix property information: The longitude of the property<br />
| [http://content.globrix.com/web-tools/8-technical-guide/74-what-are-globrix-meta-tags-and-how-can-i-use-them FAQ About the Globrix meta tags.]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| go-import<br />
| Defines a remote source code location and version control scheme for the Go programming language's toolchain. Content format: <code>import-prefix vcs repo-root</code>.<br />
| [http://golang.org/cmd/go/#hdr-Remote_import_path_syntax go tool documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| google<br />
| Used to declare text that should not be translated by the Google Translate plugin <meta name="google" value="notranslate"> will declare the whole page should not be translated. <span class="notranslate"> is for text or paragraph areas you wish to not be translated.<br />
| [http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html Google blog post]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| google-site-verification<br />
| Used to verify ownership for Webmaster Tools.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=79812 Google documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| googlebot<br />
| Synonym of <code>robots</code> for targeting Googlebot only.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=93710 Google documentation]<br />
| <br />
|Proposal<br />
<br />
|-valign="top" <br />
| googlebot-mobile<br />
| Synonym of <code>robots</code> for targeting Googlebot-Mobile<br />
| [https://developers.google.com/webmasters/smartphone-sites/googlebot-mobile]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| gwt:property<br />
| Used to specify the locale client property<br />
| [https://developers.google.com/web-toolkit/doc/latest/DevGuideI18nLocale Locales in GWT]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| handheldfriendly<br />
| Informs the BlackBerry browser that the content contained within the document is designed for small screens.<br />
| [http://docs.blackberry.com/en/developers/deliverables/6176/HTML_ref_meta_564143_11.jsp BlackBerry browser documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| icbm<br />
| Defines geographic position to which page is related to. The acronym stands for ICBM Intercontinental Ballistic Missile - an old, humorous allusion to the possible use of such coordinates.<br>Example:<br />
<meta name="ICBM" content="47.0667, 15.4500" /><br />
| [http://geourl.org/add.html GeoURL documentation]<br />
| geo.position (different value syntax)<br />
| Proposal<br />
<br />
|-valign="top"<br />
| IE_RM_OFF<br />
| If set to "true", disables Internet Explorer 11 Reading View button adjacent to address bar when the page is detected to have content suitable for Reading View. This is intended for pages that are not articles and are not intended to be read in IE 11 Reading View.<br />
| [http://ie.microsoft.com/testdrive/browser/readingview/ Microsoft: Reading View Guidelines and Information] In the Code tab, at the bottom where Opt Out is read.<br />
|<br />
| Proposal<br />
<br />
<br />
|-valign="top" <br />
| itemsPerPage<br />
| Used to identify the number of search results returned per page.<br />
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| meta_date<br />
| The date used to indicate that the Metadata has been prepared and/or reviewed and approved by the Metadata Unit. Its purpose is administrative. (Used by "Autonomy".)<br />
| [http://www.hc-sc.gc.ca/home-accueil/alt_formats/pacrb-dgapcr/pdf/Metadata_Application_Profile_2009.pdf Health Canada Web Metadata Application Profile March 2009 ]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| mobile-agent<br />
| Specifies the mobile-compatible url of the web page. Used by mobile browsers and search engines to redirect mobile phone visitors to the proper mobile page. <br><br />
The following properties can be used in the value of the content attribute:<br>url - The mobile-compatible url of the web page.<br>format - The format of the mobile page. An enum of "wml", "xhtml" and "html5".<br>Example:<br />
<meta name="mobile-agent" content="format=html5; url=http://3g.sina.com.cn/"><br />
| [http://open.shouji.baidu.com/?page=developer&action=pcandmo Baidu Mobile SEO]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| mobile-web-app-capable<br />
| Sets whether a web application can be added standalone to a home screen and launched in fullscreen mode. Also proposed as a vendor-neutral version of apple-mobile-web-app-capable.<br />
| [https://developers.google.com/chrome/mobile/docs/installtohomescreen Add to Homescreen - Google Chrome Mobile &mdash; Google Developers] (though a WHATWG or W3C spec would be preferred)<br />
| apple-mobile-web-app-capable (vendor specific synonym)<br />
| Proposal<br />
<br />
|-valign="top" <br />
| mobileoptimized<br />
| Controls layout behavior in older versions of Internet Explorer (e.g., 6.5). <br />
| [http://msdn.microsoft.com/en-us/library/bb431690.aspx Microsoft Windows Mobile 6.5 documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-task<br />
| '''"Jump List" or "Pinned Sites" in Windows 7'''<br />
Jump List items act as entry points into the website even when the browser is not running. A Jump List can contain commonly used destinations and tasks. Some items apply to the whole site, and some apply only to specific users. <br />
For example, to add a single task called "Check Order Status" specify a meta element in the head of your webpage, as follows:<br />
<META name="msapplication-task" content="name=Check Order Status;<br />
action-uri=./orderStatus.aspx?src=IE9;<br />
icon-uri=./favicon.ico" /><br />
| [http://msdn.microsoft.com/en-us/library/gg491725(v=vs.85).aspx Tasks in Jump List]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-starturl<br />
| '''"Jump List" or "Pinned Sites" in Windows 7'''<br />
The "msapplication-starturl" metadata contains the root URL of the application. The start URL can be fully qualified, or relative to the current document. Only HTTP and HTTPS protocols are allowed. If this element is missing, the address of the current page is used instead.<br />
<meta name="msapplication-starturl" content="./" /><br />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-tooltip<br />
| '''"Jump List" or "Pinned Sites" in Windows 7'''<br />
The "msapplication-tooltip" metadata provides additional tooltip text that appears when you hover over the Pinned Site shortcut in the Windows Start menu or on the desktop.<br />
<meta name="msapplication-tooltip" content="Channel 9 Podcasts" /><br />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-tap-highlight<br />
| '''Link highlighting in Internet Explorer'''<br />
The "msapplication-tap-highlight" meta tag can be used to disable automatic highlighting of tapped links in Internet Explorer. Applies to IE10 on Windows Phone 8 and IE11 on Windows 8.1.<br />
<meta name="msapplication-tap-highlight" content="no" /><br />
| [http://msdn.microsoft.com/en-us/library/ie/bg182645%28v=vs.85%29.aspx#tapHighlight Link highlighting]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-navbutton-color<br />
| '''"Jump List" or "Pinned Sites" in Windows 7'''<br />
The "msapplication-navbutton-color" metadata define the custom color of the Back and Forward buttons in the Pinned Site browser window. Any named color, or hex color value is valid.<br />
<meta name="msapplication-navbutton-color" content="#FF3300" /><br />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-window<br />
| '''"Jump List" or "Pinned Sites" in Windows 7'''<br />
The "msapplication-window" metadata sets the initial size of the Pinned Site window when it is launched for the first time. However, if the user adjusts the size of the window, the Pinned Site retains the new dimensions when it is launched again.<br />
The following properties can be used in the value of the <code>content</code> attribute:<br />
* width - The window width in pixels. The minimum value is 800.<br />
* height - The window height in pixels. The minimum value is 600.<br />
<meta name="msapplication-window" content="width=1024;height=768" /><br />
| [http://msdn.microsoft.com/en-us/library/gg491732(v=VS.85).aspx Declaring Pinned Site Metadata]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-config<br />
| '''"Pinned Sites" in Windows 8'''<br />
The "msapplication-config" metadata defines the path to a browser configuration file, letting you set pinned sites customizations (such as tile background, badge updates and notifications) with this external XML file rather than metadata within the HTML markup of webpages.<br />
<meta name="msapplication-config" content="IEconfig.xml" /><br />
'''Note'''<br />
Without this metadata, IE11 looks for a default "browserconfig.xml" in the root directory of the server.<br />
| [http://msdn.microsoft.com/en-us/library/ie/dn320426%28v=vs.85%29.aspx Browser configuration schema reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-TileImage<br />
| The "msapplication-TileImage" metadata define the path to an image to be used as background for a tile in Pinned Sites in Windows 8. Tile images must be square PNGs 144px by 144px.<br />
<meta name="msapplication-TileImage" content="images/benthepcguy-144.png" /><br />
| [http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx High Quality Visuals for Pinned Sites in Windows 8]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-TileColor<br />
| The "msapplication-TileColor" metadata define the background color of a tile in Pinned Sites in Windows 8. The tile color can be specified as a hex RGB color using CSS’s #rrggbb notation, via CSS color names, or by the CSS rgb() function.<br />
<meta name="msapplication-TileColor" content="#d83434"/><br />
| [http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx High Quality Visuals for Pinned Sites in Windows 8]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-square70x70logo<br />
| '''msapplication-square70x70logo'''<br />
Specifies the image to use as the small tile, which is 70x70 pixels at 100% scaling.<br />
<meta name="msapplication-square70x70logo" content="images/tinylogo.png"><br />
'''Note''' The '''msapplication-square70x70logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.<br />
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-square150x150logo<br />
| '''msapplication-square150x150logo'''<br />
Specifies the image to use as the wide tile, which is 310x150 pixels at 100% scaling.<br />
<meta name="msapplication-square150x150logo" content="images/logo.png"><br />
'''Note''' The '''msapplication-square150x150logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.<br />
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-wide310x150logo<br />
| '''msapplication-wide310x150logo'''<br />
Specifies the image to use as the medium tile, which is 150x150 pixels at 100% scaling.<br />
<meta name="msapplication-wide310x150logo" content="images/widelogo.png"><br />
'''Note''' The '''msapplication-wide310x150logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.<br />
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| msapplication-square310x310logo<br />
| '''msapplication-square310x310logo'''<br />
Specifies the image to use as the large tile, which is 310x310 pixels at 100% scaling.<br />
<meta name="msapplication-square310x310logo" content="images/largelogo.png"><br />
'''Note''' The '''msapplication-square310x310logo''' value is supported as of IE11 Preview and applies to tiles pinned to the Windows Start screen.<br />
| [http://msdn.microsoft.com/en-us/library/ie/dn255024%28v=vs.85%29.aspx Pinned site metadata reference]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| msvalidate.01<br />
| One of the verification elements used by Bing.<br />
| [http://onlinehelp.microsoft.com/en-us/bing/hh204490.aspx Bing Webmaster Tools]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| norton-safeweb-site-verification<br />
| Used to verify ownership of Website for Norton SafeWeb.<br />
| [http://safeweb.norton.com/help/site_owners#verification_tips Norton SafeWeb Help Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| p:domain_verify<br />
| Used to register a site's domain with Pinterest as a "verified domain".<br />
Example:<br />
<code><meta name="p:domain_verify" content="5dd1c5f2db0ac0b521f08d56b4cd271b"></code><br />
| [https://help.pinterest.com/entries/22488487-Verify-with-HTML-meta-tags Pinterest Help Article]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| pingdom<br />
| Used by Pingdom monitoring services as a heartbeat verification. The heartbeat service will only consider the request successful if it contains the "pingdom" meta tag, with the content set according to a per-customer key.<br />
Example:<br />
<code><meta name="pingdom" content="6bh3nxnx"/></code><br />
|<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| pinterest<br />
| Used to block pinterest from linking to content on the URL.<br />
Example:<br />
<code><meta name="pinterest" content="nopin"/></code><br />
| [https://support.pinterest.com/entries/21101932-what-if-i-don-t-want-images-from-my-site-to-be-pinned Pinterest Help Article]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| rating <br />
| The Restricted to Adults label (RTA) provides a way for adult oriented websites to indicate that their content is off limits to children. RTA was introduced in 2006 and is currently used by a large number of adult web content providers. RTA is recognized by all major parental control filters.<br />
Example:<br />
<meta name="RATING" content="RTA-5042-1996-1400-1577-RTA" /><br />
| [http://www.rtalabel.org/index.php?content=howto RTA documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| referrer<br />
| Controls whether the user agent includes the Referer header in HTTP requests originating from this document<br />
| [http://wiki.whatwg.org/wiki/Meta_referrer Meta referrer]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| RepostUsAPIKey<br />
| Used to verify ownership of Website for Repost syndication service<br />
| [http://www.repost.us/meta-headers-used-by-repost/ Meta Headers used by Repost]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| ResourceLoaderDynamicStyles<br />
| [[mw:|MediaWiki]]'s [[mw:ResourceLoader|ResourceLoader]] uses this name with <code>content</code> set to the empty string. The purpose is to mark the DOM position before which dynamic styles should be added.<br />
| [[mw:ResourceLoader/ResourceLoaderDynamicStyles specification|ResourceLoaderDynamicStyles]]<br />
|<br />
| Proposal<br />
|-valign="top" <br />
<br />
| review_date<br />
| The date a resource is scheduled for review by content creator in order to determine if it should be archived, updated or retained as is.<br />
| [http://www.hc-sc.gc.ca/home-accueil/alt_formats/pacrb-dgapcr/pdf/Metadata_Application_Profile_2009.pdf Health Canada Web Metadata Application Profile March 2009 ]<br />
[http://lists.w3.org/Archives/Public/www-archive/2014Feb/att-0020/dnd_ims-6001-1-2-eng.pdf IMS 6001-1-2, Metadata for Recordkeeping and Web Content]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| revision<br />
| The revision of this page as reported by an underlying Version Control System. This is a free format string.<br />
| [https://github.com/krallin/meta-revision Meta Revision Specification]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| revisit-after<br />
| revisit-after is used to tell search engines how often to recrawl the page. To our knowledge only one search engine has ever supported it, and that search engine was never widely used — at this point, it is nothing more than a good luck charm.<br />
| [http://code.google.com/webstats/2005-12/metadata.html Google documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| rights-standard<br />
| The purpose is to enable search engines and other cataloging services to compile the types of rights allocated to the work. (Does any search engine actually implement this? [[User:Hsivonen|hsivonen]] 07:34, 14 July 2011 (UTC))<br />
<br />
'''This keyword does not provide, remove or alter any legal protections or designations.'''<br />
<br />
Format: <br />
<pre><meta name="rights-standard" content="element id;rights" /></pre><br />
<br />
* element id - the HTML Element ID of the item these rights apply to<br />
* rights - what rights are assigned to the item<br />
** "pd" - Public domain<br />
** "cc by-sa" - Creative Commons Attribution<br />
** "cc by-nd" - Creative Commons NoDerivs <br />
** "cc by-nc" - Creative Commons Attribution-NonCommercial<br />
** "cc by-nc-sa" - Creative Commons Attribution-NonCommercial-ShareAlike<br />
** "cc by-nc-nd" - Creative Commons Attribution-NonCommercial-NoDerivs<br />
<br />
| [http://sites.google.com/site/metarightsstandard/ Spec]<br />
|Redundant with [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#licensing-works Microdata vocabulary for licensing works].<br />
|Proposal<br />
<br />
|-valign="top" <br />
| robots<br />
| A comma-separated list of operators explaining how search engine crawlers should treat the content. Possible values are "noarchive" to prevent cached versions, "noindex" to prevent indexing, and "nofollow" works as the link rel value with the same name. This meta name is already supported by every popular search engine.<br />The content value "NOODP" has been offered elsewhere, so I'm proposing it here. It blocks robots from using [http://www.dmoz.org Open Directory Project] descriptions of a website instead of Web pages' own meta descriptions. It may have been introduced by Microsoft.<br />The content value "NOYDIR" has been offered by Yahoo, so I'm proposing it here. It blocks Yahoo's robot from using the Yahoo directory's descriptions of a website instead of Web pages' own meta descriptions. Whether any other robot supports this is unknown but possibly no other search engine uses Yahoo's directory anyway.<br />
| [http://www.robotstxt.org/wc/exclusion.html#meta Robots exclusion protocol], NOODP value: [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35264 Google], [http://help.yahoo.com/l/us/yahoo/search/indexing/indexing-11.html Yahoo], NOYDIR value: [http://ysearchblog.com/2007/02/28/yahoo-search-support-for-noydir-meta-tags-and-weather-update/ Yahoo], as accessed 4-28-09<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| rpuPlugin<br />
| Version of installed Repost syndication service plugin<br />
| [http://www.repost.us/meta-headers-used-by-repost/ Meta Headers used by Repost]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| rqid<br />
| Request identifier of request that generated this page.<br />
| [http://wiki.whatwg.org/wiki/RequestID RequestID]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| shareaholic:site_name<br />
| Used by Shareaholic social media plugin to learn more about your content and site.<br />
| [http://support.shareaholic.com/hc/en-us]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| signet:authors<br />
| Authors of a page for use with javascript signet library<br />
| [https://github.com/HubSpot/signet/blob/master/README.md Signet Revision Specification]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| signet:links<br />
| links to related pages, for use with the javascript signet library<br />
| [https://github.com/HubSpot/signet/blob/master/README.md Signet Revision Specification]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| skype_toolbar<br />
| Prevents the Skype browser extension from automatically seeking through the page and replacing telephone numbers (or any number the program's algorithm thinks is a telephone number) with its own custom presentation that allows direct invocation of the Skype program to call the telephone number.<br />
<br />
Example:<br />
<meta name="skype_toolbar" content="skype_toolbar_parser_compatible" /><br />
| [http://skype.otherlinks.co.uk/page.asp?id=toolbar_number_formatting Skype Info]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| slurp<br />
| Synonym of <code>robots</code> for targeting Yahoo! only.<br />
| [http://help.yahoo.com/l/au/yahoo7/search/indexing/indexing-11.html Yahoo! documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| startIndex<br />
| Used to identify the index of the first search result in the current set of search results.<br />
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| startver<br />
| Used to verify WebApps for JokeNetwork's Start!-WebApp<br />
| [https://jokenetwork.de/faq/start/verification/ JokeNetwork's Start Documentation]<br />
| <br />
| proposal<br />
<br />
|-valign="top" <br />
| teoma<br />
| Synonym of <code>robots</code> for targeting Teoma and Ask.com only.<br />
| [http://about.ask.com/en/docs/about/webmasters.shtml Ask.com documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| totalResults<br />
| Used to identify the number of search results available for the current search.<br />
| [http://www.opensearch.org/Specifications/OpenSearch/1.1#Response_metadata_in_HTML.2FXHTML OpenSearch Specification]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:card<br />
| The card type, which will be one of "summary", "photo", "app", or "player".<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:domain<br />
| the domain of the website (added w/ API 1.1)<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:url<br />
| Canonical URL of the card content.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:title<br />
| The title of the content as it should appear in the card.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:description<br />
| A description of the content in a maximum of 200 characters.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:name:iphone<br />
| Name of your iPhone app<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:name:ipad<br />
| Name of your iPad optimized app<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:name:googleplay<br />
| Name of your Android app<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:id:iphone<br />
| String value, should be the numeric representation of your app ID in the App Store.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:id:ipad<br />
| String value, should be the numeric representation of your app ID in the App Store.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:id:googleplay<br />
| String value, and should be the numeric representation of your app ID in Google Play.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:url:iphone<br />
| Your app's custom URL scheme.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:url:ipad<br />
| Your app's custom URL scheme.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:url:googleplay<br />
| Your app's custom URL scheme.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:app:country<br />
| If your application is not available in the US App Store, you must set this value to the two-letter country code for the App Store that contains your application.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image<br />
| A URL to the image representing the content.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image:height<br />
| The height of the image representing the content.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image:src<br />
| URL of image to use in the card. Image must be less than 1MB in size.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image:width<br />
| The width of the image representing the content.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image0<br />
| A URL to the image representing the first photo in your gallery.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image1<br />
| A URL to the image representing the second photo in your gallery.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image2<br />
| A URL to the image representing the third photo in your gallery.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:image3<br />
| A URL to the image representing the fourth photo in your gallery.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:site<br />
| @username for the website used in the card footer.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:site:id<br />
| Twitter ID for the website used in the card footer.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:creator<br />
| @username for the content creator / author.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:creator:id<br />
| Twitter ID for the content creator / author.<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:data1<br />
| String value; value for labels such as price, items in stock, sizes, etc<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:label1<br />
| String value; label such as price, items in stock, sizes, etc<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:data2<br />
| String value; value for labels such as price, items in stock, sizes, etc<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:label2<br />
| String value; label such as price, items in stock, sizes, etc<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:player<br />
| HTTPS URL to iframe player. This must be a HTTPS URL which does not generate active mixed content warnings in a web browser<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:player:width<br />
| Width of IFRAME specified in twitter:player in pixels<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:player:height<br />
| Height of IFRAME specified in twitter:player in pixels<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:player:stream<br />
| URL to raw stream that will be rendered in Twitter's mobile applications directly<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| twitter:player:stream:content_type<br />
| The MIME type/subtype combination that describes the content contained in twitter:player:stream<br />
| [https://dev.twitter.com/docs/cards Twitter cards documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| typemetal.formatprefs<br />
| Per-file HTML formatting preferences used by the TypeMetal HTML editor<br />
| [http://coherencelabs.com/typemetal/manual/typemetal-custom-metadata.html TypeMetal User Guide]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| verify-v1<br />
| Superseded by google-site-verification. Legacy verification for Google Sitemaps.<br />
| [http://sitemaps.blogspot.com/2006/05/more-about-meta-tag-verification.html Inside Google Sitemaps: More about meta tag verification]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| version<br />
| The version of a web application according to the [http://semver.org/ Semantic Versioning] specification<br><br />
Example:<br />
<code><meta name="version" content="0.1.0+1"></code><br />
| [https://github.com/dvorapa/meta-version Documentation]<br />
| deprecated `page-version` due to backward compatibility<br />
| Proposal<br />
<br />
|-valign="top"<br />
| vfb-version<br />
| Specifies a Visual Form Builder plugin version for Wordpress.<br />
| [http://wordpress.org/plugins/visual-form-builder/ Visual Form Builder Documentation and specs]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| <span id="viewport">viewport</span><br />
| Provides a way for documents to specify (using markup rather than CSS) the size, zoom factor, and orientation of the viewport that is used as the base for the document's [http://www.w3.org/TR/CSS21/visudet.html#containing-block-details initial containing block]. The following properties can be used in the value of the <code>content</code> attribute:<br />
* width<br />
* height<br />
* initial-scale<br />
* minimum-scale<br />
* maximum-scale<br />
* user-scalable<br />
Examples:<br />
<meta name="viewport" content="initial-scale=1.0"><br />
<meta name="viewport" content="width=480, initial-scale=2.0, user-scalable=1"><br />
| [http://dev.w3.org/csswg/css-device-adapt/#viewport-meta CSS Device Adaptation]<br />
|<br />
| Proposal<br />
<br />
|-valign="top"<br />
| web_author<br />
| Credits the developer(s) responsible for the technical design of a website.<br />
| [http://www.metatags.info/meta_name_webauthor Documentation]<br />
| [https://sites.google.com/site/metadesignerspec/ designer] - for visual presentation<br />
| Proposal<br />
<br />
|-valign="top" <br />
| wot-verification<br />
| Used to verify ownership of WOT (Web Of Trust)<br />
| [http://www.mywot.com/wiki/Verify_your_website WOT's verify your site wiki page]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.cg_n<br />
| '''Name of the Content Group'''<br />
Used to configure the appropriate Webtrends advanced feature. These are just some of the more popular ones. These appear in your META tags. – showing you the web page, the source (meta tag), the log files entry and the subsequent WT report.<br />
Example:<br />
<meta name="wt.cg_n" content="My content"><br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.cg_s<br />
| '''Name of Content Sub-Group'''<br />
Used to configure the appropriate Webtrends advanced feature. These are just some of the more popular ones. These appear in your META tags. – showing you the web page, the source (meta tag), the log files entry and the subsequent WT report.<br />
Example:<br />
<meta name="wt.cg_s" content="My content"><br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| WT.si_n<br />
| '''Scenario analysis parameter - scenario name'''<br />
This defines a scenario name for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends.<br />
Example:<br />
<meta name="WT.si_n" content="my_scenario_name"><br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| WT.si_p<br />
| '''Scenario analysis parameter - scenario step name'''<br />
This defines a scenario step name for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends. It works when paired with metedata tag name WT.si_n.<br />
Example:<br />
<meta name="WT.si_p" content="my_scenario_step_name"><br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| WT.si_x<br />
| '''Scenario analysis parameter - scenario step number'''<br />
This defines a scenario step number for the page or set of pages to be included in the scenario. This in turn produces a funnel type report in Webtrends. It works when paired with metedata tag name WT.si_n, and as an alternative to Wt.si_p.<br />
Example:<br />
<meta name="WT.si_x" content="my_scenario_step_number"><br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters].<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.ac<br />
| '''Advertising Click parameter'''<br />
When a visitor to your site clicks on an ad, that action is referred to as an Ad Click. The following META tag tracks advertising clicks:<br />
<META NAME="WT.ac" CONTENT="name"><br />
Defines the name of the advertisement clicked to reach a particular web page. The Ad Click must contain an external redirect back to the client. The redirect needs to include the necessary code to generate a hit to the SDC server. You can designate multiple Advertising Clicks using semicolons.<br />
Examples:<br />
<a href="file111.html?WT.ac=CONTENT111"><br />
<a href="file222.html?WT.ac=CONTENT222"><br />
The name of the advertisement clicked to reach a particular web page. To capture this information with DCS, the Advertising Click must contain an external redirect back to the client. The redirect needs to <br />
<br />
include the necessary code to generate a hit to the DCS. The maximum length for each name is 64 bytes.<br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.ad<br />
| '''Advertising View parameter'''<br />
Visitors often view advertisements that they do not necessarily click on. You can use On-Site Advertising to determine the number of visitors to your web site who view particular ads. With this feature you can produce advertising reports for each of your clients.<br />
If you are selling advertising space on your web site, for example, you can collect traffic statistics to help determine pricing schedules.<br />
The following META tag tracks advertising views:<br />
<meta name="WT.ad" content="My content"><br />
An Ad View occurs when a visitor views a page containing an ad. An ad is a link or graphic that contains an Ad Click parameter in the query portion of it's URL.<br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.mc_id<br />
| '''Identifies the ID of the marketing campaign'''<br />
To attract new students, a university launches a marketing campaign by sending recruitment email to all graduating high school seniors in a metropolitan area. The email links to a special landing page in the university’s web site, containing the following META tag to track marketing campaigns.<br />
Example:<br />
<META NAME="WT.mc_id" CONTENT="1X2GG34"><br />
You may use this parameter on the URL.<br />
Example:<br />
<a href="link?WT.mc_id=1X2GG34"><br />
The Campaign ID 1X2GG34 represents recruits to be contacted by email<br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.sv<br />
| '''Tracking Servers parameter'''<br />
If your site is hosted on multiple servers, a server cluster, or a server farm, and you want to evaluate the performance of your load balancer, Webtrends can track page views for each server. To do so, populate the following META tag on all pages on each server:<br />
Example:<br />
<meta name="WT.sv" content="My Server"><br />
Defines the name of the machine that serves the web page. If you have two servers (Server1 and Server2), you would make two copies of the META tag and designate CONTENT=“Server1” for deployment to pages on the first server and CONTENT=“Server2” for deployment to the same pages on the second server.<br />
For a server farm, you can extract the value of the built-in server name and dynamically assign it to the<br />
META tag using server-side scripting.<br />
Example:<br />
<meta name="WT.sv" content="Server1"><br />
<meta name="WT.sv" content="Server2"><br />
An Ad View occurs when a visitor views a page containing an ad. An ad is a link or graphic that contains an Ad Click parameter in the query portion of it's URL.<br />
| [https://tagbuilder.webtrends.com/Help/Miscellaneous/AdSearch.aspx?keepThis=true&TB_iframe=true&height=450&width=650 About WT.ad].<br />
| <br />
| Proposal<br />
<br />
|-valign="top"<br />
| wt.ti<br />
| '''Tracking Page Titles'''<br />
You may want to modify a page title before sending it to Webtrends in the following cases:<br />
* You are dealing with dynamic content pages identified by URL parameters, and the page title represents the title of the base URL page rather than the dynamic content page.<br />
Unless you modify the page titles, all pages have the same title in the reports.<br />
* All pages have been assigned the same title, for reasons of style or company policy.<br />
Even though URLs are displayed in addition to page title, the entire URL cannot be depended upon to distinguish one page from another.<br />
Use server-side scripts to change the title to something that reflects the content of the pages so that you can identify them in reports. Next, pass the customized page titles to Webtrends, using the following META tag:<br />
<META NAME="WT.ti" CONTENT="title"><br />
Defines the name of the title for this page.<br />
| [http://product.webtrends.com/WRC/OnDemand/ResourceCenter/rc/Library/PDF/IGOD/WebTrendsAnalyticsOnDemandImplementationGuide.pdf Webtrends Parameters]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| y_key<br />
| Used to verify ownership for Yahoo! Site Explorer<br />
| [http://help.yahoo.com/l/us/yahoo/search/siteexplorer/siteexplorer-06.html Yahoo! documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| yandex-verification<br />
| Used to verify ownership for Yandex Webmaster.<br />
| [http://help.yandex.ru/webmaster/?id=995300#995356 Yandex Webmaster ownership verification]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| ZOOMCATEGORY<br />
| Category of page to be grouped in Wrensoft Zoom Search Engine.<br />
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| ZOOMDESCRIPTION<br />
| Alternative page description for Wrensoft Zoom Search Engine.<br />
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| ZOOMIMAGE<br />
| URL to image to be displayed alongside result in Wrensoft Zoom Search Engine.<br />
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| ZOOMPAGEBOOST<br />
| Page boost factor to increase or decrease the relevance of page in Wrensoft Zoom Search Engine.<br />
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| ZOOMTITLE<br />
| Alternative page title for Wrensoft Zoom Search Engine.<br />
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| ZOOMWORDS<br />
| Additional keywords to be indexed for Wrensoft Zoom Search Engine.<br />
| [http://www.wrensoft.com/zoom/zoommeta.html Wrensoft Zoom Meta Documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| witget<br />
| Used to verify ownership for Witget.com.<br />
Example <meta name="witget" content="XXXXXXXXXXXXXXXXXXXXXX"><br />
| [http://support.witget.com/topic/435278-prostaya-ustanovka-skripta/ Witget manual]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSDateCreation<br />
| Mentions the date when this web page was created<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSDatePublish <br />
| Mentions the date when this web page was created<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSFLContent <br />
| Informs the Publisher tool whether this page contains any content or not. Valid values yes or no<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSLanguage <br />
| Language of the content in the page. Example: US English or UK English, etc<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSOnSitemap <br />
| Whether the page is accessible via the Sitemap link in the firmsite<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSPageDescription<br />
| Description of the content of page<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSSearchable<br />
| This tag mentions whether a certain page can be searched or not<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSWritertoolPageType<br />
| Page Type of a page in the firmsite. Page Type values help the Publisher toold in page creation<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSSection<br />
| Depicts whether a page is a Section Page or simple page. Section pages can have links to other pages<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FSPageName <br />
| Name of the page within a Findlaw firmsite<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|-valign="top" <br />
| FLBlogAuthor<br />
| Depicts whether author of the blog is lawfirm or FL author<br />
| [http://images.findlaw.com/firmsites/flfs_meta_tags.html FL Meta Names documentation]<br />
| <br />
| Proposal<br />
<br />
|}<br />
<br />
== Proposals that don't meet the [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names requirements] for a registration ==<br />
<br />
Note that these proposals can be moved back to the registry table if the problems listed in the rightmost column of this table are addressed.<br />
<br />
{| class="wikitable sortable"<br />
! Keyword<br />
! Brief description<br />
! Link to specification<br />
! Synonyms<br />
! Status<br />
! Registration requirement failure<br />
<br />
|-valign="top" <br />
| gm-gpx-v<br />
| Wordpress Plugin Google Maps GPX Viewer<br />
| [http://wordpress.org/extend/plugins/google-maps-gpx-viewer/ Google Maps GPX Viewer]<br />
| <br />
| Incomplete proposal<br />
| Claimed spec link is not a link to a spec<br />
<br />
|-valign="top" <br />
| og:title<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| og:type<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| og:url<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| og:image<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| og:site_name<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| fb:admins<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| og:description<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| fb:page_id<br />
| Open Graph Protocol by Facebook developers<br />
| [http://developers.facebook.com/docs/opengraph/ Facebook developers]<br />
| <br />
| Incomplete proposal<br />
| The spec specifies this to be a value of the property attribute--not a meta keyword<br />
<br />
|-valign="top" <br />
| audience<br />
| To aid search engines in classifying and to aid directory compilers, an audience most appropriate for the page may be suggested. Subject matter may not be a good clue; for example, an analysis of children's literature may be directed to teachers.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated. Singular and plural forms have the same meaning.<br />Recognized values:<br />-- "all" and "everyone", which have the same meaning<br />-- "adult" and "mature" have the same meaning and are for content that only adults may access, but no one responsible for preventing a nonadult or the immature from accessing the page or its content should rely on either or both of these values to do so without other means (not the same as "grownup", which see)<br />-- "child" and "juvenile", which have the same meaning<br />-- "teen"<br />-- "grownup" is not identical to "adult" or "mature" in not implying a precise boundary but is approximately any person who may be able to understand and apply the content (e.g., car driving instruction that may be read by a minor not yet old enough to drive a car but who would likely benefit from somewhat early exposure to the instruction)<br />-- "parent" to include guardian and temporary caregiver<br />-- "teacher" to include professor and ad hoc instructor<br />-- "elementary school student" to include any student below high school<br />-- "high school student"<br />-- "elhi" to include any student in elementary school through high school<br />-- "college student" including graduate and professional school<br />-- "business" including management, finance, and prospective customers (this includes e-commerce and investor sites)<br />-- "health" including any health care provider including alternative and ad hoc<br />-- "patient" for any health care recipient<br />-- "lawyer" including judge, paralegal, and jailhouse lawyer<br />-- "law client" for any prospective recipient of a lawyer's service (not usually a social work client) with ''lawyer'' including paralegal and jailhouse lawyer but not necessarily judge<br />-- "craft" for any craftworker including laborer and artisan<br />-- "artist" including musician, actor, dancer, and sculptor and including creator and performer<br />-- "military" including paramilitary<br />-- "news" including any consumer of rapidly-developing news<br />-- "introductory" and "beginner", which have the same meaning<br />-- "intermediate" and "midlevel", which have the same meaning<br />-- "advanced" and "advance", which have the same meaning<br />-- "scholarly" and "scholar", which have the same meaning<br />-- "popular" generally referring to a writing style<br />-- "older" including retiree<br />-- "institution" including from corporation to conspiracy (such as for management advice)<br />-- "government" including agencies and prospective politicians<br />-- values using any integer or single-digit decimal in the form of "grade 8" or "grade 6.4" including to refer to a reading comprehension level (this generally will not exceed 12 and might be meaningless above 20 so higher values may be interpreted as the highest meaningful value)<br />-- "viewers" for when content (such as a movie) is intended almost entirely to be seen rather than read<br />-- "listeners" for when content (such as music) is intended almost entirely to be heard rather than read but not generally including text-to-speech support<br />-- "tts", "text-to-speech", or "text to speech", which three have the same meaning and which are for a page that has substantial support for TTS or that will be readily understood through TTS without need for such support (TTS is often aided by, e.g., pre-resolving pronunciation ambiguities in page coding)<br />-- values using any numbers in the form of "3-6 years old", whether a range or a single-number value<br />-- values using any decade in the form of "born in 1970s"<br />Unrecognized values such as "botanists", "Texans", and "writers who use red ink" may be used but at a risk that a search engine or directory editor will either fail to recognize it or will interpret it in unpredictable ways, or will in the future.<br />Spellings that are erroneous or slightly different from a recognized value may be interpreted by a search engine or directory editor as representing a recognized value.<br />The absence of the keyword defaults to a value of "all" but without overriding another indication arrived at by other means.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| blogcatalog<br />
| Used to verify ownership of Blog Catalog.com<br />
| [http://www.blogcatalog.com/ Blog catalog site]<br />
| <br />
| Incomplete proposal<br />
| Claimed spec link is not a link to a spec<br />
<br />
|-valign="top" <br />
| bot-. . .<br />
| Robot owners, to allow page authors access to robotic capabilities, e.g., to deny them, should prefix "bot-" to the name of their robot, especially for proprietary bots.<br />Example: If a robot were to be named "dullbucklequiz", the name in the meta element would be "bot-dullbucklequiz".<br />The value "bot-" alone represents all bots so prefixed, like a wildcard.<br />Arguably, there's no need for a list here of any specific bots if http://user-agents.org or http://www.botsvsbrowsers.com/ (and perhaps other sites) is reliable.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec, tries to register a space of names instead of enumerated names<br />
<br />
|-valign="top" <br />
| created<br />
| The datetime at which the document was created. The value is an ISO8601 date. The date MUST follow the [http://www.w3.org/TR/NOTE-datetime W3C Profile of ISO 8601] with a granularity of "Complete date:" or finer. The [http://www.bbc.co.uk/guidelines/futuremedia/desed/previousversions/searchmetadata_vs_1_0.shtml#metadata BBC] use this name.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| creator<br />
| The creator is an off-Web or pre-Web creator of a work for which an author authored a Web page, so that the creator and the author may be different people.<br />Searching for one content creator's work requires a standard robot-parsable format for the information. A personal name, institutional name, or other text entry is permissible.<br />One element represents only one creator. Multiple creators are to be represented with multiple tags.<br />Search engines may index by any component of a name, so a content creator need only enter a name once in one first-last or family-given order (e.g., Pat Thunderbird or Thunderbird, Pat, but not requiring both).<br />
| [[Talk:MetaExtensions#Re:_Proposed_'creator'_MetaExtension|Talk]]<br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
<br />
|-valign="top" <br />
| msnbot<br />
| Synonym of <code>robots</code> for targeting Bing only.<br />
| <br />
| <br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| ia_archive<br />
| Synonym of <code>robots</code> for targeting Internet Archive and Alexa only.<br />
| <br />
| <br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| datetime-coverage<br />
| The author may be the best expert on which time frame is most relevant to the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers that may focus on the 1800s but mention 1731 and 1912 perhaps unimportantly.<br />The value for this keyword is a date or time -- not a range and not vague, for which other keywords are proposed -- in a format in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, all the values so appearing are determinative. Multiple values are to be expressed with separate meta elements lest the note be revised in the future in a way incompatible with comma-separating a list.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| property="og:*"<br />
| Metadata used by the Open Graph protocol (used by Facebook). Note: currently these are defined as: <meta property="og.*" content="x"/><br />
| [http://developers.facebook.com/docs/opengraph/ FAQ About the Open Graph protocol from Facebook.]<br />
| <br />
| Doesn't belong in this registry<br />
| Not a value to be used in the <code>name</code> attribute<br />
<br />
|-valign="top" <br />
| datetime-coverage-end<br />
| This is identical to the keyword datetime-coverage except that it represents only the end. If this keyword is used without datetime-coverage-start (also proposed), its value is interpreted as ending a range without a start.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the end of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-end=1865, datetime-coverage-start=1914, datetime-coverage-end=1918, and datetime-coverage-start=1862, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| datetime-coverage-start<br />
| This is identical to the keyword datetime-coverage except that it represents only the start. If this keyword is used without datetime-coverage-end (also proposed), its value is interpreted as starting a range without an end.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the start of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-start=1862, datetime-coverage-start=1914, datetime-coverage-end=1865, and datetime-coverage-end=1918, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| datetime-coverage-vague<br />
| This is identical to the keyword datetime-coverage except that its value is not necessarily crisp. This keyword should be used only when datetime-coverage, datetime-coverage-start, and datetime-coverage-end are inappropriate, but there's no ban on using all four. Any text without a comma can be the value (e.g., Pleistocene, 1820s, Tuesdays, or before we were born); multiple values are comma-separated.<br />If this keyword is used with datetime-coverage, datetime-coverage-start, or datetime-coverage-end, the vague value should be exploited along with the value/s for the other keyword/s.<br />Should this keyword appear more than once, all are determinative.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| DC.<br />
| Dublin Core, maintained by Dublin Core MetaData Initiative (DCMI), is an extensive system with some overlap with non-DC names.<br />This reserves all strings that begin with DC and a dot. ''Not true; DC-HTML doesn't use hardwired prefixes, but defines the prefixes using link/@rel="scheme.prefix"''<br />
| [http://www.DublinCore.org DCMI]<br />
| <br />
| Incomplete proposal<br />
| Tries to register a space of names instead of enumerated names<br />
<br />
|-valign="top" <br />
| dir-content-pointer<br />
| When several pages in a directory include main content, a table of contents, an index, and the like, a search engine may be able to organize results more usefully by identifying which is which with a standard vocabulary, helpful when different publishers use different conventions when displaying or printing content.<br />A value is free-form case-insensitive text without a comma and optionally with a trailing number. Multiple values are to be comma-separated (multiple values are appropriate when one document serves multiple purposes). Singular and plural forms have the same meaning.<br />Recognized values, which are pointer types to which numbers may be suffixed, are limited to "start" meaning 'the first page that should be seen by a user' (this may be anywhere in the directory and anywhere within content), "toc" meaning 'table of contents', "intro" including introductions, forewords, prefaces, and tables of figures, "abstract", "main", "bibliography" and "biblio", which have the same meaning, "index" which may mean 'sitemap' or not, "afterword" and "update" which have the same meaning and need not actually update, "credit" meaning 'credits and acknowledgments', and "author bio" meaning 'author's biography', including any information about the author including credentials and contact information. The number suffix may be spaceless or not.<br />When numbers are suffixed, a search engine or directory should arrange like items in numerical order in the results, with unnumbered items following like items that are numbered, e.g., intro 1, intro 2, main 1, main 2, main, main, and so on.<br />Each directory and each subdirectory has its own sequence.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top"<br />
|expires<br />
|<code>meta name='expires'</code> defines the expiration date of the page. This can be used for web pages in preparation for an upcoming event, e.g. a registration form for an exposition or competition, or other cases with a pre-set date when the document will no longer be valid, e.g. a product offer in a special sale or a support page for a product known not to be supported anymore from a given time onward.<br />
<br />
Search engines should respond to this meta tag in a reasonable way, i.e. by removing the page from their main search results after the expiration date (possibly still returning the result in a special search for expired pages as long as the page exists and is not explicitly excluded via <code>robots.txt</code> or <code>meta name='robots'</code> etc.) or simply by indicating to the user that this result is out-of-date.<br />
<br />
The content attribute should define the expiration date in accordance with http://www.w3.org/TR/NOTE-datetime . The meta tag should not be used for pages without expiration date. However, for historical reasons, search engines should also interpret other date formats where possible and should be prepared to find values such as "", "0", "no" and "never". Such non-date values are to be interpreted as no expiration date.<br />
<br />
Correctly formatted example:<br />
<code><pre><meta name='expires' content='2012-12-31T23:59Z'></pre></code><br />
<br />
This tag is not to be confused with and has a different meaning than <code>meta http-equiv='expires'.</code><br />
|<br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| format-print<br />
| This is to allow a user agent to inform an operating system or a printer driver of the preferred print medium, such as the paper size.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated (multiple values might be appropriate because standard paper sizes vary around the world). Singular and plural forms have the same meaning.<br />Recognized values are limited to "letter", "A4", "legal", "A5", "B5", "monarch", "envelope 10" meaning size #10, "envelope 6-3-4" meaning size #6 3/4, values with integers and decimals in the form of "8.5 x 11" or "8.5x11" in which spacing of the "x" does not affect meaning, "paper", which means 'paper of the default color (usually white) and weight (usually 20-lb. stock)', "white", "yellow", "pink", "blue", "green", "violet", or "multicolor", which means a medium of the given color or mixed, "letterhead", "p2 letterhead" meaning 'letterhead intended for any page except the first', "watermark" meaning a 'special watermark such as an organization's own', and "plain" meaning 'not preprinted and not letterhead (it may have a paper manufacturer's watermark not related to letterhead)'.<br />Omitting "paper" when another recognized value is given defaults to an implied meaning of 'paper' with the other value; e.g., "letter" means 'letter paper'; the same principle applies to a medium's color (the default being white for paper and colorless for transparency) and plainness or lack thereof (the default being plain).<br />Other values should be proposed before being recognized here. Label sizes should be proposed here for labels that are not on backing sheets that fit one of the recognized values, e.g., labels on narrow rolls. Blueprint paper sizes should be proposed here. Media other than standard paper, such as onion skin, heavier paper, card, and clear or color transparency, should be proposed here.<br />The user agent may, with the user's or user sysadmin's permission (as by a menu-driven default), interpret a value to offer an alternative the user might accept and software and firmware other than the UA may interpret a value to the same end with or without permission, so this keyword is only suggestive; e.g., "letter" may be interpreted as "A4".<br />The absence of the keyword defaults to a value determined by other than the page, e.g., by the printer driver or the user agent.<br />
| [[Talk:MetaExtensions#Re:_Proposed_'format-print'_MetaExtension|Talk]]<br />
| <br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| geographic-coverage<br />
| The author may be the best expert on the geographic relevance of the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers and epidemiological studies which may mention locales only once.<br />Absence of the keyword defaults to a value of world (not universe), unless the search engine chooses to interpret the page or larger unit for some other value, probably based on other than just contact information given in the website.<br />The value for this keyword is a semicolon-separated list of one or more place-values, the order of which do not matter. One place-value will use commas to separate, in order, an optional standard natural language symbol applicable to the place-value (when omitted the language applicable to the page will control), a place-class, one or more place-subclasses if any, and one or more place name parts (where, e.g., in "Cape Town, South Africa", "Cape Town" is a place name part but "Town" is not). Spaces after semicolons and commas are optional; spaces within place-values are present when required for each place-value (e.g., "Quezon City", not an invented "QuezonCity").<br />To distinguish names that might otherwise be too similar, place-classes, all lower-case and hyphenatably spaceless, include ''outer-space'', ''region'' (on Earth and crossing or larger than a nation, e.g., southern hemisphere, polar region, temperate zone, or Asia), ''intntl-water'' (an 'international water body'), ''intntl-agcy'' ('international agency' or 'international collection', e.g., all U.N. member nations), ''nation'', ''within-nation'' (limited to only one political level down from nation, e.g., state, province, territory, possession, city not included within other political units of a nation, or any comparable unit), ''city'' (including town, village, hamlet, and any comparable political unit below the level of ''within-nation''), ''addr'' (including address, full-length street, building, institution, and neighborhood without political boundaries), ''pol-unit'' (''pol'' abbreviating 'political') (e.g., a place of disputed nationhood), ''hist-pol-unit'' (''hist'' abbreviating 'historical') (e.g., the Roman Empire), ''feature'' (e.g., river), ''num'' (e.g., latitude and longitude or outer-space equivalent in numbers), and ''ethereal'' (including thealogical/theological, fictional including from modern popular entertainment, and ancient secular mythical, but not including that which is asserted to be a state of mind or existence but not a place, such as nirvana). (Example for one hypothetical page: name="geographic-coverage" content="region, sub-Saharan Africa; nation, Panama; city, Panama, Panama; within-nation, Sao Paulo, Brazil; city, Sao Paulo, Sao Paulo, Brazil; within-nation, Mississippi, United States of America; region, Middle East; region, Midwest, United States of America; hist-pol-unit, Northwest Territory, United States of America; feature, river, Indus; outer-space, Indus; ethereal, ultima Thule; ethereal, Heaven; ethereal, Flatland; ethereal, Valhalla; en-US, addr, Hotel Valhalla, Fredrikstad, Norway; es, nation, Espana" (Indus is both a river and a constellation, illustrating the need for place-classes)).<br />Ambiguity of place-values should be avoided despite convenience in coding because search engines may each interpret them as they see fit, e.g., it would be hard for an engine to distinguish New York from New York.<br />For consistency of spelling, several authority lists should be settled upon, with legal, well-known, and disputed names and common abbreviations all being acceptable; but I'm not proposing one here now (relying on IANA's ccTLD list might be too complex to implement and still assure coding consistency, e.g., occasionally ccTLDs can be phased out and off of IANA's list) (a standard vocabulary possibly usable here is the [http://www.getty.edu/research/conducting_research/vocabularies/tgn/index.html Getty Thesaurus of Geographic Names Online], subject to licensing and charset choice); and promulgating authority lists may best be done publicly by search engine managements, who may disagree with each other.<br />Allowing Unicode for non-Roman alphabet-using locales is desirable, but at present that may raise technical problems, including computer security issues, that are not yet readily soluble.<br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| google-translate-customization<br />
| Used to verify ownership for Website Translator. <meta name="google-translate-customization" content="Your Website Code Goes Here. Generated When Adding The Google Translate Plugin To Your Site" /><br />
| <br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| keywords-not<br />
| A comma-separated list of negative keywords that distinguish a closely-related theme from this page's true theme, to support Boolean NOT searches often more realistically than visible text can, especially when both themes share the same lexicon.<br />If keywords is no longer a supported name for a meta element, keywords-not is superfluous; however, debate has been revived on whether keywords should be supported or not; see the keywords entry in this Wiki.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6609 W3C Bug 6609]<br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| nextgen<br />
| Used for nextgen gallery plugin in wordpress<br />
| [http://www.alexa.com/faqs/?p=188 Alexa FAQ About this meta attribute Reference]<br />
| <br />
| Incomplete proposal<br />
| Unrelated spec link<br />
<br />
|-valign="top" <br />
| page-datetime<br />
| Better ranking in search engine results for recency or relevance to an event date would be aided by a standard format robots can parse. Users would save search time by not having to load many pages to find which ones are new or date-relevant.<br />To supply a consistent and known format, the value for this keyword is a date-time expression formed in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />
| <br />
| <br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| page-version<br />
| Pages may be revised several times daily. While date-time given to a granularity of a fraction of a second would often suffice, when a page has to be approved more than once before posting, any or no such time may be correct (without this keyword, a comment could be necessary but probably not parsable by an engine). In addition, versions regardless of date may show consecutiveness and can replace a date that must be vague. In that case, a version number may be more useful for searches and so a robot-parsable format is needed.<br />The keyword's value is stated in ASCII digits, is any nonnegative base-10 rational number expressed as an integer or a decimal, with any number of decimal places allowed, and may be padded with any number of leading zeros to support extraction for ASCII sorting.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />The versions 0 and 0.''n'', with ''n'' being to any number of places, signify beta versions, i.e., drafts, in the tradition of beta software, while versions 1 and higher ordinarily signify final-release versions. After a final-release version is released, a draft of a later version is not given a version number of 0 or 0.''n'', but is numbered higher than the last final-release version. It is suggested to page authors that draft status, if applicable, be shown in the visibly displayed text of the page, rather than that this meta tag be relied upon as the sole notice of draft status, as it may be inadequate notice if alone.<br />To assign a low page-version such as 0.''n'' or 1, the page's URL, if static, may be used as the relevant premise. Thus, if a page is copied or moved to a new URL, the author may choose to restart page-version numbering from 0.''n'' or 1. If a page's URL is dynamic, e.g., if created on the fly from a script, the page author may prefer to use as the relevant premise for assigning a low page-version such as 0.''n'' or 1 the URL of the script or other technology that generates the dynamic-URL page, placing this meta element containing this attribute within the script or other technology, not within the generating page's head element (the generating page's head element may have its own meta element with this attribute describing the generating page). If one page containing the script or other technology that generates another page has more than one means for generating dynamic-URL pages, each means should contain its own meta element with this attribute. Page-version is thus largely independent of the page's date, although both would likely advance roughly in parallel.<br />
| <br />
| <br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| resolutions<br />
| Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.<br />
<br />
To accomplish this, I propose a new HTML Meta Tag, <code>resolutions</code>, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page. <br />
<br />
So, for example…<br />
<br />
<code><pre><meta name="resolutions" content="2x"></pre></code><br />
<br />
… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix. <br />
<br />
To illustrate, if her image tag is as follows…<br />
<br />
<code><pre><img src="/images/flower.jpg" alt="A flower"></pre></code><br />
<br />
… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg. <br />
<br />
(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)<br />
<br />
Based on the meta tag, if the browser detects that the user is running at a <code>min-device-pixel-ratio</code> of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag. <br />
<br />
Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.<br />
<br />
<b>Multiple resolutions</b><br />
<br />
The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future. <br />
<br />
For example:<br />
<br />
<code><pre><meta name="resolutions" content="2x, 4x, 8x"></pre></code><br />
<br />
In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.<br />
<br />
<b>Advantages</b><br />
<br />
The advantages of this approach are several:<br />
<br />
<ol><br />
<li>Makes it very simple for developers to support high-resolution displays like the iPhone 4's Retina screen</li><br />
<li>Does not require JavaScript</li><br />
<li>Does not change the default way that things work (if the meta tag is not specified, the browser simply behaves as it always has).</li><br />
</ol><br />
<br />
| [http://aralbalkan.com/3355 Proposal for native browser support of high-resolution image substitution]<br />
[http://aralbalkan.com/3331 How to make your web content look stunning on the iPhone 4’s new Retina display]<br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| rights<br />
| As a page effectively appears in at least two forms, usually one as interpreted and displayed on a device and the other as source code, arguably intellectual property rights that must be asserted must be asserted in ways understandable in both contexts. For example, &amp;copy; is a raw representation that may legally fail as part of copyright notice to someone seeing source code and not the display, important when someone wants to copy source code for use elsewhere and may rely on a defense of innocent infringement (at least in U.S.). While such assertions can be made in a comment element, it may be helpful to have a tag that search engines can parse and index verbatim.<br />The value may include standard and nonstandard notices, invocations of licenses such as GFDL and ASCAP, and any other information. Content is defined as free-form, leaving the page author discretion for the entry.<br />Statements in one tag may discuss several portions of the page differently, e.g., with different licenses.<br />More than one license may be offered, along with the page's relationship to all.<br />Not all statements need be license grants. A statement may state whom to ask for reprint permission or may reserve all rights, for example.<br />Only one meta tag with this keyword may be present. Page authors must not use more than one. A UA finding multiple such tags on one page must ignore all of them.<br />The copyright symbol that would be generated by its character entity is not recommended for legal notice in source code when the word 'Copyright' may be used instead, because the entity may be read in raw form, but use is up to the page author. The same concept applies to any intellectual property rights symbol for which a suitable alternative is available, such as for trademark or service mark.<br />ASCII text would not suffice when a name or notice legally may have to be in a non-Roman alphabet, but no alternative may yet exist in HTML5.<br />Search engine storage may impose a length limit, but, because of legal consequences, if the value's length exceeds a given limit the search index should retain or interpret none of it but only refer to it.<br />The content string may only be copied verbatim in its full length, referred to, or ignored. It may not be, for example, paraphrased, truncated, interpreted, or classified except in addition to being copied verbatim in its full length.<br />Ignoring shall not void, nullify, or alter any rights stated in such tag.<br />For the synonymy, ''IP'', ''IP-rights'', and ''IP-right'' are not reserved; while the abbreviation ''IP'' 'intellectual property' is common among attorneys in the U.S., page authors will more likely be computerate, and the abbreviation may be wanted for 'Internet Protocol'.<br />
| [[Talk:MetaExtensions#rights:_why_reversion|Talk]]<br />
|<br />
| Incomplete proposal<br />
| Lacks link to a spec<br />
<br />
|-valign="top" <br />
| subj-. . .<br />
| To classify by subject a page's content, a standard subject taxonomy that will be recognized by a search engine or directory will help. Because many such high-quality taxonomies exist, only a prefix is proposed. Over time, particular taxonomies, in print or online, may be recognized here and keywords assigned for each.<br />The keyword will be constructed case-insensitively with subkeywords in the form subj-[nationAbbrev]-[taxonomy]-[edition][-optionalSubedition], e.g., subj-US-MeSH-2009online (perhaps). After "subj-", the second subkeyword will identify the nation where the taxonomy is published or offered as an aid in identifying the taxonomy and does not limit the subject coverage; e.g., a taxonomy published in Japan may be ideal for classifying Canadian botany or Peruvian economy.<br />As subject values may vary between editions of one taxonomy, an edition and optionally a subedition is to be identified in the third and optionally the fourth subkeywords. The subedition, if any, is any update or revision occurring between editions, such that a value drawn from that edition and subedition is stable. The means of identifying edition and subedition should be included in the registration of a keyword.<br />Examples of taxonomies from the U.S. include MeSH (medical) and the Library of Congress Subject Headings.<br />The value identifying a subject for a Web page will be drawn from the cited taxonomy's edition and subedition.<br />If the value should have a style to prevent ambiguity in interpretation, that style is to be registered here for that keyword. Multiple values are expressed with multiple meta elements, one value for each, since comma-separation is probably not compatible with all taxonomies.<br />If a value requires case-sensitivity to prevent confusion, the entry here registering the keyword must accommodate that need with the needs of HTML 5 with an appropriate rule. To that end, a proposal to allow case-sensitivity in meta tags under some circumstances has been offered in the W3C bug reporting system.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854 W3C Bug 6854]<br />
| subject-. . .<br />
| Incomplete proposal<br />
| Lacks link to a spec, tries to register a space of names instead of enumerated names<br />
<br />
<br />
|-valign="top" <br />
| nibbler-site-verification<br />
| Used to verify ownership of Nibbler site<br />
| [http://nibbler.silktide.com/ Nibbler site]<br />
| <br />
| Incomplete proposal<br />
| Claimed spec link does not link to a spec<br />
<br />
|-valign="top" <br />
| MSSmartTagsPreventParsing<br />
| Microsoft introduced into Internet Explorer 6 Beta a feature that some website designers wished to preclude from applying in order to prevent public misunderstanding of their websites. The feature allowed a browser to add information but at a risk that users wouldn't know that it wasn't supplied by the website. This keyword was provided by Microsoft for those of us who wanted it.<br />Its value was "TRUE". Microsoft spelled the keyword with some capitals and the value in all capitals but whether capitalization was required for either is unknown; some opinions vary. Since it need be understood by only one browser, and that one a beta version, full standards compliance should not be assumed, and original case may be required. (This tag is used by Google: "<meta content='true' name='MSSmartTagsPreventParsing'/>" appeared (with internal quote marks as singles) in the source code for <http://googleblog.blogspot.com/2009/04/listening-to-google-health-users.html>, as accessed 4-27-09.)<br />Microsoft has apparently removed this instruction from its website on the ground that the beta version is no longer available and is not supported, but that doesn't assure that some users aren't still using the beta browser, perhaps inadvertently. Therefore, designers may wish to continue using the keyword and value and they are preserved here.<br />
| e.g., [http://www.theregister.co.uk/2001/06/25/web_sites_banish_those_winxp/ The Register (U.K.)], [http://cc.uoregon.edu/cnews/summer2001/summer2001.pdf Univ. Oregon (U.S.) (PDF p. 18)], & [http://trillian.mit.edu/~jc/demo/SmartTagsOff.html John Chambers (U.S.) (job résumé near root)], all as accessed 4-19-09<br />
| <br />
| Incomplete proposal<br />
| Lacks spec, potentially never minted by MS as a meta name (as opposed to a http-equiv value), even if minted by Microsoft, abandoned before shipping in any final release of IE<br />
<br />
|}<br />
<br />
== Failed Proposals ==<br />
<br />
{| class="wikitable sortable"<br />
! Keyword<br />
! Brief description<br />
! Link to more details<br />
! Synonyms<br />
! Status<br />
<br />
|-valign="top" <br />
| cache<br />
| This doesn't actually work; use HTTP headers instead.<br />Value must be "public", "private", or "no-cache". Intended as a simple way to tell user agents whether to store a copy of the document or not. An alternate for HTTP/1.1's cache-control; for publishers without access to modifying cache-control.<br />
| none<br />
| <br />
| Unendorsed<br />
<br />
|-valign="top" <br />
| no-email-collection<br />
| HTML5 prohibits URL-valued meta names. They should be rel keywords instead.<br />Intended to reference legal policy of web site indicating that harvesting of e-mail addresses on the site is not permitted and in violation of applicable laws such as the CAN-SPAM Act of 2003.<br />
| [https://www.ProjectHoneyPot.org/how_to_avoid_spambots_5.php Project Honey Pot]<br />
| <br />
| Unendorsed<br />
<br />
|}<br />
<br />
== Process ==<br />
<br />
The process for this page is being discussed on the whatwg@whatwg.org mailing list as we speak. Contribute to the discussion!<br />
<br />
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0097.html<br />
[[Category:Registries]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=9629MicrosyntaxDescriptions2014-06-28T17:57:18Z<p>Zcorpan: /* source-size-list */</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML5 microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [http://www.whatwg.org/specs/web-apps/current-work/ WHATWG version of HTML 5] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki], or must be an absolute URL. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [http://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>.<br />
<br />
==language==<br />
An [http://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [http://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a '''media type''' and zero or more expressions that check for the conditions of particular '''media features'''. A media type is one of the following: '''all''', '''braille''', '''embossed''', '''handheld''', '''print''', '''projection''', '''screen''', '''speech''', '''tty''', or '''tv'''. ''Note: The '''aural''' media type is deprecated''. For information about valid media features and about the exact syntax of media queries, see the [http://dev.w3.org/csswg/css3-mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [http://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [http://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [http://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [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].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes (&lt;media-condition> &lt;length>) optionally followed by a default size (&lt;length>) but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but '''commas must not be used to separate commands''', though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-month-string month], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-date-string date], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-time-string time], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-week-string week], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=MicrosyntaxDescriptions&diff=9628MicrosyntaxDescriptions2014-06-28T17:53:37Z<p>Zcorpan: /* source-size-list */</p>
<hr />
<div>The purpose of this page is to enable collaborative creation of brief advisory text for each HTML5 microsyntax so that when the content of an attribute value or the text content of an element does not conform to a given microsyntax, a validator can display the advisory text about the syntax to guide the author to fix the content. Note that like the rest of this wiki, editing requires you to agree to release your contributions under the MIT license (see wiki footer). Please note that while copying text from the [http://www.whatwg.org/specs/web-apps/current-work/ WHATWG version of HTML 5] is OK, copying text from RFCs or W3C specs is not OK.<br />
<br />
Note that some formats pertain to Web Forms 2.0 (e.g. <code>datetime-local</code>).<br />
<br />
Please keep descriptions short: one paragraph in length.<br />
<br />
==a-rel==<br />
A whitespace-separated list of link types, with no duplicate keywords in the list. Each link type must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> in the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes HTML specification], or must be listed as allowed on <code>&lt;a&gt;</code> and <code>&lt;area&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki], or must be an absolute URL. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==browsing-context==<br />
A browsing context name is any string that does not start with an underscore (<code>_</code>).<br />
<br />
==browsing-context-or-keyword==<br />
A browsing context name or keyword is either any string that does not start with an underscore (<code>_</code>) or a string that case-insensitively matches one of: <code>_blank</code>, <code>_self</code>, <code>_parent</code>, or <code>_top</code>.<br />
<br />
==cdo-cdc-pair==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>".<br />
<br />
==charset==<br />
An preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8</code><br />
<br />
==charset-list==<br />
A whitespace-separated list of preferred encoding names according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>utf-8 windows-1252</code><br />
<br />
==circle==<br />
A circle is specified as three comma-separated (no spaces allowed) integers the last one of which is non-negative. An integer consists of one or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). Examples of circles: <code>5,5,10</code> and <code>-5,0,20</code><br />
<br />
==date==<br />
A date in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code>. Example: <code>2002-09-29</code>.<br />
<br />
==date-or-time==<br />
A [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-date-or-time-string date or time string]; that is, one of the following:<br />
a <b>date</b>, which must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • or, a <b>time</b>, which must begin in the form <code><i>hh</i>:<i>mm</i></code>, and can optionally be followed by <code>:<i>ss</i></code>, which in turn can optionally be followed by “<code>.</code>” and one or more digits • or, a <b>date</b>, followed by “<code>T</code>”, followed by a <b>time</b>, followed by <b>time-zone information</b>, which must be either “<code>Z</code>”, or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01</code>, <code>12:05:25</code>, <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25.6</code> • <i>Note: The validator currently allows some values that the HTML specification prohibits; for example, it allows <code>1996-01-01T12:05:25</code> (a date and time with no time-zone information) and <code>12:05:25Z</code> (a time with no date but with time-zone information).</i><br />
<br />
==datetime==<br />
An ISO 8601 date and time in the UTC time zone, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one, two, or three digits for the fraction of a second, and finally followed by <code>Z</code>. Examples: <code>1996-01-01T12:05Z</code>, <code>1996-01-01T12:05:25.6Z</code>.<br />
<br />
==datetime-local==<br />
An ISO 8601 date and time with no time zone information, i.e. <code><i>YYYY</i>-<i>MM</i>-<i>DD</i>T<i>hh</i>:<i>mm</i></code> optionally followed by <code>:<i>ss</i></code> for the seconds, optionally followed by <code>.</code> and one or more digits for the fraction of a second. Examples: <code>1996-01-01T12:05</code>, <code>1996-01-01T12:05:25.6</code>.<br />
<br />
==datetime-tz==<br />
A [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time string]; that is, a <b>date</b>, followed by a “<code>T</code>” or a single space, followed by a <b>time</b>, followed by <b>time-zone information</b>, where: the <b>date</b> must be in the form <code><i>YYYY</i>-<i>MM</i>-<i>DD</i></code> • the <b>time</b> must begin in the form <code><i>hh</i>:<i>mm</i></code>, followed by <code>:<i>ss</i></code>, optionally followed by “<code>.</code>” and one, two, or three or digits • the <b>time-zone information</b> must be either “<code>Z</code>” or in the form <code>+<i>hh</i>:<i>mm</i></code> or the form <code>-<i>hh</i>:<i>mm</i></code> • Examples: <code>1996-01-01T12:05:25-02:00</code>, <code>1996-01-01T12:05:25Z</code><br />
<!-- • <i>Note: The validator currently prohibits some values that the HTML specification allows; for example, the HTML specification allows <code>1996-01-01T12:05Z</code> (a date and time string with no seconds specified), but the validator prohibits it.</i> --><br />
<!-- (''[http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder/microsyntaxes-dates This format deviates from the spec draft.]'') --><br />
<br />
==email==<br />
An e-mail address must match the <code>addr-spec</code> production defined in [http://tools.ietf.org/html/rfc2822#section-3.4.1 RFC 2822 section 3.4.1] excluding the <code>CFWS</code> production everywhere and excluding the <code>FWS</code> production everywhere except in the <code>quoted-string</code> production.<br />
<br />
==float==<br />
First, optionally, <code>-</code> (U+002D). Then, a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>-42.42E+42</code> is valid but <code>.5</code> or <code>+2</code> are not.<br />
<br />
==float-non-negative==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. Or, alternatively to the foregoing: First, <code>-</code> (U+002D). Then, a series of one or more zeros. Then, optionally, a single <code>.</code> (U+002E) followed by one or more zeros. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> and <code>-000.000</code> are valid but <code>.5</code> or <code>-0.01</code> are not.<br />
<br />
==float-positive==<br />
A series of one or more characters in the range <code>0</code>…<code>9</code>. Then, optionally, a single <code>.</code> (U+002E) followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. One of the digits so far has to be non-zero. Then, optionally, either <code>e</code> or <code>E</code>, optionally followed by <code>-</code> (U+002D) or <code>+</code> (U+002B), followed by a series of one or more characters in the range <code>0</code>…<code>9</code>. For example, <code>42.42E+42</code> is valid but <code>0.0</code> or <code>-2</code> are not.<br />
<br />
==hash-name==<br />
A <code>#</code> (number sign) character followed by any string.<br />
<br />
==ID==<br />
An ID consists of at least one character but must not contain any whitespace.<br />
<br />
==image-candidate-strings==<br />
A comma-separated list of strings, each of which consists of a URL optionally followed by either a pixel density descriptor or a width descriptor.<br />
<br />
==image-candidate-strings-width-required==<br />
A comma-separated list of strings, each of which must consist of a URL followed by a width descriptor.<br />
<br />
==integer==<br />
One or more digits (<code>0</code>–<code>9</code>), optionally preceded by a hyphen (<code>-</code>). For example: <code>42</code> and <code>-273</code> are valid, but <code>+42</code> is not.<br />
<br />
==integer-non-negative==<br />
One or more digits (<code>0</code>–<code>9</code>). For example: <code>42</code> and <code>0</code> are valid, but <code>-273</code> is not.<br />
<br />
==integer-positive==<br />
One or more digits (<code>0</code>–<code>9</code>), with at least one which is non-zero. For example: <code>42</code> is valid, but <code>00</code> is not.<br />
<br />
==iri==<br />
An absolute URL. For example: <code><nowiki>http://</nowiki>example.org/hello</code>, but not <code>/hello</code>. Spaces should be escaped as <code>%20</code>.<br />
<br />
==iri-ref==<br />
Any URL. For example: <code>/hello</code>, <code>#canvas</code>, or <code><nowiki>http://</nowiki>example.org/</code>. Characters should be represented in [http://www.macchiato.com/unicode/nfc-faq NFC] and spaces should be escaped as <code>%20</code>.<br />
<br />
==language==<br />
An [http://tools.ietf.org/html/rfc5646 RFC 5646] language tag consists of hyphen-separated ASCII-alphanumeric subtags. There is a primary tag identifying a natural language by its shortest ISO 639 language code (e.g. <code>en</code> for English) and zero or more additional subtags adding precision. The most common additional subtag type is a region subtag which most commonly is a two-letter ISO 3166 country code (e.g. <code>GB</code> for the United Kingdom). IANA maintains a [http://www.iana.org/assignments/language-subtag-registry registry of permissible subtags].<br />
<br />
==link-rel==<br />
A whitespace-separated list of link types listed as allowed on <code>&lt;link&gt;</code> in the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes HTML specification] or listed as an allowed on <code>&lt;link&gt;</code> on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] without duplicate keywords in the list. <strong>You can register link types on the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Microformats wiki] yourself.</strong><br />
<br />
==media-query==<br />
One or more media queries, combined in a comma-separated list. Each media query consists of a '''media type''' and zero or more expressions that check for the conditions of particular '''media features'''. A media type is one of the following: '''all''', '''braille''', '''embossed''', '''handheld''', '''print''', '''projection''', '''screen''', '''speech''', '''tty''', or '''tv'''. ''Note: The '''aural''' media type is deprecated''. For information about valid media features and about the exact syntax of media queries, see the [http://dev.w3.org/csswg/css3-mediaqueries/ Media Queries] specification.<br />
<br />
==meta-charset==<br />
The string <code>text/html;</code>, optionally followed by whitespace, followed by <code>charset=</code>, followed by a preferred encoding name according to the [http://encoding.spec.whatwg.org/ Encoding Standard]. Example: <code>text/html; charset=utf-8</code><br />
<br />
==meta-name==<br />
A metadata name listed in the [http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#standard-metadata-names HTML specification] or listed in the [http://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki]. <strong>You can register metadata names on the [http://wiki.whatwg.org/wiki/MetaExtensions WHATWG wiki] yourself.</strong><br />
<br />
==mime-type==<br />
A [http://tools.ietf.org/html/rfc2616#section-3.7 media-type as defined in RFC 2616]; that is, typically, a required ''type'', followed by a "<code>/</code>" character, followed by a required ''subtype'', optionally followed by one or more instances of a "<code>;</code>" character followed by a ''parameter''. Examples: <code>text/css</code>, <code>text/css;charset=utf-8</code>.<br />
<br />
==mime-type-list==<br />
(WF2)<br />
<br />
==month==<br />
An ISO 8601 date with year and month, i.e. <code><i>YYYY</i>-<i>MM</i></code>. Example: <code>2007-11</code>.<br />
<br />
==non-empty-string==<br />
Any string that is not the empty string.<br />
<br />
==pattern==<br />
(WF2)<br />
<br />
==polyline==<br />
...<br />
<br />
==ratio==<br />
(progress content)<br />
<br />
==rectangle==<br />
...<br />
<br />
==script==<br />
Any text content that does not contain the character sequence "<code>&lt;!--</code>" without a later occurrence of the character sequence "<code>--></code>" and that does not contain any occurrence of the string "<code>&lt;/script</code>" followed by a space character, "<code>></code>", or "<code>/</code>". For further details, see [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].<br />
<br />
==script-documentation==<br />
Zero or more ''code comments'', each of which is either a single-line comment starting with "<code>//</code>" or a multi-line comment starting with "<code>/*</code>" and ending with "<code>*/</code>". The content must also meet the constraints of the [http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions#script script] microsyntax. For further details, see [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#inline-documentation-for-external-scripts Inline documentation for external scripts].<br />
<br />
==simple-color==<br />
A string of seven characters that starts with <code>#</code> and ends with six characters each of which is <code>0</code>…<code>9</code>, <code>a</code>…<code>f</code> or <code>A</code>…<code>F</code>.<br />
<br />
==source-size-list==<br />
A comma-separated list of zero or more source sizes optionally followed by a default size but at least one of them.<br />
<br />
==string-without-line-breaks==<br />
Any string that does not contain the carriage return character or the line feed character.<br />
<br />
==svg-pathdata==<br />
A list of zero or more path-data expressions, where each expression consists of a one-letter command followed by numbers that serve as arguments for the command (in most cases, pairs of coordinates). Commas and/or whitespace must be used to separate the arguments for a command from one another—but '''commas must not be used to separate commands''', though whitespace can optionally be used to do so. Examples: "<code>M 100 100 L 300 100 L 200 300 z</code>" or "<code>M100,100L300,100,200,300z</code>". For more information, see the [http://www.w3.org/TR/SVG11/paths.html#PathData section on path data in the SVG 1.1 specification].<br />
<br />
==time==<br />
A time (hour, minute, seconds, fractional seconds) is encoded according to ISO 8601 with no time zone: two digits (<code>0</code>–<code>9</code>) for the hour, a colon, two digits for the minute, optionally a colon and two digits for the second, and optionally (if the seconds are present) a period (<code>.</code>) and one, two, or three digits for the fraction of a second. All the numbers must be in base ten and zero-padded if necessary. For instance: <code>23:59:00.000</code> or <code>00:00:05</code>.<br />
<br />
==time-datetime==<br />
One of the following: [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-month-string month], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-date-string date], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-yearless-date-string yearless date], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-time-string time], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-local-date-and-time-string local date and time], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-time-zone-offset-string time-zone offset], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-global-date-and-time-string global date and time], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-week-string week], [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-non-negative-integer non-negative integer], or [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-duration-string duration]. For more information and examples, see the [http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#datetime-value section on the datetime value in the HTML specification].<br />
<br />
==week==<br />
A week consists of a year and a week number encoded according to ISO 8601: four or more digits (<code>0</code>–<code>9</code>) representing the year, a hyphen (<code>-</code>), a literal <code>W</code>, and two digits for the week, zero-padded if necessary. The week number must be a number greater than or equal to <code>01</code>. Week <code>01</code> of a given year is the week containing the 4<sup>th</sup> of January; weeks start on Monday. For instance: <code>2005-W52</code> is the week that ended on Sunday the first of January, 2006.<br />
<br />
[[Category:Validator.nu Documentation]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Who_to_ask_about_stuff&diff=9325Who to ask about stuff2013-10-15T12:13:03Z<p>Zcorpan: /* Opera */ jgraham no longer works for Opera</p>
<hr />
<div>This page is intended as a hub for information for spec editors regarding who to contact at various browser vendors and other implementors for various topics.<br />
<br />
== Mozilla ==<br />
<br />
See: [https://wiki.mozilla.org/Modules/Core Module Owners]<br />
<br />
People generally like being cc'ed on bugs for feedback; sicking says he prefers direct e-mail.<br />
<br />
== WebKit ==<br />
<br />
Presumably: [http://trac.webkit.org/wiki/WebKit%20Team WebKit Team]<br />
<br />
== Opera ==<br />
<br />
Ask simonp.<br />
<br />
== IE ==<br />
<br />
Contact Travis Leithead <travis.leithead@microsoft.com> for everything; he'll direct your call.<br />
<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9262New Features Awaiting Implementation Interest2013-08-05T14:29:51Z<p>Zcorpan: http://html5.org/tools/web-apps-tracker?from=8085&to=8086</p>
<hr />
<div>There are features that have been requested, but for which we are lacking implementor interest. Without two or more vendors interested in implementing the feature, they are unlikely to get added to the specs.<br />
<br />
<table class="wikitable"><br />
<tr><th rowspan=2>Feature <th colspan=6>Interest indicated by... <th rowspan=2>Comments<br />
<tr><th>Mozilla (Firefox) <th>Opera <th>Microsoft (IE) <th>Apple (Safari) <th>Google (Chrome) <th>Others<br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22682 Some way to add files to <input type=file>]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0153.html Jonas Sicking]<br />
<td><br />
<td><br />
<td><br />
<td> Nico Weber<br />
<td><br />
<td> On track for spec<br />
<tr><br />
<td>[[AllowSeamless|Cross-origin seamless iframes]]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0149.html Boris Zbarsky]<br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html Pending input on this thread]<br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22698 HTMLCanvasElement.printCallback API]<br />
<td>Julian Viereck<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0107.html Metadata API for media elements]<br />
<td>Ralph Giles<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td>Also needs a spec for the metadata schema<br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22696 Adding defer/async to inline scripts]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0290.html Jonas Sicking]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22675 &lt;meta name="referrer">]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22699 Location.ancestorOrigins]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Already implemented<br />
<td><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0259.html Negative feedback from Tobie Langel]<br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22701 A method to trigger autofill]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0231.html Elliott Sprehn], [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0289.html Peter Kasting]<br />
<td><br />
<td><br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22676 Prerendering APIs]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037833.html Gavin Peters]<br />
<td><br />
<td> Needs detailed specification work to describe what happens with scripts running in the prerender context (since normally scripts can't run in non-active documents, and normally there's only one active document per session history).<br />
<tr><br />
<td> [https://www.w3.org/Bugs/Public/show_bug.cgi?id=22697 APIs for 'palpable' content] (at the bottom)<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0082.html Ojan Vofai]<br />
<td><br />
<td><br />
<tr><br />
<td>Appcache: [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0345.html More detail in error events]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038185.html Michael Nordman]<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0088.html Making drawImage() have a mode to clamp at source rectangle]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Justin Novosad<br />
<td><br />
<td> There is a workaround using ImageBitmaps to extract a subregions of the source image. The workaround does not solve cases where sub-region extraction needs to be synchronous either because the source image content changes over time (e.g a canvas or video), or because the subrectangle coordinates cannot be determined in advance.<br />
<tr><br />
<td>Appcache: [https://www.w3.org/Bugs/Public/show_bug.cgi?id=20083 Interceptor Worker]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Needs use cases as well<br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22680 FormData]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674 Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0073.html Canvas: Page flipping for the 2D context]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0098.html James Robinson]<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038079.html Canvas: control over when shadows paint]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0138.html &lt;img srcset>: a mechanism to enable adaptive images]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859 locale=""]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0238.html <video> currentTime and seek using rational numbers]<br />
<td><br />
<td><br />
<td><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0232.html Jer Noble]<br />
<td><br />
<td><br />
<td> Would expose the video's timebase, too, assuming it's constant. See also next line.<br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=22678 video source material metrics] (e.g. frame rate for fixed-frame-rate video data)<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0617.html Cross-origin workers]<br />
<td><br />
<td><br />
<td>[http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0647.html Travis Leithead?]<br />
<td><br />
<td>[http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0618.html Ojan Vafai]<br />
<td><br />
<td><br />
<tr><br />
<td>[https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842 Deferring &lt;img> loads until the image is needed]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0272.html API to request Web Worker latency guarantees (in exchange for guaranteeing low CPU usage)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Oct/0024.html SearchBox API]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Tony Gentilcore<br />
<td><br />
<td> No longer being tracked.<br />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Differences_from_HTML4&diff=9114Differences from HTML42013-05-02T11:47:35Z<p>Zcorpan: </p>
<hr />
<div>{{obsolete|spec=[http://html-differences.whatwg.org/ HTML differences from HTML4]}}<br />
<br />
== Global overview ==<br />
<br />
HTML5 is different from HTML4 in a way that it addresses both document and application semantics making it more suitable for the web applications created today. HTML5 also reflects implementations better where they differ from HTML4 to ensure the language is implementable and compatible with the web. Inspired by the forward compatible error handling in CSS HTML5 defines detailed processing models where necessary to ensure that implementations become interoperable and that the language stays extensible in the future.<br />
<br />
HTML5 also integrates a new version of DOM Level 2 HTML so the element-specific APIs are defined along with the rest of the language. Because the language is mostly defined in terms of the DOM it's very easy to get an XML serialization as well. This XML serialization is called XHTML5 and is basically an update to XHTML1.x.<br />
<br />
== Syntax ==<br />
<br />
; Writing HTML5: HTML5 specifies its own syntax rules authors have to follow. HTML5 documents can be written in a way that looks exactly like XHTML although this does not imply that parsing such a document with an HTML parser will give the same result as parsing it with an XML parser.<br />
; Parsing HTML5: HTML5 defines its own parsing rules (including "error correction") for text/html resources and no longer pretends that HTML is an application of SGML.<br />
<br />
== Elements and Attributes ==<br />
<br />
=== New elements ===<br />
<br />
==== Document Structure ====<br />
<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-article article]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-aside aside]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-dialog dialog]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-figure figure]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-footer footer]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-header header]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-nav nav]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-section section]<br />
<br />
==== Data ====<br />
<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#audio audio]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-embed embed]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-m m]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-meter meter]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-source source]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-time time]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#video video]<br />
<br />
==== Applications ====<br />
<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-command command]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#datagrid datagrid]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-details details]<br />
* [http://www.whatwg.org/specs/web-forms/current-work/#the-datalist datalist] (Web Forms 2)<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-event-source event-source]<br />
* [http://www.whatwg.org/specs/web-forms/current-work/#the-output output] (Web Forms 2)<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-progress progress]<br />
<br />
In addition to the above the input element's type attribute can now have the following new values which enables a bunch of new native controls:<br />
<br />
* datetime<br />
* datetime-local<br />
* date<br />
* month<br />
* week<br />
* time<br />
* number<br />
* range<br />
* email<br />
* url<br />
<br />
=== New Attributes ===<br />
<br />
An overview of all elements from HTML4 that got new attributes in HTML5.<br />
<br />
{|<br />
! Element !! Attributes<br />
|-<br />
| a || media?, ping<br />
|-<br />
| area || ping<br />
|-<br />
| base || target<br />
|-<br />
| button || autofocus, form, replace, template<br />
|-<br />
| fieldset || disabled, form<br />
|-<br />
| form || data, replace<br />
|-<br />
| input || autocomplete, autofocus, form, inputmode, list, min, max, pattern, step, replace, required, template<br />
|-<br />
| li || value (no longer deprecated)<br />
|-<br />
| meta || charset<br />
|-<br />
| ol || start (no longer deprecated)<br />
|-<br />
| select || autofocus, data, form<br />
|-<br />
| script || async, defer<br />
|-<br />
| style || scoped<br />
|-<br />
| textarea || autofocus, form, inputmode, required<br />
|}<br />
<br />
HTML4 didn't have a concept of an attribute that applies to every element. HTML5 calls such attributes global attributes. The following attributes from HTML4 are made global attributes:<br />
<br />
* class<br />
* dir<br />
* id<br />
* lang<br />
* title<br />
<br />
The following new attributes are global attributes:<br />
<br />
* contenteditable<br />
* contextmenu<br />
* draggable<br />
* tabindex<br />
<br />
HTML5 also has global attributes that also can be applied on elements from other vocabularies (when namespaced):<br />
<br />
* repeat (Web Forms 2)<br />
* repeat-start (Web Forms 2)<br />
* repeat-min (Web Forms 2)<br />
* repeat-max (Web Forms 2)<br />
<br />
=== Changed Elements ===<br />
<br />
These elements have new meanings in HTML5 which are incompatible with HTML4. The new meanings better reflects the way they are used on the Web or gives them a purpose so people can start using them.<br />
<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-a a]: The a element without an href attribute represents a "placeholder link".<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-address address]: The address element is now scoped by the new concept of sectioning.<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-b b]: The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened.<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-hr hr]: The hr element now represents a paragraph-level thematic break.<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-i i]: The i element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-label label]: The browser should not transfer focus from the label to the control unless such behaviour is standard for the underlying platform user interface.<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#menus menu]: The menu element is redefined to be useful for actual menus.<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-small small]: The small element now represents small print (for side comments and legal print).<br />
; [http://www.whatwg.org/specs/web-apps/current-work/#the-strong strong]: The strong element now represents importance rather than strong emphasis.<br />
<br />
=== Dropped Elements ===<br />
<br />
That these elements are dropped means that authors are no longer allowed to use them. User agents will still have to support them and HTML5 will probably get a rendering section in due course that says exactly how. (isindex for instance is already supported by the parser.)<br />
<br />
* acronym (use [http://www.whatwg.org/specs/web-apps/current-work/#the-abbr abbr] instead)<br />
* applet (use [http://www.whatwg.org/specs/web-apps/current-work/#the-object object] instead) <br />
* basefont <br />
* big <br />
* center <br />
* dir<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-font font] (allowed when inserted by WYSIWYG editors)<br />
* frame <br />
* frameset <br />
* isindex <br />
* noframes <br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-noscript noscript] (only dropped in XHTML5) <br />
* s <br />
* strike <br />
* tt <br />
* u<br />
<br />
=== Dropped Attributes ===<br />
<br />
Some attributes for elements included in HTML4 are not allowed in HTML5:<br />
<br />
{|<br />
! Element !! Attributes<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-a a] || rev, charset<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-area area] || nohref<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-head head] || profile<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-html html] || version<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-link link] || rev, target, charset<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-map map] || name<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#meta meta] || scheme<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-object object] || archive, standby<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-param param] || valuetype<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#script script] || charset<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-table table] || summary<br />
|-<br />
| [http://www.whatwg.org/specs/web-apps/current-work/#the-td td], [http://www.whatwg.org/specs/web-apps/current-work/#the-th th] || headers, axis<br />
|}<br />
<br />
In addition, HTML5 has none of the presentational attributes that were in HTML4 (including those on &lt;table&gt;). Any attributes defined on ''elements'' that are not in HTML5 are (obviously) also not in HTML5.<br />
<br />
== APIs ==<br />
<br />
HTML5 introduces a number of APIs that should help in creating web applications. These can be used together with the new elements introduced for applications:<br />
<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#the-2d 2D drawing API] which can be used with the new [http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas] element<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#media API for playing of video and audio] which can be used with the new [http://www.whatwg.org/specs/web-apps/current-work/#video video] and [http://www.whatwg.org/specs/web-apps/current-work/#audio audio] elements<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#storage Persistent storage]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#offline Online / offline events]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#editing Editing API] in combination with a new global [http://www.whatwg.org/specs/web-apps/current-work/#contenteditable0 contenteditable] attribute<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#dnd Drag & drop API] in combination with a [http://www.whatwg.org/specs/web-apps/current-work/#draggable draggable] attribute.<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#network Network API]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#history API that exposes the history] and allows pages to add to it to prevent breaking the back button.<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages Cross document messaging]<br />
* [http://www.whatwg.org/specs/web-apps/current-work/#server-sent-events Listening to server sent events]<br />
<br />
== Character Encoding ==<br />
<br />
The character encoding can be declared using the meta element, but the syntax of the meta element has changed. In HTML 4.01 and earlier, the meta element was:<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In HTML5, the syntax was simplified to remove the unnecessary markup, yet still remain compatible with the encoding detection implemented in most existing browsers.<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
=== HTML 4 Algorithm ===<br />
<br />
Source [http://www.w3.org/TR/html4/charset.html#h-5.2.2 5.2.2 Specifying the character encoding], HTML 4.01 Specification.<br />
<br />
# An HTTP "charset" parameter in a "Content-Type" field.<br />
# A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".<br />
# The charset attribute set on an element that designates an external resource.<br />
<br />
=== HTML 5 Algorithm ===<br />
<br />
The exact algorithm that browsers must follow in order to [http://www.whatwg.org/specs/web-apps/current-work/#the-input0 determine the character encoding] is specified in HTML 5. The basic algorithm works as follows:<br />
<br />
# If the transport layer specifies an encoding, use that, and abort these steps. (e.g. The HTTP Content-Type header).<br />
# Read the first 512 bytes of the file, or at least as much as possible if less than that.<br />
# If the file starts with a UTF-8, UTF-16 or UTF-32 BOM, then use that and abort these steps.<br />
# Otherwise use the special algorithm to search the first 512 bytes for a meta element that declares the encoding. The algorithm is relatively lenient in what it will detect, though since it doesn't use the normal parsing algorithm, there are some restrictions.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Main_element&diff=8883Main element2012-12-14T08:39:54Z<p>Zcorpan: /* problems with first article */</p>
<hr />
<div>There is an HTML5 extension specification that proposes adding a <code>main</code> element to HTML5.<br />
<br />
* https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html<br />
<br />
Summary: This page contains arguments for, rebuttals to arguments against, and research/data supporting the introduction of a <code>main</code> element to HTML/HTML5.<br />
<br />
HTML5 has several new "block like" semantic elements (article, aside, section), including header and footer elements. There is no element to represent (and provide a hook for) for ''the'' "main content". The only landmark ARIA role that lacks an equivalent semantic HTML element is also called "main", and it is being used on real world websites.<br />
<br />
This page contains:<br />
* positive reasoning and supporting evidence for <code>&lt;main&gt;</code><br />
* arguments against <code>&lt;main&gt;</code>, with follow-ups<br />
* counter-proposals to <code>&lt;main&gt;</code>, with explanation of inadequacies<br />
<br />
== Use cases ==<br />
Though there are some documentation of use-cases elsewhere, it's helpful to provide some of these in this context to help with consideration of the proposal.<br />
<br />
=== Reduce need for explicit skip links ===<br />
One of the motivators was to get rid of skip links (http://webaim.org/techniques/skipnav/).<br />
<br />
A main element would reduce work for authors.<br />
<br />
Adding skip links is extra work for the author, particularly for accessibility, and thus it can be missed.<br />
<br />
It would be less work for authors to simply use a main element. Authors naturally use the semantics of a main content area (with classes, id etc.) thus if they were given a <code>main</code> element to use, they'd easily use that instead (paving a cowpath).<br />
<br />
Browsers could (user-configurably) provide some sort of built-in skip to main content gesture (link, or other mechanism).<br />
<br />
== Arguments for ==<br />
In general there must be a high burden of justification for adding new elements, in order to keep the language easier and more usable overall. Every new element adds cost to learning/usability, and thus must more than make up for it in benefits.<br />
<br />
=== paves a cowpath ===<br />
A <code>main</code> element paves an already researched cowpath.<br />
<br />
Or: it should have been included with header footer et al.<br />
<br />
The introduction of <code>&lt;header></code>, <code>&lt;footer></code>, <code>&lt;aside></code>, <code>&lt;nav></code>, and <code>&lt;article></code> is based on careful consideration based on data gathered (in 2005). <br />
<br />
Even according to Hixie’s research, the class “content” ranked higher than “nav” or “header”. It would be even more obvious if you took the sum of “content”, “main” and “body” (as class names or ids). <br />
<br />
See https://developers.google.com/webmasters/state-of-the-web/2005/charts/top20-classes.svg . <br />
<br />
That Hixie left <code>&lt;main></code> out in the first place is not justified by the research presented.<br />
<br />
=== avoids last case of having to use an ARIA landmark ===<br />
"Use of ARIA (a stop gap) should be a smell. Using it generally<br />
implies a weakness in native semantic, or, an abuse of native semantics." -David Bolter<br />
<br />
Additionally, role=main is the most commonly used ARIA landmark per:<br />
* http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/ <br />
And it’s the only landmark that doesn’t have a one-to-one mapping to an HTML element name.<br />
<br />
A main element would avoid the need to use role="main".<br />
<br />
=== definitively answers a common question ===<br />
On various development forums and sites, there are many questions of the nature: what HTML5 element do I use for the main content of my page? E.g.:<br />
* Sitepoint: [http://www.sitepoint.com/forums/showthread.php?855981-Main-content-area-in-HTML5-what-is-correct Main content area in HTML5 - what is correct ????]<br />
* Stack Overflow: [http://stackoverflow.com/questions/12438300/html-5-element-for-content HTML 5 element for content?]<br />
<br />
Given that web developers are already asking these questions (and getting wildly inconsistent answers), and that they're going to author *something* for what they consider the main content, a main element would naturally provide this functionality, and alleviate a common source of confusion.<br />
<br />
== Arguments against ==<br />
=== Lack of concrete use case documentation ===<br />
See previous [[Main_element#Use_cases|Use cases]] section.<br />
<br />
=== main does not meet a high bar of inclusion ===<br />
Per the research cited in [[Main_element#paves_a_cowpath|paves a cowpath]], a main element meets a higher bar than "article" for example (which has plenty of real world use in blog posts), and certainly more than "hgroup" (which is debatable whether it should be kept or not).<br />
<br />
== Counter-proposals ==<br />
=== Use existing markup instead ===<br />
==== first article ====<br />
Referred: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037826.html<br />
<br />
Summarized:<br />
* To Authors: just use <code>&lt;article></code>. The main contents of a page are worthy of independently syndicating - nearly all content on the web works this way today.<br />
* To Accessibility Tools: If you don't find a role=main element, then just use the first <code>&lt;article></code> in the page as if it were a <code>&lt;main></code> element.<br />
<br />
The use of <code>&lt;article></code> instead also makes sense as a generalization of <code>&lt;main></code> that arises as soon as one thinks of how to write processing rules for the case where a page has more than one <code>&lt;main></code> even if it isn’t supposed to have more than one <code>&lt;main></code>.<br />
<br />
Questions:<br />
* Q: Where's the end of <code>&lt;main></code> content? <br />
** A: End of the last <code>&lt;article></code>.<br />
* Q: How do you skip stuff between <code>&lt;main></code> elements? <br />
** A: Skip stuff between <code>&lt;article></code> elements.<br />
* Q: Is it appropriate to use <code>&lt;article></code> in the gmail message list?<br />
** A: Yes, each message does have its own URL, and POP could arguably be a form of syndication.<br />
<br />
===== problems with first article =====<br />
Problems with the first article rule: [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038219.html][https://bugzilla.mozilla.org/show_bug.cgi?id=820508#c3]<br />
<br />
1) The generalization no longer looks the way authors think. The<br />
cowpath being paved is hard to recognize. That is, the idea that you<br />
replace <code>&lt;div id=content></code> or <code>&lt;div id=main></code> with <code>&lt;main></code> is more intuitive than that you replace <code>&lt;div id=content></code> with <code>&lt;article></code> but<br />
you also replace each <code>&lt;div class=comment></code> with <code>&lt;article></code> and since the comments come after the main article, the first <code>&lt;article></code> ends up having the semantics of main content.<br />
<br />
2) When role="main" exists, it’s hard to convince people that implicit works as well as explicit. Even if browsers actually exposed the right accessibility API role for first <code>&lt;article></code>, authors would still probably feel it’s better to say role="main" just in case. I would love to see ARIA obsoleted in the sense that people who don’t retrofit accessibility to legacy code and who aren’t recreating GUI widgets is JS wouldn’t need to deal with ARIA (where including role=main just in case because one doesn’t trust rules like “first <code>&lt;article></code>” counts as “needing” to deal with ARIA).<br />
<br />
3) Even though in principle, the element names are just runes whose<br />
meaning is given by the spec—not by the English meaning of the element<br />
name, people still try to guess usage from the element name. It’s<br />
pretty easy to believe from element names alone than <code>&lt;main></code> is <code>&lt;div id=content></code> or <code>&lt;div id=main></code> made as a part of the language itself. It’s harder to grok the defined semantics of <code>&lt;article></code> from its element name.<br />
<br />
4) It’s more obvious to write main { ... } in CSS than<br />
body > article:first-of-type { ... } (assuming the article is a child of body -- there's no way to write a selector for "first article in the document")<br />
<br />
5) "first article" (and <main>) fails to handle a similar use cases:<br />
<source lang=xml><br />
<section><br />
<h1>Heading</h1><br />
<aside> ... </aside><br />
<nav> ... </nav><br />
text...<br />
<aside> ... </aside><br />
<aside> ... </aside><br />
text...<br />
</section><br />
</source><br />
where you want to navigate from "Heading" to "text...".<br />
<br />
== Implementation impact ==<br />
Notes on potential implementation impact of a main element on web browsers.<br />
<br />
To be done right, <code>&lt;main></code> and <code>&lt;p></code> should interact the way e.g. <code>&lt;article></code> and <code>&lt;p></code> do.<br />
<br />
Consider<br />
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1939 and<br />
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1940<br />
<br />
vs.<br />
<br />
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1942 and<br />
* http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1941<br />
<br />
Implementer feedback:<br />
* Mozilla: <br />
** From a layout engine implementation point of view the burden is trivial.<br />
** The parser change would be absolutely trivial. There is absolutely no basis for opposing <code>&lt;main></code> on the grounds of amount of parser change work needed.<br />
<br />
== Implementation bugs ==<br />
* Mozilla Firefox/Gecko: [https://bugzilla.mozilla.org/show_bug.cgi?id=820508 Bug 820508 Add support for <main> element]<br />
* WebKit: [https://bugs.webkit.org/show_bug.cgi?id=103172 Bug 103172 - implement the HTML <main> element]<br />
<br />
== Open issues ==<br />
=== Different HTML parsing algorithms ===<br />
It’s just unfortunate that if <code>&lt;main></code> was introduced, the HTML parsing algorithm wouldn’t be one exact thing but there’d be HTML parsing pre-<code>&lt;main></code> and HTML parsing post-<code>&lt;main></code> and during the transition, Web authors would have to explicitly write the </p> tag, which is supposed to be optional. However, we are headed to a world where there will be HTML parsing pre-<code>&lt;template></code> and HTML parsing post-<code>&lt;template></code> anyway.<br />
<br />
== Asides ==<br />
=== Mesolithic analogy ===<br />
It's interesting that debates over introducing a term for "the middle part" of something long predate this discussion, see for example the controversy over the introduction of the term "mesolithic":<br />
<br />
http://en.wikipedia.org/wiki/Mesolithic#History_of_the_concept<br />
<br />
as the thing between, Paleolithic (header), and Neolithic (footer). Despite the controversy, mesolithic is now an established term.</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Web_ECMAScript&diff=8821Web ECMAScript2012-11-26T16:54:52Z<p>Zcorpan: </p>
<hr />
<div>{{obsolete|spec=[http://javascript.spec.whatwg.org/ JavaScript, aka. Web ECMAScript]}}<br />
<br />
This page is for documenting the differences between ES5 specification and the requirements for ECMAScript implementations in web browsers.<br />
<br />
'''It is now maintained as specification: [http://javascript.spec.whatwg.org/ JavaScript, aka. Web ECMAScript]'''<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 />
== var statements ==<br />
<br />
The erratum in https://bugs.ecmascript.org/show_bug.cgi?id=78#c0 needs to be followed so that var statements at the top level of scripts can shadow any properties from the global object's prototype chain.<br />
<br />
== Eval ==<br />
<br />
Use of eval not called "eval". Should 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 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, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).<br />
<br />
Chakra (IE) doesn’t support these syntax extensions.<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 />
Note: __proto__ will be fully specced in ES6.<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 />
* https://bugs.ecmascript.org/buglist.cgi?product=ECMA-262&component=technical%20content&resolution=--- – open bugs on the ES spec<br />
<br />
[[Category:Spec_coordination]]</div>Zcorpanhttps://wiki.whatwg.org/index.php?title=Web_ECMAScript&diff=8820Web ECMAScript2012-11-26T13:23:16Z<p>Zcorpan: </p>
<hr />
<div>{{obsolete|spec=[http://mathias.html5.org/specs/javascript/ JavaScript, aka. Web ECMAScript]}}<br />
<br />
This page is for documenting the differences between ES5 specification and the requirements for ECMAScript implementations in web browsers.<br />
<br />
'''It is now maintained as specification: [http://javascript.spec.whatwg.org/ JavaScript, aka. Web ECMAScript]'''<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 />
== var statements ==<br />
<br />
The erratum in https://bugs.ecmascript.org/show_bug.cgi?id=78#c0 needs to be followed so that var statements at the top level of scripts can shadow any properties from the global object's prototype chain.<br />
<br />
== Eval ==<br />
<br />
Use of eval not called "eval". Should 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 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, "-->" on any line that starts with just whitespace (but not comments) is treated as a line comment (same as //).<br />
<br />
Chakra (IE) doesn’t support these syntax extensions.<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 />
Note: __proto__ will be fully specced in ES6.<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 />
* https://bugs.ecmascript.org/buglist.cgi?product=ECMA-262&component=technical%20content&resolution=--- – open bugs on the ES spec<br />
<br />
[[Category:Spec_coordination]]</div>Zcorpan