CSS/DHTMLバグ辞典スレッド【第５版】

**Name_Not_Found** · 2006/04/08(土) 20:05:59

CSS（とDHTML）のバグ報告、お待ちしてます。
※報告の際はOS・ブラウザ名とそのヴァージョンを明記して下さい。
　再現条件をつきとめるため、必要に応じてソースを出して下さい。

第４版レス314までのバグは下記に登録済み（前々366◆E3CSS.J95U／◆B7TCOttEさんに感謝）。
【CSSバグリスト＠CSSバグ辞典スレッド】　
http://cssbug.at.infoseek.co.jp/index.html
　（もうずっと更新休止、誰かwikiででも引き継がないか？）

　プロパティ別にバグを調べたいときは――
・K@tsukun's PAGE! ＞ CSS対応状況表（の各プロパティ「関連バグ情報」）
　http://hp.vector.co.jp/authors/VA022006/css/corrbrwser.html
・CSSプロパティ別トラブルの索引
　http://dhr.at.infoseek.co.jp/stylebug_index1.htm

【バグ説明・回避法などを載せた参考サイトへのリンク】
　http://cssbug.at.infoseek.co.jp/link.html
【過去ログ】
　1 http://mentai.2ch.net/hp/kako/987/987003410.html
　2 http://pc2.2ch.net/hp/kako/991/991666454.html
　3 http://2ch-library.com/hp/1050844510.html
　4 http://pc8.2ch.net/test/read.cgi/hp/1078463560/l50
【関聯スレッド】
・/* CSS・スタイルシート質問スレッド*/
　http://web2ch.s31.xrea.com/?CSSLog
・代替スタイルシートに萌え～
　http://pc8.2ch.net/test/read.cgi/hp/991400015/l50
・独自拡張、草案段階のCSSについて語れ
　http://pc8.2ch.net/test/read.cgi/hp/1019912046/l50

その他あれば、>>2-5あたりで。

**Name_Not_Found** · 2013/10/31(木) 17:27:10.18

Google Chrome30

折り返しを抑制した文字列を含むテーブルが横方向にはみ出すことがある。
例）
nowrapを指定してないA要素以外の文字列で折り返す筈だが……？
navbar1 a:link, .navbar1 a:visited {white-space:nowrap;}
.navbar1, .navbar1 table {width:80%;}
<div class="navbar1">
<table width="100%" border="1"><tr>
<td>
<a href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／<a
href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／<a
href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／<a
href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／<a
href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>
</td>
</tr></table>
</div>

但し、HTMLソースでの改行の仕方を変更すると、nowrapを指定してない文字列でちゃんと折り返す。
<td>
<a href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／
<a href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／
<a href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／
<a href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>／
<a href="./index.html">折り返し抑制折り返し抑制折り返し抑制</a>
</td>

cf. 「テーブルがはみ出しても横スクロールバーが表示されない」
http://pentan.info/stylesheet/bug/mozilla051.html

**551** · 2013/10/31(木) 17:58:13.75

類似現象はむしろこっちか。
「表セル内要素への折り返し禁止指定がセル自体に作用する」
http://pentan.info/stylesheet/bug/opera008.html

あと、折り返し禁止してない文字列「／」を２文字にすると、
ちゃんと折り返して、テーブルが横に伸びる現象を回避できる。

**551** · 2013/10/31(木) 18:22:17.29

これも該当か。
「インライン要素への折り返し禁止指定が当該要素の外のブロックに作用する」
http://pentan.info/stylesheet/bug/mozilla029.html
＞折り返しが行われるべき場所に空白類文字を挿入するとこのバグを回避できます。

何年も前のNetsacape7.0で発生してその後修正されたバグが、今になってChromeに再来するとは……。

**Name_Not_Found** · 2013/11/04(月) 20:26:07.56

IE10／Chrome30／Firefox24／Safari5.1.7／Opera12
リンク疑似クラスで、font-weightプロパティーの上書き指定を反映しない。
A:link {
color:red;
font-weight:900;/* bolderでも可 */
}
A:visited {
color:blue;
font-weight:100 !important;/* lighterかnormalでも可 */
}
<p>未訪問と既訪問済みを比較→
<a href="./001.html">未訪問リンク</a>／
<a href="./index.html">既訪問リンク</a>
</p>

リンク文字列の色は変ったのに、字の太さは太くなったまま変化しない。
font-weightに限っては擬似クラスA:linkでの指定が強くて、A:visitedでは上書きできない罠。
これは全ブラウザで一致するみたいなので、バグでなく仕様なのか？
と思ったが、該当する記述は仕様書に見当らなかった。
http://www.asahi-net.or.jp/~BD9Y-KTU/htmlrel_f/W3Ccss1/index.html#anchor-pseudo-classes
http://momdo.s35.xrea.com/web-html-test/spec/CSS21/selector.html#link-pseudo-classes
http://momdo.s35.xrea.com/web-html-test/spec/CSS21/fonts.html#font-boldness

