- From: Greg Holmes <gregh99@gmail.com>
- Date: Fri, 27 Feb 2015 18:30:46 -0500
- To: Florian Rivoal <florian@rivoal.net>, Axel Dahmen <brille1@hotmail.com>
- Cc: www-style list <www-style@w3.org>
[my reply is below] On 2015-02-27 11:15, Florian Rivoal wrote: > >> On 28 Feb 2015, at 00:04, Axel Dahmen <brille1@hotmail.com> wrote: >> >> "Florian Rivoal" schrieb im Newsbeitrag news:521A25AB-C03B-44F8-9353-25A441C03683@rivoal.net... >>> Also, while this should be fairly easy to spec and to implement, I am not fully convinced this is actually a good idea to give this control to authors. As a platform wide setting, or a user controlled preference, sure, but I worry that having many sites being inconsistent with each-other about the look and feel of scrolling would be detrimental to users ability to recognise scrollable things. >> >> Certainly, hiding the system scrollbar wouldn't be the end of the story for the author, of course. It's just a necessary prerequisite. >> >> After having hidden the system scrollbar, authors would be able to add/apply their own, custom, visual cues for scrolling. Imagine a scrolling jog wheel. Or a paging scroll header ("page 1 of 10"). Or something similar to a progress bar. Anything but the system provided scroll bars. Even nothing, if that's the intention of the author. We should leave the decision of which or whether a visual cue is to be provided to the author. > > > Hiding for the purpose of providing a custom made alternative that looks different because it is applied to a different context, as your examples suggest, sounds perfectly valid to me. > > But with the same control, you let authors who have a personal preference for invisible scrollbars inflict the confusion on unsuspecting users who just want common controls to look as they always do. > > Of course, you can't prevent people from making lousy pages if they want to, but we should think twice before providing people with footguns. Maybe this is actually ok, but I'd like to try and consider other ways to get us the benefits while reducing the risks before we jump on this. > > - Florian > This is one of my "pet issues", and I was going to take my time to assemble a more comprehensive comment, but since this topic is hot right now, the following will have to do for now... apologies in advance if it is not clear or useful. The various user agents currently behave differently re scrollbars on elements with overflow:auto. Some show the scroll bars, whereas some (e.g. Chrome mobile on Android) do not. Also, some user agents include the scrollbar height in the JS height of the element, some do not. This inconsistency should be resolved. I can't recall at the moment whether this is scrollHeight, clientHeight, offsetHeight, or ...? I'm not at my workstation at the moment, where I have the test script. Here's an example: as an author, I want wide images to scroll horizontally (and have scrollbars) only if they are too wide for the current screen width or current user agent window width. See here: http://www.gregholmes.com/news.html#item20070405 The "filmstrip" image is 955px wide, but it scrolls horizontally on narrow mobile devices, as I want it to. But, on those user agents that do not show a scrollbar, the page visitor has no visual indication that the image can potentially scroll. So I am looking for CSS attributes that tell me that: a) the scrollbar is visible or not (which currently varies, depending on user agent) b) the element needs to be scrolled to be fully visible, or, in other words, parts of the element are not visible due to scrolling I might propose ":scrollbar-visible" and ":scrollbar-hidden" for a), and ":scrolling-needed" for b). So, for those times where the scrollbar is hidden, but the element needs to be scrolled because it is wide, I would want to add a graphical overlay of an arrow, or perhaps a "ragged right edge", to somehow indicate that horizontal scrolling is possible. div:scrollbar-hidden:scrolling-needed { ... } This might be possible from JS, except that user agents vary in including the scrollbar as mentioned above, but in any case a pure CSS version is far more desirable. Perhaps there is already a pure CSS way to acheive this?
Received on Saturday, 28 February 2015 02:53:42 UTC