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

[Mike Schinkel]

Ian:

(I didn't know what part to quote, so I left your email intact below.)

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

1.) Currently coding HTML(4) but trying to move to XHTML
2.) Currently coding XHTML and cleaning up only HTML(4)
3.) Currently coding only in XHMTL
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
6.) Currently offering a CMS/web app generates HTML(4) with string
concatonation and XHTML with an XML pipeline
7.) Currently offering a CMS/web app generates XHTML with an XML pipeline

And, respectfully, "it doesn't matter" should not be considered a valid
answer.

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/


-----Original Message-----
From: Ian Hickson [mailto:ian at hixie.ch] 
Sent: Saturday, December 02, 2006 3:48 AM
To: Mike Schinkel
Cc: whatwg at whatwg.org
Subject: RE: [whatwg] Allow trailing slash in always-empty HTML5 elements?

On Sat, 2 Dec 2006, Mike Schinkel wrote:
> 
> >> You don't need to do one or the other. It's just up to you which 
> >> you do. Neither is better or worse than the other. They are 
> >> equivalent, neither is deprecated, .... There's no reason to try and do
both.
> 
> If, as you say one is as good as the other, why in the world have both?

The Web Apps 1.0 spec doesn't have both. It has a single format, HTML5, that
is compatible with the overwhelming majority of Web content, and is
compatible with the "tag soup" parsers as supported by all major Web
browsers (including most mobile browsers).

However, since HTML5 is defined in terms of the DOM, and since XML is one
way of serialising a DOM, it is guarenteed that _someone_ will try to create
an XML serialisation of HTML5 DOMs. Therefore, the Web Apps spec addresses
this, gives it a name (XHTML5), and makes sure to clearly state how that
should work, so that when someone does it, they don't have to guess.

We have no choice about having the HTML format -- that's what the Web uses
today and we have to be compatible with that to be successful. We have no
cohice about the XML form, XML is used by certain people and there is a
guarentee that people will try to use HTML5 with XML. Therefore we are stuck
with having both.

For most people, however, XHTML5 need never enter their world.


> Maybe I'm wrong about this, but I bet most of the word-a-day web 
> developers and vendors of products that would need to support both 
> would agree. Has there been any attempt to learn their options on the 
> direction of HTML5 vs. XHTML?

There really is very little reason for anyone to use XHTML5 today, since it
doesn't work in IE7, the majority browser, whereas HTML5 does.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'