themorgue.org

The last few articles here have dealt with using CSS to create custom buttons with hover and click effects. While in a perfect world, the CSS versions would be enough, but in a world with MSIE, they fall a little short. Some versions of MSIE only allow active and hover effects on <a> tags, but what if you want to create a custom button using some other type of tag? For that case, you’ll have to resort to using Javascript.

There are many different Javascript libraries to make cross-browser differences fade away, but I have been leaning towards using MooTools. So my example here will be shown using MooTools, but I would imagine most of the other Javascript libraries would work as well.

The first thing we need to do is change our CSS code to use class names rather than the :active and :hover pseudo-classes. The new CSS code is shown below with the old selectors commented out for reference.

/* Old Selectors: #nav a:hover, #nav a:hover span */
#nav .btn-hover, #nav .btn-hover span {
    color: #2A5E5E;
    background-position: left -22px;
}

/* Old Selector: #nav a:hover */
#nav .btn-hover {
    background-position: right -22px;
}

/* Old Selectors: #nav a:active, #nav a:active span */
#nav .btn-click, #nav .btn-click span {
    color: #74A074;
    background-position: left -44px;
}

/* Old Selector: #nav a:active */
#nav .btn-click {
    background-position: right -44px;
}

Just so you don’t have to go back and look, our original HTML code was as follows.

<div id="nav">
<a href="#"><span>OK</span></a>
<a href="#"><span>Cancel</span></a>
</div>

In order for these new selectors to work, we have to apply the btn-hover and btn-click classes at the appropriate times. The events we are going to use are mouseover/mouseout for the hover effects, and mousedown/mouseup for the click effects. MooTools makes it insanely easy to add events to multiple elements using the $$ function in combination with the addEvents method. The code to do this is shown below.

window.addEvent('domready', function() {
    $$('#nav > *').addEvents({
        'mouseover': function(e) { this.addClass('btn-hover') },
        'mouseout': function(e) { this.removeClass('btn-hover') },
        'mousedown': function(e) { this.addClass('btn-click') },
        'mouseup': function(e) { this.removeClass('btn-click') }
    })
})

You’ll, of course, have to include the MooTools Core and More scripts from the MooTools web site. As you can see from the code above, the btn-hover class is added and removed by the mouseover and mouseout events, respectively. And the btn-click class is added and removed by the mousedown and mouseup events, respectively. The $$ function is selecting all immediate children of the element with ID of “nav”. In this case, that would be the <a> elements. With all of this in place, all of the button effects should work in all browsers now even if you use elements other than <a>.

The last article I posted here showed how to add hover effects to CSS-styled buttons. It is possible to use a similar technique to add onclick effects with CSS. This technique works well in Safari and Firefox, but not quite so reliably in Internet Explorer so you may want to combine this technique with the onclick support of Javascript libraries like MooTools.

The first thing to do is add another image to our button sprite. We’re going to add a green version of the button to display when the button is clicked. Here is our button sprite with all three variants.

To create the onclick effects, we are going to use the CSS :active pseudo class. The CSS code itself is almost identical to the CSS code used in the hover effects.

#dialog a:active, #dialog a:active span {
    color: #74A074;
    background-position: left -44px;
}
#dialog a:active {
    background-position: right -44px;
}

The only difference between this CSS code and the hover CSS code is that the :active pseudo class is now being using instead of :hover, and the background position has been shifted up by another 22px to display our third button image (we also changed the text color of the button to coordinate). Now when you click on the button, you’ll see the following effect.

As mentioned earlier, you have to be a bit more cautious with this trick because MSIE doesn’t work so well, but using Javascript and onclick events you can set the background position programatically to get the same result.

The last article I posted showed how to use a single button image to create variable width buttons with custom backgrounds. That’s all well and good, but what about hover effects? You can change the look of your buttons, including the background image very easily.

The first thing we need is an image that contains both the default and hover versions of the button. Put the default image on top and the hover image below it as shown here.

Now all we do is add new rules for the hover action. All the new rules have to do is change the background-position so that rather than getting the default button image, we reposition the background image so that we see the hover background image. To do this, we simply bump the background image up by the height of the button (22px in this case). We also added a text color change just for kicks. Here are the CSS additions for the hover effects.

#dialog a:hover, #dialog a:hover span {
    color: #2A5E5E;
    background-position: left -22px;
}
#dialog a:hover {
    background-position: right -22px;
}

With these rules in place, hovering over a button gives the following effect.

