From Wikipedia, the free encyclopedia

Template:Click is permanently protected from editing, as it is a heavily used or visible template. Substantial changes should be proposed here, and made by administrators if the proposal is uncontroversial, or has been discussed and is supported by consensus. Use {{editprotected}} to attract the attention of an administrator in such cases. Any contributor may edit the template's documentation to add usage notes, categories or interwiki links.

This template page was nominated for deletion on 10 March 2006. The result of the discussion was no consensus. An archived record of this discussion can be found here.

This template was considered for deletion on 17 December 2006 . The result of the discussion was no consensus.

Contents 1 Documentation 1.1 Syntax 1.2 Examples 1.3 Unlinked image 2 Discussion 2.1 Wont work 2.2 A simpler template for Mediawiki sites that support embedding external images 2.3 Can this be used on the same line as text? 2.4 Confusing 2.5 One hundred–pixel restriction 2.5.1 Fix for images with more than 100px 2.6 Titles 2.7 Parameters 2.8 Nominated for deletion 2.9 A less evil way of achieving the same thing? 2.10 This does work in Safari 2.11 Eu InterWiki 2.12 Better Version 2.13 Underlining 2.14 Add to category 2.15 Erm... copyright violation central 2.16 This does not work any more 2.17 Nominated for deletion 2.18 Edit request 2.19 Replacement 2.20 Get the story straight 2.21 Replace 2.22 Template:Click 2.23 external links 2.24 ar:قالب:نقر 2.25 Depreciated 2.26 Replacement template 2.27 The downfall reimplementation of {{click}} 2.27.1 Looks like this should work 2.28 Impact of your changes 2.29 Code changes 2.30 Code change part two 2.31 Problem with new line

[edit] Documentation

This template causes an image to link to a specified page when clicked, rather than its image description page. It should be used sparingly as image description pages contain copyright information and should normally be easily accessible. There is also an alternative Version of this Template, Click-Inline. It does practically the same as Click, but without generating a new paragraph (newline). For more information see Discussion on Click-Inline.

[edit] Syntax

{{Click |
| image = <location of image>
| link = <page to link to>
| width = <width of image> (not more than 100)
| height = <height of image> (not more than 100)
}}

[edit] Examples

{{Click |
| image = Nuvola apps package network.png
| link = :Category:Geography
| width = 40
| height = 40
}}

{{Click |
| image = Wikinews-logo-textless.png
| link = n:Main Page
| width = 35
| height = 19
}}

[edit] Unlinked image

This template can also be used to produce images that are not clickable, by using as the link parameter:

link = {{FULLPAGENAME}}

The cursor can also be changed to appear normal when over the image by using styles

<div style="cursor:default;">
{{Click |
| image = Nuvola mimetypes info.png 
| Link = {{FULLPAGENAME}}
| width = 30px 
| height = 30px
}}
</div>

See also: Wikipedia:Images

[edit] Discussion

[edit] Wont work

I can click that pic, and my cursor turns into a hand. (i'm using mozilla firefox 1.5x on a windows xp)--85.164.186.121 13:25, 16 May 2006 (UTC)

You're right. I can click the image which is supposed to be "unclickable", and the other examples go to the normal image page rather than the page they were supposed to go to. This template is broken on Firefox 1.5. --Tim1988 ^talk 09:23, 15 June 2006 (UTC)

I think the <pre> </pre> tags break the template. The images here didn't work correctly for me at first, but when I moved them so they came before the first <pre>, they worked. -- kenb215 01:47, 26 July 2006 (UTC)

This error can be fixed by upgrading to Mozilla Firefox 2.x (which is very easy and free), therefore it is not priority.  Tcrow777  talk  02:40, 1 August 2007 (UTC)

[edit] A simpler template for Mediawiki sites that support embedding external images

See m:Template:Clickpic. This will not work with main Wikimedia projects (i.e. Wikipedia and Meta) buts works very well on sites that support embedding external images - i.e. most personal, public websites and corporate intranet sites that use Mediawiki.

[edit] Can this be used on the same line as text?

Can the image in this template appear on the same line as text? Take a look at the album link in the right box for Stairway to Heaven to see what I mean. --Oldak Quill 17:43, 20 December 2005 (UTC)

I don't know. I assumed it would work but ran into a similar problem when trying to add it to Wikipedia:Browse. Perhaps it could be done using tables? the wub "?!" 18:08, 20 December 2005 (UTC)

Since the template uses div tags, which are block elements in HTML, it won't work inline with text, but you use a table to force it onto the same line as text. – Minh Nguyễn (talk, contribs) 05:26, 21 December 2005 (UTC)

Use Template:Click-Inline --PSIplus Ψ 00:04, 23 June 2006 (UTC)

[edit] Confusing

I believe this template to be inherently confusing to some editors and especially many readers. If people click on a small image, they expect to see it enlarged, and/or to see info on it. Could anybody please give good reasons for the existence of this, considering that this talk page already basically tells us not to use it? Radiant_>|< 03:33, 24 December 2005 (UTC)

I agree. Images work the way they do by design. As Radiant says, there is an expectation that when you click any image on WP, you go to the image page. If the developers or community wanted them to have optional alternate targets, they would already be part of the [[Image:]] tag. The problem is that these Click templates are already being used for very casual uses. Any proliferation could be quite unbearable over time. The creators should instead pursue filing a MediaWiki feature request, rather than implementing this. Please remove all instances of them from any active use. -- Netoholic @ 04:44, 24 December 2005 (UTC)

Actually I would argue it is the current system that is inherently confusing. For every other website, if you click on an image on the main page, you go to the article it is associated with. Thousands of people per day click on the image for the featured article expecting to go to the article, when in fact they simply get to a highly technical image description page. Editors such as ourselves know where to click, but I doubt most readers do. - SimonP 14:22, 24 December 2005 (UTC)

Agree with SimonP. The intention is for this to be used in a very limited number of cases. The main place I created it for was the sister projects box on the Main Page, to let the images link directly to the sister projects. People who are new to Wikipedia will not be expecting details on the picture at all, and I feel we should be making Wikipedia as easy to use as possible for new users. I believe this has already been submitted as a feature request, but there seems to be little point wasting the developers time on it when this is an adequate solution. the wub "?!" 15:00, 25 December 2005 (UTC)

• While I see Simon's point, wouldn't it be better to talk to the devs about this one? Radiant_>|< 10:42, 26 December 2005 (UTC)

Also agree with SimonP. There are a few cases where the typical WP action of going to the image info isn't what's needed. As for talking to the devs, there's already a feature request in bugzilla asking for this; once it gets implemented (assuming it meets the needs addressed by this template) I'm sure we can move over to that. I'd like to think this template (and others like it) are temporary. —Locke Cole 13:12, 26 December 2005 (UTC)

For reference, Locke is referring to Bug 539. This template is indeed only temporary; the Dutch Wikipedia only created this CSS-based hack because they wanted a large number of icon-style images on their front page, all linking to portals or entries, rather than the image description pages. – Minh Nguyễn (talk, contribs) 22:56, 26 December 2005 (UTC)

Yes, that's the one. 12 votes so far– anyone even remotely interested in this might consider signing up and voting for this. —Locke Cole 02:25, 27 December 2005 (UTC)

I agree with Netoholic, this is confusing and shouldn't be used. It also seems to fail completely in Safari. SimonP complains that the status quo is contrary and confusing, but it is at least consistent. Adding this template breaks the consistency, making things more confusing. Then it gets worse: because this template fails in some browsers, it makes its effect unpredictable, so editors don't know what other readers will see—there isn't even a warning here, so it's going to fail unexpectadly for most editors. Still worse, the way images work reflects design and policy, and using this template is a way to sneak around Wikipedia's normal restrictions without any votes.

Finally, this is a CSS-based hack, and not an actual linked image, which breaks a priority-one WAI accessibility checkpoint[1] by making the site work differently for users with visual browsers than for users of text-only and screen readers. It creates a link before the image whose text is just three white-space characters. It will likely not appear in most HTML-only browsers, but its effect in all browsers is impossible to predict. —Michael Z. 2006-02-12 01:00 Z

Ah, I see this template is on the main page. Nice: completely breaking A, AA, and AAA accessibility on the front page of a "free" and "open" encyclopedia. —Michael Z. 2006-02-12 01:09 Z

In Lynx this renders fine, for what it's worth. I'd be interested to hear how it renders in screen readers though (with the understanding that we can't possibly test every software, but getting a general idea would help). Please don't knee-jerk, BTW; unlike WP:AUM, the people here are a lot more thoughtful and generally care about accessibility. —Locke Cole • t • c 02:53, 12 February 2006 (UTC)

Not true. Surprisingly, the links render as intended in Lynx, but the "unlinked image" breaks in different ways in both Lynx and Safari. In Safari the example above doesn't show the link cursor, shows a bogus tooltip indicating a link to Template talk:Click, but actually links to Image:Nuvola mimetypes info.png. In Lynx, it just links to Template_talk:Click, with the underscore. This template breaks in different, unexpected ways in different browsers. Editors are being told to expect one thing, but something elso shows up for substantial numbers of readers, probably including users of assistive technology. Broken, broken, broken.

This is what happens when we try to subvert the standards. The general principle behind this hack is to use CSS to change the apparent content of HTML, rather than go through the proper channels to make WikiMedia generate the desired HTML. The underlying concept is flawed, and contrary to the word and spirit of the the HTML and CSS standards and the WAI accessibility guidelines and technical recommendations. The underlying concept breaks A, AA, and AAA accessibility.

Yes, there is an understanding that we can't test in every software. That's why we shouldn't ignore standards this way. If we care so much about accessibility, let's remove and delete this template now, and start a campaign to add linked images to WikiMedia. —Michael Z. 2006-02-12 18:10 Z

I don't think it is too bad. Very Many userpages use it, though they put subt and you can't conut them with "What links here". but probably more users will like it. —Argentino (talk/cont.) 21:29, 28 May 2006 (UTC)

[edit] One hundred–pixel restriction

We can lift that 100px restriction on the height or width of an image by changing font-size: 100px; to font-size: {{{height}}}; and line-height: 100px; to line-height: {{{height}}};. I've tested this at the Vietnamese Wikipedia, and it seems to be working just fine. – Minh Nguyễn (talk, contribs) 22:49, 26 December 2005 (UTC)

Nice! Hopefully someone with admin access will modify the template to include this change. —Locke Cole 02:23, 27 December 2005 (UTC)

There is in fact an issue that I'm having a hard time figuring out: the specified link doesn't extend all the way to the right edge of the image, leaving the description page link exposed. I've worked around the problem at vi: with font-size: 1{{{height}}}; and line-height: 100px; to line-height: 1{{{height}}}; (note the extra digit). I'm not sure, however, if this'll cause any serious issues with browsers, since I know that Mozilla on Linux used to crash with very large font sizes. – Minh Nguyễn (talk, contribs) 06:37, 27 December 2005 (UTC)

The width is controlled by two factors: 1) the font size, 2) the characters used. The link is made with the following– [[link|...]], so if for some reason the three periods don't take up all the space, it's possible clicking on the right side of the image to still take you to the image info. You could try working around this by adding more periods (maybe [[link|........]]), or maybe using another character? Perhaps underscores ([[link|________]])? There might be side effects from doing that thought, so be careful. =) —Locke Cole 07:17, 27 December 2005 (UTC)

