カテゴリー: IT系

私はエディタとしてxyzzyというEmacsもどきのソフトとVimと いうViもどきを使っている。双方ともほとんど全ての操作をキーで行う。EmacsもViもUnixのエディタであることを考えれば当然なのだが、 Windowsしか使ったことのない人には非常に奇異なことにうつるかもしれない。しかし慣れるとマウスなんかもう使っていられないので是非お試しあれ。 なお、Viはほんとにシンプルなテキストを編集するのに向いており、キーバインドがホームポジションに近いので実に楽。これに対し、Emacsは非常に高 機能だがキーバインドがCtrl+やM(Shift)+が基本になっているのでVi使いからは「指がつる」と非難される。どちらかといえばEmacs互換もどきのxyzzyの方が入りやすいかもしれない。

PCユーザーは慣れてくるとだんだんにマウスが疎ましくなってくる。最初にわかりやすいのはいいのだが、ある程度システムが理解できると、直感というあやふやなもので操作すると時にエラーを出してしまうのである。つまりコマンドを打つのであればキーを押し間違えなければ確実にあるコマンドを入力できるが、アイコンをクリックするとなるとマウスで非常に狭い領域にカーソルをもって行かなければならないので、ときにその領域をはずしてしまうのである。

ましてノートＰＣのユーザーであるとタッチパッドなどのポインティングデバイスがいくら進化しても、いろいろなことをキーボードショートカットで済ませるようになるのである。そうなるとあるアプリケーションでショートカットを使って予想外の結果がおきると非常に困惑することになる。それが良く起きるのがWWWの世界である。

HTMLにはaccesskeyという属性が用意されている。たとえばこのサイトをInternet Explorer 6で見ているならば、Alt+2–Enterでトップページに移るはずである。これは、トップページへのリンクにaccesskeyとして2が設定されているためである。さてIEではAlt+aで「お気に入り」を開くというショートカットが設定されている。このときあるサイトでaccesskey属性としてaが設定されているとどうなるだろうか。結果としてはaccesskey属性が優先される。すなわちあるwebサイトを見ていたユーザーが別のサイトに移ろうとAlt+aでお気に入りを開こうとしても、トップページへのリンクへフォーカスが移ってしまうという全く予期しないことが起こりうるのである。

これがMozillaなどではさらに深刻で、Alt+bでbookmarkが開く。ところがアクセシビリティを考慮してaccesskeyを設定している多くのサイトではbを「戻る」のリンクのaccesskeyとして設定している。しかもMozillaではIEと違って、Alt+accesskeyでEnterすることなく、一発でリンク先に移ってしまう。そうするとbookmarkを開こうとするたびに戻ってしまうようなことが発生するのである。

思うにHTMLでaccesskey属性は不要なのではないか。UAがlink要素に対して各UAごとにショートカットを設定していれば充分なのではないだろうか。どうせHTML作成者が個々にaccesskeyを設定すれば統一的な設定もなされず、かえってユーザビリティを低下させるだけのような気がするのである。

0.9.9リリース後のMozillaのNightly Trunkがやたらと不安定なのは私の環境のせいか。まっさらなプロフィールからやろうとしてmozilla.exe -Profile Managerを起動しようとしてもXML Parther Errorが出て、はじかれてしまう。うーむ。あ、まさしくBug 131016 – Current “nightly” is hosed. Menu, address bar are gone, xul in the broser windowです。

スラッシュドット ジャパン | カシオ、2004年にも20時間使用可能なノートPC発売?。かなり便利かも

webサイトの制作はいくつかの技術が複合的に絡まりますが、その基本はHTMLです。HTMLの書き方は、「ホームページの作り方」としてネット上に散在していますが、きわめて大きな思想的・技術的「誤り」を含むものをよく見かけます。HTMLの書法には、一種のコツ、あるいはクセが伴います。外国語の発音ではありませんが、はじめに間違ったクセをつけるとそれを取り除くのは大変な苦労をすることになります。初発の段階で正しいHTMLを学ぶことが重要です。

HTMLはきわめて論理的に設計されています。設計されたという点からわかるようにその運用・思想は本質主義的です。なるべく汎用性を高めるべく、自然言語を抽象化するのですから当然です。繰り返しますが「設計されている」ものですから、設計に照らし合わせて「正しいもの（validなもの）」と「正しくないもの（invalidなもの）」にわけることができるのです。自然言語では「意味の伝わる英語」と「意味の伝わらない英語」の区別はありますが、「正しい英語」と「正しくない英語」の基準は不明瞭で主観的なものでしょう。しかしHTMLの場合、「正しいHTML」と「正しくないHTML」は厳格に峻別されることを忘れないようにするべきです。つまり文法的に正しくない英語も英語ですが、文法的に正しくないHTMLはそもそもHTMLではないということです。

正しくないHTML（らしきもの）でも意味の伝わる場合はあります。しかし伝わらない場合もあります。正しいHTMLでは確実に意味が伝わることになっています。しかも正しいHTMLの場合は、単に文法的事項を満たすことによって「正しさ」の大部分をカバーできます。したがって、論理的な関連性のない個々の瑣末な具体的例文を学ぶよりも、正しいHTMLの文法を理解するほうが効率的です。以下は正しいHTMLを書くために非常に簡潔でわかりやすい説明をしているwebページへのリンクです。きわめて短い時間でHTMLの初歩的な文法事項をほぼ完全に理解することができるでしょう。

• ごく簡単なHTMLの説明　神崎正英さん
• ごく簡単なHTMLの説明 — 30分間HTML入門　神崎正英さん
• 好ましいHTML文書を書くための方法と考え方　矢野啓介さん
• はじめてのWebドキュメントづくり　内田明さん

しばらくは、どのように見えているかを気にしないほうが、正しいHTMLを書くクセをつけるにはよいでしょう。意図通りに表示されているということとHTMLが正しいということは等価ではありません。

注意

正しいHTMLを書く、という試みは、自然言語の書き方にも影響を与えることでしょう。

自然言語の文書における論理的な意味を、よりわかりやすくするために特殊な情報を埋め込んでゆく（「マークアップする」といいます）のがHTMLです。したがって、論理性の低い文書は非常にマークアップが困難で、もとの文書にも論理性が求められます。

文学的叙述を重視する人にとっては、機械の都合に人文的理念が負けた、と感じるかもしれません。それは正当な感想です（この点に関しては、拙稿「新世紀エヴァンゲリオンSS/FFをHTML化する人のために」中の「日本語における意味段落・形式段落とHTMLにおけるBR要素・P要素」を参照してください）。しかし一方で、正しいHTMLは文章の論理性を明示的に際立たせます。その意味で、論理的な文章を組み立てる訓練になるのもHTMLを書くということの利点でしょう。

なお英語が読めるひとはW3Cの仕様書なども読むとよいでしょう。特に技術的に難解なことが書いてあるわけではないので、HTMLの理解を深めるのに有用（というより本来は必須）です。日本語訳もありますが、記述がやや生硬ですのであまりお勧めできません。

主張を明確にするためにあえてvalidを「妥当」ではなく「正しい」と訳しました。

【第305回】 GoogleとUnicode(2001年10月14日)で触れたが、Namazuの最大の弱点はunicodeを扱えないことであろう。日本語の形態素要素分析まで行えることがNamazuのウリなわけだから、外国語を完璧に扱える必要はない。中国語を扱ったりする場合は、KakashiやChasenじゃない分かち書きのシステムが必要だろう。しかし単語の区切りでスペースを使用する言語や、日本語は扱えてしかるべきである。特にUnicodeはXMLにおいて標準だし、Microsoft Office文書もXMLを使用する以上、unicode対応は必須だろう。文字としてunicodeを扱えるということと、他言語の検索システムとして利用できるという真のi18nとは別のことである。perlも5.6から、正式にunicodeに対応したことであるし、そろそろ文字レヴェルでは対応して欲しいのである。とっくにこんなことは議論されているとは思うが。

まだペルシア語だけで一ファイル作ったりはしないが、文書の一部でアラビア語やペルシア語を使うことは充分あり得るし、すでにそのようなコンテンツもある。アラビア語やペルシア語の部分はとりあえずおいておいて良いので、日本語の部分だけでも検索できるようにしてほしい（実はサーバのコンテンテトネゴシエーションをつかえば何とかなるのだけれど、なんか無常を感じる）。そうしたらほとんどのコンテンツはUTF-8で作ってしまうつもりである。たとえば「トウショウヘイ」のトウの字はMS-IMEではすぐに出てくるが、Shidt_JisやEUC-JP、ISO-2022-jpでは定義されていないので、現在の掲示板などで使ったりすると不正なのである。しかし掲示板の文字コードまで考えて投稿するような人はいないであろう。そのようなことを考えるとUTF-8で統一してしまいたいのである。Namazuさえ対応してくれれば。……ってもしかしてfilterで可能？

そういえばいつの間にかgoogleもunicodeに対応していたらしくきちんとヒットする。

改装終了

改装が終了した。ナヴィゲーションを消滅させたのは日記で示した通り、HTMLのBODY要素内はなるべく本文以外のものをいれないようにするという方針に従ったためである。ところでなぜlink要素にaccesskey属性がないのだろうか？ もしリンクナヴィゲーションはUAが解決すべきと考えられているなら、とっとと実装をしてほしい。

YY-BOARD過去ログのHTML化

いろいろやっているうちに、これまで改造しながら導入してきたさまざまなCGIが私がStrict化するうちに、perlとしてははなはだ美しくない代物、スパゲティプログラムと化していることを痛感した。スタイルシートもカオスと化しているので、そちらを済ませてからCGIの方も新規変数などを導入してエレガントなものにしていく予定。

ただ直すだけでは面白くないので、T-BookmarkやYY-BORDは表示はなるべくHTML文書として出力するようにしたいと考えた。うちみたいな弱小サイトは全然関係ないが、CGIでそのたびに出力しているとサーバに負担がかかるし、動的コンテンツのためにGoogleをはじめとしたロボットの拾い方も不正確になる。そしてなにより、Namazuのような全文検索で引っかからなくなる。インターネットという場の性質を考えると、掲示板などでなされた議論やリンク集の紹介文も検索できたほうがいいに決まっている（私自身が使いたい）。そのためには、掲示板のログが更新されるたびにHTMLを更新するようにし、過去ログもHTMLとしてValidなものを出力できるようにすれば良いだけである。つまり、読むだけならCGIを使わない書評掲示板のような形にすればよいということだ。掲示板の場合、書評掲示板のように一冊ずつに分ける必要がないので、書評掲示板に比べればずっとシンプルになるだろう。Namazuでのサイト一括の全文検索で掲示板の過去ログまで読めるなら、それくらいはしてもよいと思っている。しかしルーチンまでいじり出すといよいよYY-BOARDとはかけ離れてゆく（笑）

Alertbox: ナビゲーションは役に立つのか？（2000年1月9日）。失われる製作者の視点 – CSSコラム –経由。かなり肯かされました。そういう方向で。

例のmozillaがつくる変なディレクトリの削除方法がでていました。やっと安心できる。秀の介の日記:2002年2月下旬。

妖精現実 フェアリアル－基本多言語面を越えて: 古代イタリア文字。Unicodeネタは私をひっぱりこみやすいが、古代イタリア文字のフォントをついついダウンロードしてしまったのは、自分としてもやりすぎだとおもう。ところでunicodeでの西夏文字の扱いってどうなるんでしたっけ？　とおもって調べてみたらWritten characters of the worldなるサイトでunicodeに設定なしとされている。ほかの言語についてみるとBMPしか考えていないような気もするのでまだ結論は出せず。ちなみに西夏文字は今昔文字鏡にも載っているし、東京外大ＡＡ研でTrue Typeフォントの制作も行われている。で、結局unicodeではどうなんだろう。

• Mozilla。2002022203。ブックマークからジャンプしない。これはまたでかいバグ。
• ぜんぜん気づかなかったが、Vixがバージョンアップしていたのでいれる。カタログの表示が非常に速くなって快適。

CSSにはfont-familyというプロパティがある。たとえば以下のように指定する。

p{font-family: "Times New Roman", Times, "ＭＳ Ｐ明朝", "ＭＳ 明朝", serif;}

この場合、UAは、font-familyにあげられたフォントを一番目から適用し、そのフォントが存在しなければ、順次次のフォントを適用することが求められている。またもしフォントが存在しても、その字形に適用すべきフォントがなければ、次のフォントを使用することが求められている。上記の例で日本語英語混在の文章の場合は、英語ではTimes New Romanがまず適用され、日本語ではTimes New Roman、Timesに日本語のフォントは含まれないためＭＳ Ｐ明朝がまず適用されるフォントということになる。

一太郎やWORDなどで欧文と日本語で別のフォントを指定するようなシステムはCSSではこのようにして実現する。しかるにInternet Explorerでは、最初のフォントがなければ、デフォルトのフォントを適用してしまう。つまり上記の例では、デフォルトのフォントにＭＳ Ｐゴシックが指定されていれば、それが適用されるということである。私自身は非常に迷惑しているわけだが、このルールはCSS2で明文化されたので、CSS1フルサポートをうたっているにすぎないInternet Explorerをあまり強く責められない。Mozillaは正しい実装をしているのだが……。

Mozilla 0.9.9フリーズ。というわけで今日のNightlyはきわめて不安定。やたらとBuildが行われているのがその証拠か。2002022002ではページ内リンクの跳び方がおかしい。Bug 126646 – reload required to load/display any url with fragment (#foo)

• Mozilla。19日に指摘した妙な小さなウィンドウが開くという事象は19日版win32.zpiでは修正されている。変わりにLanguages and Wec ContentでPreferencesが開くようになっている。なんだろ。
• Acrobat Reader 5.0.5リリース。ダウンロードするたびにユーザー登録するのが面倒。

Mozilla。17日の版から起動時に妙な小さなウィンドウが開いて、それが最小化してから起動するという感じになっている。いったいこれはなんなんだろうか？

16日の2月はじめのインストーラ付のmozilla Nightlyは¥document and Settings¥all users¥以下に怪しげなディレクトリを作る（bugzilla:Bug 125958 – Installer creates invalid directories bugzilla-jp:Bug 1906 – インストーラーでデスクトップやスタートメニューのショートカットが作成されない）。これはインストーラを使わずzip版でも同様。削除もできず最悪パーティションの再フォーマットが必要できわめて危険なので最近のnightlyは使わないほうがよい。

2月15日の版にいたってようやく例のmozillaのバグが解消。やっとこさまたNightlyを使う気になる。ところでBuild Comments – MozillaZine!ってその日のビルドでフィックスされたバグだけじゃなくて生じたバグについても書いてくれると嬉しいんですけどねぇ。

My Works/ContextMenu-Extensions for NS6 & Moz – outsider reflex。二週間弱の沈黙を経て、出ました。piroさん、お疲れ様です。先方の掲示板でいろいろと要望を述べましたが、ほとんど解決されています。やっぱりこれなしじゃやっていけません。

Sidebar tabs now have a stop button (41445) while loading their content.

これはいいとして、SidebarをF9で閉じられないのはかなり不便です。明日にはなおるかな……？　Sidebarまわりにかなりの不具合があるようです。

10月17日から三田キャンパス校舎すべてで無線でのLANへの接続が可能になった。276回で実験については書いておいたが、実施段階に入るのが思いのほか早かった。無線LANカードか、無線LANの機能をそなえたPCおよびSSHがあれば、三田ITCのWindows NTアカウントがあれば誰でも使える。

ようやく前から要望していたカフェテリアで珈琲をのみながら、あるいは図書館でレファレンスの禁帯出の書物とインターネットを使いながら、といった環境が用意されたわけで、何はともあれめでたい。ただし図書館は本当に入っているのかどうか疑わしい点もあるので実証実験が必要（つまり自分で試す必要がある）。まだ私自身は一回もつかってみていないので、すべての教室で平均的に満足な接続が得られるのか、あるいはかなりバラツキがあるのか、そのあたりはなんともいえない。近日中に試してみる必要がありそうだ。

私の立場からみれば限りなくめでたいのだが、大学のインフラとしてどうかと考えると、案外SSHの導入がネックになりそうな気もする。ftpサイトからTera Termをダウンロードしてインストール、さらに別のところからSSHを引っ張り出してインストール。しかも全て英語。こうなると普通の初心者には少々つらい気もするのである。

ところでMozillaのSide BarはF9で開閉できる。知らんかった……。