Don't Let HTML5 Become the New DHTML

This photo represents some of the technologies (pint glasses) that HTML5 (t-shirt) is thought to encompass (drink). The horror of that concept is represented by the hands (defensive wounds coming).

I had the pleasure of sharing some pints with Bruce Lawson and Chris Mills last week in London. While discussing what bands are emo versus punk rock and during an exchange of favorite phrases to refer to the chronically daft, we touched on HTML5 and its perceptions a bit.

This thought process was rekindled just this week when I got in a discussion with a not-very-technical manager of web projects who insisted on mobile support and decidedly CSS3-based styling by implementing HTML5. The key here is the insistence on using HTML5. For a little context, we use HTML 4.01 Transitional for our projects. It's a valid and complete specification. It allows us to use things like WOFF, CSS3, AJAX, support mobile devices and so on.

I understand that many have co-opted "HTML5" as a brand for a suite of new technologies (most of them even from the W3C or WHATWG). I do not accept that, however, because it confuses the point when it comes time to make choices about technologies. This is a battle I have already fought repeatedly back when DHTML (and IE4!) became the rage and I had clients asking what technologies I would use to build their pages — insisting in advance that it be DHTML. I could explain that DHTML was just a terrible term coined to mean HTML4, CSS and JavaScript, but clients didn't care. It didn't matter to them. Good for them.

For developers and the people that manage them, including those who write on these topics, I have a different expectation than I have from clients. Allowing HTML5 to mean CSS3, geolocation, H.264, or any other technology just makes it harder on us who work in this space. A technology for a project should be chosen based on the goals at hand, not because a client insists on it because of a misunderstanding of a brand or because the press release will sound great when citing how cutting edge everyone is. Most importantly, a technology should not be chosen because of confusion over terminology — least of all when that term actually refers to one particular specification.

Please, fellow developer/writer/manager, make an effort to understand the technologies you reference so you do not confuse other developers/writers/managers, set incorrect expectations with clients, or generally demonstrate that you do not get it (especially if you want to work for me).

I have written on this extensively (with many links in each article that are to further details not written by me):

• W3C Clarifies HTML5 Logo Is for HTML Only
• HTML5 Finally Gets... a Logo?
• Google, Arcade Fire Confused on HTML5
• Google Doodle: Bouncy Balls Aren't HTML5
• HTML5 and CSS3 Confusion

If you are a writer (whether a journalist, blogger or analyst) then please take a few moments to read this useful and informational post: HTML5: notes for analysts and journalists (also not written by me). There will be a quiz. I don't know when, but there will be a quiz.

Now, to reveal how Bruce and Chris really felt about the HTML5 confusion:

Here are posts from both Bruce and Chris discussing this confusion, within the context of the new HTML5 logo muddying the point earlier this year:

• On the HTML5 logo, by Bruce Lawson on January 18, 2011.
• HTML5 logo: be proud, but don’t muddy the waters!, by Chris Mills on January 18, 2011.

Two Advent Calendars for Web Developers

One of the best parts of December, regardless of whether you believe in Christmas or that it belongs in December, is the fun of the advent calendar. As a kid I used to look forward to jamming a new piece of creche-themed chocolate (chocolate stablehand, anyone?) into my mouth every morning before breakfast. Now that I am a little older and can wait until after breakfast, I can also appreciate more evolved advent calendars.

24 Ways

Today marks the start of 24 Ways, an article-a-day site presenting web design and development posts from authors such as Dan Mall, Simon Collison, Richard Rutter, Cennydd Bowles, Sarah Parmenter, Veerle Pieters, etc. The site has been dispensing holiday nuggets ever December since 2005 and, based on past years (2005, 2006, 2007, 2008, 2009), this year will have some gems. Last year I had a write-up on 24 Ways as well (24 Ways Is Back Over 24 Days), and I can tell you that I have referred back to some of the posts often.

You can find daily updates right on the home page, or by following 24 Ways on Twitter (@24ways), Facebook and/or following the RSS feed in your favorite aggregator (full content of each article is in the feed).

This year 24 Ways is changing it up and also offering a printed annual with all the 2010 articles with all the proceeds from the sales to be given to UNICEF. The printed version of 24 Ways is only on sale during December 2010 (for £8) and will be printed at some point after that. You can read more and place an order at the 24 Ways Annual site.

Adfont Calendar

Fontdeck has created its own advent calendar, or its Adfont Calendar (see the image above). Each day a user can select the appropriate "drawer" to access another free web font special. Here's the cool part about it — these are web fonts.

Before you get too excited, it's clearly a sales promotion, but at least you get to try out some new typefaces and enjoy a discount to buy the whole thing. According to Fontdeck, all of their web fonts are free to trial for up to 20 visitors, but the fonts in the Adfont Calendar are also free to upgrade for use on a web site with up to 1 million page views. You will need to sign up for an account and provide Fontdeck with the URL of the site on which you will use the typeface. Once you do that, Fontdeck provides you with code to link to the CSS file and the appropriate CSS to use in your site.

I signed up for today's free font, Museo 900. All I had to do was create my account and then click the big red "Purchase font licenses" option. Since it's a $0 annual license, I wasn't too concerned about clicking the button (but I shouldn't count on it lasting past December 1 of next year). I was presented with a block of text that, comfortingly, read:

Thank you! We've upgraded this account to unlimited use – now all your site visitors will see the fonts.

And that's it. It looks like it's good to go. Now, today's offering isn't exactly the typeface I would choose for my site, so I will be visiting daily to see what other typefaces open up this month.

If you are really itching to play around with web fonts and want more options, check out the article I wrote in July, Trying Google Font Previewer.

Trying Google Font Previewer

I'm going to make the assumption that if you are reading this you have at least a passing interest in typography on the web and have heard about Google's new font preview tool. There are already plenty of articles talking about how easy it is, how Google hosts the typefaces, how licensing isn't an issue, and so on. Some of them are linked at the end of this article, so go read up. As such, let me just dive right into the piece I find most interesting — the implementation.

I started to play around with Google Font Previewer by dropping code samples onto my development site. I tried to see how many typefaces I could embed, how I could mesh the code into my site, how easy it would be, and how it would look in different browsers. The screen shot below (from Google Chrome) shows my site with three of the typefaces in place: Molengo for the overall copy, IM Fell DW Pica SC for the headlines, and Reenie Beanie for the banner text with my name. You won't see this on my live site because this is, after all, only a test and I am not writing a ransom note.

In order to use these typefaces I needed to drop three references to the Google typefaces into the head of my document (one for each typeface):

<link href="//fonts.googleapis.com/css?family=Molengo:regular" rel="stylesheet" type="text/css">
<link href="//fonts.googleapis.com/css?family=Reenie+Beanie:regular" rel="stylesheet" type="text/css">
<link href="//fonts.googleapis.com/css?family=IM+Fell+DW+Pica+SC:regular" rel="stylesheet" type="text/css">

From there I simply found the appropriate selectors in my CSS file and added the following styles (you'll note that I edited them heavily from what the tool provides):

body {
  font-family: 'Molengo', Trebuchet, sans-serif;
  font-size: .82em;
  font-weight: 400;
  word-spacing: -0.1em;
  line-height: 1.6em; }

h1 {
  font-family: 'IM Fell DW Pica SC', serif;
  font-size: 25px;
  text-shadow: 2px 2px 2px #333;
  line-height: 1em; }

#Banner p#Title {
  font-family: 'Reenie Beanie', serif;
  font-size: 100px;
  font-weight: 600;
  text-shadow: 4px 4px 4px #333;
  line-height: 1em; }

You can see that I played around with font sizes (switching between using ems and pixels), font weight, drop shadows, and even adding an alternate font in case the user cannot see the selected typeface. I then loaded up my most current browsers on my Windows machine (my Mac and Ubuntu machines are hiding) and ran the site through each, comparing and contrasting. The image below shows a representative slice of the page with all three typefaces loaded in each browser. Click the image (or use whatever input device you prefer, such as your meatstick) to see the full-size screen shot. Browsers used in the test:

• Internet Explorer 8
• Chrome 5.0.375.99
• Safari 5.0 (7533.16)
• Firefox 3.6.7
• Opera 10.6

I noticed the browsers were generally consistent on the font scaling and weight, with minor differences in anti-aliasing and line-height. Shadows showed greater variance among the browsers. Opera seemed to have a whole different idea of font weight, size, and anti-aliasing, but wasn't so far out of the park that it was unusable. Most interesting was how punctuation was treated. Note how only Internet Explorer and Opera show the commas in the tag-line under my name, or after the word "project" in the first sentence. Chrome, Safari, and Firefox each lost the commas altogether. While I am comfortable with the other display differences, losing punctuation is a deal killer for me.

