# Re: self-closing tags in html5

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 20 Sep 2010 12:14:24 +0300
Cc: public-html@w3.org, Ian Hixie <ian@hixie.ch>
Message-Id: <A0B9CED9-6D8F-4517-97B8-7F250363F51F@iki.fi>
To: William F Hammond <hammond@csc.albany.edu>
On Sep 20, 2010, at 01:44, William F Hammond wrote:

> With the document
> http://math.albany.edu/~hammond/mmlmisc/mathjax/forqht5mj.html
> mathjax scripting is invoked.

It's rather unfortunate to invoke mathjax in browsers that support HTML5 parsing and MathML rendering (Firefox 4 and some recent flavors of WebKit).

> Mathjax provides a right mouse button
> tool for viewing a serialization of the dom that it sees initially.
>
> With browser X that serialization is explicitly non-empty, i.e.,
> <mspace> ... </mspace> with everything included from the original
> location of <mspace/> up to the close of the parent.  In browser Y the
> corresponding serialization shows no closetag for "mspace", and,
> therefore, is not a serialization of well-formed xml.

For which values of X and Y? I see the exact same serialization in the latest Firefox trunk nightly (Mac) and in IE8 (Windows XP).

> I think that things might work better if all self-closing tags,
> foreign or not, i.e., marked up in the form "<foo/>", are recognized
> as empty elements, whether defined-empty or merely de facto empty.  Of
> course, if "foo" is the name of an element in the short list of
> defined-empty html elements, it should still be the case that "<foo>"
> is recognized as indicating an empty element.  It would certainly be
> simpler for building the dom skeleton this way.

For backwards compatibility reasons, it's not OK to make <foo/> act as self-closing syntax when foo is an HTML element. On the other hand, where foo is a MathML element, we don't need to make <foo> (without the slash) self-close, since introducing that level of DWIM isn't necessary for compatibility.

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 20 September 2010 09:15:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:50 UTC