Hatena::ブログ(Diary)

Webデザインの日々日記 RSSフィード

2016-09-23

floatで並べていたタイルをflexboxで書き直す

タイルレイアウトをfloatで実現するにはタイルの高さをそろえるためにheightを固定するとかしなきゃいけない。

WordPressみたいに記事からタイトルとサムネイルを取り出して並べる場合はタイルの中身がはみ出すというトラブルによく遭遇する。何でそんな縦に長い写真を使ってるんだとかお前タイトル長すぎだろうとかそういうのが原因。

仕方がないので、height固定はあきらめてmin-heightである程度高さを持たせてレイアウトすることが多い。

そんなことをやっていたのは1年ほど前までで、IE8も9も公式には存在しないことになっている今となってはflexboxレイアウトを導入することができるよねと。

で、これまでfloatで配置していたものをflexで書き換えるにはどうするかと。

このとき、heightではなくmin-heightで調整していたのなら簡単で、並べているタイルの一群をラップするdiv箱を作って、そこにflexboxのプロパティを設定するだけでよい。

例えばラップするdivのクラス名を"flex"とした場合、CSSには以下の記述を追加する。

.flex {	
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display: flex;
  align-items: stretch;
  -webkit-flex-direction: row;
  -ms-flex-direction: row;
  flex-direction: row;
  -webkit-flex-wrap: wrap;
  -ms-flex-wrap: wrap;
  flex-wrap: wrap;
}

webkit系のベンダープレフィクスはもう要らないかも。

子要素の幅の調整とかは従来floatで行っていたwidthの値がそのまま生きるから気にしなくていい。

また、子要素にfloatの指定が残っていても、flexboxの方が優先される。つまりfloat: left;で、親要素に flex-direction: row-reverse; がある場合、子要素は右詰めで並ぶ。

floatとの混在はあまりきれいなものとは言えないかもしれないが、IE9以下がしぶとく使われそうな日本の状況では残しておくとレガシー対応となってよい感じになる。

新規に作る場合でレガシー対応せざるを得ない場合

デバッグ済みのフレームワークを使う。bootstrapとかは重くて扱いにくいのでKomitsuboshi-cssを使っている。自分で作るのは大変だけどかなり勉強になる。

IE8,9でもmatchheight.jsを使えばflexboxみたいに高さを合わせることができる。ただしdisplay:none;してる要素の高さも計算するらしいのでその点は注意が必要。

「時代遅れになるUX」ってのはUXの話じゃ無いんじゃね?

UX論は間違っているんじゃなくて時代遅れなんじゃないの?という疑問 - architecture_database

そもそもUXって、「時代遅れになる」ような代物じゃないだろうと。「事業計画の立案は時代遅れになる」なんてことを言っているようなものである。

UXってのは「お客さんの体験」であり、UX論は「お客さんにどんな体験をしてもらうのか」って話。

UXを提供するのも、UXを考えるのも、そこら辺のお店の店員がずーっとやってきてる。時代遅れも何も、商売の基本だよね。物やサービスを売ることって、流行したり廃れたりするものなの? 経済の土台とともに存在しているんだから、これが「時代遅れ」になるってのは、経済そのものが終わってからの話になるんじゃないだろうか。

そもそもUXってのはお客さんにどうやって物事を提供するのかを改めて考え抜きましょうよと言う話であって、本質的には事業者が日常やっていることでしかない。

だからこそあなたも私もUXデザイナー、社長も下っ端もみんな「UX」考えましょうということになる。

もしかしたら、「UXデザイナー」なんてなじみのないオシャンティな名前が壁になって、関係者を巻き込めない、なんてことになっているかもしれない。そういう視点からは、「『UX』という単語で事業の見直しを行うのは悪手になりつつある。」ということは言えるかもしれない。


「退会させない設計」やソシャゲのガチャ設計の問題は、それが劣悪であるというだけでそれが「UX」であることに間違いはない。その事業者はそういう選択をしたというだけのこと。

射幸性の高い設計を好むかどうかはユーザー次第であり、高い射幸性を求めるユーザーを満足させたいUX設計が他のタイプのユーザーに不適切であるのは当然のこと。万人を満足させるUX設計は無い。

そして違法性や倫理性の問題はUX以前に考えることでありUXの話ではない。「UXデザイナーは法律への対応もしてくれるのか」なんてのは、物理の授業で「国語は教えてくれないの?」と言うようなものである。日本語で教えているからと言って物理の授業で国語も教えるべきなどと言うのはただの暴論である。



