W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: Reconsider SVG 1.2

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Wed, 17 Nov 2004 14:50:00 -0500
Message-ID: <419BAB68.3000102@Kodak.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "Thomas DeWeese"@MIT.EDU, www-svg@w3.org

Boris Zbarsky wrote:
> Thomas DeWeese wrote:
>>    Can you please let me know what this "concrete collision with the
>> CSS2.0/2.1 box model" is?
> Ian posted an explicit testcase earlier in this mess of threads [1].  
> It's unfortunate that there is so much noise that the real technical 
> issues are getting lost.  :(

    This wasn't missed by me!

    I guess you missed all the follow up[4] to that where we discussed
the fact that line-height handling is unclear in the SVG 1.2
specification.  So it's a little silly to talk about _exactly_
what an conformant SVG implementation would render in this test
case.  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).

>>    A conflict would be a place where SVG says you must do X, and CSS
>> says you must do Y.
> That's exactly what happens in Ian's testcase.  Applying the CSS 2 
> rendering rules you get one rendering, applying the SVG 1.2 rendering 
> rules you get a different rendering.

   In that same thread[2][3] I tried to point out that even if SVG
were to choose not to use line-height for line spacing (and perhaps
just use font-size for example).  This would not be a real conflict,
yes you could give 'equivalent' input and get different results, but
if SVG just doesn't use line-height an implementation could still use
the same layout engine by 'fixing' it to 1.0 internally while
processing a flowRoot element.

    An example of a conflict would be if SVG said flowPara elements
have a margin property but they don't collapse between elements.  This
would require an implementation to recode all the margin handling
stuff, which could be buried with the line placement stuff causing all
kinds of problems.

    I think the CSS camp is overlooking the fact that the WG is
really trying to be a compatible _subset_ of the complete CSS
block model.  It would be really helpful if the CSS folks would
look at the text stuff and try and make sure that it is compatible
rather than wasting lots of time and energy arguing that SVG doesn't
need text, or drawing arbitrary lines at word breaking, or line height

> [1] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0011.html
[2] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0016.html
[3] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0041.html
[4] http://lists.w3.org/Archives/Public/www-svg/2004Nov/0134.html
Received on Wednesday, 17 November 2004 19:50:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC