Wikipedia talk:WikiProject Mathematics/Archive/2023/Jun

Talk:Pascal's triangle#Addition of a section on the base of the natural log (e)

I would appreciate it if someone else could add their feedback here. --JBL (talk) 17:07, 1 June 2023 (UTC)

Requested move at Talk:Ultrafilter (set theory)#Requested move 1 June 2023

There is a requested move discussion at Talk:Ultrafilter (set theory)#Requested move 1 June 2023 that may be of interest to members of this WikiProject. PatrickR2 (talk) 05:08, 2 June 2023 (UTC)

Creation of a 'Women in mathematics' page

Hi all, would there be any appetite for creating a page for Women in mathematics (which is currently a redirect to timeline of women in mathematics)? This would be a pretty large project, requiring lots of research to be done, and which would hopefully parallel pages like women in engineering, women in computing or women in science. Things that might live on this page include history of women in mathematics, modern statistics for number of women studying mathematics at university (undergraduate, postgraduate) and women holding academic positions, factors discouraging women from pursuing mathematics and achievements of women in mathematics.

I personally identify as male, and so I couldn't do the topic justice myself. It would be really nice to have female-identifying contributors! For context I am a PhD candidate in mathematics, so I'm also not qualified on the history side. Zephyr the west wind (talk) 22:40, 1 June 2023 (UTC)

There are many books on this topic, so it should be easy to justify it as notable. Just avoid Osen's Women in Mathematics (for reasons that should be apparent if you read the linked article). See Category:Women in mathematics for related topics. —David Eppstein (talk) 23:26, 1 June 2023 (UTC)

The fact that it cites Lise Meitner as a mathematician rather than as a female chemist and physicist who did the work for which Otto Hahn got the Nobel prize is enough to raise my eyebrows. However, I find the author's focus on its subjects' victimization by society to be reasonable, given the history of misogyny. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:51, 2 June 2023 (UTC)

The focus is not the reason to avoid it. The reason to avoid it is that its biography of Hypatia is based entirely on a piece of children's historical fiction replete with faked quotes justifying early-20th-century-American moral values, and that it cannot even spell the names of three of its other subjects correctly. The issue with Meitner is another piece in the same puzzle. Nothing it says can be relied on. —David Eppstein (talk) 18:04, 2 June 2023 (UTC)

I also lack the history qualifications, but I would love to see someone with a suitable background doing such an article. Feel free to use this protest against misogynist prejudice.

It may be hard to prevent the article from being dominated by a single figure, given the importance of Emmy Noether's work, but there have certinly been quite a few major female mathematicians in recent centuries. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:51, 2 June 2023 (UTC)

I am strongly opposed to the "great woman" theory of women in mathematics, where we hear only about one or two superstars such as Noether and a few up-and-coming "science communicators". It would be as if we had an article ostensibly about mathematics that only told readers about Archimedes and the soldier on the beach, Galois's duel, and Euler going blind. There are some 1800 notable women mathematicians listed in List of women in mathematics. Most are accomplished professors and researchers but not superstars. Rather than focusing on a few personalities any such article should focus on broad trends, what barriers existed and still exist for women in the field, what resources are available, etc. —David Eppstein (talk) 18:09, 2 June 2023 (UTC)

It is certainly necessary to cover the many solid female mathematicians, but to ignore the superstars would create a false picture, just as ignoring Gauss would create a false picture of male mathematicians. That said, all of the issues that Zephyr the west wind mentioned are important. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:19, 2 June 2023 (UTC)

With that title it might also cover women in mathematics now, the gradual acceptance of women in maths aroud the world so now for instance in Sudi Arabia one can have news like this Saudi women making their mark in science where women graduates outnumber men in mathematics. NadVolum (talk) 18:54, 2 June 2023 (UTC)

Thank you for the responses. I've started a draft here Draft:Women_in_mathematics which as of me writing this comment is very bare-bones and which you are all welcome to work on! I will myself focus on finding concrete statistics for the time being. Zephyr the west wind (talk) 22:19, 2 June 2023 (UTC)

One possible resource for a particular era: [1]. —JBL (talk) 22:53, 2 June 2023 (UTC)

I think the history section should be split up into a collection of "key time periods" where the major advances/problems can be discussed. It seems difficult to avoid the "great women" story entirely, since early on so few women had any opportunities that they stand out like lighthouses. Perhaps a good narrative is to slowly transition the history section from "Great women" to "Democratization of academics" to reflect the progress in the form of the article itself.

It seems the key time periods are probably something like:

• Female mathematicians in antiquity (most famously Hypatia, although I'm sure a historial survey which didn't focus on "great women" would turn up many interesting things to discuss about how the average woman in antiquity knew/used a lot more mathematics than we suspect. Don't know any good sources for that though).
• "Pre-Noether"/Renaissance to Mid 1800s : Female mathematics during the period where academics was strictly the cultural domain of men. Main story beat here is Sophie Germain corresponding with Legendre and Gauss under a male pseudonym (later revealing herself to Gauss' surprise). Note that at this time academics was in most cases still dominated by wealth, and Germain for example was the daughter of a wealthy merchant. Other discussions: Nightingale's development of statistics and communication in mathematics outside traditional (male) educated circles;
• Noether/Late 1800s/Early 1900s: This is when it started to become more legally accepted that women could participate in academic circles, if not yet culturally. Main story beats are Sofya Kovalevskaya becoming the first full professor in Europe, Noether and her obstructions to formal academic position + her significant achievements. Other key figures being Ada Lovelace.
• Post-Noether/Contemporary: 20th century, when the real democratization of academics happened (due to massive expansion in access to education among all classes). Slow march towards equality of opportunity and outcome.

Could either include a discussion of the contemporary state of women in mathematics here, or in the following section of the article. Tazerenix (talk) 01:43, 3 June 2023 (UTC)

how the average woman in antiquity knew/used a lot more mathematics than we suspect: I am not sure that makes much sense. The "average woman" knew practically nothing about mathematics. That has not changed today, but neither did and does the "average man". The average person in the street is completely ignorant of mathematics. PatrickR2 (talk) 01:52, 3 June 2023 (UTC)

I don't necessarily mean median person. I was referring to the fact that many people used mathematics in ancient times for, for example, bookkeeping and transactions, and I highly doubt such behaviour was restricted only to men (although I of course don't have any sources to back this claim up). It seems like the sort of thing which should be investigated when writing the page to do due diligence to the history of women in mathematics. Tazerenix (talk) 02:06, 3 June 2023 (UTC)

Well, (not even taking about women here) bookkeeping and counting are not exactly mathematics. (and furthermore, in ancient times people engaged in such activities were part of an educated elite). But ok. PatrickR2 (talk) 03:11, 3 June 2023 (UTC)

On the use of Mathematics StackExchange and MathOverflow as references

I recently made some modifications to the Compactly generated space article that included the use of references to Math StackExchange for justification of certain results. Another editor then came along and removed all references to Math SE, based on the fact that WP:RSP lists the whole StackExchange network (to which both Math SE and MathOverflow belong) as "generally unreliable". For background, by their own admission: "I'm not a mathematician, I've just seen some previous discussions around stackexchange.". This brings up the question: Is is appropriate to use Math StackExchange (Math SE) or MathOverflow (MO) as references in Wikipedia mathematics article?

Here is the way I see it. Claims made in Wikipedia must be verifiable WP:V in reliable sources. But for mathematics the notion of "verifiable" could be viewed a little differently than in other fields. In mathematics, a verifiable source may mean a reference to a textbook or a peer reviewed journal (where we take it on faith that the result has passed scrutiny from some experts and is therefore reliable.) That's the usual and preferable case. Or if the first type of reference is not readily available, it could be a reference to a post on Math SE or MO that gives explanation and a detailed proof of a result. This type of post often gives very clear and in-depth justifications, with answers often written by experts in the field, with peer feedback visible to all. Most importantly, it is "verifiable" in the sense that anyone with the proper background can sit down with pen and paper and read a Math SE or MO post to verify it themselves instead of taking it on faith. And sometimes I find it beneficial to combine both types of references; for example, a textbook exercise stated without justification, together with a detailed explanation in Math SE/MO if available.

At the same time, I agree that the average post on the various stackexchange sites is not "reliable" for general Wikipedia usage. And even on the two math related sites, there is wide variation in the quality of the posts. The difficulty is to choose posts of sufficient quality, and it is a judgement call that would be hard to make by a WikiGnome with no expertise in the field. But if we make a blanket prohibition to use Math SE/MO references just because it's easy to enforce automatically, that would cause a loss of valuable information in support of claims in Wikipedia.

Finally, strictly speaking it may not be entirely prohibited, as WP:RSP also mentions: Context matters tremendously when determining the reliability of sources, and their appropriate use on Wikipedia. Sources which are generally unreliable may still be useful in some situations. And in WP:What "Ignore all rules" means: Don't follow written instructions mindlessly, but rather, consider how the encyclopedia is improved or damaged by each edit.

So, what is this community's opinion about this topic? PatrickR2 (talk) 02:46, 4 June 2023 (UTC)

Just to dismiss some of the rather arrogant comments, no I'm do not work as a mathematician but that doesn't mean I don't understand the nature of mathematical proves. Saying I'm a wikignome with no expertise in the field is a foolish supposition based on no evidence. It's true I am a wikignome, something I do as mindless distraction from whatever it is I do in the real world (which I have no interest in discussing). The issue in question is covered by WP:UGC and the previous discussions on WP:RSN 1, 2, 3. As I pointed out to PatrickR2 previously per WP:LOCALCON any discussion about this needs to happen on WP:RSN. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:26, 4 June 2023 (UTC)

At this point, I am just trying to gauge the opinion of the mathematics community (this Project in particular) regarding this issue. This is best discussed in this forum first, and not in WP:RSN. (Not it could also be discussed over there afterwards.) PatrickR2 (talk) 19:18, 4 June 2023 (UTC)

To clarify, when I said "no expertise in the field", I meant no expertise in the field being discussed. In this particular example, the topic was about general topology. I am competent enough to understand and discuss results in that field, but for example would not feel competent to understand some posts about algebraic geometry or analytic number theory. Similarly, someone is not well versed in general topology would not be equipped to judge the validity of MO/MSE posts in that particular field. PatrickR2 (talk) 22:06, 4 June 2023 (UTC)

Without taking a position on SE, I note that arXiv is also not considered a RS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:50, 4 June 2023 (UTC)

Wikipedia:CALC is also relevant. In practice it gives wide latitude in math articles. But my understanding is that MathOverflow et al. are not Wikipedia:Reliable sources.

Now, if your goal here is to discuss changing that policy, then there are lot of details to work out. As I understand it, literally any garbage can be posted to MathOverflow. The site maintains quality through up-voting and down-voting by peers. So do you propose that we accept posts that meet a certain up-voting threshold, or what? Regards, Mgnbar (talk) 16:21, 4 June 2023 (UTC)

I don't dispute that anybody can post anything to MathOverflow or Math SE or any of the other stackexchange sites. We also cannot rely on a certain up-voting threshold, as that is not a necessary reliable indicator of quality (although there is some correlation). What I am saying is that there are some posts on Math SE or MO that are of high quality and provide valuable information in support of results stated in Wikipedia or valuable extra commentary on those. And it would be sad if we could not refer to them.

And I am also saying that there is no automatic way to decide what is good and what is not so good. It is a judgement call that is made on a case by case basis by people with the required background to judge the contents of these posts. But that is not that much different from classical types of references, namely an editor with the required background checks a paper in the literature or a textbook and refers to it. And in the rare cases that a later editor happens to double check it and sees that the referred paper said something a different, or that the textbook was not a correct source for the claim, it is then corrected. All I am advocating for is to be less legalistic, follow the spirit of the law. (I fully understand why these laws are there: nobody wants a bunch of random editors starting to put a bunch of random crap in there). PatrickR2 (talk) 19:35, 4 June 2023 (UTC)

I would suggest links to MathOverflow or Math might be better suited to the external links section. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:39, 4 June 2023 (UTC)

Could you expand on what that would look like? I am not quite sure I follow. PatrickR2 (talk) 19:50, 4 June 2023 (UTC)

Do you mean inline citation would instead refer to a note at the bottom, and the note at the bottom would say "See external links", and the external links section would have a list of relevant links to MO/MSE posts? PatrickR2 (talk) 19:53, 4 June 2023 (UTC)

No I still mean it shouldn't be used for referencing, but that it should be included separately in the external links section so as to direct readers to other sources that be helpful with the subject matter. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:59, 4 June 2023 (UTC)

Usually not in the external links section either, WP:ELNO point #10 is usually read as excluding such links. MrOllie (talk) 20:01, 4 June 2023 (UTC)

Eeurgh I'd missed that. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:02, 4 June 2023 (UTC)

Again, the lawyers here are speaking. In WP:ELNO it says one should generally avoid ... (notice the word "generally"). All your legalese is making Wikipedia a poorer source of information in my opinion. PatrickR2 (talk) 20:15, 4 June 2023 (UTC)

As I said below your reading of "generally" is the legalese reading. It's there for other exceptions, not so it can be ignored. But I think you're right in your other comment, I don't see that Math SE/MP should be treated as a social networking site (I may be wrong in that, but it doesn't seem to fit my understanding of a SN site). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:20, 4 June 2023 (UTC)

(aaaand David Eppstein showed I was wrong under in under three minutes) -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:27, 4 June 2023 (UTC)

This isn't a enforcing a technicality - the spirit of the guideline is to prevent exactly this kind of thing. MrOllie (talk) 20:23, 4 June 2023 (UTC)

Also note that Math SE/MP are not "social networking sites". If anything, they are the antithesis of such sites. PatrickR2 (talk) 20:17, 4 June 2023 (UTC)

They are certainly social networking sites (as is Quora, for example). --JBL (talk) 21:46, 4 June 2023 (UTC)

See the quote at MathOverflow#Reception: Math Overflow is almost an anti-social network, focused solely on productively addressing the problems posed by its users. PatrickR2 (talk) 22:20, 4 June 2023 (UTC)

Or easier: no inline citation. Just add to the external links section a few MO/MSE links useful to the topic at hand. That would work out, in the sense that there is no direct claim of use as reliable source, and at the same time the information is readily available. PatrickR2 (talk) 20:11, 4 June 2023 (UTC)

No. WP:ELNO. It may not be a social networking site but it's a discussion forum, prohibited by #10. —David Eppstein (talk) 20:23, 4 June 2023 (UTC)

May I ask your opinion about WP:ELMAYBE: Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sources PatrickR2 (talk) 20:47, 4 June 2023 (UTC)

Not an exception to ELNO. —David Eppstein (talk) 21:39, 4 June 2023 (UTC)

Hmm, maybe. Maybe debatable, as MO seems more a question and answer site than a discussion forum. But thanks for your opinion. PatrickR2 (talk) 21:42, 4 June 2023 (UTC)

