#mathml

There are two main technologies involved: protocols and documents. Protocols make sure you can send and receive documents. The documents contain some content and instructions what to do with that content in computer readable language.

Over the past years, protocols have gotten more and more sophisticated. Quite recently, a lot of effort went into encrypting all these protocols better. But they also get faster, integrate new algorithms more efficiently and generally move forward at an impressive pace. There are some problems, but generally speaking humanity has protocols figured out.

Documents are a bit more problematic. When you look at a web-page, you use a browser (Firefox, Chrome, Safari, Opera and some unimportant ones) to do all the heavy lifting for you. The browser figures out what protocols to use, who to talk to and what documents to request. Once it got all the documents, it reads all the computer languages in the document to figure out how to display the content.

There are three main languages we use to make web-pages pretty:

Hyper Text Markup Language or HTML describes the structure of a document. Where does a paragraph start and end? What text should link somewhere else? Is that text for the user or the computer?

Cascading Style Sheets or CSS tell the browser what the document should look like. Text color, size, where to position text and what text should be hidden is defined using CSS. It's probably the most difficult to learn language of these three.

[Javascript or JS](https://en.wikipedia.org/wiki/JavaScript "Wikipedia on JS"] is the only programming language here. It can change a documents layout, evaluate input and is nothing short of the brain of a web-page.

That's the good part. Let's start with the bad part at a point you bare some responsibility for: bad browser support.

Superficially, all browsers agree on how the internet should look like. Over some time, we got all browser-suppliers to listen to the World Wide Web Consortium, an organisation that defines how HTML and CSS should work and how JavaScript interfaces with both. In detail however, many browsers speak there own, specific "slang" instead of what the W3C defined.[1] Sometimes browsers charge ahead and implement features the W3C didn't have time to define yet. Other times they don't implement something for various reasons. And then again some browsers understand words differently.

For everybody caring about their web page, that meant to write different documents for different browsers. Most of the time, only tiny bits and pieces need to be different. Though there is not much work involved, it's a plethora of annoyance to test every detail in every browser. So much so that it's big business to help people with cross-browser-testing.

That's where the math breaks.

There is a great standard embedded in HTML, the Math Markup Language or MathML. Though it's part of HTML, part of the web and well defined by W3C[2], most browsers don't understand MathML.

JavaScript To The "Rescue"

It's such a pain to test different browsers, sometimes only to find out that what worked nicely in one doesn't work at all in the other, that developers started to use frameworks. Frameworks teach a browser some new language, usually as an extension of JavaScript. Most are written in JavaScript, but all promise to look the same across all browsers. It's a lot easier to write a page nearly exclusively in JavaScript than using HTML and CSS, both possibly failing in one browser or the other. Furthermore, CSS tends to have unexpected results. It's a quite old language that pales in comparison to newer ones. CSS' complexity is partly to blame for the popularity of frameworks.

Here the math came in. Since MathML is badly supported, a framework exists to display mathematical formulas. I used MathJax because it allows formulas to be written in LaTex, a language used in scientific literature.

E.g. this LaTex code:

\gamma ={\frac {1}{\sqrt {1-{\frac {v^{2}}{c^{2}}}}}}={\frac {1}{\sqrt {1-\beta ^{2}}}}=(1-{\frac {v^{2}}{c^{2}}})^{-{\frac {1}{2}}}={\frac {dt}{d\tau}}

ideally renders as:

People are lazy. Web developers especially. If there is a tool out there fixing a problem[3], people will use it. The additional cost is conveniently hidden. But there is plenty!

Your browser is a tool to display HTML and CSS. It's well optimised to do that quickly, neatly and securely. JavaScript on the other hand is designed to be able to do everything. And it's actually quite hard to do that quickly, not to mention securely.

JavaScript is awesome. Used correctly, it allows a more fluent user experience. And smoothing over browser differences is possible as well. There seems to be no limit to what JavaScript can do.

But when it's used for everything, web-pages require a lot more code to be transferred, slowing users down. JavaScript, though fast, can't come close to a browsers native ability to read HTML and CSS.

More recently, JavaScript is used for user surveillance. Tracking your device, your click-behavior, and of course what pages you visit is all possible with JavaScript.

JavaScript used at the scale it's used today excludes slow connections and slow computers and enables user surveillance by big companies. That's why I try to reduce JavaScript to an absolute minimum in all my projects.[4]

How That Works

HTML tells the browser about a documents structure. Browsers expect everything in a document to be embedded in HTML. Documents are generally structured as follows:

- tells the browser this document may contain HTML - Everything between and is html-code. </p> All document properties go here. The head is never displayed, but used to tell the browser how to handle the document. <title>The Documents title goes here</title><style> Cascading _Style_ Sheet language goes here </style><script> JavaScript code would go here, use sparingly! </script><link href="Here%20we%20could%20write%20some%20link%20to%20load%20additional%20CSS-files" the> - tag is used for very basic document descriptions, like if the document contains emoticons: <meta charset="utf-8"> Content goes here. Ideally, we don't need any more property-definitions here, though it would be possible to enter them here as well.

tumblr allows quite substantial manipulation of a blog's HTML. But they insert some extra HTML without asking any blogger. By inserting some <script>-tags, they can add some JavaScript. That is mostly for surveillance purposes, but some is to show e.g. that tumblr-bar at the top of the page.

By adding some JavaScript to display nice formulas I contribute to the jungle of JavaScript. Then again, removing MathJax would change little. However, I could actually add some JavaScript to protect my visitors from surveillance. Even better, I can use HTML itself.

There is a lot more to HTML than most people, even web-developers[5], realise. For example, there is a way to define what sources the browser should trust, and discard all others. That way, a browser will block any JavaScript[6] which is not allowed.

These restrictions are actually part of the protocol, not the document. But HTML has a way to tell the browser about things the protocol might have forgotten to mention. This extra information is of course valid for the whole document, so they go in the <head> element. On this blog, this line keeps you safe from surveillance JavaScript:

<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-eval' 'nonce-optica_setup' 'nonce-disqus' 'nonce-mathjax' https://*.tumblr.com">

This line introduces itself to the browser as meta-information about the document. http-equiv tells the browser it's supposed to treat the line as equivalent to an HTTP[7] statement, which is specified in quotation marks. The content specifies what the statement is evaluated as. Suffice to say, this content tells the browser to ignore all JavaScript not from tumblr.

Safe From Math As Well

You may have noticed that I said pretty formulas needed JavaScript because browsers don't all support MathML. Well, there are ways around this shortcoming. MathJax is one way, browser specific CSS is another.

Assume a browser doesn't understand MathML. It's still HTML, but uses tags the browser has no use for. Since it's HTML, the browser would understand CSS styling it's content perfectly well. That allows to as a browser to please draw e.g. a square root in pure CSS. Or to define the style of how fractions are written. And how the typesetting of a formula differs from that of text.

This method is called a "CSS-fallback". Your browser doesn't understand MathML? Well, you can fall back to how we did it in the old days. It won't be as pretty and there won't be the same functionality, but it covers you for the most part.

There is a catch, though. Say a browser understands MathML perfectly fine and reads the CSS-fallback. MathML tells it to draw a square root. CSS tells it to draw a square root as well. Now you have two square roots on the screen. Ugly.

What needs to happen is that the browser reads the CSS if it doesn't understand MathML and ignores it otherwise. However, there is no way to ask a browser if it understands MathML. The only way to reliably test weather a browser does requires JavaScript.

Trying to reduce JavaScript, there is only one way: browser specific hacks. Browsers implement HTML and CSS differently. That's generally an annoyance. But, once you know how exactly they differ, it's possible to write code one browser will understand and others won't. Once we know [what browser actually understand MathML](https://caniuse.com/mathml “caniuse.com is a helpful page that documents what which browser understands”), all we need to figure out is how to talk specifically with those who don't.

I failed. There is nothing that exclusively browsers that don't speak MathML understand.[8] The frustration is real.

The Demise of The Web (Page)

On the modern web, fewer and fewer documents contain static content. Most web pages rightfully call themselves "web apps", since they more closely resemble a dedicated application than any form of document. But by using browsers, they need to work with the minimum set of features every browser supports. Electron to the rescue!

Electron is a tool that solves many problems. Using Electron on a page returns a stripped-down version of Chromium that runs only that page. The web-developers are happy, because there is only one browser looking at their page. Chromium is happy, because there are much more people using Chromium now. And app-developers are happy, because Chromium works on any computer so their app will work on any computer.

There is a bunch of problems with Electron, specifically security wise, but it's better these projects are turned into apps than pages. That's because your program is your problem. How much work you invest vs. how bad it turns out is your decision.

A web-page is everybodie's problem. Because of browser economoics.

The Politics of Browser Economics

Browsers and web-developers are in a weird dance with users. Every browser wants to be the most popular and lure users with features. Web-developers depend on browser support, so they tend to use features all browsers support. Users generally want a page to work before caring about what nice features it offers. And ideally, the W3C finds common ground and writes that down which we then call a standard.

To be the most popular, every browser found something it’s particularly good at. Firefox has the most experimental features, Chromium is super fast, Opera is pretty and Edge is good at downloading Firefox.

Faster browsers are easier to sell. The moment a user installs a faster browser he feels improvement. But it takes a document including e.g. MathML for a user to see the benefits of beautiful formulas. At the same time, every user with browsers not supporting MathML will leave the page because it looks ugly to them. That's why fallbacks are important. And that's why JavaScript frameworks are so convenient. But JavaScript is slow, so users would see a real improvement by switching to faster browsers. It's a vicious circle.

If we all could get faster browsers, that would be awesome. But we can't. There are people with old computers that don't have the power to run fast browsers. There are countries with slow connections and every byte JavaScript they need to download counts. And though JavaScript has it's applications, extensive use of JavaScript comes with many ramifications.

JavaScript takes time to load. A lot of companies use JavaScript for surveillance. Since JavaScript is so powerful, it's easier to hack. And since JavaScript is everywhere, it is used to grab your attention.

The Ad-Epidemic

The availability and prevalence of JavaScript everywhere has enabled new exploitation. Annoyingly blinking ads have existed since the very early days of the internet, but it took a lot of ~surveillance~ behavioral science to turn that into a business.

In the early days, to advertise you had to find a page that attracted users who might buy your stuff. Then you needed to actively reach out to that page and ask it to put some paid ads up. It was your responsibility to guess what users visit what pages and it was the pages responsibility to guess weather this or that ad might scare users away.

Today ads work like this: If you want to advertise, you hire an ad-network to show your ads to specific users. The ad-network has access to many thousand pages and will show your ad whenever a user you specified visits.[9] At the same time, all pages contributing to the ad-network can set what ads shouldn't be displayed on the page. There is no more guessing involved.

It's crucial to this process that the ad-network knows what user is currently visiting the page. Surveillance is a key element of modern advertising. The better an ad-network knows a user, the better it can show ads the user will actually click on and thereby earn money. Therefore, the best at this game are Google and Facebook. Google, because it knows what you search. Facebook, because you told them everything about you. And of course JavaScript based surveillance of user behavior.

Web-developers are lazy. Selling users attention and privacy is a super simple and reliable way to get enough money to keep a page running. Of course there are other concepts out there, ranging from plain paid subscriptions to more creative concepts! All of them require some thought into how a page adds value to a users life, though.

Plain And Simple

I'm lazy. I want a fast web. I'm easily distracted. And I don't know anybody who doesn't hate ads.

You are responsible for the browser you use. Could I convince you to switch to a browser with MathML support to make my life a little easier? If not, how about a fast browser with decent HTML support?

If you still have time, think about installing an ad blocker. You will experience faster pages, because the JavaScript trying to load ads is blocked. And if enough people block ads, web-developers will have to think of new ways to get money.

Another part to this story is mass surveillance. Surveillance is a lot easier with a lot of JavaScript and advertising requires surveillance to be efficient. Making surveillance more difficult is simple:

Privacy Possum disables surveillance a page does on it's own.

TorBrowser disables surveillance based on protocols

It's a bit more tricky to disable JavaScript based surveillance. The best way is to disable JavaScript. Some tools allow you to disable specific sources of JavaScript. uBlock has this functionality integrated. However, these tools require a bit more substantial understanding of how HTML documents work.

Most of this measures don't have an immediate benefit to you. Quite the opposite! TorBrowser is slow. Disabling JavaScript will break most pages because they rely so heavily on it.[10] But we shape the web by the way we use it. Using these tools shapes the web away from specific, slow, surveilled user experiences towards a common experience equal to all users.