Re: Comments on SVG 1.2 from a Gecko developer

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

>>> 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 think we also need language clarifying how CSS applies to SVG. You're 
saying CSS3 paged media properties don't apply to SVG documents. Is the 
assumption that all CSS properties not mentioned in SVG 1.2 must be 
ignored by SVG documents? What about mixed content?

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

I also don't see how CSS/XHTML is "more flexible"/"less strict" if you 
assume particular fonts. I'd love to be enlightened.

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

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

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 00:16:07 UTC