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

1 ：Name_Not_Found：2006/04/08(土) 20:05:59 ID:FsSaRr1T.net

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あたりで。

578 ：Name_Not_Found：2015/11/08(日) 20:27:40.40 ID:aoSagCoy.net

ぬるぽ

579 ：Name_Not_Found：2016/05/06(金) 13:40:02.20 ID:???.net

ガッ

580 ：Name_Not_Found：2017/12/12(火) 04:21:02.29 ID:MrUcGD8N.net

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

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

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

TU3YZB5BIW

581 ：Name_Not_Found：2018/02/18(日) 20:19:11.30 ID:???.net

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

582 ：Name_Not_Found：2018/05/01(火) 21:55:26.87 ID:l1wYHpV1.net

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

AFLZE

583 ：Name_Not_Found：2018/12/30(日) 10:46:45.78 ID:???.net

久し振りに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/

584 ：Name_Not_Found：2019/01/08(火) 21:21:58.82 ID:???.net

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

585 ：Name_Not_Found：2019/01/09(水) 01:39:17.45 ID:???.net

>>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指定に入れられるんだけど。

586 ：Name_Not_Found：2019/01/09(水) 14:08:54.60 ID:???.net

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

587 ：Name_Not_Found：2019/01/15(火) 20:33:49.93 ID:???.net

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

588 ：Name_Not_Found：2019/01/15(火) 20:36:41.71 ID:???.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="検索語&hellip;" value="" name="s" />
</form>
</div>
<div class="sidemenu">右寄せメニュー〜</div>
</div>
</header></body></html>

589 ：Name_Not_Found：2019/01/15(火) 20:52:07.69 ID:???.net

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

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

590 ：Name_Not_Found：2019/01/15(火) 21:40:40.88 ID:???.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：2019/01/16(水) 02:13:34.85 ID:???.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：2019/01/16(水) 03:27:21.38 ID:???.net

>>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経由で利用する場合は問題ないみたいです。」

593 ：Name_Not_Found：2019/01/16(水) 15:40:27.59 ID:???.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：2019/01/17(木) 03:12:34.66 ID:???.net

>>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ファイルで上書きすれば良し。
これで、入力フォームにカーソル入れると横幅が伸び縮みする不条理は避けられるはず。

595 ：Name_Not_Found：2019/01/22(火) 02:38:40.50 ID:???.net

>>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)の「⋯」を使うだけで真ん中に表示される日本人の大好きな三点リーダになります。

596 ：Name_Not_Found：2019/01/22(火) 19:34:51.02 ID:???.net

【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

597 ：Name_Not_Found：2019/01/22(火) 19:35:40.93 ID:???.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：2019/01/22(火) 20:51:50.61 ID:???.net

>>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書き方まとめ

599 ：Name_Not_Found：2019/01/22(火) 20:53:37.04 ID:???.net

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

600 ：Name_Not_Found：2019/01/22(火) 21:20:46.74 ID:???.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で指定しなければならない。
https://w3g.jp/blog/use_yufamily
https://speakerdeck.com/tacamy/modanri-ben-yu-huontozhi-ding?slide=79

601 ：Name_Not_Found：2019/01/22(火) 22:08:14.28 ID:???.net

>>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どれも表示に反映されない。

602 ：Name_Not_Found：2019/01/23(水) 11:38:54.62 ID:???.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×

ダウンロード　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

603 ：Name_Not_Found：2019/01/23(水) 14:03:18.00 ID:???.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：2019/01/28(月) 03:11:07.93 ID:???.net

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

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

605 ：Name_Not_Found：2019/01/29(火) 11:53:41.59 ID:???.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. https://helpx.adobe.com/jp/fonts/using/open-type-syntax.html#palt

606 ：Name_Not_Found：2019/01/29(火) 13:02:19.34 ID:???.net

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

607 ：Name_Not_Found：2019/01/29(火) 13:10:52.41 ID:???.net

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

