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)

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)