目次
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
「結局、お客様にとってサービスの品質って、画面がどれだけ洗練されているか、なんだよね」
企画や営業担当の方からよく聞く言葉です。全くもってその通り。
でもエンジニアとしては、データの保存と加工、セキュリティを最初に気にしてしまいがち。だから「こそ」、画面のしっかいりしているサービスは「いいサービス」と言えるのでしょう。
というわけで、自分が携わってきた画面（ブラウザ）系のびっくりしたことを紹介します。
まず前提として、自分は普段このようなスタイルでコーディングを行っています。
- 基本的にサーバサイドのアプリを作ることがメイン（Rails 以前はPHP）
- よく使うブラウザは FireFox。LiveHttpHeaders と FireBugs に惹かれてそのまま
- 開発機は MacOS。テスト用に Linux。windowsテスト機は共有
cookie制限の罠
自分が初めて本格的なjavascriptを書いたのは今から4年前。新卒で入社して1ヶ月が経ったGW前でした。作ったアプリは、画面上のガジェットを「開閉」できるようにする、という今ではよく有るもの。mixi では、ガジェットの右上をクリックして調整します。
今ではmixiも上記のガジェットはリアルタイムで行いましたが、当時はクリックするたびにリクエストが飛んでいるのを見て、
「じゃぁ自分は遷移せずに変更／保存できるようにしまーす」
ととんでもないことを宣言した新入社員時代。しかも javascript は素人同然。「○日までに実現の目処が経たなかったら、遷移で実装してくださいね」と繰り返すリーダーを尻目に設計／実装してみたものFireFoxでは動くが IE6で動かない。
んで、その原因は何故かというと、自分はその実装で各ガジェットの状態をcookie で保存していたのですが、1ガジェットにつき1つのcookieを発行していました。それが、制限にひっかかっていました。
http://www.studyinghttp.net/cookies#Restriction
で、これを共有したときに「これだからIEは。。。」と言いそうになったのですが、
実はこれ、IEの方が本来のcookieの仕様（rfc）に忠実で、FFの方が拡大解釈をしている模様。そのため、設計（仮実装）のときにうまくいっていたのが、そろそろ出来そうかな、となった時点で大幅変更を加えるはめになりました（各ガジェットの状態を構造化し、jsonにして1つのcookieに保存）。
FFの「ゆるさ」というのも、後々問題になるというお話。
IE6のselect tag問題
IE7が出来て（普及して）一番うれしかったのが、この問題が解消されたこと。
これは、各タブを重ねたときに、IE6（以前）の場合はselectタグが1番上にきてしまう、というもの。このページの一番下を参照して下さい。
で、iframe を使うという対応策は既に知られているのですが、 とはいっても複数ブラウザで競合チェックしたりというのはやっぱりめんどくさいです。
IE での position : fixed が効かない問題
こちらも、比較的有名なIEの不具合？仕様？でしょうか。こちらができると固定したサイドバー等が簡単に実装できるのですが（javascript で実現したものはわざとらしくて）、これはどうしようもないです。
fixed.jsというライブラリがありますが、それでもテストの心配はあるわけで、 その分の調査やデバッグの期間というのは長く取る必要がある、と経験上感じています。
上記のセレクトタグと併せて、javascriptとCSSでリッチな画面を作ろうとした場合に大問題となる場所ですので、その点、調整にはかなりの時間を確保しておく必要がある所です。
json.stringify と prototype の喧嘩
2つ続けてIE6という古いブラウザの話をしましたが、今後は最近のブラウザの話。
前回の記事、 何か変なjson が吐かれるために苦労していましたが、そちら、やっと原因がつかめました。
現在担当しているプロジェクトではjavascript のライブラリはjQuery を主に使っているのですが、以前からの資産もありprototypeで実装されているものもあります。そのprototype のライブラリが json.stringify を汚染していた模様。
http://d.hatena.ne.jp/Gimite/20091129/1259495440
よって、今回は、json化は他のライブラリを使わず、その部分だけprototypeを使うように実装しました。
var json = Object.toJSON(obj);
ブラウザというよりもprototype.jsの問題ですが、高機能というのもアレなものだということで。
ajax 通信における post（本番） と get（開発時） の使い分け with firebugs
rfc には含まれていないのですが、IE系では get で指定できるURLの長さは2083文字という制限があります。たしかにそれくらいの長さになるドメインやディレクトリはとても考えづらく、それくらい長いパラメータをつけるならpostにしろよ、というのは極々当たり前の常識的な判断ですので、特に疑問や憤りを覚えず他のブラウザの場合でも素直に従うべきでしょう。
ですが、ajax で非同期にページに一部だけ更新する場合、その通信は「開発期間の間は」getで行った方が特なことがあります。
Firefox で ajax 通信を行った場合、「接続」タブを開いた状態ではそのページでリクエストされた全てのコンテンツのリクエスト状況が表示されます。勿論、ajax でリクエストされたページも表示されます。
ajax で呼び出す URL（上記だと「ajax_body」）は、大抵の場合、Ruby(on Rails）等のサーバサイドの言語で動的に生成されています。勿論、開発中でバグや未実装があることも多いでしょう。そのリクエストが失敗した（500系のステータスコードが返ってきた）場合、上記のようにpostだと追跡が難しいです。
そのため、開発期間中だけでも get で ajax通信をするようにします。
このようにすると、上記の「ajax_body」にリクエストパラメータが付属してつくため、そのパーツとなるページだけ、別途ブラウザで表示し、デバッグを進めることができます。
最近のajax は、jQuery.ajax 等を用いて実装されるケースが多いと思われます。getとpostの切り替えに大幅な仕様変更を伴いませんので、ちょっとした参考にして下さいませ。勿論、リリース時より前、例えば負荷検証やUIテストの前には、post に戻しておく必要があります。
＜script type=”???”＞の怪奇
最後に、ちょっと脱力してしまったお話しを。
＜script type=” text/javascript” language=”javascript”＞〜＜/script＞ で囲まれたjavascript は、firefox, safari, chrome では実行されますが、IE系, Opera では実行されません。
つまり、
type の中が不正、つまり「（半角スペース）text/javascript」等、想定されていないものが入った場合、ブラウザ毎に挙動が異なります！！
お気をつけ下さい。