Actually, the Dutch template originally used underscores, but later changed it to non-breaking spaces (which are invisible to the user) by the time I adapted it for the Vietnamese Wikipedia. I'm not sure exactly why the wub ended up using periods, though. – Minh Nguyễn (talk, contribs) 05:31, 28 December 2005 (UTC)

For some reason I couldn't get the non-breaking spaces to form a link on the English Wikipedia at first so used periods instead. I thought it must have been a difference between the language configurations. But I just went back and tried nbsp again and it worked fine, so it was probably just me making a stupid mistake. the wub "?!" 22:39, 31 December 2005 (UTC)

[edit] Fix for images with more than 100px

This works pretty good with all (major) browsers on de.wikt:

<div style="position: relative; overflow: hidden; width: {{{width}}}; height: {{{height}}}; z-index: 2;">[[Image:{{{image}}}|{{{width}}}]]<div class="nodeco" style="position: absolute; top: 0px; left: 0px; z-index: 3;">[[{{{link}}}|<span style="float: left; width: {{{width}}}; height: {{{height}}}; font-size: {{{height}}}; line-height: {{{height}}}; word-spacing: {{{width}}}; cursor: pointer;">   </span>]]</div></div>

Add to MediaWiki:Common.css:

.nodeco a:hover {text-decoration: none !important}

Best regards, Melancholie 11:41, 31 December 2005 (UTC)

[edit] Titles

Could the titles (that is, the popup hints) that appear over the image be specified in the template somehow? Lupin|talk|popups 14:09, 26 January 2006 (UTC)

Answer: yes. {{titled-click}} Lupin|talk|popups 04:13, 2 February 2006 (UTC)

[edit] Parameters

How is it possible to pass the normal image parameters like 'thumb', align, etc. ?

Poupoune5 19:26, 9 March 2006 (UTC)

[edit] Nominated for deletion

This template was nominated for deletion on 10 March, 2006. The result was no consensus. The archive of the discussion can be found here. Zzyzx11 (Talk) 00:13, 18 March 2006 (UTC)

[edit] A less evil way of achieving the same thing?

Clone the image (foo.png is copied to, say, link-foo.png), and make Image:link-foo.png into a redirect page. Shimmin 12:04, 8 April 2006 (UTC)

If that works, it's a much better idea. Include some info in the redirect image page to indicate the original image? — Omegatron 15:25, 8 April 2006 (UTC)

We used to do that here, but the main problem was that the linked image would actually show up at the top of the destination page (if it was a page at the English Wikipedia). I don't know if that's still an issue. The problem now is that redirects across wikis no longer work. For example, if you were to redirect an image with the code #redirect [[wikt:Main Page]], you'd get end up at the redirect page. But I suppose that wouldn't be as confusing as seeing the image description page, so it might be a good compromise for the sister project links at least. – Minh Nguyễn (talk, contribs) 03:52, 22 May 2006 (UTC)

[edit] This does work in Safari

I noticed the comment on the template page says this does not work in Safari. I am currently using Safari 2.0.3 and it works fine. Could someone change the message? I'll see if I can find some other Mac users and determine what version of Safarai works on it and what doesn't, so maybe it could say it works on Safari X.0 and later or something. -- Ned Scott 03:40, 5 May 2006 (UTC)

Ok, this is odd, the examples on this talk page do not work, but the ones found at User:Nightstallion/linkage work perfectly. -- Ned Scott 03:42, 5 May 2006 (UTC)

Yay, I'm an example. ;) —Nightstallion (?) ^{Seen this already?} 23:32, 5 May 2006 (UTC)

The functionality of the template breaks inconsistently. Another reason to avoid using this. —Michael Z. 2006-05-22 04:26 Z

Using Firefox 1.5.0.4 (need to upgrade!) on Windows and getting a continuously running script when I click on an image. Let's not use templates that require readers to upgrade their browsers, please. - BT 21:15, 7 June 2006 (UTC)

[edit] Eu InterWiki

Please, add the next interwiki if it is possible: eu:Txantiloi:Lotura iruditik. Thanks.--Berria · (talk) 22:01, 12 July 2006 (UTC)

Done.--Commander Keane 08:20, 16 July 2006 (UTC)

[edit] Better Version

<div style="position:relative; width:{{{width}}}; height:{{{height}}}; overflow:hidden;"><div style="position:absolute; font-size:{{{height}}}; overflow:hidden; line-height:{{{height}}}; letter-spacing:{{{width}}};">[[{{{link}}}|<span title="{{{title|{{{link}}}}}}" style="text-decoration:none;">&nbsp; &nbsp;</span>]]</div>[[Image:{{{image}}}|{{{width}}}|{{{title|{{{link}}}}}}]]</div>

