This is a document written using ReMarkable, a shorthand syntax for generating HTML.

{	"date"		:	201009161416,
	"updated"	:	201009211300,
	"licence"	:	"cc-by",
	"tags"		:	["windows", "annoyances"]
}

<section>

# Microsoft, Please Stop This Madness #

<aside>
	*Update:* _
	Added <response to feedback (#answers)>.
</aside>

*Microsoft have released a beta of Internet Explorer 9.* This much is good, they’re back in the game. The engine supports modern standards—and for the first time Internet Explorer now renders this website (which has been HTML5 <since early 2008 (/hello)>).

I said that my website will work with IE when Microsoft fix IE to work with my site, rather than change my code to suit them. They have done exactly that. This is a new era where developers can code for standards and expect browsers to support _them_ instead of the other way around.

One feature IE9 supports is pinning websites to the task bar as web-apps. Microsoft have said that the jump list (neé context-menu) in Windows 7 can be customised using some HTML. I was intrigued by this part—_what_ HTML, exactly?

fig.	<"Example of IE9’s ‘jump-list’ menu on Ars Technica" /blog/stop_this_madness/ie9-ars-jump-list.png>
	
	: IE9 web-app jump list¬image courtesy of <Ars Technica (//arstechnica.com/microsoft/news/2010/09/inside-internet-explorer-9-redmond-gets-back-in-the-game.ars)>

This HTML, apparently.

~~~ HTML ~~~>
<!-- C-razy IE9 stuff -->
<meta name="application-name" content="Ars Technica"/>
<meta name="msapplication-starturl" content="http://arstechnica.com/"/>
<meta name="msapplication-tooltip" content="Ars Technica: Serving the technologist for 1.2 decades"/>
<meta name="msapplication-task" content="name=News;action-uri=http://arstechnica.com/;icon-uri=http://arstechnica.com/favicon.ico"/>
<meta name="msapplication-task" content="name=Features;action-uri=http://arstechnica.com/features/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-features.ico"/>
<meta name="msapplication-task" content="name=OpenForum;action-uri=http://arstechnica.com/civis/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-forum.ico"/>
<meta name="msapplication-task" content="name=One Microsoft Way;action-uri=http://arstechnica.com/microsoft/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-omw.ico"/>
<meta name="msapplication-task" content="name=Subscribe;action-uri=http://arstechnica.com/subscriptions/;icon-uri=http://static.arstechnica.net/ie-jump-menu/jump-subscribe.ico"/>
<~~~

Stop this madness 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).

Microsoft, if you want a way to declare a context-menu in HTML in a browser-agnostic way that is both forward and backwards compatible *use HTML5’s <``<menu>`` element (//www.whatwg.org/specs/web-apps/current-work/#menus)>!* Even IE6 supports it without any hacks because it was part of HTML4 and thus, not an anonymous element.

As browser UI begins to converge and websites become more and more integrated into the OSes we use, the menu element is there to describe native toolbars, menus and context menus that the user-agent could expose. It would thus make sense to use this to specify the jump lists as it can _easily_ expand in capabilities in the future and it’s way easier for other vendors to get on board with than the horrible hack that was favicon.ico.

All the developer needs to do is include an HTML5 ``<menu>`` element which for backwards compatibility they can hide using CSS, and a meta tag to tell IE the ID of the menu element to use as the jump list.

~~~ HTML ~~~>
<!doctype html>
<head>
	<title>Ars Technica</title>
	<meta charset="utf-8" />
	<meta name="ms-application-jumplist" content="jump" />
	<style>
		#jump	{display: none;}
	</style>
</head>
<body>
	<menu id="jump" type="context"
	      label="Ars Technica" title="Ars Technica: Serving the technologist for 1.2 decades"
	>
		<li><a href="http://arstechnica.com/">
			<img src="http://arstechnica.com/favicon.ico" /> News
		</a></li>
		<li><a href="http://arstechnica.com/features/">
			<img src="http://static.arstechnica.net/ie-jump-menu/jump-features.ico" /> Features
		</a></li>
		<li><a href="http://arstechnica.com/civis/">
			<img src="http://static.arstechnica.net/ie-jump-menu/jump-forum.ico" /> OpenForum
		</a></li>
		<li><a href="http://arstechnica.com/microsoft/">
			<img src="http://static.arstechnica.net/ie-jump-menu/jump-omw.ico" /> One Microsoft Way
		</a></li>
		<li><a href="http://arstechnica.com/subscriptions/">
			<img src="http://static.arstechnica.net/ie-jump-menu/jump-subscribe.ico" /> Subscribe
		</a></li>
	</menu>
</body>
<~~~

This has the added benefit of being valid HTML5 and far more future proof than an insane collection of messy meta tags. This is a fully parseable tree that would be easier to mash up and present in external contexts.

Microsoft, please don’t cripple user-agents with another bone-headed mistake like favicon.ico again. You may support all the standards with your new browser but you have a long way to go to learn about writing decent HTML and we don’t want you screwing it up for all of us, especially those who have been already using HTML5 for the last two years and don’t want to go back to doing things “the Microsoft way” and duplicating for “the proper way”.

There’s a standard for context menus, now please use it.
¬¬
Kind regards, _
_Kroc Camen._


Assertions Answered: (#answers)
============================================================================================================================
Well, my my, this attracted a lot of attention. My thanks goes out to all those who helped spread this blog post, first across Twitter, then on Reddit, then on HackerNews and as I’ve heard from kind users, apparently into the very bowels of Microsoft.

There has been much feedback, and aside the positive, it falls into the following categories:

:: Using a CSS hack to hide the ``<menu>`` is wrong
	
	I don’t think you understand the term “CSS hack”. This is _just_ CSS. This is the exact opposite of a hack.
	You don’t even have to use the <IE HTML5 shim (http://code.google.com/p/html5shiv/)>, because ``<menu>`` is a
	recognised element in IE6+. Hiding this from non-supported browsers is exactly the thing we should be doing, and if
	screen readers do pick it up—then all the better—it’s infinitely more accessible than a bunch of meta tags which
	are purposefully designed to be invisible from the document and not presented to the user in any way.
	
	Screen readers would greatly benefit from being able to just press a key and get a jump list to the most pertinent
	navigation, rather than scrolling through the ads and <pointless fluff (/web-dev/if-i-designed-engadget)> that bogs
	pages down these days. This directly relates to the next point…

:: This is an external menu, not one within the page
	I’ve heard it said many times that ``<menu>`` is for menus _inside_ the page, not outside.
	In my opinion ``<menu>`` is for defining _chrome_, not just in-page content. That is, chrome may take whatever form
	is relevant to the particular application, operating system and device that it is in use. Not all menus have to be
	menu-shaped and look like menus and appear in menu places.
	
	We need to seriously think outside of IE, outside of Windows and outside of desktop operating systems.
	
	Just because Internet Explorer presents the data as an external context-menu on the application icon, that doesn’t
	mean that that should be the one and only use for the data (which is the very problem with what Microsoft have done
	here). What if another user-agent wants to show the menu inside the browser, when you right-click on a tab? Or in
	the regular context menu, or in a pie menu on a special key press, or as a spoken list for screen readers? Or even
	printed out and flown to you by pigeon—if you so please?
	
	The _point_ is that it is entirely up to the application, the operating system, and the hardware to decide for
	itself what is the appropriate way to display this information and Microsoft’s one browser, one OS, one platform
	[to rule them all] approach is the problem.
	
	Why should every web author be burdened with this bloat for one browser’s feature? Should we have a set of metadata
	for Firefox, a set for Opera, a set for WebKit and another set for the different style of chrome in mobile
	browsers? Is 100+ lines of meta the right way to do this as more and more OS-integration occurs?
	
	Is IE9 on Windows 7 _the only way_ to design a browser and to implement a feature?
	
	Microsoft completely sidestepped the democratic processes, instead having foistered on us a perpetual desktop
	browser mindset which has left them <three years behind the competition in the mobile space with a completely
	useless mobile web browser (/writing/missed_the_boat)>.
	
:: Experimentation with proprietary additions is normal, and good
	Yes, and it’s
	<why we have the ``<img>`` tag (//web.archive.org/web/20110709121809/http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element)>,
	``<canvas>``, and even <the ``<video>`` element (//www.osnews.com/story/22677/_Re-_Introducing_HTML5_Video)>.
	
	There's a big difference between a feature that one browser vendor adds for the benefit of all other vendors
	(see how vendors have played off of what others have shipped to help shape ``<video>`` support), and features that
	are <purposefully obtuse (//weblogs.mozillazine.org/roc/archives/2010/01/activex_all_ove.html)> and are instead
	designed only to
	<spearhead market share (//osnews.com/story/23735/MPEG-LA_Makes_Free_Internet_Video_Royalty_Free_Perpetually)>.
	
	I am to take it, Microsoft, that you will be donating the {ICO|icon} format to the public domain, correct? You are
	recommending that web authors should use this proprietary format and that other web browsers should too [since you
	won’t accept other file formats like PNG in jump lists].
	
	How Microsoft have designed this standards-extension is for the purpose that _you_, dear web-authors, will write
	this ugly code into your pages and help sell copies of Windows 7 for them for free (IE9 won't be available for
	Windows XP, despite Firefox providing hardware acceleration on XP just fine). Want a better integrated web?
	Simply buy a PC running Windows 7, or upgrade your old Windows XP! You could of course just download any web
	browser for free and even use a free operating system, but promoting that won't sell copies of Windows 7, so this
	new feature needs to be executed in an IE-only fashion to deter other vendors from implementing this feature in
	other-contexts not related to Windows 7. Not least what I've laid out in the previous point with user-agents
	perhaps coming up with _better_ ideas (I would quite like my news delivered by pigeon at just the click of a
	button).
	
	Okay, okay, so I’m being unduly unfair to Microsoft. They have every right to put whatever features into their
	software and better integration with the specific behaviours of operating systems is a very good thing, compared to
	making all browsers look the same and smell the same regardless of platform.
	
	But—and it’s a big but—I have been so uppity over this feature announcement because Microsoft don’t seem to have
	acknowledged that they no longer control the web and are just merely participants with a number of other brothers
	and sisters who are all trying to steer the good ship ’Web in a good direction, and that Microsoft—if it does not
	want to offend—should not just grab the wheel and steer it head-first into Windows-land.
	
	Can you honestly say Microsoft that having this markup around for 10 years is going to be just peachy?
	That it’s in no way short-sighted? Is it really going to help a diverse web full of different browsers on different
	hardware, with different screen sizes and input methods on different operating systems?
	
	Your meta data method has to be parsed and extracted in an oblique, single-purpose way unlike any other part of
	HTML5, especially the HTML5 parsing algorithm, which my example markup does work with (it being valid HTML5).
	
	Your HTML, like diamonds, should be forever.

The future of the ‘browser wars’ is he who integrates with the OS best. We can do this either the hard way, or we can do this the easy way. I hope we choose the way where everybody participates fairly and makes use of each other’s innovations rather than stifling the progress of the individuals who we are privileged enough to design and build for their future.

</section>