2001-02

Alternations

2001-02-27T13:30:00+09:00

2001-02-26T08:30:00+09:00

2001-02-19T20:30:00+09:00

2001-02-16T14:30:00+09:00

2001-02-06T22:30:00+09:00

2001-02-04T22:30:00+09:00

Feelings

2001-02-28

STAND UP TO THE VICTORY!

アニマックス(誤変換:兄マックス)で3月からVガンダム(∀ではない)が始まるらしい。テーマソングのプロデュースが川添智久さんなので親近感があるのだ。ピック貰ったし。

驚き。

HTML4の仕様邦訳)を見る限り、UAは推奨シート・代替シートの切り替えを最低限サポートする必要があると読みとれます。そもそも複数文書で「同じtitle」の「違うシート」を参照する可能性もある事などを考えると、これ以上の事は安易に「仕様」で定めるわけにはいかない──というかこの辺になるとWAIのUA開発者向けガイドライン邦訳)などの範疇だと思うのですが。

シート切り替えは最低限求められる機能。仕様を満足しつつ実用に耐えるような実装の工夫をするのがベンダの仕事。cite属性から引用元を辿れるようにしたiCabやLynxを評価するか、それともcite属性をアンカーのように動作させるべしと明言しなかったW3Cを批判するか。「仕様」に全てを求めても埒が明かないと思いますが……

まぁ、仕様に穴が多いのは事実ですけども。

ウチの日記を読んでいて突っ込んでくれる人がいるとは知らなかった。ちょっと照れくさい。……引用する際にソースコードを見てコメントアウトしている部分を見つけたけど、これをサルベージするのは著作権法に引っ掛かるのかな?……

仕様書を批判する事と、その仕様に則ったアプリケーションを批判する事はどちらもより良いユーザーエクスペリエンスの提供と言う意味で目的は一致しているかも知れないが、アプリケーションを評価するのは使えば出来るので簡単だ。HTMLの仕様になると、それを使うのはコンテンツ作成者だけに絞られる。その穴を埋めるように要求するのは義務だ。……いや、だからと言ってW3Cに楯突く程の根性はないんだけど。

ユーザーエクスペリエンスの提供は完全にUA側の仕事だとするのであれば、その実装の理念を提供する仕様が曖昧だと結局ツケはユーザーに回ってくる。特に、rel周りはその使い方すら曖昧な状態で、nextでナビゲーションメニューを記述している所まであるサイトのコンテンツを全て先に読み込まれては迷惑千万だ。見ないコンテンツだってあるのにCSSの仕様書SVGの仕様書に至ってはプロフィールの無い状態でrel="CSS-properties"を使っている。普及していないもんだからやりたい放題だ。

引用要素のcite属性にアクセス出来ないのは明らかにUA側の問題だが、a要素の様に普及しているものならいざ知らず、情報を提供することを目的としているとだけ書いて代換スタイルシートのように対応するべきとは明言しなかったのにも問題がある。さらに言わせてもらえば、qなら仕方ないかも知れないがblockquoteなら属性では無く対応していないUAの事も考えて何らかの先頭要素(theadのようなもの)を使用するべきでは無かったのか。

複数文書で「同じtitle」の「違うシート」を参照する可能性もある事に対するソリューションを提示するなら(2001-01-10にも書いたけど)、C言語の#includeやCSS2の@importを真似ると言う方法もある。具体的に言うなら、<link rel="linkinclude" type="text/html" href="云々">と書く事で参照先のlink要素をこちらに書くのと同じようにする事(しかしlinkincludeなんてセンス無い名前。もっとかっこいいの無いかな?)。無論のURLの変換は行わなければならない。これなら、「同じスタイルシート群を使用するかどうか」の情報のみでなくrel="made"等も共有する事ができる。ウチのサイトの場合、ちょっと違うような気もするのだがフルナビゲーションをrel="bookmark"で記述しているのでこの機能があると大変有り難い。deegg君ともメールで話したが、同じサイト内であれば共有出来る情報は結構多い。色んな文書でインデックスやコンテンツやプロパティリストや同じナビゲーションバーをいくつも書いているW3Cだってそう言った事に気付いている筈だ。

僕がW3Cの仕様を「理念ばかり先攻」と言ったのは、もうひとつある。JavaWorld 2000年12月号内XML WORLD特集XMLボキャブラリ作成のポイントを知る[中編]にある精密タギング症候群にW3Cのメンバーがかかっていやしないかと思うのだ。特にtableなんかにその傾向が見られる。Netscapeに便利なタグを発明された事がそんなに嫌だったのか、table周りの精密さは変質的だ。IE5:macなんかは一応thead等に対応はしたが、結局CSSも含めた実装では不安定なままになってしまった。ややこしいタグの構成はユーザーだけではなくデベロッパーにまで迷惑がかかる。

もっとも、先述のlinkinclude精密タギング症候群ではないとする根拠はない。ただ、僕の実感として必要、不必要を感じたのだ。

ジュラシック・パークIII

ロゴがティラノサウルスからヴェロセラプトルに変わってるぅ。最近はスカベンジャーだとか言われてイメージが低下している所為かな?

Mozilla0.8

サイドバーにようやっと履歴が標準搭載された。N6版は何処や?

IEのエクスプローラバーをパクっておいて一番便利な履歴を搭載しなかった事について思うのは、実はMozilla.orgの人間はMozillaを使っていないからではないか?そうとでも考えないと説明がつかんぞ。それに、今まで表示されていたツールチップが真っ白なのは嫌がらせか?

表現?

2001-02-23の日記を読み返していて、何処が違ったんだろうかと考えた。多分、僕はLaTeXの入門書によく出てくるロゴの埋め込みをやりたかったのではないか。ただ、それをやるには現行のシステムでは解像度が低すぎた。ただ、ひょっとしたら、SVGがその答えになるかも知れない。

使っていて困るナビゲーションバー

Back
一つ前の文書に行くのか、それとも一つディレクトリが上がるのかが判らない。Previousの併用等を考慮してクリックしなければならないので不便。ディレクトリが一つ上がるのならそのディレクトリの名前にしてもらいたい。
ページ最下部のTop
トップページに行くのか、ページの先頭に行くのかが判らない。現在のURLとステータスバーに現れるURLを相対的に見比べる必要があり不便。
ページ最上部に位置するフルナビゲーション
自分はそのコンテンツが見たくてジャンプしたのにいきなり他のコンテンツへのリンクがずらっと並んでいる。下手にリストで書かれていたりすると画面がそれで埋まってしまい一番見たいものが初期状態で全く見えないので不便。
ページ毎に名前や位置の違うナビゲーション項目
同じ性質のリンクに違う名前や違う位置を割り当てていると、クリックする時にカーソルが一瞬迷うので不便。

僕自身は自分で使っていた経験から現在のような最下部にディレクトリを表示するだけの簡単なものにしたが、その理由の大半はジオガイドと同じ「在って無きがごとし」ものになっていたからだ。

ZOIDS

やっぱりリノンの重武装ガンスナイパーは変。

格闘戦に優れていると言う事は、「シュナイダー」は格闘家からのネーミングなのか?しかし「格闘 シュナイダー」で検索したら銀河英雄伝説とか出て来たんやけど……

機獣警察パトゴジュラス

ゾイド。それは戦闘用に開発された機械生命体の総称である。最強兵器として君臨していたが戦争は集結。だがテロ行為が増加して行く中、帝国と共和国は共同で遊撃部隊を設立、これに対抗した。通称、ガーディアン・フォースの誕生である。

前回の暴走族の話でタイムパトロールっぽいタイミングで現れた警察がゴジュラスを使っていて、しかも二体。例のMkIIカラーリングだから目の色を緑ではなく赤にすれば完璧に……

シリーズ仇敵は、やっぱり黒いアイアンコング。MkIIの赤い部分まで黒く塗りつぶしたのがいいかな。

研摩クリーナー

「極細の繊維」って、まさかアスベストでは無かろうな?

2001-02-27

ジオガイド

広告によって最悪なHTMLを埋め込んでくるものとaltもついたましなものを埋め込んでくるものがある。だから、Another HTML-lintで採点する時に変な差があるのだ。あ?て事は場合によってはW3CのValidatorも通ると言う事か?……やっぱり。

標準仕様

ウチのサイトをマルチスタイルシート化するにあたって、Netscape6のスタイルシート選択メニューの挙動を色々調べたが、Mozilla.orgはスタイルシートに関しては良くやっている。問題なのは、W3Cの規格が実際に使うには中途半端極まりない事だ。この辺はPNGも同じ。

alternateなスタイルシートを指定出来るお蔭でユーザーがスタイルシートを選べる、までは良い。だが、一つのサイト内では大抵同じスタイルシートを使用する事が多く、もしユーザーが代換スタイルシートの方を使いたい時、一つページを移動する毎にいちいち選び直さなければならない。面倒だ。(Netscape6をお持ちの方なら、表示メニュー、スタイルシートを使用、の項目から代換スタイルシートを選ぶ事が出来ます。)

こんな事は、実際に代換スタイルシートを用意するHTMLを書けば誰にでも判る事だ。それに気がつかないと言う事は、W3Cの人達は理論ばかり先攻させて実装すると言う事を考慮に入れていないのではないか?HTML4/CSS2の仕様とAmayaの実装のギャップ等も考えると今のW3Cの仕様策定方式には疑問を感じざるを得ない。

だから、

「馬鹿言っちゃいけないよ。でも、あり得ない話ではないな」大爆笑だった。

2001-02-26

犬小屋

ウチの大学のキャンパス正面の向かい側、車道を挟んでアパートが二件ある。どちらも大学の生協が営業している。当然、学生ばかりだ。僕もそこに部屋を借りようかと思った事があった。だが、溜り場になると思ったので、部屋は別の所に借りた。