People make posts, comment on them, comment on the comments, upvote and downvote items, have user profiles that accumulate "badges" and "reputation"... it's not meaningfully different in operation from anything that WP:ELNO explicitly excludes. I've seen the occasional subreddit where the commenters are decently well-informed and maybe even subject-matter experts, but that doesn't make Reddit an exception to WP:UGC either. XOR'easter (talk) 23:00, 4 June 2023 (UTC)

On rare occasion when a stack exchange answer is written by someone considered a recognized expert in that specific topic, we can use that escape clause from WP:SPS. But most of the time they fail WP:USERGENERATED and do not count as reliable sources. The same thing is generally true for arXiv preprints that are not yet published, although more of those probably can be justified as being by recognized experts (especially in the cases of heavily-cited but unpublished arXiv preprints). —David Eppstein (talk) 19:43, 4 June 2023 (UTC)

I think this summarizes the situation pretty well. XOR'easter (talk) 22:53, 4 June 2023 (UTC)

Also, regarding WP:UGC, is says Content from websites whose content is largely user-generated is generally unacceptable. Notice the word "generally". It does not have an explicit prohibition to all UCG contents. Even WP:RSP says that such contents can be useful in some situations. PatrickR2 (talk) 19:44, 4 June 2023 (UTC)

That's not the get out you think it is, as with WP:IAR it's only meant for edge-cases (as with David Eppstein comment about WP:SPS above). -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:49, 4 June 2023 (UTC)

We have that ambiguity in the guideline because we have carved out exceptions elsewhere. 'I would really like to use this cite' is not one of those exceptions. MrOllie (talk) 20:02, 4 June 2023 (UTC)

To be clear, WP:CALC is also not one of those exceptions. For basic arithmetic or simple algebraic manipulation, WP:CALC might justify the omission of any sources, but it does not justify using an otherwise-unreliable source. For more complicated mathematics, such as detailed proofs, WP:CALC does not apply. —David Eppstein (talk) 20:21, 4 June 2023 (UTC)

I think there is quite enough maths around for Wikipedia without needing ArXiv etc! However if they are cited in a reliable source or discussed in the news then that can well make them okay as WP:PRIMARY sources. If a recognized expert wrote something in ArXiv I'd still want a mention elsewhere but I think I could then extend to recognizing it as a reliable source without caveats. NadVolum (talk) 20:05, 4 June 2023 (UTC)

I agree with the revert at Compactly generated space. In particular, it looks to me like PatrickR2 took a bunch of cn tags from the article, posted them as questions on Stackexchange, and then used the solutions that resulted as references. This is not appreciably different than if I took a cn tag, wrote a blog-post about it, and then cited my blog -- an obvious violation of our policies. A more plausible use-case for Stackexchange with Wikipedia would be to make reference requests -- but then the books or articles that get dug up that way would be the references, not the SE post. --JBL (talk) 21:53, 4 June 2023 (UTC)

Perhaps WP:CALC should be modified slightly to include not just "routine calculations" but also "routine proofs"? It is clearly written with the intention of allowing expert editors to make straightforward justifications for claims in the text of an article without needing to find an explicit literature reference for every single detail. In that sense the only difference between "routine calculations" and "routine proofs"/"routine justification for a not especially complicated mathematical idea" is the level of the mathematics itself, and the Math wikiproject is already given plenty of leeway when it comes to that. From the perspective of mathematics, a routine proof or routine justification for an idea is often just as mechanical as a routine calculation.

At the very least, maybe WP:CALC could be clarified to explicitly describe what sorts of "routine" things are and are not acceptable? If the consensus is despite the mild benefit, we simply shouldn't cite Mathoverflow/SE, then thats a shame but lets write it down somewhere? Tazerenix (talk) 01:14, 5 June 2023 (UTC)

We have far too many detailed and unsourced workings-out of uninformative and routine proofs of the sort that undergraduates would often see in their undergraduate classes, probably added to Wikipedia by those same undergraduates. When a proof is particularly elegant, and including it would be helpful to reader understanding of the topic, it should also be easily sourceable. When a proof is just routine grinding through the details of an induction, it is not particularly helpful, and I would not want to encourage the addition of more such content. —David Eppstein (talk) 02:07, 5 June 2023 (UTC)

Totally in agreement with you on this. PatrickR2 (talk) 02:35, 5 June 2023 (UTC)

I meant, totally in agreement that we have too many detailed working outs of uninformative and routine proofs. On the other hand, it is often the case that mentioning some key ideas in the derivation of something, in addition to a sourced reference, can be useful in clarifying a concept. But cluttering Wikipedia with the full details of a routine proof does not seem optimal. If we cannot find a good source for a "routine proof", but one is available on MO/MSE, it would be a shame not to be able to use it. But like Tazerenix said, if that's what the community decides, it should be mentioned somewhere. PatrickR2 (talk) 02:47, 5 June 2023 (UTC)

We simultaneously have too many detailed derivations while also often missing crucial conceptual explanations, intuition, pictures, connections, historical discussion, ...

I chalk it up to: good writing is hard even for a focused professional writer or team with deep subject expertise, a well-defined audience, and a clear vision. Here we have a heterogeneous group of hobbyist volunteers writing for an unknown assortment of readers, piling bits on a hodgepodge of material accreted over years or decades, and trying to coordinate despite substantially varying goals and preferences.

Reading articles about basic technical topics here typically leaves me simultaneously frustrated thinking about how extraordinarily much better they could be if someone serious would be willing to devote a few dozen hours of sustained effort to each article, especially considering Wikipedia is often people's first destination to learn about something, but also amazed that it works as well as it does. –jacobolus (t) 05:15, 5 June 2023 (UTC)

I agree with this as well. I think proofs should generally be avoided, unless on a page for a specific theorem and it is possible to describe the proof (and even then not necessarily to give the proof) in a reasonably short span. (An extreme example of the bad way this can go, which also contains many routine parts, is at Monotone convergence theorem.) Gumshoe2 (talk) 05:54, 5 June 2023 (UTC)

Thank you all for the discussion. I will respect the consensus here: except for very rare cases mentioned by David Eppstein, we should not be using MO/Math SE as references in Wikipedia mathematics articles. PatrickR2 (talk) 17:37, 5 June 2023 (UTC)

Incidentally, while we were having this discussion, events have been taking place on StackOverflow, including MathOverflow: the management has decreed that most AI-generated content must be allowed, and in exchange the moderators have gone on strike. If the inability to block AI content continues, the site will be even less usable than before as a source. See [2]. —David Eppstein (talk) 06:46, 5 June 2023 (UTC)

@David Eppstein: I don't think you should ever hope to see any shred of honesty from Stackexchange, Inc. Michael Hardy (talk) 00:22, 6 June 2023 (UTC)

My first RfD

I have sent MathematicsAndStatistics and Mathematics and Statistics to RfD. Since this is a complicated case, I would really appreciate your input. (Currently it seems as if we might either keep them as redirects to Mathematics or setindexify them, but there isn't consensus yet.) Duckmather (talk) 18:26, 8 June 2023 (UTC)

Discussion is taking place here. Felix QW (talk) 18:39, 8 June 2023 (UTC)

What is the reason for suggesting that they be deleted? They are both getting hits, presumably from search engine results. Perhaps they should redirect to Mathematical statistics instead, if that's what people meany by searching for this pair of terms. Tayste (edits) 18:43, 8 June 2023 (UTC)

"Cumulative density function"

Currently Cumulative density function is a disambiguation page explaining that it's a misnomer resulting from confusion between Cumulative distribution function and Probability density function. Its deletion is proposed at Wikipedia:Articles for deletion/Cumulative density function. You can comment there. In fact, Google Scholar shows 53100 hits for that exact phrase, showing that even authors of scholarly papers are often so confused that they use that phrase. Thus it appears to me to be very useful as a means of correcting an appallingly widespread error. Michael Hardy (talk) 14:54, 14 June 2023 (UTC)

About an hour and a half after this message, the AfD was closed as "keep". --JBL (talk) 17:31, 14 June 2023 (UTC)

I have some concerns about the outcome here, which I've expressed at talk:cumulative density function#Disambiguation pages and common errors. --Trovatore (talk) 18:09, 14 June 2023 (UTC)

Should "Mathematics Subject Classification" (2020) be in "Authority Control"?

Current Wikidata has d:P3285 for the 2010 Mathematics Subject Classification classification. When this is updated for 2020 or a new property is introduced, the Template:Authority Control could populate MSC2020 ID from WikiData. While Authority Control seems to be mainly for Authors/Artists, it does include subjects from some National Libraries. The 2020 CSV file has 6603 entries, with 63 2-character prefixes and 597 3-characters ones. Partial Differential Equations (prefix 35) has the most descendants at 317, over Number Theory at 302. Based on What Links Here, Wikidata has less than 500 uses of P3285 currently. Comments? RDBrown (talk) 07:12, 15 June 2023 (UTC)

Why can't mathematicians spell?

I found this in the article titled Bessel function:

Plot of the Hankel function of the first kind H⁽¹⁾
_n(x) with n=-0.5 in the complex plane from -2-2i to 2+2i with colors created with Mathematica 13.1 function ComplexPlot3D

I changed it to this:

Plot of the Hankel function of the first kind H⁽¹⁾
_n(x) with n = −0.5 in the complex plane from −2 − 2i to 2 + 2i with colors created with Mathematica 13.1 function ComplexPlot3D

Note:

n=-0.5 versus

n = −0.5

so both the horizontal spacing and the minus sign are different.

-2-2i versus

−2 − 2i

so horizontal spacing and the two minus signs and italicization are different.

I have been forced to learn that some otherwise conscious people don't notice that there is less space between the minus sign and the first 2 then between the second minus sign and the second 2, for a reason.

Not only in non-TeX mathematical notation in Wikipedia articles, and not only in Wikipedia's TeX-like software, but also in daily use of LaTeX on the job, mathematicians are incredibly callous about things like this, although when Donald Knuth created TeX he said it was for the purpose of making attention to things like this possible that he did that. And he succeeded brilliantly, and most mathematicians appear not to want to know that.

The reason why one font looks good and another looks horrible is a lot of tiny details that go unnoticed by people who nevertheless think the aesthetic differences are conspicuous. Yet one mathematician I know of, when his attention was called to one of those differences in detail, said he doesn't think anyone will even notice. You can't miss the point more completely: the effects of such details happen whether their cause is noticed or not.

Here I think a sort of literacy campaign for mathematicians may be in order. Michael Hardy (talk) 18:50, 14 June 2023 (UTC)

It's not a matter of literacy, it's a matter of style. And for 99% of people 2+2i and 2 + 2i is exactly the same thing. So 99% of people just don't care because they got the message across, even if not up to the stylistic standards of professional publishing. Headbomb {t · c · p · b} 19:10, 14 June 2023 (UTC)

@Headbomb: You are mistaken and you are naive. Notice that I said the many tiny differences of this kind are the cause of one font looking good and another looking bad. And there is probably no instance of this sort of thing that will not make the difference between understanding and failing to understand in at least some contexts. Michael Hardy (talk) 19:27, 14 June 2023 (UTC)

I've taught math and physics for well over 10 years now, included entire classes on how to style equations, variables, etc. My opinion is informed, no matter how much you dislike it. Headbomb {t · c · p · b} 19:30, 14 June 2023 (UTC)

I am certainly not convinced that everyone who has taught classes on this for a long time is well informed about at least some of the matters that I raised. Michael Hardy (talk) 19:40, 14 June 2023 (UTC)

Illustrating with one of your examples, I see that you now improved the result by tweaking for example the formula {{math|-2-2i}} by manually adding "&nbsp" around the minus sign to make some space around it and manually adding double quotes around the "i" to make it italic. The result looks ok, but it seems way too complicated for editors to do routinely. We should encourage people to take advantage of the automatic formatting provided by Tex and use <math>-2-2i</math>. The result will be both easier to maintain and perfectly formatted. PatrickR2 (talk) 19:23, 14 June 2023 (UTC)

@PatrickR2: . . . . . or maybe <math display=inline>-2-2i</math> Perhaps this is no longer as problematic as it used to be. In the past you could get some hideous font mismatches by doing that in an inline setting. Michael Hardy (talk) 19:29, 14 June 2023 (UTC)

I could be missing something, but I have never seen it to be a problem without "display=inline". PatrickR2 (talk) 05:33, 15 June 2023 (UTC)

The addition of display=inline is only needed when you want to force inline style per se, for instance if you have a sum like ${\textstyle \sum _{n=0}^{\infty }n.}$ If you just have a one-off fraction you can alternately use \tfrac, e.g. $\tan {\tfrac {1}{2}}\theta .$ Whenever the formula is already all on a line, display=inline doesn't make much practical difference, e.g. $e=mc^{2}$ vs. ${\textstyle e=mc^{2}}$ render the same. One place that the inline style is unexpectedly helpful is in making square roots take less vertical space, e.g. ${\sqrt {x^{2}+y^{2}}}$ vs. ${\textstyle {\sqrt {x^{2}+y^{2}}}.}$ –jacobolus (t) 15:30, 15 June 2023 (UTC)

Good to know. Thanks for the explanation. PatrickR2 (talk) 20:36, 15 June 2023 (UTC)

@PatrickR2: And just using TeX doesn't fully solve the literacy problem. If you write <math> X/\sim rather than <math> X/{\sim}</math> (referring to a quotient space of a space "X" by an equivalence "~", then you get an incorrect result: you see ${\textstyle X/\sim }$ where you should see ${\textstyle X/{\sim }.}$ The reason why that is software functioning just as it ought to function, for good reason, is something that too many users fail to understand. And many many other things like that. Michael Hardy (talk) 19:33, 14 June 2023 (UTC)

Seems to me like a pretty bizarre use of the words "spell" and "literacy"! Could you clarify to what extent you are speaking about something objective? From your comments so far, it seems like you just have some very strong personal preferences.

I think the much more serious problem is the inconsistent vertical/font alignment of latex. Is there a reason it's never been fixed? Gumshoe2 (talk) 22:57, 14 June 2023 (UTC)

Because the Wikimedia developers are at best indifferent to and at worst hostile to LaTeX-based mathematics markup. It has always been a badly-working patch while they wait for decades for MathML to take over. For a few years we had workarounds to let us run MathJax in place of their bad formatting but they killed them off. —David Eppstein (talk) 03:35, 15 June 2023 (UTC)

If they really want MathML then they need to do something about the repurposing of <math>...</math> for LaTeX. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:25, 15 June 2023 (UTC)

The section title is appalling: it begs the question and totally misleads the reader. Style may be important, but it is very different from spelling; the text presents no evidence that the literacy and spelling skills of mathematicians are in any way deficient, and, in any case, improving those skills would in no way address the stylistic issues that Michael Hardy is concerned with.

As a side note, mathematicians are used to dealing with journals that have house styles. Tweaking the markup in that context is pointless because the editors will change it after submission. Even articles submitted to arXiv are often intended for publication elsewhere. It's likely that habits relevant to journals carry over to text intended for wiki. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)

Well at least the math tag defaults to using SVG now instead of generating png imge files. That is making the math template redundant at least, perhaps something can be done about that. I don't believe MathML has enough support in browsers to be the default - anybody got any ideas what on earth has happened with that effort? As to typing − versus -, I really don't feel like saying that all the mathematicians who came before Knuth or utf-8 can't spell! In terms of the literati of the future I give that a 👎. NadVolum (talk) 14:15, 15 June 2023 (UTC)

If the text is in the body of the article, the top example should be replaced by:

Plot of the Hankel function of the first kind $H_{n}^{(1)}(x)$ with $n=-0.5$ in the complex plane from $-2-2i$ to $2+2i$ with colors created with Mathematica 13.1 function ComplexPlot3D

Unfortunately LaTeX in captions breaks mediawiki (when a user clicks the image to see it rendered larger, the LaTeX does not render in the image viewer mode) so in this case Michael Hardy's version using math templates is the appropriate alternative. But the original version is also fine enough considering it was added by some untrained volunteer. The trivial spacing differences are not a big deal. Fix such formatting when you come across it and and then move on with your day. –jacobolus (t) 15:38, 15 June 2023 (UTC)

Also Michael Hardy's version contains four "& nbsp;" that are here only for making more difficult to read the source code, since Michael Hardy certainly knows that lines cannot be brocken inside {{math}}. D.Lazard (talk) 16:04, 15 June 2023 (UTC)

I'm pretty indifferent to extraneous explicit  s in the markup, but fair enough, you are right that ideally they should be left out. Either way, this doesn't seem like a reason to start a conversation here. Fix such problems case by case and move on with your day. –jacobolus (t) 19:08, 15 June 2023 (UTC)

So SVG doesn't work well if used in the caption of an image and one clicks on the image? That sounds like a solvable problem surely? NadVolum (talk) 17:21, 15 June 2023 (UTC)

Both the original code and your alternative are buggy. ComplexPlot3D is a function in the Wolfram language so should be typeset as code like other such language constructs: {{code|ComplexPlot3D}} typesets as ComplexPlot3D. --{{u|Mark viking}} {Talk} 17:46, 15 June 2023 (UTC)

Some people have objected to the word "spell." Since orthography consists of more than what is usually called spelling, just changing "spelling" to "orthography" ought to make it fully unobjectionable.

There do exist orthographic standards in mathematical notation. And mathematicians are usually callously indifferent to them and don't realize that they exist and have difficulty understanding why they ought to exist. But they make a practical difference. Donald Knuth, when he invented TeX, was absolutely clear that those have virtually the highest priority in his work on TeX. Failure to adhere to them does strike some people the same way bad spelling does. Maybe I will come back and try to explain why this is not all just subjective taste at some point. Some of the comments here seem like people belligerently insisting on a right to be ignorant. Michael Hardy (talk) 21:22, 16 June 2023 (UTC)

Does anyone know precisely what causes phantom scrollbars in <math display=block>?

Here are some recent examples that on my browser generate them (I'm not trying to pick on you user:sbb; your recent changes applying display=block to existing formulas were just already close at hand, so I didn't have to hunt around as much for examples):

$$J^{-1}={\begin{pmatrix}{\dfrac {x}{r}}&{\dfrac {y}{r}}&{\dfrac {z}{r}}\\\\{\dfrac {xz}{r^{2}{\sqrt {x^{2}+y^{2}}}}}&{\dfrac {yz}{r^{2}{\sqrt {x^{2}+y^{2}}}}}&{\dfrac {-(x^{2}+y^{2})}{r^{2}{\sqrt {x^{2}+y^{2}}}}}\\\\{\dfrac {-y}{x^{2}+y^{2}}}&{\dfrac {x}{x^{2}+y^{2}}}&0\end{pmatrix}}.$$

$${\begin{aligned}{\frac {d}{dx}}[\sin(x)+C]&={\frac {d}{dx}}\sin(x)+{\frac {d}{dx}}C\\&=\cos(x)+0\\&=\cos(x)\end{aligned}}$$

$${\begin{aligned}\langle -\Delta f,f\rangle _{L^{2}}&=-\int _{-\infty }^{\infty }f''(x){\overline {f(x)}}\,dx\\[5pt]&=-\left[f'(x){\overline {f(x)}}\right]_{-\infty }^{\infty }+\int _{-\infty }^{\infty }f'(x){\overline {f'(x)}}\,dx\\[5pt]&=\int _{-\infty }^{\infty }\vert f'(x)\vert ^{2}\,dx\geq 0.\end{aligned}}$$

$${\begin{aligned}\ln(z)&={\frac {(z-1)^{1}}{1}}-{\frac {(z-1)^{2}}{2}}+{\frac {(z-1)^{3}}{3}}-{\frac {(z-1)^{4}}{4}}+\cdots \\&=\sum _{k=1}^{\infty }(-1)^{k+1}{\frac {(z-1)^{k}}{k}}\end{aligned}}$$

$${\begin{aligned}t'&=\gamma \left(t-{\frac {vx}{c^{2}}}\right),\\[2pt]x'&=\gamma \left(x-vt\right).\end{aligned}}$$

$$n!_{(\alpha )}={\begin{cases}n\cdot (n-\alpha )!_{(\alpha )}&{\text{ if }}n>\alpha \,;\\n&{\text{ if }}1\leq n\leq \alpha \,;{\text{and}}\\(n+\alpha )!_{(\alpha )}/(n+\alpha )&{\text{ if }}n\leq 0{\text{ and is not a negative multiple of }}\alpha \,;\end{cases}}$$

$${\begin{aligned}\int _{0}^{\infty }{\frac {\sin t}{t}}\,dt&=\lim _{s\to 0}\int _{0}^{\infty }e^{-st}{\frac {\sin t}{t}}\,dt=\lim _{s\to 0}{\mathcal {L}}\left[{\frac {\sin t}{t}}\right]\\[6pt]&=\lim _{s\to 0}\int _{s}^{\infty }{\frac {du}{u^{2}+1}}=\lim _{s\to 0}\arctan u{\Biggr |}_{s}^{\infty }\\[6pt]&=\lim _{s\to 0}\left[{\frac {\pi }{2}}-\arctan(s)\right]={\frac {\pi }{2}}.\end{aligned}}$$

$${\begin{aligned}\int {\sqrt {a^{2}+x^{2}}}\,dx&={\frac {a^{2}}{2}}(\sec \theta \tan \theta +\ln |\sec \theta +\tan \theta |)+C\\[6pt]&={\frac {a^{2}}{2}}\left({\sqrt {1+{\frac {x^{2}}{a^{2}}}}}\cdot {\frac {x}{a}}+\ln \left|{\sqrt {1+{\frac {x^{2}}{a^{2}}}}}+{\frac {x}{a}}\right|\right)+C\\[6pt]&={\frac {1}{2}}\left(x{\sqrt {a^{2}+x^{2}}}+a^{2}\ln \left|{\frac {x+{\sqrt {a^{2}+x^{2}}}}{a}}\right|\right)+C.\end{aligned}}$$

In my browser, they not only cause an eyesore, but also hijack my mouse scrollwheel/touchpad scoll gesture so that it only scrolls the math container box rather than the whole page. It's incredibly frustrating.

They often show up with multi-line "align" formulas, big matrices, "cases", and other similar formulas, but not always and I can't figure out quite what distinguishes the formulas where they appear from the formulas where they do not.

Does anyone have any reliable workaround(s) to make them go away? –jacobolus (t) 01:45, 17 June 2023 (UTC)

Kindly (no picking received, understood), I have been been playing with such maths, trying to understand the scrollbars issues. I haven't nailed it down precisely, but I've noticed that adding [2pt]] after the \\ on lines the precede fractions has seemed to reduce or eliminate the scrollbars. Will test and get back...  — sbb (talk) 01:57, 17 June 2023 (UTC)

I see the phantom scrollbars as well, on Firefox 114.0.1 on Windows 10. -- King of ♥ ♦ ♣ ♠ 06:48, 17 June 2023 (UTC)

I see them on Microsoft Edge and Firefox on my laptop, but not on Safari on an iPad. It is definitely suboptimal. 100.36.106.199 (talk) 14:13, 17 June 2023 (UTC)

They also exist in iPad Safari, but scroll bars there auto-hide when not actively being scrolled. The content of the math boxes will still sometimes (not always) hijack your scroll gesture if you try to touch them and swipe your finger to scroll. –jacobolus (t) 14:22, 17 June 2023 (UTC)

For what it's worth, I use Chromium on Ubuntu 20.04 and there the behaviour is as jacobolus describes for Safari on iPad. Felix QW (talk) 15:35, 17 June 2023 (UTC)

Also exists on MacBook Safari. Similar to what Jacobolus describes, it's hidden until you deliberately attempt to scroll the content, then the scroll bar appears and sections of content move slightly as result. DB1729^talk 15:35, 17 June 2023 (UTC)

History of the separation axioms

This page, history of the separation axioms, is kind of strange. From what I can find, the given references don't say anything about the history of the separation axioms, other than these four sentences in Willard's book:

"The T2 axiom is included in the original list of axioms for a topology given by Hausdorff. The T0 axiom is usually credited to Kolmogoroff and the T1 axiom to Frechet or Riesz. Tietze was the first to use the term "separation axiom," in 1923. The T0 identification is due to M. H. Stone."

However, none of the above quoted content has made it into the wikipage. The content of the wikipage seems to be more like an essay contrasting the definitions made by different textbooks, and speculatively interpolating/suggesting a historical interpretation. At the end of the day I think it only beleaguers the simple point that different authors use different conventions ... which doesn't warrant a whole wikipage.

Unless someone would like to improve the article I will probably nominate it for deletion soon. Gumshoe2 (talk) 19:41, 16 June 2023 (UTC)

Please don't nominate it for deletion. The article, originally written in 2005, clearly explains the different and conflicting conventions that have evolved over time in the definitions of separation axioms (especially the inclusion of T_1 or not in the higher axioms). It mentions as landmarks for both categories Steen & Seebach (1970) and Kelley (1955), and refers to Willard as the more commonly used convention nowadays. So it is a very useful article in that sense. It is true that it is not an article about the history of each separation axiom (such a history is best kept together with each separation axiom article). But it is an article about how the separation axiom conventions have evolved over time, clearly explaining that there were (and still are) some of these differences and why and which is the more common convention nowadays. Very valuable to have this overview in one place. Maybe you would prefer a different article title to better reflect the contents? PatrickR2 (talk) 21:39, 16 June 2023 (UTC)

Also note that there is no dispute about the T0, T1, T2 axioms. All authors treated those in the same way, which is why no details are given about those in the article. The differences start with T3. PatrickR2 (talk) 22:20, 16 June 2023 (UTC)

Please correct me if I’m wrong, but all of the content about how the conventions have evolved over time is speculative, at best “original research.” I do agree that it’s good to have easily accessible information on the differing conventions, but that seems perfectly appropriate to about one paragraph’s worth of content on the separation axioms page. Instead of deletion I should have suggested merging the good content into that page (and then deletion). Gumshoe2 (talk) 00:05, 17 June 2023 (UTC)

There is nothing speculative about that. It's all a matter of looking at the sources and seeing what each author is using. It is true that not that many sources are cited in the article (maybe in 2005 the guidelines were not as strict?). But looking at all the classic textbooks for general topology (Hausdorff, Kuratowski, Dugundji, Kelley, Engelking, Bourbaki, Willard, Schechter, etc, etc) matches what's in the article. One additional reason that overall information is useful to have is that it is often confusing for newcomers to topology and it's good to spell out why Wikipedia made a certain choice and not the other one. As far as merging into separation axiom, that's a possibility, as long as we don't obliterate this useful information. PatrickR2 (talk) 00:50, 17 June 2023 (UTC)

It's all a matter of looking at the sources and seeing what each author is using. Is this not definitionally WP:SYNTH? --JBL (talk) 00:54, 17 June 2023 (UTC)

Reporting what each text says is probably OK. Speculating about why certain changes happened, or saying that there has been a general trend towards some point, would be advancing a new conclusion that no source has itself advanced first, which would be over the WP:SYNTH line. XOR'easter (talk) 14:41, 18 June 2023 (UTC)

I do not currently have any opinion on whether this information is verifiable and encyclopedic.

I do think that if it is, it is valuable, but seems to me to have a much better place on the seperation axioms page, where it is actually seen by the readers that are interested in it. Felix QW (talk) 09:34, 17 June 2023 (UTC)

Should all math articles be immediately switched from : indentation to <math display=block>?

User:Sbb (contribs) has recently been making large numbers of regular expression assisted changes to math and other technical pages, switching them in mass from : indentation style to <math display=block> instead. I asked them to stop doing this at large scale, because in my opinion it is of limited benefit, not an urgent problem to fix, and needs to be manually checked/fixed afterward which requires nontrivial effort from other editors, and is therefore unhelpful and disruptive to do quickly at wide scale. They have promised to continue such edits, saying (paraphrased) "don't tell me what to do". I'm bringing the conversation here, as the math wikiproject seems like the group of most direct interest in this topic.

User:Sbb, please desist from further edits along these lines pending some consensus here.

I have several problems with uncareful uses of <math display=block>:

• First, it often creates weird phantom vertical scroll boxes on blocks of mathematics that otherwise fit just fine on the page, and these intercept user mouse/touchpad scrolling to scroll the tiny box (which only scrolls by a pixel or two) instead of scrolling the page as intended. Tweaking the LaTeX markup to find an appropriate workaround so that these scrollbars disappear is fiddly and unpredictable, and takes a few minutes of going back and forth between preview and markup to fix each individual case. I don't know how to predict when/why this happens. Does anyone else know?

• Second, when formulas are placed to the left and floating images are placed to the right, if the content column gets narrow (e.g. in a narrow browser window), colon-indented math will be moved after the image while display=block will try to display to the left no matter how much the image and math block collide, and the block math box will get as narrow as necessary, showing a horizontal scrollbar to see the rest of the formula. If the formula is of moderate width, this is incredibly inconvenient to read. To work around this, editors often move images away from where they think would be the best spot or resize them to a non-optimal size to minimize the chance of creating a collision.

• Third, display=block always generates invalid HTML markup, because it puts a <div> inside a <p> element, but according to the HTML specification a <div> is not "phrasing content", and therefore cannot sit inside a paragraph. The browser responds by adding an implicit closing </p> immediately before the math block, and then also implicitly adds another opening <p> tag at the end of the paragraph. When block math is included in the middle of a paragraph of text this is especially problematic: the content of the paragraph after the end of the block math ends up being inserted into the HTML as a bare text node without any enclosing element, breaking CSS's ability to style it. The workaround is to always surround display=block by blank lines. The resulting HTML is still invalid (still tries to put a <div> inside a <p> element) but at least the rest of the paragraph ends up inserted into the HTML as intended. Any large-scale use of <math display=block> should adopt this workaround, pending fixes to mediawiki (don't hold your breath for fixes; this issue was reported in 2017). Otherwise editors have to come and manually add the blank lines afterward. See user:jacobolus/math block example for a bit of detail.

• Fourth (and somewhat less importantly), display=block has more vertical whitespace padding than colon-indented math, and on pages with many formulas, this is sometimes space wasting and somewhat ugly. In some cases formulas should be manually combined using \begin{align} ... \end{align}. In other cases this can be worked around using {{bi}} or the like. Again, any intentional fix takes quite a bit of manual work to do.

Overall, my impression has been that there is not any consensus at this wikiproject that all colon-indented block math in math articles must be switched to <math display=block>. I find such changes to many pages on short time scale to be distracting and unnecessary. But I am curious what other editors here think about it. –jacobolus (t) 17:51, 15 June 2023 (UTC)

Accessibility is not optional. MOS:ACCESSIBILITY demands that we not use : for indentation. Editors who improve the accessibility of our articles should not be discouraged from doing so. There are other alternatives that we can use in place of display=block or : – another that I often use is {{bi|left=1.6| ...math... }}. All three of these alternatives are problematic in different ways but that can be laid at the feet of the Wikimedia developers who refuse to put any effort into improving our mathematics capabilities. —David Eppstein (talk) 19:05, 15 June 2023 (UTC)

Unfortunately {{bi|left=1.6|<math>..</math>}} turns out to cause its own problems: it creates a box that gets cut off on the right in a narrow browser view and isn't scrollable at all, leaving especially some mobile readers unable to see the whole equation. Is there some other workaround? Can we make some alternative indentation template?

What is the precise accessibility issue with colon indentation? Something about screen readers speaking? Can someone demonstrate concretely what the difference is between math with vs. without colon indentation? Are the display=block formulas actually accessible by screen readers? How are they rendered in speech? Is it coherent and legible? Are there other ways to add explicit fallbacks that are directly intended for clear audio rendering? –jacobolus (t) 19:16, 15 June 2023 (UTC)

The accessibility issue is that it gets marked up in html as the definition of an entry within a list of definitions rather than as an indented piece of content. So content readers based on the semantic markup of an entity rather than on the visual rendered appearance will not be likely to handle it correctly, because the semantic markup says that it has a different purpose than its actual purpose. —David Eppstein (talk) 19:24, 15 June 2023 (UTC)

Is there a concrete example of what screen readers actually do with each version? What is the actual spoken content in each case? –jacobolus (t) 19:40, 15 June 2023 (UTC)

I knew it. Based on the discussion at my talk page, I sensed User:jacobolus wasn't going to represent the discussion fairly or honestly. It is a flat-out smear to summarize the discussion as They have promised to continue such edits, saying (paraphrased) "don't tell me what to do".

For some reason, User:jacobolus is concerned that I use a regex to find colon-indented math blocks at the beginning of a line. He noted it here (regular expression assisted changes), and twice characterized it as script changes, when I specifically reiterated, multiple times, that I specifically read each pattern match before replacing, to make sure I don't include apparent block-math with following wikitext (such as refs, equation numbers, etc.).

As I summarized in that discussion, both MOS:INDENT and MOS:INDENTGAP say don't abuse colon-indent, as well as Help:Displaying a formula#Block stating <math display="block"> is the way to do it. Yes, poor HTML5 is produced with display="block", but that can be fixed in the Math plugin code. Conversely, the colon-indent will never be fixed in the wikitext parser.

As I stated, I am absolutely willing to also make more substantial edits to articles. But I am primarily a gnomish editor, and User:jacobolus can't berate and brigade me because he doesn't like what I edit, when they are all constructive edits. I'm pretty sure this forum isn't the place for this; my edits are constructive, and it's not up to any individual user to require me to get consensus from a WikiProject, when I'm not violating WP:PRESERVE.  — sbb (talk) 19:17, 15 June 2023 (UTC)

That was intended as a quick summary not a "smear". Please stop with your own personal attacks. I will directly quote you if it helps. I politely asked you to please stop making many such edits in quick succession, pending a discussion arriving at some wider consensus, and you said:

IMO, replacing invalid HTML5 markup–generating wikitext with recommended best practice doesn't need consensus. And I'm going to continue WP:BOLDly fixing them. [...] At any rate, respectfully, no, I don't intend to stop. [...] I'm not going to ask you for permission before I edit. [...] I'm not going to justify my edits, where I choose to focus my efforts, to you. Stop asking me to defer to what you want. [...] Do what you need to do. I'm going to continue to edit where I think it's necessary.

I thought that "don't tell me what to do" was a reasonable one-sentence paraphrase of the above. But again, you trying to turn this into some kind of personal tit-for-tat is all an off topic digression from the subject of this conversation. My point here is to reach some kind of community consensus about how block math should be treated and whether it should be changed at wide scale right now instead of handled gradually case by case in the course of other edits, not to start some kind of personal dispute. A request to reach community consensus before making sweeping changes is a fundamental norm of Wikipedia collaboration, not intended to be a personal attack. This Wikiproject is the most appropriate venue for this discussion (see WP:SEEKHELP), not "brigading". –jacobolus (t) 19:25, 15 June 2023 (UTC)

I really don't want to go back and forth with you. But your I thought that "don't tell me what to do" was a reasonable one-sentence paraphrase of the above is not at all a reasonable summary of the discussion, when I continually said that I was absolutely willing to make more edits to those articles, or other steps you might suggest. But your one-sentence summary paints me as unwilling to discuss, interact, or come to a compromise. And when you kept mischaracterizing my edits as "script assisted", and damned me with faint praise by comparing me to another bot-mimicking user who has now wasted thousands of hours of volunteer cleanup effort... . And yet I'm the one making personal attacks? No, I am not.

I agree, the back-and-forth tit-for-tat must stop. I hoped it would have stopped on my talk page. But don't you dare try to open a topic like this here a project talk like you did, with absolutely ZERO WP:GOODFAITH in my intentions or contributions, like you did. I'm done conversing with you about this, I don't think there's anything more productive you and I can say to each other in this matter.  — sbb (talk) 19:46, 15 June 2023 (UTC)

Yikes. Please try to re-read more charitably, and not try to imagine a personal attack in every part of every comment. I swear to you that not a single one is intended.

I'm sorry, it is unfair of me to take my frustration with other script-assisted editors making large-scale changes (who have cost other Wikipedians thousands of hours and me tens of hours of cleanup) out on you. I was not trying to directly associate you with those other scripts or editors; my point bringing it up was just that semi-automated changes are relatively cheap while coming back and manually inspecting/undoing such edits if necessary takes dramatically disproportionally more effort. Therefore, I think it's important to be extra careful to get it right up front.

continually said that I was absolutely willing to make more edits – I just wanted to have some kind of community discussion about the best approach forward before you invest a huge amount of time into making changes and before I invest a huge amount of time into trying to check them one by one. We can together as a community decide if such effort is helpful/necessary, and perhaps collectively we can come up with some solutions to any problems created. I am not trying to question your motives or belittle your effort.

I wish I had a clear idea of extra steps you could take to not get phantom scrollbars (which have showed up on many of the pages you changed); does anyone know an easy way to avoid them? My method of adding weird LaTeX spacing tweaks to work around the problem is not reliable and takes a lot of fiddling.

One concrete thing I would ask, if you insist on changing block math at scale: would you please add a blank line after any block math formula that you turn to? Otherwise the text content afterward gets inserted into the HTML as a blank text node, not inside any paragraph. This makes it completely impossible for anyone to style it with CSS. –jacobolus (t) 20:09, 15 June 2023 (UTC)

I'm sorry, it is unfair of me to take my frustration with other script-assisted editors making large-scale changes ... "other script-assisted editors", but not me. I see. Please, police your wording if you're actually apologizing. Again, I'm not a script-assisted editor, so "other" means nothing in this context.

(who have cost other Wikipedians thousands of hours and me tens of hours of cleanup) out on you. I was not trying to directly associate you with those other scripts or editors; ... Yet, you keep lumping me, in your set-associative language (with "those other, but not you" (meaning, me) ...), but still characterizing me as a script-editor that you seem to hold with disdain or derisiveness.

Look, it's quite simple: I, or any other editor, script-using or not, am not making/requiring you to do anything. You don't have to edit WP. You don't have to review a single one of their, or my, edits. You keep talking about "thousands of hours" (eyeroll of eyerolls) that you and your fellow put-upon guardians against the chaos (this is the subtext I read from you, with little exaggeration) must endure. You don't have to do anything. Please stop victimizing yourself with my WP editing. Please!

my point bringing it up was just that semi-automated changes are relatively cheap while coming back and manually inspecting/undoing such edits if necessary takes dramatically disproportionally more effort. Therefore, I think it's important to be extra careful to get it right up front. To the extent that doing semi-automated changes (which, I'm not), yes, it's important to get it right. And in this case, I'm sorry to say that you aren't correct. Rather, you and I differ on opinion; and I'm totally backed by MOS and documentary direction. Nowhere in MOS / MOS:Accessibilty does it say that editors should hack wikitext to achieve visual goals at the expense of semantic correctness (for as much as wikitext (and/or template wrapping) provides semantic correctness).

I just wanted to have some kind of community discussion about the best approach forward before you invest a huge amount of time... my time is my time, please. No need to presume to speak for me. ... into making changes and before I invest a huge amount of time into trying to check them one by one. What you choose to do with your time, likewise, is up to you.

We can together as a community decide if such effort is helpful/necessary, and perhaps collectively we can come up with some solutions to any problems created. Consider this: I'm not doing anything wrong. You have chosen to allow yourself to be put out by me. In that reframing, do you not see that you are the one making "any problems created"? Again, you don't have to check me. At all. You can choose to just... not.

I am not trying to question your motives or belittle your effort. Sincerely, and without snark, thank you. And in the grand scheme of things, truly, I don't think you are, AT ALL. But I do think you're convinced that you're so right, that you need me to stop editing, until you're convinced that I'm actually making semantic improvments to wikitext. Here's the thing: it might be that neither of us are objectively right or wrong in our positions. Where does that leave us? Frankly, it leaves us with you doing your thing, and me doing mine. And hopefully, we can try to come to a mutual understanding. Speaking of which, let's address that...

I wish I had a clear idea of extra steps you could take to not get phantom scrollbars (which have showed up on many of the pages you changed) I appreciate that, and while they suck, I have to admit, I'm not very concerned about them. By that, and let me be clear, I intend on making better semantic improvements to wikitext, with less concern towards mitigating specific browser bugs, etc. I spent a lot of my earlier programming career HTML & CSS hacking to get around IE/FF discrepancies in presentation, and I'm done with it. My job as Wikipedian is to produce the best possible wikitext, with the least sacrifices to accessibility, with the faith that eventually parsing and presentation bugs get fixed in the MW engine and plugins. But tweaking wikitext to massage presentation is a fool's errand, and I won't cotton to it. I just won't. I've been around that block waaaay too many times. It's a de-stabilizing effort, to accede to poor input just to mollify the existing bugs in software. Commit to correct input, and thereby lampshade and shine a light on how the system isn't producing the right output, rather than hide the bugs with workarounds and mollycoddling.

One concrete thing I would ask, if you insist on changing block math at scale: would you please add a blank line after any block math formula that you turn to? Otherwise the text content afterward gets inserted into the HTML as a blank text node, not inside any paragraph. This makes it completely impossible for anyone to style it with CSS Finally, after many repeated offers and requests by me, have you suggested compromise or meeting you halfway. This is a reasonable request, truly. However, I'm initially inclined to deny it, at least prior to discussion and consideration. Let me explain...

I have been making article-wide changes by mass-replacing colon-indented math blocks, but aside from that, trying to minimize my additional impact. Ideally, in those changes, literally all you would see is s/^: *(\<math)/$1 display="block"/ -type changes (if you're sed-saavy). Many articles with <math> tags with prepended ":" don't have blank lines around those math block; many other articles do have blank lines around them.

• Semantically speaking, from a wiki-text–parsing standpoint, there shouldn't be blank lines around block-displaying <math>. This is because, although presentationally-speaking, the CSS is displaying them as blocks, linguistically/syntactically, they're not separate paragraph objects. They are absolutely part of the sentence(s)/fragments that lead and/or follow them. So normally speaking, wikitext blank lines indicate paragraph breaks.
• However... I fully realize and understand what's happening with blank lines (or the lack thereof) around <math> blocks. And yes, the behavior is different when disply="block" is applied. I get that. And no, it shouldn't be, I agree.

So... to that end, I'd absolutely like to know, what is the suggested path to take with regards to <math display="block">? Should those blocks be separated by blank wikitext lines, or not? IMHO, I'd prefer they would be separated by blank lines, trusting the Math-plugin parser to be fixed to not introduce empty <p> tags before/after, like "works" with :<math> surrounded by blank lines.

But inasmuch as this has become a huge distraction for me, when I truly try to minimize the additional edits I make, I'm a bit hesitant to go adding blank lines around colon-indented math blocks, simply because I'd prefer to just minimize other changes, for fear of going through the sturm und drang like we're doing now.

I'll happily submit to larger input, and blank-line pad my math block edits, if there's a hint of consensus which way it should be in semantic wikitext. Truly and respectfully.  — sbb (talk) 02:59, 16 June 2023 (UTC)

I'm not very concerned about [ugly phantom scrollbars that hijack users' attempts to scroll the page] [...] My job as Wikipedian is to produce the best possible wikitext, with the least sacrifices to accessibility, with the faith that eventually parsing and presentation bugs get fixed in the MW engine and plugins.

We should be very concerned with those. Wikipedia exists for readers, not for some kind of platonic ideal machine ingesting markup to reach enlightenment. We should try our best not to generate pages that are worse for nearly all readers today (except possibly some screen reader users whose specific problems I still do not have a clear understanding of) in the hopes that they might be better for some hypothetical readers in an uncertain future.

We could just as well wait until "eventually parsing and presentation bugs get fixed", whereupon we can all together have a barn raising effort to fully adopt a working solution site-wide. I'd be happy to contribute substantially to that. But it seems just as likely that these bugs will not get fixed for years or perhaps ever, and then by making a mass switch all of our readers will just be indefinitely stuck with result which is worse than the previous version.

Wikitext markup isn't what is shown to readers. What readers see is HTML as rendered by their user agents (browsers or other tools).

"Semantic" purity of Wikitext (or any other document format or other kind of nontrivial human or machine interface in use ever anywhere) is an impossible pipe dream. Rendering legible (and yes, accessible) pages requires piles of workarounds and hacks, just as there are piles of workarounds and hacks at every level from bare machine metal on up – you'd be amazed at the impurity compiler writers, language implementors, network hardware/software, browsers, display driver authors, etc. have to put in so that you can [mostly] not have to think about how much stuff is happening for you to read this page – and web authors including wiki authors are sadly are not exempt from that.

Many articles with <math> tags with prepended ":" don't have blank lines around those math block; many other articles do have blank lines around them.

A line-leading : is always interpreted in mediawiki as starting a new block-level element, and new block elements in mediawiki such as lists, headings, etc. are indifferent to separation by (zero or one) blank lines. So adding or removing blank lines around :<math>...</math> makes absolutely no difference to the HTML rendered as output, and presence or absence of blank lines does not express any kind of authorial intent one way or the other. This is just the same as the way I can add double spaces after sentences or pad section headings like either == Heading == or ==Heading== without any effect. Ideally the mediawiki software would also output well-formed HTML when encountering <math display=block> irrespective of the preceding or following text. But sadly it does not.

linguistically/syntactically, they're not separate paragraph objects.

This is true in a certain very pedantic sense, but that's because mathematical typography (and in general text with intra-paragraph block elements) has conventions which are not at all aligned with the basic design choices of HTML. There's a mixup of two different things here, first the logical structure of the text, and second the presentational structure (a tree structure consisting of boxes positioned relatively to each-other) browsers use to render the page.

Ideally any table, block quotation, figure, list, formula, etc. could be stuck into the middle of a "semantic paragraph" while still rendering as a separate block, and the user agent would know that the block element should be pulled out of the ordinary flow and rendered on a separate line (optionally centered, indented, boxed, or whatever else), but that inline content afterward should subsequently continue as ordinary following lines, not treated as the beginning of a new paragraph.

Unfortunately, HTML was not ever designed to work that way, and in practice effectively never does work that way. Instead, it has a strict distinction between "phrasing" vs. "block" content, and the latter is not allowed in paragraphs. Nearly everyone who outputs HTML, including every mediawiki author, is stuck expressing their block-presenting elements as separate blocks, and using the content within multiple <p> elements to implicitly create "semantic" units across markup-element boundaries. This applies not only to math content but also to lists, tables, figures, etc.

Feel free to take it up with the original creators of HTML and CSS. –jacobolus (t) 06:41, 16 June 2023 (UTC)

re: [ugly phantom scrollbars that hijack users' attempts to scroll the page]: We should be very concerned with those. Wikipedia exists for readers, not for some kind of platonic ideal machine ingesting markup to reach enlightenment. I am concerned with them, yes, to the extent that I want those issues to be fixed. But I am not willing to commit to hacking wikitext to get it done. The correct place to fix it is in the Math extension parser/generator.

We could just as well wait until "eventually parsing and presentation bugs get fixed", whereupon we can all together have a barn raising effort to fully adopt a working solution site-wide. I'd be happy to contribute substantially to that. That's not how this wiki project has ever really worked. We write and edit IAW what the parser, MOS, and Help pages advertise and suggest. That's what I'm working with and towards.

Wikitext markup isn't what is shown to readers. What readers see is HTML as rendered by their user agents (browsers or other tools). Correct, absolutely. And in order to help the parser & plugins generate the best possible HTML+CSS, we should try our best to create the best possible wikitext as input. Clarity of intent (input) helps drive better improvement and fixes to the output. We shouldn't be trying to fuzz the parser with production content in order to massage the best output. That leaves cruft and clutter around for years when the parser bugs eventually get fixed. That's why metric boatloads of inline <math> content have trailing "\, " in order to pad them out from surrounding inline text, when instead, it should have been (and eventually was) fixed in either the generated math output or the math CSS.

"Semantic" purity of Wikitext (or any other document format or other kind of nontrivial human or machine interface in use ever anywhere) is an impossible pipe dream. As an absolute, sure, it'll never be 100%. But let's don't dismiss all of the tools that marginally improve semanticness. There are a lot of words in MOS:EMPHASIS to explain several ways to italicize text, but they explain clearly, using the word "semantic" frequently, to not use '' or <i>...</i> to italicize text that is meant to indicate emphasis, and rather to use {{em}} or <em>...</em> to semantically mark up the content, which also happens to italicize it. Etc., etc., for everything else in wikitext that needs to be indicated with semantic meaning.

Rendering legible (and yes, accessible) pages requires piles of workarounds and hacks, just as there are piles of workarounds and hacks at every level from bare machine metal on up – you'd be amazed at the impurity compiler writers, language implementors, network hardware/software, browsers, display driver authors, etc. have to put in so that you can [mostly] not have to think about how much stuff is happening for you to read this page – and web authors including wiki authors are sadly are not exempt from that. Spare me. I've designed circuits, written entire parsers with metatemplate programming, written hypervisors and emulators, network stacks, and hardware drivers. I know what's involved. And in every case, every layer is an abstraction to hide the tough and gritty details, to make it cleaner and easier for the next person up the stack to use.

Wiki editors are not web developers; we shouldn't be asked to be, nor should we rely on our lower-level knowledge to hack the wikitext to massage the output, when instead we should report bugs, and let the development process work. When you put on your wiki-editor hat, you are committing to producing wiki content. You might know what's going on under the hood, which is great. But bodging wikitext as a matter of practice is not something we should be doing. And it's certainly not something we should be trying to build sub-community consensus around.

Community consensus should be aimed at best practices. Best practices don't always yield perfect results, but they produce consistently better results than without them. The metric of "consistently better", of course, is up to community judgement. There's compromise involved, and faith and judgement that the tools' bugs will get fixed. Without that faith, we might as well just drop back to nested table layouts and pixel twiddling. We're not going to do that, and I'll fight such inclinations, or their analogues, every step of the way.

Many articles with <math> tags with prepended ":" don't have blank lines around those math block; many other articles do have blank lines around them. A line-leading : is always interpreted in mediawiki as starting a new block-level element... Immaterial. I'm removing colon-indent math blocks as I go, leaving it semantically better.

and presence or absence of blank lines does not express any kind of authorial intent one way or the other. This is just the same as the way I can add double spaces after sentences or pad section headings like either == Heading == or ==Heading== without any effect. You're missing my point about blank lines. You're talking about blank lines separating block-level content. In wikitext, consecutive lines of text, without blanks in between them, become a single HTML (and conceptual) paragraph. Editors writing sentences with block-layout math interspersed, if they don't put blank lines surrounding the <math display="block">...</math> tags, aren't doing anything wrong. Yes, the Math extension is generating poor HTML, as you have noted (and has nothing to do with [taking] it up with the original creators of HTML and CSS). But that needs to be fixed in the extension. I don't think it's justifiable to make a consensus policy against legitimate, should-work-as-advertised wikitext, just because some of us might be fatalistic about the bug ever getting fixed.  — sbb (talk) 14:53, 16 June 2023 (UTC)

concerned with them, yes, to the extent that I want those issues to be fixed. But I am not willing to commit to hacking wikitext ... – It sounds like your alternative plan is to leave them strewn across all technical articles on the site and shrug about it, vaguely hoping someone else will eventually deal with it. Are there other concrete steps we can take here as a community to push on this? I personally find these scrollbars very ugly and annoying, and I think they make Wikipedia seem unprofessional.

That leaves cruft and clutter around for years when the parser bugs eventually get fixed. That's why metric boatloads of inline <math> content have trailing "\, " in order to pad them out from surrounding inline text, when instead, it should have been (and eventually was) fixed in either the generated math output or the math CSS. – This supposed "cruft and clutter" has never harmed anyone throughout its lifetime, but its inclusion meant that for many years (a decade?) the content appeared as intended despite poor technical choices in the platform. It is excellent that authors adopted such "cruft" to fix their pages as a workaround for technical shortcomings; as a result readers were able to read pages with better, more consistent typography – both when they were written and still today – instead of living with wonky rendering inconsistencies violating authors' intentions. Once the technical issue has been resolved resolved it's fine to now eliminate vestigial "cruft" at leisure, a bit at a time, but there's no particular hurry because it doesn't cause any significant problem to just let it continue to sit doing nothing.

You're talking about blank lines separating block-level content. In wikitext, consecutive lines of text, without blanks in between them, become a single HTML (and conceptual) paragraph. ...

In wikitext, a line beginning with : always indicates a new block-level element. Whether or not it is offset by blank lines does not make any difference to the output. Whether authors add blank lines around their :<math>...</math> lines is not inherently meaningful, and should not be interpreted to mean any particular thing.

But that is all somewhat irrelevant. As a general rule, in mathematical typography, block math is semantically part of the previous sentence. Readers can infer this from the punctuation and phrasing used. But in HTML (both at Wikipedia and pretty much everywhere else on the internet), block math is encoded in markup using separate block level elements, with text afterward encoded as a separate paragraph.

Or sometimes, as in the wiki bug I am complaining about, authors write it using invalid markup as a <p> element with a block-level element nested inside which the browser proceeds to break by implicitly closing the <p> before the block element and then inserting any trailing part of the paragraph as a bare text node not inside any <p> element. Then the authors are left puzzled if they ever try to style their paragraphs with CSS and some part of their content is left unstyled because their markup is broken.

If you want to "fix" this so that "pure semantic HTML" is properly interpreted, feel free to go tell Google, Mozilla, Apple, and the W3C that their HTML specifications are all broken and they should change this behavior which has been baked into browsers for decades because it is incorrect and you aren't willing to "hack" your HTML to work in browsers because you intend for someone external to eventually fix it so that you can continue to purely convey your intentions. They will ignore you, or if you are lucky they will patiently explain that backwards compatibility prevents such a fundamental change to browser parsing. –jacobolus (t) 15:42, 16 June 2023 (UTC)

It sounds like your alternative plan is to leave them strewn across all technical articles on the site and shrug about it, vaguely hoping someone else will eventually deal with it. You seem bound and determined to undermine what little common ground to discuss this we've built, by going back to passive-aggressive and undercutting barbs. Please stop.

Are there other concrete steps we can take here as a community to push on this? Yes. The Phab ticket(s) you linked to (or opened, I can't recall, and really ATM, I can't be bothered) are a great place to get people to ping the devs about the issue. Advocate for that. I'm on board. I'll try to carve out time later to figure out what I have to do to chime in on Phabricator.

In wikitext, a line beginning with : always indicates ... Please, stop talking down to me about block content. I know what block content is. In wikitext, a line beginning with a : always results in a <dl><dd>, full-stop. And that's not going to change. The base wikitext parser has been immutable on that score, and it's safe to assume it always will be. Ignore the colon, because standalone colons (i.e., not part of a description list) are going away. That's the whole entire reason for this conversation you dragged me into against my will. Follow the MOS and documentation.

If you want to "fix" this so that "pure semantic HTML" is properly interpreted, feel free to go tell Google, Mozilla, Apple, and the W3C... Stop telling me to "feel free" to contact orgs outside of WP. That's the 2nd time you did that, in a row. I don't have a problem with browser devs, WhatWG, or even MW devs for that matter. They aren't my problem.

This discussion has gone on long enough. We're back to arguing round and round. Either get your consensus to enjoin me from editing IAW MOS:INDENT, MOS:INDENTGAP, and Help:Displaying a formula#Block, or drop it.

With regards to adding blank lines around <math>...</math> blocks where none existed before, as I said earlier, that's a reasonable request, but I'm not convinced of the merits of it. I will consider it.  — sbb (talk) 16:19, 16 June 2023 (UTC)

Nobody is talking down to you. I repeated my previous point again because you ignored it the first time and talked past me. And now you have ignored it again a second time.

The point is, when you look at existing wiki pages with the intention of switching colon indentation to <math display=block>, you cannot (and should not try to) draw any meaningful inferences about author intent from whether or not there are blank lines surrounding block math. Those do not now (and should not in the future either, once this bug is fixed) make any difference to HTML output, which should ideally be something like:

<p>some leading text</p><div class=math><svg>... formula ...</svg></div><p>some trailing text.</p>

Until this bug is fixed, adding blank lines after math blocks makes the HTML output significantly less broken than not adding them (though still slightly broken). Once the bug is fixed – years from now if ever – those blank lines will no longer make any practical difference to the HTML output and will at that point only be an aid to legibility of the markup. That's just fine. –jacobolus (t) 16:37, 16 June 2023 (UTC)

I have ignored your digression about HTML phrasing and flow elements, because you're assuming it must always present breaking <p>...</p> tags around math blocks. There's no reason to presume that the Math extension fix won't use nested <span> tags (like is currently done for non–display=block math) with the inner one using class="mwe-math-mathml-block" instead of class="mwe-math-mathml-inline".

It can be made to emit correct HTML5, and made to respect blank wikitext lines before, after, both, or neither, around the <math> block. All other navel-gazing about it is not productive here. These details need to be hashed out at Phab.  — sbb (talk) 19:16, 16 June 2023 (UTC)

I am assuming that Wikipedia body copy should be inside <p> elements, that is correct. That is how all ordinary text on the web is marked up and how HTML/browsers were designed to work.

I am also suggesting that block content should be marked up as HTML block elements. This is also fundamentally part of the design of HTML.

Whether you like it or not, block content is not in HTML allowed to nest inside of paragraphs (which only allow "phrasing" content).

The most semantically explicit HTML markup accurately conveying author intent would be something like:

<div class=paragraph><p>...</p><div class=math>...</div><p>...</p></div>

The alternative, of having elements (math, lists, tables, figures, ...) intended to be displayed as a block but as a hacky workaround marked up using <span> elements instead of divs, lists, figures, etc. so that you can stick them into a paragraph is a gross abuse of the <span> element which does not actually work very well in practice because browsers are not intended to work that way.

There's no reason to presume that the Math extension fix won't use nested <span> tags (like is currently done for non–display=block math) – there is a very good reason to presume that. The reason is that block math is intended to be displayed as a block, whereas inline math is intended to be displayed inline ("phrasing content"). It is supposed to be separated from the paragraph, centered or indented, with padding on top and bottom, not rendered within the body copy but pulled out as a block... i.e. precisely the intended use of HTML block elements. This is just the same as literally every other kind of block element (lists, tables, etc.). For every kind of block element, sometimes the author's intent is to have a semantic "paragraph" wrap the block with part before and part after. However, HTML as designed does not and never will accommodate this. The mental model around which HTML is designed is in fundamental conflict with a mental model which holds that "semantic paragraphs" should wrap block content. Those decisions were made decades ago and there's absolutely nothing we can do about it now or ever in the future. –jacobolus (t) 20:33, 16 June 2023 (UTC)

Whether you like it or not, block content is not in HTML allowed to nest inside of paragraphs (which only allow "phrasing" content). The most semantically explicit HTML markup accurately conveying author intent would be something like... It has nothing to do with whether I like it or not. Flow element content (i.e., <span>) with "block" presentational attributes (display=block or display=inline-block) is specifically allowed accommodated for in HTML+CSS. It's entirely semantically-explicit to have a paragraph (<p>) with flow elements with block display attributes within.

The most semantically explicit HTML markup accurately conveying author intent would be something like: [stuff with <div>s, etc. ...] Pure opinion. If it needs to be inline flow content with block-style breaking and indentation purely for display/formatting reasons, it's perfectly semantically correct to represent it in <span>s.

them into a paragraph is a gross abuse of the <span> element which does not actually work very well in practice because browsers are not intended to work that way. [[citation needed]]. Balderdash. HTML+CSS provides fairly little semantic structure, but block and flow level content can definitely be structured on top of it by a pre-processed language... such as Wikitext. HTML+CSS can absolutely provide as much semantic information as required by the authors, or the meta-authors with language translation tools. That's the very flexibility of HTML+CSS once we abandoned pre–HTML 4.

there is a very good reason to presume that. The reason is that block math is intended to be displayed as a block, whereas inline math is intended to be displayed inline ("phrasing content"). I have news for you: MW/WP's <math> isn't HTML5. It's re-interpreted (i.e., pre-parsed and rewritten) for MW/WP's Math extension's own purposes.

And what's more, "The <math> MathML element is the top-level MathML element, used to write a single mathematical formula. It can be placed in HTML content where flow content is permitted." (directly quoting MDN). Meaning, <math> is a flow-content tag every bit as much as <span>. They can both be "promoted" to block-style presentation via CSS.

For every kind of block element, sometimes the author's intent is to have a semantic "paragraph" wrap the block with part before and part after. However, HTML as designed does not and never will accommodate this. The mental model around which HTML is designed is in fundamental conflict with a mental model which holds that "semantic paragraphs" should wrap block content. Those decisions were made decades ago and there's absolutely nothing we can do about it now or ever in the future. Now you're just talking out of your ass, with a weird fatalism, and without apparent understanding of how HTML was initially conceived and developed from SGML, through standards with XHTML via hard work from W3C and WhatWG, and ultimately settled fairly rationally by WhatWG in HTML5.

I'm not trying to disparage you now. But what I see is simply floundering; your ego is defensively reaching to claw some sense of a "win" from this fight. From this windmill-tilting. And it's not going well. Again... all of these "points" (such as they are, and they're not strong) should be developed and brought up at the Phab ticket to potentially solve the Math extension's bug. But this dead horse has been beaten and bloodied. There's no more traction here.  — sbb (talk) 22:25, 16 June 2023 (UTC)

not trying to disparage you – haha. yes you are, as you have been since the beginning of this conversation, which from your end has consisted of a mix of aggressive insults, passive aggressive insults, false claims about my statements and intentions, whining about my good faith efforts to engage with you, and now preposterous disclaimers about how your insults aren't meant to be insulting (lol). All of which I have been largely ignoring because responding in kind to rudeness is a fool's game on the internet. As they say about mud wrestling pigs...

Your comments about <math> elements meaning MathML are all off topic and irrelevant to what we are discussing here. Wikipedia does not currently (and as far as I know is not planning to) emit MathML.

Spans are inline elements intended to be used, when inside a paragraph, as "phrasing content" and only allowing "phrasing content" nested inside them. If you want to stick any kind of "block level content" (such as new paragraphs, headings, ordered lists, unordered lists, definition lists, tables, blockquotes, figures, ...) inside a span inside a paragraph, you are entirely out of luck. HTML does not allow it – instead your browser will implicitly close the paragraph. HTML is designed in such a way that block elements are not intended to fit inside paragraphs (or spans inside paragraphs).

You can if you want override the display style of a span to make it render as a block, but it's an abuse and in my experience putting a block display element in the middle of a paragraph doesn't work very well and is a pain to style with CSS in such a way that the text on both sides of the block actually does what you want, because browsers aren't really expecting that to be done. (Disclaimer: most of my CSS experience was 10–20 years ago.)

Why don't you make an example page (off wiki) showing of the HTML markup and CSS you think Wikipedia should use for block math embedded in a paragraph, demonstrate how you think it should render, and we can test it in the common browsers, and then we can all try to pitch the developers to adopt that preference in what they emit, ASAP. If such markup works effectively and such a change lands in the code (and especially if someone fixes the phantom scrollbar bug and slightly reduces the vertical padding of <math display=block>) I'll be more than happy to leave all of the block math crammed inline into paragraphs of markup. I don't think it's going to work very well but am happy to be proven wrong. In the mean time, please don't emit such markup, because as of today it results in completely broken HTML. –jacobolus (t) 23:54, 16 June 2023 (UTC)

Your comments about <math> elements meaning MathML are all off topic and irrelevant to what we are discussing here. No, they're not. You said, and I quote, block math is intended to be displayed as a block, whereas inline math is intended to be displayed inline ('phrasing content'). I don't know how you can square the circle you've painted yourself in, but MW's Math plugin allows us to specify block display vs. inline display. Both can be done, with a flow container (<span>). With flow oriented HTML tags, if the bug is fixed. So don't presume to assume that MW has decided to override HTML+CSS intent for all time.

It's really simple. We can generate whatever content we want, assuming we pressure the devs to generate it correctly. So the focus and fight isn't here, in this alreaddy overly digressed thread. The fight is with the devs over at Phab.

I'm not, nor ever have been, trying to disparage you. You picked a fight, went passive aggressive early (c.f., the title of this ENTIRE subject, et al, dismissively cheap characterization of our initial conversation, etc.), and are trying to back out of the personal fight you picked.

Stop. Breathe. Recognize that in the big picture,

1. colon-indent anything, including math blocks, is never going to be supported by the parser. (BTW, colon-indent is 100% presentational markup, completely in violation of separation of content from presentation. Other lang wikis either center or left-align math blocks. Don't dictate indentation when it isn't semantic).
2. <math> can be emitted 100% as flow content, within <span>, if we have the MW Math plugin devs recognize the need to fix the emitted HTML.
3. CSS display=block is 100% legitimate, and not encumbered by semantic constraints, for flow tags like <span>.

 — sbb (talk) 00:25, 17 June 2023 (UTC)

trying to back out of the personal fight – yes that is correct, I never wanted a fight, and now I would like to back out. –jacobolus (t) 00:48, 17 June 2023 (UTC)

Agreed. Handshake, honestly and wholeheartedly. 🤝  — sbb (talk) 01:29, 17 June 2023 (UTC)

As an aside, in my opinion wiki markup with block elements (lists, math, figures, headings ...) clearly separated by blank lines is more legible than when they are crammed together, even in cases where the extra whitespace does not affect parsing. Separating mathematics blocks (and sometimes writing the LaTeX markup across several lines) makes it easier for source readers/authors to see that there is a block-level element and the appearance in markup matches the appearance in the output. This also encodes one kind of semantic intent – not intent about sentence grouping, but intent about whether an element should be visibly separated from the rest of the paragraph.

If I write:

The formula for such-and-such,

<math display=block>
f(x) = ...,
</math>

is so-and-so.

That is much more legible as markup, and IMO better conveys both semantic author intent and expected output, than:

The formula for such-and-such, <math display=block>f(x) = ...,</math> is so-and-so.

Which is just a big distracting wall of illegible markup overhead. –jacobolus (t) 16:21, 16 June 2023 (UTC)

In some contexts it is an absolute necessity to format the source of the display=block math as part of a paragraph of source, rather than setting it off by blank lines. For instance, in any kind of list environment, a blank line would interrupt the list, indent the math by the wrong amount (not accounting for its inclusion in a list), and start a new list.

More generally, your proposed multi-line format is semantically wrong. Again. —David Eppstein (talk) 17:37, 16 June 2023 (UTC)

In those contexts there is no need for a blank line because they are not output as HTML <p> elements, they have no restriction to only allow "phrasing" content nested inside, so there is no issue including block content inside. In such cases mediawiki does not emit invalid HTML and browsers are able to interpret it just fine. So they are somewhat of a tangent. I agree that given the way mediawiki markup is parsed, block math (or other block content) should not be put on a separate line in such cases.

"your proposed multi-line format is semantically wrong" – "Semantically right" output does not accord with the design of HTML. Block elements (whether formulas, figures, tables, lists, etc.) are not allowed in the middle of HTML <p> elements, full stop. It is simply impossible in HTML to "correctly" put block content in the middle of paragraphs. You can try to shoehorn block elements in using <span> elements that are then styled as separate blocks with CSS, but this is an abuse of the inline elements and is also somewhat buggy in results.

For better or worse, the design of HTML forces authors to encode separate chunks of "phrasing content" (i.e. prose and other objects that flow like prose) on either side of block elements as separate paragraphs with a separate block element in between.

The semantic structure of the text then does not precisely match the tree structure of the HTML markup, but that's the best we can do. –jacobolus (t) 18:00, 16 June 2023 (UTC)

The incorrect output semantics is merely a bug in rendering. It is your input that is semantically wrong, by formatting something whose intended meaning is one continuous paragraph of text (including a block formula) using a format that means three separate paragraphs. One cannot hope to get correct output semantics from incorrect input semantics. GIGO. You are encouraging our input to be garbage. —David Eppstein (talk) 18:09, 16 June 2023 (UTC)

One cannot hope to get correct "output semantics" no matter what one does. HTML does not allow it. But if we pretend and try to cram everything into a paragraph, what we get instead is completely broken invalid HTML that cannot be styled in CSS. If and when this bug is ever "fixed", the output is necessarily going to be what you call "garbage". So basically your preference amounts to, a bit snarkily phrased, "we should intentionally emit garbage on fire today because someday Mediawiki might be smart enough to put out the fire and emit mere garbage". –jacobolus (t) 18:12, 16 June 2023 (UTC)

What pretending? It really is a paragraph in its meaning. All else is hackery to work around formatting bugs. —David Eppstein (talk) 19:19, 16 June 2023 (UTC)

The fundamental issue is not "formatting bugs". The fundamental issue is that HTML was designed to never allow block content nested inside paragraphs. So in short: your mental model of how the markup should be structured is fundamentally in sharp conflict with what HTML is designed to accept / what browsers are designed to display. –jacobolus (t) 20:23, 16 June 2023 (UTC)

That is a matter for the back-end translation from markup to html. If we do not provide meaningful front-end markup, we cannot hope for the rendered appearance to correctly reflect our meaning. —David Eppstein (talk) 20:38, 16 June 2023 (UTC)

The rendered appearance should be as 2 separate paragraphs with block math in the middle. If we wanted to get fancy we can e.g. wrap the whole thing in an extra <div class=paragraph> or we can add an additional style to the trailing-content paragraph, say <p class=trailing> so that stylesheets can intentionally style the start of the paragraph differently from the end of the paragraph. If you want to accomplish this today you can emit that markup explicitly, instead of writing ordinary wiki-syntax paragraphs, though I would recommend against it.

One way or another, emitting a <p> element with any kind of block content wrapped inside is fundamentally broken and will never not be broken. It is mangled invalid HTML which does not render properly in readers' browsers. It just isn't how HTML works however much you might wish otherwise. –jacobolus (t) 20:47, 16 June 2023 (UTC)

INCORRECT. The rendered appearance should be as one paragraph consisting of three blocks of text, math, text. A paragraph is a semantic unit describing a meaningful sequence of text sentences. A rendered block of content in the visual appearance is a different thing. You should separate the meaning from the appearance rather than conflating the two.

This may seem like a subtlety but it does make a visual difference. For instance, in a style where the starting line of each paragraph is indented, the third block (second text block) should not have its starting line indented. —David Eppstein (talk) 21:13, 16 June 2023 (UTC)

The "correct" way to achieve a rendered appearance of "one paragraph consisting of three blocks of text, math, text" in HTML is by using the three HTML elements, <p>..</p> <div>..</div> <p>..</p>, optionally wrapped in a top-level <div> container or with distinct classes for the two <p> elements so they can be styled independently.

Trying to wrap the "internal blocks" of a paragraph inside a <p> element is always and inevitably broken invalid markup, not allowed by the HTML specification and not rendered properly by browsers.

You are trying to hammer a round peg ("semantic purity") into a square hole ("how HTML is specified to function"). –jacobolus (t) 21:28, 16 June 2023 (UTC)

The 'correct' way to achieve a rendered appearance of "one paragraph consisting of three blocks of text, math, text" in HTML is by using the three HTML elements, <p>...</p> <div>...</div> <p>...</p>, optionally wrapped in a top-level <div> container or with distinct classes for the two <p> elements so they can be styled independently. ... or, just as "correctly" (as in, 100% legitimate HTML, no abuse of the language), <p><span display="block">...</span></p>. 100% correct, supported by HTML+CSS, no problem at all. et voila, no need to hammer a round peg ('semantic purity') into a square hole, as you put it. And thus, no need to require wikitext to have blank lines around <math display="block"> blocks.  — sbb (talk) 23:38, 16 June 2023 (UTC)

I don't know anything about HTML and don't really care to, but certainly David Eppstein is correct about the semantic content. --JBL (talk) 00:14, 17 June 2023 (UTC)

100% agreed.  — sbb (talk) 00:17, 17 June 2023 (UTC)

Nobody thinks that mediawiki markup should be require[d] to have blank lines. The primary problem is that when the blank lines are not included, for the past 6+ years, the result has been broken HTML, and there is no sign that this bug will be fixed (the HTML is also slightly broken when the blank lines are included, but in a less harmful way). The secondary question is how precisely the bug should be fixed. Personally I expect the result would be better (easier for browsers and stylesheet authors) if mediawiki emitted separate paragraphs with an intermediate div. But I would be happy if the bug were fixed in whatever way more or less works. –jacobolus (t) 00:26, 17 June 2023 (UTC)

So we're back to assuming fatalism w.r.t. getting the bug fixed? This has has been... a lot of back-and-forth, just to get back to that point. So let's wrap this up: what else needs to be said, that hasn't been said, regarding this specific topic to enjoin me from making edits? Sincerely, I'm asking. ???  — sbb (talk) 00:33, 17 June 2023 (UTC)

This is not "fatalism". I'm cautiously optimistic that this might someday be fixed. I'm just not willing to put up with all of our technical pages having broken output in the mean time, especially since I have no evidence that any such fix is on the way. –jacobolus (t) 00:41, 17 June 2023 (UTC)

According to a Mediawiki developer "This cannot be done from the math extension as it does not know the context of the math element. So this can not be implemented in the near future." That doesn't sound particularly hopeful for any kind of prompt fix. In the (indefinite) mean time I would recommend we ask authors to put a blank line after every instance of <math display=block> as part of a top-level paragraph on Wikipedia. –jacobolus (t) 19:24, 20 June 2023 (UTC)

If you're going to recommend hacky workarounds, wouldn't it make more sense to wrap problematic paragraphs in <div> ... </div> and then NOT put artificial paragraph breaks within them, so that the math block div ends up nested inside another div (where it works) instead of nested inside a p (which breaks the html syntax)? See Special:Diff/1161125998 for an example. —David Eppstein (talk) 20:22, 20 June 2023 (UTC)

If you instead want to do something like:

<div class=paragraph><p>Leading text, </p><math>...</math><p>trailing text.</p></div> that would also be fine. But I doubt many Wikipedia authors want to put such a bunch of illegible markup overhead in the middle of their page. Even if we can wrap it in a template it's going to be kind of a pain.

By comparison, adding a blank line is pretty trivial, and if anything makes the source appear more like the rendered output. –jacobolus (t) 01:22, 21 June 2023 (UTC)

The biggest problem with your example is that you need to more explicitly tell stylesheets/user agents that your div is standing in for a paragraph. The most effective way to do this would be by adding explicit paragraph elements inside as I suggested just above. You could alternately try to establish some convention for a "class" to apply to the p-like div, and then advise everyone else on Wikipedia to adopt that one, so that stylesheet authors would know which divs were really supposed to represent paragraphs. One slight issue is that it's then a bit hard to style those "fake paragraphs" one way but style the math or other block elements contained inside them a different way that properly spills out of the paragraph container. I think the CSS may be achievable, but it's going to require some experimentation and maybe some annoying CSS hacks. –jacobolus (t) 01:31, 21 June 2023 (UTC)

@David Eppstein you might find the blank lines less unsavory if you mentally reinterpret the <p> to mean "contiguous block of prose" rather than "paragraph" per se. This interpretation accords much more closely with how browsers actually interpret (and web authors actually use) the <p> element in practice.  :-) –jacobolus (t) 01:36, 21 June 2023 (UTC)

Here is a single contiguous block of prose:

"An affine permutation is a list $[u_{1},\ldots ,u_{n}]$ of $n$ integers such that

$$u_{1}+\ldots +u_{n}={\binom {n+1}{2}}$$

and exactly one $u_{i}$ is conjugate to $j$ modulo $n$ for each $j$."

Indeed, it is a single sentence. As I said, I don't know much about HTML, but it seems obvious to me that any good outcome necessarily must respect that structure. I don't see any point in doing formatting hacks if the result is not going to be compatible with a good outcome; it's like how lots of equations all over WP have ridiculous \, in them still because once upon a time a decade ago that forced PNG or SVG or something. --JBL (talk) 17:33, 21 June 2023 (UTC)

This is very clearly not a contiguous block of prose. It is three separate visual blocks, two consisting of prose and one consisting of an indented and whitespace padded mathematical equation. Every typesetting system on the planet, whether chalkboard, pen and paper, hand-set metal in a printing press, MS Word, Indesign, or LaTeX treats this as 3 separate visual blocks. (Some systems have a richer set of primitives which treat "paragraphs" and "blocks of prose" as separate kinds of objects. HTML conflates the two, and the "p" tag is closer to representing the latter than the former.) –jacobolus (t) 19:06, 21 June 2023 (UTC)

Thanks for fixing the weird problems the reply-tool caused. As I say, I don't know at the level of the machine what's going on, but semantically what I have written it is a single block and this is certainly recognized by LaTeX, which would (correctly!) interpret the stuff following the displayed equation as part of the same paragraph as the stuff before it. A good system should involve me writing semantically sensible things and having the output work correctly; LaTeX does this right. You are arguing that the fix to a problem I personally cannot see is that instead people should write things that are semantically wrong; I think it would make more sense for you to think about, among all semantically correct ways for people to write, which one produces the best outcome (either now or in some future where something I don't understand is changed by the developers, whoever they are), and argue that people do that. At least, I personally would take such an argument much more seriously -- I am tired of deleting absurd \, from equations, and ten years from now I would not like to be tired from deleting [hopefully what will then be seen as] absurd blank lines around displayed equations. --JBL (talk) 19:22, 21 June 2023 (UTC)

problem I personally cannot see – the problem here is that there's a bunch of generated prose in the generated markup that is not included in any paragraph, which makes it completely impossible for CSS to style it. If you never try to apply a stylesheet to Wikipedia that tries to style paragraphs, you will see no difference. But if you do want to style paragraphs, you're completely out of luck. –jacobolus (t) 20:13, 21 June 2023 (UTC)

If you do want to style paragraphs under your proposed workaround of breaking everything into little marked-up-as-paragraph sentence fragments, you're still completely out of luck, because you will be styling them as whole paragraphs (for instance indenting the first line if that is your style) when they are not really intended as whole paragraphs. —David Eppstein (talk) 20:45, 21 June 2023 (UTC)

From my perspective, your argument can be more or less paraphased as "we should emit completely invalid malformed HTML because emitting more-or-less-okay HTML still wouldn't be perfect." I think that's a crummy place to come down, and I have a personal interest because this completely breaks my own stylesheet (in my logged-in browser, your experiment removing all the <p> elements at Sophie Germain's identity makes it now the least legible page on Wikipedia.) But YMMV. –jacobolus (t) 21:33, 21 June 2023 (UTC)

your experiment removing all the <p> elements at Sophie Germain's identity makes it now the least legible page on Wikipedia [...] But YMMV. Please, let's calm down and de-escalated. Saying a page that is 2 days old is the "least legible page on WP" is a bit hyperbolic, don't you think? Let's all step back and breathe a bit on this. I'm as guilty as you for having getting heated, but let's slow down. Please.  — sbb (talk) 00:32, 22 June 2023 (UTC)

In my browser, yes, it is the least legible, because (unlike nearly any other page on wikipedia) it breaks my browser's ability to style paragraphs. This is not intended to be an "escalation", I am just reporting my experience. –jacobolus (t) 16:54, 22 June 2023 (UTC)

That is an incorrect and uncharitable paraphrase of my argument. My argument is actually that both the semantically-correct wikimarkup (paragraphs with displayed equations within them) and the hacky split-up-into-fragments workaround that you are pushing so hard are broken, in different ways, but both legible. Given that it is impossible to produce non-broken output now, we should prioritize getting the wikimarkup correct, in the hope that it will eventually become unbroken (by using spans instead of divs). Your alternative would leave us with permanently broken wikimarkup and a big messy cleanup job that you are leaving as a debt of work for later editors. —David Eppstein (talk) 01:59, 22 June 2023 (UTC)

I think you are missing my main point though.

Currently most block math on Wikipedia uses colon indention, which results in the HTML elements (p, dd, p). This is technically an abuse of the dd element, but it has been more or less working for nearly all readers since the beginning of Wikipedia, and matches the way every other kind of block element is handled on Wikipedia. It works with all of the major browsers, user stylesheets, other tooling, etc. but unfortunately some screen readers don't deal with it well. (Aside: It's still not clear to me what their issue is and whether our alternatives are accessible.)

If we find/replace every example of colon indentation and replace it with display=block, the result is instead (p, div, orphan text fragment), which is broken (today) given a technical failure which has existed since the beginning of display=block and whose back-end solution has no clear timeline.

This is a clear regression (among 2–3 other problems with display=block which I laid out above), so I am asking in this thread if we can hold off on doing this mass find/replace job until the technical problem that causes the issue is fixed (and ideally the other issues as well). If such a mass find–replace is done, every single technical article on Wikipedia will become significantly less readable for me, making my Wikipedia browsing experience dramatically less pleasant. The phantom scroll bar and poor floating image collision handling issues also impact a substantial number of pages switched to display=block, and are a significant regression in experience for literally every reader of Wikipedia.

As a workaround for the first issue, I suggested we could instead add a blank line after every instance of display=block, which would instead result in (p, div, p). This would be effectively the same structural HTML (but with a div instead of dd element) as the original colon indentation. So if we do the find–replace of colon indentation for display=block but add this workaround, there is at least one of the three significant regressions that will be avoided.

My impression of your argument is "I don't think regressions in reader browsing experience matter in comparison to the 'semantic purity' of the wiki markup (with eventual technical fix someday in the indefinite future)". Which seems like a very reader-hostile take to me. But YMMV. –jacobolus (t) 17:06, 22 June 2023 (UTC)

Again, you are misreading my argument, after it has been explained to you several times, starting to rise to the level of WP:IDONTHEARTHAT. All current variations are broken, in different ways. Indenting with a : is broken. Breaking up sentences into fragments by blank lines is broken. All current variations produce somewhat-legible output, especially if you don't run custom scripts that interact who-knows-how with Wikimedia. Given that there is no current way of producing output that is not broken in some way, and no serious harm to readers in choosing whichever way we choose, we should go with the way that preserves the most hope of eventual non-broken output, which is to mark up the input with the intended semantic meaning. —David Eppstein (talk) 17:38, 22 June 2023 (UTC)

Breaking up sentences into fragments is not "broken" and calling it "broken" is "uncharitable" at best. This markup just aligns the markup with the visual structure of the document – for better or worse, the way HTML has always been designed to work, and the same way every other block element in HTML also works – rather than the sentence structure (the way you personally imagine wiki markup to work, without any obvious rationale). Your problem is with the creators of HTML from the 1990s, but as a result you are trying to pound a round peg into a square hole.

What you are recommending causes nontrivial harm to readers today for no discernible benefit today, based on a hope in some future benefit which may never materialize.

no current way of producing output that is not broken in some way – then we should favor the status quo ante (colon indentation), which is currently working for most readers and tools, instead of allowing significant regressions.

If we are concerned about accessibility, we should directly solicit advice from readers / screen reader software creators who currently have a problem with it (which, again, has still not been described), and design a solution which actually works for them. As far as I can tell the switch from colon indentation to display=block does not actually make the resulting HTML markup accessible to screen readers. It's still an opaque blob of LaTeX code. We shouldn't vaguely handwave toward "accessibility" to justify regressions in everyone else's experience. –jacobolus (t) 18:04, 22 June 2023 (UTC)

without any obvious rationale Surely it is obvious that this is an encyclopedia, written in natural language, and the basic units of meaningful natural language are the sentence and the paragraph? I mean I guess we could insist that editors put a line-break after every word, or after every punctuation mark, or ..., but that would be insane. --JBL (talk) 18:43, 22 June 2023 (UTC)

Let me phrase this a different way: Why should block mathematics be treated differently from every other kind of block content (list, quotation, table, figure) in Mediawiki markup and in HTML everywhere else on the web? Any of these kinds of blocks can be meaningly inserted in the middle of a paragraph (or sentence even), but none of them is allowed to be included in an HTML <p> element, or ever has been. You can argue that this is a bad design, but it makes clear what the internal mental model was for the creators of HTML: the <p> element was designed to represent a contiguous block of inline prose, rather than a "paragraph" per se. –jacobolus (t) 20:49, 22 June 2023 (UTC)

Let me guess: You also use plain TeX and advocate the abolishment of LaTeX, because manually formatting everything rather than describing its semantics and letting the formatter do the formatting is closer to the mental model from Knuth's original design? —David Eppstein (talk) 20:52, 22 June 2023 (UTC)

You may have intended that as a snarky jab, but in the name of comity, I'll answer your question frankly:

I generally use plain text with implicit formatting encoded in the visual structure, because I think it's an incredible pain to deal with fiddly markup languages, which for most uses are overkill.

Where that text needs to be turned into some kind of publishable structured output, my first preference would be to use InDesign or a similar tool that gives a user simple visual control over the output because I have very high standards and making LaTeX output truly excellent instead of kinda-sorta-acceptable-if-you-squint is always a gigantic pain in the rear.

For light-duty uses, markdown is much more pleasant than LaTeX (or HTML, or Mediawiki markup). But I can use LaTeX where necessary for collaboration. All the best. –jacobolus (t) 20:59, 22 June 2023 (UTC)

Well, that explains your attitude, at least. As you say, "making LaTeX do what I want is always a gigantic pain in the rear". It is a pain in the rear because it is a mistake. If that is how you are using LaTeX, you are doing it wrong. The right way to use LaTeX is to describe the semantic structure of your document and let LaTeX do what it wants to format it. Using LaTeX in that way becomes much easier. If you have to achieve a specific appearance rather than a canned one, you can hack up the style file instead, but that's something of a black art.

Frequently for situations where LaTeX is appropriate (scientific publication) you are going to have to follow the publication's formatting design rather than your own, anyway, and semantic markup rather than format-based markup is a much more robust way to make your document flexible enough to handle formatting changes, without having to do all the same work over again when you want a different format.

Similar responsiveness to formatting changes is also necessary for Wikipedia, where we have many different skins available for different readers, not to mention users of screen readers and the differences in formatting in browser versus mobile views. For that reason, using a semantic markup rather than a format-based markup is a good idea, so that the conversion to the reader's desired view can be done on a format-by-format basis. The alternative approach, in which editors hack up the source in whatever way they can find to optimize the appearance to their taste, risks unknowingly making it worse for everyone else reading under different skins, or even under future versions of the same skin. —David Eppstein (talk) 21:25, 22 June 2023 (UTC)

Also "everyone else" here apparently is just you: maybe there is another editor who experiences this problem, but you're the only person I've ever seen assert it. Perhaps you over-estimate how common it is for readers to use personalized CSS or whatever when viewing Wikipedia. --JBL (talk) 18:45, 22 June 2023 (UTC)

I do actually use custom CSS from my Wikipedia preferences, also, but not in a way that is affected by this. (Mine bumps the font size to 110% and makes {{orphan}} banners visible.) —David Eppstein (talk) 19:06, 22 June 2023 (UTC)

Yeah please read an implicit "that is affected by this issue" into my comment. --JBL (talk) 20:43, 22 June 2023 (UTC)

The fundamental problem is that <p> is broken by the requirement of compatibility with old old html that failed to close its tags, and is therefore unable to contain nested block-level content. Like the oldest of html tags, it is a bad mix of semantics and formatting locked together. The solution is to replace it by something like <div class="paragraph"> that can handle multiple interior blocks, with divs nested inside it for each block if necessary, and with css to make it otherwise behave like <p> There is no technical reason why the mediawiki conversion from wikimarkup to html could not do it this way. Nobody will care that their paragraphs are marked up as divs instead of ps. —David Eppstein (talk) 01:15, 17 June 2023 (UTC)

Honestly, I'm not sure this is the case (that <p> tags aren't closed by the MW parser, at least as an attempt, in the whole). I've been through the parser engine, and it seems MW parser tries to close <p> tags as much as possible (probably because of XHTML days' strict XML-based open/closed philosophy, which IMO is a noble effort).  — sbb (talk) 01:28, 17 June 2023 (UTC)

