Why Do Font Squirrel's @Font-Face Definitions Contain Two Src Declarations

Why do Font Squirrel's @font-face definitions contain two src declarations?

It's an IE9 compatibility mode issue.

For a full explanation, first see: http://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax

How it works

Internet Explorer <9 has a bug in the parser for the src attribute. If you include more than one font format in the src, IE fails to load it and reports a 404 error. The reason is that IE attempts to load as a file everything between the opening parenthesis all the way to the very last closing parenthesis. To deal with that wrong behavior, you merely declare the EOT first and append a single question mark. The question mark fools IE into thinking the rest of the string is a query string and loads just the EOT file.

Then see the follow up article: http://www.fontspring.com/blog/further-hardening-of-the-bulletproof-syntax

A potential looming problem with the new syntax we introduced earlier this month was raised by Microsoft. The soon-to-be-released IE9 comes with a feature that allows it to render in both IE7 and IE8 Modes. In these two modes, Microsoft 'fixed' the parser bug that affected the actual IE7 and IE8. This fix breaks the @font-face syntax for those compatibility modes.

...

This syntax is exactly the same as our previous iteration with the addition of a second 'src:' attribute that specifies the EOT again. We'll leave it up to you to decide if this is necessary.

If you don't care about compatibility view you can clear that first src right out.

If multiple sources are listed in an @font-face, are all of them loaded on the client side?

A typical browser should attempt to load the fonts in the list one by one, depending on what format it supports, starting from the first in the list. Once it obtains a font file that it can use, it doesn't attempt to load any of the rest of the files in the list. If a browser doesn't support a particular format, it should never attempt to load that font; it should move straight on to the next source and looks at that.

This is similar to how a browser uses a font stack in the font-family property.

Of course, not all browsers behave conformingly to the spec. Some browsers like IE will try to download as many fonts as they can or parse the rule in unexpected ways; see the comments for more info and research.

CSS is already designed to help minimize the load time and number of requests through this sequential approach. If your fonts are taking too long to arrive from your own server, consider using a fast CDN instead like Google Web Fonts, Typekit or Adobe Edge.

Why not define font-weight or font-style in @font-face, Font Squirrel?

By default, Font-Squirrel does this in order to increase support with user-agents that do not follow specification (those that ignore font-weight and font-style).

If you do not care about those outdated user-agents, you may enable the "Style Linking" option which is available in the expert section of the @font-face kit generator. Note that IE8 and below ignores numbered font-weight values and only support normal and bold (and corresponding 400, 700 weight values).

CSS, Font-face, Squirrel generator

src: url('someFont.eot'); is for IE9 compatibility Modes, while src: url('someFont.eot?#iefix') format('embedded-opentype') is for IE6 to IE8.

font-family crash with @font-face src

As your code shows that you have included only .eot format webfont in body in css. The .eot format will work only on IE.

Now since you have added only url('../fonts/daxregular-webfont.eot') [notice 'regular'], the IE browser showing your text in regular or not-in-bold format. So if you want to display your text in-bold format on IE, you would need to add an additional url('../fonts/daxbold-webfont.eot') [notice 'bold'] definition in your css and also the relevant font in your font folder.

Now, why chrome displays it properly? I doubt if chrome would be showing your text in your desired font i.e. dax or .eot. Since you have not defined .woff font in your css (which chrome normally requires), most probably using some other font defined in some other css on your page.

To display your page consistently across all browsers using for custom font you would need to add all fonts definition in your css including adding the same in your font folder -

`@font-face {
  font-family: 'dax-regularregular';
  src: url('../fonts/daxregular-webfont.eot');
  src: url('../fonts/daxregular-webfont.eot?#iefix') format('embedded-opentype'),
       url('../fonts/daxregular-webfont.woff2') format('woff2'),
       url('../fonts/daxregular-webfont.woff') format('woff'),
       url('../fonts/daxregular-webfont.ttf')  format('truetype'),
       url('../fonts/daxregular-webfont.svg#svgFontName') format('svg');
}`

---

UPDATE:

First, other then font definition mentioned above you'll also have to add other font formats definitions in your css like

for bold,