A lot of times when people create buttons on web pages, they want them to have nice gradients in the background and rounded corners and such. The trouble is that in order to create nice looking buttons like that, you either have to make the button contain the text itself, or you have to chop up the image into pieces and use the sliding door technique. The problem with putting the text in the image is that it is much more difficult to do translations. The sliding doors technique is annoying because you have to chop your images up. However, there is a third way which is much easier and will work in most cases.

The third technique is a lot like the sliding doors technique, but doesn’t require you to chop the image up. All that it requires is an image that looks like the button you want to create and is wider than any content that you may want to put into it. We’ll use the button shown below.

We are going to create a typical dialog style button bar with an OK button and a Cancel button. The HTML for this is shown below.

<div id="dialog">
<a href="/"><span>OK</span></a>
<a href="/"><span>Cancel</span></a>
</div>

Each button in this code consists of both an <a> tag and a <span> tag. The names of the tag aren’t important, but you do need to have two of them: one to render the left side of the button and the other to render the right side of the button. In our example, we are going to use the <span> tag to render the left side and the <a> tag to render the right side. Let’s start with the left side first.

The CSS code below will put our button image behind the <span> tag as well as set the height of the element to the same height as the background image and set the appropriate font size.

#dialog a span {
    background: transparent url('button.png') no-repeat scroll left 0;
    display: -moz-inline-box;
    display: inline-block;
    height: 22px;            /* Same as height of background image */
    font: 16px/22px "Lucida Grande", Arial;
}

We used the inline-block display type so that we could set the height of the button properly. Since Firefox 2 doesn’t support the inline-block type, we had to use -moz-inline-box as well. With these rules applied to our HTML, we get the following representation.

The text is crammed onto the left side, so add the following padding rule to the above CSS code to give us some room on the left side.

padding: 0 0 0 15px;

Our buttons should now look like the following.

We’re almost there, we just need to get the right hand side of the buttons rendered. Of course, that’s where the trick comes in. We are going to add 15px of margin to the right of each <span> tag (using margin: 0 15px 0 0). This will allow 15px of the <a> element to show through. We then use the same background image that we used for the <span> element except that we align it to the right side of the element. Here is the CSS rule for the <a> tag.

#dialog a {
    background: transparent url('button.png') no-repeat scroll right 0;
    display: -moz-inline-box;
    display: inline-block;
    height: 22px;
    font: 16px/22px "Lucida Grande", Arial;
}

We now have nice looking buttons using just a single image and CSS!

Since most of the rules for the <span> and <a> tag are the same, we can combine those rules and just override the differences in a second rule. We’ll also add a couple of attributes to set the color of the text and turn off any link underlining.

#dialog a, #dialog a span {
    background: transparent url('button.png') no-repeat scroll left 0;
    margin: 0 15px 0 0;       /* 15px == amount of background image to the right */
    padding: 0 0 0 15px;      /* 15px == amount of background image to the left */
    display: -moz-inline-box; /* Firefox 2 support for inline-block */
    display: inline-block;    /* Must be used so that height can be set */
    height: 22px;             /* Same as height of background image */
    font: 16px/22px "Lucida Grande", Arial; /* Appropriate font size / line height */
    color: black;
    text-decoration: none;
}
#dialog a {
    background-position: right 0;
    margin: 0;
    padding: 0;
}

Here is the final result.

Not only can you use this technique for buttons, but you can also use it to style tabs the same way. While this isn’t a perfect solution since it requires a fixed height font to be used in the button, it is a simpler way of handling styled buttons since you don’t have to worry about slicing and dicing your button backgrounds.

I was at a FedExKinkos in Norman, OK today just browsing around and came across the greeting card section of the store. One card caught my eye that had George Bush’s face on it. The card said something about Bush’s last day in office (which is in 2009) and that on your birthday you should party like it’s 2009. OK, not a really big deal, people have been taking shots at Bush for years. As I continued browsing, I noticed an anti-Cheney card. Again, not a real surprise. Further browsing did turn up some slightly more surprising cards.

The next one I came across was a Hillary Clinton card. With the words “President Hillary Clinton” across the top. The inside said something along the lines of: see there are things scarier than getting old. This one did stray a bit off the usual anti-Bush fodder, but she was once a first lady, so I guess it still makes sense. Believe it or not John McCain was next. This one did strike me as a bit more odd than the others; however, this is an election year so I guess you’re bound to see cards poking fun at all of the candidates… Not quite.

