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

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

Received on Friday, 16 March 2012 18:11:01 UTC