CSS/DHTMLバグ辞典スレッド【第5版】
>>563 >monospaceに書き換えるとちゃんとMS Pゴシックで表示される 総称ファミリー名をmonospaceと指定した場合、「MS Pゴシック」でなく「MS ゴシック」で表示されるべきなのでは? Pはプロポーショナル・フォントだから、固定幅でない。 Cf. http://momdo.s35.xrea.com/web-html-test/spec/CSS21/fonts.html#monospace-def >>564 何だかんだ試してみて、以下のことが分かった。>>560 を訂正。 Windows8.1+IE11 ・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。 欧文フォントについては適用されるが和文フォントの指定が無視されて、 和文はIEの標準フォント(ツール>インターネットオプション>フォントで指定したフォント)で表示される (>>560 のケースは標準フォントもMS PGothicだったから、指定が効いたんだと勘違いしていた)。 ただし欧文フォントの後ろに「sans-serif」と「serif」が指定されると無視されず、 sans-serifはメイリオで、serifは(おそらく)MS P明朝で表示される。 それ以外のmonospaceやfantasyなどについても無視されて、IEの標準フォントで表示される。 【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"><!-- ChangeStyle = function( name ){ // 代替スタイルシート切替スクリプトは右記を拝借→ http://www.usamimi.info/ ~geko/arch_web/02_sample/018/index.html }//--> </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のレンダリングはちょっと問題含みか。 >>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>ABCDE</li> <li>あいうえお<br>ああああ<br>aaaaa</li> </ul> ところが、これでもGoogle Chrome(とSafari)で別の不具合が生じた。 代替スタイルシート適用直後、リスト一行目のリストマーカー画像が消えたり、右半分欠けたりする。 そこでdefaultスタイルに戻してから再度代替シートに切換すると、まともに表示される。 しかしページ再読み込みして、また代替スタイルシートで縦書きを適用すると、やはり一行目のliの背景画像だけ消える。 なにこれ? >>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要素にも指定すると、バグは解消した。 >>550 のSafari5.1.7の縦書きでのバグについて。 Safariブラウザのウィンドウを垂直に伸ばすと縦書きボックスの横幅も増えてゆく。 つまり>>544 のIEバグと似て、縦の高さ(height)がなぜか横幅の長さにまで影響するバグだった。 そこで>>568 の解決法を試して、body, html {height:100%;} としてみた。 すると>>550 後半のStrictモード時に縦書きの各段毎の横スクロールが出なくなる不具合だけは解消した。 しかし依然としてbody内の縦書きボックスのwidthが画面表示領域の高さと連動するバグは出る。 Safari6以降では修正されたのかな。 【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が効いて横並びに戻った。 よく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 Safariでテーブルにダッシュのボーダーの要素thやtdに幅いれると隙間あくのバグかな とりあえずこのスレでいいのかな…ちょっとコレ見て欲しい。 (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はコレでシステム起動時間もどきを取れるの確認したけど、他だとどーよ? WinXP・IE7 縦書きwriting-mode:tb-rl;適用時、font-familyで和文OpenTypeFontを指定すると、字間ピッチが変に詰まる。 ブラウザーモードIE10 ドキュメントモード IE8標準・IE9標準・Quirks・標準 <ul> <li><del><p>リスト1</p></del></li> <li><ins><p>リスト2</p></ins></li> </ul> ・リスト1 ・リスト2 となるべきが、 ・ リスト1 ・ リスト2 となる。 IE5Quirksでは不具合は生じなかった。Firefox36やGoogle Chromeでも問題無し。 IEだけのバグ。 また、下記のソースにすると、ズレは起きない。 <li><p><del>リスト3</del></p></li> <li><del>リスト4</del></li> ホームページで友達が稼げるようになった情報とか ⇒ http://asaswq3wq.sblo.jp/article/181819223.html 興味がある人だけ見てください。 TU3YZB5BIW ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 誰でもできる在宅ワーク儲かる方法 少しでも多くの方の役に立ちたいです グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』 AFLZE 久し振りにHTML・CSSをいぢってるんだが、いまだIE11がバグで足引っ張るんだなあ。 フォント指定でヒラギノや游明朝・ゴシックや小塚明朝・ゴシックにするだけで文字の位置が上にズレ。 h1 {font-family: KozMinPr6N-Regular, '小塚明朝 Pr6N R', serif;} 下に続く要素との間にヘンな余白が空く。 IE11は先日マイナー・バージョンアップしたけど直ってない。 何なのこれ。 先頭に欧文フォント指定すればバグ回避できるけど、半角英数字は当然欧文フォントで表示され不統一に。 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/ >>583 源ノ明朝・源ノ角ゴシックを指定したら、逆に下に寄った。 h1 {font-family: 'Noto Serif CJK JP';} 総じて、IEはオープンタイプ・フォント(.otf)への対応が変なのでは。 ディセンダー(ベースラインより下に出た部分)を設定するディセント値WinDescenderの問題かも。 >>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指定に入れられるんだけど。 IE10, IE11ではフォーカス時にplaceholderの表示が消えますが、Chrome、 Firefox、Safari などでは、文字を入力するまで表示され続けます。 https://qiita.com/myzkyy/items/54c19077f95f0fc1a19a ここから派生したバグ。 条件1 ・検索ボックスが、display: flex;(IEだとdisplay: -ms-flexbox;)を指定した祖先要素内にあり、フレックス・ボックスを継承。 条件2 ・検索ボックスのinput要素にwidthを%単位でスタイル指定してある。 条件3 ・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 >>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> >>588 追記 :-ms-input-placeholder {font-family: sans-serif;} 総称フォントでは、このsans-serifが一番ひどい。 フォーカス時は検索ボックスの幅が半分位に短くなる。つまり通常時は倍に伸びてしまってる。 monospace にすると、1文字分ほど(約1em)増減する。 serif では逆に、フォーカス時にプレイスホルダーの文字が消えると、検索窓の横幅が長くなる。伸縮率は短く0.5em程。 system-ui は挙動はserif と同じだが初期状態(非フォーカス時)の長さが少し短くなるので、伸縮率は1em位。 以下のグローバル値もsystem-uiと挙動は同じ。伸縮率も同程度に軽少。 font-family: inherit; font-family: initial; font-family: unset; ちなみにIEの設定はデフォルトのまま、ツール>インターネット オプション>全般>フォントで Webページ フォントが「MS PGothic」、テキスト形式フォントが「MS ゴシック」。 >>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 のバグの発生条件には、これも足すべきだった。 >>587 ・>>588 バグの発生条件に下記は関係無かった。 >条件1 >・検索ボックスが、display: flex;(IEだとdisplay: -ms-flexbox;)を指定した祖先要素内にあり、フレックス・ボックスを継承。 >条件2 >・検索ボックスの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を継承してないからか)。 >>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ファイルで上書きすれば良し。 これで、入力フォームにカーソル入れると横幅が伸び縮みする不条理は避けられるはず。 >>583 >しかも、三点リーダー「…」なんかは欧文式にベースライン表示の「...」になる罠。 「三点リーダが真ん中に表示されない理由」 http://www.koikikukan.com/archives/2013/02/27-012345.php 「三点リーダ問題、webfontでついに解決!……か?」 http://orangeprose. blog.fc2.com/blog-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)の「⋯」を使うだけで真ん中に表示される日本人の大好きな三点リーダになります。 【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("MS 明朝");} .f01 {font-family:"f01";} </style> </head> <body> <div class="f01">永なふをQ9g桜咲く</div> </body> </html 上記"MS 明朝"の箇所に明朝体の日本語フォントを日本語名/英語名で代入して、日本語の表示がsans-serif(ゴシック体)でなくなるかを確かめた。 結果一覧は>>597 >>596 のテスト結果 "MS 明朝" 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の英数字になる。 >>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書き方まとめ >>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 >>600 しかし"MS 明朝"の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どれも表示に反映されない。 >>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 >>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やスマホは確認できないので、できる人よろしく。 他のブラウザでは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 >>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で游明朝体の文字詰めが効かなかったり >>604 ここ↓、その@face-font内font-feature-settingsで嵌ってた。 「CSSで行頭の約物を半角にする」 https://dskd.jp/archives/87.html 【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 >>608 × 「&;#x4E13;」 &の後の「;」が不要。 ○ 「专」 >>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(ゴシック体)のまま。 >>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で反映しなかったのは、フォントキャッシュとかの問題では? >>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"だけ有効だった。 >>551-553 のwhite-space:nowrap;バグ、最新のChrome73になってもまだ直ってないのな。 WebKitのバグってどこに報告すれば修正してくれんのかね? >>583 >フォント指定でヒラギノや游明朝・ゴシックや小塚明朝・ゴシックにするだけで文字の位置が上にズレ >先頭に欧文フォント指定すればバグ回避できるけど、半角英数字は当然欧文フォントで表示され不統一に。 このIEバグは、ただ先頭に欧文フォントを指定しても、不具合は解消しない。同時に子要素の行間を小さく指定しないと。 下記ソースで確認。 <!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> とインライン要素タグで括って中に半角英数や記号以外の日本語文字を入れると、直る。 >>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先頭の欧文フォント指定と掛け合せた上で2バイト文字列のどれかを<span> </span>で挟めば、行高設定次第でずれ解消が有効になるはず。 >>560 - >>565 Windows8.1+IE11 ・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。 ↑これ、全く再現しないね。 font-family:Arial, 'MS Mincho'; とか font-family:Arial, 'Yu Mincho'; とかで試したけど、ちゃんと日本語の部分は日本語フォントで描画される。 総称ファミリー名のserifを末尾に指定するかどうかも関係無し。 なんか、間違ったのか? これは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」で2文字と計算するらしく、 それで要素の横幅がフォント・サイズ1文字分(1em)より小さいと、1文字はみ出たVSの分だけ文字化けして表示され、基底文字の下に流れて配置される。 width指定で要素の幅がfont-sizeより広く取ってあっても、box-sizing: content-box;(既定)の場合にpaddingとかborderを入れると、この不具合が発現したりする。 floatでwidtj指定を入れる場合にも、注意↓。 実例 http://wakufactory.jp/densho/font/db/mojidb2.html#09038 Firefox67やChrome75では再現しなかった。 ただ上記一行のソースは、Firefoxでは、 逸󠄁/ 齋󠄁 と2行に表示され、 逸󠄁 / 齋󠄁 と3行に表示された。 「/」を「―」「■」等の記号に変更しても同様。 >>617 追記修正 <div style="font-size:51px; width:50px;">逸󠄁/齋󠄁</div> ただ上記一行のソースは、Firefoxでは、 逸󠄁/ 齋󠄁 と2行に表示され、他方、Chromeでは、 逸󠄁 / 齋󠄁 と3行に表示された。 「/」を「―」「■」等の記号に変更しても同様。 font-familyプロパティーの値でインストールされてないフォントのみを指定された場合、継承値を反映しなくなる難があるが、 値の末尾に総称ファミリー名の代りにinheritを指定すると、 Chrome・Firefoxでは継承値で表示されて問題は解消するものの、Internet Explorer 11では無効のまま。 環境はWindows8.1で確認。 body {font-family: YuMincho, '游明朝', serif;} <p>例1:フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝'">馬酔木明朝</span>」ってフォントがある。</p> <p>例2:フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit;">馬酔木明朝</span>」ってフォントがある。</p> <p>例3:フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit, serif;">馬酔木明朝</span>」ってフォントがある。</p> 上記ソースで、本文は游明朝(それが無ければ他の明朝体)になるが、例1の"馬酔木明朝"の文字列はゴシック体になった。 例2でスタイル設定値にinheritを足すと、Chrome75とFirefox67では游明朝になったがIE11ではゴシック体のまま。 例3で値の末尾に更に総称ファミリー名serifを追記すると、IE11だけ游明朝でなく'MS 明朝'になった。 但し、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>例4:フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit, monospace;">馬酔木明朝</span>」ってフォントがある。</p> <p>例5:フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', monospace, inherit;">馬酔木明朝</span>」ってフォントがある。</p> とか総称フォント名をmonospaceにしても、等幅フォントで表示されなかったし、 <p>例6: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年1月に出たヴァージョン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>大見出し1</h1> <h1><a href="">■</a> 大見出し2</h1> <h1><a href="">■</a>​ 大見出し3</h1> Chrome108/Firefox108での表示 ■大見出し1 ■ 大見出し2 ←■の後に一文字の三分の一程の幅のスペースが空く。 ■大見出し3 ←前行末にゼロ幅スペースがあるとソース改行による空白が打ち消される。 Falkon3.1.0での表示 ■大見出し1 ■ 大見出し2 ←■の後に一文字の三分の一程の幅のスペースが空く。 ■ 大見出し3 ←前行末にゼロ幅スペースがあってもソース改行による空白が打ち消されない。 read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる