html5

“iPhone developers are stupid!”

by

steve says: may iphone devs burn in appstore hellI’m not really a fan of blogposts that are mere quotes, but forgive me while I post this beauty from “Apple is not evil. iPhone developers are stupid” by Peter-Paul Koch on Quirksmode;

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies.
[…]
After ten years I am fucking tired of the “Web development is not real programming” bullshit that the arrogant bastards in “real programming” are spouting because they’re too frightened to learn something new. Fuck those condescending, ignorant, self-important, stupid, blind, fearful pricks. Fuck them real hard. Where it hurts.
And fucking them real hard where it hurts is exactly what Apple is doing right now.
That’s why I changed my mind. That’s why I’m cheering Apple on. I hope the App Store approval process sticks around for a loooooooong time.

Chrome, Opera to support html5 webdb, FF & IE won’t

by

HTML5’s WebDB is one of the building blocks to create offline-enabled webapps. It allows web applications to store data in a local database and it is as such an important part in Google’s push for mobile webapps as an alternative for native mobile apps. The spec (although not finalized) is already implemented in Safari, Safari Mobile and in the Android 2.0 browser.
So WebDB will take the world by storm, won’t it? Well, pretend you didn’t read the title of this post and let’s look at some excerpts of the meeting minutes of the W3 Web Applications Working Group Teleconference of 02 Nov 2009 for more info on the state of WebDB. Charles McCathieNevile (Opera) had some good news to share:

At opera, we implemented web db […] it’s likely we will [ship it] as people have built on it

and Google’s Ian Fette joined in:

We’ve implemented WebDB … we’re about to ship it

So that’s great news, no? We can expect WebDB to arrive in Chrome and Opera! OK, so what about Firefox and MSIE? Microsoft, represented by Adrian Bateman, stated:

We don’t think we’ll reasonably be able to ship an interoperable version of WebDB

Well, that doesn’t really come as a surprise does it? No WebDB in MSIE, but surely Mozilla will support this great spec? But Jonas Sicking’s point of view might be slightly shocking to some:

We’ve talked to a lot of developers, the feedback we got is that we really don’t want SQL […] I don’t think mozilla plans to ship it.

Sorry, come again? Does that mean that Firefox will never support window.openDatabase()? Nope, they probably won’t and they provide some valid concerns (see also Vladimir Vukićević’s blogpost) in a mailinglist-discussion between Mozilla and Apple-engineers shortly after the meeting minutes were published. Summarized and simplified their objections boil down to two issues;

  • in order to have a webdb standard, you also have to specify (and standardize) the SQL-language to query that database, the question is what SQL-dialect to standardize on.
  • as the current implementations are all SQLite-based (including Google’s and Opera’s), the spec would have to describe the very specific SQL-dialect that SQLite uses (and maybe even of a specific version of SQLite)

Although I doubt that web-developers don’t want to do client-side SQL at all, writing a spec that almost mandates the use of a specific version of a specific product (even if it’s open source) can indeed be hardly considered the goal of w3.org’s standards creation process.
So back to the drawing-board for yet another spec? Based on the webapp group’s meeting minutes, Web SimpleDB (or  “Nikunj”, after the name of the Oracle-engineer behind the idea) is considered a worthy alternative by at least Mozilla, Opera and Microsoft. Let’s hope that a consensus, a finalized spec (it’s in draft now) and the first usable cross-browser implementations will arrive soon.

Voorspelling 2010: offline is het nieuwe online

by

failmailAf en toe loopt het mis in “the cloud” en dan durven nochtans doorwinterde digitale nomaden al eens klagen over de onbeschikbaarheid van hun online tools, terwijl eeuwige web2.0-twijfelaars hun grote gelijk -dan toch tijdelijk- bewezen zien.
Misschien moeten die mannen en vrouwen toch eens kijken naar de offline-ondersteuning die bv. Gmail, Google Reader, Google Docs, Google Calender, Zoho, Mindmeister en Remember the Milk bieden? En misschien moeten de webbouwers onder hen hun klanten die mogelijkheden ook beginnen verkopen? Want ik voorspel: 2010 wordt het jaar van offline-enabled webapps, mobiel maar even goed in de desktop-browser!

Google loves html5 (in Android 2.0)

by

android 2.0 aka eclairThe specs for Android 2.0 were just released and whaddaya know;

Support for HTML5:

  • Database API support, for client-side databases using SQL.
  • Application cache support, for offline applications.
  • Geolocation API support, to provide location information about the device.
  • <video> tag support in fullscreen mode.

Great, no more fiddling with Gears just for Android’s sake. Let’s hope they adhere to the relevant html5–specs the same way Apple does, so you don’t need to do differentiate between iPhone os3 and android 2.0 when creating offline-capable web-apps!
Off course there’s more than just html5 in this new Android version, here’s a short video showing some of the changes in Eclair:

Android 2.0 Official Video
Watch this video on YouTube.

A personal message for HTC to finish this blogpost: feel free to skip Android 1.6 to focus on using 2.0 as the basis for my Hero‘s next rom update 🙂

