Bloggy Matters
I’ve been too busy, lately, to do much posting. But there are a couple of blog-related matters I thought were noteworthy. So here goes …
Open Source MovableType
I put a lot of effort into extending the capabilities of MovableType, to make publishing mathematical content fun and easy. Some of what’s needed is available in the form of plugins
- itexToMML
- Contains the itex2MML binary, which converts embedded itex input into MathML, and adds itex-enabled text filters to MovableType.
- MT-Textfilters
- Adds support (with a little hacking) for user-selectable text filters in comments.
- MTValidate
- A built-in copy of the W3C Validator, to make sure that entries and comments are valid XHTML.
- MTHash
- A little hack to ensured that the Preview function (where the aforementioned validator runs) isn’t bypassed.
- SVGFix
- Fixes up namespace support in SVG content, to make the Validator happy. It also rolls in the functionality of the NumericEntities plugin.
But much of what was required came in the form of patches to the MT source code.
And therein lay my frustration. After all this work, there’s no easy way for anyone else to replicate this setup, because MovableType isn’t open-source and I couldn’t distribute my changes in any rational way … until now.
SixApart has announced that MT4 (currently in beta) will be released as open-source (with a GPL license).
Moreover, the whole thing is moving to a component architecture, which will hopefully make it even easier to modify the things that need modifying.
I haven’t tried out the beta yet (no time, remember?). But I’m very excited at the prospect. At some point, in the not too-distant future, I hope it will be possible to download an XHTML+MathML+SVG ready version of MovableType, and be good to go.
If anyone’s interested in helping fashion the world’s most technologically advanced blogging software, let me know.
MathML in HTML5?
A while back, I wrote rather breathlessly about the prospect that HTML5 might allow one to embed MathML and SVG content.
Technically, I think it’s doable.
With a few minor restrictions on authoring,
- No named entities
- All empty elements, like MathML’s
<none/>or SVG’s<rect/>need to be written out in full (<none></none>).
both of which are handled automatically by the SVGFix plugin, one could easily stick <math> and all of its children in the MathML namespace and <svg> and all of its children in the SVG namespace in the DOM. Which is all that’s required for renderers that support them to be able to handle this content1.
But, watching the subsequent discussions, it’s not so clear that it’s gonna happen.
- Whenever anyone suggests extending HTML5 in this way, someone invariably retorts, “If you want to embed other XML dialects (MathML, SVG, …), why not use XHTML5?” Obviously, using the XML serialization (XHTML5) doesn’t raise any of the issues that trying to shoehorn this type of content in to HTML would.
- There’s strong sentiment, in some quarters, not to blur the line between XHTML and HTML. Appendix C was a fiasco, according to them, and allowing XML features in HTML documents would be to head down the same misguided path.
- MathML (and perhaps SVG) are niche technologies, with few users; the HTML5 Spec is supposed to cater to millions. Infrequently-used features of HTML4 have been pitched. And those, probably, had more users than MathML does.
- If the HTML5 Spec did bless the inclusion of MathML and SVG content (and specify how these should be parsed), there would then be an onus on browser vendors to actually implement these Standards. Opera and Safari have no intention of implementing MathML and Internet Explorer has no intention of implementing either. Browser vendors would, surely, prefer to be able to announce full HTML5 support and, even if MathML/SVG support were labelled “optional”, its mere mention would create demand that they implement it before being able to do so.
None of these seem particularly persuasive reasons to me.
- Theoretically, authors could just flip a switch and have their CMS spit out XHTML(5) instead of HTML(5). If only there were such a switch to flip. There’s a reason I’ve had to waste a substantial amount of time adapting MovableType blogging software to this task (and intend wasting more time in the future). But say you wanted a Wiki instead. You’d be out of lu… oh wait.
- I’d be more persuaded by this argument if those seeking to preserve the purity of XHTML didn’t, at the same time, think that XML on the web has been a colossal failure.
- The use-case for vector graphics is substantial. And SVG is, at least in principle, accessible, as is MathML. The need for mathematics is more widespread than you’d think. But, since MathML is basically unusable by all but the privileged few, I tend to recommend jsMath. Most people seem to make do with crappy little GIF images of their equations.
- What’s good for the web ≢ what’s good for browser vendors.
Still, while I don’t think they’re persuasive, I think that they’re persuasive enough that they may prevent the idea from being studied seriously. And things that don’t get serious study don’t get into the Spec.
1 I’m not sure what you’d do with XLink attributes. They’re nice to have in MathML, but are pretty much indispensible in SVG. And — because SVG uses camel-cased element and attribute names — you will need to do case-sensitive parsing. Perhaps these issues will torpedo the idea. If they don’t, then perhaps the nesting of different dialects (as with SVG’s <foreignObject>, if that ever became practical to use) would. I don’t know, but that’s the kind of thing I think should be the focus of discussion.
Re: Bloggy Matters
This sort of argument always gets my goat. Well maybe it’s because it’s so hard to use MathML/SVG that few people use them. Doesn’t that ever occur to anyone?