Ran across a fairly nasty bug in Yahoo’s spreadsheet viewer, the one that lets its users view excel and similar files. I had a file set up with a column of type time, in HH:MM:SS AM/PM format, and what it does with that is show them as 12 AM or 12 PM! I could not figure out why my co-hort (in organizing a seminar) was having such trouble confirming flight arrivals and departures until she showed me what she was doing.

So…if you’re using Yahoo to look at these files, be aware that it has at least this problem. Google’s spreadsheet viewer was fine, MS’s Excel was fine, and OOo’s spread sheet all were fine with this file. And Google and OOo are free (the former with a Google Account, that’s easy enough to sign up for).

So just passing along that warning. Also, sorry about the hiatus, it’s been absolutely crazy at work and then also with this seminar coming up. I should be picking up soon.

OK, I think I’ve got a cut for the next release of Lorelle’s requested plugin. However, I have not had a chance to test this outside of my own system (where it seems to work fine), and so I would love to have any volunteers help check this out on different installations for anything I’ve overlooked.

The basic mechanics are as follows: I coded up a new link “Reply To” for each post, which you all saw in the last cut. In that one the link goes to the post page’s comment reply section, which at least cut out the intervening pages. At one point I realized the Reply To doesn’t need to be added for comments not yet approved (!) so I cleaned that up (see example).

Anyway, now the Reply To link (see example) opens up a small box with a submit button under the comment using javascript (see example). I added code to the edit-comment.php that now handles a submit query. Each “Reply To” opens up its own box/submit button for the owner’s (see example). On submission, it refreshes, staying on this comment management page (see example). Sorry, no ajaxy goodness at this step, perhaps at the next step if I can figure out how to hook into something similar as to what the approve/unapprove links are doing.

There are a few annoying points left, which I’m not entirely sure how addressable they are. For example, once you approve a post, you’ll need to refresh the page to get its Reply To link, since that part of the code is not hooked into the ajax that WP is using to do this. Ideally I’d like to tap into that, I’ll have to poke around some more. I also have a feeling I should be utilizing the Nonce security model as well.

If you’d like to test this out, please comment! I’d feel better if it were tested out on a few more sites before I release it out in the wild…

Webcams are interesting beasties…

First of all, I found out, somewhat to my surprise, that the quality of a webcam can depend as much on the software used as on the camera itself. It turns out that Yahoo’s webcam is very choppy and slow, though it gets the job done. The webcam through the MSN protocol was much better. However, using Kopete’s MSN protocol let me to run into a bug where the incoming cam just freezes and lags — at one point, I realized I was seeing images 10 minutes old. I can only speculate the packets took a quick side trip to a sun-drenched beach somewhere first before coming back to our gray, drizzly area.

So, I tried out aMSN to see if it was true that the webcam performance was better over MSN. This package is strictly for the MSN protocol and is designed just for Linux. The interface to this looks a little rough around the edges, although it’s possible that it’s a font issue in my installation. Ubuntu has 0.95-2.1 in its repositories, but I don’t recommend installing that. aMSN has a later version (0.96) that’s demonstrably improved, and I found it here using a standalone installer (a tar.gz for more traditional compile/install is also offered) which intrigued me enough to try it out, and it installed without any problems.

And indeed, it proved quite responsive with both incoming / outgoing webcams, showing the picture with much less choppiness.

I think in conclusion I’d have to say that I really look forward to Gaim incorporating video capability (which is rumored for 3.0, but as I said, I’m not holding my breath since 2.0 just came out) because I like Gaim’s interface the best. Kopete seems to be actively working on its code, judging from all the email on its devel list, so I would expect the bug I found to be fixed quickly. At that point, I’d be happy to use Kopete, as I can see its interface growing on me. It’s just a pity it doesn’t have a windows version, as I like being able to use the same programs at home and at work. But, in the meantime, aMSN’s not bad at all and I won’t mind using it for the webcam until one of the multiprotocol apps work for me. I prefer to run as few programs as possible

