おいらのサイトのトップページは、2つのコンテンツへの飛ぶリンクが書かれているだけ。そうそうメンテナンスは必要ないだろうとタカをくくっていたら、昨日紹介したのstar*sugar*starの7月1日分でこんな指摘が。
あ、そういえばtopページの広告はちょっと困りました。Mozillaだと閉じれないので(^^; うは。
はにゃー、ごめんなさい〜。昔、指摘されたときにグランド・ウェブのほうは直しておいたのに、トップページだけは忘れていたんだ＜おいおい（￣△￣；。すぐに修正しました。
それにしても、ウインドウを閉じられないなんて、なにが起こるかわかったもんではないなぁ。サイトに置かれるリソースが増えてくると、普段見ていないページがいったいどうなっているのか管理しきれなくなる。
こういった事故を減らすために、ユニバーサルデザインが推奨されているというのもわかるなぁ。ポップアップ広告なんかはUAの能力を頼りに設計されるわけだけど、サーバー業者が提供するポップアップ広告なんてサイトの管理者自身がスクリプトを書くわけじゃないのがミソ。とくにおいらのように、スクリプトに疎い人間は、最初から手書き挿入を選ぶべきだったかな。
そういえばね、こんなことも書いてあったよ。
早いっていうかあれだけrefererがあると気になりますです。ある意味恐くて神経まいるので...。
コミューンの過去の所業は、あちこちに知れ渡ってると思っても間違いないと確信＜ime.nuから大量にアクセスがあるより少しはマシかと言ってみるテスト（￣△￣；。
というわけで、現在のデスクトップのスクリーンショットを公開。面白い内容ではないけど、興味のある人は見てみて。総容量170キロバイトくらいの重いページだけどね（￣△￣；。
ずっとMac OS Xを使っていたせいか、明るめのデザインのデスクトップがお気に入り。emacsはなぜか背景色の初期設定がこんな感じだったけど、これはこれで見やすいのでそのまんま。
使ってるソフトは、パネルに並んでいるgftpとemacsとシルフィードとモジラ。gftpをのぞけば、どれもMac OS X（XDarwin）からそのまま移行できたソフトばっかり。ポインター操作が苦手なので、ファイルマネージャーはほとんど利用してなくて、さらにターミナルを起動するのも面倒くさい状態。emacsからシェルを扱う方法を知って喜んでるんだけど、問題は2分割した画面のそれぞれの大きさをどうやって設定していいやら。XEamasならマウスでポンだったのに、XEmacs入れるか……？＜マウス苦手って言ってるのに矛盾してる（￣△￣；。
いまの環境で不満があるとすれば、シャーロックの代わりになるソフトがないこと。いや、モジラ起動すればいいんだけど、複数のサイトへの串差し検索が欲しいときもある。しかもデスクトップから。そういうのKDEのアプレットでないのかなぁ。
Googleで検索中に「css-mode.el」なるパッケージを見つけた。emacsにCSS編集モードを付加するもの。
っつーても、プロパティと値とコメントを色分けしてくれる程度のもの。値の挿入が可能なだけmiの方が優秀。おまけに2バイト文字入力しようとすると、結局入力できないし。うーん、もう少し探してみよう。
一応、設定方法だけどemascのパッケージが入っている /usr/share/emacs/20.7/site-lisp にcss-mode.elファイルをつっこんで、.emacs.elに以下のように記述すればOKだった。
(autoload 'css-mode "css-mode")
(setq auto-mode-alist (cons '("\\.css$" . css-mode) auto-mode-alist))
star*suger*starの、文字サイズを大きくするとテキストボックスが横に間延びしてしまう問題は、無事解決。ある程度まで大きくしても全然平気。っていうか、閲覧者側で文字を大きく表示したとしても、これなら十分かっこいいと思うけど。
せっかくLinuxを入れたんだし、鯖の練習でもしてみようかと思った。ウェブサーバーの真似事は今まで何度もやってきたが、きちんと勉強したことがなかったからだ。
だって、旧Mac OS時代にはWebStarなんて便利なものがあったし、Mac OS Xに組み込まれているアパッチは、システムの環境設定上でボタンを押すだけですぐにある程度の機能を使えてしまう。データベースに関してもファイルメーカーのCDMLを覚えればいいだけだったから、調べなければならないことなどなかったのだ。
とはいうものの、せっかくいろんな機能を使えるサーバースペースを借りていることだし、いろいろできるようになっても損はないなと。なので、自分のところにテスト環境を作ってしまえと思ったわけだ。
とりあえず、自分の手元のHTMLファイルをhttp経由で見られるように、サーバーを起動し、そこに新規ユーザーを追加して、ファイルをアップロードしたい。
アパッチはすでに入っていて、稼働しているようだ。「http://localhost/」にアクセスすると、ちゃんとテストページが表示される。「httpd」というユーザーのホームにある「public_html」がルートディレクトリに指定されている模様。ただし、個別のいわゆる「http://hogehoge.jp/~foo/」以下に置かれるファイルの格納場所がわからん。
というわけでググること約10分。「~/public_html」を作成し、その中に置けば特に設定は不要ということが判明。ただし、ホームのパーミッションを「755」にしると書いてある。「/home」内の各ディレクトリのパーミッションを確認すると、おいらのホームが「700」、「httpd」と「ftpd」が「755」になっている。なんか変えるのいやだなぁ。
でもパーミッションを変更しないと、アパッチがその中のファイルを読み出せないらしい。そういえば、Mac OS Xでは各ユーザーのホームのパーミッションが「755」になっていた。「なんだ、ほかのユーザーから丸見えじゃん」（ホーム内にある、ウェブ共有とファイル共有用以外の各フォルダーは「700」になっている）と思っていたけど、これはアパッチを使ったウェブ共有を一発で実現するためなのかもなぁ。
そこで、冴えた方法を思いついた。ウェブサーバーの練習用アカウントを作って、そっちでいろいろ試せばいい＜誰でも思いつくわい（￣△￣；。せっかくなので、VineLinuxに付属する設定ツール「Webmin」を使ってユーザーを追加しよう。さっそくKDEのメニューから「システム管理ツール（Webmin）」を選んだところ、モジラが起動したものの「接続を拒否されました」と無碍な表示。
原因がよく分からず、再び何十分と時間が過ぎていったが、ふとシェルから「$ rpm -q webmin」と入力したところ、Webminが入っていないことが判明＜もっと早く気が付けや（￣△￣；。メニューにあるからといって組み込まれているとは限らない訳ね（まあFTP版だし、ノートPC設定でインストールしたし）。
ユーザーの追加は問題なくOK。さっそくファイルをアップロードしようとしたところ、FTPがつながらない。初期状態では起動してないのか。これは「# /etc/rc.d/init.d/proftpd start」を実行するだけで済んだ。なるへそ、最初のセットアップはそれほど難しい訳じゃないのね。もっと早く挑戦すればよかった。
しばらくは、いろいろいじって遊んでみないとなぁ＜鯖で動くソフトを作るお勉強でないところがミソだな（￣△￣；。CGIあたりから手を着けてみるか……。
ウェブコンテンツ制作環境の充実を図るために、ローカルのシェル上でHTML文法をチェックできるようにあれこれインストール。マックでは、AHL Runner使ってた。あの素敵なGUIと比べるとちと見た目がショボイが、シェルで作業する分、手が慣れてくれれば効率よくチェックできるのではないかと期待。。
チェックに使うLintはAnother HTML-Lintのダウンロードページから入手。「~/htmllint」を作成して、その中でアーカイブを展開。
できあがったディレクトリの中にあるPerlスクリプトの「htmllint」が実行ファイルなので、これに「# chmod 755 htmllint」というコマンドで実行属性を与える。このファイルはPerlのパスが「/usr/local/bin/perl」になっていたので、自分の環境に合わせて「/usr/bin/perl」に変更。なお、Perlの場所は「$ which perl」というコマンドで調べられた。とりあえず一段落。ところで「~/htmllint」には、パスを通しておいた方がいいのかなぁ？
あと、日本語の文字コードをPerlで扱うための「Jcode」というモジュールが必要らしい。「Jcode - Japanese Charset Handler」というページの解説によると、Perl 5.8にはこの機能があらかじめ組み込まれる予定なのだそうが、おいらの手元のPerlはバージョンが5.6.1だったので、同ページからソースコードを入手してインストールした。rpm化してあとあとのアンインストールを楽にしようと思ったのに、なぜか失敗。うーん（￣△￣；。
準備はこれでOK。一応「~/htmllint」にパスを通してみたので、あとは「# htmllint htmlファイルのパス | less」と入力して、lessページャーで結果を表示させる、と。「〜行目に間違いがあります」形式なので、emacsで行数を表示するようにしておかないとなぁ……。うげ、86点だって（￣△￣；。
ねこめしにっき7月3日分「本文は特定のフォントでの表示を強制しないでほすぃ」に端を発する、ウェブページでのフォント指定に関する各サイトのお話、見てておもろかった。
特に目を引いたのが不浄に日記の「ううう」。本人の実体験談なのでなんか笑える。でもここにウェブサイトの在り方に関する認識の現状が現れてると、おいらは勝手に思いこんでるんだけど、ちとあーだこーだと言わせてもらうよ！
「スタイルシートとかなら、きっちりフォントサイズを決められるんですよね？それでやってくださいな」「それは良いんですが、ここでちょうど良い文字の大きさが、場所によっては小さすぎることもありますよ」「あー、大きすぎてかっこわるいと思われるよりは、小さくて見づらい方がマシなんで、そっちで行きましょうよ」
3番目の発言者、お前はなんのためにウェブサイトの担当をしているのかと小一時間問いつめたい。こういう人にとってウェブサイトなんて、所詮あるだけでいい広報パンフレットの表紙写真代わりでしかなく、これがプレゼンやデモと同じ情報伝達の手段だなんて考えはないのかなぁ。
外注に出すくらいだから、そのサイトってのは広報やユーザーサポート、場合によっては物販に使ういわゆる商用サイトかな。1996年頃の「最新技術にも気を配ってることを宣伝するために、とりあえずウェブサイトを開くか」的な時代なら「あるだけでいい」とか「かっこいいだけでいい」というのでも許されたとは思うけど。
もし商用サイトなら顧客（潜在的に自社従業員）に対する情報の提供というのが第一の目的のはずだし、ビジネスの何かの足しになるビジョンというか存在意義が見えてるから置くわけだし。
存在意義っつーのは、例えばウェブであるが故に万人向けに公開されている結果、サポートの手間が減るとか、本来は営業の人間がプレゼンしながら新規の顧客に説明していたビジネスの内容や提供するソリューションの認知度が口コミ（リンク）で上がる――だったりするわけで、それが見づらかったら意味ないじゃん。紙のブリーフで文字が小さい部分なんて、どうでもいい情報か、義務で仕方なく載せている都合の悪い情報だったりするのがほとんどだぜ。
画面がきれいでも見せ方がどうしようもないレベルなんて、そんな費用対効果の悪いサイトの維持・運営にかかっている費用がもったいないと思わないのだろうか。
※プレゼンという話まで踏み込めば、CSSのprintメディア指定で、カラープリンターで印刷すれば即ブリーフになるなんてのだったら、営業の人間には役立ちそう。
「商用サイトなんだからデザインがしょぼいと……」つー言い訳もありそうだけど、「デザインって何？」ってもう一度問い直した方がいいような気がする。デザインに定評のある雑誌の、例えばテキスト主体のページを見てみるとか。きれいな画像を埋め込むだけがデザインじゃないということがわかるんじゃないかな。そういった雑誌のデザインをしてるのは、オペレーターじゃないよ、デザイナーだよ。あの手の仕事を成し遂げる人たちは、本当のデザインを知ってると思うな。
DTPのデザイナーのエキスパートたちは、見た目の装飾ではなく機能美としてのデザインを追求してる。ウェブに比べてレイアウトの自由度が高い分、目で文章を追いかけやすいように工夫しなければならない。よく、段が飛び飛びでどこにいったらいいのかわからず矢印で行き先を示してるのがあるけど、あれ、だめね＜おまけに、文章あふれてて、続きがどこにあるのかわからなかったり（￣△￣；。校正するほうもやりにくいんじゃないかなぁ＜誤字脱字ばかりのヤシが偉そうに（￣△￣；。
こういった機能美の追求から、「じゃぁここにはこんなリソース（画像とかロゴとかキャプションテキストとか）を置くと、バランスがとれるかな？」とか「何のコーナーかわかりやすいように柱部分に統一したデザインを置いてみよう」という欲求が生まれ、見事なデザインが生まれるんだと思う。よーするに、ただ漫然とブツを置いていくな、ということだけど。
まー、クライアントさんはデザイナーじゃないから、その辺の例はウェブデザイナー側で具体的なものを見せながら提案すべきかとは思うけど。企業サイトでも、機能美と見た目の綺麗さを両立したサイトがあって、そういうのはさんざんウェブ制作の専門誌で取り上げられてるんだし。クライアントにみせないの？ そういうの。
閑話休題。おいらは商用サイトなら、サイトでなにが成功（実現）すれば採算がとれるのかを考えて必要なスペックを検討しないと、この不況のさなかに金をドブに捨ててるようなもんだと言いたいの。でかい文字が本当に格好悪いのか、それとも小さな文字が読むに値しないものなのかの比較は、その上で判断した方がいい。それは外注に依頼する立場の人間としての最低限のルールじゃないかなぁ。
ついでに、同じ文からこれも……。
「フォントはOsakaじゃないといやなんですぅ」とかおっしゃる"プランナー"を名乗る女性
いまどき、初期状態でOsaka以外（つーか、間違いなく細明朝だろ）のフォントが表示されるブラウザーなんぞ使ってるヤシは、例外なく……＜以下、危険なので略（￣△￣；。まあ、そんな厨房プランナー様は「モナーフォントじゃないといやなんですぅ」とでも言ってなさいってこった。
……と、現場の人間でもないのに、さんざん煽ってみるテスト＜おい（￣△￣；
えーっと、どんなウインドウサイズでもなるべくレイアウトが崩れないようにスタイルシートの設定を心がけてきたつもりだった。現行の「puriso」スタイルの大元は、Mac IEを使っているときに出てきたものだ。
それが現在では、モジラに一回表示させてから文字校正をしている。ところがこの環境では、Mac IEではほとんど使わなかったサイドバーを常に表示する状態で使っているためか、ブラウザーのウインドウが非常に幅を取る。HTMLファイルの編集に使ってるemacsと並べるとかなりの面積が相手方のウインドウかぶってしまう。
そこで、ブラウザーのウインドウ幅を狭めてみるが、これがもう大変！ 画面左側にあるリンク集などの表示に約200ピクセル、広告バナーの表示に460ピクセルを使っているため、実際は700ピクセル近くウインドウの横幅がないと横スクロールバーが表示されてしまう。また、それを我慢したとしても、本文の幅がウインドウの半分くらいしかないため、非常に窮屈な感じを受けてしまう。
これではイカンと思い、狭い画面用の代替スタイルシート「w480px」を作ってみた。モジラを使っていれば、「表示」メニューの「スタイル」から選択して適用できる。
このスタイルはバナーの幅である480ピクセル幅でウインドウを表示することを想定して作ってある。pre要素やimg要素の内容がウインドウの幅を超えない限りは、横スクロールバーは表示されず、また本文の幅をある程度余裕を持って確保できる。これなら、emacsの画面と並べて文字校正ができるだけのスペースを空けられる。
ただし、一つだけ問題があった。せっかく選んだスタイルシートは、ページを読み込み直すたびにデフォルトのものに戻されてしまう。Cookieに書き込まないとダメみたい。コミューンのいろんなサイトで使われているJavaScript版のCSSセレクターを導入するのが良さそうだけど、どこで手に入れるのやら。
つーわけで大変に申し訳ないんだけど、「☆☆ 10倍ズバリ！！ 素敵にするホームページの条件」のスタイルシート切り替え（オブジェクト指向）で紹介されていたPiroさん作のCSSセレクターを持ってきてとりあえず適用。問題ありだったら言ってください（￣△￣；。
気をつける点は4つ。1つ目はHTMLのhead要素内にスタイルシート指定のlink要素を置かないこと。2つ目はスタイルシートの起点となるルートはURLじゃないといけないようなので、ローカル環境で恩恵を受けるためには、ローカルとリモートに別の設定をしたファイルを置いておくということ。3つ目はスタイル名を英語にしておくこと。あとはXHTMLを使っているなら、切り替えメニューを置くためのscript要素の周りにあるコメントアウト指定をはずすこと――などかな。
おいらの場合、ハードウェアに関して「ほすぃ」と思うことはほとんどなくて、物欲の対象はたいていソフトだ＜そりゃ物欲と言わんでぇ＜（￣△￣；。
つーか、Desire for Wealthの「ちぃたん日記」7月5日更新分「Marine Aquarium」にて、Mac OS X用のスクリーンセーバーソフト「Marine Aquarium」に関する紹介を発見。これひょっとしてバリュースターに入ってる魚のスクリーンセーバーと同じもの？
というか以前から店頭でヨダレ垂らして見てたので＜きたねぇなぁ（￣△￣；、即Get決定（約12ドル）。家のiMacに突っ込んだですよ。ああ、なんかステキ。惜しむらくは1024×768ピクセルで表示している状態だと、フレームレートが12フレーム/秒くらいしかでないので、どことなくぎこちない。まあ、クェークⅢ アリーナでもその程度の数値しか出ないビデオチップ積んでるし。
マックネタはえらく久しぶりな気がした。
この間からデスクトップの環境を整えるべく、せこせこKDE3を入れているわけだが、ISDN 64キロbpsという貧弱なネット環境のため、なかなか辛いものがある。おいらの青春はダウンロードとともに過ぎ去ってしまうのか……、と悲しくなったので、KDE3の入ったVinePlusを収録した本を探しに行く。Linux magazineのムック版「Linux magazine for beginners」を購入（980円）。
GnomeのTips集以外はほとんど読んだことのある記事ばかりだな……と思いつつ、付録のVinePlusのCD-ROMを挿入。KDE関連のrpmをインストールしたが、あれが必要これが必要とうるさい。依存関連を満たさないとインストールできないようになっているのはrpmの便利な仕様だが、必要なライブラリはどれに入っているのやら。
考えるのも面倒くさいので賭に出た。「/mnt/cdrom/RPMS」上で「# rpm -ivh --replace i386/*.rpm noarch/*.rpm」を実行（￣△￣；。数十秒の沈黙の後、山のようなコンフリクト警告と必要なライブラリーの要求がターミナル画面を埋め尽くしたのは言うまでもあるまい。
この辺、非標準のライブラリーやフレームワークが必要な場合は、ソフトのパッケージに内包してしまうMac OS Xの流儀のほうが、おいらのようなスブの素人には優しい。反UNIX的な流儀かもしれないが、これならコンフリクトの心配もないし、必要なものはソフト自身が持っているわけだから。その代わり、細かなファイルがハードディスク内に山のように増えてしまうし、場合によってはメモリーも喰うけどね。
src.rpmは付いてないのか＜素直にパッケージを買えば？＜だってあれに付いてる商用ソフトに興味ないモン（￣△￣；。XDarwinにKDEを入れる実験をしたかったのになぁ＜丸一日かかりそうだからやめとけ（￣△￣；。
はい、先日のちと格好つけてあれこれ言ってた件。その中の、「※プレゼンという話まで踏み込めば、CSSのprintメディア指定で、カラープリンターで印刷すれば即ブリーフになるなんてのだったら、営業の人間には役立ちそう。
」と言った件について、adramineさんが「gobbledygook/debris+diary」の7月4日更新分「プレゼン…、というかマニュアル」でレスをくれた。
というわけで、営業がhtmlでプレゼンするような酔狂な人間／会社は、見かけたことが無い、私は。私自身はやったことあるけど、営業じゃないし。
ギャフン。やはりいないかぁ、酔狂か。営業が自分で作るんだよな、パワーポイントの資料を。
いや、おいらの視点はそこにあるのではなくて、もっと宣伝っぽいパンフとか。本格的に作るには、アドビ イラストレーターやインデザインのようなソフトが必要になる。もしドリームウィーバーやゴーライブでCSSを活用したピクセル単位のレイアウトが組めて、しかもそれがスクリーン表示用と印刷用の双方を作れるなら、用意するリソースはひとつで済むのになぁー、と効率の問題で考えただけ＜発想が逆か？ インデザインでやれと言われそうだ（￣△￣；＜第一、図版の解像度が3倍以上違うのに……（￣△￣；。いや、営業とマーケと広報が同じことを別々にやっているのもなんだかな、と思っただけ。
XSL-FOを使ってHTMLとPDFに吐き出した方がいい？ そりゃごもっとも。誰かXSL-FOによるレイアウトのスキルを公開するか、XSL-FOをページメーカーレベルの操作性で扱えるレイアウトソフトを作ってくだされ。
あともうひとつ。そのレスの最後に書いてあった文によって、本日2度目のギャフン。
で、話は変わるんだけど、あのー（￣△￣；さん。titleが6月なのは何か意味が？
おいらの脳味噌が1カ月前から進歩していないことの証であります（￣△￣；。
コミューンのみなさま、何かのソースコードを例示するとき、HTMLにはどういう風に記述してます？ やっぱ、<pre><code>ホゲホゲ</code></pre>みたいな感じっすか？
せっかくこの間、狭い横幅で表示するためのスタイルシートを作ったのに、emacsのlispコードを書いたらウインドウ幅からはみ出して、ブラウザーに横スクロールバーが表示されてやんの、しくしく。
いや、preを使う理由はbrによる強制折り返しを書かないで済むというのが一番の理由なんだけど、それで自然な折り返しができなくなるとは、うううっ＜preってそういうもんじゃないの（￣△￣；。
もし、<div><code>ホゲホゲ</code></div>の形でもよさそうなら、あとは面倒な強制折り返しの処理をどうするかだ。偉い人ならきっとPerlを使えと言うだろうと思い、グーグルで調べて回っていたが、「<」や「/」なんかのエスケープの仕方がわからず四苦八苦。そうした苦難の中で拾い集めた数々の資料を参考にし、ヒイヒイいいながら書き上げたのがこのスクリプト。
#!/usr/bin/ruby
while gets
chop!
gsub!(/&/, "&")
gsub!(/</, "<")
gsub!(/>/, ">")
gsub!(/"/, """)
gsub!(/$/, "<br />")
print
print "\n"
en
……それperlちゃうで（￣△￣；＜しょうがないだろー、背に腹は代えられなかったんだから（￣△￣；。
全行末に<br />が付加されてしまう情けないスクリプトではあるが、とにかくこいつを適当な名前でホームディレクトリに保存（おいらはescapeと付けた）。「$ chmod +x escape」でこのスクリプトに実行属性を付加する。
次にソースコードを単体のファイルで用意し（これにはhogehogeと名前を付けた）「./escape hogehoge > hogehoge1」でHTML内で使える形に変換しhogehoge1という名前のファイルとして保存して完了。うぉぉぉ、便利じゃぁー。これならpre使わなくてもいいような気がしてきたが、なにかHTML的にまずいことあるのかなぁ？
ソースコード例示の件について、闇黒日記7月6日分で野嵜さんが私案を提示してくれた。
私案。
<ul>
<li><code>ホゲホゲ</code></li>
</ul>「取敢ずブロック要素はdiv」と云ふ發想は敵。
意外な回答。ならば、「リスト」を選んだ発想の根元というか意義を知りたかったり。というのもHTML 4.01の勧告文には、リストについて次に挙げるような説明文があるから。
HTMLは著者に対して、リスト情報を指定するための幾つかのメカニズムを提供する。どのリストも、1つ以上のリスト要素を含まねばならない。リストには、次の内容が含まれ得る。
- 順不同の情報。
- 序列のある情報。
- 定義。
上のリストに含まれる内容とコードの例示では、釣り合わない気がする。ただしリストにこだわるのであれば、タイトルを用意することで定義リスト（dl）としてマークアップする手が使えるかもしれない。とりあえず「とりあえずdivを避けるためだけのマークアップ」や「（￣△￣；をカモネギにするためのネタ」でないことを祈るのみ ＜「世の中の出来事はすべてネタ」説ですか、あのーさん（￣△￣；。
Life whith MacOS Xの7月6日分「...馬鹿?」にこんなことが書かれていたですよ。
えっと、Xserveですが、まだ届きません(^^; 2CPUモデル注文したので、どうも出荷が遅れてる模様です。
で、1CPUの方ならちらほら届いた人も居るみたいですが。。。はやくも
- 五月蠅い
- でかい
- たわむ
などの評価が上がってるそうで。。。馬鹿か？ 音楽用のフロントしか止めない小さな、コンピュータのことなど考えてないラックとか、机のような平らなところに置いただけで運用している模様でこの評価... もう、悪いけど頭イタイよ。
書きっぷりというか口っぷりは悪いけど、これ、この間おいらがUNIXのサーバーを売ってる某有名パソコンショップで偶然耳にした話で出てきた、マックユーザーに対する評価が、そのまま真実になっちゃった形だね。
「たわむ」ことをマイナスの評価に感じた人、XServeってラックに入れて使用しないと、補償対象外なんじゃなかったっけ？（￣△￣；。熱伝導率を上げるためにアルミとか使ってるんでしょ、おまけにフロントしか止めてないなら、そりゃたわんであたりまえだし、設計思想をまるで理解できていないっつーの。というかもしかして、購入するまで1Uラックマウントサーバーって見たことなかったのでは？＜事前の下調べもなしに、そんな特殊な機械を購入するなよ（￣△￣；。
... ええ、私が今 一番危惧してるのは、そんなエエカゲンな扱いの末、「日本の夏」に耐えきれずダウンさせた上で、「Xserveはすぐ壊れる欠陥品だ」って馬鹿騒ぎしないかという事です。
このサイトの人は、NeXT系の有名なうに屋さん。おいらは、プロなら「魚屋は魚屋の、八百屋は八百屋の立場でものを言う」べきだと思うよ、少なくとも浅い評価で風評を流そうとする勘違いくんに対しては。言い方がきついのは「勘弁してくれ」だけど（￣△￣；。
マックの世界は、きちんとしたマス・メディアがほとんど育っていない。多くの人の情報源がルーマーサイトか個人サイトで、マックの情報全般にわたって無条件で全面的に信頼できるメディアは少ない（なおUNIXのコミュニティではわりと一般的な情報入手手段である、技術系メーリングリストやネットニュースの存在は、考慮に入れていません。ほとんど見てないので）し、いーかげんな情報が流布するのは当然かと。
ジョブズだって、「アップルはこの分野で実績がないから、謙虚な姿勢でいく」といっていたんだから、マカも知らないものに対してはもっと謙虚でいいような気もするんだけど、どう？＞マカのみなさま＜「お前が一番謙虚じゃないだろ」という突っ込みもありです（￣△￣；。
それから、このサイトのオーナーはもっと積極的にメディアに出ていって、「ものの見方のひとつ」としての自分の意見をもっと示した方がよいかな、と思ったりする（少しずつ出始めているようだけど）。そういうのがマカ全体のスキルの底上げにつながるような気がしたり。
野嵜さんの提案に対して投げかけた疑問に、返答が帰ってきた。
上のリストに含まれる内容とコードの例示では、釣り合わない気がする、と言はれても、俺は「釣り合ふ氣がする」んですがー。
以下の二點が問題となるのだらうが、いづれも問題ではない。
- HTMLのソースの類を「リスト情報」にする事
- 「リスト情報」が一つである事
最初の方は、「リスト情報」が具體的に定義されてゐない以上、主觀に基いて決定してよろしい筈。次の方は、W3Cの勸告を見れば、火を見るよりも明らか。
確かにリストの内容については具体的に言及されてないなぁ。おいらの判断がうかつだった。
順不同型リストって、おいらは項目を複数列挙するときに使っている。なのでリストの情報がひとつしかない場合というのは、あとあと項目を追加する時までの暫定的な状態だったりする。そのつもりでいるから、先のコードの例示のように複数列挙の可能性を考えていない事例で使うのに抵抗感が出てくる。でも複数云々を言いだすと、定義型リストを一対だけで使うことが多いことに対して、弁明ができなくなるね。
それから、同じ記事にあった以下の記述に対して、ちと補足。
しかし、divを避ける爲にマーク附けを工夫するのが、そんなにいけない事なんですかね。
いけない事かどうかはわからない。前回の記事は野嵜さんがリストを推薦する意図がよくわからなかったから。おいらは「divを避けるだけの、とりあえずのマークアップ」である可能性が心配だった。でも、意味はきちんと存在したみたいだし。
class="tsukkomi"のem要素をあのー氏がspanではなくemにしてゐるのは、氏の解釋であるが、個人的には納得出來た。codeをdivに單にぶち込むのには、何の解釋も介在しない。
突っ込みの部分は、文章中では異質な存在なのであえてemを使って差異を強調してる。その上で、他のemと区別するのにclass属性が必要だった。
おらいがpreなりdivなりでマークアップしようとしている本来の意図は、「コードをまとめたブロックを作りたい」というものだ。こうする理由は、ブロックという見せ方で見た目のメリハリをつける、プレゼンテーション的な要望から。でも単にdivで括っただけでは、HTMLとしての解釈が足りないとのこと。そこで、望ましいマークアップをするために何を選ぶか、もしもそれがdivになってしまった場合はどういう対処が必要になるかを考えてみた。
code自体はテキスト中のコード部分をマークアップするための要素。プレゼンテーション的な要望を満たすためには、より大きく括れるなんらかの要素を併用する必要が出てくる。
次にHTML的な意味合いから、数ある要素の中から、どれでブロックをマークアップするかの選択を迫られる。とりあえず、思いつくままの候補と、それに対してどう考えたかを列挙する。
用語の部分には、HTML 4.01勧告文の非公式日本語訳「W3C勧告 私的 日本語訳」中の、各要素の説明へのリンクを用意した。適時参考にしてちょ。
上のような理由だと、ddとdivが比較的望ましいように感じた。あとはどう扱いたいかだよね。タイトル付けられるんだったらddがわかりやすいし、それがイヤだってんだったらdivになるけど、その代わりid属性やclass属性でメッセージを付加するのを忘れずにね、ってこと。
ちなみに、outsider reflexのLatest Topics7月6日分「div をなくすよりは、より適切マーク付けを重視します」で、Piroさんがこういう解釈を示している。
ある部分が何らかの理由でひとまとまりのものとして扱われるべきと判断した場合、僕はまず、その部分を匿名ブロックと見なす。そして、その部分がリスト的な性質を持っていると思えば、リストにする。段落的な性質だと思えば、段落にする。もし HTML で定義されたブロック要素の中に適当なものがなければ、 div でマーク付けし、 class か id で補足する。 XHTML なら、内容を的確に表した要素型を自分で定義して勝手に埋め込むというのもアリだ。
なるへそ。何をしたいのかで適時選択していくというのが必要なのかな、と。そのために、「こういった場合どうしてる？」と聞いているわけで。それから、ここで挙げているXHTMLの独自要素の利用を、おいらはしばらくは避けるつもり。せっかく公開されている文書型を使っているメリットを捨てるだけの勇気がないので（￣△￣；。
で、コードを例示する場合のマークアップはどうするよ＞ALL。
まず感想。古いUAを切り捨てざるを得ない一番の原因はスライス画像をposition:absoluteを使って配置してることだと思うんだけど、一枚絵に切り替えるという選択肢はなしですか。w3mで見たら、何も表示されていないように見えて焦った。
とは言っても画像の容量が大きくなってしまう可能性があるか。画像はいわゆる「白バックによる切り抜き」なのでJPEGだったら圧縮の効きが良さそう。だけど、イラストだし背景の透過を使ってるから、そういう選択肢はとりにくそうだしなぁ。
それならロゴと画像、アイキャッチテキストとカウンターを別のファイルに分けて、それぞれを好きな順（早く読み込ませたい順？）に記述。position:absoluteで重ねていった方が、古いUAにも優しいかな……と思った。いずれにせよ、手間と必要性と画像の容量とやる気とご相談していただければ。
とりあえず今使ってる画像かわいいっす。
つーわけで、今日一日「コード例示のマークアップ方法」に関するみなさんの反応を待ってましたが、「ガイシュツ」っぽい話題なのか、それとも例によって相手にされていないのか、なかなか反応がない。その中でfuck a duck!の7月7日分「偶には HTML のことも」で、麻衣さんが素敵なヒントをくれた。
コードを例示する場合のマークアップはどうするよということですが、矢張り普通に考えて
<pre><code> 〜 </code></pre>じゃないですかねえ。はみ出てウザイのは北村さんのように overflow で対処するのがカックイイと思います。いつかパクろう、パクってみせようと思っているのですが CSS を書き直す気合が不足しているのでなかなかできません。はい DQN ポイント + 1 ね俺。
ステキだぁ〜〜！ これならあきらめざるを得なかったpre要素を引き続き利用できそう！
というわけで、紹介された徒書の5月6日分「pre要素とoverflowとMacIE」を読んでみた。ところが、MacIEで「overflow:scroll」を利用すると、要素の中身が消えてしまうとのこと。ふーむ。
ここでは、MacIEでの適用を避けたいセレクタを「@media screen{セレクタ{プロパティ:値;}}」として囲むとあった。だが、これを指定してしまうと、なぜか手元のモジラ（Linux版1.0）でもスタイルが適用されない！
UAのバグっぽいクセを利用する手法はなんか心配なので、別の手段を検討した。で、JavaScriptはどうだろうと考えた。おいらはJavaScriptはまったくわからないのだが、CSSの振り分けをjavaScriptでやる人が多いのだから、いけるだろうと考えた。
で、またしてもヒイヒイ言いながら、MacIE以外でpre要素にoverflowが適用される以下のようなスクリプトを書き上げた。ただしMacIEではまだ未確認（￣△￣；。
//UAごとに処理を振り分けるスクリプト
var ua = navigator.userAgent; //UA名取得
this.MacIE = ua.indexOf("Mac" ,0) //UAがMacIEかどうか
if (this.MacIE == -1){ //MacIEではないと判断した場合
document.write('
<style type="text/css">
div.date div pre.code-sample{overflow:scroll;}</style>
'); //pre要素にoverflow処理をかける
}else{ //MacIEと判断した場合
} //何もしない
プ。これを書いたあとに、他の人のJavaScriptを見たら、全然洗練されてて、上のコードを見せるのが恥ずかしくなってしまった＜恥を忍んでがんばれよ、公開しているのは自分のためだろ（￣△￣；。
詳しくないからよくわからないんだけど、どうやらJavaScriptを多用する人たちは、同じ設定値を使い回すためにどんどん変数に値を代入して、ブラウザーの数が増える中でも記述をすっきりさせるよう配慮している印象を受けた。
現在のおいらは、そこまで複雑なことは必要ないので、これで我慢。どうしたらああいう書き方ができるのかを勉強しながら、徐々に直していこう。
これだけだと、MacIEではoverflow:scrollが適用されていないはずなので、もう一工夫必要そうだ。
ねこめしにっき2001年10月25日分「MacIE5 の overflow:auto/scroll/hidden 」には、「つまり、これを回避しつつ「疑似フレーム」をデザインするならば、必要がなくてもとりあえず div 要素で囲み、それに対して overflow: auto なりを指定しなきゃダメという状態っす。
」と書いてあるので、これが利用できそう。
今考えているのは、徒書6月26日分「見よう見まねJavascript」にある、要素名を書き換えるというJavaScript。これでMacIEで読み込んだときのみ、<pre class="code-sample">というところを<div class="code-sample2"><pre>なんて感じに書き換えらるようにすればいいのではないかと。
あくまでも素人の勘ぐりだし、あちらで挙げているコードサンプルの内容をさっぱり理解できない（￣△￣；。なので、今日の夜にでも再チャレンジ。
「今日の夜にでも再チャレンジ」と言っておいて、何もしてない＜この嘘つきめ（￣△￣；。
北村さんが徒書7月9日分「ソースコードのマークアップ」で、この話題を拾ってくれている。北村さんが言うような「問題提起」というより、おいらが単に困っていただけなんだけど。
で、仕様書を確認したところ、code要素の説明はコンピュータのコード片《
a fragment of computer code》となっていたので、やはりcode要素は通常テキスト中に存在するコードの断片に用いるのが似合うのでは、とも思い直したり。今のところは。
そう、「コード片」。なのでおいらの用途には合ってないんだ、この仕様。合わせようとすると窮屈になるので、より厳密にマークアップする必要があるなら、いずれは自分でDTDを書いて自分に合わせた語彙を用意するか、パブリックな仕様から自分の要求に近いものを探すことになるかもしれない。ただウェブで表示するために、最終的にHTMLの形にしなければならないとしたら……。
あと、北村さんがこの話題に触れた人の記事を集めてリンクしてくれている。どうもです。
PiroさんがLatest Topics 7月8日分で提示してくれたソースコードを外部に置く方法。ああ、そんなことまったく思い付きもしなかった。うまく行くなら、これが多くの人にとって納得できる選択になるかもしれない。その方向で検討してみるかぁ。
それにしても、おいらがやってる<pre class="code-sample"><code>ホゲホゲ</code></pre>というクラスの使い方って、プププ（￣△￣；。CSSで、pre[code]（code要素を子ノードとして含むpre要素）のようなセレクタを使えるとこの冗長さを解消できそうなんだけど、ひょっとしてできたりします？
最後に闇黒日記の7月8日分より。
あのー氏の6日の文章が改竄されてる。
<pre><code>ホゲホゲ</code></pre>
あのヘタレに、こともあろうか改竄疑惑が発覚！ さっそくニュー速板で、野次馬2ちゃんねらーによるお祭りが。助けて〜……＜嘘付け（￣△￣；。
agendaの7月5日分「文書構造と無関係な表題（HTML）」を見ていたら、おいらが「横広いやーん（3）」で使っていたh4要素「各マークアップ候補に対する感想」の使い方が、まさに文書構造とは無関係な表題のような気がした。hn要素だけ抜き出して目次を作ったら、たしかにあれだけ浮いてしまう。どうしたものか、はてはて。
自サイトを1週間近くも放置しておったヘタレでございます。みなさま、いかがお過ごしでしょうか。まあ、忙しいことは幸せだったり。
コード例示の件は各地でまだ話題が続いてるけど、ここで取り上げなかった分も含めて、いろんな解釈や考えを知れて面白かったっす。それに付随する、いろんな情報に触れることができたのも収穫かな。
HTMLのあの仕様は、論文的な構造を表すのに向いているんだけど、そうでない場合はHTMLで記述しにくいこともある。写真にキャプションを付けたり、9日の「独立した表題」で示した例のようなことをしようとすると、拡大解釈をしないと苦しくなってしまうこともある。
で、コード記述の件に反応をくれたサイトを探してるうちに「箱庭」というサイトで、「XML で書く日記」というコンテンツを見つけた。おいらは、独自要素の利用に対してまだ及び腰だけど、遊びで勉強するのには良い手がかりになりそうなので、今度挑戦してみようっと。
訳あって、PCのLinuxシステムを入れ換え。その後、とあるサーバーからモジラの1.0のRPMを落してる途中に、突如回線が切断。再び接続したところモジラ関係のRPMが一切見当たらなくなった。うーん、幻でも見ていたか。
それはそうと、普段HTMLの記述に使っているPSGMLの設定をしようと.emacsファイルを開いたものの、どうやって設定していたか、まるっきり忘れてしまっている。任意に追加するDTDをまとめたCATALOGファイルは古い環境から持ってきているので、.emacsの設定法さえ探せばいい。それであれこれ調べて、設定が完了。忘れないように、ちゃんと書きとめておく。XATALOGファイルとECATファイルが/home/anoh/site-doc/for_psgml\という階層におかれてる前提で設定を記述している。
毎日会っている相手が、さとみかんに捕捉されているあのサイトの人だったことに気がついてから、はや一週間。もういい加減、こちらのサイトを発見できましたでしょうか（リファラ発射しないと無理かなぁ？）
もしかしたら、ほかにもちょくちょく会ってるのに、コミューンの人間と気がついていない相手がいたりして（￣△￣；。
Linux用のメール&コンタクト管理ツールとして「evolution」を試してみることにした。「マイクロソフト アウトルック」のクローン的なインターフェースが売りらしいのだが、実はおいらアウトルックは使ったことがないので、実際そうなのかはよくわからない。マックではずっと「マイクロソフト アントラージュ」を使っていたけど、あれは製品コンセプトから言っても似て非なるものであるわけだし。あ、少なくともRedHat Linuxに付属するバージョンは日本語メールを扱える。
実際に使ってみて、モバイルセレロン333メガヘルツ+KDEではちょっと動作が重い印象を受けたのだけど、この手のソフトを使うとワクワクしてしまう。頭の回転の遅いおいらにとって、この手の管理ツールって実は自分の情况を冷静に把握するために必須だったりして。
ところで、メールだったらIMAPがあれば、どこでもメールを管理できるわけだけど、コンタクト情報やスケジュールを同じようにどこからでも管理できる仕組みがあると最高なんだけどな。その１つの解答はMSNのサービスなんだけど、ほかにもあるといいなぁ。
マックのウェブコミュニティの中心たる「いぬリンク」の運営者「いぬ」が綴る「いぬ日記」を見ていると、結構頻繁にモジラの話題をとりあげていて、こんなことが出来る、あんなことが出来る、といった感じで管理人が楽しそうにモジラとふれあっている様子がよく伝わって来る。
モジラはよくできたソフトで、インターネットをベースにした多才な、云わばemacsのようなソフトウエア実行環境を提供してくれる。モジラをベースにいろんな機能を自分の好きなようにカスタマイズできるのがたまらなく楽しいという人も多いのだろう。
ウィンドウズの世界にはあって、マックの世界にはまだないブラウザーに「Opera」がある。欧米ではマック版が存在するが、2バイト文字を扱えるマック用のOperaはまだない。これもPCから組込み器機にまで幅広くフルセットのHTML対応機能を提供できる柔軟性と、多くの部分をユーザーの手でカスタマイズできる設計が売りのブラウザーだ。HTMLやCSSの対応度合いも、マックで言えばIEやモジラに十分対抗できるレベルにある。
欧米でマック対応版がでている以上、いつかは日本語対応のマック版が登場することになるかもしれない。そのときに、Operaはモジラのように熱狂的なファンを獲得できるのだろうか。ウィンドウズ版で得た評判に恥じないだけのソフトとして登場することになるのだろうか、そしてそれはいかにもマックらしいソフトの姿になるのかどうか。
先のことなのに、つい気になってしまうおいらは、ウィンドウズ上でこのサイトのOperaでのレンダリング度合いを確認したりしてる。一応、オイラ的にはすでに気になるブラウザーになってるってことで。
はやりもの。ねこめしにっき26日分「ワツニュ風娘娘飯店」と、らぶらぶだいあり26日分「人ん家のスタイルシートで表示」で取りあげられていた、他人のスタイルシートを適用するゲートウェイを試してみる。ネタ提供の感謝の意を込めて上記両サイトも試してみる。
この結果を見ると、いろいろ考えさせられてしまう。いや、下の2つのサイトのイメージカラーになっているピンクと、うちのオレンジが似合わないのはともかくとして、段組みや回り込み、displayプロパティによる見せ方の変更といった仕掛けが無効化されたときの中途半端ブリがなんとも（￣△￣；。ページ構造に対する考え方のツメが甘いんだろうな。
あと、もひとつ。日記なんてどこもたいてい似たような構造を採っているだろうに。なのに制作者毎にクラス名の語彙が違うのもナニかと。うちと各サイトとの間だけでなく、例えば「ねこめしにっき」と「らぶらぶだいあり」の間でスタイルシートを交換しても、同じような見た目にはならないし。
知人に「プライベートなこと書かないのですか」と聞かれる。万が一書いてみたところで、きっと特定の知人の監察日記になってしまうのがオチ。「知人Wの今日の昼飯は、主食が焼き肉弁当でおかずに冷やし中華の組み合わせ。さらに……」とか「知人Mは、ウェブ日記では猫をかぶって書いているけど、飲み会のあの様子を見てると……」なんて書いたところで、あまり面白みがないような気がしてしょうがない(身内にはウケるだろうけど。あ、例に挙げた記述に他意はないです)。
つーか、他人様が読んで面白いかどうかなんて気にしてたら日記は書けないね、ハイ。というわけで、先月から「日記」という文字をタイトルから外してる。「グランド・ウェブ! ファンキー ヘタレ・ロード」は、ウェブの話題を中心にしたネタコンテンツでござい。
ねこめしにっき26日分「WYSIWYG なオーサリングツール のつかいかた」より。
… デカい table を作るときだけ使う。
おいらもよく、「ゴーライブはテーブルレイアウトを作るためのツール。テーブル作らないなら、手書きでも十分だよ」なんてことを人前で言ったりする。つーか、もはやテーブルレイアウトと決別して4年近くたっているので、すっかりゴーライブは眠っているんだが。
それはともかく、今までも何度か口にして来たんだけど、おいらは本当は製作効率を上げるために、オーサリングツールを活用したい派だったりする。何がしたいかというと、サイトで使うリソースの管理をして、サイト内外のリンクのデータベースからa要素にURLを埋めこんだり、コンポーネントファイルを用意して同じソースを各ページで共有したり、CSSファイルの編集時にプロパティ名を記述しなくてもスタイルの設定が出来るようになったりしたいわけ。
とは言っても、ページの記述は手書きで進めたいし、その際にエディタがDTDと連動して、使えない要素や属性をシャットアウトしてほしい。つー要望にはドリームウィーバーがいちばん近いってなことは前にも言ったんだけど、あの使い慣れないUIを見ると、とても弄る気にはなれなかったり＜典型的なヘタレ（￣△￣；。第一、オーサリングソフトは、どれもdiv要素のハンドリングが下手だしね。
プライベートな話はないと言いつつ、たまにはしてみる。巡回コースにラブラブをうたってるサイトがいくつかあるんだけど、そのわりにその手の話題をほとんどしてないトコロがいくつかあるので、それに遠からず近からずな話題を。
それはそれは、10年近く昔の話。いろいろ事情がからんだ禁断の××の最中、あまりに相手が色っぽいので、ツキナミだけど「やっぱり昼は天使、夜は娼婦ってなとこ?」と聞いてみた。ちょっと困った表情をしたあと相手が返して来た言葉は「夜も天使だぃ」。あー、それもいいかも。
そりゃラブラブではなくて、エロな話題じゃないか? と書き終った時点で思ったり（￣△￣；。