agenda 2002-12(下旬)

Semantic markup

公開
2002年12月31日

今日はリアル大掃除とサイト内の大掃除で目が回りました。さて、ちょっとした事件があったので臨時に27日のボツ記事を公開いたします。因みに、2002年の全てのボツ記事は年始に公開します。例の下品な企画ですね。

ここからボツ記事です。

Mark Pilgrimさんが、記事の中のcite要素を利用して、アーカイブを作られた模様。

Let's see, why can't you do this? Wait, wait, don't tell me... it's coming to me... oh right, you don't use semantic markup. Sucks to be you.

Pushing the envelope (dive into mark) より

痛快ですなあ。私大好きですこの人の文章。何故オライリーの記事にはスパイスが効かなかったのか……ってそりゃあそうですね。

ただこの話をHTMLに結び付けるのは勘違いの原因になります。何故なら、個々人が勝手にclassで定義した<span class="cite"></span>でも一向構わないわけですから。このような制作者サイドの利用に限っては。

このような方法に基づいた記事収集を検索エンジンが行ってくれるなら、その時は私も攻勢(謎)に出ますけれども。

ここまでがボツ記事です。

氏の、この「痛快」な文章ですが、「腐れぶろがー」達を煽る結果になったらしく、中々面白いことになっています(The tag soup of a new generation (英語)参照)。「似非セマンティッカー」とか色々登場。しかしHTMLでさえ意味付けを徹底しようとしない連中が何を言っても説得力はない訳で、Pilgrimさんのいう「新世代不思議マークアップ」が登場するだけだと思います。

リンクの性質をUser Agentに伝える

一連の話題のうち、面白そうなアイデアをピックアップします。

dive into mark (英語)では、他サイトとの自動的な双方向リンクを実現しており、リンク元の記事のタイトルやPermalink、所謂「永続的URI」を取得させているそうです。制作者のエゴだ等々という批判を受けながらどんどん進化していった経緯があり、便利なので私は良く利用します。逆にいえば、dive into mark以外の「双方向リンク」は全然使ったことありません。リンク先に何があるか良く分からないからです。メンテナンスも疎かなので、宣伝目的のリンクとかが紛れているのも嫌です。それはさておき。

その「永続的URI」をUser Agentに知らせる為には、a要素にrel="bookmark"という属性を付加すると良いそうです。むしろそれ以外には無い気もします(推測になってしまう為)。他のa要素についても、XSLTスタイルシートを変更してなるべくrel属性を示そうと思いました。

余談

サイトの大掃除(全ての文書をXSLTスタイルシートで変換)が終ってからこの辺りを考えたので、またやり直しです。急いでPURLを取ってきて、大急ぎでRDF形式のprofileをでっちあげ、それをXHTMLに変換するスタイルシートを書き、変換の高速化を図るためにスクリプトを修正し、ようやく今さっき終ったところです。バッチリうまく行ったのはスクリプトだけですね。200以上のファイルを20秒で全部変換します。今までは変換結果のXMLファイルのDOMツリーにアクセスしていたのですが、変換結果(XHTML)をパースする際にDTDを毎回読みに行っていたのが遅くなっていた原因の全てでした。メモリも恐ろしく消費しまして、ごみ収集だけで2、3分かかっていました。ところが変換結果をStringとして取得してDOMツリーのアクセスを諦めれば、何もかも高速になります。折角大掃除用に考えてみたXSLT&DOM用クラスの数々のメソッドが殆ど無駄になってしまいました。まあ今後使いまくる予定なのですが。

文書の断片とそのURI

公開
2002年12月25日

文書断片についてのお話。

日記型コンテンツの更新版のidについて

日々更新されるコンテンツ(日記型コンテンツ)の各記事には、idを振るべきではありません(保存版には振った方が便利ですが)。更新された際、URIが消滅することになってしまいます。

というわけでスタイルシートを慌てて修正。このagendaの方はウッカリしていただけなのですが、よく考えてみるとPersonnel更新情報の方もまずかったのです。クライアントサイドでのXSL変換後に生成されるURIというのは、結構盲点でした。

