On Thu, 29 May 2008, Keith Hopper wrote:
Maybe I didn't correctly explain my concern very well. If, using RISC
OS I need to select from a program (eg NetSurf) menu then I click on the
Menu button; any selection then goes to the program action.
If there is a menu produced by the combination of xhtml and css made
visible on the screen by hovering then, as I understand it, any attempt to
scroll down unless using a 'scroll wheel' facility on the platform
concerned and then making a selection will not actually scroll that
sub-menu - well at least that is what I have found using Firefox, Opera,
Konqueror, etc.
I'm not entirely sure what you're getting at here. Anything in the content
area of a browser window (whatever browser, whatever platform) is highly
unlikely to obey the UI conventions of the platform in question.
If you're creating a menu using CSS dynamic pseudo classes and you want to
be able to scroll the menu you've created, then I advise making the
menu fixed size and setting the menu's overflow property to scroll or
auto. That should give you a scrollbar to play with.
Alternatively, if you're creating any dynamic rendering effect that
requires the main viewport to be scrolled, you're probably going to lose
out somewhere. That kind of thing simply isn't catered for in a useful way
by any browser afaiaa. Note that you can use the cursor keys or page
up/down to scroll the viewport on most browsers.
It was this failure to scroll without using the scroll wheel which led
me to think that, under RISCOS, selection using the middle mouse button in
this sort of circumstance would be necessary - but that brings up the
Netsurf rather than the document menu!
If you're creating a menu using CSS, then there's utterly no way that the
browser can determine what you're doing. It has no way of distinguishing
between a menu and any other dynamically modified styling effect.
Certainly, there's no way you can bind the middle mouse button to this
using CSS.
John.
