Strict-HTML スレッド 3.2 (W2C Recommendation)

書いてたら長くなったので、茶ぷろだに投稿してきました。

http://members6.tsukaeru.net/xelvis/txt/headings.txt

皆様のご意見をお聞かせくださいませ。

フォントサイズの指定の仕方には、
SI単位(国際単位系)を使うのが世界標準です。
「pt」,「px」,「em」などの単位は認められておらず、
「cm」を使わなければなりません。

>>277
そのまま引用でいいんじゃネーノ？

>>277
classで「引用の見出し」とマークアップするのが一番良かったりして。

>>277
blockquote の中は別世界、ということにしてそのまま。

ってゆーか、不思議系の文章を引用する時も困るんだよなあ。
font -> em などと勝手に修正していいものかどうか。

引用するのは内容なんだから
基本的な構造さえ維持してればマークアップに気を遣うことないんじゃ。
fontが明らかに強調目的ならemにしてもいいと思う。
というかせざるを得ない。

＞blockquote の中は別世界
それ考えたけど、自分の場合は(2)になる。

>>277
俺も(1)だな。
引用部分内は他人の文章じゃん。
自分の文章の見出しと他人の文章の見出しが
見出しのレベルの整合性を持っている必要はないと思う。

>>282
引用って「部分」だと思うんだけど、「一つの文書」になっちゃうの？

>>283
文書でも部分でも最上位の見出しならh1が適当かなと。

基本的には>>280の立場で。

>>284
なるほど。でも >>280 の「引用の見出し」は構造見れば解ることだから
わざわざ class をつけることはないかもと思った。

>>282
強調なのか弱調(?)なのか定義語なのか単に色を変えたいだけなのか
はっきりわからない時があるんだよね。
そーゆーのも全部まとめて em にしちゃっていいのかなーと。

# まあ、font 要素を無視するのも手なんだけど。

>>286
「マークアップは筆者による」ってのはどうかな。
よくあるじゃん、「傍点は〜」っての。
断り書き入れて、原文の URL とか入れて
読者が原文を参照できるようにしてけば、大きな問題はないんじゃない？
元々マークアップされていない一般書籍や PDF 文書から引用する場合は
それこそ著者が勝手にマークアップするしかないわけだし。

>>287
それが最善かも。

(3)だと思います。blockquoteはテキストを引用するもの(仕様書参照)でタグを引用するものではない。テキストは原文のままであることが求められるが、タグは柔軟性が許容される。

引用する際の文脈も無視できないとﾁｮﾄ思った。
たとえば以下のような日記の構造だとする。

<h1>バイク便日記</h1>
<h2>4/24 (水)</h2>
<h3>はれ</h>
<p>総走行距離245km、燃費22km/l。思ったより市街地の渋滞がひどかった。</p>

これを他の人が参考にして、表を作ると考えたらどうだろう。

<blockquote>
<table>
<caption>○○市のバイク便の燃費</caption>
<thead>
<tr><th>日付(曜日)</th><th>走行距離</th><th>燃費</th><th>メモ</th></tr>
<tbody>
<tr>
<td>4/24(水)</td><td>245</td><td>22</td><td>思ったより市街地の渋滞がひどかった</td>
</tr>
</tbody>
</table>
</blockquote>

こういう形を引用と呼ぶべきではないかも知れないけど、
必要な部分だけを抜き出して比較したいときなどは
元の文書のマークアップを踏襲しない方がよいな、と思った。

>>290
その場合はq要素の方が適切では。

>>291
うむむ。
やはりそれぞれのtd要素に対してqでマークアップするべき？
なるべく高次の親要素に引用であることを示すマークアップを入れた方が
スマートだと思ったんだけど。
trやtbodyにcite属性が使えないからなぁ。

話それちゃってｺﾞﾒｿ。

>>290
　マークアップそのものは、新しい文書や文書の HTML / XHTML の仕様に基づいて
引用者が書き直すべきだが、元々「表」ではないデータを「表」にするのは
マークアップ上の問題ではなく、引用の仕方として問題がある。

　どうしても（自分で表形式に書き換えた）表のデータの出所を明らかに
したければ、データにリンクでも付け、「<cite>ドコソコ</cite>の
<q>○○</q> との記述に基づく」と解説を書くべき。

>>277
　リンクできる WWW 上の HTML の場合、俺は可能な限りリンクを張って
ごまかし、4 になるようにしている。どうしても見出しを引用せねばならない時は、
3 にしている。

＃引用は、引用先の文書が主、引用が従となるように書かかねばならない、という
　引用の原則から、引用文は (他者の著作物であるが) 引用先の文書の一部、
　という解釈

…早く XHTML 2.0 が勧告されてレベルを気にしない見出しが使えるようにならないかなぁ…

みなさんのご意見を参考にして、俺もちょっと自分で考えてみました。

