Asked  7 Months ago    Answers:  5   Viewed   98 times

The following code works in Google Chrome beta as well as IE 7. However, Firefox seems to have a problem with this. I'm suspecting it to be a problem of how my CSS files are included, cause I know Firefox is not too friendly about cross-domain imports.

But this is all just static HTML and there's no question of cross-domain.

On my landing-page.html I do a CSS import like so:

<link rel="stylesheet" href="../css/main.css" type="text/css" media="screen, projection" />

Within the main.css I have another imports like so:

@import url("reset.css");
@import url("style.css");
@import url("type.css");

and within the type.css I have the following declarations:

@font-face {
    font-family: "DroidSerif Regular";
        src: url("font/droidserif-regular-webfont.eot");
        src: local("DroidSerif Regular"), 
                url("font/droidserif-regular-webfont.woff") format("woff"), 
                url("font/droidserif-regular-webfont.ttf")     format("truetype"), 
                url("font/droidserif-regular-webfont.svg#webfontpB9xBi8Q")     format("svg"); 
    font-weight: normal; font-style: normal; }
@font-face {
    font-family: "DroidSerif Bold";
    src: url("font/droidserif-bold-webfont.eot");
    src: local("DroidSerif Bold"), 
        url("font/droidserif-bold-webfont.woff") format("woff"), 
        url("font/droidserif-bold-webfont.ttf") format("truetype"), 
        url("font/droidserif-bold-webfont.svg#webfontpB9xBi8Q") format("svg");
    font-weight: normal; font-style: normal; }

body { font-family: "DroidSerif Regular", serif; }
h1 { font-weight: bold; font-family: "DroidSerif Bold", serif; }

I have a directory called "font" in the same location as type.css. This font directory contains all the woff/ttf/svg files etc.

I'm stumped on this one. It works in Chrome and IE but not on Firefox. How is this possible? What am I missing?




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:


Set it to false and you should be able to load local font resources across different path levels.


As per my comment below, and you are experiencing this problem after deploying your site, you could try to add an additional header to see if your problem configures itself as a cross domain issue: it shouldn't, since you are specifying relative paths, but i would give it a try anyway: in your .htaccess file, specify you want to send an additional header for each .ttf/.otf/.eot file being requested:

<FilesMatch ".(ttf|otf|eot)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"

Frankly, I wouldn't expect it to make any difference, but it's so simple it's worth trying: else try to use base64 encoding for your font typeface, ugly but it may works too.

A nice recap is available here

Tuesday, June 1, 2021
answered 7 Months ago

this works in ie8/9

@font-face {
    font-family: 'AftaserifRegular';
    src: url('AftaSerifThin-Regular-webfont.eot');
    src: url('AftaSerifThin-Regular-webfont.eot?#iefix') format('embedded-opentype'),
         url('AftaSerifThin-Regular-webfont.woff') format('woff'),
         url('AftaSerifThin-Regular-webfont.ttf') format('truetype'),
         url('AftaSerifThin-Regular-webfont.svg#AftaserifRegular') format('svg');
    font-weight: normal;
    font-style: normal;

Thursday, June 17, 2021
answered 6 Months ago

This could be related to an issue with the Security Settings as described in this bug report.

In Internet Options go to:

  • The Security Tab
  • Security level for this zone
  • Custom level
  • Downloads
  • Font Download

If it's Disabled then you need to Enable it.

Screenshot of the Internet Options window. The Security tab is selected and the "Custom level..." button has a red box around it.

Screenshot of the Security Settings window. Font download's "Enable" option has a red box around it.

Thursday, June 24, 2021
answered 6 Months ago

A hat tip to Jonathan Kew's response on a relevant mozilla bugzilla entry:

I believe this is working as designed. AIUI, the issue here is that for a page loaded from a file:// URI, only files in (or below) the same directory of the filesystem are considered to be "same origin", and so putting the font in a different subtree (../font/) means it will be blocked by security policy restrictions.

You can relax this by setting security.fileuri.strict_origin_policy to false in about:config, but as this gives the page access to your entire local filesystem, it's something to be used with caution.

To summarise, the "fix" without re-arranging your files:

  • Open about:config
  • Set security.fileuri.strict_origin_policy to false
  • Beware of the security implications

The best way is, however, to make sure any resources are accessible without going back up the file system first.

Note: the origin policy is calculated based on the html, NOT the css file! So a font file right besides an css file might not work, which is very confusing. (At least this is what I thought was the case with Firefox!)

Follow ups:

eradman comments:

It's the other way around: relative paths are relative to the CSS file.

chrylis responds:

You'd think that, but the actual code in Firefox doesn't seem to agree.

Wednesday, July 21, 2021
answered 5 Months ago

The solution is not straightforward. Font appearance varies by browser, OS, and of course by which fonts are available on the client's system. Don't take this answer at face value without further testing based on your target audience.

On Windows, ever since Firefox 4 and IE9, fonts are rendered using DirectWrite instead of GDI. Since this change, fonts like "Arial Narrow" and "Arial Black" are considered part of the Arial family and not as standalone families. So in Firefox, you access Arial Narrow through the regular Arial declaration with some modifiers. IE9 works in a similar fashion, but seems to have some pragmatic cheats baked-in that makes it work in the way developers have been used to.

Franklin Gothic Medium

font-family: "Franklin Gothic Medium", "Franklin Gothic", sans-serif;

All browsers except Firefox understand "Franklin Gothic Medium". Firefox doesn't and goes on to the next choice, "Franklin Gothic", which you might not even think you have, but that is where "Franklin Gothic Medium" is living in the DirectWrite world. In the absence of any other modifiers (italic, bold, stretch), my Firefox grabs "Franklin Gothic Medium" when "Franklin Gothic" is specified.

Arial Narrow Bold

font-family: "Arial Narrow Bold", "Arial Narrow", "Arial", sans-serif;
font-stretch: condensed;
font-weight: 700;

Some browsers, like Chrome and IE7–8 recognize "Arial Narrow Bold". But IE9 and Firefox do not. IE9 does recognize "Arial Narrow". Firefox falls down to Arial. font-stretch: condensed tells Firefox to use the "Arial Narrow" version of Arial, and font-weight: 700; tells both IE9 and Firefox to use to the "Arial Narrow Bold" version as far as I can tell. Font weights of 600, 700, 800, and 900 are triggering the bold for me.

Franklin Gothic Medium with Arial Narrow Bold fallback

Now you've got a Catch-22.

font-family: "Franklin Gothic Medium", "Franklin Gothic", "Arial Narrow Bold", "Arial Narrow", "Arial", sans-serif;

If Firefox can find "Franklin Gothic" you are fine, but if it can't then it will fall back to "Arial". If you use font-stretch: condensed; font-weight: 700; to turn that into "Arial Narrow Bold", you will affect the appearance of Franklin when the Arial fallback is not used. Every browser will apply the font-weight rule to Franklin if Franklin is available—not what you want at all. If you use font-stretch: condensed and Firefox has access to Franklin, it will dutifully condense it. (I didn't see that in any other browser.) In your particular situation, I would count on Firefox getting Franklin and accept that regular Arial will be used as the fallback. But adding "Franklin Gothic" (for FF) and "Arial Narrow" (for IE9) is going to help a lot.

(At the time of writing, Chrome is at version 21 and Firefox is at version 14.)

Monday, August 2, 2021
answered 5 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :