Space Before Closing Slash?

I've frequently seen a space preceding the closing slash in XML and HTML tags. The XHTML line break is probably the canonical example:

<br />

instead of:

<br/>

The space seems superfluous. In fact, I think that it is superfluous.

What is the reason for writing this space?

I've read that the space solves some "backwards compatibility issues." Which backwards compatibility issues? Are those issues still relevant, or are we still adding extra spaces for the sake of, say, IE3 compatibility? Does there exist some spec with the definitive answer on this?

If not backwards compatibility, then is it a readability issue? Similar to the Great Open Curly Brace debate?

void it_goes_up_here() {

int no_you_fool_it_goes_down_there()
{

I can certainly respect differing stylistic opinions, so I'll be happy to learn that writing the space is simply a matter of taste.

Solution 1:

The answer is people wish to adhere to Appendix C of the XHTML1.0 specification. Which you only need to do if you are serving XHTML as text/html. Which most people do, because XHTML's real MIME type (application/html+xml) does not work in Internet Explorer.

No current browser cares for the space. Browsers are very tolerant of these things.

The space used to be required to ensure HTML parsers treated the trailing slash as an unrecognised attribute.

Solution 2:

Netscape 4.80 showing different behaviour of <br/> and <br /> in HTML

Supporting bobince's answer with screenshot of Netscape 4.80 showing documents

data:text/html,<title>space</title>foo<br />bar

(top left, linebreak rendered) and

data:text/html,<title>no space</title>foo<br/>bar

(bottom left, linebreak ignored).

Posting as answer to show the picture

Tangentially related: in fact I had a lengthy answer identifying the cause of such misbehaviour of ancient browsers (and resulting recommendation to include space) in misunderstood SGML specs, namely SGML Null End Tag (NET) (where 1<tag/2/3 equals 1<tag>2</tag>3 so 1<tag/>2 would actually mean 1<tag>>2), but not only I was unable to find good proof and concrete version of standard, I wasn't even able to grasp proper standard-complying behaviour. So few raw links for reference:

w3c validator notice mentioning problematic closing slash and pointing to
Empty elements in SGML, HTML, XML, and XHTML @ www.cs.tut.fi/~jkorpela/
Beware of XHTML: Null End Tags (NET) stating, that

However, there are still some smaller user agents that properly support Null End Tags. One of the more well-known user agents that support it is the W3C validator.

(Unable to reproduce there now, but supports Lee Kowalkowski's statement about multiple browsers affected by this.)

XML W3C Working Draft 07-Aug-97 - latest specs draft that includes reference of Null End Tag in DTD snippet: NET "/>"

Solution 3:

Are those issues still relevant or are we still adding extra spaces for the sake of, say, IE3 compatibility?

You were close - it is for Netscape 4.

It is interesting to see other rationalisations, but that's all it was meant for.

Solution 4:

No, the space is not required but it is necessary for some older browsers to render those tags correctly. The proper way to do it is without the extra space as this is something XHTML inherited from XML.

Solution 5:

The space just makes the tags more readable. I am a big proponent of formatting for more readable code. Little things like that go a long way. Without the space the closing tag blends in with the opening tag. It takes just an instant longer for me to process it as I am quickly reading the code.