Help talk:Displaying a formula

Indentation rules

Tracked in Phabricator
Task T416809

The most used indentation rule for displaying math is to use a colon such that :<math>E=mc^2</math> renders

$E=mc^{2}$

however if I am reading MOS:INDENT and this page right, we should use two line breaks and <math display=block>E=mc^2</math>

$$E=mc^{2}$$

Is this right? This would require a lot of work to change everywhere. Is this recent? Is there anyway to revert to the previous convention? The colon is shorter and simpler, while the double line break and block display does not indent on mobile, and leads to other problems, specially if text is in the same line. ReyHahn (talk) 11:23, 7 April 2025 (UTC)

• A leading colon is not indentation, it is the definition part of a description list. Using it for indentation produces invalid HTML and is an accessibility error. It has never been correct practice. Lack of indentation and displaying on the same line on mobile is a bug IMO, which I've reported. Hairy Dude (talk) 23:29, 8 February 2026 (UTC)

  There is a lot of wikitext to change if we're going with what MOS:INDENT is currently advising. Furthermore, the behavior of <math display="block"> is not as described here at Help:Displaying a formula#Block. These are not rendered as their own paragraph. You need to add blank lines before and after and between each (see this diff). The rendered result consumes more vertical space than the old technique using colons. Pinging Bkell who has recently made some of these improvements. ~Kvng (talk) 14:52, 16 August 2026 (UTC)

  You shouldn't need to add blank lines before and after each math block. There was a while where there was a bug where they would render malformed HTML, but it was fixed a while back. –jacobolus (t) 16:31, 16 August 2026 (UTC)

  As for the "lot of wikitext to change", this really shouldn't be a priority. Someone can switch from colons to display=block on an occasional article, and after another decade most of them will be converted. The articles won't be much affected either way.

  Using the definition list for this is in theory an abuse of HTML, but in practice it has been working fine for the entire history of Wikipedia and is not a serious problem. It's claimed that we shouldn't use definition lists for this because some screen readers might get confused, but as far as I can tell there aren't any screen readers which have a problem with this which can make any sense of the math blocks when written the other way, so this is mostly also a theoretical concern. –jacobolus (t) 16:40, 16 August 2026 (UTC)

There was recently a somewhat related discussion about chemical equations at Wikipedia talk:Manual of Style/Accessibility#MOS still encourages chemistry articles to indent with colons. I'm not surprised that actual practice differs from the accessibility guidelines, because the colon is much simpler to use and does visually produce an indent. Anything that makes this more straightforward and efficient for editors would be an improvement. Pinging @Scyrme, who might have thoughts on this based on the chemistry article experience. —Myceteae‍🍄‍🟫 (talk) 15:22, 16 August 2026 (UTC)

NB: if the use of colons for indentation is, in fact, an accessibility issue, then this needs to be addressed site-wide, not just in article-space. While most of the MOS only applies to articles, "... provisions related to accessibility apply across the entire project". Colons-as-indentation are used extensively in discussion pages, such as this one. pburka (talk) 03:21, 17 August 2026 (UTC)

Tbh, I've often wondered about this. The colon convention is pervasive and is even encouraged by the reply tool on discussion pages. If it is truly an accessibility issue but one we don't care to enforce, perhaps the recommendation should be downgraded. I don't love the idea of throwing up our hands and saying "this accessibility concern is too hard to manage so just forget about it!" but we shouldn't have policies or guidelines that are contrary to widespread practice. —Myceteae‍🍄‍🟫 (talk) 03:42, 17 August 2026 (UTC)

"The colon convention is pervasive ..."? It may be common in other parts of Wikipedia, but I rarely see in physics-ish articles. Johnjbarton (talk) 22:13, 17 August 2026 (UTC)

It sees widespread use on talk pages and other discussion forums, although the guidance acknowledges this. Less so in articles, but I do encounter it. MOS:CHEMINDENT encourages it, as does the guidance here. I edit chemistry articles from time to time but not enough to say how common this is. I wouldn't call it pervasive in article space. —Myceteae‍🍄‍🟫 (talk) 23:23, 17 August 2026 (UTC)

