- From: Chris Lilley <chris@w3.org>
- Date: Fri, 16 Mar 2012 14:33:54 +0100
- 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 UTC