Image Manipulations with Javascript


Today most computers, graphic cards and monitors can display 16-bit, 24-bit, 32-bit or even 48-bit color depth. The color quality can be selected in the control center of the graphic (video) card.

ATI Radeon Control Center Window

Example : ATI Radeon Control Center Window


In 8-bit color graphics each pixel is represented by one byte, the maximum number of colors that can be displayed at any one time is 256. There are two forms of 8-bit color graphics. The most common uses a separate palette of 256 colors, where each of the 256 entries in the palette map is given red, green, and blue values. The other form is where the 8 bits directly describe red, green, and blue values, typically with 3 bits for red, 3 bits for green and 2 bits for blue.

16-bit color

With 16-bit color, also called High color, one of the bits of the two bytes is set aside for an alpha channel and the remaining 15 bits are split between the red, green, and blue components, allowing 32,768 possible colors for each pixel. When all 16 bits are used, one of the components (usually green) gets an extra bit, allowing 64 levels of intensity for that component, and a total of 65.536 available colors.

24-bit color

Using 24-bit color, also called True color, computers and monitors can display as many as 16.777.215 different color combinations.

32-bit color

Like 24-bit color, 32-bit color supports 16.777.215 colors with an additional alpha channel to create more convincing gradients, shadows, and transparencies. With the alpha channel 32-bit color supports 4.294.967.296 color combinations.

48-bit color

Systems displaying a billion or more colors are called Deep Color. In digital images, 48 bits per pixel, or 16 bits per each color channel (red, green and blue), is used for accurate processing. For the human eye, it is almost impossible to see any difference between such an image and a 24-bit image.


A colour look-up table (CLUT) is a mechanism used to transform a range of input colours into another range of colours. It can be a hardware device built into an imaging system or a software function built into an image processing application.


High-dynamic-range imaging (HDR) is a set of techniques used in imaging and photography to reproduce a greater dynamic range of luminosity than is possible with standard digital imaging or photographic techniques. The aim is to present the human eye with a similar range of luminance as that which, through the visual system, is familiar in everyday life.

Pixel Image

PixelImage 8 x 8

PixelImage 8×8

To dive into the Image Manipulations with Javascript, we will use the Pixel Image shown left which has 8 x 8 pixels and a color depth of 1 bit. The bit value 0 is associated to the color white, 1 means black. We see later that in real systems the colors are inverted (1 = white, 0 = black). In the next steps we will look how to display this image in a browser with HTML5 and javascript.

The following table shows the pixel data for the image. I used the MathIsFun website to do the binary to hexadecimal and decimal conversion.

rows column bits hexadecimal decimal
1 01111110 7E 126
2 10000001 81 129
3 10100101 A5 165
4 10000001 81 129
5 10011001 99 153
6 10000001 81 129
7 11100111 E7 231
8 00111100 3C 60

We can now use the following code to draw the pixels on a canvas :

<canvas id="pixelboard" width="512" height="512"></canvas> 
var myCanvas = document.getElementById("pixelboard");
var myContext = myCanvas.getContext("2d");
myContext.fillStyle = "silver";
myContext.fillRect(0, 0, myCanvas.width, myCanvas.height);
myContext.fillStyle = "black";
// here are the pixel data for the 8 rows
var pixelData = [126, 129, 165, 129, 153, 129, 231, 60];
for (i = 0; i < pixelData.length; i++ ) {
 var base2 = (pixelData[i]).toString(2);
 var p = 7; 
 // set pixels in canvas from right to left
 for (j = (base2.length-1); j >= 0; j-- ) {
 if (base2[j] == 1) {
 myContext.fillRect(p * 64, i * 64, 64, 64);
 } // end if
 } // end base2
} // end pixelData

Click this PixelData link to see it working. The image is stored in 8 bytes.

PNG Image

To draw the picture in the original size of 8×8 pixels, we change the canvas size

<canvas id="pixelboard" width="8" height="8"></canvas> 

and the code line in the inner loop as follows

myContext.fillRect(p, i, 1, 1);

Click this PixelData link to see it working.