I see the colons all over the technical articles I work on. I beleive it is much more common than <math display="block">. here's a search if you want to get a feel for it. ~Kvng (talk) 23:23, 18 August 2026 (UTC)

It's an "accessibility issue" in the sense that there exists at least historical screen reader which reads something weird when it encounters a definition list like this. But as far as I can tell most screen readers of a similar age can't make any sense whatsoever of our math blocks, and read a bunch of gibberish regardless. Whenever I've asked about this nobody could give me the actual list of screen reader(s) affected or any idea about the number of their users reading Wikipedia. My impression was that the people who didn't like colons for HTML purity reasons threw up the accessibility thing mostly as a "and here's another reason colons are bad" bullet point in their argument list rather than because they thought it was a serious practical problem. –jacobolus (t) 04:04, 17 August 2026 (UTC)

I'm less concerned with math blocks than with discussions like this one, which are far more pervasive and might effectively block users of those readers from contributing to the project. Given how pervasive colons are (and encouraged by the software), this is probably something that would be better addressed on the rendering side (if it's a real problem at all). pburka (talk) 11:45, 17 August 2026 (UTC)

But do you have a concrete example of such a screen reader? My impression is that the affected software is like 20 years old and not still in wide use. I would expect any still-maintained screen reader is probably tested on Wikipedia or receives bug reports from Wikipedia readers/listeners complaining about the site being inaccessible due to a screen reader oddity, and I would expect old and unmaintained software to no longer be in widespread use.

Maybe that's not accurate, but if so, all I can remember hearing about this is vague handwavey asides without concrete details. –jacobolus (t) 14:23, 17 August 2026 (UTC)

I have no idea if it's a live issue in 2026 or what the extent of the impact is. I'm sensitive to the risk of prematurely dismissing it just because a small group of editors here who don't use screen readers are't aware of a current problem. I think a wider discussion would need to take place at Village Pump or WT:ACCESS. There seems to be a "local" issue here with <math> and a global question of what the usual practice is and should be, and why. If screen readers can't read <math> equations anyway, and the community has accepted this as the preferred way to display equations across the project, then the colon question may indeed be moot here. —Myceteae‍🍄‍🟫 (talk) 15:14, 17 August 2026 (UTC)

It is nice to improve accessibility, but the way to do that is not to have well-meaning Wikipedians make a bunch of changes to articles based on speculation about HTML features. That method is frankly no less dismissive of people's actual needs.

The way to improve accessibility is to ask some screen-reader users (Wikipedia readers and authors or prospective authors) what problems they have with the site and what we could do better to solve their concrete concerns. If we want to get more elaborate, we could recruit a number of participants who use various assistive technologies and get some UX experts (and ideally also the developers of the mediawiki software) to watch them as they use the site, and make up some kind of report of what problems they experienced and then discuss it as a community. –jacobolus (t) 19:06, 17 August 2026 (UTC)

@Jacobolus: I was not saying the change was infeasible due to the extent of the existing colon practice; I just think we should be certain this is what we want before embarking.

I have done some fiddling and find that there is a whitespace sensitivity in the in-browser preview option (the little magnifier button to the right of Show preview). I think this preview option is enabled somewhere in preferences. This is not the only quirk of this preview method so I guess once I know about it, it is tolerable. ~Kvng (talk) 04:46, 17 August 2026 (UTC)

Can you be more explicit? What do you mean by "whitespace sensitivity in the in-browser preview"? –jacobolus (t) 05:27, 17 August 2026 (UTC)

Extra preview and changes buttons. The little magnifier button is the problem.

Misrendering of formulas in Queueing theory updated to use <math display="block"> without addtional whitespace. ~Kvng (talk) 13:33, 17 August 2026 (UTC)

In my browser I don't get this behavior with either the visual editor or the source editor, whether logged in or out. There's definitely some kind of bug going on there. –jacobolus (t) 14:28, 17 August 2026 (UTC)

I usually use Firefox browser but I checked, and I'm getting the same preview result in Chrome. ~Kvng (talk) 14:58, 17 August 2026 (UTC)