As demonstrated at m:Template:Click.--65.141.141.145 23:49, 14 July 2006 (UTC)

The one at meta works, however, there is something wrong with this version. --DavidHOzAu 06:46, 22 July 2006 (UTC)

Yes, that's why I called this one a "Better Version". I'm not a wikipedian, but I noticed this one is constricted to 100px x 100 px images and its invisible overlay gets underlined in some cases. I cleaned it up some of the css and fixed the aforementioned issues.
Edit: You'll also notice you can title it, obsoleting {{Titled-click}}.--65.147.170.213 21:20, 3 August 2006 (UTC)

It also works in Safari—at least the example on the template page does. –Ian Spackman 21:56, 14 August 2006 (UTC)

Applied. Thanks for the suggestion, and sorry about the long wait. JesseW, the juggling janitor 21:49, 31 August 2006 (UTC)

[edit] Underlining

All images using this template seem to be underlined like normal links, despite the text-decoration: none; -- is this a problem with my own settings? Is there a way to fix this problem? — Dan | talk 05:45, 2 September 2006 (UTC)

See #Fix for images with more than 100px! --84.156.96.213 20:26, 25 October 2006 (UTC)

[edit] Add to category

Could Template:Click be added to Category:Wikipedia workaround templates? It seems to be a textbook example of one.-- kenb215 04:39, 14 September 2006 (UTC)

[edit] Erm... copyright violation central

So, the "issue" that this template "works around" is that images in Mediawiki automatically link to the image description page? Well, except for public domain images and those out of copyright that is a legal requirement. (And, yes, that includes GFDL, a licence under which authors are entitled to receive credit for their work). Of course, everyone using this template is only linking to PD images or otherwise attributes the image, right? --kingboyk 17:25, 12 October 2006 (UTC)

Probably the main use for this template is to make neat clickable icons on userpages for quick links. It souldn't be too big an issue I'd imagine, or there'd be 'regulations' on use (Eek, instruction creep). Certainly most images used in website interfaces don't link to the image (the Wikipedia logo for instance, which links to the main page). Doesn't seem to me like a big issue however, or the template wouldn't exist. Probably not worth fretting about :D Michael Billington (talk • contribs) 11:52, 18 October 2006 (UTC)

[edit] This does not work any more

This does not work on an English Wikipedia page as of December 2006. I have attempted to use this template to links from images at User:PockBot and it does not work - PocklingtonDan 18:59, 4 December 2006 (UTC)

[edit] Nominated for deletion

Yeah, I'm nominating this for deletion. -Amarkov ^blah_edits 01:35, 17 December 2006 (UTC)

This second deletion request was closed as no consensus here. --CBD 23:20, 31 December 2006 (UTC)

It was? — Omegatron 16:21, 1 January 2007 (UTC)

Hrrm? Yes. See the link in my prior note above. --CBD 19:06, 1 January 2007 (UTC)

[edit] Edit request

1. It works in Safari.
2. The statement that the template itself breaks accessability criteria is disputed. The arguments should be moved to this talk page with only neutral information on the template page itself.

--GunnarRene 06:26, 15 January 2007 (UTC)

It does not work in all browsers. Thus, it breaks the accessability criterion of working in all browsers. -Amarkov ^blah_edits 06:27, 15 January 2007 (UTC)

We're not going to remove all images, css and javascript though, right? Because lynx doesn't show them? The point here is that essential functionality should not depend on CSS, but it can be used to enhance text links with an image that you can actually click on and get the expected response.--GunnarRene 07:04, 15 January 2007 (UTC)

See also Template:Reflist. You might want to include that one in future deletion discussions. It only works in certain Mozilla versions. --GunnarRene 07:07, 15 January 2007 (UTC)

It doesn't work in all browsers and it breaks accessibility. Neither of those two things is disputed. — Omegatron 14:58, 15 January 2007 (UTC)

It doesn't work in Firefox now, either, at least in the examples used above.—Ryūlóng (竜龍) 21:46, 15 January 2007 (UTC)

The existence of this discussion makes the second point ipso facto disputed. The related project page also has a dispute tag slapped on it. Not by me. --GunnarRene 05:45, 16 January 2007 (UTC)

 ??? How can you dispute that it breaks accessibility? — Omegatron 15:01, 16 January 2007 (UTC)

Easily, if it's used correctly or if it enforces correct use by its code, then it doesn't break stuff. Believe me, I've been browsing the web with non-CSS 1990s vintage computers, so I know how frustrating it would have been to deal with incorrect use. But now: Imagemap. Yay. (?) :-) --GunnarRene 00:52, 18 January 2007 (UTC)

[edit] Replacement

A potential replacement for this template has been coded into the MediaWiki software. This feature can duplicate the existing functionality of 'Click', always includes a separate clickable icon for the image description page, and even allows different portions of a single image to link to different pages. See ImageMap for details. Hopefully transitioning to this new methodology can be performed carefully and with a minimum of insanity. --CBD 15:03, 17 January 2007 (UTC)

Thankyou to Tim Starling for the new extension. As the person who created this template on the English Wikipedia, or more precisely copied it from other language editions, I fully support changing to the new software based method as quickly and smoothly as possible. This template was only ever intended as a stop-gap solution, mainly for the clickable logos on the Main Page (which have already been changed). As people have pointed out it has a number of problems, and its use has extended far beyond what I originally envisioned. I am keen to help with the transition, and also to explore the new opportunities this extension opens up. the wub "?!" 16:39, 17 January 2007 (UTC)

