RE: Comments on SVG 1.2 from a Gecko developer

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.

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.

>> -- "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.
>  
>
Fair enough.

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

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

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

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.

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

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

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

>Similarly, there are some features of SVG that may need to be made into
>their own Spec, or seem more suited to a different Spec. I personally don't
>see any harm in their being developed in SVG, in a timely manner that lets
>them be used sometime soon, with later revisions relocating and deprecating
>them.
>  
>
In practice deprecation doesn't help on the Web. Once a feature is added 
to a spec and implemented, it must be supported forever, or close 
enough. A later merge --- which would almost certainly differ from its 
progenitors in syntax and semantics --- would actually add to the 
duplication. If there's going to be unity we need it now.

>That being said, I'm looking forward to the day when a mixed-namespace
>browser is prevalent, and I'm glad that the Mozilla project in trying to
>bring that about. This was certainly not an attack on your observations, but
>just my own take on the subject.
>
No problem, much appreciated.

Rob

---
Robert O'Callahan <robert@ocallahan.org>
"In the beginning was the Word, and the Word was with God, and the Word
was God. ... The Word became flesh and made his dwelling among us. We
have seen his glory, the glory of the One and Only, who came from the
Father, full of grace and truth." 1 John 1:1,14

Received on Wednesday, 26 May 2004 12:02:37 UTC