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