Category: WebDesign

Things definitely to come in the redesign:

1. Less junk on the page. Somehow.
2. Less crufty CSS.
3. More elegant typography.
4. More elegant design, period.
5. New site logo and masthead.
6. New navigational resources, including a greatest hits.

Things I’m thinking about:

1. Dumping the news item department graphics, in favor of text links. On the plus side, they brighten up the page a bit; on the minus side, they’re not exactly coherent, design wise, and they’re probably a good deal less understandable (unless you’re in the habit of mousing over graphics) than a simple link to the department archives page would be.
2. The blogroll. Well, not dumping it, exactly, but maybe getting smarter about how I show it, along the lines of Greg’s MORE link. It will definitely disappear from sublevel pages.
3. The badges, unless required by some sort of reciprocal agreement.

Here are some of the extremely helpful resources I’ve been consulting:

• Zeldman’s CSS smorgasbord II, an enormously useful rollup of links about designing with CSS; which has in turn led me to…
• Layout-o-matic, and its kindred spirit tool List-o-matic.
• And, of course, the CSS reference, handily available (if you aren’t on a wireless LAN) in PDF form.

Via Scripting News, Deane asks whether RSS aggregators should strip style attributes (presumably, this would also apply to aggregators of Atom/Echo/whatever the RSS successor format is called as well).

Count me in the minority that wants my feeds presented as the author provided, within limits (“I wants my funk uncut”). There is semantic meaning carried in tags like <strong>, <em>, and <pre> that would render some posts meaningless. That said, I hate feeds that render as white text but don’t have the dark background specified in their page’s body tag to make the post readable. Maybe if everyone moved to using CSS stylesheets and classes instead of local CSS styles or <font> tags, preserving styles would be OK.

In fact, let’s go a step further: CSS compliant styles should be rendered by aggregators; old-skool HTML styles should be stripped. How’s that for incentive to learn the new technology?

I still have a few problems with Safari, including the fact that it doesn’t appear to support font-variant: small-caps; as a result my date headers appear in lowercase. But I bit the bullet and redid my CSS so I wouldn’t fall prey to the problem that was hitting me with a div nested inside my H3 tags, so most of my page now displays correctly.

For the record, I just appended the border effect I was using in my “grabber” div to the H3 style definition. It means I have to update multiple places in my style sheet if I decide to get rid of the blue bar effect, but it seems a small evil to put up with.

I should just leave well enough alone. IE 5 and 6 won’t allow me to resize the font even with its size specified in pixels. Also, more seriously, Gentium looks like crap when it’s bolded, since the designer hasn’t provided a true bold. Buh-bye.

Things have been pretty crazy at our office owing to the SQL Slammer worm. We’re just starting to settle back to normal, but I expect to continue to have an impacted blog for another day or so.

In the meantime, go take a look at the much faster loading Weblogs.com. Dave updated the page design this morning, based on some seriously heavy CSS lifting by Douglas Bowman at StopDesign. There are some really good lessons to be learned about list coding in this redesign. The big table was turned into an ordered list; each entry in the list has a blog name and an update time. “But wait!” you cry. “How did he get the time to float to the right?” Very simple. He surrounded each time with emphasis markup (em>) and defined a rule for emphasis inside an ordered list that floated the emphasis all the way to the right hand side of the bounding box.

Semantic? No. Tricky lightweight code? Absolutely.

Apple made a new browser available in public beta yesterday. This doesn’t happen every day. There was, naturally, a rush to get it, and then a rush to test it. I think every web designer and blogger in the world was thinking what I was: “Great, another browser that I have to worry about. How many things on my pages will break with this one?”

In this case, for me, not much breaks. If you’re reading my page using Safari, the title of each post will appear in the same font and size as the paragraph text below it. It should instead appear in Verdana, Helvetica, or your favorite sans serif, at 14px (slightly larger), as specified by my CSS rule for the H3 tag. Also, periodically a page will load but not show any content or only show a few images on a page; reloading generally fixes the problem. So far I haven’t found anything else broken yet. It does seem a little faster than Chimera, though I haven’t done any stopwatch exercises.

There are a bunch of other folks looking at the browser, though, chief among them Mark Pilgrim (who has both an initial review, in which he strongly states that the lack of tabbed browsing is a showstopper, and Safari Information For Web Designers, in which he summarizes rendering successes and failures of the browser). and Mena Trott (whose article contains links to most of the other big articles on the subject, including the changelog from KHTML to Safari). Finally, here is the blog of Dave Hyatt, one of the team members, in which he addresses some of the initial review comments.

It’s always driven me nuts that the month links didn’t line up properly underneath my site calendar. I figured it had something to do with the way I had defined the div around the calendar, but I didn’t have time to look at it until this afternoon.

The problem was that the div was defined to start at 70% of the page width and take the rest of the space on the page, but the content was centered in the div. For some reason, the table had a different center than the line following it, which caused the month links to show up askew.

