3番目の編集:動作するテストケースです。 svgスプライトシートのキャッシュに関係しているようです。 SVGのキャッシュがないようにサーバーでキャッシュ制御を構成すると、動作が発生します。ソースを自由に表示してください(1つのファイルにすべて含まれていますが、ここにすべてを含めたくありません)。
https://stuff.spherical.fish/svgtest.html
2番目の編集:以下にリストされている修正(外部スプライトシートを使用する代わりにindex.htmlの要素を直接挿入する)は、Chrome v49(私のベータチャンネルブラウザが更新されたばかり))で動作を停止しました。 v48には断続的なレンダリングの問題がありますが、v49は<svg><use></use></svg>
パターンに従って参照されるものanythingを一貫してレンダリングしませんが、大きな場合のみ、複雑なangular page。退屈な単純なテストケースは問題なく動作します。既知の問題やこれがどこから来たのかを直接指摘できる人に報奨金を追加しました。 -not-found、これはまだ断続的なバグであり、ページ全体がfirefoxおよびsafariで正常にレンダリングされます。
編集:これは間違いなく外部リソースへの参照に関係しています。 SVGをindex.htmlに直接埋め込み、<use xlink:href="#id"></use>
でそれらを参照する場合、それらは正常に機能しますが、<use>
要素で外部ファイルを参照する場合、それらは時々ロードされるだけです。
chrome(のみ-これはオペラ、firefox、safariでは発生しません)で奇妙な動作があります。少なくとも40年代前半からバージョンごとに見ています。
私の動作は、ng-repeated angular構造の真ん中にあります。すべてが同じです。フレックスボックスにまとめられたdivがたくさんあります。次のようなSVG要素もあります。
<svg class="icon-3">
<use xlink:href="/assets/trellis-icons.svg#icon-users"></use>
</svg>
とても簡単です。
問題は、これらの繰り返される要素のsomeの場合、アイコンがレンダリングされないことです。 chrome devツールで要素を検査すると、レンダリングされたSVGの<use>
要素には高さと幅があり、レンダリングされていない要素にはゼロの高さと幅があることがわかります。
ここに本当の違いがあるわけではありません。 DOMを手動で編集して、問題のあるエントリの1つをレンダリングされたエントリの1つと完全に一致させましたが、svgはまだレンダリングされません。関連するスクリーンショットを次に示します。
以下を見ることができます(ボタンのパディングの問題は無視してください)、最初の行には小さな頭とWordバブルアイコンがありません。これは断続的な問題です。ページをリロードしても問題ないか、アイコンがまったくロードされない可能性があります。
私は疑問に思っています:スプライトシート(この動作を示すすべてのSVGは同じ大きなSVGファイル内にあり、#idによって参照されます)を非同期または何かにロードすることに関連した何らかの不明瞭な問題がありますか?
これが本当に未知/新しい動作である場合、テストケースのエンジニアリングに取り組みますが、何らかの並行性のバグに依存する可能性のあるものを作成するのは、ちょっと難しいです。だから私は最初に尋ねるだろうと思った。
追加する編集:個々のsvgをスタンドアロンとしてエクスポートし、<img src="icon.svg">
方式で使用する場合、この動作は発生しません。単一のスタンドアロンファイルのアイコンでsvgを使用すると、まだ失敗します。
編集:@kaiidoのリクエストごとに、問題の関連するsvgがあります。
<svg xmlns="http://www.w3.org/2000/svg">
<!-- thirty other symbols snipped -->
<symbol id="icon-users" viewBox="0 0 512 512">
<path d="m352 397c-15-16-78-32-109-48c-21-11-32-33-32-53c0-10 7-19 13-26c5-6 9-14 13-24c8-4 18-12 18-31c0-12-2-19-5-24c1-11 2-22 3-34c4-45-42-90-89-90c-47 0-92 45-88 90c1 12 2 23 3 34c-4 5-5 12-5 24c0 19 9 27 18 31c4 10 8 18 13 24c6 7 13 16 13 26c0 20-11 42-32 53c-18 9-48 19-72 28l0 68l354 0c0 0 0-32-16-48z m146-7c-21-8-46-16-62-24c-17-8-25-27-25-43c0-8 5-15 10-21c4-5 8-12 11-20c7-3 15-10 15-25c0-10-2-16-5-20c1-9 2-18 3-27c3-37-34-76-73-76c-38 0-75 39-72 76c1 9 2 18 3 27c-3 4-5 10-5 20c0 16 8 22 15 25c3 8 7 15 11 20c4 6 10 13 10 21c0 10-4 22-11 31c30 11 43 22 53 33c19 19 19 58 19 58l103 0z"/>
</symbol>
</svg>
結局のところ、これはchromeバグであり、特定の状況下でブレークの周りの<use>
要素を変更することです。これらの状況は基本的には次のとおりです。 svgスプライトシートがブラウザにキャッシュされていないとき。
https://code.google.com/p/chromium/issues/detail?id=580809
カナリア(M50)で修正され、M49にマージされる可能性があります。
回避策は、SVGスプライトシートにゼロ以上のcache-controlヘッダーを設定することです。それはまた、本番環境ではなくテストサーバーでのみこのバグを見た理由を説明するのに役立ちます-ベータボックスで異なるキャッシュ設定があります。
属性xlink:href
はSVG 2から非推奨になりました( 証明リンク )。 Chromeの新しいバージョンは、この属性で奇妙に動作します。
xlink:href
(古代のブラウザ用)とhref
(新しいブラウザ用)を使用すると、どこでも問題なく動作します。
私もこのバグがありました。キャッシュおよびWebkitアップデートにより、pfootiソリューションで修正されました。
しかし、後で戻ってきました。同じものではありませんでしたが、後で他の人に役立つかもしれません。
InkscapeでSVGを開き(ただしIllustratorでも同じ)、オブジェクトを選択してpath
> union
を適用し、保存しました:
<path class="st0" d="M32 272l128 48 16 160 80-112 112 112L480 32 32 272zm318.7 145.4L256 320l128-176-192 153.8-82.6-31 322-172.5-80.7 323.1z"/>
なりました
<path d="M480 32L32 272l128 48 16 160 80-112 112 112L480 32zm-48.6 62.3l-80.7 323.1L256 320l128-176-192 153.8-82.6-31 322-172.5z"/>
そして今、それは動作します!
正確な理由はわかりませんが、Chromeは最初の構文に何らかの問題があるようです。