その二件のアパートに挟まれるようにして一件の民家がある。ひょっとしたら学生の下宿を入れているかも知れない。その民家は正面、つまりキャンパスを向いている方にけっこう広い庭がある。砂利で敷き詰められていて、洗濯物干や鉢植えや意味不明のブロックやその他諸々が置いてある。

吐息が白く凍る朝、停留所近くの信号機が青になるのを待っていると、何処からともなくガタガタと言う音が聞こえて来た。音を追うと、その庭でバケツの頭をした犬が地面を突っついていた。

何をしているんだろうと思って見ていると、犬はバケツの頭を外して普通の柴犬になった。体を震わせながら鼻をペロッと舐める。いくら天然の毛皮に包まれているとは言え、それ以上に重武装の人間が寒さを感じる気温だ。寒くなかろう筈がない。僕が見た限りでは、傍に犬小屋一つ見当たらなかった。

凍るような夜を、犬小屋一つ与えられずに過ごしているのか?そんな事を気にしながらも、信号機が青になり、周りの人間が歩き出す気配に釣られるようにして僕は横断歩道を渡った。また、犬がバケツの底を突っつく音が聞こえて来た。

しばらくして、その犬の事を思い出して庭を振り返ったら、柱に繋がれたままぐうたら寝転がっていた。

収穫

IE5.5SP1では、フォントサイズのpx指定が効かない。……何で?

ガイドライン

高校の文化祭の時、実行委員会が模造紙に書く文字の大きさ等のガイドラインを発表し、これに準拠しない族に注意し、ひどい時にはペナルティを与えると言った事をやったことがあった。その時、Wb君がそれに対して猛反発し、「見易いかどうかを決めるのは俺達だ。模造紙の数に制限だってある。何でそんな事をお前達から決められにゃならん。」と言っていた。その時は、模造紙に書く字の大きさで何をそんなに反発する必要があるのか疑問だった。

最近になって、WAIのガイドラインに一生懸命準拠しようとしていたりAnother HTML-lintで高得点を一生懸命取ろうとしていたり、自分でサイトの「見易さ」を考えていたのか疑問に思うようになった。

例えば、tableにスライスした画像を埋め込んだりしてレイアウトしている場合、少なくとも彼等に知っている環境では問題なく見られるのであり、彼等の知っている環境では最も見易いサイトであるはずだ。tableで凝ったレイアウトをするような人達は、少なくとも自分のサイトの「見易さ」を考えている人達であり、決して何も考えずにいる訳ではない。

さて、ウチのサイトは、見易いですか?

10:30:00

ジオガイドの書式が変わったのか、Another HTML-lintの採点基準が変わったのか、突然大幅にに減点されるようになった。

…lintのバグ臭い。nameを指定していないaにアンカー名 `SCALAR(0x82033a8)` は 110行目にもありました。云々と、意味不明のメッセージが出てくる。Perlの処理の中でアンカー周りがおかしいのだと思う。

ジオガイドのお蔭でW3CのValidatorを通らなくなっていたのでバナーを削除。GeoCitiesの馬鹿野郎〜ぉ!

2001-02-25

WAI

僕がWebを見て回っていて、所謂WAIのガイドラインに従ったページの印象は「しょぼい」か「ごてごて」に大別される。

しょぼいレイアウトのページに共通してみられるのは、h1その他に borderを適用しているだけ、と言う状態だ。いや、colorやその他も一応指定している事は指定している。けれど、そのレイアウトにborder以上のものが見出せない。.exe君に言わせれば、「耳がついているだけ」のもの。僕から言わせれば、hrをいっぱい使ったような印象だ。だいたい、どのページも同じに見える。

(しょぼいに較べて圧倒的に少ないが)僕的にパッと見て「凄い」と思えるページの場合だとだんだんそれが鬱陶しく感じるようになる。だけど、CSSをオフにしてあの味気ない画面で見る気もさらさら無いので、ごてごての状態で閲覧する。ごてごてのレイアウトのページに共通しているのは、グラデーション等を表現する為にけっこう大きな画像を使う事だ。それがサイトの随所に見られる為、全体のダウンロード数はかなりのモノになる。しかも、img要素のように枠が表示される訳ではないからどのくらいダウンロードしたのか把握出来ない。あと、ごてごての印象を深めるものとして、borderの使い過ぎもある。僕も最近インライン要素にborderを指定していたが、文字色やその他の書式で示した方がスッキリする(どの色がいいのかが一番迷う所だが)。

それで、僕はh2と引用以外にborderは使っていない(インラインフレームは引用かな?)。引用に使うborderも、ごてごてした印象を排除する為にsolidにした。h2に使ったものは少々特殊な方法で「画像を使った表現」を擬似的に再現している。まずmarginを深くマイナスで取り、続いてborderで「見出しを修飾する背景」を描く。そしてpaddingのマイナスは効かない為text-indentをまた深くマイナスで取る。こうする事で、普通は背景画像を使う所をborderで済ましている。ただ、この方法だと複数行に表示された時に変な事になる。ここでは、h2に改行する程長いフレーズを書く事はないだろうと判断している。

残念な事に、画像を殆ど使わずごてごてせずに目を引くようなページは未だ存在していない。WAIから離れるなら、僕はAppleのページが一番だと思っている(身内贔屓)。Sunのページはごてごてしているし、Microdoftは良くも悪くも大雑把だ。SGIやAdobeはいい線行っているけどもうひとつ。所謂「ポータル」になると僕にとっては有用な情報を効率良く閲覧出来る場所は全く無し。

一番困るのは、文章系のサイトなのに文字サイズをpxやptで絶対指定しているサイト。WAIのガイドラインでもこれは許されていない。胡麻粒みたいに小さな文字が並んでいる所や、一円玉みたいに大きな文字のサイトを見ると、「どうしてデフォルトが嫌なんだろう?」と穿ちたくなる。良くも悪くも、一番慣れ親しんでいるデフォルトが一番見易いのに。

Mozillaに思う事

オープンソース式の、細かいバージョンの違いがブラウザに存在する事で一番困るのはどう言う実装を前提にすればよいのか分からない事だ。正式リリースが殆どの現在の状況でも、ブラウザ毎の実装の違いで四苦八苦しているのに、Mozilla1.0、Mozilla1.1、Mozilla1.2、Netscape6、Netscape6.5と細分化されたバージョンが存在していてはどれにあわせればいいかわからなくなる。どこかで「正式バージョンなんか気にせず、自分の環境で安定したバージョンを使えばいいんだ」と言う記述を見かけた事があったが、ブラウザがそんな状態だとWebマスターが困る。結局、最低ラインに合わせるしかなくなるからだ。

ECCO's ECHO on IE5.5SP1

deegg君に頼んでスクリーンショットを貰ったが、IE5:macで「これでよかろう」と思ってレイアウトしたものがあちこちで狂っているのが分かった。annotationのwidthを50%にしているのは、div.noteに対する50%なのにウインドウに対する50%と勘違いしている臭い。IE:winだけをエスケープするCSS記法ってないかね?

Internet Developer

developer.apple.comのサイトマップで見つけた。Appleにしてみればサイトの構築と運営だってれっきとした開発な訳だ。それはさておき、ここのCSSのコーナーなんかはけっこう有用な情報が揃っている(僕にとって)。やっぱりあのAquaっぽいページレイアウトを実現する為に色々やったんだろうな。フォームに関するCSSとか、DOCTYPEに因るレンダリングの違いとか、僕も少なからずぶちあたった問題について詳細に書いてある。

2001-02-24

収穫

MacのAPIの場合、C言語だからJavaでExceptionthroughする代わりにOSErrを返す様に出来ている。……Cのプログラマには常識?

疑問

void型のポインタでキャスティングって何?

2001-02-23

Rip. Mix. Burn.

うへぇ。Flower PowerBlue Dalmatianて、趣味悪い。アメリカ人と日本人って美的感覚に差はあるだろうと思っていたけど、こんなもんを商品化するとは。まだPowerBook G4の方がマシ。これなら昔PowerBook 1400でやっていた透明プラ版を使ったやつの方がいいんではないの?

それにしても、映像の次は音楽ね。順番が逆になった気がするけど、確かに他のPCと較べてMacはマルチメディア関連の標準装備が充実している所為で割高な部分もあるから通常ならハードウェアシンセサイザを必要としていたMIDI演奏をQuickTimeによってソフト一本で実現していた事や、スピーカーに注ぎ込まれる惜しみない素材、高性能のディスプレイ等それを売りにしない手はないね。ただ、iTunesでMixはやり難いと思う。

話は戻るけど、やっぱりiMacは外観もカスタマイズ出来るようになるのかね。Aquaとの兼ね合いもあるから、難しいだろうとは思うけど。いや、Aquaのアピアランスの中にFlower PowerBlue Dalmatianが無ければ買った人が可哀想だぞ。

MathML 2.0

速ッ。もうv2が勧告になってしまった。やっぱり実装系が普及していないとW3Cもやり易いんだろう。なまじ普及していると既存の実装系との互換性もあるから問題がややこしくなる。大体、仕様通りに動く実装系だってその後の拡張とは全く相容れない事N4が好例もあるし、拡張する事を前提にした場合だってその前提とは違った拡張が求められる事だってある。いや、どちらかというとそっちの方が多いと思う。XPじゃないけど、拡張等端から考えず、思い切って互換性も無視した方が遥かにスマートになる。Web標準と開発手法とではその方法論が大きく違う事は承知の上で。そう言う意味ではVMLと言う実装系が先に、しかもMicrosoftと言う巨大なバックボーンを持って存在していたSVGは、AdobeのSVG Viewer 2.0のベータリリースで更に苦しくなっている。……何時までCRなんだよぅ……

