Re: Comments on SVG 1.2 from a Gecko developer

Hi Robert,

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


Robert O'Callahan wrote:
>> 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?

I can see the value in allowing XHTML to be able to import this feature 
from the SVG space, however since the flow is specified using SVG, it 
would seem more logical to have XHTML define the way in which they reuse 
it rather than the SVG WG specifying stuff in the XHTML space :) If the 
XHTML WG and the CSS WG wish to define such a property, I'm sure that 
the SVG WG will be glad to be of assistance.

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

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

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.

The only thing that doesn't fall into this category (RCC) has been 
off-loaded to a joint task force between SVG and CSS which is to produce 
sXBL, a version of XBL that covers SVG's requirements and is built with 
future developments corresponding more to the Mozilla XBL in mind. It is 
in it's own namespace, it's own spec, and not the sole responsibility of 
the SVG WG.

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

Well, it is in our mandate to do these things as they constitute 
prerequisites for implementing XForms, which is a high priority in our 
charter. You could call it a WebApp nursery, once you have SVG and 
XForms you only need a few things from XHTML and you have webapps for sure.

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


-- 
Robin Berjon

Received on Thursday, 17 June 2004 16:31:28 UTC