Upon installing MT 3.2, I took the plunge and refreshed the templates, which brought me to the MT default Vicksburg Style. I spend some time with the Site Styles sheet, changing colours to get my old scheme back, and then in the Main Index and Individual Entry Index. I was still writing CSS by trial and error, so I invested in an O’Reilly book and spent some time on a few Web sites.
The default MT3.2 Stylesheet is logically organized and annotated – it’s easy to find the lines that change the font properties, layout, colours. It’s feature rich, with CSS classes defined for many blog features, all set to go. Some of the default settings are curious, but I supposed they make sense as a default. Fixed width columns at 480 and 200 pixels leave wide margins or black space when the blog is displayed on all but the smallest displays, and the font size properties are defined in pixels instead of ems. This is fine for Firefox, but not the best way to design for IE, which is still the browser most people use. IE won’t allow the browser user – for instance a user who prefer to see large text on screen – to resize text properly if the fonts are set in pixels. (It isn’t a well-known feature but resizing text is important to people with visual impairments and as a matter of personal preference in customizing one’s own viewing preferences). I don’t know if this has changed in IE 6 but it is a well-known problem with IE 5.
I applied some of my new knowledge by tweaking a few settings, mainly borders on elements that served as visual dividers. I changed the shade of red in the banner text to a less glaring shade. I did a little more experimental work in redesigning the stylesheet for the Web pages that accompany the blog, and the pages themselves (accessed by the links in the Author area of the sidebar). It was a good project. I learned more about inherited settings in CSS, where to make a single change that would ripple across the blog or the site pages. I played with fonts, on the blog and the web site, trying to get a less stark look to the main entry text. I tried out a serif look, after reading the serif vs sans-serif debates. Bookman Antiqua came out nicely but after trying it out I moved to a sans-serif look again. I may not stay with it. I have a problem with text spacing in the display of almost all fonts that I have tried. When I end a sentence, I type a period (.) followed by two spaces. That seems to display properly in my Entry edit screen, but it doesn’t display welll on the published page. I have started to use Gill Sans as the main Sans-serif font for Banner headers and body headers, Lucida Sans Unicode for entry text and various other page elements. Nicer look than MS Arial or Verdana, imho. I did a bit of writing on the web site pages while I was in them, making them more current.
Randy has a post on styles in WordPress on his blog (new version, published in WordPress). WordPress has a nice set of open source design templates. People, with taste and design skills, have made some nice designs available open-source. MT is lagging there, although the harmonization of the MT defaults with Typepad styles, and the StyleCatcher tool may help – if someone will start to collect the styles and make them available. I think MT has the ability to change looks (if you are prepared to reinstall some of your customizations) quite easily now, but it presently has only a small library of styles and templates.
The spam protection in MT 3.2 with Spamlookup has been good. There are Feedback screens, that is, Comment and Trackback management screens, blogwide or sitewide. Some feedback is in the main folder. That includes published feedback for editing control and unpublished (moderated) feedback. Some feedback is “moderated” to Comment and Trackback junk folders for review and deletion. It still requires some work, but it is a great improvement over checking Comments and Trackback lists for multiple blogs, and then checking separate logs and control screens in 2-3 plugins, and updating blacklists. The main problem with MT is that the new features are complex, and not intuitive or transparent. There is still minimal documentation on important features. I have figured it out, I have invested time in learning, and things work, so I am not driven to learning a new system right now.
Pixels vs ems vs points vs % is an ongoing debate. I’ve used all of them. Designers tend to prefer pixels because you know exactly what it’s going to look like on screen. Unfortunately, if your visitor has a 21 inch monitor with 1600+ horizontal resolution, you’ll end up with a website looking like a small block in the middle of the screen if it’s defined as 800 pixels wide. Ems or % are more open, but can muck with design and text flow. IE is just fine with pixels [unless the user wants to resize the page]. A site like yours, mostly text, will work fine with %. Ems are relative to font size. If you define your font as 22 points wide, one em will = 22 points.
You’re correct, IE won’t resize text properly if its size is defined in pixels. FireFox does ok. While this is bad in terms of usability for people who like large (or small) text, it makes some designers happy… those who don’t like users mucking with the appearance of a site.
You could simply define the font with fallbacks and not worry about defining size… then the browser will handle it based on the users preference.