Microsoft, Please Stop This Madness | Hacker News Reader

Microsoft, Please Stop This Madness

camendesign.com

245 points_e_55 comments

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>

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

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

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.

> 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)

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

> 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?

Well, to be fair, HTML5 also already has the <meta> extension mechanism. I know you're not making the argument that one is more "standardsy" than the other; you're just pointing out that both approaches are equally "standard".

Though I'll never use IE as a daily browser, I do love the possibilities with this new SSB (Site Specific Browser) and jump list functionality. That said, I like your way of doing it better. It's much cleaner than the "spam the main file" method they're using now.

This also has the advantage of not bloating every HTML page with the jump list data. Using an external resource that is downloaded once at the time of pinning is clearly a technically superior mechanism and I'm surprised that it's not implemented like that already.

Oh, you mean like Aurora was going to use? That's Netscape Aurora, in 1998 http://xml.coverpages.org/revengeXML.html

The format was RDF, any any day now it's going to take over the web with all this nicely formed, semantic data!!

Shit, I thought JSON had taken over by now. Well, I guess html is XML, and you know they say XML is like violence; if it didn't solve your problem is because you didn't use enough...

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

I think the other thing that they will say (if they have any guts) is that this is a beta, and that the point of a beta is to get technical feedback and respond to it. Therefore, it is entirely unnecessary to take such a strongly negative tone in making this relatively minor and mostly incorrect criticism.

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.

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.

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

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

> Here[1] you can see that the standard places no restrictions on what can be entered in the <meta> name option

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.

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

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.

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.

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.

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

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.

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.

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

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.

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

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.

Well, for that matter HN has a fixed minimum width defined which makes it unable to display properly on an iPad (ie. without scrolling back and forth to read comments).

That's odd. I never have to horizontally scroll comments in my Android browser.

Well... Since we are reporting bugs, the Nook browser is also unable to properly show HN without horizontal scrolling.

That and logging in, but this one I suspect is a browser problem.

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

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

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

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?

Ah, okay, I got the irony with the non-standard Apple's meta tag :) Took me 18 hours.

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.

It zooms just fine on Safari on the Mac.

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.

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.

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

</figcatpion> should be </figcaption>

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.

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

The conversation on reddit wasn't that interesting because the post itself isn't that interesting, or insightful, or worth anyones time.

Fixed, thanks for the keen-eye.

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

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?

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.

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

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.

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

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

Madness? This... is... Microsoft!

"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

Reply on news.ycombinator.com