拡張性の事を言うのであれば、SGMLではその為に「知らないタグは無視」と言うオプションがあって、HTMLでは確かそれがオンになっていたはずだから、ruby要素等の実に便利な要素を使ったり、特定のスタイルシートをオフにするIEの拡張属性を使ったりするのは決してHTML4的に不正では無いはずだ。なのに、僕自身はAnother HTML-lintに文句を言われるのが恐くて使うのをやめた。仕様書って恐い。

Web

Webに於ける表現手法の実験として、今日の日記は目一杯imgタグを張り付けてみたが、やっぱりマークアップのやり過ぎは鬱陶しいだけだ。つくづくHTMLって言うのは文章系の付票言語だ。マルチメディアの中にテキストを包有する事は出来るけど、メディアの一つであるテキストの中にマルチメディアは包有できない事がよく分かった。

同じように、abbr要素やacronym要素の使い過ぎは音声ブラウザにとっても鬱陶しいはず。一ファイル内、或は一セクション内での重複は避けた方がいいだろう。

Opera:mac

は、Worldwide Downloadsだとよ!Asciiしかマトモに処理出来ないブラウザにWorldwideを標榜する資格なんて無いね。フリーで多言語に対応しているMozillaを少しは見習え。スクリーンショットを見てどうしても「再読み込み」にしか見えないボタンだが、あのアイコンはNeXTじゃゴミ箱のアイコンだったんだよ。確かに、インターネットはゴミ箱と呼べない事も無いかもね!

祝!

DEVICEREIGN WEB RINGバナー正式採用!

……tableは使わないでって言ったのに……書き換えはOKみたいだから書き換えるか。

2001-02-22

呼称

厳密に考えてみれば、「太平洋戦争」と言うのは「太平洋を挟んで行われた戦争」であり、西暦1941年に行われた真珠湾攻撃以降の太平洋上での主に日本軍と連合軍の戦闘行為を総称してそう呼ぶものである筈だ。よって、日本軍が当時の満州を独立させたり欧州の植民地を取り上げたりした行為は太平洋戦争には当たらない。産経新聞によると、真珠湾攻撃の後で「支那事変を含めて大東亜戦争と呼ぶ」と言うのが当時の日本の呼称の由来であり、その後GHQが「太平洋戦争」の呼称で「大東亜戦争」の詳細な経緯を記したのが取り敢えず普及したものらしい。そう言う意味では、侵略行為を「太平洋戦争」と呼ぶのは無理な話ではない。ただ、ややこしいけど。当時の日本の呼称に基づくなら、「大東亜戦争」であり、それが嫌なら「東アジア・東南アジア戦争」とでも呼べばいいだろう。特に、占領政策に関してを言うのであれば「太平洋戦争」という呼称は誤解を招きやすい(それが狙いなのだろうが)。

「欧米の植民地政策はただ単に搾取する為だけのモノだったが、日本のそれは文化を否定し、自分の文化を押し付けるものだった。だから日本は悪い」とする人も居たが、欧米の場合文化もヘッタクレもなくそもそも人間として扱っていなかったのだから日本の政策の方が遥かに進んでいたことになる。大体、人権意識の低かった当時の日本国内でも文化の押し付けはあったのだから、植民地の住民が不当に扱われたと言うのは現在の人間の言うことだ。それに問題が無いとは言わない。だが問題があったのは占領政策ではない。

ツインテール

愛蔵版ウルトラ怪獣大全集 第25刷より

地底怪獣 グドン
身長:50m 体重:25000t 出現地:奥多摩・第二砕石場
中生代ジュラ紀の恐竜の一種で、性格は荒っぽく好戦的だ。ツインテールを常食にしており、手のムチと頭の角が武器。
古代怪獣 ツインテール
身長:45m 体重:15000t 出現地:新宿ビル工事現場
マットシュートを受けた卵が巨大化し、その中から生まれた。上部の二本の尾を敵に巻きつかせ、麻酔液を注射する。

偽春菜関係のサイトを回っていて時々「ツインテール」と言う言葉を見るので、その度にあのケムラーみたいに間抜けな顔を思い出してしまう。尾部(上部?)にある緑に光る模様は子供心にカッコよかったのに。それにしても、グドン(さっきからウチのことえりは愚鈍愚鈍と変換してくれるが、彼はそのムチでウルトラマンと同等に戦った兵だ)に常食されていると言うのはラドンに喰われるメガヌロンのようだ。と、言うことは「ウルトラマンコスモス」でトリプルテールとして復活……する訳無いか。

2001-02-21

G

確かゴジラの事をGと呼んだのはゴジラvsビオランテの作戦海図やM6000TCシステムのフィールドマップでゴジラを示すのに怪獣フォント(他にいい呼び方を知らない)のGの形をしたプラスティック板を置いていたのが最初だったと思う。

時を置いてガメラ2の予告編が現れた時、ガメラの事をGと略してGIIとでっかくスクリーンに叩き付けていた。その後ガメラ3の予告編でもGIIIと言うロゴが使われていた。ただ、これは予告編のみの話で、劇中では一回も使われなかった。ギャオスと紛らわしいからだろう。ゴジラvsスペースゴジラ直後の予告で、ゴジラvsデストロイアの事をゴジラ7(セブン)と呼んでいた(それ以前にもある友人がゴジラvsメカゴジラのことをゴジラ5(ファイブ)と呼んでいた)ので「ゴジラもGになったらややこしいな」と思っていた。

……そう言えばゴジラvsメカゴジラで既にUNGCC:国連対G対策センターが出来てたっけ。パンフレットの表記のままなのだが、どう考えても対が二つあるのはおかしいよな。あ、ゴジラvsビオランテで既にG細胞とか警戒体制規定での呼称にGを連発していた……大森さ〜ん(泣)。

ゴジラ2000ミレニアムになると、硬そうな自衛隊司令官がGを連発するようになった。あれは聞いていてこそばゆく、略せば軍隊っぽくなるもんでも無かろうに、と思った。それが分かったか分からないでか、ゴジラ×メガギラス G消滅作戦ではとうとうタイトルにGが現れたものの、本編ではあまりGは使わずとか言う事が多かった。要望としては、何かのシンボルとか以外にはGと略さずにちゃんとゴジラと呼称して欲しい。

……ちなみに今回のようなマークアップを「やりすぎ」と言います。

参考までに

第一種警戒体制
Gの活動が物理的以外の科学、地質、気象、精神などいかなる点でも一つ確認された場合。
第二種警戒体制
Gの活動が声、動きなど物理的に確認された場合。
第三種警戒体制
Gが出現した場合。
第四種警戒体制
Gが日本のある特定地域に上陸することが確実とされた場合。
国土庁・特種災害研究会議

以上の警戒体制下でどのような対処をするかは明記されていなかった。劇中では黒木特佐に一任されていたと思う(特に第三種警戒体制下)。安保のガイドラインもこのくらいしっかりしていれば、ね。劇中に使用されたこの規定の表れるコンピュータ画面は妙にカッコよかった。今考えると黒地に緑字と赤字なんて偏見に満ちた画面やけど。それにしてもこの映画の首相って凄かった。ゴジラ対策は特種災害研究会議:通称ゴジラルームに任せっ切りで、自分は「ゴジラよりも野党」やったからなぁ。森総理もそのくらい図太い神経持っていたら……持ってそう。

プログラミング

トイ・プログラムのアバウトボックスのOKボタンが効かないだとか、クローズボックスを押しても何も起きないだとか、編集メニューの必須項目が何時まで経っても使用可能にならないとか、様々な不具合を抱えながらも何とかビルドに成功。オブジェクト非思考なんて嫌いだっ!

MBP

「骨は三年で生まれ変わるんです」フォフォフォフォ……

映画「サトラレ」

NECOの広告でモスラのテーマ(モスラ〜ヤッ、ではなく)が流れてた。なんで?

映画「風・花」(かざはな)

うちのサイトに置いてある絵とは関係ありません。多分。

機動警察パトレイバー CLATよ永遠に

ヘッドギアやり過ぎ。30分間笑いまくった。

BLOOD THE LAST VAMPIRE

上、下巻を買ったらお店の人に「横置きか縦置きスタンドをプレゼントさせてもらっています」と言われた。横置きにするならスタンドの意味なんか無いので、縦置きを貰った。……SONY純正のモノでは無く、どこか知らない企業のモノだった。……このデザインでは売れへんわ。お店がおまけにしたのも頷ける。

2001-02-20

MPW

本気でプログラミングを始めたいので、MPWでプログラミングのサンプルソースをちまちま手で打っているが、どうもやっている事が泥臭い。まずマウスイベントを拾って、メニューバーをクリックしたのならメニューバーアイテムのどれなのかを探し、プルダウンメニューを表示させ、もしそこからメニューアイテムが選ばれたのならそれに呼応した関数を呼び出して……と、Toolboxの関数をいちいち呼び出して行かなければならない。この程度であればAPI或いはフレームワーク側で処理出来るだろうと思うのだが、オブジェクト思考では無いからこんな事になるのかも知れない。数行でJavaアプレットが取り敢えず動いたのとはえらい違いだ。

折角時間をかけて打ったコードが動かないので、気分転換にCarbonのAPIリファレンスを眺めていたら、Menu Managerの関数リファレンスのInitializing the Menu Manager前後、IE5:macで見たら「痴」の字が並んでいた。中々にシュールな光景だったが、単純に文字セットを英語にしただけでちゃんとなった。

2001-02-19

共存?