**Name_Not_Found** · 2013/11/04(月) 20:30:19.86

>>554
>IE10／Chrome30／Firefox24／Safari5.1.7／Opera12
>これは全ブラウザで一致するみたいなので
間違った。
Opera12.16だけは、a:visitedでのfont-weightの上書き指定が有効だった。

**Name_Not_Found** · 2013/11/04(月) 20:31:12.61

それは仕様。

http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#the-link-pseudo-classes-link-and-visited
Note: It is possible for style sheet authors to abuse the :link and :visited pseudo-classes to determine which sites a user has visited without the user's consent.
UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user's privacy while rendering visited and unvisited links differently.

の範囲内の動作。

**Name_Not_Found** · 2013/11/04(月) 21:12:19.47

>>556
邦訳だと、ここだね。
http://standards.mitsue.co.jp/resources/w3c/TR/css3-selectors/#the-link-pseudo-classes-link-and-visited
Note: スタイルシート製作者は :link, :visited 擬似クラスを悪用し、ユーザーがどのサイトにアクセスしたかをそのユーザーの承諾なしに知ることができる。
このため、UA はすべてのリンクを未訪問として扱う、もしくはそれぞれのリンクを表示する際ユーザーのプライバシーに配慮した方法を実装するなどの方法をとることができる。

でも、それなら、色は変化するのに太さは変化しないって、整合性がないよ。
やっぱちょっと異常な挙動ではある。

**Name_Not_Found** · 2013/11/14(木) 07:15:01.69

Chrome 30.0.1599.101 m ／ Safari5.1.7
>>550のソースで、縦書き段内の横スクロールをした場合。
その文中にA要素があると、a:hoverをセレクタにした指定が効かなくなる。
横スクロールを動かさない初期状態だと、リンク・アンカーにカーソル乗せれば指定通りに背景色等が変化した。
.tategakiへのwidth指定でoverflowが発生するとこのバグが生じる。
普通の横書きでは段落ボックス内でoverflowの縦スクロールを動かしても、問題無し。

**Name_Not_Found** · 2013/11/15(金) 10:14:25.03

>>543
IE11も縦書き指定でルビありだと表示が乱れるとさ。
http://togetter.com/li/562466
http://answers.microsoft.com/ja-jp/ie/forum/ie11_pr-windows8_1_pr/win81preie11/36d8f830-518c-4b0c-a49f-c15662b0b466
http://social.msdn.microsoft.com/Forums/ja-JP/e721ea0a-ff57-45c3-b728-31e2cc7618ad/win81preie11-?forum=internetexplorerja

縦組みに限っては、IE6までが一番マシだったかも。

**Name_Not_Found** · 2013/11/19(火) 22:53:03.13

Windows8.1＋IE11
font-family:"欧文フォント","和文フォント",sans-serif;とすると、和文フォントの指定が無視される。

body {font-family:"Verdana","ＭＳＰゴシック",sans-serif;}
→ＭＳＰゴシックが無視され、sans-serifのメイリオで表示される。
Verdanaを後ろにする（もちろん半角英数はVerdanaでなくなる）か、
sans-serifを取り除くとＭＳＰゴシックが反映される。

**Name_Not_Found** · 2013/11/20(水) 00:19:11.56

>>560
和文フォント名を"MS Gothic"とかアルファベット表記にしたらどうなります？
Cf. http://blog.sakurachiro.com/2012/10/font-family/

**Name_Not_Found** · 2013/11/20(水) 22:30:07.69

Google Chrome 31.0.1650.57m
Safari5.1.7

list-style-image指定時に画像非表示にするとリストマーカーまで消える。

<ul style="list-style-image:url(mark.jpg); list-style-type:square;">
<li>AAA</li>
<li>BBB</li>
</ul>
代替表示されるはずのlist-style-typeプロパティで指定したリストマーカーも表示されない。
IE10やFirefox25では、画像非表示でもリストマーカーは表示された。
仕様書には「画像が利用可能の場合、'list-style-type'で設定したマーカーと置き換える」とある。
http://momdo.s35.xrea.com/web-html-test/spec/CSS21/generate.html#propdef-list-style-image
画像が利用可能でない場合は置換せずにマーカーを表示すべき筈。

Cf.存在しない画像をリストマーカーに指定するとリストマーカーが完全に消える
http://pentan.info/stylesheet/bug/mozilla026.html

**Name_Not_Found** · 2013/11/20(水) 22:43:31.39

>>561
「font-family:"Verdana","ＭＳＰゴシック","MS PGothic",sans-serif;」ではダメだった。
sans-serifを外したり、monospaceに書き換えるとちゃんとＭＳＰゴシックで表示されることから、
「sans-serif」の処理に問題がありそうな感触。

「font-family:"Verdana","MS PGothic",sans-serif;」だとどうなるかは、今度試してみる。

**Name_Not_Found** · 2013/11/20(水) 23:21:50.25

>>563
>monospaceに書き換えるとちゃんとＭＳＰゴシックで表示される

総称ファミリー名をmonospaceと指定した場合、「ＭＳＰゴシック」でなく「ＭＳゴシック」で表示されるべきなのでは？
Pはプロポーショナル・フォントだから、固定幅でない。
Cf. http://momdo.s35.xrea.com/web-html-test/spec/CSS21/fonts.html#monospace-def

**Name_Not_Found** · 2013/11/21(木) 22:27:50.54

>>564
何だかんだ試してみて、以下のことが分かった。>>560を訂正。

Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。

欧文フォントについては適用されるが和文フォントの指定が無視されて、
和文はIEの標準フォント（ツール＞インターネットオプション＞フォントで指定したフォント）で表示される
（>>560のケースは標準フォントもMS PGothicだったから、指定が効いたんだと勘違いしていた）。

ただし欧文フォントの後ろに「sans-serif」と「serif」が指定されると無視されず、
sans-serifはメイリオで、serifは（おそらく）MS P明朝で表示される。
それ以外のmonospaceやfantasyなどについても無視されて、IEの標準フォントで表示される。

**Name_Not_Found** · 2013/11/22(金) 21:09:54.35

【Google Chrome 31】【Sagari5.1.7】
代替スタイルシートによって縦書き指定（-webkit-writing-mode:vertical-rl）を適用すると、リストマーカー画像の位置が左にずれたり消えたりする。

<link rel="stylesheet" type="text/css" href="./default.css" hreflang="ja" charset="Shift_jis" media="screen,print,projection,tv">
<link rel="alternate stylesheet" type="text/css" href="./tate.css" hreflang="ja" charset="Shift_jis" media="print, screen" title="縦書き版">
<body>
<script type="text/javascript">
</script>
<select onchange="sn=this.options[this.selectedIndex].value;if(sn)ChangeStyle(sn);">
<option value="Main">default</option><option value="縦書き版">縦書き版</option>
</select>
<div class="tategaki">
<ul><li>あいうえお</li><li>ああああ</li><li>aaaaa</li></ul>
</div>
</body>

/* default.cssの中身 */
ul {list-style-image:url(./mark.jpg);}
/* tate.cssの中身 */
.tategaki {
-webkit-writing-mode:vertical-rl;/* Chrome用 */
writing-mode:vertical-rl;
writing-mode:tb-rl;/*For under IE8*/
}

tate.cssを読み込むlink要素でrel="alternate stylesheet"をrel="stylesheet"にして
最初から縦書きを適用すると、この不具合は起きない。
なぜか代替スタイルシートで適用した直後だけ、リストマーカー画像が左に半行分以上ズレて、本来上に来るべき行より左の行の上に掛かって表示される。
>>562もだが、Webkit系のlist-style-imageのレンダリングはちょっと問題含みか。

**Name_Not_Found** · 2013/11/22(金) 21:28:11.99

>>566の問題を下記で代用して解決できる。

tate.cssに下記を追記し、list-style-imageでなくbackground-imageでリストマーカーを画像にする。

/*===WebKitハックでGoogleChrome（とSafari）のみに適用===*/
@media screen and (-webkit-min-device-pixel-ratio:0){
.tategaki ul {-webkit-padding-start:20px;}
.tategaki ul li {
list-style:none;
padding-top:20px;
background: url(./mark.jpg) no-repeat right top;
}
}/**Safari・Chrome対策**/

<ul>
<li>さしすせそ
<ul>
<li>たちつて</li>
<li>なにぬねの</li>
</ul>
</li>
<li>ＡＢＣＤＥ</li>
<li>あいうえお<br>ああああ<br>aaaaa</li>
</ul>

ところが、これでもGoogle Chrome（とSafari）で別の不具合が生じた。
代替スタイルシート適用直後、リスト一行目のリストマーカー画像が消えたり、右半分欠けたりする。
そこでdefaultスタイルに戻してから再度代替シートに切換すると、まともに表示される。
しかしページ再読み込みして、また代替スタイルシートで縦書きを適用すると、やはり一行目のliの背景画像だけ消える。
なにこれ？

**Name_Not_Found** · 2013/11/22(金) 22:15:59.31

