Tag: javascript

Posted on

Microsoft and Nokia adopt jQuery

(Note: This entry was originally published on the Skyscanner Geeks blog.)

Here’s something I didn’t see coming:  Microsoft and Nokia have announced that they are adopting jQuery as part of their application development platforms. 

What this means on the Microsoft side of things is that they will provide an intellisense-annotated version of jQuery for Visual Studio 2008 (available as a separate download in a few weeks), and will also distribute it as part of the forthcoming ASP.NET MVC release.  Expect it to be even more tightly integrated with the newly announced Visual Studio 2010. (We’re talking about products with 2010 as part of their version name? Already?)

Further notes on the announcement and integration:

We use YUI as the base library for our JavaScript code at Skyscanner, but jQuery is a sweet and slick package. Making it part of the ASP.NET MVC release is a splendid idea. The ASP.NET page model has always felt fat and bloated to me, and the Atlas extensions are a very clever but awkward hack to tap into this model. The combination of ASP.NET MVC + jQuery might actually allow you to write clean web pages with progressively enhanced Ajax functionality out of the box.

Might .NET actually become a cool platform for writing web apps?

Posted on

Wiggle stereoscopy, follow-up

Almost immediately after putting up my posting about Wiggle stereoscopy with Javascript, I got reports of funny behaviour with Internet Explorer. I can’t say this came as a great surprise.

To recap on the technique, the core idea was to:

  1. replace a composite image with a <div> of a fixed size,
  2. set the background-image of this div to be the same as the replaced image, and
  3. flip the position of the background image every 120ms

Replacing the composite image with a div

Toggling the background image position

You can see the original script in action in Example 1.

The problem lies with the way Internet Explorer handles CSS background images. If IE’s cache settings are at their least forgiving (i.e. check for newer versions of stored pages “Every visit to the page”), changing the background-position of the background image causes IE to requery the web server for the image in question. The answer will generally be “HTTP 304: Not Modified”, so at least it doesn’t re-download the image again, but there’s a good chance that 120ms (the flicker rate) is not long enough for the server round-trip to complete. Result: IE spends all of its time checking for a new version of the image, and no time at all actually displaying anything.

Internet Explorer set to check for a newer version of a page on every visit

This problem is comprehensively documented at FiveSevenSix.com. There is a workaround involving server settings, but that goes against my desire for a keeping the technique nice and simple to implement. Alternatively, I could probably have used a variant of the double-buffering technique to fix it. But upon reflection I wondered if it was worth using background images at all.

Background images are perfect if you want to transform a piece of naked markup (like a <ul> list) into something graphically pleasing. But the wiggle technique is specifically designed to animate an existing in-line image. So: the new version of the script (1.1) does the following:

  1. It wraps a <div> around the <img>,
  2. sets the overflow property of the <div> to hidden, so that the excess parts of the image are masked off, and
  3. changes to position of the <img> itself every 120ms.

Example 2 is running with version 1.1 of the script.

Another problem that the original wiggle script had was that even with IE’s cache settings at a more normal level, it interfered with the mouse hovering over any hyperlinks in the same page: the hand cursor would change immediately back to an arrow, and in some configurations the url of the hovered link would also instantly disappear from the status bar. Version 1.1 fixes this, too.

Posted on

Dynamically created (or included) Javascript

Dynamically created page elements? No problem. Dynamically created Javascript? As in, using document.createElement() to create a <script> element? Sounds like black magic, and it’s not something I would have tried myself until I saw the article @import voor JavaScript on Naar Voren (in Dutch). Basically, it’s a technique for giving Javascript the ability to include other script files “on demand,” much in the same way as PHP’s include() and include_once() functions.

This technique has actually been around for a while: a quick google showed me the article “Javascript includes – yet another way of RPC-ing”, by Stoyan Stefanov from July of this year, which in turn points back to articles from 2002. In addition to making the whole include() thing possible (a fantastically useful feature), using dynamically generated script also allows you to use make remote calls to other domains–something the HmlHttpRequest object forbids. In fact, Simon Willison was just talking about this the other day, in the context of Yahoo!’s web service APIs now providing output in JSON format as well as traditional XML.

It’s all coming together. A bundle of key techniques that have been around for ages (Unobtrusive javascript, object-oriented javascript, Ajax/remote scripting) have suddenly seen massive adoption and tremendous development. Javascript has matured a great deal over the course of 2005, and is rapidly tuning into one of the cornerstones of modern web development. It’s a very exciting time for the field.