Friday, October 8th, 2010

A Call for “Pinning Menus” Sanity

Category: IE

<p>One of the unique new features of Internet Explorer 9 is the ability to ‘pin’ web sites to the Windows task bar:

While this feature is cool, the way to do it is to use the META tag and drop in some fairly grotty markup into your page:

  1. <!-- C-razy IE9 stuff -->
  2. <meta name="application-name" content="Ars Technica"/>
  3. <meta name="msapplication-starturl" content="http://arstechnica.com/"/>
  4. <meta name="msapplication-tooltip" content="Ars Technica: Serving the technologist for 1.2 decades"/>
  5. <meta name="msapplication-task" content="name=News;action-uri=http://arstechnica.com/;icon-uri=http://arstechnica.com/favicon.ico"/>
  6. <meta name="msapplication-task" content="name=Features;action-uri=http://arstechnica.com/features/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-features.ico"/>
  7. <meta name="msapplication-task" content="name=OpenForum;action-uri=http://arstechnica.com/civis/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-forum.ico"/>
  8. <meta name="msapplication-task" content="name=One Microsoft Way;action-uri=http://arstechnica.com/microsoft/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-omw.ico"/>
  9. <meta name="msapplication-task" content="name=Subscribe;action-uri=http://arstechnica.com/subscriptions/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-subscribe.ico"/>

Via Kroc Camen comes a call for sanity. Kroc argues that the IE 9 team should just use the HTML5 <menu> element and get rid of all that META tag nonsense:

Microsoft, if you want a way to declare a context-menu in HTML in a browser-agnostic way that is both forward and backwards compatible use HTML5’s <menu> element! Even IE6 supports it without any hacks because it was part of HTML4 and thus, not an anonymous element.

As browser UI begins to converge and websites become more and more integrated into the OSes we use, the menu element is there to describe native toolbars, menus and context menus that the user-agent could expose. It would thus make sense to use this to specify the jump lists as it can easily expand in capabilities in the future and it’s way easier for other vendors to get on board with than the horrible hack that was favicon.ico.

Example proposed usage of the <menu> tag to achieve IE 9 pinning:

  1. < !doctype html>
  2. <head>
  3.     <title>Ars Technica</title>
  4.     <meta charset="utf-8" />
  5.     <meta name="ms-application-jumplist" content="jump" />
  6.     <style>
  7.         #jump   {display: none;}
  8.     </style>
  9. </head>
  10. <body>
  11.     <menu id="jump" type="context"
  12.           label="Ars Technica" title="Ars Technica: Serving the technologist for 1.2 decades"
  13.     >
  14.         <li><a href="http://arstechnica.com/">
  15.             <img src="http://arstechnica.com/favicon.ico" /> News
  16.         </a></li>
  17.         <li><a href="http://arstechnica.com/features/">
  18.             <img src="http://static.arstechnica.net/ie-jump-menu/jump-features.ico" /> Features
  19.         </a></li>
  20.         <li><a href="http://arstechnica.com/civis/">
  21.             <img src="http://static.arstechnica.net/ie-jump-menu/jump-forum.ico" /> OpenForum
  22.         </a></li>
  23.         <li><a href="http://arstechnica.com/microsoft/">
  24.             <img src="http://static.arstechnica.net/ie-jump-menu/jump-omw.ico" /> One Microsoft Way
  25.         </a></li>
  26.         <li><a href="http://arstechnica.com/subscriptions/">
  27.             <img src="http://static.arstechnica.net/ie-jump-menu/jump-subscribe.ico" /> Subscribe
  28.         </a></li>
  29.     </menu>
  30. </body>

Looks nice to me.

Posted by Brad Neuberg at 6:00 am
26 Comments

+++--
3.3 rating from 4 votes

26 Comments »

Comments feed TrackBack URI

It looks like, the markup is a little destroyed on ajaxian…

Anyway, I actually agree with Kroc, except from one point. The meta-tags method microsoft chosen make them “browser-specific” for IE and are ignored by other browsers. If I put a menu-tag in my document this also get interpreted by other browsers and I need css to hide this, no big deal ok – but it gets into the renderprocess and I want to keep that one as clean as possible. What about the further markup? A list, simple img + anchor, definitionlist? Which information from this should microsoft then use to populate their menu?
I would propably suggest something like aria-* attributes => microformats. So you may already have the given elements in your markup and give them the desired attributes, or if not maybe something else in the head-tag, except those awful meta-tags, with rich information while using microformats there.

Comment by gossi — October 8, 2010

Fixed. Thanks.

Comment by Brad Neuberg — October 8, 2010

Does not look nice to me.
.
The menu Element describes data, the meta Element describes metadata.
The meta tag is just the right way to go.
.
Besides it’s not browser specific, nothing prevents other browser to parse thoses and implement them and roll they’re own jumplists.
You can even use them on other OS and use them to build let’s say dock stacks on OSX. Of course they’re is the ms prefix, but I don’t see how this is any different than every other prefixed non standart css properties.

