Strict-HTML スレッド20

1 ：Name_Not_Found：04/06/21 23:07 ID:???

Strict な HTML について語るスレッド ver.20
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 スレッド19
http://pc5.2ch.net/test/read.cgi/hp/1086000635/

過去ログ・関連スレ >>2
勧告等・その他 >>3

2 ：Name_Not_Found：04/06/21 23:08 ID:???

3 ：Name_Not_Found：04/06/21 23:08 ID:???

■勧告等
HTML 4.01 ttp://www.w3.org/TR/html401/
XHTML 1.0 ttp://www.w3.org/TR/xhtml1/
XHTML Basic ttp://www.w3.org/TR/xhtml-basic/
XHTML 1.1 ttp://www.w3.org/TR/xhtml11/
XHTML 2.0 W3C (Working Draft) ttp://www.w3.org/TR/2003/WD-xhtml2-20030506/
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/

■その他
W3C ttp://www.w3.org/
HTML Working Group Roadmap ttp://www.w3.org/MarkUp/xhtml-roadmap/
Another HTML-lint ttp://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service ttp://validator.w3.org/
ごく簡単なHTMLの説明 ttp://kanzaki.com/docs/htminfo.html

4 ：Name_Not_Found：04/06/21 23:20 ID:???

>>1
Z

さーて、うちのサイトにそろそろURNを取り込むか。

5 ：Name_Not_Found：04/06/21 23:21 ID:mRtKb/H8

>>1
乙。
前スレは意外に消費早かったね。

6 ：Name_Not_Found：04/06/21 23:36 ID:???

ついにStrictスレもPart20ですか。

7 ：junkline のマネ：04/06/21 23:52 ID:???

ストリクてぇ！カスらせろ！

8 ：Name_Not_Found：04/06/22 00:51 ID:???

すとりくたん(;´Д｀)ﾊｧﾊｧ

9 ：Name_Not_Found：04/06/22 11:47 ID:???

</html>

の後に



って書くのは反則ですか？

10 ：Name_Not_Found：04/06/22 12:18 ID:???

別に。

11 ：Name_Not_Found：04/06/22 12:43 ID:???

によるコメントは所謂要素ではないので、
少なくとも「全ての要素はルートノードを起点とした木構造をしている」という
規則には拘束されない。

また、SGML / XML によって定義されているので DTD に依存しない。
# あ、DTD 短縮命令で  を吹き飛ばしてきた場合どうなるんだろう。
　もし短縮命令によってコメントを無効化することが可能でも、
　そんなDTDあったらクソなので、気になくても良いとは思うけど。

12 ：Name_Not_Found：04/06/22 13:59 ID:???

あれ？　コメントってルートノードに含まれるんじゃ？
ルートノードと最上位のエレメントノードの違いはそこにあるのだと思っていたけど。

13 ：Name_Not_Found：04/06/22 14:57 ID:???

>>12は文書型宣言もHTML要素の中に書かなければならなくなりました。

14 ：11：04/06/22 15:16 ID:???

>>13
いや、ごめん、俺が間違ってた。
>>11 のルート"ノード" はルート"要素" の間違い。

15 ：Name_Not_Found：04/06/22 15:27 ID:kD6PY5X8

パンくずリストのマークアップってどうするのが適切？
つい<ul>とか使いたくなるけどそれでいいんかいな。

16 ：Name_Not_Found：04/06/22 15:41 ID:???

俺はolかulにしてるけど、
<dl><dt>2つ上位ノード</dt>
<dd><dl><dt>直上のノード</dt>
<dd>この文章</dd></dl></dd></dl>
でも許容されそうだし（日記をdlで書くくらいの正当性は有ると思う）

<p>この文章は<a>hoge</a>内の<a>hoge</a>シリーズの<a>hoge</a>です。</p>
をCSSでパンくずリスト風にするとかもアリだとおもう。
（ただし、pの地の文を消すのが難しそうなので、大量のstyle用spanを
追加する事になりそうだが）

17 ：Name_Not_Found：04/06/22 16:10 ID:???

XML的には
document ::= prolog element Misc*
で、Miscにはコメントも入っているので
ルート要素の後ろにもコメントを置けるわけです。

18 ：Name_Not_Found：04/06/22 16:20 ID:???

>>16
なるほど。自分としてはソースが長くなるからいやだけど
dlでもいけるんだね。<p>でもそういう書き方にすればアリか。

＞（ただし、pの地の文を消すのが難しそうなので、大量のstyle用spanを
CSSで予めdisplay:none;指定しとくってのは？
んで<a>の時だけ表示させるって言う…

19 ：Name_Not_Found：04/06/22 16:22 ID:xRIGVomQ

パン屑リストも色々なところに文章があるから検索してみな。
ソフィアさんのところのパラグラフかも・・・とか。

20 ：Name_Not_Found：04/06/22 16:48 ID:???

>>18
CSSの話なんですれ違いになるが、現行のCSSだと無理なんじゃないか？

少なくともこれだと駄目。
p {display:none;}
p a{display:inline;}

21 ：Name_Not_Found：04/06/22 16:49 ID:???

>>18
http://hp.vector.co.jp/authors/VA022006/css/visualren.html#display
noneのとこ。

22 ：Name_Not_Found：04/06/22 17:02 ID:???

>>20-21
仰るとおり無理ですな…ｽﾏｿOTL

でもそーすると無理して<p>使うよりulとかolのが良いって事？
待ってもっと調べてみる>>19ありがとう

23 ：Name_Not_Found：04/06/22 17:32 ID:???

>>22
パンクくずリストのような「表示の為に」
「（１）p要素にspan要素を追加する」のはよくないので
「（２）ulやolを使う」ことにした。

さて、「表示の為に」がかかるのは（１）と（２）どっち？　或いは両方？

パンくずリストという「表示結果」を中心に考えると混乱するだけ。

自分が書きたいのはナヴィゲーションの為の文章(p)なのか、
ナヴィゲーションリスト(ul、ol)なのか、はたまた
（強引だが）文書の階層を定義するリスト（dl）なのか、

さきにそっちを考えた方が良いと思う。

24 ：Name_Not_Found：04/06/22 17:48 ID:???

>>18
aのフォントサイズが絶対値指定になるので苦しいが

p {font-size : 0}
p a {font-size : medium}

で一応いける。p a {font-size : 100%}はだめ。
あとは

p a {display : block; float : left}

とした後pの中身をごまかすとか(Mozillaだとテキスト選択したときにおもしろい選択のされ方する)。

あと素直にJavaScript使うというのも1つの手。

#スレ違いすまそ

25 ：Name_Not_Found：04/06/22 17:48 ID:???

26 ：Name_Not_Found：04/06/22 17:52 ID:???

>>23
まさしく混乱してます。
「パンくずリストにはこーゆうマークアップが適切」
ってんじゃなくて
「自分がパンくずリストで表現したいのは何か」
ってことから考えろってこと？
divを使うのは逃げなのかな～

27 ：Name_Not_Found：04/06/22 17:57 ID:???

Strictって・・・・・txtであげろよ。ってまあそれは違うが
いつからHTMLは論理構造だけを。なんて事が正しくなったんだ？

不思議でならない。HTMLで見栄えをやるのも正しいんだよ。DTD次第ではね。ここに来る
素人くんはそこらへんを勘違いしないようにね。

W3C信者だけだからね。HTMLでは論理的構造を、っていうのは。信者じゃない人はW3Cの作った
HTMLのバージョン以外を使いなさいな。

あ～COOKIEってめんどくさ。データベースはもっとめんどくさ。

28 ：Name_Not_Found：04/06/22 18:00 ID:???

釣りにしてもつまらん。

29 ：Name_Not_Found：04/06/22 18:00 ID:???

Strictでない方はお帰りください

30 ：Name_Not_Found：04/06/22 18:02 ID:???

ヴァリッダーが来てるよ。

31 ：Name_Not_Found：04/06/22 18:06 ID:???

え！もしかして、あの妥当戦士ヴァリッダー？！

32 ：Name_Not_Found：04/06/22 18:06 ID:???

そろそろ「パンくずリストは散々既出」って突っ込むやつの登場

33 ：Name_Not_Found：04/06/22 18:11 ID:???

>>27 は釣りにしても、実際Strictを勉強し始めて、
なんで DTDや仕様が認めている記述すら「それはStrictではない」と言われるか、
そもそもStrict（厳格な～）とは何に対して Strictなのか、と思っている人には
Semantic Web に関して勉強することをお薦めする。

# すると、Strict志向な連中が、なぜRDFやらオントロジーやら
七面倒臭い事をやってメタな情報を連結させたがるか、も見えてくる。

34 ：Name_Not_Found：04/06/22 18:15 ID:???

でも万人が認めるStrictの定義は無いんだよね。

35 ：Name_Not_Found：04/06/22 18:33 ID:???

DTD並びに仕様を越える部分の各見解聞いてると
その人がStrict(または他のXML/HTML)を何に使ってるか解るよね。

36 ：12：04/06/22 18:38 ID:???

>>13って>>11？
違うとしたら、>>13の言ってる意味がよくわからないんだけど。

37 ：Name_Not_Found：04/06/22 18:41 ID:???

>>36
>>14

38 ：12：04/06/22 18:43 ID:???

>>37
どうも。
>>13に名前書いてなかったから>>14が>>11と>>13のどっちを訂正してるのか分からなかったもので。

39 ：Name_Not_Found：04/06/22 19:23 ID:???

ぱんくずリストってなんですか？
適当なリスト？？？くずみたいなリスト？？
気になる・・・

40 ：Name_Not_Found：04/06/22 19:24 ID:???

>>39
ヒント：ヘンゼルとグレーテル

41 ：Name_Not_Found：04/06/22 19:25 ID:???

えーと。


<html>
</html>


はOKなんですね。

こんなのは？

/* コメント */
<html>
</html>
// コメント

html の外だけど、 でコメントアウトしなきゃだめ？

42 ：Name_Not_Found：04/06/22 19:26 ID:???

>>41
Webサイト制作初心者用スレ vol.94
http://pc5.2ch.net/test/read.cgi/hp/1087025773/

Strict以前の問題だろ。

43 ：Name_Not_Found：04/06/22 19:29 ID:???

44 ：Name_Not_Found：04/06/22 19:30 ID:???

ごめん。　二度書きしちゃった。

 でコメントアウトするのは、htmlの規則でしょ？

<html> </html> の外なら、それに縛られないのかな？　と思って。

45 ：Name_Not_Found：04/06/22 19:32 ID:???

>>1
遅ればせながら、乙

46 ：Name_Not_Found：04/06/22 19:36 ID:???

>>44
>>42

47 ：Name_Not_Found：04/06/22 19:56 ID:???

>>44
<html> </html> の外でも、それ text/html としてブラウザに食わせるんだろ？
ちなみに注釈宣言はSGMLの規則だ。

48 ：Name_Not_Found：04/06/22 21:35 ID:???

>>15
サイトの文書全体の構造が、

<h1>ほげたら</h1>
<h2>1章ふげたら</h2>
<h3>1.1節はげたら</h3>
...
<h3>1.2節ひげたら</h3>
...
<h2>2章へげたら</h2>
...

こんな感じとして、この節ごとにページに分かれているとすると、
例えば1.2節のページのパンくずリストって、

<h1>ほげたら</h1>
<h2>1章ふげたら</h2>
<h3>1.2節ひげたら</h3>

とするのもありなんじゃないかという気もしてるのですが...。
つまり、パンくずリストは見出しだと。変かな?
もちろん、このページ内の見出しは <h4> 段階から始まります。

49 ：Name_Not_Found：04/06/22 21:39 ID:???

>>48
まず、bodyがあって、直後にh1,h2,h3があって、
本文を代表する見出しがh4からって事？
＞もちろん、このページ内の見出しは <h4> 段階から始まります。
すると「ページ」は「パンくずリストのh1から」はじまってるんだよな？（念のため）

その場合、その文書のtitleはどうなるんだ？　と言う事を考えたら不都合な気がするがどうか？

50 ：Name_Not_Found：04/06/22 21:49 ID:???

>>48
パンくずリストがないと構造的に不思議なことになる文書はどうかと思う

51 ：48：04/06/22 21:50 ID:???

>>49

<title>ほげたら - ひげたら</title>

という風にサイト名とそのページの内容が入った感じなら
それほど不自然さはないかなと。
もちろんパンくずリストにはリンクが入るので、

<body>
<h1><a href="../../">ほげたら</a></h1>
<h2><a href="../">1章ふげたら</a></h2>
<h3>1.2節ひげたら</h3>

こんな感じ。ちょっと前に見出しにリンクが入るのは云々という
議論があったばかりだけど。

52 ：Name_Not_Found：04/06/22 21:53 ID:???

>>15
p要素でいい

53 ：48：04/06/22 21:53 ID:???

>>50
パンくずリストのためのパンくずリストではなく、
構造的には単なる見出しで、見栄えをパンくずリストに見せている
というイメージなんだけど。

54 ：Name_Not_Found：04/06/22 21:56 ID:???

>>52
えーと、氏ね

>>53
それはパンくずリストとは言わないのでは……。
見出しをパンくずリストに見せかけているわけであって、
本質は「リスト」などでなく見出しであって。

それでも構わんのなら問題はないと思うが。

55 ：Name_Not_Found：04/06/22 22:16 ID:???

"散々既出"なので、過去ログを検索してみれ。
ぱんくずリストは、「2ch > hp板 > strictスレ」を入れ替えると意味を成さない
（hp板 > strictスレ > 2ch はおかしい）ので、順序つきリストと考えられる。
リストをつかうならulじゃなくてolな。

56 ：32：04/06/22 22:17 ID:???

>>55
待った甲斐があったよ

57 ：Name_Not_Found：04/06/22 22:25 ID:???

このスレでStrictを擬人化した「すとりくたん」を作って、
Strict推奨キャンペーンをうつのはどうだろう。

58 ：Name_Not_Found：04/06/22 22:26 ID:???

>>57
応援してる。ｶﾞﾝｶﾞﾚ

59 ：Name_Not_Found：04/06/22 22:29 ID:???

いや既にあるんでないの？

60 ：Name_Not_Found：04/06/22 22:34 ID:???

誰か説明書いてやれよ
ttp://suika.fam.cx/~wakaba/-temp/wiki/wiki?HTML%2F%2F%BB%D7%C1%DB
> ストリクタン?, ストリクタソ?

61 ：39：04/06/22 22:41 ID:???

http://ew.hitachi-system.co.jp/w/E38388E38394E38383E382AFE38391E382B9.html
見つけたよ。っていうか教えろよお前ら。ったくほんとに根暗なやつらだな。
まあとりあえず<ol>だな。まずもって見だしってことはないな。
本文のない見出しは邪道だろ。本文のための見出しなんだからな。

そして俺の疑問。
牛肉　松坂産　1kg　5000円　？個　かごにいれる
牛肉　松坂産　2kg　8000円　？個　かごにいれる

↑をリストにすると微妙テーブルにしても微妙。リストは一続きの文、単語だろ。↑のはリスト
にしただけじゃ構造的な示しがはっきりしないと思う。

62 ：40：04/06/22 22:43 ID:???

>>61
あのヒントで足りないなら言ってくれればよかったのに。

63 ：Name_Not_Found：04/06/22 22:44 ID:???

>>61
俺ならテーブルにするが。

64 ：39：04/06/22 22:50 ID:???

テーブルだと確かに見栄えもそろっていいんだが、少し違和感ね。
レコード毎に読むわけでもないでしょ？いきなり縦に読まれたら意味不明な文書になっちゃうし。

というかテーブルってさ、例えば野球とかサッカーの総当り表とかあるじゃん？
あれってthが上一列と一番左側一列じゃん。あ～いうのをHTMLで正しく構造をマークアップ
するにはどうやる？

Strictというか、音声ブラウザから注文のできるサイトを作ってるんだけど、どの順で読まれるか
微妙なテーブルは、今のところ一つもない。（テーブル使ってないってことね）

65 ：Name_Not_Found：04/06/22 22:52 ID:???

>>64
thを上一列と左一列におくテーブルにすればよいと思われ。

66 ：63=65：04/06/22 22:54 ID:???

追記。二次元データ記述にはテーブル使うしかないわけで、
音声ブラウザとかに線形に解釈されるとわかりにくいのはやむを得ないと思う。

67 ：Name_Not_Found：04/06/22 22:54 ID:???

すとりくたんのキャラクターってやっぱり厳格なのかな。

68 ：Name_Not_Found：04/06/22 23:06 ID:???

>>61
定義リスト、ってのはどうだろうか。

69 ：Name_Not_Found：04/06/22 23:20 ID:???

>>54
>えーと、氏ね

？？？なんで？？
p要素で十分じゃん。

70 ：Name_Not_Found：04/06/22 23:27 ID:???

なんか、前スレの div の必要性云々から酷いことになってるな。

71 ：Name_Not_Found：04/06/22 23:29 ID:???

>>64
仕様上テーブルは非視覚系UAを考慮した作りになってはいる。
実在のUAで解りにくいというのは実装の問題。

てか、どの順で読まれるか微妙ってのはテーブルに限った話じゃない。

72 ：Name_Not_Found：04/06/22 23:30 ID:???

ぶ、振返？

73 ：Name_Not_Found：04/06/22 23:32 ID:???

何だっけ？使ったこと無いけど行とか列とかまとめるの使えばいいじゃん。
colgroupとかrowgroupだっけか？

74 ：Name_Not_Found：04/06/22 23:46 ID:???

>>70
誰もみんなを納得させられる答えをだせてないからじゃないか？おまいも出せないだろ。

75 ：Name_Not_Found：04/06/22 23:46 ID:???

>>74
答えは出ただろ。おまえは納得できなかったのかもしれんが。

76 ：Name_Not_Found：04/06/22 23:47 ID:???

>>71
んなこたない。テーブル以外は多少の差異はあれ、意味が飛ぶことはない。そのための
マークアップなんだから。実装のせいにして逃げても何の解決にもならないと思われ。

77 ：Name_Not_Found：04/06/22 23:48 ID:???

>みんなを納得させられる答え
>>75はこれが読めないのだろうか？

78 ：Name_Not_Found：04/06/22 23:49 ID:???

>>77
そりゃ74みたいのがいたら不可能になるね。
それと出された答えは一つとは限らないよ。

79 ：Name_Not_Found：04/06/22 23:52 ID:???

>>78
結局抽象的な事言って逃げるのね。

80 ：Name_Not_Found：04/06/22 23:53 ID:???

そもそもHTMLは音声ブラウザへの考慮が元々欠落していた。それを後から埋めようとしても
そう簡単にはいかないわな。

81 ：Name_Not_Found：04/06/22 23:54 ID:???

>>79
だから何通りかの解釈が出てるだろ。
どれにも納得できなかったのか？
それとも一つにまとまらないと許せないのか？

82 ：Name_Not_Found：04/06/22 23:56 ID:???

っていうかお前ら、構造のはっきりしている表ってなんだ？表は視覚的には効果的だけど、耳からはどうやっても
わかりづらいものだろう。
>>64のいう総当り表などが顕著だな。

83 ：Name_Not_Found：04/06/22 23:57 ID:???

>>82
>>66
もともと視覚的にわかりにくいものを記述するなら仕方ないところがあると思うぞ。

84 ：Name_Not_Found：04/06/22 23:57 ID:???

>>81
で、その何通りもの解釈を話しあうのがこのスレだが、おまいは一体今の流れのどこに不満を持ってるんだ？

85 ：Name_Not_Found：04/06/22 23:59 ID:???

>>83
視覚的にわかりにくいって？視覚的ならテーブルレイアウトマンセーでもいいだろ。

86 ：Name_Not_Found：04/06/22 23:59 ID:???

>>84
ループしてるところか、基本をわかってない人が話し合いに参加しているところじゃない？

87 ：Name_Not_Found：04/06/23 00:00 ID:???

>>85
だから例えば二次元データ、総当たり表とか。
これは別に見栄え重視でそうしているのではないだろ。

88 ：Name_Not_Found：04/06/23 00:00 ID:???

ここは>>81を叩くスレですか？

89 ：Name_Not_Found：04/06/23 00:03 ID:???

>>86
別にループしてもいいんじゃないか？基本をわかってない人が増えたのはそれだけ
新しくStrictに興味を持った人が出てきたってことでもあるし。
どちらにせよこのスレがstrictを広めるのに少しでも役に立てばそれでいいだろ？

日本はかなり遅れてるんだからさ。

90 ：Name_Not_Found：04/06/23 00:03 ID:???

>>88
？

91 ：Name_Not_Found：04/06/23 00:07 ID:???

>>87
＞だから例えば二次元データ、総当たり表とか。
＞これは別に見栄え重視でそうしているのではないだろ。
表ってのは視覚的にわかりやすくするためのものじゃないかい？
聴覚的にわかりやすいのは↓
<li>巨人対広島＝1対0
<li>巨人対中日＝1対2
とか定義リストで聞きやすさを重視したものだろ。表はどう考えても聴覚系には向かない。

92 ：Name_Not_Found：04/06/23 00:09 ID:???

表は表であるけど、見易さからできたようなもんだしなあ…
（たぶん、昔の人がツラツラデータを書いていくのが
非効率だと思ったからだろうな）

93 ：Name_Not_Found：04/06/23 00:09 ID:???

>>91
まあ表が二次元データの表現形式の一つであることは確かかもしれないが、
それはアクセシビリティやらユーザビリティの話題だね。
表で表現できるものをtableで表現するのはstrict的に何の問題もない。

94 ：Name_Not_Found：04/06/23 00:10 ID:???

表っていうくらいだからね。視覚障害者には表（おもて）存在しないからね

95 ：Name_Not_Found：04/06/23 00:14 ID:???

アクセシビリティとかユーザビリティ、又は機械にもわかるようにStrictっていう概念が
出てきたのでは？

人間が目で見てわかればいいなら、StrictでなくてもTransitional+CSSでいいでしょ。
今のStrictの仕様がこうだからそれ以上考える必要はない。なんて言ったらそれこそ、ただの
W3C厨になっちゃうんじゃないかな

96 ：Name_Not_Found：04/06/23 00:15 ID:???

>>95
W3C厨は駄目ですか？彼らの言うとおりにしとけばとりあえず問題ないよ。まあそれならこんなスレいらないけど；

97 ：Name_Not_Found：04/06/23 00:16 ID:???

世の中3次元4次元のテーブルだってあるわけだが
利用して解りやすいかどうかは結局UI次第だ。

良いUIがないから使わず済ますという選択は自由だが
このスレとしてはどうでもいい立場だと思う。

98 ：Name_Not_Found：04/06/23 00:17 ID:???

>>89
それはともかく基本的なところは自助努力して欲しいつうのは贅沢ですか。

パンくずリストのマークアップも散々既出でぐぐれば出てくるだろうし、「p で十分だ」なんて（ry

99 ：Name_Not_Found：04/06/23 00:18 ID:???

>>95はW3CよりもStrictになるつもりでつか？

100 ：Name_Not_Found：04/06/23 00:21 ID:???

馬鹿も増えたが、釣られる奴も増えた。
荒らしに反応する奴も荒らし（オレモナー）。
ガイシュツなり、初心者スレへの誘導でスルー汁。

101 ：Name_Not_Found：04/06/23 00:23 ID:???

>>99
てか、このスレの住人はみなそうだろう。
仕様書に書いてある以上のことを追求してる。

正直、俺のスキルではついていけない orz

102 ：Name_Not_Found：04/06/23 00:24 ID:???

>>100
釣られてもいいからこの餌食いたい！

…と思ってる奴がこれだけいたってことでしょうな。

103 ：Name_Not_Found：04/06/23 00:24 ID:???

ところで、音声ブラウザなにつかってる？
漏れは HomePageReader 3.0 。

104 ：Name_Not_Found：04/06/23 00:24 ID:???

>>95
それは行き過ぎだと思うがな。
HTMLの特徴の一つに色んなマルチメディアファイルを連結できるところがあったわけで。
音声ブラウザにも配慮はしたいが、やりすぎると表やら画像やらを全否定することになってしまうぞ。

105 ：Name_Not_Found：04/06/23 00:26 ID:???

>>98
それは確かにね。
まあマニアックな議論と、素人をたしなめつつStrictを教えて行くっていうのでも
いいじゃないかな？

できれば、「構造的なマークアップ質問スレ」とかあるとそういう人はそっちに流れてくれるから
いいんだけど、スレとか新しく立てるのって微妙だしね。
Webサイト制作初心者用スレ vol.94
↑で足りてる気もするけど、スレタイにvalidとか見栄えと構造を分離とかが入ってるのがあると
結構広まって行くと思うんだけどな。

正直目が見えなくなってからもネット楽しみたいでしょ？現状の日本じゃ無理だよ・・・・

106 ：Name_Not_Found：04/06/23 00:29 ID:???

>>98
過去ログはいいんだけど、pじゃ駄目な理由ってある？
さっきから氏ねだの（ｒｙだの。
変なマークアップされるよりはよっぽどマシな気がするんだが。
確かに、あれらには順序はあるが、pの中身だって十分順序だってるぞ。
あまり混乱を呼ばないためにも、簡潔にp程度でいいと思うぞ。

＃こういうと荒れるから反応しないで欲しいが
＃ここのスレでたまに例示される例は、
＃やりすぎで本末転倒になっているものが含まれていると思う。

107 ：Name_Not_Found：04/06/23 00:30 ID:???

>>106
pでよい、という意見も一部である。前にも行ったがソフィアさんとかもそんなこと言ってた気がする。

108 ：Name_Not_Found：04/06/23 00:30 ID:???

>>105
＞正直目が見えなくなってからもネット楽しみたいでしょ？現状の日本じゃ無理だよ・・・・
ちょっと揺れちゃいますた・・・・
漏れのサイト思いっきりテーブルレイアウトなんだけど・・・書きなおそかな・・・

109 ：Name_Not_Found：04/06/23 00:32 ID:???

>105
W3C信者にサイトを正しい記述に直して貰うスレ3
ttp://pc5.2ch.net/test/read.cgi/hp/1061741473/
でいいと思う

110 ：Name_Not_Found：04/06/23 00:33 ID:???

>>107
これかな？
http://members.jcom.home.ne.jp/jintrick/Personal/d20035l.html#d28_3

111 ：Name_Not_Found：04/06/23 00:34 ID:???

ｽﾄﾘｸﾀﾝの存在知らないやつ明らかに　新人だよな。　過去ログ嫁よ。

112 ：Name_Not_Found：04/06/23 00:35 ID:???

スレタイ考えますた！
【ちゃんと】ValidなHTMLを書こう【聞こえるよ】

【真っ暗】聞いてもわかるHTMLを書くために質問汁！【なんかじゃない】

本気で合ってもいいと思いまつ！このスレ！

113 ：Name_Not_Found：04/06/23 00:35 ID:???

>>106
漏れは<p id="breadcrumb-trail"></p>とマークアップしてたな。
今は、ナビゲーションと言えばlink要素のみだけど。

114 ：Name_Not_Found：04/06/23 00:38 ID:???

>>106
p 要素がより妥当である理由を明示できないのに「過去ログ検索しろ」
などの方法を一切提示せず「p 要素でいい」と断言することに対する「氏ね」

>変なマークアップされるよりはよっぽどマシ

俺にとってはこの直球な提示がまさしく<q>変なマークアップ</q>

>>113
英語にするなら topic-path のがスマートでね？

115 ：Name_Not_Found：04/06/23 00:46 ID:???

>>91
定義リストか表かは、一変数関数か多変数関数かの違いでは?

y=f(x) の関係が定義リスト。
<dl>
<dt>x1</dt><dd>y1</dd>
<dt>x2</dt><dd>y2</dd>
</dl>

z=f(x,y) の関係が表。
<table><tbody>
<tr><th></th><th>x1</th><th>x2</th></tr>
<tr><th>y1</th><td>z11</td><td>z21</td></tr>
<tr><th>y2</th><td>z12</td><td>z22</td></tr>
</tbody></table>

これらは完全にデータ構造の違いだけで見栄えや分かりやすさは
関係ない。

116 ：113：04/06/23 00:48 ID:???

>>114
＞topic-path
その言い方自体、ついさっき>>61見て知ったよ…

当時、考えた結果p要素にしたのだと思うんだけど、
結局何が妥当なのか分からなくなって、すぐに止めちゃったんだよな。

XHTML2.0にnl要素が有る辺り、現在の仕様に遡ると、W3C的にはolが正解なのかな。
それとも、パンくずリストはナビゲーションリストとはまた別に考えるのか？

117 ：Name_Not_Found：04/06/23 00:48 ID:???

>>115
それは言えるが、二次元データは一次元データに書き下すことができるんだよね。
いや俺は表で十分だと思うけど、彼はそっちをして欲しいみたい。

118 ：Name_Not_Found：04/06/23 00:50 ID:???

>>109
そういえばそんなのあったね。すれたいがイマイチだけど。
逆にStrictスレとそこがくっついてもいいんじゃない？微妙かな
要はStrit系のスレが盛り上がってれば自然と参加者が増える。
参加者が増えれば、Strictな考え方を理解してくれる人が増える。
2ちゃんからStrictを広めようみたいな感じかな。

119 ：Name_Not_Found：04/06/23 00:55 ID:???

>>118
議論と質問は明確に分けたほうがよいと思われ。

120 ：Name_Not_Found：04/06/23 00:59 ID:???

>>115
それだとthが一列のものは全て定義リストでよくなっちゃわないかい？
俺としてはthが一つ以上あるならそれはすべて表でかまわないと思うよ。

ただ
商品名　グラム　産地　単価　個数入力　かご入れ
っていうようなthの場合は何故か釈然としないな。これ表なのかな？って
まあフォーム部品が絡むと表以外でもhTML特有な感じになるから結局表でもリストでも
いいのかもしれない。（表の方が若干いいのかな？）

121 ：Name_Not_Found：04/06/23 01:01 ID:???

>>119
質問から議論になること多し。
議論を見て質問が解決することもあり、議論を見てると自分も勉強して発言したくなる場合もあり。
故に分けないメリットもあると思われ。

122 ：Name_Not_Found：04/06/23 01:04 ID:???

>>114
何故提示しなくちゃいけないの？過去ログについては思いつかなかった。
それと、疑問に思えば、聞けばいいじゃない。書き込みについて非常にむかついたってこと？？

変なマークアップというのは、ol要素を出されると、
当然、単に順序付きリストを期待するわけだが、
まさかUAや見る側がol要素に並んだものを見て、階層的である
とかをわざわざ意識してくれるのは不自然だと思ったから。
どうせなら、わざわざ深い意味を込めなくても、p要素でマークアップ
してしまってもいいと思った。まあ、後は
http://members.jcom.home.ne.jp/jintrick/Personal/d20035l.html#d28_3
の人にも共感できる。

>>115
これならa ∈ f なるaを羅列していくパターンもあるとｵﾓﾀ。見づらいが。

123 ：Name_Not_Found：04/06/23 01:17 ID:???

>>122
> 何故提示しなくちゃいけないの？過去ログについては思いつかなかった。
> それと、疑問に思えば、聞けばいいじゃない。書き込みについて非常にむかついたってこと？？

正直お前にはこういう場所でのやり取りに関して決定的なものが不足しているとしか思えない。

> 変なマークアップというのは、ol要素を出されると、
> 当然、単に順序付きリストを期待するわけだが、
> まさかUAや見る側がol要素に並んだものを見て、階層的である
> とかをわざわざ意識してくれるのは不自然だと思ったから。

つうか「単に」も何も ol 要素は順序付きリストですが。それ以上でも以下でもない。
階層がどのような順序で連なっているか？を想定するなら ol であることは自然だろ。
もうちょっと柔軟に物事考えれ。

> どうせなら、わざわざ深い意味を込めなくても、p要素でマークアップ
> してしまってもいいと思った。

深い意味込めずに見出しも p でマークアップしたらどうですか。

124 ：Name_Not_Found：04/06/23 01:18 ID:???

strict信者で攻撃的な人ってなぜか目立つよね。

125 ：Name_Not_Found：04/06/23 01:21 ID:???

>>120
フォーム部品は「申込用紙」と考えれば、HTML特有とも言えないかも。

126 ：Name_Not_Found：04/06/23 01:23 ID:???

>>123
そうですか…。こちらは別に攻撃合戦したいんじゃないんですが、残念です。

127 ：Name_Not_Found：04/06/23 01:29 ID:???

相手の意図が攻撃合戦に持ち込むことにあるとか勝手に想定するのもどうかと思う。

128 ：Name_Not_Found：04/06/23 01:32 ID:???

