(Last Updated on 19 August 2009)
So you’re making a site “optimised for the iPhone”. Hurray! I was starting to miss those “this site looks best in Internet Explorer 5 with 800×600 resolution” badges. So here are my top two iPhone develpment techniques.
1. Don’t do browser sniffing. The iPhone is just a phone, and Safari is a web browser. There are other browsers out there capable of rendering your content. There are even other mobile devices out there!
2. Think very carefully about why you want to use maximum-scale on viewport or user-scalable=0/ no. Is it for valid application reasons (think of zooming in on something in a game, whereby the zoom event does an XHR to the server to show a higher-scale map or higher-resolution image) or is it just to protect your lovely design?
If the latter, then it’s just the iPhone equivalent of setting fonts in pixels for old versions of Internet Explorer, as it prevents a user with low vision zooming the screen to a magnification that they want. And that is, of course, evil selfish and stupid.
That’s it. Have a lovely day.
sent from my ZX80.
On Monday, Rich Clark, Jack Osborne, Mike Robinson, Remy Sharp, Tom Leadbetter and I launched HTML 5 Doctor, a resource with small tutorials and references about—guess what? That’s right!—HTML 5. I hope it become the resource that I wished I’d had access to when doing my redesign after Xmas.
Yesterday, Sitepoint published an article of mine they called Yes, You Can Use HTML 5 Today!. The changed title made it seem like much more of a call to action than my original title “A snapshot of HTML 5″, updating Lachlan Hunt’s 2007 A List Apart article A Preview of HTML 5, and earned me comments berating me that current HTML 5 support isn’t perfect, but never mind.
Dull meta-note: I’d more or less given up blogging small announcements and links like this, as Twitter seemed more the medium for it. But at the @media conference, a lot of people who work in Evil Corporates told me that they can’t access Twitter at work, so I’m making a conscious effort to announce here as well.
video element is the one that seems to excite n00bz the most when I do introductory talks about HTML 5, yet it was always the element that seemed to me to be furthest away from cross-browser interoperability.
Originally, the specification (being an Open Standard) said
User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format.
Ogg is a free, open standard container format maintained by the Xiph.Org Foundation which claims that it is unrestricted by software patents. Firefox and experimental video builds of Opera support Ogg for the element.
However, there were complaints from Nokia (PDF) and Apple that Ogg formats are not good enough technologically and still within patent lifetime and therefore susceptible to submarine patents (unexpected future patent challenges).
Therefore, the spec was revised with the much more wishy-washy
It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: […] This is an ongoing issue and this section will be updated once more information is available.
Yesterday, Ian Hickson removed any mention of codecs from the spec because of impasse and non-interoperable implementations: there is no suitable codec that all vendors are willing to implement and ship. He writes
Apple refuses to implement Ogg Theora in Quicktime by default (as used by Safari), citing lack of hardware support and an uncertain patent landscape.
Google has implemented H.264 and Ogg Theora in Chrome, but cannot provide the H.264 codec license to third-party distributors of Chromium, and have indicated a belief that Ogg Theora’s quality-per-bit is not yet suitable for the volume handled by YouTube.
Opera refuses to implement H.264, citing the obscene cost of the relevant patent licenses.
Mozilla refuses to implement H.264, as they would not be able to obtain a license that covers their downstream distributors.
Microsoft has not commented on their intent to support
video at all.
So does that end the dream of interoperable, no-plugin video in the browser? Perhaps not entirely.
Some point to the BBC format, DIRAC as “the BBC has no IPR interest in any implementation of Dirac by anyone, based on the Dirac software or not”. However, the answer to the question “Do you infringe any patents?”
The short answer is that we don’t know for certain, but we’re pretty sure we don’t. We haven’t employed armies of lawyers to trawl through the tens of thousands of video compression techniques.
is unlikely to satisfy those who are worried about submarine patents in Ogg.
Sun Microsystem’s announcement of their OMS Video format was exciting:
The Web needs royalty-free video and audio codecs.
…OMS Video seeks to bring an updated royalty-free variant from the h.2.6x video codec lineage to the open source / royalty-free community. With the open source / royalty-free codec community, the OMS Video initiative seeks to collaborate through shared interests and common royalty-free technologies, to unleash innovation, and to update outmoded RAND (“reasonable and nondiscriminatory”) standardization processes to Web speed.
An OMS Video specification is published, but with the Oracle buy-out, I’ve no idea what’s happening with the specification.
I’m not pointing the finger at any other browser manufacturers because it’s entirely understandable after the EOLAS patent debacle that browser vendors are frightened of submarine patents. (I work for Opera which supports Ogg Theora/Vorbis but this is a personal site not the opinion of employers blah.)
What this sorry story really shows is that closed standards and proprietary formats are the enemy of an Open Web.