Since there is obviously a great deal of interest in it, a rational analysis of what sIFR means is in order.

At WE04 earlier this month I was asked on-stage once and a few times privately what I thought of sIFR, or scalable Inman Flash Replacement, the new Flash replacement technique. While I don’t for a second pretend like I know everything about it, I believe I’m familiar enough with its usage issues to offer an opinion. And that’s what this is, an opinion — take it with a grain of salt.

sIFR has evolved quite a bit in its year-long life cycle. Initially crossing my radar in October 2003, a lively argument between Mike Davidson (creator and maintainer of the code) and myself is still preserved at holovaty.com. Mike won, because he had obviously thought about it in great detail and had good answers for most questions.

Since that time, he and some others (notably Shaun Inman, hence the ‘I’ part of sIFR) have taken it much further, and solved many of the problems with the original version.

Pros

sIFR is easier to implement than any image replacement technique. Instead of manually generating each header through an image editor, you’re able to skip the editor completely. Elegantly, it will skim through an XHTML document and find the relevant bits, swap out the text and drop in the typographically rich replacement.

And that is what makes it so exciting. It’s a useful piece of non-intrusive scripting that adds an extra dimension to a page. And the scripted effect is by no means required, it degrades gracefully. sIFR allows for dynamically-generated snippets of text which can use any font, not just VerdanaGeorgiaArial. And that’s a major benefit to those of us resigned to the same five fonts.

The immediate reaction of purists and purist wannabes is, inevitably, ‘ew’. Invoking Flash is reason enough to cause the reaction, but using it for such trifling detail as a header? Who could be that insane?

Well, Mike was, and others were, and now sIFR is a real technique to contend with. But on to the cons.

Cons

First, as far as I’m aware, the accessibility of the technique is a question mark right now. I haven’t heard of any screenreader testing, and I’m unaware of anyone having done a more in-depth look into the implications on assistive technologies. (Update: Mike confirms that it has been tested, and appears to work just fine.)

And there are a few usability niggles. You can’t select the text within a sIFR headline. Well, you can… but not in the same swaths as you’d select body text. You have to make a separate pass for each. This is an improvement over image replacement, though, since no text within an image is selectable. (Update: Mike and others note that the text does get selected, there’s just no visual feedback mechanism.)

Text within sIFR also doesn’t scale. Well, it does… but only according to your font size when loading the page. Any subsequent instances of Ctrl + “+” are ignored, until you reload the page. This is also an improvement over image replacement, since no image-bound text has ever scaled. And I’m inclined to say it’s more a consistency problem than an accessibility problem anyway, since those who need the larger text size are more likely to be browsing with their font scaled appropriately to begin with.

Then there’s the dependency issue. If a user doesn’t have Flash or JavaScript enabled, then what? Well, without JavaScript they would get a gracefully-degraded HTML header, which is easily styled with CSS. Heck, you can even use image replacement at that point, if you really want. Without Flash, the JavaScript (presumably, I’m not clear on this, but I’d assume this scenario has been accounted for) will detect the lack thereof, and not attempt to apply the replacement, again defaulting to HTML headers. Not to mention that something like 97% of the population has Flash installed, and well over 90% have JavaScript enabled…

My personal peeve is speed. A page with more than one instance of sIFR has a much longer load time. Jeff Croft has pushed his adaptation of sIFR to the limit, and waiting for the headers to load so I can determine whether I’ll read the block of content below is a little irksome.

Finally just a little thing, but an important one — a sIFR header is able to act as a hyperlink. When I hover over a normal link to decide whether I want to follow it or not, I very frequently check my browser’s status bar to see where it’s taking me, and whether the destination in question is worth viewing. sIFR doesn’t have any way of reporting back to the browser where that link is going, so I don’t get the preview, and links become a little more blind.

One Solution, of Many

At the same conference I referenced earlier, Doug Bowman mentioned in his presentation that advanced techniques come about because someone was trying to solve a problem. sIFR is just that: a solution.

The problem is that there aren’t enough fonts in a web designer’s palette. We are technologically (and quite probably legally) bound to 5 or 10 fonts that we can be reasonably sure the end user has installed, and that’s all we’ve got to work with. Solutions have been proposed, and font embedding was even a part of the CSS2 standard (though it was ditched in CSS2.1 since no one uses it). But the problems are much broader, ranging from font licensing to delivery to rendering, so there’s no clear solution in sight.

sIFR is one proposed solution by those in the trenches. It works, it’s here today, it works around licensing problems, and despite the other problems above, it’s usable. It’s not the perfect solution by any means, but until the standards bodies, font foundries, and browser manufacturers can all agree on one thing, it’s what we’ve got to work with for now.

It may not be for you. Image replacement may not be for you either. I personally plan to continue using the latter, and may investigate sIFR at some point in the future, but I’m in no hurry to shake up my development practices at the moment. It’s one choice amongst many, but the important thing is having the choice.

This article is meant to provoke discussion, it is not the final word. Feel free to fact-check me and report back in the comments. The information in this article is true to the best of my knowledge, but without having used it or tested it I can’t be considered a sIFR authority.

Reader Comments

The reason I decided not to use siFR on my site is control. Yes there issues with speed (and also with sizing - I got some very weird font sizes in my experiments), but the fact that I can’t tweak kerning, or vary sizes/colours/styles within the text I find quite restrictive. Yes, its a pain making images, but I enjoy the freedom it allows.

In an age when fonts can be embedded in Flash movies and PDF documents, you’d have thought that someone like Macromedia would’ve created the technology to allow it in HTML.

Jesse: Yes, I suppose we could put the status bar thing in there via a combination of FSCommand and JS. I just didn’t think that was a very big deal, but maybe I can shoehorn it into the final release.

Jon: Yeah, sIFR is interesting in that it gives you a lot of control, but only by giving up some control as well. While I’m not sure the method will ever give you as much control as a hand-generated Photoshop image, I feel that it is better compared to the control you are given with browser text. Using browser text or sIFR is just a question of values and needs for a particular application. If you *need* your text to be exactly 24px and you don’t mind using standard browser fonts, browser text is better. But if you want to use a custom font and you can handle a headline somewhere between 23px and 25px, then sIFR may be a better solution.

Your point is a good one, but it all depends on what type of text you want to style.

For example, if you want a custom typeface for five headers, one at the top of each of your main sections, then by all means, make the images. It’s relativley fast and gives you the most control.

But, if you’re like ESPN, and wish to use a corporate typeface on every header in a site that’s thousands of pages big and updated by the minute, it’s unrealistc to make images.

Like most things in webdev, it again boils down to using the tool that’s best for the task at hand. Although weblogs are probably the most common place you’ll find sIFR (because us designers and bloggers are rather progressive), I really don’t think that weblogs are the target audience for it. The group it benefits the most is the newsy type of sites that require a particular typeface for branding purposes, but are updated way too often (and often by a CMS and non-techy users) to make image creation realistic.

I am sitting on the fence on this issue.
sIFR looks more or less OK for me, but I think I won’t use it unless there will be very clear need for that.

On the one hand, if I need to style two or three headers with sIFR code — overhead seems too big. On the other hand if I have enough headers and specific requirements for branding, this technique is appropriate, but then I run into performance issues.

sIFRed links are some problem. Not seeing url in the status bar is more or less tolerable (I like to see the URL, though).

Javascript code changing statusbar text was one of the first thoughts in my head, but hey - I have checkbox checked in my Firefox preferences page and that does not allow scripts to change statusbar.

For me the biggest issue is unability to open sIFRed link in background tab middle-clicking it. I guess that can be somehow fixed vith ActionScript and javascript magic, but I doubt it is trivial.

A little late to the party. We’re supposed to launch a big site at work tomorrow so I’ve been working 14 hour days (and I’m still at work).

One important thing that I think we’re all overlooking when conceding that browser text is just as good as flash-replaced text is anti-aliasing. The majority of you that have chimed-in live, work and play on OS X. Typical web fonts look great at any size in OS X (within the confines of your particular tastes, of course, Arial isn’t for everyone ;D), but 18px Georgia on a PC is a completely different animal.

Last I heard (and fact me if I’m wrong) ClearType is something that you as a user have to seek out and turn on (Display>Appearances>Effects>second drop-down) if you don’t want to feel like you’re playing Super Mario Brothers every time you visit CNN.com.

