Wikipedia talk:Manual of Style/Superscripts and subscripts

Proposed MoS guideline

Note: the content on this page is not something I made up, it's merely a compilation of guidelines from various MoS pages aimed to let the reader get an overview. jonkerz♠ 11:26, 17 August 2010 (UTC)

Which means it's something somebody else made up.

It's bad enough having these expressions of prejudice at all, without having a separate page for them, which will evolve separately from the rest of MOS as some Secret Master of Wikipedia takes seizin of it.

The first sentence is ungrammatical; the rules are largely arbitrary; and anybody who's interested in formating mathematics or music will be looking at WP:MOSMATH and WP:MOSMUSIC anyway.

Remove the silly general rules here and where you found them; and send the subject sections back to the relevant subjects. Septentrionalis PMAnderson 14:48, 17 August 2010 (UTC)

I agree. There's no reason for this to exist as a separate page: each paragraph of it belongs somewhere else. A. di M. (talk) 15:12, 18 August 2010 (UTC)

I see your point, but do not agree with your conclusion. My reasoning for creating this page was because all sup/subscript guidelines are scattered over multiple pages, this page is intended for ease of navigation. If you're interested in how to format music, you go to WP:MOSMUSIC, if you would like to know how to format superscripts you go here. Similar pages include Wikipedia:Manual of Style (abbreviations) and Wikipedia:Manual of Style (capital letters). I guess it's a matter of opinion: some go to WP:MOSMUSIC to figure out how to handle a specific music-related problem, some go there to learn how to format music articles in general. Likewise, this page is will teach how to format sub/superscripts in general. That said, I understand if this is a minority point of view and this page should not be included in the manual. jonkerz♠ 09:41, 19 August 2010 (UTC)

If this page to be used, it should itself be made MOS-compliant with regards to the accessibility guidelines, namely WP:COLOR - the "correctness" of some of the examples is indicated by colour alone, and note that coloured text should really only be used if there's a pressing reason to do so. Knepflerle (talk) 16:35, 17 August 2010 (UTC)

If you were refering to the comparison in the lead, it's now fixed. jonkerz♠ 09:45, 19 August 2010 (UTC)

Apply to article title?

Do these guidelines apply to article titles? Could it explain why (or why not)? Thank you. Regards, RJH (talk) 21:30, 12 July 2012 (UTC)

Done use the characters like "²" in the title, but don't use  tags either, instead use {{DISPALYTITLE:}} to make it look right. Graeme Bartlett (talk) 11:28, 9 September 2019 (UTC)

Lost semantic integrity

I'm pretty surprised of this guideline: the semantic integrity of the super/subscript is lost to favour rendering hacks. The real meaning is lost by using <sup> or <sub>: when copy-pasting the example wⁱx²z^{(n + 6)} [w{{sup|i}}x{{sup|2}}z{{sup|(n + 6)}}] you end up with wix2z(n + 6) while the unicode wⁱx²z⁽ⁿ⁺⁶⁾ stays wⁱx²z⁽ⁿ⁺⁶⁾. Presentation shortcomings should be treated separately (by using a different font or by automatically enlarging/shifting sub/superscript to a more visible size, I don't know precisely, I'm no expert) Plus the wikitext is easier to edit in unicode. It's not 2010 anymore, unicode support is great everywhere!--Marc Lacoste (talk) 09:43, 9 September 2019 (UTC)

Unicode causes many complications, for example in my browser I cannot type those suffix Unicode characters and I only know to copy and paste them from elsewhere. Also searching for "2" does not find "²". The Wikipedia search treats "²" as if it didn't exist, though a regex search can spot it. Graeme Bartlett (talk) 11:26, 9 September 2019 (UTC)

Thanks for your reply. Of course we can't have all thousands of Unicode characters on our keyboards, but they are available by many other means, most ostensibly the insert section at the bottom of this edit window. And searching for "2" (two) should not find "²" (square), they do not have the same meaning. The Wikipedia search should be fixed, but it is a problem of its own.--Marc Lacoste (talk) 13:26, 9 September 2019 (UTC)

More in Unicode subscripts and superscripts. So, the font designers are dumb, but we continue to use <sup>/<sub> hacks instead of switching to a more sane font?--Marc Lacoste (talk) 13:34, 9 September 2019 (UTC)

More than one year after, we're still not in the future yet.--Marc Lacoste (talk) 09:16, 29 December 2020 (UTC)

Unicode superscripts and subscripts are long gone from modern typesetting. This isn't the 90s anymore. Headbomb {t · c · p · b} 21:35, 9 May 2021 (UTC)

I'd love to be proven wrong and enlightened, but as I see it currently, I beg to differ. I doubt "modern typesetting" involves using the HTML <sub>/<sup> tags. Browsers just take the ordinal digits and make them smaller, which is already wrong. The Unicode subscript and superscript numerals are styled differently from the ordinal digits. Fonts that employ old-style numerals by default with descenders and ascenders (and miniature 0,1,2) use the even-sized tabulating numerals for its sub/sups. The forms are then adjusted for clarity and consistency, the strokes are proportionately thicker, serifs are reduced or even absent, and they have their own kerning and layout rules. Dumping all that logic out to the browser's HTML renderer is just silly in 2022. Sensible semantic search results are solvable problems using appropriate Unicode equivalence and text normalisation rules in the search engine. I agree with Marc Lacoste (talk · contribs) that this part of the MOS should be reconsidered. It is inconsistent with how most modern fonts work, produces ugly typography, and conflicts with use of Unicode elsewhere in Wikipedia (e.g. ♭, ♮ and ♯ symbols in music articles). Anyone needing to routinely type all these sorts of characters can use a compose key; it has eleventeen bazillion shortcuts by default in Linux, and there's WinCompose (open source) which gives you the same thing in Windows, instead of horsing around trying to remember loads of obscure 4 digit numbers, and there's bound to be something on a Mac (I have no idea, sorry, good luck with that). For instance, I can type ₂ using the following key strokes: [RAlt] [_] [2] and similarly, [RAlt] [~] [n] produces ñ. Anyway, I think in the last several years, there has been a lot of progress and change in the uptake of Unicode both within Wikipedia and everywhere else. — Jon (talk) 23:34, 16 March 2022 (UTC)

