I would appreciate it if someone else could add their feedback here. -- JBL ( talk) 17:07, 1 June 2023 (UTC)
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)
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)
focus on its subjects' victimization by societyto be reasonable, given the history of misogyny. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 14:51, 2 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 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)
no expertise in the fieldis 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)
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)
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)
Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sourcesPatrickR2 ( talk) 20:47, 4 June 2023 (UTC)
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)
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)
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)
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)
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)
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)
I found this in the article titled Bessel function:
Plot of the Hankel function of the first kind H(1)
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(1)
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:
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)
{{math|-2-2i}}
by manually adding " " 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)
<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)
<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 where you should see 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)<math>...</math>
for LaTeX. --
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 11:25, 15 June 2023 (UTC)
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){{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)
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):
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)
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)
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)
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>
:
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.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.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)
{{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?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)
They have promised to continue such edits, saying (paraphrased) "don't tell me what to do".
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.).
<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.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 aboveis 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.
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'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.
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 CSSFinally, 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...
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.
<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.<math>
blocks. And yes, the behavior is different when disply="block" is applied. I get that. And no, it shouldn't be, I agree.<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.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.
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.
:
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.
<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.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.
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 eitherYou'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== Heading ==
or==Heading==
without any effect.
<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. ...
:
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.<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.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.
<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)
<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>
<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".<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)
<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.<div class=paragraph><p>...</p><div class=math>...</div><p>...</p></div>
<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.<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.
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...
<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.<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.<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.<span>
.The formula for such-and-such, <math display=block> f(x) = ..., </math> is so-and-so.
The formula for such-and-such, <math display=block>f(x) = ...,</math> is so-and-so.
<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.<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.<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)
"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.<p>
element is always and inevitably broken invalid markup, not allowed by the HTML specification and not rendered properly by browsers.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,... or, just as "correctly" (as in, 100% legitimate HTML, no abuse of the language),<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.
<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)
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)
"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)<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.<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)
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)
<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)
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.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.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.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.
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 rationaleSurely 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)
<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)
<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)
<p>Here is a formula, <div class="mwe-math-element">...</div> and here is text afterward.</p>
<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>
<p>Here is a list, <ul><li>one</li><li>two</li></ul> and some trailing text.</p>
<p>Here is a list, </p><ul><li>one</li><li>two</li></ul><p> and some trailing text.</p>
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)
<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)
:
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.:
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)
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)
:
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.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)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)
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)
I'm just seeing now that the template was already proposed for deletion at some point, but there was no consensus to delete it:
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)
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)
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)
<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 would appreciate it if someone else could add their feedback here. -- JBL ( talk) 17:07, 1 June 2023 (UTC)
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)
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)
focus on its subjects' victimization by societyto be reasonable, given the history of misogyny. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 14:51, 2 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 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)
no expertise in the fieldis 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)
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)
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)
Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sourcesPatrickR2 ( talk) 20:47, 4 June 2023 (UTC)
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)
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)
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)
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)
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)
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)
I found this in the article titled Bessel function:
Plot of the Hankel function of the first kind H(1)
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(1)
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:
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)
{{math|-2-2i}}
by manually adding " " 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)
<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)
<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 where you should see 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)<math>...</math>
for LaTeX. --
Shmuel (Seymour J.) Metz Username:Chatul (
talk) 11:25, 15 June 2023 (UTC)
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){{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)
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):
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)
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)
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)
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>
:
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.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.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)
{{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?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)
They have promised to continue such edits, saying (paraphrased) "don't tell me what to do".
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.).
<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.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 aboveis 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.
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'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.
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 CSSFinally, 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...
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.
<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.<math>
blocks. And yes, the behavior is different when disply="block" is applied. I get that. And no, it shouldn't be, I agree.<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.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.
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.
:
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.
<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.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.
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 eitherYou'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== Heading ==
or==Heading==
without any effect.
<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. ...
:
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.<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.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.
<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)
<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>
<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".<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)
<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.<div class=paragraph><p>...</p><div class=math>...</div><p>...</p></div>
<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.<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.
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...
<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.<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.<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.<span>
.The formula for such-and-such, <math display=block> f(x) = ..., </math> is so-and-so.
The formula for such-and-such, <math display=block>f(x) = ...,</math> is so-and-so.
<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.<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.<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)
"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.<p>
element is always and inevitably broken invalid markup, not allowed by the HTML specification and not rendered properly by browsers.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,... or, just as "correctly" (as in, 100% legitimate HTML, no abuse of the language),<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.
<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)
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)
"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)<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.<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)
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)
<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)
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.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.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.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.
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 rationaleSurely 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)
<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)
<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)
<p>Here is a formula, <div class="mwe-math-element">...</div> and here is text afterward.</p>
<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>
<p>Here is a list, <ul><li>one</li><li>two</li></ul> and some trailing text.</p>
<p>Here is a list, </p><ul><li>one</li><li>two</li></ul><p> and some trailing text.</p>
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)
<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)
:
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.:
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)
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)
:
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.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)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)
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)
I'm just seeing now that the template was already proposed for deletion at some point, but there was no consensus to delete it:
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)
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)
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)
<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.