semi/signal

Interesting post on the realization that :hover (in CSS, this defines what occurs when the mouse is over an HTML element) is no longer viable for layout on touchscreen devices.

When I sat down to a redesign of the Gameplan2 admin interface I suddenly came to a realisation, :hover doesn’t work. It’s entirely possible I’d skim read this somewhere, but somehow the implications for my design work had passed me by until I saw an iPad in use.

I came to the same realization when designing the Ekkio web client, and realizing I couldn’t open the file and folder submenus on my Palm Pixi.

The arrows on the left would only appear when the user hovered over a file or folder. The solution, as shown, was to always show the arrows, but make then a lighter shade; on hover or when the dropdown is open, the arrows become a darker shade. This works well, despite the visual clutter of the arrows always being visible.

I agree with Croll’s conclusion,

So my proposition is this: :hover as an web interface design tool going forward is going to be less and less important.

I see :hover (and javascript mouse events such as onmouseover, for that matter) being unused or used only for non-essential stuff, such as added visual flair.

On a related note, touchscreen also don’t allow viewing the alt-text when hovering over an image. This is probably not a big deal when it comes to web layout, but it sucks for reading xkcd.

A similar issue to the one I mentioned in my previous post. The problem is the same, the behavior of anchor elements is broken, however, the cause seems to be different.

The image above demonstrates the issue. The area enclosed by the blue box is the anchor element. It’s a block-level element (display:block) and positioned using position:absolute. The area enclosed by the white lines is part of a paragraph element. When the paragraph element overlaps the anchor element, the functionality of the anchor element is broken (oddly, the functionality on the border of the anchor element is still active).

I’ve found two solutions.

• Reduce the width of the paragraph element or it’s container to prevent the overlap
• Use a transparent gif for the background of the anchor element. The same solution for the issue described in my previous post

I’ve previously expressed dissatisfaction w/ the look of my homepage but apparently there were functional issues as well. I never did a thorough test of the page in IE (either version 6 or 7), just a quick glance to see that the layout was correct, this bit of carelessness bit me in the ass as I’ve recently discovered the links weren’t working in IE.

The problem was the result of IE not allowing background:transparent AND filter:alpha on the anchor elements. Having both breaks the behavior of the elements (i.e. they don’t function like links and you can’t click on them). I needed the filter attribute for the translucency effect, so my fix was to simply use a 1×1 transparent gif for the needed transparent background.

oh, and these links are somewhat weird. They have no content, they’re just empty block elements absolutely positioned on top of their parent div (whose background image contains the text identifying the link’s function to the user). When hovered over, their background changes to a image that gives them a border. When clicked, their background changes to black and opacity decreases so it’s a translucent shade over the parent div. When unselected (i.e. another link is clicked), they have to go back to being transparent where the user sees right through to the parent div.