Oh, the issue of p tags not being closed has nothing to do with Wikimedia. It is an issue with old-days html when html was hand-coded and people didn't close some tags. I still have lots of more or less hand-coded pages where that is the case. But because of that issue, p has been defined to be auto-closed when any other of various block-level tags starts. I'm not sure whether it is actually impossible to nest a block-level tag within a p, or whether it can be done by using a non-standard tag that you have set to be block-level, but it definitely doesn't work to nest a div within a p, by definition in the html standards. On the other hand, nesting a div within a div is non-problematic. —David Eppstein (talk) 06:26, 17 June 2023 (UTC)

The implicit closing is done by the browser, not the Mediawiki parser. Mediawiki emits malformed HTML such as

<p>Here is a formula, <div class="mwe-math-element">...</div> and here is text afterward.</p>

then when the browser sees that, it implicitly closes the <p> tag before the <div> and turns it instead into:

<p>Here is a formula,</p><div class="mwe-math-element"> ... </div> and here is text afterward. <p></p>

See User:Jacobolus/math block example for slightly more detail. –jacobolus (t) 14:00, 17 June 2023 (UTC)

As an aside, the Mediawiki parser will do (what I would call) the "right thing" if you try to nest some other kind of block element inside a paragraph. If you explicitly add the following raw HTML to a wiki page:

<p>Here is a list, <ul><li>one</li><li>two</li></ul> and some trailing text.</p>

it gets turned into:

<p>Here is a list, </p><ul><li>one</li><li>two</li></ul><p> and some trailing text.</p>

with two separate paragraphs and the block element in between. My proposal for a bug fix for block math in a paragraph would be for Mediawiki to do exactly the same thing with block math that it already does with any other block element put in the same place. –jacobolus (t) 14:10, 17 June 2023 (UTC)

that can be fixed in the Math plugin code – it is not reasonable to rely on some future fix from the Mediawiki developers, who have in general made it clear that they don't care very much about either math rendering or accessibility. We should try to find the best available workaround solutions today using the currently available technical tools as possible (including e.g. making new templates) instead of hanging our hopes on potential changes that might happen years down the line. –jacobolus (t) 19:31, 15 June 2023 (UTC)

Disagreed. I don't think that's charitable of the developers. Bugs don't fixed if they're shown the light of day. In the meantime, I strongly believe that we should write the best wikitext we can, based on WP:MOS and Help guidelines, rather than hack too much with templates. <math display="block"> is the officially-supported way forward for the time being (since around 2015 or so), and are not so bad as to require poor work-arounds, IMO.  — sbb (talk) 19:52, 15 June 2023 (UTC)

