Strict-HTML スレッド 39

StrictなHTMLについて語るスレッド。W3C信者もそうじゃない人も投稿歓迎。
でもHTMLの基礎知識は欲しいね。sage進行推奨。

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

Strict-HTML スレッド 38
http://pc8.2ch.net/test/read.cgi/hp/1158665739/

勧告等・その他は http://bell.skr.jp/web/strict/#etc
過去ログは http://bell.skr.jp/web/strict/#past_thread

初心者の質問はこちらへ
Webサイト制作初心者用質問スレ Part 175
http://pc8.2ch.net/test/read.cgi/hp/1161537564/

実装の話は10中8, 9スレ違い。

関連スレは>>2

/* CSS・スタイルシート質問スレッド【61th】 */
http://pc8.2ch.net/test/read.cgi/hp/1160702243/

XML→XHTML
http://pc8.2ch.net/test/read.cgi/hp/1039933755/

@media:all { 真のアクセシビリティ }
http://pc8.2ch.net/test/read.cgi/hp/1034270272/

ユーザビリティ専用スレ　その３
http://pc8.2ch.net/test/read.cgi/hp/1136275352/

【みらくる】XHTML 2.0 (その2)【ドリーム】
http://pc8.2ch.net/test/read.cgi/hp/1098711758/

XML使いのスレ 2.0
http://pc8.2ch.net/test/read.cgi/hp/1057198990/

XSL/XSLT
http://pc8.2ch.net/test/read.cgi/php/999654569/

いちもつ

また落ちたか

ここも落ちそうな勢いだな

ネタ振りさえあれば結構盛り上がるんだけど

>>6
んじゃ〜,
h1 の使い方について...
僕は独自の解釈をしている:
h1 : chapter
h2 : section
h3 : division (section をさらに分割)

ようするに一つのテーマを分割するとき,
h1 が 1ページに対応,
{ h2, h3 } が ページない分割に対応.
よって { h2, h3 } が最も多く使われ,
それ以外の利用頻度は極めて低い.

>>7
感覚としてなら良いんじゃない？
俺も結果的にはだいたいそんな感じになるな。

>>8
" h1 なしのページは許せん ! " と言う人もいるので
議論になると思ったんだけど.

ところで strict の精神て何だろ ?
単なる DTD だけの問題ではなさそうだけど...

ん？なんでh1が無い状態？
まあよくわからんが、その場合は見出しのレベルを下げて、
chapterより上の見出しを作ってページ毎にやればいいんだろうけど。

talk:>>9 h1の次の見出し要素がh3になるなどということが無かったらいいのではないか？

>>9
H1無しは許せん！というか、当たり前にいるでしょ。

>>10, >>11
仮に " h1 必須 " と考えると
head 内の title と 同じものになるのが自然じゃないかな ?

しかし, 僕は " テーマの分割 と対応 " と言う考え方をしている.
んで, chapter レベルでの分割が必要なテーマは僕の場合, 極めて少ない.
必然的に, h1 なしのページの方が多くなる訳.

>head 内の title と 同じものになるのが自然じゃないかな ?

根拠を示せ。漠然と「じゃないかな？」とか言われても賛同も反対もできん。

>しかし, 僕は

お前の感情論とか感覚論だったらブログでも作ってそこで公開したら？

>必然的に, h1 なしのページの方が多くなる

「階段を上るときに一段目は必ず抜かします」ってくらい滑稽だと思うんだけどどう？

>>14
" 根拠を示せ " と言われてもなぁ.
僕としては " ネタ振り " のつもりだったんだけど,
そう出て来られると " 寝たふり " をするしかない.
ようするに h1 の活用法は個人差が出ると言いたかったんだけど.

んで, あんたはどう考えてるのさ ?

>>13
そうならない場合もない？
titleは全ページ同じでh1はその画面のタイトルみたいになることがあった。

>>15
極端に書くわ。
<title>hoge.net(HOGE)の管理人fooくんのプロフィール</title>
---------
<h1>プロフィール</h1>

TITLE要素は、文書の基本情報として書く。
H1要素は、LINK要素等で文書の関係(例えばどこどこの子ページであるとか)を示した上で、それを前提として多少省略して簡潔に書く。
上記は極端に書いたけど、現実には考えたあげく同じ記述になる場合も有り得る。それでもやっぱり書く。
H1要素は普通に考えて文書には必要だよ。表示で要らないならdisplay:none;でいいわけだし。

>>16
それはブックマークの時に困りそうだ……。
strictとは関係ないかもだが。

>>16
titleが全ページ同じというのはどういう状況？

title要素は文脈と離れた所でも参照され得ることを考え、文脈が分かるものを
付けるべきといった話が仕様書にある。一方、見出しはその文脈の内容を短く
記述するものとある。

というわけで、そのページを一目見て何の事か分かるのならh1が「更新履歴」
だけでもいいが、titleはそれでは駄目で「○○に関する更新履歴」などと、
titleだけで文脈が分かるようにすべきということ。そう言う意味で、titleとh1は
違って当然だろう。

fieldsetってフォーム以外で使用したら駄目？

umu

zannen mitame ga iinonine

とりあえず、 ttp://www.geocities.jp/kmath1107/ 以下のファイルにアクセスしてh1要素が全部でいくつあるか数えてみよう。

キモいコテ2人も居着いちゃったな。

talk:>>24 誰だよ？

>>25
YOUだYO！

talk:>>26 お前に何が分かるというのか？

>>27
26じゃないが、少なくともお前がキモイということはわかる。

>>27
キモいってわかるんだYO！

キモイコテ>>27 ＞＞＞＞(越えられない壁)＞＞＞＞ ウザイななし>>28-29

>>27-29
中二病
>>30
高二病
>>31
大二病

はいはい次どうぞ

だみだこりゃ.
結局, 痴話喧嘩で終わるのね.
data 落ちするのも当然.
面倒見切れんがな.

面倒見てくれとは言ってないな。できれば消えてくれ。

>>32
"痴話"喧嘩かよｗ

>>17,19
おおう、なんかすごい納得させられた。
そういう考え方聞くのが面白いんだよなー。
もっとおかわり＾＾

talk:←これがきもい

「これが俺の個性なんだ。カッコイイだろう。」って勘違いが見え見えで気持ち悪い。
ジーンズメイトで買ったような服なのに、
「この素材感が好きで探したんだよね〜」とか、
「このワンポイントがなかなか効いてていいでしょ？」とか語ってるみたいで。

例えば、すっごい厖大な文書を分割したとして、
はじめにだけh1があって、残りのやつはrel=nextとかで明示しておいて、
h1自体は暗黙の諒解ってことで省略してh2から始めるとかとかみたいに、
暗黙的に省略するのはOKかな？

1P
→h1：タイトル
→h2：もくじ

2P
→h2：第一章
・・・・

みたいな感じで

>>38
2P目のh1要素は「第一章」になるべき。

その気持ちはすごく良くわかるｗ

talk: お前に何が分かると言うのか？
talk: 私は男だがいいのか？
talk: 私を呼んだか？
talk: お前誰だよ？
talk: 人の脳を読む能力を悪用する奴を潰せ。

<!-- チラ裏
このスレにおけるhnの解釈はhnをツリー構造に見たてるもの。
根であるh1は複数存在してはならないし
ツリー構造が崩れるので見出しレベルをスキップしてはならない。

もう一つはhnを階層構造に見立てるもの。
最下層であるh1は複数存在してもいいが
階層構造が崩れるので見出しレベルをスキップしてはならない。

これら二つの解釈の欠点としてはh6以降(h7やh8)が必要になる場面が存在しうること。
XHTML2のhとsectionによる構造と実質同じものになってしまうこと。

もう一つは見出しをh1からh6という枠の中で割り振るというもの。
こちらは複数ある枠の一つにすぎないのh1は複数存在してもいいし
同様に見出しレベルをスキップ(スキップと表現するのもおかしいが)しても何ら問題ない。

この解釈の欠点は筆者によってhnの使い方にばらつき出てしまうこと。
ソースを見ただけではビジュアル部分(文字のサイズとか)に依存した使い分けをしている人間と区別がつかないこと。
-->

>>42
> これら二つの解釈の欠点としてはh6以降(h7やh8)が必要になる場面が存在しうること。
階層構造やツリー構造でも深さが無限とは限らんし、
実際この場合は有限じゃん。
つーか一般の階層構造やツリー構造は間を飛ばしてはならないなんてことはない。

> ビジュアル部分(文字のサイズとか)に依存した使い分けをしている人間と区別がつかない
こんなもん何に対してだってつけられる難癖だろ。


まーでもイメージとしてはそんなもんだろう、たぶん。
そんな明確に区分できるわけではないとは思うが。

とりあえず、hn単独についてはそんなように幾通りか解釈の幅がありうるから、
他のポリシーとの兼ね合いで、整合性が取れるように選ぶことになるんだろうね。
ツリー構造をなすsectionを想定して組んであるのにhnはそれにそぐわない配置の
仕方だとか、そんなふうだと「整合性があんまりとれてないね」ってことになるかも。

>>19
いまさらだけど、お答えします。
以前にある企業のあるシステムB2Cの製作をしたことがあるのですが、
そのWebページのタイトルを全ページのtitleに指定しろとのことだった。
例えばWebページのタイトル（HP名？）がYahoo!で、どのコンテンツに移動しても
ページのtitleはYahoo!。どこをブックマークしてもYahoo!みたいな。
なんか気持ち悪いが、>>19のように技術者が納得できる理由をを客が理解できるわけもないわけで。
そんなことよりデザイン担当したやつがテーブルレイアウト＆全td内にfont書きまくってたのには勘弁して欲しかった

> つーか一般の階層構造やツリー構造は間を飛ばしてはならないなんてことはない。
「一般」とかいわれてもなあ。俺的は、枝がなく分かれている部分はツリーの一部とは言えないし、上下に層がなく分かれている部分は階層の一部とは言えないな。
それこそ、"1" "2" "3"という階層構造で"2"に相当する部分を飛ばしたとしても、再ナンバリングして"1" "2"にするのが「一般」なんじゃなかろうか？

>>38
その文書群構造だと、title要素も最初のページだけに付ける方が自然って
ことにならないか？　でも、HTMLの設計はそうなってない。

HTMLの設計は、
「まず文書群があり、その部分として各ページが存在する」
という形式ではなく、
「まずページがあり、それらが関連し合う事で文書群になる」
というもの。この設計思想は、title要素が全ページ必須で個々のページの
文脈が分かるように書けと仕様書に書かれている事からも明らか。

ということは、見出しも文書群で付けるのではなく、個々のページごとに
付けるのがHTMLの設計思想に合っているということにならないか？

>>45
> 「一般」とかいわれてもなあ。
知名度や普通さ加減のことじゃないよ…
とくに追加を条件を付さないものを一般、条件を付したものを特殊、
というような使い方での一般のことな。

階層構造だからすなわ」間を飛ばしてはならない、となるんじゃなくて
「階層構造、かつ再ナンバリングして詰める」というのもあれば、
「階層構造、かつ詰めない」というのもあれば、
「階層構造、つめるかつめないかは考えない」というものもある、
つー話な。最後のは一般、前二つのは特殊化された階層構造、と言ってる。

たとえば、階層構造と42の
> もう一つは見出しをh1からh6という枠の中で割り振るというもの。
を組み合わせたものは、詰めない例だな。
(だから43で「そんな明確に区分できるわけではないとは思うが。」
と言ってるわけよ。)

>>46
> その文書群構造だと、title要素も最初のページだけに付ける方が自然って
> ことにならないか？
ページタイトルと一連のページをまとめたタイトルの違いだと思うよ。
前者をtitleで後者をh1で、という話だろう。

温度差が禿しいスレでつね

本文とは関係ないブロックに見出しというか名前をつけたいときって、みんなどうしてる？

例えば、kanzaki さんとこの 1 ページを例にあげると、
ttp://www.kanzaki.com/docs/sw/rss.html
<h1> が 「RSS -- サイト情報の要約と公開」 で、
<h2> が 「RSS 1.0の要素と構文」 とかの本文だけど、
その間にページ内のアンカーとか、このページの要約とかがあるよね。

そこのブロックには 「ページ内の目次」 とか 「このページについて」 なんて見出しとかは書いてない。
でも、そのブロックが何であるか明示するためにそれをつけたい、ってなったら、何の要素で マークアップするんだろう？ って。

<div class="header"><h2>ページ内の目次</h2> 〜内容〜</div> とか？
<div class="header"><div class="適当に">ページ内の目次</div> 〜内容〜</div> とか？
<dl class="header"><dt>ページ内の目次</dt><dd>内容</dd></dl> とか？

>>50
ページ内の、さらに狭い範囲でのヘッダやフッタにあたるものは、
見出しという考え方はなじまない(適切ではない)と思う。
また、セクションフッタやセクションヘッダというようなものに特に
対応する要素はない。

だから、divだろうな。divだから、結局はclass属性値を割り当てる
程度の意味づけしかできない。("header"や"footer"という値を
割り当てることはできるが、ヘッダやフッタの性質をもつ要素という
ような意味づけはHTML上では記述できない。)

これは、ページ内アンカー(そもそもそれの存在自体の問題は
置いておく)についても同様だな。ページ内アンカーを特に
意味づけする、ということはできないから、その他適当な要素を
使うことになるし、見出しという考え方がなじまないからつけない。


ただ、「なじまない」とは言うが、基準が我ながらわからんね。
なんか文章っぽいのは見出しがなじんで、本体じゃない脇の脚注とか
そんな感じの付属品はなじまない、というような感じがする。

あと、要約の場合は、要約って見出しをつけるか迷うね。著者の意図として、
文章本体の先頭にあるものなら見出しをつけるし、文章本体の付属品として
ついているものなら、見出しはつけない、かな。


それと、たとえば全部のページにサイトメニューを置く場合、そのページの中の
文章本体とは別に、サイトメニューをもうひとつのコンテンツ本体とみなして、
見出しを置くような場合はある。
まえに「一ページにコンテンツが二つあるのは許されるのか？分割するぺきだろ」
というような話があったから、これもこれで話の余地があるところなんだが。

見出しだけに注目するなら「見出しを付けない」「見出しがない」ってのは？
どういうこと？
hn要素は次のhn要素が出現しなくてもdiv要素等で領域を区切ればブロック(それともセクション？なんの事だ)として前出の見出しからは独立するのか？
それヘンじゃねーかぁ？

> それヘンじゃねーかぁ？
ヘンかどうかじゃなくて、すべてに見出しを割り振るか省略されているものと
みなさないと気がすまない(というかそういう方針を貫いてる)人もいれば、
「文書構造は別に見出しで規定されるとは限らないわけだしー」という人もいる、
ということだな。

>>53
いるだろうね。
でもStrictスレなので認めないね。

＞ページ内の、さらに狭い範囲でのヘッダやフッタにあたるものは、見出しという考え方はなじまない

うん、うちもそう思うんだよね。
だから、たとえば fieldset に対する legend や、 table に対する caption みたいなのをつけたいと思っても、
該当する要素がないわけで、それは、header とか anchor は普通 div のブロックだからなんだよね。

だから、「見出しという考え方がなじまないからつけない」 のはわかるんだけど、
でも、table の caption みたいな、そのブロックに対する名前をつけた方がそれがわかりやすい、とか、
つけなきゃ何のブロックかわからないなあ、ってときはどうしたらいいのか、って話で。


＞たとえば全部のページにサイトメニューを置く場合
そうそう、ブログのマークアップってみんなどうやってるんだろう？
「カテゴリ」 とか 「最近のコメント」 に <hn> 振ってるのかな？

自分はやっぱ気持ち悪くて、dl-dt-dd でやってしまった。

>>54
Strictは関係なく、お前の脳内専用ルールに反してるだけだろうな。

>>55
> つけなきゃ何のブロックかわからないなあ、ってときはどうしたらいいのか、って話で。
51で言ったのは、説明をつけてdiv要素にすりゃいい、ってことね。
(「だから、divだろうな。」じゃいくらなんでも言葉足らずすぎた……)

で、それがHTML上での意味づけの限界だろうから、そこで
妥協するしかない、というようなことを書いた。

とはいえ、
> 自分はやっぱ気持ち悪くて、dl-dt-dd でやってしまった。
とか、divの他に適当な要素がつけられる場合なら、そうするのは良いと思う。

こんにちは。

ＨＴＭＬのＦＯＲＭについて教えて下さい。
<INPUT type=submit value=送信ボタン！>

とすると、灰色のボタンしか使えなくて悩んでいます。
テキスト文字だったら、ＣＳＳやＦＯＮＴが使えるので
表示に幅ができてよいのですが、何かいい方法はないでしょうか？

蹴り出さないでちゃんと教えてください！！
（ちょっと急いでるー）

死ねばいいんじゃね

>>56
過去数スレを見る限り、
見出しによってのみ区切られるって考えがこのスレのマジョリティで、
今までもそれを基に議論がなされてきたようだが。

>>57
strict すれっどで "font" を持ち出すとか,
double-quote で囲ってない記述を書き出す神経...
もしかしてゾーマ ?

さて, どうしても ボタンの代わりに text を使いたいのなら
JavaScript を使えばいい.
しかし, "灰色のボタンしか使えなくて" と言ってる時点で...
もしかして iCab 使い ???

すべての UA で通用するわけではないけれど
CSS で form の部品に色づけできることを覚えて おいて おくれ.

答えんなアホ

