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

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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:14 UTC