Strict-HTML スレッド 40

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 スレッド 39
http://pc10.2ch.net/test/read.cgi/hp/1162719363/

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

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

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

関連スレは>>2

/* CSS・スタイルシート質問スレッド【64nd】 */
http://pc10.2ch.net/test/read.cgi/hp/1172417488/

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

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

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

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

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

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

世界標準ホームページ制作王の、国内における標準化を目標に、
他社工作員と戦い続ける愛国有志のスレッドは以下の通りである。

【警告】21世紀の世界標準はホームページ制作王のみ
http://pc10.2ch.net/test/read.cgi/hp/1172413968/

非標準アプリケーションを製造・販売するために
標準アプリケーションに対していわれなき悪評を喧伝する企業、
ならびに非標準アプリケーションを使用しつづけて
標準アプリケーションの普及を妨げるユーザー、
彼らに世界の意志による正義の天誅が下る日は近い！

相手は死ぬ

世界の権威COMDEXが、21世紀の世界標準に認定したアプリケーションは、
地球上に唯一つ、ホームページ制作王のみである。

ホームページ制作王によってオーソライズされるWebのみが標準であり、
ホームページ制作王を使わずにパブリッシュされるあらゆるコンテンツは
すべからく非標準＝まがいものであることが、既に世界の意志によって
定められているところである。

日本では、2ちゃんねるなどにおいて、非標準のインチキソフトウェアの
販売で生計を立てるイカサマ企業工作員が、ホームページ制作王に対して
いわれのない悪評をでっちあげ、「あるある大辞典」などを盲信する国民性を
背景として、ホームページ制作王の普及・標準化を妨害している。

そのため、21世紀に入って７年目の今年に入ってもなお、
我が国においてはホームページ制作王の標準化が達成されていないのが現状で、
ホームページ制作王とともに進化を続ける世界のWebとの差は広がるばかりである。

今こそ我々日本国民は、強い意志で風評被害を克服し、ホームページ制作王を
Webオーソリューションのベーシックスタンダードとして受け入れ、
とめどなく進化を続ける世界のWebと肩を並べねばならない。

まだ間に合う。しかし、残された時間は少ない。

>>1乙

前スレは勝手に落ちるとして、
こっちの即死回避はいくつなんだろ

即死回避については知らないが、こんな俺でも>>1乙するくらいならできるぜ

>>1
乙

前スレ落ちたね >>1乙

落ちてネーヨw

即死判定

そもそも即死判定があるのかが
疑わしくなってくるレス数だな

フレーム使用禁止、モバイル向けドメイン“.mobi”
ttp://www.atmarkit.co.jp/news/200703/01/mobi.html

GMOの宣伝はさておき、.mobiってそんな規約あったのね。

>>13
多くの携帯端末はフレームをサポートしていない、というよりは
サポートできないだろう。

しかしmTLDでそのような規約をもうけるのはどうかと思う。
こっちの勝手だし。……こうやって統一すれば、利用者は「問題なく閲覧できる」という
前提でモバイルサイトを利用するのかな。

でも正当かつ厳密型のHTMLで書いていれば、だいたいどんな環境でも
問題なく閲覧できると思う。わざわざ「携帯サイト」として独立させる意味がわからん。

W3C、HTML 4の後継となる次期HTMLの標準策定に着手
http://internet.watch.impress.co.jp/cda/news/2007/03/08/15013.html

HTML 5.0 になるのかな？

HTML5.0＝Web2.5の時代ですか？

ストリクタがバズワードですか？

なんだ祭りになってないな。
シンプリィハイパーテキスト次期HTMLとリッチテキスト志向のXHTML2.0が混在するんだな。

またIEが命拾いした・・・orz

ttp://www.w3.org/2007/03/html-pressrelease

5.0イラネ
xhtmlでいいじゃん
っていうかW3C氏ね

5.0をクソIEに喰わせて、XHTML 2.0はガチガチで行こう！

次期htmlは
色々なHTML
http://pc11.2ch.net/test/read.cgi/hp/1155668123/
ここのyhtmlを取り入れて素晴らしいhtml5.0になります！

仕様の厳密化が目的なら歓迎だな。

論理マークアップから今度は感情マークアップなのかよｗ

おもしろい？

>>23
＞感情マークアップ
yhtmlのことかーーーっ！！！

ちんこ

HTML 4.1（控えめに）
HTML 4.5（「4 の後継」を強調）
HTML 5（一番順当？）
HTML 6（ネットスケープ風味）
どれかになるかな？

HTML 4.2（忌々しい思い出を彷彿）

<控えめに>HTML 4.1</控えめに>
<忌々しい思い出を彷彿>HTML 4.2</忌々しい思い出を彷彿>
<「4 の後継」を強調>HTML 4.5</「4 の後継」を強調>
<一番順当？>HTML 5</一番順当？>
<ネットスケープ風味>HTML 6</ネットスケープ風味>

まとめるとこうですか？

俺はyhtmlって命名した自家製XHTMLを作ってるんだがどうしよう？
まネームスペースがあるから銅でもいいけど。

好きにしたらいいよ

てか4.1って4.0の仕様ミス修正版じゃなかったけ？

もう3.0復活で良いよ

>>32
それは4.01だろう。

はやくcanvas使いたいわー。

はやくHTML5使いたいわー。

HTML5ってWHATGLが狙っていなかったっけ？

WHATWGだった。。。

キミはStrictに向かないな

空気読んでないようで恐縮ながら。
「正しい (X)HTML」もバズワードのような気がするんだけど、どうなんだろう。

例 ttp://www.midnightlover.net/memo/2007/03#D04D
・全ページ共通で h1要素がサイト名
・本文より先にナビゲーション
・body要素の中身が丸々 div要素

早い話、全ページでh1がサイト名というのが自分のことでショックだ。
ただ、自分の場合、h1の中身を同じにすることが適切だと思うからそうしているわけで、
それが（遠慮がちにも）「間違い」だと言っている人を見るとやり切れない。
ナビゲーションというのが具体的に何のことを言っているのかわからないけど、
自分はこれにも該当するのだろうか。

仮に自分の考えが「間違い」だとしても、
それをサイトで主張するなんて、自分には畏れ多くてできるものではない。

よくわからんがザウェブカンザキとか読んだほうがためになるぞ

>>39
まあみんなそんなとこを通過していくものだからな。
勉強していけばそのうちわかってくるよ。

「本文より先にナビゲーション」 ってのはわからんが。
ページ内の目次だったら本文より先だよなあ・・・。

その辺は全部状況次第だからね。

>>39
何かその人の「私の主張はすべて正しい」的ふいんきがダメ…

strictスレでナニほざいてんだ？バカども

>>39
何スレか前にも似たような話があったが、例えば、

<h1>大見出し</h1>
<h2>中見出し1</h2>
<h3>小見出し1-1</h3>
……
<h3>小見出し1-2</h3>
……
<h2>中見出し2</h2>
<h3>小見出し2-1</h3>
……

こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので
この部分だけを別ページに分離したい場合。

<h1>小見出し1-2</h1>
……

という構造しかあり得ないという主張と、

<h1>大見出し</h1>
<h2>中見出し1</h2>
<h3>小見出し1-2</h3>
……

みたいな構造でもあり得るんじゃないかという主張があってだな、仕様書の
どこを読んでもどちらが正解なんて答えは出てこないんだよ。見出しの内容
にもよるが、単独でこのページだけを見た場合でも、どちらも構造的には
おかしくないしな。で、後者を押し進めると、全ページh1がサイト名となる。

>>39
俺もそう思っていたことはあるが、一部の人間が俺仕様を振りかざしているだけで
多くの場合、だいたいの共通認識はある。
指針が必要であれば、公式の仕様に則ったvalidな(X)HTMLと、
WAIなどのガイドラインを最大公約数的な基準として考えておくといいよ。

それ以上をぐだぐだ言われたら、根拠を聞いて、
納得・受容できるかで対応を変えればいい(別に俺仕様に従う義理もないが、
ユーザの真っ当なフィードバックの可能性もあるので顧慮するのもいい)。
たいがいは、俺仕様を主張する者同士で衝突しているだけだから、
そういうのに関わらなければ大して問題ではない(し、関わっても費用対効果は低い)。

>>39
どうでもいいが物凄くキモイなそのサイト。

>>39
q要素が文字色の微妙な違いでしか判別できない。
code要素が背景色の違いでしか判別できない。
見出しのつけ方が数字2桁で意味不明。

これらのアクセシビリティやユーザビリティを考えることより、
h1要素をページごとに変えることのほうが大切というわけか。

>>48
表示は関係ないね

どうもありがとうございます。いくらか自信を取り戻しました。

>45
自分はまさに後者です。
サイトの構造を見出しレベルで書いていたらそういう流れになりました。

>46
勧告・ドラフト・ガイドラインなど、「文書」として出ているものに従えば、
少なくとも「間違い」ではないと考えてよいのかなと思います。

そこから先を考えるのがこのスレの存在意義だとは思いますが、
あまり先入観で「正しい」とか「間違い」だとか言うべきではないのだろうとも思います。

例にあげてるサイトを尊敬してるのか叩きたいのかわからん

たしかに、なんでもかんでも単純な二分法で割り切れるなら簡単でしょう。
しかし、残念ながら、世界はそれほど単純にはできていません。
以下略

39のレスの時点で39は例にあげてるサイトを叩きたいんだと
俺は思ってしまっていました・・・

「こちらしかあり得ない」という人に理由を聞くと、「もっと勉強すれば
分かるようになる」とか「あんたはStrictに向いてない」とか「そんなことが
問題になるほど、このスレのレベルは落ちたのか」とかいう答えが返ってきて、
結局、理由が挙がらないというのは、過去スレにも何度もあったこと。

これが、レイアウトのための記述だとか、仕様書で推奨されてないとかいうの
なら話が分かるが、そういうレベルの話でもないんだから、俺ルールでしかない。
要は、文書構造の捉え方の違いだろ。

最後の一行だけで良かったのでは？

たしかに理由が挙がってないな。
>>39 にあがってるサイトも理由を書けばまだいいんだがな……。

>>39 も 「じゃあなんで H1 にサイト名を書くことが問題なのか」 をもっと考えればいいのに、
ショックだ とか 適切だと思う とか サイトで主張するなんて恐れ多い とか、
自信を取り戻したとか、先入観で「正しい」とか「間違い」だとか言うべきではないとか、
なんか方向が違うくね？

「こうこうこういう理由で H1 にサイト名を書くことが問題だ、という話もわかったが、
　自分はこうこうこういう理由で H1 にサイト名を書くことに到った。
　その過程をただ先入観で否定されるのは甚だ遺憾だ」
とかまで言ってくれると面白いんだが。

おれは別にh1にサイト名が来る必要は無いと思う。
>>39が痛い事は別にして。

たぶん、他の部分であるスタイルを採っているために、
各ページにh1要素としてサイト名をおくことが、その
スタイルに違反してしまう、ということなんだろうと思う。

なんにしろh1に関してだけ話をしても分からんね。

title要素には何を書いてますか？
「ページ名 - サイト名」ってのをよく見かける気がするけど
意見を聞かせてください参考にさせてください

39のrel属性にmade,authorがあるけど、profile属性がないぞ。

>>59
サイト名で検索にヒットさせたい場合を除き、TOP以外にサイト名は不要だと思うが

理由を書けばまだいいんだがな……。

>>58
スタイルって何の話？

>>59
うちも 「ページ名 - サイト名」 だなあ
とりあえず title と H1 には、そのページの主題を書く。

なんでかってーと、そうかいてると、
ブラウザで見たときに、そのページが何について書かれているか一目でわかるから。

サイト名を後置するのは、たとえば検索とかで複数のページを開いてるとき、
同じタイトルだとブラウザのタブやツリーメニューで行ったり来たりするとき迷うから。

昔 H1 にもサイト名書いてたけど、
そのページを見てる段階でサイト名とかわざわざ見る必要がないことに気づいてやめた。
ページ毎にサイト名が必要なのは主にデザイン面かなと思うけど、それはCSSで何とでもなるしね。

各ページのh1にわざわざタイトルを入れるのは糞ブログだけ

> サイト名を後置するのは、たとえば検索とかで複数のページを開いてるとき、
> 同じタイトルだとブラウザのタブやツリーメニューで行ったり来たりするとき迷うから。

なるほど
いろんなページを同じフォルダに保存したときに
title要素をファイル名にした場合だと、
名前でソートすると同じサイトがまとまったほうが
わかりやすいだろうと思って「サイト名 - ページ名」ってしてたけど
保存しなきゃ意味ないし閲覧時のわかりやすさのほうが重要ですね

そもそもtitle要素にサイト名を書く必要があるのかって人なども
理由付きで教えていただけると参考になります

SEO的にはタイトルに余計な文字を入れないほうがいい。

titleの書式については、どうもStrictと関係ない理由しか
思い浮かばないよね。何かガイドラインで言及はあるのかな？

h1(というかページ毎)にタイトルがあると、文書だけスクラップした
ときに後で分かりやすかったり、検索エンジンから個別ページに
たどり着いたときに分かりやすかったり。
そう高い頻度で役立つわけじゃないけど、書いておいて損はない
情報だな。(つまり、文書の構成としてそういうのはアリだろう、ってこと)
これもStrictと関係ない気がする。

>>63
> スタイルって何の話？
具体的に何なのかは想像がつかない。

title要素に関しては仕様書にしっかり書いてあるぞ。そのページだけ取り出した
時でも文脈が分かるようなタイトルをつけなきゃならん。「Introduction」だけ
とかはダメで、何のイントロかしっかり書けと書かれている。

つまり、<title>更新履歴</title> とかは駄目だ。これだけでは何の更新履歴か
分からない。例えば、<title>○○の更新履歴</title> と書かなきゃならん。
ってことは、サイト名そのものである必要はないが、それに相当するものは
入れなきゃならんってことだ。

ってことで、title にサイト名を入れるのがいいのは以前から分かってる事で、
今の問題はh1のサイト名の方。

>>45の例はありえなくはない。それは前提で。
h1を常にサイト名にするのも有り得るが、じゃあ内容はh3の重要度かってこと。

>>68
> title要素に関しては仕様書にしっかり書いてあるぞ。
確認してなかった。いまは反省している。
仕様書にもわりと具体的に書いてあるね。

> 今の問題はh1のサイト名の方。
ページ毎にh1要素としてサイト名、ってのがアウトというのは、
「サイト名は内容を表してないから見出しとして不適切」ってことかな。

その場合は、サイト名ってサイト全体を指してるものだから、
ページの内容を表す大見出しとしても別に問題なさそう。
あと、そもそも内容をよく表しているサイト名（「〜〜に関するまとめ」とか）
の場合はh1にサイト名を置くのは問題なさそう。

>>69
相対的に内容の見出しレベルがh3になるのは構わないんじゃない？
幸い見出しは6レベルあることだし。

うん。構わないんじゃない？
常にh3から内容が始まるサイトｗｗｗ
h6までいっぱいいっぱいなサイトｗｗｗ

たしかに見出しの数が狭くなるのはないなーｗ

気になるなら全部で1ページにしちゃえば良いよ＾＾

>>73
天　才　現　る　！！

このスレ的には会社の住所とかどうやってマークアップするか興味深いんだが

素直にちゃんと状況を書け

いやふと思っただけでほとんど<p>で<br>使ってるからこのスレの住人ならどうするかなあと

addressで良いのでは

そう思ったんだけど会社概要とか一列で表示されることって稀だから
<address><span>でスタイルシートで調整かなーと電車で考えてた

>>79
すとりくたがレイアウトのためにspan仕込むわけないだろ。
おまえバカか？

address 要素は p 要素より、どちらかというと div 要素よりの解釈ができるわけで、中に ul 要素などを含めることができる。
よって、address 内にリストを作っちゃうのもあり。
それならスタイルも定義しやすいでしょ？

「会社の住所」がいつの間にか「会社概要」に変わっている
というか「会社の住所とか」の「とか」って何を含んでいるのか
もっとストリクトに

>address 要素は
>中に ul 要素などを含めることができる。
>address 内にリストを作っちゃうのもあり。

釣りではありません真性です

そもそも会社の住所がその文書の連絡先なのか
単に文書中に住所が出てくるだけなのか不明だろ。

で、文書の連絡先ということなら会社の住所とか
わざわざ限定する意味はない。

しかも79を見る限り、書式も勝手に思い描くものがあるようだし、
詳細を明らかにしろよ、ということ。

ふと思ったんだけど、住所がaddressってことは
その文書について問い合わせたい時は、手紙を送るか乗り込んでいくのかな。

ごめんよくある会社概要のページ思い描いてたんだけどフッタのページ連絡ではなく
<address>に<span>入れるのはおかしいけどclass,idで入れるのはありかなと思ってた
<span class="telephone">とかで構造を表しつつスタイルシートも使えると思ってた
そもそもこれを<address>でマークアップしていいのかもわからんかった
<h2>会社概要</h2><p>住所</p>が正解かもしれんね正直スマンかった

すまんｗ blockquote 要素と間違えたｗ
ul は使えないね＾＾；

> よくある会社概要のページ
> <h2>会社概要</h2><p>住所</p>が正解かもしれん
定義リストよりもそっちのほうが適切なの？

住所をp要素とする時点で不適切だし、
「住所=address」と短絡してaddress要素とするのも不適切。

<dl>
 <dt>会社名</dt>
 <dd>株式会社○○</dd>
 <dt>所在地</dt>
 <dd>○○県○○市○○</dd>
 <dt>資本</dt>
 <dd>○○○億円</dd>
</dl>
>>88 のいうように、これが割とストリクトかも知れぬ。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4
にあるようにtableでOK。

