<!-- page.html -->
<meta name="msapplication-jumplist" content="http://arstechnica.com/jumplist.xml">
<!-- jumplist.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<tooltip>Ars Technica: Serving the technologist for 1.2 decades</tooltip>
<!-- etc -->
No. The request only happens if you decide to "pin" the site, or otherwise give it a first-class status on your machine (one could imagine the same by pining it to the OSX dock or making a site into a "standalone app", I think there was a browser doing that a while ago)
Erm... you make absolutely no sense here?
Of course the "HTML version" (aka hello we're talking about web pages here) is the main resource, what else would be, unicorn and ponies?
The format was RDF, any any day now it's going to take over the web with all this nicely formed, semantic data!!
"You may add your own values to this list, which makes them legal HTML5 metadata names. We ask that you try to avoid redundancy; if someone has already defined a name that does roughly what you want, please reuse it."
They will also argue that menu is intended to create toolbars and menus within a webpage, not within the browser itself - and that by using meta extensions, the IE team have implemented their browser-specific extensions in a standards-based way supported by the WHATWG. They will say that it also doesn't pollute the markup with an extension that only applies to a single browser on a single platform (which is why WHATWG developed the meta extensions). In short, pages that implement this are HTML5 compliant.
Now my own opinion. The browser makers need differentiation between their products. Browser market share is as important, if not more important, than OS market share.
If Microsoft want to enable websites to deeply integrate with a Windows desktop by using meta extensions, then that seems like the right place to do it. A lot of us would prefer that every browser maker simply implements the standards, but a lot of innovation in web technologies (img tag, applets, xmlhttprequest) started life as browser-specific extensions. Frowning upon, or not allowing any differentiation would remove a lot of motivation for pouring resources into browser development.
As much as we might not like it, we have to deal with it - at least they put this extension in the right place with meta instead of not implementing menu properly or doing their own implementation of menu (besides, I can't think how this desktop pinning would work on for eg. OS X and Chrome - it seems something very 'active desktop' windows specific).
"A lot of us would prefer that every browser maker simply implements the standards, but a lot of innovation in web technologies (img tag, applets, xmlhttprequest) started life as browser-specific extensions. Frowning upon, or not allowing any differentiation would remove a lot of motivation for pouring resources into browser development."
Very well put.
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.
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 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.
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.
yes, what about screen readers? Screen readers get a well-thought-of menu of accelerators to existing features of the website. If the website is well coded, this can even be one of the website's own, displayed menus.
What is there not to like?
Instead, by embedding it in random meta elements, screen readers have to download the useless code (as does every other browser out there) and can not use any of it.
You're right, it's brilliant.
<meta name="viewport" content="width=device-width, maximum-scale=1.0, user-scalable=no" />
Edit: indeed, this is a bug: there are different CSS styles for devices with < 480px screen width and > 480px (via @media CSS rules). Desktop browsers pick the latter style and ignore "viewport" meta tag. iPhone picks the former style and takes into account viewport. iPad picks the desktop style and takes into account viewport, which disables zoom (intended for the iPhone style version).
Now that I debugged the problem, can we instead report bugs to website designers instead of commenting here on HN?
That and logging in, but this one I suspect is a browser problem.
- should we allow companies to bend the standard in order to innovate?
- is this implementation a good way to implement this innovation?
- is this an innovation that we would like to see on other OSes?
I think the answers to these questions should be yes, no, and maybe. The 'yes' is because that is the norm, and it hasn't turned out bad. The 'no' is for two reasons:
- as others indicated, putting this stuff in an external file makes more sense.
- terminology could be made a bit more platform independent.
</figcatpion> should be </figcaption>
Ps: I sent an email to the author of the blog post inviting him to join the conversation here. If interested.
Here is how it looks like for me: http://s1.image.gd/o/d6/d63da036dc4e2e93670dac425ca017d9b227...
I'm guessing this will be in a jQuery plugin very soon.
A jump list isn't a bunch of metas either. An HTML <menu> or a specific, custom XML format can be ways to describe jumplists. These descriptions are then translated into whatever actual format jumlist specs use. No problem.
> I'm not sure describing it with html tags makes sense
A jump list is a menu. So is a <menu> element. You could hardly make more sense.
Hmm. With the iPod, there's the apple-touch-icon.png