UAの意味を間違えている時点で(ry

>>60
ありがとう！
すごい参考になったけど、タグが書けない！！

じゃあ、逆にＣＳＳで
<a href=・・・>hogeでっす</a>
に対し、imgでなく、自動で灰色のボタンがでるように
するには、どうＣＳＳで書けばいいのでしょうか？

説明だけだとめんどくさいから、タグを書いてね！

どうでもいいけど, どうして ここはケンカ腰の人が多いんだろ ?
そもそも strict スレッドの存在価値って あるのかどうか...
markup は目的に合わせて工夫すれば良いだけの話では ?
他人の意見を聞くのも悪くないが, 結局 自慢話で終わる気が...

>>63
取り合えず ここは質問スレッドではない.
(まあ, スレッドの趣旨自体 意味不明だけど)
それと まるちぽす とって知ってるのかな ?
知らないのなら覚えておくこと :

複数のスレッドもしくは掲示板に
同じ内容の質問を書き込むことはルール違反なんだ.
そういう事をする人は叩かれるばかりで回答をもらえない.
万が一答えた人もルールを破ったと見なされる.

見出し以外で自由に領域区切って意味づけ出来るんならサジ加減でなんでもありだよなー。
屁理屈ゴネてる「俺マークアップ」脳内ルールはどっちなんだかなーｗｗｗ

>>65さん
すいませんでした。

ところで、
<INPUT TYPE=submit VALUE=送信 STYLE=BORDER-STYLE:solid;BORDER-WIDTH:1px;BORDER-COLOR:black;COLOR:black;BACKGROUND:white>
こんな感じのものを見つけましたが、Hoverするにはどうやるんですか？

>>67
とりあえず ここで答えるわけにはいかない.
(ご覧のとおり うるさ方が うじゃうじゃいる !)
再利用できるところを探すから待っててね.

>>67
それはHTMLの話じゃなくて、CSSの話なので、CSS質問スレに行って。

下手に優しくするからつけあがってるじゃないか。
スルーするか、初心者質問スレに誘導して終わりでいいだろ。
http://pc8.2ch.net/test/read.cgi/hp/1160534021/
http://pc8.2ch.net/test/read.cgi/hp/1158773821/こっちのほうがいいか

いつから質問自体が禁止になったんだか

>>67
http://pc8.2ch.net/test/read.cgi/hp/1155395444/l50
･ 個人的に使いたくないスレッドだが ほかに適当なのが見つからなかった
･ CSS の記述は解ってるんだよね ?

自演の匂いがぷんぷんする

>>1にご丁寧に"初心者の質問はこちらへ"ってリンク貼ってあるんだけどな。

自称中級者なんだろ。

こんにちは！
やっぱり蹴り出されると思ったけど、また来ました！！
この短時間（２時間程度で）ＣＳＳを集中勉強しました！！

でも、動かないので教えてください。。。

<style type="text/css">
<!--
INPUT{text-decoration:none;border-style: none;color:blue;background-color:white;}
INPUT:Link{color:blue;}
INPUT:Visited{color:blue;}
INPUT:Active{color:blue;}
INPUT:Hover{color:#f00;text-decoration:underline;background-color:#fdd;}
-->
</style>
<INPUT type=submit value=【　送　信　】>

hrefだと当然hoverは動くのですが、↑これだとhoverしません！
もうちょっとなんだけどなあ〜

ＲＯＭってる！！

どうすんだよコイツ…
糞コテ責任取れよ。

ＣＳＳ板に行って来ます。
さよなら〜、ありがとうね！>>72

もしわかったら、ＣＳＳの方に書いてね！！

>>76
2時間程度で本当に CSS を理解できたとするならば
あんた, 相当勘が良いですぜ.

それで a:hover は CSS1 の範疇に入るけれど,
a 以外の場合は CSS2 の範疇.
IE は CSS2 をサポートしていないらしいので
(Mozilla 系 UA でチェックしないと)
永遠に "うまくいかないと" 言い続けることになる

んで, 参考まで...
hp.vector.co.jp/authors/VA022006/css/selector.html#pseudo-classes

そもそも有名な「LoVe and HAte」を無視してるじゃん。それに:linkと:visitedはリンク疑似クラスだから無意味だし。
故にCSSをセレクタの時点で理解していない。

CSSスレの人可哀想……。自分もたまに行くから尚更。

>>56
> 説明をつけてdiv要素にすりゃいい
あぁ、把握ｗ
どっちでも捉えられて迷ったんだ、うん。(笑)

ありがとう、なんか同じ考えのひとがいるみたいで安心した。

>>59
うん、この場合も、普通はそれが基本なんだよね。
ただ、「見出しは本文の関係にしかつけない」 という自分ルール (御幣が悪いか？) があったときの話で。

ページ内アンカーとかheaderやfooterなんかのページ情報やナビゲーション部分も、
そのページ内の一要素である、とも言えば言えるわけなので、
BODYの直下でもいいし、 H1 のセクションの中にも入れられると思うんだけど、
　(※ H1以外の本文内 (H2 のセクション以下とか) に置くことはまずないと思う)
だから完全に 「その部分が本文から独立するとして扱ってる」 わけじゃないんだけど。

他にも、例えば、本文内のとあるリストに、
「table-caption のように、ｈn の見出しってわけでもないんだが、そのリストの名前を明示したい。」、
ってなったときは、どうマークアップするのだろう？ って感じに似てるかな。

そういえば以前のスレで <div class="hoge"><strong>ブロックの名前</strong></div> みたいな書き方も見たことあるがｗ

>>82
しつこい。全否定だ。

話題を振ってみる。

http://www.kt.rim.or.jp/~kbk/perl-5.8/perlfaq5.html
例)
#how_can_i_make_a_filehandle_local_to_a_subroutine_how_do_i_pass_filehandles_between_subroutines_how_do_i_make_an_array_of_filehandles

こういう長いIDってストリクタ的にはあり？ｗ

>>82
「本文」とは？
テキストによる文章も表も画像もリストでのナビゲーションも構造がどうかには関係ない。
原点がStrictではない。他スレで満足するまで語りなさい。

わからん。
つまりどうやってマークアップしてるの？ よくあるブログとかマークアップするときどうやってるの？
これが理想、みたいなページとかあったら教えてくれ。

>>59,66,83
> 見出しによってのみ区切られるって考えがこのスレのマジョリティ
> 見出し以外で自由に領域区切って意味づけ出来るんならサジ加減でなんでもありだよなー。
> 全否定だ。
結局根拠不明な制約だから脳内ルールだな。自己目的的なマゾヒズム
じゃあるまいし、意味もなく制約課したいだけなら他所でやるといいよ。

>>82
> 「table-caption のように、ｈn の見出しってわけでもないんだが、そのリストの名前を明示したい。」、
文書内で明示したいなら、やっぱりtitle属性に書くだけじゃじゃだめだろうな。

かといって明確にリストの見出しだと意味づけできるわけでもないけど、
それをHTMLの力不足ととるか、HTMLの担当外ととるか、で諦めの
つきようが変わる気がする。

>>84
クライアントがURIとして処理できない可能性のある長さ、に達するIDはどうかと思う。
具体的な長さは忘れたけど、最低限処理できるべき長さ、というのがRFCかなんかで
示されてなかったっけ？

>>87
じゃあ全部DIVで良いではないかｗ

脳内ルールを否定するのにいちいち根拠を提示しろとな？
<div><strong>あああ</strong></div>
これの否定をまたいちからやるのか？めんどくせー。
DIV厨め。

>>89
> <div><strong>あああ</strong></div>
そんなの誰も賛成も推薦もしてないのにｗ

核についての議論自体を否定する民主党を髣髴した。

BLOGなんてとりあえずのマークアップだぞ。
万人に扱いやすいように、なるべく多種のブラウザに「とりあえず」表示するだけだぞ。それはそれで評価すべきかもしれないがStrictの見本にはなり得ないだろう。

>>88
それはお前だけ。

>>87
とりあえず過去ログ読んできたら？

>>91
いやいや、見本になれ なんていってないよ。逆逆。
ブログとか日記なんて本来のHTMLじゃ扱いづらいものをマークアップするときに、
ストリクタの人はどうマークアップして、自分なりに納得してんの？ って聞いてるだけ。
で、参考にしたいから例を示してくれないかな、と。

>>84
HTML4.01の仕様によれば、IDは65536文字以内でないとならない。
HTTP1.1の仕様によれば、URIは255文字を超えない方が良い。

>>87
見出しのみによって区切られるというのは、ISO-HTMLにある制約だな。
HTML4.01の方はそこまでの制約は書いてないが、少なくとも「根拠不明の
脳内ルール」ではないよ。

>>87
見出し以外でも区切られるって考えもお前の脳内ルールなんだが。
むしろ今までのスレの方針を否定して、自分のルールを正しいというのなら、
根拠を示すべきはお前の方じゃないのか？

>>95
> 見出しのみによって区切られるというのは、ISO-HTMLにある制約だな。
ありがとう。
http://yupotan.sppd.ne.jp/web/isohtml.html#HEADINGS
に書いてあるようなことでいいのかな。

> 少なくとも「根拠不明の脳内ルール」ではないよ。
こういう根拠と、その根拠が言及している範囲を示さずに
　> 見出しによってのみ区切られるって考えがこのスレのマジョリティ
　> 見出し以外で自由に領域区切って意味づけ出来るんならサジ加減でなんでもありだよなー。
　> 全否定だ。
なんて言ってりゃ脳内ルール扱いだよ、そりゃ。
実際、HTML全般の話ではなくISO-HTMLの話だったわけだしな。

>>96
> 見出し以外でも区切られるって考えもお前の脳内ルールなんだが。
俺は53で「文書構造は別に見出しで規定されるとは限らないわけだしー」という人もいる、
と言ってるが、すべてのHTMLの要素は文書構造を作るから、これは当たり前だよな。
そして、それ以上の区切りに関するルールなんて俺はなにも主張してないぞ。

まず見出しが普通の要素以上になにかを区切るというソースすら出てこないから
脳内ルールだと言ってたわけだが、ISO-HTMLのルールを持ってきてそう主張しているのか？

見出しほど明確じゃないが、構造はdivでも提供できると考えてる派な俺。
divをsectionみたいに使えばいいし。

あとISO-HTMLはなんかｷﾗｲなんだよなぁ。

>>97
だから過去ログ読んでこいって。
あと、その引用してる部分、一人のレスじゃねえぞ。

>>99
> あと、その引用してる部分、一人のレスじゃねえぞ。
さすがにそれを思い込むほど2ch病は進行してないです。

>>97
> 実際、HTML全般の話ではなくISO-HTMLの話だったわけだしな。

HTML4.01StrictをさらにStrictにしようとして出来たのがISO-HTML
なんだから、これは、単にISO-HTMLだけで成り立つ話という事ではなく、
Strict-HTMLという方向性での話だよ。

HTML4.01Strictと仕様が変わってる時点でそもそもStrictじゃないじゃん。
ただのパチモンでしかない。

>>102
StrictであることとStrict-DTDは違うんだけど。

確かに ISO-HTML とか持ち出されても困るなｗ

スレの主旨すらわからんらしい。

>>102
次からはValidとStrictの区別がつくようになってから話に参加しろ、な?

>>94
実際例書いてみるお。
div の id や html, body 等は省略。

※案1: 全部に「見出し」をつける

<title>ページのタイトル - ブログ・サイトのタイトル</title>
<h1>ページのタイトル</h1>
<div class="section"><h2>ヘッダ</h2> 〜内容〜</div>
<div class="section"><h2>リンク</h2> 〜内容〜</div>
<div class="section"><h2>プロフィール</h2> 〜内容〜</div>
<div class="section"><h2>新着記事</h2> 〜内容〜</div>
<div class="section"><h2>カテゴリ</h2> 〜内容〜</div>
<div class="section">
    <h2>本文</h2>
    <p>あーだこーだ</p>
    <div class="section"><h3>○○について</h3><p>あーだこーだ</p></div>
    以下略
</div>
<div class="section"><h2>リンク</h2> 〜内容〜</div>
<div class="section"><h2>フッタ</h2> 〜内容〜</div>

※案2: 「見出し」はなじまないので div にする
<title>ページのタイトル - ブログ・サイトのタイトル</title>
<h1>ページのタイトル</h1>
<div class="block"><div class="block-title">ヘッダ</div> 〜内容〜</div>
<div class="block"><div class="block-title">プロフィール</div> 〜内容〜</div>
<div class="block"><div class="block-title">新着記事</div> 〜内容〜</div>
<div class="block"><div class="block-title">カテゴリ</div> 〜内容〜</div>
<div class="block">
    <div class="block-title">本文</div>
    <p>あーだこーだ</p>
    <div class="section"><h2>○○について</h2><p>あーだこーだ</p></div>
    以下略
</div>
<div class="block"><div class="block-title">リンク</div> 〜内容〜</div>
<div class="block"><div class="block-title">フッタ</div> 〜内容〜</div>

だいたいこの2つですか？ わかりません＞＜

>>101
> HTML4.01StrictをさらにStrictにしようとして出来たのがISO-HTML
規格として厳密だ、という点ではstrictという表現が当てはまるかもしれんが、
規格策定者が規格の厳密さを維持できるレベルまで規格の自由度を
落とすことによって作られたものだろ？

ISO-HTMLで閉じて、ISO-HTMLしか存在を認めないなら、それをStrictとすれば
済むのかもしれない。だけど、そこからISO-HTML即ちHTML全般のバイブル、
とはならんだろう。ISO-HTMLの話をHTML全般の世界に話を持ってくるには、
ISO-HTML以外の流儀を認めない理由は必要になるだろう。
言い換えると、HTMLに自由度を認めない理由が必要になるということ。
(XHTMLとの間には、SGMLとXMLという違いもあるわけだしなあ。)
それは容易なことじゃないと思うんだが。

> これは、単にISO-HTMLだけで成り立つ話という事ではなく、
> Strict-HTMLという方向性での話だよ。
「ISO-HTMLで成り立つルール」の話を持ってきてStrict全体に
敷衍しようとしている、という前提となる事実を隠蔽して
「Strictとして当然だ」と主張してたわけだから、姑息だわな。
カルトな新興宗教が「キリスト教です」といいながら布教するような
姑息さだよ。

>>102
さすがにそれはないわ。XHTML1.1はStrictじゃないのかと。

>>109
それを言うとすべてのStrictは自由度を落としているぞ。Strict-HTMLが
font要素などを禁止しているのも自由度を落としているだけか？

そもそもISO-HTMLは、規格策定者が勝手に方向性を作ったものではなく、
それまでStrict指向の人たちの間で考えられていた方向性をまとめたものだよ。
確かに唯一無二の解ではないが、Strictの方向を向いたらその眼前にあるものだ。

そしてその考え方はISO-HTMLがオリジナルではなく、先述の通り、それまで
Strict指向の人たちの間で考えられていたものに由来している。

＞それを言うとすべてのStrictは自由度を落としているぞ
それ違うんじゃね？
「自由な校風を」 っていわれて 「じゃあ煙草吸うのも自由ですね」 って言ってるようなもんじゃね？

まあ section(div)-h で文書区切るタイプの人は ISO-HTML の見出しで区切るって概念とは相容れないよな。
だから昔こういうこと (ttp://noz.hp.infoseek.co.jp/diary/20020301.html) を言い出した人がいたんだろうな。
Stricter じゃなくて単に ISO-HTMLer なだけじゃないのか？

要するに僕の考えた超人ｗでしょ。

>>103>>106
んなのわかってる。
Stict-DTD以前に、オリジナルStrict思想でStrictを定義したStrictでしかないじゃない。

>>109
>さすがにそれはないわ。XHTML1.1はStrictじゃないのかと。
w3cの決めた仕様なのに…
そっちの方がさすがにそれはないわ。

ふと疑問に思った
MSの思想を厳密にしたStrict-DTDを作って
MSのHTMLを元にしたStrict思想を考えたら、
ISO-HTMLマンセーの人はそれもStrictと認めるようになるのかね？ｗ

w3cの考える仕様を仕様書以上につきつめて厳格である事はStrictだと思うが、
Strictはどうあるべきかを語りだしたらもはやStrict(厳密な)じゃないよな。

>>112
sectionはいいんだが、divはsectionじゃない。
class付けしたところでdivはdiv。
文書を区切る意味なんて持たない。

>>113
＞んなのわかってる。
わかってねえじゃねえかｗ
>>114
バカなの？

MSの思想とは何だ？Internet Explorer 向けの文書データに関するDTDを書くのは不可能だから、何のことか分からない。

区切られているという現実をどう判断するの？

たしかにdivは区切るなんて意味付けは無いんだが、
<body><div></div><div></div></body>
<body><div></div></body>
じゃ、bodyの中は明らかに2つに別れてるし。
これはsectionと同じ使われ方の場合もありうるよね。

ラベリングという点では確かに明確にわかるけど、
区切りという意味を持ってるわけじゃないからという理由で、区切りに過剰反応するんじゃね

talk:>>119 それでは div はどういう意味なのだ？ division ではないのか？

>>119
区切られていない。
"div要素が二つある"。ただそれだけ。
sectionと同じ使われ方がされていても、sectionと同じ意味を持つわけじゃない。
divをどう使おうが、見出しにも段落にもリストにもならない。
同じようにsectionにもならない。

divとdivisionが同一であると？
名前の語源じゃなくて、htmlにおいてどういう意味を持つかが大事だろ

idでラベリングされてた場合、前者に含まれる場合と後者に含まれる場合で
所属が変わってくるのに？

意味付けはなくとも、機械的に判断してもわかるぐらい、
区切られてるのは一目でわかるわなｗ
見出しでも段落でもないというだけで。

divはブロック要素なのにブロックとして認められてないって差別だと思います＞＜

>>124
前者と後者って何を指して言ってんの？

>>125
例えばUAが、そのdivがsectionとして使われているか否かを判断できるとでも？

ちょっと言い方悪かったな。
2つのidを振られたdivの一つ目が前者、2つめが後者と言いたかった。
ブロック要素であるんだから、ひとつのかたまりとして見るのは普通だと思うんだがねぇ。
インライン要素なら当てはまらないが。

>>129
＞ブロック要素であるんだから、ひとつのかたまりとして見る
それは当然そうだが、それが何？
文書を区切る区切らないとは関係ない。

ん？俺は文書を区切る意味をもつなんて言ってないぞ。
一つの塊としてみるんだから、区切りとしての意味が無いだけで、
わかるだろって言ってるだけだから。
塊としてみると言う事は、それ以外の塊との差異は明確な訳だし。

divはそれ単体で一つのブロック要素=ブロックでもあるのに、
区切りと言う意味を持たないというだけでブロックまで否定してるのはどうなんだ？って事な。

ブロックであることを否定した覚えは無いんだが。
誰かしてたか？

日本語文書(じゃなくてもいいが)の文意や常識として見出しで
分割されることと、HTMLで分割の意味づけがされることは別の話だろう。

日本語の文意として区切られる、という話を何の根拠もなくHTML上の
意味づけにまで影響をあたえるなんてことにしたらなんでもし放題だが、
それは「classに日本語で意味を書いておけばそのとおりの要素として
意味づけしたことになるよ」というのと同じ類の主張だな。

>>110
> 確かに唯一無二の解ではないが、Strictの方向を向いたらその眼前にあるものだ。
産業での応用の簡便さも考慮して決まった仕様だろうし、「まじりっけなしのあらゆる
Strict思考が行き着く当時最高の到達点」、みたいな言い方は無理があると思う。
作成する文書を制約し、Strictの流儀のあるひとつを適用する場合の、
ひとつの解、というくらいのものだろ？
これは単に言い方を程度の低いものに変えたいとかいうつまらん話じゃなくて、
そもそもISO-HTMLはあらゆるStrict思想のバイブルになるというような仕様
じゃないだろ？という話な。

>>113
> w3cの決めた仕様なのに…
W3C信者でない人も歓迎のスレなのです。
言い換えると、W3Cを盲信するスレではない、ということです。

>>133
文意でどうこうなんて話はしてないが。

ブロックが2つ有るとその2つは明確に区別できるんだから、
divは区切りになってないってのはそれも否定してね？

>>133
>それは「classに日本語で意味を書いておけばそのとおりの要素として
>意味づけしたことになるよ」というのと同じ類の主張だな。

それは意味付けが出来るって事の否定であって、
区切られると言う事の否定にはなってないと思うんだが。
区切りって、そもそも区切られた物に意味がある必要ないんだぞ。
住所の地番みたいに。

>>135
区切りっていうのはそういうレベルの話をしてんじゃないんだよ。

Strict語るっていうレベルじゃねーぞ！

<h1>hoge</h1>
<div id="d1">
<h2>hogehoge</h2>
AAA
</div>
BBB
<div id="d2">
<h2>hogehoge2</h2>
CCC
<h2>hogehoge3</h2>
DDD
</div>

って書くと、暗示的に@id=d1/h2以下「AAA」部分がその内容
で、divはh2の親要素だから、「BBB」部分は支配しない
こうやって使うとsectionのように使える（≠sectionになる）
でも、だからといってsectionにはならなくて、
あくまでh2がdivの子要素だから、遡れない＝「BBB」に支配が及ばないってだけで、
div自体は「sectionと同じ区切り方している謎の区切り」

ってこと？

>>135
そこらはdivで区切る話に対しての叩きじゃないよ、うん。
見出しって書いたとおり、見出しに対しての話。

見出しで区切れるという主張はISO-HTMLを除いて成り立たないけど、
divで区切れるというのはISO-HTML以外でも成り立つわな。
そこを「見出しで区切れるがdivでは区切れない」というようなことを
言ってる人がいたから。

>>134の言う通りだとしたら、>66のような発言は出てこないと
思うんだが。やっぱり文意とごっちゃにしてるんじゃないかなあ。
>136とかも。それとも136は、またISO-HTMLのことを一般化した
ところの話なのかな。

div区切り否定派がいい感じに壊れてきたなｗ

>>138
sectionてそんな使い方したっけ？

>>138
そうやってもBBBはAAAと同じ見出しだよ。

>>139
＞divで区切れるというのはISO-HTML以外でも成り立つわな。
その根拠は？

ところで この中で JavaScript を書いたことのある人はどれだけいるんだろう ?
JavaScript で重要なのは DOM なんだけど,
div を使わないで block をどう表現したらいいのか想像もつかない.
(ここで言う "block" とは任意の文章の一塊)

ISO html の構造で script を加工とした人居る ?

JS使うために文書崩すなら、JS使わなければいい

nullは出てこなくていいよ。
ISO-HTMLでJavascriptは使えないからそもそも考える必要も無い。

>>146
申し訳ない.
ここに集まる狂信者たちとは相容れないのは承知の上.
ただ... ISO-html の話が出ていたので確認したかったんだ.
JavaScript を使えない仕様ねぇ〜...

なにかしら間違ってる気がしてならねぇ〜 !

全て同じ内容なら複数の仕様はいらないと思うよ

DIV要素でセクション構造を作れないことの証明

SGML/XMLの仕様に、要素構造はシーケンシャルに解釈できなければならない
というのがある。「ここにこのタグが書かれているから、さっきのタグは
こういう構造の要素だったんだな」などと遡って解釈してはならないと
いうこと。では、

<h2>見出し</h2>
<p>…</p>
<div class="section">
<h2>見出し</h2>
<p>…</p>
</div>

と

<h2>見出し</h2>
<p>…</p>
<div class="section">
<h3>小見出し</h3>
<p>…</p>
</div>

を考える。前者の「セクションDIV」は見出しレベル的に上のh2要素と並列で、
後者はh2要素の下位の構造。しかし、これが並列のセクションか下位の
セクションかは、<div>開始タグを読み込んだ時点では分からず、次の見出し
要素を読み込んでから遡って解釈する必要がある。これはSGML/XMLの解析方法に
反する。故に、このDIV要素はセクション構造を表し得ない。

>>149 のつづき。
この問題の解決方法は3つある。

1. 見出し要素をDIV要素内に書くことを禁止する。
…これで、見出し要素が出てきた時点で並列か下位かは分かるので、常に
シーケンシャルに構造が決まる。
2. すべての見出しをセクションDIVで囲み、セクションDIV以外のDIVを禁止する。
…これでDIV要素の入れ子で並列か下位かが分かるので、常にシーケンシャルに
構造が決まる。この場合、DIVは常に下位セクションの始まりとなるので、
セクションDIV以外のDIVが許されなくなる。
3. DIV要素とは別にセクションを表す要素を設ける。
…DIV要素は汎用となり、セクション要素でセクションを表せる。

HTMLで階層セクション構造を表すには、この3つ以外に解決方法はない。
ISO-HTMLは当初 3. を目指していたが、HTML4.01Strictとの互換性を要求された
ので出来なくなった。2. を採用すると汎用ブロック要素がなくなってしまう。
結果、1. しか方法はなくなった。

一見、結論のDTDだけを見ると特殊に見えるISO-HTMLも、目指したことは、
XHTML2.0のsection-hと同じだ。だから、section-h構造とISO-HTMLが相容れ
ないなどというのは的外れ。ISO-HTMLがStrictの方向の眼前にあるというのは、
その結果のDTDについて言ってるのではなく、見出しの階層セクションという、
その目指した設計思想について言っている。

>>149
あー、それでsection要素のマークアップがあんな事になるわけかー。
よくわかった。

h2の下位なら前者もh3なんじゃ？

なんで前者は

<div class="section">
<h2>見出し</h2>
<p>…</p>
</div>
<div class="section">
<h2>見出し</h2>
<p>…</p>
</div>

じゃないん？

ちなみに後者の場合は

<div class="section">
　<h2>見出し</h2>
　<p>…</p>
　<div class="section">
　　<h3>小見出し</h3>
　　<p>…</p>
　</div>
</div>

だな。
言いたい事の為に都合のいいように省略してそれを根拠にするのは(･A･)ｲｸﾅｲ!!

>>154
省略しても明示しても意味するところは>>153->>154って意味じゃない？

>>155
いや、わざわざ省略するからこういう状況になるって事ね。

>次の見出し要素を読み込んでから遡って解釈する必要がある。
>これはSGML/XMLの解析方法に反する。

わざわざ問題があるように書く必要はないでしょ？
問題が無いように記述するのは当たり前なんだから。
手間の点やdivだらけになるとかで問題とするとかはまた別として。

うん

俺はdiv区切り否定派だけど、セクションdivはありだと思う。
ただdivをセクションとして使うなら厳密に使わなければならないから、
>>138の例示のような使い方はありえない。
どこのセクションにも属さないものが突然現れたらそこで階層構造が破綻する。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4
> DIV要素とSPAN要素は、id属性及び class属性と併用することで、
> 文書に構造を付加するための一般機構を提供する。
構造を付加します。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.5
> 次の例は、見出しとそれが導くテキストとをDIV要素で連結する方法を示している。
> こうすることで、スタイルシートによってセクション単位のスタイル定義(背景色や
> フォント設定等)を行うことができる。
見出しと内容を連結できます。

とはいえ、ネストするdivセクションもどき間の関係までは意味づけされない。
(単なる汎用ブロックの上下関係が構造として明示されるだけ)
だからセクションではないんだよな。セクションと似たような構造を付加するだけで、
セクションのように構造の上下でレベルの上下を表すことにはならない。

これはXHTML1,XHTML1.1でも変更はないと思ったが、なんかこの点を変更するような
文言はあったっけ？ 要素の意味は継承するよね？

>>158
> どこのセクションにも属さないものが突然現れたらそこで階層構造が破綻する。
>138のAAAはセクションd1に属してるつもりだと思ったんだが違うのかな。

>>138もdivの使い方が中途半端で構造を提供できてないって感じだな。
それだけじゃなんともいえない。

>>159
AAAはid=d1のh2の内容、BBBはh1の内容、
CCCとDDDはid=d2以下のそれぞれのh2の内容
id=d1とid=d2の構造が違うのはsectionに限らず
単なる区切りとしても使えると思っていたからです

>159はBBBのことを言いたかった。
　誤 >138のAAAはセクションd1に属してるつもりだと思ったんだが違うのかな。
　正 >138のBBBはセクションd1に属してるつもりだと思ったんだが違うのかな。
まあそれでもそもそもの(こちらの過失による)誤読がひどかったわけだが。

改めてよく読んでみたが、div#d2については
<div id="d2">
　<div id="d2a">
　　<h2>hogehoge2</h2>
　　CCC
　</div>
　<div id="d2b">
　　<h2>hogehoge3</h2>
　　DDD
　</div>
</div>
としないとHTML4系のdivセクション(もどき)にはならないと思う。

で、セクションを意図しない見出しだっていうんだよな？
それは整合性が取れてないと思う。で、整合性がとれてないゆえに、
h1のかかる範囲が不明になってる。

HTML4系のdivセクションとして解釈するならh1の外側をdivで囲んでやれば、
(仕様が示すように)div#d1とBBBとdiv#d2(つまり同階層全部)にかかると定まるけど、
それを無視してるから、h1がどう結合するのか不明。

h1 の外側は body で囲んでるって前提じゃないの？

>>153-154
その書き方は >>150 の 2. の方法を採ろうとしているわけでしょ。
でも、その方法でセクションを表そうとすると、セクションDIV以外の
DIVは許されなくなるよ。

<div>
<h2>見出し</h2>
<div><p>…</p></div>
</div>

と

<div>
<h2>見出し</h2>
<div>
<h3>小見出し</h3>
<p>…</p>
</div>
</div>

の両方があり得る状態だと、h2要素直後の<div>開始タグを読み込んだ時点
では、次にどっちの構造が来るか（下位のセクションかただのDIVか）が
区別出来ないでしょ？　中の要素を読んでから判断するのは駄目だから、
つまり、DIVでセクションを表すと決めたなら、DIVを汎用には使えなくなる
わけ（セクション専用になる）。

ISO-HTMLの見出しの階層構造だけど、
見出しは BODY 直下にしか置けないから、
DOMツリー的にみれば、h1 も h2 も h3 も同じ階層になってしまう、ってのがなあ。

ついでに >>149 の理論は 「まず見出しレベルで構造を示す」 という発想なんだよね。
<div class="section"> を使うのは、 「<section> がまだないから代わりに仕方なく使う」 のであって、
>>150 の 2 ではないと思うんだけど。

>>150 の 2 は、
「<div> を <section> として扱う」 ってことであって、
「<div class="section"> を <section> として扱う」 ってことではないよね。

「div に class つけたところで div は div でしかない」 ってのが理論の元にあるんだろうけど、
その話はまあループなわけで、証明というには説得力にかけるな。

>>139
見出しがセクションを作り出す事はHTML4.01の仕様書にも書かれているよ。
まあ、仕様書にはそのセクションの範囲が書かれていないのが一番の問題点
で、だからこそDIVで区切れるかどうかという議論が出てくる訳だ。DIVで
区切れるとは仕様書には書かれていない。でも、少なくとも見出しを書くだけで
セクションになることだけは間違いない。

ISO-HTMLはセクションの範囲を、その見出しの直後から、その見出しと同位か
上位の見出しが現れる直前までと規定したわけだけど、これはそんなに特殊な
考え方ではないと思う。従って、HTML4.01でも同等とする考え方も特殊では
ないはず。

>>164
いや、sectionの代用として使おうとするからだめなのであって、
ただの塊、ブロックとしてみるのであれば遡る必要さえないんじゃないかね。

>>165
ISO-HTMLをDOMツリー的に見てもしょうがないと思うけど。

代用というか補助的というか、本音をいえばスタイルシート用。

>>167
その通り。ていうか、それが俺の言いたかった事だが。

>>149 の先頭で書いたように、「DIVはただの塊であって、セクション構造は
作れない」というのが言いたかった事。分かってると思うが、149=150=164 ね。
164の部分は背理法とでもいうか…。

>>166
> 見出しがセクションを作り出す事はHTML4.01の仕様書にも書かれているよ。
どこに。

>>165 >>169
ISO-HTMLが現在のDOMやCSSと親和性が悪いのはその通りだが、だからと言って
ISO-HTMLが悪いとは一概に言えないと思う。例えば、

section(h3#foo) { border: 1px solid }

みたいなセレクタで、そのh3要素から次に現れるh1/h2/h3要素の前までが
選択されるとすれば、CSSのためのセクションdivなどは要らなくなる。

つまり、現在そういうセレクタがないCSSの機能がしょぼいということで
あって、ISO-HTML側の問題ではない。結局のところ、そのセクションdivは
装飾のためのdivだったということだし。

上記のセレクタが導入されれば、大半の装飾用divが排除出来ると考えれば、
明らかにこれはCSS側の不備だよ。

>>170
XHTML2.0だっけ？のsectionは
<hn></hn><section></section>
予定だから、それに合わせるといいんじゃね。
見出しの後が確実にsection用途のdivならその辺も全て解決する。
なんで
<section><hn></hn></section>
じゃないんだろうって思ってたんだが、その辺を考えるとなんとなく納得だな。
ちょっと新しい発見だった。

<h2>見出し</h2>
<div>
　<div><p>…</p></div>
</div>

<h2>見出し</h2>
<div>
　<h3>小見出し</h3>
　<div><p>…</p></div>
</div>

こんな感じか。

>結局のところ、そのセクションdivは
>装飾のためのdivだったということだし。

え？どの辺が･･･？
dl-dt-ddのdt-ddの関係と同じで、hnとsectionが対になってるという
ただの構造だと思うんだが。

>>171
見出し要素の説明部分だよ。日本語訳を見ると分からんが原文を読むと、

A heading element briefly describes the topic of the section it introduces.

これは関係代名詞 that (whom) の省略された文で、文をバラすと、
A heading element introduces a section.
A heading element briefly describes the topic of the section.
の2つの文になる。つまり、
「見出し要素はセクションを導き出す（始める）」
「見出し要素はそのセクションの話題を短く記述する」
を一つの文にまとめたもの。

従って、見出し要素でセクションが始まる。どこで終わるかは書かれてない。

>>173を書いてからふと思った。
<hn></hn><div class="section"></div>
でやるとして、floatとか背景をいじるとしたら、divでくくったりする必要があるし、
互換モードでieとの差異を吸収する為にdiv入れ子してborderやmargin等を設定するとなると、
さらにdiv成分が増えまくり。

考えただけでもげんなりするなｗ
テーブルレイアウト並に見づらいし、インデントが深くなって読み難いとかもでてくるし。

>>176
XHTMLって前提だけど、
その辺はユーザサイドXSLT変換で乗り切ってみるってのは？

>>174
だから、>>169 が「スタイルシート用」と言っていることに対して言って
いる。すべてのセクションが装飾用だなんて言ってない。

そして、CSSがこの機能を持てば、>>169 がやっているような装飾用divを
なくす事ができるという意味だ。

>>176
それもCSSがこのsectionセレクタ機能を持てばすべて解決。
結論……ISO-HTMLは悪くない。CSSがしょぼい。

>>173
＞XHTML2.0だっけ？のsectionは
＞<hn></hn><section></section>
＞予定だから、
違うぞ。
ttp://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.18.

>>175
　> A heading element introduces a section.
じゃなくて、"A heading element introduces the section."が正解だな。
任意のsectionの話じゃなくて、ある見出しがintroduceするそのsection、
という限定・特定の意味だから"the section"になってる。

つまり「見出しでセクションが始まる」なんて言ってるわけじゃなくて、
「ある見出しが紹介するところのそのセクション」について言及する、
という意図しかない。

だいいち、
> The following example shows how to use the DIV element
> to associate a heading with the document section that follows it.
で、「divで見出しとセクションを関連付けるよ」って言ってるんだから、
そうしない限りはセクションとその見出しは、(たとえセクションが後続しようが)
関連付けが明示されてない(暗示でしかない)と見るのが自然だろ。

>>172
> ISO-HTMLが現在のDOMやCSSと親和性が悪いのはその通りだが、だからと言って
> ISO-HTMLが悪いとは一概に言えないと思う。
ISO-HTMLが構造を明示しないのが元凶だから、ISO-HTMLが悪いだろう。
仕様として「暗示式にしろ」と強制してるならなお一層悪い。

>>178
> >>169 がやっているような装飾用divをなくす事ができるという意味だ。
DOMとの親和性や装飾でないdivについてもISO-HTMLの欠点を補える
他分野の進化を要求するんだろうけど、ISO-HTMLの仕様が元凶なんだから、
対処を求めるとしたらISO-HTMLの方が、問題解決の対象としては道理だと
思うんだが。

>>179
それは最新版じゃない。Latestはこちら。

ttp://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.8.

まあ、これも基本的に
<section>
　<h>○○○</h>
　　　 〜〜〜
</section>
なのだが、h1要素に相当する部分のh要素だけは
body要素の直下に来るようになっているようだ。

>>180
どちらにせよ、見出しがセクションをintroduceすることには変わりないだろ。

それに、
The book he found is mine.
は、
He found a book.
The book is mine.
をまとめたもの。関係節になると特定になるんだよ。彼が見つけた本は
ただ（不特定の）の本だが、それが私の本だったんだから特定なんだよ。
じゃあ、セクションを始めない見出しがあったとしたら、その見出しは何を
記述してるんだよ。仕様書では一切言及されてない…ってか？

... to associate a heading with the document section that follows it.
は「見出しとセクションを関連づけるよ」じゃなくて、「見出しと、その
見出しが従えるセクションを結びつけるには」だろ。つまり、見出しが
セクションを従えているのは既定なんだよ。

装飾用divをなくすとか言ってるけど、
Strictにやるならもとよりそんなものあってはならないんじゃないの？

>>182
おおサンクス。
まあほとんど変わっとらんのだが。

究極的には装飾要らないんじゃない？
可読性とかのために、用途に応じてちょっと整形することがあるかもしれないにしろ

>>183
> をまとめたもの。関係節になると特定になるんだよ。彼が見つけた本は
> ただ（不特定の）の本だが、それが私の本だったんだから特定なんだよ。
ここはその通り俺が間違えてると思う。正しくは
　A heading element introduces a section.
　The heading element briefly describes the topic of the section.
だろう。
「ある見出し要素があるセクションをintroduceする」
「その見出し要素はそのセクションのトピックを簡潔に記す」
ということだな。

どちらにしろ、すべての見出しはセクションを開始する、というような
意味はどこにもないだろう。そういう風に言う場合は、たとえば
　> The DIV and SPAN elements
というように、全称的に書いてある。

> セクションを始めない見出しがあったとしたら、その見出しは何を
> 記述してるんだよ。
見出しはなんかのセクションの概要を記述してるんだってば。
「セクションというものは必ず見出しによって開始され、見出しの直後に続く」
なんて言及がないだけで。

> 「見出しと、その見出しが従えるセクションを結びつけるには」だろ。
"the document section that follows it"は、it=headingにfollowsする、
つまり見出しに後続するセクション、ということだよな。で、これも、
見出しの後に出現するセクションに特定して、そのセクションと見出しを
結びつける場合を言ってるだけであって、
　> 見出しがセクションを従えているのは既定
なんてことは書いてないだろ。

邦訳の解釈はそうだとして、じゃあ、見出しはなんの為の見出しなんだよｗ
見出しの後ろが必ずしもセクションにならないなら、divは必須になってしまうではないか。
そしてdivはそれ以外には使いようもない。

文書の途中で突然英文とか外国語の纏まった幾つかの段落入れたいけれど・・・
って時に<div lang="de">とかやるのに使えるんじゃないかな？
いちいち<p lang="de">たくさん作ってもいいけど、
どうせ纏まってるんだから、って時

--
<p>そこで私はこういいました．</p>
<div lang="fr">
　<p>Comment vous appellez-vous?<p>
　<p>Je m'appelle Tsukasa.</p>
</div>
<p>えー、、、ですが、相手は〜</p>
--

こんな感じに書きたい時

>>189
dl,dt,ddだな

>>188
> 邦訳の解釈はそうだとして、じゃあ、見出しはなんの為の見出しなんだよｗ
セクション構造のためとは限らない見出しで、じゃあ具体的になにと見出しが
対応しているか、ということは、特にdivなりで明示してなければHTMLの範囲外の
文脈での話だよ、という感じだな。
それでも見出しとして意味づけされるんだから意味は十分ある。

> そしてdivはそれ以外には使いようもない。
なに言ってんの？

>>191
>なにの(内容)と見出しが対応しているかdivなりで明示
じゃあ、明示していなければ見出しは見出しのみで階層だのなんだのしてるわけかｗ
>見出し後のセクションがその見出しのセクションとはかぎらない。
ならセクションじゃねーじゃん。

>>191
セクション構造の為の見出しとは限らない見出し。
見出しはセクション構造を作ったり作らなかったりするのか。
明示する事によってセクションは作られるのか。
明示しないものはセクションではないのか。セクションではあるが、見出しと結び付いていないだけなのか。


それとも、見出しの有無に関わらずセクションは常に有るのか。divによって自由に操れるのか。

結局divdivしたいだけのおばかさん。

見出し要素は章立てするのと同じように使えばいいのではないか？

>>191
divがなければ見出しがどこからどこまでの内容に対応しているのか
文脈でしか判断できないって言うの？
本気で言ってんの？

>>187
省略された関係代名詞でつながっているのは section という語であって、
heading element ではない。それに、heading element は主節の主語なので、
そちらが冠詞 A が付いていて、従属節でそれを it で受けているのだから、
むしろ従属説の方が特定だよ。

ここを「ある見出し」と解釈すると、「セクションの概要を記述する」
ということ自体、全ての見出しに成り立たなくなる。それにその解釈だと、
「見出しはセクションを始める事も始めない事もあるが、見出しの後ろに
セクションがある場合はDIVで結びつける事が出来る」と読めてしまう。

ならば、セクションを始めない見出しはDIVで結びつけることが出来ないという
ことになり、さらに、どんな見出しがセクションを始め、どんな見出しが
セクションを始めないかは書かれてない、となる。それではDIVも何の意味も
なく、見出しも何の意味もなく、定義が不十分。その解釈はおかしい。

DIVを使って「見出し」と「見出しに後続するセクション」を結びつけることができる

という文だから、DIVは単に結びつけるだけであって、セクションが見出しに
後続するのはDIVなしでも成り立つ。という解釈が自然だな。

というか、その上の方にある文を見ても、「見出しは、その見出しが始める
セクションの概要を記述」だから、セクションとは、見出しに後続する、その
見出し自身を含まない部分と解釈出来るな。見出しからセクションが始まる
のではなく、見出しの後から始まる。

<h2>見出し</h2>
<p>セクションはここから始まる。</p>

で、両者をセットにしたけりゃDIVを使えという感じだろう。

>>196
二文に分けるとき、前者の文のheading elementはitで特定されている
ものにあたるんだから、後者の文で不定冠詞なのはおかしいだろ。

> 全ての見出しに成り立たなくなる。
つまり、セクションの見出しにしか限定するものじゃない
見出し全般として使えるものと考えればすむことだな。

> 「見出しはセクションを始める事も始めない事もあるが、見出しの後ろに
> セクションがある場合はDIVで結びつける事が出来る」と読めてしまう。
だから「見出しはセクションを始める事」なんて言及はないって。
「見出しはセクションを始める事もある」なんて書いてない。
セクションが開始されるなんてことは書いてないんだから、
すべてセクションを開始しない見出しだよ。(見出しがセクションを開始する
他の仕様にとらわれすぎじゃないか？)

単に、見出しとその後にあるセクションをdivによって結びつけることができる、
ということなのに、セクションの開始とかいう書いてないことを読み取ろうとするから
> セクションを始めない見出しはDIVで結びつけることが出来ない
なんてとんちんかんなことになる。

> その解釈はおかしい。
となるのは、すべて「見出しはセクションを開始する」ということを前提にしている
せいであって、それの根拠であるところの文
　> A heading element briefly describes the topic of the section it introduces.
は、
> つまり「見出しでセクションが始まる」なんて言ってるわけじゃなくて、
> 「ある見出しが紹介するところのそのセクション」について言及する、
> という意図しかない。
ということだろ、と>180,187で言っている。見出しを開始するなんて読むことが
間違いだってこと。

>>197
> セクションが見出しに後続するのはDIVなしでも成り立つ。
見出しにセクションが必ず後続するということが成り立つ、と言ってるつもりなら、
わざわざ見出しに後続するセクションだなんて特定する必要はないから、
その解釈は不自然だよ。
that follows it が自明なのならそんな言及をする必要はなく、
a heading with the document section だけで十分。

>166のように、「HTML4.01でも同等とする考え方も特殊ではないはず」
という思い込みがあったから、不定冠詞なのを無視して「すべての見出しは
セクションを開始する」と読むし、「関連付けのためにdivを使える」というのに、
なぜか>197のように「divがなくとも結びついている」と解釈したり、「見出しに
後続するセクション」に限定して語っている文を「すべての見出しはセクションが
後続する」と解釈したりすることになる。

途中経過の議論をすっ飛ばして、整合性が一番取れそうな結論としては、

<hn>hogehoge</hn>
<div class="section">
　<p>huga mogera</p>
</div>

って使い方でdiv使うならより確実って事？

>>198
だいたい、heading element が section を introduce すると書いているのに、
セクションが始まらないって、どんな introduce のしかただよ。introduce
には始めるや挿入するという意味もあるのに。

> 単に、見出しとその後にあるセクションをdivによって結びつけることができる、

じゃあ、divで結びつける前からそこにはセクションが存在していたんだろ。
そのセクションはどこからわいてきたんだ？

そっちこそ、見出しでセクションは始まらないという思い込みがあるから
そういう解釈になるんじゃないのか？

>>201
　> だいたい、heading element が section を introduce すると書いているのに、
日本語にするときに冠詞を無視したために文意が変わってる。
　> セクションが始まらないって、どんな introduce のしかただよ。
どうおかしくなるか言わないと。
　> introduceには始めるや挿入するという意味もあるのに。
「そう取るのはおかしい」ということをいままで説明してきたんだよ。

> そのセクションはどこからわいてきたんだ？
涌くもなにも、すでにあるセクションをマークアップするんだよ。
セクションはもともとあるもので、見出しを置いたから涌くというものじゃないだろ。

> そっちこそ、見出しでセクションは始まらないという思い込みがあるから
> そういう解釈になるんじゃないのか？
疑うだけならなんの根拠もなくできるから、根拠を添えて言わなきゃ意味ないよ。

見出しはセクションをつくらないなら、セクションはどこにあるんですか？

セクションなどない

ないものをどうやって結び付けるんですか？

今北産業

>>205
多分お前の相手が言いたいのは、「見出しによってセクションが生成されるのではなくて
定義されていないだけでセクション的な内容は既に存在している」みたいなことだと思われ。
それを見出しと結びつけることによってセクションと定義してるだけじゃないの？

>>200
ISO-HTMLだと>>200の方式だけど、
XHTML2.0だと>>182の方式
HTML4.01も(仕様の例を見る限りは)>>182の方式で、
XHTML1,XHTML1.1でも同じ。

ISO-HTMLを使い続けるつもりじゃないなら、
セクションdivの中に見出しとセクション本体を突っ込むのが
いいんじゃない？

じゃあdivで関連付けしないと不明なセクションだらけになるから全部囲まないとなｗｗｗ
バカか？

TeXにはセクション(section)がある。
HTML には無い。
見出し要素の説明として、セクションという言葉が出てくることはある。

見出しを置かないとセクションが発生しない、とした場合、

<title>タイトル</title>
<body>
<p>あれこれ</p>
<p>かれこれ</p>
</body>

の 「あれこれ〜かれこれ」 はセクションじゃない、ってことにならん？

>>208 の論理がわかんね。

やっぱ見出しは見出しでしかないなあ。
なんかあんまり議論に参加しないで、ぽっと発言するのも悪いんだけど。

例えば、日記でも漫画でも小説でもいいんだけど、
「第一話: なんとか」 「第二話: かんとか」 ってあったとして、
それの 「見出し」 を付けなかったらどうなるだろう？
そしたら最初から最後までただひとつのセクションになるのか？
「見出し」 があろうがなかろうが、そのセクションはそのセクションで存在してるでしょ。

普通の文章をマークアップするときだって、
　　<p>まず 「○○」 の場合、どーたらこーたら・・・</p>
　　<p>では次に 「××」 の場合を考えてみよう。この場合、なんたらかんたら・・・</p>
　　<p>最後に 「△△」 の場合について考える。この場合、なんたらかんたら・・・</p>
こう書くのは普通に 「アリ」 だよね。

また、これを、
　　<h2>「○○」 の場合</h2>
　　　　<p>どーたらこーたら・・・</p>
　　<h2>「××」 の場合</h2>
　　　　<p>この場合、なんたらかんたら・・・</p>
　　<h2>「△△」 の場合</h2>
　　　　<p>この場合、なんたらかんたら・・・</p>
こう書くのも 「アリ」 だよね。

でも、後者のように書いたときに初めて 3つのセクションがつくられた (3つに増えた)、って考えるのはおかしいと思う。
もともと同じレベルで 3つのセクションがあって分かれてた (分割可能だった) から、そこに見出しをつけれただけじゃない？

>>211
同意。divによるグルーピングがどうして「不明なセクション」の解消になるのか？
セクションであることを明示することとセクションの内容が不明なことは別だし、
divで囲むことでそれを明示できるようになると思い込んでる時点で対話不能な気がする。

>>213
じゃあなにをどうやっても見出しとセクションは関係ないということですね。

>>213
だからバカかと言っとるがな。

だからそんなこと誰も言ってないのにそう解釈してるから理解できんって言ってるわけだが。

LaTeXの\chapter をHTML の h1要素に、
LaTeXの\section をHTML の h2 要素に、
LaTeXの\subsection を HTML のh3要素に、
LaTeXの\subsubsection を HTML の h4 要素に読み替えてみる。

論点ずれてて冷ややかにﾜﾛｽｗ

\part, \chapter, \section, \subsection, \subsubsection, \appendix.
h1, h2, h3, h4, h5, h6.
\appendix　が微妙なところだ。 subsubsubsectionという意味ではなさそうだ。

part, chapter, section などの言葉にとらわれずに、
h1,h2,h3,h4,h5,h6 と並んでいる。
とりあえず、大きいほうから順に使ってみよう。

>>216
じゃあおまえは見出し付けなくてよし

なんでそういうことになるのかもわかんね。

>>213
見出しとその後ろのセクションが関係なく、divによってグルーピングも出来ないとなると、見出しとセクションは一切関係ないということですね？

>>223
>見出しとその後ろのセクションが関係なく

俺はそんなこと言ってないぞ？

>divによってグルーピングも出来ない

divによるグルーピングは出来る。
それをセクションとして意味づけするのは今のところ制作者か好意的な解釈の場合のみ。
section要素が使えないのだから仕方がない。

>見出しとセクションは一切関係ない

俺はそんなこと言ってないぞ？

HTML4におけるセクションと見出し

・セクションであることの明示
できません。セクション部分の構造をdivやその他要素として明示することはできます。
ただしその場合でも、セクションとしてのレベルの上下を表すことはできませんし、
そもそもdiv要素はその内容がセクションであるという意味づけをしません。

・セクションと見出しの関連付け
仕様にある例のようにdivの中に見出しとセクションをぶちこむことで、関連付けできます。
セクションは明示できませんが、明示するか否かと関係なくセクションは存在しますから、
そのセクション部分をdivの中にぶち込むことで、セクションと見出しとの関連付けができます。

・関連付けしないとどうなるの？
HTML上で関連付けの意味づけがなされていない状態です。
ただし、この状態はとくに禁止されてはいません。

・見出しを置いたら、以降はセクションになるんでは？
見出しはそのような意味づけをしません。
ゆえに、見出しの直後に見出しの表すセクションがこないような文書もマークアップ可能です。
ただし、見出しとセクションが分断されている場合、それらのみをdivにぶちこむことはできないので、
それら見出しとセクションの関連付けを明示することはできません。

>>225
<div class="h1" id="h1-1" >
<h1>ニュース</h1>
　<div class="h2" id="h2-1">
　<h2>またいじめで</h2>
　<p>またいじめでなんとかかんとか。</p>
　</div>
　<div class="h2" id="h2-2">
　<h2>あの神田うのが</h2>
　<p>ついに神田うのがなんとかかんとか。</p>
　</div>
</div>


<div id="midashitokankeinaiyo">
<p>バカは氏ねばいいのに。</p>
</div>


↑これがStrict的にありだと？

<div class="section">
　　<h2>見出し2</h2>
　　<div class="block_or_group">
　　　　<p></p>
　　　　<p></p>
　　</div>
　　<div class="section">
　　　　<h3>見出し3</h3>
　　　　<p></p>
　　</div>
</div>

この場合のclass="section"は下位にh3が有って初めてsectionとして成り立つから
要素構造をシーケンシャルに解釈できないと言ってる人がいるけどさ、
これってただのdivだからsectionと判別できるかどうかは関係なくね？
sectionと同じ囲いをしてるけど、sectionという意味付けを持たせてるのではなく、
ただdivで一つの塊にしただけだから。

なんでsectionと区別出来ないからdivは使えないとかいう結論になるのかさっぱり理解できんｗ
classやidでは意味付け出来ないでFA出てるうえに、ただのdivなのにな。

<div class="section">を<section>に変えてもdivと区別はつくし、
divに意味付けがsectionとされてる場合を考えるとclassで意味付けぐらい？
この場合は意味付けされてるから遡って判断しなくてもsectionとわかるんだよな。
どう考えてもsectionでdivを使うとグルーピングでdivが使えないって結論にならない気がする。

何が言いたいんだろうか。だれか解説してくれ。

>>226
html的には全部ただのグルーピングでしかないな。
人間が見るとそのdivはsectionを表してるとはわかるが。

>>226
ない。
>>225もない。

>>226
逆にそれがナシなら、こういうのも Strict ではないってこと？

<body>
<div id="header">
　ページの案内とかアンカーとかをどーこー
</div>
<h1>ニュース</h1>
<div class="section">
　<h2>またいじめで</h2>
　<p>またいじめでなんとかかんとか。</p>
　<p>そういえば自らの国家や民族に固執する右翼系の若者が世界的に増えているという事実も、多少気になるところだが</p>
</div>
以下略

>>202
it は主語を指しているから「セクションをintroduceする見出し」と
「トピックを記述する見出し」は同じものだよね。A heading element を
「ある(certain)見出し要素」の意味だというのなら、「見出しはトピックを
記述する」ということ自体すべての見出しについては言えない事になるよ。
じゃあ、そうでない（トピックも記述しないしセクションもintroduceしない）
見出しは何をするの？　仕様書にはそうでない場合は何も書いてないんだが。

セクションは元々あるというのは、例えば「P要素を置いたから段落になる
わけではない。元々ある段落を表すためにP要素を使うのだ」みたいな論理を
言ってるのか？

それならそれでもいい。セクションは元々そこにあった。そのセクションの
トピックを記述するために見出し要素を置く事が出来る。ということは、
見出し要素が置かれているということは、そこにセクションがあるということ
だろ？

>>230
ない。
文書は重要な内容を前にするのが基本だから、ナビゲーションが一番重要とは思えない。ナビゲーションにも適切な(下位の)見出しを付けて後ろに置くべきだと思う。そして実際の表示の順序はスタイルシートで、というのが理想だけど。
実際無理だわなｗ


ページ内で便利にリンクしたりするなら上に表示されないと実用的な意味は薄れる。仕様書もその形だ。それでそのナビゲーションの存在自体も適切なのかという疑問も湧く。
一番前に書いたモノが一番上に表示されるとは限らない(表示とも限らない)。
便利に使えるから書く、使えないから書かない、というのもStrictと違うな。
文書の構造として必要なら書く。だから宗教。

つまり、
＞ A heading element briefly describes the topic of the section it introduces
を誤解のないように和訳するとどうなるの？

>>232
＞文書は重要な内容を前にするのが基本
これはどこの社会の基本かわからんがｗ

後ろに置くのをよしとしたら >>226 はアリにならね？
ってか今度は ISO-HTML派が 「ナビとかは後ろには置けない」 とか言いだすんじゃね？

「下位の見出しを付ける」 ってのは疑問符だけど、ここは主題と逸れるので置いておく。

>>227
話の前提がごっちゃになってるぞ。

・divはただのグルーピングだと見なした場合
　→ <div class="block_or_group"> の形でも <div class="section"> の形でも
　好きな形でdivが使える。ただし、<div class="section"> の形で使っても
　それはただの塊であって、セクションの意味にはならない。

・divでセクションを表せると見なした場合
　→ シーケンシャルに考えると、div開始タグだけで下位セクションが始まって
　しまうことになるので、divを一般のグルーピングとしては使えなくなる。

で、HTML4.01/XHTML1.x は前者の方だ。divでセクションなんて表せないんだ
というのが結論。

「見出し要素（に）は、その見出し要素が従えるセクションの内容を簡単に記述する」ぐらいか？
2文に分けると却って解り辛くなると思う。

んで疑問なんだが、この文中の"section"と、xhtml2.0のsection要素が示す"section"って同じものなんだろうか？

そもそも 「divでセクションを表せる」 なんて誤読以外で誰か言ってた？

>>234
WCAG1.0
Section 508

>>231
> 仕様書にはそうでない場合は何も書いてないんだが。
　> Headings: The H1, H2, H3, H4, H5, H6 elements
と書いてあるだろ。そこに限らずHnの説明やら見て分かるとおり
HnがHeadingであることは示されてる。
見出しの情報をUAが参照してどうこうするかもね、
ということも書かれている。
見出しには6レベルあり、見出しの重要度によってレベル
付けされることも書いてある。

何も書いてないって本当か？

> そこにセクションがあるということだろ？
必ず見出しの直後に出現するとは限定されてないけどな。
ましてや、見出しの直後からは必ずセクションと意味づけされる
なんてことは書いてない。

>>235
「好きな形でdivが使える」というのは語弊があったので訂正。
<div class="block_or_group"> の形でも <div class="section"> の形でも
使える。ただし、以下のように見出し構造をぶった切るdivについては議論の
余地あり。

<div>
<h2>見出し</h2>
<div>
<h3>小見出し</h3>
<p>…</p>
</div>
<p>…</p>
</div>

>>235
いや、多分貴方が混同しちゃってる。

ただ、後者の場合はdivでsectionの意味付けをできるのであれば、
それは現実的に考えてclassやid名でやるしか選択肢はない。
そうなるとclass名でsectionを表せることになる。
だから、わざわざシーケンシャルに考えても
下位セクションから遡って判断する必要が無い。

どっちにしてもdivで問題ないじゃないって言ってるんだが、
今補足した部分以外は言ってる事は同じだから。

>>240
それは<p>…</p>がh2の見出しレベルの支配下にあるって構造だってだけでは。
構造を与えない場合はh3の支配下に来る筈だが、
構造を提供する事によりそれが明確にh2の支配下だって示したに過ぎないんじゃね？

あ、ちなみに>>241はあくまでsectionと意味付けできると「仮定した場合」の話ね。
現実はただのdiv(ブロックやグルーピング)でしかないから、
遡ってsectionかどうか判断する必要さえない。

>>238
508?

>>239
＞(セクションが)必ず見出しの直後に出現するとは限定されてないけどな。ましてや、見出しの直後からは必ずセクションと意味づけされる なんてことは書いてない。



じゃあ、どうやって区別すんだ

区別しなきゃならんような状況があるのか？

>>246
限らないんだから、
<h2>見出し</h2>
<p>内容</p>
だと足りないんだろ？

区別したい時に構造を付与すれば良いだけじゃ。

>>248
その構造はなに？
divとか言うなよ。

>>247
なにが足りないの？

>>249
divだという話がとっくに出てるのに、いまさらそんなことを言うなよ。

>>250
おまえは全部読んで流れを把握しろ

>>248-250
divは「見出し」と「見出しに続くセクション」を結ぶことが出来るという
だけだから、divを付けたからといってセクションになるわけじゃないし、
divを付ける前からセクションになっている。

そして、「見出し」の後にセクションがあることもあれば、ないこともある
とする説に従うなら、見出しの後にセクションがある時だけdivでグループ化
出来るが、見出しの後にセクションがない時は、divを書いても意味がない
という理屈になる。

>>249
いい加減div要素に特定の意味があると思い込むのやめなよ。

>>241
そもそも属性は意味を付加する事が出来るだけで要素の構造は変えられない。
class名によって並列構造か下位構造かを切り替えることが出来るというのは
設計自体おかしいよ。だからclass名で区別というのは最初からあり得ない。

>>242
divで区切れるかどうかは議論の分かれる所なので、それは一概に言えないよ。

>>252
>divを付ける前からセクションになっている。

そして、「見出し」の後にセクションがあることもあれば、ないこともある
とする説に従うなら


>セクションになってる。
>セクションがあることもあればないこともある。

なってないじゃん。

流し読みだけど、要するに、
div要素でセクションを明示することは出来るけれど、
divがセクションになるんじゃなくて、意味的には

<section>
　<div class="section">
　　○○
　</div>
</section>

ってこと？
で、しかもこれで「区切れてる」かどうかは謎なので、
自明の場合にそれを囲い込む以外の用法で使うのは危険ってこと？

>>252
> 見出しの後にセクションがある時だけdivでグループ化出来るが、
> 見出しの後にセクションがない時は、divを書いても意味がない
> という理屈になる。
divは見出しとセクションの関連付けしかできないだなんて、252しか言ってないよ。
divは構造を付加する一般機構で、見出しとセクションを関連づけるといった
ことができる、ということ。

仕様書は見出しとその後のセクションの関係があって、それを前提として、その区切りにdivを置いてやればいろいろ便利かもね。ってだけの事だろ。
見出しの後にはその見出しの内容がある。内容には見出しを付ける。当たり前の事だろう。ここはStrictスレじゃないのか。

>>256
> div要素でセクションを明示することは出来る
できない。そういう意味はdivにはない。

>>259
セクションの範囲って意味ですたよ
ただ、それが「セクション」であることは解らないけれど

>>258
Strictスレなので、スレを読よまずに一方的に思い込みを垂れ流すのはご遠慮ください。

>>261
Strictな日本語でおｋ

>>261
仕様書はそうだ。
セクションの関連付けた区切りにDIVを入れて見せただけのことだ。

>>260
見出しと、見出しの後に続くセクションとを関連付けるdiv、ということだから、
　<div>
　　<h2>見出し</h2>
　　　...セクション本文(内容)...
　</div>
というように、見出しの後にセクション部分をおいて、
それをdivで括る、というのが仕様にある例。
で、
・この外側のdivはセクションdivっぽい構造をつくってるけど、
　セクションと意味づけしたことにはならない。
・セクション本文(内容)をセクションとして意味づけするタグもない
ということ。

"本文内容としてのセクション"と"セクションの見出し"が"セクションdivもどき"
の中に入ってる、ということだな。セクションという言葉が被ってて分かりにくい。
(HTML4の仕様では、セクションは"内容本体としてのセクション"をさして言っていて、
"セクションdivもどき"をセクションとは呼んでないから、混同はないんだが。)

ごめん嘘ついた。
>>264
　> (HTML4の仕様では、セクションは"内容本体としてのセクション"をさして言っていて、
　> "セクションdivもどき"をセクションとは呼んでないから、混同はないんだが。)
仕様書でも両方使ってた。

>>256
セクションはdivを付ける前から決まっている。divはそこを囲む事ができるだけ。

<h2>見出し</h2>
<p>セクションがここから…</p>
<p>…ここまでだったとする。</p>

これを

<div class="section">
<h2>見出し</h2>
<p>セクションがここから…</p>
</div>
<p>…ここまでだったとする。</p>

と囲むのは間違い。divでは区切りは変えられないということ。

結局、>>226がナシになる根拠はないんだよな。

>>263
仕様書には
　> 見出しの後にはその見出しの内容がある。内容には見出しを付ける。当たり前の事だろう。
なんて書いてないと既出。>>197,199

>>266
その「ここまで」は次に出現するhnまでですよね？

>>267
なしになる根拠はDIVで意味付け出来ないからだ！！

>>267
おまえか

>>269
divは構造を加えるという意味づけができます。

構造の明示と意味の明示は違うとオモ

構造 = 意味だと明確に解釈できるのは好意的な人間のみ。
UAにとってみたら構造 = 構造。意味まで到達するには不十分。

見出しを付けて内容を書く。
内容を書いたら見出しを付ける。
カレーはやっぱりチキンカレー。
百回唱えろ。当たり前だろ。仕様の問題ではないぐらい当たり前だ。

ばかやろう、ビーフカレーに決まってんだろうが。

クローブ、シナモン、ナツメグ、クミン、カルダモン、メース、こしょう、唐辛子。
さて、divにはどういう意味づけがあっただろう？
HTMLではセクションという言葉もないはずだ。

な？ターメリック抜くだろ。
ネタさえまともじゃないんだこいつは。

あと米。白米じゃないやつね。

ナンもうまいよな

一部の馬鹿がdiv=sectionと混同して批判してるんだよな。

>>254
そうか？そういう設計ならそれはそれで全然問題ないと思うが。

>>281
DTDを考えても、内容モデルは要素だけで決まり、属性では内容モデルを
変えられない。つまり、構造的なものは要素だけで決まるわけだ。
セクションかグループかは内容モデルの違いではないが、基本的に構造が
異なるものを属性に負わせるのはSGML/XML的ではないよ。

例えば、code, samp, kbd などを一つの共通の要素にまとめてしまって、
属性の違いだけにするという設計は問題ない。でも、段落と見出しを一つの
要素にまとめて属性の違いだけにしてしまったら、たとえ両者の内容モデルが
同じであったとしても（DTD的に問題なくても）設計としておかしい。

セクションとグループが属性だけの違いというのは、段落と見出しが同じ要素
みたいな状態だよ。

talk:>>277 インド風のマサラにターメリックは必須ではない。
talk:>>278 米はハーブなのか？
talk:>>279 ナンは加工食品だ。

('A`)？
ここで <div class="section"> 派がいってる 「セクション」 って 「グループ」 のことでないの？

つまり、
<div>
　　<p>なんだかんだ</p>
　　<p>はなかんだ</p>
</div>
で、DIVはただのグループでしかなく、セクションを明示してるわけではない。

が、その2つのPはもともとセクションであったとした場合、
<div>
　　<h2>かくしか</h2>
　　<p>なんだかんだ</p>
　　<p>はなかんだ</p>
</div>
と書ける。

DIVが示してるのは、ただのグルーピングだけど、
内容はひとつのセクションから成っているわけで、それは変わらない。
内容がセクションから成っているから、<div> を <div class="section"> と書こう。

だめなん？

HTML でマサラの説明を書いてみる会をやらないか？
マサラではなくて、他の料理でもいいが。

おひとりでどうぞ

>>285
それは問題ないと思うが、問題は、

<h2>見出し</h2>
<p>あああ</p>
<h3>小見出し</h3>
<p>いいい</p>
<p>ううう</p>

とあった場合、「いいい」と「ううう」は元々「小見出し」のセクション内と
見なせる。divは元々あったセクションを囲む事しか出来ないので、

<div class="section">
<h2>見出し</h2>
<p>あああ</p>
<div class="section">
<h3>小見出し</h3>
<p>いいい</p>
</div>
<p>ううう</p>
</div>

という囲み方は駄目。という考え方も出てくるよな。これだとdivによって
元々とは違うセクションを作り出そうとしていることになるので。

>>288
そりゃあ普通にダメなんでない？

というか <p>いいい</p> と <p>ううう</p> がどう見ても同じセクション内にあったとした場合、
それを DIV で別のように区切るなんてことは誰もしないと思うんだけど。

<h2>見出しA</h2>
<p>あああ</p>
<h3>小見出し</h3>
<p>いいい</p>
<h2>見出しAの続き</h2>
<p>ううう</p>

こんなのだったら、

<div class="section">
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<div class="section">
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</div>
　　<p>ううう</p>
</div>

としてもいいかどうかは、まだ議論の余地があると思うけど、
いまそんな話してたかどうか、すべきかどうかはわからない。

>>289
いや、それのことを言ってるんだが。
divでセクション構造が変えられないとするなら、divに依存するセクション
構造は駄目ではないかと。divで囲む前(divを除いた状態)には「いいい」と
「ううう」の間にセクションの切れ目はなかった訳だし。

元々>>289の後者のはそういう構造だったってだけなんじゃ。
以前前者だったのを後者の形に構造を付与したのならおかしいが、
文書の存在と同時にマークアップが存在すると考えると、
マークアップした時点で既に後者の形になってるべきだし。

だから、前者と後者は全く別の物なんじゃないかね。

そのdivによるセクション構造、階層構造の改変を可とするか不可とするか。
一連の議論の発端は突き詰めるとそこにあったと思うんだが。

div区切り肯定派の理論はそれを可とするものだったから
俺はそれがおかしいと思ったから反対派にまわった。
途中で方向性が変わってきたから議論に参加するのやめたけど。

>>292
いや、構造を可変させるかじゃなくて、
マークアップした時点でその構造を与えられた状態でしょ。
だから、構造を与えられてない状態と比較する事自体がそもそもおかしい気がする。

>>293
sectionというクラス名をつけられただけのdivに
見出しによる階層構造を崩す力があるのかが問題。
>>288の例でいうと
divが無ければh3の配下に入る　ううう　をdivで囲った外に追いやるだけで、
その支配を脱してh2に属するとすることができるんだろうか。
できるのなら、そのdivがそういう意味を持ったものなのか、
それともただの意味の無い、あるいは意味の後付された汎用ブロックにすぎないのか、
どうやって判断するのだろう。
今こういう議論をしている俺らはdivの位置で判断できるが、
全然知らない第三者は推測しかできないんじゃないか？
ましてUAには判断のしようが無いと思う。
仮に階層構造を何らかの方法でレンダリングしなければならなかったとしたら、
それが見出しによってのみ提供されるのなら可能だが、
divまでもがそれを提供するとしたらレンダリングのしようがない。

「文書には最初から構造があり、それをマークアップする」という立場を
取っていてもマークアップ言語の制約からそれが叶わないことがあり得る
よな。例えば、段落内にリストがあるという構造が「最初からある構造」
だとしてもマークアップ出来ないなど。

では、例えば以下のような構造の文書がマークアップ前にあるとしよう。

<section>
<h2>見出し</h2>
<p>あああ</p>
<section>
<h3>小見出し</h3>
<p>いいい</p>
</section>
<p>ううう</p>
</section>

これをマークアップする際に <section> 部分を <div class="section"> と
書けるかだ。既に議論のあったようにdivでセクション構造を表せないとすると、
divを書くことによってセクションの切れ目が変わるという文書は正しくない。
つまり、この構造の文書はdivでは書けない事になる。これはマークアップ言語の
制約であって、段落内にリストが書けないのと同じと考えられないだろうか。

もちろん、divとは別にセクション要素を導入すれば、その要素によって
セクション構造が決定されるので、このような構造を書いて何の問題もなくなる。

>>292
> div区切り肯定派の理論はそれを可とするものだったから
いや、文書のもともとの意味合いを変える、ということは誰も主張してないと思う。
文書のもともとの意味合いにそわないマークアップはそもそも間違ったマークアップ
だから、もともとある構造を明示できても、もともとある構造を変えるのは可能にならない。

>290
> divで囲む前(divを除いた状態)には「いいい」と「ううう」の間にセクションの切れ目はなかった
もとの文書として、そこできれないなら、それを分割するマークアップってのは
もとの意味にそってないと言う意味で単に間違ったマークアップだろう。
で、もともとそこに切れ目があったなら、divで「こういう構造だ」という意味づけを
してやることで切れ目を明示できる、という主張だろう。

>>272,273
無意味な構造ならdivが存在する意味がないわけで、構造と意味は明確に
分離されているものだとするのは無理があると思う。divに著者が何か任意の
意味を与える、なんてことは当然できないけど、構造を与えることによって
導かれる範囲に限った意味づけはあるわけだ。

「構造を与える」ということでは、ネストした構造にレベルの上下の意味を
持つことは導けないから、セクションの明示はできない。
しかし、仕様の例によれば、見出しとセクションをまとめてひとつの構造を付与
することで、関連付けをしたことになる。構造を付与することでそういう意味づけ
が導かれるわけだ。「構造を与える」という意味づけ、というのはそういう意味。

>>282
セクション構造に必要なのは、レベルの上下関係で表される、要素の木とは
また別の意味での構造だから、要素の木構造モデルを変えずに属性値で
セクションを作れる仕様を設計しても、その方針に違反しないと思う。
段落と見出しという相容れないものというよりは、グループを派生させたものが
セクションというものだと思うよ。要素の内容モデルは変わらないんじゃないか？
(まあ現実にはそんな仕様はないけど…と思ったけど、inputとかは似た感じだよな)

や、「いいい」 と 「ううう」 が、もともと別のセクションに属し、「あああ」 と 「ううう」 は同じセクションに属する、とした場合、

<h2>見出し</h2>
<p>あああ</p>
<h3>小見出し</h3>
<p>いいい</p>
<p>ううう</p>

も、ISO-HTML のように 「見出しで区切り、その間は同じセクション」 とした場合、おかしいことになるでしょ。

<h2>見出しA</h2>
<p>あああ</p>
<h3>小見出し</h3>
<p>いいい</p>
<h2>見出しAの続き</h2>
<p>ううう</p>

でも、「「あああ」 と 「ううう」 は同じセクションに属する」 とはマークアップ上はならないわけで、
やるなら

<section>
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<section>
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</section>
　　<p>ううう</p>
</section>

とするしかないんだけど、<section> は定義されていない。
でも、「同じセクションである」 は DIV ではできないけど、「同じグループである」 は DIV でできるとしたなら、それでもいいんでない？

ごめ、若干かぶった(´･ω･｀)

結局、一言で言えば DIV はセクションを"明示"はできないが"暗示"はできる、ってことでどうだろう。

>>294
> 今こういう議論をしている俺らはdivの位置で判断できるが、
> 全然知らない第三者は推測しかできないんじゃないか？
(もしdiv区切り可能ならば)仕様から判断できる。じゃなきゃ、仕様に書いてない
ローカルルールでHTMLの意味を変えることができる、という類の主張になっちゃう。

「divで見出しの範囲を区切れるという(HTMLにない)ルールで書いたよ」
という話だったら、「お前以外は判断できないじゃん」となるけど、
「仕様からdivで見出しの範囲を区切れるということが導かれるよ」
という話なら、(それが正しいなら、)仕様に従う限り判別できる。

>>295
> 既に議論のあったようにdivでセクション構造を表せないとすると、
> divを書くことによってセクションの切れ目が変わるという文書は正しくない。
その理屈はおかしい。セクションは単に切れ目を作ることでは実現できないから、
divが単に切れ目を作ることができても、依然としてdivはセクションを表せない。
つまり、divがセクションを表せなくとも、divは切れ目を表現しうる。

だから、問題とすべきことは、divが切れ目を表現しうるか。
たとえば、
<div>
　<h1>大見出し</h1><p>リードテキスト</p>
</div>
<div>
　<h2>小見出し</h2><p>h2セクション本文</p>
</div>
が仕様で許されているなら、「divはかならずしも切れ目を表現しない」ということになる。
つまり、divが出現しても切れ目かどうかはHTMLの意味づけでは判別できない、ということになる。

divで構造を与えることによって、見出しと対応するセクションが定まる。もしh1がdivの
外に及ぶとすると、すなわち見出しと対応するセクションが定められないということになる。
だから、見出しとセクションを対応づけられるということから、divは見出しの範囲を区切れる。

ここにいる連中に script を書かせたら
ぜ〜〜〜〜たいに ぐちゃぐちゃなものを書くはず (確信 ! )

お前ら、自分が何話してるかわからなくなってきてるだろｗ

参加できないからって僻むなよ

>>300 に同意。

そういえば、たまに >>300 のように

<div id="header"><h1>ページタイトル</h1></div>
<div id="main">
　　<div class="section">
　　　　<h2>見出し</h2>
　　　　〜いろいろ〜
　　</div>
</div>

って書き方の人みるけど、すごい違和感感じてたな。
自分的に H1 は BODY 直下。

>>302
たまに思うｗ

日本語が理解できない馬鹿ｗ

303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ
303 名前：Name_Not_Found[sage] 投稿日：2006/11/18(土) 15:36:21 ID:???
参加できないからって僻むなよ

>>297
その

<section>
　<h2>見出し</h2>
　<p>あああ</p>
　<section>
　　<h3>小見出し</h3>
　　<p>いいい</p>
　</section>
　<p>ううう</p>
</section>

をセクション要素を使わずに書くには、

<div>
　<h2>見出し</h2>
　　<h3>本論1</h3>
　　<p>あああ</p>
　<div>
　　<h3>ちょっとそれた話題</h3>
　　<p>いいい</p>
　</div>
　　<h3>本論2</h3>
　　<p>ううう</p>
</div>

じゃないのか、「続き」などという見出しにするから前半と後半が
アンバランスな構造になるんじゃないか。

>>306
おまえか。

>>300
> divで構造を与えることによって、見出しと対応するセクションが定まる。もしh1がdivの
> 外に及ぶとすると、すなわち見出しと対応するセクションが定められないということになる。
> だから、見出しとセクションを対応づけられるということから、divは見出しの範囲を区切れる。

それは結局、divでセクションを決めてるんじゃないのか。セクションはdiv以前に
存在し、divはそれを囲む事しか出来ないとするなら、divがあってもなくても
セクション構造が変わらないようになってなきゃならない。

「見出しとセクションを対応づけられる」というのも、「見出し」と「その
見出しによって暗示されているセクション」を対応づけて明示出来るという
だけの意味という解釈も成り立つので、その論理展開は無理があるよ。

>>305
例えば
http://www.mainichi-msn.co.jp/kurashi/women/shirokuro/news/20061031ddm013070105000c.html
で、読者からのメール部分に見出しをつけたとするやん。
そしたら、<section> ができるなら、

<section>
　　<h2>ふー、びっくりした</h2>
　　〜略〜
　　<p>〜今回は多数を占める「しなくていい」派からいってみよう。</p>
　　<section>
　　　　<h3>反対派のメール</h3>
　　　　<blockquote>いろいろ</blockquote>
　　</section>
　　<p>ふー、びっくりした。</p>
　　〜略〜
</section>
とかなったっていいんじゃね？

いちいち
　　<section>
　　　　<h3>本論2</h3>
　　　　<p>ふー、びっくりした。</p>
　　　　〜略〜
　　<section>
ってする方法しかないん？ ISO-HTML的にはそうするしかないっぽいけど・・・。

>>308
>>300じゃないけど、なんてか、「DIVでセクションの"範囲"を表した (グルーピングした)」 って感じなんだが、
それってそんなに無理で理解できないものなのかな。

>>300
特定の条件下でdivが階層構造を分断できると仕様に明示してあれば、当然判別はできるわな。
しかし言うまでも無くそんな記述は無い。
そもそも、そういった手段を想定していれば、そういう要素が用意されていると思う。

俺はdivは見出しの範囲を区切れるということにそもそも懐疑的、
というか、できないと思っているが、
仮にそれができるとして、
そのdivがどういう時に見出しの範囲を区切る機能を持つのか。
その判断基準は何だ？

UAがセクションをレンダリングしようとした時
（もしもの話、可能かとかどのようにするのかはこの際どうでもいい）、
そのdivがセクションなのかどうか、
見出しの範囲を区切っているのか、どう判断する？
少なくともdiv単独では判断できない。
divの中身とその前後、あるいは全体の構造から判断できるかもしれないが、
実際それで判断してレンダリングするとしたら、
その判断基準は仕様には書かれていないのだから、
それは仕様に無いことをUAが勝手にやってるということにならないか？

見出しの及ぶ範囲を終了できるのが見出しだけだとしたら、
かなり面倒だな。

グルーピングで及ぶ範囲の終了と出来なかったら、
全てのものに乱しつけにといけなくなるし。

>>311
だから、なんでdivがsectionかどうか判断するんだ？
セクションをセクションとしてレンダリングするのは<section></section>の場合だけだぞ。
<div></div>の場合はただのブロックとしてレンダリングされる以上の何物でもないでしょ。

まあUA的には機械的に判断すると、見出しを包括するブロックを範囲とするか、
次に見出しが来るまでを範囲とするかってとこだろうな。
要するに現状のUAの解釈そのままだろうけど。

見出し要素を書くだけで、何らかの区切りになっていると考えるのが普通だろう。

うむ、
「見出しの及ぶ範囲を終了できるのが見出しだけ」 とするなら、
極端な話、例えば (普通こんな書き方は誰もしないけど)

<h2>見出しB</h2>
<p>ほげほげ</p>
<div><div><div><div>
　　<p>へげへげ</p>
　　<div><h3>見出しC</h3><ul><li>ひげひげ</li></ul></div>
　　<p>ひげひげ</p>
</div></div></div></div>
<p>はげはげ</p>

こういう場合も、「はげはげ」 は h3 が示すセクションの中にあるってことだろ？
ちょっとないなあ・・・。

>>314
いつも論点がずれてるのは何なんだ？ ある意味天才。

>>315
いや、そういうdivの書き方自体が許されないという話をしているんだろ？

見出しを区切れるのが見出しだけなら、<section></section>なんか必要ない罠。
見出しの存在だけでsectionが決定されるからな。

>>313
セクションかどうかというのは、そのdivが見出しの範囲を区切る機能を持っているのかどうかということ。
そこを判別しなければ、そのページに存在する全てのdivが見出しの範囲を区切るか、その逆、ということになるだろ？

＞まあUA的には機械的に判断すると、見出しを包括するブロックを範囲とするか、
＞次に見出しが来るまでを範囲とするかってとこだろうな。

前者だとすると、見出しを包括するブロックは全て見出しの範囲を区切ることになるよな。
つまり見出しを含む限りdivをそれ以外の用途には使えなくなるということだ。
後者だとそもそもdivは見出しの範囲を区切ってない。

>>317
ああ、そうかｗ ごめんｗ

>>315 のような場合、「ひげひげ」 や 「はげはげ」 にも見出しをつけて、
そしたら 「へげへげ」 がアンバランスな構造なので、それにも見出しをつけなきゃいけない、って話になるんだっけ。
>>306 を見る限り。

>>318
XHTMLのsectionはhとセットです。

XHTML2.0ね

>>318
divしかないから見出しを区切れるのが見出しだけになるのであって、
sectionがあればsectionで区切れるから、いちいち全部に見出しを
付けなくて済むようになるという話じゃないのか？

>>323
それでもいちいち全部付けるのがすとりくた。

そもそも、見出しでレベルを表してるんだから、h2のあとh3があって、
h3が終わった後にまたh2の続きが出る場合も普通に考えられるよな。
直後に繋がる下位レベルの見出しは、
直前の上位見出しの示す内容を引き継いだり補足する場合が殆どだから、
上位レベルの見出しの影響は下位レベルの見出しまで包括するし。
h2の後のh3がh2と全く関係ないテーマの場合は、h2で再度見出しをつけるよね。
見出しの及ぶ範疇を区切れるとするならば、
それは同じかもしくは上位レベルの見出しってのが妥当な所だろう。

┏<h2></h2>
┃<p>h2の範疇</p>
┃┏<h3></h3>
┃┃<p>h3の範疇</p>
┃┗<p>h3の範疇</p>
┃┏<h3></h3>
┃┃<p>h3の範疇</p>
┃┗<p>h3の範疇</p>
┗<dl><dt>h2の範疇</dt><dd>h2の範疇</dd></dl>

だから、下位レベルの見出しがある場合に上位レベルの見出しは強制的に終了させられるだと、
文章をマークアップする時に絶対ひずみが出てくると思うんだが。
もしそうだとしたら、文書が存在したらマークアップが存在するっていう
根源的な前提が覆ってしまうし、マークアップの為の文書の改変が必要になるよな。

この場合のdlがh2の範疇にあるのは確かだとして、再度h2の見出しをつけるとすると、
今度は最初のh2の見出しの範疇から外れてしまい、話が続かなくなるんだよねぇ。

dlが前にあるべきだっただけのこと

で、続きだけど、まだsectionを使えない場合にどうするかと考えると、
divしか選択肢は無いんだよな。

否定派の人はh2の後にh3が来て、
再度同じh2の範疇の話が出る文書をマークアップする時は、一体どうするんだろう。
divで見出しの及ぶ範囲を名言できないとしたら、手詰まりになってしまうよね。
勿論、文書を改ざんするのは論外で。

そういう時にやりくりする為のdivでもあると思うんだけどねぇ。

>>326
文書の並び順変えちゃいかんでしょ。

ちょっと Strict な議論とは異なるんだけど、
DOM的に考えると DIV で区切ればそれで区切れてるんだよね。
Script とかでもそっちのが扱いやすいし。

>>326
「以上の点を踏まえて考えると・・・」 とかいうものの順序まで変えるのかよｗ

>>308
> divがあってもなくてもセクション構造が変わらないようになってなきゃならない。
変えちゃいかんのは元の文書におけるセクションの構造で、
divがあるのとないのとで(要素の)構造に違いがなかったら逆におかしいだろ。
(その構造が見出しを区切るか否かはまた別の話な。
　> divがあってもなくてもセクション構造が変わらないようになってなきゃならない。
がおかしいと言う話。)

divで構造を付加するときは、元の文書に沿った構造の付加をしなければならない。
つまり、divはもとの文書の構造を変える意味づけをしてはならない。(つーかそれは
divに限らず、元の文書の(構造を含めた)意味を変えるマークアップは単に間違い。)

> 「見出し」と「その見出しによって暗示されているセクション」を対応づけて
> 明示出来るというだけの意味という解釈も成り立つ
「定まる」ってのはもちろんHTML上で定まるということだぞ。その「暗示されている」
というのはあくまで元の文書においてで、HTML上では暗示されていない。
だから、あの論理はその解釈で成り立つ話だぞ。どう成り立たないんだか説明してくれ。

>>311
> そもそも、そういった手段を想定していれば、そういう要素が用意されていると思う。
そういった手段を用いる例示が、hnの項の見出しとセクションを関連付ける例である、
ということを言っている。既存の要素でできるならわざわざ別の要素を用意しないだろ？
(セクションを明示する意味づけはできないが、見出しとセクションの関連付けはできる。
　で、それは見出しの範囲を定めることと同義だってこと。つまり見出しの範囲を定めれる。)

あと、なんか勘違いしてるっぽいから念のため確認しておきたいんだが、見出しの範囲を定める、
というのは、divにセクションと一緒に突っ込んだ見出しは、そのdivの外とは対応をもたないよ、
ということであって、
<h1>見出し</h1>
<div>......</div>
<p>hogehoge<p>
とあるときに、h1の範囲がdivの前後でぶった切られ(てpにはかからない)という話じゃないからね。

>>327
なに？おかしな俺文書の俺補正には俺divを使うしかないという俺仕様話し？

>>330
そうそう。見る価値無いから他のスレ行くのがオススメ。

>>327
> 再度同じh2の範疇の話が出る文書をマークアップする時は、一体どうするんだろう。
俺は >>297 だと思ったんだが、>>306 らしいね。

>>306だと本論1と2でばっさり切られてしまってるから、元の文書と異なってしまってると思うな。
<h2>の持つ本来のセクションが<h3>でぶった切られてしまってるって事でしょ？
勝手にセクションをぶった切るのはマークアップとして正しくないと思うわ。

あれ、ごめん、否定派 (現状のHTMLでは見出しでしか区切れない派) の人って、

<section>
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<section>
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</section>
　　<p>ううう</p> (←見出しAのセクションの中)
</section>

はOKで

<div class="section">
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<div class="section">
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</div>
　　<p>ううう</p>
</div>

はダメなんだっけ？

>>332
>306は>297で言う
　> でも、「「あああ」 と 「ううう」 は同じセクションに属する」 とはマークアップ上はならないわけで、
という問題を抱えていると思う。

確かに>306では「あああ」も「ううう」も(h3を子要素とするdivも)同じh2に属しているんだが、
h3レベルでは異なるセクションに属している。

>297の元文書は、h3レベルでも同じセクションに属しているのを意図してるんだろ？
それなら>297で、
　> でも、「同じセクションである」 は DIV ではできないけど、「同じグループである」 は
　> DIV でできるとしたなら、それでもいいんでない？
という通りだと思う。

再度同じh2の範疇の話が出るときは「さっきのh2と関連ですよ」としてまた見出しを付ければ良い。
ブッタ切られるのがイヤならくっつけて書けば良い。

機械的にみると、再度同じ見出しをつけても同じとはわからない訳どころか、
同じレベルの別の見出しとしかわからない訳で。
それにくっつけるのは文書改ざん。

>>333
ISO-HTMLな流れだと思うねえ。
そこでぶった切ってるわけじゃないんだけど。
何ていうか、そこにセクションがあったら、それに全部見出しをつけないといけないんだろうな、って感じはする。
HTML では、セクションがあっても見出しをつけるかどうかは比較的自由というか。
その違いなのかも。

>>337
じゃあ文書がヘンなんだよ。

見出しを書いて本題を書いてプチ情報は後ろでええやんけｗｗｗ

>>338
ISO-HTMLでも、下位レベルの見出しは上位レベルの見出しを分断しないだろ？
これは見出し必須話とは関係ないと思う。

ISO-HTML好きにはスマンが、ぶっちゃけISO-HTMLはどうでもいいｗ

んー、例えば、
------------------------------
■なんとかの証明
あーだこーだ
□Aの場合
　　どーのこーの
□Bの場合
　　どーのこーの
以上のことから、なんとか証明された。
------------------------------
って文章をマークアップするとき、賛成派なら、
---------------------------------------
<h1>なんとかの証明</h1>
<p>あーだこーだ</p>
<section>
<h2>Aの場合</h2><p>どーのこーの</p></section>
<section><h2>Bの場合</h2><p>どーのこーの</p></section>
<p>以上のことから、なんとか証明された。</p>
---------------------------------------
こう書ける訳だが、ISO-HTMLなら、結論部分が 「〜の場合」 より下に来るので、
---------------------------------------
<h1>なんとかの証明</h1>
<h2>本論</h2>
<p>あーだこーだ</p>

<h3>Aの場合</h3><p>どーのこーの</p>
<h3>Bの場合</h3><p>どーのこーの</p>
<h2>結論</h2>
<p>以上のことから、なんとか証明された。</p>
---------------------------------------
と書かなきゃいけないわけじゃない？
見出し必須じゃんねこれ。

いらん改行入った、ごめ。

>>342
なんか見出しでしか区切れん派の人ってISO-HTMLな思考の流れだと思うんだｗ

>>343
WCAG1.0 14.1 (優先度１)

結局は >>295 だと思うんだが。例えば、

<p>この問題の解決方法は、
<ul>
<li>あああ</li>
<li>いいい</li>
<li>ううう</li>
</ul>
の3つがあり得ます。</p>

という構造の文書をマークアップしたい。しかし段落内にリストは書けない。
なら、文章を変えるとか、P要素を2つに分けるとかしか方法はないだろ？
実際に書きたい構造とは違うがマークアップ言語の制約で書けないんだから、
「その書き方は構造と違う」と言っても仕方がない。

section要素のないHTMLでも同じ事。本当に書きたいのはそんな構造じゃない。
そんなことは分かってる。しかし、その構造がマークアップで書けないんじゃ、
文章を変えたり、いちいち見出しを書くことになっても仕方ないじゃん。

どちらも、XHTML2.0になれば、その構造のまま書けるってことだよ。

その場合はspanで代用じゃね。

divは構造を提供できるって仕様なのに、見出しに関してのみ構造を提供できないってのもおかしいよな。

>>346
> どちらも、XHTML2.0になれば、その構造のまま書けるってことだよ。
HTML4系でも書けるよ。
ISO-HTMLではどうだか知らんが、ISO-HTML的思考の人は書けない。


実際に仕様の制約がある(>346)場合の対処については、
　a. それでも文書の意味を変えず、正しいマークアップをする。
　b. Strict的には邪道だけど、実際問題の解決のために文書を変える。
　c. 仕様違反の俺マークアップをして、俺解釈を要求する。
の三通りがある。
>346はbとcを挙げたけど、cは論外だと思うよ。

a.の方法としては、pは適切ではなく、他に文書の意味を表す適切な要素
がないんだから、汎用要素であるdivを使えばいい。文書の意味を変えず、
マークアップも正しい。(ただし、段落であるか段落でないかの意味づけは
なされない。)

>>343
あーごめん、そもそもISO-HTMLだとdivのなかに見出しを
突っ込めないことすら知らなかったんだよ。
見出しは全部body直下じゃないといけなくて、しかも見出し
によって暗黙にしか構造を示せないのね。

前者と後者のマークアップは意味が変わってるから、
ISO-HTMLで意味を変えずに書く場合は、一切見出し要素を
使わないことしか方法はないんじゃないか？

ISO-HTMLの仕様におけるセクションより広い意味のセクションを
使った文書だから、ISO-HTMLの仕様におけるセクションを使わずに、
汎用要素のdivとspanを使って構造だけでもマークアップするしかないと思う。
(そうしないなら元文書改変をするしかないが、Strict的じゃないし。
つまり、ISO-HTMLでマークアップするのに適さない文書ということだね。)

>>349
本当は段落なのにdivで書くって、どんだけdiv厨なんだよ。w

>>351
段落もまともに表現できない仕様に文句つけるのが筋だな。

XHTML2.0では改善されるんだっけ？

いつから段落すらを表現できなくなったのか

じゃあ>>346を正しいマークアップで表現してくれ。

すらを？

<p>この問題の解決方法は、 あああ、いいい、うううの3つがあり得ます。</p>
_______
<p>この問題の解決方法は、 以下のの3つがあり得ます。</p>

<ul>
<li>あああ</li>
<li>いいい</li>
<li>ううう</li>
</ul>
_________________
文章の中に含まれるの複数項目をリストにする必要はないんだよ。
もし、そうしたいなら文章の中に含まれる「複数有り得るかもしれないけど、今はたまたま単数の項目」を全部リストにしなさい。
結局こんなことしたいやつは、構造うんぬんじゃなくてリストの見栄えが欲しいだけだ。↓↓↓
<p>この問題の解決方法は、
<ul>
<li>あああ</li>
<li>いいい</li>
<li>ううう</li>
</ul>
の3つがあり得ます。</p>

<p>この問題の解決方法は、<br>
<span class="list">あああ</span><br>
<span class="list">いいい</span><br>
<span class="list">ううう</span><br>
の3つがあり得ます。</p>

おれなら無理やりこうする
とりあえず文章を勝手に変えるのはいかんだろ

>>357
おまえ最悪。

Strictバカとバカは交われないんだよ

今思ったのだが

このWWWで

最もStrictなサイトは

何処なんだろうか……

是非参考にしたい。

だが

何処なのか分からない……

【謎】

仕方なく >>356 にするしかない、ってひとは、
見出しのせいで一連の文章の構成を変えのもかまわない人な気がするね。
>>326 とか >>339 とかそうでしょ。

<p>この問題の解決方法は</p>
<ul />
<p>の3つがあり得ます。</p>
って書くのは、>>289 で言えば前者のタイプかな。

とすると、
<div class="paragraph">
　　この問題の解決方法は
　　<ul />
　　の3つがあり得ます。
</div>
って書くのが、<div class="section"> になるのかなあ・・・。

<div class="paragraph"> と書いたところで <p> じゃないので 「段落」 という意味にはならないんだが、
・できないからしょうがない
・XHTML2 がきたら、それに書き換える。
・<p>をつけたから段落になるわけではなく、元々あった段落を<p>でマークアップするだけ
というのは <div class="section"> の論理と似てる気はする。

<div class="paragraph"> はやったことない (だいたい意味が変わらない範囲で文章変えちゃう) んだけど、
多数のサイレントマジョリティを考慮すればアリかな。わらい。

>>360
>>86 でも聞いてたけど、でてこなかったなｗ
理想郷は存在しないんだな、とｵﾓﾀ

>>361
仕方なくじゃなく普通じゃないの？
文章の中に含まれる複数の項目はそのまま文章だから。


「来週の土曜日と日曜日の二日間イベント開催。
フォーク、ロックをはじめとして出演バンドがもりだくさん。フリーマーケット、大道芸、たこやき屋台もあるよ。
おとうさん、おかあさん、お友達もさそってみんなで行こうね！」


これリストいる？

>>361
魔法のｉらんどにカエレ！

>>363
とっさには思いつかないが、仕方なく な場合もあるんじゃね？
そうじゃなかったら XHTML2 でそういう案すらでてこなかったでしょ。
前スレで 「<p> には IMG や INPUT などの文章以外も含むことができる」 とか誰かが言ってたけど、ここではどうでもいいか。

>>363 の文章で言えば、いるかいらないかでいえば、リストにしてもしなくてもいいんじゃないの？ プログラムのあたりとか。
文化祭とかのアナウンスで、
「体育館では、12:00 から演劇部による○○、13:00から合唱部による○○、14:00から吹奏楽部による○○、（以下略） が行われます。」
とかも、リストにすればしてもいいと思う。

>>365
>「体育館では、12:00 から演劇部による○○、13:00から合唱部による○○、14:00から吹奏楽部による○○、（以下略） が行われます。」
>とかも、リストにすればしてもいいと思う。


だから、普通に含まれるならリスト要らないんだってｗｗｗばーか。
それに進行表ならタイムテーブルでTABLEだろうな。
構造じゃなくて見栄えで惑わされた構造もどきでモノ言ってんじゃねーよｗｗｗ

>>366 ｱﾎｽ

<p>この問題の解決方法は、<br>
あああ<br>
いいい<br>
ううう<br>
の3つがあり得ます。</p>

普通にこれでよくね？
見栄えの為の改行を嫌うやつもいるだろうけど、本来の文章は

>この問題の解決方法は、「あああ」「いいい」「ううう」の3つがあり得ます。

で、実際はリストではなく、あくまでリストっぽく見せたいだけでしかないから。

>>368
それはないなあｗ
何の解決にもなってないし、それだったら BR とかしないで書くし。

>>368
いや、図や表と同じように文章中にリストを使ってる文書をマークアップする、
ということなんだから違うでしょ。

「実際はリストではなく、あくまでリストっぽく見せたいだけでしかない」という
意図だったから直す、というのは元文書の段階でのミスを修正するという話で、
HTMLの話じゃない。リストを意図して書かれた文書のマークアップという問題
を避けただけで、元文書のミスじゃない場合の解決にはなってない。

「この文書の段落はHTML4が表現する段落ではない」なら、段落をdiv要素
(またはより適切な要素)とするのが正しい。

「この文書のリストはHTML4が表現するリストではない」なら、リストをインライン
要素としてマークアップする。(もしインライン要素としての構造を意図した文書で
ないなら、段落の定義がHTML4と違うから、この方法を選ぶのは間違い。)

で、インライン要素としてマークアップするには、リストの構造をそのままインライン
構造として表現するならば、次のようになる。
　<p>この問題の解決方法は、
　　<span>
　　　<span>あああ</span>
　　　<span>いいい</span>
　　　<span>ううう</span>
　　</span>
　の3つがあり得ます。</p>

>368は……、まず、見栄えのみが目的という点で仕様違反。
br要素(とかいろいろ)は、見栄えじゃなくて、文章構造関係の要素だと、
　http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html
の冒頭に書かれている。
しかし、「リストじゃなくて、単に改行をはさんだ文章で、その改行に意味がある」
と(本当に)意図していたなら、368となると思う。

すっごいバカがきますた

放っておけ

出掛けてたので亀レスになるが
>>327,328
＞再度同じh2の範疇の話が出る文書をマークアップする時は、一体どうするんだろう。
文意云々はまた別の話。マークアップ不可能になったとしたら、それは仕様上の欠陥。
実際、p内にリストを置けないなど、仕様には欠陥がある。（XHTML2.0では置けるようになるようだが）
>>329
＞そういった手段を用いる例示が、hnの項の見出しとセクションを関連付ける例である
その例は俺の言う"そういった手段"に該当しない。
＞なんか勘違いしてるっぽい
大丈夫、そんな勘違いはしていない。

で、XHTML2.0のsection要素が使えるようになれば、
それを用いて見出しによる階層構造を改変できる（>>334の上の例のような状態）
とする考えがあるようだが、それはちょっと疑問。
なぜかというと、
section要素はh要素とセットで使うことが想定されている。
それは、従来の見出し（h1~h6）による階層構造の形成から
よりXML的に階層構造を形成できるようにしたものだ。
つまり、section要素は、
"見出しとは別個で階層構造を定義し、場合によっては見出しの影響が及ぶ範囲を限定する"
ということを想定して作られたものではないということだ。
だから>>334の上の例のような使い方がそもそもOKなのか、
それを示す記述が無い以上、断定はできない。あやふや。グレーゾーン。
仕様上そう書くことはできたと（Validだと）しても、Strictなのかどうかは疑問。

>>373
現在の議論はh1〜h6であることが重要なのではなく、見出し要素である
ことが重要だと思うので、

<section>
<h>見出し</h>
<p>あああ</p>
<section>
<h>小見出し</h>
<p>いいい</p>
</section>
<p>ううう</p>
</section>

で考えればいいと思う。section要素の場合なら「ううう」に見出しが
ないのもあり得るだろうという意味。

>>374
いやそれだと最初のhが「ううう」の見出しになっている。
問題はそういう記述はOKなのかどうかということ。
ダメだって言ってるわけじゃないよ。

もしダメだとしたら、仕様に
「section要素 の中に一度 section要素 が現れたら、それ以降は section要素以外は置いてはいけない」
ってことになるよな？
<section> には <h> はひとつしか置けなかった(はず) だし。
まじでそんな仕様になると思う？

>>376
・section要素 の中に → section要素 の子要素に
・それ以降は → それ以降の子要素には
のがわかりいいか。

掘り返すけれど、

<p>この問題の解決方法は</p>
<ul />
<p>の3つがあり得ます。</p>

は普通にOKだよね
ulで区切られてるけど、pは「段落」というより「小節」だから

で、hとsection問題の場合、これと違って、
sectionの、hに対応するcontent（仮）の部分の定義が問題で、
このcontent（仮）の中の小節部位だから、上のように書けるってことだよね

>>375
「ううう」の前に見出しがないと書いたのは、
「ううう」の直前に小見出しがないの意味ね。

「上のように」 ってどれを指してるのん？

>>378
普通にダメだ。

>>373の安価間違えてた。>>327,328じゃなくて>>325,327

>>376
最初言っている意味が分からなかったが、なるほどな。
そう考えるとありだな。
まあXHTML2.0のsection要素については余談なんでこのへんで。

言い忘れてた。
>>327
＞まだsectionを使えない場合にどうするかと考えると、
＞divしか選択肢は無いんだよな。
divに見出しによる階層構造を崩す力がないなら、（その是非が議論のポイント）
「divしか選択肢は無い」んじゃなくて「選択肢は無い」。
XHTML2.0を待つしかない。

>>373
> 文意云々はまた別の話。
横からレスするが、そこは、「そういう文書は普通に存在する」ということを
言ってるんだと思う。「文書がおかしい」というちゃぶ台返しに対する否定だな。
別の話じゃなくて、根本となる前提の確認だろう。「その文書をどうやって
マークアップするか」以前の、「そういう文書をマークアップする必要はある」という。

> その例は俺の言う"そういった手段"に該当しない。
いや、理由つきで説明されてる話に「俺は違うと思う」だけ言われても話に
ならないんだが。

> つまり、section要素は、
> "見出しとは別個で階層構造を定義し、場合によっては見出しの影響が及ぶ範囲を限定する"
> ということを想定して作られたものではないということだ。
sectionはhn見出しじゃなくて、h見出しに対応するセクションを意味づけする要素
だということだな。これはその通りだろう。

>>382
> divに見出しによる階層構造を崩す力がないなら、（その是非が議論のポイント）
> 「divしか選択肢は無い」んじゃなくて「選択肢は無い」。
>327は
　> divで見出しの及ぶ範囲を名言できないとしたら、手詰まりになってしまうよね。
って言ってるからそんなことは先刻承知だと思うんだよ。実際に手詰まりになる
ISO-HTMLという例がすでにあるわけだし、そういうことが起こる可能性はある。
でも(>373や>382で)その可能性ばっかり言っても議論は進まないよね。

>>378
HTMLの仕様から分かる範囲では完全な段落の定義をしているわけではない
(そんなん無理があるだろう)から、HTMLでどうこうというより、HTML以前の
文書としてそれはパラグラフなの？って話になる。つまりスレ違い。
ただ、「日本語文章ではパラグラフという概念がなじまない」という話の場合には、
パラグラフを日本語で近いものとして意味づけを融通してしまっていいのか、という問題が(以下略)

talk:>>360
ttp://www.geocities.jp/kmath1107/
あそこはSSIが入るから、DOCTYPE宣言は書いていない。
とりあえず、SSIを除去して、先頭にHTML 4.01 Strict のDOCTYPE宣言が入っているものに書き換えてみてくれ。

>>383
「そういう文書は普通に存在する」からといって
必ずValidでStrictにマークアップできるわけじゃない。
ある文章が存在して、それをマークアップしなきゃいけない、
そのために本来不可能であることを可能であるとしてしまったら、
それはもうStrictではない。
だから議論すべきは純粋に可能か不可能かということであって、
特定の構造を持った文章をマークアップする必要がある
→だから何とかしてマークアップする手段を見つけなければならない（あるはずだ）
という前提は意味が無いし、Strictな考え方ではないということが言いたかった。

＞いや、理由つきで説明されてる話に「俺は違うと思う」だけ言われても話にならないんだが。
そりゃそうだな。
俺の言う"そういった手段"というのは見出し以外の要素で階層構造を形成すること。
あるいは見出しによる階層構造を二次的に改変すること。
しかし、「hnの項の見出しとセクションを関連付ける例」は
それが階層構造を定義しうるものなのかについては言及がない。
もししうるのであれば、そんな重要なことは言及されないはずがない。

でもってさ、
＞セクションを明示する意味づけはできないが、見出しとセクションの関連付けはできる。
＞で、それは見出しの範囲を定めることと同義だってこと
「見出しとセクションの関連付け」と言っている時点で、もともセクションはあるわけだろ？
つまりdivで囲わなくてもどこからどこまでが一つのセクションであるのか
明確に判断できなければならない。特に文意を読めないUAにとってね。
ならばどこで判断する？
section要素がない以上、次の同レベルの見出しの直前まで、という判断しかできないよな？
これはもうsection要素に相当する概念を準備しておかなかった仕様上の欠陥としかいいようがない。
それをdivで代替するということは、divに勝手にセクションを明示する意味づけをすることだ。
それはもうStrictから外れた妥協案だし、それが有効であるという保証は全くない。

>section要素がない以上、次の同レベルの見出しの直前まで、という判断しかできないよな？

だから、どこからどこまでが一つのセクションであるのか明確に判断できない場合には、
divで構造を付与するって事じゃないの？
無い場合は、次の見出しまでってだけだし。
明確に見出しに対になるセクションが定義されて無い場合は、
そういう事だと思うんだが。
それに、文意を読めないUAだって、構造なら簡単に読み取れるんだからさ。

section要素に相当する概念を準備しておかなかった仕様上の欠陥ってのは同意だが、
こういうときのためのdivなんじゃないのかね。
それは仕様として提供された、必ず起こりうるイレギュラーを吸収する為の緩衝材だと思うんだが。

<div class="section">
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<div class="section">
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</div>
　　<p>ううう</p>
</div>

見出しだけで定義され、他のいかなる要素でも定義できないとすると、
「あああ」は見出しＡ、「いいい」は小見出しの内容というのはまあいいとして、
本来「ううう」は小見出しの内容になる、ということになる
なのに、divに区切られてて、構造が一致しない
となると、「ううう」は暗默のh2、h3があるかもしれないと判断されるんじゃなかろうか？

>>385
> 「見出しとセクションの関連付け」と言っている時点で、もともセクションはあるわけだろ？

> つまりdivで囲わなくてもどこからどこまでが一つのセクションであるのか
> 明確に判断できなければならない。
それは>308の前段で言われてることだな。
それはおかしい、勘違いだということはすでに>329ですでに書いてある。

divで構造を明示することによって見出しと対応するセクションを明示できる
という話なのに、「divで明示しなくともセクションを明示できなきゃおかしい」
とはこれ如何に。構造を付加せずに元のセクションを明示できない場合
だからこそ、構造を付加するんだが。
もとあるセクションにそった構造と異なる構造になってしま(い、意図と異なる
範囲がグループだとUAに解釈される構造になってしま)うから、divで構造を
付加することで、著者の意図に反しない構造としてUAに解釈されるようにする、
という話だぞ。

> それが階層構造を定義しうるものなのかについては言及がない。
> もししうるのであれば、そんな重要なことは言及されないはずがない。
divではなにができるか、というと、構造を加えることができる一般機構だということと、
divで構造を加えることで、見出しと後続のセクションを関連付けできるということ、
これは仕様に明示されている。

で、後者ができるということは、(追加の定義を要することなく、)見出しの範囲を
区切ることができるということになるということだと>300最下段で説明してる。

暗黙と言うか、一行目の<div class="section">というブロックの中には、
h2という見出しと、それと対になるセクションがあり、
セクションだと思われるp div pという2つのブロックがそれと同レベルにあるって判断だな。

まともに文章かけないやつの文章に構造があわないからといって、divでどうにかしようとか、divで付加だの言われたくない。
いいかげんにしろよ。

またおまえか。

無題の文書を書きたい時は「無題」というタイトルを書くんだよ。
見出しも同様。セクションに適した見出しをいちいち付ければ良いだけの話し。
セクション区切りブロック区切り以前に論外なんだよ。そんなものを想定して仕様が不備だなんだのって寝言は。

私はHTML に title 要素を入れる必然性は無いと思っている。
だが、仕様で必須となっているからには入れるしかないのだろう。

見出しを入れたほうが良いと思ったら、見出しを入れればいいし、
見出しを入れようと思わないなら、見出しは入れなくていい。

>>388
元々の文章にある構造を表したいと思っても、マークアップ言語の制約によって
それが出来ない場合というのを考慮してないんじゃないのかな。

divが出来るのは「見出しに対応するセクション」の明示じゃないぞ。そんなこと
仕様書のどこにも書いてない。仕様書に書いてあるのは「見出し」と「見出しに
よるセクション」を結びつけるというだけだ。つまり、divを書かずに、

<h2>見出し</h2>
<p>あああ</p>
<h3>小見出し</h3>
<p>いいい</p>
<p>ううう</p>

こう書くと、

<h2>見出し</h2>
<s2>
<p>あああ</p>
<h3>小見出し</h3>
<s3>
<p>いいい</p>
<p>ううう</p>
</s3>
</s2>

このようなセクション構造が暗示される（s2,s3は暗示されるセクション）。
このh2とs2や、h3とs3などをdivでくくってセットに出来る。バラバラだった
ものをセットにするという意味の構造の付加だよ。それでこそグループ化要素。

>>392
本来あるべき1つの見出しの範囲を下位レベルの見出しでぶった切って、
2つの見出しに分けるってどうなのよ。
それこそ2つの見出しはUAには同一のものとは認識できないし、
本来有るべき見出しの構造を勝手に変えてる事になるんだが。
そっちの方が論外ｗだと思うがね。

ちょっとおかしかったな。

本来あるべき1つの見出しの及ぼす範疇を、
下位レベルの見出しがあるからという理由だけでぶった切って、
2つの見出しに分けるってどうなのよ。

に訂正。

>>395
> 元々の文章にある構造を表したいと思っても、マークアップ言語の制約によって
> それが出来ない場合というのを考慮してないんじゃないのかな。
ねえ、過去レスを片端から忘れていくの……？
　>383
　> >327は
　> 　> divで見出しの及ぶ範囲を名言できないとしたら、手詰まりになってしまうよね。
　> って言ってるからそんなことは先刻承知だと思うんだよ。実際に手詰まりになる
　> ISO-HTMLという例がすでにあるわけだし、そういうことが起こる可能性はある。
　> でも(>373や>382で)その可能性ばっかり言っても議論は進まないよね。

> divが出来るのは「見出しに対応するセクション」の明示じゃないぞ。そんなこと
> 仕様書のどこにも書いてない。仕様書に書いてあるのは「見出し」と「見出しに
> よるセクション」を結びつけるというだけだ。
なあ、レスを無視して自分の主張を根拠なしに繰り返すのはやめてくれないか？
なんでレスに対する反論じゃなくて、反論を無視した自分の主張を繰り返すんだ？
　> divではなにができるか、というと、構造を加えることができる一般機構だということと、
　> divで構造を加えることで、見出しと後続のセクションを関連付けできるということ、
　> これは仕様に明示されている。
　>
　> で、後者ができるということは、(追加の定義を要することなく、)見出しの範囲を
　> 区切ることができるということになるということだと>300最下段で説明してる。

>>392
ヘッダやフッタさえ表現できないISO-HTML思考でものを言われても困ります

仕様書に無い事を勝手に考えても、自分の考えの押し付け合いでしかない事が証明されたな。
どっちも合ってるっていえないんだから、議論は永遠に平行線。

>>397
本来あるべき1つの見出しの及ぼす範疇は、下位レベルの見出しでぶった切らないで続けて書けば良いだけの事。

またソース改ざんは〜って言わせたいのか？
そんなの論外だろ。

>>398
一番の問題点はここだ。

・「見出しによるセクション」と「見出し」とを結びつける（セットにして
　括る）事が出来る。
・「見出しによるセクション」の及ぶ範囲を制限する事が出来る。

これがイコールである事の証明だよ。すべての論点はそこにつきると思う。
この二つの文は全然違う事を言っていると思う。なぜこれがイコールだと
言えるんだ？

>>399
ヘッダフッタはなにのヘッダフッタだよ。
「表現」とは？

>>402
クソソースに合わせて仕様の不備を唱える方が論外だね。

>>388
>>395,403とかは俺じゃないよ。念のため。

観点を変えてみよう。
例えば文書構造から自動的にセクションを抽出し、
その階層構造を
ttp://www.atmarkit.co.jp/aig/01xml/domtree.gif
このようなDOMツリーを視覚的に表現できるシステムを想定する。
（この画像は要素や文字列なども含めているが、あくまでセクションレベルで抽出するシステム）
<h1>
<div id="level1">
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<div id="level2">
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</div>
　　<p>ううう</p>
</div>
このようなソースだった場合、（便宜上idをつけている）
level1のセクションからlevel2のセクションが枝として延びているツリーが作られるように見える。
だがそれは、divをセクションの範囲だと限定した場合だ。
システムが全てのdivをセクションの範囲だと認識してしまったら、
そうでないdivがあったときに誤ったツリーが描画されることになる。
つまり、そのdivがセクションの範囲を示しているのかそうでないのか、
自動的に、なおかつ100%確実に、判別可能でなければならない。

div単独で判別することは不可能だから、できるとしたら構造からだ。
もし構造から判別できるとするなら、どういう条件ならば可能なのか。
（続く）

（続き）
一、見出しを含んでいる
極端な話、<div><hn>見出し</hn></div>
こんなのもセクションになってしまうし、
<div><div><hn>見出し</hn><p></p></div></div>
これがセクションが二つあることになってしまうので不可。
二、直下に見出しとそれに続く一つ以上の要素を含む
<div>
<hn>見出し</hn>
<p></p>
<hn>見出し</hn>
<p></p>
</div>
これを一つのセクションとしてしまうので不可。
三、直下に一つの見出しとそれに続く一つ以上の要素を含む
俺の今の考えだと、この条件下でならそのdivがセクションの範囲を示していることを判別できる。
しかしこれも、今俺が思いつかないだけで、一つでもそれを不可とする例が出てきたら駄目になる。
つまり、構造からでは"100%確実に"判別可能とするのは無理がある。

でもってそもそも、構造から判別するという行為自体が正しいのかどうか。
(X)HTMLは意味を持った要素群によって構造が作られるのに、
要素の役割が構造によって定められるというのがそもそもおかしいとは思うが、
より分かりやすい問題として挙げられるのは、
>>149の「要素構造はシーケンシャルに解釈できなければならない」ということだ。
構造から判別するなら最低条件としても
「直下に見出しとそれに続く一つ以上の要素を含む」必要があるというのは上で示したが、
その条件に合致しているかはdivが出て来た時点では分からない。
divが閉じられるまで分からない。
つまりシーケンシャルに解釈できない。
だから、少なくともこの場合、構造から判別することはできない。
よって、divがセクションの範囲を示すことはできない。

>>403
ちがくね？

〜〜まずは前提〜〜
・文書における「見出しによるセクションの範囲」がどこまでであるかは、
文書の製作者の意図をくむしかなく、機械的には判断できない。

〜〜本題〜〜
機械的に判断される見出しの及ぶ範囲は、グルーピングされていない場合、
1)下位レベルの見出しが始まるまでである
2)同位、もしくは上位レベルが始まるまでである
3)上位、同位、下位の全てのレベルの見出しが始まる時である

また、見出しがdiv等のブロック要素でグルーピングされていた場合、
機械的に見て見出しの影響の及ぶ範囲は
1)見出しを包括するdiv等のブロックの範囲内に限定される
2)ブロックを無視し、前質問の回答1)〜3)のどれかの見出しの前までに及ぶ
　（言い換えると、そんなdivの使い方は出来ない）

