2006-08 アーカイブ

Safari 2.0 では外部 CSS にて content プロパティの値にマルチバイト文字列を直接指定しても大丈夫なのだろうか

今回の記事は、 Safari と content プロパティ (2) のように疑問を呟くことで、複数の方から検証をしていただいて疑問を解決できたことに味を占めて、また疑問を呟いて検証してもらおうという浅ましい記事です、注意。

以前、 Safari と content プロパティにて、外部 CSS 内で content プロパティの値にエスケープを行わないマルチバイト文字列を指定した場合に、 Safari 1.0 では文字化けが起こると書きました。 そこで hxxk.jp の CSS では、 content プロパティの値には数値文字参照用変換スクリプトを使ってエスケープしたものを指定するようにしていますが、これって Safari 2.0 でも受け継がれているバグなのでしょうか ?

外部 CSS の content プロパティにて、エスケープを行った値と行っていない値を指定した場合の比較用サンプルを用意してみましたので、 Safari 2.0 環境がある方は是非開いていただき、「化けたよ」「化けなかったよ」程度の書き捨てコメントでも良いので、この記事に検証結果を届けていただけると助かります。

……という記事を昨晩書いていたら、マシンが突然再起動を行ってくれたのでそのままフテ寝していたところ、今朝 Lucky bag::blog の e-luck さんが調べて下さると仰ってくれました。 が、せっかく書いた記事を使わないのも勿体無いのと、 e-luck さんのコメントやトラックバックの受け皿としての場所が必要だろうということで、こうして記事を残しておきます。 もちろん、 e-luck さんに限らず Safari 2.0 環境がある方のご協力はありがたく頂戴いたしますのでどうかひとつ。

CSS の記述ルール

いまだに私自身「これだ ! 」という答えを見出していないのですが、 CSS の記述ルールって絶対的な正解ってありませんよね ? ちょっと私が知っている範囲で明文化されている CSS の記述ルールを集めてみましたので、それを元に絶対的な正解のルールではなく、最大公約数的なルールを模索してみたいと思います。

ちなみに、今回模索するのは Lucky bag::blog: CSS を作成する際のお約束やデフォルトスタイルの差異を無くすCSS のような Tips ではなくて、あくまで .css ファイルを書き上げる際のルールのことです。 それと、取り上げた記事は順不同です。 書き上げてから、公開日時順にした方が良かったかなあとも思いましたがもうこのままで公開。

1. Type selectors を XHTML Abstract Modules の順番に沿って記述 - hxxk.jp
2. ガイドラインを作成および公開・共有し、ルールの統一 - 2xup
3. セットフォーマットを厳密に定義して可読性を高める - orz.cc
4. CSS2 Specification の記述順を元にプロパティの記述順を決定 - pur*log
5. W3C の CSS の記述順を元にプロパティの記述順を決定 - LIPPiN
6. HTML の階層構造に合わせて CSS の記述もインデントする - Lucky bag::blog
7. .css ファイルの先頭にルールを明確に記述しておく - Code-404
8. CSS の自分ルール - nulog
9. その他関連しそうなリソース
10. 模索結果

Type selectors を XHTML Abstract Modules の順番に沿って記述 - hxxk.jp

まず、私が採用している手法。 CSS のセレクタ ( この場合は class や id を付加しない Type selectors のことを指すことにします ) を書く順番というのは、特に決まったルールはありません。 ( 本当はもう少し細かいのですが ) 後から書かれた方がより優先されるため、最初に html や body などの大まかなセレクタを書いて、後からあまり使わないような部分を書いて……という方法を採っていました。 しかし、それだと後から CSS をメンテナンスする時に「あれ、あのセレクタはどこに書いていたっけ ? 」ということが起こります。 そこで、何か記述順のルールというか指標が無いかなあと思って採り入れたのが、 XHTML Abstract Modules の順番に沿ってセレクタを記述していく方法です。

hxxk005.css を見ていただければ分かりますが、 Structure Module から始まって Legacy Module ( 実際には使っていませんが ) で終わるように記述しています。

3ping.org のうーたんも 真琴さんのCSSをこっそり覗き見してモノマネして くれているらしく、 デフォルトスタイルの差異を無くすCSS で紹介されている default.css でも同じ方法を採用しているようです。 更にこの CSS では先頭にモジュールの簡易目次を書いているので、いずれこれを逆輸入しようかな。

ガイドラインを作成および公開・共有し、ルールの統一 - 2xup

スタイルシートを書く時のガイドライン - 2xup にて、セットフォーマット ( インデントをどうするか、スペースをいくつ空けるかなど ) やプロパティの順序をどのように決めているかを公開しています。

このファイルは共有するので、独自にカスタマイズしてオリジナルのガイドラインをつくるサンプルとしてご利用ください。 もっと良い考えがあるかもしれないし、ミスや理解不足もあるかもしれないのでそういったご指摘も歓迎です。 そしてそれを元に何かフィードバックなどをいただければ、それはステキですね ということで、今後の充実が期待されます。 また、スタイルシートを書く時のガイドライン - 2xup へのトラックバックや更にそのリンク先から、次のような CSS ルールに関する記事を辿ることができます。

• CSSガイドライン メモ編 (Jamz Design)
  • [16] CSS コーディングガイドライン
• Blog|hamashun.com - 外部CSSを記述する際のガイドライン

セットフォーマットを厳密に定義して可読性を高める - orz.cc

CSS の閲覧用整形ガイドライン < Black Box という記事があったのですが、現在見られません。 いつかまた見られるようになることを期待してメモ。

CSS2 Specification の記述順を元にプロパティの記述順を決定 - pur*log

CSSで見やすくメンテナンスしやすいコードを記述するための自己流ルール - pur*log では、 CSS2 Specification ( 実際は邦訳版の方を参考にしているようですが ) に書かれている 解説を順番に読んでみて、視覚系ブラウザに必要なプロパティかつ、現状普及している主要ブラウザで解釈できるプロパティをざっと順番に抜き出して プロパティの記述順を決定しているようです。

W3C の CSS の記述順を元にプロパティの記述順を決定 - LIPPiN

LIPPiN - プロパティの書き順@脳内ルールでは、 W3C の CSS の記述を参考にし、また mozilla.org Base Styles の記述も参考にしてプロパティの記述順を決定しているようです。

HTML の階層構造に合わせて CSS の記述もインデントする - Lucky bag::blog

Lucky bag::blog: CSS の可読性を高めるためのアイデアでは、 HTML ブロックレベルの階層に合わせてセレクタをインデントして書くという方法が紹介されています。

.css ファイルの先頭にルールを明確に記述しておく - Code-404

これは実際の .css ファイルに書いてあって「おおー ! 」と思ったものです。 Code-404 の square.css からインポートされている dont-forget-the-rules.css という CSS には、 ルールを忘れるな という直球タイトルのルールが記述されています。 その内容を見てみると

1. プロパティの出現順序
2. セレクタの記述
3. プロパティと値の記述
4. 値の記述
5. コメントの記述
6. 特殊なルール
7. 全スタイルのリセット

といったルールが羅列されています。 また、 square.css の方の先頭部分にはカラースキームやセレクタの目次も書かれていますので、合わせて参考にすると良いでしょう。

CSS の自分ルール - nulog

CSS で面倒くさいのは < 13 < July < 2006 < nulog, NULL::something : out of the headphone に、記述ルールと実際に記述された CSS が公開されています。

その他関連しそうなリソース

記述ルールからは少し逸れますが、関連しそうなリソースを挙げておきます。

• Lucky bag::blog: 疑似要素の表記法
• Lucky bag::blog: 維持しやすい CSS を考える
• Lucky bag::blog: カラー関連の情報を CSS 内に記述
  • CSS の色指定に関するメモと、 JIS 慣用色の一覧表
  • JIS 慣用色の色名と CSS での数値指定との対応表

……なんだか Lucky bag::blog ばかりですね。 辛うじて hxxk.jp の派生記事が入っていますが。

模索結果

最大公約数的なルールを模索した後に、 hxxk.jp の CSS をリファクタリングして実例としてみようと思いましたが、まとめてみたら意外と多くなったので、それはまた別の記事に機会を譲ろうかと思います。

大分間が空きましたけれど

txqz への先読みと質問を書いていて、 Safari は attr(X) に未対応 ? に対してスクリーンショットの提供を受けていたのに、それを記事にしていないことに気付きました。

回答までもらっているのに、サイト上では疑問を投げっぱなしという状態はいかんだろうということで、今回はそのフォローです。

Safari は attr(X) に対応しています

まず、 Safari は attr(X) に未対応 ? を書いた数日後にいただいたメールから。 メールを下さった方は Mac OS10.3.8 & Safari 1.25 という環境だそうです。

を見ると、確かに「スタイルシートサンプルブック 280 ページ より引用」と表示されています。

次に、メッセンジャーでお話をしていた時に、その方が Safari をお持ちだということで「じゃあスクリーンショット撮って撮って ! 」とお願いしたログから。 OS のバージョンは聞きませんでしたが、 Safari のバージョンは 2.0 だそうです。

の方も、確かに「スタイルシートサンプルブック 280 ページ より引用」と表示されています。

お二方とこれらのやりとり ( そういえば双方ともに、スクリーンショットは使って良いですよという許可はいただきましたが、名前を出して良いかどうかを尋ね忘れていました ) をしたのが既に数ヶ月前の話ですので、最新バージョンの Safari ではないかもしれませんが、現在も対応していると見て良いのではないでしょうか。

Safari は content プロパティで追加された内容はどう扱うのだろう

txqz への先読みと質問やいわゆる「闇黒式引用」で再び話題になった content プロパティで追加された内容をコピー ( というかマウスでのドラッグ ) ができるかどうかの問題ですが、これって Safari はどうなっているんでしょう ?

私は Mac 環境が無いので実験できませんが、どなたか Safari をお持ちで「しょうがねえちょっと手伝ってやっか」という方がおられましたら、仕様書に明記されていますのような、 hxxk.jp 内で引用部分のあるページを開いて引用部分の「～より引用」や「引用元 URI: 」がマウスでドラッグできるかを試していただけると助かります。

Re: はてなブックマーク - AAぶろぐ_仏苦魔悪 - 最新のものしかブックマークしてはいけないの?

これ...引用元のURIがコピペできないのはどういうわけなのか（そーす開いて探したぞ）あと対象のリンクぐらい入れて欲しい というコメントを見る限り、 Firefox を使っているのでしょうか ? txqz の CSS を完全に解析したわけではないので正確ではないかもしれませんが、 :before 擬似要素 / :after 擬似要素の活用例 - blockquote 要素で引用元の明示のような手法で書き出しているのでしょう。 IE 6.0 で最新のものしかブックマークしてはいけないの? を見ると、引用元のタイトルや URI は書き出されませんし。 ( その代わり、引用部分にマウスをホバーさせるとあれこれポップアップによる、引用元のタイトルと引用元へのリンクアンカーがブラウザ上に表示されます。 )

で、 ::before/::after 擬似要素などにおいて content プロパティで内容を追加した場合、 Opera ではその内容をコピーすることが可能です。 これは cite 属性を使う場合やついでに content プロパティ関連の各ブラウザの実装の簡易まとめで触れました。 それと SeaMonkey ( 旧称 : Mozilla Application Suite ) では cite 属性の URI を「引用部分を補助クリック」→「 Properties 」で表示することができます。 また、以前 Safari は attr(X) に未対応 ? と書きましたが、読者の方から最近の Safari の場合は attr(X) の表示に対応していますというメールをスクリーンショット付きでいただきましたので、もしかしたらコピーできるようになっているかもしれません。 ( 表示できることは確認しましたが、コピーできるかどうかまでは確認していません。 )

ということで、 Opera や SeaMonkey では URI をコピーできますし、 IE では ( txqz に限って言えば ) あれこれポップアップでリンクアンカーのクリックができるように配慮されています。 また Firefox でも cite 属性からリンクアンカーを手軽に生成という方法でリンクアンカーを生成することができますので、はてなブックマーク - AAぶろぐ_仏苦魔悪の高橋雅奇さんがどんな環境なのかは分かりませんが、最近のグラフィカルブラウザをお使いなら問題は無いんじゃないかなあと思いました。

ちなみに、 hxxk.jp の場合はあれこれポップアップは導入していませんが、引用を行った場合は「 Re: ほげほげ」といった見出しを付けて引用元へのリンクを行ったり、あるいは本文中に自然な形でリンクアンカーが登場するような文章を書くようにしたりするという自分ルールを設けています。 blockquote 要素や q 要素の外に引用元へのリンクアンカーを配置しても、それは引用部分との明確な結び付きがあるとは限りませんし、かといって blockquote 要素や q 要素の中にリンクアンカーを配置するのは、引用元のテキストに無いものを勝手に引用者が加えることになります。 そこで、私の場合は cite 属性によって引用部分と引用元の明確な結び付きを示しつつ、明確な結び付きは無いかもしれないけれども a 要素によるリンクも置いておきますねということにしています。 あれ、 txqz の話のつもりが何故か hxxk.jp の身の上話に !

これこそコメント欄に書いた方が良いんじゃないかなあと思う

最近ははてなブックマークのコメント欄の使い方について言うことも少なくなりましたが、やはり記事作成者本人に伝えるべきことはその記事のコメント欄などに書いた方が良いと思いました。 はてなブックマーク - AAぶろぐ_仏苦魔悪 - 最新のものしかブックマークしてはいけないの? で 対象のリンクぐらい入れて欲しい と言うのなら、最新のものしかブックマークしてはいけないの? のページにはコメント欄があるのだから、はっきりと言えば良いじゃないですか ? という。

ちょうど本日付けで、はてなブックマーク - AAぶろぐ_仏苦魔悪 - Discommunicative - Effective はてなブックマーク：ブクマのコメント欄は相手へコメントするためについているわけではないことを理解しようにて そもそも相手に伝えたいことばかりとは限らない というコメントを残していますが、相手に伝えるべきものまではてなブックマークのコメントに留めているのはどうかなあ、と思いました。

まあ、最新のものしかブックマークしてはいけないの? のコメント欄に「表示されている引用元の URI がコピペできないのですが何故でしょう ? ブラウザは○○を使っています。それとできればリンクアンカーも添えて欲しいです」と書いても、 txqz の陽坂智佐真さん ( またの名を id:denken) はきっと前項の私の解説と同じような回答を出すとは思いますが。

それと、この際だから txqz にも質問

これは今回気付いたのではなくて以前から疑問に思っていたのですが、ちょうど良い機会なので便乗して質問をしてみます。

txqz の記事中の引用部分にマウスをホバーさせると、 "「" attr(title) "」からの引用です。" の部分が、 「」からの引用です と、 attr(title) が無かったことにされてしまっているのですが、何故でしょう ? n101.css や subdefault.css や default.css の ::hover 擬似クラスや content プロパティ周りの指定をざっと眺めてみましたが、目立つようなおかしな記述はありませんでした。 (.whisper:after の content プロパティの後に ; が抜けているくらい )

を置いておきますので、お暇な時に調べていただけると助かります。 ( 陽坂智佐真さんは私よりも早くに CSS を使っていましたし、実は私が知らないだけのバグなどがあるのかもしれません。 )

ちなみに、スクリーンショットは Firefox 1.5.0.6 で取得しましたが、 Opera 9.01 でも SeaMonkey 1.0 でも同様の現象が再現されました。 ( IE 6.0 はそもそも ::before/::after 擬似要素に未対応なので再現しようにもできません。 )

トラックバック送信先

最新のものしかブックマークしてはいけないの?

http://b.hatena.ne.jp/TakahashiMasaki/20060814#bookmark-2506445 という質問と要望が来ていますが、たぶんこんな感じの回答をされるんじゃないかなあという先読みと、あと txqz の CSS では、マウスホバーと同時に attr(title) が消し去られてしまうのは何で何で ? という質問。

大事なことを書き忘れていました

昨日書いた Firefox とマルチバイト文字列を含む URI という記事ですが、肝心なことを書いていないのでした。

例えば hxxk.jp 内のタグ "ビール" が設定された記事のように、 URI にマルチバイト文字列を含むリソースへのリンクを指し示したい場合、 hxxk.jp 内では <a href="http://hxxk.jp/tag/ビール">hoge</a> と記述してもリンク元もリンク先も UTF-8 であるので Firefox では無事に該当リソースに到達できます と書いていますが、そもそもマルチバイト文字列が URI に含まれるような場合、直接記述するのではなく UTF-8 エンコードあるいはエスケープを行う必要があります。

仕様書に明記されています

Basic HTML data types - 6.4 URIs に URI についての定義が書かれていますが、 Please consult the appendix for information about non-ASCII characters in URI attribute values. と、非 ASCII 文字列を URI の属性値に含める場合は Non-ASCII characters in URI attribute values を参照するように示されています。

Non-ASCII characters in URI attribute values では、

Although URIs do not contain non-ASCII values (see [URI], section 2.1) authors sometimes specify them in attribute values expecting URIs (i.e., defined with %URI; in the DTD). For instance, the following href value is illegal:

<A href="http://foo.org/Håkon">...</A>

We recommend that user agents adopt the following convention for handling non-ASCII characters in such cases:

1. Represent each character in UTF-8 (see [RFC2279]) as one or more bytes.
2. Escape these bytes with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value).

This procedure results in a syntactically legal URI (as defined in [RFC1738], section 2.2 or [RFC2141], section 2) that is independent of the character encoding to which the HTML document carrying the URI may have been transcoded.

と、非 ASCII 文字列をそのまま記述することは不正であると強調して示されています。 ちなみに、 Note. The same conversion based on UTF-8 should be applied to values of the name attribute for the A element. のように、 UTF-8 によるエンコードは a 要素における name 属性も同様であると示されています。

よって、もし Firefox とマルチバイト文字列を含む URI を読んで、「同じ文字コードのリソース間のリンクであれば、 URI に日本語を直接含めてもちゃんとリンクできるんだ」という理解をされた方がもしいらっしゃれば、文字コードが同じであろうがリソースに到達できようが、その URI は不正であるのだということを理解していただきますようお願いします。

b:id:FTTH:20060814 経由

最近、ようやくはてなブックマークのお気に入り機能を利用しての情報収集を始めたところですが、それによって記事を書く、ということはまだありませんでした。 そこで今回は b:id:FTTH:20060814 経由で OpenCage: Firefox urlエンコード機能をUTF-8化する方法。を紹介。

この方法を行うとどうなるのかを簡単に説明すると、例えば hxxk.jp 内のタグ "ビール" が設定された記事のように、 URI にマルチバイト文字列を含むリソースへのリンクを指し示したい場合、 hxxk.jp 内では <a href="http://hxxk.jp/tag/ビール">hoge</a> と記述してもリンク元もリンク先も UTF-8 であるので Firefox では無事に該当リソースに到達できますが、同じようなリンクを Shift_JIS のリソースに記述すると http://hxxk.jp/tag/%83r%81%5B%83%8B という URI としてエンコードされてしまい、該当リソースに到達することができません。 なお、文字コードが同じであれば該当リソースに到達することができますが、そもそも仕様上非 ASCII 文字列を URI に直接記述することはしてはいけません。

そこで、私が hxxk.jp 内でタグページへのリンクを記述する場合は <a href="http://hxxk.jp/tag/%E3%83%93%E3%83%BC%E3%83%AB">hoge</a> のようにあらかじめ UTF-8 でエンコードした状態で記述しています。 このようなリンクであれば仕様の面でも問題ありませんし、 Shift_JIS のリソースや EUC-JP のリソースに記述しても問題なく該当リソースに到達することができます。 ( よって、他の方がタグ "ビール" が設定された記事を参照したい場合も、 UTF-8 エンコード済の URI をコピーすることで問題なくリンクすることができます。 )

さて、ここで Firefox のアドレスバーに、 URI を直接入力してリソースを取得することを考えてみましょう。 現バージョンである Firefox 1.5.0.6 では、デフォルトでは network.standard-url.encode-utf8 の値は false になっていますので、アドレスバーにマルチバイト文字列を含む URI を入力すると Shift_JIS でエンコードされます。 すなわち、 http://hxxk.jp/tag/ビール とアドレスバーに入力しても http://hxxk.jp/tag/%83r%81%5B%83%8B という URI をリクエストした形になってしまいます。 そこで OpenCage: Firefox urlエンコード機能をUTF-8化する方法。を参考に network.standard-url.encode-utf8 の値を true にすると、 http://hxxk.jp/tag/ビール とアドレスバーに入力すると http://hxxk.jp/tag/%E3%83%93%E3%83%BC%E3%83%AB という URI をリクエストした形になり、無事に該当リソースに到達することができます。

network.standard-url.encode-utf8 の値が true の場合の hxxk.jp 閲覧時の tips

http://hxxk.jp/tag/hoge という URI をアドレスバーに入力することで、 hxxk.jp 内で特定のタグが設定された記事を探すことができます。 これはタグ名がアルファベットであれば network.standard-url.encode-utf8 の値に関係なく探すことができますが、 network.standard-url.encode-utf8 の値が true であれば日本語のタグ名でも同様に探すことができます。 ( 逆に言うと、 network.standard-url.encode-utf8 の 値が false であれば日本語のタグをアドレスバー入力で探すことはできません。 )

実は http://hxxk.jp/search/hoge という URI をアドレスバーに入力することでも、検索フォームから全文検索を行ったのと同じ結果が得られるように設定しています。 これも同じく network.standard-url.encode-utf8 の値が true であるという前提になりますが、日本語のキーワードでの全文検索を Firefox のアドレスバーから行うことが可能です。 頻繁に使うことは無いかもしれませんが、 hxxk.jp ジャンキーな貴方 ( きっといない ) は覚えておくと良いでしょう。

あと今思い付きましたが、はてなブックマークの文字コードも UTF-8 なので、 network.standard-url.encode-utf8 の値が true であれば http://b.hatena.ne.jp/t/hoge/ という入力で、はてなブックマーク上の日本語なグローバルタグが設定された記事群を得ることもできます。

関係あるような無いような話

数日前から VOX に招待していただいて、試しに使っているところです。 ちなみに英語版の方なので、日本語版の招待状が届き次第また色々と試してみるつもりでここ数日は全く触っていないのですが。

Busy as a cat burying shit - wu’s blog を見てみてビックリ、 http://wu.vox.com/library/post/トリプルブッキング.html という URI になっています。 Vox 内のソースでは UTF-8 エンコードはされているのでリンクを行う際のアドレスのコピーなどはそう問題はありませんが、マルチバイト文字列なファイル名でサーバに put されるっていうのは、私個人としてはあまり好きじゃないなあと思いました。 ( http://hxxk.jp/tag/hoge や http://hxxk.jp/search/hoge の場合は、サーバに静的に put するのではなく、リクエストがあるごとに動的に結果を返しているのです。 ) それならまだ日本語は dirify されてしまいますが、 Movable Type 3.x のように MTEntryBasename を用いた URI にしてくれた方が良いと思います。

それと MTEntryBasename で気付きましたが、 wonderful - wu’s blog の方はタイトルとファイル名 (wonderful.html) が一致しているのに、 Busy as a cat burying shit - wu’s blog の方はタイトルとファイル名 ( トリプルブッキング.html) が一致していないんですよね。 もしかして、最初は「トリプルブッキング」というタイトルにしていたけれど、そうしたら「トリプルブッキング.html 」という日本語ファイル名になっちゃったので、 "Busy as a cat burying shit" というタイトルに変更してみたにも関わらず、ファイル名は最初に決定した「トリプルブッキング.html 」で固定されてしまったという流れでしょうか ?

ドメインの有効期限を更新しましたよ

hxxk.jp のドメインの有効期限が迫ってきていたので、 1 年分の有効期限の延長を行いました。 これで突発的な事態 ( 私自身の身に何かが起こるとか、 weblog に割ける時間が無くなるとか ) が無い限り、 hxxk.jp は無事 3 回生ライフに突入できそうです。 何故 3 年生ではなく 3 回生と表現するのかは 1 年前の記事を参照のこと。

それと 2 周年記念祭りのようなイベントはしません。 pp 祭りとかもしません。

有効期限の更新手順を簡単にメモ

購入可能金額がいくら残っているかを事前に確認しておいた方が良いのですが、その手順は割愛。

1. VALUE DOMAIN:バリュードメイン - ご入金方法：クレジットカード編の手順に従い、必要な額を入金。
2. VALUE DOMAIN:バリュードメイン - 有効期限確認/更新・延長 ( 要ログイン ) から有効期限の延長操作を実施。
3. 併せて VALUE DOMAIN:バリュードメイン - サーバーアカウントの登録・管理・購入 ( 要ログイン ) から、 XREA+(PLUS) サービス利用権も 12 ヶ月分購入。

XREA+(PLUS) サービスというのは以前「有料広告免除サービス」と呼ばれていたサービスで、 2005 年 12 月 19 日にサービスの名称が変更になりました。 このサービスも併せて更新しておかないと、使用できるサーバスペースが 1000MB から約 50MB まで激減してしまいますので、忘れないようにしておかないといけません。

以上、また来年の夏の私に向けてのメモ。

無難に国内盤をセレクト

[PR] Score: 20th Anniversary World Tour Live Octavarium Orchestra で気合を入れて紹介した DREAM THEATER の新アイテムですが、 PC の方の DVD ドライブのリージョンがどうなっているか分からなかったので、無難に国内盤の方をポチっと買いました。 ドライブの箱はあったんですけど、その中に説明書が入っていなかったんですよねえ。 どこになおしたんだろう過去の私。 昨日はすごく眠かったので思い至りませんでしたが、きっと説明書関連をまとめている棚の上の箱の中でしょう。 うん、やっぱり。

そして何気なく文章中に使ってしまいましたが、この場合の「なおす」は片付けるの意味です。 方言キーワード - なおすでは 主に関西地方で使用？ とありますが、おそらく西日本ではたいてい通じるんじゃないでしょうか。 追記しておきますね。

積み CD たち

Amazon で国内盤を予約して買うと 25%Off で買えるので、価格差としてはそう大きくありません ( それでも 1,500 円近くは違いますが…… ) 。 あとは発売日が 1 週間ほど違うという点さえ我慢できれば。

どうせ 8 月末から 9 月頭は仕事で忙しいことが分かっているからいーもん、と自分を慰める予定ですが、現時点ですら購入だけして開封していないものがいくつか。

ミホミホマコト

ミホミホマコトを買い忘れていましたで取り上げたのに、まだ開封していません。 既に購入して配送され、 Amazon のパッケージまで開けたのになあ。

踊る赤ちゃん人間

これは Amazon ではなく CD ショップで買ったもの。

有心論

これも踊る赤ちゃん人間と同時に CD ショップで買ったもの。

ベスト・オブ・ゴー!ゴー!

これも CD ショップで買ったもの。 アルバムは持っていたのですが、シングルのカップリングなどを未聴だったのと、ボーナス CD が付いてくるということで購入。 これは帰りの道中で少し聴きました。

山羊王のテーマ

これはまだ注文しただけで、現物は届いていません。 通常4~6週間以内に発送します。 ということですが、これは在庫切れとほぼ同じような状態だと伝え聞いたので、キャンセルして CD ショップで買おうかなあ。 川本真琴大好きとか言っておきながら、これもリリース後に情報を得るという出足の遅さ。

FORGET ME NOT/GO A HEAD

これも現物はまだで、かつリリース後に情報を得たもの。 最近こういうリリース情報のアンテナがかなり低くなっているなあ。

学生時代は、 CD の発売日ともなれば放課後にすぐさま CD ショップに行っていました。 雨が降ればカッパを着て自転車をこいで行き、また台風が近付いて下校時刻が繰り上れば営業時間を短縮してもうすぐ閉店という店内に滑り込んでまで購入するくらい、発売日が待ち遠しかったものです。 そして帰りの電車で早速聴いていたものでした。

10 年前の私が、今の私を見たら何と思うのでしょう。 インターネットでポチッとするだけで CD が購入できて、自宅に配送までしてくれる。 そういうシステムに慣れたためか、こうして発売日の感動というものも希薄になってしまっている私を。

とか言いながら、こうして積み CD を晒す記事を書いているあたりに最も失望するかもしれませんね、と自嘲気味に締め。

DREAM THEATER の New DVD & CD

情報としては以前から知っていたのですが、発売日などをすっかり忘れていたら、 Amazon からおすすめメールが届いて思い出しました。 忘れっぽい私にはこういうメールがありがたいなあ。

ということで、 DREAM THEATER の新しい DVD と CD が発売されます。 といっても新作のスタジオ作品ではなくライブテイク作品であるのですが、結成 20 周年記念ワールドツアーのグランドフィナーレ、 2006 年 4 月 1 日に Radio City Music Hall で行われたライブを収録 ( かつ DVD の方はドキュメンタリーを収録したボーナスディスクも付属 ) したもので、後半はフルオーケストラとの共演によるものとなっており、単なるライブテイク作品とは一線を画すものになっています。

ちなみに輸入盤と国内盤では発売日や価格が違いますので、そのどちらを購入するかを迷い中。 我が家の DVD プレーヤはリージョン 1 のディスクも再生できたと思いますが、 PC の方のドライブはどうだったかなあ……。

DVD 盤

	輸入盤	国内盤
商品名	Score: 20th Anniversary World Tour Live Octavarium Orchestra	スコア~フル・オーケストラ・ライヴ 2006
発売日	2006 年 8 月 29 日	2006 年 9 月 6 日
価格	3,020 円	5,900 円 (Amazon の 25%Off 期間中は 4,425 円 )
ディスク枚数	2
リージョン	1	2
収録内容	Disc 1 The Root Of All Evil [Set 1] I Walk Beside You [Set 1] Another Won [Set 1] Afterlife [Set 1] Under A Glass Moon [Set 1] Innocence Faded [Set 1] Raise The Knife [Set 1] The Spirit Carries On [Set 1] Six Degrees Of Inner Turbulence: [Set 2] I. Overture [Set 2] II. About To Crash [Set 2] III. War Inside My Head [Set 2] IV. The Test That Stumped Them All [Set 2] V. Goodnight Kiss [Set 2] VI. Solitary Shell [Set 2] VII. About To Crash (Reprise) [Set 2] VIII. Losing Time/Grand Finale [Set 2] Vacant [Set 2] The Answer Lies Within [Set 2] Sacrificed Sons [Set 2] Octavarium: [Set 2] Intro [Set 2] I. Someone Like Him [Set 2] II. Medicate Me [Set 2] III. Full Circle [Set 2] IV. Intervals [Set 2] V. Razor's Edge [Set 2] Encore: Metropolis [Set 2] Disc 2 20周年記念ドキュメンタリー Octavarium Animation Bonus Live Another Day (Tokyo 1993) The Great Debate (Bucharest 2002) Honor Thy Father (Chicago 2005)

DREAM THEATER に限ったことではありませんが、輸入盤の方が早く発売され、価格も安くなっています。 リージョン 1 の DVD を再生できる環境であれば、輸入盤を購入した方が良いでしょう。 ちなみに、 [Set 1] が通常のバンド編成でのプレイ、 [Set 2] がフルオーケストラとの共演とのこと。

CD 盤

	輸入盤	国内盤
商品名	Score: 20th Anniversary World Tour Live with the Octavarium Orchestra	スコア~フル・オーケストラ・ライヴ2006
発売日	2006 年 8 月 29 日	2006 年 9 月 6 日
価格	2,764 円	4,725 円
ディスク枚数	3
収録内容	Disc 1 The Root Of All Evil I Walk Beside You Another Won Afterlife Under A Glass Moon Innocence Faded Raise The Knife The Spirit Carries On Disc 2 Six Degrees Of Inner Turbulence: I. Overture II. About To Crash III. War Inside My Head IV. The Test That Stumped Them All V. Goodnight Kiss VI. Solitary Shell VII. About To Crash (Reprise) VIII. Losing Time/Grand Finale Vacant The Answer Lies Within Sacrificed Sons Disc 3 Octavarium: Intro I. Someone Like Him II. Medicate Me III. Full Circle IV. Intervals V. Razor's Edge Encore: Metropolis

こちらは DVD Disc1 の内容を CD に収録した形。 輸入盤の方の商品紹介ページでは視聴をすることができます。

Live at Budokan の時は DVD ( 国内盤 ) と CD ( 国内盤 ) の両方を購入しましたが、今回は DVD だけでいいかなあ。 ( この時は PC に DVD ドライブを装備しておらず、音声だけを抽出してカーステ用にディスクを作成することができなかったのです。 )

#movabletype-ja Open!

IRC チャンネル #順列都市で、 antipop | antipop.vox.com のけんたろたんから #movabletype-ja (Kickstart my heart) という記事を教えてもらいました。

Say hello to geeks who love MT in JAPANESE at #movabletype-ja! ということなので、 Movable Type 大好きな私としては早速 Join !

何故か主がいない ?

1. 23:40:17 mkt_BEER > ええと
2. 23:40:30 mkt_BEER > 潜入してみたはいいが、drryさんオンリーて！
3. 23:41:56 drry > ええと
4. 23:42:18 drry > サーバはここじゃありませんのです。
5. 23:42:24 mkt_BEER > おお
6. 23:42:25 drry > irc://irc.freenode.net/#movabletype-ja
7. 23:42:42 drry > 間違えてくる人がいるかもしれないと思って
8. 23:42:50 drry > 一応 join してたです。
9. 23:42:52 mkt_BEER > ぶほｗ
10. 23:42:57 mkt_BEER > ←間違えてきた人

IRC チャンネル #hxxk でいつもお世話になっている drry+@-> の drry さんしかいなくて、実は drry さんが Kickstart my heart の Fumiaki Yoshimatsu さんなのだろうかなんて思いましたが、何のことはない、サーバを間違えていただけでした。

1. 23:44:05 drry > -ja とあったら、大抵は freenode のことなんです。まぁ書いてないのも悪いですが。
2. 23:44:14 mkt_BEER > ほへー
3. 23:44:23 drry > IRCnet だと、-ja とかせずに、:*.jp です。

IRC のこういった面での知識を持っていないなあ……と改めて思わされた夜でした。 もしかしたら一般常識なのかもしれませんが、私のようにそうと知らない人もまだいるかもしれませんので、 #movabletype-ja (Kickstart my heart) には Freenode ネットワークである旨を明記して欲しいです、間違えておいてお願いするのも憚られますが……。

ちなみに、 Freenode ネットワークに継続的に接続する場合は、 freenode: frequently-asked questions に沿って、 nick をレジストレーションしておくと良いとも教えていただきました。 drry さんありがとうございました。

トラックバック送信先

#movabletype-ja (Kickstart my heart)

#movabletype-ja という記述で irc.freenode.net であることは示されているかもしれませんが、そうと知らない人のためにも「 Freenode ネットワーク上で展開している」ことを明記して欲しいと思いました。

たまには推敲せずに書いてみよう

はてなブックマーク関連の話で色々と言いたいことが溜まってきたけど、記事のために割けるまとまった時間が取れないので、推敲なしで書いてみることにします。 本当はそんな文章は自分のはてなダイアリーに書くのが自分ルールなん ですけどね。 not well-formed な状態による parse error が生じない限りは手を加えない、という勢いで。 ちなみにただいまビールをいいかんじに摂取していいかんじな気分です。 ( 今日に限らずビールを飲みながら記事を書くことがよくありますが、ちゃんと推敲しているのですよ ! )

あ、それと推敲していないからって文責を負わないってことはないですよ。 推敲していようといまいと、私が常々思っていることという事実には変わりませんので、ご意見や反論は歓迎します。

概要ページを Wiki 的に使うのもいいんじゃない ?

分裂勘違い君劇場グループ - 劇場管理人のコメント - ブクマWikiページの運営ルールは誰が決めるのか？を読んで思っていたのですが、編集したら「編集ユーザの ID 」「編集した時刻のタイムスタンプ」「編集内容」が自動的かつ強制的に記録されるんなら、ルールなんて特に決めなくても自然に落ち着いていくんじゃないかなあ、と。 これははてなブックマークの概要部分に限らず、はてなダイアリーのキーワードにも言えることですが。

あまりに自分のルールに拘って概要やキーワードの編集をしていれば、その行動は確実にログとして残されるので、そうそう変なこともできないでしょう ? ( それすら予測できずに好き勝手やるのなら、ルールを知らしめたり伝えたい思いを伝えたりすることは叶わず、単純に冷笑しか得られないはずです。 )

もっと直接的に言いましょう。 修正や削除の履歴が残らないブックマークコメントよりも、履歴が残るような場所で議論や対話をしてくれ、と。 はてなブックマークのコメントはやっぱり対自分、対第三者向けであるべきだで書いたことと一部重複しますが、はてなブックマーク - ブクマWikiページの運営ルールは誰が決めるのか？の b:id:fromdusktildawn さんのブックマークには何らかのコメントがあったはずです。 また保存し損ねていたのですが、 ご趣旨には賛成しますです ↓うい。 という b:id:p_shirokuma さんのコメントが何のこっちゃ分からなくなっています。

概要ページを活用したいのはやまやまだけれど

はてなブックマークの概要ページと言えば、もうひとつ言いたいことがありました。

「概要に全力を込めて最適化」という動きが起こって欲しいなと思いました。 ――はてブについては、エントリーページ上部の、記事概要(「エントリーの編集」)を作者自身で編集してしまう文化にも期待。

―― 一般論だけど、全削除して「botによるコピペ」に戻すよりも、「より良い」内容を登録してブクマーカたちに訴えかけるべき。 //記事作者は、?B編集権持ってる場合、第1次的編集責任者。 議事進行権も認めるべき。

これは両方とも b:id:mind さんのコメントで、非常に良い視点で見られていると思います。 でも、記事を作成する側 ( ブックマークされる側 ) としては、「ンなこと言ってもはてなブックマークのシステムやコミュニティがそれを受け入れてくれねえンだよッ ! 」と「大人は何も分かっちゃくれない」的なグレ方をしたくなるような事柄なんですよねこれ。 ( いや私がそういうやさぐれていた中高生だったわけじゃないですよ念のため。 )

前者で引用した はてブについては、エントリーページ上部の、記事概要(「エントリーの編集」)を作者自身で編集してしまう文化にも期待。 という下りや、後者で引用した 「より良い」内容を登録してブクマーカたちに訴えかけるべき。 者は、?B編集権持ってる場合、第1次的編集責任者。//記事作者は、?B編集権持ってる場合、第1次的編集責任者。 という下りは、はてなブックマークの Robot が概要をちゃんと取得すれば解決する問題なんですよね。

私ははてなブックマークがサービスを開始した当初から、その概要掲載について何度も取り上げてきました。

• はてなブックマークによる記事本文の掲載についての考察
• はてなブックマークの概要掲載は必要なのか ?
• はてなブックマークの概要部分を編集できる裏技
• はてなブックマークのキーワードを裏技で増やしてアクセスアップ ! できるかも……?
• はてなブックマーク正式版の気になる変更点
• はてなブックマークの概要をきちんと修正できるようになりそう
• はてなブックマークの概要をきちんと修正できるようになりました
• 一つ一つの記事に含まれる概要と、その活用
• はてなブックマークと <$MTEntryExcerpt$>
• はてなブックマークと dc:description
• はてなブックマークと RSS Auto-Discovery
• はてなブックマークと個別記事ごとのサマリを提供する Feed
• 先頭に全力を込めるのも良いけど、その動機が重要

自分の記事を再び見返していて気付いたんですが、最初ははてなブックマークの Robot は <$MTEntryExcerpt$> を取得してくれていたんですよねえ。 その機能を再び活かしてくれれば、 hxxk.jp のみについて言えば エントリーページ上部の、記事概要(「エントリーの編集」)を作者自身で編集 や、 「より良い」内容を登録してブクマーカたちに訴えかける という作業は不要になるんですよね。 そもそも概要欄を別途記入できないはてなダイアリーユーザや、別途記入できるけれど冒頭から自動で生成してしまっている Movable Type ユーザには関係の無い話ですが。

naoyaのはてなダイアリー - はてなブックマークの概要取得の処理という技術情報も出たので、はてなブックマークと個別記事ごとのサマリを提供する Feed という手法も試してみましたが、うまくいきませんでした。 更に、よく考えてみたら「なんでこれまでも概要を提供していたのに、わざわざはてな ( に限らず特定のサービス ) のためにまた手を加えないといけないのか」という考えに至ったので、この方法は現在採用していません。 はてなアイデア - RSS などの Feed で description を提供している weblog であれば、その description から概要を自動生成するようにして欲しい。本文からの自動生成は description が提供されていない場合のみに。というアイデアも出しましたが、未だ検討中のままです。 hatom - Microformats を用いて概要を提供していることを明示するという方法を教えてもらったので、これをまず試してみるのもいいかもしれません。

だったら機械的な処理に頼らずに、自分で概要を編集すればいいじゃないか ? という意見もあるかもしれません。 それはある意味正しい指摘ですし、私もいくつかの記事は概要を編集しました。 流石に面倒臭くなったので最近はやっていませんが、 antipop - 自 Blog のエントリを自動的にブックマークすることにより、ソーシャルブックマーク最適化を施すのようなスクリプトを正しい概要掲載のために使えば、手間を軽減できるかなあとも考えましたが、自分の記事をブックマークすることついて嫌悪感を抱く人もいるわけでして。 そこまで気を遣わなければならないのなら、やっぱり Robot が概要を取得する時点でまともなものを作って欲しいなあと思うわけです。 ( caramel*vanilla の記事は、自分の記事を自らブックマークすることでアクセスアップを狙うこと、そしてそれによってブックマーク記事にノイズが混じることについて嫌悪感を抱いているようですが、「概要が生成される時点でノイズが紛れ込むこと」を解消する有効な手段もまたセルフブックマークであるので、機械と人が混在して形作るコンテンツは結局のところ何らかのノイズが混じるものだなあと思った次第です。 )

多数派が常に正解と限らないのは Google に限ったことではないけど

Google多数決というサービス、便利そうですね。 辛いものを食べて汗をかく私と、汗をかかないアイツの DIT のように、日本語訳にばらつきがある際に参考にすると良いかも。 実際に DIT の訳語を多数決してみると、「食事誘発性体熱生産」が最も多いようです。

ただ、心に留めておかなければならないのは、必ずしも件数が最多のものが正解ではない、ということ。 これにばかり頼るようにせず、きちんと自分なりに調べることが重要だと思います。 特に夏休み中のよいこのみんな ! ( に、限った話じゃありませんが )

多数派が誤りである例

という結果になっていますが、「実態参照」の方が件数が多くても、実際はその記述は誤りなのです。 以前私も同じ間違いをしていて北村曉さんからご指摘を受けました。 これは顕著な例ですが、「よくある誤解」というのは他にも潜んでいそうなので、ゆめゆめ信用しすぎないようにしましょう、ということです。 以下文字参照関連の関連リソース。

• コメントスパム対策と実体参照
• entity = 実体 - 徒書
• 実体参照 ( 正 ) と実態参照 ( 誤 ) と数値文字参照
• マーク付けノート - 一般実体参照と文字参照
• Re: 参照の件 - 徒書
• Perlで文字列をHTML数値文字参照に変換 - 徒書
• 2006年7月14日の実体参照とか - 徒書