W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

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

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Mon, 4 Dec 2006 00:48:34 -0500
Message-ID: <023f01c71767$d9464580$2102fea9@Guides.local>
Shadow2531:

Sounds like you are in agreement. But can I ask you to summarized what you'd
propose?

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

 

-----Original Message-----
From: Shadow2531 [mailto:shadow2531@gmail.com] 
Sent: Sunday, December 03, 2006 12:57 PM
To: Mike Schinkel
Cc: Elliotte Harold; Lachlan Hunt; WHAT WG List
Subject: Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?

On 12/2/06, Mike Schinkel <mikeschinkel at gmail.com> wrote:
> On another note, why not another new content type, one that would mean?:
>
>         "Striving to be XHTML, but if not consider me HTML5. And if 
> that doesn't work, try HTML 4.01."

If you're implying, "Treat as XML and if that fails....":

One of the cool things about Opera is that if it encounters a broken xml
document, you can reparse it as HTML with a click of a link.

That means, there could be an option for browsers that support
application/xhtml+xml to treat text/html as xml ( by sniffing for a xmlns or
some other way) and then either directly or non-directly fall back to html
if there's an error.

Firefox could do the same with the yellow bar that pops up at the top of the
page that says, "The document appears to be XHTML, but is not well formed.
Firefox has reparsed it as HTML for you in an attempt to handle the
errors.", or something like that.

The problem with that would be that a lot of well-formed XHTML markup would
break if treated as XML ( because of casing rules etc.), so you'd still want
an option to reparse as HTML even if there were no markup errors.

Sites could have a "Our pages support 'text/html as XML'  handling.
Add us to your browsers's text/html -> XML list.".

One point is that stuff like that could be done in a slick way with the
text/html type instead of a new type as we already have problems with 2
types. (not that I believe this idea would be well accepted or
practical)

Just mentioning this though, I realize everyone's thinking, "Users would
just turn that feature off and what's the point anyway etc.???", but I do
see some benefit in the idea as a developers tool, to spread XHTML awareness
and to provide XHTML benefits with just using text/html.

To be on topic, the other point is, that describes a (far fetched) use case
for those suggesting  *partial* integration of XML stuff in HTML5.

--
burnout426
Received on Sunday, 3 December 2006 21:48:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:31 UTC