Re: Comments on SVG 1.2 from a Gecko developer

On Wed 26 May 2004, Robert O'Callahan wrote:

> 
> Amalgamating responses to different posts ... hope this is OK.
> 
> Antoine Quint wrote:
> 
> >The SMIL Animation spec is meant to be "hosted" by 
> >another spec that refines areas where adaptation to the host language 
> >is needed.
> >
> So then if I have a mixed HTML+SVG document, I can have HTML-SMIL and 
> SVG-SMIL elements with the same name in different namespaces. Is their 
> behaviour guaranteed to be same? This is more of an academic question 
> since SMIL isn't on our radar just yet.

I haven't looked closely, but I think they are the same.
However, implementing SMIL is a lot more work than the SMIL animation
used in SVG.

> Robin Berjon wrote:
> 
> >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).
> > 
> >
> 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. 

> >>-- 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.
> > 
> >
> I understand why you want precise specification of the rendering and 
> interactivity of actual SVG graphic content, but I don't see how that 
> extends to UI features like tooltips. You *want* tooltips to be rendered 
> differently depending on the platform, the user's accessibility 
> requirements, etc. If you want a very rigid interpretation of 'tooltip' 
> then the only thing you can reasonably say is that it *must* (appear to) 
> be a native platform tooltip, assuming there is such a thing. But is SVG 
> the right place to specify a language for describing bindings to native 
> platform UI?

Firstly I'll just agree with Robin - title attribute bad!
We already have a <title> child element, but that doesn't help
for tooltips. Jim Ley gave the example:

Title: The blue bunny
Tooltip: Click on the blue bunny to make it dance

Is SVG the right place to specify a binding to the platform UI? We're not
really specifying how the tooltip should display, just that it should
be a tooltip. This feature was a pretty common request.


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

SVG Pages have a lot more semantics and behaviour (streaming, animation).

> >>(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 ;)
> > 
> >
> 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.

> It seems to me that specifying and implement pixel-perfect consistency 
> of text rendering in the presence of all these features is daunting. As 
> an alternative, an authoring tool could always flow the text itself and 
> output explicitly positioned SVG 1.1 text runs ... but I'm sure you've 
> considered that.

I agree that this is the best solution in most cases.


> >>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/
> >
> > 
> >
> Good, I hope something good happens there.

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.

> >>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?
> >
> Some of my concerns are addressed but not all.
> 
> Doug Schepers wrote:
> 
> >I don't think that it's reasonable for SVG to conform wholly to a CSS
> >spec, for example, that was designed for HTML; better that SVG explores its
> >own advantages and limitations, and a more neutral approach is developed 
> >for
> >both.
> > 
> >
> I appreciate that but the fact is that in a mixed-namespace environment, 
> there's limited room for manouvering because, for example, authors may 
> write a CSS rule that applies to both HTML and SVG elements. If the SVG 
> WG wants to simply declare that SVG 1.2 is not appropriate for 
> mixed-namespace environments then that would ease many of my immediate 
> concerns, although it would raise other concerns about forking Web 
> standards.

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?

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

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?

Thanks for the feedback btw, and sorry for the late response.

Dean

Received on Monday, 14 June 2004 09:24:24 UTC