「リンクはジャンプではない」が頭でしか理解できていない証拠ですな。染み付いているという奴でしょうか。これが本当に分かっていれば、こういったミスは二度と起らない筈なのです。

どこにidを振るべきか

記事の見出し要素にidを振るか、記事を包括したdiv要素に振るか、という話題が出ていますが、どちらでも参照したい(参照してもらいたい)と考えるものに振れば良いのではないかと思います。「思います」というか、当然のことではあります。寧ろ振らなくても問題ないわけです。idによって示された断片は、制作者以外の参照する側が参照しようと思った部分であるとは限りませんから、その参照する側にとっては結局のところ不完全な仕様であり、不便も何も、欲を言えばきりが無いのです。

問題は、参照方法です。参照する側の問題です。「どこどこの12月25日の記事」というテキストをa要素にして、フラグメント識別子つきのURIで表されるリソースにリンクしたとすれば、その断片は「記事そのもの」でなければおかしい訳です。見出しや空文字列にリンクする意図は無いのですから。

例え話

ある長大な文書があったとします。例えばW3Cに置かれている仕様書を想像して下さい。その中の、ある用語の定義にリンクしたい場合、リンクした側には、その仕様書全体を紹介する意図は全くありませんし、利用者側も、文書全体をレンダリングさせたいとは思いません。にもかかわらず、現在の一般的なWWWブラウザは、文書断片へのリンクであったとしても文書全体をレンダリングする仕様になっており、WWWユーザー全体でどれほどの時間の損失が発生しているか、その量は計り知れないものがあります。

何故改善されないのでしょうか。私は2つの原因があると考えます。

  • 1. リンクの意図とその実質の乖離
  • 2. 著作権の所在が不明瞭になる

2. については、個人レベルで改良すれば誰から文句を言われるものでもありませんが、その場合でも、文書断片のみをレンダリングするようにブラウザを改良したとしても、1. の問題があるため多くの場合全く役に立ちません。 仕様書の例でいえば、<a name="dt_foo"></a>のような断片が散見されますが、それらにリンクしても空の文字列がレンダリングされるだけです。つまり、1. が原因で改善不可能、あるいは無駄になってしまうのです。

「リンク=ジャンプ」という考え方が如何に様々な実害をもたらしているか、良く私はここで書きますが、この例え話(あるいは、<a name="dt_foo"></a>)などもその氷山の一角といったところでしょうか。今更どうにもならないのです。

今後の方針

どの文書断片に識別子が振られていようと私の知るところではありませんが、私が意図する参照先と明らかに異なる断片であった場合、その識別子は今後利用しないことになりそうです。不便ですが、徹底しなければいつまでも観念のままです。参照ではなく、引用することが妥当となるように文章を書き直すことも多くなるでしょう。意図しない空文字列にリンクするよりは幾分マシというものです。

参照

リッチなブラウザを利用されている方はフラグメント参照もどうぞ。

ウェブデザインの間違いトップ10 - 2002年

公開
2002年12月23日

漫画つき。

テーブルレイアウトと余白目的のblockquoteタグは、トップ10に入っていない模様です。

しかし、特にテーブルレイアウトはユーザースタイルシート使いにとって大打撃なんですよね。まあ確かに普通の人には関係ないかも知れませんが、例えば私が英語圏のサイトを閲覧する際には、その文書にきちんとした意味付けが行われていると、ユーザースタイルシートによって読みやすさが25%上昇するのです。いやホント。

日本語以外だと概観が掴み難いですから、どこからどこまでがナビゲーションで、どこから本文で、といったことを瞬間的に把握するのにユーザースタイルシートが結構役に立ちます。さもなくば、各情報ブロックを凝視しなければその性質が分からないこともあります。ですから、似たようなサイトならば正しいHTMLで作られたサイトのほうを優先的に閲覧することになります。

さて、このサイトは最後の項目(10番目)に引っかかりました。突然起動するメーラー問題。