>>544の解決法。→　body {height:100%} を指定しておく。
しかし、WinIE7標準モードで発生する別のバグにはそれだけでは不足。
>>544のソースのDOCTYPE宣言を変更して標準モードにし、IE7で閲覧する。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";>
<html lang="ja"><head>
<meta http-equiv="X-UA-Compatible" content="IE=7;IE=emulateIE7">
またはIE8～10でF12開発者ツールを使ってドキュメントモードをIE7標準にして閲覧する。
ソースは下記の通り。互換モードやIE8標準～IE10標準だとこのバグは起きない。
.tategaki {
writing-mode:vertical-rl;
writing-mode:tb-rl; /*For under IE8*/
-webkit-writing-mode:vertical-rl;
overflow-x:auto;
height:50%;
width:95%;
}
<body>
<div class="tategaki" id="COL1">
<p>ここに一段目の縦書きのテキストが入ります。</p>
<p>折り返される長文にする。長文にする。長文にする。長文にする。長文にする。長文にする。長文にする。長文にする。</p>
<p>以下繰り返しで横スクロールが生じる幅を出す。</p>
<p>以下繰り返しで横スクロールが生じる幅を出す。</p>
<p>……横スクロールが出るまでコピー＆ペースト繰り返し……</p>
</div>
<div class="tategaki" id="COL2">
<p>ここは二段目になります。</p>
</div>
すると、なぜか横スクロールが発生した分だけ長文が折り返されなくなるバグが発現した。したがって縦組み段の高さがどんどん伸びる。
これへの対処法としては、body {height:100%} だけでは足りない。
body, html {height:100%;} とhtml要素にも指定すると、バグは解消した。

**Name_Not_Found** · 2013/11/23(土) 11:52:59.97

>>550のSafari5.1.7の縦書きでのバグについて。
Safariブラウザのウィンドウを垂直に伸ばすと縦書きボックスの横幅も増えてゆく。
つまり>>544のIEバグと似て、縦の高さ（height）がなぜか横幅の長さにまで影響するバグだった。
そこで>>568の解決法を試して、body, html {height:100%;} としてみた。
すると>>550後半のStrictモード時に縦書きの各段毎の横スクロールが出なくなる不具合だけは解消した。
しかし依然としてbody内の縦書きボックスのwidthが画面表示領域の高さと連動するバグは出る。
Safari6以降では修正されたのかな。

**Name_Not_Found** · 2013/11/24(日) 02:54:41.24

【IE5Quirks／IE7～9互換モード】
定義リスト（dl要素）を横並びさせる際、dd要素内でem要素が折り返される長さだけあると横に並ばなくなる。
定義リストをfloatで横並びにして表組み風にするのは、よくある。
Cf. http://blog.d-spica.com/entry/080512dtfloat.html
その際、IE6において、dt要素の高さよりdd要素内の段が高い場合、dtの横に隣接するddの一行目テキストだけ3pxほど右にずれるバグがある。
これに対処するには、zoom:1; を指定してhasLayoutをtrueにすれば解消する。
Cf. http://www.coolwebwindow.com/weblife_column/coolweb/000174.php
しかし、或る条件下では、この横並びが崩れた。
dd要素内にemなど斜体（font-style:italic;）で表示される要素があり、且つその文字列が途中で行の右端に掛かって折り返しされるのがその条件。
下記の例で、横並びにならなくなって、ddがdtの一行下から表示された。
dt {clear:both; float:left; min-width:1em;}
dd {margin-left:1.2em; zoom:1;}
<dl>
<dt><a name="n25" href="#t25">註2</a></dt>
<dd><p>……著者名，<em>折り返される長さの書名</em>，出版社，刊年，pp29-31.</p></dd>
</dl>

zoom:1;を削るか、em {font-style:normal} とすると、floatが効いて横並びに戻った。

**Name_Not_Found** · 2013/11/25(月) 09:37:02.67

>>570
関連
「フロートの左右にある行の端がずれる」
http://pentan.info/stylesheet/bug/winie151.html

**Name_Not_Found** · 2013/11/28(木) 01:53:22.39

よくremを使ったフォントサイズ指定で

html { font-size: 62.5%; }
body { font-size: 1.4rem; }

なんていうのがブログ等で紹介されているけど、
現状バージョンのChromeでフォントサイズの継承かおかしいのか
変更になったのかわからんがフォントサイズがおかしくなってしまう。

ttp://stackoverflow.com/questions/20099844/chrome-not-respecting-rem-font-size-on-body-tag

**Name_Not_Found** · 2013/12/06(金) 16:08:46.35

Safariでテーブルにダッシュのボーダーの要素thやtdに幅いれると隙間あくのバグかな

**Name_Not_Found** · 2013/12/24(火) 15:00:14.92

とりあえずこのスレでいいのかな…ちょっとコレ見て欲しい。
(1<<32)-1は0になるので(1<<30)*4-1で読み替えてもらうとして、
環境によっては49.7日問題が出ない代わりに上限が0x7fffFFFFミリ秒までになる。
0x7fffFFFFミリ秒あれば普通は十分だろうけど、32ビットフルで使えないのはバグな気もする。

