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

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Tue, 28 Nov 2006 16:20:31 -0500
Message-ID: <456CA81F.1050708@intertwingly.net>
In response to a weblog post of mine[1], Ian stated[2]:

     we can?t make trailing ?/? characters meaningful ? it would
     change how about 49% of the Web is parsed

Just to make sure that we are talking about the same thing, let me make 
a much more carefully scoped proposal.

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 param.

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 diverge?

As an additional constraint, I am explicitly suggesting that the 
"Attribute value (unquoted) state" not be changed - slashes in this 
state would continue to be appended to the current attribute's value.

The basis for my question is the observation that the web browsers that 
I am familiar with apparently already operate in this fashion, this 
usage seems to have crept into quite a number of diverse places, and all 
this is coupled with Lachlan's observations[3] on what it would take to 
change the popular WordPress application to produce HTML5 compliant output.

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 separately.

- Sam Ruby

[1] http://intertwingly.net/blog/2006/11/28/Meet-the-New-Boss
[2] http://intertwingly.net/blog/2006/11/28/Meet-the-New-Boss#c1164743684
[3] http://intertwingly.net/blog/2006/11/24/Feedback-on-XHTML#c1164720800
Received on Tuesday, 28 November 2006 13:20:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:49 UTC