By the way, are there any reasons, besides historical, to specify image sizes in “pixels” (which nowadays often don't correspond to actual device pixels) instead of font units (such as em)? I see at least several benefits in using font units:

1. The image size usually needs to be commensurate with the nearby text (including reasonably sizing text labels in the figures), so font units are much more natural in this respect.
2. Sometimes adjustments to the default size are made to accommodate the caption properly, which is difficult to do in pixels, taking into account different font sizes in different skins (and browser settings).
3. For advanced texts, “symbols” (for example, ancient glyphs) that do not exist in Unicode (or common fonts) need to be embedded in text or tables and should be sized and scaled according to the surrounding font size; see two previous arguments about pixels in this context.
4. For SVG images (in particular, see “symbols” above), pixels are not even intrinsically meaningful.

In T201233#10714102, @Physikerwelt wrote:

We could check if it’s a div —> block or a span —> inline

In T201233#10713566, @Jdlrobson-WMF wrote:

• Edit the page to force onto new lines https://en.wikipedia.org/w/index.php?title=Pi&diff=1283938085&oldid=1283399385

Please revert ASAP, since it breaks many WP articles (examples).

For consistency, the scope is actually broader than the title says:

1. The same background should be used for all image formats supporting transparency (PNG, GIF, what else?), not only SVGs.
2. There should be an option to apply the filter regardless of transparency (particularly, to images with opaque white background).

@matmarex Probably not automatically. I mean, some very bright photos could look too harsh on a dark page and might benefit from dimming (case-by-case), but generally good photos have reasonable average lightness to avoid overexposure within the display dynamic range an look fine on both light and dark backgrounds.

Here is an illustration of the proposed change described above (for the dark mode; the light mode is obvious) from the same page edited in DOM/style inspector ("Current" is the same as "Plain" in the original):

The idea of using color-disabled as background was bad to begin with. Because this color is supposed to have sufficient contrast w.r.t. white, and thus there is a great chance that it can be used for meaningful elements in drawings, so placing them on such background would make these elements invisible (as can be seen in the example). But it is, not surprisingly, very much in line with the silly modern fashion when light themes use gray text on white background (poor readability with excessive brightness) instead of black text of light-gray background (good readability with comfortable brightness). The proper way to avoid bright white spots in dark mode would be to use normal white background under the image and then reduce the overall lightness by something like filter:brightness(80%), similarly to the class=skin-invert mechanism (either by default, with a possibility to override by class=skin-dont-dim, or as an option with class=skin-dim). This would also work consistently for images that have hard-coded white background, as opposed to the current mess when images with and without background are used (see https://en.wikipedia.org/wiki/Oblique_projection#Examples for an example; it's a gallery but has the same problem).

This change has been broken by some further edits, see https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_218#Thumbnail_background for some history and examples. I would suggest to make the background white again. Even in the dark mode (then class=skin-invert/skin-invert-image will make it black for automatically color-inverted images to maintain good contrast and consistency with the page background).

Regarding the before/after comparison, I see that the infobox has just lost 1.5 lines without any gain in readability, plus all (for narrow screen) or some (for wide) article text has been lost. Not an improvement from any perspective.

Changes font size from 88% to 90%

@Physikerwelt, thanks! As far as I can tell, the DOM and visual results are now correct. I probably can't help with more testing as is (beta.math.wmflabs.org apparently doesn't even have skins and mobile version), but since now you have a working implementation, I hope that the testing team can work with it...

On https://en.m.wikipedia.org/wiki/User:Mikhail_Ryazanov/sandbox/display_math_span they also appear without indentation or centering, which is of course not how it should be, but this might be caused by using too many spans with contradictory classes:

<span class="mwe-math-mathml-display">
 <span class="mwe-math-element">
  <span class="mwe-math-mathml-inline ...>...</span>
  <img class="mwe-math-fallback-image-inline ...>
 </span>
</span>

The proper solution solution should not have that outer span (manually inserted by me) but instead should have ...-display instead of ...-inline classes for the inner span and img:

<span class="mwe-math-element">
 <span class="mwe-math-mathml-display ...>...</span>
 <img class="mwe-math-fallback-image-display ...>
</span>

as I guess it will if you just change div to span, as proposed.

Communication and instructions could be better, but instead of dragging WP stuff into jsfiddle, I've created a demo in my enwiki sandbox: https://en.wikipedia.org/wiki/User:Mikhail_Ryazanov/sandbox/display_math_span, using current styles but with a manually inserted <span> around <math>\displaystyle in place of <math display="block">. Decreasing the current "outrageously wide" spacings can be discussed elsewhere (or adjusted to personal taste by user styles), but that at least will be possible with correctly formed HTML.

@Physikerwelt, I understand that you want a demo. My question was how should I provide it — I obviously can't change how Wikipedia articles are generated currently, so do you want me to take one of them, pack everything in a stand-alone HTML, manually change there all the relevant divs to spans and upload here? Or maybe there's a simpler way?

@Physikerwelt, that "standard form" with MathML markup is a good demonstration of what I meant by XML-like markup with all these <mrow> <munderover> as opposed to human-oriented TeX and wiki markup... Of course, it can be kept as a backup/compatibility option (like the rest of HTML), but the more difficult it is to type, the fewer editors will use it instead of the old (wrong) :<math>. This is indeed offtopic here, but the word block has already confused Inzo in the discussion above.

First of all, using the syntax <math display="block"> was a very bad decision both in terms of terminology (in typesetting, these are not called "block" but just "display" formulas) and usability, as it forces editors to use machine-oriented XML-like markup instead of something human-oriented wiki-like (could be at least just <math display>, like <math chem>, or better <dmath>, akin to TeX's tfrac/dfrac).

@matmarex, thanks for pointing to isVectorized()! Then my proposed patch would be simply to replace this line:

if ( !$noscale && !$manualthumb ) {

by this:

if ( ( !$noscale && !$manualthumb ) || $file->isVectorized() ) {

That is, add higher-resolution subimages for all "vector" files (currently just SVGs, it seems), regardless of whether the "thumb" is the full-size image or substituted manually. (The parentheses around && are unnecessary but the current coding style apparently uses them, for example.)

@Aklapper, I know how to use Git (and have already committed to another WP-related project), but I'm not familiar with the Mediawiki codebase. In particular, I don't know what is the proper way to determine the image type (to make that $noscale = true; conditional) and how to test the results. I would expect that for any active Wikimedia developer these things should be trivial, and my suggestions where and which modifications to make should be sufficient to at least try...

Is anybody going to work on this? Doing nothing for 7 years doesn't look nice...

Well, I've created a pull request at GitHub. Hopefully, this will speed up the process..

Looks like the problem is in Core/generator.php: here, here and here. If I understand correctly, replacing in each case

$strlen = max( $strlen, strlen( $parameter ) );

by

$strlen = max( $strlen, mb_strlen( $parameter ) );

and

" |" . str_pad( $parameter, $strlen, " " ) . " = $value\n";

by something like

" |$parameter" . str_repeat( " ", $strlen - mb_strlen( $parameter ) ) . " = $value\n";

should solve the issue.
(It might be also a good idea to refactor such code into a separate function instead of copy-pasting it...)

what about the rest of the email notification preferences that aren't necessarily watchlist-related?

The "notification-related" email settings are already located in the "Notifications" tab. Other email settings, about password reset and user interactions, should naturally remain in the "User profile" tab (there is currently no other place for them anyway).

If moving these options to "echo" is difficult, can they at least be moved to the "Watchlist" tab? This will be even more appropriate, since the "Notifications" tab currently has no watchlist options. Please see https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Preferences.