- From: James Clark <jjc@jclark.com>
- Date: Tue, 15 Oct 1996 14:07:44 +0000
- 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. James
Received on Tuesday, 15 October 1996 09:13:15 UTC