Easy fix, right? Just recode the width of the calendar div. Except that it turns out not to be simple with CSS. Basically, what I want the calendar to do is this:

• Hug the right hand side of the page, most of the time
• If the window is too narrow to put the calendar to the right of the logo and still be visible, either:
  • wrap the calendar to the next line, or
  • scroll the calendar off the page to the right.

I don’t know a way to manage all of those things at once. I currently have changed it so that the calendar hugs the right hand side (for what it’s worth, I changed the width to 190px, the same as the min-width; eliminated the left attribute; and set the right attribute to 0). But if you shrink the browser window too far, the calendar overprints the site logo.

Actually, this isn’t the biggest problem, since the content starts to run into the nav bar before this happens… This is all because there’s no concept of “min-left,” the minimum left distance from the left hand bounding box that an element needs to respect.

more…

Mark Pilgrim wraps up “30 Days to a More Accessible Weblog,” the longest running and most useful targeted discussion of why standards for accessibility matter and how to implement them that’s ever written. I’m glad he’s through, because I’m about 20 days behind in implementing his recommendations and the backlog was growing. Still, we owe him a big big big round of thanks. Someone give that man a lot of money.

On a related note, I’ve forgiven Mark for winning our category in the 2001 Scripting News Awards. In the last month he’s done more service for the weblogging community than I will in a long time.

more…

Mark Pilgrim: Using relative font sizes. I should be pointing to one of Mark’s articles every day. This is just one of the thoughtful, well written articles on the state of designing web sites for accessibility in 2002. It offers a good mix of audience justification for taking the trouble to make your pages resizable (“if people can’t read your words, what’s the point?”) and technical details, including stylesheet tricks that prevent Netscape 4 and Mac Opera 5 from choking on CSS syntax they don’t understand.

Of course, I haven’t had time to implement his suggestions yet. Next on my list…

more…

After much head scratching, I finally figured out why this site never displayed correctly in IE for Windows. I had some tags nested in the following order in my template:

<div class="grabber"><h3>Heading</h3></div>

After this line, text in the following part of the page drifted just slightly to the left, eventually getting cut off by the bounding box of the parent div so that it became unreadable. By reversing the order of the <div> and <h3> tags, so:

<h3><div class="grabber">Heading</div></h3>

it works on IE for Windows.

I should amend my first sentence. While I’ve figured out how to fix the problem, I’m still not sure why the order of the tags should matter—and why IE/Windows cares when other browsers (including IE/Mac) doesn’t. But the important thing is the problem is fixed.

more…

Brent: Best viewed with Lynx:

And now we’re returning to simple HTML, not unlike the HTML of 1994. More structural markup, less of that complex and weird junk. Layout is done through style sheets.

Sites designed that way look good in Lynx. You don’t even have to try. I didn’t go out of my way to make this site work in Lynx.

This site looks pretty good with Lynx, too. And it’s a Manila site. The secret is in the CSS. There’s still navigation, but except for the calendar it’s way down in Lynx; the content stays at the top.

more…

David Donald raises some interesting issues with the new design. Namely, a lot of the edit forms that Manila puts up if you want to post a comment are wider than my center column on most resolutions. As I don’t have much control over how wide those forms are, I may have to rethink how I’m doing the page layout. I think another issue was my design environment—I designed on a 1024×768 monitor, but readers like David are likely reading at 800×600. Maybe the best thing to do is to take everything back to two columns? What are people’s thoughts?

Here’s a sneak peek of a problem I’m having with the site redesign in IE 6 on Windows. It works fine on the other browsers I’ve tried (mostly readable in NS 4, ugly in Mac iCab but that’s OK), but on IE 6 it starts doing funky things with border and text position. I’ve been over the stylesheet lots of times and can’t find the issue…. Interestingly it only does it on the second and subsequent news items.

I’m very taken with A List Apart. They really have the sweet spot between coding and development—and between what the CSS spec says and how it is implemented. One complaint: there’s a lot of value in their series on transitioning to CSS from older forms of design (tables), but it was written in 1999 and a lot of the practical issues they mention have evolved with Netscape and IE 6 on the table.

more…

I spent all yesterday (when I wasn’t in class) working on the CSS redesign of the site. I was about ready to give up on being able to view it in Netscape 4 until I found this site, which offers a free stylesheet for a fluid three-column layout (fluid meaning it resizes to fill the available browser width).

I had to tweak it a bit because of the Manila calendar. Manila automatically renders the calendar as a table, so it doesn’t resize. This is a problem with small browser width as it extends past the edge of the navigation div. I had to make the left navigation fixed width to solve the problem. This in turn meant the middle and right divs overlap at some smaller browser widths. I’ll do some work in 800×600 today to see if I can isolate the problem.

But most of the structural work is done. Now I can move on to aesthetics — colors, border widths, font leading — oh yeah, you can do leading, aka line height, in CSS. This old digital typographer is thrilled.

more…