7

私は次のHTMLを持っています：

<!DOCTYPE HTML>
<html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=8" />
        <link href='https://fonts.googleapis.com/css?family=Bitter:400' rel='stylesheet' type='text/css'/>

        <style type="text/css">

        h1 {
            font-family: Bitter;
            font-weight: normal;            
        }
        </style>
    </head>
    <body>
        <h1>Why is this different?</h1>
    </body>
</html>

Windows 7のIE9で表示すると、Bitterフォント面が正しく読み込まれ、適用されます。IE9Windows7のHTML

しかし、Windows 8のIE10で表示した場合はそうではなく、デフォルトのフォントフェイス（Times New Roman） にフォールバックします。IE10Windows8のHTML

両方のブラウザが同じものを使用しているDocument Modeので（X-UA-Compatibleメタタグのため）、両方ともBitterフォントを使用するか、失敗してTimesNewRomanフォントにフォールバックすると思いました。ただし、1つは機能しており（Windows 7ではIE9）、もう1つは失敗しています（Windows 8ではIE10）。

これは既知の問題ですか、それとも文書化された機能ですか？

4

4 に答える 4

13

更新しました。

IEの性質上、これは少し複雑な問題のようです。ここでは、特定の状況に応じて異なる問題が発生する可能性があることをカバーするために、ここでの参加者の調査から生じたと思われるオプションを示します。

注：ページが正しくロード/提供されるように、ページのキャッシュを必ずクリアしてください。

オプション1：

互換性メタタグをに変更します <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />。

IE=8からに変更するEmulateIE8と、互換モードでDOCTYPEが尊重され、IEがCSSファイルからフォント設定を正しくロードします。

オプション2：

使用しているファイル形式が、IEが使用および理解できる形式で提供されていることを確認してください。

@font-face {
  font-family: 'Bitter';
  font-style: normal;
  font-weight: 400;
  src: url(https://themes.googleusercontent.com/static/fonts/bitter/v4/XexqN1a_o27MhVVdJFKAcA.eot);
  src: local('Bitter-Regular'), url(https://themes.googleusercontent.com/static/fonts/bitter/v4/XexqN1a_o27MhVVdJFKAcA.eot) format('embedded-opentype'), url(https://themes.googleusercontent.com/static/fonts/bitter/v4/SHIcXhdd5RknatSgOzyEkA.woff) format('woff');
}

これを見渡すときに注意すべき重要な項目は、フォントのファイル形式です。IEフォントのサポートに関する限り、これは少し次のようになります。

  • IE8は.eot形式のみをサポートします。
  • IE9/10は.woffおよび.eot形式をサポートします。

オプション3：

ここでこのオプションに到達している場合は、IEのWeb標準の採用と実装が不十分な場合があることに対処している可能性があります。IE9がページをIE8モードで表示しているだけでなく、.woff形式の独自のサポートも追加している可能性があります。反対に、IE10は、実際にサポートされているファイル形式を使用して、IE8モードでページを正しく表示しています。したがって、私の結論は、IE9がお粗末な標準サポートを隠そうとしている間、IE10は実際にページを正しく表示しているということです。

以下のコメントでも機能しているようだとおっしゃっていたので、ここでもう1つ考えたのは、ブラウザがIE10であったが、コンテンツをIE8モードで表示していたため、Googleが誤って間違った形式を提供していた可能性があるということです。その場合、IE8の「正しい」表示は、IE10で受け入れられる.woffファイルがIE8ではないことを意味します。

サイドノート：

すべてのWeb開発者にとって最大の問題の原因の1つは、この種のことです。IEの競合は、サポートが非常に貧弱で実装が不適切であることを指摘していますが、IEは市場に出回っているPCの大部分にプリインストールされているため、ほとんどが特定のオペレーティングシステムを実行しているため、依然として不利です。これは、標準とベストプラクティスの受け入れ、実装、および使用に関する非常に強力な議論の1つです。

于 2012-09-30T20:46:34.260 に答える
5

フォントが実際にIE8自体で機能しない場合は、IE10の方がIE9よりも優れた互換性エンジンを備えているように見えます。IE8がレンダリングする内容を実際に正しく示しているからです。

IE9 Compat 8で実際にフォントが表示されるのはなぜですか？また、IE8でフォントが機能しないのはなぜですか？私はこれをフォントファイルの問題にチョークで書きます。@font-face問題にかなり悩まされているようです-フォントプロパティの設定は時々それらの1つであるようです。参照：これらのフォントの1つがIE8でレンダリングされるのに、他のフォントはレンダリングされないのはなぜですか？。

フォントをダウンロードし、Font Squirrelsジェネレーターに通し、独自のコードを使用してフォントファイルのセットをローカルでホストすると@font-face、フォントがIE10Compat8で機能することが報告されました。IE9のすべてのCompatモードでも機能することを確認できます。 IE7/8と同様に。

苦いフォントは、フォントリスが生成したフォントファイル/コードを使用してIE10互換モードで動作します。

他のGoogleフォントがIE9/10 Compatモード8の両方で機能すると述べたように、問題がフォントファイル自体にあるという取引と、IEがそのプロパティでランダムに発生するように見える問題を実際に封印していると思います。Font Squirrelジェネレーターは、問題に関してはほとんどの人の問題を修正しているようですが、「IE8でこれらのフォント面の1つがレンダリングされるのに、他のフォントはレンダリングされないのはなぜですか？@font-face」でわかるように。、常にそうであるとは限りません。

これは互換性のみの問題ではないため（IE8ではまったく機能しません）、フォントをローカルでホストすることが唯一の選択肢のようです。

フォントをより細かく制御し、フォントのロード中または失敗中に要素CSSを操作する機能が必要な場合は、フォント（@ font-face）がすでにロードされているかどうかを確認する方法を参照してください。

于 2012-09-27T10:30:24.480 に答える
0

IE8では（IE8ドキュメントモードで実行されている別のIEバージョンとは対照的に）上記のHTMLが機能しないことを確認しました（つまり、Windows 8の例のIE10のように表示されます）ので、IE10のバージョンが変更されているように見えますより正確なIE8ドキュメントモード。

于 2014-01-28T20:25:45.777 に答える
0

サーバーがApacheの場合、Webサイトのルートにある.htaccessファイルのby2行でこのディレクティブを置き換えることができます。

BrowserMatch MSIE best-standards-support
Header set X-UA-Compatible IE=8 env=best-standards-support

これにより、IE8をエミュレートする場合でもIE10またはIE11でのGoogleフォントに問題はなくなりました。

于 2014-02-05T18:54:37.960 に答える