When I debuted (my that’s a funny looking word) IFR on my site, the large majority of emails I received were about how I managed to anti-alias my HTML text headers (only the observant ones asked how I was able to use a non-standard typeface).

And that’s really the allure of flash replacement for me. Not that I can use any typeface, but that my chosen typeface is anti-aliased for everybody. You can’t have one without the other. To the majority of users, an aliased 22px DIN is going to look just as mucked-up as any other aliased sans-serif at that size.

So W3C be damned, but if tomorrow they came out with a CSS or HTML extension that allowed any font to be used on any computer with all the major browsers spontaneous support, it would not be a suitable stand in for *any* image or flash text replacement technique unless it also provided anti-aliasing of reasonable quality.

And just to be clear, that’s an un-endorsement of linked sIFR text… not sIFR. Also, the contextual menu to open links in a new window actually *does* work upon right-clicking (as long as you don’t use the hovercolor function of sIFR).

Anti-aliassing has been mentioned that one big plus point. I’d say, it depends on the fonts and size used (and that is obviously not a limit of the technique itself). Mike D’s headlines look very poor on my Mac (sorry Mike), other sites do a much better job. Bigger text, fatty fonts works better, but on avarage, I’m still not impressed by the ability of Flash to display fonts.

Next, a reaction from a client to the use of image replacement for headlines (the client is using W2K): he felt very off balance, the difference between the smooth headlines and the jaggy body text (on a text-intensive site), and found the whole text hard to read.

There’s no doubt in my mind that Flash’s anti-aliasing routines aren’t as good as Mac OS X’s built in anti-aliasing, or as good as most of us can do in Photoshop. But, it’s beat the hell out of Windows non-anti-aliased text (by default) and even ClearType (in the unlikley event the user has turned it on).

On the sIFR debate in general:

I’m still having a hard time seeing even a single con to using sIFR in it’s element. So, if you aren’t in favor of sIFR, I’d love to know what you would have me do if:

- I have to create 500 headlines
- Each headline has different text
- There could be more headlines added at anytime by via my CMS by someone unfamiliar with HTML, Flash, or Photoshop
- The marketing department insists upon using the corporate typeface, which doesn’t happen to be Arial.

This may sound like ridiculous requirements to the average blogger, but they are precisley the types of requirements people deal with every day at news sites, newspapers, magazines, etc, etc, etc.

If there’s a better way, I’ll happily adopt it. And if there’s a better way, I haven’t found it yet.

I am one of the new converts to sIFR. I personally like the discussion points you’ve raised in regards to the fact sIFR is simply a solution to an existing problem. Although sIFR is in the trenches it still does a lot better than the previous experiements and forays I’ve seen and done in terms of web-based typography management (Microsoft WEFT, anyone?).

My thinking is that sIFR should be used in a non-invasive way, focussing on headings and major branding texts. It should add to the existing content, not completely override it.

This isn’t a light technique by most means, however it is one we’ve implemented on many occasions where we need precise control of type but have style (i.e., typeface) requirement issues.

Using a scripting language (say Perl) and an image manipulation package (something like ImageMagick), you can with little work create a mechanism where headlines can be auto-created once and used many times, and put in place with an image replacement technique of your choice.

I don’t know whether this is always a better solution to using sIFR or not, but it is certainly another option, another real choice that’s available.

Whenever this is released (Macromedia moves slowwww these days…) it should solve my main problem with sIFR, which is that while Flash type is anti-aliased and non-VerdanaArialGeorgia, it lacks fine-grade kerning, and its smoothing looks llke it is applied with the airbrush tool.

I’m looking forward to future versions of both sIFR and Flash to keep this momentum alive. Also, here’s another vote for FSCommand/JS status bar action in a future release.

You aren’t restricted to Flash, you know. If you have PHP access and can convince your webhost to add the GD2 and FreeType2 libraries (GD1 and FreeType1 is not good enough, you must have FreeType2 for really good anti-aliasing and GD1 is restricted to a 256 color palette), you can get excellent anti-aliased non-standard fonts in images created on the fly (refer to the imagettftext and imagettfbbox documentation on php.net). Of course, you’ve still got the whole text selection issue to sort out on your own, but at least it’s another avenue for fancy on-the-fly headlines. I personally created a CSS background definition on-the-fly via JS for my own site, but you could certainly use it in PPK’s method as well (ie. converting the headline from an h1 to an image tag).

