W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

Re: Feedback Request: Difference Between Scroll and Pan?

From: Robin Berjon <robin@berjon.com>
Date: Tue, 23 Sep 2008 15:30:05 +0200
To: Andreas Neumann <a.neumann@carto.net>
Message-Id: <C69ECBE8-FEDE-4402-9671-758D1AEE2320@berjon.com>
Cc: "www-svg" <www-svg@w3.org>

On Sep 23, 2008, at 08:49 , Andreas Neumann wrote:
> I agree that
> svg:not(:root) { overflow: hidden }
> should be the default.

Me too.

Regarding the group's debate on whether panning and scrolling are the  
same thing I think that there is only one difference, and it is solely  
of author expectations: scrolling is expected to be bounded (you can  
always scroll to the end of something) whereas panning is expected to  
be potentially infinite or close enough to it to make scrolling  
impractical (the typical case being the map where a script would watch  
the current pan and add/remove content to match). That having been  
said I don't think that the two are different enough to warrant being  
treated differently by the UA. In fact the more they are treated  
similarly (preferably identically) the more we can let authors decide  
which UI they want to put on it to best match their expectations.

I'm not convinced this warrants the addition of a pan value to the  
overflow property. If overflow is set to hidden but the content has  
enabled zoomAndPan, then I would expect no scrollbars but the ability  
to pan.

Given a couple beers I could perhaps make the case for cursor: pan.  
That's a fairly common cursor, often showing a hand with all fingers  
extended (unlike the typical pointer cursor) and switching to a  
grabbing hand when dragging stuff around. Presumably that's different  
from the move and all-scroll cursors, but to be honest I don't have a  
strong opinion here and am happy to leave that to whichever future  
generation is in charge of CSS UI.

> If the content is pannable/zoomable there should be a visual  
> indication
> that it can be panned/scrolled. Scrollbars are good in providing a  
> visual
> clue how large the panning area is and how much of it is currently
> displayed. But often scrollbars are very ugly and disturbing and may  
> not
> fit into the design of a web application. Scrollbars are also not very
> efficient for navigation.

I am not convinced that the UAs should be mandated any kind of  
affordance for pannable content. If as an author I hide scrollbars yet  
maintain panning enabled then I probably want to handle indicating  
that to the user as my use case probably doesn't match much that is  
generic. In other words I don't think that there's a UI that would  
work for both a 2D scrolling game and for a map.

> On the other hand, panning with just a simple pan hand provides no  
> visual
> clue how big the pannable area is. I like the idea of a more complex  
> pan
> cursor indicating in which directions I can pan and how much (at least
> very roughly). We could ask some designers to come up with  
> suggestions for
> an interactive pan cursor.

I think we should let designers handle interactive pan themselves :)

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Tuesday, 23 September 2008 13:30:43 GMT

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