キモいキモいと言うなかれ

話題に乗り遅れた感があるが、「のあたん」「あやのたん」のValidateバナーのお話。非常にかわいいバナーなのでもらってきた。まずはHTMLのほうをサイトのトップに張ろうと思う

「Validateバナーをサイトに張っているのはキモい」という意見を見ることがあるんだが、それは言いすぎなんじゃないかなぁ。テーブルレイアウトのように誤ったHTMLを使っていてもチェッカーで100点だったので、ということでValidateバナーを張っている人間がいたりするが、それでもある程度のコードの質が確保されていることの証明になるわで。

もう少し本質的な部分を理解してHTMLを書いていますつーことを自己申告するためのバナーがあれば、そちら方面の要求は満せるとは思うんだけど。張った以上正しいHTMLに対するコミットを継続していくんだな、という暗黙の要求が課せられるという罠。

まあ、「こういうブランディング的なものを個人のサイトでやっていることがキモいんじゃ。気取ってるんじゃねぇ」という気持ちもあるかもしれないが、とにやく公の場に出すものに対する「よりよいものを」という意識が少しでもあるが故と思っていただければ、というこで。

RSS不完全燃焼

Mac OS X用ミニソフトのランタイムエンジン「Konfabulator」上で動作するニュースティッカー「News JP」なるものを見つけた。RSS情報を捕捉しデスクトップに最新ニュースを表示するわけだが、この手のツールってなぜか捕捉サイトを自分で登録できないものが多い。RSSつーの自体がまだマイナーな規格だから、どうせ自分で探さないだろうしプリセットでいいでしょ？って感じなのかなぁ。ウィンドウ開いていると見えなくなっちゃうし。

プリセットだけで構成されたニュースティッカー「イーヘッドライン」というのがある。こちらはRSSを利用しているのかどうかは不明なんだけど、Windows用のソフトで広告を絡めることでサービスの運営を維持しているような雰囲気があるですな。ソフトがタスクトレイに常駐して.Netアラートのようにポッポアップしてくる点はこの手常駐ソフトの悩み（つまりいざというときに隠れて見えない）をうまく避けているような感じ、正直これは感心。ただ、ページ下部の特許出願中って、こんなありふれた手法で特許を取る気なんでしょうか（￣△￣；。ウェブの肝であるハイパーリンクに特許を主張した某社のようなことを言いださねばいいんですが。

正直、RSSはもう少しコンシューマーの注目を集めてもいい分野のような気がするんだけど、知名度の点では今ひとつですなぁ。みんながそれと気が付かずに（Wikiやニュースティッカーのようなかたちで）使っているからかもしれないんだけど。RSSのポータルも、おいらはRSS-JP以外は知らないんですが、他に有名で情報収集できるところってあるんですかねぇ。

「はてな」を捕捉するニュースティッカー

昨日紹介した「News JP」というニュースティッカー。実行環境がバックグラウンドで動作するので、「NetNewsWire Lite」に比べると邪魔になりにくい、という利点がある。でも「News JP」は、2ちゃんねるのスレッドなんかは（板の移転がよくあるので）自分で任意のURLを埋め込めるようになっているのだが、基本はプリセット。プリセット以外にも、CSSコミュニティ関連のサイトの見出し一覧で並べておきたいトコロがあるわけで。でも、そういうったサイトのRSSは登録できない作りになっていまして、「うーん」とイマイチ感が拭えないのだ。

ただし、今日ちと使ってみようかなぁと思わせる出来事があった。今日新しもの好きのダウンロードを見てたら、早速バージョンがあがってて、はてなアンテナ対応と書いてあったのだ。というわけで、さっそく試してみますた。

こういうことができると、いくらか使う価値というのがでてきますなぁ。常時デスクトップ上にいて、「Command」+「Q」でうっかり終了してしまうこともないので、更新チェック用に自分もはてなアンテナのアカウントとって表示しっぱなしにしてみようかなぁ、という気にもなりそうだし。ただ、この大きさだと画面が1024×768だとキツいのが難点（￣△￣；。

「ふーん、がんばっているなぁ」と思いつつ、どうやってこれらのサイトを取得してるんだろうと思って、ソフトの設定ファイルを覗いてみたですよ。JavaScriptとXMLで作られているソフトだけに内部を調べるのは造作もないことですなぁ（￣△￣；。結果例のRSS-JPから情報を引っ張ってきていることがわかりましたよ。あそこのCGIでRSS化したデータをこのソフトが取得しているというシカケ。

それにしても今のままでもオモシロイけど、やっぱり欲しいよね。独自RSSを登録する機能。

RSS完全燃焼

最近しつこく取り上げている「RSS JP」が独自RSSに対応してくれたですよ。これでRSSビューワはこれで一本化してもいいかなぁ、と。だって、Konfabulator自体をレジストしちゃったし（￣△￣；。捕捉できるRSSが5つとは少いような気もしたんだけど、人に聞いた話ではNews JPのウィジェットファイル自体を複製してリネームしてしまえば、2つでも3つでも起動しておけるとのこと。なるほど。

ウェブの進化、ブラウザーの進化

おいらがウェブを始めたのは丁度ネットスケープの3.0ベータが出るか出ないかの頃。フレームなんちゅーものが出てきて「対応ブラウザってネスケだけでしょ。互換性を考えるとなぁ」なんて、笑うに笑えない会話をしてたのが思い出されたり。あの頃はテーブルでレイアウトをガチガチに組むも、ろくなオーサリングソフトもなかったから「この写真右側より左側に置くほうがいいんじゃない？」なんて言われた日にゃ、「お前はウェブの画面上で位置を動かすのがどれくらい大変か知っているのか」なんて、今じゃ「float:right」を「float:left」って書き替えるだけで済むようなことに必死になったり、そんな頃で。あの頃はウェブ技術もブラウザーの進歩が早くて、いつもキドキしてましたですよ。

それがある時期からブラウザーの進化はパタリと止ってしまったように感じる。フレーム以降のトピックを思い出してみようよ。IE 5ではXMLがサポートされメディアバーが組み込まれた。同じころモジラよりゲッコーが産声を上げ、標準サポートとあらゆるウェブ技術を組み込んだ巨大戦艦のようなブラウザーへと変貌していく。モジラやオペラで用意されたオープンなサイドバーとナビゲーションバー。……、おいらにはこのくらいしか思い浮ばない。これらも'96年当時のハァハァに比べると、温度というのは低いように感じる。

そういう意味では今はウェブ技術やその応用のほうが熱い気がする。RSSはネットスケープ4の頃の技術だが、XMLベースとして公式な規格になったこと、最近のblogブームと上手くマッチしたこともあり、一気に一般化した。はてなダイアリーや関心空間のようなキーワード連携による情報リンクの構築とか、Zopeのようなウェブアプリケーションの開発の敷居を低くするツールの登場とか。

ウェブがこれだけおもしろくなっているのに、ブラウザーは非常に元気がない。サファリのように使いやすさを堅実に固めていくのも悪くはないんだけど、ウェブ市場全体をひっぱっていくイニシアチブ性を持ったブラウザーっていうのがいなくなってしまったような気がして、非常にさみしかったりする。

個人的には次のモジラパーティで何の話題が飛び出すか気になるところだが。普通に考えればカミノとフェニクスの話題が中心か？ うーん（￣△￣；。

frame、去り行く技術

「フレーム」。いったいこの機能はなんのために生まれたのか。Netscape 3.xでの悪名高い独自拡張の産物でもあり、当時ネットスケープを必死に追い上げていたマイクロソフトもInternet Explorerで実装をし、一気に普及。W3Cもそれを後追いで容認し規格化、「HTML4.0 Frameset」という特殊な文書型を用意した。その後、時代の流れと共にフレームは有害だとする考えが生まれた。またHTMLが目指すマークアップとは方向性が異なることもあってか、最新のHTMLの規格からは外された、という歴史がある。

おそらくはHTMLに外部オブジェクトを含めるという、マルチドキュメントの流れの過程でフレームは生れたのだろうと考えている。極端な話を言えば自分のURLで表示されるドキュメントに外部のHTMLリソースを埋めこめる、それは便利だという発想だったのだろう。また、ひとつのドキュメントを複数に分割することにより、パーツの使いまわしが利くようになる。膨大なドキュメントの管理上、これはひとつの「グッド・アイデア」だったのかもしれない。

画面を分割して、複数ドキュメントを表示するという考えかたについては、フレームのようにHTMLで行うという試みのほかに、ブラウザー独自の機能として装備する試みも並行して行われていた。今知られているマルチドキュメント方式のブラウザーとしてはオペラがある。これはウィンドウのタイル分割や複数ドキュメントのカスケード表示などをブラウザーの機能として行おうというものだ。ひとつのURLの元に複数ドキュメントを「アーカイブ化」しようとしたフレームとは異なり、その後、複数の異なるページをユーザー側で好き勝手に指定していく「タブ化」に流れていったわけだが、Opera 7にて複数のタブのURLをまとめて「セッション」という形でアーカイブ化する機能が装備された点が、なかなか興味深く感じるわけだ。

これに対しネットスケープでは、HTMLで複数のドキュメントをコントロールする方法を選んだ。オペラがマルチウィンドウを自前で実装しているのは時期的に当然知っていたとは思うが、敢えてHTML側に組み込んで「ネットスケープならこんなホームページも作れますよ、便利でしょう」と宣伝しようと考えた可能性が高い。

こうした形で長い間使われてきたフレームだが、時代の流れとともにそれほど有用な方法としては認識されなくなってきた。ひとつはSSIやPHPなどによるサーバーサイトでの合成技術、およびDOMを使ったクライアントサイトでのドキュメントコントロール技術の進化だ。

フレームが利点とされてきたひとつに、ドキュメントを分割させることによって一部のみを更新させればよく、管理効率や処理面で有利だ、という点がある。ところがいざ使ってみると、一部分のみの更新で済む例は稀だ。

例えばグループウェアなどで作業画面とメニュー一覧を分割していた場合、右で今作業している画面が左のメニュー一覧のどの機能にあたるのがわからないと不便と思う向きもある。そうなると、現在選択中の機能はハイライト表示しよう、ならばこの機能用にメニューページ一覧を用意しようということになる。結局、機能ごとにマスターフレームを切り直したりして、ファイルは膨大な数となり管理効率は低下する。

メニュー一覧のコントロールにDOMを利用したり、フレームごとに文字セットを変化させるような事例においてはまだフレーム分割に活用の道は残っているが、現在ではそれほど多くのアドバンテージは残っていない。

もうひとつは、ブラウザーがフレームに合せて使い勝手を進化させているわけではないという点。スクロールマウスが出て来ていらい顕著になってきたが、ブラウザーをコントロールする外部機器に対してフレームはまだまだ不親切だ。これは何もフレームだけの問題ではない。現在多くのブラウザーに搭載されているサイドバーとワークエリアの間の切り変えも同じことが言える。ほとんどの場合は、いったんマウスでエリアをクリックしてフォーカスを当て直さないとならない。フレームの場合はこの問題が顕著化し、使いづらさが増していく。これをクリアーするためにいくつかの方法が用意されているが、そこまでの配慮ができる製作者にフレームを敢えて使おうという気があるのかどうか。

これから出てくる問題には、非パソコン機器での閲覧性の問題がある。PDAのブラウザーでフレームをサポートするものは増えてきたが、多くの場合画面は非常に窮屈となる。ナビゲーション用のフレームを切っていた場合、ナビゲーション部分だけものすごく狭く表示され、使いものにならない可能性がある。これはフレームの問題というより、フレームに頼り切った情報デザインをしている製作者の問題ではあるが。

フレームの有用性と有害性、そしてそのほかの代替となる技術の台頭を天秤にかけた場合、フレームの代替手段を選ぶ傾向が強くなっていっている。それは「他に代替があるのに、フレームの持つデメリットを無視してまでフレームを使う理由がない」という考えかたがあるように思える。

またしてもヘタレ

随分前にハードディスクの内容を入れ替えて以来、いろんなソフトのインストールが中途半端なままになっている。このページの上部にあるFlashも直さんといかんのに、まだインストールしていないし（￣△￣；。

ほかに半端になっているのが、以前活用してたUNIX由来のソフトとか。ターミナル上で動かすemacsの日本語関連の扱いがおかしかったので、その辺りを設定しなおすことにした。

とりあえず.emacsの確認。入力も出力も保存もEUCで行われ\C-x\C-jでSKKが起動することを点検。日本語の入力はセットアップが容易なSKKを利用している（ほかに日本語入力を使う場面ないし）。なのにemacsを起動するとSKKがロードされないですよ（￣△￣；。

昔SKKやAPELを入れたときのログを見ると、ちゃんと「/usr/share/emacs/」以下の各所にインストールされたことになっているんだよね。あれー、ってな具合でemacsが入っていそうな階層をあれこれ見てまわると、/usr/bin/に「emacs」に並んで「emacs-21.3.50」なんつーのが入っている。試しに起動するとエラーが起きるんだが、むーもしやと思って、「./emacs-21.3.50 -nw」と入れるときちんと起動する。さらに「emacs -version」とすると「Gnu Emacs 21.3.50.1」という表示が。ぐにゅー（￣△￣；。

.cshrc見るとちゃんと「alias emacs emacs-21.3.50 -nw」と書いてあるんだよね。こんなのいつ入れたんだ、と思ったんだが、過去ログにカーボン版が云々と書いてあるのでこの時に入れてそのまま忘れていた模様。しかもこれ、ターミナル経由でことえりから日本語入るじゃないですか。

SKKが使えないのは、Emacs 21.3からAPELもSKKも見えないからのようだ。つーわけで、apleとskkに関するインストール物を「/usr/local/share/emacs」以下の各所にリンクしたですよ。これで一件落着。

んでも、日本語を入れている際のターミナルの挙動がおかしい。変換中のインライン表示が確定後も残ったり、確定後にカーソルが数文字分飛んでしまったり。使っているターミナルはiTermってやつなんだけど、この端末エミュレーションソフトそのものの問題かもしれないので、JTerminalとKtermを入れて比べることにした。

JTerminalは半年ぶりに入れたけど、随分安定性が上っている。描画も綺麗だし入力も問題なし。こりゃ、iTermがヘタレだったのかも。

んで、Kterm、Kterm、あ、入れてなかった（￣△￣；。ついでなんで入れてしまおうと、Kterm 6.2.0をダウンロードしてきてmakeしようと思ったのだが、READMEに書いてある通り「xmkmf -a; make」としても「何だよ、そのコマンド」と言われてしまう。対策を調べるべくネット中見て回るが、みんな別に特別なこともせずに普通にこれでmakeしてる。うーん、とxmkmfコマンドつーのを探してみたら「/usr/X11R/bin/」に入っている。そう言えばコマンドサーチパスに入れてないわ、ここ（￣△￣；。いや、それでパスを切ったんだけど、まだ何かエラーが出る。

そういえば1ヶ月くらい前にアップル製のX11を一度入れて、その後アンインストール。そして再度X11を入れたという経緯がある。その際にSDKを入れ直したかどうかがわからない。それならアップルからX11のSDKを落してきてとにかく入れてみよう、としたところ「より新しいバージョンが入っているので上書きできません」という表示。えええっ!?（￣△￣；。

これ、よーく考えたら原因がわかった。落してきたSDKの日付けを見ると去年の12月になっている。今のbeta3が出たのはもっと後だったからこのSDKを入れるのは適切でない可能性がある。米国サイトから落してきたところ、今度はより新しい日付けのSDKだった。これでばっちりKtermをビルドできた。

KTerm上でも、SKKからの日本語入力は問題なし。利用者の多いソフトだから、安定しているのかなぁ。とりあえず以前の環境が戻ったので、去年の秋以来ほったらかしてたmule-ucsのインストールをしないとねぇ。とにもかくにも基本がなってないんで、またハマりそう。

ソースコードを文書中に

去年7月の「横広いやーん」以来、ソースコードの表示にはObject要素を使った外部文書の取り込みを行ってきたが、一部のブラウザーで不便が多いし、文書を別に置くのもなんだかなという気がしてきたので、リスト要素を使って文中に置く方法を取ることにした。

とは言ってもあくまでリスト要素はHTML中で一番意味の近いものとしての代替的な使い方。HTMLに吐き出す前の元の文書では、ソースコードであることを示す「source」要素に「line」という行を表す要素をネストしてマークアップするようにした。現在、属性としてsoure要素の「title」属性のみ用意している。

さてソースコードを載せる場合、文字参照を使った置きかえはもちろん、ソースコード自体へのマークアップが必要になってくる。あまり手間がかかっても意味がないので、スクリプトを使って一括置き替えをするのが得策。冒頭の記事の際に文字参照を置き替えるRubyスクリプトを作っているが、今回これを元にしてソースコードをおいら流のXMLに置き替えるスクリプト「sline-xml」を作ってみた。これくらいなら、スクリプト初心者のおいらにも楽勝♪ ターミナル上から「sline-xml 元ファイル名 > 変換後のファイル名」と入力して変換する。

例えば上記のコードをXMLにするために変換したとしよう。変換後のソースはこんな風に吐き出される。これをXML文書にコピペすることになる。

あとはこれをリスト要素として表示するXSLTスタイルシートを書けばいいわけ。何もかも全自動でやっているわけではないから、一時的な変換のみやってくれるスクリプトを書くだけで済んでしまうのがミソ（￣△￣；。いや本当はもっと全自動作業環境を作って楽がしたいですなぁ、ヘタレなんで今以上に高度なことは当面無理そうですが。