<!-- CSS Articles

Styling Links: Part 2 - Block Links

In Part 1 of Styling Links, I went over several common methods of styling inline links in a way that would allow you to derive and create your own styles, which suit your own designs. When styling block-level elements, it's even more important to notice the methods and the way in which desired structures and effects are achieved, since the range of what you can do when styling block-level elements is much wider.

Block-Level Links

Block-level elements, unlike inline elements, 'break' the flow of content somewhat in that they create a new vertical buffer for themselves. If you were to place a P element somewhere along your page, it would isolate itself, vertically, from the preceding and following elements, and take up as much horizotal space as it can within its Containing Block. This is because the default width property value for block-level elements is 100%, and they do not allow other elements to float around them, by default.

Often, however, these are all good things when you're structuring your layout, and styling these block-level elements when they're contained within A elements, as links, can be very beneficial.

The Cautionary Tale of Browser Compatibility

When using CSS to apply pseudo link classes, which is how we get block-level elements to react to mouse-overs, we encase other block-level elements with A elements and specify rules for them. This is simple enough, for all but a single browser version that is still being used by a large percentage of internet users today: Internet Explorer 6 (IE6). At this point, I should clarify two points: First, by this I don't mean that styling block-level elements "doesn't work" in IE6, it simply doesn't support all of the reactions properly (I'll elaborate in a moment). Even in the more complex scenarios, IE6 will not make anything on the page unaccessible, or 'break', it will, at worst, leave the links unstyled, they'd just look the way they would if you didn't apply the pleudo link classes. What this means is, that the page will 'fall back' without your needing to insert any script conditions for alternate CSS styles, the page will adapt on its own to IE6 and what it is capable of displaying. Second, the number users of IE6 is, thankfully, diminishing, as Internet Explorer 7, with much better standards support of CSS properties, selectors, and their respective implementations, is being downloaded by more users. Internet Explorer 7 renders everything documented in this article just fine, even if some of the 'style interpretations' are different (but everything is within the standard's specification).
I'm not going to get into the browser wars or start taking sides in this particular document, but it is a fact, not an opinion, that the latest versions of both Firefox and Opera are more standards compliant, which means that they both have no problem rendering everything I'll go over in this article, and, in fact, a lot more complex structures.

So what exactly does IE6 do differently? Well, let's say we place a P element within an A element. We've set the A element's display property to block, and we've set a pseudo link class rule to the P element (we'll get into how you do this in practice in a moment). We also placed some text in the paragraph.

A modern browser will consider the entire area of the P element to be a mouse-over trigger, shaped like a rectangle:

How much wood could a
woodchuck chuck if a
woodchuck could chuck wood?

This is a very good thing, as this will mean that A) Anywhere on the rectangle the cursor touches will trigger a hover event and B) Clicking anywhere on the rectangle will activate the link. On the other hand, IE6 will see the same implementation like this:

How much wood could a
woodchuck chuck if a
woodchuck could chuck wood?

