Re: Wrapping Text in SVG

Doug Schepers :
> Hi, Dr. Olaf-
>
> On 6/4/13 5:22 AM, Dr. Olaf Hoffmann wrote:
> > to fit text into a rectangular area, the approach of
> > SVG tiny 1.2 textArea is already not bad - why not
> > to continue with this?
>
> <svg:textArea> has several logistical problems:
>
> 1) Its name conflicts with the HTML <textarea> element, and it compounds
> this by having different functionality than <textarea>; this will make
> it confusing for authors, and makes parsing SVG in HTML (a very common
> case today, with script libraries like D3.js and Raphael) much harder (I
> suspect browser vendors would not implement this, because of the parsing
> conflict);

Compared to XHTML textarea it has another name ;o)
As you know, there are already elements with different
meaning and the same name in SVG and (X)HTML.
And it is in another namespace, therefore no real problems.
And textArea is already in the SVG namespace, therefore
a little bit late now to care about such HTML5-specific problems.
If authors want to to provide meaningful content, they should
not use HTML-tag-soup ;o)
But without caring about backwards-incompatibilities to
previous SVG recommendations, one can of course chose
another name ...

>
> 2) It doesn't provide a fallback, and does not degrade gracefully in
> older user agents; if an SVG UA (browser) doesn't know the
> <svg:textArea> element, it will simply not render the text, which is the
> worst option. In my proposal to extend the functionality of <svg:text>,
> if the browser doesn't know how to apply the 'width' property to
> <svg:text>, it will still render the text as a straight line; this is
> not a great fallback, but it's much better than not rendering anything
> at all (at least in most cases); 

It is more an indication for readers, that they have to use either another
viewer or that they have to look into the source code to get what was
intended. 
Not sure, that authors really need such a poor fallback here.

> you could use <switch> for this, but 
> that's a clumsy construct most people don't know and won't bother with;

You need it anyway to provide a manually wrapped text,  a foreignObject
with CSS-styled XML text content or a link to an XHTML file with the text to
provide an meaningful fallback.

But indeed, most authors will not care about fallbacks anyway, one only
has to provide such a tool for a minority - and typically such people
will not be satisfied anyway with text in one line as a fallback.


>
> 3) SVG Tiny 1.2 defines a specific text layout algorithm [1], which on
> the face of it seems smart and responsible, but in this instance, it may
> cause conflicts with the existing engine-based text-layout mechanisms in
> browsers today; for all I know, the SVGT algorithm is largely compatible
> with existing browsers, since CSS does not actually define text layout,
> but in the past, this has been a source of some contention with browser
> vendors, and the suggestion that they subscribe to SVGT's text-layout
> algorithm is likely to be rejected; the algorithm also defines behaviors
> for certain properties that are indeed likely to not perfectly match CSS
> (being based on XSL), and this would add to the difficulty of
> implementation. The path of least resistance toward text-wrapping in SVG
> is to reuse existing CSS code-bases;
>

Why did it reach with SVG tiny 1.2 the status of a recommendation?
A simple alternative could be to write, that user-agents at least have to
display CSS-styled XML text content in foreignObject with a subset
of some CSS properties. Often there is no need for additional 
functionality beyond presentation for such texts and this would be a 
good method to provide general simple text fallbacks in many cases.
If one already starts to require another content model for text with
automatic wrapping in SVG and CSS like presentation, it looks ok 
to require to have this model available for arbitrary 
XML inside foreignObject for presentation.


> 4) It has a few minor warts: the camelCased tag name is out of fashion,
> and error-prone (I've been bitten by viewbox/viewBox myself several
> times); it uses 'xml:space' in a way that we know is an abuse;
>

There are several of such attributes and elements in SVG and
other languages as well, nothing to worry about.
And for longer names this notation is better readable.
If you start to change SVG names according to the fashion
of the year, I think, this will be the end of this language.

>
> I want to note that I actually quite like most of the way <svg:textArea>
> is defined, and I would like for CSS to adopt some of its
> characteristics, including a well-defined text-layout algorithm and the
> XSL-based, internationalization-friendly layout properties. It's just
> that it's not pragmatic to insist on <svg:textArea> when there is likely
> to be well-justified resistance, and I want to meet the needs of authors
> in a short timeframe more than I want to see the "best" solution win; in
> this case, compromise also has other benefits, because CSS offers a very
> workable and familiar model that will help CSS experts adopt SVG.

Well, several parts of SVG 1.0/1.1 have not been implemented widely
or correctly for more than 10 years.
I think, there is no need to hurry with SVG 2 now ;o)
The best solution has potential for the future,
a fast simple solution will always cause problems and annoyance
in the future ...

>
> I also want to point out again that Tav's proposal for text layout into
> arbitrary shapes, using CSS conventions wherever possible, is also quite
> good, and he and I believe it is complementary to what I'm proposing. In
> fact, my simple text-wrapping proposal would be a good fallback for the
> more advanced shape-wrapping that Tav is describing.
>
> Does all this seem reasonable to you?

I think, such a rectangular area is just a general case of this more
interesting and complex feature.
But because we can assume, that this simple case will be much 
more used, it is ok to provide a specific element for this simple 
case as we have rect, circle, ellipse etc as specific shapes compared
to the additional available option to specify arbitrary path data.
And implementors can start to get experience with such
a feature with the simple case. 
If they manage this, in a second step they can try to do
it for the more general case.

>
> > But what one needs additionally, from my point of view:
> > a) overflow: scroll and overflow: auto for text boxes
> > with a behaviour as known from ordinary CSS.
>
> Agreed. Cameron mentioned this during the telcon (well, F2f, but I was
> not there, so I dialed in), and it seems sensible to me.
>
> > b) Additionally an alternative approach for the
> > situation, that the text with line wrapping does
> > not fit into the rectangular box.
> > To be able to have a method to adjust the
> > font-size automatically would be a good
> > idea, for example a property named
> > scale-font-size with values like auto,
> > resize,  reduce,  increase, none.
> > reduce only applies in case there is a
> > need to reduce the font-size, that the
> > text fits into the box.
> > increase only applies to in case there
> > is a need to increase the font-size,
> > that text fits into the box.
> > resize fits in both cases the text into
> > the box.
>
> We talked about this during the telcon, and Tab suggested that we use
> percentages for this; if we define a width and height for <svg:text>,
> then we can also define a way for 'font-size' percentages to fill that
> space.

Doesn't font-size="140%" already have a defined meaning?
I think, a specific attribute/property to indicate the intended 
automatic scaling would be much more useful, especially
because with this authors can decide what to do for different
cases - more text than space or less text than space as
already described.

>
> Tab also mentioned that CSS was looking at a more advanced way to do
> this, and we could simply use what they create.
>

One has to see, it this is meaningful, if applied to the
different document model of SVG.

>...


Olaf

Received on Thursday, 6 June 2013 08:40:29 UTC