A few months ago I posted a tip on how to Minimise file size with the YUI Compressor TextMate Bundle. The idea is to get minifying of CSS and JavaScript files into your workflow even if your server or CMS isn’t setup to do it automatically for you.

It works well, but I recently ran into a YUI Compressor bug that had me scratching my head for quite some time. Some of my media queries simply weren’t working. I checked the Media Queries specification, read various tutorials and examples from around the Web, and despite my syntax being correct some things just wouldn’t work.

Incredibly frustrating, but I found out what the problem was and how to fix it.
Read full post
Posted in CSS, Coding.

I’m starting to get into WordPress child themes. I have a lot of themes are they are all based on one theme. Until now, I have been using Subversion to merge the changes across themes. But this is getting to be painful.

When I make a change in one theme I have to integrate all the rest and it just doesn’t happen when I’m busy. After a while some themes get totally left out and then it turns into this big production to bring them up to date. The base theme often contains plugin dependencies and so the themes that haven’t been updated can’t use my latest plugins.

Using child themes will help me so much. All I have to do is a Subversion update on the base theme when I make changes to the core functionality, which is often all I do. It will also help my organization not to have so many files that are different on purpose.

I know it sounds obvious, but you really have to have a need for child themes to become worthwhile, and now I have that need.

When you have a key-value list what HTML tags should you use? I’ve been thinking a lot about this and I’ll say it flat out: the answer is tables. Here are some of the common tags used to contain key-value pair lists and why using tables is better.

Tags That Don’t Work Very Well

Dictionary Lists

You could use a dictionary list like so:

<dl>
<dt>Color</dt>
<dd>Red</dd>
<dt>Shape</dt>
<dd>Square</dd>
</dl>

Semantically, this kind of works out. It has key and value tags, dt and dd. But the problem comes with formatting. What if you want to put a border around a key value pair? Well, you can’t. One solution is to wrap each key-value pair in its own dl tag, but that seems like a lot of work and then you lose out on the whole list wrapper, so you have to wrap the whole thing in a div or something depending on your formatting requirements.

This is not to say that dictionary lists are bad, they are perfect for things that closely resemble actual dictionary lists, but they are not a very good general key-value pair container because of limited formatting options.

Unordered Lists

Unordered lists are very flexible and can wisely be used for all kinds of lists. The other day I saw them used as a container for key-value pairs like this:

<ul>
<li>Color <span class="Value">Red</span></li>
<li>Shape <span class="Value">Square</span></li>
</ul>

In many cases this will work fine. It has the benefit over a dictionary list that both the key and value are contained within one element. It has the downside that the Value span has to be formatted to undo any formatting you’ve given the li (the key). This could be altered by adding a Key span, but at that point you may as well just use a bunch of divs. This doesn’t give you very good CSS free presentation and completely loses the semantics of the data. The point of HTML is that if there’s no style things still end up looking fairly decent and that at the very least, the HTML can accurately represent the data relationships.

The Winner

Tables

We’ve been so conditioned against tables and rightly so. People have abused tables in the past to format their pages to the point where you can’t tell what’s going on. But remember the rule, “Tables should be used for tabular data.” A list of key-value pairs is an excellent example of tabular data, but I think people don’t think to use tables at first because the tabular data in this case only has two columns. People start to think of tables for things with three or more columns. Here’s the markup.

<table>
<tr>
<th>Color</th>
<td>Red</td>
</tr>
<tr>
<th>Shape</th>
<td>Square</td>
</tr>
</table>

This fixes all the problems. Each key value pair is enclosed in a tr element. The key is enclosed in a th and the value is enclosed in a td. The default formatting is going to be perfect.

Furthermore, tables offer so much more extensibility. If you need a header row, break out the thead and tbody elements. If you need a summary row at the bottom, add another tbody element. It’s ultimately extendable with no classes.

Of course, that doesn’t mean it’s the solution for everything. If what you have is a dictionary list, then of course the dictionary list tags are going to work better. But for general key-value pairs, and the ways we generally think of formatting key-value pairs this is way better.

It might be time to get back in touch with tables if you’ve stopped thinking about them. Once you drop the idea of tables being used for page formatting and adopt the idea of using them just for small blocks of data you can really start to see how great they are.

The CSS for tables is a little more complex, so take some time to start understanding that. I’ll give you a hint, though. Do yourself a favor and use the border-collapse property. It takes a lot of the fuss and mess out of formatting tables:

table
{
border-collapse: collapse;
}

Difficult Situations

I just thought I should mention here that I have run into one situation that isn’t covered very well by any existing HTML elements and in its nature is just difficult. This is the case where you have individual key-value pairs that you want “arranged” in an some custom manner. For instance you want the key on top with a border on the bottom and the value beneath that. Then you want those elements to be lined up horizontally:

Color Shape
-------- --------
Red Square

Using more radical CSS dictionary lists can be made to perform this way although it’s probably better handled by turning the table suggestion above on its side and using a table with two rows, a header row and a data row depending on how you want it formatted.

<table>
<thead>
<tr>
<th>Color</th>
<th>Shape</th>
</tr>
</thead>
<tbody>
<tr>
<td>Red</td>
<td>Square</td>
</tr>
</tbody>
</table>

That’s more HTML than absolutely necessary, the thead and tbody can be left out, but it still feel like a lot of HTML for something semantically simple. But at this point it’s going to take either a lot of HTML (tables) or a lot of CSS (dictionary lists) to make this particular scenario work. If you want it to work without CSS, you really have no choice but tables.

The issue with this concept is that it doesn’t allow for very long values or very many key-value pairs horizontally and the whole scenario is only appropriate when you know in advance the range and quantity of values to expect.

A pretty neat plugin for TextMate (and a few other text editors) that I have started using is Zen Coding. I’d heard of it before but didn’t “get it” until I read Jonathan Christopher’s blog post The Art of zen-coding: Bringing Snippets to a New Level.

Jonathan explains very well what you can do with Zen Coding, so I’m not going to get into much detail. One example though. Zen Coding lets you use syntax that looks very much like CSS selectors to write HTML, which can look like this:

div#news.module>div.header+div.body>ul>li#item-$*5

When you put the cursor at the end of that line and execute the Zen Coding command, the result will be the following HTML snippet:

<div id="news" class="module">
<div class="header"></div>
<div class="body">
<ul>
<li id="item-1"></li>
<li id="item-2"></li>
<li id="item-3"></li>
<li id="item-4"></li>
<li id="item-5"></li>
</ul>
</div>
</div>

This is just one quick example of what Zen Coding can do. Try it out for yourself.
Posted in Coding, Productivity.