近頃の、とあるR。

WEBサービス100選 日本で有名でないおもしろサービス part2の文末に記載されている「こねた」に触発されケータイサイトを作ってみました。当然アクセスはありません＼(^o^)／

アクセスにガツガツするのは嫌いなのですが、私もウェブ屋の端くれ。好き嫌い以前に、ある程度は出来なきゃなりませぬ。と言う訳で、これを機会に携帯SEOに挑戦！……基礎的すぎてお恥ずかしい(ノ∀`)

とりあえずサイト作る

後にも先にもまずはサイトを作らねば始まりません。

押しやすそうなドメインを取ってみた

携帯で押しやすそうな admda.com を取ってみました。

深く考えずにコンテンツを作ってみた

知育系の内容で、更新の必要がほとんど無いツールっぽいコンテンツを作ってみました。
深い理由はありません。ただ、絶対音感コンテンツはDoCoMo未対応に(ノД`) だってDoCoMoで音を出すのがそんなに難しいとは知らなかったんです

googleにインデクスしてもらう

勉強と言うことで、今風のやり方に挑戦。

google webmaster tools

google webmaster toolsにアカウントを作ります。

サイトマップを作成

モバイルサイトマップの作製にマニュアルがありますが、googleサイトマップ ツール等でググると、ウェブ上で使える楽ちんツールがヒットしましたのでそちらのお世話になりました。
google webmaster tools にサイトマップのURLを登録すれば、数分（精々数時間？のオーダー）で認識されました。

robots.txtを設置

ロボットウェルカムですから、無くても全く問題ないような気がしましたが、練習ですので、しっかり!?と設置。

インデクスされたのは３日後

金曜日夜にこの作業を行い、実際にインデクスされたのは月曜日でした。

アドセンスを使う

同金曜日に、Google AdSenseに申請。こちらの承認も月曜の昼ころとなりました。

ソーシャルブックマークサービスに登録

触発された元ネタに従い、めぼしいソーシャルブックマークサービスに登録。
SEO以外で勉強になった点も少なからず有りました。例えば、

• アドレスを入力するとタイトルを自動取得してくれるインターフェイスを採用しているブクマサービスが多かった
• 携帯のUIDを認証の代わりにしていて～もにゃもにゃ～でセキュリティ的に問題のあるサイトが少なくなかった
• 普段携帯サイトを使わないからか、メアドの入力や空メールがとても怖かった（結局ほとんどの操作をPCから行うことに）

ポッとでの孤立サイトにドカンとアクセスが集まるような劇的な効果は有りませんが、確かに、SEO効果は有りそうです。キーワードでググると、ブクマサービスのページがかなり引っかかりますので。

マイナー検索エンジンにも登録

携帯専用の検索エンジンサービスにも何件か登録してみましたが、即反映されないからでしょうか、今のところSEO的な効果は見られません。

失敗した点

まだ、ちょっと登録した段階なのですが、それでも結構失敗したなぁと思う点があります。

• コンテンツそれぞれを別サイトにすべきだった
• もろもろ登録作業中に登録キーワードが揺らいだ
• 既存カテゴリにバッチリ当てはまるコンテンツではなかった

ぼやき

社○.comなんかは、17日にドメイン登録でその日のうちにブレイク。おそらく某ニュースサイト自身による小遣い稼ぎか実験なんだろうなぁ(・ω・)
４文字＋jpのドメインは某NTT系列が抑えまくってる。

position:relative;やabsoluteで位置を調整するケースがありますが、
微調整に向いているrelativeに意外な落とし穴を発見。

落とし穴１：パーセント値の扱いが違う

サンプルHTMLを用意しました。
これの、黄色のボックスの位置がブラウザによって結構変わります。
px指定の場合は大差無いんですけどね(・ω・)パーセント指定だと途端に癖が出まくります。
まとめると以下の通り。

自ボックスを基準にした指定値（ほぼ）を取る

IE6
IE7

ブラウザのinnerHeight?を基準にした指定値をとる

Chrome(2.0.172.30)
safari(4.0)

指定が無効

IE8
FireFox(3.0.10)
Opera(9.64)
macのSafari(3.2.3)

