Wikipedia talk:Manual of Style/Mathematics

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

WikiProject Manual of Style
WikiProject iconThis page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
 

Markup for math variables[edit]

FYI: Pointer to relevant discussion elsewhere.

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

Indenting[edit]

@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):

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.

(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:
(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>}}
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)[edit]

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[edit]

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?):

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[edit]

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 &sup2;. 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 &beta;), 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''<sup>5</sup>''y''² comes out as x5y² 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?[edit]

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 , , and always be used for their respective meanings, with the bare 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 . 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 means (that's what I learned), while the convention in higher-level mathematics and engineering seems to be that means . I don't recall any specific case where meant , but I would not be at all surprised to have such cases pointed out to me. Given the inherent ambiguity, I agree that bare 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, 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 = log2 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 or or or . 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 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 is used in any article; we should not change the notation if that would be weird in the context. If an explicit , , 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 log103 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[edit]

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

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.

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-forkingof 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)
Of course there is. If the main MOS page (and the others) discourage an accessibility-problematic approach in favor of one that is not, and this MoS subpage pretends the only possible approach is the problematic one, that's obviously a conflict. See also WP:WIKILAWYERING and WP:GAMING on misinterpreting policy and guideline wording by the technicalities of its exact wording instead of absorbing its clear intent.  — SMcCandlish ¢ 😼  19:20, 2 July 2018 (UTC)
This bullshit CONLEVEL argument was definitively demolished at the aforementioned RfC, by an overwhelming consensus. I've no interest in repeating arguments there, which are available for your own perusal. You seriously need to drop the stick, mate. Sławomir Biały (talk) 22:04, 2 July 2018 (UTC)

Back to the technical matters[edit]

[3] Thumbs up67.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)
@Izno: The relevant bit is: A p element's end tag may be omitted if thep element is immediately followed by [a] […] div […] element, or if there is no more content in the parent element […]. In other words, if there’s a <p>, and then there’s a <div>...</div>, the div follows the entirety of the p with no need to explicitly close it. This is also why <p>...<p>...<p>...</p> results in one paragraph after another rather than nonsensically nested paragraphs. That’s how HTML5 works, and Wikipedia uses HTML5. The language provides no mechanism to alter this behavior.
I think you’re focusing too much on the orphaned </p>. That tag is nonsensical; there’s nothing left to close. It’s like if a recipe said to put the pan in the oven, bake, let cool, serve, and then take it out of the oven—it’s already out! —67.14.236.193 (talk) 02:13, 3 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)
No, NOW DAMMIT NOW! heh.  — SMcCandlish ¢ 😼  19:20, 2 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
  • List item 2
  • List item 1: math display=block on its own lind

  • 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
  • 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
  • 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)

    is an integral. For some reason there seems to be extra vertical space above this line.
  • List item (currently recommended practice)
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)
    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)
Yeah, see, I didn't want to get into this--the fact you slipped right back to it in a section talking about the technical matter is a bit telling about your general motivation. Do you have anything further on talking about using display math (esp. issues you have observed)? --Izno (talk) 15:52, 2 July 2018 (UTC)
@CBM: A colon without a definition list does have a specific meaning, which is to indent. Not according to what the markup actually does, and has done since its inception: it creates a description list. See MDN’s page about the Description Details element. We’re arguing semantics here, but semantics matter (and if you don’t believe so, I’d ask what you’re doing in the MOS part of Wikipedia). If you want pure indentation markup, the colon is not what you’re looking for. On talk pages, for instance, discussions have long been threaded by means of nested description lists, which are actually better suited for the task than pure indentation. Doesn’t work so well when they’re broken up by things like blockquotes as above, but that’s getting off topic. —67.14.236.193 (talk) 01:45, 3 July 2018 (UTC)
I am not sure why you are singling me out for "slipping back into this". Anyway, if display=block inserts a following line break, then the other usage doesn't work, which is to put extra text after the displayed equation so that the text will not be rendered in math mode. This is used for explanatory text, comments, etc.
  • List item with text after a displayed equation
    is an integral
  • List item (with display=block inserting a spurious line break)
    is an integral
  • List item
The same thing would happen without the list, of course:
these comments should be on the same line as the integral.
This is a worse issue, actually. — Carl (CBM · talk) 15:58, 2 July 2018 (UTC)
What you describe just strikes me as bad style. If you want the equation inline with text, don’t try to put it on its own line, and vice versa. Enforcing good style is not a drawback. —67.14.236.193 (talk) 03:25, 3 July 2018 (UTC)
Testing display=block with inline references (based on the featured article Pi):
[1]
[2]

References

  1. ^ ref 1: current system, outside math
  2. ^ ref 2: outside math display=block
— Carl (CBM · talk) 16:35, 2 July 2018 (UTC)

───────────────────────── What I was actually trying to ask at the top of this subsection was whether there were any issues with using block-display independently of list markup—under circumstances where it would make stylistic sense to have the math alone on its own line with no other markup on the same line as it.

Regarding indentation, it works just fine in blockquotes:

Markup Renders as
Quote:

<blockquote>
blah blah <math>x=3</math> blah:

<math display="block">\int_0^3x\,dx</math>

blah
</blockquote>

Quote:

blah blah blah:

blah

(Note: I use {{blockindent}} above since I’m not actually quoting anything, but the result is the same.)

It also seems to work inline, with no line breaks of any sort, even in lists. Like so:

Markup Renders as
* …
* Another example of an integral is <math display="block">\int_0^3x\,dx</math> which resolves to <math>\frac x4</math>.
* …
  • [List items about different kinds of integrals or something.]
  • Another example of an integral is
    which resolves to .
  • [More list]

67.14.236.193 (talk) 03:10, 3 July 2018 (UTC)

With the block’s use of div, though, it’s still not technically correct to use it in the middle of a paragraph of running text (it actually terminates that paragraph). But that seems to be the only real issue, and it’s a fairly minor one. The issues illustrated above in lists all seem like user error, adding unnecessary line breaks and the like. —67.14.236.193 (talk) 03:57, 3 July 2018 (UTC)

One remaining key issue is that the display=block adds a line break, so it is impossible to put anything after it on the same line.
this should be on the same line as the formula.
Even if this "strikes you as bad style", it's a requirement for a functionally complete replacement for the current system. Similarly, inline references placed after display=block are moved to the next line. A replacement for the current system needs to be able to do the things the current system does. — Carl (CBM · talk) 12:29, 3 July 2018 (UTC)
It strikes me as bad style too (do you want your math to be block or not? pick one.). I don't think it would be unreasonable to raise a task on Phabricator about that though. As for references, we can handle them like we handle blockquotes today (references before the quotation, generally). That aside, we do not need a "functionally complete replacement" to start using or even recommending block display rather than ": <math>". (I might suggest something like: "For a block of math content, use <math display=block>. You may use this other, deprecated form in these x, y specific cases that do not have a functional equivalent, but we advise a rewrite such that this way is unnecessary. (Those cases may be supported by math at some point in the future. [Link to Phabricator]) Your article should be internally consistent." and go from there. --Izno (talk) 13:04, 3 July 2018 (UTC)
@CBM: Can you give an example from an article in which this is necessary? —151.132.206.26 (talk) 18:11, 3 July 2018 (UTC)
Very little is necessary with enough edits to rewrite the articles. But if you want examples where displayed math is used in non-standalone ways, in the current versions of the article: Reference after equation in 115 (number); displayed math in bulleted list (with incorrect indentation) in 251 (number); text used at the end of one displayed equation to link it to the next one in 3SUM. —David Eppstein (talk) 18:22, 3 July 2018 (UTC)
Just to note, the example at 3SUM is an “or” toward the end of 3SUM#Reduction from 3SUM to Conv3SUM. The best alternative that comes to mind isn’t good, which is using ... \text{ or} ... which would render in a different font than plain text. —67.14.236.193 (talk) 01:43, 4 July 2018 (UTC)
And now, predictably, the proponents of the modified formatting have started editing those articles and destroying their value as examples. I'm switching to permalinks, because the point is not the usage in those specific articles, it's that these are standard usages on Wikipedia more generally that any modified formatting must also be able to support. —David Eppstein (talk) 19:09, 3 July 2018 (UTC)
I’ve only edited the one at “251” (that was me, away from home), and it rather seemed like an example of what not to do: improperly simulating an unnecessary line break before an equation that would wrap to the next line anyway, in a list of otherwise single-line items. Apologies if the break actually served some purpose, and sorry about invalidating your example without thinking—I’ve been pretty tired all day. But the others don’t seem to have been touched at all. —67.14.236.193 (talk) 01:34, 4 July 2018 (UTC)

Indenting: arbitrary break[edit]

With RemexHtml having now been in play for weeks, where do we stand on this? —67.14.236.193 (talk) 01:59, 26 July 2018 (UTC)

What does this do?

^ I see in my source:

<p><div class="mwe-math-element"><div class="mwe-math-mathml-display mwe-math-mathml-a11y" style="display: none;"><math display="block" xmlns="http://www.w3.org/1998/Math/MathML"  alttext="{\displaystyle \int _{0}^{3}x\,dx}">
  <semantics>
    <mrow class="MJX-TeXAtom-ORD">
      <mstyle displaystyle="true" scriptlevel="0">
        <msubsup>
          <mo>&#x222B;<!-- ∫ --></mo>
          <mrow class="MJX-TeXAtom-ORD">
            <mn>0</mn>
          </mrow>
          <mrow class="MJX-TeXAtom-ORD">
            <mn>3</mn>
          </mrow>
        </msubsup>
        <mi>x</mi>
        <mspace width="thinmathspace" />
        <mi>d</mi>
        <mi>x</mi>
      </mstyle>
    </mrow>
    <annotation encoding="application/x-tex">{\displaystyle \int _{0}^{3}x\,dx}</annotation>
  </semantics>
</math></div><img src="https://wikimedia.org/api/rest_v1/media/math/render/svg/4f6ee37704c67835d227c5b66f046f1ba9142be3" class="mwe-math-fallback-image-display" aria-hidden="true" style="vertical-align: -2.338ex; width:8.168ex; height:6.176ex;" alt="{\displaystyle \int _{0}^{3}x\,dx}"/></div>
</p>

And Firefox even highlights the last </p> in orange fore-color as if it is errant (because it is). --Izno (talk) 02:24, 26 July 2018 (UTC)

So we still have the empty paragraph element. Is there anything that can be done about that? Even if not, it still seems a good sight better than creating spurious description lists in article space. As I recall, the only other substantive complaint was the inability to treat block-style as inline (and we shouldn’t condone mixing the styles anyway). (Edit: Also the inability to use <ref>s with block display, which admittedly can be a problem.) —67.14.236.193 (talk) 03:50, 26 July 2018 (UTC)

Proposal: Recommend using <math display="block">…</math> when a block-level effect (with indentation) is desired. Recommend putting any explanatory text and citations in a paragraph before or after the math, because you can't use block display inline with other text. Stop recommending the use of description lists where no list is called for. —151.132.206.26 (talk) 00:28, 31 July 2018 (UTC)

