W3C home > Mailing lists > Public > www-svg@w3.org > January 2001

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

From: Patrick Schmitz <pschmitz@microsoft.com>
Date: Fri, 12 Jan 2001 09:38:11 -0800
Message-ID: <6CAC6551F8C10F4C9EC0CF34132F2AAE4FCB94@red-msg-07.redmond.corp.microsoft.com>
To: "'Dave J Woolley'" <david.woolley@bts.co.uk>, www-svg@w3.org
Cc: "'Jon Ferraiolo'" <jferraio@Adobe.COM>
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 04:03:51 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:19 GMT