Wikipedia talk:Manual of Style/Mathematics

Markup for math variables

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Text formatting#Mathematics variables section is wrong and needs updating

Indenting

@SMcCandlish: I object to using {{in5}}, which uses multiple nonbreaking spaces to indent what follows, for indenting displayed math content. Unfortunately, the "obvious" <math style="margin-left:2em"> doesn't seem to be supported (perhaps a Phabricator task should be opened about this?). A simple TeX-based solution would be to start the math content with an initial "\quad\ " (a quad followed by a space):

$\quad \ \int _{0}^{\pi }\sin x\,dx$

Colon-provided indent, for comparison.

There might be a better (if not more convenient) TeX-based solution if I thought about / researched it a bit. Opinions? Suggestions? - dcljr (talk) 06:19, 2 December 2017 (UTC)

Then do that. Just don't given wrong HTML advice. PS: There's nothing wrong or objectionable about what I wrote; MoS doesn't care at all about non-rendered whitespace in wikicode, and there's nothing invalid about it. We do not have a rule to compress away whitespace in wikicode, and shouldn't have one, since we often use it to good effect. For every person who would object to the version I use there are probably 1+ who prefer it because it makes it easier to find the math markup in the source. I don't really care either way as long as we stop mis-advising abuse of list markup for non-lists, which is an accessibility problem.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:24, 2 December 2017 (UTC)

