search

mdn / yari

The platform code behind MDN Web Docs
Mozilla Public License 2.0
1.19k stars 508 forks source link

Some pages show raw math syntax (LaTeX?) #4197

Closed foolip closed 2 years ago

foolip commented 3 years ago

MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/PeriodicWave

What information was incorrect, unhelpful, or incomplete?

"\left(a+bi\right)e^{i} , \left(c+di\right)e^{2i} , \left(f+gi\right)e^{3i}" appears on this page, which is unreadable. It looks a bit like LaTeX, presumably this was once turned into a math image?

Specific section or headline?

What did you expect to see?

No expectations, just not this :)

MDN Content page report details * Folder: `en-us/web/api/periodicwave` * MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/PeriodicWave * GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/api/periodicwave/index.html * Last commit: https://github.com/mdn/content/commit/babc0473793bbe3cfa66cd96fae7f84348be373b * Document last modified: 2021-02-08T10:05:46.000Z
Rumyra commented 3 years ago

Is this where the fourier equation is under the 'Example' heading @foolip ?

I ask because I see a rendered equation and not what you have above...

foolip commented 3 years ago

Yes, it's what follows "The coefficients of the Fourier transform should be given in ascending order".

It looks like it's MathML, so the issue is actually one of browser support?

Rumyra commented 3 years ago

Yes looks like it to me https://caniuse.com/mathml

It's not rendering in Opera or Edge for me which adds up. Wonder whether this is an issue for Yari as there are polyfills available 🤔

teoli2003 commented 3 years ago

Yes, it displays correctly in Firefox. If I remember well, long time ago, there was on MDN a fallback from MathML to MathJax or similar. @elchi3 will surely know if it survived the move to yari, or if it is planned for the future. If not, we should find a solution, There is not much MathML on MDN – besides the MathML documentation that is – but we should track and fix it if MathJax is gone for good.

Elchi3 commented 3 years ago

Yeah, this came up recently on other pages as well and @schalkneethling said that MathML polyfills didn't make it to yari. I'm not sure what the plan is. I guess someone needs to investigate the need for MathML or what we could do instead.

schalkneethling commented 3 years ago

@peterbe Thoughts? I know there is a polyfill we used to use on Kuma. If there is enough of a need we could introduce it again perhaps?

peterbe commented 3 years ago

Oh no! Did we lose this in Yari?

For JS features, we use https://polyfill.io/v3/url-builder/ so that it dynamically injects one of their polyfills. Is there a similar thing we can do for MathML? I'm quite ignorant of how MathML works in browsers. But it seems very possible to just extend the existing JS polyfill with one more specifically for MathML.

Rumyra commented 3 years ago

I just did a quick search just in the web directory and it came back with 253 <math matches in 86 files. Enough to be noticeable, but also not a huge percentage.

I also wonder what the strategy is for MathML with the move to markdown - does that influence how this is tackled?

hamishwillee commented 3 years ago

@wbamberg see ^^^ https://github.com/mdn/content/issues/3435#issuecomment-850348200

Mostly when I see math markup extensions in markdown they use $ guards and subsequently follows its own standard rules and sometimes $$ guards for code blocks. I'm pretty sure github doesn't support it.

wbamberg commented 3 years ago

I just did a quick search just in the web directory and it came back with 253 <math matches in 86 files. Enough to be noticeable, but also not a huge percentage.

I also wonder what the strategy is for MathML with the move to markdown - does that influence how this is tackled?

The plan is to keep it, so anything inside <math> tags stays unconverted. It's not very common, its use tends to be clustered in niche areas, and there isn't really a Markdown equivalent in many cases.

hinell commented 3 years ago

Please add also the following:

wbamberg commented 3 years ago

Should we transfer this to mdn/yari?

peterbe commented 3 years ago

Solving this won't be easy because we can't add a polyfill that slows down people (with more JS) on every single page. 99% of pages don't have MathML on them. The majority of our traffic is Chrome and Chrome would need the polyfill. So for 99% of pages, it would be a waste to have to download this polyfill.

The ideal thing would be if the document itself could be aware that it needs polyfills and then that gets automatically injected into the DOM based on the document. Then, the 99% of pages don't get a heavy polyfill and the few pages that needs it get nice equations in Chrome (and any other browser that needs it).

What if we put into the front-matter, some sort of clue about it needing a polyfill and then the <Document> component can be fed this and it then injects a <script src="polyfills-r-us.biz/mathml"></script>. Would that be a solution?

wbamberg commented 3 years ago

Personally I'm not too keen on using front matter for implementation specifics like this, but I take your point. Could the builder look for <math> elements in the page and insert a polyfill based on that?

peterbe commented 3 years ago

Here's how the old Kuma used to solve it: https://github.com/mdn/kuma/pull/6546/files I think it's time to revive that because it didn't make it across to Yari. But this time, let's take a fresh look at it so we do it in an optimal way.

hinell commented 3 years ago

Cutting out formulae I think is a viable option. It can be saved to Wikipedia and linked. Cheap & quick.

its4zahoor commented 2 years ago

The Math.log10 is still showing raw math syntax.

MathLog10_LaTeX

hamishwillee commented 2 years ago

@schalkneethling Is this something you might help with?

schalkneethling commented 2 years ago

@schalkneethling Is this something you might help with?

Yes! I will bump this up. We looked into this and then it lost momentum with all the things that happened. I will add these to my priority list. Thanks for the ping @hamishwillee and @its4zahoor

himanshugarg commented 2 years ago

MathJax is gone for good.

Sorry for reusing this issue. The only one returned when searching for MathJax. Just for my own understanding for similar situations in future - we don't use MathJax because that would add a potentially heavy dependency on every page on MDN, right? Or is there more to it?

schalkneethling commented 2 years ago

MathJax is gone for good.

Sorry for reusing this issue. The only one returned when searching for MathJax. Just for my own understanding for similar situations in future - we don't use MathJax because that would add a potentially heavy dependency on every page on MDN, right? Or is there more to it?

From what I understand the examples on MDN does not warrant something like MathJax and the CSS solution we added is good enough? It might be worth considering MathJax as I note their statement regarding accessibility https://www.mathjax.org/#a11y

The way we currently do it does no add the CSS to every page but, only to pages that has math element and then only if viewed in a browser that does not support MathML. We could probably do the exact same thing with MathJax.

Thoughts @ddbeck and @Rumyra? Is the current solution good enough and accessible? Should we consider MathJax? Thanks!

Rumyra commented 2 years ago

We'll be doing an accessibility audit over the coming months and will circle back to this should any issues arise 👍

Josh-Cena commented 2 years ago

Hi, bringing this up because the big chunks of MathML aren't really maintainable on MDN. If the entire MathJax bundle is too big, is server-side rendering an option? Can we use a Markdown plugin (Rehype, I suppose) and statically transform TeX to MathML with KaTeX/MathJax? This way we only need to send the CSS bundle, and we can even code-split that like we currently do.

schalkneethling commented 2 years ago

Hi, bringing this up because the big chunks of MathML aren't really maintainable on MDN. If the entire MathJax bundle is too big, is server-side rendering an option? Can we use a Markdown plugin (Rehype, I suppose) and statically transform TeX to MathML with KaTeX/MathJax? This way we only need to send the CSS bundle, and we can even code-split that like we currently do.

@mdn/core-dev Something for the future?