If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple.
IE would have died years ago if developers had adopted that culture en masse.
"on hover" is a side effect of pointing at things with a mouse. With a touch screen you touch things directly with your finger, you don't hover. So you have to design your website/app with that in mind: users will touch whatever they want to interact with. That's neither a mouse "on hover", nor a mouse "click".
Of course you can forgo people who use touchscreen, or even mouse and go keyboard only... it's a choice.
There isn't now, but there well could be.
Suppose for a moment that you get a good old cursor on iPhone and it follows your fingertip as you move it around the screen. It wouldn't even have to be user-visible. To click, you press a bit stronger, or you raise & lower your finger (`tap' if you will). The hover's back.
There's nothing inherent in touch-based technology that prevents hovers from working. Such behavior has been available way on (decent) touchpads for well over a decade now, modulo user-level configuration.
Or not.
On touch touchscreen it feels natural to just touch the part of the screen you want to interact with. I hate the word, but it's intuitive. It doesn't feel like something you need to learn and become familiar with. My daughter understood how to use my iPad when she was less that one year old. She just touched the screen and something happened, she was happy. Even my mother-in-law understand how to use a touchscreen.
Neither my daughter nor my mother-in-law can use a mouse: it requires too much dexterity. I've seen people hovering a mouse in front of the screen hoping that something will happen. It's less intuitive, but it's familiar to all of us on hackernews.
What I'm trying to say is that there is something intrinsically natural and easy with a touchscreen: touch - interact. We won't go back from that.
I might be proven wrong, and tomorrow everybody will do on hover with its phone/tablet with the process you describe, or the one described by grovulent, or another one. But my guess is that it will remain mostly unused, except for a few "power users".
Twenty years ago, I'm sure people would have been skeptical if you told them that someday, they would be able to wirelessly interact with a mass network of information via a touch-responsive, glassy device that fits in the palm of their hand.
Now where would be today if we'd listened to THOSE skeptics...
If we think about the future of touch and gesture interfaces, I absolutely think we'll see a hover state be implemented, but it won't be connected to a mouse cursor. That's moving backwards.
There will likely come a point where a touch or gesture interface will be able to tell if your hand or finger is quite literally -hovering- over a touch-enabled element, and will be able to give you context.
It's seems completely intuitive. If you're hovering over an element, you're likely hesitating, so give more context. Preview the next screen, provide info in a tooltip. Why wouldn't you take advantage of this?
A Synaptics touchpad can do that, no problem. Used for, at very least, the `palm detect' functionality. Catches a single finger at a few milimeters' distance, configurable to the boot.
But I believe pushing that is a prime example of backwardnes -- a metaphor taken literally overriding ergonomics concerns. It taxes your muscles more to hover your hand in air with no support, than to slide it on screen. Perhaps that doesn't concern a person nearing top physical fitness, but that's a limited segment of market. Also, keeping fingers away precludes tactile feedback of reaching edge of active area, or some sort of active tactile feedback: http://www.macrumors.com/2009/12/24/apples-research-on-tacti...
The fingertip is the new cursor ;-)
Build your interface around the inputs. One nice thing about using CSS in this manner is one could (along with some discrete use of JS) build equivalent interfaces which are useful on touchscreens.
If developers choose en masse various interface methods that a particular platform doesn't support - that platform loses.. end of story.
Nor is there anything inherently impossible about hover + touchscreen. Double tap to prevent scrolling (and at least on my nexus S I'd prefer that to zooming which 3/4 times doesn't actually zoom at all). Move finger across screen - stop over element without additional tap. That's hover baby!
Not sure why folks voting me down. What I'm saying is not only right - it's sensible... and it's also preferable. Developers should be deciding UI reality.
Also, it's easy to add a touch event to do the same as the hover event, it's up to developers to do it. I was just thinking about the dependency of hover which need to go.
The thing I don't like about hover is that at core, it's a leap of faith -- you're asking your user to mouse around blindly (like Myst, anyone remember that frustration?) until the page rewards their fumbling with some sort of UI treat. It's a symptom of inefficient and poor design.
(Having said that, these are lovely animations.)
It's also important to note that discoverability is really different than it used to be due to touchscreens and that plays a major role in usability.
The tradeoff was simple: marginally greater market share at the time vs the fact that if we supported IE we would not be able to use BUTTONs to separate labels and inputs for i18n purposes. Really, there was no case to be made for IE support at that point.
So developers hsould consider the tradeoffs carefully.
> drop support for IE due to a lack of BUTTON support