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: <AndrewWatt2001@aol.com>
Date: Sat, 13 Jan 2001 13:46:01 EST
Message-ID: <95.5792358.2791fc69@aol.com>
To: www-svg@w3.org
[I mistyped the address when originally sending the following message. The 
original was copied to: jferraio@adobe.com, svg-developers@egroups.com, 
pschmitz@microsoft.com, MBierman@adobe.com]

In a message dated 13/01/01 18:00:52 GMT Standard Time, jferraio@Adobe.COM 

> 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


I understand the point you make. SVGScroll was "extended" (in a non-technical 
sense) to include panning. I have no problem thus far. But I am a little 
concerned about where your reply quoted above and the earlier one you gave 
are leading.

Are you trying to imply that scrolling is an optional functionality within 
SVGScroll - when applied to the context of the Windows platform?

Given that the original question related to whether the Adobe SVG Viewer, 
which I assume aspires to be a conforming SVG Viewer, required to implement 
scrolling functionality - which on a Windows browser platform would, in any 
other context, imply the provision of scroll bars I am a little concerned by 
your reply here and the one you gave a little earlier on the SVG-Developers 

If, on a Windows platform, the Adobe SVG Viewer and others implemented on 
that platform fail to provide scroll bars then it seems to me that such a 
viewpoint (if indeed that is your viewpoint) is likely to lead to serious 
fragmentation of the user interface on the Windows platform. I understood 
such fragmentation to be contrary to the basic principles on which W3C 

The position as it seems to be is that the Adobe team overlooked the 
requirement (as I see it) to provide scroll-bar based scrolling functionality 
for the Adobe SVG Viewer on the Windows platform. Michael Bierman essentially 
stated that in his recent post to the SVG-Developers group. Such an oversight 
is entirely human.

And presumably with some early, concerted effort within Adobe the effects of 
the oversight can be alleviated. However, rightly or wrongly, I sense a move 
towards saying that scroll bars are (no longer?) normative scrolling 
functionality on a Windows platform.

Let me refine my questions and repeat them:

1. Is it now the SVG WG's view that implementation of (at least) normative 
scrolling functionality - as appropriate to a platfom - is a requirement for 
a conforming SVG Viewer.

2. More specifically, given the normative nature of scrolling using scroll 
bars on a Windows platform is it the SVG WG's view that scroll bars are a 
requirement for a conforming SVG Viewer on a Windows platform?

I would view it a serious deficiency if the SVG spec were to allow, indeed 
tacitly encourage, a fragmentation of the user interface on the Windows 
platform by failing to require implementation of scroll bars (of course, in 
parallel with any panning functionality or alternate scrolling functionality).

I would be grateful if the SVG WG would look at this issue and consider the 
issue carefully. As I said previously I read the SVG CR as already requiring 
that functionality for SVG documents, which as I pointed out previously 
explicitly includes SVG document fragments. Is it the SVG WG's view that such 
functionality is required? Or do they hold a contrary view?

I appreciate that it may not be possible to give an immediate answer to the 
questions. I would rather wait for a carefully considered answer which 
produces the right result.

However, I would say that my personal view is that it would be wholly 
inappropriate for the SVG CR to progress to PR if it tacitly encourages an 
avoidable fragmentation of user interface.

Thanks for any clarification.

Andrew Watt
Received on Saturday, 13 January 2001 13:46:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:50 UTC