- From: Chris Lilley <chris@w3.org>
- Date: Mon, 19 Mar 2012 19:02:54 +0100
- To: Cameron McCormack <cam@mcc.id.au>
- CC: SVG public list <www-svg@w3.org>
On Saturday, March 17, 2012, 4:25:42 AM, Cameron wrote:
CM> Chris Lilley: > CM> (a) Render those subsequent lines.
>> My preference (and avoids having to throw in tspans just to get line breaks)
CM> OK, I think I can go with that. And we wouldn't want to introduce a new
CM> <tbreak/> or equivalent element, right -- just suggest using
CM> white-space:pre-line and newlines in content.
Good point. You can get the line break preserving without having to force monospaced text.
>> 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> We could also put it not exactly on a parallel path, but just a path
CM> translated by the line height.
That would be way simpler to implement and probably look like a train wreck. Which may be ok if the spec says "don't do this" and the implementation needs to do something when people do.
CM> Or we could treat it just like with
CM> normal straight line text by resetting the x position, shifting the y by
CM> the line height, and then relaying out on the path. That'd look like this:
CM> http://mcc.id.au/temp/multipath.svg
Hmm that looks better actually.
>> 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 actually think this isn't a completely crazy idea, as it's similar to
CM> how glyphs that extend beyond the end of the path are handled (i.e.,
CM> just dropped).
True. OK.
>> 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'.
CM> I think one of the reasons we want to move away from xml:space="" is
CM> that it's really an abuse of the original intention of that attribute.
CM> From the "treatment of white space in SVG text rendering" perspective,
CM> xml:space="default" means something specific, doesn't it? Not just
CM> "whatever default behaviour your implementation happens to have".
From an xml perspective, it really is that vague and processor specific. From an SVG 1.1 perspective, SVG tried to get some value out of the attribute but it is really at the wrong level.
>> 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> OK, although I didn't intend to suggest xml:space="" be the sole
CM> presentation attribute for white-space and gain new values.
CM> What about instead we handle it with a UA style sheet:
CM> svg|text[xml\:space="preserve"],
CM> svg|tspan[xml\:space="preserve"], ...
CM> { white-space: pre }
CM> I guess that was the essence of my question; do we need to keep the
CM> differences between xml:space="preserve" and white-space:pre alive,
No, I don't think so.
And remember that we removed the xml:space tests from the SVG 1.1SE test suite, because we did not want to force implementations to do it.
CM> or
CM> can we define xml:space="preserve" in terms of CSS white space
CM> behaviour? It would be lovely if I could avoid implementing
CM> xml:space="preserve" on top of white-space processing. :)
I would suggest just ignoring xml:space as the two values, in modern xml parsers, mean the same thing.
>> 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> I'm working under the assumption here that we need to keep
CM> xml:space="preserve" doing some kind of white space preservation going
CM> forward. I'm right in that, yes?
I am not making that assumption.
>> Which means that the two presentation attributes should be called text-space-collapse and text-wrap.
CM> Sure, we should definitely have those. (And the white-space shorthand
CM> presentation attribute, like we've discussed for font.)
Right.
--
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 Monday, 19 March 2012 18:02:55 UTC