The final group of cards were the Barack Obama cards. I figured that they would again take some shots at the prospective presidential candidate. That’s where I was wrong, way wrong. These cards portrayed Obama as some sort of superstar, sex symbol. Not a single negative or even neutral point was made about him. You could have replaced his pictures on the cards with pictures of Marilyn Monroe and left all of the prose in place! Needless to say, I was flabbergasted! It’s basically like the greeting card company is campaigning for Obama through their cards (and FedExKinkos is indirectly doing the same by carrying the whole collection). I guess it’s their company and they can do what they want, I’m just taken aback by how blatantly biased they are. Oh well, I guess you can just chalk it up to more free publicity for Obama.

The current SVN version of Django has a new way of creating forms for adding and editing objects in a database. The most recent released version, 0.96, had two functions to create objects that generated forms for you: form_for_model and form_for_instance. The form_for_model function would take a Model class and generate an input form for it. The form_for_instance function would take a Model class instance and do the same, but would also fill in the values specified in the database. These were pretty handy, but it was inconvenient to have two functions that did basically the same thing. So the Django team added ModelForms.

ModelForms combine the features of the two previously mentioned functions into a single ModelForm class. Let’s say that we have a Student model in our Django application and we want to create a form for it in our view. We would create a subclass of ModelForm as follows.

from django.newforms import ModelForm

class StudentForm(ModelForm):
    class Meta:
        model = Student

If you were to create an instance of StudentForm in a view method and run the as_table method, you would get an HTML form that contained all of the fields in the model. A sample view method is shown below that creates a new user if there isn’t posted data, or saves the student information if there was posted data.

def studentEditor(request):
    # Save the newly created student using posted data
    if request.method == 'POST':
        form = StudentForm(request.POST)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect('/students/')

    # Create a new Student with no data
    else:
        form = StudentForm()

    return render_to_response('studentEditor.html', {'form':form})

This is great, and does basically the same thing as the old form_for_model function, but it still leaves the editing portion to be done. Before ModelForms came out, you had to use the form_for_instance function to convert an existing instance to a form instance, then render the HTML form to edit the data. Now it is much easier. You simply add an ‘instance’ keyword option to the ModelForm constructor that speficies the instance to read the initial data from. Below is the same view as above with a new argument that is the primary key of a student in the database. This primary key is used to get a student instance to pass to the StudentForm constructor.

def studentEditor(request, id=None):
    instance = None
    if id is not None:
        instance = Student.objects.get(id=id)

    # Save the created or edited student using posted data
    if request.method == 'POST':
        form = StudentForm(request.POST, instance=instance)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect('/students/')

    # Create/edit a Student with database values
    else:
        form = StudentForm(instance=instance)

    return render_to_response('studentEditor.html', {'form':form})

This is pretty nice, but there is still a redundancy in creating the StudentForm instance. You have to do it in two different places for the create and edit cases. However, with a couple of little Python tricks using ‘and’ and ‘or’, you can simplify the above code to this:

def studentEditor(request, id=None):
    form = StudentForm(request.POST or None,
                       instance=id and Student.objects.get(id=id))

    # Save new/edited student
    if request.method == 'POST' and form.is_valid():
        form.save()
        return HttpResponseRedirect('/students/')

    return render_to_response('studentEditor.html', {'form':form})

Now that’s an idiom that would make a mother proud.

There is an epidemic of bad design in this world that is more than just annoying, it’s dangerous. I’m not just talking about bad aesthetic quality of devices, obviously. I’m mean that their behaviors are badly designed as well. I think Steve Jobs nails it when he talks about design.

Design is not just what it looks like and feels like. Design is how it works.

So how could this possible lead to “danger?” I’m glad you asked. I’ve been dealing with safety devices in the home lately. Safety has taken on a new meaning to me since I moved to Tornado Alley last year. The weather in this area pretty much mandates that you have a weather alert radio to notify your of impending danger (especially at night). The other badly designed device I’ve dealt with recently is a smoke alarm. Let’s start with the smoke alarm since most people are familiar with them.

There is a smoke alarm installed in my kitchen that was there when I moved in. It works well. Too well. Any hint of smoke in the air from cooking sets it off. What happens when it starts going off for that reason? I get annoyed and remove the battery. This isn’t necessarily dangerous while I’m cooking, but I have to remember to put it back in when I’m done. That doesn’t always happen. To try to remedy this situation, I bought a new smoke alarm made for kitchens that has a “hush” button. This is a button that you press when you get “false alarms” due to cooking. Great idea! Except that it was badly designed.

