Re: Comments on SVG 1.2 from a Gecko developer

Peter Sorotokin wrote:

>> I see that you've taken some shortcuts to make it work in the SVG 1.2 
>> recommendation, such as the idea that the line-height is always 
>> derived from the first word.
>
> If so, this is something new to me. It certainly not we have 
> implemented, for instance.

Sorry, I was mistaken.

>>  I hope you're aware that (as far as I can tell) you will get 
>> something surprisingly ugly with the following markup:
>>
>> <flowRoot>
>>  ...
>>  <flowLine>Some very long text string.</flowLine>
>>  <flowLine>Hmm, <flowSpan style="font-size:200%">Uh 
>> oh</flowSpan></flowLine>
>> </flowRoot>
>>
>> It seems to me that the basic ideas behind SVG 1.2 text flow could be 
>> easily adapted to CSS. You could solve the line-height determination 
>> problem by requiring that for elements flowing inside a shape, the 
>> CSS3 line-stacking-strategy property be treated as "block-line-height".
>> http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#LineStacking
>> Then you can compute the text regions for a line just like you do 
>> here in SVG 1.2. We already know how to place a line's inline boxes 
>> offset from the left and right edges of the block (to handle floats). 
>> Handling discontiguous text regions shouldn't be too hard (providing 
>> the behaviour of text-align:justify is specified, which it doesn't 
>> seem to be in this case in SVG 1.2). Placing floats might be 
>> troublesome. But we already have to place floats adjacent to other 
>> floats so it might not be too much extra work. Or, you could state 
>> that floats are not allowed inside SVG text flows at this time.
>
> In other words, there is a LOT of work to integrate it on the spec level.

Yeah, but it's a lot of work to specify it in SVG too (and apparently 
more work remains).

>> 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. 
http://www.w3.org/TR/2004/CR-css3-page-20040225/#page-size
This is just ignored if the document is SVG?

>>  Is the assumption that all CSS properties not mentioned in SVG 1.2 
>> must be ignored by SVG documents? What about mixed content?
>
> All CSS properties not mentioned in SVG 1.2 are ignored by SVG 
> rendering engine, just like SVG-specific CSS properties are ignored by 
> CSS rendering engine. CSS really smashes together styling and 
> rendering parts. SVG uses only styling and has its own renderer.

OK, that clarifies things a bit.

>>>>>> [Discussing whether SVG 1.2 flowed text and XHTML avoid 
>>>>>> implementation overlap]
>>>>>> Not at all, considering what they have in common. Blocks, 
>>>>>> horizontal and vertical alignment, inline images, spans, Bidi, 
>>>>>> all styled with whatever properties you envisage applying to 
>>>>>> text, on top of the basics of text measurement and line breaking. 
>>>>>> Plus, beyond just what you've specified explicitly, in a 
>>>>>> mixed-namespace environment every single CSS text property can be 
>>>>>> applied to these SVG text elements and authors will expect them 
>>>>>> to work. Also this is an area that you'll no doubt want to extend 
>>>>>> in future revisions of SVG. (I'm sorta surprised text-decoration 
>>>>>> isn't in there already.)
>>>>>
>>>>> All good points.
>>>>
>>>> Then could the WG revisit the issue?
>>>>
>>>> Given that the Adobe SVG viewer implements some subset of XHTML, 
>>>> I'm surprised this hasn't been highlighted as a major issue already.
>>>
>>> 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?

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

>> I also don't see how CSS/XHTML is "more flexible"/"less strict" if 
>> you assume particular fonts. I'd love to be enlightened.
>
> CSS does not specify how lines are broken into "words", for instance. 
> It does not talk about kerning either. In effect CSS defines what a 
> "good" result would be, but there are several possible "good" 
> solutions in some cases. This is perfectly fine for documents, but not 
> very good for artwork. Also, many problems in layout simply don't 
> occur in rectangular regions and CSS says nothing about them.

Thanks, that's helpful.

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

Javascript:
    var s = document.window.createConnection();

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

Rob

-- 
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 Thursday, 8 July 2004 15:56:02 UTC