HTML的に考えて見出しの影響の及ぶ範囲は
1)見出しを包括するdiv等のブロックの範囲内に限定されなくてはならない
2)ブロックを無視し、前質問の回答1)〜3)のどれかの見出しの前までに及ばなくてはならない
　（言い換えると、そんなdivの使い方は出来ない）

こんな感じじゃね？

>>406
また勘違いしてる。

>だがそれは、divをセクションの範囲だと限定した場合だ。
これは、人間が見た場合セクションの範囲に合わせてdivでグルーピングしたとわかるかもしれないが、
機械的にはただのdivでしかなく、セクションであるかどうか判断するどころか
セクションと判断すること自体がありえない。
ただのブロックとしてレンダリングされる。

前提が間違ってる上に仮定が成り立つ訳無いよ。
これこないだも指摘したじゃん。

>>408
前提が違う。

>>409
divをセクションの範囲だと限定した場合というのはあくまで、
"人間が"このシステムを構築するにあたってそう設定した場合、という話だぞ。

＞機械的にはただのdivでしかなく、セクションであるかどうか判断するどころか
＞セクションと判断すること自体がありえない。
それはどんな場合においてもそうということか？

>>400
仕様に書いてある、と主張していた側は
英文の解釈のおかしいところを指摘されたら、それを訂正した主張をしました。
仕様に書いてない、と主張していた側は、
英文の解釈のおかしいところを指摘されたら、消えてしまいました。