そういや address といえば、
Web Applications 1.0 (html5) の文書で、
「address要素にその文書の問い合わせ先以外入れんなやボケが」 って書いてあって、
　　(> http://www.whatwg.org/specs/web-apps/current-work/#the-address)
いままで Copyright とか address 内に合わせて書いてたんだが、
もしかしてそれは違うのかなあ、って最近悩んでるんだが、どうなんだろう？

copyright表記は文書の権利者の表示だからOKじゃない？
文書についての連絡先としては、名前、住所、電話番号、URL、などがありうると思う。
文書についての連絡先と権利者は必ずしも一致しないけど、
権利者を(連絡先として)示すつもりならaddressに書いても問題ないでしょ。

92のURLと同じところに
> The p element is the appropriate element for marking up such addresses
って書いてあるね。>89の
　> 住所をp要素とする時点で不適切だし、
ってのは間違いになるっぽい。

strict wiki なくなってしまいましたか？

このスレ数年ぶりだな。

サイト名をtitleやh1に云々の話だけど、そもそも「サイト」というのが曲者だと思う。
サイトという概念を認めると、例えばリンクに関して言えば、
「トップページ」へのリンクと「ディープリンク」を区別するのを認めることになるよね。
まあ区別したから即「リンクはトップページへ」となるわけじゃないけど、
そういうのは正しいWWW認識ではないんじゃないのかなと思う。

参考：
http://d.hatena.ne.jp/kana-kana_ceo/20061123/1164272941

まあ何らかのテーマに沿っていくつかの文書を書く「プロジェクト」みたいなのはありえるから、
それをサイトと呼ぶのはアリだと思うんだけど、そういう認識ならどっちかというとaddressにしたい。

> まあ区別したから即「リンクはトップページへ」となるわけじゃない
から
> そういうのは正しいWWW認識ではないんじゃないのかな
ということはないだろ。

明確には区別しがたい場合もあるにしろ、コンテンツ作者が
コンテンツ群をひとつのサイトと意図してることは多いわけで、
それを見出しとして文書に表示するのは問題なしだと思うよ。

文書の内容までWWWの原理に従わなきゃならないという
話はないわけだし。

> まあ何らかのテーマに沿っていくつかの文書を書く「プロジェクト」みたいなのはありえるから、
見出しとしてのサイト名であって連絡先じゃなんだからaddressは
ないだろ。何かのプロジェクト名を文責として示すならともかく。


全般的に、95の内容は、サイトになんか変な特性・制約を付加してるような気がする。
サイトはサイトでいいじゃん。サイトという概念でコンテンツを括って、それを文書の
見出しとして表示することが通るとしても、サイトという概念がすべてに強制されるわけ
じゃないし、その概念がうまく機能すると認めることにもならない。

>サイトという概念を認めると、例えばリンクに関して言えば、
>「トップページ」へのリンクと「ディープリンク」を区別するのを認めることになるよね。

少なくとも「画像ファイルを参照しているHTMLファイル」へのアンカーと、
「画像ファイル」への直接的なアンカーは別の意味合いを持つと思う。
そういった意味では（もちろん個々のファイルで完結する場合もあるが）「サイト」という概念は
誰かが持っていて利用するに越したことはないし、あったところで問題もないものではないか。

>何らかのテーマに沿っていくつかの文書を書く「プロジェクト」みたいなのはありえる

その概念ならむしろ「コンテンツ群」であって「サイト」の十分条件であっても必要条件ではない。
例えば文書群の著者についての略歴だとか、そういうものをイメージした方がいいんでは。

>そういう認識ならどっちかというとaddressにしたい

96に同意。

ファイルがなんだろうとリソースにはかわりない。

リソースには変わりないけどリソースの質は変わるでしょ。

ここで言ってる「サイト」とは、「たまたま同じ人が作って同じサーバーに
上がってるだけのあまり関連性のないページ群」のような薄い繋がりじゃなくて、
例えば「rel="next"などで繋がるような一連のページ群」のことだと思う。

仕様書にある「title要素は文脈込みで」という話も、前者のような薄い繋がりの
サイト名なら文脈に関係ないから入れる必要がないだろう。後者の場合、サイト名
こそが文脈となるから入れるべきとなる。

文書の所属サイトも文脈のひとつだよ。
一般論としては、その文脈を示す必要がないと著者が思えば
サイト名は文書内に示さないし、必要だと思えば文書内に示す。

title要素については>68のような注意点がある。
そのサイトにしかないコンテンツとかならサイト名はいらんだろうけど、
そうでない状況は多いため、サイト名はわりと必要になるだろう。
title要素が「小説コーナー」や「鉄道写真のページ」などであるよりは、
サイト名という文脈も示されていた方がよりよいだろう。

要は、サイト名が文脈に関係ない、というのは一般的には言えない、ということ。
(サイト名じゃなくても同様の文脈を示せることはあるけどね。)

> 「rel="next"などで繋がるような一連のページ群」のこと
のように条件を加えた状況については、>70の
> あと、そもそも内容をよく表しているサイト名（「〜〜に関するまとめ」とか）
> の場合はh1にサイト名を置くのは問題なさそう。
あたりに似たようなことが書いてあるね。

>>99
参照にかわりはない。

変わりない面もあれば変わりがある面もある。
つまり併せて考えれば変わりがある、ってことだな。

話に関係があるのかないのかは知らんが。

>>97
HTMLファイルへのリンクか画像ファイルへのリンクかでは、リンクの意味は
変わりないよ。相手のファイル形式が何であれ、あるリソースへのリンクだ。

もし相手が、状況によって PNG と HTML のどちらかを返すような CGI だったら
どうする？　そのリソースが画像かどうかさえ議論出来なくなるぞ。

もちろん、<a href> でのリンクか <img src> でのリンクか、だったら意味は
変わるけどね。

じゃあそもそもサイトって何よ。

>>104
> もし相手が、状況によって PNG と HTML のどちらかを返すような CGI だったらどうする？
そんな状況の話してなくね？
> 「画像ファイルを参照しているHTMLファイル」へのアンカーと、
> 「画像ファイル」への直接的なアンカー
の話なんだから。
それらが存在しえないって話なら分かるけど。

> 相手のファイル形式が何であれ、あるリソースへのリンクだ。
それだけだと、「hrefだろうがsrcしていだろうが参照には違いない」とか
言うのと同じで文に中身が無くない？同じあるリソースへのリンクであっても、
意味合いに違いがあるだろ、って話でしょ？


思うに>97のその部分は、文書と文書の一部を区別することに意味があるように、
文書ひとつとサイトを区別することに意味があるだろうから、サイトという考え方には
意味がある、というような話だろ。
ただ、それが97の引用部とどういうつながりがあるのかよく分からんけど。

>>105
よく分からんけど一般にサイトと呼ばれているものだろ。
だいたいは、管理者が管理するネットワーク上の領域とか文書群の単位として
サイトという言葉が使われてると思うけど、過不足なくしっかりサイトの定義を
するのはあんまり簡単じゃなさそう。
あと、「URLのドメインが異なれば同じサイトじゃないよ」とか言う人もいて、
一意に使われているものじゃなかったりもする。

まあ、考えるに必要な程度だけサイトを認識してればいいんでない？
認識ズレは話の途中ですり合わせればいいんだし。

WWWの仕組みからして、どんな内容のリソースでも立場は平等だということは言える。
でも、内容は千差万別だから、内容的に特別な関係にあるリソースというのはある。
HTMLの場合、その特別な関係がlink要素となって明示される。
本屋や図書館で言えば、どの本も同じように置いてあって、同じように売るけど、
漫画とかでよくある「続き物」はある。と。

サイトっていうのは続き物一セットのことで良い？
「目次ページ」はそのガイドブックみたいなもの？

>>104
言ってることには同意だけど、場合によって全然違うリソースが返ってくるっていうのはURIとしてどうよ。
コンテントネゴシエーションというのはあるけど、限度があるだろうし、
そもそも普通の文脈ではそんなURIでリンクすることはできないはず。

今日、田中さんに会った。

この文の「田中さん」もリンクだよね。人間のURIが標準化されれば、
<a href="(田中さんのURI)">田中さん</a>とすることができる。
リンクってこのくらいものだよね。

- 今日、<a>HTMLの仕様書</a>を読んだ。
- 今日、<a>CSSの仕様書のfloatの図</a>を見た。

だから、リンク先が文書でも画像でも、「トップページ」でもそうでなくても、一緒だと思う。

imgやobjectで埋め込まれる形で呼び出されるリソースはまた異なるんでないの？

>>109
それは既に >>104 の最後であがってる。

卵と鶏のどっちが先か、になるけど、いわゆるサイトのトップかサイトの一部か、には違いがあるでしょ。
それこそ総称目次に対する参照か続き物の一部に対しての参照か、になるわけだから。

>>107
> WWWの仕組みからして、どんな内容のリソースでも立場は平等だということは言える。
どういう意味で平等なのかはよくわからんけど、
「WWWの仕組みからは違いは生じない」ということでしょ？
「違いがあるように扱うことが禁止されている」ってわけじゃないんだから、
サイトという考え方自体がHTMLやWWWと相容れないものだという話にはならんでしょ。

>>108
それはどうみてもハイパーリンクじゃない。
喩えとしても意味が分からなかった。

>>112
あー…。
その程度なら引っ込んでろ。

>>113
具体的に指摘できず揶揄するだけなら引っ込んでなさい。

>>114
小麦粉を知らないのにパンを語るな

今度は妙な言い回しで「何か言ったつもり」ｗ

>>112
サイトが出来るかどうかと、リンクの意味が異なるかどうかは全く別次元だろ。

rel="start" や rel="next" などを使って、複数ページでサイトを構成する事は
出来る。

でも、リンクは、サイト全体を指す事は出来ないんだよ。トップページにリンク
しても、その1ページだけを指しているに過ぎない。末端ページや画像ファイルに
リンクしている時と違いはないよ。

>>117
> サイトが出来るかどうかと、リンクの意味が異なるかどうかは全く別次元だろ。
そこは別の話だと解釈してたけど。
「文書とその部品(画像)という関係があるように、サイトとその部品(各文書)
という考えでものを捉えても別にいいよね」ということを言ってるんであって、
「文書もその部品へもリンクできるから、サイトもその文書へもリンクできるよね」
ということは言ってないんじゃない？
まあ実際のところは97にしか分からんけど、俺はそう読んだ。

むしろ、サイトという概念を認めることがそういうことを認めることにつながる、
と言ってるのは>95の方だと思うよ。>97じゃなくて。

>>118
文書でも文書の断片でも文書に埋め込まれていたファイルでも変わらない。

>>119
それは>95に言えって。

部品へしか明示的にリンクすることができない（総体へリンクしたことを明示的に示せない）から、
総体的な概念である「サイト」は存在しない、とは言い切れまい。

んじゃサイト全体にリンクできるようにサイト全体のアーカイブを置くべ

<a href="http://example.com/unko.zip">うんこのサイト</a>

>>112
>それはどうみてもハイパーリンクじゃない。
何でハイパーリンクじゃないと思うの？
じゃあこれはどっち？：
<a href="urn:isbn:...">...</a>

>「違いがあるように扱うことが禁止されている」ってわけじゃないんだから、
そんなに必死にならなくても、>>107はサイトという概念を認めてると思うよ。

>>121
だから、>>117 で「サイトを構成する事は出来る」って言ってるんだけどね。

サイトは作れるし存在する。ただ、サイトにリンクする事は出来ないから、
サイトの存在を認めたところで、リンクの概念が変わる訳ではないってこと。

>>123
aタグでマークアップしてる方じゃなくて
　> 今日、田中さんに会った。
　> この文の「田中さん」もリンクだよね。
こっちの方の話だよ。

> そんなに必死にならなくても、>>107はサイトという概念を認めてると思うよ。
サイトという概念自体が成立するかしないかの話じゃなくて、
サイトという概念とWWW認識とやらが矛盾するものなのかどうかの話だよ。

だからリンクの概念を調節しよう、って思ってる人たちが「トップページへリンク」「ディープリンク」
っていう言葉を作り出したっていうことなんじゃないの？
それの是非についてをああだこうだ言うならともかくさ、あまり意味のない言い合いでしょ現状。

サイトって検索エンジンやソーシャルブックマークが発達してなかった時代の遺物なんじゃないのか。
リソースを探す手段が乏しかった頃は便宜上そういうものがあるような言い方をして
ディレクトリ的な整理をせざるを得なかったけど、これからはそういう幻想はあまり必要無くなると思う。
必要無くなれば消えていくだろう。
つまり、誰が作ったリソースかを無視したリンク集(自動的に生成されるものもあり、手動で生成されるものもあり)と
自己紹介的な「私はこんなものをウェブで公開しています」というものだけが残る。

>>125
<a href="(田中さんのURI)">田中さん</a>
田中さんもリソースだよ。

>サイトという概念自体が成立するかしないかの話じゃなくて、
>サイトという概念とWWW認識とやらが矛盾するものなのかどうかの話だよ。
WWWの上に成り立ってる概念がWWWと矛盾してるってことはあり得ないだろ。
サイトという概念が成り立つと言ってる人はサイトという概念が「正しいWWW認識」と矛盾しないと言ってるんだよ。

話のおおまかな流れ

・全ページ共通でh1にサイト名書くやつはHTMLとして正しくない？(>39)
　→・とりあえず仕様書にはそんなこと書いてないよ(>45)
　　→・内容がh3レベルの重要度って変じゃね？(>69)
　　　→・相対的なものだから別に変じゃないでしょ(>70)
　→・サイト名はサイト全体を指す言葉だから各文書の見出しとして適切だよ(>70)
・サイトという概念を認めると「トップページ」へのリンクと「ディープリンク」を
　区別するのを認めることになるから正しいWWW認識じゃないよ
　→・区別だけなら別にWWWなんとかと衝突しないだろ(>96)
　→・アンカーの意味合いの違いのような感じでサイトって概念も問題なし(>97)
　　→・アンカーということは同じだから意味の違いなんてないよ(>>98,102,104)
　　　→・同じだけど意味の違いがある、って話なんじゃね？(>106)
　　・WWW的にはリソースは平等だよね。リソース間に特別な関係があったりはするけど(>107)
　　　→・WWW的な平等さがサイトという概念と衝突したりはしないでしょ(>112)
　　　　→・リンクの意味に違いはないよ
　　　　　　サイトはリンクで指せないよ
　　　　　　トップページへリンクしてもサイトへ指した意味にはならないよ(>117)
　　　　　→・サイトをリンクで指せるって話じゃなくね？(>118)
　　　　　→・トップページ云々はリンクの概念の調節にあたるんじゃね(>126)
・シリーズなページ群を指してサイトと言うんじゃないなら
　サイト名は文脈に関係ないからtitleにすら入れる必要なし(>100)
　→・十分文脈になるだろ(>101)

>>127
> <a href="(田中さんのURI)">田中さん</a>
> 田中さんもリソースだよ。
aタグでマークアップしてる方じゃなくて
　> 今日、田中さんに会った。
　> この文の「田中さん」もリンクだよね。
こっちの方の話だよ。

> WWWの上に成り立ってる概念がWWWと矛盾してるってことはあり得ないだろ。
> サイトという概念が成り立つと言ってる人はサイトという概念が「正しいWWW認識」と矛盾しないと言ってるんだよ。
WWWの上に成り立ってる概念がが「正しいWWW認識」とやらと矛盾することはあり得るの？

>WWWの上に成り立ってる概念が

WWWの上に成り立っている概念、と一部の人たちが主張する概念、のことじゃないの？

>>127
じゃあ、rel="start" や rel="next" などで繋がったページ群をどうとらえる？

結局、現在主流のUAが link要素を上手く扱えないから、サイトというまとまりが
見にくくなったってだけじゃないのか？

今北

えーと、つまり、
『「人類はみな平等」 って概念はあるけど、実際は国とか民族とか学校で区別されてるわけで、
　それって平等じゃなくね？』
って話？

「人類はみな平等」 って概念はありません

あの……キミらの言い争いは Strict でなければ HTML でもなく、ただのハイパーリンク論じゃない？ どちらかというと精神論的な。
定義とか概念とか、意味ないんじゃないかと。
ページ作った人が「このページとこのページは同じ屋根の下に入れる」って考えたら、それがその人のいう「サイト」なんだと思う。

>>129
テキストありきだろう。
後半については、俺は「矛盾しないし、今のところ成り立っているが、これからは不要になって意識されなくなる」と思ってるよ。
みんなが意識しているからそういうものがあるだけで、サイトという実体は無いから、意識されなくなったら消滅するはずだ。
というか俺は「あり得ないだろ」と言ったのに何で「あり得るの？」と聞かれなきゃいけないんだ。

>>131
それは<q cite=">>107">内容的に特別な関係</q>があるもの、「続き物」ってことで良いんじゃないだろうか。
いや、>>107はそれをサイトと呼んでるのか。

でも、link要素的な関係でサイトを定義すると、1つのリソースが複数のサイトに属するっていう事態もあり得るよね。
個人的にはそれでも良いけど。

>>134
最初から読め。発端はtitle要素の扱いについてだ。

title 要素は明示的なファイル名だよ。h1 は見出しだから関係ない。

>>134,136
なぜかトップページへのリンクの意味とかそういうことに関しての話に
なってるんだよな。

結局、サイトって考え方とトップページへのリンクでサイトを指せるか否か
とかってのは別の話だから、サイト名をtitleやh1に突っ込むことの問題点
にはならない、というところだろうな。

>>135
> テキストありきだろう。
ありきかどうかの話じゃなくて
そのテキストがリンクかどうかの話だよ。

> というか俺は「あり得ないだろ」と言ったのに
お前が言ったのは「『WWW』と矛盾してるってことはあり得ない」
お前がレスしてる先で言ってるのは「『正しいWWW認識』とやらと矛盾することはあり得るの？」

自分で「WWW」と「正しいWWW認識」という言葉を区別して使い始めておいて
自分で区別ついてないってのは……

>>138
>そのテキストがリンクかどうかの話だよ。
リンクだからa要素なんじゃないの？
リンクじゃないものをリンクにするのは見出しじゃないものを見出しにするのと同じだろ。

>自分で「WWW」と「正しいWWW認識」という言葉を区別して使い始めておいて
ああ、それは悪かった。略しただけ。
でもWWWを正しく認識していればWWWに矛盾するものは受け入れられないし、
WWWを正しく認識していると受け入れられないものはWWWとも相容れないはずだからほとんど一緒だろ。
本を正せば正しいWWW認識ってのもよくわからないけど。

>>139
> リンクだからa要素なんじゃないの？
a要素やらなにやらでリンクを張らないことにはリンクにならないよ。
もともと見出しだから見出し要素としてマークアップする、というのとは違う。

　> 今日、田中さんに会った。
　> この文の「田中さん」もリンクだよね。
テキストの著者が「田中さん」の部分をリンクの始点アンカーと意図したとする。
でも、その時点では始点アンカーではないし、リンクも存在しない。
それが素のテキストとハイパーテキストの大きな違いなんだよ。

> WWWを正しく認識していると受け入れられないものはWWWとも相容れないはずだからほとんど一緒だろ。
そもそも、現実に存在する実装としてのWWWの上にサイトという概念がすでにある。
だから、「サイトって考え方をよしとすると、正しいWWW認識とはぶつかるよね」という
話が出てくるわけだ。
たとえサイトという概念が正しいWWW認識とやらと相反するものだとしても。

で、「サイトって考え方自体、成り立たないよね」とかいう話になるまた違ってくる。
それに関する話としては、>97に
　> そういった意味では（もちろん個々のファイルで完結する場合もあるが）「サイト」という概念は
　> 誰かが持っていて利用するに越したことはないし、あったところで問題もないものではないか。
という言及がある。
この「そういった意味では」という部分が指す「意味の違い」ってことに対して、
その後「HTMLやWWWとしては意味の違いはない」というレスが続いて今に至る、
という話の流れ。

>>140
> > 今日、田中さんに会った。
> > この文の「田中さん」もリンクだよね。
>
> テキストの著者が「田中さん」の部分をリンクの始点アンカーと意図したとする。
> でも、その時点では始点アンカーではないし、リンクも存在しない。
> それが素のテキストとハイパーテキストの大きな違いなんだよ。

「田中さん」という語句と田中さんは、潜在的な繋がり＝リンクがあるよ。
だから著者は「田中さん」という語句と田中さんのリンクを明示できるんだよ。
明示されたリンクはハイパーリンクだよ。

>>141
それは、…

「机の下に本があります。それは私の本です。」
……という文の「それ」は「本」を指してるからリンクだ。

…みたいな話だろ。「田中さん」という言葉も、田中さんという人物を指して
いるからリンク。なるほど、確かに代名詞や固有名詞はすべてリンクだろう。

でも、そこからハイパーリンクの話に結びつけるのは強引というか例が悪い。

>>141
リンクをハイパーリンク以外の意味で使ってたんかい
>108じゃどう見ても使い分けなんてしてないじゃねーか

まあ、結局ハイパーリンクという意味でのリンクじゃない
ってことで落ち着いたならそれでいいよ。

ここまでの流れのまとめを
お願いします

ありがとうございました

Strict の精神 → 意味を重視 → 意味のつながり → ハイパーリンク？
だったら始点と終点になりうるものすべてにアンカー要素が必要になる。
HTML では単なる「つながり」よりも「関連する事象のつながり」のほうが重要だと思うのだが。
単語の意味対象となりうる言語学的なつながりは、HTML 的にはあまり重要でない気がする。

冗長的なんだよストリクターは。

>>146
「何かの意味を持つものには、その何かを指すハイパーリンクを張れる」
って言ってるだけで、特に中身のない話だから気にするな

もうストリクタは全ての単語にアンカーつけようぜ。
たとえば「冗長的」はどっかの辞書にでもつければいい。

冗長を冗長的って使い方するんだ

>>149
それなんてはてなダイアリー？

一般にURIは、文書をアップロードしたサーバ内のディレクトリを反映するから階層に見える。その階層
が「サイト」の概念。
でもURIは階層を示すものではなく、一意な「名前」に過ぎない。
URIの概念把握が甘いと「サイト」（階層構造）の概念になりやすいね。

別にフラットなディレクトリ構造のサイトもあるよな

階層構造やフラット構造以外にも色んな構造のサイトが考えられる。
例えば、「あなたは○○ですか？ (Y/N)」とかを1ページずつ答えていったら
解説ページに行き当たるというようなサイトだったら、網目構造かもしれない。

重要なことは、サイトの構造は、URIやディレクトリ構造とは関係なしに、
各ページの関係だけで決まるということだ。

サイト構造は、URIやディレクトリ構造と一致している必要はない。一致してたら
URIが分かりやすいっていうだけに過ぎない。>>152 の話は原因と結果が逆だ。

数十レスほど通して読んでみたけど話の筋がよく掴めない。
サイトというものを HTML 文書のモジュールとしてとらえ直そうという話？
例えばＡさん・Ｂさん・Ｃさんの小説ページをリンクして文芸サイトを構築した際に
Ａさんたちの小説ページは文芸サイトのコンテンツになり得るから、
制作者が想定している枠組みの名前を文書に含めるべきではないということ？
もしそうなら、URI の階層構造云々の話は脱線なんじゃないかな。

>>155
>>39のネタ振りから始まる話題だよ。
・全ページのh1にサイト名を書くのはダメ
　↓
・とくに理由はなくね
　↓
・サイトという概念そのものがダメだからダメ
　↓
・べつにそんなことなくね　←今ココ

サイトという概念がダメというのは、「正しいWWW認識に反する」とか
「構造がURIの表記に依存してる」とか「リンクの意味を変えるから」とか
その辺出てきたけど、それを否定する意見もいろいろ出てたね。

あと、「とくにダメな理由はなくね」に至るまでに、「サイト名をh1にすると
内容の見出しがh3レベルになるけどそれっていいの？」とか「一般に言う
"サイト"のサイト名は意味が薄いからtitleにすら入れる必要はないよ」とか
の話が出たけど、これも否定する意見が出てた。


話の途中で「ディープリンクとトップページへのリンク、サイトを指す目的のリンク、
これらはアウト」という話に枝分かれしたけど、これはどうなったんだろ。

そのうちサイトとしてのhtmlのグルーピングの概念も出来てきそうだな。
そうなってくるとナビゲーションを別に指定してUA側がそれを読み込んで、
アウトラインとして表示してくれるようになったりとか。
そこまでくると手間はかかるけど色々楽になりそうだなぁ。
フレーム使わないでメニューとか作ると、全部のHTMLに埋め込まないといけないし。

PDFみたいな感じで？

くだらねぇ

普通に考えてh1要素全てにサイトのタイトルはおかしいでしょう。
Strict論と云う論文を書いたとして、

Strict論

　第一章　Strict論
　　一　節　○○○
　　二　節　○○○
　　二　節　○○○
　第二章　Strict論
　　一　節　△△△
　　二　節　△△△
　　二　節　△△△
　第三章　Strict論
　　一　節　□□□
　　二　節　□□□
　　二　節　□□□

・・・とまぁありえない論文になるわけで。

大体、”トップページ”の参照先のアンカーは”リンク集”だとか”日記”だとかなのに、大見出しがサイト名なのは不自然だし不適切。
そんなこと、とてもStrictなサイトの管理者がやることとは思えない。

　

>>160
「h1要素全てにサイトのタイトル」というページ群を
そういうありえない論文にしてるのはお前であって
HTMLの仕様からくる要請ではない。

あと、
> ”トップページ”の参照先のアンカーは”リンク集”だとか”日記”だとかなのに
から
> 大見出しがサイト名なのは不自然だし不適切
への論理の飛躍がある。

>>160
Strict論一巻
第一章　hogehoge
　　一　節　○○○
　　二　節　○○○
：
：

Strict論二巻
第一章　fugafuga
　　一　節　○○○
　　二　節　○○○
：
：

>>160
「Strict論」という連載を考えた場合、毎回「Strict論」という見出しが
付くのは当然とも考えられるが。「連載第3回 リストの考え方」とかいった
各回の見出しはh2レベルになって不自然はないし。

>>161
頭大丈夫ですか？自分の書いた文字を何度か読み直してみてください。
あと、あなたはこのスレにいるべきじゃないと思います。
>>162
対象は”Strict論”と云うタイトルを全てのページのh1要素にする場合の話であって、何を仰りたいのか意味が分からないのですが？
>>163
そんな論文見たことがありません。不適切だからです。
本でもそうでしょう？章が全てタイトルと同じですか？
大学出ていらっしゃいますか？学がなさすぎると思います。
Strict論
　第一章　WWWについて
　　一　節　WWWの始まり
　　二　節　W3Cの方針
　第二章　WWW の現状
　一　節　不便なWWW
　二　節　WWWの進化？
　第三章　Strictにする意義
　一節　アクセシビリティへの配慮
　　　　　　　　・
　　　　　　　　・
　　　　　　　　・
となるはずです。
各回の見出しはh2レベルで良いと言ってしまえるあなたもこのスレに居るべきじゃないと思います。
もしもサイト名を全てのページに含めるのが重要と思うならば”Strict論執筆にあたり参考にしたリンク集”だとか、”Strict論執筆中の日記”等にするべき。
各回の見出しがh2レベルは不自然かつ不適切。

ああ、そんな季節か

>>164
独立した一遍の論文の話じゃなくて、連載記事の話だろ。
誰も章とタイトルが同じになるとは言ってない。
h1がタイトルでh2が章になり得ると言ってるだけだろ。
まず前提条件をよく読もうよ。

>>166
なり得るよ。
だからh2なりh3なりから内容が始まって、h6までいっぱいいっぱいに使う文書を書いてりゃいいじゃん。
場合によってはh6でも内容が始まらないんだろうな。マヌケな話しだ。

結局ID:Nf07tAcfの妄想ルールの話であって、
Strictがどうとかいう話じゃねーなこれ。

>167ともども>39のリンク先のサイトに引きこもってればいいんじゃね。
根拠なしのプロパガンタで主張が通るのはそういう場所だけだろ。

>>167
じゃあ好きにすれば？
俺様ストリクトを追求しつづければいいよ。

プロパガンタ→プロパガンダ

じゃあh1要素の内容は全部WWWにするべきだな。

>>171
好きにすれば。

>>171
「HTTP/1.1 200 OK」というレスポンスで「<html>」というルート要素の
ものが送られるんだから、h1は、もっと下位の内容じゃないとおかしいな。w

h6で足りないんですけど…

>>174
それは判断間違えたんじゃね

>>166が桜満開

>>164
1ページにすれば？ｗ

h1タイトルにしなかったらタイトルはどのように指定するのがいいのですか？

>>178
title要素

>>179
ご一緒にポテトもドゾー
つhttp://www.akatsukinishisu.net/itazuragaki/id/display_title

解ったよ。
このスレにいる奴等はstrictでvalidもしくはノーエラー100点で俺ｽｹﾞｰってなって偉そうに語ってるだけの似非の集まりだ。
まぁ、テーブルレイアウトだとかフレームだとかで俺ｽｹﾞｰってなってる奴等と五十歩百歩って事だ。
違いは、仕様を全く無視して自分のデザインに自己陶酔しているか、仕様を守っている自分に自己陶酔しているかの違いだけ。
深いところまで知りもしないくせに玄人ぶらないでいいよ。strictでvalidなんてデザインとか考えなければ誰にでもできることなんだしさ。

ｽｺﾞｲﾈｰ ﾖｶﾀﾈｰ

>>181
（　´,_ゝ`）ﾌﾟｯ

すみません。正当な XHTML 1.0 Strict 文章に埋め込まれたスクリプトによって、後から XHTML 1.0 Strict で使用できないタグを追加したような場合、
その文章は正当な XHTML 1.0 Strict 文章であると言っちゃって良いのですか？

初心者用質問スレへ逝け

スタックトじゃなくてトランジスタに変えればいいんじゃないかな？

>>184
出力後の状態で判断するのは常識。

バリッドじゃないだろ常識的に考えて...

タグは追加できないよ

ということは、読み込み後の DOM を下手に弄るようなスクリプトを含む文章は、
たとえ XHTML ファイルの書式が正当であっても、その時点で正当ではないと見なされるのですね。

了解です。どうもお手数をおかけいたしました。

ん？　こんがらがってきたな……。
例えば、ファイル sample.html が

　<?xml version="1.0" encoding="Shift_JIS"?>
　<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
　<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
　<head></head>
　<body><script type="text/javascript" src="sample.js"></script></body>
　</html>

みたいに一見正当に見える文章だったとしても、参照先である sample.js の中身が

　document.body.innerHTML = "sample<br>sample";

みたいだったならば、正当ではないということですか。
それともファイル sample.html は正当だが、読んだ後の DOM は正当ではないという解釈なのか……？

DOCTYPE で指定する DTD は、ファイルと DOM のどちらに適用されるんでしょうか。

過去にも何度か出てない？その話題
結局どうなったんだっけ
過去ログ漁って報告よろしく

>>191
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/scripts.html#h-18.2.4
> HTML文書は、どのSCRIPT要素の処理前も処理後も、HTML DTDに適合するよう制約される。

>>193
なる。了解しました。ありがとうございます。

>>193
おー。感動。

ここも世代交代してるんだな

（　´,_ゝ`）ﾌﾟｯ

w3cへの当て付け？
ttp://w2c.jp/

>>198
高木敏光がいる！

無修正はいかんよ

>>198
ネタじゃないよな……？汗

高木浩光はいないのか?

どうせ2ちゃんねらーだろ

>>193
じゃあGoogle Adsがあるページは全滅じゃない？
そう考えると真のストリクタはかなり少ないことになる

>>204
気になるのなら document.write() を上書きして読み込み中の書き出し処理をさせず、HTML仕様に則した検証は済んだとみなされる読み込み後の完成したDOMを操作すれば良いだろう。
規約違反にはならないと思うが、グーグルが読み込み中にしか取得し得ないような値(例えばSCRIPT要素とIFRAME要素それぞれのリクエストの時間間隔)を取得できなかったなどと文句を言って来ないとは言い切れないけどな。

真のストリクタにはスクリプトの知識も必要なのか…

まだまだ道のりは長いな。

googleは金を払わない為ならここぞとばかりに言いがかりを付けてくるぞｗ

s/google/企業/

ストリクタのみなさんは link rel="next" 等書いていらっしゃいますか？(必須？)
最近オペラを使ってみて便利だなと思いました

便利かどうかは関係ない

>>209
とりあえず、俺は自分で便利だと思ったから書いている。
必須ではないだろうが、あればいろいろと助かるので。

>>209
ナビゲーションは必須です
<head>には<link>が4つ以上必要です(俺的にMUST)

ほら(俺的)DTDを見ると
<!ELEMENT HEAD - -  (LINK)++++>

それって結局ひとつじゃね？

確かにその機能はOpera使うとありがたみがわかるよな。

全ページStrictに書き換えたらアクセス数が倍に増えました

手間も倍かかりました。

プライスレス

でもコンテンツが糞なので収益には結びつきませんでしたorz
ｵﾌﾄﾋﾟｽﾏｿ

俺も倍に増えました！




1hit/dayから2hit/dayに・・・

全米が炊いた！

次世代HTML規格はHTML5? - WHAT WGからW3Cへ熱烈ラブコール
http://journal.mycom.co.jp/articles/2007/04/12/html5/index.html

Apple、Mozilla Foundation、Opera Softwareの関係者は9日(米国時間)、W3C HTML Working Groupに
対して「Proposal to Adopt HTML5」と題したメールを送信した。これは次期HTML標準の策定開始を
打診するもので、その足掛りとしてHTML5を使ってはどうかと提案している。内容は、W3Cが公開して
いるメーリングリストのアーカイブで確認できる。

HTML5は、ブラウザベンダーらによって構成される団体「Web Hypertext Application Technology
Working Group(WHAT WG)」において策定が進められている規格。同グループで策定している「Web
Applications 1.0」や「Web Forms 2.0」といった規格をベースにしたもので、HTML4との互換性を保
ちつつ、新しい機能を採り入れたものとなる。

HTML4の普及後、W3Cが推奨する新標準としてXHTMLがリリースされたが、現在のところ、広く普及す
るまでには至っていない。原因は後方互換性の欠如にあるという見方が一般的だ。そこで、後方互換
性を確保しつつ、新しい機能を取り込むための規格として策定されているものがHTML5だ。

同メールにおいて関係者は連名で次の提案を行っている。
W3C HTML Working Groupが取り組む次世代HTML規格のベースとしてWHAT WGが策定している
HTML5を採用することW3Cの次世代HTML仕様の名前を正式に「HTML5」と命名すること
WHAT WGの検討内容を有効に活用するために、Ian Hickson氏をHTML5仕様の策定担当者にすること
新たなHTML規格がリリースされれば、各種ソフトウェアにおいてレビューや互換性のチェックが必要
になる。すでに各ブラウザでHTML5の検証作業が進められていることから、HTML5を次世代HTML規格の
ベースとして採用することは十分妥当な選択肢だと言えそうだ。

W3C HTML Working Groupが同提案を受け入れた場合、Apple、Mozilla Foundation、Opera Software
は、HTML5仕様に対するW3Cの「non-exclusive copyright assignment」に合意するとしている。


次世代HTML規格はHTML5で確定か。

>>221
HTML 4.01 と HTML 5 の違いを誰かまとめてくれー。
ググっても日本語だとほとんど情報なし・・・。

4.01を使い続ければおｋ

canvasとかってHTML5じゃなかったっけ？

xhtmlでいいだろ…
5マジでイラネ

だよねえ

msがapplication/xhtml+xmlに対応しないからだろ。
あのままじゃ永遠にアップデートできないもんな。

互換性をどんどん切り捨てて行くXHTMLの方針に違和感を感じて
HTML4.01Strictを使い続けていた俺に取っては、HTML5は歓迎だな。

>>222
5はノートすら出てないんだが。
オカ板の住人にでも頼め。

>>227
text/htmlとtext/xmlで何の問題も無かったし、今でも何の問題も無い。
どうしても必要なら、慣例通りに text/html; type=XHTML1.0 のようにすれば良かっただけだ。
むしろ梯子を外されたマイクロソフトが悪意に満ちたapplication/xhtml+xmlという特殊な記法に合わせる必要など全く無い。

ブログが全盛の今時、仕様を気にしている奴がいるのか?
そういうのは、ベンダーが従うべきであって、
個人なら従わざる奴は、消えてく運命なんだよ。

過去互換ってのも、もはや神話だ。
余程の堅物(←よい意味で)で無ければ、URIの一意性が守られている所など無いぞ。

全盛ってことは今後は廃れる
そろそろ気にし始めた方がいいぞ

>>231
過去互換が重要なのは、古いHTMLを新しい環境で閲覧する場合より、
新しいHTMLを古い環境で閲覧する場合に問題になるんだと思うが。
だから、URI一意性の問題とかとは関係ない。

>>233
俺に言わせば、
URIの一意性は、HTML類いの互換性より重要なんだけどなあ。
電話が通じなくばFAXでも良い、
でも、連絡先そのものが変更されれば、連絡も出来んよ。

>>234
それは一理あるな。
しかし受話器からFAXのピーピー音を聞いてもなんにもわからん。

確かに、たまに電話にFAXがかかってくるよな。

>>234
いや、URIの一意性が重要でないと言ってるんじゃなくて、HTMLの互換性と
URI一意性は別次元の話だから関係ないと言いたかったんだ。

古いページを新しい環境で見る場合は、URI一意性と、UAの互換性の問題が重要。
逆に、新しいページを古い環境で見る場合は、HTMLの互換性の問題が重要。

UAの互換性とHTMLの互換性はレベルが違う話だし、URI一意性は全く別の話だ。

>>230
どの辺が悪意に満ちてるのか詳しく。
w3cは将来的に柔軟に対応できるXMLに移行していこうとしてると思ってたんだが。

書いてあるじゃん。字が読めないのか？

>>239
俺もわからない

application/xhtml+xmlは妥当だと思うけどな(特殊でも何でもないし)
text/xmlだと汎用すぎるし
text/htmlのままでいくとなると"X"HTMLである理由がない

俺は自分のところで XHTML 1.1 を採用しているのもあるが、XML ベースのほうが将来性あっていいよなあ……と思ってみたりする。
MIME タイプの問題は、text/html が絶対に禁止されているわけじゃなく、どうしてもそれしか方法がないなら使ってもいいわけだし。

というか URI の普遍性を確保する努力ぐらいしろよ、と。

そもそも、SGMLは規格が重すぎて大変だからXMLに移行しよう、という話
だったと思うが、その後、XMLの方もどんどん複雑になっていったので、
本当に当初の目的が達成されたのかどうか。

ここらで yhtml へ移行しようか。

>>241
> というか URI の普遍性を確保する努力ぐらいしろよ、と。
どういうところで大事になってくるの？

>>244
ttp://www.kanzaki.com/docs/Style/URI.html

>>245
ごめん、「この話のどこで」って意味で言った


URI永続性は、WWWを巨大な情報の蓄積所と見立てたときに
URI永続性がないと資料の散逸が生じて機能を大きく損なう、
ってのが本質的に重要なところだと思う。

だから、そういう精神無しに「リンク切れが不便だなあ」とかの
単なる利便性を主張の拠り所にする場合は、生じるコストや
制約とのトレードオフの問題に過ぎないと思う。
つまり「どんなときも最大限守るべき性質」というものじゃない。


個人的には、アーカイブはアーカイブ、生きたネットワークは生きたネットワーク、
別のものとしてやっていくほうが全体的に幸せなんじゃないかと思う。

HTML5ってまさかSGMLなのか？

>>247
おまえ死ねよ

結局、XMLの方が将来性があるなんてのは妄想に過ぎないってこった。
XMLは単なるSGMLのサブセット。すべてはSGMLの手の平の上だ。

>　XMLはSGMLのサブセットだと言われるが、これはSGMLがフルセットで、XMLがその機能限定版という意味ではない。
>XMLの開発当初、XML専用の処理ソフトが何もないため、SGML用のソフトを通すことができるよう、SGMLのサブセットの形に文法が定められたと言うことである。
>つまり文法面でサブセットになっているだけで、機能面ではSGMLに存在しないものがXMLで規定されているものも多い。
>そのため、XMLはSGMLを置き換える新世代の言語と見るのが正しく、SGMLは順次XMLによって置き換えられ消滅していくことが予想される。

>>250
そうなればいいんだけどなあ。

普通に考えてSGMLよりXMLの方が合理的で将来性あるだろ…
例えば空要素とか。

情報学の分野で10年近くも経過してまだ将来性があるとかないとかが口から出るということは、終わってるんだよ。
10年近く経っても有効な利用はフィードとXSLTだけに限定されているし、
XHTMLなんかは完全に矮小化された解釈で利用されているし、
各種設定ファイルやデータ授受ファイルとして利用されても、どれもが他のフラットな設定ファイル形式で置き換えられるほど無意味な使われ方をしている
――何が将来性だ、ばか、永久に言ってろ。

エンタープライズ系だといやになるほど使われてるけど。

>>253
将来性＝今はだめだが、将来は良くなる
ではなくて、
将来性＝将来にわたって存続可能である
ていう意味だと思うんだが。

じゃ、XMLの代わりになる良いフォーマットはあるのかい？
SGML(笑)かい？

text/plain 系？

>>255
将来にわたって存続可能


なら紙媒体にはかなわない。

text/paper

toilet/paper
application/x-shockwave-flush

text/plane

　　　　　　　　　　　　　 　 　 　 　i|　　 　 .i
　　　　　　　　　　　　 　 　 　 　 | | 　 　 .||
　　　　　　　　　　　　 　______＿,| .|＿,,___!.|、
　　　 __ 　　　　　　　　　＼　 /|///　/　|i!'￣ﾞﾞﾞ',''
　 　 ﾞ' - , _￣ ﾞ" ''' ''　─;-／_, ./ 　/__ﾞ., -;;:''_________＿＿＿＿＿
　　　　　　　"''.‐- ,,, ／　 ./;:/ノ,. 　/　/ ＼＿＿＿___,,,,,, 　--‐‐‐'ﾞ
　- - -　 -　-　-　 -'!i,　/;;'./￣)　/;';/.,／'ﾞ-　-　 - 　- -　-　- - -
　　　　　　　　　　　　　ﾞ‐-./:::: / /--ﾞ　　　　　　　　　　　+
　　　‐　-　;　. -‐　_　‐　./::::;/./　　 ;;　　　　‐ -‐　_-
　　　　　　;　　.　　　.　　/⌒ /　　　　　　　+
　　　　　+　 .‐　　.　'　 /　 ./　　　　　　;　　-　　;　‐　　　_-
　　　　　　,　　　　　 　 |.／　　　　　‐　　　ﾞ
　　　　_＿＿＿＿＿＿ﾞ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　／／／／／／／／／／／／／／／／／／／／／／／

