[shaggyfrog]

Is there something intrinsic to the WebKit versions on iOS products, or are your problems more general, i.e. learning how to support "limited" devices again (relatively small CPU, GPU, memory)?

What is it about the iPad 1 & 2 that is giving you so many more problems compared to the iPad 3?

I found I was spending way more time on IE bugs with Web app I recently did (~1000 users/month) than any other browser by far.

[aethr]

Hover states are a big one. Also making call-to-action targets bigger for the less precise pointing device (ie, your users' fat fingers). Making sure you use Flash fall-forwards with HTML5 video/audio available for iPad / non-flash devices.

iPads and iPhones also have great support for CSS3 transforms (3D included with hardware acceleration), but some of the other "common" CSS3 and HTML5 technologies do bog down on the slower processor. Your average desktop may not have a dedicated video card and a browser with hardware acceleration, which creates a smaller intersection of features that will work with no brains on iPads and (generic) desktops.

The list, of course, goes on, and it will continue to grow with time. As with the well known deficiencies of IE (floating, clearing, zindex bugs, etc) however, the iPad caveats and corner cases are becoming more of a known quantity. As with IE, just takes a bit more planning.

[lloeki]

> Making sure you use Flash fall-forwards with HTML5 video/audio available for iPad / non-flash devices.

Can't you for the love of all that is binary do it the other way around? I hate it when sites push Flash on me on the desktop when there's a pure html version ready a user agent string away.

[WiseWeasel]

Desktop browser support for h.264 video via HTML5 is a crap shoot. Sometimes it works well (Safari), sometimes it works poorly (Chrome), and sometimes it doesn't work at all (Firefox and IE9-).

[chucknelson]

I think he's just asking for a flash fall-back if native playback through HTML5 isn't supported. Maybe that is what "fall-forwards" already meant, but I'm not too familiar with that term...

[Chris_Newton]

There are definitely oddities about how iOS Safari does things. Handling orientation changes and using high-resolution images for the devices with Retina displays are repeat offenders.

[shaggyfrog]

Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now).

But orientation changes? Is that not a general "mobile issue" for you? Or is (are) the WebKit build(s) in iOS doing something specifically bad compared to (say) Android?

[josteink]

Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now).

Not "right now". As long as you intend to support "retina displays", it will always be an Apple-specific thing.

If you want to support something as general as high-DPI devices, you know, something concrete and not an Apple marketing-term, there are certainly lots of those being made and sold as we speak. They run Android and are not made by Apple.

You might want to consider supporting those as well.

[FaceKicker]

I downvoted you because your post seemed unnecessarily pedantic and condescending to me. I think it was pretty clear that GP was casually (or accidentally) using "retina display" as a generic term for "high DPI display".

[josteink]

Fair enough and I guess you are free to do that.

Still: targetting "retine display devices" is wrong for a multitude of reasons. You don't want your website to be tailored for a device which has 4x the number of pixels of another very specific device made by one vendor only. That is not the problem you are trying to solve.

The problem you are trying to solve is creating a DPI-independent site layout which exploits the resolution and estate available, while degrading gracefully on lower class devices.

If your solution to that problem is making your website hardcoded to fit two devices made by one vendor, as long as they remain true to leaving everything pixel perfect as they are now, for all eternity, needless to say, it's not a good nor elegant solution.

It's the "This website was made for MSIE" of olden days all over again, only this time for Apple-devices. And thats just not going to cut it.

[karlshea]

Well as long as they are running WebKit and support the device pixel ratio media query, they will be supported.

But I'm guessing that Android phones with high-dpi screens that support that query are still at the single digit percentage of browser statistics.

[WiseWeasel]

That's fine for CSS images (media queries), but what about content images?

[karlshea]

All the code I've seen for content images involves some JavaScript stuff that uses the device pixel ratio as well.

[Chris_Newton]

If you rotate an iPad from portrait to landscape, for example, then the default behaviour in Safari is to show the same page layout as you had before, but scale it up to the new width. That's far from ideal if your site uses a responsive design that could adapt quite happily to use the extra width in a landscape orientation.

[bigiain]

Can I just mention that at least on my phone, websites that "adapt" to landscape mode often bug the hell out of me. With my getting-old-eyesight, I often rotate to landscape mode to get bigger text so I can read it more easily. When a website goes "Oh look, more horizontal pixels, I'll shrink the middle column and add some nav on the left and ads on the right!"; I'll usually just hit [back] and move on to some other site.

(Possibly interesting idea: add some analytics so that you can detect portrait/landscape orientation changes, and report on bounce rates immediately afterwards…)

[Chris_Newton]

In our defence, we do our best to keep the standard zoom gesture working and we use a reasonable default font size. We're not 21 any more either. ;-)

However, for most of our users, a zoomed single-column layout is going to be less useful than switching to two columns when in landscape mode on an iPad.

On an iPhone, you should see a single-column layout in either orientation using the design we're currently testing.

[barumrho]

Can't you disable zooming to solve that problem?

[bigiain]

I suggest you ask your 40+ year old users (or any users with less than 20/20 vision) about what they think of you disabling zooming on them…

[Chris_Newton]

Yes, but that workaround has accessibility problems of its own.

[lazerwalker]

In my experience, the problem is that the Android/WP7/[other smartphone OS here] web browsers are so far behind iOS WebKit in terms of functionality that you basically have to handle each device on a case-by-case basis. Given that, a lot of developers choose to focus solely on iOS since it's the lowest-hanging fruit with a massively large userbase and a relatively-standards-compliant codebase.

For example, all mobile web browsers should theoretically throw either a resize or orientationchange event on orientation change, but some Android devices don't, with no other viable fallback, and no clear rhyme or reason as to which devices support it and which don't (other than that newer flagship devices are slightly more likely to be standards-compliant). CSS media queries are more consistently supported, but they aren't the solution to every problem.

[josephcooney]

What percentage of your users were on IE?

[shaggyfrog]

I think around 70-80%; the product the Web app was supporting was targeting schools/non-profits and other demographics where IE usage is high.

[josephcooney]

So isn't it fairly natural that IE would account for most of the bugs (if that represents 3/4 of your users)?