Re: Comments on SVG 1.2 from a Gecko developer

Doug Schepers wrote:

>I don't think you got the proper reading from this. In section "3.1.12 Text
>Flow", item #7:
>  
>
You're right, I was mistaken. Thanks for clearing that up.

>| It seems to me that the basic ideas behind SVG 1.2 text flow 
>| could be easily adapted to CSS. You could solve the 
>| line-height determination problem by requiring that for 
>| elements flowing inside a shape, the CSS3 
>| line-stacking-strategy property be treated as "block-line-height".
>| http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#LineStacking
>| Then you can compute the text regions for a line just like 
>| you do here in SVG 1.2. We already know how to place a line's 
>| inline boxes offset from the left and right edges of the 
>| block (to handle floats). Handling discontiguous text regions 
>| shouldn't be too hard (providing the behaviour of 
>| text-align:justify is specified, which it doesn't seem to be 
>| in this case in SVG 1.2). Placing floats might be 
>| troublesome. But we already have to place floats adjacent to 
>| other floats so it might not be too much extra work. Or, you 
>| could state that floats are not allowed inside SVG text flows 
>| at this time.
>
>I don't understand the need to try to put this into CSS. That would cause a
>terrible delay in the release of this functionality, when it's already
>defined very well in SVG as it is. If someone wants to use flowtext in an
>XHTML page, why not simply use an SVG block (either an embed, iframe,
>object, or a hopefully-functional mixed-ns section)? This solves the problem
>of fonts, precision text layout, and several other issues.
>  
>
The author then has to use a completely different set of text elements, 
just because they wanted this one feature. All DIVs inside the shaped 
region have to be converted to svg:textDiv, all Ps convert to 
svg:textPara, etc, and stuff like floats or anything else that the SVG 
WG saw fit to not support doesn't work at all.

But my wish is not primarily to make this available to XHTML users, my 
wish is to avoid duplication of markup languages, specification and 
implementation caused by having two separately specified text layout 
engines under the rubric of the W3C.

>| I'm not ready to comment on the details of the APIs. However, 
>| I think you could address the namespace issues and deflect 
>| concerns about scope creep by 1) creating a 
>| Web-applications-nursery namespace and putting the extensions 
>| there and 
>
>I have reservations about this. If control of their development is placed
>outside the charter of the SVG WG, the subsequent politics would essentially
>mean the death of these features. If this could be done without removing
>them from SVG WG development, and still passing them on to Recc status with
>the rest of SVG 1.2, I'd be fine with it, but I am far from the only one who
>wants these features ASAP.
>  
>
I was suggesting that this remain under the control of the SVG WG for 
the 1.2 timeframe at least.

>| 2) putting the extensions in their own section of 
>| the SVG draft, clearly separating them from "SVG proper", and 
>| explaining that the hope is to migrate them to a broader Web 
>| applications forum at a later date.
>
>That seems sensible, if the only intent is to modularize them, and not to
>yank them from the SVG1.2 Recc.
>  
>
The intent would be to modularize them and make them eventually 
separable from the SVG WG --- *eventually*.

Maybe you guys don't realize this, but there's a serious guffaw factor 
when outsiders read through the SVG spec and find the "Scalable Vector 
Graphics" group developing networking APIs. I understand the need for 
you to do this, but clearly marking such APIs as destined for another 
forum would help fix that perception and add to your credibility.

Rob

-- 
Robert O'Callahan <robert@ocallahan.org>
"Here is a trustworthy saying that deserves full acceptance: Christ
Jesus came into the world to save sinners-of whom I am the worst.
(1 Timothy 1:14-16)

Received on Thursday, 8 July 2004 09:12:11 UTC