Re: Comments on SVG 1.2 from a Gecko developer

Robert O'Callahan wrote:

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

    What to do if the property is not set?  Wouldn't it be a bit
odd to require a property to be set on an element?  Off the top
of my head I can't think of anything else that behaves like this.
Perhaps you could have it flow into the current viewport...

>>    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?
> 
> If it was up to me, I'd support specifying a subset of XHTML and CSS for 
> this.

    Then your basic objection is naming.  I don't think there is
anything in conflict or 'overlap' between the current flow elements
and the 'equivalent' XHTML elements (I looked at the XHTML equivalents
quite a bit when the feature was first developed).

    To be honest I couldn't care less about the exact syntax (obviously
cleaner is better).  All I really care about is having a good
balance of features and complexity of implementation.

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

    Carefully what you wish for ;)
    For your world to exist there couldn't possibly be seperate XHTML,
CSS, and SVG WG - you would only have one WG tasked with handling
everything - I am convinced that in this world there would be
literally no progress on any of the specs :)

>>    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)?

    There are existing rendering 'hints' to control this.  See
the text-rendering property (11.7.5 of SVG 1.1).

> -- Have you defined exactly where overstrike and other text decorations 
> must be drawn?

    Section 10.12 of SVG 1.1, we reference CSS2 which (without looking
it up) probably isn't very definative on location.  It is probably
worth having the WG clarify (I haven't heard much complaint here,
so presumably most UA's get this mostly correct).

> -- What algorithm must be used to distribute whitespace with 
> 'text-align:justify'?

    I did most of the work on this, and there were a number of
concrete proposals made within the working group.  One of them
was accepted, but the text has not apparently worked it's way into
the specification since I left.  It generally depends on the existing
'lengthAdjust' attribute.  The only real debate was on if SVG should
do justify at all and if so how to decide what should go on a line
(do you allow some amount of text compression).  The working group
never seriously considered 'paragraph' scope justification - although
we considered providing a property to allow implementations to do this
if the content requested it.

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

    Certainly, of course I don't know how this helps your Gecko 2 text
layout engine argument any ;)

Received on Thursday, 8 July 2004 15:35:36 UTC