Re: Comments on SVG 1.2 from a Gecko developer

Robin Berjon wrote:

> thank you very much for your feedback, it is most valuable.

Thanks to you too.

> Robert O'Callahan wrote:
>> 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.
> That seems like a reasonable argument to me. I don't mind resolving to 
> remove tooltips since they can be done in script (unless there's a 
> compelling counter-argument), but that's just my personal opinion.

Any motion on this issue from the WG?

>> 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.
> The things that these comments relate to are APIs, not things that are 
> part of the grammar. I really don't see what the problem will be in 
> the future of offloading, say, the Network API to another WG, 
> irrespective of how successful this API is (which it already is, since 
> implementors support parts of it already under user pressure).
> I would say that the only thing we need to do is put the IDLs under 
> org.w3.webapp.* instead of org.w3.svg.*. That's certainly something 
> that can be done now.

That sounds good. You'd also want to move it from "SVGWindow" to 
something more neutral.

>>> 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...)
> How so? The advantage of foreignObject is that it provides a viewport, 
> which can be used by XHTML to render itself into, and by SVG as a box 
> that's not its problem. I find that the <tharBeMonsterrrs/> approach 
> to mixed namespaces makes a lot of things easier to begin with, even 
> if farther down the line we might want to work on tighter integration.

Sounds reasonable.


Robert O'Callahan <>
"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:27:00 UTC