Everything except the search is implemented in JavaScript, so the server never knows the playlist. Because I didn't want to send the playlist to the server just so the user can download it I investigated what methods there are to save data generated in JavaScript. I came up with the solution presented here. It does not use Flash or a echo server and is therefore supported in every recent browser except Internet Explorer before the version 10.

Feature test: Does this browser support the download attribute on anchor tags? (currently only Chrome)

Use any available BlobBuilder/URL implementation:

IE 10 has a handy navigator.msSaveBlob method. Maybe other browsers will emulate that interface?
See MSDN about it.

Anyway, HMTL5 defines a very similar but more powerful window.saveAs function:

However, this is not supported by any browser yet. But there is a compatibility library called
FileSaver.js
(github) that adds this function to browsers
that support Blobs (except Internet Exlorer).

Mime types that (potentially) don't trigger a download when opened in a browser:

Blobs and saveAs (or saveBlob)

Currently only IE 10 supports this, but I hope other browsers will also implement the saveAs/saveBlob method eventually.

I don't assign saveAs to navigator.saveBlob (or the other way around) because I cannot know at this point whether future implementations
require these methods to be called with 'this' assigned to window (or naviagator) in order to work. E.g. console.log won't work when not called
with this === console.

Blobs and object URLs

Currently WebKit and Gecko support BlobBuilder and object URLs.

Currently only Chrome (since 14-dot-something) supports the download attribute for anchor elements.

Now I need to simulate a click on the link. IE 10 has the better msSaveBlob method and older IE versions do not support the BlobBuilder interface and object URLs, so we don't need the MS way to build an event object here.

In other browsers I open a new window with the object URL.
In order to trigger a download I have to use the generic binary data mime type "application/octet-stream" for mime types that browsers would display otherwise.
Of course the browser won't show a nice file name here.

The timeout is probably not necessary, but just in case that some browser handle the click/window.open asynchronously I don't revoke the object URL immediately.

Using the filesystem API you could do something very similar.
However, I think this is only supported by Chrome right now and it is much more complicated than this solution. And chrome supports the download attribute anyway.

data:-URLs

IE does not support URLs longer than 2048 characters (actually bytes), so it is useless for data:-URLs.
Also it seems not to support window.open in combination with data:-URLs at all.

Note that encodeURIComponent produces UTF-8 encoded text. The mime type should contain the charset=UTF-8 parameter.
In case you don't want the data to be encoded as UTF-8 you could use escape(data) instead.

Internet Explorer before version 10 does not support any of the methods above.
If it is text data you could show it in an textarea and tell the user to copy it into a text file.

Ah nice! (Even though you can only save .txt and .html files this way.)I use this code in my "Greattune Player" (formerly known as Magnatune Player). This is not on github but on bitbucket (I like mercurial better than git so I use it if there is no good reason not to): https://bitbucket.org/panzi/greattune-player

I still don't understand what you want to do. What I wrote has nothing to do with hyperlinks or their visibility. Do you want to load a file from an url in JavaScript into a Blob? This is only possible from the same origin and is something completely different to what I described here anyway.

Sadly no. Only the download attribute and the saveAs method allow to define a file name, but currently only Chrome supports the download attribute and saveAs is currently only supported by IE 10. I think it is time for other browsers to catch up (Firefox and Opera).

But, for real-word use: do I see it right that you'd need to maintain as many local playlists as the number of different browsers -- permuted by host environments -- you use?

Now that web applications shift to the client side, and "client-only" apps shift to online, and thus browsers are more and more our default all-around platforms: is there any hope that the W3C finally recognizes the there is this entity there, the *local user* being in the center of all this, and not just a "visitor" any more, but really "The Client", and allow him/her to do real application work, rather than living in a crippled sandbox forever due to browser paranoia? :-/

"do I see it right that you'd need to maintain as many local playlists as the number of different browsers -- permuted by host environments -- you use?"

Because I store them in the browsers local storage, yes. But you can export the playlist to a file and import them in another browser. You can even drag and drop playlists between browsers (if both support HTML5 D'n'D).

But I wouldn't at all call it browser paranoia. If any webpage could just access the users file system this could have devastating consequences (wiping the users HD, scanning for bank/credit card details etc.).

Yes, there should be a way to do more, but in a secure manner. Mozilla is developing some such APIs for Firefox OS and they want to propose them as standard:https://developer.mozilla.org/en-US/docs/Web/Apps/Reference

However, these APIs might be limited in another way: They aim at mobile platforms (mainly phones), not the desktop.

If you use a link then the download attribute can be used to set the file name (if the browser supports it). Chrome supports this attribute and so does Firefox in general. Though I'm not sure if it works in Firefox with object URLs, because in Firefox it only works if the downloaded file is from the same origin than the page. I don't know if object URLs count as such.

You can't really "write a file". You can only provide a BLOB to the user who can then save that file. It's your browser that renames it to "info (1).txt" in order to prevent name conflicts. It's just exactly the same as with other downloads.

That's not possible. You can only tell the browser that there is data that the user might want to save and that "info.txt" is the *suggested* file name. What happens after that is up to the browser and/or user.