Author Archives: Peter Krautzberger

Talking, really, about work

Yesterday I was driving up to Northeim to pick up some Sandkastensand (because people had actually cleaned out the other store’s 150 25kg packs — are you kidding me). While in my car, I was listening to this conversation on DLF, featuring a writer notable for her children’s books. I didn’t know her though I’ll try to get my hands on her collection of new translations of English poems (for children).

What struck me about the conversation was the nature of the discussion. I suppose a good example was a ever so slightly sharp turn in the conversation when it came to the translation of a Lewis Carroll poem which, in its new translation, featured a Porsche — an anachronism that met criticism from the host.

What caught my ear was how these two talked eye-to-eye, the host displaying in-depth knowledge not only of literature in general but the guest’s work in particular. This allowed them to discuss how the writer worked, the real essence of her work, the challenges, the modus operandi. (What also made me wonder was the precarity of the writer; the collection came out of her PhD work, the first book seemed only a success in so far as it landed her some prize/stipend that allowed her to write the second book. Literary careers always sound like scientific research careers, yet we keep things separated.)


I’ve always yearned for the equivalent of an art critic (which the host evidently provided) but for math and science. One of my first blog posts ever was about mediocrity and, in may ways, critics are the perfect example of why mediocrity is [pun not averted] critical. Instead of pretending to pursue “high” art/science/math a critic is helping their field by providing constructive (and when necessary destructive) review. In public. We do not have this for STEM. Yet the discussion between those two was as esoteric to me as a discussion about forcing axioms or JavaScript libraries would be to them. Of course, German Feuilleton (oh my, I had no idea about contemporary meaning in French) assumes none of its work is esoteric but features 0% of real science criticism (let alone math).


Skip back a few years. My only comment left on Carta.info (no link because I can’t find it and because carta has become quite strange) was a foolish, troll-like comment (confirming Hanlon’s razor, it was out of stupidity) where I wondered why DLF’s Presseschau never included quotes from blogs, since I clearly had (and have) the impression political bloggers are on par with those strange, small-town newspapers that make it into that selection of op eds. (IIRC, there’s now some minor tech segment on DLF that features some blog posts; oh well.)


Over the past year I started to listen to more and more podcasts, primarily about web technology, i.e., work (it all started with the excellent Shoptalkshow). Listening to the conversation on DLF, I realized two things. First, technology podcasts provide just that criticism for web technology. While it’s often infantile, it’s equally often profoundly useful. As usual, web tech is trying to skip an old medium; a loss for both sides.

Still, during the DLF conversation yesterday I realized that I need to look for another kind of technology podcast: one about actual code. That is, where developers talk about their approach to programming, problem solving, how various tools do their job, and who knows, maybe even actively review code. In other words, a podcast that does for web tech what the DLF piece yesterday might do for writers. Maybe streaming things like twitch.tv (and perhaps livecoding.tv if it ever goes [pun not averted] live) will fill the gap naturally. Still, I’ll have to hunt around some time.

Thinking back to mathematics, the podcasts I tried do not fill that gap. There are really good ones out there but they are not on the level of that DLF conversation or on the level of technology podcasts. They always seemed to be more interested in news, puzzles etc rather than challenging the listeners and the experts alike. Which reminds me, I should try to pick up Vilani’s book.


Later it smelled like Sommerregen. And everything was well.

catch my post at the Wiley Exchanges blog

It’s been quiet around here — too much work behind the scenes — BUT you can still read some of my usual incessant babbling over at the Wiley Exchanges Blog where I write about MathML and its role in Making math and science first class citizen’s on the web.


For posterity, here’s the version I submitted, including typos

Making math&science first-class citizens on the web

img

Without mathematics, there’s nothing you can do. Everything around you is mathematics.
Shakuntala Devi

It has always surprised me a little that the web — created at CERN by a trained physicist turned computer scientist — was born without much consideration for math and science. Of course, it isn’t all that surprising since the original HTML lacked more basic things (such as support for tables or images). Either way, people did see the need early on and in 1995 the draft of HTML 3 proposed a <math> tag, adding basic math support in HTML. Unfortunately, HTML 3 was rejected by browser vendors, and its more fortunate successor, HTML 3.2, dropped the <math> tag (among other things). As was the fashion of the time, the <math> tag was turned into a separate XML specification and within a year MathML was born. Problem solved? Not quite.

