うちのIE5.5は、実はIE6ベータなのではないだろうか。確かにバージョン情報では5.5と出るが、どうも6ベータの特徴がそのまんまだ。CSSの解釈が特に。
Leonard Cohen (英語)のアルバムをなくしてしまい、危うく発狂するところだった。幸い見つかったので正気を保っています（無関係）。
どうやら、Mozillaにて要素生成処理が異常に遅くなるのは、絶対配置（position : absolute, position : fixed）が大きく関係しているらしい。例えば、div等の親要素を生成した直後にstyleプロパティを弄って絶対配置にすると、この問題が起きる。
var nDiv = document.createElement('DIV');
nDiv.style.position = 'fixed';
ところが、子要素を全て生成し終わってから、同様の処理をした場合には、この問題は起らなかった。
var nDiv = document.createElement('DIV');
document.body.appendChild(nDiv);
var nDL = document.createElement('DL');
nDiv.appendChild(nDL);
--------------------------
nDiv.style.position = 'fixed';
お世辞にも速い、とは言えないものの、これでサイトマップ機能はMozillaでも実用レベルになった。と思う。
position : fixedの宿命と思って諦めるしかないような。そういうわけで、サイトマップ機能をMozilla対応にしてみました。
複数の要素を生成する場合、全ての生成が終ってからレンダリングを開始する（そうでなければ困るのだが）。
W3C CSS (英語)のデフォルトCSSがいつの間にか変更されている。このマークアップは変っていなかったけれど。
<div class="back"> <div class="section">
無意味に二重に囲むのは少しかっこ悪い。というより、面倒臭い（経験者）。それに、backってどうだろう。他の代替スタイルシートで表示すると、backでも何でもないというがちょっと。偉そうなことは言えないけれど、どういうクラス名が悪いかといえば、やはり永続性の無いものだと思う。そういう意味で、うちでは極めて抽象的で、どうとでも解釈できる玉虫色のクラス名をつけることにしたわけだが。なぜって、仮にSectionとかいうクラス名を付けたとしても、どうせブラウザは解釈してくれないし、再利用の方法によってはSectionにならないかも知れないから。
あれ？そんなことより、W3C CSS (英語)をMozillaで見ると凄いことになるな。と、書いている最中に強制終了。Netscape6.1でも見てみる。同じだった。スクロールが非常に重くなる。こういうのをスクロールと言って良いのか悩む程重くなる。なんてことだ……。以下、http://www.w3.org/Style/ に置かれているCSS。
とりあえず、これらはすべて保存しておいた。shadow.cssに、-moz-border-radius: 4em;なんて記述があるところを見ても、Mozillaを無視しているとは到底考えられないのだけど。古いバージョンで確認しているのだろうか。
それにしても、これはさすがにまずいのではないか。個人サイトではあるまいし。一番悪いのはCSSごときで強制終了するMozillaだけど。
原因は何だろう。position:fixedが絡んでいるような気がするが、複合的な要因があるはず。でも、こんなにもCSSを小分けにされていると確かめるのが面倒臭い。
もしかしたら、うちのサイトマップ生成処理があまりに遅すぎたのも、position:fixed絡みかも知れない。そうだとしたら、JavaScriptの処理が遅いわけではないのかも知れない。折角苦労してDOMLevel1準拠で作ったサイトマップ自動生成スクリプトが、Mozillaで実用に耐えないと分かった時はショックだった（＠9/3）からなあ。position:fixedを諦めれば、大丈夫なのか？
Googleのキャッシュには、以前のW3C CSSのスタイルが残っていた。こちらでは問題は起らない。
他所のサイトに、勝手にCSS規則を追加し、しかも勝手にクッキーを発行するスクリプトは、凶悪ながら中々強烈。
どうせ公開するなら完成度を上げたいので、しばらく色々なサイトで試してスクリプトの競合を減らすことにした。それと今のところ、宣言は幾らでも書ける一方で、セレクタは一つしか指定できないのでこれをどうにかしたい気がする。CSS Editorのスクリプトを流用しているから仕方ないのだけど、書き直すとなると「やる気」が保てるかどうか不安だ。
それにしても、定義しているclass、idの半分くらいが、CSSとは全く関係なく、DOMの処理のために存在しているのに気づいた。
bodyのclassなんか特に勿体無いな。コンテンツごとにデザインを変えるとか、CSSに反映してみようか。
一応、出来た。しかし、こんなに大変なものだと思わなかった。何がってバグ取りが。
新しい関数の追加方法は、自作オブジェクトのメンバーに追加するだけになった。ただ、innerHTMLを極力排除していったら、その分記述が増えまくったのでサイズは大して変わらなかった。これを何とかするため要素生成の汎用的な関数を作ることにした。どの程度出来るかは分からないけれども、このサイトのJavaScriptにも使えるはずなので結構やる気は残っている。
どうやらゼロから書き直す必要あるようだ。最初から思っていたが、今見ても酷い内容。ざっと見た感じでは、サイズを3分の1に減らせそう。
やる気が失せる前に、一気に仕上げてやる！
ユーザー発行のCookieを使って、我侭を追求してみる。
あるウェブサイトで、文字のサイズが小さいと感じたとする。このとき、ユーザーが埋め込んだJavaScriptによって入力フォームを呼び出し、適当なCSSルール（例body{ font-size:1.1em }）を記入する。ボタンを押してこのCSSルールをそのページに適用すると同時に、このCSSルールをクッキーに書き込む。次にそのサイトを訪れた時には、Cookieによって自動的にCSSルールをそのサイトに追加するため、適度な文字の大きさで表示される。例えばこのページが白すぎて眩しいと感じたならば、background-colorを好みに変更すれば、次回からその色で表示される。という具合。
あと、CSSを正しく記述しているにもかかわらず、こちらの環境のために生じてしまう「ブラウザによる表示バグ」を回避することが出来るだろうと思う。
CSSが好きでないと、面倒でしょうがないが、その辺は別にどうでもいいか。
他に、ユーザー発行のCookie使って何かもっと実用的なことはできないものか。頭痛がしてきたので寝る。
人を鬱な気分にさせたいのなら、かなり効果的な方法があります。もちろん私的にそう思うだけの話ですが。
内容は、感情を全く表さない日記。リアリティ溢れるものにします。一つのページの文章量は、読者を引き込み、息をつかせない為にかなり多めにします。そして――これが重要なのですが――背景色です。黒だと思うでしょう。そうじゃあないんです。虚無感を演出するには、どんよりとした灰色が最適なんです。また、灰色は最も目が疲れにくい色の一つです。読者を長時間ひきつけるに最適なわけです。文字色は黒または紺。背景画像はあっても無くても良い気がしますが、演出がわざとらしくならないように、或いは虚無感を更に演出するために使わないほうが良いかも知れません。
今日、そういう日記を見つけ、一時間ほど引き込まれてしまいました。内容はそれほど暗いというわけでもなく、しかし恐ろしく味気なくてなんとなく絶望感が漂っていて、また、単にアレをした、コレをしたという類の物でなくそういった出来事に交えて日々の思索が長々と綴ってありました。
IEコンポーネントブラウザfub。最近のバージョンでは、VirtuAlavenueで広告消しを行なっているサイトを開くと強制終了する。
まるで広告消しという行為を憎んでいるかのようで、実に気に入った。そういうわけで、VirtualAvenueドメインはポップアップ抑止用のURLに追加。ついでだから、f2sとかその辺も入れておいた。fubは調べものに使っているので多分困ることはないと思う。
超かっこ悪い馬鹿みたいなページ＠9/7
徹底的にこのスタイルシートを使いこなして作り上げた超かっこ良いページを、スタイルシートをサポートしていないブラウザーで見た場合、背景もない只の黒の小さな文字だけがびっしり書いてある、いわばメモ帳で見ているような感じの超かっこ悪い馬鹿みたいなページが表示されるはずです。
AGIC超初心者-14 より
珈琲を吹きそうになってしまった。それとも自虐なのか。
超かっこ悪い馬鹿みたいなページ
？これだ。決定的なギャップは。最近また「CSSは時期尚早」とか意味不明な判決を下している作成講座系（1つのこだわりホームページ講座）を見かけたが、やはり、デフォルトの表示を超かっこ悪い馬鹿みたいなページ
と思っているに違いない。
そう見えるのはね。そのページがスッカラカンだからなのですよ。内容的あるいは文法的あるいはそのほか諸々的に。
例えば、ENTERとだけ書かれた表紙。こんなのはブラウザのデフォルトで表示するとちょうかっこわるいばかみたいなページ
に過ぎない。
CSS否定論を展開しているサイトはなぜかFlashは否定しない。私的には、ActiveXがまともになるまではFlashの方が余程時期尚早
だと思う。私など、個人的に相当憎んでいるframe要素でさえ、きちんと否定論を展開するための前提を立てて、熟考したにもかかわらず容易に否定できなかったと言うのに、どうしてこうも簡単に否定してしまえるのか。そういうサイトは、ほとんど日記の愚痴レベルだ。意識が低すぎるよ。
JSウザいとかいう意見を見かけるたびに悲しくなるね。個人的にはCGIとかSSIとかサーバーサイド系が苦手。「見えない」から。JSはオフにすればいい。MIDIもアニメもそう。しかしSSIの処理は一方的なものだ。
しかし、なんでまたウザいという表現を全世界に向けて公開（？）しますかね。これほど幼稚な言葉もないと思うんですが。よく見る例、
「顔文字ウザい」
これは極めて滑稽なセリフです。自覚なき自虐です。
DOM実験室にて
見たくない人のために結論を書きますと、アクセスキーを無効にしたり書き換えたりするには、一度要素を消去して、生成しなおす必要があるようです。私は、複製して 置き換える方法を推奨します。IEはプロパティを書き換えれば良いのですが、Mozilla、N6は駄目です。
文脈で登場するアンカー（<a class="within" href="#foo">bar</a>）は、私はそれほど便利だと思わない。※印で補足説明をした別の箇所へ飛ばされると、集中できないことがよくある。かといって別窓で開くと、何故かページの最上部になってしまうことがある。
次のようなモデルを考えてみた。
<p> 当サイトでは、<a class="within" href="#css">CSS（※）</a>でレイアウトを行っています。 </p> ---------------------------------------------------- <p> <a id="css">※CSS</a>とはCascading Style Sheetsの略です。 </p>
CSS（※）という部分をクリックすると、ページ内の別の箇所に飛ばされてしまうわけだが、そうではなく、クリックした時にその場で説明がポップアップすれば、文章の流れを変えることなく、説明を参照することが出来る。
もっとも、ポップアップなどは珍しいものでもなんでもない。しかし、このHTMLに全く手を加えることなく、このようなポップアップを実現できるとしたらどうだろうか。そういうことを可能にするのが、Document Object Modelで、HTMLとJavaScriptの主従関係を完全に保存したまま、表示関係を処理することができる。
innerHTML）を変数aに格納する。2.が怪しい。説明がp要素ではなく、dt,dd要素でされていた場合、全く違う処理をしなければならない。だから、悪く言えばHTML文書の柔軟性を損なう恐れがあるが、しかし良く言えば文書構造に一貫性を持たせる動機となり得る。
何れにしろ、HTMLの文法を遵守していたとしても、汎用性のあるスクリプトを書くのは不可能に近いということ。一貫性のある美しいHTML文書を書くことこそ、Document Object Modelを利用するには大切なのだと思う。
人が何も意識しないで文書を作れるやうにしなければならない、と云ふ「信仰」は、好い加減、捨てるべき。コンピュータは意識を持たない。文章を書くと云ふ行爲が本質的に無意識の意識化の過程である以上、プログラムに全てを任せ切る事は出來ない。
delやins要素にも、cite属性があって、これは、追加や削除等、文書を編集した理由を示した文書へのURIを記述するものだという。一方、blockquote要素のcite属性は、引用元のURIを示す。
共通して、要素の由来を示す属性だと考えられないだろうか。またこれは、cite要素の解釈にも妥当な気がする。
positon:fixed＠9/32通りの選択肢があった。
まず、CSSのoverflowを利用する方法。しかし、これはHTMLの構造を変えなければならない。つまり、スクロールと連動させない要素以外を全て一つのdivで括らなければならない。さらに問題がある。背景画像を固定した場合と同じ問題が起るのだ。スクロールが重くなるのである。ホイールクリックで自動スクロールさせたとき、動きが滑らかでなくなってしまう。これはおそらくIEがCSSのposition:fixedをサポートしても残る問題だと思われる（推測）。
もう一つの選択肢。これは、HP-DESIGN.NETで配布しているELEVATING NAVIGATORような、setTimeout()等を使ったエレメントの再配置である。これなら、ほんの10行程度のスクリプトで済むし、スクロールも重くならない。何となく鬱陶しいのが最大の問題点ではあるが、止むを得ない。この方法を採用することにした。
他にも、イベントを利用して何とかする方法もありそうだが、イベント関係が良く分からない。bodyにonscroll属性をつければいいのだが、要するにJavaScriptで代替させるとしたらどうすればいいのか皆目見当がつかない。setAttributeでは多分駄目。addEventListener()が使えさえすれば。
また、あの重ったいライブラリを見に行かなきゃ。でも、W3C勧告の Document Object Model でやるからこそ、やりがいを感じているわけで。
ユーザビリティといえば、Albert Boxの新しい記事が出ていた。Alertbox: クリック率データを活用したウェブ広告デザイン（2001年9月2日）。これでつまらんアニメーション（または画像）広告が減ってくれれば幸い。もっとも、プロがテキスト広告の有効性を知らないはずがないから、問題は依頼主ということになる。しかし、「権威がこういうことを言っています」と示せるか示せないかは大きな違いだと思う。それにしても、Googleに広告なんてあったかな。
関係ないが、Personnel agenda で検索すると、.usドメインばかり引っかかる。やはりコンプレックスがあるんだろうな。日本人がタイトルを英語にするのと同じで……。うちもオマケでJavaScriptカレンダーでも付けてみようか。ほとんどシャレ。
Geckoエンジンの処理速度が実用に耐えない。div, h2, p, textNode, dl, dt×5, dfn×5, textNode×5 を生成するだけなのに5秒かかる。なんとかならないかと試行錯誤して、随分時間を取られたけど、結局これは生成処理と配列処理の相性が悪いことに原因があるようで、配列についても同じように速度テストしなきゃならない。ギブアップ。整形したHTMLをそのまま書き出したら、折角データベース化した意味が無いもの。というわけで、Mozillaさんサヨナラ。1.0が出るその日までお元気で。
IE5.5については全く問題は起らず、サイトマップの形は出来上がった。Macintosh版はどうだか。でもスイッチを押さなければどうということはないはず。
サイトマップには、:hoverで背景色を変えるCSSを採用。リストの間隔を詰める必要を感じたから。
またしても書くが、このサイトマップ機能は、なくても何一つ困らないものである。トップページと同じ機能を外部JSファイルとして各文書に埋め込んだだけだから。
JavaScriptで色々遊んでいたら、半年前にやりたくて出来なかったサイトマップ系ナビゲーションの構築が、簡単にできるようになっている事に気づいた。ほとんど「オブジェクト指向プログラム言語としてのJavaScript」のお陰といって良い（やはり後半の部分がイマイチ理解不能だが）。DOMはCSSにも手を伸ばせるから、IEとN6のCSS実装の差なんてほとんど問題ない。position:fixedも使いたい放題だ。この辺はDOMリンク集に挙げたサイトのお陰。JavaScriptの本なんて見つからなくて逆に良かった。私は本を持っていない。documentオブジェクトにtitleプロパティがあることは、つい先月、DOM仕様書で知った。
そういえば、ナビゲーションをレイアウトに含めてしまっているデザインを良く見る。というかほとんどそういう形ばかりだが、これには反対。コンテンツを追加するごとにページのレイアウトに気を使わなければならないサイトデザインは、自分の首を締めているようなものだ。「訪問者に優しい」が「自分に厳しい」。トップページに関して、私がpositionではなくfloatを使っているのは、レイアウトを意識せずに自然にリンクの数を増やせるから。やりたいことをやる系個人サイトには、これはかなり重要な問題。
前、「目次にposition:absoluteは99%有害」なんていうパロディを書いてみたことがあったが、うまい方法もあるはずなので封印。
まず、トップページの読み込み完了まで、20秒かかる（ちなみに私はケーブルモデムで接続している）。フラッシュか何かのオブジェクトが3つあり、そのうち2つは最後まで読み込まれずに終る。
目的のコンテンツまで、7秒、3秒、3秒、3秒、5秒（ここでツールバーなどを強制的に消去された別窓を開かされる）、3秒、5秒、3秒、11秒。
これ、何だと思いますか。J-COM@Nethomeメンバーサービスの「ウェブサーバの統計」のページを開くまでのプロセスです。8回もクリックする必要があります。計1分かかります。これだけプロセスが長ければ、迷う人もいるでしょうから、実際はこんなものじゃないかも知れません。
もう二度と見ない。
愚痴ばかりでもなんですから、嬉しい話を一つ。
とうとうGoogleが、menbers.jcom.home.ne.jpドメインを補足し始めました。正確にいつからなのかは不明です。