JavaScript 3
http://toro.2ch.net/test/read.cgi/tech/1380177260/124
124 名前：デフォルトの名無しさん[sage] 投稿日：2013/12/22(日) 03:38:15.71
ググっても
http://ap.atmarkit.co.jp/bbs/core/fjava/20589
http://ap.atmarkit.co.jp/bbs/core/fdotnet/20546
しか話が出てこないけどさ、JScriptのsetTimeoutって普通に49.7日問題発生するよな？
多分、timeout+starttime<GetTickCount()的な判定なんだと思うけど、
setTimeout("alert(0);",(1<<32)-1);とかだと普通に0秒でタイムアウトしてしまう。

応用すれば対象PCの起動からの時間も49.7日以下なら計測可能という。
例：http://jsbin.com/aBegAMI/2
WindowsXP SP3(32bit)+IE8はコレでシステム起動時間もどきを取れるの確認したけど、他だとどーよ？

**Name_Not_Found** · 2013/12/30(月) 05:09:11.98

WinXP・IE7
縦書きwriting-mode:tb-rl;適用時、font-familyで和文OpenTypeFontを指定すると、字間ピッチが変に詰まる。

**Name_Not_Found** · 2015/03/17(火) 10:24:59.26

ブラウザーモードIE10
ドキュメントモード IE8標準・IE9標準・Quirks・標準
<ul>
<li><del><p>リスト１</p></del></li>
<li><ins><p>リスト２</p></ins></li>
</ul>

・リスト１
・リスト２

となるべきが、
・
　リスト１
・
　リスト２
となる。
IE5Quirksでは不具合は生じなかった。Firefox36やGoogle Chromeでも問題無し。
IEだけのバグ。
また、下記のソースにすると、ズレは起きない。
<li><p><del>リスト３</del></p></li>
<li><del>リスト４</del></li>

**Name_Not_Found** · 2015/08/10(月) 00:43:26.38

アゲ

**Name_Not_Found** · 2015/11/08(日) 20:27:40.40

ぬるぽ

**Name_Not_Found** · 2016/05/06(金) 13:40:02.20

ガッ

**Name_Not_Found** · 2017/12/12(火) 04:21:02.29

ホームページで友達が稼げるようになった情報とか

⇒　http://asaswq3wq.sblo.jp/article/181819223.html

興味がある人だけ見てください。

TU3YZB5BIW

**Name_Not_Found** · 2018/02/18(日) 20:19:11.30

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**Name_Not_Found** · 2018/05/01(火) 21:55:26.87

誰でもできる在宅ワーク儲かる方法
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい鎌野介メソッド』

AFLZE

**Name_Not_Found** · 2018/12/30(日) 10:46:45.78

久し振りにHTML・CSSをいぢってるんだが、いまだIE11がバグで足引っ張るんだなあ。
フォント指定でヒラギノや游明朝・ゴシックや小塚明朝・ゴシックにするだけで文字の位置が上にズレ。
h1 {font-family: KozMinPr6N-Regular, '小塚明朝 Pr6N R', serif;}
下に続く要素との間にヘンな余白が空く。
ＩＥ11は先日マイナー・バージョンアップしたけど直ってない。
何なのこれ。
先頭に欧文フォント指定すればバグ回避できるけど、半角英数字は当然欧文フォントで表示され不統一に。
h1 {font-family: "Times New Roman", KozMinPr6N-Regular, '小塚明朝 Pr6N R', serif;}
しかも、三点リーダー「…」なんかは欧文式にベースライン表示の「...」になる罠。

CSSでfont-familyに小塚ゴシックを使うときに注意すること
https://www.emuramemo.com/entry/2015/03/31/194850
IEで「游ゴシック／游明朝」を表示させると、文字の下側に由来不明の余白が生じる
https://answers.microsoft.com/ja-jp/ie/forum/ie11-iewindows8_1/ie%E3%81%A7%E6%B8%B8%E3%82%B4%E3%82%B7%E3%83%83/b2572d25-4877-40ce-b46d-237d52d47d37
游明朝体・游ゴシック体の使用は注意しなくてはならない・・・　やってくれるねIE先輩！
https://qiita.com/hrdaya/items/0f5985794e2a2b451ac0
【CSS】游明朝・游ゴシックがIEでずれる
https://norando.net/yumin-ie/
游を font-family で指定した時に IE で生じる謎余白対策
https://thk.kanzae.net/net/itc/t4898/

**Name_Not_Found** · 2019/01/08(火) 21:21:58.82

