blog home

Text vs. Image

Posted by Jen in coding front-end on December 6th, 2010

fontsDifferent fonts have different personalities. Properly using fonts to your web page will give your web page a vivid look, and will help your audience understand the message that you are trying to send even before they start to read the content. However, most of the great-looking fonts are non-standard fonts that are not installed to the computers of all your audiences. Special font displaying has been a big headache for all web folks in the past decade.

As I am just finishing up a project which involves with special fonts, I would like to share my hands-on experience in this area. Methods are listed below with pros and cons that were found from my latest experience. Anyway, after some research, you will find there are multiple ways to implement special fonts on the web pages. To summarize all these different methods, these are the two main ones - using text and using images.

1. Text method

This is a very appealing one. Thanks to the innovative JavaScript / CSS3, now we can show all special fonts by just typing in the text to the HTML code. Under this text display method, there are also multiple implementation ways, all of which need external files (javaScript files) though. Two of them I have been using are Google API and webfonts’ fonts-for-web tool. Both of them work great!

pros: This is so obvious -

1. easy to maintain. To update the text you don’t need to use any other applications/tools, all you need to do is just to pull out your HTML and change the text in there.
2. Since it’s text, the page load is minimized. Comparing to image, text on HTML page loads much faster due to its smaller size.
3. SEO friendly. As we know, search engine cares about the real content of the page more than what the meta tags say.Search engine crawls to the web page to get the info by reading text on the page. For image, in order to let the search engine know what it is about, we need to use ALT tag. But even if ALT tags are used, images don’t talk to search engine as efficiently as text.

cons:
1. Always need external files. Loading the external files from external domains, which will add more HTTP requests and  for sure affect the performance of the page, slow down the page load time.
2. For Google API, if you can find your fonts from that list, you are lucky. But overall, it’s a very small list, most of the great looking fonts are not in there. Collection is very limited for now. Hope they can add more fonts in the near future.
3. For webfonts, it’s actually an online subscription, you need to use their tool to generate the JS code. So they have the full control of the usage of the fonts, and the access you have to the fonts depends on the type of the membership you subscribed to webfonts. For free membership, the access is pretty limited, in terms of the page views per month and the number of fonts per page, etc.
4. Browser compatibility issues. Special fonts don’t look the same in different browsers. Modern browsers are developed in a way to display CSS2 pretty consistently. However, when it comes to special fonts, all the modern browsers have their own way to show those fonts. Fonts look very inconsistent even with the same browser but different versions. For example, Helvetica font looks good in Safari 5.0.1 but the line height looks so wrong in Safari 5.0.2. Same problem between FF 3.6.8 and 3.6.12, IE7 and 8, etc.
5. ok, now here comes the biggest problem to use text fonts. External files will cause Safari in ipad crash! Yes, external files from both Google API and webfonts will cause iPad Safari crash. So far, I don’t have any fix for this problem, but seems to me iPad Safari is much more fragile than any other browsers, improperly rendered JS code tend to kill the browser.

Basically item 4 and 5 are the showstopper for using this method.

In a nutshell, even though using text to display special fonts seems very appealing due to the pros listed above, it’s probably not time yet, for this method to come play the role, as we see a lot of the modern browsers are not ready for it. Cons number 4 and 5 are the major obstacles of this method. Therefore, using image is still the master stream to give the web page not only a nice look of the text, but also a consistent feel and experience across all browsers. So here comes the image method.

2. Image method

pros:
1. no browser compatibility issues at all. Images look the same on all browsers, no matter if they are modern browsers or not.
2. No need external file or JS coding which can burden the browser from loading the files on other domains.
3. No limit to the usage or access. As long as your computer has the font you want, you can use it however you want.
4. Never cause browsers to crash.

cons:
1. Hard to maintain. If you need to change the text, you have to use image editing tools. This takes much more time and cost than just updating the text in HTML.
2. Loads slower than text, due to the size. Also, images are external files as well, so to load one image, it take one HTTP request from the browser, which affect the loading time and performance. But as a designer, we should know images can be optimized, different types of images are for different format. Using image optimizing knowledge can produce high quality images while minimize the image sizes.
3. Not SEO friendly. Image itself doesn’t send any message to search engine. But if used properly, there are still ways to achieve almost the same result as using text.

