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

Re: B.10 Empty elements?

From: Len Bullard <cbullard@HiWAAY.net>
Date: Mon, 14 Oct 1996 20:39:29 -0500
Message-ID: <3262EB51.4728@HiWAAY.net>
To: Bill Smith <bill.smith@Eng.Sun.COM>
CC: w3c-sgml-wg@w3.org
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.
> 
> I might trade speed for complexity but I'd hate to lose speed while increasing
> complexity. Bad tradeoff.

Agreed that is a bad tradeoff.  Forcing lookahead isn't good, and
maintaining a stack seems to be undesirable for the PERL hacker.
It appears though, that this is still a case where the absence 
of the DTD bites, and perhaps the </e> is the best tradeoff.  
Thanks for making it clear, Bill and Lee. 

Get ready to answer this same question a few hundred times 
a year.  No matter how we explain it, the <e></e> looks redundant 
for an EMPTY element and a lot of SGML hackers are taught not to 
do it.  It will be a tough habit to break because from the 
author's perspective, not the parser programmer, it looks like 
YetAnotherReasonSGMLIsUgly.

Oh well, my drummer is ugly but he has good meter.

len
Received on Monday, 14 October 1996 21:39:18 UTC

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