W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > October 1996

Re: B.10 Empty elements?

From: James Clark <jjc@jclark.com>
Date: Tue, 15 Oct 1996 14:07:44 +0000
Message-Id: <>
To: cbullard@HiWAAY.net
Cc: Bill Smith <bill.smith@eng.sun.com>, w3c-sgml-wg@w3.org
At 07:57 15/10/96 -0500, Len Bullard wrote:
>James Clark wrote:
>> At 18:21 14/10/96 -0700, Bill Smith wrote:
>> >Len Bullard wrote:
>> >
>> >> 3.  Is the processing time severe for the case you state?
>> >> I realize this question has many hands to argue with.
>> >
>> >While the average case time may not be "severe", the worst case behavior
>> may be
>> >and therefor cannot be ignored.
>> >
>> >If an empty element is inserted high in a document instance (say an <A>
>> within a
>> >high-level <DIV> in HTML 3.2), the emptiness of <A> cannot be inferred
>> until the
>> >enclosing element is closed - or the parser performs lookahead. Either way,
>> >processing is delayed and application complexity increases.
>> Isn't the problem even worse than this?  You don't just to figure out that
>> empty elements are in fact empty, you also have to figure out that non-empty
>> elements are not in fact empty. The first time I see a chapter tag, I can't
>> tell that it is not in fact an empty tag until I see its close tag.  So
>> either I can't start displaying the chapter until I have got the whole
>> chapter or I have to assume initially that every tag is non-empty and be
>> able to go back and reformat when I discover one that's not.  This just is
>> not going to work.
>> James
>But it is working.

I meant that neither of the two possibilities in the penultimate sentence
were viable: if you are guaranteed to have a DTD (or at least a partial one)
there's no problem using <e> for empty elements; if you are happy not to
have the document display as it loads, there's also no problem.

Received on Tuesday, 15 October 1996 09:13:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:04 UTC