I am glad that something proper has been implemented. The first attempt at replacing this with the imagemap tag didn't work on any of the pages I viewed, though. — Omegatron 17:25, 17 January 2007 (UTC)

Yes, the 'imagemap' syntax apparently doesn't play well with template parameters... which means that every call to this click template will have to be replaced with the corresponding 'imagemap' logic. --CBD 17:30, 17 January 2007 (UTC)

If that is true, we should immediately introduce a unique template comment in the code for both this and other templates so that we can track it if it's subst'ed. Right? --GunnarRene 00:55, 18 January 2007 (UTC)

After further review I'm afraid 'imagemap' just isn't ready for primetime yet. The fact that it cannot accept parameters or magic words (e.g. {{PAGENAME}} breaks it) means that it can't be used in place of 'click' logic in Template:Portal and the like. The clickable images on the Main Page have been updated to use imagemap and there are other places where it could be implemented, but replacing the thousands of pages currently passing parameters to 'clickable templates' with hard-coded imagemaps just isn't feasible (and would quickly result in chaos as imagemaps for the same location got set to different images/sizes/et cetera on different pages). Hopefully 'imagemap' will be updated to be able to handle parameters and can then be used to phase out other forms of clickable images entirely. --CBD 14:51, 20 January 2007 (UTC)

[edit] Get the story straight

Either the "Use the imagemap feature instead" language should come out; or this template should be tagged with {{Historical}} or TfD'd. — SMcCandlish [talk] [contrib] ツ 17:49, 29 January 2007 (UTC)

{{tdeprecated}} would be a better tag. Polonium 17:01, 31 January 2007 (UTC)

I disagree. The text should absolutely tell people to use ImageMap instead of this. ImageMap can't do everything 'Click' can, but that's not a reason to continue using Click for the things ImageMap can do. --CBD 22:41, 31 January 2007 (UTC)

[edit] Replace

This template should be replaced as fast as possible (once the bug in ImageMap gets fixed, in all places). This CSS hack doesn't work for me in firefox (all the example links point to the image page). Polonium 17:58, 31 January 2007 (UTC)

{{Click-Inline}} works in firefox, but {{click}} doesn't. Polonium 18:01, 31 January 2007 (UTC)

Odd. I've been using 'click' in Firefox just fine for over a year. --CBD 22:37, 31 January 2007 (UTC)

My mistake. {{click}} works, but was not present in the above examples until recently (see below), this was why I thought it didn't work. Polonium 20:44, 20 April 2007 (UTC)

[edit] Template:Click

This should be added to the image. --Indolences 21:36, 7 March 2007 (UTC)

Edit: haha wrong talk page. -Indolences 21:44, 7 March 2007 (UTC)

[edit] external links

