Re: Comments on SVG 1.2 from a Gecko developer

At 12:15 AM 7/8/2004 -0400, Robert O'Callahan wrote:
>Peter Sorotokin wrote:
>
>>At 12:20 AM 6/17/2004 -0400, Robert O'Callahan wrote:
>>
>>>Dean Jackson wrote:
>>>
>>>>Robert O'Callahan wrote:
>>>>
>>>>>It seems appropriate to me to allow CSS to specify a URI to an SVG 
>>>>>fragment for the shape. This would be a nice extension from the point 
>>>>>of view of HTML authors too, properly done.
>>>>We looked (for a *long* while) at ways to allow wrapping text using HTML
>>>>that met our requirements, but it just didn't cut it. As Robin said, we
>>>>needed arbitrary shapes and exclusions. Also, we didn't want to add
>>>>all the elements from HTML (like <ul>).
>>>>
>>>>Your point on allowing CSS to specify a shape to wrap into is an
>>>>interesting one. We'd need to reference multiple shapes (for flowing
>>>>and exclusions), so we'd still need a grammar.
>>>
>>>A grammar could be provided either as a complex CSS property or else as 
>>>another SVG element referenceable from CSS. So you didn't look at this 
>>>approach?
>>
>> From my point of view the grammar is largely irrelevant. I do not see 
>> how CSS box layout algorithm would work in arbitrary shapes. That would 
>> have to be resolved before we can have CSS layout in arbitrary shapes 
>> and it is not an easy problem. SVG does not use CSS box layout, only 
>> flow layout (much more rigidly specified than in CSS). BTW, if you open 
>> a graphics tool (like Illustrator) you'll see this type of text as a 
>> separate option.
>
>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.

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


>>>>I guess if people apply CSS Paged Media to SVG content there would be 
>>>>problems, but I can't
>>>>think why anyone would do that (same thing for XSLFO)
>>>
>>>They might be using SVG content in a mixed-language document which is 
>>>being formatted using CSS3.
>>
>>And it would work just fine. As long as you are in CSS Box layout 
>>context, CSS3 applies, if you are in FO document, FO controls paging. SVG 
>>paging only applies in SVG document, if your top-level tag is not SVG, 
>>than it does not apply.
>
>Then I think we need language in the 1.2 draft saying that explicitly (and 
>clarifying exactly what is an "SVG document" --- a document with a root 
>element in the SVG namespace? A document served with an SVG MIME type?) 
>Currently I see mention of "an SVG file" which seems to assume mixed 
>scenarios simply don't occur. Can we have that?

I agree it should be fixed. If svg is not the root tag, I don't see how svg 
paging can apply and it should be explicitly stated.


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

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

In the mixed content, styling is done for the whole document and renderer 
is switched according to the context - elements in SVG namespace have to be 
rendered by SVG renderer, elements in FO namespace rendered by FO renderer, 
elements in HTML namespace have to be rendered by CSS renderer. CSS also 
probably renders all elements in unknown namespaces, although it is a bit 
of a shady area.


>>>>>[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).


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


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


>>Which WG that would be and when would we have anything that is standard, 
>>though? This question was raised many times, but I see very little 
>>movements in this area. Do you have specific problems with APIs that SVG 
>>WG proposed? If so, we are very open for suggestions and criticism, but 
>>as a UA vendor, I either implement what SVG 1.2 or I have to roll my own 
>>proprietary extensions if SVG 1.2 does not define that. Do you see 
>>current mess with non-standard Window object in HTML scripting as 
>>acceptable? You basically cannot write any useful HTML scipts without 
>>using that non-standard interface!
>
>I'm not ready to comment on the details of the APIs. However, I think you 
>could address the namespace issues and deflect concerns about scope creep 
>by 1) creating a Web-applications-nursery namespace and putting the 
>extensions there

Well, these extensions are really APIs. Extensibility mark-up extensions 
which are are being extracted into XBL namespace, as you suggest.

>  and 2) putting the extensions in their own section of the SVG draft, 
> clearly separating them from "SVG proper", and explaining that the hope 
> is to migrate them to a broader Web applications forum at a later date.

That's a good suggestion.

Peter


>Rob
>
>--
>Robert O'Callahan <robert@ocallahan.org>
>"Here is a trustworthy saying that deserves full acceptance: Christ
>Jesus came into the world to save sinners-of whom I am the worst.
>(1 Timothy 1:14-16)

Received on Thursday, 8 July 2004 15:29:16 UTC