19/01/15 20:36:41.71 .net
>>587のバグは下記のソースで再現する。
<!DOCTYPE html>
<html lang="ja">
<head>
<title>IE11検索窓プレースホルダー・バグ検証</tutle>
<style type="text/css">
:-ms-input-placeholder {font-family: sans-serif;}
input[type="search"] {width: 90%;}
.site-header-main {
-webkit-align-items:flex-start; -ms-flex-align:flex-start; align-items:flex-start;
display: -webkit-flex; display: -ms-flexbox; display: flex;
-webkit-flex-wrap: wrap; -ms-flex-wrap: wrap; flex-wrap: wrap;
-webkit-justify-content:space-between; justify-content:space-between; -ms-flex-pack:space-between;
}
div, h1, form {border:1px solid red;}/*視認しやすくするため*/
</style>
</head>
<body>
<header>
<div class="site-header-main">
<div class="site-branding">
<h1>タイトル</h1>
<form role="search" method="get" action="hoge.com">
<input type="search" placeholder="検索語…" value="" name="s" />
</form>
</div>
<div class="sidemenu">右寄せメニュー～</div>
</div>
</header></body></html>
589:Name_Not_Found
19/01/15 20:52:07.69 .net
>>587・>>588参考
【HTML】IEで、inputタグの width を指定したにもかかわらず、幅がずれる
URLﾘﾝｸ(blogs.yahoo.co.jp)
IE：入力フィールドのプレースホルダは選択ボックスの幅に影響します
URLﾘﾝｸ(stackoverrun.com)
590:Name_Not_Found
19/01/15 21:40:40.88 .net
>>588追記
:-ms-input-placeholder {font-family: sans-serif;}
総称フォントでは、このsans-serifが一番ひどい。
フォーカス時は検索ボックスの幅が半分位に短くなる。つまり通常時は倍に伸びてしまってる。
monospace にすると、１文字分ほど（約1em）増減する。
serif では逆に、フォーカス時にプレイスホルダーの文字が消えると、検索窓の横幅が長くなる。伸縮率は短く0.5em程。
system-ui は挙動はserif と同じだが初期状態（非フォーカス時）の長さが少し短くなるので、伸縮率は1em位。
以下のグローバル値もsystem-uiと挙動は同じ。伸縮率も同程度に軽少。
font-family: inherit;
font-family: initial;
font-family: unset;
ちなみにIEの設定はデフォルトのまま、ツール＞インターネット オプション＞全般＞フォントで
Webページ フォントが「MS PGothic」、テキスト形式フォントが「MS ゴシック」。
591:Name_Not_Found
19/01/16 02:13:34.85 .net
>>588
誤 <title>IE11検索窓プレースホルダー・バグ検証</tutle>
正 <title>IE11検索窓プレースホルダー・バグ検証</title>
それと、div.site-brandingの中で問題のinput要素の上にある要素（この場合、h1要素）の幅が長くなると、再現しないみたい。
横幅を計りやすくするため、
h1 {font-size:1em; font-weight:normal;}
<h1>一二三四五六七八九〇一二三四五六七八九〇</h1>
とする。幅20emの定規になる。
この長さを調整すると、h1の幅が18em未満の時にバグが出る。
以上はIEで 表示＞文字のサイズ＞中 にして確認した。
文字のサイズ小だと、親ボックスのwidthを決める要素（ここではh1要素）の横幅の長さが21em以上ある場合バグは起きない。
また、h1は短い文字数のままにしておいて、
input[type="search"] {width: 90%;}
に min-width:21em; を追記すると、検索入力欄の伸縮は起きなくなった。
min-widthの数値を20.6em未満にすると、バグは起きる。
>>587のバグの発生条件には、これも足すべきだった。
592:Name_Not_Found
19/01/16 03:27:21.38 .net
>>583
IE11のバグまとめ
特定のフォントでテキストの下に隙間が空く。
URLﾘﾝｸ(qiita.com)
「バグの現象としては、行間が膨れ上がった上にテキストの下に隙間ができるため、font-sizeが大きいほど顕著にズレが生じる。」
>>584
「Noto Sansを利用する場合はCJK jpをダウンロードして利用せずに、Noto Sans jp, Noto Sans JapaneseなどGoogle fonts経由で利用する場合は問題ないみたいです。」
593:Name_Not_Found
19/01/16 15:40:27.59 .net
>>587・>>588
バグの発生条件に下記は関係無かった。
>条件１
>・検索ボックスが、display: flex;（IEだとdisplay: -ms-flexbox;）を指定した祖先要素内にあり、フレックス・ボックスを継承。
>条件２
>・検索ボックスのinput要素にwidthを%単位でスタイル指定してある。
もっと単純に、placeholder属性へのfont-family指定だけで、検索入力欄の横幅が変に伸び縮みする。
要は、input要素とplaceholder属性とでfont-familyが異なると、バグる。
<style type="text/css">
:-ms-input-placeholder {
font-family: sans-serif;/*任意のフォントで試す*/
}
</style>
<body>
<input type="text" size="22" name="word" value="" placeholder="プレースホルダーです">
</body>
「プレースホルダーです」が10文字あり、size="20"で入力欄が10文字分の横幅に表示される。
これも>>591にある通りmin-width指定でフォーカス時の横幅の変化を防げる。
input[type="text"] {min-width: 21em;}
input要素でsize="30"と10増やすと、最小幅指定もmin-width: 31em;にしないとバグ抑止できなくなる。
size=""と空指定にした場合は、min-width: 21em;以上でバグは起きなくなった。
どのみち、指定されたフォント名次第でこの数値は上下するみたいで、不安定。
上記ソースではfont-family: system-ui;にするとバグは発生しないが、既にinput要素へのfont-family指定があると別。
プレースホルダーに対するfont-family指定自体を削除したい所だが、WordPressテーマ（twentysixteenとか）のstyle.cssでプレースホルダーへのスタイル指定がある場合等は難しい。
スタイル指定でwidthを決め打ちするのが良いかも。この場合、%指定でも可（flexを継承してないからか）。
594:Name_Not_Found
19/01/17 03:12:34.66 .net
>>593
font-family: system-ui;は、IE未対応らしい。
URLﾘﾝｸ(developer.mozilla.org)
で、プレースホルダーのフォント名が親要素であるinput要素と不一致なのがいけないんだから、
:-ms-input-placeholder {font-family: inherit;}
がバグ対処法になる。祖先要素からの継承を明示するわけ。
WordPressの場合はこれを子テーマのcssファイルで上書きすれば良し。
これで、入力フォームにカーソル入れると横幅が伸び縮みする不条理は避けられるはず。
595:Name_Not_Found
19/01/22 02:38:40.50 .net
>>583
>しかも、三点リーダー「…」なんかは欧文式にベースライン表示の「...」になる罠。
「三点リーダが真ん中に表示されない理由」
URLﾘﾝｸ(www.koikikukan.com)
「三点リーダ問題、webfontでついに解決！……か？」
URLﾘﾝｸ(orangeprose.)<)
「「三点リーダの表示位置」問題を完全かつ最終的に解決する」
URLﾘﾝｸ(d.nekoruri.jp)
U+2026の「…」ではなく、(U+22EF)の「⋯」を使うだけで真ん中に表示される日本人の大好きな三点リーダになります。
596:Name_Not_Found
19/01/22 19:34:51.02 .net
【IE・Firefoxバグ】InternetExplorer11、Firefox64、GoogleChrome71、をWindows8.1で確認。
font-familyプロパティが、@font-face内だと通常と違って和文フォントを英字名しか読み込まず日本語名を受けつけなくなる。
また特にFirefoxではファミリー名にウェイトを附けると認識しないことがある（>>585の逆）。フォント・ファイル名なら末尾に‘-weight名’が入っても可みたいだけど、それではChromeで反映しなくなる。
バグではなく仕様にしても、ブラウザ間の不一致がひどすぎて、使用するのに困惑する。
OS標準インストールの和文フォント名一覧とも微妙に齟齬する。
URLﾘﾝｸ(w3g.jp)
Webフォントでなくローカル・フォントに對して@font-face内font-familyでフォント・ファミリー名を上書きして複数まとめたりする手法（下記等）が、無為になる。
URLﾘﾝｸ(text.baldanders.info)
URLﾘﾝｸ(qiita.com)
URLﾘﾝｸ(qiita.com)
テストしたソースは以下。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<style type="text/css">
div {font-family: Tahoma, sans-serif; font-size:1.5rem;/*視認しやすくするため*/}
@font-face {font-family: "f01"; src: local("ＭＳ 明朝");}
.f01 {font-family:"f01";}
</style>
</head>
<body>
<div class="f01">永なふをQ9g桜咲く</div>
</body>
</html
上記"ＭＳ 明朝"の箇所に明朝体の日本語フォントを日本語名／英語名で代入して、日本語の表示がsans-serif（ゴシック体）でなくなるかを確かめた。
結果一覧は>>597
597:Name_Not_Found
19/01/22 19:35:40.93 .net
>>596のテスト結果
"ＭＳ 明朝" IE× FF× GC○
"MS Mincho" IE○ FF○ GC○
"游明朝" IE× FF× GC○
"Yu Mincho Regular" IE× FF○ GC×
"YuMincho-Regular" IE○ FF○ GC×
"Yu Mincho" IE○ FF× GC○
"YuMincho" IE× FF× GC×
"ヒラギノ明朝 ProN" IE× FF× GC○
"ヒラギノ明朝 ProN W3" IE× FF× GC×
"Hiragino Mincho ProN" IE× FF× GC○
"Hiragino Mincho ProN W3" IE○ FF× GC×
"HiraMinProN" IE× FF× GC×
"HiraMinProN-W3" IE○ FF○ GC×
"小塚明朝 Pr6N R" IE× FF× GC×
"小塚明朝 Pr6N" IE× FF× GC○
"Kozuka Mincho Pr6N" IE× FF× GC○
"Kozuka Mincho Pr6N R" IE○ FF× GC×
"KozMinPr6N-Regular" IE○ FF○ GC×
"KozMinPr6N" IEC× FFC× GC×
"Noto Serif CJK JP" IE○ FF○ GC○
"NotoSerifCJKjp-Regular" IE○ FF○ GC×
"NotoSerifCJKjp Regular" IE× FF× GC×
"Noto SerifCJK jp Regular" IE× FF× GC×
"源ノ明朝" IE× FF× GC○
"Source Han Serif" IE○ FF○ GC○
"SourceHanSerif-Regular" IE○ FF○ GC×
"IPAmj明朝" IE× FF× GC○
"IPAmjMincho" IE○ FF○ GC○
"IPAex明朝" IE× FF× GC○
"IPAexMincho" IE○ FF○ GC○
×印はフォント指定が表示に反映されなかったが、にも拘らず妙なことに、半角英数字の文字列だけはIEもFirefoxもTahomaでない別のフォントになった。しかもなぜかIEは総称フォントsans-serif指定を無視してserifの英数字になる。
598:Name_Not_Found
19/01/22 20:51:50.61 .net
>>596
URLﾘﾝｸ(www.tomotanuki.com)
「指定するフォント名は現段階ではブラウザによってまちまちです。
ChromeとOperaは「游ゴシック」「Yu Gothic」でも標準（Regular）を指定できたりします。
ですが、Firefoxでは「Yu Gothic Medium」と英語名+ウェイトで指定しなければなりません。
これは標準（Regular）でも同じで標準（Regular）サイズをFirefoxで指定したい場合は「Yu Gothic」ではなく「Yu Gothic Regular」と指定しなければ表示されません
(ちなみに「Yu Gothic Regular」で設定すると、ChromeとOperaとIE11では表示されません)。」
「Chromeの現バージョン ( 58.0.3029.110 (64-bit) ) で英語フォント名（Yu Gothic Medium）を認識しないようです。」
Hiragino Sansフォントウェイトのcss書き方まとめ
599:Name_Not_Found
19/01/22 20:53:37.04 .net
>>598
Hiragino Sansフォントウェイトのcss書き方まとめ
URLﾘﾝｸ(joppot.info)
URLﾘﾝｸ(hiragino.joppot.info)
600:Name_Not_Found
19/01/22 21:20:46.74 .net
>>596・>>597
>"Yu Mincho Regular" IE× FF○ GC×
>"YuMincho-Regular" IE○ FF○ GC×
>"Yu Mincho" IE○ FF× GC○
ChromeはPostScript Nameを認識できないので、Font Family Nameで指定しなければならない。
URLﾘﾝｸ(w3g.jp)
URLﾘﾝｸ(speakerdeck.com)
601:Name_Not_Found
19/01/22 22:08:14.28 .net
>>600
しかし"ＭＳ 明朝"のPostScript名は"MS-Mincho"らしいが、
Cf.「フォントのPostScript名, フルネーム, ファミリーの日本語名と英語名」URLﾘﾝｸ(taken.jp)
@font-face {font-family: "f01"; src: local("MS-Mincho");}
と指定しても、IE・Firefox・GoogleChromeどれも表示に反映されない。
602:Name_Not_Found
19/01/23 11:38:54.62 .net
>>601は誤り。"MS-Mincho"でIE・Firefoxに有効だった。
>>597
>"Noto Serif CJK JP" IE○ FF○ GC○
>"NotoSerifCJKjp-Regular" IE○ FF○ GC×
これがRegularでない他のウェイトだと、IEのみが認識するイレギュラーな結果になる。
"Noto Serif CJK JP Bold" IE○ FF× GC×
"NotoSerifCJKjp-Bold" IE○ FF× GC×
同じ形式で下記ではどのブラウザも読み込まないのに。
"Noto Serif CJK JP Regular" IE× FF× GC×
ダウンロード URLﾘﾝｸ(www.google.com)
Cf. URLﾘﾝｸ(qiita.com)
Google Fontsの'Noto Serif JP'も同様かね？
URLﾘﾝｸ(fonts.google.com)
603:Name_Not_Found
19/01/23 14:03:18.00 .net
>>596・>>597を整理して纏め直すと―
@face-fontのsrc記述子でlocal()構文を指定する場合
・使用可能なフォント名は、英文名のみ。
フォントの日本語名はIE・Firefox無効、Google Chromeしか認識しない。
・PostScript名はChrome不可、全く効かない。
・名にウェイトが含まれると、PostScript NameであれFull Nameであれ、Chrome不可。
Full NameはIEだとフォントのウェイト（Regular等）によっては不可。
Full NameはFirefoxだとフォント（ヒラギノ・小塚・Noto Serif CJK JP等）によっては駄目。
・ウェイトの含まれない英語フォント・ファミリー名だけにすると、Chromeに有効。
だがIE・FFで読み込まれないフォントもある（ヒラギノや小塚フォント等。游フォントはFFのみ不可）。
対策としては―
src: local("PostScript名"), /*IE・Firefox適用、Chrome無効*/
local("Weight抜きのFont Family名")/*Chrome向け*/;
としておくしかないか。
EdgeやMacやスマホは確認できないので、できる人よろしく。
604:Name_Not_Found
19/01/28 03:11:07.93 .net
バグではなく未対応だかららしいけど、混乱するので。
font-feature-settingsプロパティーは、ほぼ全てのブラウザが対応する。
URLﾘﾝｸ(caniuse.com)
URLﾘﾝｸ(developer.mozilla.org)
しかし。
font-feature-settingsを@font-face { }内で使用すると、Firefoxでしか有効でない罠。
URLﾘﾝｸ(developer.mozilla.org)
605:Name_Not_Found
19/01/29 11:53:41.59 .net
他のブラウザでは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. URLﾘﾝｸ(helpx.adobe.com)
606:Name_Not_Found
19/01/29 13:02:19.34 .net
>>605
游明朝のカーニング設定がうまくいかない話
URLﾘﾝｸ(qiita.com)
Mac (10.12.6)
■ Chrome(64)、Safari(11)、Firefox(58)
Boldとpknaを組み合わせると、カーニングが無効。
Windows(10)
■ IE11
Boldとpaltを組み合わせると、カーニングが無効。
Normalとpaltを組み合わせると、カーニングが無効。
URLﾘﾝｸ(bulan.co)
Mac OS SierraのChromeで游明朝体の文字詰めが効かなかったり
607:Name_Not_Found
19/01/29 13:10:52.41 .net
>>604
ここ↓、その@face-font内font-feature-settingsで嵌ってた。
「CSSで行頭の約物を半角にする」
URLﾘﾝｸ(dskd.jp)
608:Name_Not_Found
19/02/04 17:06:35.30 .net
【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. URLﾘﾝｸ(pentan.info)
609:Name_Not_Found
19/02/04 17:09:42.04 .net
>>608
× 「&;#x4E13;」 &の後の「;」が不要。
○ 「专」
610:Name_Not_Found
19/02/10 18:52:31.49 .net
>>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（ゴシック体）のまま。
611:Name_Not_Found
19/02/15 18:30:21.46 .net
>>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で反映しなかったのは、フォントキャッシュとかの問題では？
612:Name_Not_Found
19/02/20 18:38:10.24 .net
>>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"だけ有効だった。
613:Name_Not_Found
19/04/19 18:42:32.78 .net
>>551-553のwhite-space:nowrap;バグ、最新のChrome73になってもまだ直ってないのな。
WebKitのバグってどこに報告すれば修正してくれんのかね？
614:Name_Not_Found
19/06/10 21:00:12.09 .net
>>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>
とインライン要素タグで括って中に半角英数や記号以外の日本語文字を入れると、直る。
615:Name_Not_Found
19/06/11 03:14:20.67 .net
>>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のバグまとめ > 特定のフォントでテキストの下に隙間が空く。
URLﾘﾝｸ(qiita.com)
「line-heightを限りなく0に近い数値にすることでズレを回避できますが、改行した瞬間に文字が重なって終わるので現実的な解決策ではありません。」
↑これも、line-height:1%;とかやっても利き目なかったけど、font-family先頭の欧文フォント指定と掛け合せた上で２バイト文字列のどれかを<span> </span>で挟めば、行高設定次第でずれ解消が有効になるはず。
616:Name_Not_Found
19/06/11 03:50:16.31 .net
>>560 - >>565
Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。
↑これ、全く再現しないね。
font-family:Arial, 'MS Mincho';
とか
font-family:Arial, 'Yu Mincho';
とかで試したけど、ちゃんと日本語の部分は日本語フォントで描画される。
総称ファミリー名のserifを末尾に指定するかどうかも関係無し。
なんか、間違ったのか？
617:Name_Not_Found
19/06/15 08:07:04.60 .net
これはCSSのバグなのかどうか……。
InternetExplorer11／Windows8.1で確認。
・フォント・サイズをその要素の横幅以上に拡大すると、IVS（＝基底文字＋VS）のVSが文字化けする。
IVS（異体字シークエンス）は、「通常の文字と同様、数値文字参照を使って書くこともできる。フォントやOS、アプリケーションが対応していない場合には、通常の基底文字のグリフが単に表示される（ことが望まれるが、VSが豆腐などで表示されてしまうことが多い）。」
URLﾘﾝｸ(shiromoji.hatenablog.jp)
ところが、別に「・」や「□」（豆腐）に化けてなかった文字も、フォント・サイズを一定以上に大きくすると四角になることがある。
下記一行のソースで再現できた。
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
どうもIE11はIVSを「基底文字＋VS」で２文字と計算するらしく、
それで要素の横幅がフォント・サイズ１文字分（1em）より小さいと、１文字はみ出たVSの分だけ文字化けして表示され、基底文字の下に流れて配置される。
width指定で要素の幅がfont-sizeより広く取ってあっても、box-sizing: content-box;（既定）の場合にpaddingとかborderを入れると、この不具合が発現したりする。
floatでwidtj指定を入れる場合にも、注意↓。
実例 URLﾘﾝｸ(wakufactory.jp)
Firefox67やChrome75では再現しなかった。
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。
618:Name_Not_Found
19/06/15 08:10:00.98 .net
>>617 追記修正
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、他方、Chromeでは、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。
619:Name_Not_Found
19/06/22 07:25:22.77 .net
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'プロパティ
URLﾘﾝｸ(momdo.github.io)
ならば厳密にはスタイルシートのバグではなくてブラウザーごとの仕様なのか？
あと、「馬酔木明朝」は下記で無料配布。
URLﾘﾝｸ(metasta.github.io)
620:Name_Not_Found
19/06/22 08:24:16.07 .net
>>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は、値の不正な記述の仕方（「不正な値」の指定ではない）でもプロパティーそのものは無効にならない点では、バグである。
621:Name_Not_Found
19/06/22 08:32:00.85 .net
>>620修正
＞body {'MS PMincho'}
body {font-family: 'MS PMincho';}
622:Name_Not_Found
22/12/16 23:35:39.75 .net
>>551
>>551-553 報告のChrome30でのCSSバグは
マイナー極まるブラウザ、Falkon Version 3.1.0 でも再現する。
hrURLﾘﾝｸ(falkon.org)<)
とすると、iPhoneではSafari以外のブラウザでもWebKit特有の問題が発生するのかも。
623:Name_Not_Found
22/12/17 00:16:31.58 .net
>>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にも効いてしまった！ バグが再生。 */
624:Name_Not_Found
22/12/18 16:26:42.99 .net
>>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）でも適用されるものの、指定しない時と比べて特に変化は起きない模様。
625:Name_Not_Found
22/12/18 18:17:57.17 EoAW88W9.net
>>622
CSSではないけど、そもそもFalkonは行中での折返し（改行）をするアルゴリズムが何かヘン。
非表示のゼロ幅スペース（​ U+200B）を挟んでも、そこで折り返してくれない。
HTMLソースで改行してあると、そこがブラウザ表示でも改行できる位置になる。
ちなみにゼロ幅スペースを入れた直後にソースで改行すると、
ChromeやFirefoxと違ってFalkonの表示ではドット一箇分ほどの幅の隙間が空く。ゼロ幅にならない！
<wbr>タグには対応してるから、そっちを使用すればいいのかもしれんが。
626:Name_Not_Found
22/12/18 18:35:49.47 .net
>>626
↓こんなソースで比較してみると。
<h1><a href="">■</a>大見出し１</h1>
<h1><a href="">■</a>
大見出し２</h1>
<h1><a href="">■</a>​
大見出し３</h1>
Chrome108/Firefox108での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■大見出し３ ←前行末にゼロ幅スペースがあるとソース改行による空白が打ち消される。
Falkon3.1.0での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■ 大見出し３ ←前行末にゼロ幅スペースがあってもソース改行による空白が打ち消されない。
627:Name_Not_Found
23/09/20 18:01:30.13 .net
正しいことをやりましょう