(Ignoring your second sentence, which makes it sound like I'm the one who was giving editors the "wrong" advice…) There is actually something very wrong with the {{in5}} approach. Look at the HTML it actually outputs: "<p>&#160; &#160; &#160;" (alternating non-breaking and regular spaces). This means long math content can actually be bumped to the next line, resulting in no indenting at all. In any case, I'm glad you see my suggestion as a viable alternative. What say other users? (In the meantime, shall we revert your change, SMcCandlish, until a better approach is found?) - dcljr (talk) 06:46, 2 December 2017 (UTC)

Then fix the template or use a different one. No-wrapping the spaces that template uses is a trivial fix, and there's probably another one that more sensibly does this with CSS padding. The point is, do something other that abuse of list markup. No, we shouldn't revert it, because abuse of list markup like that is, well, abusive, while the consequence of a long math content wrapping to a new line without an indent is just a line without an indent which isn't invalid, just not perfect. I've asked the Lua handlers of {{in5}} to fix the wrapping issue.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:35, 2 December 2017 (UTC)

Oh, duh. I actually wrote the ideal template for this, and forgot: {{blockindent}}. Just tried that, and it works fine. No blank line needed, either. (I created this originally as a {{blockquote}} replacement for material that isn't a quotation).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:38, 2 December 2017 (UTC)

The standard way to indent in mathematics articles is to use colons, and this page should reflect that. I am not sure I know of any math article that uses templates for indenting displayed math formulas. The HTML generated is irrelevant to this point - "colon" in wikitext means "indent", not "dd", and at any point Mediawiki could switch from "dd" to anything else that achieves an indentation. It is not in any way an abuse of wikitext to use colons to indent content. — Carl (CBM · talk) 15:08, 2 December 2017 (UTC)

Using something other than a colon is probably semantically better, but it's hard to see justifying the change at this point. On a different but related topic, I was wondering about the practice of having blank lines before and after indented equations. Doing so seems to help readability while editing, but again, semantically it would seem to be wrong, because it indicates paragraph breaks where there shouldn't be any. I don't know of a good way around this, but maybe it's worth thinking about along with the above. –Deacon Vorbis (carbon • videos) 15:27, 2 December 2017 (UTC)

I would agree about the spacing issue if the blank lines had an effect on page spacing, but I don't think they do, looking at the source of this from my sandbox: [1]. In general displayed math should not start a new textual paragraph, of course.

Regarding the colons, I think the key issue is that semantically, colons mean "indent" in wikicode. So the concern is not with the semantics of the wikicode but with the current implementation of those semantics, which is not an issue I think we need to worry about as editors. But moreover the very well established standard is to use colons, not some other template, for indenting displayed math. — Carl (CBM · talk) 15:36, 2 December 2017 (UTC)

Er, well, actually colon means "here is the definition part of a definition list". It just happens to be the case that that meaning causes things to be indented. I think that "indent something" is far more frequent than "definition part of a definition list" as the intended meaning by the editors using it, and that it would be a good idea for the Wikimedia engine to use semantic coding that reflects that, but it doesn't. In the meantime, if you want semantic purity, there's always <math display="block">, e.g.

$$E=mc^{2}$$

(But there is no way that I know of to use that to get more than one indent, e.g. to match the indentation of this comment.) —David Eppstein (talk) 03:11, 3 December 2017 (UTC)

Yes. It definitely does not mean indent; we just abuse it for that on talk pages because we're lazy.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:50, 3 December 2017 (UTC)

Depends on what you're trying to do. For what we've been talking about:

{{block indent|1=Your math here.}}
{{block indent|{{block indent|1=Further-indented math here.}}}}
emits:

Your math here.

Further-indented math here.

For simple stuff (but requires either a blank line or a <br /> preceding it, and indents less by default):
{{in5}}Your math here.<br />
{{in5}}{{in5}}Further-indented math here.<br />
or
{{in5|10}}Further-indented math again.<br />
yields:
     Your math here.
          Further-indented math here.
or
          Further-indented math again.

Neither of these produce bogus list markup, but the {{in5}} stuff can wrap such that the math is non-indented, as someone noted above, if the math content is long (or the viewport is tiny). There are also other indentation templates, but they are also space-based like {{in5}}. The most robust is the {{block indent}} approach.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:50, 3 December 2017 (UTC)

PS: You can also use {{block indent|left=X}} where X is an value in em units, to change the indent spacing (e.g. to make it match regular list indentation instead of blockquote indentation, or to indent further instead of using a block indent nested in a block indent. Another approach to the first example would be to open a block indent, put the first math, then do another block indent, do the extra-indented math, then close both block indents. That would be "cleaner", unless you need some non-indented text between the indented and extra-indented material, e.g. to introduce the second example.

I'm not sure why you'd want to have math examples indented to different levels in the first place, though.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:54, 3 December 2017 (UTC)

I think David E. buried the lead a bit: it appears that <math display="block"> is exactly what we've been looking for. Getting it to be generally accepted by editors is, of course, a totally different matter. I agree (with the implication of SMcCandlish's last comment) that indenting displayed math beyond one level is probably a relatively rare requirement in articles, but I imagine there are probably several legit examples lying around. In those cases, {{block indent}} looks like an acceptable approach:

$f(x)=|x|$

(assuming, of course, that it's not more appropriate to handle the formatting inside the TeX content itself).

BTW, the template-inside-template approach shown above to get further indenting is not necessary, since {{block indent}} has an em parameter to control how far to go (in ems, of course):

{{block indent|em=4|<math>f(x)=|x|</math>}}

$f(x)=|x|$

Yay. - dcljr (talk) 08:16, 3 December 2017 (UTC)

• Comment. Please note that changes such as this, which mandate a different way than the norm for all mathematics articles out there, including all mathematics featured articles and good articles, requires very strong consensus. The last time this issue was raised at WT:WPM, there was no consensus for a change. Similarly to this discussion, the change was imperialistically imposed on high by editors who do not routinely need to edit mathematics articles. Templates and display blocks are simply not as convenient for editors as colons, which have been used for indentation in Wikipedia since the very early days. (See WP:INDENTATION, Help:Talk, as well as the history of this guideline.) Even the alleged "violation" of WP:ACCESS is spurious: "This is not ideal for accessibility or semantics, but is currently in wide use." That guideline then gives guidance on how to use colons for indentation purposes! Consensus should be established with a formal RfC, as I said the last timme this issue was raised. Sławomir Biały (talk) 12:39, 3 December 2017 (UTC)

A couple further quick observations: If you're manually setting the indentation size (like the 4em above), you're almost surely doing it wrong. If any change is made, it should probably produce something that's at least very close to what a colon produces. Otherwise, we'll have pages with mixed amount of indentation as new stuff is added. Alternatively, someone could come up with a very thoroughly tested solution for converting automatically. –Deacon Vorbis (carbon • videos) 13:02, 3 December 2017 (UTC)

It it also very easy to find featured articles, such as Californium, which use colons for indentation. That is the standard way of indenting displayed formulas, is the only way in Help:Wikitext, and is explicitly allowed by WP:ACCESS. The real solution to access issues is get the developers to stop Mediawiki emitting dd/dl lists when colons are used for indentation, rather than trying to avoid using indentation wikicode to indent things in wikicode. In general, though, if we are looking at the HTML being emitted, we are doing it wrong. Editors work with wikicode, and the the HTML is the problem of the developers. — Carl (CBM · talk) 13:33, 3 December 2017 (UTC)

WP:OTHERSTUFF and WP:NODEADLINE.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:37, 3 December 2017 (UTC)

@SMcCandlish: I think Carl's remarks are entirely relevant and do not raise the spectre of WP:OTHERSTUFF. OTOH, your repeated reverting of the project page back to your preferred version suggests you think there is a DEADLINE in getting these guidelines changed. Please try to gain some kind of consensus before making such a major change to the guidelines. (Yes, I see the VP discussion linked below.) @Deacon Vorbis: The specific "4em" example I used above was only to get the mathematics at the third level of indenting. I assume that "almost never" happens in articles. @CBM: Considering the HTML that actually gets generated can help to decide which wikicode approach is better than another, or whether an approach can be improved (as just happened with the {{in5}} template/module). As for developer-involved solutions, I think a more realistic approach (rather than deprecating or reimplementing colon-indenting) may be to work towards a <math>-only solution for indenting mathematical content in particular. I've opened a new subsection for this below. - dcljr (talk) 11:36, 4 December 2017 (UTC)

Accessibility versus convenience in indentation (RfC at VPPOL)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:37, 3 December 2017 (UTC)

Extending math element functionality

Like I said above (although not to this level of precision), just using display="block" seems to give exactly the same indenting as a single colon (does anyone see otherwise?):

$|x|$

$$|x|$$ These are, respectively, coded as:

• :<math>|x|</math>
• <math display="block">|x|</math>

This tells me that it is not unreasonable to consider implementing the indenting of math content with the display="block" approach. (Again, as I suggested above, having the option and requiring it are two different things. Here I'm discussing having the option to indent in the math element itself. Also remember that MediaWiki features are used in wikis other than those hosted by the Wikimedia Foundation. Mathematically oriented wikis may actually like the idea of colon-less indenting of math content.)

Unfortunately, the way display="block" is currently implemented appears to result in bad HTML: paragraph opened before a <div> element then closed after it. Given this, I'm not sure I understand what the thinking was when the feature was originally proposed/implemented (since "displayed" math [in the TeX sense] almost always occurs inside a paragraph, yet a <div> element cannot). Perhaps someone knows where this was discussed? The only thing I've been able to find is mw:Extension:Math/Displaystyle, which doesn't have any real discussion.

Another, more serious, problem is that the page I just linked to reveals that on the MediaWiki wiki, display="block" results in centered displayed math (just like in TeX), not displayed math indented to the level of one colon! (Waaah…)

Notwithstanding all of the above, indenting to the level of however-many colons could be implemented in the <math> element with new syntax. This very idea came up back in December 2008 (phab:T18829) and was quickly nixed (within 14 hours!) by a developer (Brion, the only other user to comment on the bug), but opinions can change in 9 years, so maybe the idea would not be dismissed out of hand if some kind of consensus were reached about what the syntax might look like.

The proposer in 2008 seemed to be suggesting:

• <math indent=number>

where number is the number of "colons" of indenting to apply (0 would mean no indenting, which the proposer said would be the default and mean inline display — I would lean toward having 0 mean non-indented but still "displayed" math [i.e., after a line break]).

Another possibility is to put it inside the display attribute:

• <math display="indent">

for displayed math with one-level indent;

• <math display="indent:number">

for displayed math with number-level indent (0 or more, 0 meaning aligned to left margin).

I could probably come up with other possibilities, but I've been typing this up for an insane amount of time already. I need to go to sleep. - dcljr (talk) 11:36, 4 December 2017 (UTC)

In principle I do not object to mentioning <math display="block">, but share your concern that if this is supposed to be the solution that leads to completely valid html, that it might fail at that. Sławomir Biały (talk) 11:41, 4 December 2017 (UTC)

Re "Perhaps someone knows where this was discussed?": https://phabricator.wikimedia.org/T111712, I think, and before that at Wikipedia:VisualEditor/Feedback/Archive 2015 3#Indentation for mathematical equations. —David Eppstein (talk) 11:44, 4 December 2017 (UTC)

Yep, there it is… lots of prior discussion. [grin] For the record, there is also phab:T6521 for discussion about changing the way MW handles colon-indenting and semicolon-bolding outside the context of a deflist.

Interestingly, phab:T111712 mentions the possibility of creating:

• <dmath>

as an abbreviation for <math display="block">, an approach I think is particularly promising. Someone else (in the task) objected to creating a new tag, but I think it's a pretty neat solution. The new tag could then be used along with sitewide style sheets to style displayed math as either indented or centered, as desired by the wiki (IOW, whichever alignment is chosen as the "default default", a wiki could change it to the other default alignment in their site's CSS).

And then

• <imath>

could be created for inline math (display="inline"), and no already existing uses of <math> would need to be changed to get the benefit of the kinds of "logical" changes people have wanted to make to the behavior of <math> (e.g., that inline math should use inline styling by default, and displayed math should use display styling — this change would bring wikicode math much closer to the way TeX/LaTeX does it, which many technical folks would likely welcome). All current math content would continue to work the same way it does now, and instances of <math> could be slowly changed to <imath> or <dmath>, as appropriate, in the normal course of editing. (The <math> tag would remain a viable option into the future.) Unfortunately, I have no idea whether having three different tags as "entry points" to the same underlying code would cause any kind of problem from the developers' side. I would hope not. (Note that the display="block" and display="inline" functionality already exists. The change would be the use of the new tags and having different defaults for the two situations.) - dcljr (talk) 23:25, 4 December 2017 (UTC)

Something like this sounds like a great idea. It would be better to do it with CSS indentation (demoed here with margin:left) rather than by changing the content type to a block element, since we can't guarantee the context; a block element wouldn't be valid inside an inline element like <span>...</span>.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:14, 11 December 2017 (UTC)

Probably it would be easier just for Math to nix the opening paragraph HTML when it's in display form. I submitted phab:T182041 for that issue. As for display math, I think it makes more sense to do something like phab:T182673 which I submitted today. I dislike the imath solution because it a) adds tags for the same semantic information and b) because the solution should work with chem as well as math without an even larger number of tags. --Izno (talk) 12:47, 12 December 2017 (UTC)

Good point.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:52, 12 December 2017 (UTC)

This is an idea, but it requires things to be in math tags, while of course many formulas are formatted in plain wikitext, because of article-by-article decisions. For example, the display in californium ("History"). We also have to be careful, technically, with displayed equations that have math tags and additional text outside of math tags, as in ROT13 ("Description"). I think that fixing the output for colons in Mediawiki seems like a more comprehensive solution, because that would fit many more use cases, compared to looking just at the math tag. — Carl (CBM · talk) 13:11, 12 December 2017 (UTC)

Surely true, but after a decade, it seems clear there's a great inertia with regard to the colon/dd markup, and it's probably easier to get <math> and <chem> adjusted.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:52, 12 December 2017 (UTC)

WP:NODEADLINE. There is no reason to rush an incomplete fix. But we can and should encourage the developers to fix the more general problem with the HTML that is being emitted. — Carl (CBM · talk) 16:09, 12 December 2017 (UTC)

Oh, I agree, but it's unlikely to happen quickly if it all, and it's no excuse to use bad markup in the interim. I am happy to see some traction on the : Phabricator ticket for the first time in years but they keep saying, basically, "it's hard" which generally translates to "WONTFIX", either formally or through perpetual inaction.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:47, 12 December 2017 (UTC)

It appears extremely unlikely that the Phab ticket is over going to be acted upon. "It's too hard", basically.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:57, 20 December 2017 (UTC)

I think <math display="block"> is the way to go. It gets centered by default, but this was changed on common.css (see Wikipedia talk:WikiProject Mathematics/Archive/2015/Sep#Styling of block mode display of math formula). Helder 12:59, 26 December 2017 (UTC)

Please add explicit guidance re markup vs. special characters

Hello.

I propose/request that the MOS be amended to include explicit guidance regarding the use of markup versus special characters when editing mathematical formulas.

The MOS currently gives guidance for specific cases of similar situations. For example, it prefers <sup>2</sup> instead of ². It does not, however, address the possibility that an editor might directly enter the "special" character itself: ². This markup-versus-special issue is the subject I request be addressed.

By providing the "Special characters" toolbar, which directly inserts hard-to-type characters into the wikitext, Wikipedia seems to favor that approach over markup. I find this problematic.

The "toolbar" method requires the editor to search for and identify the desired character by eye alone. This effort is difficult.

• There is often no easily-recognizable strict total order on the set of symbol characters. It is not even clear within which category to search. (Is the "sigma" I want in category "Greek," "Greek extended," or "Symbols?")
• Even worse, can my sigma appear under multiple categories, suggesting that the correct choice of category depends on the character's semantic function? For example, if I wrote an article about a mathematician from Athens, would I need to use sigma from one toolbar category when specifying his name, and sigma from a distinct toolbar category when typesetting the formula he produced? Likewise, the toolbar offers "↑". Is that supposed to mean Knuth's up-arrow notation, or is it just a dingbat? Is there even a difference? Can this situation even happen?
• Even if the editor knows where to look, some characters are difficult to distinguish visually. Consider Ö and Ő and Ố.
• The above problems do not easily abate as the editor gains experience. Even if I know I want Knuth's notation, there is no way for me to quickly specify it.

The consequence of this difficulty is editor fatigue, and therefore editor carelessness. Editors who want beta will just use ß (Eszett) if they find it first. In the long term, I am concerned that "emojification" of Wikipedia's mathematics content will create ambiguity and decrease the value of articles. (See Emoji#Emoji_communications_problems.)

The alternative to the "toolbar" method is markup using one of the supported languages such as HTML or <math>. This eliminates the ambiguity problem (ala β), but has the disadvantage of a steep learning curve. I suppose that my preference for the direction of guidance is clear, but my aim in writing today is to gain clarity for myself and other editors, not to promote my particular opinion.

To summarize, I request that the MOS

1. clarify whether or not (English) Wikipedia has a preference regarding markup versus special characters, and if so, specify what that preference is.
2. clarify whether editors should or should not observe a semantic difference between symbols/characters used in formulas and used elsewhere.
3. advise that this guidance concerns an advanced editing technicality, and that inexperienced editors should not allow it to dissuade their participation. (A WikiGnome will come along to fix any mistakes.)

Thank you,

Christopher Ursich (talk) 00:31, 19 February 2018 (UTC)

Um, Christopher, you don't have to use bold on every link. In fact, please don't make links bold unless there's some particular reason to emphasize them. - dcljr (talk) 04:11, 20 February 2018 (UTC)

The preference for explicit superscripts over the superscript-2 character has nothing to do with how it is marked up. It is because the character doesn't match other superscripts; e.g. ''x''⁵''y''² comes out as x⁵y² which (at least in my view) has the 2 tiny and squished into its variable compared to the 5. So you should not use this character regardless of whether you type it directly or use the html entity. For the same reason, for characters that are ok to use directly, it should not matter whether you type them or name them. I think we should not express a preference for one way or the other, and in fact more strongly I think we should discourage editors from changing one way to the other or vice versa, because it is a useless waste of time for them to do so and a useless waste of time for the rest of us to see those changes on our watchlist. Better to encourage those editors to do something else, like creating actual content. —David Eppstein (talk) 06:09, 20 February 2018 (UTC)

Logarithms?

A discussion on this topic from 2010 is in the archive, but no conclusion seems to have been reached, there's nothing in the article, and I'd think there ought to be a consistent guideline here. I would propose $\ln$, $\log _{10}$, and $\log _{2}$ always be used for their respective meanings, with the bare $\log$ being reserved for contexts such as asymptotic behavior. Mathematicians might object to the foremost, but this being Wikipedia, I'd imagine even quite advanced topics would be found by a fair share of readers likely to read "log" and infer "common log"; similarly, although I'd imagine most of those with the sort of background to assume the natural log would catch on from context in most circumstances, the lay usage of the bare symbol to mean the common log should probably also be avoided for the confusion it might cause, as should the niche $\lg$. Regardless, even if all of that is rebuked, I do strongly believe we need some community-wide standard. Thoughts? 50.252.247.245 (talk) 19:37, 30 May 2018 (UTC)

That is not the standard usage in pure mathematics, where "log" without adornment is much more common as the notation for the natural log. —David Eppstein (talk) 20:09, 30 May 2018 (UTC)

I'm aware of this. However, as I said, this seems likely to confuse anyone not a reader of pure math journals, likely to be the majority of readers even on extremely advanced topics. Even those familiar with mathematicians' convention might not expect it on Wikipedia. 50.252.247.245 (talk) 20:32, 30 May 2018 (UTC)

On first glance it seems like a reasonable request. But it's a problem for Wikipedia, where we need to stick to the sources, and the sources all use "log". Hmm. Mgnbar (talk) 20:53, 30 May 2018 (UTC)

The convention in lower-level mathematics (in the U.S., anyway) seems to be that $\log$ means $\log _{10}$ (that's what I learned), while the convention in higher-level mathematics and engineering seems to be that $\log$ means $\log _{e}=\ln$. I don't recall any specific case where $\log$ meant $\log _{2}$, but I would not be at all surprised to have such cases pointed out to me. Given the inherent ambiguity, I agree that bare $\log$ should be discouraged in articles, except (as pointed out by the OP) in cases where it doesn't matter which base is used. In all other cases, $\log$ should never be used without clarification as to which base is intended. As for sticking to the sources, we need not use the exact notation used in sources as long as the notation we use has the equivalent meaning. - dcljr (talk) 21:05, 30 May 2018 (UTC)

There are definitely textbooks in computer science, information theory, and engineering that use the log = log₂ convention. See footnotes 17–19 of binary logarithm. I would be surprised to see this variation in pure mathematics, though, and I wouldn't recommend it even for computer science articles in Wikipedia (except within O-notation, where the base of the log is largely irrelevant). —David Eppstein (talk) 21:19, 30 May 2018 (UTC)

It's more important from our perspective to maintain consistency with sources rather than between articles. In some articles it will be more natural to write $\log$ or $\log _{10}$ or $\log _{2}$ or $\ln$. To impose order on this would be for Wikipedia to decide that certain matters of notation are better than others. That is incompatible with our objectives. So we simply stick with what prevailing sources use in a given context, and if there are no dominant conventions, we follow MOS:RETAIN. Sławomir Biały (talk) 21:45, 30 May 2018 (UTC)

"Sticking with sources" should not come at the expense of readers' understanding. This is an encyclopedia, not a professional journal. We should make it clear in each article which base logarithm is meant, and not rely on unspecified "conventions", whether they are shared by our sources or not. Surely we can all agree that (when it matters) simply using $\log$ in an article without providing any additional context (as to what the base may be) should be discouraged. No? - dcljr (talk) 00:51, 31 May 2018 (UTC)

I would again say it depends on the article. In an article like calculus or exponent, absolutely. In an article like Poisson kernel, nor so much, as one would never see any other kind of logarithm in that context. Again, we can let the treatment of standard sources in the subject inform our stylistic preferences for a given article. Sławomir Biały (talk) 00:59, 31 May 2018 (UTC)

There are also contexts for which "log" is the only correct notation for a concept that generalizes the natural log to other domains; see e.g. closed subgroup theorem or logarithm of a matrix. It would be incorrect to substitute "ln" or to put a subscript on the log in those contexts. —David Eppstein (talk) 01:37, 31 May 2018 (UTC)

What I believe we should do is to mention clearly which logarithm is used the first time an unclear $\log$ is used in any article; we should not change the notation if that would be weird in the context. If an explicit $\ln$, $\log _{2}$, $\log _{10}$ etc. is used, though, there is no need to explain. While some might find it strange to mention the log used as it would be obvious to them, we have to remember this is an encyclopedia and that we are writing to laymen (although in some cases we do expect some education). --Jhertel (talk) 10:33, 31 May 2018 (UTC)

Obviously if something is unclear to readers, it should be pointed out, whether that is a logarithm, units, and other conventions. Conversely, if something is likely to be clear to readers, then it is not necessary to point it out. The MoS doesn't usually take a position on whether extremely specific conventions like those for logarithms must be pointed out in the text. Sławomir Biały (talk) 11:44, 31 May 2018 (UTC)

I would agree it depends on the context. I would apply the rule that whatever we can assume six months before a person would be properly prepared to read an article need not be gone over again in the article. Anything which would be dealt with in a mathematics degree need not assume log is anything but a natural logarithm. Anyway the days when people remembered from their 7 figure tables that log₁₀3 was 0.4771213 are long gone, one just uses a calculator to multiply. Dmcq (talk) 11:57, 31 May 2018 (UTC)

Don't we already clarify a lot? Are there specific examples where the logarithm is not already clarified? Mgnbar (talk) 12:25, 31 May 2018 (UTC)

Indenting, again

From § Indenting (permalink) as well as various other MOS pages, it seems like using colons solely for indentation within articles is Bad, and using LaTeX’s block display mode $$x=3$$ does exactly what we want. Is there a reason the article doesn’t advise that over misusing colons? —67.14.236.193 (talk) 05:12, 28 June 2018 (UTC)

I think the main reason is that the |display=block syntax is still pretty new. But also, it doesn't work properly for text that is already indented (for instance in bulleted lists, and yes, I have seen bulleted lists with displayed equations in them). And if your goal is semantic cleanliness, it's just as broken as indenting with colons; for instance, your comment above nests a div (actually two nested divs) inside a p, something that is forbidden in proper html. Finally, the idea of avoiding colons for indentation is based on what is arguably a bug in Wikimedia rather than an actual semantic problem; colons are widely used with the intended meaning of indenting something, so the semantics of the wiki-markup is clean enough. The actual problem is that the Wikimedia engine renders the "indent something" semantics as a piece of a definition list even when there is no surrounding definition list to be found. So avoiding : is just working around a bug rather than making your intent clearer. —David Eppstein (talk) 05:25, 28 June 2018 (UTC)

WP uses HTML5; the paragraph element automatically ends whenever another paragraph or div or similar is encountered. (Edit: it doesn’t start a new <p> after the math, so the text underneath isn’t even in a paragraph, so there is that bug.) And colons (and semicolons) still function exactly as originally intended, and wikimarkup still lacks a simple indent. That’s not a bug in the colon; that’s us misusing definition/description/glossary lists purely for aesthetics. —67.14.236.193 (talk) 06:11, 28 June 2018 (UTC)

Yes. The convenience-over-standards-compliance hissy fit that was thrown the last time we raised the issue of abuse of description-list markup (:) was, frankly, shameful and an embarrassment to the project.  — SMcCandlish ☏ ¢ 😼  06:21, 28 June 2018 (UTC)

Calling indentation "abuse of description-list markup" borders on Stockholm syndrome. It is widely used here as indentation. Therefore it should be thought of as indentation and marked-up as indentation. The bug is that it is instead marked up as a description list, not our usage of it. —David Eppstein (talk) 06:36, 28 June 2018 (UTC)

“My computer won’t turn on when I press the space bar!” “That only wakes it if it’s already on. Have you tried the power button?” “No, couldn’t you just remap it to the space bar?”

We use colons for indenting because indentation is a side effect of what they actualy do. That’s not a technical problem. It’s an institutional problem of not knowing how to use it. —67.14.236.193 (talk) 07:06, 28 June 2018 (UTC)

Exactly. It's unprofessional and ignorant. In debates about it on this page it's faux-ignorant; the participants all actually know better. I call it shameful and embarrassing because none of the same people would tolerate abuse of mathematical markup for cutesy font and layout effects. It's simply not their personal technical specialty, so they're giving the finger to a different variety of geeky standards – discipline and specs snobbery, laced with excessive demand for "expediency" (i.e., laziness).  — SMcCandlish ☏ ¢ 😼  17:49, 28 June 2018 (UTC)

@SMcCandlish: Bit harsh and a bit ad hominem, but I agree that, as a group building a complex project on top of a number of technical standards (including our own!), we should at least pretend to care about technical standards in any formal discussion. And yes, using wiki-colons solely for the visual effect of indentation is no different from using math markup for visual effects in standard text. —151.132.206.26 (talk) 20:40, 28 June 2018 (UTC)

If we use <math display="block"> in its own paragraph (with a blank line above and below), and if we just use list markup instead of block in lists, wouldn’t that avoid these issues? Is there any reason not to use display="block" on its own between two blank lines? —67.14.236.193 (talk) 06:32, 28 June 2018 (UTC)

Let’s see.

$$x=3$$

Well, there’s an empty paragraph (<p></p>) above and below the math, so that’s weird, but otherwise no reason not to use it in typical cases. —67.14.236.193 (talk) 06:32, 28 June 2018 (UTC)

I'm not entirely sure how you are seeing an empty p element above/below; the source I have access to is <p><div>latex{x=3}</div></p>. mw:Remex (via use of the parser migration edit tool) will add apparently empty p elements at some point in the near-future rather than allowing that bad behavior, but that still doesn't explain how you are getting the source you are. Maybe because you are unregistered? The math source I get is because I have the option set for the MathML. Do you receive a PNG? --Izno (talk) 12:49, 28 June 2018 (UTC)

Same IP user as above, not on home computer. @Izno: I was actually looking at the DOM tree (right-click, Inspect Element or equivalent), not the page source, so I didn't see the div inside the paragraph because that’s not a thing that’s possible under HTML5. And yeah, if there’s nothing in the paragraph before the div, that would give you an empty paragraph. —151.132.206.26 (talk) 16:01, 28 June 2018 (UTC)

There was a formal RFC in December, which concluded with an outcome keeping the current guideline [2]. — Carl (CBM · talk) 12:56, 28 June 2018 (UTC)

Yes, we know. Consensus can change, and often does when a former conclusion was based on bloc voting and ignorant or territorial arguments.  — SMcCandlish ☏ ¢ 😼  20:55, 28 June 2018 (UTC)

Hmm... Consensus is great, except for all the ignorant fuckwits who disagree with you. Not exactly a winning argument. Sławomir Biały (talk) 22:40, 28 June 2018 (UTC)

Yeah, consensus can change… if you try every six months forever.</snark> - dcljr (talk) 21:45, 28 June 2018 (UTC)

I didn't bring this up, an anon did. And I've opened no new RfC or other proposal about it. I'm simply expressing my displeasure with the hypocritical bullshittiness of it. I'm confident that it will change eventually, even if I drop dead an hour from now, because everything about this site and "WMF stuff" in general is moving increasingly toward standards compliance, metadata, and automation.  — SMcCandlish ☏ ¢ 😼  23:04, 28 June 2018 (UTC)

For "you try" in my comment, read: "one tries". I wasn't necessarily talking about you, personally. - dcljr (talk) 23:22, 30 June 2018 (UTC)

To add something slightly more relevant (ever so): In my experience, style guidelines can be problematic, because they tend to be developed by people who like to develop guidelines rather than people with direct experience in the area the guidelines purport to cover. - dcljr (talk) 21:51, 28 June 2018 (UTC)

Imaginary dichotomies. a) Mathematics has no professionally codified or ingrained standard for what wikimarkup to use for a visual indentation; maths editors are on the exact same footing as every other editor using the same markup language. B) MoS editors likewise have the same broad and continual article-editing experience as the set of editors who never edit the MoS; same footing again. You're also missing that one doesn't have to like to develop guidelines in order to work on them and try to see them consistently implemented; it is entirely sufficient to simply keep readers, re-use, tools, the editorship as a whole, accessibility, and futureproofing in mind, and to be more averse to unresolved style disputes (which are often quite disruptive) than to writing guidelines that resolve them and forestall recurrence. It takes very little time, comparatively.  — SMcCandlish ☏ ¢ 😼  23:17, 28 June 2018 (UTC)

So you (SMcCandlish) know enough about my personal experience with guidelines to dismiss my statement as being based on "imaginary dichotomies"? Are you trying to make people ignore your point of view, or is that unintentional? (You can treat that as a rhetorical question.) - dcljr (talk) 23:33, 30 June 2018 (UTC)

Re "Mathematics has no professionally codified or ingrained standard for what wikimarkup to use for a visual indentation": actually it is pretty ingrained (because of LaTeX) to use centering rather than indentation for displayed mathematics, to the point where I've seen complaints from authors who thought it was a bug when some specific LaTeX style chose to use indentation instead. One actual advantage of |display=block would be to decouple that sort of stylistic decision from the semantic content. As for codification of the markup to use: LaTeX is codified and is the defacto standard. Based on it, most mathematicians would expect \[ ... \] or $$ ... $$ for displayed equations (and \( ... \) or $ ... $ for inline ones), so anything else (like our math tags) will take some getting used to. —David Eppstein (talk) 01:09, 29 June 2018 (UTC)

I don't disagree that enabling block display (and doing other things, like using a template to apply a close, to permit people to re-style with CSS) might be nice. Has nothing to do with abuse of description list markup to get a visual indentation. Of course maths people use LaTeX, and it is codified and its use is ingrained. I said "codified and ingrained standard for what wikimarkup to use" (emphasis added) because that is the actual topic.  — SMcCandlish ☏ ¢ 😼  02:37, 29 June 2018 (UTC)

"MoS editors likewise have the same broad and continual article-editing experience as the set of editors who never edit the MoS; same footing again." If we're on the same footing, then the expectation is that you should accept the overwhelming consensus of the RfC, based on discussion with your equals, and retract the dismissive personal attack that the outcome was based on "ignorant bloc voting". Everyone in that discussion is exactly as entitled as you are to determine what the manual of style should mandate. Sławomir Biały (talk) 13:49, 29 June 2018 (UTC)

So… are the various pages that explicitly advise against using : for simple indentation outdated? Because this contradicts them. —67.14.236.193 (talk) 15:00, 29 June 2018 (UTC)

Obviously not, and this is a WP:CONLEVEL and WP:POLICYFORK problem, where a wikiproject is trying to declare itself immune to site-wide guidelines. We've been through this many times and it never goes well (I mean, that's why we have CONLEVEL policy; it was written specifically to curtail this sort of thing, because it's disruptive to the encyclopedic output, and internally in the form of protracted dispute about a matter resolved a long time ago more broadly). Given the stonewalling this MoS sub-page, the proper course of action would be to open a new RfC at WT:MOS, neutrally and accurately advertise it at WP:VPPOL, and here, and at the maths project talk page (to prevent a repeat of the distorted canvassing that happened last time). I don't have the "drama" patience to do it now, but the outcome is pretty obvious. If the rest of the advice says not to abuse d-list markup, this page doesn't get a free pass to do so, especially since there is no maths-specific reason to (there is no WP:IAR rationale). See also MoS's lead: "If any contradiction arises [between the main MoS and other MoS pages], this page always has precedence." The MOS:MATH policy-fork is invalid on its face both by MoS's wording and by CONLEVEL policy.  — SMcCandlish ☏ ¢ 😼  15:20, 29 June 2018 (UTC)

(edit conflict) Sławomir, that's all off-kilter. It's not a "personal attack" to observe that the RfC was flooded by WP:WPMATH editors – after shameless canvassing that grossly misstated the nature of the proposal in a way that was sure to alarm wikiproject members into a negative mass over-reaction. It's an observation of stacked turnout, well-poisoning, and poor breadth of discussion; see WP:FALSECONSENSUS. That many of the arguments presented were ignorant of the HTML specs and even of what our wikimarkup resolves to in HTML, and of why it matters, was well demonstrated at that discussion (and in other ones); many were also not responsive to the actual proposal but reacting to the canvassed straw man of it.

Moving on: MoS, like other guidelines, doesn't "mandate" anything. But that rules/winning/control approach to the matter sure explains a lot, as does the implication that because you "won" last year no one's allowed to question the matter ever again. You also more directly suggset that the result of the RfC hasn't been "accepted"; yet no one is editwarring to change the wording, going around editing in contravention of what it says, or even opening a new RfC on it (I generally wait at least a year before I seek a broader consensus re-discussion of something, and I may never get around to this one; someone else is likely to do it before I do). You're not in a position to try to forbid people from saying at a guideline talk page that one of the guideline's line-items is wrongheaded, why, and why the process at which was got to it was faulty. Such discussions are what a guideline's talk page exists for.

Speaking of straw men, I've nowhere suggested that your or anyone else's input into process (RfC, etc.) is less legitimate, only that some of the facts and assumptions are demonstrably wrong; that too many of the arguments are off-topic, subjective preference, dismissiveness of standards that aren't maths standards, and/or grounded only in editorial convenience; and dominated by a particular bloc of (canvassing-confused) editors from one wikiproject.
 — SMcCandlish ☏ ¢ 😼  15:07, 29 June 2018 (UTC)

Frankly, I find your assertion that the people who actually edit mathematics articles should have been kept away so that the style-junkies could have this little playground to themselves to be bizarre and counterproductive. —David Eppstein (talk) 16:40, 29 June 2018 (UTC)

Silly straw man. I said nothing remotely like any of that. Objecting to a blatantly misleading canvassing of a wikiproject bears no resemblance to suggesting that people in the wikiproject be kept away from a discussion. The matter under discussion has nothing to do with mathematics anyway. There is no magically special "mathindents". Misusing description list markup for indentation is a topic-unrelated issue. It's a few people from WP:WPMATH who are treating this page (a WP guideline, not a wikiproject's WP:PROJPAGE essay) as an owned playground.  — SMcCandlish ☏ ¢ 😼  18:11, 29 June 2018 (UTC)

You of course had the option of notifying the affected WikiProject yourself. I'd be interested in knowing the reason for your failure to do so, from someone who so forcefully proclaims that he is entitled to a say in such matters. It's frankly weird for you to say that MoS editors are entitled to opine about style matters despite their lack of experience, yet your apparent attitude that others are too "ignorant" to have an opinion worth noting. But you're entitled to whatever delusions of grandieur you may suffer from. However: Don't you dare try to change mathematics markup recommendations again, without notifying the WikiProject, or I suspect you will soon see what "ignorant bloc voting" can achieve in an ANI report on your deplorable bullying behavior. Sławomir Biały (talk) 22:41, 29 June 2018 (UTC)

More ad hominem nonsense; I have never suggested I have more entitlement to a say in anything. You can falsifying my statements and views all day (well, in theory), and I'll keep correcting you until you stop it and say something substantive.

What this is going to continue boiling down to is what it boiled down to in the previous discussion. I'll just quote (with minor contextual revision) what I said then (and moving those discussions into /Archive 1 isn't going to sweep the issue under the rug): What's happened here is PoV policy-forking – of what a maths-topical MoS subpage says about an accessibility matter about which the maths page is not authoritative, from what the main MoS page and the accessibility MoS page (among others) say about the exact same matter. Contrary to reality-denying claims in these discussions, there absolutely is general MoS material on indenting all kinds of content (regardless of topic) – lots of it, and all consistent except at MOS:MATH. All emphasis is as in the original; these are direct copy-pastes from the pages in question:

• From the main WP:MOS page, at MOS:INDENT: Various templates are available for indentation, including {{block indent}}, and (for inline use) {{in5}}. For more information on the accessibility problems of using : (description list markup) for visual indentation, see [the next page quoted below].
• From MOS:ACCESS, at MOS:INDENTGAPS: An accessible approach to indentation is the template {{block indent}} for multi-line content; it uses CSS to indent the material. For single lines, a variety of templates exist, including {{in5}} (a universal template, with the same name on all Wikimedia sites); these indent with various whitespace characters. ... A colon (:) at the start of a line marks that line in the MediaWiki parser as the <dd>...</dd> part of an HTML description list (<dl>...</dl>). The visual effect in most Web browsers is to indent the line. ... However, this markup alone is missing the required <dt> (term) element of a description list ... this results in broken HTML ... which is confusing for any [screen-reader-using] visitor unused to Wikipedia's broken markup. This is not ideal for accessibility, semantics, or reuse....
• From MOS:LISTS, at MOS:DLIST: When wikimarkup colons are used just for visual indentation, they too are rendered in HTML as description lists, but without ;-delimited terms to which the :-indented material applies, nor with the list start and end tags, which produces broken markup (see WP:Manual of Style/Accessibility § Indentation for details). More accessible indentation templates can be used, e.g. {{in5}} or one of its variants for one line, and {{block indent}} for more than one line (even if misuse of description list markup on talk pages is too ingrained to change at this point).
• From Help:List § Extra indentation of lists): [Need for indentation] is fixed by increasing the default indentation ... and it can be done in multiple ways: ... use an explicit CSS margin spacing of [tech details elided]. Though not the simplest, this is the cleanest and most versatile method, as it does not rely on any peculiarities of the parser, nor on abusing any semantic markup for purely visual purposes. ... A list of one or more lines starting with a colon creates an HTML5 description list (formerly definition list in HTML4 and association list in draft HTML5), without terms to be defined/described/associated, but with the items as descriptions/definitions/associations, hence indented. ... Deprecated method: [this] technique ... produces poorly formed ... markup and abuses the semantic HTML purpose of description lists for a purely visual effect, and is thus a usability and accessibility problem. It will work in a hurry, but should be replaced with cleaner code....