I’m far from knowledgeable about Flash (dipped my toes in version 4 and haven’t really touched it since), but I think PHP generated images might offer a lot more freedom with headline image generation as well as being much less bandwidth intensive. I mean, you can rotate the text to display at an angle or merge existing images sandwich style (want to have an emoticon appear just overlapping the last letter of your text? PHP can do this easy). You can use multiple font-faces with a little bit of extra work (e.g. using a decorative initial caps type font as your first letter with the rest of the text being slightly less gaudy). The other bonus is that there is no plugin requirement: almost everyone supports images.

I won’t say it’s perfect, because there is a fairly significant learning curve when it comes to advanced manipulations of the text. Careful consideration must be made on how to handle large blocks of text that may fall outside of the allocated image dimensions (do you make the font size smaller or allocate a larger image?) There is no magical flag for center or right aligned text and I wouldn’t even know where to begin writting an elegant wordwrapping solution. I can’t say how well this scales from a server load perspective, either, since my own site gets all of 5 visitors a day.

D’oh. That is scaling, in some sense of the word. And when you throw in Cmd+Option+’=’, and Windows’ Magnifier, and any number of third-party add-ons that zoom the whole screen, there are myriad ways to make images scale.

Which begs the question whether a browser’s built-in ability to scale text matters much, in light of the other solutions a low-sighted individual potentially has available. (But of course it does, since more options are always better.)

Hey Dave, thanks for the review. A lot of the issues you mentioned have been discussed, and in some cases, resolved, in the comment threads at Mike’s site (but, okay, I don’t expect you to read those, they’re way too long) and at noscope (http://www.noscope.com/journal/2004/10/sifr and http://www.noscope.com/journal/2004/10/sifr-experiences
).

As you can read in the posts I linked to above most limitations of sIFR are due to Flash.

And indeed, sIFR won’t replace elements if Flash has not been installed.

In the end, of course, sIFR is but a solution. Flash files can get heavy, and the JavaScript isn’t that lightweight either. This accounts for almost all of the “delay” when compared to normal text. However, when compared to images for each text, sIFR is far more efficient.

Gabriel, the Flash elements are placed *inside* the replaced elements (effectively only the childnodes of the replaced elements are replaced). If I didn’t misunderstand you this means you can use it just fine.

David Ely, thats an option in Adblock. sIFR isn’t to blame for that :-)

1. Screenreaders. Yes, this technique has been tested in screenreaders by mikeindustries.com readers. Seems to work just fine. No issues have been reported.

2. Text selection. You actually can select all text in the same swath. The visual feedback for it is just absent. Try doing a “select all” on the page and pasting into a text editor. All the text is there.

3. Text scaling. Yes, you are correct on this. My feeling is that a) sIFR is best used on display type which is already large to begin with, and b) people with impaired vision probably always have their text zoom on so they will always get the bigger text.

4. No Flash or no javascript. If either of these conditions is true, you simply get your normal CSS styled browser text. No problems. The only edge-case would be if you browsed the web with CSS off and javascript and Flash on which is just a really weird combination. I’m not sure why anyone would do that.

5. Speed. Yes, to me this is probably my biggest pet peeve. Having to wait an extra second or two for headlines to pop in sometimes is a bitch. BUT, with all due respect to Jeff’s site (which is great, and I *love* it), the speed of his site has always been slow for me. Before sIFR and after sIFR. I haven’t done enough research to figure out if it’s filesize-related or server-related, but it has really always rendered kinda sluggishly for me. How fast sIFR headlines render is directly proportional to how fast the rest of the site loads so that is clearly an issue here.

In conclusion (for now), I’ll say this. sIFR is best used in moderation. It’s ideal use is for display type. One headline at the top of your pages. One title per post. That sort of thing. If you want to use it for 30 items on your page, even linked things, you may, but that’s when some of the issues you raise come into play.

For an example of probably the best sIFR use I’ve seen, check out http://www.prospermag.com . Now that’s a picture perfect application for it.