608 ：Name_Not_Found：2019/02/04(月) 17:06:35.30 ID:???.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. http://pentan.info/stylesheet/bug/winie033.html

609 ：Name_Not_Found：2019/02/04(月) 17:09:42.04 ID:???.net

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

610 ：Name_Not_Found：2019/02/10(日) 18:52:31.49 ID:???.net

>>608
下記ソースで再テスト。
p {font-family:Tahoma,sans-serif;}
.f01 {font-family:"游明朝";}
<p>「专」：ユニコード数値文字参照（16進数）→「&#x4E13;」</p>
<p class="f01">「专」：ユニコード数値文字参照（16進数）→「&#x4E13;」</p>
IE11ではp.f01で「 」内がsans-serifを継承せずserif（游明朝ではない何かの明朝体）になった。
やはりIEは所詮IEで、対応に問題があるみたい。
Firefox65・GoogleChrome72では「 」内はsans-serif（ゴシック体）のまま。

611 ：Name_Not_Found：2019/02/15(金) 18:30:21.46 ID:???.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：2019/02/20(水) 18:38:10.24 ID:???.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：2019/04/19(金) 18:42:32.78 ID:???.net

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

614 ：Name_Not_Found：2019/06/10(月) 21:00:12.09 ID:???.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：2019/06/11(火) 03:14:20.67 ID:???.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のバグまとめ > 特定のフォントでテキストの下に隙間が空く。
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>で挟めば、行高設定次第でずれ解消が有効になるはず。

616 ：Name_Not_Found：2019/06/11(火) 03:50:16.31 ID:???.net

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

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

617 ：Name_Not_Found：2019/06/15(土) 08:07:04.60 ID:???.net

これはCSSのバグなのかどうか……。
InternetExplorer11／Windows8.1で確認。
・フォント・サイズをその要素の横幅以上に拡大すると、IVS（＝基底文字＋VS）のVSが文字化けする。

IVS（異体字シークエンス）は、「通常の文字と同様、数値文字参照を使って書くこともできる。フォントやOS、アプリケーションが対応していない場合には、通常の基底文字のグリフが単に表示される（ことが望まれるが、VSが豆腐などで表示されてしまうことが多い）。」
　https://shiromoji.hatenablog.jp/entry/20120308/1331194033
ところが、別に「・」や「□」（豆腐）に化けてなかった文字も、フォント・サイズを一定以上に大きくすると四角になることがある。
下記一行のソースで再現できた。

<div style="font-size:51px; width:50px;">&#x9038;&#xE0101;／&#x9F4B;&#xE0101;</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では、
&#x9038;&#xE0101;／
&#x9F4B;&#xE0101;
と２行に表示され、
&#x9038;&#xE0101;
／
&#x9F4B;&#xE0101;
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。

618 ：Name_Not_Found：2019/06/15(土) 08:10:00.98 ID:???.net

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

619 ：Name_Not_Found：2019/06/22(土) 07:25:22.77 ID:???.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'プロパティ
https://momdo.github.io/css2/fonts.html#font-family-prop
ならば厳密にはスタイルシートのバグではなくてブラウザーごとの仕様なのか？

あと、「馬酔木明朝」は下記で無料配布。
https://metasta.github.io/asebi/

620 ：Name_Not_Found：2019/06/22(土) 08:24:16.07 ID:???.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：2019/06/22(土) 08:32:00.85 ID:???.net

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

622 ：Name_Not_Found：2022/12/16(金) 23:35:39.75 ID:???.net

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

623 ：Name_Not_Found：2022/12/17(土) 00:16:31.58 ID:???.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：2022/12/18(日) 16:26:42.99 ID:???.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：2022/12/18(日) 18:17:57.17 ID:EoAW88W9.net

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

626 ：Name_Not_Found：2022/12/18(日) 18:35:49.47 ID:???.net

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

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

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

627 ：Name_Not_Found：2023/09/20(水) 18:01:30.13 ID:???.net

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