>>583
源ノ明朝・源ノ角ゴシックを指定したら、逆に下に寄った。
h1 {font-family: 'Noto Serif CJK JP';}
総じて、IEはオープンタイプ・フォント（.otf）への対応が変なのでは。
ディセンダー（ベースラインより下に出た部分）を設定するディセント値WinDescenderの問題かも。

**Name_Not_Found** · 2019/01/09(水) 01:39:17.45

>>583
>h1 {font-family: KozMinPr6N-Regular, '小塚明朝 Pr6N R', serif;}
正しくは、
h1 {font-family: 'Kozuka Mincho Pr6N','小塚明朝 Pr6N', serif;}
　参考：https://taken.jp/font-family-name-english-japanese.html
でないと、IE以外のFirefoxなんかにはフォント指定が反映しない。
しかしこれがヒラギノだと、
　font-family: "ヒラギノ明朝 ProN W6","HiraMinProN-W6";
みたいに、ウェイトまでfont-family指定に入れられるんだけど。

**Name_Not_Found** · 2019/01/09(水) 14:08:54.60

https://blogs.yahoo.co.jp/inabata_001/15580820.html

**Name_Not_Found** · 2019/01/15(火) 20:33:49.93

IE10, IE11ではフォーカス時にplaceholderの表示が消えますが、Chrome、 Firefox、Safari などでは、文字を入力するまで表示され続けます。
https://qiita.com/myzkyy/items/54c19077f95f0fc1a19a

ここから派生したバグ。
条件１
・検索ボックスが、display: flex;（IEだとdisplay: -ms-flexbox;）を指定した祖先要素内にあり、フレックス・ボックスを継承。
条件２
・検索ボックスのinput要素にwidthを%単位でスタイル指定してある。
条件３
・placeholder属性が空でなく、且つプレースホルダーにfont-familyを指定してあった場合。
以上の三条件を満たす時――
フォーカス時にプレースホルダーの文字列が消えると、検索ボックスの横幅まで縮む。
逆に言ったら、通常時（非フォーカス時）は他のブラウザと違ってIE11だけ検索窓の幅が伸びてしまって、
ブラウザーのウィンドウ幅によっては続くフレックス・ボックスが折り返されたりする罠。
幅が長くなったり短くなったりする伸縮率は、プレースホルダーの文字数の長さには関係無いみたい。
widthの%指定は、width: calc(100% - 43px);とかでも駄目。width: calc(20em - 43px);なら可。

↓これは関連するか？
スマホでinputにwidth: 100％;とplaceholderを指定した時に、端末を横向きから縦向きに変更すると画面幅がおかしくなる
http://cly7796.net/wp/smartphone/if-you-change-the-direction-by-specifying-width-100-and-placeholder-for-input-a-problem-will-occur/

再現ソースは>>588

**Name_Not_Found** · 2019/01/15(火) 20:36:41.71

>>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>

**Name_Not_Found** · 2019/01/15(火) 20:52:07.69

>>587・>>588参考
【HTML】IEで、inputタグの width を指定したにもかかわらず、幅がずれる
https://blogs.yahoo.co.jp/dk521123/34679595.html

IE：入力フィールドのプレースホルダは選択ボックスの幅に影響します
https://stackoverrun.com/ja/q/11271481

**Name_Not_Found** · 2019/01/15(火) 21:40:40.88

>>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 ゴシック」。

**Name_Not_Found** · 2019/01/16(水) 02:13:34.85

>>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のバグの発生条件には、これも足すべきだった。

**Name_Not_Found** · 2019/01/16(水) 03:27:21.38

>>583
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
「バグの現象としては、行間が膨れ上がった上にテキストの下に隙間ができるため、font-sizeが大きいほど顕著にズレが生じる。」
>>584
「Noto Sansを利用する場合はCJK jpをダウンロードして利用せずに、Noto Sans jp, Noto Sans JapaneseなどGoogle fonts経由で利用する場合は問題ないみたいです。」

**Name_Not_Found** · 2019/01/16(水) 15:40:27.59

>>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を継承してないからか）。

**Name_Not_Found** · 2019/01/17(木) 03:12:34.66

>>593
font-family: system-ui;は、IE未対応らしい。
　https://developer.mozilla.org/ja/docs/Web/CSS/font-family#Browser_compatibility
で、プレースホルダーのフォント名が親要素であるinput要素と不一致なのがいけないんだから、
:-ms-input-placeholder {font-family: inherit;}
がバグ対処法になる。祖先要素からの継承を明示するわけ。
WordPressの場合はこれを子テーマのcssファイルで上書きすれば良し。
これで、入力フォームにカーソル入れると横幅が伸び縮みする不条理は避けられるはず。

**Name_Not_Found** · 2019/01/22(火) 02:38:40.50

