Comments on textArea vs flowText

Hi all,

    I am deeply concerned about the changes to flowing text
that the SVG 1.2 Tiny Last Call introduces.  This concern
lies on several fronts.  The biggest concern for me, as has
been echoed in other people, is the possible loss of functionality.
Now I know that members of the WG have "promised" that almost
all of the functionality will be added back for the full
release, but this is in my opinion unacceptable.  What does
'almost' mean?  Can we have a concrete proposal?

    Implementors and users have been able to look at implement
and  use the flowText element as specified by the WG in the
last several releases of the specification (covering several
years).  I can count at least four fairly complete implementations
of the feature (ASV 6, Batik, InkScape and BitFlash).  Now however we
are told that it is moving in a new direction with the textArea and we
have essentially nothing we can use to compare the full flowText
against.

    I personally am _very_ concerned about giving the change
to textArea a pass with no concrete proposal for how  it will
be extended to handle the use cases that flowText handled.  In
particular it is unclear how a textArea element will be extended to
handle multiple flow regions with excludes. If it will support out of
order rendering (the flowRef element). There is no guidance given to
implementations as to a suggested set of CSS properties to implement
(if there are any).

    So far the major feature that was listed as being dropped
was the notion of paragraphs, on the grounds that this violates
some taboo on "semantics".  However, I would contend that
this is _required_ for proper handling of international text.
The first step in UAX-9 (http://www.unicode.org/unicode/reports/tr9/)
is splitting the text into paragraphs so the default embedding
level can be determined.

    I am not sure how the SVG WG anticipates user agents to implement
properties like 'text-align' properly without a proper embedding level.
However, since I can't find any mention of text-align in
the Tiny spec perhaps this feature was also dropped?  Or is
there some assumed list of CSS properties which are currently
unlisted which are expected to be implemented by UA's? Is there
a missing description of how text-anchor is supposed to apply
to blocks?  It would be very disappointing if such a basic feature
(that is also almost trivial to implement for rects) were
dropped from the specification.

    Going in another direction, one of the few objections to the
old text wrapping proposal that I considered legitimate was the
possibility that existing XHTML/CSS text layout engines might find
the layout model of flowText incompatible (something I didn't agree
with, however it was a legitimate concern).  However, it seems quite
clear to me that the new "simplified" line height calculation (the
'line-increment' property) is a significant step in the wrong
direction. While it may be _very_ slightly simpler it is fairly
divergent from the CSS line-height property.  The ironic bit is
that this is just about the only piece of layout that implementations
are required to follow.

    Over all I get the impression that textArea provides
facilities that are just shy of what is needed to actually
be useful in the majority of 'real world' situations.  Missing
things like text-indent, and margin (or it's equivalent) are likely
to be problematic (margin isn't such a big deal for rects but for
flowing in complex geometry you need a way to 'inset' content from
the edges).

    Many of these could be worked around using script or convoluted
text structures (e.g. using 'dx' for text-indent, providing an inset
version of the geometry), however the results would make the
language cumbersome to use, lead to poor support for BIDI
(will people reverse 'dx' for RTL?) and more or less makes it
feel only a touch better than the current solution of absolutely
positioning text with tspan's and x/y.  Also the abandonment of
any sort of baseline for layout means that a compliant rendering
engine could even go as far as not even doing the simplest word
breaking.  Making this feature, in the worst case, no better
than textPath!

    This change would probably not be as disappointing if it
weren't for the fact that flowText was probably the most widely
implemented of all the SVG 1.2 features.  A lot of implementation
and usage experience was developed for flowText, much of which
will need to be redeveloped for textArea. I'm especially
concerned about the usage experience since that necessarily lags
implementation, and in my opinion a number of important features have
been removed that will make the usage of textArea in the real world much
more difficult than flowText.

Received on Friday, 29 April 2005 14:20:28 UTC