The <title> tag does it with no big issue. Though an external <link>ed file (à la RSS/ATOM) would be much better. Meta tags are not really structured and forces everybody to download a bunch of browser-specific crap they don't carte for.
> As an aside, I can tell you that if they'd implemented it as a menu tag, we wouldn't have put it on Ars for the purposes of that article.
Why not? If you don't already have a menu with these "essential tasks" it becomes a great one, and if you do have one and don't want to bother with reimplementing it as <menu> (yet anyway) display: none on the jumplist menu.
Here[1] you can see that the standard places no restrictions on what can be entered in the <meta> name option and the browser is not required to implement handlers for all names. Given that this is not display HTML, I think the <meta> tag is the perfect place for this.
[1] http://www.whatwg.org/specs/web-apps/current-work/#attr-meta...
Just because the standard places no restriction on it doesn't mean it's a good idea.
> doing a CSS hack
Setting a CSS property is not a hack.
> so that your <menu> hack
Using existing, well-defined elements whose purpose perfectly fit the needs of the situation is not a hack.
> is worse than doing the standards-compliant method of implementing the browser-specific feature via the meta tag.
There is nothing non-standard-compliant about using a <menu> object for defining a menu.
Meta tags are the most standards compliant way to do those jump menus. I don't buy the idea of hijacking a menu tag to alter browser chrome. From an implementation perspective, I'd much rather they let me link to a manifest file of some kind than add multiple meta tags in places, but it's not a horrible choice.
As an aside, I can tell you that if they'd implemented it as a menu tag, we wouldn't have put it on Ars for the purposes of that article.