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.

June 17, 2007

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/1324

9 Comments & 1 Trackback

Re: Bloggy Matters

MathML (and perhaps SVG) are niche technologies, with few users; the HTML5 Spec is supposed to cater to millions.

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?

Posted by: Aristotle Pagaltzis on June 18, 2007 6:13 AM | Permalink | Reply to this

Re: Bloggy Matters

Is it really hard to use SVG? There are a good deal of graphical tools now to edit SVG and just do “save as…”

The issue here I see is more the drag and drop of inline SVG. I have done a drawing in a graphical software and I want to put it in my XHTML. Amaya does it. So it is possible.

The silly thing is what’s happening now when I’m typing this comment. I’m in a text form area to write something when I should be able to have full capabilities of creating content in a wysiwyg mode.

  • When the browser is crashing, I loose my editing.
  • The area is not simple to resize except in some browsers like Safari 3 for example.
  • 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.

Posted by: karl dubost, w3c on June 21, 2007 2:24 AM | Permalink | Reply to this

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.
  • I want arrow heads in Opera and Prince.
Posted by: Henri Sivonen on June 21, 2007 3:46 AM | Permalink | Reply to this

Re: Bloggy Matters

Gecko trunk now supports em-sized svg.

Posted by: Henri Sivonen on June 27, 2007 7:26 AM | Permalink | Reply to this

Editing

  • When the browser is crashing, I loose my editing.

Don’t use such crash-prone software.

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

There are some alternatives to CSS3 resize listed 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.

Posted by: Jacques Distler on June 21, 2007 8:22 AM | Permalink | PGP Sig | Reply to this

Re: Bloggy Matters

Comment on this post from IRC:

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

Posted by: Henri Sivonen on June 21, 2007 4:05 AM | Permalink | Reply to this

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}}

Posted by: Jacques Distler on June 21, 2007 8:05 AM | Permalink | PGP Sig | Reply to this

Re: Bloggy Matters

hmmm interesting I have a complete smooth experience of SVG. I never found it hard. Henri is addressing implementations troubles, not SVG issues in his list.

And there are some issues with SVG 1.0 like text flow.

:) I guess question of personal experiences in different type of contexts.

Posted by: karl dubost, w3c on June 21, 2007 4:28 AM | Permalink | Reply to this
Read the post SVG in MathML in ...
Weblog: Musings
Excerpt: On mixing SVG and MathML.
Tracked: October 23, 2007 1:56 AM

Re: Bloggy Matters

Done. Enjoy!

Posted by: Ian Hickson on April 9, 2008 5:44 AM | Permalink | Reply to this

Post a New Comment