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

Read More

Unicorn Validator

The W3C has today announced its brand new validator, named Unicorn for reasons they do not explain. The new validator combines four other validators into one:

Unicorn combines a number of popular tools in a single, easy interface, including the Markup validator, CSS validator, mobileOk checker, and Feed validator, which remain available as individual services as well.

W3C is inviting developers to submit their own modules for the validator to continue to expand its capabilities. So far Unicorn has been translated (localized) into 21 languages, and is hoping users can contribute more.

Unicorn's CSS profile validation includes the ability to choose warning levels to report and to choose a medium (all, braille, handheld, print, screen, etc.). The "Custom Task" allows users to choose among (X)HTML, CSS, MobileOK, and RSS/Atom. With this custom option, users can also choose a level of CSS (Level 1, 2, 2.1, or 3) in addition to other profiles (SVG, mobile, TV, etc.) and then again from a CSS user medium.

The report page has a much nicer way to display all the issues than previous validators, allowing users to collapse an entire section and showing icons and numbers corresponding to the count of specific error types within a section (2 errors, 3 warnings, for example). Each message also shows the specific line number and (if appropriate) character number of the error (warning, info alert) along with the corresponding message. Each section and message even has an anchor on it so you can link directly to any item for sharing issues with a team. Now if W3C could add a background color to the page (white would be ideal), then I wouldn't have to squint to see the results.

Give Unicorn a try and see what you think.

Read More

This, the F**k, Is Social Media Now

Yes, it's a tired title already. But it's based on the third installment of the popular What the F**k is Social Media NOW? slide show that's been recycling around the web again for the last couple weeks. As such, not including it here almost makes me seem like I'm clueless. Scroll down to see it embedded.

Back in October I linked the Social Media Revolution video from this blog after I spoke to a few hundred people about that very topic (social media, not videos). I made the poor assumption they had all seen it. Of course the video has been updated too, so I've embedded the May 2010 version below.

