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

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

From: Řistein E. Andersen <html5@xn--istein-9xa.com>
Date: Fri, 01 Dec 2006 02:44:29 +0100
Message-ID: <E1GpxS1-00004s-00@ws1.ou-data.net>
Trailing slashes in void elements are clearly unnecessary from a syntactic point
of view, but I think it can be argued that allowing them actually makes HTML
more internally consistent.

Current versions of HTML allow many unnecessary closing tags to be omitted
(e.g., </p>), and for authors exploiting this feature, adding trailing slashes to void
elements probably does not make much sense. Let's call this syntax I.

But current HTML also allows closing tags to be used for all non-void elements.
Authors doing this consistently will quite reasonably want to indicate closure of void elements
explicitly, which can be done by allowing something like either <img/> or <img></img>,
of which the former is probably preferable because it makes it overt that the element
is void, i.e., that it must be empty. Let's call this syntax II.

[Personally, I would like a conformance checker to issue either a warning or an
informational statement if (1) some, but not all optional closing tags are omitted,
if (2) some, but not all void elements contain a trailing slash, and perhaps even
if (3) the author does not adhere to either syntax I or syntax II. I do realise, though,
that others may want to keep conformance and consistence separate, and that such
additions to a conformance checker are unlikely to be made if important
modifications would be necessary in order to do so. This is only one example of
inconsistency that authors might want to avoid, of course.] 

Finally, not allowing trailing slashes in HTML does indeed make the format more
different from XHTML, but this does probably not imply that the distinction
between the two will be clearer or easier to grasp, which is what is really wanted.

-- 
??istein E. Andersen
Received on Thursday, 30 November 2006 17:44:29 UTC

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