ディスカバリーチャンネルで、釣り舟を襲うクロコダイルを何とかしようと言う番組があったのだが、その中で取られた解決策は、「捕まえて縛り付けて、一晩中その傍をボートで暴走族宜しく駆けずり回る」と言うものだった。厳しい自然界に於いて捕まると言う事は即ち喰われると言う事であり、いかな爬虫類と言えどもそんな事をされてはトラウマにならない訳がなく、以来ボートを襲わなくなっていた。番組の最後は「この方法であれば、追い出したり殺したりせず平和的にに共存出来るのだ」と結んでいた。鰐のテリトリーでは釣をしないと言った方法は論外らしい。

ゴミ箱改め屑篭

Aquaに関して、一つ嬉しい事がある。それはゴミの入ったゴミ箱が膨れる事だ。

2001-02-18

TVあれこれ

リカルデントの彼は左利き。マウスパッドがノートパソコンの左にあった為。て、ノートパソコンでマウスを使う人っているの?

正確な体温が測れると言う触込みの耳温計(みみおんけい)。じおんけいが正しいと思う。

発信する為に必ず面舵一杯するアルカディア号。埠頭にでも横付けしてたの?宇宙艦の埠頭って一体?

ヌードを出したとか言う由美かおるって、ひょっとしてキングコング対ゴジラの由美かおる?道理で何やら知った顔やと思った。

CSS

Validaterに文句を言われた上、N6もIE5:macもろくに処理してくれないのでoutlineを除去。N6でコンテンツの上半分が動かないのも対応。

N6には、ヘルプメニューの「Netdcape6について」は動くのにアップルメニューの「Netdcape6について」の項目が何の役割も果たしていないと言うMacユーザーを馬鹿にした仕様がある(断じてバグではない)。クロスプラットフォーム大いに結構である。しかし、例えばW3Cの言っているクロスプラットフォームと言うのはそれぞれのプラットフォームに応じて処理出来るようにデータを抽象化するものであって、断じてあらゆるプラットフォオームで全く同じ挙動を示す事ではない。GFXスクロールバーをプラチナに無理矢理対応させようとしているMozillaのやっている事は全く的外れだ。Aquaの時は一体どうするつもりだ?資源を再利用すると言う現在のコンポーネントデベロップメントの思想からも真っ向から対立する方法だ。

この事は、MozillaがUNIX、特にLinuxやBSDのオープンソースの流れをモデルにした事と密接に関わっている。一番いい例が存在するDEの雑多さだ。似たようなインターフェイスライブラリをいくつも作って、「こっちの方がオープンだもんねっ」「こっちの方が軽いもんねっ」等と悦に入っている様を見ていると、彼等には統一された美しさと言うのは理解できないものらしい。無論の事、Lerning Perlの序文にあるように様々な方法をグチャグチャと固めた方が良い場合もある。だが、事ユーザーインターフェイスに限って言えばユーザーのする事は少ない方がいいに決まっている。

Mozillaに詳しい人等は、Netscape6をMozillaの出来損ないだとして(そのMozilla自身もまた出来損ないであるからと)存在する不具合に関して寛容な人達も居る。CSS1を完全に実装したIE5:macやCSS2を完全に実装したICE BrowserやOperaに出来た事が何故Mozillaには出来ない?Mozilla.orgはXULなんてもの考えずにGeckoの完成に全精力を注いでいれば良かったのだ。"OK"を押しても閉じないダイアログや動かないメニューアイテムなどXULを使っている事を理由にして看過出来るモノではない。

そのうえ、Mozilla.orgはMozilla1.0は別に正式リリースでもなんでもないと表明している。こうして、ソフトウェアはますますややこしく分かりにくいものになって行くばかりだ。現在のPCに、パーソナルを名乗る資格はない。

2001-02-17

ZOIDS

ディバイソンの換わりにガンスナイパーって、ちょっと無理がないか?やっぱりCG作ってなかったのか、マキシムファイアが板野ミサイルになってたし。これから考えると、チームブリッツの初期ゾイドがライガー・ウルフ・バイソンだったのは単純に他のゾイドをいちいち作るのが面倒だったからではないのか?

次回、やっと次のタイプチェンジ、ライガー・ゼロ・シュナイダー(ちょっとこのネーミングは元が分からない)の登場だが、おいおい、放熱フィンの横にブレードがついてないか?あんな構造でブレードになるんかいな……いや、ブレードではないのか?

HP

あれぇ?アメリカンネイティブな英語を話すはずのヒッキーがHPって言ってる。ひょっとして、この言い方ってアメリカでも普及しつつあるのか?

2001-02-16

演歌ぁ?

うちの母親がTHE YELLOW MONKEYの歌を聞いて「格好はロックやけど中身は演歌」と言っていた。確かに、旋律線の構成なんかをよく聞いてみると演歌として歌えなくもなさそうだ。

2001-02-15

ビギナーのためのネットスケープ6講座

GeoCitiesでXHTML化は不可能じゃ(2001-01-21参照)と言うに。やりたくてもできないのに気がついて止めたこの気持ちを逆撫でないでくれ!

Windows XP & Luna...Mac OS X & Aqua

.exe君によると「Windows XPではアーキテクチャの分離がより進み、今までのソフトは殆どエミュレーションに近い状態で動作するようになり、新しいテーマの適用もない」との事だった。Darwinの上にClassic、Carbon、CocoaがのっかるMac OS Xと何が違うと言うの?それにあのスクリーンショット。どう見てもAquaのデッドコピーにしか写らないLunaの存在価値って何?ひょっとして、MacとWinって実は全く同じアーキテクチャで出来ているんじゃないの?

だが、AppleがAqua以外のアピアランスに関してカスタマイズを全く認めない方向にある(これに関してはKagiに責任がある筈だと僕は確信している)のに対して、Lunaは切り替えられるテーマの内の一つだと言う。あの程度のデザインであればいくらコピられてもAqua程騒がなくてもいいと思っているのかもしれない。あれをそのままコピーする人は、変質的なKaleidoscopeスキーマーぐらいだと思う。

Windows 97のフレーム分けされたデスクトップや、Windows Millenium(Meではない)のWebサイトのようなインターフェイスを見て僕はある意味Microsoftのインターフェイスに対する意欲的なまでの姿勢を評価していた(当時は口汚く罵ったけど)のだが、結局本の鞘、Mac OSのデッドコピーメーカーに成り下がってしまったのは何故なんだろう?

そう言えば、Aquaのネーミングは何となく分かるが、Lunaのネーミングはよく分からない。ひょっとして、母音のスペルが似ているからでは無いのか?

カスタマイズ

デスクトップカスタマイズ熱が再発したので(病気みたいだが)久し振りにKaleidoscopeをインストール。とってもAquaな気分だったのでAquaなスキームを探したが……無い。そう言えばAppleが散々潰したんだっけ。サウンドセットも色々探したのだがいいものが見つからず、"Wet"とか言う名前のがよさげだったので暫く使っていたのだが、何となく便所に居るような気分になったのでポイ。結局……プラチナ使ってるっ!(笑)

2001-02-14

CSS2

CSS2の仕様書の表の所に

HTML文書の'display'プロパティにこれらの値が指定された場合、ユーザエージェントはそれらを無視してもよい。 何故なら、文書作成者はHTML要素に意図されている動作を変更すべきではないからである。

とあった。なら、特定のdlにtableっぽい動作をさせようとしても出来ないと言う事だ。これには不満が残る。

2001-02-13

いつまでもいつまでも降り続く白い雪は春夏秋二人が残した足跡を消してく

早くアルバム出ないかなぁ(シングル買わない派)。

CSSに優しい文章系XMLボキャブラリ設計

シンプルなHTMLにCSSで装飾して行く際に一番困るのがセクション毎のグループ化だ。わざわざシンプルなHTMLにしたにも拘らずセクションのグループを標準で行わないのでCSSで装飾する為にいちいち独自の"div.云々"を定義して書き込まなければならない。更に、現行のHTMLでの限界と言えば6階以上のセクション分けが標準状態では出来ない事(する人いるかどうかは分からないが)。

そこで、無限階のセクション分け、セクション毎の標準でのグループ化を実現する簡単なボキャブラリを考案。

<!ELEMENT container ( information*, heading?, ( %paragraph; | container )+ ) >

DTDが読める人は分かると思うが、汎用のセクショングループとしてcontainerがあり、場合によってはcontainerの最初にinformationheadingが来て、その後に最小段落要素かcontainerが一つ以上並ぶ。このボキャブラリは、DOM構造は若干変わってしまうがHTMLのブロック要素の持つ機能をほぼ完全に受け継ぐ事ができる。

ただ、こう言ったボキャブラリの「再発明」は現行のブラウザとは共存できないし、スマートな方法とは言えない。JavaWorldの記事の中で「classを使え」とあるのもその為だ。以前書いたように、HTMLとCSSの持つclass機能によるボキャブラリ設計は仕様書で「やるな」とすら言われている程に強力だ。そこで、先程設計したボキャブラリをHTML4内に埋め込む方法を考えよう。

まず、div.containerdiv.headingを定義する。%paragraphinformationはもとからある機能で十分なので定義しない。次に、CSS内での記述を簡潔にする為全てのbodyにはclass="container"を、全てのh1h6class="heading"を適用する。こうする事でわざわざbodyやその他の見出し要素を個別に呼び出す必要無く、階層構造に応じた呼び出しでスタイルを割り当てる事ができる。

問題になるのは、既存のライブラリによる文法チェックが機能しない事だ。この辺りは、ボキャブラリを使用する状況に併せて選ぶしかないだろう。

冷蔵庫

帰って来てみたら冷蔵庫の扉が半分開いていて、中から水がジョボジョボ溢れていた。この冷蔵庫、扉のパッキンが硬くなっていてちょっとやそっとの力じゃマトモに締らないようになってるし、何かの拍子にすぐ開いてしまう。そんな訳で霜が南極の氷宜しくセンチ幅で降りており、昨日設定温度を緩めた事も相まって溶け出したらしい。

