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

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり 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

平和島 P.A.

今日は弟一家を羽田に送りに行ってきた。
その羽田から会社に向かっていたら、平和島 P.A. の看板を見付けた。そういえば首都高のサービスエリアやパーキングエリアに入ったことないなぁと思い、ちょうど、朝食も摂っていなかったので寄ってみることにした。

想像したものより立派なパーキングだった。

ただやはり狭い(^^;

ところでサービルエリアやパーキングエリアの定番メニューと言えば、ボクはカツカレーである。特に食べたいものがない場合は、だいたいカツカレーを頼む。と言うわけでここでもカツカレーを注文。
なんかぬめっとしたルーに、味のぼやけたカツであった。
まずい!
まぁ、そんなもんか(ぉ

売り場の方は思ったよりお土産とか充実していて、面白かった。
下町のお土産が多い。とりあえず飴を買って帰った。

首都高のパーキングエリア巡りってのも、面白そうだなぁ。
わりとすぐにできそう。

1412070720 1412070725 1412070726 1412070722 1412070723

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 だとこうは行かなかったと思う。

被害低減ブレーキかぁ……

Google をはじめ、自動運転の実地実験が色々な所で始まりつつある。いつか自動車は、人が運転しなくても良くなるのだろうと何となく思っている。そして人が運転してはならないものになる可能性も……。ただそれは、ボクが 70 歳を過ぎてからにして欲しいと何となく願っているけれど。
なぜならボクは運転が大好きだからだ。

まぁでも、各メーカーの自動ブレーキの動画を見つけたので張ってみる。スバルでもダメな車種があるんだなぁ。ただこの動画の車はどれもぶつかりそうだというのは、警告音で教えてくれるようだ。
ボクには不要の機能だけどね。次、車を買い換えるときもこの機能のない車を選ぶと思われる。

どごーん!

[youtube id=”apAZOLgw3zU”]

念願の『癒空間』へ…!

TAMA Networks では何度も登場している博多水炊きのお店「いたや」。高校時代からの友人が教えてくれたお店で、非常にボクも気に入っているお店だ。しかし、立地が悪かったのか店を畳んでしまった。
その店主が大泉学園でお店を新しく始めたのは、聞いていた。
なかなか行けなくて(大泉学園に行く用事があんまりなかった)、前回の時は満席で行けず……今日、ようやく行くことができた……!

名前は『癒空間』(食べログ)。たぶん「いくうかん」って読むんだと思う。

結果、ほとんど変わってなかった!!
嬉しい~~。
具もほとんど同じ。〆のソーキ蕎麦も一緒。
一品料理は鮮魚系が減って、煮物・焼き物が多くなった気がする。
お酒は……詳しくないから、解らない(汗)。

でも、この脂分がまったくない鳥のスープがなんと言っても、美味しい。お塩だけでも充分美味しいし、ポン酢をこのスープで割っても美味しいし……あの味が二度と食べられないかもと思っていたので、満足でした。

1412040668 1412040672 1412040675 1412040677 1412040680 1412040681 1412040687 1412040690 1412040693

みの屋

弟に桜なべの店に連れて行ってもらった。森下にある「みの屋」っていうお店。
メニューも本当に桜なべしかない。
一応、馬刺しが何種類か。
本当にメニューはそれだけしかない。

味噌仕立てなのね。
柔らかくて、美味しかったです。

お風呂屋さんは、外国人にも有名な浅草の蛇骨湯
黒湯の温泉なのよね。

で、ラーメンは荻窪の野方ホープ。懐かしいなぁ、10 年ぶりくらいに入ったわ。
昔荻窪の会社に勤めていた頃があって、あの頃よく行った。

1412030645 1412030647 1412030648 1412030649 1412030652 1412030654
1412030658 1412030661 1412030665

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 だけのサイトしか作ってないと、全然ダメだね、というお話。

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