[whatwg] Allow trailing slash in always-empty HTML5 elements?

[Lachlan Hunt]

Mike Schinkel wrote:
> So what guidance would you publish after HTML5 is released with regards to
> people in each of the following situations:

Note: Where I refer to outputting HTML below, I assume the use of 
text/html.  Where I refer to outputting XHTML below, I assume the use of 
an XML MIME type.  XHTML5 is not an option for content served as text/html.

> 1.) Currently coding HTML(4) but trying to move to XHTML

Those who are more comfortable with HTML4 will find it easier to move 
directly to HTML5.  Such authors can choose to migrate to XHTML if they 
wish, but to do so requires that they begin authoring using XML tools, 
or at least testing in a browser that actually supports XHTML using an 
XML parser.

> 2.) Currently coding XHTML and cleaning up only HTML(4)
> 3.) Currently coding only in XHMTL

That depends how they're coding XHTML.  If they're making the common 
beginner mistake of coding XHTML under text/html conditions (for which 
there is significant evidence proving it to be a fatal mistake), then 
such authors should migrate to HTML5.

If they're authoring with XML tools under XML conditions, then they may 
choose to migrate to XHTML5, but the final decision of what to use would 
still depend on how they intend to serve the content.

> 4.) Currently offering a CMS/web app generates HTML(4) using string
> concatonation, with plans to move it to XHTML
> 5.) Currently offering a CMS/web app generates HTML(4) and XHTML both using
> string concatonation

As Henri has outlined in his article on producing XML, using string 
concatenation and print statements to produce XML is a mistake. 
WordPress and MediaWiki fall into this category and it has proven to be 
a fatal architectural flaw in their design.  CMSs built like that would 
find it easier to migrate to HTML5.

http://hsivonen.iki.fi/producing-xml/#dontprint

> 6.) Currently offering a CMS/web app generates HTML(4) with string
> concatonation and XHTML with an XML pipeline

CMSs that do use a proper XML pipeline may choose to migrate to XHTML5. 
  However, such CMSs would, in reality, still be required to be able to 
output HTML5 given current browser limitations with XHTML.  But rather 
than using string concatenation to generate the HTML, it would be more 
effective to put an HTML5 serialiser on the end of the XML pipeline to 
output HTML5 from the XHTML source.

Authors wishing to output both formats depending on the browsers 
support, based on the Accept header, would also need to be aware of the 
issues involved with writing scripts and stylesheets that work correctly 
in either format, and also aware of the conditions under which 
reserialisation as HTML will result in a slightly different document.

e.g. In XHTML:

<p>A paragraph containing
   <ul>
     <li>a list</li>
     <li>of items</li>
   </ul>
</p>

Cannot be accurately represented in the HTML serialisation, as it would 
result in the following:

<p>A paragraph containing
   </p><ul>
     <li>a list</li>
     <li>of items</li>
   </ul>

http://www.whatwg.org/specs/web-apps/current-work/#restrictions

If wanting to author in HTML and reserialise as XHTML, there is also an 
issue with using the <noscript> element, as it is forbidden in XHTML5.

> 7.) Currently offering a CMS/web app generates XHTML with an XML pipeline

CMSs like that that only output XHTML and do not wish to output HTML may 
choose to migrate to XHTML5.

-- 
Lachlan Hunt
http://lachy.id.au/