1. I think I’ve taken sIFR <em>too</em> far on my site. Like Mike said, it’s best used in moderation, for a handful of headers per page. Particularly on my full entry pages that have lots of comments, it gets slow. I intend to scale back the usage.

2. In regard to Mike’s comment about my site always having been slow: I recently (like three weeks ago) moved to a new server. My site was <em>horribly</em> slow before that, but I think the server-side issues are resolved now. Any slowness that still exists could well be related to sIFR, or other browser rendering issues.

In general, I love the sIFR technique. I think Dave’s review makes it pretty clear that it is, in almost every way, an improvement over image-based replacement. Is it better than plain ol’ CSS text? No — if you can live with your type being in VerdanaArialGeorgia.

Mike, Shaun, Thomas, and the others who have contributed to sIFR have done a brilliant job of pushing the envolope. Whether or not this exact technique ever becomes a widely-used sort of thing, I don’t know. But, I’m convinced that the work being done on sIFR will impact the way we handle type on the web in the future — even if it’s only purpose is to say, “Damnit, W3C, we <em>need</em> typographic control, and if you’re not going to give it to us, we’ll find another way.”

By the way…a while back I wrote an article entitled “Why sIFR Matters.” There is some overlap with what Dave writes above, but I do include a real-world example of how sIFR can make your life a helluva lot easier in some cases. If you’re interested:

I’m glad your site was mentioned, Jeff … it’s always been slow to load, and your newest redesign is the slowest of them all. You’re right, though, since the server-side issues have been “resolved,” I’ve noticed a slight speed increase.

I’m glad you plan on scaling back the amount of sIFR. You’ll make us return-viewers even MORE reason to come back. ;)

You guys are right, and I figured someone would mention it. With gd or ImageMagik, you can certainly create images on the fly. I’ve done this in the past, and while it works well, I just find that Flash meshes a bit better with my design side, I guess. Although I’ve got plenty of technical skills, I consider myself more a designer than a coder and I’d just prefer to work in Flash than in server-side code. But that’s just me. Server-side image generation is certainly a viable option here.

“However, certain actions such as .. writing text that can be seen by search engines but not by users .. may result in permanent removal from our index.”

The fact is: the text behind sIFR can still be seen by the end users, regardless of whether or not their system is capable of Flash or Javascript.

Textual content is different than the visual display of that content. sIFR deals with the visual display of the content - the text remains the same, it’s just how it gets displayed that gets changed. Mike Davidson is right in saying the techique is transparent to search engines. Fire up a text-only version of an sIFR enabled site cached by Google to see that there is no change.

“The textual content isn’t hidden or moved, from what I’ve done in testing of sIFR”

Aren’t there various bits of CSS that refer to

visibility: hidden;

in respect to replaced headings? I must admit to only a cursory glance through the example HTML page that came with the download so might have got the wrong end of the stick but if I haven’t then this CSS would almost certainly be enough to make a few engines take note. Especially if (as in the downloadable example) the styles are in the head of the HTML page.

“Anything that involves hiding or moving the textual content runs the risk of getting that page penalised by search engines.”

If PageRank spammers latch on to these CSS properties and Google decides to deal with this, they’ll have to consider the legitimate uses of display: none and visibility: hidden as well.

I’ve been using them for years, well before I even started doing full-on CSS-based layouts. They’re invaluable for DOM scripting. There are plenty of reasons why they’ll continue to be used on honest sites, so banning an entire site just because it uses hidden content doesn’t seem likely. It’s more likely that the hidden content just won’t be indexed, which is a much different prospect than outright blacklisting.

Aside from Dave’s point, which is true, the answer to your question Kev is no, sIFR introduces nothing whatsoever that would penalize placement in search engines. Original text is hidden via Javascript and the DOM… not directly with CSS. Thus, the technique is completely transparent to search engines.

“If PageRank spammers latch on to these CSS properties and Google decides to deal with this, they’ll have to consider the legitimate uses of display: none and visibility: hidden as well.”

Spammers already are. As far as Google dealing with it, they don’t ‘have to’ consider the legitimate use of anything, they play by their rules.

“Original text is hidden via Javascript and the DOMâ€¦ not directly with CSS.”

