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

On Jan 30, 2006, at 7:33 PM, Bjoern Hoehrmann wrote:

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

The 1.2 spec also says the rules do not affect the DOM, I simply  
missed this before. Nontheless, given these rules, I think defining  
the behavior in terms of properties is a no-brainer.

> Regarding style properties, mapping might make sense, but it's still
> more appropriate to use markup rather than style sheets for this.

If the mapping is there, this would be up to authors, which is fine  
by me. Although if "xml:space" has effects on text rendering that  
differ per language, using it in a CDF context would be extremely  
tricky.

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

Both are bad form in my opinion. The <p> element should specify a  
semantic class, or an appropriate semantic element should be used. A  
presentational class or a presentational attribute are both subpar.  
For example <p class="verse"> if you mean to be writing poetry, or <p  
class="ascii-art">.

Note also that "white-space: pre" is not compatible with what SVG  
specifies for xml:space, so without knowing the language you wouldn't  
be able to know what xml:space does with the whitespace. For example,  
if instead of <html:p> your example was an <svg:text>, then doing the  
transform below would be perfectly legitimate in the face of xml:space.

> 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.

You can't correctly mess with the text in HTML at all unless you  
implement CSS and how how HTML presentational attributes are mapped.  
And even if you can figure out the current whitespace mode, the  
author may later use a different stylesheet, or may change the white- 
space mode via script, or may transform the document via XSLT.

So if a tool wants to mess with your whitespace, it simply cannot  
avoid the possibility that it will break some documents.

Regards,
Maciej

Received on Tuesday, 31 January 2006 07:14:20 UTC