取り敢えず、床を拭く為冷蔵庫を引っぱりだし、然る後に霜を取る為マイナスドライバーをノミ代わりにトンカチと併せてコンコン氷を割って行く。取り敢えず作業はこれで終了。パッキンって取り替え効くのかなぁ?

名前

以前、"DEVICEREIGN"でWeb上を検索してみた時、そのままの名前のサイトを見つけた事があった。期待してジャンプしたら、「DEVICEREIGNはmoo系同人サークルTeam悠久組曲の公式ホームページです」との旨が書かれていた。そしてその下には「Team悠久組曲は何時何時を持って名前をTeam悠久幻想曲に戻します」とあった。

BBSに入ってみると、「真端実」の名前が目に付いた。他の人達の名前もDEVICEREIGNや悠久幻想曲等moo系の登場人物からそのまま名付けられたものだった。

最近、よく聞くFM局(金曜日の深夜11時にローソンに行ってみよう)への投稿に、ペンネームとして「フルアーマーダブルゼータガンダム」とか「シャア・アズナブル」とか、ウルトラマンティガをもじったもの(それもかなりディープに)とかが聞こえるようになった。

程度の差はあれ、何れの場合も僕は不愉快な気持ちになった。翻って自分の所業を見てみると、好きなゲーム"ECCO THE DOLPHIN"の主人公からハンドルをもらったし、サイトにはイルカのシルエットまで配している。僕がこの名前を選んだのは、単純に好きだったからゲームの主人公にはまず「エコー」と言う名を付けていた事や、ゲームがマイナーな上に小文字に変えた事から勘違いされる事は無いだろうと思ってつけたのだが、ひょっとして僕以上にこのゲームが好きな人はこれを見て不愉快になるのでは無いか?

好きだからこそそれと一体化しようとし、その名前を付けてしまうのか、或は本当に好きでは無いからこそ名乗る事ができるのか。

少なくとも、僕のハンドル、或は僕の本名と全く同じハンドルの人が現れたら僕は嫌がるだろう。

……www.ecco.com。うゎ。

2001-02-12

衝突事故

感極まって涙を流す乗員に向けてばちばちフラッシュを炊いたり、「何もしてくれなかった米原潜に対してどう思いますか?」等信じられないような質問をしたり、ひょっとして最近の日本が荒れているのはマスコミの所為じゃ無いかと思うのだが。森総理の失言やらスキャンダルやら鉾先が減少している為なのか、あっさり米国攻撃に回っているマスコミ連中。おかしいと言うのは簡単だ。何故そうなったかを検証するのが筋なのでは無いか?

攻撃型原潜の最も敏感な前方の状況の未確認、過密海域での緊急浮上訓練、早すぎる米国政府の対応。全てに於いて不自然なこの事件、その真相は一体なんなのか?

まず米国政府の態度。これはブッシュ新政権に変わってから沖縄駐留軍指揮官の失言も加わって日本が頑な態度を取らないように細心の配慮をしているのだと言う意見もある。だがこれしきの事で日本が米国のお膝元を離れる事はあり得ない。不平等条約を突き付けられても唯々諾々と従っているしか無い弱小国家に、そんな事をしたって無駄だ(現に例の指揮官には何のお咎めも無い。日本では一官僚を中国が首にすると言うのに)。これは、真実を米国が早い時期から、ともすると事件よりも前からその情報を持っており、その真実を公表したくないからこのような態度に出たのだ。

次に浮上時の状況。これはどう考えてもあり得ない話だ。ならば起こった事態はなんだったのか?答えは簡単である。あれは訓練等では無く、本当に緊急だったのだ。米国はそれを知っていて真実を隠す為に「訓練だ」と称したのだ。例えどのような事態であれ駐留艦隊の監視する海底で起こったとなれば、完璧だと思われている米国の危機管理がマスコミ攻撃の餌食になるのは火を見るより明らかだ。

以上を踏まえて、真相はこうだ。あの潜水艦は実はある組織による表沙汰に出来ない会合に使われていたのだ。無論その組織は米国ともツーカーの仲である。考えてみて欲しい。潜航する史上最強の攻撃型原潜の内部。盗聴する余地もスパイの入り込む余裕も無い。闇の会合にはもってこいの場所だ。だが、その闇の会合による陰謀を阻止する為、別の組織の要員がこっそり原潜の物資の中に忍び込んだかなんだかして、何とか原潜を緊急事態に追い込むまでに至った。が、事前に情報を手にしていた米国の策略により犯人は呆気無く捕まり、実はその会合も罠だったのである。

そんな米国にも予測できない事があった。偶然にも近くを通った漁船との衝突事故によって事が公になってしまったのである。そこで米国は異例の早さで謝罪を表明し、事を静めにかかった訳である。さてここで、米国との繋がリの深いある組織と言えば、ユダヤ=フリーメンソン(イルミナティ)しかいない。対する別の組織とは、もちろん我等が日本赤軍である!

……以上は、全てフィクションです。うーん、論理が途中で破綻している。

ブラウザ

Abstructをココとは違った一つの表現として立ち上げたつもりだったのだが、ココの流儀が染み付いてしまっていてなんだか束縛されているような気がする(全然作ってないが、ココでやれる事はあっちではやろうと思わない為)。いっその事XML&XLink独自ボキャブラリ+CSS2でやってやろうかと思ったのだが、HTML4+CSS2よりもマトモに表示してくれるブラウザが存在しない(XLink対応なんてそもそも無いし)からせめてXHTML1.0Strictにでもしようかとも思ったがスタイルシートやlangの記述等ハッキリ言ってスマートで無いのでうざったいから却下。XHTML Basicに至っては制限が多すぎて使おうとも思わない。XHTML1.1を使うならモジュール化やXMLNSを使用した別メディアタイプの埋め込みなんかも出来るようにならないと意味が無い。

HTML4Strict+CSSに落ち着く訳だが、それならココでもやっている。もうW3Cの規格なんか無視するか?

2001-02-11

ZOIDS

試合中にメンテナンスは許されているのかなぁ。インストレーションシステムなんて殆どドック入りに近い気がするんだけど。……あのホバーカーゴはアンパンマン号か?!後、バックドラフトの連中が「アルティメット・エックス」なんて言葉を使っている(エグザクソンでの「ラウンメイタル・ユニット」の扱い?)のも気になるし。あれ?イェーガーをインストールした後のライガーを見てそう呼んだって事は、あのインストレーションシステムがアルティメット・エックスの要なのか?だとするとトロス博士、リノンと一緒に「儲〜かった儲〜かった、五ば〜い五ば〜い(嬉々)」等と無邪気に喜んでいるが、実は物語の謎を知る重要な人物なのではないか?

それにしてもチームバイパー。チームブリッツにも舐められてバックドラフト団にもあっさり潰されて不憫な事不憫な事。漫画版アーバインが泣いてるぞ。

Netscape6

Netscape6でウチのデフォルトスタイルでのコンテンツメニューの上半分が動かなくなった。理由は分かっている。おそらく個々のボックスでマイナスポジションを取るか、グループボックスでマイナスポジションを取るかの違いだ。次いでに言うと、これは明らかにNetscape6の問題だ。

HTML4StrictだXHTMLだCSSだと言ってみた所で、結局はブラウザ実装の現状を無視していてはアクセシビリティなんでものには意味が無い。分りやすいナビゲーションなんてのも同じだ。殆どのナビゲーションをdiv#navigationからheadのlinkへと移したものの、サイトトップとコーナートップへのリンクは消せなかった。少なくともNetscape6がLynx並みのlink要素解釈をしてくれれば、全部消していたと思う。

HTML4とCSS2の仕様書を提示したW3Cは自分でブラウザを作っている。Amayaがそれにあたるが、とてもじゃ無いがHTML4の機能をフルに引き出しているとは言えない。cite付きの引用要素がhref付きのaと同じ挙動をする事やMathMLを一応実装している所を除けばNetscape4より劣るかも知れない(あのトンでもCSS実装は無いが)。自分で策定したものなんだからXSLTに対するXT並みのリファレンス実装くらいはやって欲しいものなのだが、あの巨大な仕様に対してその注文は無理だろう。

それでも全く実装していないのならまだ諦めが付く。困るのはこの例の様に中途半端に対応している場合だ。他にもIE5:macでのposition:fixedなブロック上でのaが動かないだとか、それなら対応して欲しく無い。

ここで、Netscape6にあわせてCSSの書き方、つまりボックスの取り方をかえるべきなのだろうか?或いはNetscape社への講議の意味を込めてこのままにしておくか?でもN6のユーザーに罪はないからなぁ。

簡単に言うと、ポジショニングしたボックスからはみ出したaはレンダリングされるけどクリッカブルにはならない。ひょっとして、z-indexを弄ればちゃんと動くかも知れないのだが、その辺りの仕様が分からないので今回はパス。

2001-02-10

相川七瀬「〜dandelion〜」は「no future」と同時リリースらしいのだが、何故かMTVには「〜dandelion〜」しか出て来ない。……どっちがいいかと聞かれたらやっぱり「〜dandelion〜」って答えると思うけど。

この曲は、僕的な相川七瀬に対する印象を(いい意味で)壊してくれたと思う。本人もインタビューで「隠し味のファンタジー要素を前に出してみた」と言っていたし。一方「no future」はそれまでの相川七瀬そのままと言った感じで、僕がZOIDSを見ていなければ多分知らなかったと思う。

2001-02-09

進化論