The point is that its being hidden, not the technique used to hide it. This quote taken from Google:

“However, certain actions such as …writing text that can be seen by search engines but not by users…may result in permanent removal from our index.”

Its a matter of interpretation. Its a fact that Heading tags seem to count in some engines algo when they calculate a pages credibility therefore anything that would appear (as oppose to is) to be against these rules is unfortunately likely to be classed as dodgy.

Google might not be able to detect these uses automatically but you run a risk of being reported and, as indicated above, removed if you use techniques that are interpreted as being dodgy.

“As far as Google dealing with it, they don’t ‘have to’ consider the legitimate use of anything, they play by their rules.”

If I had time, I could probably find you dozens of big-name .com sites that use display: none for various purposes. I don’t have time, but my point is that you’re telling me Google will block these large commercial sites, as well as tens of thousands (or hundreds, or millions) or smaller sites just because some spammer got ahold of an improper use for a legitimate technique? You can continue believing that if you want, but I don’t.

Furthermore, if we’re going to get technical, sIFR *necessarily* reproduces the very text that it replaces. With a lot of image replacement techniques, you could easily replace the word “Apple” with a hand-generated graphic of the text “Orange”, thus creating the possibility of trickery… but with sIFR, what gets sucked in is what gets spit out.

At this time, it’s my understanding that Google calculates PageRank on XHTML alone, so we are just talking theoretically here.

The idea of CSS and JS affecting ranking results is a what-if at the moment… a strong what-if though, due to the potential for abuse. And that’s where Kev’s argument stems from. I understand the concern, I just don’t share it, based purely on logistics.

My main issue is with replacement techniques as a whole. Anything that involves hiding or moving the textual content runs the risk of getting that page penalised by search engines.

Its a shame as I’d like to make more use of various replacement techniques but I don’t think any technique that results in a possible ban from Yahoo or Google is a good thing to use and if you’re banned, you can’t be easily found - whats the point of a great looking site no one can find?

“but my point is that you’re telling me Google will block these large commercial sites, as well as tens of thousands (or hundreds, or millions) or smaller sites just because some spammer got ahold of an improper use for a legitimate technique? You can continue believing that if you want, but I don’t”

I’m telling you no such thing at all. In fact, I’m telling you nothing. I’m *suggesting* that its a possibility. At the moment there are clear indications of the penalties involving hiding or moving textual content. There are no clarifications forthcoming from Google on how they view such a technique as sIFR. I know this for a fact because I mailed them to ask awhile ago regarding standard image replacement techniques. They pointed me to the guidelines I quoted above and said nothing else on the subject, despite a request for further clarification.I personally find that ominous.I took it one step further and asked the opinions of a group of SEM specialists at High Rankings forum and they said they wouldn’t use such a technique because of the risk of being banned. I found this equally ominous.

“If that’s correct, then there is simply no way that Google would even know if the text was hidden, replaced, or anything else in the visual presentation.”

Not automatically no, there’s no way I know of for an engines algo to parse anything except markup. I do know of instances where sites have been reported for hiding or disgusing text and said sites have been removed. As to whether the sIFR technique would be classed as a ‘safe’ method of hiding text, that would be for each individual engines to decide for themselves.

re: the two comments from Mike and Lawrence. I disagree that this is not an issue. IMO, its enough of an issue for me to drop plans to use this technique on production sites. I’m sure if clients understood the risks then they would also be concerned.

I completely understand how sIFR and other image replacement techniques work and I understand that sIFR is different then the other techniques but really, its not me you’d have to convince. Its all the search engines that matter. Believe me, I’d love to use such a clever amd useful technique but this is one of those times when I think the unknown risks outweigh the potential benefits. It would be nice if the engines could clear up their stance on such things but I doubt they will.

“At the moment there are clear indications of the penalties involving hiding or moving textual content.”

How is sIFR hiding textual content ?
The text-only cache on Google shows exactly the same text as the sIFR rendering I run.

How is sIFR moving textual content ? All it’s doing is giving a visual display change to the existing textual content - it’s not moving it anywhere (e.g. offscreen).

Kev, I’ve tried finding any sign of a supposed panning of image replacement techniques on Highrankings and I can’t seem to find this supposed claim that people in the SEO community wont use image replacement “because of the risk of being banned”.

