How to Add Internet Explorer 9 Jump Lists to Your Site

With Internet Explorer 9 Beta is out, I’m poking around with some of the new features available. One of the new features called website pinning allows you to “pin” a website to your Windows 7 taskbar for easy access later. The pinning feature, in itself, isn’t really all that interesting to me because you could create desktop shortcuts to webpages for years. What is cool, though, is the ability specify direct links to important pages from a pinned website. These are called “Jump Lists” and they provide navigation capabilities straight from a pinned website. The obvious use case for this is to allow users to immediately reach the most important pages on a site without having to open the browser, type in the web address and click on several links to get to a page.

The code to make jump lists available is very straightforward. A new meta tag called “msapplication-task” is available in IE9 which allows you to define the navigation for your pinned website. For example, I added the following jump list to my blog:

and here’s the code I added to my site to make that happen:

[code language=”html”]
<meta name="application-name" content="Rey Bango Front-end Developer"/>
<meta name="msapplication-tooltip" content="Launch Rey Bango’s Blog"/>
<meta name="msapplication-task" content="name=About;action-uri=/about/;icon-uri=/images/about.ico" />
<meta name="msapplication-task" content="name=The Big List;action-uri=/the-big-list-of-javascript-css-and-html-development-tools-libraries-projects-and-books/;icon-uri=/images/list_links.ico" />
<meta name="msapplication-task" content="name=jQuery Posts;action-uri=/category/jquery/;icon-uri=/images/jquery.ico" />
<meta name="msapplication-task" content="name=Start Developing;action-uri=/category/javascript/;icon-uri=/images/script.ico" />
<link rel="shortcut icon" href="/images/favicon.ico" />

The content attribute allows you to specify the name, action and icon that you’d like to use for your jump list nav entry. Here’s a list of the available meta elements that you can use to format your jump lists:

Name Content
application-name The name of the shortcut. If missing, the document title is used instead.
msapplication-tooltip Optional text that is displayed as a tooltip when the mouse pointer hovers over the pinned site shortcut icon in the Windows Start menu or desktop.
msapplication-starturl The root URL of the application. If missing, the address of the current page is used instead. Only HTTP, HTTPS, or FTP protocols are allowed.
msapplication-navbutton-color The color of the Back and Forward buttons in the pinned site browser window. Any named color, or hex color value as defined by Cascading Style Sheets (CSS), Level 3 (CSS3) is valid. For more information, see Color Table. If this meta element is absent, the color is based on the shortcut icon.
msapplication-window The initial size of the pinned site browser window. Content sub-elements provide size as number N, separated by a semicolon.

  • width=N (minimum 800)
  • height=N (minimum 600)

Note that user action overwrites this value. Windows preserves the user-generated window size when the user changes the size of the window and then closes the instance.

I could further customize the pinned site shortcut with start URL, initial window size, and navigation button color using the following code:

[code language=”html”]
<meta name="msapplication-starturl" content=""/>
<meta name="msapplication-window" content="width=800;height=600"/>
<meta name="msapplication-navbutton-color" content="red"/>

What About Other Browsers?

Unfortunately, this feature is IE9-specific functionality and not available via other browsers or operating systems; only Windows. I really wish it was more portable because it’s a slick feature and I honestly don’t know if other browser makers could do something like this. Let’s see if they consider adopting this type of UX.


To actually see how the pinning works and how jump lists appear, I created a screencast that explains the whole process:

