Nothing But Words

Deko Boko 1.1 - Compatible with IE 7 and the New WP-reCAPTCHA

Topic: WordPress and Web Programming
Tags: CSS, Deko Boko, WordPress, XHTML

A report of CSS trouble with IE7 in Deko Boko 1.0 has led me to release a fairly major upgrade - Deko Boko 1.1 is available for download at wordpress.org:

• I’ve completely rewritten the XHTML and the CSS for the contact form. If you’re upgrading, and you’ve customized your contact form, you’ll need to migrate your changes. The reason is that the widely used CSS “clearfix” code that I had in Deko Boko breaks in IE7 (I know, I’m late in catching this - I’ve switched to Ubuntu on my laptop and I wasn’t keeping up with the latest Microsoft nonsense). For reasons explained in my rant below, this pushed me to do a full rewrite, which simplifies both the markup and the CSS.
• One of the features of Deko Boko is that is it plays nicely with WP-reCAPTCHA (the official reCAPTCHA plugin for handling spam in comments). The latest version of WP-reCAPTCHA changed the name of the WordPress option variable where it stores its API key, so Deko Boko now looks for it under the new name and the old name.
• I added a language selector to the Deko Boko settings menu, so you can choose a language other than English for the reCAPTCHA widget.

<rant>The challenge with writing a plugin like this is keeping both the XHTML and the CSS at a level where you don’t need to be a coding guru to make changes yourself. I want the Deko Boko contact form to be customizable by people with beginner-to-intermediate level coding skills. But there are a multitude of variations in how CSS is implemented in different browsers, not to mention the things that are just plain broken. Nowhere is this problem worse than forms. So developers are often forced to choose between doing semantically “incorrect” things in their markup (like using br tags to force certain layout effects), or writing hundreds of lines of complicated CSS, often with filters to deal with incompatibilities between browsers.

Unfortunately the solution for the IE7 “clearfix” problem I mentioned above breaks clearfix for IE6 (requiring an IE6 filter to then fix that). IMHO clearfix is a hack to begin with, needed to deal with an oversight in the CSS model. And in any event, the code needed to fix the problem for definition lists was way too fragile for a plugin like this, which is meant to be flexible and extensible. So I dropped the definition list in favor of an ordered list, following the techniques described in Cameron Adam’s excellent article on form layout. His approach to form layout is the best I’ve seen, with some clever yet simple approaches to the markup (the right word is “elegant” - as it’s semantically correct too) to get around some of the most common problems with form layout. It’s also such a well written and highly detailed article, that I can simply refer you to it if you want to extend the layout of the Deko Boko contact form to suit your own needs .</rant>

CSS and the Limits of Definition Lists

Topic: WordPress and Web Programming
Tags: CSS, XHTML

I’ve become a fan of definition lists as a layout tool. Here’s a snippet of HTML, using them to markup a form. You can make the input element label the definition term (dt) and the input element itself the definition data (dd), like so:

<dl>
<dt><label for="first_name">First Name<label></dt>
<dd><input type="text" name="first_name" id="first_name" size="20" /></dd>
<dt><label for="last_name">Last Name<label></dt>
<dd><input type="text" name="last_name" id="last_name" size="20" /></dd>
etc...
</dl>

What makes this better than using an HTML table is that with CSS you can specify whatever layout you want: you can style it so the dt is above, below, to the right, or to the left of its dd partner. This is particularly helpful when you’re writing re-usable code that might be needed in situations where you can’t predict the layout needs.

But tonight I discovered the limit of this approach, which is when you can’t predict whether the vertical height of the dt’s content will exceed the height of the dd’s. I’ve been working on the next version of Shashin, and what’s been driving the effort is the Boxing Dragons art gallery site, which I just finished working on. I’m using Shashin to display a list of albums (in this case artists) with the description of the album alongside the cover image of the album. For the next release of Shashin, I was originally planning to do this markup with definition lists (with the album cover as the dt and the description as the dd), giving users the flexibility to layout their album and description pairs any way they want, via CSS.

This approach to styling definition lists is fairly tidy, and works fine when the height of the dd is the same or greater than the dt. And in Firefox it also works when the height of the dt is greater, but not so in IE6 (I’ve been resisting upgrading so I haven’t tested with IE7). In IE6 the content of a dd will “flow up” into any available space above it, pushing a dd’s content higher than the position of its dt partner.

The clearfix solution for positioning floating divs doesn’t help here (believe me, I tried). I found several threads of people discussing this problem (or something quite similar to it) but no reliable solutions. The best I found was this admirable effort, but it entails about 70 lines of CSS code as well as some goofy markup. It’s also quite fragile - as soon as I started tweaking things like margins even slightly, it would start to fall apart. Although I probably could have gotten the layout I wanted if I kept at it, the CSS would have been so complex it would have defeated the purpose: to make it fairly easy for Shashin users to alter the stylesheet to get the layout they want.

So, at least for now, I’ve given up on using a definition list and have retreated to using a table. The upside is the markup and the CSS are straightforward and cross-browser compatible. The downside for Shashin is that there’s no flexibility: the album covers have to stay on the left, and the descriptions on the right.

“Less Is More” Theme, with CSS Drop Down Menus

Topic: WordPress and Web Programming
Tags: CSS, Web Design

If you do a Google search for “CSS drop down menu”, you’ll find a number of examples that have been provided by well meaning folks. I wasted a lot of time with them. With only one exception, they were either:

1. Poorly modularized, in that if I included their stylesheet and javascript files, and then dropped their menu markup inside a div in my design, my page would explode into a million pieces, or
2. They relied on 100+ lines of javascript, which seems really unnecessary in the age of CSS (except for IE’s lack of CSS support for hovering with anything other than an anchor tag), or
3. If I scrolled through the submenu items, the hover color on the top menu item would disappear, resulting in a goofy menu display (that’s a problem most don’t know how to solve without javascript though, including me).

The one exception was the CSS Express Drop Down Menu, which was the seventh or eighth one I tried. It has only one small javascript function (to patch the IE hover problem), the xhtml and css aren’t unnecessarily complicated, and the css is very well documented. It even includes special handling for the notorious IE5 for Mac. After dropping in the code, I just had to spend about 20 minutes tweaking the css for fonts, colors, and padding to fit my design, and now I’m good to go. If you’re looking for a good CSS drop down menu, this is the one to use!