Published 28 Apr 2005
You (meaning the five of you who are repeat visitors) may have noticed the recent redesign, which is about number 12 for this blog. I am bucking the trends again, going with a more complicated layout while most are moving to something more simple. I just couldn’t stand all the f’ing boxes.
I thought it was about time to marry the square edges with the curves— kind of a nice metaphor for me, don’t you think? I really wanted some asymmetry, because I felt my designs were tending more and more toward the blocky, minimalist thing. And while that’s a really good solution for something like a web ap, it’s a terrible solution for a site whose sole purpose is to represent me.
I have the good fortune to not be seeking employment or clients, and to not be selling anything, so I can make this site as personal as I want without having to worry about branding, watching my language, screwing up my feeds, or providing an inconsistent experience. This site is about me finding my voice, through design, writing, humor, photography, and chemistry. I wanted a layout that represents that complexity, while still focusing on the color schemes generated by the animals, which is a current fascination of mine.
So I turned to an oldie but goodie.
Rounded corners are part Holy Grail and part yesterday’s news. As standards-based web designers, we’re pretty much stuck with boxes, since the whole layout engine is based on them. So talented designers, CSS gurus, and programmers have been exploring how to make the boxes more interesting for a couple of years at least. Step one is rounding those corners, which someday could lead us to (gasp!) circles.
There are a wealth of techniques out there for making rounded corners, ranging from the markup-heavy but bulletproof to the elegantly simple but widely unsupported. There are even rounded corner generators. For this site, I wanted to go with a minimal mark-up solution. I felt like I was already using my fair share of extra
<span>s to solve other layout problems, namely creating the framework that lets me easily change background colors of the columns1 and ordering the source to allow the content to come first in non-textual browsers2. I was willing to use a CSS3 solution, since I am targeting users with standards-compliant browsers and this is an experimental site.
Unfortunately, the most elegant solution I could find would not work for my purposes, because it’s set up to achieve the exact opposite of what I needed to do. The technique uses CSS3 generated content and pseudoclass properties to add the images that round off the corners to the document. By creating an image that is partially transparent (which allows the background color of the content block to show through) and partially opaque (to blend into the background), you can seamlessly round off the corners of a colored content block (see Figure 1). However, on this site, it is the background color that is the unknown. The color of the content block is always white. And, unfortunately, reversing the transparent areas of the corner images causes the technique to fail. Rats.
So, I decided to try to make due with using HTML elements that already occurred naturally in the mark-up, adding extra elements only when necessary. Since I actually never have boxes with four rounded corners— at least one edge of every visual box runs into a margin— I thought it was likely that I would have close to enough elements to work with.
It turns out I was right. I ended up with a system where I had to add needless
<span>s only in one place to achieve the look I was going for: between comments. The rest of the layout had enough hooks, between the layout
<div>s and, text mark-up, and my new little hero: the
Now, I realize that the semantic worth of
<hr> elements is in question. I tend to think they short-changed, though, for two reasons: they are misnamed, and they are hard to style. We’ll get to the second point in a bit.
<hr>s were called “section dividers” instead of “horizontal rules”. This is how I use them, and I think they are very powerful when used in this way, especially in non-graphical browsers or when styles are turned off. It is much easier to comprehend an unstyled document when there is something to break up the flow and signify where major sections are starting and ending. This section divider happens to look like a long, horizontal line when styled by the base browser stylesheet, but that doesn’t (or rather shouldn’t) mean that it has to. What’s more, a “section divider” may actually belong in the mark-up of a document, rather that the stylesheet— a demarcation of where sections start and end adds semantic meaning to the document. I’d like to hear from the accessibility gurus out there as to whether
<hr>s affect the accessibility of the document, either in positive or negative ways. My gut tells me that logically placed
<hr>s (i.e. section dividers) would aid accessibility, but I defer to the experts on this.
In any case, I had decided at the beginning of this redesign to place
<hr>s logically throughout my documents to aid comprehension in non-graphical browsers, and hide them with CSS from the main design. It turned out that if I didn’t hide the
<hr>s I was able to use them as hooks on which to hang my rounded corners. This worked out great in most browsers, but caused me some problems in one particular class of browsers… I’ll give you one guess as to which.
<hr>s in Internet Explorer turned out to be a challenge. Previous articles had warned me that using background images on
<hr>s was problematic. Even after removing the borders, IE insists on leaving a light grey “pseudoborder” around the
<hr> (see Figure 2), as well as adding some non-removable white space below it. After a little tweaking, I was able to able to get things working in IE 5 Mac. The trick here was to create height using the
padding property rather that the
height property, and to add
overflow: hidden. Then all that was needed was some negative margins to pop the
<hr>s into place.
Unfortunately, this trick did not work for IE PC. No matter what I did, there was still a grey “pseudoborder” along the bottom of the
<hr>. I thought I was sunk, until I reflected for a moment. I was willing to use a CSS3 solution to the rounded corner problem, which would have left IE PC with square corners, since its CSS3 support is not exactly stellar. So if I just hid the ugly
<hr>s from IE PC, wouldn’t that have much the same effect? Why yes, it would. So now, IE PC gets a few less rounded corners than other browsers, but the design concept still holds, more or less. Anyplace where I used a different element for my style hook still gets rounded corners in IE PC, and the rest of the corners are square.
The moral of this story is to be clever in your use of naturally occurring mark-up elements before you add anything extra to achieve a graphic effect. If you carefully examine your mark-up, goals, and the compromises you are willing to make (or forego) for older browsers, you may find that you already have what you need.
1 This is done with a clever layout from Ruthsarian Labs that uses borders of a containing
<div> to create a background colors for nested
<div>s that are pushed over top of them with negative margins. Column colors can easily be changed by changing the border colors of the parent
2 Ruthsarian Labs also offers this option— see the Gargoyles layout.
3 Actually, I can see a lot of influences from Jon Hicks in the design as a whole, so hats off to you Jon! I really like your work!
This is the section that contains all of my professional articles — serious, no-nonsense stuff that you may need caffeine to get through.
I’ve been trying to figure out how to sum up SXSW 2009 since I got back, and I’m still not sure I can do it. It was a much …More »