agenda 2001-08（上旬）

「この文字列」に複数のクラス（class="test1 test2"）を付けてみた。ちなみにidは（id="testFord200108a23"）

私は子供の頃から酷い頭痛持ちで、こいつとの付き合い方は誰よりも知っているつもり。

人間、幸せを感じることが出来るのは、苦痛があるからであって、苦痛も不幸も何も無ければ、徐々に日々が平凡になってゆくに決まっているのだが、誰も苦痛とは付き合いたがらない。まあ、それはそうだ。

さて、昼寝か何かして頭痛になったとしたら、これはラッキーである。肩を揉んでみたり、首を回してみたりして足掻けるだけ足掻き、苦しむだけ苦しむのだ。とことんまで気分が落ち込んだなら、風呂に入る。全身に刺激を与えると風呂上りの爽快感と共に頭痛が治まることがあるのだ。これで直らないほど酷い頭痛なら、これはもう幸福が約束されたに等しい。死にたくなる直前まで気分を落ち込ませると良い。

本当に死にたくなってしまったらまずいので、限界を感じたら頭痛薬（※）を飲む。

しばらくすると痛みが引いてゆくのをありありと感じることが出来る。快感である。このあと、散々悩み苦しんだ頭痛の「余韻」が30分から1時間は続くが、これがまた適度な余韻で実に気持ちがいい。我慢した時間が長ければ長いほど、この余韻もまた長く続く。そして、解放感に浸りつつ一番のお気に入りタバコを、味わいながら一本吸うのである。

（※）中新薬業（株）の「オピス錠」がお勧め

このメソッドの正しい使い方は唯一つ。authorが、UserAgentのリファラを予測できない時にのみ、「戻る」の代わりに用意してやる。それ以外には使ってはならない。予測できるのならば、そのURIをhref属性に記述したa要素を作成してやるべきだからである。

ページ上部のナビゲーションの部分のul要素の、JavaScriptで生成した（2番目以降に出現する）子要素の先頭に、「>>」を挿入するというスクリプトを書いた。

「2番目に出現する子要素」は、childNodes[1]で問題なく参照できるはず、と思っていたが、Mozilla0.9.3と、IE5.5で、この違い。 document.getElementById('testULFord200108a21').childNodes[1].innerHTML

IE5.5の結果

<B>&gt;&gt;</B>agenda

Mozilla0.9.3の結果

<a href="./">Personnel</a>

Mozillaの参照するchildNodes[1]は、IEの参照するchildNodes[0]と同じになっていて、んじゃあ、Mozillaの場合、childNodes[0].innerHTMLには何が入っているんだという話。

document.getElementById('testULFord200108a21').childNodes[0].innerHTML

IE5.5の結果

<a href="./">Personnel</a>

Mozilla0.9.3の結果

undefined

何も入ってないよ（苦笑）。

これはもう解釈の違いというより、違う言語であるかのような違和感。こんな基礎的なところで、また実装の違いですか。疲れた。でもCSSと違って他サイトにも再利用できる汎用性があるのでくじけないでやるつもり。このくらいなら、判別に数バイト我慢すれば済むし。

他のリスト要素でも試してみた。

document.getElementById('testOLFord200108a21').childNodes[0].innerHTML （結果は同じ）

とにかく、トータルデザインというやつを一刻も早く確固たる物にしたい。私は後になってから「ああしておけば良かった」が多すぎるからだ。関連コンテンツの更新も進まないし。

更新履歴を書くというのはやたら面倒臭い。理想とするのは、一度HTML文書を作成したなら、それをサーバに置いて即完了とすることである。サイト構造に変化があるならば、せいぜい関係ある文書のlink要素を少し書き換える程度で済ませる。これが現時点でのベスト。

ところが以前やっていた方法では、新規HTML文書を作成するたび、このような余計な手間があった。

1. トップページに更新箇所を記述
2. 更新履歴ページに同様の記述を追加

さて、やはり問題解決の糸口は、文書の再利用にあった。どこか更新した場合、このagendaに日記としてつけておけば良い。ついでで良いのだ。そして、そのセクション要素（あるいはその見出し要素）にclass名を与えておいてやる（複数クラスとなるだろう）。そしてDocument Object Modelを利用し、更新履歴を記述したセクションの一覧を生成してやるのである。

