sIFR: anti-aliased text in any font

December 29, 2004 11:36 AM

Forget Verdana, here’s sIFR: anti-aliased text in your browser in any font you like.
The next big thing? Just a kludge? Heard about it already?
posted by Termite (160 comments total)

They use this on ABC News. It works well as long as it's only used for display. When used as a text link (as a clickable headline, for instance), it breaks all the standard link symantics like right-clicking and "Open in New Tab", which drives me nuts.
posted by smackfu at 11:46 AM on December 29, 2004

Funny; I thought I already knew all I needed to know about this technique, but I hadn't checked in since the Werner/Cameron innovation. This new development is quite welcome.
posted by eustacescrubb at 11:47 AM on December 29, 2004

Beautiful tool, but as smackfu mentions, it breaks usual copy-pastability. That's the downfall of flash sites, especially ones that rely on word-of-mouth for publicity. Word of mouth spreads faster when your text can be paste-bombed into blogs, IMs, and e-mails.
posted by NickDouglas at 11:52 AM on December 29, 2004

This is what it looks like. Try resizing your browser window and then hit reload to see sIFR adapt.
posted by Termite at 11:52 AM on December 29, 2004

good idea (now i know why flashblock gives me "empty" movies on the ESPN website). but i do agree with the author that this sort of thing shouldn't be necessary.

if i can't have my flying car, can i at least have some class and fanciness for my web? we've got the technology but it hasn't been implemented. jakob neilsen be damned, usability is a good idea and all, but clean and interesting design shouldn't need to be this hard.
posted by caution live frogs at 11:56 AM on December 29, 2004

It's a neat solution but it breaks more things than it solves. I can think of only a few instances I would want to use this.
posted by camworld at 11:57 AM on December 29, 2004

Actually, you can copy and paste with this technique. No right-clicking though. Still, great use of Flash. It certainly beats using GIFs/PNGs for headline type.
posted by gwint at 12:01 PM on December 29, 2004

I've always found it brilliant, but then, Shaun Inman and Mike Davidson are a brilliant men.

What I've found to be more exciting than the Flash technique itself is the way members of the design community have taken it and modified and improved it to create something that I'm fairly certain is more than just a passing trend. That evolution over the past year has been fascinating to experience. And, in the next year, I'm hoping that many of it's current bugs and issues will be solved.

This has been a hot topic in the design community for some time now with just about everyone weighing in on it's pros and cons and you give MetaFilter one link? ;)
Here's Shea's commentary and some facts and tips on how to use it.
posted by erisfree at 12:01 PM on December 29, 2004

Fine and dandy for titling, but not for the entire text.

Aside from the many concerns my clients profess against Flash, money being one of them, processor speed at anything other than a gamer's box is considerably low, thus when one has many apps and browser windows open, things would slow to a crawl if there were a ton of embedded flashii on the pages. Been there, done that, not worth the trouble.

Progress is progress, yes, but until a complete solution is found, one that does not need a plugin, we'll still be making our titles out of gifs.

If Macromedia were halfway smart, they be developing a browser, instead of all the other BS they do.
posted by jsavimbi at 12:02 PM on December 29, 2004

Jakob Nielsen is irrelevant to clean and interesting design. People who focus on demonizing him for paying attention to the details that interest him -- who insist on making it a personality issue -- fail to understand the real barriers to what they want.

As for sIFR, I love the results, but AFAIAC, any "standard" that relies on a proprietary format is a non-starter. At some point, I'll probably use it for someone who's paying me to use it and insists on this level of anal-retentiveness, but I doubt I'll ever use it for myself.
posted by lodurr at 12:04 PM on December 29, 2004

more importantly, does it render the blink tag properly?
posted by evilgenius at 12:04 PM on December 29, 2004

Wow, what a nightmare. Is there no concept of time in Flash? Are all delays accomplished by no-op loop? (Even if this is true, surely an animation can find out how much time has actually passed and skip frames accordingly, right?) I spent about three or four minutes waiting for the demo to do something and then gave up on it. It had got as far as saying "This text looks like garbage". I couldn't agree more.

Needless to say, any site that makes me wait several minutes for a pokey Flash animation isn't going to sell me on the idea of using Flash for basic text rendering.
posted by dreish at 12:06 PM on December 29, 2004

You might also be interested in the previous discussion about sIFR on Whitespace. Always good design discussions there.
posted by erisfree at 12:06 PM on December 29, 2004

jsavimbi, I'm not sure that Macromedia aren't a bit more than halfway smart. Why should they expend time and energy developing a browser, when people keep using their "technology" to produce solutions like sIFR?

sIFR generates profits for Macromedia. Browser development would be a huge cost center.

Put another way: Macromedia benefits from the failure to fully implement decent web based layout. I'm not suggesting that they try to inhibit the processes -- I sincerely don't think they do -- but it's clear that the need for things like sIFR enhances sales of Flash.

FWIW, I've been telling people for a couple of years now that Macromedia are the way of the future -- if not the next Microsoft, then close to it. If they can't sell you a server, they can sell you an IDE that will work with yours. They are turning themselves into the IBM of the content delivery and management stream.
posted by lodurr at 12:09 PM on December 29, 2004

There’s an improved version 2.0 out. The headlines on the example page are clickable and you can right-click and copy them, but not together with the small text. (For me the example page works in IE but not in Firefox).
posted by Termite at 12:14 PM on December 29, 2004

Erisfree: thanks for the links!
posted by Termite at 12:23 PM on December 29, 2004

I loathe Flash for exactly the same reason web designers love it - it sacrifices usability for prettiness. I don't think web designers should get to use any font they damn well please. I surf the net for content, i.e., words and pictures. The fonts they come in shouldn't affect the content - in fact, they should pretty much be dictated on the client-side. But I'm not an artist.

lodurr is right in saying that Macromedia benefits from poor web standards and browser design.

On a side note, I use Proxomitron with JD5000's filter set that replaces all Flash animation with a toggle switch. That's not the only thing it does, of course ;)
posted by aerify at 12:24 PM on December 29, 2004

Wait a minute. Didn't Netscape 4 have the feature of being able to embed fonts in webpages? I distinctly remember that, even though it appears to have fallen by the wayside.
posted by neckro23 at 12:25 PM on December 29, 2004

No problem, Termite, it's just a topic I'm familiar with.
posted by erisfree at 12:36 PM on December 29, 2004

sIFR looks absurd when Flashblock is installed. A bunch of Play buttons where headlines should be, and me scratching my head wondering why there are so many ads on a page.

(For the record I'm not anti-Flash but Flash bogs down my Firefox on OS X so I deny by default and then show the stuff I'm interested in.)
posted by revgeorge at 12:42 PM on December 29, 2004

Wow, that's a lot of ADBLOCK buttons.

But, like any tricky new web technology, there is an appropriate time and place to use it... I'm definitely going to play around with this.
posted by hartsell at 12:44 PM on December 29, 2004

Ick. Let's take the most open, widely-supported, indexable and flexible aspect of the web and lock it into a proprietary, clunky, nasty, closed plug-in. My thesaurus does not have enough words for "stupid".
posted by gimonca at 12:51 PM on December 29, 2004

While yes, Flash is proprietary, has anyone viewed the source of the sIFR example pages? Now *that* is a beautiful (and deliciously standards-compliant) thing...at the very least, it's a huge improvement over the many image replacement techniques that the standards-approved crowd of Zeldman et al have been using for the past six months or more.

Plus it gracefully degrades to displaying regular CSS-styled text if either javascript or Flash aren't present. I'm finding it hard to dislike sIFR, if used in moderation and with some sense...
posted by flaneur at 12:56 PM on December 29, 2004

Netscape and IE had ways of embedding fonts but both companies dropped those non-compatible features long ago.
posted by infowar at 12:57 PM on December 29, 2004

"I don't think web designers should get to use any font they damn well please"

I've read some dumb shit on Mefi but this one is a standout. And what about all those annoying 256 colors, do we really need all them?

The technology that has spawned sIFR will no doubt find usefullness in other areas of the web. I believe it's called progress Aerify. Yeah, at this point a waste of time for most users but everything has to start somewhere.
posted by j.p. Hung at 1:24 PM on December 29, 2004

You people would bitch if you were hung with a new rope.
posted by majcher at 1:26 PM on December 29, 2004

Long ago I set up my browser preferences so that all text anywhere is rendered in Verdana, minimum size 10px. I cannot say how displeased I am when I use someone else's computer and notice how many sites want to use Comic Sans.

