CSS/DHTMLバグ辞典スレッド【第５版】
これは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での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■ 大見出し３ ←前行末にゼロ幅スペースがあってもソース改行による空白が打ち消されない。 
