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

SVG has defined "SVGScroll" to mean either scroll or pan, which should be 
generalized to mean any shift in view regardless of the UI control used to 
achieve it, which is consistent with what Patrick says below.

Jon Ferraiolo
SVG Editor
jferraio@adobe.com

At 09:38 AM 1/12/01 -0800, Patrick Schmitz wrote:
>In addition to which, it is common in many hypermedia documents to
>"automatically" scroll the document when a link is traversed, such that the
>target (element) is in view. This can provide a reasonable alternative to
>window scrolling mechanisms.
>
>In further addition, script could easily provide scrolling by supporting
>"click to recenter" functionality as is common on many mapping
>applets/widgets.
>
>And finally, it may even be possible (ask Jon or others, as my knowledge of
>SVG is insufficient), to effect scrolling using animation.
>
>IMHO, Scrolling events should be a function of the shift in view, and not
>(necessarily) user actions at the viewer application level.
>
>Patrick
>
> > -----Original Message-----
> > From: Dave J Woolley [mailto:david.woolley@bts.co.uk]
> > Sent: Friday, January 12, 2001 5:27 AM
> > To: www-svg@w3.org
> > Subject: RE: Does the SVG CR require a conforming viewer to provide
> > scroll bars?
> >
> >
> > > From:       AndrewWatt2001@aol.com [SMTP:AndrewWatt2001@aol.com]
> > >
> > > 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.
> > >
> >       [DJW:]  This is only true for windowing type GUI browsers,
> >       and even then, the convention is to use the window scrolling
> >       mechanism of the underlying GUI++, not necessarily scroll bars,
> >       although scroll bars do tend to be fairly universal at this
> >       point in time==.
> >
> >       SVG claims to be accessible, which means that
> > non-visual browsers
> >       (as well as non-GUI image viewers##) may try to render more than
> >       the text.
> >
> >       Is not the CSS2 "overflow" property relevant here.
> > >
> > [DJW:]
> > ++ Although NS 6 seems to use its own widgets.
> >
> > ## This could include the full screen mode of image viewers
> > running under
> >    a GUI, as well as image viewers running without an underlying GUI.
> >
> > == Taking things to extremes, maybe, I could conceive of a viewer that
> >    monitored brain activity to determine when to scroll.
> >
> > [ Original was cross-posted, but I'm only on one of the lists. ]
> > --
> > --------------------------- DISCLAIMER
> > ---------------------------------
> > Any views expressed in this message are those of the
> > individual sender,
> > except where the sender specifically states them to be the
> > views of BTS.
> >
> >
> >

Received on Saturday, 13 January 2001 13:00:02 UTC