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

Chris Lilley: > CM>       (a) Render those subsequent lines.
>
> My preference (and avoids having to throw in tspans just to get line breaks)

OK, I think I can go with that.  And we wouldn't want to introduce a new 
<tbreak/> or equivalent element, right -- just suggest using 
white-space:pre-line and newlines in content.

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

We could also put it not exactly on a parallel path, but just a path 
translated by the line height.  Or we could treat it just like with 
normal straight line text by resetting the x position, shifting the y by 
the line height, and then relaying out on the path.  That'd look like this:

   http://mcc.id.au/temp/multipath.svg

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

I actually think this isn't a completely crazy idea, as it's similar to 
how glyphs that extend beyond the end of the path are handled (i.e., 
just dropped).

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

I think one of the reasons we want to move away from xml:space="" is 
that it's really an abuse of the original intention of that attribute. 
 From the "treatment of white space in SVG text rendering" perspective, 
xml:space="default" means something specific, doesn't it?  Not just 
"whatever default behaviour your implementation happens to have".

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

OK, although I didn't intend to suggest xml:space="" be the sole 
presentation attribute for white-space and gain new values.

What about instead we handle it with a UA style sheet:

   svg|text[xml\:space="preserve"],
   svg|tspan[xml\:space="preserve"], ...
   { white-space: pre }

I guess that was the essence of my question; do we need to keep the 
differences between xml:space="preserve" and white-space:pre alive, or 
can we define xml:space="preserve" in terms of CSS white space 
behaviour?  It would be lovely if I could avoid implementing 
xml:space="preserve" on top of white-space processing. :)

But I would like xml:space="default" to mean "do what the white-space 
property says".  white-space:normal is still different from 
xml:space="default", because the latter will remove newline characters 
while the former will turn them into a space.

If we had to keep xml:space="default" behaviour, then I am not sure how 
authors are going to opt in to having the white-space property handle 
things rather than xml:space="".

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

I'm working under the assumption here that we need to keep 
xml:space="preserve" doing some kind of white space preservation going 
forward.  I'm right in that, yes?

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

Sure, we should definitely have those.  (And the white-space shorthand 
presentation attribute, like we've discussed for font.)

Received on Saturday, 17 March 2012 03:26:19 UTC