This has never been about anything other than MOS:MATHS recommending a practice deprecated in favor of more accessible practice specified by the main MoS page and the accessibility page and the list-markup page and the list-coding instructions. That's four against one, so we know where WP:CONLEVEL policy goes on this, especially since the main MoS trumps MoS subpages, and it explicitly defers to MOS:ACCESS on this matter. The indentation-related material at MOS:MATHS has nothing at all to do with mathematics and <math>...</math> markup, only with good versus awful ways to shift content – of any kind – to the right.
 — SMcCandlish ☏ ¢ 😼  23:42, 30 June 2018 (UTC)

MOS:INDENT does not say "don't use colons". It says, "This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers.". Which is to say, "colons are still commonly used even though we know they have issues.". There is no conflict between this page and that page. — Carl (CBM · talk) 13:18, 2 July 2018 (UTC)

Back to the technical matters

[3] —67.14.236.193 (talk) 23:34, 30 June 2018 (UTC)

So what exactly is the problem with using <math display="block"> when on its own line? The only technical issue that’s been mentioned is the empty paragraph before the div, which really seems like a non-issue (though it seemed to cause some confusion: under HTML5, which we use, <p> is self-closing; it’s functionally identical to <p></p><div>...</div>, so there is no nesting). —67.14.236.193 (talk) 15:50, 29 June 2018 (UTC)

