Almost no one doubts it, but still how powerful it is? Just go to and see it for yourself! These awesome visuals use only JS and JS-based frameworks (such as Prototype & JQuery); no Adobe Flash or Microsoft Silverlight! Not just that, these demos could also be stress testers for your browser’s JavaScript engine.

 “Google Gravity”, “Browser Ball” & “Ball Pool” are my favorites! There are other fun stuffs too. Another (game) example showing the prowess of JS is

 All these demos use the new <canvas> element introduced in HTML 5 spec and JS to manipulate it. <canvas> allows dynamic drawing/manipulation of graphics and images using JS in a web page. Possible usage scenarios include (but not limited to) showing dynamic graphs, charts, other data visualizations and creating interactive content without using any 3rd party components. Perhaps AJAX and <canvas> duo could make users’ web experience at par with Flash or Silverlight. Wouldn’t they?

<canvas> at present supported by Mozilla Firefox 1.5+, Apple Safari, Google Chrome 1.0+ and Opera; IE is yet to catch up (including IE8). So, see the above samples in <canvas>-aware browsers only.

    One of the new features introduced in IE8 is support for the data: protocol. Though IE8’s support this protocol is a welcome one, it is very limited in terms of features and usage compared to other browsers that have been supporting this protocol for quite a long some time. The data: URI scheme (or protocol, to use a familiar term) has been around for more than a decade but it was hardly used due to inconsistent browser support. Some web browsers have been supporting this protocol right from their V1, but the protocol capabilities and usage limitations inherent in them varied widely. However, recent versions of popular web browsers provide better consistency in data: protocol handling thus reducing the gap.


The purpose of data: protocol is to embed resources of any type, binary or text, within a page itself so that the browser doesn’t have to make network requests to remote servers and the saved bandwidth might be used to retrieve other resources in the page. Resources that are static or change infrequently (site logo, bullet images of lists, mini CSS style sheets/JavaScript code – to name a few) are the best bets to go with this protocol. I should emphasize that the resource file size be smaller and appearing in just few places in a page. Let’s see why towards the end or maybe you would figure it out by yourself as we go. The format of the data: protocol is:


data:MIME-Type;Parameters;Base64,Data Sequence


Everything except the URI scheme and the data sequence are optional.


MIME-Type can be any valid “type/sub-type” as specified in Content-Type HTTP header (but not all browsers support all MIME types for the data: protocol). If omitted it defaults to text/plain.

Parameters are an optional list of key=value pair, each separated by a semi-colon. If both MIME type and parameter list are omitted, they default to text/plain;charset=US-ASCII.

Base64, another optional parameter indicates that the data is base64 encoded (typically for binary data). Omitting this parameter would mean that the data is in URL-escaped format: URL unfriendly characters are specified in %xx (hex) format. Nevertheless, you can represent every byte in the data stream in hex format and it would just work fine.


As you aware, base64 encoding bloats the data size in a 3:4 ratio (every triplet results in a quartet after encoding), resulting in a bigger encoded size. With the URL escape method, the bloating ratio will vary positively because only non-URL compliant characters need to be escaped using the hex format. However, if every byte in the data stream is hex-escaped, it bloats the result in a 1:3 ratio – each byte results in three bytes. For example, if the original data size is 1024 bytes, the base64 encoding yields 1,366 bytes and a hex escaping would yield 3,072 bytes. So, using the data: based resources heavily, either the same resource being used in multiple places or too many unique resources in a page would just increase the HTTP payload bringing down the performance.


    Since the data: protocol is nothing but an URI scheme, theoretically it can be used anywhere an URI is expected, but browsers vary in its usage contexts. Nonetheless, all browsers support data: resource anywhere an image URI is expected including CSS properties. Here are a few examples:


  • HTML
    • <img
      src=”data:image/jpg;base64, base64_encoded_jpg_data”
    • <iframe
      src=”data:text/html, URL-escaped_or_hex-escaped_html”
    • <table
      background=”data:image/gif, Hex-escaped_gif_data”
    • <body
      background=”data:image/png;base64, base64_encoded_png_data”

  • CSS
    • .data_gif: {background-image: url
      (‘data:image/gif;base64, base64_encoded_gif_data’)}
    • .data_png: {list-style-image: url
      (‘data:image/png, hex_escaped_png_data’)}


