wheresrhys

Yesterday and today I’ve been rewriting my jQuery crossSelect plugin (probably over half of the code has changed) to; a) Fix the serious bugs brought about by trying to bring my plugin closer in line with how it’s supposed to be done, without fully understanding the implications in advance; b) make the code more efficient, in part applying the ideas in this excellent article; and c) prepare the code for bringing in more functionality in later releases.

With regard to c), the main thing I needed to do was rewrite all my selection and removal functions so that moving many items into the selected column at once could just be the move one item function iterated a number of times. I’ve now ( I think) found a pretty efficient solution (each move many function is only 3 lines long), but along the way I came across an interesting dilemma.

My selectOne() function essentially moved a list item and then checks how many items are in each list before adjusting the buttons appropriately. Now, to do a selectAll() or a selectMany() the obvious thing to do is just to iterate that selectOne() function over all list items – just a handful of lines of code – … but this unfortunately leads to a less efficient (and probably slower) function. Writing a selectAll()/selectMany() function from scratch would enable me to only adjust the buttons once and, in the selectAll() case, not have to care about tracking which list item I’m dealing with as they all get moved over in the end… but this way would not only be less elegant, I feel, but also lead to more lines of code.

I’d always assumed that optimising code meant two things – faster and smaller – and I’d always thought that one more or less implies the other. Turns out I was wrong.

In the end, the escape from this trade off involved removing the button adjustment from selectOne() and putting it in selectNow(), a new function triggered by a click. But this required a feature of jQuery which I’ll talk about in some other post.

The other day I neglected to mention how I had resolved the list/table dilemma on the site I’d been working on.

As I explained, the content fitted the semantics of a table more than that of a list, but Internet Explorer’s bugs in applying positioning to <tr> tags (up to and including ie8) prevented me from using a table to implement the design.

Or did it.

In the end I had two choices of mark-up for each item in the list:

<ul>
  <li><h3><a title="Blue Reef Resort" href="duikhotel/Egypte/
... marsa_alam/Blue_Reef_Resort">Blue Reef Resort</a>
</h3>
     <ul>
        <li>All inclusive</li>
        <li>8, 15 dagen</li>
        <li>Marsa Alam</li>
        ...
     </ul>
  </li>
</ul>

or

<tr>
  <th colspan="3" scope="row">
    <a title="Blue Reef Resort" href="duikhotel/Egypte/
... marsa_alam/Blue_Reef_Resort">Blue Reef Resort</a>
  </th>
  <td class="rating">
     <img alt="4 stars" src="/img/star4.png"/>
  </td>
</tr>
<tr>
  <td>All Inclusive</td>
  <td>8, 15 dagen</td>
  <td class="location">Marsa Alam</td>
  <td class="price">vanaf €399</td>
</tr>

The second example, combined with appropriate column headings, I figured gave the closest approximation to the real table structure of the content. And the presence of a <th> every other row does suggest that rows are to be taken in pairs (though I’m not sure this is any help to screen reader users).

The above means, I think, that I am closer to web design zen. I have rejected the false grail of table based design, and only now that I have mastered CSS and semantic structure can I claim to understand the table and start to mold it to my enlightened purposes.