Microsoft has just released a preview release of IE 9; it is all for public to download and take a test run. It’s a preview release in a “truest” sense because the preview version has lots of limitations: no toolbar, no address bar, no navigate back/forward options, no printing capabilities, etc. etc. However you can press Ctrl+L to navigate to new URLs but cannot go back or forward in the browser history (even the keyboard shortcuts don’t work). It is intended to show the capabilities of the new browser engine in terms of HTML 5 support, CSS3, ACID 3 browser test, and few other standards.

I browsed few of my most-frequently-visited pages and found no hick ups. Looked at the IE9 demos as well and found some of them to be not working.

Get it from http://ie.microsoft.com/testdrive/

In Part 1, I discussed what the data: URI scheme is all about, its various usage scenarios and available browser support. Let’s see few examples in this post. Just copy and paste the following HTML code into a HTML file and open it any of Firefox, Safari, IE8, Google Chrome or Opera. Since today’s browsers are very forgiving, this bare HTML tag should work without any fuss!

<img src=’data:image/jpg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/4QByRXhpZgAASUkqAAgAAAAFABoBBQABAAAASgAAABsBBQABAAAAUgAAACgBAwABAAAAAgAAADEBAgAQ
AAAAWgAAAABRBAABAAAAAAAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQuTkVUIHYzLjM2AP/bAEMAEAsMDgwKEA4NDhIREBMYKBoYFhYYMSMlHSg6Mz08OTM4N0BIXE5ARFdFNzhQ
bVFXX2JnaGc+TXF5cGR4XGVnY//bAEMBERISGBUYLxoaL2NCOEJjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY//AABEIAC4AQQMBIgACEQED
EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygp
KjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy 8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXx
FxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl
5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AGnFRx8k049KbF3NcB6BbgGag1K/WxTAAaRvuj+tWLbqawNZBfU3iHzO20KPwqqcVKWpE5OK0Kt1qN1dALJIfLU52jjJqDzPmyOK6YeH
Y4bL52Lykc+xrl7hRbysj8FTjFdatsjnkmtWbuka6d6wXR+UnAf0+tdUBla8ziPz5HTNeh6VJ52mwsTk7cH8OK5a8EtUb05t6MsYop2Peiue5qc+/ApsNPK5FRx/K5FasRdt/vVC9usN
9JfmIO21Rgn7p/xxip7f7wrSQ2+yXdjb97n1q6RM0ZUetpPI0MkJVl4JB4FZWqtp05ZX4k9QK3IfsS75SI0JyULd/esOazs7q5fDDLHduHINb6GbTtYyHs2jVWt281GOPcGu60m1Nnp8
ULHLYy31PWsBLGKONo0+bOO/bvXTWilLeJT1CgVjXeiKpxtqS7aKfiiuQ1OeIxVcf6w1ZIqhcXCWxLOGI9q3tcTdjUtzUkw3xNGRw3Fc1LrswG2BAnueTVvQJ57y8mE0ztiEsMngHcvb
8a1hRktTKVWOxoXo2WojmkDY+6WAGP0rCcsgzuREB+XaMEmtXUNV2IUeMErxkVjoTqFyqDCA881srsmUkjV0RBPuZ2JwRxmunj6CvO0vpbO+eS3JUK2MHoQOOa6bS/Ei3U0cMtuUZztD
KcjNYVqctyqdRPQ6SijFFchsf//Z’ alt=’data: URI for images’ />

If your browser supports data: protocol, the above puzzling lines should show a small picture (actually, the CEO of my company). OK, here is his name!

<!– IE8 won’t render this as it supports data: for image type OBJECT only –>
<object type=”text/html” data=”data:text/html,%3C%73%70%61%6E%20%73%74%79%6C%65%3D%27%63%6F%6C%6F%72%3A%67%72%65%65%6E%3B%66%6F%6E%74%2D%77
    %65%69%67%68%74%3A%62%6F%6C%64%3B%27%3E%46%72%61%6E%63%3C%2F%73%70%61%6E%3E%69%73%63%6F%20%44%27%53%6F%75%7A%61″
    height=”40px”>
    You are probably running IE!
</object>

Note that I am not using Base64 encoding for the actual HTML markup data; rather I use URL escaping, the default data representation mechanism of the protocol, for the HTML bytes. As commented above, IE8 currently does not support data: protocol for HTML object contents, but others do. Stretching a bit more, the following example shows how CSS can be sourced from a data: URI.

<html>
<head>
    <title>The data: URI Scheme</title>
    <meta http-equiv=”X-UA-Compatible” content=”IE=8″ /> <!– For IE8 only –>
    <link rel=”Stylesheet” href=”data:text/css;base64,LmNzc0RhdGFEZW1vIHtmb250LWZhbWlseTpCcnVzaCBTY3JpcHQgTVQ7IGZvbnQtc2l6ZTozMHB4OyBib3JkZXI6ZG90dGVkIDNweCBibHVlO30=” />
</head>
<body>
    <span class=”cssDataDemo”>Using style class from CSS embedded using data: protocol.</span>
</body>
</html>

The <meta> tag is required only for IE8. Other browsers don’s use it as they allow data: for CSS content also.

Here is a bit interesting one!

<html>
<head>
    <title>The data: URI Scheme</title>
    <script type=”text/javascript” src=”data:text/javascript;base64,ZnVuY3Rpb24gc2hvd1RpbWUoKSB7YWxlcnQgKG5ldyBEYXRlKCkpO30gZnVuY3Rpb24gdXNlRGF0YVVyaSgpIHthbGVydChjb25maXJtICgnV291bGQgeW91IGNvbnNpZGVyIGRhdGE6IFVSSSBzY2hlbWVzIGluIGZ1dHVyZSBwcm9qZWN0cz8nKSk7fSBmdW5jdGlvbiBzaG93QXBwVmVyc2lvbigpIHthbGVydCAobmF2aWdhdG9yLmFwcFZlcnNpb24pO30=”></script>
</head>
<body>
    <!– Embedded JS –>     <span>JavaScript embedded using data: URI scheme. Don’t try this on IE8…</span>
    <br />
    <form action=”dummy.cgi”>
    <input type=”button” onclick=”showTime();” value=”Show Date & Time” />&nbsp;&nbsp;
    <input type=”button” onclick=”useDataUri();” value=”Your Choice!” />&nbsp;&nbsp;
    <input type=”button” onclick=”showAppVersion();” value=”Browser Version” />
    </form>
</body>
</html>

Each button calls different JavaScript functions, all sourced from a base64-encoded script (you can decode it using an online base64 decoder or do Console.WriteLine (System.Text.Encoding.ASCII.GetString (System.Convert.FromBase64String (base64_encoded_data))), if you want to see the actual JavaScript code).

I hope now you’ve got a better understanding of data: and its several usage scenarios. But just keep in mind that overusing or using it in inappropriate contexts might negatively impact the web application performance.

UPDATE: Looks like the HTML markup code went haywire (likely due to Word 2007 which I use for blog posting) and a portion of the HTML got clipped off; fixed it and everything is fine now (in a scrollable view).

    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 Amazon.com 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.