
Microsoft, Please Stop This Madness - _e_
http://camendesign.com/blog/stop_this_madness
======
alextgordon
I think the best way to do it would be an XML file referenced from a meta tag.
This is a property of websites, not web pages, so it makes sense to put all
the information in one place.

    
    
        <!-- page.html -->
        <meta name="msapplication-jumplist" content="http://arstechnica.com/jumplist.xml">
        
        <!-- jumplist.xml -->
        <?xml version="1.0" encoding="UTF-8"?>
        <jumplist>
            <name>Ars Technica</name>
            <starturl>http://arstechnica.com/</starturl>
            <tooltip>Ars Technica: Serving the technologist for 1.2 decades</tooltip>
    
            <task>
                <name>News</name>
                <action-uri>http://arstechnica.com/</action-uri>
                <icon-uri>http://arstechnica.com/favicon.ico</icon-uri>
            </task>
            <task>
                <name>Features</name>
                <action-uri>http://arstechnica.com/features/</action-uri>
                <icon-uri>http://static.arstechnica.net/ie-jump-menu/jump-features.ico</icon-uri>
            </task>
            <!-- etc -->
        </jumplist>

~~~
rafaelferreira
Yeah, a reference to an external file would be a better way to do it. And
HTML5 already has the mechanism for this sort of thing: the <link> element[1]
and the "rel extensions" registry.

[1] [http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/semantics.html#the-link-element)

[2] <http://wiki.whatwg.org/wiki/RelExtensions>

~~~
andreyf
Uh, doesn't that just add an extra round trip and yet another mandatory HTTP
request? No thanks, I think we've enough of those.

~~~
masklinn
> Uh, doesn't that just add an extra round trip and yet another mandatory HTTP
> request?

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)

~~~
andreyf
Even worse. That gives first-class status to the "HTML version" which contains
links to all of the other "versions" of a webapp.

~~~
masklinn
> That gives first-class status to the "HTML version"

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?

------
bl4k
I can tell you right away what their response will be, and it is that meta
extensions are an accepted way of extending HTML5 with browser-specific
features, see:

<http://wiki.whatwg.org/wiki/MetaExtensions>

 _"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).

~~~
qeorge
I must confess, this post makes me feel a bit like Edward Everett. In the
future when I attempt this argument, I'll just quote you:

 _"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.

------
mrkurt
Wow, weird to see markup of mine show up in a blog somewhere.

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.

~~~
masklinn
> I don't buy the idea of hijacking a menu tag to alter browser chrome.

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.

