2002 年 3 月の日記

Keep-Alive でセッション維持してしまえば接続は 1 回で続けて持ってこられます。

しかし、cache control 関係で多数のファイルを管理することになるため、その点で不利になる可能性があります。また、当然のことながらリクエスト回数が増えるため、それによるオーバーヘッドが発生します。

逆に、関連するスタイルを一つのファイルにまとめることで、モジュール単位の読み込みのイメージで簡単にスタイルシートを管理できるという利点があります。私は分割しまくっている理由はこれ。リスト関係は list.css、フォーム関連は form.css みたいに。

今日も行ってみたり……波田野さん、前人未到の 5 連続を達成。

環境と言っても、マシンではなく自分。テレビ台とかトイレ回りとか色々買ってくる。

荷物はかなり片付いたので、あとは不要な UNIX USER 他を捨てたりしたら、かなりスペースができるかな。

それよりも、要らない CD を捨てる方が余程スペースができるけど。内容を確認しながら選ぶ必要があるものが結構あるので、ちと時間かかりそうなので、これは後回し。

捨てられない CD も多そうだけど……。

昼過ぎまで寝て、昼からはオウガバトル PS 版などに興じてみる。

たまにはこんな休日も良い。

Ancient library の文字がガタガタ揺れていたのに対処してみました。

要は redraw が発生しないようにするのがポイントらしい。Mozilla では描画要求が発生する度に描画してしまい、IE は double buffering して描画を減らすことで高速化しているのでしょうな。

んでも、Mozilla って build 時に --enable-double-buffer ってあるんですが。有効になってませんか。

で、今回の場合は背景画像が置いてあったのは body 要素で、html 要素に対しても背景色を指定していたのが問題。

これにより、スクロール時に body 要素の描画とは別に html 要素に指定されていた背景色も再描画がかかってしまっていたこと。

これの解決策としては、以下のものが考えられます。

• html 要素の背景色を指定しないことで、html 要素に対する再描画要求を無くす。背景画像は body 要素に。
• html 要素に背景画像を置いてしまう。body 要素で背景色を指定すると上書きされてしまうので background-color を transparent にする。body に padding を指定しておかないと駄目。

それにしても、久しぶりに Windows を起動したなぁ。使いにくさ抜群。せめて HHK 繋いで使ったりしないと typo 多すぎ。;)

でも、やっぱり GUI な見た目の確認には、速度も速くて Windows の方が楽。常用はできないけど。

W3C HTML と ISO/JIS HTML では、文書構造という言葉自体が示すものが明確に違うため、ISO/JIS HTML な理論を無理に W3C HTML に適用する必要はないのです。

W3C HTML は DOM を視野にいれたツリー型の文書構造を持ちますが、ISO/JIS HTML の場合にはそれを考えていません。というか、考えていたら body 直下にしか置けない見出しなんて発想は出てきたりはしないでしょう。

そもそも、ISO/JIS HTML の概念だと XHTML 2.0 で予定されている section/h なんて実現不可能ですね。

まぁ、方向性が違うのでいいのですが。

色々見直したりしていたのですが、Mozilla/IE/Opera の実装差違ありすぎ。

Opera だと、* { font: normal normal normal medium / normal sans-serif; } しておいて em で何もスタイルを指定しないと、em 要素が斜体表示。これは IE6 でも問題ないので Opera が負けてる珍しい例。

Mozilla だと、* { cursor: auto; } しておくと、a 要素でも text な pointer になってしまうので、a { cursor: pointer; } しておかないと悲しい。

ついでに、非常に基本的なスタイルのみを指定したテンプレートスタイルシートを用意してみた。

とりあえず最初にこれを @import してから見た目を自分の思い通りに指定したら、XHTML 2.0 Ready になるかなぁ?

FreeBSD Mall CEO の Bob 訪日によりインタビューがある、ということで参加。興味深い話を聞くことができた。

その後、まぁ、飲み。非常に興味深い話を聞くことができた。:)

(ご) さん、楽しすぎ。

i-mode 端末とかでは XML 宣言が見えた記憶があります。自分のサイトを見て悲しくなってみたりしました。でも、使う。

将来的には解決すると思っているので気にしていません。ソースが表示される、というレベルよりはマシですし。

Windows CE の Pocket IE も怪しいという話をどこかで目にしたような。

部活動～。満足して帰途に付いたものの、家が近付けば近付くほど憂鬱に。ん～、Mozilla やりたくない～。

んでも、非常にモチベーションを上げる話があるので、がんばります。うは。

冷蔵庫、電子レンジ、洗濯機、乾燥機、ベッドが到着。いきなり部屋に生活感が出てきた。

とりあえず洗濯してみる……うわ、乾燥機万歳!

太田さんから赤紙が来たのでさくっと波田野さんに声を掛けて部活動。

