CSS/DHTMLバグ辞典スレッド【第５版】 (627ﾚｽ)
上下前次1-新
1(8): 2006/04/08(土)20:05 ID:FsSaRr1T(1/2) AAS
CSS（とDHTML）のバグ報告、お待ちしてます。
※報告の際はOS・ブラウザ名とそのヴァージョンを明記して下さい。
再現条件をつきとめるため、必要に応じてソースを出して下さい。
第４版レス314までのバグは下記に登録済み（前々366◆E3CSS.J95U／◆B7TCOttEさんに感謝）。
【CSSバグリスト＠CSSバグ辞典スレッド】
外部ﾘﾝｸ[html]:cssbug.at.infoseek.co.jp
（もうずっと更新休止、誰かwikiででも引き継がないか？）
プロパティ別にバグを調べたいときは――
・K@tsukun's PAGE! ＞ CSS対応状況表 （の各プロパティ「関連バグ情報」）
外部ﾘﾝｸ[html]:hp.vector.co.jp
省17
608(2): 2019/02/04(月)17:06 ID:??? AAS
【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等の中国語フォントか？）。
省8
609: 2019/02/04(月)17:09 ID:??? AAS
>>608
× 「&;#x4E13;」 &の後の「;」が不要。
○ 「专」
610: 2019/02/10(日)18:52 ID:??? AAS
>>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: 2019/02/15(金)18:30 ID:??? AAS
>>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: 2019/02/20(水)18:38 ID:??? AAS
>>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"; /*有効*/
省1
613: 2019/04/19(金)18:42 ID:??? AAS
>>551-553のwhite-space:nowrap;バグ、最新のChrome73になってもまだ直ってないのな。
WebKitのバグってどこに報告すれば修正してくれんのかね？
614(1): 2019/06/10(月)21:00 ID:??? AAS
>>583
>フォント指定でヒラギノや游明朝・ゴシックや小塚明朝・ゴシックにするだけで文字の位置が上にズレ
>先頭に欧文フォント指定すればバグ回避できるけど、半角英数字は当然欧文フォントで表示され不統一に。
このＩＥバグは、ただ先頭に欧文フォントを指定しても、不具合は解消しない。同時に子要素の行間を小さく指定しないと。
下記ソースで確認。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>OpenTypeフォントのIE表示</title>
省18
615: 2019/06/11(火)03:14 ID:??? AAS
>>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のバグまとめ > 特定のフォントでテキストの下に隙間が空く。
外部ﾘﾝｸ:qiita.com
「line-heightを限りなく0に近い数値にすることでズレを回避できますが、改行した瞬間に文字が重なって終わるので現実的な解決策ではありません。」
↑これも、line-height:1%;とかやっても利き目なかったけど、font-family先頭の欧文フォント指定と掛け合せた上で２バイト文字列のどれかを<span> </span>で挟めば、行高設定次第でずれ解消が有効になるはず。
616: 2019/06/11(火)03:50 ID:??? AAS
>>560 - >>565
Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。
↑これ、全く再現しないね。
font-family:Arial, 'MS Mincho';
とか
font-family:Arial, 'Yu Mincho';
とかで試したけど、ちゃんと日本語の部分は日本語フォントで描画される。
総称ファミリー名のserifを末尾に指定するかどうかも関係無し。
なんか、間違ったのか？
617(1): 2019/06/15(土)08:07 ID:??? AAS
これはCSSのバグなのかどうか……。
InternetExplorer11／Windows8.1で確認。
・フォント・サイズをその要素の横幅以上に拡大すると、IVS（＝基底文字＋VS）のVSが文字化けする。
IVS（異体字シークエンス）は、「通常の文字と同様、数値文字参照を使って書くこともできる。フォントやOS、アプリケーションが対応していない場合には、通常の基底文字のグリフが単に表示される（ことが望まれるが、VSが豆腐などで表示されてしまうことが多い）。」
外部ﾘﾝｸ:shiromoji.hatenablog.jp
ところが、別に「・」や「□」（豆腐）に化けてなかった文字も、フォント・サイズを一定以上に大きくすると四角になることがある。
下記一行のソースで再現できた。
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
どうもIE11はIVSを「基底文字＋VS」で２文字と計算するらしく、
それで要素の横幅がフォント・サイズ１文字分（1em）より小さいと、１文字はみ出たVSの分だけ文字化けして表示され、基底文字の下に流れて配置される。
省13
618: 2019/06/15(土)08:10 ID:??? AAS
>>617 追記修正
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、他方、Chromeでは、
逸󠄁
／
齋󠄁
と３行に表示された。
省1
619(1): 2019/06/22(土)07:25 ID:??? AAS
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ではゴシック体のまま。
省8
620(1): 2019/06/22(土)08:24 ID:??? AAS
>>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>
省4
621: 2019/06/22(土)08:32 ID:??? AAS
>>620修正
＞body {'MS PMincho'}
body {font-family: 'MS PMincho';}
622(3): 2022/12/16(金)23:35 ID:??? AAS
>>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を使うことを強制しています」
外部ﾘﾝｸ:news.livedoor.com
省1
623: 2022/12/17(土)00:16 ID:??? AAS
>>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には無効、ここまでバグ発生せず。 */
省4
624: 2022/12/18(日)16:26 ID:??? AAS
>>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: 2022/12/18(日)18:17 ID:EoAW88W9(1) AAS
>>622
CSSではないけど、そもそもFalkonは行中での折返し（改行）をするアルゴリズムが何かヘン。
非表示のゼロ幅スペース（​ U+200B）を挟んでも、そこで折り返してくれない。
HTMLソースで改行してあると、そこがブラウザ表示でも改行できる位置になる。
ちなみにゼロ幅スペースを入れた直後にソースで改行すると、
ChromeやFirefoxと違ってFalkonの表示ではドット一箇分ほどの幅の隙間が空く。ゼロ幅にならない！
<wbr>タグには対応してるから、そっちを使用すればいいのかもしれんが。
626(1): 2022/12/18(日)18:35 ID:??? AAS
>>626
↓こんなソースで比較してみると。
<h1><a href="">■</a>大見出し１</h1>
<h1><a href="">■</a>
大見出し２</h1>
<h1><a href="">■</a>​
大見出し３</h1>
Chrome108/Firefox108での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
省5
627: 2023/09/20(水)18:01 ID:??? AAS
正しいことをやりましょう
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.379s*