Does the SVG CR require a conforming viewer to provide scroll bars?

The question has arisen of whether a conforming SVG Viewer is required to 
provide a scrolling facility for SVG documents i.e. to provide scroll bars 
similar in appearance and functionality to those provided routinely in the 
major web browsers.

Let's look first at what the November 2000 CR says about what constitutes an 
"SVG document". In paragraph 3 of Section 5.1.1 of the CR (page 59 in the 
PDF) it states, "An SVG document fragment can stand by itself as a 
self-contained file or resource, in which case the SVG document fragment is 
an SVG document ...". Thus we see that an SVG document fragment when standing 
alone **is** an SVG document.

In Appendix G.7 we read, "(User interaction includes support for
hyperlinking, events [e.g., mouse clicks], text selection, zooming and 
panning [see Interactivity]". So what are the events for which support is 
required, as listed in the "Interactivity" section of the CR?

When we look at the "Interactivity" section we find a table listing the 
"events" which are to be supported in SVG. Among those events is the 
"SVGScroll" event.

As we saw from Section 5.1.1 a standalone SVG fragment is an "SVG document". 
It seems to me that a conforming dynamic SVG viewer is required to support 
scrolling of such SVG documents i.e. that a conforming SVG viewer is required 
to provide scrolling and support scrolling events.

The globally recognised way to provide such scrolling within a web browser is 
by means of scroll bars. Thus it seems to me that a conforming SVG viewer is 
required to provide scroll bar facility for standalone SVG documents/document 
fragments.

I rest my case. :)

I appreciate that some aspects of scrolling as mentioned in the SVG CR link 
to CSS2 and to DOM2 but I was unable to identify any obvious "get out" clause 
in those cross refences.

Can someone from the working group confirm that a conforming SVG Viewer is 
required to support "scrolling"? If the view is that that is not a 
requirement then I would be very interested to be helped to understand the 
reasoning, on the basis of the CR, which supports such a view.

If the view is taken that scrolling is optional then it seems to me that a 
"scrolling" attribute similar to that which applies to optional zooming and 
panning should have been provided in the CR. The absence of an attribute to 
control such an "option" is either evidence that a scrolling facility was 
mandatory (the more reasonable interpretation in my view) or that provision 
of a suitable attribute to control/identify such a scrolling "option" has 
inadvertently been omitted from the CR.

I acknowledge that I could have overlooked some vital "get out" clause. If I 
have then I would appreciate enlightenment.

At the risk of provoking outrage, is scrolling implicitly a conformance 
criterion whose absence could legitimately delay exit of SVG from CR stage?

Thanks in advance for helping me understand this.

Andrew Watt

Received on Friday, 12 January 2001 06:20:25 UTC