MathML did turn out to be hugely successful in the XML world. Authoring and conversion tools quickly made MathML easy to create and edit while publishers adopted MathML in their XML workflows. The main reason was that MathML provided a robust, exchangeable, and reusable format for rendering and archiving equational content. However, XML did not succeed as much on the open web and the XML legacy made it difficult to use MathML in HTML itself. This meant that mathematics (and in extension scientific notation) remained a second-class citizen. Surprisingly, MathML did not simply fade away like other web standards but made a comeback in HTML 5, where we can now use like any other tag. Problem solved? Not quite.

Despite its success, its rich ecosystem, and its importance for research and education, MathML continues to struggle on the most critical front: browser adoption. So far, not a single browser vendor has actively developed their MathML implementation. While Internet Explorer and Chrome lack MathML support entirely, Firefox and Safari at least accepted code contributed by volunteers (and in Mozilla’s case actively supported the code base). To compensate, the MathJax project (disclaimer: which I work for) developed an open-source JavaScript solution that authors and publishers can easily drop into their content. MathJax renders MathML on the fly, providing high-quality output that works everywhere out of the box, using only web standards such as HTML and CSS. A joint venture of the American Mathematical Society and the Society for Industrial and Applied Mathematics with the support from numerous sponsors, including Wiley, MathJax has become the gold standard for math on the web with our free CDN service alone registering 35 million daily visitors. Problem solved? Not quite.

While we are proud of our accomplishments at MathJax, we know that we can only provide half the solution: native browser support must be the goal. Only native browser support can make MathML universal, helping everyone and allowing people to push the envelope for math and science on the web further. I believe a crucial role lies with publishers. Taking a cue from Forbes, now every publishing company is a web technology company. Not being involved in the development and implementation of web standards is a bit like printing books but not caring about literacy rates — if you build it, they still can’t come! When it comes to the development of the web, scientific publishers can become the bridge between authors and standards bodies and they can be instrumental in supporting the development of tools and processes that push everyone forward. Problem solved? Not quite but if you build this

The re-integration of MathML into HTML5 was a huge step towards math and science becoming first class citizens on the web. MathML is not only a fully accessible exchange format for mathematics but it is also part of other scientific markup such as the Chemistry Markup Language and the Cell Markup Language. The future of MathML in browsers will determine the future of scientific markup on the open web. In the end, a chemical reaction or a data plot has no more reason to be a binary image than an equation — we need markup that is alive in the page and can adapt to the needs of the users. Only this will allow us to develop new forms of expressing scientific thought, forms that are leveraging the full breadth of the open web platform, that are truly native to this amazing medium called the web. And that would be an exciting problem to have.


The comments were also interesting.

  • Kaveh Bazargan • 23 days ago

Thank you Peter for your accurate and witty post, and thank you for MathJax which has served as a beautiful solution to math on the web. The lack of support from browsers has been pathetic and shameful, and you are right that the only real solution is that MathML (and other MLs) are supported natively supported as the definitive content. We should not really have to resort to “tricks” such as MathJax, however well executed those tricks might might be!

  • Peter Krautzberger re Kaveh Bazargan • 23 days ago

Thanks, Kaveh. As I wrote, Firefox and Safari do have some support for MathML and of course MathJax is also not yet complete in its implementation (there’s only so much room in a non-technical post).

In my humble opinion, it’s an achievable goal for a publisher to produce MathML that renders fine on Firefox’s native support (while I don’t think the same can be said about Safari at this point).

  • Kaveh Bazargan Peter Krautzberger • 23 days ago

Of course in practice we simply cannot restrict users to browsers these days, so until there is native support of MathML in all popular browsers, we’ll continue with MathJax which does work on all. 😉

  • Peter Krautzberger Kaveh Bazargan • 23 days ago

Here’s hoping that one day, we won’t have to. Wouldn’t that be a nice problem to have?

  • Robert O’Callahan • 23 days ago

The best way to get all browsers to support MathML natively is to push math users to use Firefox for its native MathML support. That will get the attention of the other browser vendors. Unfortunately, even in this post you didn’t clearly commend Firefox for being the only browser with native MathML.

  • Peter Krautzberger re Robert O’Callahan • 23 days ago