Bridging the gap between html5 and Gears

by

my trash in gmail mobileGoogle claims HTML5 on the web is the future of applications on mobiles and they present the high-end mobile version of Gmail (on iPhone and Android) as an example of what can be achieved with web-based applications. But, as I wrote earlier, the Android-browser does not support HTML5’s webdb, appcache or geolocation at all (and neither does Google Chrome). Instead Google offers similar (but different) functionality in their Gears-plugin.
Almost the same functionality, but with a different API, how did they implement mobile Gmail? Well, Appcache (a.k.a. “offline web application”) seems to be implemented separately. That  makes sense as defining which files can be stored locally is more or less a one-off job. But for more complex data-oriented offlining with a local database, Google created a wrapper-script that hides the Gears and HTML5-API’s and the underlying differences, thus offering a unified way to store and retrieve information from a local db. The code, including an example, can be found in WSPL’s svn-repository in Google Code.
And while it’s not used (or needed) in gmail, there also is a a geolocation-wrapper to abstract those HTML5 and Gears-implementations. Once the wrapper is instantiated, getting the user’s location on iPhone (OS3), Android and some others becomes as easy as doing:

geo_position_js.getCurrentPosition(success_callback,error_callback);

Great stuff, those wrappers. But wouldn’t it be even greater if Google’s browsers would support the native html5-specs, so these stopgap solutions  weren’t needed to start with?

HTML5 offline webapps vs Google Gears Localserver

by

Google Gears is a fantastic browser plugin; it allows a developer to create applications that run while offline, syncing with a server when online. Two great examples of the power of that mechanism are Gmail (both the “desktop browser” and the mobile Android-version) and Mindmeister (only while in trial, for paying Mindmeister-accounts after that period). The problem with Gears however is that it’s a plugin and not a lot of people have it installed: only Chrome-users have it by default. And that’s where HTML5 comes in; one of the areas where the new spec offers vast improvements over html4/xhtml is the ability to take webapps offline by allowing a developer to store files for offline usage and to write data to a local, browser-embedded database. Both Safari 4 and Firefox 3.5 support these features, so maybe HTML5 makes Gears already redundant in those browsers with more to come?
I haven’t gotten around to experimenting with offline databases yet, but I did already look into offline files. At first sight, Gears Localserver and HTML5 Offline Webapps indeed seem very similar; your html-page points to a manifest-file which contains a list of assets (pages, images, css, js, …) that the browser has to store for offline usage. Easy enough, no?
To get a better feel of how offlining in HTML5 works, I decided to try to write a simple WordPress plugin to replace its ‘Gears Turbo’-option. Turbo (which you can find in the Options-menu) essentially stores 1Mb of files locally, to speed up delivery of the WP-admin pages. To make a long story short; my plugin didn’t work. For starters, by default requests for non-local data are blocked, but it’s easy enough to unblock network access by adding “NETWORK:*” (with a newline before the wildcard) to the manifest. But more fundamentally; HTML5 Offline Webapps not only stores the files specified in the manifest-file, but also every html-page which points to the manifest (see my test here). There’s no way you can exclude those “master entries” from being stored. So if pages are stored, that means they have to be static and that all dynamic parts should be handled by javascript (fetching data using ajax and updating your page with it). And that, my friends, is clearly not a use-case that is applicable to WordPress admin-pages.
So HTML5 Offline Webapps is no drop-in solution to speed up delivery of dynamic pages, you’ll still need Gears to take care of that (or rely on old-fashioned carefully configured expiry- and cache-headers). But, as Google proves with the iPhone-version of Gmail, Offline Webapps combined with a HTML5 offline database can work miracles if you use it the correct way.

http://blog.futtta.be/2007/04/06/cache-header-magic-or-how-i-learned-to-love-http-response-headers/

Google hates HTML5, pushes Gears?

by

don't want no google gearsSo you bought this brand new HTC Hero and you tell everyone it’s on a par with the iPhone 3GS and its great browser? I mean, both are very recent Webkit-implementations aren’t they? Safari Mobile on iPhone OS3 is based on AppleWebKit/528.18, Chrome Mobile (or don’t they call it that?) for Android 1.5 on AppleWebKit/528.5+, and between 528.5+ and 528.18 there can only be minor differences? So HTML5-goodies (such as geolocation, localstorage and app cache) which Google is actively promoting, will work out of the box, just like on that dreaded iPhone 3GS, won’t they?
Sorry to bust your bubble, but Google seems to have decided otherwise; there’s no navigator.geolocation, no localstorage and no app cache on my HTC Hero (which is running Android 1.5 aka cupcake). You can access similar functionalities by calling the built-in Gears plugin, but mobile web-developers can’t assume that these HTML5-draft-specs are available on all modern high-end mobile handsets at all. Hell, even “big” Chrome 3.0.195.10 (which is based on Webkit 532!) does not seem to support these killer-features. Must be that Google is secretly pushing for Gears to become the default “rich internet enabler” instead of HTML5?