I love a well-designed page as much as anyone, but let's be honest, you come across those sites so infrequently, and the design so rarely relies on the typeface, that I hardly see why this technique is any better than using the image-based CSS/JavaScript replacement techniques, if you really have to use anything at all.

In just playing around with some of the examples linked to above, I noticed a sluggish behaviour when trying to select the text, or right-clicking in the area nearby. Let's not even get into what happens with FlashBlock/Toggle software enabled. It's just a mess.

I too wish for an easy way to embed fonts in webpages (natively, not with plugins or hacks). I'm sure there are copyright issues to contend with, which is disappointing, but I'm still waiting for the day when fonts can be used successfully, without today's problems. To those outraged at the outrage of people complaining about sIFR: Progress it may be, but it's still a hack/workaround that should be used sparingly and only until a truly viable solution is developed.
posted by odinsdream at 1:30 PM on December 29, 2004

Didn't Netscape 4 have the feature of being able to embed fonts in webpages?

Microsoft tried to get this passed by the w3, but they, being the Microsoft-fearing bastards they are, refused to make it a standardized process. Still, you can embed fonts in HTML, but it only works with Internet Explorer 4+. Here are detailed instructions in how to do this.

My thesaurus does not have enough words for "stupid".

Completely agreed.
posted by Civil_Disobedient at 1:33 PM on December 29, 2004

"I don't think web designers should get to use any font they damn well please"

I've read some dumb shit on Mefi but this one is a standout.

Oh, please, give me a break. You know damn well that we'd be living in design hell if "web designers" could use any damn font they pleased at any damn resolution they pleased.

Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.

When content is indivisible from presentation, that is usually, IMNSHO, a failure of design. There are occasional exceptions; but for all the successful marriages of presentation and idea that litter the design rags, there are hundreds and hundreds of failures.

Odinsdream: I actually set my default sans-serif to Comic Sans precisely so I can tell when someone isn't properly binding fonts to the page elements. It's a pet peeve of mine.
posted by lodurr at 1:54 PM on December 29, 2004

...I actually set my default sans-serif to Comic Sans precisely so I can tell when someone isn't properly binding fonts to the page elements. It's a pet peeve of mine.

You are a far braver man than I.
posted by flaneur at 2:18 PM on December 29, 2004

As it is implemented in the above links, I think this technique is a bad idea. Although the code is clean, using JavaScript to rewrite portions of the page with Flash is still terrible for accessibility, because it ignores user-defined fonts and stylesheets. If odinsdream configures his browser to display everything in Verdana, and my parents want to see everything in 24pt bold, we as web designers should let them.

However, I think this could still be useful when the text in question is not content. (Sorry lodurr.)
posted by hartsell at 2:30 PM on December 29, 2004

Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT

This implies that print is not about content?
posted by romanb at 2:32 PM on December 29, 2004

"Content" needs to be clarified. The net is made for shuffling bytes around. Those are the content. All the other stuff are poorly-thought-out ad-hoc protocols and formats stacked in an ever-higher tower. sIFR is a program written in Flash, embedded with ActiveX into an HTML document which is rewritten with Javascript. We're talking four or five layers above the application layer (web browser.)
Pick out the robust, well-defined protocols in the above. Funny things will go wrong in the others. The hacker in me thinks this is very neat, but the web surfer in me wants to weep at the thought of using this Rube Goldberg machine to read 1k of text.

(ob: Flash and Javascript have improved about 300% in the last 3 years, so I'm not really complaining. When the Metaverse arrives, we'll all have beautiful type.)
posted by sonofsamiam at 2:57 PM on December 29, 2004

Flash has its purposes, but it is a poor substitute for a browser's native abilities. For instance, can I scale the Flash-fonts? In Firefox, this is trivial (CTRL + mouse wheel). And how about speed? If you've ever used the lame scroll-panels in Flash on a slow computer, you'll quickly appreciate built-in OS widgets.
posted by Civil_Disobedient at 3:12 PM on December 29, 2004

You people would bitch if you were hung with a new rope.

Indeed. People seem to be turning a small, useful tool into a fight for the Web's soul. The main purpose of sIFR, from my understanding, is to give the designer just a little more control over typography. Make those headers look perfect. Give the page a little more style. Have some fonts match your corporate identity while still retaining the ability to scale and copy. sIFR does those things very well.

If you truly believe graphic design has no place on the web, use lynx and shut the hell up.
posted by gwint at 3:48 PM on December 29, 2004

I think someone's still upset that they only had the 8 color box of crayons when all the other kids had 64.

You're web may be only about content but my web is about many other things, including "experience".


...but mostly porn and mp3s
posted by Mick at 3:56 PM on December 29, 2004

Flash and Javascript have improved about 300% in the last 3 years

300% of an infinitesimal amount is.....a very slightly larger, but infinitesimal amount.

Make those headers look perfect. Give the page a little more style. Have some fonts match your corporate identity while still retaining the ability to scale and copy.

Higher production costs and more brittle, breakable pages with virtually no added value. Bad business decision. Good for "graphic designers" who bill by the hour; bad for everyone else.
posted by gimonca at 4:05 PM on December 29, 2004

Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.

No more than print is about content. Both can be about more than content without sacrificing the content.

If someone wants to make what you deem to be an ugly website, why shouldn't they be free to do so?
posted by rushmc at 4:12 PM on December 29, 2004

I like this idea and I think I'll try it on a site soon, but I actually think I'd prefer generated gif / png files with proper alt / title tags (and within the right semantic markup, of course), if you can get the php font dealie to behave. A flash file with an embedded font is probably bigger or equal to a gif or png of a single title, so I'm not sure there's a huge bandwidth savings, especially when the javascript's considered too. But then, like I said, I might give this a shot.
posted by condour75 at 4:38 PM on December 29, 2004

Huh? What's the innovation here? Replace some text on the page with a fucking SWF file? Woo.... hoo? I don't see the value of this. if you want things to look nice in the browser, use a browser that makes things look nice!
posted by majick at 4:38 PM on December 29, 2004

This is turning into a typical sIFR comments page, with people who don't understand the technology wading in with their "Flash is bad", and "proprietary, clunky, nasty, closed plug-in" opinions.

For the record, I am the author of the How and when to use sIFR article referenced by Eris above. If you can't see why sIFR is important - then go and read it.

I am resisting the temptation to repeat everything I have written at UsableType, but...

Many designers will never need to implement a solution like sIFR. Many designers have never developed sites where hundreds of dynamically created pages are added daily and a corporate typeface is required. Those that have, will instantly see the advantages of sIFR over dynamically generating images or any other current methods.

As for "higher production costs", why do you think IFR was developed in the first place? To reduce costs of course: by reducing server load and bandwidth.
posted by andyhume at 4:39 PM on December 29, 2004

"weep at the thought of using this Rube Goldberg machine to read 1k of text."

Not 1k of text. It's for magically replacing headlines (which apparently don't render well in some browsers) with SWF. So, you're reading, what, 30 bytes of text?
posted by majick at 4:42 PM on December 29, 2004

One sentence above should of course read:

"...and a corporate typeface is required for titles or headings."

I'm not advocating using this for body text!!
posted by andyhume at 4:42 PM on December 29, 2004

hehe, point "Mike".

Incidentally, it looks like Metafilter has picked up on sIFR today and is sending over a ton of traffic to the original sIFR article. Reading the Metafilter comment thread is a bit humorous. It never ceases to amaze me how some people will see the word “Flash” and cry about imaginary accessibility issues, imaginary proprietary file format issues, and other imaginary “sky is falling” issues. Look at the code people. Study it. Analyze it. Understand it before you jump to conclusions. And above all else, understand that the entire web as we know it is a hack. I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join.

posted by wah at 4:44 PM on December 29, 2004

You owe me a fiver then Mike.
posted by andyhume at 4:49 PM on December 29, 2004

Well, thanks for that, andy! I'm not trying to pick a fight here, but at what point does

"The scenario: A large sports news website decides to style all their headlines in a unique corporate typeface."

translate to "it is a good idea to shove semi-optional binary data at the user" rather than "we don't get the web, we don't get the web, we do not understand the purpose of the web"?

I don't think the issue is with people who "don't understand the technology" -- I could implement this myself having now read a general description -- but with people who don't think Your Corporate (oo! so important!) Decision About Your Fancypants Font merits anything so drastic as slapping people around with Flash.
posted by majick at 4:49 PM on December 29, 2004

