MT Admin
It sounded like a simple request: serve the MovableType Administrative Interface with the correct XHTML MIME-type, so that authors at the String Coffee Table could see the MathML when they preview their posts.
Shouldn’t be too hard, eh? After all, MovableType is supposed to be pretty hip with Standards-compliance, and we’re already serving all of the public-facing pages with the correct MIME-type.
One of the abiding illusions of web-design, is that, on a well-constructed XHTML website (and, if MovableType isn’t one, what is?), changing from text/html to the correct application/xhtml+xml should be an easy transition. Well, here was a good test case: a web application, written by hip, Standards-aware people, but which had (evidently) never been tested with an XHTML MIME-type.
How did it fare?
Almost every single screen was ill-formed. Those which weren’t, lacked the required xmlns attribute on the <html> element, and so were rendered as an XML document tree in Mozilla.
Correcting all of that, the Javascript — all of it— which provides much of the functionality in the MT Admin Interface, was broken:
- 1. Hidden away, unseen, in XML comments.
- The content of the
<script>element is CDATA in HTML, but PCDATA in XHTML. You can’t hide scripts in
in XHTML. If you need to hide scripts in XHTML, and want them to work when served as HTML as well, you can go to extraordinary lengths and wrap them in<script> <!-- ... --> </script>
I did that for those scripts that really needed it.<script> <!--//--><![CDATA[//><!-- ... //--><!]]> </script> - 2. Used
document.write. - Not allowed in XHTML. You need to use DOM-scripting.
- 3. Triggered by
onClick="..."oronChange="..."event handlers. - Attributes are case-sensitive in XHTML. Those need to be
onclick="..."andonchange="...".
What I thought would be a few hours work, proved to be a major undertaking. My accumulated changes, eventually ran to a 1340-line unified-diff file. Thirteen hundred and forty lines1!
I made no attempt to produce valid XHTML, nor did I attempt to add any new functionality. I merely wanted something which would not produce a Yellow-Screen-of-Death and which had functional Javascript. Doing that required a patch file more than twice as long as my existing set of patches to MovableType, which add all sorts of cool new functionality.
Now, someone will surely pipe up with the fact that the WordPress Administrative Interface works just fine under application/xhtml+xml. Indeed, it does. But, then, its lead developer actually uses the correct MIME-type to run his own site.
I think the moral is clear …
Update (5/5/2005): It’s not a bug, it’s a feature!
Urs reported a disastrously bad bug when serving the MT Administrative Interface as application/xhtml+xml: compose and preview an entry. Then click on Re-Edit this entry. Poof! … all the line breaks in your text are turned into spaces. The same operation continues to work flawlessly when the page is served as text/html.
This drove me up a wall, till I discovered the reason for the behaviour. The text of your entry is passed as a hidden form field
<input type="hidden" name="text" value="..." />
where “…” is the text of your entry. And what does the XML Specification say should be done with linebreaks in attribute values? Why, golly, they should be turned into spaces.
As The Church Lady would say, “Isn’t that special!” Do any of the XML gurus out there know how one is supposed to submit a form with hidden textual data, in which white spaces are preserved?
Isn’t that semantic:
Sam Ruby comes through with the solution. Replace<input type="hidden" name="text" value="..." />
with
<textarea style="display:none" readonly="readonly" name="text">...</textarea>
for any hidden form-input that needs to be white-space-preserving. Tell me again about how you thought XHTML was “more semantic”?
I guess that, now, I need to hunt through the MT Administrative interface for (other) instances of this. But, at least, Urs’s problem is solved.
Update (5/10/2005): 1399 Bottles of Beer
Well, it seems to have stabilized at 1399 1624 lines of unified diffs. For the curious, or masochistic, herewith is my patch to turn the MT Admin interface into well-formed XHTML. Don’t bother complaining that it’s still not valid XHTML. I ain’t listening. If, however, you find further instances where the MT Admin interface is not well-formed, please let me know.
These patches were extracted from my only slightly larger (1975 2200 line) patch file for MT 3.16. The latter implements all kinds of additional useful stuff, like (entry- and) comment-validation, forced comment previews, threaded comments, internationalized trackbacks, comment text filters, …
1 Even discounting the ‘context’ lines in a unified-diff, that was still 510 added/subtracted lines of code.
Re: MT Admin
It does because I reported all the bugs I encountered with the admin interface of WordPress some time ago. (When I still used it.) I assume someone continued to check all those things after that a bit closer or so, but before that every page was ill-formed. (Matt is actually using text/html for his weblog at the moment. He gets invalid characters in his comments occasionally, et cetera.)