W3C home > Mailing lists > Public > www-svg@w3.org > December 2005

RE: [SVGMobile12] SVGT12-207: use of xml:space for whitespace

From: Jon Ferraiolo <jonf@adobe.com>
Date: Sat, 31 Dec 2005 08:00:01 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C84F846A@namail3.corp.adobe.com>
To: "Maciej Stachowiak" <mjs@apple.com>, <www-svg@w3c.org>

Marcel,
I was involved in the definition of SVG 1.0 back in 1998-2001, the time
when SVG's rules for xml:space were defined. Now, at the end of 2005, I
am in general agreement that it was a mistake for the SVG language to
use xml:space as its syntax for controlling the treatment of white
space. You suggest that CSS's white-space property might have been a
better alternative, and looking back, perhaps that would have been
better. 

However, it is about 5 years too late for this feedback. The decision
about xml:space vs. CSS's white-space property vs. XSL-FO's white space
features (linefeed-treatment, white-space-collapse,
white-space-treatment, wrap-option:
http://www.w3.org/TR/xsl/slice7.html#white-space) vs other possible
options was made by the original SVG Working Group in 1998-2001, went
through various last calls (including specific feedback on xml:space
from the internationalization interest group, particularly regarding
Japanese/Chinese text), candidate recommendations, and ultimately was
approved by the Director as a Recommendation. Note that nothing has
changed with xml:space from Tiny 1.1 to Tiny 1.2, and in fact nothing
changed with xml:space from SVG 1.0 to Tiny 1.1.

xml:space has now been implemented by scores of companies. I would
estimate thousands of web sites depend on SVG's rules for xml:space
somehow or other. There is a large amount of SVG content deployed on web
sites which was originally created in Adobe Illustrator, which puts
xml:space="preserve" at the top of every SVG file it exports. At this
point, it is much too late to change SVG's rules about xml:space. 

One idea for the future would be to have the W3C look at white space
handling rules on a comprehensive basis across its Interaction Domain
and find a consistent way of handling white space across all of its
languages, where all languages adopt the new approach and define how to
map their existing white space handling rules into the unified approach.
The four white space handling properties in XSL-FO (linefeed-treatment,
white-space-collapse, white-space-treatment, wrap-option) would be a
good starting point.

Jon Ferraiolo
Adobe Systems, Inc.


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Maciej Stachowiak
Sent: Wednesday, December 28, 2005 7:39 PM
To: www-svg@w3c.org
Subject: [SVGMobile12] SVGT12-207: use of xml:space for whitespace



This is regarding section 10.10.

- It seems like a bad idea to turn xml:space into effective a  
presentational attribute for SVG, instead of using a property along  
the lines of the CSS white-space property.

- The behavior specified for "default" is different than normal CSS  
whitespace collapsing with regards to line-breaks. Line-breaks are  
removed rather than collapsing to a space. I think it is surprising  
that:

<text>
one
two
</text>

Will result in the single word "onetwo" being displayed.

- It is unclear what to do in default mode with a text run that  
consists solely of whitespace. Does it collapse to nothing, because  
"Then, it will strip off all leading and trailing space characters"  
or does it collapse to a single space because "Then, all contiguous   
space characters will be consolidated"? It sounds like the former is  
more likely, but this too seems surprisingly unlike CSS whitespace  
collapsing.

- "preserve" mode does not in fact preserve tabs or for that matter  
newlines, unlike the "white-space: pre" property from CSS2 or "white- 
space-collapse: preserve" from CSS3 text effects.

- "Any features in the SVG language or the SVG DOM that are based on  
character position number are based on character position after  
applying the white space handling rules described here." It should be  
clarified that this does not refer to standard w3c DOM APIs, for  
example the interface to text nodes in DOM Core, or DOM Range.

Regards,
Maciej
Received on Saturday, 31 December 2005 17:08:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:32 GMT