A web developer (to a certain extent) is required to deliver what the client needs. What would you do in that situation? Sit them down and tell them, "you don't get the web, you don't get the web, you don't understand the purpose of the web"?

Can we have a rational discussion, rather than a "sky is falling" one? What's wrong with sIFR, majick?

And it's "semi-optional binary data" doesn't count, OK?
posted by andyhume at 5:01 PM on December 29, 2004

Oh, and it seems to add about 10k to page weight. If I were to put this on my Large Corporate Image-Conscious Marketing-Driven employer's Highly Visible Web Site, I would be risking getting canned just for spending the 10k in APW even if we offloaded the heavy stuff to Akamai.

"What would you do in that situation? Sit them down and tell them, [the nanny-nanny boo boo rant]"

Yeah. That's what I'm getting paid for. If my current employer wants Shut-Up-And-Implement service, they can farm the project out to the team in India . They're inexpensive and have been doing a pretty good job. If they want a serious discussion about doing the Right Thing, they ask me.

There seem to be two different web development models. One is purely client driven, the client delivers a spec, the developer turns it around, gets paid. For something like this, I suppose replacing headlines with 10k of JavaScript and Flash might sell some contracts and probably leave some customers pretty pleased.

In the other model, the client (my employer, for example) wants an optimal solution and wants someone who can tell them "you're crazy, that's a waste of time, money, and architectural robustness".

I try to contstrain myself to the latter category as I find the work more satisfying and suited to my curmudgeonliness.

So what's wrong with sIFR? The fundamental assumption that it's actually a good idea to put more Flash on the page for what are, essentially, static elements. It's not. Seriously. Rendering is the browser's job.

I realize that sIFR has left all the right escape hatches in place for both technical and curmudgeon-compatibility. They're clever, fiendishly clever. Except that I shouldn't have to dodge yet another binary that's going to kick off yet another Flash thread that's going to hang yet another browser window just because you want your headline font.

The utility of this thing is limited, at an unknown cost to robustness. It's not a tradeoff I would make.
posted by majick at 5:21 PM on December 29, 2004

I love the comments from people who comment before they know what the hell they are even talking about. sIFR is brilliant. It's not Flash, it's a font exported as a .swf file that can then be dynamically rendered as anything (headlines are the most obvious). It is a way of embedding fonts that is extremely lightweight. SWF is not Flash.

Here is an hour long Breeze presentation on sIFR from Macromedia and a good article on Why sIFR Matters.
posted by spock at 5:23 PM on December 29, 2004

I stumbled on this, like, yesterday. How serendipitous.

I don't think I'll use it except maybe to play around with a bit, but I like things that are fiendishly clever, which, as makick says, this is.
posted by stavrosthewonderchicken at 5:36 PM on December 29, 2004

10k to page weight once. The .js and .swf files need only be downloaded once to be used on thousands of headlines.

However...

You are right about two current web development models. I guess it comes down to your fundamental feelings about the web and the way it should be going.

Generating Flash headlines is one massive hack, of course it is. But no more so than any of the dozens of techniques that makes the web look like it is today. Tables for layout? Image replacement? etc... None of it is good.

But I still haven't heard one good reason against using sIFR in the right situation apart from that it goes against an idealistic philosophy.
posted by andyhume at 5:39 PM on December 29, 2004

As far as weight is concerned it is far lighter than your previous option of using gifs or jpegs for typographical headlines ... the sifr.js file (which does all the work) is a 12K file (and is cached after the first load, right?). The individual font files are only 8K - 16K each (and if you are smart you are probably only using ONE of them, not SIX as in the example page). The added code on the page is next to nothing. The bandwidth savings can be HUGE for a high traffic site.
posted by spock at 5:39 PM on December 29, 2004

The release candidate 3 has dropped the sifr.js to 8.8K.
Micheal Davidson has some comments for ignorant metafilter commenters on the RC3 page:

"Reading the Metafilter comment thread is a bit humorous, however. It never ceases to amaze me how some people will see the word “Flash” and cry about imaginary accessibility issues, imaginary proprietary file format issues, and other imaginary “sky is falling” issues. Look at the code people. Study it. Analyze it. Understand it before you jump to conclusions. And above all else, understand that the entire web as we know it is a hack. I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join."
posted by spock at 5:44 PM on December 29, 2004

Another article: How and When to Use sIFR
posted by spock at 6:02 PM on December 29, 2004

hrm, am I missing something? on the example page, and several sites that have implemented it, I have no problems in Firefox 1.0F on winxp copy/pasting this stuff. I can take whole paragraphs and get the headlines in there too...either right-click to copy (full contextual menu) or good ol' ctrl-c. I can highlight a part of a sIFR headline and right-click or ctrl-c again (tho in this example I get a slimmed down contextual menu...just cut/copy/paste/delete and select all, which only selects the headline).

versions from the 1914 translation by H. Rackham.
The Quick Brown Fox Jumps Over the Lazy Dog
The standard chunk of Lorem Ipsum used

While the highlighting is a touch unclear (parts of the sIFR headline will be highlighted, others not) the whole text comes through (see above, formatting added for emphasis with empty lines removed).

I think this is an awesome use of flash...it adds a whole new dimension for developers and is quite discreet...that is, if you dont have flash/js, you dont see it (how much easier can it be?) just the old style page. Kudos to Mr. Davidson et all for the innovation...I'll be playing around with this all weekend.
posted by gren at 6:06 PM on December 29, 2004

"10k to page weight once."

As someone who has come up against millions of page views of what are inarguably fairly complex web pages, I'm extremely confident in saying that trusting the browser cache is an extremely bad idea. This is a good first approximation, but that's all it is. In reality, I'd change "once" to a rough factor of "one and a third times," modulo how much AOL cached traffic you expect.

"SWF is not Flash."

This is disingenuous. The thrust of the argument is that "Flash" is a suite of authoring software, and SWF is a file format. That's great, except the only widely distributed interpreter of SWF data is something called the "Macromedia Flash Player," and SWF content has been commonly called "Flash" for quite a long time. In the end, a thread is going to run some (in my experience, especially shoddy) Macromedia code if you throw SWF at the browser.

"other imaginary 'sky is falling' issues."

At no point am I claiming the sky is falling. I'm claiming that the sort of thinking that leads people to want to ram their fonts down the browser's throat -- even with fiendishly clever browser tricks -- is wrongheaded. If you want falling sky rants, I'll rail about how this is one more tiny step towards turning the web over to Big Corporate Content. But I'll spare everyone, since in then end that's all speculation on my part.

"And above all else, understand that the entire web as we know it is a hack."

I'm not sure I can dignify this with an appropriate response, other than to call it incorrect. sIFR is a (fiendishly clever) hack. The entire web as brochureware designers know it is a hack. The rest of us see it as a relatively mature, extremely well specified, open platform.

Now, I'd go so far as to say that most of the major browsers are hacks, but that's mostly to support the bad things brochureware designers are doing and some early markup language ambiguity. The web is not your browser.
posted by majick at 6:29 PM on December 29, 2004

Micheal Davidson has failed to address my point, but of course he would, because my point still stands.

Can you dynamically resize the text of the embedded SWF? Because just about every browser on the planet has this ability.

Get it through your fucking head: this isn't just about your c00l l33t font, oh great d3sign3r king. It's also about a little thing called accessibility. Many people have to use larger font sizes because they have difficulty seeing. How does the embedded SWF option scale when the rest of the text on the screen increases in size?
posted by Civil_Disobedient at 6:36 PM on December 29, 2004

Civil_Disobedient, this is from the "How and When to Use sIFR" article that has now been posted twice in this thread:


* sIFR does not require any changes to the (X)HTML code, all the work is done by Javascript, Flash and CSS.
* If the user does not have Flash installed or Javascript enabled then the (X)HTML text is displayed and styled by CSS.
* sIFR is scalable, and when rendered will adjust to the users font size settings.
* sIFR is compatible with all screen readers. No problems or issues have ever been reported.
* sIFR text is selectable with the mouse, although visual confirmation of the selection may be absent when selected with body text.
* sIFR does not affect search engine placement or ranking, nor does it hide textual content from search engines or users.

posted by erisfree at 6:47 PM on December 29, 2004

Funny, it didn't adjust for me.
posted by Civil_Disobedient at 6:50 PM on December 29, 2004

When the page is loaded the text scales to the users font settings. If the settings are changed then the javscript needs to be called again, the font size redefined and sent to Flash: so a refresh is required.
posted by andyhume at 7:02 PM on December 29, 2004

