With HTML/CSS/JavaScript, hover events (both the :hover and "onmouseover" event in JavaScript) are typically used for visual feedback (the :hover event being strictly presentation...)
There's a reason for this: Users can disable JavaScript.
A core fundamental of web development (graceful degradation or progressive enhancements) is the result of this. As a developer, you can't assume the "mouseover" event will be available.
Web developers write functional pages first. They then progressively enhance it with JavaScript. This is why the web does (or, theoretically) works (contrary to what you said...)
Flash, on the other hand, is different by nature. It doesn't permit users to disable mouse events (or any other events), from firing. As a Flash developer, you can write code that requires a hover event, with fair confidence that it won't hinder a visitors interaction with the site/project.
To be honest, it's what made Flash so tempting to develop for. You're given an equal playing field through the SWF player.
Unfortunately for Adobe, with Safari/Chrome/FireFox/Opera pushing web standards, HTML5/CSS3/JS are making things (quite) interesting for web developers.
You're confusing best practices with common practices. The vast majority of sites are developed with the assumption that javascript will be enabled in the viewer's browser.
You're right. That's why I included, "This is why the web does (or, theoretically) works..."
To be honest, I know a few developers that develop with the assumption that JavaScript will be enabled. I've also worked at a few companies that assume clients should have JavaScript enabled...
Unfortunately, I see too many sites that completely fall apart if you disable JavaScript (some sites that are even selling a product!)
JavaScript still has a stigma as being a "toy" language and until developers understand/utilize it's full potential, a lot of crummy code will still be written. Thankfully, jQuery (and other great JS libraries) are opening the potential for JavaScript to developers.
Yes, and because Apple controls WebKit they were able to add a workaround to MobileSafari's touch interactions to prevent breakage on sites that use CSS hover menus (give it a try, they work).
Will Adobe's mobile Flash have a similar attention to detail in user interaction design? We'll see.
Agreed that it's a red herring from a pure technology standpoint: they both expose hover events, for better or for worse.
And I agree that a large portion of things like navigation elements and the like will work fine because of the way mobile Flash Player passes those events on touch devices to apps. But I think nearly all of us agree that nav elements shouldn't be done in Flash. They work best and it makes the most sense to use built-in browser technologies for them.
So, other than video (the recent trend there seems strongly to be toward HTML5 <video>), that leaves mostly Flash games.
Many existing Flash games will work with a touch interface enough to get to an intro screen, and perhaps even into the game itself. But it seems like a good majority will be unplayable, and doubly frustrating because you can see the game running, but not actually control it.
