Good to see Facebook putting pressure on the mobile manufacturers to standardise their HTML5 implementations

Try it here http://rng.it

Facebook today addressed three challenge areas that make it hard for developers to build apps on the mobile web: app discovery, browser fragmentation, and payments. As part of the second one, Facebook released Ringmark, a new mobile browser test suite, which it developed with open web technology company Bocoup. Facebook will soon open source it, publish it on GitHub, and donate it to the W3C.

The test suite for mobile browsers helps you, the developer, understand which mobile browsers support the functionality your app needs, such as orientation lock for games or camera functionality for social apps. Facebook says it is comprehensive, fair, and tests the feature sets which developers really need.

zdnet article

Original post from April 18, updated for the 1 year anniversary of apple web-apps going dark!

Being a developer of several web-apps for both pc and mobile phones, I read with interest way back in March the brouhaha regarding whether Apple had intentionally hamstrung web-apps performance on the iPhone by preventing their use of its brand shiny new Nitro javascript engine.

The question that remains is whether this is an oversight on the part of Apple, or whether it is quietly intentional. With the company’s stand against Flash, an open standard of HTML5 should be its next logical thing to support. But if it doesn’t fix the problem in future versions of iOS, that leads a hefty credence to the rumor mill.

The debate primarily centred around whether with their update to Safari in iOS 4.3 Apple had purposely excluded web-apps for security reasons (JIT’s ability to mark memory pages in RAM as executable) or something more nefarious, such as perhaps feeling threatened by the rise of web-apps and a potential hit on the native app-store revenue….that debate rages on.

As I mentioned, I develop a number of websites with web-app versions customised to run on mobile phones. One of these apps is SwipeStudy (a flashcard study tool) which I submitted to the Apple web-app library, which is (or perhaps was) a very useful and thoughtful site provided by Apple for developers to showcase their (typically freeware) web-apps. However on my last update I mistakenly entered the web address without the http:// prefix (my mistake I admit) which causes the link to wander off to some internal Apple error page…doh!

I have been trying to contact apple to rectify this link, but started to suspect and now after the passing months am pretty sure that they are no longer maintaining this site. In fact the last update to was 3rd Dec 2010, over 4 months ago a year ago!

So I conclude with the question that if Apple are playing with a fair hand with respect to web-apps on iOS, why would they stop updating this site. I guess they may just be too busy dealing with their undoubted many successes, or could they see the writing on the wall with a business model based on app-store revenue when the whole app-ecosphere is converging on html5?

But I think there’s actually a very good reason why we should, in fact, embrace the term “HTML5” as an overarching buzzword for this latest round of web standards and specifications. Our industry has proven on several occasions that we don’t get excited about new, interesting, and useful technologies and concepts until such a buzzword is in place.

“AJAX,” of course, is the canonical example of this. DOM scripting, XMLHttpRequest, and dynamic Javascript all existed long before the term “AJAX”. But it wasn’t until the clever term was coined that anyone really cared. As soon as we had a single, simple word we could all get behind, Javascript really took off. A proliferation of frameworks and libraries hit the scene, and suddenly we were all building dynamic web projects. And the term was misused. Badly. Left and right. Much of the great code being written didn’t use XML. Much of it wasn’t asynchronous. But most of it was pretty great, and it was usually called “AJAX” wether it really was or not. And pedants went crazy. They argued about the semantics of the term “AJAX” until they were blue in the face. But in the end, no one would argue that “AJAX” wasn’t a good thing for our industry. Without that term, we wouldn’t be where we are today.

And it’s not just AJAX. If you want other examples, look no further then “Web 2.0” and “Microformats.” “HTML5” is today’s “AJAX.” Just as with “AJAX,” people are misusing the term all over the web. But it wasn’t until influential people and companies (notably Apple) started misusing the term that web developers at large (myself included) starting taking this new collection of web standards, specifications, and best practices seriously, as something that might be useful before 2022.

Sometimes we just need a word to rally behind. And put in job descriptions. And claim we “support” (another word that is mostly meaningless). It’s a language thing and a human psychology thing.

So be pedantic about the semantics of “HTML5” if you want, but don’t be surprised if no one really listens. This is something most people can understand and get behind. This, on the other hand, is not.

http://jeffcroft.com/blog/2010/aug/02/term-html5/

For the home page of my site I wanted to cause certain divs to fadeIn using jQuery after varying amounts of time. In javascript we can use setTimeout() to schedule an arbitrary function call for some point in future. However the function works differently between Firefox and Internet Explorer (MSIE).

In FireFox, you would do this:

setTimeout(myFadeIn(), 1200, "id1");
setTimeout(myFadeIn(), 2700, "id2");
setTimeout(myFadeIn(), 3500, "id3");

Except, MSIE doesn’t like this. And in fact the additional parameter is not even part of the official javascript spec.

So how can we work around this ?

Closures. In the below example I use closures to pass an anonymous function to setTimeout() that contains in its “frozen in time local scope” the id of the div to fadeIn.

// Return delayed fadeIn closure function 
function delayFadeIn(id){
    return (function(){
        $('#'+id+'_img').fadeIn(1000);
    });
} 

//Setup three delayed fadeIns by passing closures to setTimeout
function setupFadeIns(){
    setTimeout(delayFadeIn("id1"), 1200);
    setTimeout(delayFadeIn("id2"), 2700);
    setTimeout(delayFadeIn("id3"), 3500);
}

And this will work in both MSIE and FireFox