結局 6 人にもなっている辺りが素敵。ご飯を食べた後の部長も参戦。部長、強すぎです。

しかし、結局 2 日連続のしゃぶしゃぶになってしまったなぁ。(^^;

手拔きパーサで處理出來るやうにXMLではタグの省略が意味もなく一律に禁止されたというのも変な話です。

複雑な SGML の規則を、より単純にすることで解釈を一定規則に従って簡単に解析することができるようにして負荷の軽減などを目指したのですから、本質的な部分を意図的に悪い方向で解釈しているようにしか感じられません。

複雑な HTML をまともに解釈できない手抜きパーサや適切な HTML を出力できない手抜きオーサリングツールによって生成された腐った HTML を必死に修復させて解釈するよりも、XML ベースでソフトウェア的に完全に一定のルールで出力させることで、HTML を何らかの形で処理する場合に、あらゆるソフトで容易になるという大きな利点を考えないのはどうかと思われます。

HTML は元々ソフトウェア的に解釈させる事を目的としているのですから、その点では ISO/JIS-HTML は XML よりも解釈が単純に行えない点で劣っています。これは W3C HTML も XML ベースではないので当然一緒です。

マークアップの表現力の点で言えば、XHTML でも不足だという方も居るでしょうけど、それは XHTML 1.1 や XHTML Basic で要素を拡張したら良いだけの話。そもそも XML でなら全く困るわけもなく。ま、当然自分で DTD 書いてもいいですし、 well formed XML で済ませてもいいでしょう。

ISO/JIS-HTML の見出しによる判別処理は、人間が解釈するにしても、コンピュータが解釈するにしても余剰処理が発生するのはあまり優れた規格とは思えません。

HTML はあくまでコンピュータが処理するデータに過ぎないので、如何に人がマークアップしやすいか、文書データをそのまま理解しやすいか、なんてものは関係ありません。もっとも、文書データをそのまま理解しやすいのは明らかに XML/XHTML だとしか思えませんが。

XML の、単純明快な書いてある通りに理解と、ISO/JIS-HTML の見出しのレベルにあわせて div[1-6] が暗黙的に存在するルールを理解した上で、適用範囲を考えながら理解するのとではどちらが容易でしょうか。

現状を考えるならそもそも XHTML 1.1 で問題がある UA は希少ですし、汎用性の面では XML を踏襲している XHTML 1.1 の方が圧倒的に上です。ISO/JIS-HTML では XSLT 通してサクッと変換することもできません。

HTML 4.01 Strictで明示を「省略して良い」とされた要素がどうして「省略して良い」のかと言われていますが、単純に DTD で省略を許しているからです。これにより暗黙的な終了点の検出を行う処理が必要となり、XML では必要のない処理が発生することになります。

HTML では DTD を解釈しない限り、その文書が Valid であるかを評価できません。XML ではそれが不要となります。これは UA の負担を軽減します。

HTML 4.01としてはinvalidになつても構はない、と云ふ事で作られた「新しいHTML」であるXHTMLとされていますが、XHTML 1.0 は HTML 4 との互換性を確保しているが為に拡張ができなくなっています。どの辺りに invalid になっても構わないとされているのでしょうか。

内容に基いて要素が定義されてゐると云ふ點ではXTHMLよりも優れてゐるという結論は少し無理があるかと思われます。

ソフトウェア的に解釈させるためのマークアップである以上、無いように基づいてマークアップした場合には、同じ要素定義であれば全く同一の (もしくは書式的な差違しかない) マークアップにしかなり得ません。

仕様的にどれだけ厳密に決めてあろうと、また緩く書かれていようと、最終的には全く同一のものとなります。

WWW 上のリソースは、W3C の方針では XML を基盤とした技術に持っていくことを考えています。ISO/JIS-HTML を現段階から広めることは WWW の世界を Classic な時代に引き戻すという点で、非推奨というのは間違いないことでしょう。

ちなみに、ISO/JIS-HTML は私的には deprecated どころかむしろ obsolete という勢いですけどね。W3C HTML 4/XHTML 1.0 も当然 obsolete です。

XHTML は、既に世界中の XML パーサを UA として対象としているのであって、XHTML をまっとうに解釈する UA は世界中に非常に多数出回っています。

XHTML の対象が WWW ブラウザだけであると考えるのは、その時点で視野狭窄に陥っているとしか思えません。

また、逆にこれを理解していっているのであれば、目的も違えば対象も違うもので、どちらが優れているのかという話を延々としていることになります。鉛筆と F1 カーではどちらが優れているか、という話は馬鹿らしい話です。

WWW 上の文書としては今後 XML ベースの方向性で進めていくことになっていますから、ISO/JIS-HTML の普及を薦めることは W3C 的に見たら妨害でしかありません。

というか、ISO/JIS-HTML 的には、Pre-HTML モードでなければ h2 要素の次が h5 要素でもいいわけで、これについては W3C XHTML/HTML と何ら差がありませんし、Pre-HTML を有効にするのと XHTML 1.1 による拡張を行うのはなんら差がないようにも思われます。

あと、個人的には、XHTML 1.1 よりも UTF-8 の方が非対応ソフトウェアに対してやさしくないと思います (ぴゅあ)

波田野さんよりお誘いがあったのでさくっと行く。麦とろ飯うまうま。

なぜそうなのか、という点は SGML ベースでは UA の作りが複雑になってしまうから XML を作った、という一点で説明されませんか。

という点は引用点以外で説明しています。

既に XML ベースで動いているか、というと、実際のところ、大勢はもはや XML ベースに移ってきています。表にでてくるリソースではなく、サーバサイドの裏で流れているデータが、ですが。

実際のところこれが一番重要な点だと思いますが、WWW で UA によって参照されるリソースは、結局 UA が解釈するという事です。

サーバサイドで、表から見えないデータが既に XML で取り扱われている状態で、さらに他のリソースとの連携を取ろうとした場合、XML ベースであれば XML パーサが 1 つあればそのまま処理できますが、ISO/JIS-HTML (や legacy な W3C HTML) では SGML パーサが別途必要になり、そこからまた擦り合わせが必要になります。

これは無駄が多くなりますし、当然 UA 側も複数のパーサを実装しなくてはならなくなります。

DOM を利用した統一的な文書操作も legacy な HTML では難しくなりますし、そういう点からもお薦めできるものではないです。

ちなみに、W3C を知らない人は、JIS はともかく ISO も知らないのでは。

某コミュニティ関係者の中で、W3C はともかくとしても、IANA、IETF、ICANN、ECMA とかなんてどれだけの人が知っているのだろう、とか思ってしまいますし。

まぁ、それはともかく一般的なウェブサイト制作代行會社で W3C を知らないとか、そういうのは確実に怠慢以外の何者でもなく、そういうところは早く淘汰されて欲しいものです。

「なぜW3Cは、HTML 4.01で一部のタグの記述を省略出來るやうに定義したのか」を、どうして答へて貰へないのですかーって、当事者以外答えられないから、我々 (誰) は誰も答えられないでしょう。

www-html@w3.org 辺りで聞いてみるとか。

Semantic Web の世界は HTML などの WWW とは別に構築される世界です。メタデータの世界ですから。

意図の読み取れないマーク付けというよりも、マーク付けされた区間が文書を見た瞬間に即座に分からないのは好ましくない、の様な気がしました。

それは無いと思うっす。逆にJIS、ISOは知っている或いは聞いたことがあるけれど、W3Cって何、って人の方が多いような気がするっす、世間一般的には。

名前だけではなく、それがどういったものなのかとか、そういう意味での知っていないので、です。

某引越業者の CM で ISO を取ったのよなどという、訳の分からないセリフを吐くものがあります。似たような認定を JIS が行っていたとして、JIS を取ったのよ、なんていう言葉が国内で放送されるでしょうか。

14000 番台とかさえも言わない。この辺りで、ISO の一般認知度はその程度だとしか思えないのです。ま、例が悪いとも思いますが。;)