Probably worth setting up a sandbox page with a test code in it with different approaches, both to see the visual effect in various browsers and to examine the post-parser source that is sent to the user agent.  — SMcCandlish ☏ ¢ 😼  18:14, 29 June 2018 (UTC)

Once we have mw:RemexHtml online in the next month or so we can look into what happens with the HTML. --Izno (talk) 18:31, 29 June 2018 (UTC)

Why not just use "View source" in browsers in the interim? This can be useful; see, e.g.: Wikipedia:Manual of Style/Accessibility/anchor tests, and sandbox we ended up saving for future tests with new browsers.  — SMcCandlish ☏ ¢ 😼  19:31, 29 June 2018 (UTC)

Mostly that it is a waste of time because RemexHtml changes the output in different ways than HTML Tidy does. You can access the Remex source by turning on the parser migration option in your (editing?) preferences and then by going to edit a page if you really want to, but in a couple month's that parser cleaner will be the default. --Izno (talk) 21:15, 29 June 2018 (UTC)

I don’t understand the problem—is RemexHtml expected to render <math> significantly differently? Do we not know? —67.14.236.193 (talk) 00:35, 30 June 2018 (UTC)

It may, or may not, change where that deviant p element ends up, or whether the div ends up inside the p--and while I trust the parser migration gadget to find issues with future rendering, I don't really trust it to output the exact rendering. If it ends up outputting as empty and closed paragraphs (well-formed but meaningless), then the use of display=block shouldn't be blocked on that issue. (There may be other technical or non-technical issues which block moving to display=block--the solution which I think is clearly the superior one.)