>>120
thもtdも一列しかないという状態なら定義リストでいいんじゃ
ないかな。さらに、
<dl>
<dt>1</dt><dd>y1</dd>
<dt>2</dt><dd>y2</dd>
</dl>
のように、dtが自然数並びなら、
<ol>
<li>y1</li>
<li>y1</li>
</ol>
と順序リストでいいと思う。表される構造としては、
順序リスト⊆定義リスト⊆表
という感じか。

もちろん、thが一列でもtdが複数列あるなら表になるが。

129 ：Name_Not_Found：04/06/23 01:32 ID:???

>>125
申し込み用紙か。あれは見た目的には表だね。
でも申し込み用紙自体文書じゃないっぽだから難しいね。
<h1>申し込み用紙</h1>
<table></table>

本文が表だけっていうのはいいかな？表って本文の途中に出てきて表について本文で
触れたり、表を元にした本文があったりみたいなのが一般かなと。

130 ：Name_Not_Found：04/06/23 01:50 ID:???

さっき、ブログ叩いているスレ見てきたんだけど、
なんか、駄文しかかけないのにhtmlコードがvalidだから、
検索上位になってウザイ、ってのがあって、ﾜﾛﾀ

131 ：Name_Not_Found：04/06/23 02:05 ID:???

>>130
いいなｗそれ

132 ：Name_Not_Found：04/06/23 02:30 ID:???

えっと、なんでこの流れでheaders属性とかscope属性とかaxis属性とか出てこないんだろう。
仕様書にはちゃんとTable directionalityというセクションもあるし、Table rendering by non-visual user agentsというセクションも例付であるよ。
仕様書読んでる？

#この異常な流れからいって少数の荒らしが自作自演してるとしか思えん。

133 ：132：04/06/23 02:52 ID:???

いや、Table directionalityほとんど関係ないし。
関係あるのはTable rendering by non-visual user agents。
仕様書嫁＞漏れ。

134 ： ◆FoxMX6a/hk ：04/06/23 08:28 ID:???

table が音声読み上げ式の UA でわかりやすく表現しにくい、というのは
UA 側の実装がヘタレている、と言えなくもないな。
# table レイアウトをわかりやすく出力しろとか言う意味ではないぞ念のため。

他にもたとえば、パンくずリストを ol でマークアップするってのは俺も支持したいところだが、
読み上げ UA がどんな風に読むのか実は知らなかったり、CSS で音声出力を制御するにも
CSS の書き方がわからなかったりという香具師が多いんじゃなかろか。

いや、俺もそうだ。がんがって仕様書読もうな、ヘタレ同士諸君。

135 ：Name_Not_Found：04/06/23 08:32 ID:???

>>132
> なんでこの流れでheaders属性とかscope属性とかaxis属性とか出てこないんだろう。
満足に実装したUAがないからじゃない？w

136 ：Name_Not_Found：04/06/23 09:31 ID:???

テーブル使わないからいいやと思って仕様書のテーブルの部分読まない人結構多いんじゃないのかな。
Stricterになりたての頃は反動でテーブルを必要なときまで避ける人多いし。

137 ：Name_Not_Found：04/06/23 09:32 ID:???

Strict HTML って何の規格なの？
リンク先読んでもいまいち・・・

138 ：Name_Not_Found：04/06/23 09:46 ID:???

>>137
メディアタイプ text/html で表されるデータの部分集合の仕様。

139 ：Name_Not_Found：04/06/23 10:01 ID:???

このソースの、
アトリビュートをエンコードしなきゃだめ、
とかいわれたんだけど、どういうこと？

<img src="buy.gif" alt="購入" />

140 ：Name_Not_Found：04/06/23 13:11 ID:???

>>136
それは言える。手書きだとテーブルは色々面倒だしな。

141 ：Name_Not_Found：04/06/23 13:38 ID:???

>>136
そういえばStricterになってから表使わなくなったなあ…

まあ、俺の場合はそもそも使う機会が無いんだけど。

142 ：Name_Not_Found：04/06/23 13:47 ID:???

>>136
axisが必要なぐらい複雑な表を扱う場合、データはサーバー側に持っていてユーザーからの要求にしたがって必要な部分だけ単純な表として出力する、ということが多いなぁ。

143 ：Name_Not_Found：04/06/23 15:32 ID:???

っていうかテーブル実際問題Strcitにはなれないだろ。
cellspacing
これがスタイル側でできないのが問題なんだよな。（CSSの仕様上では問題ないが、実装がということね）
中途半端なStrictはストリクタンにとって一番のストレスだから、結局テーブルを排除することになるんだよね。

144 ：Name_Not_Found：04/06/23 15:42 ID:???

>>143
それ、大した問題じゃないです。

145 ：Name_Not_Found：04/06/23 16:04 ID:???

>>144
問題だよ！俺みたいな頭の堅い人間にとっては！

146 ：Name_Not_Found：04/06/23 16:19 ID:???

>>144
うるせんだよ！

147 ：Name_Not_Found：04/06/23 17:22 ID:???

確かにこのスレとしては無問題ですな。

148 ：Name_Not_Found：04/06/23 18:02 ID:???

>>144
(ﾟдﾟ)ﾊｧ?
重大問題じゃねーか

149 ：Name_Not_Found：04/06/23 18:06 ID:???

荒らしと思ったらスルー。
荒らしに反応した奴も荒らしの一種（オレモナー）。

150 ：Name_Not_Found：04/06/23 18:20 ID:???

>>147
ここはlintで100点とか、仕様書上では問題ないとかじゃなく
本物のStrictになるために談義するスレです。

151 ：Name_Not_Found：04/06/23 18:33 ID:???

>>143を見る限り、それは実装の問題であって
Strictは実装とは関係ないわけだし。

152 ：Name_Not_Found：04/06/23 18:34 ID:???

ついでにCSSの話だからさらに無関係。

153 ：Name_Not_Found：04/06/23 18:46 ID:???

>>151-152
だから放置しろっつーのハゲ

154 ：Name_Not_Found：04/06/23 19:41 ID:???

表なのに音声ブラウザではわかりにくいからってリストを使うとしたら、
表じゃないのにテーブルタグをつかって
「用法が間違ってたとしてもテーブルでレイアウトした方が視覚的にわかりやすい」
と言ってるのと同じ気がする。

実装の問題も有るけど、なんつーか、音声ブラウザではどうやっても
情報に齟齬が発生することは認めないといけないと思う。
野球のラジオ中継ではＴＶ中継よりどうやっても情報が少なくなってしまうのと
同じかな。
音声メディア向けのCSSではcontent: "以下のリストはこのページへの位置を示します";
みたいに出来る限り情報を補ってあげよう。

155 ：Name_Not_Found：04/06/23 20:17 ID:???

>>154
寧ろ、本文にできる限りの情報を突っ込んで、
CSSで不要なメディアの場合、それを非表示にしたり、読まないようにするほうが
（CSS未対応の場合を考えれば）いいのではないかと。

156 ：Name_Not_Found：04/06/23 21:27 ID:???

>>154
>表なのに音声ブラウザではわかりにくいからってリストを使うとしたら、
>表じゃないのにテーブルタグをつかって
>「用法が間違ってたとしてもテーブルでレイアウトした方が視覚的にわかりやすい」
>と言ってるのと同じ気がする。

全然違うだろ。テーブルレイアウトは視覚だけを重視。音声ブラウザでわかりにくいから
表を排除ってのは、全てのUAにたいして公平平等で、わかりやすくしようというStrictの考えそのもの。

視覚はスタイルで後からどうにでもなるけど、構造は全てのUAに対してわかりやすくないといけない。
スタイルが通用しない非視覚系UAや音声ブラウザで構造自体が理解できないものに
なるのはStrictとしては避けなきゃいけない。

よって表を排除するのは現時点では最もStrictであると言える。

157 ：Name_Not_Found：04/06/23 21:33 ID:???

>>156
釣りですか？

158 ：156：04/06/23 21:35 ID:???

おかしな部分があったら言ってちょ

159 ：Name_Not_Found：04/06/23 21:36 ID:???

>>156
表 = レイアウトと思いこんでいるあたりが釣り又は天然。

160 ：157：04/06/23 21:41 ID:???

「全てのUA」が想定不可能だからこそ構造と見栄えを分離してStrictに書くのだと思うが。

161 ：154：04/06/23 21:47 ID:???

>>156
それいっちゃうと、em要素なんてスタイル無しだったら文章にとけ込んじゃって
視覚メディアじゃ理解できなくなるよ？
それこそ
「フォントサイズや色を変えられないブラウザのために強調はカギ括弧でくくれ、
それならスタイルが通用しなくても理解できる」
って言ってるのと同じ事。

>>155の言うようにどちらかと言えば不要部分（レイアウトなどの視覚的効果などで判断できる部分）
は非表示にする、っていう方法がベストでしょ。（CSSで付け足すのはマズイと気が付いた）
例えば、imgのalt属性（画像が表示できるならば必要ない）が普通は表示されないように。

HTMLは構造とスタイルを分離することでセマンテックを目指すわけで、
>スタイルが通用しない非視覚系UAや音声ブラウザで構造自体が理解できない
っていのはおかしい。表という「構造自体」は理解しているのに実装の「表現力」が不足してる。
これは実装の問題だよ。
逆に考えるとリストにしてしまったばかりにXSLTなどの機械処理で不具合が出ることもありえるんわけで。

162 ：159：04/06/23 21:52 ID:???

>>156
なんか釣りじゃなさそうなので、一応解説する。

>>154 は
「データとして表」の時に「読み上げ（表示の一種）」の都合で「リストを使う」
のは、
「データとして表じゃない」時に「表示」の都合で「テーブルを使う」
のと同じくらい良くない、っていってるの。

だから、いきなり「テーブルレイアウトは～」と言った時点で既に
レスになってない。

よって釣り認定した。

163 ：156：04/06/23 22:05 ID:???

>>159
そこまで俺はしょっぱくはないが；

とりあえず。俺の解釈しているStrictってのは全てのUAに対してわかりやすいHTML。
だと思っている。

見栄えと構造をわける理由をたどればそんな答えがでると思う。

164 ：Name_Not_Found：04/06/23 22:10 ID:???

>>163
「全てのUAにわかりやすい」の時点で間違っているときが付いてくれ。
「データとしての表」をリストとしてマークアップしたらUAが混乱するだろ。
「全てのUAをだます」HTMLになってる。

君の目指しているのは「その場限りの」「全てのユーザにわかりやすい」HTMLだ。
構造とスタイルが分離されてないからXSLTで縦と横のセルの入れ替えも
出来ない中途半端なものだよ。
テーブルレイアウトと同じだ。

165 ：Name_Not_Found：04/06/23 22:12 ID:???

「表」に対して「定義リスト」でマークアップしておいて
「ま、これは表なんだけどね、UAが馬鹿だからわかりやすく定義リスト使ってるんだけどさ」

これわかりやすいか？誤解生むだけだろ。

166 ：156：04/06/23 22:12 ID:???

>>164
お前が正しい

167 ：Name_Not_Found：04/06/23 22:14 ID:???

サーバでUAにしたがって動的にHTMLを吐くってのは
このスレ的にはどうなの？

168 ：Name_Not_Found：04/06/23 22:15 ID:???

>>166
どっちなんだよ（笑

>>167
送信されるHTML文章は全てStrictで有るべきだと思われる。
ただ、実装に合わせてHTMLのバージョンを変えることは許されるかも知れない。

169 ：Name_Not_Found：04/06/23 22:15 ID:???

>>167
それってググとかにもかかるのか？

170 ：Name_Not_Found：04/06/23 22:39 ID:???

表とリストの話についてだが、

　巨.阪.ヤ
巨＼○○
阪×＼○
ヤ××＼

上の表を

　・巨人vs阪神　5：3
　・巨人vsヤクルト　3：0
　・阪神vsヤクルト　4：1

こうするんだろ？

表がリストから成り立っている場合、
音声ブラウザ使用者に対しては表をリストに戻して配慮するのはどうよ。
って話じゃないの？

171 ：Name_Not_Found：04/06/23 22:45 ID:???

>>170
Strictとしてはその作業はUAの仕事。表現の一環としてね。

実際はサーバサイドで音声ブラウザだけ変換して送るのもありかも知れないが恐らくスレ違い。

172 ：Name_Not_Found：04/06/23 23:53 ID:???

>>167
content negotiation の一種かな。
strictと関係ないけど、別に問題はないと思われ

173 ：Name_Not_Found：04/06/24 00:08 ID:???

>>156
うわあ

174 ：Name_Not_Found：04/06/24 00:38 ID:???

http://www.w3.org/TR/2004/WD-cselection-20040611/
Working Draft: Content Selection for Device Independence (DISelect) 1.0
というのも最近出てきた。

175 ：Name_Not_Found：04/06/24 07:33 ID:???

table自体はストリクトなhtmlなんですよね？
tableを表としてじゃなくてレイアウトに使うと音声ブラウザで理解不能になる事が問題点ですよね？
（読み込みが遅くなるとかも問題点としてあるか。）
それじゃ、ちゃんとした表の形で、音声ブラウザでも理解できるtableの使い方だったら、
多少レイアウト的に使っても大丈夫なんじゃないでしょうか。↓こんな感じで（一部要素省略）。

<table border="0"><tbody>
<tr><td><a href="～">メインコンテンツ</a></td><td>○○○についての分析。</td><tr>
<tr><td><a href="～">掲示板</a></td><td>意見交換所です。</td><tr>
<tr><td><a href="～">自己紹介</a></td><td>管理人です。</td><tr>
</tbody></table>

実際に自分のサイトは、こんな感じでtableを利用してるんですが、これはstrictなhtmlじゃないと
判断されるんでしょうか。これもテーブルレイアウトの悪い例になりますか？

176 ：175：04/06/24 07:34 ID:???

一部訂正。</td><tr>じゃなくて</td></tr>

177 ：Name_Not_Found：04/06/24 07:47 ID:???

いやレイアウトに使っても
線型に並んでいれば音声ブラウザでも理解可能。。。ってので、
昔はW3Cもレイアウトに使ってました。

178 ：Name_Not_Found：04/06/24 07:51 ID:???

線形に読んで (つまり、表関係のタグを無視して順番に読んで)
意味が通じるような使い方であれば、レイアウトに使うのも許容される
というガイドラインがWCAGにあったはず。

真のすとりくタンはそんなところで妥協しないとは思うけど

179 ：Name_Not_Found：04/06/24 08:16 ID:???

>>175
その程度ならわざわざ使う必要はないんじゃないかしら♥
使う方が不自然よ♥♥♥このハートマークみたいに♥♥

dl要素を使うのが一番自然で意味があるわね♥♥
<dl>
<dt>メインコンテンツゥ♥</dt>
<dd>ぬるぽについての分析♥</dd>
</dl>
＃あと自己紹介の所が意味不明だわ♥♥♥

180 ：175：04/06/24 08:19 ID:???

>>179　自己紹介はプロフィールってことだﾖｳ

181 ：Name_Not_Found：04/06/24 08:46 ID:???

>tableを表としてじゃなくてレイアウトに使うと音声ブラウザで理解不能になる事が問題点ですよね？

表組を表す要素なのにそれ以外の目的で使うことが問題。
音声ブラウザがどうだ、ってのは実装とユーザビリティの問題。

# この場合ユーザビリティの大部分はソフトウェア側が担ってる気はするが

182 ：Name_Not_Found：04/06/24 10:18 ID:???

>>175
HTMLでは、表形式のデータは table 要素となる。
table 要素なので、table tag でマークアップする。

逆に table tag は table 要素以外では使われず、
table 要素は表形式のデータ以外では出現しないので、
表形式のデータ以外を table tag でマークアップしたら間違いになる。

と言うのが仕様からみた正しいHTMLのマークアップ法。

>>178
あれは、レイアウト目的で使うなら最低限こういう点に配慮しろ、という
指針であって、レイアウトを許容する、という内容ではないかと思われる。

ついでに言えば、WCAGのワーキンググループが何を言おうが、
HTMLの仕様を上書きする性質の物ではないし。

183 ：Name_Not_Found：04/06/24 10:52 ID:???

>>180
「自己紹介：管理人です」だと、自己紹介 = 管理人　になっちゃうので、
「自己紹介：管理人○○ (ハンドル名など) の情報です」のような
書き方にしろという、突っ込みではないかと思われる。

184 ：Name_Not_Found：04/06/24 11:48 ID:???

>>175
とりあえず、データの表なら th 要素がないのはおかしいだろ。

185 ：Name_Not_Found：04/06/24 19:35 ID:???

とりあえず多くの人にとっては脳内既出だと思うけど、
もしかしたらそうでない人もいるかもしれないから、念のため確認。

・視覚UAの出力は2次元
・聴覚UAの出力は1次元
・表の情報は2次元
・リスト等を含む通常のテキストは1次元

1次元の情報は2次元でも出力できるけど、2次元を1次元で出力するのは難しい。
だから聴覚UAで表を出力するのは当然難しい。

186 ：Name_Not_Found：04/06/24 19:36 ID:???

だからといって表を定義リストで（ry

187 ：Name_Not_Found：04/06/24 19:38 ID:???

>>185
同じく。

・2次元情報は2次元情報としてマークアップするのがstrict
・読み手に配慮して表現を変えるのはマークアップの前段階の作業

188 ：Name_Not_Found：04/06/24 19:49 ID:???

>175
このぐらいだったら表として成り立っていそうだし、別に問題ない気がするのだが。
<table>
<tr><th>ページ</th><th>説明</th></tr>
<tr><td><a href="～">メインコンテンツ</a></td><td>○○○についての分析。</td></tr>
<tr><td><a href="～">掲示板</a></td><td>意見交換所です。</td></tr>
（以下略）

3次元の表ってどんなマークアップになるんだろ。

189 ：Name_Not_Found：04/06/24 20:09 ID:???

>>188
> 3次元の表ってどんなマークアップになるんだろ。
headers属性とaxis属性を使います。
詳しくは
11-4-2 コマのカテゴリーづけ
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/tables.html#h-11.4.2
の例を。

190 ：Name_Not_Found：04/06/24 20:19 ID:???

table内にtbodyは複数あっても・・・いいんだね。189の見て分かった。良かった。

191 ：Name_Not_Found：04/06/24 20:45 ID:???

表は最初からシーケンシャルに読むだけに使われるのではない。
何のためにheaders,scope,axis属性が存在するんだ?
表の一部の要素を取り出して読み上げることができるように
するためではないのか。
不必要にdl要素でやろうとすれば、このメリットも失われることになる。

192 ：Name_Not_Found：04/06/24 20:54 ID:???

>>187
手慣れてくると、自分の書きたいこと考えながら、
マークアップするようになってきて、
そうすると知らず知らずのうちに

・読み手に配慮して表現を変えるのはマークアップの前段階の作業

がマークアップ自体にスライドして来ちゃうこともあるよね。
気を付けようっと。

193 ：Name_Not_Found：04/06/24 20:57 ID:???

>>192
まさにその通りのことを最初からやってますた…
（font要素とか恥ずかしげも無く使っていた厨三の頃から）

まあ、俺のサイトは俺のためのメモサイトみたいなもんだから、いっか…。

194 ：Name_Not_Found：04/06/24 21:06 ID:???

そうやって妥協と正当化を繰り返すんなら最初からStrictなんて謳わなければいい

195 ：Name_Not_Found：04/06/24 21:28 ID:???

>>194
好きよ。結婚して

196 ：Name_Not_Found：04/06/24 22:17 ID:???

>>193
漏れ厨三のとき、音響カップラでパソ通やってた… orz
夏華嬢は今どこに…

197 ：Name_Not_Found：04/06/25 15:30 ID:???

微妙に便乗。
HTMLでトーナメント表を表現するにはどのように書くのが妥当でしょう？
出場チーム名や名前なんかをtableに入れるまではいいとしても、試合の流れを示す線などをどうすればいいのか
さっぱり見当が付きません。
線を引くだけならば画像をべったり貼ってしまってもいいのですが、それだと誰と誰が試合をするのかをHTMLで
表現し切れていないなぁ、と。

198 ：Name_Not_Found：04/06/25 16:41 ID:???

やっぱ画像しかないと思うけど。
試合内容とかはaltなりlongdescなりで

199 ：Name_Not_Found：04/06/25 17:03 ID:???

トーナメント表（というか図だよね）って、
試合の流れを図示したフローチャートじゃん。
図≒絵ということで、イメージにしてますよ、漏れは。

その流れの説明を alt でするのか、別途文章にするかは別問題。

200 ：Name_Not_Found：04/06/25 17:35 ID:???

やっぱ画像にしておくのが無難なんですかねぇ。
altやlongdescで説明を書く際にはやはり「A対B、C対D・・・の勝ち抜きトーナメント」のようになるんでしょうか。
しかもそのトーナメントが結果の場合には「A対BでAの勝ち、C対DでDの勝ち・・・優勝はA」ですかね。

201 ：Name_Not_Found：04/06/25 17:47 ID:???

object要素でトーナメント表(図)を表示して、
内容に pre 要素でアスキーアートのトーナメント表を書き、
さらに読み上げ式UAの為に、一般的なアスキーアート同様に、
アスキーアートをスキップする為のハイパリンクと、文章として >>200 に
有るような対戦成績を書いたテキスト (*) へのハイパリンクを設定する。

*:ラジオで高校野球とかのトーナメントを解説しているような文章が
無難かと思われる。

WinIEのobject要素の実装に問題があるのでobject要素を使いたくない、という場合は、
トーナメント表(図)をimg要素で表示することになるが、この場合も
上記のようなアスキーアートや文章へのナヴィゲーションを設置すれば、
最低限のユーザビリティーは確保できるかと思われる。

202 ：Name_Not_Found：04/06/25 17:59 ID:???

なるほど、object要素のこと忘れてました。
と思ってやってみたら・・・WinIEでの実装に問題ってのはこういうことですか。
色々意見を頂いた（>>198 >>199 >>201）のでこれらを総合的に考えながら今回のケースではどうするのが良いか検討してみます。
ありがとうございました。

203 ：Name_Not_Found：04/06/25 18:10 ID:???

>>201
もし高校野球なら出場校のサイトへクリッカブルマップ（object での画像）・文字アンカー（代替 pre）でリンクするとよりよいかも

204 ：Name_Not_Found：04/06/25 18:14 ID:???

なんかこう、実装とかアクセシビリティとかはちょっと置いといて、
とりあえずマークアップしてみませんかとかいうスレではないのですか。

<ul class="game final">
　　<li class="frame">
　　　　<ul class="game primary">
　　　　　　<li class="frame">Aチーム</li>
　　　　　　<li class="frame">Bチーム</li>
　　　　</ul>
　　</li>
　　<li class="frame">
　　　　<ul class="game primary">
　　　　　　<li class="frame">Cチーム</li>
　　　　　　<li class="frame">Dチーム</li>
　　　　</ul>
　　</li>
</ul>

やっぱHTMLの範疇ではないですか…。

205 ：Name_Not_Found：04/06/25 18:17 ID:???

>実装とかアクセシビリティとかはちょっと置いといて

実装はともかくアクセシビリティは……。

206 ：Name_Not_Found：04/06/25 18:54 ID:???

Strictって実際の所何なんだ?
俺的にはXHTML1.1(もちろんaltやclass等は好ましくない物を避けて)でCSSを使っていて、JSはECMAScriptとJavaScript、DOMにそってるものだけだと思うのだが。

てかW3Cは早くHTML～XHTML1.0を廃しすれ。

207 ：Name_Not_Found：04/06/25 18:59 ID:???

>206
廃止したってIEがさ…

208 ：Name_Not_Found：04/06/25 19:01 ID:???

>>206
アホか。後方互換性もちっとは考えろ。
おまえがせっせと書いたXHTML1.1が
XHTML2.0やら知らんが次世代規格の登場で
速やかに廃止されたらどうすんだよ？
その都度修正しなければならないのか？

209 ：206：04/06/25 19:09 ID:???

>>208
現在XHTML2.0で書いてますが何か?
そして、其のつど修正してきましたが何か?

次世代規格への対応はローカルでXSLT変換させて少し手直ししてｳﾏｰ
後方互換はサーバー側で

210 ：Name_Not_Found：04/06/25 19:13 ID:???

そんな誰もが喜んで負担を受け入れるわけがあるまいに。
はるか昔にメンテナンス放棄された文書だって腐るほどある。

何ならW3Cに「HTMLとXHTML1.0を廃止しろ」ってメールしてみろよ。
厨房メール展覧会に晒してくれるかも知れんぞｗ

211 ：206：04/06/25 19:17 ID:???

送ってみる

212 ：Name_Not_Found：04/06/25 19:22 ID:???

主観で話すなってわけだね。

213 ：Name_Not_Found：04/06/25 19:22 ID:???

∑(ﾟДﾟ；) 送るのかよ！

214 ：206：04/06/25 19:31 ID:???

送りますた。

215 ：Name_Not_Found：04/06/25 19:34 ID:???

>>213
可愛い！

216 ：Name_Not_Found：04/06/25 19:35 ID:???

>>206は謎小屋とかいうユーザビリティ全くナシのサイトの中の人か？

217 ：206：04/06/25 19:37 ID:???

>>216
キーボード使ってる人への対処忘れてた

218 ：Name_Not_Found：04/06/25 19:45 ID:???

>>100 と >>149 参照

219 ：216：04/06/25 19:47 ID:???

あー、あー。
中の人だってわかったんならお前が相手にする価値がない思慮の浅さの持ち主だということも同時に判明するわけでつまり今後スルーしますと宣言。

>>218
スマンね。

220 ：Name_Not_Found：04/06/25 20:34 ID:???

>>201で思い出したから忘れないうちにメモというか共有というか確認というか。

- alt属性に迷ったらラジオや電話で伝えるときのことを考えると良い。

221 ：Name_Not_Found：04/06/25 21:26 ID:???

それだと画像の説明になっちゃわないか？

222 ：Name_Not_Found：04/06/25 22:05 ID:???

代理に表示するテキストとして、説明が相応しければ、説明でもＯＫ。

おれは「先に画像なしのテキストで文書を作り、テキストの代わりに画像を
指定し、代わりになったテキストをaltに設定する。」と言う事をしてる。

とはいえ、テキストで表現出来ないから画像を用いる事も多い訳で、
完璧にテキストに画像の代理をつとめさせるのは難しいやね。

223 ：W3Cの中の人：04/06/25 22:53 ID:???

>>210
何か妙なメールが来ました。晒しましょうか?

224 ：Name_Not_Found：04/06/25 22:55 ID:???

>>223
おねがい。strictに晒してください。

225 ：Name_Not_Found：04/06/26 00:39 ID:???

ttp://nazo.europe.webmatrixhosting.net/distribution.aspx/gets_out_ie_from_all_windows.xml

>206はこういう電波なこと言っちゃう人だから仕方がない

226 ：Name_Not_Found：04/06/26 00:40 ID:???

画像使って注文手順中で、今、この作業ですよっていうのを画像で説明するときあるんだけど、
パンくずリストの矢印を少し大きめの矢印画像に変えるみたいなかんじ。
それって何でマークアップするべきかな？

<ol>かなって思うけど、一番初めの<li>には矢印画像を付けたくなくて、さらに全ての
矢印画像は同一ではなく、場所によって色が薄かったり濃かったりする。

<ol>を一つづつに付ければ一応できるけど、それだとCSS切ったときに番号が全部1になるし
何より、見た目の為にマークアアプが変わるようではStrictではないよね。

227 ：Name_Not_Found：04/06/26 00:56 ID:???

<ol>
<li>商品を選ぶ</li>
<li class="now_here"><strong>支払い方法を選ぶ</strong></li>
<li>注文の確認</li>
</ol>

という感じにして

li{display : inline}
li:before{display inline; width : 画像の幅}
li li:before{display inline; background-image : 矢印画像}
li li.now_here:before{display inline; background-image : 濃い矢印画像}

かな。
今いるステップをstrongでマークアップしたけどもっと良いマークアップがあるかもしれない。
どちらにしろ「今このステップである」という情報は単なる見栄えではないのでHTMLレベルでマークアップすべき。

228 ：Name_Not_Found：04/06/26 00:58 ID:???

>>226
Strictの幼稚さがうかがえるな。中途半端なもんなんだよ。
一言で済ますとムリ。

229 ：Name_Not_Found：04/06/26 01:03 ID:???

>>227
そういえば<strong>は必要だね。でも矢印画像が背景になるのはやっぱしょうがナインかな。

とりあえずかなり参考になった。後は自分で工夫してみるよ。

230 ：227：04/06/26 01:05 ID:???

訂正
× li li:before{display inline; background-image : 矢印画像}
○ li + li:before{background-image : 矢印画像}

その次の行も同様。

ちなみに段落形式のパン屑ナビゲーション風にすると
「注文するにはまず商品を選び、次に支払い方法を選択し(現在このステップです)、注文を確認します。」
となるかな。

231 ：Name_Not_Found：04/06/26 01:20 ID:???

>>225
本気でﾜﾛﾀ

232 ：Name_Not_Found：04/06/26 02:07 ID:???

>>225
何故か見づらいなそのページ。
なんか太字と普通字のバランス悪いというか。
よくわかんないけど目が痛くて、面白くなかった。

HTML4.01Strictを非推奨化なんてしてほしくないのは間違いない。

233 ：Name_Not_Found：04/06/26 03:49 ID:???

>>232
>色々問題になってるIEを窓から捨てろ発言について自分なりに考えてみました。
>マニュアル型なのは従えということじゃなくて、単に自分なりにまとめてみただけです。

って書いてあるから勘違いしないように…。

ページのCSSはムダに悪いね。
OperaよりIEのがまともな表示してくれるし、Operaだと目次が見られない。

234 ：Name_Not_Found：04/06/26 04:32 ID:???

margin:0;のページか・・・

235 ：Name_Not_Found：04/06/26 08:04 ID:???

っていうかStrictとはすこし違うけど
<strong>とかって一般的な視覚UAでは太字になるけど、俺は<strong>にCSSで
font-weight:normal;
を付けてる。

太字ってさ、見だし以外であると文章が読みづらくてしょうがないんだよね。
なんかムダに主張してきて他の文字を読みたいのに強制的に目の中にそいつも入ってくるから
結局同時に2ヶ所見てることになって目に悪い。

強調って下線が一番よくないか？

236 ：Name_Not_Found：04/06/26 10:43 ID:???

>235
スレ違い。↓へどうぞ
ユーザビリティ専用スレ　その２
http://pc5.2ch.net/test/read.cgi/hp/1020575673/

一応返答しておくと、下線はリンク文字列と紛らわしいのでやめたほうがいい

237 ：Name_Not_Found：04/06/26 12:59 ID:???

>>233
独り言ならメモ帳にでも書いてろ。な。

238 ：Name_Not_Found：04/06/26 14:13 ID:???

>>235
>ムダに主張してきて他の文字を読みたいのに強制的に目の中にそいつも入ってくる
くらい強調しなければならないところこそがstrong要素であって、それほどでもないのならem要素だ。
つまり、スタイル以前にマークアップが間違ってる。

239 ：Name_Not_Found：04/06/26 16:15 ID:???

っていうかよくやるやういるけど
<dt><strong>dfghjk</storng></dt>
とか
<hn><em>fghjkl</em></hn>

ってどうなの？すでに強調されてるんじゃないのか？見だしと定義見だしは

240 ：Name_Not_Found：04/06/26 16:31 ID:???

<dl>
　<dt><strong>警告</strong></dt>
　<dd>
　　...
　</dd>
　<dt>注意</dt>
　<dd>
　　...
　</dd>
</dl>

こういう感じならいいんじゃネーノ
強調される箇所とそうじゃない箇所のコントラストがあれば不自然じゃない
コントラストが無ければ不自然

241 ：Name_Not_Found：04/06/26 18:58 ID:???

>>239
> すでに強調されてるんじゃないのか？見だしと定義見だしは
「見出し⇒強調である」は間違いだろ。
「強調でない⇒見出しでない」は正しく無いもん。

242 ：Name_Not_Found：04/06/26 19:00 ID:???

スマソ、寝ぼけているな説明が

243 ：Name_Not_Found：04/06/26 19:00 ID:???

>>241
待遇をとってみたのね。
>「強調でない⇒見出しでない」
とはいえこれを正しいと思う人もいるでしょう。

244 ：Name_Not_Found：04/06/26 19:03 ID:???

場合によると思われ。
<dfn>見出し</dfn>とは<q>内容の要点が一目で分かるように、本文の前につけた短い語句</q>
なわけだが、
「主張を強調した」と考える人と「これから説明する部分について書いた」と考える場合もあるし

245 ：Name_Not_Found：04/06/26 19:09 ID:???

Goo辞書より引用

みだし 0 【見出し】

(1)新聞・雑誌などの記事の内容が一目でわかるようにつけた標題。ヘッドライン。
「大―」「小―」
(2)本や帳簿の内容がすぐわかるように書き出した目次・索引など。インデックス。
「ノートに―をつける」
(3)辞書で項目を示すために掲げる語。見やすいように太字などで示す。見出し語。

246 ：Name_Not_Found：04/06/26 19:46 ID:???

見出しとして強調したい→見出しのスタイルいじれば十分
見出しの中でも強調したい→見出しの上で強調の要素を。

247 ：Name_Not_Found：04/06/26 20:17 ID:???

XHTML2.0で要素の重要度を示す属性があればな。

<strong importance="2">
とか
<strong importance="-5">
とか

248 ：Name_Not_Found：04/06/26 20:42 ID:???

>>247
emのネストでよくない？

249 ：Name_Not_Found：04/06/26 21:16 ID:???

>>248
247案のキモはimportanceに負数が指定できることだろう。
過去スレで強調の逆について議論していたこともあるし。

250 ：Name_Not_Found：04/06/26 22:11 ID:???

>>248
まず、em要素の強調の度合いを「レベル1」、strong要素の強調（つまり、em要素より強い強調）の度合いを「レベル2」と考えます。

現行のHTMLにおいて、次のようなマーク付けをした場合、
<em>foo<strong>bar</strong>baz</em>
strong要素である「bar」が「『1＋2＝3』だからここは『レベル3』の強調がされている」とは、普通考えないと思います。
「strong要素だから、em要素より強い強調（＝「レベル2」の強調）がされている」という判断が普通だと思います。

それを踏まえて、「emのネスト」を考えてみると、
<em><em>foo</em></em>
em要素である「foo」が「『1＋1＝2』だからここは『レベル2』の強調（＝strong要素と同等の強調）がされている」とは普通考えない、という事になってしまうのではないでしょうか。

# つまり、現行のHTMLにおけるem要素・strong要素の強調の強さの度合いは「相対的」にではなく、
# 「絶対的」に考えられていると私は考えている、という事です。

# ちなみに、私の場合、XHTML 2.0でstrong要素で廃止された場合の代替は、class属性の指定という方法を考えています。
# <em>foo<em class="level-2">bar</em>baz</em>

>>247
>247案のキモはimportanceに負数が指定できることだろう。
（・∀・）ｲｲ!!ですね。

251 ：Name_Not_Found：04/06/26 22:14 ID:???

つーか数段階の強調なんか使うか？
弱調はまだしも。

252 ：Name_Not_Found：04/06/26 22:21 ID:???

煩雑になるだけの気がする。
というか強調は一つで充分かと。

253 ：Name_Not_Found：04/06/26 22:24 ID:???

どうしても必要なら独自に拡張、かなあ

254 ：Name_Not_Found：04/06/26 22:27 ID:???

俺の人生をStrictに書き直したいのですが

255 ：Name_Not_Found：04/06/26 22:27 ID:???

まあ一般に必要があるとすれば強調の種類・理由だよな。
強調のレベルというのはそうした種類の一つだろうが
classやtitleで区別すれば充分なような。

256 ：Name_Not_Found：04/06/26 22:30 ID:???

>>254
お前の人生って特定のスキーマで記述しきれるような単純なものなの？

257 ：Name_Not_Found：04/06/26 22:30 ID:???

>>255
>まあ一般に必要があるとすれば強調の種類・理由だよな。
どゆ意味？

258 ：Name_Not_Found：04/06/26 22:40 ID:???

>>255
実際に「見出しだから強調」という場合、見出しという要素で足りてるし
言葉の定義の場合もしかり。

強調は一般的に結果であって、明確な理由がある場合、その理由そのものを
要素とする事で十分かと。

259 ：Name_Not_Found：04/06/26 23:06 ID:???

>>258
要素を一々作るとなるとXMLとかでも面倒で敷居は高い。

abbr の title 属性みたいに em の title 属性は強調理由を記述する、
とかの方が汎用性も高いしいいんじゃない？

260 ：Name_Not_Found：04/06/27 00:01 ID:???

>>251
一昔前のフォントいじりテキスト系サイトをマークアップしようとすると複数段階の強調が必要だと思います。
そのようなサイトのよしあしは別として。

でもそれより理由が書けたほうが確かにいいですね。

261 ：Name_Not_Found：04/06/27 00:03 ID:???

強調の理由ってのがよくわからん。classじゃダメなの？

262 ：Name_Not_Found：04/06/27 00:43 ID:???

例えばdfn要素が無かったとしたら、emを使う理由として「定義語」という
のが存在する事になって、定義語以外の強調と区別したい、と言う事があるかも知れない。

で、そのような種類分けを行うには現在のclassやtitleではちょっと力不足、
というか、セマンティック性に欠けるので強調に対して、どんな理由か、
理由を記述する属性が仕様に明言されていると上記のような要望に答えられるよね、
と言う話かと。

263 ：Name_Not_Found：04/06/27 00:50 ID:???

>>262
うーん。それは強調だけに限る話じゃないな。リストなんかもそうだし。
だがそうすると、属性増やせばいいのか理由説明するのか曖昧になる。
ひいては見栄えと要素を混同するようになる気がする。

264 ：262：04/06/27 00:54 ID:???

いや、理由解らん、といわれたので、「と言う話かと」と
流れを言っただけなので、俺じゃなくてそう言う意見を言ってる方によろ。

265 ：263：04/06/27 00:56 ID:???

>>264
それはすまんかった。
>>263は「という話」を主張する人がいるとしたら、それに対する俺の意見ね。

266 ：Name_Not_Found：04/06/27 04:54 ID:???

>>248,250
こんなのとか。
・野望の王国の強調に一言物申す
http://www.homoon.jp/users/www/diary/2004/05a.shtml#d06b

プレーンテキストよりも重要度が低いものをマークアップする必要があるというのなら入れ子はまったく意味を無くすな。
Emphasisでもなくなる。代わりにImportance(重要性)を示す要素、略して <impo> とか？

267 ：Name_Not_Found：04/06/27 10:30 ID:???

ちなみに本気でimpo要素が出来たとして、
<impo val="2">ああああ<impo val="-2">いいいい</impo></impo>

この場合「いいいい」の重要度は-2? 0?

結局「ネストする場合のデメリット」は解消されて無くない?

だったらemを+1に固定して、-1に相当する要素を新設して
これらのネストで表現した方が楽っぽい気がする。

268 ：Name_Not_Found：04/06/27 11:19 ID:???

>>267
その場合+1の要素の中には-1の要素が現れないように制限して、-1の要素の中には+1の要素が現れないようにしないと意味がちゃごちゃになるし、CSSのセレクタとかで扱いづらそう。
その制限をDTDで書こうとすると……。

語彙をどれぐらい用意するかは難しい問題ですね。
少なすぎれば不満が高まってそれぞれが勝手にマークアップしだしますし、多すぎれば複雑になりますし。

269 ：Name_Not_Found：04/06/27 11:28 ID:???

とりあえず「強調」「もっと強調」「弱調」の3つあれば全く事足りる。とか言ってみる。

>>267
どっちにしても結局「仕様ではっきりさせれば良い」っていうところに落ち着くんだけど。

270 ：Name_Not_Found：04/06/27 12:33 ID:???

>>269
もっと強調は、強調のネストでよくない？

あと、仕様の件はその通りなんだけど、仕様そのものが
扱いづらすぎて使い物にならないとか言うこともあるわけで
新たに仕様をさだめるならどうあるべきか、を考えるのは
思考実験と割り切っても有意義だと思う。

271 ：Name_Not_Found：04/06/27 12:57 ID:???

>>269
引用文の中の引用をマークアップするために「さらに引用」はいらない。
・彼は<引用>だって彼女が<引用>やれ</引用>って言ったから……</引用>と言った。

同じように「もっと強調」もいらない。
・彼は<強調>ゲイでさらに<強調>マゾ</強調>だ</強調>。

272 ：Name_Not_Found：04/06/27 13:02 ID:???

>>270
>>267-268

273 ：Name_Not_Found：04/06/27 13:21 ID:???

>>271
> 引用文の中の引用をマークアップするために「さらに引用」はいらない。
真面目に聞きたいのだが、なぜ？
漏れは二義的な引用内引用を表す要素としてq要素が適切かどうかで悩んでいたから、
（XMLではなく）HTMLにもそういう要素があればいいのになあ、といつも思っていたんだが。

強調に関しても、強調内における強調がマークアップで必要とされる場合もあるかもしれない。

274 ：Name_Not_Found：04/06/27 13:41 ID:???

>>271
Aさんが、Bさんの言葉を引用して行った発言をどのように引用するのか知りたい。

>>272
どこら辺が回答になっているのかさっぱり解らん。
解説をキボン。

275 ：Name_Not_Found：04/06/27 13:53 ID:???

>>274
>272は回答ではないでしょ。
>268でネストで表現することが引き起こす複雑さ・わかりにくさが示されているのに
それでもネストすることがメリットになるのはどういうことだ、みたいなことでは？

276 ：Name_Not_Found：04/06/27 14:30 ID:???

>>274
271は引用内引用は引用をネストして使えばいいから「引用内引用」を表す要素は要らない、と言っているのでは？

ただ、引用と引用内引用は別のものだが、強調と強強調は量的な違いなので個人的には属性で指定に一票。

277 ：274：04/06/27 15:01 ID:???

あー、主張を逆に勘違いしてた。そら、話がかみ合わんわ（俺脳内で）

解説ありがと。

278 ：Name_Not_Found：04/06/28 03:21 ID:???

お前ら、strictにマークアップする前に、strictな文章書こうな。

まずはお前から↓

279 ：Name_Not_Found：04/06/28 03:29 ID:???

Taro is not Hanako.

280 ：Name_Not_Found：04/06/28 04:05 ID:???

信じてください、私は嘘つきです。

281 ：Name_Not_Found：04/06/28 05:09 ID:???

<br>
これって明らかに物理マークアップになるタグだよね。
でもさ、
<p>契約内容は正しいでしょうか？それでは「進む」のボタンよりお進みください。</p>
っていう文章の時、見栄えの為に？の後で、改行したい時なんかはどうするべきかな？

<span>で？以降を括るのは、見栄えの為に新しくタグを追加する行為だからStrictらしくない。
もちろん<br>は物理だと思うから駄目。
他に何かあるかな？

多分<br>が物理じゃないって思ってる人もいるだろうから、<br>について少し。
そもそも、文章中における改行というのは基本的に段落であって、それ以外で改行が必要な
事なんて論文やbookではありえない。
改行したい＝次から新しい段落が始まる
なので、改行は本来<p></p>で行うべき。

じゃあなんでStrictに<br>があるんだってことになってくるけど、俺の解釈は
W3CのStrictに対する考え自体が実は意外にStrictではなかったと思っている。
しかし、W3C以上にStrictなHTMLを目指す俺としては、<br>は使えない。

282 ：Name_Not_Found：04/06/28 07:34 ID:???

突っ込みどころは多いが(以下略)。

283 ：Name_Not_Found：04/06/28 08:13 ID:???

ブレイク！ブレイク！

　　　　　( ﾟ∀ﾟ)　　　　・∴.
　　　　（ヽ□＝□━━━
　　　　　　>　> 　　　　.∵’

284 ：Name_Not_Found：04/06/28 09:32 ID:???

>>281
> 改行したい＝次から新しい段落が始まる
> なので、改行は本来<p></p>で行うべき。

改行はbr要素で行うべき。
段落はp要素でマークアップするべき。

W3C以上にStrictなHTMLを目指すとStrictなのかどうかは知らんが、
少なくとも「改行」をbr要素で示さなければStrictではない。

285 ：Name_Not_Found：04/06/28 10:40 ID:???

<br>が物理要素かとかはとりあえず置いといて

>文章中における改行というのは基本的に段落であって、それ以外で改行が必要な
>事なんて論文やbookではありえない。

ちょっとカルチャーショック。そういう論文ばかりの分野もあるんだな。

286 ：Name_Not_Found：04/06/28 10:42 ID:???

>>281
＞見栄えの為に？の後で、改行したい時
見栄えのために個々の文字を全て別の色にしたいときw、と同じだろうね。
そこまで指定可能なスタイルシートシステムの登場を待つしかないだろう。

287 ：Name_Not_Found：04/06/28 10:47 ID:???

「太郎は山へ出かけました」
「花子はどこへ出かけましたか？」
「花子は川へ出かけました」

>>281
こういう表現をする小説は台詞ごとに段落として認識してるのかね。
それともこれはbookじゃないってことかね。

288 ：Name_Not_Found：04/06/28 11:42 ID:???

　単語を折ったりするための強制改行しか必要ないのは英語の仕様、でしょ。
日本語だったら、段落中でも改行は適宜行われる。

　国語の時間にやったじゃん。なんたら段落と意味段落があります、って。

289 ：Name_Not_Found：04/06/28 11:43 ID:???

>>288
形式段落と意味段落ね。

290 ：Name_Not_Found：04/06/28 11:52 ID:???

意味段落と形式段落とでは改行の必要性云々は語れんぞｗ

その段落の中でどうあるか（>287とか）が問題になるわけであって。

291 ：Name_Not_Found：04/06/28 12:17 ID:???

>>287
「太郎は山へ出かけました」「花子はどこへ出かけましたか？」「花子は川へ出かけました」

同じ文書の中にこういう表現があったら>>287も段落かもしれないな。

> 形式段落
形式段落って…
段落のスタイルで改行を行わない場合でも、適宜改行を必要とするのだろうか。
その場合に必要ないのであれば、それは「改行」なのだろうか？

292 ：Name_Not_Found：04/06/28 12:33 ID:???

>>291
意味がわかりません。

293 ：Name_Not_Found：04/06/28 13:00 ID:???

p要素は形式段落の意味なので注意。

294 ：Name_Not_Found：04/06/28 13:02 ID:???

>>293
ソースある？

295 ：Name_Not_Found：04/06/28 13:58 ID:???

>>291
いや、その「太郎は～」「花子は～」「花子は～」がひとつの段落かどうか、でなくて、
カッコの（前）後で改行されることに関してどのように>>281は対応するつもりなのか、っていう。

296 ：Name_Not_Found：04/06/28 14:31 ID:???

形式段落って詩における行と一緒な気がする。
それ自体に視覚表現以上の意味がない。

297 ：Name_Not_Found：04/06/28 14:38 ID:???

とりあえずpでぶったぎった場合、
（大小はあるが）文の趣旨の変わり目として捉えられるよな。

298 ：Name_Not_Found：04/06/28 14:49 ID:???

>>296
形式上、のことだから視覚上のことであって当然だね。
んでも会話文の前後の「」に意味はあるべ？

詩のマークアップとか大変そうだなぁ。
空白とか行間にも意味があるとか主張されそうだし。
HTMLが得意としない分野であることは確かだ。

299 ：Name_Not_Found：04/06/28 15:00 ID:???

>>293
んなことないと思われ。
だいたい原文の英語に意味段落と形式段落の区別あるか？
むしろ paragraph=意味段落だろ。

300 ：Name_Not_Found：04/06/28 15:00 ID:???

XHTML1.x(= HTML4.01)のPとXHTML2.0のPが同じPとは限らない訳だが（名前空間違うし）

XHTML2.0に限定すれば、
P 要素 = 意味段落
L 要素 = 形式段落
でいいのかなぁ。
それとも L はもっと物理的な要素とみなされるんだろうか。

301 ：Name_Not_Found：04/06/28 15:02 ID:???

>>299
俺は「原文の英語に意味段落と形式段落の区別はなくてparagraph=形式段落」
だと習った。

ぐぐってみたが適当なソースが見あたらず、正しく習ったのか、
俺が勘違いして憶えてないかあんま自信ないが。

302 ：Name_Not_Found：04/06/28 15:17 ID:???

ティムたんが、日本語の意味・形式段落の使い方を知っているとは
想像しがたい。

303 ：Name_Not_Found：04/06/28 15:17 ID:???

参考まで
ttp://www.asahi-net.or.jp/~wq6k-yn/para.html

304 ：Name_Not_Found：04/06/28 15:21 ID:???

>>303
その文章は明らかに意味段落と形式段落を区別していないな。
知っていて paragraph=形式段落としているのではなく、
区別自体をないものとして記述している。（わざとか天然かは知らんが。）

305 ：Name_Not_Found：04/06/28 15:22 ID:???

>>300
lはlineだよな

306 ：Name_Not_Found：04/06/28 15:30 ID:???

こういう細かいところは自然言語の根本的な違いが響いてくるな。
個人的にはPは形式段落だと思ってるが。
意味段落ってかなり曖昧だし。

個人的には意味段落として分割されるような切れ目には見出しを
入れることにしてる。

307 ：Name_Not_Found：04/06/28 15:30 ID:???

http://www.google.co.jp/search?q=paragraph+%E6%84%8F%E5%91%B3%E6%AE%B5%E8%90%BD+%E5%BD%A2%E5%BC%8F%E6%AE%B5%E8%90%BD&ie=UTF-8&hl=ja&lr=

↑ぐぐって見た。やはり意見が分かれている模様。

308 ：Name_Not_Found：04/06/28 15:45 ID:???

仮に意見が分かれたままFAが出ないとして…、
一つのソースで両方の解釈を混在させるのは論外なのでどっちかに統一して
書かねば成らない訳だが、どっちのほうがStrict的に「より無難」かなぁ。

309 ：Name_Not_Found：04/06/28 15:48 ID:???

>>308
だからその意見が分かれているのでは？
形式段落をpとすれば特に意味段落もマークアップするにはdivがいるだろうし、
意味段落をpとすれば形式段落の表現にbrを連発しなければならない。

形式段落をpとする方がどっちかというと多数派な気はする。
（そして意味段落は特別にマークアップしない。）
やっぱbrはstrictが敬遠する要素の一つだと思う。

310 ：Name_Not_Found：04/06/28 15:49 ID:???

英語で書いてしまう

311 ：309：04/06/28 15:49 ID:???

×strict
○strict志向の人

312 ：Name_Not_Found：04/06/28 15:51 ID:???

>>309
brはStrictとか以前にXML的な書き方ではないからなあ…。

313 ：Name_Not_Found：04/06/28 15:59 ID:???

>意味段落をpとすれば形式段落の表現にbrを連発しなければならない。
これは本当なの？意味段落の為に div なら、形式段落為にspanじゃないの？

形式段落 -> (原稿用紙だと)改行で表現 -> br

ってことなら、span に display:block のほうがマシというかstrict的じゃないかと
思う訳だが。

314 ：Name_Not_Found：04/06/28 16:04 ID:???

>>287の br 使わないマークアップ例きぼん

315 ：Name_Not_Found：04/06/28 16:20 ID:???

そもそもこの例題に疑問があるが、それはおいておいて、

pは形式段落派
<div>
　<p>「太郎は山へ出かけました」</p>
　<p>「花子はどこへ出かけましたか？」</p>
　<p>「花子は川へ出かけました」</p>
</div>

pは意味段落派
<p>
　<span>「太郎は山へ出かけました」</span>
　<span>「花子はどこへ出かけましたか？」</span>
　<span>「花子は川へ出かけました」</span>
</p>

他のdivやspanと区別が付かなくなると言う場合適当なclassをつけて対応。

316 ：Name_Not_Found：04/06/28 16:23 ID:???

個人的にはHTMLのpは形式段落だろうが意味段落だろうがどうでもいいんだと思うw
形式段落にpを使うのは、spanに比べて後方互換に優しいってだけじゃないかな。

317 ：Name_Not_Found：04/06/28 16:30 ID:???

spanでいいじゃんという人はCSS切ったときのことは考えないんですか？
改行が見栄えだと割り切れるということか。

318 ：Name_Not_Found：04/06/28 16:32 ID:???

classで複数のspanを関連付けるんならともかく、
単に<span></span>の連続で構造を分けるだけなら
<br>を使うのとたいして違わないような気がする

319 ：Name_Not_Found：04/06/28 16:39 ID:???

というか、形式段落とか意味段落とかいうもの自体がナンセンスだと思うのだけど。
小説やエッセーの場合は、英語でもパラグラフ自体が曖昧だから置いといて、
論文の場合はパラグラフライティングをするべき。
単純に、形式段落＝パラグラフ、意味段落＝セクションで良いと思う。
「形式」段落と言っても、全く無造作に切り分けたものではなく、
一定の意味のまとまりになっていなければならない。
形式段落がパラグラフになっていない論文は、ただの悪文。

320 ：281：04/06/28 16:48 ID:???

とりあえず俺は>>287の

>「太郎は山へ出かけました」
>「花子はどこへ出かけましたか？」
>「花子は川へ出かけました」

これを一行ずつ改行するのは読みやすくの為であって構造的なものではないと思う。
こういうセリフは元々、別の何かでそれぞれ別の人間の発言であるとわかるように
マークアップするべき。

改行しただけで、それぞれが別の人の発言ですよ。なんてのは書いた本人だけの勝手なルール。
引用になるのかどうかはわからないが、とりあえず<br>でやることじゃないな。

まあそもそも<br>に構造的な意味があると考えていいのかね。

321 ：Name_Not_Found：04/06/28 16:48 ID:???

>>319
理系の論文の場合はどうするのよ。
化学式や数式が入る場合には、形式段落として解釈するわけにはいかない。

<p>標準酸化還元電位は次のようになる。</p>
<p>O(g) + H2O + 2e ⇔ 2OH(1-)-</p>
<p>この組成式は…</p>

この場合、「O(g) + H2O + 2e ⇔ 2OH(1-)-」は意味段落に近いと思う。

322 ：Name_Not_Found：04/06/28 16:50 ID:???

>形式段落がパラグラフになっていない論文は、ただの悪文。

論文の書き方スレじゃないんだから、論文を例に出すなら
どういう論文が良文かじゃなく、すでにある論文をどう
マークアップすべきかという話をするべきだと思うんだが……

ちなみに、数学や物理系など数式が大量に出てくる論文では、
文の途中での改行すら日常茶飯事。むしろ推奨されてる。

323 ：Name_Not_Found：04/06/28 16:52 ID:???

>まあそもそも<br>に構造的な意味があると考えていいのかね。

何らかの構造的な区切り、という程度の意味はあるんじゃない？
それが必ずしも段落と呼べるほど意味の強いものではないとは思うけど。

324 ：281：04/06/28 16:53 ID:???

後、俺の元もとの質問は

><p>契約内容は正しいでしょうか？それでは「進む」のボタンよりお進みください。</p>
>っていう文章の時、見栄えの為に？の後で、改行したい時なんかはどうするべきかな？

なので、構造的には不必要な改行の時には何でマークアップするべき？ってことね。
なんか俺が<<br>を物理ダグだとか言ったせいで欲しい回答とは別の方向へ話が進んじゃったみたいで。

今の流れとは別に↑の場合のマークアップも答えてくれると嬉しい。

325 ：Name_Not_Found：04/06/28 16:56 ID:???

>>320
>改行しただけで、それぞれが別の人の発言ですよ。なんてのは書いた本人だけの勝手なルール。

違うだろ。日本語の書き言葉が築き上げてきたルールの一つだと思う。

326 ：Name_Not_Found：04/06/28 16:57 ID:???

>改行しただけで、それぞれが別の人の発言ですよ。なんてのは書いた本人だけの勝手なルール。

>>287の用法は日本文学では伝統的なものであるわけだが。

327 ：Name_Not_Found：04/06/28 16:57 ID:???

>>324
<p>契約内容は正しいでしょうか？</p>
<p>それでは「進む」のボタンよりお進みください。</p>
でいいじゃん。

328 ：Name_Not_Found：04/06/28 16:58 ID:???

>>324
<p>契約内容は正しいでしょうか？<br>
それでは「進む」のボタンよりお進みください。</p>
でもいいじゃないの？

329 ：281：04/06/28 17:11 ID:???

>>325-326
日本文学って言われても外国の人がわからないなら意味ないんじゃない？
日本の文章を翻訳にかけて読むときに日本人にしかわからない構造でいいの？

>>327-328
ありがとう。でもそのやり方は微妙かな

330 ：Name_Not_Found：04/06/28 17:14 ID:???

HTMLではどう書いて言い訳しても情報の劣化が避けられないようなものを
わざわざHTMLなんかでできるだけ正しく書こうとする動機が解らん。

>>322
数式の前後の改行って、どう考えても
数式という構造のに与えるスタイルだと思うんだが。
読む側が見栄えで構造を判断してしまうのは仕方のない結果なんだが
同じ見栄えだからといって同じ構造だと判断してしまうのは危険じゃないか？
#「形式段落」なんて元々意味なしだからどうでもいい？

331 ：Name_Not_Found：04/06/28 17:16 ID:???

>>326
例として天声人語だと段落が◆になる事を考えると、
改行が別の人の発言である、という規則は必ずしも当てはまらないと思うがどうだろう。

そもそも「改行」とは文章に置ける理論的な「構造」なのか
はたまた「構造」を視覚的に伝えるために伝統的に生み出された「表現」
なのかを考える必要があると思われる。

個人的には改行は表現の一種だと思う。
>>324の例ではBR要素が合ってもなくてもその文章の意味が変わらない。
こういった場合、「『？』の後で改行したい」というのは表現の一種であり
CSSのセレクタで対応すべき。
ただ、テキストノードという概念が怪しいCSSの構造だと将来的にも
不可能である可能性は高いかもしれない。

332 ：315：04/06/28 17:19 ID:???

>>317
>spanでいいじゃんという人はCSS切ったときのことは考えないんですか？
>改行が見栄えだと割り切れるということか。
UAのデフォルトスタイルに影響を受ける文書構造なんて有り得ない。
すくなくともStrictなマークアップの考え方ではない。

たしかにspanで形式段落を表現する事によって一部ユーザビリティーが
低下する可能性はある。が、それはStrictとはまた別の問題として、
「じゃあ、その上でユーザビリティーはどうやって確保しようか」と
考えるべき事。

333 ：Name_Not_Found：04/06/28 17:25 ID:???

>>331
> そもそも「改行」とは文章に置ける理論的な「構造」なのか
> はたまた「構造」を視覚的に伝えるために伝統的に生み出された「表現」
もう一つ、構造伝達とは無関係の視覚効果を狙った「表現」である可能性もある。

334 ：Name_Not_Found：04/06/28 17:30 ID:???

>>330
情報を劣化させるのは君がショボイだけ。
世界に情報発信するのに一番適しているのはHTML。

335 ：Name_Not_Found：04/06/28 17:33 ID:???

>>334
突っ込みたいけど荒れそうだから止めとく。

336 ：334：04/06/28 17:39 ID:???

>>335
イヤできれば後学ために聞かせてくれ。間違ってるなら早いとこ正しい認識に直したい。

337 ：Name_Not_Found：04/06/28 17:39 ID:???

結局、brが物理要素であることを前提に語っている人と
そうでない人がいるわけで議論は永遠に平行線と思われ。

個人的にはbrとhrは似たようなもんだと思うわけだが。

338 ：Name_Not_Found：04/06/28 17:41 ID:???

HTMLは万能記述言語じゃないんだから、数式や化学式などを
現状のままHTMLで記述しようとすると、うまくいかなかったり、
物理マークアップに頼らざるを得ない場合もある。

そう言う場合は「（数式を記述する書式として）HTMLは使い物にならない」
と言うのは全く持って正しい評価であって、だからといって現状がどう変わる訳でもない。

SGMLベースのHTMLだとMathMLの埋め込みが困難だから、XMLベースのXHTMLに
移ろうぜー、というなら同意。ただし、現在の流れとは関係ない。

339 ：322：04/06/28 17:43 ID:???

>>330
>同じ見栄えだからといって同じ構造だと判断してしまうのは危険じゃないか？

そう言いたくて322を書いたつもりだったんだけど…わかりにくくてスマソ。
論文において、すべての改行が同一レベルの意味区切りになっているとは
限らない、と言えば伝わるかな。

340 ：Name_Not_Found：04/06/28 17:46 ID:???

HTMLとしてStrictを目指すあまりに
日本語の記述に縛りが出るのは本末転倒だと思う。

＞会話文
「どうですか？」<br>「いいです」<br>
発言者が違うのは英訳したって文脈からわかるでしょ。
わからない場合は読者か筆者の頭が悪い。

＞契約内容は正しいでしょうか？それでは「進む」のボタンよりお進みください。
日本語の文章で段落の前後、会話文の前後、
以外に改行を入れるときってあったっけ？
----
　私は学校へ行った。教室へ入った。
机が一つも無かった。
----
段落の中で唐突に改行が出るのはおかしくない？
素直に段落分けるか、改行しないかするべきだと思うよ。
日本語で<br>使うのは会話文の前後だけ。

341 ：Name_Not_Found：04/06/28 17:54 ID:???

>>340
日本語表記にも色々なスタイルがあると思うんだが。
会話文だって改行を行わないスタイルもある。
印刷媒体では少ないけれど、手書きの文章なんかでは
文節が途中で切れないように一つの文の途中で改行したりするのは普通でしょ？

342 ：Name_Not_Found：04/06/28 17:56 ID:???

>>340
> 段落の中で唐突に改行が出るのはおかしくない？
> 素直に段落分けるか、改行しないかするべきだと思うよ。
> 日本語で<br>使うのは会話文の前後だけ。

漏れも国語がそんなに優秀だったわけではないのでアレなんだけど、
この辺に学術的にエロイひと…

…このスレ（板）にはいなさそうだなあ。

343 ：Name_Not_Found：04/06/28 17:57 ID:???

>日本語の記述に縛りが出るのは本末転倒だと思う。
激しく同意するが、しかし、現状仕方がない。

例えば、HTMLはp要素の中に、リストを持てない、表を持てない、
段落を形成する大きさの引用文を持つ事ができない。

たしかに本末転倒だが、しかし、そもそもWebで文章を発表する時に
書式としてHTMLを選んだ時点で受け入れるべき事かと思われる。

必ずしもHTMLでなければいけない訳ではないのだから、自ら意味段落、
形式段落、台詞などを明確に区別した仕様を作るとか、全く別の
フォーマットを採用するとかすることになるのではないかと思う。

# その上で、現在のHTMLはこういう欠点があるのでXHTML2.0では解消される
べきだ、と言う意見はアリだとおもうが。

344 ：Name_Not_Found：04/06/28 18:51 ID:???

>>340
>＞会話文
>「どうですか？」<br>「いいです」<br>
>発言者が違うのは英訳したって文脈からわかるでしょ。
>わからない場合は読者か筆者の頭が悪い。

頭が悪いのか。それでいいと思うならそれでいいが・・・・・

例えばa君の発言とb君の発言がある文章中からa君の発言だけ抜き出そうなんて事が
正しい構造化ができていればできるわけで、それが改行で勝手に筆者がこれは別の
人間の発言な。とか言っても全く通用しないわけで。

345 ：Name_Not_Found：04/06/28 19:01 ID:???

例えば議事録や裁判の速記をマークアップしたものなら構造化は必要だが、
純然たる小説から主人公の発言だけ抜き出すなんてことは需要があるのかね？
ないならやらなくても問題なしとは言わんが、部分的に抜き出してああだこうだ、
ってのも実に色気のない話だなぁと思ったりする。

# 小説媒体を Web に移すためにはそれだけでマークアップ言語構築できそうだな。

346 ：Name_Not_Found：04/06/28 19:01 ID:???

>>344
しかし、
「<p>パイナップルは50円ですが、リンゴは10円です。ミカンも10円でスイカは60円です。</p>」
という文章から「10円のものだけ抜き出す」という事は出来ない。
テーブルにすれば抜き出せるかも知れないけど、これはこれでStrictな段落だと思う。
だから、必ずしも「Strict＝構造化」とは言えないかも。

他にも
<p>我が社では最先端技術の開発はもちろんのこと、環境保全や世界平和にも取り組んでいます。</p>
という文章は
<p>我が社では次の事業に取り組んでいます。</p>
<ul>
　　<li>先端技術の開発</li>
　　<li>環境保全</li>
　　<li>世界平和</li>
</ul>
となる場合もある。
この場合も「最初の例は取り組んでいる事業をリストとして抜き出せないから通用しない」
とは必ずしもならない。

わかりやすさを考えればもちろんどちらを選ぶかが決まってくるけど、
どこまでを要素としてマークアップするかは必ずしも一意ではないはず。

347 ：Name_Not_Found：04/06/28 19:05 ID:???

>>345
それは同意。風情がないよねえ。
なんというか、やりだすと行間まで説明するとかなりそうだし。

348 ：Name_Not_Found：04/06/28 19:12 ID:???

>>347
極端な話、構造に示せない部分に味のある文書だってあるわけだしね。
それをメタデータ化して抜き出すのは実に困難であると思われるわけで。

349 ：Name_Not_Found：04/06/28 19:15 ID:???

>>345
>だから、必ずしも「Strict＝構造化」とは言えないかも。

>>345 の理論から導き出せる結論は

必ずしも「Strict＝ "閲覧者or記述者が望む" 構造化」とは言えない