ここまで書いておいてこんなことを言うのもなんだが、私はUXにはあまり関心がない。なので上で書いている「UXって要は客の『体験』を考え抜いた設計だろ?」という私の解釈が正しいというつもりはない。しかしあれもこれもUXと言うのであれば、それは「事業」という日本語で適切に代替できる。改めて名前など与えなくても、みなすでに真剣に考えていることである。それを新しいことのように解釈することにどれだけの意味があるのだろう?

2016-09-07

「プロが実践するモダン CSS の書き方入門テクニック20選まとめ」を補足

プロが実践するモダン CSS の書き方入門テクニック20選まとめ - PhotoshopVIP

1. 縦方向のマージン

他のプロパティとは異なり、縦方向のマージン幅はうまく効きません。

「うまく効かない」ではなく「相殺される」「重複する」と訳すべきでしょうね。

横方向のマージンは単純に足していけばよい一方、縦方向のマージンは相殺(重複)されるのが仕様です。

この特性が余白に関して想定していない問題を発生させることはよくあります。その代表的な例を2つ紹介します。

親要素にマージン・パディング・ボーダーがなく、子要素にマージンが設定されている場合、子要素のマージンが親要素のマージンに見える

例えば、

<header><h1>タイトル</h1></header>

というコードで、headerのmargin-top、padding-top、border-topが0で、h1にmargin-topがある場合、headerの上にh1のマージンが設けられます。

ここでheaderに背景色を設定していると、headerの上に白い余白が発生します。

「なんだこの余白?」と思ってデバッグしようとするとheader内にあるすべての要素のmargin-topの設定を確認しなければならず、面倒くさいことになります。

ボックス要素が入れ子になっているときに、縦方向に想定以上の余白が発生する

親要素にpadding-top, border-topがない場合、親要素のmargin-topと子要素のmargin-topは相殺されます。

一方、親要素にpadding-topまたはborder-topがある場合、子要素のmargin-topは、親要素のcontentから計算されます。その結果、親要素のmargin-topと子要素のmargin-topは相殺されなくなります。

この時、親要素に背景やborder-topがない場合、子要素の上の余白が妙に広く見えることになります。


margin-topを原則0にして、margin-bottomで縦方向のマージンを制御する方法は、これらの問題の回避に有効です。

2. レイアウトに Flexbox

日本では古いIEがしぶとく生き残る傾向があるので、Flexboxの活用はもうしばらく先のことになりますね。

jQueryライブラリmatchHeight.jsを使うことで、floatを使いながらもカラムの高さをそろえることができます。

また、横方向の等幅分割を実現する際には、Flexboxよりもdisplay: table; table-layout: fixed;を使う方がブラウザ間の差異をなくすことができます。

新しいプロパティを活用するのはウェブデザインの楽しみの一つですが、安定した「枯れた」テクニックを活用するのもプロに求められる資質ではないかと思います。

3. CSS リセット, 4. Border-box をすべてに適用

原則的に既存のライブラリを使うべきです。元記事では全称セレクタを使ったやり方が紹介されていますが、これは基本的にバッドノウハウです。(言い切っていいのか?)

全称セレクタを使ってよいのは box-sizing: border-box; くらいで、他のプロパティを全称セレクタでリセットするのは継承が失われる副作用の方が強いので避けた方がよいです。

5. イメージファイルは背景に適用するべきではない

なぜimg要素の代わりにbackground-imageを使ってはいけないのか。

理由の筆頭は、「アクセシブルではないから」です。背景画像にはalt属性を付けることができません。装飾以外の機能を持たない画像ならともかく、メインコンテンツの一つとして画像があるのなら、このようなテクニックの採用は即却下すべきです。

アクセシブルではないサイトは、SEOの面で不利になります。

また、この方法は空divというあまり褒められないコードが増えるため、この点でも評価は下がるでしょう。

これらの問題を解決するために、背景画像を用意したdiv要素内にalt属性にあたる解説文を付けるという方法もあるかもしれません。しかしその文字は画像の上に被って表示されます。alt属性の代替とするには text-indent: -120%; overflow: hidden; なんて方法を使わなければなりません。(今はどうかわかりませんが)MacOSChromeだとこれでも1文字だけは表示されます。そしてGoogle検索エンジンは隠しテキストと判断してやはりサイトの評価を下げるでしょう。