I also just want to point out that there is just no way that Google would ever be able to automatically penalize any site based on css/js hidden content. There are just too many ways to hide/replace content using CSS and Javascript that writing something to read all the different ways to figure out what is hidden and what is not would be impossible.

So this means that a human would have to look at your site, and I think I have enough faith in google employees’ common sense that sIFR wouldn’t be an issue.

It does kinda suck that people have to be so paranoid about it though, since google is by far the dominant search engine. It makes them the wal*mart of the internet, able to strong-arm developers into doing what they like, which I think is partially a good thing with getting people to use well structured code, but on the other hand, could be stifling new development and experiementation… but i guess that’s a whole other conversation.

Does Google just go willy-nilly banning every site that has been reported? I doubt it.

I’m sure it’s possible your site could get reported. But then, isn’t a Google employee going to go and look at your site, see that you’re not doing anything shady (or are you?), and let your site be?

As with most so-called SEO, what we’re talking about here is trickery. If you stop trying to trick the search engines into higher results, and concentrate on writing good code and popular, useful content (which results in links to your site), you’ll be just fine.

I’m sure Google doesn’t appericate it when someone tries to trick them using any method. sIFR and other replacement techniques could be used for this purpose, and if someone does it, they deserve to be penalized. But, I have faith in Google to be able to tell the difference between rightful usage of image replacement and shady usage, just like they’ve been able to do with keywords and all the other SEO trcikery.

I’ve had to deal with google before, and we went through several emails back and forth over a course of two weeks before any sort of action was taken. This was regarding their ads. Aparently they found some deep forum post hidden in the depths of my ancient archives that promoted “not clicking on the ads unless they interest you.” Aparently to google, they thought it drawed too much attention to them and thus violated their policy.
The emails that went back and forth were basically trying to figure out what rule I violated and on what page it occurred.
Once they sent a link to the page, It was as easy as removing it with the click of a button, and all was well. So if any lesson is learned, you’ll definitely be warned before you’re penalized.
I’d say it’s safe until you’re warned. So far I’ve heard none of the big dawgs get hit up and asked by google to remove it.
And when the big dawgs are unleashed, the puppies follow….

re: the wider points. I don’t think that this is necessarily a massive issue but Google’s recent behaviour is something of an unknown and I personally don’t want to be penalised. I hope I’m not scare mongering but I do think this is a genuine concern.

I agree there’s not a lot of chance of getting penalised, especially as Google has to be hand checking right now but as possible abuse reports go up the chances of engines developing a script to parse styles for potential abuse only rises. Hopefully engines will take as much about the intent as a dumb script possibly can but it still seems to me to be an unanswered question.

Thanks Dave, and all other commentators to expand more on the sIFR technique. I’ve been wanting to try it out for a long while now, but things kept getting in the way. I’m definitely going to spend some time toying with it though this weekend.

As PHP + GD has been mentioned I’ll expand on it a bit. If you use PHP with GD, you can add in the possibility to ‘cache’ the headlines, outputting the image to a real image. Give it the name of the headline (or any other reference of your choice), and when the headline needs to be shown again, the ‘cached’ image would be shown. This reduces server overhead a bit (and also page loading time).

PHP 4.2 includes SWF support, and if you compile it with libswf you could also ‘cache’ SWFs dynamically. Anyone interested? ;-)

I’m currently plugging sIFR into my initial HTML build of a large corporate site (pre CMS inplementation). Just 2 hours into the process (sIFR setup is so simple only the first 15 mintues were used to actually get the js, css, and swf all in place and functioning) I can already see many benefits. The largest is the ease of which we’re going to be able to translate the site into various languages for our various global entities. Holy moly are we going to save time and money!

Used in moderation, for a few header/title lines and navigation here and there, I really don’t see much down-side to this sweet mutha.

I tried css off and javascript+flash (Opera easily does this if the user asks for it :-) ) and it sure does not look good. On the other hand, it was expected by Mike D and I agree that I don’t think anyone want to do that combination in real life.

Search this site:

About This Entry:

You are reading “sIFR”, an entry posted on 26 October, 2004, to the Twiggy collection. See other posts in this collection.