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

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