If only it were that simple.

Try changing the font size. If your set-up is anything like mine, it looks perfect on any size except the default.

Shrink the font, and it fits on one line. Increase the font and it splits over two at the right point. Leave it at “Normal” and it doesn’t fit and doesn’t split.

I am getting frustrated about now.

Tested in IE6. IE6 can’t handle zero-width spaces, even when using the decimal expansion AND setting the font AND declaring the style to be zero pixels wide. Changed back to a normal space between June and July, but still have set the width to zero pixels.

The proportional spacing problem wasn’t proportional spacing. It was a plain old error in the CSS. Fixed.

Firefox looks good when in a small font (year displayed on one line), and when in a large font (year displayed on two lines) but not in a medium font (year displays on one line even though it won’t fit.)

I swear, I am close to redoing the whole theme with good old reliable tables, and giving CSS the flick. How close? Well I would show you, but   isn’t widely supported yet.

are you still fiddling with the month thingies?

Yes.

For me, the lines are not breaking [...] in Firefox.

Waaah! I tested in Firefox on my test blog, but my test blog has less frequent posts, and it looked fine. I just tried again with the live site, and yuck!

(For that matter, this comment edit box spills over into the right-hand blue margin once I type enough text into it.)

When given the choice between breaking a word at a non-space or scrolling off into no-man’s-land, browsers always seem to choose the latter…

In IE, on the other hand, there is a visible dot after June and the months are broken into two lines.

I am not seeing that on IE7. It could be the zero-width space is being rendered as an unknown character on IE6. I’ll test it out.

In both browsers, it looks like the spacing of the unavailable months is larger than that of the available months.

Agreed. I need to fix that. I mentioend it before as a “proportional spacing” issue.

Thanks for your continued feedback!

In IE, on the other hand, there is a visible dot after June and the months are broken into two lines. In both browsers, it looks like the spacing of the unavailable months is larger than that of the available months. So in IE, 2006 lines up nicely, but 2005’s top row is longer while 2007’s bottom row is longer. (I should probably mention that my version of IE is 6.0.)

Other than that, I think this looks and works noticeably better than the larger month initials. It’s much closer to what I was trying to describe earlier with only limited success due to my rudimentary knowledge of HTML, CSS, and other browser-related technical details.

I also wanted to mention that the Subscribe page is vastly improved. It’s not even a bad day. Again, I’m not as minimalist as Aristotle, and find it more comforting to see the protocols mentioned, even if not strictly required. And I do have a rational reason for this: I would rather not have to try something and only learn by its success or failure whether it was supported.

Does having a list item larger than its parent look vaguely disturbing to other people, or is it just me?

The area for each link is still relatively small

I approve of the theme changes, but it looks odd to me that the months are larger than the heading above them. I realise this conflicts slightly with the goal of making them easy to click on.

Based on the above feedback, I have made the text small, but increased the padding associated with the link, so being slightly inaccurate will still get you to the right link.

I didn’t seem to have to use Aristotle’s negative margins. Tested on IE7 and FF, and it seems to work. Is something going to bite me later?

IE7 has a zoom feature (a different feature to setting default font-size) which appears buggy. When you zoom, it forgets about the padding. It looks fine at 100% though.

I replaced the Thin Space with a Zero-Width Space, with additional CSS to handle the fact that most fonts don’t support it.

When the months don’t fit on one line, the dates don’t line up due to proportional spacing. I am too tired now to work out if the CSS box model supports specifying an overall width for a box.

Btw, the HTML you produce is a bit suboptimal. Instead of all those SPANs, it would be better to have LIs inside another unordered list; simply use a display: inline property for the list and its items and they’ll render just like your current pile of SPANs does.

My thinking was that if it is distributed as a widget and the user has a theme that doesn’t explicitly support the new styles, the widgt should give a reasonable result anyway. Missing the “display: inline;” would give a pretty awful result.

Though I must admit, your solution on plasmasturm of putting a generous amount of space between lines does work quite well.

:-) That one’s a well-known typographic rule: you can make lines quite wide (though not arbitrarily so) without significantly affecting readability as long as you adjust the line height to match. Since the eye has to travel further to find the start of the next line with longer lines, you have to make the “grooves” wider to allow it to track them reliably.

The default line height used by webbrowsers is too small for general use.