落とし穴２：webkitの挙動がwindowsとmacで異なる

微妙なバージョンの違いかも知れませんが、何れにせよ、
本件に限らず、windowsのChromeやSafariでレンダリングが意図通りだからと言って、
macのSafariでも大丈夫とは限らない訳です((((；ﾟДﾟ))))
ちゃんと、macチェックもしましょう俺(ノ∀`)
※追記：safari4で挙動がそろいました

ウェブとしては、テキストはザックリ(ﾟДﾟ)と流し込み、ブラウザのレンダリングに任せて整形。細かい文字送りや禁則に左右されないデザインを心がけるのが理想の一つです。
しかし、毎度毎度そうはいきませんよねぇ。
字数を決めてコピーを書いてもらった挙げ句、macだけちょっと２、３文字飛び出て改行しちゃいます(ノ∀`)とかwindowsは字足らず気味になっちゃいます……等々を避ける為にも、テキストのズレを最小に抑えたいケースも多々。

最も簡単な方法

等幅フォントにしてしまうことです。
PSDデザインの時点で、「HiraKakuPro W3」か「MS　ゴシック」を使ってテキスト部をデザインしてもらいます。
これだけで、全角は大体合います。

厄介なのは実は半角

サンプルHTMLを用意しました。
このテストのAが通常の等幅フォント指定となります。（私の場合）
しかし、これですと、半角に差が出ちゃうんですよねぇ。「MS　ゴシック」の半角の方が細いのです。

全角指定が先の場合

Aの書き方
font-family:”Hiragino Kaku Gothic Pro”,”ヒラギノ角ゴ Pro W3″,”ＭＳ ゴシック”,Helvetica,Arial,sans-serif;
では、全角フォントを先に指定し、その後半角フォントを指定しています。
しかし、この指定方法では、半角も「MS　ゴシック」に（つまり細く）なってしまうんですよね……

半角指定が先の場合

Bの書き方
font-family:Helvetica,Arial,sans-serif,”Hiragino Kaku Gothic Pro”,”ヒラギノ角ゴ Pro W3″,”ＭＳ ゴシック”;
では、逆に、半角フォントを先に指定しています。
しかし、FireFoxとMacのSafari以外、つまりwindowsの殆どのブラウザでは、全角フォントの指定が無視されてしまいます。よって、ツカエナイパターン。

バッチリ合わせるには

まぁ、Aで良いと思います。実用的には。半角でズレますけど。
そこもバッチリ合わせたいんじゃー！！と言う場合は、
Cの方法。
全角に font-family:”Hiragino Kaku Gothic Pro”,”ヒラギノ角ゴ Pro W3″,”ＭＳ ゴシック”;
半角に font-family:Helvetica,Arial,sans-serif;
全角と半角で異なるフォントを割り当てるしかなさそうですOrz
もっとマシな方法を発見したい(ノ∀`)

サンプルHTMLの表示に於いて、
IE8、Firefox3、Safari3(chromeも)では、

この画像のように、ボックス間に隙間が空いてしまいます。
IE6,7、Opera9ではボックスAとボックスBは密接します。
ボックスAは、marginもpaddingも（borderも）なし。
Aの子ボックスのbottomにmarginが入っています。

名だたるモダンブラウザがほぼ全滅

本来？なら、ボックスAとBの隙間はボックスAの背景色で埋められるのが直感的なレンダリングです。
ところが、モダンブラウザと名高いIE8、gecko、webkitがボックスAの背景をキャンセルしてしまいます。
うーむ。ここまで、そろいもそろってですと、流石にバグではなく仕様なんでしょうね(´・ω・｀)

親ボックスのpaddingにダミー値をいれて対策

良くある実例では、ボックスAが id=”main” ボックスBは id=”footer” で共にダミー的コンテナボックスだったりで、余白系の値は０にされていることでしょう。
大抵の場合は無調整で問題ないのですが、
（無駄に）複雑な多重背景で、うかつなズレが許されない場合がままあります。
そんな際の、margin、padding、時にはborderで、ごまかす調整するでは、キャンセルされるボックスAのbottomにpaddingの値を与えてやるのが良さそうです。

「固定幅＋中央寄せ」時の背景ズレ対策を半年以上前に書きました。
背景画像がブラウザをリサイズすると1pxうねりますよね？
その補整に関する記録です。その際は、偶数幅のものをセンタリングするからうねるのだと思っていたのですが、よくよく考えてみると、奇数でもうねるんですよね。他にも色々と気になり、もう少し突っ込んで検証してみました。

検証用素材HTMLをご覧ください。

奇数幅でもうねります

センタリングでは、
ブラウザ幅が偶数幅の時は奇数幅画像がずれ、
ブラウザ幅が奇数幅の時は偶数幅画像がずれます。
1px違いますので当然です(ノ∀`)

