- From: Arkin <arkin@trendline.co.il>
- Date: Mon, 01 Mar 1999 16:01:45 -0500
- To: Lauren Wood <lauren@sqwest.bc.ca>
- CC: www-dom@w3.org
Lauren Wood wrote: > > Arkin wrote: > > > > The application should somehow learn when whitespace appearing in the > > element content is significant or not, and potentially be able to > > control it as it is delivered from the parser. > > So your concrete proposal is that DOM Level 2 Core add something > like an "isignorablewhitespace" property to Text nodes? If you put > your proposals in a concrete form, it does make it easier to > understand precisely what it is that you want. I'm thinking along the following lines: 1. If the DOM Level 2 will cover the parsing/processing API, it could specify how this behavior could be controlled by the application; I would rather see the SAX API being extended and covered by the W3C Options I would cover when defining a parsing API would be: validation, external entity parsing, entity expansion, whitespace removal, etc. 2. The DOM may specify what is the recommended default behavior when producing a DOM tree as a way to clarify inconsistency; not good enough, and only in no. 1 is out of the question That could go in an Appendix, covering implementation details that are outside the document object model, but are affected by it or affecting its use. 3. The DOM may specify a method that removes all ignorable whitespace from elements and their descendants and from documents, on the lines of Element.normalize(), so an application can always call this method when recieving a new document; the benefit is the ability of the application to dump spaces at the element level, or globally for the document 4. As you suggested, a new data type might be introduced which is ignorable whitespace, and NodeIterator could be made to skip over it when iterating the document; this is my least favorite option Arkin > > Lauren
Received on Monday, 1 March 1999 16:07:38 UTC