1) It's much easier to stick meta tags in HTML than it is to reference an external file in many cases (blog hosting services, hosted storefronts, etc).
2) Sites that make the best use of that menu will have different data depending on what page is pinned. We didn't do much implementation, but assuming enough people used IE9 we'd probably make that set of meta tags page dependent. Separating it into an external link when it's page specific data doesn't make a bunch of sense. Particularly page specific data that changes frequently.
Also, that 1kb of text is more like 260 bytes gzipped (as it is for us). We'll survive. :)
Interesting. I would have expected the Menu to be identical for a site or application. Maybe have different ones for a forum vs a dashboard, but identical between topics in the forum. What is the use-case for a different menu per-page? Do you expect users to pin different pages?
And even gzipped, 260B * 1M pageviews/day is ~ 1GB a month. Plus the memory to hold the text, the CPU to compress it, versus serving a static file from Apache to the fraction of users the ask for it? Still sounds like a win.
Maybe make it even more like stylesheets: embeddable in the page or linkable to another page.
I have to agree with this article in that there is FAR too much text being added to the webpage for this functionality. Separating it out into a separate file is the way to go. You know, like CSS already does.
I also agree. Given that the pinned menu isn't even rendered in the browser it seems strange to describe this resource in a page. The lifecycle doesn't fit at all. If the content of the pinned menu changes I wouldn't expect to have to reload a page in the browser. Windows will be making a request for the page resource and then completely ignoring the html.
The extra HTTP request only has to be performed on pinning, probably only once (or at least only once in a long time depending on the HTTP headers, and the refresh of the file can be performed asynchronously by the browser when and where it thinks it should check) and only by users actually able to pin (so IE9 users).
The external resource can be cached, pre-generated, shared, managed separately from your page templates.
The main argument seems to be that the metadata involved here is to do with the site, not the page, whereas <meta> tags should be for resource-specific use.
I up voted both these comments because it just goes to show that different people care about different things. It is not a matter of better, just a matter of preference.
Bear in mind that a HTTP Request is significantly slower than the bytes in the page. A request could be anything from .25s to 2 whole seconds, if the bandwidth is saturated. Not least problems with blocking other parallel downloads and delaying the initial paint. HTTP requests that are not images or the CSS are to be absolutely avoided!
Since this isn't used until the menu is pinned, and doesn't show on the page, the time it takes to download should only be taken when the user requests that it be pinned. This shouldn't hold up the page being rendered, since it is not page content.
Edit: Additionally, how does what's in the pinned menu get updated? Does it need to make a full page request to get the new items? This will needlessly inflate pageview numbers in that case (I'm sure the "fix" for that will be that Microsoft will change the User Agent to say that it's not the browser but rather than pinned menu making the request). As for implementation, does the browser create the menu from the this and it's static? Or does the URL to the page get passed to the menu bar where it is pinned and then the menu bar is responsible for making the request? Or does the browser actually run the menu bar -- this seems like the wrong kind of integration.
Maybe I'm just out of touch, but does anyone actually use the pinned menu? If no, does it matter how Microsoft decides to implement this? It seems like it's a feature roughly on the importance level of their web snippets feature; that is, not very important at all.
I use the jumplists, pinned and recent documents/files/sites for a bunch of apps in Windows 7 (Outlook, Chrome, Visual Studio, Notepad, Remote desktop, etc etc).
If websites comes to support this, I'm pretty sure I will welcome that as a feature. Not required by any means, but a nice extra.
Yeah, I was surprised not to see your sample XML in the article.
I really hope this appeal gains some traction. Pinning and jump-lists should be seen as Windows 7 features, not IE9 features (which runs on Vista too).
I'd put the odds of this feature even being used by most web developers at about 10%. If no other browser supports it, what's the point?
It'd be much better if MS were to just take a page outline (from all the headlines) that were links and make their menu out of that. Or, look at the HTML5 <nav> elements. Then IE9 users might actually see it in use once in a blue moon.
10% of the IE9 users is really a huge absolute number. It's probably larger, too, when you consider it could become applicable to all browsers on Windows 7. If it gains traction, it or something similar might be picked up by OSX or Gnome/KDE.
It's still worth investigating doing it right, instead of letting IE define the standard, and letting it stagnate.
Um, I'm going to go out on a limb and guess that there will be at least one major browser bug leading to a remote compromise from this feature.
Maybe I'm just paranoid...
Perhaps, if the <link> points to a menu.xml you don't control? I'm not sure what you could do with this that couldn't also be done with <link rel=stylesheet>...
The pinned menu feature allows you to put images and text on a native system menu. It is conceivable that a malicious person could use this to crash the browser, or have unauthorized code run.
Sorry, I wasn't more clear. I meant the browser feature, not the specific implementation.
I think the idea in the article was fantastic, and would be much cleaner for developers.
My original comment deserved it then, not my clarification and praise of the implementation idea in the article?
The idea of a website being able to inject things into the task bar menu seems like it would open the door for injecting things that overflow buffers, call other code, etc. What is the security model for that code? What are the limits on what the URL can point to, etc.
It's not like the IE team has a stellar record for this kind of stuff?
I can't seem to ropy to the child of this post, but this is a response to that.
All of those risks are present for PDFs or png images. If the browser's XML parser is vulnerable, having this feature additionally available won't make and difference.
1) It's much easier to stick meta tags in HTML than it is to reference an external file in many cases (blog hosting services, hosted storefronts, etc).
2) Sites that make the best use of that menu will have different data depending on what page is pinned. We didn't do much implementation, but assuming enough people used IE9 we'd probably make that set of meta tags page dependent. Separating it into an external link when it's page specific data doesn't make a bunch of sense. Particularly page specific data that changes frequently.
Also, that 1kb of text is more like 260 bytes gzipped (as it is for us). We'll survive. :)