将来的には、アクションを介してトップページに埋め込んでやることも可能かも知れない。

私が予想（夢想）しているのは、将来的に、正しいHTML文書を書く人間のウェブサイトが、その情報量、質ともに誤まったHTMLを書く人間のそれを圧倒的に凌駕し、それらを自然消滅に導くというシナリオである。

正しいHTMLを馬鹿にする人間に、Document Object ModelやCascading Style Sheetsの真の使いみちは理解できまい。現時点で、すでに勝負はついているのである。

ただし、再び馬鹿ブラウザが台頭することのないことが絶対条件である。ふざけたバグを抱えたまま、実装を謳うな。

AHLで、ISO-HTMLとしてチェックして、高得點を取るやうなHTML文書でないと、私は「良いHTML文書」だと認めません。

闇黒日記 より

初チェック。

http://members.jcom.home.ne.jp/jintrick/Personal/index.html を ISO/IEC 15445 としてチェックしました。 25個のエラーがありました。このHTMLは -18点です。タグが 21種類 115組使われています。

Check result of Another HTML-lint より

エラーの内容を見る限り、空要素を閉じるのを止めなければ高得点は不可能な模様。CSSやDOMでもう少し賢いことが出来るようになればdivなんて止めますが、閉じていないタグは、最近ではどうも気持ちが悪いのです。

なにやらIEの様子が変だ。ローカルで文書を更新してリロードすると、得体の知れない外国のサーバに何かを要求しに行く。そのサーバがIISというのが妙に気になる。わらい。fubを使えば大丈夫なので、ほとんど関係ないが。

自衛には随分気を使ってきたつもりなのだけれど。

ちなみに、今回のfubの人柱バージョン（195c）は、IEの外観を超えたような気がする。大きいボタンが好きだ。一向に不具合が発見できず、あまつさえIEの尻拭いをしているというこの滑稽。

HotWired Japan : Webmonkey : multimedia : ユーザビリティの神様も筆を誤る？

Jakob Nielsenを批判している。しかもかなり強気。翻訳者の問題もあるだろうが。しかし、内容がコミカルであることに違いはない。私はFlashは好きだが、このライターが作ったFlashは見たくない。

「ブラウザーで設定する文字サイズがきかない。そのためユーザーは、デザイナーが指定したフォントサイズでしかテキストを読めない。デザイナーはとても目が良いからかもしれないが、多くのFlashコンテンツでは文字のサイズが酷く小さい」、視力に関していえば、私は視力の弱いデザイナーをたくさん知っている。ただフォントサイズが固定されているという点についてはその通りだが、デザイナーが「文字のサイズを大きくする」機能をつければその限りではない。つまりこれもデザイナーの問題で、ツールのせいではない。

訳文 より

The 'Make text bigger/smaller' button does not work. Users are thus forced to read text in the designer-specified font size, which is almost always too small since designers tend to have excellent vision. I know plenty of designers who have horrible vision, but the point about fixed font size is true ... unless the designer creates an "increase the text size" feature. Fault: designer, not tool.

原文 より

そうではない。問題なのは、文字のサイズを大きくする機能を、わざわざ付けなければならないこと。何もしなくても可変のものをわざわざ固定するデザイナーが非常に多いというのに、そんな機能をつけるのに時間を割くのを期待するのは、それこそばかげている。

ちなみに、このライターが関わっているという2つのサイト（http://www.mytrainingcamp.com/ (英語)およびhttp://www.i2ii.com/index.phtml (英語)）でも、やはり文字サイズは固定されている。言行不一致。

まあ、HTMLで作る限り本質的に固定なんぞ出来やしないが、恐らく固定した気になっているのだろう。CSSをオフにすると当然文字サイズは可変にすることが出来るが、するとデザインがボロボロに崩れるからだ。

「何よりテキストが動いていては、その言語を読むのが達者じゃない人にしてみれば、読みにくくて仕方が無い」、これは動こうが動くまいが関係無い。文字が止まっていようがスクロールしていようが、日本語で書いてあったら私には読めない。きっと、日本のユーザーで英語を全く読めない人だって、全く同じように感じるのではないか。したがってこれは全人類の使っている全ての言語にユーザーが精通していないからだ。そんな人がいるのかどうか知らないけど。

