Aw man. As a bootstrapping web business guy, I can say I've had way more problems with supporting iPads and iPhones than IE. IE costs me $0 to support, and I don't even bother (nobody asks!). Supporting hip and popular Apple browsers can run me a grand in a fast minute. Pleasing early adopters without working really well on the iPad3 is a tough sell.
I think startups fighting to support < IE9 is a done decision (don't do it). Start worrying about mobile and tablet platforms instead. 'cause the future, it's knocking.
I'm not crazy about getting an iPad myself, but I'm starting to feel cornered into spending hundreds of $$ on one just to keep those early adopters happy. I think this is where the real browser/device compatibility discussion is, not around IE.
We're in a similar position, except that we did recently drop the money for a new iPad. FWIW, it's actually a nice piece of kit, as long as you don't mind playing by Apple's rules of course.
However, the browser idiosyncracies drive me nuts, and we spent considerable time not just updating all our graphics but also redoing way too many different parts of our HTML, CSS and JavaScript in order to get the high-res images to display properly and to have the correct version of each image download efficiently on both Retina and lower resolution displays.
Not all of this is Apple's fault. Some of it comes from limitations in the current HTML and CSS specs, which would apply to high-res displays on Android devices as well. But some of it seems to be entirely due to choices in how iOS Safari does things, and the problems aren't limited to high-res images.
I'm still not entirely happy with many of the solutions we are using. I think we have a practical workaround for most of the issues, but often the results behind the scenes are just nasty and hacky. And as you say, it has been vastly more work than supporting IE9, which required approximately zero extra effort.
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.
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.
> 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.
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-).
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...
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.
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?
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.
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…)
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.
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.
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".
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.
The server should not have to decide which image to send, based on whatever it can gather of a combination of various factors, including device display resolution capability (double-density vs regular pixel mapping) and connection quality (wireless vs broadband) or whatever else comes into play. The server should be advertising the capability of high res images and the user agent should be requesting them if it wants.
That's a great idea, but that's not currently how it works. All of the high-res website image stuff that I've seen all uses client-side JavaScript to fetch the 2x images.
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.
"Early adopters" - surely we're beyond calling IPad owners early adopters? As for desktop and tablet support, is it really that hard with excellent toolsets such as Bootstrap etc. ?
iPad _3_ owners are 'early adopters' to me - and I understand the gp as having trouble supporting the latest and greatest features - or changes- in those things.
Like the retina display, which does seem to require some dev love to look decent, according to statements on this very site.
Sure, they're early to you, but not to the consumers or industry. The adoption cycle applies to a product family, not model. The iPad is not a new device.
This is where things like 320 and up: https://github.com/malarkey/320andup and future GUI libraries (Twitter bootstrap as a single example), will start to change everything.
The main problem with what you've mentioned is the size issue. So for startups that are dire in need of building fast and getting things right but not looking stunningly beautiful - this is an option.
The people with too much money to know what to do with it, can then build things in a crazy way with agencies for the logo, different agency for web design and then a 3rd agency for build etc.
As an almost universal rule of thumb, there is no perfect simulator/emulator substitute for a target hardware platform.
For example, the iOS Simulator runs in an x86 environment. There's no way to throttle it to run at hardware spec speeds, never mind that the Safari in Simulator is quite possibly running different code than the Safari that ships on the devices themselves.
I had never heard of the iOS simulator! Thanks for mentioning it, it just changed my friggin life. I'm on Snow Leopard, and there is no free upgrade to Xcode 4.0. I hunted down a torrent of 4.2 and got it installed though, and the simulator is pretty great.
My larger point is that the hassle isn't supporting X version of a browser anymore, it's supporting X version of a browser on various hardware devices. Web-dev hell isn't going to be the fault of IE anymore, it's going to be the fault of mobile platforms with differing browsers, screen-sizes, and use patterns.
I think startups fighting to support < IE9 is a done decision (don't do it). Start worrying about mobile and tablet platforms instead. 'cause the future, it's knocking.
I'm not crazy about getting an iPad myself, but I'm starting to feel cornered into spending hundreds of $$ on one just to keep those early adopters happy. I think this is where the real browser/device compatibility discussion is, not around IE.