Overall, the Google Font Previewer is a great way to quickly select and style type, drop it into your pages, and get it done quickly enough to go get an ice cream before your Dallas reruns. However, take some time to clean up the CSS it provides so that it matches your site coding style and isn't full of unnecessary declarations (do you really need to define word-spacing if you aren't changing the browser defaults?). Consider adding other, standard typefaces into the list as back-ups. Once you've done that, make sure you fire up your newly-typographized page in a few different browsers and are comfortable with the results. Those punctuation marks can be a killer, so check those. Don't limit yourself to your own browsers, either. Go find some variety and give the page a spin in alternative browsers, older browsers, and even mobile devices. You just might find that you added a style that works well with current browsers, but blows up the version of Netscape 4.x sitting on your grandmama's old Centris 610.

Related

• New Google Font Previewer - Webfonts Easier and More Fun
• Google Font Previewer
• Test Drive Your Type With Google Font Preview
• HOW TO: Implement Google Font API on Your Website
• Google Makes Custom Web Typography Ridiculously Easy

Bulletproof @font-face Syntax (reprint)

Paul Irish has gone ahead and created a block of CSS that we can reliably embed into our pages that will import .eot and .ttf/.otf font files. In his article Bulletproof @font-face syntax, he breaks down the various options and their support, providing arguments for and against each. In the end, he provides what he considers the best method to declare your @font-face styles in your CSS:

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('Graublau Web Regular'), local('Graublau Web'), 
         url('GraublauWeb.otf') format('opentype');
}

If you can support (generate) WOFF or SVG typefaces, then he provides a slightly expanded block of code that can support Chrome 4 and Firefox 3.6 (neither of which has been released yet):

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('Graublau Web Regular'), local('Graublau Web'),
    url("GraublauWeb.woff") format("woff"),
    url("GraublauWeb.otf") format("opentype"),
    url("GraublauWeb.svg#grablau") format("svg");
}

Firefox 3.6 to Support Web Open Font Format

Mozilla's developer blog today posted that they have added support for the Web Open Font Format (WOFF) to Firefox 3.6. Firefox 3.5 gave us support for linking to TrueType and OpenType fonts, but this takes it a step further to support a format that is more robust for two key reasons:

1. WOFF is a compressed format, resulting in files smaller than an equivalent TrueType or OpenType font.
2. It avoids DRM and domain labels by containing meta data about its source, garnering support from typeface designers and foundries.

If you want to see this in action, you'll need to grab a Firefox 3.6 nightly build until the full release is out the door. If you should feel compelled to do that, the nice folks at Mozilla have provided a sample block of CSS that uses the @font-face rule to link to a WOFF font:

@font-face {
  font-family: GentiumTest;
  src: url(fonts/GenR102.woff) format("woff"),
       url(fonts/GenR102.ttf) format("truetype");
}

body {
  font-family: GentiumTest, Times, Times New Roman, serif;
}

Structured this way, browsers that support the WOFF format will download the WOFF file. Other browsers that support @font-face but don’t yet support the WOFF format will use the TrueType version. (Note: IE support is a bit trickier, as discussed below). As WOFF is adopted more widely the need to include links to multiple font formats will diminish.

If you are fortunate enough to have a build of Firefox 3.6 already up and running on your machine, go to a test page using ff Meta set up by the nice folks at edenspiekermann (if part of the name is familiar, Erik Spiekerman is the designer of the Meta family, and if the typeface is familiar, it's what we use at Algonquin Studios). The image below shows how that page looks in Firefox 3.6 using ff Meta (left side) and how it looks rendered in Internet Explorer 8 (right side).

Because IE8 only supports the EOT format, the blog offers some code to account for IE8 in the CSS. Because IE8 doesn't understand the format hints, it will parse the hints as part of the URL, resulting in requests to the server for files that don't exist. The end user will see things just fine because of the EOT reference, but your logs will show some odd 404s as a result of this technique. The Mozilla post has more details on this and some other issues. The code to do this:

@font-face {
  font-family: GentiumTest;
  src: url(fonts/GenR102.eot);  /* for IE */
}
 
@font-face {
  font-family: GentiumTest;
  /* Works only in WOFF-enabled browsers */
  src: url(fonts/GenR102.woff) format("woff"); 
}

The main Mozilla blog has a post today listing the supporting organizations with the following endorsement:

We endorse the WOFF specification, with default same-origin loading restrictions, as a Web font format, and expect to license fonts for Web use in this format.

Updates

• font_dragr: a drag and drop preview tool for fonts
• after Firefox 3.6 – new font control features for designers