- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Sat, 31 Dec 2005 08:00:01 -0800
- 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 UTC