元記事にはこの点への言及があるものの、翻訳記事の方でこの重要なポイントをばっさり削除してしまっています。

その結果、まったく褒められない行為を推奨する記事と化してしまったことは残念なことです。

レスポンシブデザインに対応するなら、次の方法が最も簡便に行えます。

画像にはheight: auto; を活用する。

例えば、画像の幅をウィンドウ幅の50%にして、縦横比を元画像と同じにしたいときはこうします。

img {
  width: 50%;
  height: auto;
}

これだけです。わざわざdivを用意して、それぞれに高さ、幅を付けて、背景画像を用意して、なんて面倒なことは不要です。

十分なサイズ(表示したいサイズの2〜3倍の解像度)の画像を用意すれば、スマートフォンのような高精細ディスプレイでもきれいに表示されます。

十分なサイズの画像が用意できず、width: 50%; では画像が引き延ばされてぼやけてしまう場合は次のようにします。

img {
  width: auto;
  max-width: 50%;
  height: auto;
}

これで画像は元サイズ以上に引き延ばされることはなくなります。

6. リストテーブル

まあ、border-collapse: collapse; は基本ですね。ここではレスポンシブ対応について補足します。

テーブル要素のレスポンシブ対応

ちょっと気になるのは、「リスト用テーブル」ってところでしょうか。リスト目的ならdl要素を使うのがセマンティックにできると思います。

もっとも、dlは枠線のコントロールなどが少し面倒になるので、十分な時間がない場合はtableの利用もありうるでしょう。タイトル部にthを、説明部にはtdを使えばそれなりに意味は通ります。

さて、タイトルと説明、というような2列しかないテーブルをレスポンシブデザインに対応させるときには、displayプロパティを活用します。

ブレイクポイントを通過したところで、th, td 要素に display: block;を適用すると、横並びの表組を崩して縦に並べることができます。

リスト用ではなく、本来の意味での表組で、横並びを崩すことができない場合は、tableをdivで囲み、

div {
  width: 100%;
  overflow-x: scroll;
}
table {
  width: 100%;
  min-width: 640px;
}

のようにして、一定の幅を下回ると(上記の場合640px)表のみ横スクロールが発生するようにします。

7. 読みやすいコメントを記述しよう。

あと、CSSの冒頭にコメントアウトで目次を付けるのも有用です。

8. クラス名に「串刺しスタイル」を利用

WordPressのCSSコーディング基準はそうなってますが、それが絶対ということはありません。

私もハイフンつなぎを好んで使っていますが、みんな好きにすればいいんじゃないですかね。MindeBEMdingなんてハイフン2個とアンダースコア2個なんて気持ち悪い感じ(いまだに慣れません)でやってますし。

とはいえ、アンダースコアは、ハイフンに比べて2つの点で劣ります。

一つ目は、アンダースコアはハイフンに比べて目立たず、存在を見つけにくいという点。

二つ目は、タイプ時にShiftキーとの組み合わせが必要で、かつキーボードホームポジションから最も遠いためタイプミスを犯しやすいことです。

そのほか、相性面での問題として、WordPressの場合、コーディング基準に違反することになります。また、Bootstrapなどの主要なフレームワークの多くはハイフンつなぎなので、それらと組み合わせると命名に規則性がなくなり、メンテナンス性が悪化します。この相性問題はキャメルケースを使った場合も同様です。

9. 繰り返しを避けよう。

補足は必要ないですね。

特にフォント回り(font-family, font-size, line-heigt)に関してはhtmlかbodyで初期値を設定します。

これを全称セレクタ(*)に適用してしまった場合は地獄を見ることになります。

その他

10〜20は大きく補足するようなことはないかなと。

14. 大文字

CSSで制御すべきなのでしょうか。状況次第のような気がします。

元サイトでは「賛同できない。セマンティックにやるなら<em>を使うべき。」とのコメントが寄せられていますね。

15. rem

remは、IE9,10ではショートハンドでは使えないという制限があります。

元記事において

pxはもっとも正確性がありますが、レスポンシブデザインでは拡大縮小スケールに対応していません。

とあるのですが「拡大縮小スケールに対応していない」というのがよく分からないですね。普通にctrl+マウスホイールでレスポンシブに拡大縮小できるので。

一方、IEではpxで指定した場合、メニューから「文字サイズの変更」を行っても文字サイズが変わらないという問題があります。それゆえアクセシビリティ/ユーザビリティ界隈ではpxの使用を避けるように言われているのですが、メニューから文字サイズの変更を選ぶ人ってどのくらいいるんでしょうね。

HTMLにfont-size: 10px;として、文字サイズをremで指定すると計算しやすくてよいかもしれません。

16. 大きなプロジェクト

Sassは書き方がCSSに近いため、学習コストが低いのが特徴です。まだ試してない人はさっさと導入しましょう。

大きいプロジェクトであれば、Sassの他にコードの可読性を上げるCSSCombの利用も重要だと思います。主要なテキストエディタのほとんどで利用可能です。

18. 圧縮コードの利用

私は圧縮コード(ミニファイ)には否定的な見解を持っています。画像などと異なりもともと大したファイルサイズではないですし、改行コードやスペースを削除したところで大幅にファイルサイズが減るわけじゃありません。

読み込み時間を改善するのなら、まず読み込むファイルの数を減らすのが先だろうと思います。CSSやjsファイルはなるべく一つにまとめる、CSSで代替できる箇所には画像を使わない、WordPressであればプラグインを入れすぎていないかなど、検証すべきところは多々あります。

本気で取り組むならgzip圧縮やCDNの活用の方がはるかに効果的でしょう。

また、CSSフレームワークではBootstrapが人気ですが、これは(CSSファイルにしては)巨大で、しかもその機能の7割くらいは使われず無駄になっています。またBootstrapのグリッドシステムはその構造上、HTMLの肥大化を招きやすい問題(グリッド間の余白を作るのに内部にdivを追加する必要があるなど)を抱えています。

読み込み時間を短くしたいのならまずは上記のような無駄をそぎ落とすのが先であって、それらをやったうえで、1バイトでも無駄を削り切りたいときにミニファイは行うべきだろうと思います。

2016-08-07

作成したWordPressテーマの国際化(i18n)対応方法

もっとも簡単な方法をメモ

普通に調べるとコマンドラインがどうたらこうたらとか難しい話が出てきたり、Poeditのバージョンが上がってUIが少し変わっていて戸惑ったので忘れないようにメモ。

※以下、WordPressテーマは"ki-orion"という名称を例にしています。

国際化手順

0 Poeditのインストールとベースになるpotファイルのダウンロード

コマンドラインとかはまだ使えないんでGUIツールを使います。

Poeditのダウンロード

有料版の方がWordPress対応が優れているそうですが、手間をかければ無料版でも使えます。本記事は無料版での手順になります。

Poedit - Gettext Translations Editor

インストール手順は省きます。普通にやれば普通にインストールされますので。

WordPressのpotファイルのダウンロード

GitHub - fxbenard/Blank-WordPress-Pot: Blank-WordPress-Pot is the starter pot file to include in your language folder

緑の「clone or download」のボタンでzipファイルをダウンロード、ローカルで展開。

参考:WordPress プラグイン・テーマ翻訳: Poedit 無料版で新規 POT ファイルを作成する | ja.naoko.cc

1 テーマのフォルダに languages というフォルダを作り、potファイルを設置。
  1. 作成したテーマのテーマフォルダ直下に"languages"という名前のフォルダを作成。
  2. このフォルダに先ほどダウンロードした「Blank-WordPress.pot」ファイルを複製。
  3. 複製したBlank-WordPress.potの名前をテキストドメインの名前に変更。

今回のテーマの場合、Blank-WordPress.pot を ki-orion.pot に変更。

2 テーマのstyle.css/プラグインのコメントヘッダーにテキストドメインの情報を書く。

テーマの場合

Theme name: ki-orion
 (中略)
Text Domain: ki-orion

テキストドメインはテーマ名と同じにする方がよいらしいです。

また、テーマの名前は他の人が作って公開しているテーマと重複していないか、公式ディレクトリで検索して確認しておくことが必要。

3 テーマの日本語部分をすべて国際化関数に変更する。

Poeditは翻訳用コードを抽出して辞書ファイルを作るので、テーマやプラグインは翻訳以外は完成している必要があります。

国際化関数の書き方(テキストドメインがki-orionの場合を例に)

翻訳結果を出力する場合: <?php esc_html_e('words','ki-orion');?>

変数に入れる、関数内で使用する場合: <?php esc_html__('words','ki-orion');?>

※単に <?php _e('words','ki-orion');> や <?php __('words','ki-orion');> でもOKだが、セキュリティ強化のためエスケープをかけておく。

4 potファイルの設定変更

potファイルを開く。

f:id:k3akinori:20160806232440p:image

メニューの「カタログ」→「設定」を選択。

f:id:k3akinori:20160806232442p:image

「プロジェクト名とバージョン」、「翻訳チーム」、「翻訳チームのメールアドレス」を適宜変更。プロジェクト名はテーマのドメイン名(テーマ名)にする。

文字コードは「UTF-8」。これはデフォルトで選択されているはず。

「更新する」ボタンをクリック。

ソーステキストが検索され、表示される。

「保存」ボタンで保存。

5 jp.poファイルの作成

メニューの「ファイル」→「名前を付けて保存」をクリック。

保存画面でファイル名を「jp.po」に変更して保存。(ファイルの種類ではpotしか選択できないように見えるが無視する。)

6 jp.poファイルの編集

一旦Poeditを終了し、再度立ち上げ。

f:id:k3akinori:20160806232444p:image

「翻訳言語がソース言語と同一です。」のアラートが出るので、「言語を修正」ボタンをクリックして言語を「日本語」に修正する。

複数形の項目は「この言語のデフォルトルールを使う」を選択。

日本語はスクロールバーを一番下までもっていくと出てくる。

「OK」ボタンを押すと翻訳が可能になる。

f:id:k3akinori:20160806232446p:image

ペインに表示される「翻訳の提案:」に適当なものがあればそれをクリック。

f:id:k3akinori:20160806232447p:image

無ければ「翻訳」欄に自分で入力する。

もしも「未確定」ボタンが有効になっていた場合、

f:id:k3akinori:20160806232448p:image

「未確定」ボタンを押して未確定状態を解除する。(翻訳が確定していないと反映されない)

7 jp.moファイルの作成

デフォルトの設定ならこのまま「保存」を押すとmoファイルが自動的に生成される。

メニューの「ファイル」→「MOにコンパイル」をクリックしても生成することができる。

参考URL,文献

2014年版: WordPress プラグイン・テーマの翻訳を始めてみよう | ja.naoko.cc

WordPress プラグイン・テーマ翻訳: Poedit 無料版で新規 POT ファイルを作成する | ja.naoko.cc

ふじこのプログラミング奮闘記 - Wordpressで翻訳が反映されない場合のチェックリスト

2016-07-23

Re:知らないと恥ずかしい。今さら聞けない、読みにくいタグ用語15選。

別に読めなくても恥ずかしくはない。

【HTML&CSS】知らないと恥ずかしい。今さら聞けない、読みにくいタグ用語15選。【プログラミング】 - いしだの話

どちらかというとタグではないものをタグと呼んでいるあたりが気になるかな。

あとどこから手に入れた知識かは知らないけど読み方は一部を除いてあまり気にする必要はないと思う。

a

アンカーは正式名称。普通はエーと呼んでいる。むしろアンカーでは通じないことが多いと思う。

href

これタグじゃなくて属性ね。

エイチレフ、なんでhだけ別なんだと言うけど、英語では最初の文字だけアルファベットで読むことはよくあること。

元になっているのはHypertext referenceだから、エイチレフと読む方が意味を忘れにくくなる。

ちなみにリンク先を指示する属性にはsrcもあり、ソースと呼ぶらしいが僕はエスアールシーと(心の中では)読んでいる。sorceから来ているから正しくはソースなのだが、タイプするときはエスアールシーと唱えている。

alt

だからそれは属性だと(ry

まあ、オルトだよね。キーボードのAltもオルトだし。オルタナティブ代替)だからオルトだ。imgタグにはaltを付けろ。中身が空でもaltを付けろ。付けないやつはアレだよアレ。

dir

これも属性(3度目)。


なんか元記事の人がごちゃまぜにしている感じがあるので念のため書いておくと、単にタグというと<>で示された文字列のことを指し、「何とかタグ」というときは通常「要素(要素名)」のことを指す(分かりやすい解説はこちら)。「pタグ(p要素)」、「divタグ(div要素)」ということはあっても、「altタグ」なんて言い方はしない。


dirは滅多に使わないので念のため調べてみたけど、要素としてのdirも、遠い昔には存在していたらしい。しかし今は非推奨要素なので使うべきではない(<DIR>?HTMLタグリファレンス)。

現在HTMLで使うdirは属性において使われているdirのことを指し、このdirはディレクトリ」ではない。directionalityのdirだ。(参照)

縦書きサイトやアラビア語など、文字の記述方向を制御する際に使う。

width, height

