https://wiki.whatwg.org/api.php?action=feedcontributions&user=Hixie&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-28T17:37:27ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=FAQ&diff=9975FAQ2015-08-27T19:26:09Z<p>Hixie: /* When will HTML5 be finished? */</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 />
=== 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 />
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 />
=== 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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9933FAQ2015-04-09T17:37:08Z<p>Hixie: </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 />
=== 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 />
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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9804FAQ2015-02-02T00:56:16Z<p>Hixie: </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, e-mail ian@hixie.ch.<br />
<br />
If you're not sure what consists harassment, the following codes of conduct from other organisations are a good guide:<br />
* http://atheists.org/convention2014/code-of-conduct<br />
* http://www.w3.org/Consortium/cepc/<br />
* https://secularstudents.org/2013con/columbus/policies<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 />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these emails:<br />
* http://lists.w3.org/Archives/Public/public-html/2009Mar/0491.html<br />
* http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0071.html<br />
At this stage, as discussed in the second of those emails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9729FAQ2014-10-01T17:25:37Z<p>Hixie: /* What is HTML? */</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 />
== 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 />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these emails:<br />
* http://lists.w3.org/Archives/Public/public-html/2009Mar/0491.html<br />
* http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0071.html<br />
At this stage, as discussed in the second of those emails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9728FAQ2014-10-01T17:23:51Z<p>Hixie: /* {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? */</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 />
== 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 they 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 />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these emails:<br />
* http://lists.w3.org/Archives/Public/public-html/2009Mar/0491.html<br />
* http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0071.html<br />
At this stage, as discussed in the second of those emails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9727FAQ2014-10-01T17:20:46Z<p>Hixie: /* How does the WHATWG work? */</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 />
== 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.<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 they 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 />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these emails:<br />
* http://lists.w3.org/Archives/Public/public-html/2009Mar/0491.html<br />
* http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0071.html<br />
At this stage, as discussed in the second of those emails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 https://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9698FAQ2014-09-23T20:36:06Z<p>Hixie: /* What's the patent story for WHATWG standards? */</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 />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail 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 as the "WHATWG members", see the [https://whatwg.org/charter charter]) 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.<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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 they 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 [http://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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9697FAQ2014-09-23T20:33:34Z<p>Hixie: /* What is the WHATWG working on? */</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 />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail 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 as the "WHATWG members", see the [https://whatwg.org/charter charter]) 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.<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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 />
<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 they 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 [http://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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9696FAQ2014-09-23T20:30:16Z<p>Hixie: </p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail 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 as the "WHATWG members", see the [https://whatwg.org/charter charter]) 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.<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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 />
<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 they 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 [http://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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9695FAQ2014-09-23T20:29:08Z<p>Hixie: /* Is participation free? */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list] or [http://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 as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) 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.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 />
<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 they 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 [http://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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<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 [http://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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9694FAQ2014-09-23T20:28:07Z<p>Hixie: </p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list] or [http://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 as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) 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.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 />
<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 they 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 [http://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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<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 [http://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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9688FAQ2014-09-16T23:24:36Z<p>Hixie: </p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list] or [http://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 as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) 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.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://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 [http://www.whatwg.org/specs/web-apps/current-work/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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
The WHATWG [http://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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=W3C&diff=9686W3C2014-09-12T16:22:00Z<p>Hixie: </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 />
* 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 />
== Extracts from e-mails ==<br />
<br />
In this section, some complaints about the W3C have been collected.<br />
<br />
=== Canvas spec woes ===<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 />
[[Category:Spec_coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=Best_Practices_for_Implementors&diff=9623Best Practices for Implementors2014-06-26T16:53:05Z<p>Hixie: </p>
<hr />
<div>== Adding new features ==<br />
<br />
* Before adding a new feature, even one that's as simple as a new &lt;meta> value, please ensure you have discussed it with other browser vendors. You can use the whatwg@whatwg.org mailing list for this purpose.<br />
<br />
* If you're adding a feature that's not in a spec, make sure to first address any concerns that the relevant spec's editor may have. You might have missed some reason why it's not in the spec. If the spec's editor has given reasons why the feature is a bad idea, but you think you should implement it anyway, make sure to make this clear in public both to the editor in question and to other browser vendors.<br />
** If there are multiple specs that could apply, e.g. because it cross multiple topics or because the spec in question is forked, make sure to raise it with all the relevant editors, not just one of them.</div>Hixiehttps://wiki.whatwg.org/index.php?title=Best_Practices_for_Implementors&diff=9622Best Practices for Implementors2014-06-26T16:52:52Z<p>Hixie: Created page with "== Adding new features == * Before adding a new feature, even one that's as simple as a new &lt;meta> value, please ensure you have discussed it with other browser vendors. Y..."</p>
<hr />
<div>== Adding new features ==<br />
<br />
* Before adding a new feature, even one that's as simple as a new &lt;meta> value, please ensure you have discussed it with other browser vendors. You can use the whatwg@whatwg.org mailing list for this purpose.<br />
<br />
* If you're adding a feature that's not in a spec, make sure to first address any concerns that the relevant spec's editor may have. You might have missed some reason why it's not in the spec. If the spec's editor has given reasons why the feature is a bad idea, but you think you should implement it anyway, make sure to make this clear in public both to the editor in question and to other browser vendors.<br />
<br />
** If there are multiple specs that could apply, e.g. because it cross multiple topics or because the spec in question is forked, make sure to raise it with all the relevant editors, not just one of them.</div>Hixiehttps://wiki.whatwg.org/index.php?title=Main_Page&diff=9621Main Page2014-06-26T16:05:51Z<p>Hixie: </p>
<hr />
<div>Welcome to the WHATWG Wiki!<br />
<br />
You can be a part of our community, making proposals for the next version of HTML. This wiki is made available for you for drafting proposals, for writing essays, for keeping track of HTML-related issues, and so forth. <br />
<br />
Before you begin, you may wish to read our [[WHATWG Wiki:Contribution Guidelines|contribution guidelines]]. Once you are an autoconfirmed user, you may [[WHATWG Wiki:How to create a user account|create new user accounts]], by request.<br />
<br />
==Quick Links==<br />
* [[FAQ]]<br />
* [[What you can do]] — '''[[Reviewing|Review our work!]]<br />
* [[:Category:Implementations|Implementations]]<br />
* [[Presentations]]<br />
<br />
==Web Developers==<br />
* [[Authoring|Using HTML in your Web site]]<br />
* [[Presentational elements and attributes]]<br />
* [[HTML vs. XHTML]]<br />
<br />
==Spec Development==<br />
* [[Best Practices for Implementors]]<br />
* [[:Category:Spec coordination|Spec coordination]]<br />
* [[:Category:Proposals|Proposals]]<br />
* [[:Category:Registries|Registries]]<br />
* [[New Features Awaiting Implementation Interest]]<br />
* [[Testsuite]]<br />
<br />
==WHATWG Specifications==<br />
* [http://www.whatwg.org/specs Complete list of specifications actively developed at the WHATWG]<br />
* [http://whatwg.org/html HTML]<br />
* [[HTML derivatives]]<br />
* [[HTML snapshots]]<br />
<br />
==Communicating with the community==<br />
The WHATWG community has several channels of communication:<br />
* [[IRC]] and [http://www.whatwg.org/mailing-list mailing lists]<br />
* [http://forums.whatwg.org/ Forums]<br />
* [http://blog.whatwg.org/ The WHATWG Blog], including [http://blog.whatwg.org/category/weekly-review WHATWG Weekly]<br />
* [http://twitter.com/WHATWG @WHATWG] on twitter<br />
* [http://www.w3.org/html/planet/ W3C's Planet HTML5]</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9609FAQ2014-05-27T21:36:56Z<p>Hixie: </p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list] or [http://whatwg.org/newbug file bugs]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
For new features, or significant changes to the processing models, the 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.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://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 [http://www.whatwg.org/specs/web-apps/current-work/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: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your 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: http://dev.w3.org/html5/html4-differences/<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
The WHATWG [http://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! [http://developers.whatwg.org/ http://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 [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=RequestAutocomplete&diff=9503RequestAutocomplete2014-04-09T21:56:24Z<p>Hixie: </p>
<hr />
<div>Something based on this is now in the HTML standard: http://www.whatwg.org/specs/web-apps/current-work/#dom-form-requestautocomplete<br />
<br />
The remainder of this page is for the historical record:<br />
<br />
requestAutocomplete proposed spec (as implemented in Chromium)<br />
<br />
This document contains a preliminary specification of the requestAutocomplete feature that allows developers to request that the browser fill a form with information based on the autocomplete attributes on the form controls.<br />
<br />
== Issues ==<br />
<br />
This should really use a promise: http://dom.spec.whatwg.org/#promises (http://crbug.com/343630).<br />
<br />
== Interfaces Additions== <br />
<br />
interface '''HTMLFormElement''' : HTMLElement {<br />
...<br />
void requestAutocomplete();<br />
};<br />
<br />
enum AutoCompleteErrorReason {<br />
"",<br />
"cancel",<br />
"disabled",<br />
"invalid"<br />
};<br />
<br />
[Constructor(DOMString type, optional AutocompleteErrorEventInit eventInitDict)]<br />
interface '''AutocompleteErrorEvent''' : Event {<br />
readonly attribute AutoCompleteErrorReason reason;<br />
};<br />
<br />
dictionary '''AutocompleteErrorEventInit''' : EventInit {<br />
AutoCompleteErrorReason reason = "";<br />
};<br />
<br />
== Algorithms ==<br />
<br />
When the '''requestAutocomplete'''() method is invoked, the user agent must run the following steps:<br />
<br />
# If we are not allowed to show a popup then asynchronously fail with the reason "disabled" and abort these steps.<br />
# If the ''requestAutocompleteIsActive'' flag is true or the form element's autocomplete attribute evaluates to “off” then asynchronously fail with the reason "disabled" and abort these steps.<br />
# Optionally asynchronously fail with the reason "disabled" and abort these steps.<br />
#: (For example the user agent may give the user an option to ignore all autocomplete requests.)<br />
# Set the ''requestAutocompleteIsActive'' flag to true.<br />
# Let the pending autofill set be an empty set of autocomplete tuples of the form <br />
#: ( autocomplete attribute: string, input: Element )<br />
# For each element that has this form element as its form owner add it to the pending autocomplete set with its attribute values if:<br />
#* The autocomplete attribute is specified for its element type.<br />
#* The autocomplete attribute parses to a valid value.<br />
# Asynchronously request autocomplete from the user agent for the pending auto fill set for this form element.<br />
<br />
When the user agent is said to request autocomplete for a form element it should run the following steps:<br />
<br />
# Let the autofill set be the set of autocomplete tuples that were passed into this algorithm.<br />
# Optionally asynchronously fail with the reason "cancel" and abort these steps. (For example if the user cancels the request.)<br />
# For each tuple in the autofill set:<br />
#: a. Skip this tuple if the input's attribute value for autocomplete is different than the one stored in the tuple.<br />
#: b. Skip this tuple if the form owner of the input is not this form element.<br />
#: c. Autofill the input following the autocomplete rules but allowing the input to suffer from a pattern mismatch.<br />
# Statically validate the constraints and:<br />
#: a. If the result is negative asynchronously fail with the reason "invalid".<br />
#: b. If the result is positive fire a simple event named "autocomplete" that bubbles on the form element.<br />
# Set the requestAutocompleteIsActive flag to false.<br />
<br />
When the user agent is said to asynchronously fail with a reason, it queues an event to fire on the form element currently being operated on of a new AutocompleteErrorEvent with the type "autocompleteerror" and the reason specified.<br />
<br />
[[Category:Proposals]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9495FAQ2014-03-26T00:06:14Z<p>Hixie: /* How does the WHATWG work? */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list] or [http://whatwg.org/newbug file bugs]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
For new features, or significant changes to the processing models, the 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.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the 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 specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the 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!<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is one of the specifications 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://validator.whatwg.org/ validator].<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots, but these are generally out of date. Some have even forked. Also, there's no documentation available describing which changes the W3C has made intentionally and which are just mistakes.<br />
<br />
The following table lists the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
The WHATWG [http://whatwg.org/specs/ also works on other specifications].<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://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 />
* http://dev.opera.com/articles/html/<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 already started implementing parts of HTML5 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 will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9476FAQ2014-03-05T19:43:34Z<p>Hixie: /* Where's the harm in adding— */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the 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 specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the 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!<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is one of the specifications 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://validator.whatwg.org/ validator].<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots, but these are generally out of date. Some have even forked. Also, there's no documentation available describing which changes the W3C has made intentionally and which are just mistakes.<br />
<br />
The following table lists the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
The WHATWG [http://whatwg.org/specs/ also works on other specifications].<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://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 />
* http://dev.opera.com/articles/html/<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 already started implementing parts of HTML5 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 will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=MetaExtensions&diff=9463MetaExtensions2014-02-17T16:24:22Z<p>Hixie: </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 may not be reflected in validators in real time.<br />
<br />
Changes to this registry may not be reflected in validators in real time.<br />
<br />
If you add a meta name value to this table and you want it supported in the validator(s), you need to either [http://bugzilla.validator.nu/ open a validator bug] or e-mail the [mailto:www-validator@w3.org www-validator@w3.org] list to ask that it be added and reference your change to this page.<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 />
| Makes WebApp Fullscreen (With iPhone 5 Support)<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 />
| No specification yet<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 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 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 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. Similar to blazerr-ssl.<br><br />
Usage: <code><meta name="blazerr-secure" content="yes"></code><br />
| [https://jokenetwork.de/faq/blazerr/metatags JokeNetwork's Blazerr 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 />
| 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.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.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 />
| 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 />
| 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 />
|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 />
| 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 />
| [https://support.google.com/translate/?hl=en Google Translate Help]<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 />
| 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 />
| 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 />
| 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-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 />
| 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 />
|<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 />
| 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: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 />
| 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 />
| 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 />
For more details, see the [http://dev.w3.org/csswg/css-device-adapt/#viewport-meta Viewport META element] section of the [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] draft specification.<br />
| For <code>meta</code> elements that have a <code>name</code> attribute whose value is <code>viewport</code>, the [http://dev.w3.org/csswg/css-device-adapt/ CSS Device Adaptation] draft specification defines the recognized properties for the <code>content</code> attribute>, as well as an algorithm for parsing the value of that attribute.<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 />
|}<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 />
| 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 />
<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>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9326FAQ2013-10-15T18:12:32Z<p>Hixie: /* How can I get involved? */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
[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 [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the 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 specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the 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!<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is one of the specifications 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://validator.whatwg.org/ validator].<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots, but these are generally out of date. Some have even forked. Also, there's no documentation available describing which changes the W3C has made intentionally and which are just mistakes.<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
The WHATWG [http://whatwg.org/specs/ also works on other specifications].<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://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 />
* http://dev.opera.com/articles/html/<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 already started implementing parts of HTML5 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 will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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, they have to be maintained<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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9320FAQ2013-10-08T03:01:33Z<p>Hixie: /* Where's the harm in adding— */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the 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 specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the 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!<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is one of the specifications 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://validator.whatwg.org/ validator].<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots, but these are generally out of date. Some have even forked. Also, there's no documentation available describing which changes the W3C has made intentionally and which are just mistakes.<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
The WHATWG [http://whatwg.org/specs/ also works on other specifications].<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://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 />
* http://dev.opera.com/articles/html/<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 already started implementing parts of HTML5 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 will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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, they have to be maintained<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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9319FAQ2013-10-07T20:11:38Z<p>Hixie: /* HTML5 */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the 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 specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the 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!<br />
<br />
== HTML ==<br />
<br />
=== What is HTML? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is one of the specifications 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 they 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How do I validate my pages? ===<br />
<br />
Use a [http://validator.whatwg.org/ validator].<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the HTML spec? ===<br />
<br />
The HTML Standard is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots, but these are generally out of date. Some have even forked. Also, there's no documentation available describing which changes the W3C has made intentionally and which are just mistakes.<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
The WHATWG [http://whatwg.org/specs/ also works on other specifications].<br />
<br />
=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://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 />
* http://dev.opera.com/articles/html/<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 already started implementing parts of HTML5 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 will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 />
* 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, they have to be maintained<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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=Specs/howto&diff=9258Specs/howto2013-07-23T22:53:01Z<p>Hixie: /* Defining an attribute */</p>
<hr />
<div>== About this document ==<br />
<br />
This document explains basic guidelines for writing a specification for the web platform. [http://www.whatwg.org/C HTML] and [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM] among others follow these guidelines. You are encouraged to study those specifications and follow the patterns and style they establish.<br />
<br />
See also [[Advice for people writing specs]].<br />
<br />
== Audience ==<br />
<br />
This document focuses primarily on specifications aimed at browser implementors. The content of these specifications focuses on API calls that browsers implement and the required browser behavior under all possible cases. Specifications for user interface design and for authored content are not addressed here.<br />
<br />
== Organization ==<br />
<br />
Each specification includes these top-level sections:<br />
<br />
* '''Introduction''' — Gives an overview of the technology defined.<br />
* '''Conformance''' — References [http://tools.ietf.org/html/rfc2119 RFC 2119] and/or explains how conformance is determined in this specification. Lists the conformance classes that apply to this specification. See http://www.w3.org/TR/qaframe-spec/<br />
* '''Terminology''' — Defines where the terms in the specification originate from and sometimes provides a few novel definitions that do not fit within the main prose of the specification.<br />
* &hellip; content &hellip;<br />
* '''References'''<br />
* '''Acknowledgments'''<br />
<br />
See e.g. [http://dev.w3.org/2006/webapi/progress/ Progress Events] and [http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ XMLHttpRequest].<br />
<br />
== Content ==<br />
<br />
Content in a specification falls into two general categories: ''normative'' and ''informative''. ''Normative'' content includes the requirements and definitions and uses verbs such as ''must'', ''should'', and ''may''. Refer to [http://tools.ietf.org/html/rfc2119 RFC 2119] for their definitions. If a normative statement uses the verb ''must'' (and applies to UAs), the browser implementor should be able to write a test case for it. (If it is not possible to write a test case for the statement, do not use the word ''must''.) The verb "may" merely grants permission and is used rarely. Do not use "may not". Normal lowercase is preferred for readability.<br />
<br />
''Informative'' content is everything that is not normative. Informative (non-normative) content includes diagrams and code examples&mdash;very useful content, but supportive in nature to the actual browser requirements. Informative content must not include RFC 2119 keywords (use words like "can" or "is" instead).<br />
<br />
See also Hixie's blog post on the subject: http://ln.hixie.ch/?start=1140242962&count=1<br />
<br />
=== Definitions ===<br />
<br />
Elements, attributes, members of an object, algorithms, are all marked up using the <code>dfn</code> element. The <code>title</code> attribute of the element or its contents if there is no such attribute represents the name used for cross references. These are the conventions:<br />
<br />
* '''Interfaces:''' InterfaceName; e.g. <code>interface <dfn>Document</dfn> { &hellip;</code><br />
* '''Interface members:''' dom-InterfaceName-attributeOrMethodName; e.g. the <code><dfn title=dom-Document-URL><code>URL&lt;/code></dfn></code> attribute must &hellip;<br />
* '''Events:''' event-eventname<br />
* '''Elements:''' elementname<br />
* '''Attributes:''' attr-elementname-attributename<br />
* '''Concepts:''' concept-word; e.g. <code>&lt;dfn title=concept-node>node&lt;/dfn></code><br />
<br />
You reference a definition using either the <code>span</code> or <code>code</code> element. [[Anolis]] takes care of linking back to the definition.<br />
<br />
=== IDL ===<br />
<br />
The structure of an API is defined using [http://dev.w3.org/2006/webapi/WebIDL/ Web IDL]. An interface can be defined as follows:<br />
<br />
&lt;pre class=idl>interface &lt;dfn>ProcessingInstruction&lt;/dfn> : &lt;span>Node&lt;/span> {<br />
readonly attribute DOMString &lt;span title=dom-ProcessingInstruction-target>target&lt;/span>;<br />
attribute DOMString &lt;span title=dom-ProcessingInstruction-data>data&lt;/span>;<br />
};&lt;/pre><br />
<br />
(See also [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#processinginstruction <code>ProcessingInstruction</code>] in DOM Core.)<br />
<br />
The interface members are described both in a non-normative and a normative way. Non-normatively using a <code>&lt;dl class=domintro></code> construct. Normatively as described in the following sections.<br />
<br />
===Defining an attribute===<br />
<br />
A readonly attribute is defined as follows:<br />
<br />
The &lt;dfn>&lt;code>novel&lt;/code>&lt;/dfn> attribute must return "&lt;code>Hear the Wind Sing&lt;/code>".<br />
<br />
An attribute whose value can be set is typically defined as two distinct definitions:<br />
<br />
The &lt;dfn>&lt;code>pinball&lt;/code>&lt;/dfn> attribute must return its value. Initially its value must be null.<br />
<br />
Setting the &lt;code>pinball&lt;/code> attribute must set its value to the given value.<br />
<br />
Sometimes it gets a little bit more complicated and you need to use steps:<br />
<br />
&lt;p>Setting the &lt;code>pinball&lt;/code> attribute must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>If the &lt;span>readonly flag&lt;/span> is set, terminate these steps.<br />
&lt;li>&lt;p>Set the attribute to the given value.<br />
&lt;/ol><br />
<br />
Keep this in mind:<br />
<br />
* Include requirements for setting the attribute to ''any'' value, not just to valid values. For example, an attribute that requires a float value must also prescribe what the browser does when the value is set to values of Infinity, zero, or NaN (not a number), unless that is already defined by IDL.<br />
<br />
* You can omit the "must" statement here for each step (as in the example above) if your conformance section says it is implied. The HTML spec, for example, says in its conformance section that "Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm".<br />
<br />
* Attributes that return objects should always return the same object. Having an attribute that returns a new attribute each time it is accessed can make seemingly innocuous scripts perform a lot of expensive operations — for example, if such an attribute is used in a loop, every single iteration of the loop would involve allocating and initialising a new object.<br />
<br />
===Defining a method===<br />
<br />
Defining a simple method can be done as follows:<br />
<br />
The &lt;dfn>&lt;code>timesTwo(&lt;var>num&lt;/var>)&lt;/code>&lt;/dfn> method must return &lt;var>num&lt;/var> &times; 2.<br />
<br />
If the method is more complicated (or you feel like being more verbose) a list of steps can be used instead:<br />
<br />
&lt;p>The &lt;dfn>&lt;code>add(&lt;var>num1&lt;/var>, &lt;var>num2&lt;/var>)&lt;/code>&lt;/dfn> method must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>Let &lt;var>result&lt;/var> be &lt;var>num1&lt;/var> + &lt;var>num2&lt;/var>.<br />
&lt;li>&lt;p>Return &lt;var>result&lt;/var>.<br />
&lt;/ol><br />
<br />
Using steps helps implementors and QA making sure they have covered all the requirements.<br />
<br />
===Dealing with exceptions===<br />
<br />
Sometimes a method needs to throw an exception:<br />
<br />
&lt;p>The &lt;dfn>&lt;code>isCuteAnimal(&lt;var>animal&lt;/var>)&lt;/code>&lt;/dfn> method must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>If &lt;var>animal&lt;/var> is not "&lt;code>cat&lt;/code>",<br />
&lt;span data-anolis-spec=dom title=concept-throw>throw&lt;/span> an "&lt;code>UnknownAnimalError&lt;/code>" exception<br />
and terminate these steps.<br />
<br />
It is important to state whether the algorithm should be terminate when the exception is thrown or not; in some cases, an algorithm will continue even after an exception is thrown (e.g. to do some cleanup).<br />
<br />
===Events===<br />
<br />
Just dispatching an event is rather trivial:<br />
<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=dom>Fire an event&lt;/span> named &lt;code>tralala&lt;/code><br />
at the &lt;span data-anolis-spec=dom title=concept-document>document&lt;/span>.<br />
<br />
However, often the situation is more complicated. Events may need to be dispatched from within a [http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task task] (see asynchronous below), listeners for the event can change the environment, events may need their own event object (to expose certain attributes), etc.<br />
<br />
====Asynchronous events====<br />
<br />
In certain circumstances the method returns "early", but the algorithm keeps going. This is done to ensure that the user interface does not lock up while running potentially expensive operations:<br />
<br />
&lt;li>&lt;p>Return, but continue running these steps asynchronouusly.<br />
&lt;li>&lt;p>Let &lt;var>visible&lt;/var> be the number of cute animals in the user's surroundings.<br />
&lt;li>&lt;p>If &lt;var>visible&lt;/var> is zero, terminate these steps.<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=html>Queue&lt;/span> a &lt;span data-anolis-spec=html>task&lt;/span><br />
to &lt;span data-anolis-spec=dom>fire an event&lt;/span> named &lt;code>spotted&lt;/code> at the<br />
&lt;span>context object&lt;/span>.<br />
<br />
To still let the developer know of the effects of the method an event has to be dispatched. This is done using the "fire an event" concept from the DOM. As it cannot be dispatched synchronously since it happens in an operation running asynchronously from JavaScript's perspective, the event loop has to be used (queuing a task).<br />
<br />
===="Cancelable" events====<br />
<br />
Certain events are dispatched as part of an operation and allow the developer to choose whether to continue running the operation. These are often referred to as "cancelable events" (although actually the operation is cancelable). You can integrate these as follows:<br />
<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=dom>Fire an event&lt;/span> named &lt;code>hanginthere&lt;/code> <br />
at the &lt;span>context object&lt;/span>.<br />
&lt;li>&lt;p>If the event's &lt;span>canceled flag&lt;/span> is set, terminate these steps.<br />
&lt;li>&lt;p>&hellip; eat all the things &hellip;<br />
<br />
====Events implementing their own interface====<br />
<br />
Often events are not just about notification, but also carry additional information. To make that work you will need to define your own event interface.<br />
<br />
&lt;pre class=idl>[Constructor(DOMString &lt;var>type&lt;/var>, optional &lt;span>PonyEventInit&lt;/span> &lt;var>eventInitDict&lt;/var>)]<br />
interface &lt;dfn>PonyEvent&lt;/dfn> : &lt;span data-anolis-spec=dom>Event&lt;/span> {<br />
readonly attribute DOMString &lt;span title=dom-PonyEvent-hairColor>hairColor&lt;/span>;<br />
};<br />
<br />
dictionary &lt;dfn>PonyEventInit&lt;/dfn> {<br />
DOMString hairColor;<br />
};&lt;/pre><br />
<br />
&lt;p>The &lt;dfn title=dom-PonyEvent-hairColor>&lt;code>hairColor&lt;/code>&lt;/dfn> attribute must<br />
return the value it was initialized to. When an <br />
&lt;span data-anolis-spec=dom title=concept-event>event&lt;/span> is created it must be<br />
initialized to "&lt;code>rainbow&lt;/code>".<br />
<br />
Defining the constructor is "magically" taken care of by the [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events constructing events] chapter of DOM. Dispatching an event implementing its own interface requires a bit more wording as well. See the [http://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html#concept-event-fire-progress "fire a progress event named e"] for an example.<br />
<br />
====Event handler attributes====<br />
<br />
HTML defines [http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#events event handlers]. Introducing these on objects upon which events are dispatched is common practice. Excluding markup, the IDL for adding a "colorchange" event's handler would be:<br />
<br />
attribute EventHandler oncolorchange;<br />
<br />
In prose you use the following language (replacing "Pony" with the name of the interface and "colorchange" with the name of the event):<br />
<br />
&lt;p>The following are the &lt;span data-anolis-spec=html>event handlers&lt;/span> (and their corresponding <br />
&lt;span data-anolis-spec=html title="event handler event type">event handler event types&lt;/span>) that must <br />
be supported on objects implementing the &lt;code>Pony&lt;/code> interface:<br />
<br />
&lt;table><br />
&lt;thead><br />
&lt;tr><br />
&lt;th>&lt;span data-anolis-spec=html title="event handler">event handler&lt;/span><br />
&lt;th>&lt;span data-anolis-spec=html>event handler event type&lt;/span><br />
&lt;tbody><br />
&lt;tr><br />
&lt;td>&lt;dfn title="event-colorchange">&lt;code>oncolorchange&lt;/code>&lt;/dfn><br />
&lt;td>&lt;code>colorchange&lt;/code><br />
&hellip;<br />
<br />
===Callbacks===<br />
<br />
&lt;p>The &lt;dfn>&lt;code>getInspiration(&lt;var>callback&lt;/var>)&lt;/code>&lt;/dfn> method must run these steps:<br />
&lt;ol><br />
&lt;li>&lt;p>Return, but continue running these steps asynchronously.<br />
&lt;li>&lt;p>Let &lt;var>result&lt;/var> be the result of running &lt;span>magic&lt;/span>.<br />
&lt;li>&lt;p>&lt;span data-anolis-spec=html>Queue&lt;/span> a &lt;span data-anolis-spec=html>task&lt;/span><br />
to invoke &lt;var>callback&lt;/var> with &lt;var>result&lt;/var> as argument and &lt;span>context object&lt;/span><br />
as &lt;span>callback this value&lt;/span>.<br />
<br />
Note that here we define the object the method was invoked upon as the [http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-this-value callback this value]. If you want the callback object itself to the this value you do not have to specify it, as that is the default.<br />
<br />
When dealing with the event loop (task queuing) the task source also needs to be clear. See &lt;canvas>'s [http://www.whatwg.org/C#dom-canvas-toblob toBlob()] method for an example.<br />
<br />
== References ==<br />
<br />
The following references provide useful information about specification writing and tools to aid the process of writing and producing a specification.<br />
<br />
* '''Language and terminology:''' [http://www.ietf.org/rfc/rfc2119.txt RFC2119]. This document explains when and why to use those spec'y verbs like ''must'', ''may'', and ''should''.<br />
* '''Interface definitions:''' [http://dev.w3.org/2006/webapi/WebIDL/ Web IDL]. This document defines an interface definition language (IDL) that is useful for describing interfaces intended to be implemented in web browsers. It defines how to write the IDL blocks, how to overload methods, and the basics of common JavaScript bindings. This standard format helps to streamline the definitions for common script objects and allows the spec to focus on defining the unique aspects of the requirements.<br />
* '''Formatting tool: '''[[Anolis]]. This irreverently named tool defines special markup elements that are processed by a Python script that adds the proper spec numbering, cross references, and table of contents. It's magic! [http://hg.gsnedders.com/anolis/raw-file/tip/example.src.html This page] demonstrates use of the prescribed markup elements.<br />
* '''Also useful:''' [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]. It's always good to keep the Big Picture in mind.<br />
<br />
== More ==<br />
<br />
Here are some links to sources that might be helpful in expanding the above:<br />
<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032361.html<br />
<br />
== Legacy DOM-style ==<br />
<br />
The old DOM specifications had a particular style of defining methods and attributes that is strongly discouraged (the separation of method definition from arguments, exceptions, and return value). Unfortunately ReSpec.js uses this style by default (consider using [[Anolis]]). E.g. the [http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-adoptNode <code>adoptNode()</code> method] in DOM Level 3 Core does not define which exception would be thrown first and more importantently it is not clear at all what the processing model is as you have to piece it together from various independent pieces of information. Therefore please follow the patterns outlined above as demonstrated by the [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-adoptnode <code>adoptNode()</code> method] in DOM.<br />
<br />
[[Category:Specification editing]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9245New Features Awaiting Implementation Interest2013-07-16T18:20:00Z<p>Hixie: </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><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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9244New Features Awaiting Implementation Interest2013-07-16T18:04:09Z<p>Hixie: </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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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><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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9243New Features Awaiting Implementation Interest2013-07-16T00:02:03Z<p>Hixie: </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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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><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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9242New Features Awaiting Implementation Interest2013-07-15T23:27:23Z<p>Hixie: </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>[[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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9241New Features Awaiting Implementation Interest2013-07-15T21:37:06Z<p>Hixie: </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>[[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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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><br />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=FAQ&diff=9238FAQ2013-07-12T20:16:46Z<p>Hixie: /* Which group has authority in the event of a dispute? */</p>
<hr />
<div>== The WHATWG ==<br />
<br />
=== What is the WHATWG? ===<br />
<br />
The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.<br />
<br />
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.<br />
<br />
=== What is the WHATWG working on? === <br />
<br />
The WHATWG's main focus is the HTML standard, which also includes Web Workers, Web Storage, the Web Sockets API, and Server-Sent Events. Occasionally, specifications outside WHATWG space are discussed on the WHATWG mailing list; recent examples include a crypto API, HTML editing APIs, and the UndoManager specification.<br />
<br />
In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] or its alternatives will bring us.<br />
<br />
=== How can I get involved? === <br />
<br />
There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!<br />
<br />
=== Is participation free? === <br />
<br />
Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C HTML WG] by going through the slightly longer application process.<br />
<br />
== The WHATWG Process ==<br />
<br />
=== How does the WHATWG work? ===<br />
<br />
People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.<br />
<br />
This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).<br />
<br />
This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.<br />
<br />
There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.<br />
<br />
Currently the editor is Ian Hickson.<br />
<br />
=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===<br />
<br />
Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [http://www.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 e-mailing him (ian@hixie.ch for HTML), or contacting him on [[IRC]] (For HTML, Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.<br />
<br />
Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.<br />
<br />
=== {{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.<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 [http://www.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 [http://www.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 specification can change at any time? ===<br />
<br />
The specification does not change arbitrarily: we are extremely careful! As parts of the 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 specification is never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)<br />
<br />
=== What parts of the specification are stable? ===<br />
<br />
You can see which parts of the spec are stable and which are not from the status annotations in the left margin.<br />
<br />
In practice, implementations all follow the latest specification drafts anyway, not the 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!<br />
<br />
== HTML5 ==<br />
<br />
=== What is HTML5? === <br />
<br />
[http://www.whatwg.org/specs/web-apps/current-work/ HTML] is the main focus of the WHATWG community. HTML5 is a snapshot of HTML, which is being worked on by the WHATWG community and also the W3C HTML Working Group.<br />
<br />
HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.<br />
<br />
Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.<br />
<br />
=== How can I keep track of changes to the spec? === <br />
<br />
There are a number of ways to track changes to the spec:<br />
<br />
* The Twitter feed: http://twitter.com/WHATWG (non-editorial changes only)<br />
<br />
* You may use the online [http://html5.org/tools/web-apps-tracker HTML5 Tracker]. The tool provides an online interface for selecting and comparing revisions of the spec.<br />
<br />
* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org<br />
<br />
* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any SVN client to check out the latest version and use your client&rsquo;s diff tools to compare revisions and see what has been changed.<br />
<br />
* At a broader level, Anne and Simon are maintaining a document that gives a high-level overview of changes to HTML over the last decade or so, as well as occasionally listing changes between versions a few months apart: http://dev.w3.org/html5/html4-differences/<br />
<br />
* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html<br />
<br />
* The W3C provide diff-marked HTML versions for each change that affect the W3C copy of the spec by e-mail: http://lists.w3.org/Archives/Public/public-html-diffs/latest<br />
<br />
=== What are the various versions of the spec? ===<br />
<br />
All active work at WHATWG is gathered in the HTML Standard. It is available in two forms: [http://www.whatwg.org/specs/web-apps/current-work/ single-page] (''very large'') and '''[http://whatwg.org/C multi-page]'''.<br />
<br />
Different parts of this specification are also published at the W3C as smaller snapshots.<br />
<br />
The following table lists in the individual specifications included:<br />
<br />
{| class="wikitable" border=1 cellpadding=3 cellspacing=0<br />
|-<br />
!<br />
! Sections of the WHATWG specification<br />
! Corresponding W3C specifications<br />
|-<br />
! HTML, DOM HTML, and XHTML<br />
| [http://www.whatwg.org/specs/web-apps/current-work/ Single-page], [http://whatwg.org/C multi-page]<br />
| Subset as [http://dev.w3.org/html5/spec/Overview.html single-page], [http://dev.w3.org/html5/spec/ multi-page] (HTML WG)<br />
|-<br />
! Microdata<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata Microdata]<br />
| [http://dev.w3.org/html5/md/ Microdata] (HTML WG)<br />
|-<br />
! Canvas 2D Context<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext The 2D Context]<br />
| [http://dev.w3.org/html5/2dcontext/ 2D Context] (HTML WG)<br />
|-<br />
! window.postMessage()<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging]<br />
|rowspan=2| [http://dev.w3.org/html5/postmsg/ HTML5 Web Messaging] (WebApps WG)<br />
|-<br />
! MessagePort<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging Channel messaging]<br />
|-<br />
! Web Workers<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Web Workers]<br />
| [http://dev.w3.org/html5/workers/ Web Workers] (WebApps WG)<br />
|-<br />
! Web Storage<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html Web Storage]<br />
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)<br />
|-<br />
! Web Sockets API<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html Web Sockets]<br />
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)<br />
|-<br />
! Server-Sent Events<br />
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#server-sent-events Server-sent Events]<br />
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)<br />
|}<br />
<br />
Web SQL Database no longer exists. The Web Socket Protocol specification is now done entirely by the IETF. The PeerConnection API has been taken over by the W3C.<br />
<br />
All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].<br />
<br />
=== Are there versions of the specification aimed specifically at authors/implementors? ===<br />
<br />
Yes! [http://developers.whatwg.org/ http://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 />
* http://dev.opera.com/articles/html/<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, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now. For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you&#8217;ll begin to understand why the time frame seems so long.<br />
<br />
Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.<br />
<br />
=== What about Microsoft and Internet Explorer? === <br />
<br />
Microsoft has already started implementing parts of HTML5 in IE8 and is adding more to IE9.<br />
<br />
HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.<br />
<br />
=== Is design rationale documented? ===<br />
<br />
Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.<br />
<br />
For a few cases that someone did take the time document, the information can be found at the following locations:<br />
<br />
* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend]] or another ''mini-header'' element.<br />
<br />
Also see ''HTML feature proposals'' below.<br />
<br />
== HTML syntax issues ==<br />
<br />
=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? === <br />
<br />
Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''<br />
<br />
=== What will the DOCTYPE be? === <br />
<br />
In HTML:<br />
<br />
<code>&lt;!DOCTYPE html&gt;</code><br />
<br />
In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.<br />
<br />
For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.<br />
<br />
<code>&lt;!DOCTYPE html SYSTEM "about:legacy-compat"&gt;</code><br />
<br />
Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.<br />
<br />
Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code>&lt;!DOCTYPE HTML&gt;</code> or <code>&lt;!doctype html&gt;</code>.<br />
<br />
These alternatives were chosen because they meet the following criteria:<br />
<br />
* They trigger standards mode in all current and all relevant legacy browsers.<br />
* They are well-formed in XML and can appear in XHTML documents.<br />
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.<br />
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.<br />
* The first is short and memorable to encourage its use.<br />
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.<br />
<br />
=== Under what conditions should a DOCTYPE be used in XHTML? ===<br />
<br />
Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:<br />
<br />
# The document is intended to be a polyglot document that may be served as both HTML or XHTML.<br />
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)<br />
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].<br />
<br />
Fundamentally, this is an XML issue, and is not specific to XHTML.<br />
<br />
=== How are documents from HTML4 and earlier versions parsed? ===<br />
<br />
All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.<br />
<br />
Validators are allowed to have different code paths for previous levels of HTML.<br />
<br />
=== If there is no DTD, how can I validate my page? === <br />
<br />
With an [http://validator.whatwg.org/ HTML validator] that follows the latest specification.<br />
<br />
=== What is an HTML Serialization? === <br />
<br />
The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.<br />
<br />
Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.<br />
<br />
=== What is an XML (or XHTML) Serialization? === <br />
<br />
The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is &#8220;html&#8221; in the HTML namespace, the document is referred to as an XHTML document.<br />
<br />
=== What MIME type does HTML use? === <br />
<br />
The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.<br />
<br />
The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.<br />
<br />
Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.<br />
<br />
=== Should I close empty elements with <code>/&gt;</code> or <code>&gt;</code>? === <br />
<br />
Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code>&lt;br /&gt;</code>, you only need to write <code>&lt;br&gt;</code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.<br />
<br />
The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.<br />
<br />
=== If I&#8217;m careful with the syntax I use in my HTML document, can I process it with an XML parser? === <br />
<br />
Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].<br />
<br />
A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.<br />
<br />
=== What is the namespace declaration? === <br />
<br />
In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]<br />
<br />
&lt;html xmlns="http://www.w3.org/1999/xhtml"&gt;<br />
<br />
In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value &#8220;<code>http://www.w3.org/1999/xhtml</code>&#8220;. It doesn&#8217;t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn&#8217;t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].<br />
<br />
=== Will there be support for namespaces in HTML? === <br />
<br />
HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.<br />
<br />
In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.<br />
<br />
In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.<br />
<br />
=== How do I specify the character encoding? === <br />
<br />
For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:<br />
<br />
&lt;meta charset="UTF-8"&gt;<br />
<br />
The following restrictions apply to character encoding declarations:<br />
<br />
* The character encoding name given must be the name of the character encoding used to serialize the file.<br />
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.<br />
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.<br />
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.<br />
<br />
Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.<br />
<br />
For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".<br />
<br />
To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)<br />
<br />
&lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8"&gt;<br />
<br />
In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.<br />
<br />
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br />
<br />
Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.<br />
<br />
=== What are the differences between HTML and XHTML? === <br />
<br />
See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.<br />
<br />
=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===<br />
<br />
Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.<br />
<br />
Case sensitivity :<br />
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).<br />
Namespaces:<br />
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)<br />
<br />
=== Why does this new HTML spec legitimise tag soup? === <br />
<br />
Actually it doesn&#8217;t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.<br />
<br />
Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.<br />
<br />
For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.<br />
<br />
Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.<br />
<br />
However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.<br />
<br />
For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.<br />
<br />
It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.<br />
<br />
== HTML feature proposals ==<br />
<br />
=== HTML should support <code>href</code> on any element! === <br />
<br />
The spec allows &lt;a&gt; to contain blocks. It doesn't support putting href="" on any element, though.<br />
<br />
Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:<br />
<br />
* It isn&#8217;t backwards compatible with existing browsers.<br />
* It adds no new functionality that can&#8217;t already be achieved using the <code>a</code> element and a little script.<br />
* It doesn&#8217;t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.<br />
<br />
The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.<br />
<br />
Wrapping &lt;a&gt; elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:<br />
<pre><br />
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr><br />
</pre><br />
<br />
=== HTML should support list headers! ===<br />
<br />
You can give a header to a list using the <figure> and <figcaption> elements:<br />
<br />
<pre><br />
<figure><br />
<figcaption>Apples</figcaption><br />
<ul><br />
<li>Granny Smith</li><br />
<li>Evil Apple of Knowledge</li><br />
<li>Apple, Inc</li><br />
</ul><br />
</figure><br />
</pre><br />
<br />
You can also label a group of lists using a definition list:<br />
<br />
<pre><br />
<dl><br />
<dt>Dry:</dt><br />
<dd><br />
<ul> <br />
<li>1c flour</li> <br />
<li>1/4c sugar</li><br />
<li>1tsp baking soda</li><br />
</ul><br />
</dd><br />
<dt>Wet:</dt><br />
<dd><br />
<ul> <br />
<li>1 egg </li><br />
<li>1/2c milk</li><br />
<li>1tsp vanilla extract</li><br />
</ul><br />
</dd><br />
</dl><br />
</pre><br />
<br />
These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near &lt;li> elements.<br />
<br />
=== HTML should support a way for anyone to invent new elements! ===<br />
<br />
There are actually quite a number of ways for people to invent their own extensions to HTML:<br />
<br />
* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.<br />
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.<br />
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.<br />
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.<br />
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.<br />
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.<br />
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.<br />
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.<br />
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)<br />
<br />
There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.<br />
<br />
We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.<br />
<br />
=== HTML should group &lt;dt>s and &lt;dd>s together in &lt;di>s! === <br />
<br />
This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.<br />
<br />
There are multiple problems with adding something like &lt;di>:<br />
<br />
* It would require parsing changes. These are relatively expensive.<br />
* It would have a poor backwards-compatibility story until the parsers were all updated.<br />
* It would have a poor backwards-compatibility story with legacy code that handles &lt;dl>s, since they're not expecting &lt;di>s.<br />
<br />
The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).<br />
<br />
=== Why are some presentational elements like &lt;b>, &lt;i> and &lt;small> still included? ===<br />
<br />
The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.<br />
<br />
While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.<br />
<br />
Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.<br />
<br />
Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.<br />
<br />
In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.<br />
<br />
This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The &lt;b> and &lt;i> Elements]</cite><br />
<br />
Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.<br />
<br />
==== But they are PRESENTATIONAL! ====<br />
<br />
The problem with elements like &lt;font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While &lt;b>, &lt;i> and &lt;small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, &lt;small> corresponds to the really quickly spoken part at the end of radio advertisements.<br />
<br />
=== The &lt;cite> element should allow names of people to be marked up ===<br />
<br />
From what some have seen, &lt;cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.<br />
<br />
So, we can't really decide what the element should be based on past practice, like we usually do.<br />
<br />
This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for &lt;cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.<br />
<br />
There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, &lt;span> and class names, etc), if you really need it.<br />
<br />
=== The &lt;time> element should allow vague times ("March") and times from ancient history to be marked up ===<br />
<br />
This has been discussed a number of times. For an overview of the topic, please see these e-mails:<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html<br />
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html<br />
At this stage, as discussed in the second of those e-mails, the best way forward is to demonstrate that there are communities interested in solving this problem, by using existing techniques such as microdata to address it. If such a solution achieves a high adoption rate, that will substantially increase the strength of the proposals.<br />
<br />
(In the future, it is expected that the &lt;time> element will be dropped. See [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240])<br />
<br />
=== &lt;input type="text"> needs a minlength="" attribute ===<br />
<br />
This has been discussed, but we are waiting for browsers to catch up with the many new form features before adding new ones like minlength="".<br />
<br />
=== 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 />
* 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, they have to be maintained<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 />
* [http://www.whatwg.org/specs/web-apps/current-work/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 />
== 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 e-mail 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 e-mails in your replies.'''<br />
<br />
Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your e-mail makes sense on its own, as it will probably be read out of context years later.<br />
<br />
That is, you should reply like this:<br />
<br />
<pre><br />
Ian wrote:<br />
> What do you want? <br />
<br />
I want cats!<br />
<br />
> When do you want it?<br />
<br />
Now!<br />
</pre><br />
<br />
You should definitely not reply like this (because this requires people to read your e-mail backwards):<br />
<br />
<pre class="error" ><br />
No<br />
<br />
Ian wrote:<br />
> Is this a good example of how to post e-mails?<br />
</pre><br />
<br />
You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):<br />
<br />
<pre class="error" ><br />
This is a bad way to write e-mail.<br />
<br />
Ian wrote:<br />
> Is this a good way to write e-mail?<br />
> Lorem ipsum foo bar baz.<br />
> Unrelated other bits that aren't replied to.<br />
> Yet more text<br />
</pre><br />
<br />
You should also not reply like this (with no context at all), because the reader will not know what you are referring to:<br />
<br />
<pre class="error" ><br />
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.<br />
</pre><br />
<br />
Quote enough original text or provide an introduction yourself.</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9237New Features Awaiting Implementation Interest2013-07-12T18:17:51Z<p>Hixie: </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>[[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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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><br />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=9172New Features Awaiting Implementation Interest2013-06-14T17:36:52Z<p>Hixie: </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>[[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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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><br />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=Specs/todo&diff=9071Specs/todo2013-03-22T18:50:40Z<p>Hixie: /* Platform */</p>
<hr />
<div>There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch, post on the WHATWG mailing list or say something on [[IRC]].<br />
<br />
See also: [[Specs|Specs with editors]], [[Howto spec]].<br />
<br />
== Platform ==<br />
<br />
* A specification that defines how XML maps to DOM Core. (I think this should be in DOM Parsing and Serialization. Well really in XML.)<br />
* X-Frames-Options<br />
* multipart/form-data<br />
* HTTP (error handling in particular)<br />
* APNG (other image formats too maybe?)<br />
* HTML editing: the spec is quite mature, but needs more work<br />
<br />
== APIs ==<br />
<br />
* User Interaction Events (onclick, onkeypress, etc).<br />
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus<br />
** setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]<br />
** [http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1719 selectstart] (WebKit/IE)<br />
* An API for cryptography, to generate keys and the like<br />
* The console.* API. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694] [http://www.w3.org/mid/d7be01cb7077$4dd45010$e97cf030$@gmail.com] [http://sideshowbarker.github.com/console-spec/]<br />
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html<br />
* [[DOM XPath]]<br />
<br />
== CSS ==<br />
<br />
There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:<br />
* Table Layout<br />
** http://dbaron.org/css/intrinsic/<br />
** http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm<br />
* Replaced Content<br />
** http://dev.w3.org/csswg/css3-content/ (Do we still want this or is the component model sufficient?)<br />
* an imperative model of box-tree construction<br />
* hit testing per http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html<br />
<br />
== Registries ==<br />
<br />
Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:<br />
<br />
* MIME types<br />
* Schemes<br />
<br />
It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).<br />
<br />
See also: [[Registries]]<br />
<br />
== MISC ==<br />
* an API to do syntax highlighting on &lt;textarea>, &lt;pre>, and contenteditable sections would be highly popular with Web developers (ack Ryan Johnson). (This would probably best be done as some sort of output filter at the CSS level, rather than anything HTML-specific.)<br />
* Animated GIFs need a spec that, in particular, specifies how to handle timings (not all browsers honour all values, so we should specify what needs to be honoured exactly)<br />
** GIF87a: [http://web.archive.org/web/20100929230301/http://www.etsimo.uniovi.es/gifanim/gif87a.txt Text] (Stanford) / [http://www.w3.org/Graphics/GIF/spec-gif87.txt Text] (W3C)<br />
** GIF89a: [http://www.w3.org/Graphics/GIF/spec-gif89a.txt Text] / [http://odur.let.rug.nl/~kleiweg/gif/GIF89a.html HTML]<br />
** [http://www.matthewflickinger.com/lab/whatsinagif/ What's in a GIF]<br />
** [http://odur.let.rug.nl/~kleiweg/gif/netscape.html GIF Application Extension: NETSCAPE2.0]<br />
** [http://www.theimage.com/animation/toc/toc.html Gifology: Understanding GIF Files & GIF Animation]<br />
** [http://web.archive.org/web/20100929231133/http://www.etsimo.uniovi.es/gifanim/gifabout.htm All About GIF89a]<br />
* Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/20101101063413.bf1d8102.eric@bisonsystems.net)<br />
* innerText and outerText, if browsers don't remove them entirely<br />
<br />
== Other stuff ==<br />
<br />
http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has a description of some sections that needed editing in 2008 and how much work they would be.<br />
<br />
Some notes from the HTML5 spec about things that need doing:<br />
<br />
* support access Array element via () instead of [] (IEism) https://bugzilla.mozilla.org/show_bug.cgi?id=289876<br />
* Need to say that NodeList's items are enumerable, so that... for (var x in myNodeList) { } ...works. (ack Dethe Elza)<br />
* a way to show icons for file types e.g. http://www.gadgetopia.com/2004/05/04/FileIconTag.html (this should probably be a function for the 'content', 'background-image' and 'list-style-image' properties in CSS)<br />
** Maybe something like moz-icon://? http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0255.html, http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html<br />
<br />
[[Category:Spec_coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=CanvasInWorkers&diff=8971CanvasInWorkers2013-02-07T21:26:57Z<p>Hixie: Created page with "blank"</p>
<hr />
<div>blank</div>Hixiehttps://wiki.whatwg.org/index.php?title=Who_to_ask_about_stuff&diff=8946Who to ask about stuff2013-01-31T22:49:46Z<p>Hixie: /* IE */</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 and jgraham.<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>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8935New Features Awaiting Implementation Interest2013-01-25T18:19:03Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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><br />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=Components&diff=8924Components2013-01-11T23:09:24Z<p>Hixie: </p>
<hr />
<div>This page discusses pros and cons of various inline component binding syntaxes.<br />
<br />
The hard requirements are:<br />
# The binding has to be done at element creation time<br />
# The binding has to be immutable during element lifetime<br />
# The syntax must not make authors think the binding is mutable<br />
# The syntax must be as terse as possible<br />
# The syntax has to convey the element's standard semantics (a specified HTML tag name) in the document markup, for legacy UAs and future non-supporting UAs like spiders.<br />
# Musn't step on the HTML vocabulary namespace (where it would prevent future standard extensions)<br />
# Needs to encourage authors to put a real semantic rather than just skipping that step.<br />
<br />
The proposals below show the syntax for binding a "geomap" component to a &lt;select> element:<br />
<br />
== Proposal: &lt;geomap>&lt;/geomap> ==<br />
<br />
Meets: 1, 2, 3, 4<br />
Fails: 5, 6, 7<br />
<br />
Pro: Looks good to the original author — this is the closest thing to extending the language that we could do.<br />
<br />
Con: Doesn't say what the standard semantic is. Throws random names into the tag namespace - makes it hard to add new tags.<br />
<br />
== Proposal: &lt;x-geomap>&lt;/x-geomap> ==<br />
<br />
Meets: 1, 2, 3, 4, 6, 7<br />
Fails: 5<br />
<br />
Pro: Looks like a new element.<br />
<br />
Con: The standard semantic is located on the <element> element, somewhere else in the document or in a linked document.<br />
<br />
== Proposal: &lt;select is="geomap"> .. &lt;/select> ==<br />
<br />
Meets: 1, 2, 5, 6, 7<br />
Fails: 3, 4<br />
<br />
Pro: No parser change. Vanilla html, no tools break, no parser harmed during the making.<br />
<br />
Con: Authors have assumed that it means they can change the binding.<br />
<br />
== Proposal: &lt;select/geomap> .. &lt;/select> ==<br />
<br />
Meets: 1, 2, 3, 4, 5, 6, 7<br />
<br />
Pro: Meets all requirements.<br />
<br />
Con: New syntax, requires parser changes and would be unfamiliar to today's authors. Requires authors to repeat the real semantic for every component instance. Shims might be hard to implement generically since in legacy UAs the component name would end up as an unadorned attribute.<br />
<br />
== Proposal: &lt;x-geomap>&lt;select> .. &lt;/select>&lt;/x-geomap> ==<br />
<br />
Meets: 1, 2, 3, 5, 6<br />
Fails: 4, 7<br />
<br />
Pro: Looks like it allows new elements.<br />
<br />
Con: Doesn't actually bind the component to the fallback, so you end up with two elements instead of one. Authors will quickly stop including the fallback when they realise it doesn't give _them_ any immediate benefit.<br />
<br />
== Proposal: &lt;x-geomap> for the default extension (specified in &lt;element>), &lt;x-geomap/select> to override the extension ==<br />
<br />
Meets: 1, 2, 3, 4, 6, 7<br />
Fails: 5<br />
<br />
Pro: Looks like a new element. Tagname is the same in both modern and legacy UAs. Allows authors to add an API to an entire class of element (all <hN> elements, all sectioning elements, etc.) without having to define multiple components.<br />
<br />
Con: Requires parsers to read the (possibly linked) element definitions to know what the default extensions are. Requires parser changes to support the override extension.</div>Hixiehttps://wiki.whatwg.org/index.php?title=Components&diff=8911Components2013-01-11T20:17:29Z<p>Hixie: Created page with "This page discusses pros and cons of various inline component binding syntaxes. The hard requirements are: 1. The binding has to be done at element creation time 2. The bindi..."</p>
<hr />
<div>This page discusses pros and cons of various inline component binding syntaxes.<br />
<br />
The hard requirements are:<br />
1. The binding has to be done at element creation time<br />
2. The binding has to be immutable during element lifetime<br />
3. The syntax must not make authors think the binding is mutable<br />
4. The syntax must be as terse as possible<br />
5. The syntax has to convey the element's standard semantics (a specified HTML tag name) in the document markup, for legacy UAs and future non-supporting UAs like spiders.<br />
6. Musn't step on the HTML vocabulary namespace (where it would prevent future standard extensions)<br />
7. Needs to encourage authors to put a real semantic rather than just skipping that step.<br />
<br />
The proposals below show the syntax for binding a "geomap" component to a &lt;select> element:<br />
<br />
== Proposal: &lt;geomap>&lt;/geomap> ==<br />
<br />
Meets: 1, 2, 3, 4<br />
Fails: 5, 6, 7<br />
<br />
Pro: Looks good to the original author — this is the closest thing to extending the language that we could do.<br />
Con: Doesn't say what the standard semantic is.<br />
<br />
== Proposal: &lt;x-geomap>&lt;/x-geomap> ==<br />
<br />
Meets: 1, 2, 3, 4, 6<br />
Fails: 5, 7<br />
<br />
Pro: Looks like a new element.<br />
Con: Doesn't say what the standard semantic is. The "x-" prefix is ugly.<br />
<br />
== Proposal: &lt;select is="geomap"> .. &lt;/select> ==<br />
<br />
Meets: 1, 2, 5, 6, 7<br />
Fails: 3, 4<br />
<br />
Pro: No parser change.<br />
Con: Makes authors think they can change the binding.<br />
<br />
== Proposal: &lt;select/geomap> .. &lt;/select> ==<br />
<br />
Meets: 1, 2, 3, 4, 5, 6, 7<br />
<br />
Pro: Meets all requirements.<br />
Con: Requires parser changes.<br />
<br />
== Proposal: &lt;x-geomap>&lt;select> .. &lt;/select>&lt;/x-geomap> ==<br />
<br />
Meets: 1, 2, 3, 5, 6<br />
Fails: 4, 7<br />
<br />
Pro: Looks like it allows new elements.<br />
Con: Doesn't actually bind the component to the fallback, so you end up with two elements instead of one. Authors will quickly stop including the fallback when they realise it doesn't give _them_ any immediate benefit.</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8909New Features Awaiting Implementation Interest2013-01-09T20:38:53Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8908New Features Awaiting Implementation Interest2013-01-09T20:38:20Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0098.html James Robinson]<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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8907New Features Awaiting Implementation Interest2013-01-09T20:00:38Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0089.html Negative feedback]<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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8905New Features Awaiting Implementation Interest2013-01-09T03:38:21Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html 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><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8904New Features Awaiting Implementation Interest2013-01-09T00:22:00Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8903New Features Awaiting Implementation Interest2013-01-09T00:21:43Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0253.html 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]<br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8898New Features Awaiting Implementation Interest2013-01-05T01:14:20Z<p>Hixie: </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>[[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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8897New Features Awaiting Implementation Interest2013-01-04T00:11:14Z<p>Hixie: </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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0082.html Progress events on &lt;img> elements]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0195.html Jonas Sicking]<br />
<td><br />
<td><br />
<td>[http://lists.webkit.org/pipermail/webkit-dev/2012-January/019182.html Dean Jackson]<br />
<td><br />
<td><br />
<td>Will likely be added soon<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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8894New Features Awaiting Implementation Interest2012-12-29T16:52:47Z<p>Hixie: </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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0082.html Progress events on &lt;img> elements]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0195.html Jonas Sicking]<br />
<td><br />
<td><br />
<td>[http://lists.webkit.org/pipermail/webkit-dev/2012-January/019182.html Dean Jackson]<br />
<td><br />
<td><br />
<td>Will likely be added soon<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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[https://bugzilla.mozilla.org/show_bug.cgi?id=655926 Canvas: fillRule]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0123.html Chris Jones]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8893New Features Awaiting Implementation Interest2012-12-29T07:38:01Z<p>Hixie: </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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0082.html Progress events on &lt;img> elements]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0195.html Jonas Sicking]<br />
<td><br />
<td><br />
<td>[http://lists.webkit.org/pipermail/webkit-dev/2012-January/019182.html Dean Jackson]<br />
<td><br />
<td><br />
<td>Will likely be added soon<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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[https://bugzilla.mozilla.org/show_bug.cgi?id=655926 Canvas: fillRule]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0123.html Chris Jones]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html 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><br />
<tr><br />
<td> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixiehttps://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&diff=8892New Features Awaiting Implementation Interest2012-12-29T07:20:24Z<p>Hixie: </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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0082.html Progress events on &lt;img> elements]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0195.html Jonas Sicking]<br />
<td><br />
<td><br />
<td>[http://lists.webkit.org/pipermail/webkit-dev/2012-January/019182.html Dean Jackson]<br />
<td><br />
<td><br />
<td>Will likely be added soon<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://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><br />
<tr><br />
<td>[https://bugzilla.mozilla.org/show_bug.cgi?id=655926 Canvas: fillRule]<br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0123.html Chris Jones]<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/2012Sep/0371.html 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>[http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/ 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>[[Meta_referrer|&lt;meta name="referrer">]]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Adam Barth<br />
<td><br />
<td><br />
<tr><br />
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html 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>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035065.html Prerendering APIs]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Gavin Peters<br />
<td><br />
<td><br />
<tr><br />
<td> [http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html &lt;template>] [https://www.w3.org/Bugs/Public/show_bug.cgi?id=17930 (bug)]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td> Rafael Weinstein<br />
<td><br />
<td><br />
<tr><br />
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0274.html 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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0532.html 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><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><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>[[FormData]]<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/2010Jul/0238.html Canvas: Stroke alignment]<br />
<td><br />
<td><br />
<td><br />
<td><br />
<td><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>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0001.html 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-whatwg-archive/2012Nov/0384.html Exception object as fifth argument to onerror]<br />
<td><br />
<td> zcorpan?<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 />
</table><br />
<br />
See also: [[Who to ask about stuff]]<br />
<br />
[[Category:Implementations]]<br />
[[Category:Spec coordination]]</div>Hixie