であり、この点には同意するが、いきなり全般的に
「必ずしも「Strict＝構造化」とは言えないかも」
などとHTMLが例外なく構造化言語であるか否かに疑問を呈する内容ではない。

350 ：349：04/06/28 19:16 ID:???

>>345 じゃなくて　>>346 の間違い。スマ。

351 ：346：04/06/28 19:19 ID:???

>>349
おっしゃるとおりです。
自分の書き方がわるかったです。

352 ：Name_Not_Found：04/06/28 19:19 ID:???

確かにマークアップの粒度はケースバイケースだよなあ。

353 ：Name_Not_Found：04/06/28 19:28 ID:???

閲覧者が望む構造化（= Strict）は、必ずしも記述者が想定する構造化（= Strict）ではない、ってことか。

354 ：Name_Not_Found：04/06/28 19:28 ID:???

「改行は句読点と同じく記号に分類されるもののひとつだ」と考えて、
かつ「会話の前後に改行を入れるのは日本語の書き物において一般的だ」と認めれば、
会話の前後に<br>を入れるのはむしろ推奨されるのかな。

段落の最初に空白文字を入れるのはStrictか、というのと似た話だと思う。
原稿用紙で1ます空いてるのを「空白文字が書いてある」と考えるべきか「隙間が開いている」と考えるべきか。
そして、「原稿用紙なら前者/後者でコンピュータなら後者/前者」という考え方はどうなのか。

355 ：Name_Not_Found：04/06/28 19:36 ID:???

>>354
段落の最初の空白は紙媒体における段落の明示。webでは<p>自体が段落の明示。
見た目を紙媒体に近づける行為はCSSでやりましょう。

っていうか
>そして、「原稿用紙なら前者/後者でコンピュータなら後者/前者」という考え方はどうなのか。
この文のスラッシュが何を意味したいのかわからん。とりあえず俺には理解できない文章だな。

356 ：Name_Not_Found：04/06/28 19:39 ID:???

>>354
前半部分に関しては多分そうだろうと思う。

後半部分に関しては、空白か、隙間か、というより、
有意の文字なのか、スタイルなのか、そして仮に有意の文字だとして、それは
日本語全体の文法なのか、原稿用紙固有の記号（一種のマークアップ?）なのか、
と言う話に成り、さらにHTMLにはP要素が既にあるのだから(*)、不要なのではないか、
と言う話になる。

ちなみに、俺としては、段落の行頭が１マス空いていない記述（或いはスタイル）も
あり得るし、P要素があるので、仮に有意の記号だったとしても、HTMLにおいてはP要素が
代理をしてくれているので、要らない、と考えている。

*: ただし、この時P要素は「形式段落」と解釈されている。

357 ：Name_Not_Found：04/06/28 19:56 ID:???

>>341
> 文節が途中で切れないように一つの文の途中で改行したりする
その類いはpreでマークアップしたい。

358 ：Name_Not_Found：04/06/28 19:59 ID:???

>>341 >>357
おまいらその発想は文字サイズ固定に繋がるんじゃないか？見た目で構造を伝えるな。

359 ：Name_Not_Found：04/06/28 20:08 ID:???

>>341
つーか「色々な『スタイル』」言ってる段階で既にStrictなHTMLの範疇ではない。

そのスタイルがどうしても構造化や意味づけと分離不可である場合、
たとえば2chの縦読なんかの場合は、>>357の言うように pre にしたり、
或いはbrの出番かとは思うが。

360 ：Name_Not_Found：04/06/28 20:14 ID:???

>>354
>307のリンク先にそんなこと言ってる人もいたな。
まあ人それぞれってこった。
HTMLはテキストのマークアップ言語だからね。

361 ：Name_Not_Found：04/06/28 20:21 ID:???

>>359
だから漏れは形式段落なんてものもHTMLの範疇ではないと思っている。
それは単に見た目であり紙の表記慣習の一つであり、構造ではない。

362 ：359：04/06/28 20:32 ID:???

>>361
それはそれで (Pが形式ではなく意味段落を表すと言う前提なら)いいのでは？

ただ、「単に見た目であり紙の表記慣習の一つ」ならbrやpreの出番ですらないが。

363 ：Name_Not_Found：04/06/28 20:34 ID:???

>>354
> 原稿用紙で1ます空いてるのを「空白文字が書いてある」と考えるべきか「隙間が開いている」と考えるべきか。
原稿用紙で改行した後に１字空いているのは、植字屋向けの指定です。
前の行が行末一杯に字が埋まっていたりする場合に
改行の存在が不明瞭になるのを避けるために、改行の後に一字空けるということをします。
# 段が落ちるから「段落」といわれる。すこぶる物理的な名前だw
# 日本語表記における「段落」が単なる改行以上の意味を持つようになったのは
# 比較的後の話かと。

364 ：Name_Not_Found：04/06/28 20:35 ID:???

っていうか<pre>はありなのか？

365 ：Name_Not_Found：04/06/28 20:36 ID:???

>>361
それはあなたの考え方。
HTMLはマークアップ言語。先にテキストありき、って人も多い。
最初からHTML向けの構造をもった情報をつくる人もいるのだろうが。

366 ：Name_Not_Found：04/06/28 20:39 ID:???

>>362
>>341は>>340の
> 日本語の文章で段落の前後、会話文の前後、以外に改行を入れるときってあったっけ？
に対する反例だから。

367 ：Name_Not_Found：04/06/28 20:55 ID:???

>>331
＞例として天声人語だと段落が◆になる事を考えると、

朝日新聞を読むようなヤツにStrictを語る資格はない！

とｵﾓﾀ。

368 ：Name_Not_Found：04/06/28 20:58 ID:???

>>364
>>359

369 ：Name_Not_Found：04/06/28 21:11 ID:???

>>365
> HTMLはマークアップ言語。先にテキストありき、って人も多い。
先にテキストありきでHTMLに向かない情報構造作っておきながら形式にHTMLを選ぶなら、
HTMLで何が表現できなくても伝わらなくても諦めるしかないだろう。
# 先に写真画像ありきなんつったって
# 16色GIF使うなら汚くてもしょーがないだろ、みたいな。

370 ：Name_Not_Found：04/06/28 21:27 ID:???

会話文なんぞqで囲って適当なスタイル付けたらいいじゃん。
数式、化学式だって同じ。

>>345
あのーそういうことやってる研究者いっぱいいるんですけど。
TEI(Text Encoding Initiative)もあるし。
そうでなくても小説とか読んでるときに前の方読み返すときに欲しいときが。

というかセマンティックWebってつきつめるとそういうことでしょ。

371 ： ◆FoxMX6a/hk ：04/06/28 21:39 ID:???

国語学はそこそこ勉強したつもりでいるのだが。

形式段落という名前であっても、意味上の区切りで段落を置くことは変わらない。
つまり、形式段落も意味上のまとまりを持った一つの単位だ。

逆に意味段落は、そうした形式段落を複数まとめたものであるといえる。
つまり、現行 HTML で表現するならば形式段落は p で、意味段落は div でよいのではないか。
将来的には section をきちんとマークアップできるようになれば、これが意味段落になる可能性がある。

372 ： ◆FoxMX6a/hk ：04/06/28 21:43 ID:???

書き忘れたが、会話文の直後で改行が発生するのは、原稿用紙の使い方というルール上の制約でしかない。
会話文を明示的にマークアップする手段が用意されていないのだから、それぞれの会話文に span を適用して
その直後での改行を CSS で実現できたら、それがもっとも適当であるように思う。

373 ：Name_Not_Found：04/06/28 22:08 ID:???

日本語における改行はこんな感じ？

1. 段落の前後の改行
段落をpでマークアップ。

2. 会話文の前後の改行
（会話文を表す要素がないので）便宜的にbrを挿入するか、
会話文をspanでマークアップしてCSS。
後者がよりStrict。

3.自由に改行した文章
preでマークアップ。

374 ：Name_Not_Found：04/06/28 22:08 ID:???

>>370
qは引用なんだから小説とかに出てくる会話に使っちゃだめだろ。
まして数式をや。

375 ：Name_Not_Found：04/06/28 22:16 ID:???

>>371
> 形式段落という名前であっても、意味上の区切りで段落を置くことは変わらない。
この点の合意が取れるかどうかは微妙かなと思う(特に論説文以外では)。

>>374
> qは引用なんだから小説とかに出てくる会話に使っちゃだめだろ。
英文の ' や " は引用符なんだから小説とかに出てくる会話に使っちゃだめ、とか思ってるの？

376 ：364：04/06/28 22:20 ID:???

なあ、だから、<pre>はありだと思ってるのか？おまいらは。

<pre>でどんな構造が伝わるのだ？<pre>=<br>を内在させまくり
なわけだがおまいら<pre>でどんな構造を示したいんだよ。

とりあえず縦読みは特殊なものだから置いておけ。

377 ：Name_Not_Found：04/06/28 22:24 ID:???

>>369
必ずしも形式段落を否定しなければならないわけではないってことだ。
# 写真画像自体を載せる目的で img 使ってもいいでしょ。
# たとえ alt に*完全な*代替記述を書けないとしても。

378 ：Name_Not_Found：04/06/28 22:25 ID:???

>>376
preなんかはまさにHTMLがもともとテキストをマークアップするために
生まれたものであることを示していると思う。

379 ：374：04/06/28 22:37 ID:???

>>375
>英文の ' や " は引用符なんだから小説とかに出てくる会話に使っちゃだめ、とか
>思ってるの？

思ってないよ。qは別に'や"や「の完全な代用品じゃないから。
HTMLの仕様書にはqは「引用されたテキストを示す」って書いてある、それだけ。

380 ：Name_Not_Found：04/06/28 22:54 ID:???

近代の小説などは、本来叙情・叙事詩などで使われる、
特に明示的に改行を含んだり、わざと句読点を抜いて段落を繋げたり
という技術がふんだんに盛り込まれている（モノもある）。

こういったモノも「自由に改行した文章」ということで、pre なんですかね。

381 ：Name_Not_Found：04/06/28 23:22 ID:???

>>376
＞とりあえず縦読みは特殊なものだから置いておけ。
何故？　preは「整形済み文章」と言う特殊な文字列を扱う為の
要素であって、「特殊な物だから置いておけ」と言われても困るんだが。

縦読以外では、改行位置によって意味が変わるプログラミングコードなんかは完璧に
preだと思うがどうか？　例えばjavascriptにおいて

a += 1 // a = a+1
と
a += 1 //
a = a+1
は全く意味が異なるので、改行が増えたり減ったりしてはいけないといういみで
この種のプログラミングコード阿ｈpreでマークアップすべきだと俺は思っている。

382 ：Name_Not_Found：04/06/28 23:24 ID:???

プログラミングコードも特殊だ、じゃあ、code要素はどうなんるだ、
おれがいっているのは自然言語としての日本語だ、じゃあ、詩は自然言語なのか、
という泥仕合が始まるに３ガバス

383 ：Name_Not_Found：04/06/28 23:44 ID:???

brは物理要素か
qを会話文でつかうか否か

散々既出だが、ここまで引っ張れるお前らが素敵。
流石に20レスもついていたら疲れるだろと

「」は全てqで置き換えると思っている人がいれば、もっと素敵

ちなみに漏れ様のpの見解を述べさせてもらうと、
pは形式段落だな。意味段落は、セクションというカタチであらわせば良いと思う。divなり使ってな。

384 ：Name_Not_Found：04/06/28 23:44 ID:???

>>380
整形済みテキストとするのも一つの解決策かとは思う。
だって、ユーザスタイルや自動折り返しなんかされたら
本来の意図がぶち壊しになるようなシロモノでしょ。

385 ：Name_Not_Found：04/06/28 23:45 ID:???

>>383
？

386 ：370：04/06/28 23:49 ID:???

>>374
会話文はqだろ。と思ってた。
昔このスレで似た話題が出たときもそういう意見の人ばかりだったがそうじゃない意見もあるのか。

John said, <Q lang="en-us">I saw Lucy at lunch, she told me
<Q lang="en-us">Mary wants you
to get some ice cream on your way home.</Q> I think I will get
some at Ben and Jerry's, on Gloucester Road.</Q>

という例文も仕様書に載ってるし。

ちなみに「数式、化学式だって同じ。」というのは「数式、化学式も適当な要素(imgかobjectかMathMLの要素かは知らないが)でマークアップしてスタイル付ければいいじゃないか」という意味。qを使えという意味ではない。言葉足らずだった。

kbdやsampなどの要素からも分るようにHTMLは元々コンピューター系の文章を書くのが主要な使い方だった(大昔だけど)。preはもともとコードを書くためのものだと思われ。PythonとかMakefileとかもろに空白の影響受けるし。
でもそれ以外にも詩とか空白や改行が意味を持つテキストには使ってもいいと思う。preformattedというよりwhitespace significantというイメージで。空白や改行がどんな意味を持つかはそれぞれの内容による。

#関係無いが縦読みは2ch独特のものじゃなくて詩などで昔から良く行われていたもんだから縦読みを除くと詩も除かないといけなくなる。

387 ：Name_Not_Found：04/06/28 23:51 ID:???

>「」は全てqで置き換えると思っている人がいれば、もっと素敵
それでも別にいいんじゃないの？
もともと引用符の入れ子の慣習を制御するための要素だし。
(地域によって"が外側に来る慣習と'が外側に来る慣習の両方があり
それを文書作成後に変更できるようにするのがqのもとの目的だった)

388 ：Name_Not_Found：04/06/28 23:51 ID:???

>>386
うーむ。例は例だけど、
引用というのは、あくまで【他人の】文章の引用だからな。
自分で会話文書いて、それを引用とするのは抵抗がある。

389 ：Name_Not_Found：04/06/29 00:02 ID:???

>>383
最近スレが伸びると必ず君見たいなの出てくるね。

そんで批判はするが、大した意見を持ってないというオチ。

まあ昔からココ見ててまたこの話か。って思うんだろうけど、うんこだよ。お腹痛いから終わり

390 ：Name_Not_Found：04/06/29 00:43 ID:???

なんで土日はスレが伸びなくて平日の昼間に伸びるんだろう。先週もそんな感じだったな。

391 ：Name_Not_Found：04/06/29 00:49 ID:???

お互いに荒らしや天然、キティーだとおもったら放置よろ。

話して分かり合える以外の奴と話すのはスレの無駄。

392 ：Name_Not_Found：04/06/29 00:59 ID:???

すまん、ちょっと話がズレるけど、サイトに掲示板スクリプトを置くとして
その書き込み内容はどう処理してる？

393 ：Name_Not_Found：04/06/29 01:02 ID:???

>>387
「」ってさ、本来の言葉とは違うっていう意味を表すときにも用いるし、
強調としても用いられるから、単純にqに置換するのはイクナイ

394 ：Name_Not_Found：04/06/29 01:02 ID:???

カスイケスレ追い出された大量の議論厨が流れ着いたと推測。
あっちもかつて平日の昼間に議論でレスが伸びてた。

395 ：392：04/06/29 01:03 ID:???

わかりづらい説明だ・・
つまり、一般にはエンターによる改行を<br>に置き換えてるよな。
このスレ的にはそれはどうなのかと思って。

396 ：Name_Not_Found：04/06/29 01:07 ID:???

>>394
遠出の釣りですか？カスイケスレに帰って下さい。

397 ：Name_Not_Found：04/06/29 01:21 ID:???

HTMLかそのサブセットを直接書ける掲示板ならそのまま。
そうでないなら改行はp。
でやってます。

Wikiは1つの改行は無視して2つの改行をpにする場合がほとんどだけど日本だとあんまりなじみが無いので。

HTMLかそのサブセットかWikiのような特殊なプレインテキストが使えない場合、書く人それぞれが俺ルールで書くので書き込み内容をうまく構造化することはできず、どうしてもStrictにはなりづらい。
この書き込みだって改行は形式段落(と2chの長い行の制限逃れ)、空白行は意味段落(もしくはXHTML2.0で言うところのsection)という俺ルールで書かれてる。

398 ：Name_Not_Found：04/06/29 01:22 ID:???

>>395
書き込む側にStrict的な意志がない以上、
ある程度までしかStrictな処理は難しいと思われ

399 ：Name_Not_Found：04/06/29 01:30 ID:???

いっそのことtextファイルにしてiframeで表示とか。

400 ：Name_Not_Found：04/06/29 01:38 ID:???

>>386
その例では実際にJohnやLucyがそういう発言をしてるわけでしょ？
つまり引用である会話文なわけだから、qの適用範囲を拡大せずとも
引用の例文として理解できる。
会話文全般への適用拡大の例だとすれば、一言その旨説明があってしかるべき。

401 ：Name_Not_Found：04/06/29 01:45 ID:???

>>397
いや、形式段落ってそういうものじゃないと思う。
その文章を原稿用紙に書いたとして、1文ごとに改行なんてことはしないよね。
空行を入れているところが形式段落(=paragraph)で、意味段落はもっと大きなまとまり
というのが妥当かなと。

402 ：392：04/06/29 01:49 ID:???

>>397
改行を<p>とするということは、たとえば

<p>HTMLかそのサブセットを直接書ける掲示板ならそのまま。</p>
<p>そうでないなら改行はp。</p>
<p>でやってます。</p>
<p></p>
<p>Wikiは～以下省略

となってしまうわけだよね。
<p></p>は無視するとしても、それってやっぱりおかしいと思うんだけど・・
と思ったら>>401がわかりやすく書いてくれてた。

書き込み自体が「整形済み」であるとして<pre>でマークアップするのはどうなのかな。
その改行も含めて書き手の意図する文章だよね。

>>395
そのある程度をどう実現するかを考えたいんだ。

403 ：Name_Not_Found：04/06/29 01:52 ID:???

>>400
小説の一節かもしれないよ。
q要素は「地の文とは異なる主体による発言」と考えられない?
フィクションであるかノンフィクションであるかで区別するより、
ある種の「」を形式的に置き換えるものと考えた方が良いと思う。

404 ：Name_Not_Found：04/06/29 02:00 ID:???

>>q要素は「地の文とは異なる主体による発言」と考えられない?
仕様で「引用」って明言されて居るんだからどう考えてもそこまで拡張するのは無理。

引用なら引用元を明示したり、引用先が引用文に対して主になっていなければ
行けなかったり色々ある訳で、単純に「他人の発言」とか「転載」でつかうと、
論文とかで本当に引用で使ってる場合でも、「このqは引用かどうか解らない」
と言う事になって自動処理（例えば引用文献一覧の作成とか）ができなくなって
きわめて迷惑。辞めてくれ。

405 ：Name_Not_Found：04/06/29 02:08 ID:???

>>404
禿同だ。ここの連中は拡大解釈が大好きなようだな。
素直にそういうセマンティックはやめてくれといいたい。

406 ：Name_Not_Found：04/06/29 02:13 ID:???

例えば小説において、q要素で誰かの発言をマークアップするのはどうだろう？
地の文と主従の関係が保てるか？とか、引用の慣例に従ってるか？とか。

407 ：406：04/06/29 02:14 ID:???

スマソリロードしてなかった。

408 ：Name_Not_Found：04/06/29 03:31 ID:???

>>392
preで良くないか？内容が整形テキストなんだろうよ掲示板での発言は。

\r\nを<br>に置換するより中身から\rを削除して<pre>で括る処理にしたほうが折れは楽。

409 ：Name_Not_Found：04/06/29 03:33 ID:???

現在のHTMLが力不足で、どうしてもある程度解釈を拡張しなきゃならない、
と言う奴はどうぞご自由に「自分で名前空間作って」そこで
（既存のUAが、HTML4.01互換の要素と勘違いするかも知れない）独自解釈の
要素を使ってくれ。

こうしておけば、既存のUAはHTML4.01風に処理してくれるし、
自分で「この名前空間のpは意味段落、brで形式段落を形成」と定義出来るし、
セマンティックを重んじる奴は名前空間みてXHTML1.xのそれと
明確に異なる処理が出来る（あるいは処理しない事ができる）ので
安心だ。

なんだったらtable要素を「レイアウトをするための物理要素」と
再定義しても良い。
Strict指向からすると眉をひそめられるかも知れないが、非難される事はないはずだ。
（まぁ、流れに逆行した概念を「広く勧めよう」としたら、それに対する
批判はあるかも知れないが）

410 ：Name_Not_Found：04/06/29 03:45 ID:???

> なんだったらtable要素を「レイアウトをするための物理要素」と
> 再定義しても良い。
> Strict指向からすると眉をひそめられるかも知れないが、非難される事はないはずだ。

そもそも XML 的にどうかということを XML でやりたがる意味がわからん。

411 ：Name_Not_Found：04/06/29 07:45 ID:???

再定義という言い方はどうかと。
新しい名前空間作って異義同名の語彙を定義するだけでしょ。

412 ：409：04/06/29 09:03 ID:???

>>410
strict的にはどうかということだが、XML的になんの問題が？
ひょっとして見栄えを定義するXMLの事を言ってる？　だとしたらSVGって知ってる？

>>411
うん。その通りです。失礼。

413 ：Name_Not_Found：04/06/29 09:41 ID:???

スレ勢い55.44です

>>391
わかりあう必要はないわけだが、他の住人のことも考えれってことに同意

414 ：Name_Not_Found：04/06/29 12:45 ID:???

>>401
397の最初の2行はどちらかというとリストだな。その次の1行と合せて形式段落であり、意味段落だと思う。

それでやはり最後の2行はそれぞれ1行が形式段落でその2行を合せて意味段落だと思う。

397ではたまたま1文で1つの形式段落となっているが普段必ずしもそうしている訳ではない。1行に2つの文を書くこともある。

>>404
どちらにしろ386に出ている例文は引用元を明示していないし引用先が引用文に対して主になっているわけでもない。
403の言うようにフィクションかノンフィクションかでマークアップが変えるの不は自然だと思う。

415 ：404：04/06/29 13:06 ID:???

>403の言うようにフィクションかノンフィクションかでマークアップが変えるの不は自然だと思う
だからそもそも会話文にqを使おうという発想そのものがまちがってるんだよ。

もっと端的に言おう。HTML4.01と、4.01互換のマークアップ言語では、
あらゆる引用以外の文章にq tagを使ったら仕様違反。
あらゆるインラインレベルの引用にq tagを使わなくても仕様違反。

それ以外に解釈の余地などない。

416 ：Name_Not_Found：04/06/29 13:10 ID:???

>>415
禿同。q要素は引用以外には適用できないし、仕様書にも使えると書かれていない。
未だにどういう思考的アプローチをもって会話文にq要素でマークアップする、
ということになったのかさえ理解できない。

417 ：Name_Not_Found：04/06/29 13:15 ID:???

>>415-416
同意。

418 ：Name_Not_Found：04/06/29 13:43 ID:???

ひょっとして英語圏だと「会話文も引用の一種」っていう認識有る？
会話文括るのもクオテーションマークだけど、べつにそういう訳じゃないのかな？

419 ：Name_Not_Found：04/06/29 13:55 ID:???

「引用符/quotation mark」という言葉にとらわれすぎ。
引用は引用符の機能のひとつに過ぎないし、逆に
引用符でくくるのは引用を示すやり方のひとつに過ぎないわけで。

420 ：Name_Not_Found：04/06/29 13:58 ID:???

>>415-417

>>386の
John said, <Q lang="en-us">I saw Lucy at lunch, she told me
<Q lang="en-us">Mary wants you
to get some ice cream on your way home.</Q> I think I will get
some at Ben and Jerry's, on Gloucester Road.</Q>

は仕様違反な例文なわけね。

421 ：Name_Not_Found：04/06/29 14:01 ID:???

>>420
会話文かどうかと引用かどうかは直行する概念だろうに。
引用でありかつ会話文ならばqを使っても何の問題もない。
400で既出。

422 ：Name_Not_Found：04/06/29 14:04 ID:???

>>420
>386は小説や文学上の表現として使われるよう例示されているのか？

423 ：Name_Not_Found：04/06/29 14:08 ID:???

>「引用符/quotation mark」という言葉にとらわれすぎ。
とはいうものの、単に引用符で囲むことが quote と言われたりもするのでなんつーか。

>>420
個人的には定義リストで対話マークアップ、と似た事例かなと思う。

424 ：415：04/06/29 14:19 ID:???

>>420
重要なのは、「引用かどうか」であって、「会話かどうか」ではない。

>>423
で、お前は仕様を読んで、単に引用符で囲むと言う意味で quote と書かれていると思う？

425 ：Name_Not_Found：04/06/29 14:26 ID:???

○ 引用 ⇔ Q
× Quote ⇔ Q
ということである。

426 ：416：04/06/29 14:31 ID:???

>>425
落ち着け。言いたいことはわかるが、そんなことは仕様書に書いてない。

427 ：Name_Not_Found：04/06/29 14:38 ID:???

事例
1.彼は「……」と言った。（実在の人物の発言）
2.彼が「……」と言ったらいいのにな。（実在の人物の、架空の発言）
3.前著で「……」と述べたが、さらに考察を進めたい。（過去の自分の文章）
4.この小説の冒頭、主人公が「……」と言っている。（他人の書いた小説の中の、架空の人物の発言）
5.私はその時「……」と言いました。（過去の自分の発言）

q要素で表せるのはどれ？

428 ：Name_Not_Found：04/06/29 14:46 ID:???

俺的自然度
４＞＞＞３＞＞1≧２＞＞５

429 ：Name_Not_Found：04/06/29 15:16 ID:???

>>427
3,4のみ

430 ：Name_Not_Found：04/06/29 15:21 ID:???

1,3,4,5

431 ：Name_Not_Found：04/06/29 15:29 ID:???

>>427
２は明らかに違うと言い切れるが、１，３，４，５に関しては
引用の要件を（著作権法的に）満たしているかどうか判断が付かないので、
その部分だけでは何とも言えない。

ただ、自己の著作や発言を引用することは一般的な引用の規範から認められている模様なので
条件が一緒なら、他人の発言と自分の発言は区別する必要が無いと思われる。

また、架空の人物の発言も、一般的にはその架空の人物を著作者の発言と
解釈出来るので、これも特に区別する必要は無いと思われる。
（架空の人物の発言が、著作者の主張と一致するかどうかはまた別の問題だが）

432 ：Name_Not_Found：04/06/29 15:32 ID:???

>>420
（´,_ゝ｀）ﾌﾟｯ

433 ：Name_Not_Found：04/06/29 15:38 ID:???

>>431
言ってる事は解るが、
＞引用の要件を（著作権法的に）満たしているかどうか判断が付かないので
この著作権法的ってどの国の法律？　やっぱ(仕様も正本は英語だし)米国？

それともベルヌ条約とか国際的な取り決め？

434 ：Name_Not_Found：04/06/29 15:39 ID:???

発言からの引用と、会話がごっちゃになってるのがいるな。

435 ：Name_Not_Found：04/06/29 15:46 ID:???

俺は引用といえば、古人の有名な言葉とか、
文書化してあるものからのことを連想する

436 ：Name_Not_Found：04/06/29 15:50 ID:???

>>431
釣り？マジレス
引用の意味およびマークアップと法的な要件は直接関係ないと思うけど。
img 画像の使い方と画像の著作権が直接関係ないのと同じ。

437 ：Name_Not_Found：04/06/29 15:54 ID:???

ちょっと話が飛ぶけど、小説なんかの中で、架空の
(作品内では実在することになっている)著作や人物の発言を
引用の形で提示する時ってq使っていいのかなあ。

「魁！男塾」をマークアップする時に

<q>ゴルフは英国発祥というのが定説であったが　最近では前出の創始者
呉　竜府の名前でもわかるとおり　中国がその起源であるという説が
支配的である。</q>
<cite>民明書房刊『スポーツ起源異聞』</cite>より

みたいな。

438 ：Name_Not_Found：04/06/29 15:57 ID:???

英語圏？でのq要素の扱いも、やはり引用専用だね。
以下のスレッドより
Correct usage of the q element
http://lists.w3.org/Archives/Public/www-html/2004Feb/0033.html

439 ：Name_Not_Found：04/06/29 16:09 ID:???

これは俺のショートショート。

　「不倫したいなー」と山田は言った。
　すぐさま悪魔が来てこう言った。
　「今、『不倫したいなー』と言ったな」
　山田が「不倫したいなー」と言ったのは事実である。

三つの不倫したいなーについて考えると、
・一つ目は山田の発言
・二つ目は悪魔による引用
・三つ目は作者による引用
とするのが妥当じゃないだろうか。
一つ目を作者による引用とするのは、物語性を排斥しすぎだと思う。

440 ：Name_Not_Found：04/06/29 16:10 ID:???

>>439
そういう作り話も徹底的にマークアップするの？

441 ：Name_Not_Found：04/06/29 16:14 ID:???

あれ。
フィクションにおける会話文は引用かどうかって話じゃなかったっけ。
フィクションはマークアップしない！って結論？

442 ：431：04/06/29 16:25 ID:???

>>433
他国の著作者の著作物を引用する事もあるわけで、WWWではやっぱり、
国際的な取り決めに基づいた物になるかと思われる。

>>434
会話かどうか、と言う基準自体が間違っていて、「引用かどうか」のみで
判断すべきと言うのが主張であり、ごっちゃには成っていない。

>>436
>釣り？マジレス
>引用の意味およびマークアップと法的な要件は直接関係ないと思うけど。
思いっきりマジレス。

仕様ではblockquoteと併せて両要素は
>These two elements designate quoted text.
と定義してある。じゃあ、この「quoted text」とは何か、と言えば、
この場合「引用」のことで、有る文章が引用か否かは著作権法に基づいて
判断する必要がある。

＞img 画像の使い方と画像の著作権が直接関係ないのと同じ。
どこら辺が同じなのか寧ろ問いたい。

443 ：Name_Not_Found：04/06/29 16:26 ID:???

藻前ら、スレがやたら早いですよ。

有意義な論議なら大歓迎だが、釣り、煽り、池沼と思ったら放置ヨロ～。

444 ：Name_Not_Found：04/06/29 16:31 ID:???

>>441
してもいいけど(その例だと二つ目は引用と言える可能性があるのかな)、
フィクションの中の引用ってマークアップする利点がいまいち見えないんだよなー。
読み手が引用元に辿り着きやすくなるのが引用をマークアップする
最大のメリットだと思うんで。
フィクションじゃない文章でも、引用元と引用場所がそこまで近かったら
俺の場合マークアップしないような気がする。

>>442
HTML的にstrictかどうかと、文書に違法性がないかどうかは別の問題でしょ。
違法性のある引用だって引用は引用。

445 ：Name_Not_Found：04/06/29 16:43 ID:???

>>444
いやいや、違法性はまた別の問題。
そうじゃなくて、「引用」の定義が法律で行われているってこと。

引用は引用というのその引用とは何ですか？　となると、
定義しているのは法律だから、法律で定めている引用の要件を
満たさないと、そもそも「引用と呼べない」という事。

446 ：Name_Not_Found：04/06/29 16:53 ID:???

>>445
著作権法で規定されてるのは、引用の適切なやり方でしょ。
法律で言葉の定義をする時はちゃんとそれが定義とわかるように書くはず。
第二条参照。
要件を満たさないのは「不適切・違法な引用」になると思うよ。

447 ：Name_Not_Found：04/06/29 16:57 ID:???

どうして「引用」の意味を知るのに、
辞書をひかず法律用語に飛躍するのか。

448 ：Name_Not_Found：04/06/29 17:16 ID:???

　法律で定義された引用の要件（同一性の保持とか）を満たしていない物を
引用と呼んだらマズイ、と言う感覚もわかる。一方で、所謂国語辞書に
載っているような「他人の発言などを『引いて用いる』引用」でなにが悪い、
と言う主張ももっともな気がする。

　しかし、法律的な意味と、慣習的な意味とどっちのほうが優先する、という
根拠が思いつかない。

　俺としては、どっちだろうが、法的なトラブルに巻き込まれたくないので
法的な引用を守ることになるとおもうけど。

449 ：Name_Not_Found：04/06/29 17:25 ID:???

だから法律で引用の定義なんてしてないってのに。
法律を守るべきってのはそれとは別に当然のことだろ。

450 ：448：04/06/29 17:39 ID:???

あ、ほんとだ。（少なくとも日本の法律には）
「著作物はこういう条件で引用出来ますよ」とか「この文面は引用に
適用される／されないよ」と言う事が書いてあるだけで、
「著作権法が定める引用とはこれだ！」みたいなことは書いてないのね…。

451 ：Name_Not_Found：04/06/29 17:44 ID:???

日本の著作権法で引用を扱っている条文

第三十二条　公表された著作物は、引用して利用することができる。
この場合において、その引用は、公正な慣行に合致するものであり、
かつ、報道、批評、研究その他の引用の目的上正当な範囲内で
行なわれるものでなければならない。

ベルヌ条約で引用を扱っている条文