The misuse of : is due to the lack of a viable alternative. The closest is {{unbulleted list}}, but it is documented as being limited to nine items and it is not clear whether it can be nested. It don't see any prospects for change without an unbulleted list type in wikitest. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:04, 19 August 2026 (UTC)

I think ease of use and lack of viable alternatives contribute. Ease of use is probably more important. Whether editors think of it as an indent or an unbulleted list—and I suspect more think of it as an indent—there is a single character that accomplishes the desired effect. A number of templates duplicate some or all of the effect but every alternative approach is comparatively fussy. Even the simplest markup is significantly more complex than : and they don't alway work exactly how editors want them to. —Myceteae‍🍄‍🟫 (talk) 15:39, 19 August 2026 (UTC)

{align} vs {aligned}

Is {align} silently being converted to {aligned}? In amsmath LaTeX, {align} can only be used in text-mode, whereas on WP it works even in a sub-expression.

Is it ok to use {aligned}? It seems to work.

If so, should this be stated (for anybody wanting to use the same code for amsmath LaTeX and WP)? catslash (talk) 23:46, 14 May 2025 (UTC)

The question is unclear. By {align} and {aligned} do you mean the align and aligned environments? please show the LaTeX source inside <syntaxhighlight lang=latex>...</syntaxhighlight> or the <math>...</math> wikitext inside <syntaxhighlight lang=wikitext>...</syntaxhighlight>. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:44, 15 May 2025 (UTC)

Yes, the align and aligned environments. The source:

\left .\begin{aligned}a & = b \\
 & = c \\
 & = d \\
 & \phantom = \vdots \\
 & = z \end{aligned} \right\} 25 \text{ lines}

works fine both as wikitext and LaTeX:

$\left.{\begin{aligned}a&=b\\&=c\\&=d\\&{\phantom {=}}\vdots \\&=z\end{aligned}}\right\}25{\text{ lines}}$

Whereas, if aligned is changed to align, then while it still works as wikitext, as LaTeX it gives the error ! Package amsmath Error: Erroneous nesting of equation structures;. catslash (talk) 16:06, 15 May 2025 (UTC)

Could One consequence is that the formula enclosed in the \left ... \right pair cannot have line breaks in the output. be the problem? Do you need anything from amsmath that is not already in LaTeX2ε? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:14, 15 May 2025 (UTC)

It is the amsmath package which supplies the align and aligned environments. Without \usepackage{amsmath} the above code results in ! LaTeX Error: Environment aligned undefined. or ! LaTeX Error: Environment align undefined.. The code works fine with or without the \left ... \right pair. The question is (1) why does it also work with align in wikitext, (2) is there any reason not to use aligned in wikitext, (3) should the help page say that's is ok to use aligned? catslash (talk) 21:11, 15 May 2025 (UTC)

The "explanation" for the message is circular. Have you tried, e.g., stack exchange? What hapens if you remove the NL (\\)? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:35, 16 May 2025 (UTC)

There is no LaTeX proper (or any TeX) in the MediaWiki implementation of TeX. What gets implemented and how they are implemented are solely at the discretion of the developers of Extension:Math, specifically in the WikiTexVC component responsible for TeX parsing/validation and TeX &arr; MathML conversion. Artoria2e5 🌉 13:07, 22 June 2026 (UTC)

Inconsistency between <math> and {math} within page

On Astronomical coordinate systems phi sub o renders differently on MacOS Chrome browser (Version 141.0.7390.108 (Official Build) (arm64)) depending on the whether HTML or Latex formatting context is used. This makes the article confusing because this expression appears in both contexts but the visual appearance is inconsistent.

Inside {math} formatting the character phi does not appear.

ϕ_o, observer's latitude

Inside <math> formatting phi appears correctly.

$\phi _{\text{o}}$, observer's latitude Setikites (talk) 15:53, 19 October 2025 (UTC)

This is almost surely a browser bug or a font configuration error, specifically in how it uses the CSS font fallback list to find a glyph for phi. Artoria2e5 🌉 13:04, 22 June 2026 (UTC)

Dark-mode

I think this Talk page is for the template used in Formula#Chemical_formulas. In dark mode it's not working for me – displaying a white rectangle instead of Butane.

