Web Typography with sIFR 3 at Drupalcamp Copenhagen
1. Web
Typography and
sIFR 3
Licensed under Creative Commons Attribution-Share Alike
Mark Wubben
2.5
supercollider.dk
http://creativecommons.org/licenses/by-sa/2.5/dk/
16. “The emerging @font-face tag
(…) will hopefully lead to a secure
technology that allows fonts to be
used in web pages. But at this
Text
time, no such security measures
exist, so the use of this tag with
our fonts constitutes the illegal
distribution of the font software…
17. …This type of use is therefore
specifically prohibited under our
End-User License Agreement.”
Text
Hoefler & Frere-Jones
23. “it (gives) a way to LEGALLY use
commercial fonts (those that
allow embedding, anyway);
directly posting the .TTF or .OTF
Text
file on your web server will violate
your license for commercial fonts
…
24. …Linking to raw .TTF/.OTF files
WILL, in fact, encourage font
piracy, as vastly more commercial
fonts will be placed (unadorned)
Text
online, where they can be easily
pilfered.”
Chris Wilson
25.
26. “Browsers should all ship
interoperable support for
downloadable (…) fonts, and then
we should see how many authors
Text
want to use it and how many
fonts become available.
27. … Some foundries might only
become willing to license their
fonts (…) once they see other
foundries making money off such
business. Text
28. … Once we've observed how
many fonts become available (…)
we can try to determine if
additional technology would lead
to a significant Text
increase in the set
of fonts available (…)”
David Baron
90. “To use an H&FJ font with sIFR,
purchase an additional single-
computer font license for the
webserver itself, and then
Text
configure sIFR (…) to prevent
unauthorized users from
accessing the system”
Hoefler & Frere-Jones
119. Ralph Aichinger Lali Masriera
Bryan Thatcher David Goehring
Wolfgang Staudt Jeremy Keith
Jeff Kubina Rex Sorgatz
Darwin Bell antifluor
Sharat Ganapati Stig Nygaard
Eduardo Arcos Jesus Solana
Hashir Milhan Daniel Catt
Andrew Becherer Ed Schipul
Germán Meyer ginnerobot
Notes de l'éditeur
Web typography and sIFR 3, a talk given on May 24, 2009 during Drupal Camp in Copenhagen, Denmark.
This talk is licensed under Creative Commons. For more information, see http://creativecommons.org/licenses/by-sa/2.5/dk/deed.en_US.
Photo by Ralph Aichinger, http://flickr.com/photos/sooperkuh/358241806/. CC-BY-2.0.
Photo by Bryan Thatcher, http://flickr.com/photos/bryanthatcher/3020368232/. CC-BY-SA-NC, used with permission.
Here’s the plan for this session. We start of with a bit of web typography history, and what’s in store for the future. Then we’ll look at alternative ways of doing web typography without actual web fonts, and finally will have a closer look at sIFR 3.
Photo by Wolfgang Staudt, http://flickr.com/photos/wolfgangstaudt/1362118738/. CC-BY-2.0.
“SiFR (sic) is the new \"1 pixel transparent gif\". A dirty fix for retarded browsers. Cmon, web fonts are here since 2002, wtf are they waiting for?”
This is what the web is like today, except that web fonts have been here since 1997. We still need tools like sIFR, and that’s a shame.Source: http://twitter.com/nerik/status/1182899006
What has been going in the world of web typography such that we still do not have a proper solution?
Sources:
http://shiflett.org/blog/2008/oct/font-linking
http://cwilso.com/2008/07/23/fonts-embedding-vs-linking/
http://jontangerine.com/log/2008/10/font-face-in-ie-making-web-fonts-work
http://www.w3.org/Fonts/Misc/eot-report-2008
http://clagnut.com/blog/2166/
http://alistapart.com/articles/cssatten
Photo by Jeff Kubina, http://flickr.com/photos/kubina/221552029/in/set-72157594317479608/. CC-BY 2.0.
In 1997, both major browsers, IE 4 and NS 4, supported web typography through CSS. Microsoft used its proprietary Embedded OpenType format, while Netscape used the proprietary TrueDoc format from Bitstream. Two competing, proprietary formats, in the midst of the first great browser wars, meant that web typography went nowhere.
After Netscape lost the wars, and open-sourced Mozilla, its web typography support had to go, for Bitstream was unwilling to open source its TrueDoc format. Microsoft kept EOT, but being the only browser to support it, nobody used it.
Sources:
http://www.will-harris.com/wire/html/truedoc.html
Photo by Jeff Kubina, http://flickr.com/photos/kubina/221552029/in/set-72157594317479608/. CC-BY 2.0.
This history is reflected in the CSS specifications. Web fonts were originally specified in CSS 2, but got pulled in 2.1. They’re back in CSS 3, but the specific specification has been dormant since 2002.
NS 4 has since passed away, but web font support is still alive in IE.
Sources:
http://www.w3.org/TR/CSS2/fonts.html#font-descriptions
http://www.w3.org/TR/CSS21/
http://www.w3.org/TR/css3-webfonts/
Photo by Jeff Kubina, http://flickr.com/photos/kubina/221552029/in/set-72157594317479608/. CC-BY 2.0.
Luckily, the future looks a bit brighter.
Photo by Darwin Bell, http://flickr.com/photos/darwinbell/290744139/. CC-BY-2.0.
Since last summer, development has picked up quite a bit. Safari 3.1 came out with support for Font Linking. Firefox 3.1 will also support this, as should Opera 10.
There are discussions going on between browser vendors and type foundries, and with the upcoming release of Firefox 3.1, web typography will be able to reach a far larger audience.
There’s also a large discussion over Font Linking versus Font Embedding, and the legal issues surrounding the two methods. But first, what is Font Linking?
Sources:
http://www.webbedenvironments.com/blog/index.php/2008/04/29/web-typography-tell-me-what-you-want/
http://webkit.org/blog/124/downloadable-fonts/
Photo by Darwin Bell, http://flickr.com/photos/darwinbell/290744139/. CC-BY-2.0.
In essence, Font Linking means that in your CSS file, you can specify a font family and a URL of where the required font file can be found. Once specified, you can use the font family in the rest of your CSS and the browser will make sure that the text is rendered with the specified font file.
Pretty easy!
Photo by Sharat Ganapati, http://flickr.com/photos/frozenchipmunk/115455059/. CC-BY-2.0.
Here we use the font-face at-rule to declare a linked font. `font-family` is the font name we need to use the font later. `src` specifies where the font file can be found, and in which `format` it is specified.
Then, we use it. Easy!
Here’s an example of linked fonts, rendered in Safari. Fontin Regular is actually a freely licensed font, OK for Font Linking.
Source: http://jontangerine.com/silo/typography/font-face/
Font Linking is easy and is the natural way of using web fonts. However, the font files used are the original font files, which may prove a problem when it comes to the licenses type foundries give out.
Additionally, the font files can be large, although one should be able to remove unnecessary glyphs.
Photo by Sharat Ganapati, http://flickr.com/photos/frozenchipmunk/115455059/. CC-BY-2.0.
The problem is that Font Linking requires you to put the original font file on your web server, so the browser can download it and apply it locally. This is a clear violation of many font licenses, which means many fonts cannot be used with Font Linking.
Photo by Eduardo Arcos, http://flickr.com/photos/earcos/2091079658/. CC-BY-2.0.
Here’s Hoefler & Frere-Jones, a well known type foundry, on Font Linking:
“The emerging @font-face tag (…) will hopefully lead to a secure technology that allows fonts to be used in web pages. But at this time, no such security measures exist, so the use of this tag with our fonts constitutes the illegal distribution of the font software. This type of use is therefore specifically prohibited under our End-User License Agreement.”Source: http://www.typography.com/ask/faq.php#Ft_10 (20. Using fonts online)
Here’s Hoefler & Frere-Jones, a well known type foundry, on Font Linking:
“The emerging @font-face tag (…) will hopefully lead to a secure technology that allows fonts to be used in web pages. But at this time, no such security measures exist, so the use of this tag with our fonts constitutes the illegal distribution of the font software. This type of use is therefore specifically prohibited under our End-User License Agreement.”Source: http://www.typography.com/ask/faq.php#Ft_10 (20. Using fonts online)
The difference between Font Linking and Font Embedding is subtle, but important. In essence, with Font Embedding the font file is embedded in an intermediate format, that is then linked into the document.
Photo by Hashir Milhan, http://flickr.com/photos/hashir/987015853/. CC-BY-2.0.
Embedded Open Type is the original format used by IE 4 for font embedding. It is (or was) also used in Word, and is a format recognized by the font industry. The important bit is that the tools generating the EOT files respect font embedding settings in font files, just like Flash does. This means that you can’t convert a font into EOT unless permitted by the type foundry.
Because it’s a slightly different format from an original font file, it can’t be installed on a computer like you would with a TrueType or OpenType file.
Some additional advantages are that an EOT file can be locked to specific domains, supports compression and even lets you pick which glyphs you want to embed.
Microsoft has released EOT to the W3C for standardization. This is still ongoing, but it clears the way for using EOT in different browsers.
Photo by Hashir Milhan, http://flickr.com/photos/hashir/987015853/. CC-BY-2.0.
Unfortunately the tools required to make EOT files aren’t that great yet, and it’s probably really easy to break the ‘protection’. Then again, it always has been, and type foundries are still on board with it.Photo by Hashir Milhan, http://flickr.com/photos/hashir/987015853/. CC-BY-2.0.
Here’s how you would use EOT. Remarkably similar to Font Linking, except that you don’t specify a format.
Is EOT DRM? Because Microsoft is Microsoft, and EOT is about protecting digital files, it is often perceived as a DRM format. I would argue that it’s not a DRM format as long as you apply it yourself – you still get a TrueType or OpenType file from the type foundry, but then *you* convert it to an EOT file. The reason you would do this is to prevent breaking your license agreement with the type foundry, which is probably a good idea.
To be clear, this won’t stop font piracy, because you can get the fonts anyway if you want to. However, font linking makes font piracy so incredibly easy that alternatives should be considered.
Also, Microsoft has opened up the EOT specification, so it’s not a secret format. You can compare it to font embedding in Flash, which is also an open format. Font embedding in Flash and EOT are accepted by the industry.
Photo by Andrew Becherer, http://flickr.com/photos/tacomalog/152190355/. CC-BY-2.0.
Here’s what Chris Wilson, chair of HTML 5, has to say about EOT:
“it (gives) a way to LEGALLY use commercial fonts (those that allow embedding, anyway); directly posting the .TTF or .OTF file on your web server will violate your license for commercial fonts. Linking to raw .TTF/.OTF files WILL, in fact, encourage font piracy, as vastly more commercial fonts will be placed (unadorned) online, where they can be easily pilfered.”
Source: http://cwilso.com/2008/07/23/fonts-embedding-vs-linking/
Here’s what Chris Wilson of the IE team has to say about EOT:
“it (gives) a way to LEGALLY use commercial fonts (those that allow embedding, anyway); directly posting the .TTF or .OTF file on your web server will violate your license for commercial fonts. Linking to raw .TTF/.OTF files WILL, in fact, encourage font piracy, as vastly more commercial fonts will be placed (unadorned) online, where they can be easily pilfered.”
Source: http://cwilso.com/2008/07/23/fonts-embedding-vs-linking/
As it turns out, neither Mozilla, Apple or Opera are willing to support EOT. They mostly get hung up on it being DRM, or protecting the type foundries. Microsoft on their part refuse to implement Font Linking, because it hurts the interests of font vendors.
There are suggestions about using HTTP headers to carry licensing information, but it’s not clear yet how this would work.
I don’t particularly care about how the foundries handle this new age, all I know is that right now putting up bare font files tends to be in violation of font licenses. We need a way around that. Apparently that way is not yet coming for real web typography.
Background reading:
https://lists.webkit.org/pipermail/webkit-dev/2008-October/005442.html
http://blogs.adobe.com/typblography/2007/11/web_fonts_1.html
Photo by Jeff Kubina, http://flickr.com/photos/kubina/564073862/. CC-BY-SA-2.0.
Here’s what David Baron, Mozilla developer, has to say about this mess:
“Browsers should all ship interoperable support for downloadable (…) fonts, and then we should see how many authors want to use it and how many fonts become available. Some foundries might only become willing to license their fonts (…) once they see other foundries making money off such business. Once we've observed how many fonts become available (…) we can try to determine if additional technology would lead to a significant increase in the set of fonts available (…)”
Source: http://dbaron.org/log/20090317-fonts.
Here’s what David Baron, Mozilla developer, has to say about this mess:
“Browsers should all ship interoperable support for downloadable (…) fonts, and then we should see how many authors want to use it and how many fonts become available. Some foundries might only become willing to license their fonts (…) once they see other foundries making money off such business. Once we've observed how many fonts become available (…) we can try to determine if additional technology would lead to a significant increase in the set of fonts available (…)”
Source: http://dbaron.org/log/20090317-fonts.
Here’s what David Baron, Mozilla developer, has to say about this mess:
“Browsers should all ship interoperable support for downloadable (…) fonts, and then we should see how many authors want to use it and how many fonts become available. Some foundries might only become willing to license their fonts (…) once they see other foundries making money off such business. Once we've observed how many fonts become available (…) we can try to determine if additional technology would lead to a significant increase in the set of fonts available (…)”
Source: http://dbaron.org/log/20090317-fonts.
So, with actual web fonts out of the window, the only other way we can have typography on the web is by replacing the text by something else.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/836443155/. CC-BY-SA-2.0.
The obvious answer is to use images. You can either create images in Photoshop, or dynamically on the server. Various techniques exist to replace HTML text by images.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/138201118/. CC-BY-SA-2.0.
Facelift uses JavaScript and server-side PHP code to dynamically generate images and replace HTML text by these images.
http://facelift.mawhorter.net
Another alternative is using Flash, which supports the embedding of typefaces, and can render text dynamically without server-side generation.
Photo by Germán Meyer, http://flickr.com/photos/kainet/144703613/. CC-BY-SA-2.0.
Another way is to render text using JavaScript.
Photo by Lali Masriera, http://www.flickr.com/photos/visualpanic/2923906764/, CC-BY-2.0.
Cufón is the new kid on the block, taking this approach. It’s a wickedly clever idea, in fact.Screenshot: http://cufon.shoqolate.com/generate/
Let’s quickly compare the three approaches.
First, Cufón. It works by translating the font information into a custom format, which it subsequently uses to draw the text. In IE it uses VML, in other browsers it uses the <canvas> element. It doesn’t use Flash, which is a great advantage. It’s also completely client-side.Photo by Lali Masriera, http://www.flickr.com/photos/visualpanic/2923906764/, CC-BY-2.0.
Downsides is that the text they render doesn’t act as text. It’s better than an image, but not quite there.
The current implementation of Cufón is also relatively static. There are no link effects, different font styles with in the same replaced text.Photo by Lali Masriera, http://www.flickr.com/photos/visualpanic/2923906764/, CC-BY-2.0.
Advantages of Image Replacement are that you can keep the original font on the server, without sending it to the client. This definitely beats Font Linking. It doesn’t require Flash either.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/138201118/. CC-BY-SA-2.0.
On the other hand, you need to have server-side code running. Images are static, you can’t change them other than by replacing them by newly generated images. And the text inside an image is not real text.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/138201118/. CC-BY-SA-2.0.
Flash Replacement requires no server-side code. The font file is only used when you export the Flash movie containing the typeface. Flash text is actual text, you can select it, copy it, et cetera. And Flash movies are dynamic: they run code themselves so you can change the text or style without reloading the Flash movie.
Photo by Germán Meyer, http://flickr.com/photos/kainet/144703613/. CC-BY-SA-2.0.
That said, Flash is, well, Flash. It can be CPU intensive. Links in Flash movies are not real browser links. For example, you can’t open Flash links in a new tab. And Flash text still isn’t browser text.
Photo by Germán Meyer, http://flickr.com/photos/kainet/144703613/. CC-BY-SA-2.0.
Any questions so far?
Photo by Jeff Kubina, http://flickr.com/photos/kubina/131672122/. CC-BY-SA-2.0.
All right! Now, I am obviously biased, which means that we’ll be looking at Flash Replacement. More specifically, scalable Inman Flash Replacement, or sIFR.
Let’s start by looking at a few sites that are using sIFR, so we can get an impression of where sIFR comes into play.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
Red Nose Day is a fundraiser campaign in the UK. They use sIFR 2, but they use it for all the right reasons. The navigation text? It’s an image. The text in the center? That’s a full Flash movie. The headers in the left sidebar and the columns underneath the center? sIFR.
Using sIFR for links is bad, and they don’t. Of course, this also lets them use a slightly bend underline, and a wiggle effect when you mose over the link in the top navigation. Other text at the bottom of the page (not currently visible) is also rendered in images, because it never changes.
In total, there are only 8 sIFR movies on this page. Very well done.
Source: http://rednoseday.com
Jason Santa Maria mixes “HTML typefaces” with sIFR text. “Articles” is HTML, “Recent Entries” is Trade Gothic via sIFR.
See also the footer here.
As it turns out, Jason might be defecting to Cufón. The bastard ;-)Source: http://twitter.com/jasonsantamaria/status/1250665926
I also really like this website. It doesn’t use sIFR at all, in fact. Just basic typography without any exotic fonts.
So, what is this sIFR thing? It’s a combination of CSS, JavaScript and Flash, designed to let you use any typeface you want on your website. You create a Flash movie in which you embed the typeface. Then apply a bit of CSS and JavaScript to your site, and wham, pretty text!
sIFR is meant for simple headings. Don’t replace all text with it. Preferably, don’t use it for links and complicated menus.
(And don’t mind that guy, it actually does work.)
Photo by David Goehring, http://flickr.com/photos/carbonnyc/496721450/. CC-BY-2.0.
Back in 2004, Shaun Inman came up with an innovative solution of doing typography on the web.
Photo by Jeremy Keith, http://flickr.com/photos/adactio/99391890/. CC-BY-2.0.
This was spring 2004, and his solution came to be known as Inman Flash Replacement. The technique inserted Flash movies with a pre-defined size into the page, and the text rendered inside the Flash movie.
Photo by Jeremy Keith, http://flickr.com/photos/adactio/99391890/. CC-BY-2.0.
Summer came, and Mike Davidson and Tomas Jogin made IFR scalable. I saw this, was pretty bored and decided to have a go at rewriting their code. From one thing came another, and so…
http://www.mikeindustries.com/blog/archive/2004/08/sifr
Photo by Rex Sorgatz, http://flickr.com/photos/fimoculous/246307803/. CC-BY-2.0.
… me and Mike released sIFR 2 in the spring of 2005.
http://www.mikeindustries.com/blog/archive/2005/04/sifr-2.0-released
Photo by Rex Sorgatz, http://flickr.com/photos/fimoculous/246307803/. CC-BY-2.0.
Fast forward to now, I’m working on v3.
Photo by Jeremy Keith, http://flickr.com/photos/adactio/523679899/. CC-BY-2.0.
sIFR follows the principles of progressive enhancement. You start of with your basic HTML page, and load the sIFR CSS and JavaScript files. If JavaScript is disabled, the sIFR code will not execute, and your page looks the same. If it is enabled, sIFR detects if the correct Flash version is installed. Again, if this is not the case, the sIFR code will not execute, and your page looks the same. sIFR also makes sure that the browser viewing the page is supported. Only if everything is OK, sIFR activates.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
sIFR follows the principles of progressive enhancement. You start of with your basic HTML page, and load the sIFR CSS and JavaScript files. If JavaScript is disabled, the sIFR code will not execute, and your page looks the same. If it is enabled, sIFR detects if the correct Flash version is installed. Again, if this is not the case, the sIFR code will not execute, and your page looks the same. sIFR also makes sure that the browser viewing the page is supported. Only if everything is OK, sIFR activates.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
sIFR follows the principles of progressive enhancement. You start of with your basic HTML page, and load the sIFR CSS and JavaScript files. If JavaScript is disabled, the sIFR code will not execute, and your page looks the same. If it is enabled, sIFR detects if the correct Flash version is installed. Again, if this is not the case, the sIFR code will not execute, and your page looks the same. sIFR also makes sure that the browser viewing the page is supported. Only if everything is OK, sIFR activates.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
sIFR follows the principles of progressive enhancement. You start of with your basic HTML page, and load the sIFR CSS and JavaScript files. If JavaScript is disabled, the sIFR code will not execute, and your page looks the same. If it is enabled, sIFR detects if the correct Flash version is installed. Again, if this is not the case, the sIFR code will not execute, and your page looks the same. sIFR also makes sure that the browser viewing the page is supported. Only if everything is OK, sIFR activates.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
sIFR follows the principles of progressive enhancement. You start of with your basic HTML page, and load the sIFR CSS and JavaScript files. If JavaScript is disabled, the sIFR code will not execute, and your page looks the same. If it is enabled, sIFR detects if the correct Flash version is installed. Again, if this is not the case, the sIFR code will not execute, and your page looks the same. sIFR also makes sure that the browser viewing the page is supported. Only if everything is OK, sIFR activates.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
sIFR follows the principles of progressive enhancement. You start of with your basic HTML page, and load the sIFR CSS and JavaScript files. If JavaScript is disabled, the sIFR code will not execute, and your page looks the same. If it is enabled, sIFR detects if the correct Flash version is installed. Again, if this is not the case, the sIFR code will not execute, and your page looks the same. sIFR also makes sure that the browser viewing the page is supported. Only if everything is OK, sIFR activates.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/397376026/. CC-BY-2.0.
Some of you may have used sIFR 2. If so, my apologies.
The good news is, sIFR 3 has a completely different way of calculating the font size it should render at. No longer do you have to spend hours tweaking this and that, just to get consistent rendering!
sIFR 3 also lets you style parts of the replaced text differently, works with browser zoom (that’s full page zoom, not text resizing) and, well, just works a lot better. So there.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/448485266/. CC-BY-SA-2.0.
Remember the steps sIFR takes regarding progressive enhancement. We’ll look at how to apply sIFR to your existing web page, by adding a bit of HTML, specifying some CSS, and writing a bit of JavaScript.
Photo by “antifluor”, http://flickr.com/photos/antifluor/2074560932/. CC-BY-2.0.
Remember the steps sIFR takes regarding progressive enhancement. We’ll look at how to apply sIFR to your existing web page, by adding a bit of HTML, specifying some CSS, and writing a bit of JavaScript.
Photo by “antifluor”, http://flickr.com/photos/antifluor/2074560932/. CC-BY-2.0.
Remember the steps sIFR takes regarding progressive enhancement. We’ll look at how to apply sIFR to your existing web page, by adding a bit of HTML, specifying some CSS, and writing a bit of JavaScript.
Photo by “antifluor”, http://flickr.com/photos/antifluor/2074560932/. CC-BY-2.0.
Remember the steps sIFR takes regarding progressive enhancement. We’ll look at how to apply sIFR to your existing web page, by adding a bit of HTML, specifying some CSS, and writing a bit of JavaScript.
Photo by “antifluor”, http://flickr.com/photos/antifluor/2074560932/. CC-BY-2.0.
Remember the steps sIFR takes regarding progressive enhancement. We’ll look at how to apply sIFR to your existing web page, by adding a bit of HTML, specifying some CSS, and writing a bit of JavaScript.
Photo by “antifluor”, http://flickr.com/photos/antifluor/2074560932/. CC-BY-2.0.
Remember the steps sIFR takes regarding progressive enhancement. We’ll look at how to apply sIFR to your existing web page, by adding a bit of HTML, specifying some CSS, and writing a bit of JavaScript.
Photo by “antifluor”, http://flickr.com/photos/antifluor/2074560932/. CC-BY-2.0.
Here’s a website you all should be familiar with.
Site: http://2009.drupalcamp.dk.
According to progressive enhancement, we start with a normal page. Then we identify the elements we want to replace by sIFR. In this case, those are the <h3> elements.
So we’re starting with a existing website. To add sIFR, we need to modify the HTML to load some JavaScript and CSS.
The HTML you need to add for sIFR to work. It’s best to load these files as early as possible. You must load them in the <head>.
Next, we write a bit of CSS. These rules will apply to the elements you are about to replace. They don’t control how the text is rendered inside Flash, aside from font size.
This is the CSS which goes into the HTML page.
`.sIFR-active` is a class that is set on either <html> or <body>, when sIFR has activated. Use this class to make sure the rules are only applied when the element is about to be replaced by sIFR.
There is some magic going on here. I’ve picked Verdana as a font family because it’s available on pretty much any platform. This means the text is rendered in roughly the same manner on each platform. This is important because it makes the height of the text the same.
sIFR uses the font size of the original HTML text. Here I just add a few styles to tweak the loading, but I can also set a different font size for sIFR.
We hide the HTML text before replacement to improve the loading experience.
You can set other properties here, to fine tune the replacement. Because of the `.sIFR-active` class, the styles are only applied to elements that will be replaced.
Now, if we were to look at the page, you wouldn’t notice any difference. That’s because sIFR hasn’t yet activated.
If we activate sIFR, however, the <h1> text will disappear. Just as it should.
Next up, the actual code we use to replace elements on the page!
Put this in the <head>, after loading sifr.js.
First we create an object which points to the location of the Flash movie on the web server. Then we activate sIFR by passing in the object – this lets sIFR load the Flash movie in the background so it ends up in the browser cache before sIFR actually starts replacing elements. Not doing this may lead to the Flash movie being downloaded multiple times.
A simple replacement statement for the <h3> heading.
We pass in the object we created earlier. sIFR uses the arguments from this object, as well as from the second object that’s passed in. This means you can put generic arguments on the `cochin` object, and specific arguments on the second object.
Selector contains a CSS selector. Note that sIFR replaces elements in the order of `sIFR.replace()` calls. Therefore, make sure to replace the most specific selectors first, before replacing generic selectors. A CSS selector may match multiple elements, sIFR replaces all of them.
And finally, some CSS for inside the Flash movie. `.sIFR-root` applies to the entire movie. You can specify simple element names inside, or select elements using just their class name.
The CSS properties are self-explanatory. Note, though, that Flash supports only a subset of CSS, and sIFR has added a few other properties. You can see the full list at http://wiki.novemberborn.net/sifr3/Styling.
We specify the Flash movie to be transparent. Because this isn’t supported on all platforms, we also specify a background-color. This acts as a fallback in case transparency is not supported.
Generally though, try to avoid using transparency.
And that’s how you apply sIFR!
Question is, how do these replacements actually work? What changes in the DOM?
First, even though you call the `sIFR.replace()` method in the <head>, sIFR waits until all HTML and CSS is available before replacing the elements. Then, it finds all elements that match the selector you specified, and starts replacing them one by one.
It calculates the font size, parses the replacement parameters, fetches the text from the DOM, and finally replaces the original text by both a Flash movie and a hidden element containing the text – for screen readers and printers.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/848656795/. CC-BY-2.0.
I hope this is readable. On the HTML element, you can see the `sIFR-active` class.
We’ve replaced an `<h1>` here. It now has the `sIFR-replaced` class.
The Flash object is inserted as a child of the `<h1>`. The original content is gone now.
There’s also a hidden `<span>`, which contains alternate text for the Flash movie. It is used by screen readers, and when you print the document, it is displayed instead of the Flash movie.
As you may have noticed, the entire content of the <h1> has been replaced by sIFR elements. This has side-effects when you replace links. If you replace the link element itself, you actually just replace the text. Clicking on a Flash movie inside an <a> doesn’t work properly, cross browser. Instead, replace the parent element of the link, such that the link itself is in the Flash movie.
Photo by Mark Wubben, http://flickr.com/photos/novemberborn/185775974/.
So don’t do this.
But do this.
Or this.
Again, any questions so far?
Photo by Jeff Kubina, http://flickr.com/photos/kubina/131673530/. CC-BY-SA-2.0.
Does sIFR violate font licenses? Hoefler & Frere-Jones also mentiones sIFR in their FAQ.
Photo by Eduardo Arcos, http://flickr.com/photos/earcos/2091079658/. CC-BY-2.0.
“To use an H&FJ font with sIFR, purchase an additional single-computer font license for the webserver itself, and then configure sIFR (…) to prevent unauthorized users from accessing the system”
It has to be noted, however, that you can always break a sIFR movie and override its protection, or extract the font glyphs.
Source: http://www.typography.com/ask/faq.php#Ft_10 (20. Using fonts online)
Let’s look at how we can make sIFR rock even more.
Photo by Stig Nygaard, http://flickr.com/photos/stignygaard/12630269/. CC-BY-2.0.
Let’s look at how we can make sIFR rock even more.
Photo by Stig Nygaard, http://flickr.com/photos/stignygaard/12630269/. CC-BY-2.0.
First of all, enable JavaScript error reporting in your browser, and check for sIFR-caused errors.
Use Firebug and similar tools to see if the replacements actually took place.
Load sifr-debug.js to get warnings from sIFR itself.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/217217600/. CC-BY-2.0.
Make sure to load the sifr-debug.js file after loading sifr.js.
Usually, the HTML font you have specified does not have the same proportions as the Flash font. Because the sIFR movie initially gets the height of the original HTML text, it typically resizes to fit the Flash text. This then causes the “jumpiness” in the page.
Ratios are a way to make the initial height approximate the correct height. You can calculate ratios using the sifr-debug.js file.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/2773841618/. CC-BY-2.0.
Let’s say we have this replacement statement.
We’ll swap out `sIFR.replace`
for `sIFR.debug.ratios`.
Then load the page, you’ll get a prompt. Copy the text to your clipboard.
It’s best to do this in Firefox.
Now, remember that you create an object linking to the Flash movie? Add a `ratios` property to this object, containing the ratios you just got from the browser.
Then change `sIFR.debug.ratios` back to `sIFR.replace`. There ya go, ratios have been calculated!
sIFR bases the width and height of the Flash movies on the values that are reported by Flash. Unfortunately, these values can be incorrect. Here’s how to adjust the width and height of the Flash movie.
Photo by Jesus Solana, http://flickr.com/photos/pasotraspaso/2672666678/. CC-BY-2.0.
In the replacement statement, you can define a few other options. `tuneHeight` makes the Flash movie higher in case of a positive integer, or smaller in case of a negative integer. `tuneWidth` affects the width, `offsetTop` and `offsetLeft` the X and Y position of the text inside the Flash movie.
Make sure to use actual numbers, not strings.
You can make the Flash movie fit exactly (well, as far as the values Flash provides) around the text. Makes it a bit smaller, depending on the layout of your page, this may work better.
Flash requires you to specify the characters you want to embed in the Flash movie.
Photo by Mark Wubben, http://flickr.com/photos/novemberborn/286773384/
When exporting the Flash movie, make sure that you embed just the glyphs you need. For example, if you only need normal text, don’t include the bold and italic variants. If you only need bold text, only include the bold glyphs. Etc.
Photo by Mark Wubben, http://flickr.com/photos/novemberborn/286773384/
Also make sure to export the glyphs you need to render the text. And, if you’re sure you’re only exporting upper case text, just export the upper case glyphs. Saves file size!
Photo by Mark Wubben, http://flickr.com/photos/novemberborn/286773384/
You can bind a sIFR Flash movie to a number of domains. This helps prevent hot linking. It’s not a real defense against people stealing your Flash movie and using it for themselves, since the code required to do the domain binding can easily be removed from the Flash movie.
This is what Hoefler & Frere-Jones was referring to earlier.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/2759322646/. CC-BY-2.0.
Put this in Options.as before you export the Flash movie. It lets you bind the Flash movie itself to a specific domain.
You can also bind the JavaScript code to specific domains. Useful if you want to ensure sIFR does not kick in when the code is loaded in a different context than you expected. Say, Google Translate.
sIFR can also do some cool tricks.
Photo by Daniel Catt, http://flickr.com/photos/revdancatt/2396307639/. CC-BY-SA-2.0.
You can hook up event handlers for the Flash movie, and you can interact with the Flash movie from inside the handler. In this case, we specify a generic onRelease handler for all h2 replacements.
Here we specify a rollover and rollout handler, which combined with the transparent background allows us to change the background color of sIFR text on mouse over.
Or, the other way around, change the text of the first sIFR replacement, and make it italic and orange.
So, what’s next for sIFR? Development at the moment is quite slow, so I’m hoping to speed that up by moving the code base to GitHub. Would be fun to have input from other developers. There’s a bunch of issues left to solve, that aren’t critical, but do stand in the way of a final release. That said, definitely go use the latest nightly, it’s awesome.
sIFR 3 as it is is Flash 8, and I have no intention of moving it to Flash 10. Eventually that would be interesting, however, since Flash 10 has better text handling capabilities.
There has also been some development recently in sIFR derivatives, such as sIFR Lite and jQuery sIFR. The biggest problem with both of these is that they’re based on sIFR 2. The second problem is that they’ve simplified too much of the sIFR 2 code base, reintroducing browser compatibility issues. Therefore I do suggest you use sIFR 3.
It’d be awesome though if there would be a jQuery version of sIFR 3, and perhaps the move to GitHub could help in that regard.
Photo by Ed Schipul, http://flickr.com/photos/eschipul/386762837/. CC-BY-SA-2.0.
Useful sIFR resources:
http://11born.net/sifr3
http://11born.net/sifr3/wiki
http://11born.net/sifr3/forum
11born.net/sifr3/so
http://11born.net/sifr3/nightlies
From the nightlies you can download the latest sIFR version.
Follow sIFR on Twitter: @sifr.
Photo by Lali Masriera, http://flickr.com/photos/visualpanic/1190611977/. CC-BY-2.0.
Thank you.
Photo by ginnerobot, http://flickr.com/photos/ginnerobot/2877212845/. CC-BY-SA 2.0.
Thank you.
Photo by ginnerobot, http://flickr.com/photos/ginnerobot/2877212845/. CC-BY-SA 2.0.
And of course many, many thanks to the wonderful people on Flickr who licensed their photos under Creative Commons.
Photo by Jeff Kubina, http://flickr.com/photos/kubina/903033693/. CC-BY-SA-2.0.