We can save the small Pixel image in the browser with a right mouse click as canvas.png file. The size of this PNG image file is 108 bytes, 100 bytes more than the size of the image stored in our javascript.Thats a lot of overhead. Sort od design overkill !

Let’s have a look inside this file with an HexEditor (HxD from Maël Hörz).


Anatomy of a small PNG Image File

We can identify the words PNG, IHDR, IDAT and IEND. The PNG format is specified by the W3C. A lite description is available at the FileFormat.Info website. PNG (pronounced “ping”) is a bitmap file format used to transmit and store bitmapped images. PNG supports the capability of storing up to 16 bits (gray-scale) or 48 bits (truecolor) per pixel, and up to 16 bits of alpha data. It handles the progressive display of image data and the storage of gamma, transparency and textual information, and it uses an efficient and lossless form of data compression.

A PNG format file consists of an 8-byte identification signature followed by chunks of data :

  • Header chunk (IHDR) : the header chunk (13 bytes) contains basic information about the image data and must appear as the first chunk, and there must only be one header chunk in a PNG file.
  • Palette chunk (PLTE) : the palette chunk stores the colormap data associated with the image data. This chunk is present only if the image data uses a color palette and must appear before the image data chunk.
  • Image data chunk (IDAT) : the image data chunk stores the actual image data, and multiple image data chunks may occur in a data stream and must be stored in contiguous order.
  • Image trailer chunk (IEND) : the image trailer chunk must be the final chunk and marks the end of the PNG file or data stream.
  • Optional chunks are called ancillary chunks (examples : background, gamma, histogram, transparency, …) and can be inserted before or after the image data chunks. Ten ancillary chunks have been defined in the first PNG version.

Each chunk has the following structure, each chunk has an overhead of 12 bytes :

  • DataLength (4 bytes)
  • ChunkType (4 bytes)
  • Data (number of bytes specified in DataLength)
  • CRC-32 (4 bytes)

The IHDR chunk specifies the following parameters in the 13 data bytes :

  • ImageWidth in pixels (4 bytes)
  • ImageHeight in pixels (4 bytes)
  • BitDepth (1 byte)
  • ColorType (1 byte)
  • Compression (1 byte)
  • Filter (1 byte)
  • Interlace (1 byte)

An analysis of our PixelData PNG image provides the following results :

  • ImageWidth in pixels :  00 00 00 08 (big-endian) > 8 pixels
  • ImageHeight in pixels : 00 00 00 08 (big-endian) > 8 pixels
  • BitDepth : 08 > 8 bit
  • ColorType : 06 > Truecolour with alpha (RGBA)
  • Compression : 00 > default = deflate
  • Filter : 00 > default = adaptive filtering
  • Interlace : 00 > no
  • ImageDataLength : 00 00 00 31 (big-endian) > 49 bytes

In the HexEditor we see that the 49 bytes of deflated image data are :

18 95 63 38 70 E0 C0 7F 06 06 06 AC 18 2A 07 61 
60 C3 50 85 70 95 28 12 18 0A 08 9A 80 EC 16 9C 
0A 70 9A 80 43 27 04 63 15 44 52 0C 00 67 20 8C 41

The image data is zlib-compressed using the deflate algorithm. zlib is specified in RFC1950, deflate is specified in RFC1951. The process is sufficient complex to not do it manually. We can use the javascript pako.js library to decompress the data block. This library was designed by Vitaly Puzrin and Andrey Tupitsin.

Here comes the code :

 <meta charset="utf-8">
 <title>Inflate byte block of PNG image pixel data with pako.js</title>
 <script type="text/javascript" src="js/pako.js"></script>
<h1>Inflate byte block of PNG image pixel data with pako.js</h1>
<div id="main"></div>
 <script type="text/javascript" >