I heard about sIFR couple of weeks ago and while impressed, wasn't too impressed. Then I read Mike Davidson's Introducing sIFR, played the demo movie and drooled like a design fanboy. It's cool. It's not a total fix, but it's a great tool.

And that, I think, is the problem.

Like the initial introduction of tables, people are going to use sIFR for all sorts of things it wasn't intended to do and 5 years from now we're going to have to redo pages for when the css equivalent of rich type finally hits the web. sIFR is fine tool for limited uses, but how many designers are just going to use for those few uses?

sIFR is a Band-Aid. It's one of those colorful, Walt Disney bandaids that you thought was kooool as a kid, but it's still a band aid.

When is the web going to be fixed so we don't have to hack it in order to get rich type? And for those who question "does the web need rich type", I'll be first to say, No, it doesn't need it. But it can look really good with it, so lets do it.

Still, as a primarily print designer, I can't help but wonder why the open source nature of the web hasn't produced the web equivalent of Postscript (the page description language which made desktop publishing and fonts BIG TIME). It seems like the wheel is being reinvented which frustrates the hell outta me as a print designer: these problems have been solved, can't we learn from those solutions and adapt them to this need medium?

It should be noted that web growth shows no sign of stopping despite the lack of rich text controls. Food for thought, eh?


Yeah, this is an idealistic philosophy, but I always liked the idea behind The Dao of Web Design. sIFR is good, but perhaps we should look deeper to solve this "problem".
posted by Brandon Blatcher at 7:08 PM on December 29, 2004

I'm gonna leave now (I think I've got my $5 worth in) so perhaps I won't have the final say on this here but...

To anyone still reading this thread who is new to sIFR, it is something you must look in to despite the difference of opinion here. It may be for you and it may not be - but don't rule it out.

It's not a question of ASCII vs. Binary or anything else these purist engineers will spout about what the web should be. It is about progress towards making the web the best it can be. If we wait for the W3C to dish out new specs, and the browser makers to implement them, we will be stuck in the current web for for the next 10 years.

The views of majick (despite their good intentions) come across as arrogant. It's a proclomation that something is evil because he himself doesn't use it... simple as that. Why go so far as to say that it's bad for everyone? If it was, clearly no one would be even interested in it.

Oh, and Brandon who's just popped in:

I think you are absolutely right about this being a stop gap technology. As I've said before, it's a hack. However, it's not a hack that is gonna do us any harm in the future. sIFR places presentation on top of a structurally and semantically built document; it will be no problem removing it once a true solution comes our way.
posted by andyhume at 7:39 PM on December 29, 2004

Arrogant is chuffing 10k down the pipe to make your 25 character headline especially fancy if the end user has the right version of the right proprietary software.

I had hoped to keep this from sinking further into the quagmire of a slugfest; hopefully I've managed to convey the (apparently now unhip) notion that one of the best things about the web is that I, and I alone, control how it looks. For me. sIFR, in most cases, takes a little bit of that away.

Never let it be said I don't appreciate the cleverness. I just can't see the value of running the end user through a known-rickety code path for the sake of a headline font. Certainly not in a production application. What clever hacks people want to put on their home page is purely a matter of individual choice.

In any case, thanks, Andy, for popping in and informing us, and above all, keeping a level head in the face of arrogant trolls.
posted by majick at 8:08 PM on December 29, 2004

sIFR does not affect search engine placement or ranking

Funny, I did a Google search on Pedro Martinez, and the only ESPN hits that turned up in the first 6-7 pages of results are two that don't use sIFR. There's Pedro's banner, in a homely old non-anti-aliased SPAN that, mirabile dictu, seems to have been indexed much better.

It's a proclomation that something is evil because he himself doesn't use it

Pot, kettle, black.
posted by gimonca at 8:17 PM on December 29, 2004

sIFR is compatible with all screen readers. No problems or issues have ever been reported.

Starts up ZoomText, hits *dictate*.. beep.. nothing.

of course, tihs isn't a formal "report", so I'm sure this little bullet point will stlil be there despite the fact that it isn't true.
posted by Space Coyote at 8:22 PM on December 29, 2004

I'm looking at ESPN's actual site...

This page has a headline in Flash. Firefox 0.9.1 on WinXP, increase or decrease text size affects most text on the page, does not change the size of the Flash headline at all.
posted by gimonca at 8:53 PM on December 29, 2004

Oh, and I did a refresh each time. No difference.
posted by gimonca at 8:57 PM on December 29, 2004

Without criticizing this font thingy, javascript, Flash in general, or anyone on either side of this argument, here's my take: I have much greater respect for web developers who create beautiful sites within the onerous limitations of clean, usable, cross-browser design. Sure, you can do all kinds of "fiendishly clever" things with Flash and javascript and anything else that limits your potential audience, and sometimes you just have to. But it's not something you should be proud of, roughly the same way filming a stage play shouldn't make a movie director proud of his mastery of the cinema.

This, incidentally, is why our host Mr. Owie is so highly regarded.
posted by rusty at 10:20 PM on December 29, 2004

God, another attack of "the enemy of good is perfect" metafilter crowd. You know what. Don't fucking tell me how to design my webpages. I kinda think this thing is cool. I might not put any content in it, but if I wanted a title to look shnazy and anti-aliased, I might use it. If your one of the infinitesimal curmudgeons who worked hard to uninstall flash then you'll see the alternate browser rendered text.

If you've setup some contraption to filter all flash files and show goatsx anuses to stick it to all the ad-supported sites because information I worked on all fucking night "wants to be free, man" then fuck you.

If you don't visit sites because they don't validate XHTML and uses tables (gasp!) for layout, fuck you.

If you shit upon other peoples work that they do for free to help out their fellow fucking man, who have tried hard to address both usability and the real fucking world where 99.999% of people could give two craps about the "semantic web" and sometimes judge a site on whether it looks, you know, professional, then....

Well, I've gone and lost my train of thought, but I think the point of it was, fuck you, you luddite holier than thou self appointed police of right and wrong on the web.


So, besides all that, there are some good points here, namely, that in the real world of web tools and tricks, there are no absolutes, and getting religious about things is stupid. There are best practices, and admittedly, those I just railed against iterated many of them. But best practices are guidelines and breaking them is not felony, and if you know what your doing, and your smart, breaking them can be just the right thing to do.
posted by PissOnYourParade at 11:17 PM on December 29, 2004

If you want your or your client's page headlines to be replaced with plugin placeholders asking me to approve a plugin in that location, by all means, use this technology. If you want to piss off people who want to dynamically resize text and select it without jumping through hoops, you can use it too.

I know the poor choice of fonts and lack of font download is a problem on many platforms, but this is too much of a hack to be useful. Though the hack itself is impressive, yeah.
posted by azazello at 11:38 PM on December 29, 2004

Whoa, piss, a little hostile there, huh?

Tell you what, you can design your webpages the way you want, and I'll view other webpages the way I want, OK? And when I stumble upon the train wreck that your page will be in my browser, I will just close that window.
posted by azazello at 11:44 PM on December 29, 2004

JP Hong: I've read some dumb shit on Mefi but this one is a standout. And what about all those annoying 256 colors, do we really need all them?

Heh. You really think the designers should have total control of what you see in your browser? The reason why we have to use plugins like adblock, pop-up blockers, HTTP proxy filters like Proxomitron, etc. is because users want to view sites the way THEY want to see it, not some designer's conception of what "looks good". Fonts are a prime example. Imagine what the web would look like if web designers didn't have to stick to web-safe fonts or could impose any font they wanted on the user. God, that would be horrible.

The color limitation was a technological one, that was surpassed with better graphics cards and monitors. New fonts, on the other hand, do not add to an objectively better experience. I don't mind a variety of fonts, but forcing it onto the user via some ugly Flash hack is not my idea of progress.

I use Proxo to substitute my own CSS file for Metafilter because I don't like the blue background. I like high-contrast colors and if you're going to use white fonts I demand a black background. Likewise I use Proxo to set a minimum size font, since on my high-res screen small fonts are a bitch to read. I also disable all background images by default. White is good enough for me. I realize that I am in the minority of hard-core anal web surfers but most people would do what I do if they knew how to do it.

lodurr: Oh, please, give me a break. You know damn well that we'd be living in design hell if "web designers" could use any damn font they pleased at any damn resolution they pleased.

Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.

