W3C home > Mailing lists > Public > www-svg@w3.org > March 2012

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

From: Chris Lilley <chris@w3.org>
Date: Fri, 16 Mar 2012 14:33:54 +0100
Message-ID: <184993186.20120316143354@w3.org>
To: Cameron McCormack <cam@mcc.id.au>
CC: SVG public list <www-svg@w3.org>
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.



-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Friday, 16 March 2012 13:34:01 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:50 GMT