So, if you're the sort of individual who uses the View Source feature of your browser, you'll have seen the following:
<!-- Short Shameful Confession: I hacked this up on a Palm Pilot, did
initial markup in Emacs, then fed it to Page Composer in Nav 4.0
to tidy up my tags a little. I'm too techno-lazy by far. -->
"tidy up my tags a little"? Whatever was I thinking? Further down the page you'll find something a little closer to reality:
<CENTER> <HR WIDTH="100%"></CENTER> <!-- now why did mozilla bother to do that? -->
Why indeed? Obviously somewhere in the internals of mozilla, now exposed to all, there is a reason for (1) my <center> tag being on a separate line and (2) the WIDTH="100%" in the <hr> tag. Perhaps it parses easier.
But if it was able to read my original HTML, which happened to be the HR tag on its own, then why rewrite it? I didn't see a "Rewrite this when I save?" dialogue box when I was saving it, much less a "Rewrite this in a difficult-to-manage-in-a-text-editor format" option on said non-box.
I'm all for rewriting HTML into machine-friendly form, but only on request. Considering that so much of Mozilla conforms to the Principle of Least User Astonishment, it seems Astonishing to this User that Mozilla would mangle my carefully crafted HTML while I'm not looking.
Besides which, my preferred HTML reformatting is more along the lines of indenting as if it were code, so you can find matching open tags and close tags by scrolling up and down the page and watching what column stuff is in. It's not bandwidth friendly, but I'm sure that's not difficult to remedy - just feed the file to Composer, and select "Save As..."...
Not A Unix Rant: the title for this page is an actual error spat out by mt on Tandem's Non-Stop UX when I mistakenly typed mt -f /dev/tape/rmt 0 instead of mt -f /dev/tape/rmt0. I can't recall the exact path, but the error was triggered by the errant spacing. Now that's a parse error.