2002.07.22
Sphere - This is an immortal holy jewel.のPleasure! TRX850 - About this site - 普及しないCSSとか，Latest topics > Past > 2002 > 07 - outsider reflexの22nd dayのWeb 標準化とか，新・戦々恐々の７月２２日 イケデ ザリンク集更新とかを読んで。
どれも愚痴に聞こえるので，私も愚痴を。
職場でこんな話が出ました。
情報のユニバーサルデザイン研究会なるものに，参加させてもらい，研究会で，今年度いっぱいかけて，ページ作成のひながたを作ろうとしています。
ユニバーサルなページを検討するには，やはりhtmlから理解しないと駄目みたいで，HTML4.01の定義等一つ一つの意味を教えてもらっているところです。(^^;;;
情報のユニバーサルデザインの本質は，正しい日本語でコンテンツを作るということなのだ，その記述の仕方の規則の一つにhtmlがあるんだ．．．
北大の山本先生曰く
正しい日本でコンテンツがつくられると，日本語の読上げも正確になる，外国語翻訳も正しくできるようになる，それを読上げれば英語圏の視覚障害者にも情報を伝えられる
でも，この話から発展して出たのは，見栄えの話ばかりでした。
そこで，いちおう，CSSで出来得ることは，物理的な視覚効果としての見易さの追求であって，そもそもの文書構成をどうこうなんて出来ません。意識しなければいけないのは，「なぜCSSを使うのか」ではなく，「なぜHTMLで書くのか」だということです
，なんてことを言ってみましたが，その返答は，なぜHTMLで書くのか。それは「見せる」ためです。CSSは単なる役割分担です
，なんてものでした。
これが，自称とはいえW3C信者からの返答なのですから，CSS普及の障害がW3C信者がどうこうって問題ではない気がします。いや，論旨的に逆ですが，障害にはなってますが。
さらに，こんな意見までいただきました。
CSSがダサいというのは、CSSだけでレイアウトの全てを行うのは表現が制約され、非効率的だからです。
テキスト制御だけの話じゃありませんよ。CSSで「レイアウト」の話です。誤解なさらないように。グラフィックやテーブル使ったほうが綺麗で早く作れることもあるわけです。汎用CSSに頼る人なら、グラフィックやテーブル使った方が、簡単にページ作れますしね。それはそれでアリだと思うのです
別に私はCSSでのデザインがダサいとは思わないし，テーブルのほうが簡単に作れるとも思わないし。
でも，この辺の意見を聞いて思ったのは，世間一般の認識は，こんな意見を聞いても受けいられるくらい，序盤の話しを理解していないのだなぁ，ということです。
これまでPiro氏や野嵜さんが語ってきたことが，余りにも広がっていないということに気がついて，ちょっと悲しくなりました。
私みたいに，HTMLどうこうより，日本語を正しく書くためにJIS-HTMLで書いといた方がいいぞ，みたいな中途半端な意見じゃ広まりようもないんだろうな，と自戒したり。
そんなわけで，CSSコミュニティの諸氏には，より一層の活躍を期待したいことろです。
2002.07.17
お笑いパソコン日誌の2002/7/17 AM 8:30付けの記述より。
『座頭市対用心棒』の例を引くまでもなく、この種の映画が成功することは希である。つか、ないんちゃうか。
独立した二つの話の主人公の競演，という意味では，成功実例はないとは思う。でも，この映画については事情が違うと思われ。
日本では知名度が低いけど，バットマンとスーパーマンは，コミックス上ではわりとしょっちゅう喧嘩している仲なので，この二人の掛け合いは，十分定番で通用するのです。
二人の競演で有名な作品ではJLAなんてのもあります。たしか，去年カートゥーンネットワークでアニメが放映されていたはず。
邦訳コミックスでは，SUPERMAN/BATMANでコミックスBATMANとTHE MAN OF STEELのクロスオーバーが読めますし，KINGDAM COMEやBATMAN DARKNIGHT RETURNSみたいな名作でも二人の対決が見られます。
バットマンとスパイダーマンの競演となると，確かに座頭市対用心棒
みたいで，大丈夫か，と心配になります。しかし，バットマンとスーパーマンの場合は，むしろルパン対ホームズといった感じではないでしょうか。
2002.07.12
agenda〜非精神的人間の反撃〜の続続・文書構造と無関係な表題（HTML）（公開：2002年7月11日）より。[see 要約文]
DDTさんが要約文と本文を明確に区別されたように、私も明確に区別します。本文ではないということをです。「User Empowerment and the Fun Factor」という「Chapter」の、本文ではない部分と認識します。つまりこの見出しと共に形成されるこのChapterのheaderであり、それとしてマークアップ（グループ化）可能であると思っています。そうであるなら、それが意味するのはISO-HTMLのdivnを考えると（以下略）。
ごめんなさい。何をいわんとしているのかよく判らないです〜。できれば以下略しないでほしかった。以前，近藤さんの文章も結局判らずじまいだったし，読解力に欠けるのか，俺。
とりあえず，その他，図などの参照されたオブジェクトの扱いについては前回も書いたように同意でして
（強調DDT）というので，私とは違う見解らしいのはわかるのだけれど。
要約はmeta name="description"でHEAD要素内に書くべき，ってことでいいのかしらん？
2002.07.09
もひとつagenda〜非精神的人間の反撃〜の続・文書構造と無関係な表題（HTML）（公開：2002年7月8日）より。
ちなみに、このようなブロックの登場が文章構造的に間違っている、というのなら、tableのcaption要素を考えてみて下さい。文書中に挿入されたオブジェクトがたまたまtable要素であればそれを表題する要素をマークアップできるではありませんか。
この件について，各地で議論されてますソースのマークアップ方法と根は同じものがあると思うので，別文章で。議論については，徒書のソースコードのマークアップに詳しいので，そちらで。
さて，テーブルにしても，画像にしても，はたまたそれ以外の挿入物（OBJECT要素やPRE要素とか）にしても，その文章の構造と挿入物の構造は別物と考えなければいけません。挿入物は，あくまでも挿入されているだけの一個の独立したものですから。
まぁ，画像の場合，文章中の言葉を，文字コードではなく，絵で描いた文字（変な日本語ですが）に置き換えるために使うこともあるでしょうから一概には言えません。しかし，こういうときはalt属性でその画像に描いてある文字を設定するため，挿入物ではなく文字の代替と考えて問題ないでしょう。
それ以外の「挿入物」は，文章の構造と直接関係はしてきません。これらは，参照しているに過ぎないものだからです。
参照されるものは，文章の中に挿入されたときは「下記」とか「下図」とかという言葉で示されますが，書籍等で別ページに描かれているときは，「別表」とか「図１」という言葉で示されます。何処に参照物があるかで文章の表記は変わりますが，それで意味が変わるわけではありません。
以上を踏まえてインラインではないプログラムソースの記述について考えてみると，ソースの内容でマークアップが変わってくる気がします。
コボルなどで，行頭のスペースの数も重要だ，とかならPRE要素になるでしょうし，行毎の記述が重要，とかならOL要素もありでしょう。特にこだわりがないなら，テキストで書いてOBJECT要素ってのが一番無難かと。
2002.07.09
先の文[see コラム]について，反応を確認。agenda〜非精神的人間の反撃〜の続・文書構造と無関係な表題（HTML）（公開：2002年7月8日）より。
視覚的・参照的効果を狙ってのもの。その場合ならリンクにしてしまえば良いのでしょう。
意図がちゃんと理解されているようでよかった。
しかし、です。
Summaryと表題されたこのブロックは、末尾に置かれたのでは無意味です。
あれ？それほどちゃんとは伝わってないのかもしれない。
さて，見出しがある文章の場合，意味的には見出しと本文は同等とみなされます。そして，その本文の要約もまた，見出しと同等と考えられます。
つまりは，その見出しに係る文章には，完全版と要約版の二種類があるわけです。
以上を踏まえて考えると，ニールセン博士の件の文書[see User Empowerment and the Fun Factor (Alertbox July 2002)]を読むとき，我々は下記のような構造をもつ文章で構成されていると脳内補完して読んでいるのではないでしょうか。
<大見出し>User Empowerment and the Fun Factor</大見出し>
<小見出し>Summary</小見出し>
<p>要約文</p>
<小見出し>The text</小見出し>
<p>本文</p>
そんなわけで，私がマークアップするとしたら，上記のように本文に見出しを加えて（ディスプレイの有無はどちらでもいい），下位の見出しレベルを調整するか，要約文書と完全版文書の二つを作り，リンクを張るか，どちらかでしょう。
余談ですが，この構成はある意味，FRAME要素とNOFRAMES要素の関係に似ていると思います。互いにどちらかに含まれる内容ではなく，どちらも独立した一個の文章（内容）という点で。
[next メタ情報？]
2002.07.05
agenda〜非精神的人間の反撃〜の文書構造と無関係な表題（HTML）（公開：2002年7月5日）より。
先頭に交通標識のような画像があり、alt属性に「Note:」と記述してある。The Web Kanzakiでは、このブロックは各節の末尾に置かれているので何ら問題があるとは思わないが、書籍等では多くの場合「点線等で区画されたブロック」はしばしば節などの途中に登場し、表題がついている。章番号、節番号などからは独立した表題だ。
このような、章や節などの文書構造とは無関係な表題は、なにでマークアップすれば良いのだろうか。
この手のコラムが書籍で節の途中で出てくるのは，視覚的・参照的効果を狙ってのものと思いますが，意味的には節の末尾に（若しくは，全く別の文章として）書かれているものと考えられます。故に，（本文とコラムの関係にもよりますが，）見出しとしてマークアップして問題はないと思われます。
webサイトで書籍と同じようなことをしたいなら，CSSで調整することになるのでしょうが，現状では出来ないンですよね。CSSはよく知らんけど。CSSに差し込み機能があると便利なンですけどね。
このNoteと表題されたブロックは、文書構造において章や節を意味するものではないが、このような形式はよく見られ、批判の的になっている。
このNoteが見出しでも何でもないなら，見出しとしてマークアップすることが間違いですし，中見出しであるなら，上位の文章が完結しないで現れることが異常なので文書の推敲が必要でしょう。
先にも書いたことがありますが{see ADDRESS要素の出現位置]，書く位置が決まっているため慣例として見出しを省略出来るような内容であれば別ですが，そうでないならこのような文章の書かれ方はおかしいものです。
考慮すべきはHTMLのマークアップではなく，意味的にその位置に書かれるべき文章かどうか，ということです。
[next 要約文]
2002.07.02
ねこめしにっきのディレクトリサイズにみる恐怖@2002/07/02 - 03:55より。
つか、このご時世に 15MB なんてケチくさいのヤメてほしーな。あ、今思いついたけど、加入からの年功序列で容量を増やすとかって、わりとナイスアイデアな気がしませんか？（しません）
加入直後は3MBytesで，１ヶ月毎に1MBytes追加とか。
そうすると，私の場合，３年半位だから45MBytesくらいか。すごいな。
もっとも，リソースの総容量みたら1.9MBytesとかなんで，全く問題ありませんが。
容量が欲しいだけなら，WAKWAKざんまいで50MBytes貰うのが安いのかな？