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

[Shadow2531]

On 12/4/06, Mike Schinkel <mikeschinkel at gmail.com> wrote:
> Shadow2531:
>
> Sounds like you are in agreement. But can I ask you to summarized what you'd
> propose?

Not sure if I can summarize, but I can be more specific by example.

Example browser preferences:
(Default value is first value)

[Markup handling preferences]
html_with_xhtml_xmlns = parse_as_html or parse_as_xml or
parse_as_xml_only_if_in_list
xml_parser_error_fallback = show_link_to_fallback_to_html or
direct_fallback_to_html[1] or no_fallback or
show_link_even_if_no_error

[parse html as xml list]
somesite.com
someothersite.com
server.domain.tld
http://somesite.com/well-formed_xhtml_markup.html

1. A direct fallback to html would not cause a loop back to the xml
parser for an html page that was set to be parsed as XML and wasn't
well formed.

Specifically, I was mentioning that settings like the following would
be a use case for XMLisms in text/html.

[Markup handling preferences]
html_with_xhtml_xmlns = parse_as_xml_only_if_in_list
xml_parser_error_fallback = show_link_to_fallback_to_html

[parse html as xml list]
Some site or page that only serves text/html, but can be properly parsed as XML.

As you can see, it wouldn't bother anyone that didn't care (as it'd be
off by default), but for those who care and want XHTML markup treated
as XML even for text/html ( and local .html and .htm), that would be a
use case.

So, my point was that we wouldn't need a text/html5 mime type (for
example) as we could reuse the text/html type (performance issues
aside). Adding a new type I don't think would help as it's probably
not compatibile, but text/html is.

It's not possible to fully get rid of mime type dependability yet, but
judging from "Who cares what mime type it uses, let's treat it for
what it is, if possible" comments on the list, the above would have
its use. And, because the above would have its use, I can see the
usefulness of some *partial* merging of XHTML5 and HTML5.

So, I agree in the usefullness of treating xhtml markup as XML at
will. I'm just not sure that it'll work good enough and many including
Ian have already strongly suggested that it would not work good
enough.

The question probably is: if the xhtml markup is being sent as
text/html and works fine as text/html, why treat it as XML?
For me personally, I like the strictness of XML and its other rules. I
want xhtml markup to blow up if there's an error so it can be fixed.
For others, that want to use XML tools on XHTML markup (regardless of
mime type), want the errors fixed also.

Don't get me wrong and it may seem contrary to what I've said above
(just being open minded), I'm fine with serving as
application/xhtml+xml and calling it a day. I don't mind serving using
HTML markup as text/html and calling it a day. But, doing both,
especially with the same markup, I am not interested in usually.
However, I'd still like to handle pages made by others that do it.

-- 
burnout426