Hi all,
we have just deployed a new URL format for MediaViewer [0], I am submitting
it here for comments and for the benefit of people who have to do something
similar in other contexts.
MediaViewer stores the name of the image in the hash part of the URL so one
can share links to a page with a specific image open in the lightbox. (We
considered using the History API [1] to change the path or the query part,
but that degrades poorly.) I have looked at three options:
1. Just put the file name as-is (with spaces replaced by underscores) in
the URL fragment part.
Pro: readable file names in URLs, easy to generate.
Con: technically not a valid URI. [2] (It would be a valid IRI,
probably, but browser support for that is not so great, so non-ASCII bytes
might get encoded in unexpected ways.) Creates nasty usability and security
issues (injection vulnerabilities, RTL characters, characters which break
autolinking). Would make it very hard to introduce more complex URL formats
later, as file names can contain pretty much any character.
2. Use percent encoding (with underscores for spaces).
Pro: this is the standard way of encoding fragments. [2][3] Always
results in a valid URI. Readable file names in Firefox. Easy to generate
on-wiki (e.g. with {{urlencode}})
Con: Non-Latin filenames look horrible in any browser that's not Firefox.
3. Use MediaWiki anchor encoding (like percent encoding, but use a dot
instead of a percent sign).
This would have the advantage that links can be generated in
wikitext very conveniently, using the [[#...]] syntax. Unfortunately the
way MediaWiki does percent encoding is intrinsically broken (the dot itself
does not get encoded, but it does get decoded when followed by suitable
characters, so file names cannot get roundtripped safely), so this is not
an option.
We went with option 2, so URLs look like this:
https://www.mediawiki.org/wiki/Lightbox_demo#mediaviewer/File:Swallow_flyin…
https://www.mediawiki.org/wiki/Lightbox_demo#mediaviewer/File:%E0%AE%85%E0%…
One issue that we ran into is that window.location.hash behaves weirdly
with percent-encoded hashes in Firefox [4], but that's easy to avoid once
you know about it. Other than that, it seems to work reliably.
[0]
https://www.mediawiki.org/wiki/Multimedia/Media_Viewer
[1]
http://diveintohtml5.info/history.html
[2]
http://tools.ietf.org/html/rfc3986#section-3.5
[3]
https://tools.ietf.org/html/rfc3987#section-3.1
[4]
https://bugzilla.mozilla.org/show_bug.cgi?id=483304