>>583
>しかも、三点リーダー「…」なんかは欧文式にベースライン表示の「...」になる罠。
「三点リーダが真ん中に表示されない理由」
　http://www.koikikukan.com/archives/2013/02/27-012345.php
「三点リーダ問題、webfontでついに解決！……か？」
　http://orangeprose.ｂloｇ.fc2.ｃoｍ/ｂlog-entry-320.html
「三点リーダー(…)を真ん中に表示する方法」
　https://blog.sixapart.jp/2013-03/how-to-get-midline-ellipsis.html
「「三点リーダの表示位置」問題を完全かつ最終的に解決する」
　https://d.nekoruri.jp/entry/20130307/horizontalellipsis
U+2026の「…」ではなく、(U+22EF)の「⋯」を使うだけで真ん中に表示される日本人の大好きな三点リーダになります。

**Name_Not_Found** · 2019/01/22(火) 19:34:51.02

【IE・Firefoxバグ】InternetExplorer11、Firefox64、GoogleChrome71、をWindows8.1で確認。
　font-familyプロパティが、@font-face内だと通常と違って和文フォントを英字名しか読み込まず日本語名を受けつけなくなる。
　また特にFirefoxではファミリー名にウェイトを附けると認識しないことがある（>>585の逆）。フォント・ファイル名なら末尾に‘-weight名’が入っても可みたいだけど、それではChromeで反映しなくなる。
　バグではなく仕様にしても、ブラウザ間の不一致がひどすぎて、使用するのに困惑する。
　OS標準インストールの和文フォント名一覧とも微妙に齟齬する。
　https://w3g.jp/sample/css/font-family#japanese
　Webフォントでなくローカル・フォントに對して@font-face内font-familyでフォント・ファミリー名を上書きして複数まとめたりする手法（下記等）が、無為になる。
　https://text.baldanders.info/remark/2018/05/using-local-fonts-in-web-pages/
　https://qiita.com/RinoTsuka/items/1e7b3ca1325e704bbc41
　https://qiita.com/ln-north/items/21bff624c5d0f8e40fe9
テストしたソースは以下。
<!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

**Name_Not_Found** · 2019/01/22(火) 19:35:40.93

>>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の英数字になる。

**Name_Not_Found** · 2019/01/22(火) 20:51:50.61

>>596
https://www.tomotanuki.com/entry/yugothic-weight
「指定するフォント名は現段階ではブラウザによってまちまちです。
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書き方まとめ

**Name_Not_Found** · 2019/01/22(火) 20:53:37.04

>>598
Hiragino Sansフォントウェイトのcss書き方まとめ
https://joppot.info/2018/12/05/4466
http://hiragino.joppot.info/

**Name_Not_Found** · 2019/01/22(火) 21:20:46.74

>>596・>>597
>"Yu Mincho Regular"　IE×　FF○　GC×
>"YuMincho-Regular"　IE○　FF○　GC×
>"Yu Mincho"　IE○　FF×　GC○

ChromeはPostScript Nameを認識できないので、Font Family Nameで指定しなければならない。
https://w3g.jp/blog/use_yufamily
https://speakerdeck.com/tacamy/modanri-ben-yu-huontozhi-ding?slide=79

**Name_Not_Found** · 2019/01/22(火) 22:08:14.28

>>600
しかし"ＭＳ明朝"のPostScript名は"MS-Mincho"らしいが、
　Cf.「フォントのPostScript名, フルネーム, ファミリーの日本語名と英語名」https://taken.jp/font-name-english-japanese.html
@font-face {font-family: "f01"; src: local("MS-Mincho");}
と指定しても、IE・Firefox・GoogleChromeどれも表示に反映されない。

**Name_Not_Found** · 2019/01/23(水) 11:38:54.62

>>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×

ダウンロード　https://www.google.com/get/noto/help/cjk/
Cf. https://qiita.com/umeume66/items/01291353fc43c17da992

Google Fontsの'Noto Serif JP'も同様かね？
https://fonts.google.com/specimen/Noto+Serif+JP?selection.family=Noto+Serif+JP:400,700&;selection.subset=japanese

**Name_Not_Found** · 2019/01/23(水) 14:03:18.00

>>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やスマホは確認できないので、できる人よろしく。

**Name_Not_Found** · 2019/01/28(月) 03:11:07.93

バグではなく未対応だかららしいけど、混乱するので。

font-feature-settingsプロパティーは、ほぼ全てのブラウザが対応する。
https://caniuse.com/#feat=font-feature
https://developer.mozilla.org/ja/docs/Web/CSS/font-feature-settings#Browser_compatibility
しかし。
font-feature-settingsを@font-face { }内で使用すると、Firefoxでしか有効でない罠。
https://developer.mozilla.org/ja/docs/Web/CSS/@font-face#Browser_compatibility

**Name_Not_Found** · 2019/01/29(火) 11:53:41.59

