- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Tue, 31 Jan 2006 04:33:34 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: www-svg@w3.org, www-style@w3.org
* Maciej Stachowiak wrote: >Right now the spec doesn't make clear whether "xml:space" triggers >DOM transformations or not. Does it? > >If you think it should not modify the DOM, but should affect >rendering, then clearly it is a presentational attribute, and should >be mapped to appropriate properties. SVG 1.1 notes that this happens after parsing, after DOM construction and defines things in terms of a copy of the original data, but I see there might still be some doubt. Maybe there should be a note to the effect that this just describes subsequent processing and does not affect what's in the DOM in any way. Regarding style properties, mapping might make sense, but it's still more appropriate to use markup rather than style sheets for this. Let's ignore for a second that XHTML does not allow setting xml:space on most elements, then you might want to use *[xml|space=preserve] { white-space: pre } ... <p xml:space="preserve"> some text here </p> and consider this versus .pre { white-space: pre } ... <p class="pre"> some text here </p> A tool like http://tidy.sourceforge.net/ can easily determine from the markup that it should not mess with the white space in the format XHTML fragment, while in the latter it would have to implement CSS to some extend in order to determine that. Given that the default white space processing rules suggest Tidy can rewrite the latter to <p class="pre">some text here</p> it's likely to do that. If you use e.g. ASCII art, this will totally obscure the text. Of course, maybe <pre> should be used instead, or Tidy should implement CSS, but there is a little bit more than pure style to xml:space. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Tuesday, 31 January 2006 03:32:50 UTC