{{Click | | image = Nuvola mimetypes info.png | link = http://tools.wikimedia.de/~interiot/cgi-bin/Tool1/wannabe_kate | width = 100 | height = 100}} turns into

Are the black brackets only in my mind? This only happens when using external links. The link is still there (around the bottom of the brackets), but it doesn't span the entire image. Am I messing up the syntax or is template broken? I tried to user click because the imagemap external link function seems to be disabled on en.WP. Or is there another workaround to link external links (edit count etc) to images? —AldeBaer 00:46, 6 June 2007 (UTC)

It would appear the link is placed within [[ ]]. External links go not within [[ ]] but [ ], so the extra [ and ] are rendered in the page text. 81.104.175.145 10:59, 7 June 2007 (UTC)

As you can see in the code I included above, I didn't use brackets at all. —AldeBaer 21:40, 7 June 2007 (UTC)

Nevermind, found a workaround simply by taking and adjusting the template code:

<div style="position:relative; width:100px; height:100px; overflow:hidden;"><div style="position:absolute; font-size:100px; overflow:hidden; line-height:100px; letter-spacing:100px;">[http://tools.wikimedia.de/~interiot/cgi-bin/Tool1/wannabe_kate <span title="edit count" style="text-decoration:none;">   </span>]]</div>[[Image:Nuvola mimetypes info.png|100px|edit count]]</div> returns as:

   ]

—AldeBaer 22:32, 7 June 2007 (UTC)

Actually this would work better:

<div style="position:relative; width:100px; height:100px; overflow:hidden;"><div style="position:absolute; font-size:100px; overflow:hidden; line-height:100px; letter-spacing:100px;"><span class="plainlinks">[http://tools.wikimedia.de/~interiot/cgi-bin/Tool1/wannabe_kate <span title="edit count" style="text-decoration:none;">&nbsp; &nbsp;</span>]</span></div>[[Image:Nuvola mimetypes info.png|100px|edit count]]

   

—  Tcrow777  talk  03:48, 14 August 2007 (UTC)

[edit] ar:قالب:نقر

{{editprotected}} Please add ar interwiki [[ar:قالب:نقر]].--OsamaK 11:06, 8 July 2007 (UTC)

Y Done and I have moved the documentation to Template:Click/doc. mattbr 14:43, 8 July 2007 (UTC)

[edit] Depreciated

{{editprotected}}

This template is currently listed as depreciated, but there is no valid replacement as ImageMap still doesn't allow for magic words or template parameters. Unless there is an actual replacement, and not a partial replacement, this shouldn't be listed as depreciated. Justin ^chat 01:48, 13 October 2007 (UTC)

N Not done There is no exact replacement (just like there isn't an exact replacement for {{User:One/Title}}). That doesn't mean that this template should be used, though. --ais523 14:52, 13 October 2007 (UTC)

{{User:One/Title}} isn't listed as depreciated, nor is it used anywhere besides the talk namespace. {{Click}} is used throughout the Portal namespace. If it "shouldn't be used",d delete it. It's nonsense to list something as depreciated, when there is no replacement, and refuse to remove the depreciated listing because it shouldn't be used. No matter how many times you use it, circular logic doesn't make sense. Justin ^chat 18:46, 13 October 2007 (UTC)

There is a replacement; I looked at some Portal uses, and they all could have been replaced by <imagemap>, just that nobody got round to it yet. Do you know of any uses of this template elsewhere which actually require this workaround that has accessibility problems, and where <imagemap> couldn't be used instead? And {{User:One/Title}} was used on articles in the past (although hopefully it never became widespread), and was userfied in the TfD as a method of preventing people using it on articles (which is deprecation, more or less), even though it had no equivalent. --ais523 15:31, 16 October 2007 (UTC)

There is an obvious difference between 'this template is deprecated' and 'we would like this template to be deprecated'. In this case, the latter applies but the former quite clearly does not. It can't simultaneously be both 'protected due to high use on thousands of pages' and 'deprecated'... that's just an inherent contradiction. At present, ImageMap cannot replace all uses of this template. If you disagree then I'd suggest going through this list of templates which call 'Click' and start replacing the logic. You'll quickly find that ImageMap just doesn't have the flexibility needed to do so. If it did then this template could be deprecated, but we shouldn't be marking it as such until that happens. --CBD 11:12, 23 October 2007 (UTC)

Exactly. And as a result, several portals are listed as using a depreciated template. It's kind of absurd really. Seems to me there's a few vocal opponents to using click, since it's a bit of hack, so instead of developing a replacement (or improving ImageMap), they simply mark a widely used template as depreciated. Until there is a fully functional replacement for Click, this shouldn't be listed as depreciated (much like click-inline, which is effectively the same exact thing, but isn't listed as depreciated). Justin ^chat 15:34, 23 October 2007 (UTC)

There is also an obvious difference between "there is no problem with this template" and "we don't want to acknowledge that there is a problem with this template". I removed click on several widely used WikiProject talk page tags, as well as one usage in a popular article template, where it had apparently been added as a bit of a test. The WikiProject tags, mainly science-related, such as Template:Fishproject, were promptly replaced by imagemap (without an attribution link to the image page, but I figured I'd annoyed enough people getting rid of the template that I didn't need to be pointing out that they were ignoring the GFDL as well). The removal from Template:Wide image was actually suggested by another user after I pointed out the accessibility issues with Click. I had made a similar point on Template talk:Video and another user decided that the template didn't really need to use Click and removed it himself.

The majority of remaining uses appear to be appearances of Template:Station bullet and admins who want a pretty image in the upper right corner of their page to link to a description of their adminness, as well some miscellaneous usages. I would say that the number of usages has thus dropped by at least several thousand in the past month and would question if all of the remaining usages are entirely necessary, in the sense of being worth the tradeoff with accessibility. I originally thought both Template:Wide image and Template:Video, both popular templates that used Click for specific purposes, were cases where Click had to be used. The fact that a note pointing out the concerns at Wikipedia:WikiProject Usability/Clickable images was enough for editors to decide they didn't need these two usages suggests that the number of absolutely essential usages, where users cannot replace with imagemap and feel that the effect of click is worth the accessibility problems, is very very small. Anyone up for Category:Pages using Click?

If link-wrapping of images was considered desirable by the WMF and devs, it would be trivial. The fact that it is not makes attempts to characterize minimizing the unthinking propagation of this template across the wiki as the efforts of grouchy busybodies who want to mess up pretty layouts ring rather hollow. I like pretty layouts. - BanyanTree 03:20, 29 October 2007 (UTC)

I agree, there is a big difference. However, I don't consider ignoring a problem fixing it. The fact that the devs haven't fixed the problem doesn't resolve it, and simply because some don't find it desirable, doesn't mean the majority do. If those posturing against this template really want to see it end, perhaps instead of inappropriately using the depreciated tag, they could improve the ImageMap template to allow template logic. You mention such enhancements would be "trivial", although I assume you mean the MediaWiki code base.

Regardless, I don't like it isn't good enough. Category:Pages using Click is, IMHO, a useless categorization unless it's used for the eventual replacement of click with a true replacement. Again, I agree with the reasoning for wanting to avoid this template. What I dislike, is a total lack of interest in finding a replacement prior to depreciating it. My major interest in the template is the fact that it is used in {{WikimediaForPortals}}, which is a highly appropriate use for clickable images. If a valid replacement (that isn't a CSS hack) comes along, I won't be disappointed in seeing this template go. But instead of complaining about its existence, perhaps some of those "grouchy busybodies" could improve ImageMap. At least that's far more progressive than simply tagging templates as depreciated, when they aren't. Justin ^chat 06:19, 29 October 2007 (UTC)

Editors just play within the world that the devs make. State that the template is not deprecated, or don't, but blaming the other side in an argument for not being devs is a rather silly line of argument. That said, Wikipedia:Glossary's main definition of "deprecated": "tolerated or supported but not recommended (i.e. beware: may well be on the way out)" seems to apply to Click, if one makes the assumption, which I certainly do, that features will continue to be added to imagemap. I don't see another use of putting a category on this image other than as a means of informing users that there may be a problem with their usage. While you are willing to argue that using Click in {{WikimediaForPortals}} is worth making portals problematic for disabled readers and others, some people are using the template in trivial ways simply because they have no idea there is an issue. I had one of those clickable icons at the top of my user page until I stumbled across a discussion about the accessibility issues. - BanyanTree 10:04, 29 October 2007 (UTC)

I'm not blaming anyone, I'm simply pointing out that disliking this template, while understandable, isn't going to fix it. As for the novel uses of this template, it is clearly spelled out on the page, that this template shouldn't be used where ImageMap can be used. I think that's a pretty clear statement. As for Wikipedia's definition of deprecated, perhaps Click does qualify, but, Category:Deprecated templates clearly states: "This category contains templates that are "deprecated" – they have been superseded by another template, often because the new template is more flexible or combines the features of two previously separate templates," which Click has not.

And we can assume that ImageMap will be improved, but wishing for something doesn't make it come true. I try to avoid assumptions which require a leap of faith. As such, I assume that the way things are, is how they will remain. And given ImageMap hasn't been updated in quite some time, that seems a safe assumption. As for it being problematic for disabled readers, is that an assumption as well or have you tried loading the template with screen reader or text-based browser? Given that {{WikimediaForPortals}} actually uses text links in addition to Click, it would seem that the problem isn't really all that big of a problem. Justin ^chat 18:22, 29 October 2007 (UTC)

[edit] Replacement template

Is it possible to make a template with a similar functionality using imagemap? It would have to have a new name, but this would facilitate replacing the click template.  Andreas  ^(T) 19:11, 13 January 2008 (UTC)

Imagemaps don't accept template parameters – Gurch 09:23, 15 January 2008 (UTC)

[edit] The downfall reimplementation of {{click}}

<imagemap> can now accept m:Help:Magic words and other fun things using the new parser function #tag. Example below.

{{#tag:imagemap|
Image:Foo.jpg{{!}}200px{{!}}picture of a foo
default [{{fullurl:{{FULLPAGENAME}}}}]
desc none
}}

produces:

Enjoy! --MZMcBride (talk) 05:51, 26 January 2008 (UTC)

Uh... {{click|image=Foo.jpg|link=Bar}} is still a lot more convenient than

{{#tag:imagemap|
Image:Foo.jpg
default [[Bar]]
desc none
}}

Can this template not simply be re-implemented to use {{#tag:}} rather than deleting it for no good reason? – Gurch 09:08, 26 January 2008 (UTC)

Here's a replacement. Although it no longer accepts the height parameter (as Imagemap works on width). Justin ^chat 17:49, 26 January 2008 (UTC)

Hmm... I'm seeing usage as Image:Foo.jpg|60x60px so it appears it does indeed accept the height param, let me work on it a bit more. Justin ^chat 18:00, 26 January 2008 (UTC)

Okay, here's what I have:

<includeonly>
{{#tag:imagemap|
Image:{{{image}}}{{!}}{{#if:{{{width}} | {{#if:{{{height}}} | {{{width}}}x{{height}}}px | {{{width}}}px }} |  {{#if:{{{height}}} | {{{height}}}px }}}}{{!}}
default [{{fullurl:{{{link}}}}}]
desc none
}}
</includeonly>
<noinclude>
{{template doc}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

There is a caveat however. Click currently accepts height and width parameters as "200px", however, because of the way imagemap works, this version of click takes the parameters as "200" (without the px). This is required, unfortunately, because when both height and width parameters are used together in imagemap, the way it's written is "200x200px". This seems rather minor, so is there a reason a bot couldn't do it? Aside from the fact that once implemented, a lot of {{click}}'s are going to be broken until the bot is finished? Unless someone comes up with a better idea :). Justin ^chat 18:17, 26 January 2008 (UTC)

Two things: (1) To my knowledge, <imagemap> doesn't accept height at all. (2) This shouldn't be implemented until the site's software is updated; there's an issue with ampersands being double encoded that's been fixed in SVN. --MZMcBride (talk) 03:13, 27 January 2008 (UTC)

The double-escaping fix has gone live. --MZMcBride (talk) 21:43, 28 January 2008 (UTC)

To address the problem presented by Justin of breaking and fixing, there is a very simple solution:

1. Create a parallel template, {{click-fixed}}, with the desired code
2. Get a bot to convert all instances of {{click}} to {{click-fixed}} while simultaneously fixing that "px" problem
3. Move {{click-fixed}} over {{click}} (causing the old revisions of {{click}} to be deleted, as a side effect)
4. Restore the old revisions of {{click}}, leave {{click-fixed}} as a redirect
5. Continue fixing {{click}}s to proper ImageMap code, the ultimate best-practice solution, without the stress that is added with the usability problems of the old version of {{click}}

That should solve all the problems... as for ImageMap not accepting height, I know that syntax containing height information works - I designed my conversion script using that assumption, and syntax containing height information will work, though granted I have not actually checked whether the height information changes anything.

Justin's version looks like a good prototype, though it'll need a couple minor fixes, and that version lacks {{click}}'s title parameter. Nihiltres^{t.l} 03:59, 30 January 2008 (UTC)

[edit] Looks like this should work

{{editprotect}} The work at {{click-fixed}} looks good, and as far as I'm concerned, the following code should be a complete replacment for the present {{click}}:

<includeonly>{{#tag:imagemap|
Image:{{{image|Transparent.gif}}}{{!}}{{{width|}}}{{#if:{{{height|}}}|x{{{height}}}px|{{#if:{{{width|}}}|px}}}}{{!}}{{{title|}}}
default [[{{{link|Main Page}}}|{{{title|{{{link|}}}}}}]]
desc {{{desc|none}}}
}}</includeonly>
<noinclude>
{{template doc|Template:Click-fixed/doc}}
<!-- Add categories and interwikis to the /doc subpage, not here! -->
</noinclude>

It seems the "px" designation is optional, so that shouldn't break anything. Unless there are complaints, this can be replaced {{click-fixed}} can be deleted and the ImageMap banner on this template can be removed :). Justin ^chat 03:34, 1 February 2008 (UTC)

I'll take care of this in a few hours. --MZMcBride (talk) 09:56, 1 February 2008 (UTC)

Y Done by User:Nihiltres. Justin ^chat 17:36, 1 February 2008 (UTC)

Can use the {{#iferror:}} parserfunction to categories (or backlink via tranclusione) pages which included a px in the height parameter or width (when used in conjunction with a height. Or has enough time passed already for people to fix these all manually. — Dispenser 23:43, 25 March 2008 (UTC)

[edit] Impact of your changes

Userpages like mine were seriously messed up by the removal of the px field. I suspected vandalism (incorrectly). It took a post at VP (technical) to get to the bottom of it and resolve the problem. Can I suggest you task a bot to remove the px from (at least) all userpage applications with an appropriate edit summary? --Dweller (talk) 12:21, 25 March 2008 (UTC)

Correct me if I'm wrong, but I'm showing the last change to this template as being on February 2. I don't believe {{Click}} is to blame for the blown-up images; I'm checking Bugzilla to see if something's changed at the system level. --jonny-mt 13:39, 25 March 2008 (UTC)

Fair enough. Cheers. --Dweller (talk) 14:44, 25 March 2008 (UTC)

Yea, I'm having the same issue all of a sudden. Let us know if you figure anything out. Drewcifer (talk) 18:06, 25 March 2008 (UTC)

[edit] Code changes

I've seen no evidence anywhere that <imagemap>'s support any type of height parameter. As such, I've removed it entirely.

In addition, I put in place a basic integer check to fix the issues with pxpx. --MZMcBride (talk) 07:32, 26 March 2008 (UTC)

ImageMaps most certainly do support height parameters; see my sandbox. Nihiltres^{t.l} 17:07, 26 March 2008 (UTC)

Thus I suggest that the code be changed to

Image:{{{image|Transparent.gif}}}{{!}}{{#iferror: {{#expr:{{{width}}} > 0 }} |{{{width|}}}|{{{width}}}{{#if:{{{height|}}}|{{#iferror: {{#expr:{{{height}}} > 0 }}||x{{{height}}}}}px|px}}}}{{!}}{{{title|}}}

to allow graceful failure without removing the height feature for those articles with correct syntax. Nihiltres^{t.l} 17:22, 26 March 2008 (UTC)

Okay, I think I understand a bit more how this works. It seems it will never take the image out of proportion, so anytime a height is specified, the width is essentially ignored. (See here.) Feel free to implement your code or I can do it a bit. Though you may want to throw it in the Template:Click/sandbox first to do some testing. My original code last night failed miserably. ; - ) --MZMcBride (talk) 18:24, 26 March 2008 (UTC)

[edit] Code change part two

I took the decision to officially deprecate the width and height parameter, as they mostly are an relic for the past, and introduce and size parameter instead. The width and hight parameter will still be available (though the height alone parameter might now always work though). I've updated the docs with the new syntax. _→AzaToth 14:48, 4 April 2008 (UTC)

Seems like a fine idea. The only pitfall is that with the size parameter, it won't be possible to easily convert all the px's to feet or somethin'. ; - ) --MZMcBride (talk) 14:49, 4 April 2008 (UTC)

[edit] Problem with new line

Hi, when i try to make a clickable image in text and in one line, i got this error:

Test {{Click|image=LinkFA-star.png|size=15px|link=WP:SIGN}} test

Test

test

So, what i want is to make that little star in same line like "test" text. Is this possible somehow ? If not, is there any other way to make this possible? --SasaStefanovic • 11:28, 12 May 2008 (UTC)

I don't know an easy way to make ImageMaps appear inline, and I'm not sure if one exists. I'll look into it. Nihiltres^{t.l} 15:58, 12 May 2008 (UTC)

No, it is technically not possible, but the German Wikipedia has a CSS workaround (German diff with workaround added - no, I don't speak German) that I'll implement in MediaWiki:Common.css. About a month from now (once that update is spread to everyone; Common.css is heavily cached), I will update the still usability-nasty {{click-inline}} to use the same code as {{click}}, but with an extra div to allow inline use – then it shall be possible to use it inline. Nihiltres^{t.l} 16:17, 12 May 2008 (UTC)

Blah. I've tested it and it doesn't appear to work properly as the p elements before and after it are closed before the element and are themselves display:block; there probably isn't any possible CSS workaround that will work totally (I can get it inline with the text after it using some tricks perhaps IE might not be happy with, but not before it, as CSS selectors can't ascend). Try {{click-inline}} for now, but I hate to think of how usability-nasty it is. Try voting for bug 539: that bug being fixed would solve the problem. Nihiltres^{t.l} 17:34, 12 May 2008 (UTC)