These both demonstrate to those not familiar with social media or its impact (or those who haven't been dragged kicking and screaming into it yet) just how far-reaching and influential it is as an overall medium.

In June, Read Write Web posted a story, Social Media Era Set to Peak in 2012, that I have heard social media naysayers and detractors reference completely out of context. First of all, nobody set social media to start its insane climb to ubiquity, and nobody can set it to peak, fall off, or get me a cup of coffee. It's a constantly moving target that is fed by the masses, not pundits and think tanks. The chart used in the article really speaks about the rise of terms more than anything. For example, "web 2.0" peaked back in 2007 on the chart. Which as a term, it did. As the core concept that spawned that term, it's more alive today than it ever was in 2007 — just look at the typical web site today to see how interactive and responsive it has become.

If anything peaks in 2012, it's the hype about social media, not the actual practice. You may no longer be forced to look at Twitter logos on drink boxes and Foursquare badges on shower stalls, but social media as a concept has already infiltrated the web and our society and isn't going away. It will simply become expected as a part of everyday life.

The article does eventually state that social media adoption may peak. I think it misses the point, getting mired down in the current technical implementations and forgetting that once everyone is using it, there will be no more need for adoption. It will be everywhere.

Ok, enough of my ramblings, check out the eye candy...

What the F**k is Social Media NOW?

View more presentations from Marta Kagan.

Now go tweet how awesome this post is. Srsly.

Read More

Opera Rep Provides HTML5 Overview

Patrick H. Lauke is the Web Evangelist at Opera Software and ran the Accessibility Task Force for the Web Standards Project (WaSP). Last week (July 13) he gave a talk to the Institutional Web Management Workshop on HTML5. He lead viewers on a general history of HTML5, through an overview of the specification, and then plans for the future.

Slides from his presentation have been posted, along with a video of the entire presentation. Sadly, watching just the slides means you miss out on his narrative, and watching just the video means you miss out on the slides. That's why I've embedded both here. Because I had to scale them to fit in this layout, you may want to see the originals of each and view them side by side (links below).

His slides include code samples and URLs to check some of them out on your own. Even if you can't get the video to work, spend some time perusing the slides (especially slide #4, from Bruce Lawson, which shows what HTML5 is not). If you can see the video, stick around for questions at the end.

HTML5 and friends - Institutional Web Management Workshop 2010

View more presentations from Patrick Lauke.

The video is about 45 minutes and is peppered with lots of good insight. For example, he frames HTML5 as an extension of HTML4, providing more options and features. He points out that valid HTML4 or XHTML1 sites don't need to be re-coded, something that many web novices worry about and web jerks may try to trick clients into doing. He even discusses his own opinions on new elements and features, such as article and video path obfuscation (to keep people from bypassing YouTube-style overlay ads).

Source:

• IWMW2010 - Patrick H. Lauke - HTML5 and friends (July 13, 2010) (watch the video, or download it in various formats).


• HTML5 and friends - Institutional Web Management Workshop 2010 (the slide show from the talk).

Read More

W3C Cheat Sheet Now Includes HTML5

Back in November, the W3C released a handy tool aimed at helping developers quickly access information from various W3C specifications (W3C Cheatsheet for developers). The features were pretty straightforward:

This cheatsheet aims at providing in a very compact and mobile-friendly format a compilation of useful knowledge extracted from W3C specifications — at this time, CSS, HTML, SVG and XPath —, completed by summaries of guidelines developed at W3C, in particular the WCAG2 accessibility guidelines, the Mobile Web Best Practices, and a number of internationalization tips.

The author has had many requests to add information about all the new, changed, obsolete and removed elements and attributes in HTML5 by highlighting them (and including the new ones) throughout the application. Today he has released the updated version of the application (HTML5 in W3C Cheatsheet) with those changes.

Now when you look up an HTML element or attribute, the results will indicate if the element is different in some way in HTML5 than it has been in the past. Optimized for mobile use, the slim interface makes for a pretty lightweight quick reference tool should you have any questions and find the W3C specs a little heavy to read through.

The cheat sheet also includes sections for mobile web best practices, accessibility (WCAG 2.0), internationalization tips, and even a small section covering common character codes. Most of the content includes links to the relevant W3C specification for further reading. All the data comes from HTML: The Markup Language Reference. Try it out and see what you think:

• W3C Cheatsheet for Web Developers

Read More

Working Around CSS3 Hacks

Until CSS3 is a final specification, we can expect to see browser makers attempting to implement some of the ideas on their own, sometimes with a nod to the forthcoming spec and sometimes without a clear correlation. Given the pressure for browser makers to claim support for a CSS3 feature as soon as possible (Does Your Browser Really Support HTML5 and CSS3? and HTML5 and CSS3 Confusion), these implementations aren't always complete or terribly close to what the final specification will require. If you're the kind of developer who just cannot wait for the W3C to wrap things up (and they still haven't finished CSS 2.1: CSS 2.1 Still Not Final), then you probably want to try your hand at using these new features, at least implemented by the browser makers. Take some time to read up on some best-practices articles that can save you a lot of time down the road as you have to re-factor your code.

In late June the article Stop Forking with CSS3 showed up on A List Apart and promoted the use of a JavaScript library over browser-specific prefixes (vendor prefixes). The author felt that the pre-pended CSS styles (such as -moz, -webkit, -o, and -khtml) were just the modern form of CSS hacks we've been using as patches through a decade of shoddy support from browsers. I am not a fan of using client-side script to make my CSS (or HTML) coding easier — I don't like to put the processing burden on every end user instead of simply writing more code. Others agreed, as this sample comment (from Bruce Lawson) highlights: vendor prefixes are a feature, not a bug

Bruce Lawson proposed his own approach in early June, Writing cross-browser, future-proof CSS 3. He argues that developers need to learn the standards in the specification and include them in the code, regardless of browser support. Then a developer can add the browser-specific hacks on top of that. This way when support for the standard emerges, no code changes are necessary. As browsers start to drop support for their browser-specific hacks, still no code changes are necessary. This is valuable for contract work when your client pays you to develop and deploy a site and months later the rules change. Now you don't get a panicked phone call about changes to the site appearance and you don't have to incur expense (yours or the clients) to fix your code. Some of the comments on the post discuss ways to separate and format the browser specific styles for later removal.

Earlier this month Eric Meyer weighs in at A List Apart with Prefix or Posthack. Here he suggests that browser-specific prefixes are the best way for browser makers to introduce new support. As the specification and/or the support is/are finalized, then browser makers should drop the prefixes. As developers, these prefixes are clues that things are still in a state of flux. At the very least, if implementations differ dramatically, it's far easier to include a prefix to specifically target each browser than to look for hacks or write browser-sniffing scripts.

Loathe though I am to write any browser-specific code, I endorse the approach outlined by Eric Meyer. Add in some of Bruse Lawson's suggestions (such as ordering the prefixes in alphabetical order) and you should have future-friendly CSS that doesn't exist solely at the whim of browser makers, but still allows you to play with these new CSS toys.

Read More

CSS 2.1 Still Not Final

We all know that CSS3 is not final, nor is HTML5. What you may not know is that the CSS 2.1 specification is also not final.

CSS2 became a W3C recommendation on May 12, 1998, over 12 years ago. Since then the CSS Working Group has been developing CSS Level 2 Revision 1 (CSS 2.1) to correct errors and omissions from the original CSS2 specification. In fact, the CSS2 specification directs people to the CSS 2.1 specification as the de facto current version. CSS 2.1 is a Candidate Recommendation, and has September 8, 2009 referenced as the date of the specification.

The W3C has a slightly confusing progression of a specification before it is considered a "standard." There are essentially four steps:

1. Working Draft (WD): This is the first time a proposed specification is shown to the public and open for comment.


2. Candidate Recommendation (CR): Significant features are mostly locked and feedback is requested in how to implement the standard.


3. Proposed Recommendation (PR): The specification has been submitted to the W3C Advisory Council for approval. Changes at this point are rare.


4. W3C Recommendation (REC): The specification is final and endorsed by the W3C. This is what the general public considers a final standard.

To clarify, the CSS 2.1 specification is in the second of four stages. For context, the HTML 4 specification was approved on April 24, 1998. The HTML 4.01 specification was approved on December 24, 1999. Between those two versions, little more than a year and a half passed. To give another example, CSS3 is an amalgam of many different modules, some of which are still working drafts, while one (Selectors Level 3) is already a proposed recommendation (third of four steps). What this means is that some aspects of the next level of CSS are already moving along regardless of the status of CSS 2.1

When you look at the names of the editors working on CSS 2.1 (Bert Bos, Tantek Çelik, Ian Hickson, Håkon Wium Lie) and compare them to the names on the CSS Selectors Level 3 proposed recommendation (Tantek Çelik, Elika J. Etemad, Daniel Glazman, Ian Hickson, Peter Linss, John Williams), you'll see some crossover. You may even recognize one of those names (Ian Hickson) as prominent in the WHATWG, working on HTML5.

The CSS Working Group recently (June 30) posted an update on CSS 2.1. Here are some of the salient points:

[G]iven the recent changes in the spec - we resolved a lot of issues some of them pretty complicated - we may have to go back to Last Call Working Draft and then back to [Candidate Recommendation] again. That's not a problem and can be relatively fast.

From that statement, the 2.1 specification may have to slide back a step before it can advance.

The W3C relies on a functional Test Suite before it can submit a specification to the next step, this is their expectation on the timing as a result:

[T]he Test Suite and the [Candidate Recommendation] should be available at same time and that time should be, as planned by the WG, after the summer. That should leave us enough time to reach Proposed Recommendation before the end of the year, as expected.

The Working Group does acknowledge that future CSS specifications hinge on what they are doing here:

[CSS] 2.1 must be released as a Web Standard because that's one of the current cornerstones of the architecture of the World Wide Web. We cannot make the next steps, CSS 3 even module by module, happen without 2.1 before.

I read that as a timeline on the soonest that CSS3 can move ahead as well, which is essentially no sooner than the end of 2010.

Update: October 8, 2010

I have been called out! HTML5 guru and all around odd bird has "referenced" me in his latest blog post:

CSS 2.1 “not ready for use” says journalist

Update: June 7, 2011

13 years on and CSS 2.1 is now an official recommendation. Read what I wrote when that decision cam down: CSS 2.1 is Finally Final

Another Update: October 14, 2011

Alexander Ovsov of Web Geek Science offered to translate this post to Romanian, and my ego could not resist. Go learn Romanian and read his translation:

CSS 2.1 nu este încă definitivă.

Read More