Styling File Inputs in iOS6 with jQuery Mobile
File this post under: “stuff that’s in obscure forum posts but not really documented well”. As per a previous post, iOS6 brought about access to the camera in Mobile Safari. While access is not real time (getUserMedia would be amazing), we are able to prompt the user to take a new photo or access the camera roll. Presumably for security reasons, styling file inputs in desktop browsers has always been hell on earth. Mobile is much the same.
What you can do as a work around is rely on native browser functionality where clicking a <label> triggers the clicking of it’s associated <input>. I’ve relied on the native jQuery Mobile button styling for speed, but you can achieve pretty much anything. Hiding the input can be achieved in various different ways, but as far as I know it cannot be display: none; for security reasons. Setting visibility: hidden; or opacity: 0; will all achieve the same effect, and setting position: absolute; will take it out of the page’s flow.
You can see it in action in the JSFiddle below.
What iOS 6 Mobile Safari Offers Front End Devs
Update: Now that iOS 6 is out and the NDA is no more, Max Firtman has posted an excellent summary of new iPhone 5 and iOS 6 mobile Safari enhancements and regressions. It goes into further detail and mentions features that couldn’t be publicly announced while still under NDA (not that I was, I’m not a registered dev).
Corrections: Although I recommend checking out the above link, I received two corrections via email from Apple. One regarding smart banner documentation and one clarifying css filter support.
Here’s what we know about Mobile Safari in iOS 6 so far, and what it brings to the table for front end developers. I expect there’s more to come in future betas and as people experiment with the current beta more.
Web Inspector via Remote Debugging
The pre-existing developer tools for iOS are limited to say the least. A console.log is flattened to a single level, without actually presenting the contents. iOS 6 introduces the Safari Web Inspector to both the iPhone and the iPad via the Safari ‘Remote Debugging’ interface.
It implements a similar interface to how the Chrome for Android remote debugging works. Safari remote debugging acts in a similar fashion, such that when you select an item in the Safari desktop inspector, it is highlighted on the iOS device.
Prior to this, the only alternative was embedding Firebug Lite, which while powerful, is not designed for touch screen devices.
As far as I can tell, the old, flawed Developer Console has been removed.
Many thanks to Andrew Harrison for fact checking and screenshots.
<input type=”file”>
Finally, it’s here. You can now upload photos and videos from the Photo Library using a regular input element. This was previously only possible via the use of Phonegap etc.
This is a real game changer for mobile apps.
No word yet on if it allows you to capture a new photo. It does.
Real time camera streaming has been confirmed as not supported.
Smart App Banners
The new Smart App Banners are a way of showing Safari users a message indicating that a native app for the website is available in the App Store. While not really a great thing for those of us hoping to move apps back towards the web, it’s still a good experience for the end user. It’s also possible to preserve the page/state/view and send this to the native app. Documentation is available on the Safari Developer Library.
Picture via Wired.
Web Audio API
How useful this is remains to be seen. Web audio tends to be fairly handicapped, regardless of browser, operating system or device. Microsoft’s HTML5 Cut The Rope game still used Flash to play the sound effects. I truly hope the iOS implementation changes that, but I’m also a realist.
CSS Filters
According to the Can I Use report, these are only supported in Chrome 18+ with a -webkit- prefix. CSS Filters are also supported in Safari 6, on Mac OS X Lion and Mountain Lion (10.7 and 10.8, respectively).
Full Screen View in Landscape Mode
Interesting by itself, but with desktop browsers beginning to land support for a full screen API - can this be triggered progammatically?
requestAnimationFrame
This has landed, albeit with a webkit prefix.
You should be using the Paul Irish polyfill anyway.
App Cache Upped from 5MB to 25MB
I believe it used to show you a dialog asking for more if you exceeded the 5MB limit.
JPEG Downsampling Ceiling Lifted
JPEG downsampling no longer occurs at 2MP, and instead kicks in around the 5MP on supported devices. The iPhone 3GS and 4th gen iPod touch remain at 2MP. That’s if your carrier isn’t downsampling for you (AT&T, Optus in Australia).
Faster JavaScript Performance
This happens every year, so it’s not really news. Nitro was previously brought to home screen apps giving them a massive performance boost. Nitro hasn’t yet been brought across to UIWebViews, one of the many reasons that the Facebook app is a steaming pile of shit. Maybe future iOS 6 betas will bring Nitro to UIWebViews? Maybe it’s already in iOS 6?
Mobile Safari Wishlist — What Devs Want
This years WWDC in June will hopefully bring about a new iPhone and iOS 6. But in reality, pundits are calling an October release far more likely. While Apple has been slowly closing the gap between mobile Safari and native application development, there is still a host of issues holding mobile Safari back. What a lot of it boils down to is granting software access to hardware components. Stabilising the home screen app experience. Ironing out inconsistencies.
So what do front end developers desperately want from the next version of Mobile Safari?
Home Screen App back to Safari
Fantastic! With a handfull of <meta> tags, you can turn your web page into standalone, chrome-less home screen app! But the second you click a non-ajax link (or external links) - you’ll be thrown straight back into Safari. While it’s not really a problem if you’re writing single page, MVC or AJAX centric applications from scratch; try serving an existing page-based layout to run as an app and you’re gonna have a bad time.
Workaround: A StackOverflow question along the same lines features a host of pre and post iOS5 solutions hacks.
getUserMedia/Camera/File Access
It’s currently impossible to take new (or load existing) photos without the use of some intermediary like PhoneGap or Titanium. More frustrating yet is the inability to upload anything in mobile Safari at all. I’m sure part of this stems from iOS not having an exposed file system, but it’s been notably missing for a long time now.
The new and immature getUserMedia functionality at least gives desktop websites the ability to access webcams. Because it’s only available in Opera nightly builds and the correctly flagged Chrome, Addy Osmani wrote a polyfill that no doubt uses Flash to patch support. That doesn’t do much for us on iOS.
Workaround: PhoneGap etc.
Device Orientation Lock
Speaking of PhoneGap founder Dave Johnson, I was lucky enough to catch his talk at the recent WDC12 conference in Melbourne. A spec is underway for a device orientation lock, resulting in layouts that are explicitly portrait or landscape only. This would help further bridge the gap between web and native by allowing apps to only work in one mode.
Workaround: Currently it can only be hacked together with CSS transforms triggered via media queries on device orientation changes. Undesirable.
WebGL
It’s possible to build some pretty amazing stuff in WebGL using wrappers such as Mr Doob’s mind-blowing three.js. His work on three.js has made it incredibly easy to get started building 3D scenes without having to write your own texture and lighting plugins.
Unfortunately iOS does not officially support WebGL, although it can be enabled on jailbroken devices with this recently released app. It relies on the fact that WebGL is actually installed, but not enabled for Safari.
WebGL was added to iOS 4.2 for iAds but Apple has not yet turned it on for general browsing and the like. Enabling WebGL for single applications has been done in the past but this is the first tweak that I know of that applies across the whole OS, including Safari.
navigator.connection.type, navigator.battery etc.
It seems that all the cool stuff seems to exist on the navigator object. In iOS we were already sourcing geolocation and connectivity via the navigator object, but there’s heaps more coming in the form of specs and proposals.
Android web browsers lead the way in exposing a navigator property that reveals the type/quality of the connection the device is receiving. It’s therefore possible to determine if the device is EDGE, 3G, WiFi or I guess LTE connected. Safari on iOS is only capable of differentiating between online and offline modes, exposed by the navigator.onLine property. You can also bind events that listen for the ononline and onoffline events too.
In his talk on AppCache manifests, John Allsop touched on the user experience methodology of listening for the online/offline events and enabling/disabling submit buttons respectively. Why not take this one step further by serving tailored resources and displaying spinners relative to the network speed? iOS already does it at the system level, so why can’t your app?
Sidenote: I only stumbled across this disparity because I was trying to implement the above for a UX Lab experiment.
Double sidenote: PhoneGap founder Dave Johnson mentioned that, funnily enough, a call to navigator.battery actually decreases battery life.
Proper Resume and Suspend
Home screen apps always start from scratch when opened.
Even if they are reopened via multitasking.
Seriously.
Workaround: Preserve the state with localStorage? I guess?
Non-binary Device Zoom
Setting the acceptable zoom levels in the viewport meta tag is quite final. When building a native-ish application, it’s generally advised to set the zoom and min/max values to 1.0. so users don’t accidentally scroll “native” elements. But doing so completely removes the user’s ability to resize images and resources displayed within the app. Think a mobile Safari Facebook where you can’t zoom any of your friends photos.
Workaround: Hilariously bad. -webkit-scale styles bound to events.
Did I miss something? Found a factual error? Let me know in the comments.
