Building a Better Blocklist
A technique popping up all over the Web recently is what I’ve dubbed the ‘blocklist’. By blocklist, I mean a list of links tiled vertically and including a fair chunk of content. To give you an idea, Veerle Pieters has kindly agreed to let me use the Approved section of her blog as an example.
I haven’t included all of the code needed for the finished technique below, as it does get quite complicated. However, you can view the demonstration of the technique and take a look at the annotated source code there. Whilst it is quite detailed, I do recommend reading through the explanation below rather than jumping straight to the demo; it’ll help you get your head around what’s going on if you run into problems or want to make changes later.
The Current Approach
Take a look at Veerle’s implementation: interact with it—hover and click on the items in the list. Works well doesn’t it? The increased clickable area adds some meat to what would otherwise be a linked heading with a separate description below it, not to mention the benefits it has in terms of accessibility for those with poor motor skills.
Let’s take a look at the code:
<h2>Approved</h2>
<ul>
<li><a href="#">
FF Meta Serif<br>
<em>A gorgeous, all-purpose typeface.</em><br>
<span> December 11 at 09.47 am</span>
</a></li>
</ul>Currently, the only way to make the entire block clickable is to enclose every component of the link—the title, description and entry date—in a single a element.
As a is inline, it cannot contain block-level elements, meaning that the title can’t be made a heading and the paragraphs can’t be marked up as such. To style the blocklist in any detail, each of the three components needs its own element. With her choices limited, Veerle has opted to contain the description in an em element and the date in a span, with br tags to drop down each onto its own line.
Veerle certainly isn’t the only one to take this approach. I hope Elliot Jay Stocks won’t mind me using the Recent Reads section in his sidebar as another example. Indeed, on every site I’ve found that includes a similar list, the authors have had to resort to using strong, em, span, small or even q tags to mark up the contents of their links.
What’s the Problem?
Marking up the list in this way raises some issues. Does the description really need to be emphasised in comparison to the rest of the link’s content? Is there any relationship implied between the item’s heading and its description? What about the date?
Secondly, styling the list has been made more difficult by the inline nature of the elements. Line breaks have had to be used to slice up what would otherwise have been a continuous line of text with CSS disabled (without the benefits of display: block;).
Thirdly, using an element like em just to contain the description prevents its use for text that actually needs to be emphasised. The same goes for links. What if you want an extra link within the description? You can’t have a link within a link.
A Fresh Look at Things
When developing this site, I planned to implement a list of Quicklinks—external items of interest on the Web, essentially the same as Veerle’s Approved section. I figured there must be a better way to construct a list with large clickable areas so got testing.
To start with, I laid out how I wanted the markup to look:
<h2>Quicklinks</h2>
<ul>
<li>
<h3><a href="#">Quicklink Title</a><h3>
<p>A short description of the link</p>
<p>January 1st</p>
</li>
</ul>The trick of the technique is that only the headings are linked. The a elements are then made block-level (display: block;) and stretched over the elements below them like a transparent sheet, making everything clickable.
I should point out that any text covered by the stretched a will not be selectable. If that poses a serious problem for you then this technique might not be what you’re looking for.
For the link to lie on top of the content that follows it without shifting everything down, it must be removed from the document flow (positioned absolutely) and given a higher z-index.
The largest hurdle to overcome is to allow for a varying amount of content or an increase in text size. It would be easy to give every link element a fixed height and leave it there, but that would a) not cover all of the content or b) limit the amount of text that can be included per link. To combat the problem, the list itself must be positioned relatively and each a element given a height of 100%. This makes every link stretch to the height of the entire list. Elements that appear further down in a page’s source naturally have a higher z-index, so each link conveniently overlays its predecessor, chopping the clickable area to the distance between its origin (the top of the title being linked) and the point where the next link begins (the top of the next title).
As a finishing touch, overlay: hidden; can be applied to the list. Making every link a height of 100% causes them to overhang where the list should end by the height of the boxes that precede them, making the list almost 200% its original height. Setting the list’s overlay property to hidden chops all of this overhang and returns the list to its proper height. (If you can’t quite get your head around all that, don’t worry. Grab the code from the demo page and remove overflow: hidden; to see what I mean).
One feature of the technique I’m not completely happy with is that a predetermined height must be allotted for the link’s title, as it has been removed from the document flow. To do this, padding of something like 3em must be added to the top of the element that immediately follows the title. This is done by applying a class to the list item if its title is likely to drop down onto two or more lines and style the element that follows it accordingly:
.longtitle h3 + p {padding-top: 5em;}
.verylongtitle h3 + p {padding-top: 7em;}
etc...If you can think of a better way to overcome this, please have a play with the code and post your findings in the comments!
So, there we have it. The basic structure behind the technique is wrapped up. All that’s left to do now is to make it look nice.
Tips on Styling your Blocklist
- Use the sibling selector to target an element that always follows another (e.g. the second paragraph in every list item:
p + p {color: red;}or, as we have used, the ‘description paragraph’ in each link:h3 + p {padding-top: 3em;}. Those sibling selectors are powerful things, yet sadly underused due to poor browser support (I’m looking your way Microsoft). - The way to style a link when it is hovered over is to apply the
:hoverpseudo-class to the list item, not theaitself. For example,li:hover {background-color: green;}. If you apply the:hoverto thea, you won’t be able to change its background for fear of masking everything below and your styling won’t affect the rest of the link’s contents. - If you are going to include additional links within the elements that are covered by the
a(one of the benefits of this technique), style them to look like normal text as they will not be clickable. Any users reading your content with CSS disabled or in a feed reader will still benefit from their inclusion but I have not found a way for them to remain clickable through the link that blankets them. Once again, any thoughts on a solution to this would be greatly appreciated in the comments. - Have fun with it! The technique gives you a lot more flexibility compared to the old method and leaves you with nice clean markup to style however you like.
The Good, the Bad and the IE
So, a roundup of the pros and cons of this technique:
| Pros | Cons | |
|---|---|---|
| Old Method | Large clickable area in IE6 | Hard to style |
| Forces use of line breaks | ||
| Uses elements improperly that could be used correctly | ||
| New Method | Clean, semantic markup | Approximate height of title must be known |
| Does not restrict proper use of inline elements | Other than title, text not selectable | |
| No superfluous markup | Small clickable area in IE6 | |
| Can contain additional links |
As you can see, it is by no means perfect but does have some major advantages over the traditional method. Your blocklist won’t work quite as well in IE6. Have no fear though, straight out of the box (using the code given in the demonstration) the blocklist should display fine, only with the clickable areas reduced back to the size of the titles.
One benefit of using so many sibling selectors to style the blocklist is that IE6 ignores much of the stuff it would usually choke on. Of course, results may vary if you customise the code to suit your needs, but a line or two of IE-specific CSS should be enough to solve any problem. As is, IE7 gets it pretty much spot on.
That’s it! Once again, a big thankyou to Veerle for letting me use her site as an example. Make sure you check out the demonstration to see the technique in action. It includes two blocklists: one in the style of my Quicklinks and the other, Veerle’s Approved section using the new technique for comparison. However, please keep in mind that any CSS given beyond the basic structure is for demonstration only and not to be copied blindly. I hope the styles I have included give you enough of a starting point to produce your own.
If you have an opinion on the technique, good or bad, any feedback in the comments would be greatly appreciated.
Dave (1 year, 5 months ago)
Michael
Luke
Salim Bensiali
Sam Rayner