@font-face {
      font-family: 'dax-bold';
      src: url('../fonts/daxbold-webfont.eot');
      src: url('../fonts/daxbold-webfont.eot?#iefix') format('embedded-opentype'),
           url('../fonts/daxbold-webfont.woff2') format('woff2'),
           url('../fonts/daxbold-webfont.woff') format('woff'),
           url('../fonts/daxbold-webfont.ttf')  format('truetype'),
           url('../fonts/daxbold-webfont.svg#svgFontName') format('svg');
    }

for semibold,

@font-face {
      font-family: 'dax-semibold';
      src: url('../fonts/daxsemibold-webfont.eot');
      src: url('../fonts/daxsemibold-webfont.eot?#iefix') format('embedded-opentype'),
           url('../fonts/daxsemibold-webfont.woff2') format('woff2'),
           url('../fonts/daxsemibold-webfont.woff') format('woff'),
           url('../fonts/daxsemibold-webfont.ttf')  format('truetype'),
           url('../fonts/daxsemibold-webfont.svg#svgFontName') format('svg');
    }

and so on including relevant fonts in font folder, whichever you need.

Second, for getting these fonts. Not sure but I think your dax font seems a licensed font and not the free one. If yes, then you can convert all above mentioned formats using the ttf / otf font which would have been installed in your system's 'Font' folder. To convert just copy the 'regular' or 'bold' font from that font folder on your desktop and then convert it using website like 'Font Squirrel'

UPDATE 2

1. The IE needs .eot version web-font only, having .woff won't affect text in any IE version. So don't fear of .woff.

2. You need to correct your font definition, which is still incorrect in your last post -

for regular or unbold font,

@font-face {
    font-family: 'dax-regularregular';
    src: url('../fonts/daxregular-webfont.eot');
    src: url('../fonts/daxregular-webfont.eot?#iefix') format('embedded-opentype');
}

for bold format font,

@font-face {
    font-family: 'dax-bold';
    src: url('../fonts/daxbold-webfont.eot');
    src: url('../fonts/daxbold-webfont.eot?#iefix') format('embedded-opentype');
}

Your html should look like this -

<p style="font-family: 'dax-regularregular';"><span style="font-family: 'dax-bold';">bold text lying here</span> unbold text lying here</p>

It should work proper across.

Note: Have shown applying font in inline tag to demonstrate html structure, please use your class for the same.

CSS @font-face - what does src: local('☺') mean?

if you read the notes in font-squirrel's font-face generator, you'll see that it was a gotcha by paul irish.

Here is the excerpt from his blog post:

---

And.. regarding @font-face syntax

I now recommend the bulletproof smiley variation over the original bulletproof syntax.

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('☺'),
       url('GraublauWeb.woff') format('woff'), url('GraublauWeb.ttf') format('truetype');
}

From the bulletproof post:

Yes, it's a smiley face. The OpenType spec indicates any two-byte unicode characters won't work in a font name on Mac at all, so that lessens the likelihood that someone actually released a font with such a name.

There are a few reasons why smiley is a better solution:

• Webkit+Font Management software can
  mess up local references, like
  turning glyphs into A blocks.

• On OS X, Font Management software may
  alter system settings to show a
  dialog when trying to access a
  local() font that's accessible
  outside of Library/Fonts. More detail
  on my bulletproof post.
  Font Explorer X is
  also known to mess up other stuff in
  Firefox.

• Although it's unlikely, you could
  reference a local() font which is
  completely different than what you
  think it is. (Typophile post on
  different fonts, same name) At the
  very least its a risk, and you're
  ceding control of the type to both
  the browser and host machine. This
  risk may not be worth the benefit of
  avoiding the font download.

These are all pretty edge case issues, but it's worth considering.

Is there any way to fix fonts.com @font-face declarations?

I wrote a small Javascript Loader for Fonts.com that allows multiple weights per font-family.
It's based on rossi's approach but converted into a re-usable script. Check out the code and usage in this gist.

Basically it loads the CSS from fonts.com, is modified according to the specified settings and is appended to the <head> of your document.

In your JS:

FontsComLoader.load('HelveticaNeueFontsCom', 'https://fast.fonts.net/cssapi/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.css', {
    'W02-55Roma': '400',
    'W02-75Bold': '700'
});

In your CSS:

.helvetica-regular,
.helvetica-bold {
    font-family: 'HelveticaNeueFontsCom', 'Helvetica Neue', Helvetica, Arial, sans-serif;
}

.helvetica-regular {
    font-weight: 400;
}

.helvetica-bold {
    font-weight: 700;
}

---

Related Topics