先日も少しだけ触れた、デジタルゲーム学会の定例研究会(講演者 : 竜騎士07&BT)に行ってきた。今回の最大の難関はなんといっても地理。東大広すぎる。わざわざ特急を使って時間に余裕をもたせたのに、結局会場には駆け込むような感じになってしまった。現地アクセスマップは、印刷していくべきだと悟る。
肝心の講演内容は、全体的に「商業と同人」の違いというテーマに引きずられ過ぎだという印象。事前収集した質問がそのカテゴリーに集中していたのかな。でもせっかく制作者達が来ているのに、ビジネス的な展開についての話ばかりが進むのは勿体ないと思った。それと、わざわざ体験版の案内までしているのだから、ごく基礎的な認識(同人ソフトの購入方法とか)についてまで確認する時間はもったいないのでは、と感じた。コミケ会場の「西館」とか、ああいうジャーゴン(?)を控えめにすれば済む話だと思う。
「ひぐらし」「うみねこ」における制作スタンスとユーザーコミュニティの関係については、割と以前から語られていた内容をなぞる程度だったような。「ゲーム=コミュニケーションツール」という認識とか、それに基づいて議論の場として公式サイトを作品内で案内したこととか、ユーザーとの関係性に制作の重点があったことは、もう言わずもがなだし。こうした定例会のテーマそのものは想定できてしまっていた話が多く、どちらかというと自身の立ち位置に対する竜騎士07さんの自覚の強さが印象に残った。竜騎士07さんの話し方がとても丁寧で、洗練された物腰だなぁと感心した。これまでいくつか対談とかを拝見していたけれど、実際に顔と声を知るとずいぶん印象が違った。もっと強い姿勢でモノをいうタイプかと思っていた。
あと非常に興味深かったのが、サウンドノベルというものへの竜騎士さんの理解。確か「サウンドノベルはゲームの一ジャンルではなく、新メディアとして考えるべきではないか」といった趣旨の発言があった。別に無理に「ゲームらしさ」というか、特殊なインタラクションを求めなくても、ビジュアル・サウンドといった要素を織り込んだテキスト、独立した表現形態と考えてよさそうなものだ。考えてみれば、サウンドノベルは何もゲーム売り場以外に置いたって不思議じゃない、「ゲームハード」で駆動するという前提がなければ。
その他、どうでもいいこと。前の席の人がコンピュータ持込していて、2ちゃんねるらしき掲示板に書き込み続けているようだったのが気になった。実況スレでも立ってたのかな。そして終了後、上野駅行きの学内バスがとっくに終了しているのに気付いて萎えた。しかしもう道に迷うのもこりごりだったので、歩かずにタクシーを拾ってしまった。
はてなブックマーク - about:blankが9件あって吹いた。暇なのか。僕もか。
HTML+CSS+JavaScriptの3Dダンジョンを作ってみた。ただし、迷路を動けるだけ。
以前、画像を使って同じようなものを作ったこともあったのだけれど、あまりに処理が重くて公開する気になれなかった。でも今回borderプロパティを駆使してみたら、なんとなくできてしまったので公開した。画像を頻繁に挿げ替えるより断然早い。ただborderに頼っていると、長さ指定にパーセンテージが使えないのがネックといえばネック。
今後非同期通信でシナリオデータを受信・処理するしくみとかを作れば、ダンジョンRPGツクールみたいな感じで使えるかも。その場合text/htmlより、解析済みのDOMツリーが取り出せるXML or XHTMLの方が使い勝手がいいかも。まあ、フリーのダンジョンRPGツクールといえばDesigeonというステキツールが現在進行形で作られているわけだけども、Webブラウザベースってことで、別の需要があったりするかもしれないし。
fragmentディレクトリに2つ文書を公開した以上、そろそろこのページをindexというかtable of contentsらしくしてやらないとだなぁ。目次 + 最新月の雑記、という扱いでいいと思うんだけど、雑記ログのURL命名規則に迷ってしまう。どうしたもんかな。
適当に調べてみたら、CSSのborderを使ったダンジョン描画はDynamic 3D with CSS and the DOMあたりで既出だったみたい。スクリプトも頻繁にコメントが書かれていて読みやすいし、関連ファイルの詰め込まれたzipにはマップデザインのツールまであるし、ずいぶん凝ってる。ちなみにこの作者も画像メインでダンジョン描画を試みたことがあるみたいで、I had to manually work out which images go together to make that particular view!
なんて苛立ちを書いてる。やっぱり嫌だよね、壁の描画はループでまわせる汎用的な処理にしたいよね。
ただサンプルの動作がずいぶんもっさりしてる…と思ったら、描画のためにdivやらspanやらにインラインのスタイル指定をどかどか書き込んで生成してる。しかもデフォルトで視界をかなり広くとれるようにしている(8歩ぐらい?)ので、要素数も馬鹿にならない。内容の動的書き換えにたくさんスタイル指定を含めてるから、再描画のコストが高くなってるんだろうな。
でもって、やっぱりテキストを処理する仕組みが見当たらない。テキスト表現の自在性がHTML+CSSの何よりの売りだと思うんだけど、ひょっとしてHTML文書をシナリオのソースとして利用するゲームAPIって、まだなかったりするのか。リニューアル版「時の封土」はかなり近いと思うけど、シナリオ記述は独自仕様XMLだし(Scene Markup Languageだっけ)。
HTML文書でシナリオ進行を記述できるゲームエンジンを作ってみたいな。制御命令用に独自の要素を作るんじゃなくて、classとidの命名だけで基本的な進行を定義できるようなやつ。profile属性を使えば、リンクタイプやmeta要素の扱いは定義できるんだし、なんとかなるんじゃねぇかと。
はてなにユーザー登録して、アンテナとブックマークを使うようにした。非常に流行遅れで恐縮。ただこれでほとんどのブックマークをWebブラウザに管理させる必要がなくなってすっきりした。理想としてはWebブラウザのブックマークリストはブックマークレットだけ、閲覧をより自由にするものだけにしておきたい。
今日の日付の闇黒日記を読んだら、学問の意味ってなんだろう、とかそんな途方もないテーマを久しぶりに考えはじめてしまった。
今は理系的な學問全盛の時代だから、俺みたいな典型的文系の人間のやり方は流行らないし、攻撃の對象にすらなつてゐるんだが、理系的な方法論を突詰めて行くと「人間は要らない」と云ふ價値觀に行き附くんだよ。ところが人間は人間であり、人間であらねばならない。人間が人間の價値・人間としての價値を認めるならば、「人間無視の自然科學」の方法論は寧ろ排除せねばならないものになる。
何年か前、生物学かなんかをやってた知人に、「文系の研究とか、何かの役に立つわけ? 」と言われたことがあった。そのとき相手が、「この世界がどういうものなのかって考えてるのは実証的な理系研究のほうでしょ。人間の考え方なんて人それぞれだし、それが対象って言ったら研究じゃなくて評論じゃん」とか言ってきて、僕はなんだか必死に「応戦」しようとしたことを思い出した。
その時僕は研究か評論かとかいう区別の問題よりも、「それぞれでしかないから人間の認識なんて放っておけ」という態度にどうしても納得することができなかった。それで自他含め人間の抱く考え方とその行く末に批判的であるべきだ、みたいなことを言いたかったのに、「じゃあお前は人間をエリートかオチコボレとしか見分けられないヤツを政治家にしたいと思うか」、「仕事を失ったとたんにお前はクズだから保険なんか使わず一人でおとなしく死ねと言われる社会で生きたいと思うか」とか、なんだかよくわからない言い回しで訴えてしまった記憶がある。
人間やその社会というものから離れた方法論
を追求し、追従することには常に落とし穴がある。人間のために生み出されたはずの技術は、人間を縛るものにだって簡単に変化する。原発の潜在的恐怖に身が震えても、原発を前提にした生活は捨てがたいと反射的に感じてしまうように、一度使うと決めたものには、続けるのもひっくり返すのもコストのかかるトレードオフが発生する。そうすると損得だけでは、方法論を計りきれなくなる。
ねちねちと認識の在り方を問いただして、失ったものや得られたものを再確認しようと頑張る「評論」めいた文系研究は、人間がトレードオフの状況を超えて決断するためにとても大事な役目を果たすはず、だよきっと。
文系の學問で重要なのは、人間の價値觀を變動させ續ける事であり、物の見方をリフレッシュし續ける事にある。もちろん、物の見方を常に新たにし續ける點で、新たな事實の發見と理論の構築を必要とする理系の學問だつて、本質的には變らない。ただ、文系の學問では人間の主觀――と言ふより價値觀による判斷を通して人間の物の見方それ自體を革新して行く方法をとつてゐるのに對し、理系では理性と知性を用ゐながら價値觀を排除して飽くまで客觀的に事實の認識を改めて行く方法をとつてゐるのが違ふ。
たしかT.S.エリオットあたりが、批評とは既存の認識を破壊し新たなものを打ち立てることだ、みたいなことを言ってた気がするけど、その流れかな。世界が違って見える、いや事実変わってしまう、という誰かの議論を通じて価値観が変化するとき特有の崩壊感と新鮮さはステキだと思うんだ。麻薬のようです。いや、麻薬知らないけど。煙草は吸うけど。
毎日.jpの記事、金色のガッシュ！！：原画紛失訴訟が和解経由で、雷句誠氏の漫画原稿紛失裁判の決着を知った。漫画家と出版社の関係について、さまざまな思惑と経緯あっての裁判だったけれど、ひとまず和解にまでこぎつけたということ。ただ雷句氏の和解についての文章を見る限り、今回達成されなかった課題についての議論は、各所で引き継がれるべき重要な内容を含んでいるように思ったので、コメントしておく。
さて、雷句氏は漫画の美術的価値
と共同提言
が受け入れられなかったことについて無念を語っていた。最初の一つは、漫画の美術的価値
というものを踏まえたうえで原稿が管理されなければならない、という主張だ。だがこれは裁判で出版社に向けるべき主張なのかが疑問だ。国立国会図書館のような公的サービスの運用と絡めていく話ではないのかな。価値云々って言っても、コレクターが高い金を出すものだから大事、なんじゃなくて、末永く残すべき重要な文化的財産だ、という主張を通そうとしているのだから。
そして二つ目の共同提言
は、提訴相手の小学館と共に行おうとして用意されたものだ。雷句氏の言によれば、その中身は小野智彦弁護士さんが作ってくれた
ものらしい。以下に引用する。
- 作者の創造性が作用する社会活動においては、関係者が創作者個々人の創造性・オリジナリティに敬意を払い、これを尊重する風土を確立することによって、文化の健全な発展の基礎が形成される。殊に、漫画出版の場合には、漫画の原稿そのものが商品化するのに不可欠のものであり、かつ、漫画のストーリーと相俟って、漫画そのもののもつ視覚的印象に美術的価値があるのであって、これらに携わる者は、これらの価値を見いだした創作者の意向を十分に尊重する姿勢が必要である。
- 我々は、漫画原稿が出版社において扱われる場合には、法律上又は倫理上、次のようなルールが守られなければならないと考える。
- 出版社は漫画原稿を預かった場合には、その原稿の価値を尊重し、善良なる管理者としての注意義務を持って、それを管理しなければならない。
- 出版社が預かった原稿については、出版できる状態、つまりポジフィルム化した段階で、速やかに漫画家に返却し、必要以上に原稿を管理してはならない。
- （この項目には賠償金の倍率設定が入っていましたが、今回の和解内容にて、「金額の内訳を公開しない」との約束が入っていますので、ここでは公開する事はいたしません。）
肝心なのは提言の内容の一番目、今回の裁判に雷句氏が踏み切った原因でもある、作家と出版社の関係性についての議論。原稿の紛失が出版社の過失として認められるということと、作家の立場を考慮する風土を作り上げるということはイコールじゃない。現状認識と打ち立てるべき理想については議論の余地がいくらでもあり、出版社と裁判で戦うだけでは到底至れないものだろう。だからこそ、この裁判は「和解」した後こそが重要だ。
そして提言の二番目の項目は、一番目の項目や上で触れた漫画の美術的価値
の同意あっての具体的ルールにまで言及している。だが法律上又は倫理上
、ルールが必要とまで言い切る積極的な提言は簡単じゃない。裁判という「決着」をつけるための場で提言するのではなく、きちんと時間をかけて合意を形成するための場を別に作るべきだと思う。「漫画界にとっての重要事項である」という前提を持つ、もっとふさわしい場を。
この共同提言は小野智彦弁護士さんが作ってくれたものです。自分もこの内容を見たときは、これはなんとしても実現させたいと思っていました。決して、無理な提言ではなく、小学館にこの先の漫画界をリードする立場となる内容である、と思っていました。しかし、この提言は全く小学館側で受け付ける事をしてくれませんでした。自分は今日の協議で、「賠償金の設定など、内容については、こちらは話し合う姿勢があるが、それ以前にもう、共同提言自体を否定しているのですか？」と、問いました。やはり、相談云々ではなく、共同提言自体ができないとの事。
雷句氏は小学館、裁判官が共に提言には付き合わなかったという点に落胆している。だが一人の漫画家とのすれ違いから発生した裁判の場で、数多くの漫画家と出版社全体を巻き込まざるをえない提言に関して話し合うこと自体が不適切だ。雷句さんが本気でこの提言を実現したいと考えているのなら、裁判を通じた短期決着なんか狙っちゃ駄目だと思う。原稿紛失の民事裁判では、雷句氏本人と出版社の間しか問題にならないのだから。
相手方に対する雷句氏の認識はどこかずれている。裁判までに数々のつらい経緯があったことは、雷句氏が提訴の時点で公開していた陳述書で語られていたし、そのことについて外部からどうこう言えるとは思わない。ただこの提言が受け入れを前提に議論できるものと信じる雷句氏の姿は、出版社の「再犯」を防ぐためには前提なしで努力すべき、という「刑事犯への追求」のように見える。
自身を含めた漫画家の職場環境に対する雷句氏の使命感は、けして馬鹿にされるべきものではないと僕は思う。だがその問題の解決に必要とされるのは「悪の断罪」を行う一人のヒーローではなく、多くの漫画家と出版社が理想として掲げることのできる風土
について、合意可能な姿を根気良く探り続ける数多くの人間(もちろん、作家・出版社双方)の努力だろう。
ところで…京都精華大学マンガ学部には、漫画家を集めたりファン向けのイベントを企画するとかだけでなく、こういう問題に積極的に関わっていく姿勢を示してほしいと思うんだけど。何かアクションはないのかな。
携帯ゲーム機は携帯しない? 自宅での使用が7割との記事。調査はアメリカのものだが、記事本文を読むと見出し以上にはっきりした数字が出ている。7割
という数字はiPodなどの「モバイル機器」全般を踏まえた数値であり、ニンテンドーDS単独ではなんと自宅利用が9割を超えるという。
ニンテンドーDSを持っているユーザーの92%はひとりでゲームをしており、その4分の1は近くに住む友達とカートリッジの貸し借りをしています。DSユーザーがゲームをする時間は一週間で4.6時間とのことです。
週に4.6時間
という集計は捉え方が難しい。モチベーションの保てる作品に出会えばついつい何時間でもやってしまうことは多いと思うが、そういう作品と出会わなければ一ヶ月一度もしないとかいうことだって頻繁にあるだろう。大体平均すればこのくらい、という目安でも答えさせたのか。
「携帯型ゲーム機」という名称に疑問もろくに抱いていなかったが、携帯「できる」ハードであることと実際に携帯「する」ハードなのかは別問題だ。僕自身、DSを外でプレイすることなどまったくといっていいほどない。電車でしている人(だいたい20代男性とか、小学生)もちらほらと見かけるが、いざ調査をしてみればニンテンドーDSを持っているユーザーの92%はひとりでゲームをして
いるという結果が出てくると。
バッテリーなどの関係から、モバイル機器を自宅で使用するというのは誰にもある経験だと思いますが、携帯ゲーム機は据え置きゲーム機と競合しないことが利点とされてきた面もあるだけに、この調査結果は携帯ゲーム機のあり方を示すよい材料となりそうです。
バッテリーのくだりは同意だが、携帯ゲーム機は据え置きゲーム機と競合しないことが利点とされてきた
というのはどのあたりのことを言ってるのか不明。アーケードとコンシューマだって、ファミコンの登場やらなんやらで「客の奪い合いだ」とか騒いでいた時代があったわけだし。まあ長年の経緯の中で、メーカーもユーザーも棲み分けが進んできたとは思うが、競合関係が解消されているという認識は今一つピンとこない。たしか以前あった芝村裕吏氏の講演などでは、「ゲームはあらゆる既存作品と競合する、発売してしまった後は自社の作品すらも中古市場を通じて競合相手になっちゃう」みたいなことが言われていたし。
いまいちはっきりしないので、元ネタを探した。それで一応調査を担当した企業、NPDのウェブサイトにレポート一覧があったが、肝心の調査の中身はどうも会員登録を経ないと読めないようだ。そりゃそうか、マーケティング会社の調査だもんな。
文書型宣言を全てXHTML 1.0 Strict → HTML 4.01 Strictへと変更した。どうせ互換性を気にしてtext/htmlをやめる気もないのだから、最初からHTML4.01にしておけばよかったのだ。XHTML 1.0 Strictは慣れ親しんだ文書型だったけど、もうXMLとの適合性についてあまり魅力を感じていない以上、さほど意味がない。XSLTを使うなら、XHTMLじゃなくて自己流XMLで好きに書いてしまえばいいんだし。
実は、文書型宣言を変えるのと別の案も考えていた。全ての文書をapplication/xhtml+xmlにして拡張子も.xhtmlの状態で鯖に保管、同一名称の.htmlにアクセスがあったら、サーバーサイドスクリプトでXHTML文書を取り込み、HTML4.01適合文書に変換して送出するというパターンだ。これだと、普段の文書作成にはXHTMLの豊富な語彙を自由に使い、HTMLしか扱えないUAにはXSLTをサーバサイドでかけて送出してやるという対応が可能。
XHTMLとHTMLの両対応ってことで二番目の方がカッコよさげなんだけど、面倒なので手をつけなかった。PHPとかSSIとか全然触ったことないし。いずれXMLを使うメリットが大きくなってきたと思ったら考える。
あとInternet Explorerのレンダリングに真面目に対応してみた。CSSハックを使うのは嫌だったし、VBScriptを利用。VBScriptは今のところIEしか読まないから、他のまともなWebブラウザに振り分けのための余計な処理をさせずに済む、というのが最大のメリット。勉強するのはだるかったが、慣れてくるとコードはスイスイ書けた。ただ動作確認はIE7でしかしてないので、旧バージョンでどうなのか知らん。
今のJunkieta.netは、スクリプトを拒否ってなければIEでも擬似要素で指定したスタイルと同等の表示がされるはず(counter-increamentのバグの影響はあるっぽいが)。一番変化したように感じられるのはおそらく引用部だろう。あと印刷時の記述ね。IEは印刷はわりにしっかりしているので、そこは丁寧に対応したいなと思っていた。
「オンラインサービスを適当に利用していると危険だよ」、という日経ネットの社説。まあ、よくありそうな話。
自分の子供の名前や住所がインターネット上の地図に目印付きで公開されていたら。そんなぞっとする出来事が全国各地で起きた。学校の教師が家庭訪問用に作った地図が外部から閲覧されてしまったのだ。
子供の個人情報が漏れていたのは青森県八戸市、長野県飯田市など報道されただけでも10件以上に上る。米検索大手、グーグルが無償で提供するデジタル地図情報サービスを教師が誤って利用していたためだ。
そもそもGoogleマイマップ自体、「意図せぬ公開」を誘発させやすいインターフェイスであることは、すでに 高木さんの日記で指摘されている。
普通にマップを作っているときも、作成過程がそのまま実況中継のごとく公開され続ける。そんなこと誰が予見できようか？
たまたま Ctrl-V （Command-V）でクリップボード内の文字列をペーストしたら、前にコピーしていた機密情報がペーストされてしまい、慌てて消すなんてことがよくあるが、そのタイミングで自動保存されると、それが他人から閲覧可能になってしまう。
たったそれだけの操作ミスで情報流出が起き得る。Googleマイマップはそういうサービスだ。
こうしたインターフェイスへの指摘はもっともで、早々に修正されるべき点だ。
しかしウェブは公開(publish)が前提の空間。そもそも「公開」するつもりのない情報をオンラインのAPIで記述するということ自体、トリッキーなことをやっていると思う。
たとえ「非公開」と名付けられた設定があったとしても、「非公開」の実質は提供側のポリシー次第だし、継続的な情報管理を行っている以上、サーバーには確実にデータが残る。削除という操作をやってみたところで、本当に全てが削除されているのかを確認する術はない。ウェブのメリットが単に出先からでもデータのチェックや更新を行える程度のものであれば、おとなしくUSBメモリでも持ち歩いた方がマシだ。
利用者も注意が必要である。最近はネット上で友人と情報交換するサービスが人気だ。日記代わりにネットを使う若者も多いが、情報が漏れる危険性を絶えず忘れてはならない。学校でも今後はネットの使い方を教えていく必要があろう。子供のほうが詳しいといわれるが、教師に対する教育も必要だ。今回の出来事はそれを端的に表している。
Winnyが取り沙汰された時もだが、そこかしこで「ネットの危険」とやらを情報漏えいの問題にしていく現状がおかしいんだよ。ネットの使い方
なんて大雑把なコトバで、情報管理の具体的知識とか方針と、「公開」についてのメディア・リテラシー一般を混同すべきではない。前者は技術的に解決可能なものが多いが、後者は情報の制作・受容とそれが行われる媒体について批判的に捉えていくことが必要。教えるべきだと言ったって、取り組みだけならずいぶん昔からやってるわけで、安易に教育に言及すればいいってもんじゃない。
ちなみに文科省が公開している資料の中に、情報活用教育を定義し、これから重要視していくよと宣言したときのものがある。
- （「情報活用能力」）
臨時教育審議会（昭59.9～62.8）,教育課程審議会（昭60.9～62.12）及び情報化社会に対応する初等中等教育の在り方に関する調査研究協力者会議（昭60.1～平2.3)での検討を経て，将来の高度情報社会を生きる子供たちに育成すべき能力という観点から，これからの学校教育においては，「情報活用能力」を育成することが重要であるとの考え方が示された。
- （「情報活用能力」の具体化）
「情報活用能力」という概念は，諸外国で「情報リテラシー」と呼んでいる概念に対応するものとして，臨時教育審議会第二次答申（昭61.4）で初めて用いられた。そこでは，「情報及び情報手段を主体的に選択し活用していくための個人の基礎的な資質」を指すものとし，「読み，書き，算盤」と並ぶ基礎・基本として位置づけ，学校教育においてその育成を図ることが提言された。その後，教育課程の編成・実施に向けて「情報活用能力」の具体的な内容についての検討が重ねられ，今日では，文部省が平成３年７月に作成した「情報教育に関する手引」（以下「手引」とする。）に，次の４つの内容で整理されている。
- 情報の判断，選択，整理，処理能力及び新たな情報の創造，伝達能力
- 情報化社会の特質，情報化の社会や人間に対する影響の理解
- 情報の重要性の認識，情報に対する責任感
- 情報科学の基礎及び情報手段（特にコンピュータ）の特徴の理解，基本的な操作能力の習得
大原則としてこういう文句が作られたのがすでに10年以上前。カリキュラムに口を出すなら、最低でもここから10年分、どんな実践があったかざっと調べた方がいいだろうな。
ただ最近文科省のお墨付きで、やってみよう 情報モラル教育なんてサイトの公開が始まってたんだけど…マークアップが見出しレベルですらぐちゃぐちゃという有様。多様な閲覧環境に対する配慮不足だって、公的機関のモラルとしておおいに問題だろ。視覚障害者、格差を痛感 ＩＴ革命に政府は旗振るけれど…なんて記事が出て、もうすぐ八年目だってのにさ。情報教育って技術を伝えるだけじゃないけど、技術をおろそかにしたまま先導するのもどうかと思うよ。
論文とかをウェブで公開することをよく考える。章・節・小節(項)とかの基本的構造は実に素直にエミュレートできるし、専用のリンクタイプまで仕様書で記されている。適当な雑記・日記なんかより、最初から構造化して記述するよう心がけている学術系の記述は、適切なマークアップを施す対象として萌えるね。
しかし論文のフォーマットはそのままじゃウェブ向きにはならない。一番、問題なのはリソース参照の在り方だ。具体的には脚注とか参考文献の記し方とかになる。
参考文献を文書の最後に列挙するフォーマルな方法は、ハイパーテキストにおいては優先的に行なうべきものでもなく、特に文中リンクを回避するのに用いてはならない。それは瞬時に参照可能であるというハイパーテキストの最も重要な利点に逆行したものであり、ウェブユーザビリティを低下させる。
ウェブでは文章から参照先を隔離する必要がない。ハイパーテキストは文字列に参照先を属性として付加させることで、閲覧者があるリソースから次のリソースへの連環を自由に拡げていくことができる。わざわざページ末や別文書に参考情報だけを分離する方法は、本文領域を圧迫しないために用いられる紙媒体の手法である。
もっとも、ウェブリソースとて印刷するならば、むしろ紙媒体の標準的なフォーマットを模した方が都合がよくなる。ハイパーテキストが文中に登場しても、URLが不明だったり、その都度行内に書き込まれたりしていると、はなはだ読みがたい結果となって現れる。本文中のA要素からhref属性、あるいはBLOCKQUOTE・Q・INS・DEL要素からciteを抜き取り、印刷ページの最後尾に「参照先一覧」として付記するのが望ましいだろう。title属性の用い方について規則性を持たせておけば、こうしたアプローチはさらに有用になりうる。実質的には、優れた印刷結果を期待するとスクリプトをこさえなければならなくなるが(CSS3が実装されてもこれは困難だろう、DOMまたはUAの仕事だ)。
今のウェブは意味を喰われた砂漠だ。ブログという魔物が、そこに住んでいる。ウェブを構成する意味を根こそぎにして、片っ端から胃袋に埋め込んでいくだけの魔物。
ブログの内部にも優れた記事は溜まっている。でもそういう問題じゃない。優れた文書はブログツールなんて使わなくても―プレーンテキストでも古典になりうる。一方で、ナビゲーションリストが一体どんな感動を与えてくれる？ ブログパーツの何が、書き手の主張を伝えてくれる？ 僕はいつもいつもいつも、余計なものに阻害され、文書になかなか出会うことができない。
XHTML&CSSが生み出すのは、広大な空間を漂う文書群を、参照という意味の糸でつなぐウェブ―セマンティックウェブという話だった。そしてブログのカラダは、これらウェブの新時代を司るといわれた仕様をベースに作られた。でも実際は、いくつもいくつも「パーツ」をつなぎ合わせるお遊戯会。文書の構造化ではなく、構造の中への文書埋め込みがウェブのトレンドってことになっちゃって。
いまや本文とは、ナビゲーションや閲覧者コメントで挟み込み、思い描いた(そして多分に、妄想的な)視覚的デザインを完成させるための隙間埋めに過ぎないのだ。実質的に埋め込みに過ぎない構造だらけならば、Frameset文書型を選んでくれた方が、読み込みコストが下がる分まだマシというもの。それがハイパーテキストだなんて、まるで悪い夢みたいだ。
構造と内容を分離し、ウェブページを動的に生成してサーブするのが制作者にしか利益がないのに対し、CSSによってセマンティクスと表現方法を分離するのは広く閲覧者に利益がある。
構造と内容の分離というキャッチフレーズがもたらしたのは、セマンティックなウェブなどではなく、構造という骨格だけを残して内容という血肉を投げ捨てた文書群。<div class="body">と<body>の境界線が消失し、後には骨だけが残る。分離されたのは表現と構造ではなく、ハイパーリンクと本文だったんだ。それは分離独立ではなく、HTMLの死。
今では「そんな文書を作っている人がいるのか」と、リンクテキストに期待を感じることはずいぶん稀な経験となってしまった。「いかにして多くのリンクを無視するか」がウェブ巡回の重要なスキルになってしまうなんて思ってもいなかった。青い下線の示す参照が、どれだけウェブの価値を占めていたのかを痛烈に思い知った。
「別にそれぞれでいいじゃないか」という声がきっとある。ちゃんとしたHTML文書を書きたい人はそう書けばいいし、デザインに興味のある人はそうすればいい。トラックバックリストやコメントリストだって立派なコンテンツだよ、興味は人それぞれ、好きにやっていけばいいじゃん、と。流行に対してものを言ってないで、せいぜい意味のある文書とやらを作ってなよ、と。
誰も自分を変えたがらない、人と同じ夢を見たいと願わない。悪いのは夢の語り部なのか聞き手なのか、仮に誰も悪くないのなら、どうしてこんなにもウェブは乾いているのか。気付けば僕のFirefoxが読むuserContent.cssは、display:noneに続くセレクタで埋め尽くされていたんだよ。
つい先日、印刷時の表記について以下のように述べた。
本文中の
A要素からhref属性、あるいはBLOCKQUOTE・Q・INS・DEL要素からciteを抜き取り、印刷ページの最後尾に「参照先一覧」として付記するのが望ましいだろう。(中略)実質的には、優れた印刷結果を期待するとスクリプトをこさえなければならなくなるが(CSS3が実装されてもこれは困難だろう、DOMまたはUAの仕事だ)。
この印刷結果の調整について調べていたら、参照先一覧を脚注として生成するスクリプト、Footnote Linksが公開されていたので、ざっとコードを読んだ。挙動をまとめると、以下のようなもの。
window.onload後にA・Q・BLOCKQUOTE要素の属性からURIを取得A・Q要素の末尾に、参照先一覧のindexを振るシンプルな動作だが、CSSの非表示指定に頼らないとならないのが苦しい。CSS OFF & JavaScript ONな閲覧環境は、すでにハイパーテキストという形で明示されている内容を二重に取得することになる。印刷結果をサポートするスクリプトは印刷時にだけ動作するのがベスト。Internet Explorerでは、独自のイベントハンドラとしてonbeforeprintとonafterprintの二つが実装されているので、IEに決め撃ちするならば用意に実現できる。
だが汎用的な処理なのだから、globalObj.addEventListener("print",generateFootnote,true)とか書きたいところ。MDCのイベント一覧をながめても、それらしいイベントタイプはFirefox3にも見当たらなかったけど。あるいは、<script media="print">とかね。読み上げブラウザもJavaScriptを解釈するくらいなのだから、@mediaがスクリプトに導入されてもよさそうなもの。でもHTML5の仕様は、asyncとかどうでもいい属性がひっついただけだし。いまいちやる気がわかないところだ。
リンクというシステムは、リンク先が存在しなくても成立するものであると私は考えます。
実際、相手が存在しないという理由で、リンクが書かれているページ自体がエラーになることはありません。「Not Found」と言われるのはリンク先に移動した後のこと。リンク先が存在しないからといってリンク元のページが成立しなくなるのか？ そんなことはありません。
エラーになる
わけではないが、文章として完結しないものが増える。明確な書誌情報を記された文献と比べたときに、ウェブが弱くなってしまう所以。
僕は大学でレポートの類を書く際、ウェブのテキストを参照する場合は存在を確認した日付を記せ
と指導を受けた。そのことがとても、哀しかったのを覚えている。一意のURIはISBN同様の信頼性を得るべきだとイデオロギッシュに信じている一方で、参照の信頼性を担保できない現実がある。
ちなみに僕自身もウェブサイト移転などという、publisherとしては批判されるべき愚を犯さざるを得なくなったばかりだ。junkieta.netというドメインの取得には、URLの喪失を二度と繰り返したくないという自戒を込めている。(それでも絶対じゃない。年間1000円以上確実にかかる維持費を、僕という個人が払い続けることができる保障などない。)
結局、ウェブでも引用が極めて重要。現状のリンクはNot Foundに対しあまりに無力。引用とリンクのどちらが適切か考える際は、その都度判断して文章の整合性を保つしかない。なにがリンクとして記述されるべきか、もっと考えておかなくてはならないな。
はてなブックマークの仕様が変更された件についての愚痴。加入したばかりでよくわからんまま、機能を色々試しながらちまちま書いていたスタイル指定はこれでパアになった。デザインの変更についてのページに「HTMLを観察してCSSを書け」みたいな文言を載せておいて、仕様変更によってこれまでのものはまるごと廃棄とか、そりゃねーよ。編集画面に「近々CSSは利用できなくなる」程度の案内は書いておいてほしかった。それならデザインなんかいじらなかったのに。もうどうにもならないが、実に無駄な労力を支払ってしまったよ。
少し調べてみたら既存UIを保持するアイデアが出ているのに気付いた。クラシック画面の提供は
、新バージョンの正式リリース後に検討して提供
との回答が出ているので、まったくの無駄、というわけにはならないかもしれない。
しかし、はてなは情報が分散していて、どこをどう辿れば、サービス利用上の重要事項を見落とさずに済むのか、どうにも把握できていない。「リニューアル」とかに振り回されるくらいならば、公開ブックマークも自前のサーバーに置いた方が楽なのかも。外部サービスの利用については、もうちょっと慎重になったほうがよさそうだ。