レスポンシブ デザインのめんどくささ

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり PC でアクセスしてもスマフォでアクセスしても、同じデザインで出力される……というわけではなくて、一つのデザインしか定義してないんだけどそれで PC でもスマフォでもちゃんと表示されることである。

今やっているスマフォのゲームも最初、レスポンシブ デザインで作っていた。
このレスポンシブ デザインの肝は簡単に言ってしまえば%で作ると言うことである(ぁ
どういうことかというと、例えば 2 段組をするとき、全体幅が 1024 ドット、左側がメイン コンテンツで 640 ドット、右側がメニューとかで 384 ドットにしよう……ってのが今までの作り方。
レスポンシブ ウェブの場合は、全体幅は 100% で作り、本文左側は 62.5%、メニューとかの右側は 37.5% にしようってこと。そうすればどんな機器だろうが割合で区切られるので、それらの機器に従った大きさになる。
これはレイアウトだけでなく、画像の大きさに至るまで何もかも%で指定する。

ところが、この作り方には二つの欠点がある。

  • 文字の大きさは変わらない
  • ドット単位の微調整は不可能

ブロック要素や画像などは画面の大きさに従って勝手に変わってくれるのだが、文字の大きさはそれに追随してくれない。なので細かいディスプレイに出しても、荒いディスプレイに出しても同じ大きさ(ドット)で表示されてしまうため、要素の中に表示される文字数が変わってしまい、結局レイアウトが乱れる。
これはディスプレイの画素数と CSS ピクセル比ごとに文字の大きさを定義しておく必要がある。
さらにゲームではインターフェースに凝るため、ドット単位でのボタンやゲージ(メーターやプログレス バー)などの表示が必要となる。ブラウザは小数点第三位くらいまでの%値しか見てくれず、ドット単位での微調整はできない。これの回避方法は、ドット単位で組んだあと、Javascript や CSS の ZOOM を使って最適な大きさに表示するのだが、iOS の Safari などでバグが発生し使えないことが多い。これに関しては、まだボクの中では特に解決策は見いだせていない。
今回はドット単位で調整が必要なところは、合成した画像を変化する種類分作って対応するというわりと原始的な方法で回避した(^^; どういうことかというと、下地があってその上にボタンをドット単位で並べなければいけないような場合、下地とドット単位で並べたボタンを合成してしまい、どのボタンが光っているかというパターン分の画像を用意することによって、ドット単位での調整をしなくて良いようにした。ただこの方法は、パターンが膨大にある場合は使えない……。

まぁ、一番いいのは Javascript の ZOOM である。コイツさえ正常に動いてくれれば、レスポンシブ デザインは一気に楽になる。何故かというと、ドット単位で自由に作れるからだ。従来の作り方のように、例えば全体幅を 1024 ドットとか 640 ドットとかと固定して自由にレイアウトした後に、Javascript で機器のディスプレイの大きさに合わせて拡縮するようにすれば楽ちんなのである(爆。

他にも Table を使うのが難しかったり、横幅を必要とするモノがどうしてもスマフォなどだレイアウトが崩れてしまったりなど、一つのデザインで様々な機器に対応するのは一筋縄では行かない。TAMA Networks も燃費なんかの表の部分や、説明付きの画像の場合はスマフォで見ると崩れてしまう。
この辺、何とかしたいなぁと思いつつ……。
写真はこの日食べたもの。バーガーキングのブルーベリーのハンバーガーと、秋葉原の万豚記。

1412080730 1412080731 1412080737 1412080740 1412080741 1412080747

Webkit オンリーで組んでも……

スマフォの開発を相変わらずしているんだけど、今回の案件は別に PC で動作する必要はない。で、スマフォというと iOSAndroid が主流で、他のプラットフォームに関しては、ほぼ無視して良い(ゲームの場合の話ね)。となると、ボクが思ったのは「じゃぁ、Webkit に対応して作ればいっか」であった。
iOS に搭載されている Safari も、Android の Chrome も Webkit というレンダリング エンジンで作られているからだ(Chrome は Webkit からさらにフォークして Blink となった)。

ところが、けっこう iOS と Android で表示が違うんですな。
更に困ったのが Android の標準ブラウザ。
実は Android に最初からついてくるブラウザというのは Google Chrome ではない。なんでなのかというと、これはボクの予想でしかないのだが、Android デビューに Chrome は間に合わなかったからだと思われる。ちなみにエンジンは Webkit である。
Android 版の Chrome は Android のバージョンが 2.3 だか 2.4 だかくらいにようやくデビューした。なので Android には「標準ブラウザ」という、別のブラウザがずっとついてきている(Android 4.4 でようやく標準ブラウザが Chrome となった)。

この標準ブラウザがとにかくタコい。
まず Javascript の実行速度が圧倒的に遅い。そして HTML5 からついた修飾(ぼかしや縁取り、グラデーション)などの再現率が低い。特にぼかしがおかしい。

次に Safari。コイツのフォント処理はおかしい。とにかく文字の大きさが合わない。
なんだこれー!?
しかもバグがあって、Javascript で拡縮をやると正しい大きさにならないという……orz(CSS でも ZOOM を使うと同じ症状が出るらしい)
これが実に問題で、先の記事の CSS ピクセル問題で、CSS を書き直しせず、Javascript で最適な大きさに拡縮するという風に逃げたのだが、この Safari のバグのおかげで結局この方法は使えなくなってしまい、CSS を全面書き直さなければならなくなった。

だ、ダメすぎる……orz

だが今回、「ブラウザの場合分けはしない」というポリシーで組んでいる。これは別にボクの勝手なポリシーなんだけど。場合分けってのは何かっていうと、Safari だとこっちの処理、Chrome だとこっちの処理というようにブラウザことに処理をわけることだ。
CSS / HTML は一種類の定義ですべてのブラウザで通用するように書いた。まぁ、なんだかんだ言ってもレンダリング エンジンが一つだったというのが大きいだろう。これが PC だとこうは行かなかったと思う。

PC ばっかり相手にしてたから……

スマフォのゲームで HTML や CSS / Javascript 部分を担当しているわけだけれども、本格的にスマフォに合わせて作るのは初めてで、色々と勉強しながら作っている。その中でどうしてもうまく動かないのが VIEWPORT
これは昔、TAMA Network の CSS をいじっている時も試したことがあるんだけど、どうしてもボクの思うように動かない。なんでだろうなーってずっと疑問だった。で、今回も案の定、ボクの思ったとおりにならない。
ただ経験上、iPhone で見ると、VIEWPORT の設定がボクが想定しているよりも倍の大きさになっているように見えるのは知っていた。なんでこんな仕様なんだってずっと疑問だったのだが、それがそもそも仕様だったことに気付いておらず、その動作がサッパリ謎だった。

で、今日、改めて調べて CSS ピクセルってのを知る(ぁ
ボクは今までデバイス ピクセルで組んでいたのである。

CSS ピクセルが生まれたきっかけは、今のスマフォってすごいドットが細かい。そのドットのまま PC のサイトを表示させると、文字が小さくてサッパリ読めない。そこで、例えば iPhone 6 までの iPhone は CSS ピクセルが 2 に設定されている。これは、デバイス ピクセル 2 ドットで CSS ピクセル 1 ドットになる。
そうすることによって、iPhone 6 の画面は 1334 x 750 ドットあるのだが、ウェブを表示する際には 667 x 375 ドットになり、2 倍に拡大されて表示されるのだ。

この仕掛けを知ってようやく VIEWPORT の動作が理解出来たというか、思った通りになるようになったのだが……しかし、全てデバイス ピクセルで作ってしまった……。しかも、Javascript や HTML 上で指定するピクセル数は CSS / デバイスどっちになるんだろうか(デバイス ピクセルで動いているように見える)?
HTML 上で <style></style> 宣言した場合は、その中は CSS ピクセルだった(当然か)。

そんなワケで、CSS 部分はほとんど作り直しに……。
やっぱ PC だけのサイトしか作ってないと、全然ダメだね、というお話。

次回はブラウザ間の色々な違いに苦労した話を……。

@font で変わったもの

rural_sy00e
10/23 に TAMA Networks に @font を導入してからサーバ上で変わったことが一つあった。それはサーバの転送量。一日辺り 300MB くらい増えた(汗)。@font はそのウェブページで必要になった文字分のフォント・データしか送ってはいないようなのだが、実は仕組みそのものはボクも理解していない。
そもそもレンダリングはどっちが行うのか? サーバ側でレンダリングしている場合は、フォントのビットマップ・データがおそらくブラウザに渡されるんだとは思うけど、そうなるとブラウザ側でのフォント表示アルゴリズムが従来のものと大きく変わるような気もしつつ……。
あとあとになって解ったんだけど、同じフォントがクライアント側にあってもどうやらサーバからのフォントを使ってるっぽい? 同じフォントがあったらクライアントのデータを使って欲しいなぁ、と思いつつ……。

まぁ、転送量そのものはうちの場合そんなに問題にはならないのだが、サーバそのものに負荷が増えたことに変わりはないので……うーむ。まぁ、アクセスが頻繁なので、サーバ側は全部メモリ上で処理されているとは思うんだけどね。

 

@font を使ってみる

bs_ryok01a
以前から、PC にインストールされていないフォントが表示できるサイトがあって、これどうやってるんだろうなぁって思っていた。ウェブサイトを表示した場合、そこに表示される文字は画像でない限り、PC にインストールされているフォントに左右されてしまう。
つまり見た目がどうしても人によって変わってしまう。
フォントを固定できれば、だいぶ環境による差を吸収できる。

話は少しずれるが、実はウェブってやっぱ読みにくいなぁと思っていて、それは当然で、同じようなレイアウトを取る雑誌では、挿絵・写真の位置や文字の大きさ改行位置が読みやすいように編集されているが、ウェブサイトは表示する幅や高さ(つまり紙の大きさ)が違うし、文字の大きさも違うし、書体も違う。当然挿絵の位置も変わってきてしまう。
なので、やっぱり読みにくいと思っている。これについてあまり言及したサイトを見たことはないが、本ってやっぱりよく出来てるなぁってボクは思っている。

閑話休題。
で、それに近づけるというわけではないのだけれど、ボク自身がサイトを編集するにあたって使っているフォントを、この TAMA Networks でも表示されるようにしてみた。CSS3 ではサーバ上のフォントをウェブサイトの表示に使うことが出来るのだ。定義は以下の通り。

@font-face {
font-family:”Migu 1C”;
src:url(‘https://amatsukami.jp/fonts/migu-1c-regular.eot’);
}
@font-face {
font-family: “Migu 1C”;
src:url(‘https://amatsukami.jp/fonts/migu-1c-regular.ttf’) format(‘truetype’);
}

ただ、このフォントをこう言う使い方していいのかは、ちょっと自信がない。一応ライセンスの所は読んだのだが……使用についてはクライアントで使用することばかりが書かれていて、ちと不安ではある。問題がある場合はこの定義を消すことになると思われる。下のは左が新しいフォント、右が Windows Vista から採用されている「メイリオ」。Windows Vista 以降で TAMA Networks を表示するとこの「メイリオ」というフォントで表示されていたんだけど、Mac やスマフォでみるとまた違っていた。
ただスマフォでは @font に対応してないらしく(CSS3 には対応してるはず)、こちらで設定したフォントは表示されなかった。

migu meiryo

DOCTYPE め

rural_ay00m
うちのサイトなんかでもそうなんだけど、WordPress で CG を別ウィンドウで拡大表示できるプラグインがあるのね。これは元々有名な lightbox とかfancybox っていうライブラリをつかっている。で、コイツ、IE9 だと何故かちゃんと表示されないという現象が前々から起きていた。まー、とりあえずいいやって思ってはいたものの、設定によってはまったく表示されないこともあるので、ずっと原因を探っていた。

起きるトリガは、position: absolute。これをつかって座標指定してある要素内の画像(img)はすべて IE9 では正常に表示されない。

最初ソースを解析しようとしたんだけど、Javascript ってサイズを小さくするために、組んだあと難読化(改行とか削り、変数名も 1 文字とかにして、とことんバイト数を削っている)するのが常識なようで、とにかく解析するのが面倒くさい。って思ったら、本家のサイトに難読化する前のソースがあった(ぁ。
まぁそれを調べたりどしたりしていると IE9 だけ座標と画像のサイズが取ってこられてないことが判明。
なんだこりゃ??
というわけで、ネットを徘徊して調べるも多くは fancybox のバージョンを上げたら直りましたっていうのばっかり。いやそうじゃないんだ、と思いながら、ボクのサイトで座標指定して IE9 で開いてみたら普通に表示されたのね。

なんだって!?

ということはボクの組み方そのものが不味いのか?
っと WordPress のスキンを眺めたところ、目についたのが、DOCTYPE だ。こいつはその HTML ファイルが、どのバージョンの仕様にのとって作られているかを宣言している。

ボクは未だにレイアウトに table を使う。これはバッドノウハウなのだが、正直、ドット単位の細かな位置合わせって、ボクの組み方が悪いのだろうが CSS はめんどくさくてしようがない。その辺 table はわりと簡単にできてしまうので、ついつい table を頼ってしまうクセがあるのだ。
が、この table タグは今の HTML では推奨されない指定が存在するのだ。width とか height とか。これらを有効にするためには、DOCTYPE で古いバージョンの仕様であることを明示しなければならない。ところがこれは Javascript にも影響するようで、ちゃんと調べてないんだけど DOCTYPE によっては実行出来ない(?)ものがあるらしい。
IE10 とか Google Chrome はそんなの関係なく実行してくれているのだが、IE9 はこの DOCTYPE を忠実に守っていたらしい。なので、IE9 だけ座標と画像サイズの決定が出来ず、表示されなかったと言うことのようだ。
うがー!!! いつもアバウトな IE がなんでよりによって DOCTYPE 見てんのよ!!

というわけで、DOCTYPE をXHTML 1.0 に定義。でもそうすると、table でレイアウトしていた部分が使えない。なのでそこは、全部書き直して、XHTML 1.0 でもちゃんとレイアウトが整うように書き換え。ようやっと、fancybox で表示されるようになった。くそー IE9 めっ、貴様さえいなければ!!
曲はトルコのメタル・バンドらしい。

WordPress あれこれ

某サイトをガリガリと作っていた。そのうち TAMA Networks でも挨拶する予定なんだけど、とりあえずサイトを紹介。

どれも WordPress で構築されている。
これらを組んだおかげで、WordPress で自由奔放にサイトを構築出来るようになった。Galette のサンタフル☆サマーのサイトも WordPress である。でも失敗しているところも実はあったりして、例えば GLacé のメニューはパーマリンクが失敗していて、カテゴリ ID が丸見えだったりとか(汗)。これは Windows Server だと rewrite がうまく動かなくなってしまった部分があって、仕方なくこうなっている(汗)。他にも相対・絶対ディレクトリの指定間違いとかがあったりして、そのたびに「あわわ」と慌てたり……いや、ちゃんとチェックしろよ(汗)。

スタッフ・ブログはいわゆる投稿ページで構成されているんだけど、サンタフル☆サマーはすべて固定ページで構成されている。スキンの方に PHP でページ名を判別して、レイアウトを変更している(現在の所、年齢認証、トップページ、その他の三つ)。GLacé 本体のサイトはトップページが固定ページで残りのページは投稿ページを使ってお知らせやダウンロードなんかを構築している。
スタッフ・ブログが一番 WordPress らしい使い方である。

なんでベタの HTML で組まなかったかというと、前の日記にも書いたような気はするけど、WordPress で構築しておけば、HTML が書けない人でもあとから更新出来るからってのが大きなメリットだったんだけど、実際に作ってみるとけっこう HTML の知識が必要だということが解った(爆)。特にサンタフル☆サマーのサイトはほとんど HTML ベタうちでつくってある(汗)。ただ、一応ボクが組んだヤツをコピペすればいいようにはしたんだけど……うーん、難しいなぁ。というのも、実は WordPress のエディタだけで作れないこともないんだけど、エディタ上で組むと、<div> や <span> を無視して改行されてしまったり、画像を挿入されてしまったりしてなかなか使いづらい。せめて <div> とか各段落ごとにうまく区分けして編集出来るようになってれば、WordPress のエディタでもいけそうなんだけどなぁ……。

ところで今回苦労したのが IE9 。とにかく IE9 だと、位置がずれるずれる。
基本 IE10 で作って、Google Chrome で確認してるんだけど、この二つはほとんど差はなく作れたんだけど、IE9 だと凄いずれる。主な原因は、Absolute。特にサンタフル☆サマーのトップページは重ねが多いため Absolute の嵐なのだが、right や left を設定してないと、親の ID(もしくはクラス)の text-align に左右されてしまうのね。本来座標を設定してないと、親の左上が起点になるはずなのだが、IE9 だと text-align で center とか設定されていると、親の真ん中の座標を起点に配置されてしまうのね……。もー。
あと CSS の座標指定を間違えて、 px じゃなくて x って書いてしまったところがあったんだけど、IE10 や Google Chrome ではそれを px として解釈して意図した位置に表示されたんだけど、IE9 では解釈してくれなかった。ところが HTML 側の表示順序を変えたら、意図した座標に表示されたりして、なんだこれw。
ただ IE9 は Windows 7 にデフォルトでついてくるブラウザなので、あんまり無視出来ないのよね。ちなみに IE8 や IE7 では確認してない(ぁ たぶん正しく表示されないような気がする。

まー、そんなこんなで、まだまだ WordPress、というか CMS を使ってサイトを簡単に構築する方法の模索は続きそうだ。
wp