Redesign with a little help from my friends
May 19, 2003
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
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
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,
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 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
which I use combined with the OmniWeb hack as
hide a few styles from both these browsers. Most of the time, though, I’ve
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
instead, but so far I’ve found that a bit flaky even in the modern
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
colspans. And it will be nice to be
up at the edge again, instead of lagging the crowd.