Re: Comments on SVG 1.2 from a Gecko developer

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?

>Is SVG the right place to specify a binding to the platform UI?
>
That's the key question.

>We're not really specifying how the tooltip should display, just that it should
>be a tooltip. This feature was a pretty common request.
>  
>
Maybe but SVG doesn't seem like the right place for it. And I don't 
understand why tooltips are so special that they, out of all platform UI 
widgets, deserve an element guaranteed to map to a platform tooltip.

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

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

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.

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

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.

>SVG definitely was designed to be used in a mixed namespace environment
>(at least as much as other W3C formats). Of course, until recently there
>wasn't a huge amount of work done ensuring the design is usable, but is
>any other spec better off?
>  
>
MathML's not too bad. But you're right. I just hope we can iron out any 
kinks in the design, or at least the biggest ones, before it gets frozen.

>>>In addition, there seems to be an assumption on your part (totally natural,
>>>since you are developing and extending an HTML UA), that all these parts
>>>(HTML, CSS, SVG, SMIL, etc.) are always going to be working together.
>>>Clearly, this isn't always going to be the case... witness Batik (a
>>>standalone SVG viewer) and mobile players. Having a well-defined SVG Spec
>>>helps those UAs tremendously, as they only have to implement SVG.
>>>      
>>>
>>I appreciate that too. But if the parts are going to *sometimes* work 
>>together then these issues arise. I'm deeply sympathetic to the point 
>>that "SVG viewers" don't want to implement a full HTML UA (I know 
>>exactly how hard that is!) so I'd be happy to see restrictions on what 
>>HTML/CSS features are accessible from SVG documents.
>>    
>>
>I thought the only HTML features accesible from SVG are when the
>HTML is embedded inside a <foreignObject>?
>  
>
Correct. (Although I could complain about the superfluity of 
foreignObject for HTML...)

>For CSS, do you mean CSS applied to SVG (which serves a purpose without
>being totally useful or necessary) or CSS to HTML inside SVG?
>  
>
The latter.

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.

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

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, 17 June 2004 00:20:44 UTC