WHATWG Wiki - User contributions [en]

Rationale

2019-10-20T19:03:42Z

J9t: Corrected misc issues

This rationale document is supplemental to the WHATWG [https://html.spec.whatwg.org//multipage/ HTML Living Standard] specification. It is a work-in-progress.

== General Rationale ==

=== In overall terms, what determines what’s in the spec? ===

==== Already-implemented features ====
In the past, the contents of the spec tended to be determined by browsers’ de facto feature set. After all, one of the main purposes of the spec is to describe reality (regardless of what the spec editor, members, and contributors think). Historically, vendors competed with one another by implementing features without regard to any specification. It’s a relatively recent phenomenon that vendors compete by their conformance to the spec. That is to say, in the past, browsers tended to dictate what was in the spec, whereas today, it's the converse.

Thus, the spec must include all already-implemented features. A feature may be moved to the obsolete section if there is consensus that the feature should not be used in new content.

==== Member and contributor feedback ====
When adding features to the spec, the editor takes into account member and contributor feedback (via the WHATWG mailing list and IRC channel). If the editor believes inclusion of a feature is justified, he will add it to the spec. Ultimately, whether a feature remains in the spec depends on whether or not vendors (at least two) decide to implement the feature.

=== One vendor, one veto ===
Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such, browser vendors already have veto power—by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for <video> and <audio></a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref> The veto isn’t a power that we grant browsers; it’s a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref>

=== Why is everything else around us developing so fast, but the web is so slow to adopt anything?<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-October/041037.html</ref> ===
Because to get something adopted in a browser, you need to do the following (not always in this order):
<ol>
<li>Have someone design the feature.
<li>Have someone write a specification for it.
<li>Have some people write tests for it.
<li>Have one browser implement it.
<li>Have another browser implement it.
<li>Have another browser implement it.
<li>Have another browser implement it.
<li>Have people document it.
</ol>
This is in contrast to “everything else,” which just needs:
<ol>
<li>Someone to implement it.
</ol>

=== Using elements where scripts “work” ===
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref>

=== It isn’t just about web browsers ===
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won’t use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.

=== Experimenting with features ===
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref>

=== Versioning the spec ===
Most authors don’t care about whether or not an implementation supports an entire, full specification; they just want to know “Can I use this feature in this browser?” So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23306.html</ref>


=== Modifying existing semantics ===
Some elements have different semantics than what HTML users would expect. Semantic markup isn’t very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated <code>dd</code> as enclosing a term being defined, for the purposes of searching for definitions, it would not find many definitions, and it would misclassify things.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-October/000668.html</ref>

=== What is the purpose of defining elements semantically? ===
Semantic definitions allow HTML processors, such as Web browsers or search engines, to present and use documents and applications in a wide variety of contexts that the author might not have considered.<ref>https://html.spec.whatwg.org//multipage/elements.html#elements</ref>

Consider a Web page written by an author who only considered desktop computer Web browsers. Because HTML conveys meaning, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. Instead of headings being in large letters as on the desktop, for example, the browser on the mobile phone might use the same size text for the whole the page, but with the headings in bold.

The same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g., using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.

Since the browsers know which parts of the page are the headings, they can create a document outline that the user can use to quickly navigate around the document, using keys for “jump to next heading” or “jump to previous heading”. Such features are especially common with speech browsers, where users would otherwise find quickly navigating a page quite difficult.

Even beyond browsers, software can make use of this information. Search engines can use the headings to more effectively index a page, or to provide quick links to subsections of the page from their results. Tools can use the headings to create a table of contents (that is in fact how the table of contents of the WHATWG HTML specification is generated).

This example has focused on headings, but the same principle applies to all of the semantics in HTML.

=== Why is it important to stick to the semantics as defined in the spec? ===
Not adhering to the spec’s semantics prevents software that assumes and relies on said semantics from correctly processing the document.

For example, the following document is non-conforming, despite being syntactically correct:

<pre><!DOCTYPE HTML>
<html lang="en-GB">
<head> <title> Demonstration </title> </head>
<body>
<table>
<tr> <td> My favourite animal is the cat. </td> </tr>
<tr>
<td>
<a href="http://example.org/~ernest/"><cite>Ernest</cite></a>,
in an essay from 1992
</td>
</tr>
</table>
</body>
</html></pre>

…because the data placed in the cells is clearly not tabular data (and the <code>cite</code> element is misused). This would make software that relies on these semantics fail. For example, a speech browser that allowed a blind user to navigate tables in the document would report the quote above as a table, confusing the user; similarly, a tool that extracted titles of works from pages would extract “Ernest” as the title of a work, even though it’s actually a person’s name, not a title.

A corrected version of this document might be:

<pre><!DOCTYPE HTML>
<html lang="en-GB">
<head> <title> Demonstration </title> </head>
<body>
<blockquote>
 My favourite animal is the cat. 
</blockquote>

—<a href="http://example.org/~ernest/">Ernest</a>,
in an essay from 1992

</body>
</html></pre>

== Specific Elements ==

=== The DOCTYPE (Document Type Declaration) ===
Because HTML has moved to an unversioned model, the <code>DOCTYPE</code> does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a <code>DOCTYPE</code> is absent.

=== Document metadata ===

==== The <code>charset</code> attribute on the <code>meta</code> element in XML documents ====
The <code>charset</code> attribute on the <code>meta</code> element has no effect in XML documents; it is only allowed in order to facilitate migration to and from XHTML.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref>

==== Inclusion of the <code>application-name</code> metadata <code>name</code> value ====
User agents may want to use the Web application name in UI in preference to the page’s <code>title</code>, as the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.<ref>https://html.spec.whatwg.org//multipage/semantics.html#the-meta-element</ref>

==== On the continued inclusion of the <code>keyword</code> metadata <code>name</code> value ====
Considering that the <code>keyword</code> value has historically been used unreliably and even misleadingly as a way to spam search engine results (i.e., to garner higher search engine rankings), why is this feature still included in the spec? Because a content management system, for example, can use the keyword information of pages within the system to populate the index of a site-specific search engine. In short, keywords have use beyond the large-scale content aggregators (e.g., Google) that pervade the Web.

=== Sections ===

==== <code>hgroup</code> and other heading elements ====
The point of <code>hgroup</code> is to hide the subtitle from the outlining algorithm.

==== <code>header</code> and <code>footer</code> ====
<blockquote>The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.<ref>http://developers.whatwg.org/sections.html#the-footer-element</ref></blockquote>

=== Grouping content ===

==== The <code>blockquote</code> element ====

===== Why is it non-conforming to place attributions and inline citations inside the <code>blockquote</code> element? =====
Because the specification does not consider attributions and inline citations to be part of a block quote proper.<ref>http://developers.whatwg.org/grouping-content.html#the-blockquote-element</ref> In other words, the <code>blockquote</code> element represents only the quote itself.

=== Text-level semantics ===

=== Embedded content ===

==== On the status of <code>image</code> ====
The <code>image</code> element is treated as an alternate (but invalid) name for <code>img</code>. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.

==== The <code>img</code> element and alternate (<code>alt</code>) text ====
On certain types of pages adding alternate text (with the <code>alt</code> attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the <code>alt</code> attribute is optional. <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref>
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref>

=== Forms ===

==== <code>textarea</code> ====

The text area defaults to soft wrapping of the text area. The attribute @wrap can have one of the following values: soft, hard, or off.<ref>https://html.spec.whatwg.org//#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref>

==== <code>meter</code> and <code>progress</code> (are not the same thing) ====

<code>meter</code> is not just a special case of <code>progress</code>. The <code>meter</code> element represents a scalar measurement within a known range, such as storage quota usage, a relative popularity rating or relevance indicator. The control allows for the indication of high and low ranges, or minimum, maximum and optimal levels.

The <code>progress</code> element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload). <code>progress</code> elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref>

See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: <progress> draft] for details.

=== Interactive elements ===

==== <code>details</code> element ====
The <code>details</code> element is needed to provide an accessible way of reflecting a
common application widget in HTML-based applications without requiring authors
to use extensive scripting, <abbr title=Accessible Rich Interactive Applications>ARIA</abbr>, and platform-specific CSS to get the same
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref>

== HTML parsing ==

=== script element ===

Why the [https://html.spec.whatwg.org//multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [https://html.spec.whatwg.org//multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?

See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html

==== @defer and @async ====
async tells the browsers to run the script with its following content at the '''same''' time(namely, asynchronously).

defer tells the browsers to run the script '''later''', and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref>

=== Quirks mode ===
The HTML parser has [https://html.spec.whatwg.org//multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:

<blockquote><dl><dt>A start tag whose tag name is "table"
<dd>If the Document is not set to quirks mode, and the stack of open elements has a p element in scope, then act as if an end tag with the tag name "p" had been seen.</dl></blockquote>

Why? See http://hsivonen.iki.fi/last-html-quirk/

=== Ignored white space before head ===
White space before the <code><head></code> tag is ignored. The main reason is that, given the markup

<pre>
<!DOCTYPE html>
<html>
<head>
<title>Sample page</title>
...,
</pre>

some people expect

<pre>
document.documentElement.firstChild
</pre>

to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html [whatwg] several messages about the tree construction stage of HTML parsing]</cite></ref>




== Rejected proposals ==
A “<code><comment></code>” element for marking up user comments (i.e., user compositions in response to newspaper or magazine articles, blog entries, discussion topics, status updates, images, videos, etc.) ===

==== Why isn’t there an element for user comments? (e.g., <code><comment></code>) ====
There is: <code>article</code>.

==== But comments are not articles ====

Unfortunately, it is basically impossible for a single word or letter to stand for a careful description of an element’s semantics, and the element name “article” isn’t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref> The term “article” is defined broadly in HTML to include any complete or self-contained composition. This includes:
* forum posts
* newspaper articles
* magazine articles
* books
* blog posts
* comment on a forum post
* comment on a newspaper article
* comment on a magazine article
* comment on a blog post
* an embeddable interactive widget
* a post with a photograph on a social network
* a comment on a photograph on a social network
* a specification
* an e-mail
* a reply to an e-mail
Comments are considered articles—in the HTML sense—because they are complete compositions unto themselves i.e., they are not part of the piece of writing that they are commenting on (though they are obviously related to what they are commenting on, for example, “is in response to.” This relationship is demonstrated by nesting the comment article inside the article it’s responding to).

==== Surely the comment “LOL” is not an article? ====
According to the HTML spec, it is. It’s true that many comments need a context to be appreciated or fully understood, but then again many (most?, all?) newspaper or magazine articles need some greater context to be fully understood as well. The point is that the definition of <code>article</code> does not require a piece of writing to be fully intelligible on its own. All that matters is that the comment is separate from the thing that it’s commenting on. It’s that separateness that makes it an article (in the HTML sense).

==== Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc. ====
There’s no compelling argument that a dedicated <code>comment</code> element would make this meaningfully easier than nested <code>article</code> elements.

==== Comments can sometimes appear in a different region of the page than the composition they are referencing. By defining comments as nested articles, the spec is artificially forcing comments to be contained within the markup of the composition they are referencing. ====
No evidence has been put forth to suggest that this is a significant authorship issue.

==== Why should the spec suggest any one specific method for marking up comments? ====
If it is clear that an <code>article</code> within an <code>article</code> represents a comment, one can easily:
* programmatically find comments in HTML
* write interoperable style sheets for comments, using the selector <code>article > article</code>
* use HTML fragments in a document store for content management (e.g., blog software with a git backend)
Without having one interoperable way of expressing comments, all that becomes a lot harder.<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0129.html</ref>

Also see [[Rationale#Why is it important to stick to the semantics as defined in the spec?|Why is it important to stick to the semantics as defined in the spec?]] on this page.

=== Why isn’t there a dedicated element for advertisements? (e.g., <code><ad></code>, or <code><advert></code>, or <code><banner></code>, or whatever) ===
Because it would give users a relatively easy method for hiding or otherwise disabling ads, in which case the element would very likely end up not being used by content authors<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033086.html</ref>:

<pre>> How should advertisements be marked up?

It's worth considering that an <advert> element (or <banner> or whatever
you decide to call it) would just cause style rules like advert
{display:none;} to become widespread (e.g. by integration into Adblock
and equivalent). Therefore I can't see this type of markup being used by
most advertisers.</pre>

<pre>> I've joined this list to put forward the argument that there should be
> elements for <comment> and <ad> included in the HTML5 spec.
>
> These are both extremely common features of many web pages; I would say
> at least as common as "article".

For <ad>, there's the obvious potential usage of setting

ad { display: none !important }

in a user style sheet. I don't think this possibility would make <ad>
popular among authors.</pre>

Ian Hickson recommends using the <code>aside</code> element instead<ref>http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0226.html</ref>:

<pre>> I've joined this list to put forward the argument that there should be
> elements for <comment> and <ad> included in the HTML5 spec.

For advertisments, I do not think it makes sense to add an element. In
practice, it would likely not end up being used, since doing so would make
it too easy to hide advertisments.

However, the <aside> element is a close fit for the semantic, so I would
recommend using that.</pre>

=== Why isn’t there a grouping-type element for description lists to represent individual name-value groups (e.g., a “<code>dli</code>” element)? It would make styling as well as adding microdata to individual groups much easier.<ref>http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2013-October/001245.html</ref> ===

There is; it is now allowed to use <code><div></code> in <code><dl></code>. See https://github.com/whatwg/html/issues/1937

=== Why isn’t there a <code>sandbox</code> attribute on the <code>html</code> element? ===
HTML is the wrong level for disabling scripts or other features. This is the kind of thing should be done at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref>

=== Feature queries ===
Various proposals have come up with the idea of being able to determine if a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:
Part of the problem is that browser vendors will be economical with the truth. Marketing people always have an over-optimistic view of the compliance of their product, and will always give themselves the benefit of the doubt in borderline cases. Also, changing the compliance statement, to remove false claims that are exposed, is likely to a very low priority for the developers.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref>
With regard to CSS feature compliance: Remember that CSS
provides hints and implementations don't have to accept those hints, and
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref>
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref>

=== Why aren’t authors allowed to make custom HTML elements? ===

It is now allowed, see https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements

Be aware however that using custom elements when standard elements could have been used make it impossible for search engines, developers, and browsers to understand the semantics of a page.<ref>http://html5doctor.com/your-questions-13/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+html5doctor+%28HTML5doctor%29</ref>



== Other Pages ==

* [http://www.w3.org/TR/html-design-principles/ HTML Design Principles]
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]
* [[XHTML2 versus HTML5]]
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html <meta http-equiv=content-language> ]
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]

