Re: Comments on SVG 1.2 from a Gecko developer

Thomas DeWeese wrote:

> Robert O'Callahan wrote:
>
>> Doug Schepers wrote:
>
>>> | 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.
>
>    Or looking at it the other way. Using XHTML/CSS I would have to
> convert/copy all my flow geometry (which I am probably already
> drawing) into CSS syntax.  I will lose the ability to use things like
> the path transformers or anything else that the XHTML/CSS WG saw fit
> not to duplicate.

No. Just make the CSS property refer to SVG elements by ID. Use 
something like "flow-shape: shape(#myshape, exclude(#cutout))".

>    How do I drag my flow regions around the document now? I have
> to muck with CSS?

>    How do I animate the regions or the text in the regions?

Solved by the above.

>    The WG strong considered using the XHTML tags for this but they
> would be a subset because various properties on the tags wouldn't make
> sense.  Is this really just an argument over what the tags are called?
> Or are you saying that SVG shouldn't include any support for text
> unless it requires all of XHTML?  This would in essence say that SVG
> can have no life outside of XHTML.

If it was up to me, I'd support specifying a subset of XHTML and CSS for 
this.

>    Should the SVG WG turn around and say that XHTML/CSS shouldn't do
> anything with geometry or graphics (image maps, image element,
> borders, pad, background, etc) unless it does all of SVG?

Actually I *would* prefer a world where CSS didn't specify backgrounds, 
borders and images, and we just used something like XBL to bind SVG 
elements to get those effects, and CSS colors were just SVG paint 
servers, but unfortunately that's not where we are. I would encourage 
you to pressure other WGs not to add any *new* graphics features.

>> 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.
>
>    One _major_ problem is that XHTML/CSS doesn't specify text layout!
> Sure it talks about blocks, line height etc, it doesn't deal with
> glyphs, bidi, what is a word, how do you wrap etc.  SVG _has_ to do
> this since it's goal is to achieve a high level of cross client
> rendering conformance.

Actually the SVG 1.2 draft from May 10 has some major underspecification 
too. Getting pixel-perfect specification (let alone implementation) in 
this area is going to be really hard work. Examples:
-- Have you defined whether and where subpixel text positioning is 
required (or allowed)?
-- Have you defined exactly where overstrike and other text decorations 
must be drawn?
-- What algorithm must be used to distribute whitespace with 
'text-align:justify'?

Furthermore, whatever rules you come up with for SVG layout could simply 
be imposed on XHTML+CSS-in-SVG as a requirement for SVG-capable UAs.

>    You keep saying that you will have two text layout engines,
> I don't think this is a necessity or even likely.  Do you have any
> evidence that one text layout engine can't support both?  Sure an
> existing XHTML engine would have to add support for flow regions, but
> you are suggesting doing that anyways.
>
>    I know most of the basics of CSS layout and I don't see any point
> of serious conflict, where possible the SVG layout draws on CSS2.

Which is great. I hope that a single engine is possible, but I fear that 
unintended specification conflicts may show up when we actually try to 
implement it that way, and the best way I know to avoid that is to share 
specifications by reference wherever possible. I'm not just thinking 
about now but about future extensions to SVG flowed text that will 
surely happen.

Rob

-- 
Robert O'Callahan <robert@ocallahan.org>
"In the beginning was the Word, and the Word was with God, and the Word
was God. ... The Word became flesh and made his dwelling among us. We
have seen his glory, the glory of the One and Only, who came from the
Father, full of grace and truth." 1 John 1:1,14

Received on Thursday, 8 July 2004 14:46:18 UTC