Category: WebDesign

Heads down

Today is a low-posting day. I’m doing some coding on the site, adding a feature—and relearning a lot of CSS lessons I had forgotten. One of the nice things about the site is that I haven’t had to touch the CSS stylesheets in almost a year, but things have gotten a bit rusty in the meantime…

Avoiding search engine confusion with charset

Following up on an old thread, the reason that MSN Search thought my pages were in Chinese and other languages rather than English was a problem with the charset specified for my pages. My site used to specify its charset as Macintosh: <meta http-equiv=”Content-Type” content=”text/html; charset=macintosh”>. Unfortunately, MSN’s search crawler doesn’t understand this charset. So as an experiment I tried changing the charset to UTF-8 on my front page, while leaving the deep pages untouched. Now an MSN search on my name no longer brings up garbage characters.

That’s the good news. The bad is that re-rendering my whole site to fix the charset on all the deep pages will be a royal pain.

Who cares about accessibility? It has small caps

Safari 1.2 is out. Along with all the new features touted on Apple’s site and revealed on ThinkSecret, including enhanced navigational options, resumable downloads, and support for LiveConnect between JavaScript and Java applets, it has what is, for me, the most important feature of all.

It supports font-variant: small-caps.

Let me repeat that: it supports font-variant: small-caps.

Finally. All my carefully designed small caps, in full living typographical color on Safari. I’m thrilled to pieces. Of course, I’m also noting that Georgia in small caps kind of washes out at that point size. Sigh.

Minor stylesheet fix

Anita was kind enough to point out that I hadn’t bothered to set background or text colors in my new lean mean stylesheet, which makes the page look kind of funny in Netscape 4 or in any browser where you can set your own background color.

This is an easy mistake to make when you’re moving away from deprecated HTML attributes. In my case, I changed my style sheet to use a plain old <body> tag instead of Manila’s [Macro error: Can't evaluate the expression because the name "body" hasn't been defined.]
 macro, which automatically inserts deprecated attributes for background color, text color, link color, and so forth. The way to handle it is either to set the attributes background (for the background color) and color (for the default text color), or else not to use any colored elements in your design at all and make the user responsible for his or her own bad taste.

At any rate, I’ve made the fix; shift-reload to get the change (very minor).

The IE Factor?

Interesting article at StopDesign describing real work experience in getting CSS layouts to work across platforms. As those who have been reading the Web Design department through my last redesign will attest, this is a non-trivial challenge; some apparently easy CSS styles will work well in one browser while not working at all in another.

But why is it the IE Factor? That is, why does IE get the blame for non-conformant behavior? That’s the question some of my coworkers might ask. After all, it has CSS support; after all, it’s the minority browser. And after all, other browsers have their own quirks. Why single out IE?

Based on my experience and StopDesign’s article (and Bryan Bell’s Designers Against Stagnant Internet Explorer (DASIE) manifesto), I think IE is getting heat for the following reasons:

  1. IE 6 was released in 2001. The most recent major revisions of the competing browsers, Mozilla/Firebird and Opera (as well as other significant browsers like Safari and OmniWeb) were all released in the last six months. That’s two solid years of designers actually using CSS and documenting their problems.
  2. Mozilla is open source; Safari is developed by a guy with a weblog where he responds to customer comments. The IE team has so far kept a very low profile about the future of their products; in fact, they’ve committed publicly to infrequent releases of new features, in line with the Windows software development cycle.
  3. Adding insult to injury, not only does IE not incorporate two-plus years of real world customer feedback, it’s the dominant platform. So it’s held to a higher standard—any flaw gets dramatically magnified.

Why are we in this boat? I think, after Netscape imploded, a lot of people thought that innovation and change was gone from the HTML space and attention shifted to the web services space, where presentation isn’t as important as XML, namespaces, and actual programming languages.

But I think IE has competition again. More importantly, I think the various campaigns to get people to upgrade to modern browsers have led more designers to push the envelope of what can be done with (X)HTML+CSS. And I think that’s a good thing.

Putting my main content first, finally, with CSS

I wanted to fix the new design so that it read well in Lynx (and by extension in other non-graphical browsers, for instance screen readers). After all, Day 10 of Dive Into Accessibility is to present your main content first, and one of the virtues of my previous design was that it did just that. (Mostly; it did have the calendar links before the content, and they were a mess in Lynx.)

So, no problem, right? My main design was two columns, a content column to the left and a navigation column floated to the right. I should just be able to put the content div first and put the navigation div after. Right?

Except that the order in which floats occur, relative to non-floated content, actually matters. To get things working right, I would either have to float the content div instead or find another approach. But as it turns out, floating the content div was a non-starter because it meant I would have to fix the width of the content div—and even if I set the width to a percentage, I would still run into some ugly layout problems in narrow browser windows.

So I waited. Which turns out to be the correct move, since a solution was posted in the comments at MezzoBlue on Friday that explained exactly how to do what I was looking for. There’s a negative margin the width of the sidebar on the main content div, with a right margin set to the same width. That gets the content div out of the way and leaves enough room for the sidebar.

