Introducing sIFR: The Healthy Alternative to Browser Text
UPDATE: Version 2.0 is now available. See article here.
It’s been well over ten years now since the debut of the graphical web browser and we still don’t have an easy way to deliver rich typography using HTML/CSS. With CSS we can size, style, color, kern, show, and hide our text but we can’t deliver something classical typesetters have delivered since at least the 15th century: custom typography. Until now. In concert with Shaun Inman and Tomas Jogin, I am releasing into the public domain a scalable, multiline, Flash 6 compatible version of IFR to help you reduce the amount of browser text in your life and free the world from the scourge of Arial.
An updated example of sIFR (now at version 2.0) is available here.
But first, a little history
Custom typography for the masses made its debut on computers in 1984 with the release of the Apple Macintosh. The original Mac came pre-installed with such jewels as Chicago, Geneva, New York, and London. As more foundries released digital Postscript versions of their masterpieces over the next several years, the pool of available typefaces grew to thousands. Want to design a wedding invitation? Use Sloop. Want to emulate an artist’s handwriting? Use Cezanne. Want to throw together a cheesy HR flyer? Use Comic Sans. The possibilities are endless, and in some cases, scary.
Then along came the web.
Originally used to spread technical documents across networks, the early web had no need for anything but the barest of typographic essentials. There was no imagery, no sound, no animation, no color, and none of the niceties we are used to seeing on the 21st century web. With the introduction of the Mosaic graphical web browser in 1993, this began to change. Text could now be rendered using any font installed on a user’s system.
A technology before its time?
This newfound support for custom typefaces was nice, but it ended up being of limited use for the following two reasons:
- Postscript typefaces were not represented on screen by their beautiful font outlines but rather by jaggy (”aliased”) bitmaps specially designed for low resolution displays. What this meant was that unless typeface designers created special bitmaps for each possible size on screen, the font ended up looking like crap. Even today, the best web typefaces (viz. Verdana, Tahoma, Helvetica) have been specially adapted for low-resolution displays and that’s why they look so clean on screen.
- There is only a tiny subset of fonts commonly installed on Macs, PCs, and (some) Linux machines. These include the usual suspects: Verdana, Times, Georgia, Helvetica, Courier, and the ugly kid in the corner that no one likes — Arial. Since most people have nothing but these core fonts installed on their systems, it is futile for a designer to specify another font to use on their web site when the user is unable to display it.
Eleven years later, the situation is finally changing. Mac OS X uses Quartz technology to display true Postscript anti-aliased fonts on-screen and the effect is stunning. Windows uses a slightly inferior technology called ClearType to accomplish a slightly inferior version of the same thing. With this newfound ability to display true versions of typefaces in web browsers, you’d think typography on the web would be exploding. Well it’s not. Why? Because no one has solved the second problem yet: how to deliver custom typefaces to people who don’t have them installed.
Premature proprietary panaceas
Several years ago, three possible solutions to this problem were floated out to the web development community. Netscape introduced a feature called “Dynamic Fonts” which downloaded a temporary character set for whatever font the designer had specified. This solution only worked in Netscape browsers of course. Then Bitstream, a renown type foundry, released a plug-in called the “Bitstream Font Player” which purported to do the same thing via a more compatible plug-in model. Eventually, Internet Explorer broke this functionality and Microsoft introduced their own solution for dynamic fonts: the very creatively named Web Embedding Fonts Tool, or WEFT. WEFT fonts took the form of downloadable EOT files which actually worked pretty well in PC Internet Explorer but were totally unsupported in any other browser or OS.
The problem with all of these solutions was that they were not compatible across OSes and browsers, but perhaps more importantly, they were too far ahead of their time. Who wants to view a custom font if it can’t be rendered as its designer intended, with anti-aliased Postscript goodness?
So here we are in 2004 and no one has come up with an easy solution to the problem of custom typography on the web.
Flash to the rescue
With today’s release of sIFR, or Scalable Inman Flash Replacement, we finally have a standards-compliant way to deliver rich typographical text in a flexible manner to over 90% of web users. What is this all about, you ask? Here’s a brief overview of how we got here:
In 2001, I redesigned ESPN.com employing a custom-built Flash 4 component to display our headlines in bold anti-aliased Akzidenz Grotesk (the official ESPN on-air typeface). Using inline javascript, we were able to display rich headlines to people who had Flash 4 installed and plain text to those who didn’t. Additionally, the Flash component automatically scaled down all headlines to fit on one line no matter how much text was entered. The rich headlines drew praise from our users and the negative effect on the code was minimal.
Two years later, Shaun Inman invented a much better technique of embedding Flash headlines by not embedding them at all. Instead, Shaun wrote his pages out as standard XHTML and then used javascript and the Document Object Model to replace all designated text with Flash-rendered text a split second after the page had loaded. Known as IFR, or Inman Flash Replacement, this method was rightly praised by the web community for enabling rich typography without affecting any underlying XHTML code. The method had many revolutionary features and only a few shortcomings, the most glaring of which was the lack of support for multiple lines of text.
Several months after Shaun released IFR into the wild, Tom Werner and Rob Cameron built on Shaun’s code and released their own version called WAC-FR, or Werner and Cameron Flash Replacement. Tom and Rob proved that there was a lot more work to be done in the world of Flash Replacement by introducing a great set of features including support for multiple lines, CSS, and scalability based on a user’s text-zoom setting. The main drawbacks of WAC-FR were that it required Flash 7, it relied on a character count to estimate how many characters might fit on a line, and it sometimes used multiple Flash movies for single blocks of text. As of the summer of 2004, Flash 7 penetration is at about 60% so WAC-FR probably can’t be considered a solution for the masses yet, but that percentage improves every day.
As part of a major yet-to-be announced redesign project (think ESPN big… details soon), I had to come up with a way to display multiple line Flash headlines while keeping compatibility with Flash 6. Furthermore, the headlines had to adapt automatically to areas of different heights and widths.
sIFR is born
sIFR approaches text replacement in a totally different way than previous methods:
- Traditional IFR says “Here’s the exact vertical and horizontal space we’re going to provide for this Flash headline. Make sure you don’t use too many words or they won’t show up.”
- WAC-FR says “Here’s the text we need to display in Flash, here’s the type size to display it at. We’ll keep stacking Flash movies on top of each other until all the text is displayed.”
- sIFR turns the model on its face and says “Here’s the exact space the headline fills up if rendered as browser text. Let’s draw a Flash movie that exact size and lay the type out as snugly as possible within it.”
The following explains the sIFR process:
- A page is requested and loaded.
- Javascript detects if Flash 6 or greater is installed.
- If no Flash is detected, the page is drawn as normal.
- If Flash is detected, the HTML element of the page is immediately given the class “hasFlash”. This effectively hides all text areas to be replaced but keeps their bounds intact. The text is hidden because of a style in the stylesheet which only applies to elements that are children of the html.hasFlash element.
- The javascript traverses through the DOM and finds all elements to be replaced. Once found, the script measures the offsetWidth and offsetHeight of the element and replaces it with a Flash movie of the same dimensions.
- The Flash movie, knowing its textual content, creates a dynamic text field and renders the text at a very large size (96pt).
- The Flash movie reduces the point size of the text until it all fits within the overall size of the movie.
This, of course, all happens too quickly for the user to even notice what’s going on, but below is a super slow motion example of the process (Flash required to see demo):
In addition to the improvements I’ve made to the original IFR on the Flash side of things, I worked with the incomparable Tomas Jogin to improve the replacement script itself. Tomas wrote in an entry several weeks ago that he wanted IFR to be able to replace not only structural elements like H1s and H2s, but all HTML elements, including DIVs. Tomas rewrote a portion of Shaun’s original IFR script to accomplish just that. So now we have in sIFR a solution which can dynamically replace any element of any height or width with a Flash movie that will correctly display one or multiple lines of text.
As another added bonus, I’ve built in the ability to automatically keep the Flash text linkable if the normal HTML version was linkable. You can even configure it so underlines show up when you hover over the text.
But will it scale?
With sIFR comes the introduction of a new feature I call “lazy scaling”. Since sIFR lets the original browser text determine the height and width of the area to be replaced, that area scales with the user’s text zoom setting. While WAC-FR does a great job of scaling on-the-fly when a user resizes text, sIFR only scales on page load. This is not much of a sacrifice in my opinion because firstly, I expect users to use sIFR mainly for text that is already large enough to see clearly, and secondly, because if a user is vision-impaired, they are probably surfing the web with text zoom consistently on. I don’t expect a lot of people are toggling between text zoom settings dynamically for every page they visit.
Limitations
The only significant restriction I am aware of so far is that you shouldn’t use Flash text which is markedly narrower than your browser text. Using text that is wider is no problem since Flash will just shrink it to fit, but for best results, try to match the metrics of your Flash font as closely as possible to the metrics of your browser font. Don’t be afraid to use negative kerning on your browser text if you have to. What I did was render a couple of lines of the custom font in Photoshop, take a screenshot, pull it into Dreamweaver, and overlay browser text on top of it. This way, you can tweak the kerning, leading, size, and weight of your browser text until you get a close match. You don’t have to get it perfect… just get it so that the browser text takes up either the same space or slightly less space than the custom font text. This is a one-time process and it only takes a few minutes.
If you must use markedly narrower Flash text, you can hack the script so that as soon as Flash is detected, your browser text is given extreme negative kerning values before the headline boxes are measured.
How to use it
Grafting sIFR into your site is simple:
- Open up “sIFR.fla”, double-click the font item in the library, and choose any font installed on your system. Export the movie out as “sIFR.swf” or whatever name you’d like.
- Set the CSS properties of your browser text as mentioned in the paragraph above.
- Set which items you’d like to replace at the bottom of the “sIFR.js” file.
- Include the “sIFR.js” file in the head element of your pages.
That’s it! You’ve just freed yourself from the typographical constraints of browser text.
What’s next for web typography?
While sIFR is a liberating solution, it clearly falls into the category of “things which shouldn’t have to be done”. Not coincidentally, this is the same category a lot of things on the web fall into. Using floats to create column layouts, using javascript to clear absolutely positioned elements, using empty alt tags, using image replacement methods, etc, etc, etc. There are simply a lot of things we do as web developers because of the glacial pace at which standards manifest themselves. Do we like standards? Yes, we do. But will we sacrifice our own ability to create better work on the web because of them? No, we won’t. Well, some people will.
I won’t.
In working through sIFR, I began to think of ways browser manufacturers could quickly implement anti-aliased custom typography. The only possible answer I could think of was licensing Flash’s rendering engine. We’ve already proven that Flash can render text as we like on all platforms, and we’ve already seen that every new version of Flash penetrates over 85% of computers within 14 months, so why can’t there be some sort of standard declaration in browsers which invokes a Flash font outline file and renders designated text in that typeface? Ideally, it would be a CSS declaration like so:
h1 {font-family-enhanced: "futura.swf"}
Update: It has been brought to my attention that the @font-face declaration is already part of the CSS2 spec (I thought it was just a Microsoft addition), so perhaps something like this instead:
@font-face {font-family: "Futura"; src: url("futura.swf") format("opentype", "flash");}
Since it’s a new property, it wouldn’t break any existing sites and would degrade gracefully as well. I know this sort of solution might be sacrilegious to the W3C, but what about the more progressive, quicker moving, less idealistic WHATWG? Here’s a group that is interested in improving browsers NOW, damn the purists. I really love what the WHATWG is doing in the HTML space these days, but I wonder if typography is even on their plate. Hey Macromedia, how about organizing a kegger with those guys or something?
In conclusion
Please feel free to use sIFR in your own projects or wherever the situation calls for it. I am under no illusions that this solution is perfect yet, so if you notice quirks or have improvements to suggest, please post them here. I will be happy to roll any improvements into new builds as soon as they are judged as such.
sIFR is offered free of charge, but also free of customer service. I usually try to answer all questions readers submit, but my time is limited.
Right-click here to download the latest sIFR (1.1.4) or check out an example online.
sIFR is now at version 2.0. Please see the most recent sIFR article for details, files, and examples.
Alright, have at it!
Brilliant!! That’s all I have to say.
Great enhancements, Mike. sIFR seems solid enough for me to actually use in a project, while past Flash Replacements merely had me curious.
And I can’t wait to see your “ESPN big” project.
Nice Work Guys!
One thing I noticed with my 2am tinkering is that when linking anywhere in the text, the entire replacement becomes a link. So no multiple linking or single work linking or am I missing something? Or was this the intended effect?
Great Stuff and I too am wondering about “ESPN big”….
I echo Ryan’s comments. My curiousity has now been graduated into motivation. I tip my hat.
So, the text isn’t selectable once rendered?
The real answer isn’t a technological one. It’s a business or licensing one. The problem has more to do with convincing makers of type to allow web developers to spread type around at no cost, or at a cost that makes sense and is practical. Obviously, no one has figured this out yet.
But I think the last thing we need is a Flash specific CSS property. We should be able to to add a call that says to get the font from the server, not the client, and render it. That breaks the current licensing model for type, so browsers makers won’t do it.
Outside of that, I’m enjoying using sIFR, but wish there were an easier way to do the code and mark-up.
Also, you ever figure out that problem with the Design Eye article? It’s the only article on DxF that the sIFR disappears. I’m beginning to suspect it’s a memory issues with Safari.
Sean and Brad:
I haven’t even tested putting multiple anchors in there. Not sure what would happen in that case. Seems like it would work though. As for the text not being selectable, it’s kind of a tradeoff between having anchoring abilities or selectability. If you open the Flash file and comment the onRollOver and onRelease stuff out, and then add “selectable” as a property for the textfield, you can have selectable text. There may be a way to have both… not sure yet.
Andrei:
Interesting insights regarding licensing. I knew there was something there but thought it had been successfully sidestepped with the WEFT tool and Dynamic Fonts. You’re right in that this may be a licensing problem more than a technology problem, but wouldn’t it then make sense for Macromedia to work with foundries to create some sort of protected format which is licensable by web publishers? I’d pay a few bucks as an individual blogger or probably a lot more as a major content provider to have this functionality. Additionally, simple licensing really isn’t the only problem: it’s rendering. WEFT fonts just look like crap. They look alright with ClearType turned on, but Flash renders them much crisper.
As for the Design Eye article, try subbing in this sIFR code (the code you’re using right now is regular IFR) and see if you still notice the problem. It’s certainly a puzzling one. (IFR on one particular page of Design By Fire draws itself, but then disappears permanently when you scroll it off screen in Safari… weird!).
I agree entirely. As stated early in the article, several companies attempted this and none got it quite right. We need a group working toward the betterment of web design as well as web standards - I hope that’s what the WHATWG will turn out to be in the long run.
Echoing Mike, I sure hope that the WHATWG has typography on that plate (or at least cooking on the back burner). sIFR and other technologies make it possible, but if we want to get away from the ‘Scourge of Arial’ we’ll need ease of use.
Excellent work, Mike! I hope to roll this out in some form on my own site soon.
By the way, the CSS solution is just a thought. I’m for whatever gets this done quickly and harmlessly. Whether it be a CSS property, an HTML extension, or a flag to designate server-delivery like Andrei suggests, I’m for it.
Very nice work Mike. I’m amazed just how flexible this is.
I agree with Andrei - font licensing may the biggest stumbling block, but there should be some sort of CSS property to deal with this. It’s presentation and thats the logical place for this to go.
Top work!
Call me a cynic but even if we get everything we want, then we’ll still have a percent of users disabling this function, or overwritting with their own fonts… or IE will require hacks or different syntax.. I’m so jaded these days!
You’re right - people will turn off the functionality and we’ll have to struggle through old browsers not supporting the newest technology. However, your first point isn’t a problem, it’s giving users a level of control they deserve. The latter point is, of course, a small problem.
But so what? Progress is progress. If we can at least come to a conclusion as to how this should be implemented and get the forerunners in browser technology in the game, we’ll be on our way. All new web technologies have started off this way in the last half decade and if we hope to continue on, standardization (to a degree) and implementation by technology leaders like Mozilla is absolutely key. Everything else will eventually fall in to place.
Nice work Mike! I’m yet to try it out, but judging by your example and your description, it really seems to be a great flash-replacement technique, overcoming several weaknesses with previous ones. Keep it up!
Just a few quick questions/ideas:
Good work. It does my heart good to see standards-compliant people giving Flash the chance it deserves…
Great work on this, Mike! Just a few observations:
In the slow-speed example, I’m only seeing one line of the original headline appear via sIFR. That’s intended… right? :)
(Editor’s Note: Oops, forgot to include font outlines on the demo… fixed now… thanks!)
On the example page:
In Firefox (0.9.3, win2k), the sIFR renders fine in the browser, but not at all in print preview, and quite broken in an actual print - for a scan of a print, see http://broome.us/sifr/print-firefox.jpg
In IE (6.0.2800.1106, win2k), print preview doesn’t show the sIFR text as fitting on the page. An actual print appears the same as the preview - see http://broome.us/sifr/print-ie.jpg
I’m only being a stickler about the print versions because I’m about to re-vamp a site using tons of images-as-headlines that I’d like to replace with IFR (or now, sIFR), and print-friendliness is an important factor.
Is this as simple as specifying different handling of “html.hasFlash” in the print-media stylesheet (and getting plain text), or is there a fix for the flash that’ll keep the nice headline when printing?
Thanks for so much already.
(Editor’s Note: Printability is now working in version 1.1… thanks for the heads up)
Mike-
I already told you that I loved you for this, for I’d just like to reitterate it publicly. :)
I’ve not yet had a change to give it a shot, but I can’t wait to play with it. Great work, guys.
The leaps and bounds IFR has taken in the last couple months is just astounding. You (and this applies to everyone who has done anything with the technology) keep updating the idea to take it to the next level. You’re improving the web, and the future looks bright. With the recent popularity of standards and accessibility, we can retain the typography branding we desire while still catering those people with vision disabilities - whether blind or merely farsighted. Nice job, though a on-the-fly scalable version would be pretty cool.
Regarding on-the-fly scalability: Currently, on-the-fly scalability is not possible because the text that is being measured is already gone the second sIFR is run. Also, keep in mind, my example shows a completely unbounded liquid layout. Although sIFR can be used for multiple widths dynamically, it’s of course best to use it in a bounded area so window resizing has no effect on its placement.
Regarding printability: Ok, we have our first problem to solve here. I think I already have an answer though. I’ll try and get it to today. Should only be a minor change to the JS file.
Excellent article. Tops. Where as all my writing on IFR has been tiny, humorless type on grey newsprint you’ve created an advocacy piece with anecdotes and history as colorful as any issue of Wired magazine. Much praise.
Here’s a snippet to guide you on your quest to printability:
swfHTML += ‘<’+e.nodeName.toLowerCase()+((e.id)?’ id=”‘+e.id+’”‘:”)+((e.className)?’ class=”‘+e.className+’”‘:”)+’>’+txt+’<’+'/’+e.nodeName.toLowerCase()+’>’;
Add this after the code that writes the object tag. This will reinsert the element you just replaced inside the containing div. And from there you can hide and show that element and the object tag based on the media type using your favorite screenreader-friendly CSS technique.
See there I go again. Humorless. ;)
Wow. Awesome. I’ve been planning on using this soon, just haven’t had time to get my mind around it. Thanks for woking this out and the great writeup.
Totally awesome, I plan on using it. Great work on meshing the usefullness of flash and HTML.
One question, Is there a way to make the background color on the flash transparent?
I am finding some interesting behavior here. This seems to work fine until you replace multipe instances of an element that have differing lengths. It seems that instead of finding the width and height of each instance, it uses the initial w & h on all instances, forcing some overscaling.
Example
Brad,
Thanks for the heads-up. I’m glad I’m not in the shrinkwrapped software industry. It’s so easy to apply fixes over the web.
The behavior you mentioned should be fixed now in version 1.1.1. (Any bets on how many revisions we’ll see today? I guessing a few). All I did was remove “i–” in the “while” loop and slightly modify the way the heights and widths get declared.
Thanks Mike, works great!
This looks really fascinating, but there’s one sticking point that I’m not getting: this system is obviously for pages with mainly static content, correct?
In other words, you would still need to manually create distinct flash movies for each headline you want displayed using this method. Using this system in a CMS-driven environment would entail building another system to automatically render Flash text, correct?
Neil,
No… this system works for static content, but is specifically made for content generated through a CMS. You just spit out the browser text normally through your CMS and one Flash file does everything for you automatically. The only time you’d even need a different Flash file is if you wanted to use a different font.
It’s that easy.
Since you added support for linked content, have you considered sending the URL to the status bar onRollOver (is this feasible)?
Hm… there seems to be a problem when the anchor tag has a title attribute — adding a title to the link prevents the Flash from showing up. So does adding an id.
Bloody brilliant, you’re now officially a ‘Diamond Geezer’!
Mike,
I just want to add another mark in the “I love you for this” column. This is just outstanding. Great job.
Cheers,
Kevin
I’ve been mostly out of the loop on the whole IFR thread, possibly because 1. I’m not a Flash person and 2. I’m not a JavaScript person. You all seem to be covering lots of ground and solving lots of issues with Flash-replacement. But two issues are popping up in my head about sIFR:
1. I can’t select any of the text replaced by sIFR: At least not in Safari. Haven’t tried this in multiple browsers yet. But I’m constantly selecting text within a browser, copying and pasting — especially headlines. Seems like this technique kills that method for me?
(Editor’s Note: This is now taken care of as of version 1.1.2)
2. Inaccessibile?: As far as I know [1], any text hidden with either display:none; or visibility:hidden; (which the sIFR example above uses) is NOT read aloud in some screen readers. Meaning this technique, while very cool (thank you for documenting it Mike), still suffers from the plague of the original image-based FIR?
[1] Facts and Opinion About Fahrner Image Replacement
Doug,
In response to your two questions:
1. Currently, if you make text clickable in Flash, it ceases to be selectable. So you can have one or the other. If you’re using this method for headlines at the top of a story (or anything which doesn’t include a hyperlink), you can simply comment out the “clickability” part of the code in Flash and your text is fully selectable. Personally, I’ll be using this method mostly for non-clickable stuff, so my text will be selectable (try selecting my own headlines on this site… they work).
2. Accessibility: The document is not even touched unless the correct version of Flash is detected. I’d assume (perhaps wrongly) that computers equipped with screenreaders would intentionally not have Flash installed, so this should be a non-issue.
Actually, the sample doesn’t illustrate this but there is an option in Flash to make the dynamic text selectable. You can see that in action on my site.
The second issue is easily addressed by positioning the hidden elements absolutely somewhere far off the left of the screen instead of changing their display or visibility. The text will even remain copyable (even though it can’t be seen) which I think is the most-likely reason someone would be selecting text on the web.
I need to learn not to walk away from the computer mid-post! What Mike said. :)
Bravo!
One suggestion about your proposed rule: do like the Mozillans do. Name it in such a way that it is obvious that it is an extension (rather than standard). Something like:
-flash-font-family: “futura.swf”;
But yes, great technique, thanks for sharing! :)
This is a really great idea! I think D. Bowman had a good critique in point #1–the first thing I tried was selecting it to. If it could be selected like web text, this would be even more amazing!
Mike and Shaun — thanks for the direct responses. Helps clarify (solve) the issue for me, and hopefully answers the same questions for others.
Excellent. I’d love to try this some time.
One suggestion: for replaced text that is selectable (not clickable), how about including one additional property to turn the cursor into a text-selection tool on hover:
html.hasFlash .replace:hover { cursor: text; }should do the trick I think… Otherwise, I just get the default cursor (black pointer on the Mac) and it doesn’t look selectable like normal text. Not sure if it needs the :hover pseudo-class or not, but I’m guessing so. I assume this would work in all non-IE browsers.
What a great technic! Eventhough (like Doug) I’m not much of a Flash and JS guy, I actually might use this technic in a project…
I would then make use the negative text-ident technic though to hide the text (as “the wolf” suggested). I’d also look into detecting flash serverside as someone suggested, the little flash you get from the js checking for flash can be quite annoying. (pardon the pun)
I do wonder though, if you could use this on a whole page…
Also, (I haven’t looked at the new code yet) would it be possible to have multiple fonts? Could you embed them in a single flash file? And then, by assigning a certain class, get the proper font?
Because, seriously, if we’re going to have this anti-aliased custom font goodness on our sites, why limit ourselves to one font?
Alright, version 1.1.2 is now live and it makes text selectable by default. I am automatically getting the text-selection tool for selectable text in Safari… ah.
The only thing that’s changed in 1.1.2 is the Flash file itself. I’ve also saved the .fla down to Flash MX for those who don’t have MX 2004 yet.
Any word as to developments toward solving the wacky Google caching issue? (via)
andrew,
Should already be solved. Original IFR did not use HTML-enabled textboxes so when Google changes this:
<h2>Improve the Weather with PHP</h2>
to this:
<h2><B style=”color:black;background-color:#ffff66″>Improve the Weather with PHP</B></h2>
… all hell breaks loose. It’s troubling to me that Google is changing anything at all on the page, but I guess they are just trying to highlight certain terms. I haven’t switched my main headlines on this site over to sIFR yet, so when I do (this week), this issue should be moot.
So this is going to allow valid XHTML because the code the JS writes happens after being parsed by DOM? Looking at the code being written by JS its including the embed tags which will not validate as proper XHTML. Does anyone see any problems? Or could we orcorporate a solution like this to the JS document.write:
http://www.ambience.sk/flash-valid.htm
Hmm, if you’re going to have updates all the time (which is a really good idea), then it might be really handy to have a separate page, or even link to this article from the sidebar.
How else can we keep up to date on the evolution of IRT (Image Replacement Technics)
Ok… now that a ton of hard work has been put into sIFR, it’s time for eiither Mike or Shaun to step up to the plate and write a step-by-step, explicit, concise manual or blog entry for how to implement sIFR into a website, including strategies for the best way to organize code snippets, and where to begin with the whole thing.
Once that is done, I’m sure we’ll see a ton more sIFR in practice. For me to implement it on Design by Fire took quite a bit of guess-work based on the haphazard detail of the entires by all parties involved on how to make this baby cook.
My humble two cents.
Now it has been a while since i fiddled around with flash, but a while back i produced a dynamic calendar with html text that contained hyperlinks to other pages… and it was all selectable.
Were you generate the link in the .fla dependant on the if statement, how about stripping out the url of the href and using the TextFormat.url property along with the other TextFormat attributes?
That may create a text field with a link that is also selectable…
For some reason 1.1.2 doesn’t seem to work for me, although 1.1.1 works perfectly first time.
Mozilla
Flash MX Professional 2004 (Educational)
Export Settings: ActionScript 1 & Flash 6
Excellent work by the way.
I should have added to my previous post that I just get a default serif font appearing in the flash movie instead of my replacement font (Myriad).
Apologies for not being clearer the first time, and please feel free to edit this into the original post if you see fit.
I too experience the default serif font with 1.1.2 and correct font rendering (Myriad even!) with 1.1.1.
I wonder if maybe a typo slipped in there somewhere.
Looks to me like the culprit is
in 1.1.2 but was set to true in 1.1.1
(Editor’s Note: Yesindeedy, that is the culprit and it is now fixed. Thanks Cameron.)
Where are the SVG developers? :D I’d love to see something like this using SVG or another open-source solution rather than Flash.
This is not to detract from the work done here at all, merely an observation… and perhaps a reason to learn SVG. >:]
I had to manually define the size of my movie in order for the text to be the correct size. Anybody else with this issue?
Also, is there a way to center the text? Picky picky huh? ;-) Way to go Shaun, Tom, and Mike!
After reading over the comments more, and your write-up (specifically your comment about doing better work now) I have some more comments:
Basically, I like the confidence about doing better solutions now, even if they aren’t “purist” solutions, but how much better is it? This is not a slam, merely a question. Yes, you’ve achieved artistic freedom with your typeface, but at what cost? Classic textual behavior such as wrapping to fit a defined box is lost except at the initial load. Selectability and the ability to copy text are present, which is good, but the ability to span from a sIFR heading to a body of hyper-text is impossible. The text also does not resize in response to browser commands.
While I like to see this type of thinking and problem solving, it reminds me of a very good point made in the most excellent article, A Dao of Web Design. Basically, is it worth pining for the typographic control of a graphic designer when you are a web designer? Yes, to be a web designer is to be a graphic designer in a sense, but we all know that the web designer did not make the graphic designer obsolete. Web design is a new medium that should not remain too strongly tied to any predecessors.
I do not assume that you disagree with this. Again, I sincerely applaud the problem-solving mindset that spawns solutions like this. I just wonder sometimes if, at least in the early stages, a more purist-minded approach to developing a medium, institution, whatever… is ultimately more beneficiary and prodcuctive.
Essentially, one would acknowledge that in their role as a web developer, the visual layout, as you’d prefer everyone to see it, is far from the top of the list of priorities, and that to pursue that in favor of abandoning other tried and true features of the web might be a tad… irresponsible?
I tried my hardest to word all that in the least confrontational, most conversational way I could.
Cheers again, I still plan to load ‘er up and check it out. :)
Seth,
Don’t worry about offending me. This isn’t a communist society, and the great thing about that is you can design sites as you please and others can design sites as they please. Some may find sIFR and other like-minded techniques more trouble than they are worth, and to those people, stick with browser text. I’ve tried to make this solution as easy as possible to implement (takes only a few minutes in some cases) with as few drawbacks as possible.
The lack of spanning selectability between Flash and browser text blocks is of little consequence to me. To be perfectly honest, I’m not sure I want people selecting entire articles of mine (or of my company’s) and pasting them anywhere to repurpose them anyway. I can see the need to select a headline (to include it as link text somewhere) or to select an individual paragraph (to cite it somewhere), but the lack of ability to select everything on the page at once is of no consequence in my opinion.
The second limitation you mentioned is the lack of on-the-fly text zooming. Again, this is of little consequence in my mind because of the reasons mentioned in the article.
I guess the difference in how I think is that I simply don’t accept web design as a more limiting field than traditional graphic design. I think it’s more flexible in many ways. I am a bleeding-heart utilitarian when it comes to body copy because I believe the only purpose of body copy is to be read as easily as possible, but when it comes to display type, I simply don’t accept the four-walled-world that is browser text.
The value you create with display type depends entirely on how good of a designer you are. You can make things worse, you can keep them the same, or you can make things better. What Rolling Stone reader would prefer they do all their headlines in 48 point Times? Not many. Why? Because the typography of the magazine is part of its personality. There is no reason to think this sentiment can’t carry through online. It carries through very nicely on the new Coudal site and they are just using browser text. Problem is, they are still limited to Times and Gill and it only looks great on Macs (5% of the world computers).
I think this solution, just like any method used in web design and development, is completely optional. I certainly think it provides more present-day value than some of the wacko puritanical stuff out there. I’ll keep my mouth shut about that stuff to avoid a holy war for now.
You make some very fine points Seth. I have to disagree with the quote above though.
When people take the time to create a new technique provokes thought and reaction.
This sort of innovation is fantastic for the web community .It highlights some real shortcomings and provides useful insights and ingenuity that can spark productive tangents.
Sure we shouldnt have to use css-hacks to make IE play nice - but on the whole we do. And in the process we are productive and provide solutions for those who wish to use them until something better comes along (which may or may not happen… I cringe regarding the SVG comment above…No offence,but SVG?)
Somehow i don’t think cavemen thought they would wait until matches were invented to put off using sticks & stones to create fire ( A dramatisation of course but you get the drift)
$0.02
Can you disagree with “I wonder…”?
I agree with most of what you “countered” with, likely because, as I implied, you can’t really disagree with what is essentially a question worded as a statement. :)
I mentioned SVG merely because it pops to mind as the “standards equivalent” of Flash. Don’t even start on their dissimilarities, I am aware of quite a few. I think merely of an open standard that provides the means to render vector graphics which could include special typefaces grabbed, say, from a server, I dunno. Again, I don’t know SVG, nor am I a Flash-head.
Just like to play devil’s advocate more than anything, I think. >:)
In case of any confusion, my previous comment was directed to Marc.
Mike,
Oh, you almost had me! Until this! :D
This is where I wonder if you’re lapsing into the perhaps overzealous insistence on the control of a graphic designer in a medium such as the web. The part I’ve emphasized speaks especially to that as you cite print examples to justify a practice on the web. I understand that you follow-up with your assertion that it carries over well. But… again, I would like to see more debate on whether or not it’s worth it! Why?
Because of the strongly emphasized portion near the end: I have been doing a lot of experimenting on my site with CSS as the primary design tool. Many would immediately argue that it is far too limited a tool for any “serious” or “complex” design. But how can those limitations be defined in any other context than the worlds, like the print one, that the web spawned from? When considered in context of the web and its history alone, are not these technologies all but constantly at their zenith, since they are currently developing? Therefore they cannot be limitations. The limitations, as we all well know, are user agents. I try not to see the lack of fonts as a limitation, but rather a creative guideline. I worry that I sound like one who doesn’t approve of “going outside the lines”, because that is definitely not true.
I guess, as I mentioned, the idea of taking a serious look at what it means to be a web designer, and questioning whether or not the current definitions are too strongly tied to other mediums really fascinates me. I feel like there isn’t as much debate on this interesting topic as I’d like to see. It’s quite likely there is, and rather that I’m just not aware…
I don’t disagree with your reminder that its optional. How could anyone? Goes without saying, no? And wouldn’t you be best to avoid instigating a war by avoiding titles like “wacko”? I kid… ;)
Off topic:
Looking at my comment… might I suggest adding a CSS rule to distinguish <em>phasized text within’ blockquotes? The italicized italics don’t really stand out. :)
Seth, i didn’t start on anything… =]
I didn’t realize that wondering about something was any different from thinking about something. I never did speak good england.
To me “wondering” about SVG compared to Flash would be like “wondering” about not to cater for IE just because it isn’t as standards compliant as Firefox…
It’s not a reflection on your or your comment - but to svg and its adoption.
But I do agree with your original point.
And hopefully in the future this result will be easier to achieve. Lets just hope this technique and these conversations are a catalyst to that.
Oh, I Can and I will disagree with peoples wonderings. It’s my prerogative a Web designer (Tongue firmly in cheek)
Expect a sIFR-led renaissance in typography based redesigns…
Seth, New Blockquote Olympic Record Holder:
Does this site look like it suffers from the “overzealous insistence on the control of a graphic designer”? Have you used the Readability tools in the sidebar? The user is the king of the castle here. Want to render the whole site out in 18 pixel Crackhouse? Just type it in. Is it overkill… surely. But it’s also the opposite of what you’re referring to.
I’m really not trying to compare the web to print here. Print was just the most recent example. Typography plays a key role in print, TV, Film, stone tablets, and just about every other visual form of media that ever was. There is no reason for the most sophisticated media of all time to be the most lacking in this regard. All we’re trying to do is push things along here. The train is moving too slow. Everyone will get there eventually, but everyone moves at their own pace.
Haha Adam..
Marc (Mike and the rest for that matter),
I hope I am clear on this much: I support this type of problem solving, and I agree that these types of solutions are often great catalysts to other things.
Off topic again:
My statement about how you can’t disagree with a question isn’t a matter of opinion, though. Questions cannot be disagreed with. Statements can. Think about it. Imagine any question. Then try to disagree with it. What are you disagreeing with? Ya dig? :D
Mike!
I didn’t say that you are and overzealous control freak as a general rule, nor did I even state that I thought so in this instance. Just using your method here as, I dunno, a sort of icon or metaphor for a broader topic. At least, I’m trying to… ;p
Mike,
Sorry, but I can’t resist pointing out your comparing the web’s evolution to print again… “the most advanced medium” is also the youngest and least evolved. Not fair to the web to want it to be more like print. Think of the issues it will have to resolve in therapy someday.
Fair enough Seth. I just don’t think the state of typography on the web right now is anywhere near proportional to the progress made elsewhere throughout the medium. Books are essentially the same as they were hundreds of years ago. Newspapers a bit less so. Film and TV have changed quite a bit, but the internet has already changed more in its first ten years than all of those mediums combined.
I think your question is basically whether or not there should be natural limitations on type on the online world, given its essence as a medium. To that, I say no.
Mike,
I couldn’t agree with you more about typography, especially when put into that perspective.
I don’t think your summary of my ideas here is best summed up with the question you chose, though. It ignores the fact that I don’t view my choices for type, as user agents currently allow, to be limitations, natural or otherwise. At least, I try not to. :)
Mike (or anyone)-
I finally got around to setting this up on jeffcroft.com (whic already had the original IFR) and while it generally works beautifully, I have a couple of questions:
1. Is it possible to make the background the flash movie transparent (forgive me, I’m not a big flash guy)?
2. There seems to be a slight shit of my text to the right by a couple of pixels. Each line starts two or three pixels right of where the container element starts. Can this be corrected somehow?
3. It says in the .js file that the width and height aren’t required elements, but I’m having trouble getting it all to work right without them. I’d like to specify a height (effectively setting a pixel size for my text), but not a width, so that the movie would extend to the boundary of the container and then wrap to the next line. Am I doing something wrong?
4. Is there a legal/piracy issue here? For example, if I make a file called conduitITC.swf (which obviously is set up for Conduit ITC), couldn’t someone that doesn’t own that typeface take my SWF and use it to implement that face on their site? Forgive me for giving people ideas — it’s just something I wondered about.
Thanks again to all of you who have contributed on this. I truly believe that this sort of thing is the future of typography on the web, and I said so when Shaun released the first version. The improvements made here take it to the next level (and then some). You all are amazing.
Oh oh…one more…
5. Is there a flash variable I can send to transform the text to all uppercase or all lowercase?
Jeff,
1. Yes. You can set the background of the Flash movie to be transparent if you’d like by adding “wmode=transparent” to the embed tag in the JS file and <param name=”wmode” value=”transparent” /> to the object tag. I’ll probably automate this with the next minor release. I don’t recommend using transparency, however, because browsers can really screw up the anti-aliasing of the text with this setting on.
2. You can always offset a font in the Flash code if you’d like. Just add something like this to the code block:
holder.txtF._x = 5;
holder.txtF._y = 5;
By the way, the shift may be the result of some padding in an element you’re replacing. Try setting your padding down to zero and it may go away.
3. Yeah, you don’t really want to set the size of the font just by setting the height of the element. Just style your browser text to the size you want it using CSS, and the Flash text will naturally be about the same size. Essentially, the Flash movie is drawing its letters in a similar mold as the browser text letters.
4. No idea about that one. I haven’t read anything about it so I’ll just assume it’s fine unless someone says otherwise.
Something that hasn’t been touched on but may prove useful to this and other flash files in regards to flash’s notorious “Pixel Shift”.
On the original technique (ifr) it was noted that using a background or animation in the flash file could be achieved , but warning about the shimmer , or pixel shift that flash is famous for.
The fix mentioned works partially (that is to offset from the edges enough, or to make sure the clip that moves is slightly larger than 100%) but the best fix, for reasons that I am not smart enough to work out - is to make sure the part that shimmers/shifts is inside a movie clip and it’s alpha is never set to either 100, or 0.
A lot of fades on MovieClips from 100 alpha to 0, or vice-versa had this problem. Simply starting the clip at 99% alpha and fading to 1% alpha eliminates this problem altogether.
Even if you are not fading a clip and it shifts this technique seems to work.
Is it possible to include the font file without having to open the .fla? This would be useful for bundling the technique with a CMS. The admin section of a CMS could show a checkbox, if sFIR should be used, and an input field for the path to some font file.
Mike-
Most of my problems went bye-bye once I read the instructions. :)
Seems that I was using display: none, rather than visibility: hidden in my CSS (this was a leftover from the original Inman technique). once I fixed that, everything just started working beautifully. Oh man, it’s nice, too.
Still have the couple-pixel shift — will play with that tomorrow.
I tried to use it with special characters (čćšđž) in my native language (Croatian) with UTF-8 encoding but instead of letters I get digits. Is there any way around this problem? Has anyone tested it yet for special characters in other languages, other than english?
I would really love to use this technique. Thank you for any help.
Igor - I’m no expert but I guess it depends which font you use. If the font supports those characters, you can choose which to export from within the flash movie
Sweet one Mike! I’ve been lookink at IFR for a current client’s site and it looks like I just found its next evolutionary step instead.
Bravo!
I am digging through this right now, and so far, it seems very elegant in its simplicity and very powerful in its flexibility.
I like this. Well done!
Point of note, it doens’t seem to work in Opera at all.
(tested using 7.53 on Windows)
Great thing, Mike!One word about your comment boxes - with one of the nightly builds of Firefox (20040809, WinXP) it’s - more or less - possible to scroll the content of them with the scroll wheel of the mouse, what looks strange.
Since Andrew commented on evolution…
What about evolving the terms FIR and IFR to be proper descriptions of what they do? You’re not replacing images or Flash, but rather replacing text with images or Flash.
They are text replacement techniques, are they not?
Let’s all pretend my last comment never happened…
How many times do y’all find yourself making statements such as that only to realize literally minutes later something like:
“Well, I suppose it depends on if you read it as what’s being replaced, or what’s doing the replacing…”
D&