With the help of John Oxton I was able to figure out how to get the flash content to stay behind my floating html content. Essentially it took two steps:

1. Add a wmode parameter to the embed code, as well as a wmode attribute to the embed element, both set to transparent. The Perl code I used to do this is:

$EmbedCode ~= s/<embed/<param name="wmode" value="transparent" /></param><embed wmode="transparent" /;

2. Set the z-indexs in the CSS, giving my floating HTML content a higher z-index than the div containing the flash content.

2 easy steps, and voila! Everything is layered just how I intended. Beautiful!

Random Posts

• Why: A Funny Google Suggest
• That Rounded Rectangle Looks Like Crap!
• On embracing my inner girl

When I was implementing the dragable popup form feature I was pleased at how easy it was to use mooTool’s Drag.Move. My little form was easily moved to anywhere in the browser window, just as I intended. A problem arose when I tried to use the form inside the dragable element. The input elements of the form were not clickable, I could not get them to have focus, as if they were behind an invisible layer, which is actually what was going on. The form elements inside the dragable div they sitting in were not clickable, because they were dragable! Ack!

Happily I was able to find a solution for my problem: the dragable element required a handle.

The above image shows the Drag.Move handle in the upper right corner of the edit list item form div. You cannot move that dragable element unless you grab it by the handle, the move icon. Using a handle frees up the rest of the element for other clickable elements, like a form.

The JavaScript for including a handle in your Drag.Move element is as follows:

new Drag.Move('dragableDivID', {handle: 'dragHandleID'});

and the HTML, with some CSS:

<style>
.dragHandle{
    background:transparent url(/images/move.png) no-repeat scroll 0 0;
    cursor:move;
    float:right;
    height:30px;
    margin:15px 15px 0 0;
    width:30px;
}
</style>
<div class='dragableBox' id='dragableDivID'>
     <div class='dragHandle' id='dragHandleID'></div>
     <div class='dragableInner'> The content goes here</div>
</div>

In looking for this solution I found this great tutorial series by Consider:open called 30 Days of mooTools.  The entire series is very well done. Web developers at any level are likely to learn something new about mooTools there. Check out thethe tutorial on Drag.Move from the series that helped me out.

You might also like...

• Maintaining Dynamic Height on a Fx.Slide element with Mootools

I spent a great deal of time trying out different WYSIWYG editors for List Central. I found many neat ones, but CKEditor was the one that gave me the fewest headaches in integrating the editor into the highly dynamic interface of List Central.  CKEditor is a full featured editor that offers a wealth of features that are not needed on List Central, which makes the editor a little heavier than I would like, but it’s a fair trade off for an editor that works properly.

One thing that I didn’t like about CKEditor is the hideous dialog popup for adding links. It is aesthetically ugly, and offers far too many options. While I certainly wouldn’t be taking away the ability to add links in editor, I couldn’t keep the functionality the way it is, I’m far to picky to let something that looks like this:

to get passed me. Call me shallow if you will, but I had to make my own CKEditor plugin for adding links that would use the KISS (Keep It Simple Stupid) design principle and have the List Central asthetic.

CKEditor is still a young piece of open source software, and lacks proper documentation. Be careful with this, as CKEditor is the next version of FCKEditor, which is very different. Following the FCKEditor documentation is likely to lead you astray. I used the following resources around the web to figure out how to make my plugin work:

• Tommed explains how to make a CKEditor plugin by building a better image uploader
• Ajithmanmu explains how to create a CKEditor plugin by building a simple add link plugin.

Happy plugin making!

Random Posts

• Divs with Round Corners
• Kiva.org and my first Wordpress Plugin!
• A little GM math

I recently started using FX.Slide in the next iteration of the List Central interface. It lets the user open and close “sliders” (div’s with content in them) as they want them. Check out the < a href="http://demos.mootools.net/Fx.Slide">mooTools demo to see FX.Slide in action.

I had one little problem with Fx.Slide though. The problem was that I wanted to be able to dynamically add content to an Fx.Slide, changing the height of the slider div after it has been opened. To my dismay, the implementation of Fx.Slide set the height of the div to specific numbers in pixel to achieve the vertical slider effect. This means that any content I added to the bottom of the div after it was opened would not be shown. In order for the height of the slider div to remain dynamic, I needed the height to be set to “auto”, not a specific number.

I had to figure out a way to maintain the the div’s ability to change in height while still using FX.Slide. I did some fiddling in mooTools source to try to achieve the effect I desired. I changed where FX.Slide set the height of the div to “auto”. After trying it out, I was astonished that it worked! I had moved on to some other development when I realized that my change to the mooTools source brock the fluid motion of my slider. It now opened all choppy and jumpy. It was no longer pleasing to the eye. I had to put the source back the way I found it. I may have learned some about the inner workings of mooTools though the process, but really, messing with the framework’s source is a path to trouble.

As with many problems, this one’s solution didn’t come to me until I put the problem away for a while, and worked on other things. The solution then came to me, and like many other solutions, it seemed so simple, once I knew it.

The trick to maintain dynamic height on a Fx.Slide is to add an onComplete function on to the slider that sets the height of the slider to “auto” if the slider is open, like this:

var formSlide = new Fx.Slide('FormSlider', {
        onComplete: function(){
            if(this.wrapper.getStyle('height') != "0px"){
                // Check if the slider is open
                this.wrapper.setStyle('height', 'auto');
            }
        }
    }).hide();

That’s it! It works like a charm now, just as I want it to. So much trouble, for such a simple solution!

I expect that this solution would work the same on the width for horizontal FX.Slide’s, though I haven’t tested it.

You might also like...

• Put a handle on mooTools Drag.Move

Random Posts

• Tuesday Round Up
• Send email from Perl routed through Google Apps SMTP
• Recommended viewing – The Story of Stuff

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!

You might also like...

• charCode is meaningless

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.

Random Posts

• Put a handle on mooTools Drag.Move
• Will CPAN and Debian ever play nice?
• The Surprising Science of Motivation by Dan Pink

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!

Random Posts

• Could whole grains be the problem?
• How Perl Became My #1
• A Brief History of Perl

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!

You might also like...

• A Brief History of Perl
• Companies that Use Perl
• How Perl Became My #1

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!

You might also like...

• Images with Round Corners
• Divs with Round Corners