I was cooking today and created a pretty good amount of smoke (no, I’m not a bad cook, some things just create smoke when you cook them). The new smoke alarm went off, and rightfully so. I pressed the hush button, and it stopped! YEAH!! Then it started to annoy me. Every minute or so, the smoke alarm let out a small chirp (basically like the chirp most smoke alarms let out when the battery is low). After a few chirps, this annoyed me enough to take the battery out. So I’m right back where I started!

If fire isn’t bad enough, weather in Tornado Alley can be even more dangerous. I purchased a weather alert radio to alert us (mainly at night) about severe weather. The first one I purchased in a very simple model and pretty well designed. It has three lights on it to indicate different levels of alert and a screen that displays what type of alert it is. It can be plugged in or can run on batteries. So what’s wrong with it? It’s too dang loud! It has the option to alert you in three different ways: light up the display, voice alert, or siren. Obviously, the light won’t do much at night; it’s not that bright. The siren is absolutely obnoxious and is loud enough to induce a heart attack in the middle of the night, so voice alert was my choice. The problem is that “voice alert” only means “partial voice alert.” Before the voice alert comes, you get about five seconds of the horrendous siren first. I’m a light enough sleeper that the voice is plenty to wake me up. I think the danger of having a heart attack by having the siren go off in the middle of the night is a bigger danger than facing whatever it is that the radio is alerting me to. Here comes weather radio number 2.

The new weather radio was much more technologically advanced. It has base station and a hand-held portion. I liked this feature because it made it handy to take into the storm shelter during an alert. Both the base station and the hand-held portion have a clock on them. Since the hand-held radio is battery operated, it isn’t affected by power outages. However, the base station doesn’t have battery backup, so when the power goes out, the time goes back to 12:00. This wouldn’t be such a big deal if it just took the word of the hand-held portion (which still has the correct time since it’s running on batteries), but the opposite occurs. The hand-held radio takes the bad time from the base station so that they are both wrong! Now I should explain that the base station is supposed to sync with the atomic click in Colorado, so it should always have the right time. But that is only true if it can actually connect to the atomic clock which brings up another design flaw.

The sensor for the atomic clock must be placed outside so that it has a clear shot at Colorado. There are conditions though. It can’t be in direct sunlight, it can’t be subject to direct moisture, it can’t solid objects between it and the atomic clock in Colorado. So it must be installed under something that gives it protection from sun and rain, but that would block the signal to the atomic clock. I give up…

I’ll definitely be sticking with the second weather radio because it has a much more sane alert than the first radio (although it does automatically turn itself to maximum volume when an alert occurs), but it is far from perfect. I haven’t even gone into the other issues that I have with it. The point is that each one of these devices annoys me enough that I consider not using them at all, which puts me in the path of danger whether it is fire, severe thunderstorms, or tornados just because of bad design. While bad aesthetics probably will never cause any real danger except to my sense of taste, design of safety devices that cause you to quit using them is dangerous.

Growing up in Michigan, the only real choice of ginger ale was Vernor’s. As I would find out later in life, this wasn’t such a bad thing. After moving to North Carolina for graduate school, I discovered that not everyone knew what Vernor’s (or ginger ale in general) was all about. The grocery stores there usually only stocked Seagram’s, Schweppes, Canada Dry, and some store brands. I had never had anything but Vernor’s growing up, so I assumed that they probably all tasted about the same. I couldn’t have been more wrong. All of the other brands that I tried tasted like Sprite with the slightest hint of ginger. This is totally unlike Vernor’s which has a strong ginger flavor and a lot of bite to it. There is even a “You know you might be from Michigan” joke that goes “You know you might be from Michigan if you can drink Vernor’s without coughing.”

I did finally find Vernor’s in North Carolina, but it was very expensive (probably twice what it cost in Michigan). My parent’s would also bring some with them whenever they made a visit to see me, which made it a little expensive as well since Michigan has a 10 cent deposit on all pop cans and bottles. I did come across some other ginger ales in the Whole Foods store in Raleigh by Reed’s. While Reed’s is better than the weak stuff you get in regular grocery stores, it goes a bit overboard. The herbs and spices are too strong for my taste.

I found inexpensive Vernor’s again while living in Colorado, but alas, I was only there for a few months. Now that I’m in Oklahoma, it’s difficult to find again. However, when I discovered Pops on Route 66, I was introduced to a much better selection of ginger ales than I had ever seen before. In my first visit, I selected Dr. Tima’s Honey Ginger Ale as my first ginger ale experiment.