>>403
一番の問題点はお前が人のレスを読まないことだよ。
>300最下段を嫁

>>406,407
　> 観点を変えてみよう。
って言ってる通り、それは別の話。(divがセクションを十分に意味づけすることは
できない、というのは既出だし。)
セクションのレベルの上下関係を示せない、ということを示したに過ぎないのに、
　> よって、divがセクションの範囲を示すことはできない。
言っている点が論理の飛躍。飛躍である理由は以下の通り。

セクション部分を区切れないならば、セクションの意味づけができないことが導かれるが、
セクションの意味づけができないことから、セクション部分を区切れないことは導けない。
(論理的な意味での十分条件と必要条件の違いね。)
これも>300に書いてあることだよ……

見出しとセクションを関連付けられるというのは、元文書のセクション部分と
見出し部分を関連付けられるということ。このうち、見出しはHTMLの見出しとして
意味づけできるが、セクションはHTMLのセクション(XHTML2や、ISO-HTMLのとかな)
としては意味づけできない。
　・見出し部分は、見出しとしてマークアップできる
　・セクション部分は、セクションとしてマークアップはできない
　・元文書の見出し部分とセクション部分を関連付けることはできる
見出し部分とセクション部分は関連付けられているが、HTMLとしては、それが
セクションであることは意味づけされない。

>>411
>それはどんな場合においてもそうということか？
そう。
divはただのdiv以外のなにものでもないし、
この話題におけるその影響力は構造付与まで。
divをsectionと勝手に置き換えて考えるのは最早divの範疇じゃないし、
sectionと意味付けするのであればsectionでマークアップされなければならない。

そりゃそうだろ。
「見出しの直後にグルーピングとして使われているdiv要素は擬似section要素」
とかいう解釈をするUAがあるとしたらIE以上の独自要素としか言えん。

そういえば、

<div>
　<h2></h2>
　<p></p>
</div>
<div>
　<h3></h3>
　<p></p>
</div>

こういうマークアップってダメ？
ダメならdivはh2のセクションの範疇を切り崩してることになるけど。

>>412
観点を変えただけで別の話になっちゃうの？
普段多角的に物事を考えることしないの？
まあいいや。

「divで構造を与えることによって、見出しと対応するセクションが定まる」
というのはdivがセクションを定義しているということにならないのか？
「セクションの意味づけができない」のであれば
</div>が現れたところでセクションが終了することにはならんよな。
それは"区切れない"ということではないのか？

つーか、そもそも言葉の定義とかに食い違いが生じてんのかな。
"区切る"のレベルが違う気がする。

>>412
区切るとは自在に範囲を設定できるという意味で言ってるんだよな？
だったら逆だろ。

