Template talk:Key press

Picture of a key

Resolved

 – Suggestion would violate WP guidelines.

I personally think we should have an actual picture of a key.

{{{1}}}

–Sidious1701_{(talk • email • todo)} 21:16, 13 January 2008 (UTC)

See WP:MOS#Images as text. Chris Cunningham (not at work) - talk 11:38, 14 August 2008 (UTC)

Doesn't work anyway. This does not look as-intended on Firefox 4, Win 7, for example; the value is next to, not on top of, the image. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:40, 19 June 2011 (UTC)

This rocks

Man, I love this template. Thanks folks. Is it advertised anywhere in the VG projects? I'd never seen it until today. Chris Cunningham (not at work) - talk 10:39, 14 August 2008 (UTC)

By "VG projects" I assume you mean "Video Game projects"?

You got a point in that it needs to be advertised. But from what I see in "What links here" it wasn't advertised anywhere. So I have now added it to Wikipedia:Template messages/Format.

--David Göthberg (talk) 20:11, 23 March 2009 (UTC)

Concur with Chris' comment - this template is lovely. — Hex (❝?!❞) 21:51, 25 February 2012 (UTC)

Using :before CSS class to show images

This would probably be better accessibility-wise than having users manually include symbols. It's supported by mosy standards-compliant browsers. Chris Cunningham (not at work) - talk 10:42, 14 August 2008 (UTC)

Bah. I've realised that this won't work, because pseudo-classes can't be styled using style attributes. I suppose something could be added to common.css, but that's a bit more work than I'd have liked. Chris Cunningham (not at work) - talk 11:36, 14 August 2008 (UTC)

Nowrap is creating a problem

It might just be my browser, but when I resize the text in Table of keyboard shortcuts, some of the keys overflow the table cells. --Nezek (talk) 08:53, 1 March 2009 (UTC)

I'd just add spaces before and after the "+", to create a break opportunity between the keys. —Ms2ger (talk) 10:21, 1 March 2009 (UTC)

I have added Ms2ger's explanation to the "Technical details" section of the documentation of this template.

--David Göthberg (talk) 17:53, 23 March 2009 (UTC)

.keyboard-key

I have left a message over at MediaWiki talk:Common.css#.keyboard-key, regarding the .keyboard-key CSS class in this template.

--David Göthberg (talk) 04:52, 23 March 2009 (UTC)

That discussion resulted in that we removed the .keyboard-key class from MediaWiki:Common.css. But we still have the class name in the template itself, so users can still style the keyboard keys by adding code in their /monobook.css and using the !important keyword to override the styles.

--David Göthberg (talk) 01:08, 24 March 2009 (UTC)

My rework of this template

I have just reworked the code of this template. There's no change in looks and no real change in functionality. Here's what I have done and why:

1: I moved the code that was used repeatedly to the {{keypress/core}} sub-template. I also moved the unicode symbol inserting code from the old subtemplate {{keypress/Switch}} to /core. This means {{keypress/Switch}} is not used anymore. But I think we should keep the old /Switch template for reference and otherwise {{keypress}} looks seriously broken when looking at older versions of it. Since we already had the /Switch sub-template which was always called this means no change in efficiency. (Note that it takes some time before the "What links here" lists are updated, since pages are only re-rendered when visited.)

2: I added a "←" symbol when "Backspace" is fed, thus rendering "← Backspace".

3: I simplified/compacted the CSS style code somewhat. (See the code in {{keypress/core}}.) It causes no change in appearance. And these keys look fine in the browsers I have (a very old IE 5.5, a slightly old Opera 9.02 and a Firefox 2.0).

4: This template used to be able to take 10 key parameters. But the worst case I could find only used 4 parameters, so 10 seems to be overkill. I lowered it to 5 to still have some margin. To make sure I made it so this template reports into Category:Wikipedia keypress template parameter needs fixing if it gets too many parameters. This means we can easily find those pages and fix them, or we can discover if we need to make this template take more parameters. It usually takes about 2 weeks until nearly all cases get visible in such a category, since pages are only re-rendered when someone visits them. I made the category hidden for now, so we can have a look at the cases (if any) without most other editors noticing. So we can decide on how many parameters we need. After about 2 weeks when we have had our look we should make the category visible, so editors that use this template on pages will notice when they use too many parameters.

--David Göthberg (talk) 18:25, 23 March 2009 (UTC)

Colon, Pipe, Star - special characters

It does not seem to work for a colon or pipe:

• {{Keypress|:}} produces ;
• {{Keypress||}} produces + (perhaps this is not unexpected - but what is the workaround?)
• {{Keypress|*}} produces *

and just to prove (to myself) that I have the correct syntax:

• {{Keypress|1}} produces 1

Anyone know how to fix this? --Robinson weijman (talk) 12:56, 5 May 2010 (UTC)

*, :, ;, and | are wikimarkup, so these are problematic. However {{Keypress|{{!}}}} | works (as does {{Keypress|{{;}}}} ;).

I've adapted the sandbox (and now the template). You can now use them in the following way:

Asterisk: {{keypress|*}} * Linked: {{keypress|[[*]]}} *

Colon: {{keypress|:}} : Linked: {{keypress|[[:]]}} :

