Wikimedia Bugzilla is closed!

Frédéric, maybe you share your ideas here?

I think our browser fallback is already good. It's just that we should try to use the standard MathML syntax

<math>
<semantics>
[MATHML]
[annotation SVG]
[annotation PNG]
</semantics>
</math>

or perhaps just one annotation (which works natively in recent Chrome versions)

<math>
<semantics>
[MATHML]
[annotation SVG]
</semantics>
</math>
<img PNG>

instead of

<math>MATHML</math>
<img SVG>
<img PNG>

and hide/show the MathML/annotation according to browser's capabilities. I don't remember why we didn't try that last time we discussed this.

Technically, that won't change much the rendering but at least this will be a more standard way and highlight that SVG/PNG are fallback.

The other thing was deciding between CSS hacks vs Javascript sniffing/feature detection, which are both bad practice anyway. But as I recall javascript could not be executed in time.

Created attachment 16320 [details]
Testcase

Here is a (valid HTML5) testcase to give the idea. Actually, the two <img> fallbacks can be in the same annotation-xml so that Blink will only display one by default.

A significant advantage of using this approach is that if we remove the style of the page (disabled by the user, copy into another document etc), Gecko, WebKit and recent versions of Blink will still display only one formula. Trident will still show the three MathML/SVG/PNG versions, though (the IE team rejected my proposal of annotation-xml for the next release).

A difficulty with that approach is the vertical/horizontal alignment of the fallback image (for which I believe we have problems/doubts anyway), but that should be studied more carefully.

Mmmh, it seems that my CSS does not work on IE, I'll need to check that later (I know it's possible to make it work since I submitted a "patch" to Microsoft!)

Another potential advantage of this approach is that it might become more friendly for accessibility tools (bug 66537), even if I suspect the "display: none" stuff is still problematic...

Thank you Frédéric,

do you think to include (and not link) the SVG to the MathML element here would be a good idea.

(In reply to physikerwelt from comment #5)
> Thank you Frédéric,
> 
> do you think to include (and not link) the SVG to the MathML element here
> would be a good idea.

This would make possible to keep the SVG fallback integrated into the doc when  doing copy & paste (better when one is offline). Also, I wonder if that helps for the size/alignment issues. However, this would add more code in the page itself so I suspect increased parsing time in browsers even when they don't use the SVG fallback. Also, this would be one more step away from our current approach, so this could be considered separately/later.

(In reply to Frédéric Wang from comment #4)

> Another potential advantage of this approach is that it might become more
> friendly for accessibility tools (bug 66537), even if I suspect the
> "display: none" stuff is still problematic...

Yet another advantage of this more standard approach: even if we default to PNG to start with, the "copy MathML / copy LaTeX" commands provided by https://addons.mozilla.org/en-US/firefox/addon/mathml-copy/ or similar tools will work. More generally this more standard approach could help any MathML-aware tools...

Initially we dropped this approach, because some browsers did ignore the MathML tag and showed all the embedded content.
Do you know how one could test the page rendering time.
I have not found a good way to do accurate measurements via the command line.

(In reply to physikerwelt from comment #8)
> Initially we dropped this approach, because some browsers did ignore the
> MathML tag and showed all the embedded content.

OK, I think that should no longer really be a problem now that we have a better idea on which "CSS hacks" allow to control which element to hide/display. The vertical & horizontal alignment might need more care, though.

> Do you know how one could test the page rendering time.
> I have not found a good way to do accurate measurements via the command line.

I'm not really sure. You might want to try to put some <script/> in the header or listening for "DOMContentLoaded" or "load". Note that the additional SVG code might also affect the server-side load time. I don't know to which extent.

So now I remember what was the problem: WebKit Nightly has support for semantics and always displays the first MathML child without the possibility to switch to the annotation fallback... (for Gecko, it is somewhat accidental that "display: none" on the first child allows to do that...)

Ok. We should somehow test with a lot of browsers before we publish something.