The ideal technical fix would be for the Mediawiki developers to recruit some group consisting of users and/or developers of screen readers or other accessibility tools and math wikipedia authors and figure out how to make both a block math mode and an inline math mode that render well on desktop, mobile, and in screen readers, including designing features for whatever accessibility fallbacks are required to make the pages fully accessible, helping us write documentation for authors to take advantage of those features, and trying to roll them out on technical pages. Ideally there should e.g. be a way to specify separate output depending on the width of the window, so that a wide formula could have additional line breaks when viewed in a mobile browser. Ideally they would adopt Mathjax or KaTeX and expose the full feature set of those implementations, instead of Wikipedia having its own limited LaTeX implementation that requires piles of workarounds to achieve basic formulas. But I don't see this kind of thing happening.

The quickest and most painless technical fix for this more limited issue would be for the mediawiki parser to interpret : starting a line without a preceding ; line to mean "indent this text" rather than "definition in a definition list". It could be inserted into the HTML as e.g. <div class="indented"> with the appropriate indentation style defined in CSS instead of as a <dl><dd>. That would have the side benefit of also fixing the longstanding problems with using colons for indentation in talk pages, and would stop complaints about "invalidity" of HTML. But that also seems unlikely to happen.

In the mean time, I wonder if anyone is interested in experimenting with other potential templates for indentation. –jacobolus (t) 20:23, 15 June 2023 (UTC)

