Re: SVGT 1.2: A proposal for how to define SVG whitespace in terms of CSS whitespace

On Jan 30, 2006, at 7:30 PM, Jon Ferraiolo wrote:

> For better or worse, the rules for SVG 1.0/1.1 are that the XML parser
> is not expected to do any special SVG-specific processing on text  
> nodes,
> no matter what the value is of xml:space, but instead that the SVG  
> UA is
> expected to collapse out white space within text nodes before SVG's
> particular rules for single-line layout per
> http://www.w3.org/TR/SVG11/text.html#WhiteSpace. Pay close  
> attention to
> the sentence:
>
> "... These are behaviors that occur subsequent to XML parsing [XML10]
> and any construction of a Document Object Model [DOM2]."

All right, I consider that "for better". The language in SVG 1.2 was  
not that clear to me. Note that my proposal is for 1.2, not 1.1.

> While there are probably thousands of better approaches to white space
> handling than what was chosen for SVG 1.0/1.1, it is too late to  
> change
> them now (e.g., changing the default from "default" to "preserve").  
> Many
> viewers, larger numbers of authoring tools, and even larger numbers of
> SVG web pages have been written to follow the SVG 1.0/1.1 rules.

Then the default doesn't have to be changed - I think the rest of my  
proposal would still apply. Again, this is just my first cut at a  
proposal. My request that the SVG WG solve this in coordination with  
the CSS WG still stands, regardless of whether my specific proposal  
is any good.

> The time to change SVG's white space handling rules is when the W3C
> mounts an effort to unify white space handling rules across its many
> document formats (HTML/CSS, XSL-FO, SVG, MathML, XForms, ...), and  
> once
> the unified approach to white space handling is defined, all of the
> formats, including SVG, should adopt the new rules.

This doesn't make sense to me. If it is "too late" to change SVG's  
whitespace rules now, how can it not be too late at an unspecified  
much later time? And if current extent of adoption makes it hard to  
change, then SVG had better align itself with other languages now,  
before extent of adoption becomes even greater. But in practice I do  
not think my proposal will create much of a compatibility problem.  
Rendering behavior would remain the same for all xml:space modes. If  
you can think of specific compatibility issues it will raise, please  
explain what the problem is.

Furthermore, I don't believe SVG 1.2 as currently written is either  
forwards or backwards compatible with 1.1, so both UAs and authoring  
tools will have to change in any case; therefore I think even if  
there were a change of behavior it would not be a showstopper.

>  If/when such unification is pursued seriously, I nominate the XSL- 
> FO white space properties for consideration.

The XSL-FO white space properties are a subset of the CSS3 draft  
properties which I referenced in my message. Now seems like a great  
time to pursue this.

Regards,
Maciej



>
> Jon
>
>
>
> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Of Maciej Stachowiak
> Sent: Monday, January 30, 2006 7:07 PM
> To: Ian Hickson
> Cc: www-svg@w3.org
> Subject: Re: SVGT 1.2: A proposal for how to define SVG whitespace in
> terms of CSS whitespace
>
>
>
> On Jan 30, 2006, at 3:34 PM, Ian Hickson wrote:
>
>>
>>
>> (SVGWG, please consider this one of my last call comments.)
>>
>> On Sat, 14 Jan 2006, Maciej Stachowiak wrote:
>>>
>>> Here's my proposal for how to change this.
>>>
>>> * The default setting for xml:space for SVG elements is "preserve".
>>
>> I don't understand what this means. Since SVG 1.2 has no DTDs, it
>> can't
>> default attributes, and XML 1.x provides no other mechanism for
>> changing
>> the "default setting" of its attributes. (By default, xml:space is
>> not set
>> on any elements, and inherits.)
>>
>> What you probably want to say is just that "all whitespace in the
>> markup
>> must be preserved during parsing", without reference to xml:space
>> at all.
>>
>> Note that in existing XML parsers in Web UAs, xml:space has no  
>> effect,
>> because the default value (unspecified), the "default" value, and the
>> "preserve" value, all have the same effect. It would be extremely
>> bad for
>> the SVG specification to require that XML parsers be aware of the SVG
>> namespace when creating the DOM.
>
> I that case, here's some alternate proposals:
>
> A) When xml:space is not specified, the document should be preserve
> all whitespace, and in general act as specified for
> xml:space="preserve".
>
> B) SVG could add a DTD or some other mechanism to set a default value
> for the attribute.
>
> C) If xml:space="default" is defined to not modify the text in the
> DOM but only apply styling, then there is no need to set a default
> value or define what any of the values do to parsing.
>
> Regards,
> Maciej
>
>

Received on Tuesday, 31 January 2006 06:55:34 UTC