Will see some samples in the next entry but before then have your IE8 installed and any other browser that supports data: protocol already (FireFox, Safari 3+, Chrome or Opera).

The final version of Microsoft Internet Explorer 8 has been released at last. I am not a big fan of alpha & CTP releases and never bother to install them and play around and read up stuff others have written about such releases – just to catch up with what is “in” and “out”. However, I do play around with beta and RC versions only to some extent and did so on IE8 beta-2 and RC-1. The overall impression from these two was, yes, there are new features, more standards-based, existing features enhanced but it leaves a lot of websites esp. those make use of IE-specific features. The final release is more polished and of course does better than beta-2 and RC1; it also incorporates few changes over RC1, but it still leaves hundreds of websites render incorrectly in “pure” IE8 mode (both browser and document modes set to IE8). I fear this will only delay the adoption of IE8 at the enterprise-level and the internet community-wide thus leaving all the great new and enhanced features to be untapped or under-utilized.

Microsoft knew this problem and has given a “switch” to change the rendering mode between IE6, IE7 and pure IE8 – allowing users to select one that shows a website in its intended or best layout/design. This switch is available in the form of a browser setting (for end-users) and a <meta> tag specifying the rendering mode to be used for that page (for developers). Remember <meta> tag overrides user’s setting in order to obey the developer’s mandate of displaying the website in the way he/she intended irrespective of user’s settings. Who knows a website better than its developers?

So, I installed the final IE8 on the very next day it was released and as I said already it has shaped better with few changes compared to RC1. I haven’t experimented with all the new features/changes but based on my experience so far, here are my picks but you can find more about IE8 at the source.

  • For Developers:
    • Full CSS 2.1 & partial CSS 3 support. As always, Microsoft does include few IE-specific extensions to the CSS 2.1 feature set but they are now identifiable with -ms- prefix (Firefox uses -moz- for its CSS extensions).
    • The first IE version to pass ACID2 test.
    • Support for data: protocol. I will cover this interesting thing in a later blog post.
    • IE Developer Toolbar now ‘burnt’ into the browser with more features in the name of Developer Tools. Touted to be what FireBug is to Firefox, but still behind FireBug.
    • Native support for JSON data exchange format. AJAX becomes much easier.
    • Support for (scriptable) DOM storage, part of HTML 5 standard, to persist data in user’s local PC; a better-than-cookie model for offline features. While cookies are limited to 4KB, DOM storage allows more than 5MB per site.
    • Backward IE compatibility: If your website is incompatible with pure IE8 mode, you can place a <meta> tag specifying the browser version (IE 5.5, 6, 7 or 8) IE8 should use to render the page, overriding user’s compatibility settings. See an image-based demo.
    • Includes a better source code viewer (built-in) showing line numbers and tag coloring.


  • For End-users:
    • Browse without traces – called as “InPrivate” mode, the feature allows browsing websites without saving any information such as cookies, browsing history and form data. Good for those doing online money/credit card transactions esp. in public internet browsing centers.
    • Reopen closed tabs within the current browser session; you cannot open tabs closed in previous sessions. However, you can reopen pages that were open in the last browser session.
    • Better “Find on the page” interface.
    • Accelerators – context menus to exchange data with services (e.g.: currency converter, dictionary definition of the selected word, etc) – functionally similar to the mini toolbar in Word 2007. Surprisingly, Microsoft and others have published lot of free accelerators, search providers, toolbars, etc for IE8. See the IE add-ons site for the full list. As per my knowledge, none of the earlier IE versions had so many extensions right from their beta-stages.
    • Domain name (base URL) highlighting in address bar to easily identify the website currently being viewed.
    • As discussed above, IE8 has a switch to display IE8-incompatible websites in the way they are supposed to be (or as best as possible) rather than giving instant surprises. If IE8 finds the site being navigated to be incompatible, it flips the switch automatically and renders the site in best possible mode – saves users a few clicks if it is to be done otherwise manually. This compatibility information can also be specified explicitly using a <meta> tag inside <head> element that directs IE8 to render the page in that particular mode only. As of this writing, Microsoft home page has a <meta> tag to display it in IE7 compatible mode! J
    • Search suggestions – ditto of the ‘Awesome Bar’ feature in Firefox 3.
    • Visual Search – Along with suggestions, you also see a relevant image for each suggestion (not necessarily for all suggestions) if fed by the search provider. Try it: do a search using or Wikipedia search provider from the Quick Search Bar in IE8.
    • Web slices – call it ‘Visual RSS Feeds’, allow you to subscribe to specific sections on a webpage (as marked by its developers), get notified automatically when the subscribed sections updated & view the new content in a mini-window without visiting the site itself. Example: headiness (or specific sections such as Sports, Health, etc) on a news website, flight arrival/departure info, weather updates. Well, you get the idea. To see it in action, visit MSN in IE8 and hover the mouse cursor over the banner at the top-left corner of the main content area and you would see a green icon popping up outlining the web slice area (see below). Click that green icon and the rest should be obvious.