SOPHIAの『進化論 〜GOOD MORNING!−HELLO! 21st- CENTURY〜』のサビ、題名も歌詞も「GOOD MORNING!−HELLO! 21st- CENTURY」なんだけど、聞いている分には「トゥウェンティワンセンチュリー」と言っているように思える。

イカ

捕まったダイオウイカを指して「美味しそうですね」と言ったニュースキャスターがいた。マッコウクジラが食するとされるダイオウイカだが、マッコウクジラもあんな深海に行くのは億劫らしく、本当の所はひもじくてしょうがないから食べているとのことである。それから、大きな体の為に筋肉の大半(つまり体の殆ど)にはアンモニアが蓄積されていて臭い事この上無いそうである。それに、TV画像のイカもそんなに美味しそうでは無かった。

ショートカットコマンド

HTML的に言う所のアクセスキーのMac的呼び名である。Windowsではエイリアスにショートカットと言う名前を当てている為に非常に分かりにくい。HTML4やiモードではaccesskey属性がそれを表す事になっているが、Jスカイではdirectkeyになっている。J-PHONEの開発者はHTML4を知らなかったのだろうか?

HTML4の仕様書には「Macではコマンドキー+accesskeyの値になるだろう」とかMacユーザーにしてみれば非常識な事が書いてある。この人は本気でユニバーサルなデザインを考えているのだろうか?HTMLドキュメントの制作者が勝手にショートカットコマンドをゾロゾロ定義してそれが有効になってしまえばとんでもない事になる。特にMacでは「この組み合わせはこう言う性質」と言うのが厳密に決められており、例えば「コマンドキー+I」は「選択したオブジェクトの情報を表示する」と言った具合だ。読んでみれば分かるように厳密ではあるが極めて抽象的であり、API的にこれを制限するのは無理だから、実際はアプリケーション制作者の裁量に委ねられている。しかしだからといって例えば「コマンドキー+I」でインデックスページに飛ばされてはたまったモノでは無い。寧ろこの場合著作権表示をするのが妥当だろう。

で、Inside MacintoshHuman Interface Guidelineには

The Control key is used with terminal-emulation programs for Control-key sequences. For all other applications, it is reserved for shortcut key sequences that the user defines using a macro-key facility.

と書いてあり、UNIXなんかのコマンドラインインターフェイスのプログラムをそのマンマ移植した時に使うもんだと言う事なのだろう。で、フツーのアプリケーションではどう使うかと言うと、ユーザーがマクロを組んだ時等にそのショートカットキーとして使えと書いてある。これから考えると、「コントロールキー+accesskeyの値」とするのはあながち的外れな事では無い。

これと関係するのかどうか分からないが、最近のMacのキーボードのコントロールキーには必ず鉛筆マークがついている。実はこれ、ことえりのショートカットキーとして割り当てられているのだ。例えばインライン入力時なんかはもはやインプットメソッドの独断場であり、FEPと言う昔の呼び名から考えてもインプットメソッドを一つのアプリケーションとしてとらえ、ショートカットコマンドを決めてもなんら問題は無い。と言う訳でことえりではインライン入力時の「コントロールキー+」「J」「K」「L」「;」にはそれぞれ「ひらがなに」「カタカナに」「英字に」「半角英字に」変換と言う事になっている。で、カーソル点滅時はどうかと言うと、これはことえりが一つ後ろに下がったと言う事なのか、「コントロールキー+シフトキー+」「各々のキー」で入力モードが切り替わるようになっている。……って、これ、マクロやないやん!

ここまで書いてAqua Human Interface Guidelineを読んでみたら

The Control key is used to modify the functions of other keys, with terminal-emulation programs for Control-key sequences, and, with a mouse click, to display contextual menus (see Contextual Menus (page 47)). Cocoa developers should also consider additional behaviors, as described in the text defaults and binding document, available in the programming topics section on http://developer.apple.com/techpubs/macosx/Cocoa.

と、コンテクスチュアルメニューの話が加わってCocoa関連の情報もついていて……何故かマクロの話は無くなっている。で、Mac OS 8 Human Interface Guidelineも漁ってみたのだがこちらにはコントロールキーについての話はコンテクスチュアルメニューの事しか書いていない。CocoaユーザーはText編集関連のとこを見ろと言う事は……Classicのことえりは黙殺なのか?!

さてHTMLのアクセスキーである。Jスカイは故意なのかどうかは分からないが独自の属性になっているが、iモードなんかは数字のキーしか割り当てる事が出来ない。その他の文字を割り当てても無意味である。この様に、HTMLドキュメントに固定的にショートカットキーを割り当てる事は全てのUAで同じキーボードが使えるかどうか分からない状態では保留するしか無い。世の中、ひょっとしたらひらがなしか打ち込めなくて、英字を打とうと思ったら変換しなきゃいけないキーボードだって存在するかも知れないのだ。僕は寡聞にして知らないけど

この辺はW3Cも認識しているようで、XHTML Basicではaccesskeyが除かれ、ショートカットキーの設定はXSLがやるようである。しかし、ドキュメント制作者がショートカットコマンドを決めるのには変わりがない。こんな事をするよりも、もっとrelやrevを標準的に決めて、それに対してUAが自分のコマンドを決める様にした方がいいと思うんだが。どんなrelやrevがあるのか調べる事もできるので。

以上の事を踏まえてさらに、いちいちサイト毎に違ったアクセスキーだったりしたら、使えるものも使えなくなってしまう。「目次」「スタート」「前」「次」くらいのごく普通に使われるものでも、サイト毎に違ったりしたら覚えてもあんまり得な事は無い。むしろさっさとマウスでクリックするかtabでフォーカスを移すかした方が速い。これは是非ともUA側で実装してもらいたい。

と言う訳で僕はアクセスキーをはずした。イニシャルの色が変わらなくなったので少し寂しいが。

2001-02-08

XP

ちょっと待て、XPには別の意味があるぞ!

どうも新聞記事で読んだWindows XPのネーミングが引っ掛かると思っていたのだが、XPと言うのはeXtreme Programmingの略で、短期間少人数で一つの開発プロジェクトを仕上げる手法の一つだ。XPは「週四日一日四時間労働」「多分動くと思われる最小限の実装だけする。拡張性は百害あって一利無し」「議題はアナログにカードで記す」「常にペアで行動する」と既存の開発手法とは一線を画するその独特なスタイルに特徴があるが、こうする事で開発の最終段階に向けて爆発的に増える仕様変更のリスクを限り無くゼロに近付ける事のできる画期的な手法だ。その解説書には「変化を抱擁せよ」と言う今のソフトウェア開発に於いて最も重要な思想が副題として付けられており、まさにエクストリームなプログラミングを提示している。

こんな所でMicrosoftにXPなんて商標を取られたら、XP関連の書籍が危なくなる。Webサイトをホームページと呼びさらにそれをHPと略するのは自然発生的に出てきたものだからまだマシなものの、Microsoftの強引な手口でこの画期的な手法と取り違えられるのは極めて不愉快だ。

ちなみに、NTはNew Technologyの略だそうである。でもNT4のスタートアップに必ず"NT Technology"と言う文字列が表れるのは何故だろう?

2001-02-07

ナビゲーション

最近この話ばっかりの様な気がする……でもどうしても気になっちゃうから……

時々、一段落毎に「ページのトップへ」と書かれたリンクを見る事があるのだが、これは本来UAが、いや、もっと言うならドキュメントのスクローリングインターフェイスを提供するOSがやるべき事では無いのか?事実、Carbon SDKについてくるHTMLRenderingLibのサンプルには「戻る」「進む」と一緒に「一番上に行く」と言うボタンがあった。(他にもあの懐かしいイヌウシのボタンがあったのだが、これは何の機能もついてなかった。)

もっと言ってしまえば、なんでスクロールバーを使いたくないのだろうか?あの幅十数ピクセルの四角い領域は決して飾りでは無い(最近のソフトには飾りが増えたけど)。僕はナビゲーションバーが使いたくてページのトップやボトムに行く時は必ずスクロールバーを使う。特にスクロールボックスを引き摺る。とここまで書いて、学校のNT機でWebを見て回っている時は、マウスホイールを使う事を思い出した。何でいつも使い慣れているスクロールバーを使わないのだろうか?

昔Macworldに「Windowsのマウスは速度に応じたアクセラレーションしないから使いにくい」と書いてあった。最近の2000やMEなら状況は違うかも知れないが、なんせウチの学校に入っているNTはMicrosoftがPPCPPReP、或はCHARP向けにすら作っていたNT4である。アクセラレーションはしていないだろう。なら、ポインティングデバイスなのにポインティングし難い等と言う致命的な欠点がある為にスクロールバーが使い難いのでは無いか?(これは慣れの問題と言えばそれまでだが)

こう言う状況を推定して、ほとんどのページは作られている。何処までがUAの仕事か、何処までが著者の仕事か。CSSの初期値問題にしてもそうだが、今のWebはそう言った余裕を残し過ぎているのでは無いか?

iアプリ

503iでサポートされたこの機能、これはつまるところ、Javaアプレットだ。

docomoがiアプリに何処までパーミッションを緩くしているのかは知らないが、Javaアプレットの例を持ち出すまでも無く出来る事と言えばミニゲーム程度だろう。僕は最初、Javaのオブジェクトをシリアライズしたものをサーバーと通信しあって何かしら高度な処理が出来るかも知れないとは思ったのだが、今の携帯電話のCPUの処理能力が単純にクロック周波数だけでも25MHz前後と言う状況を考えるととてもそんな抽象的な処理をしていては満足に扱えるものにはならない。考えられるのは、そう、PocketStation程度のゲームくらいだと思われる。こんなもん、PS2かゲームキューブかX-BOXかとにかくなんらかのゲームハードのバックボーンが無い事には普及のしようがない。