I suspect the developers would be even less interested in your "quickest and most painless technical fix" than they are with fixing math markup: because it doesn't advance their goal of making the markup carry semantic meaning both on the wikicode side and on the html-to-browser side. Mixing two unrelated meanings of : doesn't do that. —David Eppstein (talk) 00:02, 16 June 2023 (UTC)

Fair enough, but : has implicitly carried the meaning of "indent this text" on Wikipedia (esp. talk pages, but also article pages) since the beginning of the site, because it was easily available and alternative methods of achieving the same (basic and obviously necessary) task were inferior or impossible. Making that user- and community-friendly technical change would be an example of paving the cowpaths, recognizing an obvious need that Wiki contributors surfaced organically and making it convenient and retroactively "correct". –jacobolus (t) 00:58, 16 June 2023 (UTC)

Unfortunately, this is simply what must happen. It's clear that WP (by that, I mean MOS/Help pages) are willing to cede Talk: namespace to the colon-devil (because, frankly, MW markup is horrible as a chat/messaging format, but having multiple markups in the engine depending upon namespace is objectively a worse solution). But from the standpoint of "what would hypothetically generate the best possible print version of WP", clean semantic & accessible markup in article space is the guidestone, and anything less should be at most begrudginly tolerated. IMO.  — sbb (talk) 03:04, 16 June 2023 (UTC)