Comment by ywg — October 8, 2010

Nice idea, but <menu> is not valid XHTML (which is the doctype of 1/3 of sites, http://dev.opera.com/articles/view/mama-markup-report-part-1-the-basics/)

Comment by dave1010 — October 8, 2010

Meta should imo be used more for data that is specific to the page itself, not for site-wide configuration data. Besides, the HTML5 WD states “The meta element represents various kinds of metadata that cannot be expressed using the title, base, link, style, and script elements.”

I think this kind of data can perfectly be described by using a link-element pointing to a seperate configuration file, which I also proposed in an earlier blogpost of mine on this very subject.

Comment by crisp — October 8, 2010

Here’s how to add with Javascript… http://msdn.microsoft.com/en-us/library/ff976312(v=VS.85).aspx

i.e. …

if( "external" in window && "msSiteModeCreateJumplist" in window.external ){
window.external.msSiteModeCreateJumplist('Recent Videos');
$("menu li").each(function(){
window.external.msSiteModeAddJumpListItem($('a'.this).text(), $('a'.this)[0].href, $('img'.this)[0].src);
});
window.external.msSiteModeShowJumpList();
}

Comment by Drew81 — October 8, 2010

Well that does seem to be what the menu element is there for. And now that Drew81 has pointed out the existence of a new javascript API to facilitate this thing, it’s worth noting that Kroc Camen’s method would not require a new API, just DOM manipulation. The external XML method doesn’t lend well to realtime updates, though it sounds like a reasonable proposal. I’m leaning towards the menu tag, since it’s leveraging an existing specification instead of creating two ways of doing very similar things.

Comment by adunn — October 8, 2010

Or more accurately, two ways of specifying the same kind of content. It’s all about the content after all ;).

Comment by adunn — October 8, 2010

Can’t help but agree with Kroc. But even using meta tags it seems that MS could’ve used neater, more compact syntax.

Comment by iliad — October 8, 2010

fyi: I’ve got a working example at http://toobify.com/ (click the “Pin Start” in top left).

I totally agree with ywg. I read an comment (probably from ajaxian), about webkitNotifications, and web Notification API. I liked the argument that the browser needs to hook into whatever notification systems the OS provides, rather than create its own. Similarly Windows 7 supports these quick-links, and IE9 is just capitalising on them.

Also: doesn’t google manually creates similiar quicklinks/jumplists for popular sites in its search results… Quick! write another specification!

*This comment was written by a monkey chained to a chair.

Comment by Drew81 — October 8, 2010

Yeah, I was just looking at the Microsoft’s actual documentation for the feature. There’s more to it than a context menu, and it’s very windows specific anyway. The reality of this level of integration with a heterogeneous pool of devices and OS’s is by definition not cross platform; I wouldn’t expect it to be.

Comment by adunn — October 8, 2010

The meta tags aren’t that bad. Just a bit verbose.

The menu option however would be a step back because even if it’s hidden by CSS, it’s still an accessibility problem for screen readers.

Comment by pnewhook — October 8, 2010

@crisp: I really like the idea with a link attribute pointing to an xml file. So the document overall is less cluttered with kilos of extra portion for one browser and the xml even could cached, nice :)
.
Even with an existent javascript API, I wouldn’t like to spent kilos and javascript to just populate a menu on windows. So, a workaround could be a conditional comment, but that can block too.
.
At the moment, this is very browser-specific to IE, because of the ms prefix. I definitely agree, this could be bound to the underlying OS, so website authors can expose quicklinks (or whatever to call them) to the OS. And yes, we recently see this. Apple introduced meta-tags to make “webapps” pinned to iOS (I dont own an iPhone, so I’m not sure how this is called correctly). Google is at the moment doing this for the Chrome Web App Store, so authors could give one metaformat for their application/website and this could be used by manu OS/Browser-Vendors. I would love to see a uniformed way of doing this and not writing a file/tag-set for each environment.
Hmm, am I thinking to enthusiasthic? :)

Comment by gossi — October 8, 2010

Someone suggested that instead of including all the meta crap on every page of a site, burdening every client for little benefit, a single meta tag be used that points to a separate file describing the pinned items. The upside of this is that the file can also be cached. Many sites would have the same items on each page so it makes sense. Those who want it to be more dynamic can use the JS API or just point to different files.

The thing is a pretty crappy solution and doesn’t work well for screen readers and other non-visual clients.

Comment by samsonjs — October 8, 2010

@gossi: The problem with trying to standardize this stuff is that it’s very new and we don’t know all of the use cases yet. Standards should follow usage, not precede it. For example we could give some standards body absolute power and they could enforce the exact use their technology, but that wouldn’t foster much innovation. The problem is that predicting the future is hard. It’s much easy to wait for enough data to make a decision.
.
Usually tool makers are able to come up with good abstractions to help with this stuff, and they can react very quickly to current events. It’s a good way to experiment with different ideas and gather the real usage data of different implementations, and that helps prevent us from going down the wrong path.

