と言う訳でものは試しとPBX.nibを書き換えてみる。日記のトップには最終更新分の日記と一覧……言う程無いけど……を置いてあるのは前と同じだけど、検索エンジン等に下手に登録されるのを避ける様になんとか明示する方法は無いものかと考えた末、今はトップにはblockquoteで括って置いてある訳だが、ここで問題になるのが見出し付け。基本的には前と同じくログもトップも同じレベル、日付けはh2、以下細かく別れて、となっている。で、h2は日付けである事が保証されているから他へのリンクにはならないので、未だ対応ブラウザの少ないblockquoteのcite属性を補完する形でトップ側にはh2にのみcite要素とリンクを指定しており、h3はログ側にidをきっちり振っているんだけど、これは他へのリンクが埋め込まれる場合もあるのでトップからログへのciteとしては機能し得ない。
で、御覧の様な形になるわけだが、大分前から大流行りの段落アンカー（とその仲間達）の世界では見出しにリンクの指定されてない意味ブロックはid付けされてないと言う暗黙の了解があるらしくきっちりidを割り振っているにも関わらず参照されるのは日付けだけ、と言う非常に好ましくない状態にある。ここに指定されているリンクはあくまでblockquoteの補完であって段落アンカー（とその仲間達）の文脈とはまた全然別なのだが、訪問者が意図通り行動しない事への責任は著作者にあると言うのはサイト管理に於いて当然の事であるからして何らかの対策を打たねばなるまい。
citeは一切無し。取りあえず現状維持。
Classic由来のリスト表示は、ファイルが選択されるとアイコンは暗くなり、ファイルネームがアクセントカラーで修飾される。この時のカーソルへの反応範囲はアイコンと名前、情報を示す文字の上であり、それ以上でもそれ以下でもない。
対してNeXT由来のカラム表示の場合、ファイルが選択されるとアイコンは暗くならずに文字と同じ扱いでバックグラウンドのみがアクセントカラーとなる。そして、アクセントカラーで修飾されるのはカラムの幅一杯。ファイルを選択する時、ダブルクリックで開く時はこのカラムの幅一杯がカーソルへの反応範囲となる。
さてここからが問題だ。ClassicからFinderは通常何も無い所をクリック&ホールドし、そのままズズズと引き摺っていくとその領域にあわせて枠が表れる。この時枠の中にアイコン、ファイルネーム、情報の内どれかの一部でも入ればそのファイルは選択される。これはCarbon Finderでも同じ。が、NeXT由来のカラム表示では事が違ってくる。この場合、カラム幅一杯にカーソルへの反応範囲がある事は述べたが、ここで文字の乗っていない範囲をドラッグすると、ファイルはマウスに付いて来ずに並んだファイルが同時に選択される。ちょうどExcelで十字カーソルをセルからセルへとドラッグした時に等しい。また、ファイルをフォルダへドロップする時はドラッグする時と同じくアイコン、または名前へと落とす必要がある。
つまり、ファイル選択/ダブルクリックオープンは可能であれど、ファイルのドラッグ&ドロップは不可能と言うグレーゾーンが存在するのだ。僕はこれの御蔭で何度もドラッグし損ねた。何かをドラッグしようと言うとき、アクセントカラーで修飾されているカラムの一部にカーソルを当てても意味は無く、意識的にアイコンか名前の上にカーソルを当てねばならないのだ。
僕としてはカラム内側でのファイルの整順/ツリー表示を望む身であるので、Classic流に統一されるのが望ましい。
ついでに書くと、OS X 10.1になってカラムの幅を変えられる様になったのはいいけど、変えた後にどうにも中途半端な幅でカラムが固定されてパスの上下どちらかに中途半端に表示されちゃってると言う事がままあるので、カラムの幅を換えるサイズボックスの脇にちょうどいい感じの幅に固定してくれるリサイズボックスを置いてくんないかな。
Script Menuを入れてみる。OS 9ではOSA Menuを愛用していたので有り難い……が、OSA Menuはアクティブなアプリケーショ毎にメニューを切り替えてくれる非常にインテリジェントな仕様だったのに、Script Menuはアプリケーションが何だろうが出て来るメニューはLibrary/Scriptsの中身のまんま、FinderなのにMail用のスクリプトフォルダを見せられたりする。どのLibraryなのかの区別がつく様になっているのがせめてもの救いだ。
で、こいつのインストール方法を見てもしやと思いバッテリモニタをCommand+Dragで動かしてみるとちゃんとツールバーやDockの様に動く。おそらく、使われているノウハウは全く同じだろう。であれば、AppleがこのAPIを公開しさえすればDocklingと同じく3rdパーティにもちゃんと使えるはず。もっとも、これを公開しないのはAppleにも考えがあっての事だろう。ただ、そうであればこのScript Menuのインストール方法には問題がある。
にしても……こうなってくるとアップルメニューを右側に移して欲しくなるんだけど……だってそうじゃない!?アプリケーションローカルなメニューは左、システムグローバルなメニューは右って形で統一出来る。昔のアップルメニューって、一番よく使う項目は二番目以降、と言うHIGに準拠する為に作られたんじゃないかと思うし。今はアプリケーションメニューがあるし。
何かこの間から保守派に刺される様な提案ばっかりしてますか僕？
何でHelp ViewerがSystem/Library/CoreServicesに入っていてSystem PreferencesがApplicationsに入っているのだろうか？
legendを書き出せない。inputのtypeを指定出来ない。legendを普通のブロック要素としてレンダリングする。……完全な標準DOMで動くスクリプトはまだまだ書けそうにない。てかMozillaもinnerHTML持ってるのでそっちの方が遥かに安全に扱えると言うのはなんとも寂しい。
自分で定義したクラス&オブジェクトでなんとかやれるかと喜んだものの、いざプロセスがユーザーインターフェイスからのアクションとなるととたんにどうしようもなくなるのに困っている。thisはそれを定義しているオブジェクトではなく本当に現在使ってるものでしかないと言う事なんだろう。
なんだこれ？<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
Apple MailのContents/Resources/senders.tiffって一体何の画像？
誰も指摘しないので全然気が付かなかったが、Carbonアプリのアプリケーションメニューに「サービス」が加わっている。それはとってもめでたい事なのだが、Carbon Finderですら何にも対応してないのでは意味が無い。
以前も書いたが、例えばOmniWebはテキストの選択範囲をURLとしてジャンプする機能があるのだが、これがIE5:macなんかでも可能になってくれれば非常に有り難い。また、Stickyを作成するメニューなんかにも対応してもらえばこれまた便利だ。
どっちかと言うとCarbonのTSMやATSで対応するべき事かも知れないけど。それにしても、Grabのウィンドウをキャプチャするコマンドはいつになったら使用可能になるのだ？
誰も書いてくれてないので自分でまとめました。
McVISIONによるとアトランティス 失われた帝国の日本語版主役は長野博らしい。
ファーストコンタクトがパクりネタだったんで印象はあんまり良くなかったんだが、これは楽しみだ（笑）。
古いけど、ECCO's ECHOで検索をかけてみると、結構出てくる。見て貰ってんだ。我ながら恥ずかしいもん書いてるし。
やべ、本家が引っ掛かってもた。
引用部分以外はその通りなので修正しました。ところで隅に残った栗きんとんのカスなんかは意地汚くても食わんと損です。それはさておき、
Mac OS X では Perl は /usr/bin/perl にしかありません。そこでハードリンクを使…うんでなくて、シンボリックリンクでいいような…。てか、「スクリプトのほうの Perl パスをいちいち書き変えませう」的説明のほうがポピュラ〜で安全カモ。シンボリック/ハードリンクでどうにかしちゃうのって、コトの道理がわかる（＆こゆ文書の助けが要らない）人向けのような。
シンボリックリンクでは動作できない事が確認されてます。
このへんって username.conf に書いておいてもいいようなきがする…。 ~/Sites 以下がぜんぶ CGI 実行可能になるのはナニだ、とか言われる可能性アリだけど。
個人的な目的としてはサーバでCGIを動かす時の練習になればいいと思ってますので、いろんなサーバで潰しの効く設定が一番いいなと思って設定はあのような形にしました。サーバのetc/httpd/users/username.confをいじる事はまずあり得ませんし、.htaccessファイルの使い方は覚えておいて損は無いと思います。
リンクを使うのも、UNIXのコマンドを覚えられるだろうと思ったからです。Macなんだからそんなもん覚えたくないというのは分かるんですが、Webサイト製作のスキルを向上させようと思えば必然的にUNIXについて学ぶ必要が出てきますし、僕自身こういうある意味不親切なコマンドを見よう見まねで打ち込んで体で覚えたと言う経験もありますので。
ところで、今このページでScript Menu/べんりせっと/引用元を表示でエライ目に遭ったんですが、やっぱり背景はいじらない方がいいと思います。
そう言えばTim LeeのWWWって元々NeXTのアプリケーションだったわけで、その直系になるMac OS Xで他のUNIXで育ったApacheを使っているのだと考えると面白い。
Project Builderのメニューが長過ぎて時計が隠れる。不便。
DockにしろMenu ExtraにしろAppleが必死でそのインターフェイスを改良しようとしているのは分かるのだが、全く別の方向に発展して来たNeXT由来のインターフェイスとコンフリクトしている部分も多々ある。何よりも、Mac OS自身がその使いやすさの為に拡張して来た（あるいはハードウェアの限界との折り合いの上で削り落として来た部分が）、本来Macのインターフェイスの中では何の違和感も無かったものがNeXTとの融合のおかげで統一性を持って整備されていない。
アプリケーションメニューは元々NeXTのものだったけど、Mac的にはアップルメニューのAbout、ファイルメニューの終了、編集メニューの初期設定（これはアプリによってはファイルメニューにあったりして統一されてなかった）そしてプロセスメニューの各表示コマンドを統一したものになっている。けど、アップルメニューが左端にあったりMenu Extraが出て来たりしてメニューバーとしてはアプリケーションメニューが増えただけと言う状態になりつつある。さらに、半ば全てのアプリケーションで義務的に用意されているウインドウメニューとヘルプメニューのおかげで画面がかなり喰われる。で、先述のように時計が隠れてしまうのだが。
以前も書いたが、先ずウインドウメニューとヘルプメニューはアプリケーションメニューに埋めてしまうべきだ。ファイルメニューや編集メニューと歴史の差はあれ、これだけ項目数に差があるものを同列に扱うのは画面が勿体ない。
と言う訳でものは試しとPBX.nibを書き換えてみる。
ウインドウメニューはきっかり動く。IB上で完全に抽象化されているからだろう。だが、IB上での抽象化が中途半端なヘルプメニューはちゃんと動いてくれなかった。とは言え、この手の改造がカット&ペーストで出来るんですよ。ResEditもかくやと思いませんか？ Visual Studioやらその他Builderがここまで出来ますかっ！？
閑話休題、これならPBでも時計は隠れない。
で、本来は画面の狭いPowerBookの為に用意されたコントロールバーだったが、別に狭くなくても使えて便利なのもあって標準的に使える様になったものを、昔からある右側メニューの形にしたのがMenu Extraで、アップルメニューが（Dockでやれ、と）カスタマイズ不可能になって結果的にMenu Extraっぽくなってしまった。もっとも、Menu Extraが出る前はDock ExtraでやろうとしていたんだからむしろMenu Extraがアップルメニューっぽくなったと言うべきか。どちらにしろメニューバー自身に大きな変化が見られないままメニューバーの中だけ、Dockの中だけでやるにはコントロールバーの機能はいささか強力すぎた。Dock/Menu Extra双方で使える様になれば嬉しいんだが。特にバッテリモニタ。
……とりあえず、アップルメニューの中身を今のままにするつもりなら右側に移しましょう。
モスラ平成三部作のサントラ（全部完全版なのだ）からクライマックス〜エンディングの選りすぐりの最高に盛り上がる曲を集めてiTunesに落としていた所、モスラ2 オリジナルサウンドトラック 完全版 disc1の中に22 千尋の谷へ (M20) 1:50
なる文字列が。
こう言う使い方をするのか。……関係無いがやっぱり現状のrubyは気に喰わない。
黒Macと言う前例はあったものの、iMacがパソコン関係、あるいはそれ以上の産業デザインに及ぼした影響に疑う余地は無いだろう。それはApple自身への影響についても言える。デザイナーがiMacのデザインにインスピレーションを受けた
と語ったIE5:macと、OS Xの顔となったAquaは驚くほどの類似を見せている（IE5:macのリリースはAquaの発表よりも後なのだが、デザインそのものはAquaが発表される遥か以前に行われたはずだ）。iMacとほぼ同時にリリースされたPowerMac G3はしかしユーザーからは結構不評が出て、iMacのカラーバリエーションが増え、iBookもリリースされた傍らでPowerMacはいち早くグラファイトモデルへと切り替わった。全てを削ぎ落としたかのようなG4 Cubeのリリースされ、ポップな色合いの5色iMacが落ち着いた雰囲気の3色iMacに変わった。
デスクトップマシンが次々にデザインを変えて行く中で、PowerBookは曲線的なラインを取り込みながら500シリーズのデザインをしっかり受け継いでいた。僕の持っているPowerBook G3 (Bronze keyboard)はその最終モデルにあたる。PowerBook G3中最も薄く、ADB/外部SCSI等のレガシーデバイスを一切廃しUSB/FireWireに完全に置き換えており、黒い美観を損ねないながら当時のMacの特徴であったトランスルーセントなキーボードを採用し、そのうえフタのアップルマークが光る（！）このモデルはおそらく頂点にあると言っていい。……贔屓している事は認める。中央のラインに微妙なモールドが無くなった事は僕も少々残念に思っている。
で、PowerMac G4に続くノート機として出たPowerBook G4は500シリーズ以来のデザインを捨て、Cubeに端を発した全て削ぎ落としたデザインになった。時を同じくしてPowerMacもまたiMac以来のデザインであったヘアライン（こう呼んでいいのかどうかは知らないけど）まで削ぎ落としている。iMacによってAppleが付加した色とテクスチャが捨てられ、形だけが残された。特に色はVAIOが落とせなかった部分だ。
そういうハードウェアの変遷の中で、ソフトウェアは止まっている。一つはOS 8……この場合System 8/Coplandと呼ぶべきか……のプラチナから出て来たQuickTimeに代表されるメタリックシルバーのインターフェイス。二つめはiMacから出て来たAqua。二つの一番いい例がiTunesだ。iTunesのインターフェイスがQuickTime風なのは周知の通り。アイコンに目を向けると、version 1ではピンクと紫のポップなイメージ、丁度5色iMacと同系統。version 2ではくすんだ青、3色iMacと同じ。またOS X版のタイトルバーを見れば分かる通り、メタリックシルバーのウインドウではAquaのボタンは浮いてしょうがない。下に配置されている各種ボタンのデザインの変遷を見ても混乱が生じているのが分かる。
変化の続いているiTunesはまだいいが、Aquaはと言うとiMac……しかも5色の頃のポップなデザインから変わっていない。いや、デザインと言うよりもスキームの問題だが、アップルメニューのアイコンは大分落ち着いた雰囲気になったものの、青いスクロールボックス、デフォルトボタン、タイトルバーの各種ボタンはいまいち落ち着かない。かと行ってアピアランスをグラファイトにしてしまうと色が一切無くなってしまうのでこれまた気持ち悪い。シックな感じのPowerBookで扱う上でも、是非とももう少し落ち着いた感じの、せめて3色iMacくらいのスキームのアピアランスを提供して欲しい。
……っちゅーかカスタマイズさせろ！
Netscape6.2日本語パッケージを入れてやっと気付いた事。Mozillaは独りで他言語対応したつもりでいる。アップルメニュー、及びアプリケーションメニューのアバウト項目以外が英語のままだ。「設定」が未だに編集メニューにあるし、手抜きもたいがいにしろと言いたい。
それと同時に気が付いたが、アプリケーションのロケールにアップルメニュー等も併せるのはいいのだが、IMメニューやMenu Extrasの方は何にも変わらない。IMはしようがないとしても、同じメニューバーに存在するにも関わらずこれでは統一感に欠ける。やはり、アップルメニューもIMメニューもMenu Extraにしてしまって右側に移し、システムグローバルなロケールに併せるMenu Extraとあくまでアプリケーションローカルなロケールに併せるアプリケーションメニュー以右にした方が統一感が出る。
僕がアップルメニューを右側に移す事を何度も言うのは、昔のアップルメニュー様に何でもかんでも出来なくなっていて、極めて限られた機能しか持たないのでそう頻繁にアクセスする事も無いと思うからだ。OS Xのアップルメニューは右利きの人が左から右へ、上から下へと操作する快適さをさほど必要としない。むしろClassicでハードディスクが右側にあるのと同じような存在であるとも言える。
Carbon Graphic Converterにパス中に日本語が含まれるファイルを表示させたら化けた。
昨日MozillaをなじったがどうやらCarbon自身がCocoaの多言語指向に馴染んでないらしい。……そう思ったのだがふと気が付いてIE5.1:macの中身を除いたら各国語のlprojフォルダがあるやんけ！ 中身は全てデフォルトの設定ファイルやrsrcファイル（Classic風に言うとリソースフォークに各国語バージョンのリソースが共存していると言う事）でnibファイルは無い。つまり、CarbonでもCocoa風多言語指向なアプリは作成できると言う事か。これってMach-Oとかそう言うレベルの問題じゃ無いよな。
もっとも、Cocoaの多言語指向にしても要は各国語専用システムをそれぞれアプリケーションにも持たせると言う発想な訳で（だから文字化ける）、本当に多言語指向にしたければ先ずロケールに関わらずあらゆる言語を扱える様にしなければならない。……道は遠そうだが。
店頭デモをプレイしてみる。先ずやったのはフライトシューティングでは必ずやらなければならない十字キーの操作上下反転。こればっかりはどうしようもない。
ワンエリアをクリアしての感想は、「ロックオンレーザーの快感だけを取り出したパンツァードラグーン」。分かる人にしか分からない例えで申し訳ないが、もちろんロックオンレーザーだけでゲームが構成されている訳では無い。ロックオンとファイアのタイミングに併せてサウンドが変化して行くと言うのがこのゲームの目玉であり、確かに面白い。が、それ以外に面白いと思える要素が無いので、これならむしろパンツァードラグーンの世界観の中でやってくれた方が面白かった様に思う。……もちろん、サウンド側に重点が置かれているこのゲームをパンツァードラグーン並のシューティングとして扱うのには少々無理があったかもしれない。
WAFFファイルのダブルクリックでIE5.1:macを起動させると指定したWAFFではなくキャッシュのWAFFの方を参照しながらオフラインで開くようだ。WAFFファイルはIE5:macの持つアドバンテージの一つなので是非とも早急に直して欲しい。
どうもHTMLの仕様にはちぐはぐな所があると思っているのだが、あるいはスケーラビリティに対する思想の欠如がその理由と言えるかもしれない。
大枚叩いたPainter。気が付けばシェイプで全てこなそうとする自分がいる。そしてドローソフトであれば当然のベジェ曲線編集機能がほとんど無い事に困ってたり。
……OS X版が出たときはFlashを買おう……思い切ってFreeHandにしようかなぁ……Adobeは嫌いなのでIllustratorは却下……Canvasって手もあるか……
全然關係ないけれども、<mouse>〜</mouse>なる「mouse要素」、或はキーボードやマウス等による操作一般を表現する要素がHTMLの規格には必要だと思つた。
HTML は電子テキストのデータ構造を規定するものです。だから見栄え飾りはブラウザのおまかせか CSS に分離することが推奨されました。おなじく、操作体系 (UI) も HTML で規定しちゃうんじゃなく、ブラウザのおまかせにするか、パゲ製作者がどーしてもカスタムしたいのなら「ユーザインターフェイスファイル」として分離されるべきかなと。
おそらく野嵜さんの言っているのはkbdみたいなやつだと思うんですが。<mouse>右クリック</mouse>とか。
僕はこういうものに関しては何も決めないのがいいと思っています。インラインフレーズではただでさえcode、var、kbd、sampの神経質な精密定義のお陰で誤用が広がっているので、むやみに要素を増やす事は更なる誤用を生む土台になるからです。……要素に限らず、リンクタイプ等についてもそれが言えますが。だいたい、元々はRTFの一種として設計されたHTMLをむやみに解釈改変したりするから……
SECOND ECHOの方向性が見えて来たので久しぶりにiCab、OmniWeb、Operaを立ち上げての表示チェック。
iCabもOmniWebも駄目駄目。N4向けのサイトを閲覧するぶんにはいいかも知れないが、IE4以下のCSS解釈はどうしようもない。フィードバックとかそう言うレベルじゃ無い。仕様書を読め。あと、W3Cもブラウザベンダーには会費無料とか開発者とのコンセンサスをもっと維持する努力をしてくれ。
評価以前がOpera。なんつったってドラッグ&ドロップへの対応は全く無し（appアイコンにしてもブラウザウインドウにしても）。ファイルオープンで開こうとしたらHTMLファイルのセルは全て薄くなってる（読めないよ〜とほざいていると言う事）。IE5:macのアドレスバーからfileスキームのURLをコピーしても駄目。
Operaはレンダリングエンジン以前の問題なので評価はしないが、未だにTasmanを超えるレンダリングエンジンがGeckoしか存在しないと言うのはどうにかして欲しい。作れないならGecko使ってくれ。特にiCab。あれが独自のレンダリングエンジンを持っている意味って一体何なのだ？
クロスプラットフォームな仕様だと騒いで、結局その仕様が特定のプラットフォームでしか有効にならないようでは全然意味がないぞ！
うぉ、何だこの企画わっ！ ネット……て事は、公式ファンブックだとか攻略本だとかは無し？ 紙面のmoo絵を眺める幸せは感じられんのか！？
border: 0 none | border: 1px solid #fff |
|---|---|
 |
 |
IE5:macとMozillaとで色合いが違って見えるのはColorSyncの威力。
何故か知らないがMozillaはborder無しのブロックの中に入れた最初のブロックのmargin-topの領域は背景を適用してくれないみたいで、borderを与えるとちゃんと表示してくれる。この手のborder無しの時のmarginの妙な挙動はIE5:macにもあるんだが、今回のは確か今は亡き旧Blackboardの構築時にも遭遇した覚えがある。おおらくblockquote等へのスタイル指定に関する互換性の為だろう。開発者は仕様書の策定者には分からない苦労をしているのだ。……おかげで御覧の様な不思議な非再現性が見られる訳だが。
もう一つ、IE5:macではline-heghitで領域が取得されその中程に表示されているのだが、Mozillaではline-heightは次の行が何処に来るかと言う形になっている。borderを指定した方を見比べれば一目瞭然。さてこれはどちらが正しいでしょうか？
正解はIE5:mac。とは言えアプリケーションの取得するフォントサイズと実際に表示される領域にはズレがあるのでIE5:macでは若干下寄りに見える。それとline-height未指定の状態のOsakaとヒラギノの見え方には違いがある。システムそのものがline-heightに近いプロパティを持っているのは当然だが、ヒラギノはデフォルトでは見辛いline-heightになっているのはいただけない。
何でlist-style-imageがあるのにlist-style-textとかlist-style-stringとかあるいはもっと包括的にlist-style-contentみたいな属性が無いのか。
現状で好きな文字をリストマーカーに指定しようと思えば:beforeを使うしか無いのだが、ただでさえこの疑似要素に対応するブラウザが少ない上にdisplay:markerに対応するブラウザなど存在しない。
絵に描いた餅のまんまで放置されている仕様の何と多い事か。仕様書を書くなら実装の見通しが立ってからにしてくれ。