僕が知る限りでは、テトリス系のミニゲームかるいは何か別のゲームとタイアップしたミニゲームばかりで、何かしら新しいものを感じさせてくれる様なモノは一つも無い。こんなもんに注力するくらいなら、PocketStationかビジュアルメモリで動くミニゲームを作った方がなんぼか増しだ。

一体、あの小さなもので汎用アプリケーションを動かして何が楽しいのだろう?……docomoには是非、いや、他のベンダーでもいいから、未来の見えるiアプリを作って欲しい。

インラインスタイル

HTMLのstyle要素やstyle属性を使えばHTML中にCSSやJSS、XSLを埋め込む事ができる。が、HTML中にこう言ったモノがある事は、font要素を使う事と本質的に何の変わりも無い。逆に表現が広がる分不便である。それでは、インラインスタイルでは無くdivやspanにclassやidを割り振って外部のスタイルシートで制御するのはどうなのだろう?

やっぱりfontと変わり無いのでは無いか?だからこそ、CSSの仕様書

注。 CSSではclass属性が非常に大きな力を持っている。 したがって文書作成者は、体裁にほとんど何の関係も無い要素(HTMLだとDIV要素やSPAN要素など)をベースにして、それらにclass属性でスタイル情報を与えれば、独自の構造化言語を設計できると考えられる。 しかし、文書の構造要素は広く受け入れられている一般的意味を持つ場合が多いので、こういった使用法は避けるべきである。 文書作成者が定めたクラス名では、意味を理解してもらえない恐れがある。

なんて脚注が書かれているのかも知れない。そう言う仕様書では、引用した部分がdivのclass="note"で括られていた。おいおいfontだろうがdivだろうが、結局はHTMLに備わっている要素でマークアップしてその上で補助的(何処までが補助なのかは断定できないのが歯痒いが)に扱うのが妥当だと言う事だろう。と、そこまで考えて、ウチのサイトで扱っているnoteやcanvas、或はgeoguideなんかは他のHTML要素で扱えるのか?

月刊JavaWorldで、XMLボキャブラリ作成の特集が三ヶ月に渡って組まれていたが、最後の方では一番現実的な選択肢としてclassを使えと言う事になっている。そうなのだ。多くのXMLの入門書で頻繁に例に上げられている議事録等のボキャブラリは、わざわざ新しくDTDやRELAXやSchemeを書かずともdivのclassで殆ど事足りる個人的に、HDML等はclassを使ったHTMLのサブセットとして設計し直した方が既存のリソースとの共有も可能になるのでいいと思っている。ぶっちゃけた話、iモードやJスカイでもezWebが閲覧できると言うのは損な話では無いはずだ。。HTMLの持つこの拡張機能のお蔭で、XMLの意義の大半は失われている。HTMLの表現力の低さからXMLが考え出された等と解説する本が巷に氾濫しているが、実際に世に出てきているXMLボキャブラリと言えばSVGやSMIL、XULやCC/PPと、HTMLの目的とは全く異なるものばかりだ。唯一MathMLがHTMLとフィールドを共有するくらいか。

XMLNSの標準化のお蔭で、HTML(XHTML)の拡張機能はclassだけに留まらずXMLNSを使うと言う方法まで可能になった。ここまで来るとW3Cがわざわざ策定したobject要素の意義はどんどん無くなってくる。かつてAppleがOpenDocでやろうとしていた事が、数年遅れで実現するかも知れない(XHTMLをコンテナ、SVG等のボキャブラリをパートとして)のは嬉しいし、Appleの先見性を改めて確認する事に図らずもなった。

えと、なんだっけ?あそう、インラインスタイル。

何処までが構造で何処までがスタイルかなんてのは、考えれば考える程分からなくなる。div.noteやらdiv#navigationやら、いくら構造とスタイルを分離すると言ったって僕自身がまずスタイルありきでこのクラスを設計したのは変え様の無い事実だ。結局の所、何処まで自分の文章をHTML的に抽象化出来るかが問題になってしまうのだろう。

2001-02-06

自分の知らない内にウチのサイトが紹介されていた。

ECCO's ECHO
ソースの記述がうざい。

頻繁に見に行くサイトだったので名前を見つけた瞬間は非常に嬉しかったのだが、コメントを見て妙に落ち込んだ。何故だかCSSのカテゴリの中にあるので多分コードソースと言うのはCSSのそれだと思うのだが、ひょっとしたらHTMLの方かも知れない。

Webと言う場所の特殊性を考えれば何処にどの様なリンクを貼ろうが勝手だし、否定意見が無い事はそれは即ち評価されていないと言う事であり、そもそもソースコードなんて人に見せるものでは無いから自分で見て分りやすければそれでいいのだし、従ってこう言う意見は無視すればいい筈だ。

と、理解しているつもりなのだが、何故か知らないが気になって仕方がない。それ程までに自分のコードは見易いものだと無意識に自負していたのか、或は単純にネガティブな反応を嫌がっているのか?CSSファイルに話を限って言えば僕自身お世辞にも綺麗とは言えない記述を何とかしたいと思っていたので、そう言った弱点を指摘されたのが嫌なのか?

どれもいまいちピンと来ない。何でこんなに凹む?

rel属性の記述

rev="made"よりもrel="author"とかにした方が分りやすいんでは無いだろうか?

それは取り敢えず置いといて、Another HTML-lintのLynxエミュレータで確認した所、link要素でtitle属性が記述されていればそれを表示し、されていなければrel属性をそのまま使っている。このrelなんだが、HTML4の仕様書に書かれている様な明らかに標準のモノであればそのソフトやプラットフォーム独自のレンダリングをするものだと思うのだが、Lynxはrelをそのまま使っている。僕はrelがそのまま使われる事は無いだろうと思ってキャピタライズさせずに書き込んだのだが、bookmarkのtitleにはキャピタライズさせて書き込んだので非常に見栄えが悪い。

そう言えばCSSやSVGの仕様書ではCSS-propertiesなるrelがプロファイル無しに使われている。rev="made"だってそうだ。こう言う状況を考えれば、ブラウザの知らないrelであっても普通に表示できるようにした方がなにかと便利だ。なら、仕様書の書式に習ってrelの中身もキャピタライズさせた方が知らないブラウザでの見栄えもいい。

ふと思ったのだが、例えばrel="Cpyright"を"©"と表示するブラウザはtitleが書かれていた場合はどちらを優先させるべきなのだろう?

Windows XP

Windows 2000の後継で、エクスペリエンスの略だそうである。最近のアメリカ人は何故か妙にこの"X"と言う文字がお気に入りのようで、なにかにつけては"X"を冠したがる。が、eXpandedにしてもXpressにしてもXtraにしてもeXPerienceにしてもeXtensibleにしてもX(Cross)Platformにしても無理があると思うし、これはガンダムXを見ていた時にも感じた事なのだが(そう言えばガンダムWのTWO-MIXも何かにつけてはXをつけていたような……Reflexionとか)、僕はこの文字に妙に古臭いものを感じてしまう。

ひょっとすると、幼いころに見たスーパーXの記憶がそう感じさせるのか?しかしあれを初めて見た頃はそんなモノの名前等覚えて無かったはずなんだが……でもあのコクピットは好きだった。

しかし、「ユーザーエクスペリエンス」の事を書いた直後でもあるので妙に反感を覚えた。新聞記事を読む限りではストリーミングコンテンツのネイティブサポートを指してエクスペリエンスと呼んでいるようなのだが、Appleの誰か(忘れた)がHIGの策定に際して唱えた「ユーザーエクスペリエンス」と言うのは全く別の話だ。モニターに表れるのが静止画なのか或は動画なのかと言った事は枝葉に過ぎない。本当に大事なのは根底に流れるユーザーインターフェイスに対する設計思想であり、ユーザーが長い事使っていて初めて得る事ができる実感である。

これと似た様なモノにプラグ&プレイがある。Appleが一つの概念としてこれを唱えた、箱から出して電源を繋げば使える、と言うのがいつの間にか全ての周辺機器のドライバをWindowsがまとめて持っている事がプラグ&プレイと言う事になってしまった(マイクロソフトはそれで商標まで取った)。SCSIにしろUSBにしろ、ドライバソフト等必要の無いくらいに抽象化されているのが本来あるべき姿だ。マイクロソフトのこう言った勘違いで強引な姿勢は決してユーザーの為にはならない。僕が一番評価しているIE5:macだって、自分の独自の設定ファイルなのに"Internet Preference"なる非常にグローバルな名前とつけてくれるお蔭で僕はこれをシステム標準のモノだと思い込んで設定ファイルを消しても消してもウインドウサイズが変わらないのにイライラした覚えがある。

Appleのオフィシャルブラウザだからいいのかも知れないが。

2001-02-05

リンク用バナー

個人的に、最も気に入らない二代目バナーに妙な人気があるのは何故でしょうか?(使用比率2/2、デフォルト除く)

2001-02-04

ファンが作品に関与すると言う事

僕は、「ウルトラマンダイナ」でアスカがダイナに変身する時のシーンが好きだった。途中で差し換えられたのでは無く、初期で使われたやつだ。

ここ最近は、インターネットの普及と供に作品の制作者に対するフィードバックもかなりし易くなっている。それはつまり、制作者の意図をファンが潰す可能性も在ると言う事だ。

僕は「ウルトラマンティガ」が終わった後だっただけに、ティガに代わるものとしてのダイナには複雑な気持ちでいた。話が進むにつれ、対象年令の低年齢化が手に取る様に分かった。合体変型するライドメカ。子供っぽい主人公。分りやすいキャラクター。何よりも、オープニングのDのロゴがやけにチープに見えた。で、変身シーンである。他のウルトラマンと違い、ぐっと仰ぐ視点は「ウルトラマン80」のそれと同じであるが、ダイナの場合はCGを使っているお蔭でより巨大感がある。「ウルトラマンができるまで」で実相寺監督が書いていたのは、ひょっとしてこういう事じゃ無かったのだろうかとその時は感じた。僕は、あの変身シーンにティガでは無いダイナを感じていたのだ。

