Jake Opines : Browsers, JavaScript

Events to Expect when Dynamically Loading iFrames in JavaScript - Take 2 (thanks Firefox 3.5)

jacobl — Tue, 18 Aug 2009 17:55:52 GMT

Just two months ago, I wrote a post on the JavaScript events you could expect when loading iFrames dynamically. Since the behavior highly depends on the browser you are using and the whims of the developer who decided what to fire and when, I put together a nice table of Browser v. Content-Disposition listing the events and any return codes that come along with them.

This is where it all falls apart. With Firefox 3.5, it appears as though my table must change. Firefox no longer fires onload when the Content-Disposition is set to Attachment. This is the same behavior that can be expected in Safari and Chrome. Even though it appears as though there's a growing consensus outside of the IE camp, I do not think it's moving in the right direction. (IE's behavior is clearly the best here: more, specific, expected)

Disappointedly, I'm posting this updated table depicting the events you should expect when dynamically loading iFrames:

Thanks for nothing.

Caching JavaScript on Your Terms

jacobl — Sun, 19 Jul 2009 13:34:00 GMT

Browsers tend to do what they like with your static content: deciding what to cache and when to refresh. On the server-side, you can specify that certain file types have a designated TTL (time to live) and that works in many cases. There are other cases when you either don't have access to the server's configuration or you need to make sure everyone has the latest bits of JavaScript.

With every release of VizitSP, our SharePoint Document Viewer, we need to make sure that users get all of the changes we've made. To achieve this, there's a very easy trick that can keep our files cached exactly as long as they need to be and it involves le query string.

What the HTTP Caching Specification Says

ThinkVitamin posted an article about the correct way to pull off browser caching while playing by the rules. This is a great way of doing things; and, if you control the server your site is running on, please do that; however, if you're a component or an installable product like our Vizit, you might not be offered that liberty.

According [to] the letter of the HTTP caching specification, user agents should never cache URLs with query strings. While Internet Explorer and Firefox ignore this, Opera and Safari don’t - to make sure all user agents can cache your resources, we need to keep query strings out of their URLs.

Supporting only IE and Firefox didn't sound that attractive to me, so I decided to do a bit of research. Digging around the net, I found out that Safari stores its cache in

        1: C:\Documents and Settings\[username]\Local Settings\Application Data\Apple Computer\Safari\cache.db  

It's a SQLite database, so a quick download of the free Sqlite3Explorer tool made querying this very easy.

       1: sqlite> select request_key from cfurl_cache_response LIMIT 735,5;       2: http://graphics8.nytimes.com/js/app/lib/NYTD/0.0.1/tooltip.js       3: http://graphics8.nytimes.com/images/global/icons/feed_icon_16x16.gif       4: http://graphics8.nytimes.com/js/app/analytics/gw.js?csid=H07707       5: http://graphics8.nytimes.com/js/app/analytics/revenuescience.js       6: http://graphics8.nytimes.com/js/app/analytics/controller_v1.1.js  

What do we have here? A static file (js extension) with a query string in Safari's cache.

This got me thinking about Opera and Chrome... luckily, they make it trivial to browse their cache using the about:cache URL. This is what I found:

chrome

opera

Cool huh? It appears as though IE, Firefox, Safari, Opera, and Chrome ignore this bit of the spec and I'm OK with that.

Versioning Your Static Content

It's important that you update your version query string parameter with every release or this technique wont work. With Vizit, we do it as part of our build process. Everywhere in the code that includes a JavaScript file we append '?ver=VIZIT_VERSION'. At build time, we sift through all the files and replace that with the version number of our assemblies. Very nice indeed.

Results

On its first load with an empty cache, an upcoming release of VizitSP weighs in at about 420 KB. That small size is achieved through CSS image spriting, JavaScript compression, concatenation, and the SharePoint Web Front Ends gzipping it all; however, a second load will see that size drop to a measly 75 KB. Compare that to the New Your Times homepage which weighed in at 763 KB on first load, only dropping to 370 KB after cached. While the New York Times is a news site which means much more of it needs to be refreshed all the time, taking advantage of the fact that Vizit can update at will makes for a very nimble and fast-loading web application.

Flash, Silverlight just Stop-Gaps

jacobl — Mon, 06 Jul 2009 13:31:01 GMT

The F.U.D.

There has been a lot of talk in the past few weeks about HTML 5 and its supposed takeover on the web (or lack thereof). It's only a matter of time before Flash and Silverlight become less relevant. The CEO of Adobe, Shantanu Narayen, defended their position in the future of the web during the company's last quarterly financial call, saying:

So [, we're] clearly supportive in terms of making sure as HTML 5 is evolving that we will support it in our web authoring tools but from the perspective of continuing to drive Flash and innovation around Flash and rich Internet applications, we still think that actually the fragmentation of browsers makes Flash even more important rather than less important.

The part of the question that he is dodging here is how a more powerful and more broadly supported standard will affect Flash in the long term.

Recently, InfoWorld posted an article about this very topic. It's a good read and the author gets a lot of things right. He talks about how IE will be a critical milestone for HTML 5 to overcome:

The exception is Microsoft, which therefore is in a difficult situation, says Almaer. The company has heavy investments in trying to propel Silverlight to dominance. "That's a big elephant in the room for them because you can imagine the Silverlight team [whose] whole existence is to add [this] functionality in. [But] if Internet Explorer puts it already in there, why do we have Silverlight?" he asks.

Good question. What incentive does Microsoft have, from a Silverlight perspective, to further the advancement of HTML 5? When IE adds support for all of the capabilities that Silverlight has to offer directly into the browser, does Silverlight still need to exist? No, it doesn't. It's arguably in Microsoft's best interest to keep its feet stuck in the mud and continue to not be a 'standards-based' browser.

The Push

This roadblock is ever more apparent with the announcement of Firefox 3.5 RC. It, along with Safari and Chrome, already support much of what HTML 5 has coming up in the pipeline. Internet Explorer is the only major player that is mum on the subject.

Fortunately, the push for more advanced capabilities in the HTML standard is so great that some of IE's shortcomings can be sidestepped. There is a project put together by Google on SourceForge called ExplorerCanvas. It allows for 2D command-based drawing. Browsers like Safari, Firefox, Chrome and Opera all support the HTML5 canvas... but Internet Explorer does not. The ExplorerCanvas project overcomes this by taking Microsoft's Vector Markup Language and wrapping it in JavaScript to create the desired effect. The DotImage Web Annotation Viewer that we use in our SharePoint Document Viewer, VizitSP, employs the ExplorerCanvas to let users author annotations in a very natural way.

Another example of this push is Kroc Camen's recent publication of Video for Everyone. By using the upcoming <video> tag along with Flash and Quicktime object tags, he is able to provide a series of fallbacks that can offer HTML5 love to people who deserve it while providing an acceptable experience for those who don't.

One area where I think InfoWorld gets it wrong is in its comment about Google's possible apprehension toward pushing the new standard:

..its YouTube subsidiary uses Flash for its video, but the inclusion of HTML 5 capabilities in browsers might cause YouTube to rethink that decision, notes Fette. "It's a cost/benefit analysis that they'd need to make."

For a couple months now, YouTube has had an HTML 5 demo available on its site. The example shows that, with a capable browser, you can view video without any codecs or plugins. It just works. YouTube has clearly already begun to invest the time into moving away from Flash as soon as it's feasible. Without much effort, YouTube could begin serving up HTML5 video to those browsers that support it. To push the envelope even further, YouTube could add features to the HTML5 version that are either not possible to do in Flash or just as an incentive to get people to use better browsers... or to give IE a hint.

The Point

The point here is that we can't allow such a fundamental piece to the future of the Internet rely on plugins. Something that is so core to the direction that the web is vectored toward deserves to be treated as such: core. While it might take us a while to get there, we will --even if it means dragging the old browsers kicking and screaming behind us. Until then, Flash and Silverlight can rule the roost.