Semicolon: {{keypress|{{;}}}} ; Linked: {{keypress|[[;]]}} ;

Pipe: {{keypress|{{!}}}} | Linked: {{keypress|[[|]]}} |

— Edokter • Talk • 19:21, 2 September 2010 (UTC)

Equals sign also needs to be treated separately:

{{Keypress|{{=}}}} =

I've added a replacement for the number sign:

{{keypress|#}} #

{{keypress|[[#]]}} #

— Simo Kaupinmäki (talk) 23:37, 6 September 2010 (UTC)

Thanks for updating the template and the doc. However, bolding the small diacritics has no effect, as the font is too small, so I have removed those. Best is to keep /core as small as possible. — Edokter • Talk • 03:03, 7 September 2010 (UTC)

Thanks for the fixes, Edokter! --Robinson weijman (talk) 12:00, 7 September 2010 (UTC)

Well, the effects of bolding the small diacritics (´`¨) depend on the font settings of your browser and the resolution of your screen. Compared with unbolded characters (´`¨) I can see a difference particularly in the diaeresis. However, generally I suppose you are right, so it may not be worth putting extra code in the core. Thanks for pointing that out. — Simo Kaupinmäki (talk) 13:29, 7 September 2010 (UTC)

OK, this left me wondering: what are the exact downsides of a bigger core? Is it just that generally it's a good idea to keep things simple, or may additional code cause more concrete problems? I ask this because my understanding of creating templates is still limited. I've just copied this template into fi.wikipedia with some modifications and additions, and while some of the additions (such as the bolded diaeresis) may be useful in a specific user case, they are not essential. It would be interesting to learn more about the principles of optimizing the code. — Simo Kaupinmäki (talk) 17:44, 7 September 2010 (UTC)

Page Up/Page Down

These keys do not have symbols; they never had. I intend to remove them from /core. Any objections? — Edokter • Talk • 18:08, 2 September 2010 (UTC)

I have removed them. — Edokter • Talk • 00:13, 3 September 2010 (UTC)

You have never used an (older) Apple keyboard nor read an ISO standard, I assume. ⇞ Page Up and ⇟ Page Down (cf. ⎗ Prev. Page and ⎘ Next Page), also ⇱ Home and ⇲ End as well as ⌧ Clear, ⌅ Enter, ⌦ Del, ⇪ Shift Lock, ⌥ Alt, Tab ⇥, ↵ Return and ⌘ , but not ⌫ Erase, ⎋ Esc or ⌃ Ctrl. — Christoph Päper 09:35, 16 July 2015 (UTC)

Opera allows a line break after the left border of a key image

Unfortunately it seems that Opera allows a line break after the left border (!) of the first key image produced by a template, thus breaking the image. You can prevent this from happening by disallowing a break right before the template by using a no-break space between the template and the preceding character. In the case of several adjacent templates you can wrap them all together with <span style="white-space: nowrap;">.

Is there any better way to prevent these brain-dead line breaks? —Preceding unsigned comment added by Simo Kaupinmäki (talk • contribs) 18:52, 7 September 2010 (UTC)

Unfortunately, no. The core template is already wrapped in a no-wrap span. Wrapping it in another span is ugly, and may not solve the problem. But I will try to eliminate preciding spaces. — Edokter • Talk • 01:42, 8 September 2010 (UTC)

Thanks for the effort, but it doesn't seem to help. And you were correct in assuming that putting the no-wrap span into the main template does not make any difference either. I even tried to replace the regular spaces in the main template with no-break spaces, but to no avail. It looks like the odd line breaks can't be prevented from within the template, so if you want to play safe, you need to separately disallow breaking just before each template. Too bad. – Simo Kaupinmäki (talk) 12:43, 8 September 2010 (UTC)

Mouse buttons

Can I make a request to include mouse buttons e.g.:

• left mouse button (or just LMB)
• middle (MMB)
• right (RMB)
• wheel up (MWU)
• wheel down (MWD)

Something like that? --Robinson weijman (talk) 09:30, 5 October 2010 (UTC)

You can already put in anything you want; you just have to enter exactly what you want to show, like LMB, but this template wasn't intended with mouse buttons in mind. — Edokter • Talk • 14:04, 5 October 2010 (UTC)

Ah, yes, of course. Thanks! --Robinson weijman (talk) 06:16, 6 October 2010 (UTC)

You could also use . ›mysid (☎∆✎) 13:15, 6 October 2010 (UTC)

Nice one - can anyone (with expertise) add them to the template? I might be tempted to give it a go... =:-) —Preceding unsigned comment added by Robinson weijman (talk • contribs) 18:36, 9 October 2010 (UTC)

You can expiriment in the sandbox, but I do believe mouse buttons are outside the scope of this template. {{Mouse click}} perhaps? — Edokter • Talk • 19:00, 9 October 2010 (UTC)

Another thing to consider is that the functions of the left and right mouse button are often reversed for left-handed people, in which case such images can be rather confusing. (Therefore it is also better to speak of primary and secondary mouse buttons unless you know for sure that the user's mouse has been configured to function as right-handed.) – Simo Kaupinmäki (talk) 23:01, 10 October 2010 (UTC)

Furthermore, this would generally violate the guidelines at WP:ICONS - don't use iconic images as cutesy replacements for simple wording unless there's a very good reason to do so (e.g. because in a wide and long table of sporting statistics, IRL is more concise than Republic of Ireland, and flags actually usually help people find the competitors they are interested in, thus their use in Olympics Games broadcasts, etc.). And yes, it would need to be a different mouse click template even if it wasn't an obvious WP:ICONS problem, since they would serve different purposes. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 09:25, 19 June 2011 (UTC)

Caps Lock symbol

What I've seen on some keyboards and in the keyboard template is that the Caps Lock key has a solid version of the upward pointing arrow that is used for the shift key. Is there a unicode solid arrow that can/should be used?Naraht (talk) 14:10, 14 February 2011 (UTC)

Arrow (symbol). — Dispenser 15:16, 14 February 2011 (UTC)

Upwards Thick Arrow From Bar 0x21ea may be appropriate.Naraht (talk) 16:41, 14 February 2011 (UTC)

I've added it. — Edokter (talk) — 16:59, 14 February 2011 (UTC)

ISO/IEC 9995: ⇧ Shift vs. ⇪ Shift Lock vs. ⇬ Caps Lock (and ⇧ Level 2 vs. ⇮ Level 3 vs. ⇯ Level 3 Lock or ⇨ Group vs. ⇰ Group Lock) — Christoph Päper 09:21, 16 July 2015 (UTC)

The element kbd

Resolved

 – Fixed.

Shouldn't this be <kbd class="keyboard-key"...> instead of <span class="keyboard-key"...>? It took several years to get the MediaWiki developers to properly and fully support the semantic markup elements like <kbd>, <dfn>, etc. Shame not to actually use them for their intended use. Especially since <span> has no semantic meaning at all, much less an appropriate one. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 09:20, 19 June 2011 (UTC)
PS: After this is fixed, the template should be added to Category:Semantic markup templates and its Template:Kbd shortcut added to Category:Wikipedia XHTML tag-replacing templates. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 09:33, 19 June 2011 (UTC)

<kbd> turns the text into a monospace font, which is not what we want. So while maybe semantically correct, visually it looks horrible. — Edokter (talk) — 13:14, 19 June 2011 (UTC)

Forgot about that. It's an easy CSS fix: Template:Key press/Sandbox. Barring any objections, I'd like to install this. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:43, 19 June 2011 (UTC)

 Done. — Edokter (talk) — 16:29, 19 June 2011 (UTC)

I added the semantic markup category, and also made {{kbd}} a new, more general-use template in the XHTML tag replacements category (as a redirect to this template, the name was only used in one place). — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:11, 19 June 2011 (UTC)

Thorn (letter) and other Alt Gr uses

Thorn (letter) is showing up at Category:Wikipedia keypress template parameter needs fixing. The thing is, I think its use of more than 5 keystrokes is legitimate: it's a composition using Alt Gr, which has to be held down for the duration of the sequence. Anyone know what the upper bound on these sequences is? If it's six characters, for instance, we can just slightly expand this codebase, whereas if it's open-ended we might want to rethink having a cleanup category for these. Chris Cunningham (user:thumperward) (talk) 15:52, 11 May 2012 (UTC)

This template has a limit of five parameters indicating consecutively pressed keys (indicated with a '+' between the keys). Any keys types in sequense must be entered using a new instance of the template. — Edokter (talk) — 19:47, 11 May 2012 (UTC)

Right, but the problem is how to represent a sequence which is "hold the Alt Gr key while typing these five characters in sequence, then release the Alt Gr key". Is it possibly worth concocting some sub-template at {{Alt Gr}} to handle this use case? Chris Cunningham (user:thumperward) (talk) 09:13, 12 May 2012 (UTC)

How about alt+(012828) ? — Edokter (talk) — 20:52, 12 May 2012 (UTC)

I concur with Edokter; that's a simple solution that doesn't require any new templates or more complicated template code. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 07:41, 13 May 2012 (UTC)

Sounds good. That would empty the cleanup category. To be quite honest, I'd rather simply have it error out than silently do the wrong thing and categorise pages for cleanup: any objections to making that change? Chris Cunningham (user:thumperward) (talk) 09:38, 13 May 2012 (UTC)

If you read through the template documentation, you can see that the solution mentioned by Edokter has also been suggested there – though without the parentheses. I don't think parentheses are really necessary here, as lack of punctuation between digits makes them appear as a group. – Simo Kaupinmäki (talk) 17:45, 27 June 2012 (UTC)

Sorry for necromancing this discussion, but {{key press|alt}}+({{key press|0|1|2|8|chain=}} does the same but is shorter. I don't know when the chain parameter was added so it might not be available 1.5 years ago. — xZise [disc] 19:08, 9 December 2013 (UTC)

DS/Wii and Electronic arrow button key

There was some discussion at Wikipedia:Templates for discussion/Log/2013 May 29#Template:DS/Wii key press with the outcome that this could be potentially merged here. The code is now in User:QM400032/DS/Wii key press and User:QM400032/Electronic arrow button key press. If this is needed or wanted, you may want to consider merging them. However, the author is currently indef blocked. Thanks! Plastikspork _―Œ^(talk) 14:07, 7 June 2013 (UTC)

Should there a distinction between left/right shift keys added?

I used this template (and the core template) for the Kerbal Space Programm Wiki. There I required a right shift so I added there right and left shift/2nd level, with the same features as the usual shift. Should this change added back into here? — xZise [disc] 11:56, 8 December 2013 (UTC)

Pollution

Over the last months, this template has been terribly polluted with all sorts of symbols that do not normally appear on a computer keyboard. This makes the template, and the pages it is used on, appear very messy (especially the shift/ctrl/alt sympbols). I am once again going to remove all sympbols that do not appear on a normal computer keyboard, for which this tempate was originally designed. — Edokter (talk) — 12:39, 8 December 2013 (UTC)

@Edokter: Have you reviewed the recent changes? It looks like some well-intentioned people have added such symbols in again.

Maybe it would be best to leave some comments about these keys being deliberately omitted, and perhaps a nice big comment right at the top of {{key press/core}} stating that "This template should NOT show symbols that ARE NOT found on the keys". Unfortunately, I see that my keyboard has arrows on the shift keys.

And, you know, consider protecting the template more fully.

If you don't want to protect it, you might want to avoid removing the multimedia keys and such that would always bear those symbols on any keyboard that has them, along with the " key" variants that display strange symbols without words; removing them seems likely to lead to (very slow, perhaps unintentional) revert wars. —SamB (talk) 03:19, 18 February 2014 (UTC)

Most of the removed symbols come from ISO/IEC 9995-7. Most of them are or have been present on actual physical keyboards. — Christoph Päper 18:50, 21 October 2014 (UTC)

For those who need less frequent key symbols, there now is {{key top}}. — Christoph Päper 09:12, 16 July 2015 (UTC)

Separator for Key Sequences

This template's doc does not describe which separator to use in case some keys are pressed in sequence, for instance in Alt+Space N to minimize (iconify) a window. I used a space here but this is not handled consistently in WP: someone else could have used Alt+Space, N, Alt+Space-N or Alt+Space—N. -- Juergen 37.252.110.97 (talk) 21:46, 8 June 2014 (UTC)

Key press change, or maybe new template "escape series"?

ANSI and VT codes consist of strings of characters, generally proceeded by the escape. To display these, someone suggesting using this template. It looks good, but it is hard to enter, because the template normally inserts plusses if multiple characters are entered in a single string. I don't want "press escape at the same time as I and 0", I need "press escape THEN I and THEN 0. Perhaps a flag to suppress the plus signs? Or maybe a different version that does it by default? Maury Markowitz (talk) 15:30, 5 February 2015 (UTC)

You can simply use the template multiple times: Esc I O. 18:28, 5 February 2015 (UTC)

Sure, but it's hard. Lots and lots of typing that's hard. Maury Markowitz (talk) 19:15, 5 February 2015 (UTC)

It turns out you can remove the "+" with |chain= (leave it empty). -- [[User:Edokter]] {{talk}} 19:38, 5 February 2015 (UTC)

• I've started {{ESC}} for this purpose. I'll neaten it up and finish it in the next few hours. In class waiting for the instructor to show up at the moment. — {{U|Technical 13}} (e • t • c) 20:13, 5 February 2015 (UTC)

Thanks to both Edokter and Tech, I'll make widespread use of both! Maury Markowitz (talk) 12:16, 6 February 2015 (UTC)

missing section in the description

In the current version of Template:Key_press/doc [1] the first para in the Key symbols section refers to some 'Arrows exception below' — but there's no 'arrows exception' below... --CiaPan (talk) 08:49, 9 July 2015 (UTC)

Removed. Documentation pages are usually not protected, so you can fix them yourself. -- [[User:Edokter]] {{talk}} 20:38, 9 July 2015 (UTC)

@Edokter: Thank you. I know I could fix it myself—if I only knew how. So far I didn't know if that was a wrong reference (in 'arrows exception' semi-title OR in the direction indicator 'below') or possibly the 'arrows exception' has been deleted some time ago (and whether it should be restored or the reference removed accordingly) or may be the 'arrows exeption' part was intended to be added but somehow somebody missed it, so it is still absent. That's why I posted my observation here, in hope someone more fluent in English AND in the template history and use will do the work better than me. --CiaPan (talk) 07:32, 13 July 2015 (UTC)

Ah OK. It was probably a reference to a deleted section. At one time, the template supported a multitude of arrows, but which were ususally not found on keyboards, so they were removed. -- [[User:Edokter]] {{talk}} 17:11, 13 July 2015 (UTC)

A more 'key-like' style

I've played around with the border/shadow definitions, and came up with this:

border:        none;
border-radius: 0.1em;
box-shadow:    0.1em -0.1em 0 0.1em #ddd, 
              -0.1em  0.1em 0 0.1em #aaa, 
               0      0     0 0.2em #bbb;

which should be rendered as ⇧ Shift instead of the current ⇧ Shift.
That's more aesthetic style in my opinion, and looks more like a keyboard key. ShoobyD (talk) 16:13, 17 February 2016 (UTC)

That’s almost indistinguishable from ⇧ Shift with simpler

border:        0.2em #ddd solid; 
border-color:  #ddd #ddd #aaa #aaa; 
border-radius: 0.2em;

and less padding. — Christoph Päper 19:50, 17 February 2016 (UTC)

Alternate key press ayntax.

Gh2d2bvs2d ^(talk) 19:44, 1 July 2016 (UTC) Instead of template, just use HTML-style tags? Something like <keypress>Key</keypress>? key press it!

Module:Key

I created Module:Key to fix the post-expand include size template errors at Table of keyboard shortcuts. The module can be called directly, and I have also changed this template to use the module.

Examples using the module directly:

• {{#invoke:key|press|Alt|F10}} → Alt+F10
• {{#invoke:key|press|Alt|F10|chain=-}} → Alt-F10

Example using the template:

• {{key press|A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z}} → A+B+C+D+E+F+G+H+I+J+K+L+M+N+O+P+Q+R+S+T+U+V+W+X+Y+Z

This shows there is no limit to the number of chained characters. However, there must be no missing parameters ({{key press|A|B||D}} would fail). Johnuniq (talk) 04:26, 13 March 2017 (UTC)

bring back symbol-only keys and ISO symbols

I'd like to bring back symbol-only keys ⌘+H as well as add the ISO symbols to the keys (e.g. ⎋ Esc).

Who's the owner of this template/module and would such a change be accepted? I can make the appropriate changes to the LUA code. Tessus (talk) 00:49, 7 October 2017 (UTC)

Of course no one WP:OWNS the page but I wrote Module:Key and I don't have any strong views about what the template outputs. However, please spell out what you mean. Currently these results occur:

• {{key press|Command|H}} → ⌘ Command+H
• {{key press|Cmd|H}} → ⌘ Cmd+H
• {{key press|⌘|H}} → ⌘+H

Are you proposing that some/all of the above would output ⌘+H instead?

Or, would different input give that result?

Or, would a new parameter such as {{key press|⌘|H|kbd=no}} give that result?

If the latter, I don't see why a template would help much since the wikitext can be used directly without needing a template. Johnuniq (talk) 02:45, 7 October 2017 (UTC)

Thanks for getting back to me and sorry that I was not elaborate enough. My bad. Here are a few examples:

symbol-only keys:

• {{key press|Command key|H}} → ⌘+H
• {{key press|Cmd key|H}} → ⌘+H
• {{key press|Option key|H}} → ⌥+H
• {{key press|Opt key|H}} → ⌥+H

Basically, if you add the word key, only the symbol is shown, not the symbol plus the corresponding text (thus the current behavior won't change)

add ISO symbols to keys:

This would change the current representation of some of the current keys.

• {{key press|Esc}} → ⎋ Esc
• {{key press|Del}} → ⌦ Del
• {{key press|Backspace}} → ⌫ Backspace
• {{key press|Home}} → ⇱ Home
• {{key press|PgUp}} → ⇞ PgUp

Most control keys have an ISO symbol associated, thus it would make sense to actually use them. Tessus (talk) 04:08, 7 October 2017 (UTC)

The first set of examples are uncontroversial because they do not change current behavior. All that remains is to identify an article where the shorthand would be beneficial.

The second set of examples would need a strong consensus to implement because they would change current appearance. Further, the point of the template is to represent what a typical keyboard looks like, as done by the current output. There is no point adding symbols which most readers are not familiar with. Johnuniq (talk) 06:37, 7 October 2017 (UTC)

I don't really know where I should start. I don't know how long you've been using key press and mediawiki. I understand some of your concerns, although the argument "people would not be familiar with" is not really valid. e.g. the ⌫ symbol is used on Android keyboards, the other symbols I used as an example are available on older Apple and ISO keyboards. Maybe 15y olds do not know these symbols anymore, but generation X and Y should all be familiar with them.

Also, the symbols do not take away the meaning (since the text is still there as well), and people can get familiar with the symbols as they go along. A learning experience of sorts.

Anyhow, when you look at the following screenshot, you can see how key press used to show symbols and keys.

Someone would expect that features would be added to a template over time, but in this case the key press template lost about 50% of its features and symbols. I don't know why and how this happened, but the current template is less useful than it was 10 years ago. The fact that one can now chain more than 10 characters is nice, but really, who the heck uses key combinations that consist of more than 5 keys?

Please don't take this personal, I'm just puzzled by the loss of symbols and features over time. It just doesn't make any sense to me.

I only wanted to bring back all the goodies this template already had. Tessus (talk) 00:28, 8 October 2017 (UTC)

I emulated what the template did at the time I wrote the module. The module was because the template was used hundreds of times on a list page, and that was causing the page to show many errors due to template limits. Can you identify a version of the template that did what you are referring to? Johnuniq (talk) 01:27, 8 October 2017 (UTC)

I don't really have a version information for the template. I had been using it for a while on some of my wikis which are not public. But here's an export file of the template. Maybe that helps to figure out from when it was. Tessus (talk) 01:45, 8 October 2017 (UTC)

I went to the history of this template and chose the version at 12:28, 25 December 2011, then copied its wikitext to Template:Key press/sandbox. The following shows the result:

• {{key press/sandbox|Command key|H}} → Command key+H
• {{key press/sandbox|Cmd key|H}} → Cmd key+H
• {{key press/sandbox|Option key|H}} → Option key+H
• {{key press/sandbox|Opt key|H}} → Opt key+H
• {{key press/sandbox|Esc}} → Esc
• {{key press/sandbox|Del}} → Del
• {{key press/sandbox|Backspace}} → ← Backspace
• {{key press/sandbox|Home}} → Home
• {{key press/sandbox|PgUp}} → PgUp

That is from nearly six years ago, and it looks like the template then behaves exactly like it does now. Johnuniq (talk) 02:20, 8 October 2017 (UTC)

This is very strange. On my wiki, I get different results. Have you tried to import the template from the xml file? I really have no idea where I got this template from, but I always thought that this was the "official" template (I'm pretty sure that I got it from wikipedia many years ago). Tessus (talk) 02:51, 8 October 2017 (UTC)

Have you seen my last update? I'm still puzzled by my version of the template. I don't understand how I can have a different version. Tessus (talk) 05:57, 19 October 2017 (UTC)

Sorry, but I cannot spend significant time investigating the many issues that I notice at Wikipedia every week. I am not going to import anything or visit a non-Wikipedia website. You could post wikitext inside pre tags at User:Tessus/sandbox and I would be happy to have a very quick look at it. However, you can use the history link I gave above to find the version I mentioned, then edit that version, copy the wikitext, then close the browser window to cancel the edit. Actually, as mentioned I posted that version at Template:Key press/sandbox so you can see it there. Then investigate the differences between your template and the version used above. Johnuniq (talk) 06:55, 19 October 2017 (UTC)

No worries, I know how to change the code so that it does what I want it to do. I just thought that more people would like this code change and have a more standardized key representation (+ additionial keys that were removed for some reason), but I guess I was wrong. I'll update my version of the module and if somebody wants to use my module, they can give me a shout. Cheers. Tessus (talk) 07:01, 19 October 2017 (UTC)

Re: "Currently these results occur" – that seems highly desirable to me, since it means we can use the long version on first occurrence and shorter ones later to not browbeat readers to death with detailia they've already been given. The long versions actually make comprehension more difficult for anyone already familiar with the symbols, since it requires reading a bunch of words. So, here's a big for the current, flexible behavior.

That said, I support having ISO symbols, either as default or as options.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:41, 6 January 2018 (UTC)

JFTR, some of the functionality previously available in this template moved to {{Key top}} in mid-2015. — Christoph Päper 19:43, 7 January 2018 (UTC)

Wikidata

d:Wikidata:Property proposal/Key press — Dispenser 21:39, 20 November 2017 (UTC)

Sizing tweaks

Need some font-size: foo% adjustments for the following:

• ≣ Menu: symbol illegibly small – can't even tell what it is.
• ×: way smaller than the rest of the symbols in the series, due to the quite small X-height of ×
• ○: a bit too small compared to □ and △
• △: should be reduced a bit due to considerably more width than the others in the series.

Getting a nice balance may require some cross-platform testing; see sandbox testcase of the gamepad stuff, at least, at Template talk:PlayStation key press#Character size.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:36, 6 January 2018 (UTC)

This sounds like a font (fallback) issue, but could also indicate that there may be better Unicode characters that could be used, currently:

• menu: U+2263 STRICTLY EQUIVALENT TO
• ex: U+00D7 MULTIPLICATION SIGN
• circle: U+25CB WHITE CIRCLE
• square: U+25A1 WHITE SQUARE
• triangle: U+25B3 WHITE UP-POINTING TRIANGLE

Geometric forms are notoriously disharmonious across fonts and sometimes even within a single font, and there are often many to choose from. — Christoph Päper 19:53, 7 January 2018 (UTC)

Here are some alternatives, but I don't know how widespread support for them is, and these are just the ones that look even in my Unicode font:
Menu: 𝌆, 𝍣, 𑁔, 𝍢.  ≣ Menu is what we use now.
X: ᳵ.  × is what we use now.
Triangles: 🜂  △ is what we use now.
Circles: ჿ, ဝ, ߋ, 𖧋, 𓏸, 𑀞, 𐰗, 𐌏, 〇, ⵔ, ⭘, ◯, ᳃, ᮰.  ○ is what we use now.
Square: ⬜︎, ☐, ▢.  □ is what we use now.
PS: This would also affect the {{Playstation key press}} template; on its talk page I demoed a sandbox version with some hand kerning via CSS, using the original characters, but that may have been a waste of time if they're not going to be consistent. It may be better to pick symbols from the above that seem to be well-supported and we aren't varying much by font. To my eyes, the best options are: the second menu option I found; the original ×, maybe made slightly larger; the original circle maybe made slightly larger, though the first three alternatives look okay (all the rest are either too large, too small, or are raised a bit); and the first alternative square (the current one is faint/thin). These are all rendering in both my reading font, and my coding font in the edit window. — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:09, 8 January 2018 (UTC)

I wonder whether we should consider the respective emojis: 🔼 ⏹️ ⏺️ ❎ (default style), 🔼️ ⏹️️ ⏺️️ ❎️ (emoji style) or 🔼︎ ⏹️︎ ⏺️︎ ❎︎ (text style). — Christoph Päper 21:08, 8 January 2018 (UTC)

The text style ones aren't rendering in either of my fonts, and the graphical ones are all showing up blue except that the × is green. Rather inconsistent with each other, and very much so with the rest of the template output.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  21:34, 9 January 2018 (UTC)

Requested move 8 March 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: No consensus. (closed by non-admin page mover) SITH (talk) 20:21, 4 April 2019 (UTC)

---

• Module:Key → Module:Key press

– Module and template should have the same name {{3x|p}}ery (talk) 23:40, 8 March 2019 (UTC) --Relisting.   samee  converse  20:23, 19 March 2019 (UTC) Initial closure overturned, see continuing discussion below. — xaosflux ^Talk 22:44, 26 March 2019 (UTC)

• Which pillar dictates the name of a module? The reason I used the simple Module:Key name is so the module could be used for anything related that came up. That hasn't been necessary yet, but why mess around with it? Johnuniq (talk) 02:30, 9 March 2019 (UTC)
• Oppose Your vague reasoning "Module and template should have the same name " is not based on any policy, it's just your opinion. Please start an RfC to make it policy first. Also as clearly explained above and elsewhere, the module can be used not only with the Key press template. I would however, be happy to change my mind if there's any policy I am not aware of that already says so.–Ammarpad (talk) 07:26, 9 March 2019 (UTC)
  • Ammarpad, policy doesn't dictate everything on Wikipedia and there's no policy specifically against this, so your argument isn't really helpful here. In fact, there are several guidelines named in the !vote below yours that point towards the rationale pppery is using. cymru.lass (talk • contribs) 20:46, 20 March 2019 (UTC)
• Support per WP:CONSISTENCY and WP:PRECISE and WP:Common sense. While the consistency and precision policies don't strictly pertain outside mainspace, as a matter of practice we apply them site-wide (they commonly comes up at CfD, etc.). There is no reason for us to use a confusingly vague name, or a confusingly different name for the module.  — SMcCandlish ☏ ¢ 😼  21:43, 9 March 2019 (UTC)
• Support - internal consistency is a good thing. cymru.lass (talk • contribs) 20:46, 20 March 2019 (UTC)

To implement the above determination of consensus. SITH (talk) 22:23, 26 March 2019 (UTC)

 Not done @StraussInTheHouse: what? The discussion above is about a module, your edit request is about Template:Key press, are you asking to move the module and to edit the template? I don't see you have worked up this template edit in the sandbox yet and verified test case either. — xaosflux ^Talk 22:41, 26 March 2019 (UTC)

Also the discussion above has multiple opposes, one with a rather convincing rationally. I'm overturning the close and reopening the discussion for further input. — xaosflux ^Talk 22:43, 26 March 2019 (UTC)

• @Johnuniq: can you tell us more about how this is a generic module that has multiple uses? — xaosflux ^Talk 22:45, 26 March 2019 (UTC)

  Xaosflux, fair enough, I considered it to be an okay close but I'm fine with a relist. SITH (talk) 12:00, 27 March 2019 (UTC)

  • @Xaosflux: The module only has a single purpose at the moment. What I meant was that at the time I created the module (in March 2017) I chose to give it a generic name so it could be used for anything that might come up that was related to keys (music? lock? other?). If the module is named "Key press" then we might have squeamish feelings about adding a short function related to "Key" but unrelated to "Key press". I know from long programming experience that using overly precise names for something like a module is unproductive because the future always confounds expectations. The counter argument is that if something does come up, we'll just move the module again (and make all the required fiddly adjustments). That's where my irritation about "make-work" comes in—there simply is no benefit from having Template:Key_press use Module:Key_press instead of Module:Key. However, I don't feel strongly about it and won't make a fuss if someone wants a neat list of templates and modules where the names all align. Johnuniq (talk) 23:41, 26 March 2019 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

How to denote dead keys?

The template doesn't seem to support dead keys overtly and I'm not aware of a well-known convention.

• Example: I want to write "gràve". So I code it as gr`ave.

which works, but I haven't given the reader any clue for what to expect. Some more complicated examples have a combination like AltGr+⇧ Shift+= u ("ų", u with Slavic hook via Chrome OS) The user sees nothing for the initial chord. I notice that some articles explain this behaviour but I wonder if there could be a better way? I can't immediately think of one. This can't be a new thing, has it been done elsewhere? --John Maynard Friedman (talk) 00:12, 7 January 2020 (UTC)

@John Maynard Friedman: Why would it? The template describes key presses, not partial results of those presses. When you say “Press a sequence `a to enter the ‘à’ character” or “Press a sequence ~space to obtain a tilde character (with ~ being a combination of ⇧ Shift+`)” it's obvious the desired character appears after the whole sequence is typed, and I can't see a need to distinguish a role of each key-press separately. --CiaPan (talk) 13:30, 7 January 2020 (UTC)

@CiaPan: It is indeed obvious if you are familiar with the convention. Frequent users of off-keytop symbols are familiar with dead keys and are not phased by the unconventional behaviour. And in my example, if an unquestioning reader does exactly 'monkey see monkey do' then they will have no problem. But if someone expects some feedback for each action and gets none for a dead-key (or worse still, two dead keys), their reaction will be puzzlement and possibly abandonment. I know that was how I reacted the first time I saw it. Maybe it is just me, let's see if anyone else considers it an issue and if so, do they have any ideas. --John Maynard Friedman (talk) 16:51, 7 January 2020 (UTC)

@John Maynard Friedman: I do not know there is any 'convention' here. It's as simple to me as understanding the word sequence: if you say “a sequence”, I know I need to make all described steps to get a result. Just like opening a door, if you say “press the door handle downwards and push the door”, do you feel anyone expects you describe an intermediate state of the handle lowered, but the door not open yet? If you write that description of a sequence of actions, does anyone really need any visual indication (any special graphical mark? a dotted underlining? boldface or thin letters? some colored background?) that the handle's turn does not open the door by itself, and another move is actually needed for a desired result?
Or consider an instruction to make a drink: “take a glass, put an ice cube in it and pour the juice” — is it necessary to say “take a glass, which is empty now, put an ice cube in it, which does not make a drink yet, and pour the juice”...???

If you want to help those unfamiliar with typing, IMHO it's much better to add a short comment after the sequence, something like “Press a sequence `a to enter the ‘à’ character (note the ` is a dead key)”. Or, if you want to be more explicit, “... (note the ` key does not make any visual effect by itself, but it modifies a subsequent a letter)”. That would explain a behavior to beginners without distracting others with varying look of key images. Additionally, it will survive a transfer to another media, e.g. conversion of a Wikipedia page to PDF file or printing it on paper. (Not sure how the key images would convert in screen readers for blind or otherwise visually impaired users, but varying character size or frame width, colors or boldface certainly wouldn't work well.) --CiaPan (talk) 08:57, 10 January 2020 (UTC)

What motivated me to raise this was wp:Readers first. Yes, I have seen articles where the editor has given a running commentary such as you suggest, but it makes it long-winded for readers who are already aware of dead keys and (as noted for example at Talk:Thorn (letter)#Keyboard entry) invites deletion of the whole thing per WP:NOTMANUAL. Your arguments are good ones and I would concede the point except that it would still leave me with the underlying concern that we aren't helping readers as best we can. But if there is no established convention for marking dead keys and we were to just invent one, it would still mean nothing to visitors and we would have wasted a lot of time and energy for nothing. So unless someone comes up with a really clever idea, I'm afraid that my question will have to end up on the cutting room floor. --John Maynard Friedman (talk) 16:55, 10 January 2020 (UTC)

I recall I have posted an invitation to this discussion at the Technical section of Village Pump (now in archives: Wikipedia:Village pump (technical)/Archive 178#Talk - how to indicate dead keys with Template:Key press) but I see nobody came here. --CiaPan (talk) 12:09, 16 March 2020 (UTC)

Is it legitimate to use the template for a sequence of characters?

Is it legitimate to use, e.g., CR+LF to indicate the sequence CR,LF? Is it legitimate to use the template for characters, or only for key strokes? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 28 July 2021 (UTC)

Nothing is really illegitimate so long as it doesn't mislead visitors. The shading is intended to give the impression of a key-top, so it would be a bit odd. I suppose you really should use {{code}} to produce CR+LF. But the plus notation means "press these simultaneously", which I don't think is what you want? Should it be CRLF (using {{key|CR|LF|chain=}}) or CRLF (using {{code|CRLF}})? The latter looks rather odd by modern standards and arguably misleading unless you put a thin space between the R and the L, so a very convincing reason to use {{key}} – so there's your legitimacy defence. wp:BEBOLD, use it then see who complains and why. --John Maynard Friedman (talk) 15:57, 28 July 2021 (UTC)

The font seems to be wrong

Due to poor font selection in this template, on some devices there is no visible difference between O0 and/or |Il.
I think this is a mistake and the font should look something like O0 and I|l instead. (not to mention it currently produces a visual that doesn't even resemble a key on a narrow character, which is also somewhat remedied by using a proper font for the task) — Preceding unsigned comment added by 212.90.73.124 (talk • contribs) 03:26, 29 March 2024 (UTC)

Your examples, slightly rewritten, are:

• {{Keypress|O|0}} → O 0
• {{Keypress|pipe|I|l}} → | I l
• <code>{{Keypress|O|0}}</code> → O 0
• <code>{{Keypress|pipe|I|l}}</code> → | I l

The current template uses (I think) whatever font the user has set as their browser default (or is it set in some MediaWiki style?). The suggestion is that the template should set the same font used for <code>. The current font works well for many cases but the code font is better for the above. Any thoughts? Johnuniq (talk) 04:00, 29 March 2024 (UTC)

Looks good to me. I worried for a moment that it might affect dead-keys but seems fine. See ` (using mono explicitly), which is usually the awkward one as it so small. 𝕁𝕄𝔽 (talk) 08:46, 29 March 2024 (UTC)

If this request gets actioned when the darkmode changes are being done, don't forget to make an exception for "keys with words" (like ⇧ Shift etc). --𝕁𝕄𝔽 (talk) 10:58, 14 July 2024 (UTC)

Dark mode compatibility

This template is currently still showing blackish text on whiteish background in dark mode. @The wub: It looks like you have some specific reasons for setting certain values, based on the comments on Template:Key press/styles.css. This page may have a solution that works for dark mode and the other considerations whatever they might be: mw:Recommendations for night mode compatibility on Wikimedia wikis. -- Beland (talk) 01:20, 14 July 2024 (UTC)