W3C なんて知らないけど、ISO というと何となくありがたみを感じてしまう、というのは結局 ISO がどういう事をしているのか、おぼろげにでも知っている人だけですし。

ISO-2022-JP にありがたみを感じられると微妙ですが。ISO-2022 に準拠してないし。

ISO が何、とかは、やっぱり関連している人しか分からないでしょうけど、そういう意味では、WWW に関わる業務に携わる人などが W3C を知らないというのは、日本で工業製品作る人が JIS を知らないのと同じ位、駄目なことでしょう。

何か思ふんですよ。この論争ッて、FreeBSD vs Linuxと云ふ構図に似てゐるなあと。

FreeBSD と Linuxは、源流は同じUnixだし、其処から分化してゐるんでせう。

ダウト。4.4BSD-Lite2 起源の FreeBSD と、kernel しか存在せず、それも別に何らかの Unix と呼ばれる血を受け継いだソースを持っていない Linux とを比較するのは変です。比べるなら RedHat Linux とかの distribution レベル。

そもそも Linux は当然として、FreeBSD も Unix でさえ無いです。認定通ってませんから。

という事で、Linux は分化ではなく、新しく起こされたものと見るべき。

HTML の最進化形という認識自体がまず違うと思われます。

ISO の考えたポリシーによって W3C HTML 4 を元に作られたものが ISO/JIS-HTML 4 であるに過ぎません。

ところで、User's Guide to ISO/IEC 15445:2000(E) Copyright notice を見ると、このユーザガイドは GPL version 2 もしくはそれ以降で配布されるそうなのですが、つまり書き換えて再配布しても構わないって事でしょうか。

というか、そもそもフリーソフトウェアなのでしょうか。This guide is free software とか書かれていて微妙な気分なのですが。

