なんというか、一本の木を作るイメージが脳内で出来上がっている。
まず幹を作って（createElement）地面（document.body）に植える（appendChild、insetBefore)。枝を作って、幹に埋め込む。葉っぱを作って（createTextNode）、枝に付ける。なんかちょっとした快感なんですが、私は異常ですか。
書き込み可能なプロパティ（innerHTML）に無理やり値を挿入するやり方は、楽だけどどうも雑な仕事という感じ。枝と葉っぱを同時に作ってしまうから。
Netscape6.1は、CSS規則の読み出し、書き込み、書き込んだ後の読み出し、すべてうまく行った。
ただ、p{ border:1px solid #000 }という規則を追加し、cssTextプロパティ (英語)を見てみると、
p{
border-top-width:1px;
border-top-style:solid;
border-top-color:#000;
border-right-width:1px;
border-right:style:solid;
border-right:color:#000;
border-bottom-width:1px;
border-bottom-style:solid;
border-bottom-color:#000;
border-left-width:1px;
border-left-style:solid;
border-left-color:#000;
}
こんな感じに一つ一つの宣言がばらばらになって返って来る（実際には改行されていない）。なんだかCSSエディタを作る気が少し萎えてしまった。これを省略形に再変換するプログラムは私には書けないし、書く気力もない。というか、CSSを書くのさえ面倒臭くて適当にエディタを作ってみようと思った人間が、そんな困難に立ち向かえるわけがない。
私が欲しいのは、CSSの規則を書いた直後にそれが視覚的に反映されて、最後に出来上がったCSSを出力してくれるソフト。Document Object Modelを使わないと不可能だと思う。しかしCSSエディタと呼ばれるフリーソフトは私の知る限り「規則を簡単に書ける」というものばかり。リファレンス片手に……という人ならともかく、CSSを弄り倒した人ならマウスを使ってプロパティを選択している間に、規則そのものを2,3個書けてしまいそう。
追加した規則を、document.styleSheetsオブジェクトから読み出そうとしたのが間違いだった。input要素か何かに入力した規則を一つにまとめてしまえば良かっただけだよ……。それならIEでも十分可能。
object要素とDOMで文書の再利用性を高める試みは、現実に負けました（IEが強制終了するケースが発覚）。IEのバグについてご報告くださった方に感謝いたします。
（※）1.で「無効にする」にチェックを入れていた場合は、問答無用で強制終了。
ご報告があり、こちらでも再現したので一般的なバグなのではないかと疑うわけですが、検索しても出てこないし、色々な方法を試してみても回避できませんでした。
私の場合、怪しげなMIMEタイプやsrc属性値等々はProxomitronで弾いていたので気づきませんでしたが、こういう設定のケースは結構多いのではないかと思います。強制終了になってしまった方には大変ご迷惑をおかけしました。
WYSIWYGっぽいCSS Editorを作ろうと思って色々試していました。Mozillaを使えば（脳内理論上）割と簡単にできたはずなのに、insertRuleメソッドでCSSの規則を追加するとMozilla0.9.3が強制終了してしまうのです（うちの環境だけかも知れませんが）。
IEの場合、独自のメソッドで規則を追加できるものの、追加した規則を参照できなくて（あるいはその方法が見つからなくて）駄目でした。
Mozillaをお使いの方なら、
document.styleSheets[0].cssRules.item(1).cssText
をクリックすると、このページのCSSの最初の規則がアラートされると思うのですが、IEで同じようなことが出来さえすれば、（オンライン）CSS Editorを作れるはずなのです（もう一つ問題はあるものの）。
cloneNode()＠8/18
innerHTMLを出来るだけ排除してみた。innerHTMLは要素生成の処理の負担を肩代わりしているだけのようで、面倒でもcreateElement、insertBefore等のメソッドを使ったほうが早いようだ。でも今のところ、onclickやらmouseoverやらの属性を持った要素は、innerHTMLで生成するしか……。
仕様書を読んでいたら、cloneNodeというメソッドを見つけた。MSのサイトを真似て早速取り入れてみた。これは便利だ。階層を丸ごと複写して任意の位置に生成できる。
さとみかん經由でagenda @ Sophia'sを見に行くと、本文が表示されないと云ふ羂。(Internet Explorer 6b)
闇黒日記 より
対処しました。ご指摘くださった野嵜さんに感謝いたします。
object要素に関するテストが原因でした。
?の有無で判別して非表示処理をしておりました。色々な利用のされ方があるのだなあと、反省。同様に#でもこの処理をしておりまして、idを間違えると何も表示されないという始末。根本的な解決法を模索します。
カシミールカレー（極辛）を食べたら一日中頭がぼーっとしていた。恐らく脳細胞がいくつか破壊されたんではないかと思う。
キーワードsans-serifを消したら直った。"ＭＳ Ｐゴシック"も指定していたのに何故。
作ってみました。
タイトル「Rooster Funeral」、サイズ「984バイト」、使用している色数「2」。画像は一切使わず。つまり即興。
主な特徴は、禁断のline-height:150%を指定していることです。img{ display:none }で解決しました。いや解決はしてないか。むしろアクセシビリティ的に問題がありますか。
というわけで、どうしても画像が見たい方はJavaScriptをオフにしてください。とかいってみたりして（私は鬼）。元々img要素はほとんど使ってないですけど。でも一応努力はしてみたんですよ。画像は表示せずに代替テキストだけ表示させるにはどうすればいいかとか、img{ display:block }にすればどうかとか。どれも駄目でしたね。
当然あるだろうと信じて疑わなかったimagesオブジェクトのaltプロパティがNC4に無いことが分かった時点で、破門というか、失格というか、不許可というか、なんというか、もう、どうでもいいや。と。でももう少し調べるつもりです。
JavaScriptに限らず、絵でも写真でも音楽であっても、美しくあろうとする志向を持ち合わせていないにもかかわらずそれ自体が目立ちたがっているという被造物には、何かしら得体の知れないところがあり、その不可思議さを尊ぶ人もあればその不自然さに嫌悪を抱く人もある。
キーワード『美しいJavaScript』にて発見。
美しくあろうとする志向
は我が国には著しく欠けており、それは急速な経済成長を後押しした。しかしその間に文化創造の主導権は「残せるものを作れる」大人から、「何も残せない」子供へ手渡されたのである。
「快」は一時的な幻想だが、「美」は普遍的な真実である。継承の意識があるならば、文化には美の概念が取り込まれる筈だ。当然ながら子供には継承の意識は無い。また、彼ら子供にとっての「ぶんか」は、すべて私物であり、消費財である。私物であるがゆえに、他人に持ってゆかれたり、真似をされることを嫌う。
テレホーダイの時間帯に入ると異様に遅いし、連日連夜こうだと真剣に移転を考えたくなるし、でももちろん軽々しくそんなことできないし、自作CGI可能な無料レンタルサーバでも、これほど遅くは無かったし、この件に関して障害情報に何のアナウンスも無いというのもふざけた話だし、メンバーサービスにログインするのにJavaScriptだの専用proxyだのを必要とするのは何か間違っているし、各ファイルのリクエスト数が見られたのはちょっとだけ嬉しかったけど、
<html><body bgcolor=white> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=EUC-JP"> <meta name="robots" content="noindex,nofollow"> <meta name="GENERATOR" content="analog 4.11/Unix"> <title>ウェブサーバの統計 [@NetHome WebSpace]</title> </head> <body>
こんな見たことも聞いたことも無いソースを吐いてるし、metaタグでロボット弾こうとしてる辺りがどうしようもなく不安を煽るし、8月のagendaのリクエスト数が1000超えてるってのはどうも胡散臭いし、時間別リクエスト数が一番多かったのはまさに遅くなる23時だったし、リファラの解析もできないようならそんなサービスどうでもいいからサーバのメンテナンスしてくれよと言いたいし、そういえばALLNET時代は年中サーバメンテナンスのお知らせが届いていたのが懐かしいし、学校なんかの公的機関にはルータの設置を薦めているって話が本当だとしたら一般ユーザをコケにしているし、もうとっくに諦めた話だけど自宅サーバの野望は潰えたし、
@Nethomeブラウザって何だろ？ スパイウェア？
うちの純正IEだと、メンバーサービスにログインできない。ふざけるんじゃあない。
外部HTMLファイル内の１セクションを埋め込むテスト終了
実用化するには、スクリプト発動のきっかけとなる要素等も全て、DOMを利用して外部JavaScriptで生成しなければならない。外部jsファイルのサイズが、そろそろ良心の限界。
ブラウザに表示されるタイトルが、object要素で埋め込んだHTML文書のものになってしまう（IE）。ちょっと考えただけでは対策が思いつかない。お気に入りに入れる際のタイトルは大丈夫だし、放置かな。
恐ろしいことに「agenda」の4月分のHTMLファイルのサイズが、44444バイトだった。基本的に、私は呪われている。
突然だけど、Mozillaは素晴らしい。右クリックのElement Propertiesが素晴らしい（今頃気づいた）。ブラウザたるものこうでなくちゃ。
というわけで（？）cite属性をハイパーリンクにするスクリプトは完全削除。Mozillaユーザに無意味な外部JavaScriptをそう幾つも読み込ますわけにいかない。
Orbit Themeが使えなくなっていたのが一時ショックだったけど、新しいModern Themeも好きになった。未練無し。Composerも、なんとなくワクワクする感じで、無意味に使ってみたくなる衝動に駆られる。実際、属性なんかを後から編集する時には使えるかもしれない。
object要素の不具合については……多分私の無知が原因に違いない。今までも多くの場合そうだった。
HP、HP、HP。このどうしようもなく安っぽい響きが嫌いだ。それだけかも。しかし安っぽいと感じるに至った経緯は無視できない。このキーワードを連呼するサイトには、共通した特徴があるように思える。
私は、生まれては消えてゆく恣意的なリソースの塊を、HPと呼ぶ。
HPという略語を私はもはや否定しないが、ホームページ、ウェブサイトとは厳密に区別されるべきだと思っている。見分けは難しい、あるいは不可能かも知れない。しかし、運営者の精神的都合で閉鎖したならば、これらの特徴を全く満たしていなかったとしてもそれはHPである。というかHPだったのだ。このとき初めて私は確信できる。
つまり、私が「安っぽい」と感じたのは、HP、HPと叫ぶ運営者にウェブサイトを私物と捉える傾向を見出したからに違いない。公開した情報にしろ、掲示板の書き込みにしろ、すべて「私物」。それゆえ、自分の気に入らない人間がそれらを利用するのを極度に嫌う。リソース全てを突然ゴミ箱に捨てても文句を言われる筋合いは無いと思っている。
私は「むかつく」という言葉が嫌いだ。その一言ですべて片付いてしまうからである。この言葉を好んで用いる人間は、自分の気持ちを整理する行為を「屁理屈」と呼んで卑しむ。
body{ font-size:80% }に変更。その他コンパクトに収まるようなスタイル指定に変更。スタイル属性を変更するのとどちらが効率的か。2が駄目だ。data属性から渡されたURIは、#以下が切り捨てられてた（IE）。?なら大丈夫だが、埋め込んだHTMLファイルの外部JavaScriptがlocation.searchを認識してくれない。
document.URLから抜き出す方法で代用できた。Document Object Model (HTML) Level 1 (英語)に挙げられているプロパティを使ったほうが気分がいいので、逆に良かった（面倒くさかったけど）。
object要素で自分自身を外部ファイルとして埋め込むと、恐ろしいことになる。そういう訳の分からないことをした際のユーザーエージェントの挙動について、仕様書は「規定しない」といっている（うろ覚え）。そしてIEは、「散々悩んだ挙句強制終了」という挙動を選択したようだ。
Web Workshop - DHTML Dude: DHTML ページのパフォーマンス向上では、position:absoluteで絶対配置してあるならば、表示・非表示の切り替えはdisplay:none / display:blockで切り替えるより、visibility:hidden / visibility:visibleで切り替えた方が高速だとあった。
実際にagendaのログで試してみると、明らかに遅くなったので元に戻した。原因調査中。
半分くらいのフレーム（frame）否定論。
というわけで無事、agendaを更新履歴として再利用するスクリプトが出来たけれども、肝心の更新情報をほとんど記述していなかった。無意味。
IEとMozillaで配列の中身がまるで違うという件。いろいろ試してみたところ、ようやく原因らしきものがわかった。
childNodes- A
NodeList(英語) that contains all children of this node. If there are no children, this is aNodeList(英語) containing no nodes. The content of the returnedNodeList(英語) is "live" in the sense that, for instance, changes to the children of the node object that it was created from are immediately reflected in the nodes returned by theNodeList(英語) accessors; it is not a static snapshot of the content of the node. This is true for everyNodeList(英語), including the ones returned by thegetElementsByTagNamemethod.
DOM1(core) より
childNodesは、すべての子を含んだNodeList型で、The items in the NodeList are accessible via an integral index, starting from 0.
とあるように0から始まる整数を経由してアクセスできるそうなのだから、childNodes[0]あるいはitemメソッドを用いてchildNodes.item(0)で、最初の子要素にアクセスできる筈。1から始まるなどというのはあり得ない。
<ul id="testUL"> <li>test1</li> <li>test2</li> <li>test3</li> </ul>
children = document.getElementById('testUL').childNodes;
document.write(children.length + '\n');
for(i=0; i<children.length; i++){
document.write(children[i].innerHTML + '\n');
}
Mozilla、N6の場合、これはどう解釈したものか。なぜchildren.lengthが、7 になるのか（IE5.5では期待通り3）。
そもそも、一応子Nodeとして数えられているがundefinedとなる、cihldNodes[0]は一体なんなのか。という話。
DOMでは、テキストも最終的なNodeとして扱われるらしい。ツリー構造なのだから当然だ。しかし、この中のどこにテキストがあるというのだろう。改行コードくらいしか入っていないよ。
というわけで、改行コードを取り払ってみると……。
<ul id="testUL2"><li>test1</li><li>test2</li><li>test3</li></ul>
if(document.getElementById){
children = document.getElementById('testUL2').childNodes;
document.write(children.length + '\n');
for(i=0; i<children.length; i++){
document.write(children[i].innerHTML + '\n');
}
}
予想したとおりの結果に。
Mozillaでは、childNodesに改行コードも含まれる。連続した改行コード、テキストは一つのNodeとして扱われる。試していないが恐らく半角スペースやタブ文字も同じだろう。
テキストがNodeとして扱われるのは良いが、改行コードを含めたところで一体何の用途があるというのだろう。ともかく、Mozillaでは添え字は1から始めて2ずつ足してゆかねば子のli要素は参照できない。或いは、ソースレベルで改行を取り払えばIEと同じ挙動になる。
良く言えば厳密な解釈。悪く言えば大きなお世話である。しかしそんなことよりも、IEがテキストを一つのNodeとして解釈しないことに驚いた。タグで明示されていようが、素のテキストであろうが、同じく子要素であるのに。これはDocument Object Modelの基本中の基本の部分 (英語)と矛盾しているといっていい、実に気持ちの悪いものだ。同じDOMでも、しかしDynamicHTML Object Modelであるといわれればそれまで。
ブラウザ判別はやはり免れないが、IE用のスクリプトをメインにするのは止めた。これからは動作確認は仕様書を眺めながらMozillaをメインに行ってゆくことにする。さもなければ私のような素人は、Document Object Modelを誤まって解釈しかねない。というか既にしている。
ローカルサーバのログファイルを半年以上放置していたため、200M（メガ）バイトになっていた。動作がだんだん遅くなってきていたのはこれが原因だったらしい。どうも外部アクセスが異常に多かったので、ZoneAlarmによるセキュリティを強化。