Template talk:Legend

message: This template does not work for me when used in image descriptions below thumbnails. Any idea why? —Nightstallion (?) 20:55, 7 January 2006 (UTC)
replies: text: Seems to work for me. Do you have an example? Zocky 19:10, 12 January 2006 (UTC)
replies: text: Erm... Pick any map, e.g. Treaty of Accession 2005 – doesn't work for me in Firefox, neither in WinXP nor in NetBSD nor in MacOS X. Works fine in IE, though, and I frankly just don't know why... —Nightstallion (?) 22:43, 15 January 2006 (UTC)
replies: text: Hmmm... it works fine for me on firefox on W2K. What goes wrong for you? Zocky | picture popups 00:13, 16 January 2006 (UTC)
replies: text: Well, the little boxes that should show up next to the text (in the example I linked to, the mint green and light green boxes to the left of "ratified" and "not yet ratified") don't show up at all. There's space there where they should be, but the boxes don't show up. scratches head Any idea what the problem might be? Or if not, any idea which other user and/or developer is likely to know? Thanks either way! —Nightstallion (?) 06:52, 16 January 2006 (UTC)

text: For the record, it works fine for me in image descriptions such as the one linked to below; just not below thumbnails. —Nightstallion (?) 11:44, 16 January 2006 (UTC)

text: Colors don't work here at all. There're just the 1px gray borders forming a thin rectangle, then the text. Firefox (Ubuntu) here. I can send you a screenshot, if necessary. --Hdante 00:07, 20 January 2006 (UTC)
replies: text:  However, if I change the " "s to some text, say "blarg", then the text appears, with a correct background. --Hdante 00:14, 20 January 2006 (UTC)
replies: text:  Changed one " " to a " " and it started working. THIS MAY BE A BUG in Firefox. Mozilla should be contacted, but I won't do this, since they don't seem to answer normal people. --Hdante 00:35, 20 January 2006 (UTC)
thread_title: Image descriptions below thumbnails

message: The size looks great for being placed inside articles, as part of the image frame. Would it be possible to have a facility to have a larger version of this, either with this template, or a twin, for the purpose of adding a legend to an Image: page? For example, see the original legend and compare with it changed to use  at :Image:Mississippi Delta Lobes.jpg. --Interiot 11:28, 16 January 2006 (UTC)
thread_title: Larger version?

message: Should this be substed? on first take I'd say yes, but I'd like to hear what others think. It doesn't seem this style is likely to change therefore it doesn't need to be dynamic like some other templates. It's also too much code to remember and therefore would make it convenient to be in template form. Comments? gren グレン ? 07:18, 20 January 2006 (UTC)
replies: text: Definitely not. It becomes unreadable and bulky if it's substed. Aris Katsaris 14:10, 27 January 2006 (UTC)

text: Yeah, why not. —Nightstallion (?) 10:28, 21 January 2006 (UTC)
replies: text:  I think it's a lot more readable and maintainable for most people if it's left unsubsted. Also, per Brion's comments, we don't really need to overboard with the substing. --Interiot 11:13, 21 January 2006 (UTC)
thread_title: Re:Subst?

