Why do designers use sIFR if they can use #font-face ?
What is wrong with #font-face ?
#font-face {
font-family: "Hacen Tehran_eot";
src: url('Hacen Tehran.eot');
}
#font-face {
font-family: "Hacen Tehran_ttf";
src: url('Hacen Tehran.ttf');
}
p {
font-family:"Hacen Tehran_eot", "Hacen Tehran_ttf", sans-serif;
font-size:40px;
}
What is wrong with #font-face ?
It's new, or at least compatible browser support for it is new.
Until very recently, the only browser to support it was IE, and then only with the EOT font format, which could only be generated by the complicated and unpopular WEFT application.
There are still format problems today. Although WOFF is the clear future winner, we've still got some recent browsers that need TTF/OTF instead, plus iPhone and its bizarre SVG fonts, and of course plenty of IE<9 browsers that want EOT.
Combine this with the issue of finding fonts whose licences actually allowed them to be embedded in a web page, and #font-face was a non-starter. The licence situation has got much better recently, with plenty of good-quality fonts available for real web embedding.
But still, chances are if you've already picked a font, especially from one of the major foundries who are still dragging their heels, it's not going to be possible to license it. Vector-based replacement techniques like sIFR and Cufon are more like the regular embedding that traditional licences often allow, and image-based replacement techniques don't need an embedding licence at all.
There are a few possible reasons:
You can embed many more fonts into Flash than you can currently get a licensed font-face compatible version of.
Even when you can get a licensed version it is often less expensive to use the font files you have that are compatible with Flash instead of buying new font-face versions.
Font-face versions of fonts are often licensed based on traffic instead of the flat rate designers are used to for desktop licensing. If you expect a site to get 10 Million page views per month its possible that the client might not want to pay the licensing for those fonts.
Some designers just don't know how to use font-face as well, but that is just a matter of education.
#font-face relies on the rendering engine of the browsers its text is appearing in so it may very well look aliased on Windows machines. This is true of Google Web Fonts and, I assume, of Typekit and similar services--this is why I continue to use sIFR. I've got a more expanded answer to this post's question here: What are cons to use Cufon? Is sIFR still good option? #font-face doesn't make the letters smooth like they look with cufon or sIFR
You cannot do complicated gradient effects such as horizontal colour scaling with sIFR whereas this can be quickly put together in a flash file.
Related
I am currently thinking about using webfonts from Google, but I have still no idea which way to do it, because there are many different opinions on the internet.
I have following options:
Webfontloader by typekit and google
rel attribute preload
When checking the performance of both on a slow 3G network, I get similar results regarding the performance. The downside of the webfontloader is the FOUT (Flash of unstyled text). Is there a way to get around that? The downside of preload is that its not supported by many browsers. Is there a fallback? I couldn't find one. Maybe you have another entirely different way.
Thanks for your help,
Nuru
I've always found the most performant way to load webfonts is as local files on your site. Just use .woff and .woff2 files because these will cover you back to IE8 unless there is some special reason to use an .otf font and then just have some good fallback system fonts. The problem with using external font libraries is that the only performance benefit from them is if the visitor has the same font from the same resource in their cached files from viewing said font on a different site. There are so many fonts on sites like Googlefonts and Typekit this isn't as likely as you think, and even then I've still not seen any improvement in performance. You can download the font files from Google (or of course from many other sources) and then convert them to woff and woff2 here:
https://onlinefontconverter.com/
Then load them into your site at the top of your site's CSS file. The example below is if I was using a font called geo-light and the font files are inside a font folder in the root of my site
#font-face {font-family: 'geo-light';
src: url('fonts/geo-light.woff2') format('woff2'), url('fonts/geo-light.woff') format('woff');
font-weight: normal;
font-style: normal;
}
You must set the font-weight and font-style to normal in the #font-face declaration and then add this again in terms of how you want the actual text styled in your elements. This will prevent rendering discrepancies across different browsers. If you download the actual different font-weights as different files you'll always need to set these to normal. Doing it this way will also prevent the dreaded FOUT.
h1, h2, h3 {
font-family: 'geo-light', sans-serif;
font-weight: normal;
font-style: normal;
}
I'm just starting to use HTML5 and CSS3 in my documents.
I understand the need for JavaScript to bring Internet Explorer up to speed with these new tags and styles, but I don't know which to use and when!
My plan was to use html5shiv and IE9.js to look after the HTML5 tags as well as the transparent pngs (and whatever other pesky errors they fix) but then Modernizr and CSS3 Pie were brought to my attention.
My question is, if I use Modernizr, does it look after my need for html5shiv as well as IE9.js? Or should I include these as well? What is the overlap, if any?
And what does CSS3 Pie do that Modernizr or the others doesn't? Or vice versa?
I appreciate your guys help. Let me know what you do!?
I've got extensive experience with all of these, having used them for a few years each.
Modernizr
Includes HTML5shiv functionality
Also does a lot more – if you don't use the other features, then don't use it, it does slow down page loads, but is worth it if you need it!
HTML5shiv
Very small, just fixes html5 elements in IE, nothing else.
CSS3PIE
Lets you use border-radius, gradients and box shadow in older versions of IE. Also can allow PNGs in IE 6. Adds a noticeable delay to page load.
ie7.js (and ie9.js)
Gives you many CSS3 selectors, min and max width, multiple classes and fixed positioning. Also can have a png fix if you like. Doesn't seem to slow things down much.
Conclusion
My advice would fall into two categories:
If you are just using the new (is 2 years new on the internet?!) elements, and CSS3 selectors, then use ie9.js + the html5shiv. This is lightweight, and just lets you get on with things without having to remember that IE6 doesn't support anything.
If you are using a lot of CSS3 stuff, then CSS3PIE will sort out border-radius and box-shadow. The gradient support seems a little flaky, so I've always used a fallback image instead. Modernizr lets you easily deliver different properties to browsers with different support. I've mainly used this for determining whether a browser has CSS transitions and transforms, as they are useful for any image sliders or content carousels. It's worth using the customisation tool to only include the functionality that you want – the webforms stuff shows a textbox with 50 in it for a couple of milliseconds, so it's worth disabling if you don't want it.
Hope that's helpful!
I would recommend you use only what you need. Build your app in a browser that supports the features you are using, and periodically test in other browsers that you support. If something isn't working correctly, find the appropriate fix, whether it be html5shiv, IE9.js, Modernizr, or CSS3 Pie. You are not going to use all of the new features in HTML5 and CSS3 all in one page, so you don't need to include every polyfill library in existence. Wait until you find problems with the features you're trying to use, then try and find the library necessary to do that.
I've used mainly CSS3Pie...it works great. But this afternoon i tested it on my laptop with I.E8 and there was an problem with it...it was disabling some css lines...when i removed the css3pie code my site gained twice the speed...then i came accross the posts with people arguing about the css3 slowdown...So at the moment i'm busy to find another way for IE7 & IE8 to have border-radius and shades.
If you want to use it...please test alot as it is NON-official fixes
There are several helpful JavaScripts and .htc behaviors that patch over the holes & buggy features in Internet Explorer's rendering engine. It seems most of them have some overlapping or incomplete feature support and it's hard to decide what to use:
DD_Roundies: border-radius
Fetchak ie-css3: border-radius, box-shadow, text-shadow emulation using VML
Keith Clark's ie-css3: advanced selector support
CSS3 PIE: border-radius, box-shadow, border-image, multiple background images, linear-gradient as background image, rgba
IE PNG Fix: Alpha-transparent PNG support using AlphaImageLoader
DD Belated PNG Fix: Alpha-transparent PNG support using VML
Dean Edwards IE[7-9].js: advanced selectors, alpha-transparent PNG, position:fixed, min/max-width/height, box-sizing
eCSStender: css3 selectors
Selectivizr: css3 selectors
Please add to this list if you have any more: this is a community wiki.
Which are your preferred scripts? What are the benefits & limitations & gotchas?
Update: these scripts are now commonly called "Polyfills"
Not a script, but probably worth mentioning the Google Chrome Frame plug-in:
Google Chrome Frame is an open source plug-in that seamlessly brings Google Chrome's open web technologies and speedy JavaScript engine to Internet Explorer. With Google Chrome Frame, you can:
Start using open web technologies - like the HTML5 canvas tag - right away, even technologies that aren't yet supported in Internet Explorer 6, 7, or 8.
Take advantage of JavaScript performance improvements to make your apps faster and more responsive.
HTML5 Shiv: HTML5 IE enabling script.
But basically, these scripts get the work done, but at the cost of performance issues and such. There are some acceptable workarounds such as using "PNG8 alpha transparency" as a replacement for PNG fix. It's just a matter of project type.
I suggest also Blueprint CSS
http://www.blueprintcss.org/
Quoting their website..
What does Blueprint have to offer?
* A CSS reset that eliminates the discrepancies across browsers.
* A solid grid that can support the most complex of layouts.
* Typography based on expert principles that predate the web.
* Form styles for great looking user interfaces.
* Print styles for making any webpage ready for paper.
* Plugins for buttons, tabs and sprites.
* Tools, editors, and templates for every step in your workflow.
I am using Large fonts in my website at a few places and they don't appear anti-aliased or smooth... I was wondering if their is any way to show large anti-aliased fonts for browsers on windows OS which has anti-aliasing switched off as default... Similar to something they have on this website here
You can't control system anti-alias in CSS.
For that, you would have to use Flash text replacement, like sIFR (they are using h2swf)
If the user's OS or browser does not have anti-alias switched on, there's nothing you can do to force either to use it. You can use other rendering platforms like Flash, or using CCS to replace text with images, to allow fonts to be displayed with anti-aliasing, but it does seem like a kludge for something as simple as rendering text. Technologies like Flash will also alienate certain audiences, either whose devices have no support for them or they simply opt out of using them.
If your user does not have AA enabled, arguably they are displaying a preference or simply don't care about the particulars of how the font is rendered. At the end of the day, you simply cannot directly control the client your users will use to consume your website. On the web you will always be at the mercy of the client application. The best you can do is present it clearly and in such a way that it should be easy for users to get the best experience they can achieve with their client.
Don't lose any sleep over whether your pixels are slightly less pretty on one client.
Cufon is an alternative to sIFR. See comparison here:
http://net.tutsplus.com/tutorials/html-css-techniques/six-ways-to-improve-your-web-typography/
Good news : in IE9 (released 3/14/11) they seem to put much larger text as anti aliased by default. I have hardware acceleration disabled - so it probably has this effect for all users.
Warning: this is an exercise in futility but....
I did notice that the text-shadow css property seems to force anti aliasing in some browsers. Unfortunately I think only Chrome at this time...
Here's a sample...
(each heading is shown first normally - and then with a text shadow).
Best viewed in Chrome!
Suppose I have the following CSS rule in my page:
body {
font-family: Calibri, Trebuchet MS, Helvetica, sans-serif;
}
How could I detect which one of the defined fonts were used in the user's browser?
For people wondering why I want to do this is because the font I'm detecting contains glyphs that are not available in other fonts. If the user does not have the font, then I want it to display a link asking the user to download that font (so they can use my web application with the correct font).
Currently, I am displaying the download font link for all users. I want to only display this for people who do not have the correct font installed.
I've seen it done in a kind of iffy, but pretty reliable way. Basically, an element is set to use a specific font and a string is set to that element. If the font set for the element does not exist, it takes the font of the parent element. So, what they do is measure the width of the rendered string. If it matches what they expected for the desired font as opposed to the derived font, it's present. This won't work for monospaced fonts.
Here's where it came from:
Javascript/CSS Font Detector (ajaxian.com; 12 Mar 2007)
I wrote a simple JavaScript tool that you can use it to check if a font is installed or not.
It uses simple technique and should be correct most of the time.
jFont Checker on github
#pat Actually, Safari does not give the font used, Safari instead always returns the first font in the stack regardless of whether it is installed, at least in my experience.
font-family: "my fake font", helvetica, san-serif;
Assuming Helvetica is the one installed/used, you'll get:
"my fake font" in Safari (and I believe other webkit browsers).
"my fake font, helvetica, san-serif" in Gecko browsers and IE.
"helvetica" in Opera 9, though I read that they are changing this in Opera 10 to match
Gecko.
I took a pass at this problem and created Font Unstack, which tests each font in a stack and returns the first installed one only. It uses the trick that #MojoFilter mentions, but only returns the first one if multiple are installed. Though it does suffer from the weakness that #tlrobinson mentions (Windows will substitute Arial for Helvetica silently and report that Helvetica is installed), it otherwise works well.
A technique that works is to look at the computed style of the element. This is supported in Opera and Firefox (and I recon in safari, but haven't tested). IE (7 at least), provides a method to get a style, but it seems to be whatever was in the stylesheet, not the computed style. More details on quirksmode: Get Styles
Here's a simple function to grab the font used in an element:
/**
* Get the font used for a given element
* #argument {HTMLElement} the element to check font for
* #returns {string} The name of the used font or null if font could not be detected
*/
function getFontForElement(ele) {
if (ele.currentStyle) { // sort of, but not really, works in IE
return ele.currentStyle["fontFamily"];
} else if (document.defaultView) { // works in Opera and FF
return document.defaultView.getComputedStyle(ele,null).getPropertyValue("font-family");
} else {
return null;
}
}
If the CSS rule for this was:
#fonttester {
font-family: sans-serif, arial, helvetica;
}
Then it should return helvetica if that is installed, if not, arial, and lastly, the name of the system default sans-serif font. Note that the ordering of fonts in your CSS declaration is significant.
An interesting hack you could also try is to create lots of hidden elements with lots of different fonts to try to detect which fonts are installed on a machine. I'm sure someone could make a nifty font statistics gathering page with this technique.
A simplified form is:
function getFont() {
return document.getElementById('header').style.font;
}
If you need something more complete, check this out.
There is a simple solution - just use element.style.font:
function getUserBrowsersFont() {
var browserHeader = document.getElementById('header');
return browserHeader.style.font;
}
This function will exactly do what you want. On execution It will return the font type of the user/browser. Hope this will help.
Another solution would be to install the font automatically via #font-face which might negate the need for detection.
#font-face {
font-family: "Calibri";
src: url("http://www.yourwebsite.com/fonts/Calibri.eot");
src: local("Calibri"), url("http://www.yourwebsite.com/fonts/Calibri.ttf") format("truetype");
}
Of course it wouldn't solve any copyright issues, however you could always use a freeware font or even make your own font. You will need both .eot & .ttf files to work best.
Calibri is a font owned by Microsoft, and shouldn't be distributed for free. Also, requiring a user to download a specific font isn't very user-friendly.
I would suggest purchasing a license for the font and embedding it into your application.
I am using Fount. You just have to drag the Fount button to your bookmarks bar, click on it and then click on a specific text on the website. It will then show the font of that text.
https://fount.artequalswork.com/
You can use this website :
http://website-font-analyzer.com/
It does exactly what you want...
You can put Adobe Blank in the font-family after the font you want to see, and then any glyphs not in that font won't be rendered.
e.g.:
font-family: Arial, 'Adobe Blank';
As far as I'm aware there is no JS method to tell which glyphs in an element are being rendered by which font in the font stack for that element.
This is complicated by the fact that browsers have user settings for serif/sans-serif/monospace fonts and they also have their own hard-coded fall-back fonts that they will use if a glyph is not found in any of the fonts in a font stack. So browser may render some glyphs in a font that is not in the font stack or the user's browser font setting. Chrome Dev Tools will show you each rendered font for the glyphs in the selected element. So on your machine you can see what it's doing, but there's no way to tell what's happening on a user's machine.
It's also possible the user's system may play a part in this as e.g. Window does Font Substitution at the glyph level.
so...
For the glyphs you are interested in, you have no way of knowing whether they will be rendered by the user's browser/system fallback, even if they don't have the font you specify.
If you want to test it in JS you could render individual glyphs with a font-family including Adobe Blank and measure their width to see if it is zero, BUT you'd have to iterate thorough each glyph and each font you wanted to test, but although you can know the fonts in an elements font stack there is no way of knowing what fonts the user's browser is configured to use so for at least some of your users the list of fonts you iterate through will be incomplete. (It is also not future proof if new fonts come out and start getting used.)