Google Chrome だけレイアウトがおかしいので調べてみると、どうやら最小フォントサイズという設定で 10px 以上に制限されているようです。わざわざこれを変更して見てくれる人はいないので、サイトデザインの時点でフォントサイズは 10px 以上に制限しておいた方が良さそうですね。
この設定は「設定 → 詳細設定を表示 →（ウェブ コンテンツ）フォントをカスタマイズ」にあります。こういう設定は無いほうがいいと思うけど、それをサイト閲覧者に求めるのも違うと思います。社内ウェブアプリケーションなら設定してもらうのもアリだけど、そもそもその用途じゃ余計 10px なんていらないし、やっぱり変な制限は付けなくていい。Google Chrome のほうがおかしいと思います。
このブログのランキングページを作るのに、1st、2nd、3rd などと序数標識の付いたリストスタイルを（ネットに落ちていなかったので）作成してみました。説明が面倒なので定義を見て欲しいのですが、before 疑似要素と nth-child 疑似クラスをうまく組み合わせて実現しています。今まで、1～3だけ特別なのかと思っていましたが、その後は同様に下１桁が1～3のとき（11～13を除く）以外は「th」になります。
ol.ranking {
counter-reset: number;
list-style: none;
margin: 0;
padding: 0;
}
ol.ranking li {
padding-left: 3em;
text-indent: -3em;
}
ol.ranking > li::before {
counter-increment:number;
display: inline-block;
width: 2.5em;
text-align: right;
margin-right: 0.5em;
}
ol.ranking > li:nth-child(n)::before { content:counter(number)"th"; }
ol.ranking > li:nth-child(1)::before,
ol.ranking > li:nth-child(10n+21)::before { content:counter(number)"st"; }
ol.ranking > li:nth-child(2)::before,
ol.ranking > li:nth-child(10n+22)::before { content:counter(number)"nd"; }
ol.ranking > li:nth-child(3)::before,
ol.ranking > li:nth-child(10n+23)::before { content:counter(number)"rd"; }
まだ、数字の位置が揃っていないのが気になりますが、この辺りが CSS の限界のようです。もし、content を二重にしたり、その中にタグを入れられたりできれば、もう少しマシにできると思います。数字の位置で縦を揃える方法、序数標識を上付き数字にする方法、これらが分かる人はコメントください（タグでゴリゴリ書くのはナシで）。
以下に使用例（Wikipedia より）を示しますが、このブログのオリジナルサイトでしか表示されないと思います。
前来たときは忙しくてブチ切りしたけど、今回は付き合ってあげました。最初何て言ったか（名乗ったかも含めて）覚えて無いけど、「電話番号データベースから自動音声で掛けている」みたいな案内の後、いくつかの質問があって終わりました。
はい、どこの調査なのか分かりませんでしたが、少し安倍政権の支持率向上に貢献致しました。たぶん聞き逃しじゃなく、名乗らなかったと思うんですが、こういう調査ってそういうもんでしょうか？ ちなみに、相手の電話番号も「非通知」でしたので、逆探もできません。
Google Analytics の言語レポートに、下記のリファラスパムらしきアクセスが記録されていたので、調べてみました。通常この部分は「ja」とか言語コードしか来ないのですが、ここに興味を惹くような文を入れて不正サイトへアクセスさせようとするのが目的です。
Secret.?oogle.com You are invited! Enter only with this ticket URL. Copy it. Vote for Trump!
「？」になっている部分は U+0262 の「G」に見える文字コードが入っています。従って、注意していないと一見 Google の URL に見えるサイトに誘導されることになります。
この攻撃のターゲットは、Google Analytics を導入していて、ある程度アクセス数のあるサイトの管理者、ということになり非常に巧妙な手法です。うちみたいな少ないアクセス数のサイトにも来ているのは謎ですが、企業とかのシステム管理者が引っかかったら、システムの深いところまで侵入される糸口になるかも知れません。これなら、何の権限もない一般人を初めから除外できるので都合が良いのでしょう。
PCRE 修飾子で「s」を指定した場合「ドットメタ文字は改行を含むすべての文字にマッチします」、「 これを設定しない場合は、改行にはマッチしません」とあります。例えば「/^(.+)$/m」のように書けば、複数行テキストを配列に取ることができるはずなのですが、実際やってみると改行を含むテキストが返ってきます。対処法で trim を掛けたりしていましたが、せっかくなので調べてみました。
改行の種類として「LF」「CR+LF」「CR」の３種類があると思いますが、実際にテストコードを書いてみたところ、ドットメタ文字は「CR」にマッチし「LF」にマッチしませんでした。マニュアルには単に「改行」と書かれているので、これらのすべてに対応しているものと思い込んでおりましたが、違うようです。従って、上の例で改行に見えていたのは「CR+LF」の「CR」が残っていたものと思われます。
原因が分かれば話は簡単で、文字クラスの否定を使って「CR」及び「LF」を指定すれば良いだけです。
preg_match_all('/[^\r\n]+/m', $text, $match);
マニュアルなどで単に「改行」と言った場合は「LF」のみを指すと思って良さそうです。プログラム書くときも特に意識しないで "\n" を使ってますし、UNIX 系では「LF」なのだから当然と言えば当然でした。毎回悩むのもアレなので、改行テキストを綺麗な配列に取る関数を自作しておくと楽かも知れません。
要注意なのは、HTML の改行コードが「CR+LF」で規定されている点です。このため、textarea で POST されたデータは「CR+LF」になっており、取り扱う際に注意しなければなりません。また、PHP などで HTML を出力する際の改行コードを「LF」のみとしてしまうのは、本来間違いということになります（今まで結構やってたなあ）。多くの場合、「LF」で出力しても、「CR+LF」「LF」が混在していてもブラウザの表示には影響しませんが、気になる方は HTML は「CR+LF」と覚えておくといいかも知れません。