But if what you need is a robust MSN connection, I’d definitely recommend aMSN.

As I noted earlier, while IE6 displayed this site (in Nearly-Sprung) correctly, IE7 did not.

The reason is this: the bug in IE6 and previous that allowed the following CSS hack to work

* html .anelement { layout fixes }

has been fixed in IE7. However, many of the layout issues that were fixed in the escaped code have NOT been fixed. In my case the particular culprits were these:

/* Essential Layout (IE Fix) */
* html #leftsidebar {
        left: 150px;              /* RC fullwidth */
}
 
/* Hides from IE5-mac \*/
* html li {height: 1%;}
/* End hide from IE5-mac */
 
/* Hides from IE5-mac \*/
* html #postnavigation {width: 145px; height: 2px;}
/* End hide from IE5-mac */
 

IE7, like IE6, needs the left: setting, but as it no longer works with the * html escape (for an explanation of why this is, see the excellent article here) it is not getting these settings as it should. The result on my site was the left sidebar’s utter disappearance.

The workaround is to isolate the IE hacks into a separate .css file and call it with an escape that all IE derivatives still honor. (Wonder how long this escape will last…) While tedious, this is overall a better solution than embedding hacks within a css file. Such hacks can be relegated to a separate file which can later be removed when IE is finally fixed (these glasses seem awfully pink, don’t they?).

So, in general this is the way to fix such problems. I checked my css files for any instances of

* html

Some of these might be in a “holly hack,” which should be moved along with the rest of the markup.

I created a new css file, iehacks.css is fine, and dumped all the hacks into this file. Now, I removed all instances of * html (this is the crucial part, otherwise no improvement is seen for IE7). In my case, this new file wound up containing the following:

#leftsidebar {
        left: 150px;              /* RC fullwidth */
}
 
/* holly hacks to fix peekabo bugs in IE */
 
/* Hides from IE5-mac \*/
li {
        height: 1%;
}
/* End hide from IE5-mac */
 
/* Hides from IE5-mac \*/
#postnavigation {
        width: 145px; height: 2px;
}
/* End hide from IE5-mac */

(Note the holly hacks in the last two rules.) Now, I needed to modify my <head> element to include this css file, which was easily done via adding

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="iehacks.css" />
<![endif]-->


In WordPress, this meant modifying my header.php file (of course I made a backup copy of it first) as follows:

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="<?php bloginfo('stylesheet_directory'); ?>/iehacks.css" />
<![endif]-->

I added this just before the call to wp_head. This would make a VERY simple plugin; I could create one if people wish. But this is pretty straightforward as is.

Update
Probably the best way to do this, allowing for testing in IE7 before proceeding completely, is to copy the suspect elements over to the new css file. Since IE7 doesn’t work with the current css file anyway, it doesn’t hurt to leave the elements in place while getting the iehacks file to work. Add the [if IE] call to the headers and check in IE6, IE7. Once everything looks okay, then remove the suspect elements from the original css file, one by one.

Roger Johansson (of 456 Berea Street) and Lorelle VanFossen both remind us that the new Internet Explorer has been released into the wild and what does that mean for all our web pages?

I want to point out that Internet Explorer really has three main versions right now. (I have to support multiple platforms, so this sort of thing is a large concern for me). IE7 is intended only for XP and Vista. Anyone who has not migrated to either of these platforms will use IE6. Since Win2K is pretty decent, and there’s a lot of people out there who haven’t bothered to shell out for the bigger badder etc computer, I expect that the web pages I work on will continue to have a substantial proportion of IE6 users. So the IE6 bugs remain a real and ongoing concertn.

In testing with IE7, we have noticed that there can be different behavior between IE7 on XP and IE7 on Vista! Now, some of this may be due to the different beta versions of Vista — I believe we’ve gone through at least two updates on Vista beta. However the possibility remains very high that IE7XP and IE7Vista will behave differently from each other as well.

So now that means three platforms to support in place of one!

In any case I’m aware that IE7 does not handle this website gracefully even though IE6 does, as you can see in this screen shot.