If generating the best possible print version of Wikipedia were the highest priority, we certainly wouldn't be using "straight quotes" everywhere. –jacobolus (t) 06:43, 16 June 2023 (UTC)

Curly quotes seems like a tangent. Let's keep this on subject.  — sbb (talk) 13:50, 16 June 2023 (UTC)

Poking at straight quotes is somewhat flippant, and is a bit of a cheap shot because straight quotes are ugly as sin, but there's a serious point lurking under the snark, which is that Wikipedia is about compromise between a wide range of conflicting interests, not any kind of absolute correctness. Anyone who knows the first thing about typography will tell you that straight quotes are unacceptable to use in any serious context. But here at Wikipedia we nonetheless settled on them (largely by consensus!) for convenient input on the widest range of author keyboard input methods (whose conventions were established by typewriters of the 19th century and have nothing to do with "print" of any kind, and certainly not "the best possible print"). –jacobolus (t) 01:24, 17 June 2023 (UTC)

Off-topic. Please keep this on topic for WP:Math. Thanks.  — sbb (talk) 00:06, 22 June 2023 (UTC)

I created two new bug reports, https://phabricator.wikimedia.org/T339996 and https://phabricator.wikimedia.org/T339999 after not finding these problems reported before. ––jacobolus (t) 00:52, 21 June 2023 (UTC)

I am having a hard time trying to follow the argument here. I usually use ":" when I want to indent for a paragraph, display equation, or quotation. and follow that with a blank line to prevent additional text from being sucked into the structure. I mostly find myself in agreement with "jacobolus" (he may not want my support since I am ignorant of this topic). JRSpriggs (talk) 00:25, 23 June 2023 (UTC)

@JRSpriggs The issue with using : for indentation is that it doesn't officially mean "indent this content". What it actually does is creates a new "definition list" with no terms to define, only definitions (<dd>, "description details" elements). This works alright in practice for most wiki authors and readers, but formally it is an abuse of the definition list element to do something it was not originally intended to do, and some screen readers (web browsers for blind people) apparently make weird noises when they encounter such a list. Years ago the <math display=block> mode was added to the math plugin to make "indent this block of math" part of the core tool instead of hacking that effect via definition lists, but there are some bugs and adoption has been slow, so most math on Wikipedia is still indented using the : method.

I'm still not really clear on which screen readers have an issue (all of them? some of them? some old ones from 10 years ago that nobody uses anymore?), precisely what issue they have, or whether the display=block generates output that is at all accessible to users of screen readers. But I would love to hear from someone who knows more about this, because I definitely want to make our technical articles as accessible as we reasonably can do given available volunteer resources. –jacobolus (t) 00:53, 23 June 2023 (UTC)

Tuple

There has been some edit-warring going on at Tuple between User:D.Lazard and an anonymous editor. I've temporarily semi-protected it (probably in the wrong version), and I assume Lazard knows not to violate 3RR, but this could use the attention of other editors. See also discussion at Talk:Tuple#Names for tuples of specific lengths. —David Eppstein (talk) 00:57, 24 June 2023 (UTC)

Template:Infobox mathematical statement

This template is apparently around since 2019, but I just became aware of it recently (due to user systematically adding it to math articles). Has their been any discussion or agreement how and whether to use that template? After all it affects potentially every theorem and lemma.--Kmhkmh (talk) 12:27, 24 June 2023 (UTC)

Can you give an example of where this template has been added, so we know what it looks like and what we are talking about? PatrickR2 (talk) 18:59, 24 June 2023 (UTC)

Special:WhatLinksHere/Template:Infobox mathematical statement. —David Eppstein (talk) 19:03, 24 June 2023 (UTC)

I vaguely remember arguing against ever including such an infobox long ago, on the basis of WP:DISINFOBOX: there is no room for subtlety or nuance in an infobox. It assumes that every statement can have at most three discrete events in its history: someone stated it at some precise time, someone conjectured it at some precise time, and then someone proved it at some precise time. For that matter, even the example infobox given in the template documentation is bad: its image is unintelligable and its image caption is a whole paragraph of text. I'm not sure where to find that past discussion. I would still argue against ever using this. —David Eppstein (talk) 19:02, 24 June 2023 (UTC)

I'd like to add that there may exist important 'mathematical statements' which are not proven and will never be, because they have been disproven already. As such, they could not be correctly described with the template in question. For example, a so-called Borsuk's conjecture. --CiaPan (talk) 21:17, 24 June 2023 (UTC)

I'd generally recommend removing these infoboxes from the articles I have seen them used in. They are redundant to the immediately adjacent text and have little if any benefit, while adding metadata that is often largely trivial or obvious and taking up space/reader attention. If someone thinks it's helpful to put an outline around a theorem statement, go ahead and just include it in the version in the text. Even add a pale background color if you want to go all out (subject to consensus from other authors of each specific page).

As an example, there is one in Goldbach's conjecture. The article leads with "Goldbach's conjecture is one of the oldest and best-known unsolved problems in number theory..." then continues in the first section "On 7 June 1742, the German mathematician Christian Goldbach wrote a letter to Leonhard Euler...". The infobox repeats this as: "Field: Number theory; Conjectured by: Christian Goldbach; Conjectured in: 1742; Open problem: Yes ...". –jacobolus (t) 19:55, 24 June 2023 (UTC)

I'm just seeing now that the template was already proposed for deletion at some point, but there was no consensus to delete it:

• Wikipedia:Templates_for_discussion/Log/2019_February_24#Template:Infobox_mathematical_statement

Nevertheless there was clearly no consensus for its use either. Personally I'm not opposed to infoboxes in principal, in some areas they are well established and somewhat useful (for instance movies, countries, cities, etc.), but I dislike the "trend" to push infoboxes into any article and in particular adding it to all the math articles about theorems and lemmata strikes me as a bad idea. Maybe we could add a note to the template, pointing out that its use is somewhat controversial/not encouraged? Otherwise its mere existence might lead (well meaning) Wikignomes astray. --Kmhkmh (talk) 21:25, 24 June 2023 (UTC)

Peer Review for Po-Shen Loh

I think y'all at Wikiproject Mathematics may be interested in looking into this peer review - I am planning to get a quick check before a GAN to see what else I may need to do before starting a GAN. — Prodraxis {talk • contributions} (she/her) 16:45, 28 June 2023 (UTC)

Math notation accessibility

Does anyone here know whether and where there has been previous discussion of accessibility of formulas on Wikipedia, or what the general best practices are for accessibility of mathematical notation online? Where would be the best place to find readers who need assistive technologies to read Wikipedia to ask them about their current experience? I'm especially thinking about screen readers here, but also happy to discuss other tools.

My speculation (based on a total lack of understanding or experience) is that screen readers would choke badly on formulas, whether expressed as LaTeX or math templates. Is that an accurate guess, or are there some screen readers smart enough to make sense of math notation? How are formulas rendered in practice by screen readers and other alternative user agents?

If mathematical notation is an accessibility problem, is there some way wiki authors can provide a fallback formula written as plain text that screen readers would read to the standard math notation? It would be a ton of work to spell out English pronunciation for every bit of mathematical notation on Wikipedia, but if the technical means were available I'd at least consider trying to add such a fallback on pages I'm spending a lot of work on anyway. –jacobolus (t) 20:40, 22 June 2023 (UTC)

Sorry about my total ignorance on this topic, but what are we talking about here? Is it about blind people wanting to read wikipedia? I imagine for regular non-math articles, there would be text to speech and they can listen to that. For mathematical formulas, not sure. I apologize in advance for my lack of sensitivity, but are there really many blind people who would need to read complicated mathematical formulas while on their own, i.e., who don't have access to other people to read and explain the formulas to them? PatrickR2 (talk) 05:11, 23 June 2023 (UTC)

I imagine Latex formulas enclosed in <math> and </math> would be easier to process automatically. One more argument for using that, and not the manual formatting solutions proposed earlier by Michael Hardy. PatrickR2 (talk) 05:15, 23 June 2023 (UTC)

@PatrickR2: I find it strange that someone thinks I expressed a preference for "manual formatting solutions" over LaTeX. Michael Hardy (talk) 21:06, 26 June 2023 (UTC)

@Michael Hardy I was referring to the earlier discussion "Why can't mathematicians spell?". You expressed (and edited articles showing) your preference for the use of manually fiddling with "& nbsp;" instead of relying on LaTeX surrounded by "<math></math>". PatrickR2 (talk) 21:47, 26 June 2023 (UTC)

@PatrickR2: No, I did not. Michael Hardy (talk) 00:36, 29 June 2023 (UTC)

Yes I am talking about blind people wanting to read Wikipedia. A purported problem that screen readers have with <dd> elements is the primary reason we are supposed to eliminate the use of : indentation (the claim is "colon indentation is not accessible"), but I noticed that I haven't ever actually heard from any screen reader listeners about math article accessibility. So I am curious if our formulas are in fact at all accessible.

I just tried the Mac VoiceOver tool (which has no problem whatsoever with colon indentation), and in my opinion our LaTeX formulas are not at all accessible using that tool, unless maybe to an extremely committed and experienced listener willing to make a lot of inferences.

Numerical exponents and coefficients are read identically, square roots are not read, fractions are not indicated and there is no audio distinction between numerator and denominator, in multiline equations it is difficult to understand the intended alignment of different parts, various irrelevant features of the markup are read out, etc.

I'm skeptical that our LaTeX formulas can be made at all sensible without some kind of explicit fallback text, but I admit I am largely ignorant about this whole subject. –jacobolus (t) 05:44, 23 June 2023 (UTC)

Blind people definitely use LaTeX for mathematics and we should stick with that. I don't think it is up to WikiMedia to invent some new way of outputting it to blind people but if there is som good software out there they could be asked to incorporate it. Otherwise it is up to whatever is the blind persons favourite reader and we provide the LaTeX. No I do not think fallback text is a good idea to pursue. NadVolum (talk) 15:53, 24 June 2023 (UTC)

Can blind people make sense of Wikipedia's current formulas using their commonly used screen readers, is my question? If not, are there ways we could make that output more accessible?

I am a sighted person with basically no screen reader experience, so my experience should not be taken as meaningfully conclusive, but my impression trying to look at Wikipedia articles with the Mac VoiceOver tool was that our current mathematical notation output is largely useless and inaccessible.

As a related question: what is the current industry best practice for making websites with mathematical notation accessible? Are there any good examples of accessible mathematical web pages that we could look at or take inspiration from? –jacobolus (t) 19:44, 24 June 2023 (UTC)

I'd suspect Latex in doubt makes it easier for sight impaired people, because whatever additional tools you might to create audio or braille for formulas, those are probably are more likely to work with Latex (as the widely adopted standard) than with a mix of wikipedia templates.

Aside from the accessibilty for sight impaired, I personally prefer Latex to template solutions, as it provides one standard pretty much anybody writing math texts is already familiar with and which is used across all language wikipedias, whereas that is not true for various template solution. I regard that as more important than templates yielding currently slightly better renderings.--Kmhkmh (talk) 17:25, 24 June 2023 (UTC)