Thanks for the comment, Robert. I’m not sure who you have in mind with “users”. I would agree that authors should ensure that their MathML renders well on Firefox natively.

I wouldn’t quite agree to call Gecko/Firefox the only browser with MathML support. WebKit/Safari made a lot of progress last year thanks to Fred Wang’s work even if it’s behind Firefox in its implementation.

  • Robert O’Callahan re Peter Krautzberger • 23 days ago

By “users” I mean people producing and viewing math content.

I’m glad Safari is making progress. Feel free to recommend it too. The important thing is to create market pressure for browser vendors to implement native MathML, and that means users/developers choosing one browser over another because of MathML.

As you probably realize, MathJax being so good has actually reduced that pressure; it’s easy for browser vendors to say “hey, MathJax works fine in our browser, so why bother investing in native MathML”. Even in this post, you haven’t clearly identified reasons why native MathML is better than MathJax fallback.

  • Peter Krautzberger re Robert O’Callahan • 22 days ago

I fully agree that users should choose browsers for their features and Firefox’s MathML support is, to me, a huge factor, especially in an educational setting. (In fact, I just recently had an interesting situation where I helped a student struggling with a school project about HTML that required some math — and naturally he chose MathML since they were using Firefox and he wasn’t even aware of browser support issues — bliss 😉 ).

I’ve encountered the “MathJax is holding back browser implementations” argument a couple of times now and it feels like a Catch-22 to me. Without MathJax (I think) there wouldn’t be significant amounts of MathML on the open web and thus no incentive to implement MathML support natively. Now, with MathJax, there’s lots of MathML, yet there’s still no incentive. I suspect the reasons lie elsewhere. (And from speaking to Gecko, WebKit and Blink developers it does not lie with the developers).

The reason why I didn’t go into technical details about why native support is so important is that it didn’t fit in this forum (both in length and audience). But you’re right that perhaps I should have tried better. Some basic notes can be found on my personal blog at http://boolesrings.org/krautzb…

  • JonRimmer • 22 days ago

You and others here say MathJax isn’t an adequate solution. But you don’t explain why? It seems like a very successful project, and a far better approach from an software engineering perspective than native browser support.

Adding MathML support into every browser requires duplication of development effort and places responsibility for maintenance in the hands of browser vendor employees for whom MathML is neither a priority nor an area of expertise. Each implementation will vary in its performance, bugs and feature-set, and authors will need to know these differences in order to produce content that is compatible across all browsers. Future versions of the MathML spec will require development and deployment across all browsers, increasing the cost and delay in making new features available.

In contrast, keeping MathML support within a library allows development to proceed at its own pace, handled by those for whom it is both a priority and an area of expertise, and removes the cross-browser compatibility burden. MathML users then only have to deal with a single set of features and bugs, and can upgrade to newer versions of the library as and when they need to, instead of being beholden to browser development and upgrade cycles.

It seems like browser vendors would be better off concentrating on providing powerful, general low-level APIs for things like parsing, layout and rendering, in order to help the implementation and use of libraries like MathJax. That way, the web can scale to support custom rendering of not just MathML, but also Chemistry ML, Cell ML, and the many other useful markup languages and formats, while reducing the centralisation of effort and complexity within the browsers themselves.

  • Peter Krautzberger re JonRimmer • 22 days ago

But you don’t explain why?

See my other comments on this.

As for the other points your raise, they seem to apply to any newer web standard so I don’t quite see how they’re relevant to MathML specifically.

But yes, certain low-level APIs could make MathML polyfilling much easier; no surprise there. However, their implementation seems even less likely — especially since some of them have been rejected in the past.

Besides, MathML is not rocket science. It adds a few basic constructs to HTML/CSS such as multiscripts, stretchy characters and better table alignments. If you look at Gecko and WebKit it’s clear that it’s not a huge burden to maintain.

  • JonRimmer re Peter Krautzberger • 22 days ago

I don’t see any concrete technical reasons in any of your other comments for the inadequacy of MathJax. Could you be more specific about which comments you mean?

