Day 122: Blogger’s still an ignorant slut
One of the most difficult things to get right when you use free and open source software is just how much you can reasonably complain about things that don’t work right for you (even with commercial software, it’s easy to go overboard: paying $35 for Blogger Pro or $39.95 for Radio doesn’t actually give you the right to call Evan or Jake in the middle of the night and expect them to drop everything to fix your particular problem; you bought a program, not the developer’s soul). I don’t want to be a whiney luser, but sometimes, when you see what looks like an easy fix for a severe dataloss bug, it’s hard to just remain silent, month after month, only speaking up when someone asks what the hell just happened to their template.
Last December, I discovered (rediscovered, actually, since it was already in Bugzilla in a slightly different form) the reason why when some people edit their Blogger templates in Mozilla, or Netscape 6+, or Phoenix, or Camino, or anything else built off Gecko, they suddenly find that their template has been ruined, with all their links turned into just <a> (the thing people notice right off), along with losing things like CSS classes and table widths, in fact every sort of tag attribute.
The problem is with the </noscript> tag: for no particular reason, once Gecko sees an unescaped </noscript> in the content of a textarea, it will strip the attributes off every tag after that. It doesn’t make any sense, but then it doesn’t have to: the content model for textareas is #PCDATA, which is parsed character data, and that means that unless you are starting a tag, you don’t use a <, you use a <. So even though it’s silly of Mozilla to strip attributes like that, and every other browser around handles it just fine, it’s wrong, and when a Mozilla bug is triggered by a page doing something wrong, it’s vastly less likely to be fixed.
However, fixing it on Blogger’s end should be fairly simple: if you put a </textarea> tag in your template, Blogger has to escape it, since that’s the one tag that every browser has to be looking for inside a textarea. If they built the template editing page without escaping your </textarea>, then your template would suddenly end right there, with no way to get the rest of it back. So, when the page is assembled, your </textarea> is converted to </textarea>, which puts </textarea> inside the textarea, rather than ending it. All they have to do is the exact same thing with </noscript>, converting it to </noscript> as well. The exact same thing will be submitted when you save changes, everything will work just the same in every browser around, the only difference will be that I won’t have to explain to Mozilla users, and Netscape users, and Phoenix users, and Camino users, just exactly why their Blogger template was destroyed, when all they did was open it up and then save it.
I run the PHP function htmlentities() (or htmlspecialchars() depending on my mood) on anything that I am about to display as the pre-filled-in content of an input field or textarea. All entities are converted, but the information is still displayed as it should be in the form fields and behaves just like you would expect it to without any risk of tags ruining everything. Keeps things valid HTML as well.
Me too, mostly, except for one dotcomments admin script where I severely messed up my handling of comments with already encoded code – I don’t use it often enough to remember that I need to fix the order of my double-encoding when I’ve got the time. But I assume that they didn’t do the right thing and encode everything because of the cost, either in time and processor to do it, or in added bandwidth (I’d hate to have to operate at the level where four characters instead of one for every < was a serious issue, but for Blogger they probably do add up).
Blogger, you brilliant sweetheart
Blogger’s templates are now a Mozilla-safe zone.