セクションを区切れなくてもセクションの意味付けはできる。
例えば、見出しから次の見出しの前までの間を囲む事しかできないような
section要素を導入したとする。つまり、section要素で囲む前から囲む範囲は
決まっている。こういう要素なら、勝手に範囲を区切れないがセクションの
意味づけはできる。

逆に、セクションの意味づけができないということは、勝手にセクションの
範囲を設定したりできないということだ。そいつが区切ることでその範囲が
セクションになってしまうんだから、セクションにならないという前提条件に
矛盾するからな。

>>416
> 「divで構造を与えることによって、見出しと対応するセクションが定まる」
> というのはdivがセクションを定義しているということにならないのか？
だからそのセクションというのは、元文書のセクション部分のことだって。
見出しと対応する任意の部分が定まる、と言い換えても問題ない(、はず)。

> 「セクションの意味づけができない」のであれば
> </div>が現れたところでセクションが終了することにはならんよな。
(元文書におけるセクション部分が終了するということなら、)なりうる。
どういうことかというと、セクションであるとは限らないが、見出しと
結び付けられたなにかはそこで区切れる、ということだ。
で、そのなにかというのを、元文書の文脈でセクションである部分
を例にして考えてきたわけだ。

>>417
> 区切るとは自在に範囲を設定できるという意味で言ってるんだよな？
いや違うよ。ISO-HTML式だろうが範囲を区切られるならセクションを
意味づけできる可能性はある、というのは417の中段の説明の通り。

逆にHTML4では、見出しと、元文書のセクション部分との対応付けができるため、
任意に範囲を区切れるが、セクション部分のレベルの上下関係は明示できない。
(見出しにはレベルがついてるけど、これは単に重要さのレベルであって、
見出しに対応したレベルのセクション階層構造をなす、とは言ってないと思う。)

そもそもHTML4にしても、見出しと、見出しに後続しない場所から始まるセクションとの
関連付けはできないから、自在というほどでもないような。そんな必要性は薄かろうけど。

> そいつが区切ることでその範囲がセクションになってしまう
セクションの範囲を設定する"専用の"要素がないから、セクションに限定した意味づけはされないんだよ。
divは汎用要素だから、セクション部分の範囲を区切ることはできるが、セクションでないものの
範囲も区切れる。だから、見出しと対応付けて区切っても、見出しと対応付けたものが区切れただけで、
それがセクションだとは意味づけされない。それでも、見出しと対応づけたものはそこで区切れる。

例えば

<div>
　　<h2></h2>
　　<p></p>
　　<h2></h2>
　　<p></p>
</div>

こういうマークアップするのはアリだと思うんだけど、
<div class="section">
とは書きたくないな、って感じだな。
<div class="sections">
ならアリだと思う。

>>418
＞だからそのセクションというのは、元文書のセクション部分のことだって。
元文書のセクションならdivで構造を与えるまでもなく定まっているだろ。
それは人間なら文意から読み取れる。
しかしUAは文意を解せないから、機械的に判断できるようにするためにマークアップするんだろ？
マークアップが成されてそれが解釈される時、文意に寄らず、
要素とその配置だけで構造が判断されなければならない。
その段階での解釈の話をしているんだから、
「divで構造を与えることによって、見出しと対応する（元文書の）セクションが定まる」
なんて定義に何の意味もないだろ。

＞(元文書におけるセクション部分が終了するということなら、)なりうる。
同様に元文書の話なんかしていない。
UAは元文書がどうであったかは知りようがないし、それを理解もできない。
<div id="level1">
　　<h2>見出しA</h2>
　　<p>あああ</p>
　　<div id="level2">
　　　　<h3>小見出し</h3>
　　　　<p>いいい</p>
　　</div>
　　<p>ううう</p>
</div>
これがどう解釈されるかだ。
level2の</div>が出てきた時にそこでセクションが終わると解釈できないのだから、
「ううう」がh3の配下から脱してh2に属すると解釈されることはない。
俺はそういう意味で区切れないと言っていた。
やっぱり食い違っていたね。

>>420
> 元文書のセクションならdivで構造を与えるまでもなく定まっているだろ。
を見て思ったんだが、
　> 見出しと対応する任意の部分が定まる、と言い換えても問題ない(、はず)。
この文を読んでないだろ。
　> その段階での解釈の話をしているんだから、
　> 「divで構造を与えることによって、見出しと対応する（元文書の）セクションが定まる」
　> なんて定義に何の意味もないだろ。
と言ってるが、そこは対応付けのことを言ってるんだぞ、意味が理解できてるか？

> level2の</div>が出てきた時にそこでセクションが終わると解釈できないのだから、
> 「ううう」がh3の配下から脱してh2に属すると解釈されることはない。
「元文書でいうセクション」にあたる、「HTMLでいう見出しと関連付けられた部分」が
終了する、という話だってば。
divで括られた見出しと後続の部分は関連付けられる、と仕様にある。
関連付けられた部分は、divによって与えられた構造の通りに区切られている。

区切りの意味の相違が問題なんじゃなくて、
セクションの区切りじゃない=見出しと関連付けられたものの区切りじゃない、
という思い込みがあるんじゃないか？ それがあるから、
　> level2の</div>が出てきた時にそこでセクションが終わると解釈できないのだから、
　> 「ううう」がh3の配下から脱してh2に属すると解釈されることはない。
の前行と後行がつながってしまうんだろう。

divで区切ればdiv区切りになるよ。でもdiv区切りはたんにdiv区切りだよ。sectionの区切りとは関係ないよ。
なんでそんなこともわからない初心者が紛れ込んでるの？

セクションの区切りではなくて、見出しの区切りの話ですよ。

>>421
だからさ、マークアップがどう解釈されるかという話をしているのに、
どうして元文書の話が出てくるんだ。

＞「元文書でいうセクション」にあたる、「HTMLでいう見出しと関連付けられた部分」が
＞終了する、という話だってば。
</div>で「HTMLでいう見出しと関連付けられた部分」が終了するのは別にいいんだよ。
その是非について俺は一切論じていないし、現時点で興味もない。
「HTMLでいう見出しと関連付けられた部分の終了」が
マークアップレベルでのセクションの終了にはならない、
ということに異論はないよな？

＞level2の</div>が出てきた時にそこでセクションが終わると解釈できないのだから、
＞「ううう」がh3の配下から脱してh2に属すると解釈されることはない。
この前後が繋がらない理由を説明してくれ。

見出しの区切りはhn開始タグと終了タグですよ。なにぬかしてやがるんですか。

>>424
> どうして元文書の話が出てくるんだ。
元文書をマークアップする話だからです。で、元文書のどの部分を
マークアップしてるのか言及してるからです。

> </div>で「HTMLでいう見出しと関連付けられた部分」が終了するのは別にいいんだよ。
> その是非について俺は一切論じていないし、現時点で興味もない。
……見出しの範囲を区切るかどうかの話なのに、何を言ってるんだ？
わけがわからん。

> 「HTMLでいう見出しと関連付けられた部分の終了」が
> マークアップレベルでのセクションの終了にはならない、
これはその通り。
「セクションである」という意味づけがそもそもできないと何度も既出だよね。
まさかいまさら「divでセクションは作れない」という話をしてるんじゃないだろうな。

> この前後が繋がらない理由を説明してくれ。
セクションが終わると意味づけできないことが、見出しの範囲が区切れないことに
なる理由を説明してくれ。理由もなく
　> セクションの区切りじゃない=見出しと関連付けられたものの区切りじゃない、
　> という思い込みがあるんじゃないか？
ということだとしか思えん。

見出しのかかる範囲の区切りの話でした。アホなことぬかしてすみません。

　大見出し
　小見出し
　文章１
　文章２
こういう文書があって、文章２は大見出しの示す内容には含まれているが
小見出しの示す内容からは外れているとする。
小見出しと文章１をHTML以外で視覚的に関連付けるとしたら
　大見出し
　＿＿＿＿
　|小見出し
　|文章１
　￣￣￣￣
　文章２
例えばこんな感じになるよな。
それをHTMLの場合divでやる。
<h1>大見出し</h1>
<div>
<h2>小見出し</h2>
<p>文章１</p>
</div>
<p>文章２</p>
結果こうなる。ここまではいい。とりあえず現時点ではいいとしよう。
俺が問題としているのは、結果的にこうなったマークアップが、
UAなどに100%確実に意図した通りに解釈されうるか、ということだ。
</div>が出てきたところで小見出しの示す内容が終わっていると解釈されうるか。
解釈されえないことは既に説明した。
そう解釈されえないのだから、文章２の内容は小見出しの示す内容に含まれる、と解釈されてしまう。

>>424
</div>で「HTMLでいう見出しと関連付けられた(と著者がかってに思い込んでいる)部分」(のdiv)が終了するんだよ。
だから
著者がかってに区切ったのdivが終了する。

見出しと関連付けられた部分は終了しない。
セクションは終了しない。

>>428
> </div>が出てきたところで小見出しの示す内容が終わっていると解釈されうるか。
> 解釈されえないことは既に説明した。
反論されたまま説明できてないだろ。反論されずにスルーされているところが
あるなら明示してくれ。

>>428

428:385 :2006/11/20(月) 07:21:13 ID:??? [sage]
　大見出し
　小見出し
　文章１
　文章２
こういう文書があって、文章２は大見出しの示す内容には含まれているが
小見出しの示す内容からは外れているとする。

↑
その時点でStrictじゃない。

>>430
じゃあ言い方変えて説明しなおすよ。
<h1>大見出し</h1>
<div>
<h2>小見出し</h2>
<p>文章１</p>
</div>
<p>文章２</p>
これが実際どう解釈されるかを見る。
h1が出てくる。これが大見出しであると解釈される。
divが出てくる。この時点でこれが何を意味しているか、どんな役割を持っているかわからない。
汎用ブロックが始まったとだけ解釈される。
h2が出てくる。これが小見出しであると解釈される。
pが出てくる。段落であり、h2の示す内容であると解釈される。
divが終わる。汎用ブロックが終わったとだけ解釈される。
pが出てくる。段落であり、h2の示す内容であると解釈される。

戻って解釈しなおせるのならh2が出てpが出てdivが閉じられた時点でdivの開始に戻って
解釈しなおせるんだが、それはできない。

>>428
まだHTML化されていないただの文章なのに、HTML的にStrictではないとはどういうことだ？
StrictというのをHTMLを超えた意味で言っているのなら、それは国語の話。
　大見出し
　小見出し
　文章１
　文章２
という文章が成り立たない、
あるいは国語的にStrictではないからHTMLに的Strictにマークアップはできない、ということなら、
そもそも上の例のようなdivの使い方を想定する必要はないから、この議論もここで終了になる。
それならそれで全然構わない。

安価間違えた。>>428→>>431

>>432
> 戻って解釈しなおせるのならh2が出てpが出てdivが閉じられた時点でdivの開始に戻って
そんな必要ないじゃん。見出しの対応する範囲が区切られるなら。

> divが終わる。汎用ブロックが終わったとだけ解釈される。
汎用ブロックが終わったことにより、この構造によって見出しと関連付けられていた
範囲から外れたと解釈できる。見出しの対応する範囲が区切られるなら。

