Re: moving from xml:space="" to white-space

Isn't there a fundamental difference between XML "xml:space" attribute and
CSS "white-space" property: the former instructs DOM implementation to
preserve or not white space characters in the "Content Tree" while the
later suggests rendering engine to create or not boxes for white space
characters in the "Render Tree" (in browser terms)?

Given the two mechanisms serve unrelated purposes, neither can be
deprecated, removed or merged.

Regards,
Sergey/



On 16 March 2012 20:10, Doug Schepers <schepers@w3.org> wrote:

> Hey, Cam, Chris-
>
> Just to chime in, I agree with Chris on every point.
>
> I'm not worried about the legacy of 'xml:space', and don't feel there
> should be any mapping.  In the future, 'white-space' and pals should be the
> way to handle all of this, and the weird use of 'xml:space' by SVG1.1
> should be deprecated.
>
> Regards-
> -Doug
>
>
> On 3/16/12 9:33 AM, Chris Lilley wrote:
>
>> On Friday, March 16, 2012, 2:59:18 AM, Cameron wrote:
>>
>> CM>  As part of aligning with CSS text handling, SVG 2 is going to
>> support CM>  (and recommend) the use of the white-space property to
>> control whether CM>  white space characters are collapsed in
>> SVG<text>  elements or not.  I CM>  have a couple of questions about
>> this:
>>
>> CM>  1. What is the expected behaviour for the following:
>>
>> CM>      <text style="white-space: pre">a CM>      b</text>
>>
>> CM>      Would we want to allow a line break there?
>>
>> We wouldn't want to disallow it
>>
>> CM>  If we do, how does that CM>      sit with our decision not to
>> include SVG Tiny 1.2's<textArea> CM>      element in SVG 2?
>>
>> Unrelated; one is doing the wrapping by itself, one is honouring text
>> breaks created by the author.
>>
>> CM>    I seem to remember a proposal at some point to CM>
>> extend<text>  with a width="" attribute, like
>>
>> CM>      <text x="10" y="10" width="100">some text that would
>> wrap</text>
>>
>> CM>      but I don't know what came of that.  Regardless, we have a
>> few CM>      options:
>>
>> CM>        (a) Render those subsequent lines.
>>
>> My preference (and avoids having to throw in tspans just to get line
>> breaks)
>>
>> CM>  (What happens on a text path?)
>>
>> We have several options for text path
>>
>> - disallow breaks - ignore breaks if it is on a path - try to put
>> text on parallel paths (hard) - say its undefined (yuk)
>>
>>
>> CM>        (b) Treat the newlines as white space, like
>> xml:space="preserve" CM>            does.
>>
>> Not a good idea.
>>
>> CM>        (c) Don't render any line after the first.
>>
>> Really not a good idea.
>>
>>
>> CM>      I'm not really sure which I like.  (a) has the advantage of
>> probably CM>      doing what the author wanted.  (b) has the
>> disadvantage of changing CM>      what white-space:pre really means.
>> (c) seems like it would never CM>      be what the author wants.
>>
>> CM>  2. Are we able to make xml:space="" a presentation attribute for
>> the CM>      white-space property?
>>
>> No.
>>
>> Firstly, because it is sort-of-similar, but if it was *that* similar
>> we would be keeping on using it. Instead, it has only one real value,
>> preserve, and a second useless value that means 'do whatever you
>> do'.
>>
>> Secondly, because its is not our attribute; it belongs to the xml
>> namespace and we can't, for example, add new values. Thus, we should
>> not promote it to a property, either.
>>
>>
>>
>> CM>   Its behaviour does not exactly match any of CM>      the
>> current white-space property values,
>>
>> Right
>>
>> CM>  but I am wondering if it CM>      is that important to preserve
>> those differences from CM>      white-space:pre.
>> xml:space="preserve" is defined to convert CM>      each tab and
>> newline into a space.  If we could make it map exactly CM>      to
>> white-space:pre instead that would be good.
>>
>> Or we could have (one or more) presentation attribute(s) that do(es)
>> exactly the right thing instead of continuing to try and bend
>> xml:space into shape.
>>
>> CM>  This doesn't affect anything,
>>
>> It does, really
>>
>> CM>  but I just noticed css3-text defines CM>  white-space as a
>> shorthand property for text-space-collapse (which gives CM>  the
>> collapsing behaviour) and text-wrap (which gives the line breaking
>> CM>  behaviour).
>>
>> Yes. Which means that the two presentation attributes should be
>> called text-space-collapse and  text-wrap.
>>
>>
>>
>>
>
>