Light mode does work, as does removing the filter (commented out) in the following rule of load.php, which applies to the <img> tag

@media screen {
html.skin-theme-clientpref-night .skin-invert-image img, html.skin-theme-clientpref-night .skin-invert, html.skin-theme-clientpref-night .oo-ui-iconElement-icon:not(.oo-ui-image-progressive):not(.oo-ui-image-destructive):not(.oo-ui-checkboxInputWidget-checkIcon):not(.oo-ui-image-invert):not(.mw-no-invert), html.skin-theme-clientpref-night .oo-ui-indicatorElement-indicator {
	color-scheme: light;
	/* filter: invert(1) hue-rotate(180deg); */
  }
}

I hope this is the right place to repot this. Thanks Tc 13 17 19 (talk) 01:32, 6 November 2025 (UTC)

Recent edit

@Altamediandies: Edit permalink/1335113448 introduce a typo LLaTeX vs. {{math}} and deleted an anchor

<span class="anchor" id="LaTeX vs. math template"></span>

. Was the removal of the anchor deliberate?

— Preceding unsigned comment added by Chatul (talk • contribs) 27 January 2026

A diff link would work better in this case, I think:

Special:Diff/1335113448

CiaPan (talk) 16:35, 27 January 2026 (UTC)

I've reverted the edits for now. There were also a bunch of unhelpful incidental markup changes. –jacobolus (t) 11:22, 28 January 2026 (UTC)

math display="block" failing?

The page g-factor (physics) is incorrectly formatted: the display="block" seems to be rendered as several spaces. The "Block" section on this page has the same problem. Johnjbarton (talk) 02:29, 10 February 2026 (UTC)

It looks fine to me. What kind of rendering do you have set in Special:Preferences § mw-prefsection-rendering? It should be set to "SVG". Other modes are still buggy. –jacobolus (t) 03:33, 10 February 2026 (UTC)