Hear, hear.
posted by aerify at 11:46 PM on December 29, 2004

Repeat after me, children; THE WEB IS NOT PRINT, THE WEB IS NOT CONTENT, THE WEB IS NOT HTML, THE WEB IS NOT PNG, THE WEB IS NOT LINUX, THE WEB IS NOT COOL FLASH GAMES, THE WEB IS NOT PICTURES OF CHILDREN URINATING ON RUM-BREATH SANTA CLAUS. THE WEB IS NOT A PLACE TO PUT PICTURES OF YOUR BABIES FIRST DIRTY DIAPER. THE WEB IS NOT OPEN SOURCE.

wait... what is the web, it seems to me to be the intersection of primarily http line protocol and ways to deliver data (content, games, anti-aliased fonts, e-commerce solutions) to clients designed to receive and parse it (primarily browsers, but also fat clients backed by web-services, neato DHTML app look-a-likes, streaming pornography video, etc)

At the present, for me professionally, the web is a condiut for a product that involves taking a legacy banking function space and making it available (and better, hopefully) by making it hosted and browser based.

Just as a single example, we have a requirement that a page displayed to a user look as closely as possible to a standard Bill Of Lading. Not just for printing, the way people work means that the look and feel during data entry is just as important as print performance. Want to try that using just your 'Best Practices' without breaking some rules. Good fucking look.

For you:
THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.

For me:
MY WEB IS WHAT MAKES THE GREATEST NUMBER OF USERS MORE PRODUCTIVE, WISER, MORE COMFORTABLE AND ADDS VALUE TO THEIR PROCESS.

I don't think that either of these are wong, but I get the distinct impress that you think my web is wrong and yours is right. And thats the part where my IQ drops 20 points and I find myself typing fuck every five or six words.

In other words, stop telling me what my web is and I'll stop telling you what your web is. I'm not doing anything to hurt you. If your not a user of my web, or if you don't like my web, don't use the product, I promise I won't come with a gun and force you to.

If the compromises I make are really onerous to the majority of my users, well then, the market will decide and I'll be back here begging for the full frontal nude tour of CSS Zen Garden. Luckly for me, all the whining and bitching seems to be exclusively on metafilter, where the intersection between my paying customers seems quite small.

Wikipedia is not the end all, be all of what the 'web' should be.

Man, you guys are going to be batshit when things like Lazlo and Flex
become popular (and they are, whether you like it or not)
posted by PissOnYourParade at 12:57 AM on December 30, 2004

Has anyone even looked at the embedded font links I provided above? The ones that only work in IE? Because THAT is a seamless solution.

I know it's not *cool* to admire Microsoft and their proprietary shit, but this is one case where they got it right, and everyone in their antitrust zeal is overlooking a truly perfect technical implementation.
posted by Civil_Disobedient at 1:22 AM on December 30, 2004

If you are having issues with sIFR not doing what it claims to do, a good course of action would be to email Mike with your browser details and the problem you are having. Bickering about its shortcomings on Metafilter isn't the best way to improve the technology.
posted by erisfree at 3:57 AM on December 30, 2004

After rereading this thread again, I've come to this conclusion:

sIFR is a start. It's not perfect, but it has improved since it was created and looks to continue to improve. So lets see where it goes.

Being able to change headlines is nice, but hardly earthshattering. Let me know when I have the same or near control as QuarkXpress did ten years ago.
posted by Brandon Blatcher at 4:33 AM on December 30, 2004

I haven't looked at the example of ESPN that "doesn't work", but before anyone rushes off to report it please check that it is actually sIFR being used.

If it doesn't scale it is not sIFR. Make sure if you are testing sIFR you are using the latest demo page
posted by andyhume at 4:50 AM on December 30, 2004

Oh no, I'd never want to look at a real-world example. Let's stick to carefully controlled demo environments where we think it maybe works.
posted by gimonca at 5:30 AM on December 30, 2004

Laszlo technology is an open source XML-native platform for building rich client applications that deliver a breakthrough online user experience.

That Laszlo sales page is definitely buzzword-compliant...but everything I right-click on is still Flash. Nothing new here--the "new" stuff in the Behr paints site is awfully similar to something I saw done in Java years ago. And Flex is just another Macromedia tentacle.

It's not open-source, it's all proprietary and Flash-based. Or to put it another way: it's not the sex, it's the lying.
posted by gimonca at 5:48 AM on December 30, 2004

You know, brining rich text to the web sounds like a perfec t Open Source project, hint, hint, for the developer reading.
posted by Brandon Blatcher at 6:01 AM on December 30, 2004

... but I get the distinct impress that you think my web is wrong and yours is right.

And I get the distinct impression that you're taking things too literally.
posted by lodurr at 6:45 AM on December 30, 2004

OK, to recap. Here's the good stuff about sIFR:

• It degrades gracefully, and is thus friendly for screen readers, search spiders, and syndication.
• It works as designed the great majority of the time.
• It looks great.

Here's the bad stuff:

• It adds about 10K, processing overhead and another HTTP turnaround to the total page impact (page weight + system overhead + net latency).
• It uses proprietary software to render the text.
• It requires about $500 worth of proprietary software to create the text.

Additionally, as a side-effect of [Bad.3], it tends to restrict page development and creation to the design shop -- "where it belongs", some people would say, but I respond, "where it costs more." Take that as literally as you wish; cost is a broad and deep concept, and one misunderestimates it at one's peril.

sIFR is a neat, elegant solution to an anal-retentive design problem; it's a really clever and elegant hack; it's a fantastic example of how to stretch the DOM without breaking it (because, really, sIFR is absolutely not a hack in that sense -- it uses the DOM exactly as the DOM was designed to be used). But it's not a solution. It's still a hack -- a band aid.

Where sIFR will get really interesting is when people start using the techniques behind it to do other things.
posted by lodurr at 7:00 AM on December 30, 2004

BTW, piss's "Laszlo" and "Flex" are examples of my last point. And the fact that piss thinks we'll be pissed by them illustrates quite well how much he misses the point of most people's objections to the idea of using a technique like sIFR for trivial applications like page headlines.
posted by lodurr at 7:04 AM on December 30, 2004

Repeat after me, children: THE WEB IS NOT PRINT. THE WEB IS ABOUT CONTENT.

Except for MetaFilter, which is mostly about discontent. :o)

I expected a yawn or two at most when I posted this. I’m not strongly for or against sIFR but it’s been interesting to follow the discussion. I’m going to keep looking to see what sIFR or something similar develops into.

On his site, Mike Davidson wrote: ”I’d respond on the Metafilter thread myself but I don’t feel like paying $5 to join.”

I e-mailed Mike Davidson and offered to post any comments he’d like to make here and he politely declined.
posted by Termite at 7:17 AM on December 30, 2004

Civil_Disobedient: MSFT's embedded font technology is indeed nice. I wonder why most web-designers won't balk at using IE-only Javascript, but will use flash or gfx for type?
posted by sonofsamiam at 7:24 AM on December 30, 2004

Regarding the MS "solution", quoting quasimondo:

I looked extensively at WEFT and here are the three major problems with it:

1. It only works on IE/PC.

2. Microsoft clearly isn't supporting it anymore.

3. It only looks good on XP with ClearType turned on. I don't know about you but I can't stand ClearType. Unlike OS X's anti-aliasing, I find it actually makes normal body copy look worse.

WEFT would be fabulous if it worked better and in other browsers, but it appears dead-in-the-water at this point.
posted by spock at 7:47 AM on December 30, 2004

It adds about 10K, processing overhead and another HTTP turnaround to the total page impact (page weight + system overhead + net latency).
* It uses proprietary software to render the text.
* It requires about $500 worth of proprietary software to create the text.


It also REMOVES the need for however many K of images you are currently using to display a title or headline in a particular font. For virtually every site that uses it, sIFR is going to result in a net weight LOSS. I don't even understand the "another http turnaround". To load an external javascript? It is the same as loading another 10K image. Again, if you no longer have to use that typographically keen gif or jpeg you've just reduced your number of http calls.

"It uses proprietary software to render the text?"

Proprietary software that is free and nearly ubitquitous. Look, I'm a huge proponent of Open Source software, but getting things bundled so they are there when the customer takes the computer out of the box is not their strong suit. If we only want Linux people to be able to see your hack after they install the right combination of plug-ins or utilities, be my guest and write one. If you aren't a Linux guy, then your attitude is indefensible (unless you want in uninstall all proprietary software from you machine, including the operating system, immediately.)