訳文 より

Also, text that moves is harder to read for users who lack fluency in the language. If it moves or not is irrelevant; I can't read Japanese, whether it's sitting still or scrolling across the screen. I would venture to guess that Japanese users with zero fluency in English would feel the same. Fault: users, for not being fluent in every language known to man.

原文 より

Nielsenは「少しは読める人」を例に挙げているのに、「全く読めない人」に摩り替えられている。反論にも何にもなっていない。この時点でもう信憑性ゼロ。黙っていれば良かったものを。

最初の論点は、Flashコンテンツが頻繁な更新に向いていないということだが、更新すればいいだけの話だ。Flashムービーをうまく作ってあれば、内容を更新するのは簡単なはずだ。テキストを全部同じフレームにまとめてあるか、あるいは外部に切り分けてあれば、Flashデザイナーでなくたって、誰でも更新できる。これはデザイナーとプロジェクトマネージャーが悪いのであって、ツールのせいではない。

訳文 より

To the first point, that Flash content is not often updated ? update it! If the movie is properly developed, it should be a breeze to update content. Either all the content will be in a particular frame, or the content will be externalized so that anyone ? not necessarily the designer ? can update it. Fault: designer/project manager, not tool.

原文 より

そう。最初の論点は、Flashコンテンツが頻繁な更新に向いていないということでした。でもたった2,3行（数十文字）を執筆する間に、この人は論点を見失ってしまう。あるいは意図的に摩り替えてしまう。

Flashデザイナーでなくたって、誰でも更新できる、そういうものは、恐らく「Flashコンテンツ」とは言わない。せいぜい、Flashオブジェクトが単独で動いて小気味いいナビゲーションアニメを演出しているといった類のものだろう。もし、更新が誰でも簡単に出来るFlashコンテンツを構築することが出来たなら、、そのデザイナーは一冊本を書くべきである。きっと売れに売れるだろう。

つまり、そういうFlashは芸術的なものであって、非現実的であるということ。このライターが、実例を挙げることが出来ていないのが何よりの証拠。

このライターの理論からすると、この問題点を解消するにはフレーム等を使って複数文書を組み合わせなければならない。しかし、フレームにはまたフレームの問題点がある。

最後にNielsenへ：現実を直視すべし。自分のユーザビリティに関する教義を見直して、「Ten Usability Heuristics(ユーザビリティ10原則)」に今どきのデザイナーが感じる違和感を無くすべし。

訳文 より

Nielsen: Step into the present. Adapt your tenets of usability and bridge the gap between the Ten Usability Heuristics and today's designers.

原文 より

非現実的なことを書いているのはどちらだろうか。デザイナーに、ものすごく高度なことを要求しているような気がするのだが。現実、現実というが、何を現実といっているのかさっぱり分からない。その 今どきのデザイナー とは誰のことだよ。フォントサイズを固定するのが今どきのデザイナーかね。

Nielsenは、そんな馬鹿デザイナーのご機嫌を取るためにUsabilityを研究しているのではあるまい。

大学のキャンパスを歩いていると、前から竹中平蔵が近づいてくるのがわかる。
「嫌な奴が来た」
そう思った。

竹中氏、歩きながら花壇をじろじろ見て、私の後方にいる誰かに手入れについての文句を叫んでいる。
「偉くなりやがって」
そう思った。

何やら花壇について警備員に薀蓄を語りだした（英語で）。語りだしたはいいが、一つの英単語を思い出せないらしく、言葉に詰まっている。警備員にその単語を言い当てられてしまった。

すると竹中氏、ムキになって、ものすごい勢いで英語を喋りだした。というか、いつのまにか竹中氏ではなくなっていたような気もする。

しかしその人物は、また言葉に詰まる。
「○○ mean…….」「mean…….」（○○の部分は覚えていない）

そして、「みーん、みん、みん、みん、みーん」と蝉の鳴き声の真似をしながら去っていった。

Proxomitron依存というのが泣き所ですが、ユーザーが利用する形のジャバスクリプトについて色々考えています。

ユーザージャバスクリプト

User-Javascriptは今のところ、こんな機能を使えます。

1. 外部CSS切替
2. blockquote要素のcite属性をハイパーリンクにして生成
3. h2要素のアウトライン機能（idを付加し、内部テキストをリストにして生成）
4. h3要素のアウトライン機能（idを付加し、内部テキストをリストにして生成）
5. 外部JavaScriptファイルならハイパーリンクに、内部JavaScriptならアラートでソースを表示するリストを生成
6. 外部CSSファイルならハイパーリンクに、内部CSSならアラートでソースを表示するリストを生成

仮に私のスキルが向上せず、User-Javascriptを効率化できぬまま組み込み予定の関数を増やしてゆくと、1000行を超えそうな勢いです。やはり本を買わなければ実力はつかないのでしょうか。DOMをきちんと扱っている本は幾ら探しても無いのですが。

ValueClickのスクリプトに負けた。エラーにはならない。

自分で作ったユーザージャバスクリプトをUser-Javascriptと名付けた。

今のところ、新たな関数を組み込むのがやたら面倒なので、もう少しまともな機能を付加してからコンテンツ化することに。とはいえ、Prxomitronのフィルタが最低3つは必要なのがどうも……。

<body>
<div style="height:1%">
 <ul style="height:300px ; position:absolute">
  <li><a class="within" href="#foo">見出し1</a></li>
  <li><a class="within" href="#bar">見出し2</a></li>
 </ul>
</div>
<div style="height:99% ; overflow:auto">
――authorのHTML――
</div>
</body>

環境によって処理速度が遅くなるという問題。

結局どーやら、blockquote の兄弟要素として生成 (obj.parentNode.insertBefore(createdObj,obj.nextSibling);) とかするのが原因らしいー。使えんなーまったく。これをやめて blockquote 内に引用元表示を生成するよーにしたら、なんと処理速度が 8 倍に…。ただいまの処理所要時間は約 2 秒。ガマンできる範囲かな。

引用元表示の自動生成の処理速度改善… より

ぎょっとした。ウチのナビゲーションで使っている要素の先頭に生成するメソッドは大丈夫かなぁとか思ったが、そういう問題ではなく、やはりJavaScriptで問答無用で何かするというのはユーザーにとって余計なお世話になる可能性はあるので、何らかのアクションを介した方が良いのかもしれない。課題、課題、課題。

でもそんなことを一々言っていたら何も出来ない。まあ、出来なくても誰も何も困らないが。

環境と言えば、このまえΣOΦIA'sの解析で解像度2560x1024というデータを見た。一体どんな具合に表示されるのか興味津々。それとも何かの冗談ですか。

調べてみると、デュアルデスクトップだそうで、なるほどという感想。トリプルデスクトップデッドリンク@2002-09-24T19:53:50+09:00 なんてのもあった。一つの大きなディスプレイがあったほうがいいと思うけどなぁ。

自作のCSSを、代替スタイルシートとしてこっそりとhead要素内に埋め込み、切り替え可能にする、というのが、今回の趣旨。

一応、authorのスタイルシートも切り替えの対象に入れた。そして早速本家に行ってどうなるか試してみた。

ユーザージャバスクリプトをW3C「Cascading Style Sheets」に適用させた画像(12kb)

凄い数のCSS。計15個！どうりで重たいわけだ。それはともかく、「authorCSS4」以降が代替スタイルシートで、それまでの5つのCSSは、単独では半端なスタイルシートとなっている。代替スタイルシート以外は1つにまとめて頂きたい。理由は色々あるが、なんといっても表示が遅くなること。ユーザーに利益がほとんど無いこと。

ともかく、さすがは本家だけあって色々CSSが用意してあるものだ。Mozillaユーザーだった頃にも全然気づかなかった。

しかし、切り替えで遊べたのはW3Cだけ。代替スタイルシートを用意してあるサイトは他にはほとんどなかった。それどころじゃない。やはりというか、競合が起った。まるで臓器移植の拒絶反応みたいに。

自分のサイトは、表示はうまく行ったが切り替え関数に同じメソッドを使っているためか機能的に競合。ただしユーザージャバスクリプトの勝ち。喜ぶべきか、悲しむべきか。

この「agenda」が日記と大きく違うのは、見出しがあるということだろう。場合によっては面倒臭いが、後で自分が参照することを念頭に置いているので、天秤が考える方に傾くのである。

将来的にタイトルに検索する価値が生まれるように心がけておくべきかも知れない。

まあ、agendaはdiaryの意味だけれども（笑）。

自分で作ったJavaScriptを適用できる、ユーザーJavaScriptとかってあったら良いのに。それともproxomitronで、他所様のHTML文書のhead要素に<script type="text/JavaScript" src="http://localhost/foo/bar.js"></script>とか埋め込んでみようかな。で、こちらのIE5.5のDOM実装を利用して、それこそ好きなように料理させていただく。

• link要素を、オリジナルのナビゲーション要素として再利用。外部CSSファイルへのハイパーリンクとかも生成してみたりして。
• 同じように外部jsファイルへのハイパーリンクとか、script要素をテキスト表示とか（出来るかな）。
• blockquoteのcite属性はハイパーリンクにして生成。これはもうすでに関数作ってある。
• HTMLのソース（body内とかhead内とか）を、エディタを起動することなくブラウザで表示とか。出来るな。多分。
• 勝手にクッキーを発行して（笑）スタイルシート切り替え機能をユーザースタイルシートを含めて実現。この場合のクッキーはlocalhostに発行されるのかな。jsファイルがlocalhostにあるから。クッキーよく分からない。

よく考えてみると、これ、色んな可能性あるなあ。しかもちょっとJavaScriptかじっただけの私でも出来そう（ここが重要なポイント）。要するにこれ、誰もが作れるオリジナルブラウザってことか。

この例は、当然ながらヘンテコなHTMLには無効。head要素が無いとかいう文書には、スクリプトタグを埋め込むことすら出来ない（</head>を置換するとかそういう方法しか思いつかないので）。この辺がネックだ。

function citeAttToLink(){
 var nBlockquotes = document.getElementsByTagName('blockquote');
  for(var i=0 ; i<nBlockquotes.length ; i++){
   var cite = nBlockquotes[i].cite; var title = nBlockquotes[i].title;
   if(cite && title){
   citeText = '<a href="' +cite+ '">' +title+ '<\/a>';
  } else if(cite){
   citeText = '<a href="' +cite+ '">' +cite+ '<\/a>';
  } else if(title){
   citeText = title;
  } else {
   citeText = 'cite属性無し。title属性無し。';
  }
  var nP = document.createElement('p');
  nP.innerHTML = '<cite>'+citeText+'<\/cite><br \/><i>User-Javascript<\/i>';
  nP.style.textAlign = 'right';
  nBlockquotes[i].parentNode.insertBefore(nP, nBlockquotes[i].nextSibling);
 }
}

window.onload = citeAttToLink;

Smarasderagd's Week in Images (英語)

こういうのを見かけるたび、WWWは大切な画像をお披露目する場として不適当なのではと思えてしまう。

それにしてもこの人、5年も前から……。

ある要素がさまざまなインターフェースにおいて、どんな挙動で表現するか、
なども判断の一つでしょう。
リンクとコメントを異なる要素するならば、
ある要素だけ抜き出す UA で一覧が生成できるでしょうし、
コメントを隠して置いてリンクにポインタを当てるとコメントが出る、
とかいったスクリプトも実装しやすくなるでしょう。
検索エンジンなら、 H1 要素や DT 要素などは重要な語句であると判断し、
それによって検索結果表示の順序を決定するかもしれません。
また、多くのブラウザのデフォルトの見栄えでは、
DD 要素の左部がインデントされるので、
スタイルシートが適用されなくてもそれなりに読みやすくなるでしょうし。

引用元 定義リストの使い道＠WEB相談室 カヅサツ氏の投稿[WriteDate : Wed Jul 25 17:29:38 2001] より

なるほど。定義型リストに限らず、要素を明示しておくと色々な利点があるものです。そのアイデアは早速、試験的に実装してみたいです。idもclassも何もつけずに。

dtの次に出現する要素ってのを参照できるかどうかが問題。自然言語的に適切なマークアップの具体的な利益や如何に。ってこれはあまり関係ないかも。

ちなみに、dfn要素を「被説明要素」と解釈して、こんなのを考えてみたけれど、なんだか美しくない。でもliの中に更にdlを入れるくらいなら、自分ならこうしたろうと思います。

<ul>
 <li>
  <dfn><a href="foo.html">サイト名</a></dfn>
  <p>サイトの説明</p>
 </li>
 <li>
  <dfn><a href="foo.html">サイト名</a></dfn>
  <p>サイトの説明</p>
 </li>
</ul>

どちらにしろこういうのをul,liでやろうとすると、定義リストの存在意義があやふやになってしまいます。そもそも、dl要素の中にはdtかdd要素しかないし、登場順序もある程度決まっているのだから、対の関係はデータ的に自明なんじゃないかと思う今日この頃。

というわけで、私もカヅサツさんと同じく、説明つきのリンク集はdl,dt,ddのみでマークアップします。説明をつけていないリンク集でも「いつか付けるかも」ということでdd要素の出現しないdl要素にしてしまっていますが。

なお再開に際しましては、気分を一新すべく各コンテンツを整理いたしました。つきましては、「はじめにお読みください。」において、新しくなったT-file についての簡単な説明をさせていただいておりますので、よろしくご覧下さい。

引用元 T-file より

よく見かけるこの整理というのは、リソースを削除することなのか。移動させることなのか。それともその両方か。どちらにしろ気分を一新というのがその理由なら、止めていただきたいというのが本音。

ローカルで仮想的なディレクトリを作っておけば、実体に影響を与えることなく幾らでも構成を変えることはできるので、曖昧な分類であれば、WWW上でディレクトリ分けする必要はないのでは。編集はローカルで行うのが普通だから、これはそれほど奇抜な方法ではないと思う。なにより、「リンクはトップページにお願いします」などという奇天烈なお願いをしなくて済む。不都合があるとすれば、FTPダウンロードの煩雑が挙げられるが、これってそう頻繁に行うものかな。

各セクションの絶対URIを自動表示させる。

これは多分楽に済みそう。なんらかのアクションを介した方がくどくなくて良いかも知れない。

意味段落あるいはセクションがそれぞれ絶対URIを持つというのは、かなり大きな意味があるような気がする。それを何らかの形で視覚的に表現したい。その第二弾。

問題はjsファイルのサイズ。CSSはどう考えてもこれ以上小さくならないので、7kbまでに抑えたい。外部ファイル15kbの鉄則（根拠は何もなし）。最初は10kbだったのに。いい加減なものだ。

あまり関係ないが、Mozillaでborder-radiusプロパティを使ってみたところ、ホームページ作成講座で表示バグ。性質上、特に念入りに文法チェックをしていたので少しショック。虚飾に関して時間を割くのはもうやめ。いい加減飽きたよ。

MozillaでCSS切り替えがうまく行かない件の修正を開始。どうやらクッキーの問題ではないようなので根幹から疑ってみる。

if(!document.styleSheets) return;
var sheets = document.styleSheets;
 for(var i=0; i<sheets.length; i++)
  document.write('<samp>'+sheets[i].title+'：'+sheets[i].disabled+'<\/samp><br \/>');

以下、実行結果。（soleilは通常スタイルシート、luneは代替スタイルシート）

Mozilla（とNetscape6）での実行結果。

代替スタイルシートが認識されてないのか。と、思ったら下の命令ではlune：true。どっちなんだ?。

alert(document.styleSheets[1].title +'：'+ document.styleSheets[1].disabled)

掲示板に件の話題があり、表から入れないページを発見。詳細があった。さすがは。

Netscape6は、読み込み完了前にdocument.styleSheetsを取得してしまうと、代替スタイルシートが正しく含まれていない不完全なコレクションを参照し続ける場合がある。

引用元 JavaScript for CSS (9-2) より

私のスキルでは致命的な欠陥。新たにmeta要素を書き出す対策があるらしいが……。

閲覧に問題ない不具合は無視。特定ブラウザのためのコードは書かないし、ブラウザ判別も一切やらない。オブジェクトやメソッドが定義されているかどうかで判別する方針。今後これは徹底することにした。これからスリム化しようというときにこれ以上jsファイルが膨らんでたまるか。

よってこの件は終了。かなり切なくはあるものの。