実行すると local な HTML が ISO-HTML 4 に書き換えられたりするのでしょうか (違)。

ちなみに、GNU は文書配布のためのライセンスも規定しています。普通、分かってるならこっちを選択する筈。この User's Guide 書いた人間は、単に GPL 言いたかっただけ (略)。この時点で脊髄反射的にこの User's Guide はステ、と言いたくなりますね。

OS/2とWindowsNTと云ふ比較は如何。

いい比較です。流れも似てますし。

反応しようとして、とりあえず取得し直してみたら文書更新されてるし。

一應、DTDを配布する、と云ふ事で、プログラムのライセンスを取敢ず採用したんぢやないですか。HTMLはともかく、SGMLは言語記述言語ですからねえ。で、「ISO-HTML」ののDTDをオリジナルのSGMLアプリケーションに「組込んで」使ふ事を仕樣策定者は考慮してゐるみたいです。

と言ふか、ISO/IEC 15445:2000のユーザガイドは、仕樣そのものではないのですが。

ちと論点がずれてますね。

こうしたユーザガイドは書き換えることを禁止して配布すべきものでは、というところが重要です。勝手に書き換えて不思議マークアップ推奨なユーザガイド化して再配布されても文句が言えないライセンスを選んでどうするのでしょうか。

ISO/JIS-HTML ステではなく、このユーザガイドはステと言っているのは、この意味です。

GPL を選択した人間を小一時間程タコ殴りにしてください。

ところで、この部分は div2 クラスの様ですが。

レベル的には他の div3 クラスの内容と変わらない筈なのに。

ISO-HTML User's Guide の話は、ISO-HTML の話の中でたまたま見つけただけであって、ISO-HTML とは完全に別件ですから、一緒の話とされても困ります。

User's Guide が駄目だから ISO-HTML が駄目だとは言ってませんし、そもそも私は ISO-HTML が駄目とは言っていない筈ですが。

新規文書として起こす場合や、他のアプリケーションとの連動を考えると XHTML の方が圧倒的に有利であることや、W3C の方針的に今後 WWW の世界では XML を基盤とした技術に進んでいくので、新規に ISO-HTML を勧めることいいことではない、と言っているに過ぎません。

既存の文書を全て最新仕様に合わせて書き換える必要がないのは当たり前のことですが、新しく作成する文書では新しい規格を使った方がいいよね、というだけの話ですので。

だから別個に div 切ったのになぁ。heading 付けないと駄目ですか。

日記データを完全に XML 化し、XSLT を通して整形してみるテスト。

当然、更新されているデータだけ XSLT を通して XHTML 化してみる。この日記が公開されていれば、ok ということです。

ちまちま進めてた伝説のオウガバトル、ようやくプリンセス + リッチ部隊を作成。

うわ、極悪なほど強い……。全体攻撃魔法 6 回ですか。

おお、自分で DTD 書いてる……と思ったのですが、なんというか……。

なぜ ISO-HTML が本来の策定しようとした Pre-HTML ではなく現在の仕様の ISO-HTML を踏襲したものにしようとしたのかが疑問。それこそ Pre-HTML を現実化した方がいいのでは。

後方互換性など、それこそ XSLT による変換で ISO-HTML 化して出したら良いだけの話。

あと、%h[1-6].content; よりも、それこそ %div[1-6].content; じゃないかと思いました。その名前だと h[1-6] の内容にしか見えないので。

PUBLIC なの? SYSTEM でいいんじゃない? とか思いました。

それと、基盤アーキテクチャは XHTML 1.1 なのだし、あまり XHTML Basic のサブセットという感じがしません。まぁ、名前付け規則が XHTML Basic でも XHTML 1.1 でも無い辺りで違和感が (prefix 辺りが特に)。

しかも、この場合、ソースが表示される、とか XML 宣言が表示される、などといった生易しい問題ではなく、「ページが表示出来ませんでした。」と表示されて、ハイそれまでよ、なのです。

なるほど。要約すると Handheld PC 2000 などに標準添付されている Microsoft Internet Explorer 4.01 for Handlheld PC はタコだと言うことですね。

しかし、私は UA 依存の問題、特に実装バグについては放置の方向で作成しておりますので、なんらそういった点を意識するつもりはありませんし、その必要は感じられません。

そういう UA を敢えて利用する方は、特定のサイトだけが対応したところで他のサイトが対応しなければ何の意味もないことです。

むしろ、そういった問題を Microsoft などの UA 製作サイドへ指摘し、対応するように強く働き掛けることが最重要でしょう。

とりあえず逃げる手段としては、XHTML 1.x to HTML 4 gateway などを作成して表示されるようにするとか。

i もちろん、「だから XHTML はダメだ」などというつもりはないですけど。

どう見ても IE4.01 for Handheld PC がダメだという受け取り方以外できないと思うのですが、どこからこういう言葉が出てくるのでしょう?