ウィドスと読む人も多いし日本じゃそれで通じるから気にすんな。ウィズやウィズスやウィスと読む人もいる。英語圏ではウィス(スは舌を噛む発音)とハイトでないと通じないので覚えておいて損はないはず。面倒なので幅と高さと言ったっていい。

i, p, q, u, em, HTML

全部普通にアルファベットで読め。 いちいち正式名称で読むな。これらを全部正式名称で読むやつに出会ったことはない。qをクォートと読んだら「<q>」ではなく「'」の方を思い浮かべる人の方が多くて誤解を招きかねないのでむしろ正式名称で読むべきではない。

別に読めなくても恥ずかしくはない。

大事なのはどうやってうまくコミュニケーションするかという問題であって、正しい読み方なんてのは些末なこと。「正しい」のを知っていても顧客が間違った読み方の方で覚えていたら、そっちに合わせた方がスムーズに話が進むし角が立たない。恥ずかしいのは「間違った読み方」をすることではなく、「通じない話し方」の方ではないだろうか。

そもそも多くのウェブデザイナー・コーダーは正しい読み方なんてちゃんと習わずにやってきた。大事なのは正しく使うことであって正しく読むことではない。

2016-07-06

Windows游ゴシックがかすれる問題対策

少し前に話題になったWindowsの游ゴシック、游明朝が汚い(かすれる)という問題について、表示をまともにするための方法を検討することにしました。

これまでの経緯

Windowsで游ゴシックが汚いのは、どう考えてもWebデザイナーが悪い? | Cherry Pie Web

Windows で游ゴシックが細字になってしまう件は誰が悪いのかについて CSS 仕様から考えてみる | WWW WATCH

Re : Windowsで游ゴシックが汚いのは、どう考えてもWebデザイナーが悪い! - to-R

表示検証

環境

今回は游ゴシック体のみで確認。

OSWindows10

font-family: "游ゴシック", "Yu Gothic", YuGothic, "ヒラギノ角ゴ Pro W3", "Hiragino Kaku Gothic Pro", "MS Pゴシック", "MS PGothic", sans-serif;

font-size: 16px;

結果

ブラウザは左からchrome, Firefox, Edge, IE11

※コメントからの指摘で気づきましたが、以下のスクリーンショットではchromeの欧文書体が游ゴシック以外のものになってます。指摘後、"游ゴシック"のみの指定して、また元に戻したら欧文フォントも游ゴシックになったので何でこんなことになったのかさっぱり分かりません。スクリーンショット撮り直すのも面倒なんでこのままにしときます。

1.特に何も指定しない場合

f:id:k3akinori:20160706181734p:image

2.font-weight: 500; を適用した場合

f:id:k3akinori:20160706181735p:image

chromeの表示がましになる一方、他のブラウザのフォントも濃くなりました。

3.font-weight: normal; color: #000; text-shadow: 0px 0px 0px #000; を指定した場合

f:id:k3akinori:20160706181736p:image

chromeは細さそのままで色が濃くなり、Firefoxはfont-weight: 500;とほぼ変わらず。Edge, IE11ではジャギーが発生して汚くなりました。(Wの斜め線で顕著にみられます)

4.font-weight: normal; color: #333; text-shadow: 0px 0px 0px #666; を指定。IEのジャギーがごまかせないか試してみました。

f:id:k3akinori:20160706181737p:image

成果はあまり芳しくありません。

結論

今回の問題は、Windowsの問題という面もありますが、それ以上にChromeのレンダリングが下手くそという面も大きいのではないかと思います。Chromeがノーマルで游ゴシックLightを使う問題(バグ?)ということかと思います。(コメントを受け修正)

text-shadowで濃くするのも一定の効果はありますが、今度はIEがshadowのレンダリングが苦手、ということが分かりました。

すべての条件下できれいに描画したのはFirefoxで、さすが、Mosaicの系譜といったところでしょうか。

追記:現時点の対策法

問題がWindows chromeに限定されていて、それはfont-weight: 500;で解消されることまでは間違いないので、JavaScriptを使ってUAを判別し、chrome専用のCSSを読み込ませて解決することにしました。

<head>内に以下を記述

<script>
 var ua = window.navigator.userAgent.toLowerCase();
 if (ua.indexOf("chrome") != -1){
    document.write('<link rel="stylesheet" type="text/css" href="chrome.css" />');
 }
</script>

chrome.cssに以下を記述

html {
	font-weight: 500;
}