Geek Meet: Web Typography and sIFR 3
•
24 j'aime•4,972 vues
A newer version of this talk is available at http://www.slideshare.net/novemberborn/web-typography-with-sifr-3-at-drupalcamp-copenhagen Web typography and sIFR 3, a talk given on February 26 2009 during Geek Meet in Stockholm, Sweden.
Recommandé
Contenu connexe
En vedette
Similaire à Geek Meet: Web Typography and sIFR 3
Similaire à Geek Meet: Web Typography and sIFR 3 (17)
Plus de Mark Wubben
Plus de Mark Wubben (8)
Dernier
Dernier (20)
Geek Meet: Web Typography and sIFR 3
- 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/ Friday, February 27, 2009
- 2. Web Typography Alternatives sIFR Plan Friday, February 27, 2009
- 3. Friday, February 27, 2009
- 4. State of Web Typography Friday, February 27, 2009
- 5. 1997 IE 4 with proprietary EOT NS 4 with proprietary TrueDoc from Bitstream Friday, February 27, 2009
- 6. CSS Web Fonts Specified in CSS 2 Removed in CSS 2.1 Implemented in NS 4, IE 4+ Friday, February 27, 2009
- 7. Progress Is Being Made Friday, February 27, 2009
- 8. Developments Renewed browser support Discussion over spec & implementation Font Linking versus Font Embedding Friday, February 27, 2009
- 9. Font Linking Friday, February 27, 2009
- 10. @font-face { font-family: quot;Fontin-Regularquot;; src: url(quot;Fontin-Regular.otfquot;) format(quot;opentypequot;); } Friday, February 27, 2009
- 11. h1 { font-family: quot;Fontin-Regularquot;; } Friday, February 27, 2009
- 13. Lessons Easy, natural Original font files Potentially large files Friday, February 27, 2009
- 14. Font Piracy? Friday, February 27, 2009
- 15. “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… Friday, February 27, 2009
- 16. …This type of use is therefore specifically prohibited under our End-User License Agreement.” Text Hoefler & Frere-Jones Friday, February 27, 2009
- 17. Font Embedding Friday, February 27, 2009
- 18. Embedded Open Type Industry recognized format Released to W3C as open specification Domain locking, subsetting, compression Friday, February 27, 2009
- 19. Embedded Open Type Horrid Tools Probably easily broken Friday, February 27, 2009
- 20. @font-face { font-family: quot;Fontin-Regularquot;; src: url(quot;Fontin-Regular.eotquot;); } Friday, February 27, 2009
- 21. Friday, February 27, 2009
- 22. “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 … Friday, February 27, 2009
- 23. …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 Friday, February 27, 2009
- 24. Friday, February 27, 2009
- 25. Alternatively, Text Replacement Friday, February 27, 2009
- 26. Images Friday, February 27, 2009
- 28. Flash Friday, February 27, 2009
- 29. Custom Friday, February 27, 2009
- 31. Custom Text Rendering (Cufón) Font translated to custom format No Flash Completely client-side Friday, February 27, 2009
- 32. Custom Text Rendering (Cufón) Not an image, but not text either Implementation relatively static Friday, February 27, 2009
- 33. Image Replacement Font remains on server No Flash! Friday, February 27, 2009
- 34. Image Replacement Server-side code Images are static No real text Friday, February 27, 2009
- 35. Flash Replacement Font only for Flash export No server-side code Actual text, dynamic Friday, February 27, 2009
- 36. Flash Replacement Flash… Links suck Flash text isn’t browser text Friday, February 27, 2009
- 37. Questions So Far? Friday, February 27, 2009
- 38. scalable Inman Flash Replacement Friday, February 27, 2009
- 40. labs.iamkoa.net Friday, February 27, 2009
- 42. Friday, February 27, 2009
- 43. Friday, February 27, 2009
- 45. sIFR?! Friday, February 27, 2009
- 46. Spring 2004, Shaun Inman Friday, February 27, 2009
- 47. Inman Flash Replacement Friday, February 27, 2009
- 48. Summer ’04, scalable IFR Friday, February 27, 2009
- 49. Spring ’05, sIFR 2.0 Friday, February 27, 2009
- 50. sIFR 3? Friday, February 27, 2009
- 51. HTML JavaScript? Flash? Browser? sIFR! Progressive Enhancement Friday, February 27, 2009
- 52. New Since 2.0 Friday, February 27, 2009
- 53. Site HTML? CSS JavaScript sIFR! Applying sIFR Friday, February 27, 2009
- 54. Site Friday, February 27, 2009
- 55. Friday, February 27, 2009
- 56. Friday, February 27, 2009
- 57. Site HTML? Friday, February 27, 2009
- 58. <head> <link rel=quot;stylesheetquot; type=quot;text/cssquot; href=quot;sifr.cssquot;> <script type=quot;text/javascriptquot; src=quot;sifr.jsquot;> </script> </head> Friday, February 27, 2009
- 59. Site HTML? CSS Friday, February 27, 2009
- 60. .sIFR-active h1, { .sIFR-active h2, { .sIFR-active h3 { font-family: Verdana; visibility: hidden; } Friday, February 27, 2009
- 61. Site HTML? CSS Friday, February 27, 2009
- 62. Site HTML? CSS JavaScript Friday, February 27, 2009
- 63. var cochin = { src: 'cochin.swf' }; sIFR.activate(cochin); Friday, February 27, 2009
- 64. sIFR.replace(cochin, { selector: 'h1', css: '.sIFR-root { color: #000000; }' }); Friday, February 27, 2009
- 65. sIFR.replace(cochin, { selector: 'h2', css: '.sIFR-root { color: #484747; background-color: #FDDE3E; }', transparent: true }); Friday, February 27, 2009
- 66. Site HTML? CSS JavaScript sIFR! Friday, February 27, 2009
- 67. Behind the Scenes Friday, February 27, 2009
- 68. Friday, February 27, 2009
- 69. Friday, February 27, 2009
- 70. Friday, February 27, 2009
- 71. Friday, February 27, 2009
- 72. Hyperlinks Friday, February 27, 2009
- 73. <h1><a href=quot;/quot;>Home</a></h1> sIFR.replace(rockwell, { selector: 'a' }); Friday, February 27, 2009
- 74. <h1><a href=quot;/quot;>Home</a></h1> sIFR.replace(rockwell, { selector: 'h1' }); Friday, February 27, 2009
- 75. <h1><span><a href=quot;/quot;>Home</a></span></h1> sIFR.replace(rockwell, { selector: 'span' }); Friday, February 27, 2009
- 76. Questions So Far? Friday, February 27, 2009
- 77. Font Piracy? Friday, February 27, 2009
- 78. “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 Friday, February 27, 2009
- 79. Making sIFR Rock! Friday, February 27, 2009
- 80. Debugging Friday, February 27, 2009
- 81. <head> <link rel=quot;stylesheetquot; type=quot;text/cssquot; href=quot;sifr.cssquot;> <script type=quot;text/javascriptquot; src=quot;sifr.jsquot;> </script> <script type=quot;text/javascriptquot; src=quot;sifr-debug.jsquot;> </script> </head> Friday, February 27, 2009
- 82. Ratios Friday, February 27, 2009
- 83. sIFR.replace(rockwell, { selector: 'h2', css: '.sIFR-root { color: #FFFFFF; }' }); Friday, February 27, 2009
- 84. sIFR.replace(rockwell, { selector: 'h2', css: '.sIFR-root { color: #FFFFFF; }' }); Friday, February 27, 2009
- 85. sIFR.debug.ratios(rockwell, { selector: 'h2', css: '.sIFR-root { color: #FFFFFF; }' }); Friday, February 27, 2009
- 86. Friday, February 27, 2009
- 87. var rockwell = { src: 'rockwell.swf', ratios: [6, 1.41, 9, 1.35, 15, 1.29, 21, 1.25] }; sIFR.replace(rockwell, { selector: 'h2', css: '.sIFR-root { color: #FFFFFF; }' }); Friday, February 27, 2009
- 88. Tuning Friday, February 27, 2009
- 89. sIFR.replace(rockwell, { selector: 'h2', css: '.sIFR-root { color: #FFFFFF; }', tuneHeight: 8, tuneWidth: 1, offsetTop: 4, offsetLeft: 2 }); Friday, February 27, 2009
- 90. sIFR.replace(rockwell, { selector: 'h2', css: '.sIFR-root { color: #FFFFFF; }', fitExactly: true }); Friday, February 27, 2009
- 91. Glyphs Friday, February 27, 2009
- 92. Normal Bold Italic Italic & Bold Glyphs Friday, February 27, 2009
- 93. lowercase UPPERCASE !@#$%^&*(){} åæøéüîãàç Glyphs Friday, February 27, 2009
- 94. Domain Binding Friday, February 27, 2009
- 95. class Options { public static function apply() { sIFR.domains = ['*.example.com', 'example.com']; } } Friday, February 27, 2009
- 96. var rockwell = { src: 'rockwell.swf' }; sIFR.domains = ['*.example.com', 'example.com']; sIFR.activate(rockwell); Friday, February 27, 2009
- 97. Next for sIFR Friday, February 27, 2009
- 98. Resources 11born.net/sifr3 11born.net/sifr3/wiki 11born.net/sifr3/forum 11born.net/sifr3/so 11born.net/sifr3/nightlies @sifr Friday, February 27, 2009
- 100. Ralph Aichinger Lali Masriera Wolfgang Staudt David Goehring Je Kubina Jeremy Keith Darwin Bell Rex Sorgatz Sharat Ganapati antifluor Eduardo Arcos Stig Nygaard Hashir Milhan Jesus Solana Andrew Becherer Ed Schipul Germán Meyer Friday, February 27, 2009
Notes de l'éditeur
- Web typography and sIFR 3, a talk given on February 26 2009 during Geek Meet in Stockholm, Sweden. 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.
- 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 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/
- 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.
- 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/131673530/. 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.
- A Brief Message features design opinions. The site is a bit too heavy on the sIFR, I think, but it sure looks great. The “No Resistance Is Futile” text uses sIFR to render Apex-Serif, as does the introduction text on the top of the page. There’s more sIFR used below, outside of the screen grab. Source: http://alphablogdesigns.com/2008/03/26/examples-of-sifr-typography/
- A development blog. You can see that the sIFR font is the same as the one from their logo, which works quite nicely. The font in question is Bauhaus Demi. Source: http://alphablogdesigns.com/2008/03/26/examples-of-sifr-typography/
- 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.
- 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.
- Here’s a website you guys probably never look at. Curious, was it made by anybody in the room? Site: http://stockholm.se
- According to progressive enhancement, we start with a normal page. Then we identify the elements we want to replace by sIFR. In this case, that’s the <h1>, <h2> and <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 <h1> 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. Here I simply replace `h1`, but you could become more specific if you need to. 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.
- 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.
- 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 Jeff Kubina, http://flickr.com/photos/kubina/1933479589/. 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.