- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Wed, 17 Nov 2004 14:50:00 -0500
- 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 determination. > [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