A couple of years ago, Richard Rutter wrote Compose to a Vertical Rhythm, which described how web developers could use CSS to maintain proper vertical typographic rhythm when designing pages. The technique is fairly straightforward, requiring some basic math to ensure consistent margins and leading across all page elements.

One issue that many people face with this technique, is that vertical rhythm can easily be thrown off by non-text elements, such as images. To illustrate, here’s a sample page which contains text, images, a code block showing a horizontal scrollbar, and even a video. Notice how the text no longer lines up perfectly within the vertical grid lines after the first image. This is because the image is 240 pixels tall, which is not a multiple of 18, the line height used throughout the document.

One solution to this issue is to make sure your images always have a height that is a multiple of the line height being used by your document. Unfortunately, this is usually not practical for production sites.

Here’s some jQuery code that you can use in order to make sure your document keeps its rhythm:

$(function() {
  var lineHeight = parseInt($('body').css('line-height'));
  function balanceHeight(el) {
      var h = $(el).outerHeight();
      var delta = h % lineHeight;
      if (delta != 0)
      {
        /* For images and objects, we want to align the bottom w/ the baseline, so we
         * pad the top of the element. For other elements (text elements that have a
         * scrollbar), we pad the bottom, to keep the text within on the same baseline */
        var paddingDirection = ($(el).is('img') || $(el).is('object')) ?
                                              'padding-top' : 'padding-bottom';

        /* Adjust padding, because margin can get collapsed and cause uneven spacing */
          var currentPadding = parseInt($(el).css(paddingDirection));
          $(el).css(paddingDirection, currentPadding + lineHeight - delta);
      }
  }

  /* Depending on your content, you may want to modify which elements you want to adjust,
   * by modifying the selector used below. By default, we grab all img, pre, and object
   * elements. */
  $('img, pre, object').each(function() {
      /* Only works if we're manipulating block objects */
      if ($(this).css('display') == 'inline')
      {
          $(this).css('display', 'block');
      }

      /* Images need to load before you get their height */
      if ($(this).is('img'))
      {
          $(this).load(function(){ balanceHeight(this); });
      }
      else
      {
          balanceHeight(this);
      }
  });
});

The code is fairly straightforward. Briefly, what it does is add padding to the top or bottom of an element in order to ensure its total height is a multiple of the document’s overall line height. Here’s the same sample page as before, but this time using the script above.

Usage

You can use this script as-is, but you may want to change the selector used in the following line:

$('img, pre, object').each(function() {

The reason is that this selector is probably too broad for your page. You most likely do not want to adjust every single image on your page, just the ones within your main content block. On my page, I adjust any pre elements, because I’ve set them to overflow with scrollbars, which can alter the height of the code block and mess up vertical spacing just like an image.

Known Issues

I’ve only found two issues with the code, and they both affect Internet Explorer:

1. object tags don’t get adjusted (see the Vimeo video at the bottom of the sample page). This might be a jQuery issue, but I haven’t investigated it yet.
2. If you use unitless line heights, jQuery doesn’t retrieve the correct line height in IE. You can either modify the code and hard code a line height, or just don’t use unitless line height on the body element

Let me know if you run into any other issues.

I’m happy to introduce version 1.0 of my Dynamic Layout JavaScript library.

Dynamic Layout is a simple library that allows you to easily adjust page layout based on the current browser width.

The script works by modifying the class property on the body element, adding a new class name that will look something like bw-1000, where 1000 is one of the numbers in a predefined list of possible browser widths.

Unless you’re reading this in your RSS reader, you can see a live demo by resizing your browser window. I’ve also created a simple multi-column demo, which will display one, two, or three columns depending on your browser width.

To download, and for details, see the Dynamic Layout project page.

Over the weekend I spent some time seeing if I could replicate the functionality found in the excellent sIFR, using Silverlight instead of Flash. The result is Sistr. For the impatient — here’s a demo test page.

Usage

1. Download sistr.js and save it to your web server (or reference it directly from this site).
2. Create a zip file with the font(s) you wish to use. Upload this to your webserver as well (Silverlight will only use fonts that are retrieved via HTTP).
3. Add the following into your HTML page:

   <script type="text/javascript" src="sistr.js"></script>

4. In your CSS file, define a new class called sistr-replace (anything that starts with “sistr-” works). Here’s an example:

   .sistr-replace { }

5. Use the font-family property to set the font name and URL to the font files, enclose them in quotes and separate with the “|” character (e.g. font-family: "Fil's Font|filfont.zip"). Make sure you also specify backup fonts for users who don’t have Silverlight installed, like so:

   .sistr-replace { font-family: "FontName|fonts.zip", Verdana, Arial, Sans-Serif; }

6. Set the class property on some of your HTML elements to sistr-replace (or whatever else you used) and re-load. For example:

   <h3 class="entry-title sistr-replace">Hello World!</h3>

7. Your text should now be rendered using Silverlight.

Take a look at the demo test page as well.

Pros & Cons vs. sIFR

Pro:

• Simpler setup: All you need to do is include the sistr.js file in your page and edit your CSS — you do not need to edit any Silverlight or JavaScript code. sIFR is pretty easy too, but you need the Flash editing program in order to create a SWF file.
• Support for Transparent Backgrounds: sIFR provides partial support, but it’s not recommended within Firefox (I believe this is an issue with Flash).

Con:

• Lack of Silverlight Install Base: Silverlight is nowhere near as common as Flash.
• No protection for Font Files: In order to use a custom font with Silverlight, you have to have the font file available for download on a web server — you cannot embed it or protect it in any way. This means you must use fonts that you either created or are liberally licensed (public domain, etc).
• Immature: Both Flash and sIFR are much, much more mature than Silverlight and Sistr. There are many bugs that I have not sorted out yet.
• Many limitations: See below

Known Issues

• No support for line height: Limitation in Silverlight
• Must use absolute units for font-size in IE: Due to IE’s lack of a getComputedStyle equivalent.
• Occasional sizing issues: I think this may be a Silverlight bug, but occasionally text will get cut off in the vertical direction. Not sure how to fix it yet
• Font size doesn’t respond to user changes: Works fine if you reload though
• No support for :hover state
• No support for nested hyperlinks
• Text selection does not work: Not sure how screen readers react either
• Cannot support nested bold in Firefox: Works in IE though

Let me know if you find others — or want to help fix bugs!

I went to Adobe’s OnAir Seattle yesterday, which was a really interesting event that I’d recommend attending if you have the time. Unfortunately, I had to leave before the end of the day, but here’s a summary of the notes I took while I was there.

The Big Picture

Adobe’s goal is to let web developers can use their existing skills (HTML, CSS, JavaScript, Flash, and Flex) to create desktop applications. AIR (formerly Apollo) provides cross-platform installation and application updates, a local database, and a variety of new APIs for managing local resources (local file access, controlling window chrome, drag and drop, etc). The Adobe guys were clear that this isn’t about porting existing web sites onto the desktop — assets and web services will obviously be re-used, but the emphasis was on not needing to learn new technologies (just a few new APIs).

Interesting Tidbits / Nerdy Technical Details

• Installation: Applications are installed via a single .air file. Installed applications can be removed just like normal applications (i.e. via Add/Remove Programs on Windows, or by throwing the application in the trash on the Mac). An express install (which can bootstrap the AIR runtime) and detection is also possible via Flash.
• Application Updates: AIR will provide support for automatic application update checking and upgrading.
• HTML Rendering: Adobe chose the WebKit HTML engine (used by Safari and Konqueror) specifically because of it’s size and speed. Someone asked if they were considering moving to Firefox at some point, and they were clear that Firefox just couldn’t meet their size requirements for mobile.This cements WebKit’s position as the number three browser family (sorry Opera).
• PDF Support: Requires Adobe Reader 8.1 — unlike HTML and Flash support, the Adobe Reader must be installed separately (I’m not sure what happens if it’s not installed).
• HTML / Flash Integration: It looks like Adobe’s done a good job integrating the two — you can make script calls between the two, and there don’t appear to be any visual differences between the technologies. I’m not sure about PDF though, I’ll need to look into that.
• Script Engine: They’re using the Tamarin JavaScript engine, which is far faster than what’s in browsers today. They showed a demo of BuzzWord, a word-processing program built on Flash, which implements their own line layout and pagination APIs that run pretty fast thanks to the JS engine. The Mozilla team plans to use Tamarin in Firefox version 4.0.
• SQLite: This must be fairly new, because none of the talks or demos I saw were using the local database. Adobe did mention that they’re working with Google to make sure they’re API-compatible with Google Gears, which also uses SQLite.
• Native Windows: Can create native windows, or go chrome-less windows with transparency that give full-freedom (at the potential cost of consistency with other applications on that OS).
• Plugin Support: Currently only Flash and PDF can be embedded within HTML. Adobe says they’re open to feedback as far as other plugins (QuickTime was requested by a member of the audience).
• SDK and Tools: Adobe already has mature tools with the Flash authoring environment, Flex builder, and Dreamweaver. They making sure to adding support for creating AIR packages (which are ZIP files) in their existing products, lowering the learning curve for developers. Command-line tools for packaging AIR files are provided as well.
• Adoption Rates: Adobe made sure to mention how quickly new versions of Flash get adopted by users — they get 85% penetration within 9 months, which is quite impressive. Obviously, it’s unclear if AIR could get this
• Linux Support: Planned in late 2008. Adobe says they’ve been waiting for the latest version of Flash for Linux before they port AIR.
• Random Notes: Built-in support for associating file types at install time, don’t need admin rights to install AIR or AIR applications, events for regaining network connection, file dialogs, drag and drop support, use PNGs instead of dealing with .ico files, and Creative Commons licensing for the books.

MS vs. Adobe: My Take

This is the right strategic move for Adobe. They’ve managed to attack the biggest weaknesses of their chief competition, Microsoft’s WPF, by being cross-platform and leveraging existing technologies already used by web developers. Using existing technologies also means there are many mature tools for both designers and developers coding in HTML/Flash, which is not the case with WPF. Adobe made a good choice not trying to boil the ocean with a lot of new technology.

Granted, WPF’s target market is a bit different than AIR’s (there are a large number of WinForms developers already using .NET technologies), but for web developers the learning curve and lack of cross-platform support made WPF a non-starter (notice how much more interest Silverlight has recieved in the community). Obviously, there are still many areas where WPF is superior (3D and document layout, to name two), but I think AIR’s advantages more than make up for these drawbacks (from a web developer’s point of view).

Although still in it’s infancy, Silverlight will likely become the real competitor to AIR. Although it’s feature-poor in comparison to Flash, Microsoft’s clearly devoting a lot of resources to catching up quickly (notice the simultaneous release of 1.0 beta and 1.1 alpha — which surely required a lot of testing resources). Silverlight plays nicely with HTML and JavaScript, provides good language support (including trendy languages like Ruby and Python), and has a very fast script runtime as well. It already lets you go into full-screen, I don’t think adding more windowing APIs wouldn’t be a stretch. I fully expect Microsoft to move in this direction.

• Will now work correctly with the /%category%/%postname% and %postname% permalink structures (this was the top request).
• No longer need to manually update the permalink structure on install or uninstall.
• Fixed incompatibility with some installations of the K2 theme.

If the previous version works well for you, then there is no need to upgrade.

Download

Top Level Categories v1.0 (ZIP file).

Let me know if you encounter any new bugs or issues.

In this post, we’ll look at how each platform renders fonts at 9, 10, 12, and 14 points — sizes commonly used for reading. I’ve used three fonts:

• Verdana: The old standby, installed on many systems.
• ITC Cheltenham: A serif frequently used in newspapers.
• Gotham Rounded: A sans-serif that I happen to like.

For no good reason, I’ve placed the results in alphabetical order. First up is Flash.

Flash

Up until a few years ago, Flash used to render fonts poorly at small sizes. Most authors worked around this limitation by changing the type of anti-aliasing used when displaying fonts. Flash provides two anti-aliasing options, one for readability and the other for animation. Additionally, Flash also allows the author to disable anti-aliasing altogether, and use aliased bitmap fonts. Flash 8 introduced a new rendering engine that vastly improved the quality of small-type text.

At small sizes, the readability setting is (unsurprisingly) far superior to the animation setting. Here’s a sample of the readability anti-aliasing for Verdana at 10 point:

For the same font and size, the animation setting is quite ugly:

Although it creates clearly more readable results, the readability smoothing creates a strange coloring affect that can be pretty noticeable at small sizes. Here’s Gotham Rounded at 9pt:

On my monitor, the effect is subtle, but noticeable — I see a bit of color around the edges of the letters.

Flex / Apollo

Apollo (through Flex) has two different font rendering engines — one of which seems to be shared with Flash (the documentation is a little vague here, so feel free to correct me if I’m wrong). The other rendering engine has access to installed fonts, and is recommended for small type sizes — however the quality is quite bad. From my simple tests, it seems that the fonts are always aliased, producing the jaggy look seen below:

This aliased look is acceptable for some fonts, such as Verdana, that have reasonable bitmap representations at small sizes. However, for many fonts the result is unacceptable, such as this sample of Cheltenham at 10 point (from Flash set to bitmap, not Flex):

Except for extreme cases, it looks like it’s best to use the Flash font rendering system when writing an Apollo (or Flex) application. (Once again, I’m under-educated in the Apollo and Flex realms, feel free to drop some knowledge in the comments)

HTML

On my machine, the Firefox and Internet Explorer 6 both rendered extremely similar results. The Firefox rendering is shown below:

The lack of subpixel positioning destroys the serif font at small sizes. You can see the effect at larger sizes as well — here is Cheltenham at 14 point:

You can see the strange letter spacing in the first line — compare “Marketing” and “cross” to see the difference.

The sans-serif fonts fared better in the browser, with Verdana doing particularly well as it was specifically tuned for on-screen use.

Internet Explorer 7 uses ClearType for its font rendering, and should therefore produce results that are nearly identical to WPF.

Silverlight

Silverlight is the least mature of the platforms (since Apollo leverages both Flex and Flash). The 1.1 Alpha version that I tested unfortunately does not support for the Adobe CFF font format — meaning I was unable to test Cheltenham or Gotham Rounded. Silverlight doesn’t use the ClearType algorithm used by WPF, instead it uses gray scale anti-aliasing with gamma correction. The results are generally good, with the clear weakness being at small sizes. Here is Verdana at 9pt in Silverlight:

At this small size, Verdana looks a bit fuzzy. The effect is less noticeable at 10 point, but still there.

WPF

All text in WPF is rendered with ClearType — developers have no way of opting out of this (actually, there is a way, but it’s pretty awkward and not really well known). The quality of text at small sizes is impressive, here’s Gotham Rounded at 9pt in WPF:

It’s slightly fuzzy and a bit gray, but overall a bit better than the flash version.

Verdict

Overall, the results are pretty good. The only engine with poor results is the native Flex engine, but with support for Flash, there’s a clear, easy to use alternative at your disposal.

Although the browsers work quite well with standard web fonts (and any other specifically tuned for small sizes), they are not an acceptable choice for traditional print fonts — especially Serif faces (Internet Explorer 7 being the exception). Considering the lack of cross-browser font-embedding, this probably isn’t a problem for most.

Silverlight is still a baby in this space, and it shows (there’s currently no way to set line height, for example). The anti-aliasing looks pretty good at larger sizes, but is noticeably fuzzy at smaller sizes. Although it’s better than what most browsers provide, it still has a way to go before catching up to Flash and WPF.

The final two contenders are Flash and WPF — and it’s a close call when it comes to rendering. Here are three side-by-side samples for WPF and Flash. The first is Verdana at 9 point (all samples show Flash with readability anti-aliasing):

Although the Flash version has a nicer color, the WPF wins by a hair here, for being a bit smoother and less blurry (look at the “B” in “Branding” in the Flash version, third line from the bottom). Let’s move on to Gotham Rounded at 9pt:

Once again, Flash has stronger lines that WPF, but it’s uneven and has a bit of color fringing. Finally, let’s look at Cheltenham at 12 point:

This time, WPF is a bit darker than Flash. This one is really a toss-up and depends on personal preference. Flash is a bit sharper, but the WPF version is smoother and more consistent.

Overall, I think WPF has the edge when it comes to font rendering, although it’s quite close and could easily come down to user preference.

Next Steps

This analysis is a bit rough, there’s a bunch on my to-do list here, including:

• Testing FlashType in Flex and Apollo
• Testing non-CFF fonts in Silverlight
• IE 7, Mac OS, and Ubuntu screenshots
• More fonts

Also, the font rendering is just one aspect of a user’s reading experience. Obviously layout, performance, installation, and many other factors come in to play here. Subscribe to feed to make sure you don’t miss the next installments.

Raw Results

If you’re interested, here are the screenshots from each test application, in PNG format: fontrendering.zip (Zip, 500K)

How tall is Paris?

Answer correctly to receive your Pink Laptop

You’ve probably seen this genre of ad before, which offers free merchandise for a trivial task — of course, the ads always state that “Details Apply” in tiny text (I wonder how the FTC feels about these “details”).

As stupid as these ads are, they’re not much worse than the advertisements for escort services that you see in back pages of a free weeky — but you’d never see one of those next to a top story in the print edition of the New York Times!

Why not? Money, of course. A prominent ad in the print edition of the NYT is far too expensive to be purchased by the low-class advertisers — and even if it were cheap enough, the NYT’s higher-end advertisers (luxury companies such as Tiffany’s, who spend a lot of money to consistently advertise in the paper) would never allow their brand to be anywhere near an ad like that.

But it turns out that Tiffany’s and other high-end advertisers don’t advertise on the web — because there’s no appropriate online advertising surface out there for them. This missing business causes two side-effects:

1. The scummy advertisers aren’t priced out of the market
2. The Times, faced with low-revenues in their online edition, can’t be as choosy when it comes to advertisers

Broader Markets are Good

One could mis-interpret my previous statements and say that I’m an advertiser snob, looking to price out the little guy. This, of course, is false. Even with way less than ten percent of the advertising market, the Internet has brought more advertisers into the market — this is undoubtedly a good thing.

Large publishers, like the Times, can (and should) still cater to the little guy. Unlike the print version, an online edition need not display the same advertisement for all readers in perpetuity. A digital publication can sell limited run, or niche-targeted advertisements at a lower total cost and higher visibility than they could in the one-size-fits-all print edition. In fact, I’m certain they already do so.

Publishers like the Times have to start being picky and demanding a certain level of quality from their advertisers. In the print world, it’s clear that advertisements are part of the content (look at any fashion magazine if you’re in doubt) — this attitude needs to extend to the digital realm.

Moving toward a better future

At Mix, I showed some sketches of what online Magazines can become. Roger Black and I are working to create higher-end content experiences that won’t dilute the brand of luxury advertisers. Rest assured, you won’t be asked to punch a monkey.

It’s still early, so all I have to show are sketches — but there’s a lot of room for improvement in this space! I’m a bit surprised by the state we’re in today, because so many of today’s mistakes come from ignoring the lessons learned during decades of print publishing. Of course, digital is a different medium than print, which means that we need new plenty of new paradigms in order to succeed — but that just makes it all the more exciting!

Update: Other Voices

After writing this post, I found P.J. Onori’s excellent (and similarly-titled) article The Sorry State of Online Advertising — which I recommend. He makes similar points (and posted them first, so he wins):

I would argue that the sheer number of advertisements some of these sites have on their site is evidence that the current ad model is not working. Instead of thinking of more original, symbiotic and user-friendly forms of advertising, most site creators have subscribed to the “more ads means more revenue” philosophy. This current relationship between the site creator and advertisers is much like a building landlord and a renter. Space is offered to the advertiser and other than the exchange of money, there is little to no relationship between the two. Under this model, the landlord attempts to rent out all the space to whoever offers money. The problem with this model is that if the landlord just rents out rooms to anyone without any discernment, the landlord’s property could be quickly destroyed by the renters. Meanwhile, the apartment building is in shambles and no one is interested to look at the space, much less rent it. Similarly, if a website does not carefully choose its advertisers, the web site could shortly be a ghost town. An interest in short-term gains can ultimately disenfranchise a site’s users to the point that they do not come back. Guess what, advertisers are going to drop you like a bad habit once you are not giving them what they want - click-throughs and revenue.

Another article worth reading is The Devil & Online Advertising by Darius A Monsef IV. Here’s an excerpt:

Do you know why you only see those terrible, low-budget ads on your local television stations? Because it costs too much for those guys to hock their “Super-Mega-One-Day-Only-Sales-Extravaganza!” on national television. When the price point to advertise online is in the pennies per CPM, then you’re going to end up with low-quality advertisers.

Unfortunately, Nick’s panel didn’t work in my application because he was modifying the Children collection in his code, which is a big no-no if you want to support databinding (e.g. in order to use it as the ItemsPanel within a ListBox). I ended up writing my own version, adding a few features that were required for the project.

At Mix, I promised Nick I’d post and get him the fixed source code. You can download the source (plus some basic tests) in the first version of the Fortes Panel Pack (currently “Pack” is a misnomer, since there’s only one — but I have a few more waiting to be packaged for external consumption).

Features / Release Notes:

• All the features of Nick’s original
• Support for data-bound children
• Special support for Expander children: Detects collapsed Expander elements and treats them as fixed-size elements
• Bug: Support for Expander within a Template does not lay out correctly on the first pass — see the DataBoundPanels.xaml file in the sample project. Resizing the window, or any other action that causes a relayout, fixes the issue. (I’ll fix it in the next release)

Unfortunately, the production quality of the video isn’t very good. The video shows only the projection feed, which was fairly static except for about 25 minutes worth of demos by myself and Tom Bodkin. Also, the projector in the room was running at 1280 by 720 pixels, which was then (stupidly) stretched to a different aspect ratio for the video. I’ve included a few non-stretched screenshots from my demo below:

If you don’t feel like watching the video, Tim Anderson has written a good summary of the panel.

During the session, I showed a demo that myself and Roger Black (amongst others) have been working on in the past couple of weeks. It’s a rendition of the English-language version of Reporte Indigo, a Mexican online weekly magazine currently done in Flash. Our goal was to show some of the directions we see online reading experiences moving toward: richer, branded layouts that look good across a variety of screen dimensions, integrated media, richer advertisements, and continued increases in community-driven features. My big fat mouth has more to say about this area, but that will have to wait until

Here’s the abstract:

Is it really possible to make online narrative content glamorous? Smart designers are complementing their traditional strengths in branding and narrative with technologies such as WPF to create highly flexible, readable and vibrant online media products. See how designer-delivered digital media can work on-and-off-line, in-and-outside the browser. Envision next year’s portal digital world and how can you become part of it. For producers of newspapers, magazines, and TV content, this is the next Web.