What one could do is go to a wiki where Remex is already enabled and test how display=block outputs. I'm a bit lazy on the point ;), so feel free to report back, IP67. --Izno (talk) 01:26, 30 June 2018 (UTC)

or whether the div ends up inside the p—You can’t have a div inside a p. I don’t mean it’s invalid; you literally can’t, it just doesn’t work that way. If you try, the p ends right there, and all you get is the div interrupting the p.

Otherwise, agreed. But I’m not at all familiar with Remex, and have no idea what wikis may or may not use it. —67.14.236.193 (talk) 15:31, 30 June 2018 (UTC)

FYI: The sysadmins have been gradually switching Wikimedia wikis from Tidy to RemexHTML for a while now. The "final switch" to RemexHTML everywhere is scheduled to happen on July 5th. See phab:T175706. - dcljr (talk) 23:19, 30 June 2018 (UTC)

IP67, I see nothing in that section to indicate that a div cannot be found inside a closed block p, which is invalid HTML (but that wouldn't stop authors from writing it that way). Does the closing </p> become stripped? Is it parsed instead as an opening <p>? It's a somewhat backward inference you're making. But as I said, if you want to test the problem, you can see after Thursday how the MediaWiki outputs the markup in question. --Izno (talk) 14:21, 1 July 2018 (UTC)

Testing on a site already using Remex would be a good idea. A test page of coded examples, as I suggested, would work well for this, since it would test various conditions of what's happening now versus what'll happen under Remex, and they'll be directly comparable (though porting some templates to do the test might also be needed, and there could possibly be user or site-wide CSS doing something at affected the output, but that should be easy enough to figure out as the cause should there be discrepancies in the rendering between the two parsers).  — SMcCandlish ☏ ¢ 😼  23:48, 30 June 2018 (UTC)

I mean, Remex will be here on Thursday, so we can also wait. :) --Izno (talk) 14:21, 1 July 2018 (UTC)