This means that to trigger the hover event, the user has to move the cursor over the text itself, rather than just the P element's area, and has to click, once again, the text itself, to trigget the link, rather than just the P's area. To be clear, this will not be seen when the HTML is displayed. This will only effect the areas to which IE6 will react to the mouse cursor.
Is there a way around this? In a manner of speaking. The 'way' around it is to code gradually, while watching what IE6 accepts and to map its behaviour. I've been coding Web Standards for long enough that I could write another article on "how to please IE6", but I will not waste your time. The course of action that is recommended by any web designer/developer today is clear: Develop for modern browsers. If you were to restrict yourself to IE6 in this instance, you'd be seriously restricting your options, where, in this case, it's simply unnecessary: IE6 will still display the results correctly, the 'bug' is relatively minor, and will not hinder IE6 users. In the meantime, users of modern browsers will be presented with a modern website.
Don't get me wrong, this is not an umbrella rule, I wouldn't suggest that you start using the most recent standards W3C releases when the first browser starts showing signs of adoption. In this particular case, however, you would simply be denying users of modern browsers (any modern browser -- the user doesn't have to switch their browser, just to upgrade their version, and this is only with Internet Explorer) too much if you were to opt against styling block links. Naturally, the final decision is up to you, but you will find, if you browse around many high-visibility websites, that they've already made this decision.

Finally, some code...

The example I'll start with is a column paragraph styling. Often, you'll see "periodical columns", where the links are accompanied by a description that takes up a small paragraph, and the designer decides where the link to that page on the site should be placed within that paragraph. It could be the title, and often is, but you're really looking at the entire thing when you're viewing it. I use the term "periodical column" because this is a common scenario, where there's a column containing often-updated links somewhere on the page, but this can really apply to any block-level element.

I'll start with the HTML/XHTML:


You can already see here that the A elements wrap around block-level elements, which means that they will have to be made block-level elements themselves, in order for this to be valid. Here's the initial CSS:


The selector strategy is clear: The periodical ID is styled first, and then descendants are selected in turn and styled. The A element is given the display property value of block, since it contains block-level elements within it. The P and H6 elements are both child elements of the A element, instead of the H6 being within the P element, this was done to make the border and margin setup easier, but you can set it up however's convenient. In fact, you may choose not to use descendant/type selectors, but rather descendant/classes applied to SPAN elements. It's a question of how you construct your page (you may want to refer to the CSS Style Rule Management document).

Here's the resulting column when the above CSS is applied:


The entire area of the 'post' is a link now, but this isn't that evident, especially if the browser has specific cursor settings applied, which today, many 'portable browsers' (browsers on dedicated devices) have. To make this properly noticeable, there's need to make these areas react to the cursor.

We'll do by adding the following CSS:


By adding just the two rules above, we get the following result:



What these two rules did was to add a :hover pseudo link class to the H6 and the P elements. These made them react specifically to the hovering state, each in their own way. Incedentally, they each reacted the same way, but this isn't a must -- they could have reacted drastically different.
But wait a minute... Why style the A element at all? I mean, the A element isn't even part of the visible area, it's completely covered by other elements. There's no reason to style it, let alone give it a background property, right? As far as the standard is concerned, yes. But guess who disagrees? Internet Explorer 6, of course! You see, if you don't style the A element independently, even if there's no need, no hover effect will be triggered in IE6 at all. Luckily, this fix doesn't take much effort on our part, and doesn't mess things up for other browsers. Basically, just remember: When styling block-level elements, and applying the :hover pseudo link class, remember to apply it to the A element as well, and add a background-color property to it, so IE6 can be happy.

In for a penny...

That was a rather simple structure. There wasn't any real nesting of elements involved, all of the rules used descendant/type selectors, and the hover effects were all the same. Let's take the same scenario, but with a more complex structure this time:


Now that's something to work with. There's an ID, a type, and three classes. Also, elements are properly nested within each other, with content within different 'layers'.

Now for the starting CSS:


This time, selectors are much more specific, due to nesting. The last selector is actually an #ID Type .Class .Class .Class selector, which in practice is really just giving the browser a run for its money, there's no need for specificity to go that far when you're selecting, I did so here so that I could demonstrate how to later convert them into even more foreboding pseudo link class selectors.
Note that since all of the classes are applied to SPAN elements, they're all given display property values of block, since none of them is inherently so. The .container class simply buffers all of its descendants 15 pixels to the right, by adding a padding-left property value of 15px. You'll see why this is done in a moment.

Here's how this looks now:



Time for some hover states:


Note that in the a:hover .container pseudo link class rule the padding-left property value is reduced, but this is compensated for by adding a border that increases the sum of pixels to the left of the content to 15, exactly what it was previously, so that the block itself does not move.

The rest of the properties are better rendered than worded:



Note: Internet Explorer, any version of it, interprets the "dotted" value of border-style as round dots (that scale up to be pixelated circles), whereas other browsers interpret this style as square dots (that scale up to be, well, squares). This is just an example, and maybe one you should specifically avoid for this reason alone. It is completely within the standard to render "large dots" any way you choose, simply because the standard does not specify how dots should look when 'zoomed in'. I must say that, intuitively, I think that Internet Explorer's rendering is the more accurate interpretation, since what do you expect to see when you 'close in on dots'? Still, the more common interpretation is squares, and that's what this specific design was aiming for, but this is really just a one-of-countless example.

It is vital at this point that you not focus on this individual effect, but rather on how it was achieved. You can craft any number of structures and effects on your own using these techniques, as long as you remember to keep the initial triggering area where you need it to be. Links don't have to be underlines under text: they can be paragraphs, tabs with backgrounds (and background-images!), headings, and overlays, and the hovered area does not all need to be effected -- you may choose to have a large area as a trigger, but just a heading react to that trigger. This means that you can create websites that feel like dynamic applications (well, the subtle ones, no need to go overboard -- and it's easy to!). Also, remember to experiment with background-images, you can combine them with block-level link styling to get amazing results.

This is it for this installment of styling links. Remember to 'hack around' and to see what works, and always remember to do two things: view the source of anything interesting you see, and always validate your code with W3C's CSS and HTML/XHTML validators.