Last modified: 2007-04-11 00:38:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3227, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1227 - Image map support
Image map support
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.w3.org/TR/html4/struct/obj...
:
: 2106 8432 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-29 17:14 UTC by Gdr
Modified: 2007-04-11 00:38 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gdr 2004-12-29 17:14:11 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.
Comment 1 Brion Vibber 2005-05-08 08:20:31 UTC
*** Bug 2106 has been marked as a duplicate of this bug. ***
Comment 2 Zigger 2005-05-08 09:32:42 UTC
(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
Comment 3 Ævar Arnfjörð Bjarmason 2005-12-26 04:52:55 UTC
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.
Comment 4 Minh Nguyễn 2005-12-31 07:27:19 UTC
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.
Comment 5 lɛʁi לערי ריינהארט 2006-02-18 23:13:28 UTC
(In reply to comment #4)
[[meta:Help:EasyTimeline_syntax]] (EasyTimeline syntax)

Comment 6 Matthew W. Jackson 2006-08-29 22:28:40 UTC
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.
Comment 7 SJ 2006-10-27 00:23:31 UTC
Imagemap support would be amazing.  +1.
Comment 9 Brion Vibber 2006-12-29 22:14:17 UTC
*** Bug 8432 has been marked as a duplicate of this bug. ***
Comment 10 Robert Shimmin 2007-01-02 15:58:30 UTC
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.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-02 17:27:32 UTC
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.
Comment 12 Brion Vibber 2007-01-02 18:53:52 UTC
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)
Comment 13 Sy Ali 2007-01-17 22:45:18 UTC
Just for reference, here's a link to the extension:
http://www.mediawiki.org/wiki/Extension:ImageMap
Comment 14 Paul Robinson 2007-03-09 10:17:54 UTC
There is a bug in the rendering of the coordinate codes.  See Bug 9236 for details.
Comment 15 Rob Church 2007-04-11 00:38:04 UTC
Resolving per comment 8.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links