Which mobile browsers versions/devices versions/OS versions currently capable for HTML 5, CSS3 and jquery?
views:
56answers:
2jQuery is just javascript, so all of them. Parts of HTML5 work about as well as in the desktop browser. CSS3 I can't comment on right now.
Webkit (Chrome, Safari) supports HTML5 and CSS3. jQuery is supported, but you might find animations to be somewhat sluggish. Webkit can be found on Android and iOS.
Opera Mini supports HTML5 and CSS3, and I'm willing to bet its Javascript performance is in the same neighborhood as Webkit.
Note that Webkit and Opera do not support the exact same features - webkit has a bit more presentational CSS available to it, but for the most part they have similar features available.
Bottom line: Keep your javascript lean and clean, and keep your HTML and CSS limited to what would normally work between Webkit and Opera (and to a lesser extent, Firefox). That way you'll be assured of developing a nice looking cross platform compatible app that doesn't bog the phone down.
Also consider using media queries to target specific platforms in CSS.
Edit: Regarding Hover / Mouseenter / Mouseleave:
I would avoid using mouseneter, hover, or mouseleave effects within a touch application. These effects are designed to provide feedback for a mouse pointer, which is not directly attached to our arm (and considering that mice can have different tracking rates, it's not always easy for the user to spot the mouse).
However, in a touch environment, these events can be triggered incorrectly, or not at all. Some browsers in a mobile environment (such as Safari on my iPad) seem to apply the hover state (see here) on clicking a link, which seems somewhat incorrect.
I'm working with a touch screen on a Windows PC for a contained application, and this presents some similar problems. When the users taps on the panel, the mouse cursor is moved to that point - and thus things like titles can show up on elements that have them. Which is silly when there is no cursor there. (Most people do not think of an invisible cursor following them, which is precisely what happens on most touch screen panels).
Consider that a touch app is designed to mimic physical, hardware buttons like those on a keyboard. You don't get any feedback that you're about to push them, but you get feedback once you have pushed the button (physical / haptic feedback) as well as the desired result. Given that most touch screens do not support haptic feedback, you must supply visual feedback to replace the physical feedback people will expect - and then the result needs to fire.
As an example, my buttons in my web application will change their background to an inverse gradient on the "active" state. Meaning when the button is pushed, the button depresses, and then the action tied to it will commence.