Sorry for being picky and changing the title... but it has to be pointed out that this is not a math problem as such but a problem with the fallback images that are required since not all browsers support HTML5 (i.e. the MathML part of it).

See also T144445

@mobrovac I have the impression that @Jdlrobson knows much more on web UI and performance than I do. While I see the pros of ex from a theoretical perspective, I would go ahead and replace ex with px. Technically this should be quite straight forward, if we just use the ex value from here. Do you agree?

I would use caution here. Personally, I'm for ex as it represents the actual correct size of the render. But switching to px could be a pragmatic solution. @Physikerwelt could you test lazy loading with px?

Hi @Jdlrobson,

Can you explain this a bit further. I see it too, but it's unclear to me what is causing this exactly. The dimensions should be known, so i suspect this has to do something with some side effect of block or content rules or something ?

It's been so long I've not sure any more....

There is definitely a reflow happening but whether it is because of ex's rather than px I'm less sure.

If I scroll so that "Black-body radiation becomes a visible glow of light if the temperature of the object is high enough." is touching the top of the window and hard refresh, it will move down by a line.
On 2G I see multiple reflows ... but these could be down to multiple things - not necessarily the Math images... for instance the height auto !important on images could be playing a part here.

Will need some more investigation.

@Jdlrobson I see one reflow, which is because the fallback image has a vertical-align offset, which is not copied into the style of the lazy loaded image. But there is also a width reflow, which I don't really understand. That has to do either with 'undeterminable' width, or because the style attribute is set 'late' or something. But it's indeed a bit hard to analyze.

Am I right in remembering that originally we didn't even copy the width and height style attributes at all ? That might explain the original description of this ticket a bit better, since indeed we did not have the pixels width/height attributes set, but only the css width/height attributes.

Can we use the http://asciimath.org/ or http://docs.mathjax.org/en/latest/mathml.html here ?

As @Krinkle points out there's a reflow in https://test2.m.wikipedia.org/w/index.php?title=User_talk:YBG&oldid=310902

Change 350496 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Placeholders should not be block

https://gerrit.wikimedia.org/r/350496

This does not seem to be related to Math.

Copying from the patch:
Looks like the image being rendered has a width of 350px and height of 233px so the placeholder has a width of 350px and height 233px.
When the image is loaded a CSS rule max-width: 100% rule kicks in to downsize it to fit into the constraints of the skin causing the reflow - 288px by 192px
I'm not sure how we can avoid this. We can obviously add overflow:hidden+display:block to all .image's but this only solves the issue of horizontal reflow.. not vertical.
This seems to be the case with display: block and display: inline-block so I think the original bug fix was ill-informed, but it probably explains the remaining reflows we are seeing in T146298
The more general issue here is that we have to apply max-width: 100%; height: auto;
Ideally all thumbnails would be standardised to a mobile friendly width/height. We can do that in MobileFormatter.
What thoughts do you have @Krinkle?

Change 350496 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Placeholders should not be block

https://gerrit.wikimedia.org/r/350496

Change 351736 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Use transparent gif as lazy-image-placeholder

https://gerrit.wikimedia.org/r/351736

This is the only way I can think to solve this problem..

In T146298#3233732, @Jdlrobson wrote:

This is the only way I can think to solve this problem..

I'm not sure I understand. Are you saying that an image with width/height set and max-height applies will scale proportionally, but doing the same on a <span> will not?

@Krinkle hopefully this helps illustrate the problem:
https://codepen.io/anon/pen/jmLZQg

Notice how height auto works differently for img tags compared to div and how if it is applied to images the scaling respects the aspect ratio.

In T146298#3233912, @Jdlrobson wrote:

Notice how height auto works differently for img tags compared to div

Right. Once an image is loaded, you can override one side to auto, and one side to a specific length (e.g. 100% or 200px). At which point it'll be computed based on the image's native natural dimensions. But that only works once the image has been loaded.

But I don't think that works on a placeholder, regardless of whether it is an <img> or a <div>. Right? Because with a placeholder GIF, it will relate itself to the natural width and height of the transparent GIF, which is presumably a square, so the aspect ratio it uses will also use a square, not the specified width/height since those end up being ignored due to CSS overriding width and height.

See https://codepen.io/Krinkle/full/gWGqqe/.

Change 351736 abandoned by Jdlrobson:
Use transparent gif as lazy-image-placeholder

https://gerrit.wikimedia.org/r/351736

Sounds like this is not fixable...