このページのもくじ

  1. ドライバの対応
  2. 絵に描いた餅
  3. 見出しのid属性

なんだか、直ったような気がしています。黒キーボードを外して、パワーブックのキーボードを使っているのですが大丈夫みたい。涼しくなったせいか、そんな馬鹿な！

ドライバの対応

少々、贅沢と思いながら、購入した、CardBusUSB2.0PCカード。RATOC Systems製ですが。ドライバのダウンロードにユーザー登録が要るのは、何故なんでしょう？顧客情報を集めて、何かあるのか。まぁ、そのようなことはこの際、置いておきます。

MacOSX用のUSB2.0ドライバー。これがくせ者。一応、ニュースリリース、それから、対応表。ご覧になって頂いてわかると思いますが、（見なくて良いですけれど）、OSXのUSB2.0は、ほぼ全滅。ほとんど対応機種がありません。今後、対応が進んでいくんでしょうか？一応、職場のMOドライブ（IO Data,MOC2-U1.3）は大丈夫の様です。それから、クリップドライブも、使えていますが、ミノルタのフィルムスキャナ（Dimage Dual III）がまるでダメです。ドライバが立ち上がらなかったり、フリーズしたり。

新パワーブックにUSB2.0が搭載され、Ratoc systemsがこのPCカードのドライバ開発にどれくらい熱心になってくれるか、いささか不安に感じております。とにかく、スリープから復帰しない、というバグは何とかして欲しいねぇ。

絵に描いた餅

agendaのそふぃあさんから、改めてご意見をいただきました。これは、道具としてのパソコン（9月15日付け）段組レイアウト＞ページ構成を工夫するべき 、に対するコメントです。

仰るように、本来、日記等の記事は独立し得る単位で一個のHTML文書とすべきなのでしょうが、契約しているサーバによる制約（動的な生成ができず、少ない容量）を考えると、どうしても月単位等にせざるを得ないのです。ブラウザや検索エンジン等が、id属性を持ったブロックを一つの独立したリソースとして扱ってくれるようになればこの問題はクリアされると思っていますが、絵に描いた餅です。XHTML（application/ xml 系）ならともかく、HTML（text/html）における終点アンカー（またはフラグメント識別子）の定義はどうしようもなく物理的で、リソースの識別としての役割を果たしませんから。残念ながらこの悪習はXHTMLになっても受け継がれてゆくと思います（例：sectionではなく見出しにid、「ページの最上部へ移動」等々）。

ブラウザや検索エンジン等が、id属性を持ったブロックを一つの独立したりソースとして扱う、云々に関して、技術的にはよく知りませんが、割と簡単にできそうなことだと思う。むしろ、そういったことを全く意識せずに作られているおびただしいinvalidなHTML文書の群れを何とかする方が先決で、その意味でも、やはり「絵に描いた餅」という気がします。

フラグメント識別子について、私も多くのページで、見出し要素にid属性を付けて、フラグメント識別子としています。少々拙いことは自覚しており、このページでも、以前に一度、見出し要素からid属性を外して、記事の１日分をdiv要素として、id属性を付けようとしました。

ところが、スタイルシートを書き直す必要があることに加え、予め計画的にdivで括るならともかく、後付でそれをやると、至る所がdivだらけになり、大変見苦しい。また、整合性を取るのに苦労し、編集する上でも混乱するので、結局元に戻し、現在日付ごとにファイルを分割する道を選び修正中です。

見出しのid属性

また、見出し要素は、きちんとマークアップされていれば、見出しから次の見出しまでが構造的なブロックになっているはずです。すなわち、見出しの存在そのものが、文書の構造を暗示するような文書であれば、見出しにidを付けることは、（仕様書上は別として）閲覧者を混乱させるものではないと思うのです。

先ほどから、いくつかのソフトがフリーズしまくり、、、えー、USB2.0のPCカードを外したら、まともに動くようになったんですけど。これっていったい、どうなっているのでしょう？

調子の悪い原因は、複合的なもののようです。