More on @font-face

Since Paul Irish's great effort on a bullet proof syntax, I have seen a lot of excitement about @font-face and the long looked after cross browser web fonts.

It is taking shape and more people are putting extra thoughts in it to make it reliable, usable and ensure all the craze is not going to turn into a wild usage and broken web pages:

• So, Paul Irish kicked the ball with a nice CSS declaration that makes @font-face accepted by all browsers, without unnecessary HTTP requests, no scripting and not event a conditional comment,
• Steve Souders went deep into the performances issues raised by @font-face,
• User Agent Man took the aesthetic and legal point of view, and expressed some concerns about bad practices,
• Font Squirrel provides the fonts and the tools,
• and Robert Accettura found some good hacks, already, @font-face as spam blocker and on using base64 encoded font data in url.
  

Now, we are almost ready for spreading the use of web fonts, keeping these considerations in mind:

@font-face is supported by:

• IE from version 4 (!!!?) using EOT converted files
• Firefox from version 3.5, Safari from version 3, and Opera from version 10 using TTF or OTF files
• Chrome, being Webkit based, supports it but... it's been disabled. It is possible to force Chrome to accept @font-face by feeding it SVG font files. Hopefully it will not be long before they join in the rest.

This "apparently" covers about 80% to 90% of all browsers in use.

Font Squirrel provides ready-made packages including EOT and TTF (or OTF) files. They also run an on-line converter to create you own package, this time including a SVG version of the font. The great advantage with them is that they took care of checking the licenses so you do not have to.

The alternative is to use command line converters:

• ttf2eot at http://code.google.com/p/ttf2eot/ (Windows/Linux)
• ttf2svg using Batik (Java)

Note 1: SVG font files often embed to many characters, ending up being twice as big as a TTF file. You can use the converter options to subset it and reduce the file size. I use the following options with Batik for a reasonable extended western character set:

java -jar batik-1.7\batik-ttf2svg.jar myFont.ttf -l 0 -h 255 -id myFont -o myFont.svg

Note 2: I found the Line Feed character is not present in the converted SVG fonts I used. Chrome, instead, displays the "missing-glyph" entry, which is usually very ugly. To fix that, you can edit the SVG file and add the following entry:

<glyph unicode="&#x0a;" glyph-name="uni000A" horiz-adv-x="560" />

where the horiz-adv-x value is equivalent to the "space" character one.

Note 3: The ID specified in the <font> tag of a SVG font is necessary for the CSS declaration.

Also:

Font files are heavy and many (four separate files if you want to cover regular, bold, italic, bold-italic): optimize them, subset them, cache them, use gzip where possible and limit the number of fonts on you pages (on a design point of view, it is better anyway).

FOUT (Flush Of Unstyled Text) is inevitable for now: it can be improved though, by following the above recommendations.

Not all fonts, even free, can be legally embedded in a website: check the licenses.

Internet Explorer ("Again!" I hear you say) can be a bit reluctant as discovered by Steve Souders (with a bit of my help, I must proudly say): @font-face should come before any <script> tag or IE will hang up, displaying nothing until the font is loaded!

Not all fonts are suitable for main content: a font can be very pretty in 30px but could be difficult or even painful to read when used over 10 paragraphs at 12px. Webkit browsers will usually make a good job at anti-aliasing text, IE and Firefox are a bit more lazy. If the font is of good quality, the result can be pleasing: test and chose carefully. I found Cantarell to be "quite" suitable for content text. If you like it, you can download the package I prepared (all variations, fixed SVG)

You need to define four variations of the same font if you want to use text styling (bold, italic): IE and Opera will generate their own (approximative) interpretation of bold and italic from the regular font. Firefox and Webkit will need properly declared variations so you can use <b> and <i> tags or CSS "font-style" and "font-weight" properties. IE and Opera will also benefit from these variations as they are more accurate than the automatic approximations. Have a look at the code on my test page to see how I declared these variations.

Lastly, this is my own opinion: keep it fresh and simple. Do not over do it, too many fonts can mess up a design and become confusing for a reader. As a rule of thumb, one or two fonts for titles and headers + one clear and readable font for the content should be plenty enough.

Good luck.

Background-color inheritance in IE

I bumped again in this today, but took the time to find some workaround.

Someone did that to the main style sheet of the open source portal I am working with:


td {
background-color: #fff;
}


Since my application sets background-color on rows (tr), all my tables were white.

The workaround should be as easy as:


td {
background-color: inherit;
}


But, Internet Explorer is known for explicitly ignoring the inherit value when it comes to background and background-color.

What it does understand though is the "transparent" value. Transparent, in IE language, means the colour of the closest relatively positioned parent with a defined background-color.

Final workaround is then:


tr {
color: red;
position: relative;
}

td {
position: relative;
background-color: transparent;
}


{width: 100%; float: left;} and Crash!

during the stressful process of testing and finalizing version 0.3 of PageLayer I suddenly ran into the Internet Explorer bug of death! During a block "drag and drop", the browser happened to crash violently, randomly and with no more explanation than the terrible "Internet Explorer has encountered a problem and needs to close..." message and an obscure reference to MSHTML.DLL

This is probably the worst thing that can happen to a web developer and I felt rather depressed at this point.

After several hours of desperate googling, testing, code commenting and the usual swearing that comes with that sort of event, I narrowed the problem down to a CSS file. That was one of the most frustrating bug hunts I had to do for quite some time: commenting CSS declarations and testing for several minutes every time, to see if a random bug would appear, while not being sure if it was fixed or just not happening. Grrrgh!

The problem lay in a class that gave a width of 100% and a float left property to my demo site's footer. I found some people talking about this, after I found the problem myself but it does not appear to be a very well known problem. The crash occurred when dragging blocks around in PageLayer, slightly changing the width of the main DIV container. Apparently, IE could not cope with this variation and adjust the width of the floating footer.

It's fixed now but I caught myself remembering the good old time of tables.

Floats Wrapping Priority - Internet Explorer vs Firefox

I ran into this problem while trying to make the PageLayer toolbar to behave properly.

The toolbar is a collection of float left divs containers (toolsets) embedding other float left divs (buttons / links). In a way, it has an onion skin structure: floats inside floats inside ... floats.

The problem is, as you can see in the screenshot, about priority: Firefox makes the outer divs wrap first (what you expect), Internet Explorer makes the inner divs wrap first (what you execrate).

I could not find much help online as it appears not to be a very well known problem (?).

The (very bad) solution I have got so far is to "clear right" the innermost divs which has for effect to make the containers (toolsets) to wrap properly but to lock the cleared divs: they do not wrap anymore in IE.

As anyone worked out a good solution for this problem? I'd like to hear about it!