WHATWG Wiki - User contributions [en]

Hgroup element

2011-05-11T12:53:08Z

Lachlan Hunt: Added The Guardian

This page documents use cases and existing usage patterns related to marking up subtitles and taglines within headers.

== Real World Examples ==

The following are real world pages all using various structures to mark up subtitles and taglines for page and article headers. Each one contains the markup copied and pasted directly from the site, only modified where necessary to tidy up whitespace or to omit irrelevant content from the header where indicated.

=== [http://www.telegraph.co.uk/ The Telegraph (UK)] ===

Example article: [http://www.telegraph.co.uk/foodanddrink/8324778/Coca-Cola-recipe-discovered.html Coca Cola recipe 'discovered']

<div class="storyHead">
<h1>Coca Cola recipe 'discovered'</h1>
<h2>A website claims to have uncovered Coca-Cola's top secret recipe.</h2>
</div>

=== [http://www.nationalgeographic.com/ National Geographic] ===

Example article: [http://news.nationalgeographic.com/news/2011/05/110505-einstein-theories-confirmed-gravity-probe-nasa-space-science Einstein Theories Confirmed by NASA Gravity Probe]

<div id="page_head">
<h1>Einstein Theories Confirmed by NASA Gravity Probe</h1>
<h2 class="subtitle">Space mission did what the famed physicist said would be impossible.</h2>
</div>

=== [http://www.gutenberg.org/ Project Gutenberg] ===

Example article: [http://www.gutenberg.org/files/36/36-h/36-h.htm The War of the Worlds, by H. G. Wells]

<h3 class="chapnum">CHAPTER ONE</h3>
<h3 class="chaptitle">THE EVE OF THE WAR</h3>

Example article: [http://www.gutenberg.org/files/28749/28749-h/28749-h.htm The Madcap of the School, by Angela Brazil.]

<div style="margin: auto; text-align: center; padding-top: 0pt; padding-bottom: 1em;">
<a name="CHAPTER_I_THE_MOATED_GRANGE" id="CHAPTER_I_THE_MOATED_GRANGE"></a>
<h2>CHAPTER I</h2>
<h3>THE MOATED GRANGE</h3>
</div>

Example article: [http://www.gutenberg.org/files/98/98-h/98-h.htm A Tale of Two Cities, by Charles Dickens]

<h1>A TALE OF TWO CITIES</h1>
<h2>A STORY OF THE FRENCH REVOLUTION</h2><br>
<h2>By Charles Dickens</h2>

=== [http://www.techdirt.com/ Techdirt] ===

Example article: [http://www.techdirt.com/articles/20110506/15124514188/when-copyright-contracts-can-get-way-art.shtml When Copyright And Contracts Can Get In The Way Of Art]

<div class="story">
<h1>When Copyright And Contracts Can Get In The Way Of Art</h1>
<h3>from the <i>tales-from-the-creative-front-lines</i> dept</h3>
<p>...</p>
</div>

=== [http://xkcd.com/ XKCD] ===

<div id="topRightContainer">
<div id="logo">
<a href="/"><img src="http://imgs.xkcd.com/s/9be30a7.png" alt="xkcd.com logo" height="83" width="185"/></a>
<h2><br />A webcomic of romance,<br/> sarcasm, math, and language.</h2>
<div class="clearleft"></div>
<br />
XKCD updates every Monday, Wednesday, and Friday.
</div>
</div>

=== [http://finance.yahoo.com/ Yahoo! Finance] ===

Example article: [http://finance.yahoo.com/news/Gas-prices-expected-to-drop-apf-3767822723.html?x=0 Gas prices expected to drop 50 cents by summer]

<div id="y-article-hd">
<h1 class="test1">Gas prices expected to drop 50 cents by summer</h1>
<h2>After 44 days of surging gas prices, analysts expect drop of 50 cents by summer driving season<br></h2>
<a href="http://us.rd.yahoo.com/finance/news/apf/SIG=10kfmofol/*http://www.ap.org/termsandconditions" rel="nofollow"><img src="http://l.yimg.com/a/i/us/fi/gr/ap_106x27.gif" alt="ap" class="sponsorimage"></a>
...
</div>

=== [http://oed.com/ Oxford English Dictionary] ===

<h1>
<span>
<p>Discover the story of English</p>
<span class="blurb">
<p>More than 600,000 words, over a thousand years</p>
</span>
</span>
</h1>

=== [http://diveintoaccessibility.org/ Dive Into Accessibility] ===

<div id="logo">
<div class="inner">
<h1 class="title"><a href="/" accesskey="1">Dive Into Accessibility</a></h1>
<p>30 days to a more accessible web site</p>
<a class="skip" href="#startnavigation">Skip to navigation</a>
<span class="divider">&nbsp;</span>
</div>
</div>

=== [http://www.calgaryherald.com/ Calgary Herald] ===

Example article: [http://www.calgaryherald.com/life/Cooking+Solo+Grows/4746884/story.html Cooking Solo Grows Up]

<div id="storyheader">
<div class="headline">
<h1>Cooking Solo Grows Up</h1>
</div>
<div class="clear">&nbsp;</div>
<div class="subheadline">
<h2>On your own? You no longer have to put up with cereal over the sink or days of the same old leftovers. Joe Yonan shows us why</h2>
</div>
<div class="clear">&nbsp;</div>
<div class="byline">
<span class="name">By Gwendolyn Richards, Calgary Herald</span>
<span class="timestamp">May 8, 2011 2:06 AM</span>
<span id="lblComment" class="comments"></span>
</div>
<div class="clear">&nbsp;</div>
</div>

=== [http://www.panic.com/ Panic] ===

Example page: [http://www.panic.com/coda/ Coda - One-Window Web Development for Mac OS X]

<div id="header">
<h1><a href="/coda/" title="Coda">Coda</a></h1>
<p>One window web development.*</p>
</div>

Example page: [http://www.panic.com/unison/ Unison - The Best Usenet Browser / Newsreader, Only For Mac OS X]

<h1>
<a href="http://www.panic.com/unison/" title="Unison - The Best Usenet Browser">Unison</a>
<br>
the best usenet browser
</h1>

=== [http://www.pcworld.com/ PCWorld] ===

Example article: [http://www.pcworld.com/article/227313/top_15_android_apps_for_smartphone_shutterbugs.html Top 15 Android Apps For Smartphone Shutterbugs]

<div id="articleHead">
...
<h1>Top 15 Android Apps For Smartphone Shutterbugs</h1>
<h2>Use these Android apps to add effects to your mobile photos and make them easier to take.</h2>

<p class="byline">By <a href="/author/Daniel-Ionescu">Daniel Ionescu</a>,
<a href="http://www.pcworld.com/" target="_blank">PCWorld</a>
&nbsp;&nbsp; <script type="text/javascript">timestamp(1304707200000,'longDateTime')</script>May 6, 2011 8:40 pm</p>
</div>

=== [http://www.computerworld.com/ Computerworld] ===

Example article: [http://www.computerworld.com/s/article/9216484/Elgan_How_to_pop_your_Internet_filter_bubble_ Elgan: How to pop your Internet 'filter bubble']

<div id="article_header" class="clearfix">
<div id="content_type">Opinion</div>
<h1>Elgan: How to pop your Internet 'filter bubble'</h1>
<h2>Personalization algorithms are stereotyping you, then hiding information from you based on that stereotype. Wait -- what?</h2>
<div id="byline">By Mike Elgan</div>
<div id="date">May 7, 2011 08:00 AM ET</div>
...
</div>

=== [http://www.apple.com/ Apple] ===

* Example page: [http://www.apple.com/imac/features.html Apple - iMac - Read about the features of the new iMac.]
<hgroup>
<h1><img src="http://images.apple.com/imac/images/features_title20110426.png" alt="Its beauty is way more than screen deep. " width="766" height="46" class="center" /></h1>
<p class="intro">All-new quad-core processors. Advanced graphics. Thunderbolt technology. FaceTime HD. iMac is a desktop workhorse disguised as an all-in-one wonder.</p>
</hgroup>

* Example page: [http://www.apple.com/pr/library/2011/03/02ipad.html Apple - Press Info - Apple Launches iPad 2]
<div id="content">
<p>
<a href="/pr/products/ipad/ipad.html" onclick="s_objectID=&quot;http://www.apple.com/pr/products/ipad/ipad.html_1&quot;;return this.s_oc?this.s_oc(e):true">iPad 2 images</a>
</p>

<h1>Apple Launches iPad 2</h1>
<h2>All New Design is Thinner, Lighter & Faster with FaceTime, Smart Covers & 10 Hour Battery</h2>
<p>
SAN FRANCISCO—March 2, 2011—Apple® today introduced iPad™ 2...
...
</div>

=== [http://docbook.sf.net/ DocBook XSL Stylesheets] ===

* All content generated from DocBook yields the following output for title/subtitle (actualy heading levels can vary depending on the depth of element with title/subtitle):
<div class="titlepage">
<h2 class="title">Title</h2>
<h3 class="subtitle">Subtitl</h3>
</div>

=== [http://miniapps.co.uk/ MiniApps] ===

<hgroup>
<h1><a href="http://miniapps.co.uk/" title="Home page"><span>MiniApps</span></a></h1>
<h2>Beautifully crafted mobile web apps.</h2>
</hgroup>

=== [http://interactwithwebstandards.com/ InterACT with Web Standards] ===

<h1>
<span id="title">InterACT With <strong>Web Standards</strong></span>
<span id="subtitle">A Holistic Approach to Web Design</span>
</h1>

=== [http://www.fokus.se/2011/05/kort-triumf-for-obama/ From the Swedish Magazine Fokus] ===

<h4>Utmanarna</h4>
<p><em>Tio republikanska kandidater som kan bli ett hot mot Obamas andra presidentperiod.</em></p>

=== [http://www.guardian.co.uk/ The Guardian (UK)] ===

Example article: [http://www.guardian.co.uk/books/2011/may/10/us-prisoners-refused-books-bible US prisoners refused all books except Bible]

<div id="main-article-info">
<h1>US prisoners refused all books except Bible</h1>
<p id="stand-first" class="stand-first-alone">American Civil Liberties Union says jail in South Carolina is banning books 'for no good reason'</p>
</div>

=== Web sites that do not markup up subtitles at all ===

''Perhaps'' because the developers lack a compelling pattern?

* IMDB
* Amazon
* Wikipedia

[[Category:Proposals]]

Hgroup element

2011-05-09T12:14:42Z

Lachlan Hunt: Added MiniApps

This page documents use cases and existing usage patterns related to marking up subtitles and taglines within headers.

== Real World Examples ==

The following are real world pages all using various structures to mark up subtitles and taglines for page and article headers. Each one contains the markup copied and pasted directly from the site, only modified where necessary to tidy up whitespace or to omit irrelevant content from the header where indicated.

=== [http://www.telegraph.co.uk/ The Telegraph (UK)] ===

Example article: [http://www.telegraph.co.uk/foodanddrink/8324778/Coca-Cola-recipe-discovered.html Coca Cola recipe 'discovered']

<div class="storyHead">
<h1>Coca Cola recipe 'discovered'</h1>
<h2>A website claims to have uncovered Coca-Cola's top secret recipe.</h2>
</div>

=== [http://www.nationalgeographic.com/ National Geographic] ===

Example article: [http://news.nationalgeographic.com/news/2011/05/110505-einstein-theories-confirmed-gravity-probe-nasa-space-science Einstein Theories Confirmed by NASA Gravity Probe]

<div id="page_head">
<h1>Einstein Theories Confirmed by NASA Gravity Probe</h1>
<h2 class="subtitle">Space mission did what the famed physicist said would be impossible.</h2>
</div>

=== [http://www.gutenberg.org/ Project Gutenberg] ===

Example article: [http://www.gutenberg.org/files/36/36-h/36-h.htm The War of the Worlds, by H. G. Wells]

<h3 class="chapnum">CHAPTER ONE</h3>
<h3 class="chaptitle">THE EVE OF THE WAR</h3>

Example article: [http://www.gutenberg.org/files/28749/28749-h/28749-h.htm The Madcap of the School, by Angela Brazil.]

<div style="margin: auto; text-align: center; padding-top: 0pt; padding-bottom: 1em;">
<a name="CHAPTER_I_THE_MOATED_GRANGE" id="CHAPTER_I_THE_MOATED_GRANGE"></a>
<h2>CHAPTER I</h2>
<h3>THE MOATED GRANGE</h3>
</div>

Example article: [http://www.gutenberg.org/files/98/98-h/98-h.htm A Tale of Two Cities, by Charles Dickens]

<h1>A TALE OF TWO CITIES</h1>
<h2>A STORY OF THE FRENCH REVOLUTION</h2><br>
<h2>By Charles Dickens</h2>

=== [http://www.techdirt.com/ Techdirt] ===

Example article: [http://www.techdirt.com/articles/20110506/15124514188/when-copyright-contracts-can-get-way-art.shtml When Copyright And Contracts Can Get In The Way Of Art]

<div class="story">
<h1>When Copyright And Contracts Can Get In The Way Of Art</h1>
<h3>from the <i>tales-from-the-creative-front-lines</i> dept</h3>
<p>...</p>
</div>

=== [http://xkcd.com/ XKCD] ===

<div id="topRightContainer">
<div id="logo">
<a href="/"><img src="http://imgs.xkcd.com/s/9be30a7.png" alt="xkcd.com logo" height="83" width="185"/></a>
<h2><br />A webcomic of romance,<br/> sarcasm, math, and language.</h2>
<div class="clearleft"></div>
<br />
XKCD updates every Monday, Wednesday, and Friday.
</div>
</div>

=== [http://finance.yahoo.com/ Yahoo! Finance] ===

Example article: [http://finance.yahoo.com/news/Gas-prices-expected-to-drop-apf-3767822723.html?x=0 Gas prices expected to drop 50 cents by summer]

<div id="y-article-hd">
<h1 class="test1">Gas prices expected to drop 50 cents by summer</h1>
<h2>After 44 days of surging gas prices, analysts expect drop of 50 cents by summer driving season<br></h2>
<a href="http://us.rd.yahoo.com/finance/news/apf/SIG=10kfmofol/*http://www.ap.org/termsandconditions" rel="nofollow"><img src="http://l.yimg.com/a/i/us/fi/gr/ap_106x27.gif" alt="ap" class="sponsorimage"></a>
...
</div>

=== [http://oed.com/ Oxford English Dictionary] ===

<h1>
<span>
<p>Discover the story of English</p>
<span class="blurb">
<p>More than 600,000 words, over a thousand years</p>
</span>
</span>
</h1>

=== [http://diveintoaccessibility.org/ Dive Into Accessibility] ===

<div id="logo">
<div class="inner">
<h1 class="title"><a href="/" accesskey="1">Dive Into Accessibility</a></h1>
<p>30 days to a more accessible web site</p>
<a class="skip" href="#startnavigation">Skip to navigation</a>
<span class="divider">&nbsp;</span>
</div>
</div>

=== [http://www.calgaryherald.com/ Calgary Herald] ===

Example article: [http://www.calgaryherald.com/life/Cooking+Solo+Grows/4746884/story.html Cooking Solo Grows Up]

<div id="storyheader">
<div class="headline">
<h1>Cooking Solo Grows Up</h1>
</div>
<div class="clear">&nbsp;</div>
<div class="subheadline">
<h2>On your own? You no longer have to put up with cereal over the sink or days of the same old leftovers. Joe Yonan shows us why</h2>
</div>
<div class="clear">&nbsp;</div>
<div class="byline">
<span class="name">By Gwendolyn Richards, Calgary Herald</span>
<span class="timestamp">May 8, 2011 2:06 AM</span>
<span id="lblComment" class="comments"></span>
</div>
<div class="clear">&nbsp;</div>
</div>

=== [http://www.panic.com/ Panic] ===

Example page: [http://www.panic.com/coda/ Coda - One-Window Web Development for Mac OS X]

<div id="header">
<h1><a href="/coda/" title="Coda">Coda</a></h1>
<p>One window web development.*</p>
</div>

Example page: [http://www.panic.com/unison/ Unison - The Best Usenet Browser / Newsreader, Only For Mac OS X]

<h1>
<a href="http://www.panic.com/unison/" title="Unison - The Best Usenet Browser">Unison</a>
<br>
the best usenet browser
</h1>

=== [http://www.pcworld.com/ PCWorld] ===

Example article: [http://www.pcworld.com/article/227313/top_15_android_apps_for_smartphone_shutterbugs.html Top 15 Android Apps For Smartphone Shutterbugs]

<div id="articleHead">
...
<h1>Top 15 Android Apps For Smartphone Shutterbugs</h1>
<h2>Use these Android apps to add effects to your mobile photos and make them easier to take.</h2>

<p class="byline">By <a href="/author/Daniel-Ionescu">Daniel Ionescu</a>,
<a href="http://www.pcworld.com/" target="_blank">PCWorld</a>
&nbsp;&nbsp; <script type="text/javascript">timestamp(1304707200000,'longDateTime')</script>May 6, 2011 8:40 pm</p>
</div>

=== [http://www.computerworld.com/ Computerworld] ===

Example article: [http://www.computerworld.com/s/article/9216484/Elgan_How_to_pop_your_Internet_filter_bubble_ Elgan: How to pop your Internet 'filter bubble']

<div id="article_header" class="clearfix">
<div id="content_type">Opinion</div>
<h1>Elgan: How to pop your Internet 'filter bubble'</h1>
<h2>Personalization algorithms are stereotyping you, then hiding information from you based on that stereotype. Wait -- what?</h2>
<div id="byline">By Mike Elgan</div>
<div id="date">May 7, 2011 08:00 AM ET</div>
...
</div>

=== [http://www.apple.com/ Apple] ===

* Example page: [http://www.apple.com/imac/features.html Apple - iMac - Read about the features of the new iMac.]
<hgroup>
<h1><img src="http://images.apple.com/imac/images/features_title20110426.png" alt="Its beauty is way more than screen deep. " width="766" height="46" class="center" /></h1>
<p class="intro">All-new quad-core processors. Advanced graphics. Thunderbolt technology. FaceTime HD. iMac is a desktop workhorse disguised as an all-in-one wonder.</p>
</hgroup>

=== [http://docbook.sf.net/ DocBook XSL Stylesheets] ===

* All content generated from DocBook yields the following output for title/subtitle (actualy heading levels can vary depending on the depth of element with title/subtitle):
<div class="titlepage">
<h2 class="title">Title</h2>
<h3 class="subtitle">Subtitl</h3>
</div>

=== [http://miniapps.co.uk/ MiniApps] ===

<hgroup>
<h1><a href="http://miniapps.co.uk/" title="Home page"><span>MiniApps</span></a></h1>
<h2>Beautifully crafted mobile web apps.</h2>
</hgroup>

[[Category:Proposals]]

Hgroup element

2011-05-09T06:52:33Z

Lachlan Hunt: /* Oxford English Dictionary */ Reformatted markup

Hgroup element

2011-05-09T06:48:24Z

Lachlan Hunt:

This page documents use cases and existing usage patterns related to marking up subtitles and taglines within headers.

== Real World Examples ==

The following are real world pages all using various structures to mark up subtitles and taglines for page and article headers. Each one contains the markup copied and pasted directly from the site, only modified where necessary to tidy up whitespace or to omit irrelevant content from the header where indicated.

=== [http://www.telegraph.co.uk/ The Telegraph (UK)] ===

Example article: [http://www.telegraph.co.uk/foodanddrink/8324778/Coca-Cola-recipe-discovered.html Coca Cola recipe 'discovered']

<div class="storyHead">
<h1>Coca Cola recipe 'discovered'</h1>
<h2>A website claims to have uncovered Coca-Cola's top secret recipe.</h2>
</div>

=== [http://www.nationalgeographic.com/ National Geographic] ===

Example article: [http://news.nationalgeographic.com/news/2011/05/110505-einstein-theories-confirmed-gravity-probe-nasa-space-science Einstein Theories Confirmed by NASA Gravity Probe]

<div id="page_head">
<h1>Einstein Theories Confirmed by NASA Gravity Probe</h1>
<h2 class="subtitle">Space mission did what the famed physicist said would be impossible.</h2>
</div>

=== [http://www.gutenberg.org/ Project Gutenberg] ===

Example article: [http://www.gutenberg.org/files/36/36-h/36-h.htm The War of the Worlds, by H. G. Wells]

<h3 class="chapnum">CHAPTER ONE</h3>
<h3 class="chaptitle">THE EVE OF THE WAR</h3>

Example article: [http://www.gutenberg.org/files/28749/28749-h/28749-h.htm The Madcap of the School, by Angela Brazil.]

<div style="margin: auto; text-align: center; padding-top: 0pt; padding-bottom: 1em;">
<a name="CHAPTER_I_THE_MOATED_GRANGE" id="CHAPTER_I_THE_MOATED_GRANGE"></a>
<h2>CHAPTER I</h2>
<h3>THE MOATED GRANGE</h3>
</div>

Example article: [http://www.gutenberg.org/files/98/98-h/98-h.htm A Tale of Two Cities, by Charles Dickens]

<h1>A TALE OF TWO CITIES</h1>
<h2>A STORY OF THE FRENCH REVOLUTION</h2><br>
<h2>By Charles Dickens</h2>

=== [http://www.techdirt.com/ Techdirt] ===

Example article: [http://www.techdirt.com/articles/20110506/15124514188/when-copyright-contracts-can-get-way-art.shtml When Copyright And Contracts Can Get In The Way Of Art]

<div class="story">
<h1>When Copyright And Contracts Can Get In The Way Of Art</h1>
<h3>from the <i>tales-from-the-creative-front-lines</i> dept</h3>
<p>...</p>
</div>

=== [http://xkcd.com/ XKCD] ===

<div id="topRightContainer">
<div id="logo">
<a href="/"><img src="http://imgs.xkcd.com/s/9be30a7.png" alt="xkcd.com logo" height="83" width="185"/></a>
<h2><br />A webcomic of romance,<br/> sarcasm, math, and language.</h2>
<div class="clearleft"></div>
<br />
XKCD updates every Monday, Wednesday, and Friday.
</div>
</div>

=== [http://finance.yahoo.com/ Yahoo! Finance] ===

Example article: [http://finance.yahoo.com/news/Gas-prices-expected-to-drop-apf-3767822723.html?x=0 Gas prices expected to drop 50 cents by summer]

<div id="y-article-hd">
<h1 class="test1">Gas prices expected to drop 50 cents by summer</h1>
<h2>After 44 days of surging gas prices, analysts expect drop of 50 cents by summer driving season<br></h2>
<a href="http://us.rd.yahoo.com/finance/news/apf/SIG=10kfmofol/*http://www.ap.org/termsandconditions" rel="nofollow"><img src="http://l.yimg.com/a/i/us/fi/gr/ap_106x27.gif" alt="ap" class="sponsorimage"></a>
...
</div>

=== [http://oed.com/ Oxford English Dictionary] ===

<h1>
<span><p>Discover the story of English</p><span class="blurb">
<p>More than 600,000 words, over a thousand years</p></span></span>
</h1>

=== [http://diveintoaccessibility.org/ Dive Into Accessibility] ===

<div id="logo">
<div class="inner">
<h1 class="title"><a href="/" accesskey="1">Dive Into Accessibility</a></h1>
<p>30 days to a more accessible web site</p>
<a class="skip" href="#startnavigation">Skip to navigation</a>
<span class="divider">&nbsp;</span>
</div>
</div>

=== [http://www.calgaryherald.com/ Calgary Herald] ===

Example article: [http://www.calgaryherald.com/life/Cooking+Solo+Grows/4746884/story.html Cooking Solo Grows Up]

<div id="storyheader">
<div class="headline">
<h1>Cooking Solo Grows Up</h1>
</div>
<div class="clear">&nbsp;</div>
<div class="subheadline">
<h2>On your own? You no longer have to put up with cereal over the sink or days of the same old leftovers. Joe Yonan shows us why</h2>
</div>
<div class="clear">&nbsp;</div>
<div class="byline">
<span class="name">By Gwendolyn Richards, Calgary Herald</span>
<span class="timestamp">May 8, 2011 2:06 AM</span>
<span id="lblComment" class="comments"></span>
</div>
<div class="clear">&nbsp;</div>
</div>

=== [http://www.panic.com/ Panic] ===

Example page: [http://www.panic.com/coda/ Coda - One-Window Web Development for Mac OS X]

<div id="header">
<h1><a href="/coda/" title="Coda">Coda</a></h1>
<p>One window web development.*</p>
</div>

Example page: [http://www.panic.com/unison/ Unison - The Best Usenet Browser / Newsreader, Only For Mac OS X]

<h1>
<a href="http://www.panic.com/unison/" title="Unison - The Best Usenet Browser">Unison</a>
<br>
the best usenet browser
</h1>

=== [http://www.pcworld.com/ PCWorld] ===

Example article: [http://www.pcworld.com/article/227313/top_15_android_apps_for_smartphone_shutterbugs.html Top 15 Android Apps For Smartphone Shutterbugs]

<div id="articleHead">
...
<h1>Top 15 Android Apps For Smartphone Shutterbugs</h1>
<h2>Use these Android apps to add effects to your mobile photos and make them easier to take.</h2>

<p class="byline">By <a href="/author/Daniel-Ionescu">Daniel Ionescu</a>,
<a href="http://www.pcworld.com/" target="_blank">PCWorld</a>
&nbsp;&nbsp; <script type="text/javascript">timestamp(1304707200000,'longDateTime')</script>May 6, 2011 8:40 pm</p>
</div>

=== [http://www.computerworld.com/ Computerworld] ===

Example article: [http://www.computerworld.com/s/article/9216484/Elgan_How_to_pop_your_Internet_filter_bubble_ Elgan: How to pop your Internet 'filter bubble']

<div id="article_header" class="clearfix">
<div id="content_type">Opinion</div>
<h1>Elgan: How to pop your Internet 'filter bubble'</h1>
<h2>Personalization algorithms are stereotyping you, then hiding information from you based on that stereotype. Wait -- what?</h2>
<div id="byline">By Mike Elgan</div>
<div id="date">May 7, 2011 08:00 AM ET</div>
...
</div>

=== [http://www.apple.com/ Apple] ===

* Example page: [http://www.apple.com/imac/features.html Apple - iMac - Read about the features of the new iMac.]
<hgroup>
<h1><img src="http://images.apple.com/imac/images/features_title20110426.png" alt="Its beauty is way more than screen deep. " width="766" height="46" class="center" /></h1>
<p class="intro">All-new quad-core processors. Advanced graphics. Thunderbolt technology. FaceTime HD. iMac is a desktop workhorse disguised as an all-in-one wonder.</p>
</hgroup>

[[Category:Proposals]]

Hgroup element

2011-05-09T06:47:52Z

Lachlan Hunt: Added Apple

This page documents use cases and existing usage patterns related to marking up subtitles and taglines within headers.

== Real World Examples ==

The following are real world pages all using various structures to mark up subtitles and taglines for page and article headers. Each one contains the markup copied and pasted directly from the site, only modified where necessary to tidy up whitespace or to omit irrelevant content from the header where indicated.

The suggested HTML5 markup that follows each example illustrates an equivalent structure using the hgroup element. This is provided for comparison purposes only to see how well its design aligns with or differs from current practice.

=== [http://www.telegraph.co.uk/ The Telegraph (UK)] ===

Example article: [http://www.telegraph.co.uk/foodanddrink/8324778/Coca-Cola-recipe-discovered.html Coca Cola recipe 'discovered']

<div class="storyHead">
<h1>Coca Cola recipe 'discovered'</h1>
<h2>A website claims to have uncovered Coca-Cola's top secret recipe.</h2>
</div>

=== [http://www.nationalgeographic.com/ National Geographic] ===

Example article: [http://news.nationalgeographic.com/news/2011/05/110505-einstein-theories-confirmed-gravity-probe-nasa-space-science Einstein Theories Confirmed by NASA Gravity Probe]

<div id="page_head">
<h1>Einstein Theories Confirmed by NASA Gravity Probe</h1>
<h2 class="subtitle">Space mission did what the famed physicist said would be impossible.</h2>
</div>

=== [http://www.gutenberg.org/ Project Gutenberg] ===

Example article: [http://www.gutenberg.org/files/36/36-h/36-h.htm The War of the Worlds, by H. G. Wells]

<h3 class="chapnum">CHAPTER ONE</h3>
<h3 class="chaptitle">THE EVE OF THE WAR</h3>

Example article: [http://www.gutenberg.org/files/28749/28749-h/28749-h.htm The Madcap of the School, by Angela Brazil.]

<div style="margin: auto; text-align: center; padding-top: 0pt; padding-bottom: 1em;">
<a name="CHAPTER_I_THE_MOATED_GRANGE" id="CHAPTER_I_THE_MOATED_GRANGE"></a>
<h2>CHAPTER I</h2>
<h3>THE MOATED GRANGE</h3>
</div>

Example article: [http://www.gutenberg.org/files/98/98-h/98-h.htm A Tale of Two Cities, by Charles Dickens]

<h1>A TALE OF TWO CITIES</h1>
<h2>A STORY OF THE FRENCH REVOLUTION</h2><br>
<h2>By Charles Dickens</h2>

=== [http://www.techdirt.com/ Techdirt] ===

Example article: [http://www.techdirt.com/articles/20110506/15124514188/when-copyright-contracts-can-get-way-art.shtml When Copyright And Contracts Can Get In The Way Of Art]

<div class="story">
<h1>When Copyright And Contracts Can Get In The Way Of Art</h1>
<h3>from the <i>tales-from-the-creative-front-lines</i> dept</h3>
<p>...</p>
</div>

=== [http://xkcd.com/ XKCD] ===

<div id="topRightContainer">
<div id="logo">
<a href="/"><img src="http://imgs.xkcd.com/s/9be30a7.png" alt="xkcd.com logo" height="83" width="185"/></a>
<h2><br />A webcomic of romance,<br/> sarcasm, math, and language.</h2>
<div class="clearleft"></div>
<br />
XKCD updates every Monday, Wednesday, and Friday.
</div>
</div>

=== [http://finance.yahoo.com/ Yahoo! Finance] ===

Example article: [http://finance.yahoo.com/news/Gas-prices-expected-to-drop-apf-3767822723.html?x=0 Gas prices expected to drop 50 cents by summer]

<div id="y-article-hd">
<h1 class="test1">Gas prices expected to drop 50 cents by summer</h1>
<h2>After 44 days of surging gas prices, analysts expect drop of 50 cents by summer driving season<br></h2>
<a href="http://us.rd.yahoo.com/finance/news/apf/SIG=10kfmofol/*http://www.ap.org/termsandconditions" rel="nofollow"><img src="http://l.yimg.com/a/i/us/fi/gr/ap_106x27.gif" alt="ap" class="sponsorimage"></a>
...
</div>

=== [http://oed.com/ Oxford English Dictionary] ===

<h1>
<span><p>Discover the story of English</p><span class="blurb">
<p>More than 600,000 words, over a thousand years</p></span></span>
</h1>

=== [http://diveintoaccessibility.org/ Dive Into Accessibility] ===

<div id="logo">
<div class="inner">
<h1 class="title"><a href="/" accesskey="1">Dive Into Accessibility</a></h1>
<p>30 days to a more accessible web site</p>
<a class="skip" href="#startnavigation">Skip to navigation</a>
<span class="divider">&nbsp;</span>
</div>
</div>

=== [http://www.calgaryherald.com/ Calgary Herald] ===

Example article: [http://www.calgaryherald.com/life/Cooking+Solo+Grows/4746884/story.html Cooking Solo Grows Up]

<div id="storyheader">
<div class="headline">
<h1>Cooking Solo Grows Up</h1>
</div>
<div class="clear">&nbsp;</div>
<div class="subheadline">
<h2>On your own? You no longer have to put up with cereal over the sink or days of the same old leftovers. Joe Yonan shows us why</h2>
</div>
<div class="clear">&nbsp;</div>
<div class="byline">
<span class="name">By Gwendolyn Richards, Calgary Herald</span>
<span class="timestamp">May 8, 2011 2:06 AM</span>
<span id="lblComment" class="comments"></span>
</div>
<div class="clear">&nbsp;</div>
</div>

=== [http://www.panic.com/ Panic] ===

Example page: [http://www.panic.com/coda/ Coda - One-Window Web Development for Mac OS X]

<div id="header">
<h1><a href="/coda/" title="Coda">Coda</a></h1>
<p>One window web development.*</p>
</div>

Example page: [http://www.panic.com/unison/ Unison - The Best Usenet Browser / Newsreader, Only For Mac OS X]

<h1>
<a href="http://www.panic.com/unison/" title="Unison - The Best Usenet Browser">Unison</a>
<br>
the best usenet browser
</h1>

=== [http://www.pcworld.com/ PCWorld] ===

Example article: [http://www.pcworld.com/article/227313/top_15_android_apps_for_smartphone_shutterbugs.html Top 15 Android Apps For Smartphone Shutterbugs]

<div id="articleHead">
...
<h1>Top 15 Android Apps For Smartphone Shutterbugs</h1>
<h2>Use these Android apps to add effects to your mobile photos and make them easier to take.</h2>

<p class="byline">By <a href="/author/Daniel-Ionescu">Daniel Ionescu</a>,
<a href="http://www.pcworld.com/" target="_blank">PCWorld</a>
&nbsp;&nbsp; <script type="text/javascript">timestamp(1304707200000,'longDateTime')</script>May 6, 2011 8:40 pm</p>
</div>

=== [http://www.computerworld.com/ Computerworld] ===

Example article: [http://www.computerworld.com/s/article/9216484/Elgan_How_to_pop_your_Internet_filter_bubble_ Elgan: How to pop your Internet 'filter bubble']

<div id="article_header" class="clearfix">
<div id="content_type">Opinion</div>
<h1>Elgan: How to pop your Internet 'filter bubble'</h1>
<h2>Personalization algorithms are stereotyping you, then hiding information from you based on that stereotype. Wait -- what?</h2>
<div id="byline">By Mike Elgan</div>
<div id="date">May 7, 2011 08:00 AM ET</div>
...
</div>

=== [http://www.apple.com/ Apple] ===

* Example page: [http://www.apple.com/imac/features.html Apple - iMac - Read about the features of the new iMac.]
<hgroup>
<h1><img src="http://images.apple.com/imac/images/features_title20110426.png" alt="Its beauty is way more than screen deep. " width="766" height="46" class="center" /></h1>
<p class="intro">All-new quad-core processors. Advanced graphics. Thunderbolt technology. FaceTime HD. iMac is a desktop workhorse disguised as an all-in-one wonder.</p>
</hgroup>

[[Category:Proposals]]

Hgroup element

2011-05-09T06:35:55Z

Lachlan Hunt: Start with list of real world examples

This page documents use cases and existing usage patterns related to marking up subtitles and taglines within headers.

== Real World Examples ==

The following are real world pages all using various structures to mark up subtitles and taglines for page and article headers. Each one contains the markup copied and pasted directly from the site, only modified where necessary to tidy up whitespace or to omit irrelevant content from the header where indicated.

The suggested HTML5 markup that follows each example illustrates an equivalent structure using the hgroup element. This is provided for comparison purposes only to see how well its design aligns with or differs from current practice.

=== [http://www.telegraph.co.uk/ The Telegraph (UK)] ===

Example article: [http://www.telegraph.co.uk/foodanddrink/8324778/Coca-Cola-recipe-discovered.html Coca Cola recipe 'discovered']

<div class="storyHead">
<h1>Coca Cola recipe 'discovered'</h1>
<h2>A website claims to have uncovered Coca-Cola's top secret recipe.</h2>
</div>

=== [http://www.nationalgeographic.com/ National Geographic] ===

Example article: [http://news.nationalgeographic.com/news/2011/05/110505-einstein-theories-confirmed-gravity-probe-nasa-space-science Einstein Theories Confirmed by NASA Gravity Probe]

<div id="page_head">
<h1>Einstein Theories Confirmed by NASA Gravity Probe</h1>
<h2 class="subtitle">Space mission did what the famed physicist said would be impossible.</h2>
</div>

=== [http://www.gutenberg.org/ Project Gutenberg] ===

Example article: [http://www.gutenberg.org/files/36/36-h/36-h.htm The War of the Worlds, by H. G. Wells]

<h3 class="chapnum">CHAPTER ONE</h3>
<h3 class="chaptitle">THE EVE OF THE WAR</h3>

Example article: [http://www.gutenberg.org/files/28749/28749-h/28749-h.htm The Madcap of the School, by Angela Brazil.]

<div style="margin: auto; text-align: center; padding-top: 0pt; padding-bottom: 1em;">
<a name="CHAPTER_I_THE_MOATED_GRANGE" id="CHAPTER_I_THE_MOATED_GRANGE"></a>
<h2>CHAPTER I</h2>
<h3>THE MOATED GRANGE</h3>
</div>

Example article: [http://www.gutenberg.org/files/98/98-h/98-h.htm A Tale of Two Cities, by Charles Dickens]

<h1>A TALE OF TWO CITIES</h1>
<h2>A STORY OF THE FRENCH REVOLUTION</h2><br>
<h2>By Charles Dickens</h2>

=== [http://www.techdirt.com/ Techdirt] ===

Example article: [http://www.techdirt.com/articles/20110506/15124514188/when-copyright-contracts-can-get-way-art.shtml When Copyright And Contracts Can Get In The Way Of Art]

<div class="story">
<h1>When Copyright And Contracts Can Get In The Way Of Art</h1>
<h3>from the <i>tales-from-the-creative-front-lines</i> dept</h3>
<p>...</p>
</div>

=== [http://xkcd.com/ XKCD] ===

<div id="topRightContainer">
<div id="logo">
<a href="/"><img src="http://imgs.xkcd.com/s/9be30a7.png" alt="xkcd.com logo" height="83" width="185"/></a>
<h2><br />A webcomic of romance,<br/> sarcasm, math, and language.</h2>
<div class="clearleft"></div>
<br />
XKCD updates every Monday, Wednesday, and Friday.
</div>
</div>

=== [http://finance.yahoo.com/ Yahoo! Finance] ===

Example article: [http://finance.yahoo.com/news/Gas-prices-expected-to-drop-apf-3767822723.html?x=0 Gas prices expected to drop 50 cents by summer]

<div id="y-article-hd">
<h1 class="test1">Gas prices expected to drop 50 cents by summer</h1>
<h2>After 44 days of surging gas prices, analysts expect drop of 50 cents by summer driving season<br></h2>
<a href="http://us.rd.yahoo.com/finance/news/apf/SIG=10kfmofol/*http://www.ap.org/termsandconditions" rel="nofollow"><img src="http://l.yimg.com/a/i/us/fi/gr/ap_106x27.gif" alt="ap" class="sponsorimage"></a>
...
</div>

=== [http://oed.com/ Oxford English Dictionary] ===

<h1>
<span><p>Discover the story of English</p><span class="blurb">
<p>More than 600,000 words, over a thousand years</p></span></span>
</h1>

=== [http://diveintoaccessibility.org/ Dive Into Accessibility] ===

<div id="logo">
<div class="inner">
<h1 class="title"><a href="/" accesskey="1">Dive Into Accessibility</a></h1>
<p>30 days to a more accessible web site</p>
<a class="skip" href="#startnavigation">Skip to navigation</a>
<span class="divider">&nbsp;</span>
</div>
</div>

=== [http://www.calgaryherald.com/ Calgary Herald] ===

Example article: [http://www.calgaryherald.com/life/Cooking+Solo+Grows/4746884/story.html Cooking Solo Grows Up]

<div id="storyheader">
<div class="headline">
<h1>Cooking Solo Grows Up</h1>
</div>
<div class="clear">&nbsp;</div>
<div class="subheadline">
<h2>On your own? You no longer have to put up with cereal over the sink or days of the same old leftovers. Joe Yonan shows us why</h2>
</div>
<div class="clear">&nbsp;</div>
<div class="byline">
<span class="name">By Gwendolyn Richards, Calgary Herald</span>
<span class="timestamp">May 8, 2011 2:06 AM</span>
<span id="lblComment" class="comments"></span>
</div>
<div class="clear">&nbsp;</div>
</div>

=== [http://www.panic.com/ Panic] ===

Example page: [http://www.panic.com/coda/ Coda - One-Window Web Development for Mac OS X]

<div id="header">
<h1><a href="/coda/" title="Coda">Coda</a></h1>
<p>One window web development.*</p>
</div>

Example page: [http://www.panic.com/unison/ Unison - The Best Usenet Browser / Newsreader, Only For Mac OS X]

<h1>
<a href="http://www.panic.com/unison/" title="Unison - The Best Usenet Browser">Unison</a>
<br>
the best usenet browser
</h1>

=== [http://www.pcworld.com/ PCWorld] ===

Example article: [http://www.pcworld.com/article/227313/top_15_android_apps_for_smartphone_shutterbugs.html Top 15 Android Apps For Smartphone Shutterbugs]

<div id="articleHead">
...
<h1>Top 15 Android Apps For Smartphone Shutterbugs</h1>
<h2>Use these Android apps to add effects to your mobile photos and make them easier to take.</h2>

<p class="byline">By <a href="/author/Daniel-Ionescu">Daniel Ionescu</a>,
<a href="http://www.pcworld.com/" target="_blank">PCWorld</a>
&nbsp;&nbsp; <script type="text/javascript">timestamp(1304707200000,'longDateTime')</script>May 6, 2011 8:40 pm</p>
</div>

=== [http://www.computerworld.com/ Computerworld] ===

Example article: [http://www.computerworld.com/s/article/9216484/Elgan_How_to_pop_your_Internet_filter_bubble_ Elgan: How to pop your Internet 'filter bubble']

<div id="article_header" class="clearfix">
<div id="content_type">Opinion</div>
<h1>Elgan: How to pop your Internet 'filter bubble'</h1>
<h2>Personalization algorithms are stereotyping you, then hiding information from you based on that stereotype. Wait -- what?</h2>
<div id="byline">By Mike Elgan</div>
<div id="date">May 7, 2011 08:00 AM ET</div>
...
</div>

[[Category:Proposals]]

Forking

2011-05-02T10:05:19Z

Lachlan Hunt: Defined differences between specification and language forks

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]].

For our purposes, there are two different approaches to forking.

: Language Forking
:: An alternative development path for the language created without using existing specification text as the basis of the work.
: Specification Forking
:: An alternative development path using existing specification text as the basis of a derivative work.

Since a ''language fork'' is not a derivative work according to copyright law, it may be done without the permission of the copyright holder. A ''specification fork'', however, requires a permissive licence or explicit permission from the copyright holder.

Standard licenses that permit specification forking include [https://creativecommons.org/publicdomain/zero/1.0/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

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

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

=== W3C-hosted forks ===

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

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

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

=== Other forks ===

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

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

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

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

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

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

== Modularization ==

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

== Supposed risks of forking ==

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

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

== Advantages of allowing forking ==

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

== Reasons preventing forking is not necessary ==

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

Content-Language

2010-06-29T08:17:24Z

Lachlan Hunt: /* allow multiple language tags in Content-Language */

{{stub}}

== <strong style="color:red">Open Poll Closes 2010-06-30</strong> ==
Please submit your objections to meta Content-Language in this poll (which closes <strong>very soon</strong>)

http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/

as well as adding them to this wiki page.

== Summary ==

The [[meta]] tag, specifically http-equiv Content-Language pragma, is confusing and broken and should be removed from HTML5 altogether.

See related issue: http://www.w3.org/html/wg/tracker/issues/88

== remove Content-Language ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0308

* This seems like the best option. It is preferable to remove broken features rather than keep them (even if "non-conforming") to minimize risk of continued misuse/misunderstanding and otherwise time-wasting on behalf of web designers and developers. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== keep Content-Language as non-conforming ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html

* I'd still prefer complete removal of a broken feature rather than issuing warnings. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== allow multiple language tags in Content-Language ==
http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages

* Even the "Summary" for this proposal is long and confusing. The workarounds provided in the change proposal increase web authoring complexity. Broken features should be removed, from the language and the specification, rather than asking web developers to waste time learning about broken features and how to work around them. Let's keep the spec as clean as possible. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

===Argument Summary===

* The change proposal is based upon the false premise that the Content-Language HTTP header and pragma directive are equivalent.
* The HTTP header is used to declare the languages of the intended audience, the only defined function of the pragma directive is to be used as a fallback language in the absence of the lang attribute.
* The use of the pragma directive as part of server configuration is out of scope of HTML. Specific server side implementation choices need not affect the conformance definition.
* The pragma directive only fulfils its purpose of providing a fallback language when one language tag is specified. Multiple language tags are, by definition of the implementation requirements, not useful.
* There are no reasons given for why it is beneficial to leave the pragma directive in the document, when the lang attribute is present on the root element.
* Failing to offer a warning about its presence in all cases would continue to mislead the author about its legitimacy.
* The inconsistency of when warnings are issued would be confusing to authors. It is better to offer a consistent warning about the presence of a redundant feature.
* The defined effect, per the implementation requirements, of declaring multiple language tags is identical to that of omitting the pragma directive entirely. No reasons are given to explain why declaring multiple language tags is useful or beneficial.
* The syntax of the Content-Language HTTP header field is not affected by the definition of the distinct Content-Language pragma directive in HTML, with which it only shares the same name, and not the functionality. It is reasonable for this distinct feature to use a different syntax that is suitable for its purpose.
* No reason is given explaining why only emitting the warning under specific circumstances, as opposed to the current specification requirement, would serve better to encourage authors to use the lang attribute instead.
* The proposed replacement specification text contains unjustified changes, inconsistencies, unimplementable requirements and is just downright inappropriate for use in the specification.
* The claimed positive benefits are unsupported by evidence and, in several cases, blatantly incorrect.
* In practice, very few authors use multiple language tags in the pragma directive, and doing so is not useful. Restricting the syntax to one language would not have a significant negative impact.

===Difference Between Content-Language HTTP Header and Pragma Directive===

This premise of this change proposal is that the Content-Language HTTP header field is functionally equivalent to the Content-Language pragma directive using the meta element. This premise is used to support the idea that that both should share the same syntax and client side processing requirements. However, this premise is demonstrably wrong, and thus the change proposal is unsupported by evidence and must be rejected.

In order to demonstrate the differences between the HTTP header and the pragma directive, it is necessary to analyse the purpose and functionality of each and see how they compare.

====Declaring the Language of the Intended Audience====

The HTTP Content-Language header field is used by HTTP servers to announce the language of the intended audience for a given resource representation. This and other related information exchanged between the client and server can be used for content negotiation based on language. When the server does this, it is important for this information to be included in the HTTP header where it can be seen by both the client and other intermediary servers.

The information declared within the document using the pragma directive is unsuitable for this purpose, as it will not be parsed by intermediary servers that would otherwise utilise the information for caching purposes.

====Server Configuration====

It has been claimed that the information declared using a pragma directive within the document may be parsed by some server implementations, which subsequently process and echo the value in the Content-Language HTTP header field. Since this header field is allowed to contain multiple language values, it is claimed that this ability is limited by permitting only one language in the pragma directive. However, no evidence has been presented to demonstrate how widely used this feature is, nor why such a feature should even be defined within HTML.

This is a layering violation because information intended for server side processing, and specific implementation details thereof, should not unnecessarily affect the conformance definition of client side HTML. That is, it is out of scope for HTML, as a client side markup language, to define specific processing requirements or features to be used by servers for implementing HTTP features. There is also no inherent need for interoperability between different back end implementation details.

Defining the pragma directive in a way that is optimised for specific server implementation details would be analogous to, for example, defining an ASP specific feature within HTML for use on Microsoft IIS platforms. While server implementations are otherwise free to make any design choices, those design choices need not affect HTML conformance requirements.

====Default Document Language====

In practice, Content-Language used within the meta element in the HTML serves as client side metadata. The functionality of Content-Language in this case is restricted entirely to the purpose of specifying a fallback language, to be used in the absence of the lang attribute. This purpose differs significantly from the purpose of declaring the languages of the intended audience.

Declaring multiple languages for the document's intended audience makes sense in some cases. However, there can only be one default language. Thus, for this purpose, the functionality as defined requires that only a single language value be specified. While the HTTP Content-Language header field is also used for determining the fallback language in cases where it only has a single language value, that is not its primary purpose and is thus not a significant similarity between these two independent features.

Permitting multiple language values to be specified in the pragma directive is at odds with its implementation requirements. Thus, for the client-side meta data functionality of the pragma directive, it is not at all useful to have multiple languages specified, and so it does not make sense for multiple languages to be considered conforming.

These 3 aspects of the functionality — declaring the language of the intended audience, server side configuration and default document language — clearly illustrate that the premise of this change proposal — the shared functionality between the two features — is fundamentally flawed. The reality is that the in-document Content-Language pragma directive only shares its name with the HTTP header field, while its functionality is closer to that of the lang attribute. And since server side implementation details are out of scope of HTML, there is no need for the document conformance definition to permit multiple language values. The solution chosen for addressing this issue must take this into account, and thus reject this change proposal.

===Arguments Against the Rationale===

The rationale for this change proposal states:

<blockquote>"[The current specification] offers no carrot for doing the right thing. while the fallback language effect stops as soon as the author adds lang on the root element, the spec requires conformance checker to continue whining until the http-equiv="Content-Language" meta element has been removed."</blockquote>

The rationale fails to explain the benefit gained by leaving the pragma directive in the document when a lang attribute has been specified on the root element. While leaving it in the document under those circumstances is mostly harmless, it is redundant metadata that the author does not need to include in their document. Failing to offer a warning would continue to mislead the author into thinking that the pragma directive is both acceptable and useful, which it is not.

<blockquote>"That it prevents authors from legally using multiple values to replicate the language fallback effect of doing the same thing in a HTTP header — whether they want to replicate the effect of multiple tags or a single tag."</blockquote>

The language fallback effect from using multiple language tags within the value is that there is no default language. This is exactly the same effect as would be achieved by omitting the pragma directive, and so the given reason is blatantly wrong about having no way to replicate the effect of having no specified language. This rationale also fails to provide a reason for wanting to replicate this effect by copying the same syntax.

i.e. The effect of including:

<meta http-equiv="Content-Language" content="en, fr">

is <em>identical</em> to that of omitting this pragma directive entirely, and there is no reason for wanting to include the above either.

<blockquote>That it underlines the confusion that may exist today, about the nature of lang versus Content-Language, by requiring:

# different syntax rules for features that are expected to be identical (HTTP and http-equiv)
# similar syntax rules for features that are different (http-equiv and lang)
# a warning message which asks authors to “use lang instead” – as if they were juxtaposable alternatives.</blockquote>

The HTTP Content-Type header and the http-equiv pragma directive <em>are</em> different. The HTTP header is used for declaring the languages of the intended audience, the pragma directive is used for specifying a default language.

The lang attribute, on the other hand, is an alternative to the pragma directive because the pragma directive only serves to specify the language of the document when a single value is used. When multiple languages are specified in the pragma directive, there is absolutely no defined effect, and so it serves no valid purpose at all.

Therefore, the pragma directive is much closer in functionality to the lang attribute, than it is to the HTTP header, with which it shares its name.

<blockquote>Instead of the above, this change proposal propose:

* the Zero-edit proposal’s warning about using lang instead of Content-Language should be changed into a warning which informs that a fallback language measure has kicked in, and recommend that authors create a language declaration (via lang) rather than relying on the fallback feature. This warning should be shown regardless of whether the fallback comes from http-equiv or from the higher level (HTTP). Justification: Since it is a fallback feature, and with other semantics, there is no guarantee that the author has used it for the language effect.</blockquote>

From the authors perspective, the inconsistency of issuing the warning about the use of the pragma directive only when the lang attribute is absent would be confusing. The better alternative is to issue a consistent warning (or error) that simply says to remove the pragma directive and use lang instead.

<blockquote>...

* to hold the syntax rules of HTTP (which permits multiple language tags) as the conforming ones (rather than those of lang, which forbids multiple languages), will have the effect of underlining that lang and Content-Language have different purposes. For instance, since the fallback algorithm doesn’t kick in whenever multiple languages are used in the pragma or on the server, there would not be any warning in these cases. </blockquote>

The syntax requirements for the HTTP Content-Type header are not affected by the HTML implementation requirements. Since the lang attribute on the root element and the Content-Language pragma directive with a single language value do have the same effect, which differs significantly from the purpose of the HTTP Content-Language header, and it is misleading to pretend otherwise, the syntax of the former does not need to match the syntax of the latter.

<blockquote>...

* a carrot: what we want from authors is that they rely on lang (and xml:lang) for specifying the language — when the author does that, he/she should get immediate reward in the form of removal of conformance warning.</blockquote>

This rationale fails to explain why that same effect of encouraging authors to use the lang attribute, would not be achieved by a more consistent warning that states to use the lang attribute and remove the pragma directive. There is no benefit gained by leaving the directive in, and merely silencing the validator by inserting a lang attribute does little to discourage the use of the redundant and totally unnecessary pragma directive.

===Arguments Against the Proposal Details===

The change proposal suggests replacing the terminology for "pragma-set default language" with "pragma-set locale language". None of the given rationale explains the need for this change in terminology.

The proposed specification text states:

<blockquote>This pragma contains a Content-Language list, whose semantics and syntax is defined in the HTTP spec.</blockquote>

The semantics of the Content-Language header field as defined in RFC 2616 states:

<blockquote>The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.</blockquote>

This semantic definition does not match the actual purpose of the Content-Language pragma directive, for specifying a "pragma-set locale language". Therefore, referring to RFC 2616 for this semantic definition is inappropriate. The syntax requirements from RFC 2616 are also inappropriate, as it defines the following ABNF, which is not directly compatible with the syntax of the meta element with http-equiv and content attributes.

<pre>Content-Language = "Content-Language" ":" 1#language-tag
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA</pre>

For these syntax requirements to be applicable at all, the specification would have to state that the value of the content attribute must match the ABNF production for language-tag. However, see below regarding the syntax defined in BCP 47.

The proposed text then states:

<blockquote>An HTML5 parser processes this list into a known or unknown pragma-set locale language... The Content-Language list may also be defined in a HTTP header, and will then result in a known or unknown HTTP header-set locale language.</blockquote>

The proposed text fails to define what "known or unknown" means in that context. It is not clear how the implementation determines whether a value is known or unknown.

The parsing requirements for the value of this pragma directive are not specified by the change proposal. However, the change proposal also does not state that the existing parsing requirements in the specification are to be removed, replaced or modified in any way. Thus, by adopting the details of this change proposal, the specification would be left in an inconsistent state which says that multiple language values are supported, but where the parsing requirements abort when more than one value is used.

The aforementioned parsing requirements only focus on parsing the value of the pragma directive, and as such, there is no implementation requirement that sets the "HTTP header-set locale language".

<blockquote>When a document is lacking a language declaration in the form of the lang or xml:lang attribute on the root element, the document’s locale language (pragma-set or HTTP-set) is consulted by the user agent and used as fallback value for the primary document language.</blockquote>

Assuming the value of the "HTTP header-set locale language" comes from the HTTP Content-Language header, this proposed text fails to specify the order of precedence of the values specified in the pragma directive or the HTTP header.

The use of the term "locale language" in this context clashes with the existing use of the term in the specification to refer to the language set by the user in the user agent's preferences. This term is used in the table within step 7 of the algorithm to determine the character encoding.

The proposed text then goes on to state:

<blockquote>The following info about the HTTP semantics and Content-Language usage, is informative: </blockquote>

However, in the non-normative list given following that statement, RFC 2119 terminology is incorrectly used to describe what appear to be authoring requirements. In particular:

<blockquote>... authors should not define the Content-Language list according to its parser effect, but according to it semantics.</blockquote>

This non-normative example text also incorrectly states that "en-US" would not be parsed into a useful value. However, this value complies with the syntax requirements specified in RFC 2616, BCP 47 and also with the existing parsing requirements in the HTML5 specification.

The proposal states that the following requirement is to be removed:

<blockquote>Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead.</blockquote>

The rationale provided does not adequately justify the removal of this warning, and nor does it adequately justify replacing it with a more limited warning to be issued only when the pragma directive is in the absence of the lang attribute.

The proposal then states to amend this requirement as follows:

<blockquote>the content attribute must have a value consisting of a valid BCP 47 language tag, or a comma separated list of two or more BCP 47 language tags.</blockquote>

However, the proposal stated earlier that the syntax for the value was defined by RFC 2616. This requirement now conflicts with that by stating that the syntax of the content attribute's value is defined by BCP 47. This inconsistency negatively affects the quality of the specification.

The proposal states that this note is to be removed:

<blockquote>This pragma is not exactly equivalent to the HTTP Content-Language header, for instance it only supports one language.</blockquote>

The removal of this note would be misleading, because the note itself is factually correct as-is with the current specification, and with the details of this proposal, which, as stated above, leave the parsing requirements unchanged. The proposal fails to include any implementation requirements that actually permit multiple language tags to be used.

It has now been clearly demonstrated that the proposed specification text provided by this change proposal is thoroughly inadequate for its intended purpose. If the specification were to be amended as required by this change proposal, the inconsistency and lack of clarity would negatively affect the ability to read, understand and implement this specification. As such, this proposal should also be rejected on the basis that its proposal details are inadequate. However, if this working group does make the wrong decision to permit multiple language tags, then I ask that the editor be given full editorial discretion to phrase the requirements in a way that more clearly expresses the requirements, rather than being asked to accept the details of this proposal as written.

===Arguments Against the Claimed Positive and Negative Effects===

<blockquote>More positive: authors can get rid of the warning by adding something — <html lang="*"> — this is better than a focus on removal of the (over all) harmless Content-Language meta element.</blockquote>

Likewise, authors can get rid of the warning as required by the current specification by removing the meta element. No rationale is provided to explain why the act of removing the pragma directive is significantly more difficult than adding the lang attribute to the root element. Depending on the authoring tool or CMS, both of these actions are likely to be just as easy or just as difficult to perform. This purported benefit is thus unsubstantiated and invalid.

<blockquote>More stable: same syntax as before continue to be permitted.</blockquote>

As documented by the zero edit change proposal, observation of the use of this pragma directive shows that only a very small minority of authors use multiple language values. However, the claimed benefit of continuing to use this syntax is nullified by the fact that, due to the implementation requirements, multiple language values are not at all useful.

<blockquote>More permissive: authors, CMS-es and browsers can continue to take advantage of HTTP-EQUIV’s ability to reference what the HTTP header is/was supposed to be, including replicating its fallback effect.</blockquote>

No rationale is provided to explain why that ability is in any way beneficial.

<blockquote>More correct: the difference between lang and Content-Language is pointed out, while the link between http-equiv and HTTP is emphasized.</blockquote>

As has been demonstrated, this is blatantly wrong. The lang attribute and the Content-Language pragma directive share more in common in terms of functionality, than to the pragma directive and the Content-Language HTTP header field.

<blockquote>More useful: a warning that a fallback feature has kicked in, is more useful than a warning which focuses on one of the places where the fallback language could potentially kick in from. Why tell the author to “please use lang instead” if the author has already made sure that the lang attribute is in place?</blockquote>

It seems more useful for authors to be informed about the presence of a redundant and useless feature, than to have them continue to mistakenly believe that the pragma directive is in any way useful. However, either way, both of these are highly subjective claims about what may or may not be useful to authors, which cannot be objectively evaluated without supporting data.

<blockquote>Has positive side effect: Encouragement to place a lang attribute on the starttag of the html element will lead authors to actually type in the html root element, instead of relying on the parser to generate it for them.</blockquote>

Relative to the status quo, the zero edit change proposal, or the proposal to make Content-Language non-conforming, the above is not a unique benefit. Both this and the other change proposals require validators to notify the author about the issue and encourage the use of the lang attribute.

<blockquote>More accurate because it does not conceal the problems by introducing an artificial technical and semantic difference between Content-Language from the HTTP header and Content-Language inside the http-equiv meta element.</blockquote>

This accuracy claim is undeniably wrong, given that the significant differences between the HTTP header and pragma directive have already been explained.

Content-Language

2010-06-29T08:16:26Z

Lachlan Hunt: /* allow multiple language tags in Content-Language */ Added summary

Content-Language

2010-06-29T07:22:43Z

Lachlan Hunt: /* allow multiple language tags in Content-Language */ Added arguments against the positive and negative effects

{{stub}}

== <strong style="color:red">Open Poll Closes 2010-06-30</strong> ==
Please submit your objections to meta Content-Language in this poll (which closes <strong>very soon</strong>)

http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/

as well as adding them to this wiki page.

== Summary ==

The [[meta]] tag, specifically http-equiv Content-Language pragma, is confusing and broken and should be removed from HTML5 altogether.

See related issue: http://www.w3.org/html/wg/tracker/issues/88

== remove Content-Language ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0308

* This seems like the best option. It is preferable to remove broken features rather than keep them (even if "non-conforming") to minimize risk of continued misuse/misunderstanding and otherwise time-wasting on behalf of web designers and developers. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== keep Content-Language as non-conforming ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html

* I'd still prefer complete removal of a broken feature rather than issuing warnings. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== allow multiple language tags in Content-Language ==
http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages

* Even the "Summary" for this proposal is long and confusing. The workarounds provided in the change proposal increase web authoring complexity. Broken features should be removed, from the language and the specification, rather than asking web developers to waste time learning about broken features and how to work around them. Let's keep the spec as clean as possible. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

===Difference Between Content-Language HTTP Header and Pragma Directive===

This premise of this change proposal is that the Content-Language HTTP header field is functionally equivalent to the Content-Language pragma directive using the meta element. This premise is used to support the idea that that both should share the same syntax and client side processing requirements. However, this premise is demonstrably wrong, and thus the change proposal is unsupported by evidence and must be rejected.

In order to demonstrate the differences between the HTTP header and the pragma directive, it is necessary to analyse the purpose and functionality of each and see how they compare.

====Declaring the Language of the Intended Audience====

The HTTP Content-Language header field is used by HTTP servers to announce the language of the intended audience for a given resource representation. This and other related information exchanged between the client and server can be used for content negotiation based on language. When the server does this, it is important for this information to be included in the HTTP header where it can be seen by both the client and other intermediary servers.

The information declared within the document using the pragma directive is unsuitable for this purpose, as it will not be parsed by intermediary servers that would otherwise utilise the information for caching purposes.

====Server Configurataion====

It has been claimed that the information declared using a pragma directive within the document may be parsed by some server implementations, which subsequently process and echo the value in the Content-Language HTTP header field. Since this header field is allowed to contain multiple language values, it is claimed that this ability is limited by permitting only one language in the pragma directive. However, no evidence has been presented to demonstrate how widely used this feature is, nor why such a feature should even be defined within HTML.

This is a layering violation because information intended for server side processing, and specific implementation details thereof, should not unnecessarily affect the conformance definition of client side HTML. That is, it is out of scope for HTML, as a client side markup language, to define specific processing requirements or features to be used by servers for implementing HTTP features. There is also no inherent need for interoperability between different back end implementation details.

Defining the pragma directive in a way that is optimised for specific server implementation details would be analogous to, for example, defining an ASP specific feature within HTML for use on Microsoft IIS platforms. While server implementations are otherwise free to make any design choices, those design choices need not affect HTML conformance requirements.

====Default Document Language====

In practice, Content-Language used within the meta element in the HTML serves as client side metadata. The functionality of Content-Language in this case is restricted entirely to the purpose of specifying a fallback language, to be used in the absence of the lang attribute. This purpose differs significantly from the purpose of declaring the languages of the intended audience.

Declaring multiple languages for the document's intended audience makes sense in some cases. However, there can only be one default language. Thus, for this purpose, the functionality as defined requires that only a single language value be specified. While the HTTP Content-Language header field is also used for determining the fallback language in cases where it only has a single language value, that is not its primary purpose and is thus not a significant similarity between these two independent features.

Permitting multiple language values to be specified in the pragma directive is at odds with its implementation requirements. Thus, for the client-side meta data functionality of the pragma directive, it is not at all useful to have multiple languages specified, and so it does not make sense for multiple languages to be considered conforming.

These 3 aspects of the functionality — declaring the langauge of the intended audience, server side configuration and default document language — clearly illustrate that the premise of this change proposal — the shared functionality between the two features — is fundamentally flawed. The reality is that the in-document Content-Language pragma directive only shares its name with the HTTP header field, while its functionality is closer to that of the lang attribute. And since server side implementation details are out of scope of HTML, there is no need for the document conformance definition to permit multiple language values. The solution chosen for addressing this issue must take this into account, and thus reject this change proposal.

===Arguments Against the Rationale===

The rationale for this change proposal states:

<blockquote>"[The current specification] offers no carrot for doing the right thing. while the fallback language effect stops as soon as the author adds lang on the root element, the spec requires conformance checker to continue whining until the http-equiv="Content-Language" meta element has been removed."</blockquote>

The rationale fails to explain the benefit gained by leaving the pragma directive in the document when a lang attribute has been specified on the root element. While leaving it in the document under those circumstances is mostly harmless, it is redundant metadata that the author does not need to include in their document. Failing to offer a warning would continue to mislead the author into thinking that the pragma directive is both acceptable and useful, which it is not.

<blockquote>"That it prevents authors from legally using multiple values to replicate the language fallback effect of doing the same thing in a HTTP header — whether they want to replicate the effect of multiple tags or a single tag."</blockquote>

The language fallback effect from using multiple language tags within the value is that there is no default language. This is exactly the same effect as would be achieved by omitting the pragma directive, and so the given reason is blatantly wrong about having no way to replicate the effect of having no specified language. This rationale also fails to provide a reason for wanting to replicate this effect by copying the same syntax.

i.e. The effect of including:

<meta http-equiv="Content-Language" content="en, fr">

is <em>identical</em> to that of omitting this pragma directive entirely, and there is no reason for wanting to include the above either.

<blockquote>That it underlines the confusion that may exist today, about the nature of lang versus Content-Language, by requiring:

# different syntax rules for features that are expected to be identical (HTTP and http-equiv)
# similar syntax rules for features that are different (http-equiv and lang)
# a warning message which asks authors to “use lang instead” – as if they were juxtaposable alternatives.</blockquote>

The HTTP Content-Type header and the http-equiv pragma directive <em>are</em> different. The HTTP header is used for declaring the languages of the intended audience, the pragma directive is used for specifying a default language.

The lang attribute, on the other hand, is an alternative to the pragma directive because the pragma directive only serves to specify the language of the document when a single value is used. When multiple languages are specified in the pragma directive, there is absolutely no defined effect, and so it serves no valid purpose at all.

Therefore, the pragma directive is much closer in functionality to the lang attribute, than it is to the HTTP header, with which it shares its name.

<blockquote>Instead of the above, this change proposal propose:

* the Zero-edit proposal’s warning about using lang instead of Content-Language should be changed into a warning which informs that a fallback language measure has kicked in, and recommend that authors create a language declaration (via lang) rather than relying on the fallback feature. This warning should be shown regardless of whether the fallback comes from http-equiv or from the higher level (HTTP). Justification: Since it is a fallback feature, and with other semantics, there is no guarantee that the author has used it for the language effect.</blockquote>

From the authors perspective, the inconsistency of issuing the warning about the use of the pragma directive only when the lang attribute is absent would be confusing. The better alternative is to issue a consistent warning (or error) that simply says to remove the pragma directive and use lang instead.

<blockquote>...

* to hold the syntax rules of HTTP (which permits multiple language tags) as the conforming ones (rather than those of lang, which forbids multiple languages), will have the effect of underlining that lang and Content-Language have different purposes. For instance, since the fallback algorithm doesn’t kick in whenever multiple languages are used in the pragma or on the server, there would not be any warning in these cases. </blockquote>

The syntax requirements for the HTTP Content-Type header are not affected by the HTML implementation requirements. Since the lang attribute on the root element and the Content-Language pragma directive with a single language value do have the same effect, which differs significantly from the purpose of the HTTP Content-Language header, and it is misleading to pretend otherwise, the syntax of the former does not need to match the syntax of the latter.

<blockquote>...

* a carrot: what we want from authors is that they rely on lang (and xml:lang) for specifying the language — when the author does that, he/she should get immediate reward in the form of removal of conformance warning.</blockquote>

This rationale fails to explain why that same effect of encouraging authors to use the lang attribute, would not be achieved by a more consistent warning that states to use the lang attribute and remove the pragma directive. There is no benefit gained by leaving the directive in, and merely silencing the validator by inserting a lang attribute does little to discourage the use of the redundant and totally unnecessary pragma directive.

===Arguments Against the Proposal Details===

The change proposal suggests replacing the terminology for "pragma-set default language" with "pragma-set locale language". None of the given rationale explains the need for this change in terminology.

The proposed specification text states:

<blockquote>This pragma contains a Content-Language list, whose semantics and syntax is defined in the HTTP spec.</blockquote>

The semantics of the Content-Language header field as defined in RFC 2616 states:

<blockquote>The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.</blockquote>

This semantic definition does not match the actual purpose of the Content-Language pragma directive, for specifying a "pragma-set locale language". Therefore, referring to RFC 2616 for this semantic definition is inappropriate. The syntax requirements from RFC 2616 are also inappropriate, as it defines the following ABNF, which is not directly compatible with the syntax of the meta element with http-equiv and content attributes.

<pre>Content-Language = "Content-Language" ":" 1#language-tag
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA</pre>

For these syntax requirements to be applicable at all, the specification would have to state that the value of the content attribute must match the ABNF production for language-tag. However, see below regarding the syntax defined in BCP 47.

The proposed text then states:

<blockquote>An HTML5 parser processes this list into a known or unknown pragma-set locale language... The Content-Language list may also be defined in a HTTP header, and will then result in a known or unknown HTTP header-set locale language.</blockquote>

The proposed text fails to define what "known or unknown" means in that context. It is not clear how the implementation determines whether a value is known or unknown.

The parsing requirements for the value of this pragma directive are not specified by the change proposal. However, the change proposal also does not state that the existing parsing requirements in the specification are to be removed, replaced or modified in any way. Thus, by adopting the details of this change proposal, the specification would be left in an inconsistent state which says that multiple language values are supported, but where the parsing requirements abort when more than one value is used.

The aforementioned parsing requirements only focus on parsing the value of the pragma directive, and as such, there is no implementation requirement that sets the "HTTP header-set locale language".

<blockquote>When a document is lacking a language declaration in the form of the lang or xml:lang attribute on the root element, the document’s locale language (pragma-set or HTTP-set) is consulted by the user agent and used as fallback value for the primary document language.</blockquote>

Assuming the value of the "HTTP header-set locale language" comes from the HTTP Content-Language header, this proposed text fails to specify the order of precedence of the values specified in the pragma directive or the HTTP header.

The use of the term "locale language" in this context clashes with the existing use of the term in the specification to refer to the language set by the user in the user agent's preferences. This term is used in the table within step 7 of the algorithm to determine the character encoding.

The proposed text then goes on to state:

<blockquote>The following info about the HTTP semantics and Content-Language usage, is informative: </blockquote>

However, in the non-normative list given following that statement, RFC 2119 terminology is incorrectly used to describe what appear to be authoring requirements. In particular:

<blockquote>... authors should not define the Content-Language list according to its parser effect, but according to it semantics.</blockquote>

This non-normative example text also incorrectly states that "en-US" would not be parsed into a useful value. However, this value complies with the syntax requirements specified in RFC 2616, BCP 47 and also with the existing parsing requirements in the HTML5 specification.

The proposal states that the following reqiurement is to be removed:

<blockquote>Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead.</blockquote>

The rationale provided does not adequately justify the removal of this warning, and nor does it adequately justify replacing it with a more limited warning to be issued only when the pragma directive is in the absence of the lang attribute.

The proposal then states to amend this requirement as follows:

<blockquote>the content attribute must have a value consisting of a valid BCP 47 language tag, or a comma separated list of two or more BCP 47 language tags.</blockquote>

However, the proposal stated earlier that the syntax for the value was defined by RFC 2616. This requirement now conflicts with that by stating that the syntax of the content attribute's value is defined by BCP 47. This inconsistency negatively affects the quality of the specification.

The proposal states that this note is to be removed:

<blockquote>This pragma is not exactly equivalent to the HTTP Content-Language header, for instance it only supports one language.</blockquote>

The removal of this note would be misleading, because the note itself is factually correct as-is with the current specification, and with the details of this proposal, which, as stated above, leave the parsing requirements unchanged. The proposal fails to include any implementation requirements that actually permit multiple language tags to be used.

It has now been clearly demonstrated that the proposed specification text provided by this change proposal is thoroughly inadequate for its intended purpose. If the specification were to be amended as required by this change proposal, the inconsistency and lack of clarity would negatively affect the ability to read, understand and implement this specification. As such, this proposal should also be rejected on the basis that its proposal details are inadequate. However, if this working group does make the wrong decision to permit multiple language tags, then I ask that the editor be given full editorial discretion to phrase the requirements in a way that more clearly expresses the requirements, rather than being asked to accept the details of this proposal as written.

===Arguments Against the Claimed Positive and Negative Effects===

<blockquote>More positive: authors can get rid of the warning by adding something — <html lang="*"> — this is better than a focus on removal of the (over all) harmless Content-Language meta element.</blockquote>

Likewise, authors can get rid of the warning as required by the current specification by removing the meta element. No rationale is provided to explain why the act of removing the pragma directive is significantly more difficult than adding the lang attribute to the root element. Depending on the authoring tool or CMS, both of these actions are likely to be just as easy or just as difficult to perform. This purported benefit is thus unsubstantiated and invalid.

<blockquote>More stable: same syntax as before continue to be permitted.</blockquote>

As documented by the zero edit change proposal, observation of the use of this pragma directive shows that only a very small minority of authors use multiple language values. However, the claimed benefit of continuing to use this syntax is nullified by the fact that, due to the implementation requirements, multiple language values are not at all useful.

<blockquote>More permissive: authors, CMS-es and browsers can continue to take advantage of HTTP-EQUIV’s ability to reference what the HTTP header is/was supposed to be, including replicating its fallback effect.</blockquote>

No rationale is provided to explain why that ability is in any way beneficial.

<blockquote>More correct: the difference between lang and Content-Language is pointed out, while the link between http-equiv and HTTP is emphasized.</blockquote>

As has been demonstrated, this is blatantly wrong. The lang attribute and the Content-Language pragma directive share more in common in terms of functionality, than to the pragma directive and the Content-Language HTTP header field.

<blockquote>More useful: a warning that a fallback feature has kicked in, is more useful than a warning which focuses on one of the places where the fallback language could potentially kick in from. Why tell the author to “please use lang instead” if the author has already made sure that the lang attribute is in place?</blockquote>

It seems more useful for authors to be informed about the presence of a redundant and useless feature, than to have them continue to mistakenly believe that the pragma directive is in any way useful. However, either way, both of these are highly subjective claims about what may or may not be useful to authors, which cannot be objectively evaluated without supporting data.

<blockquote>Has positive side effect: Encouragement to place a lang attribute on the starttag of the html element will lead authors to actually type in the html root element, instead of relying on the parser to generate it for them.</blockquote>

Relative to the status quo, the zero edit change proposal, or the proposal to make Content-Language non-conforming, the above is not a unique benefit. Both this and the other change proposals require validators to notify the author about the issue and encourage the use of the lang attribute.

<blockquote>More accurate because it does not conceal the problems by introducing an artificial technical and semantic difference between Content-Language from the HTTP header and Content-Language inside the http-equiv meta element.</blockquote>

This accuracy claim is undeniably wrong, given that the significant differences between the HTTP header and pragma directive have already been explained.

Content-Language

2010-06-28T14:26:40Z

Lachlan Hunt: /* Arguments Against the Proposal Details */ typo

{{stub}}

== <strong style="color:red">Open Poll Closes 2010-06-30</strong> ==
Please submit your objections to meta Content-Language in this poll (which closes <strong>very soon</strong>)

http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/

as well as adding them to this wiki page.

== Summary ==

The [[meta]] tag, specifically http-equiv Content-Language pragma, is confusing and broken and should be removed from HTML5 altogether.

See related issue: http://www.w3.org/html/wg/tracker/issues/88

== remove Content-Language ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0308

* This seems like the best option. It is preferable to remove broken features rather than keep them (even if "non-conforming") to minimize risk of continued misuse/misunderstanding and otherwise time-wasting on behalf of web designers and developers. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== keep Content-Language as non-conforming ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html

* I'd still prefer complete removal of a broken feature rather than issuing warnings. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== allow multiple language tags in Content-Language ==
http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages

* Even the "Summary" for this proposal is long and confusing. The workarounds provided in the change proposal increase web authoring complexity. Broken features should be removed, from the language and the specification, rather than asking web developers to waste time learning about broken features and how to work around them. Let's keep the spec as clean as possible. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

===Difference Between Content-Language HTTP Header and Pragma Directive===

This premise of this change proposal is that the Content-Language HTTP header field is functionally equivalent to the Content-Language pragma directive using the meta element. This premise is used to support the idea that that both should share the same syntax and client side processing requirements. However, this premise is demonstrably wrong, and thus the change proposal is unsupported by evidence and must be rejected.

In order to demonstrate the differences between the HTTP header and the pragma directive, it is necessary to analyse the purpose and functionality of each and see how they compare.

====Declaring the Language of the Intended Audience====

The HTTP Content-Language header field is used by HTTP servers to announce the language of the intended audience for a given resource representation. This and other related information exchanged between the client and server can be used for content negotiation based on language. When the server does this, it is important for this information to be included in the HTTP header where it can be seen by both the client and other intermediary servers.

The information declared within the document using the pragma directive is unsuitable for this purpose, as it will not be parsed by intermediary servers that would otherwise utilise the information for caching purposes.

====Server Configurataion====

It has been claimed that the information declared using a pragma directive within the document may be parsed by some server implementations, which subsequently process and echo the value in the Content-Language HTTP header field. Since this header field is allowed to contain multiple language values, it is claimed that this ability is limited by permitting only one language in the pragma directive. However, no evidence has been presented to demonstrate how widely used this feature is, nor why such a feature should even be defined within HTML.

This is a layering violation because information intended for server side processing, and specific implementation details thereof, should not unnecessarily affect the conformance definition of client side HTML. That is, it is out of scope for HTML, as a client side markup language, to define specific processing requirements or features to be used by servers for implementing HTTP features. There is also no inherent need for interoperability between different back end implementation details.

Defining the pragma directive in a way that is optimised for specific server implementation details would be analogous to, for example, defining an ASP specific feature within HTML for use on Microsoft IIS platforms. While server implementations are otherwise free to make any design choices, those design choices need not affect HTML conformance requirements.

====Default Document Language====

In practice, Content-Language used within the meta element in the HTML serves as client side metadata. The functionality of Content-Language in this case is restricted entirely to the purpose of specifying a fallback language, to be used in the absence of the lang attribute. This purpose differs significantly from the purpose of declaring the languages of the intended audience.

Declaring multiple languages for the document's intended audience makes sense in some cases. However, there can only be one default language. Thus, for this purpose, the functionality as defined requires that only a single language value be specified. While the HTTP Content-Language header field is also used for determining the fallback language in cases where it only has a single language value, that is not its primary purpose and is thus not a significant similarity between these two independent features.

Permitting multiple language values to be specified in the pragma directive is at odds with its implementation requirements. Thus, for the client-side meta data functionality of the pragma directive, it is not at all useful to have multiple languages specified, and so it does not make sense for multiple languages to be considered conforming.

These 3 aspects of the functionality — declaring the langauge of the intended audience, server side configuration and default document language — clearly illustrate that the premise of this change proposal — the shared functionality between the two features — is fundamentally flawed. The reality is that the in-document Content-Language pragma directive only shares its name with the HTTP header field, while its functionality is closer to that of the lang attribute. And since server side implementation details are out of scope of HTML, there is no need for the document conformance definition to permit multiple language values. The solution chosen for addressing this issue must take this into account, and thus reject this change proposal.

===Arguments Against the Rationale===

The rationale for this change proposal states:

<blockquote>"[The current specification] offers no carrot for doing the right thing. while the fallback language effect stops as soon as the author adds lang on the root element, the spec requires conformance checker to continue whining until the http-equiv="Content-Language" meta element has been removed."</blockquote>

The rationale fails to explain the benefit gained by leaving the pragma directive in the document when a lang attribute has been specified on the root element. While leaving it in the document under those circumstances is mostly harmless, it is redundant metadata that the author does not need to include in their document. Failing to offer a warning would continue to mislead the author into thinking that the pragma directive is both acceptable and useful, which it is not.

<blockquote>"That it prevents authors from legally using multiple values to replicate the language fallback effect of doing the same thing in a HTTP header — whether they want to replicate the effect of multiple tags or a single tag."</blockquote>

The language fallback effect from using multiple language tags within the value is that there is no default language. This is exactly the same effect as would be achieved by omitting the pragma directive, and so the given reason is blatantly wrong about having no way to replicate the effect of having no specified language. This rationale also fails to provide a reason for wanting to replicate this effect by copying the same syntax.

i.e. The effect of including:

<meta http-equiv="Content-Language" content="en, fr">

is <em>identical</em> to that of omitting this pragma directive entirely, and there is no reason for wanting to include the above either.

<blockquote>That it underlines the confusion that may exist today, about the nature of lang versus Content-Language, by requiring:

# different syntax rules for features that are expected to be identical (HTTP and http-equiv)
# similar syntax rules for features that are different (http-equiv and lang)
# a warning message which asks authors to “use lang instead” – as if they were juxtaposable alternatives.</blockquote>

The HTTP Content-Type header and the http-equiv pragma directive <em>are</em> different. The HTTP header is used for declaring the languages of the intended audience, the pragma directive is used for specifying a default language.

The lang attribute, on the other hand, is an alternative to the pragma directive because the pragma directive only serves to specify the language of the document when a single value is used. When multiple languages are specified in the pragma directive, there is absolutely no defined effect, and so it serves no valid purpose at all.

Therefore, the pragma directive is much closer in functionality to the lang attribute, than it is to the HTTP header, with which it shares its name.

<blockquote>Instead of the above, this change proposal propose:

* the Zero-edit proposal’s warning about using lang instead of Content-Language should be changed into a warning which informs that a fallback language measure has kicked in, and recommend that authors create a language declaration (via lang) rather than relying on the fallback feature. This warning should be shown regardless of whether the fallback comes from http-equiv or from the higher level (HTTP). Justification: Since it is a fallback feature, and with other semantics, there is no guarantee that the author has used it for the language effect.</blockquote>

From the authors perspective, the inconsistency of issuing the warning about the use of the pragma directive only when the lang attribute is absent would be confusing. The better alternative is to issue a consistent warning (or error) that simply says to remove the pragma directive and use lang instead.

<blockquote>...

* to hold the syntax rules of HTTP (which permits multiple language tags) as the conforming ones (rather than those of lang, which forbids multiple languages), will have the effect of underlining that lang and Content-Language have different purposes. For instance, since the fallback algorithm doesn’t kick in whenever multiple languages are used in the pragma or on the server, there would not be any warning in these cases. </blockquote>

The syntax requirements for the HTTP Content-Type header are not affected by the HTML implementation requirements. Since the lang attribute on the root element and the Content-Language pragma directive with a single language value do have the same effect, which differs significantly from the purpose of the HTTP Content-Language header, and it is misleading to pretend otherwise, the syntax of the former does not need to match the syntax of the latter.

<blockquote>...

* a carrot: what we want from authors is that they rely on lang (and xml:lang) for specifying the language — when the author does that, he/she should get immediate reward in the form of removal of conformance warning.</blockquote>

This rationale fails to explain why that same effect of encouraging authors to use the lang attribute, would not be achieved by a more consistent warning that states to use the lang attribute and remove the pragma directive. There is no benefit gained by leaving the directive in, and merely silencing the validator by inserting a lang attribute does little to discourage the use of the redundant and totally unnecessary pragma directive.

===Arguments Against the Proposal Details===

The change proposal suggests replacing the terminology for "pragma-set default language" with "pragma-set locale language". None of the given rationale explains the need for this change in terminology.

The proposed specification text states:

<blockquote>This pragma contains a Content-Language list, whose semantics and syntax is defined in the HTTP spec.</blockquote>

The semantics of the Content-Language header field as defined in RFC 2616 states:

<blockquote>The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.</blockquote>

This semantic definition does not match the actual purpose of the Content-Language pragma directive, for specifying a "pragma-set locale language". Therefore, referring to RFC 2616 for this semantic definition is inappropriate. The syntax requirements from RFC 2616 are also inappropriate, as it defines the following ABNF, which is not directly compatible with the syntax of the meta element with http-equiv and content attributes.

<pre>Content-Language = "Content-Language" ":" 1#language-tag
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA</pre>

For these syntax requirements to be applicable at all, the specification would have to state that the value of the content attribute must match the ABNF production for language-tag. However, see below regarding the syntax defined in BCP 47.

The proposed text then states:

<blockquote>An HTML5 parser processes this list into a known or unknown pragma-set locale language... The Content-Language list may also be defined in a HTTP header, and will then result in a known or unknown HTTP header-set locale language.</blockquote>

The proposed text fails to define what "known or unknown" means in that context. It is not clear how the implementation determines whether a value is known or unknown.

The parsing requirements for the value of this pragma directive are not specified by the change proposal. However, the change proposal also does not state that the existing parsing requirements in the specification are to be removed, replaced or modified in any way. Thus, by adopting the details of this change proposal, the specification would be left in an inconsistent state which says that multiple language values are supported, but where the parsing requirements abort when more than one value is used.

The aforementioned parsing requirements only focus on parsing the value of the pragma directive, and as such, there is no implementation requirement that sets the "HTTP header-set locale language".

<blockquote>When a document is lacking a language declaration in the form of the lang or xml:lang attribute on the root element, the document’s locale language (pragma-set or HTTP-set) is consulted by the user agent and used as fallback value for the primary document language.</blockquote>

Assuming the value of the "HTTP header-set locale language" comes from the HTTP Content-Language header, this proposed text fails to specify the order of precedence of the values specified in the pragma directive or the HTTP header.

The use of the term "locale language" in this context clashes with the existing use of the term in the specification to refer to the language set by the user in the user agent's preferences. This term is used in the table within step 7 of the algorithm to determine the character encoding.

The proposed text then goes on to state:

<blockquote>The following info about the HTTP semantics and Content-Language usage, is informative: </blockquote>

However, in the non-normative list given following that statement, RFC 2119 terminology is incorrectly used to describe what appear to be authoring requirements. In particular:

<blockquote>... authors should not define the Content-Language list according to its parser effect, but according to it semantics.</blockquote>

This non-normative example text also incorrectly states that "en-US" would not be parsed into a useful value. However, this value complies with the syntax requirements specified in RFC 2616, BCP 47 and also with the existing parsing requirements in the HTML5 specification.

The proposal states that the following reqiurement is to be removed:

<blockquote>Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead.</blockquote>

The rationale provided does not adequately justify the removal of this warning, and nor does it adequately justify replacing it with a more limited warning to be issued only when the pragma directive is in the absence of the lang attribute.

The proposal then states to amend this requirement as follows:

<blockquote>the content attribute must have a value consisting of a valid BCP 47 language tag, or a comma separated list of two or more BCP 47 language tags.</blockquote>

However, the proposal stated earlier that the syntax for the value was defined by RFC 2616. This requirement now conflicts with that by stating that the syntax of the content attribute's value is defined by BCP 47. This inconsistency negatively affects the quality of the specification.

The proposal states that this note is to be removed:

<blockquote>This pragma is not exactly equivalent to the HTTP Content-Language header, for instance it only supports one language.</blockquote>

The removal of this note would be misleading, because the note itself is factually correct as-is with the current specification, and with the details of this proposal, which, as stated above, leave the parsing requirements unchanged. The proposal fails to include any implementation requirements that actually permit multiple language tags to be used.

It has now been clearly demonstrated that the proposed specification text provided by this change proposal is thoroughly inadequate for its intended purpose. If the specification were to be amended as required by this change proposal, the inconsistency and lack of clarity would negatively affect the ability to read, understand and implement this specification. As such, this proposal should also be rejected on the basis that its proposal details are inadequate. However, if this working group does make the wrong decision to permit multiple language tags, then I ask that the editor be given full editorial discretion to phrase the requirements in a way that more clearly expresses the requirements, rather than being asked to accept the details of this proposal as written.

Content-Language

2010-06-28T14:24:43Z

Lachlan Hunt: /* allow multiple language tags in Content-Language */ Added arguments against the proposal details

{{stub}}

== <strong style="color:red">Open Poll Closes 2010-06-30</strong> ==
Please submit your objections to meta Content-Language in this poll (which closes <strong>very soon</strong>)

http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/

as well as adding them to this wiki page.

== Summary ==

The [[meta]] tag, specifically http-equiv Content-Language pragma, is confusing and broken and should be removed from HTML5 altogether.

See related issue: http://www.w3.org/html/wg/tracker/issues/88

== remove Content-Language ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0308

* This seems like the best option. It is preferable to remove broken features rather than keep them (even if "non-conforming") to minimize risk of continued misuse/misunderstanding and otherwise time-wasting on behalf of web designers and developers. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== keep Content-Language as non-conforming ==
http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html

* I'd still prefer complete removal of a broken feature rather than issuing warnings. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

== allow multiple language tags in Content-Language ==
http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages

* Even the "Summary" for this proposal is long and confusing. The workarounds provided in the change proposal increase web authoring complexity. Broken features should be removed, from the language and the specification, rather than asking web developers to waste time learning about broken features and how to work around them. Let's keep the spec as clean as possible. [[User:Tantek|Tantek]] 01:29, 27 June 2010 (UTC)

===Difference Between Content-Language HTTP Header and Pragma Directive===

This premise of this change proposal is that the Content-Language HTTP header field is functionally equivalent to the Content-Language pragma directive using the meta element. This premise is used to support the idea that that both should share the same syntax and client side processing requirements. However, this premise is demonstrably wrong, and thus the change proposal is unsupported by evidence and must be rejected.

In order to demonstrate the differences between the HTTP header and the pragma directive, it is necessary to analyse the purpose and functionality of each and see how they compare.

====Declaring the Language of the Intended Audience====

The HTTP Content-Language header field is used by HTTP servers to announce the language of the intended audience for a given resource representation. This and other related information exchanged between the client and server can be used for content negotiation based on language. When the server does this, it is important for this information to be included in the HTTP header where it can be seen by both the client and other intermediary servers.

The information declared within the document using the pragma directive is unsuitable for this purpose, as it will not be parsed by intermediary servers that would otherwise utilise the information for caching purposes.

====Server Configurataion====

It has been claimed that the information declared using a pragma directive within the document may be parsed by some server implementations, which subsequently process and echo the value in the Content-Language HTTP header field. Since this header field is allowed to contain multiple language values, it is claimed that this ability is limited by permitting only one language in the pragma directive. However, no evidence has been presented to demonstrate how widely used this feature is, nor why such a feature should even be defined within HTML.

This is a layering violation because information intended for server side processing, and specific implementation details thereof, should not unnecessarily affect the conformance definition of client side HTML. That is, it is out of scope for HTML, as a client side markup language, to define specific processing requirements or features to be used by servers for implementing HTTP features. There is also no inherent need for interoperability between different back end implementation details.

Defining the pragma directive in a way that is optimised for specific server implementation details would be analogous to, for example, defining an ASP specific feature within HTML for use on Microsoft IIS platforms. While server implementations are otherwise free to make any design choices, those design choices need not affect HTML conformance requirements.

====Default Document Language====

In practice, Content-Language used within the meta element in the HTML serves as client side metadata. The functionality of Content-Language in this case is restricted entirely to the purpose of specifying a fallback language, to be used in the absence of the lang attribute. This purpose differs significantly from the purpose of declaring the languages of the intended audience.

Declaring multiple languages for the document's intended audience makes sense in some cases. However, there can only be one default language. Thus, for this purpose, the functionality as defined requires that only a single language value be specified. While the HTTP Content-Language header field is also used for determining the fallback language in cases where it only has a single language value, that is not its primary purpose and is thus not a significant similarity between these two independent features.

Permitting multiple language values to be specified in the pragma directive is at odds with its implementation requirements. Thus, for the client-side meta data functionality of the pragma directive, it is not at all useful to have multiple languages specified, and so it does not make sense for multiple languages to be considered conforming.

These 3 aspects of the functionality — declaring the langauge of the intended audience, server side configuration and default document language — clearly illustrate that the premise of this change proposal — the shared functionality between the two features — is fundamentally flawed. The reality is that the in-document Content-Language pragma directive only shares its name with the HTTP header field, while its functionality is closer to that of the lang attribute. And since server side implementation details are out of scope of HTML, there is no need for the document conformance definition to permit multiple language values. The solution chosen for addressing this issue must take this into account, and thus reject this change proposal.

===Arguments Against the Rationale===

The rationale for this change proposal states:

<blockquote>"[The current specification] offers no carrot for doing the right thing. while the fallback language effect stops as soon as the author adds lang on the root element, the spec requires conformance checker to continue whining until the http-equiv="Content-Language" meta element has been removed."</blockquote>

The rationale fails to explain the benefit gained by leaving the pragma directive in the document when a lang attribute has been specified on the root element. While leaving it in the document under those circumstances is mostly harmless, it is redundant metadata that the author does not need to include in their document. Failing to offer a warning would continue to mislead the author into thinking that the pragma directive is both acceptable and useful, which it is not.

<blockquote>"That it prevents authors from legally using multiple values to replicate the language fallback effect of doing the same thing in a HTTP header — whether they want to replicate the effect of multiple tags or a single tag."</blockquote>

The language fallback effect from using multiple language tags within the value is that there is no default language. This is exactly the same effect as would be achieved by omitting the pragma directive, and so the given reason is blatantly wrong about having no way to replicate the effect of having no specified language. This rationale also fails to provide a reason for wanting to replicate this effect by copying the same syntax.

i.e. The effect of including:

<meta http-equiv="Content-Language" content="en, fr">

is <em>identical</em> to that of omitting this pragma directive entirely, and there is no reason for wanting to include the above either.

<blockquote>That it underlines the confusion that may exist today, about the nature of lang versus Content-Language, by requiring:

# different syntax rules for features that are expected to be identical (HTTP and http-equiv)
# similar syntax rules for features that are different (http-equiv and lang)
# a warning message which asks authors to “use lang instead” – as if they were juxtaposable alternatives.</blockquote>

The HTTP Content-Type header and the http-equiv pragma directive <em>are</em> different. The HTTP header is used for declaring the languages of the intended audience, the pragma directive is used for specifying a default language.

The lang attribute, on the other hand, is an alternative to the pragma directive because the pragma directive only serves to specify the language of the document when a single value is used. When multiple languages are specified in the pragma directive, there is absolutely no defined effect, and so it serves no valid purpose at all.

Therefore, the pragma directive is much closer in functionality to the lang attribute, than it is to the HTTP header, with which it shares its name.

<blockquote>Instead of the above, this change proposal propose:

* the Zero-edit proposal’s warning about using lang instead of Content-Language should be changed into a warning which informs that a fallback language measure has kicked in, and recommend that authors create a language declaration (via lang) rather than relying on the fallback feature. This warning should be shown regardless of whether the fallback comes from http-equiv or from the higher level (HTTP). Justification: Since it is a fallback feature, and with other semantics, there is no guarantee that the author has used it for the language effect.</blockquote>

From the authors perspective, the inconsistency of issuing the warning about the use of the pragma directive only when the lang attribute is absent would be confusing. The better alternative is to issue a consistent warning (or error) that simply says to remove the pragma directive and use lang instead.

<blockquote>...

* to hold the syntax rules of HTTP (which permits multiple language tags) as the conforming ones (rather than those of lang, which forbids multiple languages), will have the effect of underlining that lang and Content-Language have different purposes. For instance, since the fallback algorithm doesn’t kick in whenever multiple languages are used in the pragma or on the server, there would not be any warning in these cases. </blockquote>

The syntax requirements for the HTTP Content-Type header are not affected by the HTML implementation requirements. Since the lang attribute on the root element and the Content-Language pragma directive with a single language value do have the same effect, which differs significantly from the purpose of the HTTP Content-Language header, and it is misleading to pretend otherwise, the syntax of the former does not need to match the syntax of the latter.

<blockquote>...

* a carrot: what we want from authors is that they rely on lang (and xml:lang) for specifying the language — when the author does that, he/she should get immediate reward in the form of removal of conformance warning.</blockquote>

This rationale fails to explain why that same effect of encouraging authors to use the lang attribute, would not be achieved by a more consistent warning that states to use the lang attribute and remove the pragma directive. There is no benefit gained by leaving the directive in, and merely silencing the validator by inserting a lang attribute does little to discourage the use of the redundant and totally unnecessary pragma directive.

===Arguments Against the Proposal Details===

The change proposal suggests replacing the terminology for "pragma-set default language" with "pragma-set locale language". None of the given rationale explains the need for this change in terminology.

The proposed specification text states:

<blockquote>This pragma contains a Content-Language list, whose semantics and syntax is defined in the HTTP spec.</blockquote>

The semantics of the Content-Language header field as defined in RFC 2616 states:

<blockquote>The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.</blockquote>

This semantic definition does not match the actual purpose of the Content-Language pragma directive, for specifying a "pragma-set locale language". Therefore, referring to RFC 2616 for this semantic definition is inappropriate. The syntax requirements from RFC 2616 are also inappropriate, as it defines the following ABNF, which is not directly compatible with the syntax of the meta element with http-equiv and content attributes.

<pre>Content-Language = "Content-Language" ":" 1#language-tag
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA</pre>

For these syntax requirements to be applicable at all, the specification would have to state that the value of the content attribute must match the ABNF production for language-tag. However, see below regarding the syntax defined in BCP 47.

The proposed text then states:

<blockquote>An HTML5 parser processes this list into a known or unknown pragma-set locale language... The Content-Language list may also be defined in a HTTP header, and will then result in a known or unknown HTTP header-set locale language.</blockquote>

The proposed text fails to define what "known or unknown" means in that context. It is not clear how the implementation determines whether a value is known or unknown.

The parsing requirements for the value of this pragma directive are not specified by the change proposal. However, the change proposal also does not state that the existing parsing requirements in the specification are to be removed, replaced or modified in any way. Thus, by adopting the details of this change proposal, the specification would be left in an inconsistent state which says that multiple language values are supported, but where the parsing requirements abort when more than one value is used.

The aforementioned parsing requirements only focus on parsing the value of the pragma directive, and as such, there is no implementation requirement that sets the "HTTP header-set locale language".

<blockquote>When a document is lacking a language declaration in the form of the lang or xml:lang attribute on the root element, the document’s locale language (pragma-set or HTTP-set) is consulted by the user agent and used as fallback value for the primary document language.</blockquote>

Assuming the value of the "HTTP header-set locale language" comes from the HTTP Content-Language header, this proposed text fails to specify the order of precedence of the values specified in the pragma directive or the HTTP header.

The use of the term "locale language" in this context clashes with the existing use of the term in the specification to refer to the language set by the user in the user agent's preferences. This term is used in the table within step 7 of the algorithm to determine the character encoding.

The proposed text then goes on to state:

<blockquote>The following info about the HTTP semantics and Content-Language usage, is informative: </blockquote>

However, in the non-normative list given following that statement, RFC 2119 terminology is incorrectly used to describe what appear to be authoring requirements. In particular:

<blockquote>... authors should not define the Content-Language list according to its parser effect, but according to it semantics.</blockquote>

This non-normative example text also incorrectly states that "en-US" would not be parsed into a useful value. However, this value complies with the syntax requirements specified in RFC 2616, BCP 47 and also with the existing parsing requirements in the HTML5 specification.

The proposal states that the following reqiurement is to be removed:

<blockquote>Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead.</blockquote>

The rationale provided does not adequately justify the removal of this warning, and nor does it adequately justify replacing it with a more limited warning to be issued only when the pragma directive is in the absence of the lang attribute.

The proposal then states to amend this requirement as follows:

<blockquote>the content attribute must have a value consisting of a valid BCP 47 language tag, or a comma separated list of two or more BCP 47 language tags.</blockquote>

However, the proposal stated earlier that the syntax for the value was defined by RFC 2616. This requirement now conflicts with that by stating that the syntax of the content attribute's value is defined by BCP 47. This inconsistency negatively affects the quality of the specification.

The proposal states that this note is to be removed:

<blockquote>This pragma is not exactly equivalent to the HTTP Content-Language header, for instance it only supports one language.</blockquote>

The removal of this note would be misleading, because the note itself is factually correct as-is with the current specification, and with the details of this proposal, which, as stated above, leave the parsing requirements unchanged. The proposal fails to include any implementation requirements that actually permit multiple language tags to be used.

It has now been clearly demonstrates that the proposed specification text provided by this change proposal is thoroughly inadequate for its intended purpose. If the specification were to be amended as required by this change proposal, the inconsistency and lack of clarity would negatively affect the ability to read, understand and implement this specification. As such, this proposal should also be rejected on the basis that its proposal details are inadequate. However, if this working group does make the wrong decision to permit multiple language tags, then I ask that the editor be given full editorial discretion to phrase the requirements in a way that more clearly expresses the requirements, rather than being asked to accept the details of this proposal as written.

Content-Language

2010-06-28T12:42:50Z

Lachlan Hunt: /* allow multiple language tags in Content-Language */ Added arguments against the change proposal's rationale

Content-Language

2010-06-28T10:11:49Z

Lachlan Hunt: /* allow multiple language tags in Content-Language */ Added arguments against multiple langauges

Rationale

2010-05-05T20:56:33Z

Lachlan Hunt: /* Meter and Progress (are not the same thing) */ Revised to provide example use cases and fix formatting.

This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.

== Other Pages ==

* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]

== Specific Elements ==

=== Plaintext ===
the <plaintext> element is a obsolete precursor to the <pre> element.<sup>[1]</sup> It is is now in the HTML5 spec as a method of stopping all further html token parsing. It lacks an end tag and just emits the rest of the page as plain text. It throws a parse error upon reaching the end of the document as it is not considered a valid element (and it is missing an end-tag).
<small>
<ol>
<li>[http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt]</li>
</ol>
</small>

=== Image ===

<image> element is treated as an alternate (but invalid) name for <img>. This is because some sites (around 0.2%) make this mistake. It is already treated as an image by most major browsers.

=== Meter and Progress (are not the same thing) ===

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

The progress element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload). Progress elmements can also be in the indeterminate state, indicating that something is in progress, but it's completion progress is unknown.

The default rendering for a meter element could look something like the following:

<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element">

Whereas, the default rendering for the progress element could look like this:

<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg">

Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:

<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber">

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

Validator.nu Useful Warning Requests

2010-04-28T11:31:22Z

Lachlan Hunt: /* Polyglot Document Checking */ Updated character encoding information

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a given, conforming HTML document is a polyglot document. This does not list all issues that would need to be checked to ensure that a given, conforming XHTML document is a polyglot document, however. As such, syntactic XML constructs which are not valid in HTML are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. For HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! The <code>xml:lang</code> attribute
| Meaningless talisman in HTML.
| In DOM implementations for XHTML, <code>xml:lang</code> represents the lang attribute in the XML namespace. For HTML, it represents an attribute in no namespace with the literal localname "xml:lang". This issue is '''unavoidable'''.
|
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is effectively dependent upon the end-user's locale (Windows-1252 for most Western locales). For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using either: <code><meta charset="UTF-8"></code>, ensure the encoding is declared in the transport layer (HTTP Content-Type header), or use UTF-8 or UTF-16 with an appropriate Byte Order Mark.
| XHTML-compatible
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! Unescaped Special Chars
| Unescaped ampersand (<code>&</code>) or less-than (<code><</code>) characters are not allowed in text and attribute values, within XHTML. (This doesn't include within CDATA sections, comments, etc.)
| HTML can include unescaped ampersands where they are unambiguous, and unescaped less than characters within rawtext or RCDATA content, and quoted attributes.
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>script</code> and <code>style</code> Elements
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! The <code>textarea</code> and <code>title</code> Elements
| The content model of these elements is RCDATA in HTML, but PCDATA in XHTML. These elements may not contain escaping text spans (<code></code>, because they look like comments), or unescaped ampersands or less than characters.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

FAQ

2010-02-04T00:23:22Z

Lachlan Hunt: /* HTML5 should support href on any element! */ Fixed more markup

== The WHATWG ==

=== What is the WHATWG? ===

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.

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.

=== What is the WHATWG working on? ===

The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

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.

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).

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 the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* 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 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.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.

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.

Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec.

* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.

* You may use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking tool]. The tool provides an online interface for selecting and comparing revisions of the spec.

* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html

* 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

* Non-editorial changes get broadcast on the WHATWG Twitter feed: http://twitter.com/WHATWG

* All changes that affect the W3C copy of the spec get broadcast on the HTML5 Twitter feed: http://twitter.com/HTML5

* The latest changes are visible in coloured diff form: http://whatwg.org/specs/web-apps/current-work/index-diff

=== What are the various versions of the spec? ===

All active work at WHATWG is gathered in the (very large) [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] document.

WHATWG HTML is a subset containing only the HTML-specific material. It is available as [http://www.whatwg.org/specs/web-apps/current-work/ single-page]
and '''[http://whatwg.org/html multi-page]''', as well as in PDF [http://www.whatwg.org/specs/web-apps/current-work/html5-a4.pdf A4] and
[http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf Letter].

The following table lists in the individual specifications included:

{| class="wikitable" border=1 cellpadding=3 cellspacing=0
|-
!
! WHATWG Specifications <br> (and sections therein)
! Section links for <br> Web Applications 1.0
! W3C/IETF Specifications
|-
! HTML5 only (excluding newer features)
|
|
| [http://dev.w3.org/html5/spec/Overview.html Single-page], [http://dev.w3.org/html5/spec/spec.html Multi-page] (HTMLWG)
|-
! Microdata
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#microdata Microdata]
| [http://dev.w3.org/html5/md/Overview.html Microdata] (HTMLWG)
|-
! 2D Context
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-2d-context In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-2d-context 2D Context]
| [http://dev.w3.org/html5/2dcontext/Overview.html 2D Context] (HTMLWG)
|-
! Communications - Cross-document messaging
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#crossDocumentMessages Cross-document messaging]
| [http://dev.w3.org/html5/postmsg/Overview.html#crossDocumentMessages Communications] (HTMLWG)
|-
! Communications - Channel messaging
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#channel-messaging Channel messaging]
| [http://dev.w3.org/html5/postmsg/Overview.html#channel-messaging Communications] (HTMLWG)
|-
! Device Element
| [http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices In WHATWG HTML]
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices Device]
| [http://dev.w3.org/html5/html-device/ HTML Device] (HTMLWG)
|-
! Web Workers
| [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers specification]
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#workers Web Workers]
| [http://dev.w3.org/html5/workers/Overview.html Web Workers] (WebApps WG)
|-
! Web Storage
|
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#webstorage Web Storage]
| [http://dev.w3.org/html5/webstorage/ Web Storage] (WebApps WG)
|-
! Web Sockets API
|
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#network Web Sockets API]
| [http://dev.w3.org/html5/websockets/ Web Sockets API] (WebApps WG)
|-
! Web Sockets Protocol
|
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#websocket-protocol Web Sockets Protocol]
| [http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol The Web Socket Protocol] (IETF)
|-
! Server-Sent Events
|
| [http://www.whatwg.org/specs/web-apps/current-work/complete.html#server-sent-events Server-sent Events]
| [http://dev.w3.org/html5/eventsource/ Server-sent Events] (WebApps WG)
|-
! Web SQL Database (stalled)
|
|
| [http://dev.w3.org/html5/webdatabase/ Web SQL Database] (WebApps WG)
|}

All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].

=== Are there versions of the specification aimed specifically at authors/implementors? ===

There are no standalone author or implementor specifications. However, the WHATWG HTML and the HTML5 specifications (and their multipage versions) can be customized to either hide or emphasize user-agent-specific material. The mode can be selected using radio buttons at the top right of those documents.

It is also possible to toggle the mode by changing the URL, here is an example for the multipage WHATWG HTML specification:

* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete
* Author view (hiding the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author
* Implementor view (highlighting the user-agent-specific material): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites that might help you work out what you can use in the meantime:

* http://diveintohtml5.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, them remove them!

=== When will HTML5 be finished? ===

"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''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.
* ''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.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’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.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’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.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

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’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

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.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]]—or another ''mini-header'' element.

Also see HTML5 feature proposals below.

== HTML5 syntax issues ==

=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? ===

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]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

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.

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.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

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><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

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:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# 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.)
# 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].

=== How are pre-HTML5 documents parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML5 validator].

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

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.

=== What is an XML (or XHTML) Serialization? ===

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 “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML5 use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.

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.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

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><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.

HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’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’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]].

=== Will there be support for namespaces in HTML? ===

HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

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.

In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

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:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* 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.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* 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.

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.

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".

To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

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

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.

<?xml version="1.0" encoding="UTF-8"?>

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>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

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.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does HTML5 legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

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.

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.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

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.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

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.

== HTML5 feature proposals ==

=== HTML5 should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’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.

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.

Wrapping <a> 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:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML5 should support list headers! ===

You can give a header to a list using the <figure> and <legend> elements:

<pre>
<figure>
<legend>Apples</legend>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML5 should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* 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.
* 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.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* 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.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* 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.
* 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.)

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.

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.

=== HTML5 should group <dt>s and <dd>s together in <di>s! ===

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.

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

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.

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.

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.

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.

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.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

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.

==== But they are PRESENTATIONAL! ====

While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements. The problem with elements like <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).

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <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.

So, we can't really decide what the element should be based on past practice, like we usually do.

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 <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.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

<strong>Note:</strong> research and opinions are being gathered that support the use of the <cite> element to markup the names of speakers (e.g. for quotations). Please contribute yours:
* [[Cite_element#examples_in_the_wild|cite element: examples in the wild of speakers marked up with cite]]
* [[Cite_element#opinions|cite element: opinions on use of cite to markup names of speakers]]

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
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.

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Web Workers ==

Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.

== Mailing List ==

=== Should I top-post or reply inline? ===

Please reply inline or make the reply self-contained.

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.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

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.
H

FAQ

2010-02-04T00:22:26Z

Lachlan Hunt: /* HTML5 should support href on any element! */ Fixed markup

Change Proposal: figure and details

2010-01-12T00:03:16Z

Lachlan Hunt: /* Impact */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 (<code><figure><legend>...</legend>...</figure>; <details><legend>...</legend>...</details></code>) ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 (<code><figure><c>...</c>...</figure>; <details><c>...</c>...</details></code>) ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code>) ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

The caption attribute is good for figure, but not details. However, that proposal retains the dt/dd names for details. And those names remain clunky and non-obvious in the context of details (hard to remember which is which) and retain all of the general problems of using dt/dd for both elements.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

==== Does Not Introduce Redundant Elements for the Content ====

Semantically, and for purposes of UA behavior, we only really need to distinguish the caption part of the element. There is no need to wrap the remaining body part with a special element. True, they can be handy as a styling hook, but authors who need that styling hook can always use <div>.

=== Proposal Details ===

This proposal includes the following specific changes:

1) Define a new element fcaption. Details would be approximately as follows:

Categories: none
Contexts in which the element may be used: As the first or last child of a figure element.
Content model: flow content
Content attributes: global attributes
DOM interface: HTMLElement
Semantics: The fcaption element represents the caption of the figure that is its parent, if it has a parent that is a figure element.

2) Define a new element dlabel. Details would be as above, but replacing mentions of "figure" with "details".

3) Change figure as follows:
New content model: "Flow content, optionally either preceded by or followed by an fcaption element."
New caption definition: "The first fcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child fcaption element, then there is no caption."
New content definition: "All child elements other than the first fcaption element, if there are any, represent the element's contents. If there are no child elements besides the first fcaption, then there are no contents.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

4) Change details as follows:
New content model: "One dlabel element, followed by Flow content."
New summary definition: "The first dlabel element child of the element, if any, represents the summary of the details. If there is no child dlabel element, the user agent should provide its own label (e.g. "Details")."
New details definition: "All child elements other than the first dlabel element, if there are any, represent the details. If there are no child elements besides the first dlabel, then there are no details.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

=== Impact ===

This proposal would have a potential negative impact on authors: it would introduce two new elements relative to the current spec.

However, the positive impact is arguably greater. The new elements would be more readable, more intuitive, and more in line with the standard HTML design pattern for structured elements. Thus, despite the addition of more elements, the overall increase in cognitive load will be less. In addition, there is no need to use <div> or any other wonky workarounds to get it to work in legacy UAs.

The impact on implementations is trivial. fcaption and dlabel are trivial to implement, and the appearance and behavior can be mostly defined via stylesheet. This is not significantly more work than altering the rendering of dt and dd inside figure and details; in fact it may be less work in some implementations.

The impact on conformance checkers and authoring tools is also trivial; neither approach is easier or harder to validate or generate.

There is no direct impact on users either way.

== Proposal 3b (<code><figure><figcaption>...</figcaption>...</figure>; <details><dsummary>...</dsummary>...</details></code>) ==
Same as proposal 3, but with the element names "figcaption" and "dsummary" respectively.

Reasoning: "figcaption" is more memorable. "dsummary" more accurately describes what the "label" of a <details> element is.

== Proposal 4 (<code><figure><caption>...</caption>...</figure>; <details><label>...</label>...</details></code>) ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

CON: "caption" has significant unsolved parsing problems.

CON: "label" use in <details> would prevent the summary of a <details> from containing a labeled <progress> element, which is common, and would make the content model ambiguous (since the contents of a <details> can itself contain labels).

== Proposal 5 (<code><figure><h1>...</h1>...</figure>; <details><h1>...</h1>...</details></code>) ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

CON: Styling issues in legacy UAs.

CON: Content model would be ambiguous.

== Proposal 6 (<code><figure><p caption>...</p>...</figure></code>)==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

== Proposal 7 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code> or <code><figure><fcaption>...</fcaption><fbody>...</fbody></figure>; <details><dlabel>...</dlabel><dbody>...</dbody></details></code>) ==

=== Summary ===

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details to replace dt. In addition, it proposes an optional fbody element for use inside figure, and an optional dbody element for use inside details, to mark up the content/body and replace dd.

FAQ

2010-01-09T09:13:52Z

Lachlan Hunt: /* What are the various versions of the spec? */ Marked multi-page Next-gen HTML as having different views

== The WHATWG ==

=== What is the WHATWG? ===

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.

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.

=== What is the WHATWG working on? ===

The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

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.

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).

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 the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* 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 browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential of fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.

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.

Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec.

* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.

* You may use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking tool]. The tool provides an online interface for selecting and comparing revisions of the spec.

* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html

* 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

* Non-editorial changes get broadcast on the WHATWG Twitter feed: http://twitter.com/WHATWG

* All changes that affect the W3C copy of the spec get broadcast on the HTML5 Twitter feed: http://twitter.com/HTML5

* The latest changes are visible in coloured diff form: http://whatwg.org/specs/web-apps/current-work/index-diff

=== What are the various versions of the spec? ===

The specs that the WHATWG works on are available in a variety of forms.

{| class="wikitable" border="1"
|-
!
!WHATWG
!WHATWG Web Applications
!W3C/IETF
|-
!Next-generation HTML (including HTML5)
|[http://www.whatwg.org/specs/web-apps/current-work/ Single-page]*, '''[http://whatwg.org/html Multi-page]'''*, [http://www.whatwg.org/specs/web-apps/current-work/html5-a4.pdf A4 (PDF)], [http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf Letter (PDF)]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0 (complete)]
|
|-
!HTML5
|
|
|[http://dev.w3.org/html5/spec/Overview.html Single-page]*, [http://dev.w3.org/html5/spec/spec.html Multi-page]
|-
!Microdata
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata Microdata multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#microdata Microdata section]
|[http://dev.w3.org/html5/md/Overview.html md]
|-
!2D Context
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-2d-context The 2D context multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-2d-context 2D Context section]
|[http://dev.w3.org/html5/2dcontext/Overview.html 2dcontext]
|-
!Communications
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging multi-page segment] and [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging Channel messaging multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#crossDocumentMessages Cross-document messaging section] and [http://www.whatwg.org/specs/web-apps/current-work/complete.html#channel-messaging Channel messaging section]
|[http://dev.w3.org/html5/postmsg/Overview.html Communications]
|-
!Device Element
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices The device element multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices The device element section]
|[http://dev.w3.org/html5/html-device/ HTML Device]
|-
!Web Workers
|[http://whatwg.org/ww Web Workers]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#workers Web Workers section]
|[http://dev.w3.org/html5/workers/Overview.html Web Workers]
|-
!Web Storage
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#webstorage Web Storage section]
|[http://dev.w3.org/html5/webstorage/ Web Storage]
|-
!Web Sockets API
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#network Web Sockets section]
|[http://dev.w3.org/html5/websockets/ Web Sockets API]
|-
!Web Sockets Protocol
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#websocket-protocol Web Socket Protocol section]
|[http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol The Web Socket Protocol] (IETF)
|-
!Server-Sent Events
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#server-sent-events Sever-sent Events section]
|[http://dev.w3.org/html5/eventsource/ Server-sent Events]
|-
!Web SQL Database (stalled)
|
|
|[http://dev.w3.org/html5/webdatabase/ Web SQL Database]
|-
|}

All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].

(*) Several of the specs above, marked with an asterisk, can further be viewed in three different ways, by toggling the radio buttons at the top right of those documents. Here are some shortcuts for viewing the multipage version of the HTML specification in these three different ways:
* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete
* Hiding all the user-agent-specific material ("author view"): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author
* Highlighting all the user-agent-specific material: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites that might help you work out what you can use in the meantime:

* http://diveintohtml5.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, them remove them!

=== When will HTML5 be finished? ===

"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''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.
* ''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.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’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.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’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.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

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’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

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.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]]—or another ''mini-header'' element.

Also see HTML5 feature proposals below.

== HTML5 syntax issues ==

=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? ===

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]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

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.

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.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

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><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

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:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# 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.)
# 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].

=== How are pre-HTML5 documents parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML5 validator].

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

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.

=== What is an XML (or XHTML) Serialization? ===

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 “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML5 use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.

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.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

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><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.

HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’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’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]].

=== Will there be support for namespaces in HTML? ===

HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

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.

In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

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:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* 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.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* 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.

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.

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".

To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

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

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.

<?xml version="1.0" encoding="UTF-8"?>

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>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

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.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does HTML5 legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

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.

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.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

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.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

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.

== HTML5 feature proposals ==

=== HTML5 should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’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.

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.

Wrapping <a> 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:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML5 should support list headers! ===

You can give a header to a list using the <figure> and <legend> elements:

<pre>
<figure>
<legend>Apples</legend>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML5 should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* 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.
* 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.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* 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.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* 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.
* 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.)

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.

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.

=== HTML5 should group <dt>s and <dd>s together in <di>s! ===

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.

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

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.

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.

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.

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.

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.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

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.

==== But they are PRESENTATIONAL! ====

While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements. The problem with elements like <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).

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <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.

So, we can't really decide what the element should be based on past practice, like we usually do.

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 <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.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

<strong>Note:</strong> research and opinions are being gathered that support the use of the <cite> element to markup the names of speakers (e.g. for quotations). Please contribute yours:
* [[Cite_element#examples_in_the_wild|cite element: examples in the wild of speakers marked up with cite]]
* [[Cite_element#opinions|cite element: opinions on use of cite to markup names of speakers]]

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
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.

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Web Workers ==

Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.

== Mailing List ==

=== Should I top-post or reply inline? ===

Please reply inline or make the reply self-contained.

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.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

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.
H

Change Proposal: figure and details

2010-01-08T15:02:40Z

Lachlan Hunt: Added rationale against dt/dd elements and added placeholders for various proposals

FAQ

2010-01-08T12:09:59Z

Lachlan Hunt: /* What are the various versions of the spec? */ Reformatted into a table.

== The WHATWG ==

=== What is the WHATWG? ===

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.

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.

=== What is the WHATWG working on? ===

The WHATWG's main focus is HTML5. The WHATWG also works on Web Workers and occasionally specifications outside WHATWG space are discussed on the WHATWG mailing list and forwarded when appropriate.

In the past it has worked on Web Forms 2.0 and Web Controls 1.0. Web Forms 2.0 has been integrated into HTML5 and Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== The WHATWG Process ==

=== How does the WHATWG work? ===

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.

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).

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 the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [http://whatwg.org/mailing-list#specs join the mailing list] first), or ian@hixie.ch. All feedback will receive a reply in due course.

If you want feedback to be dealt with faster than "eventually", e.g. because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editor know by either e-mailing him (ian@hixie.ch), or contacting him on [[IRC]] (Hixie on Freenode). Requests for priority feedback handling are handled confidentially so other implementors won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* 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 browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential of fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:
# Research the use cases and requirements by discussing the issue with authors and implementors.
# Come up with a clear description of the problem that needs to be solved.
# Discuss your proposal with authors and implementors. Read the responses. Listen to the feedback. Consider whether your ideas are good solutions to the use cases and requirements put forward. Discussions here should be done in public, e.g. on an archived public mailing list or documented in blogs.
# Get implementors to commit to implementing the feature. If you can't get several implementors to implement the feature, then get at least one user agent to implement it experimentally. Experimental implementations should be publicly available.
# Bring the experimental implementations to the attention of the spec's editor. Document the experience found from any implementations, the use cases and requirements that were found in the first step, the data that the design was based on.
# Demonstrate the importance of the problem. Demonstrate that the solution is one that will be used correctly and widely enough for it to solve the stated problem.
# Participate in the subsequent design discussions, considering all the proposals carefully. Typically at this step the original design gets thrown out and a significantly better design is developed, informed by the previous research, new research, and implementation and author experience with experimental implementations. Sometimes, the idea is abandoned at this stage.

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.

Writing a comprehensive test suite is also an important step, which should start a bit before implementations start being written to the spec. (Test suites usually find as many problems with implementations as they do with the spec; they aren't just for finding browser bugs.) We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

== HTML5 ==

=== What is HTML5? ===

[http://www.whatwg.org/specs/web-apps/current-work/ HTML5] is the main focus of the WHATWG community and also that of the W3C HTML Working Group. HTML5 is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec.

* The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed.

* You may use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracking tool]. The tool provides an online interface for selecting and comparing revisions of the spec.

* There is a commit-watchers mailing list that is notified of every edit: http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org

* The W3C provide a Web view of their CVS mirror of the HTML5 spec: http://dev.w3.org/cvsweb/html5/spec/Overview.html

* 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

* Non-editorial changes get broadcast on the WHATWG Twitter feed: http://twitter.com/WHATWG

* All changes that affect the W3C copy of the spec get broadcast on the HTML5 Twitter feed: http://twitter.com/HTML5

* The latest changes are visible in coloured diff form: http://whatwg.org/specs/web-apps/current-work/index-diff

=== What are the various versions of the spec? ===

The specs that the WHATWG works on are available in a variety of forms.

{| class="wikitable" border="1"
|-
!
!W3C HTML WG
!WHATWG
!WHATWG Web Applications
|-
!HTML5
|[http://dev.w3.org/html5/spec/Overview.html Single-page]*, [http://dev.w3.org/html5/spec/spec.html Multi-page]
|[http://www.whatwg.org/specs/web-apps/html5/ Single-page]*
|
|-
!HTML (Incl. HTML5)
|
|[http://www.whatwg.org/specs/web-apps/current-work/ Single-page]*, '''[http://whatwg.org/html Multi-page]''', [http://www.whatwg.org/specs/web-apps/current-work/html5-a4.pdf A4 (PDF)], [http://www.whatwg.org/specs/web-apps/current-work/html5-letter.pdf Letter (PDF)]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0 (complete)]
|-
!Microdata
|[http://dev.w3.org/html5/md/Overview.html md]
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata Microdata multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#microdata Microdata section]
|-
!2D Context
|[http://dev.w3.org/html5/2dcontext/Overview.html 2dcontext]
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-2d-context The 2D context multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-2d-context 2D Context section]
|-
!Communications
|[http://dev.w3.org/html5/postmsg/Overview.html postmsg]
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages Cross-document messaging multi-page segment] and [http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging Channel messaging multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#crossDocumentMessages Cross-document messaging section] and [http://www.whatwg.org/specs/web-apps/current-work/complete.html#channel-messaging Channel messaging section]
|-
!Device Element
|[http://dev.w3.org/html5/html-device/ html-device]
|[http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices The device element multi-page segment]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#devices The device element section]
|-
!Web Workers
|[http://dev.w3.org/html5/workers/Overview.html workers]
|[http://whatwg.org/ww Web Workers]
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#workers Web Workers section]
|-
!Web Storage
|[http://dev.w3.org/html5/webstorage/ webstorage]
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#webstorage Web Storage section]
|-
!Web Sockets API
|[http://dev.w3.org/html5/websockets/ websockets]
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#network Web Sockets section]
|-
!Web Sockets Protocol
|[http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol draft-hixie-thewebsocketprotocol] (IETF)
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#websocket-protocol Web Socket Protocol section]
|-
!Server-Sent Events
|[http://dev.w3.org/html5/eventsource/ eventsource]
|
|[http://www.whatwg.org/specs/web-apps/current-work/complete.html#server-sent-events Sever-sent Events section]
|-
!Web SQL Database
|[http://dev.w3.org/html5/webdatabase/ webdatabase] (deprecated)
|
|(excluded)
|-
|}

All of the above are generated from one [http://www.whatwg.org/specs/web-apps/current-work/source source document].

(*) Several of the specs above, marked with an asterisk, can further be viewed in three different ways, by toggling the radio buttons at the top right of those documents. Here are some shortcuts for viewing the multipage version of the HTML specification in these three different ways:
* As a normal spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=complete
* Hiding all the user-agent-specific material ("author view"): http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author
* Highlighting all the user-agent-specific material: http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites that might help you work out what you can use in the meantime:

* http://diveintohtml5.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, them remove them!

=== When will HTML5 be finished? ===

"Finished" is a big deal... You'll be able to use HTML5 long before then. See [[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''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.
* ''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.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’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.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’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.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

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’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, that same timetable gave a date for First Public Working Draft that was eight months premature, and the W3C, as of the predicted date for the third milestone, Candidate Recommendation, had still not come anywhere near reaching the second milestone, Last Call. You can make your own judgements regarding the W3C timetable's credibility.)

=== What about Microsoft and Internet Explorer? ===

Microsoft has already started implementing parts of HTML5 in IE8.

HTML5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

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.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]]—or another ''mini-header'' element.

Also see HTML5 feature proposals below.

== HTML5 syntax issues ==

=== Will HTML5 finally put an end to the XHTML as <code>text/html</code> debate? ===

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]]''

=== What will the DOCTYPE be? ===

In HTML:

<code><!DOCTYPE html></code>

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.

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.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

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><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

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:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# 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.)
# 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].

=== How are pre-HTML5 documents parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by HTML5. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax of HTML5 therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed using the HTML5 parser.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [http://validator.whatwg.org/ HTML5 validator].

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

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.

=== What is an XML (or XHTML) Serialization? ===

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 “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML5 use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML1, XHTML5 ''must not'' be served as <code>text/html</code>.

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.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

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><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 to HTML5.

HTML5 also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serializations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’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’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]].

=== Will there be support for namespaces in HTML? ===

HTML5 is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

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.

In conclusion, while HTML5 does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

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:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* 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.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* 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.

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.

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".

To ease transition from HTML4 to HTML5, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

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

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.

<?xml version="1.0" encoding="UTF-8"?>

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>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

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.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does HTML5 legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

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.

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.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

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.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

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.

== HTML5 feature proposals ==

=== HTML5 should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5. The main reason this isn't in HTML5 is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’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.

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.

Wrapping <a> 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:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML5 should support list headers! ===

You can give a header to a list using the <figure> and <legend> elements:

<pre>
<figure>
<legend>Apples</legend>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML5 should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* 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.
* 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.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* 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.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* 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.
* 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.)

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.

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.

=== HTML5 should group <dt>s and <dd>s together in <di>s! ===

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.

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

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.

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.

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.

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.

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.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

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.

==== But they are PRESENTATIONAL! ====

While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements. The problem with elements like <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).

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <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.

So, we can't really decide what the element should be based on past practice, like we usually do.

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 <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.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

<strong>Note:</strong> research and opinions are being gathered that support the use of the <cite> element to markup the names of speakers (e.g. for quotations). Please contribute yours:
* [[Cite_element#examples_in_the_wild|cite element: examples in the wild of speakers marked up with cite]]
* [[Cite_element#opinions|cite element: opinions on use of cite to markup names of speakers]]

=== The <time> element should allow vague times ("March") and times from ancient history to be marked up ===

This has been discussed a number of times. For an overview of the topic, please see these e-mails:
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html
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.

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#history0 The history section in HTML5 itself]

== Web Workers ==

Besides HTML5 the WHATWG works on [http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]. It does this together with the W3C WebApps Working Group.

== Mailing List ==

=== Should I top-post or reply inline? ===

Please reply inline or make the reply self-contained.

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.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your e-mail backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post e-mails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

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.
H

HTML vs. XHTML

2009-09-08T17:44:33Z

Lachlan Hunt:

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFEEEE; padding: .5em 1em;"><strong>This page is currently being revised. Some information is incomplete or missing.</strong></p>

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
!Parsing Modes
|Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
|XML parsing rules are used. There is only one mode.
|The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
!Error Handling
|HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
|Well-formedness errors are fatal
|
|-
!Namespaces
|Elements and attributes for known vocabularies (HTML, SVG and MathML) are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
|The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
!Namespace attributes on HTML elements
|Elements in the HTML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xhtml"</code>. The 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 no namespace.

Attributes of the form <code>xmlns:<var>prefix</var></code> may not be used on HTML elements.
|The HTML namespace must be declared for HTML elements according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!Namespace attributes on foreign elements
|
Elements in the SVG namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/2000/svg"</code>. The attribute is optional because the namespace is implied during parsing.

Elements in the MathML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1998/Math/MathML"</code>. The attribute is optional because the namespace is implied during parsing.

Foreign elements may also have an <code>xmlns:xlink</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xlink"</code>. This attribute is optional, even if XLink attributes are used, because the namespaces for XLink attributes is implied during parsing.

When parsed by an HTML parser, the <code>xmlns</code> and <code>xmlns:xlink</code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|The SVG and MathML namespaces must be declared for SVG and MathML elements, respectively, according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!XLink attributes
|Foreign elements may use the attributes <code>xlink:actuate</code>, <code>xlink:arcrole</code>, <code>xlink:href</code>, <code>xlink:role</code>, <code>xlink:show</code>, <code>xlink:title</code> and <code>xlink:type</code>. These attributes are placed in the <code>"http://www.w3.org/1999/xlink"</code>. The prefix used must be "<code>xlink</code>".
|XLink attributes may be specified on foreign elements using any prefix, subject to the conformance rules defined by ''Namespaces in XML''. The XLink namespace must be declared according to the conformance rules defined by ''Namespaces in XML'' if XLink attributes are used within the document.
|
|-
!XML attributes
|
Foreign elements may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".

HTML elements may use the <code>xml:lang</code> attribute. The attribute in no namespace with no prefix and with the literal localname "<code>xml:lang</code>" has no effect on language processing. HTML elements must not use the <code>xml:base</code> or <code>xml:space</code> attributes.
| Any element, including HTML elements, may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".
|
|-
!Space characters
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000C FORM FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|-
!CDATA sections
|
|
|
|-
!Processing Instructions
|
|
|
|-
!Character References
|
|
|
|-
!Entity References
|
|
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-06T22:41:39Z

Lachlan Hunt: /* Syntax and Parsing */ Added placeholder rows for some things

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
!Parsing Modes
|Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
|XML parsing rules are used. There is only one mode.
|The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
!Error Handling
|HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
|Well-formedness errors are fatal
|
|-
!Namespaces
|Elements and attributes for known vocabularies (HTML, SVG and MathML) are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
|The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
!Namespace attributes on HTML elements
|Elements in the HTML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xhtml"</code>. The 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 no namespace.

Attributes of the form <code>xmlns:<var>prefix</var></code> may not be used on HTML elements.
|The HTML namespace must be declared for HTML elements according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!Namespace attributes on foreign elements
|
Elements in the SVG namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/2000/svg"</code>. The attribute is optional because the namespace is implied during parsing.

Elements in the MathML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1998/Math/MathML"</code>. The attribute is optional because the namespace is implied during parsing.

Foreign elements may also have an <code>xmlns:xlink</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xlink"</code>. This attribute is optional, even if XLink attributes are used, because the namespaces for XLink attributes is implied during parsing.

When parsed by an HTML parser, the <code>xmlns</code> and <code>xmlns:xlink</code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|The SVG and MathML namespaces must be declared for SVG and MathML elements, respectively, according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!XLink attributes
|Foreign elements may use the attributes <code>xlink:actuate</code>, <code>xlink:arcrole</code>, <code>xlink:href</code>, <code>xlink:role</code>, <code>xlink:show</code>, <code>xlink:title</code> and <code>xlink:type</code>. These attributes are placed in the <code>"http://www.w3.org/1999/xlink"</code>. The prefix used must be "<code>xlink</code>".
|XLink attributes may be specified on foreign elements using any prefix, subject to the conformance rules defined by ''Namespaces in XML''. The XLink namespace must be declared according to the conformance rules defined by ''Namespaces in XML'' if XLink attributes are used within the document.
|
|-
!XML attributes
|
Foreign elements may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".

HTML elements may use the <code>xml:lang</code> attribute. The attribute in no namespace with no prefix and with the literal localname "<code>xml:lang</code>" has no effect on language processing. HTML elements must not use the <code>xml:base</code> or <code>xml:space</code> attributes.
| Any element, including HTML elements, may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".
|
|-
!Space characters
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000C FORM FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|-
!CDATA sections
|
|
|
|-
!Processing Instructions
|
|
|
|-
!Character References
|
|
|
|-
!Entity References
|
|
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-06T21:02:28Z

Lachlan Hunt: /* Syntax and Parsing */

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
!Parsing Modes
|Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
|XML parsing rules are used. There is only one mode.
|The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
!Error Handling
|HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
|Well-formedness errors are fatal
|
|-
!Namespaces
|Elements and attributes for known vocabularies (HTML, SVG and MathML) are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
|The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
!Namespace attributes on HTML elements
|Elements in the HTML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xhtml"</code>. The 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 no namespace.

Attributes of the form <code>xmlns:<var>prefix</var></code> may not be used on HTML elements.
|The HTML namespace must be declared for HTML elements according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!Namespace attributes on foreign elements
|
Elements in the SVG namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/2000/svg"</code>. The attribute is optional because the namespace is implied during parsing.

Elements in the MathML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1998/Math/MathML"</code>. The attribute is optional because the namespace is implied during parsing.

Foreign elements may also have an <code>xmlns:xlink</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xlink"</code>. This attribute is optional, even if XLink attributes are used, because the namespaces for XLink attributes is implied during parsing.

When parsed by an HTML parser, the <code>xmlns</code> and <code>xmlns:xlink</code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|The SVG and MathML namespaces must be declared for SVG and MathML elements, respectively, according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!XLink attributes
|Foreign elements may use the attributes <code>xlink:actuate</code>, <code>xlink:arcrole</code>, <code>xlink:href</code>, <code>xlink:role</code>, <code>xlink:show</code>, <code>xlink:title</code> and <code>xlink:type</code>. These attributes are placed in the <code>"http://www.w3.org/1999/xlink"</code>. The prefix used must be "<code>xlink</code>".
|XLink attributes may be specified on foreign elements using any prefix, subject to the conformance rules defined by ''Namespaces in XML''. The XLink namespace must be declared according to the conformance rules defined by ''Namespaces in XML'' if XLink attributes are used within the document.
|
|-
!XML attributes
|
Foreign elements may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".

HTML elements may use the <code>xml:lang</code> attribute. The attribute in no namespace with no prefix and with the literal localname "<code>xml:lang</code>" has no effect on language processing. HTML elements must not use the <code>xml:base</code> or <code>xml:space</code> attributes.
| Any element, including HTML elements, may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".
|
|-
!Space characters
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000C FORM FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-06T11:24:25Z

Lachlan Hunt: /* Syntax and Parsing */ Described namespace attributes and processing in more detail.

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
!Parsing Modes
|Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
|XML parsing rules are used. There is only one mode.
|The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
!Error Handling
|HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
|Well-formedness errors are fatal
|
|-
!Namespaces
|Elements and attributes are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
|The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
!Namespace attributes on HTML elements
|Elements in the HTML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xhtml"</code>. The 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 no namespace.

Attributes of the form <code>xmlns:<var>prefix</var></code> may not be used on HTML elements.
|The HTML namespace must be declared for HTML elements according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!Namespace attributes on foreign elements
|
Elements in the SVG namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/2000/svg"</code>. The attribute is optional because the namespace is implied during parsing.

Elements in the MathML namespace may have an <code>xmlns</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1998/Math/MathML"</code>. The attribute is optional because the namespace is implied during parsing.

Foreign elements may also have an <code>xmlns:xlink</code> attribute specified, if, and only if, it has the exact value <code>"http://www.w3.org/1999/xlink"</code>. This attribute is optional, even if XLink attributes are used, because the namespaces for XLink attributes is implied during parsing.

When parsed by an HTML parser, the <code>xmlns</code> and <code>xmlns:xlink</code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|The SVG and MathML namespaces must be declared for SVG and MathML elements, respectively, according to the rules defined by ''Namespaces in XML''. The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes end up in the <code>"http://www.w3.org/2000/xmlns"</code> namespace.
|
|-
!XLink attributes
|Foreign elements may use the attributes <code>xlink:actuate</code>, <code>xlink:arcrole</code>, <code>xlink:href</code>, <code>xlink:role</code>, <code>xlink:show</code>, <code>xlink:title</code> and <code>xlink:type</code>. These attributes are placed in the <code>"http://www.w3.org/1999/xlink"</code>. The prefix used must be "<code>xlink</code>".
|XLink attributes may be specified on foreign elements using any prefix, subject to the conformance rules defined by ''Namespaces in XML''. The XLink namespace must be declared according to the conformance rules defined by ''Namespaces in XML'' if XLink attributes are used within the document.
|
|-
!XML attributes
|
Foreign elements may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".

HTML elements may use the <code>xml:lang</code> attribute. The attribute in no namespace with no prefix and with the literal localname "<code>xml:lang</code>" has no effect on language processing. HTML elements must not use the <code>xml:base</code> or <code>xml:space</code> attributes.
| Any element, including HTML elements, may use the attributes <code>xml:lang</code>, <code>xml:base</code> and <code>xml:space</code>. These attributes are placed in the <code>"http://www.w3.org/XML/1998/namespace"</code>. The prefix used must be "<code>xml</code>".
|
|-
!Space characters
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000C FORM FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-06T09:34:59Z

Lachlan Hunt: /* Syntax and Parsing */ Revised parsing modes description.

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
!Parsing Modes
|Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
|XML parsing rules are used. There is only one mode.
|The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
! Error Handling
| HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
| Well-formedness errors are fatal
|
|-
! Namespaces
| Elements and attributes are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
| The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
!Space characters
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000C FORM FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-06T09:33:49Z

Lachlan Hunt: /* Syntax and Parsing */ Revised space character description

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
! Parsing Modes
| Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
| XML parsing rules are used.
| The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
! Error Handling
| HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
| Well-formedness errors are fatal
|
|-
! Namespaces
| Elements and attributes are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
| The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
!Space characters
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000C FORM FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The space characters are defined as:
* U+0009 CHARACTER TABULATION
* U+000A LINE FEED
* U+000D CARRIAGE RETURN
* U+0020 SPACE
|The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-06T01:10:55Z

Lachlan Hunt: /* Syntax and Parsing */ Mentioned obsolete permitted DOCTYPEs, more thorougly describe the permitted syntax

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
! Parsing Modes
| Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
| XML parsing rules are used.
| The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
! Error Handling
| HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
| Well-formedness errors are fatal
|
|-
! Namespaces
| Elements and attributes are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
| The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
! Space characters
| The space characters are defined as U+0020 SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+000C FORM FEED, and U+000D CARRIAGE RETURN. i.e. SPACE, TAB, LF, FF and CR.
| The space characters include U+0020 SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, and U+000D CARRIAGE RETURN. i.e. SPACE, TAB, LF, and CR.
| The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

When using the obsolete but conforming DOCTYPEs based on the HTML 4.0 and 4.01 Strict DTDs, the system identifier is optional. The obsolete but conforming DOCTYPEs based on XHTML 1.0 Strict and XHTML 1.1 may also be specified.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply (everything is case sensitive).

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE. If the poublic identifier is specified, the system identifier must also be specified. The obsolete status of the ''obsolete permitted DOCTYPEs'' defined for HTML does not apply to XHTML. Any DOCTYPE may be used, subject to the conformance rules defined by XML.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

* HTML Parse Errors with special handling:
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).

* The sequence of characters "<code>]]></code>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-05T23:20:15Z

Lachlan Hunt: /* Syntax and Parsing */ Added whitespace and placeholders for more elements

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
! Parsing Modes
| Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
| XML parsing rules are used.
| The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
! Error Handling
| HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
| Well-formedness errors are fatal
|
|-
! Namespaces
| Elements and attributes are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
| The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
! Space characters
| The space characters are defined as U+0020 SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+000C FORM FEED, and U+000D CARRIAGE RETURN. i.e. SPACE, TAB, LF, FF and CR.
| The space characters include U+0020 SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, and U+000D CARRIAGE RETURN. i.e. SPACE, TAB, LF, and CR.
| The difference is the inclusion of Form Feed.
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply.

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Raw text elements
|
|
|
|-
! RCDATA elements
|
|
|
|-
! Foreign elements
|
|
|
|-
! Normal elements
|
|
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

** 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></br></code> or <code></p></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>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-05T23:09:47Z

Lachlan Hunt: /* Syntax and Parsing */ Added namespaces

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
! Parsing Modes
| Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
| XML parsing rules are used.
| The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
! Error Handling
| HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
| Well-formedness errors are fatal
|
|-
! Namespaces
| Elements and attributes are implicitly assigned to appropriate namespaces, according to the rules specified in the parsing algorithm.
| The rules defined in the [http://www.w3.org/TR/REC-xml-names/ Namespaces in XML] specification apply. Namespaces must be explicitly declared.
|
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply.

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

** 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></br></code> or <code></p></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>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-05T23:01:08Z

Lachlan Hunt: /* Syntax and Parsing */

== Differences Between HTML and XHTML ==

<p style="border: 1px dashed lightgray; background-color: #FFF8E4; padding: .5em 1em;">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.</p>

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.

=== MIME Types ===

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
| Mime Type
| Must use <code>text/html</code>.
| Must use an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
| It is the MIME type that determines what type of document you are using. Any document, including a document authored with the intention of being XHTML, served as <code>text/html</code> is technically an HTML document.
|}

Note that XHTML 1.0 previously defined that documents adhering to the compatibility guidelines were allowed allowed to be served as <code>text/html</code>, but HTML 5 now defines that such documents are HTML, not XHTML.

=== Syntax and Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today. The following table describes the differences between how each is parsed.

{| class="wikitable" border="1"
|-
! Feature
! HTML Requirement
! XHTML Requirement
! Notes
|-
! Parsing Modes
| Three parsing modes are defined: ''no quirks mode'', ''quirks mode'' and ''limited quirks mode''. The mode is only ever changed from the default by the HTML parser, based on the presence, absence, or value of the DOCTYPE string.
| XML parsing rules are used.
| The parsing modes in HTML also have an effect upon script and stylehsheet processing. XHTML is considered to be in ''no quirks mode'' for these purposes.
|-
! Error Handling
| HTML does not have a well-formedness constraint, no errors are fatal. Graceful error handling and recovery procedures are thoroughly defined.
| Well-formedness errors are fatal
|
|-
! The DOCTYPE
|
A DOCTYPE is a mostly useless, but required, header. The DOCTYPE is used during parsing to determing the parsing mode. The keywords "<code>DOCTYPE</code>", "<code>PUBLIC</code>" and "<code>SYSTEM</code>", and the name "<code>html</code>" are treated case insensitively. The system identifier <code>"about:legacy-compat"</code> (and the public and system identifiers for previous versions of HTML) are case sensitive.

Conforming HTML documents are required to use <code><!DOCTYPE html></code> (case insensitively) or the legacy-compat version <code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>.

Use of an internal subset is forbidden. The system identifier is never de-referenced by HTML implementations.
|
The DOCTYPE is optional. XML rules for case sensitivity apply.

Either of the DOCTYPEs defined in HTML5 may be used, or any other custom DOCTYPE.

Use of an internal subset is permitted according to the requirements of XML. Some validating XML processors may dereference the system identifier, if used, but most browsers use non-validating processors.
|
|-
! Void Elements
| Void elements only have a start tag; end tags must not be specified for void elements, and it is impossible for them to contain any content. A trailing slash may optionally be inserted at the end of the element's tag, immediately before the closing greater-than sign.
| Void elements may use either the empty-element tag syntax (''EmptyElemTag'') or use a start tag immediately followed by an end tag, with no content in between. While it is possible for the element to contain content, this is non-conforming.
|
|-
! Optional tags
|
For [[#HTML_Elements_with_Optional_Tags|some elements]], the start and/or end tags are optional and are implied by certain specified conditions. For example, the end tag for the <code>p</code> element is implied by a subsequent <code>p</code> element.

Omitting the end tag for other elements is a parse error and various error recovery procedures are applied appropriately.
| End tags must be explicitly included for all elements, except empty elements using the ''EmptyElemTag'' syntax.
|
|-
! Unescaped Special Characters
|
Unescaped ampersands (U+0026 AMPERSAND - <code>&</code>, instead of <code>&amp;</code>) are permitted within the content of ''normal elements'', ''RCDATA elements'', ''foreign elements'' and ''attribute values'' where they are not considered to be ''ambiguous ampersands'', and within ''Raw text elements''.

Unescaped less than signs (U+003C LESS-THAN SIGN - <code><</code>, instead of <code>&lt;</code>) are permitted in ''Raw text elements'', ''RCDATA elements'' and ''attribute values'', excluding the ''unquoted attribute value syntax''.
| Unescaped ampersands and less-than signs may not appear within ''CharData'' or ''AttValue'' (basically, the normal text content of elements and attribute values.) Violation of this constraint is a well-formedness error.
|
|-
! Comment syntax
| Comments must start with the four character sequence "<code></code>". The content of comments must not start with a single U+003E GREATER-THAN SIGN ('>') character, nor start with a U+002D HYPHEN-MINUS (-) character followed by a U+003E GREATER-THAN SIGN ('>') character, nor contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a U+002D HYPHEN-MINUS (-) character. Violating these constraints is a parse error and various error recovery procedures are applied appropriately.
| The content of comments must not contain two consecutive U+002D HYPHEN-MINUS (-) characters, nor end with a hypen. Violating this is a well-formedness error.
|
|}

'''THIS PAGE IS IN THE PROCESS OF BEING REVISED'''

** 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></br></code> or <code></p></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>" in content 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> elements. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that things that look like comments are treated as <em>real</em> 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> elements. (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 an <code>CDATA</code> element. If scripting is disabled, it's parsed as a normal element. In XHTML, the element is always parsed as a normal element, 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> elements. 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.
* In HTML, elements with optional tags are implied in certain conditions.
* 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.)
* In HTML, a line feed that immediately follows a <code>pre</code>, <code>listing</code> or <code>textarea</code> start tag is ignored.
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

* In HTML, [http://wiki.whatwg.org/wiki/FAQ#What_will_the_DOCTYPE_be.3F the <code>doctype</code> is required]. In XHTML, it is optional.
* In HTML, the DOCTYPE is case insensitive. (e.g. <code><!DOCTYPE HTML></code> or <code><!doctype html></code>, or any case variation of that is acceptable). In XHTML, the DOCTYPE, if used, is case sensitive and must be well-formed XML. i.e. <code><!DOCTYPE html></code>, with optional PUBLIC and/or SYSTEM identifiers.
* 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:

* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></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>
* HTML allows attribute minimisation (i.e. omitting the equals sign and 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 can 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.

==== HTML Elements with Optional Tags ====

{| class="wikitable" border="1"
|-
! Element
! Start Tag
! End Tag
|-
!html
|optional
|optional
|-
!head
|optional
|optional
|-
!body
|optional
|optional
|-
!li
|required
|optional
|-
!dt
|required
|optional
|-
!dt
|required
|optional
|-
!p
|required
|optional
|-
!colgroup
|optional
|optional
|-
!thead
|required
|optional
|-
!tbody
|optional
|optional
|-
!tfoot
|required
|optional
|-
!tr
|required
|optional
|-
!th
|required
|optional
|-
!td
|required
|optional
|-
!rt
|required
|optional
|-
!rp
|required
|optional
|-
!optgroup
|required
|optional
|-
!option
|required
|optional
|}

--
1. 9.1.1 The DOCTYPE
2. 9.1.2 Elements
1. 9.1.2.1 Start tags
2. 9.1.2.2 End tags
3. 9.1.2.3 Attributes
4. 9.1.2.4 Optional tags
5. 9.1.2.5 Restrictions on content models
6. 9.1.2.6 Restrictions on the contents of raw text and RCDATA elements
3. 9.1.3 Text
1. 9.1.3.1 Newlines
4. 9.1.4 Character references
5. 9.1.5 CDATA sections
6. 9.1.6 Comments

=== Markup ===

* The [http://wiki.whatwg.org/wiki/FAQ#What_is_the_namespace_declaration.3F namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on any 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.
* XHTML can use <code>xml:base</code>, HTML cannot.
* 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://wiki.whatwg.org/wiki/FAQ#How_do_I_specify_the_character_encoding.3F specify the character encoding]. In HTML, the XML declaration is forbidden
* In HTML, the <code>meta</code> element with a <code>charset</code> attribute may be used instead. It 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 and Node.nodeName 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 will 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 and Safari, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element.
* XPath expressions targeted at pre-HTML5 browsers need to use the XHTML namespace for XHTML and null for HTML. (HTML5 browsers would use the XHTML namespace even in HTML.)

=== 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 ==

See [http://dev.w3.org/html5/html4-differences/ HTML 5 differences from HTML 4].

== 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)"]
* [http://dancewithnet.com/2007/10/28/differences-between-html-and-xhtml/ Chinese translation: "HTML和XHTML的不同"]

HTML vs. XHTML

2009-09-05T21:19:57Z

Lachlan Hunt: Merged Syntax and Parsing sections

HTML vs. XHTML

2009-09-05T12:40:55Z

Lachlan Hunt: /* Parsing */ Began reformatting and rewriting

HTML vs. XHTML

2009-09-05T08:01:31Z

Lachlan Hunt: /* MIME Types */ Reformatted as a table

Validator.nu Useful Warning Requests

2009-09-05T07:53:11Z

Lachlan Hunt: /* Polyglot Document Checking */ Added xml:lang

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a given, conforming HTML document is a polyglot document. This does not list all issues that would need to be checked to ensure that a given, conforming XHTML document is a polyglot document, however. As such, syntactic XML constructs which are not valid in HTML are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! The <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. For HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! The <code>xml:lang</code> attribute
| Meaningless talisman in HTML.
| In DOM implementations for XHTML, <code>xml:lang</code> represents the lang attribute in the XML namespace. For HTML, it represents an attribute in no namespace with the literal localname "xml:lang". This issue is '''unavoidable'''.
|
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using either: <code><meta charset="UTF-8"></code>, ensure the encoding is declared in the transport layer (HTTP Content-Type header), or use UTF-8 or UTF-16 with an appropriate Byte Order Mark.
| XHTML-compatible
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! Unescaped Special Chars
| Unescaped ampersand (<code>&</code>) or less-than (<code><</code>) characters are not allowed in text and attribute values, within XHTML. (This doesn't include within CDATA sections, comments, etc.)
| HTML can include unescaped ampersands where they are unambiguous, and unescaped less than characters within rawtext or RCDATA content, and quoted attributes.
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>script</code> and <code>style</code> Elements
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! The <code>textarea</code> and <code>title</code> Elements
| The content model of these elements is RCDATA in HTML, but PCDATA in XHTML. These elements may not contain escaping text spans (<code></code>, because they look like comments), or unescaped ampersands or less than characters.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-05T06:53:09Z

Lachlan Hunt: /* Polyglot Document Checking */ Described escaping text spans for RCDATA

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a given, conforming HTML document is a polyglot document. This does not list all issues that would need to be checked to ensure that a given, conforming XHTML document is a polyglot document, however. As such, syntactic XML constructs which are not valid in HTML are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using either: <code><meta charset="UTF-8"></code>, ensure the encoding is declared in the transport layer (HTTP Content-Type header), or use UTF-8 or UTF-16 with an appropriate Byte Order Mark.
| XHTML-compatible
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! Unescaped Special Chars
| Unescaped ampersand (<code>&</code>) or less-than (<code><</code>) characters are not allowed in text and attribute values, within XHTML. (This doesn't include within CDATA sections, comments, etc.)
| HTML can include unescaped ampersands where they are unambiguous, and unescaped less than characters within rawtext or RCDATA content, and quoted attributes.
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>script</code> and <code>style</code> Elements
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! The <code>textarea</code> and <code>title</code> Elements
| The content model of these elements is RCDATA in HTML, but PCDATA in XHTML. These elements may not contain escaping text spans (<code></code>, because they look like comments), or unescaped ampersands or less than characters.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-05T06:49:17Z

Lachlan Hunt: /* Polyglot Document Checking */ Updted unescaped special chars

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a given, conforming HTML document is a polyglot document. This does not list all issues that would need to be checked to ensure that a given, conforming XHTML document is a polyglot document, however. As such, syntactic XML constructs which are not valid in HTML are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using either: <code><meta charset="UTF-8"></code>, ensure the encoding is declared in the transport layer (HTTP Content-Type header), or use UTF-8 or UTF-16 with an appropriate Byte Order Mark.
| XHTML-compatible
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! Unescaped Special Chars
| Unescaped ampersand (<code>&</code>) or less-than (<code><</code>) characters are not allowed in text and attribute values, within XHTML. (This doesn't include within CDATA sections, comments, etc.)
| HTML can include unescaped ampersands where they are unambiguous, and unescaped less than characters within rawtext or RCDATA content, and quoted attributes.
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>script</code> and <code>style</code> Elements
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! The <code>textarea</code> and <code>title</code> Elements
| The content model of these elements is RCDATA in HTML, but PCDATA in XHTML. These elements may not contain escaping text spans, or unescaped ampersands or less than characters.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-05T01:40:25Z

Lachlan Hunt: /* Polyglot Document Checking */

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a given, conforming HTML document is a polyglot document. This does not list all issues that would need to be checked to ensure that a given, conforming XHTML document is a polyglot document, however. As such, syntactic XML constructs which are not valid in HTML are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using either: <code><meta charset="UTF-8"></code>, ensure the encoding is declared in the transport layer (HTTP Content-Type header), or use UTF-8 or UTF-16 with an appropriate Byte Order Mark.
| XHTML-compatible
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! Unescaped Special Chars
| Unescaped ampersand (<code>&</code>) or less-than (<code><</code>) characters are not allowed in XHTML
| HTML can include unescaped ampersands where they are unambiguous, and unescaped less than characters within rawtext or RCDATA content, and quoted attributes.
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>script</code> and <code>style</code> Elements
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! The <code>textarea</code> and <code>title</code> Elements
| The content model of these elements is RCDATA in HTML, but PCDATA in XHTML. These elements may not contain escaping text spans, or unescaped ampersands or less than characters.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-04T18:57:36Z

Lachlan Hunt: /* Polyglot Document Checking */ Updated character encoding issue

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a document is a polyglot document.

Any syntactic XML construct which is not valid in HTML is also assumed to be problematic, but are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements. In other words, this table only lists the things that would need to be checked to ensure that a fully conforming HTML document is a polyglot document.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using either: <code><meta charset="UTF-8"></code>, ensure the encoding is declared in the transport layer (HTTP Content-Type header), or use UTF-8 or UTF-16 with an appropriate Byte Order Mark.
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! <code>script</code> and <code>style</code> element Content
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-04T17:59:51Z

Lachlan Hunt: /* Polyglot Document Checking */ Added noscript and iframe elements

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a document is a polyglot document.

Any syntactic XML construct which is not valid in HTML is also assumed to be problematic, but are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements. In other words, this table only lists the things that would need to be checked to ensure that a fully conforming HTML document is a polyglot document.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using: <code><meta charset="UTF-8"></code>, or otherwise ensure the encoding is declared in the transport layer (HTTP Content-Type header).
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! <code>script</code> and <code>style</code> element Content
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|-
! The <code>noscript</code> Element
| The <code>noscript</code> Element is forbidden in XHTML.
|
| XHTML-compatible
|-
! The <code>iframe</code> Element Content
| The <code>iframe</code> Element must be empty in XHTML documents.
|
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-04T17:20:00Z

Lachlan Hunt: /* Polyglot Document Checking */

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a document is a polyglot document.

Any syntactic XML construct which is not valid in HTML is also assumed to be problematic, but are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements. In other words, this table only lists the things that would need to be checked to ensure that a fully conforming HTML document is a polyglot document.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using: <code><meta charset="UTF-8"></code>, or otherwise ensure the encoding is declared in the transport layer (HTTP Content-Type header).
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! <code>script</code> and <code>style</code> element Content
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
| XHTML-compatible
|}

Validator.nu Useful Warning Requests

2009-09-04T17:19:13Z

Lachlan Hunt: /* Polyglot Document Checking */ Merged case sensitivity issues, mentioned legacy-compat DOCTYPE.

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a document is a polyglot document.

Any syntactic XML construct which is not valid in HTML is also assumed to be problematic, but are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements. In other words, this table only lists the things that would need to be checked to ensure that a fully conforming HTML document is a polyglot document.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications. The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code> (or the legacy-compat version).
|
| XHTML-Compatible (and SVG+MathML)
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using: <code><meta charset="UTF-8"></code>, or otherwise ensure the encoding is declared in the transport layer (HTTP Content-Type header).
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! <code>script</code> and <code>style</code> element Content
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
|
|}

Validator.nu Useful Warning Requests

2009-09-04T17:16:32Z

Lachlan Hunt: Described more polyglot document requirements

This page documents requests for potential optional checks to be implemented by HTML5 QA tools, like Validator.nu. This is only intended to document feature requests, and may not reflect what is, or will be, implemented in the future.

The following tables describe issues that a QA tool might provide options to warn about. None of the issues listed in these tables are technically conformance errors, but have been requested directly by authors and/or are considered to be useful for authors to be warned about.

== Syntactic Issues ==
{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Quoted attributes
| Boolean option to require quoted attribute values for all attributes.
| XHTML-like syntactic convention commonly requested by authors. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Minimised attributes
| Boolean option to require all boolean attributes to use the non minimised form. e.g. <input disabled="disabled"> instead of <input disabled>
| XHTML-like syntactic convention commonly requested by authors.
|-
! Trailing Slashes
| Options to either:
# Warn about unnecessary trailing slashes in void elements
# Require trailing slashes for in void elements
# None (default)
| Some authors like to follow the XML convention, others prefer to always omit them, and others don't care that much. ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional </p> ahead of new structural element
| Boolean option to warn about omitted paragraph end tags ahead of start tags of section, nav, article, aside, header and footer
|
|-
! Optional End Tags
| Boolean option to require end tags for all non-void elements, which normally have optional end tags
| ([http://www.zeldman.com/superfriends/guide/#validation request])
|-
! Optional Start Tags
| Options to require start tags for the elements 'html', 'head', 'body' and 'tbody'.
| XHTML-like convention, mostly applies to html, head and body. Some authors still choose to omit tbody, but like to always include the others.
|-
! Case sensitivity
| Boolean option to check tag names and attribute names for case sensitivity.
| HTML and MathML elements and attributes are all lowercase, but SVG contains some camel case names.
|-
! Character Entity References
| Options to allow:
# The 5 predefined named entity references only (lt, gt, amp, quot, apos)
# HTML 4.01 entity references only
# XHTML 1.0 entity references only ([http://www.zeldman.com/2009/08/31/loving-html5/#comment-48070 request])
# All named entity references
| Warning about HTML4.01 references is a useful check for compatibility reasons, due to existing legacy browsers that don't support the additional entity references imported from MathML yet. Use of only the 5 predefined entity references is needed for those who want XHTML compatibility, without a DOCTYPE.
|}

== Other Warnings ==

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
|-
! Untitled document
| Warn about the use of meaningless or empty titles. e.g. <title>Untitled document<title> (or similar)
| This is a common default title inserted by authoring tools. Advise the author to use a more appropriate title for the document. ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|-
! Unnecessary whitespace
| Warn about long stretches of unnecessary whitespace
| ([http://krijnhoetmer.nl/irc-logs/whatwg/20090903#l-132 request])
|}

== Polyglot Document Checking ==

There are 3 levels of polyglot documents that can be created.

;Talismans Only :An HTML document that contains a number of XML-like syntactic constructs purely as a matter of convention. The document itself may not entirely conform with all well-formedness requirements or may not function properly for other reasons if it were to be treated as XHTML. (This is not really a true polyglot document, but is included here for completeness)
;XHTML Compatible :A valid HTML document that is also fully conforming XHTML. However, the different processing requirements between HTML and XHTML may give slightly different results that would not match in a tree comparison and is not round-trippable.
;Strict Polyglot :A valid HTML document that is also fully conforming XHTML, which would pass a tree comparison of the resulting DOMs (excluding unavoidable differences), and which is fully round-trippable.

Note that these descriptions intentionally ignore differences that could be caused by script and stylesheet processing.

The following is a table of issues that would need to be checked to ensure that a document is a polyglot document.

Any syntactic XML construct which is not valid in HTML is also assumed to be problematic, but are not listed here. For example, the internal subset of a DOCTYPE declaration or the use of CDATA sections within HTML elements. In other words, this table only lists the things that would need to be checked to ensure that a fully conforming HTML document is a polyglot document.

{| class="wikitable" border="1"
|-
! Title
! Description
! Notes
! Polyglot Level Requirement
|-
! <code>xmlns</code> and <code>xmlns:<var>prefix</var></code> attributes.
| The <code>html</code> root element needs to have an <code>xmlns="http://www.w3.org/1999/xhtml"</code> attribute. The <code>svg</code> and <code>math</code> elements need to declare the appropriate namespaces for SVG and MathML, respectively, and, if used within the document, XLink.
| In DOM implementations for XHTML, these attributes are in the <code>http://www.w3.org/2000/xmlns/</code> namespace. In HTML, these are in no namespace. This issue is '''unavoidable'''.
| XHTML-compatible (and SVG+MathML)
|-
! DOCTYPE Declaration
| The DOCTYPE declaration is case sensitive in XHTML. Must be <code><!DOCTYPE html></code>
|
| XHTML-compatible
|-
! Default Character Encoding
| The default character encoding for <code>text/html</code> is UTF-8. For <code>application/xhtml+xml</code> (and other XML types), it is UTF-8.
| Use UTF-8 and declare this using: <code><meta charset="UTF-8"></code>, or otherwise ensure the encoding is declared in the transport layer (HTTP Content-Type header).
| XHTML-compatible
|-
! The characters "<code>]]></code>" in content
| The use of this sequence of characters is a well-formedness error in XHTML.
|
| XHTML-compatible
|-
! <code>script</code> and <code>style</code> element Content
| In HTML, these elements are parsed as CDATA, allowing the use of unescaped special characters. In XHTML, these are parsed as #PCDATA, and any occurrence of the characters < or & must be escaped as <code>&lt;</code> and <code>&amp;</code>, respectively.
| Scripts and stylesheets containing these characters should be linked externally instead.
| XHTML-compatible
|-
! Line feeds after start tags
| A line feed (LF) after the start tags for <code><pre></code> or <code><textarea></code> (or the non-conforming <code><listing></code> element) is ignored in HTML.
| Avoid using line feeds after these start tags
| Strict Polyglot
|-
! Quoted attributes
| Unquoted attributes are not allowed in XHTML.
|
| XHTML-compatible
|-
! Minimised attributes
| Minimised attributes (attributes without a value) cannot be used in XML.
| Used expanded form. e.g. <code>disabled=""</code> or <code>disabled="disabled"</code>
| XHTML-compatible
|-
! Trailing Slashes
| Void elements require explicit closing with trailing slashes.
|
| XHTML-compatible
|-
! Optional start- and end-tags
| Neither start- nor end-tags may be omitted.
|
| XHTML-compatible
|-
! The <code>tbody</code> Element
| In HTML, the <code>tbody</code> element will be implied automatically, but in XHTML, it is optional.
| Explicitly include the <code>tbody</code> element.
| Strict Polyglot
|-
! Case sensitivity
| All tag names and attribute names for HTML elements must be written in lowercase. Tag names for SVG and MathML must be written in the case defined by those language specifications.
|
| XHTML-Compatible (and SVG+MathML)
|-
! Character Entity References
| Without a DTD, only the 5 predefined entity references in XML may be used.
| The additional entity references defined and supported using the XHTML 1.0 or 1.1 DOCTYPE cannot be used in XHTML.
|
|}

Validator.nu Useful Warning Requests

2009-09-04T16:52:10Z

Lachlan Hunt: /* Polyglot Document Checking */

Validator.nu Useful Warning Requests

2009-09-04T10:03:31Z

Lachlan Hunt: /* Polyglot Document Checking */

Validator.nu Useful Warning Requests

2009-09-04T09:59:56Z

Lachlan Hunt: /* Polyglot Document Checking */ Added LF after Start Tags issue

Validator.nu Useful Warning Requests

2009-09-04T08:34:16Z

Lachlan Hunt: Added polyglot document checking section

Validator.nu Useful Warning Requests

2009-09-03T14:11:19Z

Lachlan Hunt: Fixed a row heading, adjusted named entities description

Validator.nu Useful Warning Requests

2009-09-03T14:08:55Z

Lachlan Hunt: List a few commonly requested warnings to begin