Why do some users citing compatibility issues when deprecating the use of Unicode characters?

I have encountered for several times that some users have complained to me the use of Unicode characters (of normal series and normal shape, i.e. not bold nor italic) such α and →, claiming that “some browsers may not have such fonts to render these Unicode characters correctly.”

However, when I looked up in MathJax font support, it is explicitly mentioned that “MathJax will download the necessary webfonts and fontdata dynamically…” and the default font is MathJax TeX, which does include all the necessary characters (It also works for mobile versions). And in MathJax browser compatibility, it says that MathJax’s HTML-CSS output has been tested on IE 6.0+, Firefox 3.0+, etc., which means there should be no compatibility issues at all.

So why do they deprecate such uses citing compatibility issues at all?

Edit: Here all characters are meant to be enclosed by math environments, so the possible compatibility issue is not about native font-rendering function of browsers.

• I don't interpret the compatibility claim in the manner that you do. You ask about "the use of Unicode characters" instead of (presumably) $\LaTeX$ syntax for notation. It seems to me likely that such substitutions hinder rather than enable the opportunity for MathJax to dynamically substitute fonts, etc. – hardmath Mar 24 '19 at 6:53
• This previous discussion is (to some extent) related: θ vs. $\theta$ - What is preferred? Unicode or MathJax? Maybe also other past questions tagged (unicode) are worth looking at. (Although I would not say that those past questions specifically address browser compatibility. But they are at least related to edits where Unicode is replaced with MathJax.) – Martin Sleziak Mar 24 '19 at 7:10
• When I see → I have no idea how to type it. But I know \rightarrow from my experience with LaTeX. – GEdgar Mar 24 '19 at 11:52
• @GEdgar For me it's more convenient to type Alt+41466 instead of \rightarrow and also clearer to see → instead of \rigtarrow, though. – Saad Mar 25 '19 at 1:24
• I have seen unrendered broken unicodes many times on the site (using Firefox), and (reading Davide's answer) didn't know about it making a difference whether they are wrapped inside dollars. So it is plausible that your critics were equally uninformed. Mind you, if I have other reasons to edit a post, I will also replace Greek letters with their respective TeX-commands. – Jyrki Lahtonen Mar 25 '19 at 6:27
• (cont'd) It is possible that this is a generation thing. People my age are used to getting a way with 7-bit ascii and TeX, and think of this is as the norm :-) I do concede that I freely use the availability of some Swedish/Finnish letters, åäöÅÄÖ. My excuse is that those were already included in the 8-bit ASCII sets from the DOS era. At least when the appropriate code page was in use. – Jyrki Lahtonen Mar 25 '19 at 6:31

So why do they deprecate such uses citing compatibility issues at all?

If you mean you are using α and → inside mathematical expressions that are typeset by MathJax, then you are right, there is no problem doing that, as MathJax will process those using its web-based fonts that include those characters. So $α → β$ is fine: $$α → β$$.

But if you mean using raw α and → outside of math mode, then the can cause problems. This is because doing so requires that your readers have a font locally installed the includes the correct character, and because not all browsers on all system look up characters that aren't in the current font in the same way.

For example, some versions of IE do not look past the first font in the list of fonts specified for an HTML element if that font doesn't include the required character. This page, for instance, lists Georgia,Times New Roman,Times,serif for the fonts in the preview area. But Georgia does not contain a glyph for →, and so some versions of IE would not show this character if you used it. MathJax can make it work because it explicitly sets a font that it knows contains the arrow, but that is not the case if you are simply typing the character in the main text of a post.

• IE supports font fallback starting with IE7, released in 2006; older versions are vanishingly rare now, and IE itself is discontinued, so i'm not sure this particular example is an especially pressing concern – Eevee Mar 24 '19 at 17:07
• On an Android mobile I use, some Greek characters in Unicode that are otherwise okay on a computer show up only as boxes. That's one compatibility issue to keep in mind. – J. M. isn't a mathematician Mar 24 '19 at 17:51
• @Eevee, but IE (through 8 or 9, I forget which) will stop at the first font in the list that it finds on the system, and if that font doesn't have the required glyph, it doesn't look further, even off some other font in the list has the needed glyph. It's been a while since I looked into this, but I'm sure the it was a problem past version 7. – Davide Cervone Mar 24 '19 at 17:52
• @Eevee, I didn't mean to imply it was a pressing concern, I only meant to indicate why some people way that some browsers don;t handle this well. The OP was citing the MathJax browser support, which goes back to IE6. – Davide Cervone Mar 24 '19 at 17:54
• On my device (iOS), α $α$ is displayed upright and \alpha $\alpha$ is slanted, so there actually is a difference – gen-z ready to perish Mar 24 '19 at 23:04
• @ChaseRyanTaylor, you are right, there are differences (I didn't mean to say there weren't any differences, only that MathJax would put the characters into its web-based fonts, when the glyphs exist in them). The STIX fonts are included in iOS (and OS X), and the HTML-CSS output will use those when they are. It turns out that STIX has both upright and italic Greek letters (while the MathJax TeX fonts don't). Also, a character (like α) that MathJax's TeX input jax doesn't have a specific definition for will be placed in an <mo> in the internal MathML, while \alpha produces an <mi>... – Davide Cervone Mar 25 '19 at 12:26
• ... and <mi> elements use italic by default for single character (and normal for multi-character) content. So <mi>α</mi> would produce an italic alpha, while <mo>α</mo> would produce an upright one. That is the difference you are seeing. Note that it only occurs in HTML-CSS output, and when STIX fonts are available. If you switch to CommonHTML or SVG output, you will get italic versions for both. I had hoped not to have to get into these technicalities, but there you are. – Davide Cervone Mar 25 '19 at 12:28