"So what exactly is the problem with using <math display="block"> when on its own line? " - several issues have been mentioned, not all of which I can remember, but one is that this is not sensitive to existing indentation, such as:

• List item 1

  $\int _{0}^{3}x\,dx$

• List item 2

• List item 1: math display=block on its own lind

$$\int _{0}^{3}x\,dx$$

• List item 2

It is quite common to have displayed math inside a bulleted list. — Carl (CBM · talk) 13:21, 2 July 2018 (UTC)

Because you placed it at a different level would seem to be the reason why there. The below is the correct analog:

• List item 1: math display=block on its own lind
• $$\int _{0}^{3}x\,dx$$
• List item 2

Now, this one has its own (probable, according to you, issue), which is the bullet next to the display block. The correct way to probably provide either of these cases is to break on the first list item, because only rarely (or perhaps never) is the display block meant to be a distinct paragraph rather than part of the first list item semantically. Or would you dispute that? :)

• List item 1: math display=block on its own lind
  $$\int _{0}^{3}x\,dx$$
• List item 2

--Izno (talk) 14:59, 2 July 2018 (UTC)

The spare bullet would indeed be a problem. It doesn't seem to me that explicit <br> tags are superior to the current system of using *:. If we want to have more commentary after the displayed equation, it seems we would need to put even more <br> tags.

