Re: Comments on SVG 1.2 from a Gecko developer

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.

    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?

    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.

    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?

    Text is a kind of important thing, so I'm not surprised to see some
level of overlap in text handling.  Just as I'm not surprised to see
overlap in the handling of images.  From a duplication point of view
things would be simplest with XSVHTGRDML (eXtensible Scalable Vector
Hyper Text & Graphics Resource Description Markup Language) - but then
the WG would take a decade to consider anything and implementations
would be impossible to produce.

> 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.

    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.

Received on Thursday, 8 July 2004 13:31:07 UTC