XHTML が XML であるがゆえの制約というものが一切記述されていない為に非常に不可解な文章になっているかと思われます。まぁ、書き殴りらしいので他人に伝える意図を盛り込むという点では、どうでもいいのかもしれませんが、制限と感じるものが数多いという割に何も挙げていないのでは、説得力がないです。

こくぶんさんの言われている文章は、そのまま情報処理用に利用するリソースとしての SGML の欠点として挙げることができます。

つまり HTML は SGML の制約を受けることで、より簡素な処理系において容易に処理することができないため、thin client で対応するにはあまりにも大変なものである、という事です。

SGML で問題がないのであれば、そもそも XML なんて作られなかったでしょうし、簡素化することのメリットが大きいと感じられたからこそ、XML が生まれたと考えます。

まぁ、もっとも「あなたの考えは間違っています」的な反論はご遠慮下さいらしいので、間違ってる部分を指摘するのは意味がないらしい。

おまけ。ISO-HTML における address 要素は節や章ごとに付けることを前提として考えられており、必要な部分にだけ挿入されていることから、考慮漏れというよりも、むしろ良く練られて考えられた結果だと思われます。

文章がセクションを構成せずに持たれるということを想定していないというか、文章はセクションを構成して持つべきである、という形で %section.content; が (%block; | %text; | ADDRESS)+ と定義されたのであろうと、DTD からはその意図が見えるからです。

address 要素は div 要素に入れないと使えないのではなく、address 要素は文書の一節一節の中に現われるものであって、それらの節は div 要素によって明示されるべきものである、という解釈の方が素直であるように思われます。

理解されましたか。では、ぜひ説明して頂けませんか。マジでさっぱりわからないので。

本当にフラットでリニアな文書だったら text/plain で十分という話にしかなり得ないと思うのですが。それこそ HTML 2.x i18n から更新される必要が無くなります。

ただ、ひとつだけ気になったのは、とりあえず逃げる手段としては、 XHTML 1.x to HTML 4 gateway などを作成して表示されるようにするというのは、全てのアプリケーションを限られたメモリ上に展開しなければならない Handheld PC 上ではかなり厳しいと思います。いや、これは私にそういった API を作成する技量がないだけなのかもしれませんが。

global network 上のリソースを対象として話をしたつもりだったので、Delegate の様な proxy server の感じで言ってました。

別に相手に理解を求めないなら相手を説得する形で表現する必要はないかと思います。

で、通常作成するドキュメントを情報処理用に利用するリソースとは思っていないそうですが、UA に食わせることを前提にしていたらその時点で既に情報処理用のリソースだと思いますが。

節を div で明示する手法が賛同できない、という事ですが、では div はどういったものだと理解されていらっしゃるのでしょうか。

div 要素は division を明示するもの以外の何者でもないですし、私はむしろ仕様書のスタイルコンテナであるという考え方自体が違うだろ、と考えています。それこそプレゼンテーションが文書構造に混じり込んできているいい例です。

日本語の文章で考えた場合だと、p 要素は形式段落を示して、div 要素は意味段落を示す、と考えると非常に素直に、全ての p 要素は div 要素に含まれる形になると思います。

これは、ISO-HTML で見出しが body 直下に書かれる必要があることと、なんら矛盾はないのでは。

私には、節を div で明示しないことについては、ISO-HTML が h[1-6] の順序規定を、W3C HTML との互換性を最大限に維持したままで行おうとしたツケが div 要素による節の明示というマークアップを殺してしまっているように思われます。

Pre-HTML to ISO-HTML の間で殺されたのは div[1-6] であって div 要素ではないのですから、それはやはり節や章を明示するためにマークアップした方が良いと考えます。

機能的に見た場合には、特定の一節だけを抜き出したいという処理を行う場合、単純に div 要素 1 つを抜き出すだけで良い、という形になっている方が処理しやすいよね、という点で div 要素に見出しを含める方が優れていると思います。

あまりに過剰にマークアップする必要はないと思いますが、マークアップしなさ過ぎるのも、マークアップをする目的自体がそもそもソフトウェア的に処理するためであるという点を忘れ過ぎるのはどうかと思います。

その目的を考えたら、ソフトウェアができるだけ容易に処理できる形でマークアップを行うのが自然で、かつ当たり前の事ではないのでしょうか。

HTML ってどういう物なのかを簡単にまとめてみるメモ。

インターネット上における定義といったら、とりあえず RFC からになるでしょう。ということで、RFC2854 辺りを参照してみます。

これは、text/html メディアタイプとはどういうものかを規定しています。

RFC2854 における規定では、全ての HTML ファイルは、ファイルの先頭付近に <html もしくは <HTML という文字列があります。

また、XHTML 文書の場合には <?xml から始まる XML 宣言から始まることができ、(XML 宣言を行った場合はその後ろに) <!DOCTYPE html から始まる DOCTYPE 宣言 が必要です。

