Redesign with a little help from my friends

May 19, 2003

Does it look different? It should. Yes, MacEdition has been redesigned. It’s a fairly subtle change – a slightly different color palette, thinner black borders, a few little tweaks here and there. The differences under the hood are much more substantial. After three years of CSS-plus-tables, we were no longer cutting-edge in our use of Web standards. In 2000, just avoiding the font tag and setting the background color in CSS was considered drastic. Now, mainstream sites like Wired and ESPN are full-contact XHTML and CSS sites. It was time to practice a bit more of what I preach.

As I’ve previously complained, our Mac-oriented audience had been holding us back to some extent, but the problem has diminished. iCab still doesn’t do any kind of float or positioning – it’s promised for Version 3 – so the site looks horrid in the half of a percent of users with that browser. The old design didn’t look too great in it either, so I’m not that bothered. OmniWeb’s recent adoption of the WebCore rendering framework also used in Safari means that it’s no longer a standards straggler. Around half of our OmniWeb-using readers have already adopted the WebCore-based Version 4.5. And of course, Netscape 4 used to hold a bit of sway for Mac users that you just don’t see so much in the Windows world. Even so, Netscape 4 usage is down to about one percent of our human pageviews, and I’m not shedding any tears over that!

As a result, the stragglers are less of a problem now, and the introduction of Safari seems to have resulted in some switching away from less CSS-capable browsers like pre-WebCore OmniWeb (Versions 4.2 and below) or iCab, as well as from largely compliant browsers like Camino. So we finally had the audience that allows for a more CSS-based design, and now that I’ve finally graduated (yes, it’s Dr. CodeBitch from now on!), I had a bit of time to put a new design together.

I’m not going to discuss the aesthetics of the new design. It’s pretty similar to the old design, and anyway, we all know economists have the aesthetic sensibilities of a stick, so some smarty-pants types will always find something to complain about. There are, however, differences in the markup and CSS that might be of interest.

Start at the hidden foundations

In the beginning, there was one stylesheet, me.css. Everything went in there, and all browsers could see everything in it. Back in 2000, Web authors knew that @import commands hid things from Netscape 4 and early versions of IE, but the array of sophisticated CSS-hiding hacks had not yet been discovered. Now we can be more sophisticated about hiding CSS rules from browsers that can’t cope, but of course this adds to the complexity of the set of stylesheets. Other than one small hack for IE/Windows using the child selector hack, which I then had to override for IE/Mac using the backslash hack, the main browsers I’ve had to protect from themselves are Netscape 4 and pre-WebCore OmniWeb.

Pre-WebCore OmniWeb can be accommodated by giving it a stylesheet it can cope with and then using the CodeBitch OmniWeb hack to override it with the styles that I really want in another stylesheet. Netscape 4 is amenable to several hiding techniques, including @import, which I use to hide the OmniWeb stylesheet from Netscape 4, and media="all", which I use combined with the OmniWeb hack as media="All" to hide a few styles from both these browsers. Most of the time, though, I’ve used Caio’s hack, which is useful for hiding particular rule blocks and property-value combinations from this elderly browser. (I haven’t bothered working around the issues this hack has with Opera 5/Mac. This browser contributes less to our pageviews than Cyberdog – most Mac users with Opera would be using Version 6 now.)

This structure of hiding techniques is on top of the different stylesheets now used for different media. Yes, folks, MacEdition now has a print stylesheet. IE, Opera, Gecko-family and KHTML-family browsers all support them, so it’s worth adding one now. The suite of stylesheets now include a screen stylesheet, a print stylesheet, and two stylesheets (Netscape 4-safe and not) of stuff that applies to both print and screen.

Is this the right way? Possibly not. One corner I have painted myself into is that much of the styling for screen presentation has had to be repeated. There’s a stylesheet that pre-WebCore OmniWeb can see, and a stylesheet that Netscape 4 can see, so all the common formatting has to go in both files. Once OmniWeb 4.5 reaches final release, though, I’ll probably get rid of the pre-WebCore OmniWeb-only stylesheet. Its main purpose is to work around the older version’s lack of support for position:relative and the strange way it deals with percentage widths. I’ve never really quite worked out what it was doing with these – maybe widths and margins in percentage units were treated differently or something. Whatever it was, it was wrong, and I’ve worked around it by using fixed units for pre-WebCore OmniWeb and percentage “fluid” units for everything else.

90 percent perspiration, 10 percent inspiration

Once this infrastructure of media types and hiding techniques is set up, what to put in it? You’ll notice a few visual tweaks, of course, but I admit that none of them are truly original. The navigation bar at the top is now a list instead of a table – after all, a navigation bar is a list of links. Much of the styling was inspired by Mark Newhouse’s seminal article on styling lists on AlistApart. Some of the experiments by Mark Pilgrim and others also gave me some ideas. (You can’t see the navigation bar in Netscape 4. I couldn’t make it work properly so I hid it.) Similarly, our rejigged sidebar derives much inspiration from the same AlistApart article. The idea of marking it up as a definition list was inspired by the list of externals on Zeldman’s site and the border hover effects came from one of Eric Meyer’s CSS Edge demos.

The layout itself uses CSS positioning, with the sidebar being an absolutely positioned div inside a relatively positioned containing div. This is a technique explained in another ALA article, as well as in the incomparable CSS-Discuss Wiki.

There are a few tradeoffs involved in this. There are some techniques using background images that ensure backgrounds go all the way to the bottom of the longest column, much like a table. Again, these are all things that people have worked out since our original design in 2000. But to date, most of these layout techniques seem to either involve fixed-pixel sidebar widths or fail to match the MacEdition layout in some other way. I wanted fluid-width sidebars, so these layouts weren’t suitable. I’ve set things up so that the sidebar should always be shorter than the main content. The orange background continues because it’s actually the background of the containing div. For short articles, we just use a short version without recent story listings. It would be nice to use the overflow property instead, but so far I’ve found that a bit flaky even in the modern browsers.

So there you have it. It’s probably not perfect, and I’d love to avoid some of the duplication of styling that the hiding techniques require. But the markup is cleaner and more amenable to automation – if we ever decide to put in a right sidebar, it’s a trivial addition of more text to an include file and some extra work on the stylesheet. That would have been a serious pain with a table layout with all its rowspans and colspans. And it will be nice to be up at the edge again, instead of lagging the crowd.

If you have any questions about why and how I’ve implemented this redesign, feel free to post your questions to the Feedback Farm or the forums.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend