月が変わると、普段更新をさぼりがちなサイトをさとみかんがさらし者にしてくれる。
はるか後ろに飛ばされちまったじい。すぐに更新しますので許してください、ドクロベェさま。
2ちゃんねるにて「祭りｷﾎﾞﾝﾇ」を口にしておきながら、「闇黒日記デー」には完全に出遅れ。あいかわらずのﾍﾀﾚっぷりを満天下に晒しめているあのー（￣△￣；でございます。みなさま、お元気でしょうか。あははははは。
「萌え混じり技術系を目指すサイト」という看板を掲げる「ツキニイチドノハツジョウキ」のレイアウトがMacIEで大幅に崩れる件。ようやく管理人さん側でも確認できた模様。
それにしても、「標準」規格というのの存在意義は、手間やコストの軽減の実現を狙って組まれることが多いわけで、CSSの存在で我々は楽ができるようにならないと「CSSはパフォーマンスが悪い」と言わざるを得なくなるわけだ。いくら個々のUAでスタイルシートの実装度合いが違うからって、スタイルシートを一個一個作っているのは手間がかかって仕方がないように思えてしょうがない。
CSSに詳しい人に聞きたいのですが、とりあえず標準のスタイルシートを用意しておいて、個々のUAごとに実装のバグへの対処法を記したスタイルシートでその内容を上書きするといったことはできないのでしょうか。
Linuxマシンの環境構築は着々と進行中。 先日のモジラ1.0 RC3の導入はTARボールを伸張する形でかんたんにすませたものの、これではRPMで管理しているこのマシンのシステムとの整合性が悪い。RPMというシステムがあるということは、最新版がでたときは自分でRPMを作って管理するか、そうでなければおとなしくRPM版が配布されるのを待てということなのだろう。
RPMの作り方についてはまったく見当がつかないので、本を探したがいまのところ見つからず。そうそう紀伊国屋に足を運べるほど時間があるわけではないので、また今度。とりあえず、LnxZipというアーカイバで作成可能という情報だけはGet。あとで詳細を調べてみよう。
そうこうしているうちにmozilla.orgに1.0正式版に対応したRPMファイルがアップされた。何を落としていいのかよくわからなかったが、いくつか落とした段階でrpmコマンドを走らせるとあれを入れろ、これをいれろとうるさいので、*-devel-*.rpmな名前のものは無視。ナローバンド環境なのできついけど、本体とmail、nspr、nss、psmの5本をダウンロードして組み込むことにした。
あとあと参考にできるように手順を書き残す（同じくらいのレベルでとまどって、Google使って必死に参考になるページを探している人もいるかもしれないし）。
とは言っても、それほど難しくない。モジラやノーチラス、ガレオンといったモジラのパーツを使っているソフトを終了する（念のため）。 rpmをおいたディレクトリに移動したらターミナルを起動して、suまたはsudoを使って、ルート権限でrpm -Uhv moz*.rpmを実行。たぶん作業は30秒くらいで終了するはず。
rootのままターミナルにmozillaを入力してモジラを起動。/usr/bin/に入っているからパスを通し直す必要はないみたい。rootのままモジラを起動するのは、なにかのファイルを作らないといけないらしい。どうせなので、そのまま日本語パックをインストール。これで終了。
昼間、Mac OS X＋ATSUI環境によるフォントスムージングが効いた状態でモジラを使ってたから、こちらの環境でスムージングが効いていないのが気にかかる。けど、スムージングを効かす方法がわからないので、どしようもなかったり。APIの固定で、モジラ用のツールが活気づいてきたようで、テーマがいろいろでている。一応、KDEテーマを入れて、それらしくしてみた。
生のLinuxならではの活用ができる日はまだ先だろうけど、まぁボチボチ頑張るですよ。実はKDE 3.0も落としているんだよなぁ……。
ひぃひぃ言いながら、やっとLinuxマシンへのKDE 3.0の組み込みが完了。いくつかモジュールをつっこんだ段階では不安定で仕方なかったのだが、いろいろ調整しているうちに調子がよくなってひと安心。初心者でもなんとかなるもんだな。
rpmは最小限の単位ずつアップデートオプション（rpm -U hoge.rpm）を使って組み込んでいくのが一番混乱がなさそう、というのが今回の感想。それでも山のようなファイルを落としては入れ、を繰り返していたので今後KDEがアップデートしたときのことを考えると鬱（￣△￣；。
それはそうと、おいらがLinuxと取っ組み合っている間に、いわゆる某方面（旧CSSコミュニティとその周辺）の様相に変化があったみたい。ここ2日間茶々入れる暇がなかった2ちゃんねるの某スレを見ると、かつての野嵜さんの手によってひと括りにされたグループという意味合いから、勉強していく意志のある人たちがお互いに影響を与えあうコミュニティという意味合いに某方面を再定義するらしい。前者が烏合の衆なら後者は意志を持つ集団と考えもいいのだろうか？
こういった目の前で展開される新しい動きを見て、おいらのコンテンツが何を目的にしているのかをもう一度きちんと示さないとな、と考えたわけだ。で、とりあえず採った手段がコンテンツ名の変更。「グランド・ウェブ！ ファンキー ヘタレ・ロード」なんてパクリ臭い匂いがプンプン漂う名前だが、偉大なるウェブの世界をネタにするために日々格闘するおいらのヘタレっぷりを、ネタとして見せつけるコンテンツとしてはまあ適当な題名かなぁと。
リンク集の内容も少し入れ替えた。CSSが有効になっている環境ならページ左側に見える「じろじろ監視中」のとこがそう。これからいろいろやっていく上で、興味を感じているサイトを挙げている。
そんなわけで、おいらのコンテンツに興味を持ってくれている方々。これからもよろしくです。
それは、「らぶらぶだいあり」なる桃色デザインのサイトの6月8日付の日記「Operaのフルスクリーンモード」に書かれていた記述。
実は、OperaのF11キーを押してフルスクリーンにすると、プロジェクタとして振る舞うらしいです。なので、media指定にprojectionがないとフルスクリーン時に読み込んでくれないというのは仕様な気がします。
ああ、ついにメディア属性なるものが目の前に現れたか。こうして、かつては「未来の話」なんて思っていたことが、実例を伴って現れるたびに時代が変わっていくことを痛感する。それはともかく、次はXLinkあたりをよろしくお願いします。難解なプロセッサーを組み込んでようやく実現できる技術より、ブラウザーでぱっと試せる方がやっていて楽しいからね（それはXSLTでも同じか）。
ときに、更新情報の提供だとか、さっき挙げたXLinkのような柔軟性と効率性の高いウェブづくりを目的にして、個人のウェブ制作者がXML扱う時代がじきにやって来るかもしれない。だが、ウェブブラウザーというのが事実上HTMLの表示ソフトになっている現状を考えると、道のりは遠いかもね。
XML文書をウェブページとして扱うにはどこかでHTMLに変換するプロセスがどうしても必要になる。サーバー側で変換する機構を組み込んであるのならともかく、ローカルで変換してからサーバーにアップするという手段しか使えないようだと、膨大なページ数を抱えている場合は、共通パーツを変更するたびに吐き出し直しが必要と、えらくパフォーマンスが悪い（サーバーで変換する場合は、パーツの共有化は便利なんだけど）。おいらは一時期この方法を試していたが、すっかり嫌になってしまったのだ＜ご愁傷さま。
柔軟性の高い文書形式をウェブで使いたければ、XMLネイティブ対応のブラウザー・カモンと唱えるべきなのだろうか？＜どんなソフトじゃ（￣△￣；。
>>1さん、もとい、よういちさんの「長い助走日記」の6月10日分「なんとも耐え難いこと」から。
某方面の方たちはどうやってCSSとかの学習をしているのだろうか。
現在AAAリーグ所属のおいらの例でいいかい？ ありみかさんとPiroさんのCSSソースをパクるところから始めましたが、何か？＜どこに生かされとんねん（￣△￣；。
本当のことを言えば、HTMLとCSSに関してはかつてZSPCが提供していた、ウェブ制作ラウンジが勉強の舞台だった。ここで過去ログを漁りながらいろんなことを覚えていった。貴重なログがたくさんあったから質問したいと思ったことは、たいてい聞かなくとも用が済んだんだ。
だから当時はほとんどROM状態。野嵜さんのアレゲなあれも端で見てるだけだったし。情報を追い剥ぎのように持っていくいくだけで、なにもお返しができなかったことは、今でも申し訳ないことをしたと思ってる。
今だったら2ちゃんのゴミのような膨大なソースを頭の中でインデックス化して、必要なときに引っぱり出している感じ。そしてお礼に膨大なコピペを＜おい（￣△￣；。
ただ、2ちゃんで捜し物というのは非常に効率が悪いので、「あれどうなっているんだろう」という場合に先に挙げたサイトを見に行って、自分の予想が合っているかどうかを確認する次第。
それはそうと新某方面が本格的に動き出すなら、かつてのZSPCのようなオープンなラウンジが欲しいなぁ。いくつか後継となったサイトはある。だけど、それらのサイトに対しては非常に申し訳ないんだけど、どことなくこじんまりしてしまった感が否めないんだ。それだけである意味、敷居の高さを感じてしまう。
ちなみにおいらは、ウェブをネタにした話はできれど、新某方面の中核メンツと違い、なにか人の役に立つ成果物（たとえばまとまったドキュメントやツール類）を残しているわけではない。だけど、まぁなにか人に理解のきっかけを提供するくらいのことならできそう。詳しい人の説明をもっとわかりやすく、その人にあったかたちに説明し直すとかね。コミューンも大きくなったことだし、公認のラウンジがあれば、おいらみたいな人も巻き込んだ形で互助が動き出すように思われ。
つーか、そういうところからまたネタが拾えたりして、非常に(ﾟдﾟ)ｳﾏｰなんだけど、どうよ？＜結局追い剥ぎか（￣△￣；
すっかり死語になってしまった「CSSコミュニティ」について評価をする「CSSコミュニティの功罪を評価するスレ 4th Reich」だが、ここにはおいらのパクリがいっぱいだ。
せっかくなので、代表選手を紹介しよう
みんなはどのフェイクが好きかな？ 「漏れもすごいフェイク作ったるでぇ」という人はどしどし光臨されたし。ただし、スレの住人に迷惑をかけない範囲でね。
「イタイのは、てめーのサイトでやれ」と言われたあのー（￣△￣；です。こんばんわ。
……と泣きながらかどうかは内緒ですが、スゴスゴ帰ってきたヘタレちゃんでございます。みなさまお元気でしょうか。
えーっと、今日は「ツキニイチドノハツジョウキ」の6月15日分「昨今のWEB事情」から逝ってみようか。え、亀レスするなと？ すんません、あのあと忙しくなっちゃってウェブ見てる時間を取れなかったんだ、とほほほほ。
アクセシビリティだってユーザービリティだって、全ての人に優しいサイトなんて今の状況じゃできないし、全てを全ての人が納得するように表現もできない。
とりあえず、前後の文脈無視。単純に「ユーザービリティ」と「全ての人に優しいサイトなんて今の状況じゃできないし」の2つのタームに関してのつっこみです、よろしくたのんましゅう＞はるのさん。
全ての人に優しいとは聞こえはいいのだけど、おいらこれが具体的にどういう姿なのかが全然想像できない。想像できないものは目指しようがない。というわけで、おいらは今のところ「すべての人に」という条件をユーザービリティには要求していないというわけ。
でも、ユーザービリティは常に気にした方がいい。というのも、自分のサイトを訪れる人に満足して欲しいというのがある。そこで何を持って満足して欲しいかというと、やはり自分のコンテンツそのものから満足して欲しいのだ。そのためには、おいらの見せたいコンテンツに見に来てくれる人たちを確実に誘導しなくてはならない。おいらはそのための手段として「ユーザービリティ」があると考えている。つまり誰にでもわかりやすい方法で、おいらと見に来る人たちがハッピーになるためにユーザービリティが存在するのだ。
逆に考えれば、その程度のユーザービリティも用意できていないサイトというのは多い。例えば、おいらだってこのサイトを始めたときに、ありみかさとみさんに「最新更新分がページの最後に追加される作りなのに、そこへすぐにたどり着けないのはどーゆーことですか！ヽ(`Д´)ﾉ」＜かなり脚色入っています――と注意されたものだ。
これがプロなら、例えば物販サイトでは売り込みたい商品の情報がすぐに得られるように、そして購入までの道筋が手短に示されるようにナビゲーションやレイアウトを設計するだろう。そういう気遣いがあるだけでサイトを開いた目的（ここでは物を売る）を阻害する要素が排除されるわけだ。ユーザービリティーの最初の一歩はそういったところにあるわけで、別に肩肘を張る必要なんて全くないのだ。だから、おいらもまずはそういったところからユーザービリティを高めていこうと、頑張っている。
具体的に何をやってるかって？ えーっとページ頭の「最新更新分」に、本日分に飛ぶためのリンクと、その概要を書き込む程度なんだけど……、だめ？
さとみかんに補足されているサイトのいくつかで、最近千葉県ネタが目立つんですが、なぜ今頃声高に……。※声高につーのは大げさだった。でも、さとみかん補足サイト千葉県人多いなーと思った次第。
2ちゃんのモナー板で、新キャラ誕生。「一郎さん」を意識するあまり自分も>>1さんになってしまった「シンイチさん」。定着するのかなぁ？
野嵜さんが有馬あきこさんをやり玉に挙げていた。話はそれの件とはまったく関係ないのだが、彼女はウェブデザイナーにしてはめずらしく、コスプレ写真を公開している点でぶっ飛んでいる。
いぬリンク系のアンテナサイト「ねずみかん」に補足されたもよう。ここのところ何もマックの話題をしていないんだけど、それでもいいのだろうか……＜ほかに登録されているサイトを一覧して、まぁいいかという気にもなった。
今度はアクセシビリティの話。「ねこめしにっき」の6月13日分「WaSP再開」が元ネタ。米国のアクセシビリティに関する法律についての話を取り上げて、ありみかさんは「日本にはこういつ法律は…無いな、きっと」と言っていた。
おいら、これに対していくつか聞きかじった話を連絡したのだが、あちらがディスククラッシュで対応できない模様。こっちで紹介してくれと話を振られたのでアップする次第。それにしても、二日もそのお願いを見逃してたなんて、申し訳ない（￣△￣；。
WAIをベースにしたアクセシビリティに関する取り決めというのが、どうやらISOでも議題にあがっているようなのだが、なんかこれに関してはあまり情報がない。ただ、おそらくWAIが公共の規格になることによって、日本にもいくらか影響が出てくるのではないかとは思う。
どんな程度の影響かというのは、IBMのサイトの「バリアフリーの扉」にあった「法と障害者」というコンテンツにヒントが書かれている（用字は元コンテンツをそのまま引用）。ちなみに、これはGoogleのキャッシュ。バリアフリーの扉のリニューアルで、元のコンテンツはどっかいっちまっただよ（￣△￣；。
これによると、日本ではどうやら緩やかなルールとしてアクセシビリティが普及していくような形になると予想している。もしも、これがきちんと実施されれば、公共のウェブの制作はISO標準やWAIに準拠できる業者が優先されるようになる、と考えてもいいのかもしれない。そうなれば、日本のウェブの未来も少しは明るくなりそうだね。
ちなみに、この文書の中には「欧州連合（EU）、国際標準化機構（ISO）等の国際機関、米国国家規格協会（ANSI）等の民間グループによって、技術のアクセシビリティを進めるための標準化努力が続けられています。
」という記述も見えるけど、これが今回の話の状況証拠くらいにはなるかな。
アクセシビリティを確保する基本的な手段の一つとして「画像にalt属性を用意し、代替となるテキストを記述する」というのがある。alt属性はHTML 4.01で必須の属性に指定されているし、ウェブコンテンツ・アクセシビリティ・ガイドラインでも、テキスト以外の要素に同等の役割を果たすテキストをつけることは最優先の項目となっている。
ただし言葉で表現しきれないから、そのほかのメディアの表現力の助けを借りる場合、同等の役割を果たすテキストを用意しようとすると難しくなってしまう。
でもよーく考えてみよう。なんのために、代替テキストが必要なのか。文字以外の手段を採った場合、それが視覚障碍者やグラフィカルな表現を行わないUAに、どのような内容のリソースが用意されているかを伝える必要があるからじゃないのかな。
むろん極端な話、例えばFlashのコンテンツは視覚障碍者をターゲットにはしていないが、そういった人が代替テキストを見てコンテンツに興味を持ち、隣にいる非障碍者にそのFlash内容を見て欲しいとお願いすることはあるかもしれない。また、旧型携帯電話の9600bpsでモバイルしている人は、いつもは画像オフのところを、その説明を見てちょっと見てみるかという気になるかもしれない。
つまり、当たり前のように画像が表示される環境にいない人にも、適切に情報を伝える意味で代替テキストが必要、と考えることもできる訳だ。となれば、その内容は簡潔に内容を示せるものであることが望ましい。長い説明には、別の属性が用意されている。
画像の内容が文字であれば、その文字をそのまま書けばいい。マルチメディアコンテンツの場合は、題名とメディア形式を例えば「日本おにぎり化計画（Flash形式）」とでもしておけば、「自分が見せたいもの」を理解してもらうには十分だと思うのだけどどうだろう。
画像のalt要素に限って言えば、内田明さんのHTML 4.01の私的日本語訳の画像の包括：IMG要素の項に「alt属性は、画像についての短い説明を提供する。 その内容は、ユーザにとって、 longdesc属性が指定する長文説明――この例では『sitemap.html』――へのリンクを辿るかどうかを判断するのに十分な内容である必要がある。
」とあるが、その内容にも十分合致しそうだ。
何か「これを取り上げないとなー」とぼんやり思っていて、忘れてたことを思い出した。
あれは外出が続いていて、外出先からあれこれ2ちゃんねるに書き込みをしてたころ。ちょうど話題がXMLの方に流れたのだが、そのとき、そのスレッドを見ていたひろりんさんが閑古鳥の6月13日分に「なにがなんだか〜」と書いていたんだ。そう、それでXMLがどういう使い方をされているのか、ウェブ向けでは一番わかりやすいXSLTをベースに紹介しようかと思ったわけだ＜つーか、お前それしか知らないだろ（￣△￣；。
XSLTはXML用のスタイルシートの一種。こいつはXHTMLやSVGなどと同様、XMLの文法に則って記述されるマークアップ言語だ。スタイルシートといっても、マークアップの構造をざっくり変えてしまう働きがある点が特色。こいつがなんでスタイルシートなのか。
HTMLとは互換性のないタグを使ってマークアップしたXML文書を、IEなんかに読み込ませると、妙なツリー構造で表示されることがある。これはIEにとって、それがXMLであることはわかるものの、そこで使われている要素や属性の扱い方をサポートしていない場合だ。IEはそれ以上どう処理していいかわからず、XML用に用意されたデフォルトのスタイルシートを使ってとりあえず整形してしまう。
このXML文書がなんらかのソフト用に用意されたものであれば、その専用ソフトで開けばいいわけだが、「ウェブブラウザーで見られた方が手っ取り早くていい」と考える人もいる。そこでブラウザー向けに、文書を独自に整形する必要が出てくる。
ブラウザー標準のスタイルシートではなく、独自の整形をXMLに対して行うために、2種類のスタイルシートがよく使われている。
1つ目はCSS、使い方はHTMLと同じで、ある要素に対するスタイルを記述するだけ。ただ、この方法をサポートしているブラウザーは少なくて、モジラとかくらいしか知らない。もう1つはXSLTを使ってHTMLの構造に書き換えてしまう方法で整形を実現する。
なんで「書き換え」がスタイルシート？という感じもしなくもないが、ウェブブラウザーがよ〜く知っているおなじみの書式にしてしまうので、デフォルトのスタイルシートが使える。その意味でスタイルシート扱いされているのかもしれない。実際、テーブルなどを併用した物理マークアップに書き出してレイアウト、というサンプルは多数見かけるし。まー、本来のXSLTはXSL-FOというレイアウト言語でマークアップするための中間ファイルを作る仕組みなんだけど。
だけど、いったん変換した結果に独自のCSSを適用するのも問題ない。なんらかのソフトでXMLファイルからHTMLファイルを書き出すことが多いんだが、IEの場合は変換結果をファイルに書き出さず、レンダリングして表示する。だからXSLT中に、変換後のファイルが外部CSSを参照するように記述しておけば、変換後の文書をCSSでレイアウトできる。
XSLTは変換にどう関わるのかというと、特定のリソースをHTMLの（もしくは変換先のDTDで定義されている）どの要素でマークアップするのかを記述（これもマークアップ）するために使われる。「特定のリソース」とは、「XPath」という方法を使って指定した、XML文書中の任意の要素内容（属性や属性値なども含む）のこと。
例えば、下のXML文書の「半角空白の連続は無視されますよ。」がこれに当たるとして、これをHTMLでマークアップした文書に変換したい場合を取り上げる。
<moe-word class="quote">半角空白の連続は無視されますよ。</moe>
こいつをXSLTのスタイルシートでこんなHTMLに変換したい。
<blockquote><p>半角空白の連続は無視されますよ。</p></blockquote>
こんな風にするのは、例えば次のようなマークアップをXSLT書類に記述する。
<xsl:template match="moe-word[@class='quote']">
<html:blockquote><html:p><xsl:value-of select="." /></html:p></html:blockquote>
</xsl:template>
なにをしてるかというと、最初の行でquoteという値を持つclass属性があるmoe-word要素（こいつはおいらが勝手に作った）の内容を、blockquote要素中のp要素でマークアップするという指定なのだ。
なんでここまで変換対象になる要素の内容を細かく指定するかというと、quoteという値で特定した要素を他のmoe-word要素と区別したいから。これがXPathの役割。
XPathではほかに、特定の要素の後ろ何個目にある要素とか、そういう指定もできる。……というか、元のXML文書にある程度リッチなマークアップがされていれば、細かく指定ができる可能性が高くなるってわけ。あくまで必然性がある範囲でリッチにしておくといいのかもしれない。
一方、元のXML文書がプアなマークアップの場合は、少々知恵を絞るか、元のXMLを書き換える必要が出てくるかもしれない＜「Pure is Poor」は音楽の世界での格言だが……（￣△￣；。
XSLTの役割は割と単純。XPathで指定した要素の内容をvalue-ofという要素（これはXSLTのDTDで定義されている）で代替し、それに対しhtmlの要素をマークアップさせてる。実際はあれこれ工夫をする必要があるんだけど、大まかに説明するとこんな変換の指定作業の繰り返し。むろんXHTMLからXHTMLへの変換もOK。
これだけだとあんまり魅力的ではないんだけど、条件を決めて変換内容を割り振ったり、特定の属性値や要素内容をキーワードにして変換時に同時にソートをかけるなんてこともできる。年表なんかを適当な順番で書き込んでいっても、年代順に並べ替えるのはちょちょいのちょい。あとからあとから情報が追加されるような手順を踏まざるを得ない場合、HTMLでテーブルを逐一書いていくよりも作業は楽だったりする。
XMLの利用例はこんな感じで、XSLTを併用することで上に上げたようなことができるんだけど、必要に迫られないと使い道が見えかなったりするのが難点。
そういう意味では、ソリューションというか、こういうときはHTMLの手書きよりXML＋XSLTという具体例を、どんどん先人が示してくれると普及が進みそうなんだけど……＜人に頼らず、自分でやれってか（￣△￣；。
XSLTに関して簡単な説明を書いたわけだけど、公開から約24時間で得たユニークアクセス数が約160。その中の1つは「XSLTって面白そう
」という反応をした本人なんだろうけど、あとの159は無反応。ROMって怖い＜おまえもROMしてるサイトいっぱいあるくせに。
つーか、おいらが意図したことは本当にあの説明で合っているのか？ 密かに突っ込みを期待していたのだが、皆の琴線に触れるためのタイミングを逃したかも。もっと早く書けばよかった……。
つーわけで、自己批判ではないがフォローを。えーっと、「元の文書にある程度リッチなマークアップがされていれば」から「『Pure is Poor』は音楽の世界での格言だが……（￣△￣；」までの件は余計だったかもしれない。
少なくともこれを書いている時点で、「レナ姫のWeb研究室」の6月16日分にある「私のサイトで div を殆ど使わない理由」や「見出し構造とツリー構造の『明示』について」で取り上げられているような観点は考慮していない。まだ、おいらの意識がそこまで到達していないからだ。少なくとも、おいらの説明だけを鵜呑みにすると、XSLTに対するものの見方が偏る可能性があることだけは注意しておく。
そしておいらは、この時期にあれこれ語られた話と自分の経験との整合性をとるために、落としどころを探す必要がある。じゃないと、おいらの知識が腐ってく。これについては、また機会があったら。
家人に作ってもらった。最初はロゴに使ってる画像を流用すればいいかと考えていたが、なんか一捻り欲しくて、お絵かきサイトを運営している家人にお願いした次第。タブレット使いのわりに、まっすぐな線を引けないが故に現れるヘタレ具合が妙にいい感じ。これで「あの顔文字ムカツク」と宣う人の増加は必死。さぁて、どこに飾ろうかなぁ♪
かなり適当に無茶な要望を並べてみるテスト。
この間、飲んでいた席で出た話題。知り合いがBzのコンサート見に行くと言ったのがきっかけ。
おいら的には「人気の秘密は、稲葉の変態っぷりにある」という説を強く押しておいたが、まぁ、B'zのエンタテインメント性の高さはあなどれないということだ。
もうちとまじめな話、松本孝弘のギターはレッドツェッペリンの影響を強く受けているような気がするんだけど、どうだろう？ 音的にもレスポールをマーシャルで歪ませました的なねばっこい感じがするし、リフ中心のギターワークもそれっぽい感じがする(本家ほど運指はヨレてはいないが） 。稲葉のボーカルも、甘ったるい声で情けない歌詞を歌うだけでなく、シャウトやスキャットでたくましい声を聞かせてくれる。七色とまではいかないが、聴いている人間を飽きさせない程度の声色は持っている＜普段プログレを聴いていると、こういった部分が気になるようになる、うーん（￣△￣；。
遙か昔に見たB'zは、TM Networkを手本にしつつもう少しソリッドなリズム感のある音楽を目指している印象を受けたが、いつの間にか方向性が変わってる。彼らの音楽を聴いていた世代が大人になり、ロック的教養が高まったのに合わせて、それに見合う音楽を提供するようになった……ということだろうか。「パクリだらけのJ-POPなんて聴いてられないよ」と言い始める世代に「あ、おいしくパクってるじゃん」と思わせることができたら、彼らの戦略は成功ということか。商業音楽なんだから、聴いてて楽しいなら、ファンもアーティストもそれでいいじゃん。
本日早朝の更新で、ウェブオーサリングソフトへのお願いを並べたんだが、あれ半分くらいはネタ気取りで挙げたもんなんだよなぁ。だから、とうてい実現不可能な要望も入っているわけで。
オーサリングソフトのネタをたくさん取り上げているFUMINGさんが、本日付けの「Mac用Webオーサリングツール」と題した項目でおいらの記述を拾ってくれてるけど、いくつか意見してくれているのでそれへの返答。
まず、ゴーライブとドリームウィーバー以外のMac用の市販オーサリングソフトなんだけど、英国ソフトプレス社の「フリーウェイ」を残して全滅。このフリーウェイはコールドフュージョンと同様、内部に独自データとして文字やリンク情報、レイアウトを保存し、最後にサイト全体をHTMLに吐き出す仕組みを持っていた。
このソフトはDTPデザイナーをターゲットにしていたんだが、もはや単純な「DTP感覚」というのが市場から要望されない時代になってしまったのか、メジャーにはなれず。日本国内ではすでに販売が終了している。
こういったソフトに対する（特に海外の）コンテンツ製作会社の視点は、「DTP感覚で扱えるか」ではなく、「WebとDTPのコンテンツ制作の両立を効率よくこなせるか」といった点に移ってしまっているのかもしれないね。アドビたんの提示するソリューションはそれをよく受け止めていると思うし＜この提案に既存の紙メディアは対応不可能だと思う（￣△￣；。けど、Webメディアが紙メディアに参入する際には役立ちそう。
それからIBMのソフトなんだけど、冷静に考えるとIBMだからマックに冷淡なのではなくて、こういったソフトの市場がマックにはない、と判断しているのかもしれない。ホームページビルダーのメインターゲットは初心者だけど、初心者にはすでにiToolsがあるし、中級者向けにはゴーライブがあるわけで。逆にウェブソフィアのような開発ツールは、NTやW2Kのほうが扱えるユーザーが多いのかもしれないし。
IBMはビアボイスというマック向けのソフトを投入している実績があるし、マックに無関心ではないはず。ホームページビルダーしかり、ホームページリーダーしかり、マックユーザーがIBMのやろうとしているビジネスに無関心なだけ、と考えることもできるんだが。
ちなみに、マックの市場でウェブオーサリングソフトというと「ビジュアルインターフェースを使ってウェブページをレイアウト、それにサイト管理機能が統合されたツール」しかないんだけど、サイト管理機能や文法チェッカー、タグ類を無視してテキストの検索置換（正規表現込み）ができる仕組み、スタイルシートの管理やHTML構造のツリー表示――といった便利なサイト管理機能を備え、ページの記述はコードエディターで行う（むろんリンクの挿入などはサイト管理機能と連携するべき）オーサリングツールがマジで欲しい。
そういった意味では、ドリームウィーバーが一番おいらの要望に近い存在だが、以前の更新で触れた部分が不満。第一、おいらのウェブコンテンツにとっては予算もスペックもオーバーすぎ。かと言って、モジラのコンポーザーは、そういった用途には向いてないし。
WinMSIE 6やモジラのような最新ブラウザーと、2年以上も前(仕様が決まったのは3年前)のブラウザーのレンダリング能力を比較して喜ぶ莫迦。こんな素敵なナードたちに支えられる日本のITの未来は明るい＜皮肉だよ（￣△￣；。
それはともかく、完全なマルチスレッド、プラグインからのDOMコントロール、シャーロックとの統合、MSXML4対応、CSS2のフルサポート、コンテクストメニューにユーザーによる機能追加を可能に――とかいうような、マニアが浮かれまくるスペックでも備えて早く出してくれ。出さぬと調布の町中に「オペラマンセー」のチラシを貼りまくって、プレッシャーかけまくるぞ＜迷惑行為です（￣△￣；。
なぜ調布かはググルで調べておくれ。
なんつーか、人間、目の前にあるパソコンしか動かさなくなるんだよな、不思議と。両刀遣いなんて人たちの感覚がおいらには信じられない（真似できない）。
んなわけで、最近はノートPCに組み込んだLinuxでほぼ全ての用事をこなしてて、家人のiMacに作ったおいらのアカウントは、メールのチェックと、ため込んだエロ画像の閲覧に使うくらい＜十分に役立っているじゃん（￣△￣；。
そんなわけで大活躍のノートPCなんだけど、どうやらこいつにサウンドカード代わりに組み込まれているNM2200というチップ、そのままじゃLinuxから認識されないんだぁぁぁぁぁぁ……（￣△￣；。これじゃ、今まで1年間iTunesで作成してため込んだMP3をまったく聞けない
/etc/modules.confに強制ロードオプションを書き加えるとか、sndconfigをやり直すとか、すぐにできる手はいろいろやってみたが効果なし。ディストリビューションに付属してきたOSSドライバーはあきらめて、ALSAドライバーをコンパイルして組み込もうとしたら「カーネルのソースをよこせ」と言われるし……（手元にないんだよなぁ）、もう散々。さて、次の一手は……。
昔、Mac OS Xを初めて触ったUNIXユーザーが「こんなに簡単にMP3の環境が手に入るのか」と感激したという話を聞いたとき、「んなアホな。UNIXだってMP3環境作るのは、そんなに難しくはないだろう」と思ったものだけど、うーむ。
つーか、22日の「XSLTを名前くらいしか知らない人のためのXSLTの基礎知識」と24日の「あのー（￣△￣；のXSLTの説明に欠陥あり」に関連した話題で、いーものを見つけた。agendaの本日分「カレントノードの強制変更（XSLT）」で、XSLTでの処理中に特定の要素（ノード）の名前を置き換える試みをしてるよ。
この例で一番問題にしているのはhnというレベルごとに名称の異なる見出し要素の扱いについて。こういうのを見てると、XSLTではこういうこともできるのかぁと、なんかワクワクしない？（この置き換えが何に役に立つのかが、あいかわらずぱっとは浮かばない厨房です、おいらは）。
閑古鳥6月28日分XSLTのぎもーんより、見せしめ。うしししし＜性格暗いね、というか……さぶっ（￣△￣；。
XSLT の中にある、 xsl:output 要素の omit-xml-declaration 属性で "no" を指定しても xml宣言が出てこないのは何故。
いや、XMLとして出力するんだろうという予想は正解。だって立派なXML文書だもん。
で、引用文であれこれ言っていたところだけど、omit-xml-declaration属性でXML宣言の生成を指示しても、その内容を指示していない予感。同じxsl:output要素の中に「method」「version」「encoding」の3つの属性を入れてあげると吉かも。「不思議マークアップ」を作成したくなければ、「doctype-system」と「doctype-public」属性も忘れずに。
さぁヒントはやったぞ、属性値の内容に何が入るかくらいは調べろ調べろ、おらおら＜お前もそこで3日くらい足止めくらってだらろうに、偉そうやなぁ（￣△￣；。
取り急ぎの更新のみ公開。本日分はまだまだ続く。
なんだかんだで、ひろりんさん徹夜でがんばったらしい。すげー＜って、おいらは徹夜でマシンの設定を……ねむ（￣△￣；。
XSLTで文書形式を変換するときに、XSLT用のプロセッサのほかにもひとつ、XMLパーサーが動いているはず（じゃないと、XMLとして処理ができない）。これって、何を使ってるんだろう？
おいらのばやい、この分野にあれこれ手を出しているジャストシステムのサイトの解説に従ってXerces-JというJavaで動くXMLパーサーを使ってる。どうせXTがJavaで動いているんだから、この辺そろえちゃっても問題ないかな……と。Mac OS Xならシェルスクリプト書いてしまえば、以後困らなかったし。
ノートPCで音が出ないまま悪戦苦闘は続く。NM2200というサウンドチップを認識するためのドライバーは確かにシステム内に存在するのだが、どういうわけだか読み込まれない。またKDEの起動時にDSPなどのモジュールをシステムが開けないというなんだか素人にはよくわからないアラートが表示される状況。
とりあえず、あれこれいじり倒すのに必要なツールを導入しやすくするために、ノートPCにつっこむLinuxシステムをVineProject製のディストリビューションに変更。apt-getを使ってネット上から設定ユーティリティやサウンドシステムなどを手際よく導入するまでは思惑通りだったのだが、ドライバーを読み込めない状況は相変わらず。
こりゃ、カーネルがサウンドのドライバーを読み込まないようになってるのかもしれない。カーネル再構築の手順を説明したサイトのあたりをそろそろつけておかないと。元々ハックでうきうきするタイプの人間ではないので、ちとヘビーすぎて疲れた。
おまけに、システムを入れ替えてしまったものだから、環境を元に戻すのに一苦労。Vineでは元々サポートしていないATOKの導入やKDEのダウンロードでむちゃくちゃ時間を取られ、Navi2chでrpm作成の練習をしてみたり、まったく多忙な一日。
こんな感じで土曜を丸一日潰してしまった（寝るのを忘れた！）が、収穫がなかったわけではない。Googleと一日お付き合いしていると、いろんなサイトが引っかかる。悔し紛れに、Linux関連で収穫かな？と思えるサイトを3つほど。
MN2200関連では、2年前の4月からLinuxなどについて調べた全メモをmh（いわゆるプレーンメール）形式にして保存・公開している人がいた。このmh形式をemacsで取り扱うためのプログラムも公開してる。これをサイトにアップして、Namazを使って検索する、というわけなんだな（はたから見るとメーリングリストのログにしか見えないが）。
個々のメモのサイズは小さいとはいえ、かなり膨大な量の資料なので、見つけたときは宝の山に出会った気分だった。
それから、KDEとGNOME関連で見つけた「SelfishGene.org」という最新情報紹介サイト。最新情報を紹介している「Documents」というコンテンツは、細かなところまで立ち入ったヘビーなものじゃなくて、流れがわかる感じのライトな感じ。マックの世界でいう「お宝」みたいなものか？（そこまで手広くはない）。
まあ、そこまではよかったんだけど、トップページにアクセスすると、どれが本題のコンテンツなのかわからない（フレームの使い方とナビゲーションに気を使ってないせい）。そのため、うっかり適当にクリックするとすぐに別のサイトに飛ばされてしまう罠が仕掛けてある。
おまけに最初は検索エンジンからフレーム内の1ページに飛んできてしまったため、どこにどう移動していいのかわからずに立ち往生してしまった。まあおいしい情報を得るためだ。仕方がない。
もうひとつ。イラストレーターだとかWebアプリ制作とか、本業はいったいなんじゃ？という感じの人のページ「star*sugar*star」。LinuxとBSDの日記って感じだけど、現在のおいらでも決して理解できなくはなさそうレベルの話題を扱っているので、隅まで読んで、おいらの脳内ポインターとさせていただきます。
それにしても字の小さなサイトだなぁ。試しに普段ウェブを見ているときのサイズ（14〜16pt程度）まで拡大させたら、テキストがレイアウト上の仮想テキストボックスからはみ出した＜ううっ格好悪い、早く対策を〜（￣△￣；。ウェブはサブノートで見てはいかんか……＜12.1インチで1024×768ドットの液晶で小さい文字は確かにきついよなぁ（￣△￣；。
しかし、なんか何かの機会で見たことのあるサイトのような気がするのは、気のせいか？
Vineに移行したら、モジラがファイルを読み込み終わるまで死ぬほど動作が重くなって、「フリーズか!?」とあせりまくってる今日この頃でやんす。
それはともかく、昨日見つけた「star*sugar*star」に早くもおいらが書いた件への返答が載ってたのを発見。いくらリファラが付くとはいえ、昼過ぎには載っていたから、見つけるの早すぎ……（￣△￣；。今日最初の話題は、夕べおいらが書いた文字サイズに対して6月30日分に掲載された返答から。
ここのサイトの字ちいさいですよね。でも好きなんです。字がちいさいのが。「ううっ格好悪い」と思われた箇所ありましたら見てるブラウザの種類とか教えてくださいませ。対策考えますです。
字の小さいのが好きなら、サイズを変える必要はないかも。えーっとおいらのほうだけど、Linux上でモジラ1.0が最近の環境。おそらくフォントデザインの問題なんだろうけど、この環境では文字が8〜9ポイント前後で表示されてしまう。100パーセントの状態でのキャプチャーを見てくだされ。これってマックで見たときに、Osaka、細明朝、ヒラギノとフォントを変えることで、行の高さや文字詰めの感じが変わってしまうのと一緒かな。
こういう事態に対処するために、多くのブラウザーに文字サイズを一時的に変更する機能があって、おいらはそれを使って文字サイズを120〜150パーセントほど大きくしてみた。120パーセントで表示した状態のキャプチャーにあるように、テキストボックスが文字の大きさに合わせて横方向ににびろ〜ん。せっかく区切り線と背景画像を合わせてあるのに、これじゃ格好わるいなぁーと。
字の小さいのはデザイン的な要求が大きいと思うんだけど、フォントのデザインとか画面の大きさとか、そういう人によって異なる不可抗力的な要素があるから、字のサイズを変えても崩れないようにしてもらえるとありがたいかなぁと。文字サイズを変えても読めないようになるわけではないから、単なるデザイン上の詰めの問題として。
それから、おいらは情報を参照するときに発信元にスキルがある・ないは特に気にしない。だって、立場が違えば目の付け所は変わるわけで、スキルのある人がおいらが悩んでいる観点で何かを調べて、その記録を残しているとは限らないわけで。