Posts from November 2009

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.

In the course of a recent debugging session, I discovered a limitation of web inspectors (Firebug, Dragonfly, Safari’s Web Inspector, et al.) that I hadn’t quite grasped before: they don’t show pseudo-elements and they’re not so great with pseudo-classes.  There’s one semi-exception to this rule, which is Internet Explorer 8’s built-in Developer Tool.  It shows pseudo-elements just fine.

Here’s an example of what I’m talking about:

p::after {content: " -\2761-"; font-size: smaller;}

Drop that style into any document that has paragraphs.  Load it up in your favorite development browser.  Now inspect a paragraph.  You will not see the generated content in the DOM view, and you won’t see the pseudo-element rule in the Styles tab (except in IE, where you get the latter, though not the former).

The problem isn’t that I used an escaped Unicode reference; take that out and you’ll still see the same results, as on the test page I threw together.  It isn’t the double-colon syntax, either, which all modern browsers handle just fine; and anyway, I can take it back to a single colon and still see the same results.  ::first-letter, ::first-line, ::before, and ::after are all basically invisible in most inspectors.

This can be a problem when developing, especially in cases such as having a forgotten, runaway generated-content clearfix making hash of the layout.  No matter how many times you inspect the elements that are behaving strangely, you aren’t going to see anything in the inspector that tells you why the weirdness is happening.

The same is largely true for dynamic pseudo-classes.  If you style all five link states, only two will show up in most inspectors—either :link or :visited, depending on whether you’ve visited the link’s target; and :focus.  (You can sometimes also get :hover in Dragonfly, though I’ve not been able to do so reliably.  IE8’s Developer Tool always shows a:link even when the link is visited, and doesn’t appear to show any other link states.  …yes, this is getting complicated.)

The more static pseudo-classes, like :first-child, do show up pretty well across the board (except in IE, which doesn’t support all the advanced static pseudo-classes; e.g., :last-child).

I can appreciate that inspectors face an interesting challenge here.  Pseudo-elements are just that, and aren’t part of the actual structure.  And yet Internet Explorer’s Developer Tool manages to find those rules and display them without any fuss, even if it doesn’t show generated content in its DOM view.  Some inspectors do better than others with dynamic pseudo-classes, but the fact remains that you basically can’t see some of them even though they will potentially apply to the inspected link at some point.

I’d be very interested to know what inspector teams encountered in trying to solve this problem, or if they’ve never tried.  I’d be especially interested to know why IE shows pseudo-elements when the others don’t—is it made simple by their rendering engine’s internals, or did someone on the Developer Tool team go to the extra effort of special-casing those rules?

For me, however, the overriding question is this: what will it take for the various inspectors to behave more like IE’s does, and show pseudo-element and pseudo-class rules that are associated with the element currently being inspected?  And as a bonus, to get them to show in the DOM view where the pseudo-elements actually live, so to speak?

(Addendum: when I talk about IE and the Developer Tool in this post, I mean the tool built into IE8.  I did not test the Developer Toolbar that was available for IE6 and IE7.  Thanks to Jeff L for pointing out the need to be clear about that.)

• Pseudo-Phantoms was published on Tuesday, November 3rd, 2009.
• It was assigned to the Browsers, CSS, DOM, Tools, and Web categories.
• There have been nineteen replies.