The eighth auction is running, and is called “Mac Software Bundle: Web Developer's Paradise.”

This is the most ‘focused’ auction to date. These are tools for web (site or app) developers, and include high-end apps like BBEdit for source editing, Coda and Sandvox for designing, SQLGrinder for databases, Interarchy for FTP, and Screen Mimic for screencasts. (I do this work for a living, and seriously wish I had all of these apps!) Also included Daylite and Billings, to help on the business side of being a web developer.

Yeah, ok, that last sentence sounded like a lame attempt at marketing, but it wasn't. I'm serious. I don't have Coda, Sandvox, SQLGrinder, or Screen Mimic, and could certainly use them. (So maybe it's not a good idea for me to sell a sweet bundle like this to my competition!)

Two last details: there's no reserve this time, and it's a seven day auction instead of five.

In Declining Your Friend Request, Apollo writes:

I’m on a large number of social networks. On some of them, people see my profile and add me out of the blue.

After receiving numerous such friend requests, particularly on new social networks, like Twitter and Pownce, I thought I’d put together a list [so you'll know why I declined your invitation].

I totally agree with Apollo. I'm only on a few social networks, but I receive a few too many requests "to be friends" from total strangers.

In fact, a few weeks ago one such request got me into some trouble. See if you can follow this: The potential "friend's" nickname sounded slightly familiar, so I followed the link to see who it was. The page was loading very slowly, and then Rich started talking to me in IM so I brought Adium to the front. One of his messages included a link, which (when clicked) opened in a new tab in Firefox. Time passed, and I forgot all about the page I'd been waiting for. Corinne sat down next to me, I showed her something, and then started shutting down the Mac for the night. As I closed my tabs in Firefox one-by-one (so I could be sure I wasn't leaving any unfinished work anywhere, as I've done many times), there was the link I'd followed from the "friend request": a page on Flickr with a model in all of her, uh... "natural beauty." NOT COOL.

Anyway, I don't care enough about the social networks to bother acknowledging most of the friend requests. I do feel the pressure to reciprocate with people I actually know, but mostly I just wish the networks would go away. How anti-social of me.

Daring Fireball (John Gruber) has been talking about email reply styles, lately, and now lots of other people are, too. (Including me!)

What I haven't yet seen mentioned is that "top posters" are notorious for only replying to one part — possibly even just one line or sentence — in a longer email. Many times over the years I have written a long-ish message to a client, explaining how I would do something (and for how much), only to receive back a copy of my entire message with a question at the top like, "How would that part work, exactly?" or "Could you send me a sketch of how you think that part would look?"

See, I've sent a message with twelve paragraphs explaining the overall flow of an application, and the question I get back could refer to almost any of it.

Even better (worse) is that my original message probably included a few questions which have gone completely unanswered.

That, to me, is the biggest benefit of the inline-reply style. You have to pay attention to what you're doing! You start your reply by quoting the entire message. As you go through the original message, you delete the stuff which needs no reply and which isn't needed for context, and then insert your own comments immediately after the relevant parts that remain. Since most email programs show different levels of quoting in different colors, it's very easy to follow the conversation.

Recently someone sent me a "breath of fresh air." It was another software developer, and we've been talking about me helping him out with the next version of his (only) application. Our conversation has stretched out over three months, but we're both sticklers for the inline-reply style so reading back through these email messages is just wonderful. Trying to have a conversation like this with a "top-poster" (someone who always quotes everything that came before, and only puts replies at the top) would be awkward, if not impossible.

Unfortunately, some email clients make inline-replying a little difficult. Gmail, MobileMail (Apple's Mail on the iPhone), and Outlook/Entourage are all good (bad) examples. They can all make very "pretty" email with bolds, colors, fonts, links and pictures, but those things are secondary (or tertiary) to good communication. At the opposite end of the spectrum are apps like Mailsmith, which *can't* create fancy-schmancy bold/colored/linked/imaged messages, but which provide tools to make inline-replying even easier than it is already. (There are other apps like that, but Mailsmith is the one I use. Claris Emailer was another great example of this type of app, back in its day.)

One of my clients has recently signed up for an online shopping cart system to work with his catalog (which is based on Conversant).

When a customer buys something through this shopping cart system, they're shown a confirmation page with a link back to a specific page on the vendor's site. That's totally standard.

The link appears to use JavaScript to submit a form which POSTs the sale's data (minus the truly private info like credit card number) back to a page on the vendor's site. Still pretty common (except their implementation doesn't actually work).

They claim that it only works in IE. Not in Firefox, not in Safari, not in Opera. Why worry about those, they're just a small percentage of the marketplace, right?

I'm sorry, but those people are morons.

Without even testing it, I can tell you that they're wrong: it doesn't work in ANY browser, not even IE. How do I know? The link just runs the script, and the script just causes the browser to navigate to the vendor's thankyou page: it never does anything with the form at all.

The form is all hidden fields, looking something like this:

<form action="url/of/thank-you/page" name="postData">
<input type="hidden" name="firstName" value="Seth" />
etc., etc., etc.

The form's action is pointing to the correct URL... but the form is never used. The script looks like this:

function submitForm()
{
	window.location.href="url/of/thank-you/page";
	return true;
}

If you understood the above, then you know how easy it would be to fix:

function submitForm()
{
	document.forms.postData.submit();
	return true;
}

Sigh. (Even easier: do away with the javascript entirely, and replace the link with an actual submit button.)

I've been doing event-based JavaScripting for approximately as long as there has been such a thing.

One of the foundations of this programming is that MSIE puts its event object at window.event, and most everybody else passes the event object to the listener (the method that is called when the event is triggered).

I moved past my frustration with that difference in behavior many years ago, so I could get some real work done. Know what I mean?

Turns out it's not true anyway.

Someone (can't say who) contacted me today in a fit of confusion. HIs events listeners in MSIE 6 were receiving events objects as parameters.

He was using Prototype to set up his listeners, so I assumed it had something to do with that. I looked into it...

First, I tried my own test, of course. Yep, there's the event object.

Second, I traced the code in Prototype. Function.bindAsEventListener() would explain it... except that's not what we were using in this case.

Nothing else in Prototype explained it, so I went out to the web to see what others had to say.

David Flanagan — The Man Himself, author of my favorite book on JavaScript — had this to say: back on October 23 of last year (just 3 1/2 months ago):

I don't know how I know this: it is just one of those things I've always known about IE. But a reader (Tom Stambaugh of zeetix.com) just emailed me with a trivially simple counter example. It turns out that if you use attachEvent() (at least in IE 6) then the event handler you specify is passed an event object as an argument.

I don't think I'm the only one who believed that handlers registered with attachEvent() don't get passed an event object. For example, the documentation on attachEvent() at about.com says:

Also unlike the standard DOM method, the event is not passed to the function as a parameter. Instead IE supplies a standard window.event object to hold the details relating to the latest event.

And the documentation for the YUI event library advertises, as a feature of the library, that:

The first parameter your callback receives when the event fires is always the actual event object. There is no need to look at window.event.

[SNIP]

Update: Thanks to the commenters who have pointed out the interesting fact that the event object passed to a handler is not the same object (not == to) window.event. I've written a trivial test that demonstrates that 1) an object is passed to a handler registered with attachEvent(), 2) that this object is not == to window.event, and that 3) the properties of this object are the same as the properties of window.event (except that they both have a property that refers to different empty arrays).

[SNIP]

Update 2: In comments, Alistair Potts presents test results that indicate that attachEvent has always passed a copy of the window.event object to event handlers. His test code is at: http://www.partyark.co.uk/html/ieeventtest.htm

(I seriously wonder if everybody else based their assumptions on David's own writing. I think the original version of his book was published by Gutenberg himself, and almost every serious JavaScripter has a copy of it.)

Long story, short: MSIE has (almost) always passed the event object to the listeners, as long as you registered the listener with attachEvent instead of just "assigning" the listener.