Rey Bango


    • Using <menu/> would surely be a terrible idea. It would leave stray <li/>s all over the page for older browsers (<menu/> is backwards compatible in its use of list-items, but wouldn’t be in this seemingly misguided (imo) use case). The spec. appears to define <menu/> for use within webpages, not outside for OS-level stuff.

      That’s not all that blogpost seems misinformed about – meta-tags are a perfectly legitimate, standardised way of adding *meta-data* to be parsed for use *outside* of the webpage (which is precisely what’s being done here).

      • @lucideer And we should have one set of metadata for IE, and one for Firefox, and one for Opera, and one for WebKit? Who will govern what is the “right” metadata if other browsers want to integrate into Win7 the same way? I’d rather all the vendors were reading from the same sheet (the HTML5 spec).

        In the blog post I showed that the menu element can be hidden from old browsers using CSS.

      • That’s a fair point. Maybe the question is why create this bridge between web page and OS in the first place? I suspect jump lists to be the kind of thing that will be implemented on 1% of sites and die off soon enough because it’s not a standard.

      • I couldn’t disagree more. “Stray <li/>s all over the page” surely would be better than a bunch of proprietary meta tags that will only be used by one browser anyway.

        The current solution, although indeed a legitimate way of adding meta-data to a document, is not helping interoperability. If we standardize this behavior from the start, other UAs can easily adopt this pattern in the future.

        If there’s a standards-based way of doing things, there’s no need to resort to solutions that are 100% proprietary.

        • @Kroc & Mathias
          Fair points that having different meta-tag definitions for every different thing is not ideal – the ideal solution would be to standardise the meta-tag definitions (IFF this is something other OS/browser vendors would be interested in implementing). But that’s an entirely different suggestion than adulterating <menu/> for something the spec. surely never intended – this is precisely what this page is for:

          As for hiding the <li/>s with CSS, that’s viable but is still a hack. Markup elements in the document body should be content intended for display *within* the bounds of the browser chrome – everything else is metadata, and should be treated as such.

          • @lucideer You should read the HTML5 specification because you are making assumptions that are simply wrong.

            “surely never intended” — you are aware that the HTML5 menu element *is intended* for toolbars, menus and context-menus? And that the menu element should be hidden by default by supporting user-agents?

            Using the HTML5 menu element for jump-lists is the exact purpose it was designed for. Microsoft are doing every other vendor and every developer absolutely no favours with the metatag overload. It’s narrow-minded and a standard desktop-centric view of the browser–which as we know is now no longer the only type of webbrowser. Microsoft added favicon.ico because they assumed that the web was (or should be) entirely viewed from a Windows PC. They are making the same mistake today.

          • @Kroc
            It’s intended for *creating* toolbars, menus and context-menus *within* the webpage – i.e. the drop-down menus and toolbars in a webmail client – just as all HTML display elements are intended for marking up content *within* the webpage. This is clearly external, for which meta-data and content usually defined in the <head/> is typically used.

            If <menu/> is intended for use outside of the webpage, why then do you need to hide it with CSS – surely if that was its intent, it should not be displayed inside the page by default.

          • No, it is not for creating toolbars &c. _within_ the page, it’s for creating toolbars &.c within *the chrome* (i.e. the user-agent). Those menus can take on any form what-so-ever that is relevant to the particular device, OS, and input mechanism. For example, instead of a visual menu, it could be read aloud for blind users, or presented as a context menu on an HTML file in a file explorer, or even in forms and devices that haven’t been imagined yet. The meta-tag method is a single-purpose, narrow view of the web.

          • Why then is it displayed?

            And why are meta-tags a “narrow view” of the web. If you think meta-tags should be deprecated, you could suggest that to WHATWG – currently they are a valid, standardised element for which this seems a perfectly appropriate use. At least they don’t litter the page with elements useless to any UA not supporting this functionality.

            The only argument one could level against this implementation is that they haven’t proposed the individual meta values for standardisation – a point I’d agree with if anyone had made it. That they should do.

          • lucideer, you don’t seem to get it. Did I ask to depreciate the whole idea of meta-tags?? No. You’re just being alarmist. I’ve made solid points and I’m done correcting you.

  1. Why should there be a ‘standard’ way of getting this OS specific functionality? There is no appropriate standard for that, I think. For me it’s no big deal to use meta tags or misuse the menu tag.

  2. “I honestly don’t know if other browser makers could do something like this. Let’s see if they consider adopting this type of UX.”

    Are you serious? IE has been behind almost any other browser for years and years now. And still IE can’t keep up with others browsers if you look at W3C standards and speed (not even talking about passing them). I really thought change was coming and IE9 would be awesome (also for web developers). But now I’ve seen IE9 doesn’t even support HTML5 as promised. Yes, IE9 does, but only in microsoft-made-ie9-only HTML5-tests… Stop it, face reality and start making a god damn properly working browser. Thank you.

    • After trying out the IE9 beta for a while, I will have to disagree with you. Performance is really nice, especially coming from Firefox which is getting slower and slower with every update and by now feels like it spends more time freezing than responding. IE9 has definitely surpassed Firefox in terms of performance, and is on par with the other major browsers out there.

      As for HTML5 support, I don’t know the particulars, but IE9 scores 95/100 in the ACID3 tests, so it can’t be that bad. And it’s still beta, so maybe it will reach 100 in the final release (IE8 had 17/100). Besides, other browsers have their own “convenience extensions” to HTML and CSS, Webkit and Opera being prime examples. As long as standards-compliant content is rendered appropriately, I don’t see the problem, and so far I haven’t had any problems with HTLM5/CSS3 rendering in IE9.

    • Ha if a million people were doing that, yes I’d be comfortable with that…and I’d be watching the money rolling in. ;)

  3. Its awesome that Microsoft has its browser in the rat race. I love it. Waiting for the bugs to be fixed and the production version launched. It at times does not display the busy status. At times loads the sites incorrectly and more.

  4. Regarding the criticism that IE9 has adopted a browser/OS-specific approach to this: apart from the obvious reason of a lack of a suitable standard for this, the tags as described in the article are not the only way of getting jumplists to show up.

    I haven’t really tried to figure out what heuristics is used, but most pages that you pin to the task bar will receive some sort of jumplist even if none is explicitly defined. It is comparable to Google search results which, for some sites, add a little table of direct links to site subsections below the result. The new meta-tags are not required for this new feature of IE, and simply provided for developers who want to have more direct control over how their sites are represented if visitors pin them.

Comments are closed.