So I have this #fontFace rule
#font-face {
font-family: 'myriadPro-Black';
src: url("fonts/myriadPro-BlackCond.otf") format("opentype");
}
It works in Chrome and Safari, but not Firefox. I understand that Firefox has different rules for fontface than other browsers, but I am having a hard time understanding. Getting used to cross browser optimization.
Any ideas on what I'm doing wrong?
Multiple extention's for wider support:
How i generate my fontface rule's is by using a online generator.
It save's a lot of time as it write's everything in the good order.
Plus it make's sure you support a wide variety of different extentions.
An example of such a generator can be found here: http://www.fontsquirrel.com/tools/webfont-generator
Security problem with firefox:
FireFox has secured the #font-face. Firefox for example might throw a 301 error, saying you don't have permission of access to the font file and therefor not load it, while other browsers don't.
You could give the right permissions using .htaccess or whatever config file for the webserver you working on but since i use a variety of webservers this is annoying. What works best for me is placing the font file's in the same directory as the .css file.
So i have one external fonts.css file containing all the css font line's within the font directory. Then i can include this .css file on the page i would like to use this font. Make sure you don't make additional directory's so you can call the font without anny directory. In your example, placing the font file in your css directory and change the code to:
#font-face {
font-family: 'myriadPro-Black';
src: url("myriadPro-BlackCond.otf") format("opentype"); }
more info: https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face
Related
I am trying to use a font awesome icon in a widget that is installed on a customers website. The font awesome icons displays correctly in Safari and Chrome but doesnt in Firefox. However, it still displays correctly in Firefox when previewing it on our site. Does this have something to do with how Firefox displays third party fonts across domains?
Any ideas would be greatly appreciated. Thanks.
Note: This was tested using Firefox V9 and above.
Firefox only allows cross-domain linking of fonts if the server the font is on sends the right CORS headers. And it does this because the spec very clearly says to do it, at http://dev.w3.org/csswg/css3-fonts/#default-same-origin-restriction
I notice a strange behaviour, probably related to the firefox security policies.
I had the same problems with a project configuration like so:
/site/html <--- where all the .html files go
/site/resources/... <--- where all the css, font, img, js stuff goes
now, I included the font-awesome.min.css in an html file located under the /site/html directory and I experimented your problem.
But when you download the Font Awesome package it is shipped with html demo files that actually works in firefox. What's the trick?!
Their project structure has the "resources" folder (they call it "assets") nested inside the "html" folder. This seems to calm down the firefox security policy.
Finally, my answer is: get a configuration like the following
/site/html <--- where all the .html files go
/site/html/resources/... <--- where all the css, font, img, js stuff goes
it worked for me.
If you are hosting your font on S3, you have to enable CORS on the bucket. See my answer to this other question for details
MaxCDN identified and fix this issue. They set the right CORS headers and embedding this line to your website should work:
<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
Firefox blocks Cross-Origin Request.
Firefox disallows reading the remote resource due to Same Origin Policy for below CDN:
https://maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css
I dug little to fix CORS issue instead I replaced above CDN with below one and icons rendering fine:
<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.1.0/css/font-awesome.min.css" media="all" rel="stylesheet" type="text/css">
Use direct link for including css files , also make sure you don't get a cross-domain error in the debugging console .
For example when you access your website from :
http://www.domain.tld make sure you link css file from the same path including www
like so : http://www.domain.tld/css/style.css
and when you access from http:// > link css files also from that very same path without www.
http://domain.tld/css/style.css
i got that issue some time ago and it was fixed by modifying css paths to request css files from the "same" web address / path .
example:
you can view font awesome icons in this path
http://webake.ro/
But not in this one :
http://www.webake.ro/
because the font was linked from within http://domain.tld path without adding www. in the
link href=
Font from origin 'http://webake.ro' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.webake.ro' is therefore not allowed access.
Turn your fonts into base64 and include through CSS. This way you push the fonts through the browser code and the font files are not downloaded in the usual fashion needing cross domain permissions. This is also a DISA STIG issue to disable downloadable fonts but probably not your issue here. The solution can be seen at this post and also copied here:
You just need to Base64 the font and include it in a CSS file. Make sure to remove your call to the downloadable WOFF file once you include the call to the new FontAwesomeB64.css
Use https://www.base64encode.org/ to encode the WOFF Font-Awesome font file.
Edit the the resulting file and add these lines. When you get to the src:url line, make sure to run that right into the base64 information you received (don't use the greater than and less than signs I show here.) At the end of that base64 information add the single quote, parentheses, a semi-colon, and curly brace to finish:
#font-face {
font-weight: 400;
font-style: normal;
font-family: 'FontAwesome';
src:url(data:application/x-font-woff;base64,<insert base64 code here>);}
You now have a base64 CSS file of the Font-Awesome font that bypasses all font download denial settings in browsers.
I've found that this works with all fonts, a little heavier on the download but worth the guarantee of functionality.
#font-face{font-family:'FontAwesome-webfont';
trust me, this really works.
I am designing a splash page for a public wifi access point and Firefox refuse to display my custom font, while it work in every other browser (well, not IE < 9 but that was expected).
The page need to work in the following constraint :
No access to the Internet : This page is displayed before the user accept the term and condition, so everything is blocked
The page is stored on the access point : That mean an embedded server probably written in C, and I can't really add additional header or something. Well its open source so it may be possible, but I am most certainly not an embedded developer!
The WiFi is used to advertise the small town in which it is offered, so it should be as pretty as possible.
To meet those constraint I used the #font-face with a data uri, like so :
#font-face {
font-family: Lato-Light;
src: url(data:application/font-woff;base64,<large base64 string>)
format('woff');
}
h1{
font-family: Lato-Light, Helvetica, sans-serif;
}
It work like a charm... Except in Firefox. Now I understand that it won't work in older IE, but I am ready to work with that. But it seem strange to me that a so-called modern browser would not offer that feature. Why isn't this working?
EDIT : Of course, I have a lot of idea for fallback, but my question here is more : Why does firefox have this behavior that is not the same as the other browsers? Is it a security setting? A bug in the data-uri implementation? A size limit for the data-uri?
In the end, the problem was that I used a woff font generator that produced an incorrect font. Safari and IE were able to read it, but Firefox and the latest version of Chrome rejected it since it contained some errors. By using a more recent woff font generator, I was able to make it work across all browser.
The correct woff font generator
http://people.mozilla.org/~jkew/woff/
For more detail, check that bugs report :
https://bugzilla.mozilla.org/show_bug.cgi?id=735556
I'd like to thank Jonathan Kew of Mozilla for providing the answer.
To cut down on HTTP requests, I subset and Base64 embedded a couple webfonts into my CSS (Font Squirrel #font-face generator, advanced settings, and for icon fonts I used icomoon.io).
Thinking I was really clever I served them from a static subdomain...No go in Firefox.
Turns out it was a restrictive cross-domain resource setting that is apparently unique to Firefox. When I uploaded the HTML5 Boilerplate 'standard' .htaccess file, it specifically permits it and it took care of the problem.
Hope it helps future readers, it stumped me for a while...sorry if my terms lack precision, I'm still pretty new at this (it is well explained in the H5BP .htaccess comments and docs).
Does anybody know why #fontface will work sometimes in Firefox but not others?
On this page... http://www.independentink.ca/gameday/indexb.htm you can see 'Design Packages' written in an embedded font. Then, I try to implement some League Gothic on the same page, as seen here... http://ggszabo.com/new/indexb.html and it won't work.
I'm viewing both in FF and one works while the other doesn't. My code is exactly the same on both.
I've searched for answers but none address this problem specifically.
My css is as follows.
#font-face {
font-family: 'League Gothic';
src: url('../fonts/League_Gothic.eot');
src: local('☺'),
url("../fonts/League_Gothic.woff") format("woff"),
url("../fonts/League_Gothic.svg") format("svg");
}
Please help!
I found an answer for local development at least...
"Firefox comes with a very strict "file uri origin" (file:///) policy by default: to have it to behave just as other browsers, go to about:config, filter by fileuri and toggle the following preference:
security.fileuri.strict_origin_policy
Set it to false and you should be able to load local font resources across different path levels."
I have yet to see if it works when published. I have reason to believe that it will.
I'm using #font-face for the first time, and it seems like the font file is always the last resource to load on the page, no matter what. I'm using a Font Squirrel-generated kit with the smiley syntax. I've tried some of the techniques suggested here, among other places, to get the font to download earlier, including putting the font directly as data in the CSS and putting a styled element in the head section of the document. None of these techniques are working; in Chrome, FF, and IE the font file is always downloaded very last.
Is there any to affect the order in which the font loads?
There is a related question here, but it just links to the same Paul Irish post I mentioned.
Font loading differs from browser to browser (i guess you're reffering to FOUC).
I think the only browser that loads it as fast as it reads the #font-face rule is IE and Opera.
EDIT with samples:
Here are some net load lists for a simple site:
font-family is called last in .css file - after all background
images
font being loaded is scriptbl-webfont
#font-face is
defined at top of css after the reset styles.
FF5 - font loads last:
IE9 - font loads on #font-face - and before background images:
Opera 11 - font loads #font-face - and before background images:
Safari 5 - font loads last (there is no favicon in my folder - Safari adds that by itself):
I'm not sure what your experiencing is a problem. To me using a different font that needs to be downloaded should be one of the last things to happen. The different font is a presentational piece, it's extra not required in my mind, let all of the required stuff download and then the extras.
For example if I put "C:\docs" in address bar of Firefox, it shows all files in the directory. Is it possible to customize this page with CSS?
Apache 2.2 allows us to do it using IndexStyleSheet directive, so I wondered if Firefox can do it.
Firefox has a file userContent.css for each profile (found in the profile's settings folder). That file defines the standard CSS, why may then be overwritten by a website. So they also apply to directory listings.
You should have a look at the actual HTML code Firefox is creating for the directory listing to see how to do the CSS definitions right. You will find extensive documentation about userContent.css on the web.
http://www.mozilla.org/unix/customizing.html#userContent
I think the easiest way is to create an own skin which custom css. You have to modify dirListing.css in this case. (chrome://global/skin/dirListing/dirListing.css)
I know the walnut theme (https://addons.mozilla.org/en-US/firefox/addon/122) includes a modified file listing.