昔はこれで連絡取りあってたよな
暗号化とかかけてないから情報筒抜けだったけどなｗ



paper/plane

>>259
flushって…

おまいら、知ってたか？　MIMEタイプって転送媒体には依存しないらしいぞ。
だから、ケーブルで転送しても、電波でも、紙でも、MIMEタイプは変わら
ないんだ。paperなんて、いちいち宣言しなくてもいいらしいぞ。

>>253
頭悪そうな書き込みだな。

>>262
ジョークに解説が要るならロムってろ

application/xhtml+svg+mathml+and+everything

ストリクタのジョークは寒いですね。

調べたんですね
乙です

とりあえずこれならどんなタイプでも大丈夫だろ


郵便/定形外

だから、MIMEタイプは転送媒体に依存しないと何度言ったら…

それ以前に…

>>265
×flush
○flash
ってことだろ？

>>272
スレ違い

http://pc11.2ch.net/test/read.cgi/hp/1145956119/

>>272
toiletに掛かってるんだとおも

うん、だからflushをただのスペルミスだと思ってる時点でセンスないんだ。絶望的に。

↓そろそろHTML5について検討しようぜ

↓
>>221に戻る

XHTMLでおｋ

>>269
定型を含まないから駄目じゃね？
実際に送れるかどうかは別として、ストリクタなんだから仕様に忠実じゃないといけないだろうしｗ

文章中に条文が出てくるときはどのようにマークアップするのが適切なんだろう？
例えば

表現の自由は憲法に規定されています。
第十九条 　思想及び良心の自由は、これを侵してはならない。
しかしこれが個人間の争いに直接適用されることはありません。

っていう文章があったとして、その
第十九条 　思想及び良心の自由は、これを侵してはならない。
の部分をどういう風にするべきなのか。
hとp？dl？
最初は条名を、例えばh5、文をpでくくればいいかな、と思ったんだけど
そうするとh1の次にh5が来るようなこともあるし、

（成年）
第四条 　年齢二十歳をもって、成年とする。

みたいな条文だと見出しは「（成年）」になる。
思想及び〜は第十九条の定義でもないしなあ、とか考えてたらどうしていいかわからんようになった。
ちなみに憲法十九条は法令中には「思想及び良心の自由」みたいな見出しはついとりません。

>>280
文書中に見出しが挟まるようにはならない。
個人的には dl でマーク付けするね。

<p>表現の自由は憲法に規定されています。</p>
<dl><dt>第十九条</dt>　<dd>思想及び良心の自由は、これを侵してはならない。</dd></dl>
<p>しかしこれが個人間の争いに直接適用されることはありません。 </p>

こうだな。
下の例では場合に合わせたレベルの hn でもいいんじゃなかろうか。

dlはそういう風に使ってもいいのか
そうするよ、thx
憲法と裁判所法改正して条名の前に見出し付けて欲しいなあ

引用だからblockquote要るんでないの？

>>283
あ、要るね。

<blockquote><dl><dt /><dd /></dl></blockquote>

こうか。

スレ違いかも知れないけど

index.html

って変更してる？
ストリクタ的にはどうよ？
慣例？

索引ってなーおい

>>285
確かにスレ違いではあるが

URLってのは、言ってしまえば住所だ。
例えば、住所に「富士見」って入っていても、
富士山が見えるか見えないかは関係がない。
だから、index.htmlだからって「牽引」である必要もない。

まあ、URLでそれが何を示しているか分かる方が良いに越したことはないが。

>URLってのは、言ってしまえば住所だ。
>例えば、住所に「富士見」って入っていても、
>富士山が見えるか見えないかは関係がない。
>だから、index.htmlだからって「牽引」である必要もない。

うーん

ディレクトリマップってのは、とくに意味がなくて
名前も階層も、人間よりって事？

HTML文書はlinkのみで構造が示される？

いやすまない、勉強不足だな

レスサンクス

>ディレクトリマップってのは、とくに意味がなくて
>名前も階層も、人間よりって事？

機械的に解釈できるようにする、というガイドラインはないし、その傾向もない。

>>154あたりの話だな

URIは機械的に処理される名前であって、それ自体は構造とは何の関係もないが、
一応は、サイト構造に即した名前を付ける方が望ましいんじゃないかな。
class名とかと同じで（これも機械的に処理されるだけの名前だが、構造を表す
名前の方が望ましいだろうから）。

ただ、index.html は「索引」と訳すより「目録」と訳す方が由来に即してるような
気がするな。それ以下のページの目録ってことね。

>>286
> 「牽引」である必要もない。

牽引じゃなくて索引だろ？

>>287

まあ、そう言うことだ。
恒久的なURLは、非常に難しいぞ。
「富士見」ってのも、昔、そこから富士山が見えたから名こそ付けたんだと思おうよ。
でも、見えなくなったからって、住所名称を気軽に変えては駄目だ。

縦しんば変えるなら、その「富士見」住所を充分単保しなきぇら成らないのだけど、
今のWEBじゃ、その担保も成ってないからな(もの凄く久しぶりのブックマークを訊ねたらサイト自体が無いってケースは、結構ある)。
こういうものは、何より「永続性」は重要だ。
最初に設定した「ディレクトリマップ」が納得いかないなら、
その変更による障害を完全に対処せよ。


ちなみに、
漏れは時間軸、西暦／月での管理をしている。
恐らく、今後100年は生き続けるフォーマット。

>>292
> こういうものは、何より「永続性」は重要だ。
> その変更による障害を完全に対処せよ。
>246で書いたけど、そこまでのレベルで重要なものではなくて、
諸々の事情と天秤にかけられるべき問題だと思うよ。

>241の言うような「努力ぐらいしろ」ってくらいなら適切なアドバイス
だと思うけど、>292レベルまでいくのは盲目だと思う。
　> 漏れは時間軸、西暦／月での管理をしている。
を厳密にやるなら、トップページについてもその月ごとの適切な(外部)URLへ
リダイレクトしてやらなきゃいけないと思うけど、それは不合理だし。
(内部パスについてはどうにでもなるだろうけど。)

>>293
要は、今ある慣習を習うか、
それとも100年度に尊ばれる慣習を習うかの、差だと思う。

自分は「トップページ」と一度銘打ったならば、
金輪際、自分から変える積りは無い。
それが、../1998/homepage.html、という名前でもじゃ。

一番困るのは、上記のURl等を勝手に変えられて、
その後の処理も放棄したものだ。

「301 Moved Permanently」で転送すればいいだけじゃないのか？
別に本体をそこに置き続ける必要はないと思うが。

俺はサイトなんか生ものだし消えて何ぼだと思うわ。
必要な情報が絶えずそこにあるのは重要だけど、
それだけでもないと思う。

つか「トップページ」ってなんだ？

>>294
> それとも100年度に尊ばれる慣習を習うかの、差だと思う。
尊ばれるのが規定事項かのように言ってるけど
そうでもないよね。

> 自分は「トップページ」と一度銘打ったならば、
> 金輪際、自分から変える積りは無い。
> それが、../1998/homepage.html、という名前でもじゃ。
それは作成(or公開)日時で分類して、更新日時では分類しないってことだよね。

トップページというのは内容がそこそこ頻繁に変わるリソースの
例として出したんだけど、URLが同じでも内容が違っちゃったら
「特定のリソースを特定のURLで参照する」というURLの永続性は
保たれないよ。

あたりまえだけど、単にあるURLにリソースが存在すればいいわけじゃなくて、
あるURLとあるリソースとの対応が取れ続けてることに意味があるんだから。

Xanaduの世界へようこそ

Xanadu Scenario II

@Yoshio.Kiya@

も　っ　と　ス　ト　リ　ク　ト　に

web site が何なのか解らなくなりました

>>73

> 気になるなら全部で1ページにしちゃえば良いよ＾＾

上の<h1>談義についてだけど

ページを分割するのってさ、見栄えの要素は孕んでいない？

文ごとに改行したり、段落ごとに空行をもうけて字下げしたり、
章分け、ページ分けといった文章や文書に含まれる書式の問題

　文書の問題｜マークアップの問題｜見栄えの問題
というように捉えたときに、
文書の問題にあわせてマークアップを変更したり、
見栄えの問題にあわせてマークアップを変更したり、
というように、他の領域に問題を持ち込んじゃいけないよ、
という話がある。

「HTMLの見出しレベルが足りないからページ分けしよう」
「HTMLの見出しレベルが足りないからサイト名を見出しに
するのはやめよう」というのはそういう点でアウト
。マークアップの問題を文書の問題に持ち込んでるからね。


HTMLでよく言われるところの見栄えの問題じゃないよ。
それは見栄えをマークアップに持ち込むな、という話だから。
あのh1談義は、文書の問題とマークアップの問題に関する話にあたる。

>>305
> 文ごとに改行したり、段落ごとに空行をもうけて字下げしたり、
> 章分け、ページ分けといった文章や文書に含まれる書式の問題

文書の問題｜マークアップの問題｜見栄えの問題
↑
ページ分割はここの問題っていうのは解る
で
>>45が"<h1>諸説あり問題"を解りやすく書いてくれてるんだけど(これも文書の問題だよね？)

>>45
> こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので
> この部分だけを別ページに分離したい場合。
の動機は何？長くても良いんでは？

("見栄え"って言ったのが悪かったかな)
人間が文書を読む"閲覧性"を上げる為にページを分割するの？

1つの文が長過ぎてダラダラしている場合、推敲して文を2つに分けるというのは
よく行われることだよな。これはレイアウトなしの地の文でも起こることだから、
マークアップの問題でも見栄えの問題でもない。長いから分けるというのは自然だ。

また、それほど長くない文でも、ある言葉がどこまで掛かってるのかが分かりにくい
ような場合は文を分ける。これは1文内の論理階層が深すぎたということ。階層が
深いから分けるというのもまた、マークアップの問題でも見栄えの問題でもない。

ページ分割もこれと同じじゃないかな？　確かに「h6まで使い切った」というのは
マークアップの問題だが、そんなページはそもそも長すぎるか階層が深すぎるので、
マークアップと関係なしでも分けるべき状況に来ていると思う。

>>306
> の動機は何？長くても良いんでは？
> ("見栄え"って言ったのが悪かったかな)
> 人間が文書を読む"閲覧性"を上げる為にページを分割するの？
そうだろね。あとはファイル管理の都合とか。

で、それは「そういう文書が存在する」という前提部分の話だね。
それに対する適切なマークアップはどうなるか、という話をするための
前提について話してるわけだ。

>45は
　> 仕様書のどこを読んでもどちらが正解なんて答えは出てこないんだよ
って言ってる。つまり "この問題に関しては" HTML仕様じゃとくに規定してない、
ということだな。
別の言葉で言えば、この問題はマークアップの問題じゃない、ということ。

（HTML仕様や関連ガイドラインは、HTML文書としての文書の問題についても
触れている場合があるから、他の問題で「文書の問題だから関係ない」と
なるとは限らないことに注意）

304,306です
先にこれ


【00】 ストリクト・コンテンツ作成の視点・知識を持つ

【01】 コンテンツ(書籍,論文等)の解読
【02】 構造マークアップの付加 (HTML等)


<!--ここまでストリクト領域-->

<!--ここからスレ違い

【03】 UA(web browser等)での閲覧性・視認性を調整 (CSS等)

-->


もっと厳密なワークフローたのむ

304,306です

>>307

的確な論理の展開を持つコンテンツであるなら、
論理階層はどんなに深くても、文章はどんなに長くても、
同一コンテンツ内に必要だと思う

で
>>45
> こういう構造の文書で、「小見出し1-2」の節だけがやたらと長くなったので
> この部分だけを別ページに分離したい場合。

の"やたらと長くなったので"という理由に
誰もつっこまないのおかしいな、と思ったのよ

文章の重要度で、それを主題とした他のコンテンツとして
ページを分けるのなら解るけど

"閲覧性"や>>308の"ファイル管理の都合"でページを分ける
ってのは

【03】 UA(web browser等)での閲覧性・視認性を調整 (CSS等)

じゃない？
って主張です

>>310
長いということは、コンテンツ内で大きな部分を占めるということなん
だから、文章の重要度で分けるのと同じことじゃないのか？

それから、閲覧性の上昇をHTMLから分離するのもおかしいと思うぞ。例えば、
本文内に「まず第一に……、次に……」などと説明文で書くことも出来るが、
リストにすると閲覧性が上がる。でも、リストにすることはHTMLとして
間違っている訳ではない。

HTMLで見た目を記述しないようにすべきなのであって、閲覧性を上昇させる
ことをしてはならないのではないだろ。

リストにすると閲覧性が上がるｗ

リストにした方が読みやすい場合もあるわな

>>310
>305

でも>>311の言ってる「閲覧性」は『マークアップの問題じゃない』よね？

>>312
上がらないとでも言うのか？
閲覧性は視覚だけのものじゃないぞ。「閲覧性の高い構造」というものがある。

例えば、一段落が長すぎると趣旨がつかみにくくなるので、こういう場合は
段落を分けた方が閲覧性が上がる。これは視覚とは関係ない。

何段落も見出しが出てこない状態が続くと閲覧性が下がる。だから、章が
長過ぎる場合は節に分けると閲覧性が上がる。これも視覚とは関係ない。

ファイルに分ける話も同様。これらは文書構造を設計するということであって、
視覚を調節することではない。

>>314
そう。マークアップ以前の文書構造の問題だ。>>310 がマークアップ以後の
スタイルの問題ではないかと言ってたので、それへの反論。

結果論というか副産物というか。
リストの構造ならリストにする。パラグラフが連続するべくして連続するならいくらでも連続する。それだけのことじゃないのか。

310です

>>311
> それから、閲覧性の上昇をHTMLから分離するのもおかしいと思うぞ。例えば、
> 本文内に「まず第一に……、次に……」などと説明文で書くことも出来るが、
> リストにすると閲覧性が上がる。でも、リストにすることはHTMLとして
> 間違っている訳ではない。

>>312

>>313

>>315の「閲覧性の高い構造」の例え(ファイルに分ける話を除く)


>>310の"的確な論理の展開を持つコンテンツであるなら"の前提条件に、
目次や文章内でのリスト表記や
的確な章、節、段落の使い方等は
含まれていると考えていました
(>>314の指摘の通りです)

説明不足ですみませんでした

>>309の
【01】 コンテンツ(書籍,論文等)の解読
のコンテンツも同様です

310です

で、あくまで主題は"ページを分ける事"です

>>311
> 長いということは、コンテンツ内で大きな部分を占めるということなん
> だから、文章の重要度で分けるのと同じことじゃないのか？
必ずしもそうじゃないよね
冗長な文だってある
(まぁ的確な論理の展開を持つコンテンツにあるかはわからないけど)

本当に重要であるなら、別コンテンツとして作るべきだし

>>315
> ファイルに分ける話も同様。これらは文書構造を設計するということであって、
> 視覚を調節することではない。

すみません、ここが良く解らない
詳しく説明して貰っていいですか？

>>316
文書構造は最初から固定のものではないよ。

文章を書いた後に、推敲してより分かりやすい文に書き換えることは、
HTMLに限らず、よくあることだよな。その時、「ここはリストにした
方が分かりやすいな」とか「分けた方が分かりやすいな」って書き換える
ことも出てくるわな。

これは、マークアップの改変でも、スタイル調整でもない。文書構造自体を
変えたってことだ。「文字が大きい方が分かりやすいな」で書き換えるの
とは、変更のレベル（レイヤー）が違う。

「書きたいもの → 文書構造 → マークアップ → 装飾スタイル」という流れを
考えれば、「構造の改変」と「装飾の改変」は、まったく別レイヤーだ。

もちろん、「こんな装飾をしたいから構造を書き換える」などと、上記と
逆方向を行うのはストリクトではないかもしれんが、「長いから分割」など
というのは、上記の「書きたいもの → 文書構造」の部分で出てくる話だから
逆転ではない。長いというのは装飾と関係なしに長いんだし。

>>318
ってことで、ページ分割も「文書構造」レイヤーの話だろ、ってこと。

そもそも、「章が長いから節に分ける」が納得出来て、「ページが長い
から別ページに分ける」が納得出来ないというのは変な感じがするが。

「ページという概念がStrictでない」のならまだ納得できるけどな。

脳波自体でやりとりが出来れば良いんだけど、
人間は"言語"と言う外部媒体を用いてしか、コミュニティを保てない。
ならば、コミュニティを円滑に行う為には”言語”のルールが必要だ。
HTMLもそのルールの一種に過ぎない。

>>321
つ ttp://yuukiremix.s33.xrea.com/chirashi/

リンク形式でPrev,Next,Startがあるんだし、分割は構わんと思うよ。章なり節なりで切る話だけど。
源氏物語は一つの作品だ、と一つのHTML文書にするとなれば読む方はキツい。
日記なんてつながってるが、だからと言ってサイト開設から延々と一つのファイルにするのはどうかと。

olが付加する数字は単なる飾りじゃなくて文章上意味があるべきだと思うんだけど
何故、W3CはCSS任せにしたり、start、value属性を排除したりと、飾りとして扱っているんだろう。

飾りとして扱うならUAに表示を求めないで欲しいし
最初から表示するのが前提なら、その意味を汲んでくれと言いたい。
おかげで飾り込みで文章を書くというおかしなことをさせられている気分。

俺もそう思う。

作業中のHTML 5ではstartもvalueもあるね。
ttp://www.whatwg.org/specs/web-apps/current-work/multipage/section-lists0.html#the-ol

>>324
要は、順序という事が重要なんだろ。
ベクトルを持っているか持っていないか。

順序に意味があるのと数字に意味があるのは違うからね。
数字に意味がある時は数字書いて、リストマークはCSSで消してるけど。環境によってはダブるから実際ウザいんだろうなとは思う。

>>328
数字にも、アラビア数字・漢数字・ローマ数字等々あるから、
それは、いわゆる表示のレベルであって、
そのリストに、順序というベクトルがあるのかと言う問題。

仮にDOM的に扱おうとした時、
olとulは別の範疇と扱うだろう、ストリクターならそう考える。

「順序に意味がある」という話と
「（olにおいて）どの項目が何番目にあるか識別できるかどうかに意味がある」という話は
一緒にしない方がいいと思う

>>329
順序に意味があってさらに数字にも意味があるリストの場合の話しをしましたが？
オツムのベクトルは大丈夫？

>>330
”認識できる”と言うのが「目」なら、その通りだが、
ストリクター的にulとolを区別するなら、
olが含有するリストは、DOM(XPath)的に順序通りな事は明白。

>>332
ul内のliにしたってol内のliにしたって
「文書順」で順序が要素の出現順に固定されるんだから
どっちも「DOM(XPath)的に順序通り」だと思うけどなー

>>332
>olが含有するリストは、DOM(XPath)的に順序通り

だから混同してるってば。
startやvalueが必要っていうのは、項目が順序だてられているのは当然のこととして、
「どの項目の次にどの項目があるか」ということじゃなくて
「どの項目は何番目にあるとされるか」ということでしょ。

まあDOM的に取得する方法はいくらでもあるんだろうけども、
簡素化できるうえに論理的な属性の付加だったら願ったり叶ったりというか誰も困らないよね。

>>331
「数字にも意味があるリスト」と言うのが既に視覚的だと思う。
おそらく、文中においてその"数字"に言及するからこそ、
意味があると言っていると思うが(例えば「?@を参照」とか)、
HTMLにおいて意味付けは、全てマークアップにおいて付けるのが正当。

>>333
違うと思う。
少なくとも俺は
ulならばXPath的順序に従わなくとも加工しようと思うが、
olならば順序に従うし、それがリスト制作者の意図だ。

>>335
1、たまねぎ、にんじん、じゃがいもを用意します。
2、1で用意した材料をひとくち大に切ります。


おまえこれどうする？

>>336
2、先に用意した材料をひとくち大に切ります。

1. <span id="sozai">たまねぎ、にんじん、じゃがいも</span>を用意します。
2. <a href="#sozai">材料</a>をひとくち大に切ります。

参照の仕方ならいくらでもある

元を変えるなら、たまねぎ、にんじん、じゃがいもをリストにしろよｗ
半端だよな、あたまでっかち。

この場合、どの程度改変するかは大きな問題じゃないだろ。
336が意図しないやり方がありますよというだけで。頭固いなあ。

それの答えがspanなんだｗ
説得力ないね。

文章変えないならこうとか
<li id="xxの手順1">たまねぎ、にんじん、じゃがいもを用意します。</li>
<li><a href="#xxの手順1" title="手順1">1</a
>で用意した材料をひとくち大に切ります。</li>

説得力のない回答にすら気付けない341

>>341
んで、お前はどうするの？もちろん説得力のある答えを出してくれるんだよね？

>>341
説得力無いも、>>336のマークアップより、
>>338の方がよっほど良いと思うがな。

”1”って、たぶんに視覚的であっても、
聴覚の「いち」と「ワン(one)」では理解できないんだよ。

そんな表現方法を使うなら、アンカーを使ってくれた方が機械的には楽。

数字と数値は区別して考えないと、話がごっちゃになるぞ。

ローマ数字か算用数字かなどの違いは装飾的な違いだとしても、
1と2の違いは明らかにデータの違いじゃないのかって話だろ。
例えば、

<p>最初の3つは以下の順で出現します。</p>
<ol>
<li>ほげほげ</li>
<li>ふげふげ</li>
<li>へげへげ</li>
</ol>
<p>しかし、4つ目以降は以下のように系統が異なります。</p>
<ol start="4">
<li>ふんたらはんたら</li>
<li>へんたらほんたら</li>
</ol>

この start="4" は装飾なのか、って話じゃないのか？

>>345
>>336はマークアップしてないよ。
どうする？って話しなんだから。

何故参照の話に？
機械的に？>>345は機械なの？

>>335
>「数字にも意味があるリスト」と言うのが既に視覚的だと思う。
多くの人が1. 2. みたいなのを想定してるっぽいけど
例えば章の見出しをリストアップするとかでも同じ問題は起こると思う。

1. 第1章 王宮の戦士たち
2. 第2章 おてんば姫の冒険

この第1章とかもHTMLに任せるべきなのかな。
この場合は見栄えが悪いだけでさほど混乱しないけど、
第1章を1.と書かれると何だか分からなくなってしまう。

>>338
あくまでHTMLは文章をマークアップするためのものでRDFなんかとは別物と考えると
最低限、人間が読める(読み取れる)文章を書くことが大事なんじゃないかと思う。
文意までHTMLに任せてしまうのは行き過ぎなんじゃないかな。

今まで文章を追ってきたのにリンクをクリックして初めて
「あっ、この材料か」って言うんじゃ文章の意味というか流れが希薄になってしまう。

リンクを張ることで何に言及しているか、より具体的になるし情報も見つけ出しやすい。
だけど、リンクは日本語の代わりにはならないし、代わりにした時点で自然言語から外れると思うな。

>>346
それ眺めつつ考えてみたけど、HTMLではol(順序)と項目番号が本来別々の情報であって、
startとかがまさしく順序の表現(飾り)と番号を結びつける方法だった。
ところが飾りをHTMLから分離したために、文章として含まれるべき番号を関連付けられなくなってしまった。
それなのに依然、olが順序の表現に番号という手段を用いていることで
好ましくない状況になっている・・・って事なのかな。

>「あっ、この材料か」って言うんじゃ文章の意味というか流れが希薄になってしまう。

アンカーテキストを「先に用意した材料」でも何でも置きかえればいいじゃないか。
もうちょっと柔軟な頭持ったらどうなのよ。

例の場合だけを言っているんなら、先に用意した材料なんて冗長に書く必要は無いでしょ。
むしろ例の通り材料って書けば済むと思うんだけど。

材料だっていろいろあるし、複数の工程で下ごしらえされて用意される。
アンカーのテキストでリンク先の情報を示そうとした場合、冗長になる可能性が大いにある。
だから、通常レシピでは1で用意した〜とか説明されるんじゃないの？

人間は、文章を読む過程で1の工程を覚えているけど
1つ目の工程で用意した材料にsozaiと言うIDが振られていて
リンクがそれを示しているってことはリンクをたどらなければ分からない。

リストにおける項目番号の意味
　a. 順序付け
　b. 項目名