で、言い方変えようとか別の観点とかじゃなくてさ、ちゃんと反論されたことは
説明しようぜ。問題は見出しの対応する範囲が区切られるか否か。>424で
　> </div>で「HTMLでいう見出しと関連付けられた部分」が終了するのは別にいいんだよ。
　> その是非について俺は一切論じていないし、現時点で興味もない。
と言っていたが、「興味ない」じゃ説明したことにはならんよ。
見出しと関連付けられた部分が終了するのに、見出しと関連付けられた部分が続くわけはない。
そちらはそれを意図的に無視しつづけてるわけだけど、説明する気はある？

>>434
見出しの対応する範囲を区切っているとUAは解釈できない、と言っている。

区切っているような書き方をしてもUAが解釈できない（実装の話じゃないよ）なら
区切れないのと同じこと、意味がない。人間にしか判断ができない。

＞反論されたことは説明しようぜ
すまんが俺が説明し切れていない反論の部分を示してくれるか。

>>432
あのね。
h1のレベルにある部おっく要素は、機械的に見て

<h2>
<div></div>
<p></p>

だけしかないの。
なんでそこでdiv役割なんか解釈する必要があるのよ。
見当違いな解釈をUAにさせるな。

>>432
世の中のテキスト全部をそのままマークアップ出来ると思うのが間違いHTMLにするならタグ以外にテキストを追加(例えば見出し)しなければならない事もある。
そんな順番を無視した手書きメモみたいなモノはpreだ。

h2のレベルにあるブロック要素は、機械的に見て

だった。まあ意図ぐらいは読み取れると思うけど訂正。

<body>
　<div class="last_update">2009年01月01日更新</div>
　<section>
　　<h>第6回 Strict語講座 投稿コメントコーナー</h>
　　<p>
　　　ここでは、皆さんからいただいた投稿コメントを紹介します。
　　</p>
　　<section>
　　　<div class="post_date">2009年01月01日</div>
　　　<h>...</h>
　　　<p>...</p>
　　　<h>...</h>
　　　<p>...</p>
　　　<address href="mailto:[email protected]">Xさん</address>
　　</section>
　　<section>
　　　<div class="post_date">2008年10月17日</div>
　　　<h>...</h>
　　　<p>...</p>
　　　<h>...</h>
　　　<p>...</p>
　　　<address href="mailto:[email protected]">Yさん</address>
　　</section>
　　<p>
　　　今回もコメントをたくさんいただきました。みなさんありがとう！
　　　追加のコメントはまだまだ受け付けていますので、どしどしご投稿ください。
　　</p>
　　<address href="mailto:[email protected]">講師</address>
　</section>
　<address href="mailto:[email protected]">サイト管理者</address>
</body>

>>432
その理論だとよぉー、
例えば address 要素なんかよぉー、だいたいページの最下部に書いてると思うんだけどよぉー、

<h1 />
<div>
　　<h2 />
　　略
　　　　　　　<div><h6 /></div>
　　略
</div>
<address />

この address は h6 の示すセクションの内容ってことになるよなぁー？
つまり address が ｈ6 の示すセクションより外に起きたい場合は、必ず文書の上部に来なければならないわけだよなぁー？
それっておかしくねぇかぁー？

>>439
section に h って複数置けたっけ?

>>440
h2で下における。

>>442 の言ってることがわかんねぇー。
<h2>著作者情報</h2>
<address>なんとかかんとか</address>
って書いてるのかー？

>>436,438
その<p></p>は<p>文章１</p>のことを言ってんだよな
じゃあ<p>文章２</p>がh1レベルにあると解釈される理由を説明してくれ。

>>437
俺が勝手にそういう文書を想定したんじゃないんだけどな。
例えば>>295とかも想定してるし。
文章１とか文章２とかは例としてそうしてるだけで、
例えば文章２がフッタでもいい。
>>51なんかはそういうものを想定して発言しているよな。

>>440
それに関しては過去散々議論されている。
とりあえず過去ログ読んできなよ。

>>435
　> 見出しの対応する範囲を区切っているとUAは解釈できない、と言っている。
の根拠はいつになったら出てくるんだ……
本当に、ただ言い張ってるだけじゃん。

>>388ですでに
　> で、後者ができるということは、(追加の定義を要することなく、)見出しの範囲を
　> 区切ることができるということになるということだと>300最下段で説明してる。
と書いているわけだが、385は>406で
　> 観点を変えてみよう。
と言いつつ別の話に変えて、これに対する説明を避けた。>>424でも、
　> </div>で「HTMLでいう見出しと関連付けられた部分」が終了するのは別にいいんだよ。
　> その是非について俺は一切論じていないし、現時点で興味もない。
と、避けているよな。
にもかかわらず、>428では
　> </div>が出てきたところで小見出しの示す内容が終わっていると解釈されうるか。
　> 解釈されえないことは既に説明した。
と前言に反することを(しかも説明したなどと)言ってる。

>>441
XHTML2.0では
http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.
の通り、できる。

>>446
Oh(´･ω･｀)thx

その場合の

<h>This is a top level heading</h>
<p>..hogehoge..</p>
<section>
　　<p>..fugafuga..</p>
　　<h>This is a second-level heading</h>
　　<p>..piyopiyo..</p>
　　<h>This is another second-level heading</h>
　　<p>..gorogoro..</p>
</section>

の fugafuga のところの見出し派の解釈が気になるな。

>>445
根拠は>>432の最初で説明した。

「divで構造を加えることで、見出しと後続のセクションを関連付けできるということ」は
「見出しの範囲を区切ること」にはならないことは説明したはずだが。
区切っているように見えてもUAが解釈し得ない限り機能しない、結果区切れていない、と。

>>444
> 過去ログ
>>1 にあるとこに繋がりません。orz
簡単に言ってくれると有難いんだけど、だめかな？

>>432 の前半の解釈のされかたは、「見出しで区切る場合」 の解釈のしかただから、何の効果もないよ。

あと、前から UA UA 言ってるけど、どこの UA の仕様なの？ そう解釈してるのって。

>>449
簡単に言える量じゃない…
にくちゃんねるとかで探して。
ざっと見36、37辺り。

>>452
読んでくる。 ｻﾝｸｽ ﾉｼ

>>451
だから実装の話じゃないってば。
人間のように、文意等からの判断や、
シーケンシャルでない判断の仕方等をしない／できないものが
どのように解釈するのか、それを明らかにしたいから
その分かりやすい顕著な例として持ち出している。

>>448
> 区切っているように見えてもUAが解釈し得ない限り機能しない
仕様から区切ってることになると分かる(って言ってる)んだから、
仕様を守る限りUAも解釈できるに決まってるだろ。
仕様上どう解釈されるかを話せばいいんだよ。

そもそも、「区切っているように見え」るだけだと主張する根拠を
求められているということが理解できてないようだ。

>432　説明　> 解釈しなおせるんだが、それはできない。
├>434　反論　> 範囲から外れたと解釈できる。見出しの対応する範囲が区切られるなら。
│└>435　反論(根拠の提示なし) > 見出しの対応する範囲を区切っているとUAは解釈できない、と言っている。
│　└>445　根拠の提示を求める > の根拠はいつになったら出てくるんだ……
│　　└>448　根拠の提示 > 根拠は>>432の最初で説明した。
「>432はおかしい」という主張(反論)への反論の根拠が>432そのもの、
ということの何がおかしいか分かるか？

>>454
> シーケンシャルでない判断の仕方等をしない
そういや、>149の
　> SGML/XMLの仕様に、要素構造はシーケンシャルに解釈できなければならない
って、どこに書いてあるか知ってる？

>>455
どうでもいいけど、おまいまとめ方うまいな。

>>444
すまん。他のやつとごっちゃになってた。
最初のh1レベルであってて、訂正が勘違い。

<div id="h1-block">
　<h1>大見出し</h1>
　<div id="h2-block">
　　<h2>小見出し</h2>
　　<p id="level2-p">文章１</p>
　</div>
　<p id="level1-p">文章２</p>
</div>

とした場合、h1-blockからわかるのは
<h1><div id="h2-block"><p id="level1-p">
っていう3つのブロックがあるってだけでしょ。
その下位構造のh2があるか無いかを判断してh2-blockがsectionかどうかを判断する必要も無いし、
sectionの範囲をdivでグルーピングしたとしても、それ以前にセクションの意味なんかdivにはない。
シーケンシャルに判断できないって言いたいんだろうけど、
シーケンシャルに判断しないから、わかるのは
<h1><div id="h2-block"><p id="level1-p">
ってブロックがあるってだけじゃん。
勝手に下位構造まで行ってから遡って、意味付けが出来る訳も無いセクションの
意味付けを判断できないって理由で否定するって根本的に考え方がおかしい。

>>458
シーケンシャルに *しか* 判断できない、だと思うんだけど。

>>385 の言いたいこともわかるんだよな。
例えば >>428 で言ってるけど、CSS なしで

<h1>大見出し</h1>
<div>
　　<h2>小見出し</h2>
　　<p>文章１</p>
</div>
<p>文章２</p>

こう書いて、IE とかで開いたら、普通 「文章２」 は 「小見出し」 の文章だと思ってしまう。
これは誰だってそうだろう。
文章が全くいままでの流れと違っていたり、CSS や <hr>等を使えば、また別だろうけども。

でも
<p>文章２</p>
じゃなしに、
<div id="footer"> リンクとか address とか </div>
とかがあっても、小見出しの内容だとは誰も思わないと思うんだよね。

だから、
a: 『「小見出し」 の内容は 「文章２」 に及ぶ』 か、
b: 『「小見出し」 の内容は 「文章２」 に及ばないが、そう誤解はされうる』 か、
どっちかなんじゃないかな、と思う。
違ってる？

>>455
ちょっと待て。
見出しの対応する範囲が区切れるという主張に対する反証が>>432だ。
それをそっちが反証するのに、見出しの対応する範囲が区切られることを前提として持ち出した。
そこがまずおかしいだろ。
>>435は反論したのではなく、反論がおかしいことを指摘した。

＞仕様を守る限りUAも解釈できるに決まってるだろ。
できないと>>432で説明した。
その反証はできていない。

ああ、すごいもやもやするがもう出掛けないとならん。
後日またこの議論蒸し返し…たらさすがにウザいか…

その辺はblockquateと同じようにすればいいだけじゃない？
margin取ったりしてわかるようにすればいいし。
UAがやってくれると申し分ないんだけど。

>>459
ケアレスミスだったｗ
補足サンクス。

>>461
いってらｗ

>>461
> それをそっちが反証するのに、見出しの対応する範囲が区切られることを前提として持ち出した。
俺がしたのは「異なる前提によって異なる結論が出る」という反論だぞ？
>>432の
　> 戻って解釈しなおせるのならh2が出てpが出てdivが閉じられた時点でdivの開始に戻って
　> 解釈しなおせるんだが、それはできない。
というのが、「見出しの対応する範囲が区切れない」ということを前提にしないと成り立たない、
ということを、その前提の逆を仮定すると別の結論がでることによって示した。

「異なる前提によって異なる結論が出る」という反論は、どちらが正しいと前提しなくとも
なりたつ反論だということは分かるか？ お前はここで、自分の前提の根拠をしめして、
「異なる前提」なんてものは成立しないということを示さなきゃならなかったんだよ。
にもかかわらず、前提をもって根拠としたのがおかしい。

「見出しの対応する範囲が区切れない」ということが>432の前提になってるんだよ。
「見出しの対応する範囲が区切れない」という前提の根拠を「見出しの対応する範囲が
区切れない」ことが前提の主張に求めることがおかしいことは分かるか？

で、俺は俺の「異なる前提」について示した根拠を何度もアンカー付きで示してるんだが、
それに対する反論は頑なに避けられている。 この状態で、お前の主張は反論になってるか？

>>463
いや、
　> シーケンシャルに判断しないから、わかるのは
以降の説明、全部意味が通らなくなってるよ。

>>466
ん？じゃあ多分ものすごい誤読してる。
正しく書き直すとこうだから。

シーケンシャルに判断できないって言いたいんだろうけど、
シーケンシャルにしか判断しないから、わかるのは
<h1><div id="h2-block"><p id="level1-p">
ってブロックがあるってだけじゃん。

>>462
うん、だから 「CSSなしで」 って書いたんだけどね。

だから、そうした場合誤解されてしまう、から問題なのかなと。
section要素が来たところで、 margin とらなきゃ誤解されてしまうのは防げないしねえ。
まあ、section要素が来たら、 margin とらないブラウザが悪い、ともいえるんだが。

divで 「区切ってる」 といっても実際 「区別がつかない」 から、
>>460 で 「小見出し」 とは別に、明確に区切るために、「文章２」 の前に見出しを置けとか、
「文章２」 を 「小見出し」 の上に置けとか、そういう解決の仕方を今までされたのかなとー。

>>467
あーそうか、シーケンシャルの意味の取り方によるね。

子要素を全部見て、そのあとに孫要素を全部見て、ということ、
先頭の子、先頭の子の子、子の子の子、というように見ていく、ということか。
木の幅優先探索と深さ優先探索の違いだと思う。

>>469
>先頭の子、先頭の子の子、子の子の子、というように見ていく

ああ確かにそういう見方もありだね。
ただ、その場合でも結局順番に見たとしても
<h1><div id="h2-block"><p id="level1-p">
っていうブロックがあるよって事しかわからないんじゃないかな。

例えば、<div id="h2-block">がレンダリングされる場合でも、
<div id="h1-block">というブロックをレンダリングし、中にh1という見出しが有ったのでレンダリング、
その下位にはなにもないので探し、次に<div id="h2-block">というブロックが見つかった。
この時点でもう既に<div id="h2-block">はただのブロックでしかなく、
それがレンダリングされた後、内包するものが無いかチェック
〜以下略〜
下位までチェックが終わったのでまた上位階層に戻り<div id="h1-block">の中を引き続きチェック、
って感じで。

そのブロック要素が意味付けされてる場合はUAもそう読み取れるけど、
divの場合は次の子要素を見る前にただのdivとして処理されるから。

>>468
HTML上で区別が付いてても、
意味づけを反映しない見た目になんていくらでもなりうるよね。
そもそもブラウザ(やブラウザのモード)によってスタイルシートは
かなり違うよね。見た目(や音声)の出力を行わないUAもあるよね。

つまるところ、その話をHTMLの問題とするのはお門違いじゃないかな。

>>460
> どっちかなんじゃないかな、と思う。
> 違ってる？
違ってると思うよ。表示実装で解決する話だし、現実に解決できるよね。
逆に、それすら解決できない悲惨な環境を持ち出して385みたいな
主張をするとしたら異常だとは思わないかな。(385がそういう発想である
とは言ってないので念のため。)
　> >>385 の言いたいこともわかるんだよな。
というのが分からないんだよ。「CSS なしで」というのは、「ivの構造を区別
できない表示スタイルをわざわざ使用して」ということになるよね。それで
区別できないのは当たり前だから、HTMLとしてなにが問題なんだか
分からない。
CSS等の表示実装(デフォルトスタイルとか)の問題なら、HTMLに文句を
つける意味がわからない。

>>471
やー、「＞区別できないのは当たり前」 だから、「誤解されうる」 って言ってるわけじゃないか。
もちろん誤解されるのは HTML じゃなくて、ブラウザ側の問題なわけなんだがね。

それが HTML として何が問題なのかは、うちは見出し唯一派じゃないし、わからんｗ
HTMLとかDOMの構造的には区切れてるしなあ。

でも 「誤解される場合もある」、とは思うわけだ。
例えば <q> とか書いても、IE では引用なのかどうかわからんし、
table の caption とか書いても、表の見出しだとはわからんかもしれんし、誤解されうる。
でもHTML的には問題ないわけだしな。

まあそんな。

頭の程度の問題

おまいらいつ寝てるんだ。w

俺も区切れない派だが、>>432 とは違って、「</div>が終了しても見出しの
効果は続く」なんて思わない。そもそもそんなHTML自体が不正であると思う。

<p>あああ<span><em>いいい</span>ううう</em></p>

というマークアップで、「ううう」部分にem要素の効果が及ぶか及ばないか。

・spanはただの汎用要素だからemを区切る力はないよ。
・spanが閉じたんだからemも閉じたと解釈されるよ。

そんな議論をして何か意味があるか？　これは不正なHTMLだ。前者の解釈を
するUAもあれば後者の解釈をするUAもあるだろう。不正なHTMLの解釈は
不定だと仕様書にある通り。

今回の話も同じだよ。ちょうどおまいらのように、そこでセクションが
区切られると解釈をするUAもあれば、区切られないと解釈をするUAもある。
それは上記spanとemの例のように、不正なHTMLだから解釈がぶれるんだ。

次の見出しの前までをdivで囲めば両陣営の解釈は一致するんだろ？
それが正しいHTMLだよ。

>>472
初心者以下派

385とかホントにいつ寝てんだろうなｗ
案外出かけたんじゃなくて、眠くなったんで寝たんじゃないか？ｗ

>>474
> 次の見出しの前までをdivで囲めば両陣営の解釈は一致するんだろ？
> それが正しいHTMLだよ。

まあそりゃそうなんだがね。
実際 >>343 のような文章とか構造もあるからねえ・・・。

>>477
結論を述べて理由を述べれば良いだけのことではないか。
WCAGではそうだ。

>>478
先に元の文書ありきな場合、自分の裁量で文書を改変するわけにもいかん場合もあるべよー。
どうでもよかったらそうするけどなー。

>>479
>>343のように見出しを付けるしかないよ。
または、日常の口語や散文詩と同じ扱いだわ。そのまま引用しなければならない状況なら、そんな扱い。

>>480
うん、まあ実際問題そう書くしかないような気はするわねぇ。
見出しの範囲とかは別の話として。

>>474
そんな明確に不正なHTMLじゃなくて、
そもそも不正ではないかもしれないって可能性は考えないん？
構造を明確に付与して区切る事が出来たら、それは不正ではないんだから。

おまいら平日の昼間から元気だな。

>>482
構造を明確に付与して区切る事が出来ない。

つーか、スレッド36 とか見てるけど、そのときも
＞セクションdivは、それを取っ払っても意味が通じなければならない。
とか言ってるな。
ちょっとﾜﾛﾀｗ

>>484
それは証明できてないのに、なんでそれを根拠に否定できるの？

>>485
だとしたら構造を提供すること自体が出来ないよねぇ。

>>486
出来ないんだよ。

仕様書に構造の提供って書いてなかったっけ？

>>488
divはdivの構造を提供します。でもそれだけです。

矛盾してるねぇｗ

例えば、こんなのを考える。

<div><p>あああ</p><p>いいい</p></div>

divが「いいい」の範囲を勝手に縮める事は出来ない（範囲はp要素で決まってる）
が、この二つの要素をセットにするという構造は提供出来る。これと同じ。

divを取り除いた時に存在する区切りはdivでは変えられない。そのような書き方
自体が不正。既に区切られているもの同士をグループ化出来るだけ。そしてこれも
「グループ化」という立派な構造の付加。

それは元々グループ化されている2つのパラグラフに、divで構造を与えただけでしょ。
グループ化を解除すると言う事はその2つの関係がなくなるという事で、
本来の意味合い自体が変わってしまう。
それはいかんでしょ。

>>492
> 元々グループ化されている
HTMLではされていない。元文書ではされている。
> グループ化を解除すると言う事はその2つの関係がなくなるという事で、
HTML上でのそのグループ関係がなくなる。
> 本来の意味合い自体が変わってしまう。
そのように、元文書と異なる構造となるなら、
divを取り除くというマークアップが間違いで、
divでグループ化されたマークアップが正しい。

>>478
> WCAGではそうだ。
ガイドライン14.1には、
　> 結論を述べて理由を述べれば良いだけのことではないか。
なんて文書構造や文章展開まで押し付けるようなことは書いてないぞ。

単に事実を伝えること以外なにも考えなくていい文書ならば
　> 結論を述べて理由を述べれば良いだけ
で、それを崩す理由なんてめったにないだろうけど、世の中のHTML文書全部を
単に事実を伝えること以外なにも考えなくていい文書にしなきゃいけないなんて
仕様規定もガイドラインもないだろ。

>>494
だから「ガイドライン」なわけだが。
>世の中のHTML文書全部を
単に事実を伝えること以外なにも考えなくていい文書にしなきゃいけないなんて
>仕様規定もガイドラインもないだろ。


事実が伝わらない文書を仕様を独自解釈してでも書くのがStrictとな？

>>495
> だから「ガイドライン」なわけだが。
じゃあ「WCAGではそうだ。」なんて嘘つくなよ。みっともない。

> 事実が伝わらない文書を仕様を独自解釈してでも書くのがStrictとな？
誰もそんなこと言ってないよ？

>>496
結論を述べて理由を書く。ななめ読みでもだいたいの意味がわかるようにうんぬんと書いてあるがな。
ぴったり一致しないと気がすまないんかえ？divの解釈もセクションの解釈も独自解釈なのに。
不思議ちゃんね。

どんだけわめいてもDIVはDIVでしかないよ。

>>497
> 結論を述べて理由を書く。ななめ読みでもだいたいの意味がわかるようにうんぬんと書いてあるがな。
なんでどこに書いてあるか明示しないんだろうな。
それはWCAG10-CORE-TECHSの5.1の2か？

http://www.w3.org/TR/WCAG10-CORE-TECHS/#writing-style
　> State the topic of the sentence or paragraph at the beginning of the sentence or paragraph
　> (this is called "front-loading"). This will help both people who are skimming visually,
　> but also people who use speech synthesizers.
http://www.zspc.com/documents/wcag10-tech/core-techniques/index.html#writing-style
　> 文章や段落の主題は、最初に書くようにする（これは、フロント・ローディングと呼ばれている）。
　> そのようにしておくことで、文章を目で拾い読みする人に限らず、スピーチ・シンセサイザを
　> 利用している人にも役立つようになる。
要点を最初に書くようにしろ、と言ってるが、>343のような構成を禁止してる
わけじゃないじゃん。343の「あーだこーだ」の部分にその節の概要をいれる
ようにしろという話で、それでなお後半に詳細が書いてあっても、十分
このガイドラインを満たしている。

そういや、5.1の1には、
　> Use informative headings so that users can scan a page quickly
　> for information rather than reading it in detail.
　> 見出しは、ユーザーが情報を得るために文章を詳しく読まなくても、
　> ざっと見ただけですぐにわかるような有益なものにする。
って書いてあるよね。
いらんとこに「無題」とか見出しをつけて冗長な構成にするなんて、この
ガイドラインに思いっきり反するのに、これはなんでスルーしたんだろう。

> divの解釈もセクションの解釈も独自解釈なのに。
根拠を明示せずに反論しづらくしたあげく、こうして独自解釈がばれた
人間の言うことじゃないよな。勝ち負けを競ってんじゃないんだから、
「独自解釈だ」と喚くだけじゃ意味がないぞ。

XHTML1.1にtarget属性を追加したいんだが、よくわからなくなった。
W3Cがtargetモジュールというのをわざわざ作ってくれてるんで、それを取り込もうと、
こんな風にDOCTYPEを書いてみたんだが

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % xhtml-target-1.mod PUBLIC "-//W3C//ELEMENTS XHTML Target 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-target-1.mod">
%xhtml-target-1.mod;
]>
これだと、W3Cのバリデータで、targetなんて属性が無いとか怒られる…。
直接<!ATTLIST a target とか書けばいいんだが、せっかく用意されてる
モジュールがあるんでこれを使って書きたいんだが…なんか間違ってる？

>>499
>禁止してるわけじゃないじゃん。
だからガイドラインというのだよ。
>「無題」というタイトルも見出しも有り得るし、構造の為に書くのと書かないのでは違うのだよ。タグもテキストも必要なら書く。

頑張って良い高校に入学してくれたまえ。

>>501
> だからガイドラインというのだよ。
ガイドラインでも、mustなことはmustといってますよ。
　> [Priority 1]
　> A Web content developer must satisfy this checkpoint.
ガイドラインだから禁止や強制をしてないんじゃなくて、
ガイドライン *ですら* 禁止されてないんですよ。

> 「無題」というタイトルも見出しも有り得る
ありうるかどうかの話はしてないですよ。
見出しがない箇所なら「無題」という見出しをつけなければいけない、
というその人独自のルールは、ガイドラインに反するということですよ。

>>500
http://xrea-memo.raccy.org/ad_xhtml.xhtml#label-11
が参考になると思う

けど、なんか不安になること書いてあるんだよなあ。

>>502
見出しを付けないと、見出しが付いてない文書になります。それだけのこと。
察しろと言うのか？

>>504
　> 見出しを付けないと、見出しが付いてない文書になります。それだけのこと。
というのは同意。見出しの付いてない文書というのは、見出しのついてない
ブロックのある文書だよね。それがあることそれ自体はダメなわけじゃないよね。