Finally, it requires NOTHING to create the text, which is why you can download and run the sIFR demo even if you don't have flash. (It includes a couple of fonts in .swf format).

If you have Flash, you can create your own font files, but you can also grab ones that other people have made (just like you can grab images that other people have made). I expect there to be loads of places to do this soon. I don't expect that the type people will be too happy about this, but I don't see what they can do about it was made the .swf file from a font that you legally have on your system. If they are going to get upset about that then they should get upset about PDFs which are also documents created and distributed with their fonts.

From the production side, sIFR is for web designers. Odds are they already have Flash. From a consumer side, you only need the flash plug-in and that is only if you care to SEE the sIFR effect. If you don't have it (or have javascript turned off) you will see the plain text you would have otherwise seen.

Choose to use sIFR or don't. But don't expect to mandate that everybody make the same decision that you came to.
posted by spock at 8:11 AM on December 30, 2004

Well, this certainly has gotten heated, as I expected it would. Here's one more complaint about sIFR:

It's said to "degrade gracefully," in the cases where the user doesn't have Flash, or doesn't have JavaScript, or has disabled one or the other. Usually, this is not someone's choice, but rather a limitation of their platform or browser. Now, it's nice and all that sIFR does degrade nicely, and leave these users still capable of reading the headlines... but here's the real question:

What about those users that have Specifically Asked that all of their text content be delivered in a particular font, or at a particular size, as the majority of browsers enable them to do? This isn't a case of a platform or browser limitation, but for the large part, is the result of the user consciously choosing this option in their browser's preferences.

For those of you that don't believe the web is about the users, I doubt you'll even understand why I'm asking this question, but for everyone else, let's talk about sIFR and whether it respects these users' choices. Does it? I don't see any evidence that it does.

In my opinion, sIFR should be able to detect this setting (not even sure if this is possible, is this part of the DOM? methinks it somehow isn't...) and turn itself off in that case.

Why? Because the user asked you nicely and did so consciously for some particular reason. CSS respects this just fine. With CSS, designers are not the Gods of the web. They're more like patron saints, who kindly suggest methods of presentation, but ultimately concede to the users' needs in the end. Why are we abandoning this in order to "preserve branding"?

Here's an idea. If you're hell-bent on using your own fonts, your own margins, your own leading, your own kerning -- Use a PDF. I would really much rather you do this. Honestly. If you're this concerned about your "branding," then that is where you should be looking. PDF's are designed for this purpose, the web is not. I'm not talking "yours" and "mys" of the web. I'm talking the reality of it. The web is not designed for the designer. It is designed for the user.
posted by odinsdream at 8:23 AM on December 30, 2004

odinsdream: I went to your personal site and could not believe when I was assaulted by that patterned graphic at the top of your screen. Perhaps it would have been better if I could have changed the colors or increased the line thickness of the pattern but there was no way to do this! What do you expect me to do, turn off images just so I never have to see that single graphic? May I remind you that the web is not designed for designers but for the user!
posted by gwint at 8:41 AM on December 30, 2004

Is it just me, or does the headline on the ESPN page to which gimonca links look a little too fuzzy? Is it the years of browsing sites without anti-aliased fonts that have made me accustomed to the horror that is non-anti-aliased text?

As near I can tell it's a nifty hack, but if it matters so much to the pointy haired types just specify the font and install it on their machines for them.

I of course am expecting to see people using this to replace their h1 header graphics, not their h2 and h3 headlines.
posted by codger at 8:41 AM on December 30, 2004

I get a little irritated with the "Inman" thing. Couldn't we just call it DOM Flash Replacement? I've been doing almost exactly the same thing for about a year now without naming it after myself.
posted by 4easypayments at 8:45 AM on December 30, 2004

I wonder why most web-designers won't balk at using IE-only Javascript, but will use flash or gfx for type?

Because they're STUPID.

Regarding the MS "solution", quoting quasimondo:

Hey, here's a little advice. OPEN IT UP AND CHECK IT OUT FOR YOURSELF. Jesus, does someone else have to do all the thinking for you. Check it out. For yourself. Here's the link again in case you missed it. You don't even need to install Internet Explorer. If you're using Windows, you can cut and paste the address into the file explorer.

See, if you actually looked at it yourself, you'd notice that it looks great without needing ClearType. I don't use ClearType, either, because I'm not on an LCD panel. Yet it looks perfect. PERFECT. I wonder why your savior would mislead you?

As for it working only in IE -- well, heck, the Flash method only works for people who have Flash installed. And aren't actively BLOCKING it. That's a lotta' meatballs.

And "Microsoft clearly isn't supporting it anymore"? That's funny, because I didn't install jack shit, and yet it works fine for me. So I would contest that it's supported quite well, actually. The reason you're not hearing about it anymore is because all the "cool kids" are dropping the ball in favor of hacks that will never be as elegant.

WEFT would be fabulous if it worked better and in other browsers, but it appears dead-in-the-water at this point.

So why not push for it? Why not try and get Mozilla The Great to support implementing it? It's obviously a great idea, there's already a working implementation that makes for a great proof-of-concept. What's stopping them? Blind, seething hatred of all that is Microsoft. That's what.
posted by Civil_Disobedient at 8:47 AM on December 30, 2004

Shaun Inman's site is excellent at using all of the CPU on my Powerbook under Safari.

One should always strive for a web page to use all CPU resources since displaying text is not a hard operation - making it harder is always desirable. Always.
posted by MrFancypants at 8:55 AM on December 30, 2004

What about those users that have Specifically Asked that all of their text content be delivered in a particular font, or at a particular size, as the majority of browsers enable them to do?

Look sIFR is a tool. sIFR doesn't "respect" anything. Don't anthropomorphize sIFR. It hates it when you do that.

That being said, any tool can be used for good or evil. sIFR is best used for replacing headlines. Is there a way that that the user can specifically choose what font/size h1-h6 tags are displayed (as separate from other text?) I'm just askin'. Cause that is the smart way to use sIFR (imho). The user's preferences are respected, except for those tags that you choose to replace (like h1 or h2, for instance).

Again, since sIFR is great at replacing that gif or jpeg that you were displaying your title or headline in 30 point insert-font-name-here, it is an improvement over that approach. The user couldn't dictate the size of the text in that gif or jpeg either. And sIFR scales. How is this bad?

I think a page looks tremendously better with just a touch of typographical originality on the page. It is subtle, but that is what typography is. I only want to use sIFR in specific places on pages I design. As a guy who loves typography, I think sIFR is one of the coolest, most important things that I have seen for the web in a looooong time.

Web designers make choices every day. Bad choices make viewers go away or not stick around to see the page load. Web designers (in general) stop using bad tools and making bad choices. It's a free market system. Let's run sIFR up the flagpole awhile and see if user's salute it.
posted by spock at 8:57 AM on December 30, 2004

Civil_Disobedient: Bill Gates, is that you?
: )
Microsoft apologetics: There is nothing worse than a bully with a persecution complex.
posted by spock at 9:04 AM on December 30, 2004

odinsdream: I went to your personal site and could not believe when I was assaulted by that patterned graphic at the top of your screen. Perhaps it would have been better if I could have changed the colors or increased the line thickness of the pattern but there was no way to do this! What do you expect me to do, turn off images just so I never have to see that single graphic? May I remind you that the web is not designed for designers but for the user!

gwint, are you being purposefully dense? My site uses CSS to suggest that your browser display that graphic pattern in that particular location. With your own CSS file (which Safari, for example, allows you to define in the preferences, while other browsers are a bit more tricky), you can easily remove that graphic by putting this in the file:

#header {
background-image: none !important;
}

You could even replace it with whatever other graphic you decide you like best. I'm sure you know this, you're obviously super-intelligent, but I'm letting everyone else in on the secret, too.

note: i recently moved servers, excuse the dust.
posted by odinsdream at 9:23 AM on December 30, 2004

For those that really care, sIFR was preceded by IFR. There have been multiple versions of sIFR and it is getting better each time. If you see a site that you think is using sIFR, check out the sifr.js file and see if it is using the latest version. Whatever is bothering you may have been corrected in the latest version and you shouldn't make hasty judgments based on somebody's implementation of a deprecated version. (Upgrading is normally as easy as simply replacing the sifr.js file with the new one, I believe.)

MrFancyPants: interesting. I'm curious: Have you checked if the same thing happens using other browsers? How long is the processor at 100%. What processor are you talking about, a G3 or G4?