また、これに加え XHTML の場合には RFC3236 によって application/xhtml+xml が規定されています。RFC3236 は RFC2854 への追加の様な内容ではありますが、基本的に RFC2854 を (Obsolete したり、という意味で) どうこうするものではありません。

これによると、RFC2854 と同様に、XHTML 文書ではファイルの先頭付近に <html という文字列があり、先頭には <?xml から始まる XML 宣言を付けることができます。

さらに、XHTML 1.0 文書ではルート要素は常に html となり、モジュール化 XHTML やそのサブセットに適合した XHTML 文書では、"//DTD XHTML" という文字列を含んだ DOCTYPE 宣言を行います。

全ての XHTML ファイルは、html 要素に XHTML 名前空間 (xmlns="http://www.w3.org/1999/xhtml") を指定するのが望ましい、とされます。

上記内容は、RFC2854 5. Recognizing HTML files と RFC3236 5. Recognizing XHTML files を元にしています。詳しい内容は各 RFC を参照してください。

インターネット上の HTML 文書は要約すると以下のような感じでしょうか。

• text/html もしくは application/xhtml+xml メディアタイプを持つリソース。

• ファイルの先頭付近に <html もしくは <HTML という文字列がある。

• XHTML の場合には XML 宣言を行ってもいい。DOCTYPE 宣言は必須。DOCTYPE 宣言は選択したバージョンに応じて適切に。

• XHTML では名前空間を指定する事が望ましい。

つまり、W3C HTML 4 など仕様に存在する HTML 開始タグの省略が行われる事は、インターネット上のリソースとしては適切ではないことになります。

しかし、HTML 文書は別に、常にインターネット上に存在するリソースではなく、ローカルホスト上に置かれていたりするものでもありますので、この場合には別に text/html メディアタイプの要件を満す必要は無いので、W3C HTML 4 Spec. にある通り、HTML 要素の開始タグを省略してもなんら問題はありません。

ただし、インターネット上にそのリソースを出す場合 (例えばメールに添付して text/html メディアタイプが付けられる場合) などには、HTML 要素の開始タグは必要になりますので、最初から付けておいた方が何かと簡単でしょう。

なお、W3C HTML Spec. には権威がないのか、という点については、IETF HTML WG が 1996 9 月に終了し、W3C に移管されたという経緯を考えれば、インターネット上においては十分な権威があるようにも思えます。まぁ、もっとも、RFC や IETF を尊重しない人には関係無いでしょうけど。

なるほど、それはツリー構造から見たら平坦に見えますね。で、Pre-HTML で目指した div[1-6] による文書階層構造が暗黙的に行われることにより、表面上フラットに見えるだけでしかない ISO-HTML の現状を鑑みて、それが本来 ISO-HTML が目指した姿なのでしょうか。

マークアップするという事は、構造を明示するという事に他なりません。つまり、暗黙的であっては意味がないのです。

japanese/another-htmllint が 2001/ 9/11 版のまま更新されてなかったので 2002/ 3/ 5 版を作ってみました。

ただし、htmllint.zip を拾ってきて、distfiles に another-htmllint-20020305.zip と名前を変更して置く必要があります。