== References ==
<references/>

User:J9t

2019-10-20T18:54:27Z

J9t: Init

I’m Jens Oliver Meiert, a web developer and author.

HTML vs. XHTML

2007-03-06T22:25:39Z

J9t: German translation available: Added link

== Differences Between HTML and XHTML ==

'''Please note that the information in here is based upon the current spec for (X)HTML5. Some of the issues technically do not apply to previous versions of HTML.'''

Although HTML and XHTML appear to have similarities in their syntax, they are significantly different in many ways.

'''Note''': As the current WHATWG document is a draft, this section will need to track to a moving target.
Differences marked @@@ are differences that could theoretically be changed without affecting
backwards compatibility.

=== MIME Types ===

* XHTML must be served with an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
* HTML must be served as <code>text/html</code>.

It is the MIME type that determines what type of document you are using. If you use attempt to send XHTML as <code>text/html</code>, you are actually just using HTML, possibly with syntax errors.

Technically, according to the spec, XHTML 1.0 is allowed to be served as <code>text/html</code>. But, due to the above reason, such a document is considered to be an HTML document, not an XHTML document.

=== Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today.

* In XHTML, well-formedness errors are fatal. In HTML, error handling rules are much more graceful. Well-formedness errors, which are also syntax errors in HTML, include the following:
** Unencoded ampersands (<code>&</code> instead of <code>&amp;</code>), and less than signs (<code><</code> instead of <code>&lt;</code>) (This does not apply to <code>CDATA</code>).
** Comments containing extra pairs of hyphens or ending with a hyphen. e.g.
*** <code></code> or
*** <code></code>.
** Mismatched end tags (does not apply to elements with optional tags)
** Unclosed tags.
** Unexpected characters occuring in or before attribute names.
** Unexpected occurrence of EOF.
** Unexpected characters before the DOCTYPE name.
** Missing DOCTYPE name.
** A <code>PUBLIC</code> identifer in a <code>DOCTYPE</code> without a <code>SYSTEM</code> identifier (Note: including either of these is a syntax error in HTML5; but, in XML only the <code>SYSTEM</code> identifier is allowed to occur on its own).
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></code> or <code></code> can cause the start tag to be implied before it).
* The internal subset is permitted in XML, but meaningless (and forbidden) in HTML.
** In some cases, an internal subset in HTML would end up being partly rendered inline.
* The sequence of characters "<code>]]></code>" when it does not mark the end of a <code>CDATA</code> section is a well-formedness error in XHTML, but valid in HTML.
* In XHTML: <code><![CDATA[...]]></code> is a <code>CDATA</code> section. In HTML, it's a bogus comment.
* In XHTML, <code><?foo ...?></code> is a processing instruction. In HTML, it's a bogus comment.
* In HTML, the trailing slash used for the empty element syntax is a parse error for non-void elements (see below), but is ignored in all cases.
* In HTML, the <code>script</code> and <code>style</code> elements are parsed as <code>CDATA</code>. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that comments are treated as real comments, and things that look like start tags actually are start tags).
* In HTML, the <code>title</code> and <code>textarea</code> elements are parsed as <code>RCDATA</code>. (Note: The definition of <code>RCDATA</code> differs from that in SGML and there is no <code>RCDATA</code> in XML).
* In HTML, if scripting is enabled, the <code>noscript</code> element is parsed as <code>CDATA</code>. If scripting is disabled, it's parsed as <code>PCDATA</code>. In XHTML, the element has no effect, and can't really be used to stop content from being present when script is disabled.
* In HTML, the <code>iframe</code>, <code>noembed</code> and <code>noframes</code> elements are parsed as <code>CDATA</code>. In XHTML, they are parsed as normal elements, and therefore do not stop content from being used.
* White space characters in attribute values are [http://www.w3.org/TR/REC-xml/#AVNormalize normalized] to spaces in XHTML.
* Elements with optional tags are implied in certain conditions.
* In HTML, <code>base</code>, <code>link</code>, <code>meta</code>, <code>style</code> and <code>title</code> elements with tags occurring in the body are moved inserted into the head. In XHTML, they stay where they were specified.
* In HTML, tags for certain elements, which appear out of context, are ignored. This includes <code>caption</code>, <code>col</code>, <code>colgroup</code>, <code>frame</code>, <code>frameset</code>, <code>head</code>, <code>option</code>, <code>optgroup</code>, <code>tbody</code>, <code>td</code>, <code>tfoot</code>, <code>th</code>, <code>thead</code>, <code>tr</code>.
* The <code>plaintext</code> element has a special parsing requirement in HTML. (it is, however, forbidden).
* Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.

=== Syntax ===

* In HTML, [http://blog.whatwg.org/faq/#doctype the <code>doctype</code> is required]. In XHTML, it is optional.
* In XHTML, tag names and attribute names are case sensitive. In HTML, they are case insensitive.
* In XHTML, non-empty elements require both a start and an end tag. In HTML, certain elements allow the omission of either or both:
** <code>html</code> (both)
** <code>head</code> (both)
** <code>body</code> (both)
** <code>li</code> (end tag)
** <code>dt</code> (end tag)
** <code>dd</code> (end tag)
** <code>p</code> (end tag)
** <code>colgroup</code> (both)
** <code>thead</code> (end tag)
** <code>tbody</code> (both)
** <code>tfoot</code> (end tag)
** <code>tr</code> (end tag)
** <code>td</code> (end tag)
** <code>th</code> (end tag)
* In XHTML, empty elements may use either the empty element syntax (<code> </code>) or have an end tag immediately follow the start tag (<code> </code>). In HTML, the empty element syntax (trailing slash) is allowed on void elements, but forbidden on other elements. However, it serves no purpose whatsoever and can be omitted. End tags for void elements are forbidden.
** <code>base</code>,<code> link</code>, <code>meta</code>, <code>hr</code>, <code>br</code>, <code>img</code>, <code>embed</code>, <code>param</code>, <code>area</code>, <code>col</code> and <code>input</code>
** Note: the following are treated as void elements for the purpose in the parsing requirements, but, as they are obsolete and non-standard, the trailing slash is not permitted: <code>basefont</code>, <code>b</code><code>gsound</code>, <code>spacer</code>, <code>wbr</code>. (although, since these elements are not permitted anyway, it doesn't make much difference).
* HTML allows attribute minimisation (i.e. omitting the value), XHTML does not.
* HTML allows the use of unquoted attribute values, XHTML does not.
* XHTML allows the use of <code>CDATA</code> sections, HTML does not.
* XHTML allows the use of processing instructions, HTML does not.
* In HTML, all entity references are predefined and do not require a DTD. But because there is no DTD for XHTML5, entity references cannot be used in XHTML. (excluding the 5 predefined entities: <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&quot;</code> and <code>&apos;)</code>
** You may provide your own DTD for use with your own validating parser, but be aware that browsers do not use validating parsers and will not read the DTD.
* The valid set of unicode characters in XML 1.0 is limited beyond that in HTML.
* Namespace prefixes are permitted in XHTML. They are forbidden in HTML.

=== Markup ===

* The [http://blog.whatwg.org/faq/#namespace-decl namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the <code>html</code> element in HTML on the condition that is has the value <code><nowiki>"http://www.w3.org/1999/xhtml"</nowiki></code>.
** <code><nowiki><html xmlns="http://www.w3.org/1999/xhtml"></nowiki></code>
** In HTML, the xmlns attribute has absolutely no effect. It is basically a talisman. It is allowed merely to make migration to and from XHTML mildly easier. When parsed by an HTML parser, the attribute ends up in the null namespace
** In XML (with an [http://www.w3.org/TR/xml-names/ XML Namespaces]-aware parser), an xmlns attribute is part of the namespace declaration mechanism, and an element cannot actually have an xmlns attribute in the null namespace. In DOM implementations, the attribute ends up in the "<code><nowiki>http://www.w3.org/2000/xmlns/</nowiki></code>" namespace.
* XHTML allows non XHTML elements and attributes (in different namespaces) to be used, HTML does not.
* XHTML uses the <code>xml:lang</code> attribute, HTML uses <code>lang</code> instead,
* XML ID introduces <code>xml:id</code>, which could be used in XHTML. In HTML it has no effect.
* In HTML, the <code>noscript</code> element may be used. In XHTML, it is forbidden.
* HTML uses the <code>base</code> element, XHTML uses <code>xml:base</code> instead.
* In XHTML, <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>. In the HTML serialisation, due to backwards compatibility constraints, this is not possible (though it may be done through DOM manipulation).
* In XHTML, <code>table</code> elements may contain child <code>tr</code> elements. In the HTML serialisation, due to backwards compatibility constraints, this is not possible (though it may be done through DOM manipulation).

=== Character Encoding ===

* In XHTML, the XML declaration may be used to [http://blog.whatwg.org/faq/#charset specify the character encoding]. In HTML, the xml declaration is forbidden
* In HTML, the <code>meta</code> element may be used insted. The <code>http-equiv</code> attribute on the <code>meta</code> element is forbidden in XHTML and is ignored if included.
* The default character encoding for XHTML is, according to XML rules, <code>UTF-8</code> or <code>UTF-16</code>. If the encoding is unspecified in HTML, it should be determined through implementation specific heuristics or fallback to a default value (Note: this section of the spec is not yet finished).

=== Scripts ===

* <code>document.write()</code> and <code>document.writeln()</code> cannot be used in XHTML, they can in HTML.
* In XHTML, the use of the <code>innerHTML</code> property requires that the string be a well-formed fragment of XML.
* DOM APIs are case sensitive in XHTML and some are case insensitive in HTML. (This does not apply to elements which are not in the HTML namespace)
** Element.tagName, Node.nodeName, and Node.localName return the value in uppercase.
** Document.createElement() is case insensitive (the canonical form is lowercase).
** Element.setAttributeNode() will change the attribute name to lowercase.
** Element.setAttribute() is case insensitive (the canonical form is lowercase).
** Document.getElementsByTagName() and Element.getElementsByTagName() are case insensitive.
** Document.renameNode(). If the new namespace is the HTML namespace, then the new qualified name must be lowercased before the rename takes place.
* In HTML, Document.createElement() will create an element in the HTML namespace. In XML (including XHTML), the namespace is defined by both DOM2 and DOM3 to be null.
** In XHTML, browsers lack interoperability in this area. In Firefox, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element and in Safari, it's always null.

=== Stylesheets ===

* Selectors, as used in CSS, match case sensitively in XHTML, but case insensitively in HTML.
* CSS requires special handling of the body element in HTML for painting backgrounds on the canvas, which do not apply to XHTML.

== Differences Between HTML 4.01 and HTML 5 ==

=== MIME Type ===

Both HTML 4.01 and HTML 5 use <code>text/html</code>.

<code>Content-Type: text/html; charset=UTF-8</code>

=== Parsing HTML ===

* HTML 2.0 to HTML 4.01 were formally based on SGML, but browsers did not implement SGML parsers. [http://www.w3.org/TR/html4/conform.html#h-4.2 4.2 SGML] and [http://www.w3.org/TR/html4/appendix/notes.html#h-B.3 B.3 SGML implementation notes], HTML 4.01. This is a non-normative section of HTML 4.01 specification. And it already makes the difference between HTML user agents and SGML user agents.
* HTML 5 is defines its own parsing requirements based on the way browsers actually handle HTML.

=== Syntax ===

* TODO

=== Markup ===

* [http://www.w3.org/TR/html4/index/elements.html List of HTML 4.01 elements]
* [http://www.w3.org/TR/html4/index/attributes.html List of HTML 4.01 attributes]
* [http://simon.html5.org/html5-elements HTML5 Elements and Attributes]

==== Obsolete Attributes ====

Some attributes that were defined in HTML4 are not included in HTML5. Here's a current list (subject to change, see the spec):

* html@version
* head@profile
* a@rev, link@rev
* a@target, area@target, base@target, form@target (is mentioned in WF2...), link@target
* a@charset, link@charset, script@charset
* table@summary
* td@headers, th@headers
* td@axis, th@axis
* param@valuetype
* object@standby
* meta@scheme
* object@archive

In addition, HTML5 has none of the presentational attributes that were in HTML4 (including those on <table>). Any attributes defined on ''elements'' that are not in HTML5 are (obviously) also not in HTML5.

==== Obsolete Elements ====

The following elements were present in HTML4 but are not defined in HTML5:

* acronym (use <abbr> instead)
* applet (use <object> instead)
* basefont
* big
* center
* dir
* font
* frame
* frameset
* isindex
* noframes
* noscript (only in XHTML)
* s
* strike
* tt
* u

=== Character Encoding ===

The character encoding can be declared using the meta element, but the syntax of the meta element has changed. In HTML 4.01 and earlier, the meta element was:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In HTML5, the syntax was simplified to remove the unnecessary markup, yet still remain compatible with the encoding detection implemented in most existing browsers.

<meta charset="UTF-8">

==== HTML 4 Algorithm ====

Source [http://www.w3.org/TR/html4/charset.html#h-5.2.2 5.2.2 Specifying the character encoding], HTML 4.01 Specification.

# An HTTP "charset" parameter in a "Content-Type" field.
# A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
# The charset attribute set on an element that designates an external resource.

==== HTML 5 Algorithm ====

The exact algorithm that browsers must follow in order to [http://www.whatwg.org/specs/web-apps/current-work/#the-input0 determine the character encoding] is specified in HTML 5. The basic algorithm works as follows:

# If the transport layer specifies an encoding, use that, and abort these steps. (e.g. The HTTP Content-Type header).
# Read the first 512 bytes of the file, or at least as much as possible if less than that.
# If the file starts with a UTF-8, UTF-16 or UTF-32 BOM, then use that and abort these steps.
# Otherwise use the special algorithm to search the first 512 bytes for a meta element that declares the encoding. The algorithm is relatively lenient in what it will detect, though since it doesn't use the normal parsing algorithm, there are some restrictions.

== Differences Between DOM Level 2.0, 3.0 and the HTML 5 DOM APIs ==

'''This section might belong on a separate page.'''

* TODO (need to talk about the changes to the DOM API that HTML5 is making, compared with DOM2 and DOM3)

== Translations ==

* [http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ German translation: "HTML 5 und XHTML 5 im Vergleich (WHATWG)"]

HTML vs. XHTML

2007-02-12T18:57:45Z

J9t: German translation announcement

== Differences Between HTML and XHTML ==

'''Please note that the information in here is based upon the current spec for (X)HTML5. Some of the issues technically do not apply to previous versions of HTML.'''

Although HTML and XHTML appear to have similarities in their syntax, they are significantly different in many ways.

'''Note''': As the current WHATWG document is a draft, this section will need to track to a moving target.
Differences marked @@@ are differences that could theoretically be changed without affecting
backwards compatibility.

=== MIME Types ===

* XHTML must be served with an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
* HTML must be served as <code>text/html</code>.

It is the MIME type that determines what type of document you are using. If you use attempt to send XHTML as <code>text/html</code>, you are actually just using HTML, possibly with syntax errors.

Technically, according to the spec, XHTML 1.0 is allowed to be served as <code>text/html</code>. But, due to the above reason, such a document is considered to be an HTML document, not an XHTML document.

=== Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today.

* In XHTML, well-formedness errors are fatal. In HTML, error handling rules are much more graceful. Well-formedness errors, which are also syntax errors in HTML, include the following:
** Unencoded ampersands (<code>&</code> instead of <code>&amp;</code>), and less than signs (<code><</code> instead of <code>&lt;</code>) (This does not apply to <code>CDATA</code>).
** Comments containing extra pairs of hyphens or ending with a hyphen. e.g.
*** <code></code> or
*** <code></code>.
** Mismatched end tags (does not apply to elements with optional tags)
** Unclosed tags.
** Unexpected characters occuring in or before attribute names.
** Unexpected occurrence of EOF.
** Unexpected characters before the DOCTYPE name.
** Missing DOCTYPE name.
** A <code>PUBLIC</code> identifer in a <code>DOCTYPE</code> without a <code>SYSTEM</code> identifier (Note: including either of these is a syntax error in HTML5; but, in XML only the <code>SYSTEM</code> identifier is allowed to occur on its own).
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></code> or <code></code> can cause the start tag to be implied before it).
* The internal subset is permitted in XML, but meaningless (and forbidden) in HTML.
** In some cases, an internal subset in HTML would end up being partly rendered inline.
* The sequence of characters "<code>]]></code>" when it does not mark the end of a <code>CDATA</code> section is a well-formedness error in XHTML, but valid in HTML.
* In XHTML: <code><![CDATA[...]]></code> is a <code>CDATA</code> section. In HTML, it's a bogus comment.
* In XHTML, <code><?foo ...?></code> is a processing instruction. In HTML, it's a bogus comment.
* In HTML, the trailing slash used for the empty element syntax is a parse error for non-void elements (see below), but is ignored in all cases.
* In HTML, the <code>script</code> and <code>style</code> elements are parsed as <code>CDATA</code>. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that comments are treated as real comments, and things that look like start tags actually are start tags).
* In HTML, the <code>title</code> and <code>textarea</code> elements are parsed as <code>RCDATA</code>. (Note: The definition of <code>RCDATA</code> differs from that in SGML and there is no <code>RCDATA</code> in XML).
* In HTML, if scripting is enabled, the <code>noscript</code> element is parsed as <code>CDATA</code>. If scripting is disabled, it's parsed as <code>PCDATA</code>. In XHTML, the element has no effect, and can't really be used to stop content from being present when script is disabled.
* In HTML, the <code>iframe</code>, <code>noembed</code> and <code>noframes</code> elements are parsed as <code>CDATA</code>. In XHTML, they are parsed as normal elements, and therefore do not stop content from being used.
* White space characters in attribute values are [http://www.w3.org/TR/REC-xml/#AVNormalize normalized] to spaces in XHTML.
* Elements with optional tags are implied in certain conditions.
* In HTML, <code>base</code>, <code>link</code>, <code>meta</code>, <code>style</code> and <code>title</code> elements with tags occurring in the body are moved inserted into the head. In XHTML, they stay where they were specified.
* In HTML, tags for certain elements, which appear out of context, are ignored. This includes <code>caption</code>, <code>col</code>, <code>colgroup</code>, <code>frame</code>, <code>frameset</code>, <code>head</code>, <code>option</code>, <code>optgroup</code>, <code>tbody</code>, <code>td</code>, <code>tfoot</code>, <code>th</code>, <code>thead</code>, <code>tr</code>.
* The <code>plaintext</code> element has a special parsing requirement in HTML. (it is, however, forbidden).
* Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.

=== Syntax ===

* In HTML, [http://blog.whatwg.org/faq/#doctype the <code>doctype</code> is required]. In XHTML, it is optional.
* In XHTML, tag names and attribute names are case sensitive. In HTML, they are case insensitive.
* In XHTML, non-empty elements require both a start and an end tag. In HTML, certain elements allow the omission of either or both:
** <code>html</code> (both)
** <code>head</code> (both)
** <code>body</code> (both)
** <code>li</code> (end tag)
** <code>dt</code> (end tag)
** <code>dd</code> (end tag)
** <code>p</code> (end tag)
** <code>colgroup</code> (both)
** <code>thead</code> (end tag)
** <code>tbody</code> (both)
** <code>tfoot</code> (end tag)
** <code>tr</code> (end tag)
** <code>td</code> (end tag)
** <code>th</code> (end tag)
* In XHTML, empty elements may use either the empty element syntax (<code> </code>) or have an end tag immediately follow the start tag (<code> </code>). In HTML, the empty element syntax (trailing slash) is allowed on void elements, but forbidden on other elements. However, it serves no purpose whatsoever and can be omitted. End tags for void elements are forbidden.
** <code>base</code>,<code> link</code>, <code>meta</code>, <code>hr</code>, <code>br</code>, <code>img</code>, <code>embed</code>, <code>param</code>, <code>area</code>, <code>col</code> and <code>input</code>
** Note: the following are treated as void elements for the purpose in the parsing requirements, but, as they are obsolete and non-standard, the trailing slash is not permitted: <code>basefont</code>, <code>b</code><code>gsound</code>, <code>spacer</code>, <code>wbr</code>. (although, since these elements are not permitted anyway, it doesn't make much difference).
* HTML allows attribute minimisation (i.e. omitting the value), XHTML does not.
* HTML allows the use of unquoted attribute values, XHTML does not.
* XHTML allows the use of <code>CDATA</code> sections, HTML does not.
* XHTML allows the use of processing instructions, HTML does not.
* In HTML, all entity references are predefined and do not require a DTD. But because there is no DTD for XHTML5, entity references cannot be used in XHTML. (excluding the 5 predefined entities: <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&quot;</code> and <code>&apos;)</code>
** You may provide your own DTD for use with your own validating parser, but be aware that browsers do not use validating parsers and will not read the DTD.
* The valid set of unicode characters in XML 1.0 is limited beyond that in HTML.
* Namespace prefixes are permitted in XHTML. They are forbidden in HTML.

=== Markup ===

* The [http://blog.whatwg.org/faq/#namespace-decl namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the <code>html</code> element in HTML on the condition that is has the value <code><nowiki>"http://www.w3.org/1999/xhtml"</nowiki></code>.
** <code><nowiki><html xmlns="http://www.w3.org/1999/xhtml"></nowiki></code>
** In HTML, the xmlns attribute has absolutely no effect. It is basically a talisman. It is allowed merely to make migration to and from XHTML mildly easier. When parsed by an HTML parser, the attribute ends up in the null namespace
** In XML (with an [http://www.w3.org/TR/xml-names/ XML Namespaces]-aware parser), an xmlns attribute is part of the namespace declaration mechanism, and an element cannot actually have an xmlns attribute in the null namespace. In DOM implementations, the attribute ends up in the "<code><nowiki>http://www.w3.org/2000/xmlns/</nowiki></code>" namespace.
* XHTML allows non XHTML elements and attributes (in different namespaces) to be used, HTML does not.
* XHTML uses the <code>xml:lang</code> attribute, HTML uses <code>lang</code> instead,
* XML ID introduces <code>xml:id</code>, which could be used in XHTML. In HTML it has no effect.
* In HTML, the <code>noscript</code> element may be used. In XHTML, it is forbidden.
* HTML uses the <code>base</code> element, XHTML uses <code>xml:base</code> instead.
* In XHTML, <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>. In the HTML serialisation, due to backwards compatibility constraints, this is not possible (though it may be done through DOM manipulation).
* In XHTML, <code>table</code> elements may contain child <code>tr</code> elements. In the HTML serialisation, due to backwards compatibility constraints, this is not possible (though it may be done through DOM manipulation).

=== Character Encoding ===

* In XHTML, the XML declaration may be used to [http://blog.whatwg.org/faq/#charset specify the character encoding]. In HTML, the xml declaration is forbidden
* In HTML, the <code>meta</code> element may be used insted. The <code>http-equiv</code> attribute on the <code>meta</code> element is forbidden in XHTML and is ignored if included.
* The default character encoding for XHTML is, according to XML rules, <code>UTF-8</code> or <code>UTF-16</code>. If the encoding is unspecified in HTML, it should be determined through implementation specific heuristics or fallback to a default value (Note: this section of the spec is not yet finished).

=== Scripts ===

* <code>document.write()</code> and <code>document.writeln()</code> cannot be used in XHTML, they can in HTML.
* In XHTML, the use of the <code>innerHTML</code> property requires that the string be a well-formed fragment of XML.
* DOM APIs are case sensitive in XHTML and some are case insensitive in HTML. (This does not apply to elements which are not in the HTML namespace)
** Element.tagName, Node.nodeName, and Node.localName return the value in uppercase.
** Document.createElement() is case insensitive (the canonical form is lowercase).
** Element.setAttributeNode() will change the attribute name to lowercase.
** Element.setAttribute() is case insensitive (the canonical form is lowercase).
** Document.getElementsByTagName() and Element.getElementsByTagName() are case insensitive.
** Document.renameNode(). If the new namespace is the HTML namespace, then the new qualified name must be lowercased before the rename takes place.
* In HTML, Document.createElement() will create an element in the HTML namespace. In XML (including XHTML), the namespace is defined by both DOM2 and DOM3 to be null.
** In XHTML, browsers lack interoperability in this area. In Firefox, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element and in Safari, it's always null.

=== Stylesheets ===

* Selectors, as used in CSS, match case sensitively in XHTML, but case insensitively in HTML.
* CSS requires special handling of the body element in HTML for painting backgrounds on the canvas, which do not apply to XHTML.

== Differences Between HTML 4.01 and HTML 5 ==

=== MIME Type ===

Both HTML 4.01 and HTML 5 use <code>text/html</code>.

<code>Content-Type: text/html; charset=UTF-8</code>

=== Parsing HTML ===

* HTML 2.0 to HTML 4.01 were formally based on SGML, but browsers did not implement SGML parsers. [http://www.w3.org/TR/html4/conform.html#h-4.2 4.2 SGML] and [http://www.w3.org/TR/html4/appendix/notes.html#h-B.3 B.3 SGML implementation notes], HTML 4.01. This is a non-normative section of HTML 4.01 specification. And it already makes the difference between HTML user agents and SGML user agents.
* HTML 5 is defines its own parsing requirements based on the way browsers actually handle HTML.

=== Syntax ===

* TODO

=== Markup ===

* [http://www.w3.org/TR/html4/index/elements.html List of HTML 4.01 elements]
* [http://www.w3.org/TR/html4/index/attributes.html List of HTML 4.01 attributes]
* No list (elements and attributes) yet for Web Apps 1.0

==== Obsolete Attributes ====

Some attributes that were defined in HTML4 are not included in HTML5. Here's a current list (subject to change, see the spec):

* html@version
* head@profile
* a@rev, link@rev
* a@target, area@target, base@target, form@target (is mentioned in WF2...), link@target
* a@charset, link@charset, script@charset
* table@summary
* td@headers, th@headers
* td@axis, th@axis
* param@valuetype
* object@standby
* meta@scheme
* object@archive

In addition, HTML5 has none of the presentational attributes that were in HTML4 (including those on <table>). Any attributes defined on ''elements'' that are not in HTML5 are (obviously) also not in HTML5.

==== Obsolete Elements ====

The following elements were present in HTML4 but are not defined in HTML5:

* acronym (use <abbr> instead)
* applet (use <object> instead)
* basefont
* big
* center
* dir
* font
* frame
* frameset
* isindex
* noframes
* noscript (only in XHTML)
* s
* strike
* tt
* u

=== Character Encoding ===

==== HTML 4 Algorithm ====

Source [http://www.w3.org/TR/html4/charset.html#h-5.2.2 5.2.2 Specifying the character encoding], HTML 4.01 Specification.

# An HTTP "charset" parameter in a "Content-Type" field.
# A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
# The charset attribute set on an element that designates an external resource.

==== HTML 5 Algorithm ====

This is currently undefined in the spec. See [[Character Encoding Detection]] for documentation.

== Differences Between DOM Level 2.0, 3.0 and the HTML 5 DOM APIs ==

'''This section might belong on a separate page.'''

* TODO (need to talk about the changes to the DOM API that HTML5 is making, compared with DOM2 and DOM3)

== Translations ==

* German translation: In progress ([http://meiert.com/en/ Jens Meiert])