I didn’t hold a lot of hope for Dr. Tima’s Honey Ginger Ale due to my previous experiences with other ginger ales, but I didn’t hold that opinion for long. Dr. Tima’s Ginger Ale not only has honey in it, but that is the only sweetener in it. There are no refined sugars or corn syrups. The first taste was very pleasant. It didn’t have quite the bite that Vernor’s does, but it had a great ginger flavor. The honey introduced a warmness to offset the tang of the ginger. Overall, it’s a great ginger ale and I enjoyed every sip more than the previous one. I’ll have to sample a few more bottles of it (and the other 20 or so brands of ginger ale at Pops) to see how the taste wears on me, but at the moment, it reigns my top choice of ginger ales.

I know that nobody thinks there is any reason to go to Oklahoma, and for the most part, you’d be right. Yeah, there is a wicked cool museum of banjos in Guthrie and there is even a canal area of Oklahoma City a lot like the one in San Antonio, but nothing I knew about prepared me for what I came across this weekend. I didn’t even know it, but there are more miles of Route 66 in Oklahoma than any other state. We decided to do a bit of touring around and see what there was to see. For the most part, Route 66 is just a highway like any other, but there are some interesting sites along the way. We went to the Rock Cafe and the round barn, but those were nothing (as far as I’m concerned) compared to a newer attraction: Pops.

The construction of Pops started in 2006. It is a store like nothing I’ve ever seen before. We actually drove by it a couple of times not even realizing what it was, but decided to go back and take a closer look. Boy am I glad we did. Pops is a Route 66 attraction that is basically a gas station and restaurant, but the real feature is pop (that’s coke for the Southerners). They have nearly 500 kinds pops and bottled waters. They don’t stock everything all the time, so you have to come back more than one time to see them all. The entire front of the building is covered in glass and has glass shelves lined with thousands of bottles of pop, just for decoration. Every bottle in the store is glass. If you aren’t a pop connoisseur, this is the only way that pop should be enjoyed. For me, this was a dream come true. They had pops there that I have wanted to try for years, and lots that I had never even heard of. They even had more than one kind of strawberry rhubarb pop! If you are looking for a reason to come to Oklahoma, this is it. But you’ll probably want to stop by and see the banjos too…

I’ve been working on a MooTools class for the past couple of days that makes large data tables scrollable. When the page loads, it checks to see if any data tables are larger than the scrollable area of the window. If there are tables like this, it puts the table into a scrolling div and copies the header and footer areas above and below the scrolling div, respectively. It also has the options of making the rows alternate colors and making the table rows sort when the headers or footers are clicked. I had it working quite well, but there were some performance issues.

The table I was testing with had 429 rows of 16 columns. This is a total of 6864 cells. I was taking advantage of MooTools’ getElementBySelector in many places because I needed to find th and td cells within the tbody, thead, and tfoot elements separately. This created some problems when the page unloaded. On Firefox, it was taking over 7 seconds just to leave the page. This obviously was unacceptable.

I was having trouble figuring out what the exact problem was. I’m having done a lot of Javascript debugging, and have done even less performance profiling. Luckily, the Firebug plugin to Firefox was a huge help. In fact, I don’t know how I would have figured out the problem if I hadn’t had it. I turned on profiling then refreshed my page. Firebug told me that the ‘remove’ method of the MooTools Array object was taking up all of the time. I wasn’t using the remove method, so I figured there must be some sort of garbage collecting going on in MooTools. After posting to the MooTools forum, I got the answer. Apparently, whenever you use any of the MooTools that returns a DOM node, it extends those nodes with the special MooTools methods. This means that if you use $, $$, getElementsByClassName, or getElementsBySelector, every node that is returned is extended by MooTools and must be garbage collected.

In my table, I had thousands of cells that I was accessing to implement various features. Every one of those cells was being extended and had to be garbage collected. By the time my script was finished, I had over 7,000 objects to be garbage collected when the page unloaded (as seen in the Garbage.elements object under the DOM tab in Firebug).

While the getElementsBySelector method is very handy, it wasn’t going to work for me because of the extreme number of cells in my table. I ended up rewriting much of my code to use the standard getElementsByTagName method to get around the issue. This made the code quite a bit uglier, but I guess most optimizations do. The lesson today is to be careful when using methods that extend nodes in MooTools. While MooTools is really nice, there can be too much of a good thing. I’ve heard that MooTools 1.2 does memory management in a very different way, so hopefully the severity of this type of situation will be reduced in the future.