悪マニと Google の話題で書いたときもそうだったんですけど、回線が細いせいなのかどうか、ひとつの記事にあんまり長い文章を詰め込むと、うまくいかないことがあります。再構築したらファイルが途切れたことがあって、過去ログなんていちいちチェックできないんだから、そういうのは困るよな、と思ったり。
本当に、本当に、本当に見栄えと構造体を分けたいのであれば、ブラウザのデフォルト表示は全くのプレーンな状態にするべきなのでは？
それは違う、と断言できる。WWW ブラウザは、製作者が CSS を用意せずとも、各要素を「それらしく」表現することを求められているのだから。
現状の問題点は、主要な視覚系ブラウザにおいて、なぜか「この要素はこう表現する」という仕方が統一されてしまっていること。だから、「見出し要素を使うと、前後に1行空きができて、文字が太字になる」といった嘘解説が出てくる。HTML の仕様書は、決してそのような表示をしなさいとはいっていないのだから、それはあくまでも各ブラウザのデフォルトスタイルがたまたまそうなっている、ということに過ぎない。
しかし、前述のような嘘解説を読んだ人は、「よし、じゃあ前後に1行空きがあって太字という表現をするために見出し要素を使うことにしよう」という方向へ勘違いしていく。こうして見た目を起点にマークアップすることが常態化すると、「見出しっぽく見えれば見出しだよね」というようになり、font 要素だけで装飾された「見出し」が登場することになって（以下略）。
ではどうしたらいいのかというと、デフォルトスタイルがブラウザごとに全然違えばいいのだ。闇黒日記のスタイルをデフォルトスタイルとするとか。ブラウザごとに全然、デフォルトスタイルが違っていれば、論理構造を明示する HTML でスタイルの指定は不可能だとみな気付くのではないか。……そう簡単でもないかな。いずれにせよ、構造と見栄えの分離とは、「ブラウザがデフォルトでスタイルを定義しない」ことではない。「HTML は特定のスタイルと結びつかない」と考えるべきだ。
CSS というのはもちろん、「特定のスタイルを指定する手段」である。
「フレーム内表示」くらいで簡単に著作者を（事実上）詐称できてしまうのは、ブラウザの実装がまずいから。逆にいえば、ブラウザが進化すればいいという話なのだから、問題の根源は「フレーム内表示」にあるわけではない。この事実が広く知られることになれば、ブラウザベンダーの努力によって、「フレーム内表示」にまつわる諸問題は解決される。
現時点でブラウザの実装がまずいのは明らかで、今そこにある問題についてこの場でどう判断するか、ということなら松永さんのおっしゃることは正しいのではないか。ただ、もっと遠くを見た意見もあっていいだろうと思う。だから私は、「それは盗用か」と問うた。ここで「それ」とは、「フレーム内表示」自体を指す。
アプリオリに「フレーム内表示」がダメなのではない。ブラウザの実装次第で解決される問題なのだ、というのが私の論旨。
主に個人情報をサイトの管理人に渡したくないと考えている方に役立つ記事。ちなみに当サイトのプライバシー・ポリシーは、次の通り。
私は様々な個人情報（主に閲覧履歴の類）の取得のために現実的に可能なあらゆる手段を取る可能性があるばかりでなく、そうして得たあらゆる情報は、無条件の公開を含めあらゆる用途に利用されうるので、当サイトの閲覧に当たっては、よくよくご注意ください。不勉強あるいは不注意ゆえに私に渡したくない情報を渡してしまった、という事故について、私は必ずしも対応を拒否しませんが、しかし対応を保証するものでもありません。
私は連絡先として電話番号を公開していますが、その一方で、番号非通知の電話は無視することも明言しております。したがって、私に電話で連絡を取るためには、私に電話番号を教えねばなりませんが、このとき私はあなたの電話番号の非公開を原則として保証しません。
私が情報を秘すのは、私がその旨を明言したケースに限られます。（とはいえ現実問題としては、私はこれまでご意見くださった方の電話番号について「非公開とする」旨を通知しなかった例が過去にありません）
とほほのWWW入門はおかしな解説をする大御所サイトとして散々叩かれてきたわけですが、皆さんよくご存知の通り、とほほさんの作成された HTML リファレンスは平均レベルよりはるかによいものです。上位1割の中に余裕で入ります。例えば「HTML4.01Strict では blockquote 要素に script 要素以外のインライン要素を直下に配置できない（script 要素はインライン要素ではない、という物言いはとりあえず略します）」という解説は、滅多にないものです。WWW ではもちろんのこと、書店で解説書を探しても、その事実は簡単に確かめられます。
ほとんどの解説では、どの要素がどの要素を直下に配置できるかについて一切説明がないか、「ブロックレベル要素はインライン要素を内包できるが、逆は不可能」という程度のことしか書かれていません。
結局のところ、とほほさんはまだ話せばわかってくれそうな感じもする相手であり、批判が「いじめ」といわれない大きな相手だから、都合よく叩かれてきたのでしょう。昔はいろいろあったにせよ、少なくとも現在のとほほのWWW入門は、ひどいというほどのサイトではありません。ホームページ入門という記事はやっぱりひどいんですけれども。
とほほさんとは逆に、実力以上によく誉められるサイトというのもあります。信頼できる HTML 解説サイトとしては Academic HTML などが有名ですが、banban さんの初心者のためのホームページ作りを好意的に紹介する記事を、最近しばしば見かけます。じつは私も以前、よいサイトとしてご紹介しました。メルマガの発行部数も6000弱と大人気となっているわけですが、この banban さんもじつはけっこうおかしなことを書いていらっしゃいます。
2004年3月19日に発行された第89号には、HTML講座 第31回
として文書型定義
について解説しよう、という一項があります。
文書型定義を一言で述べれば、作成するHTML文書の仕様を定義するものです。
つまり、記述されるHTMLが、どのバージョンに準拠しているかを明示的に宣言します。本来ならば Webブラウザは記述された文書型定義を参照し、その仕様にしたがってレンダリングすべきものですが、実際は Webブラウザが実装している仕様にしたがってレンダリングするのが実情です。
概ね正しいことをいっているようですが、つまり、記述されるHTMLが、どのバージョンに準拠しているかを明示的に宣言します。
という説明は致命的な誤りを含んでいます。記述されるHTMLが、どのバージョンに準拠しているかを明示的に宣言
するのは文書型宣言であって、文書型定義とは別物です。banban さんは、文書型宣言のことを文書型定義
と呼んでいます。そこで、banban さんの説明にある文書型定義
を文書型宣言で置換すると、説明は概ね誤りとなってしまいます。続く説明がまたおかしい。
- １．HTML4.01 Transitional 互換型
この文書型定義は、それ以前のバージョンで定義された要素や属性などを使うことができる過渡期仕様の互換型で、DTDを参照する URI は含まれません。
互換型の文書型定義は以下のように記述します。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">- ２．HTML4.01 Transitional 標準型
Transitional互換型と同様に、以前の要素、属性などを使うことができます。この宣言は、その仕様を参照する URI が含まれます。
基本的に Webブラウザは、その仕様を参照してレンダリングすることとなっていますが、銘柄によってはそれを無視することがあります。
標準型の文書型定義は以下のように記述します。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
まず、文書型定義を文書型宣言と読み替えましょう。しかしなお問題が残ります。互換型
とか標準型
といった説明は、いったいどこから出てきたのでしょうか。IE や Mozilla のレンダリングモードに「互換」「標準」（などと翻訳されるモード）があることはよく知られていますが、文書型宣言に互換型
と標準型
がある、というのは初めて見る説明です。おそらく、この説明には出典がないと思います。HTML4.01 の仕様書から読み取れる内容は、せいぜい
といったことであって、URI の有無によって「互換」「標準」と呼び分けるといった説明は出てきません。
……というわけで、banban さんの解説は概ね信頼できるけれども、ときどきこういったポカがあるのは事実です。入門記事を除けば、とほほさんの記事と banban さんの記事の信頼度は、私の中であまり差がありません。ようするに私がいいたいことは、本当にひどい解説をしている方は世の中にいくらでもいるのであって、例えば野嵜さんがお勧めしない本としてとほほ本だけをあげているのは、ちょっとどうかと思うわけです。
しかしだからといって超大手のダメ解説サイトみんなのタグ辞書やlove cherryを批判しても、やはり労多くして益絶無となりそう。ヘミング先生批判が何にもならなかったように。
この話題については反応記事、関連記事が多数存在するが、私の目を引いたのは1件のみだった。
- Orbium: コンテンツは盗用するな！ 共有財産であるべきだ．
僕はリンクフリーで公開しているコンテンツはそうした知識の共有を行うために公開しているものだと理解している． この盗用は明らかにそうした意志を無視し，踏みにじるものだ．
知識の共有を目的とした公開であったなら盗用も糞も無い。実際私はサイトポリシーにおいてiframeによるembed型リンク他あらゆる形式のリンクを許可しているが、embed型リンクをされたごときによって目的が踏みにじられることは断じて無い。
松永さんがコンテンツを公開している理由は定かではないが、仮に知識の共有を行うため
であれば、松永さんには反撃する理由がない。ただ、松永さんは以下のように述べているので、ずいぶんいろいろと雑念が入っていらっしゃるようだ。
当方としては、サイト閉鎖ではなく「インラインフレームの解除と出典の明示」だけ対処してもらえばよかった、というのは当初から一貫した考えである。別にMLMだろうと何だろうと、あるいはネガティブリンクだろうと、リンクだけならご自由に、だ。しかし、そのサイトに協力も賛同もしていないのに、そのように受け取られかねないような表現、あるいは当方の作成したものを安直に流用して儲けようとしていながらこちらに何らの見返りもないやり方というのは避けてもらいたい、ということである。
ところで、フレームの中に他サイトの文書を読み込む手法は、一概に盗用
とは言い切れない。Google 画像検索やキッズ goo という前例について、松永さんはどのようにお考えなのだろうか。両者とも、他者のコンテンツを安直に流用して儲け
ているわけだが。
そのサイトに協力も賛同もしていないのに、そのように受け取られかねないような表現
ともおっしゃるが、フレームの中に表示されているだけでそう考えてしまうのは、むしろ読者のリテラシーの問題ではないのか。多くの閲覧者のリテラシー不足を、安易に肯定する意見には賛成しない。
Google にキャッシュを取られているサイトは、みな Google に協力しているのか。賛同しているのか。そうではない。大多数の方は、Google にキャッシュを取られていることを知らない、あるいはキャッシュを取られずに済む方法を知らない、もしくは単に黙認しているに過ぎない。
blockquote 要素には引用元を示す cite 属性があるが、Windows 版 IE では cite 属性が解釈されない。そのため、cite 属性を記すだけでは、多くの人にとって引用元は不明であろう。では、引用時の出典情報は cite 属性に明記するだけでは不足なのか? 私は、十分ではないかと考える。もちろん、最大シェアの IE で無視され、他の主要ブラウザでも面倒な操作なしに表示されない形では「出典を明記しているとは言い難い」という判断もありうる。しかしそれは唯一の正解ではない。
インラインフレームへの文書読込は、HTML の観点からいえば「引用」ではない。リンクによる参照である。見た目は引用に似ているかもしれないが、技術の本質は全然違う。フレーム未対応のブラウザ（の一部）では、参照文書へのリンクが用意されるだろう。あるいは、noframes 要素に記述されるフレームの代替内容は、リンクになるはずだ。見た目だけを判断の根拠として、リンクを盗用といって糾弾するのはいかがなものか。
……という私の記述についてHatena::agenda 2004-03-29にて以下のご意見あり。
HTMLの観点からいえばembed、埋め込みです。埋め込んでしまっているのですから参照ではありません。これは通常なら転載というのが最も近い表現かと。文脈によっては引用になり得ます。確かにレンダリングの過程（あるいはソースレベル）においてはブラウザにとってURIの参照かもしれませんが、プログラムを擬人化しても仕方ないでしょう。
読者の方は、dotnote Days...2004年03月27日も参考にしてください。embed は「参照」だと私は考えます。例えば、被「参照」側がファイルを削除した場合、「参照」した側からもファイルが消えます。これは「転載」では起こりえない事態です。しかしこの辺は日本語の問題で、意見の分かれるところ。ただし印象が大きく異なる言葉なので、この言葉の選択次第で結論に多大な影響が。
一人が勘違いしている場合、勘違いする側が馬鹿だ、という話になる。みんなが勘違いしている場合、勘違いさせる側が馬鹿だ、という話になる。いずれにしても勘違いは勘違いなのだが、多数派のいうことは正義になってしまう。見た目はどうあれ、松永さんのコンテンツは盗まれてはいなかった。転載されたわけではなかったのだ。img 要素にせよ、フレームにせよ、src 属性で指定された URI にあるリソースが参照されるに過ぎない。
Google画像検索、キッズgoo、excite翻訳などはいずれもフレームの中に他人のコンテンツを勝手に表示する。大手サイトがやれば誤解されないのに、弱小サイトがやると誤解され血祭りに。結局、フレーム内表示自体の問題じゃなくて、それを見る側のリテラシーの問題なのだ。文書のプロパティを見れば、フレーム内に表示されるリソースの URI などはわかる。他サーバから呼び出された文書かどうかは、閲覧者がちょっと調べれば簡単にわかるのだ。
そういう話をまったく無視して、「弱小サイトが Google と同じことをやると誤解されるらダメ」とは不公平な話ではないか。だいたい Google なんてのは反則企業だから、キャッシュとかいう著作権侵害を平気でやる。あそこは大手だから、「キャッシュされたくなければこうしろ」という情報は「常識」で、知らない方が悪いらしい。そんな理屈が通るのか。ブラウザがきちんと進歩して、誰が Google の真似をしても勘違いが起きないようにするのが、正しい未来のあり方ではないか。
私の言葉の伝わりにくい部分などを整理してくださっていて、ありがたい。また、DAC さんの感想が、うまく松永さんの気持ち（もちろん推測）と私の意見の間を埋めるものとなっているのではないか。また、追記にまとめられた整理すべきポイント
はたいへんありがたかった。必読の文書。
当サイトでは Trackback を受け付けていないので、この場で反論を拾います。ページ盗用問題のまとめのコメント欄より。
- [No.9] 投稿者：松永［2004年03月28日 19:11］
↑上記徳保氏の記事について簡単に。私は「参考文献の提示」（参照）である「リンク」と、適切に参照元を提示してコンテンツを利用する「引用」、そしてそれ以外の「転載」や「盗用」を厳密に区別しています。書かれたタグのみで単純に判断して徳保氏はインラインフレーム表示を「リンクであって盗用ではない」と主張していますが、現実問題としてインラインフレームでは内容そのものすべてが「リンク元」サイト内に取り込まれて表現されるため、著作権違反になるという判例もあるわけです。その判例を私は支持します。したがって、「リンクを盗用という愚」と主張する愚には賛同しかねます。なお、googleやgooなど検索エンジンでの取り込みについては、検索した人がだれも「これはgoogleが作成した画像である」と考える余地がないという点で同意を得やすいと思います。以上。
- [No.10] 投稿者：松永［2004年03月28日 19:13］
なお、いちいちソースを見て判断することをリテラシーとして読者に求めることには賛同できません。出力された結果において判断するのでなければ、ブラウザは不要ということになりましょう。
松永さんが多数派の論理を正義の源泉としていることは当初からわかっていた。野嵜さん流にいえば、賛同者の多寡に関わらず「正しい」ものは「正しい」のだが、ようは HTML の原理原則から考えるか、実際の閲覧者のリテラシを前提に含めるか、という差だといえる。私が前者を重視するのは、次のように考えるからだ。
先にあったのは HTML であって、ブラウザの設計がまずく適切なインターフェースが用意されていないのが問題の根本原因だ。例えばブラウザに「プロパティサイドバー」が常設され、現在アクティブな HTML 文書（または選択された要素）のプロパティが表示されるのが標準状態であったなら、別ドメイン下からのリソース参照は誰にでも簡単に判読できる。Google のような大手サイトは、有名であるが故に「システムを理解できない方が馬鹿」といわれるのだが、本来なら、あらゆるケースにおいて誤解を防止できたはずだ。ブラウザベンダーの想像力不足が、このような事態を招いている。
もちろん、近視眼的な問題解決も世の中には必要とされている。だからそれはそれとして認めるが、もう少し遠くを見た意見があってもいいのではないかと思うわけだ。ところで、
「W3C原理主義」の人は、「インラインフレームはリンクタグなのだから、インラインフレーム表示はリンクであって盗用ではない」と主張 ワラタ さすが原理主義者
楽屋裏の発言にすぐ辿りつけるというのもいかがなものか。松永さんらしく、ここでも十分に抑制した表現を採用されているのはさすが。
松永さんがちょっと悪口を書いただけで退会者がボロボロ出てくるというのは、それはそれでいかがなものか。影響力、大き過ぎ。現実にそこにある問題を松永さんは無視できないだろうから、今後は今回のようなネタはやりにくくなるだろうと思った。
ところで、盗用サイトを作ったユーザーが非常に紛らわしい表記をしていたため、私もVEGA CLUBさんの表現を貶めるような表現を過去にとってしまっていました。
と松永さんは述べていて、「みんなも勘違いしたよね? だから僕が勘違いしたのも仕方ないよね?」ということを言外にいっている。首尾一貫した言動であるなあ、と思う。ウケ狙いのネタにしないで、最初から VEGA CLUB にメールでクレームをつけるのが無難だったのではないか、と思ったりもする。
端的にいうと、現状において件の「盗用」が問題になること自体は当然だ。しかしそれは近視眼的な物の見方であって、別の観点からは異なる結論を導くことができるし、そして最終的に望ましいのは原理原則に基づいた解決策であろう、という話をしたかったわけだ。
受け止める側のリテラシ云々を問うのもばかばかしいし、そういうことを平気で言うのは技術者側の傲慢さが見えてきて、私的には反吐がでる。
この批判は単純すぎる。リンクと引用が素人目に区別できないのは、ブラウザの実装がまずいからだ、と私は述べた。そこで私は、ブラウザの実装の改善案をいくつか示した。現状の実装のままではリテラシの向上は掛け声倒れだろう。しかし、blockquote 要素の cite 属性問題と同じで、技術者の工夫によって、技術の本来の意図を反映した状況を生み出していくことができるのではないか。
現在、Google などの大手サイトだけが、大手であるが故に、弱小サイトと同じことをしても誤解されない。これは不公平な話だ。本来、弱小だろうと大手だろうと、（HTML の観点からいえば）それはやっていいことなのだ。ようは、誤解が生じない実装があればいいわけであって、これは技術的に解決しうる問題ではないのか。
とりあえず、今ここで述べておきたいことは、アプリオリにフレーム内表示がダメだというわけじゃないという話だ。まずこの事実を押さえておかねば、技術者の工夫も始まらない。
私は2人兄弟で、弟は4月から大学3年生になる、はずなのだが、これがいささか怪しくなってきたとのこと。おそらく大丈夫だとは思うのだけれども、年度末の試験結果が思わしくないようで、4月の成績発表には戦々恐々であるらしい。留年してもしなくても学生寮は追い出されてしまうので、3月から大学のすぐそば（大岡山）にある家賃8万円のアパート（築6年）で暮らしているという。しかし家賃8万円って、贅沢なやつだなあ。
弟は親のすねかじりで生活している。面倒くさがって、ろくにバイトもしないくせにお金だけは湯水のごとく使うのは、いったいどういう了見か。それでいて留年の危機だという。お話にならない。しかし当人は、「超一流とはいわないまでも一流の国立大学に合格して、自分で返す奨学金もとっているのだから、こんな経済的な孝行息子はそうそういないよ」といってはばからない。なるほど、一浪したとはいえ市立の小中学校と県立高校を卒業し、予備校も特待生で授業料免除、病弱で親を泣かせた私と違って健康で運動も得意だった弟は、よくできた息子には違いない。「自分の価値」を両親は正当に評価していない、という気持ちは理解する。理解するが……。
私は両親に多くを望まなかった。病弱に生まれ育ち、そして病気の克服のために何らの努力もしてこなかったことに、私は引け目を持っている。私は「こんなもの、たいした病気じゃない」と思っていて、その克服のための努力にはとても耐えられなかったのだった。結局、病気と一生付き合うことになってしまったが、私自身は納得している。
しかしそのために、両親の人生は路線変更を余儀なくされた。登山の好きな父は、私と山に登りたいと願い、私の名前に登山に関連する漢字を入れた。しかしついに、その望みはかなわなかった。両親は兼業農家になろうと計画し田舎にささやかな土地も用意していたのだが、病院から遠いためにとうとう家を建てる決心がつかず、手放すことになった。他にもたくさんのことを、諦めなければならなかった。
だから、というわけではないが、私は現状以上のことを、両親に望まなかった。毎日、おいしい食事を与えられ、部屋も服も与えられ、何を学ぶ際にも支援があり、これで何の不満があるというのだろう。
弟が、テレビゲームや漫画やお小遣いを欲したのは、別段、おかしなことではない。私にとってそれらは必要なものではなかったが、ふつうの子どもである弟には、なくてはならないものだったに違いない。友人より「程度」の低い環境に、甘んじることはできなかったのだろう。よその子が学校のテストで100点をとっただけで新しい自転車を買ってもらえるのに、私の弟であったばっかりに、あるいは、いつも100点を取っていたばっかりに、「よかったわねぇ」という言葉しか報酬が無い。弟は不満だったろう。私は、両親に誉められるだけで満足だった。ありがちな科白を援用するなら、「ぼくはここにいていいんだ」と安心できた。弟にとって「自分がここにいていい」なんてのは当然のことだったから、よりよい環境を求めてやまなかった。
私の弟だったために、私より勉強も運動もはるかによくできたにもかかわらず、叱られ続けて育った。ただ「正当な報酬」がほしかっただけなのに、「親に過大な要求をする傲慢な子」として扱われた。よその子が、ずっと羨ましかったろう。
４年で、ＮＯ！は、留学を厳に戒める昨今珍しい Web サイトだ。弟には、ぜひ読んでほしい。留年するとこうなるによれば、奨学金が止められてしまうのだという。まずいんじゃないのか。父はまじめだから、無いお金をどうにかして工面してしまうだろう。けれども、それを「当然だ」なんて、俺はいわせない。弟は「当然のことを当然といって何が悪い」と眠たいことをいうだろうけれども、そろそろ大人になってほしい。両親に、二言目ではなく、一言目に「ありがとう」といえる人間になってほしい。
- すちゃらかCSS素材集
CSSの「素材屋」ついに現る!? IE6でレイアウトがめちゃくちゃになるのは、サードパーティの画像をブロックしている所為かな。Mozillaで見たら今度はサードパーティのクッキーが凄い勢いで襲ってきた。
この勢いでタグ屋みたいなの（ルール屋?）が現れる前に手持ちのテクニックは片っ端から公開しておこうかな。
いわゆる「タグ屋」は昔から「CSS 素材」とやらを配布している。「マウスを乗せると上下に線が出る」とか、そういう「素材」に著作権を主張する恥知らずも少なくない。すちゃらかCSS素材集に近い存在としては、Webデザインテンプレート集という有名サイト（「Webデザイン」でGoogle1位）がある。論外というべきテンプレートをたくさん紹介しているサイトだけれども、世評は高い。
ところで、ウェブログ 虎の穴 其の四においてすちゃらかの管理人がインタビューに答えている。「簡単なのはよいことだ」式の価値観を明らかになさっているので、今後の改善にもあまり期待できないことがわかる。
「CSS デザインは HTML によるデザインより素晴らしいのだ」という価値観が、理屈抜きで蔓延しつつあるらしい。デフォルトのテンプレートが CSS でレイアウトされているというだけで、一部のブログツールは高く評価されていたりする。馬鹿げている。「なぜ CSS デザインの方がいいのか、説明してみろ」といいたい。
HTML をきちんと使うと、自分の希望と異なる表示結果となることが多い。HTML は文書構造を明示することしかできない。見出しなら見出しをどのように「それらしく」表現するかは、各 WWW ブラウザに任されている。「それでは嫌だ、自分で表現の仕方を決めたいんだ」という人だけが、CSS を使えばいい。CSS デザインなんてのは、ただそれだけのものに過ぎない。ブラウザのデフォルトスタイルがもっと魅力的で、大勢の人にとって不満の無いものだったなら、今そうであるほど CSS には需要が無かったろう。
CSS を用いたデザインだからといって、何が素晴らしいというものではない。HTML をきちんとせずに、ただ CSS でデザインするだけなら、くだらないとしかいいようがない。
Doblogは論外である。
MovableType のデフォルトテンプレートは評判が高い。しかしその実情はプロが教えるMovable Typeの構造デザインに詳説されている通り、お寒いものだ。そもそも公式サイトが構造化の「こ」の字もない見た目だけしか考えていないマークアップ（しかもテーブルレイアウト）になっているのだから、作者の方が HTML についていい加減な認識を持っていることは明らかなのだった。
ところで、ここは所謂『日記』でありまして、ブログとか blog とか、そーゆーもんじゃありませんので、トラックバックとか無縁な訳ですが、アレですよ。MT とか『はてなダイアリー』とか、ブログツールとか、そーゆーもんは、比較的まともそうなマークアップを自動的に吐き出す、とゆーか、生成されるマークアップが妥当になるような制約があるものものだと、勝手に思い込んでいたのですが、そーでもないのですね。そのうち、ガチガチのテーブルレイアウトのブログとか出て来るのでしょうか。とゆーか、既に存在してるとか……。
MT 利用サイトでテーブルレイアウトをやっているところは、ガチガチかどうかはともかくとして、じつはたくさんある。そもそも公式サイトがそうなのだから、利用者がそれを見習うのも不思議なことではない。テンプレートをいじっているサイトのほとんどはろくなマークアップになっていないし、記事本文のマークアップを自分でやっているサイトは、たいてい妙なことをしている。
MT 以外に目を向けると、例えば華式 Kshiki はいろいろカスタマイズが可能だが、基本的にはテーブルレイアウトしかできない。これは極端な例としても、デフォルトのテンプレートのマークアップが素晴らしい、というケースは滅多にないといわざるを得ない。Weblogツールリスト（ホスティングサービス）に掲載されているサービスのマークアップの仕方を簡易に分類すると、以下のようになる。（注：ポータルサイトではなく、ブログのデフォルトテンプレートをチェック）
とまあ、こんなわけで、「ブログ＝ CSS デザイン」という常識は、いささか怪しい。ところで、Weblogツールリストのマークアップもずいぶんひどい。
俺は将来自分の子供が「もう勘弁してつかぁさい。勘弁してつかぁさい」と泣いて許しを乞うまでしつこく映画に連れて行ってやろうと思った。ついでに言うと俺は5月に結婚するのです(お祝いの言葉禁止。無視するよ！)。
年貢の納めどきですな。
よくある、勘違い記事。同種の Web サイトが乱立しているのは、ニュースサイトや日記サイトに限らない。単に特化するだけではダメだ、という点に触れているだけマシな記事なのだけれども、ニュースの紹介をするだけなら、誰がやったって同じなのだ。
なんて書いているのは酷い。誰がやったって同じ
ではないから、ライバルの多い中でもぐんぐん伸びるニュースサイトが存在するのだ。
人気のないサイトは、紹介した記事の筆者がいうような意味においてどこにでもあるおなじようなニュースサイト
だからダメなのではない。そのサイトの管理人が何かに特化したサイトへ方向転換したとしても、十中八九、人気のないままに違いない。しかも、本来やりたいことのいくつかを我慢するので、ストレスがたまって閉鎖の危機も迫る。たしかに、人気サイトと不人気サイトには、何らかの違いがある。端的にいえば、需要の大きさが違う。問題は、なぜその違いが生まれるのか、ということだ。しかし、それが簡単にわかるなら、マーケティングの担当者は苦労しない。
はっきりいって、ほとんどの人は不人気サイトしか作れない。馬鹿の考え休むに似たり、というが、素人考えで右往左往しても無駄な努力である。そう認識した上で、自分の進む道を考えた方がいい。
2月29日に、くつしたさんに呼ばれて清麿加入くつしたライブ（一番下のは嘘写真なので注意）へ顔を出しました。ライブが始まるまでは、例によって「私はどこに立っていたらいいのでしょうか」という不安な気分。暑く、暗い店内、座席は壁沿いに少しだけ。日頃、まったく縁のない場所。前回、ライブに顔を出したときに見た顔がいくつか。でも話すことないし、名前も忘れてしまったし……。何もかも面倒くさくなって、ぽつねんと立っていました。
とはいえ、居場所の無さを感じるのはステージ交代の準備時間中だけ。いざステージが始まってしまえば、意想外に時間が経つのは早いし、楽しい。清麿加入くつしたライブは午後2時からだったと思うのだけれど、1時45分頃に始まったステージはそのひとつ前のでした。前回もそうだったように、時間が押していくのが恒例のパターンなのかもしれません。ガランとした店内に、響く熱唱。医者の見習いだそうだけれども、何であれ趣味に傾倒するとたいへんだなあ、なんてことを考えていました。
さて、前のステージの途中でどんどん人がやってきて、清麿加入くつしたライブは盛況の中でスタート。私はその直前に席をゲットできて、一安心。壁際以外に席が無いためほとんどのお客さんが立っていて、ちょっとステージが見づらかったけれども、やはり座れるのはありがたい。前回同様、いや、前回以上にお笑いに走った内容で、それでいて歌もよかったという謎ライブでした。会場の反応がよかったので、私もよかったです。みんながシラーっとしていたら、やはり私もそれに影響されてしまうので。楽しいときにその気持ちを出せるのは、とてもいいこと。
後日、びっくりしたことがひとつ。
ぼんやりしていると、いつまで経っても更新できそうにない。今日は、今月中に書こうと思っていた話題を、いくつか拾っていきたい。
多忙につき、次の休日まで備忘録に新規に話題を追加しません。下手に睡眠時間を削るとまずいので、そういうことに決めました。
というわけで、お休みなさい。（って、字にしてみると、なんだか変な挨拶だなあ）
東京にいると、こういう楽しみはあまりないなあ、と思いました。
ところで「次女」を「妹のルミ」に変換していただいた件、おかげさまで読みやすくなりました。でも「次女」の正しい使い方は、依然、謎ということですね。（全然関係ないですが、こっちの界隈でルミさんといえばルミ姉さんだったわけでその……。ここで「妹のルミ」が登場してくるというあたり、面白いなあ、と。まるっきりこっちの話なんですが）
そういえば、3刷かかって118万部も出たという文藝春秋2004年3月号掲載「蹴りたい背中」をようやく読んだのだけれども、にな川というオタクが追っかけをしているモデルの名前が「Oli ちゃん」だったので驚愕しました。加野瀬さんが綿矢さんの写真と勘違いしたのがコスプレーヤーの織さんの写真だった、というエピソードを思い出したのです。ちょっと、できすぎた話。まさか、狙ってやったネタでは……。
でも、これって、気付いたのは私だけなんですかね? みんな、とっくに気付いていて、どこかで話題になっていたりするのかもしれませんけれども。
天安門広場では誰も死傷しなかったかもしれない。ただ、場所は広場の外かもしれないが、「いわゆる天安門事件」において319人が亡くなったことは、中国政府が発表している通りである（Wikipedia）。
町山さんの書き方は勝谷さんと大差ない。記事の主眼は理解するが、だからといって広場の外で（公式発表の数字においてさえ）319人もの方が亡くなっていることをきちんと書かないのは、いささかバランスが悪い。コメント欄を見ると、事件に犠牲者がいなかったと勘違いしている人がいる。広場の外では、大勢が死んだのだ。その事実が、伝わっていない。町山さんは、誤解を解こうとする記事によって、新たな誤解を生んでいる。皮肉な話である。
補注：村田忠禧さんは政治的に中国よりの発言を繰り返しており、端的には日本軍国主義の中国における犯罪行為についてに示されているような歴史観、価値観を根強く有している方だということをお断りしておく。村田さんは中国で人民解放軍が暴徒の制圧に際し死者を出したことを「虐殺ではない」とかばう。しかし仮に日本で自衛隊や警察が暴徒を319人も殺害したら一方的に国家権力を非難するはずだ。（注：憶測です）
なお、The Massacre - June 4, 1989（残酷画像注意!）では「虐殺の証拠画像」が多数、紹介されている。おそらく天安門広場の外で撮影されたものだろうから、キャプションには注意されたい。ただし、いずれにせよ、あの事件で人が大勢亡くなったのは事実である。
あえてここで視線を日本の国内事情に向けて、右だの左だのという話をしてみたい。
親米保守派は天安門事件をうまく利用したので、親共市民派（60・70年安保世代）を反中共へと導いた。旧ソ連圏の社会主義政権が続々と崩壊していった頃でもあり、市民派もそろそろ中共の擁護に飽いていた頃だった。とはいえ、左派のマスコミが情報戦の「敗北」を唯々諾々と受け入れるはずがない。その後、天安門広場の中に死傷者が生じなかったことを積極的に報じたのが NHK と朝日新聞だった……というのは、わかりやす過ぎる。
産経新聞にとっての南京事件が NHK と朝日にとっての天安門事件ということか。
私はここで南京事件をフレームにするつもりはないが、簡単に補足したい。南京で市民に対する組織的な虐殺はなかったかもしれないが、敗走する中国軍に対する追撃戦は一方的なものとなり、中国側に（軍人を中心として）多大な犠牲が出たことは事実と断言してよい（と考えている）。いわゆる「虐殺」イメージとの合致の如何を問わないこととすれば、多数の死者が出たこと自体は多くの証言に裏付けられている。
ところで、私が朝日より産経をマシだと思うのは、産経自身の胡散臭さを隠そうとしないことだ。かつて高山正之編集委員（現・帝京大学教授）は、毎週土曜日の連載コラムで毎回のように社説に反する持論をぶっていた。先のイラク戦争の際にも久々に紙面に登場して、またもや産経的モノの見方をひっくり返してみせた。ようするに産経は編集方針がいい加減だということなのだけれども、読者としては素直に歓迎したい。その後、高山先生ほど強烈に社の方針を無視した大物記者はいないが、最近でも黒田勝弘論説委員、牛場昭彦編集委員、斎藤勉論説委員らは、しばしば社説と異なる意見を述べているので注意されたい。そういえば、吉本翁が麻原逮捕後にオウム擁護論をダダーンと開陳したのも産経の夕刊文化面だった。破防法適用を求める新聞のすることとは、とても思えない。
圏外からの一言では模倣犯の記事へのリンクテキストにそのまんま東は淫行をしていない
と書いているが、これは明白な嘘だ。淫行はしたのである。ただ、相手が17歳とは知らなかったに過ぎない。ディテールの誤りを訂正するに乗じて、核心というべき事実までひっくり返してはいけない。
ことによると、essa さんは立件されなかったことをもって、淫行という語を封じているのかもしれない。仮にそうであれば、私はその立場を理解するけれども、誤解を招きかねないな、と思う。「立件されようとそうでなかろうと、淫行は淫行だ」と考える人は、無視できるほど少ないだろうか?
模倣犯のアニさんは堅実に東さんは犯罪行為はしてな
かった、と書いている。東さんは、刑法犯にはならなかった。しかし、淫行はしたということだ。→そのまんま東さん 続き（と、いうことらしいですので要注意）
みのべ博行さんの解説は、いささか怪しい。仕様書は、abbr 要素が略語であり、acronym 要素が頭字語である、ということしかいっていない。読み方に関しては、いろいろあるからスタイルシートで指定しようね（大意）という説明なのだ。仕様書が略語の読み方に一定のルールがないことを指摘している事実には、よく注意すべきだと思う。
関係ないけれど、まなさんが、妹のことを次女
と書くのはおかしい。たくさん妹がいて、その中のとくに上から2番目の妹を指定するためにそう書いているのだろうけれども、常連読者にはきちんと意味が伝わるけれども、やはりおかしい。次女というのは親を起点として使う言葉であって、姉が妹を呼ぶ場合には、そういわない。……と、書いてから不安になって辞書を引いたのだが、望む回答は得られなかった。本当のところ、どうなんだろうか。
- 次女
- 同胞の女の子の中で、上から二番目のもの。→長女・三女 表記：「二女」とも書く。
競馬が、競馬をよく知らない一般の方の話題になって盛り上がることについては大いに歓迎なのですが、生涯で一度も勝ったことがない馬が、ＧＩレースを勝った馬達よりも注目を集める対象になるというのはどうにも理解し難いものがあります。
武豊さんがこう書いたのは、あくまでも苦言を呈しておきたいという意図があってのことだろう。理解し難い
と本気でそう思っていらっしゃるわけはない。が、念のため、ちょっと書いておきたい。武豊さんの日記の読者には、文字通りの解釈をなさる方がいるようなので。
長らく弱かった阪神が、なぜ横浜やヤクルトよりも人気があるのか? あるいは、国内のパソコン販売シェアは NEC が首位を守り続けているのに、私が学生の頃、なぜか一般紙で報道されるのはソニーの VAIO が中心だった。結局その後も VAIO は天下を取れないままで、今では赤字事業に転落しかかっている。昨年はスズキのチョイノリがたいへん話題になったが、毎年売れ続けているカローラはなぜ注目されないのか。単年でもチョイノリとは比較にならないほどの利益を上げているのに。
ハルウララの人気はたしかに極端な例ではあるけれども、ようするに世の中にはたくさんの価値観があって、生涯で一度も勝ったことがない馬が、ＧＩレースを勝った馬達よりも注目を集める
状況というのは、別段、おかしなことではない。
「負けても負けても走り続ける」という物語に感動する価値観と、強い馬を褒め称える価値観は、いずれも珍しいものではない。一般化してしまえば、後者の方が強い価値観だといってしまってもいいだろう。平凡な勝ち馬は、平凡な負け馬よりもずっと有名だし、大勢の人に「勇気と感動」とやらを与えるに違いない。ただし今のノボトゥルーは、たくさんいる強い馬の一頭に過ぎない。これに対して、ハルウララは常識外れに負け続けている。「負けても負けても走り続ける」という物語における、史上最高クラスのヒーローなのだ。
普段はあまり表に出てこない価値観も、ヒーローが登場すればドカンとくる。ふだんは勝ちそうな馬にしか注目しない競馬新聞も、ハルウララの動静は記事にせざるをえなくなる。「勝つ馬が偉い」という意見はまったくその通りだけれども、しかし、「勝つ馬だけが偉い」というものではない。負け馬も、負けることを極めればヒーローになるということだ。
ＧＩレースで勝てば、たった1勝でも大きく新聞に載る。負ける方は、ちょっとやそっと負けるくらいでは無理だ。これが価値観の優劣の差だ。ハルウララは不世出の奇跡の負け馬なのだから、ちょっと騒がれるくらいは大目に見てやればいい、と思う。ただし、武豊がこのタイミングで苦言を呈したこともまた、正解だ。「本来、強い価値観は何なのか」を確認することは、浮かれて我を忘れがちな人々にとって重要なことだろう。
先に挙げたようにakiaryで入力すると改行全てに勝手にbrが入るのだけど、ローカルでソースを書いて貼り付ける人にはこれが問題になるようで。（多分この文章もタイトルの後に改行して入力してるので隙間がデカいはず）データがブッ飛ぶのが怖いので、オフラインでソース書く→それを貼り付ける→ログを自動作成→( ﾟДﾟ)ｳﾏｰという算段だったが、便利な自動改行が仇になるとは…。むぅ。cgiのソースを見てもさっぱりなのでbrがあるところを消しまくってみるか？（ダメです）
単純には、改行しなければいいんですね。私が Akiary を使うときには、いったんふつうに「改行あり」で作成した文書を、改行を扱える検索置換ツールを使って「改行なし」にしてから、フォームに貼り付けています。
ところで、いまのブームらしいのがblogというのだけはわかった。えーと、更新が楽なツールが出現したので、今までネットに触ったことがないような人でも利用できることに古参のインテリが不満たらたら。そのツールの普及によりCSSを意識するサイトが増えたが、その中途半端ぷりにCSSコミュニティ・W3C信者の怒りが沸騰点に。
というのは、現状とかなり異なっているような……。私が感じたのは「寂しさ」だったのだし、某 CSS スレも淡々とした反応でした。CSS がきちんとした形で普及するなんて、ありえないことだとみな思っていたはずで、予想通りに中途半端な使い方が広まりましたね、という感じなのではないかと。
「ダブルバインド」でGoogleすると上から2番目に登場する記事になって5年余り。「せっかく読んだのに意味不明だった」という感想を目にすることが増えました。これは個人的な備忘録であって、言葉の説明を意図した記事ではなかったのですが、状況を鑑みて全面改訂しました。（2011-05-27）
「ダブルバインド」を逐語訳すれば「二重の拘束」となります。他人の言葉を単純に解釈してその通りにしたら、その真の意図に反してしまい、逆に怒られる。その後も真の意図が明確に言語化されることはなく、怒られた人は「一体どうすればいいの?」と途方に暮れてしまう。これがダブルバインドの状況です。
例えば、あなたは未経験の部署に転属になった社員だとしましょう。「わからないことがあったら何でも質問してください」と上司がいうので、早く仕事を覚えようとして朝から晩まで質問攻めにしたら怒られてしまいました。上司の本意は「可能な限り自分で調べて、よく考えて、それでもわからなければ何でも質問してください」というもの。ずっと質問攻めにされたら自分の仕事が進まない。「それくらい察しろ。俺の迷惑も考えろ」というわけです。しかし、話はここで終わらない。
「まず自分で調べるべき」ならば、上司はマニュアルを用意して、「たいていのことはそれを読めばわかる」という風にでもしておく必要がありました。実際はそうなっていないとすれば、初めての職場に戸惑っている人が自分一人で調べられることなど、ほとんどありません。じつは「上司や同僚に質問して疑問を解消する」か「わからないなりに適当にごまかしていく」しかない状況だったのです。もちろん、部下のごまかしが破綻して勉強不足が露呈しても、やっぱりこの上司は怒ったでしょう。
結局、問題の根幹は、この上司が新しい部下の教育に必要な時間の見積もりを誤っていたことにあります。それなのに、部下がたくさん質問をすれば怒り、質問せずに失敗しても怒る。上司が自分の失敗から無意識に目を逸らし続ける限り、矛盾は怒りの種を撒き散らし続けます。
つまりダブルバインドとは、「他人の言葉の背景にある考え方を推察する能力の低さ」という聞き手側の問題だけが生み出すのではありません。「真意をきちんと説明しようとすると矛盾や問題に直面するので、無意識に言葉を単純化して、正解のない課題を押し付けてしまう」という話し手側の問題も大きいのです。たいていのダブルバインドは話し手側に大きな問題があり、聞き手側の努力では解決できません。
親と子、上司と部下、先輩と後輩など、権力関係のあるところにダブルバインドは生じやすい。とくに自分が権力を持つ側に立っていて、相手が自分の意図に沿わない行動を取ったときにこそ、ダブルバインドという言葉を思い出してください。
「ダブルスタンダード」とは、複数の価値判断の基準を持ち、相手や状況に応じて使い分けること。必ずしも「利己的な動機から自分だけに都合よく基準を使い分ける」ことを意味しないので注意。ちなみに、基準は2つとは限らず、3つでも4つでもダブルスタンダードといいます。
さて、ダブルスタンダードとダブルバインドの関係ですが、「相手によって基準が変わる」タイプのダブスタは、個々人にとってダブルバインドとは無縁です。一人一人は、いわれた通りにすればいいからです。
他方、「状況によって基準が変わる」タイプのダブスタは、ダブルバインドの具体的な現れ方のひとつかもしれません。しかし事前に「状況Aでは基準Aを、状況Bでは基準Bを適用する」というように、起こりうる全ての状況について指示されていれば、ダブルバインドの状況にはなりません。
読んでみたら面白かった。
私は天羽さんのやることに反感を覚えることが多いのだが、同族嫌悪のようなものなんだろう。大学も同じだし（天羽さんは私の13年先輩）、天羽さんが講師を勤める放送大学の図書館で、私は書架整理のアルバイトをやっていたことがある……そんな縁もある。でも、苦手なんだな。ひとつ疑問に思うことがある。他人に親近感を覚えることが稀にあるが、そのとき「好き」に分類される人と「嫌い」に分類される人がいる。その違いは何なのか。
天羽さんが読めない
といっているマイナスイオンという名の環境問題とエコロジーを考えるを私の IE6 に表示させてみたら、テキストも画像も問題なく読めた。たしかにマークアップには難があるし、無駄な全角空白が無数にあるので、音声系ブラウザの利用者には災難。たしかに、天羽さんの作成なさった文書の方が、ずっとよくできていると思う。ただし、サイトの表紙はひどい。見た目だけを考えてテーブルを組んでいるので、目次のあたりは音声系ブラウザでは意味の通じない順番で読み上げられることになる。
ところで、天羽さんは異次元人とのコンタクトが喧嘩別れに終ったことを不思議がっていらっしゃるが、私には当然の帰結に見える。先日の専門家の情報発信の話題に関して、私の発言は崎山さんの罵言を呼び寄せたけれども、ここにも謎はない。これは、「必然」ではない。しかし、「当然」ではあった。
以前、とある単純なデータ処理を「VB でやれ」という指示があって、いろいろ勉強を始めた。で、入門書を1冊やり終えたのだけれども、結局、その程度では仕事に使えなかった。半角空白で区切られた12万行×30列くらいのデータがあって、3列目のデータが一定の値以上になっている行の1列目と5列目のデータを抽出する、というのが課題の具体的内容だったのだけれども、awk の本を10ページくらい読んだら簡単に解決してしまったのでガックリきたことを覚えている。ごく単純にいうと、簡単なことをやるには簡単なツールでいい、ということなのだった。しかし課題が深化するにつれて、awk ではいささか無理が出てくる。結局、perl で片がついた。
perl は確かに、簡単なことをするには awk と比べて大袈裟だ。しかし、目的次第ではその大袈裟なところが効いてくる。経験的に、簡単なものは簡単な目的にしか使えない、と私は思っている。XML の活用範囲が広いのは、単に XML を利用する側の問題であって、XML 自体はつまらないものだ。XML が単純なものだから、XML を扱えるいろいろなアプリケーションが登場したわけだけれども、XML そのものだけでは何の役にも立たない。単なる静的なデータに過ぎない。HTML も、そう。WWW の素晴らしさ、というのは実のところ、HTML 自体の素晴らしさではない。XML や HTML のような例でもって、シンプルさと高度な利用方法を両立することは可能だとかおっしゃる方が出てくると、ちと困る。
単純な仕組みで高度な作業をするのって、ものすごい天才スキルが要求されるよね。
と otsune さんが書いていらっしゃるけれども、まさにその通りだと思う。awk に耐えられずに perl を勉強したのは、まさにそういう理由だった。awk をマスターすれば、私が音を上げた程度の課題は、難なく解決できたのだろう。しかし、私には無理だった。
ところで、これだけ大勢の人が言及したのは、高林さんがUnix 上で広く使われているツールとしてはTeX, Emacs, sendmail, bind, perl, gnuplot, procmail などは、役に立つツールであると同時に、その 複雑怪奇な仕様によって長年に渡ってユーザを苦しめ続け、バッド ノウハウの温床として悪名が名高い。
と、名指しで書いたこともひとつの要因であるように思った。
ちなみに私は TeX（注：私が使ったのは正確には pLaTeX だから、結城さんの定義では「グッドラッパー」にあたるものしか扱っていないことになる）と Emacs と perl は少しだけ触れたことがあるけれども、いずれも何の不満もなかった。これらには、シンプルな目的を実現するシンプルな方法が用意されていて、そんなに非難されるようなものとは思えない。
Web デザインにおけるクロスブラウザの問題とか、そういった本来の技術仕様と関係のない部分における手間は、なるほど、なければないに越したことはない。しかし高林さんが挙げたのは、そういう例ではなかった。私は pLaTeX も Emacs も perl も基幹部分についてはよく考えられたツールだと思っている。わけもなく奥が深い
わけではない。おそらく、もっと整理することはできるのだろう。しかし、複雑怪奇
はいくらか改善できるとしても、奥深さは解消しようがないのではなかろうか。
Amazon のカスタマーレビューというのは、あまり信用できません。おかしな解説をしている本であっても、読者が満足すればいい点がつくわけですから。「うまく騙した者勝ち」になってしまっています。その点、2ch の技術系板にある書評系スレには、「わかっている人」が内容を監査して感想を述べている発言がたくさんあります。
スレに登場した本をほとんどすべて紹介しています。それがいいところでもあり、悪いところでもあります。
基本的に評判のよかった本だけが紹介されているので、紹介されている本の数が適度に少ない。
しばらく更新されていないのが残念ですが、入門者向けの本にはたいてい定番があるので、最近の本の紹介がないことを気にする必要はありません。とくに HTML や CSS の場合、HTML4.01 が勧告されたのは1999年だし、CSS2 に至っては1998年です。定番といえる本が、既に出揃っています。そもそも書評サイトの類を利用するのは、主に自分の選書眼が怪しいと思っている方でしょう。ならば定評ある本できちんと基礎を学ぶことが大切。そうすればその後は、最近の本を自力で適切に選ぶことができるのではないか。
このサイトの難点は、2ch のスレが情報元なので、「入門」「初級」といった紹介文句の印象よりは実際のレベルが高い本が多いということ。ホントの入門レベルの方にお勧めするような本はあまり紹介されていません。きちんと勉強する意欲・素養がない方（とりあえず＊＊できればいいや、みたいな方）には、つらいことになります。
ところで、HTML や CSS の解説書に嘘っぱちを教える本が多いことは、よく知られています。
紹介した文書はいずれも4年ほど更新が止まっています。それはなぜかというと、状況が進展していないからです。1998年に「スタイルシート Web デザイン」という傑作が登場したというのに、その後ちっともダメな本が減らなかったのです。ここ数年、少しずつまともな本も登場してきましたけれども、いまだに大半はいい加減な本です。よく注意してください。
……とまあ、こんなところで書いてみてもですね、当サイトの読者は既に勉強なさっている方が多いでしょうから、あまり意味がないだろうと思います。そこで、一番広報力の高い場所、Amazon のレビューにいろいろ書こうと思っています。4年前には「この本はダメ」というのは簡単でも、（とくにホントの入門レベルの方には）代わりに薦める本がありませんでした。しかし現在は違います。「HTMLとスタイルシートによる最新Webサイト作成術」があるのです。「一週間でマスターするCSS」があるのです。というわけで、少しずつ書いていく予定。
Amazon のカスタマーレビューは信頼できないと書きましたが、エディターレビューは参考になります。意外に、ほめていない書評があります。批判には必ずフォローが付属しているので印象は薄まっていますが、読者はそこをうまく見分けなければなりません。字数制限がないので、力作が多数あります。提灯記事と決め付けて読み飛ばすと、損をしかねません。ただ、HTML や CSS について、きちんと仕様に目を通している書評担当者はいないようなので、本の内容が技術的に正しいのかどうかという点についての情報は得られませんので要注意。
考えてみると、内容が技術的に正しいのかどうかというのは、オンライン書店系サイトの書評からは一番得にくい情報であるように思います。あるいは出版社の書籍紹介にも、そんな情報は載っていません。要注意、であります。
各所の質問スレ回答者には便利なサイト。質問者には、多分あまり役に立ちません。ただし FAQ だけは例外。一読の価値あり。
本日午後、労組は予告通りにストを打った。私のような非組合員は、製造現場などにはほとんどいない。ガランとした工場は声がよく響いて、なんだか楽しい。
ストだからといって、組合員が楽をできるというわけではない。工場の屋上に集まって、労組の偉い人の演説を延々と聞かされ、「ガンバロー」の大音声とともに何度もこぶしを天に向かって突き上げなければならない。組合員にとっては闘争も仕事の内とはいえ、いやはやお疲れ様です。
やや蛇足になりますが、HTML4.01仕様書で、del要素とins要素は、それが変更点であるということを明確にするようなスタイルで表現されるべきであるとされています。しかし、del要素に対してのスタイルの例として、「表示しない」ことで変更点であることを表現するというものが挙げられているのですが、表示されなかったら明確ではないと思うのですがね。取り消し線をひくなど、以降に続く表示例のほうが相応しいと思います。
表示されなかったら明確ではない
という意見には賛同できない。書籍が版を重ねる際に記述を修正する場合には、削除された文章を隠すのが通例となっているが、yuu さんは「元々何らかの記述があり、それが削除された」ことを示すのが del 要素の役割とお考えだから、引用したような意見になるのだろう。だが、del 要素の役割は「内容の無効化」ではなかろうか。元々どのような記述が存在したのかということは、重要ではない。むしろ、del 要素の内容は存在しないものとして扱うべきではないか。
del 要素の表示・非表示に、たいへん示唆に富む例が紹介されている。
- ほげほげはぴよぴよである。
- ほげほげは
<del>ぴよぴよ</del><ins>ふがふが</ins>である。- ほげほげはふがふがである。
- ほげほげは
<del>ぴよぴよ</del><ins>ではなく、ふがふが</ins>である。- ほげほげはではなく、ふがふがである。
さて、望ましい削除と追記の方法はいずれか? 仕様書に deleted text may not be shown at all
とあるのは、まさにこういった問題を予見していたからではなかろうか。表示結果から要素の使い方を考える……というと、本末転倒なようだけれども、一概にそうとはいえない。仕様書の解説は、del 要素の意義は「削除の告知」ではなく「内容の無効化」だ、と端的に表現している。
del 要素と ins 要素は版管理の必要な文書を想定しているので、過去の記述を断りなく消すことが一切できない状況が前提となっています。通常の文書はそういった制約下にありませんから、基本的に del 要素などを使う必要はないでしょう。また音声系ブラウザの場合、del 要素の内容をいちいち読み上げられる現状は、かなりうるさく感じます。削除訂正された箇所は、とくに興味のある人だけが知ることができれば（例えばユーザスタイルで del 要素の読み上げを許可するなど）十分かもしれません。
「元々どのような記述があったのか」を重視する場合には、del 要素ではなく、他の方法を用いるべきではないかと思うのです。一般に Web サイトの目次は削除・追記が頻繁に行われますが、del 要素や ins 要素でそれらをいちいちマークアップしている例を、私は見たことがありません。目次の変遷は「更新履歴」などで示すのが妥当なのであって、「削除」だから del 要素、「追記」だから ins 要素、という単純なものではないだろう、と私は考えます。
あと、この手の間違つた論法を平氣で用ゐる連中は、どうして同じやうな文體を用ゐるのだらう。「〜しちゃいました」「〜なんだよね」「〜なんですよ」等と、とても押附けがましい文體を、彼等は用ゐる。アレ氏とかホラ氏とか、自稱お兄ちゃんとか。もちろん、と××氏もさうだ。
伏字に大笑した。面白い。ことによると別のどなたかのことかもしれませんが、私は、これは私のことをいっているな、と思いました。
引用部分とは関係ありませんが、と言ふか。
という野嵜さんの書き癖は、主に私に対して伝染力が強くて、闇黒日記を読んだ後に何か書こうとすると、すぐに「というか、」と書いてしまう。私が「というか、」で文章をつなげたときは、たいてい直前数時間の内に闇黒日記を読んでいます。（……なんて書くと、すぐに全面的に信じてしまう人がいて困る。多少の誇張は割り引いて読んでください）
- 999 名前：名無し草[sage] 投稿日：04/03/10 22:51
- 問題：「と××氏」の「××」に当てはまる文字は何ですか？
- 1000 名前：名無し草[] 投稿日：04/03/10 22:56
- ほほ？
あっ。
順に検証してみよう。HTMLで書いた場合、本当に容量が重くなるか？これはメールが使われる状況に依存するはず。友人・知人同士の一言メールに、いちいちタグを打っていたらそれは重くなるだろう。まずマークアップする価値のない内容しかないから。
でも、それがメールマガジンのような、ある程度構成のある内容を伴っていたら、全く逆のことが起こる。ある程度の規模を持つメールマガジンは、それぞれ内容に見出しをつけている場合が多い。ある種の記号で見出しに相当する文字列を囲んだり。これは、グラフィカルな要素を認識できる人間に大してはアクセシビリティ向上の効果がある。が、それ以外の場合（例えば読み上げ）は、こういったグラフィカルな要素を示す文字列は障害となる。また、こうしたグラフィカルな要素を配置するよりは、HTMLを使用して適切に各内容をマークアップしたほうが、健常者にとってもアクセシビリティ向上に結びつく。
ちょっとこの「検証」は無理があるのではないか。たしかに記号文字の類で簡単な装飾をしているテキストメールは少なくない。しかし、まともにマークアップした場合のファイルサイズ増大と比較すれば、微々たるものだといえる。当サイトのマークアップはかなり単純なものとなっているが、それでも全文字量の2割弱をタグの記述が占めている。テキストメールで2割弱も装飾のための記号文字を用いたら、大変なことになる。
以上の論証では、HTMLを解釈しないことで得られる強いメリットは特に得られなかった。
メリットが云々というより、HTML メールには明白なデメリットがあるということ。
現在主流のグラフィカルな HTML 文書を適切に解釈するためには、相当大規模なソフトが必要になる。大勢が何年もかけてブラウザを開発してきたが、それでも IE にせよ Opera にせよ、十分に仕様を満足しない。メーラーが独自の HTML 解釈エンジンを積むことに躊躇するのは当然であって、基本的に HTML 文書を解釈できるメーラーは、視覚系の WWW ブラウザを適宜利用するものがほとんどだ。すると、いくつかの問題が生じる。
まず、ほとんどのブラウザは、利用者の声に応えてデフォルトで JavaScript が有効。メールというのは、基本的に勝手に送られてくるものだ。したがって、JavaScript が有効な状態で HTML メールを読むのは危険だ。信頼できない Script を実行させられてしまうことになる。
また多くのブラウザでは、画像の表示もデフォルトで有効。HTML メールはしばしば画像を利用するのだけれど、このような画像はメール本文と一緒に送れない（通常 HTML 文書は添付ファイルから画像を呼び出すことができない）。ではどうするかというと、適当なサーバにあらかじめ画像を置いておく、ということになる。これがなぜまずいのかというと、SPAM 業者に宛先の有効無効を判断する情報を与えることになるからだ。
俺は、そもそもなぜHTMLを解釈しないメールソフトなんかが生き残っているかが不思議なのだが。何故？
マークアップなんて、本来的には読者の要求の外にあるのではないか。そもそも HTML 文書がブラウザのデフォルトスタイルで表示されると「味気ない」と思うのは、MOSAIC 以来、視覚系 WWW ブラウザ開発者らが進めてきた戦略にはまって妙な先入観が植えつけられているからに過ぎない。HTML 文書を解釈するソフトがいつまでもテキストブラウザだけであったなら、CSS などというものも登場しなかっただろう。メールに、カラフルなあれこれとかマークアップによる文書構造の明示などを期待している人が、あまり多くないということではないか。
春闘が佳境に入った。明日から組合員はストに突入するのだそうだ。他人事だけに、何だかワクワクする。みんな、そんなにお金に困っているんですかね。とにかく凄いことになるぞ。
今年度は久々に黒字決算となる。そこで組合は、ベースアップと2.8ヶ月（赤字決算となった過去2年は約2ヶ月だった）の夏季一時金を要求した。当然、経営側の返答は「バカいわんでくれたまえ」だ。無い袖は振れない。というわけで、長年の鬱積を晴らす長期間の闘争となりそうだ。おそらく4月まで、ことによるとメーデー前後まで延々と続くだろうから、新入社員はびっくりするだろうね。社内中に赤い布が翻っているわけだから。
うはははは。まるでタイムカプセルの中を覗き込んだような世界。
以前、黎明日記で紹介されていたcss.maxdesign.com.auを一通り見た。CSS Tips の事典みたいなサイトで、眺めていて面白かった。最初の頃はいちいち CSS を読んでいたのだけれど、疲れたので終盤はひたすら表示結果ばかり見ていたような気がする。
ところで、久々に JavaScript を有効にしたら、いくつかのサイトに Google アドセンス広告が表示されていることに気づいた。
この手の文書は、ややもすると揶揄的な文面になりがち。ご紹介した中にも一部にヒートアップした状態で書かれたと思しき文章がありますが、まずまず安心して読めるのではないかと思います。ただしですね、この文書が無断リンク禁止派に対して十分な説得力があるかというと、そうでもないのではないかと思います。宇園まことさんは価値観の差異の埋め難さに一定の配慮を払っているものの、結局、多くの箇所で細野数学の「これは当然だよね」式の省略をなさっています。ちょっと残念。「当然」が通じないのが、価値観の違う人とのコミュニケーションの特徴なんです。
とはいうものの、勢いあまってミイラ取りがミイラになった感のある（かの有名な）世にも奇妙なネットマナーよりは、よほどお勧めできるのではないかと。
ご冥福をお祈りいたします。
毎年、こうして何人もの方が亡くなられます。この死を無駄にすまいと、毎回、心に刻み込むのに、なぜ同じ過ちを繰り返すのだろう、私は。
ところで、死んでお詫びすることを無責任という人は多いけれど、その批判は無責任じゃないのか。と、思う。
今日は忙しかった。
私は IME Watcher を使っています。