As for other new web standards, you are absolutely right that same points apply to them. The web has to get away from the situation where features must be implemented natively in the browser in order to avoid feeling second-class. That is the only way the web will be able to regain competitiveness with native platforms like iOS and Android. As it stands, the web is losing ground quickly to these platforms, because the need to implement features natively results in an unacceptable bottleneck in innovation.

Fortunately, while there may have been resistance in the past to making low-level capabilities available to library authors, that is changing. For example, there W3C CSS Working Group has recently created the Houdini Task Force [1] which aims to design low-level APIs for parsing, layout, content fragmentation and font metrics. I am certain that they and others would be very interested in hearing what APIs would help in implementing MathJax and equivalent libraries. The Extensible Web Manifesto [2] also covers similar ground.

[1] https://wiki.css-houdini.org/
[2] https://extensiblewebmanifesto…

  • Peter Krautzberger re JonRimmer • 22 days ago

Thanks, I’m well aware of Houdini and the extensible web manifesto and these are great initiatives with excellent people involved (such as Rob who commented here as well).

Personally, I think reports of the imminent death of the web are exaggerated. But even so, I’d argue that abandoning important and established web standards will do nothing but speed that up.

As for the technical issues, they are (again) nothing particular to MathML. Polyfilling a textual rendering component — be it math or bidi or linebreaking — always happens too late in the game, i.e., after the page renders because good layout will depend deeply on the surrounding context. Similarly, inserting large amounts of content fragments (easily in the thousands) into the DOM will always come with issues, especially performance.

More importantly, relying on a polyfill will prevent universal use. Developers will always have to make a conscious decision to add support, adding complexity and risking instability. In reality, we could never expect to be able to use mathematics in something as basic as a webmailer or a social network.

The thing is: the “if” is not even the problem. When you ask actual browser developers (be it Mozilla or Google or Apple or Microsoft) they in favor of MathML. The problem lies much more on the management side.

Ultimately, it comes down to how important mathematics is. (Why not kick bidi? SVG? flexbox? tables?)

The web is the most important medium for human communication and mathematics is one of the oldest and most universal forms of expression. Every school kid (worldwide) engages in mathematics (often for many years) and soon will do so in an HTML context. In particular, students will have to actively communicate (author, share, digest) mathematics and this will primarily happen on the web. To me, that makes it pretty important to have math natively on the web.

Looking back at my tiny blogging challenge

At the end of last year, I tried to motivate myself to write more so I set myself a tiny blogging challenge: writeo one post each week for the remaining weeks of the year, don’t spend more than for 30mins per post.

It didn’t really work out but perhaps in a good way. Yes, I posted 7 out 8 weeks so that’s close (still, Mike gets to name a charity of his choice). No, I most definitely did not spend just 30min per post (more like 1h, sometimes way more…). But those were means to an end which included a) try out something that gets me to write more regularly and b) make it interesting for my two readers, maybe add a third reader (crazy, I know!).

At the end of the year I was exhausted (so I had to take January off — well, be kind enough to pretend I did that intentionally and not simply failed to write that one last post for week 8). In part this was due to me writing on a couple of other, work-related places. I suppose one could say the blogging challenge helped there; e.g., it motivated me to finish a couple of outstanding blog posts on mathjax.org. But I think in reality it was the holidays and I had enough opportunity to write for a couple of hours (or sleep in to compensate).

As for the means, this exhaustion leaves me in doubt for the first one. Did I simply overdo it? Maybe I just need to pace myself better. We’ll see (thanks to Asaf for bugging me to get back on the wagon).

As for the second one, I think that was a bit of a miss. At least in the sense that my posts seemed to cause a lot of confusion and irritation. Then again, that was somewhat intentional, I just wasn’t happy with the kind of confusion, perhaps.

As for 2015, I will try to pace myself better. First target: finish that post from the original list of the tiny blogging challenge.

Bonus round: Why I care about native MathML

[This is week 7 of the challenge but really a post to make up for dropping the ball on week 5.]

Last week I wrote about why I care about MathML in general. Given that I work for a project that serves as a MathML polyfill, it’s worth while to to point out why native implementations matter; they matter an entire alot of mattering.

A while back, Alex Miłowski asked me for some quotes about how native MathML implementations are important so luckily I can copy myself here.