第十条　〔引用〕
(1)
既に適法に公衆に提供された著作物からの引用（新聞雑誌の要約の形で行う
新聞紙及び定期刊行物の記事からの引用を含む。）は、その引用が公正な
慣行に合致し、かつ、その目的上正当な範囲内で行われることを条件として、
適法とされる。

あとは各自考えるということでこの話題終わり。

452 ：Name_Not_Found：04/06/29 18:21 ID:???

>>438
その話はもっぱらqのUAでの扱いについての話で、qが会話文に使えるかどうかについては1人しかコメントしてないので根拠としては薄いかも。

453 ：Name_Not_Found：04/06/29 18:58 ID:???

自作自演が無ければ半分ぐらいの速度になりそう。

454 ：Name_Not_Found：04/06/29 21:42 ID:???

>>453
同じ事の繰り返しでも、繰り返しをすればするだけStrictが広まって行く。
それでいいんじゃない？

455 ：Name_Not_Found：04/06/29 22:20 ID:???

でも自分の意見を通したいために多数派に見せようとしているのはね……。

456 ：Name_Not_Found：04/06/29 22:34 ID:???

俺はここを見ているが一度も意見に染まらずにいる…

457 ：Name_Not_Found：04/06/29 22:48 ID:???

俺も参考程度だよ

458 ：Name_Not_Found：04/06/29 22:49 ID:???

なんか最近変なのが増えたような。
どっかで紹介されたのかな？

459 ：Name_Not_Found：04/06/29 23:24 ID:???

段落や引用の議論を見て、それでも自分の持論を変えられない
自分を頑固者だと思った。猛省する。

460 ：Name_Not_Found：04/06/29 23:26 ID:???

多数派だからって調子こいてんじゃねぇ。そして俺もまた。

461 ：Name_Not_Found：04/06/29 23:39 ID:???

<strong><a>料金一覧表</a></strong>
<a><strong>料金一覧表</strong></a>

↑はどっちがいいの？一応言葉じゃなくリンク自体を強調したいから前者なのかと思うが、
そもそも<a>を<strong>で括る行為はリンクの強調として解釈されるのかな？

見た目にはどちらでもいいんだけどね。意見を聞かせて。

462 ：Name_Not_Found：04/06/29 23:41 ID:???

>>460
一番の多数派はテブル大陸の住人だろ

ストリクタンは何度となく奴らに弾圧されてきたからな。踏絵だよ。

463 ：Name_Not_Found：04/06/29 23:45 ID:???

>>461
どちらでもいいと言ったら君はどう思うだろう…

464 ：Name_Not_Found：04/06/30 00:34 ID:???

>>461
正直Strictと言えども、そこまで気にするほど厳格な統一解釈な
ないかと思われる。

ので、自分の好きな方でドゾ。

465 ：Name_Not_Found：04/06/30 03:01 ID:???

「リンク」を含めて強調したいなら前者を、
「文字列」のみを強調したいなら後者を。

466 ：Name_Not_Found：04/06/30 03:25 ID:???

Strict+CSSで初めて作ってるんだけど、表を作る時に全てのセルにクラス与えるのが面倒。
<colgroup>ってe3n6以上なら対応してるみたいだけど<colgroup>にクラス与えてやるのもあり？

構造的にはありなきがするけど

467 ：Name_Not_Found：04/06/30 04:01 ID:???

<a target="_blank">って使えないみたいだけどどうすればいいの？
JSで別窓開けたらblankが禁止の意味がないよね？

でも注文ページでどうしても別窓にしなきゃいけないんだけど、W3Cは一体どういうつもり？
postで作ったページは行ったり来たりが普通にはできないんだよね・・・・・
そのページに送料一覧表へのリンクを貼りたい。別窓であれば問題ない。
でもStrictじゃない・・・・

マジでW3Cはアホ？Strictで作れないページが存在するって一体なんなのよ！

まあpostで作らずデータベースつなげてセッションでうまくやれば別窓にしなくてもいいけど
プログラム丸々書きなおすなんて馬鹿らしい。

誰か助けて

468 ：Name_Not_Found：04/06/30 04:32 ID:???

>>466
ありでしょう。しかしこのスレ的には「まずマークアップ」
スタイルのために変な論理構造にならないように。という感じかな

>>467
ウィンドウというものがあるとは限らない。

469 ：467：04/06/30 06:56 ID:???

>>468
あるでしょ？別にタブブラウザでも。

～どういう意味だ？

470 ：Name_Not_Found：04/06/30 07:33 ID:???

>>469
ハイハイ。
お猿さんは帰ってくださいネ♪

471 ：Name_Not_Found：04/06/30 07:34 ID:???

>>469
例えば携帯電話のブラウザとか、DOSみたいなテキストベースのブラウザも
存在する。

今じゃマルチタスクのOSが一般的だけど、シングルタスクでそもそも
ウィンドウの概念が存在しないOSは存在するし、そう言うOSでも
Webは見るかも知れない。

472 ：467：04/06/30 08:30 ID:???

>>470
なんだこいつ？

>>471
ありがと。理解した。

473 ：Name_Not_Found：04/06/30 09:52 ID:???

ほんと変なのが増えた気がする。

474 ：Name_Not_Found：04/06/30 10:04 ID:???

>>467

＞マジでW3Cはアホ？
お前にアホと言われるほどｱﾌｫな組織だったら既に存在すらしていない。

475 ：Name_Not_Found：04/06/30 10:43 ID:???

バカっていうやつがバカなんだ、の好例

476 ：Name_Not_Found：04/06/30 11:15 ID:???

>>475
ﾜﾗﾀ

477 ：Name_Not_Found：04/06/30 13:16 ID:???

>>475
漏れもﾜﾛﾀｗ

478 ：Name_Not_Found：04/06/30 13:22 ID:???

あからさまな釣りだと思うんだがマジなのか？

479 ：Name_Not_Found：04/06/30 14:35 ID:???

最近strictに興味をもった初心者がこのスレに来る事多いみたいだし

そもそも質問スレと勘違いしてる奴も多いみたいだし

釣りっつーか、単に「Strictつかえねー！」と思ってこのスレ住民に
怒りをぶつけてみたら納得出来ちゃった、みたいな、そんな感じかと。

480 ：Name_Not_Found：04/06/30 15:27 ID:???

>464とか>465みたいな存在が困る

481 ：Name_Not_Found：04/06/30 15:36 ID:???

>>480
それは両者が誤りで厳密な正解があるということかな？

482 ：Name_Not_Found：04/06/30 15:52 ID:???

>>478 とかも煩わしいな。

483 ：Name_Not_Found：04/06/30 16:06 ID:???

まぁ>>480もどうとでも取れる書き込みなわけだが。

484 ：Name_Not_Found：04/06/30 17:01 ID:???

>>464が何を考えてるのか分からない。
見た目で考えても、例えばCSSでborderとか使ってたら変わってくるでしょ。

>>467
送料表がどんなものかは知らないけど、いちいち書き出してはいかが。
お客さんに「いちいちこの表出てきてうざいよ」って思われそうなら
クライアントサイドスクリプトで表示/非表示を切り替えるのも有効かも知れない。
インタフェイスに気をつければの話だけど。

ちなみに>>467のことをバカって言った>>475もバカ。
――っていう突っ込みを>>475は期待してたんだよね？

485 ：464：04/06/30 17:06 ID:???

元の質問が
＞一応言葉じゃなくリンク自体を強調したいから前者なのかと思うが、
＞そもそも<a>を<strong>で括る行為はリンクの強調として解釈されるのかな？
と、セレクタとしてではなく、記述順による解釈の違いに関する物だったので、

「どっちでも解釈に大差はない」と答えた。

486 ：Name_Not_Found：04/06/30 19:15 ID:???

…本当に変なのが増えたな

487 ：Name_Not_Found：04/06/30 19:19 ID:???

荒らしとか、変なのとか、兎に角、すれ違いでその話題を長引かせたくなかったら
スルーでお願いします。

誰も相手にされなければ自演も飽きるので。

488 ：Name_Not_Found：04/06/30 19:26 ID:???

んで、>464とか>465ってどうなの？
正しい解釈を教えてくれ。

489 ：Name_Not_Found：04/06/30 19:52 ID:???

>>486
その変なのをちゃんとしたやつに変えるのがこのスレの役目でもあるな。

490 ：Name_Not_Found：04/06/30 20:00 ID:???

>>489
スルーでお願いします。

491 ：Name_Not_Found：04/06/30 21:03 ID:???

<a>の流れで思ったけど、例えばさ、ページ内リンクを作る時に
<h1>ホームページ作成講座</h1>
<ol>
<li><a href="#1">HTMLとは</a></li>
<li><a href="#2">CSSとは</a></li>
</ol>
<h2><a name="1">HTMLとは</a></h2>
<p>～</p>
<h2><a name="2">CSSとは</a></h2>
<p>～</p>
<--\tend-->
↑こうゆう場合って本来タイトル自体をリンクにしたいわけだよね？別に文字に意味があるわけじゃないから。
だから本当は
<a name="1"><h2>HTMLとは</h2></a>
の方が論理的には正しいと思うんだけど、HTMLでは<a>はブロックを内包できない。

おかしくないか？<a>がブロックを内包できないっていう今のHTMLは

492 ：Name_Not_Found：04/06/30 21:08 ID:???

>>491
論理的にマークアップとかにこだわるやつは馬鹿。HTMLはそんなものじゃない。
黙って仕様に従え。仕様に従う事がValidなんだよ。別に理由は考えないでも
仕様とおりにすれば、それが一番寿命が長く、色々なものに対応できるHTMLになるんだよ。

493 ：489：04/06/30 21:09 ID:???

>>490
俺のことをみんなにスルーしろってこと？

それとも俺に対して「変な奴はスルーしてね」ってうながしてるの？

494 ：Name_Not_Found：04/06/30 21:14 ID:???

>>491
<ol>
<li><a href="#html">HTMLとは</a></li>
<li><a href="#css">CSSとは</a></li>
</ol>
<h2 id="html">HTMLとは</h2>
<p>～</p>
<h2 id="css">CSSとは</h2>
<p>～</p>

495 ：Name_Not_Found：04/06/30 21:59 ID:???

validはDTDにしたがったものだけどなー。

まぁ、仕様に従ってれば、仕様に記述されたDTDも守って自動的に
Validにもなるけどなー。

言葉位知らないと恥書くぞー

496 ：Name_Not_Found：04/06/30 22:05 ID:???

>>491
a で内包する必要がない。
ブロックレベル要素からアンカー貼ることもないしな。

497 ：491：04/06/30 22:19 ID:???

>>494
うわ！？

IDが付いてる要素にはaで飛べるんだなんて知らなかった・・・・

これはどんなブラウザ（古いのとか）でも動作するの？

498 ：Name_Not_Found：04/06/30 22:22 ID:???

んなこた自分で調べろハゲが。ここはお前のための手取り足取りスレじゃねぇんだ。

499 ：Name_Not_Found：04/06/30 22:53 ID:???

>>497
>>1
>W3C 信者もそうじゃない人も投稿歓迎。でもHTMLの基礎知識は欲しいね。

500 ：491：04/06/30 22:59 ID:???

だれか知ってる人いないのかな。お願いします。

501 ：Name_Not_Found：04/06/30 23:01 ID:???

だから知ってるけどお前には教えない、つってんの。
ぐぐれば出てくるから回答待つ暇があったら検索しろ。

502 ：Name_Not_Found：04/06/30 23:03 ID:???

>>500
動作しないブラウザがあるとしてもシェア1%未満。
だいたいページ内アンカーはダメもと。

503 ：Name_Not_Found：04/06/30 23:10 ID:???

俺の普段使ってるブラウザ対応してねえや

504 ：Name_Not_Found：04/06/30 23:27 ID:???

煽り、荒らし、馬鹿はスルーでお願いします。

505 ：Name_Not_Found：04/06/30 23:35 ID:???

<h1>ちんこでかい</h1>
<div class="section">
　　<h2>まじで？</h2>
　　<p>まじなんです！</p>

　　<div class="subsection">
　　　　<h3>うこでた</h3>
　　　　<p>まじで？</p>
　　</div>
</div>

これってdiv厨？

506 ：Name_Not_Found：04/06/30 23:47 ID:???

>>505
前スレで議論されてたネタに近いな。許容範囲か。
個人的にはsectionとsubsectionを分けるのは好きじゃない。

507 ：Name_Not_Found：04/06/30 23:54 ID:???

>>481
>465な

508 ：Name_Not_Found：04/06/30 23:54 ID:???

The XHTML namespace may be used with other XML namespaces as per [XMLNS], although such documents are not strictly conforming XHTML 1.0 documents as defined above.

他のネームスペースの要素や属性含めたらXHTML 1.0 Strictとは呼べないんか。
他のネームスペースの要素や属性含めたいときはXHTMLのモジュール化を使えってことか。ちなみにXHTML1.1はモジュール化を前提としてるから仕様書には上のような記述はなかった。

DTD書くのめどいな。

509 ：Name_Not_Found：04/07/01 00:00 ID:???

<strong><em><b>ばかが増えた</b></em></strong>

510 ：Name_Not_Found：04/07/01 01:05 ID:???

<div><b>放置しても<i>放置しても</b>沸いてくる</i>んだよなぁ…<div>

511 ：Name_Not_Found：04/07/01 01:29 ID:???

放置できない奴も仲間（オレモナー）。徹底放置で。

512 ：491：04/07/01 04:20 ID:???

>>502
ありがと。1%未満ってことは少なくともIE4/N4以上はokなのね？

>>503
何使ってるの？

>>501
お前は軽く馬鹿だな。そんな長い文打つんなら、答えを言ったほうが早いだろ。
まあ答えに自信がないから言えないんだと思うけど。

>>510
馬鹿？

513 ：Name_Not_Found：04/07/01 06:35 ID:???

StrictHTMLと関係のない話題はスルーで。

514 ：Name_Not_Found：04/07/01 08:43 ID:???

>475

515 ：Name_Not_Found：04/07/01 12:56 ID:???

なんでこんな短期間で急に…

516 ：Name_Not_Found：04/07/01 16:44 ID:???

>>514
>>484

517 ：Name_Not_Found：04/07/01 16:50 ID:???

>>514-517
>>513

518 ：Name_Not_Found：04/07/01 17:43 ID:???

id、class名が長いのってよろしくないですか？

519 ：Name_Not_Found：04/07/01 18:10 ID:???

>>518
必要な長さなら問題ない。

まぁ、メンテナンス性やソースの可読性が損なわれない程度の範囲で。

520 ：Name_Not_Found：04/07/01 19:23 ID:???

> ID屬性及びNAME屬性、さらに對應するHREF屬性の値に使ふ文字を次の
> 40字 ABCDEFGHIJKLMNOPQRSTUVWXYZ.-_:0123456789 に限る
でなかったか

521 ：Name_Not_Found：04/07/01 21:01 ID:???

>>520
長さと種類になんの関係が？　釣りにしてもワケワカラン

522 ：Name_Not_Found：04/07/01 21:38 ID:???

変化球の釣りなんだろ。つまり、放置しとけ。

523 ：Name_Not_Found：04/07/01 21:47 ID:???

ときどき旧カナの人いるけど、どうして？
辞書引き引き書いてるの？

524 ：Name_Not_Found：04/07/01 21:52 ID:???

辞書でしょ。スレ違い。

525 ：Name_Not_Found：04/07/01 21:53 ID:???

ああ、IMEのね。

526 ：Name_Not_Found：04/07/01 21:54 ID:???

ま、ましゃか！
字種の数じゃなくて、文字数だと思ったのか。

>>523
どうでもいいことだけど、辞書に登録してあるんでしょ。
漏れも「らじお」って打って変換すると第一候補に

<input type="radio" name="" id="" value="">

ってでたりする。

527 ：Name_Not_Found：04/07/01 21:55 ID:???

旧かな使うことに気を取られて肝心の中身が空っぽである好例。

528 ：Name_Not_Found：04/07/01 21:59 ID:???

>>527 は input 空要素と掛けた高度な駄洒落

529 ：Name_Not_Found：04/07/01 22:18 ID:???

>>528
高度だけど駄なのか

530 ：Name_Not_Found：04/07/01 23:17 ID:???

divのclass名とかid名をつけるのに参考になるようなｲｲサイトないですか？

531 ：Name_Not_Found：04/07/01 23:20 ID:???

http://dictionary.goo.ne.jp/

532 ：Name_Not_Found：04/07/01 23:24 ID:???

<body>
<div class="container">
　<div class="main">
　なんてろ
　</div>

　<div class="menu">
　なんてろ
　</div>
</div>
</body>

こういうのありですか？

533 ：Name_Not_Found：04/07/01 23:25 ID:???

取りあえずbody全体を括るdivに意味は感じられないな

534 ：Name_Not_Found：04/07/01 23:40 ID:???

ページの一番下に
<a href="home.html">[ home ]</a>
<hr class=keisen>
<div id=footer>hogehoge</div>
</body></html>

こういうのやるときて<a>～</a>の部分を何のブロック要素でマークアップすればいい？
とりあえずいきなり<p>ってやるとその前にある見だしに属されちゃうから駄目。
でも見栄え的には罫線の上に乗っかってる感じにしたい。

どうするべき？

535 ：Name_Not_Found：04/07/01 23:43 ID:???

>>533
HTML的に意味はなくともCSSレイアウトをする上で必要になるときもある。
センターレイウアウトなんかは好例かな。

536 ：Name_Not_Found：04/07/01 23:45 ID:???

>>535
そういう発言は荒れるから止めてくれ。

537 ：Name_Not_Found：04/07/01 23:45 ID:???

bodyにclassを与えればいいんじゃ？

538 ：Name_Not_Found：04/07/01 23:47 ID:???

荒れるこた無いでしょ。「div厨」と一言で終わり。

539 ：Name_Not_Found：04/07/01 23:48 ID:???

>>534
<h2 class="hidden">ナビゲーション</h2>
<p><a href="home.html">Home</a></p>
としてhiddenはdisplayをnoneにするという手がある。

540 ：Name_Not_Found：04/07/01 23:50 ID:???

構造的に意味があるなら、良い。100このstrictな意味のあるdivなら
div房じゃない。

構造的に意味がないなら、駄目。１こdivでも駄目。

divの数じゃない。

541 ：Name_Not_Found：04/07/01 23:58 ID:???

strictな意味のあるの定義って決まってないんですか？
英和辞典で意味が出てくる名前なら付けても大丈夫ですか？

542 ：Name_Not_Found：04/07/02 00:05 ID:???

>>541
何でもいい。自分でメンテナンスできるなら。
重要なのは名前ではなく意味によって分類されることだ。

543 ：Name_Not_Found：04/07/02 00:06 ID:???

>>541
idとclassに関してはない。
というか、具体的に意味がある物は既に要素になってる。
link要素のrelとかrevのキィワードなら定義されているので仕様参照の事。

544 ：Name_Not_Found：04/07/02 00:24 ID:???

>>541
ただrel, revは仕様書にないのも沢山使われてるから要注意。
http://www5d.biglobe.ne.jp/~quia/tech/html/linktype.html
を参照のこと。

545 ：Name_Not_Found：04/07/02 00:46 ID:???

>>523
ttp://members.jcom.home.ne.jp/w3c/
を熟讀しませう。

546 ：Name_Not_Found：04/07/02 00:53 ID:???

>>539
class="hidden"を id="nav"に。

547 ：Name_Not_Found：04/07/02 01:31 ID:???

ウェブログとかで左右に段組するときに
メインの日記みたいなのが出る方の<div>のクラス名、ID名は何がいいでしょうか？
あとカレンダーとか出るほうの名前は何がいいでしょうか？
mainなんとか、leftなんとか、sideなんとかはよくないと思うのですが、
他に思いつきません。

548 ：Name_Not_Found：04/07/02 01:32 ID:???

>>547
ウェブサイト・HP制作初心者が質問するスレ vol.95
http://pc5.2ch.net/test/read.cgi/hp/1087865807/

549 ：Name_Not_Found：04/07/02 01:44 ID:???

>>547
main, subというのは構造だから良い。
leftは視覚的のなので良くない。
sideは微妙。視覚的とも取れるし論理的とも取れる。

550 ：534：04/07/02 02:04 ID:???

>>539
それおかしくないか？
消すなら視覚ユーザには構造をインペイすることになるだろ。

551 ：Name_Not_Found：04/07/02 02:23 ID:???

>>550
隠蔽することにはならないでしょ。
視覚的にはその前にある見出しに属さないとわかるんでしょう？
だから「表示しない」だけであって、隠している訳じゃない。

class="hidden"がおかしいというのなら分かる。
それなら>>546の言うようにすればいい。

552 ：Name_Not_Found：04/07/02 02:25 ID:???

>>550
視覚的なブラウザ上でなら人間は見て判断できる。
いや、視覚的でなくとも普通に読んでるなら人間なら判断できるかもしれない。
でもHTMLを処理するプログラムは分らないかもしれない。

構造化というのは機械のためにするのです。
というのはちょっと極論で、客観的に誰が見ても明かなようにするのが構造化。
一方それから特定の環境、特定の利用者(いろんな人間、いろんなプログラム)に合わせて冗長な情報を隠して、その環境に必要な情報を加え、情報を変更して最適化するのがスタイル作り。

553 ： ◆FoxMX6a/hk ：04/07/02 02:26 ID:???

>>550
[Home] へのリンクが footer の一部でない理由は何？
本文の中に含まれるべき理由があるならわからんでもないが。

554 ：Name_Not_Found：04/07/02 04:17 ID:???

>>546や他にも色々なところで、id属性値には小文字が使われてますが、
本来は大文字を推奨されてるんですよね？

Another lintでそういうエラーがでました。
<a href="#foo">hjkl;</a>
<h2 id="foo">ghjk</h2>
ではなく
<a href="#FOO">hjkl;</a>
<h2 id="FOO">ghjk</h2>
としなさいっていわれました。

でもなんでこのスレではidの属性値に小文字を使ってる人だらけなんですか？
<a>が絡まないidだからですか？でもaが絡むかどうかは後々変わってくる場合も
あるので、大文字に統一するべきだと思いますが。

どうしてでしょいうか？

555 ：Name_Not_Found：04/07/02 04:25 ID:???

漏れXHTML1.1だが一回もそういうエラー出たこと無いぞ
バージョンに絡む問題じゃないのか？

556 ：554：04/07/02 05:31 ID:???

http://openlab.ring.gr.jp/k16/htmllint/explain.html#lower-id
http://openlab.ring.gr.jp/k16/htmllint/explain.html#id-link
です。

私の勘違いですか？

557 ：554：04/07/02 05:38 ID:???

ageてしまいました。

<a name>の形式はいずれなくなるらしいので、できるだけ使わないほうがいいと思ってますが
HTML4.01の仕様書邦訳ではidの値に小文字を使うなとはありませんでした。
例文も小文字でした。

一体どっちなのでしょうか？

558 ：Name_Not_Found：04/07/02 05:55 ID:???

ttp://www.satoshii.org/markup/notes/2003/11#date23
ttp://diary.petronius.biz/2003_11b.html#H15Y28A
ん、これかな。冬に挙がった議論で、それによってlintの仕様がそのように。

559 ：Name_Not_Found：04/07/02 06:20 ID:???