追記。ん～、あんまりネタには見えなかったので念のためです(苦笑)。どっちかっつーと、「嘘撒き散らし文書」に見えますね。日頃まじめな文章を書いている人がその流れの中でまじめな論調でネタを書くとネタとうけとられにくい傾向があると思います。そして、日頃からネタ満載な人はその逆があるわけですな。そうですね、ネタにするのならもっとネタっぽく扇るような文章にして、文中に「(ぉ」とか散らしておくのがよろしかと……。安全のため最後でネタだと明示しておくのもありだと思います。

がーん。全然ネタに見えませんでしたか。というか、嘘撒き散らし文書は不本意だなぁ。もうちょっとネタに見えるように書くべきでしたね。すいません。

やっぱりマークアップレベルで明示するか。スタイル用意しないとなぁ……。

以下はややまじめにフォロー。「で、識別のための～」ですが、もちろんならないと思います。「W3C/ISO (X)HTML Spec. を満していない HTML 文書ファイル」を text/plain と見なすのは乱暴です。つーか、そんな可読性の低いもの、text/plain に対して失礼だ(苦笑)。「text/html を意図したけど壊れている文書」ですよね。

うは。確かに失礼ですね (笑)。

正しくない HTML 文章はレンダリングする必要が無い、というのは正論ですが、そのエラーを指摘してくれるほうのがより良いアプリケーションだとは思います。エンドユーザは、もう、経験的に既存ブラウザが「正確には間違えている HTML」でも表示してしまうことを知っていますから、画像なら文句を言われないことを論拠に、HTML でもそうできるか、というと、それは難しいですねぇ。そんなブラウザ作っても、よっぽど他に魅力が無い限り、多くの人からは見向きもされないことでしょう。残念ながら、「text/html」は、もうよごれっちまったフォーマットだと思います。「application/xhtml+xml フォーマットだと思います。「application/xhtml+xml」ならまだ大丈夫でしょうけど。

iCab 辺りは Valid では無い場合にエラーの報告をしてくれた記憶があります。Mozilla の場合には、Piro さん作の Mozilla 拡張 extension を利用することで、Another HTML-lint に飛ばすことでチェックできますが、これはパース失敗を報告するようなものでもないので、ちょっと性格が違いますね。

text/html は汚れちまったフォーマットですか。確かに世界中の人に寄ってたかって汚されまくったフォーマットなので、今からクリーンにするのはほぼ不可能と言えます。IE や Opera がそんなことをしてくれるとは思えないので (Opera はまだ期待できるかもしれないですが、要望上げないと無理でしょう) Mozilla の Gecko エンジンにそういった機能を組み込むのはアリなのかも知れません。

…… Gecko のソース読みたくないなぁ。Necko と NSPR だけで精一杯。

おっしゃることは理解できます。とは言え、何らかの特別な処置を取っていない限りは、私のサイトのみならず、日記サイトに共通して起こる悩みの一つではないかと考えられます。

そういう面倒くさいことを自動でやらせるための、コンピュータだと思います (ピュア)。

先日まで XHTML で直接最新部分の日記だけ書いて、それをスクリプトに食わせてアーカイブに自動反映させてから更新日時を付け、それを WWW サーバへ転送するまでを一連のスクリプトにしていました。

これでも面倒なので、今は日記用 XML データを XSL 変換させて XHTML 文書として出力し、この出力結果に対して連結情報 (link 要素の next/prev 連結情報) と更新日時を付けて WWW サーバへ転送するまでを一連のスクリプトにしています。

日記の文書部分は自由度のために、敢えて XHTML 直接記述にしていますが、えらく楽になりました。構造もシンプルですし。well formed でもサクサク処理できる XML 万歳。

こういった事をされている方はまだ少ないと思いますが、結局日記用スクリプトなどが出てくるのも、こういった理由からではないでしょうか。

これだと自分でログ管理する必要なくなりますし。

私は WWW サーバに負荷をできるだけ掛けたくない、という事からこうしたものの採用は見送り、静的コンテンツとして出しています。

ん、1 日毎の文書化もできるか。ちょっとファイルが多くなりそうで嫌だけど。

現行の Mozilla の実装では名前解決の問い合わせ順序に問題があるので、getaddrinfo ベースに置き換えないと駄目なのですが……はぁ、進まない。というか、進んではいるのだけど、終わりが全く見えない。

とりあえず NSPR に getaddrinfo を呼び出す wrapper 部分を作って、nsprpub/pr/tests に getaddr テストツールを作成。まぁ、ここまでは良し。

とりあえず基本は DNS の問い合わせを司る部分だよな、と思って netwerk/dns 以下をまずやるべきだよな、と思っていたのに、妙なコンポーネント独立のお陰で各モジュールに名前問い合わせを行う処理が散ってる散ってる。

別コンポーネントはまぁいいとしても、netwerk 以下で DNS サービスを使わずに名前解決してるのはどういうものかなぁ。

セキュリティの話で結構見落とされるのが物理的なセキュリティ面というのは有名な話です。サーバの電源ケーブルを掃除のおばちゃんが抜いていたせいで毎朝定期的に落ちていた、なんていう笑い話もあります。

ということで、やはりここは我らが djb 先生に出てきてもらいましょう。

• 従来のエンドユーザは安全ではありませんでした。djb エンドユーザを使用しなさい。
• 従来の Internet Explorer は安全ではありませんでした。djb Internet Explorer を使用しなさい。
• 従来の Windows は安全ではありませんでした。djb Windows を使用しなさい。
• 従来の刃物は安全ではありませんでした。djb 刃物を使用しなさい。
• 従来の自動車は安全ではありませんでした。djb 自動車を使用しなさい。
• 従来の住宅は安全ではありませんでした。djb 住宅を使用しなさい。
• 従来の人間は安全ではありませんでした。djb 人間を使用しなさい。

そして世界の安全性は確保される。ん、嫌な世界だ。

build 時に freetype 辺りで syntax error が出る場合、freetype 1/2 を入れ直してから再度チャレンジ。freetype 1/2 の header file 辺りの入る先が変わるので、build が通るようになります。

Mozilla.jp のトップにも書いておきました。

なお、italic font 回りの問題に対処する patch が追加されましたので、この辺りが気になる人は再度 build することになると思われます (お。

いい加減見ようかな、と思って DVD を再生できる環境を整えてみました。

xine 0.9.8 では再生できるものの、途中で絵がぴたっと止まってしまったりしてちと悲しいので、しょうがなく Windows 2000 に入っている PowerDVD 2000 で試してみたところ、再生ボタンを押したら、表示領域のサイズ調整が行われた後、CPU 使用率 100% になって固まってしまう。げふ。

Windows Me に入れてみても駄目。ドライバ入れ直してみても駄目。試しに十戒の DVD とか入れてみると、さっくり再生可能。これは R.O.D 3 巻のフォーマットを PowerDVD 2000 じゃ再生できないのかな、と判断。

試しに PowerDVD XP 試用版を入れてみると、最初の 5 分だけ音が鳴ります、とあるのに音が鳴らない。なんだこれは。とりあえず映像だけは出る模様。

諦めて xine で繰り返し見るかなぁ、進めたり巻き戻したりすると core 吐いて落ちるからなぁ、と思っていたら WinDVD 2000 発見。B's Recorder GOLD とかと一緒に入っているとは迂濶だった。

で、駄目で元々、突っ込んでみたら WinDVD 2000 でさくっと再生 ok。PowerDVD XP 買わずに済んで良かった良かった。(^^;

無事 R.O.D 3 を 2 回 (主音声と副音声) 見られたので、これでようやく Ys とか M:I-2 とか見られそう。

……うぅ、おもいっきり寝過ごして行けなかった……。

ということで、ごー。無事合流できて、mutoh さんともお会いできました。良かった。

UFS_DIRHASH を高速化する code が 5-CURRENT に commit されたので、早速 build してみる。

結果、Sylpheed で Crusoe 600MHz な PC-SX1-H1 で cvs-all@FreeBSD.org などの、メールが 2 万通程入ったディレクトリを開いたら、10 秒掛からずに開きました。

うお、加速度高すぎ。効果めちゃめちゃ高いです。これは幸せ。

近日中に MFC される予定なので、4-STABLE ユーザも近いうちに幸せになれそうです。

たまたま Mozilla の Related Links から見つけたコンテンツなのですが、結構いい感じのものを見つけました。

だれもが読めるホームページを作るコツが出てきたのですが、だれもが読めるように - ぱそ工房ばうの説明は、とりあえず最初に読むにはいい文書かも知れません。

NiAOU さんトコで告知されていた通り、大阪に行ってきました。

天才に会ったり神が降臨したりと、なかなか楽しげでした。

何か、久しぶりに仕事らしい仕事をした気がする。

こんなんでえぇんかいな。

言葉だけだと、新潟出身とかとは見られてなかったらしい。

まぁ、確かに新潟市辺りだと全然訛りとかって無いからなぁ。

ZD Net エンタープライズの記事でトレンドマイクロ CTO が言う事には、.NETやXMLは，（一般の開発者だけでなく）ウイルス作者にとっても最適の環境だそうで。

これって、IE や HTML はウィルス作者にとって最適な環境だとか、Microsoft Java VM や Java はウィルス作者にとって最適な環境だとか、Windows や C/C++ はウィルス作者にとって最適な環境だとか、そういう置き換えが可能な発言に見受けられます。

.NET 側に脆弱性が見つかったから、それを基盤技術としている XML も危険なものだとみなすこの文章は、ものすごく不快でした。

正直、こんな人が CTO なのでは、トレンドマイクロダメダメかぁ? とか思わされましたよ。

.NET + XML では危険、であればともかく、さしたる根拠もなしに .NET || XML は危険、ではねぇ。

そんなに危険なのであれば、トレンドマイクロ製品を購入して防ぐよりも、djb .NET を作ったほうが余程安全で根本的な解決になってると思いますよ。:-p

Microsoft から C# や CLI のソースが公開されたらしい。

らしい、というのは、どこから落としたらいいのかさっぱり分からないという罠の為。試してみたいのだけどなぁ。

w3m から見ると、MSDN に行ってみてもどう辿ったら拾えるのか、正直言ってさっぱりわかりませんでした。

あぁいうのが、アクセシビリティが低いサイトの典型なのかな。

今日は肉体会でした。酒と肉でお腹一杯。しあわせ～。

明日は murashin さんの送別会。遅れずに行けるかなぁ。(^^;

CATV 会社の方が来る時間が前倒しになったので、予定より早く八王子に向けて出航。

お花見から参加できたので良し。

中華料理屋は金額の割に料理が美味しかったですね。歩きではちと行きたくない距離でしたが (^^;

あちらに行っても、健康に気をつけて頑張ってください。

今日は秋葉原で SUPER BELL"Z のミニライブだよ～、とのお誘いがあったので出航。

並走区間はやっぱりレースなのですね (笑)。

6 月は鉄道模型展参加決定してみるテスト。

安かったのと、ようやく見つけた、という事で新しい PC を購入。いやぁ、探してましたよ、FDD 付き MSX2。

これで実機で、既に購入しておいた Wizardry が出来ます。