A new feature is on its way to the List Central interface. Soon List Central users will be able to associate a date, and time with any list item in any list, and request List Central to email him/her either once, annually, monthly, weekly or daily on that date and time.

I love the date picker Javascript script I found to help accomplish this new feature. It is the MooTools DatePicker by MonkeyPhysics. The script is flexible and well documented. There are even 4 different skins ready made to use in your application. Thank you MonkeyPhysics for building this date picker script!

Lets say you have a textarea in which you will only be saving the first 300 characters the user puts in there. You likely have a database field of type varchar(300), and a small space to fit the user input into that makes a long text input not feasible. You could let the user type in whatever s/he wants, and then be disappointed to find that only the first bit of their epic novel was saved. Likely your users will call your site buggy and find some other website to play with, because your lazy handling of their input did not have their needs in mind. The user must be informed that their input will be truncate at 300 characters.

To handle this situation you need a multi-line text input, that enforces a 300 character limit. If the user types more than 300 characters, the extra characters shouldn’t show up so that s/he knows that only what they can see displayed will be saved. For the multi-line requirement, you have to use a textarea, but textarea’s do not have a built in max-length directive like the one line text inputs do. So, we have to make out own. I went looking for a solution today, and found a rather handsome, one liner solution over at psacake. Sadly though this solution is serverly flawed, to a degree in which I would say it’s unusable. The psacake solution stops the user from inputting more than 300 characters, but it also prevents the user from using the backspace to change their input. I have updated psacake’s solution to give the user a chance to chance to edit what they have written after they discover the textarea has a character limit imposed upon it.

function imposeMaxLength(event, object, MaxLen){
    var key = event.keyCode ? event.keyCode : event.which;
    if(key == 8){
        // 8 is the keycode for the backspace key
        return true;
    }else{
        return (object.value.length <= MaxLen);
    }
}

Then, call they function like this:

<textarea onkeypress='return imposeMaxLength(event, this, 300);'></textarea>

Please feel free to use this code on your site. It has passed my tests on both Firefox and IE8.

and STAY down from LOLcats

Every web designer has tackled the problem of keeping that footer at the bottom of the page, no matter the amount of content above it. At first look one might assume this is a simple task, but as it turns out, you can really drive yourself batty trying to make this seemingly simple task to happen.

A while back I settled on a not so perfect solution that used min-height’s to get the job done. This was alright, but it was problematic in that you never know how your user will have his or her browser sized. I continued on with the development of the site, but never felt quite right about leaving the footer that way. Today I decided to look for a better option once again, and I sure am glad I did! I happened upon Ryan Fait’s Make the Footer Stick to the Bottom of the Page solution!

The solution is so simply beautiful that it makes me wonder how it took so gosh darn long to figure out! There is really only one extra div in the html, and only 15 lines of css! Wait a second, did I just say “gosh darn”? Right well, never mind that.  Head over Ryan Fait’s site for all sorts of design resources, including the Sticky Css Footer I love so much!

I use Google Apps to manage the few email addresses I have for the listcentral.me domain. Google Apps is amazing! Very easy to use, and super powerful. For today’s small business, there is no better service for managing email, doc shares, and online calendars, specially considering the price!

Unfortunately, I have encountered a problem with using Google Apps. Fortunately there is also a solution to my problem!

The Problem

I have a few, on demand, features on List Central that sends emails to the users, for instance, there is an “Email this list” feature. This requires that I send emails with the from address as lists@listcentral.me from my webserver to the varied email addresses of my future users. Because Google knows all about my domain listcentral.me, if any email I send from my webserver arrives at a google managed email address, google knows that the email didn’t come from it’s system, and it assumes that it must be dealing with a spammer, or other such scam.  This is not good for business, as I cannot have the emails sent from the List Central system being marked as spam!

The Solution

It is possible to route the emails sent from the List Central system through the Google Apps SMTP (Simple Mail Transfer Protocol) system, which has the same effect as actually sending the email through the Google Mail interface. A copy is even saved in the Sent folder!

Using the instructions detailed by Robert Maldon, I was able to get my emails sending through Google’s SMTP server, and passing though the spam checks without too much hassle!

There was one sticking point! For those on Debian, one of the perl packages that you much install, Net::SMTP::SSL, is available in a Debian package only for lenny. I opted to upgrade from etch for this!

The Implementation

I added a little bit to Maldon’s solution to include the multipart/alternative option in order to send both plain text and html versions of the email and allow the email viewer to choose which to display. The code is as follows:

   my $fromEmail = 'lists@listcentral.me';
   my $emailPassword = 'emailpassword';
   my $toEmail = 'someone@somewhere.com';

   my $text = 'Some email message without fancy formatting!';
   my $html = '<b>Some email message with fancy html formatting!!</b>';

   my $smtp;
   if (not $smtp = Net::SMTP::SSL->new('smtp.gmail.com',
                                        Port => 465,
                                        Debug => 1)) {
      die "Could not connect to mail servern";
   }

   $smtp->auth($fromEmail, $emailPassword) || die "Authentication failed!n";

   $smtp->mail($fromEmail . "n");
   my @recepients = split(/,/, $toEmail);
   foreach my $recp (@recepients) {
       $smtp->to($recp . "n");
   }

   $smtp->data();
   $smtp->datasend("From: " . $fromEmail . "n");
   $smtp->datasend("To: " . $toEmail . "n");
   $smtp->datasend("Subject: " . $subject . "n");
   $smtp->datasend("MIME-Version: 1.0n");
   $smtp->datasend("Content-Type: multipart/alternative; boundary="$boundary"n");
   $smtp->datasend("n--$boundaryn");
   $smtp->datasend("Content-Type: text/plain; charset=iso-8859-1n");
   $smtp->datasend("Content-Transfer-Encoding: quoted-printablen");
   $smtp->datasend($text . "nn");
   $smtp->datasend("n--$boundaryn");
   $smtp->datasend("Content-Type: text/html; charset=iso-8859-1n");
   $smtp->datasend("Content-Transfer-Encoding: quoted-printablen");
   $smtp->datasend($html . "n");
   $smtp->dataend();
   $smtp->quit;

In my figuring this out, I nearly fell into a couple of traps. Here’s the lessons learned:

• Google Email only allows SSL Authentication. There is no way around it.
• This means a Debian upgrade to Lenny if you want to use the pre-built Debian package libnet-smtp-ssl-perl
• You do not have to upgrade to Google Apps Enterprise to make this happen. There is some Google documentation about Email Routing that can lead you to think you might need to upgrade for this feature, but this is a completely different feature!

I seem to been obsessed with round corners, with all of the posts I have written on the topic (I had no idea!), so I thought I’d do some research into the future of round corners on these great inter-tubes and share my findings with you.

Currently the Mozilla based web browsers, Firefox being the most popular, supports the css directive -moz-border-radius, which effectively gives web elements round corners without using and nested divs or images. It really works quite beautifully, but it only exists in the Mozilla based browsers. IE, and others don’t know what to do with the directive, and just toss it out.

The Mozilla border-radius directive can be broken down to specify each corner to have it’s own roundness:

The CSS3 web standard has specified that browsers that meet the standards will implement this same functionality with the CSS3 directive border-radius. CSS3 is still a work in progress, and it will be an even longer wait for all of the browsers to catch up with the standards it sets. Us web developers do have some good things to look forward to though!

If you are interested in learning more about CSS3, Six Revisions has an awesome LIST of Useful Resources for CSS3.

Gotta love lists!