Archive for January, 2009

Yahoo! Updates Graded Browser Support

Thursday, January 29th, 2009

Yahoo! updated it’s Graded Browser Support yesterday. The changes involved dropping support for non-Safari browsers on Mac OS X 10.4 and non-Internet Explorer browsers on Windows 2000. Support for Internet Explorer 8 was added for Windows XP and Windows Vista.

This has given clout to support Internet Explorer 8 (which is in Release Candidate version now) in addition to versions 6 and 7. Here’s hoping Microsoft forces Internet Explorer 8 upgrades now that version targeting has been implemented.

Old Stuff Up, New Stuff On The Way

Tuesday, January 20th, 2009

I finally finished importing all the relevant old content from Robertdots of yore. It amounted to about 36-ish posts. I’ve set up all the 301 redirects and pulled the 503 I’ve had running for a month or more.

I still have some editing to do on older stuff and I there are still some areas of the CSS that I need to address. The pressing stuff is done, though. In the days ahead, I’ll concern myself with new stuff.

Apologies For Old Content

Wednesday, January 14th, 2009

I started working on importing all the old content I planned on keeping on the site. So far, I’ve only posted two or three old stories, but I have another 30-something in the queue. So, I want to apologize to anyone who reads my news feeds for all this old content showing up. At this point, I don’t know how to make WordPress understand that these posts are old and need to (at least) be appended to the feed.

Until I get through all the old stuff (hopefully by the end of the week), please be patient.

Adding Location Awareness to Your Site

Friday, January 9th, 2009

I recently launched a new personal site.  I wanted to integrate some level of location awareness to it.  My initial design sketches called for the weather information and a position on a map of my last known location.

Initially, I was using a program on my iPhone called Loopt.  Loopt is like Twitter with location.  That involved jumping through hoops, as Loopt’s RSS feed only shows the GPS position of the last post.  Not only would I have to post a message every time I got somewhere, I’d have to reverse geocode my position to grab the zip code to send to get the weather information.  I achieved this through JavaScript with the Google Maps API.  This worked until I found out about Fire Eagle.

All Fire Eagle does is log your location. Luckily, Fire Eagle has an API. Eagle Feed turns your location into a publicly accessible RSS feed. So, getting your location is as easy as parsing an RSS feed. By setting the read level of Eagle Feed to
my zip code

, the title of the single item in the RSS feed reports my city, state, and zip (e.g.
Birmingham, AL 35223

), and my GPS coordinates are also in the feed.

You can update Fire Eagle by manually by entering your location on the site. However, there are mobile applications, such as Active Eagle on the iPhone, that use the GPS functionality of your device to update Fire Eagle. In Active Eagle, I simply tap “Update Fire Eagle” to update my location, and my Eagle Feed.

Once you can get your feed there are plenty of cool things you can do.

I wrote a simple PHP script to open my feed (or pull it from a cached file), grab the human-readable location from the title and parse out the zip code and my GPS position.

1
2
3
4
5
6
7
8
9
10
11
$out = file_get_contents($feed_url);
 
preg_match_all('/<title>(.*?)<\/title>/', $out, $loc_matches);
$human_loc = $loc_matches[1][1];
preg_match('/\d{5}/', $human_loc, $loc_matches);
$human_zip = $loc_matches[0];
 
preg_match('/<abbr class="latitude".*?>(.*?)<\/abbr>/', $out, $lat);
$loc_lat = $lat[1];
preg_match('/<abbr class="longitude".*?>(.*?)<\/abbr>/', $out, $long);
$loc_long = $long[1];

I then pass my zip code to Yahoo’s weather feeds to get weather data. I also pass my GPS position to Google Maps Static API to get a map of where I am.

Another idea would be to show Flickr photos in your area via the Flickr API. I’m sure there are tons of other things that would be fun or useful. Come up with some more ideas and make some cool stuff.

The State of Web Fonts

Thursday, January 8th, 2009

A long time ago, Microsoft started making use of @font-face (also called web fonts) in CSS. This would have been revolutionary if not for the fact that using fonts required the designer to encode them into a weak DRM file called an EOT, which stands for Embedded OpenType. Open indeed. Things are starting to look up now.

The great thing about Microsoft trying to introduce this is that it would have ended an era of Web Safe fonts and “download this font to view my page properly” messaging before Web Safe fonts were understood. Unfortunately, no other browser bothered implementing the CSS or EOT and @font-face fell into obscurity for many years, forcing web designers to use images of text. EOT’s major flaw was that it pandered to font makers and left web designers jumping through hoops to create font files.

Microsoft apparently has strong corporate ties to certain Font Industry big-wigs, and they didn’t want to upset them. Better to make life hard for your developers than help font makers come up with workable solutions for licensing web fonts (like hosting font files and checking the HTTP_REFERER for the correct domain before allowing access to the font file, which seems as good as the weak DRM of EOT files). When you are the most commonly used browser, I guess you can do stuff like that and still have your CEO chant, “Developers! Developers! Developers!” The problem is that Microsoft didn’t anticipate empowering font creation software like FontStruct that lets mere mortals create fonts under Creative Commons licenses. Frankly, it’s unfair to force me to put DRM on stuff I create if I don’t want it.

