RE: Comments on textArea vs flowText

Hi, WG-

As usual, Thomas' perspective as an implementor and his keen insight speak
more eleoquently than I can about the issue of flowing text, but I would
like to add in my two cents to support his overwhelmingly sensible argument.

I have chimed in before about the notion of semantics and their place in W3C
specs. To reiterate, I do not think that HTML has a lockdown on text
semantics. Most of the data that is dealt with on the Web is textual in
nature, and there may be many differing needs in presentation of that data.
Speaking as one who has studied linguistics, let me asssure you that HTML's
semantics are woefully inadequate. It does a passable job on superficial
European-style text presentation, but what about for othographies that use
utterly different layout schemes, such as those that don't use paragraphs,
for example? Or that have features not in Western orthographies? Far better
to allow text semantics to be defined for each orthography, and try to
create a schema in some presentation markup language (hey, how about SVG?!)
that is flexible enough to allow enforcement of those rules.

Also, the argument that SVG's flowing text is too much like HTML's is at
odds with the alternate claim that browsers need to be able to implement
only one flowing text mechanism. So what if there is some duplication? Why
be utter purists to the point of impracticality; these specs are meant to be
useful for real people, are they not?

And again, to underscore Thomas' point, what if I am writing in, say,
English and want to have a funky-phat-neato layout for my text, such as an
ad company or design firm might like? We need areas of combination and
exclusion. HTML *cannot* and *should not* be the place to do this, even in
the context of compound docs.

Don't underspecify an inadequate substitution for what has already been
designed and implemented. That would really kill the usefulness of SVG.

Regards-
Doug

doug . schepers  @ vectoreal.com
www.vectoreal.com ...for scalable solutions.
 

| -----Original Message-----
| From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] 
| On Behalf Of Thomas DeWeese
| Sent: Friday, April 29, 2005 10:20 AM
| To: www-svg@w3.org
| Subject: 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.
| 
| 
| --
| No virus found in this incoming message.
| Checked by AVG Anti-Virus.
| Version: 7.0.308 / Virus Database: 266.11.0 - Release Date: 4/29/2005
|  
|

Received on Friday, 29 April 2005 21:51:04 UTC