Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

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.

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.

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.

Posted by distler at June 17, 2007 11:07 PM

TrackBack URL for this Entry: http://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/1324

Re: Bloggy Matters

Yes, SVG is hard. It was crazy how hard it was to make scalable, non-crufty and interoperable (Prince 6 beta, Firefox trunk, WebKit trunk, Opera 9.20) figures for the XHTML version of my thesis. No animation—just plain old figures for an academic publication.

Very quick laundry list (off the top of my head):

Gecko needs to get em sizes on the svg element right.

CSS needs a concept of intrinsic aspect ratio (from viewBox) and then it needs to be super-easy to say that I want a figure this wide in CSS length and as high as needed to keep aspect ratio from viewBox.

Prince needs to get interoperable with percentage sizes on the svg element.

Opera needs to get interoperable with implicit dimensions of the svg element.

Editing

The area is not simple to resize except in some browsers like Safari 3 for example.

There are some alternatives to CSS3 resizelisted here. I like the bookmarklet, though I’d like CSS3 resize support a lot better.

We don’t have a full editing menu.

We can’t do a temporary save.

I wish there was an option ala setenv EDITOR of unix, where you could from your form controls trigger a local editor and edit a fragment of XHTML+SVG+MathML.

This should be the responsibility of the Operating System/Editor. Note that, in properly-written Cocoa Apps (like Safari and Camino), the contents of the <textarea> is a Cocoa TextObject. That’s why the Services Menu works (for instance).

What you want is a system-wide Editing Service (like the system-wide Spell-Checking Service) so that you can use your favourite editor controls in any Cocoa TextObject.

Re: Bloggy Matters

“[I] love how some of [the] most important issues are relagated to a footnote ” — Hixie

I guess he’s unfamiliar with the house style. On my blog, the important issues are always relegated to the footnotes.

That said, the issues in this footnote are almost exclusively issues for SVG-in-HTML5. The only issue for MathML-in-HTML5 is how to do this:
Rμν−12gμνR=8πGTμν
R_{\mu\nu}- \frac{1}{2}g_{\mu\nu} R = 8\pi G\, \href{http://en.wikipedia.org/wiki/Stress-energy_tensor}{T_{\mu\nu}}