Posts Tagged ‘Browser Support’

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.

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:

@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.

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) {
		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.

The Great MIME-Type Swindle

Sunday, November 19th, 2006

It’s a really old subject, but I haven’t said my piece on the XHTML 1.0 versus HTML 4.01 debate. While commenting on Roger Johansson’s blog, 456 Berea Street, I said a little bit about what I think. I figured I ought to go ahead and say my fill.

XHTML was supposed to be the death of HTML. HTML 4.01, until recently, was supposed to be the last iteration of HTML. I think XHTML is great. It allows the designer to implement bits of XML, should he want to. It also is very strict, requiring proper syntax where HTML didn’t. If there is something wrong with the code, the page should not render at all. This makes good syntax coding a requirement rather than a suggestion. However, the current implementation of most of the XHTML pages I know of is ideologically broken. The rest don’t work on Internet Explorer.

The comments I made assumed a little foreknowledge but basically say what I want to say here. However, I’ll go ahead and lay out my full argument here.

In 2000 when XHTML 1.0 was introduced, there was a need for backward compatibility since most browsers could not render real XHTML. That is, browsers were built to render HTML served as text/html. Sending XHTML as XML resulted in, I assume, an interpreted XML tree. So that adoption of XHTML would occur, it needed to work in browsers. So, the XHTML recommendation had guidelines in place of how to make XHTML work on HTML browsers. This wasn’t backward compatibility so much as a hack. It didn’t allow for any of the benefits of XHTML, though it succeeded in making pages written with XHTML syntax render on old browsers. So, the mime-type is the modern equivalent of DOCTYPE triggering quirksmode (which the Web Hypertext Application Technology Work Group embrace).

As far as hacks go, it worked. Like all transitional solutions, it was supposed to be dropped as browser support for XHTML grew. The problem is that Internet Explorer never supported it (even in version 7) and people opted to continue to send HTML-XHTML. Further, it seems, many people don’t realize that real XHTML requires the correct application/xhtml+xml mime-type being sent. This is something that must be set up on the server, as text/html is the default mime-type for sending .html documents on every web server I know of.

When XHTML is sent as text/html, it behaves differently than if it is sent correctly. XHTML sent as HTML is treated as tag soup, which means any optimized, light weight XML parsers aren’t used. Tag Soup XHTML doesn’t require strict use of CDATA elements and improper syntax doesn’t stop rendering of the page. The null closing tags are treated as broken attributes. While it still works, XHTML is ideologically broken if it is sent as text/html. People who suggest we ought to use XHTML to guarantee that fledgling designers pick up XHTML (which would require strict syntax) are suggesting that we use a broken implementation to uphold an ideal that is at odds with broken implementations (ignoring that an unforgiving markup language would cause most designers to give up out of irritation). It is hypocritical.

So, I see two choices that are ideologically sound. The first is to use XHTML and send it as application/xhtml+xml, Internet Explorer be damned. However, this is really not a good choice for most. Some would suggest content negotiation, but this is still a hack that requires a lot of extra thinking and planning (albeit a better one than sending XHTML as HTML). The second is to only use XHTML in specific instances where compatibility can be guaranteed.

Let me elaborate on the second choice. HTML 4.01 is a web standard. Anyone in the web standards group that always advocates XHTML over HTML on grounds that XHTML is better suited for use than HTML doesn’t understand what tools are for. HTML with a strict DOCTYPE can be validated, written semantically, and obsessed over as much as XHTML. HTML just allows the web designer to make the choice (and good designers will obsess over their markup no matter what).

HTML and XHTML are tools to solve a problem. Just like a screwdriver won’t help when a hammer is needed, XHTML is no good when HTML is needed. I’ll be specific. On pages where free-form user input is allowed, the potential for non-designers (and designers, too, for that matter) to enter bad markup is huge. In a real XHTML page, the user could easily break a page, preventing rendering. When using HTML, the page may no longer validate, but it will still render. In instances such as these HTML is a better tool than XHTML.

Web applications, however, are a different story. System requirements can be specified as they are on traditional applications (e.g. a browser that supports XHTML can be required). This means that no hacks need to be used. Since web applications generally use form elements to display and edit data, concerns over user input are drastically reduced. Most of the time, discreet data is required rather than free-flow data that one might find on, say, a comments page. So, data can be more accurately validated. When that data is inserted into an XHTML page, it’s far less likely to break the page. On a syntactical level, XHTML meshes well with programming languages. That is, the code must live up to certain standards. XHTML would help tie the front end to the back end. XHTML is a perfect tool for web applications.

So, ignoring all the common arguments about the dangers of using XHTML, the ideology of XHTML is broken if the page works in Internet Explorer 7 or below. Advocating the use of a broken technology is hypocritical when well written HTML 4.01 with a strict DOCTYPE is better suited for normal web usage. However, XHTML has a defined and useful place on the World Wide Web.

If you want another opinion, Maciej Stachowiak of Apple’s WebKit / Safari project weighs in with pretty much the same opinions I have.

Update: The Lachlan Hunt pointed out that I screwed up the XHTML MIME-type. I fixed the error.