ずれ方が違う……

msieもgeckoもoperaもwebkitも……リサイズで黒と赤の線がチラチラしますね(・ω・)
よくよく考えてみました。

余ったマージンを左へ送る場合

ブラウザ幅が偶数の時に右に黒線が出ます。

余ったマージンを右へ送る場合

ブラウザ幅が偶数の時に左に黒線が出ます。

つまり、ブラウザ幅が偶数の時と奇数時で、余分マージンを送る側を変えるレンダリングエンジン以外は、リサイズで黒と赤の線がちらつくことになります。
幸か不幸か、現状のメジャーなレンダリングエンジンは全てちらつきます。

各ブラウザの特徴

IE6,7だけ（６未満は無視）が左に余分マージンを送るようです。他は皆右へ。
IE6.7以外は、偶数と奇数の画像を混在させない限り、ずれな……ん？
いや、それって偶数と奇数がずれるのであって、バックグラウンドとフォアグラウンドがずれる原理とは関係ありませんよね＼(^o^)／

フォアグラウンドのずれ方を見る

ブラウザ幅に限らず線と画像が合う、operaとwebkitは、問題ありません。
これらは、偶数と奇数の画像を混在させない限りずれないと言うことです。
問題は、msie6,7とgecko。
マージン送り方向という考え方では、どうも、バックグラウンドとフォアグラウンドで逆にマージンを送っているようです。

msie（6,7）

バック　余分マージン左送り
フォア　余分マージン右送り

gecko

バック　余分マージン右送り
フォア　余分マージン左送り

msie8,opera,webkit

バック　余分マージン右送り
フォア　余分マージン右送り

対策

結局、前と大差ありませんorz

• IE6.7は背景画像の右端に１ピクセル足す
• FireFoxは背景画像の左端に１ピクセル足す
• 奇数幅でそろえても無駄＼(^o^)／

動的にjQueryで内幅を変えるのも面白いかなと考えていたのですが、
ブラウザ間の「ずれ方」の差異は幅いじりだけでは無理のようです。

具体的に

標準モード

#main {
	background:url(main-bg.gif) repeat-y center 0;
	_background:url(main-bgie.gif) repeat-y center 0;/* IE6 センタリング補正 */
	*background:url(main-bgie.gif) repeat-y center 0;/* IE7 センタリング補正 */
}
#maincontainer:-moz-read-only {
	background:url(main-bgff.gif) repeat-y center 0;/* Mozilla センタリング補正 */
}

互換モード

#main {
	background:url(main-bg.gif) repeat-y center 0;
	_background:url(main-bgie.gif) repeat-y center 0;/* IE6,7 センタリング補正 */
}
#maincontainer:-moz-read-only {
	background:url(main-bgff.gif) repeat-y center 0;/* Mozilla センタリング補正 */
}

で動くっぽいです。
どうもIE8がくせ者です。
互換モードでは新セレクタが機能しない((((；ﾟДﾟ))))
互換モード時にはヘッダに、

を追加したら上手くいきました。
アンダースコアハックやらスターハックが無効化されるようです。

単純なリキッドレイアウトは画面が狭かった時代の遺物だと思っています。
もちろん、リキッドを全否定する意味ではございません。

アマゾン風リキッドを知る