While using text got two showstoppers, the major SEO issue of using images can be resolved. Here is the solution:
To address the issue that search engine recognize text content more efficient than looking at the image alt tags, we should still have the text that has been converted to image files entered in the HTML again. But remember, the text in the HTML is not supposed to show up on the page, it’s just for the SEO purpose only, while the image instead will display.  Examples are as follows:

HTML code:
<div class=”headlines”>
<h1>Your Personal Organizer.</h1>
<h2>The best way to stay in sync with your close friends and co-workers.</h2>
</div>

The associated CSS code:
.headlines {
background:url(”images/text_big_banner.png”) no-repeat scroll left top transparent;
height:133px;
margin:0;
width:513px;
}
.home_banner h1 {
display:none;
}
.home_banner h2 {
display:none;
}

Another tip of using images to show the text - transparent PNG 24 format for the images are recommended. This way, the images are independent with the background, and it has the best quality and image size among all the other image formats.

In summary, at the time being, although we have ways to show special fonts by using text and JS file and external libraries, this technology is not maturely integrated with the modern browsers yet. Image, on the other hand, can resolve all issues that text has. For other cons of using images, we still have ways to work round. Therefore, using images to display special fonts are the best solution so far.

How to apply mobile CSS to smart phone devices

Posted by Jen in coding front-end, trends on December 9th, 2009

screenshot1When I am talking about mobile css, I am looking for safari in iphone, blackberry default browser and this new born but the mobile browser for majority to be - opera mini. These days, in spite of the fact that the third generation phones - smart phones have made the majority share of cell phone market in US, unfortunately the mobile web hasn’t come to a universal standard that we can apply like we do to those modern computer browsers.  As a result, when designing a website for mobile, it usually takes more effort to find a solution to browser compatibility and accessibility. And funnily, most smart phones don’t consider themselves as handheld device, thus this “handheld” media for CSS doesn’t work for them:

<link media=”handheld” href=”mobile.css” type=”text/css” rel=”stylesheet” />


First of all, iphone and its default browser Safari.

Yes, iphone made everything easy for everyone, not just consumers but also iphone application developer as well as web designers :) So this approach is rather simple comparing to all other smart phone devices.

<link media=”only screen and (max-device-width: 480px)” href=”mobile.css” type=”text/css” rel=”stylesheet” />

In order to include all other devices which consider themselves as handheld, we tweak this line to be more general:

<link media=”handheld, only screen and (max-device-width: 480px)” href=”mobile.css” type=”text/css” rel=”stylesheet” />

To be even safer, there are times, the device width is 320 pixel or less. So here we are:

<link media=”handheld, only screen and (max-device-width: 320px)” href=”mobile.css” type=”text/css” rel=”stylesheet” />
<link media=”only screen and (max-device-width: 480px)” href=”mobile.css” type=”text/css” rel=”stylesheet” />

Everything works perfectly well with these two lines, except when you come to W3C CSS validator. Yes, W3C doesn’t recognize the mobile style lines, and it doesn’t let them pass through validation. And there is really nothing you can do about it. for more info, you can see some discussion here: http://csscreator.com/node/28171

Blackberry and its default browser.

Blackberry doesn’t pickup any mobile style sheet no matter what media you set to it, not handheld, not width 480px or 320px. There is only one way to give blackberry a mobile looking page - using javascript and direct the page to a blackberry. Below is the script that works. I also tried to apply some mobile style sheet without directing the page to another, but unfortunately didn’t work. more details hereinafter:

<script type=”text/javascript”>
var deviceBB = “blackberry”;

//Initialize our user agent string to lower case.
var uagent = navigator.userAgent.toLowerCase();
var cssFile = “mobile.css”;
//**************************
// Detects if the current browser is a BlackBerry of some sort.

if (uagent.search(deviceBB) > -1) {
//document.getElementById(’blackb’).href = ‘mobile.css’; // this doesn’t work
window.location = ‘home_bb.html’;

//document.write(’<link href=”‘+cssFile+’” type=”text/css” rel=”stylesheet”>); //this doesn’t work either

}
</script>

Opera Mini

It’s a cool mobile browser, which works well with most smart phones - blackberry, iphone, treo palm, etc. To display your mobile CSS on this browser, all you need is still the two lines:
<link media=”handheld, only screen and (max-device-width: 320px)” href=”mobile.css” type=”text/css” rel=”stylesheet” />
<link media=”only screen and (max-device-width: 480px)” href=”mobile.css” type=”text/css” rel=”stylesheet” />

