- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 2 Jan 2006 03:00:45 -0800
- To: Jon Ferraiolo <jonf@adobe.com>
- Cc: www-svg@w3c.org
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