Firefox 3.5 and tinyvid.tv do Ogg/Theora

by

theora.orgGoogle might be pushing back support for HTML5’s <audio> and <video>-tags in Chrome, but these certainly are one of the nicer features the upcoming version of Firefox will bring us. Version 3.5 (RC1 will probably be released the beginning of July) will indeed natively support ogg/vorbis, wav and ogg/theora. And this is important why? Well, apart from the open source (Theora) vs proprietary (Adobe Flash with VP6-codec) argument, using video will allow us to get rid of the memory (and cpu) hog Flash can be (or at least to replace it by another cpu-hog 😉 ).
Now having Ogg/Theora built right into your favorite browser might be great, but you’d need a place where you can use that as well, no? Well, there’s no support for Ogg on YouTube yet, but that void can be filled by TinyVid, an “experimental Ogg video uploading and converting site”. Especially the converting-part is handy; just enter the URL of a YouTube, Vimeo or Daily Motion-video and TinyVid will download and convert it for you a few minutes later (depending on the length of the conversion queue).
So you’re having big fun, uploading, converting and watching, but wouldn’t you want to show off those great vids on your open source blog as well? Easy-peasy;
<video src='http://tinyvid.tv/file/3h31b472fv0ng.ogg' controls='controls'></video>
And if you’re in a partcilurly good mood and you want friends that are not running an Ogg-enabled browser to be able to see some disco, you could even try this;
<video src="http://tinyvid.tv/file/3h31b472fv0ng.ogg" controls="controls">
<applet code="com.fluendo.player.Cortado.class" archive="http://tinyvid.tv/static/cortado.jar" width="640" height="368">
<param name="url" value="http://tinyvid.tv/file/3h31b472fv0ng.ogg"></param>
<param name="BufferSize" value="4096"></param>
<param name="BufferHigh" value="25"></param>
<param name="BufferLow" value="5"></param>
<param name="duration" value="257.369"></param>
</applet>
</video>
And that’ll result in Thom Yorke doing this disco-version of “Everything In Its Right Place” in Theora;

Firefox 3.1; Mozilla Corp’s answer to Google Chrome

by

Firefox 3.1 is just around the corner and I’ve been using the beta’s for a couple of months now, but I didn’t really feel the urge to write about it up until now. But with things heating up between Google Chrome (already out of beta!), Safari and Firefox and with new versions of MS Internet Explorer and Opera in the making as well, one can’t really stay indifferent I guess?
First off; a non-exhaustive list of changes;

So if FF3.1 performs that great in Sunspider, does it really feel that much faster as well? To be honest; it doesn’t. Or at least, it didn’t, at first. But here’s a tip; if you’re a bit like me you’re bound to have a lot of extensions installed (and disabled and uninstalled and not compatible and …), you might have some forgotten tweak in your about:config and you probably have huge history and bookmark-databases. In that case do yourself a favor and start from scratch with a new profile and Firefox 3.1 will truly fly.
Off course not all is perfect. I don’t like the fact that tabs inadvertently get moved to a window of their own regularly. And Flash still crashes FF all too often, Firefox really needs something like the process isolation in Google Chrome and MS IE8’s loosely coupled IE, but that might be more than just a small CR.
All in all, with Firefox 3.1 the Mozilla-folks seem to have almost everything to fight the new kid in town. You can download the latest beta here and test for yourself. Let those browser-wars rage!

New: cross-document messaging

by

With new versions of our trusted browsers coming out, web developers who like living on the edge can start  using some of the new features that are becoming available. One such goody is cross-document messaging, which is part of the HTML5 draft spec.
Cross-document messaging allows children of a window (think iframes, popups, …) to communicate using JavaScript, even if they originate from a different domain. This means that Instead of just iframing an external application, without being able to integrate further, your page can send and receive messages to/ from it. PostMessage could even be used to do cross-domain XHR (a hidden iframe on the same domain as a a remote datasource can be used as a proxy to perform XmlHttpRequests on that remote domain) untill the real thing hits the streets as well.
The two additions that allow you to perform such messaging, are window.postMessage and an eventlistener for events of the “message” type to handle the message. A pretty straightforward example of this can be found on JQuery’s John Resig’s site (see also his lastest blog entry about postMessage). As cross-domain javascript can be a potential big security risk, taking into account some precautions is really really really really really necessary. Really!
On the downside (as if security is not a problem); this brand new feature is only available in Firefox 3 for now. My own little test (a copy of John Resig’s example with some minor tweaks) worked in Opera 9.2x (and 9.5b) as well, but postMessage seems to have been dropped from the final Opera 9.5, as the tests on Opera Labs don’t seem to work any more either. Support for postMessage is also available in Webkit (Safari‘s backbone) nightly builds and in Microsoft’s IE 8 BETA (with the event being ‘onmessage’ instead of ‘message’ and some other quirks but hey, this is beta, no?).
So expect postMessage to be available in all major browsers by the end of the year. But why wait if you know that Facebook is already using postMessage in their chat application. I wonder what they fall back to if it is not available though …