Ah! fonts and the internet. A quandary that's plagued many a designer; the internet's lack of typographic expression. Or... so it would seem.

Prior to HTML5 if we wanted to achieve any kind of typographic freedom on the internet we had to resort to some pretty intricate artistry to make it happen. Technologies such as sIFR and, in the case of PHP, the GD Library and an ability to render imagery on the fly.

Then came along HTML5 and the renewed @font-face attribute for CSS. A lantern, a beacon for all the enthusiastic designers out there eager to splash fonts galore into their artwork, but... there's still a small hurdle to overcome. HTML5 isn't officially released and some browsers (yes you Internet Explorer) have limited support.

As quickly as the HTML5 cheer crescendoed it simmered down into cacophonous boo-ing!

That was until this little gem cropped up. The Google Font API initiative.

Having some foresight Google have recognized that, even with the eventual release of HTML5, this new typographic wizardy is going to rely on fonts being available to the browser. No one is really sure how HTML5 is going to play out in terms of font-licensing so Google have decided to setup the Google Font Directory. A repository where budding font-designers can showcase their work and potentially make some money from donations.

Logically Google have taken it a step further and introduced a nifty little API. By simply including something along the lines of

<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Font+Name">

in your code you can request any font in the directory to be downloaded into cache.

As most CSS folks will tell you. Once a font is available locally on the machine you are completely at liberty to do things like

CSS selector {
  font-family: 'Font Name', serif;
}

In your stylesheet. Ta Da! Let the typographers rejoice! Naturally you can arrange your font-stack to gracefully degrade; and eventually fall back to one of the systems default fonts: serif, sans-serif, cursive, fantasy or monospace.

It's supported in all current browsers; noteably. IE 6+, FF3.5+, Chrome and Safari (Which means it also works on 'droid and iOS).

Technical Considerations. Not to many; except the possibility of increasing page-load as your users try to download a dozen typefaces:

If a page uses web fonts, then the font files have to be downloaded to the site visitor's computer before they can be displayed initially. The font files are served compressed for a faster download. After that initial download, they will be cached in the browser. As the Google Font API becomes widely used, your visitors will be likely to already have the font you're using in their browser cache when they visit your page.

In general, however, you should keep an eye on the size of the font files you are serving. Also be aware that using web fonts may result in the browser making more HTTP requests than would otherwise be necessary.

Compared to using images to display a lot of text on a page, web fonts are likely to enhance the performance (and maintainability, and accessibility) of your page. In other situations, however, they might add to the overall weight of your page.

Further Reading

• Google Font API - Getting Started Guide

OK; this was another one of those WTF-CSS moments after spending a couple of hours scratching heads trying anything and everything.

A website currently in production; we're doing some X-browser testing and a very odd scenario kept occurring in IE7 only. The website looked beautiful in everything except IE7 (usually it's IE6 we're cursing at). For some reason DOM elements kept 'vanishing' even though they were there!, there in the HTML. We thought we were going mad!

A cursory glance at the 'vanishing' elements in the IE Developer Toolbar > DOM Inspector highlighted their "hasLayout" property, and it's "-1" value (not set) which led me to a solution, but I'm still scratching my head as to why!?

Firstly the solution in-case anyone has Google'd looking for the same answer:
For IE7 ONLY, to make your vanishing elements magically re-appear, applying ONE (or more) of the following properties to the 'vanishing' elements will force those DOM elements to have a "hasLayout" value of "1" (true), in affect forcing them to render. HOWEVER in typical Microsoft fashion some of these CSS attributes have UNIQUE values that really do not stick to any x-browser standard. (Typical M$! *evil*).

• display:inline-block
• height:{any value}
• float:left (or) right
• position: absolute
• width: {any value}
• -ms-writing-mode: tb-rl
• zoom: {any value}

Secondly, the theory for anyone interested:
From what I can make out; and I'll probably add to this as I found out more, but from what I can make out, under a given set of circumstances absolutely positioned elements near floated elements will 'cause them to 'disappear'. This article (http://www.brunildo.org/test/IE_raf3.html) exploring this scenario led me to another article (http://msdn.microsoft.com/en-us/library/ms533776%28VS.85%29.aspx) at the Microsoft Developer Network (MSDN) and ultimately a solution. By forcing hasLayout to 1 you're telling IE that this element hasLayout, has form, shape and substance. In other words don't hide the damn thing! I'd definitely welcome any comments as to WHY this happens because it's one of those incidents where the solution works but you don't quite understand the underlying principals behind it.

HTML is a structural semantic Markup Language. HyperText Markup Language, in it's fuller term, was first prototyped in 1980 by Tim-Berners Lee an independent contractor working at CERN. Since it's initial launch in 1989 it has gone on to help define the internet we see today driven largely by the W3C consortium.

The easiest difference to explain is the relationship between HTML and DHTML. Dynamic HTML is a descriptive term for collating various client-side technologies together. HTML can combine Javascript, CSS and the DOM (Document Object Model, a cross platform convention for representing objects in HTML, XML and XHTML). Together these technologies form Dynamic HTML. It is a way of describing this collection of technologies and it's association with HTML.

The differences in XHTML are a little more involved. HTML is based on the Standard Generalized Markup Language model (a descendant of IBM's Generalized Markup Language). XHTML on the other hand is based on an XML model. XHTML can be thought of as the intersection of HTML and XML in many respects. XHTML is still very immature, but the next landmark is actively being worked on; HTML5 and XHTML5.

True XHTML (XHTML2.0) hasn't seen wide adoption. Most developers tending to stick to XHTML1.0 which offers better support for transitioning traditional HTML.

One of the major advantages though, of true XHTML, is speed of parsing (processing information). XML(XHTML) based parsing is quick than traditional SGML(HTML) parsing, but unfortunately not all browsers provide mature support for this. You guessed it. Microsoft's Internet Explorer is one of them.

To quote HTML inventor and W3C chair Tim Berners-Lee's Blog :

The attempt to get the world to switch to XML … all at once didn't work. The large HTML-generating public did not move … Some large communities did shift and are enjoying the fruits of well-formed systems … The plan is to charter a completely new HTML group.

Personally I think we'll see wider adoption of HTML5 than true XHTML.

True XHTML brings about a whole new way of thinking when it comes to writing presentational code. Standard HTML elements that alot of developers are used to are replaced.

HTML forms are replaced with XForms, HTML framesets with XFrames and traditional DOM events with XML Events. HTML5 offers less of a "break from the norm' " and I think, from either lack of understanding, a willingness to self-educate, or promotion of XHTML, true XHTML will not see as wide an audience as HTML5.

We'll see.