• Bug 2106 has been marked as a duplicate of this bug. ***

zigger wrote:

(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

avarab wrote:

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.

gangleri wrote:

(In reply to comment #4)
[[meta:Help:EasyTimeline_syntax]] (EasyTimeline syntax)

TheMuuj wrote:

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

shimmin wrote:

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.

ayg wrote:

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)

sy1234 wrote:

Just for reference, here's a link to the extension:
http://www.mediawiki.org/wiki/Extension:ImageMap

paul wrote:

There is a bug in the rendering of the coordinate codes. See Bug 9236 for details.

robchur wrote:

Resolving per comment 8.