- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 23 Sep 2008 15:30:05 +0200
- To: Andreas Neumann <a.neumann@carto.net>
- 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 UTC