OL要素ではb.の意味づけがなされないので、
項目番号を項目名として用いている文章においては、
リストの項目名はOL要素のマークアップによっては置き換えられない。

項目番号が項目名として参照されないリストについては、
OL要素によりマークアップすることで、その項目番号の
意味を落とさず表現できる。
そのため、項目番号はOL要素のマークアップにより置き換えられる。

>>352
いや、>>346 のような例を考えると、各項目が持っている意味上の番号は、
その番号が参照されるどうかとは無関係に存在し得ると思うが。

あと、ベストテンなどで10位からカウントダウンするとか、逆順になるような
リストも考えないと。

そもそも数字とかアルファベットという言語に依存する状況がダメってだけなんじゃ？
意味的な順番が大事で、それを表現する為の数字なだけであって、
それが漢数字でもいいってだけだから、見た目って事になるんだろう。

まあhtmlをアルファベットで記述してる時点で現実的ではないけどｗ

>>353
> その番号が参照されるどうかとは無関係に存在し得ると思うが。
言われてみればそうだな。
>352とは別に、>346のいうリストの開始番号とか、>353のいう
例についても、HTMLで意味を担う範疇じゃない部分があるね。

>328のいうところの、
数字に意味がある、というような話に近いのが>336,349,352、
順序に意味がある、というような話に近いのが>346,353、
という感じか。

>>354
やっぱり、数字と数値をごっちゃにすると話がややこしくなるな。
確かに、数字（数を表すための文字）は言語に依存するが、数値（その値）は普遍だ。
つまり、type属性は装飾でいいが、value属性はデータじゃないのかって話になる。

>>353
>あと、ベストテンなどで10位からカウントダウンするとか、逆順になるような
>リストも考えないと。

「10位〜4位のリスト」を考えると、リストの順序とstart属性的なものが必要になるな。

問題は数字にも意味がある場合に、
現状を踏まえて、どうしたらいいかってことだよね。

1. olでマークアップ。マーカーの数字を意味のあるものとして使う。
　　問題点：マーカーは飾りでは？value属性などは廃止。
2. olでマークアップ。数字は別に書いて、マーカーをCSSで消す。
　　問題点：CSSを当てないと数字がダブってしまう可能性が。
3. ulでマークアップ。数字は別に書く。
　　問題点：順序の意味付けが出来ない。
4. dtに数字、ddに内容を書く。
　　問題点：3と同じ。そもそも数字→内容という意味付けが妥当なのか。

ざっと思いつくのは、こんなところかね。

でも、よく考えるとdlで会話ログなんて例もあるわけで
4でも順序の意味付けは出来ているとみなせるんだろうか。

>>281
で数字、内容ってやってるけどあれは別物？

別じゃないよ。4は、まんま>>281の形だね。
>>281も問題なさそうだし、数字に意味がある場合はdl使っておくのがベストなのかな。

それじゃあ、OL要素って、
「順序はあるが何番目であるかには意味がない」
という場合にしか使えないってことか？
あまり使い道のない要素だな。

>>361
それぞれの項目には順序付けができるが、項目間の差異が一定とも言えん

警視庁クオリティに驚愕した
ttp://www.npa.go.jp/safetylife/

ttp://www.npa.go.jp/safetylife/chiiki2/KaiseiIsitsubutsuhouTop.files/slide0001.htm を HTML4.01 Transitional としてチェックしました。
523個のエラーがありました。このHTMLは -1083点です。タグが 18種類 119組使われています。文字コードは Shift JIS のようです。

>>363
オランダじゃ無いんだからそんなもんでしょ

ピーポ君のページでも見て絶望しておれ
ttp://www.keishicho.metro.tokyo.jp/sikumi/pipo/pipo.htm

パンくずリストをマークアップするとき、olは適当ですか？

>>365
順番に意味が有るならいいんじゃないの

>>366
どうもありがとうございます。
パンくずリストは順番と言うよりも階層を表しているような気がするので、少し悩んでいました。

>>367
改装なら入れ子。

その階層へのルートを表したリストじゃないかな。
階層そのものを表現しているわけじゃないと思う。

>>368-369
個人的に入れ子だと無駄にくくりまくっている（実際は無駄ではありませんが）ように感じて避けたいと思っていました。
正直言うと自分の自己満足を正統化したかっただけなのですが、
結果的にリストで良いという意見をもらえたので満足しました。

あなたは正直者ですね
ほうびに金のDIVと銀のSPANをあげましょう

いいえ、自分は正直者ではありません。

それでは銅のdlをあげましょう

せっかくだから俺はこの赤いtableを選ぶぜ

今更menu要素をどうしろと？
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-command.html#menu

<ul class="menu"> より <menu> の方が好ましかろう

whatwg熱いなあ。
毎日のようにDraftが書き換わって行く。

自分はvar要素を

<p>ユーザー名を指定してSSHでログインするには
<kbd>ssh <var>username</var>@example.com</kbd>
と入力します。</p>

こんな風に使っているんだけど、これってStrict的にあり？

むしろ推奨

