[whatwg] Empty elements

[Ian Hickson]

On Sun, 28 Aug 2011, Bronislav KluÄ~Mka wrote:
>
> Hi,
> HTML5 defines several void elements.
> I think this enumeration is insufficient, and I'd like to suggest to simply
> allow every element to have syntax with /> at the end if such element has no
> content.
> e.g
> <div class="placeholder" />
> <script src="lib.js" />

On Sun, 28 Aug 2011, Nils Dagsson Moskopp wrote:
> 
> This would most certainly not be backwards-compatible.

Indeed.


On Sun, 28 Aug 2011, Jukka K. Korpela wrote:
> 
> The word "void", though used even in the validator's message, is at 
> least misleading if not incorrect. The correct word is "empty".

In HTML, the terms "void" and "empty" are orthogonal.

"Empty" refers to the state of the element's child nodes.

"Void" refers to the syntactic quality of the parser closing the element 
as soon as it sees the start tag, without looking for an end tag.

Here is an empty but not void element:

   <p></p>

Here is an empty and void element:

   <br>

Here is a non-empty and not void element:

   <p>x</p>

Here, a script appends to the document body a non-empty and void element:

   var img = new Image();
   img.textContent = 'x'; // note: creates non-conforming DOM
   document.body.appendChild(img);

The HTML syntax doesn't currently support any way of representing a void 
element that is not empty. Void elements are those that are never allowed 
to be anything but empty, so this is not a relevant limitation.


> The interesting question is: Where do the normative rules say that 
> self-closing syntax must not be used for other than empty elements?

"Void elements only have a start tag; end tags must not be specified for 
void elements."

http://www.whatwg.org/specs/web-apps/current-work/#syntax-tags


> > Have you tried using the XML serialization instead?
> 
> How would things be different in XML serialization? The whole idea of 
> "self-closing" tags is an XML idea, and it would be rather pointless to 
> use them in HTML serialization at all - there it is much more natural to 
> write <br> and not <br/> or <br />.

While it is indeed more natural to not use the redundant / in HTML, it is 
still conforming, and I believe it is the HTML syntax that the original 
poster was asking about.


On Sun, 28 Aug 2011, Aryeh Gregor wrote:
> 
> Those are relevant only to documents served with an XML MIME type. 
> Documents served with a text/html MIME type must obey the HTML syntax 
> rules, not XHTML.  I couldn't find where the spec says this normatively, 
> but there's an informative note at the top of the HTML syntax and XHTML 
> syntax sections.

"Labeling a resource with the text/html type asserts that the resource is 
an HTML document using the HTML syntax."

http://www.whatwg.org/specs/web-apps/current-work/#text/html


On Sun, 28 Aug 2011, Jukka K. Korpela wrote:
> 
> So does this mean that the rules are, after all, different for HTML 
> serialization than for XHTML serialization?

Yes, one is HTML and one is XML. They have only superficial similarities.


On Mon, 29 Aug 2011, Jukka K. Korpela wrote:
> 
> All previous HTML and XML specs have used the term "empty element" tp 
> denote an element for which the syntax allows no content. So what's the 
> compelling reason for changing that?

The term has long been overloaded to refer both to elements with no 
children and to elements that do not support an end tag. This was a highly 
confusing overloading of terminology.

(HTML4 falls prey to this problem. For example, consider the sentence "We 
discourage authors from using empty P elements" in section 9.3.1, or the 
phrase "For each empty COLGROUP element" in section 11.2.4.)


> > Maybe void isn't a great term, but empty isn't either.
> 
> In which way is "void" better than "empty"?

It's not better. It's different, which is what matters.


On Mon, 29 Aug 2011, Simon Pieters wrote:
> > 
> > About a validator - as HTML5 sets requirements on them, it would 
> > appear to be natural to require that they allow a document to be 
> > validated either as HTML-serialized or as XML-serialized.
> 
> I don't think the spec has such requirements.

Correct. A user agent can chose to support either or both syntaxes.

"For compatibility with existing content and prior specifications, this 
specification describes two authoring formats: one based on XML (referred 
to as the XHTML syntax), and one using a custom format inspired by SGML 
(referred to as the HTML syntax). Implementations must support at least 
one of these two formats, although supporting both is encouraged."

http://www.whatwg.org/specs/web-apps/current-work/#conformance-classes


On Mon, 29 Aug 2011, Jukka K. Korpela wrote:
> 29.8.2011 13:10, Simon Pieters wrote:
> > > 
> > > In which way is "void" better than "empty"?
> > 
> > The sentence "<p></p> is an empty element since it has no content, but 
> > p is not an empty element." is more confusing.
> 
> More confusing than what? (Is that hypothetical sentence more confusing 
> than "<p></p> is a void element since it has no content, but p is not a 
> void element."?)

No, it's more confusing than the current terminology: "<p></p> is an empty 
element since it has no content, but p is not a void element"


On Mon, 29 Aug 2011, Simon Pieters wrote:
> > 
> > Previously, "empty element" was used as a technical term, and <p></p> 
> > was not called an empty element.
> 
> It seems reasonable to call it empty. It matches XML's definition of 
> "empty". http://www.w3.org/TR/xml/#dt-empty

Indeed.


On Mon, 29 Aug 2011, Bronislav KluÄ~Mka wrote:
>
> Hi, it is not confusing at all, empty element is an element with no 
> content (<p></p>), void element is element that can have no content... 
> the difference is clear, but yes... void is not the best name

Agreed.

If anyone has a suggestion for a particularly better name that would make 
it worth the cost of changing, we should definitely consider it. At this 
point thought it might be better to just stick with "void".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'