見出しが不足していたりしたら、それは問題になる。その一方で、無駄に多ければ
いいわけでもない。「あらゆる部分に見出しは必要」なんてことは、少なくとも
ガイドラインには書いてないんだよ。
ましてや、「必ず見出しをつける」ということのためだけに、見出しをつけると
かえって内容のかさが増えたりして分かりづらくなる場合にもつけろ、というのは
分かりやすい文書にとっしては論外だよね。

>>392はああいうけど、ガイドラインによると、論外なのは392だ、という話。


> 察しろと言うのか？
察しなきゃ分かりづらいようなら、ちゃんと見出しをつけなきゃダメだよね。
察する必要があるほど複雑な内容に見出しをつけないのはガイドライン違反。
察するまでもないほど簡単な内容に、冗長な見出しをつけることもガイドライン違反。

だから、察する必要はないようにしなきゃいけないけど、
(表示上ではなく)文書として冗長で邪魔になってしまうような場合に
見出しをおくのもダメ。
さじ加減が大切だね。臨機応変。

>>503
thx,参考にしてみた。でもこの通りにやっても結局バリデータ通らないなぁ…。
そもそもxhtml-pre/postfw-redeclモジュールってなんなんだ？DTDにはプレースホルダだとか書いてあるけど…謎。

けど他に、モジュールを追加する方法を説明してるページとか、全然見つからん。
XHTML1.1はモジュール化されてるので容易に組み合わせてどうこうできますとか、謳い文句で終わってるところばっかりだ…具体的なやり方が何処にもないよ。
DTDから書けってことなのか？

なんか否定派でひとり必死な人がいるっぽいなぁ。
否定派で頑張って議論で書き込みしてるのは、殆どが一人で他の否定派は様子見してるだろｗ
その人に反論しまくってる肯定派も2人ぐらいで。

>>505
簡単な内容であってもセクションがぶった切られるとかなんとかホザくなら付けるべき。数文字のテキストの内容であってもだ。また必ずしもテキストとも限らない。

>>506
W3Cのバリデータを試してみた。

http://xrea-memo.raccy.org/sample/xhtml11-t-m.xhtml
このURLを指定してチェックすると通る。
けど、これのソースをコピペしてチェックしても通らない。

なんかオプションが違ったりするのかな。

392が頑張りまくってるな。
ダメな方向にｗ
不必要に喧嘩売りまくり口調だからﾊﾞﾚﾊﾞﾚ。

>>509
たしかに、鯖にあげたのを渡すとOKになる。MIMEとかそのへんかな…？
あとはこれが正しい方法なのか、よくわからないのが問題だなあ。
この方法じゃ２つ以上のモジュールを突っ込みたい時、できなさそうだしなあ、frames+target、とか。
一体何が正しい方法なのか…。

確かに、どんだけわめいてもDIVはDIVでしかないのと同様に、
どんだけわめいてもDQNはDQNでしかないなｗ 3行以上書けないし。

個人的には、静観していたであろう
必死な人とシーケンシャルな人以外の反対論が聞きたかった。

馬鹿ばっか

まとめサイトってどこかに移転したんですか?

要素、属性がdeprecatedになった理由をまとめたトコって誰か知らない?
iframeがXHTMLのstrictに無い理由を知りたいのだが。
# 個人的には、1つの文章の内容が複数のファイルに分かれてしまうからと判断しているが、合ってる?

iframeってHTML4.01 Strictにもなかったような…

objectでやれってことじゃないの

>>518
単純に『機能が被ってるから』なのか、>>516に書いたようなハッキリとした理由が有るからなのかが知りたい。
後者なら(文法的にはよくても)構造的にはアウトって事になりそうで。
# pの中にobject作って、それの子としてブロック要素を書いた場合、
# 文法的に正しくても構造的にアヤシイみたいに。

frame自体がStrictに入ってないから、iframeも入ってないってことなんじゃ
ないのか？

>>519
>>516のような理由なら、object要素からiframeと同様の機能は外されているはずだろ？

>>521
そうか、成程。納得した。サンクス。
>>517が気になって今まで調べてたが、確かにW3CのHTML4.01のトコにそのものズバリな例が載ってた……
 ttp://www.w3.org/TR/html4/struct/objects.html#embedded-documents
XHTMLの方しか見て無かったよorz

そろそろここの成果(マークアップの定石とか)をまとめないか?

言いだしっぺの法則

見本テンプレートみたいなのはほしいよね

あのな、Strictな文書ってのは中身ありきなんだよ。
何をマークアップするのかもわからん状況を想定して見本テンプレートなんて作れるか。

アドレスの場合とかみたいに、いくらでも見本テンプレートの状況もあるんじゃ？ｗ

>>523
このスレで何か話がまとまったことってあったか？

話がまとまった後にも、主張の否定された奴が喚いてることはよくある。

見本を書くときに話を拾い読みするだろうけど、どの意見が否定されていて、
どの意見が成り立っているか、なんて迷うことはそんなにないだろ。
「どの主張も成り立ちうる」ということはあんまりなかっただろうし。

で、フォームのマークアップはどうするの？
よくある右上のサイト内検索は？

さしあたってこのスレとかマークアップしたらよくね？

そんなの永遠に終わらないぜ

例えばパンくずリストを書きたいと思ったとき、
こういうマークアップにすべきっていう例がすぐに調べれるといいな。

どういうマークアップにすべきかの議論はここに任せて、
一般にはその結果だけ使えればいいし。

>>533
そういう「Strict的HTML Tips」みたいなのがあると便利だろうけど、
単一の「その結果」が出るのにいつまでかかることやら。

>>533
思考停止奨励してどうする。

>>533
細かい前提条件や例外がついて、しかも前提条件(というか状況)の
違いによって数通りの例が載るだろうから、例から結果だけぶっこ抜いて
使えばすむ、というほど単純にはならんと思う。

>>534
べつに単一じゃなくてよくね？
というか、あとからテンプレに反する主張が成立してテンプレ修正するはめに
なるのは仕方ないと思う。そういうこともある。

よしわかった！
とりあえず>>536は原形らしきものを作ってくれ。

>>537
536が「どうしてもテンプレを作りたい側の人」には見えんのだが。自分でやれ。

ここ見てると、政治なりなんなりで統一見解だすのが難しいってわかるな。

他人のふんどしで相撲をとろうとするやつがいるからな。

他人のふんどしにさんざケチつけといて、じゃあどんなのがいいの？、って聞いたら、自分で考えろ、だって。

文句垂れたいだけでないなら、自分の発言のレス番号と不服の理由を簡潔に述べなさいな。

マホカンタ

ID欲しいわ。

作るならwikiのほうがいいかな?

過去ログもみれるようにするにはどうしたらいいんだろう…。

StrictorならMediaWikiですよね。

保守

結局正しいマークアップができる人間はこの世にいないっていうことか。

1つの決まり事に流派がいてどうする

その論理でいくと正しいキリスト教徒もイスラム教徒もこの世に存在しないな

質問スレで、<link rev="made">の href属性に
メアドではなくメールフォームのURLを書いても良いかって話題があるんだが、
Strict的はどうなんでしょ？
http://pc8.2ch.net/test/read.cgi/hp/1161537564/586-

議論されたことある？

>>550
made は登録された linktype じゃないからそもそも、非strict
profile で自分で定義するなら、何でも書けばいいと思うけど。

>>551
うお、非strict だったのか
あまりにも普通にみんな書いてる慣例だったから勘違いしてたｗ
そうなら確かにprofileを適当に書いて俺仕様で何でも書けるわな

で？profile定義どうすりゃいいの？

profileの定義方法は特に決まってない。好きに書け。
例えばテキストで、

head 要素の profile 属性でこのリソースを参照させることによって、
link 要素の rev 属性に指定されたキーワード made は作成者を表し、
href 属性にメールアドレスまたはメールフォームなどの
作成者と連絡取るための手段を得る URI を記述することで、
その文書と作成者とを関連付けします。

みたいな文章を保存してサーバーに上げてprofileでそのURLを示せばいい。
文字通り適当だが。

profile属性全然つかえねぇ…。
profile属性自体否定派がいてもよさそうなもんだ。

まあ適当でもせめてHTMLで書いてDL要素で定義したいとは思うが。
<dl id="profile">
<dt id="keyword">keyword</dt>
<dd>説明</dd>
</dl>

まじめに作るんならこんな感じだな。
ttp://www.kanzaki.com/ns/metaprof
ttp://mayah.jp/meta/linkprofile.html

DL厨きたる!

どっかの勧告か暗黙かで、<dl id="profile"> で定義するのが一般的。

ソーシャルブックマークっていうの作ってるんですけど
<ul class="posts">
　　<li class="post">
　　　　タイトル
　　　　説明
　　　　タグ(複数)
　　　　投稿者
　　　　投稿日時
　　</li>
</ul>

みたいにしようと思ってるんですけどli.postの中は
dlにしたほうがいいでしょうか？

普通にdlだろ。

>>560
こんなに早く答えていただけるとは
ありがとうございました

>>549
宗教と仕様を一緒にするな

<body>
<div class="header"><h1>サイト名</h1></div>
</body>

みたいなのってstrict的にはダメですか？

>>563
わかめ

>>563
<div>を使う理由は？

>>565
CSSセレクターを書き易くするためだけに決まってるだろ。分かりきったことを聞いてんじゃねえよ。

普通にh1だけでいいだろ
どうしても必要ならh1にclassつけたら?

レイアウト目的くさいからh1だけでどうにかならんか工夫してみ

レイアウトというか背景とかボーダーの装飾も含めてじゃね？
h1だけじゃどうにもならん気が。

>>563 >>566
背景もボーダーもそれぞれひとつならばｈ1だけで済むだろ。
とにかく提示されたソースだけでは、h1にまとめろとしか言えない。
どういう意図してdivを使ったのか理由が重要。

他に<div class="header">はh1だけしか含まないが、
<div class="menu"><div class="body">等が存在し、
統一感を持たせるという意味での使用ならありかもしれない。

h1は見出しであって、headerとするのはよくない気がする。

>>570
ブラウザでの見た目がheaderなのだろう。
要は、慣例的で意味など考えていない、いわば物理的二重マークアップだな。
CSS作者たちのその慣例を変えた方が良いという提案なら、代替案を出した方が好ましいかもな。

>>570
「h1はサイト名(あるいは一連の文書を代表するタイトル)で、
その文書固有の見出しはh2から」という形式なら、
そのサイト名がheaderに含まれてもいいような気はする。

全ページにサイト名があるサイトってのは結構あるから、
現実にもそういう形式は存在すると思う。
(その形式をheaderというclass属性値のdivで括るマークアップ
で表現するのは適切かどうか、というのはまた別の話だけど。)

上の方の議論で DIV で構成を区切れる、って考え方だと、>>563 はありえないね。

デザインのためなら、<h1><span id="site-title">サイト名</span></h1> とかのがまだありな気がする。
「デザインのため」 って考えるのがそもそも strict 的ではないのは置いておいて・・。

>>573
そのspanこそねーよ。

>>573よりはまだ>>563のほうが許せる。

掲示板の書き込み情報を
<ol>
<li>
　<dl>
　　<dt>タイトル</dt>
　　<dd>strict-html スレッド</dd>
　　<dt>名前</dt>
　　<dd>名無しさん</dd>
　　<dt>内容</dt>
　　<dd>うんこうんこうんこうんこ</dd>

　　<dt>カテゴリ</dt>
　　<dd>りんご</dd>
　　<dd>みかん</dd>
　　<dd>ぶどう</dd>
　<dl>
</li>
</ol>
のようにしてるのですが
カテゴリの部分は上の方法か
　　<dt>カテゴリ</dt>
　　<dd><ul>
　　<li>りんご</li>
　　<li>みかん</li>
　　<li>ぶどう</li>
　　</ul></dd>
これかどっちのほうがいいとおもいます？

>>576
意味的には後述のほう。
ただ入れ子がな…。

<dt>カテゴリ</dt>
<dd>
<div>りんご</div>
<div>みかん</div>
<div>ぶどう</div>
</dd>

こうするとか？

上でよくね？
わざわざリストにして可読性を犠牲にする必要もない気がする。

上は違う。よくあるけど違う。

<dl>
<dd>
<dd>
<dd>

ってやっぱ違うよな
ADPでやってるけど

複数のカテゴリに同時に所属してるんだから、
上であってると思うよ。

>>576
そもそもolっているか？
dlだけでよくね？

りんごのカテゴリに所属しています。
みかんのカテゴリに所属しています。
ぶどうのカテゴリに所属しています。


りんご、みかん、ぶどうのカテゴリに所属しています。


どっちだ？

>>584
下だと、「りんご、みかん、ぶどう」というひとまとまりのカテゴリに属してる
ような意味合いになって不適切だと思う。

「りんご、ばなな、ぶどう」とは別の所属カテゴリ、というわけじゃなくて、
りんごカテゴリに所属、ぶどうカテゴリに所属、というのは共通で、
ばななカテゴリとみかんカテゴリの所属については異なる、ということだから、
上の方がより正確に意味を表していると思う。

このカテゴリってのは全てのレスに必要なの?
そうでなければ外に追い出した方がいいかと。

>>584
どっちかというと上です

>>586
最近流行りのタグ的なものです

何で上がダメなんだ？って疑問。

上でも下でも良いと思うけどな
解釈の問題でしょｗ

http://johnbokma.com/

このサイトすげーよくね？
strictスレ的に

<span class="separator">|</span>

クモの画像が気色悪いです＞＜

<h1>を変なdivで囲ってないってだけでかなり高得点だよ

>>591
ｗ

<div class="logo"><img></div>
ｗｗｗｗｗ

>>591
>>592
>>594
>>595
君らは一体どんだけやれば満足するつもりだ！

もしstrictな記述が解らないなら、
XHTMLで提供して、ユーザサイドでXSLTしてもらって、
問題の少ないStrictな文書を提供して、かつ向こう側で変換してるから、
最初から問題のある文書を提供するよりましかな？

>>596
別に今のままでいいんじゃね？
「strictスレ的に」というと思い切りアウトだけど

せっかく>>590を参考にしようと思ったのに
また別のを探すことにする

参考にすればいいじゃん。コピーするわけじゃないんなら。

参考にはならんぎらす

spanて使ったらだめなの？

>>602
どのspanのことを言ってるのかは知らんが、
>>592は装飾だろ。spanどころか | すらだめじゃん。話にならない。

>>603
あ>>592じゃなくて>>591だった

>>601
参考にする、というのは何から何までなぞることではない。
ここで受けた指摘を元にして、それを踏まえてよいところは参考にすればよい。

>>576
明確に関連付けをしたいなら、迷わず<table>を使えよ。
ここの常駐者の大半は単なる知識不足で<table>を避けてるだけだから。

たまに表れるよね、こういうバカ。

別に避けてる訳じゃなくてtableはtable本来の使い方をするだけ
別にtableに限った事じゃないし

IEの馬鹿のせいでセパレータをどうするかって問題があるんだよな。
画像だとCSSや画像がOFFの場合に見づらいし。

ﾊｧ?

そもそも、情報を見せるためのレイアウトじゃないの？
問題があるのにそのレイアウトに拘る必要無いんじゃない？

ttp://osamurai.flnet.org/weblog/2006/12/05
ttp://pi8027.flnet.org/other/diary/2006/11#d_30_02

これって如何なんだろうか……

>http://pi8027.flnet.org/other/diary/2006/11 を XHTML1.1 としてチェックしました。
>21個のエラーがありました。このHTMLは 69点です。タグが 27種類 249組使われています。文字コードは UTF-8 のようです。

人のフリ見て我がフリ直せ

>>613
お前馬鹿か？
エラーの内容までちゃんと読め。

これはそれで採点するものなのかい？

>>613
AHLはXHTML 1.1 plus MathML 2.0 plus SVG 1.1未対応。
多分取り敢えずAHLで採点してエラーが出たから言ったんだろうな。この文書を書いた人側には何の問題も無いよ。

と云うか、612は文章の内容について言っているんじゃないの？

kanzakiのパクリみたいなデザインだな。

要は、

<dl>
<dt>用語</dt>
<dd><p>……。</p>
<p>……。</p></dd>
</dl>

は「用語に1つの意味があり、それを2段落に渡って説明」を意味し、

<dl>
<dt>用語</dt>
<dd>……。</dd>
<dd>……。</dd>
</dl>

は「用語に2つの意味がある」を意味する。全然違う構造なんだから
ごっちゃにするなという話だろ。当たり前の話じゃないか？
むしろ、

<dl>
<dt>用語</dt>
<dd><ul><li>……</li>
<li>……</li></ul></dd>
</dl>

をどう考えるかの方が問題だと思うが。

>>617
kanzakiもw3cのパクリだけどな。

>>614
ほらよ。

3: line 52: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 53: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 54: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 55: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 56: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 57: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 58: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 59: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 60: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 61: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 62: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 63: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 64: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 65: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201
3: line 66: 45行目の <pre> 内にはタブ文字を書かないようにしましょう。 → 解説 201

>>619
あれはわざとそのまま使ってるんじゃね？

うん。

Strict教はlint厨じゃないよ。

Strict教信者もValidですらないHTMLを書くのか。

Validの意味を勉強しなおせ

Validですらないにはstrictも包括されるんじゃ？

Validではある。
バカじゃねーの？

バカで〜す

>>624
先のURIに置かれた文書がInvalidである根拠を明確に示してみ。

倫人くんがゆったからｗ

>>621
わざとならそのままパクっていいなんて初めて聞いた

大丈夫か?

>>631
cssファイル丸パクリだとまずい
デザインが意匠登録されてるとまずい
パクリ元サイトと混同させかねない場合もまずい
インスパイヤはOK

そのままってか、どうしても似てくるよな。

アプリケーションの操作の説明はどのようにマークアップするのが正しいですか?

例えば
「ファイルを保存するにはメニューのファイル(F)→名前をつけて保存(A)を選択します。そしてファイル名の欄にhoge.txtと入力し、OKを押すと保存されます」
と言う文章だと、

ファイル(F)
名前をつけて保存(A)
ファイル名
hoge.txt
OK

をマークアップするにはどう書くべきですか?

>ファイル(F)
>名前をつけて保存(A)

これはpre要素でしょ。

とりあえず、
(F)、(A)、hoge.txt は <kbd> だな。

olかdlでしょ。またはその組み合わせ。
普通にテキストの説明文でpならpでもかまわんでしょ。

>>637
お前は本当に文章の読めないやつだな

635も636も違うと思う。

>>635
preはインライン要素じゃない。

>>636
hoge.txtはkbd要素でいいと思うけど、(F)とか(A)は表示されてる文字であって、
単にメニュー項目の表示文字列を示した文なんだろうからkbdは不適だと思う。
メニュー項目全体(つまり「ファイル(F)」とか)をkbdで囲むのも、そのテキスト自体は
キーボード入力ではないから不適だと思う。

>>634
「UIにおける、ユーザーがクリックすべき箇所」という意味の要素はないから、
マークアップしないか、せいぜいspanだと思う。

辞書型定義リストDLは、
入れ子にできますか？

<!ELEMENT DL - - (DT|DD)+>

>>640
HTMLの仕様では可能だが、そういったケースが思う当たらない。
どういったケースでそれが必要？

よかった。　使ってもよいのですね。
こんな具合にしているのです。
IEとFFだとうまく見えてくれます。

第一章
　　第一節
　　　第一葉
　　　　説明……
　　第二節
　　　第一葉
……

ずこー

dlの入れ子は手打ちだと氏ねる

しかし、Dreamweaverだとうまくやってくれませんでした。

>>642
何のためにh1〜h6があると思ってるんだ

簡単に見出し以下が、
インデント付きになるのがよいのです。

そういうときこそdivのグルーピングなんじゃ。
まあ全部に一々margin設定でも良いけど。

そういうのを指示しなくていいので楽ちんなのですよ！

>>647
見てくれの話なら用途違い。

楽ちんなのがいいなら、このスレ来ちゃダメだよ

半年ROMってろ

もっとROMってろ

永遠に(ry

いや、ROMも禁止した方が(ry

マークアップについて質問です。

<p><img src="***.jpg" width="***" height="***" alt="***"></p>
<h3>絵の説明</h3>
<p>文章文章……。</p>

絵のサイトなので１つのページに、以上の順番で出現させたいのですが、しっくりきません。
img要素をh3要素（h1とh2は他で使います）で包含するのがいいのでしょうか。
それとももっと適当なマークアップがありましたら教えてください。

<h3>絵の題名</h3>
<dl>
<dt><img /></dt>
<dd>絵の説明</dd>
</dl>
<p>文章文章……。</p>

こうじゃねえか？

すみません、h3要素の内容は「絵のタイトル」でした；
もう一度書き直します。

<p><img></p>
<h3>絵のタイトル</h3>
<p>文章文章（絵の説明）……。</p>

「絵」「絵のタイトル」「文章（説明）」の順番で出現させたいのです。
>>657のようにタイトルを先に持ってきてCSSで順番を変えるほうがいいのでしょうか。

>>658
<dl>
<dt><img></dt>
<dd>
<dl>
<dt>絵のタイトル</dt>
<dd>文章文章（絵の説明）……。</dd>
</dl>
</dd>
</dl>
か、
<dl>
<dt><img></dt>
<dd>絵のタイトル</dd>
<dd>文章文章（絵の説明）……。</dd>
</dl>
でどうだろう？

「絵のタイトル」はタイトルだけど絵より下に出てくる時点で、
見出しではなく「絵に対する説明」だと解釈した。

imgにもtableみたいにキャプションあればいんだけどな。
本で画像載せる時は大抵付いてるのに…

talk:>>660 ところで、img要素はインライン要素だ。

<dl title="絵のタイトル">
<dt><img src="foo" alt="bar"></dt>
<dd>絵の説明</dd>
</dl>

<table summary="caption">
<caption>caption</caption>
<tbody><tr><td><img src="src" alt="alt" /></td></tr></tbody>
</table>
talk:>>662 お前は dl を何だと思っている？

うざコテが帰ってきちゃったな･･･
帰ってこなくていいのに。

「絵」「絵のタイトル」「文章（説明）」の何処が表なんだ？
strict以前の問題。

以前から思ってたんだけど、
<dl>
<dt><img src="hoge.jpg" alt="〜"></dt>
<dd>〜〜〜</dd>
</dl>
dtのなかにimgはアリなんかね？
イマイチ気持ち悪いんですが・・・

talk:>>665 caption をつけるのだから表組みにしてもいいだろう。

>>667
バカなの？

そんなルール初めて聞いた

>>666
説明付きリストや会話文などまでも許容されるとなった今となっては、
まだ「画像とその説明」の方が会話文よりも妥当で理に叶ってると思う。

「用語定義」しか認めてなかった頃だったら気持ち悪いかもしれないけどね。

talk:>>668 [>>660]に訊け。

>>671
白痴なの？

talk:>>672 何考えてんだよ？

>>673
いいかげん消えろよ。
一人だけレベル低すぎて浮いてるぞ。

talk:>>674 人の脳を読む能力を悪用する奴を潰せ。

パラノイアぶったりキモイ前置詞使ったりしてるあたりで明らかにただ荒らしたいだけのネタコテだろ。
いちいち荒らしに反応するな。

複数の画像があって、それぞれのタイトルや説明を書いた「一覧表」みたいなモノは有り得るだろう。
それがたまたま単数ならば単数の表も有り得る。
この場合はどうかと思うが、全否定は出来ないよ。

>>658
まず、それはどういう構造なのか考える。
俺が考えるに、2パターンあると思う。

一つ目は、絵にタイトルが係り、同じく絵に説明が係る、というもの。
二つ目は、絵にタイトルが係り、絵とタイトルのペアに説明が係る、というもの。

一つ目は、
<>
　<><img></>
　<>
　　<h3></h3>
　　<p></p>
　</>
</>
二つ目は、
<>
　<>
　　<img>
　　<h3></h3>
　</>
　<>
　　<p></p>
　</>
</>
という構造を意図して言っている。

あとは適切な意味づけを探せばOK。
構造は、必要に応じて追加したり省略したりすること。

>>678
ばーか

またHnとセクションの話しか・・・

>680のおかげで>679が何を言ってるのか分かった。
これは話すまでもなく俺(>678)が馬鹿だったわ。

みなさま、ありがとうございます。
dl要素でマークアップするのが適当みたいですね。
その方向で考えてみます！

talk:>>682
いいから table を使え。
<table summary="美術館の一部？">
<tbody>
<tr><td><img src="src" alt="alt" /></td></tr>
<tr><td>絵のタイトル</td></tr>
<tr><td>説明</td></tr>
</tbody>
</table>

だから逃げでそればっか言っててつまんねぇ。
まともな指摘さえ出来ない奴はくんなよ。

talk:>>684 table と dl のどっちが適当か、すぐに分かるだろう。

>>685
どう考えてもdlだね。
消えてね。

talk:>>686 並べ方まで指定したいのだから、table以外に考えられない。お前は dl を何だと思っている？

dlだろ。
tableになる事はKingOfUniverse ◆667la1PjK2がもてはやされる事ぐらいありえない。

talk:>>688 お前は反論できなくなると人格攻撃に出るのか？

反論じゃなくてただの事実です。