It’s a tricky little hack, and it scared me sufficiently that I changed the name of the stylesheet to ensure that new browsers would download it so the page wouldn’t look broken. The good news is that means that old pages that haven’t been re-rendered on the static site should still look OK, though they won’t get the correct content order until they’re fixed.

Thanks to Dave Shea at MezzoBlue for asking the question, and to Ryan Brill for providing the solution.

Joys of collapsing margins, and custom 404s

I made some minor changes to the main stylesheet today to improve the readability of the site. In keeping with some of my recent reading, I kept the changes simple and almost entirely typographical. I had already increased the leading between text lines; to break up the flow and call out the post titles a little more (which were drowning in a sea of grey), I indented the post text under the headlines by 24 pixels, also known as two ems (since the text is specified at 12 pixels). Shift-refresh any page on the site (to force the stylesheet to reload) to get the changes.

Incidentally, why pixels and not points or ems? There’s a long history of discussion on that point but it basically comes down to browser compatibility issues; IE3/Win renders ems as pixels, and points vary from browser to browser and platform to platform. There are ways to work around the problem, and someday I’ll tackle resetting everything to use them, but not today.

So, implementing 24 pixels of white space to the left of the news item text should have been simple, and it mostly was. I already had a class for the news item description, fortuitously, though I never defined any style attributes for it, and my news items were automatically wrapped in a div of that class. So it’s easy, right? Just set margin-left: 24px; and you’re good to go.

Except: margins collapse. This is a factor in the CSS box model that I keep forgetting. If you have margins in two blocks that touch each other, the margin sizes collapse to zero. CSS 2 amends this to say horizontal margins should never collapse, but IE6 collapsed the margins anyway. So, setting padding-left: 24px; solves the problem. Padding never collapses.

I’m also finding other minor problems throughout the site with the display. This time it’s in the content markup, which means it will be harder to fix. NetNewsWire correctly wraps both opening and closing <p> marks around paragraphs (though it sometimes gets overanxious and wraps them around list markup, which is technically a no-no). But Manila’s in-browser editor, by default, only places a <p> mark at the end of each paragraph, as though it were a glorified <br>. The net result is that many of my posts that were made from the browser do not have paragraph styles applied to the first paragraph of the post, since Manila doesn’t insert a paragraph mark, and the post title ends up touching the first paragraph instead of being offset by 12 pixels. The fix is simple: going forward, I’m manually inserting paragraph markup, and as I touch old entries I fix the paragraphing. But I’m not going to go through all umpty-thousand news items and fix them one by one, at least not right away. So be nice and ignore any inconsistency, won’t you?

One last thing: Based on the guidance in last week’s A List Apart, I implemented a custom 404 page on the static site that provides links back to the home page and the site map. It also customizes the message according to whether you’ve come from inside the site, from a bookmark, or from an external referrer. You will only hit it if you try to find a page where the URL starts with www, not discuss.

Crazy workaround for three pixels

I just cleared up a funny problem that I’ve had with my site on IE6/Win ever since the redesign. Only folks who were leaving comments via the Discussion Board or my coeditors would have seen this one; it doesn’t affect most users becauase I generally don’t use tables in my content, at least not tables with explicit widths.

The problem was in the feature that allowed users to edit content in the site in an HTML form. The form, which is automatically generated by Manila, is displayed on the page wrapped in a table with width=100% set. Apparently this invokes an obscure bug in IE6/Win in which IE silently adds three pixels of padding when content is displayed next to a float, which if the content next to the float is specified as 100% of the width suddenly means that the content is now 103% wide. To display the content, IE then drops the content down below the float. What this means in practical terms is that every time I wanted to make a change to the site, I had to scroll down past my navigation bar to see the edit area.

The fix turns out to be to specify a dimension (width or height) for the problematic element. In my case, this looks a little like this:

/* fix for tables falling below the float in WinIE; hide from IE5 Mac */

* html #content table { margin-right: -3px;}

/* end hide from IE5/Mac */

So the hack only gets applied to tables in the content pane, and only for WinIE (because it uses the StarHTMLHack wrapped in the commented backslash hack.)

The scariest parts of this are:

  1. Someone actually did enough debugging to figure out the bad behavior and find a clean solution.
  2. This makes the second or third browser specific hack I’ve had to introduce into what was otherwise a fairly clean simple stylesheet. Grrr.

More semantically correct page layout

I really should hang out one of those old “under construction” signs on this site. I keep finding new ways to tweak and optimize both the HTML and the CSS on the site. The under construction part? It may look funny unless you refresh your browser to force the style sheet to reload.

