Re: Reconsider SVG 1.2

> Thomas DeWeese wrote:

>> That said I don't see any reason the two couldn't 
>> produce identical results (assuming the SVG WG decided that a
>> flowPara acts as a CSS Block for line-height calculations, which
>> it probably makes sense to do).

Boris Zbarsky wrote:

> Did I miss something?  Can't the text inside a flowPara wrap?  

    Yes.

> And then wouldn't the models described in SVG and CSS produce different 
> layout of the resulting lines?  I thought that was the point of Ian's 
> example...

    So, as I said I don't think the SVG spec is clear enough to know if
the two _should_ produce different layout.

    But let's take the cases I can see:

	1) SVG doesn't use the Block element's line-height (the
zero width strut stuff) in this case I think a 'full' CSS
implementation could still get equivalent layout by simply setting
the block line-height and strut ascent/descent to zero - everything
would then come from the inline boxes.

	2) SVG doesn't use the 'line-height' property and continues to
force it to the value of the font-size (but does do the block strut
stuff). In this case a 'true' CSS implementation simply forces
line-height to be '1.0'.

	3) SVG uses line-height and considers a flowPara a block
element.  A CSS implementation does not need to adjust it's
line-height/baseline determination in any way.

    So in these cases it is true that a full CSS implementation
would have to be "handicapped" to ignore some CSS properties and
use fixed internal values but the core of the layout engine can remain
unchanged.  As I tried to make clear to Ian the issue of compatibility
is much deeper than do I get the same thing given "equivalent" input,
SVG's flowRoot is clearly a subset of the CSS Block model so as soon
as you touch a feature not included in that subset you will get
different layout.  I don't consider this a 'compatibility' issue since
the same layout code can be used an implementor just needs to adjust
the inputs to that engine somewhat.

Received on Wednesday, 17 November 2004 20:59:45 UTC