WebKit and MathML
Dave Morrison always has the coolest toys. Years ago, he was the only person I knew with SSH on his cell phone. So it wasn’t all that surprising that he was the owner of the first iPhone I ever got to fondle.
“Look,” he said, “here’s your blog.”
Sure enough, there was Musings, in all its glory … Or most of it. “No MathML,” he muttered. And, indeed, that’s something that I’ve been muttering about for years. In the two years since it became open-source, WebKit has gained a lot of mindshare. In addition to Safari and the iPhone, it powers Nokia’s mobile browser and even the developers of KHTML have bowed to the inevitable.
So it’s a little disappointing that the WebKit MathML project has gone precisely nowhere. Dave and I discussed the matter, and he even expressed an interest in joining the aforementioned project … if only there were something to join.
So where are the developers interested in implementing MathML in WebKit? Y’all should talk.
Someday, it would be nice to be able to read this blog on Dave’s phone.
Update (7/26/2007):
Speaking of Safari, it appears that I unjustly maligned that browser’s DOM support in real XHTML. It turns out that it’s broken, but not quite as broken as I thought. What I thought was brokenness was merely WebKit being stricter than the others.document.createElement doesn’t do what you think it does1 (as it does in Mozilla or Opera). You really do need to use document.createElementNS. The upshot is that Instiki now sends S5 slideshows to Safari as real XHTML. Which means that inline SVG, if not MathML, works.1 In other browsers, document.createElement creates an element in the XHTML namespace. In Safari, it creates an element in the null namespace.
Re: WebKit and MathML
Design Science has offered to work with them years ago by helping them create a WebKit (Safari) plugin interface capable of handling our MathPlayer plugin. This would not at all preclude others from creating MathML display engines using the same interface. We would have no interest in making the interface proprietary. In fact, such an interface could be general enough to handle other XML languages. We would even allow them to distribute MathPlayer until them came up with their own engine. Our only restriction is that we won’t make MathPlayer open source. This is core technology for us and we still have to pay the bills ;-) So far they haven’t taken us up on the offer.
Paul Topping,
Design Science, Inc.