There is this Opera Mini simulator http://www.opera.com/mini/demo/, which makes it possible to test your mobile styles without a mobile phone, however, it only gives you FALSE result. So don’t use it for testing. Install it to your mobile phone and do the real test from there!

Issues you see in real mobile phones but not in simulator:
Opera Mini doesn’t pick up the font size setting in css. Here is the sentence I got from wikipedia:  Opera Mini supports only one font, which can be set to “Small”, “Medium”, “Large”, or “Extra large” size.

http://en.wikipedia.org/wiki/Opera_Mini

The default setting of font size in mobile phone is “medium”. Be aware of this issue when you design the mobile styles, if you are targeting Opera Mini as your mobile browser - use one font size - medium for all text and let it fit in the page.

Another trick of CSS for printing in FF

Posted by Jen in coding front-end on November 12th, 2009

firefoxbugWorking on a printing CSS today, and I found when I tried to print or print preview the page in FF, it only prints/shows the first page, the rest are just blank. This issue only exists in FF browser, all others (IE6-8, Safari) are just fine. So what causes the problem and what’s the solution?

All because of this: overflow: hidden
As soon as I removed it, the print preview is good. However, this overflow:hidden is there for a reason, if you remove it, you have to work on the overflow issues. So printing or overfow? you gotta choose one, or if you are flexibile enough, work around the content to prevent it from being overflown.

Well, Firefox also has bugs… it’s the hard cold fact, so deal with it :)

Many reports about this issue in FF suport:

report 1,  report 2, report 3, look at the comments down there, they are really helpful.

Firefox 3.5 and some interesting articles about CSS3

Posted by Jen in coding front-end, trends on August 28th, 2009

ff35Firefox3.5 was released a while ago, yet lazy I just updated my FF today. And the direct reason for that is I read two interesting articles, both talking about some fancy CSS effects to the text - one is about the fancy text gradient/shadow effect, one is about text rotation. Both didn’t work on my FF3.0 or FF2.0. :(

All right, so here we go, FF3.5. How much better is it ? It’s faster, it displays fonts even more nicely, and most of all - it supports CSS3 and above! well, while enjoying this advanced modern browser, I also noticed a few cons - forcing to update the add-ons: I have had the great add-ons of firebug, colorpicker and measurelt, they were working perfect and I had no intention of changing them. But as soon as I installed the FF3.5, it told me I have to update them otherwise they won’t be functioning… anyway, I am not so used to the new interface of firebug yet.

Overall I liked FF from day one. It never lets me down with 2.0, 3.0 and the updated 3.5 version, both as a regular computer/internet user and as a web designer. However, to be a web guy, we need to realize that what we produce is for the mass media, instead of for ourselves. Therefore, the two CSS3 tricks about the text effects are just for fun, but definitely not for real work practice. I am taking notes of those codes, but I would say it’s for the future only, when the market share of IE (of all versions), FF3.0 and below, Safari 3 and below and Opera 9 and below are all close to 0%. When will that happen? You tell me. :)

CSS transparency tricky IE6 fix

Posted by Jen in coding front-end on June 29th, 2009

semi-transparentIt’s not hard to implement a semi-transparent block by CSS in all modern browsers. The code is something like this:

.thisblock {
filter: alpha(opacity=65);
-moz-opacity: .65;
opacity: .65;
}

And in your HTML, you have something like

<div class=”thisblock”><img src=”someimage.jpg” />some text after the image</div>

Very eassy, right? It basically covers all browsers - IE7, Firefox, Mozilla, Chrome and even Opera. However, if you try IE6, it’s not working.  Here is one little trick for that… add either width or hight to that div class, then you are done. So the fix will be

.thisblock {
filter: alpha(opacity=65);
-moz-opacity: .65;
opacity: .65;
width: 50%;
}

width can be anything, number, percentage, except “auto” or “inherit”.

With the above trick said, if you really don’t want to define the width or height of a block, but have to implement the semi-transparency in IE6, use <p> instead. With <p>, you don’t have to worry about width or height, because not like <div> which span across the entire row,  <p> automatically wrap around the elements inside it, thus it got a specific width by itself.