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

Hi Maciej,
Sorry about messing up your name. I should be sensitive to that, given
that both of my names tend to be misspelled.

I think you make many good points. I can't speak for the SVG WG, but I
can guess that the SVG WG will feel it is not necessary to reconcile
SVG's white space features with CSS at this time. Such a reconciliation
probably makes more sense for SVG Full 1.2 than for SVG Tiny 1.2. There
has been lots of feedback on this list from web browser implementers,
such as Apple, which is fantastic, but it should be pointed out that the
constituency which has the longest standing demand for SVG Tiny 1.2 and
who have been the main contributors within the WG is the mobile
industry, which is looking for a "tiny" version of SVG which will fit on
a wide spectrum of constrained devices and not optimizing as much around
sharing code across HTML and SVG engines. In fact, one key workflow on
mobile devices is the integration of SVG with Java via JSR-226, where
Java applications use SVG as a graphics subsystem. From what I hear,
there are a large number of mobile devices that will be shipping in 2006
with JSR-226 support. In this workflow, HTML and CSS engines do not get
invoked. Thus, it might be sufficient to define a mapping from SVG's
xml:space feature into a consolidation with CSS3's white space
properties to make sure there is forward compatibility, but not enhance
SVG Tiny 1.2 to support CSS3's white space properties.

I think you make a very interesting comment below:

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

Note that the SVG WG consists of (what is basically) volunteers from
organizations. In the case of the SVG WG, most of the work is done by
volunteers from major companies who are attempting to implement and ship
SVG software. As such, strawman proposals or any other submissions from
the public are very welcome.

Jon

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Monday, January 02, 2006 3:01 AM
To: Jon Ferraiolo
Cc: www-svg@w3c.org
Subject: 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 16:20:40 UTC