W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1997

Re[2]: coping with overlapping elements in the DOM

From: <eqbridges@cbs.com>
Date: Fri, 8 Aug 1997 09:00:35 -0400
Message-ID: <3eb18830@cbs.com>
To: www-dom@w3.org
     
     this is the best proposed alternative that i've seen thus far.  it 
     allows the browser to provide a suitable, and rational, alternative 
     while also enforcing a "standard" approach to writing code.  someone 
     who has written the flawed code, and sees it as it is displayed (i.e. 
     flawed) should make the changes themselves.
     
     the whole point of drafting a standard is to develop a "correct" way 
     of coding.  this implies one way to do it.
     
     when we find that we're accounting for variations on a given way to do 
     something, we run into more complicated code and software with more 
     potential for bugs.  when we plan on (and make accomodations for) 
     other people's mistakes, then they will make them.
     
     regards
     ed.q.bridges
     


______________________________ Reply Separator _________________________________
Subject: Re: coping with overlapping elements in the DOM 
Author:  www-dom@w3.org at Internet
Date:    8/7/97 9:47 AM


> <P><B>This is <EM> not </B> a good idea</EM></P>
                         ^
                         |
     
At this point, you have an end tag which does not match the current element, 
but that element's start tag is on the stack (this is a stack-based parser). 
Close all open elements until the corresponding element is closed.  Extraneous 
close tags are ignored.  Hence my solution would be equivalent to:
     
<P><B>This is <EM> not </EM></B> a good idea</P>
     
This method has the advantage of not requiring the parser to look ahead.
     
To an author who is testing their document, hopefully this strategy would 
reveal
that there is a problem with the document (because something they thought 
would be italicised isn't).
     
Hope that helps,
Steve Ball
     
Received on Friday, 8 August 1997 09:05:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:44 GMT