As with anything related to page rendering, the faster processor will do a faster job of it and any delay (etc.) will be magnified for the user with the older equipment. This is a concern, though not necessarily a fatal one (imo). I'd like more info on what you are experiencing.
posted by spock at 9:23 AM on December 30, 2004

odinsdream: My (sarcastic) point was that a user can't change elements of an image-- as in, I like your tessellating pattern but it looks terrible unless the line thickness is doubled (not really, I'm just saying as an example) Some people feel the same way about fonts and other design elements as you did about that image. The only option a user has is to view it exactly as it is or turn it off. Same with sIFR.
posted by gwint at 9:36 AM on December 30, 2004

More data:

Tested the demo sIFR page in Jaws 4.51 -- Jaws won't read any of the sIFR headlines. All this talk of "accessibility" is just hot air. You might as well have .gifs with blank or missing alt attributes, you'll get the same result.
posted by gimonca at 9:43 AM on December 30, 2004

gwint, I know what you're getting at, but this is completely not the point I was making. Text is the blood of the content. It is not unreasonable for your users to want (and indeed to already have the ability) to control the text presentation to a very precise level. This is much different from the problem you made up out of thin air. (And, by the way, you Can redesign any page you view. Take my metafilter profile, for example. The same can be achieved anywhere you want with a user stylesheet. Really. This is what content/presentation seperation is about. Don't like ads on the sidebar here? Set their display property to "none" in your stylesheet.)

There are very few people who dislike only particular elements of a page, and wish to change them. There are significantly more people who dislike the font a webpage uses, or the size it presents the text in, and wish to change it. That's what this is about. Text.

We're creating a problem where there wasn't one before, only in the name of "branding" or "design preference."

Why should I not be able to specify the font, and have this specification respected? I don't understand your problem with users choosing their own fonts so that they can read the content successfully. This is at the heart of the matter. Users should be able to have flash enabled, javascript enabled, and still control their fonts.