Comment by adunn — October 8, 2010

See:
.
http://crisp.tweakblogs.net/blog/5100/ie9-pinned-sites-a-lot-of-cruft-in-your-kleiner-dan-head-groter-dan.html
.
The element will be read by screen readers, you know. This stuff does not have to do with the site’s menu/navigation (though it creates a menu to navigate the site — chew on that).
.
While I think the example above that MS is using is unnecessarily verbose, it does drive me nuts that the “obvious” thing to do is also the least thought out. MS has a responsibility to NOT just go use the tag, break accessibility, and thus break the law, for them and all the websites that are not one-man-shops.

Comment by sroussey — October 8, 2010

BTW: two weeks ago, MSFT answered the question about how to not have a lot of duplicate content on the IE Blog:
.
Israelh [MSFT]
27 Sep 2010 4:59 PM
.
One way to avoid having multiple meta elements on each page is to only define the startURL meta element in all of your webpages. The webpage that the startURL points to will have all of the other meta elements that define the Pinned Site integration experience. In addition, this pattern allows sites to standardize the user experience with a consistent start. This should take care of the meta element duplication that was identified. Facebook is following this approach today.

Comment by sroussey — October 8, 2010

@sroussey: even with that arrangement (all meta tags just on the startpage, only one on all other pages) it’s still a lot of cruft on the one page that is most likely to be visited the most often.
The fact that obviously they have some sort of mechanism to request the startpage to get the rest of all meta information when the user pins the site is even more reason that they should (and could) have used a link element with a separate configuration file. This is also more consistent for implementation (not having to make a distinction between the site’s index page and all other pages – especially when using some sort of template or framework).

Comment by crisp — October 8, 2010

@crisp: An xml file would good for static sites, but they seem to be interested in what dynamic sites are able to do with the feature. One of their examples is showing a notification for a meeting. In that case caching anything would be pointless anyway, and would make things more difficult.

It’s not so much data that I would worry. The latency of the head request and response that will happen on every page load anyway to check the last modified date of the xml file will take far longer than it will to actually transmit the data inline with the document. So speed probably isn’t an issue. Especially with the 3 MB (!) of jQuery plugins in the head (!!) of the document that will invariably come down the pipe next (maybe not on your sites, but I see that all too often).

Also that’s a more complicated implementation for developers — if you’re outputting dynamically you’ll have to mess with response headers and you would be of process of the actual page request and might not have the entire context available. It’s certainly doable, just not as easily, and it looks like they are going for easy.

Comment by adunn — October 8, 2010

Honestly, I agree with Microsoft’s positions on this one and here is why. When it comes to semantic page layout the pinned menu is NOT part of the body of the page. To stick it into the body seems to me to blur the lines of the what is page specific and what is chrome specific. For instance the title element goes in the head because it related to the browser chrome, and not the page content. Similarly the pinned menu items really relate to the browser chrome and thus should be in the head element. Now maybe the implementation could be refined, but really I think it is best in the head. No one is stopping other browsers from implementing this feature, and if you don’t like it … don’t implement it, or do it with JavaScript.

Comment by fredclown — October 8, 2010

Why not standardize on a mechanism like favicon.ico or crossdomain.xml? An external xml (or other format) that specifies a custom menu in a way that can be consumed by other clients.

Comment by tgfoster — October 8, 2010

I think it should be in a SEPARATED FILE. Why to make the html document bigger and bigger?

Comment by wagoon — October 8, 2010


I think the idea of using the tag is not a good one.. What’s to stop people inserting whatever they want into these tags?

Some random text Sub menu

Comment by elkaz — October 8, 2010

Comment fail :S

Comment by elkaz — October 8, 2010

All of this discussion is really based on Ars writing about before MS came out with the docs for it. When it is all said and done, it probably should have been a JS-only API so people don’t put the whole jump list thing in every page, likely including the stuff for non-IE9 browsers.

Using the meta tags seems like it was meant for the noobs intro into how to do it *really fast* so they can be the first to get it on their site. Then again, who care if there is extra cruft for tiny sites with one-man web teams? Larger sites will use better ways, so everyone wins.

Such a non-event.

Comment by sroussey — October 9, 2010

I agree with @wagoon:

Just like the flash crossdomain.xml, or the sitemap.xml format, or the robots.txt – win7 pinning stuff should be located in a separate file.

The logic is simple – is the menu page specific? No. Then the extra markup on each page is cruft and redundant. Meta-tags should be used when the “meta information” truly is information to the information contained in this page.

Hristo

Comment by tutini — October 10, 2010

Leave a comment

You must be logged in to post a comment.