It’s important.

Some people say, “few people on the web need MathML support.” This is true. Just like saying “few people need children’s clothing”.

Why is MathML important? Education, education, and education. Mathematics is a core skill and a vast amount of educational time and effort is spent on teaching children and adults to understand and apply math & science. Very soon, HTML will be the dominating delivery method for educational content across the world. This means mathematics must be HTML, viz. MathML.

HTML rendering should be native

Where should HTML rendering be implemented? In the browser!

MathML has been HTML from its inception and after a (forced) XML-detour, MathML is back where it belongs: a part of HTML5. MathML layout is core HTML functionality, widely used in everything from web communities to professional publishers to educational startups. HTML and thus MathML rendering belongs in the browser.

Performance

While browser vendors show great interest in enabling polyfills to behave like native implementations, polyfills implementing layout standards (MathML, Flexbox etc), in the end, will not achieve native performance. The reason is simple: layout polyfills simply enter too late in the game — after the browser layout is done, at a point where the user expects content, not additional rendering delays. Moore’s Law helps a little but, ultimately, performance issues will prevent math and science from fulfilling their potential on the web.

Robustness

Even the most advanced polyfilling technology will remain a JavaScript solution. This increases the risk of problematic interactions with regular scripts for design, user interaction, and styling. Native support will always be more robust for web developers and consumers.

Ubiquity

Even the most ideal polyfill will require a conscious choice of the web developer to load it. This poses a grave restriction for end users and the emergence of new platforms for math and science on the web. From webmailer, to web based authoring, to social networks, all of these could turn out to be highly productive platforms — but it’s unlikely their developers will consider adding a polyfill for a perceived niche. With native MathML rendering, rendering MathML would be universal.

The Future

The web has revolutionized how we communicate. Not by magic but because thought leaders continually push the envelope, building new tools and platforms that transform how we work, speak, and think. These innovations feed back into standards development, enabling everyone to benefit and restarting the process, pushing us further.

MathML 3 captures traditional mathematical typography. Thanks to polyfills, we get a glimpse of how MathML might develop, how it can revolutionize the communication and dissemination of scientific knowledge. Yet without native implementations of MathML 3, we will never see MathML 4, 5 or 10, and the opportunities this will open up.

It took 50 years from Gutenberg’s printing press to the first typeset mathematics book. We’re 25 years into the web. Do we wait another 25 years or can browser vendors finally invest 1-2 developer years to get us there?


Update.

First, I changed the embedded video; it was previously this one.

Second, over on Google+, Harald Hanche-Olsen asked about the claim that MathML is a huge success. Here’s what I responded with.

Re success of MathML. Today, almost all equational content is stored as MathML. This is because almost all scientific (including mathematical) publishers have switched to XML workflows for production and archival where MathML fits in very naturally; similarly most technical writing (e.g., aerospace) is done in XML workflows.

For authoring, it’s a bit more complicated. It is similar to, e.g., vector graphics where applications such as Adobe Illustrator have their own formats but when you save vector graphics for re-use you’ll most likely export to SVG.

As I mentioned, there’s definitely the need for a professional-grade, open source pure MathML editor (ideally HTML5). The only one I know of is MathFlow. But if you have ever used MathJax then you have authored MathML — it’s how MathJax works: convert any input to MathML and then leverage our MathML rendering engine.

