button 要素と IE のバグ
フォーム関連要素は使う機会が少ないので今まで気付かなかったが、IE の button 要素の実装にしてやられたという気がした。以下のコードを見て頂きたい。
<form> <ul> <li><button type="submit" name="btn1" value="1">Prev</button></li> <li><button type="submit" name="btn2" value="1">Next</button></li> </ul> </form>
2 つの提出（submit）ボタンを持った、ごくありふれた小さなフォームである。これを Netscape（Mozilla）*1で開いて[Next]ボタンを押すと、以下のフォームデータが Web サーバに提出される。
btn2=1
サーバサイドスクリプトは、送られたキーを基準にユーザの要求を正しく判別することができる。しかし IE 6.0 で同様に [Next] ボタンを押してみると、
btn1=Prev&btn2=Next
と、押すか押さないかに関わらず全てのボタンに割り当てられたフォームデータを送信してしまう。これではどちらのボタンが押されたか全く判別できない。正しく判別させるにはクライアントサイドスクリプトを用いるか、提出ボタンを一つにして select 要素等で選択させるしかない。 HTML 4.01 の仕様書によると、
1つのフォームに複数の提出ボタンがある場合、アクティブにされた提出ボタンのみが満足となる。
とあるので、IE の動作は明らかに間違った実装だ。実際、そんな事をやらかされると大いに困る。
もう一つ気が付く点として、IE は初期値として設定した value 属性の値を無視し、内容のみ送信した。悪い予感がしたので、このようなボタンを作って試してみた。
<button type="submit" name="btn" value="1" > <img src="./btn.png" alt="Submit" /> </button>
この画像ボタンを含んだフォームデータの送信文字列は、IE では
btn=%3CIMG+alt%3DSubmit+src%3D%22.%2Fbtn.png%22%3E
となる。予感は的中、見事に img タグを丸々送信してくれている。そんな馬鹿な。ボタンに画像を用いることの有用性は別として、これでは全く使い物にならない。
BUTTON要素が生成するボタンとINPUT要素が生成するボタンは、機能的には同等だが、 BUTTON要素の方がレンダリング能力が高い。
BUTTON要素は内容を持てる。例えば、画像を内容に持つBUTTON要素の機能は、type属性が"image"のINPUT要素とそっくり同じだが、BUTTON要素型は内容を持てるのだ
とあるが、IE がある以上かえって button 要素の方が使い難くなっている。もちろん Moz や Opera はそんな馬鹿なことはしない。 これらの問題点は、伝統的な input 要素を用いれば解決する。しかし折角 button 要素があるのにわざわざそちらを用いるのは今ひとつ潔しとしない。
button 要素を用いる具体的なメリットとして、たとえば属性セレクタを用いなくても押しボタンに CSS の規則を与えることができるというものだある。input 要素ではテキストフィールドやラジオボタンにまで同じスタイルが指定されているため、属性セレクタに対応していない IE では別途 class を当てるなどして割り振らなければならない。
IE のために button 要素を使いたいのに、やっぱり IE にそれを阻まれるというのは皮肉な話だ。JScript の style プロパティから JSSS もどきなスタイル指定をしても良いが、内部的には style 属性によるインラインスタイルシートと同様な扱いをされているということに気付いて使う気が失せた。最も、送信ボタンのスタイルを無闇にデフォルトスタイルから変更するのは、ユーザビリティ的な観点からしてあまり好ましくないのだが。
比較的 MS 製品支持派の私でも、久しぶりに IE がかなり嫌いになった。これでは button 要素を他の人に勧めようがない*2。提出ボタンはユーザインタフェース上のかなりクリティカルな位置を占める要素なので、後方互換性は最大限に考慮しなければならないだろう。またしても我々は IE に足を引っ張られるのだろうか。
Perlぷろぐらみんぐメモ
ここにあげる項目は、私が Perl を扱う上で日々心がけているものです。別に Perl に限った話ではないのですけれど、最近この言語の面白さにすっかり嵌ってしまったので。
- 関数を細かく分ける
- とりあえず基本から。ひとつの関数につき 20〜25 行以内がベスト。80 行を超える関数なんかがあったら、一体どんな処理をしているのか全く把握できない。デバッグも大変。
- グローバル変数を減らす
- これも基本。Perl はそのままでは全てグローバル変数化してしまうので注意すべき。よほどのことが無い限り、my で局所化しておくこと。一時的に使った大域変数も、使い終わったら積極的に undef しておくと良い。
- 変数・関数名をわかりやすく
- $tmp とか $flg とか $aaa のような、わけのわからない変数は作らない。一目で用途のわかる、意味のある名前を付けること。引数を格納する特殊変数 @_ も、そのまま使うと後から見たときに判別しにくいので、きちんと名前の付いた変数に代入（or リファレンス）しておくとなお良い。
- コメントをこまめに
- ソースが長くなるにつれて内容の把握が次第に困難になってくる。そんな時にコメントが記述されていないと、かなり作業効率が低下する。面倒でもきちんとコメントは加えること。せめて関数の大まかな用途くらいは記述したい。
- ヒアドキュメントは使わない
- 一見便利そうなヒアドキュメント（
<<）だけれども、ソースコードをぐちゃぐちゃにする最悪の代物である。無駄に関数が伸びるし、うかつにインデントできないから構造を把握しにくい。一箇所にまとめて使うか、外部にテンプレートを用意しておけばそれだけでかなり綺麗になる。 - 出力はテンプレートを用いて行う
- CGI として使用する際、HTML の定型部分は全てテンプレートを介して行う。可変部分だけをリストとして取り出してやり、纏めて変換してやるとそれほど処理量も増えない。二重、三重にテンプレート変換を加えることで、可変長のデータ表などにも対応できる。
- コード内に日本語を書かない
- コメントを除くソースコード内全てには、日本語を使わないほうが良い。文字コード関連の問題もあるが、それ以上に出力する文字列がごちゃごちゃと散りばめられているとコードが見難くて仕方ない。全て外部ファイルにまとめておくと良いだろう。メンテナンス性も向上する。別に日本語に限らないのだが、これを書かないようにしておけば自然と他のベタテキストも記述しなくなっている。プログラムの国際化が簡単になるという意外なおまけも付いてくる。
- 必然性の無いリテラルは全て定数化
- ディレクトリ名やループ最大数など、後で変更の余地がある部分は全て定数（costant）プラグマを用いるとメンテナンス性がいくらか向上する。後に他の人がプログラムを再利用する際にも、変更が簡単なので便利である。
- プロトタイプ宣言をする
- Perl はプロトタイプ宣言しなくても普通に関数を使用できるが、メソッド呼び出し等を除き、ほとんどのサブルーチンにはプロトタイプ宣言をしておく。引数の指定によりデバッグがしやすくなるし、ライブラリの上部にインデックスとして置いておく事で検索性も向上する。
- シェルコマンド実行部分に充分注意する
- open 関数の第二引数など引数の値をシェルコマンドとして実行する部分には、ユーザの入力をそのままぶち込む等危険な真似は絶対にしない。重大な XSS 脆弱性を持ったスクリプトになりかねないからだ。こまめにサニタイズするか、sysopen など危険性の低い関数を使う。eval 関数も結構怖い。
HTMLレポート
うちの大学の一部の実習は、レポートのフォーマットとして HTML 形式が義務付けられている。これは大変良い事だと思う。
むしろ HTML は面白可笑しいほーむぺーじなんかよりも、よっぽどレポート向けのマーク付け言語ではないかと思う。きちんと階層的な見出しがあって、引用があって、著作情報があって、参照画像がある。実習レポートはまさに HTML にうってつけの逸材だ。
しかし、それはもちろん書き手の使い方次第である。目の前で、こんな会話が展開されていた。
A.「th と td って何が違うん？」 B.「ああ。th だと太字になって、td だとならないんだよ。」 A.「それだけ？」 B.「うん。」 A.「そーなんだ。なんだ、それだけかー。」
ちなみに補足しておくと、多くの人が本文全体を center で括る癖がついているので text-align が継承されて、中央揃えされる規則には気が付かなかったらしい。
― そもそもそれ以前の問題だが。
Alertbox: 訪問済みリンクの色は変えるべし（2004年5月3日）
Alertbox: 訪問済みリンクの色は変えるべし（2004年5月3日）
メニュー・リンクを画像にすることの最大のデメリットは、訪問済みリンクを見分けられなくなることだと思う（あの小汚い枠線を表示したがる人はあまりに少ない）。クライアントサイドスクリプトで訪問済みか否かを判断する手段が無いのだから仕方が無いのかもしれない。
a:link{background-image:url("normal.png")}
a:visited{background-image:url("visit.png")}
a:hover{background-image:url("active.png")}メールサービスと代替手段
私は大学の複数の端末からログインする可能性があるので、Outlook のようなメールクライアントを用いるより Web ブラウザ上で動作するメールサービスのほうが何かと都合が良い。
しかし困った事に、多くの無料メールサービスではクライアントサイドスクリプトや meta タグによるクライアントプルが利用に必須となっている。それらを用いなければ正常にログインできなかったり、削除や返信といった作業を実行出来なかったりする。これは非常に困った事態である。
Web サーフ時も普段から注意しているほうだが、悪意あるスクリプトが実行されたり、ウィルスを食わされたりした経験は殆ど無い。余程危ない橋でも渡らない限りは滅多にそのようなものに遭遇することは無いだろう。それに比べて私のメールボックスには、毎日呆れるほどの量のスパムや謎の添付付きメールが届いている（最近『アドレス変更しました』というsubjectのものがやたらと多い）。
そのような状態を、何の防護策も無しに渡り歩くのはかなりの冷や汗ものだ。スクリプトやクライアントプルを無効化するだけでも、幾らかは対策になる。環境上、高度な対策ソフトを導入するのが難しいので、最も簡単な方法がそのくらいしかないのだ。
hotmail、Yahoo、Goo、AAA!Cafe など有名どころを色々と試してみたが、なかなか快適に利用できる所は未だ無い。要望メールも出してみたが、所詮無料サービスではあまり期待できないだろう。是非 Web メールサービスにおけるスクリプトの代替手段の提供をして欲しいと思う。こういう時のための“快適なWebデザイン”なのではないだろうか。
Perlとテンプレート処理
最近、再び Perl によるサーバサイドのプログラムに手を出している。
処理と出力がごちゃ混ぜになった小汚いプログラムが嫌いなので、私はテンプレート・ファイルを使うのが好きである。外部にある程度完成させておいた HTML を用意しておき、動的に変更する部分だけを置換によって操作する。PHP や ASP の中途半端な埋め込み型スクリプトよりはよっぽど綺麗なソースになるのが最大のメリットだ。
サーバ側の処理量増加が不安だったが、ローカルマシンで 10000 回ループなど色々試した結果、差は 10% 強だった。これを多いと見るか少ないと見るかは微妙なところだが、趣味で作るスクリプト程度ならあまり問題は無いだろう。
色々な汎用関数を作りながら、何かちょっとしたゲームのようなものが出来ないか現在検討中である。
Web広告とテレビCMの違い
私はテレビをあまり見ない。特に、民間放送に関していえばほとんどお目に掛かることがない。なぜならばテレビ CM が大嫌いだからだ。テレビ上のそれは、Web 広告よりもはるかに図々しい。一分余りの間、画面全体を完全に占拠し、騒々しい音楽や派手な演出と共に存在感をアピールする。邪魔どころの話ではない、その間は完全に番組が中断されてしまう。
それに比べて Web 広告は慎ましいとも言えるだろう。確かにポップアップ・ウィンドウやアニメーションするバナー画像は画面への集中力を妨げるが、記事自体を閲覧不能にすることは稀だ。スプラッシュページに関しても、配慮ある Web サイトでは Skip ボタンが用意されている。テレビ CM をスキップするという芸当は、現在のアナログ TV の技術では不可能な話だ。
しかし一般的に言うと、Web 広告やスパムメールは圧倒的に嫌悪されるのに対し、テレビ CM はいまだに健在である。印象でも、商業効果の面でもこちらのほうが優れた結果を弾き出している。名物 CM や CM から生まれた流行歌なんてものが年にいくつか登場するが、「名物バナー広告」なんてものは聞いたことがない。
この違いは何だろうか。
ひとつの答えとして、それはユーザの姿勢にあるだろう。テレビはソファに寝そべりながらぼんやり見るものに対し、Web は極めて能動的に、目的を持って閲覧する場合が多い。しかし、何ともなしにネットサーフするケースもあるだろうし、完璧な答えとは言えないかもしれない。
私は民放をほとんど見ないので、なぜ多くの人がその大袈裟なテレビCMを目にしながら、なおその番組を見続けるのかが理解出来ない。是非そのあたりを訊いてみたいところである。ひょっとすると、成功する Web 広告の秘訣がそこに隠されているのかもしれない。
