Last modified: 2007-04-11 00:38:04 UTC
It would be very useful to be able to create image maps — images with specified areas associated with tooltips and links. Several kinds of images would benefit from imagemap functionality, including geographical maps (click on a country to read the article about that country); family trees (click on a person to read their biography); technical or anatomical diagrams (click on a part to read the article about it). It should be possible to create an imagemap that can be automatically resized in the same way as an ordinary image, with the active areas rescaling appropriately.
*** Bug 2106 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > *** Bug 2106 has been marked as a duplicate of this bug. *** From bug 2106: Currently, clicking on an image goes to the image's resource page, metadata page, index page (or whatever you want to call the page where the image is described, who uploaded it, etc.) There are some images where it would be useful to allow them to become clickable image maps. One example being where a map of the U.S. can be broken out into the individual states and allow someone to reference a particular state from that clickable image map in order to get more in-depth information on a subject. Another example would be to have say, the list of every county in a country be selectable starting from the country at large having individual states, then each state having the list of every city and county being clickable, then the link goes to that particular county. A lot of this has already been done in versions that are already public domain; the White House website has a state-clickable map for all 50 states and DC, so there is a source for that purpose, for example. Now, there is the issue of how to allow access to the original image metadata page. I think this would require an extra link be available (generated) after the image to allow both clicking on a page as a client-side map and as access to the underlying metadata describing the image and who created it. I have, in certain articles I have written/edited, realized that if the image in the map was a clickable client-side image map, it would have made the article much easier to work with, as I would not have had to include all the links for each item separately after the image. In generating the map, it may be that we want to have all of the points identified, and thus the means to describe the map would require identifying the points in order that an automatic table of links following (or preceding) the image be made for those that do not generate images or who cannot click on an image because of visual impairment, would still be able to use the linkages provided by the map as it would be usable for people with normal vision capability. As a side note, it may be that being able to create an image as a clickable client-side map should be something that requires an additional privelege or that requires one request it be enabled from someone who has the privelege to do so if it is felt that allowing anyone to make an image into a clickable client-side map could be something that would be abused or is seriously abusable in some cases. I think allowing the implementation of clickable client-side maps would improve Wikipedia and the related services (wiktionary etc.) as it would enhance the multimedia capability of what this project is supposed to provide, a truly rich content, web-based encyclopedia (and other services). In the interim, I would like to recommend that where client-side image map HTML syntax is written into a page that the system simply ignore it, rather than writing out the code back to the page, or give an indication that client-side maps are not (yet) supported; putting a client-side map into a page causes the client-side map code to render as text instead of being simply quietly included as non-functional html that is simply not sent to the user's browser. I therefore recommend the inclusion of capacity to provide client-side image map capability. The ability to add the client-side map coding can, if need be, made subject to having a privelege to do so if it is deemed necessary. Paul Robinson paul@paul-robinson.us
If we were to implement this it would have to use a syntax where you could specify the map independently of the image's size, since it's unacceptable to have to manually make a new map each time the image gets resized, whether that happens manually or automatically.
If I'm not mistaken, the EasyTimeline extension already uses image maps. Perhaps we could base this image map support on the [[m:Help:EasyTimeline syntax|EasyTimeline syntax]]. It's not the cleanest stuff ever, but at least it'd be consistent with some of the syntax already found at Wikipedia, for example.
(In reply to comment #4) [[meta:Help:EasyTimeline_syntax]] (EasyTimeline syntax)
I'm not sure how complicated this would be to write, but I'm going to suggest it anyway as it would be a fantastic feature. Since MediaWiki is already able to render SVG to PNG, wouldn't it be great if links defined in the SVG could also be rendered to an image map? So, rather than having to upload an image (using the discussed example) of the United States and define points for click-able regions, the map could be defined in SVG, and each state could have an element inside a hyperlink. For example: <svg:a xlink:href="/wiki/Texas"><svg:path id="Texas" .../></svg:a> <svg:a xlink:href="/wiki/Oklahoma"><svg:path id="Oklahoma .../></svg:a> This would generate an <area> HTML element for each hyperlink based on the path data. Actually, the more I think about this I realize it probably has a lot of issues that would need to be worked out, such as how do internal links in the SVG, and whether defining links inside SVG is even appropriate for a Wiki. Still, I wanted to put the thought out there so it wouldn't be lost. Maybe SVG will become supported widely enough that we won't need image maps anymore.
Imagemap support would be amazing. +1.
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ImageMap/
*** Bug 8432 has been marked as a duplicate of this bug. ***
To make obvious what previous commenters probably knew and implied, but could bear being made more plain: The SVG vector graphics format inherently includes this ability. SVG images can behave interactively, responding in various ways to user inputs. One supported behavior is for a region of an image to be a hyperlink. Presently, the wiki software does not serve SVGs natively, but instead converts them to appropriately sized PNGs, and serves that. Reasons include lack of browser support for SVGs, and fear that SVGs might do evil things to unsuspecting users, because they can contain scripts that could do malicious things if executed at an inappopriate trust level. SVG browser support has advanced markedly since these decisions were made, and SVGs can be sanitized by removing <script> elements from them, as is described here: http://en.wikipedia.org/wiki/User:Aarchiba/SVG_sanitizer. This bug request could be completely fixed by reconsidering the appropriateness of native SVG support for wikipedia.
At present, no version of Internet Explorer (80% of viewers?) natively supports SVG rendering, and rendering in other browsers is inconsistent. Scripts are the least of the reasons we don't enable direct SVG rendering, and probably won't for another couple of years at least. See also bug 3593. Do we want this in core? If we're fine with an extension, this is FIXED.
IMHO the extension's rather low-level and awkward. It works, but it's ugly, and as with too many of our fancy syntaxes and extensions it drops this big blob of incomprehensible _stuff_ directly into the text of the article using it, cluttering up the editor's view. What would be slicker would be if we can rig up a visual editor for the thingy; compare with adding notations to images on flickr. That might end up spitting back the same extension code, or we might integrate it more directly into the image page, or something else. (cf the long-ago talk of having a separate namespace for tables... man I wish we'd done that instead of what we did, it would make a lot of thing simpler)
Just for reference, here's a link to the extension: http://www.mediawiki.org/wiki/Extension:ImageMap
There is a bug in the rendering of the coordinate codes. See Bug 9236 for details.
Resolving per comment 8.