Yes, I have SVG. Hmm. I guess I have to reboot :-( Johnjbarton (talk) 03:47, 10 February 2026 (UTC)

Well rebooting did not fix it. Any other ideas?

mwe-math-element-block in my style sheet is setting the inline. If I disable it with the Inspector the display block is corrected. Johnjbarton (talk) 04:02, 10 February 2026 (UTC)

I'm not entirely sure what you are seeing. Maybe you can take a screenshot? Does it look better if you open an 'incognito' browser tab? Does it look better in a different browser? –jacobolus (t) 07:55, 10 February 2026 (UTC)

Debugging screenshot for a math rendering problem

The problem occurs in a incognito tab is Chrome (Mac OS) but not in Safari on the same machine. Johnjbarton (talk) 22:00, 10 February 2026 (UTC)

Whither TikZ?

§ Diagrams in TeX says Xy-pic (online manual) is the most powerful and general-purpose diagram package in TeX. Surely TikZ deserves mention, and the wording seems to violate WP:NPOV. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:10, 22 April 2026 (UTC)

If the aim is to make the diagram in SVG, then it seems strange to suggest starting with any sort of TeX. catslash (talk) 14:28, 27 April 2026 (UTC)

Commutative diagrams are very simple and usually created directly in people's LaTeX documents, rather than with a separate graphical tool. –jacobolus (t) 14:59, 27 April 2026 (UTC)

This is a help page, not an encyclopedia article. The goal is to give helpful advice, not encyclopedic summary. I don't see how pointing someone at the Tikz manual at https://pgf-tikz.github.io/pgf/pgfmanual.pdf is supposed to help them create a commutative diagram (the topic of the section under discussion). –jacobolus (t) 15:07, 27 April 2026 (UTC)

How about a link to https://ctan.org/pkg/tikz-cd, which uses PGF/TikZ|TikZ? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:29, 27 April 2026 (UTC)

That's probably better. (I don't have much experience here; I haven't made any commutative diagrams for Wikipedia articles.) Also feel free to expand the section with examples, etc. –jacobolus (t) 16:34, 27 April 2026 (UTC)

I've used both, but never for wiki. I've added three examples for both packages. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:01, 28 April 2026 (UTC)

Not quite sure what happened, but now the page is full of "Lua error: too many expensive function calls." –jacobolus (t) 16:24, 28 April 2026 (UTC)

I don't see them. My guess is that it's something in <syntaxhighlightt\s>...</syntaxhighlightt\s>. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:59, 28 April 2026 (UTC)

Try scrolling down to the bottom of the page. It's breaking the citations and some of the external links. –jacobolus (t) 17:58, 28 April 2026 (UTC)

Weird! I tried deleting references and example, and each took the count down by one. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:05, 28 April 2026 (UTC)

Yeah, there's probably just overall too much LaTeX, syntax highlighting, etc. on the page. I wonder if there's a way to get some of it to be cached better and not stress the Lua so much. –jacobolus (t) 19:44, 28 April 2026 (UTC)

References

alignat

Do align and alignat do the same thing or are they different?ACarWP14_TC 20:50, 16 June 2026 (UTC)

They are different. –jacobolus (t) 21:03, 16 June 2026 (UTC)

But what makes them different? Also, what does the second set of curly brackets do in alignat? \begin{alignat}{These brackets}ACarWP14_TC 17:41, 17 June 2026 (UTC)

Page 8 here https://www.ams.org/arc/tex/amsmath/amsldoc.pdf or page 47 here https://tug.ctan.org/obsolete/info/math/voss/mathmode/Mathmode.pdf The basic difference is that alignat doesn't add extra horizontal space, so it can be used to handle trickier situations. –jacobolus (t) 18:10, 17 June 2026 (UTC)

Lua error: too many expensive function calls.

There are eleven of these errors on the page as of the time of writing. On preview MW reports: "It should have less than 500 calls, there are now 514 calls."

Going to trim off a few existence checks from see also first. Artoria2e5 🌉 13:17, 22 June 2026 (UTC)

Additional colors

@~2026-52089-59 I reverted your addition of another table of additional colors and long explanation. Here was the removed material:

The colors shown in this table come from the LaTeX {xcolors} package with the [dvipsnames] option, but the {xcolors} package also includes 19 basic colors available without this option, that is, simply by calling \usepackage{xcolors}. The names of these basic colors begin with a lowercase letter. In LaTeX editor – and similarly on Wikipedia – they are always available for colorizing formulae and differ from the 68 colors provided by the dvips driver. The following table compares them with the dvips colors, where the most similar (or having similar names) are coupled into pairs.

Basic colors from xcolors package of LaTeX compared to those shown above

$\color {Blue}\bullet Blue\color {blue}\bullet blue$	$\color {Red}\bullet Red\color {red}\bullet red$	$\color {Green}\bullet Green\color {green}\bullet green$
$\color {Cyan}\bullet Cyan\color {cyan}\bullet cyan$	$\color {Magenta}\bullet Magenta\color {magenta}\bullet magenta$	$\color {Yellow}\bullet Yellow\color {yellow}\bullet yellow$
$\color {Brown}\bullet Brown\color {brown}\bullet brown$	$\color {LimeGreen}\bullet LimeGreen\color {lime}\bullet lime$	$\color {OliveGreen}\bullet OliveGreen\color {olive}\bullet olive$
$\color {Orange}\bullet Orange\color {orange}\bullet orange$	$\color {Lavender}\bullet Lavender\color {pink}\bullet pink$	$\color {Purple}\bullet Purple\color {purple}\bullet purple$
$\color {TealBlue}\bullet TealBlue\color {teal}\bullet teal$	$\color {Violet}\bullet Violet\color {violet}\bullet violet$	$\color {Black}\bullet Black\color {black}\bullet black$
$\color {Gray}\bullet Gray\color {gray}\bullet gray$	$\color {darkgray}\bullet darkgray\color {lightgray}\bullet lightgray$	$\color {White}\bullet White\color {white}\bullet white$

Even those pairs, which are seemingly identical, like red, yellow, black and white, are in fact different.

I don't think this is worth encouraging people to use, even if it happens to work, especially since many of these lowercase colors are entirely inappropriate for use in Wikipedia (especially lightgray, cyan, yellow, magenta, lime, and pink, but frankly also blue, orange, violet, and red) because they are too light (not enough contrast with the background) and/or excessively chromatic, and as a secondary reason because many of their names don't match their appearance, which is confusing.

If we want to mention this at all, I think it should be a sentence saying to please make sure to use the exact upper-case names, because some lower-case versions of the same keyword have a different undesirable meaning. A detailed explanation about the history/internals of the relevant LaTeX packages seems more distracting than helpful. –jacobolus (t) 23:22, 27 September 2026 (UTC)

I did not describe the history of LaTeX packages, because the {xcolors} package is still available at present and is used by the editors working with LaTeX. These colors can also be used by WP editors and should be described in the help article. There is absolutely no reason to hide them and if someone thinks a color is too light or too saturated, then can not use it. Therefore I restore my edit again. ~2026-52089-59 (talk) 00:06, 28 September 2026 (UTC)

These colors should not ever be used by Wikipedia authors, for any reason. There's not a single one of them that serves a purpose not already met as well or better by the list of upper-case color names, and, as you point out, having a bunch of names that differ only in capitalization but do senselessly different things is incredibly confusing and unhelpful. If someone wants an additional color which is not in the upper-case color list, they should define it as an RGB triple, and we should encourage authors to only do that if none of the existing named colors would work, and only if they can be tasteful about their choices. –jacobolus (t) 02:33, 28 September 2026 (UTC)

Also, as an aside, the new LaTeX rendering mode that mediawiki developers plan to deploy to Wikipedia (which could happen any day now; they threatened to deploy it last week, even though it is still extremely buggy) does not do the same thing with these colors that the previous math rendering mode did. Which is just an extra headache not worth diving into.

Server SVG	Client SVG
$\color {blue}\blacksquare \ {\textbf {blue}}$
$\color {red}\blacksquare \ {\textbf {red}}$
$\color {green}\blacksquare \ {\textbf {green}}$
$\color {cyan}\blacksquare \ {\textbf {cyan}}$
$\color {magenta}\blacksquare \ {\textbf {magenta}}$
$\color {yellow}\blacksquare \ {\textbf {yellow}}$
$\color {brown}\blacksquare \ {\textbf {brown}}$
$\color {lime}\blacksquare \ {\textbf {lime}}$
$\color {olive}\blacksquare \ {\textbf {olive}}$
$\color {orange}\blacksquare \ {\textbf {orange}}$
$\color {pink}\blacksquare \ {\textbf {pink}}$
$\color {purple}\blacksquare \ {\textbf {purple}}$
$\color {teal}\blacksquare \ {\textbf {teal}}$
$\color {violet}\blacksquare \ {\textbf {violet}}$
$\color {black}\blacksquare \ {\textbf {black}}$
$\color {gray}\blacksquare \ {\textbf {gray}}$
$\color {darkgray}\blacksquare \ {\textbf {darkgray}}$
$\color {lightgray}\blacksquare \ {\textbf {lightgray}}$
$\color {white}\blacksquare \ {\textbf {white}}$

–jacobolus (t) 02:50, 28 September 2026 (UTC)

While we're at it, it would probably be worth discouraging a bunch of the upper-case color names as well because they have poor contrast with the site's light background and using them makes our pages unattractive and inaccessible. Does anyone know how to get the RGB coordinates for the existing colors in the list?

And we might want to re-organize the list by color rather than alphabetically. For reference, the upper-case list of supported colors is:

Colors supported

$\color {Apricot}{\text{Apricot}}$	$\color {Aquamarine}{\text{Aquamarine}}$	$\color {Bittersweet}{\text{Bittersweet}}$	$\color {Black}{\text{Black}}$
$\color {Blue}{\text{Blue}}$	$\color {BlueGreen}{\text{BlueGreen}}$	$\color {BlueViolet}{\text{BlueViolet}}$	$\color {BrickRed}{\text{BrickRed}}$
$\color {Brown}{\text{Brown}}$	$\color {BurntOrange}{\text{BurntOrange}}$	$\color {CadetBlue}{\text{CadetBlue}}$	$\color {CarnationPink}{\text{CarnationPink}}$
$\color {Cerulean}{\text{Cerulean}}$	$\color {CornflowerBlue}{\text{CornflowerBlue}}$	$\color {Cyan}{\text{Cyan}}$	$\color {Dandelion}{\text{Dandelion}}$
$\color {DarkOrchid}{\text{DarkOrchid}}$	$\color {Emerald}{\text{Emerald}}$	$\color {ForestGreen}{\text{ForestGreen}}$	$\color {Fuchsia}{\text{Fuchsia}}$
$\color {Goldenrod}{\text{Goldenrod}}$	$\color {gray}{\text{Gray}}$	$\color {Green}{\text{Green}}$	$\color {GreenYellow}{\text{GreenYellow}}$
$\color {JungleGreen}{\text{JungleGreen}}$	$\color {Lavender}{\text{Lavender}}$	$\color {LimeGreen}{\text{LimeGreen}}$	$\color {Magenta}{\text{Magenta}}$
$\color {Mahogany}{\text{Mahogany}}$	$\color {Maroon}{\text{Maroon}}$	$\color {Melon}{\text{Melon}}$	$\color {MidnightBlue}{\text{MidnightBlue}}$
$\color {Mulberry}{\text{Mulberry}}$	$\color {NavyBlue}{\text{NavyBlue}}$	$\color {OliveGreen}{\text{OliveGreen}}$	$\color {Orange}{\text{Orange}}$
$\color {OrangeRed}{\text{OrangeRed}}$	$\color {Orchid}{\text{Orchid}}$	$\color {Peach}{\text{Peach}}$	$\color {Periwinkle}{\text{Periwinkle}}$
$\color {PineGreen}{\text{PineGreen}}$	$\color {Plum}{\text{Plum}}$	$\color {ProcessBlue}{\text{ProcessBlue}}$	$\color {Purple}{\text{Purple}}$
$\color {RawSienna}{\text{RawSienna}}$	$\color {Red}{\text{Red}}$	$\color {RedOrange}{\text{RedOrange}}$	$\color {RedViolet}{\text{RedViolet}}$
$\color {Rhodamine}{\text{Rhodamine}}$	$\color {RoyalBlue}{\text{RoyalBlue}}$	$\color {RoyalPurple}{\text{RoyalPurple}}$	$\color {RubineRed}{\text{RubineRed}}$
$\color {Salmon}{\text{Salmon}}$	$\color {SeaGreen}{\text{SeaGreen}}$	$\color {Sepia}{\text{Sepia}}$	$\color {SkyBlue}{\text{SkyBlue}}$
$\color {SpringGreen}{\text{SpringGreen}}$	$\color {Tan}{\text{Tan}}$	$\color {TealBlue}{\text{TealBlue}}$	$\color {Thistle}{\text{Thistle}}$
$\color {Turquoise}{\text{Turquoise}}$	$\color {Violet}{\text{Violet}}$	$\color {VioletRed}{\text{VioletRed}}$	$\color {White}{\text{White}}$
$\color {WildStrawberry}{\text{WildStrawberry}}$	$\color {Yellow}{\text{Yellow}}$	$\color {YellowGreen}{\text{YellowGreen}}$	$\color {YellowOrange}{\text{YellowOrange}}$

–jacobolus (t) 23:33, 27 September 2026 (UTC)

@Jacobolus We can recommend some set of colors for use in mathematical formulae, but all colors available should be listed in this article. ~2026-52089-59 (talk) 00:23, 28 September 2026 (UTC)

First, you must stop revert warring. If you can build consensus for your change, we can include it.

I don't at all agree with your edit. This help page has listed the same list of colors for the past 15 years (since 2011), and for years before that linked to a PDF document containing the same list. Nobody has been missing these additional (bad) lower-case keyword colors, and as far as I can tell they are not being used in any non-accidental way on Wikipedia.

Listing them here is a suggestion that they can be used, and authors will then do so. But that's a bad idea which we do not want to condone, let alone encourage. Again, we could mention to authors to make sure to capitalize correctly because some keywords have lower-case variants which do the wrong thing, and if you want, we can put a list in a footnote along with a warning not to use them. If you like, the footnote can even include a sentence or two about obscure LaTeX package history/trivia. –jacobolus (t) 02:29, 28 September 2026 (UTC)