Re: Comments on SVG 1.2 from a Gecko developer

Robert,

thanks for your comments.

Robert O'Callahan wrote:
> -- The text flow elements in section 3 overlap considerably with regular 
> HTML/CSS text layout.

I am not aware that HTML/CSS can flow text through arbitrary shapes, 
with region exclusions, etc. I'm not convinced that adding that to 
HTML/CSS would work either (you need the shapes).

> -- "Focusable" seems like it should just resurrect the CSS3-UI proposed 
> "user-focus" property. I'm not sure why it was dropped from CSS3-UI...

I don't know why it was dropped from CSS but I'm happy to know it's not 
there. CSS should be a styling language, not a way of using CSS 
selectors to dump arbitrary properties onto elements. It's already gone 
too far in that direction. I'm not convinced that it should be a 
property in SVG 1.2, barring a convincing argument I'd rather keep it a 
simple attribute.

> -- The tooltip support could just reuse the HTML 'title' attribute, as 
> far as I can tell.

HTML's title puts text intended for human consumption in an attribute. 
That's completely broken I18N-wise. Besides, in HTML the tooltip for 
title is just traditional UA behaviour, not rendering intent. In SVG 
it's about rendering/interactivity intent.

> -- Instead of copying parts of SMIL into SVG, why not create a SMIL+SVG 
> profile?

I think Antoine expressed that well.

> -- The SVG page support seems to overlap with CSS3 Paged Media.

No, SVG pages have to do with printing but not only that. A large part 
of their role is resource scoping (to avoid memory overloads in long 
streams) and independent timelines (so that streamed animation is 
possible). CSS would never give us that.

And don't forget that CSS is not supported in SVG Tiny, and likely never 
will be.

> (Case in point: a 
> browser that already does HTML+CSS won't want to reimplement text layout 
> slightly differently for SVG.)

But it's not slightly differently, it's *very* differently ;)

> Some other features, such as the streaming attributes in section 9, and 
> the DOM enhancements in section 17, seem to fall into the charters of 
> SMIL and DOM if not the current SMIL and DOM recommendations. (The DOM 
> group per se may be inoperative, but the work on general purpose DOM 
> APIs still needs a venue of its own.)

The DOM WG is dead and buried, the SMIL WG is barely being reawakened. 
However for both of these we have coordinated our work with people that 
were on those groups, or with the IGs that survived them.

As for the venue, we can be seen as preparing the grounds for what 
hopefully will emerge from:

   http://www.w3.org/2004/04/webapps-cdf-ws/


> Has the SVG WG given any thought to this problem?

All the time.

> Is there any way we 
> can avoid this overlap and the difficulties it will cause for 
> implementors and authors?

In light of the answers you have received, would you mind detailing 
those difficulties?

-- 
Robin Berjon

Received on Friday, 14 May 2004 05:20:01 UTC