Eventually, some good people created sIFR, which allowed designers to (with great effort) cobble together a Flash file that embedded a font. Adding some JavaScript code to the page allowed designers to add fonts in a more accessible, user-friendly manner than simply using images of text. While sIFR had some problems (for example, links in headings were buggy and the text wouldn’t resize with the browser), it was a breath of fresh air. Suddenly, it was only a little work to have nice typographic options for limited use in headers and the like.

Recently, Apple (in the form of WebKit) and Opera have brought back the @font-face. Luckily, Apple and Opera didn’t bend over for the Font Industry. They boldly allowed support of plain-old TrueType fonts. With half of the major rendering engines supporting easy web fonts (and Firefox support on the way), I decided to give EOT another shot. That would allow me to have four out of five browsers (that I support) rendering my fonts out-of-the-box with sIFR as a worse-case fallback.

The results were mixed. Using @font-face is progressive enhancement with CSS and using sIFR is progressive enhancement with JavaScript and Flash. To start, I went through the lengthy and buggy trial and error process of creating an EOT with WEFT. After getting that worked out, I added the following to my screen stylesheet:

1
2
3
4
5
6
7
8
9
10
11
@font-face {
	font-family: "MyFont Sans";
	src: url("../media/myfont_sans.ttf") format("truetype");
}
 
@font-face {
	font-family: "MyFont Sans IE";
	font-style: normal;
	font-weight: normal;
	src: url("../media/MYFONTS0.eot");
}

I could then set a font by specifying font-family: MyFont Sans, MyFont Sans IE, sans-serif;. In Safari, Opera, and Internet Explorer, my site used a custom font. Other browsers fell back so a system chosen sans serif font if the font MyFont Sans was not installed on the system. That gets us half way there.

The next step is to create the sIFR and load it only if it is needed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
var MYSITE = {
	sifr: true,
	init: function() {
		if(window.getComputedStyle) {
			var ff = document.defaultView.getComputedStyle(h,null).getPropertyValue('font-family');
			switch(ff.toLowerCase()) {
				case 'myfont sans':
				case '"myfont sans"':
				case "'myfont sans'":
					MYSITE.sifr = false;
			}
		} else {
			MYSITE.sifr = false;
		}
		if(MYSITE.sifr) {
			MYSITE.setSifr();
		}
		return true;
	},
	setSifr: function() {
		// Code enabling sIFR
	}
};
 
if(window.addEventListener) {
	window.addEventListener('load', MYSITE.init, false);
} else if(window.attachEvent) {
	window.attachEvent('onload', MYSITE.init);
} else {
	window.onload = MYSITE.init;
}

The script runs after the page loads. Checking for window.getComputedStyle ensures that any standards compliant browser that supports web fonts will not get sIFR, since the browser will report that it is using MyFont Sans. Firefox, if I remember correctly, reports a list of fonts, but it ends up in the result of Firefox getting sIFR. Once Firefox has web fonts support, this script will need to be reevaluated. If the browser doesn’t support getComputedStyle, the browser is (probably) Internet Explorer, which supports web fonts. So, we can turn sIFR off.

Finally, any browser that needs sIFR will execute MYSITE.setSifr();, adding the custom fonts to the page.

This should provide custom font support in most major browsers. The only caveat is that a suitable fallback should be chosen (one that looks similar to the @font-face font, rather than sans-serif mentioned above), as browsers without Flash or without JavaScript will see the fallback font if the browser doesn’t support web fonts.

Since we have a suitable fallback with sIFR when web fonts aren’t available to the browser, there is a good enough methodology for implementing custom typography on live sites that don’t support web fonts. Until Firefox releases support for web fonts, it may be too much trouble to implement. However, in the spirit of progressive enhancement, one could skip the sIFR step and simply allow the installed system font fallback, as pixel-perfect cross browser support is turning into an obsolete, undesirable practice and progressive enhancement is becoming common place.

The final rub is Microsoft’s persistence in supporting EOT and not TrueType or OpenType fonts. While it is possible to get web fonts in Internet Explorer, it is a royal pain to create EOT files. If it’s too much effort, using sIFR or keeping the tenants of progressive enhancement with CSS may be a workable solution.

So, it seems web fonts have almost come of age. Once Firefox supports @font-face, web fonts can be used on a wide scale. While you may not want to jump on the bandwagon yet, it is definitely time to start looking into web fonts.

Robertdot Relaunch

Wednesday, January 7th, 2009

Welcome to the relaunch of Robertdot. As you can see, there isn’t much here. I still have a ton of work importing relevant old posts, fleshing out the site, and debugging.

The reason for all the changes is to help take Robertdot away from its original purpose as personal blog and move it toward my new goal for the site as a web design blog. That means I’ve purged everything, and I’ll slowly bring back content relevant to the site while letting the unneeded parts fall away.

If you’re used to keeping up with my personal life here on Robertdot, you may want to take a look at my new personal site, Robert Brodrecht’s Vanity Site.

So, keep an eye out in the coming weeks for things to get finalized and Robertdot to turn into a finished product, rather than the live beta you see now.