~~~
Locke1689
Because as people have already said, doing a CSS hack so that your <menu> hack
doesn't display in the page itself is worse than doing the standards-compliant
method of implementing the browser-specific feature via the meta tag.

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...](http://www.whatwg.org/specs/web-apps/current-work/#attr-meta-name)

~~~
kroc
I don’t think you understand what “CSS hack” means.

~~~
Locke1689
By hack I meant workaround to overload the original function of the CSS menu
tag to replicate the function of the <meta> tag. The <meta> tag is explicitly
meant to represent metadata about the page. The <menu> tag is explicitly meant
to represent a menu _in_ the page.

------
kevingadd
I don't know if I buy it. The jump list isn't really part of the page itself,
it's metadata attached to the 'website' in question, so I sort of understand
them putting it in <meta>... at the very least, I don't think it makes sense
as an inline <menu> element in the middle of the page content. It sucks having
all those meta tags there, though, since that's a huge blob of html that has
to go in the header of every page when it really should live in a metadata
file somewhere on your site... sort of like a stylesheet.

~~~
alsomike
His solution is to put the menu in the page content, and use a CSS work-around
to not display it. What about screen-readers? I don't think he thought this
through.

~~~
masklinn
> What about screen-readers? I don't think he thought this through.

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_.

~~~
alsomike
And screen readers would implement that by detecting a meta tag named "ms-
application-jumplist"? In other words, screen reader developers should support
proprietary Microsoft extensions rather than using the standard methods of
supporting screen readers?

You're right, it's brilliant.

------
thought_alarm
Speaking of stopping the madness, this guy's website uses a fixed viewport
that prevents iPad Safari from zooming in and out. Stop the madness, indeed.

~~~
carussell
Maybe you should be directing your anger at Apple for implementing the quick-
but-harmful viewport hack in the first place.

------
Groxx
They have a point, but... <menu> != what they did. It's an add-on for an
_external_ menu on IE _in Windows_ ; extensions make sense there.

------
rscott
I wish his "HTML 5 from early 2008" site would support zooming on my iPad,
pretty obnoxious it doesn't.

~~~
dchest
I wish people stopped complaining on HN that linked websites don't work on
their iPads, and instead sent bug reports to Apple or authors of the websites.

~~~
jonknee
It's not a bug, it's intentional (and thus obnoxious):

<meta name="viewport" content="width=device-width, maximum-scale=1.0, user-
scalable=no" />

~~~
dchest
OK, but why not ask the author to fix this?

~~~
mahmud
Because it's ironic that he's being a stickler for standards when his own site
is broken.

~~~
dchest
There is nothing ironic in the fact that people cannot afford to test their
websites on every single device Apple releases. FYI, I just opened that
website on my iPhone and it works great. Perhaps, the viewport meta tag was
added here with iPhone in mind, before iPad was released.

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?

~~~
kroc
Yes, the problem is that iPhone’s HTML layout engine breaks the page when you
rotate the phone, then breaks it further when you rotate it back to where you
were. I put the viewport tag in to solve the iPhone, but then the iPad came
out and there’s no way to have a different viewport for an iPhone / iPad.
Blame Apple, I’m still trying to find a working solution.

------
jasonlotito
_sigh_ This again? Okay, Apple does the same thing with meta tags and links. I
don't see the issue here. MS is using the standards. I mean, this guy is
basically asking for MS to break with convention and do something people might
not have intended. Rather, this way is explicit.

------
Someone
I see three different 'issues':

\- 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.

The 'maybe' is because I think this innovation will turn out to be useful.
Other OSes or browsers could implement the way to activate in a completely
different way. On the other hand, I do not quite see how this is different
from a bookmark that the browser UI knows to display in a small pop-up window.
A single meta-tag that indicates 'show this URL in a small borderless window
close to what you think is the point it was opened from', plus some Javascript
call 'ask the user to put the following URL in his start menu' could do most,
if not all what this tries to accomplish. Splitting this into parts has the
advantage that it promotes reuse.

------
ryanwaggoner
Just FYI, you've got a typo in your markup that's preventing your page from
validating:

</figcatpion> should be </figcaption>

~~~
_e_
Actually it's not me the author. I run in the link at reddit (the conversation
there wasn't that interesting about the topic) so i thought to submit it here.

Take care, _e_

Ps: I sent an email to the author of the blog post inviting him to join the
conversation here. If interested.

~~~
stanleydrew
No need to sign your name. We can tell it's you from the username. See the
comments section of the guidelines:
<http://ycombinator.com/newsguidelines.html>

------
aw3c2
If you read what you saw and it made absolutely no sense, there is actually
more below the image. The footer makes it look like the article has ended.
It's like a frame but with no apparent scrollbar. Terrible non-intuitive
webdesign (sure looks fancy though).

Here is how it looks like for me:
[http://s1.image.gd/o/d6/d63da036dc4e2e93670dac425ca017d9b227...](http://s1.image.gd/o/d6/d63da036dc4e2e93670dac425ca017d9b2278fb7.jpg)

~~~
kroc
Scrollbar should be there, what web browser are you using? The y-overflow is
hidden on html, but not on body for page-centering reasons but this has not
affected browsers I have tested thus far. Maybe you’re on kHTML?

------
armandososa
I don't have access to IE9, but maybe it's possible to create the necessary
meta tags using javascript to clone a <menu> (or <nav> or a list with links
for that matter) the same way jQTouch creates the apple meta-tags on the fly?

I'm guessing this will be in a jQuery plugin very soon.

------
Twisol
Wait, hang on... Why can't a microdata format be used for this? It seems like
it would be a perfect fit to me. Granted, I've never actually used microdata,
but from what I've read...

------
confuzatron
A jump list isn't an HTML document - I'm not sure describing it with html tags
makes sense, since it'd be too easy to write invalid jumplist markup that's
valid HTML. I could envisage somehow replacing RSS with HTML (use the right
tags, in the right order, don't use the wrong tags), but it wouldn't make much
sense.

~~~
masklinn
> A jump list isn't an HTML document

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.

~~~
confuzatron
A jumplist menu doesn't support the content that an HTML menu lets you author.
It's only a superficially sensible idea.

------
ricardo_sdl
Madness? This... is... Microsoft!

------
WalterBright
"This is the exact same kind of terrible, short-sighted, browser-specific
garglemesh that plagued the web with favicon.ico a Microsoft only image format
that forced a specific file name and location (and generates billions of 404s
across the web every day)."

Hmm. With the iPod, there's the apple-touch-icon.png