<style>
.red { color:#f00 }
.bold { font-weight:bold }
</style>
<p class="red bold">注意：〜〜</p>

こういう装飾のしかたってHTMLの志向的に間違ってるのかな

お前がここに来たことが間違い

>>380
class="attention" にするべきだろうね

>>380
それじゃ、fontやb使うのとなんら変わらないよ。
HTMLでなんなのか規定されてるだけ、まだfontとかの方がマシかもしれない。

見た目を変えたくなったら片っ端からHTMLを直さないといけないし
そういう意味でもCSSのメリット半減かと。

でも現実問題HTMLいじらずcss変更だけで済むことってまず無い

それは設計段階の詰めが甘い

つか現実問題どうのこうのはスレ違い

>>380
未だにこんな化石があるとは思わなかった

>>384
おじいちゃんの孫がそんなデザインなんかするなって言ってたよ

そこが技術のある人とない人の差なのかもね。

わかると思うけど
>>387は>>385へのレス

アンカーミス
>>385 ×
>>384 ○

いや、技術云々じゃなくて、蔵の要求が体裁変更のみじゃ絶対に終わらないってこと
この要素加えてとかその他諸々HTMLレベルでの変更がもれなく付いてくる

>>390
まったくのスレ違い。
馬鹿な蔵から貪るくせに。

>>384を見て仕事限定の話だなんて思う人は居ないと思うよ。
少なくともこっちの現実では、デザイン変更だけでHTMLをいじる事なんてほとんど無いし。

いや、待て。
>>380 の「red bold」とは、ずうずうしい(bold)左翼(red)に対する注意
かもしれんぞ。

>>393
ならstrongだ

単語の意味はどこかで定義されたもんじゃないんだから
作った人がredとかboldに意味を与えたつもりになっていればそれでいいだろう

意味というか単に変数として捉えればいいんじゃないかな
idは単一の値(要素)を持つ、classは配列のように複数の値(要素)を持つような

名前付けに失敗した奴は後で困ると

HTMLの仕様ではclass属性値の単語がもつ自然言語的意味なんてどうでもいい
色指定きめうちというのがStrict精神的にはアウト

.red { color:#00f }

CSSで文字を赤く表示してみるサンプルとかだったら
<span class="red">赤い文字</span>
ってのもありかなと思う。

その手の話は393で既出。

>>399
それこそ意味を限定しない hoge とかを使うべきで
名前自体が色を連想させる red はまずいだろ

サンプルならexampleとかsampleとかで良いんでない？

>>399
表示方法に依存する意味付けって何？

色を連想させたらダメってアホかwww
「divはdiv厨が悪用するものだから使っちゃダメ」
というのと同程度のアホさ加減

>>399
もしredクラスを「赤く装飾する」というつもりで指定するなら、
どっちにしろダメ。
これは、たとえば「字のサイズを3emにするために
"title"というクラスを指定する」というのがStrict精神的に
ダメなのと同様の話。

"赤い文字"を意味するテキストにそれを適切に表すスタイルを
適用したいというStrict精神的にまっとうな意図があるならOK。
（そのつもりなら、分かりやすさの点から言って、クラス名は
redtextとかした方が好ましい気がするが。）

この場合、実際に#FF0000で色付けするか、それとも
"#FF0000"という文字をテキストの後ろに生成するか、
というように、赤色の表し方をスタイルシート側にゆだねることになる。

言いたいことはわかるが言ってることはわかりにくい

>>404
つかおまえがダメ。
強調のフレーズを赤く装飾したいならアリ。
引用部を区別する為になんらかの装飾したいならアリ。

＞"赤い文字"を意味するテキストにそれを適切に表すスタイルを適用したいというStrict精神的にまっとうな意図があるならOK。

どこがまっとうなんだ？赤い文字を意味するテキストってなんのこっちゃ？バカか。

＞これは、たとえば「字のサイズを3emにするために"title"というクラスを指定する」というのがStrict精神的にダメなのと同様の話。

違うだろｗｗｗ
"title"ってクラス名がマズいのはもっと手前の話しだろ。

クラス名がまずい、まずくないのは人間による邪推があるから。
クラス名自体にまずいまずくないはない。ただの文字列なわけで。
「おそらくhn要素で表すべきものをp class="title"としている」のはまずい。
実際問題上記のような（またはそれに類似する）状況でないのなら、クラス名がtitleでもなんら問題はない。

自分は最初
<span style="color:red">赤い文字のサンプル</span>
とかやってたんだけど、クラスで装飾することにして
<span class="red">赤い文字のサンプル</span>
に変更した。
<span class="sample1">赤い文字のサンプル</span>
にするのも考えたけど、見た目を変更するためにクラス名をつけることには変
わりはないのだから、それなら「red」とか「bgblue」とか具体的な名前のほ
うがいいんじゃないかと。
表現したい意味内容が見た目と一致している場合に、クラスを見た目に関する
名前にする他に、もっといい方法があるといいんだけどね。

>見た目を変更するためにクラス名をつける

まずこの行為がStrict的でないし、

>表現したい意味内容が見た目と一致している

これが自分の環境や感覚に依存していると自覚するべき。

>>409
ってことはCSSの表示例とかは画像にするしかない？

初心者スレはここですか？

>>407
>>実際問題上記のような（またはそれに類似する）状況でないのなら、クラス名がtitleでもなんら問題はない。

それの具体例を教えて下さい。

>>404
＞"赤い文字"を意味するテキストにそれを適切に表すスタイルを
適用したいというStrict精神的にまっとうな意図があるならOK。


むしろいさぎよくfontにしなさい

>>408
意味上の赤色と、出力媒体に対する赤色指定は区別しな。
別のものであって、一致なんてことはない。

白黒印刷媒体などで、「赤色の文字」を意味するところに
color:redとする代わりに404でいうような手段をとるように
変更することを考えてみそ。

「赤色の文字」であるテキストを装飾するためにredtextと指定しているなら、
redtextクラスの要素の表示を、スタイルシート上で印刷メディア時に"#FF0000"と
生成するように変更すればいい。
これは装飾がちゃんと分離できている例。

しかし、もしredクラスが「文字を赤色に装飾して表示する」という意図の
クラスだったら、「赤色という文字色を文字の後ろに表示する」という、
別の意図のクラスにHTML上で指定しなおさなければならない。
これは装飾が分離できてない例。

>>408
見た目を変更するためにクラス名をつけることには変わりはないのだから

うん。
で、見た目を変更する為にSPANてのがそもそもおかしいわけですよ。

テストの赤点や経理の赤字を class="red" として赤で表示するのは問題ないと
思う。別の装飾もあり得る中、たまたまクラス名と装飾が一致しているだけだと
考えられるから。これらは赤で書くのが一般的だが必須ではない。だから、
装飾方法を変えたとしても、クラス名がおかしくならない。

色彩学に関するページで、赤色に関する説明をしている所を赤系の色で表示したい
という場合も class="red" でいいと思う。これも実際に赤系の色で装飾しなければ
ならないわけではなく、装飾が変わってもクラス名がおかしくならない。

内容自体に色が関係している場合は、見た目だけのクラス名と言えないと思う。

ここまでの話をHTML+CSSでまとめると

<h3>第3話 - やる男の策略</h3>
<p class="red speech">っく、ここまでか。</p>
<p class="yaruman speech">「ここまでか」　だっておwwwwwww</p>
<p class="yellow speech">ふふ、こんなこともあろ(ry</p>

.speech:before {content: "「";} .speech:after {content: "」";}
.red:before [content: "レッド:";}.yellow:before [content: "イェロー:";}.yaruman:before [content: "やる男:";}
red {color: #F00; background-color: inherit;}yellow {color: #FF0; background-color: inherit;}yaruman {color: #583; background-color: inherit;}
ってことだな？

>>416
> 赤系の色で表示したいという場合も class="red" でいい
redは「赤系の色で表示する」ものという意図で指定してるんでしょ？
なら、後で「赤系以外の色で表示する」というつもりに変えたなら、
それを示す別のクラスに指定しなおさなきゃ、思ってることと
やってることが違うじゃん。

> これも実際に赤系の色で装飾しなければならないわけではなく
と言ってredクラスの文字色を変更するなら、
そもそもredクラスが「赤系の色で表示する」クラスなはずがないじゃん。

クラス名は本質じゃなくて、大事なのは意図だよ。
「赤系の色で表示する」なんていう意図でクラスを指定するような方針だと、
装飾を変更したいときには、
「ここは表示を指定するわけじゃない、ということにしよう」となってその方針が破綻するか、
「別の色で表示する」というクラスに指定を変更することになり装飾の分離が損なわれるか、
のどっちか。


後付けの言い訳で「いや、このクラス名はおかしくないんだ」と言い張るくらいなら、
破綻するような方針を最初からとるな、ということだよ。
「〜の色で表示する」とかいう意図でクラスを指定するな、ということ。

>>418
いや、赤系の色で表示しようと思ったから class="red"

ではない。（これだと表示を表したクラス名だから駄目）

赤色に関する話題を書いている部分だから class="red"
赤色に関する話題を書いているから赤系の色で表示しよう

と、たまたま両者が一致する場合、class="red" は表示ではなく、
内容を指しているではないかという話。

>後で「赤系以外の色で表示する」というつもりに変えたなら、
>それを示す別のクラスに指定しなおさなきゃ

すげえ頭悪いな

>>419
> （これだと表示を表したクラス名だから駄目）
そもそもクラス名に直接の制約はないんだから、
赤色表示を意図してredと命名した場合に問題なのは、
赤色表示を指すredというクラス名自体じゃないでしょ。

逆を言えば、そのクラスを指定する意図がダメなら、
そこでクラス名をredtextとかtext1とかしてもダメ、ということ。

だから、表示を表したクラス名だから駄目、とか、
クラス名が表示色の意味を指してるわけじゃないからＯＫ、とか
いう論理はダメだよ。


クラス名が色の名前だからといって一律禁止というのは間違いだ、
適切なクラスの使い方でもredという命名をする場合はある、
という話の主旨には同意するけど。
そのへん>416を誤解してたのは>419で分かった。

お前ら馬鹿だな。
もう面倒だから好きな食べ物を羅列してclassにつけてけば良いよ。
俺は親子丼は譲れないからclass="oyakodon"は他のやつは使うなよ。

>>412
私がよく使うのは、文中やリストや表に出てくる、
書籍や音楽のタイトルが、class="title"で、
著者が class="author" 、アーティスト名が class="artist"

>>423
ないね
そんなんだと思ったわ

なにが「ない」？

そもそもclass="title"の話はクラス名の問題じゃなくて、
考え方として、見た目を変えるためにクラスをつけるという行為が「Strictな精神」といえないという話だろ。

>>425
話に参加した気になりたいだけの頭の弱い子が
へんな煽りをちょくちょく入れてるだけだから安心しろ。

要素名、属性名とタブっても問題ないと？

tabる？

>>423
class="author"なんて文書の著者みたいだけどな。

低レベルは昔からだよ。

>>421
クラス名の是非を言ってるんじゃなくて、そういうクラスを作ることの是非を
言ってるんじゃなかったのか？

もちろん、名が体を表しているのは前提だけど、そういうクラス名を付ける
ということは、そういうクラスを作るのと同じでしょ。だから、red は表示色を
指してるのか、赤色に関する内容を指しているのかが問題になる。

名（クラス名の意味）だけの問題ではなく体（何を指すクラスか）の問題なのは
言うまでもない。でも、名が体を表す命名をしてるなら、これらは同じこと。

>>431
> クラス名の是非を言ってるんじゃなくて、そういうクラスを作ることの是非を
> 言ってるんじゃなかったのか？
・クラス名が問題？
　→redというクラス名でもOKな場合もある
・クラスを作ることが問題？
　→赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で
　　作られたクラスを指定する場合でも問題は変わらない
というのは今まで出た話。

悪いのは、特定の表示・装飾を目的としてHTML要素のクラス指定をすること。
クラス名が人間にとって表示色を指すもの(たとえばred)であっても、
赤色表示の意味であるとしてredクラスが作られていても、
それらはこの悪いことと一緒に表れやすい特徴の例でしかない。
これら特徴がなくとも悪いこともあるし、これら特徴があってもいいこともある。

何が悪いかを捉え違えている、ということを言ってるのよ。
「そういう特徴がある場合に、問題もある（ことがおおい）」というのと
「そういう特徴は問題だ」というのとは同じじゃないのよ。
　・クラス名が表示色を意味するものであること
　・ある表示色の装飾を意味するクラスを作ること
　・特定の表示・装飾を目的としてHTML要素のクラス指定をすること
それ自体が悪いことか否か、ということを考えるときこれらは同じものじゃない。
(＝同じとして一括していいか悪いか考えられるものではない)

>>432
つまり、きちんと構造を表したマークアップをし、構造を表したクラス名を
付けたとしても、その目的が特定の表示だったのなら悪いと言いたい訳か？

だとすれば、捉え違えてるのではなく、元々俺の考え方とは違うだけだよ。
どう思いながらマークアップしたかより、結果としてどういうマークアップが
されたのかが問題だと思う。UAにはその結果しか伝わらない訳だし、結果が
きちんと構造を表しているかだ。

>>432と>>433は討論しているが結果的に同じマークアップをしている予感。

一応、騙りじゃないと思ってレス
>>433
> どう思いながらマークアップしたかより、結果としてどういうマークアップが
> されたのかが問題だと思う。UAにはその結果しか伝わらない訳だし、結果が
> きちんと構造を表しているかだ。
　> だから、red は表示色を
　> 指してるのか、赤色に関する内容を指しているのかが問題になる。
言ってることちゃうやん。
UAにはr,e,dのアルファベットの並びしか伝わらんし、著者の意図するクラスの
意味なんてのも伝わらん。結果としてのスタイルシートしかね。

> 元々俺の考え方とは違うだけだよ。
その考えじゃ今話してるところのStrict精神話なんてものどころか、
そもそものHTML仕様からして守れないよ。
「それぞれ考え方が違うんだね」で済む話じゃなくて、
その考え方は単に間違いだと思う。

いくら文書を他人が見て「ああこれなら妥当だね」と思おうとも、
著者の意図と食い違うマークアップがされてるなら
それはHTML仕様と照らして問題なんだから。
仕様上妥当なマークアップがなされているか考えるのに著者の意図を
はずして考えるなんてのは成り立たない。(著者の意図によらない部分
だけを考えるのでは検証できない。)

マークアップは完全なる主観の元で行われるべきものだと考える

もう div と span だけ使って id も class も GUID 入れときゃいいよ

>>435
> 　> だから、red は表示色を
> 　> 指してるのか、赤色に関する内容を指しているのかが問題になる。

そのクラスは「表示色が赤い所」というグルーピングなのか、「赤色に関する
話題を書いた所」というグルーピングなのかという話だよ。言い方を変えると、
マークアップ結果として、そのクラスは、同じ構造をグループ化したものか、
同じ装飾をグループ化したものかということを問題にしている。

で、著者の意図した構造と食い違ってるのなら、結果としてきちんと構造を表して
ないんだから駄目だろ。

そうじゃなくて、…ある特定の表示をしたいと思う。そこで文書構造を考え直して、
構造化し直し、きちんと文書構造を記述したマークアップが出来た。これが悪か、
という話だよ。結果がきちんとStrictに構造化されたものが出来たのなら、最初の
動機なんていいじゃないかという話をしてるんだ。

>>438
> で、著者の意図した構造と食い違ってるのなら、結果としてきちんと構造を表して
> ないんだから駄目だろ。
それだから著者の意図も考えなきゃ駄目よ、って言ってるんだけど。

その辺はそっちも「クラス名がどういう意味を意図して書かれたか」とか
「クラスをどういうつもりで作ったか」とかが問題だって言ってるんだから
了承できると思うんだけど、何がひっかかってるんだろう？

> …ある特定の表示をしたいと思う。そこで文書構造を考え直して、
> 構造化し直し、きちんと文書構造を記述したマークアップが出来た。これが悪か、
> という話だよ。
あとから書き換えた構造がまともかどうかは別の話じゃん。
表示のために論理構造を書き直す羽目になる原因を作るのが悪いことで、
その悪いものとしてそちらが挙げてるものが間違ってるって話だよ。


「クラス名の意味がダメ」というのも「クラスを作った意図が駄目」というのも
表示のために論理構造を書き直す羽目になる原因とは一致しない。
「特定の表示のためにクラス指定をする」ということが原因よ。
　別の特定の表示をするために、クラス指定を変更するか
　特定の表示のためのクラス指定というのが破綻するか
なんだからね。（というのが要約かな）

もう全部XSLで書いて好きにすりゃいいんじゃね？

>>439
書き直す羽目になる原因が悪いというのなら、とことん細かくクラス指定すれば
いいという結論にならないか？　微細に渡り完全に細かくクラス指定していれば、
まず書き直す羽目にはならないわけだし。

で、「特定の表示のためにクラス指定をする」とは
　A.「特定の表示を表すクラスを作る」
　B.「特定の表示をしたいから（きちんとした構造の）クラスを作る」
のどちらとも解釈出来てしまって、俺はA.は駄目だがB.は良いのではないかと
言ってるんだが。

「きちんとした構造のマークアップ」自体、解は一つではないんだから、その解の
一つから別の一つに変更したい場合だってあるだろう。それが悪いことだとは
思わないし、その動機も関係ない。悪いのはきちんと構造が表せてなかった場合だ。

>>441
> 書き直す羽目になる原因が悪いというのなら、とことん細かくクラス指定すれば
> いいという結論にならないか？　微細に渡り完全に細かくクラス指定していれば、
> まず書き直す羽目にはならないわけだし。
たとえそうしても、特定の表示目的でクラス指定しようとすると、
　別の特定の表示をするために、クラス指定を変更するか
　特定の表示のためのクラス指定というのが破綻するか
になるよ。

「書きなおす羽目になる原因を作るのが悪いとすると、
現実的に無理なことが解決法になるから、原因とするのはおかしい」というようなことを
言いたいのかも知らんが、書きなおす羽目になる原因すべてに現状で満足な
解決法があるかどうかはまた別の話だよ。

だけど、その原因が取り除けるものなら、原因を作るのは悪いことだよね？
今回は、だから「特定の表示目的でクラス指定するな」となる。


> のどちらとも解釈出来てしまって
どちらも「特定の表示のためにクラス指定をする」という原因とは一致してないよ。
> 俺はA.は駄目だがB.は良いのではないかと言ってるんだが。
>432
　> ・クラスを作ることが問題？
　> 　→赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で
　> 　　作られたクラスを指定する場合でも問題は変わらない
一致しないことはいままで説明してきたんだけど、なんか反応してちょうだい。


> 一つから別の一つに変更したい場合だってあるだろう。それが悪いことだとは
表示のために論理構造を書き直す羽目になる原因を作るのが悪いことなんであって、
構造の変更一般が悪いことだなんて話はしてないよ。

＞表示のために論理構造を書き直す羽目になる原因

表示ってのは、論理構造の視覚化なんであってさ、
その視覚化という視点から、作っていたロジックの穴とかが
見えてくることがあるんだよ。そういうときは論理構造の見直しが必要になるの。

>>443
それは表示のために論理構造を書き直しているわけじゃなくて
論理構造のために論理構造を書き直してるんじゃないの？
表示によって気づかされた誤りだけれども、表示のために変えてるわけじゃない。

>>444
毒か威力零

>表示によって気づかされた誤り

なぜ表示から正確な論理的構造を読み取れると思い込んでいるのか

クソな論理構造としてマークアップしてあると、
いざ表示する段になって「あ、これ構造からして
くさってるわ。表示でどうにかなる問題じゃない」
って気づくことがある、ということだろう。

class="red"の何が悪い、という話とは関係ないけどな。

>>447
だからそれが思い込みなんだろ。
モダンブラウザがデフォルトで採用しているスタイルシートが、
いかにも文書を構造的に表しているかのように表示してるだけ。
そこから本質的に構造を読み取るのは意図的にでないと無理。

例えば、見出しから次の見出しまでの間をdivでくくってセクション構造を表す
というマークアップ方法がある。一方、見出しレベルだけで階層を表してdivは
一切使わないというマークアップ方法もある。一応、どちらも論理的なマーク
アップだよな。

今、後者のマークアップをしていたが、各セクションを枠で囲みたくなった
（特定の表示）。そこで前者のマークアップ方法に変更した。

この場合、書き直す羽目になった悪い原因とやらは何だ？　divでセクション構造を
記述してなかったことが悪いのか？　結局、その原因が悪いとすると、あらかじめ
出来るだけ細かくマークアップしておけという話にならないか？

>>448
視覚化した結果から分かる、じゃなくて、
視覚化をかんがえるに当たっての作業や
構造の把握なんかで見直せることもある、
という話じゃね。
話じゃね、と言ってもそのへん>443はあいまいだから
当人がどう思ってるかは分からんけど。

それをわざわざ「表示のために論理構造を書きなおす」とは言わんけどな。
表示の問題に対処するためじゃなくて、表示以前の問題に対処するためなんだし。

>>449
> 結局、その原因が悪いとすると、あらかじめ
> 出来るだけ細かくマークアップしておけという話にならないか？
あらゆる状況に耐えうるほど細かく十分なマークアップをしておくなんて
現状のHTMLで理屈の上では可能なの？

> この場合、書き直す羽目になった悪い原因とやらは何だ？
自分の目的に十分な程度のマークアップをしてなかったことじゃね？
ただ、目的が変わることを予測して十分なマークアップをするなんてのは
難しいことだから、「悪いからやめろ」と言えるか「仕方ない」かは
分からんけどな。

>>449
「枠で囲みたくなった」は気が変わっただけだろ。レイアウト煩悩でチーンだ。
見出しによるセクションはdivがなかろうと論理構造としてそこにある。

>>451
じゃあ、class="red" 部分の色を変えたくなったのも、気が変わっただけ
なんだし、そこを否定すると、スタイルを変えることが全部否定されて
しまうぞ。

要するに、変更が生じる羽目になったからと言って、何かが悪かったとは
限らない訳だよ。何も悪くなくても変更なんてものは生じる。

装飾に対応するクラス名ではなく、構造に対応するクラス名を付けろと
いうのは、きちんと構造を記述するために必要なのであって、変更を少なく
するために必要な訳ではない。

>>452
> 要するに、変更が生じる羽目になったからと言って、何かが悪かったとは
> 限らない訳だよ。何も悪くなくても変更なんてものは生じる。
それでclass="red"の場合に「特定の表示目的でクラス指定する」ことが
悪くなくなるわけじゃないけどな。

> 装飾に対応するクラス名ではなく、構造に対応するクラス名を付けろと
> いうのは、きちんと構造を記述するために必要なのであって、変更を少なく
> するために必要な訳ではない。
きちんと構造を記述するだけで済む話なんて最初(>380)からされてないよ。
それだけじゃclass="red"の問題は解決できないって何度も言われてるって。

もしかして、>441とか読むに、
「構造の記述が不正じゃなければいくら表示のために変更しようが構わん」
と思ってるの？

>>452
HTMLの論理構造とスタイルを変えることの全否定は関係ないでしょ。
クラス名は構造を示しませんよ。

枠を囲みたくなった＝論理構造に変更を加えたくなった
ってこった。
headingやpが基本論理構造であるのと同様にemも論理構造の一環。
それと同様に、同一要素に対する異なるクラス名は構造を示すんだよ。

>>455
枠でな。で。

＞囲みたくなった=論理構造を変えたくなった

話しにならんわ。
見た目を変えたくなったら論理構造を変えたくなるのか。バカか。

・・・「見た目」が「論理構造」と疎結合であると思ってるほうがバカだな。

>>457
愛はやりたくなるけど、やりたくなるのが愛じゃないんだよ。
--お塩大先生--

枠で囲みたくなった＝論理構造を変えたくなった

divか？divで論理構造が変わるのか？
またかおまえか

divなんか使うな

一切

hnで充分だ

強調したいから枠で囲むとか、本文より重要度が低いからフォントサイズを小
さくするとかあるだろう。そういうのはdiv要素でマークアップするしかない。

>>461
初心者は初心者スレへ

>>453
「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが
構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った
記述が出来ているかどうかであって、その動機が出来上がりに影響を与えないの
なら、どんな動機で始めたとしても同じだろ。

red という文字列の意味はUAには伝わらないが、どれとどれが同じクラスなのかは
伝わる。表示を表すクラスは、構造のグループと関係なしにグルーピングされて
伝わるのが問題なのであって、後の変更に耐えうるかどうかなどという制作者の
都合で駄目な訳ではない。

いくら変更しようが構わんかどうかは、構造をいくら変えても構わんのかどうかと
同じだよ。

>>463
> 問題はきちんと構造に合った記述が出来ているかどうかであって、
それだけじゃすまないって理由つきで何度も言われてるんだからちゃんと反論しなよ。
> その動機が出来上がりに影響を与えないのなら、どんな動機で始めたとしても同じだろ。
出来上がりから動機を切り離して考えることはできないって言われてるんだからちゃんと反論しなよ。

「構造だけじゃなくて意図も考えないとだめだよ」
　→「いや、その場合は意図は結果に反映されてる」
　　→「その結果とやらは、UAや他人に伝わる情報だけじゃなくて
　　　　著者の意図も入ってるじゃん」
というやりとりが何度もあるのに、それをスルーして
　「いや、その場合は意図は結果に反映されてる」
といい続けるだけじゃなあ。

> 表示を表すクラスは、構造のグループと関係なしにグルーピングされて
> 伝わるのが問題なのであって
クラス指定に「構造のグループを指定して伝える」なんて意味は無いよ。

> 後の変更に耐えうるかどうかなどという制作者の
> 都合で駄目な訳ではない。
俺定義のクラス指定の意味に反するからというのは俺ルールでしかない。
そうじゃなくて、構造と表現の分離という原則に反するせいで
変更時とかにたいへんだからダメなんだよ。

> いくら変更しようが構わんかどうかは、構造をいくら変えても構わんのかどうかと
> 同じだよ。
どうなのかちゃんと言おうね。

>>464
何度も言ってる
何度も言われてる


おまえがな

じゃあ、ともかく論点を簡単に整理してくれよ。
vipperには辛いわ読むの

>>464
> 出来上がりから動機を切り離して考えることはできないって言われてるんだからちゃんと反論しなよ。

要するに、悪い動機からは悪い結果しか得られないと言いたい訳か？　きっかけは
不純でも、そこからしっかり構造を考え直して、しっかりした物が出来るという道は
あり得ないと？

> クラス指定に「構造のグループを指定して伝える」なんて意味は無いよ。

グループという言い方が悪ければ「同じ種類」と言ってもいいよ。同じクラス名が
付けられている要素は、なんらかの意味で同じ種類に意味づけがされているとUAに
伝わるでしょ？

> そうじゃなくて、構造と表現の分離という原則に反するせいで
> 変更時とかにたいへんだからダメなんだよ。

そちらのいうStrictって、その程度のものなの？　構造と表現の分離は、メディア
依存性を排除するという重要な意味があるのに、単に制作が楽になるからだけなの？

クラス名からもメディア依存性を排除しようという話じゃなかったのか？　もう
ちょっと分かってる人だと思ってたが…。

>>467
> 悪い動機からは悪い結果しか得られないと言いたい訳か？
class="red"話において「特定の表示を意図してクラス指定すること」についてはね。
> しっかりした物が出来るという道はあり得ないと？
class="red"話において「特定の表示を意図してクラス指定すること」について
しっかりしたものがどうやってできるか反論してみて。

> グループという言い方が悪ければ「同じ種類」と言ってもいいよ。同じクラス名が
> 付けられている要素は、なんらかの意味で同じ種類に意味づけがされているとUAに
> 伝わるでしょ？
それが構造の指定と食い違う

> 構造と表現の分離は、メディア依存性を排除するという重要な
> 意味があるのに、単に制作が楽になるからだけなの？
メディア依存性を排除することにより、各メディア対応の出力を得たり、
出力を変更することが楽になるんだけど、メディア依存性を排除する
ことの効果とか、作業が楽になることの意義を考えてみたら？
「単に」というほどくだらないものじゃないはずだよ。

確かに宗教のごとく「メディア依存性を排除」と唱えてそれを実践するだけでも
それによる恩恵は受けられるし、そうする意味はあるけど、それを実践すること
がなんでよいことなのかの理解を深めれば、よりよく実践できるようになると思うよ。

> クラス名からもメディア依存性を排除しようという話じゃなかったのか？
class="red"話はとくにメディア依存性に限る話じゃないよ。
たとえredクラスが各メディアに対応して作られていて、
また各メディアへの対応が不都合なくできるように作られていても、
その各メディアへの特定の出力を狙ってred指定するなら話は
同じなんだから。
# 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて)
# メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな？
# それじゃ「構造と表現の分離」のトートロジーだし。

>>466
(1)「特定の表示を意図してクラス指定すること」は表示と構造の分離に反する
よって、class="red"とするときにそうすることは悪い。
└ (2)"結果に影響なければ" 指定する意図なんて関係ない
　　(3)クラスを指定する意図が "UAに伝わらないんなら" 関係ない
　　よって(1)とはならん
　　└ "UAや他人に伝わらない" 場合でも、たとえば「著者の意図と食い違う意味づけ」
　　　　という場合には悪いかどうかに関係する。
　　　　だから(3)は成り立たない。
　　　　└ 「構造が著者の意図と違う」というのは結果として含めるから
　　　　　　それは"UAに伝わらない"例に含まない
　　　　　　└ それじゃ結果に意図が含まれてるじゃん。"結果に影響ある"んだから、
　　　　　　　　(2)の前提がなくなる。よって(1)を否定するには(1)の根拠への反論か要るよ。
(4)"クラス名"がダメだと構造がダメになる
class="red"ではその点が問題だ
└ クラス名がまともでも「特定の表示を意図してクラス指定すること」
　　を直さなきゃ相変わらず表示と構造の分離に反するよ
　　だからそれじゃ問題の捉え方が不十分だよ
(5)"クラスを作る意図"がダメだと構造がダメになる
class="red"ではその点が問題だ
└ まともな意図で作られたクラスでも「特定の表示を意図してクラス指定すること」
　　を直さなきゃ相変わらず表示と構造の分離に反するよ
　　だからそれじゃ問題の捉え方が不十分だよ

>>468
> class="red"話において「特定の表示を意図してクラス指定すること」について
> しっかりしたものがどうやってできるか反論してみて。

「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ？
そこで、一から構造を練り直し、しっかりした構造のものを作り上げるんだから、
悪いものしか出来ないという方がおかしいと思うが。

> それが構造の指定と食い違う

それは食い違った結果が悪いのであって、動機が悪い訳ではないよな。

> # 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて)
> # メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな？

まさしくそれを言ってるんだが…。HTMLは全メディアから独立した状態で書く。
各メディアへの対応はスタイルシートでやるというのが、「構造と表現の分離」
じゃないのか？　そして、スタイルシートは必須のものであってはならない。

「たとえredクラスが各メディアに対応して作られていて」とか、その時点で駄目
だよ。どのメディアにも関係なく存在する（つまり、どのメディアにも対応しない）
「文書本来の構造」に従ってクラスを割り振れ、そうじゃないものは悪い、と
言ってるんだ。たとえ、きっかけが「見た目を変えたい」であったとしても、その
ような構造を見つけ出して構造化出来たのなら良いと言ってるんだ。

制作が楽になるためではなく、その文書がより普遍的に（メディアに関係なく）
利用可能になることを目指してのStrictなんだから。

>>469
> 　　　　　　└ それじゃ結果に意図が含まれてるじゃん。"結果に影響ある"んだから、

そちらは「著者の意図」とは「制作者の動機」とほぼ同義で使ってるのか？
俺は「伝えたい文書構造」の意味で言ってたんだが…。 >>438 でも「著者の
意図した構造」と言っているように、意図とは構造のことを言ってた。

> └ クラス名がまともでも「特定の表示を意図してクラス指定すること」
> 　　を直さなきゃ相変わらず表示と構造の分離に反するよ

これも >>431 で「名が体を表しているのは前提」と言っているので、クラス名の
名前だけまともっぽく見せて中味が食い違っているものなどは最初から論外にしている。

> └ まともな意図で作られたクラスでも「特定の表示を意図してクラス指定すること」
> 　　を直さなきゃ相変わらず表示と構造の分離に反するよ

それはこっちが理由を聞きたい。きっかけはあくまできっかけでしかないと思うが。

>>470
> 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ？
きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、
class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるわけだが、
　> class="red"話において「特定の表示を意図してクラス指定すること」について
　> しっかりしたものがどうやってできるか反論してみて。
とまで言われてもなお答えないつもりなのかなあ。

あと、「きっかけに過ぎない、結果に影響を与えない意図なら問題ない」というのは
そちらの言ってる(言いたい)ことであって、なんで「きっかけに過ぎないんだろ？」
とか言い出してるのかわからん。

> > それが構造の指定と食い違う
> それは食い違った結果が悪いのであって、動機が悪い訳ではないよな。
ごめん、そこ書きかけだった。
「classは構造を指定するもの」と定義されてるなら食い違ったらアウトだけど、
そうじゃない以上食い違うこと自体が禁止されてるわけじゃないよね、ということ
を書くつもりだった。

まず「構造と表示の分離に反する」ということがあって、
それを引き起こす原因に「特定の表示を意図してクラスを指定する」
ということがあって、class="red"話で問題なのはそれ、というわけだ。

で、「特定の表示を意図してクラスを指定する」ことをする場合に
いろんな特徴が見られるけど、それら自体を消すことでは問題は
解決しない、という話。

「構造と一致しないクラスのグルーピング」も、そんな特徴のひとつ
でしかない。それが直接規則に触れるわけではないし、
その特徴がたとえなくとも、つまり構造とクラスのグルーピングが
一致してても「特定の表示を意図してクラスを指定する」ならダメだし。

>>470
> 「たとえredクラスが各メディアに対応して作られていて」とか、その時点で駄目だよ。
スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
その時点で何が駄目なのか分からん。

> 「文書本来の構造」に従ってクラスを割り振れ、そうじゃないものは悪い、と
> 言ってるんだ。たとえ、きっかけが「見た目を変えたい」であったとしても、その
> ような構造を見つけ出して構造化出来たのなら良いと言ってるんだ。
>447,450で書いてるように俺はそこに争いが無いんだよ。
そこに反論してる奴に対して主張するならともかく、
話し相手考えて主張しろよ。
それじゃ問題の認識が不足してる、って言ってるやつに対して
その主張ばかりリピートする行為がどういう意味をもつかよく考えてみれ。

>>471
> そちらは「著者の意図」とは「制作者の動機」とほぼ同義で使ってるのか？
> 俺は「伝えたい文書構造」の意味で言ってたんだが…。
　>438> …ある特定の表示をしたいと思う。そこで文書構造を考え直して、
　　　　> 構造化し直し、きちんと文書構造を記述したマークアップが出来た。
　　　　> これが悪か、という話だよ。
という話では著者の意図する構造、
　>432> 悪いのは、特定の表示・装飾を目的としてHTML要素のクラス指定をすること。
という話ではHTML要素のクラス指定をする目的を指して使ってるよ。
これらが違う話なのは>439,442に書いてある通り。

　>453> それでclass="red"の場合に「特定の表示目的でクラス指定する」ことが
　　　　> 悪くなくなるわけじゃないけどな。
　>463> 「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが
　　　　> 構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った
　　　　> 記述が出来ているかどうかであって、その動機が出来上がりに影響を与えないの
　　　　> なら、どんな動機で始めたとしても同じだろ。
という話があったよね。class="red"話では463のここで言う前者だから、
「クラスを指定した動機」が出来上がりに影響を与えるから問題なんだよ。
ここでの「クラスを指定した動機」を意図として、>469で今までの話をつなげてる。

そちらの話したがる、463でいう後者の話では、著者の意図ってのは構造で、
動機ってのは変更の動機だよね。けど、class="red"はその話じゃないよね。

> それはこっちが理由を聞きたい。
>432
　> ・クラスを作ることが問題？
　> 　→赤色表示目的のredクラスじゃなくて、titleとかredtextとかまっとうな目的で
　> 　　作られたクラスを指定する場合でも問題は変わらない
というか
　> きっかけはあくまできっかけでしかないと思うが。
とか言ってるあたり、まだ別の話を続ける気なの？class="red"の話をちゃんとしようよ。

見かけと意味って直結してるんだから区別できるわけなんて無いじゃん。
そんな単純なものじゃないだろ。

つかさ。classやid名じゃ意味を与えられない以上細かいことは気にスンナよ。
だから意味的な名前をつけるのが推奨だが、結局機械処理前提ではどうでもいい。
人間がみてわかるようにclassに意味づけがされるのであれば、
divとか自体がhtml上で別の意味を持ってしまう訳だし。要するに記号でしかないのよ。
htmlの構造がわかればその要素が何を意味するかがわかるから、
意味じゃなくてclass="header"（笑）みたいな
構造を連想させるものだったとしても判断できる訳だし。
redだろうが見掛けの表すイメージがあるんだから人間が読めば大体はわかる。
結局attentionだろうがなんだろうが意味づけできない以上文字列でしかない。
その辺を機械的に考えようとしてないのもhtmlのダメさだと思う。

微妙に違う話だが、前section divの話でclassやidで意味を与えられるかって話題を思い出した。

話がどっち行ってるんだか、わからないけど
class="red"の具体例として、こんなのはどうだろう。

　colorには<em class="red">#FF0000</em>を指定した。

「赤い表示」じゃなくて「赤い色」を表したクラスって事なんだけど。

まあ、無理やり例示してみたけど、class="red"がありえるか、ありえないかなんてどうでも良くて、
Strictに考えてなお、必要だと思う場面があったならredだろうがなんだろうが指定すればいいんじゃないかと。
少なくとも今ここで、絶対に駄目だと言うべき事ではないと思うよ。

もうその段階の話はとうに通り過ぎて、精神論に移ってるんじゃないのか？

>>476
そういう、OKかもしれない状況、ってのは
>393,399でも既出だよ。
　> class="red"がありえるか、ありえないか
　> 少なくとも今ここで、絶対に駄目だと言うべき事ではないと思うよ。
「class="red"は絶対ダメ」なんてことはない、
というのは、具体的な反例とともにもう示されてる話。


まず、class="red"話ってのは>380から始まる話のことね。

そこから話が始まって、
「class="red"は〜が駄目だからダメ」→「いや、class="red"がこういう場合はＯＫだよね」
というのを何度か繰り返してるから
　「普通class="red"はダメだと言われるけど、それの何が本当は駄目なのか」
という話をしてるわけよ。

結局は「特定の表示を意図してクラスを指定するのがダメ」ということだと思う。
476とかの「OKな場合」を含まず、class="red"と同じダメな場合を含むからね。
これは「Strict的に考えて絶対にダメ」なんじゃないかな。
…という話。


そこになぜか、クラス指定する意図ってのを、構造を変更するきっかけととったりしてる人がいて、
「"クラス指定する意図・動機"が特定の表示を意図しているのはダメ」というのを
「"構造を変更する動機・きっかけ"がダメでもよいものはできる」というから
後者はclassを指定する時の話じゃねーじゃねーか、と何度も言ってるんだけどね。

>>475
> 見かけと意味って直結してるんだから区別できるわけなんて無いじゃん。
直結部分がHTMLのclass指定部分で、その指定を特定の見かけの実装に
依存しないでやることで、直結しつつも区別できるようになるんじゃね？

>>473
> スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
> その時点で何が駄目なのか分からん。

HTMLにとってスタイルシートとは、「著者お勧めのスタイル」に過ぎなくて、
UAは表示の際に、著者指定のスタイルシートには従わなくても良いという規定に
なっている。だからHTMLは、HTMLだけですべてが伝わらなければならない。
スタイルシートの存在を前提にしている時点で駄目だということだよ。

あと、構造と表現を分離して、構造はHTMLで、表現はスタイルシートで、とされて
いるんだから、HTML側にあるクラス指定は、構造を指定するものであるべきだろ。

>>474
> >463> 「特定の表示を表すクラスを指定した」なのか「特定の表示をしたくなったが
> 　　　> 構造にあったクラスを指定した」なのかが重要。問題はきちんと構造に合った
> という話があったよね。class="red"話では463のここで言う前者だから、

前者なのか？　それを聞きたかったんだよ。前者なら当然駄目だ。

そもそもこの話は >>441 で既にしている。「特定の表示のためにクラス指定をする」
という言い方は曖昧で、前者(A.)の意味とも後者(B.)の意味とも取れる。どちらの
意味で言ってるのか分からないので、前者なら駄目で後者なら良いと言った。

そしたら >>442 で「クラスを作ることが問題」なのではないという話が出た。
さらに「まっとうな目的で作られたクラスでも問題は変わらない」とある。
つまり、前者(A.)「そんなクラスを作ること」が問題なのではなく、後者(B.)
「正しい構造を作る」場合でも発生する問題だなと判断して以下の展開。

> そちらの話したがる、463でいう後者の話では、著者の意図ってのは構造で、
> 動機ってのは変更の動機だよね。けど、class="red"はその話じゃないよね。

別に俺が話したがってた訳じゃない。そちらが後者の話をしているんだと思った
からそうしてただけだ。だから「きっかけに過ぎないんだろ？」とか、何度も
念を押していたんだ。 >>463 でもう一度、前者と後者の文を書いたのも、
本当に後者の話でいいのかを探るためだった。

じゃあ残る問題は、表示用のクラスを作る事自体が問題なのではないという点。
いや、それが問題なんだろ？

>>479
> スタイルシートの存在を前提にしている時点で駄目だということだよ。
class属性にスタイルシートにおけるセレクタの役割があるからこそ、
それに関して「特定の出力を意図してclass属性指定」という話が
されてるんだが、いまさら何いってんの？

スタイルシートによる置き換えが可能であるから
HTMLの見た目関連要素・属性が削減されていってるのに、
「いや、こちらが見た目を指定する機能が存在することは前提としちゃいけない」
なんてのは成り立たんよ。

「こちらが見た目を指定する機能が確実に動作することは前提としちゃいけない」
というなら分かるが、それは「スタイルシートの存在を前提」とは、
スタイル指定が確実に動作することは前提としてないところが違うし、
「redクラスが各メディアに対応して作られていて」という話とも、
クラスがスタイルシートのおかげで各メディアへの出力に対応していても、
そのスタイル自体が適用されるかどうかは別の話である点で
ぜんぜん違うしな。
だからまさかそんな意味で言ってないだろうとは思うが。

> HTML側にあるクラス指定は、構造を指定するものであるべきだろ。
ある表現そのものの指定(赤色表示とか)だと分離できてないけど、
それは表現の用に供する目的(つまりスタイルシートのセレクタの意図)で
指定してもよいということ自体まで否定する理由はないよ。
(ないどころか、classには表示への橋渡しの役がある)
構造はHTML上で要素として明示されてて、class属性は要素単位でしか
割り振れないから、表示の用に供する目的で指定しても構造の壊しようがないしな。

>>480
> つまり、前者(A.)「そんなクラスを作ること」が問題なのではなく、後者(B.)
> 「正しい構造を作る」場合でも発生する問題だなと判断して以下の展開。
あくまでclass="red"話してるってのは何度も言ってるけど、それにもかかわらず
そこで「正しい構造をつくるあらゆる場合」に話を広げて文書の変更のときの
動機の話をし始めてるのはなんで？

> だから「きっかけに過ぎないんだろ？」とか、何度も念を押していたんだ。
「別の話だ」と何度も否定してたし、それに対してちゃんとレスつけてたよな。
そしてそのその話は>>442で
　> だけど、その原因が取り除けるものなら、原因を作るのは悪いことだよね？
　> 今回は、だから「特定の表示目的でクラス指定するな」となる。
と言ったこところですでに終わってる話じゃん。それ無視しておいてよく言うわ。

> じゃあ残る問題は、表示用のクラスを作る事自体が問題なのではないという点。
> いや、それが問題なんだろ？
また始まった。レスついてるんだから見落としてるなら話の頭から追い直せよ。
それはclass="red"話の問題じゃなくて、みられることの多い特徴に過ぎないって
何度書かれれば書かれた文を読むんだよ。
　> それはこっちが理由を聞きたい。
と言っておいて、それを過去レスから持ってきたら無視されたんだが、
これは一体なんのつもりなんだろう。

>>481
なんか、ここだけを読んでるとStrictを全く分かってない人のように見えるんだが
気のせいか？

まず、UAが著者指定スタイルシートを無視する方法まで仕様書に書かれている
意味は分かってるか？　著者指定スタイルシートなんて、所詮ただの「著者のお勧め
表示方法」に過ぎないんだぞ。そして、各UAは著者指定スタイルを完全に無視して、
独自の表示方法を用意して構わない。それでもスタイルシート対応と言える。

例えば、「週刊誌風表示」「スポーツ新聞風表示」なんてメニューがあって、
それを選んでいると、勝手に週刊誌やスポーツ新聞っぽいに表示にされるという
ようなUAがあってもいい。もちろん、HTMLの見出しや段落などの構造に従った
表示になる。HTMLに対するスタイルの意味なんてその程度のものだ。「著者の
仮定する見た目が完全に動作することは前提としちゃならない」なんてレベルの
話ではない。

そういう仕様だからこそ、特定の表示のためのクラスなんて駄目なんだ。表示は
一片たりとも想定出来ない。想定していいのは記述した構造だけだ。

それから仕様書では、現在存在しない（将来現れる）メディアも想定している。
そのようなメディアまで想定してのメディア非依存だ。だから「あるクラスが各
メディアに対応」なんておかしい。未来のメディアにも対応してるのかと。

表示は一切想定せず、存在しないメディアは想定する。それがStrict。ならば、
信じられるのは構造しかない。

>>482
> あくまでclass="red"話してるってのは何度も言ってるけど、それにもかかわらず

redが表示色を表すクラスか、構造（赤色に関する話題など）を表すクラスかが
問題だと何度も言ったが、そちらが「まっとうなクラスでも問題だ」などと言い出す
から、なぜ正しい構造でも問題なのかという話になって、話が広がった。

> > だから「きっかけに過ぎないんだろ？」とか、何度も念を押していたんだ。
> 「別の話だ」と何度も否定してたし、それに対してちゃんとレスつけてたよな。

それは「特定の表示目的でクラス指定するな」という話だよな。だからその言葉
自体が二重の意味を持つんだよ。「特定の表示目的で（正しい構造の）クラス指定
をするな」の意味も持ちうる。特に「まっとうなクラスでも問題だ」という発言が
あった後では、そういう解釈も成り立つ。つまり否定になってない。だから、俺も
A. か B. かなどと色々言ってたんだ。
「特定の表示目的 *の* クラス指定をするな」だったら紛れようがなかったが。

> それはclass="red"話の問題じゃなくて、みられることの多い特徴に過ぎないって
> 何度書かれれば書かれた文を読むんだよ。

だからその理由が分からないって。「表示を表すクラスを作る」と「表示目的 *の*
クラスを指定する」は同じじゃないか。当然、クラスを作ったからには指定するん
だろ。片方はよく見られる特徴で片方は原因だなんて話は何度も聞いてるよ。でも
その違いが分からないんだよ。同じことじゃないか。

まさかと思うが「表示を意味するクラス名を作る」「まっとうなクラス名でも問題だ」
という意味で言ってる訳じゃないよな？　だったら全然意味が違うが、それは俺が
最初から「名が体を表しているのは前提」と言っているように、「名前だけ…」なんて
のは、ハナから論外として議論から外してあるんだが。

>>483
> HTMLに対するスタイルの意味なんてその程度のものだ。「著者の
> 仮定する見た目が完全に動作することは前提としちゃならない」
> なんてレベルの話ではない。
「その程度」「レベルの話ではない」とはっきりしないようだけど、
　> それは表現の用に供する目的(つまりスタイルシートのセレクタの意図)で
　> 指定してもよいということ自体まで否定する理由はないよ。
を否定するのかどうかはっきりしてね。

> そのようなメディアまで想定してのメディア非依存だ。だから「あるクラスが各
> メディアに対応」なんておかしい。未来のメディアにも対応してるのかと。
　> スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
　> その時点で何が駄目なのか分からん。
と>473で念押ししてあるから、「未来のメディアにも対応してるのかと。」というのは
HTML側の話じゃなくてスタイルシート側の話だと取るしかないんだが、
　>470> 各メディアへの対応はスタイルシートでやるというのが、「構造と表現の分離」
つまりお前はスタイルシートにおいて各クラスに対して未来のメディアに関する
指定までされてないと、構造と表示の分離が出来てない、と言うわけだな？

俺は、スタイルシート側で各クラスについて未来のメディアについて対応してなくとも、
HTML側でスタイルシートの特定の表示に依存してなけりゃ、HTMLのメディア非依存性
は保たれると思うんだけどなあ。

>>484
> そちらが「まっとうなクラスでも問題だ」などと言い出す
> から、なぜ正しい構造でも問題なのかという話になって、話が広がった。
「クラスを指定する意図」の良し悪しを考えるときの構造について、
その構造がまっとうな場合の話に広がるなら分かる。
しかし、なぜか「クラス指定をする意図」を「構造を変更するときの動機」にすりかえて
「構造を変更するときの動機」の良し悪しを考えるときの構造の話をしだしたわけだけど、
きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、
class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるんだよな。

> そういう解釈も成り立つ。つまり否定になってない。だから、俺も
> A. か B. かなどと色々言ってたんだ。
　> B.「特定の表示をしたいから（きちんとした構造の）クラスを作る」
に対して「一致しない」って言って、理由も説明して、「なんか反応して」とまで
言ってるのに無視したあげく、
　> 「特定の表示目的で（正しい構造の）クラス指定をするな」の意味も持ちうる。
「作る」と言ってたのを「指定をする」と言い換えたうえで否定になってない
なんて言い出すわけか。

> 「表示を表すクラスを作る」と「表示目的 *の* クラスを指定する」は同じじゃないか。
そりゃ都合よく言い換えりゃ同じにもなるわ。
　(作っただけで指定しないなんて場合もあるが、これはしても意味ない話だな)
> クラスを作ったからには指定するんだろ。
特定の表示目的じゃなく作られたクラスを、特定の表示目的でな。

redが「赤い色に関するテキスト」のクラスという場合。
スタイルシート側では「文字色を赤色として表示」としてあるが、
もちろんこの表示を前提としたクラスではない。
　(これは特定の表示目的じゃなくともありうる、ってのはもう書かれてることだね。)
そして、これを「赤い色に関するテキスト」を要素内容とする要素に、
「文字色を赤色として表示」する意図で指定したら、
著者の伝えたい構造とクラスが合致してようがダメだよ。

議論が決着したらまとめを書いてくれるとうれしいです

引用文と地の文は一行空けると読みやすい｡

引用文の色を変えろよ

つかもうさすがにキモい。

>>485
> 「その程度」「レベルの話ではない」とはっきりしないようだけど、

特定のスタイルシートを想定してHTMLにクラスを付けるのは間違い。先述の通り、
著者指定スタイルシートは想定出来ないから。だから、HTML側はスタイルとは
関係なしに、構造（あるいは何らかの意味）に従ってクラスを割り振る。そして、
そうやって出来たクラスに対してスタイルシートは装飾する。

だから、HTML編集時には否定で、スタイルシート編集時には肯定だ。

> 　> スタイルシート側では各メディアに対応してスタイルを規定するわけだが、
> 　> その時点で何が駄目なのか分からん。
> と>473で念押ししてあるから、「未来のメディアにも対応してるのかと。」というのは
> HTML側の話じゃなくてスタイルシート側の話だと取るしかないんだが、

そこだけ読むとそうなるが、最初に「redクラスが各メディアに対応」と言ってた
時は、そのようなクラスをHTMLに指定、という話だった。HTML側に取っての
クラスは、スタイルシート側で何に対応しているかは関係ない。だから、そのような
クラスをHTMLに指定するということは、特定のスタイルを想定したクラス指定
なので、たとえどんなメディアに対応していても駄目だという意味で書いた。

> HTML側でスタイルシートの特定の表示に依存してなけりゃ、HTMLのメディア非依存性
> は保たれると思うんだけどなあ。

その通り。だからHTML側はスタイルシートに依存してはならない。つまり、
HTML側が特定のスタイルシートを想定してクラス付けしてはならない。

>>486
> 特定の表示目的じゃなく作られたクラスを、特定の表示目的でな。

ようやく話が分かった。そんな場合のことをずっと言ってたのか。そりゃあ
話も噛み合わんわ。最初からそう書いていれば2〜3レスで済んでた話かもな。

要は、「構造には合ってないが同じスタイルなのでクラスを流用した」という
状況を想定してるんだな？　それは名が体を表してない状況だ。俺は >>431 で
「名が体を表すのは前提」と書いていたように、違う意味で流用する場合なんて
のはハナから論外として論点から外してあったんだ。

「特定の表示目的でクラス指定するのが悪い。まっとうな目的で作られたクラスでも
問題は変わらない」

そちらの書き方はこうだった。俺は名が体を表すのは前提なので、この書き方では
「特定の表示目的で、真っ当なクラスを（正しい構造に従って）使うのも悪い」と
いう意味にも解釈出来てしまう。じゃあ「表示目的」とは動機のことか…となった。

「クラスを作ることが問題ではない」

この書き方も同様だ。今から見れば言いたいことは分かるが、名が体を表すのを
前提にすると「クラスを作ること」とは「正しい構造に従ってクラスを指定する
こと」と同義だ。それが問題ではない（つまり、正しい構造に従ってクラス
指定したかどうかは関係ない）と言われれば、やっぱり動機が問題だと言いたい
のか？…となる。

> 著者の伝えたい構造とクラスが合致してようがダメだよ。

これは合致してない場合だろ。明らかに違う意味のクラスを割り当ててるんだから、
著者の伝えたい構造ではない。伝えたい表示が合致しているだけだろ。それを意図
と呼んでいたのなら、意図とは合致してるのかもしれんが。

似非すとりくた

まあ、ここまで全部俺の自作自演なんだけどね

>>494
それなら安心した

> 先述の通り、著者指定スタイルシートは想定出来ないから。
　> 「こちらが見た目を指定する機能が確実に動作することは前提としちゃいけない」
と言ってるとおり、著者指定スタイルシート"のみ"なんて話はしてないから、
"のみ"ではなく、可能性のひとつにも入れてはいけないと言っているんだよな。

想定しているのがそれ"のみ"ではなく、それ以外のスタイルでも読めるように
なっているのであれば、たとえ著者指定のスタイルを適用することを想定して、
(特定の表示を意図してでなく)スタイル指定の用に供するためにclass指定しても、
そのクラスにスタイルが適用されない場合も他のスタイルでもあいかわらず
読めるわけで、それ自体には問題じゃないじゃん。(否定するにはなにか追加の
悪い要因が要る。)

> だから、HTML編集時には否定で、スタイルシート編集時には肯定だ。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html
　> HTMLにおいて、class属性は、次の各々の役割を果たす。
　> ・著者が要素集合にたいしてスタイル情報を割り当てたいと考えた際の、スタイルシート選択子。
上でくどくど説明したけど、結論だけなら仕様に書いてあるんだから、
まず仕様を無視する俺ルールをやめなよ。

> その通り。だからHTML側はスタイルシートに依存してはならない。つまり、
> HTML側が特定のスタイルシートを想定してクラス付けしてはならない。
依存してなければ存在することを想定しても別に構わん。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/present/styles.html#h-14.3.1
　> HTMLでは、著者は、いくつの外部スタイルシートを1つの文書と関連づけてもよい。
結論だけなら仕様にある。

>>496
お薬だしておきますね。

>>492
> 最初からそう書いていれば2〜3レスで済んでた話かもな。
指定するクラスが特定の表示目的のクラスじゃなくとも、
特定の表示目的で指定すりゃダメ、という旨の
発言が一回も書いてないと宣うお前のおかげで
ここまで伸びたんだけどな。
お前は"title"や"redtext"とかの話をどういうつもりで
読んでたというつもりだよ。

> 要は、「構造には合ってないが同じスタイルなのでクラスを流用した」という
> 状況を想定してるんだな？
要はとか言って話を都合よく狭くするのはいい加減やめたら？
　> redが「赤い色に関するテキスト」のクラスという場合。
　> そして、これを「赤い色に関するテキスト」を要素内容とする要素に、
　> 「文字色を赤色として表示」する意図で指定したら、
という文を読んで構造と不一致と考えるならどこが不一致か言ってみろ。
赤いテキストの要素に赤いテキストのクラスを割り振ることが
どう構造と食い違うんだろうな？

> じゃあ「表示目的」とは動機のことか…となった。
そちらの話していた動機云々は「クラスを指定する動機」ではなく、「構造を変更するときの動機」だ。
だから「クラスを指定する動機」として話してみろ、と>472で
　> 「特定の表示をしたくなった」というのは単にきっかけに過ぎないんだろ？
　> きっかけがどうこうという話は、変更するときの、変更することの動機の話であって、
　> class="red"と指定するときの意図の話じゃねーじゃんと何度も書かれてるわけだが、
　> 　> class="red"話において「特定の表示を意図してクラス指定すること」について
　> 　> しっかりしたものがどうやってできるか反論してみて。
　> とまで言われてもなお答えないつもりなのかなあ。
とまで言ったんだが今なお無視してるよな。
「構造を変更する動機」と摩り替えて話を変えた理由になってないよ。
>486冒頭でもそのことを指摘してるのに無視したあげくこんなこと言ってるが、
今後も無視し続けて、この理由を説明しないつもりなのかな。

>>498
お薬飲んで下さいね。

お互い何を主張して何を張り合ってるのか、傍から観て良く分からないんだけど・・・

引用やめて5行くらいにまとめてくれれば読みやすいのに。

討論好きな学生とかいるよね。

>>500
　Ｑ. class="red"の類がダメな理由として、適切なのはどちらでしょうか？
　Ａ１. 「クラス指定が構造を表してないからダメ」（相手）
　Ａ２. 「特定の表示を意図してクラス指定してるからダメ」（俺）
という話。

>>496
だから、class="red" の悪の根源は何かと言えば、特定のスタイルシートを
想定したクラスを指定することにあるわけよ。だから、HTML編集時には
スタイルシートを想定してはならないんだよ。

>>498
> お前は"title"や"redtext"とかの話をどういうつもりで

どんなクラスを作っても問題は変わらないというから、じゃあそれ以前の動機の
問題だと言いたいのか？…と思ったって、既に書いた通りだよ。最初に読んだ時は、
「Strictでないことを思い浮かべただけで、Strictではないのです」と、キリスト
みたいな主張をしてるのかと思ったぐらいだ。

> 要はとか言って話を都合よく狭くするのはいい加減やめたら？

つまり、「制作者本人は見た目を指定するつもりで編集していたが、結果としては、
完全に構造をきちんと表したものが出来た」という場合を言ってるのか？
また、ずいぶんと特殊な例を出すんだな。まあ、その文書に関しては結果オーライ
だが、そういう編集方針が危険な状態だという主張は分かる。

> そちらの話していた動機云々は「クラスを指定する動機」ではなく、「構造を変更するときの動機」だ。

俺は、「クラスは構造に従って付けるべき」と主張してたんだから、その2つは
全く同じ意味を持つよ。話をすり替えてたんじゃなくて、話の前提が違ってただけ。

> 　> 　> class="red"話において「特定の表示を意図してクラス指定すること」について
> 　> 　> しっかりしたものがどうやってできるか反論してみて。

これも >>470 などで答えてるが答えるたびに無視してると言われて訳が分から
なかった。無視してるんじゃなくて、前提が違ってたから話がすれ違ってただけ。
俺の方もそれを感じてたから、たぶんお互いに「同じ話ばかり繰り返して、なんで
肝腎なことを言わないんだ」と思い合ってた状況だろう。

俺も相手も痛いヤツにしか見えない。
文章まとめる能力を身に着けてから来い。

>>503
>Ａ１. 「クラス指定が構造を表してないからダメ」（相手）
>Ａ２. 「特定の表示を意図してクラス指定してるからダメ」（俺）
これってどっちも当てはまるんじゃない？「class="red"の類がダメな理由」
が一つでなければならない理由もないし。とよく読まずに書いてみるテスト。

>>504
> だから、class="red" の悪の根源は何かと言えば、特定のスタイルシートを
> 想定したクラスを指定することにあるわけよ。だから、HTML編集時には
> スタイルシートを想定してはならないんだよ。
という主張は>496で反論されてるのに、なんで同じ主張をリピートしてるの？
さすがにこれは目を疑ったわ。

> これも >>470 などで答えてるが答えるたびに無視してると言われて訳が分から
> なかった。無視してるんじゃなくて、前提が違ってたから話がすれ違ってただけ。
単に訳が分からないだけなら、「構造の変更」という状況から「クラスの指定」
という状況に変更しても同じだというんだから、同じになることを堂々と相手に
示せたはずだよね。
なんで示さずにレスを放置したの？

そりゃ自分の前提にあわせたルールで相手の言葉を言い換えれば、
相手の発言を間違ったものに変更できるわな。
>484でも懲りずに「俺の考えでは同じだから」として言い換えて、
結局相手の発言の意味を変更してたよね。

> まあ、その文書に関しては結果オーライだが、
> そういう編集方針が危険な状態だという主張は分かる。
そちらの脳内ルールでは結果の構造がOKならオーライなのかもしれないけど、
その時点で著者のやってることが表示と構造の分離に反してるからダメです。

>>506
たしかに両者の言ってることはある程度被ってるんだよね。
細かいこと気にしなきゃどっちを理由でも不都合はないんじゃね？

ただ、そもそも字面上class="red"でもOKな場合があるんだよね。
A1だと、class="red"において、HTMLで許容されてることまでダメと言ってる上に、
ダメな場合の言い漏らしもあるのよ。A1は余分に厳しくて、しかも不十分、ということ。

>>507
HTMLで許容されてる部分でどうのこうののスレじゃないの。
おまえも帰れ。

>>507
仕様書で許されてるというが、じゃあ文書が正しく書けてても意図が駄目なら
駄目だなんてのも仕様書で禁止されてるのか？　そんなレベルの話じゃないだろ。
構造と表現を分離するにはこうすればいいという話をしてたんじゃなかったのか？

あと、クラスは構造を表すと何度も言ってたし、名が体を表しているのは前提だと、
前提は最初に言ってたんだけどね。

> そちらの脳内ルールでは結果の構造がOKならオーライなのかもしれないけど、
> その時点で著者のやってることが表示と構造の分離に反してるからダメです。

構造と表現を分離しなければならない理由。
　→文書が様々なメディアで利用出来るようするため。（メディア非依存）
構造と表現を分離したら他にどんな利点があるか。
　→分離していると、文書の変更が容易になる。

「特定の表示を意図しながら編集したが、たまたま真っ当な構造のものが
出来た」という場合、前者の目的は達せられ、後者の目的は達せられない。
しかし、前者が達せられないと閲覧者に不利益があるが、後者は制作者の
自己責任だ。だから前者の方が重要だと言ってる。

>>503
これも同じ。

class="red" 類は何が悪いのか。（悪の理由）
　→クラスが構造に合わなくなる。（構造と表現が分離出来てない）
人はなぜそんなことをしてしまうのか。（悪の根源）
　→クラス指定の際に特定の表示を想定してるから。

こう考えると、「ダメな理由」は前者な訳。基本的にほぼ同じことを言ってる
んだろうが、そちらは、何が主なのかがどうもおかしいと思う。

>>509
> 仕様書で許されてるというが、じゃあ文書が正しく書けてても意図が駄目なら
> 駄目だなんてのも仕様書で禁止されてるのか？
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/intro/intro.html#h-2.4
　> 本仕様は、HTML 4で作業を行う著者並びに実装者に対し、次の一般原則に従うよう推奨する。
　> 2.4.1 構造とプレゼンテーションの分離
出来上がりの文書がよいだけではなく、作業する著者自身も表示と構造の分離を
守ることを指定されてるんですよ。「文書がOKだから結果オーライ仕様に反してない」
じゃないんです。

> 前提は最初に言ってたんだけどね。
何に対して話してるのかよく分かりません。どこにレスしてるのか示してくださいな。
>507の第二段落についてなら、前提を示せなんて話はしてなくて、むしろ
お前の話は状況が変わってるじゃねーか」と再三指摘しましたよね。
それを無視して「俺にとっては同じ」という勝手な読み替えをし続けてましたが、
それはなぜでしょう？
また、「クラスは構造を表す」なんてのは過去スレのdiv話で既に否定されてることですが、
　> 「classは構造を指定するもの」と定義されてるなら食い違ったらアウトだけど、
　> そうじゃない以上食い違うこと自体が禁止されてるわけじゃないよね
と>472で指摘されてますし、>481あたりからの一連の話も、結局あなたは仕様に反してる
ということを>496において示されましたが、無視して主張をリピートしましたよね。
なんででしょう？

>　→文書が様々なメディアで利用出来るようするため。（メディア非依存）
またちゃっかり意味をすり替えましたね。
　> > # 広い意味でのメディア依存性の排除、つまり(特定メディアということじゃなくて)
　> > # メディアのさまざまな要素(赤色表示とかな)への依存の排除、ということじゃないよな？
　> まさしくそれを言ってるんだが…。
さすがに「特定メディア依存ということなら関係ないよ」という話で長々と説明して
念押しして確認したことをひっくり返すのは、会話の便宜上問題だと思いますよ。

>>509
> しかし、前者が達せられないと閲覧者に不利益があるが、後者は制作者の
> 自己責任だ。だから前者の方が重要だと言ってる。
手間が減ることの重要さを考え直すようにと>468で言っておきましたが、
考え直す気すら微塵もないようなので、仕様の一部を引用して説明しましょう。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/intro/intro.html#h-2.4
　> また、文書の構造をプレゼンテーションと切り離すことで
　> 広汎なプラットフォームや多様なメディアでの文書提供コストを低下でき、
　> 文書の改訂も容易になるということが、経験的に知られている。
構造と表示の分離というのは、いくつかの目的に対するコスト低下効果が
重要なんですよ。

構造と表示が一体化してる文書でも、手間を掛ければ各メディアに
対応することはできないわけでもないんです。ただ、実際問題
構造と表示の分離があまりうまくいってない文書をさまざまなメディアや
プラットフォームで利用可能にすることは、結構な困難があります。
これが、「そんな手間は掛けられない」という理由で利用できるメディアや
プラットフォームが制限されてしまうことにつながるわけです。

話は戻りますが、そもそも重要さなんて問題以前の、仕様の問題だという
指摘がされてるんですよ。あなたがまだ無視している>496にあるように、
あなたの言ってることのいくつかは仕様を読んでないことからくるものです。
仕様を知らずに作られるStrict精神のまがいものは、一人の世界に閉じた
俺ルールでしかありません。
仕様の先を語るつもりなら、まず仕様を知ってくださいな。

> →クラスが構造に合わなくなる。（構造と表現が分離出来てない）
この左から右へのつながりが、仕様無視のあなたの脳内ルールのみという話ですね。
だから、理由になってないんですよ。よくみられる特徴ではありますが。
> 基本的にほぼ同じことを言ってるんだろうが
あなたに関しては、これは「一致してない」といい続けている通りです。
不都合を軽視して混同したままでいるのは容易いですが、ぜひStrictに考えてくださいな。

お注射しますね。

表示がどうのこうのに関係なく
赤色に関する話題だからその要素のクラス名をredとする・・・

なんかグダグダ言ってるけどこれだけの話じゃないのか？

>表示がどうのこうのに関係なく

関係ないことが明らかでないからグダグダ言ってるんでしょ

>>510
> 出来上がりの文書がよいだけではなく、作業する著者自身も表示と構造の分離を

で、それは、著者の作業内容に対する規定ではなく、著者の心の中に対する規定
だと、仕様書に書いてあるわけか？

> >507の第二段落についてなら、前提を示せなんて話はしてなくて、むしろ

話の前提が違っていたのに、お互い同じ表現を繰り返していたので、まったく
伝わらなかった。>>486 でそちらが表現を変えたので俺に伝わった。俺も表現を
変えていたら伝わっていたかもしれない。じゃあ、なぜ変えなかったかなんて
のは、そちらにも言えること。「まさか相手がそんな前提の話をしているとは
想像もしなかった」…たぶん、両者ともそういうことじゃないのか？

> >　→文書が様々なメディアで利用出来るようするため。（メディア非依存）
> またちゃっかり意味をすり替えましたね。

あらゆるメディアで利用可能にするために（目的）、あらゆるメディアへの依存性
を取り除く（手段）。…何かすり替えがあるか？　もちろん、HTML側の話だぞ。

>>511
> これが、「そんな手間は掛けられない」という理由で利用できるメディアや
> プラットフォームが制限されてしまうことにつながるわけです。

それは出来上がりが悪いからダメな状態だろ。

要するに、手間を減らすというのは手段だろ？　そして目的は、ここにも
書いてあるように、メディアやプラットフォームが制限されないことだ。
仕様書にも推奨と書かれているように、これは非常に良い手段だろう。
俺もそう思う。ただ「最良の手段」と「達成すべき目的」は違うということだ。

これふたりともストーカーになるタイプだね。

>>515
> で、それは、著者の作業内容に対する規定ではなく、著者の心の中に対する規定
> だと、仕様書に書いてあるわけか？
HTML4での著者等が従う原則だと明示されてますね。
特定の表示目的でクラスを指定する著者はこの原則に従ってませんね。

> じゃあ、なぜ変えなかったかなんてのは、そちらにも言えること。
あなたのように、相手に「別の話をするな」といわれても、相手の言葉を勝手に
いいかえて相手の主張に反論しつづけた、という意味で、こちらが
あなたの言葉の言いかえを勝手にして、もとに戻すことに応じなかった
ことがあったなら私も謝るべきですが、まずそれを指摘してください。
言葉の確認は結構念入りにしましたが。

> 「まさか相手がそんな前提の話をしているとは想像もしなかった」
あなただけです。
こちらはあなたが別の話をしているということを延々と主張し続けました。

前提が食い違っていても、素直に勝手な言い換えをやめて、そちらの前提で
「class="red"でもこういう状況ならOK」と言えば、
「いや、その状況ではこうだからダメ」と返すことで、
すぐいたるところの言葉の言い換えが分かります。
そちらの話してることが別の話だから、こちらの状況でものを語ってみろ、
というのに従わなかったのは、言葉の言いかえをやめなかったのは、なぜですか？

まっとうに作られたクラス（redtext）でもだめ、という話自体は>404で既出です。
その時点であなたが話に参加してなかろうが、キーワードで遡って検索するなりすれば
話の流れくらい把握できますよね。
>404の時点で「それを適切に表すスタイルを適用したい」なんて言ってるんですから、
それを読んでいればすぐ「いかなるスタイルも存在を一切想定してはダメ」という話題に移れたはずですが、
あなたは「クラスを指定すること=クラスを作ること」というそちらの明らかな間違いを自覚せず、
そのうえ「クラスを指定する意図→構造を変更する動機」という言いかえをいつまでもやめず、
延々と別の話をしつづけていました。

別れ話のもつれでカッとなるタイプだよね

>>515
> あらゆるメディアで利用可能にするために（目的）、
> あらゆるメディアへの依存性を取り除く（手段）。
今「(手段)として含めているから別に限ってない、すり替えじゃない」と主張してますが、
そのような一方のみを目的とする話をながながと否定した上で、
否定したような意味か、そうでないかの確認をし、あなたはそうでないと答えました。
いまあなたが意味をすりかえ話をひっくり返すのならば、
単に話が>468に戻るだけのことなんですよ。

あらゆるメディアで利用可能であっても、個々のメディアでの利用にあたって
特定の出力をすることに依存していれば構造と表示の分離に反するので、
とくに"特定メディアへの依存"に限る話ではない、ということは>468で説明しました。

手段に過ぎないというならば、スタイルシート側で
あらゆるメディアへの表示・出力に対応していたとしても、HTML側で
たったひとつのメディアについてでも特定の出力に依存していればダメです。
（他のメディアへの出力はなんでもいいけど、プロジェクタ表示では
赤色表示に依存する、などですね）
この時点で、>468でいう狭い意味でのメディア依存性はないですが、
広い意味でのメディア依存性はあります。

構造と表現の分離の原則を守ることは手段です。
それは構造と表現の分離の原則により得られる恩恵が目的です。
あらゆるメディアで利用可能になることは、その恩恵のひとつにすぎません。
　> 依存性を排除するという重要な意味があるのに、単に制作が楽になるからだけなの？
という>467から露呈しはじめたあなたの勘違い、仕様を読んで理解できましたか？
あなたが思い込んでいるような、そんな狭い目的ではないんですよ。

> ただ「最良の手段」と「達成すべき目的」は違うということだ。
それらをあなたが主張する前に、脳内前提のクリアと仕様を知ることから
はじめるといいですね。まずはそれからの話です。

プライベートな場じゃないんだし、お互いに引き際をわきまえようよ。
このまま続けることで、議論が収束すると思ってるの？
これだけ、同じ話が続くって事はお互いに相手を納得させるだけの話術も材料も持ってないって事。
このまま議論を続けても無駄にレスを消費するだけ。

自分が最後に反論しないと、なんて下らない意地でレスしてるんだったら他行って欲しい。

hnが示す論理構造の範囲
と
divが示す論理構造の範囲
はどう違いますか？

hnは
<h1>ごにょごにょ</h1>
で要素内にinline要素しか認められず閉じられているけど、ベージ全体に論理構造を示している？
このページは「ごにょごにょ」について書かれているページですよって

h2は次のhn(n>1)が出てくるまで？
h3以降も…略

divは
<div id=site-navigation>
<ol>
<li>menu list</li>
<li>about this site</li>
</ol>
</div>
とblock要素の中にblock要素も記述できるので解りやすいのですが

>>521
初心者は初心者スレへ

>>517
> HTML4での著者等が従う原則だと明示されてますね。

「著者が従う」とは行動についてか、心の中についてか、というのはどこにある？

で、以下の話は、前提が違っていたと分かった時点で、それ以上の結論が出るとは
思わんが…。そちらの想定する前提が分かってなかったので、「意図が駄目なら
真っ当なクラスを指定しても駄目」という言葉は「きっかけの動機が駄目なら
その後正しく行動をしても駄目」と解釈出来ただけ。その書き方では伝わらなかった。

>>519
なるほど、今 >>468 を読み返せば、そちらがどういうことを言いたかったかは
分かる。これも同じ話だ。そちらの想定する前提はかなり特殊な状況なので、
それが分かってないと、すべて誤解出来てしまうような書き方になっている。

で、そもそも赤くしたいから class="red" と付ける人はなぜそうすると思う。
そう考えた方が直接的で楽だからだ。後の変更が面倒になると言っても、今はそう
考えれば楽だ。…そう考える人はいる。この状況を「お前が楽にならないからダメ
なんだ」という訳か？　そんなのは自己責任だろ。メディア依存によって、他人に
不都合が及ぶからダメなんだろ？　楽になるという方が狭いんだよ。

>>523
> 「著者が従う」とは行動についてか、心の中についてか、というのはどこにある？
作業の意図がOKなら行動はどうでもいいとか、意図が原則に反していてもたまたま
結果オーライだったら問題ないとか、そのように限定している文言はありません。
HTML4での作業中の著者は、特に限定なくこの原則に従うことが推奨されています。

そしてあなたは行動とか心の中とかを明確に区別できるものとして使っていますが、
それができてないことはすでに話しましたね。あなたの前提は「構造が著者の意図に
合うか合わないかは結果に含める」「クラス名の指すところとクラスの指すところ
との合致は考慮に含める」ということでした。しかし、クラス指定の意図だけ
含めない、という前提は仕様無視なんです。表示と構造の分離を著者が守るに
おいては、そのような例外はないんですから。

著者の意図や作業目的や方針は原則に反しても結果オーライならStrict、という
主張はあなたの区別に基づきますが、それは現実とは異なります。
あなたも、あなたの考えるその害悪(編集方針として危険だとか)は述べてましたね。
あなたのいう結果オーライという（つまりは一時の文書状態のみに判断を
限定するような)免罪符は、その存在を否定する理由もあるわけです。

> 解釈出来ただけ。その書き方では伝わらなかった。
「言い換えることが出来る」というのはあなたの思い込みでしたよね。
「クラス指定=クラス作成」のあたりはあなたの間違った決め付けでしたよね。
それで相手の話をつじつまが合うように理解できなかったのですから、
それは「解釈できた」ではなく、「解釈しようとするとつじつまが合わない」ですよね。
相手の話の解釈を間違えてる兆候が存分に現れてるのに、
「クラス指定の話に戻せ」という要求に応じませんでしたよね？
それがなぜか、ということをたずねているんですよ。
> その書き方では伝わらなかった。
結果伝わらなかったのはその通りですが、いまのところあなたの勝手な読み替えと
決め付けが原因の誤解と、話をあわせる要求を突っぱね続けたことしか
明らかにはなっていません。それで書き方が悪いと言われても理解しがたいので、
>517でもこちらの同様な落ち度を指摘するように尋ねているのです。

>>521
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.5
> 次の例は、見出しとそれが導くテキストとをDIV要素で連結する方法を示している。
っていう例によれば、
見出しとテキストをdivの作る構造で括る場合には、見出しの範囲を区切れるみたいよ。
ただ、見出しとテキストを一緒に括らない場合には区切られるのか、とか、
区切らずh2が二つ以上出てくる場合はどうなるのかとか、
そのへんはよく分からん。

過去スレでも似たような話題が何度か出てるかもしれん。

>>525
div要素で連結する例は、[見出し→内容]という風に
HTML的に関係を明示すると言うほど厳格な意味じゃなくて
バラバラに並ぶ要素をdivで纏めることで、
一つの構造に連結できると言いたいんじゃないかな。

だから、見出しを一緒に括らなくても、逆に複数あっても
1つの括りという以上の意味は無いんだと思う。

おまえら二人ともトリップつけてくれ
NGにするから

>>523
> 今 >>468 を読み返せば、そちらがどういうことを言いたかったかは分かる。
で、今回あなたはなにをどう勘違いして、>467,468,470の話のつじつまが
合わなくなったんでしょうか？それすら明言をさけるようになったようですが。
「すでに"あなたが"否定済みの話に戻る」という婉曲的な書き方では
追い詰め方が足りなかったようで、あなたにとぼけたこと言い出す余地を
与えたことは申し訳ないですが。

> すべて誤解出来てしまうような書き方になっている。
あなたは相手にやめるよう言われた自分の決めつけをやめずに話し
誤解のすり合わせを拒否してましたから、こちらはあなたの決め付けが
あなたの話の範疇ですら間違ってることをあなた自身の言質をとってから
示すこと、こちらの言う状況で話のすりあわせをするよう要求すること、
両方やることになり、苦労しました。
こんな相手の逃げ道を塞いでいく話運びよりも、話のすり合わせをさっさと
行う方が当然早いのですが、それはあなたの意思なしには無理です。

> メディア依存によって、他人に不都合が及ぶからダメなんだろ？
> 楽になるという方が狭いんだよ。
別メディア利用者が理解、表示に苦労したり、著者スタイル・特定ブラウザ以外の利用者が苦労したり、
今は偶然まともなソースがクソな方針のせいで将来のクソソース量産につながる危険をはらんでいたり、
そんなクソソースをなにかに利用することに苦労したり、いろいろありますね。

> そちらの想定する前提はかなり特殊な状況なので、
そちらの主張は、いろいろ前提を組み込むことでそこそこうまく穴埋めしてありますから。
ぱっと思いつく例で間違ってる状況の量はわりと少ないです。だから、根拠がずれてるせいで
生じてる塞ぎ残しの穴を、場当たり的解決な穴埋め部分(いろんな意図を取捨選択して
結果に組み込んだり)との対比で示すことで、考え方の"間"違いを指摘する形になる。

個人が多少考えて思いつく程度でも穴があるとなると、世の中の状況でどれだけ不都合が
でてくるか想像も付かない。それが結果論的な間違いなら今あーだこーだ言っても
どちらが正しいか知るのは無理な話ですが、今分かる間違いなら今のうちに考慮しておきましょう。

いい加減トリップ付けろよ！

>>526
意味の対応付けが明確とまでは言えなさそうだよね。
だからhnでは構造化はされないか。

ただ、divとhnを併用するときは、
　<h2>見出し</h2>
　<!--テキスト1-->
　<!--テキスト2-->
と
　<div>
　　<h2>見出し</h2>
　　<!--テキスト1-->
　</div>
　<!--テキスト2-->
で、要素の連結のされ方が区別できるだろうから、
見出しの意味的にもそこそこ有意義だと思う。

>>530
　<h2>見出し</h2>
　<!--テキスト1-->
　<!--テキスト2-->
と
　<div>
　　<h2>見出し</h2>
　　<!--テキスト1-->
　</div>
　<!--テキスト2-->

上記どちらもh2によるセクション構造に変わりはない。

過去スレ全部読んで来い。
初心者は初心者スレへ。

>>531
>>530は別におかしなことは言ってないと思うよ。
divで括ることで構造を明示して要素を連結したと言うだけで
それ以上でも以下でも無いかと。

と言うか、セクション構造って何を指しているんだろうか。
>>525からの流れでW3Cのを前提に言っているとしたら、
ちょっと変な言い方じゃないかね？

>>532
構造は明示しているが要素を連結はしていない。
divというブロックレベル要素の中に入っただけ。

>>533
連結って言うのは、>>525の例にある表現に倣ったんだけど
確かに違和感を感じる言い方ではあるね。
まあ、ニュアンスを感じ取っていただけたらと・・・

>>534
違和感というか
　<div>
　　<h2>見出し</h2>
　　<!--テキスト1-->
　</div>
　<!--テキスト2-->

これ自体ないんだけど。
連結を連結とすると、連結以外は切り離されているということ。
divというブロックレベル要素の中か外か、それだけのこと。
hnのセクション構造とは関係ない。

>>535
ないと言うのは？別にそう書いても構わないと思うけど。

divの中か外かと言うことは、それだけの差はあるということだよね。
同じ階層にあるという事は、同じ括りの中にあるという事であって
連結って言うのは、それくらいの関連性を指しているだけ。
多分、言葉から受ける印象ほど強い意味では使ってないと思うよ。

セクション構造とやらとは、関係なく話しているつもりなんだけど
こういう言葉を勝手に解釈して話すのも誤解の元だし
出来れば、そちらで何を指しているのか一度説明して貰えると有難いなって。

>>536
過去スレ読んで来いマジで。
話しにならない。

>>537
話す気が無いんじゃしょうがないね。
まあ、いいけどさ。

>>538
いいから読んで来い、カス。

おまえらトリップ付けるか他所でやれ

読んできますた。後人のために重要な箇所を引用しとく。

497 ：Name_Not_Found：2007/06/30(土) 19:34:43 ID:???
>>496
お薬だしておきますね。
499 ：Name_Not_Found：2007/06/30(土) 21:05:48 ID:???
>>498
お薬飲んで下さいね。
505 ：Name_Not_Found：2007/07/01(日) 00:01:04 ID:???
俺も相手も痛いヤツにしか見えない。
文章まとめる能力を身に着けてから来い。
508 ：Name_Not_Found：2007/07/01(日) 00:40:16 ID:???
>>507
HTMLで許容されてる部分でどうのこうののスレじゃないの。
おまえも帰れ。
512 ：Name_Not_Found：2007/07/01(日) 15:47:37 ID:???
お注射しますね。
516 ：Name_Not_Found：2007/07/01(日) 22:13:58 ID:???
これふたりともストーカーになるタイプだね。
518 ：Name_Not_Found：2007/07/02(月) 10:30:59 ID:???
別れ話のもつれでカッとなるタイプだよね
522 ：Name_Not_Found：2007/07/02(月) 22:13:52 ID:???
>>521
初心者は初心者スレへ
527 ：Name_Not_Found：2007/07/03(火) 02:22:15 ID:???
おまえら二人ともトリップつけてくれ
NGにするから
529 ：Name_Not_Found：2007/07/03(火) 03:01:52 ID:???
いい加減トリップ付けろよ！

>>535
section divがhnのsectionの範疇をぶった切れるかって議論は
結局結論でなかったじゃん。
何勝手に決めてるんだ。

>>542
切れないよ。divだから。

ソースうｐ

数式中のベクトルを<var><b>a</b></var>のようにマークアップするのは
Strict的に認められますか？<var><span class="vector">a</span></var>とし
てspan.vector { font-weight: bold }とする方法だと、CSS非対応の環境で見
たときに"a"がベクトルであるとわからなくなるという問題があるけれど、物
理要素であるb要素を使うのもどうかと感じているのですが。

>>544
hnのセクション構造はhnで構造化されるから「hnのセクション構造」って言うわけで。
最後だけはbody終了タグの出現で終了になるけどね。

divやら他のなんやらでブッた斬られたり繋がったりするなら「hnのセクション構造」とは言わないよね。
文書全体の論理構造として関連付けだの意味付けだの斬れる斬れない云々なら議論の余地もあるかもしれないけど。
「hnのセクション構造」って言った時点で「hn」でしょ。
俺おかしい？

>>545
b要素でもspan要素でのスタイルでもvar要素にスタイルでも視覚的に太字になったとして、その「a」は「太く見えるa」でしかない。太字にならない環境もあるよ。
数式は数式の書き方というか補足というか、なんか読んだそのまんま書くような書き方があるよ。
定義されているのか慣例なのかはわかりません。
そちらの世界で太く見えるだけで解決するならそれはそれで。

hnのセクション構造と言うものが、そもそも幻想に過ぎないような。
h1もh2もただの見出し要素。そのセクションの範囲まで定めようというのは強引では。

セクション構造を記述する術がなければ>>530の例は両方とも妥当と見れる。
どのテキストも見出しとの関連性なんて元々無いのだから。

>>547
＞どのテキストも見出しとの関連性なんて元々無いのだから。
では、すべてのテキストをなにかの方法で関連付けしなければならないだろう。
見出しはただそこにポツンと独立している。その後の内容もそれぞれ何処にも関連なく独立しているということか。
http://www.kanzaki.com/docs/html/headings-note.html
妥当 = Validと言いたいなら異論はないが、Validスレではない。

トゲトゲしい口調で会話しなくてもいい

いきなりげんそうとかぜんひていするならこんきょをしめしてほしいにゃん
こうか？

仕事行って来る。じぁあね。

HTML4では、セクション間の階層関係をその通り意味付けする
方法がないんで、いわゆるセクションdivの実現や、見出しによる
セクション構造の表現が十分にはできない、んだよね。

ただ、divが構造を付加することによって、つまり「divの構造の中に
入る」ということが、見出しとその後続部分との連結を行うことを
表す、ってのが>525に書かれてる字面通りの話だよね。
（セクションの階層構造の意味づけはできないけど、
　見出しと連結される範囲を区切る程度は
　構造のマークアップの範疇の話だ、という例。）

ただ、「divがあってもなくても意味が同じじゃなければならない」
というようなことをいう人もいる。そっちの人の言うことはよく分からんけど。

>>524
要は、どちらの言い分も仕様書には明言されてないということ。だから、「一方の
言い分は仕様書に明言されてて他方の言い分は仕様書に反する」とするのは間違い。

「クラス指定=クラス作成」に関しては、そちらの前提に立てば等しくなく、俺の
前提に立てば等しいだけ。前提が違うのであって、どちらが間違いとかではない。

俺の言ってた「著者の意図」とは「こういう *構造* にしたい」という意図のこと
なので、そちらの言う「意図」とは指すものが違っていたことに注意。

前提が違ってたと分かった時点で、過去発言を掘り返しても「前提が違ってたから
だ」という結論以上のものは出ないのではないか？　建設的だと思えない。

>>528
前提が伝わってない相手に何度「それは違う」と言った所で前提が伝わる訳では
ないという点も考慮すべき。おかげで俺も「じゃあ、こうではないか？」と何度も
念を押す羽目になった。それをそちらが、決め付けやすり替えと感じただけの話。

一番ダメなのは、他人に不都合を及ぼす状況だ。「間違った考えに基づいているが
正しい結果を出す人」は、間違いがその人の中に閉じているので、周りに不都合を
及ぼしていない。それを結果オーライと言った。他の人が苦労するのなら、それは
既に結果が悪い状況だからダメだ。

…と、このように長々続けてることも他人に不都合を及ぼしてるので、脇道の話は
放っておいて、本論をまとめるべきだと思うが。

>>552
頭悪過ぎ

>>548
＞それぞれ何処にも関連なく独立しているということか。
W3CのHTMLでは関連性を明示できないだけと言うべきかな・・・
無論、人間は明示されてなくても見出しに対する内容を見出すだろうけど。

神崎さんのところも、HTML4にhnのセクション構造が定義されていると言ってるようには読み取れないな。
むしろ無いからこそ、hnを厳格に使う必要があると説いているのでは。
もし、hnのセクション構造があるとしたら「DTDによる見出し順序の制約」のように
＞ただし、このモデルでは、文書末尾にナビゲーションやフッタを置く場合、そのための見出しが必要になります
と同じ状況になってしまうということだよね。

末尾に置くaddressは見出しが必要って変な文書じゃないかな。
過去にも、そんな話が出て頭に置けとか色々意見が出てた気がするけど
hnの拡大解釈による弊害なのではと思う。

>>549-550
幻想って煽りっぽかったのかな・・・
そんなつもりじゃないんだけど不適切な表現だったね。
口調も気をつけるよ。申し訳ない。

否定する根拠は、HTML4.01の仕様書を見る限り、そうは読み取れなかったから。
逆にセクション構造があると言うのは何を根拠にしているんだろう。

>>552
＞divがあってもなくても意味が同じじゃなければならない
これが言われるのは、主にdivでセクションを区切れるという主張にたいするレスのような気がする。
divが無いとhnの範囲が変わってしまうのはおかしいと。
これもHTMLにセクション構造があるという前提の話だね。

>>555
仕様書の書き方は微妙だから、どちらとも解釈出来るんだよ。

ただ、HTML2.0の仕様書には「セクションの見出しを表す。見出しレベルは飛ば
すな」と書かれているので、HTMLにとって見出しセクションというのは昔からの
考え方だ。ただ、HTML4.0では「飛ばしてはダメだという考えもある」みたいな
後退した表現になっているので、HTML2.0ほど明確なセクション構造はないとも
読めるかな。

他にも、HTML2.0では「HR要素はセクションを区切る。代表的な表示方法は
横線を引く」と、あくまで論理要素として書かれてあるので、見出しセクションが
あってもHR要素で区切ってその後にADDRESS要素を書くという使い方が意味を
持った。ただ、HTML4.0では「HR要素は横線を表す」と物理要素のように
書かれているので、これまた微妙になってしまった。

セクション構造に関しては、HTML4.0はHTML2.0より後退していると思う。

>>553
> 要は、どちらの言い分も仕様書には明言されてないということ。
あなたの言い分に反する書き方がされてる仕様を認めたくないのは勝手ですが、
事実として、「結果オーライ」なんて限定なく、HTML4の作業において原則に従うよう
書かれているのですから、「いや、ここは（俺定義の）作業者の心の中は
含まれないとも読める！」というのは事実に反します。

また、あなたの主張においてアドホックに結果に著者の意図を含めた「結果オーライ」
では危険な編集方針になることはあなたが理解していることで、ゆえにその点おかしい
のもあなたの理解しているとおりです。
（仕様にあなたが期待しているような限定があるべきでない一つの理由になりますね。）

> 前提が違うのであって、どちらが間違いとかではない。
> そちらの言う「意図」とは指すものが違っていたことに注意。
単に違う前提で話していてすれ違ったのではないですよね。
相手が「それは違う話だ。こういう状況での話をしろ」と指摘しているのに
これに従うことを拒否して話をこじれさせた点についてのあなたの意図を
尋ねているんですよ。

> 前提が違ってたと分かった時点で、過去発言を掘り返しても「前提が違ってたから
> だ」という結論以上のものは出ないのではないか？　建設的だと思えない。
現状では私は一方的にあなたが悪いという言い方をしていますが、しかし
あなたは私も悪いと言っています。もし私にあなたのように悪い点があるなら、
すなわち私は過去の議論を正しく認識してないのですから、これ以降も建設的な
議論に近づくことができなくなってしまいますよね。
建設的な議論のためには、議論の仕方におかしい点が残っているなら、それを
明らかにしなければダメです。話の勝ち負けで遊ぶゲームじゃないんですから、
あなたが、私も同じことだとか、私の書き方がおかしいとか、そういうことを言ってる
のは反論のための反論ではないと思いたいです。しかしそのわりには具体的な
指摘をしませんから、何を意図してそんなことを言ってるのか理解しかねるのです。
すでにあなたは私が悪いという旨の主張をしているのですから、次は詳細を指摘して
相手に理解させることが必要なのですよ。「お前が悪い」だけでは片手落ちです。

>>553
> 前提が伝わってない相手に何度「それは違う」と言った所で前提が伝わる訳ではない
それを考慮しているから、違う話になってるから"こういう状況として話せ"、と言うんですよ。
そうして話の違いを減らすことで、捉え方の違いをより明らかにしていきます。
「同じだから変えなかった」などとしてそのすりあわせの第一歩から否定したのがあなたですよ。

（前提の違いの話ではないですが、）今も「建設的でない」とか言って話のすりあわせを
拒否してますが、そんな態度でおなじ手を使って議論をこじらせる方がよっぽど建設的ではないです。

> おかげで俺も「じゃあ、こうではないか？」と何度も念を押す羽目になった。
それ自体はたんなる話のすりあわせですね。その中であなたが勝手においた
決め付けを指摘してますが、「俺の前提では決め付けれるから応じなかった」
ということで、すりあわせが進みませんでしたけど。

たとえば>>441では「クラスを作ることが指定することと同一だ」とか
「クラスを指定する意図の話と構造を変更する動機の話は同じだ」とかいう
自分の前提での勝手な決めつけを当時行っていたそうですが、
直前の>439や直後の>442においてさえ、後者については指摘されてますね。
にもかかわらずそれ以上の話のすり合わせをあなたは拒否してます。
442についてはもう何度も指摘してることですね。あなたはそれを認めませんが、
それはつまり今後も同じことを繰り返すということですから、それは困ります。

で話は戻って、議論の後半であなたが言葉の確認をするとき、
「自分はこういう意味で言っていたのだが」ということをよく言ってました。
しかし過去の話をそういう意味として解釈するとつじつまが合わなかったり、
過去に「こういう意味だ」と言ってることと違ったりしてました。
そのことをすり替えだとか決め付けだとか指摘されているわけです。

> それをそちらが、決め付けやすり替えと感じただけの話。
具体的な指摘があるのに、それを放って総論的な話に逃げないでくださいね。
そんなことをするから話が何十レス分も遅くなるわけです。
>528第一段落について説明をしてくださいな。

空気読まずに見出しの話。

ttp://www.rusica.net/note/2007/06/30/css_8.html
ttp://www.akatsukinishisu.net/itazuragaki/html/h1_is_the_most_important.html

自分はサイト名を h1 としている。以下、理由。
Aさんが書いたBという記事を読むとき、自分が重視しているのはAの方。
Bという記事を読んでみようかと思うことがきっかけでサイトを訪問するので
表面上はBを重視しているように思えるが、
個人的にはどんな人がそういう記事を書いているのかということを重視する。
サイト名はハンドルと同じように、ネット上で個人を識別するための大切な情報であり、
個人的には記事の題名よりも重要だと思っている。
よって h1 の内容がサイト名であることはまったく問題ない。
また、サイト名はひとつの文書群につけられた名前だとも考えている。

補足。
HTML のことを知らない人が HTML の記事を書いたとしても読む気にならないとか、
宣伝だらけで本文はどうでもいいことしか書いてないとか、
そういう例を考えてもらえればわかりやすいだろうか。
つまり、記事を書いている人が誰なのかということは、記事の信頼性に関わる。
もちろんこれだけの理由ではないけど、理由のひとつを出してみた。

>>553
> 「間違った考えに基づいているが正しい結果を出す人」
あなたの前提で結果と意図を取捨選択すると「正しい結果」になりますが、
実際にはそうではありません。

まず、「著者のクラス指定の意図が表示と構造の原則に反する」のは
仕様違反です。（仕様違反の件。）

つぎに、あなたの意図の取捨選択は、その仕様違反と、あなたも認める
危険性とをともに見落としているので、Strict的にダメです。
(前提の違いではなく単に間違いだという件。)

で、クラス指定の意図もあなたのいう結果に含めるなら、これは単にダメな結果です。
結果に含めなくとも、著者の意図が間違っている点でその文書はダメです。
間違った意図自体もダメですし、それでは意図が伝わらないという点もダメです。

> 間違いがその人の中に閉じているので
改訂コストが高くなったせいで文書が改訂されなくなれば、困るのは文書の利用者です。
「その時点では結果オーライ」というのは結局「その時点ではまだ他人に被害が及んでない」
ということにすぎないですよ。しかし危険性はすでに生じ、存在しつづげていくんです。

　>519> あらゆるメディアで利用可能になることは、その恩恵のひとつにすぎません。
　>528> 今は偶然まともなソースがクソな方針のせいで将来のクソソース量産につながる危険をはらんでいたり
と言われて、メディア対応と文書の改訂について書かれた仕様を読んで、
なおメディア対応のことしか考えが及ばないようでは、それは独り善がりなエセStrictですよ。

> 他の人が苦労するのなら、それは既に結果が悪い状況だからダメだ。
たとえ他人が苦労しなくとも、意図が伝わらないのはダメですよね。
著者のオススメに過ぎなかろうが、オススメする意図があるならば
当該外部スタイルシートと当該HTML文書との関係を適切に明示しなければ
なりませんし、特定の表示をする意図があるなら、HTMLでそれを意図するんじゃなく
外部スタイルシート側の記述などによって意図を表現しなければ伝わりません。

>>555
> これもHTMLにセクション構造があるという前提の話だね。
あー、見出しによるセクション構造がすでにできているとすれば、
divに関わらず成り立ってると考えないといけなくなるか。

その場合仕様書の例は、見出しによるセクション構造と一致する構造を
divで示している例、という解釈をすることになるわけね。

HTMLが本質的にセクション構造と不可分なものだと考えるか、
セクション構造も表現できるけどべつに従う義務はないと考えるか、
どっちなんだろうなあ。

HTML4ではっきりしなくて、ISO-HTMLでははっきりしてるんだよね、たしか。
>556によれば、HTML2.0でもはっきりしてるのか。とするなら、このスレ的には、
理想の仕様としてはどっちであるべきか、という話になるのかな？

>>559
>39あたりからの話が参考になるかも。

商標というかブランド名というか、まあそんな大げさなものじゃないけど
サイト名も似たような意味合いはあるよね。
ただ、常にサイト名をページに表示しておくと見栄えがいいから
とかなると駄目だと思うけど。

一ヶ月ぶりにきてここまで読んだ。

red の二人はまだ結論というかまとめ出てないのね・・・。
もう前提とか返答がない、とか一旦置いといて一から話しなおしたほうがわかりやすい気がするｗ

hnとdivのセクション構造の話は前スレでさんざんやったよね。
結局双方譲らず結論も総論もでなかったが・・・。

サイト名をH1にするのは自分は反対だが、いろいろ意見きいててありっちゃありかとは思った。
ただ、<h2>本文</h2>〜<h2>フッター</h2> とか書くのはまだちょっと抵抗があるなあ・・・。

そう、総論も結論も出なかった。
なのに勝手に一人で結論出してるアホがいた。
それだけの話よｗ

>>563
事故照会乙

521です

hnのセクション構造はありえる

hnのセクション構造はありえない

色々意見があるのですね


hn section で論理構造(樹形図)の縦関係を示せる
(4.01でsectionは仕様書にないので<div class="section">で代用？)

<div id or class="x">は横関係を示せる
そしてhnを股がない(縦関係と横関係を混同しそう)


たくさんの意見があるので、こう思い込む事にします
ありがとうございました

一番良いのは「hnのセクション構造はありえる」でdivは使わない…かな

hnのセクションがないって仮定すると、
見出し
内容
見出し
内容
見出し
内容
…となんの関係も関連も意味付けも連結もなくただ並んでいるだけってこと？
「見出しの後ろの内容は、見出しの後ろにある内容でしかない」ってこと？

>>566
>565でいうセクション構造の縦関係が表せないんだから
どのみちhnセクションはなくね

>>567
じゃあ、ないとして、どうやって関連付けますか？
Strict的に関連もなにも要らないと？

だからiso htmlではsectionがあるし、
xhtmlでhnにsectionつけるようにされるってことでしょ。
現状のhnに対するsectionの概念があいまいすぎてダメだったって事。

html5でもsectionとか追加されるのかね。
でもそれ使うとそれこそdiv厨みたいにsection厨って言いたくなりそうな程多用しないといけなく・・・
インデントとかするとh4〜6だと深すぎ。
さらにdivとかtableとかdlが入ってくると訳わかめ。

>>557
細かく書かれてないということは、「全部」とも「一部」とも言えないということ
だ。「全部」とは「一部ではない」ということだから否定の限定が付いている状態
だよ。そこを分かってる？　「仕様書からはどちらとも言えない」が正しい。

こんな長い議論を延々とここで続けるのは、周りに迷惑だというのは分かってる？
それこそ勝ち負けじゃないんだから、Strict論そっちのけで過去発言を検証し直す
などという不毛なことはやりたくないということ。

>>558
自分の発言が伝わったはずだと思えるのは、自分自身が自分自身の前提を知って
いるからだ。自分の前提から脱却出来ないと、それを認識出来ないと思う。

あと、俺はそちらの言いたい事が分かってからは、そちらの前提に立った発言も
多くしているので、そちらの定義に従った言葉を使っている部分もあるから注意。

528第一段落って、もはや何について説明して欲しいのか分からんぞ。具体的に
何を説明して欲しいんだ？

>>560
class="red" とする人はそう考える方が楽だからと前に言った。変更時に
あちこち変えなきゃならないとしても、ツールを使えば、極端に面倒という
程でもない。それより頭を使って構造を考える方が面倒と考える…そういう
人もいるんだ。結局、どちらが面倒と考えるかはその人による。だいたい、
そんなに劇的に楽になるのなら、世の中みんなStrictになっている。

あと、「結果オーライ」とは「問題なし」の意味じゃないぞ。どんどん俺の
言った言葉の意味を変えてないか？　それから俺は、どちらも重要だがどちらが
より重要かという話をしてたよな？　「…しか考えが及ばない」か？　そりゃあ、
そんな読み方をしてたら相手がはぐらかしてるようにも見えるわな。

>>566
hn要素がセクションまで決定するとなると
<h1>foo</h1>
<h2>bar</h2>
<h3>baz</h3>
<p>bra bra...</p>

<p>Copyright (c) someone</p>
<address>[email protected]</address>
こういう構造のページがあったとき、いわゆるフッタの部分までh3のセクショ
ンに含まれてしまって都合が悪い。ということで、自分はhn要素がセクション
までは決定しないことにしている。

>>571
都合が悪いからないことにするわけかｗ
おまえ百回死ね。

> <p>Copyright (c) someone</p>

これがStrictな記載じゃない気がする。meta要素じゃないのか

>>573
はぁ？

574 名前：Name_Not_Found[sage] 投稿日：2007/07/05(木) 01:06:13 ID:???
>>573
はぁ？

>>571
文書の権利者・文責はaddressの中でおｋ

>>573
メタデータ類は、可能ならmetaじゃなくて文書本体中でマークアップしてもおｋ
metaでもいいけど。

>>556
以前は、もっと具体的にセクションを扱っていたんだね。
何でその辺を曖昧にしてしまったんだろう。

>>568
関連付けなければならない理由は、なんだろう？

例えばHTMLは、日本語の意味段落と形式段落を書き分けられない。
書き分けられないなら書き分けなければいいと、論文のように書いている人もいれば、
div+pやp+span(br?)といった形で構造化しようとする人もいる。

構造化する方も、片方にしかパラグラフの意味を与えられていないけど、
それでも構造化する理由は、日本人に馴染みのある文書構造を再現して可読性を上げたいからかな。

セクションにしても、無いとすれば無いままでも構わないのでは。
何らかの理由でセクションを構造化するのなら
仕様書の例のようにdivで構造化すればいいってことになるんだと思う。
divがセクションになるって事ではなくね。

いわゆるセクションだと、
　<h>見出し</h>
　<section>セクション内容</section>
という感じになるから、HTML4の仕様の例のような
　<div class="セクションと見出しの連結構造">
　　<h1>見出し</h1>
　　<!-- セクション内容 -->
　</div>
という形とは構造が違うんだよね。

HTML4の意味づけとしては、見出しと、見出しと何かとの連結構造、
そこまでがマークアップの限界だよね。

hn要素があればそれ以降の適当な見出しまでがセクションになる、とすると、
要素としてマークアップされてない部分にまで意味づけがされることになっちゃう。
それはHTMLの考え方じゃない気がする。

>>578
いや、xhtml2.0のことを言ってるのなら、普通に
　<section>
　　<h>見出し</h>
　　<p>セクション内容</p>
　</section>
じゃね？ (→ http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-block-text.html#sec_8.9.)


実際、>>571 のいうように、hnセクション構造だけだと、
文書下部に (c) とか ナビゲーションとか書くとすれば都合悪いんよね。
だったらナビゲーションとか書かなきゃいい、とか、文書上部に書けばいいじゃん、
なんてのは現実的じゃないから解決にならんわけで・・・。
「<hr /> でセクションを区切れる」、ってのが有効ならまだいいがなあ・・・。

あと、
　<address>Copyright (c) someone</address>
ってのは address 要素の 「連絡先」 ってのを示してないからNG、とか上でいってなかったっけ。
　<address>Copyright (c) <a href="mailto:[email protected]">someone</a></address>
とかならアリかと思うが。

ってか話題はやっぱループするねｗ 未解決な分野だからしょうがないがｗ

<h1>foo</h1>
<h2>bar</h2>
<h3>baz</h3>
<p>bra bra...</p>

<h2>footer</h2>
<p>Copyright (c) someone</p>
<address>[email protected]</address>

これでOK｡

>>577
関連付けなければならない理由。
見出し
内容
見出し
内容
という並びが、ただ単に並んで書いているというだけで、なんの関連付けの概念もないとすると、極端な話し、見出しに対しての内容をどの順番で書いて良いということにもなりませんか。並び的にとんだり、またいだりも自由ということになりませんかね。

>>580
(・｀Д・´；

Copyright
(c)
＆copy;
はベルヌ条約に基づく表記です。「2004-2007」こんなんを入れないと正式表記ではありませんので。
正式でも正式でなくても書いても書かなくても日本国内ではたいして変わりませんが。

>>579
見出しの次になんか要素がくるのはISO-HTMLのh1とdiv1の方だっけ？
とりあえず>578はxhtml2の方のつもりで言ってたから大間違いだね。すまん。

ということは、xhtml2では見出しの範囲は見出しかそれを括るsection以外では
制限されないんだよね？html4と同じ問題があると思うんだけど、とくに
トップレベルではどうすることになってるんだろ。

> ってのは address 要素の 「連絡先」 ってのを示してないからNG、とか上でいってなかったっけ。
会社紹介での会社の住所とかを「住所だからaddress」というのはNGで、
単に見出しの役割のサイト名をaddressにするのもNG、という話だったような。

名前もメールアドレスも、文書の連絡先を示す意図ならOKなんじゃね？
必ず連絡先をuriとして表現した上でハイパーリンクを設定しなきゃいかんわけでもないだろうし。

>>581
HTMLで定義できないものってたくさんあるけど、
それ全部に同じこと言うの？

>>584
定義出来ないのが前提なわけですか。
じゃあ見出しの意味なんかないですね。見出しと内容はバラバラでも良いと。
読んだ人間が頭で考えれば良いんですね。

>>585
見出しの意味知らないの？

>>584
> トップレベル
<body> 直下の <h> が <h1> の役割みたいな感じ。

ただ、xhtml2 では <h1> も残ってるので、
(1) <section>→<h> でセクション構造を表すか、
(2) <hn> で hnのセクション構造を表すか、
は製作者の裁量、・・・って上でも誰か言ってなかったっけ。

html4 や xhtml 1系 でも (1) の構造を表現したい、って人が <div class="section">→<hn>派で、
そりゃできんだろ、hn でしかセクション構造を表せないし、div はただの divだから構造区切れない、ってのが hn(iso)派。

これを前スレでやってたってわけ。
認識は深まったものの、結論はでなかった。

>>587
xhtml2でも同じ問題が…ってのは、>571みたいに
<body>
<address>...</address>
<h>
<p>...</p>
<section>...</section>
<section>...</section>
<div class="footer">...</div>
<body>
とかする場合、address部分やfooter部分の扱いは
どうなるんだろうなあ、というような話。


あと、話としては
(1) セクション構造の表現は無理だから見出しに対して構造を付加しておく程度が限度
(2) hnでセクション構造が表現できるから、それに関してはdivの作る構造なんて無関係
という感じだと思う。

>>581
それは、ちょっと飛躍しすぎじゃないかな。
その考えが成立するためには、要素の並びにも意味が無いことが言えないと。

その為には最低限、あらゆる要素について前後関係が仕様化されていると言えなければならないけど
DTDに無い前後関係を明記しているのは、ul, olくらいなもので、
あらゆる要素に順序の定義があると考えるのは少し無理があるように思う。

それにHTMLは仕様書に逐次表示のためのアドバイスがあったりと、
頭から順に処理することを前提としているように読める。

ついでにHTMLの仕様というには少しずれるけど、DOMでも要素は配列としてアクセスできて、
順不同リストでさえ並び順と異なる配列になることは無いはず。

>>585
＞読んだ人間が頭で考えれば良いんですね。
それはあながち間違っていないと思う。
結局のところHTMLは、メタデータの集合ではないわけだし、
意味づけ、構造化されなかった部分は、人間が判断することになるかと。

>>588
ああ、おｋおｋ

んー、section - h が 1対1 の関係であれば考えやすくていいのだけど、

> http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-structural.html#sec_8.8.
　<section>
　　　<p>....</p>
　　　<h>This is a second-level heading</h>
　　　<p>....</p>
　　　<h>This is another second-level heading</h>
　　　<p>....</p>
　</section>

こういう例もあって、
見出しとセクションは対なんだけど、必ずしも一対一の関係ではないんだよね・・・。
body - h でも同じ。

（以下自分的な解釈だけど）
これは、見出しでセクションを表すとか、見出しでセクションを区切ってるとかじゃなくて、
そのセクション内の見出しは、そのセクション内でその見出しの後に続く一連の項の見出しでしかない、ように思う。
（もちろん、これでセクションの内容自体は見出しで表せていることになっているのだけれど）

で、>>588 の例で言うと、
address は一番上のセクション(body)の子であって、それはその文書自体の address だからいいとして、
footer は、そのままだとやっぱ 見出し body-h の内容の項になっちゃうと思う。
body-h が 1つで、title と同じならまだいいのかもしれないけど、2つになったときは困ってしまうな。

でも、xhtml2.0 には <separator> という要素があるみたいだから、それで区切れそうな気はする。
これも今は <hr> の回帰的解釈で代用できればいいのだけど、ちょっと微妙・・・。

> そのセクション内の見出しは、そのセクション内でその見出しの後に続く一連の項の見出しでしかない、ように思う
極端なこと言うと、dlにおける複数のdtとddの対応と同様の
<h1>...</h1>
<h1>...</h1>
<h1>...</h1>
<p>...</p>
というような、
ひとつのセクションに観点の異なる複数の見出しをつける書式も考えると、
同レベルの見出しでセクションが切れると言えるかも微妙なんだよね。

h1が三つというのは極端過ぎるけど、複数の見出しは新聞なんかでも
よく見られるもので、それら見出しに必ずしも重要度を1,2,3と順序付け
できる(されるべき)とは限らないだろうし。

雑誌のインタビュー記事なんかだと、インタビュー内容の区切りを
明確にせずに複数の見出しを挿入する場合もある。その場合は、
見出しが指す範囲が、見出し以降だけではなく、見出し以前も
含めたその周辺となるということになる。

見出しにまつわる書式って、いろいろあると思うんだよね。だから、そのうちの
どれかの書式にHTMLの範囲で限定しなくとも、または限定されるよう無理に
こじつけなくとも、あいまいなのは自然なことじゃないかと思う。

もはや見出しにはたいして意味がないね。

その辺も一部の人には文書がおかしいとか言い出すからなぁ。
ttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-structural.html#edef_structural_h
って構造の文書だった場合、どうやって表現するのって聞かれて
無理やりhnを捏造してくっつけようとするし。

あとdivで構造付与してもhnの範疇は区切れないって訳わからんわ。
グルーピングしてるんだからグループそれ以外とは別になるだろうに。
そんな半端なまとめる印にしかならないならブロック要素である必要さえないのに。
hnとかと対等なブロック要素なのにhnの持つsectionに負けるのかよ。
hnがdivの範疇をぶった切れるなら納得だけど、それじゃ元も子もないしな。

じゃあもれなく全部divで。
それがstrict。

>>593
divがそんなに強力なら、どうしても適切な要素が見当たらなくて、lang属性の為だけにdivを使うのは無しになるんだよ。
ブッた切られるから。

classで識別しても良いけどね。それならそんな強力な重要な意味を持つclassは全部に付けるべきだね。

>>595
> lang属性の為だけにdivを使うのは無しになるんだよ。
どういう例？

強力ってなにそれ？ｗ
divはただのブロック要素だろ。
それ以上でもそれ以下でもないし、ぶった切れるとしたらどんなブロック要素でも同じ。
divでくるんであったとしても、ただそういうまとまりがあるってだけだ。

ひょっとしてdivでくるむとh2とh3みたいに重要度が変わると思ってるの？ｗ

>>597
ブッたぎれるってか、hnのセクション自体が幻想派の人にとっては、ブッたぎれるもなにも最初から切るべきセクションなんてないってことだよね。

>>597
> それ以上でもそれ以下でもないし、ぶった切れるとしたらどんなブロック要素でも同じ。
<form>
<h2>...</h2>
フォーム内容
</form>
ってあったら、見出しはフォーム外の部分には係らない、ってことだよね。

「構造を加えても見出しによるセクション構造には関係ない」という人にとっては、
この場合、form内の見出しはformより大きいセクションに対応する、というセクション構造を
作るんだよね。見出しがformの外まで及ぶという。

<h1>タイトル</h1>

<h2>はじめに</h2>
<h3>このファイルについて</h3>
<p>これはABCについて書いてるファイルですよ</p>

<h2>本題</h2>
<p>ABCっていうのは〜</p>

これはnot strictですか？
つまり、
<h3>まであるところと、<h2>までしかないところがあるのはだめですかね？

どういう理屈だ

俺は、Hnは「ここから下がこんな内容」という要素だと思っている。
次の同じレベルのHnでるかそのHｎが属しているブロックが終わるまでの内容の見出し。
見出しの前にその内容の一部や全部が来るケースは見栄えの問題。

＃上から見ていって同じレベルのHnが出たら見出し変数が上書きされるイメージ。
＃そのHｎが属しているブロックが終わってしまうとローカル変数は破棄されるイメージ。
HTMLって、コンピュータがパースしやすい様にするのも重要だし。

フッターやナビゲーションは、
やはり<h2>フッター</h2>や<h2>ナビゲーション</h2>で
見出しをつけてCSSで非表示とか。

そして<h1>がサイト名なのはOKか否かは、
フッターやナビゲーションに書く内容を想像してみればいい。
そこに書かれたのが、その記事についての案内のみならば<h1>は記事の大見出しだし、
そのサイトについての案内ならば、<h1>はサイト名になりうる。

>>600
余裕でおｋ

フッターやナビゲーションに付ける見出しがまんまではダサいので、
そこは、<h2>著作表示</h2>とか<h2>サイトメニュー</h2>とか適当に。

補足すると、俺の意見だと、下記の二つはほぼ同義。

<h1>サイト名</h1>
<div class="section">
　<h2>記事タイトル</h2>
　<p>記事内容</p>
</div>
<address>著作情報や連絡先</address>

<h1>サイト名</h1>
<h2>記事タイトル</h2>
<p>記事内容</p>
<h2>フッター</h2>
<address>著作情報や連絡先</address>

＞ <h2>フッター</h2> や <h2>ナビゲーション</h2>

個人的な嗜好だけど、これちょっと気持ち悪いんだよねえ・・・。
というのも、例えば、次のようなの記事があったとする。

<h1>世界びっくりニュース</h1>
　<h2>2007/07/05</h2>
　　<h3>ファッションに頭を悩ます新防衛大臣</h3> 〜本文略〜
　　<h3>シンガポールの主婦、eワラントの取引コンテストで優勝</h3> 〜本文略〜
　<h2>2007/07/04</h2>

で、「2007/07/05 のニュースだけを集めたページを作ろう」 としたとき、
その 「2007/07/05のページ」 では、
h2→h1、 ｈ3→h2、・・・というように、全ての見出しレベルが1つずつずれるわけだけど、

<h1>世界びっくりニュース</h1>
　<h2>ナビゲーション</h2>
　<h2>コンテンツ</h2>
　　<h3>2007/07/05</h3>
　　　<h4>ファッションに頭を悩ます新防衛大臣</h4> 〜本文略〜
　　　<h4>シンガポールの主婦、eワラントの取引コンテストで優勝</h4> 〜本文略〜
　<h2>フッター</h2>

こういう構造にすると、「2007/07/05のページ」 では、
h3→h1、ｈ4→h3、・・・というように h2 レベルだけを飛ばすようになる。 h2だけは動かない。

これではセクションや見出しの 階層性 や 連続性 が邪魔されてしまうんじゃないかなー、と・・・。
そもそも、果たして 「見出し」 であるのだろうか、ただのそのブロックの名前というかIDみたいなものでは、と。

> A heading element briefly describes the topic of the section it introduces.
> Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
　> 見出しの要素は、その章・節で述べられる話題を短く記すものである。
　> 見出し情報は、ユーザエージェントによって、例えば文書の目次を自動生成するために用いられたりもするであろう。

　　　　　　　　　　　↑こういうときにも <h2>フッター</h2> などは不必要な情報になるのではないかと・・・。

strict とは関係ない話だったらすまない。

「じゃあhnの代わりに何で書けばいいの？」 とかは自分の中でも答えは出てないんだけどもｗ

>>605
<h1>世界びっくりニュース</h1>
　<h2>2007/07/05</h3>
　　<h3>ファッションに頭を悩ます新防衛大臣</h3> 〜本文略〜
　　<h3>シンガポールの主婦、eワラントの取引コンテストで優勝</h3> 〜本文略〜
　<h2>フッター</h2>

なぜこのようにしないのですか｡

話の流れから外れてしまうけど、
何で「著作情報や連絡先」等を最下部にマークアップしなきゃいけないの
見栄え？

ページ内に見える形で表示させるにしても、
h1をサイト名にするかページ名にするかは意見が分かれるようだけどいずれにせよ、
見出しレベルがサイト名から始まる（h1がサイト名）なら
そのh1の下にでもナビゲーション類といっしょに配置、
見出しレベルがページ名から始まる（h1がページ名）なら
そのh1の上にでもナビゲーション類といっしょに配置
でいいんじゃない

手紙やメールだと文章の最後に署名が入るルールがあるっぽいけど
htmlドキュメントは最後に署名を入れないといけないわけでもないし

<p|div id="footer">でいーじゃん。

>>608
誰も

> 「著作情報や連絡先」等を最下部にマークアップしなきゃいけない

なんて言っていませんよ｡

しなきゃいけないとは言ってないけどしたがっている人はいるよね
上に

>>607
日付見出しとフッタ見出しの重要度が違うと考えたんじゃね

>>608
「連絡先」「本文」「サイト中のナビ」などと構造を分割して、
それらの順序を考えるときに、いろいろ考えた末じゃね？

連絡先とかナビが先にUAに読み込まれることになるのは
逐次表示の邪魔になる、と考えたりとか。

>>610-611
誤解を招いて申し訳ない、
訂正↓
×しなきゃいけないの
○したがるの

> 構造を分割して、
なんて言ってるけど結局は
> 表示

セクション構造があるっていう人から
あまり仕様だとかの具体的な理由が伝わってこなくて、根拠が良く分からない。
で、無理やり考えてみたんだけど、HTMLの仕様としての文書構造と
人間が把握した文書構造をごちゃ混ぜにしてしまっているんじゃないだろうか。

1. hnは見出し(HTML）
2. 見出しに続く文章は見出しの内容(人間？)
3. 内容の終端は次のhn or divの終端(HTML)

2が人間の裁量で把握されているのならば
3も人間の裁量で柔軟に決められるべきなのに、
各自がHTMLレベルに落として厳格に定めようとしている為に
落としどころが見つからなくなってしまっているような。

それとも仕様では無いけど、セクション構造という概念を導入することで
よりStrictなマークアップを目指しているのだろうか。
もしそうだとしたら、divで区切れない派は厳格にしようとするあまり
末尾にaddressが置けないとか、かえって歪になってしまっているのでは。

>>608
最下部に置くのは、文章末尾に連絡先などを書くという文章構成だから。
文書を読まずにコンタクトを取りたいと考える人は少ないだろうし、
内容、連絡先という流れは、理にかなっていると思う。
逆に連絡先という信頼性に関わる部分を開示してから、内容という考え方もできるかも知れない。
どっちにしても、書きたい構成をそのまま書ければ一番いいでしょう。

とはいえ、どうしてもHTMLがその文章構成を実現できなければ、
構成を変えるという選択肢も考えなければならないけどね。

>>607
「フッター」 が 「2007/07/05」 と同列だと、
「フッター」 っていう 「ニュース」 があるように見えない？

<ul>
　<li>記事A</li>
　<li>記事B</li>
　<li>フッター</li>
</ul>

↑ニュアンス的にはこんな感じに見える

>>608
strict うんぬんというより アクセシビリティ では。

スタイルシートなどのないブラウザで閲覧者を考えたとして、
本文より先に、本文に関係ないナビゲーションやら連絡先やらがごちゃごちゃあったら、
本文の始端を探すのに結構苦労すると思うよ。
新聞の上の方に広告があったり、雑誌の前の方のページがほとんど広告なようなものでしょう。

でもそういうスタイルもありっちゃありだから、やりたいひとはやればいいんでない？

divで区切れない派だと、hnはそれが見出しである以上の意味を持たないと考えるか、
もしhnが内容を表すことができるなら、（専用の見出しを書かない限り）フッターは書けなくなる。

俺はフッターの問題に悩んだ末の、divでも区切れる派なんだが、
内容の終端は、「対象のhnからみて下位レベルではない次のhn」と
「hnが存在したブロックの終端」のどちらか先に来た方。

ブロックレベル要素って言うのは、ひとかたまりに纏めるものだ。
一つのブロック要素の中にある見出しの内容がそのブロックを超越する
ということは、構造が互い違いになる事を意味するのでこれは問題。

例えば、
<body>
<h1>みだし</h1>
<p>うんたらかんたら</p>
</body>
もその見出しの親ブロックが閉じること（</body>）で終端になると考える。

そしてdivも同じ理屈だが、セクションという特別なものを用いているのではない。

> divで区切れない？

これは、「逆に考えるんだ」 的発想な上、状況証拠にしかならないんだけど、

<p>文章A</p>
<div id="B" calss="section">
　<h2>見出しB</h2>
　<p>文章B</p>
</div>
<p>文章C</p>

ってのがあって、んで、

<style>
.section { border:1px solid; }
</style>

とスタイルを付与された場合、B に枠がついて、
見出しB は 文章B に係っていて、文章C には係ってないようにしか見えないじゃんね。

もし 見出しB が 文章C に係ってるとするなら、
逆に、こんな、たかが枠ひとつの 「見た目」 で誤解を与えてしまいかねない 「構造」 って何よ？
そんなだったら、「そんな誤解を与えないために、文書作者が見た目を決定しなきゃいけない」 ことになってしまわない？

親要素で区切られる、と思うほうが自然なのでわ。

divで区切れるとか、divを無視してhnだけで範囲が決定するとかじゃなくて、
そもそもHTML的には見出しが係る範囲なんて意味付けされない、とかは？
HTMLの外のルールに従って解釈するべき事柄なのかもしれない。

本などで第二章の最後に関係無いコラムが書いてあった場合なども
第二章の範囲に含まれるのか否かは明示されている訳ではない。
見出しはその内容がここから始まるというだけで、終わりは表さない。
「hnは暗に内容の範囲を表すことはない」ということだろう。

しかし、「hnが暗に内容の範囲も表している」としたらdivで区切れるはず。
それは>>619の様なマークアップで文章Cも見出しBの内容の場合は、
>>618の解説のように、互い違いになっている訳で論理構造がおかしい。
「hnは暗に内容の範囲も表しているが、divで区切れない」というのは認めづらい。

よって、「hnは内容の範囲を表さない」か「ブロック要素で区切れる」のどちらかだろう。
実際は前者なのだろうが、実際問題として構造化の一環でブロック要素で囲っておけば、
「見出しと内容」を機械的な抜き出しをした場合の精度が増すことになる。

>>620
> A heading element briefly describes the topic of the section it introduces.
　> 見出しの要素は、その章・節で述べられる話題を短く記すものである。

「で、その章・節 (セクション) ってのはどこまでよ？」 って話をしてんじゃね？

脚注は？ページ末ではなく後注として専用の註釈ページを別途用意？

脚注は補助的なもので一連の文章の構造を妨げないように
普通は見出しレベルは与えないよね？

Wikipediaでは見出しレベルを与えてるけど
// 例えば
// http://en.wikipedia.org/wiki/Footnote
// など
WikipediaなどのWikiはたいてい
一つの文章が一ページで完結する場合が多いだろうから
有りかもしれないとしても、

一連の文章を複数のページに渡って記述する場合
// 主にドキュメント類、例えば
// http://www.python.jp/doc/release/tut/
// のような文章の場合
は各ページの脚注に見出しレベルを与えていたら
文書全体の構造が変わってくるよね？

divで区切れないとすれば
「脚注」という表現はできないの？
hrで区切る？

hrがいいか悪いかは別として、
hrで区切ったとしても（p要素は例）
-h1
-p
--h2
--p
---h3
---p
hr(a)
---p
---h3
---p
--h2
--p
hr(b)
--p
hr(a)の次のpはその前のh3のpであることが想像できるけど
hr(b)の次のpもその前のh2のpだと思うよね普通。
hr(b)の次のpは一連のh1から始まる文章とは別だとは思わないよね？
ってこれはdivで区切ったとしてもあてはまる・・・？
やっぱり見出しレベルでしか区切れない？？
脚注は表現できなくて別ページを用意するしかない？
脚注という概念は活字向けの物でHTMLに持ち込んではいけない？

divで、

-h1
-p
--h2
--p
--p
--h2
--p
<div>
--p
</div>
このdivの使い方だと区切れてなくて（p要素は例）（classやidは省略）

<div>
-h1
-p
--h2
--p
--p
--h2
--p
</div>
<div>
--p
</div>
このdivの使い方だと区切れてる？？（p要素は例）（classやidは省略）
h1（またはそのページの最上位の見出しレベル）を含むグループと含まないグループで。
当然idやclassを付加してお互いに別グループであることを主張して・・・

でも「脚注」を表現したいがために「divで区切れる」ってことにしてしまうのは
本末転倒・・・？

>>624
divで区切れるとする場合は、hrがどの見出しに入ってるかで決まるんじゃね

>>625
> 当然idやclassを付加してお互いに別グループであることを主張して・・・
これは何の別グループか分からんから意味なさそう。

見出しが、HTML上の階層構造を遡って範囲を広げることはないだろう、
って話じゃね？といっても
<div>
<h>見出し</h>
<p>リード文
</div>
<p>本文1
<p>本文2
という構造を考えればそれも微妙になると思うけど。

>>626
こうするべきじゃないだろうか。
<h>見出し</h>
<p>リード文
<div>
<p>本文1
<p>本文2
</div>

頑固者のスレは初心者の憩いの場となりましたとさ。
めでたし、めでたし・・・。

昔からじゃん
いまさら気付いたってことはやっと初心者の外の視点に立てたのか

シーケンシャルな解釈で判断できないといけないから、
divで構造付与するとhnもその影響は受けるよ。
ただし、sectionをdivで表現することが出来るかと言われるとまた問題が出てくるけど。

公式に決められていないからどれも間違いじゃない
ということでここはひとつ

Validスレw

サイト情報のページは appendix か help かどっちだろうか。

>>631
な に の 公 式 だ ？

w3c

>>635
W3Cのなーんだ？

なぞなぞ？ｗ

今までにあった派閥まとめ（以前のスレの意見も含む）

1. 「divセクション派」
　…見出しによるセクション範囲などは存在しない。divでセクション構造を表す。
2. 「セクション完全否定派」
　…今の(X)HTMLにセクションなんて存在しない。XHTML2.0のsection要素を待て。
3. 「divは見出しセクションより強い派」
　…見出しを含むdivを書くと、見出しによるセクション範囲を区切れる。
4. 「見出しセクションはdivより強い派」
　…見出しを含むdivを書いても、見出しによるセクション範囲は変わらない。
5. 「見出しセクションもdivも強い派」
　…見出しによるセクション範囲は絶対。それを区切るようなdivを書くと両者の
　構造が矛盾するので、そのようなdivを書くこと自体Strictでない。

なぜか今は 3. と 4. の意見が多いようだな。ずいぶんとおとなしくなったもんだ。
以前は結構いた 5. 派はいなくなったのか？

派ってより、フッターに見出しを付ける違和感とかさ、divへの嫌悪感とかさ、そんなんがね。
勘だけで絡みたがるのはまあかわいいが。

まあ、セクションってHTML 4.01では定義されていないわけだし(HTML 5や
XHTML 2で登場する)、好きにすればいいんじゃないかな。

>>640
定義されていないというか、あいまいなだけ。
もしかしたら読み取る能力がないだけかもよ。
「hnのセクションがないとしたら」という仮定の上の矛盾はどうする。
「hnのセクションがあるとしたら」という仮定の上にも矛盾はある。

ないとした場合の矛盾って何？

divで区切れたり区切れなかったりするような
見出しセクションなんて意味づけが見出しには
ないものとして考えればOKっぽい気がするね。

見出しによるセクション範囲は存在するが、divでセクション構造を表せない派なんだが。

>>622
それは見出し要素の役割を説明するために出てきた言葉で、
HTML上意味のあるセクションを指しているとは読めないな。
セクション構造が無いと仮定して、見出し要素の説明をしようとしても
同じ説明にしかならないと思う。

逆にセクション構造があるなら、どこまでがセクションなのか説明して
その存在を明記するはずじゃない？
そうすれば、目次だけじゃなく、1セクションを抜き出すだとかの使い道も増えけど、
これだけの記述で、セクション構造があるから有効活用してねって言うのは無理があるでしょう。

>>633
appendixは、ちょっと違うような気も。
サイトの説明とかだろうからhelpかな。
サイト情報に著作権情報も含むならcopyrightでもいいかも。

>>641
あると言ってる人の間でさえ、意見がまとまらないほど曖昧な「仕様」にどれ程の意味があるんだろうか。
仕様よりも厳格に書くのは結構だけど、それを仕様そのものと混同するのは良くないと思う。

>>644
その理由も言ってもらえると判断材料が増えて良いと思うんだけど。

xhtml1.0strictで多段リストはダメなんですか？
ulの中にul書くとエディタの文法チェックでエラーが出るんですが。

脚注をどう書くか教えてください

>>646
li の中に ul
初心者は初心者スレへ

>>647
原文晒せ

>>648
> 原文晒せ

>>623
> // http://www.python.jp/doc/release/tut/

> li の中に ul
> 初心者は初心者スレへ
何か問題でも？
liはブロック要素を包括できるし
・あああ
　　・かかか
　　・さささ
・いいい
　　・ききき
といった多段リストを表現するときに使うよ
>>646
エディタがあまり賢くないんでない

ごめん646はulの中にulか
読み間違えた本当にごめんなさい

>>648　>>650
うがーほんとしょぼくてすいません！<li>を閉じずに<ul>なんすね。
お二人とも正しいです。
<ul>
<li>りんご　←ここで</li>入れて閉じてました。
<ul>
<li>ふじ</li>
<li>むつ</li>
</ul>
</li></ul>

初心者スレ行きまつ。

脚注という表現はできません

HTML5のドラフトを見ると、div要素はインライン要素かブロック要素のどちらか
しか含めないことになっている。要するに、((%inline;)|(%block;))* ではなく
((%inline;)*|(%block;)*) になるようだけど、これは、インラインとブロックが同列に
並ぶ「匿名ブロック」を嫌った仕様だよな。

しかしHTML5では、li要素に関しては匿名ブロックが許されている。まあ、これを
禁止すると >>652 のような階層リストが出来なくなるからだろうが、匿名ブロック
という点で言えば、divだろうがliだろうが同じこと。

li要素内にインラインテキストとul要素とが同列に並んでしまう >>652 のような
構造って、Strict的にはどういう位置づけになるんだろう。やはり「りんご」は
ブロック要素にすべきなのかな？

<ul>
<li><dl>
<dt>りんご</dt>
<dd>ふじ</dd>
<dd>むつ</dd>
</dl></li>
</ul>
これじゃダメなの？

>>655
ふじの説明とか、さらに詳細な品種などがあったらどうする？
あ、そうか、<dd>の中にまた<dl>作ればいいてか。

というか、<lt>とかがあれば解決なのにな。

dl厨

>>654
>HTML5では、li要素に関しては匿名ブロックが許されている。

いや、許されていないでしょ。
> When the element is a child of an ol or ul element and the grandchild
> of an element that is being used as an inline-level content container,
> or, when the element is a child of a menu element: inline-level
> content.
> Otherwise: zero or more block-level elements, or inline-level content (but not both).
http://www.whatwg.org/specs/web-apps/current-work/#the-li

>>658
おお、確かに内容モデルの所に書いてあるな。本文の説明文の方には書いて
ないのに。

リストの入れ子ができないのは不便だと思うんだが、どうなるんだろうな。

今まで匿名ブロックだったところをpなりなんなりで囲むだけじゃね?

>>661
pか…。
苦しいな。でもpか。
それだとリスト項目全部にp付けなきゃ？

<address>について質問させて下さい
全ページ共通で下部（フッター部分）にページのタイトルとページに関する住所TEL等を書いており
その内容をaddressタグで囲っているのですが
ページ内コンテンツの交通案内のページ（内容は地図の画像とフッターと同じ内容の住所TEL等）
このページのフッターでもaddressタグは使用されてる訳ですが、コンテンツ内に書かれている
この画像や住所TEL等もaddressで囲むべきですか？

べきでない

>>663
それがサイトで扱っている会社なりの所在の案内ページなら
(それがたまたまページの問い合わせ先と同じでも)入れない方がいい

address 要素はあくまでの「そのページ」の文責者への連絡方法を示すものだからね

>>664-665
レスありがとうございます
文責者の情報とは勉強になりました
という事はそもそもフッターの住所等情報も<address>じゃなく<p>でという事なんでしょうかね

ttp://www.doing.tv/D-spot_ch/voice.html
美人さんだな・・・髪下ろしてる姿本当にﾔﾊﾞｲ

誤爆です、すみませんorz

>>667
普段こういう系のひとでも別のところではストリクト〜ストリクト〜とか言ってるやつっていたんだなｗ


俺だけかと思った

俺もそっち系の人だ。所詮Stricterなんてオタクですよ。

断じて違う