Re: B.10 Empty elements?

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.  It requires the DTD and in cases for systems that 
already do SGML as hypermedia, it has required a stylesheet where a 
DTD was not used.  I see the point of avoiding lookahead that it adds
complexity, 
but in fact, empty elements are used successfully and they work.  In the 
cases I'm thinking about, IDE/AS and IADS they don't format as they 
load, but many of these documents are considerably bigger than the 
average Web page and the performance is acceptable.  I think you
overstate.

The <e></e> looks worse than <@e>.  It is consistent, but intuitively
wrong.
As I said, do as you will, but be prepared to explain it repetitively.

len

Received on Tuesday, 15 October 1996 08:56:54 UTC