13/11/20 00:19:11.56 .net
>>560
和文フォント名を"MS Gothic"とかアルファベット表記にしたらどうなります？
Cf. URLﾘﾝｸ(blog.sakurachiro.com)
562:Name_Not_Found
13/11/20 22:30:07.69 .net
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'で設定したマーカーと置き換える」とある。
URLﾘﾝｸ(momdo.s35.xrea.com)
画像が利用可能でない場合は置換せずにマーカーを表示すべき筈。
Cf.存在しない画像をリストマーカーに指定するとリストマーカーが完全に消える
URLﾘﾝｸ(pentan.info)
563:Name_Not_Found
13/11/20 22:43:31.39 .net
>>561
「font-family:"Verdana","ＭＳ Ｐゴシック","MS PGothic",sans-serif;」ではダメだった。
sans-serifを外したり、monospaceに書き換えるとちゃんとＭＳ Ｐゴシックで表示されることから、
「sans-serif」の処理に問題がありそうな感触。
「font-family:"Verdana","MS PGothic",sans-serif;」だとどうなるかは、今度試してみる。
564:Name_Not_Found
13/11/20 23:21:50.25 .net
>>563
>monospaceに書き換えるとちゃんとＭＳ Ｐゴシックで表示される
総称ファミリー名をmonospaceと指定した場合、「ＭＳ Ｐゴシック」でなく「ＭＳ ゴシック」で表示されるべきなのでは？
Pはプロポーショナル・フォントだから、固定幅でない。
Cf. URLﾘﾝｸ(momdo.s35.xrea.com)
565:Name_Not_Found
13/11/21 22:27:50.54 .net
>>564
何だかんだ試してみて、以下のことが分かった。>>560を訂正。
Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。
欧文フォントについては適用されるが和文フォントの指定が無視されて、
和文はIEの標準フォント（ツール＞インターネットオプション＞フォントで指定したフォント）で表示される
（>>560のケースは標準フォントもMS PGothicだったから、指定が効いたんだと勘違いしていた）。
ただし欧文フォントの後ろに「sans-serif」と「serif」が指定されると無視されず、
sans-serifはメイリオで、serifは（おそらく）MS P明朝で表示される。
それ以外のmonospaceやfantasyなどについても無視されて、IEの標準フォントで表示される。
566:Name_Not_Found
13/11/22 21:09:54.35 .net
【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 ){
// 代替スタイルシート切替スクリプトは右記を拝借→ URLﾘﾝｸ(www.usamimi.info)
}//-->
</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のレンダリングはちょっと問題含みか。
567:Name_Not_Found
13/11/22 21:28:11.99 .net
>>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の背景画像だけ消える。
なにこれ？
568:Name_Not_Found
13/11/22 22:15:59.31 .net
>>544の解決法。→ body {height:100%} を指定しておく。
しかし、WinIE7標準モードで発生する別のバグにはそれだけでは不足。
>>544のソースのDOCTYPE宣言を変更して標準モードにし、IE7で閲覧する。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "URLﾘﾝｸ(www.w3.org)
<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要素にも指定すると、バグは解消した。
569:Name_Not_Found
13/11/23 11:52:59.97 .net
>>550のSafari5.1.7の縦書きでのバグについて。
Safariブラウザのウィンドウを垂直に伸ばすと縦書きボックスの横幅も増えてゆく。
つまり>>544のIEバグと似て、縦の高さ（height）がなぜか横幅の長さにまで影響するバグだった。
そこで>>568の解決法を試して、body, html {height:100%;} としてみた。
すると>>550後半のStrictモード時に縦書きの各段毎の横スクロールが出なくなる不具合だけは解消した。
しかし依然としてbody内の縦書きボックスのwidthが画面表示領域の高さと連動するバグは出る。
Safari6以降では修正されたのかな。
570:Name_Not_Found
13/11/24 02:54:41.24 .net
【IE5Quirks／IE7～9互換モード】
定義リスト（dl要素）を横並びさせる際、dd要素内でem要素が折り返される長さだけあると横に並ばなくなる。
定義リストをfloatで横並びにして表組み風にするのは、よくある。
Cf. URLﾘﾝｸ(blog.d-spica.com)
その際、IE6において、dt要素の高さよりdd要素内の段が高い場合、dtの横に隣接するddの一行目テキストだけ3pxほど右にずれるバグがある。
これに対処するには、zoom:1; を指定してhasLayoutをtrueにすれば解消する。
Cf. URLﾘﾝｸ(www.coolwebwindow.com)
しかし、或る条件下では、この横並びが崩れた。
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が効いて横並びに戻った。
571:Name_Not_Found
13/11/25 09:37:02.67 .net
>>570
関連
「フロートの左右にある行の端がずれる」
URLﾘﾝｸ(pentan.info)
572:Name_Not_Found
13/11/28 01:53:22.39 .net
よくremを使ったフォントサイズ指定で
html { font-size: 62.5%; }
body { font-size: 1.4rem; }
なんていうのがブログ等で紹介されているけど、
現状バージョンのChromeでフォントサイズの継承かおかしいのか
変更になったのかわからんがフォントサイズがおかしくなってしまう。
URLﾘﾝｸ(stackoverflow.com)
573:Name_Not_Found
13/12/06 16:08:46.35 .net
Safariでテーブルにダッシュのボーダーの要素thやtdに幅いれると隙間あくのバグかな
574:Name_Not_Found
13/12/24 15:00:14.92 .net
とりあえずこのスレでいいのかな…ちょっとコレ見て欲しい。
(1<<32)-1は0になるので(1<<30)*4-1で読み替えてもらうとして、
環境によっては49.7日問題が出ない代わりに上限が0x7fffFFFFミリ秒までになる。
0x7fffFFFFミリ秒あれば普通は十分だろうけど、32ビットフルで使えないのはバグな気もする。
JavaScript 3
ｽﾚﾘﾝｸ(tech板:124番)
124 名前：デフォルトの名無しさん[sage] 投稿日：2013/12/22(日) 03:38:15.71
ググっても
URLﾘﾝｸ(ap.atmarkit.co.jp)
URLﾘﾝｸ(ap.atmarkit.co.jp)
しか話が出てこないけどさ、JScriptのsetTimeoutって普通に49.7日問題発生するよな？
多分、timeout+starttime<GetTickCount()的な判定なんだと思うけど、
setTimeout("alert(0);",(1<<32)-1);とかだと普通に0秒でタイムアウトしてしまう。
応用すれば対象PCの起動からの時間も49.7日以下なら計測可能という。
例：URLﾘﾝｸ(jsbin.com)
WindowsXP SP3(32bit)+IE8はコレでシステム起動時間もどきを取れるの確認したけど、他だとどーよ？
575:Name_Not_Found
13/12/30 05:09:11.98 .net
WinXP・IE7
縦書きwriting-mode:tb-rl;適用時、font-familyで和文OpenTypeFontを指定すると、字間ピッチが変に詰まる。
576:Name_Not_Found
15/03/17 10:24:59.26 .net
ブラウザーモード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>
577:Name_Not_Found
15/08/10 00:43:26.38 .net
アゲ
578:Name_Not_Found
15/11/08 20:27:40.40 aoSagCoy.net
ぬるぽ
579:Name_Not_Found
16/05/06 13:40:02.20 .net
ガッ
580:Name_Not_Found
17/12/12 04:21:02.29 MrUcGD8N.net
ホームページで友達が稼げるようになった情報とか
⇒ URLﾘﾝｸ(asaswq3wq.sblo.jp)
興味がある人だけ見てください。
TU3YZB5BIW
581:Name_Not_Found
18/02/18 20:19:11.30 .net
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
582:Name_Not_Found
18/05/01 21:55:26.87 l1wYHpV1.net
誰でもできる在宅ワーク儲かる方法
少しでも多くの方の役に立ちたいです
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』
AFLZE
583:Name_Not_Found
18/12/30 10:46:45.78 .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に小塚ゴシックを使うときに注意すること
URLﾘﾝｸ(www.emuramemo.com)
IEで「游ゴシック／游明朝」を表示させると、文字の下側に由来不明の余白が生じる
URLﾘﾝｸ(answers.microsoft.com)
游明朝体・游ゴシック体の使用は注意しなくてはならない・・・ やってくれるねIE先輩！
URLﾘﾝｸ(qiita.com)
【CSS】游明朝・游ゴシックがIEでずれる
URLﾘﾝｸ(norando.net)
游を font-family で指定した時に IE で生じる謎余白対策
URLﾘﾝｸ(thk.kanzae.net)
584:Name_Not_Found
19/01/08 21:21:58.82 .net
>>583
源ノ明朝・源ノ角ゴシックを指定したら、逆に下に寄った。
h1 {font-family: 'Noto Serif CJK JP';}
総じて、IEはオープンタイプ・フォント（.otf）への対応が変なのでは。
ディセンダー（ベースラインより下に出た部分）を設定するディセント値WinDescenderの問題かも。
585:Name_Not_Found
19/01/09 01:39:17.45 .net
>>583
>h1 {font-family: KozMinPr6N-Regular, '小塚明朝 Pr6N R', serif;}
正しくは、
h1 {font-family: 'Kozuka Mincho Pr6N','小塚明朝 Pr6N', serif;}
参考：URLﾘﾝｸ(taken.jp)
でないと、IE以外のFirefoxなんかにはフォント指定が反映しない。
しかしこれがヒラギノだと、
font-family: "ヒラギノ明朝 ProN W6","HiraMinProN-W6";
みたいに、ウェイトまでfont-family指定に入れられるんだけど。
586:Name_Not_Found
19/01/09 14:08:54.60 .net
URLﾘﾝｸ(blogs.yahoo.co.jp)
587:Name_Not_Found
19/01/15 20:33:49.93 .net
IE10, IE11ではフォーカス時にplaceholderの表示が消えますが、Chrome、 Firefox、Safari などでは、文字を入力するまで表示され続けます。
URLﾘﾝｸ(qiita.com)
ここから派生したバグ。
条件１
・検索ボックスが、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を指定した時に、端末を横向きから縦向きに変更すると画面幅がおかしくなる
URLﾘﾝｸ(cly7796.net)
再現ソースは>>588
588:Name_Not_Found
19/01/15 20:36:41.71 .net
>>587のバグは下記のソースで再現する。
<!DOCTYPE html>
<html lang="ja">
<head>
<title>IE11検索窓プレースホルダー・バグ検証</tutle>
<style type="text/css">
:-ms-input-placeholder {font-family: sans-serif;}
input[type="search"] {width: 90%;}
.site-header-main {
-webkit-align-items:flex-start; -ms-flex-align:flex-start; align-items:flex-start;
display: -webkit-flex; display: -ms-flexbox; display: flex;
-webkit-flex-wrap: wrap; -ms-flex-wrap: wrap; flex-wrap: wrap;
-webkit-justify-content:space-between; justify-content:space-between; -ms-flex-pack:space-between;
}
div, h1, form {border:1px solid red;}/*視認しやすくするため*/
</style>
</head>
<body>
<header>
<div class="site-header-main">
<div class="site-branding">
<h1>タイトル</h1>
<form role="search" method="get" action="hoge.com">
<input type="search" placeholder="検索語…" value="" name="s" />
</form>
</div>
<div class="sidemenu">右寄せメニュー～</div>
</div>
</header></body></html>
589:Name_Not_Found
19/01/15 20:52:07.69 .net
>>587・>>588参考
【HTML】IEで、inputタグの width を指定したにもかかわらず、幅がずれる
URLﾘﾝｸ(blogs.yahoo.co.jp)
IE：入力フィールドのプレースホルダは選択ボックスの幅に影響します
URLﾘﾝｸ(stackoverrun.com)
590:Name_Not_Found
19/01/15 21:40:40.88 .net
>>588追記
:-ms-input-placeholder {font-family: sans-serif;}
総称フォントでは、このsans-serifが一番ひどい。
フォーカス時は検索ボックスの幅が半分位に短くなる。つまり通常時は倍に伸びてしまってる。
monospace にすると、１文字分ほど（約1em）増減する。
serif では逆に、フォーカス時にプレイスホルダーの文字が消えると、検索窓の横幅が長くなる。伸縮率は短く0.5em程。
system-ui は挙動はserif と同じだが初期状態（非フォーカス時）の長さが少し短くなるので、伸縮率は1em位。
以下のグローバル値もsystem-uiと挙動は同じ。伸縮率も同程度に軽少。
font-family: inherit;
font-family: initial;
font-family: unset;
ちなみにIEの設定はデフォルトのまま、ツール＞インターネット オプション＞全般＞フォントで
Webページ フォントが「MS PGothic」、テキスト形式フォントが「MS ゴシック」。
591:Name_Not_Found
19/01/16 02:13:34.85 .net
>>588
誤 <title>IE11検索窓プレースホルダー・バグ検証</tutle>
正 <title>IE11検索窓プレースホルダー・バグ検証</title>
それと、div.site-brandingの中で問題のinput要素の上にある要素（この場合、h1要素）の幅が長くなると、再現しないみたい。
横幅を計りやすくするため、
h1 {font-size:1em; font-weight:normal;}
<h1>一二三四五六七八九〇一二三四五六七八九〇</h1>
とする。幅20emの定規になる。
この長さを調整すると、h1の幅が18em未満の時にバグが出る。
以上はIEで 表示＞文字のサイズ＞中 にして確認した。
文字のサイズ小だと、親ボックスのwidthを決める要素（ここではh1要素）の横幅の長さが21em以上ある場合バグは起きない。
また、h1は短い文字数のままにしておいて、
input[type="search"] {width: 90%;}
に min-width:21em; を追記すると、検索入力欄の伸縮は起きなくなった。
min-widthの数値を20.6em未満にすると、バグは起きる。
>>587のバグの発生条件には、これも足すべきだった。
592:Name_Not_Found
19/01/16 03:27:21.38 .net
>>583
IE11のバグまとめ
特定のフォントでテキストの下に隙間が空く。
URLﾘﾝｸ(qiita.com)
「バグの現象としては、行間が膨れ上がった上にテキストの下に隙間ができるため、font-sizeが大きいほど顕著にズレが生じる。」
>>584
「Noto Sansを利用する場合はCJK jpをダウンロードして利用せずに、Noto Sans jp, Noto Sans JapaneseなどGoogle fonts経由で利用する場合は問題ないみたいです。」
593:Name_Not_Found
19/01/16 15:40:27.59 .net
>>587・>>588
バグの発生条件に下記は関係無かった。
>条件１
>・検索ボックスが、display: flex;（IEだとdisplay: -ms-flexbox;）を指定した祖先要素内にあり、フレックス・ボックスを継承。
>条件２
>・検索ボックスのinput要素にwidthを%単位でスタイル指定してある。
もっと単純に、placeholder属性へのfont-family指定だけで、検索入力欄の横幅が変に伸び縮みする。
要は、input要素とplaceholder属性とでfont-familyが異なると、バグる。
<style type="text/css">
:-ms-input-placeholder {
font-family: sans-serif;/*任意のフォントで試す*/
}
</style>
<body>
<input type="text" size="22" name="word" value="" placeholder="プレースホルダーです">
</body>
「プレースホルダーです」が10文字あり、size="20"で入力欄が10文字分の横幅に表示される。
これも>>591にある通りmin-width指定でフォーカス時の横幅の変化を防げる。
input[type="text"] {min-width: 21em;}
input要素でsize="30"と10増やすと、最小幅指定もmin-width: 31em;にしないとバグ抑止できなくなる。
size=""と空指定にした場合は、min-width: 21em;以上でバグは起きなくなった。
どのみち、指定されたフォント名次第でこの数値は上下するみたいで、不安定。
上記ソースではfont-family: system-ui;にするとバグは発生しないが、既にinput要素へのfont-family指定があると別。
プレースホルダーに対するfont-family指定自体を削除したい所だが、WordPressテーマ（twentysixteenとか）のstyle.cssでプレースホルダーへのスタイル指定がある場合等は難しい。
スタイル指定でwidthを決め打ちするのが良いかも。この場合、%指定でも可（flexを継承してないからか）。
594:Name_Not_Found
19/01/17 03:12:34.66 .net
>>593
font-family: system-ui;は、IE未対応らしい。
URLﾘﾝｸ(developer.mozilla.org)
で、プレースホルダーのフォント名が親要素であるinput要素と不一致なのがいけないんだから、
:-ms-input-placeholder {font-family: inherit;}
がバグ対処法になる。祖先要素からの継承を明示するわけ。
WordPressの場合はこれを子テーマのcssファイルで上書きすれば良し。
これで、入力フォームにカーソル入れると横幅が伸び縮みする不条理は避けられるはず。
595:Name_Not_Found
19/01/22 02:38:40.50 .net
>>583
>しかも、三点リーダー「…」なんかは欧文式にベースライン表示の「...」になる罠。
「三点リーダが真ん中に表示されない理由」
URLﾘﾝｸ(www.koikikukan.com)
「三点リーダ問題、webfontでついに解決！……か？」
URLﾘﾝｸ(orangeprose.)<)
「「三点リーダの表示位置」問題を完全かつ最終的に解決する」
URLﾘﾝｸ(d.nekoruri.jp)
U+2026の「…」ではなく、(U+22EF)の「⋯」を使うだけで真ん中に表示される日本人の大好きな三点リーダになります。
596:Name_Not_Found
19/01/22 19:34:51.02 .net
【IE・Firefoxバグ】InternetExplorer11、Firefox64、GoogleChrome71、をWindows8.1で確認。
font-familyプロパティが、@font-face内だと通常と違って和文フォントを英字名しか読み込まず日本語名を受けつけなくなる。
また特にFirefoxではファミリー名にウェイトを附けると認識しないことがある（>>585の逆）。フォント・ファイル名なら末尾に‘-weight名’が入っても可みたいだけど、それではChromeで反映しなくなる。
バグではなく仕様にしても、ブラウザ間の不一致がひどすぎて、使用するのに困惑する。
OS標準インストールの和文フォント名一覧とも微妙に齟齬する。
URLﾘﾝｸ(w3g.jp)
Webフォントでなくローカル・フォントに對して@font-face内font-familyでフォント・ファミリー名を上書きして複数まとめたりする手法（下記等）が、無為になる。
URLﾘﾝｸ(text.baldanders.info)
URLﾘﾝｸ(qiita.com)
URLﾘﾝｸ(qiita.com)
テストしたソースは以下。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<style type="text/css">
div {font-family: Tahoma, sans-serif; font-size:1.5rem;/*視認しやすくするため*/}
@font-face {font-family: "f01"; src: local("ＭＳ 明朝");}
.f01 {font-family:"f01";}
</style>
</head>
<body>
<div class="f01">永なふをQ9g桜咲く</div>
</body>
</html
上記"ＭＳ 明朝"の箇所に明朝体の日本語フォントを日本語名／英語名で代入して、日本語の表示がsans-serif（ゴシック体）でなくなるかを確かめた。
結果一覧は>>597
597:Name_Not_Found
19/01/22 19:35:40.93 .net
>>596のテスト結果
"ＭＳ 明朝" IE× FF× GC○
"MS Mincho" IE○ FF○ GC○
"游明朝" IE× FF× GC○
"Yu Mincho Regular" IE× FF○ GC×
"YuMincho-Regular" IE○ FF○ GC×
"Yu Mincho" IE○ FF× GC○
"YuMincho" IE× FF× GC×
"ヒラギノ明朝 ProN" IE× FF× GC○
"ヒラギノ明朝 ProN W3" IE× FF× GC×
"Hiragino Mincho ProN" IE× FF× GC○
"Hiragino Mincho ProN W3" IE○ FF× GC×
"HiraMinProN" IE× FF× GC×
"HiraMinProN-W3" IE○ FF○ GC×
"小塚明朝 Pr6N R" IE× FF× GC×
"小塚明朝 Pr6N" IE× FF× GC○
"Kozuka Mincho Pr6N" IE× FF× GC○
"Kozuka Mincho Pr6N R" IE○ FF× GC×
"KozMinPr6N-Regular" IE○ FF○ GC×
"KozMinPr6N" IEC× FFC× GC×
"Noto Serif CJK JP" IE○ FF○ GC○
"NotoSerifCJKjp-Regular" IE○ FF○ GC×
"NotoSerifCJKjp Regular" IE× FF× GC×
"Noto SerifCJK jp Regular" IE× FF× GC×
"源ノ明朝" IE× FF× GC○
"Source Han Serif" IE○ FF○ GC○
"SourceHanSerif-Regular" IE○ FF○ GC×
"IPAmj明朝" IE× FF× GC○
"IPAmjMincho" IE○ FF○ GC○
"IPAex明朝" IE× FF× GC○
"IPAexMincho" IE○ FF○ GC○
×印はフォント指定が表示に反映されなかったが、にも拘らず妙なことに、半角英数字の文字列だけはIEもFirefoxもTahomaでない別のフォントになった。しかもなぜかIEは総称フォントsans-serif指定を無視してserifの英数字になる。
598:Name_Not_Found
19/01/22 20:51:50.61 .net
>>596
URLﾘﾝｸ(www.tomotanuki.com)
「指定するフォント名は現段階ではブラウザによってまちまちです。
ChromeとOperaは「游ゴシック」「Yu Gothic」でも標準（Regular）を指定できたりします。
ですが、Firefoxでは「Yu Gothic Medium」と英語名+ウェイトで指定しなければなりません。
これは標準（Regular）でも同じで標準（Regular）サイズをFirefoxで指定したい場合は「Yu Gothic」ではなく「Yu Gothic Regular」と指定しなければ表示されません
(ちなみに「Yu Gothic Regular」で設定すると、ChromeとOperaとIE11では表示されません)。」
「Chromeの現バージョン ( 58.0.3029.110 (64-bit) ) で英語フォント名（Yu Gothic Medium）を認識しないようです。」
Hiragino Sansフォントウェイトのcss書き方まとめ
599:Name_Not_Found
19/01/22 20:53:37.04 .net
>>598
Hiragino Sansフォントウェイトのcss書き方まとめ
URLﾘﾝｸ(joppot.info)
URLﾘﾝｸ(hiragino.joppot.info)
600:Name_Not_Found
19/01/22 21:20:46.74 .net
>>596・>>597
>"Yu Mincho Regular" IE× FF○ GC×
>"YuMincho-Regular" IE○ FF○ GC×
>"Yu Mincho" IE○ FF× GC○
ChromeはPostScript Nameを認識できないので、Font Family Nameで指定しなければならない。
URLﾘﾝｸ(w3g.jp)
URLﾘﾝｸ(speakerdeck.com)
601:Name_Not_Found
19/01/22 22:08:14.28 .net
>>600
しかし"ＭＳ 明朝"のPostScript名は"MS-Mincho"らしいが、
Cf.「フォントのPostScript名, フルネーム, ファミリーの日本語名と英語名」URLﾘﾝｸ(taken.jp)
@font-face {font-family: "f01"; src: local("MS-Mincho");}
と指定しても、IE・Firefox・GoogleChromeどれも表示に反映されない。
602:Name_Not_Found
19/01/23 11:38:54.62 .net
>>601は誤り。"MS-Mincho"でIE・Firefoxに有効だった。
>>597
>"Noto Serif CJK JP" IE○ FF○ GC○
>"NotoSerifCJKjp-Regular" IE○ FF○ GC×
これがRegularでない他のウェイトだと、IEのみが認識するイレギュラーな結果になる。
"Noto Serif CJK JP Bold" IE○ FF× GC×
"NotoSerifCJKjp-Bold" IE○ FF× GC×
同じ形式で下記ではどのブラウザも読み込まないのに。
"Noto Serif CJK JP Regular" IE× FF× GC×
ダウンロード URLﾘﾝｸ(www.google.com)
Cf. URLﾘﾝｸ(qiita.com)
Google Fontsの'Noto Serif JP'も同様かね？
URLﾘﾝｸ(fonts.google.com)
603:Name_Not_Found
19/01/23 14:03:18.00 .net
>>596・>>597を整理して纏め直すと―
@face-fontのsrc記述子でlocal()構文を指定する場合
・使用可能なフォント名は、英文名のみ。
フォントの日本語名はIE・Firefox無効、Google Chromeしか認識しない。
・PostScript名はChrome不可、全く効かない。
・名にウェイトが含まれると、PostScript NameであれFull Nameであれ、Chrome不可。
Full NameはIEだとフォントのウェイト（Regular等）によっては不可。
Full NameはFirefoxだとフォント（ヒラギノ・小塚・Noto Serif CJK JP等）によっては駄目。
・ウェイトの含まれない英語フォント・ファミリー名だけにすると、Chromeに有効。
だがIE・FFで読み込まれないフォントもある（ヒラギノや小塚フォント等。游フォントはFFのみ不可）。
対策としては―
src: local("PostScript名"), /*IE・Firefox適用、Chrome無効*/
local("Weight抜きのFont Family名")/*Chrome向け*/;
としておくしかないか。
EdgeやMacやスマホは確認できないので、できる人よろしく。
604:Name_Not_Found
19/01/28 03:11:07.93 .net
バグではなく未対応だかららしいけど、混乱するので。
font-feature-settingsプロパティーは、ほぼ全てのブラウザが対応する。
URLﾘﾝｸ(caniuse.com)
URLﾘﾝｸ(developer.mozilla.org)
しかし。
font-feature-settingsを@font-face { }内で使用すると、Firefoxでしか有効でない罠。
URLﾘﾝｸ(developer.mozilla.org)
605:Name_Not_Found
19/01/29 11:53:41.59 .net
他のブラウザではfont-feature-settingsによる字詰めが有効なのに、IE11だけ無効。
font-familyに游明朝・游ゴシックを指定すると発症。
以下で再現。
.yu {font-family:"游明朝", YuMincho;}
<div class="yu" style="font-feature-settings : 'palt';">
くし」、「ト。りょうった
</div>
Firefox64、GoogleChrome71ではちゃんと字詰めされる。
IEでも、プロポーショナルメトリクス情報を持つ他のフォント（#）にするとpaltが効いたので、これはバグと言ってよいかと。
# "ヒラギノ明朝 ProN W3"・"小塚明朝 Pr6N'"・"IPAmj明朝"・"Source Han Sans"等
Cf. URLﾘﾝｸ(helpx.adobe.com)
606:Name_Not_Found
19/01/29 13:02:19.34 .net
>>605
游明朝のカーニング設定がうまくいかない話
URLﾘﾝｸ(qiita.com)
Mac (10.12.6)
■ Chrome(64)、Safari(11)、Firefox(58)
Boldとpknaを組み合わせると、カーニングが無効。
Windows(10)
■ IE11
Boldとpaltを組み合わせると、カーニングが無効。
Normalとpaltを組み合わせると、カーニングが無効。
URLﾘﾝｸ(bulan.co)
Mac OS SierraのChromeで游明朝体の文字詰めが効かなかったり
607:Name_Not_Found
19/01/29 13:10:52.41 .net
>>604
ここ↓、その@face-font内font-feature-settingsで嵌ってた。
「CSSで行頭の約物を半角にする」
URLﾘﾝｸ(dskd.jp)
608:Name_Not_Found
19/02/04 17:06:35.30 .net
【Firefox65／GoogleChrome71 バグ】
IE以外で、JIS外字を表示させるとfont-familyプロパティーで総称ファミリー名serifが効かなくなる。
Win8.1で確認。
p {font-family: "游明朝",serif;}
</p>「专」：ユニコード数値文字参照（16進数）→「&;#x4E13;」</p>
鉤括弧「 」内の外字部分だけゴシック体（sans-serif）になる。
FiefoxやChromeは、初期設定で明朝体 (Serif)は游明朝が既定。
それで游明朝に無い外字は他のフォントで表示されるため、ゴシックになると推定される。
しかしserifが無効になるのは指定に反する。
IE11だと他のフォントでも指定通りserifのフォントを選んでくれる（SimSun等の中国語フォントか？）。
総称ファミリーをsans-serifにすればIEでも全てゴシック体表示になったから、IEは正しく動作してる。
ついでに、総称ファミリーをcursiveやfantasyだけにすると―
p {font-family: cursive;}
IEでは、本文がゴシック体だが外字部分は明朝体のまま。
Firefox・Chromeでは、全てゴシック体。但しChromeでは半角英数字に変化あり。
しっかし、IEの方が正しい挙動をするのって珍しくないか。
大抵はIEが足を引っ張るのに。
Cf. URLﾘﾝｸ(pentan.info)
609:Name_Not_Found
19/02/04 17:09:42.04 .net
>>608
× 「&;#x4E13;」 &の後の「;」が不要。
○ 「专」
610:Name_Not_Found
19/02/10 18:52:31.49 .net
>>608
下記ソースで再テスト。
p {font-family:Tahoma,sans-serif;}
.f01 {font-family:"游明朝";}
<p>「专」：ユニコード数値文字参照（16進数）→「专」</p>
<p class="f01">「专」：ユニコード数値文字参照（16進数）→「专」</p>
IE11ではp.f01で「 」内がsans-serifを継承せずserif（游明朝ではない何かの明朝体）になった。
やはりIEは所詮IEで、対応に問題があるみたい。
Firefox65・GoogleChrome72では「 」内はsans-serif（ゴシック体）のまま。
611:Name_Not_Found
19/02/15 18:30:21.46 .net
>>602
>これがRegularでない他のウェイトだと、IEのみが認識するイレギュラーな結果になる。
>"Noto Serif CJK JP Bold" IE○ FF× GC×
>"NotoSerifCJKjp-Bold" IE○ FF× GC×
再現しない。下記の通りになった。
"Noto Serif CJK JP Bold" IE○ FF○ GC×
"NotoSerifCJKjp-Bold" IE○ FF○ GC×
Firefoxで反映しなかったのは、フォントキャッシュとかの問題では？
612:Name_Not_Found
19/02/20 18:38:10.24 .net
>>585
>しかしこれがヒラギノだと、
> font-family: "ヒラギノ明朝 ProN W6","HiraMinProN-W6";
>みたいに、ウェイトまでfont-family指定に入れられるんだけど。
否。ヒラギノでもフォント名にウェイト入れるとfont-family指定が反映されない。
Firefox65、GoogleChrome72、Windows8.1にて表示確認。
font-family: "Hiragino Mincho ProN W6"; /*無効*/
font-family: "ヒラギノ明朝 ProN W6"; /*無効*/
font-family: HiraMinProN-W6; /*無効*/
font-family: "Hiragino Mincho ProN","ヒラギノ明朝 ProN"; /*有効*/
IE11では日本語フォント名の"ヒラギノ明朝 ProN W6"と"ヒラギノ明朝 ProN"だけ有効だった。
613:Name_Not_Found
19/04/19 18:42:32.78 .net
>>551-553のwhite-space:nowrap;バグ、最新のChrome73になってもまだ直ってないのな。
WebKitのバグってどこに報告すれば修正してくれんのかね？
614:Name_Not_Found
19/06/10 21:00:12.09 .net
>>583
>フォント指定でヒラギノや游明朝・ゴシックや小塚明朝・ゴシックにするだけで文字の位置が上にズレ
>先頭に欧文フォント指定すればバグ回避できるけど、半角英数字は当然欧文フォントで表示され不統一に。
このＩＥバグは、ただ先頭に欧文フォントを指定しても、不具合は解消しない。同時に子要素の行間を小さく指定しないと。
下記ソースで確認。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>OpenTypeフォントのIE表示</title>
<style type="text/css">
.otf {background:#ff0; font-size:6em;/*視認しやくすくするため*/
font-family:"Times New Roman",'Kozuka Gothic Pr6N', 'Yu Gothic', 'Noto Sans Japanese', 'Source Han Sans';}
.otf * {border:1px solid red;/*視認しやすくするため*/
line-height:0.1;
white-space:nowrap;/*折り返すと行が重なるので*/}
</style>
</head>
<body>
<div class="otf"><span>壹貳</span>12<a>參肆</a>34</div>
</body></html>
line-heightの値は1.0より小さい方がよいみたい。
div.otf直下の和文フォント適用部分をインライン要素タグ（<del><ins>も可）で括れば、なぜか、文字が上下にはみ出る不具合はなくなる。
欧文フォント適用部分（半角英数字や記号類）は何も括らず剥き出しで直下に置いてよし。
しかし、divの中に<p>56</p>とかブロックレベル要素を入れるとまた隙間が空く。
.otf p * {line-height:10%;} と指定してから
<div class="otf"><p><a>56伍陸</a></p></div>
とインライン要素タグで括って中に半角英数や記号以外の日本語文字を入れると、直る。
615:Name_Not_Found
19/06/11 03:14:20.67 .net
>>614
＞.otf p * {line-height:10%;} と指定してから
これは不要だな。既に、全称セレクター*で".otf p * "に対しline-height:10%;を指定済みだから。
必要なのは、第一に、p直下の日本語文字列をインライン要素としてタグ附けすること。
それと、表示させるフォントによって{line-heightの値は上下して調整ねばならず、1.0より大きい方がいいことも。
でもボックス下部に余白が空くから、.otf , .otf * {height:1.2em;}とか、.otf p {margin:0;}とか、追記すべし。
IE11のバグまとめ > 特定のフォントでテキストの下に隙間が空く。
URLﾘﾝｸ(qiita.com)
「line-heightを限りなく0に近い数値にすることでズレを回避できますが、改行した瞬間に文字が重なって終わるので現実的な解決策ではありません。」
↑これも、line-height:1%;とかやっても利き目なかったけど、font-family先頭の欧文フォント指定と掛け合せた上で２バイト文字列のどれかを<span> </span>で挟めば、行高設定次第でずれ解消が有効になるはず。
616:Name_Not_Found
19/06/11 03:50:16.31 .net
>>560 - >>565
Windows8.1+IE11
・「font-family:"欧文フォント", "和文フォント";」とすると、和文フォントの指定が一切無視される。
↑これ、全く再現しないね。
font-family:Arial, 'MS Mincho';
とか
font-family:Arial, 'Yu Mincho';
とかで試したけど、ちゃんと日本語の部分は日本語フォントで描画される。
総称ファミリー名のserifを末尾に指定するかどうかも関係無し。
なんか、間違ったのか？
617:Name_Not_Found
19/06/15 08:07:04.60 .net
これはCSSのバグなのかどうか……。
InternetExplorer11／Windows8.1で確認。
・フォント・サイズをその要素の横幅以上に拡大すると、IVS（＝基底文字＋VS）のVSが文字化けする。
IVS（異体字シークエンス）は、「通常の文字と同様、数値文字参照を使って書くこともできる。フォントやOS、アプリケーションが対応していない場合には、通常の基底文字のグリフが単に表示される（ことが望まれるが、VSが豆腐などで表示されてしまうことが多い）。」
URLﾘﾝｸ(shiromoji.hatenablog.jp)
ところが、別に「・」や「□」（豆腐）に化けてなかった文字も、フォント・サイズを一定以上に大きくすると四角になることがある。
下記一行のソースで再現できた。
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
どうもIE11はIVSを「基底文字＋VS」で２文字と計算するらしく、
それで要素の横幅がフォント・サイズ１文字分（1em）より小さいと、１文字はみ出たVSの分だけ文字化けして表示され、基底文字の下に流れて配置される。
width指定で要素の幅がfont-sizeより広く取ってあっても、box-sizing: content-box;（既定）の場合にpaddingとかborderを入れると、この不具合が発現したりする。
floatでwidtj指定を入れる場合にも、注意↓。
実例 URLﾘﾝｸ(wakufactory.jp)
Firefox67やChrome75では再現しなかった。
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。
618:Name_Not_Found
19/06/15 08:10:00.98 .net
>>617 追記修正
<div style="font-size:51px; width:50px;">逸󠄁／齋󠄁</div>
ただ上記一行のソースは、Firefoxでは、
逸󠄁／
齋󠄁
と２行に表示され、他方、Chromeでは、
逸󠄁
／
齋󠄁
と３行に表示された。
「／」を「―」「■」等の記号に変更しても同様。
619:Name_Not_Found
19/06/22 07:25:22.77 .net
font-familyプロパティーの値でインストールされてないフォントのみを指定された場合、継承値を反映しなくなる難があるが、
値の末尾に総称ファミリー名の代りにinheritを指定すると、
Chrome・Firefoxでは継承値で表示されて問題は解消するものの、Internet Explorer 11では無効のまま。
環境はWindows8.1で確認。
body {font-family: YuMincho, '游明朝', serif;}
<p>例１：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝'">馬酔木明朝</span>」ってフォントがある。</p>
<p>例２：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit;">馬酔木明朝</span>」ってフォントがある。</p>
<p>例３：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit, serif;">馬酔木明朝</span>」ってフォントがある。</p>
上記ソースで、本文は游明朝（それが無ければ他の明朝体）になるが、例１の"馬酔木明朝"の文字列はゴシック体になった。
例２でスタイル設定値にinheritを足すと、Chrome75とFirefox67では游明朝になったがIE11ではゴシック体のまま。
例３で値の末尾に更に総称ファミリー名serifを追記すると、IE11だけ游明朝でなく'ＭＳ 明朝'になった。
但し、CSS仕様書を見ると、font-familyプロパティーにおけるグローバル値inheritは、フォントファミリー名や総称ファミリー名とは併記できないらしい。
Cf.「Cascading Style Sheets Level 2 Revision 2 (CSS 2.2) Specification 日本語訳」
15.3 フォントファミリー：'font-family'プロパティ
URLﾘﾝｸ(momdo.github.io)
ならば厳密にはスタイルシートのバグではなくてブラウザーごとの仕様なのか？
あと、「馬酔木明朝」は下記で無料配布。
URLﾘﾝｸ(metasta.github.io)
620:Name_Not_Found
19/06/22 08:24:16.07 .net
>>619
＞値の末尾に総称ファミリー名の代りにinheritを指定すると、
＞Chrome・Firefoxでは継承値で表示されて問題は解消する
これは指定したinheritの値が有効になったってよりも、
inheritとフォント・ファミリー名との両方を値に記すこと自体が不正で無効（invalid）な書き方だから、
font-family指定そのものが無効になって、親要素bodyへの指定だけが有効になりその値を継承した
―と解釈される。
その証拠にFirefoxでは、body {'MS PMincho'}とかプロポーショナル・フォントを指定した上で
<p>例４：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', inherit, monospace;">馬酔木明朝</span>」ってフォントがある。</p>
<p>例５：フリーの「<span style="font-family: 'Asebi Mincho Light','馬酔木明朝', monospace, inherit;">馬酔木明朝</span>」ってフォントがある。</p>
とか総称フォント名をmonospaceにしても、等幅フォントで表示されなかったし、
<p>例６：Win8.1以降標準装備の「<span style="font-family: YuMincho,'游明朝','Yu Mincho', inherit;">游明朝</span>」ってフォントがある。</p>
とか、インストール済みのフォントファミリー名を指定しても無効になった。
IEは、値の不正な記述の仕方（「不正な値」の指定ではない）でもプロパティーそのものは無効にならない点では、バグである。
621:Name_Not_Found
19/06/22 08:32:00.85 .net
>>620修正
＞body {'MS PMincho'}
body {font-family: 'MS PMincho';}
622:Name_Not_Found
22/12/16 23:35:39.75 .net
>>551
>>551-553 報告のChrome30でのCSSバグは
マイナー極まるブラウザ、Falkon Version 3.1.0 でも再現する。
hrURLﾘﾝｸ(falkon.org)<)
とすると、iPhoneではSafari以外のブラウザでもWebKit特有の問題が発生するのかも。
623:Name_Not_Found
22/12/17 00:16:31.58 .net
>>622
Falkonのバグ対策（の失敗）について。
>>551の例で実験。
/* WebKit HackでGoogleChrome30とSafari5とOpera15+対策 */
@media screen and (-webkit-min-device-pixel-ratio:0){
.navbar a {white-space:pre-wrap;}
} /* Falkonにも効く。 */
@-moz-document url-prefix() {/* Firefoxで元の指定に戻す */
.navbar a {white-space:nowrap;}
} /* Falkonには無効、ここまでバグ発生せず。 */
/* Chrome39+ハックで新Chromeや新Edgeも元の指定に戻す */
_:lang(x)::-internal-media-controls-overlay-cast-button, .navbar a {
white-space:nowrap;
} /* 新ChromeだけでなくFalkonにも効いてしまった！ バグが再生。 */
624:Name_Not_Found
22/12/18 16:26:42.99 .net
>>622
>>551のバグは、Falkon3.1では、下記を追記すると発生しなくなった。
@media screen and (-webkit-min-device-pixel-ratio:0){
.navbar a {display:inline-block;}
}
要は、折返し禁止（white-space:nowrap;）にするa要素をインラインブロックとして扱ったら、まともにレンダリングしてくれるみたい。
上記WebKitハックによるスタイル指定は、GoogleChrome最新版（バージョン: 108.0.5359.125）でも適用されるものの、指定しない時と比べて特に変化は起きない模様。
625:Name_Not_Found
22/12/18 18:17:57.17 EoAW88W9.net
>>622
CSSではないけど、そもそもFalkonは行中での折返し（改行）をするアルゴリズムが何かヘン。
非表示のゼロ幅スペース（​ U+200B）を挟んでも、そこで折り返してくれない。
HTMLソースで改行してあると、そこがブラウザ表示でも改行できる位置になる。
ちなみにゼロ幅スペースを入れた直後にソースで改行すると、
ChromeやFirefoxと違ってFalkonの表示ではドット一箇分ほどの幅の隙間が空く。ゼロ幅にならない！
<wbr>タグには対応してるから、そっちを使用すればいいのかもしれんが。
626:Name_Not_Found
22/12/18 18:35:49.47 .net
>>626
↓こんなソースで比較してみると。
<h1><a href="">■</a>大見出し１</h1>
<h1><a href="">■</a>
大見出し２</h1>
<h1><a href="">■</a>​
大見出し３</h1>
Chrome108/Firefox108での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■大見出し３ ←前行末にゼロ幅スペースがあるとソース改行による空白が打ち消される。
Falkon3.1.0での表示
■大見出し１
■ 大見出し２ ←■の後に一文字の三分の一程の幅のスペースが空く。
■ 大見出し３ ←前行末にゼロ幅スペースがあってもソース改行による空白が打ち消されない。
627:Name_Not_Found
23/09/20 18:01:30.13 .net
正しいことをやりましょう