Hover effects on smart phones/touch screen devices

I’ve seen keyboardable dropdowns where the subs do become visible on :focus (of the particular submenu item, not the parent li). They do look a bit weird though, appearing out of nowhere without the rest of the subs showing. Of course, IE6 doesn’t support :focus, but whatever.

I wouldn’t send people to a sitemap, but to a page with info about that theme/rubriek/whatever, and inside are further links.

For instance I had a menu for an insurance page. If you chose Transport, but clicked on that menu choice (people who make the dropdowns appear by hover don’t ever seem to think of clicking on the main link) get to the Transport page, which is about the three sorts we had: Cars, motorcycles/scooters, and boats. That page had small pieces of text about each sort of insurance and several clickie links to the individual pages-- they could choose to go directly to “get a quote” (one of the sub-sub menu items) or they could go to the “info/about/conditions” page (the other sub-sub menu item), each for that particular vehicle.

Those who could get the dropdown to work could use it as a dropdown, but it wasn’t required for anyone and the menu actually wasn’t so deep that you had to click through pages of garbage to get to any particular page (esp since the menu was prolly a little too redundant-- instead of navigating through Transport, you could instead choose the Get a quote main menu item as well and then choose your type of insurance on that new page too.

I think it was pretty nice, but even better was when I removed it entirely.

I would never build a menu out of Javascript, and never will have that as a sole menu option until every single user agent out there supports it, and cannot be turned off by the user. Which will never happen so long as 12-year-olds continue to do Javascript attacks on lax websites (when they made that epilepsy support forum flash crazy colours so the users has seizures… those kids should all be dropped from tall buildings). Javascript can make things pretty, or make things fancy, or make things slow. Beyond that, I avoid it. I hate scripts making things dance and sing unnecessarily (MooTools, I’m talking to you) and that’s reason #2 why I always surf with scripts off.

An example of why I hate Javascript menus: http://opmaatverhuizingen.nl visit it with scripts off. Click on what you DO see at the top, and you’ll get a nice advertisement for Open Cube, instead of the guy’s business. That’s just wrong on so many levels.

And yes, I know that’s not what brothercake is advocating. I’m not sure what he’d have in place of a main menu though. I don’t see any problems with a main menu available for everyone. Letting people get to the subs pages can be done in so many different ways.

OpenCube is one business I have dealt with in the past. They use the old model of developing in the 1990’s with poorly implemented JavaScript focused “solutions” which are so heavily encrypted to protect their code that you have no way to debug or resolve any issues with the projects. They are obtrusive and extremly heavy on the KB size.

I’d have a top-level navigation bar same as it is anyway, linking to pages from which all the submenu content is available - sub-index pages as it were.

Ah, ok. I thought you meant “no menu” when no js. : )

Generally I make sure the website is still useable if JavaScript is not enabled. It would bbe overkill accessibility to eradicate JavaScript.

They can, but it must be remembered that touch screens are not fancy mice.

The cursor should usually suppressed and some other method used to indicate acceptance of the mouse action.

One key I found necessary is to add onMouseDown=“return false” to the <body> tag to suppress highlighting while dragging the finger across the screen.

onMouseOver() and onMouseOut() are used to activate/deactivate stuff, and there must be an onMouseUp() somewhere to do the same thing as onMouseOut().

I have an example of a work in progress (it’s only slightly broken) on the web - it’s a multi-speed scrollable list menu for use in our touch screen operated building directory. (They won’t let me post a link and I’m not about to post the entire file here - google “dos batch language: a personal view” to find the server, then select the “other stuff” link - it’s the ts_menu_sample file ".)

Which leads to my own question: lifting the finger leaves the cursor over the element, and therefore the element selected. onMouseUp=“scrollStop()” in the <body> tag stops the scroll when the finger is lifted, but I want the colors to revert to the unselected state. I haven’t managed to get Javascript to change the colors: it changes the values, but the colors on screen don’t change. The simplest (in theory) solution would be to cancel the :hover state, but I haven’t a clue how to do that.

The context is Firefox in kiosk mode under XP, using Apache as the localhost server on a dedicated machine with a portrait mode monitor and touch screen - no mouse or keyboard.

T.E.D.

But that seems like a very poor way of navigating around a website

What seems like a poor way to navigate a site?

If you mean touch screens, you are right … except for public kiosk type installations - there, it’s the only reasonable way. Our building directory is mounted on the side of a staircase which makes a mouse pretty much impossible. The second one will be mounted on a wall. The web version will be mouse oriented, but that’s still in the future.

I personally dont like drop down menus. there are also other people see the java script to disable. Aker link I much prefer. I would recommend that one on the left side normal build, there is so much simple and useful

[QUOTE=;][/QUOTE]
The final version doesn’t use either drop down menus or hover. It is structured as four frames: top (title and menu for tall people), bottom (menu for short people and wheelchair users), left (floor plans with animated paths to selected rooms), and right (scrollable indexes with entries that link to left pane items). The hover effect is implemented with some rather complicated onMouseOver CSS that inverts the color scheme for index entries, scroll buttons (that control the vertical marquee tag effect speed and direction), and menu buttons.

I overheard a visitor’s comment Friday: “That’s really cool!”.

T.E.D.