ところが、その変身シーンは早い内から使われなくなり(ティガでは変身シーンを使わない事はしょっちゅうだったので、別にどうとも思っていなかったが)別のバージョンが登場した。ティガで使われたCGを用いたモノでは無く、もう完全にカメラで撮った人形そのままと言った感じだった。後でsgi君に聞いてみた所、ハネジローBBS(円谷プロ公式サイトのBBS)では初期に使われた変身シーンはかなりの不評だったらしい。「CG丸出し」なのがその主な理由だったと言う。おそらく、それを「汲んだ」円谷プロは新しく撮り直したのだろう。

僕は、あの初期の変身シーンを「CG丸出し」として否定した人たちに尋ねたい。じゃぁ特撮シーンは「特撮丸出し」では無いんですか?

特撮ファンの間で、模型サイズのモノを「模型そのものじゃ無いか」等と不粋な事を言わすにそれを本物として「見立て」ることは日常的に行われている。「ゴジラ」以来40年近い歴史を持つ特撮では、一般的にそれも認められている。だが、CGに関してはそうでは無い。「ジュラシック・パーク」を持ち出すまでも無く、CGを使えば殆ど本物のように見せる事が出来る事を誰でも知っている。故に、本物っぽく無いCG等は特に攻撃され易い。「温もりが無い」等と。ところが、もともと本物っぽさは要求されて来なかった日本のリミテッド・アニメーションではほぼCGによる描写が定着した感がある。最も分りやすいのは「ZOIDS」だろう。

では、本物っぽくする事が出来るもののその表現には限界のある、つまり見立ての必要な特撮で、なんであのシーンが受け入れられなかったのか。僕は、円谷プロにフィードバックした否定派の人達が特撮のそれのようにCGの変身シーンを「見立て」られなかったからだと思っている。僕にとってみれば、当時の機材の性能と、ティガの終盤に圧された極めて苦しい時間と、何よりもティガ当時のスタッフのCGの技術力を考えれば、あのシーンは賞賛こそすれ、否定等出来ない。そして、僕自身はあのシーンを「アスカからダイナへの変身」として見立てる事が出来た。

制作者は、フィードバックをくれる人達だけが視聴者だと思わないで欲しい。特にインターネットでは「正しい人」では無く「声の大きい人」の方が多数だと思われがちなのだ。そうでは無い。大部分の人達は「正しい」認識をしている。だがそれは「声の大きい人」の意見に隠れて見えない。僕は、ダイナを見ていた多くの人達はあの変身シーンをちゃんと「見立て」られたと思っている。

今までと変わり無いノーマルな変身シーンに差し換えられた事は、その後の「ガイア」にまで影響を残した。こちらは今までのノーマルな変身シーン、特に初代ウルトラマンのそれを当時のCG技術で焼き直したようなモノである意味洗練されていて好きではあるのだが、もしダイナ初期のシーンが受け継がれる事になっていたらと思うと、非常に残念だ。

2001-02-03

ZOIDS

いくら同じゾイド(ライトニングサイクス)に乗ってるからって同じ声優使うこた無いでしょ……もっともカスミ/リノンぐらいに離れていてもちょっと戸惑うが。

何はともあれ、タイプチェンジである。ライガー・ゼロ・スカイタイプ(紫じゃなくて青だからミラクルタイプ?)ことライガー・ゼロ・イェーガー。このネーミングがチャック・イェーガーから取られた事は想像に難くない、が、いくら何でもゼロ・イェーガー・イオンブーストにスパイラルブーストモードはないでしょぅ。あのブーストユニットつけてるだけでノーマルよりかなり重くなりそうなんだが、そこはフィンスタビライザーを逆向きにして浮力を作っている為か?あるいはゼロ・イェーガーは普段から常にブーストポッド作動状態なのか?ここは児童向け雑誌から情報を得る他あるまい。でもどれも立ち読みできないんだよなぁ。買う訳にもいかんし……

さて、気になる残りの2タイプなのだが、赤はこの流れからパワータイプと仮定するとオープニングに見られる赤の挙動(見た感じはスナイプっぽかった)が若干不振に思える。残る黄色か緑(箱の色からは緑だと思われるのだが、ちょっと分かりにくい)の役所も気になる。しかしライガー・ゼロにここまでポテンシャルを持たせると、残りのウォーリア達の立場がどんどん無くなって行く様に思えるのが気掛かりだ。

γ

gAMAチャンクを抜いたPNGであればプラットフォオームのγに沿ってレンダリングしてくれるものと思っていたら、N6で表示させた所全然直ってなかった。不振不審に思ってPNGの仕様書を調べてみた所、

When the incoming image has unknown gamma (no gAMA chunk), choose a likely default file_gamma value, but allow the user to select a new one if the result proves too dark or too light.

肝心の所は、省略時設定っぽいものを選べと書かれている。と言う事は、別段プラットフォームのγに束縛される必要はなく、デファクトスタンダードであるWindowsアプリケーションで作られたとして表示されてもおかしくない。ならば、PNGの場合HTMLやCSSで指定した色と併せるのは原理的に無理だ。

結局、HTMLやCSSとの色彩的な親和性を考える時、GIFの方に軍配があがってしまう。PainterにGraphicConvertorだからライセンス問題は無いと思われるものの、このサイトの背景の場合ファイルサイズが68バイト増えてしまう……

アルファチャンネル

PNGのアルファチャンネルを手放しで喜ぶ人も多いのだが、ちょっと待って欲しい。これをアルファチャンネル非対応のビューワとの互換性を考える時、非常に困った事になってしまう。

ピクセル毎の透明度が指定できる事で何が一番いいのかと言うと、無論の事アンチエイリアシング処理した画像上のエッジが異なった背景の時に目立たなくなる事だろう。これは理解できる。しかし、そうするためにはエッジ上のピクセルは全て地の色でなければならない。そうするとアルファチャンネル非対応ビューワで見た時に、所謂ジャギが目立つ上にエッジが若干広くなったり、あるいは背景が地の色と全く同じになってしまうと言った事になる。

結局の所、新しい仕様を使って古いソフトを切るか、古いソフトを優先させて新しい仕様を使わないかになってしまうのだ。Webと言う場所の特殊性を知っていれば、そして普通にグラフィックをやっていれば、ここまで来る前にこの程度の問題にはすぐ気がつくはずである。PNGの策定者は、おそらく何も考えずに今までの画像処理の論法をそのままPNGにも持ち込んだのだろう。しかし、今までのそう言ったアルファチャンネルサポートの画像形式がほとんど下位互換性の無い事に気付かないはず無い。そう言う事や前述のγの話も含めて、PNGはあちこちで言われている程簡単にGIFに代われるモノではない。ここ最近、嫌と言う程それを知った。

2001-02-01

object要素

これで包んでやったPNGのimgは、Win版のN4ではaでリンクを指定してやっても何故か動かない。ローディングをよく見ているとobjectのJPEGは内蔵ビューワで表示しているのに対し、objectのPNGはいちいちQuickTimeを呼び出しているのが分かる。imgのPNGではこんな事無いのに不思議だ。で、おそらくN4的にはプラグイン・ペインの内部で起きたマウスイベントはプラグインが処理するべきであってN4そのものは関知しないからaが効かないのでは無いだろうか。

しかし、これではアイコンが全く役に立たなくなってしまう。どうするべきか……

ナビゲーションバー

N4で見て回っていて一番気になるのはナビゲーションバーが若干妙な表示になることだ。これは見ていて気持ちが悪い。HTML的に見て正しくはあるが、ナビゲーションのし易さから言うと三角だ。そんな訳で以下に続く

アクセシビリティ

とほほのWWW入門アクセサビリティと表記しているのは、ひょっとして"Access"+"Ability"で"Accessability"になる筈だと勘違いしているからだろうか?正解は、"Accessibility"なんだが。"Visual"+"Ability"だって"Visibility"だし、自然言語が表記上の合理性より口にした時の語呂を優先させるのは別に変な事では無いと思う。

そんな事はさておき、アクセシビリティの高いページがナビゲーションし易いページかと言うと、そう言うものでも無いのでは無いのかとこの頃思えるようになってきた。Appleのページなんか、テーブルにスライスした画像をばんばん使って、「これってただの文字やん」と言えるようなものまで画像で表現し、WAIとは程遠いページ構成なんだが、確かにN4でブラウズしている時の感触は時としてAquaを触っているんではと錯覚させてくれる程気持ちが良い。同じ様な構成にも拘らず、Sunやその他の企業のサイト、あるいはどの個人サイトでも感じる事のできない「Appleフィーリング」がそこに存在し、それがナビゲーションの快感にもなっている。「ユーザーエクスペリエンス」と言うのはコンピュータに於いてはどの工学分野よりも蔑ろにされがちであるが、「使い易さ」の原点が「ユーザーエクスペリエンス」の重視にある事を考えれば、決してそれを重視しているとは思えないHTMLの「アクセシビリティ」の思想が果たして正しいものなのか、非常に不安になる。

もっとも、「ユーザーエクスペリエンス」の提供はUAがやるべきであって、HTMLの範疇では無いと言えばそれまでなのだが、例えばlink要素のrel="bookmark"なインスタンスにaccesskeyが指定できないでは一サイト内をショートカットキーでコンテンツを移動する際にlinkでは無くaをつかえと言う事になるがそれでは「ユーザーエクスペリエンス」はHTML上の問題となってしまう。