Counter-proposal: don't make markup recommendations that invalidate existing content. The content we produce should dictate the kinds of markup we use to format it, not vice versa. —David Eppstein (talk) 02:03, 31 July 2018 (UTC)
@David Eppstein: You are exactly right, and I’m not sure how that conflicts with my proposal. If the content we produce calls for a math formula within a paragraph of text, use inline math markup; if it calls for a standalone math formula with paragraph(s) above or below, use block math markup. If you want both at once, pick one, because that’s just good style. —67.14.236.193 (talk) 02:33, 31 July 2018 (UTC)
Your proposal invalidates block-level display that has non-mathematical text on the same line. If we want to change current markup, we need to find a way of doing so that accommodates that sort of thing, not that forbids it. —David Eppstein (talk) 04:07, 31 July 2018 (UTC)
The purpose of a manual of style is to encourage good style, not to accomodate bad style. —67.14.236.193 (talk) 01:57, 2 August 2018 (UTC)
If only more people understood that. In particular, our MoS doesn't exist to enshrine bad ideas just because some people in a particular wikiproject have a lazy habit or don't care. If it comes down to it, get a bot to fix the bad markup. Just get it fixed one way or another. The ideal way is for recalcitrant editors to stop being recalcitrant and to instead write better code; this produces less bad code for others to have to repair.  — SMcCandlish ¢ 😼  04:22, 2 August 2018 (UTC)
@David Eppstein: Just so there’s no confusion, I’m asying that block-level display math should not have non-mathematical text on the same line, no matter what markup is used. It’s sloppy. You said yourself that it’s unnecessary and can be rewritten (with minimal effort, in the examples given here earlier). If adopting a better practice with markup “forces” us to stop using sloppy style, I’m afraid I’m not seeing the down side. —67.14.236.193 (talk) 05:29, 2 August 2018 (UTC)
How much mathematics article editing have you done? It's sometimes not just not sloppy, but necessary. For instance, when using {{NumBlk}}. —David Eppstein (talk) 06:06, 2 August 2018 (UTC)

─────────────── I’m surprised <math> doesn’t have that formula-numbering capability itself, but display="block" appears to work perfectly well with {{NumBlk}}. (Edited 23:14, 2 August 2018 (UTC) to display the table borders. We really shouldn’t be using code [or templates] that use tables this way.)

Markup Renders as
{{numBlk||<math display="block">x=3</math>|eq. 1|Border=y}}

Sample text.

 

 

 

 

(eq. 1)

Equation number’s on the same line, math’s properly indented with no colon lists. Actually we could probably edit NumBlk to use block display and ignore the first param. The template doesn’t seem to play well with lists, though. Wonder if that’s fixable… —67.14.236.193 (talk) 07:34, 2 August 2018 (UTC)

Would it be possible to enable the equation environment in <math>? Then we’d be able to use \tag in the math markup itself rather than a template kludge that fakes it with tables (which is notoriously bad web-design style, by the way). —67.14.236.193 (talk) 22:49, 2 August 2018 (UTC)

Jc86035 I saw you resolve something similar quite recently (shortcut template breaking lists). Maybe you have some input? I could probably beat on this myself, but am running out of time for the day, maybe the rest of the week, for anything "involved".  — SMcCandlish ¢ 😼  04:09, 3 August 2018 (UTC)
@SMcCandlish: I don't think I can help, since the other issue was caused by Module:Shortcut emitting extra line breaks and breaking the list formatting. I also would rather leave the solution to this to someone else. Jc86035 (talk) 04:38, 3 August 2018 (UTC)
If it can’t be rewritten to use CSS rather than empty tables for layout, I say we’d be better off deprecating NumBlk and looking for alternatives. It just compounds bad style on top of bad style. —67.14.236.193 (talk) 12:27, 3 August 2018 (UTC)

Italic Greek capitals[edit]

Several authorities recommend italic be used for all variables, whether Greek or not, and whether uppercase or not: IUPAC, NIST & ISO (referenced by NIST). In practice this is not always followed, although those 'contraventions' are not necessarily because of an opposing view. Sometimes the use of roman for variables is founded on the type of application (e.g. to represent a tensor), and very often it is due to defaults built into the software — which may or may not be appropriate.

The current MOS page claims that Greek capitals should (always!) be set roman in order to follow TeX's default setting!

First off, I personally think that they should be set italic if they represent variables; roman would be fine by me if they represent a function. But that's just my opinion.
More importantly, it seems like a terrible justification to say that the default of some typesetter is to be followed with no other reason given. Although there is a lot of discussion of the MOS in the archived talk page, there was no evident discussion of or consensus on this particular matter.

I am not confident of a consensus being reached on this matter. If my own preferences aren't adopted, then I hope some flexibility will be allowed in the MOS to allow for different applications (scalar variable versus function, say) and different contexts (pure mathematics versus engineering, say). But at the least there should be be a better justification presented — if not in the MOS page itself, then here on its Talk page!.
—DIV (120.17.228.105 (talk) 12:47, 9 July 2018 (UTC))