// enter datastream as array
var hexData = [0x18, 0x95, 0x63, 0x38, 0x70, 0xE0, 0xC0, 0x7F, 0x06, 0x06, 
0x06, 0xAC, 0x18, 0x2A, 0x07, 0x61, 0x60, 0xC3, 0x50, 0x85, 0x70, 0x95, 0x28, 
0x12, 0x18, 0x0A, 0x08, 0x9A, 0x80, 0xEC, 0x16, 0x9C, 0x0A, 0x70, 0x9A, 0x80, 
0x43, 0x27, 0x04, 0x63, 0x15, 0x44, 0x52, 0x0C, 0x00, 0x67, 0x20, 0x8C, 0x41];
 // Pako inflate
 var inflateData = pako.inflate(hexData);
// output inflated data
var output = "<p>The lenght of the inflated data sequence is : " 
+ inflateData.length + "bytes.<br/>"; 
 for (i = 0 ; i < 8; i++) {
 for (j = 0 ; j < 33; j++) {
 console.log((i * 33) + j);
 output+= decimalToHexString(inflateData[(i * 33) + j]) + " ";
 } // end for loop j
 output+= "<br/>";
 } // end for loop i
 output+= "</p>";
 element = document.getElementById("main");
 element.innerHTML = output;
 function decimalToHexString(number)
{ if (number < 0)
 { number = 0xFFFFFFFF + number + 1; }
 return number.toString(16).toUpperCase();
Byte sequence in PNG image rows

Byte sequence in PNG image rows

The byte sequence of pixel data stored in  PNG images is shown in the left figure.

In our case we have 8 rows with 8 * 4 bytes (RGBA) plus one null byte, giving a total of 8 * 33 = 264 bytes.

Click the inflate link to see the result of the inflate process. The sequence length is really 264 bytes and the structure of the PNG format is visible in the output.


inflating PNG image data

The RGB hexadecimal values C0 generate grey (white) pixels, the values 0 generate black pixels. The alpha channel is always transparent (hex FF).

Synthesize a PNG image

To synthesize a minimal PNG image with monochrome PixelData, we modify the original canvas.png data as follows :

1. The signature does not change, the bytes in hexadecimal format are :

89 50 4E 47 0D 0A 1A 0A

2. In the header we set the bit depth to 1 (mono-chrome) and the color type to 0 (gray-scale). We get the following byte sequence in hexadecimal format :

00 00 00 0D 49 48 44 52 00 00 00 08 00 00 00 08 01 00 00 00 00

We have several possibilities to calculate the new CRC32 checksum over the header name and the new data :

CRC32 calculation with desktop and online tool

CRC32 calculation with desktop and online tool

Here comes the code for the javascript CRC32 calculation :

 <meta charset="utf-8">
 <title>Calculate checksum crc32 with SheetJS/js-crc32 
of canvas.png chunks</title>
 <script type="text/javascript" src="js/SheetJS_crc32.js"></script>
<h1>Calculate checksum crc32 with SheetJS/js-crc32 of canvas.png chunks</h1>
<div id="main"></div>
 <script type="text/javascript" >
 // calculate crc32 over chunk name and data
// enter datastream as hexadecimal numbers
var charData = [0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 
0x00, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00];
var myCRC32 = CRC32.buf(charData);
var crc = decimalToHexString(myCRC32);
var output = "<p>Here is the signed 32 bit number of the CRC32 : " 
+ myCRC32 + "<br/>Here is the hexadecimal value of the CRC32 : " 
+ crc + "</p>";
 element = document.getElementById("main");
 element.innerHTML = output;
 function decimalToHexString(number)
{  if (number < 0)
   { number = 0xFFFFFFFF + number + 1 }  
   return number.toString(16).toUpperCase();
} // end function

Click this CRC32 link to see it working. The checksum to add to the IHDR chunk is EC 74 83 26.

Now we tackle the IDAT chunk. We have 8 rows for the PixelData, starting each with a NullByte (filter), followed by 1 byte in each row for the monochrome pixels. That makes a total of 16 bytes. The data length in hexadecial format is 10. We use 1 for black and 0 for white, giving us the following byte sequence :

00 7E 00 81 00 A5 00 81 00 99 00 81 00 E7 00 3C

This byte sequence is deflated with the Pako.js library with the following script :

 <meta charset="utf-8">
 <title>Deflate byte block of PNG image pixel data with pako.js</title>
 <script type="text/javascript" src="js/pako.js"></script>
<h1>Deflate byte block of PNG image pixel data with pako.js</h1>
<div id="main"></div>
 <script type="text/javascript" >
 // enter datastream as numbers
var charData = [0x00, 0x7E, 0x00, 0x81, 0x00, 0xA5, 0x00, 0x81, 0x00, 0x99, 
0x00, 0x81, 0x00, 0xE7, 0x00, 0x3C];
 // Pako deflate
 var deflateData = pako.deflate(charData);
 var output = "<p>The length of the deflated data sequence is : " 
+ deflateData.length + " bytes.<br/>";
 for (i = 0; i < deflateData.length; i++) {
 output+= decimalToHexString(deflateData[i]) + " ";
 } // end for loop i
 output+= "</p>";
 element = document.getElementById("main");
 element.innerHTML = output;
 function decimalToHexString(number)
{ if (number < 0)
 { number = 0xFFFFFFFF + number + 1; }
 return number.toString(16).toUpperCase();

Click this deflate link to see the result. The length of the deflated sequence has 21 bytes (hex : 15) and is longer than the original sequence.That happens with very short image sequences.


deflating PNG image data

There are possibilities to minify the deflated sequence lenght, but this is not our goal. There are several blogs and posts dealing with smallest possible png images.

The last step is the calculation of the CRC32 checksum, same procedure as above. The following crc32 link shows the 4 byte hexadecimal number : EC 01 89 73.

The final byte sequence for the IDAT chunk is displayed hereafter :

00 00 00 15 49 44 41 54 78 9C 63 A8 63 68 64 58 0A C4 33 81 F8 39 83 0D 00 23 
44 04 63 EC 01 89 73 

3. The IEND chunk remains unchanged and has no associated data :

00 00 00 00 49 45 4E 44 AE 42 60 82

To create and display this synthetic PNG image, we copy all the hexadecimal data in our HexEditor and save it as mysynth.png file. To check that the format is right, we can use the pngcheck tool or  load the image in Photoshop. It works.


Analayse file mysynth.png with pngcheck.exe

PNG in

Open file mysynth.png in Photoshop

Display the PNG image in the Browser

The typical HTML code to display an image in a web browser is

<img src="url" alt="abcde" width="xxx" height="yyy" />

The src attribute specifies the URI (uniform resource identifier) of the image. The most common form of an URI is an URL (uniform resource locator) that is frequently referred as a web address. URIs identify and URLs locate. Every URL is also an URI, but there are URIs which are not URLs.

The URI syntax consists of a URI scheme name (such as “http”, “ftp”, “mailto” or “file”) followed by a colon character, and then by a scheme-specific part. An example of an URI which is not an URL is a dataURI, for example


The data URI scheme is a URI scheme that provides a way to include data in-line in web pages as if they were external resources. This technique allows normally separate elements such as images and style sheets to be fetched in a single HTTP request rather than multiple HTTP requests, which can be more efficient.

We will use the dataURI to display our synthesized PNG image in a web browser without saving it to an external source. The data URI scheme is defined in RFC 2397 of IETF. URI’s are character strings, therefore we must convert (encode) the image data to ASCII text. The most common conversion is base64, another method is percent encoding.

There are several possibilities to encode our image data in base64 :

Here comes the code for the javascript btoa() conversion :

 <meta charset="utf-8">
 <title>Display mysynth.png with dataURI</title>
<h1>Display mysynth.png with dataURI</h1>
<div id="main"></div>
 <script type="text/javascript" >
var signature = [0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A]; 
var ihdr = [0x00, 0x00, 0x00, 0x0D, 0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 
0x00, 0x08, 0x00, 0x00, 0x00, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00, 0xEC, 
0x74, 0x83, 0x26];
var idat = [0x00, 0x00, 0x00, 0x15, 0x49, 0x44, 0x41, 0x54, 0x78, 0x9C, 
0x63, 0xA8, 0x63, 0x68, 0x64, 0x58, 0x0A, 0xC4, 0x33, 0x81, 0xF8, 0x39, 
0x83, 0x0D, 0x00, 
0x23, 0x44, 0x04, 0x63, 0xEC, 0x01, 0x89, 0x73];
var iend = [0x00, 0x00, 0x00, 0x00, 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 
0x60, 0x82];
var mysynthPNG = signature.concat(ihdr).concat(idat).concat(iend);
var imageStringBase64 = btoa(String.fromCharCode.apply(null, mysynthPNG));
var mysynthImg=document.createElement("img");
mysynthImg.setAttribute('src', 'data:image/png;base64,' + imageStringBase64);
mysynthImg.setAttribute('alt', 'mysynthPNG');
mysynthImg.setAttribute('height', '8px');
mysynthImg.setAttribute('width', '8px');

Click the following base64 link to see the result. The pixel colors are inverted, 1 is white and 0 is black.


The following list provides links to websites with additional informations about image pixel manipulations :

Responsive javascript slideshows

Last update : July 5, 2014

Early 2006, Lokesh Dhakar introduced Lightbox, a unobtrusive script used to display large images using modal dialogs over a black faded background. Six years later, there were hundred of scripts available to create slideshows, carousels, sliders and image galleries on the web. I evaluated the following responsive javascript slideshows for different projects:

Today, some of these scripts are outdated and I included them only for historical reasons. Some scripts are standalone, but most are based on jQuery, a fast, small and feature-rich JavaScript library. Most of them are also available as WordPress plugin.

My favorite script is the …

I use the following code :


See the demo

The following list provides links to websites with additional informations about slideshows and related topics :

Cross Domain Communication, Same Origin Policy and CORS

In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The term origin is defined using the domain name, protocol, and port number of the HTML document running the script. It has always been possible for the browser to make cross origin requests by specifying a resource from a foreign domain in the IMG, SCRIPT, IFRAME tags etc. But with these requests the client-side script does not have access to the content of this resource, it can only be executed or rendered by the browser.

The same origin policy permits scripts running on pages originating from the same site to access each other’s methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites. The goal of the policy is to prevent cross-site scripting (XSS), a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users.

With the growing popularity of Ajax, a group of interrelated web development methods used on the client-side to create asynchronous web applications, the same origin policy became more and more a serious drawback. With Ajax, data is usually retrieved using the XMLHttpRequest object.

Various alternatives have been developed to circumvent the same origin security feature, for example :

  • Flash or Silverlight with a  crossdomain.xml policy file
  • iFrame URL Technique
  • JSONP (JSON with padding)
  • XMLHttpRequest Level 2, which has been merged into the main XMLHttpRequest specification in December 2011
  • XDomainRequest (non standard) used by IE 8
  • window.location.hash hack
  • Facebook cross domain communication channel
  • window.postMessage() : supported by Firefox 3, Safari 4, Chrome and IE 8

With HTML 5, a new web browser technology emerged which defines ways for a web server to allow its resources be accessed by a web page from a different domain. This technology is called CORS (Cross-Origin Resource Sharing), a first working draft was published by W3C.

CORS works on a per-page access-control model. Every page has to respond with a special header, the Access-Control-Allow-Origin header to be accessible by a foreign site.In the CORS model the responsibility of Access Control is in the hands of the developers and not the server administrators. One drawback of this technology is that the Access-Control-Allow-Origin header is not yet supported by Amazon AWS S3. A lot of web designers are requesting this feature on the AWS Developer Forum.

The following list gives additional useful links to websites reporting about this topic :

Google Web Toolkit, Google Doctype, Closure Tools

Closure Logo

Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. GWT is open source and used by thousands of developers around the world.

Google Doctype is an open encyclopedia and reference library.

The Google Closure Tools help developers to build rich web applications with JavaScript that is both powerful and efficient. The Closure tools include:

  • The Closure Compiler compiles JavaScript into compact, optimized and high-performance code
  • The Closure Library is a broad, well-tested, modular, server-agnostic and cross-browser JavaScript library.
  • The Closure Templates are a client- and server-side templating system that helps developers to dynamically build reusable HTML and UI elements.
  • The Closure Stylesheets is an extension to CSS that adds variables, functions, conditionals, and mixins to standard CSS.
  • The Closure Linter ensures that all JavaScript code follows the guidelines in the Google JavaScript Style Guide.
  • The Closure Inspector is an extension to Firebug, the Firefox debugger extension.

The Google Closure Website provides FAQ’s, a Blog and other resources about Closure tools. The Google Doodle “Happy Holidays 2011”, created by software engineer Nathan Naze, is based on Closure.

YUI compressor for Javascript and CSS

The YUI Compressor is a JavaScript compressor which, in addition to removing comments and white-spaces, obfuscates local variables using the smallest possible variable name.

The YUI Compressor is also able to safely compress CSS files. The decision on which compressor is being used is made on the file extension (js or css).

The YUI Compressor is written in Java and relies on Rhino to tokenize the source JavaScript file. It starts by analyzing the source JavaScript file to understand how it is structured. It then prints out the token stream, omitting as many white space characters as possible, and replacing all local symbols by a letter symbol wherever such a substitution is appropriate . The CSS compression algorithm uses a set of finely tuned regular expressions to compress the source CSS file. The YUI Compressor is open-source.

Several GUI’s are available :

Online versions are available at the website of Zileex Media, of  Rodolphe Stoclin and of gpbmike.


last update : 18 January 2012
Modernizr is a small JavaScript library that detects the availability of native implementations for next-generation web technologies. These technologies are new features that stem from the ongoing HTML 5 and CSS 3 specifications. Many of these features are already implemented in at least one major browser. Modernizr tell you whether the current browser has this feature natively implemented or not.

  1. Modernizr tests for over 40 next-generation features, all in a matter of milliseconds;
  2. Modernizr creates a JavaScript object (named Modernizr) that contains the results of these tests as boolean properties;
  3. Modernizr adds classes to the html element that explain precisely what features are and are not natively supported. It allow you to target specific browser functionality in your stylesheet ( if-statements in your CSS ). You don’t actually need to write any Javascript to use it.

I started with version 1.6.  and experienced a problem with Chrome 9 (beta) which was also reported by other people. The current version  2 was released on 1st June 2011.

With the help of the Modernizr library, the website gives a quick overview of a browser’s support for recent technologies in the world of HTML, CSS and Javascript.


How to make an iPhone web app ?

Tetris web app for iPhone

An iPhone web application (web app) uses Web 2.0 technologies to deliver a focused solution that looks and behaves like a native iPhone application. iPhone web apps run in Safari on iPhone, the unique implementation of Safari that provides full-featured web browsing on iOS-based devices and responds to touch-based gestures.

The Apple Safari Developer / Reference Library provides guides, tutorials, code samples, FAQ’s  and best practices about the creation of web content for iOS devices. The Safari Web Content Guide, the HTML Reference, the CSS Reference and the JavaScript Guide are key documents.

A very useful tutorial about the creation of an off-line Tetris game for an iPhone has been published by Alex Kessinger on the Six Revisions Website. A tutorial about how to install a web app on iPhones has been written by jeshyr on the iTalk Magazine.

There are several tools and frameworks available to build html5/css3 web apps for iPhones or for other mobiles (cross-platforms). A list of a few ones is shown herafter :

  • iWebKit 5 : an outstanding kit with copy and paste elements designed by Christopher Plieger and Johan Van Wilsum to create iPhone web apps.
  • Appcelerator Titanium : an SDK for different application environments. The SDK provides the necessary tools, compilers and APIs for building for the target platform.
  • Sencha Touch : a free HTML5 mobile JavaScript framework that allows you to develop mobile web apps that look and feel native on iPhone and Android touchscreen devices.
  • PhoneGap : an open source development framework for building cross-platform mobile apps with support of core features in iPhone/iPod touch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.
  • Corona : fast and easy development tool for iPhone, iPad and Android games and applications.
  • jQuery Mobile : Touch-Optimized Web Framework for Smartphones & Tablets.
  • iUI: iPhone User Interface Framework
  • Dashcode : part of Apples iPhone SDK

There are also tools and simulators to test created web apps :

  • Bugaboo : an App for debugging web apps on iPhone, iPad, and iPod touch devices, downloadable from the Apple App Store.
  • iPhone  simulator : web browser based simulator

You have to be aware that there are some differences between iPhone native Apps and web apps.

A native App runs code (Objective-C program) on the device and is installable through the App store (if approved by Apple). You have access to all the UI elements the iPhone uses and can do things like 3D which are impossible in the Safari browser. You need a mac to make a native App, but you can make web apps with any platform of your choice.

A web app is accessed via the Safari browser and requires no install. You are just going to a website that has a special stylesheet for the iPhone. Because a web app can also be installed on an iPhone with a custom icon, a custom startup screen, a native look-and-feel and can be used even when the phone is not connected to the Internet, the differences between Apps and web apps are becoming very small.

There are a lot of native Apps that could be run more efficient as web apps. And there are tools to convert a web app into a native App. Make your choice !

Facebook Javascript API

The new Facebook Javascript API handles the following methods :

Core methods

  • FB.init : Initializes the library
  • FB.login : Login/Authorize/Permissions
  • FB.logout : Logout the user in the background
  • FB.api : Make a API call to the Graph API
  • FB.ui : Method for triggering UI interaction with Facebook as iframe dialogs or popups, like publishing to the stream, sharing links
  • FB.getLoginStatus : Find out the current status from the server, and get a session if the user is connected
  • FB.getSession : Synchronous accessor for the current Session (less overhead as the asynchronous access)

Data Access Utilities

  • FB.Data.query : Performs a parameterized FQL query and returns a FB.Data.query object which can be waited on for the asynchronously fetched data
  • FB.Data.waitOn : Wait until the results of all queries are ready

Event Handling

XFBML methods

Canvas methods

Some useful tutorials about the new Facebook Javascript SDK are listed hereafter :

  • Mahmud Ahsan on Graph api & javascript base Facebook Connect tutorial
  • Abu Ashraf Masnun on : Using The Facebook Graph API with js-sdk : An explanatory Tutorial
  • timware on Hyperarts : How to Add Facebook’s XFBML Like Button & Social Plugins to Your Web Pages & WordPress Posts

A very useful development tool is the Test Console made available by Facebook.

XHTML validation and Javascript : CDATA

With HTML pages on the web you can include the required Javascript betweentags. The W3C validator ignores the Javascript content. The same is not true for XHTML where the code between the script tags is considered to be PCDATA (parsed character data) which is therefore processed by the validator.

The result is a break of the page validation. To fix this problem, one solution is to make the Javascript external to the page. Another solution is to  place the Javascript code within a CDATA tag. However some older web browsers don’t understand the CDATA tag and this breaks the Javascript in those browsers.

If the CDATA tag is commented out, the Javascript code is handled correctly both by newer browsers and by validators and ignored by older browsers and the page is displayed as expected in all cases.

<script type=”text/javascript”>
/* <![CDATA[ */
// content of your Javascript goes here
/* ]]> */

A guide about this topic has been written by Stephen Chapman on the website.

Unobtrusive JavaScript

The following HTML code shows the basics of modern javascript programming :

<script type=”text/javascript” src=”helloworld.js”></script>
<p id=”hello”></p>

The concept is to keep the javascript separate from the HTML of the web page and to just use a script tag in the head section of the webpage to link the two together. An id tag is used to identify the part of the body of the web page that should be updated with javascript.

The javascript code is shown below :

function sayHello() {
document.getElementById(‘hello’).innerHTML = ‘Hello World’;
window.onload = sayHello;

In the past the function document.write() was used for this purpose, but this is “bad form” and not valid xhtml code. To adhere to strict xhtml code, then it would be better to create elements using document.createElement and element.appendChild (and other native DOM node manipulation functions). For inserting text into an existing element, innerHTML is still acceptable code (and completely cross-browser). The “all DOM” way requires a lot of extra code, is slower, harder to maintain than simpler method and it needs more bandwidth.