As you might have noticed, many of the new features are already present in other browsers; you can find almost every feature in at least one of Opera, Firefox, Chrome or Safari. The notable exceptions are Web Slices, DOM Storage and native JSON support. I do not know if any of the latest or currently-in-beta versions of other browsers support any of these exceptions.

Well, that’s all for now.

I usually don’t talk too much about or discuss things that are commonly known to everyone. Why add noise unnecessarily when something has already been discussed overwhelmingly by the internet community and all it takes is an internet search to find them. The subject of this post is just one of them. I frequently see many posts requesting for jump-start help, suggestions for improving performance or troubleshooting assistance for web applications that automate MS Office applications (primarily Word, Excel & PowerPoint). Microsoft has gone depth and breadth and documented comprehensively why one should not attempt to automate Office applications on server side and consequences of doing the same. See Considerations for Server-side Automation of Office for details.

Just to reiterate quickly:

  1. Office applications are still COM based (COM servers) working in STA model. Microsoft hasn’t made them to be server-side friendly and it may not happen, at least in near future. OK, the Office interoperability library provided by Microsoft is intended for desktop Windows applications only.
  2. The object model is not thread-safe and naturally not suited for multi-threaded web server environment.
  3. Office applications are designed to be desktop-based applications and assume the availability of user interactivity (e.g. popping up a dialog box and waiting for the user to respond to it). Since web applications run in non-interactive mode, an Office application popping up a dialog box, will just keep waiting (hanging) because the dialog box won’t be visible and hence impossible to respond to it. The end-result is unpredictable.
  4. Deriving from 1 & 3, concurrent requests to Office object model will be serialized for unknown periods of time. This affects the web application’s stability, performance and scalability adversely. Web servers will start issuing HTTP/500 status code to client requests once the request queue becomes full.
  5. Too many instances of Office applications consume more memory and have the potential for threading and shared-resource related issues.

As obvious as can be, none of the above are in favor of multi-threaded web server environments and this is just a small list highlighting significant ones. There are other aspects such as security, data marshalling between COM and .NET, etc, each playing their own devil game.

So, what are the alternatives for programmatically creating/manipulating Word, Excel and PowerPoint files?

  1. Migrate to OpenXML based file formats (.docx, .xlsx, .pptx) which use XML files for data storage and Zip as the container format for the XML files. By the way, .docx, .xlsx & .pptx are all actually zip files with different extensions. Rename any of these files to .zip extension and open it using your favorite unzip tool to see the actual ‘ingredients’ of those files. Working with OpenXML formats is possible from .NET 3.0 onwards (System.IO.Packaging namespace is all about this only) and they are interoperable with other OpenXML based Office suits. Users having Office 2000/XP/2003 can still open and edit OpenXML-based files using the Office 2007 compatibility pack available freely from Microsoft.
  2. Use a 3rd party component to programmatically manipulate Office documents without Microsoft Office installation. Aspose is a popular component vendor in this area. See their website for more details (I am no way associated with this company).
  3. Consider text-based formats such as rich text format (.rtf) or HTML instead of binary .doc format. HTML is flexible, simple to create and can be opened in any browser, while RTF requires some learning curve (and patience!).
  4. If the document or Excel file is relatively simple in size and format, you may use XML cum XSLT based rendering.

If none of these are to your liking, you may write your own Office 2000/XP/2003 file processor! The binary file format specifications are freely available from Microsoft!!

Not to mention, the whole story applies not only to web applications but Windows NT service applications (or any application/service that runs in non-user interactive mode on Windows) as well.