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

Hi Jon,

First, I'd like to note that my name is "Maciej", not "Marcel". My  
name is often misspelled, so I am not gravely offended, but I'd  
appreciate it if you spelled it right in the future. :-)

I'm glad you agreee that using "xml:space" was a mistake, and that at  
some future point the w3c should harmonize whitespace handling across  
all interaction domain languages.

I think the right time to do this is now, and the right group within  
the w3c to do it is the SVG working group. The reasons I say this are:

- Other Interaction Domain languages are already harmonized or  
harmonizing on this front, so far as I know. SVG is the odd duck.
     - The XSL whitespace properties you mention are being folded  
into and being revised via CSS3 Text Effects Module properties.
     - The CSS 2.1 whitespace properties can all be defined in terms  
of the CSS3 whitespace properties.
     - HTML whitespace effects are all now defined in terms of CSS.
     - I don't know of any other W3C languages that define odd  
whitespace behavior.

- The use of SVG combined directly with other languages is about to  
get way more popular, making it imporant for SVG to play well with  
other W3C languages.
     - The CDF working group is defining standards for this.
     - Mainstream UAs, including Mozilla Firefox, Opera and Safari,  
are in the process implementing SVG in direct combination with (X) 
HTML and CSS.

- Better to resolve this for SVG 1.2 than to wait until 1.3, which  
may be a long time coming.

Therefore, I formally rquest that the SVG working group coordinate  
with other WGs to harmonize whitespace behavior with other W3C  
languages for SVG 1.2. I request that the solution meet those  
following requirements:

- "xml:space=pre" is clearly specified to affect only rendering and  
certain SVG APIs, but not the characters present in the DOM.
- use of "xml:space=default" is deprecated; since it is woefully  
underspecified by the XML standard, it would be a huge burden on XML  
parsers in multi-language UAs if it became commonplace for different  
languages to define behavior for this in their own way. It can be  
removed in a future version.
- whitespace rendering behavior for "xml:space=pre" is defined in  
terms of properties, ideally using standard properties from other w3c  
languages where possible.
- interaction with normal whitepsace properties is defined, so that  
SVG text can be styled with CSS.

I think it is possible to meet these requirements without breaking  
compaibility with previous SVG versions, which appears to be a major  
concern for you. If it would help, I can come up with a strawman  
proposal for how this could be done. But it is a lot of work to write  
a description that is tight enough for use in a standards document,  
so I'd rather leave this up to the relevant working groups.

Regards,
Maciej


On Dec 31, 2005, at 8:00 AM, Jon Ferraiolo wrote:

>
> 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 Monday, 2 January 2006 11:00:53 UTC