jQueryで作るAmazon流リキッドレイアウトを読んで、始めて最近のアマゾンのリキッドレイアウトを知りました(ノ∀`) ブラウザの横幅に応じて、表示点数を変える（ずらすのではなく）レイアウト。
なるほど。これはある。あるぞぉーーー
記事はどうやら、jQueryを使うことに主眼があるようで、jQueryを使わない実装には触れられていませんでした。

とりあえず作ってみる

さらっと作れるじゃんね。一応プロだし(ノ∀`)
ん。。。むむ……案外手強いｗｗｗｗ
アマゾンどうのこうのの部分は問題ないのですが、それ以前のリキッドレイアウトが手強いぞーー
というか、リキッドの案件なんてほとんど縁が無かったな俺(・ω・)ダメじゃん

練習じゃぁ！

危機感を感じ、とりあえず練習に。
目指すは、本文部のみがリキッドの３カラムレイアウト。

１つ目。まずは、ネガティブマージン（とやら）でを作る。

1. IE6でウィンドウ幅を縮めると左サイドが散歩に出かける
2. ウィンドウリサイズ時等々、挙動がおかしい((((；ﾟДﾟ))))(IE,Opera)

なんじゃこりゃ｡･ﾟ･(ﾉ∀`)･ﾟ･｡
IE6がどうのこうの以前にIE7でどうにもならん((((；ﾟДﾟ))))
ふぅおちつけ。良くある事じゃないか。
どうせ、ブロックモデルの解釈がおかしいに違いないさ……

２つ目。リキッド部を無駄タグで入れ子にしてみた

なーんだ、あっさり動いたじゃん……IE6のアレ以外は。

ちょっとネガティブマージンから離れてみましょうか……

３つ目。左カラムをアブソリュートしてみた

お！IE6でも大丈夫じゃん！
って、フッタを突き抜けてます。当然です。それがアブソリュートです。

４つ目。もっと大胆にアブソリュートしてみた

本文部と、サイド部を別レイヤーにして、サイド部を丸ごとアブソリュート。
フッタを突き抜けないように、JavaScriptで高さをリアルタイムで調整(ﾟДﾟ)食らえっ！
やけくそだったのに、リサイズ時の値取得が上手くいかず放心。
まて、リアルタイムにサイズを変えるなら、リキッド部の横幅を弄ればいいじゃないか……

５つ目。JavaScriptでリキッドさせるタイプ

もうね、素直にリキッド部の幅をJSで弄っちゃいますよ。ええ。
ええ、普通に動きます。柔軟性も結構ありますよ。ええ。
なのになんでしょう。この敗北感は（´－｀）
そうだ！jQueryで作るAmazon流リキッドレイアウトを読んで、いやCSSでいいじゃん？と思ったのが発端だったのです。
まぁ、該当箇所こそあっさりCSSで動いてますが、ソレより基本とも言える部分でjQueryを必須にしてしまう訳には参りません。

６つ目。ネガティブマージンのものを基本に、IE6だけJS補正してみた

挙動のおかしなIE6だけをJavaScriptでねじ伏せれば良いのです(ﾟДﾟ)
世に出回ってるサンプルも結構眺めました。
上手く動いている物は、大抵、サイドも可変となるパーセンテイジ指定でして、本文部のみリキッドというタイプは、どれも、IE6のこの挙動に関しては放置しているようでした。
テーブルよりはJSかな(´・ω・｀)IE6（正確には７未満）だけに適用もできるし。

と言う訳で、今回の修行はここまで(ﾟДﾟ)今日のところは勘弁したらぁ

女子美術大学みたいなことできる？と聞かれサンプルを製作。

実は、その昔に挑戦してクロスブラウザの面で失敗したことがあり(ノ∀`)
いやぁ、jQueryは便利ですね(・ω・)表示すべき「幅」の取得も楽にできてしまいました……
スクロールバーの幅とかは考えずに、windth:100% のブロック要素の幅を取るのが吉なのかもしれません。
CSSだけで動くのはIE位でしたが、背景ストレッチくらいは標準機能であっても良さそうなものです。

追記

flash背景のが軽いっぽい(・ω・)　flash背景サンプル
ランダム背景やら伸縮の微妙な具合やらも調整の幅が広そうだし、縦幅を固定しようとすると、jQuery＋私の技術では厳しかった(ノ∀`)overflow:hiddenも効かず。
なにより、flashのが軽い((((；ﾟДﾟ))))