That's why my site uses text in the way it does. My "dangerously quaint" heading isn't part of the header image. It's live text on the page, so that it gets scaled properly, and rendered as Verdana unless the user says otherwise. That's why I only experimented with PHP/JavaScript Dynamic Headline Replacement using Images. I thought it looked beautiful, sure. It was a lovely curly font, and it made the page look nicer in my opinion, but I decided against it since it wasn't the most readable font in the world, and users couldn't easily override it. (By the way, was that patterned graphic the only usability concern you could come up with viewing my site? I intend for my site to be as readable as possible, and you should be able to see the content no matter what browser or platform you're using. sIFR: not so much.)

If it's text: let it be text, and let the browser render it as it would any other text.
posted by odinsdream at 9:55 AM on December 30, 2004

Bill Gates, is that you?

We have your position and troops are on their way. You have no chance to survive make your time.
posted by Civil_Disobedient at 10:09 AM on December 30, 2004

spock: This is a G4 1.25Ghz Powerbook running OS X v10.3.7. Under Safari v1.2.4 it runs the processor to 100% - although everything is still usable, more than about 20 seconds there and the fans kick in (and it uses more battery power of course).

Under FireFox 1.0 it "only" uses 69%, but goes to 75% or higher if I try to scroll on that page.

Probably of significance (mostly in how browsers handle the content over that of anything interesting about the page) - in Safari the load is there when I have that page visible. But if I move another window to cover Safari so that I can no longer see the page, the load drops back to normal (fluctuating over various amounts but peaking at 9%). If I have that page open in FireFox, regardless of what window and/or tab has focus, and even if FireFox is totally hidden from view, the processor still hits 69-75% usage.

Safari has a few issues with pages that use a lot of JavaScript - I haven't bothered to look into his page any further than that, but it is probably something rather significant if it also is causing FireFox to exhibit similar behavior.

It doesn't prevent the system from being usable, it just causes it to heat up more and drain the battery faster. I only happened to notice it since I have a CPU monitor up at all time and tend to want to see what applications (either written by me or not) are using more resources on my machine.
posted by MrFancypants at 10:48 AM on December 30, 2004

spock: also note that this isn't a bursting of CPU usage, but a constant maxing out which sustains for as long as you are on the page (and it is visible in Safari, or just as long as it is loaded in any browser window in FireFox, visible or not).
posted by MrFancypants at 10:52 AM on December 30, 2004

It's telling that we're already into a discussion on CPU usage in a thread about typography. These are the kinds of pages I won't be visiting twice.
posted by odinsdream at 10:59 AM on December 30, 2004

Spock: It also REMOVES the need for however many K of images you are currently using to display a title or headline in a particular font.

Um.... Huh?

I guess I don't get this. Because it seems to me that the clearest and simplest alternative is to make the headline PLAIN TEXT, not an image. So, unless you assume that the only solution for displaying headlines is graphics, then your position is indefensible.

In fact, sIFR at base DOES SOMETHING THAT DOES NOT NEED TO BE DONE for the vast, vast, vast majority of cases. It doesn't neet to be cone on ESPN.com. It doesn't need to be done on any commercial site. Not if by "need" we mean that we're helping the reader in any way to understand the content of the site.

Why it does in fact "need" to be done on ESPN is because someone defined it as necessary, which has absolutely nothing to do with whether any user actually needs to see it that way. Whether the reason for defining it that was was "branding" or anal-retentive design is more or less irrelevant: It's a decision that someone made, divorced from any really objective evaluation of cost:benefit.

Now, if your cost:benefit calculations at your own site determine that you need to display some text in exactly a specific font for the subset of web users who have Flash installed


Proprietary software that is free and nearly ubitquitous. Look, I'm a huge proponent of Open Source software, but getting things bundled so they are there when the customer takes the computer out of the box is not their strong suit. If we only want Linux people to be able to see your hack after they install the right combination of plug-ins or utilities, be my guest and write one. If you aren't a Linux guy, then your attitude is indefensible (unless you want in uninstall all proprietary software from you machine, including the operating system, immediately.)

Finally, it requires NOTHING to create the text, which is why you can download and run the sIFR demo even if you don't have flash. (It includes a couple of fonts in .swf format).

Wow, so much here to respond to....

First, if the point is that you need to have a specific font show up in your headlines, you're not likely to find the SWF fonts you need at the sIFR site. If you can, great: You just saved yourself the $500 you'd need to spend to buy Flash so you can compile the font as SWF. (And we're both ignoring the font-licensing issues here, but I'm happy to do that since everyone else seems willing...)

Second, F/OSS is a red herring. F/OSS is not the same as open standards. "Proprietary" is not synonymous with "commercial"; "Open standards" are not synonymous with "non-commercial". Moz/Firefox, Opera, Safari and even IE work primarily via open standards. Flash does not.

For the record, I'm not "a linux guy". I'm writng this on a Win2K system that I could boot to Linux if I wanted to (at which point I would probably be able to see sIFR headlines just fine, thank you, using Mandrake's default Konqueror configuration). And in any case, I really just don't get your point, I guess: Why does it matter if I'm a "Linux guy" or "Mac guy" or "Windows guy"? I don't see you making a coherent argument for why that should matter.
posted by lodurr at 11:17 AM on December 30, 2004

Here's a sentiment that I see a lot in this thread, and in general, as expressed by Spock: "Bad choices make viewers go away or not stick around to see the page load."

Well.... No. Actually. No.

I can understand the source of the sentiment. We all like to think of the web as a technical meritocracy. It's not. It's an ecosystem. We like to think of evolution as something that produces best results, as we'd like to understand them. It doesn't. It produces optimal results, in the terms of the relevant ecosystem.

Bad choices degrade the user's experience, but maybe not enough to make them leave. If the content trumps the impact of degraded experience, then they'll stay.

Bad choices affect the implementation cost, but maybe not enough to get noticed, or maybe in a way that's hidden by the organizational structure or business process. So maybe no one notices that simple template changes now have to be routed through an irrelevant department, or have to be sent back to the design department to fix breakages.

Bad choices, in fact, only cause those choices to be noticed if the results of the bad choices have sufficient impact.
posted by lodurr at 11:38 AM on December 30, 2004

I heart majick. S/He gets the web.
posted by five fresh fish at 11:47 AM on December 30, 2004

It's not a question of ASCII vs. Binary or anything else these purist engineers will spout about what the web should be.

Now there are people on the sIFR page complaining that they can't do something as basic as an ñ. Obviously no character set issues were even considered.
posted by gimonca at 12:01 PM on December 30, 2004

So, to summarize sIFR:

Advantages:

• You can use any font you want on a webpage

Disadvantages:

• To use any font, you must purchase Flash for $500


• Users must have flashplayer and javascript installed and enabled


• Users must not block or toggle flash objects


• CPU usage may border on a constant 100% in some cases


• Significantly more bandwidth will be used


• Full character sets may be unsupported


• Font size rescaling does not occur until the page is entirely reloaded. No dynamic text scaling occurs, even with browser support for dynamic text scaling


• Highlighting sIFR text alongside other text will cause visual anomalies


• Users with flash and javascript installed and enabled cannot override your font choice (arguably an advantage, a reality nonetheless)


• Screen readers do not understand the text

Ok, I think that clears things up. I'm with civil_disobedient on this one. Stick to the embedded fonts that Internet Explorer supports. You'll save people a lot of headaches, still have a sigificant audience seeing your chosen font, won't have to shell out for Flash, and possibly help the web to move in a more sensible direction in regard to embedded font support.
posted by odinsdream at 12:32 PM on December 30, 2004

I'm torn by this thread. On the one hand, sIFR is a really profound example of the kind of power you can wield via the DOM, and I admire the out of the box thinking that went into creating it.

OTOH, I don't think it needed to be done. Especially not on commercial sites, and especially not on sites that are already heavy with plugins and clutter.

I also think it's unfair to rag on them for not supporting extended character sets -- hell, some typefaces just don't support those characters. I also know that these guys try hard to make it work, as a point of pride.

But at base, I have to think that using sIFR as a production tool in and of itself is a bit like commuting in a street rod.

On Prev: I'll get behind odinsdream's summary, FWIW.
posted by lodurr at 12:36 PM on December 30, 2004

Bad choices degrade the user's experience, but maybe not enough to make them leave.

Definately no. Case in point: my SO just had to reboot her computer (old, Windows 98) because she tried viewing Salon, with it's craptacular Flash ads. The system came to a standstill. Completely halted. I honestly doubt she's going to be visiting it again any time soon.
posted by Civil_Disobedient at 1:04 PM on December 30, 2004

So that token amounts to "definitely no"?
posted by lodurr at 1:49 PM on December 30, 2004

For her, yes. So it refutes your absolutist comment, "Well.... No. Actually. No." In some cases, actually, yes. Definately yes.
posted by Civil_Disobedient at 1:58 PM on December 30, 2004

Mike was kind enough to e-mail me about errors I made in my Summary above. I think it's useful to discuss, but I'll just paraphrase his replies:

For the complaint about having to buy Flash for $500:
Use a trial version, or use a friend's copy. Obviously it only applies to the page developer, which I said above.

For only working with flashplayer/javascript installed/enabled/not blocked:
That covers 95%-99% of visitors. The others will see CSS-styled text.
True, for those who don't have Flash "Click to View" plugins installed. He mentions that these blockers should report that the browser doesn't support flash, so that sIFR would show you text instead. This makes no sense. The browser does support flash, but the user is choosing which flash objects she wishes to view, before viewing them.

For the CPU usage disadvantage:
I was referencing an unverified claim by someone reading a site that wasn't using sIFR, or was using it incorrectly, or using it in too many places.

For the bandwidth issue:
Doesn't use more than image replacement. It's only a one-time hit. That's true, it doesn't use more than image replacement, which I wasn't considering. I was only talking about text. Just because it's supposed to be a one-time hit doesn't mean it will be. Cache settings vary between users, and cannot be relied on.

For the Character Set issue:
I'm just wrong, apparently they are supported.

For the dynamic scaling issue:
People who scale their pages read all their pages in the same scale, according to some study. Also, it should only be used for headlines. Well, I don't read all pages scaled. I scale pages when they need to be scaled, some pages don't need it. I'm sure other people behave differently, but the behaviour of the user shouldn't be relied on. Text scaling should scale text, shouldn't it? We don't need to reload the whole page to scale normal text... why should sIFR be different? Because it's a hack.

For the user losing font control:
sIFR shouldn't be used for body text. Only headlines. (The problem still stands, users do lose control of their fonts.)

For Screen Readers not being able to read sIFR:
I'm just wrong, apparently they can.


For the whole explanation behind these issues, e-mail mike about it. I'm not going to repost his whole email here, I just wanted to post his side of things. I don't want anyone to think I'm trying to insult the work done on sIFR. That's certainly not the case. It's very clever, and I respect the fact that people are looking for solutions, but I do still hold the opinion that this way is UnGood.
posted by odinsdream at 3:16 PM on December 30, 2004

Just a little demonstration of what I'm talking about when I question the sanity of sIFR. Here are two images, the first of which is before I click to enable the flash headline, the second is after I've clicked it.

Ok, first thing to notice: Only the top two headlines, about the Death Toll and the New Rave Drugs, were Flash objects. The ones on the bottom are real text, and showed up without any additional work on my part. Now, that's one complaint. If the technique is so great, why not use it consistently?

Secondly, after I click on the headline to show it, it looks almost identical to the real-text ones! I thought this was supposed to be about fancy design and style. I don't know what font is being used in the Flash headlines, but it looks almost identical to Verdana, which everybody already has. It looks close enough (if it isn't verdana) to safely use Verdana in stead.

I just... this is my fear. This usage is what I fear. It's senseless.
posted by odinsdream at 3:36 PM on December 30, 2004

For the Character Set issue: I'm just wrong, apparently they are supported.

Then why did three different people post to the sIFR site that they aren't working? They're not talking about some obscure scripts--the posters are trying to do Spanish, Portuguese, and (guessing from the name of the third) Italian. Those ought to be pretty much universal, seeing as they're all covered by ISO 8859-1. If they don't work, something is going horribly wrong somewhere, something that in a normal environment would never happen.

For Screen Readers not being able to read sIFR:
I'm just wrong, apparently they can.

Again, totally contradicted by the sIFR site itself. From a poster to that site:

Sigh. This means that this trick will not be accible for most blind users, as they tend to use a regular browser with a screen reader that reads the rendered page, not the source code (while Flash is installed by default and JavaScript must be enabled for most sites to work).

I've confirmed this live. My copy of Jaws skips past "The Quick Brown Fox Jumps Over the Lazy Dog" every time. The only way to avoid the problem is not to use the hack to begin with.
posted by gimonca at 4:01 PM on December 30, 2004

So it refutes your absolutist comment

If I had made an absolutist comment -- which I did not -- it would have refuted it. Here's what was said.

Spock: "Bad choices make viewers go away or not stick around to see the page load."

Me: "Well.... No. Actually. No."

Spock makes an absolutist comment ('If the page is bad people will leave'); I negate it ('No, actually, it's not true that if the page is bad people will leave'). That does not imply, in any way, that I'm sayign people always stick around. In fact, the context of my comment makes it clear I was arguing more or less the opposite. But since you seem to need it spelled out for you, I'll do that:

SOMETIMES WHEN THINGS ARE BAD ON A PAGE, PEOPLE LEAVE AND NEVER COME BACK. SOMETIMES THINGS AREN'T BAD ENOUGH THAT THEY DO STILL COME BACK.

There, is that clearer?
posted by lodurr at 8:28 PM on December 30, 2004

gimonca – I'm just telling you what Mike e-mailed me. I haven't tested it, and he's saying that sIFR does work with screen readers, despite what you guys are reporting. That doesn't make much sense to me, but I'm pulling his comments back into this thread where they belong.
posted by odinsdream at 8:50 PM on December 30, 2004

I tested it with Mac OS X's built-in speech software, and the headings on abcnews.com were spoken, even if flash click-to-view plugin is installed and blocking the flash object. Just saying.
posted by odinsdream at 8:54 PM on December 30, 2004

My visually impaired focus group is all Jaws/Windows users, so that's what I test with.

Are you sure abcnews.go.com is using the current version?
posted by gimonca at 9:27 PM on December 30, 2004

An interesting point of view, from Roger Johansson's web-design predictions for '05:

Typography-starved web designers go crazy with their new toy, sIFR, and use it for everything. The resulting slow-loading sites look like flyers from the desktop revolution in the late eighties because of their use of at least ten different fonts. Only this time, the text is anti-aliased. As more people install ad blockers, site owners will get complaints about missing headings and text. By the end of the year, sIFR gets mentioned in the same sentence as <marquee>, <blink>, and Java applets.
posted by ubernostrum at 1:56 AM on December 31, 2004