message: Hello. I think I have a conclusion about Firefox not correctly rendering this template. The unchanged version (id 35788705) used two "em spaces" ( ) filled with the desired background color. The expected output was a little box with a customized color and border. There were two problems: mine was that the spaces inside the border didn't appear, so that there were just the borders with a zero area inside (it appeared like a thin gray '|'). Nightstallion's was that neither the inside nor the borders of the box appeared, if it was inserted inside an image box. I didn't really understand Nighstallion bug, it seemed that the 'span' tag was being ignored as if the browser didn't recognize the attribute specification (it seems to be possible for the browser to ignore, say, an invalid font or color, but I couldn't reproduce that specific problem). On the other hand, I've found some text about the XHTML specification listing which characters are considered whitespaces:
(...)
White space is handled according to the following rules. The following
characters are defined in [XML] white space characters:
* SPACE ( )
* HORIZONTAL TABULATION (	)
* CARRIAGE RETURN ()
* LINE FEED (
)
(...)
C.15. White Space Characters in HTML vs. XML
Some characters that are legal in HTML documents, are illegal in XML
document. For example, in HTML, the Formfeed character (U+000C) is treated
as white space, in XHTML, due to XML's definition of characters, it is illegal.
Those whitespace characters are typically compressed so as to keep just a single space between words and to remove the leading and trailing spaces. And that's what Firefox seemed to be doing here — it was most likely treating emspaces as white spaces and compressing them (if I remember well, wget downloaded the page with two emspaces, while Firefox 'view source' showed the page with no space at all). Again, I still think that this is a BUG IN FIREFOX. That's so, because:
* Zocky and Nightstallion were able to render the box in Internet Explorer
* I was able to render the box in Konqueror
* I was able to render the box in Firefox 1.5, which I've just downloaded
Since I believe that this is a Firefox bug, I see no reason why we shouldn't revert back to the original box or, for the sake of current Firefox users, use a combination of, say, emspace and nbspace so that the old bugged Firefox isn't able to compress them. As for Nightstallion, I can only ask that he update his browser and try again.
:My browser is up-to-date, I'm afraid. —Nightstallion (?) 19:17, 22 January 2006 (UTC)
replies: text: Well, much better than that, here is the actual code pointed out by Interiot.
 	Salé-Cypremort  	4600 years BP
 	Cocodrie             	4600-3500 years BP
 	Teche                	3500-2800 years BP
 	St. Bernard          	2800-1000 years BP
 	Lafourche            	1000-300 years BP
 	Plaquemine           	750-500 years BP
 	Balize               	550 years
--Hdante 22:53, 21 January 2006 (UTC)
thread_title: Template and Firefox (final)

message: Does using █ work for everyone, or are there issues with this? It shows up perfectly for me now. —Nightstallion (?) 10:40, 26 January 2006 (UTC)
replies: text: Seems to work fine, provided that the template is used exactly as instructed. It's whitespace problems again, but different from what was noticed before. Many people like adding extra spaces around separators, which breaks this template for some. Example:   MediaWiki translates trailing whitespace in template parameters to HTML character entities. Here the CSS property in the second test is given to the browser as " color: #f00 ; " (where 160 is the same as nbsp). IE parses this incorrect value and shows what may have been intended, but Firefox goes by the specs and ends up with a meaningless value, rendering it black. I'm not sure if this is really a MediaWiki problem, maybe leading or trailing whitespace is actually necessary somewhere, and all templates where parameters are directly used for CSS should be accompanied with a note to drop the spaces. --para 21:00, 19 April 2006 (UTC)
thread_title: Next attempt

message: Since tooltips (at least in Mozilla FF 1.5) do not show colors, the tooltips for images using this template are useless. For one example, see Driving on the left or right; the tooltip for the top image (the map) has two black boxes... not very useful. Any way to fix this? -Grick(talk to me!) 00:00, 13 August 2006 (UTC)
replies: text: I understand it'd be good that the tooltips included the legends... But to be honest what's the real issue? The tooltip is duplicating the text which is used to annotate the image under the thumbnail - therefor it's already displayed correctly on the page. Regardless I think we're stuck with a browser limitation here. Thanks/wangi 00:12, 13 August 2006 (UTC)

text: I... don't think there's any remotely easy way to fix this, no. Even if it were, and it required very much finagling at all, I'd say it's not worth it. Besides the point that wangi brought up, that alt-text is typically primarily meant to be used when the image isn't displayed, and if the image isn't displayed, then what's the point of explaining to the user what the exact colors used in that image are? --Interiot 09:20, 13 August 2006 (UTC)
thread_title: tooltips: colors don't work

message: Documentation says:
: color is passed to the css background property, so it can also include images. The optional border argument is passed to the css border property.
first looking the code this is not what code does + as much I have tested, searched, CSS background-image is one thing that doesn't work in page code, so the second part of the text is misleading. Or can somebody expalin opposite? --TarmoK 09:34, 29 October 2006 (UTC)
replies: text: No, I think it's pretty clear that background-image doesn't work anywhere on this specific wiki at least. It's possible it would work on other MediaWiki wikis, but not this one. --Interiot 18:59, 29 October 2006 (UTC)
replies: text: I fixed the documentation to reflect that. Zocky | picture popups 03:09, 7 November 2006 (UTC)
thread_title: images?

message: I've recently created a version of this template which does not force a block element / new line after it's use, see: . It would be good if this functionality could be incorporated here so we could avoid a fork - is it doable? Thanks/wangi 00:35, 28 January 2007 (UTC)
thread_title: Non block element

message: This template is used here, but I think it would look better if a legend template that didn't modify the font size was used. The text becomes too small because it is nested within two templates, both which tries to modify font size. —Tokek 14:03, 3 February 2007 (UTC)
thread_title: Version that doesn't mess with font size?

message: After the change from User:BenoniBot  which included the interwiki links already transcluded from Legend/doc, all the interwiki links from this template were visible in article that are transcluding this template. Somehow the double-noinclusion does not work properly. I reverted the adding of the interwiki links for the moment. I don't quite find the right point to do this permanently. Can someone see to that the bot will not destroy the template again? --FordPrefect42 00:23, 19 June 2007 (UTC)
thread_title: Broken transclusion

message: I fiddled a bit with the border setting, hoping to make it better, so that the following example looks correct, i.e. all the boxes are the same size:
But, as we can see in the example on the right, the template isn't working exactly right. The wrapped rows shouldn't extend under the colored box. At least in my Firefox on Ubuntu, the divs in captions no longer make the text progressively smaller, so we should be able to do this correctly by inserting floating divs, as in the bottom example. Does this look correct in IE? Zocky | picture popups 14:21, 24 September 2007 (UTC)
thread_title: Floating

message: Hi -- I just observed that the color swatches produced by this template don't show up on printouts (at least, from the most recent Safari browser on Mac 10.5). Can this be fixed? I am not, unfortunately, terribly advanced in the art of template-fu. :( Love the template, though -- it's allowed some really nice improvements to a number of articles I've worked on. -Pete (talk) 23:41, 12 September 2008 (UTC)
thread_title: Printing

message: On Commons it's mentioned that this template can take an image instead of a colour. Is this possible and if so what syntax should be used. /Lokal_Profil 20:08, 5 December 2007 (UTC)
thread_title: Image

message: This template exists on the Commons too. See commons:Template:Legend. --Timeshifter (talk) 22:09, 26 September 2008 (UTC)
thread_title: commons:Template:Legend

message: Per Wikipedia:Colours#Using_colours_in_articles "ensure that colour is not the only way used to convey important information". Therefore wouldn't it be beneficial to add a code to allow text to be entered here. So you could have for example
  *   Explanation
Is this a useful, viable option? Rambo's Revenge (talk) 18:06, 23 October 2009 (UTC)
replies: text: I've now mocked up code and testcases with the changes I suggested. Rambo's Revenge (talk) 12:04, 25 October 2009 (UTC)
replies: text: I also think this is necessary. KV5 (Talk • Phils) 19:28, 28 October 2009 (UTC)
replies: text: , Rambo's Revenge (talk) 17:51, 3 November 2009 (UTC)
thread_title: Alteration?

message: I remember there was no boarder and it's smaller, is it on my computer or on wikipedia? Other languages still small without boarder.
I tried looking in the history, but it's the same as now.--125.27.45.78 (talk) 07:43, 21 December 2010 (UTC)
replies: text: There have been some changes to the template which made the icons bigger. The older pages won't show any difference because the example uses the current template, not the old one. I asked Edotker to add a size parameter so the size can be controlled (see the section above this one). Betty Logan (talk) 07:58, 21 December 2010 (UTC)
thread_title: Weird change

message: Could a CSS class be added to the output of this template, so that custom styling can be applied? Ucucha 22:51, 18 July 2011 (UTC)
replies: text: Good idea. Classes added: .legend, .legend-color and .legend.text.  — Edokter (talk) —  00:57, 19 July 2011 (UTC)
thread_title: CSS class

message: I was trying to figure out how to get a legend with stripes, and I ran across this article: http://lea.verou.me/2010/12/checkered-stripes-other-background-patterns-with-css3-gradients/
Does Wikipedia have a policy against using CSS3 right now (since may browsers don't support it), or could we use this technique to get striped legend entries? At the very least, since striping is a common technique on maps, we need a way to designate striping in legends --Nick2253 (talk) 19:27, 6 February 2012 (UTC)
thread_title: CSS3 to get striping

message: This template is probably a prime candidate for TemplateStyles because it includes a lot of inline CSS and is expected to almost always occur multiple times on a page. I've started a simple prototype of conversion to use TemplateStyles at Template:Legend/styles.css and Template:Legend/sandbox; some review is highly desirable given the 21k transclusions of this template. Importantly, I haven't (yet) considered consistency with  or done a search for other objects using the classes legend or legend-color that could be affected by the stylesheet, so it probably needs a bit of tweaking. Please provide your input! :)  20:31, 1 August 2020 (UTC)
thread_title:  TemplateStyles 

message: Just wanted to give a heads up about having made , which I think would be a good reason to suggest or adopt as the standard wrapper for uses of this template. I'm not sure exactly where this template is used, so right now image key is limited to applying its styles inside a div with the thumb class (which is our thumb files!), but styles can be added for that.
More discussion at Wikipedia:Templates for discussion/Log/2021 January 8#Template:Column-count. --Izno (talk) 05:42, 9 January 2021 (UTC)
thread_title:  Noticed an ouch or two use patterns of this template 

message: - -->
replies: text: This looks useful, but it's not entirely clear. Can you please put this edit in the sandbox and then add at least one relevant case to the testcases page so that the live template can be compared to the sandbox? – Jonesey95 (talk) 13:58, 11 May 2021 (UTC)
replies: text:   Nixnova had already added this to the sandbox, and I added testcases to the end of the /testcases page. Thoughts? * Pppery * it has begun... 18:58, 14 May 2021 (UTC)
replies: text: I have added some more test cases, including some degenerate ones. The only problem I see is when  exists but is empty. I see a vertical offset of the label text, which I can't explain. If you all are happy with the test cases, I'll implement the sandbox code. I have added this page to my watchlist. Sorry if this seems excessive, but this template is used in a LOT of pages and sometimes in strange ways. The testcases page should probably be updated with some oddball usages from actual articles. – Jonesey95 (talk) 21:02, 14 May 2021 (UTC)
replies: text:  I'd say that the test cases you added look good to me.  Thoughts? * Pppery * it has begun... 00:40, 18 May 2021 (UTC)

text: Thanks for the update. I found a degenerate case in the wild, and I have copied it to the testcases page to demonstrate a bug or limitation of the current code. Take a look at the "Misnested span tag errors". I have copied the previous version of the template into the sandbox so that you can see how it rendered in the past and how it is broken today. – Jonesey95 (talk) 15:02, 21 July 2021 (UTC)
replies: text: Pleasure! As you know, Jonesey95, there are some templates out there that behave in unexpected ways under certain conditions. That can be noted in the documentation under headings like  or  to let editors know that they might receive results they don't expect. If a true bullet is needed in those cases, they can use  instead of a plain asterisk, as I've done in the same testcases section. P.I. Ellsworth  ed. put'r there 21:32, 21 July 2021 (UTC)
replies: text: Sorry if I was unclear. I was attempting to report a bug that may be fixable with a modification to the template's code. The previous version of the template rendered an asterisk as an asterisk; the new version changed that behavior and also caused Linter misnested tag errors. It seems likely that other variants of this bug have been introduced into articles with the latest change. – Jonesey95 (talk) 23:38, 21 July 2021 (UTC)
replies: text: This bug is also present in . See the "Inner text test" at Template:Legend inline/testcases. – Jonesey95 (talk) 00:24, 22 July 2021 (UTC)
replies: text:  thought some about this, but a fix appears to be above my paygrade. What do you think? Should we go back to the previous version? or do you have any idea what code change will squash the bug? P.I. Ellsworth  ed. put'r there 09:44, 23 July 2021 (UTC)
replies: text: I tried a few things in the sandbox but was unable to fix it. I think this may be related to . I decided to just document the new limitation, which I am sure exists in other templates, and fix the new errors that showed up in the Linter lists. I think we can let this go. – Jonesey95 (talk) 13:34, 23 July 2021 (UTC)
thread_title:  Template-protected edit request on 11 May 2021 

message: What do you think about adding border-radius to the CSS of this template? I note that rounded borders/corners are a trend in current web design and layout and have a positive psychological and emotional effects on people. − Allice Hunter (Inbox) 03:45, 2 November 2021 (UTC)
replies: text: It's usually best to have the whole site looking pretty much the same, rather than changing just one template, but you are welcome to put your change in the template's sandbox and demonstrating it on the testcases page. – Jonesey95 (talk) 04:49, 2 November 2021 (UTC)
replies: text: I agree with you about keeping the entire site looking the same. But I think we could implement changes little by little in all templates until we get a standardization of the layout. Unfortunately I notice that the site is looking very outdated. We don't even have a decent dark mode and the changes in the new Vector weren't enough to update our layout according to the new trends. A small change in cascade can make good difference. − Allice Hunter (Inbox) 19:49, 2 November 2021 (UTC)
thread_title:  Border radius 

message: A lot of people have been using the dark mode gadget.. This gadget inverts the colours, but NOT for images. As Template:Legend is NOT in image, it DOES get inverted. There is a way to opt out of this behaviour, using the class "mw-no-invert", but... Template:Legend is used for both images (maps generally) and non-images (CSS graphs for instance).
I see no good way around this, other than maybe have things like Template:Pie chart call Template:Legend, with a specific parameter to indicate that the "mw-no-invert" should NOT be used in those specific cases. But even then there might be lots of use cases out there.
Thoughts welcome. Examples to the right if you want to enable dark mode and see the problem of legend collars not matching the colours they are describing. —TheDJ (talk • contribs) 10:15, 6 January 2022 (UTC)
replies: text: @TheDJ We could target pie-chart specific legends using html.client-dark-mode .PieChartTemplate .legend in TemplateStyles. – SD0001 (talk) 08:05, 8 January 2022 (UTC)
replies: text: But there is more than 1 template. And a few of the calls aren’t even templates at all. —TheDJ (talk • contribs) 10:27, 8 January 2022 (UTC)

text: I've applied no-invert to both legend and piecharts, but there might be lots more cases. I guess we will await the feedback. —TheDJ (talk • contribs) 13:23, 21 July 2022 (UTC)
replies: text: @TheDJ Very belated response, but (through ) this template is apparently used in articles like iPhone 15 Pro. You can see in the "Design" and "Detailed Specs" sections I've utilized the .mw-no-invert to prevent the colors from being changed when dark mode is enabled. This isn't ideal as it requires knowledge of the issue by editors to resolve. Not sure what the right answer is here, but wanted to give a few more examples for anyone still looking at this. —Locke Cole • t • c 03:47, 18 September 2023 (UTC)
replies: text: Someone would have to analyse the usages of colorbox to check if they refer to true, 'source' colours, or more 'legend' colours. If they are almost always source colours, the class probably can best be set on the template itself. —TheDJ (talk • contribs) 09:36, 18 September 2023 (UTC)
thread_title:  Dark mode compatibility 

message: I did a search in the help and talk pages, so forgive me if this has been reported in the past.
Is there a reason the legend boxes in Media Viewer are narrow? I seem to remember them being square some years ago.
Example: https://en.wikipedia.org/wiki/Template:Legend#/media/File:Celts_in_Europe.png. The Equalizer (talk) 20:45, 15 February 2022 (UTC)
replies: text: This is an issue with TemplateStyles and MediaViewer, and not the template itself. Parsed content is being used in the MediaViewer view, but it's not wrapped in the mw-parser-output class. All TemplateStyles styles are "hoisted" to only apply within an element with that class, so TemplateStyles styles don't apply in MediaViewer, and only dynamic properties specified on the rendered HTML element (i.e. the background colour and text colour) are being passed through. A bug is already filed as T284857.  15:47, 16 May 2022 (UTC)
replies: text: Thanks for the update, forgot to check Phabricator. Regards, The Equalizer (talk) 13:47, 17 May 2022 (UTC)
thread_title:  Media Viewer