Pick any modern professional word-processing software, HTML-editor, or other professional typesetting editors (such as LaTeX-based editors), when you select the superscript function, what you get is the regular characters raised and shrinked, not converted to corresponding unicode entities. Unicode entities have long been deprecated on Wikipedia and elsewhere, let's not re-introduce them. As for searching for "2" (two) should not find "²" (square), they do not have the same meaning, it should, because both mean 2. 2 does not differ in meaning depending on its position. 2 means 2 in 22, 1/2, 3², ²√134 or a₂ = 1.375. Headbomb {t · c · p · b} 00:00, 17 March 2022 (UTC)

Add exception to allow Unicode super/subscripts in COinS fields in {{cite xxx}} templates?

Several fields in the various {{cite xxx}} templates ({{cite book}}, {{cite journal}}, etc.) generate COinS metadata. The documentation for these templates warn against using templates, HTML, or HTML entities within these fields, because raw HTML will get generated and pollute the COinS data. In these cases, the Unicode superscript/subscript entities should be allowed.

This doesn't happen very often, but sometimes appears in the title= field of journal citations in chemistry-related articles, when the journal entry is about a specific chemical or chemical formula. sbb (talk) 01:41, 23 March 2021 (UTC)

No. There should be no exception, anywhere, unless these are specifically about the unicode characters themselves. If there's a metadata issue, fix how metadata is emitted. Headbomb {t · c · p · b} 01:45, 23 March 2021 (UTC)

The outcome of Help talk:Citation Style 1/Archive 80#HTML markup seems to be that we don't make an exception for footnotes, and templates are expected to clean up COinS output as needed. -- Beland (talk) 22:47, 3 December 2021 (UTC)

Yeah, I've been following that discussion a bit. I should have closed the loop here. Thanks for doing that for me, and thanks for driving that whole issue forward. Cheers. =)  — sbb (talk) 18:19, 17 December 2021 (UTC)

Degree symbol

@Headbomb: Greetings! Regarding this revert: what is the purpose for keeping the mention of &deg; as a way to make the symbol for diminished cord? In order to avoid requiring editors to be familiar with HTML entity syntax in addition to other wikitext syntax, a few months or perhaps years ago I went around and changed all of those HTML entities to the Unicode character. If we tell people to keep using the HTML entity, that just makes more work of having to go around and change those instances later. The degree symbol is also available right in the edit window on desktop browsers, which isn't mentioned.

Looking deeper into this style recommendation, I see that Wikipedia:Manual of Style/Music#Images and notation actually also recommends {{music|diminished}} or {{music|dim}}. It seems to me that would actually be a much better ASCII-only option, as it conveys the semantic meaning and lets editors find documentation on the template page. It would also make it easier for spell-checking bots to distinguish the musical notation from malformed attempts to use the degree symbol for angle or temperature and superscript "o" for the masculine ordinal. -- Beland (talk) 07:39, 3 January 2022 (UTC)

The purpose is to have an easy way of writing it that doesn't involve remember complex keyboard shortcuts or figuring out where in the interface the degree sign is hiding. No different than mentioning the &ndash; and &mdash; entities for – and —. As for this creating "more work", this isn't something that needs to be fixed in the first place, and ease of editing takes priority over other concerns. Headbomb {t · c · p · b} 14:42, 3 January 2022 (UTC)

@Headbomb: Doesn't {{music}} satisfy the requirement to provide an easy way of making the character without keyboard shortcuts or clicking through menus? Isn't it easier for editors compared to HTML entity syntax which references a word ("degree") unrelated to the diminished chord semantic? -- Beland (talk) 21:09, 8 January 2022 (UTC)

Not the point. &deg; is simple and familiar to many people, and will work in on any HTML page. {{music}} is a Wikipedia-specific template that requires reading documentation to figure out what to do with it. People are free to use whichever method they want to produce the desired output. Headbomb {t · c · p · b} 21:17, 8 January 2022 (UTC)

@Headbomb: Anyone who already knows how to use &deg; can still use it. No editors will encounter that markup in articles, because all instances have been converted to the raw Unicode character. What is the point of telling Wikipedia editors who haven't heard of it that they can use it on music pages? The vast majority of people familiar with the topic of music (and most topics) are not be familiar with HTML, which is the whole point of why Wikipedia uses wikitext markup (which it considers easier to learn) instead of HTML. -- Beland (talk) 01:28, 5 February 2022 (UTC)

"What is the point of telling Wikipedia editors who haven't heard of it that they can use it on music pages?" What's the point of telling anyone anything? It's a valid input option, one that is extremely easy to do, and thus should be mentioned. Headbomb {t · c · p · b} 14:50, 5 February 2022 (UTC)

@Headbomb: But {{music}} is also valid and easy. Why not just tell editors who haven't heard of either method about that one, which is undisputed and semantically related to the markup, instead of only telling them about the easy but disputed method which is semantically unrelated? -- Beland (talk) 23:50, 13 February 2022 (UTC)

Only you are disputing it. Both methods are equally valid and equally correct. Headbomb {t · c · p · b} 23:54, 13 February 2022 (UTC)