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

Re: Comments on SVG 1.2 from a Gecko developer

From: Peter Sorotokin <psorotok@adobe.com>
Date: Fri, 09 Jul 2004 09:26:43 -0700
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Dean Jackson <dean@w3.org>, www-svg@w3.org
Message-id: <>

At 03:55 PM 7/8/2004 -0400, Robert O'Callahan wrote:
>Peter Sorotokin wrote:
>>>I think we also need language clarifying how CSS applies to SVG. You're 
>>>saying CSS3 paged media properties don't apply to SVG documents.
>>Correct me if I am wrong, but I think that CSS3 paged media properties 
>>need box layout to function. SVG does not use CSS box model, only cascade 
>>and inheritance. CSS does not render SVG.
>For example, the 'size' property sets the size and orientation of a page 
>using the @page syntax. 
>This is just ignored if the document is SVG?

I think the whole @page is ignored for SVG, but it is not specified. 
Concepts of borders, margins, etc. are not there in SVG and without them 
@page cannot function properly. I think @page is unsutable for FO as well, BTW.

>>>>It was and we discussed it quite a bit. I actually proposed to simply 
>>>>use XHTML syntax inside the flow, but it was rejected since that XHTML 
>>>>syntax would have to be rendered by non-XHTML rules. SVG rules are much 
>>>>stricter; with CSS/XHTML you have much more flexibility; also SVG lacks 
>>>>box layout, XHTML uses it all the time. From my (implementor's) point 
>>>>of view, syntax is not all that important, though. XHTML and SVG text 
>>>>layout are done by the same text engine internally in Adobe viewer, so 
>>>>all overlaps (which SVG imported, not reinvented!) can be leveraged 
>>>>quite nicely. You should be able to do the same. Again, note that CSS 
>>>>box model has to be done separately (on top of text layout).
>>>If the rules are different, how then can the implementation be the same? 
>>>I'm a bit confused.
>>>To put it another way, if you've implemented CSS/XHTML on top of SVG 
>>>text layout, in a standards compliant way, then it must be possible to 
>>>specify that mapping as additional rules for rendering CSS/XHTML, and 
>>>require those rules to be followed by any UA that mixes SVG and XHTML. 
>>>Surely no XHTML curmudgeon could object to this :-).
>>CSS rules are not strict, SVG rules are. You simply can use SVG rules 
>>where it makes sense and parameterize where CSS has to be done 
>>differently. The point is you cannot take CSS text layout engine and 
>>simply use it for SVG (or vise versa), and you cannot take SVG engine and 
>>use it for CSS, however you can write an engine that services both at 
>>probably extra 10% of the cost of either engine alone (and probably do a 
>>lot of FO as an added benefit).
>Okay. Then wouldn't it make sense to require that a UA that supports both 
>SVG and CSS *must* render CSS in an SVG conformant way?

This is up to CSS WG.

>By the way, can you share with us any areas where you have discovered CSS 
>must be done differently?

The engine itself is exactly the same, but several "callback" objects that 
are provided are done differently for SVG and CSS. That has to do with 
dx/dy adjustments or baseline shifts in SVG, doing CSS floats (we don't 
yet) would also add more differences.


>>>>>Even if the SVG WG decided to extend its own mandate and create a new 
>>>>>Web-app-namespace-nursery to put these extensions in, that would still 
>>>>>seem better than this, to me.
>>>>In terms of JavaScript APIs, I do not see any problems for another WG 
>>>>to take over them.
>>>Javascript might not be a problem, but for other binding languages, such 
>>>as Java, putting (say) a socket API in the SVGWindow interface means 
>>>that people are going to write programs whose text demands that there is 
>>>a socket API in SVG. That's bad.
>>Why??? Besides all APIs must be language-neutral, so if it is available 
>>in JavaScript, it is available in Java as well.
>Sure. I guess I'm being unclear. Here's what I'm talking about:
>    var s = document.window.createConnection();
>    DOMWindow w = document.getWindow();
>    SVGWindow w2 = (SVGWindow)w;
>    Connection c = w2.createConnection();
>You can move createConnection() to a WebAppWindow interface without 
>breaking the Javascript program, but it will break the Java program.

Not a problem if SVGWindow will inherit from WebAppWindow. SVG DOM using 
multiple inheritance (for interfaces) all over the place.


>Robert O'Callahan <robert@ocallahan.org>
>"In the beginning was the Word, and the Word was with God, and the Word
>was God. ... The Word became flesh and made his dwelling among us. We
>have seen his glory, the glory of the One and Only, who came from the
>Father, full of grace and truth." 1 John 1:1,14
Received on Friday, 9 July 2004 12:32:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:02 UTC