I haven't seen any of the archived discussion, so I'll just give my views without looking first. First off, pulling out things like NIST standards tends to be a dead end; they're just not really followed in the wild. However, if it's really common in some particular area to use italic capital Greek letters for something, then it's probably okay to use here too. After all, the MoS is a series of guidelines, none of which are set in stone. But it really should be done to follow a standard practice and not just out of personal preference. Also, I don't think deferring to what (La)TeX does is all that bad of a reason. It's (sort of) what Wikipedia uses in <math>...</math> sections, and it's what people use in practice to write. –Deacon Vorbis (carbon • videos) 13:18, 9 July 2018 (UTC)
Looking a bit more closely at the section in question, it seems like the intent is just to warn against italicizing capital Greek letters that are being entered as wiki markup. For example, use Γ or {{math|Γ}} (Γ or Γ), not ''Γ'' or {{mvar|Γ}} (Γ or Γ). In this respect, I think this is a fine thing to keep. If there really is a rare exception needed for an italic capital Greek latter, it would be fine to do so, provided that it would be done correspondingly in a <math>...</math> block as well. –Deacon Vorbis (carbon • videos) 14:46, 9 July 2018 (UTC)
Italicization of variables is an independent reason for use of the style, versus italicization of something because it's not English. We don't italicize Greek script for the latter reason because being non-Latin is enough to set it apart. But we do italicize Greek book titles, another independent reason. If it's customary to italicize variable regardless of script, WP should do it, too, unless there's a good reason not to it. "TeX doesn't do it by default" seems like a pretty weak reason, but I don't write enough formulas to care. I think this is another case of conflicting consistencies, and the most important consistency (for the project and its readers, not for someone's preferences) should win.  — SMcCandlish ¢ 😼  20:29, 9 July 2018 (UTC)
What TeX does by default is also pretty much what working mathematicians do by default (for reasons going in both directions). So going against what TeX does by default because you have non-mathematical stylistic instincts that differ is a mistake, likely to produce idiosyncratic and incorrect formatting. Anyway, it is customary (as evidenced by the TeX defaults) to italicize Latin-script single variable names, regardless of case, but not to italicize uppercase-Greek single variable names. This custom is important to follow, not only so that we agree with our sources but also because this convention allows certain Greek and Latin variable names to look more different from each other than they otherwise would. —David Eppstein (talk) 21:06, 9 July 2018 (UTC)
Following typical mathematics usage in RS is the important consistency probably, so this seems good enough to me. I'm wary of specialize-style fallacy arguments, but I don't detect one here; it's not an attempt to impose a specialists' style convention against normal English typography, since there's not a particular way to write formulas in everyday English, with readers getting hit with a principle of least astonishment issue if we do it the maths journal way.  — SMcCandlish ¢ 😼  21:27, 9 July 2018 (UTC)

The reason that TeX does not do it by default is the most mathematical publishing does not do it - TeX was specifically designed to emulate the best quality hand-typeset mathematics. On the other hand, ISO and NIST are pretty much irrelevant to mathematics publishing. The idea that Greek variables are italicized but not Greek functions is challenging to reconcile with variables that range over functions. — Carl (CBM · talk) 20:47, 9 July 2018 (UTC)

I think it is also curious that we have a number of IP editors arriving on an MOS page. Perhaps it would be a better idea to establish oneself as an editor, get experience editing mathematical articles, and then discuss the manual of style later. It's not productive for inexperienced editors to make random MOS suggestions. — Carl (CBM · talk) 20:47, 9 July 2018 (UTC)

Many IP editors are experienced (you can tell when they make clueful rather than clueless arguments based on WP policy, and so on). If you think someone's socking, the place to provide evidence is WP:SSI.  — SMcCandlish ¢ 😼  21:27, 9 July 2018 (UTC)
See also WP:ADHOM and WP:ABP. —151.132.206.26 (talk) 22:13, 23 July 2018 (UTC)