CSS/DHTMLバグ辞典スレッド【第５版】
他のブラウザではfont-feature-settingsによる字詰めが有効なのに、IE11だけ無効。
font-familyに游明朝・游ゴシックを指定すると発症。
以下で再現。
.yu {font-family:"游明朝", YuMincho;}
<div class="yu" style="font-feature-settings : 'palt';">
くし」、「ト。りょうった
</div>
Firefox64、GoogleChrome71ではちゃんと字詰めされる。
IEでも、プロポーショナルメトリクス情報を持つ他のフォント（#）にするとpaltが効いたので、これはバグと言ってよいかと。
# "ヒラギノ明朝 ProN W3"・"小塚明朝 Pr6N'"・"IPAmj明朝"・"Source Han Sans"等
Cf. https://helpx.adobe.com/jp/fonts/using/open-type-syntax.html#palt >>605
游明朝のカーニング設定がうまくいかない話
https://qiita.com/y___k/items/7715cccafa6ac2adf2ec
Mac (10.12.6)
■ Chrome(64)、Safari(11)、Firefox(58)
Boldとpknaを組み合わせると、カーニングが無効。
Windows(10)
■ IE11
Boldとpaltを組み合わせると、カーニングが無効。
Normalとpaltを組み合わせると、カーニングが無効。
https://bulan.co/swings/css_around-characters/
Mac OS SierraのChromeで游明朝体の文字詰めが効かなかったり >>604
ここ↓、その@face-font内font-feature-settingsで嵌ってた。
「CSSで行頭の約物を半角にする」
https://dskd.jp/archives/87.html 【Firefox65／GoogleChrome71 バグ】
IE以外で、JIS外字を表示させるとfont-familyプロパティーで総称ファミリー名serifが効かなくなる。
Win8.1で確認。
p {font-family: "游明朝",serif;}
</p>「专」：ユニコード数値文字参照（16進数）→「&;#x4E13;」</p>
鉤括弧「 」内の外字部分だけゴシック体（sans-serif）になる。
FiefoxやChromeは、初期設定で明朝体 (Serif)は游明朝が既定。
それで游明朝に無い外字は他のフォントで表示されるため、ゴシックになると推定される。
しかしserifが無効になるのは指定に反する。
IE11だと他のフォントでも指定通りserifのフォントを選んでくれる（SimSun等の中国語フォントか？）。
総称ファミリーをsans-serifにすればIEでも全てゴシック体表示になったから、IEは正しく動作してる。
ついでに、総称ファミリーをcursiveやfantasyだけにすると――
p {font-family: cursive;}
IEでは、本文がゴシック体だが外字部分は明朝体のまま。
Firefox・Chromeでは、全てゴシック体。但しChromeでは半角英数字に変化あり。
しっかし、IEの方が正しい挙動をするのって珍しくないか。
大抵はIEが足を引っ張るのに。
Cf. http://pentan.info/stylesheet/bug/winie033.html >>608
× 「&;#x4E13;」 &の後の「;」が不要。
○ 「专」 >>608
下記ソースで再テスト。
p {font-family:Tahoma,sans-serif;}
.f01 {font-family:"游明朝";}
<p>「专」：ユニコード数値文字参照（16進数）→「专」</p>
<p class="f01">「专」：ユニコード数値文字参照（16進数）→「专」</p>
IE11ではp.f01で「 」内がsans-serifを継承せずserif（游明朝ではない何かの明朝体）になった。
やはりIEは所詮IEで、対応に問題があるみたい。
Firefox65・GoogleChrome72では「 」内はsans-serif（ゴシック体）のまま。 >>602
>これがRegularでない他のウェイトだと、IEのみが認識するイレギュラーな結果になる。
>"Noto Serif CJK JP Bold" IE○ FF× GC×
>"NotoSerifCJKjp-Bold" IE○ FF× GC×
再現しない。下記の通りになった。
"Noto Serif CJK JP Bold" IE○ FF○ GC×
"NotoSerifCJKjp-Bold" IE○ FF○ GC×
Firefoxで反映しなかったのは、フォントキャッシュとかの問題では？ >>585
>しかしこれがヒラギノだと、
> font-family: "ヒラギノ明朝 ProN W6","HiraMinProN-W6";
>みたいに、ウェイトまでfont-family指定に入れられるんだけど。
否。ヒラギノでもフォント名にウェイト入れるとfont-family指定が反映されない。
Firefox65、GoogleChrome72、Windows8.1にて表示確認。
font-family: "Hiragino Mincho ProN W6"; /*無効*/
font-family: "ヒラギノ明朝 ProN W6"; /*無効*/
font-family: HiraMinProN-W6; /*無効*/
font-family: "Hiragino Mincho ProN","ヒラギノ明朝 ProN"; /*有効*/
IE11では日本語フォント名の"ヒラギノ明朝 ProN W6"と"ヒラギノ明朝 ProN"だけ有効だった。 >>551-553のwhite-space:nowrap;バグ、最新のChrome73になってもまだ直ってないのな。
WebKitのバグってどこに報告すれば修正してくれんのかね？ >>583
>フォント指定でヒラギノや游明朝・ゴシックや小塚明朝・ゴシックにするだけで文字の位置が上にズレ
>先頭に欧文フォント指定すればバグ回避できるけど、半角英数字は当然欧文フォントで表示され不統一に。
このＩＥバグは、ただ先頭に欧文フォントを指定しても、不具合は解消しない。同時に子要素の行間を小さく指定しないと。
下記ソースで確認。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>OpenTypeフォントのIE表示</title>
<style type="text/css">
.otf {background:#ff0; font-size:6em;/*視認しやくすくするため*/
font-family:"Times New Roman",'Kozuka Gothic Pr6N', 'Yu Gothic', 'Noto Sans Japanese', 'Source Han Sans';}
.otf * {border:1px solid red;/*視認しやすくするため*/
line-height:0.1;
white-space:nowrap;/*折り返すと行が重なるので*/}
</style>
</head>
<body>
<div class="otf"><span>壹貳</span>12<a>參肆</a>34</div>
</body></html>
line-heightの値は1.0より小さい方がよいみたい。
div.otf直下の和文フォント適用部分をインライン要素タグ（<del><ins>も可）で括れば、なぜか、文字が上下にはみ出る不具合はなくなる。
欧文フォント適用部分（半角英数字や記号類）は何も括らず剥き出しで直下に置いてよし。
しかし、divの中に<p>56</p>とかブロックレベル要素を入れるとまた隙間が空く。
.otf p * {line-height:10%;} と指定してから
<div class="otf"><p><a>56伍陸</a></p></div>
とインライン要素タグで括って中に半角英数や記号以外の日本語文字を入れると、直る。 >>614
＞.otf p * {line-height:10%;} と指定してから
これは不要だな。既に、全称セレクター*で".otf p * "に対しline-height:10%;を指定済みだから。
必要なのは、第一に、p直下の日本語文字列をインライン要素としてタグ附けすること。
それと、表示させるフォントによって{line-heightの値は上下して調整ねばならず、1.0より大きい方がいいことも。
でもボックス下部に余白が空くから、.otf , .otf * {height:1.2em;}とか、.otf p {margin:0;}とか、追記すべし。
IE11のバグまとめ > 特定のフォントでテキストの下に隙間が空く。
https://qiita.com/sawadays0118/items/bd0731878e9eb49c03f5#-%E7%89%B9%E5%AE%9A%E3%81%AE%E3%83%95%E3%82%A9%E3%83%B3%E3%83%88%E3%81%A7%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%81%AE%E4%B8%8B%E3%81%AB%E9%9A%99%E9%96%93%E3%81%8C%E7%A9%BA%E3%81%8F
「line-heightを限りなく0に近い数値にすることでズレを回避できますが、改行した瞬間に文字が重なって終わるので現実的な解決策ではありません。」
↑これも、line-height:1%;とかやっても利き目なかったけど、font-family先頭の欧文フォント指定と掛け合せた上で２バイト文字列のどれかを<span> </span>で挟めば、行高設定次第でずれ解消が有効になるはず。 >>560 - >>565
Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。
↑これ、全く再現しないね。
font-family:Arial, 'MS Mincho';
とか
font-family:Arial, 'Yu Mincho';
とかで試したけど、ちゃんと日本語の部分は日本語フォントで描画される。
総称ファミリー名のserifを末尾に指定するかどうかも関係無し。
なんか、間違ったのか？ これはCSSのバグなのかどうか……。
InternetExplorer11／Windows8.1で確認。
・フォント・サイズをその要素の横幅以上に拡大すると、IVS（＝基底文字＋VS）のVSが文字化けする。
IVS（異体字シークエンス）は、「通常の文字と同様、数値文字参照を使って書くこともできる。フォントやOS、アプリケーションが対応していない場合には、通常の基底文字のグリフが単に表示される（ことが望まれるが、VSが豆腐などで表示されてしまうことが多い）。」
https://shiromoji.hatenablog.jp/entry/20120308/1331194033
ところが、別に「・」や「□」（豆腐）に化けてなかった文字も、フォント・サイズを一定以上に大きくすると四角になることがある。
下記一行のソースで再現できた。
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
どうもIE11はIVSを「基底文字＋VS」で２文字と計算するらしく、
それで要素の横幅がフォント・サイズ１文字分（1em）より小さいと、１文字はみ出たVSの分だけ文字化けして表示され、基底文字の下に流れて配置される。
width指定で要素の幅がfont-sizeより広く取ってあっても、box-sizing: content-box;（既定）の場合にpaddingとかborderを入れると、この不具合が発現したりする。
floatでwidtj指定を入れる場合にも、注意↓。
実例 http://wakufactory.jp/densho/font/db/mojidb2.html#09038
Firefox67やChrome75では再現しなかった。
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。 >>617 追記修正
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、他方、Chromeでは、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。 font-familyプロパティーの値でインストールされてないフォントのみを指定された場合、継承値を反映しなくなる難があるが、
値の末尾に総称ファミリー名の代りにinheritを指定すると、
Chrome・Firefoxでは継承値で表示されて問題は解消するものの、Internet Explorer 11では無効のまま。
環境はWindows8.1で確認。
body {font-family: YuMincho, '游明朝', serif;}
<p>例１：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝'">馬酔木明朝</span>」ってフォントがある。</p>
<p>例２：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit;">馬酔木明朝</span>」ってフォントがある。</p>
<p>例３：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit, serif;">馬酔木明朝</span>」ってフォントがある。</p>
上記ソースで、本文は游明朝（それが無ければ他の明朝体）になるが、例１の"馬酔木明朝"の文字列はゴシック体になった。
例２でスタイル設定値にinheritを足すと、Chrome75とFirefox67では游明朝になったがIE11ではゴシック体のまま。
例３で値の末尾に更に総称ファミリー名serifを追記すると、IE11だけ游明朝でなく'ＭＳ 明朝'になった。
但し、CSS仕様書を見ると、font-familyプロパティーにおけるグローバル値inheritは、フォントファミリー名や総称ファミリー名とは併記できないらしい。
Cf.「Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification 日本語訳」
15.3 フォントファミリー：'font-family'プロパティ
https://momdo.github.io/css2/fonts.html#font-family-prop
ならば厳密にはスタイルシートのバグではなくてブラウザーごとの仕様なのか？
あと、「馬酔木明朝」は下記で無料配布。
https://metasta.github.io/asebi/ >>619
＞値の末尾に総称ファミリー名の代りにinheritを指定すると、
＞Chrome・Firefoxでは継承値で表示されて問題は解消する
これは指定したinheritの値が有効になったってよりも、
inheritとフォント・ファミリー名との両方を値に記すこと自体が不正で無効（invalid）な書き方だから、
font-family指定そのものが無効になって、親要素bodyへの指定だけが有効になりその値を継承した
――と解釈される。
その証拠にFirefoxでは、body {'MS PMincho'}とかプロポーショナル・フォントを指定した上で
<p>例４：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit, monospace;">馬酔木明朝</span>」ってフォントがある。</p>
<p>例５：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', monospace, inherit;">馬酔木明朝</span>」ってフォントがある。</p>
とか総称フォント名をmonospaceにしても、等幅フォントで表示されなかったし、
<p>例６：Win8.1以降標準装備の「<span style="font-family: YuMincho,'游明朝','Yu Mincho', inherit;">游明朝</span>」ってフォントがある。</p>
とか、インストール済みのフォントファミリー名を指定しても無効になった。
IEは、値の不正な記述の仕方（「不正な値」の指定ではない）でもプロパティーそのものは無効にならない点では、バグである。 >>620修正
＞body {'MS PMincho'}
body {font-family: 'MS PMincho';} >>551
>>551-553 報告のChrome30でのCSSバグは
マイナー極まるブラウザ、Falkon Version 3.1.0 でも再現する。
hrtps://falkon.org
2022年１月に出たヴァージョン3.2.0が最新だが、Windows向けには3.1.0までしか配布されてないので未見。
ウィキペディア曰く「Qt WebEngineから提供されるChromiumエンジンを使用」ってことだけど、
つまりBlinkに移行する以前のChromeに近いのか？ FalkonはWebkit系なのか？
するとWebkitの親玉Safariでも、同じバグが起きてるのかしらん。
「AppleはiOS上で動作するブラウザについて、たとえFirefoxやChromeであっても、ブラウザのレンダリングエンジンにはAppleが開発したWebKitを使うことを強制しています」
tps://news.livedoor.com/article/detail/22408540/
とすると、iPhoneではSafari以外のブラウザでもWebKit特有の問題が発生するのかも。 >>622
Falkonのバグ対策（の失敗）について。
>>551の例で実験。
/* WebKit HackでGoogleChrome30とSafari5とOpera15+対策 */
@media screen and (-webkit-min-device-pixel-ratio:0){
.navbar a {white-space:pre-wrap;}
} /* Falkonにも効く。 */
@-moz-document url-prefix() {/* Firefoxで元の指定に戻す */
.navbar a {white-space:nowrap;}
} /* Falkonには無効、ここまでバグ発生せず。 */
/* Chrome39+ハックで新Chromeや新Edgeも元の指定に戻す */
_:lang(x)::-internal-media-controls-overlay-cast-button, .navbar a {
white-space:nowrap;
} /* 新ChromeだけでなくFalkonにも効いてしまった！ バグが再生。 */ >>622
>>551のバグは、Falkon3.1では、下記を追記すると発生しなくなった。
@media screen and (-webkit-min-device-pixel-ratio:0){
.navbar a {display:inline-block;}
}
要は、折返し禁止（white-space:nowrap;）にするa要素をインラインブロックとして扱ったら、まともにレンダリングしてくれるみたい。
上記WebKitハックによるスタイル指定は、GoogleChrome最新版（バージョン: 108.0.5359.125）でも適用されるものの、指定しない時と比べて特に変化は起きない模様。 >>622
CSSではないけど、そもそもFalkonは行中での折返し（改行）をするアルゴリズムが何かヘン。
非表示のゼロ幅スペース（​ U+200B）を挟んでも、そこで折り返してくれない。
HTMLソースで改行してあると、そこがブラウザ表示でも改行できる位置になる。
ちなみにゼロ幅スペースを入れた直後にソースで改行すると、
ChromeやFirefoxと違ってFalkonの表示ではドット一箇分ほどの幅の隙間が空く。ゼロ幅にならない！
<wbr>タグには対応してるから、そっちを使用すればいいのかもしれんが。 >>626
↓こんなソースで比較してみると。
<h1><a href="">■</a>大見出し１</h1>
<h1><a href="">■</a>
大見出し２</h1>
<h1><a href="">■</a>​
大見出し３</h1>
Chrome108/Firefox108での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■大見出し３ ←前行末にゼロ幅スペースがあるとソース改行による空白が打ち消される。
Falkon3.1.0での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■ 大見出し３ ←前行末にゼロ幅スペースがあってもソース改行による空白が打ち消されない。 