自分でも間違えてクリックしてしまったことがあったりします。そもそもa要素として明示する必然性があるのかどうかかなり怪しいものです。意味の明示ではなく行為を意図しているので、その意味では間違いと言って良いでしょう。なんとか改善しようと思っています。

リンクフォルダからDOM Inspector

公開
2002年12月21日

お気に入りのリンクフォルダから使うDOM Inspectorを試作してみました。Internet Explorer6限定の方向で。Mozillaはもっとずっと立派なものが最初からありますし。

こいつをお気に入りのリンクフォルダに入れて使います。所謂「対象をファイルに保存」です。意味不明ですが。なんだファイルに保存て。

何をしているかというと:

  1. 表示している文書のBODY要素を消去
  2. FRAMESET要素と2つのFRAME要素(A, B)を生成
  3. Aにその文書のURLを読み込ませる(通常キャッシュから取ってくることになります)
  4. Aの読み込みが完了したら、BにDOM Inspectorを生成

制作者側のJavaScriptをProxomitron等でカットしておけば、そこそこ動きます。

2つのフレームはドメインが同じなので、お互いのdocumentにアクセスできるのではないだろうか、という実験でしたとさ。

リンク抽出

公開
2002年12月17日

JavaScript等を用いてリンクを抽出しようとすると、次の3点の問題が出てきます。

  • 1. 多数のリンクを抽出して視覚化しようとすると、描画に時間がかかる
  • 2. JavaScript依存のアンカーをどうするか
  • 3. 文脈に依存したアンカーテキスト(a要素の内容)は抽出しても意味があまりない

1. については、描画のタイミングで解決できます。配列に収めたリンクに関する情報達を、検索エンジンの結果のように小分けすれば良いだけです。また、同じリソースへのリンクを纏めてしまうことで、かなり速度を短縮できる例もあります。

2. は、例えばjavascriptスキームに頼っていたり、onclick属性にJavaScriptコードを記述しつつhref属性が「#」になっていたりするa要素が原因になります(例:<a href="javascirpt:jump(uri)">)。

3. が問題です。「ここをクリック」をどう解決するか、と言い換えてもいいでしょう。これは実際に文脈全体を把握する以外にありませんが、このようなタイプのリンクを抽出して一体どれだけの利益があるのかということも考える必要がありそうです。

fub_net限定

前述の2. の問題は、fub_netのカスタムパネル上ならば解決できます、これは画期的なことだと思います。何故なら、JavaScriptを無効にしている際にこれらのアンカーに出くわしたとしても簡単にリンクを利用できるからです。例えば、javascript:jump(uri)の例では、uriを正規表現で抽出するとかいう方法ではなく、window.jump(uri)を実行すればよいのです。windowオブジェクトはアクティブタブのものであり、JavaScriptが有効になっているカスタムパネル上から実行します。

問題が無いわけでもありません。制作者がexternalオブジェクトを利用していた場合などは、警告ダイアログ等を出す必要があるでしょう。完成度を高めるには「実戦」経験が必要になると思います。ブラウザクラッシャーを経験しなければ駄目です。

カスタムパネル上でActiveXを解禁にすれば、例えば拡張子が不明な、あるいは信頼できないリソースでも、HEADリクエストを送ってMIME typeを調べることなどが可能です。

ともかく可能性が大きすぎて目がくらくらしてきます。何から手をつけるかということをこのように事前に纏めておかないと、色々なことに手をつけ始めて頭がパンクしてしまいますよ。ここ数日はJtrEntで実戦経験を積んでいましたが、そろそろ何か台本を書きたくなってきました。

scrollIntoViewメソッド

脱線しますが、先日msdn (英語)をうろうろしていた際、scrollIntoView (英語)なるメソッドを見つけました。DOMでいうElement全般が実装している模様です。

var elm = document.getElementById('some_id');
elm.scrollIntoView();

このように使用可能です。window.scrollよりも良い点は、例えばoverflow:scroll、またはoverflow:autoというCSS宣言によってスクロールバーが表示されている「コンテナ」でさえもスクロールさせ、目的の要素を表示できることです。