Similarly, lots of other tools are able to output MathML — besides converters from TeX (such as LaTeXML or tex4ht), Microsoft Word Equation editor can export to MathML, as does Open Office Math editor, MathType, MathMagic, the Windows Math Input Panel (handwriting recognition), MyScript (ditto), Maple, Mathematica and virtually any other tool you might have authored serious equational content in. (Oh well, I should’ve simply linked to http://www.w3.org/Math/wiki/Tools#Authoring_tools which I recently set up.)

Of course, Word is the big reason why most scientific and educational content ends up providing MathML. I don’t claim (or believe) that people are aware of most of this which was one of the reasons I wrote about it.

Why I care about MathML

[This is week 6~7? Mpf, I missed one (and a half?), bummer. I’ll try to make up for it.]

When I started this writing challenge, I had listed a couple of potential blog post titles. One of them was “Why you should care about MathML”. I realized later that I really didn’t want to pretend I could even try to tell my two readers what they should or should not care about. Instead, I want to jot down (remember: 30mins time limt) a few reasons why I started to care about MathML, alot.

I care about this Alot

© Ellie Brosh

Unsurprisingly, it was in many ways a story of my education. Here are two quotes from yours truly.

I think MathML is so far the best solution to present mathematical content on the web
actually me, Dec. 2009

Actually, more stuff wrong on my post; also, referencing Terry Tao’s blog, weird.

But mathml sucks […]
also actually me, Feb. 2011

(In my defence, I probably meant authoring tools and browser support.)

So as you can see, I flip-flopped a bit there (and, in a fundamentally different way, I still do). So here are five short reasons why I care about MathML.

a stable exchange format

When I started using MathJax on a personal blog (thanks to the above quote I realize I started blogging 5 years ago this month, (local copy), although I think I started to blog a year ealier on scivee.tv (though this seems lost)), I was first annoyed and then very happy to not use macros. Obviously, you can use macros with MathJax but I started to avoid personalized macros at all costs. Ultimately, they prevented me from writing mathematics elsewhere and they limited re-use of my writing by other people (well, ok, that’s more hope than reality I suppose).

MathML does not suffer any of these complications (well, technically Content MathML could if anyone used it). Instead, MathML provides a truly stable format for storing equational content while still allowing for re-use. Granted, it’s not exactly easy to write by hand but neither are SVG or HTML/CSS (certainly not as soon as you want to express something more complex). Still, I’d encourage anyone to spend some time with it (e.g., try copy-editing a random piece of MathML and compare that to copy-editing some macro-filled LaTeX horror). In any case, creating MathML is straight forward, especially for those knowing LaTeX syntax (even if we could use a a good open-source MathML editor). Ultimately, MathML is more readable in isolation thanks to its nature of being actually a mark-up language and not a programming language.

a focus beyond research

What struck me early on was how successful MathML was outside of research. Research mathematicians (and scientists) tend to think their habits are vital for the longevity of mathematical writing. However, technical writing (such as industrial (think aerospace) documentation), engineering, and most importantly school-level mathematics are arguably more important — and have benefited enormously from a mathematical markup that is easily handled by researchers and non-researchers alike. MathML has brought high quality rendering together with easy authoring to an incredibly wide and diverse community; a huge accomplishment.

accessibility, for real

What I also learned early on (in crass contrast to my 2009 self above) was that MathML has turned out to be critical for having truly accessible mathematics.

Of course, TV Raman’s AsTeR voiced TeX/LaTeX long before MathPlayer, ChromeVox or VoiceOver voiced MathML. But besides the refinements (which later tools could so easily provide), the notion of accessibility stretches far beyond voicing and visually impaired users. Features like synchronized highlighting would be much harder in TeX (just think about identifying subexpressions in a complex TeX macro, let alone in poorly authored TeX) but they are critical for helping people with learning or physical disabilities. Even more advanced features like summarization and semantic analysis are much more straight forward in a markup language like MathML than in TeX. And so is search whose importance can hardly be overstated in times of ever increasing publication pressure; without search mathematical knowledge won’t be accessible to us in the long run.

the DOM (etc)

The main reason why MathML is irreplaceable on the web is its compatibility with the DOM. This allows web developers to apply the full breadth of their tools to make mathematical content truly native instead of copying print-based layout. We cannot re-invent everything as Knuth did because web “typography” is far from finished and communicating on the web will probably change drastically every couple of years for the foreseeable future (just like communicating using the printing press did in another age). Having a naturally fitting technology allows mathematics to continually evolve its expression alongside other forms of expression on the web — an incredible benefit (and challenge!).

an open future to revolutionize how we “speak” mathematics

This leads me straight to the last and probably main reason why I care for MathML. What the web has already done for regular language (all over the world), it can do for the language of mathematics: transform the way we communicate; expand, enhance, deepen, and lighten the way we express mathematical thought. You don’t have to be Bret Victor to believe that in 30 years we will have developed new forms of expressions that truly leverage web technology and eliminate baroque limitations of black-and-white, print layout. We should strive to do so much better and I believe MathML is an important step in this direction.