Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace

* 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">

and consider this versus

  .pre { white-space: pre }
  <p class="pre">

A tool like 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
Björn Höhrmann · ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

Received on Tuesday, 31 January 2006 03:32:50 UTC