[whatwg] Allow trailing slash in always-empty HTML5 elements?
rubys at intertwingly.net
Wed Nov 29 08:15:53 PST 2006
Lachlan Hunt wrote:
> Sam Ruby wrote:
>> In HTML5, there are a number of elements with a content model of
>> empty: area, base, br, col, command, embed, hr, img, link, meta, and
>> If HTML5 were changed so that these elements -- and these elements
>> alone -- permitted an optional trailing slash character, what
>> percentage of the web would be parsed differently? Can you cite three
>> independent examples of existing websites where the parsing would
> If it's only allowed on empty elements (now known as "singleton
> elements" in the spec) then this isn't about changing the handling, it's
> just about defining what is and is not conforming.
> I do not think it's a good idea to make the trailing slash conforming.
> Although it is harmless, it provides no additional benefit at all and it
> creates the false impression that the syntax actually does something.
> The fact is that authors already try things like <div/>, <p/> and even
> <a/>. I've seen all of those examples in the wild. See, for instance,
> the source of the XML 1.0 spec (and many others) which claim to be XHTML
> as text/html, littered with plenty of <a/> tags all throughout.
If these are common, and implemented interoperably, then what is the
harm? An example of something that is NOT implemented interoperably is
In my book, a document that states that it always is a parse error to do
something despite abundant evidence to the contrary is not as useful as
one that says here are the places where it works, and here are the
places where it does not.
> I've even come across various authors either thinking that does work, or
> (when they find out the truth) wondering why it doesn't. It's not a
> good idea to confuse them any more by giving the impression that it
> works for some elements but not others. It's better to just say it
> doesn't work at all and forbid it in all cases.
That's a slippery slope. At the extreme, it leads to XHTML 2.0, where
features that are thought to be problematic are removed. "Think of the
By contrast, in HTML5, I see a document that attempts to be considerably
less judgemental, and considerably more resilient. Inside the comments
in the HTML 5 document I see statistics lovingly cited. Example:
<!-- As of
2005-12, studies showed that around 0.2% of pages used the
<image> element. -->
What percentage of pages use <img/> constructs?
>> and all this is coupled with Lachlan's observations on what it
>> would take to change the popular WordPress application to produce
>> HTML5 compliant output.
> That just illustrates a fundamental flaw in the way WordPress has been
> built. It is a perfect example of a CMS built by a bunch of bozos 
> and cannot be used as an excuse for allowing the syntax.
Be careful when you patronize.
Is there really any excuse for allowing "<b><i>OMG!</b></i>"? No, but
HTML5 is willing to pinch its nose with thumb and forefinger and look
the other way. It literally is not a battle worth fighting.
>> As a side benefit of this change, I believe that I could modify my
>> weblog to be simultaneously both HTML5 and XHTML5 compliant, modulo
>> the embedded SVG content, something that would needs to be discussed
> No you couldn't, and how would that be a benefit if you could? XHTML 5
> requires xmlns, HTML 5 forbids it. HTML 5 requires <!DOCTYPE html>,
> XHTML 5 doesn't (though it's still well-formed, so you could get away
> with it).
The last I saw, HTML 5 is a working draft. Did I miss a memo?
With Venus, I translate all content into a canonical well formed XML
format. This enables people who author filters to the ability to worry
about a lot less random edge cases. I've already seen a lot of
inventiveness when people find that they can apply off the shelf XML
tools like XPath and XSLT.
I'd gladly put in a <!DOCTYPE html> in my page, the question is: would
the WHATWG be willing to meet me half way and allow xmlns attributes in
a very select and carefully prescribed set of locations?
By the way, my experience is that these types of conversations always
start off bumpy not merely due to the well known limitation of email for
conveying human emotion. The problem is deeper than that: there
literally is no good place to start. The only way I know how to deal
with that is to pose, and repeat, concrete and simple questions. And
the one that I am posing with this thread is as follows:
If HTML5 were changed so that these elements -- and these elements
alone -- permitted an optional trailing slash character, what
percentage of the web would be parsed differently? Can you cite
three independent examples of existing websites where the parsing
>  http://hsivonen.iki.fi/producing-xml/
- Sam Ruby
More information about the whatwg