http://members6.tsukaeru.net/xelvis/txt/headings2.txt

ひきつづきご意見もとむ。

>>277-294
blockquote の中の見出しを h1 などでマークするのは宜しくないと思います。
CSS の counter で見出しに番号を振るような場合や、
ブラウザの見出しジャンプとかの機能なんかを想定すれば
解ると思うんですが。(まぁ、blockquote h1 を特別扱いする手はあるけど)

つーことで、h1-h6 は「本文の構造を作る」見出しのマークに対してのみ
用いるべきだと漏れは思います。

<h4>4月1日</h4>
<p>晴れ。</p>
<h4>4月2日</h4>
<p>曇り。</p>

を引用するなら、

<dl>
　<dt>4月1日</dt>
　<dd>
　　<p>晴れ。</p>
　</dd>
　<dt>4月2日</dt>
<dd>
　　<p>曇り。</p>
　</dd>
</dl>

辺りが適切ではないかと。

いっそ別ファイルにしてobjectで挿入(w

>>297
(・∀・)ｿﾚﾀﾞ!

>>297
そんなことする位ならば、pre要素化するでしょ。
面倒だから俺はそうしてる。

全く持ってスレ違いだけど。

　引用元に直リン張って「ココを先に読め！」じゃ駄目なの?
　引用元がデットリンクになったら素直に諦めるって方向で。

…やっぱりスレ違いだ…。

>>295
引用部がはっきりしないのでよろしくない。
> <p>以下は、××さんの日記の引用です。</p>
という説明がある限り、以下の文は"××さんの日記"という引用のひとまとまりであるはずである。>>289で解決してしまっていいと思う。

>>290
これは、引用ではない。まとめである。よってblockquoteもqも不適切。

>>296
"見出し"構造と"リスト"構造の用法は必ずしも一致しない。
<h1>見出し</h1><p>内容</p>
この場合見出しは内容の要約や地位を表す。
<dt>A</dt><dd>B</dd>
この場合A=Bであることを表す。

blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。

>>302
> <dt>A</dt><dd>B</dd>
> この場合A=Bであることを表す。

そんなことはないよ。定義リストはもっと柔軟に使ってよいもの。

> blockquote 内の heading 要素を特別扱いするほうがより汎用的に対処できるかと。

もしこれを認めてしまうと、例えば「メニュー表示用に見出しを抽出したリスト」
なんてのも h1-h6 でマークしてよいことになるだろうし、
同じ論法で「文書本体の構造を示す h1-h6」以外の h1-h6 を
(blockquote 内のみならず、他の要素内でも)
勝手に使って良いことになってしまうでしょう。

そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
見出しを抜き出した目次の作成なんてのは一切不可能になってしまいます。
これでは h1-h6 を定義した意味がありません。

>>303
>「メニュー表示用に見出しを抽出したリスト」
リストを見出しとしてマークアップすることは不適切。"'見出し'構造と'リスト'構造の用法は必ずしも一致しない。"というのはそういうことです。

> そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
引用の文章であっても程度の長さがあれば、折りたためたほうが便利ですよね？

>>303
　結局の所、引用先の文章にとって、h1〜h6 でマークアップするに
相応しいかどうか、と言う事になるんでしょうか。

>>277
　引用文の見出しは blockquote の title 属性に書く、という方法を提案。

>>303
> そうすると、見出しジャンプや見出しを用いた本文の折り畳み、
> 見出しを抜き出した目次の作成なんてのは一切不可能になってしまいます。
自分でそういうスクリプトを書いていて
これを行う際に blockquote 内の見出しは必要ないと思った。
たとえ見出しレベルの矛盾を解決しても、
やはり著者による本文の見出し構造とは直接関係ないものだ。
俺は最終的に blockquote 内の見出しは見出しリストから外すことにした。
特別扱いってより、無視って感じ。
どうやったってなんかしらの矛盾を抱えるものだと思う。

世界の視線はホームページ制作王に集約されている。
21世紀のWEBは制作王が統治するのだ。
君達も先見性に目覚めるべきだ。

>>301
「以下は〜引用です」という文章をとっぱらえば問題ないと思いますが。
それから、引用文の見出し（h1〜6）と本文（blockquote）に、
title="××さんの日記より"という属性をつけてやれば、より明確になるし。
あとは、全体を<div class="quote" title="××さんの日記より">で囲ってやる
という手もあるけど、Strict的には邪道かな。

>>302
> blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。

文書を利用するのは著者自身だけではないので、そういうコンセンサスが得られて
いない以上、避けた方がいいと思います。
（たとえば他人の書いた文書の見出しを自動抽出して目次を作ったりすることも
ありえるので）

あのさ、これを読んでて気がついたんだけど、英単語の前後に半角スペース入れてる人いるよね。
>>306さんとか。
これ凄く読みやすくて自分も今度からそうしようと思ったんだけど。
Strict 的には半角スペースを入れるのはNGっすかね？（意味の無い半角スペース）
だからといって、 CSS で letter-spacing すると一文字一文字離れちゃうし…。

>>309
前後の半角スペースまで英語の規則と考えればアリか？

>>309
OK。ちなみにCSSでやるつうことは英単語部分に汎用マクアプするってことだろ。
ならpadding使え。LRのな。

>>309
CSS3 text で検討されてはいる。
http://www.w3.org/TR/2001/WD-css3-text-20010517/#text-autospace-prop
スペース入れるのが Strict 的にどうなのかは俺にはなんとも判断できないけど。

>>312
スペースを入れているサイトから引用する時に
スペースを削っていいのか悩む時がある。

スペースを入れていない人は
逆の事で悩むのかもしれないけど。

>309
以前は僕も半角スペース入れてたんだが，読み上げブラウザで
「2 月」が「に つき」と読まれたり，「A 君」が「えー きみ」とか読まれるので今は全部詰めるようにした．

>>314
どっちにしろそれはスペース空けるべきところじゃないと思う。
2月もA君もひとつの単語でしょ。

要素や属性名を書く時なら自分はcodeでマークして
padding 取ったりフォント変えたりしてたけど、
それ以外となるとやっぱりスペース入れるかな。

>315
それはまあそのとおりで，以前は空けるべきじゃなかったところも空けてたのはまずかった．
で，今は，ものによって単語と見なせるかどうかを考えるのが面倒
（というか，自分の中で基準を完全に統一するのが難しい）ので，とりあえず全部詰めるように．

>>313
漏れは >>303 でもそうしてるけど、元の文にスペースがなくても入れるよ。
句読点とかマーク付けとかは、引用する側の体裁に統一して構わないはず。

>>308
>「以下は〜引用です」という文章をとっぱらえば問題ないと思いますが。
>それから、引用文の見出し（h1〜6）と本文（blockquote）に、
>title="××さんの日記より"という属性をつけてやれば、より明確になるし。
>あとは、全体を<div class="quote" title="××さんの日記より">で囲ってやる
>という手もあるけど、Strict的には邪道かな。
なぜあえて邪道な道に進もうとするのか。短い引用ならblockquote+title属性、長い引用ならblockquote+見出し要素でまったく問題ない。

>>302
> blockquote内のheading要素を特別扱いするほうがより汎用的に対処できるかと。
>文書を利用するのは著者自身だけではないので、そういうコンセンサスが得られて
>いない以上、避けた方がいいと思います。
>（たとえば他人の書いた文書の見出しを自動抽出して目次を作ったりすることも
ありえるので）
しかしblockquoteの中に見出し要素が許容される以上、抽出する人はそのことを考えて目次を作らなければならないのではないでしょうか?

>>318の訂正
>>302ではなくすべて>>308の引用です。。。

>>318

> なぜあえて邪道な道に進もうとするのか。

「全体を<div class="note"〜で囲って」というのは、「引用部がはっきりしない
からよろしくない」というご意見に対して、そこに拘るなら（俺は拘らないけど）
そういう手もあるよ、と例示しただけで、俺自身はやりません。

> 短い引用ならblockquote+title属性

たしかに、295で俺が示した方法より、見出しで区切られた地の文ごとに区切って
引用し、title属性に引用元の見出しを書く、というやり方の方がいいかも。
各引用文の、原文における階層がわからなくなる、という欠点はありますが。
しかし、

> 長い引用ならblockquote+見出し要素でまったく問題ない。

これに関しては、すでに >>303 や >>308 で述べられている問題があるので、
「問題ない」と断言はできないと思うんですが。

> しかしblockquoteの中に見出し要素が許容される以上、抽出する人はそのことを
> 考えて目次を作らなければならないのではないでしょうか?

だから、「blockquoteの中の見出しをどう扱うべきか」という点について、
コンセンサスが得られていないのに、抽出する人に「blockquoteの中の
見出しは別扱い」というやり方を強要することはできないので、とりあえず
最初からそういうマークアップは避ける方が無難だと言ってるわけです。
それに、仕様やDTDの許容範囲ならどう書いてもいいというなら、そもそも
こういう議論自体が無意味では？

あっ、バグってる

不毛な論議は止めて、ホームページ制作王を使おう！
21世紀型webソリューションのスタンダードとして世界が認めた制作王。
もはや敵は存在しない。

何処の世界ですか？

>「blockquoteの中の見出しをどう扱うべきか」という点について、
>コンセンサスが得られていないのに、抽出する人に「blockquoteの中の
>見出しは別扱い」というやり方を強要することはできない
　引用文の中に出現する見出しが、通常の本文と異なり、例えば
見出しリストを作るときに抽出対象にすると不都合が起こる、という事は、
HTML とかマークアップ以前の「引用」という部分で自明のことと思われるが？

　それに対し、H1-H6 は見出しをマークアップする、というコンセンサスが
取られており、例え引用文中であろうが、（その見出しレベルがそうなるかは
論議の余地は有るが）見出しである以上、h1-h6 でマークアップするのが
必然かと思われるが、どうだろうか。

>>323
あのCOMDEXを知らないのですか。
素人ですね、貴方。
勉強したまえ。

>>324
どこまで行っても見出しは見出しだから、という意味では
杓子定規にやればそうなると思う。

ただ、確実に不都合が存在していて、
それに対する解決策が見出せていない現状では、
>>320のいう「コンセンサスがない」というのも理解出来るから、
それを避ける（避け方は色々あるだろうけど）のも、ひとつの解決策だと思う。

正直、これ以上は答えが出ない様な気もするな。

>ホームページ制作王
　一応真面目に調べて見たものの、話にならない。

　このスレでオーサリングツール薦めるなら、最低限「正しいHTML目指す姿勢は
評価できるなぁ…」程度の印象を与えるような物にしてほしいだが。

>>326
>ただ、確実に不都合が存在していて、
　だから、>>324 で、不都合は存在しない、って書いているつもりなんだが。

例えば>>303 の指摘する見出しを抜き出してリストを作るとき問題だと言う話は、
引用中の見出しをそういう用途で抜き出す方が(HTMLだろうが、普通の紙の文書だろうが)変。
　HTML仕様とかコンセンサスとか言う問題ではなく、引用を含む文書の編集の処理方法の問題。

>>327
突っ込むの止めてくれ。
隔離スレが出来てるんだからそっちで相手してくれ。

ゲイツも驚くサポートの短さだな！(ﾜﾗ

> 用文の中に出現する見出しが、通常の本文と異なり、例えば
> 見出しリストを作るときに抽出対象にすると不都合が起こる、という事は、
> HTML とかマークアップ以前の「引用」という部分で自明のことと思われるが？

でも、blockquote の中にはイレギュラーな h1-h6 を書いて良いと言うのなら、
>>303 に書いたように「blockquote 内のみならず、他の要素内でもそういう
h1-h6 を書いて良い」ことになってしまうだろ。
特殊なクラスを指定した div とか。そういうのには対応のしようがない。

HTML 4.01 系の HTML で blockquote 内に h1-h6 が認められるのは、
引用内の見出しを想定したからではなく、
単に h1-h6 が %block.mix; が含まれていたから、と考えるのが妥当と思われ。

どの仕様について話をしているのか小一時間問い詰めたい。

HTML4 はイレギュラーな見出しを「書いて良い」仕様だよ。
「よくないと考える人もいる」程度の注記があるだけ。禁止していない。
だから blockquote 内に見出しを書けるんだよ。
仕様で禁止しているのは ISO-HTML だ。
ISO-HTML は見出しは body 直下にしか置けないから、はじめからそんな問題は起こらない。

何故そこだけ仕様書が違うんだ？
複数の仕様を部分的に適用すればそりゃ矛盾も出るよ。
このスレで「Strict 的」ってよく聞くけど、一体何？
無形の不思議仕様について是非を議論してないか？

>>332
>どの仕様について話をしているのか小一時間問い詰めたい。
同意。仕様の話をするときはどのHTMLか限定しないと
不毛になると思われ。

>Strict 的
これはあくまで理念の問題であって、
直接仕様とは絡まない部分の範囲で使う言葉では。

>>332
「仕様的に OK だから」では>>320 のいう通りに
「こういう議論自体が無意味」になってしまう。
書けるとかそういう問題ではない。

>>333
これだけ問題点が指摘されているのに、
事実上、ISO-HTML については議論の対象ではないと思う。

XHTML1.1 は多少毛色が違うけど、
HTML 4.01 Strict, XHTML 1.0 Strict 辺りが議論の対象で、
そこらは暗黙の了解があるかと。

まあ、マークアップ言語の話をしていて、
「暗黙の了解」は矛盾だというツッコミは無しで。

>>334
>>1に
Strict な HTML(*)
* HTML 4.01 Strict, XHTML 1.0 Strict, XHTML Basic 1.0 (XHTML Basic),
XHTML 1.1, ISO/IEC 15445 (ISO-HTML), JIS X 4156 (JIS-HTML) など。

と書かれている以上、
＞事実上、ISO-HTML については議論の対象ではないと思う。
は思いこみに過ぎない。
と一応ツッコミ。

>>333
> 直接仕様とは絡まない部分の範囲
つまり Strict の範囲外なのでは。

仕様に沿うことを言っている時もあれば、
論理 markup 全般を指して言っているように思う時もある。
markup とは無関係の件に Strict 的という言葉が使われることさえある。

「Strict 的」って、「ホームページ」と同じくらい
拡大解釈が一人歩きを始める危険性をはらんだ言葉だと思うんだよ。
「Strict 的にどうよ？」というときは、そこを抑えとかないといかんなあ、と。

>>334
>「こういう議論自体が無意味」になってしまう。
無意味だと感じたんだよ、俺。
実際の HTML4 仕様原文は下記だ。

http://www.w3.org/TR/html401/struct/global.html#h-7.5.5
> There are six levels of headings in HTML with H1 as the most important and H6 as the least.

"most important" の H1 と "the least" の H6。
HTML4/XHTML1.0 Strict での見出しレベルは階層構造の上下ではなく重要度の上下だと思う。

>>336
＞「Strict 的」って、「ホームページ」と同じくらい
＞拡大解釈が一人歩きを始める危険性をはらんだ言葉だと思うんだよ。
＞「Strict 的にどうよ？」というときは、そこを抑えとかないといかんなあ、と。

「現状の仕様的に許される方法はいろいろあるけど、
W3CがHTMLというマークアップ言語をどうして行きたいのかと言う意図を汲んだら、
またはW3Cが推奨するマークアップをするならどうよ？」＝「Strict 的にどうよ？」
と思うのだが。Webドキュメント全般の話にまで広げることもなくはない。
W3C信者的にどうよ？と言い換えた方が適切か。

なんか書いてること矛盾してるかも。
ちょっと逝って来る。

＞Strict的
大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
語感としては「文章に対して(能動的に)マークアップする」というよりも
「文章があれば自ずとマークアップが『発生する』」もんだと思う。

我々が手書きで文章を書く場合、見出しはよほどのことがない限り 大 -> 小 の序列を持っている。
だから仕様書はいきなり h3 から書き始められるとしても、
元の文章を書くという観点からするとそれは不自然なマークアップだ。

hn に限っていえば、見出しがある限り h1 は自ずと発生するものであり、
その下位段落に相対的に h2 以下が発生するはず。
結果的に hn は階層構造になるはず。
重要度は文脈に依存するので、 <h2 class="important"> とか
<h2 class="note"> とかで意思表示するべきだと思う。

追記。
HTMLは自然言語のニュアンスをUAを通じて閲覧者に伝達するためにあるわけで、
仕様書に曖昧だったり雑な部分があるのは、自然言語の文法の曖昧さ加減や
雑さ加減に配慮したものなのかも知れない（ｗ

自然言語には文語と口語があるけど、不思議マークアップは発想が口語的。
書き言葉では必要な全体の構成や段落の適切な配置が、あまり意識されない。
日常会話では「あ、さっき言い忘れたけど」とか、段落を超えて話が飛躍することも多い。

<h1>ブロードバンド時代とStrict</h1>
<h3>xDSLとFTTHが各家庭に普及</h3>
<h3>Webのマルチメディア化が進展</h3>
<h3>MIDI厨やFlash厨が激増</h3>
<h2>(ﾟдﾟ)ﾏｽﾞｰ</h2>

口語的にはこんな感じでしゃべるのはありだろうけど、

<h1>ブロードバンド時代とStrict</h1>
<h2 class="process">xDSLとFTTHが各家庭に普及</h2>
<h2 class="process">Webのマルチメディア化が進展</h2>
<h2 class="process">MIDI厨やFlash厨が激増</h2>
<h2 class="result">(ﾟдﾟ)ﾏｽﾞｰ</h2>

文語的にはこういう感じであるべきなのではないかと。
HTMLは活字なんだから、極力文語であることを意識しようぜ、というのが
ある意味「Strict的」な発想なんじゃないか、と思う。

個人的には、「のぞましいマークアップ」（情報の利用性やアクセシビリティの
見地から）を、「仕様の範囲内」で実現するための方法や考え方を論じるべきだ
と思っております。
それを便宜上「Strict的」と呼ぶのだと勝手に思ってたのですが。

>335
>> 事実上、ISO-HTML については議論の対象ではないと思う。
> は思いこみに過ぎない。

もしかして、今回の「blockquote内の見出し」論争（？）のみについて、
限定して言ってるのでは？
そもそもblockquote内に見出しを書けないISO-HTMLではこの議論は
成立しない、という意味で。

>>340
この場合、「文語」ではなく「文章語」と言ふべきであらう。
と、野嵜氏が見たらツッコミ入れそうなところ。

って、スレ違いのような気もするが、一応。

blockquoteの中に見出し要素が記述できないとなると、divの中にも見出し要素が記述できないことになりますね。
なぜなら、見出しを抽出する人は見出しが同階層にあるものとする(見出しの暗黙的な階層構造のみを利用する)わけだから。
blockquoteの中にある場合も同階層の概念でないと一概に否定するべきではない。

もちろん>>289でかまわないわけだから、ほかのコンテキストとあわせたマークアップが望まれるわけだが、見出し要素の出現自体は否定すべきものではないと思う。

> なぜなら、見出しを抽出する人は見出しが同階層にあるものとする(見出しの暗黙的な階層構造のみを利用する)わけだから。

何を根拠に言っているのか分かりません。
どこからそんな思考が出てきたんですか?

>>339-340
> 大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
でもその文章にとって HTML が適切な文書型であるとは限らない。
マークアップに悩んでいるケースの大半がこれのような気がするんだよ。
それでも HTML を選ぶ動機が閲覧環境が普及しているからとか
W3C によって標準化された文書型がないからとかいう理由であれば、
それは PDF でやった方がいいことを Transitional でやるのと同じだ。

> 結果的に hn は階層構造になるはず。
この点について俺は懐疑的なんだ。
見出しが階層構造を持っている文章と Strict と、何の関係があるんだ？

HTML は HyperText Markup Language の略だが
HyperText というものを調べれば調べるほど
「人間の思考の非線形性」みたいな文章が出てくる。調べ方に問題あるのかな。
俺はますます混乱してわからなくなっている。

> >>339-340
> > 大前提として、先に文章が存在して、適切なマークアップがなされていくわけで。
> でもその文章にとって HTML が適切な文書型であるとは限らない。
> マークアップに悩んでいるケースの大半がこれのような気がするんだよ。

確かにそうだけど、マークアップの悩みはむしろ紙媒体や電波媒体などの
他のメディアのメタファとしてWebを捉えているから発生している面が大きいんじゃないかな。

プレーンテキストの文書同士を Hyper Link するというのが、
HTMLの原始的な姿だったのではないかと思う。
だから、別メディアにあるものをHTMLで再提示するのであれば、
一度プレーンテキストに落としたものをマークアップし直すのがよいと思う。
これができない情報は、少なくともHTMLで表現するのには向いてないのかも知れない。

> > 結果的に hn は階層構造になるはず。
> この点について俺は懐疑的なんだ。
> 見出しが階層構造を持っている文章と Strict と、何の関係があるんだ？

見出しが階層構造を持たない、つまり重要度の差はあれ平坦な構造をしているとしたら、
それこそすべて h1 でマークアップした上でそれぞれに class で役割を与えては？

……ってそういう意味じゃなく？

「人間の思考の非線形性」も分からないのに、
HTMLを語るな。

>>345
>HyperText というものを調べれば調べるほど
>「人間の思考の非線形性」みたいな文章が出てくる。調べ方に問題あるのかな。
>俺はますます混乱してわからなくなっている。
　裏付けのない全くの「俺の解釈」なのだが、

　複数文書を関係付ける段階では、確かにHyperTextは参照元と参照先の文書を
パッチワークの様に非線形で跳躍したものにするが、参照の対象となる個々の
独立した文書の内容は、当然（万人向けに情報を伝達する為には既知から未知へ
段階的に順を追って情報を伝えねばならないのだから）線形になる…筈だ。

　従って、一つの（単独で読まれることを考慮した） HTML Document を
製作する段階としてマークアップが語られる場合、それは、既存の論文と
何ら変わらない線形の文書構造を有した物である事を前提にすると思うのだが、
どうだろうか。

＃単独で機能しないことを前提とした、例えばリンク集などは非線形の文書に
　なって当然と思う。例えば、分類学的な整理より、利用者の巡回経路に
　あわせて整理されたリンクリストの方が一般的には使い勝手がよい。

hnについて。

仕様書には h1 がもっとも重要な見出しを示し、h6 はその反対と書いてあるわけだが、
文脈上の重要度だけを根拠にマークアップすると、たとえ文書冒頭にあっても
「このセクションは全体から見て重要ではないから、h4 から始めよう」ということが可能だ。
で、DTDには反していないから valid ではある。

が、正規のHTMLは文書型宣言とHTMLの開始タグから始まりHTMLの終了タグで終わる。
# もちろん必要に応じてxml宣言もありだが。
これを考えると、HTMLは単一文書内でマークアップとして完結している必要がある。
つまり、他の文書との相対的な重要度でマークアップが左右されてはいけないのではないか。

他の文書との関連性を示すには link要素が使われるべきであって、
続き物のコンテンツであってもよそから直接参照される可能性があるのが
HTMLの特徴であり利点なわけで(このあたりが思考の非線形性の具体化された部分でもある)、
単独で見たときに意図がつかめないマークアップはするべきではない。

で、hn が相対的なものだとしても、デフォルトが h1 で以下相対的に
h2〜h6 が下位に配置できるということだと思う。
つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。

まとまりない長文でｽﾏｿ

>>346
> それこそすべて h1 でマークアップした上でそれぞれに class で役割を与えては？
class は具体的な役割を与えることはできない。
「何かの役割が与えられている」ということを表せるだけ。
それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。

>>348
> 参照の対象となる個々の独立した文書の内容は、(中略) 線形になる…筈だ。
では、線形の内容をもつ文書の一部分にリンクするような
部分識別子によるリンクはあまり望ましくない？
また link rel="next" のような順に読むことを想定する文書群は
予め一つのファイルにする方がよいのだろうか。

>>349
> つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？

>>350
＞ それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。

役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない？
現状のHTMLでは
<h2><strong>これが大事だ！</strong></h2>
とか
<h3><code>foreach <var>変数</var>(条件式)</code></h3>
などのマークアップが精一杯だし、逆に言えばこのあたりの制約の多さが
HTMLを簡素化しているし見通しもよくしている(個々の不満はあるにせよ)。

で、このあたりを補うのにclassやidが用いられるのは間違ってはいないと思う。

＞ > つまり、h1 が存在しない文書や h2 を飛び越して h3 が配置された文書はおかしい。
＞ その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？

そりゃおかしいのでは？
というか、そういうマークアップに必然性のある文書ってどんなものがある？

>>350
>class は具体的な役割を与えることはできない。
（中略）
>それが Strict な文書かと聞けば、やっぱり意見が割れるような気がする。
　基本的には同意するが、少なくとも class をつけなかったり、
マークアップしなかったり、又は全然別の要素でマークアップするより
strict だとは思う。
　例えばh1-h6 のレベルに当てはまらないが、しかし、文書構造上「見出し」のhoge
をマークアップする場合、<div class="hoge">hoge</div>より<h1 class="hoge">hoge</h1>
の方がstrict 的にはベター。

　また、どうしても既存のDTDにない要素を明示する必要性がある場合は、
XHTML で文書を作成し、その中に独自の要素を定義したDTDを名前空間を使って
挿入する、という方法を既に W3C は提供している。

>順に読むことを想定する文書群は予め一つのファイルにする方がよいのだろうか
　ファイルの転送速度やら、DOMなどの処理時の要素数を考慮した分断が
原因であれば、その原因が取り除かれ次第一つにした方が良いと思う。
　が、例えば「１．足し算」「２．引き算」「３．掛け算」という文書なら
それぞれ独立文書として分けたほうが良い筈。

>その立場では、 h4, h2, h1, h3, と続くような文書は、どうなの？
　申し訳ないが、h１から並べなおすと、それが改悪になるような文章というのが
想像できないので、例示して欲しい。

>>351
>役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない
　CSS は役割を表示するときの表示手法であって、あくまで HTML はCSSと独立して
存在しえるべき。
　その他の部分に関しては激しく同意。

>>329
　今更だが、スマソ。

> 役割を明確にするために目立たせたりひっこめたりするのはCSSの任務じゃない？
CSS がなければ役割を明確にできないということ？

> そりゃおかしいのでは？
> というか、そういうマークアップに必然性のある文書ってどんなものがある？
例が極端すぎたかな。ちょっと前に出てた >>238-243 あたりとか。
あれって h1, h2, h4 を禁止してしまっているから出てくる話だ。

W3C のトップページの h1-h3は、見出しレベルが飛んでこそいないけれど
階層構造を全然表さない見出しレベルが使われている。
あれはよろしくないのか？ Transitional だから OK なのか？

>>353
>ちょっと前に出てた >>238-243 あたりとか。
>あれって h1, h2, h4 を禁止してしまっているから出てくる話だ。
　正にその最後の部分の >>243-244 で一応俺の意見は述べているが、
　今の論議にあわせて、改めて言わせてもらえば
　>>238 の件は
１：本当はどこかに隠れた分類上の見出しがある。
２：同一レベルのない様に思えるが分類上はネストの深さが違うので、
見出しレベルが異なる方が寧ろ相当。
　のどちらかになると思われる。つまり、問題ない。

>W3C のトップページの h1-h3は、見出しレベルが飛んでこそいないけれど
>階層構造を全然表さない見出しレベルが使われている。
>あれはよろしくないのか？ Transitional だから OK なのか？
　W3C は自身のWebSiteをstrictより、実装重視でマークアップしているだけかと。
　というわけで、strict的には例えW3Cのマークアップだろうとも、「よろしくない」。

　ついでに言えば、transitional だからといってtableでレイアウトが許容
されるとは仕様の何処にも書いていないので、仕様第一主義ならtransitionalであってもNG。

>>352-353
hnが階層構造をなすという仮定で書いてきたけど、
現状 hn では6階層の見出ししかマークアップできない。
h1 を基点とした相対的な重要度しか与えることができないから、
このあたりがHTMLの限界ではある。
で、手薄な部分を補うためには class や id に頼らざるを得ないのではないかと。

先に挙げた例で言えば、
　1.<h2><strong>これが重要！</strong></h2>
　2.<h2 class="strong">これが重要！</h2>
上記のどちらがよりStrict的か、という話にもなる。

1.はソースの見通しがやや悪く、2.はCSSオフの状態では
(現行UAは)当該セクションの位置づけを明確に表示できない。
CSSがなくても位置づけが明確になることが理想だとすると、2.の方が適切なのかな。

>>353後半については、>>239で一例を挙げたように
div 内の見出しを h1 から振り直すことで一応の階層構造を維持できる。
# これもCSSオフの状態では表示上厳しいが。

CSSオフで class/id で与えた役割が伝えられないのも、
現行HTMLの欠点と言えるだろうしUAの未成熟とも言える。
# UAについては、たとえばclass/id をツールチップで表示するなどの方法があっていい。

でも、代表的な視覚系UAの表示に立脚して述べるのは、少なくともStrict的ではないだろうね。

>>354
見出しの重要度をネストの深さとみなせる根拠は何？暗黙の了解か？
その部分で、HTML4 Strict にないものを
他所から持ってきて勝手に組み込んでしまっていないか？
それは既に Strict とは別の何かじゃないのか？

>>356
>見出しの重要度をネストの深さとみなせる根拠は何？暗黙の了解か？

　>>238 が
>分類内の小分類の有無によって
>あるタグは h3 だけど別なタグは h4、という場面が出てきて、なんか気持ち悪い。
　と述べているので、俺は「小分類の有無によって見出しレベルが分かれるのが相当な文書」の
HTMLによるマークアップ法について語っていますが何か？

>>357
俺、 W3C のトップは「見出しの重要度」を
マークアップできていて、 Strict だと思うんだ。
何故それが「実装重視でよろしくない」になるの？

>>358
　マジゴメン。

　テーブルレイアウトしてたり、border か outline 相当の
仕切り線をパイプで書いてたりしてるので、見出しのマークアップに関しても
勝手にいい加減なものに脳内変換してた。

　ちょっと逝って詫びて来る。

> 見出しの重要度をネストの深さとみなせる根拠は何? 暗黙の了解か?

SGML 時代から10年以上続いている常識ですから、文字通り暗黙の諒解でしょう。
ISO-HTML でも構造のレベルと明言されていますし。
HTML 4.01 では「h1 + h3 のような記述を好まない人もいる」
という程度の表現に留められていますけれども。

rubyの仕様書を読んでたら、classで読み仮名なのか何なのかを区別すべき
とあったけど、意味あるのかねコレ。
UAにルビの意味を伝えるなら新しい属性を作るべきと思った。

>>361
用途別の属性値が何か規定されてるわけでも無し、
人がソース見たときに、用途を推測できるという以上の意味は無い。

それ以前にrubyなんてXSLにすべき物であってXHTMLに含める必要は無いと思う。

>>362
> それ以前に ruby なんて XSL にすべき物であって XHTML に含める必要は無いと思う。

面白い。でも、XSL/T 使うにしても、日本語のように読みがなを漢字から
一意に特定できない場合は、何らかの形で読みがなの指定が必要になってくるんじゃないか?
<span pron="にちゃん">2ch</span> とか。

…この形で読みを示す汎用属性が定義されている方が便利かも。
でも、title をそういう風に使うこともできるか。
とは言え title は他の使われ方をすることもあるんだから、
title を直に rt に変換する訳にもいかないし…。

見出し要素の数字を重要度とみなすのは確かに合理的だが、見出し要素はUAが目次に抽出してよいと仕様書に規定されているように、慣用的に階層構造とされているので、それに従うべきである。
HTMLの問題はほかの文書形式と整合性を取り、文書構造を単純にするために、見出し要素に暗黙的な階層構造を持せることで、文書構造が複雑になるのを防いだ。
その意味で、HTMLはDOMの階層よりも見出し要素の暗黙的な階層構造のほうが重視されるべきである。
しかし、XML(SGML)はDOMの階層はもちろんDOMの階層がすべてであるから、今厳密にHTMLを記述しようと思えばこの二つの階層構造がともに成立しするようにすべきである。

>>355
HTML自体では、class属性は意味を持たない。ほかのスタイルシート・プログラムと組み合わされて始めてその意味を持つ。単体では表示されるべきでない属性であり、ツールチップはtitle属性でかまわない。

>>362
振り仮名という意味で厳密に使われれば音声ブラウザにとって都合がいいんだけどな。

ところでhttp://www.w3.org/TR/html4/からLatest version of HTMLのURIへ行くとXHTML 1.0の仕様書になるね。なぜXHTML 1.1でないのだろう。