どうでもいいけどなぜそんなに詰問口調なんだ(w
実は俺も>>520読んで「あれ？小文字もOKじゃなかったっけ？」
と思ってちょっと調べてみたところだったり。

大文字に変換されるのはSGMLの要求であって、HTML4.01やISO-HTMLは
SGML準拠なので影響を受ける。XHTML内で閉じている場合には発生しない。
小文字で書いてもHTML的に違反というわけではないけど、
id="foo"の部分を指す識別子は大文字であるべき(#FOO)なので
idも大文字に揃えた方がわかりやすいため「推奨」されている。
ただし、現状でほとんどのUAは大文字小文字を区別していない。

ということらしい。

http://www.satoshii.org/markup/notes/2003/11 の11/23以降とか
http://kazmacky.cool.ne.jp/kinkyo/2003e.html の11/29以降あたりが詳しかった。

560 ：559：04/07/02 06:21 ID:???

リロードさぼったらかぶった。スマソ。

561 ：554：04/07/02 12:13 ID:???

>>558-560
わかりました！
私はこうすることにしました。
<a href="#FOO">hjkl</a>
<h1 id="foo">hjkl</h1>

かなりすっきりしました！

562 ：Name_Not_Found：04/07/02 12:20 ID:???

最悪の結果にたどり着いたな。

563 ：554：04/07/02 15:47 ID:???

>>562
そうですか？x系に移行するときのことを考えるとこれが一番いいです。
<a name>の形式は完全に排除してるので、こんがらがるとこもありませんし。

どうせid="aaa"はhtmlならid="AAA"と解釈され、x系なら小文字のままなので、
<a href="#AAA">を小文字に変えれば済みますので。

564 ：Name_Not_Found：04/07/02 15:59 ID:???

>>563
> <a href="#AAA">を小文字に変えれば済みますので。
それはつまりURIが変わるということに意味するわけだが、それは解ってるな？

565 ：Name_Not_Found：04/07/02 16:05 ID:???

俺はid属性についての不変性は放置している。

566 ：Name_Not_Found：04/07/02 16:21 ID:???

コンテキストネゴシエーションとか使うなら同一内容の筈のソースの
IDが異なっているってのは具合悪そうだが、
単に「将来移行します」ってんならまぁいいかと。
勿論ID込みの場合URLが変わる事は認識しておくひつようはあるが。

所で、「そもそも」論としていっそ「今」XHTMLに移行してみてはどうだろうか、
と提案してみる。

567 ：Name_Not_Found：04/07/02 16:32 ID:???

クレーム対応マニュアル

XHTMLに以降汁 ⇒ XML宣言が出るから嫌だ ⇒
utf-8にしろ ⇒ utf-8は面倒、ファイルサイズデカくなる
⇒ お前のサイトを読むほうが面倒で、無ければリソースの節約になる

568 ：Name_Not_Found：04/07/02 17:25 ID:???

htaccess でコード指定しちゃえば Shift-JISとかでも使えますが何か。

(そして、utf-8面倒ってやつがhtaccessを自分で設定するのか、それ以前に
サーバ側がhtaccessの設定を認めているのか、と言う問題が新たに浮上)

569 ：554：04/07/02 17:41 ID:???

>>564
あぅ！；
どうしよう・・・・

１．IDは全て大文字で。
２．アンカー目的のIDは使わず<a name>形式で。

２で行きます。Xに変える時は<a>を消してIDを与えることで対応。が、一番いいかなと。
どうでしょう？

570 ：Name_Not_Found：04/07/02 17:54 ID:???

>>561
自分でリンクを張るならちゃんと#FOOに張れるだろうけど、
事情を知らない第三者は#fooに張ってしまう可能性が高い。
公開しないなら良いけども。
だいたい、href属性とid属性で値が一致していないとスクリプトとかで少し面倒な思いをすることになるのでわ。

「XHTMLでは属性値に大文字が使えない」っていうのは嘘なんだけど、そのへん分かってる？
なんか読んでると思いっきり勘違いしてるように見えるんだけど。

571 ：570：04/07/02 17:58 ID:???

ごめん、リロードして無かった。
ついでに。

>>569
それはURIが変わる問題への対策にはなってないはず。

572 ：569：04/07/02 18:36 ID:???

>>570-571
IDは小文字にしたいのです；大文字は嫌いなので・・・・・

<a name>の形式にすればリンクも小文字で良いので他人が貼る場合にも混乱しなくてよいかと
思います。IDにリンクする行為をHTML4.01で書いている間は撤廃しますので。

なのでXに移行して、idをリンクに使う時は今度は<a name>を撤廃して、もちろんidは小文字で
やりますので、これで問題ないかと。ですよね？

573 ：Name_Not_Found：04/07/02 19:25 ID:???

おまいら、accesskey属性とtabindex属性ってちゃんとやってる？
俺のサイト一応HTML4.01でanother lintにかけると100点ではあるけど、
↑の二つは全くやってない。

っていうかイマイチやる意味が・・・・・・accesskeyもtabindexも決めておいても
わからなくない？閲覧者からするとさ。サイト毎に違うんだし・・・どうなのストリクタン

574 ：Name_Not_Found：04/07/02 19:32 ID:???

>>573
みんな、accesskeyってどうしてる？　tabindexは？
http://pc.2ch.net/hp/kako/1006/10062/1006224399.html

575 ：Name_Not_Found：04/07/02 19:37 ID:???

実にすばらしいスレだったね。そこ。

576 ：Name_Not_Found：04/07/02 19:40 ID:???

>>573
lintがチェックするのはWCAG1.0で勧告されてるからでしょ。
マウスでもキーボードでもアクセスしやすければ
アクセシビリティが高まるということだそうだ。
つうことでアクセシビリティスレ向きの話だと思うがna-。

577 ：Name_Not_Found：04/07/02 19:40 ID:???

うん、是非573にも読んで貰いたい。

578 ：Name_Not_Found：04/07/02 19:42 ID:???

自分もそこに感銘を受けてaccesskey設定するようにしたよ

579 ：Name_Not_Found：04/07/02 20:15 ID:???

タイトルに
「-」
を入れるのあり？

<title>$nbsp;すばらしいスレ -２ちゃんねる</title>

とか良く見かけるけど、なんやねん「-」って！物理マークアップみたいなものじゃないのか？
よくわからないけどSEO的には問題ないのかな？

580 ：573：04/07/02 20:17 ID:???

>>578
何番くらいに感銘を受けたの？
ゆっくり全部読むけど、とりあえずその場所が気になる！大体でおちえてよ！

581 ：578：04/07/02 20:34 ID:???

しかしだいぶ前だからね。読んだの。
具体的にどの辺りといわず、全般に渡って出てくる1の物腰というか、
人柄に惹かれる。accesskey/tabindexに対する姿勢とか。

こう指定すれば効率がいい、こうあるべきだ、という議論ではなく、
いかにそうした指定により、多様な層の閲覧者に利を供することが
できるか、といった具合にね。
いがみ合いにならず、大勢の意見をうまくまとめる中核になってる。

とてもまじめに取り組み、そして考えていて、スレの住人の多くが
惹かれてゆくのが見ていて読み取れる。
最後の方はいなくなっちゃうけどやっぱり尊敬できるよ。

って、過去ログこれだけだっけ？
最後の方はかなり寂れてたような記憶があるのだが。

582 ：Name_Not_Found：04/07/02 20:35 ID:???

>>579
タイトルなんだから好きにしたらいいと思うが。

583 ：Name_Not_Found：04/07/02 20:54 ID:???

個人的にはHTML内にaccesskeyを入れるのはどうもおかしい気がする。
キーがないUAはどうするんだとか、そもそもユーザのアクションに対する
リアクションをHTML内に書くべきなのだろうか。

CSSか他のレイヤーで実装すべきなんじゃないかなぁ。

584 ：Name_Not_Found：04/07/02 20:55 ID:???

>キーがないUA

キーがないプラットフォーム、の間違い？

585 ：Name_Not_Found：04/07/02 20:55 ID:???

http://roblog.s60.xrea.com/
見てください。お願いします。

586 ：585：04/07/02 20:56 ID:???

見てくださいって宣伝じゃなくてちゃんと書けてるか見てくださいってことです。

587 ：Name_Not_Found：04/07/02 21:01 ID:???

>>585
はぁ？行ったけどお前のサイトなんてなかったぞ？っていうか見つけたかたすらわからん。
なんじゃ！

588 ：585：04/07/02 21:02 ID:???

>>587
なんだって！

589 ：Name_Not_Found：04/07/02 21:02 ID:???

>>585
W3C信者にサイトを正しい記述に直して貰うスレ3
http://pc5.2ch.net/test/read.cgi/hp/1061741473/

590 ：585：04/07/02 21:06 ID:???

>>589
そこ行ったら
■■ HP評価スレッド vol.37 ■■
http://pc5.2ch.net/test/read.cgi/hp/1088237268/
に誘導されたんですが、デザインができてないんで↑はダメだと思ったわけですよ。
正しいHTML書けてますかっていうのを見てくださいよ。お願いしますよ。

591 ：Name_Not_Found：04/07/02 21:07 ID:???

>>588
なんだって！じゃねんだよ！いいからお前のサイトのソースの見方を教えろや！

そのサイトの使い方がわからんのじゃボケ！

592 ：Name_Not_Found：04/07/02 21:11 ID:???

>>590
誘導したのは俺だが、また勝手にこのスレで「評価してください」かよ。
評価スレのテンプレ見て評価基準に達してないと判断したのは賢明だが、
しっかり作り直してから再度依頼しようとは思わなかったのかね。

ついでだから言っとくが、MT3.0はまだクローズドテストの段階のはずだが。

593 ：585：04/07/02 21:11 ID:???

クリック→右クリック→ソースを表示です

594 ：585：04/07/02 21:12 ID:???

>>592
だからここでひっそり見てもらってるんです。

595 ：Name_Not_Found：04/07/02 21:13 ID:???

>>593
？
もしかしてそのサイト自体がおまいが書いたのか？
どうやらそうっぽいな。あほらし。

596 ：Name_Not_Found：04/07/02 21:16 ID:???

>>564
fragment idってURIの一部ではないんじゃ？

4.1. Fragment Identifier
http://www.ietf.org/rfc/rfc2396

597 ：585：04/07/02 21:18 ID:???

内容が必要なんですか。
どうせ書いてもくだらない内容ですよ。
HTMLの評価には関係ないでしょうよ。
デザインはHTMLしっかり書けばいいって言うから
しっかりかけてるか聞いたんですよ。
もういいですよ。ありがとうございました。
あぁ僕はなんてアホな人間なんだろう。
僕の人生お先真っ暗だ。

598 ：Name_Not_Found：04/07/02 21:27 ID:???

書いてもくだらない内容、すら書いてないページを読まされる身にもなってみろ。

599 ：Name_Not_Found：04/07/02 21:40 ID:???

なんかすごい方が降臨されてるな。
ここ最近のスレの流れ見て中級者スレが必要だと思った。
初心者以上このスレ住人未満くらいが対象の。
おそらく今までカスイケスレがその役割を果たしていたんだろうが…。

600 ：Name_Not_Found：04/07/02 21:41 ID:???

>>599
Web製作板【中級者スレッド】
http://pc5.2ch.net/test/read.cgi/hp/1026891247/

601 ：Name_Not_Found：04/07/02 21:41 ID:???

>>599
カスイケスレは関係なし。

602 ：Name_Not_Found：04/07/02 21:48 ID:???

やはり最近の変なのはカスイケから来てたのか。

603 ：Name_Not_Found：04/07/02 21:51 ID:???

内容がないサイトは禁止とか書くか？

604 ：Name_Not_Found：04/07/02 21:51 ID:???

>>603
サイト？何のこと？

605 ：Name_Not_Found：04/07/02 21:55 ID:???

そもそも評価スレじゃない。

606 ：Name_Not_Found：04/07/02 22:02 ID:???

>>596
全く仰る通り、RFC2396が定めるURIは部分識別子を含まない。
だが、では各種仕様並びにDTDに記され
大抵RFC2396参照としてあるだけの %URI; が
URI参照ではなくURIなのかというと、けしてそうではないわけで。

ともあれ、>>564は適切な表現ではなかった。指摘ありがとう。

607 ：Name_Not_Found：04/07/02 22:25 ID:???

>>606
全くどうでも良いけれどもノリで突っ込んでみると、「けして」も適切な表現ではない。

>>572
idを書くのであれば、書いた以上、自分は使わなくても他人がリンクなり何なりに使う可能性が生じる。
大文字が嫌だからと言って小文字で書いていると他人がまずいリンクを張ってしまうかもしれないし、
自分自身もメンテナンスしにくくなる虞がある。
じゃあそもそもidを書かなければ良いかというとそうでもなく、
スタイルシートやスクリプトの応用を考えればidはつけておいたほうが得だと思う。
ということでidをつけると――以下無限ループ。
現実には(今のところは)UAのいい加減さ故に何とかなるだろうけど、
そんなこと言ったらそもそも全部小文字idで行けば良いんじゃないか、っていう。

ばっさり言うと、Strict路線ならこの二択。
　1. HTML 4.01 で大文字 id を我慢する
　2. XHTML に移行して小文字 id を使う

そもそも、name属性だといろいろ問題が生じる。リンクはジャンプじゃないとか。
まあそういう話なんだけど、説明するのが面倒になってきたらパス。
知りたくなったら>>611あたりにでも聞いてみてください。

608 ：572：04/07/02 22:38 ID:???

>>607
IDは使いますがアンカー目的では使わないのでHTML4.01でも小文字でやります。
どうせ大文字にしたところで、他人が大文字のアンカーを振る確証はないので。

とりあえずアンカは全て<a name>でいくので問題はないかと。

609 ：Name_Not_Found：04/07/02 22:41 ID:???

610 ：Name_Not_Found：04/07/02 22:43 ID:???

とりあえず落ち着いて入力した方がいいと思う。

611 ：Name_Not_Found：04/07/02 22:48 ID:???

dがどうにかなってるのか?

612 ：Name_Not_Found：04/07/02 23:01 ID:???

lang属性は子要素に伝搬しまっせ

613 ：Name_Not_Found：04/07/03 01:19 ID:???

>>609
html 要素に lang="ja" を付けてるなら要らない。
html 要素に付けた lang と異なるなら付けなきゃならない。
meta が複数あるかどうかは関係ない。

614 ：Name_Not_Found：04/07/03 02:03 ID:???

>>608
> IDは使いますがアンカー目的では使わないのでHTML4.01でも小文字でやります。
「アンカー目的では使わない」って、「HTMLは私用だ」って思ってるんならそもそもこのスレにｸﾝﾅよな。

615 ：609：04/07/03 04:03 ID:???

>>611
するどい！dがおかしかった。再起動したら直った。

丁寧なせつめイありがとう。理解した、

616 ：Name_Not_Found：04/07/03 04:25 ID:???

>>615
こんどiがいかれてないかい？

617 ：Name_Not_Found：04/07/03 04:46 ID:???

句点、読点もアレな感じだ。

618 ：Name_Not_Found：04/07/03 05:37 ID:???

なんか上でidとアンカーの話があったが
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/links.html#h-12.1.1
HTML4.01の仕様書では小文字だ。アンカーも小文字だ。idももちろん小文字だ。

仕様書が間違ってるとでも言うのかね？まあ邦訳だけど；

要は気にせず小文字で行けと。lintで100点なんて必要ないと。仕様書とおりにしていれば
そんな大した問題は起こらない。

619 ：Name_Not_Found：04/07/03 06:18 ID:???

リンク要素の使い方を練習してるんだけど例えば
top/通信販売/店舗沿革
みたいなページでtopに書く場合
<link rel="start" href=topのurl>
<link rel="chapter" href通信販売>
<link rel="chapter" href沿革>
でよくあるお買い物ガイド的なものはどこから見ても
<link rel="help" href=お買い物ガイド>
でok？

それで通信販売ページにいくと
<link rel="start" href=topのurl>
<link rel="chapter" href=商品１のurl>
<link rel="chapter" href=商品2のurl>
それか
<link rel=section href商品１のurl>
のどっちだろ？

っていうかrelって今表示されてる文書からの相対的な話だからページ毎に同じページへの
linkのrelの値が変わるから難しいね。

620 ：Name_Not_Found：04/07/03 06:27 ID:???

>>619
Chapter
文書群の中の章である文書を指す。
Section
文書群の中の節である文書を指す。
Subsection
文書群の中の小節である文書を指す。

仕様書邦訳から引っ張ってきたものだけど、「文書群」って言ってるから、サイト全体に対する位置で
いいんじゃないか？
だから
index - 通信販売 - 沿革
　　　　　|
　　　　　-商品１
　　　　　|
　　　　　-商品２
みたいに階層で考えてやれば？だから商品１なんかはsectionでいいんじゃない？
お買い物ガイドなんかはhelpでもAppendixでもありえる気がするけどな。

621 ：Name_Not_Found：04/07/03 06:35 ID:???

>>619
TOPページに<link rel="start" href=topのurl>を書く意味ないんじゃない？

622 ：619：04/07/03 06:41 ID:???

>>620
え～、でもrelの意味がおかしくならないそれって。

>>621
色々サイト見てると結構やってるとこ多いから一応やっておいてもマイナスにはならないかなと思った。

それにしてもリンク要素の使い方は難しいね。誰かバチコンマニュアルとかだしてくれないかな。
既存の普通のサイトを例にして、このサイトの場合は本来こうやってlink要素を使うのが正しいです。みたいな。
relの値がムずいんだよ・・・

623 ：Name_Not_Found：04/07/03 06:46 ID:???

きちんと実装してるＵＡが中々ないから
実際に使ってみないことにはわからないよね。

624 ：619：04/07/03 07:34 ID:???

>>623
俺としては検索ロボを助ける目的のみなんだけどね。

625 ：Name_Not_Found：04/07/03 08:08 ID:???

>>624
俺もlink要素は悩んだ。HTMLの仕様書ってまるでHTMLが論文の発表にでも使うのが主な感じで
書かれてるから、いまいちわかりづらいんだよな。

っていうかHTMLってページ毎に独立した構造なわけだから、
relの索引とかって意味不明だよな。なんで自分以外の文書が自分の中身の索引や目次を持ってるんだっっていう矛盾。
索引や目次はちゃんと自分で持っとけといいたいんだが、そこらへんがはっきりしないから俺は結局link要素は
ガイブファイルとか印刷用とかでしか使ってないね。

とりあえず
<link rel="index">
<link rel="contents">
<link rel="chapter">
<link rel="section">
<link rel="subsection">
<link rel="appendix">
辺りはHTMLの基本から考えておかしいと思うが・・・・まるで<h1>はサイト内で一つで良いみたいな話になりかねない。

626 ：619：04/07/03 08:17 ID:???

>>625
relのnext,prev,startはいいんだよね？
本の1作目、2作目とかで考えておかしくなかったらいいのかな？
htmlのそれぞれのページが一つづつの作品みたいな。
でもそれだどやっぱり、索引ってなんだろうね？

1作目はそれ以降の本についても説明してるとなると、これは同じシリーズではなくて
ただの宣伝文書だよね。そうなると他のページがその索引的なページに対してstartを
指定するのはおかしいかな？
「踊る～１」
「踊る～２」
があってそれの索引はコマーシャル？みたいな感じで「踊る～１」が
<link rel="start" href="索引を持つコマーシャルへのurl">
ってのはおかしいよね。

なんかよくわからなくなってきた；

627 ：Name_Not_Found：04/07/03 08:18 ID:???

仕様書に翻訳なんてあるんですか？良かったら教えて下さい。今まで英語だから読みませんでしたが、邦訳があるなら読んでみたいです。

628 ：Name_Not_Found：04/07/03 08:23 ID:???

>>625
激しく勘違いを誘う発言だな。

>>619
とりあえずカタログ本とかで考えてみたらどうだ？

629 ：Name_Not_Found：04/07/03 08:31 ID:???

まあそもそも仕様書にある
>Chapter
>文書群の中の章である文書を指す。
の文書群て何を指してるかによるな。

HTMLの場合はページ１とページ２は内容に共通性、繋がりが合っても別のページというか
それぞれ独立した構造なわけだろ。それが基本なのに「文書群」ってなんなんだと。

例えば論文のページ１とページ２。それをHTMLに起こしたときのページ１とページ２は
全く立場が違うものになってくるんだよな。

論文では
<h1>イカにも利き腕あり</h1>
それに関する文章

↑みたいなのが２ページに渡っているとして、それをHTMLにしてページをわけると
<h1>イカにも利き腕あり１</h1>
と
<h1>イカにも利き腕あり２</h1>
に分かれて、継続性はあるが別の文書になるんだよな。

まずい収拾がつかん・・・まあ要は文書群ってのは（ｒｙ

630 ：Name_Not_Found：04/07/03 08:32 ID:???

>>629
文書群じゃなくて作品群またはシリーズとでも言えってか？

631 ：619：04/07/03 08:34 ID:???

なんかよくわかんないけど、ここの人でも<link>に関しては解釈がまとまってないのかな？

632 ：Name_Not_Found：04/07/03 09:47 ID:???

>>629
> 論文では
> <h1>イカにも利き腕あり</h1>
> それに関する文章
>
> ↑みたいなのが２ページに渡っているとして、それをHTMLにしてページをわけると
> <h1>イカにも利き腕あり１</h1>
> と
> <h1>イカにも利き腕あり２</h1>
> に分かれて、継続性はあるが別の文書になるんだよな。

そうじゃなくてだな、
「イカについて」
　┣「イカにも利き腕あり」
　┗「イカの頭部と胴の境目」

「イカについて」で一つの文書郡、って考える方がピュアだろ。

633 ：Name_Not_Found：04/07/03 09:47 ID:???

>>631
違うよ。今はバカしかいないんだ。

634 ：Name_Not_Found：04/07/03 09:49 ID:???

>>630
そもそも作品群のトップは不動であると考えていいものかだな。
今みてるページが作品群のトップなのか、索引又はstartに設定したページが常に作品群の
トップであると考えていいのか。

635 ：Name_Not_Found：04/07/03 09:50 ID:???

>>634
トップ、ってのは、まとめた人が想定するもんじゃないの？

636 ：Name_Not_Found：04/07/03 09:51 ID:???

>>633
とりあえずおまいの意見を聞かせてくれ
無意味な煽りでないことを願う。

637 ：Name_Not_Found：04/07/03 09:55 ID:???

>>636
>>632が俺。
「別の文書だから独立してる」はわかる。が、総括が存在しない、と展開するのは思惟が浅すぎるとしか思えない。
こんなバカしかいないスレッドじゃあなかったぞ？　でも、指摘が無いってことはバカしかいないってことだ。

638 ：Name_Not_Found：04/07/03 09:57 ID:???

>>634
Index
当該文書の索引である文書を指す。
Start
文書群の中の最初の文書を指す。検索エンジンに対して、最初に読ませたいと著者が想定している文書がどれであるかを示すことができる。

indexは文書群の索引ではなくて、今見てる文書の索引である文書。
startは文書群の始まりを明示する。

なので
>そもそも作品群のトップは不動であると考えていいものかだな。
についてはstartに設定したページが常にトップであるといえると思う。

639 ：633：04/07/03 10:00 ID:???

>>632
別の文書になることには変わりない。文書を関連性、継続性のあるものを集めて文書群というんだろ？
特に間違ってるとは思わないけど？

640 ：619：04/07/03 10:04 ID:???

>>637
>>619の場合はどちらが正しいの？
sectionやchapterはその時に開いてる文書を起点にするんじゃなくて、文書群として
常にchapterとして指定されるURLは変わらないの？

641 ：Name_Not_Found：04/07/03 10:06 ID:???

>>639
>>629は「それぞれ独立した構造」だから「「文書群」ってなんなんだ」といってる。
独立はしてる。が、それを総括したものも存在し、それらを文書郡と呼ぶことも可能だ、と>>632で述べた。
そして、>>633は俺だ。

642 ：Name_Not_Found：04/07/03 10:09 ID:???

>>640
頭から考えるのが順当だろ。

第13章第4節は、
第13章を読んでる段階で、それに対する「第4章」にはならないだろ。

643 ：Name_Not_Found：04/07/03 10:14 ID:???

おまいら。ここらへんで俺の意見をば。
例えばシリーズ本なんかは階層構造ではないよな？
で、今言ってるページを分けたらシリーズが別のものになるんじゃないか？という意見については、
シリーズにするかHTML特有の階層構造にするかはおまい次第なわけだよ。

まあ簡単に言えばlink要素をうまく使って、階層構造をUAに対してはっきりさせろと。
それをやった瞬間からシリーズではなくて、サイトが一つの本みたいなものになる。

と思う。

644 ：633：04/07/03 10:14 ID:???

>>636
納得か不満かくらい書けよ。

645 ：Name_Not_Found：04/07/03 10:16 ID:???

>>643
つまり、「トップは（制作者の意図したレベルで）不動」かな。

646 ：645：04/07/03 10:19 ID:???

語弊があるな。

俺の書いたもの（トップ）
　┣乗り物について（トップ）
　┃┣馬について（トップ）
　┃┗車について（トップ）
　┣山について（トップ）
　┗ふぐの毒について（トップ）

でもいいわけだ、ってことが言いたかったんだが。

647 ：619：04/07/03 10:20 ID:???

>>643
なんかちょと理解できそうな気が・・・

>>642
疑問なのは、HTMLって自分が何章の何節かなんて知らないんじゃないかな？って事。
chapterをやる場合は結局サイトの全ページ<head>内にサイトの全構造を<link>で
書いてやらないといけないって事だよね？

<link>って今読んでるページから他のページへの関連性をつけるものだと思ってたけど、
どっちかというとサイト全体の構造化の為に使うものなの？

っていうか、おかしなこと次レスで例文かいてみる。

648 ：645：04/07/03 10:24 ID:???

>>647
> 疑問なのは、HTMLって自分が何章の何節かなんて知らないんじゃないかな？って事。
HTMLが知ってるかどうかじゃなくて、「読むもの」に「書いた人」が「教えるもの」なんじゃないのか？

> chapterをやる場合は結局サイトの全ページ<head>内にサイトの全構造を<link>で
> 書いてやらないといけないって事だよね？
そういうことだよ。

> <link>って今読んでるページから他のページへの関連性をつけるものだと思ってたけど、
> どっちかというとサイト全体の構造化の為に使うものなの？
いや、サイト全体であるかどうかは「制作者の意図」じゃないか？
制作者が、どういう関連を表したいか、というものを表すためにlink要素が存在するわけなんだし。

649 ：645：04/07/03 10:26 ID:???

あ、
＞サイトの全構造を
か。読み違えた。

全構造は表さなくていいだろ。
「第4節」にとっては、「元」が「第13章」であって、「次」が「第5節」、「前」が「第3節」ってだけだろ。

650 ：619：04/07/03 10:31 ID:???

index.html　-　shop.html　-　company.html
　　　　　　　　|
　　　　　　　　item1.html

[index.htmlのhead]
<link rel=chapter href=shop.html>
<link rel=chapter href=campny.html>
<link rel=section href=item1.html>

[item1.htmlのhead]
<link rel=start href=index.html>
<link rel=chapter href=shop.html>
<link rel=chapter href=company.html>

これで正しいってこと？なんかひっかかるんだけど・・・

nextとかは相対的で、section,chapterなんかは絶対的だってこと？

651 ：619：04/07/03 10:33 ID:???

>>648
>> chapterをやる場合は結局サイトの全ページ<head>内にサイトの全構造を<link>で
>> 書いてやらないといけないって事だよね？
>そういうことだよ。

HTMLのページは独立しても意味が通じないといけないんだから、全ページに書かなくても
っていうか書いたとしても他のページになんて書いてあるかは当該文書には知る由もなしでしょ？

652 ：633間違えた636だったついでに639：04/07/03 10:37 ID:???

>>644
なんとも言えないな。総括を何でするつもりなの？

653 ：Name_Not_Found：04/07/03 10:44 ID:???

>書いたとしても他のページになんて書いてあるかは当該文書には
>知る由もなしでしょ？

だから知らせるためにlink要素があるんでしょ？

654 ：619：04/07/03 10:48 ID:???

>>653
え？link要素をやったからってわざわざそのページに言ってソースを読んでくる。まで、
させるのが仕様書通りのブラウザってことになるの？

nextとかは先読みしてくれる場合もあるって事は知ってるけど、他のはソースを読んできたりしないでしょ？
いやするのか？ならあんまり使うと重くなるって事だよね。

655 ：653：04/07/03 10:52 ID:???

>え？link要素をやったからってわざわざそのページに言ってソースを読んでくる。
>まで、させるのが仕様書通りのブラウザってことになるの？

いまいち質問の意味がよくわからないけど、そうするのが便利だと思ったら
そういう動作をするブラウザを作ってもいいんじゃない？そのへんは自由。
示された情報に対してどう動作をするかまでは仕様は述べてないと思うけど。

656 ：619：04/07/03 11:09 ID:???

>>653
？
HTML4.01の仕様に完全準拠しているブラウザが存在していたとすれば、
link要素の先のソースを全部読みこむってことだよね？って質問だけど、
良く考えたらCSS外部ファイルとかもソースを全部よみこんでるんだよね；

text/htmlでも全部読みこむのが常識だったね。重さが気になってしょうがないけど、
あまりたくさんlinkで構造の為に読みこむとアホみたいにおもくなっちゃうよね？

657 ：653：04/07/03 11:20 ID:???

>656
link要素で指定された先を必ず読み込まなきゃならないという
決まりはHTML4.01の仕様内にはないように思えるけど……俺見落としてる？
同時に読み込んじゃった方が便利だとブラウザ作者が判断したなら
読み込むし、そうじゃないなら他の形で利用するのでは。
現状ではrel="stylesheet"以外はリンクの形で表示するブラウザが多いよね。

658 ：619：04/07/03 11:34 ID:???

>>657
>現状ではrel="stylesheet"以外はリンクの形で表示するブラウザが多いよね。
CSS以外は読みこむのが決まってるわけではないのか；でもそれならやっぱり他の文書に
どんなlink要素があるかは知る由もないと思うんだけど・・・勘違いかな？

そもそもHTMLは一つのファイルで一応完結しているのに文書群っていう概念をHTMLに使えるっていうが
イマイチ理解できないとこ。

検索ロボットとかのUAにlinkを使ってサイトを一つの文書群だと明示し、あるページを
その文書群の中の一つの章であると理解させるのは難しいきがするんだけどな。

あるページにrel=section href=hoge.htmlってのがあるときに、検索ロボはそのリンク先をあるページから
見た「節」であると捉えるような気がするというか、startを書いたとしても、そこを起点としてくれないん
じゃないかという悪寒。

俺のせいで話をループさせるのは問題なので、とりあえずlinkは階層構造を明示するものって
ことで片付けて、階層構造付きのリンクを表示してくれるブラウザもあるってことで・・・・

6時間近く付き合ってくれてありがとう！

659 ：Name_Not_Found：04/07/03 11:39 ID:???

ほんとにこのスレって最近別のものになってきたな。
良いか悪いかは別として、strictを広めるのに以前よりは役に立ってるぽいな。
議論スレというか、質問スレぽいけどな。まあ何はなくともstrict+CSSレイアウトが
広まれば俺の仕事も楽になりそうだから、文句はないけどな。

660 ：Name_Not_Found：04/07/03 12:01 ID:???

語尾が「な。」ばっかだなお前。

661 ：653：04/07/03 12:02 ID:???

>他の文書にどんなlink要素があるかは知る由もないと思うんだけど・・・

何も文書群全体をあらかじめ読み込む必要はないでしょ？
全体の構造を把握したいならrel="Contents"だけ読み込めば済むからね。
もちろん、Contentsに該当する文書にちゃんとlink要素を書かないと意味ないけど。

662 ：Name_Not_Found：04/07/03 12:14 ID:???

>>659
最近スレの利用者の変化について愚痴垂れてるのって同じ人？複数人が書いてるの？
どっちにしても何度も同じこと書かれてもうざいだけ。
嫌なら嫌で建設的な提案してくれ。strictスレッド分割の具体案とか。

663 ：Name_Not_Found：04/07/03 12:39 ID:???

なんかリンク要素を勘違いしてないか？
そもそもrel属性をつかって表せるのは、該当文書からの関連性であって、起点はあたりまえのごとく
該当文書であって、他のファイルではないのよ。

一応言っとくけど、該当文書＝今開いてるHTMLファイルのことね。

だから上で言ってるのは勘違いだらけ。

664 ：659：04/07/03 12:44 ID:???

>>662
俺は今のままでいいと思うがな。ただ、前からこのスレを見てる人間としてはつい
「変わったな」って言葉がでちゃうのよ。気を悪くしないでくれ。

>>663
なら
Chapter
文書群の中で章である文書を指す。
ってのはどうなるんだ？

665 ：Name_Not_Found：04/07/03 12:47 ID:???

「上で言ってる」だけじゃどれを指してるのかさっぱりわからん。

666 ：662：04/07/03 12:50 ID:???

>>664
いや思うのはいいし俺も変わったなと思うけど、何度も何度も
「変わったな」「変わったな」連呼されると嫌になっちゃうのよ。

667 ：Name_Not_Found：04/07/03 12:53 ID:???

619も663もまず仕様書読め。

668 ：Name_Not_Found：04/07/03 13:21 ID:???

>>666
お前もウザい。

669 ：ｽﾄﾘｸﾀｿ：04/07/03 14:25 ID:???

マターリ汁！

670 ：Name_Not_Found：04/07/03 14:47 ID:???

おまいら土曜の朝から熱いですね。乙。

671 ：Name_Not_Found：04/07/03 16:59 ID:???

会社の下に部があって、部の下に課があるとします。

部から見て課はなんでしょう。
当然「課」ですね。

672 ：Name_Not_Found：04/07/03 17:34 ID:???

日記は自分のサイトに書け

673 ：Name_Not_Found：04/07/03 17:54 ID:???

4.01 で、q に title ってあり？

674 ：Name_Not_Found：04/07/03 17:56 ID:???

あり。

675 ：Name_Not_Found：04/07/03 19:05 ID:???

index.htmlでサイトタイトルをh1にした場合は、それ以降の***.htmlでの一番の見出しはh2にするべきでしょうか？

676 ：Name_Not_Found：04/07/03 19:12 ID:???

>>675
それはやっちゃダメ。あくまで1つのHTML上での事と考えるのが正解かと。

677 ：Name_Not_Found：04/07/03 19:54 ID:???

それ以降の***.htmlでの一番の見出しもサイトタイトルにするのは？

678 ：Name_Not_Found：04/07/03 20:03 ID:???

<div class="section">
　　<h2>abcd</h2>
　　<p>efgh</p>
　　<div class="section">
　　　　<h3>1234</h3>
　　　　<p>5678</p>
　　</div>
</div>

か

<h2>abcd</h2>
<div class="section">
　　<p>efgh</p>
　　<h3>1234</h3>
　　<div class="section">
　　　　<p>5678</p>
　　</div>
</div>

どっちがいいですか？

679 ：Name_Not_Found：04/07/03 21:02 ID:???

>>678
XHTML2.0的にもフラグメント参照的にも前者の方が良いと思われる

680 ：Name_Not_Found：04/07/03 22:04 ID:???

まずは div class="section" が必要かどうかじっくり考える。

681 ：Name_Not_Found：04/07/03 22:12 ID:???

お前の中で div class="section" の持つ意味を考える。

というか定義が「見出しを内包する文章の塊」なら前者だし、
「直前に存在する見出しの範囲」なら後者。

例えばそのsectionを使ってCSSやXSLやDOMでなにをするの？
場合によっては両方ともいらないし、両方とも必要になる場合もある。

682 ：645：04/07/04 01:54 ID:???

>>651
>>649で修正してるだろうが。

683 ：Name_Not_Found：04/07/04 01:56 ID:???

>>663
起点について話してるんじゃなくて、「start」とかがどこにあたるのか、って話なんだけどな。

684 ：Name_Not_Found：04/07/04 10:30 ID:???

むかし擬人化キャラクターのｽﾄﾘｸﾀﾝだっけ？そんなのいたじゃない。
あれって人気でなくて消えちゃったの？最近全然みないんだけども。

685 ：Name_Not_Found：04/07/04 11:03 ID:???

>>678
こうすれ

<div class="section">
<h2>abcd</h2>
<div class="content">
<p>efgh</p>
<div class="section">
<h3>1234</h3>
<div class="content">
<p>5678</p>
</div>
</div>
</div>
</div>

>>681
構造化したり、XHTML2へ移行する準備には必要。
CSSも後から変更しやすいしな。

686 ：Name_Not_Found：04/07/04 11:36 ID:???

掲示板で投稿日時をあらわす時

<dl class="date">
<dt>投稿日時</dt>
<dd>2004-01-01 11:11</dd>
</dl>

と

<p class="date">投稿日時 2004-01-01 11:11</p>

どっちがいいでしょうか？

687 ：Name_Not_Found：04/07/04 13:52 ID:???

ちょっと出遅れた。
>>650
しかし、rel要素は現在のドキュメントからの関係の意味だから
絶対的にはなり得ないと思うが。

節ごとにページを分けている場合、
第3章第5節のページから見て rel=chapter というのは、
現在の章のページ、つまり、第3章の扉ページへのリンクか、
扉ページがなければ第3章第1節へのリンクになるんじゃないの?

ページが階層ごとに分かれていれば、例えば、

トップページ > ショップ > コンピュータ > ノートパソコン

というような、パンくずリストを

<link rel=start href=トップページ>
<link rel=chapter href=ショップ>
<link rel=section href=コンピュータ>

みたいに表せるんじゃないかなと。

688 ：Name_Not_Found：04/07/04 13:54 ID:???

>>686
<p class="投稿日時">2004-01-01T11:11+09:00</p>

p.投稿日時:before{content:"投稿日時"}

689 ：Name_Not_Found：04/07/04 13:56 ID:???

>>686
後者でいいんじゃない？
一組とわかっているときに定義「リスト」を使うのは抵抗が。
その後で、投稿者：投稿名とか続けるなら別だけど。

>>688
一番ありえない。

690 ：Name_Not_Found：04/07/04 14:00 ID:???

>>688
かなりﾜﾛﾀ

691 ：Name_Not_Found：04/07/04 14:10 ID:???

>>689
688ではないが、どの辺りが有り得ないの？
自分で似たような事をやっているので知りたい。

692 ：Name_Not_Found：04/07/04 14:13 ID:Hf64ae67

>>691
CSSに対応してないブラウザだと数字の意味がわからないんじゃない？

693 ：Name_Not_Found：04/07/04 14:17 ID:???

( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

694 ：Name_Not_Found：04/07/04 14:34 ID:???

>688
ins:before{content:"投稿日時："attr(datetime);}
<ins datetime="2004-01-01T11:11+09:00"><p>投稿本文</p></ins>
このぐらいやろうよｗ

695 ：Name_Not_Found：04/07/04 15:44 ID:???

つまんないね。

696 ：ｽﾄﾘｸﾀｿ：04/07/04 15:58 ID:???

>>684
>669

697 ：Name_Not_Found：04/07/04 18:16 ID:???

>>608
なんか分かってるのか分かってないのかよく分からないんだけど。

制作者Aの作ったHTML文書aに小文字で書かれたidがある部分があるとする。
<h2 id="example1"><a name="example2">……</a></h2>
Aはここへリンクを張るとき(見出しに張って何が面白いのか分からないが)、
<a href="a#example2">とするようにする。
これだけなら問題ない。

しかし、制作者BもHTML文書bからそこへリンクを張りたいと思っている。
そのとき、id="example1"と書いてあるからBは素直にこう書いてしまうかもしれない。
<a href="a#example1">

このような不正を招く可能性があるから、idは大文字で書くべき。

そもそも、URIの尻尾以外でも――例えばスクリプトでも、idを使う限り大文字で書かなければならない。
例えばCSS。
h2#EXAMPLE1{.....}
本当に正しいのはこれ。次の例は厳密に言えばいまいち。
h2#example1{.....}
実際にはCSSでは大文字小文字は区別されないから、この例はいずれも間違いではない。
でも、他に区別する言語はいくらでもあるだろうし、云々。

698 ：Name_Not_Found：04/07/04 18:27 ID:???

まあ、XHTML使ってる俺には関係ない話題なわけですね。

699 ：Name_Not_Found：04/07/04 20:37 ID:???

XHTML文書からHTML4.01文書のフラグメントにリンクを張ることもあるだろうさー

700 ：Name_Not_Found：04/07/04 21:55 ID:???

これだからHTML4.01は(ry

701 ：Name_Not_Found：04/07/04 22:33 ID:???

該当する全てのレス番を挙げるのは面倒なので無し

中途半端な知識でツッコミ入れるな
話がこじれて長くなるだけだ

702 ：Name_Not_Found：04/07/04 22:52 ID:???

>>701
おかしい所があるなら、はっきり指摘してほしいな。その方が読む側も助かるし。

703 ：Name_Not_Found：04/07/04 23:04 ID:???

それは確かに。

704 ：Name_Not_Found：04/07/04 23:20 ID:???

>>701
中途半端なツッコミの典型例

705 ：Name_Not_Found：04/07/05 00:42 ID:???

文章・・・・・・
<div style="回り込み設定">
<img src="hoge.jpg" alt="" /><br />写真の説明
</div>
・・・・・・文章

# 以前は　<br />写真の説明　を付けてなかったのですが
# 説明があったほうが見やすいとの指摘があり全体を<div>で囲って説明を追加しaltを空にしました。

このような場合、どのような書き方をするのが良いのでしょうか？
また、altは空にすべきか何か書くべきか・・・どちらが良いでしょうか？

706 ：Name_Not_Found：04/07/05 00:44 ID:???

なんとなくbrが気に喰わないが
alt="[写真]"
でいい気がする

707 ：Name_Not_Found：04/07/05 00:51 ID:???

<img src="hoge.jpg" alt="hogehogeの写真です。" />

img:after{ content:attr(alt); }

708 ：Name_Not_Found：04/07/05 01:05 ID:???

>>707
altよりかtitleの方がいいかも。

短い説明であればtitleでいいと思うけど長いようなら別に文章にしていいと思う。
他の要素の内容について説明を書くときも短いものはtitleで長いものはそうすることが多いし。
#より正確には長い短いよりもそれが補助的なものか、それ自体がコンテンツの一部になるか、か。

709 ：Name_Not_Found：04/07/05 03:04 ID:???

>>687
文書群の意味を考えれ。

課長から見て部長。係長からみても部長。

↑これは課長と係長からの部長との関連性を表している。誰から見ても部長は部長。
わかた？

710 ：Name_Not_Found：04/07/05 03:42 ID:???

>>687
よし！俺が>>709につけたしてやろう！

「部長」と言うのは会社内でのある人物の立場を、絶対的なもので表現したものだ。

これをHTMLに置き換えてみよう。社長はstart、部長はchapter、課長はsection。
かなりおおざっぱな言い方だけど、文書群と文書の違いに気づくべし！グループ内での
絶対的な立場を表現するのに使うのが、chapterとかなのさ！

711 ：687：04/07/05 04:38 ID:???

>>709 >>710
もちろん、見る人によって部長が課長に変わったりはしない。
そう言う意味では絶対だが、私の言った相対というのは
そういう意味じゃない。

自分が例えば営業部の所属だとすると、
部長と言えば営業部長のことであって、人事部長のことではない。
しかし、人事部所属の人から見れば、部長とは人事部長のこと。
そういう意味の相対を言ってる。

だから、同じ文書群でも文書ごとに chapter のリンク先は異なる。
>>650 のような、自分が所属してない章にまでリンクして
全文書同じことを書くのはおかしいと言いたかった。

712 ：709：04/07/05 05:06 ID:???

>>711
それはどうなんだ？

そもそも
>自分が例えば営業部の所属だとすると、
>部長と言えば営業部長のことであって、人事部長のことではない。
>しかし、人事部所属の人から見れば、部長とは人事部長のこと。
>そういう意味の相対を言ってる。
ここまでのことをlink要素で表現しようとするべきなのかね？部長は部長。どこの部長なのかは
表現しなくてもいいんじゃない？

どっから見ても文書群のなかでは「章」である。くらいでいいんじゃない？そもそもchapterとかは
文書群の中における立場を表すもので、読んでる文書からのはnextとかparent辺りで済ましたほうが
すっきりすると思うけどね。link要素をテキストブラウザ用にやる場合なんかはただのナビ的な役割も
大きいし。

>>711の完璧なまでの構造化をやるのに疑問があるのだけど、人事部の平社員から見た営業部の
部長の事をrelの値の何で表すつもり？表せないなら却下ね。

713 ：Name_Not_Found：04/07/05 06:50 ID:???

>>712
1章とか2章とかまでは構造を示せないってことか？
章である。で終わりか・・・・なんかショボイなhtml4.01って
お前ら今はサイバーノーガードの時代ですよ。

714 ：Name_Not_Found：04/07/05 06:52 ID:???

>>712
仕様書に書いてある値しか使えないと思ってるぽ

715 ：Name_Not_Found：04/07/05 07:21 ID:???

>>713
なんか技の名前みたいでかっちょええ。
サイバーーーーーッ
ノォーーーーーーグァーーーーーッド！！

716 ：Name_Not_Found：04/07/05 07:46 ID:???

relのchapter、sectionはこう使うのだと思っていた…
例えば当該文書が第三章四節だとして、

rel=chapter href=chapter1
rel=chapter href=chapter2
rel=chapter href=chapter3
　rel=section href=section1
　rel=section href=section2
　rel=section href=section3
　rel=section href=section5
　...
rel=chapter href=chapter4
...

717 ：Name_Not_Found：04/07/05 08:36 ID:???

>>716
上から順番に1章、2章であるなんて仕様書に書いてあったっけ？

ところで初歩的ですまんがdl定義リストの入れ子について。
<dl>
<dt>hoge</dt>
<dd>あぴい<dt>ちゃちゃちゃ</dt><dd>うちゃちゃ</dd></dd>
</dl>
っていうのは駄目なんだな。知らなかった。
<dd>の中で定義リストを作りたいときはどうすればいいんだ？仕様書の定義リストの
レベル２のとこみたけど、いまいちわからなかった。

っていうか仕様書の例文が終了タグを省略するなよな。どれとどれとが入れ子になってるかわかんねよ。

718 ：Name_Not_Found：04/07/05 08:39 ID:???

>>716
真面目な話すると、そこまでやられるとlynxでの見栄えが悪い。逆効果だね。

719 ：Name_Not_Found：04/07/05 08:44 ID:???

>>716=711なのか？
だとすると矛盾するけどな。>>716のは思いっきり絶対的な表現になってる。というかできてる。
3章4節からでもどこからでも順序によって、どこの「部」のどんな役職かをはっきり表せてると思うんだけど
違うのかな？

それにしてもわざわざsection4を抜いてる意味は何？自分がどこなのか言わないと、
それこそ関連性もないんじゃない？文書群の中での自分の位置ね。

720 ：Name_Not_Found：04/07/05 08:50 ID:???

>>717
> <dd>の中で定義リストを作りたいとき
<dd> の中に <dl> 入れる。

> どれとどれとが入れ子になってるかわかんねよ。
新手のヘタレだなぁ。見慣れなきゃ解らんでもいいけど
そんな不満SGML系の仕様書に言ってもしょうがないと思われ。

721 ：717：04/07/05 08:51 ID:???

ごめん解決。
<dl>
<dt></dt>
<dd>
<dl>
<dt></dt>
<dd></dd>
</dl>
</dd>
</dl>
だったね；忘れてたよ；

722 ：717：04/07/05 08:52 ID:???

>>720
おっと紙一重。わざわざアホな質問相手にしてくれてありがと。

723 ：687：04/07/05 10:23 ID:???

>>712
表せないというか、表す必要がない。上下関係が示せていれば、
全体の構造化はできるし。

>>719
もちろん私は >>716 じゃない。
私は例えば、第3章第4節第2小節の文書からなら

rel=chapter href=chapter3
rel=section href=section4

でいいと思う。>>716 の考え方だと、rev=chapter とかだと何を
リンクする? 全文書?
で、chapter は全部書くのに、section は自分の章だけを書くの?

724 ：Name_Not_Found：04/07/05 16:53 ID:???

なんつーか、直系血族だけを示せば良いってことでおｋ？

725 ：716：04/07/05 17:18 ID:???

>>723
> rev
特に必要なければ無理やり入れることもない気が。
> chapter は全部書くのに、section は自分の章だけを書くの?
まあ、文書群の中でその文書が見渡せる部分の視覚象、といったところか。

>>723案のほうが簡素でいいかもね。

726 ：Name_Not_Found：04/07/06 12:44 ID:???

CSSスレと迷ったけど、結局は現実的にStrictで書くときの問題なので一応こっちに。

HTML4.01Strict+CSSでサイトを書き上げた。CSSはNC4以前、IE4以前には空のCSSを読ませる。
しかし、IE5って実は結構な実装不備？がある。

IE5に空CSS読ませてすっぴんではさすがに困る；けど、IE5用に別に作ると、サイトの更新が不便になる。
そんなわけでどうするか迷ってる・・・・・

みんなはIE5の扱いどうしてる。実際にStrictでじゃんじゃｎサイトを作ってるここの住人の意見が
とても聞きたい。頼む！

727 ：Name_Not_Found：04/07/06 13:19 ID:???

XSLTを使うのだ、ルーク。

728 ：Name_Not_Found：04/07/06 13:22 ID:???

>>726
はっきり言うが、スレ違い。
IE5用のCSSを用意してUA判別するという話だとして、Strict-HTMLとは関係ない。
HTMLはUAの実装や種類とは別の次元の話。

さらに、誤読かもしれないが、IE5用に別のHTMLを用意するなどという話であれば
もはやStrict-HTMLの話題ですらない。

729 ：Name_Not_Found：04/07/06 13:24 ID:???

>>726
SSIでも使っとけ。

俺はIEには空CSS読むようになってしまってるがな（＾∀＾）ﾐﾔｽｲｼﾞｬﾝ

730 ：726：04/07/06 13:46 ID:???

>>727
XSLTなんて使えないよ；
>>728
htmlを二つ用意するなんて意味不明なことしないよ。CSSファイルをIE5用に別に作るかって話だよ。
>>729
通販サイトだから、IE5以上n6以上では見栄えを保持したいよ。

なんか俺は質問もしっかりできない馬鹿なんだな；
要約すると、Strict+CSSで書くときに、実際にみんなはCSSファイルを何パターン作るの？

まず標準準拠してるブラウザ用に一つだよね。
それでn4以前ie4以前用の空ファイルを一つ。

ここまではいいんだけど、これではIE5でつまづく可能性もある。
だからIE5にも空CSSを読ませるか、それともie5だけの為にie5で通用するおかしなCSSを書いて読ませる。

みんなは実際にHTML4.01Strict+CSSでサイトを作るときどうしてる？
（HTML4.01ってさっきは言い忘れてごめん）

731 ：Name_Not_Found：04/07/06 13:55 ID:???

ほう、見事に質問を理解できてなかったんだな俺は。
俺はI5には普通に書いたCSSを読ませてる。
っていうか良いことを教えてあげよう。
ここにいる人間はStrict+CSSでサイト構成なんてしてるやつはあまり多くない。
というかサイトを作ってるやつが少ない。
何しろStrictなんてのは、仕事として作成代行をしてるやつらには現実的には役に立たないものだからだ。
Strictで書いてるのはほとんど趣味で自分のサイト作ってるやつらだけ。
もしくはほんとの凄腕君。まあ凄腕君がここにいるかは知らないけどな。
簡単に言うとこのスレは妄想スレなのだよ。
ただしくマークアップする、又はその話をするのが趣味であって、現実的にサイトを作ることはしないのよ。
だからお前はStrict+cssで作ってるやつらの経験からなるアドバイスを求めてここに来たのは
間違いってこった。

とりあえずサイバー！

732 ：Name_Not_Found：04/07/06 13:58 ID:???

特定のUAでの見栄えのためにHTMLを変えるのはこのスレ的にはだめだが特定のUAでの見栄えのためにCSSをいじったり、そのUA用のCSSを作るのはこのスレ的にはどうでもいい。
HTMLからはただのスタイルシートの1つにしか見えない。
よってスレ違い。

ちなみに漏れはMozillaに合わせて作ってIEで確認して致命的な部分だけ修正という感じ。CSSはクソなので見栄えはあきらめてる。それかXSLT使う。

733 ：Name_Not_Found：04/07/06 14:12 ID:???

CSSはスレ違い

734 ：Name_Not_Found：04/07/06 14:29 ID:???

> CSSはクソなので見栄えはあきらめてる。
同意。

735 ：Name_Not_Found：04/07/06 14:48 ID:???

知った事か。

736 ：Name_Not_Found：04/07/06 14:57 ID:1vkNLh5/

荒らしと思ったら放置。
スレ違いと思ったら１回だけ指摘して後は放置。

737 ：Name_Not_Found：04/07/06 15:17 ID:???

>>730
> 要約すると、Strict+CSSで書くときに、実際にみんなはCSSファイルを何パターン作るの？
2つ。
nn4以前対策用と普通のCSS。
普通の方は、
全体を@mediaで括って、mac ie5を弾き、
その中で内で、子セレクタ(p > em)や属性セレクタ(p[class="note"])を駆使して
IE5以降とMoz系を切り分ける。

という解凍が模範解答ですか？

738 ：730：04/07/06 15:29 ID:???

ここは自治厨で一杯だな。

>>737
模範回答です。保存しておきます。

739 ：Name_Not_Found：04/07/06 15:38 ID:???

>>737
正しい実装であふれて来たら書きなおさなきゃいけないなんて、
テーブルレイアウトと共通する部分があるな。

いいか>>730
Validってのは仕様書通りに書くことなんだよ。
お前がCSS1を使ってるならその仕様書に従え。そこにブラウザ振り分けについて書いてないのなら
何もする必要はない。それがValidだ。

740 ：Name_Not_Found：04/07/06 15:42 ID:???

>>738 はどうやって >>737 が模範解答であるかどうかを判断しているんだか。

741 ：Name_Not_Found：04/07/06 15:44 ID:???

俺　イズ　ルール

742 ：Name_Not_Found：04/07/06 16:04 ID:???

>>739
> >>737
> 正しい実装であふれて来たら書きなおさなきゃいけないなんて、
正しくなったら書き直さなくても良いと思うけど？
変な実装が増えたら書き直さなくてはならないことは確かだけど。

743 ：Name_Not_Found：04/07/06 16:29 ID:???

pre{
　overflow : auto;
}

/* 後方互換 */
pre{
　width : 100%;
}

/* 標準 */
*>pre{
　width : auto;
}

744 ：Name_Not_Found：04/07/06 16:36 ID:???

過疎状態の方がまだマシだったと思う夏の日

745 ：Name_Not_Found：04/07/06 16:43 ID:???

@import "IE5_IE6.css";
@import "Mozilla.css" all;

746 ：Name_Not_Found：04/07/06 16:47 ID:???

CSSでイケてるデザインサイトスレも「通販サイトを作りたい」って奴に
荒らされてたな。

荒らしも相当に駄目な奴、ネタ切れの所に放置スキルが低すぎた住民も駄目だった。

747 ：Name_Not_Found：04/07/06 17:08 ID:???

HTMLいじりたくないから送信するCSSをPHPで選んでる。。

Gecko用に書いたものをメインにして、
IEとかOperaはそれをインポートして細かい修正。
んで、リクエストが来たらHTTPヘッダからUA割り出して
どのファイル送信するか決める。
楽ちん。

748 ：Name_Not_Found：04/07/06 17:12 ID:???

Strictと現実のブラウザの実装に合わせたテクニックというのは違う話題だしね。
ただ両方需要のある話題だと思うので、後者の話題を扱うスレを立ててはどうだろうか？

余談だけど、Web Designという雑誌に属性セレクタ等を使って
IEとMoz、Opera、Safari系に適用するスタイルを振り分けるというTipsが
紹介されてて、この手の雑誌もなかなか侮れないなと思った。

749 ：Name_Not_Found：04/07/06 17:37 ID:???

>>748
まあ、よっぽどうがった見方をしなければ「この手の雑誌」の中の人も
うすうす html + css の有用性はわかっているのだろうと思うよ。

ただ、それを大声で(･∀･)ｲｲって言っちゃうと、
毎月原稿書いてくださっているテーブルレイアウターのお歴々を
全否定することになりかねないので、扱いが小さいのかな、と。

750 ：Name_Not_Found：04/07/06 17:39 ID:???

今出てる内容レベルだったら、十分
Webサイト制作初心者用質問スレ
http://pc5.2ch.net/test/read.cgi/hp/1088856477/l50

で十分だろ。仕様に対して厳格でありたいなら
W3C信者にサイトを正しい記述に直して貰うスレ
http://pc5.2ch.net/test/read.cgi/hp/1061741473/l50

或いは、StrictなHTMLを用意した上で各種UAのバグ回避を行いたいなら
CSS･スタイルシート質問スレッド
http://pc5.2ch.net/test/read.cgi/hp/1087263288/l50

ここら辺。

751 ：Name_Not_Found：04/07/06 17:40 ID:???

>>748
Safariだけに対して適用というのもあるの？
だったら見てみるかな・・・

752 ：Name_Not_Found：04/07/06 18:25 ID:???

>>748
スレ違いだと解りながらスレ違いな話題を振るなよ

753 ：Name_Not_Found：04/07/07 01:19 ID:???

>>739
しかしCSSには前方互換というものがあってまた話がややこしくなる。
#スレ違いスマソ。

754 ：Name_Not_Found：04/07/07 08:05 ID:???

謝るくらいなら

755 ：Name_Not_Found：04/07/07 08:06 ID:???

最初からやるな。

756 ：Name_Not_Found：04/07/07 14:20 ID:???

HTML4.01Strictでサイトを作りおわって、後は宣言だけなんだけど、

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

これと

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">

これはどっちがいいの？確か上はIEとかでCSSが標準準拠モードになって、下は互換モードに
なるんだったよね？合ってる？

まあCSSのモードはどちらでもいいけど、ストリクタンならどっち？

757 ：Name_Not_Found：04/07/07 14:29 ID:???

どっちも良くない気が。
TransitionalかStrictか位明記した方がいいような。

758 ：Name_Not_Found：04/07/07 14:36 ID:???

IEはどっちでも標準準拠モードよ。

759 ：Name_Not_Found：04/07/07 14:40 ID:???

>>758
ttp://www.faireal.net/articles/4/25/#d20216a

<q>MSIE6には「後方互換モード」と「標準準拠モード」があって、HTML文書の最初の行にDTDを書くと（もちろんDTDを示すURIのことです、以下同じ）「標準準拠」になります。</q>

下は互換モード。勉強しなおせ。

760 ：Name_Not_Found：04/07/07 14:51 ID:???

>>759
別に勉強する必要がないと思うが。

761 ：756：04/07/07 15:13 ID:???

>>757
とりあえずあなたは間違っている。

>>758
あなたも間違っている。

>>759
その最初の行って、URI自体は2行目になってもokでしたよね？ってまあ一応ブラウザで確認済みだから
別にいいですが、なんか変な言いかただから気になって；

>>760
仲良くしませう

762 ：756：04/07/07 15:18 ID:???

っていうか俺はCSSのモードなんてどうでもよくて、ストリクタン的にはどちらを推奨するかって話しなんだよな・・・・

763 ：Name_Not_Found：04/07/07 15:21 ID:???

>>756
ｽﾄﾘｸﾀﾝと(*´Д`)ﾊｧﾊｧする資格はその二つの上の方の記述のみ有する。

764 ：Name_Not_Found：04/07/07 15:32 ID:???

http://members.jcom.home.ne.jp/pctips/www/DOCTYPE.html
> HTML 4.01の文書型宣言に於るシステム識別子(*.dtdのURI)の記述は省略できます。
> SGMLアプリケーションであるHTMLでは、この記述は省略した方が正式であるとの説もあります(?)。

怪しいねえ。俺は省略できるものも省略しないのが真のすとりくたんだと思ってるけど。

765 ：Name_Not_Found：04/07/07 15:43 ID:???

public identifier自体がリソース指しているから省略していいよ。
<!DOCTYPE root SYSTEM...
ってやった場合はもちろん省略してはいけないが。

766 ：756：04/07/07 15:45 ID:???

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

やっぱこっちか。そりゃそうだよな。

関係ないけど、早くStrictが広まらないかな

767 ：Name_Not_Found：04/07/07 15:46 ID:???

>>765
それってTransitionalでも？

768 ：Name_Not_Found：04/07/07 15:48 ID:???

>>767
別にTransitionalかそうでないかは、関係ないと思うけど…？

769 ：Name_Not_Found：04/07/07 15:48 ID:???

ここは役にたつか？どうか？
ttp://www.mars.dti.ne.jp/～fuming/advanced/dtd.htm

770 ：Name_Not_Found：04/07/07 15:54 ID:???

>>768
だってloose.dtdじゃん。trは。

771 ：Name_Not_Found：04/07/07 15:55 ID:???

ttp://style.tigris.org/nonav/tigris_transitional.dtd

772 ：Name_Not_Found：04/07/07 15:56 ID:???

>>770
？？問題あるの？？

773 ：Name_Not_Found：04/07/07 15:59 ID:???

>>772
中身が違う

774 ：Name_Not_Found：04/07/07 16:00 ID:???

>>773
だから何？

775 ：Name_Not_Found：04/07/07 16:01 ID:???

スレ違いな話題はスルーで行きましょう。
荒らしは完全放置でお願いします。

776 ：Name_Not_Found：04/07/07 16:01 ID:???

>>773
まさかTransitionalが
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
とかかれるのを忘れていないよな？

777 ：769：04/07/07 16:02 ID:???

役にたたか？どうか？

778 ：Name_Not_Found：04/07/07 16:02 ID:???

>>777
スレ違いかと。

779 ：773：04/07/07 16:06 ID:???

>public identifier自体がリソース指しているから省略していいよ。

public identifierの意味を激しく勘違い。言うのは恥ずかしいからヤダ。

780 ：Name_Not_Found：04/07/07 16:07 ID:???

>>779
可愛いなぁ

781 ：Name_Not_Found：04/07/07 16:08 ID:???

一連の流れ自体、「仕様嫁」の一言に尽きる訳だが。
ttp://www.w3.org/TR/html4/struct/global.html#h-7.2
ttp://www.w3.org/TR/html4/sgml/intro.html

とりあえず上記２文書を読めば自分の指定したい DTD の宣言が書け、
かつ、URLを省略しても構わない理由が理解出来ると思うのだが。

782 ：Name_Not_Found：04/07/07 16:11 ID:???

強制IDに戻らんかな

783 ：Name_Not_Found：04/07/07 16:15 ID:???

>>782
多分2人か、1人のアホがかまって欲しくてうめいているだけかと。
スルーでよろ

784 ：758：04/07/07 21:16 ID:???

ほう、俺は間違ってましたかそうですかそうですか…
http://www.microsoft.com/japan/msdn/ie/ie60/cssenhancements.asp

785 ：Name_Not_Found：04/07/07 22:01 ID:???

スレ違いな話題はスルーで行きましょう。
荒らしは完全放置でお願いします。

786 ：Name_Not_Found：04/07/07 23:14 ID:???

略

・　荒らしを無視できない。
　　例）「あらあらまたですか。暇な人ですねえ。」
　　　　「みんな、わかってると思うけど、>>○○はスルーですよ！(`･ω･´) 」
構うから荒らされるんだぞと、１０回注意しても直らない。

787 ：Name_Not_Found：04/07/08 01:20 ID:???

strictだね

788 ：Name_Not_Found：04/07/08 01:40 ID:???

本文中の最上位の見出し（h1）はtitle要素と同じ値になるのが一般的なんでしょうか？
titleで示されているレベルの見出し（文章の表題）をh1でもう一回書くのが冗長に思えるのですが。

具体的には

title:７月の日記
h1:７月の日記
h2:１日
h2:２日

と言う構成からh1レベルの階層を丸ごと引っこ抜いて

title:７月の日記
h1:１日
h1:２日

ってな文書構成で十分間に合っている気がするんですが如何でしょうか？
ちなみに、この場合文書全体へのナヴィとかはtitleと同レベルのlink要素
などで

789 ：788：04/07/08 01:43 ID:???

すません、途中で送っちゃいました…orz

（続き）
ちなみに、この場合文書全体へのナヴィとかはtitleと同レベルのlink要素
などで提供されていると考えるので（そもそも従来のh1レベルの見出しが
head内にあるからいらないや、と言う発想なので）body直下にくる内容はなく、
全ての文章は複数ある何れかのh1に属する物になる、つもりです。

790 ：Name_Not_Found：04/07/08 02:10 ID:???

>>788
h1は本文、titleはメタ情報。
例えば、h1は単に「7月」だけでも良い。
titleの方は、「2004年7月の日記」とか、その文書の内容を正確に示すものにする。

日記帳の各ページに、いちいち「○年○月の日記」と書く必要はない。
でも、そのページの内容を正確に示そうとすれば、「○年○月の日記」と言わなければならない。

791 ：788：04/07/08 08:25 ID:???

>>790
ええとじゃあ、titleは「誰某の2004年7月の日記」と書くとして、
結局「2004年７月」というくくりのh1は必要でしょうか？

h1を「2004年７月○日」というレベルにして、一つの文章にh1が
（従来のh2の数だけ）複数登場する文書構造というのはどうだろう、
と言うのが自分の疑問です。

792 ：Name_Not_Found：04/07/08 08:29 ID:???

>h1を「2004年７月○日」というレベルにして、一つの文章にh1が
>（従来のh2の数だけ）複数登場する文書構造というのはどうだろう

誰か翻訳もしくは脳内補完きぼん

793 ：Name_Not_Found：04/07/08 08:36 ID:???

>>791
君が文章の執筆者なんだから、どれを見出しにするかは君が決めること。
hの数字は見出しのレベルを表してるだけであって、いくつあろうが問題ない。

794 ：Name_Not_Found：04/07/08 08:44 ID:???

それからよくある質問なんだが、画像を表示させているとして
文章上それが見出しの役割をもっているならhnでマークアップするべき。
万が一画像が表示されなくてもalt属性に指定した文字列が見出しとして適切に機能する。

795 ：Name_Not_Found：04/07/08 09:45 ID:???

>>788
同じ時間に全く同じこと考えてました・・不思議

>>790
titleがメタ情報であるならば、meta要素を使うのでは
特殊なメタ情報として独立定義されたということでしょうか？

>日記帳の各ページに、いちいち「○年○月の日記」と書く必要はない。
>でも、そのページの内容を正確に示そうとすれば、「○年○月の日記」と言わなければならない。
この文書のtitleは「○年○月の日記」ではなく「日記帳」ではないでしょうか。

h1は文書の「章題」だったような。
文書題名＝章題としてしまうと、連番章（第１章・第２章...）が記述不可能では。
即ち、ｈｔｍｌ文書中には連番章は置けないのでしょうか？

ちなみに、W3Cのサイトは、h1にtitleと同じもの使ってますね。

796 ：Name_Not_Found：04/07/08 09:57 ID:CTqO+vGD

DOCTYPEのコメントでは>は使ってはいけないのでしょうか？

<!DOCTYPE --test>-- HTML PUBLIC ... >

797 ：Name_Not_Found：04/07/08 10:02 ID:???

>>792
>>788

798 ：Name_Not_Found：04/07/08 10:43 ID:???

>>795
言いたいことはわかるし、確かに仕様書では一般例としてh1要素をsectionとして扱っている。

ただ、以下は漏れの仕様書を読んだ上での解釈が混じっていることを予め断っておくが、
連番章よりも大きな単位の「見出し」がマークアップ前の段階で既に存在しているのであれば、
それをthe topic of the sectionとしてh1要素として定義"すべき"で、
連番章を具体的に表すにはh2要素を使用してもよいのではないだろうか。
だから、連番章よりも大きな見出しがマークアップ前の時点でなければh1要素を章題として扱うだろうし、
あれば（おそらくはtitle要素内容と同じものが）h1要素となると思う。

より大きな単位の見出しがない場合も文書構造によっては存在するだろうし、
title要素とh1要素が同じ要素内容を常に持たなければならないことはないと思う。
あくまでもtitle要素はidentify the contents of a documentだから、
h1要素よりも具体的な文章のタイトルが与えられるはず。
文章構造によっては「日記帳」かもしれないし、日記帳の一部分であれば「○年○月の日記」かもしれない。

# それにしても、HTML4.01仕様書の「7.5.5 Headings: The H1, H2, H3, H4, H5, H6 elements」は出来が悪い気がする。
# div要素でsectionを表す方法と見出しをsectionとして扱うなんてことが併記されている割に、
# h1以下はどういう明確な意味を持つのかをきちんと説明してくれていない。

799 ：796：04/07/08 12:39 ID:???

<A --href="no"コメントなの -- href="yes">test</A>
<A -- href="no"コメントじゃないの -- href="yes">test</A>
<A -- href_="no"コメントなの -- href="yes">test</A>
結果：
yes
no
yes

800 ：Name_Not_Found：04/07/08 13:13 ID:???

>>796
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/intro/sgmltut.html#h-3.2.4
http://www.ne.jp/asahi/minazuki/bakera/html/sgml/comdeclare
使っても良い。

ただし通常のタグの中ではそもそもコメントは書けない。

801 ：Name_Not_Found：04/07/08 13:27 ID:???

ttp://pc5.2ch.net/test/read.cgi/mac/1083108306/
ここで粘着してるあんたらのバカ仲間さっさと連れて帰ってくれよ。

802 ：Name_Not_Found：04/07/08 13:29 ID:???

サイト名っていうのは、何要素でマークアップすればValidになれますか？
もちろん自分のサイト名です。

<hn>で→別に見出しではない気がします。
<title>（head内の）で→これのような気もしますが、２ちゃんとかは使ってませんし。
　　　　　　　　　　　　サイト名がmeta情報っていうのも違和感があると思うのは間違いでしょうか？

そもそもサイト名って、本の名前と同じですよね？そうすると文書群に付ける総称とかにあたるわけですよね？
文書群であるかどうかはリンク要素でしっかり他文書との位置付けをしてあるかどうかだと思うので、
title要素でやるのは少しおかしいかなと。

でもtitle要素以外にイマイチ見つかりません・・・
title要素→文書のタイトル。
ですが、サイト名は文書群のタイトルなので・・・・この考え自体が間違ってますか？

803 ：Name_Not_Found：04/07/08 13:35 ID:???

<title>文書のタイトル - サイトタイトル</title>
ってのがよくあるわけだが、まあ確かに<title>要素内に文書のタイトル以外をいれるのはStrictではないかもね。

804 ：Name_Not_Found：04/07/08 13:37 ID:???

>>802
サイト名 - ページ名
とか
ページ名 - サイト名
というタイトルを使う手があるな。
あとは文章群の考えにそってトップページのtitleにサイト名を書いて、それ以外のページはlinkでそこにリンクするとか。

805 ：Name_Not_Found：04/07/08 13:38 ID:???

>>802
divとかpとか適当な要素でいいんじゃないの？
ナビゲーション部分に入れちゃうって手もあるし。

806 ：Name_Not_Found：04/07/08 13:56 ID:???

>>802
そもそもサイト名っているの？
これはサイト名（に代表される一連の文書群）に属しますよ、
と言う事なら >>805 の言うとおりナビで良いと思う。

逆にナビする必要がないほど関連が希薄なら本文中にわざわざ記述する必要は
ないんではないかと。

807 ：Name_Not_Found：04/07/08 13:58 ID:???

>>806
そこはあなた、近年のプレゼンテーション化の一途を辿る文書における
訴求力というモノですよ。

808 ：Name_Not_Found：04/07/08 13:59 ID:???

俺の場合
<title>h1の内容 - サイト名</title>
ですよ。

809 ：Name_Not_Found：04/07/08 14:02 ID:???

よし、ここは背景画像で。

810 ：Name_Not_Found：04/07/08 14:04 ID:???

>>809
まさか左上にfixedに四角の中にサイト名入れるとか！？

811 ：796：04/07/08 14:34 ID:CTqO+vGD

>>800
thx.
通常のタグの中でコメント?がもし書かれてたら
>>799,796
みたいなことになっちゃうんですね。

実装次第っぽいからここの○○は諦めるか...

812 ：802：04/07/08 14:38 ID:???

>あとは文章群の考えにそってトップページのtitleにサイト名を書いて、それ以外のページはlinkでそこにリンクするとか。

>ナビゲーション部分に入れちゃうって手もあるし。

参考になりました！よくよく考えてみたら、全部のページにサイト名をいれる必要はないんですね。
本だって外回りに作品の名前があるだけで、中のページにはですからね。

<link rel="strat">
相手からされるページに（トップページ）、サイト名を表記してその後はどこにもなくてもいいですね。

ところで、この考えは文書郡の中に文書群としてのヘッダ（トップページ）があるみたいな感じになりますが、
文書群の中のfooterと位置される文書もあっていいですよね？
それは何で関連づけすればいいですか？（relの値）
序章と後書きとかも何でやればいいかちょっとわかりまえんね。

813 ：Name_Not_Found：04/07/08 14:44 ID:???

とりあえず "bookmark" にしておけば「関連のある何か」程度の意味は
持たせられる。

あとは title属性で「後書き」とか書いておけば、UAを通じて最低限の情報は
読み手に提供出来るのではないかと。

814 ：Name_Not_Found：04/07/08 14:46 ID:???

>>811
タグの中にコメントは入れられません。
799は文法エラーでエラーリカバリーとしてたまたまそのUAが
1つ目は--hrefという名前の属性が"no"、hrefという属性は"yes"
2つ目はhrefという名前の属性が2つあって1つ目を優先
3つ目はhref_という名前の属性が"no"、hrefという属性は"yes"
という風に扱っているだけ。エラーリカバリーなので基本的にUA依存、エラーメッセージを出して終了されても文句は言えない。

815 ：795：04/07/08 14:59 ID:???

>>798
私は、ｈ1の上位層として、titleを捉えています。無理矢理表現するならば、h0でしょうか。
即ち、文書中に１つしか出現せず、文書全体の見出しとなるものを、
ｈｎから独立させ、titleとして定義できるのでははないかということです。
ツリー構造の起点がtitleで、そこから派生するのがhnと。

論点少しずれますが、
title要素が視覚系UAではタイトルバーにしか表示されないことに、疑問を感じます。
描画エリアにtitle要素が表示されればな、と。
過去のUAは、描画エリアにbodyを表示しています。
しかし、標準準拠モードでは、描画エリアにhtmlを表示しています。
htmlとbodyに別々背景色指定ができ、それが描画されることから明らかであるといえます。
head中のtitleを表示しないのは、UAが過去の仕様を引きずっているのではないかと。
独りよがりすぎますかね...

文書のタイトルが表示されれば、ｈ1はタイトルより下層の分類に使用されることが
視覚的に明確にできるんじゃ、と。

816 ：Name_Not_Found：04/07/08 15:05 ID:???

>>815
＞描画エリアにtitle要素が表示されればな、と。
CSSで可能では？
head *{display:none;}
head, head title{display:block;}

817 ：795：04/07/08 15:29 ID:???

>>816
私の不勉強でした。できますね。ありがとうございます。
IEでは無理みたいですが。

818 ：796=811：04/07/08 15:45 ID:CTqO+vGD

>>814
解説、参考になります。
(ちなみに、N7.1だと三番目がnoでした。)

エラーリカバリーしないと見れなくなるし、
エラーリカバリーを失敗したらおかしなことが起こる可能性がある
のかぁ。そもそもエラーのないファイルだけなら幸せなんだろうが、
そうもいかんだろうし、難しい...

ありがとうございました。

819 ：Name_Not_Found：04/07/08 15:52 ID:???

>>817
Operaではこれやると子ウィンドウに表示されるはずのタイトルが
表示されなくなります。Operaではユーザビリティを下げかねないかも。

820 ：Name_Not_Found：04/07/08 16:05 ID:???

>>819
CSSの話の上、UAの実装の問題なので完全にスレ違い。

821 ：795：04/07/08 16:55 ID:???

>>820　>>816　>>all
私の無知の為、スレ趣旨から外れたことをお詫びします。

一連の議論から、
文書の本体を示すbody内に、文書名と同趣旨の見出しが挿入されることが、
自分の違和感の原因だと自覚できました。

漠然としたものが形になっただけでも有意義です。
皆さんありがとう！

822 ：Name_Not_Found：04/07/09 10:58 ID:???

h1に文書名を表示し、かつh1による連番章を可能にするには？

[結論]
章接頭部にタイトルを表示

[以下考察]
文書構造を詳細に記述する。

整形前
文書名：○○動物園
・○○動物園　序章
・○○動物園　第1章
・○○動物園　第2章
　・○○動物園　第2章　第1節
　・○○動物園　第2章　第2節...

これでは煩雑

整形後
文書名：○○動物園
・○○動物園　序章
・第1章
・第2章
　・第1節
　・第2節

823 ：Name_Not_Found：04/07/09 11:50 ID:???

>>822
タグで説明してくれ。

824 ：Name_Not_Found：04/07/09 11:57 ID:???

825 ：Name_Not_Found：04/07/09 15:43 ID:???

>>824
汗クセーってお前はw
まあしょうがないよなこの季節はさ。

ところでお前明日の用意してある？俺まだなんも・・・・とりあえずおやつだけでも買っておこうかなと
思って、4時に悠が来るよ。

826 ：Name_Not_Found：04/07/09 15:54 ID:???

え、うん、もうばっちりさ！

827 ：822：04/07/09 15:56 ID:c240cWUi

<head><TITLE>○○動物園</title></head>
<body>
<h1>○○動物園序章</h1>
<h1>第1章</h1>
<h1>第2章</h1>...
</body>

本当は階層表示したい...ul駄目だよね確か...「>」必要？
あと、接頭語という表現は不適切か？「上層を省略しない」ということをいいたい。
要するに「パンくずリスト」類似の表現方法

828 ：Name_Not_Found：04/07/09 16:03 ID:???

>>825
いきなり自分の名前が出てきてびっくりしたｗ

829 ：822：04/07/09 16:08 ID:???

まあ、あれだ、通常の文書では、過剰な情報を省略していると捉えるということ。
階層で表現するのか、語句省略なのか..
うまいこと表現できない。

仕事済んでからまとめるしばしまたれよ。

830 ：Name_Not_Found：04/07/09 17:08 ID:???

>本当は階層表示したい...ul駄目だよね確か
リストじゃないからね。
「既存の要素にない『何か』の階層」だったらdivで良いかと思われ。

>あと、接頭語という表現は不適切か？「上層を省略しない」ということをいいたい。
単なる整形の問題なら CSS で消せば?

今ひとつ何を問題にしているのか解らない。

831 ：1/4：04/07/09 20:04 ID:???

まず結論から。

・h1によって文書名又は同趣旨のものを表示すること（通説）は不適切であると考える
・上記のとおりに解すると、不都合が生じる
・不都合回避し、ブラウザで文書名を強調表示する方法として、>>822を挙げる

C1：h1による文書名表示への批判
　h1によって文書名又は同趣旨のものを表示することは不適切であると考える。
　以下根拠。
　・hnの用法は、本来的に文書内容の区切りを示すものであり、
　　異なる文書間の区切りを示すものではないこと
　　- bodyは文書内容を示す要素であり、その区切りがhnである。
　・文書間の区切りを示す要素には、既にtitleが定義されていること
　　- 詳細は>>815前段引用、文書名はhead内のtitleで示されれば足りる。
　　　h1で表現することは、蛇足である。
　　　bodyにtitleを表示していると捉えられかねない。

　[文書構造モデル]
　 <title>
　 <h1>
　 <h2>
　 <h3)
　 <h2>
　 <h1>...

832 ：Name_Not_Found：04/07/09 20:04 ID:???

C2:h1に文書名を表示しないことの実質的な不都合
　かといって、C1のように考えると、
　titleを描画エリアに表示したいという実際上の需要を満たせない。以下理由。
　・描画エリアにおいて、title要素がデフォルトで表示されないこと
　　- タイトルバーに表示されるだけでなく、
　　　文書名を強調したい場合、その方法がない。
　　　（titleのCSSによる表示は不具合等あり不十分であり、
　　　選択方法として挙げられない）-スレ違い
　・（CSSにより表示するとしても、title中はテキストの記載しか許されておらず、
　　　画像やリンクは使えない）-スレ違い

833 ：3/4：04/07/09 20:05 ID:???

C3:ブラウザで文書名を強調する方法の代替案>>822
　C2の需要を満たしつつ、C1によらない方法として>>822。
　以下理由（説明重複する）。

S1:実際の文書における構造の分析とhtml
　例えば、以下の文書がある。
　
　民法
　第１編　総則
　　　第１章　人
　　　第２章　法人..
　　第２編　物権
　　　第１章　総則
　　　第２章　占有権
　　　　第１節　占有権の取得
　　　　　第１８０条[占有権の取得]
　　　　　第１８１条[代理占有]
　　　　　　占有権は代理人に依りて之を取得することを得..

　C1の立場を取り、
　民法を<title>、編を<h1>、章を<h2>、節を<h3>、条を<h4>で表す。

　この場合、第１８１条の通例的な表現は、
　<h4>第１８１条</h4><p>本文</p>
　しかし、「第１８１条」の前には、当然に省略されている部分がある。

834 ：4/4：04/07/09 20:07 ID:???

　省略せずに第１８１条を表すならば、
　「民法という文書中の第２編物権中の第２章占有権中の
　　第１節占有権の取得中の第１８１条[代理占有]」
　なぜ省略されるか？前後の文書構造により明らかだから。
　省略しないと、煩雑であるから。

　言い換えるなら、<h4>中には、<title><h1><h2><h3>の文書構造が記述されるが、
　通例上省略される。

　では、前後の文書構造が提示できない場合に、第１８１条をどう表現するか？
　省略せずに書けば、どの文書のどこに配置されるべき内容であるか判明する。

S2:文書名をブラウザの描画エリア内で表現する
　これを、html文書として公開する場合を考える。
　<h1>第１編　総則</h1>では不十分と考えて、
　描画エリアに「民法」を強調して表示したい場合を考える。
　C2により現状実質的に不可能であり、提示不可。
　ここで、「第１編　総則」に注目する。
　文書構造を省略せずに書くと、「民法という文書中の第１編総則」

　タグで表すならば、
　<h1>民法という文書中の第１編総則</h1>

このように表示することにより、描画エリア内に「文書名:民法」が表現できると考える。
ということで、>>822を書かせて頂きました。

補足：>>802-813
　サイト名とタイトル名に関する議論も、上記と類似しますね。
　この場合、「サイト名日本国法規集中の民法という文書中の第１編総則」と。
　まあでもlinkによる解決の方が良いですね。

835 ：Name_Not_Found：04/07/09 21:16 ID:???

ちなみに、W3Cの中の人は、h1はtitleと同じでありうると述べているようです。既出かも。
ttp://www.w3.org/QA/Tips/Use_h1_for_Title

836 ：Name_Not_Found：04/07/09 22:30 ID:???

>>831-834
かなり無理がある。

見出しのない文書をマークアップする場合、
title=最上位見出しとすると、titleは空白になってしまう。

本文は本文として記述し、titleはそれとは独立して記述する、で良いと思う。
標題や著者名のような、本文に現れ得るメタ情報に関しては、
body要素内に本文の部分を、head要素内にメタ情報の部分を記述すると
すればすっきりする。

837 ：Name_Not_Found：04/07/09 22:47 ID:???

文書における「見出し」とは、
本文の内容を要約し、簡潔に表現したものだと、私は認識しております。

そのように考えるならば、
見出しのない文書は存在せず、
ただ省略されている、というのが私の立場です。

花

花がさいた

たったこれだけの文書でも、見出しがあります。
もちろん、省略できます。

まあ、通説を真っ向から否定するわけですし、
「あーこいつなんか変わったこといってるなー」
でも、それはそれで良かったり（笑

838 ：Name_Not_Found：04/07/09 22:52 ID:???

ということで、「見出しのない文書」の例示をお願いします。

839 ：Name_Not_Found：04/07/09 23:00 ID:???

ないものをあるかのように見なすのはまさに例証的解釈。
いや、それともこれはウィーン学派の説教かしら。

840 ：Name_Not_Found：04/07/09 23:01 ID:???

とりあえずtitle要素とh1要素の中身は
おんなじでいいよ。深く考えるな。感じるんだ。俺の鼓動を。

841 ：Name_Not_Found：04/07/09 23:02 ID:???

まあ確かに、ちょっとしたメモを取るときに
<title>○○に関するメモ</title>
<h1>○○に関するメモ</h1>
<p>本文</p>
とするのは冗長だと感じるときがある。

842 ：Name_Not_Found：04/07/09 23:07 ID:???

>>841
XSLTを（ｒｙ

843 ：Name_Not_Found：04/07/09 23:09 ID:???

>>839
「例示を伴なわない>>838への批判」

844 ：Name_Not_Found：04/07/09 23:13 ID:???

>>843
言語ゲームの取り違え

845 ：Name_Not_Found：04/07/09 23:16 ID:???

>>837
ということは、実際には省略するつもりでも、
HTMLでは表記しなければならないと?

本の表紙と扉と奥付とでは、標題の表記が違う場合がある。
サブタイトルの有無とか。あれと同じことだよ。

846 ：Name_Not_Found：04/07/09 23:19 ID:???

>>845
いえいえ、見出しはいくらでも省略できますよね。
ただ、最上位の見出しである「タイトル」は、
少なくともhtml文書上は省略できませんよね？

847 ：Name_Not_Found：04/07/09 23:22 ID:???

「見出しのない文書」は存在しない。
なぜなら見出しのない文書には「見出しのない文書」という見出しが存在するからである。
という詭弁に一票。

848 ：822：04/07/09 23:46 ID:???

私が実際ｈｔｍｌ書くとしたら、h1にタイトル付けますよ。
通説に従います。

ただ、このスレの議論として面白いかなと思って前述したまでで、
論理学等を展開しようと思っているわけでもないですし、
実際にh1にタイトル使ってる人責めてるわけでもないです。
趣旨から外れたケンカになるのはもちろん御免です。

まあ、珍論でもなんでも、考えている時が面白いっていうか。
あまり深い意図はありませんので、お気を悪くされた方いましたらすみません。

849 ：Name_Not_Found：04/07/09 23:58 ID:???

>>846
つまり、タイトルが表示上冗長になりすぎることもやむを得ない
ということになる。
「誰々の何年何月何日の日記」
これは本文として表示されるべきものだろうか。
また、下位の見出しの一部分を流用して、最上位見出しのように見せかける
というのは、物理マークアップと大差ないように思う。

以前、同じようなこと考えてたから言いたいことは分かる
(CSSでtitle表示も試したことがある)けど、
「title＝最上位見出し」であるなら、bodyの子要素であるはず。
本文とメタ情報とを分けて考えた方が、一貫した解釈ができると思う。

850 ：Name_Not_Found：04/07/10 00:10 ID:???

>>847
それは詭弁なのか？

851 ：Name_Not_Found：04/07/10 00:20 ID:???

>>849
要約ですから、「日記」でもいいんじゃないでしょうか。

確かに、本来省略されるべき文言を表示して「ごまかす」ことは承知しています。
あくまでも、h1<>titleの立場をとった場合の表示方法の代替手段で、
strictではないと言われてもしかたありません。
実は、その点が上記説の展開の弱点です。
上記説に従うならば、
本当は、代替手段を全くとらないのがstrictでしょう。

titleに特別の意義を与え、headに記述する、というのが、
bodyの子要素ではない理由と感じています。
まあ、わかりやすいようにということで。

ちょっとすみません、仕事明日もあるので寝ます。

852 ：Name_Not_Found：04/07/10 01:06 ID:???

ここは病的なインターネットですね。

853 ：Name_Not_Found：04/07/10 01:17 ID:???

スレには合致しているが、机上の空論の発表なら自分のサイトでやれば？

マジなのかネタなのか理解に苦しむ上に、「まとまってないので
また今度」では、独り言以外の何者でもない。

854 ：Name_Not_Found：04/07/10 01:22 ID:???

まず、body要素内容がリソースの本体であって、
head要素内容は、そのリソース外部の観点からそのリソースについて記述したリソースである。
ただし便宜上、文書という実体の単位においては本文リソースと共に包括されている。
title要素の存在意義は、本文リソースの表題を外部的な視点から示すことである。
title要素の内容に「表題 - それを包括するコンテンツ名」のような記述がしばしばされるのは、
こうした外部性ゆえである。
それに対してh1要素は、本文リソース内部において、文章全体の要約者としての役割を負う。
h1要素の内容は、外部と接触する術はなく、常にそのリソース内部の要因によってのみ決定される。

などというのは、いかにも怪しい議論だ。

855 ：Name_Not_Found：04/07/10 01:28 ID:???

ここは牽強付会なインターネットですね。

856 ：Name_Not_Found：04/07/10 05:00 ID:???

誰が民法をマークアップしてもbody要素以下は同じになるけど、
head要素以下は個々人の個性がでておかしくない。
title要素もみんな自由に書けばいいじゃん。

title要素が省略できないのも、
「何書いてもいいんだから、何か書いてよ」って感じだよ。たぶん。

857 ：Name_Not_Found：04/07/10 10:17 ID:???

たぶん、な。

858 ：Name_Not_Found：04/07/10 12:29 ID:???

メタ情報とかいう言い方が初心者の理解を妨げてるような。

859 ：Name_Not_Found：04/07/10 13:16 ID:???

>>858
どう言ったらいいかな？

860 ：Name_Not_Found：04/07/10 13:35 ID:???

タイトルバーに表示する文字列は表示じゃないでしょうか

861 ：Name_Not_Found：04/07/10 14:35 ID:???

>>860
それはUA依存。

また、googleの検索結果などではまさに本文として扱われる。

ただ、本に例えるなら、表題なので、本文を読んでいるときに表示されて
いなくても困らない情報、ではある。

862 ：Name_Not_Found：04/07/10 14:43 ID:???

>>853
剥げ同

863 ：Name_Not_Found：04/07/10 14:47 ID:???

>>861
rdfのdc:titleと

864 ：Name_Not_Found：04/07/10 20:53 ID:???

禿同だけの書き込みは自作自演っぽくていやん。

865 ：822：04/07/10 21:14 ID:???

すみません、昨日はお騒がせしました。

あれから色々考えたところ、>>836氏のいうことが、最も適切な説明方法だと理解できました。
私の考え方は、確かに詭弁であったこと、理解できました。

titleがメタ情報、というのがいまいちピンとこなかったのです。
だったら<meta title...>とかにするんじゃないの？と思っておりましたが、
titleはhtml1.0の頃から存在し、その後metaが追加されたのですね。
非常に基本的な情報が欠落しておりました。

headは文書の情報を表す、ということは、当然描画エリアに表示されるものではなく、
現在のブラウザがtitleを表示しないのも、当たり前ですね。
titleはメタ情報の1種と考えると、ｈｎとは相関関係はない。
いえ、むしろ、titleは文書本体body内の全ての要素とテキストと等しく相関関係にあり、
ｈｎと特別の関係にはないといいえましょうか。

だから、titleとh1の記載が同一でも、特段の不都合はない、と。

あやふやな知識で物事を論じようとするのは、非常に危険なことだと身に染みました。
長々とスレ汚し申し訳ありませんでした。反省しております。

866 ：Name_Not_Found：04/07/10 21:24 ID:???

>>864
禿同

867 ：Name_Not_Found：04/07/10 21:28 ID:???

>>853
禿同

とりあえず変なショーは終わったようだから、以後いつもの寂れ加減で。

868 ：名無しさん＠そうだ選挙に行こう：04/07/11 12:08 ID:nfIyv4F8

Internet Explorer のレンダーモードはどこを見たらわかりますか？
ページが Standard になっているか確認したいです。

どこかに表示されてるはずだった気がするけど、見つからない。(´・ω・`)

869 ：名無しさん＠そうだ選挙に行こう：04/07/11 12:30 ID:???

>>868
> どこかに表示されてるはずだった気
Gecko と間違えてんじゃ？　IE にはそんなもんナイだろ。

アドレスバに直打ち（IE6 専の悪寒

javascript:alert(document.compatMode);
BackCompat -> 互換
CSS1Compat -> 標準

870 ：名無しさん＠そうだ選挙に行こう：04/07/11 12:33 ID:???

>869
なかったですか。確認できました。ありが㌧。

871 ：名無しさん＠そうだ選挙に行こう：04/07/11 16:30 ID:???

今日パソコン利用技術認定試験を受けてきた
2級問7

<h1><font color="#">庭の花</font></h1>では、見出しタグ<h1>~</h1>を用いて章立ての階層を表示している。<h1>,<h2>,<h3>…とhのあとの数値を大きく指定すると、文字サイズは[ (2) ]なる。

(2) ア:大きくイ:小さく

872 ：名無しさん＠そうだ選挙に行こう：04/07/11 16:51 ID:???

> 文字サイズは[ (2) ]なる。

この後に、

> のではなく、見出しレベルが[ (2) ]なる。

と書き加える。

873 ：名無しさん＠そうだ選挙に行こう：04/07/11 16:58 ID:???

懐かしいな、<font color="#">とか。

874 ：871：04/07/11 17:00 ID:???

<font color="#0000ff">…

色は指定してあった。
まあどうでもいいけど。

875 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:07 ID:???

(ﾟДﾟ)

876 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:23 ID:???

>>871
主催者のメアド公開汁

877 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:30 ID:???

PAT認定試験でググれ

878 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:31 ID:???

ちんちんは[ (2) ]なる。

(2) ア:大きくイ:小さく

879 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:37 ID:???

試験問題に「これはWindows版InternetExplorerの一般的な挙動に関する問題です」
って書かれていれば問題ないんだがな。

880 ：871：04/07/11 17:43 ID:???

「WEBページ作成に関する問題です」ですた

881 ：名無しさん＠そうだ選挙に行こう：04/07/11 17:46 ID:???

そうか。でもきっと言語はHTMLじゃないんだよね

882 ：名無しさん＠そうだ選挙に行こう：04/07/11 18:04 ID:???

言語はきっと謎マークアップ言語だね

883 ：名無しさん＠そうだ選挙に行こう：04/07/11 18:17 ID:???

>パソコン利用技術認定試験
であって、ウェブコンテンツ作成とか HTML の仕様とかでは
ないところがミソとか。

884 ：名無しさん＠そうだ選挙に行こう：04/07/11 18:24 ID:???

http://www.pcua.or.jp/PAT/index.html を HTML4.01 Transitional としてチェックしました。
72個のエラーがありました。このHTMLは -34点です。タグが 18種類 106組使われています。
文字コードは EUC-JP のようです。

885 ：名無しさん＠そうだ選挙に行こう：04/07/11 18:47 ID:???

HTMLで厳密な構造を記述するの無理だし意味ない。
XMLで新しい言語でも作らないと

886 ：名無しさん＠そうだ選挙に行こう：04/07/11 18:58 ID:???

HTMLはその程度の言語ですよ
その程度の言語以上のものを見出そうとする連中がいるから困ったものです

887 ：名無しさん＠そうだ選挙に行こう：04/07/11 19:02 ID:???

だからムチャクチャ書いていいって訳でもないような

888 ：名無しさん＠そうだ選挙に行こう：04/07/11 19:27 ID:???

その程度の物というなら、そもそも試験の課題にするのが間違ってる。
さらにその程度の物を理解できてない出題者のレベルも知れる。

全部解ってて「その程度の物ですよ」ってな出題ならまだ
苦笑いしたり憤慨も出来るが、今のレベルじゃ呆れるばかり。

889 ：886：04/07/11 19:36 ID:???

>>887-888
俺へのレスか？

890 ：Name_Not_Found：04/07/11 20:37 ID:???

なんかそのPAT試験の２級と１級のレベルが随分離れてないか？
１級は論文記述試験だし。

891 ：Name_Not_Found：04/07/11 22:04 ID:???

英検の1と2とかもそうじゃね

892 ：Name_Not_Found：04/07/12 02:26 ID:???

>>883
ホームページ作成検定というものがある。
<p>は<br>二つ分とか。

893 ：Name_Not_Found：04/07/12 02:27 ID:???

ひどい…ひどすぎる

894 ：Name_Not_Found：04/07/12 02:59 ID:???

W3Cが認定するとかはないのかね。国からお墨付きもらっても嬉しくない。

895 ：Name_Not_Found：04/07/12 03:09 ID:???

XMLでそれをやったらインとかフォとかテリアとかつく会社が困りそう

896 ：Name_Not_Found：04/07/12 07:08 ID:???

>ホームページ作成検定というものがある。
その「ホームページ」とはいったい以下省略

897 ：Name_Not_Found：04/07/12 09:01 ID:???

如何に速く about:blank から変えられるか、とかかね。

898 ：Name_Not_Found：04/07/12 14:22 ID:???

about:blankをホームページにする。記録0秒。

899 ：Name_Not_Found：04/07/12 16:35 ID:???

いやいや、ホームページ「設定」検定じゃなくて作成なんだから、
やっぱり自分のホームページを作 (いい加減スレ違い ry

900 ：Name_Not_Found：04/07/12 17:03 ID:???

漏れ様はgoogleと2chとその他のリンクを張っているから
記録時間は最下位になるかモナｗ

901 ：Name_Not_Found：04/07/12 23:13 ID:???

apacheインストールして、トップページ表示させて、おわり。

902 ：Name_Not_Found：04/07/13 07:36 ID:???

html 一枚書くよりは、apache のインストールの方が時間はかかりそうだな。

903 ：Name_Not_Found：04/07/13 08:40 ID:???

俺のサイト、Apache起動してないと、
ローカルで見られない。

904 ：Name_Not_Found：04/07/13 08:41 ID:???

そうですか。

905 ：Name_Not_Found：04/07/13 08:43 ID:???

まあそうだよな。「そうですか」、と言うしかないか。スレ違いだしな。
Apacheﾏﾝｾｰ

906 ：Name_Not_Found：04/07/13 14:53 ID:???

IIS最強伝説。

907 ：Name_Not_Found：04/07/14 19:36 ID:zqUtojmE

<A "href = test1 " >no_link</A>
<A " href = test2 " >link</A>
<A hh "= href = test3 >mukou_ie__no_link_n71</A>
<A hh "= href = href = test4 >no_link</A>
<A hh =" href = test5 >mukou</A>
<A hh =" href = href = test6 >no_link</A>

上記のエラーのあるタグの解釈はこれでよいのでしょうか？

1.""で囲まれていて、"の後がwhitespace(以下ws)でないのでリテラル
2."の後にwsがあるので"はスキップ、href属性になる
3."の後に=があるのに"で閉じていないので無効(IEはテキストも無効に)
4."の後に=があるのに"で閉じていないので無効
5.hh ="のrValueが"で始まってるのに閉じてないので無効(IEはテキストも無効)
6.hh ="のrValueが"で始まってるのに閉じてないので無効

908 ：Name_Not_Found：04/07/14 20:22 ID:???

>>907
スレ違い。

909 ：Name_Not_Found：04/07/14 21:28 ID:???

>>907
HTMLのつもりであれば、

><A "href = test1 " >no_link</A>
><A " href = test2 " >link</A>

属性名の省略とみなそうとする
<A "href = test1 "="href = test1 ">
が、属性値に区切り子が使われているので不正

><A hh "= href = test3 >mukou_ie__no_link_n71</A>
><A hh "= href = href = test4 >no_link</A>

hhは属性名の省略とみなす
<A hh=hh>
が、次の属性"= href = test3 ... でlitがないので、属性値が終了しない。

><A hh =" href = test5 >mukou</A>
><A hh =" href = href = test6 >no_link</A>

<A hh="...">とみなそうとするが、これもlitがないので、属性値が終了しない。

910 ：Name_Not_Found：04/07/14 21:36 ID:???

エラーのあるHTML文書をどう補正して解釈するかは定められていない。
特定のブラウザの挙動を知りたいのならそのスレへ。

911 ：907：04/07/14 23:31 ID:???

>>908-910
ありがとうございました。

912 ：Name_Not_Found：04/07/15 18:57 ID:???

>>911
SGMLの仕様を読むのが良いかと。
XHTMLではエラーが決まっているので、エラーについてめんどくさい場合はapplication/xhtml+xmlでXHTMLを使うことをお勧めします。

913 ：Name_Not_Found：04/07/16 19:41 ID:???

あぁ、いつかの平穏なstrictスレに戻った。

914 ：Name_Not_Found：04/07/16 19:44 ID:???

>>911
ちなみに、深い世界を見たいのでなければ…、というか手段としてWebで
発表する文書の文法を憶えたいだけなのであれば、SGMLよりXMLの勉強を
お薦めする。SGMLは短縮命令とか、閉じないタグの処理とか、NET区切り子とか
首突っ込むとかなり深い世界に連れて行かれる。

ちなみにXMLの場合も、最初は（ゆくゆくは憶える必要があるけど）名前空間は
気にしないで憶える事を推奨。単一のスキーマだけを使う分には「これは呪文だ」
と思っていても余り困らないので。

915 ：Name_Not_Found：04/07/16 21:22 ID:???

SGMLって将来性無いのかな（゜・ω・゜）

916 ：Name_Not_Found：04/07/16 21:38 ID:???

省略形云々で無意味に巨大化しすぎてるし、そのせいで拡張も不自由。だからこれからはXMLにとって代わられるんじゃないかな

917 ：Name_Not_Found：04/07/16 21:52 ID:???

ある意味親殺しか

918 ：Name_Not_Found：04/07/16 23:04 ID:???

...でもXMLも当初に比べたらなーんか大きくなっちゃったよなぁ。

919 ：Name_Not_Found：04/07/16 23:10 ID:???

それぞれが自分の欲しい機能を主張するからね。

920 ：Name_Not_Found：04/07/17 00:11 ID:???

>>917
それを親殺しというならほぼ全てのヴァージョンアップは親殺しだな。

>>918-919
ややこしい話はそれぞれの名前空間に任せて、ツンプルなXMLは
ツンプルで居てくれないかなぁ。

921 ：Name_Not_Found：04/07/17 00:13 ID:???

で、しっかり煩雑になったところで新メタ言語の発表ですよ。

922 ：Name_Not_Found：04/07/17 02:40 ID:???

MHTML？

923 ：Name_Not_Found：04/07/17 02:47 ID:???

>>1さーん

924 ：Name_Not_Found：04/07/17 09:30 ID:???

>>922
なんでメタ言語がHTMLなんだよｗ

925 ：Name_Not_Found：04/07/17 18:44 ID:???

>>922
RDFでしょ

926 ：Name_Not_Found：04/07/17 20:53 ID:???

MHTMLってあれだよね。MSの。

927 ：Name_Not_Found：04/07/17 21:02 ID:???

<div id="banner">
サイトタイトル
</div>

とかやる場合は
<div id="banner">
<h1>サイトタイトル</h1>
</div>
にしないほうがいいでしょうか？

<p>か<div>なんかで囲っといたほうがいいですか？

928 ：Name_Not_Found：04/07/17 21:15 ID:???

>>926
http://pc5.2ch.net/test/read.cgi/hp/1018053359/118

こっちでしょ

929 ：Name_Not_Found：04/07/17 21:19 ID:???

>>927
情報少なすぎ。

サイトのトップページの場合はサイトタイトルをh1にしておくのは常套手段だが
メインコンテンツでh1にするのはコンテンツのタイトル。

Strict DTDを使っているのであればBODY直下にインライン要素を置けないので
適当なブロック要素を見繕う。

930 ：Name_Not_Found：04/07/17 21:25 ID:???

http://www.kanzaki.com/
ぶっちゃけ↑のみたいにしたいんだけど、
<div id="banner"></div>の中に使う画像がないのでテキストでやる場合は何かで囲ったらいいのかなと思いました。

それとインデックスページのbannerの中にh1使わずサイトタイトル入れた場合に下にh1でまた同じこと書くのもなんか嫌だし
↑のみたいに画像もないんですけど、ようこそ的なこと書いたらいいでしょうか？

931 ：Name_Not_Found：04/07/17 21:40 ID:???

■インデックス
<div id="banner">
<h1 class="sitetitle">サイトタイトル</h1>
</div>

■その他
<div id="banner">
<p class="sitetitle">サイトタイトル</p>
</div>

こんな感じでいいでしょうか？

932 ：Name_Not_Found：04/07/17 21:59 ID:???

<h1 id="SITETITLE">サイトタイトル</h1>
これだけで。

933 ：Name_Not_Found：04/07/17 22:09 ID:???

>>932
その場合もし別のページでドラえもんについて書いていたとしたら。

<h1 id="SITETITLE">サイトタイトル</h1>
<h2>ドラえもんについて</h2>

ってなことになるわけですよね。

934 ：Name_Not_Found：04/07/17 22:13 ID:???

全容が見えないのだけど、
index : <h1>サイトタイトル</h1>
その他 : <p id="sitetitle">サイトタイトル</p>
と言う案を挙げとく。
飽くまでもサイトタイトルであると言う認識なら、indexのh1にもidを振っても良いかもしれない。

935 ：Name_Not_Found：04/07/17 22:26 ID:???

>>934
http://www.kanzaki.com/で全部のページの一番上にある

[the web kanzaki]←これ画像 Japan, Music, Internet & Computer

ってなってるところの [the web kanzaki] が画像じゃなくてテキストでサイトタイトルになっていた場合に
pかdivかh1か何もつけないかっていうのを知りたかったんです。

それでもしこの中がh1以外だったらインデックスページのh1には何を書いたらいいのかなと思いました。
http://www.kanzaki.com/ではなんか変なおっさんが楽器弾いてる画像ですね。

もしh1だったら他のページの一番の見出しはh2になるんでしょうかっていうことも考えて。
そんな感じです。

936 ：934：04/07/17 23:06 ID:???

色々書いてたら、まとめきれずにごちゃごちゃしたので消した。
で、

＞ってなってるところの [the web kanzaki] が画像じゃなくてテキストでサイトタイトルになっていた場合に
＞pかdivかh1か何もつけないかっていうのを知りたかったんです。
自分だったら、<p id="sitetitile">The Web KANZAKI</p>。

＞それでもしこの中がh1以外だったらインデックスページのh1には何を書いたらいいのかなと思いました。
＞http://www.kanzaki.com/ではなんか変なおっさんが楽器弾いてる画像ですね。
画像は仮の姿。alt属性を見るべし。その画像のaltの値は"Welcome to The Web KANZAKI"。
すなわち、<h1>Welcome to The Web KANZAKI</h1>。

で、>>934の案に戻るんだけど、indexだと<p id="sitetitle">と<h1>とで、サイトタイトルを2回連呼する事になるので、
indexのみ、<p id="sitetitle">を記述しない。と言うところか。(The Web KANZAKI的には連呼してるんだけど)

どちらにせよ、サイトタイトルは飽くまで<p id="sitetitle">。
各ページのh1は、それぞれに適切な内容にするべき(常にh1がサイトタイトルなのはおかしい)だと思う。

937 ：Name_Not_Found：04/07/17 23:16 ID:???

>>936
oh!アリガトウゴザイマシター

938 ：NAME_Not_Found：04/07/18 02:07 ID:???

たとえば 932 はこうした展開になってしまったことをどう思ってるの？

939 ：Name_Not_Found：04/07/18 07:26 ID:???

良いじゃない。夏だもの。