Thoughts From Eric Archive

It’s been said before that web inspectors — Firebug, Dragonfly, the inspectors in Safari and Chrome, and so forth — are not always entirely accurate.  A less charitable characterization is that they lie to us, but that’s not exactly right.  The real truth is that web inspectors repeat to us the lies they are told, which are the same lies we can be told to our faces if we ask directly.

Here’s how I know this to be so:

body {font-size: medium;}

Just that.  Apply it to a test page.  Inspect the body element in any web inspector you care to fire up.  Have it tell you the computed styles for the body element.  Assuming you haven’t changed your browser’s font sizing preferences, the reported value will be 16px.

You might say that that makes sense, since an unaltered browser equates medium with “16”.  But as we saw in “Fixed Monospace Sizing“, the 16px value is not what is inherited by child elements.  What is inherited is medium, but web inspectors will never show you that as a computed style.  You can see it in the list of declared styles, which so far as I can tell lists “specific values” (as per section 6.1 of CSS2.1).  When you look to see what’s actually applied to the element in the “Computed Styles” view, you are being misled.

We can’t totally blame the inspectors, because what they list as computed styles is what they are given by the browser.  The inspectors take what the browser returns and prettify it for us, and give us ways to easily alter those values on the fly, but in the end they’re just DOM inspectors.  They don’t have a special line into the browser’s internal data.  Everything they report comes straight from the same DOM that any of us can query.  If you invoke:

var obj = document.getElementsByTagName('body')[0];
alert(getComputedStyle(obj,null).getPropertyValue('font-size'));

…on a document being given the rule I mentioned above, you will get back 16px, not medium.

This fact of inspector life was also demonstrated in “Rounding Off“.  As we saw there, browsers whose inspectors report integer pixel values also return them when queried directly from the DOM.  This despite the fact that it can be conclusively shown that those same browsers are internally storing non-integer values.

Yes, it might be possible for an inspector to do its own analysis of properties like font-size by checking the element’s specified values (which it knows) and then crawling up the document tree to do the same to all of the element’s ancestors to try to figure out a more accurate computed style.  But what bothers me is that the browser reported computed values that simply aren’t accurate in the first place.  it seems to me that they’re really “actual values”, not “computed values”, again in the sense of CSS2.1:6.1.  This makes getComputedStyle() fairly misleading as a method name; it should really be getActualStyle().

No, I don’t expect the DOM or browsers to change this, which is why it’s all the more important for us to keep these facts in mind.  Web inspectors are very powerful, useful, and convenient DOM viewers and editors, essentially souped-up interfaces to what we could collect ourselves with JavaScript.  They are thus limited by what they can get the browser to report to them.  There are steps they might take to compensate for known limitations, but that requires them to second-guess both what the browser does now and what it might do in the future.

The point, if I may be so bold, is this:  never place all your trust in what a web inspector tells you.  There may be things it cannot tell you because it does not know them, and thus what it does tell you may on occasion mislead or confuse you.  Be wary of what you are told — because even though all of it is correct, not quite all of it is true, and those are always the lies that are easiest to believe.

• Inspector Scrutiny was published on Monday, February 15th, 2010.
• It was assigned to the Browsers, Commentary, Tools, and Web categories.
• There have been ten replies.

Monospace text sizing is, from time to time, completely unintuitive and can be quite maddening if you don’t look at it in exactly the right way.  Fortunately, there is a pretty simple workaround, and it’s one you might want to consider using even if you weren’t aware that a problem existed.

But first, allow me to lay some foundations.  Assuming no other author styles beyond the ones shown, consider the following:

span {font-family: monospace;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

All right, what should be the computed font-size of the span element?  Remember, there are no other author styles being applied.

The savvier among you will have said: “It depends, but most likely 13px.”  That’s because here, the size of the monospace text is controlled by the browser’s preferences.  The vast majority of users, of course, have never touched their default settings of “16” for proportional fonts and “13” for monospace/fixed fonts.  For them, then, the answer is 13px.  Similarly, if I’d asked about the p element’s computed font-size, the answer would be: “It depends, but most likely 16px.”

So let’s add a bit more and see where we land.

span {font-family: monospace; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

As before: bearing in mind that there are no other author styles, what should be the computed font-size of the span element?

In this case, building on the previous question and answer, you might say, “It depends, but most likely 16px.”  The reasoning here is pretty straightforward:  since the computed font-size of the p element is 16px, the font-size: 1em; assigned to the span will result in it having the same size.

And that’s true… in two of five browsers I tested: Opera 10 and Internet Explorer 8.  In the other three I tested—Firefox 3.6, Safari 4, and Chrome 4—the computed (and rendered) font-size of the span is 13px, the same as in our first example.  This result holds true if the rule is changed to use font: 1em monospace; instead of the two separate properties.  The behavior continues to persist even when adding specific font families, like Courier New, Courier, Andale Mono, and so on to the rule.  It also persists if 1em is converted to 100%.

So in other words, even though I have written CSS that explicitly says “Make the font-size of this element the same as its parent”, three of five browsers apparently ignore me.

I say “apparently” because what’s happening is that those browsers are allowing the span to inherit the default font-size from its parent (and thus, indirectly, all its ancestors), but the default font-size is medium.  If you go look up medium, you find out that it doesn’t have a defined numeric size. So what those browsers do is equate medium with the preference settings, which means it’s different for monospace fonts than for everything else.

In other words, those three browsers are doing something like this:

1. This span needs to have the same font-size as its parent element.
2. The parent’s font-size is medium, even though when my web inspector (or an author’s DOM script) asks, I report the 16px I used to output the text.  So the span‘s font-size is actually medium.
3. This medium-sized span is using a monospace font.  The preference setting for monospace is “13”, and I equate medium with the preference setting, so I’ll output the span using 13-pixel text.

Opera 10, as I said, doesn’t do this, even if your monospace font preference setting is the default value of “13” or indeed different from the preference for non-monospace fonts.  And IE8 doesn’t appear to do it either, although you can’t set numeric font size preferences in IE8 so what it’s actually doing is open to interpretation.  Oh, IE8, you inscrutable little scamp, you.

All that might seem reasonable enough, but it turns out that’s not the whole story.  No, the three resizing browsers are being a good deal more “clever”, if that’s actually the word I want, than that.  In fact, what those browsers do makes it seem like they use the two preference settings to create a ratio, and that ratio is used to scale monospace text.  That’s not actually what’s happening, but it looks that way at first.  To see what I mean, let’s consider:

span {font-family: monospace; font-size: 2em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

Again: in the absence of other author styles, what should be the computed font-size of the span element?

The answer: “It depends, but most likely 26px as long as we aren’t talking about Opera 10 or IE8.  If it is one of those two, then most likely 32px.”  Why?  Because the resizing browsers see the font-size: 2em; declaration as “twice medium” and twice 13 is 26.  Opera 10 and IE8, as previously established, don’t do the resizing.  Or else they simply interpret medium as being equal to the proportional font size preference setting.  Whatever.

Okay.  So what all this means is that in many browsers, you can declare that an element’s font size should be twice the size of its parent’s and have it actually be 1.625 times the size — or, if you want to look at it another way, 0.8125 times the size you expected it to be.  The 0.8125 comes from 26/32, which of course reduces to 13/16.  If you were to adjust your browser’s preferences so the monospace setting is “15”, then monospace fonts would be 0.9375 (15/16) times the expected size.

But — and here’s where things get really fun — this is not always so.  See, you may not have run into this problem if you’ve been declaring specific font families with no generic fallback.  Consider this variation (note that I dropped back to 1em for the font-size):

span {font-family: "Courier New"; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

This time, in every one of the five browsers I mentioned before, assuming the browser defaults, the computed (and rendered) font-size of the span will be 16px.  Not 13px.  And the only difference is that we switched from a generic font family to a specific one.

“Hey presto!” you shout.  “We’ll just tack the generic family on the end there and be right as rain!”  Sadly, no.  For if you do this:

span {font-family: "Courier New", monospace; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

…then the answer to the question I keep asking will be:  “It depends, but given browser defaults it will be 16px, unless we’re talking about Safari.  In that case, it’s 13px.”

Really.  Alone among the browsers I tested, Safari goes back to doing the resizing when you provide a generic fallback to your specific family.  Or even multiple families.  Do your best to make sure the user at least gets a fixed-width font, and you get a size smaller than you’d intended.  (You can get the back story on this in a late-2006 post on the Surfin’ Safari blog.)

So what do we do?  Get creative.  That’s what the ARIA folks did in their specification’s style sheet, where they declare two font stacks: the first with a generic fallback, and the second without it.  That works, but it’s ugly.  I didn’t like that at all.  And then, halfway through writing up this post, a fix came to me like a shot in the dark.  Check this out:

span {font-family: "Courier New", monospace, serif; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

This time around, the answer is:  “It depends, but given browser defaults, 16px.”

Really!  Even in Safari!  And in all tested browsers, it falls back to a generic monospace font at the requested size even if the specific family (or families) we declare aren’t available!  This can be verified by altering the specific font family to something that doesn’t actually exist:

span {font-family: "Corier Neu", monospace, serif; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

Monospacey goodness at the intended, parent-matching size.  It’s enough to make a body believe in monotheism.

Since I generally assume that anything I devise was already invented by someone else, I went Googling for prior art.  And wouldn’t you know it, the Wikipedia folks had worked it out around the end of last year.  This, of course, supports my contention that Wikipedia is the new Steve Allen.  I also found some claims that ending the font stack with monospace, monospace would have the same effect, but that wasn’t borne out in my testing.  Perhaps it worked in older versions of browsers but no longer does.

I did leave out another way to make monospaced fonts behave as expected, which you may have already figured out from the preceding: declare the font-size for any parent of a monospaced element to be a length value, along the lines of body {font-size: 12px;}.  That will pass the length value down the document tree to the monospaced element via inheritance, which will use it without resizing it in every browser I tested.  Though you may have heard that page zooming makes pixel-sized text okay, I’m not really convinced.  Not yet.  There are too many people who don’t know how to zoom, and too many whose browsers aren’t advanced enough to zoom pages.  Even in page-zooming browsers, there are problems with pixel text.  So I’m still on the ems-and-percentages bandwagon.

In fact, there are a fair number of details and extra browser oddities that I left out of this, as it’s already way more than long enough, and besides you don’t really want to hear the gory details of manually stepping through 37 different preferences settings just to verify a theory.  Plus you already heard about the font-size rounding investigation that spawned off of this one, about halfway through.  I think that’s more than enough for the time being.

I should also lay down a caveat: it’s possible that this behavior will be interpreted as a bug by the Safari team and “fixed”, if that’s the word I want, in a future release.  I really hope not — and if they’re looking for ways to improve how they handle monospace font sizing, I have a few suggestions — but it is possible.  Adjust your expectations accordingly.

And with that, I’m going to stop now.  I hope this will be useful to you, either now or in the future.

• Fixed Monospace Sizing was published on Friday, February 12th, 2010.
• It was assigned to the Browsers, CSS, Standards, and Web categories.
• There have been twenty-three replies.

In the course of digging into the guts of a much more complicated problem, I stumbled into an interesting philosophical question posed by web inspection tools.

Consider the following CSS and HTML:

p {font-size: 10px;}
b {font-size: 1.04em;}

<p>This is text <b>with some boldfacing</b>.</p>

Simple enough.  Now, what is the computed font-size for the b element?

There are two valid answers.  Most likely one of them is intuitively obvious to you, but take a moment to contemplate the rationale for the answer you didn’t pick.

Now, consider the ramifications of both choices on a situation where there are b elements nested ten layers deep.

If you hold that the answer is 10px, then the computed font-size of the tenth level of nesting should still be 10px, because at every level of nesting the mathematical answer will be rounded down to 10.  That is: for every b element, its computed font-size will be round(10*1.04), which will always yield 10.

If, on the other hand, you hold that the answer is 10.4px, then the computed font-size of the tenth level of nesting should be 14.802442849px.  That might get rounded to some smaller number of decimal places, but even so, the number should be pretty close to 14.8.

The simplest test, of course, is to set up a ten-level-deep nesting of b elements with the previously-shown CSS and find out what happens.  If the whole line of text is the same size, then browsers round their computed font-size values before passing them on.  If the text swells in size as the nesting gets deeper, then they don’t.

As it happens, in all the browsers I’ve tested, the text swells, so browsers are passing along fractional pixel values from level to level.  That’s not the interesting philosophical question.  Instead, it is this:  do web inspectors that show integer font-size values in their ‘computed style’ windows lie to us?

To see what I mean, load up the font size rounding test page in Firefox and use Firebug to inspect the “1(“, which is the first of the b elements, in the first (1.04em) test case.  Make sure you’re looking at the “Computed Styles” pane in Firebug, and you’ll get a computed font-size of 10.4px.  That makes sense: it’s 10 × 1.04.

Now try the inspecting that same “1(” in Safari or Opera.  Both browsers will tell you that the computed font-size of that b element is 10px.  But we already know that it’s actually 10.4px, because the more deeply-nested layers of b elements increase in size.  These inspectors are rounding off the internal number before showing it to us.  Arguably, they are lying to us.

But are they really?  The reason to doubt this conclusion is that the values shown in those inspectors accurately reflect the value being used to render the characters on-screen.  To see what I mean, look at the last example on the test page, where there’s sub-pixel size testing.  The “O” characters run from a flat 10 pixels to a flat 11 pixels in tenths (or less) of a pixel, all of their font-sizes assigned with inline style elements to pin the characters down as much as possible.  In Safari, you can see the size jump up one pixel right around the text’s midpoint, where I wrote font-size: 10.5px.  So everything from 10px to 10.49px gets drawn at 10 pixels tall; everything from 10.5px to 11px is 11 pixels tall.  Safari’s inspector reflects this accurately.  It’s telling you the size used to draw the text.

In Opera 10.10, you get the same thing except that the jump from 10 to 11 pixels happens on the very last “O”, both visually and in the inspector (Dragonfly).  That means that when it comes to font sizes, Opera always rounds down.  Everything from 10px to 10.9px — and, presumably, 10.99999px for as many nines as you’d care to add — will be drawn 10 pixels tall.  Brilliant.

In Firefox for OS X, there’s no size jump.  The “O” characters look like they form a smooth line of same-size text.  In fact, they’re all being drawn subtly differently, thanks to their subtly different font-size values.  If you use OS X’s Universal Access screen zooming to zoom way, way in, you can see the differences in pixel shading from one “O” to the next.  Even if you don’t, though, the fact that it’s hard to tell that there is an increase in size from one end of the line to the other is evidence enough.

In Firefox for XP, on the other hand, the size jump occurs just as it does in Safari, going from 10 pixels to 11 pixels of text size at the 10.5 mark.  But Firebug still reports the correct computed font-size values.  Thus, its reported value doesn’t match the size of the text that’s been output to the screen.  Arguably, it’s lying just as much as Safari and Opera,  in a different way.

But, again: is it really?  The computed values are being accurately reported.  That there is a small variance between that fractional number and the display of the text is arguably irrelevant, and can lead to its own confusion.  Situations will arise where apparent rounding errors have occurred — I see people complain about them from time to time — when the apparent error is really an artifact of how information is delivered.

I have my own thoughts about all this, but I’m much more interested in the thoughts of others.  What do you think?  Should web inspectors report the CSS computed values accurately, without regard to the actual rendering effects; or should the inspectors modify the reported values to more accurately reflect the visual rendering, thus obscuring the raw computed values?

Addendum 10 Feb 10: I’ve updated the test page with a JS link that will dynamically insert the results of getComputedStyle(el,null).getPropertyValue("font-size") into the test cases.  The results are completely consistent with what the inspectors report in each browser.  This tells us something about the inspectors that most of us probably don’t consciously realize: that what they show us rests directly on the same JS/DOM calls we could write ourselves.  In other words, inspectors are not privileged in what they can “see”; they have no special view into the browser’s guts.  Thus another way to look at this topic is that inspectors simply repeat the lies that browsers tell the world.

• Rounding Off was published on Wednesday, February 10th, 2010.
• It was assigned to the Browsers, CSS, and Web categories.
• There have been thirty-seven replies.

I’m a bad conference organizer.

Why?  Because we opened the An Event Apart 2010 schedule for sales back in, um, flippin’ November, and I never mentioned it here.  Cripes, I never even posted when we announced the lineup of cities.  I could go through the great big long sob-story list of reasons why 2009 was really tough and blah blah blah, but when you get right down to it, I fell down on my job.

Okay.  So.  Time to correct that.

(deep breath)

Hey everyone, check it out: the complete tour schedule for An Event Apart 2010!  Woohoooo!

1. Seattle: April 5-7, 2010 (yes, three days; more on that anon)
2. Boston: May 24-25, 2010
3. Minneapolis: July 26-27, 2010
4. Washington, DC: September 16-17, 2010
5. San Diego: November 1-2, 2010

We’ve got a pretty killer lineup, if I do say so myself.  You can get the mostly-complete list from our opening-of-sales announcement last November.  It lists the people we had confirmed at the time; there have been a few additions since then.  Check out your city of choice to see who’s going to be there!  (But always remember that speaker lineups are subject to change: speakers are people too, and life has a way of interfering with schedules.  I myself had to withdraw from An Event Apart Boston last year due to a family emergency.)

The price to register for these two-day, one-track Events is the same as it was in 2009, and there are educational and group discounts available for those who are interested.

But wait, I just said “two-day” when the first show of the year is clearly three days.  What gives?

Seattle is the site of our first-ever A Day Apart, a full-day workshop that can be attended on its own or as part of a full three days of Event Apart ecstasy.  And the inaugural Day Apart will be nothing less than a detailed plunge into HTML 5 and CSS3 with Jeremy Keith and Dan Cederholm.  Jeremy handles the markup; Dan gets stylish.  It’s going to be fantastic.  I’m going to be in the back of the room for the whole day, soaking up as much as I can.

If you want to attend just the workshop, it’s $399 for the whole day if you buy an early bird ticket (available through March 5th).  The price goes up $50 when early bird ends, and another $100 if you show up at the door.  But I wouldn’t recommend that last, because I don’t think there will be any tickets available at the door.  Again: if you show up unannounced on the day of the workshop and ask to buy a ticket, we will most likely have to turn you away, because I expect that there won’t be any seats available.

On the other hand, maybe you’d like to experience more than just one day of AEA goodness.  Maybe you’d like to go whole hog and attend both the two-day Event Apart and the subsequent Day Apart, soaking up all the knowledge and enthusiasm and camaraderie that typifies An Event Apart.  And who could blame you?  If you do that, then the total early bird price for all three days is $1,190, whereas buying the event and workshop passes separately would total $1,294.  That’s right: you actually get slightly more than $100 off the cost of the workshop if you attend all three days, over and above the early bird discount.  (Or you can think of it as getting $100+ off the cost of the conference.  We’re not fussy.)

As it happens, these three-day passes have proved quite popular.  So if you want to get your hands on one of those — or on any Seattle tickets, whether one, two, or three days — I wouldn’t wait too long.  Our internal analyses suggest that there will come a time, some time before the doors open on April 5th, that the ability to buy a ticket will cease to be.  It may even pine for a fjord or two.

As for the four shows that come after Seattle, well, they’re looking pretty popular too.

I know I say this every year, but I’m really excited about what we’ve got planned for the year.  Jeffrey and I constantly and (we hope) consistently strive to create an event that we ourselves want to attend, and that’s absolutely true of the shows and workshop we have planned in 2010.  I can’t wait to hear what the speakers and attendees have to share.  Hope to see you there!

• Events and A Day, Belatedly was published on Monday, February 8th, 2010.
• It was assigned to the An Event Apart and Projects categories.
• There have been six replies.

I was recently honored to be asked to be a judge for the MIX 10k Smart Coding Challenge, running in conjunction with Microsoft’s MIX conference.  The idea is to create a really great web application that totals no more than 10KB in its unzipped state.

Why did I agree to participate?  As much as I’d like to say “fat sacks of cash“, that wasn’t it at all.  (Mostly due to the distinct lack of cash, sacked or otherwise.  Sad face.)  The contest’s entry requirements actually say it for me.  In excerpted form:

• The entry MUST use one or more of the following technologies: Silverlight, Gestalt or HTML5…
• The entry MUST function in 3 or more of the following browsers: Internet Explorer, Firefox, Safari, Opera, or Chrome…
• The entry MAY use any of the following additional technology components…
  • CSS
  • JavaScript
  • XAML/XML
  • Ruby
  • Python
  • Text, Zip and Image files (e.g. png, jpg or gif)

Dig that:  not only is the contest open to HTML 5 submissions, but it has to be cross-browser compatible.  Okay, technically it only has to be three-out-of-five compatible, but still, that’s a great contest requirement.  Also note that while IE is one of the five, it is not a required one of the five.

I imagine there will be a fair number of Silverlight and Gestalt entries, and I might look at them, but I’m really there — was really asked — because of the HTML 5 entries.  By which I mean the open web entries, since any HTML 5 entry is also going to use CSS, JavaScript, and so on.

The downside here is that the contest ends in just one week, at 3pm U.S. Pacific time on 29 January.  I know that time is tight, but if you’ve got a cool HTML 5-based application running around in your head, this just might be the time to let it out.

• MIX Judging was published on Friday, January 22nd, 2010.
• It was assigned to the (X)HTML, Browsers, HTML5, Standards, and Web categories.
• There have been five replies.

I am now a Fray Contributor.  Official, for real, badge and everything—check the sidebar on the home page.  My completely and in many ways unbelievably true story of beginnings around an ending, “A Death of Coincidence”, appears in Issue 3: Sex & Death.

This is a huge deal for me.  I still have a little trouble believing it.

For a long time—as in, for more than a decade—I’ve had “participate in Fray” as one of those little deferred dreams we all carry around in the background.  I certainly could’ve submitted pieces all along, either for the original site or one of the live events, and might even have been accepted.  The thing is, I wasn’t dreaming of simply getting a piece accepted and checking an internal to-do box.  I wanted to participate the right way, by my own internal reckoning.  That meant not only vying for inclusion, but doing so with a worthy story, one that felt right.

When Fray relaunched as a themed quarterly, I took notice.  I often work better when I have something to work against; constraints energize me more than they chafe.  The first issue‘s theme, “Busted!”, called to mind a few childhood incidents, but nothing really coalesced.  There was nothing that said, “I’m a Fray piece; write me.”  The second issue‘s theme, “Geek”, left me with far too many options.  I couldn’t hook onto anything with the right vibe.

Then issue 3‘s theme was announced, and I knew exactly what I was going to submit.  No rumination of possible narratives, no idle exploring my past for ideas, no doubt at all.  I knew, and it was right.

In fact, it was a piece I’d already written, except for the ending.  The ending I had used was certainly good enough, and was certainly the right ending for the time and place I wrote and performed it.  But there had always been a different, nearly unbelievable ending to that story and I’d always held it back, kept close to myself, never quite sure why.  Now I know why.  It was the piece that made that story a Fray story.

If you want to read it, you’ll need to pick up Issue 3 of Fray, which you can of course do very easily.  You can pick up issues 1 and 3 together for a great price, or become a subscriber and get issue 3 as your first.  Any of those would be awesome.  Or, I suppose, you can wait until the piece is published for free on the Fray site, though I should tell you that it could be a long while until that happens.

I can’t thank Frayer-in-Chief Derek Powazek enough for including me in Fray.  I am quite literally as proud as I was when my first book was published.  I’ve passed a personal and professional milestone, and far from just ticking off a checkbox on some internal to-do list, I’m basking in the glow of a dream fully and properly fulfilled.

• Into the Fray was published on Friday, November 27th, 2009.
• It was assigned to the Writing category.
• There have been five replies.

At some point, for some reason I cannot quite fathom, a WordPress or PHP or mySQL or some other upgrade took all of my WordPress database’s UTF-8 and translated it to (I believe) ISO-8859-1 and then dumped the result back right back into the database.  So “Emil Björklund” became “Emil Björklund”.  (If those looked the same to you, then I see “Börklund” for the second one, and you should tell me which browser and OS you’re using in the comments.)  This happened all throughout the WordPress database, including to commonly-used characters like ‘smart’ quotes, both single and double; em and en dashes; ellipses; and so on.  It also apparently happened in all the DB fields, so not only were posts and comments affected, but commenters’ names as well (for example).

And I’m pretty sure this isn’t just a case of the correct characters lurking in the DB and being downsampled on their way to me, as I have WordPress configured to use UTF-8, the site’s head contains a meta that declares UTF-8, and a peek at the HTTP response headers shows that I’m serving UTF-8.  Of course, I’m not really expert at this, so it’s possible that I’ve misunderstood or misinterpreted, well, just about anything.  To be honest, I find it deeply objectionable that this kind of stuff is still a problem here on the eve of 2010, and in general, enduring the effluvia of erroneous encoding makes my temples throb in a distinctly unhealthy fashion.

Anyway.  Moving on.

I found a search-and-replace plugin—ironically enough, one written by a person whose name contains a character that would currently be corrupted in my database—that lets me fix the errors I know about, one at a time.  But it’s a sure bet there are going to be tons of these things littered all over the place and I’m not likely to find them all, let alone be able to fix them all by hand, one find-and-replace at a time.

What I need is a WordPress plugin or something that will find the erroneous character strings in various fields and turn them back into good old UTF-8.  Failing that, I need a good table that shows the ISO-8859-1 equivalents of as many UTF-8 characters as possible, or else a way to generate that table for myself.  With that table in hand, I at least have a chance of writing a plugin to go through and undo the mess.  I might even have it monitor the DB to see if it happens again, and give me a big “Clean up!” button if it does.

So: anyone got some pointers they could share, information that might help, even code that might make the whole thing go away?

• Correcting Corrupted Characters was published on Thursday, November 19th, 2009.
• It was assigned to the Web and WordPress categories.
• There have been seventy-two replies.

It wasn’t what I would call unseasonably cold, but then the season was mid-autumn and the afternoon wind along the river did cut the skin a bit.  I kept my leather jacket zipped up all the way as I made my way back to the hotel with shopping bag in hand.  Brisk, I might have said back home, or even chilly.  Not winter yet, but you could feel it coming in the snap and shift of the air.

I crossed the last street before the hotel, keeping an eye on both the short-cycle light and the short-tempered traffic.  Not that there was any particular reason for them to be short-tempered—it was a Sunday afternoon and there were hardly any cars on the bridges and roads that grid the downtown area—but I knew from experience that pedestrian intimidation was something of a sport for the locals, and I really didn’t feel like tempting fate, or at least somebody’s ideas about what constituted a bit of fun.

Having threaded through the small bunch of oncoming pedestrians and reached the relative safety of the sidewalk, I came upon a large man with two children in tow, all bundled against the cold in parkas and scarves and hats.  He asked if I had a minute, and I immediately knew what was coming.  Sure enough, it came out: the request for a dollar, some change, anything I could spare.  I glanced at him, at the children, back at him.  Something for bus fare, he said.  They’d missed dinner at the Mission the night before, he said.  Just a little help, anything I could do, he said.

How many times had I heard this before?  I gave the usual excuses about not having any cash, I only travel with credit cards, so sorry, had to go.

And went, the wind biting into my cheeks as I strode to the hotel’s front door, the overhead heater blowing a curtain of warmth across the entryway.  Into the lobby.  Into the elevator.  Thirty floors into the air.  And in my sight, still, the children looking at me.  The boy of maybe eight, looking up at me curiously.  The girl of six, peeping at me warily from behind the man’s bulk.  Props?  Accomplices?

Did it matter?

I stood at the counter of the lobby gift shop, stacks of nutrition bars in my hands.  A bottle of water in the side pocket of the jacket I had yet to shed.  An apple in the other.  My credit card between two fingers, ready for the attendant to take.

Through the doors, into the cold wind under the canopy, the plastic shopping bag weighing down my hand.  I reached the sidewalk and there they were on the same corner, looking like they were getting ready to cross the street.  I caught the man’s eye, signaled him to wait.  As I approached his face shifted, softened, something like relief warring with shame melding into a curiously childlike expression.

“God bless you,” he said to me, and I chose to believe that he meant it.  The little boy smiled up at me, a tiny edge embedded in the corners of his mouth.  The girl still peeped warily, maybe even more so now.  The man and I were shaking hands, looking squarely at each other for a moment.  I told him to make sure to get the kids to that Mission dinner.  I could think of nothing else to say, because it was the only thing I was thinking.  Get the kids fed, keep them as healthy as possible, no matter what else.

As I turned into the recessed, canopied area that sheltered the hotel’s front door, I glanced back at the street corner.  The three of them were waiting to cross toward the small park to the north, the gift shop’s white bag ludicrously small in the big man’s hands, and then they were occluded by the building’s corner.  I walked back through the wall of warm air, into the dim lobby and out of the bright outdoors, thinking that there was every chance I’d been suckered, and knowing that it didn’t matter.

• To All Who Seek It was published on Thursday, November 12th, 2009.
• It was assigned to the Personal category.
• There have been no replies.