他のブラウザでは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

**Name_Not_Found** · 2019/01/29(火) 13:02:19.34

>>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で游明朝体の文字詰めが効かなかったり

**Name_Not_Found** · 2019/01/29(火) 13:10:52.41

>>604
ここ↓、その@face-font内font-feature-settingsで嵌ってた。
「CSSで行頭の約物を半角にする」
https://dskd.jp/archives/87.html

**Name_Not_Found** · 2019/02/04(月) 17:06:35.30

【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

**Name_Not_Found** · 2019/02/04(月) 17:09:42.04

>>608
×　「&;#x4E13;」　&の後の「;」が不要。
○　「专」

**Name_Not_Found** · 2019/02/10(日) 18:52:31.49

>>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（ゴシック体）のまま。

**Name_Not_Found** · 2019/02/15(金) 18:30:21.46

>>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で反映しなかったのは、フォントキャッシュとかの問題では？

**Name_Not_Found** · 2019/02/20(水) 18:38:10.24

>>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"だけ有効だった。

**Name_Not_Found** · 2019/04/19(金) 18:42:32.78

>>551-553のwhite-space:nowrap;バグ、最新のChrome73になってもまだ直ってないのな。
WebKitのバグってどこに報告すれば修正してくれんのかね？

**Name_Not_Found** · 2019/06/10(月) 21:00:12.09

>>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>
とインライン要素タグで括って中に半角英数や記号以外の日本語文字を入れると、直る。

**Name_Not_Found** · 2019/06/11(火) 03:14:20.67

>>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>で挟めば、行高設定次第でずれ解消が有効になるはず。

**Name_Not_Found** · 2019/06/11(火) 03:50:16.31

>>560 - >>565
Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。

↑これ、全く再現しないね。
font-family:Arial, 'MS Mincho';
とか
font-family:Arial, 'Yu Mincho';
とかで試したけど、ちゃんと日本語の部分は日本語フォントで描画される。
総称ファミリー名のserifを末尾に指定するかどうかも関係無し。
なんか、間違ったのか？

**Name_Not_Found** · 2019/06/15(土) 08:07:04.60

これは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では、
逸󠄁／
齋󠄁
と２行に表示され、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。

**Name_Not_Found** · 2019/06/15(土) 08:10:00.98

>>617 追記修正
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、他方、Chromeでは、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。

**Name_Not_Found** · 2019/06/22(土) 07:25:22.77

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/

**Name_Not_Found** · 2019/06/22(土) 08:24:16.07

>>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は、値の不正な記述の仕方（「不正な値」の指定ではない）でもプロパティーそのものは無効にならない点では、バグである。

**Name_Not_Found** · 2019/06/22(土) 08:32:00.85

>>620修正
＞body {'MS PMincho'}
body {font-family: 'MS PMincho';}

**Name_Not_Found** · 2022/12/16(金) 23:35:39.75

>>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特有の問題が発生するのかも。

**Name_Not_Found** · 2022/12/17(土) 00:16:31.58

>>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にも効いてしまった！　バグが再生。 */

**Name_Not_Found** · 2022/12/18(日) 16:26:42.99

>>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）でも適用されるものの、指定しない時と比べて特に変化は起きない模様。

**Name_Not_Found** · 2022/12/18(日) 18:17:57.17

>>622
CSSではないけど、そもそもFalkonは行中での折返し（改行）をするアルゴリズムが何かヘン。
非表示のゼロ幅スペース（ U+200B）を挟んでも、そこで折り返してくれない。
HTMLソースで改行してあると、そこがブラウザ表示でも改行できる位置になる。
ちなみにゼロ幅スペースを入れた直後にソースで改行すると、
ChromeやFirefoxと違ってFalkonの表示ではドット一箇分ほどの幅の隙間が空く。ゼロ幅にならない！
<wbr>タグには対応してるから、そっちを使用すればいいのかもしれんが。

**Name_Not_Found** · 2022/12/18(日) 18:35:49.47

>>626
↓こんなソースで比較してみると。
<h1><a href="">■</a>大見出し１</h1>
<h1><a href="">■</a>
大見出し２</h1>
<h1><a href="">■</a>
大見出し３</h1>

Chrome108/Firefox108での表示
■大見出し１
■ 大見出し２　←■の後に一文字の三分の一程の幅のスペースが空く。
■大見出し３　←前行末にゼロ幅スペースがあるとソース改行による空白が打ち消される。

Falkon3.1.0での表示
■大見出し１
■ 大見出し２　←■の後に一文字の三分の一程の幅のスペースが空く。
■ 大見出し３　←前行末にゼロ幅スペースがあってもソース改行による空白が打ち消されない。

**Name_Not_Found** · 2023/09/20(水) 18:01:30.13

正しいことをやりましょう