• List item (with br tags)
  $$\int _{0}^{2}x\,dx$$
  is an integral. For some reason there seems to be extra vertical space above this line.
• List item (currently recommended practice)

  $\int _{0}^{2}x\,dx$

is an integral

• List item

I still think that it would be better to fix the problem by fixing Mediawiki to parse Wikitext better. — Carl (CBM · talk) 15:14, 2 July 2018 (UTC)

I don't think you need the ending break for further eliding, which is why you are seeing hte issue (math display=block is a block, which outputs a div, which by default forces everything below it):

• List item (with br tags)
  $$\int _{0}^{2}x\,dx$$ is an integral. The extra unnecessary break you added is the reason why there is extra space.
• 2nd list item.

As has been elided in many, many places, ":" has a specific meaning, and there are a number of reasons why it should not be changed. It is not a question of "parsing wikitext better". --Izno (talk) 15:32, 2 July 2018 (UTC)

A colon without a definition list does have a specific meaning, which is to indent. This has been standard usage for over a decade and is described in places such as this page, Help:Indent, etc. The specific way that the indentation is handled is not optimal - there's no reason Mediawiki should still create a definition list when no semicolon is used. But there is no way to argue that a colon in wikitext is not intended to denote indentation (it's a little like arguing that "cool" only means "low temperature" and does not mean "interesting"). The issue is that Mediawiki needs to recognize that, when there is no semicolon, a colon should be rendered via increased indentation. — Carl (CBM · talk) 15:47, 2 July 2018 (UTC)