Re: Comments on SVG 1.2 from a Gecko developer

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.

>[snip]
>>>I understand that SVG pages do not map directly onto CSS3 Paged Media 
>>>but they do overlap and that is still going to be a problem.
>>>
>>I'm not sure exactly how they overlap.
>SVG and CSS3 both provide mechanisms for controlling the page size and 
>orientation, as well as the placement of content on pages. The duplication 
>here is probably tolerable if there's some way to handle conflicts.

Again, SVG does not have CSS box layout. It only uses CSS as a styling 
language. At this point SVG defines only a single page size and only 
provides orientation/placement (which is expressed through SVG user-space 
transformations), so I do not see any overlap with CSS other then ability 
to have multiple pages in a single document.


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


>It might be enough to declare that CSS3 paged media can't be used with 
>SVG-rooted documents, and that only <svg> elements which are document 
>roots can use the SVG page support. I suppose the latter condition is 
>implied by the text in section 8 
>(http://www.w3.org/TR/2004/WD-SVG12-20040510/#multipage) but that text 
>just seems to not imagine SVG in mixed documents at all.
>
>>>[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).

Also, line breaking is relatively cheap thing to do. Given all 
internationalization features that SVG has to support, line breaking adds 
maybe another 10% of the code. It was (again, from an implementor's point 
of view) absolutely insane not to have line breaking in SVG 1.1 but have, 
say, bidi, baseline alignment properties and text on the path. Every single 
graphics tool I know has line breaking (and, no, it cannot be 
precalculated, since text can be changed by scripting or font can be 
different). This does not make Illustrator an HTML editor. Currenly, we 
cannot even roundtrip such text.


>>I seem to be saying this everywhere (in response to "??? does not
>>belong in a vector graphics spec") but it isn't the intent of the
>>SVG working group to own everything. At the moment there are no
>>working groups that are looking at client side applications (developed
>>mostly in Javascript) to the extent of the SVG WG. We gets lots of
>>feature requests in this area.
>>
>>So, we try to solve the problem and hopefully in the future there
>>will be a WG at the W3C to take over this stuff.
>>
>That's a good sentiment but if SVG 1.2 is at all successful, you'll never 
>be able to offload features to these putative other WGs unless you ensure 
>that the syntax of these features does not point to SVG. If you put 
>features in an SVG namespace, then going forward you will have to choose one of
>1) Break compatibility by moving them to another namespace
>2) Keep them in the SVG namespace but move responsibility for them to some 
>other group
>3) Duplicate them into another namespace
>None of these options seems good for anyone.

I would suggest that SVG namespace is a perfect way to describe a shape and 
no other namespace should be invented for that. Shape is graphics!


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


>[snip]
>
>For the sake of argument, the SVG spec could replace its flowed text 
>section with the definition of an <svg:html> element which is defined to 
>contain XHTML Basic markup. You could even work around the complex shapes 
>problem by defining the shape on or inside the svg:html element.

Yes, I proposed exactly that at some point (well, svg:div, but not 
svg:html). It was rejected because it would be similar syntax yet different 
layout rules and it was deemed to cause confusion.


>>Thanks for the feedback btw, and sorry for the late response.
>>
>Thank you!
>
>Rob

Yes, thank you for the feedback, I hope that the above clarifies what we 
are trying to do in SVG.

Peter


>--
>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, 17 June 2004 15:40:12 UTC