Today’s tweaks:

  • I cleaned up the style sheet, fixing some font inconsistencies (and incidentally saving almost a full kilobyte of file size). I did this by grouping all the CSS classes and other selectors that should have a sans serif font together and stating the font family name once and only once. (For the curious, the exact code is a comma-delimited list of class selectors, followed by this property listing:
    { font-family: font-family: "Lucida Grande", "Lucida Sans Unicode", verdana, lucida, sans-serif; }
  • At the same time, I added a new selector that sets the size of H2 headers in my sidebar to 11px, and changed the markup in the sidebar so that each of the bolded headings are tagged as <h2> rather than <p><b>.

So who cares? My readers who use Lynx or other user agents (for instance, the wireless version of Google, which scrapes pages into WML). Now, the sidebar is defined as a series of headings with detail underneath, rather than as an unstructured bunch of paragraphs.

Next step of course is to make it so the content, not the sidebar, appears first in those other browsers, and loads first in modern browsers. That’s a harder job than it appears; more details to come.

Jarrett House North, now automatically Print Friendly

I have, I think, put the finishing touches on another element of the new design for this website: the print stylesheet. One of the things I wanted to do when I first transitioned this site to a CSS based design was to optimize the print experience as well as the online experience. CSS, through using stylesheets linked for media="print", allows you to specify alternate presentations of your pages for print purposes without having to change your underlying HTML or forcing the user to choose a “print friendly” view.

The print stylesheet for Jarrett House North now suppresses all the navigation elements, gives a reduced size version of the site logo, and (on browsers that support it, such as Gecko-based browsers and Safari) prints the full hyperlink as text next to each link. Give it a whirl—I think you’ll like it.

For now, the regular print-friendly link will remain on every page, for print-friendliness on browsers that don’t offer full CSS compliance. But you no longer have to do anything special to get that print friendly feeling.

One interesting implementation thing I learned in the process. I couldn’t figure out how to dynamically resize the banner image and provide alternate text that I didn’t show in the main template, so I created a DIV that is hidden by the default stylesheet (by setting display: none;) and shown in the print stylesheet. Or at least, that was the intention; the first few times I made the change, the print version of the banner never showed up. I finally figured out that the default stylesheet’s rules are applied to the print content, then overridden by the print stylesheet’s rules. So rather than just redefining the div, I had to actually specifically override the display property by setting display: inline;. Once I did that, I was golden.

The main resource I used in creating the print stylesheet was an article by Eric Meyer at A List Apart called CSS Design: Going to Print.

Real HRs and faking them properly

I finally got around to putting in proper HRs in my CSS and in the sidebar. The redesign uses a fleuron from the Cronos font (in which the other fleurons and my page title are set) where a horizontal rule would normally go. Of course, this looks pretty silly in Lynx. So I turned to Dive Into Accessibility to see how HRs should be “faked” using CSS. It turns out to be a pretty simple trick involving background images and HR display rules, though of course there are some hacks required to get properly degraded behavior in downlevel browsers. Anyway, the point is, it worked. You may need to refresh the page to get the updated stylesheet to load properly, but once you do, you’ll see the fleurons and downlevel and text browsers will see horizontal rules.

Trackback and validation, and CMSes, and …

Scoble says that the Radio trackback feature (which is implemented identically to the Manila implementation on this site) makes his site fail validation. Frustrating when a useful feature like that has to be turned off, but I understand the pain; I’ve been working on validation myself.

At this point there are still a bunch of errors reported by the W3C’s validator, none of which I can do anything about. They all have to do with ampersands in URLs in my articles. Ampersands are commonly used in URLs when there are multiple arguments. Manila thinks that those ampersands should be represented by actual & characters (and enforces this in its managed content), while the W3C validator insists that, at least for HTML 4.01 Transitional, the ampersands must be represented as &, even in URLs. So there’s nothing I can do; the site is as valid as it’s going to get.

(Incidentally, if anyone has Manila spitting out valid XHTML, I’d love to know. It would be nice to get off HTML 4.01.)

For more info about CMSes and HTML validation, there’s a great interview with What Do I Know’s Todd Dominey over at WebStandards.org.

IE 5 CSS bug: fixed?

I think I fixed the CSS bug that was causing my site to crash IE 5 on Mac OS X. The offending rule was for list items inside unordered lists inside the .navContainerSide class, which are specified as floating—apparently having floated list items breaks IE 5. I used the Comment hack to hide the offending CSS from IE 5 and it now appears to work. Please advise if you’re still having problems reading the site with a particular browser.

More redesign angst

My new site design appears to crash IE 5 on the Mac, and I think I know why—it looks like a problem with the custom list CSS that I use to show the category buttons in the sidebar. If I suppress that section of the sidebar, the page loads, but the same code doesn’t render correctly in the header. I will work on this later; in the meantime, if you are having problems reading the site, try the print friendly version.

Redesign: heavy lifting done

I think that most of the work on the redesign is done. As you can see, the site now sports a new logo, new fonts, a different design, streamlined navigation, some new pages, and a bunch of other goodies.

So what’s left to do? There are always a few things. I think there may be some weirdnesses on IE Win that I need to fix. I need to fix a few graphics here and there.

But the biggest thing, ironically, is that I’ll have to repeat the rendering exercises that I did over the last two weeks all over again, so that all the static pages pick up the new design. Sigh.