Now I’m seeing the Googlebot request /about/ pages relative to known blogs that don’t have any links to any /about/ URI. The last time the Googlebot flailed around like this it was fun to watch for a little bit and wonder what they had cooking in the labs, but then it got annoying. I don’t know if there are rules of bot etiquette, but requesting imagined unlinked resources while spidering can’t be a best practice.

There is of course one blog vendor who consistently has about pages at /about/ URIs, and that’s Typepad. Now my question Google is: what should the rest of us do if we want our about pages indexed by this new system? Mine happens to be in the about subdirectory of my blog, but what about people who have about.html or about-me.php? Should I set up a permanent redirect for every blog I have redirecting to the real about page?

(Note: That’s faux indignation. I don’t have any juicy conspiracy theories, and I’m not really that peeved, mostly I’m just curious what they’re up to. However juicy conspiracy theories are welcome in the comments. [As long as they don’t make fun of me for noticing these things.] )

UPDATE: It just requested a non-existent non-linked /contact/ URI.

UPDATE: It just requested a non-existent non-linked /stats/ URI.

DEVELOPING . . .

In Joining the Dark Side -OR- Is Mac IE 5 Support Worth $1,500, Scott responds to Tantek’s calling out of the new Feedster’s lack of support for Mac IE. Personally I’m sympathetic to Feedster’s case because I’ve had to spend hours talking to someone with a Mac trying to debug Mac IE issues with this site and wordpress.org and ended up having to change my favorite list menu technique from using floats to display: inline, which meant changing all the other menu styles to compensate. It was a pain.

I know that when I’m tweaking and checking things in different browsers, the number of my audience who uses that browser isn’t always the most important thing. In the previous case the only Mac IE I had heard anything from since both of the sites started was Tantek, and that was important enough to spend a couple hours of my time on. Imagine if you’re doing a job and the client’s boss uses Netscape 4, (god help you and) suddenly that browser becomes much more important in your testing, and you should triple your rate.

However, is this something the Web Standards Project should be interested in the same way we have been All Music or Odeon? I don’t speak for anyone but myself, but in my opinion it’s not the same at all. Feedster’s pages are a few trivial mistakes away from valid XHTML 1.1 and valid CSS, which is no easy task. (MIME issues aside.) Of course they should fix those mistakes, but it is a matter of a few minutes rather than 1-1.5 days. They aren’t writing to one browser or propietary technologies, they’re writing to modern standards and excluding browsers that have serious flaws in that area. Is that so different from the browser upgrade campaign?

From a user experience point of view, excluding Mac IE users might be a good idea as well. If Feedster allowed Mac IE users to visit and they saw a messed up layout (or no layout at all), as Tantek has suggested, then their perception of the Feedster brand, reliability, and image would be negative. I bet Keith would have some great thoughts on this. If they’re given a message that the site doesn’t support Mac IE, (honestly) they’ve probably seen this before and will just switch to another browser for that site. In my experience Mac users tend to be total browser flirts, and have every browser you’ve ever heard of installed. I would rather they open up my site in Safari or Firefox.

If Tantek was here I imagine he would counter that those browser options are really only valid for users on OS X, and that ignores hundreds of iMacs and such in libraries and such. Of course the question that a site owner needs to ask himself then is that in terms of costs and benefits, does that half of a single percent audience in libraries on older computers overlap with the audience you’re targetting with your site? If I was doing an ecommerce selling something like BMW accessories, I wouldn’t even give it a second thought. This isn’t about the many innovations that Mac IE introduced or its excellent standards support for its time, the issue is where Mac IE stands today.

On the bright side, Feedster has characterized this as a business cost/benefit decision and said if anyone sends them Mac IE CSS they’ll use it, which seems like a good concession. Of course I think Feedster should support Mac IE, and a day and a half to add support seems a little high, but if they choose not to I can understand.

I’m doing some code cleanup around here, and I came to a line in my <head> that is soley to work around an Internet Explorer feature I don’t want on my site.

Here is the standard way to remove it:

<meta http-equiv="imagetoolbar" content="no" />

Since the http-equiv attribute is meant to be simply a document-level replacement for real HTTP headers, and I have the ability to send out real HTTP headers, I decided to try out removing this line and replacing it with this bit of PHP, which according to the spec is functionally equivilent:

<?php header ('imagetoolbar: no'); ?>

Looks funky, but according to the HTTP 1.1 specification user agents should ignore headers they don’t recognize, so there’s no harm. However in my testing I was disappointed (though not terribly surprised) to find that Internet Explorer did not respect the header. I have trimmed other parts of my markup quite a bit though, and I’m willing to sacrifice this one line.