Strict-HTML スレッド21

1 ：Name_Not_Found：04/07/19 14:52 ID:???

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

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

2 ：ura2ch：04/07/19 14:53 ID:???

strict strict

3 ：Name_Not_Found：04/07/19 14:53 ID:???

4 ：Name_Not_Found：04/07/19 14:55 ID:???

■関連スレ
/* CSS･スタイルシート質問スレッド【33】 */ http://pc5.2ch.net/test/read.cgi/hp/1089975931/、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
W3C信者にサイトを正しい記述に直して貰うスレ3 http://pc5.2ch.net/test/read.cgi/hp/1061741473/
ユーザビリティ専用スレ　その２ http://pc5.2ch.net/test/read.cgi/hp/1020575673
【野望の】XHTML 2.0【王国】 http://pc5.2ch.net/test/read.cgi/hp/1028659057
XML使いのスレ 2.0 http://pc5.2ch.net/test/read.cgi/hp/1057198990

■勧告等
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

5 ：Name_Not_Found：04/07/19 15:01 ID:???

■関連スレ訂正

/* CSS･スタイルシート質問スレッド【33】 */ http://pc5.2ch.net/test/read.cgi/hp/1089975931/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html

ユーザビリティ専用スレ　その２ http://pc5.2ch.net/test/read.cgi/hp/1020575673/
【野望の】XHTML 2.0【王国】 http://pc5.2ch.net/test/read.cgi/hp/1028659057/
XML使いのスレ 2.0 http://pc5.2ch.net/test/read.cgi/hp/1057198990/
XSL/XSLT http://pc5.2ch.net/test/read.cgi/php/999654569/

6 ：Name_Not_Found：04/07/19 15:02 ID:???

>>1
乙カレ

早速質問なんだけど<br>って例えば<address>内で改行したいときなどに使うのは問題無し？

7 ：Name_Not_Found：04/07/19 15:06 ID:sa8p41fu

>>1
乙

>>6
>早速質問なんだけど
スレ間違えてないか？　ま、問題無しだと思うがな。

8 ：Name_Not_Found：04/07/19 15:31 ID:???

>>6
問題あり

9 ：Name_Not_Found：04/07/19 16:08 ID:???

Strict-HTMLでは問題あるか無いかを聞いてるんじゃね？

10 ：Name_Not_Found：04/07/19 16:10 ID:???

>>6
問題なし。<address>でマークアップしてるならそれ以上マークアップする必要ないよね？
たとえばその中にメールアドレスとか会社名とか書いてくと
見た目では一行につながって見にくい。
かといって改行させるという見た目の為だけに一つ一つを<span>なんかで囲んだりするのはナンセンス。
素直に<br>で見やすくしてやればいい。

11 ：Name_Not_Found：04/07/19 16:15 ID:???

>>10
わーい　わーい

12 ：Name_Not_Found：04/07/19 17:00 ID:???

addressの子にpreが使えたら一発解決

13 ：Name_Not_Found：04/07/19 17:03 ID:???

>>12
スタイルであるよ

14 ：Name_Not_Found：04/07/19 18:27 ID:???

>>13
CSSで「white-space:pre」を使うのは、何か違う気がする。
address要素は同一HTML文書内で何回でも使えるんだから；

<div>
<address id="mail-to-author">[email protected]</address>
<address id="copyright">copyright © 2004 FooBar All right reserved.</address>
</div>

でもいいんじゃないか。

15 ：Name_Not_Found：04/07/19 18:38 ID:???

>>14
まずお決まりのdivにつっこみを(`･ω･´)

んでもって<address>は文書作者の情報、連絡先や更新日時をなどを印付けするもの。
書物でいったら奥付だな。
だからわざわざまとめて書けるものを分ける必要がない。
音声ブラウザなんかで文書情報にぱっと飛ぶときなんか
一つ目のアドレス再生するとメールアドレスしか聞こえない、なんてことになると問題でしょう。
<address>を同一ＨＴＭＬ内に何度でも書けるのは当然だけど
それはとても長い文章等の合間、合間に書いてやるべきであって
その場合どの<address>からでも完全な文書情報を得られる様にするべきでは。

16 ：Name_Not_Found：04/07/19 19:14 ID:???

>>14
俺はそうしてるよ

17 ：Name_Not_Found：04/07/19 20:29 ID:???

前スレ埋まったね・・・

18 ：Name_Not_Found：04/07/19 20:52 ID:???

>15
そういうなら、>6の質問へのおまいなりの答えを出してくれ

19 ：Name_Not_Found：04/07/19 20:56 ID:???

ようするに>>10でＦＡだろ。
ユニバーサルＨＴＭＬ／ＸＨＴＭＬでもそうやってる。

20 ：Name_Not_Found：04/07/19 21:03 ID:???

copyrightはaddressに含んでいいのか？

21 ：Name_Not_Found：04/07/19 21:06 ID:???

もちろんおｋ。
あと<addres>の中にはインライン要素しか使えないから<pre>も<p>もだめ。

22 ：Name_Not_Found：04/07/19 21:21 ID:???

ふたつくらい前のスレでは含まないってことになってた気がする

23 ：Name_Not_Found：04/07/19 21:37 ID:???

w3cはcopyright分けて書いてるね。
見てきたら<p class="copyright">だってさ。

24 ：Name_Not_Found：04/07/19 21:39 ID:???

>>23
W3Cってh1が複数ある文書を平気で公開していたり
一時期はトップがテーブルレイアウトだったり
そんなにStrict派じゃないよね

25 ：Name_Not_Found：04/07/19 21:43 ID:???

>>24
h1が複数ある文書はStrictに影響ないと思うのだが。

26 ：Name_Not_Found：04/07/19 22:10 ID:???

h1が複数あるのは別におかしくない。
hnに関しては前スレあたりでも似たような議論なかったっけ？

27 ：Name_Not_Found：04/07/19 22:34 ID:???

疑問で返されても...

28 ：Name_Not_Found：04/07/19 22:38 ID:???

へぇ～H1って１回以上使ってもいいんだ。
たまに使いたくなるんだよね。今後は使っていこうかな。

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

>>26
あった。

30 ：Name_Not_Found：04/07/19 23:13 ID:???

>>28
仕様書ぐらい読もうね＾＾

31 ：Name_Not_Found：04/07/19 23:44 ID:???

>>30
日本語を勉強しようね。この場合は「ぐらい」ではおかしいよ^^

32 ：Name_Not_Found：04/07/19 23:56 ID:???

くらい　くらゐ

（副助）
〔名詞「くらい（位）」からの転。中世以後生じたもの。「ぐらい」の形でも用いる〕体言および活用する語の連体形に付く。

(2)ある事柄を示し、その程度が軽いもの、弱いものとして表す。
「酒―飲んだっていいよ」「ご飯―たけるよ」

33 ：Name_Not_Found：04/07/20 00:01 ID:???

>>28は一回以上～と言っている
さて

34 ：Name_Not_Found：04/07/20 00:01 ID:???

他にも読むべきものがあるのなら「ぐらい」を用いても適切
そうでない場合「最低限」を意味する「ぐらい」であれば適切

「ぐらい」が適切でないのは仕様書が至上命題である場合

35 ：Name_Not_Found：04/07/20 00:04 ID:???

>>33
仕様書は (%block;|SCRIPT)+ と言っている。
さて

36 ：Name_Not_Found：04/07/20 00:48 ID:???

日本語の不自然な使い方する人とかが多いスレですね＾＾
日本語ぐらい最低限ちゃんと使っていただきませんとstrictとかなんて語ってはいられませんよ＾＾；

37 ：Name_Not_Found：04/07/20 00:51 ID:???

>>36
君の文章、特に２行目も日本語として不自然。

38 ：Name_Not_Found：04/07/20 00:52 ID:???

>>36

39 ：Name_Not_Found：04/07/20 00:54 ID:???

無駄な荒らし・煽りはスルーで

40 ：Name_Not_Found：04/07/20 01:08 ID:???

^^なんて2chで使うのは山（ｒｙくらいしか無いんだから釣り確定。クマー

41 ：Name_Not_Found：04/07/20 01:19 ID:???

>>36
> 日本語の不自然な使い方する人とかが多いスレですね＾＾
日本語の不自然な使い方する人ですね＾＾

不自然な日本語の使い方をする人が多いスレですね、じゃないかな

42 ：Name_Not_Found：04/07/20 01:28 ID:???

>>34
仕様書読めばHTMLについては完璧に理解できるはず。
というかこれ読んで理解できない、何読んでも無理。
仕様書以上はないので「ぐらい」ではおかしいと思う。

まるで仕様書の後にもっと凄いものが待ってるかのようだ。ちょっと見てみたいぞ^^

43 ：Name_Not_Found：04/07/20 01:33 ID:???

とほほのwww入門見れば充分だい！

44 ：Name_Not_Found：04/07/20 01:44 ID:???

最近話題のJIS X 8341-3でもおすすめします。

45 ：Name_Not_Found：04/07/20 07:45 ID:???

JIS X 8341-3 ウェブコンテンツJIS
http://pc5.2ch.net/test/read.cgi/hp/1087746643/

46 ：Name_Not_Found：04/07/20 09:19 ID:???

W3Cは結構Strictじゃないよ
br要素が沢山出てきたりして萎える。

47 ：Name_Not_Found：04/07/20 09:31 ID:???

W3Cはこのスレの住人みたいにHTMLに何もかもを求めてはいないから。

48 ：Name_Not_Found：04/07/20 10:26 ID:???

「W3Cはこのスレの住人みたいに」「HTMLに何もかもを求めてはいない」から。
「W3Cは」「このスレの住人みたいにHTMLに何もかもを求めて」はいないから。

どっち？　どっちでもいいけど

49 ：Name_Not_Found：04/07/20 10:34 ID:???

>>48
意味がわからん。

50 ：Name_Not_Found：04/07/20 11:23 ID:???

・W3Cはこのスレの住人（と同様に）HTMLに何もかもを求めてはいないから。
・W3Cはこのスレの住人（とちがって）HTMLに何もかもを求めてはいないから。
のどっちとも読めるってことでしょ。

51 ：Name_Not_Found：04/07/20 11:39 ID:???

どうでもいい

52 ：Name_Not_Found：04/07/20 11:39 ID:???

よくきたすとりくと、わしがおうのなかのおう
りゅうおうの　ひまごじゃ。

53 ：Name_Not_Found：04/07/20 14:08 ID:???

>>50
普通、上の解釈はしないと思うが。

54 ：Name_Not_Found：04/07/20 14:30 ID:???

2chで普通とか言われましても。

55 ：Name_Not_Found：04/07/20 14:38 ID:???

ハァ？何言ってるの？

56 ：Name_Not_Found：04/07/20 14:42 ID:???

>>54
お前の考えの逆って事だ。分かるか?

57 ：Name_Not_Found：04/07/20 14:52 ID:???

喪前ら、夏厨に付き合うなんて優しいな。

58 ：Name_Not_Found：04/07/20 15:27 ID:???

ストリクター放置やスルーは学ばない

59 ：Name_Not_Found：04/07/20 15:42 ID:???

W3CにあるCSS2.1の仕様書のURIって
http://www.w3.org/TR/CSS21
じゃん。
バージョンナンバーが2ケタいったらどうするつもりなんだろう？

60 ：Name_Not_Found：04/07/20 15:53 ID:???

そのころにはWWWはもうない

61 ：Name_Not_Found：04/07/20 15:56 ID:???

CSSの名前を変えればいいじゃん

62 ：Name_Not_Found：04/07/20 15:59 ID:???

XCSSとか？

63 ：Name_Not_Found：04/07/20 16:08 ID:???

CSS X(テン)になる。

64 ：Name_Not_Found：04/07/20 16:20 ID:???

CSSがそこまで改版・レベル分化が必要になるほどの糞仕様になったら
CSS9のあとはCSS9.1, CSS9.2, ..., CSS9.9, CSS9.9.1, CSS9.9.2, ...,
CSS9.9.9, CSS9.9.9.1, CSS9.9.9.2, ... と続くだろうな。
尤もその頃にはCSSよりも新しい枠組みが出てきてCSS自体が陳腐化してそうだが。

65 ：Name_Not_Found：04/07/20 16:44 ID:???

他の規格も同じような名付け方だな。

66 ：Name_Not_Found：04/07/20 16:45 ID:???

>>64
スレ違いだがJavaの状況を思い起こすね
Java2.0 を Java2 と呼ぶと混乱するからな
一気にJava3.0も逝くのかしらん

67 ：Name_Not_Found：04/07/20 16:46 ID:???

Java5じゃないっけ？

68 ：Name_Not_Found：04/07/20 16:47 ID:???

J2SE 5.0
ttp://www.sun.com/smi/Press/sunflash/2004-06/sunflash.20040628.3.htm

69 ：Name_Not_Found：04/07/20 16:53 ID:???

>>67
それって実はJava1.5のことだよね。
んで昔、Java1.1→Java1.2の変更が特に大きかったため、
Java1.2以降をJava2と呼ぶことがあった。
Java1.5以降でバージョンアップが続いてJava2.0になると・・・
ってことなんだが。
（Java1.5も変更が大きいのでグレードアップしてJava2.0になるという噂もあったな。）

いやスレ違いｽﾏｿ

70 ：Name_Not_Found：04/07/20 17:26 ID:???

つーかピリオド区切りのデータと思えば、x.9の次をx.9.1にせず、
x.10にすりゃいいだけなんでは。数学的な小数点ではないんだから。

71 ：Name_Not_Found：04/07/20 19:53 ID:???

でも最初にやった人は「変更具合が1/10くらいだ」っていう気分を表そうとして2.1とかやったんだよね。多分。

72 ：Name_Not_Found：04/07/20 20:32 ID:???

>>58
ﾜﾗﾀ

73 ：Name_Not_Found：04/07/20 21:16 ID:???

ここの中の人って結構流動的だからな。
中身変わって既出の話題

74 ：もの申す：04/07/20 21:33 ID:???

必死にユーザビリティ・アクセシビリティを考慮したサイトを作ってるんだけど
マジで無理ぽ・・・
HTML4.01Strict+CSSでやってるけど、実装の問題じゃなくて仕様自体がおかしい気がしてきた。

<div id=main>
<h1><img src="" width=400 height=300 alt="ようこそ！"></h1>
<p>今日はうんたらかんたら、明日もうんたらかんたら</p>
</div>

#main{
border-width:1px;
border-style:solid;
border-color:#000;
width:700px;
}
#main h1{
width:400px;
height:300px;
float:left;
}
#main p{
width:300px;
float:left;
}

75 ：もの申す：04/07/20 21:34 ID:???

こんな感じにしたいが、ボックスの中でfloatするとボックスのボーダーが仕様通りなら
widthは指定してるから問題ないけど、heightは指定してないので、img（h1）の大きさではなくて、
pのheightになってしまう。それもfloatした位置からの・・・・だからボーダーがとんでもないことになる。

divにheightを指定してしまうと中の文字をユーザが大きくしたときに、ボーダが対応しない。
W3Cってしょぼくない？代替法はあるけど、それはValidなやり方ではない。
ブラウザの実装が悪いんじゃなくて、仕様自体がだめじゃん。

ボックスの中身にfloat指定するとボックスのheightが変なことになるのが仕様通りってマジアフォ

76 ：Name_Not_Found：04/07/20 21:43 ID:???

ボックス要素のheightの値を指定しない場合に、どうやって値が算出されるかってことか？

っていうかそんなこと言ったらwidthだって指定しちゃ駄目だろ。幅固定は良くない。
しかしそんなことで、自由なレイアウトができるかというと無理！
適当に妥協しろってことだよ。まああまり堅く考えるなよ。

77 ：Name_Not_Found：04/07/20 21:48 ID:???

確かそれについてはIEの方が正しいはず。通常指定しなくても内容の高さで自動で決まる。

でもfloatが絡むと、文字の行の高さ？だけが計算されて他のものは完全に計算されないのが仕様だったかな。
floatさせなければいいんじゃないか？

78 ：もの申す：04/07/20 21:51 ID:???

>>76-77
そんな後ろ向きな発想は悲しい・・・
弱視でも、全盲でも、ロボットでも、健常者でも楽しめるサイトを作りたいんだよorz

79 ：Name_Not_Found：04/07/20 21:55 ID:???

とりあえず文法が正しくて
lynxとかw3mで見られれば問題ないかと

80 ：Name_Not_Found：04/07/20 21:59 ID:???

ええ、CSSの問題はこのスレでは扱えません。

81 ：もの申す：04/07/20 22:02 ID:???

>>80
CSSの問題ではない気が・・？
CSSの実装の問題ではないですが、確かにCSSの仕様の問題はスレ違いでしたねorz
もういいや・・・CSSスレに同じ事を書くのは荒らしみたいで嫌だし
なんか鬱だな。なにがコンソーシアムだバカヤロー・・・

82 ：Name_Not_Found：04/07/20 22:08 ID:???

display:inline-block;
が使えれば解決ですよ
Operaしか実装してませんが

83 ：Name_Not_Found：04/07/20 22:14 ID:???

努力や知識の足りないことを策定団体の仕様の所為にするな。

84 ：Name_Not_Found：04/07/20 22:17 ID:???

<div id=main>
<h1><img src="" width=400 height=300 alt="ようこそ！"></h1>
<p>今日はうんたらかんたら、明日もうんたらかんたら</p>
<br style="clear: both;">
</div>

ってﾀﾞﾒ？

85 ：Name_Not_Found：04/07/20 22:21 ID:???

>>84
漏れ、hr でやってるー

86 ：Name_Not_Found：04/07/20 22:22 ID:???

>>81
floatがああいう仕様なのはこういう配置が目的だから。
http://www.w3.org/TR/CSS21/images/float2p.png

87 ：もの申す：04/07/20 22:24 ID:???

>>83
実装の話ではありません。

>>84
ありがとうございます。その代替方法は知っていますが、Validでなくなってしまうのが痛いところです；

88 ：Name_Not_Found：04/07/20 22:26 ID:???

strict ではないが、valid でなくはないのでは？

89 ：Name_Not_Found：04/07/20 22:27 ID:???

努力や知識の足りない、ってところは事実のようだな。

90 ：もの申す：04/07/20 22:28 ID:???

>>86
ありがとうございます。
floatに限らず基本的にボックス要素内で段組をする時に、ボックス要素の中身の高さ（ユーザの文字設定による可変長）に応じて
自動で外のボックス要素の高さが変わるという仕様にならない限り無理ぽです。

91 ：Name_Not_Found：04/07/20 22:28 ID:???

Validなままでもお前の望むような表示方法はいくらでもあるし、
弱視でも全盲でもロボットでも健常でも楽しめるよう配慮することはできる。
その代替案がいくらでもごろごろとしているというのに、
単一のHTMLファイルのみで目的が果たせないから「W3Cのバカヤロー」？
おめでたいやつだなお前は。

92 ：もの申す：04/07/20 22:29 ID:???

>>88
HTML4.01Strictで書いてるのでValidとはHTML4.01Strictの仕様と意向に沿ったものだと思っています。

>>89
具体論なしみたいですが、ただの煽りですか？

93 ：Name_Not_Found：04/07/20 22:31 ID:???

>HTML4.01Strictで書いてるのでValidとはHTML4.01Strictの仕様と意向に沿ったものだ

そりゃお前さんの独自拡張だ。
他人に説明するときはせめて脳内用語使うのやめれ。

94 ：もの申す：04/07/20 22:31 ID:???

>>91
仕様に沿った記述の仕方の例を言ってみてください。ブラウザの実装で正常にならない、又は
実装の不備を利用した代替方法はくそ食らえです。

95 ：もの申す：04/07/20 22:33 ID:???

>>93
ではあなたの正しいと思っているValidの意味を説明してください。
私はHTML4.01のValidと他のバージョンでのValidはそれぞれ別であると思っています。

あなたはバージョンがなんであれValidなHTMLに差がないと思っているのですか？

96 ：もの申す：04/07/20 22:34 ID:???

>>94
ちょっと間違えました。ブラウザの実装はどうでもいいのです。
仕様として可能であるならそれでいいのです。仕様として可能でないから暴言を吐いちゃいました。

97 ：Name_Not_Found：04/07/20 22:36 ID:???

98 ：Name_Not_Found：04/07/20 22:38 ID:???

なんかよくわからんが、見栄えのために<br>入れるのがvalidだとは俺は思わないけどなぁ

99 ：Name_Not_Found：04/07/20 22:38 ID:???

>>95
漏れ >>93 じゃなくて、>>88 なんだけど。例えば

<body>
<div>
てへ♪
</div>
</body>

って書いても valid だけど、strict 思考じゃない、よね。
このスレ（はまだ浅いから前スレとか）見てみるとわかると思うけど、
ここの人たちは、ある意味ティムたんよりも strict 思考だったりするから。

--

関係ないけどティムたんナイトになったね。

100 ：Name_Not_Found：04/07/20 22:40 ID:???

>>95
>ではあなたの正しいと思っているValidの意味を説明してください。

「俺が思う」「お前が思う」ではない。ValidはValid。それ以外の意味はない。
StrictはStrict。ValidはValid。なんのために別の単語があると思ってんだ？

>私はHTML4.01のValidと他のバージョンでのValidはそれぞれ別であると思っています。

脳内でどう解釈してようが構わんが、外に出てそれ使ったら混乱招くことは容易に想像できるだろ。
毎回そこで俺様ルール押し付けるつもりならまぁそれでも構わんが、逆切れして暴れたりすんなよ。

>あなたはバージョンがなんであれValidなHTMLに差がないと思っているのですか？

「俺が思う」「お前が思う」では（ry

101 ：Name_Not_Found：04/07/20 22:44 ID:???

てぃむたんがknightに？
功績からしたら当然かもな

102 ：もの申す：04/07/20 22:44 ID:???

>>100
で、結局Validを何だと思ってるのかはコメントなしですか。
煽りはやめてください。

103 ：Name_Not_Found：04/07/20 22:51 ID:???

>>102
おれは１００じゃないが、ＶＡＬＩＤってのは正しいマークアップで、ＳＴＲＩＣＴってのはただの仕様だろ？別に表題をＰでマークアップしてもｓｔｒｉｃｔ。でもＶＡＬＩＤではない。だからＶＡＬＩＤとＳＴＲＩＣＴは違うってことだと思うが間違ってるのか？

104 ：Name_Not_Found：04/07/20 22:52 ID:???

ホームラン級のバカばっかだな

105 ：Name_Not_Found：04/07/20 22:52 ID:???

>>103
釣りはやめてよ。

106 ：１０３：04/07/20 22:53 ID:???

>>1045
違うの？じゃ白根。

107 ：Name_Not_Found：04/07/20 22:56 ID:???

>>102
だから思うとか思わないとかの話じゃないっつってんのに。日本語読めてるかね？

108 ：Name_Not_Found：04/07/20 22:58 ID:???

valid
http://dictionary.goo.ne.jp/search.php?MT=valid&kind=ej&mode=0&ej.x=0&ej.y=0
strict
http://dictionary.goo.ne.jp/search.php?MT=strict&kind=ej&mode=0&ej.x=0&ej.y=0

109 ：もの申す：04/07/20 22:58 ID:???

>>107
煽りはいいから、全世界共通のValidの意味を言ってください。

110 ：Name_Not_Found：04/07/20 22:58 ID:???

実際問題二人の間で解釈に違いが生じてるんだから、
どちらがおかしいか判断するには両者が自分の解釈を表明しないと判断しようがない。

111 ：Name_Not_Found：04/07/20 22:59 ID:???

>>108
そりゃただの単語でしょ。

112 ：もの申す：04/07/20 23:00 ID:???

>>108
それでいいんですか？それだと私が正しくなりますよ？
Validは仕様に基づき正当なマークアップをされたHTMLってことになりますので、
バージョンによってValidの基準は変わります。

113 ：もの申す：04/07/20 23:01 ID:???

>>110
私は既に表明しています。

114 ：110：04/07/20 23:03 ID:???

>>113
俺は部外者。紛らわしくてすまん。

115 ：108：04/07/20 23:07 ID:???

>>111
ただの単語についてあーだこーだ言ってるんじゃないんですか？

116 ：Name_Not_Found：04/07/20 23:07 ID:???

はぁ・・・・validすらわかっていないなんて・・・・・アフォだなぁ
このスレも終わったな

117 ：Name_Not_Found：04/07/20 23:08 ID:???

基準は変わらないだろ。
程度に差は生じるが、仕様に準じるという意味で同じ基準。

118 ：Name_Not_Found：04/07/20 23:09 ID:???

Strict と Valid の違いもわからんアホは半年ロムってろ

119 ：もの申す：04/07/20 23:09 ID:???

>>116
>>107さんですか？正しい解釈を教えていただけないでしょうか？お願いします。

120 ：Name_Not_Found：04/07/20 23:09 ID:???

煽りしか能のない奴は一生ロムってりゃいいんだろうけどな。

121 ：Name_Not_Found：04/07/20 23:10 ID:???

前スレ一応保存しますた。必要かな？
http://2ch.kyoso.net/strict20.html

122 ：Name_Not_Found：04/07/20 23:11 ID:???

皆さん、どうか放置してください。

123 ：Name_Not_Found：04/07/20 23:11 ID:???

#main:after{content:'';display:block;clear:both}

124 ：もの申す：04/07/20 23:12 ID:???

>>117
どうして基準がかわらないんですか？
だってHTML4.01Strictでは<br clear=all>なんてものは定義されていませんよ？
バージョンによって定義内容がかわるんですから、当然Valid＝正当なマークアップも
変わりますよ。

私はValidとはバージョンの仕様に従って、正当なマークアップをしているHTMLだと思っていますが
私の勘違いですか？イマイチ具体的に教えてくれる人が現れないの、みなさんバラバラな解釈をされてるような
感じがします。どうなのでしょうか？

125 ：Name_Not_Found：04/07/20 23:17 ID:???

validはHTMLとして正当かどうかってことだろ。
だからvalidでも不思議マークアップというのはあり得る。
strictは、このスレにおいての意味で行けば、
strictでかつ不思議マークアップというのは無い。
strictは物理マークアップを極力廃し論理マークアップに徹するということ。
悩ましくあってもアクセシビリティ、ユーザビリティも考慮に入れていくと

126 ：Name_Not_Found：04/07/20 23:21 ID:???

>>124
仕様書が変われば内容が変わるのは当たり前。
Valid という概念自体には「どう記述するか？」は関係ない。それは仕様書が決めること。
Valid であるということは仕様書に準じているという、それ *だけ* のこと。

Transitional な仕様で Valid であることと Strict な仕様で Valid であることで記述結果が変わろうと、
どちらも Valid という概念自身は「仕様に沿っている」ことのみ。
仕様に沿っていても不思議マークアップは可能であり、その場合 Strict とは呼べない。

Another-HTML Lint で満点取ったら Valid かも知れんが Strict であるとは限らん。
Strict = Valid と勘違いしてるお前が叩かれているのはこの辺理解してないからだと思われ。

127 ：Name_Not_Found：04/07/20 23:24 ID:???

頭の悪い誰かに具体例を示すテスト

<div id="h1">ぼくのホームページへようこそ！</div>
<div class="paragraph">ここはぼくのホームページです！</p>

上記の例は文法違反を犯していないので Valid であると言える。

<h1>ぼくのホームページへようこそ！</h1>
<p>ここはぼくのホームページです！</p>

上記の例は文法違反がなく、より適切にマークアップされているので Strict に近い。

128 ：もの申す：04/07/20 23:26 ID:???

>>125
>validはHTMLとして正当かどうかってことだろ。
HTMLとして正当化どうかなんて、どのバージョンのHTMLと照らし合わせるかによって
変わってきますよ？

>だからvalidでも不思議マークアップというのはあり得る。
そのバージョンで定義されてるタグだけを使うことをValidなHTMLであるというわけですね。

Valid ＝バージョンごとの決められたタグだけを使っているもの
Strict＝Validでかつ論理的なマークアップ

でいいですね？あんまり私のはじめに言っていたのとかわりませんね。
やっぱりただの煽りだったんですね。

129 ：Name_Not_Found：04/07/20 23:27 ID:???

>>127
横やりで悪いんだが上の例、文法違反犯してる。

130 ：Name_Not_Found：04/07/20 23:28 ID:???

そういえばそろそろ夏休みなのかな。

131 ：Name_Not_Found：04/07/20 23:28 ID:???

>92
>HTML4.01Strictで書いてるのでValidとはHTML4.01Strictの仕様と意向に沿ったものだ

>128
>Valid ＝バージョンごとの決められたタグだけを使っているもの
>Strict＝Validでかつ論理的なマークアップ

どこが一緒なんだよｗ

132 ：127：04/07/20 23:29 ID:???

>>129
不思議マークアップしようとしたら体が拒否したらしい

133 ：もの申す：04/07/20 23:30 ID:???

>>126-127
どうもです。読み返していたら

>HTML4.01Strictで書いてるのでValidとはHTML4.01Strictの仕様と意向に沿ったものだと思っています。

この私の発言は間違っていましたね。なんか煽りばかりで疲れました。

134 ：Name_Not_Found：04/07/20 23:31 ID:???

>>132
わかるよ、その感覚(`･ω･´)

135 ：Name_Not_Found：04/07/20 23:32 ID:???

>>133
煽られたのはお前が自分の発言見直しもしないからだろ？
変な指摘されたと思ったら自分の発言を見直せ。
それもせずに「煽りはやめてください」しか言わないんなら電波と思われて当然。

136 ：もの申す：04/07/20 23:33 ID:???

>>131
そうですね。途中あなたのように正しい人じゃなくて、変な煽りが
ValidとStrictは関係ないなんて勘違いしやすい言い方をするもんだから
なんかもっと間違ってると思いました。

Strictって言葉を流れ的にHTML4.01Strictって意味で受け取ったもんで。

137 ：もの申す：04/07/20 23:35 ID:???

>>135
っていうかValidの正しい解釈を言うのにこれだけのスレ消費してる住人の
レベルの低さも原因ですね。

一言Validは定義されてるタグだけ使ってるものだって言えば終わるのに。

138 ：Name_Not_Found：04/07/20 23:37 ID:???

validを”正しい”という日本語に置き換えてみよう。
仕様１に照らし合わせて正しい。
仕様２に照らし合わせて正しい。
基準になるのはあくまでも”仕様”であって、
その”仕様”がどう変わろうとも”正しい”という考え方は変わらない。

139 ：Name_Not_Found：04/07/20 23:37 ID:???

>>128
valid = DTDに照らし合わせて妥当な記述であると言う事。簡単に言えば、validatorでvalid!と言われる事。
strictは、その通り、より論理的なマークアップ。

>>92での
> HTML4.01Strictで書いてるのでValidとはHTML4.01Strictの仕様と意向に沿ったものだと思っています。
は、validではなくてstrict志向。

と書いたところで、いくつかレスがついているんだが、もったいないので投下!

140 ：Name_Not_Found：04/07/20 23:41 ID:???

>>137
クレクレは帰れ

141 ：Name_Not_Found：04/07/20 23:41 ID:???

スクリクタン　実は大好き　アフォなやつ
　　　　　　　　　　　議論の為なら　自演もやむなし

142 ：Name_Not_Found：04/07/20 23:42 ID:???

な、だから自身の能力の無さを棚に上げてW3Cがクソとかいう連中はこの程度なんだよ

143 ：Name_Not_Found：04/07/20 23:43 ID:???

>>138
多分そういう言い方しても理解できないと思われ。
具体例示すまで全然理解する気配なかったからな。

144 ：Name_Not_Found：04/07/20 23:43 ID:???

字余り。

145 ：Name_Not_Found：04/07/20 23:44 ID:???

スレを無駄に消費したのは教えてくれない他人のせい、
自分はむしろ被害者だから全然悪くありませんよー、か。

146 ：Name_Not_Found：04/07/20 23:44 ID:???

おっと違った

147 ：Name_Not_Found：04/07/20 23:53 ID:???

>>1
> でもHTMLの基礎知識は欲しいね。

夏厨の中の人はお断りです

148 ：もの申す：04/07/20 23:54 ID:???

>>142
はじめから読み直したら？とちゅうからvalid云々に変わったけど、
俺がWWWC批判したのはそんなことからじゃないから。

149 ：Name_Not_Found：04/07/20 23:57 ID:???

CSSはスレ違いです。

150 ：Name_Not_Found：04/07/21 00:03 ID:???

XHTML1.1で、<input type="hidden" name="hoge" value="abc" />
といった hidden な<input>はどうマークアップしたら良いでしょうか？
根本的に<form>関連のマークアップがよく分かりません。

151 ：Name_Not_Found：04/07/21 00:03 ID:???

読解力のない人間は悲惨だな

152 ：Name_Not_Found：04/07/21 00:17 ID:???

自分だけは特別とか思ってる人間は悲惨だな

153 ：Name_Not_Found：04/07/21 00:20 ID:???

人並みの読解力があるだけであなたにとっては特別なのですね

154 ：Name_Not_Found：04/07/21 00:21 ID:???

HTML-lintで、
XHTML1.0 Transitional
のソース中の
<img src="/mark.gif" width="60" height="14" alt="" align="absmiddle" />ほげほげ

について、
<img> の align の属性値 `absmiddle` は正しくありません。`top`、`middle`、`bottom`、`left` または `right` でなければなりません。

と怒られてしまいました。

XHTML1.0 Transitional
を守りながら、同じ見た目（画像ボタンの中心線と文字の中心線が一致する）にするにはどうするのが、
スマートなのでしょうか？

自分には、
<table summary="hoge" cellspacing="0" cellpadincg="0" borde="0">
　<tr>
　　<td align="/mark.gif"></td><td>ほげ</td>
　</tr>
</table>
とするしか思いつかないのですが・・・

155 ：Name_Not_Found：04/07/21 00:29 ID:???

>>154
誤爆？

Webサイト制作初心者用質問スレ vol.97
http://pc5.2ch.net/test/read.cgi/hp/1089867985/

156 ：Name_Not_Found：04/07/21 00:48 ID:???

昨日が終業式だったんだっけ？

157 ：Name_Not_Found：04/07/21 01:05 ID:???

>>154
`top`、`middle`、`bottom`
　　　　　~~~~~~

158 ：Name_Not_Found：04/07/21 01:25 ID:???

<div><div><div><div><div><div><div><div>
わーい！valid だよー！！
</div></div></div></div></div></div></div></div>

でも、strict じゃない。

159 ：154：04/07/21 01:42 ID:???

>>155
誤爆です。すみません

160 ：Name_Not_Found：04/07/21 03:38 ID:???

>>158
そんなに悔しかったのか？馬鹿はスルーしとけよ。

161 ：Name_Not_Found：04/07/21 07:02 ID:???

なんか凄いことになってますね。

みんな俺の精子でも飲んでﾓﾁﾂｹ

162 ：Name_Not_Found：04/07/21 07:31 ID:???

すごい伸びだな。一瞬荒らされたのかとオモタ

。。。いや、ある意味荒らされたのか。

163 ：Name_Not_Found：04/07/21 10:23 ID:???

掲示板に文字を大きくして書き込みたい時は
<SPAN STYLE="FONT-SIZE:50pt">大きくしたい文字</SPAN>
で合っていますか？
これで書き込んでも大きくなるどころか<SPAN～とそのままの表示でした。
その掲示板には文字を大きくしたり、太くしたりした書き込みがあるので出来ると思うのですが
どうすればいいのでしょうか。
ちなみに、このサイトを参考にしました。
ttp://hp.xrea.jp/

もしスレ違いでしたら、お手数ですが誘導お願いします。
よろしくお願いします。

164 ：Name_Not_Found：04/07/21 10:33 ID:???

Webサイト制作初心者用質問スレ vol.97
http://pc5.2ch.net/test/read.cgi/hp/1089867985/

165 ：Name_Not_Found：04/07/21 11:26 ID:???

>>164
誘導ありがとうございます。
そちらで質問してみます。

166 ：Name_Not_Found：04/07/21 12:52 ID:ObNlDNzj

うっひょーーーーーーーーーーーーーーーー今日から夏休み！！！！！！！！！
毎日strictの勉強が出来ますよ！

167 ：Name_Not_Found：04/07/21 14:02 ID:???

カツオ、strictの勉強は夏休みの宿題が済んでからよ。

168 ：Name_Not_Found：04/07/21 14:06 ID:???

サザエ、いいじゃないか。
カツオ君、やる気になってるみたいだし。

169 ：Name_Not_Found：04/07/21 14:54 ID:???

今日から夏休みの人間が果たしてStrictに興味持つのか？
そういう年齢層って物理的要素乱舞、不思議マークアップのhtml書いてそうな
イメージなんだけど。

170 ：Name_Not_Found：04/07/21 15:05 ID:???

そんな簡単に釣られんなよ

171 ：Name_Not_Found：04/07/21 15:45 ID:???

>>58
激しく同意

172 ：Name_Not_Found：04/07/21 16:06 ID:???

>>58
さしたる話題もなく放置＆スルーをしてると存在しないことにされるのね。

173 ：Name_Not_Found：04/07/21 17:40 ID:???

Strictってオタクっぽいから、ここ以外では話せないよねorz
仕事でやってる人は別だろうけどさ

174 ：Name_Not_Found：04/07/21 17:43 ID:???

仕事でやってるやつはStrictで書いたりしない

175 ：Name_Not_Found：04/07/21 18:13 ID:???

何かに真面目に取り組んでると、オタクって言われるよな。何なんだ。

176 ：Name_Not_Found：04/07/21 18:17 ID:???

何かにしか真面目に取り組んでないとオタクって言われるのでは?

177 ：Name_Not_Found：04/07/21 18:41 ID:???

呼び方はともかく、何か一つでも真面目に取り組むということはいいことだと思う。

178 ：Name_Not_Found：04/07/21 19:23 ID:???

インドア系は詳しいとすぐにオタクって言われるね

179 ：Name_Not_Found：04/07/21 19:36 ID:???

そんなことない。
俺、釣りオタクって言われる。

180 ：Name_Not_Found：04/07/21 19:47 ID:???

一人で黙々と打ち込むものがそう呼ばれやすいっていうかスレ違い

181 ：Name_Not_Found：04/07/21 20:40 ID:???

ここは雑談オタクが集まるスレですね

182 ：Name_Not_Found：04/07/22 00:59 ID:???

>>174
漏れは蔵が理解あるんで、strictで書いてるよ。
「メンテ楽なんで」って言ってる。

183 ：Name_Not_Found：04/07/22 04:04 ID:???

お前ら頭の悪いプログラマーに言いたい
http://pc5.2ch.net/test/read.cgi/php/1090421140/

1 名前：nobodyさん[] 投稿日：04/07/21(水) 23:45 ID:uWuT3YUy
HTMLのコーディングもまともにできねーのに
変なCGI配布してんじゃねーよ。
HTMLがめちゃめちゃすぎてカスタマイズできねーんだよ。

184 ：Name_Not_Found：04/07/22 07:06 ID:???

>>183
strict掲示板自作して使ってます。

185 ：Name_Not_Found：04/07/22 07:10 ID:???

空気の嫁ない>>183のさらに上を逝く>>184に惚れた

186 ：Name_Not_Found：04/07/22 07:24 ID:???

>>185
配布してないから。
残念な思いをさせてしまったね。ごめん。

187 ：Name_Not_Found：04/07/22 09:24 ID:???

とんでもない質問でスマン
html4では「要素名は大文字」が推奨？だよな

html4.01では小文字が推奨なんだとどこぞのサイトで読んだ気がして
今までずっと小文字で書いていたんだが、

仕様のどこにそんな記述が？

188 ：Name_Not_Found：04/07/22 09:35 ID:???

>>187
> html4では「要素名は大文字」が推奨？だよな
仕様書の記述が、区別付きやすいようにそうしてる、って話。

> 仕様のどこにそんな記述が？
XHTMLに移行しやすいように、と提唱されてる、って話。

189 ：Name_Not_Found：04/07/22 09:41 ID:???

>>187
仕様書の記述の話なのか。

英語力及ばなんだ

1.2.1 Elements and attributes
Element names are written in uppercase letters (e.g., BODY).

って書いてあるからあれ？と思ったけど、
その項の名前が

1.1 How the specification is organized
じゃん。
仕様の記述法、だな。これ。

記述の仕様、って勘違い。何をどう読んだんだ俺は。

190 ：Name_Not_Found：04/07/22 09:46 ID:???

HTML4.0 でも HTML4.01 でも、要素名の大文字小文字は問われないし、どっちが推奨とも書いていない。
ただ、仕様書は「見やすさの便宜のために」大文字で書いてあるだけ (HTML4.01 Spec. 1.2.1) 。

XHTML1.0 / XHTML1.1 では、要素名 (および属性名) は小文字でなくてはならない。

XHTMLへの移行をにらんだ場合、HTML4でも全部小文字で書いた方が後々楽だろうということで
小文字を勧める人が多いが、仕様上では特に決まっていない。

あと小文字はタイプが楽。

191 ：190：04/07/22 09:48 ID:???

リロード忘れたので吊ってくる

192 ：188：04/07/22 09:58 ID:???

>190
んじゃ、ｹｺｰﾝということで。

193 ：Name_Not_Found：04/07/22 10:16 ID:???

>>190
SGML の大文字小文字問題は、
「大文字小文字の違いは問わない」ではなく、
「小文字で書かれていたら大文字に変換してから解釈」という
仕様なので、大文字が基本で小文字は代替。

従って、推奨というレベルではないが、
HTML4 は全て大文字で書くのが基本で、
小文字で書くのも許されるという感じかと。

194 ：Name_Not_Found：04/07/22 10:19 ID:???

http://altba.com/bakera/hatomaru.aspx/ebi/genre/00480054004d004c

195 ：Name_Not_Found：04/07/22 10:22 ID:???

>>193
変換されるんなら基本もなにもないんじゃない？
普通にどっちでもよい、かと。

196 ：Name_Not_Found：04/07/22 10:42 ID:???

>>193
BR要素のような空要素のの終了タグも、
書くのが基本で省略も許される感じ、ですか？

197 ：Name_Not_Found：04/07/22 10:43 ID:???

>>196
なんでそんな飛躍をするの？
そんな話は出てないし、そういうわけではないし。

198 ：Name_Not_Found：04/07/22 10:55 ID:???

>>196
そんなあなたは過去のSGMLなんかより今のXMLを使いましょう

199 ：Name_Not_Found：04/07/22 11:53 ID:???

>>196
>>197と同じく、自分にもそこまで飛躍する意味は分からんが、敢えて釣られてみる

br要素の様な内容が空である要素は、
HTMLでは必ず終了タグを省略しなければならない
逆にXHTMLでは省略してはならない

>>198
SGML⊃XMLなんだが

200 ：Name_Not_Found：04/07/22 11:58 ID:???

> SGML⊃XML
前にこのスレでこれは違うと指摘された覚えがあるな…

201 ：Name_Not_Found：04/07/22 14:12 ID:???

HTMLがSGMLのサブセットという話は聞いたことあるけど
XMLがSGMLのサブセットという話は聞いたことない

202 ：Name_Not_Found：04/07/22 14:22 ID:???

仕様書冒頭に書いてあるけどな

203 ：Name_Not_Found：04/07/22 14:31 ID:???

仕様書仕様書っておまえらは仕様書村の村民かっつーの！

204 ：村人1：04/07/22 14:58 ID:???

あ、カラスが山に帰っていくわぁ

205 ：村長：04/07/22 15:33 ID:???

カラスは山に帰る仕様だからのぅ

206 ：村の娼婦１：04/07/22 15:43 ID:???

ねぇーねぇーＨ仕様♥

207 ：Name_Not_Found：04/07/22 15:49 ID:gmK8fwAr

今までdiv厨ってバカにしてたけど、CSSでの管理のしやすさはもの凄いものがあるんだね。
それで今迷ってるんだけど、ブロック毎にdivにid振ってCSS面で一番便利な構成にするか、
<hn>を正しく使ってるんだから、divでわざわざ囲むのはstrictではない！って頑固に、クラス名だらけの汚いソースでいくか。

ここにいる人ならどちらを日常で選んでるの？クラスたくさん振るのはなんか嫌いだけど、
CSSの観点からdivを必要とするのも、微妙・・・迷える子羊にアドバイスをorz

208 ：村の青年：04/07/22 15:50 ID:???

どう仕様･･･

209 ：Name_Not_Found：04/07/22 15:57 ID:???

>>207
class使うのはだめでid使うのはいいのか。

210 ：Name_Not_Found：04/07/22 15:59 ID:???

>>207
完全にStyleの追加が目的ならclassの追加もStrict的にはdivも追加も同じくらい
よろしくない。

逆に、何らかの意味づけの追加をclassなりdivなりで行って、それをセレクタの
対象にしてCSSでStyleを追加するならclassごてごてでもdivごてごてでも
Strict的には問題ない。

あとは具体的にどんなソースかによって要素の追加(div)と属性の追加(class)と
どっちの方が好ましいか、と言う話になるので、こっちで相談するヨロシ。

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

211 ：207：04/07/22 16:00 ID:gmK8fwAr

>>209
どちらも一長一短だと思うから悩んでる・・・
実際divで初めにブロック毎にうまく括れば、リニューアルするときにHTML側を
全くいじらないで済む。CSSファイルの管理からすると、完全にdiv圧勝なんだけど、
Strictを追い求めたい願望もあって・・・・；

212 ：Name_Not_Found：04/07/22 17:00 ID:???

>>210
いくつか前のスレでも議論したけど、HTMLレベルではdivはなくても困らないんだよね。
もちろん正しい使い方ならあってもいいんだけど、HTMLだけを考えることがStrictならdivは不要。
もちろんclassも不要。

だからCSSレイアウトでHTMLをStrictにすることは難しいし、余計な手間。
どこかで適当に妥協するといい。一応Strictにはなるから。
極限までStrictにこだわろう！とか思ってるから迷うんだよ。

divに意味のあるidをつけていくのは、極限的なstrictではないけど、十分strictだから安心しる。
ガンガレ！

213 ：Name_Not_Found：04/07/22 17:58 ID:???

迷ったらとりあえず<div class="section">ですよ！

214 ：Name_Not_Found：04/07/22 18:03 ID:???

Copyrightとかの表示は何でマークアップするとStrictになれるんですか？
Copyrightの下には、住所とかも書くのですが、それは又別のものでやるべきでしょうか？
それとも全部pとかでいいのですか？

215 ：Name_Not_Found：04/07/22 18:06 ID:???

>>219
まずはmeta要素。コレが一番意味付け的に安定している。

で、bodyないでは書き方による。箇条書きならulなりolだし、dlにも
成るかも知れない。自然な文章の中で主張するならpに成るだろうし、
著作者への連絡先を兼ねるならaddressに成るかと思う。

少なくともCopyrightならxx要素、と言うのはない。

216 ：215：04/07/22 18:07 ID:???

未来に向かって何を言ってるんだ、俺は…orz

正しくは >>214。スレ汚しスマ。

217 ：Name_Not_Found：04/07/22 18:53 ID:???

<h1>
<h2>
<h3>
<h4>
<h5>
<h6>
上から順番に意味で言うと何？
chapter
section
sub section
？
？
？
誰かわかる？

218 ：Name_Not_Found：04/07/22 18:56 ID:???

part chapter section subsection subsubsection paragraph subparagraph

219 ：Name_Not_Found：04/07/22 19:02 ID:???

>>217
固定的な正解は「存在しない」

h1-6のナンバは各文書ごとにふり直されるから、
h1が本の題名レベルならh2が章でh3が節になる（かも知れない）し、
決算書などでh1が部なら、h2が款、h3が項、h4が目になるかもしれない。

220 ：Name_Not_Found：04/07/22 19:22 ID:???

>>218
7個あるし、何で見出しがparagraphなんだよ。
>>219
ならh2をsectionとして考えてもそれは製作者の勝手ってことかな？ある程度の
筋が通っていればいいみたな感じ？

221 ：Name_Not_Found：04/07/22 19:28 ID:???

「ある程度」ってどの程度だ

222 ：Name_Not_Found：04/07/22 19:29 ID:???

>>220
218はLaTeXのコマンドだろ

223 ：219：04/07/22 19:57 ID:???

>>220
有る程度っていうか、トップレベルの見出し(h1)から１段階ごとに
h2,h3,h4,h5,h6となっていれば、sectionとかsubsectionとかいう名前はどうでもいい。

HTMLの仕様で定められているのは各HTML文書は、h1を最も大きい見出し、
h6を最も小さい見出しとして1-6で見出しに重み付けをしているという程度だし、
strictな信者的にもISO-HTML見たいな、レベルをスキップしない見出しの明示や
文書の構造化が正しいとする程度で、h2がsectionかどうかなんてのは
悩む所じゃない。

224 ：Name_Not_Found：04/07/22 20:08 ID:???

とりあえず、h1-6はXHTML2で亡くなるのだからいまさら議論する意味は無い

225 ：Name_Not_Found：04/07/22 20:12 ID:???

XHTML2でHTML4.01やXHTML1.xがなくなる訳でもない。

たしかに今更な感は高いが。

226 ：Name_Not_Found：04/07/22 20:48 ID:???

こんなのみっけた
http://www.w3.org/MarkUp/2004/xhtml-faq

227 ：Name_Not_Found：04/07/22 21:09 ID:???

>>223
h2の部分をコメントでブロックにするときに、sectionとするかchapterとするかで迷っただけなんだけど
理解できたよ

228 ：Name_Not_Found：04/07/22 21:55 ID:???

h1 root
h2 main
h3 main-contents
h4 main-contents-child
h5 misc
h6 misc

229 ：Name_Not_Found：04/07/22 22:47 ID:???

>>194
SGMLでは名前は大文字に変換してから解釈されるということは、
タグが小文字で書かれていても、
要素は大文字として解釈されるということ。
(タグと要素の違いに注意)

つまり、HTMLでは、小文字の<p>タグは存在し得るが、
小文字のp要素は存在しない。大文字のP要素のみが存在する。
(小文字の<p>タグは大文字のP要素を表す)

従って、HTMLの要素は大文字なのにXHTMLではなぜ小文字に
したのかという疑問は別に間違ったことを言ってる訳ではない。
「推奨」とは関係ないが。

230 ：Name_Not_Found：04/07/22 22:48 ID:???

>>201
HTMLはSGMLの応用。XMLはSGMLのサブセット。

231 ：Name_Not_Found：04/07/22 23:01 ID:???

お前らスレタイ読めるか？

232 ：Name_Not_Found：04/07/22 23:17 ID:???

>207
遅レスだが、「DIV厨と呼ばれるほど使う」か「まったく使わない」の二択しかないのか？
適度、って言葉があるだろう。適度かどうかの判断は自分と、周りの意見で左右されればいいだろうけど、
そんな二択じゃな。熱湯の風呂か氷水の風呂かどっちにします？ってくらいイカれてる。

233 ：Name_Not_Found：04/07/22 23:30 ID:???

>>231
お前は >>1 が読めないのか？

234 ：Name_Not_Found：04/07/22 23:55 ID:???

また低レベルな争いが始まったよorz

235 ：Name_Not_Found：04/07/23 00:01 ID:???

そんなときは、>>58

236 ：Name_Not_Found：04/07/23 00:28 ID:???

>>234
ここに争いが起こってるように見えるお前の目が不思議でならん。

237 ：Name_Not_Found：04/07/23 00:39 ID:???

>>232
そして適度に使っているつもりが、divがないと何も出来ないようになっていたりするんだな。

238 ：Name_Not_Found：04/07/23 00:58 ID:???

>>237
睡眠薬と同じ。
必要なときだけ使えるやつはうまく使う。
中毒になるやつもいる。
それが怖くて使わないやつ、
不自然だと言って使わないやつ、

それぞれいる、ってだけだろ。

239 ：Name_Not_Found：04/07/23 03:19 ID:???

>>238
>必要なときだけ使えるやつはうまく使う。
うまくってCSSからみてだろ？htmlとして考えたときにdivのうまい使い方なんてないだろ。
なくても困らないものなんだから。

このスレで言うことではないけど、CSS3にセレクタが新たに増えればいいんだよな。
<h2>から次の<h2>までをブロックみたいに捉えることができるセレクタがあれば
divなんてほんとになくてもいいよ。まあW3Cはそこまでストリクタンではないだろうから
期待はできないけど。

240 ：Name_Not_Found：04/07/23 03:34 ID:???

>htmlとして考えたときにdivのうまい使い方なんてないだろ。
XSLT用の構造明示とかDOM向け構造明示とか。

レイアウトじゃなくて、あくまで「構造明示」の目的できっちり使える。

241 ：Name_Not_Found：04/07/23 03:36 ID:???

>>239
Body直下に見出しでも、段落でも、そのた既存の要素ではない
文字列を記述したいときにどうするのだ？

例外は存在しない、と言う保証があるなら兎に角、
今そんな例外は思いつかないから今後とも大丈夫と言う訳にはいかない。

242 ：Name_Not_Found：04/07/23 03:44 ID:???

>>239
CSSのセレクタやDOMを使ったアプリケーションやXPointerが十分強力ならばdivは要らないという主張でOK?

その前提で話すけど、それらのようなものを使って外部のものがグループを決めるだけでなく、Authorがグループを決めてそれを表したいこともある。
ここからここまではなんらかの意味を持ったグループである。という意味で。
その詳しい意味は自然言語などによる取り決めや別のネームスペースの属性などで決まるということで。
コメントでと書くのに似ている。

あと単純に複数のブロック要素にlang属性を付けたいときにも便利。

さらにh2からh2までのブロック、という指定の方法だとコンテンツが変わってしまったときにXPointerなどが切れてしまう恐れがある。uriの永続性を確保しつつコンテンツを必要に応じて変えられるように特定の範囲にidで名前を付けられるというのは有効。
これはuriの話なのでHTML単体で考えても意味がある。

243 ：239：04/07/23 04:14 ID:???

>>240
XSLTなんて知らない。HTMLはあくまでHTML。論理的なマークアップさえすればいいだけで
XSLT用のマークアップをするのがStrictなのかはよくわからない。何せXSLTを知らないから；

>>241
俺は今までにdivをHTMLレベルで必要だと思ったことがないから、HTMLのみなら
divはなくても困らないって言ったんだけど、だからってdiv自体を仕様からなくそうなんて事ではないから安心してよ。

>>242
なんか難しい事言ってる。
別におれは今までのものをなくせと言ってるのじゃなくて今までのプラスそういうセレクタがあればいいなってだけ。

<h2 id=hoge>
<架空のdiv>
<p></p>
<ul></ul>
</div>
<h2 id=hoge2>
<架空のdiv>
<p></p>
</div>

同レベル<hn>～<hn>の間がdivで括ってある感じで、<hn>につけたid＋なんか新しい表記で
架空のdiv内の要素を指定して行く幹事。別に困ることはないと思うけど。
基本的に架空のdivにはuriは付かないし、uriが関係するのは<hn>につけたidだけ。

よく考えたら>>242は賛成派なのかな？難しいや

244 ：Name_Not_Found：04/07/23 10:09 ID:???

>>243
>基本的に架空のdivにはuriは付かないし、uriが関係するのは<hn>につけたidだけ。
じゃあキミはhnにリンクを張って何が嬉しいの？

というか
>別におれは今までのものをなくせと言ってるのじゃなくて今までのプラスそういうセレクタがあればいいなってだけ。
そんな単純にやるとそれこそ互換性云々。

245 ：Name_Not_Found：04/07/23 10:15 ID:???

<h1/>
　<h2/>
<h1/>
　<h2/>

「同レベル<hn>～<hn>の間のブロック」なんて
たったこれだけのサンプルでもまともにつかえるのは h1 に対してだけだ。
# 見出しレベルのセマンティクスを CSS 側で認識すべきとか言うなよ。

246 ：Name_Not_Found：04/07/23 10:16 ID:???

>俺は今までにdivをHTMLレベルで必要だと思ったことがないから、HTMLのみなら
>divはなくても困らないって言ったんだけど、
個人的に要らないと思うのは勝手だが、こういう公の論議スレで「要らないと思う」
と言ったら「廃止論者」ととられても仕方ないと思うが。

誰かに訴えたいなら兎に角、「僕はこう思いました」レベルの独り言なら
部屋の隅で壁に向かってやれ、体育座りで。

247 ：Name_Not_Found：04/07/23 11:33 ID:???

　　　｜
　　　＆|＜divはなくても困らない…
￣￣￣

248 ：242：04/07/23 11:54 ID:???

XPointerとういのは簡単にいうとURIの#の後に式などを書いてXMLの一部分を示すもの。
たとえば
#xpointer(id('foo')/range-to(following-siblings::h1/preceeding-siblings::*[1])
で

<h1 id="foo">
<p>...</p>
<p>...</p>

<h1 id="bar">
<p>...</p>
<p>...</p>

のid="foo"のh1とその後の2つのp(次のh1の前)を指し示すことができる。
あるh2(aとする)から次のh2までを選択するには、aから、aの次にあるh2、ただしaの次にあるh1よりも前にあるもの、もしくはaの次にあるh1、ただしaの次にあるh2よりも前にあるものまでを選択すればいい。

XPointerは拡張可能なのでこれらをもっと簡単に書くことも可能。例えば
#mynamespace:section('foo')
とか。

なので
<div id="foo">
...
</div>
は
<hn id="foo">...</hn>
...
に損失無く書換え可能。

ただ、これで文章の構造が分り易いかどうかという問題はISO派とXHTML派の抗争に繋がるのでノーコメント。

249 ：Name_Not_Found：04/07/23 12:55 ID:???

現状ではXPointer自体なんともいえないし、
そこまでのリソース払うんだったら俺はdiv要素選んでしまいます
ヘタレだな俺

250 ：243：04/07/23 13:24 ID:???

>>245
>「同レベル<hn>～<hn>の間のブロック」なんて
>たったこれだけのサンプルでもまともにつかえるのは h1 に対してだけだ。
なんかおかしなこと言ってないかい。divで構造を示さなくても、<hn>をちゃんと使ってれば
それだけで構造はハッキリしてるんだから、何も問題はないよ。<hn>だけでツリー構造になってるんだから、
そのツリー構造をCSSで理解させればいいだけでしょ。どの<hn>に属する要素なのかもハッキリしてる。
もちろん全ての要素は<h1>に属するわけ。

>>244
>じゃあキミはhnにリンクを張って何が嬉しいの？
意味わかんない。divにリンクを張るのと差異はないのにどういう意味？

>>248
なんかわかんないけど、XPointerをやるのに今はdivが必要なの？ってことではないよね。

とりあえずみんなが何を批判してるのかわからない。ディレクトリとかのツリー構造と同じことが
<hn>だけで可能だと思うから、そういうセレクタがあってもいいと思う。X系は知らないけど
divなんかなくてもツリー構造が明確であれば問題ないんでしょ？

251 ：Name_Not_Found：04/07/23 13:32 ID:???

>>250
それってh1をルートフォルダに置き換えてってこと？h1の前にパンクズリストとか書く場合は、おかしくなるぞ。
まあbodyフォルダにあるファイルでいいか。それでh1がbodyフォルダの中にあるフォルダ。ならルートはbodyか？いっそhtmlがルートだな。

252 ：Name_Not_Found：04/07/23 13:46 ID:???

くそ、無知を装ったISO派の高度な釣りか！

253 ：Name_Not_Found：04/07/23 14:19 ID:???

なんつーかだな。SGMLもXMLも、マークアップ言語ちゅーのは、
意味のある範囲を「ここから～ここまで」とtagで "明示する"ってのが
大原則な訳で。

見出しがはっきりしていれば解るよね、と言うのは確かにその通りだが、
文書中のある要素が、どの見出しに属しているかを一々文書構造解析するのが
面倒臭いから「予めtagで印をつけとけばUAに認識させる時、負荷も少なくて楽」
と言うのがマークアップ言語の利点。

「そもそもUAに理解させる必要はない」ってんなら、文書構造を明示するdivイラネで
結構だが、「理解させる必要がある」というのならCSSのセレクタがどうこうじゃなくて、
マークアップ言語の基本的な思想として何らかの要素でマーク付けするのが自然。

んで、HTMLの場合、該当する専用の要素がないので、汎用要素divでこれを
代用するのが一般的。

以上

254 ：Name_Not_Found：04/07/23 14:42 ID:???

div一つだけでここまで不毛な議論が出来るなんて・・・
ストリクターって<del>キモイ</del><ins>素敵</ins>ですね。

255 ：Name_Not_Found：04/07/23 15:00 ID:???

>>253
(´-`).｡ｏＯ(それでいーのにねぇ。。。)

256 ：Name_Not_Found：04/07/23 15:01 ID:???

スタイルの悪い私でもスタイルシートは使えますか？

257 ：Name_Not_Found：04/07/23 15:06 ID:???

誤爆すみません。

258 ：Name_Not_Found：04/07/23 15:06 ID:???

ここはHTML派とXHTML派が混じる所でつか?
xpointerはXHTML等のXMLの上に成り立つ物しか使えないですよ。
HTMLでもstrictは可能だがHTMLは既に古くなっているので、XHTMLでstrictを語るのに統一した方が良いと思われ。

#divは意味付けとして利用。classの無いdivは反対という立場な方向で。

259 ：Name_Not_Found：04/07/23 15:09 ID:???

>>253
>んで、HTMLの場合、該当する専用の要素がないので、汎用要素divでこれを
>代用するのが一般的。
まるでdivがHTML以外のためにあるみたいなこと言ってるな。HTMLレベルでの話をするのがこのスレじゃないのか？

>>254
divというかUAの文書構造把握方法みたいな話なんじゃないか？

俺が思うにdivで
「ここから～ここまではhogeという塊です。」
なんてやること自体HTMLレベルで何故必要なのか不明だな。HTMLはHTMLなんだから他が
HTMLソースを勝手に利用するのは勝手だけど、そのためにHTMLの書き方が変わるなんてのはおかしい。
だから>>250の言うHTML側の文書構造把握方法を変えろなんていうのは、傲慢。

divは文書構造をはっきりするためにあるわけじゃなくて、そもそも文書構造用のタグが
できないことを考えれば、HTMLレベルでは見出しと本文がしっかりしてれば、そんなタグは
必要ないっていう証拠。div厨と騒がれるのは、結局汎用要素divで構造をハッキリさせること自体が
Strictといえるのか微妙だから。初めから構造毎に括る専用タグがあれば問題はなかった。
まああくまでHTMLなわけだから、そんなものは必要ないわけだけど。

とりあえずHTMLとその他のHTMLソースにかかわるものをちゃんと分離しれ。

260 ：Name_Not_Found：04/07/23 15:19 ID:???

>>259
> 俺が思うにdivで
> 「ここから～ここまではhogeという塊です。」
> なんてやること自体HTMLレベルで何故必要なのか不明だな。

もっといろんな文書の文体というか書き方があるを知った方がいい
と思う。

261 ：Name_Not_Found：04/07/23 15:19 ID:???

>>259
それで君はdivがHTMLで採用されている要素であることについてはどう考えているのかな？

262 ：Name_Not_Found：04/07/23 15:20 ID:???

画像の名前にアンダーバーを使うのはStrictですか？
a_on.jpg
私はこれはおかしいと思うのですが、みなさんはどう思いますか？

263 ：259：04/07/23 15:26 ID:???

>>260
君はまずこんにゃくとオナホールの違いを知るといいと思う。

>>261
その名の通り汎用要素。基本的には既存のタグで表せないもの用。
まあ例外用ってとこだな。構造に使うとなるとその需要はかなりのものになるわけで、
下手したら他の要素よりも頻繁に使うことになる。それを例外用のdivでやるのはちょっとおかしい。
例えばpの部分を全てdivでやることは仕様上では問題ないからと言ってp要素は削除しようなんて
流れになったら違和感あるでしょ？

需要の多いものは専用タグを作ってしかり。作られないものは所詮例外。
HTMLレベルではそこまで必要ではないって事だと思う。

264 ：Name_Not_Found：04/07/23 15:31 ID:???

>>259
昔々あるところにお爺さんとお婆さんが…
あ、ちょっとごめん、全然違う話していい？あのね…
話を元に戻す。川の上流から大きな桃が…

という文章があった場合、第二段落が第一・第三と別物だと言うことを、

小説のようなテキストのみで表現するメディアでは、空行を入れたり、
書体をかえたり、文体をかえたりして表現する。
プリントやスクリーンのようなメディアでは、色やカコミを付けたり
して表現したりできる。

ただし、それらは別物である、という「意味」の「表現」手段であり、
html は表現ではなく、意味を伝えるべきもの。

<p>○○○○○○…</p>
<p>○○○○○○…</p>
<p>○○○○○○…</p>

とマークアップされた場合、第二段落が別物であるという「意味」は
伝達することが出来ない。で

<p>○○○○○○…</p>
    <div>
    <p>○○○○○○…</p>
    </div>
<p>○○○○○○…</p>

とする、と。
そういった意味では、文書をブロック分けする必然性はあるわけですよ。
どう？

265 ：259：04/07/23 15:37 ID:???

>>264
divにidを振って意味づけするのとpにidを振って意味づけするのとどう違う？
ついでに言うと例文がわかりづらいな。2行目が第2段落とは思えない。全部おまいの発言。

もう少しわかりやすい例文だしてくれればいいかも

266 ：Name_Not_Found：04/07/23 15:39 ID:???

>例えばpの部分を全てdivでやることは仕様上では問題ないからと言って
>p要素は削除しようなんて流れになったら違和感あるでしょ？

段落はp要素だからpでマークアップしなければ仕様違反な訳で…。

最近DTDを守っているかどうか (validかどうか) と仕様違反かどうかを
区別しないで喋る（或いは区別する能力がないバカ）が増えたなぁ。

ttp://www.w3.org/TR/html401/struct/global.html#h-7.5.5ちなみに、HTMLの仕様自信が h1-6とdivを組み合わせると文書構造が
明示出来るとしているのをどう考えているのか、或いは、
仕様を読みもせずほえているのが、…特に知りたくもないなぁ。

レベルの程も知れたし。

267 ：Name_Not_Found：04/07/23 15:45 ID:???

>>254
同意。

268 ：259：04/07/23 15:46 ID:???

>>266
人をけなしてストレス発散もいいけど他のスレ行ってやってくれ。

>段落はp要素だからpでマークアップしなければ仕様違反な訳で…。
汎用要素で段落を括れないとはどこにも書いてないわけで。

269 ：Name_Not_Found：04/07/23 15:49 ID:???

>>268
> 最近DTDを守っているかどうか (validかどうか) と仕様違反かどうかを
> 区別しないで喋る（或いは区別する能力がないバカ）が増えたなぁ。

これを100回嫁

270 ：Name_Not_Found：04/07/23 15:49 ID:???

>>266
僕はdiv厨って言われるのがいやだからテーブルレイアウトしてますが;
divでブロック毎に括ってもいいんですか？でも何でdiv厨っていわれちゃうんでしょうか？

271 ：259：04/07/23 15:51 ID:???

>>269
仕様違反の意味を調べなさい。

272 ：Name_Not_Found：04/07/23 16:19 ID:???

>>270
>>259 の様な div 全面否定なひとでなければ、
div の使い方を誤っていなければ div 厨とは言わないと思うよ。

もしくは、批判する側が div の使い方をよくわかっていなくて、
とりあえず div 厨って言っておけばｶｺｲｲと思っていたり。

--

荒れる前に弁明しておくと、>>259 批判ではないです。

273 ：259：04/07/23 16:29 ID:???

>>272
ちなみに俺はdivを構造明示目的で使うのがなんかな～っていってるのであって、
div自体を否定してるわけではないよ。

divを使っての構造化自体HTML以外の目的のためのとこが多いってのが、って俺しつこいな。
失礼しました。

274 ：264：04/07/23 16:44 ID:???

>>265 = >>259
よし、これならどうだ！？

<p>…この扉の向こうに何かあるはず。開くぞ。ガチャ！うわぁっ！</p>
<p>[広告] この番組はご覧のスポンサーの提供でお送りしています<img /><p>
<p>そこには、便器にまたがる敏蔵（83）が微妙な顔をしていたのだった。…</p>

ね、ほら。第二段落は別物であると構造化する必要があるでしょ？
ね？

275 ：Name_Not_Found：04/07/23 16:46 ID:???

>>273
XHTML+独自名前空間での意味付けができるようなれとそういうことですね?

276 ：Name_Not_Found：04/07/23 16:52 ID:???

>>274
259ではないのだがpにclassを使ってはだめなん？

277 ：274：04/07/23 17:20 ID:???

例えばスクリーンメディアで下記のような表示を期待した場合、

http://v.isp.2ch.net/up/438f2feaeacd.gif

「提供」以下一連の所を枠で囲っているのは、他の本文部分とは別物ですよ、
という文書構造を伝達するための表現手段ですよね。
つまり、伝達（明示）すべき構造がある、と思うのです。

278 ：Name_Not_Found：04/07/23 17:29 ID:???

わざわざわからない人をわからせる必要はないじゃん…
放置しちゃおうぜ

279 ：Name_Not_Found：04/07/23 17:51 ID:???

269じゃないが…

仕様違反のHTML文書は「仕様に従っていないHTML文書」。
段落はp要素と仕様に書いてあるのに段落をp要素以外でマーク付けしたり、
h1要素はtable要素を無いように持てません、と仕様に書いてあるのに
h1の中にtable書いている様なHTMLが仕様違反。

Valid ではないHTML文書は「DTDの記述（但しコメント文は拘束力を持たない)
に従っていないHTML文書」。

各要素および属性の出現位置や内容が正しければ、レイアウト目的でtableを
使おうが、bodyの内容が全部テキストノードとdivで構成されていようが
valid。h1の中にtableが現れるようなレベルになってはじめてinvalid。

段落はp要素なのだから、p tag以外のtagでマーク付けをしたら必ず仕様違反。
しかし、DTDに従った親子の要素の関係を守っていればvalid。

divの意味とか以前に、仕様読んで、仕様の読み方そのものを勉強汁。
（親切な事にHTMLの仕様には仕様の読み方まで解説してある。）

280 ：259：04/07/23 17:51 ID:???

>>274
<h1>僕らの大冒険！</h1>
<h2>1部</h2>
<p>…この扉の向こうに何かあるはず。開くぞ。ガチャ！うわぁっ！</p>
<h2>提供（CM）</h2>
<p>[広告] この番組はご覧のスポンサーの提供でお送りしています<img /><p>
<h2>2部</h2>
<p>そこには、便器にまたがる敏蔵（83）が微妙な顔をしていたのだった。…</p>

一体何故divが必要なの？

281 ：259：04/07/23 18:04 ID:???

>>279
仕様違反＝Strict
って事か。テーブルレイアウトも全て仕様違反ね。無知でごめん。

仕様違反ってそういう意味とは捉えてなかったけど、そっちのほうが正しいんだろうね。
Strictではないけどvalid　＝　仕様違反だけどvalid
なんか仕様違反って言われると重大な間違いっていう俺の勝手なイメージでしゃべったのが
悪かったのね。Strictではないと言われても別に気にもならないのに比べて仕様違反はインパクトあるからなぁ。
言い訳してごめんなさい。

pをdivでやるのは仕様違反
のほうが正しいです。ごめんなさい。

282 ：Name_Not_Found：04/07/23 18:05 ID:???

＞280
いつもいつも自分の文章だけをマークアップできるとは限らないから、かな？

<blockquot>
<p>私には昔、料理人になりたいという夢があった。...</p>
<p>ところでラッシャー板前は今、どこで何をやっているのだろう。</p>
<p>閑話休題。今の食品業界の混乱を見ると、かつての夢が思い出されて悲しくなる。...</p>
<blockquot>

引用文の文章は弄れないから、勝手にHnを増やせないし。
この例の場合はp要素にclassかidを振ったら解決しそうだけどね。

283 ：259：04/07/23 18:19 ID:???

>>282
そもそも広告まで引用する必要性はあるの？
<blockquot>内で<hn>が駄目なのは、見出しまで引用する必要性がないからでしょ？
広告を引用する必要が俺には理解できないよ。

異なる部分なら<blockquot>又は<q>要素を増やせばいいんじゃないかな。

<blockquot>
<p>私には昔、料理人になりたいという夢があった。...</p>
</blockquot>
<blockquot>
<p>閑話休題。今の食品業界の混乱を見ると、かつての夢が思い出されて悲しくなる。...</p>
</blockquot>

↑これくらいなら<q>でいいと思うけど。

ところでこれは引用の必要があるのかい？
<p>ところでラッシャー板前は今、どこで何をやっているのだろう。</p>

284 ：Name_Not_Found：04/07/23 18:23 ID:???

>仕様違反ってそういう意味とは捉えてなかったけど、そっちのほうが正しいんだろうね。
意味とか、そっちとかじゃなくて、定義された「用語」だから。
だろうね、とかじゃなくて、今すぐ仕様を読みにいけ。

あと、strictと仕様違反もまた違うから。

って言うか、strictかどうかってのは使ってる仕様とDTDの話しで
＞Strictではないけどvalid　＝　仕様違反だけどvalid
これ、間違った理解だから。

TransitionalなDTDをつかってて valid/invalid
TransitionalなDTDではvalidだが、Transitionalな仕様に対して合致/仕様違反

StrictなDTDをつかってて valid/invalid
StrictなDTDでもvalidだが、Strictな仕様に対して合致/仕様違反

それぞれ別な状態。

いいからマジ仕様読みに行けって、はっきりって、こんな解説を他人にされてる
あたり、>>1 に書いてある最低限の知識がない状態だから。

仕様云々以前に、用語が解ってない時点で言葉通じてないから。
やばいって、マジで。

285 ：Name_Not_Found：04/07/23 18:28 ID:???

HTMLはある、ハイパーテキストがあったとき、それをどのようにHTTP上で
公開するか、と言う文書の書式に関する仕様なので、文書の内容は
一切問わないし、気にしない。

>そもそも広告まで引用する必要性はあるの？
これに対する本スレ的回答は「著者があると思ったらある」だ。

仕様の都合上、記述出来ない文書構造や文字コードは存在するが、
内容そのものは論議や評価の対象外。

286 ：259：04/07/23 18:34 ID:???

>>284
>意味とか、そっちとかじゃなくて、定義された「用語」だから。
>だろうね、とかじゃなくて、今すぐ仕様を読みにいけ。
仕様違反ってのは日本語だから。国語辞典を薦めておくれよ。

Strict　＝　仕様違反
俺ってアホだな。

287 ：Name_Not_Found：04/07/23 18:38 ID:???

＞286
>仕様違反ってのは日本語だから

いやいやいやいや。そんなこと言ったらStrictもValidも英語だから。
一般名詞とは区別されるべき用語だから、仕様書を読むのが正しい。

288 ：259：04/07/23 18:40 ID:???

>>284
<blockquot>内に<hn>をないほうできないなんてわけのわからないことをいってるな。

とりあえず引用先の文書が論理的なマークアップしてくれていれば基本的に問題ないでしょ？

289 ：259：04/07/23 18:41 ID:???

>>287
スレ違いな話だからどうでもいいけど、
Strictやvalidは用語だけど
仕様って言葉は日本語だよ。

290 ：Name_Not_Found：04/07/23 18:41 ID:???

要素とか属性も日本語な訳だが？

そうか、HTMLで解らない単語が出てくると、辞典ひいて解った気になっているのか…。

291 ：Name_Not_Found：04/07/23 18:42 ID:???

そろそろ自分の無知さ加減をフォローできなくなって、
大漁宣言がでるに20ガバス。

292 ：Name_Not_Found：04/07/23 18:48 ID:???

---------------- ここまで読み飛ばした ----------------

頼むから、アホだと思ったらスルーしてくれよ。

293 ：274 = 279：04/07/23 18:51 ID:???

>>281
>>277 みたいな事を考えているのですが、どう？

294 ：274 = 279=293：04/07/23 18:52 ID:???

うわ、レス番まちがえた。
>>280
>>277 みたいな事を考えているのですが、どう？

295 ：259：04/07/23 18:55 ID:???

>>290
要素や属性は明らかに用語でしょ。
でも、なんでもかんでも用語だと思うのはよくないよ。
HTML特有の意味を持ってるものは用語でいいけど仕様なんてのは別に特有の意味を持ってないでしょ？
仕様はどこいっても仕様。

>>291
なんか話ずれてるよね。まあ原因は明らかに俺だから悪いと思ってるけど、煽りみたいのは
できればやめてほしいかな。

俺マジで馬鹿だけどこれでも真面目に話してるんだよ。実際本題部分についての
具体的な批判はないでしょ。

まあ俺みたいな馬鹿が、人と議論するなんてのが無理だったかな。
なんか疲れたし去ります。さようなら。

296 ：274 = 279=293：04/07/23 18:56 ID:???

あと、>>280 の場合
「1部」「2部」と「提供（CM）」が違うとわかるのは、
人間が日本語を理解しているからであって、マークアップによって、
違うセクションであることは明示できてはいないと思うわけです。

297 ：259：04/07/23 18:57 ID:???

>>294
お。最後に返事。
表示はCSSでやりましょう。とても簡単です。

298 ：259：04/07/23 19:01 ID:???

>>296
又だ。
そんなこと言ったら見出しの意味がなくなります。

299 ：274 = 279=293：04/07/23 19:02 ID:???

>>297
あー、そういうことではなくて。そんなことはわかっております。
デザイン・表示のためにマークアップする訳じゃないです。

逆に、文書に区切りを明確化する意図がなければカコミというデザインも
生まれないわけです。
文書内での区切りを明確化する意図が著者にあるのに、css がなければ、
言い換えれば、webブラウザというメディアでなければ、それを伝達できない
のであれば、物理マークアップであって、マークアップ失敗だと思うのですよ。
どう？

300 ：299：04/07/23 19:04 ID:???

誤：物理マークアップであって
正：物理マークアップみたいなもので

すまそ。

301 ：Name_Not_Found：04/07/23 19:17 ID:???

>>298
ぬー。

提供
うまい棒
２ちゃんねる
ライブドア

って書いて「提供」がその後に続くものの見出しだとわかるのは人間だけで。
それを、全てが理解できるようにするために、

<hn>提供</hn>
<ul>
<li>うまい棒</li>
<li>２ちゃんねる</li>
<li>ライブドア</li>

ってマークアップするわけじゃん。つまり、文書の内容を理解できることを
前提にマークアップするのは本末転倒だと思うわけですよ。

302 ：259：04/07/23 19:54 ID:???

>>299-301
何が言いたいのかよくわからない。
>>280は論理的なマークアップになってるよ。

303 ：Name_Not_Found：04/07/23 19:59 ID:???

100レス分くらい読んだが
馬鹿同士の言い争いってほんとに悲惨だな

仕様は用語だ！日本語だ！
これが一番ひどいな。夏の間だけの我慢か

304 ：Name_Not_Found：04/07/23 20:13 ID:???

>まあ俺みたいな馬鹿が、人と議論するなんてのが無理だったかな。
>なんか疲れたし去ります。さようなら。

もう延命措置はいいから逝ってこい

305 ：Name_Not_Found：04/07/23 20:17 ID:???

"blockquot" とか、"タグ" と "要素" の混同とか、思いっきり釣りくさかったけど、みんな相手してあげてたんだね。
血が通いまくってるなあ。

306 ：Name_Not_Found：04/07/23 20:46 ID:???

http://pc5.2ch.net/test/read.cgi/hp/1086686223/l50
やっぱり釣りか…。

307 ：Name_Not_Found：04/07/23 20:47 ID:???

夏は新人が入ってくる時期。
そしてそれを放っておけない人たち。

308 ：Name_Not_Found：04/07/23 21:02 ID:???

釣りだったのか・・・・・・
馬鹿ぽいけど、微妙に正しいことを言ってるときもあったから中途半端な知識で暴れてるだけかと思った

309 ：Name_Not_Found：04/07/23 21:12 ID:???

(´-`).｡ｏＯ(最低半年は ROM れ！　なんだけどなぁ。。。)

310 ：Name_Not_Found：04/07/23 21:29 ID:???

わざとやってる釣りにしても頭悪いなぁ。

311 ：Name_Not_Found：04/07/23 21:32 ID:srCVwAxd

<address>
<span class="Copyright">Copyright (C) 1999-2004</span>
</address>
ってありでしょうか？

312 ：Name_Not_Found：04/07/23 21:32 ID:srCVwAxd

<address>
2004-11-11更新　メール***@***.***
<span class="Copyright">Copyright (C) 1999-2004</span>
</address>
です

313 ：Name_Not_Found：04/07/23 21:36 ID:???

addressは著作者に対する連絡先の要素だから、
著作権表示を兼ねても問題ないが、連絡先に成ってないと駄目。

314 ：Name_Not_Found：04/07/23 21:37 ID:srCVwAxd

>>313
<address>
2004-11-11更新
<a href="mailto:***@*****">Copyright (C) 1999-2004</a>
</address>

のほうがいいですか？

315 ：Name_Not_Found：04/07/23 21:39 ID:???

だって>>259=>>282でしょ。

316 ：Name_Not_Found：04/07/23 21:44 ID:???

>>314
a要素の内容がhref属性と無関係な気がするんだけど。

317 ：初心者EMG：04/07/23 21:46 ID:???

質問があります。
ホームページで写真をうｐして、写真の横に文章を打ちたいのですが、
普通に打つと写真の下にしか文字が打てません。
どうすれば写真の横に文字を打てるのでしょうか？

318 ：Name_Not_Found：04/07/23 21:47 ID:???

<address>
2004-11-11更新
Copyright (c) 1999-2004 <a href="mailto:***@******">314さん</a> All Rights Reserved.
</address>

ですかね？

319 ：Name_Not_Found：04/07/23 21:50 ID:???

>>318
いいんじゃない？
(c) は &copy が使えるぞよ

320 ：Name_Not_Found：04/07/23 21:51 ID:???

>>319
ありがとうございます。
©にします。

321 ：Name_Not_Found：04/07/23 21:53 ID:???

322 ：Name_Not_Found：04/07/23 21:55 ID:???

こ、こんどは釣られないぞー（ｸﾏAA略

323 ：Name_Not_Found：04/07/23 22:03 ID:???

そうか、ここはIDでないんだー。

324 ：Name_Not_Found：04/07/23 22:04 ID:???

<p class="copyright"></p>
にしとけ

325 ：Name_Not_Found：04/07/23 22:05 ID:???

<ul>
<li><p class="copyright"></p></li>
<li><address></address></li>
</ul>

なんてイケてるんじゃね？

326 ：Name_Not_Found：04/07/23 22:38 ID:???

このスレで、答える知識はないけど答えたい人たち（困ったことに善意の人も含む）が、
最後の最後にありがたく使わさせていただく合い言葉。それは、

釣りだった。
なんだ釣りだったのか。
そうか釣りだったのか。

というわけなので、スルーしろというのはむり。チン。

327 ：Name_Not_Found：04/07/23 22:45 ID:???

自己分析乙。

328 ：Name_Not_Found：04/07/23 23:00 ID:???

>> 327
おまえのことじゃん (w

329 ：Name_Not_Found：04/07/23 23:09 ID:???

>>317
名前がムカつく。

330 ：Name_Not_Found：04/07/23 23:35 ID:???

たまに今までの問答で何言ってるか素で分からなかったことがあった。
最初から最後まで相手できた奴は神認定してやる。

331 ：Name_Not_Found：04/07/23 23:38 ID:???

まだやってるのかおまいら。

332 ：Name_Not_Found：04/07/24 00:18 ID:???

>>317
http://pc5.2ch.net/test/read.cgi/hp/1089975931/l50

333 ：Name_Not_Found：04/07/24 00:32 ID:???

釣りだろうがなんだろうが、ログになったときに初心者が
参考にして不味い文章は一応否定しておかないと将来的に困る。

釣りとか何とかじゃなくて、ネタスレと同じ感覚でネタ発言をする事自体がDQN。

厨房に解るように言うと、学校のテストで０点とっといて、
「わざとでしたー」で済ませようとしている位アホ。
真性でも釣りでもアホはアホ。

334 ：Name_Not_Found：04/07/24 00:35 ID:???

釣りってのは仕込があって、ネタバレ時に「おお！」と言わせるようなものがいいですな。

335 ：Name_Not_Found：04/07/24 00:38 ID:???

何て言うか、このスレって理系多いだろ。

336 ：Name_Not_Found：04/07/24 00:55 ID:???

>>200-300くらいを読んだけど結局divはいらんの？

337 ：Name_Not_Found：04/07/24 00:59 ID:???

ぱんくずリストで疑問があるんですが、

top　＞　cahpter1　＞　section1

この場合「＞」これは背景とかlist-style-imageでやるべきでしょうか？
でもCSS切ったときに
1.top
2.cahpter1
3.section1

では理解してもらえない気がします。画像でやるのと「＞」これを実際に打ち込むのと
どちらが正しいのですか？

ちなみに
<ol> <li>top
<li>chapter1
<li>section1 </ol>
のようにマークアップしています。

338 ：Name_Not_Found：04/07/24 01:01 ID:???

>>336
h1-h6で構造を表せなくはないが、不便。div使った方が楽。

339 ：Name_Not_Found：04/07/24 01:02 ID:???

CSSで意味を持たせるのは正直間違っている

でもすまん、俺はそれを解決する手段を知らない
階層リストって欲しいんだよな・・・

340 ：Name_Not_Found：04/07/24 01:04 ID:???

>>337
スレの主旨にそってない気がするが。
ul要素でマーク付け、
list-style-type: none;
display : inline;
background : url(arrow.gif) no-repeat;
padding-left : 1em;
みたいに俺はやってるかな。

341 ：Name_Not_Found：04/07/24 01:04 ID:???

>>336
毎スレ同じ結論
効果的な使い方もあるが、絶対に必要というわけでもない。

詳しくは仕様書を読むことを薦める。

342 ：Name_Not_Found：04/07/24 01:08 ID:???

>>339-340
一応CSSなしでも理解できるものにしたいので、olかなと思いました。
olの入れ子で階層は作れますが、CSS切ったときに理解できない気がするので、
やはりolネストなしが一番いいのかなとおもいました。

「＞」これが半分論理的な意味を持っているような気がするので、CSSでやることに迷ってます。
いっそ<img>にしてaltを空にしてもいいかなと思いますが・・・どうなのでしょう

343 ：337：04/07/24 01:10 ID:???

>>342に名前入れるの忘れてました。ごめんなさい。

344 ：Name_Not_Found：04/07/24 01:16 ID:???

>>336
tableがあるからリストは要らないと言うのと同じ。

345 ：Name_Not_Found：04/07/24 01:40 ID:???

>>344
ぜんぜん違うだろ。
テーブル→2次元
リスト→1次元

ほんと最近適当なこというやつが増えたな。何なんだ？

346 ：Name_Not_Found：04/07/24 02:17 ID:???

いや、2次元だから1次元のものを表現可能なわけ。

347 ：Name_Not_Found：04/07/24 03:35 ID:???

またパンくずリストネタかよ。

348 ：Name_Not_Found：04/07/24 05:54 ID:???

>>342
> 一応CSSなしでも理解できるものにしたいので、olかなと思いました。
序列だと思うなら序列でいいんじゃない？

> olの入れ子で階層は作れますが、CSS切ったときに理解できない気がするので、
入れ子階層とパンくずは違うだろ

> 「＞」これが半分論理的な意味を持っているような気がするので、CSSでやることに迷ってます。
ない。

> いっそ<img>にしてaltを空にしてもいいかなと思いますが・・・どうなのでしょう
初心者スレいけ。

349 ：Name_Not_Found：04/07/24 06:57 ID:???

>>342
> CSS切ったときに
CSS は忘れろ

>>348
> ない。
何故無いのか説明してくれ

350 ：Name_Not_Found：04/07/24 07:21 ID:???

パンくずリストってそもそもリストなの？？？

351 ：Name_Not_Found：04/07/24 07:27 ID:???

知らないやつも多いみたいだが、英語圏ではtopic-pathな。

352 ：Name_Not_Found：04/07/24 07:37 ID:???

>>337
自分もまさに今似たようなことで悩んでるんだよな。
今のところ＞は実際に打ち込んでいるんだが
<ul>
<li>top ＞</li>
<li>chapter1 ＞</li>
<li>section1 </li>
</ul>
で良いのか（今の方法）、
<ul>
<li>top </li>
<li>＞chapter1 </li>
<li>＞section1 </li>
</ul>
に変えるべきか。
まあ、ものすごく些細なことだし、どっちでもいいんだろうけどな。
むしろlist-style-imageの方がいいのかね。

353 ：Name_Not_Found：04/07/24 07:55 ID:???

「＞」にどんな意味があるのよ？
実際にli要素同士を隣り合わせるようスタイル指定しないと意味ないだろそれ。

top ＞
chapter1 ＞
section1

こんなリスト明らかに不自然だろ。

354 ：Name_Not_Found：04/07/24 08:07 ID:???

<ul class="pankuzu">
　<li>top
　<ul>
　　<li>chapter1
　　<ul>
　　　<li>section1</li>
　　</ul>
　　</li>
　</ul>
　</li>
</ul>

ul.pankuzu ul {
display : inline;
padding: 0;
}

ul.pankuzu li {
display : inline;
list-style-type: none;
}

ul.pankuzu ul li:before {
content: " > ";
}

355 ：Name_Not_Found：04/07/24 08:12 ID:???

CSSはスレ違い

356 ：Name_Not_Found：04/07/24 08:43 ID:a4UrKNlJ

>>354 がいい感じだな。ひとまず CSS は置いておくとして。
<body>

<ol class="topic-path">
　<li><a href="/" rel="start">home</a>
　　<ol>
　　　<li><a href="/hoge/" rel="up">contents</a>
　　　　<ol>
　　　　　<li>foo</li> 
　　　　</ol>
　　　</li>
　　</ol>
　</li>
</ol>

<h1>foo</h1>
<ol class="bookmark">
　<li><a href="#sec1" rel="bookmark">初めに</a></li>
　<li><a href="#sec2" rel="bookmark">次に</a>
　　<ol>
　　　<li><a href="#sec2.1" rel="bookmark">例 1</a>
　　　　<ol>
　　　　　<li><a href="#sec2.1.1" rel="bookmark">例 1 の注意点</a></li>
　　　　</ol>
　　　</li>
　　</ol>
　</li>
　<li><a href="#sec3" rel="bookmark">結論</a></li>
</ol>

<h2 id="sec1">初めに</h2> ...

357 ：Name_Not_Found：04/07/24 09:32 ID:???

>>349
> 何故無いのか説明してくれ
無い事を証明するよりも、あることを証明する方が適切。
あることが証明されないから、ない。

358 ：Name_Not_Found：04/07/24 09:35 ID:???

自分にはあることを証明できないからないと思う

と言えよｗ

359 ：Name_Not_Found：04/07/24 09:36 ID:???

>>358
じゃお前が証明してやりゃいいんでないの。

360 ：Name_Not_Found：04/07/24 09:38 ID:???

>>358
なんで俺が「ある」ってことを証明するの？　バカか？
悪魔の証明って言葉を調べてみれば理解できるんじゃないかな。　　　バカでも。

361 ：Name_Not_Found：04/07/24 09:49 ID:???

口先だけの厨定番のセリフが出ましたね。
逃げ口上だけは得意なようだ。

362 ：Name_Not_Found：04/07/24 09:50 ID:???

>>361
負け惜しみはいいよ。悪魔の証明知らなかったんだろ？

363 ：Name_Not_Found：04/07/24 09:52 ID:???

最近の子は悪魔の証明も知らないのね。

「どんな人間でも即死させることができるスピーカーは存在するか否か」
しない、の証明なんてできないしね。する、って側が提供するのが筋でしょ。

364 ：Name_Not_Found：04/07/24 09:53 ID:???

結局は説明も出来ずに話をずらして終わりか

365 ：Name_Not_Found：04/07/24 09:54 ID:???

>361

>364

アンカーなしってのは不安が募ってる証拠だよ。

366 ：Name_Not_Found：04/07/24 09:55 ID:???

ないことを説明しろ、という無学がいるスレはここですか？

367 ：Name_Not_Found：04/07/24 09:57 ID:???

>>366
一つ上でお前のことを何か言ってるぞ。

368 ：Name_Not_Found：04/07/24 09:57 ID:???

>>349=358=361=364がおかしいだけだ。相手にするなよ。

369 ：Name_Not_Found：04/07/24 09:58 ID:???

>>367
定型レスにﾏｼﾞﾚｽかこいい

370 ：Name_Not_Found：04/07/24 10:01 ID:???

だれかこのスレの総意じゃなくても良いからまとめサイト作ってくれないかなぁ。
あまりにもループが多すぎるし、そのたびに初心者を惑わす馬鹿がpopする。

371 ：Name_Not_Found：04/07/24 10:02 ID:???

あることもないことも説明できないってことだな。
引っ込みつかなくなって必死か。

372 ：Name_Not_Found：04/07/24 10:03 ID:???

バカでもわかる「悪魔の証明」

ttp://ja.wikipedia.org/wiki/%E6%82%AA%E9%AD%94%E3%81%AE%E8%A8%BC%E6%98%8E

373 ：Name_Not_Found：04/07/24 10:03 ID:???

>>371
読解力身につけろ。
＞あることもないことも説明できないってことだな。
なんでそうなる？

＞引っ込みつかなくなって必死か。
>>349がな。

374 ：Name_Not_Found：04/07/24 10:04 ID:???

>>372
検索で最初にかかるそれを読んでも理解できなかったから噛み付いてるんじゃない？
バカにはわかんない、でFA？

375 ：Name_Not_Found：04/07/24 10:08 ID:???

「ねぎ」これが半分信仰対象的な意味を持っているような気がするので、ねぎを食することに迷ってます。

ない。

何故無いのか説明してくれ

376 ：Name_Not_Found：04/07/24 10:10 ID:???

だから「ある」ことを説明も証明もできないんだろ？
もしかして自分の説明できないことはすべて存在しないと？
へーへー、ご立派な方でございますな
まるで神だなｗ

377 ：Name_Not_Found：04/07/24 10:11 ID:???

>>376
> だから「ある」ことを説明も証明もできないんだろ？
ないものをどう説明しろと？
>>372の参照先を読んでこれを言ってるなら神だな。

378 ：Name_Not_Found：04/07/24 10:12 ID:???

大好きなパンくずが否定されたみたいで、凄くムカついたんです、

と素直に言えば許してやらないこともない。

379 ：Name_Not_Found：04/07/24 10:12 ID:???

暑くなると可哀想な人が増えるんだから、
お前ら優しい心でもってスルーしてやれ。

380 ：Name_Not_Found：04/07/24 10:15 ID:???

散々反応しておいて　（ ´,_ゝ｀）ﾌﾟｯ

381 ：Name_Not_Found：04/07/24 10:16 ID:???

>>376
>もしかして自分の説明できないことはすべて存在しないと？

「誰もが」証明できないものは存在しない。

382 ：Name_Not_Found：04/07/24 10:19 ID:???

このスレの数人が「誰もが」に相当するほどとは知りませんでした。
もしそうなら俺の負けだな。

383 ：Name_Not_Found：04/07/24 10:22 ID:???

>>382
悪魔の証明は理解できたのか？
「ある」ことを誰も証明できないのなら（議論の場だろうが世界的な学会だろうが）、
その場では「ない」ことになる。それに異を唱えるなら「ある」と証明する。
証明できないのなら「ない」ことになる。

「ある」と誰かが証明できるまでそれは「ない」。
お前は「ある」と主張するが証明できていない。
よってこの場では、誰かが「ある」と証明するまで「ない」。

384 ：Name_Not_Found：04/07/24 10:27 ID:???

>>383
お前は説明うまいな

385 ：Name_Not_Found：04/07/24 11:10 ID:???

そういうお前は皮肉がうまいな

386 ：Name_Not_Found：04/07/24 11:20 ID:???

議論のための議論が続いてるようなので話を戻した方がいいと思う。

で、パンくずリストの「>」記号に論理的な意味があるかどうかだが、
少なくとも、階層の上下関係を示すという論理的な意味はあるだろう。

違う例で言うと、数学で「x < y」と書いた時の「<」記号は
大小関係を示すという論理的な意味がある。でも、もしこれを例えば、
<COMPARE><LITTLE>x<GREAT>y</COMPARE>
と表すようなマークアップ言語があったとしたら、「<」記号は
もはや書かなくてよい。でも、それがマーク付けで表せないなら、
「<」記号は要る。つまり、書くか書かないかは、論理的な意味を
持つかどうかより、マーク付けで表せるかどうかの方で決まる。

同様に、HTMLで上下関係の階層が表せる要素があるなら、
「>」記号は書かないのが正しいが、それが表せないのなら
「>」記号は書かなきゃならないんじゃないだろうか。問題は
「>」記号に論理的な意味があるかどうかではなく、ol 要素等が
上下階層を表しているかどうかにあると思う。

387 ：Name_Not_Found：04/07/24 11:27 ID:???

「目を閉じいても理解出来るか否か？」
でいーんじゃないの？
紙に書いたもんではないんだからさ。

388 ：Name_Not_Found：04/07/24 11:30 ID:???

>>386
> で、パンくずリストの「>」記号に論理的な意味があるかどうかだが、
> 少なくとも、階層の上下関係を示すという論理的な意味はあるだろう。

で、HTMLの「b」要素に論理的な意味があるかどうかだが、
少なくとも、太字を示すという論理的な意味はあるだろう。

という話じゃないか？
「俺は『＞』に階層の意味を込めるぜ」なんてのは通用しないだろ。

389 ：Name_Not_Found：04/07/24 11:31 ID:???

>>386
>問題は「>」記号に論理的な意味があるかどうかではなく、

それじゃ話が振り出し以前に戻っちゃうだろうがスカタン

>で、パンくずリストの「>」記号に論理的な意味があるかどうかだが、
>少なくとも、階層の上下関係を示すという論理的な意味はあるだろう。

その「>」は、左に上の階層、右に下の階層が並べて表示されるという前提ありきだろ？（>353）
例えばolでマークアップするなら階層の深さを順序で明示できるわけだし、
HTMLに直接書き込む必要性はほとんど感じられないわけだが。なくてもいいなら必須じゃないんだし。

390 ：Name_Not_Found：04/07/24 11:39 ID:???

で、「ないことを説明する方法」はいつ教えてもらえるんですか？

391 ：Name_Not_Found：04/07/24 12:24 ID:???

俺が説明してやろう。

仕様を全部読んだ。で書いてなかった。だからない。以上。

反論したければ、仕様の書いてある場所を探してくれ。俺の代わりに。

392 ：Name_Not_Found：04/07/24 12:37 ID:???

とりあえず2.0の<nl>に待望。

。。。と思ったら久々に出てたんだな。
ttp://www.w3.org/TR/2004/WD-xhtml2-20040722/

393 ：Name_Not_Found：04/07/24 13:03 ID:???

>>390
>>383

394 ：Name_Not_Found：04/07/24 13:11 ID:???

>>388
おいおい。太いというのは見た目を示したものだが、
階層構造の上下関係は見た目を表したものじゃないだろ。

395 ：Name_Not_Found：04/07/24 13:40 ID:???

「サイトのインデックスとなるリンク文字列を列挙しているわけなのだから、リストなのではないか」
（http://homepage1.nifty.com/VET06031/web/lint100.html）

に対して疑問を持つやつはいないのかね。
ペイジの階層、位置情報に、たまたまリンクがされているとは思わないの？

396 ：Name_Not_Found：04/07/24 13:49 ID:???

簡単に言えば、∃x( φ(x) )の反対が
￢∃x( φ(x) ) ≡ ∀x( ￢φ(x) )ってこった。

397 ：Name_Not_Found：04/07/24 13:57 ID:???

>>346
こいつネタか？
1次元のものを2次元でマークアップするのは仕様違反だ

398 ：337：04/07/24 14:13 ID:???

昨日パンクズについて質問したものですが、レスがいっぱいあってびっくりしました。

とりあえず完全にCSSを抜きにして、スッピン状態でパンクズリストだとわかるようにできれば
いいんだと思います。それで、
1.top
2.chapter1
3.section1
これがolの場合のスッピンですが、果たしてこれは階層構造を示せているのでしょうか？
又、これがパンクズとしての役割を果たせますでしょうか？
もしかしたら
<p>
<a href="top.html">top</a>
＞
<a href="chapter1.html">chapter1</a>
＞
<strong><a href="section1">section1</a></strong>
＞
</p>
これが一番近いのではと思います。音声ブラウザでも「＞」は数学記号として
通用しますから、topから順に小さい関係であると理解できます。
そしてパンクズリストを道しるべとして捉えたなら、段落としてp要素でやっても
あまり問題はないかと思われます。

このp要素のタイプでいこうと思いますが、批判あったらお願いします。

399 ：Name_Not_Found：04/07/24 14:16 ID:???

質問
h1タグを2回同一ページで使用するのは間違いですか？こんな感じに
<h1 id="header"></h1>
<p></p>

<h1 id="contentsheader"></h1>
<p></p>
以下hタグを順々にマークアップ

400 ：Name_Not_Found：04/07/24 14:25 ID:???

>>399
文書全体に共通するタイトルがあればh1はそれにあたる。
即ちhead内のtitleと同じ内容であることもしばしば。

でも、だからといって文書内に一つしかh1を置けないか、と言われれば、
そうとは言えない。

文書内で最も大きな区分が、文書全体を包括することが出来ないのであれば、
h1が複数発生することはあり得る。

すまん、日本語が変かもしれん。
とにかh1が文書内に複数あるのは問題ない

401 ：Name_Not_Found：04/07/24 14:28 ID:???

"＞"
これを論理的にマークアップするのか、無意味な装飾とするのか。
無意味な装飾であるならば、なくても意味を伝えることには支障はないからこまらないはずだ。
で、困らないのか？困るだろ？

教示のときの問題だからといって、意味を伝えることに使うものをCSSでやるのは間違い。
意味はHTML
装飾、レイアウトはCSS
ここをしっかり守ってほしい。CSSを切ったときと適用されてるときで、意味が変わるのではだめだ。
1.top
2.chapter
3.section
これがCSS適用すると、なぜか番号が"＞"に変わってしまう。それはおかしい。
番号と"＞"これは同じ意味を持ってるのか？持ってないだろ？

Strictを追い求めると構造さえ論理的であればいいと思いがちだが、意味を持つものは全て
HTMLでしなきゃいけないんだ。そこを忘れてるやつが意外の多い。

402 ：Name_Not_Found：04/07/24 14:32 ID:???

403 ：Name_Not_Found：04/07/24 14:37 ID:???

>>400
>文書内で最も大きな区分が、文書全体を包括することが出来ないのであれば、

できないわけないが、h1を複数使うのは一応認められてる。しかし>>399の場合は
使うべきではない。

404 ：Name_Not_Found：04/07/24 14:41 ID:???

一応って言い方も語弊があるぞ。
大見出しが６つあって小見出し２つだろうが、大見出し１つで小見出し５つだろうが
そんなものは執筆者の自由だ。
一応も何も完全に認められてる。

405 ：Name_Not_Found：04/07/24 14:44 ID:???

>>398
＞1.top
＞2.chapter1
＞3.section1
＞これがolの場合のスッピンですが、果たしてこれは階層構造を示せているのでしょうか？
一応突っ込んで置くが、それは一般的なブラウザのデフォルトスタイル。

406 ：Name_Not_Found：04/07/24 14:49 ID:???

>>401
>で、困らないのか？困るだろ？

困る場合を挙げれ。挙げられないなら悪魔の（ry
少なくとも俺は今までolのtopic-pathで困ったことはない。

>これがCSS適用すると、なぜか番号が"＞"に変わってしまう。それはおかしい。

そう変わるように指定してるんだからおかしくないだろ。
番号は必ず表示されるとは限らないし、表示させないよう指定もできる。
表示されるか？されないか？されなければ意味を持たないか？
意味を持つものは全てそこに集約されているがそれが表示されるとは限らん。
論理的な構造を持った文書というのはそういうものだ。

407 ：337：04/07/24 14:49 ID:???

>>405
そうですよね。でもある意味数式みたいな感じで捉えるとp要素でやるのは間違いでは
ないと思いますが、それもやはり間違ってますでしょうか？

順序付きリストもよく考えれば、1番目に落とした道しるべ、2番目に落とした道しるべ
ってことで論理的である気がしてきましたが、なんとなく広く意味を伝えるのにはp要素で
やるほうがいいかなと思います。駄目ですか？

408 ：Name_Not_Found：04/07/24 14:49 ID:???

>>404
同意。大体こんなことで悩む奴は、素の文章の時点できちんとした見出しをつけたものを
かけていないんだろ。
その文章をHTMLでマークアップしていくにあたって無理矢理hnを使おうとするから困るんだよ。
もとが見出しのない文章ならhnなんて使えるはずがない。
逆に言えば見出しのない文章なんていくらでもあるわけで
それならそれでhnなんて無くてもいいんだ。
おまいら、本も読まずに文章書くなんて甘いんですよ。

409 ：Name_Not_Found：04/07/24 14:52 ID:???

パンくずってのはいままで辿ってきた道を表すもんだから(topic-pathだし)階層を表すものとは違うのでは。
>は不等号じゃなくて矢印だろうし。

410 ：Name_Not_Found：04/07/24 14:56 ID:???

「＞」が他の記号でも代替可能である（と思われる）以上、
必ずそれがHTML文書に含まれていなければならないようには思えん。

Home → Contents → Archive

とか

Home >> Contents >> Archive

とか

Home - Contents - Archive

どれでもパンくずリストとして通らないことはないだろ。
「＞」に論理的な意味があるとするのはこの点で根拠が弱い。

411 ：401 402：04/07/24 14:58 ID:???

なぜか連投すまん。

>>406
番号と＞は同じ意味ではないだろ？＞を使うのは装飾したいんじゃなくて意味を示したいわけ。
意味を示したいものをCSSでやるのはおかしい。

もちろん順序付きリストでやって、
1.top 2.chapter 3.section
とレイアウトだけ変えるのであればなんら問題はないが、番号付きリストの
1.2.3の関係を＞これで代替はできない。＜これならいいがね。

＞これ自体左辺の方が大きいという意味を持った記号で、
1.2.3は順番を表す記号
この二つは同じ意味ではないから。

って俺のいってるのは順序付きリストのマーカーを「・」これとかに変えることを
否定することになるな・・・・orzスルーしてくれ。

412 ：Name_Not_Found：04/07/24 14:59 ID:???

>>397
HTMLのtableというのは2次元のものではなく、任意の次元の情報を表わせる。
軸が1つしかなければ当然1次元。

413 ：Name_Not_Found：04/07/24 15:02 ID:???

>>411
>>353

414 ：Name_Not_Found：04/07/24 15:04 ID:???

＞ (山括弧) ではなく / (スラッシュ) ならどうだろう。

　http：//<a href="/" title="Home" rel="start">hoge.com</a>/<a href="../" title="Artworks" rel="up">artworks</a>/r-18

論理的だと思うのだが。

415 ：337：04/07/24 15:04 ID:???

>>410
要はパンクズリストとは、スタート地点からの道しるべですよね。
homeの次のcontentsの次のarchiveを今見てますよって事ですね？

<p>homeの次のcontentsの次のarchiveを今見てますよ</p>
<p>home＞contents＞archive</p>
な具合に省略されたけど段落っていうのは強引ですか？

416 ：Name_Not_Found：04/07/24 15:08 ID:???

>>412
勝手な解釈やめれ

417 ：Name_Not_Found：04/07/24 15:12 ID:???

>が述語かどうかは文脈依存だろ

418 ：Name_Not_Found：04/07/24 15:12 ID:???

>>414
必ずしもディレクトリ構造を表すものでもないからなぁ。
www.hogehoge.comがsub.hogehoge.comをtopic-pathに含めてることもあるし。

>>415
それでいいと思ったらそれでいいんでないの。
妥協してこれでいい、っていうのを誰も責めはしないし、
いや納得がいかない、っていうのを鬱陶しがったりもしないから。

ただその例だと「省略されてますよ」ってことを全員が全員解釈できるか？っていう。

419 ：401 402：04/07/24 15:12 ID:???

>>413
リストでやるとは言ってない。

420 ：Name_Not_Found：04/07/24 15:13 ID:???

>>392
立ち消えしたのかと思っていたのでちょっとだけ安心した（ｗ

421 ：Name_Not_Found：04/07/24 15:16 ID:???

422 ：337：04/07/24 15:20 ID:???

>>418
実はCSS切ったときのことを考えてるんです。もちろんそんなことを考慮するのはおかしいですが、
順序付きリストのデフォルトスタイルで果たして、理解してもらえるだろうかと思って
StrictでありながらCSS切ってもユーザにわかってもらえるものにしたいなと・・・

きっとぱんくずリストって表示にも意味があるんだとおもいます。
home>contents>archive
これを見たらだいたいの人が、「パンクズリストだ！」って自然にわかると思うんですが、
1.home
2.contents
3.archive
を見たら「何だこれ？パンクズリストかな？」みたいなかんじになると思うんですよ。

なんか
home>contents>archive
この形自体がパンクズの意味をあらわしているような気がして・・・

423 ：Name_Not_Found：04/07/24 15:20 ID:???

物事の順番表すのに

1.　AをＢする
2.　ＣをＤする。
3.　2つを混ぜ合わせる
と書こうが

AをＢする→ＣをＤする→2つを混ぜ合わせる
と書こうが
”論理的な意味”は変わらないだろ。

パンくずリストにおける">"は>>409-410の言うように矢印であるから>>411の主張は的外れだし。

ついでに、>>415の主張だと、リストそのもを否定することになりかねないよ。
リストがどういうものか言葉で説明してやりゃ段落になっちまうがな。

424 ：Name_Not_Found：04/07/24 15:24 ID:???

なんかまた速くなってるな。

>>415
パン屑リストをpで表す人もいる。
その場合
<p><a>home</a><span>の次の</span><a>contents</a><span>の次の</span><a>archive</a><span>を今見てますよ</span></p>
としてspanを消してaの間に>を入れるということをしている。
spanが必要なのはCSSの制約によるもので本当は好ましくない。

>>416
412とは違うのだがtableを行列と考えると1行/列しかない行列はベクトルだからリストなんじゃない？

425 ：Name_Not_Found：04/07/24 15:26 ID:???

>>422
>実はCSS切ったときのことを考えてるんです。もちろんそんなことを考慮するのはおかしいですが、
おかしくないし。CSSがあるときだけを考えてるようではアクセシビリティが損なわれる罠。

>を見たら「何だこれ？パンクズリストかな？」みたいなかんじになると思うんですよ。
だったら

<h2 class="topic-path-h">トップページからの経路</h2>
<ol class="topic-path">
<li>home</li>
<li>contents</li>
<li>archive</li>
</ol>

とかしてやって、あとはＣＳＳでうまいことやればいいんじゃないか？

426 ：Name_Not_Found：04/07/24 15:28 ID:???

>>424
spanなくても実現できるんじゃないか？
いったんpを全部消して、aだけ表示。aの背景に＞等を入れる。

427 ：Name_Not_Found：04/07/24 15:29 ID:???

>>426
それができないんですって。

428 ：Name_Not_Found：04/07/24 15:33 ID:???

>>426-427
話がずれてますよ。HTMLだけ考えてくださいね。

429 ：Name_Not_Found：04/07/24 15:40 ID:???

>>422
>これを見たらだいたいの人が、「パンクズリストだ！」って自然にわかる

今までのパンくずリストがそのように表示されるようにしてきたから。
暗黙の習慣に基づくものであって、それが一般的であるとは言い難い。
2chやその他の掲示板では引用冒頭部に「>」をつけることが多いが、
これが付いてればblockquote要素であるとは限らないだろ？

430 ：Name_Not_Found：04/07/24 15:54 ID:???

>>429
>
引用符。

431 ：Name_Not_Found：04/07/24 16:40 ID:???

あれ、ここですか

＞を不等号としてしか使えないインポがいるのは。

432 ：Name_Not_Found：04/07/24 16:46 ID:???

>>427
p { visibility: hidden }
p a { visibility: visible }

433 ：Name_Not_Found：04/07/24 16:58 ID:???

link要素として表す (べき) elements はそれぞれが独立して情報を持っている。
だから可分であり、 (諸事情により断腸の思いでbody要素内に書くなら；或いは思考実験(謎)的には)
これはul要素である。
対して、パンくずリストの elements はそれら全体でその文書までの経路を示している。
だから不可分であり、 (諸事情によりulかolかの二択を迫られれば；或いは(同上)) これはol要素である。

なんかだいたいこんな感じの話は前提とみなしておｋ？
つーかそもそも、前者と後者が別物だと考えるのは妥当だよね？

そして、要約するところに論点は
a) パンくずに限らず電車の乗り継ぎなども含めて、経路をolとするのは妥当か
b) olでなく例えばpとするとして、その区切りの記号として妥当なのは何 (と何)* か
ということで良いであろうか。

>>427
>>428をスルーするようだが、font-size:0;を使えば一応可能なので。
まあ区切りをどうするかとかいう問題はありますが。>>426はあまりにcheap!!!
というか結局spanか自身へのリンクが出てくるのでその意味では五十歩百歩。

>>432
それは妙な隙間が開くぞ。

434 ：Name_Not_Found：04/07/24 16:58 ID:???

>>432
全て消えましたが何か？

435 ：Name_Not_Found：04/07/24 16:59 ID:???

そうでもない

436 ：Name_Not_Found：04/07/24 17:17 ID:???

パンくずの > は一般的に用いられているから、ユーザの混乱をなくすために統一して用いているだけ。
だから
<p> 2ch のネット関係カテゴリの Web製作板の Strict スレの 436 番目のレス</p> でも
<ol><li>2ch</li> <li>ネット関係</li> <li>Web製作</li> <li>Strict</li> <li>436</li></ol> でもよい。
これが結論。

というのに100レスも消費か……折角だからもっと深く掘り下げてくれよ

437 ：Name_Not_Found：04/07/24 17:17 ID:???

>>434
displayと勘違いしてない？

438 ：Name_Not_Found：04/07/24 17:25 ID:???

>>431
悪魔の証明は理解できたの？

439 ：337：04/07/24 17:50 ID:???

色々考えましたが現状のまま、olとしてやって記号はCSSでやることにしました。

440 ：Name_Not_Found：04/07/24 18:05 ID:???

>>438
「ある」ことを証明するのは「実際にある」
事を示せば、とそれが一番の証明で、

「ない」ことを証明することは非常に困難であると。
ようするにあれだろ　検証に対して（対さないんだけど）、
反証は対称とは言えない、非対称であると。

即ち、「ある」という事象はごく一部の事実から
（正しいかどうかは別として）導き出すことが出来るのに対して、
「ない」という事象は「全事象」を検証する以外に（特別な場合を覗いて）、
立証は出来ないと。

ならば、「あることを証明出来ないならば無い」と。
それが論争の場では止むを得ず用いられる論法とされているわけだな。
「無いことを証明する」側の不利さをカバーするために。

で、何の話だっけ。

441 ：Name_Not_Found：04/07/24 18:06 ID:???

HTML4.01で構成してますが、link要素のrelの値には仕様書に書いてあるもの以外は使ってはいけませんよね？

top>category>item1
みたいな場合に、item1に書くリンク要素は
<link rel="strat" href="top.html">
<link rel"parent" href="category">
<link rel="next" href="item2.html">

のようにしたいのですが、parentは仕様には載ってないのでやはりおかしいでしょうか？

442 ：440：04/07/24 18:11 ID:???

スマン文が変だ
書き直す

「ある」ことを証明するには「実際にある」
事を示すのが一番有効な手段で、
「ある」という事象はごく一部の事実から
（正しいかどうかは別として）導き出すことが出来る。

それに対して、
「ない」という事象は「全事象」を検証する以外に（特別な場合を覗いて）、
立証は出来ない。ようするに　検証に対して（対さないんだけど）、
反証は対称とは言えない、非対称である。

ならば、「あることを証明出来ないならば無い」と。
それが論争の場では止むを得ず用いられる論法とされているわけだな。
「無いことを証明する」側の不利さをカバーするために。

で、何のｒｙ

443 ：Name_Not_Found：04/07/24 18:15 ID:???

そういやリンク要素で思い出したけど、前から疑問に思ってたけど、
another-lintではstrictでチェックすると
<link rel="next"～>
がないよって言う警告でるけど（減点なし）最後のページってnextなんかないよね。
そこらへんはどうなん？

444 ：Name_Not_Found：04/07/24 18:15 ID:???

>>441
仕様にlink要素のrel/rev属性に
「文書の相互関係」以外の制約があったとは記憶してない。
仕様書に記されているのは、文書の相互関係の一例で、
尚かつそのうち記入することを推奨しているもの。

すまん、英語力が無いから今更仕様書を読み直す気にはならない。
記憶違いもあるかもしれん。

445 ：Name_Not_Found：04/07/24 18:19 ID:???

文書というよりはDocument、って言うべきだったか？

まぁいいや

446 ：441：04/07/24 18:24 ID:???

>>444
ありがとうございます。和訳を見たんですが、多分俺が勝手に勘違いしただけだと思います。
あそこにあるのは推奨される一例で、自分で関係を記述するのもありなんですね。

ありがとうございました。

447 ：Name_Not_Found：04/07/24 18:39 ID:???

>>441
まだ見てるかな。
仕様書に無いリンクタイプも使うことはできる。
ただしその場合headのprofile属性を設定するべきとされている。
実際にはprofile属性を設定せずに仕様書に無いリンクタイプを使うことが多い。
詳しくは「リンクタイプの深淵 [QUIA]」
http://www5d.biglobe.ne.jp/~quia/tech/html/linktype.html
あたりを参照のこと。

448 ：Name_Not_Found：04/07/24 19:21 ID:???

>>443
「<HEAD>～</HEAD>内に<LINK REL="NEXT" HREF="～"> などの
ナヴィゲーション用のリンクが含まれていません。」のこと？
「など」だから、別にnextじゃなくてもprevとかcontentsとか
書いておけば出ないよ。

449 ：Name_Not_Found：04/07/24 20:09 ID:???

というかAHLを絶対の基準にするなと

450 ：Name_Not_Found：04/07/24 20:30 ID:???

>440

>442

＞に論理的な意味がある気がする
　↓
ない
　↓
ない理由を説明しろ

という「バカにサンドイッチされてる人」がいた、ってこと。

451 ：Name_Not_Found：04/07/24 20:50 ID:???

>>450
よく考えるとこれは、あるかないかの問題じゃなくて、
「論理的な記号」か「物理的な記号」かの問題であって、
悪魔の証明とは全然関係ないんじゃないのか？

452 ：Name_Not_Found：04/07/24 21:16 ID:???

>>451
論理的じゃない、を照明しろ、って言ってるんだし

453 ：Name_Not_Found：04/07/24 21:22 ID:???

>>451
じゃあ、簡単に。

「俺は　＞　に　階層の前後　って意味を込めるぜ」
ってのは、
「俺は　b要素　に　強調　って意味を込めるぜ」
ってのと同じ。自分にしかわからないルール（仕様書に記載されてないもの）を用いて、「それに則ってるから論理的」ってのは正しくないわけだ。

「強調」を青くする、と定義することはできるが、
「青」を強調する、というのは青が論理的でない、ってのと同じ。

「階層」を＞で表す、
「＞」を階層と解釈する、という違いである、と。

454 ：Name_Not_Found：04/07/24 21:46 ID:???

>>453
しかし問題はHTMLに階層構造を表す要素がないことだな。
それが存在すれば元々こんな議論は必要ないわけで...。

一方、強調を表す要素はあるわけで、それと比較されても...
という感じもする。

455 ：Name_Not_Found：04/07/24 22:05 ID:???

<b>と<strong>との話をしてるんだとおもうが、

物理的意味合い、というのは要するに
太字か、そうでないか、という差だろ。

それに対して論理的意味合い、というのは
その部分が文書に対して強調されているかいないか、っていう差だ。

だから、<b>に対して強調、って意味を込める必要性はまるでない。
<strong>っていう立派な強調、の意味があるんだから。

確かに「階層」を＞で表すのは仕様外だ。
でも、「階層」は仕様に無い。

まぁだから>>454の言う通り、ここに<b>要素の理論を持ち込むのは間違っている。

じゃあ仕様内で表せない事態が発生した。
即ち、文書内で「階層」を表現したい。
ではどうするか。という事だな。

456 ：Name_Not_Found：04/07/24 22:08 ID:???

>>450
なるほろ。
そこに悪魔の証明が何たらだったのか。

まぁ確かに＞が持つ論理的な意味は「だいなり」であって
階層ではないな。
階層としての意味を持っている事は証明不可能だ。
「慣習」は無視したとして。

従って無いと言うより他無い。
よく分かった。ありがとう

457 ：354：04/07/24 22:20 ID:???

>>422
だから>>354でいいじゃないか。

1.home
2.contents
3.archive
これだとなんだかわからなくても、

・home
　・contents
　　・archive
これならわかるだろ。

458 ：Name_Not_Found：04/07/24 23:40 ID:???

>454

>455

「適切な要素を使え」というたとえじゃなくてだな、
>>456の言うように、「「慣習」は無視」だろ？って言いたいんだよ。

「＞は（慣習的に）階層の前後を繋いでる」
ってのは、
「font color="red"は（慣習的に）注意書きを表してる」
と同じ類だろう、って。

459 ：Name_Not_Found：04/07/25 00:23 ID:???

>>457
>>423
について意見ぷりず

460 ：Name_Not_Found：04/07/25 00:49 ID:???

そろそろ自演やめれ。
ぱんくずの話はもう終ってんだよ。

続けるならせめて階層構造をどうやってマークアップするかにしぼってくれ。
ぱんくずは階層を言ってるのではなく経路としての意味を持ってるんだから
olでやるのが一般的。そのほかでやるのは勝手にして。

>>457
どうせネタだろうけど、一応突っ込んでやる。
視覚系UAのデフォルトの見栄えと、論理的であるかないかは関係ない。

461 ：Name_Not_Found：04/07/25 01:04 ID:???

>>460
>>457じゃないけど、
深く掘り下がってる見えるから階層だ、って言ってるわけじゃなくて、
liの中のｌｉ、liの中のliの中のliだから下の階層だとわかる、って意味じゃないかな。

例えば仕様書の
http://www.w3.org/TR/1999/REC-html401-19991224/about.html#h-1.2.2
なら、
<ol>
<li><a class="tocxref" href="about.html" rel="chapter">About the HTML 4 Specification</a>
<ol>
<li><a class="tocxref" href="about.html#h-1.2">Document conventions</a>
<ol>
<li><a class="tocxref" href="about.html#h-1.2.2">Notes and examples</a></ol></ol></ol>
ということで。

462 ：461：04/07/25 01:08 ID:???

>>461の補足。
仕様書のFull Table of Contentsが
About the HTML 4 Specification の中の How the specification is organized 、Document conventions という記述の仕方をしてる。
olでね。

463 ：Name_Not_Found：04/07/25 01:08 ID:???

>>460
その経路は階層をたどったものなわけだが。

464 ：Name_Not_Found：04/07/25 01:12 ID:???

ぱんくずリストに関しても既存の議論ログが山ほどあるよね。
ま、話題にでるのはそんなのばっかだから別に文句じゃないが。

465 ：Name_Not_Found：04/07/25 01:13 ID:???

ちょっとパンクズの話に近くなってしまうかもしれないが、
◆とかの記号を文中に使うのはStrictだと思う？

意味を持たない文字を文中に記述できるかどうか、意見を伺いたいのですが。

466 ：Name_Not_Found：04/07/25 01:15 ID:???

>>465
どういう目的で使うのかによるが、
気になるなら、

<li><span class="no-style">◆</span>入口</li>

でCSSを使う感じでやればいいんじゃないの？

467 ：Name_Not_Found：04/07/25 01:17 ID:???

>>465
それだけで判断しろと？

<p>結晶が◆の形になって目に見えるようになります</p>
なら意味のあるものだろうし、
<dt>◆センター</dt>
<dd>真ん中</dd>
だったら記述すべきじゃない。

468 ：Name_Not_Found：04/07/25 01:18 ID:???

>>466
「これはスタイルを切ってるとき用のものですよ」なんて論理的じゃないと思うわけで。

469 ：村人1：04/07/25 01:23 ID:???

<span title="菱形">◆</span> と書くくらいなら菱形と書くだろうな

470 ：Name_Not_Found：04/07/25 01:24 ID:???

>>469
そんな話はしてないよ。

471 ：Name_Not_Found：04/07/25 01:25 ID:???

>>467
そう、あえてこれだけで判断したいと思った。

読み上げブラウザを考慮した場合、視覚情報としてしか意味の無い文字の
記述を認めるられるかどうか気になった。
　<p>結晶が◆の形になって目に見えるようになります</p>
　なら意味のあるものだろうし、
なら「しかく」と読み上げてくれればＯＫだし、
　<dt>◆センター</dt>
　<dd>真ん中</dd>
なら読み上げなければＯＫかなと思って、ちょっと伺ってみています。

472 ：Name_Not_Found：04/07/25 01:29 ID:???

>>471
これは「ひし」でも「しかく」でも変換されるから読み上げるときはどっちで読み上げるのかわかんないね。
読み上げツールのメーカー次第、とかかな。やっぱ「菱」か「四角」か、どっちとして書いたのかをわかるようにすべきだと思うけど。

＞そう、あえてこれだけで判断したいと思った。
あんたが判断するのは自由だが、人に尋ねたいならもっと丁寧に聞けよ。
人が答えてからそういう意味で聞いた、みたいに言われてもな。
「意味のある◆と、意味のない◆の場合は」とか。

473 ：Name_Not_Found：04/07/25 01:31 ID:???

>>472
ごめん。

474 ：Name_Not_Found：04/07/25 01:34 ID:???

>>473
もう一つ言っておくが、strictってのは読み上げとかのためにあるんじゃないぞ。
あくまでもstrictにしておくと、読み上げへの配慮もできる、ってだけで。
読み上げで問題がクリアできるからOKってスタンスなら、どのブラウザでも人間が理解できるものならOKって理屈になってしまう。

475 ：Name_Not_Found：04/07/25 01:39 ID:???

>>461
これを見ると、ol のリストは同じ階層内の順序を表していて、
階層の違いは ol の入れ子で表してるみたいだな。

476 ：Name_Not_Found：04/07/25 01:42 ID:???

>>475
てか
・○○○
　　・○○○
　　　　　・○○○
の例を挙げてた人はみんなそういう意味で言ってたんだと思うんだが。
「見栄えで階層」と言ってるわけじゃないかと。

477 ：Name_Not_Found：04/07/25 01:43 ID:???

ネタ切れだね。自演乙。

実際のとこ議論することなんかだよな。仕様書読んで来いって話だよ。仕様書読んだら
疑問なんか何もなくなるよ。

著作権表示くらいかな。

478 ：Name_Not_Found：04/07/25 01:44 ID:???

>>477
何でそう釣ろうと必死なの？

479 ：Name_Not_Found：04/07/25 01:45 ID:???

>>477
疑問なんかなんもないあんたならさっくり解決させてくれるだろ。
今現状で出てる陳情全部解消してくれ。
仕様書読めと過去ログ読めの場合は参照先も明示してな。

480 ：Name_Not_Found：04/07/25 01:46 ID:???

>>478
これは釣りじゃないよ。
恐らく「＞は論理的」と言ってたトンチキとか、
「olのネストで階層を現せない」と言ってたトンチキとか、
いずれかのトンチキだよ。

481 ：477：04/07/25 01:51 ID:???

>>479
何が疑問なんだ言ってみれ。

482 ：Name_Not_Found：04/07/25 01:54 ID:???

>>481
正しいパンくず。

483 ：477：04/07/25 01:58 ID:???

>>482
ギャグ？
<ol class="topic-path"><li>home
　　　　　　<ol><li>contents
　　　　　　　　　　　　　　　<ol><li>archive</li></ol>
　　　　　　</li></ol>
</li></ol>

484 ：Name_Not_Found：04/07/25 02:00 ID:???

>>483
それ、俺が答えたやつなんだけど。
終わってからしゃしゃって既出の回答か。めでたいね。

485 ：Name_Not_Found：04/07/25 02:00 ID:???

>>483
その手の記述をするときはulにすべきだと思うがどうか

486 ：Name_Not_Found：04/07/25 02:02 ID:???

>>485
順序はない、と？

487 ：477：04/07/25 02:05 ID:???

>>485
やるなおまいは！
確かに順序はないな！
お前最高

488 ：Name_Not_Found：04/07/25 02:05 ID:???

パンくずリストの議論をまとめたページとかないのか？

489 ：Name_Not_Found：04/07/25 02:05 ID:???

>>486
深さ方向の順序はあると思うけど、>>483みたいに書くと全部１になるような気が。

490 ：489：04/07/25 02:06 ID:???

出遅れた。

491 ：Name_Not_Found：04/07/25 02:07 ID:???

>>489
その階層の、他のものを記述していないから1だけになるのであって、
その階層の、

んー、どっちでも好きなほうで、な気がするんだがな。
どっちも間違いではない、と。

492 ：477：04/07/25 02:08 ID:???

>>489
>深さ方向の順序はあると思うけど
深さは階層ね。番号は深さの順番を表すものじゃないからね。わかってると思うけどさ。
多分おまいは>>485でいい発言した俺よりも頭のいいやつだろ。

493 ：477：04/07/25 02:10 ID:???

>>491
おまいは間違い。
home>chapter3>section4
なんかの場合に全てが１ではおかしい。だからulだ。とりあえずおまいは>>485の爪の垢でももらえ。

494 ：Name_Not_Found：04/07/25 02:13 ID:???

リストみたいに横の方向に広がる情報を記述できるタグの他に
ディレクトリのパスみたいに縦の方向に広がる情報を記述できるタグがﾎｽｨ。

うーん、上手く言えない。

495 ：Name_Not_Found：04/07/25 02:13 ID:???

>>493
<ol class="topic-path"><li>home
　　　　　　<ol><li value="3">chapter3
　　　　　　　　　　　　　　　<ol><li value="4">section4</li></ol>
　　　　　　</li></ol>
</li></ol>

自分が使わない属性をないもののように扱わないでくれ。

496 ：Name_Not_Found：04/07/25 02:14 ID:???

>>494
いや、だからリストの入れ子、だろ。

497 ：477：04/07/25 02:16 ID:???

>>495
ここはStrictスレだぞ。

498 ：Name_Not_Found：04/07/25 02:16 ID:???

477は大好きな仕様書を読みに行きました

499 ：Name_Not_Found：04/07/25 02:17 ID:???

>>496
リストの入れ子でもいいけど、
なんかこう、一直線の従属関係を示せるような感じの。

500 ：Name_Not_Found：04/07/25 02:18 ID:???

>>497
お帰り。仕様書の推奨しないを探すのにずいぶん掛かったね。

＞全てが１ではおかしい。
全てが１だからおかしい、って発想がおかしい、ってこと。
もともと、その階層のリスト、下の階層のリスト、が存在して、
他の部分を削除したもの、がパンくずなんだから、「全てが１ではおかしい。」という理由で順序がないというのはおかしい。

501 ：Name_Not_Found：04/07/25 02:18 ID:???

>>495
それはもはやパンくずリストではないと思うけどな。

502 ：Name_Not_Found：04/07/25 02:18 ID:???

>>499
どういうものを指してるのか想像できない。
架空の要素でマーク付けしてみてくれないかな？

503 ：Name_Not_Found：04/07/25 02:19 ID:???

>>501
なんで？
もしかして＞じゃなくて数字が入ってるから、とか言わないよね？

504 ：Name_Not_Found：04/07/25 02:19 ID:???

>>500
他の部分を削除したら順序なくなるだろ。

505 ：Name_Not_Found：04/07/25 02:20 ID:???

>>503
パンくずリストは経路を明示するためのもので、
途中パスの順序（？）は不要な情報だから。

506 ：477：04/07/25 02:20 ID:???

>>498-500
妄想が激しいな。

507 ：Name_Not_Found：04/07/25 02:21 ID:???

>>504
いや、だからさ。
自分が「順序有るものの中の一部」と思うのならol、逆もまた然り、と>>491で言ったつもりなんだけど。

508 ：477：04/07/25 02:22 ID:???

仕様書を読めない馬鹿が暴れてるだけっぽいな。

509 ：Name_Not_Found：04/07/25 02:23 ID:???

>>502
<pl>
<pt name="usr" rev="root">usr</pt>
<pt name="bin" rev="prev" href="#usr">bin</pt>
<pt name="mc" rel="prev" href="#bin">mc</pt>
</pl>

こんな感じで、binの前はusrだよ。みたいな。
/usr/bin/mcって感じで表示してくれたり。

510 ：Name_Not_Found：04/07/25 02:24 ID:???

>>504
その考え方だとリストを作りまして、二つ目が出来たらolに書き換える、ということになるのかな。
一個しかなくても、順序あるリストならolだと思うんだけど。

<h2>今日食べたもの</h2>
<ol>
<li>ニラ</li>
</ol>

511 ：Name_Not_Found：04/07/25 02:24 ID:???

・ぱんくず
・パンくず
・ぱん屑
・パン屑

どれがいい？

512 ：Name_Not_Found：04/07/25 02:25 ID:???

>>510
それは他のものを削除したわけじゃないでしょ？

513 ：Name_Not_Found：04/07/25 02:25 ID:???

>>509
間違えた　<pt name="mc" rel="prev" href="#bin">mc</pt>
正しくは　<pt name="mc" rev="prev" href="#bin">mc</pt>

514 ：Name_Not_Found：04/07/25 02:25 ID:???

>>509
なるほど。

>>508
自己紹介か。

515 ：477：04/07/25 02:27 ID:???

>>509
それ結局階層構造だろ。何を求めてるんだ？ソースを短く済ませたいとかって事か？

516 ：Name_Not_Found：04/07/25 02:28 ID:???

とりあえず序列リストの定義から入らないと埒が明かないな。
仕様書には序列は数字が付くかもよ。順不同は付かないよ。としか書かれてないし。

>>477は仕様書に精通してるんだろ？　定義を聞かせてくれないか？

517 ：Name_Not_Found：04/07/25 02:30 ID:???

>>508
無駄に煽るのｲｸﾅｲ!!
仕様書を読めるだけの馬鹿って言われちゃうよ。

518 ：Name_Not_Found：04/07/25 02:30 ID:???

書いてないことも仕様書読めばわかる天才

519 ：Name_Not_Found：04/07/25 02:31 ID:???

>>515
リストは入れ子にできる、ってあるだけで
本質は並列した情報を記述するためのタグな気がするんですよ。

そこで、階層構造の情報を記述するためのタグが欲しくなったです。

520 ：Name_Not_Found：04/07/25 02:32 ID:???

パンくずリストの論理的解釈が異なってるからマークアップがことなってるんだな。

すべてのページをあらわした木から、必要となるパスを取り除いたものとしたら、
リストの入れ子になる。もしここで、ノードの兄弟関係に順序が存在するならolだろうし、存在しないならulの入れ子となる。

一方で、トップページから現在表示しているページへの順序を表している場合、１次元の順序リストであらわすことになる。

と。
上と下どちらがいいのか、はたまたどちらでもいいのか、要点はそこだな。
パンくずりすとの由来を考慮して、おれは下を推す。

521 ：477：04/07/25 02:32 ID:???

>>516
>とりあえず序列リストの定義から入らないと埒が明かないな。
理解できてないのはお前だけ。仕様書を読んでも理解できないからって暴れるなよ。

522 ：Name_Not_Found：04/07/25 02:33 ID:???

>>519
待て待て。
li要素の中のli要素は「li要素の中のli要素」ときっちり階層を示してるじゃないか。
入れ子に出来る、ってそういう意味だろ？

523 ：Name_Not_Found：04/07/25 02:33 ID:???

>>521
仕様書には序列は数字が付くかもよ。順不同は付かないよ。としか書かれてないし。

>>477は仕様書に精通してるんだろ？　定義を聞かせてくれないか？

524 ：Name_Not_Found：04/07/25 02:34 ID:???

この板だとコテが痛くなるのか、この板で痛いやつがコテになるのか。

525 ：477：04/07/25 02:34 ID:ZNWTdUpI

とりあえずidを出してくれないか？
アフォが一人で暴れてるだけにしか思えない。

526 ：Name_Not_Found：04/07/25 02:35 ID:???

とすると、パンくずはこんな感じ？順序がいるからolで。

<h1>このページまでの順序</h1>
<ol>
<li><a href="xxx">トップページ</a></li>
<li><a href="yyy">板リスト</a></li>
<li><a href="zzz">Web製作技術</a></li>
</ol>

527 ：Name_Not_Found：04/07/25 02:36 ID:???

>>525
あることの説明要求されてるんだから、OL要素とUL要素の定義を仕様書を元に説明してあげればいいんじゃないのか？

528 ：Name_Not_Found：04/07/25 02:36 ID:???

>>526
えさつけなきゃダメだよ。

529 ：Name_Not_Found：04/07/25 02:39 ID:???

>>526のように、単純に順序、と考えるのも間違いではないんじゃないかな。

530 ：Name_Not_Found：04/07/25 02:42 ID:???

>>529
>>520

531 ：Name_Not_Found：04/07/25 02:44 ID:???

>>530
つまりどっちも正しい、ってことだよね？

532 ：Name_Not_Found：04/07/25 02:44 ID:???

パンくずの話をしてる香具師はその間だけ名無しさんをやめてほしい。
実のない議論がスレを消費してるだけに見えるぞ。

533 ：Name_Not_Found：04/07/25 02:44 ID:???

>>532
パンくず以外の話が出てないんだが。

534 ：Name_Not_Found：04/07/25 02:45 ID:???

>>531
そんな気がしてきた。

535 ：Name_Not_Found：04/07/25 02:45 ID:???

>>532
確かに実がないな。
漏れ的には仕様書に書かれていない序列と順不同の定義が知りたい。

536 ：Name_Not_Found：04/07/25 02:47 ID:???

そこらへんのことが書かれてるRFCとかないのかな。

537 ：477：04/07/25 02:49 ID:ZNWTdUpI

>>526-536
一人で楽しいか？

538 ：Name_Not_Found：04/07/25 02:50 ID:???

>>537
説明まだ？

539 ：Name_Not_Found：04/07/25 02:52 ID:???

<ol>
<li>質問された</li>
<li>仕様書を読みに行った</li>
<li>本当に載ってなかった</li>
<li>話をそらそうと思った</li>
</ol>

540 ：526=534：04/07/25 02:53 ID:???

>>537
いや、俺は二つしか書いてない。
パンくずは>>520の言ってることで納得したよ。

# 実は526を書いてみたとき、>>520をろくに読んでなかった。

541 ：Name_Not_Found：04/07/25 02:55 ID:???

>>540
気にするな。反論するやつは脳内で一人に仕立て上げないと恐怖に心が支配されちゃうタイプのやつだ。
コテハンって自己顕示欲が強いくせに臆病だよな。

542 ：477：04/07/25 02:55 ID:ZNWTdUpI

黙ってid出せよ。

543 ：526=534：04/07/25 02:56 ID:NM+b4XCl

idってこう？

544 ：Name_Not_Found：04/07/25 02:57 ID:???

>>542
説明まだ？

521 名前:477 投稿日:04/07/25 02:32 ID:???
> >>516
> >とりあえず序列リストの定義から入らないと埒が明かないな。
> 理解できてないのはお前だけ。仕様書を読んでも理解できないからって暴れるなよ。

仕様書読んで定義が理解できなかったから、理解できてるあなたに頼んでいるんだけど。

545 ：Name_Not_Found：04/07/25 02:58 ID:???

>>543
こいつに自演と思われたところで、こいつが回答できないこととは無関係なんだし合わせることはないよ。
あと、漏れがid出さなければあんたが出したのも無意味だしね。

546 ：526=534：04/07/25 02:59 ID:NM+b4XCl

>>542
出したけど、あんまり意味ない気が。
俺はもう納得してるし。

547 ：Name_Not_Found：04/07/25 02:59 ID:???

一人なのかどうなのか、なんてどうでもいいだろ？　>>477は一人ぼっちなのがよくわかるけど。

548 ：Name_Not_Found：04/07/25 03:00 ID:???

>>543 & >>545

>>546 & >>547

性格の激変にﾜﾛﾀ

549 ：Name_Not_Found：04/07/25 03:03 ID:???

>>542
> 黙ってid出せよ。

これって、>>477がID出して黙って消える、という暗示だったのかな。

550 ：477：04/07/25 03:05 ID:ZNWTdUpI

で、結局一人しかいないのね。

551 ：Name_Not_Found：04/07/25 03:06 ID:???

回線切ってip変えたり携帯から書き込んだり、と複数を装うことは出来る。
複数いることを証明しろ、ってのは悪魔の証明じゃない？

552 ：526=534：04/07/25 03:06 ID:NM+b4XCl

俺だって仕様書ぐらい読めるし、477に聞く必要も無いよ。
俺はパンくずの表現方法がすっきりわかったから、もうＯＫ。

553 ：Name_Not_Found：04/07/25 03:06 ID:pMqGk6RP

で、結局答えられないのね。

554 ：Name_Not_Found：04/07/25 03:08 ID:???

一人かどうかに固執するふりをして必死に話を変えたがってるな。

555 ：532：04/07/25 03:09 ID:ndvg7+Q2

漏れが出して意味あるの(・∀・)?

556 ：477：04/07/25 03:10 ID:ZNWTdUpI

>>551
複数を証明してほしいわけじゃなくて、idなしだと自演ばっかで荒れ放題って事にもなるでしょ。
みんながid出してればとりあえず一人1意見でハッキリするから話しやすい。

まあidを使い分けるほど真性なやつはそうそういないでしょ。
だからidを出して、悩んでることを具体的に言うのであればレスをつけるよ。

557 ：Name_Not_Found：04/07/25 03:10 ID:pMqGk6RP

>>555
悪魔の証明だよな。これって。
騙られている、とかの証明にはトリップとかあるけど、「別のID」で別人を証明するのは無理だろ。

558 ：526=534= p36095-adsao12honb4-acca.tokyo.ocn.ne.jp：04/07/25 03:12 ID:NM+b4XCl

>>557
フシアナサンは効果あると思う。
さすがに大手プロバイダを二つも持ってる人は、そうはいないと思う。

559 ：Name_Not_Found：04/07/25 03:12 ID:pMqGk6RP

>>556
そういうことか。

521 名前:477 投稿日:04/07/25 02:32 ID:???
> >>516
> >とりあえず序列リストの定義から入らないと埒が明かないな。
> 理解できてないのはお前だけ。仕様書を読んでも理解できないからって暴れるなよ。

仕様書読んでも
Ordered and unordered lists are rendered in an identical manner except that visual user agents number ordered list items. User agents may present those numbers in a variety of ways. Unordered list items are not numbered.
としかありませんでした。

定義が理解できなかったから、理解できてるあなたに教えて欲しいです。

560 ：520：04/07/25 03:13 ID:ZLmOJA2I

>>550
居ますがね。

ずっとみてるわけじゃないのよ。

561 ：477：04/07/25 03:14 ID:ZNWTdUpI

>>559
それは階層構造をリストでやるべきか？っていう部分から出た疑問なの？

それとも階層構造をやるのはいいけど、olでやるかulでやるかっていう部分からの疑問なの？

562 ：526=534：04/07/25 03:15 ID:YTRt3r08

>>560
おかげですっきり寝れます。ええ、ええ。

563 ：Name_Not_Found：04/07/25 03:16 ID:???

>>561
一個だったら順不同ですか？

564 ：526=534：04/07/25 03:16 ID:YTRt3r08

id変わった！変わるな…。
では、おやすみ。

565 ：Name_Not_Found：04/07/25 03:18 ID:???

>>556
> 複数を証明してほしいわけじゃなくて、idなしだと自演ばっかで荒れ放題って事にもなるでしょ。
多分いきなり現れて罵倒する行為、の方が荒れる原因になると思う。

477 名前:Name_Not_Found 投稿日:04/07/25 01:43 ID:???
> ネタ切れだね。自演乙。
>
> 実際のとこ議論することなんかだよな。仕様書読んで来いって話だよ。仕様書読んだら
> 疑問なんか何もなくなるよ。
>
> 著作権表示くらいかな。

566 ：477：04/07/25 03:19 ID:ZNWTdUpI

>>563 >>565
idないね

567 ：563：04/07/25 03:21 ID:???

>>566
思うんだけどさ。
なんであんたに従わなくちゃならないの？
ID出してなくても、>>559の回答に対する質問なんだから>>559ってわかるでしょ？

568 ：Name_Not_Found：04/07/25 03:22 ID:???

複数かもしれない、と想像すると不安で仕方がないんだな。

569 ：Name_Not_Found：04/07/25 03:24 ID:???

あら、age進行になったの? このスレ。

570 ：Name_Not_Found：04/07/25 03:25 ID:???

>>569
ageろ厨が暴れてるんだよ。

571 ：Name_Not_Found：04/07/25 03:26 ID:???

http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
の488-510をみると入れ子について語られてる。

572 ：Name_Not_Found：04/07/25 03:29 ID:???

>>570
そうでしたか。じゃ、収まるまでXHTML2.0 WDでも読んでます。

573 ：Name_Not_Found：04/07/25 03:30 ID:???

>>571
これって「実装しょぼいから、こうしたほうがええで」って話だろ？
NN4.ｘではCSSが～テーブルレイアウト推奨、ってのと大差ない気がするな。

574 ：477：04/07/25 03:30 ID:ZNWTdUpI

>>563
idないけど結構真面目な質問みたいだから一応。

順序付きリストか順序なしリストかは、まずは<li>要素が増えたときのことを考え手ほしい。

上のほうで誰かが言っていたtransitionalだが<li value="3">は結局その階層の3番目のリストだと
示したいわけだけど、その場合は<li>要素をその階層に3つ作りCSSで消すといい。
それで今いる場所として、<strong>を使えばぱんくずをolでやってもおかしくはない。

なぜvalueがstrictでは駄目なのかを考えると理解できると思うよ。valueは所詮見栄えであって論理的なものでは
ないとW3Cが捉えているから。論理的な３つめとはol内の<li>要素の3つ目であり、番号とは無関係なんだよね。

575 ：Name_Not_Found：04/07/25 03:33 ID:???

>>574
いや、やり方じゃなくて。

＞示したいわけだけど、その場合は<li>要素をその階層に3つ作りCSSで消すといい。
この場合は「抜き出したいものだけを表示する」という意味だよね？

＞valueは所詮見栄えであって論理的なものでは
てことは、「抜き出したものは順序あるリストではない」ということだよね？

じゃ、順不同リストになる、でFA？

576 ：477：04/07/25 03:37 ID:ZNWTdUpI

>>575
論理的なマークアップは表示を考えることではなくて、CSSは論理的な構造に影響を与えるものではないって
事は理解してると思うけど

>てことは、「抜き出したものは順序あるリストではない」ということだよね？
この抜き出したものっていうのがわからない

577 ：Name_Not_Found：04/07/25 03:41 ID:???

>>576
上記のほうは、

　　1.ああああ
　　　　　1.いいい
　　　　　2.ううう
　　　　　3.えええ
で中の1.いいい　3.えええを非表示にする、ってことでしょ？

　　1.ああああ
　　　　　2.ううう
だったら（てやりたかったら、って意味）、liの中のliは既に「序列リストの一部だった」という情報はないんだよね？　って。

578 ：477：04/07/25 03:48 ID:ZNWTdUpI

>>577
どっちの意味だろうか？

>liの中のliは既に「序列リストの一部だった」という情報はないんだよね？　って。
HTMLにちゃんと３つの<li>要素があれば表示無関係に順序付きリストだけど
HTML自体に3つの<li>要素がない場合は順序付きリストでやるのは不可能。

困るのはulでやったとしても、この場合<li>要素が増えると順序付きリストであるべきになってしまい、
<li>要素が増えることが不可能なリストになり、それは結局リストではないことになる。
これって結構問題。

579 ：Name_Not_Found：04/07/25 03:52 ID:???

>>578
　　1.ああああ
　　　　　2.ううう
　　　　　3.えええ
とか。VALUE属性使えないんだから、　ううう　えええ　は「順序などないものなのだ」としてしまうしかないわけなんだよね？

580 ：Name_Not_Found：04/07/25 03:57 ID:???

元のリストは順不同のulで構成し
liが増えて順序の意味づけをしてやるべきところができたら
その部分をolで入れ子にしてやればいいんじゃないの？

581 ：Name_Not_Found：04/07/25 03:58 ID:???

>>580
よくわからない。
>>579をマーク付けしてみてくれないか？

582 ：477：04/07/25 04:01 ID:ZNWTdUpI

home
contents
section
これ以外のものをHTMLに書きたくなければdivの入れ子で階層を作るしかないかな。
<div class="topic-path">home
　　　　　　　　　　　　　　<div>contents
　　　　　　　　　　　　　　　　　　　　　<div>section</div>
　　　　　　　　　　　　　　</div>
</div>
ちゃんと全部書くなら↓
<ol class="topic-path"><li><strong>home</strong>
　　　<ol><li><strong>chapter1</strong>
　　　　　　　　　<ol><li>section1</li>
　　　　　　　　　　　<li><strong>section2</strong></li>
　　　　　　　　　　　<li>section3</li></ol></li>
　　　　　<li>chapter2</li></ol>
</li></ol>

rootはひとつ以上にならないはずだからリストでなくてもいいね。

583 ：_：04/07/25 04:04 ID:???

valueが非推奨なことから考えてorderedというのは要素の間に前後関係が定義できるかということじゃないのかな。
で、ulはただの集合を表すんじゃないだろうか。
例えば
<ol><li>a</li><li>b</li></ol>
<ol><li>b</li><li>a</li></ol>
は違うもので
<ul><li>a</li><li>b</li></ul>
<ul><li>b</li><li>a</li></ul>
は同じものということじゃないだろうか。

だから1,3,7のように値が飛んでいてもolなんじゃないのかな。
もちろん仕様書にはないから推測にすぎないし、これだと視覚的UAが数値を付けてレンダリングすると書いてあることが説明できないけど。

584 ：583：04/07/25 04:06 ID:???

_だけじゃID出ないのか。

585 ：Name_Not_Found：04/07/25 04:13 ID:???

<li>要素の中にブロックレベル要素いれられるから<hn>を入れて
見出しの名前とレベルで表すのは？

586 ：583：04/07/25 04:14 ID:???

>>585
コンテンツではないパン屑リストにそこまでしなくても。と思う。

#結局IDの出し方が分らない。

587 ：Name_Not_Found：04/07/25 04:14 ID:???

>>585
実際のマークアップ例をキボンヌ

588 ：Name_Not_Found：04/07/25 04:16 ID:???

>>583
メール欄のsageを取る。

589 ：Name_Not_Found：04/07/25 04:23 ID:???

>>586
「コンテンツではない」と割り切ってしまうなら
rdfとかで書いて外部に置くという選択肢が・・。

590 ：Name_Not_Found：04/07/25 04:26 ID:???

<ul>
<li>home</li>
<li><h1>＞</h1></li>
<li>contents1</li>
<li>contents2</li>
<li><h2>＞</h2></li>
<li>section1</li>
<li>section2</li>
<li><h3>＞</h3></li>
<li>section1</li>
<li>section2</li>
</ul>

591 ：Name_Not_Found：04/07/25 10:38 ID:???

----------- ここまで読み飛ばした -----------

592 ：Name_Not_Found：04/07/25 10:39 ID:???

よーしボチボチこの暑さをStrictに回避する話題でも雑談するか

593 ：Name_Not_Found：04/07/25 11:11 ID:???

>>592
夏くらいTransitionalな生活をエンジョイしようぜ（´Д｀　）

594 ：Name_Not_Found：04/07/25 12:42 ID:???

たまにやるなら loose.dtd も悪くない過ごし方だ

595 ：Name_Not_Found：04/07/25 13:14 ID:???

＞#結局IDの出し方が分らない。

仕様書読め

596 ：Name_Not_Found：04/07/25 14:45 ID:???

>>591-594
独り言は自分のノートにな

597 ：Name_Not_Found：04/07/25 15:52 ID:???

you too

598 ：Name_Not_Found：04/07/25 19:41 ID:???

結局パンクズリストは>>582が正しいの？
div厨って言われそうなんだけどな。

599 ：Name_Not_Found：04/07/25 19:52 ID:???

答えしか欲しくないんならリファレンスサイトでも見て回れば？
思考停止するんならこんなとこに来るよりよっぽどためになる。

600 ：Name_Not_Found：04/07/25 22:30 ID:???

ﾊｹﾞﾜﾗ

601 ：Name_Not_Found：04/07/25 22:37 ID:???

2.0が普及したらsection厨が増えるのかな、やっぱり。

602 ：Name_Not_Found：04/07/25 22:48 ID:???

他人を房呼ばわりする人は増えそうですね。

603 ：Name_Not_Found：04/07/25 23:11 ID:???

>>601
どういうのがsection厨？

604 ：Name_Not_Found：04/07/25 23:16 ID:???

<section>そんな事より１よ、ちょいと聞いてくれよ。スレとあんま関係ないけどさ。</section>
<section>このあいだ、近所の吉野家行ったんです。吉野家。</section>
<section>そしたらなんか人がめちゃくちゃいっぱいで座れないんです。</section>
<section>で、よく見たらなんか垂れ幕下がってて、１５０円引き、とか書いてあるんです。</section>
<section>もうね、アホかと。馬鹿かと。</section>

605 ：Name_Not_Found：04/07/25 23:17 ID:???

1行ごとに <p> を使うのと同じパターンかよ

606 ：Name_Not_Found：04/07/25 23:33 ID:???

見出しの無いsectionはどうだ、とか。
じゃぁ「暗黙の見出し」を明示(というのも変だが)するのか、とか。
根本的な話のたねはこれまでもこれからも一緒かもしれない。

予想されるあっち方面でのFAQ：
Q. XHTML 2.0 は使って良いの？
A. 現状ではブラウザが対応していないので互換性を考えると現実的にはまだ控えたほうが良さそうです。

そっち方面：
A. 現状で対応しているブラウザはありませんが、スタイルシートで見栄えを確保することができます。
　　新しい物好きの人はどうぞ。

どっち方面：
A. スタイルシートを使えば見栄えは確保されますが、アクセシビリティは確かに低下します。
　　もっとも、現行のブラウザで大きな差が出るとは思えませんが。

607 ：Name_Not_Found：04/07/25 23:42 ID:???

書くのはStrict
心はルーズに

608 ：Name_Not_Found：04/07/26 01:01 ID:???

順序付きリストの使い方について疑問があります。
<h1>かっこいい節ベスト３</h1>
<ol>
<li>section1</li>
<li>section3</li>
<li>section9</li>
</ol>

olのli要素を上から1位、2位、3位等に使ってもstrictですか？
もしも３～６位だけのリストの場合も
<h1>ださい節3位～5位</h1>
<ol>
<li>sectio11</li>　
<li>section8</li>　
<li>section21</li>　
</ol>
のように使っても良いですか？もうひとつの疑問も次レスで。

609 ：Name_Not_Found：04/07/26 01:04 ID:???

>>608
このスレを読み返せば分かると思うけど、「1から始まらない」序列リストは序列リストとして扱えない、ってことで。

610 ：608：04/07/26 01:06 ID:???

もうひとつの疑問は、リストで後々li要素が増えていくような場合のときですが。
順序付きのリストの場合は後々li要素を加える場合、必ず一番下に追加しなければなりませんか？
それとも途中に挿入しても良いですか？

611 ：608：04/07/26 01:10 ID:???

>>609
この疑問は>>583を読んでて思いました。
<ol>
<li>section4
<li>section9
</ol>
olの場合のli要素は上から1番目、2番目と言う意味なのでしょうか？それとも
前後関係を意味してるだけなのでしょうか？

612 ：Name_Not_Found：04/07/26 01:25 ID:???

>>611
>もちろん仕様書にはないから推測にすぎないし、これだと視覚的UAが数値を付けてレンダリングすると書いてあることが説明できないけど。
583はこんなことも言っている。W3Cは視覚系UAが番号を1から付けてレンダリングすることに文句はないようなので
いまのとこ>>609の言うことが無難だと思うが。

ただ番号が1から始まるがその意味は、前後関係を示してるだけかもしれないので
どちらが正しい！と強弁することはできないな。

613 ：Name_Not_Found：04/07/26 01:28 ID:???

>>610
更新時にどこに追加するかはあまり関係ない。アップした状態の時にそれが序列リストであればそれでいい。
過去のリストとの互換性はなくてもいいということ。

614 ：Name_Not_Found：04/07/26 02:36 ID:HL+mZD5Z

サイトマップを作ってるんですが、階層構造を定義リストでやるにはどうするのですか？
HOME
FF8
disk1
disk2
disk3
disk4
FF9
disk1
disk2
disk3
disk4
というページ構成です。
各ページの階層構造と共にページ毎に解説を一言入れたいので定義リストだとおもうのですが、
<dl>
<dt>HOME</dt>
<dd>トップページです。<dd>
<dd><dl><dt>FF8</dt><dd>FF8の攻略法トップページです。</dd><dd><dl><dt>disk1</dt>
～～～
のようにやるか
<dl>
<dt>HOME</dt><dd>トップページです。<dl><dt>FF8</dt><dd>FF8の攻略法トップページです。
～～～
のようにするか、どちらがいいかわかりません。

お願いします。

615 ：Name_Not_Found：04/07/26 02:43 ID:???

>>614
<ul>
<li><dl>
<dt>ほーむ<dd>ほーむです。
</dl>
<ul>
<li><dl>
<dt>日記<dd>日記です。
</dl>
<li><dl>
<dt>夕飯<dd>夕飯です
</dl>
<ul>
<li><dl>
<dt>おかず<dd>おかずです。
</dl>
<li><dl>
<dt>しゃけ<dd>魚
</dl>
<li><dl>
<dt>ニラ<dd>ニラです。
</dl>
</ul>
<li><dl>
<dt>ペット<dd>ニラです。
</dl>
</ul>
</ul>

616 ：614：04/07/26 03:01 ID:???

>>615
ありがとうございます。順序なしリストで海藻構造を作って、その中に定義リストを使うんですか。
定義リストだけでは階層構造を作れないんですか？それともサイトマップのようなものの場合は
定義リストで階層を作るとおかしな意味になってしまうからでしょうか？

617 ：Name_Not_Found：04/07/26 03:03 ID:???

>>616
あのな。
初心者スレ行け。
見栄えに固執してるうちはここに用はない。

618 ：614：04/07/26 03:06 ID:???

>>617
見栄えはどうでもいいですし、見栄えについての質問はしてませんが？

619 ：Name_Not_Found：04/07/26 03:08 ID:???

>>618
面倒だったから適当に答えた。
どっちにしろDL要素がどういうものかわかれば階層なんて使えないことくらいわかるだろ。

620 ：619：04/07/26 03:08 ID:???

×使えない
○作れない

クーラー壊れて苛立ってるんだよ

621 ：614：04/07/26 03:12 ID:???

>>619-620
クーラー自体ないです。すぐ慣れますよ。ありがとうございました。

622 ：Name_Not_Found：04/07/26 03:19 ID:???

関係ねえけどすげえ面倒なこと思いついた。
よくあるメニュー
home contents1 contents2 contents3
っていうやつって階層じゃん。
誰もそんなことしてねえけど、実はhomeをrootとした階層構造であるといえるよな。
すくなくともぱんくずを階層でマークアップしてることはメニューも階層でマークアップしなきゃおかしいな。
でも面倒くさい。

結局ぱんくずは階層なんてやらなくていいかもな。W3Cもみとめる妥協点だな。

623 ：Name_Not_Found：04/07/26 03:59 ID:???

日記はメモ帳にどうぞ

624 ：Name_Not_Found：04/07/26 06:30 ID:???

そもそもパンくず外部ファイルにしたい派

625 ：Name_Not_Found：04/07/26 07:32 ID:???

>>608
「3位」や「5位」もデータだと考えればテーブルの方が良いと思うんだがな。

626 ：Name_Not_Found：04/07/26 07:50 ID:???

>>608
順位等の数字に意味があるのなら、それをliの中に含めてul使えばいいと思う

<ul>
　<li>3位 section11</li>
　<li>4位 section8</li>
　<li>5位 section21</li>
</ul>

一応、各リストアイテムをグチャグチャに並び替えても順位の数字が入ってるからわかる、
ということでulにした。
この場合dlでもいいと思う。

627 ：Name_Not_Found：04/07/26 11:42 ID:???

フレームの元になりそうだが、

＞一応、各リストアイテムをグチャグチャに並び替えても順位の数字が入ってるからわかる、
＞ということでulにした。

もし、「昇順（或いは降順）にソート済み」と言う事に意味があるなら、
おれはolでマークアップする。

olが1から番号を振るのは空くまでデフォルトスタイルの話だし、
（ソート順位）1番目のデータは「3位 section11」と言う事なら、
デフォルトスタイルでも問題ない。

と言う訳で >>609 と真っ向から対立する訳だが、うーん。
俺の論拠は「順序リスト(ordered list)」ならolと言うと言うだけ。
一応仕様をよんでみたが特に1からの連番でなければならないという
記述も見つからなかったし。

628 ：Name_Not_Found：04/07/26 12:21 ID:???

ordered は「順序がある」であって「番号がある」じゃないんだが、ここ最近のレスの中に勘違いしている節がちょろちょろと見られたな。

629 ：Name_Not_Found：04/07/26 12:58 ID:???

>>625
これくらいは重々承知の上で何か考えがあって言ったんだと思うけどあえて言っとくと、
むしろ定義リストのほうが普通。

630 ：Name_Not_Found：04/07/26 13:29 ID:???

>>624
外部ファイルにしちゃうと、今度は本文とパンくずリストを結びつける
仕様が必要に成っちゃうのでそれはそれで面倒臭いが、少なくとも
ナビゲーション情報なのだからbodyじゃなくてheadに含まれる内容だよなぁ、
とは思う。

631 ：Name_Not_Found：04/07/26 15:23 ID:???

>>628
仕様書には
視覚系UAがデフォルトで番号を1から振ってレンダリングされる。
みたいなことが書いてあるけど、文句ありませんってことではないの？

632 ：Name_Not_Found：04/07/26 15:24 ID:???

ところでおまいらぱんくずやサイトメニューをちゃんと階層にしてマークアップしてるの？
実際そこまでやるやつっているのかな？まだ見たことない

633 ：Name_Not_Found：04/07/26 15:39 ID:???

>>632
div で囲うだけ。だって所詮「くず」だもの。マークアップする価値無しってことで。
でもまぁ、 class="KUZU" くらいは入れてあげようかな。
見出しに使うような「●」画像に alt="●" いれているようなもんだし。
所詮、低脳な「人間様」だけが判ればいいだけのものだからね。

634 ：Name_Not_Found：04/07/26 15:57 ID:???

>>632
ぱんくずに関しては俺も633同様divで囲ってid="kuzu"って感じ。
メニューは場合によっては階層化してマークアップするよ。

635 ：Name_Not_Found：04/07/26 16:11 ID:???

>>632-633
同一人物だよな？ぱんくずりすとの意味を知らないやつが二人もいるとは思えんな。

>見出しに使うような「●」画像に alt="●" いれているようなもんだし。
そんなのやるのはお前だけ。意味のない画像はHTMLには絶対に使わないのがStrict。

636 ：Name_Not_Found：04/07/26 16:12 ID:???

↑
>>633-634の間違い

637 ：Name_Not_Found：04/07/26 16:27 ID:???

自作自演と解る所も含めて低脳の釣りかと。
放置で。

638 ：Name_Not_Found：04/07/26 17:01 ID:???

所詮、釣られるのは低脳な「人間様」だけということで。
キカイさんには LINK で指し示してあげればすむだけだもの。

> そんなのやるのはお前だけ。意味のない画像はHTMLには絶対に使わないのがStrict。
やってるなんて云ってないよ。もうちょっと頭を冷やしてね。

639 ：Name_Not_Found：04/07/26 18:41 ID:???

>>638
あきらめろって

640 ：Name_Not_Found：04/07/26 19:27 ID:???

屑

641 ：Name_Not_Found：04/07/26 20:36 ID:???

>>627
> 一応仕様をよんでみたが特に1からの連番でなければならないという
> 記述も見つからなかったし。

start属性が非推奨　＝
1以外からはじめることは薦められない　＝
1から始まる

value属性が非推奨　＝
途中から番号を変えられない　＝
連番になる

番号付けの「数値」に意味はなく、
ただ、上から順番に数値が割り当てられる、と考えるのが順当じゃないかな。

成績が5番、7番、12番のやつを呼び出して、
「成績いい順番に並べ」と言ったら、
5番の子が1番目にくるから「1」、7番の子が二番目にくるから「2」という番号札が渡される、みたいな。

642 ：Name_Not_Found：04/07/26 20:47 ID:???

>>641
俺もそう思う。
どこまで視野にいれるかでも違うしね。
同じ成績順のリスト作るのでも
クラス＞生徒
かもしれないし
県内全校＞学年＞クラス＞生徒
かもしれない。
上みたいにどこを起点にするか決めづらい場合もある。
順に番号が割り当てられるんだよ。

643 ：Name_Not_Found：04/07/26 21:04 ID:???

JavaScriptでも使ってソートさせれば良い感じになってきたな

644 ：Name_Not_Found：04/07/26 21:05 ID:???

http://headlines.yahoo.co.jp/hl?a=20040726-00000006-wir-sci

大手サイトの不備を模造サイトで指摘するユーザーたち

ウェールズ、カーディフ発――「きちんと仕事をしたいなら、自分でやるのが一番だ」という格言がある。ずさんなデザインのウェブサイトにいら立ちを覚えたユーザーが、
この理論をインターネットに当てはめて実践するケースが増加している。
企業サイトのあからさまなページ設計ミスにうんざりした多数のユーザーが、
こうしたサイトの修正を進んで引き受けはじめている。しかも、このような修正作業は、サイト所有者が目にできるかたちで公然と行なわれ、
所有者にばつの悪い思いをさせている。こういったボランティアでサイトを作り直すコンサルタントたちは、
努力に対する報酬を受け取るどころか、所有者の許可さえ得られない。ウェブ上のコミュニティーで
『よきサマリア人』[苦しむ人々に援助と同情を与える人：聖書]と賞賛されながら、訴訟の脅威にさらされているのだ。
オックスフォード大学数学科卒業のマシュー・サマービルさんは、イギリスの映画館チェーン『オデオン』の
http://www.odeon.co.uk/ サイトが「非常に使い勝手の悪い」ことに困り果て、自分で
サイトをデザインし直すことに決めた。サマービルさんはこのとき、自分と同じ映画ファンの役に立てればとしか考えていなかった。オデオンのサイトは、不要な
Javaスクリプトやクッキー、入り組んだメニューで構成されており、映画の上映時間を調べに来た多くの訪問者を
混乱におとしいれていた。そこで、サマービルさんは http://www.dracos.co.uk/ 自身のサーバーにすっきりと
簡素化された模造サイトを立ち上げ、多くのユーザーから
http://www.matthewman.net/archives/2004/07/11/spend_money_on_accessibility_not_lawyers.php 称賛を獲得した。
オデオンはサマービルさんの注意を受けた後、サイトの http://www.dracos.co.uk/odeon/odeonreply1.txt
バグを修正したにもかかわらず、その後サマービルさんに対し、そっけない http://www.dracos.co.uk/odeon/odeon1.txt 停止命令を送付した。
（以下略）

645 ：627：04/07/26 21:07 ID:???

>>647
ですから、そう述べている訳ですが…。

646 ：Name_Not_Found：04/07/26 21:35 ID:???

ぱんくずはol一個でいいと思うんだけどどう？
<ol>
<li>top
<li>chpater1
<li>section
</ol>
ぱんくずは経路であるから、経路としてマークアップすれば最低限の意味を伝えられる。
経路が階層構造であるかどうかは問われていない。なのでol一個でも間違いではないはず。

ちょっと乗り遅れたけど、一応自分の意見も言っておきたかった。
逆にサイトマップなんかはちゃんと階層構造でマークアップするべきで、もちろん
サイトマップのミニ版である、メニューバーなんかも階層でやるのがStrict。

まあどういう意味がこめられてるかによりマークアップも変わってくるね。

647 ：Name_Not_Found：04/07/26 21:42 ID:???

>>646
ぱんくずはp一個でいいと思うんだけどどう？

648 ：Name_Not_Found：04/07/26 21:52 ID:???

>>644
漏れ、3年くらい前にフ○テレビのサイトをネタにしてそういうコトしたら、
○ジテレビから、やめてください、って言われた。

649 ：Name_Not_Found：04/07/27 06:31 ID:???

>>646に限らずall
>逆にサイトマップなんかはちゃんと階層構造でマークアップするべきで、
そもそも文書群に階層なんかないんじゃないか？もしくはなくても問題ないんじゃないか？基本的には
start
prev
next
があれば全てを表現できる。本だと思えばわかるでしょ？

でも自分が階層だと思うのなら、階層でマークアップするのがいいけど、普通文書群って言うと"本"的なものを
イメージするんだけどな。
だからぱんくずは完全に<ol>でやる。
home>chapter1>chapter2>chpater3>section1>section2>section3
みたいな感じにね。本だから。長いのが欠点だけどそれはStrictととは無関係だし。

650 ：Name_Not_Found：04/07/27 07:11 ID:???

>>649
本にだって、どこから読んでもかまわない並列なsection群が、
紙を束ねた物の制約として仕方なく順番に並んでいるだけの物もある。

例えば、学校の作文集みたいに、文書間に特に意味的なつながりはなく
（或いはテーマ毎に纏まっている程度の希薄さで）、でも、とりあえず
何らかの順番で並べざるを得ないので書き手の名前の五十音順で並んでる、とか。

確かに「本」の構造は参考になるし、長い時間をかけてああなっただけ有って
洗練もされているから迷ったらとりあえず真似しておくのも悪くないが、
文書群のつながりに関して言えばHyperLink時代に何故本の構造を
参考にせねばならんのか、理解に苦しむ。

651 ：Name_Not_Found：04/07/27 09:15 ID:???

紙媒体の延長線上のもの程度にしか考えられないからなのでしょう。tu-kaそういう香具師大杉鬱。

652 ：Name_Not_Found：04/07/27 09:16 ID:???

アナロジーは便利ですからねえ。

653 ：Name_Not_Found：04/07/27 10:03 ID:???

HTML文書というかリソースの一つ一つを本の一冊一冊に相当する何かとして扱うと筋が通るような気はする。
特に見出しとかタイトルとかnext/prevあたりの関係とか。

じゃあchapterとかはどうなんだと、もう一人の自分に突っ込まれて困ってみるテスト。

654 ：Name_Not_Found：04/07/27 10:13 ID:???

655 ：654：04/07/27 10:14 ID:???

なんか " が3つくらい抜けてるけど脳内補完してください。

656 ：Name_Not_Found：04/07/27 10:22 ID:???

>>653
>本の一冊一冊に相当する何かとして扱うと筋が通るような気はする。
　その「紙媒体の本相当する何か」の筋が通ると、「WWW上のHyperText」に
どのような利点が生まれるの？
　勿論、ちゃんとした利点が有る事もあるが（と言うかその方が多いと思うが）
よくよく考えてみると、単なるノスタルジィと言う事もある。

>>654
そもそもHyperText自体が、単一の文書と複数の文書、或いは
自身と他の文書の垣根をとっぱらって相互参照する為に生まれたのだから、
そういう使い方に今更「なるほど」もないものだ、と思うのだが。

657 ：Name_Not_Found：04/07/27 15:59 ID:???

視覚的効果ばっかり考えるのはStrictとはほど遠いからね

恐らくパンくずリストとか「階層」って考え方自体危ういかも。
要するにparent/child or next/prev文書との関係をlinkで記せばHTML的には○。

だと思うんだけど・・・

ぶっちゃけ新スレ立てても良いくらいの議論量だな。
実際に立てたら単発クソスレだけど。

658 ：Name_Not_Found：04/07/27 16:11 ID:???

ところで本当に同じディレクトリ下にあるHTMLファイルが階層構造だと言えるのかね？
内容としてはchapterありきのsectionである場合があるが、本当に階層かな？

前後関係だけであってもおかしくはないよ。と、半分は本的な文書群の作成に賛成してもいいけど、
もしも、前後関係で文書群を構築すると
start
chapter1
section1
section2
chapter2
section1
section2
みたいな並びであった場合に、chapter1がなんらかの理由で削除された場合にそれ以下の
全てを書き換える必要がある（ぱんくずやページ数をね）。それらを踏まえれば
やはり階層的な構造であるとして構築することが賢いといえるだろう。
そしてそれこそがHTMLの魅力のひとつだと思う。でも本みたいにやるのもデザイナ的な発想としては面白いね。

ぱんくずに関してはずいぶん正論的なものでも4つくらい出てるけど、これをどっかのサイトにまとめれたら
いいよね。このスレと初心者スレのテンプレに加えてもらえば、Strictを理解してもらうのに貢献しそう。

659 ：Name_Not_Found：04/07/27 16:17 ID:???

＞同じディレクトリ下にあるHTMLファイルが階層構造だと言えるのかね？
どうでしょう。文書の相互関係的に上下があれば、階層と見ても問題ないと思うけど

＞ぱんくずに関してはずいぶん正論的なものでも4つくらい出てるけど、これをどっかのサイトにまとめれたら
＞いいよね。このスレと初心者スレのテンプレに加えてもらえば、Strictを理解してもらうのに貢献しそう。
だな。

一々議論が再燃するのも何だし、
ある程度まとめたサイトがあると、ちょっとした時に便利かも

俺にはStrictにこだわって一つサイト作る根気はないけどな・・・
スレ住人で有志募ってやってみると面白いかも

議論スレだからそれで議論が湧くのも一興。

660 ：Name_Not_Found：04/07/27 16:33 ID:???

> 同じディレクトリ下にあるHTMLファイルが階層構造だと言えるのかね？
とりあえず「同じディレクトリ」なんて
ファイルシステム(ファイル管理・URI管理でもいい)の問題は
文書間の関係・構造とは無関係かと。

661 ：Name_Not_Found：04/07/27 17:04 ID:???

>chapter1がなんらかの理由で削除された場合にそれ以下の
>全てを書き換える必要がある（ぱんくずやページ数をね）。

普通chapterが削除されたら、他の文書も見直さないか？

ちなみに、前後関係「だけ」、階層構造「だけ」で文書を表現しようと言うのは
両用とも同じくらい滑稽だと思うのだが（勿論もともと存在しないなら、なくてあたりまえだが、
それは書く文書に依存する話）。

紙の本だって、目次などを開けば、インデントなどにより前後だけでなく、
階層構造が存在し、明示されている事は一目瞭然といえる。

662 ：Name_Not_Found：04/07/27 17:06 ID:???

そもそも今のところは明確に階層構造だとマークアップする要素はないよね。
それで借りにその要素と、それを解釈するＵＡがあったとして
どういうメリットが考えられるの？
俺にはいまいち必要性が感じられない。

663 ：Name_Not_Found：04/07/27 17:14 ID:???

たとえばマンションの見取り図あるじゃない。
各階ごとに見取り図があるとする。
文章としてはギコマンション１階見取り図、２階見取り図と見出しで示してる。
その見取り図の階層構造なんて順番に並べてやれば、読み手が判断するでしょう。
いちいち２階の見取り図と５階の見取り図では５階の方が上ですとは説明しない。
見出しと順列で表せばそれでＯＫだと思うんだけど。

664 ：Name_Not_Found：04/07/27 18:27 ID:???

>>663
人間が見た目で理解するか否かが、strictではないのだからやはり機械にもわかるように
論理的なマークアップをすることがstrictでしょ。

機械は括られてる中身を理解できないのだから、HTMLで中身がどんなものなのかをを理解させる（段落とか見出しとかね）。それが
論理的なマークアップをしようという始まり。

そもそもどこまでのstrictが有益なのかっていう議論もあってもいいかもしれない。
strictにこだわりすぎて、ソースが汚くなってしまうのはいいことなのか。
汚くなったソースの見返りはあるのか？ってことだよね。

階層なんかは顕著にその問題を抱えてると思うんだけど、実際に完璧主義で階層は階層としてマークアップ
なんてするとソースが長くなるし見づらくもなる。機械に対しては親切だけど、今度は人間に対して不親切な
ものになってしまうのもいかがなものだろうか。

665 ：Name_Not_Found：04/07/27 18:37 ID:???

パンくず厨うぜええええええええええええええええええええええええ

666 ：Name_Not_Found：04/07/27 18:40 ID:???

>>662
>それで借りにその要素と、それを解釈するＵＡがあったとして
>どういうメリットが考えられるの？
文書群をDB化して、例えば検索サイトのヒット率を向上させたり、
UAに向かって「今読んでいる文章の関連文書をまとめてこのフォルダに
ダウンロードしといてくれ」という命令が出せるようになったりする。

>>663
UAがマンションの見取り図をみる人間と同じくらいの「読み手が判断する」
AIを搭載しているなら、そう。
でも、現在のUAは見出し構造すら認識出来ず、h1-6 tagで明示せねばならない、
判断力をほぼ全く持ちあせない存在なので、絶望的。
理解力はあるが、知識も判断力も持ち合わせない白痴にも解るほど
明確な意味づけがどうしても必要。

>>664
＞ソースが汚くなってしまうのはいいことなのか。
＞汚くなったソースの見返りはあるのか？ってことだよね。
そもそもソースが汚いとは？　Strictの有益性を疑うなら、
綺麗なソース（謎）の有益性も疑うべきでは？

Strictの有益性を疑うなら、比較すべきは対象は「非Strict」。
それ以外の価値を持ち込むと、論点が際限なくずれていき、
奇跡でも起きない限りまともな結論にはたどり着かない。

667 ：Name_Not_Found：04/07/27 18:51 ID:???

>>664
いや文章の内容は人間が把握するべきものじゃないのかな。
マークアップしてるのは文章中でどういう意味をもってるかってことでしょう。
段落にしろ、表にしろ、見出しにしろ、リストにしろ、
それぞれの内容についてまでは表してない。
極論として考えて欲しいんだけど、将来単語の配置等から文章の大凡の内容を推察する
ＵＡが出来るとする。例えば児童に有害な文章を検出して排除したりね。
でも文章の内容は人それぞれ捉え方、解釈の仕方が違うべきであって
例え著者が”この段落は共産主義思想を表してます”等と印付けしても
実際にそれを判断するのは人間であるべき。
そういう技術を使えば、都合の悪い文章は閲覧できないように誰かが細工することも可能だよね。
ＨＴＭＬの大元の理念はあらゆる環境下で文章の可読性を再現することだし
文章内容まで決めつけるようなことはおこがましいと思うよ。

668 ：Name_Not_Found：04/07/27 19:00 ID:???

>>667 は釣り。又は馬鹿。最大限に弁護してうっかりさん。

669 ：Name_Not_Found：04/07/27 19:27 ID:???

>>666
>綺麗なソース（謎）の有益性も疑うべきでは？
綺麗というのは最小限必要な論理的なマークアップになってるってことかな。
俺は商売してるからSEOが一番重要なのね。階層構造なんてやってもSEOとしてはマイナスにしかならないから。

なので、見やすいソース且つ論理的なソースが製作者とSEOには一番いい。
ってStrictからずれてるから無意味な発言だね；

StrictとSEOは関係ないけど、通常SEOがStrictで書く時のひとつのメリットだから。
SEO的にプラスにならないものはやる気が起きないと・・・・やっぱり話がずれた。

スルーしておくれ。

670 ：Name_Not_Found：04/07/27 19:55 ID:???

独り言は日記でどうぞ。

671 ：Name_Not_Found：04/07/27 20:56 ID:???

>>667
>例え著者が”この段落は共産主義思想を表してます”等と印付けしても

一応突っ込んどくが、論理的なマークアップとはそういうことじゃない。
とりあえず仕様書読んで来い。やばいって今のお前。

672 ：Name_Not_Found：04/07/27 21:13 ID:???

まあ確かに「論理××」って誤解されがちな用語ではあるよな。

673 ：Name_Not_Found：04/07/27 21:29 ID:???

案外そのうちできそうだよな。
ＩＥの独自拡張とかで
pg { age:13 }
（１３歳未満は保護者監督下で閲覧推奨）
とか(ﾟДﾟ,,)

674 ：Name_Not_Found：04/07/27 21:39 ID:???

body{
migiclick:kinshi ;
source:pakuruna;
innyou:kinshi;
}

675 ：Name_Not_Found：04/07/27 21:40 ID:???

>>674
三つ目のプロパティはお前の趣味かよ

676 ：Name_Not_Found：04/07/27 21:40 ID:???

CSSはスレ違いですよ。

677 ：Name_Not_Found：04/07/27 22:00 ID:???

>>675
漏れも一瞬そう思ったけど、
飲尿じゃなくて引用だな。

678 ：Name_Not_Found：04/07/27 22:26 ID:???

ばれた趣味は>>675のこそだった模様。

679 ：Name_Not_Found：04/07/27 22:27 ID:???

>>675
いいこと思いついた。お前、俺の尿を飲め。

680 ：Name_Not_Found：04/07/27 22:28 ID:???

>>679
禁止だって

681 ：675：04/07/27 22:31 ID:???

やべっ、ばれた。
でもおまいらだって飲尿って読んだだろ。隠すなよ。

682 ：Name_Not_Found：04/07/27 22:37 ID:???

>>680
ユーザースタイルシートで!importantだ！！

683 ：Name_Not_Found：04/07/27 22:38 ID:???

だからＣＳＳはスレ違いだってば(´･ω･`)

684 ：Name_Not_Found：04/07/27 22:42 ID:???

>>683
もしかしてマジレス？

685 ：Name_Not_Found：04/07/27 22:46 ID:???

　　　　　　!important
あらビックリ　インポ　勃たんと

686 ：Name_Not_Found：04/07/27 22:49 ID:???

下らないのにワロてしまった自分に鬱
首吊ろう

687 ：Name_Not_Found：04/07/27 22:56 ID:???

ものすごく頭の悪い発言してくださいその2
http://pc5.2ch.net/test/read.cgi/hp/1086686223/

688 ：Name_Not_Found：04/07/28 00:01 ID:???

すとりくたんってどこいったの？

689 ：Name_Not_Found：04/07/28 00:29 ID:???

小学校

690 ：Name_Not_Found：04/07/28 00:37 ID:???

>>689
俺も連れてってくれ(*´Д`)ﾊｧﾊｧ

691 ：Name_Not_Found：04/07/28 11:50 ID:???

いまは夏休みなので海にいきますた

692 ：Name_Not_Found：04/07/28 13:52 ID:???

なにこのキモい流れ

693 ：Name_Not_Found：04/07/28 14:15 ID:???

パン屑の話題よりよっぽどマシ

694 ：Name_Not_Found：04/07/28 15:27 ID:???

キモイかマシかは兎に角としてスレ違い

695 ：Name_Not_Found：04/07/28 17:40 ID:???

>>693
おまいにはわからない話題だったかもしれないが、ここはStrictスレ。
今の流れはスレ違い。というより荒らし。まあ弁護してるとこをみるとお前が荒らしてるんだろうがな。

小学生は外で遊んでおいで。

696 ：Name_Not_Found：04/07/28 18:46 ID:???

なんだかなあ…>>58

697 ：Name_Not_Found：04/07/28 18:58 ID:???

698 ：Name_Not_Found：04/07/28 19:08 ID:???

どうも疑問なんだけどそれって文章間の序列を表してるだけで
階層とは違うんじゃないの？

699 ：Name_Not_Found：04/07/28 19:32 ID:???

>>697
なぜnextかsectionの二択なの？

rel、rev属性は（classみたいに）スペース区切りの値なんだから、
rel="section next"ってかけばいいじゃん。

700 ：697：04/07/28 19:41 ID:???

>>699
sectionを書くとなると全部30個書かなきゃいけないかなと思ったので。
本当はsectionが30個あっても<link>要素のrel="section"は全て書かなくてもいいんでしょうか？

701 ：Name_Not_Found：04/07/28 19:44 ID:???

>>698
階層

702 ：Name_Not_Found：04/07/28 20:02 ID:???

スレ違いとは言わんが何だか「質問です」が増えてきたね

703 ：699：04/07/28 20:09 ID:???

>>700
微妙な言い回しになるが、
UAに伝える必要があるなら、書かなきゃいけないし、
別に伝える必要も無ければ、書かなくても良いと思う。

どっちか迷うなら「あった方がいい」とおもう。

あとStrict原理主義的に言えば、
「Q: 数が多すぎてめんどくさい A: 知るか！」
「Q: 数が多いと一部UAのアクセシビリティが下がる A: そのUAのデザインが悪い」
と言う事になると思うが…まぁ、現実的な妥協点は自分で考えるって事で。

704 ：Name_Not_Found：04/07/28 21:42 ID:???

>>702
新手のネタ投下方法じゃないか？ここ最近「質問です。」の一言から議論が始まってる感じがするよ。
まあ「質問」っていうのも微妙だが、逆に「どう思う？」みたいなネタ投下方法は
たまにうざいからな。

705 ：Name_Not_Found：04/07/28 22:01 ID:???

おまいらも夏の間くらい厨にここゆずって
ストリクタンと海にでもいこうぜ。

706 ：Name_Not_Found：04/07/28 23:52 ID:???

>>697
Chapter1のnextをChapter2にしておけばChapter1とその子のsectionに興味が無いユーザーはChapter1とその子のsectionをいっきに飛ばせるから楽。

707 ：Name_Not_Found：04/07/29 00:55 ID:???

>>706
strictとは無関係

708 ：Name_Not_Found：04/07/29 02:52 ID:???

でもChapter1の次はChapter2じゃないの。

こういうコースを旅行するとする。

日本
　大阪
　東京
アメリカ
　ロサンゼルス
　ニューヨーク
イギリス
　ロンドン

この場合、大阪の次はもちろん東京。
じゃあ日本の次はと聞かれたら、多分大阪じゃなくてアメリカと答えるのが正しい。

709 ：708：04/07/29 02:56 ID:???

ごめん、何か違った。
>>708は撤回。

ところで、そもそも子Sectionを持つChapterには何を書けば良いの？
ていうかどういうのがChapterになるの？
SectionたちのToCみたいな感じ？
或いはブログみたいなのでよくありそうな「長いので別ページにしました」みたいな？

710 ：Name_Not_Found：04/07/29 03:08 ID:???

HTML4.01Strictで書いています。

<input type="image" name="hoge" src="img/hoge.gif">
width属性とheight属性がstrictでは使えないので一応CSSでやっていますが、
CSSが効かない状況では当然img要素にwidth等を指定しなかった場合のように
画像を読み込んだ後に再描画されますよね？

CSSが効く前提のこの仕様はおかしくないですか？再描画のことは考慮されてないんでしょうか？

711 ：Name_Not_Found：04/07/29 03:15 ID:???

>>708-709
>ところで、そもそも子Sectionを持つChapterには何を書けば良いの？
>ていうかどういうのがChapterになるの？
chapter=文書群の中での章
section=文書群の中での節
章を飛ばして節があるなんてのは、h1の次がh3のようなもの。

712 ：Name_Not_Found：04/07/29 03:56 ID:???

結局それは順列でしかないんだって。
仕様書のどこにも階層なんて単語でてこないでしょ？
無理矢理こじつけてるだけなんだよ。

713 ：Name_Not_Found：04/07/29 03:58 ID:???

>>710
そもそも「画像が表示されて、再描画が行われる」というのが幻想。

画像は表示されないかも知れないし、画像を読み込むまでそこで描画を
ストップするかも知れない。

>CSSが効く前提のこの仕様はおかしくないですか？
そんな前提はどこにもありません。

>再描画のことは考慮されてないんでしょうか？
そもそも再描画という手段の選択がUAベンダによる物です。

714 ：Name_Not_Found：04/07/29 04:08 ID:???

>>712
釣りかも知らんがマジレスしとく
＞結局それは順列でしかないんだって。

<link rel="chapter" href="c2.html" title="第2章" />
<link rel="chapter" href="c1.html" title="第1章" />
<link rel="chapter" href="c3.html" title="第3章" />

じゃあ、これらの章の読む順番が第1章、第2章、第3章の順番である事を
どうやってtitleが理解できないUAが認識するのか教えてくれ。

階層という表現が嫌いなら「文書を区切ったときの大きさの単位」と言ってもいいが、
chapterやらsectionは文書間の包括関係を表す物であって順列情報は
存在しない。

715 ：710：04/07/29 04:17 ID:???

>>713
レスありがとうございます。ところでどうしてimg要素のwidtｈ,height属性は禁止されないのですか？

716 ：Name_Not_Found：04/07/29 04:22 ID:???

>>712
>>708だよね？疑問があって質問側なら、できるだけ番号つけてほしいよ。

順列か階層かにこだわってるみたいだけど、君の具体的な悩みは何？
マークアップの具体例を出してくれると、説明もしやすいかな。

717 ：Name_Not_Found：04/07/29 04:33 ID:???

>>715
<img src="hoge.png" alt="縦横比が１：２の方形" />

仮に画像サイズの描画が任意になったら上記のような場合、
意味も失われないだろうか？

もちろん
<p>赤い文字の曜日は休業日です。<font color="red">１日、８日、１５日</font></p>
なんて事もあるので、たんなるシガラミかも知れないが。

# ちなみにXHTML2.0のWDにはimgが無く、objectに一本化されており、
　objectにはwidthもheightもない、というのは「参考」になる…かも？

718 ：717：04/07/29 04:35 ID:???

わかりにくいので自己レス。

fontの例は、つまり「無くなったら意味が失われる＝理論的要素」という
解釈に対する反証のつもり。

719 ：Name_Not_Found：04/07/29 04:37 ID:???

>>715
そもそもINPUT要素にWIDTH/HEIGHT属性なんてあったのか?

720 ：710：04/07/29 06:08 ID:???

>>717-8
そもそも何でimg要素にはwidth等の属性が必要だったんですかね？（strict以前の話です）
UAは以前から転送されてきた画像のwidth等のプロパティを解釈できたんですよね？

721 ：Name_Not_Found：04/07/29 08:40 ID:???

>>720
レガシーな環境でのレンダリング効率のためだろう。
物理的な属性っぽいので最近はあんまし好かれてないみたいだが。

個人的にはそもそもINPUT要素で画像を使うこと自体が
頂けないんだが・・・、アクセシビリティとかどうなるんだ？

・・・趣味的なものなのでAC。

722 ：Name_Not_Found：04/07/29 09:57 ID:???

<img src="./spacer.gif" width="100" height="1" alt="">
こういうﾊﾞｸｧを根絶させるため？

723 ：Name_Not_Found：04/07/29 10:04 ID:???

>>722
なにが？

724 ：Name_Not_Found：04/07/29 10:17 ID:???

>>722
あなたのようなレスでは何に対してレスを返しているのかわかりにくいです。
Strictのスレなんだからせめてレスの対象を明確にしましょうよ。

725 ：Name_Not_Found：04/07/29 12:46 ID:???

>>721
ACって何だ？

726 ：Name_Not_Found：04/07/29 12:53 ID:???

>>725
./ 用語だろ

727 ：Name_Not_Found：04/07/29 12:53 ID:???

>>725
交流

728 ：Name_Not_Found：04/07/29 12:53 ID:???

/. に訂正

729 ：Name_Not_Found：04/07/29 12:54 ID:???

<q cite="http://pc5.2ch.net/test/read.cgi/hp/1090216329/724" title="Strict-HTML スレッド21">
あなたのようなレスでは何に対してレスを返しているのかわかりにくいです。
Strictのスレなんだからせめてレスの対象を明確にしましょうよ。
</q>
ｽﾏｿ

730 ：Name_Not_Found：04/07/29 12:58 ID:???

>>723-724
Strictな奴らって全てを明確に説明しないとわからないのか？
読解力が低すぎですね（藁
仕様書仕様書いうだけあって、マニュアルには忠実だけど応用力がないというか
仕事では指示されないと何もできないタイプでしょ（ﾌﾟｹﾞﾗｯﾁｮ

731 ：Name_Not_Found：04/07/29 13:55 ID:???

もう何に対しての煽りかすらもわからん

732 ：Name_Not_Found：04/07/29 15:24 ID:???

>>726-727
Current

733 ：Name_Not_Found：04/07/29 15:54 ID:???

>>730
＞Strictな奴らって全てを明確に説明しないとわからないのか？

若いうちに「思い込みが命取りになる場合もある」ってことを勉強しておくと良いですよ。
相手はきっとわかってくれてるだろうと思って話をすすめていった結果
取り返しが付かなくなる事などよくありますから。

朝鮮民族に対する日本の対応なんかが良い例です。

734 ：Name_Not_Found：04/07/29 16:18 ID:???

theadは見出しを書く部分だからわかるけどtfootって何を書く所？
thead, tbody, tfootという分け方は視覚的UAを意識してるように思える。
tfootは仕様書にもちゃんとした例が無いし。

735 ：Name_Not_Found：04/07/29 16:27 ID:???

736 ：Name_Not_Found：04/07/29 16:33 ID:???

tfootってtbodyより前に出てくるのは何でだろう。

737 ：735：04/07/29 16:48 ID:???

あ、しまった。出現順は thead?, tfoot? tbody+ ですね。すま。

738 ：Name_Not_Found：04/07/29 17:33 ID:???

＞736
tableは描画に時間が掛かるから、先にフッタも読みこませた方が便利なんじゃないか、みたいな理由からだったかと。

739 ：Name_Not_Found：04/07/29 17:48 ID:???

>>730
（´,_ゝ｀）ﾌﾟｯ

740 ：Name_Not_Found：04/07/29 18:00 ID:???

>>738
ずいぶん論理的でない理由なんだね。wwwcも

741 ：710：04/07/29 18:05 ID:???

>>721
>個人的にはそもそもINPUT要素で画像を使うこと自体が
>頂けないんだが・・・、アクセシビリティとかどうなるんだ？

画像が描画されなくてもalt属性あるのでそこらへんはimg要素と大差なしです。
そもそもinput要素自体のデフォルトの描画（image以外の）もUA,OS依存ですから
valueが必須なわけで、imageだけ毛嫌いするのはどうかと。

742 ：Name_Not_Found：04/07/29 19:04 ID:???

>>734
たしかにtheadほどは重要ではないな。

743 ：Name_Not_Found：04/07/29 19:06 ID:???

例えば、月ごと、事業所ごとの売り上げを表にして、
ついでに月ごとの売り上げの小計も記述したいときなんか、
tfootが使えるんじゃないの？
HTMLはもともと論文用に作られたから、
学術レポートで使えそうなものはけっこう豊富なんじゃないかな。
（数式はちと書きにくいが。）

744 ：708：04/07/29 20:26 ID:???

>>716
>>712は知らないおじさんですが。

>>715
我思ふに、What width and height are to an image is what length is to a text resource. と。
画像の種類にも因るけど。

745 ：Name_Not_Found：04/07/29 21:29 ID:???

禁止したければ磯釣りに。

746 ：Name_Not_Found：04/07/29 21:35 ID:???

theadって見るたびに
threadにみえる

747 ：Name_Not_Found：04/07/29 22:09 ID:???

http://souenhomura.fc2web.com/
このHTMLはダメらしいのですがどこがダメですか?

748 ：Name_Not_Found：04/07/29 22:14 ID:???

>>747
もー、一行目からダメダメ。

749 ：Name_Not_Found：04/07/29 22:18 ID:???

>747
ここはStrict-HTMLスレッドですよ？　寝言は寝て言え。

750 ：Name_Not_Found：04/07/29 22:21 ID:???

<font color="#F2EEF1" face="serif">（ぷ

751 ：Name_Not_Found：04/07/29 22:23 ID:???

だから釣られすぎ何だよ！

752 ：Name_Not_Found：04/07/29 22:28 ID:???

>>747の管理人です。何者かのいたづらでここに掲載されたようです。
無視してくださるようお願いいたします。

753 ：Name_Not_Found：04/07/29 22:30 ID:???

( ´_ゝ`)ｿｳﾃﾞｽｶ

754 ：Name_Not_Found：04/07/29 22:33 ID:???

http://rob2.jp/
http://roprop.s57.xrea.com/
http://satukuran.fc2web.com/
http://metasuraclan.fc2web.com/
http://www.geocities.jp/musicmtglife/Mugen/mmo.html
http://cocoa-works.hp.infoseek.co.jp/

全部チェックしてください

755 ：Name_Not_Found：04/07/29 22:41 ID:???

>>747必死だな

756 ：Name_Not_Found：04/07/29 22:48 ID:???

>>754の管理人です。何者かのいたづらでここに掲載されたようです。
無視してくださるようお願いいたします。

757 ：Name_Not_Found：04/07/29 22:51 ID:???

>>754
全部見ちゃったよ。糞だらけ。くせーくせー。

758 ：Name_Not_Found：04/07/29 22:59 ID:???

くせーくせー
ーせくーせく
せくーすせくーす

759 ：Name_Not_Found：04/07/29 23:48 ID:???

夏厨でもこんな変に堅いスレ見るんだな。

760 ：Name_Not_Found：04/07/29 23:56 ID:???

http://pc5.2ch.net/test/read.cgi/hp/1089286062/l50

皆さんの参加をお待ちしております。よろしくお願いします。

761 ：Name_Not_Found：04/07/30 03:18 ID:???

>>740
テーブルの総括だから、だったと思う。
中身の説明のためのヘッダとフッタ、と。

762 ：Name_Not_Found：04/07/30 03:45 ID:???

リードミージャパンっていうテキストサイトでは有名なランキング集があって
そこに登録したんだけど、ランキング集計用HTMLを貼り付けてチェッカーにかけたら
リンク先が存在しないかアクセスできないと減点されたよ。
チェッカーが弾かれてるんだろうけど、何かくやしい。

763 ：Name_Not_Found：04/07/30 03:56 ID:???

>>762
漏れんとこはそんな風にならんかったけど？
鯖が落ちてただけじゃないの？　よく落ちるし。

764 ：Name_Not_Found：04/07/30 04:06 ID:???

>>763
本当だ。W3Cvalidatorでやったらエラーでないけど
lintは何度やってもダメだった。

765 ：Name_Not_Found：04/07/30 04:11 ID:???

>>764
lintでも減点されなかったけど。
どんな記述してるのよ。
それとどんなエラーでてるの？

766 ：Name_Not_Found：04/07/30 04:31 ID:???

>>765
貼り付けてるのは、配布されてるのにalt属性つけてtargetを取ったもの。
lintでチェックすると４０３って言われるよ。
<A> の HREF 属性の URI はインタネット上に存在しないかアクセスできません。403 Forbidden
<IMG> の SRC 属性の URI はインタネット上に存在しないかアクセスできません。403 Forbidden

767 ：Name_Not_Found：04/07/30 04:34 ID:???

いやtargetじゃなくてborder。

768 ：Name_Not_Found：04/07/30 04:49 ID:???

>>766
うちもそのエラーでた。
試しに他の登録サイトもﾘﾝﾄかけたら同じエラーでたよ。
しょうがないんじゃん？

769 ：765：04/07/30 07:29 ID:???

>766

>768

DTDが違うのか？
書き込み見て即試したけど、問題でなかった。
当方html4.01strict

770 ：768：04/07/30 07:41 ID:???

あれうちも4,01strictだよ。
ﾘﾝﾄで調べる時にURL入れてやるとエラーになるけど
ソースをテキストエリアに入れてやるのはエラーでない。
あとオプションの”以下すべてのチェックを有効”でやってる。
そうじゃなくて”宗教的なチェックは無効”にチェック入ってるかな？
それだったらエラーでないけど。

771 ：765：04/07/30 08:00 ID:???

>>770
ホントだ。
以下の全て～、にチェックつけたら出たよ。

772 ：Name_Not_Found：04/07/30 08:36 ID:???

何か予想はついたけど
すとりくたーってやっぱりテキスト系おおいんだな。
ちと萌えた。

773 ：Name_Not_Found：04/07/30 10:02 ID:???

>>772
なんだろう。テキスト系はネタ待ちじゃないから、思いつくまでの間、ってそういうこと考えてるゆとりがあるのよね。
ネタに追われるほど書かなきゃならんこともないし、気が向いたときに書くからかな。

774 ：Name_Not_Found：04/07/30 10:48 ID:???

>>764
validatorはDTDを見てるだけで、リンク先まで見ないからな。

775 ：Name_Not_Found：04/08/01 03:09 ID:???

なんかすっかり寂れたな。
ところでおまいらクラス名とかをちゃんと論理的にしてる？

776 ：Name_Not_Found：04/08/01 04:11 ID:???

↓以下、「論理」「論理的」の定義のおさらい

777 ：Name_Not_Found：04/08/01 04:30 ID:???

↑ガちんこ勝負

778 ：Name_Not_Found：04/08/01 12:32 ID:???

漏れの朕子は堅くて太くて大きいです。

779 ：775：04/08/01 12:59 ID:???

なんだこのスレ？
もしや住民は完全に避難してるのか？

780 ：Name_Not_Found：04/08/01 13:34 ID:???

>>705の通りです。

781 ：Name_Not_Found：04/08/01 14:46 ID:???

それもありそうだが、>>775が燃料だと思ってる物は水な気がする。

782 ：Name_Not_Found：04/08/01 15:02 ID:???

ttp://okiit.okihawk.org/

783 ：Name_Not_Found：04/08/01 16:25 ID:???

>>775
末期の日本軍の燃料並のオクタン価ですね

784 ：Name_Not_Found：04/08/01 17:14 ID:???

>>782
This page is not Valid XHTML 1.0 Transitional!な上に
地味過ぎ、そしておまけに見にくい(´･ω･`)
そこまで無理しなくてもいいのになぁ。

785 ：Name_Not_Found：04/08/01 18:10 ID:???

>>784
それ以前にマークアップされていませんが。

786 ：Name_Not_Found：04/08/01 18:44 ID:???

それ以前にそういうスレではありませんが。

787 ：Name_Not_Found：04/08/01 21:20 ID:???

下らない質問で恐縮なんですが・・・
ここのスレの住人的には、角が丸いBOXを作るために
意味の無いDIVを３～４個重ねるのは（自分はしないにしても）
許容範囲ですか？それともうんこ？

788 ：Name_Not_Found：04/08/01 21:28 ID:???

当然うんこ

789 ：Name_Not_Found：04/08/01 21:28 ID:???

ヽ(･∀･)ﾉ●ｳﾝｺｰ

790 ：Name_Not_Found：04/08/01 21:29 ID:???

余裕でウンこ

791 ：Name_Not_Found：04/08/01 21:30 ID:???

スタイルシートのためにidやclass振るのは許容範囲
それ以外はボッシュートアンドレイプ

792 ：Name_Not_Found：04/08/01 21:33 ID:???

でもそういう所は「やっぱテーブルレイアウトのがいいじゃーん」
って言われかねない点だから、どうしてもやりたいならそれこそ、そういう表現が
CSS で出来るようになるまでの transitional なマークアップと開き直ってしまっても
誰も責められないと思うな。やっぱ strict スレ的にはウンコだけど。

793 ：Name_Not_Found：04/08/01 21:55 ID:???

良くないと分かりつつ-moz拡張でもつかっとけ

794 ：Name_Not_Found：04/08/02 00:25 ID:???

>>791
スタイルシートのためにIDやCLASSを付けるんじゃない！
あくまで、意味があるからIDやCLASSを振り、
意味があるからその部分のスタイルを変更するんだ！

…建前上はな。

795 ：Name_Not_Found：04/08/02 00:27 ID:???

>>794
まあ、idやclassフリまくっても名前は一応ちゃんと命名しているから
代替スタイルシート書くときに威力発揮するんですよね…

796 ：Name_Not_Found：04/08/02 02:04 ID:???

まあスタイルを変えたりしても使い回しの利く所謂論理的なidやclassならたとえスタイルのためであっても、
あれだ、褒められたいが故に電車でお年寄りに席を譲るみたいな。

>>792みたいなのをアリとするなら、個人的にはありみか式って名前付けて良いのかは知らないがそれに一票。

797 ：Name_Not_Found：04/08/02 07:51 ID:???

>>787
角の丸いやつは文字サイズ固定でやれば、一応不要なdiv使わずとも
できるよ。文字サイズ固定はユーザビリティ無視だがstrictであるか否かには無関係だから
このスレ的には、どうしてもやりたいなら文字サイズ固定でやればいいんじゃない？
って結論だな。

まあネスケは文字サイズ固定できないから結局"あれ"なかんじだけど、まあStrictとは無関係。
っていうか、そもそも角の丸いやつを作るか否かはこのスレとは無縁。

class,idの命名に関しては、自分以外に対してもわかりやすい論理的なものにするのがいい。
極端にchapter,section毎にdivで括って構造を明確にして、divにidを振るのが一番手っ取り早い。
それならレイアウト変更の時に、HTMLをいじらずに済むから何かと都合がいい。

とりあえず、>>796の例えは微妙だなw

798 ：Name_Not_Found：04/08/02 08:21 ID:???

strictってのはユーザビリティを向上させる意味もあるような気がするが、
まあスタイルに関することはスレ違いだな。

799 ：Name_Not_Found：04/08/02 09:45 ID:???

>>798
Strictとユーザビリティは関係ないだろ。
論理的なマークアップと視覚、音声、その他UAでのユーザビリティを確保することは別問題。
たまたま論理的なマークアップが音声ブラウザには聞きやすいだけ。

文字サイズ固定でもstrictはstrict。

800 ：Name_Not_Found：04/08/02 10:29 ID:???

なんかよくわかりませんが800もらっときますね

801 ：Name_Not_Found：04/08/02 10:40 ID:???

ウホッ

802 ：Name_Not_Found：04/08/02 10:51 ID:???

>>799
ハァ？何だこいつ？
Strict=ユーザビリティだってことはW3Cの見解だっつんだボケェ！
仕様書熟読してこいよアフォ！

803 ：Name_Not_Found：04/08/02 10:58 ID:???

ここの連中は逝かれてるから気にするな。

804 ：Name_Not_Found：04/08/02 11:26 ID:???

プログラム(の著者)に対するユーザビリティはStrictと関係あるだろうな。
プログラムの利用者に対するユーザビリティは殆ど関係ないが。

805 ：Name_Not_Found：04/08/02 11:42 ID:???

>>803
そうだよな。ここに書きこむ連中は逝かれてるよな。

806 ：Name_Not_Found：04/08/02 11:47 ID:???

>そもそも角の丸いやつを作るか否かはこのスレとは無縁
そもそも(「角の丸いやつを作る」目的で) *無意味にdivを重ねること* は
ストリクター的に許されるかどうかって質問じゃないのか。

807 ：Name_Not_Found：04/08/02 11:59 ID:???

如何に Strict であり続けながら好みのレイアウトに仕上げるか、ってテーマにこのスレが真っ向から反しているとは思えん。スレ違いに認定されがちだが。

808 ：Name_Not_Found：04/08/02 12:43 ID:???

>レイアウトに仕上げるか
この段階でダウト。

例えばCSSに望むセレクタがあるか、望むプロパティがあるか、
と言う事とHTMLは分離されているべきと言うのがStrict。

809 ：Name_Not_Found：04/08/02 12:54 ID:???

真っ向からとまではいかないがスレ違い。
HTMLの規格的にはなんでもできるし、今有る規格でもXSLT+SVGでたいていのことはできる。
Strict+CSSやスタイルシート専用スレがあればいいんだけど。

>>802
文字サイズを固定するというのはスタイルシートのユーザビリティ。HTMLのユーザビリティとは無関係。
Strictにするとユーザビリティが上るというのはリンクにrel, revを設定したりtitleを設定したりとかそういうの。
しかし一方でユーザビリティとStrictは両立しないこともある。「ここをクリック」とか「メニューから○○を選んで……」などの特定のUA用の説明を加えればそのUAにとってユーザビリティは上るがStrictではない。
flashやフレームや別ウインドウも特定の場合にはユーザビリティーが上るかもしれないがそれもStrictではない(flashは代替を用意すればStrict)。

810 ：Name_Not_Found：04/08/02 13:13 ID:???

strictってのは「厳格な」という意味で、何にたいして厳格か、と言えば、
HTMLの「文書構造のみを記述する」という本分に対して厳格。

厳格にHTMLの本分を守ると、ユーザビリティが向上したりするのは、
そういう風にHTMLがデザインされているからで、Strict＝ユーザビリティ向上ではない。

例えばHTMLに欠陥があって、よりStrictに仕様とするとユーザビリティが下がる
事もあるかも知れない。この場合、Strictとユーザビリティという二つの「異なる価値観」
を天秤にかけてより文書を書く目的に合致した方を著者が選択する事になる。

Strictは飽くまでStrict。ユーザビリティやメンテナンス性の向上はなどは付随する
現象であって、Strictの本質とは無関係。

811 ：Name_Not_Found：04/08/02 13:17 ID:???

>>809
>特定のUA用の説明を加えればそのUAにとってユーザビリティは上るがStrictではない
そりゃ確かにそうだけど、Strictは「UAを問わない」っていう目標みたいなものがあると言えるから、
そういう発想は反則。
「Strictを崩してユーザビリティを上げたらStrictではない」っていうことなんだから。

812 ：811：04/08/02 13:17 ID:???

目標って言い方は変だったな。
まあ適宜解釈してくれよ、とか無責任なことを言ってみる。

813 ：Name_Not_Found：04/08/02 13:34 ID:???

どうしても、「 HTML = レイアウト」という図式が拭い切れていないんでしょうねぇ。
「マークアップよりも SEO 」なんてことを平気で宣う WEB 屋もまだまだ多い現状が如何ともしがたいけれども。

WEB 屋にしばし在籍していたけれども、「このレイアウトで他のページもたのみます。」と云われて、
「（なんじゃこれ）マークアップはしなくても良いのか？」と訪ねてみたところ、
「？？？」な顔されたときには正直悲しかったヨ。。。

814 ：Name_Not_Found：04/08/02 14:18 ID:xik5CmGA

英文の和訳の際の、以下のようなマークアップについて賛否を問わせてください。

<blockquote cite="http://hoge.com/" title="hoge.com - homepage">
　<p>Is this not strict as well as a cite element in blockquote?</p>
　<div xml:lang="ja" title="hoge.com - ホームページ">
　　<p>blockquote 内の cite 要素と同じく、ストリクトじゃないですか?</p>
　</div>
</blockquote>

815 ：Name_Not_Found：04/08/02 15:16 ID:???

>>814
利用しにくそうな構造なので俺は嫌い。

816 ：Name_Not_Found：04/08/02 15:22 ID:???

>>814
どうでも良いけど訳が怪しいので添削：
>blockquote 内の cite 要素とは違ってストリクトなのでしょうか?

817 ：Name_Not_Found：04/08/02 15:31 ID:???

not と as well as の組み合わせについてきちんと勉強しなされ。

818 ：Name_Not_Found：04/08/02 15:43 ID:???

<blockquote cite="http://example.com" title="example">
<p>原文</p>
</blockquote>
<p>以下日本語訳。</p>
<blockquote cite="http://example.com" title="example" xml:lang="ja">
<p>訳文</p>
</blockquote>

ってやるな。

819 ：818：04/08/02 15:49 ID:???

間違った xml:lang は逆だ。

820 ：Name_Not_Found：04/08/02 15:54 ID:???

>>817
>>814と>>816は意味は同じだろ。よく読んでくれ。
単に誤解の無いように書き直しただけであって、日本語の問題。

821 ：Name_Not_Found：04/08/02 16:11 ID:???

>>818 はつまり、>>814 の例と同じく、「訳文は引用文の範疇である」という見解なのだね?

822 ：Name_Not_Found：04/08/02 16:36 ID:???

　まず、文章は翻訳しても元の言語の著作者の著作物なので（それとは別に訳した人にも
訳したという著作権が発生するが）「引用の範疇」といえる。

ただ、>>814 の形式だと、「原文に訳文が含まれていた」のか「原文を引用者が訳した」のか
区別が付かないので、俺なら >>818 の4行目を
<p>以下、（訳者）による日本語訳。</p>
とする。
（訳者）が自分の場合、自分の名前なり「著者」などの文字列に成るだろうし、
他者による翻訳物の場合、<cite>（訳者の名前）</cite>とする。

※俺自身は普段ここまで厳密にはやってないけど、Strictスレ的には多分こうなるんでは、と。

823 ：814：04/08/02 17:04 ID:???

>>822
分かりやすい解説ありがとうございます。

blockquote を分けるかどうかについてですが、
　<p>以下、（訳者）による日本語訳。</p>
にはもちろん、引用文と厳密に関連付けられていない
　<cite>（訳者の名前）</cite>
にも具体的なメタは含まれていないので、>>814 の div 要素の title を
　title="(訳者) による日本語訳"
とするのと変わらないように思うのですがどうでしょうか。

824 ：818：04/08/02 17:10 ID:???

漏れの言いたいことを殆ど言ってくれたぜ>>822

>>814 だと何処までが原文の引用なのかが微妙だと思う。

825 ：822：04/08/02 17:14 ID:???

>>823
本件に限らず引用文と出典の関連付けは、
・UA向けの情報としては cite属性、title 属性で行う。
・読者（人）向けの情報はcite要素を使って読んで解るように文章で行う。

UAにさえ伝われば、読者向けのフォローはUAが行うべきだと思うなら、
title属性だけでも十分だろうし、その上で「地の文章として読者に伝えたい」
なら併せてcite要素などを使ったテキストの記述も推奨するが、
そこらへんは文書の用途とか、文脈とかに依存するので、適宜必要と
思われる範囲で記述するよろし。

826 ：Name_Not_Found：04/08/02 18:25 ID:???

一週間ほどスレ読まなかったらすごい話だったのね。
パンくずリストネタ、聞いていい？
駄目だったらスルーして。お願い。

">" って、この場合リダイレクトという意味があるのでしょう？

　　A > B > C

シェルスクリプト書く人なら、パイプとかいろいろ使うでしょう？
その広義の名残と思ってたけど。
各レスの引用に ">" 付けるのは、参照してけろってことでしょう？
ポインタを示すということじゃないのかい？

　　D / E / F

"/"使うのは、ディレクトリの構造を表記したいからじゃないのかい？

間違って覚えてるなら教えてくらさい、エロイ人。

827 ：Name_Not_Found：04/08/02 18:38 ID:???

>>826
1つの記号には1つの意味しかない訳ではないでしょ。
例えば ">" の場合、
レスの引用に現れたら参照を意味していて、
パンくずリストで現れたら階層構造 (あるいは何らかの順序) を意味している。
「パンくずリストの中の ">" を参照を意味している」というのは文脈を無視した餓鬼の屁理屈だぞ。

828 ：Name_Not_Found：04/08/02 19:07 ID:???

>>826
>が二項関係だときまってるわけじゃない。
/が有理数を表すときまってるわけじゃない。

829 ：Name_Not_Found：04/08/02 20:50 ID:???

>>828
記号の意味を特定のものに確定してしまいたいが慣習上もう無理ぽ
…というのが偉い人たちの本音だろうけどね。

830 ：826：04/08/02 21:19 ID:???

>>827-829
なるほろね。
strictってのはある意味「絶対」を求めてるのかね？
（strcitが絶対って意味じゃないですよ。なんとなく向かっている先ってことで。）
誰もが誤解し得ない物を求めてる感じ。論理的ってのはそうかも知れないね。
まあ、嫌らしく言うなら揚げ足取られない表現ともいえるけど。

なんか、strictに失望。
錯誤から生まれる良的な要素すら排除されていきそう。
主題がそこにある訳じゃないから、仕方ないんだろうけど。

エロイ人ありがとう。

831 ：Name_Not_Found：04/08/02 21:19 ID:???

物の見事にstrictと関係有りませんな。
単なる記号論で、文書構造とすら関係ない。

>聞いていい？
>駄目だったらスルーして。お願い。
しかも、自覚有り。

無能な釣りか、低脳な天然。どの道スルーで。

832 ：Name_Not_Found：04/08/02 21:49 ID:???

そもそもStrictの定義が各人によって異なるので、議論がかみ合わない。

833 ：Name_Not_Found：04/08/02 23:58 ID:???

HTMLの仕様、或いは仕様書が広義的な解釈が出来るように作られているので仕方ない。

834 ：Name_Not_Found：04/08/03 00:09 ID:???

>>831
おまいがいちいち批判すると馬鹿が暴れるから、こういうときはまずはおまいがスルーをするのだよ。

>>832-3
自信のなさなのか、ある程度の余裕を持たせたかったのかどっちなのかね。

>>all
全然関係ないけど携帯用のサイト作る時に、Strictで書いてるやついる？正直無理だよね？
まだ作ったことないんだけど、PC用のサイトでは完全にStrict+CSSで決めてるから、携帯も
ちゃんとStrictで書きたいな。

835 ：Name_Not_Found：04/08/03 00:18 ID:???

>>834
俺は携帯用のページを4.01strictで書いてるよ
（CSSは使ってません）

836 ：Name_Not_Found：04/08/03 00:20 ID:???

>>834
キャリアに依りますね。auとかならXHTML使えますから容量の都合上あんまり冗長にはできないですが無難なStrictにはできます。Vodafoneもそうでしたっけ？

837 ：Name_Not_Found：04/08/03 00:21 ID:???

>>834
スルー出来ない典型例

838 ：Name_Not_Found：04/08/03 00:25 ID:???

>>831
どのタグが適切かというのは、文書構造を論理的に記述する上でオミットすべき
話題ではないんでしょう？記号論にしか見えないのは、文書構造のことしか頭に
ないってことだと思うぞ。中身を適切に仕上げる事もstrict文書を作成する上で
考慮しなければいけないと思うけどね。

>>832
同意。

>>834
なぜstrictなんだ？
論理的だからか？基準書に定められたからか？それともカッコイイからか？
最小公約数として良さげだからか？
このあたりの前提がばらばらだと議論もなにもってとこですわなぁ。

839 ：Name_Not_Found：04/08/03 00:28 ID:???

「携帯用のページ」を書き分けること自体、限界を示しているだけどね。

840 ：Name_Not_Found：04/08/03 00:30 ID:???

>>838
そっすね

841 ：Name_Not_Found：04/08/03 00:31 ID:???

でも最近のケータイはパワフルになってきたしな。京ポンみたいなケータイばかりになれば……。

842 ：Name_Not_Found：04/08/03 00:32 ID:???

最小公約数って言葉を読んだのは人生二回目。

843 ：Name_Not_Found：04/08/03 00:37 ID:???

>>842
俺は十回以上はあるなあ。

844 ：Name_Not_Found：04/08/03 00:51 ID:???

最小公約数ならいつも1だな

845 ：Name_Not_Found：04/08/03 00:52 ID:???

最大公倍数よりマシかもね

846 ：Name_Not_Found：04/08/03 01:10 ID:???

正解:ぱんくずリストは使わない

847 ：834：04/08/03 02:12 ID:???

>>835-836
意外にできるのね。CSSはどのくらい対応してるんだろね。ってそれは自分で作る時に調べるからいいや。
>>837
俺も書いてて思ったよ。
>>838
何故ってストリクタンだから。
>>839
別にテーブルレイアウトでも携帯用には別途つくる必要があるんだけどね（テキストサイトでない限り）。

まあ早く携帯の機能が上がって、CSSもJSも完全にフォローしてくれればHTMLはひとつですむんだけどね。
画像もJSで渡すものを振り分けれるし（cgiでやれば今もできるけど）。

ところでサイト全部cgiにして、動的にHTMLを作ってCSSだけ数種類用意しておいてどんなキャリアにも対応できます！
みたいなサイトってないんかね。だいたいがいちいち別のHTMLを書いてるみたいだけど、更新が大変。
漏れの通販サイトは毎週更新だからしんどいよ。・・・・っていうかかなりスレ違いだorzスマン

日記うんたらっていうAAコピペの嵐だろうな

848 ：834：04/08/03 03:04 ID:???

うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこう
んこうんこうんこうんこうんこうんこうんこうんこうんこうんこうん
こうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ
うんこうんこうんこうんこうんこうんこうんこうんこうんこうんこう
んこうんこうんこうんこうんこうんこうんこうんこうんこうんこうん
こうんこうんこうんこうんこうんこうんこうんこうんこうんこうんこ

849 ：Name_Not_Found：04/08/03 06:17 ID:???

スルーできない典型例のうえスレ違い書き込みをやめられない典型例

850 ：Name_Not_Found：04/08/03 11:08 ID:???

苦しみながら死んで欲しいところだ

851 ：Name_Not_Found：04/08/03 11:57 ID:???

ﾜﾗﾀ

852 ：Name_Not_Found：04/08/03 13:07 ID:???

>>834
ウチのサイトはStrictだけど、携帯へはCGIを通して
タグを自動変換してページ分割したものを吐かせている。

例えば、
表示に影響しないlink要素など　→　削除
<h1>見出し</h1>　→　<h1><font color="blue">見出し</font></h1>
<em>にょにょ</em>　→　<font color="red">にょにょ</font>
一部の閉じタグ　→　<br>

ここの住人からみれば吐かれたソースは鳥肌ものだろうけど
元のページがXHTMLだったおかげで変換自体はスムーズ。
見た目のカッコよさからXHTMLに転向して2、3年経つが、初めてそれが役に立ったよ。
・・・テーブルレイアウトのままだったら、今ごろどうなっていたことか。

853 ：Name_Not_Found：04/08/03 13:24 ID:???

xsltつかってるよ俺は。

854 ：Name_Not_Found：04/08/03 13:52 ID:???

EZwebのサイトには、
9KB以内のShift_JISのXHTMLだけ対応と書かれてあるんだが、
auの携帯で、
20KBのISO-2022-JPで要素名を大文字で書いたHTML4.01Strictが
何の問題もなく閲覧できるのですが...。
これなら、携帯対策要らない。

855 ：Name_Not_Found：04/08/03 13:56 ID:???

元ソースは飽くまでstrictで作っておいた上で、
特定UAに対する出力形式と割り切ってTransitionalなHTMLを使う分には良いんじゃない？

ある意味、そう言うときのためのTransitionalな訳だし、Transitionalの欠点は、
元ソースをStrictで作っている事によって克服出来てるし。

856 ：Name_Not_Found：04/08/03 16:30 ID:???

経歴をウェブ上に載せる時は、どうやって書くのがいいですか？

19xx年07月　埼玉に生まれる
19xx年04月　自作自演高校入学
19xx年03月　自作自演高校卒業
19xx年04月　挫折大学無能学部入学
19xx年09月　論文：寄生と共生（引篭学会）
19xx年03月　挫折大学無能学部卒業
　　　　　　卒業論文：寄生生活への期待
19xx年04月　挫折大学大学院引篭研究科入学
19xx年06月　論文：逝ってよし（無職研究会）
19xx年10月　論文：寄生生物の生態（引篭学会）
19xx年06月　論文：萌え萌え（変態学会）
19xx年11月　論文：社会生活に適応するには（禿同学会）
19xx年03月　挫折大学大学院引篭研究科卒業
　　　　　　修士論文：引篭生態論
20xx年02月　著書：人生の負組み（ω出版）

857 ：Name_Not_Found：04/08/03 16:37 ID:???

>>856
その程度だったらふつうにdl要素でマークアップしたらいいんじゃないかい？

858 ：Name_Not_Found：04/08/03 16:45 ID:???

漏れは >>856 ではないのだけれど、
>>856 みたいなのとか what's new 的なモノは dl で漏れも書いている。
では大化改新から室町幕府までの年表、みたいなモノもdlなのだろうか、
年「表」なんだからtableなのか、悩みます。
どう？

859 ：Name_Not_Found：04/08/03 16:45 ID:???

>>857
俺ならdlだけど、tableでも間違いじゃないと思う。お好きな方で。

860 ：Name_Not_Found：04/08/03 16:59 ID:???

>>857-859
thx
現状ではtableで書かれていますが「表」では無いような気がするので
dlにすべきか、tableでも良いのか・・・と考え中。

>>858
what's newはdl使ってます。

861 ：Name_Not_Found：04/08/03 16:59 ID:???

あらわせる次元　　ol,ul <<<< dl <<<< table 　だから、どれでもどうぞ

862 ：Name_Not_Found：04/08/03 17:05 ID:???

>>858
最終的にどう利用したいか、でしょう。

リストで済むならdlでいいだろうし、表形式のデータとして複数列に内容を
保持したいならtable。
その上で、列数が1列(通常olやul)や2列(通常dl)の場合にtableを使っても
必ずしも間違いとは言えない。

ただ、一般的には、要素数が少ない（シンプルなソース）の方がUAへの負担が少ないので
特にどれかの要素にする理由がなければ、列数が1つならolかul、2つならdl、
3つ以上ならtableにするのが良いと思う。

863 ：Name_Not_Found：04/08/03 17:20 ID:???

DHTMLなんかを使うと、ブラウザ上で直接文字列を編集できたりするんですが、
HTMLでやる方法って何かありますかね？

ttp://www.makoto3.net/DHTML_IE_NEO/dhtml_ie_neo0225.html
ttp://www.makoto3.net/DHTML_IE_NEO/dhtml_ie_neo0226.html

こんなやつ。
Mozillaで表現できる類似の方法なら何でもいいんですけど。

864 ：Name_Not_Found：04/08/03 17:28 ID:???

>>863
必要性を感じない・・・って答えはダメ？

865 ：Name_Not_Found：04/08/03 17:31 ID:???

>>863
それはScriptなどの仕事であって、文書構造のマーク付け言語である
HTMLの仕事ではない。よって、スレ違い。

で。
スレ違いの上でW3C標準のやり方で無理矢理実現しようとするなら、
目標の要素のonfocusイベントで、目標の要素に重なるようにDOMとCSS使って
inputを表示させて、その編集用inputがonblurしたら、inputを消して、
元の要素に編集した内容をDOMで反映…かな。

866 ：863：04/08/04 09:39 ID:???

>>864
なるほど、そういう見方もありますね。参考になります。

>>865
情報ありがとうございました。その方法でまずは試してみて、
その上で他の選択肢も検討してみます。

867 ：Name_Not_Found：04/08/05 00:09 ID:???

ﾊｹﾞﾜﾗ

868 ：Name_Not_Found：04/08/05 10:19 ID:???

割り込むね。

あるページで画像を表示するのに、
これは絶対指定で正しいよね。
<img src="http://www.2ch.com/img/sample.jpg">

これもいいと思う。　ホストのルートからの指定。
<img src="/www.2ch.com/img/sample.jpg">

これは正しいの？
<img src="//www.2ch.com/img/sample.jpg">

RFC1738
scheme specific data は
共通のインターネット構文に対応していることを示すため
ダブルスラッシュ "//" で始まる。

は読んだけど、実際にどうなのかわからない。

これはだめ、だよね。
<img src="www.2ch.com/img/sample.jpg">

869 ：Name_Not_Found：04/08/05 10:52 ID:???

とりあえず、現在のURI仕様は RFC2396 だ。

www.2ch.com/img/sample.jpg も構文上間違いではない。
(意味は意図するものではないだろうが)

870 ：Name_Not_Found：04/08/05 11:08 ID:???

>これは正しいの？
><img src="//www.2ch.com/img/sample.jpg">
多分、正しい。
ただし、プロトコルの指定が無いので、ローカル環境でテストすると、
file://www.2ch.com/img/sample.jpg
を探そうとして失敗する悪寒。

また、
>これはだめ、だよね。
><img src="www.2ch.com/img/sample.jpg">
これも正しいはず。

ただし、
http://www.2ch.com/hoge.html
で、上記tagを記述すると
http://www.2ch.com/www.2ch.com/img/sample.jpg
を参照する事になる筈。(どこにも絶対パスと判断出来る記述がないし)

871 ：Name_Not_Found：04/08/05 14:06 ID:???

RFC2396 読んだけど、
authority component というのがよくわからない。
ホスト名とは違うのだろうか？
この二つの意味的な差異は？

<img src="//www.2ch.com/img/sample.jpg">
<img src="/www.2ch.com/img/sample.jpg">

872 ：Name_Not_Found：04/08/05 14:10 ID:???

どこがstrictHTMLに関する話なんだ？
論理的にマークアップすることと、URIと何の関係があるんだよ。

873 ：Name_Not_Found：04/08/05 14:14 ID:???

そういやURIについて議論するスレはないな。
そんなマニアックなスレがいるのかどうかは知らんが。

874 ：Name_Not_Found：04/08/05 14:34 ID:???

>>871
authorityの下りはよく解らんが、"//" だと絶対パスになって
"/" だと相対パスにならない?

>>872
本スレはStrictなHTMLに関する話題全般を扱う物であって、
論理的マークアップの話題が中心ではあるが、ある属性に入り得るvalidな値の
話題も一応スレ違いではないかと思われ。

どうせ今話題も枯れてるし。

875 ：Name_Not_Found：04/08/05 17:28 ID:???

じゃあStrictスレらしく、alt属性書こうよと敢えて言ってみる。

876 ：Name_Not_Found：04/08/05 17:30 ID:???

じゃあ、ついでにhtmlとheadとtitleとbodyとdivも書くか。
いきなりimgなんて有り得ないしね！

あほらし。

877 ：Name_Not_Found：04/08/05 17:48 ID:???

>>874
>ある属性に入り得るvalidな値の
>話題も一応スレ違いではないかと思われ。
俺様ルールを押し付けられちゃ迷惑。

878 ：Name_Not_Found：04/08/05 18:04 ID:???

>>877
～だと思うって口調を押し付けと取るのか。

879 ：名無しを決めよう @ ソフトウェア板：04/08/05 19:18 ID:???

じゃあStrictスレらしく、object要素で書こうよと敢えて言ってみる。

880 ：Name_Not_Found：04/08/05 19:33 ID:???

>>879
名前が残ってるぞ。。。

881 ：879：04/08/05 20:19 ID:???

やべ…

882 ：Name_Not_Found：04/08/05 20:26 ID:???

>>876
divよりもむしろpにしｔ(ry

883 ：871：04/08/05 20:44 ID:???

知ってたら、いじわるしないで教えてください。

884 ：Name_Not_Found：04/08/05 20:47 ID:???

>>883
Webサイト制作初心者用質問スレ vol.99
http://pc5.2ch.net/test/read.cgi/hp/1091428116/

885 ：Name_Not_Found：04/08/05 20:50 ID:???

どう考えても初心者の質問ではなさげだけどね。
まあみんな知らなかったということやね。

886 ：Name_Not_Found：04/08/05 21:05 ID:???

知ってたら、いじわるしないで教えてください。

887 ：Name_Not_Found：04/08/05 21:35 ID:???

>>871
http://example.org/xxx/yyy.html にこれが書かれているとすると、

src="//www.2ch.com/img/sample.jpg"
　→ http://www.2ch.com/img/sample.jpg を指す。
src="/www.2ch.com/img/sample.jpg"
　→ http://example.org/www.2ch.com/img/sample.jpg を指す。
src="www.2ch.com/img/sample.jpg"
　→ http://example.org/xxx/www.2ch.com/img/sample.jpg を指す。

これで分かったか？

888 ：Name_Not_Found：04/08/05 22:00 ID:???

> src="//www.2ch.com/img/sample.jpg"
>　→ http://www.2ch.com/img/sample.jpg を指す。
違くね?
http://example.org//www.2ch.com/img/sample.jpgだと思われ。
//は/と同等として扱われるからsrc="/www.2ch.com/img/sample.jpg"と同等と思われ

889 ：Name_Not_Found：04/08/05 22:33 ID:???

実際知ってて損はないけど、実用的な話をするなら、
相対パスを記述するのに　// は出てこないだろうし、
絶対パスを書きたいならプロトコルも一緒に書けばいいし。

890 ：887：04/08/05 23:04 ID:???

>>888
RFCを読め。"//" で始まるとその後ろは authority component。
"/" で始まるとその後ろは path component。これらは違う。

あと、パスの部分の "//" と "/" が同等に扱われるのは、
UNIX のシステムコールがそういう仕組みになっているから。
UNIX では "///aa//bb.html" というファイルをオープンしても
"/aa/bb.html" がオープンされる。

しかし、URI にはパスの "//" と "/" を同一視する規定はない。
つまり、"http://example.org/" と "http://example.org//" が
違うリソースを指すサーバーがあってもよい。

891 ：Name_Not_Found：04/08/06 00:17 ID:???

>つまり、"http://example.org/" と "http://example.org//" が
>違うリソースを指すサーバーがあってもよい。

で、これは Strict な HTML とどう関連性がある結論？

892 ：Name_Not_Found：04/08/06 00:27 ID:???

結論だけに関連性を聞くのか？

893 ：Name_Not_Found：04/08/06 08:48 ID:???

そういう鯖があった場合hrefやscrがそう言う値をvalidに
取り得るかどうかという話の途中で早漏

894 ：Name_Not_Found：04/08/06 09:20 ID:???

>>885
「初心者スレでなかったらここで決まり！」いう勘違いか？
初心者スレは、専用スレを立てるまでもないことを質問する場所でもあるが、
ここはそういうスレではない。

>>893
サバの仕様とStrictは関係ない。CSSと同じレベルでのスレ違いだな。

結局初めから最後までスレ違いだったわけだな。

895 ：Name_Not_Found：04/08/06 09:24 ID:???

検証。質問の最後に「～ストリクトですか？」とつけておかしくないか考える。

＞RFC2396 読んだけど、
＞authority component というのがよくわからない。
＞ホスト名とは違うのだろうか？
＞この二つの意味的な差異は？
＞
＞<img src="//www.2ch.com/img/sample.jpg">
＞<img src="/www.2ch.com/img/sample.jpg">

この二つはどちらがストリクトなのですか？それとも両方ストリクトですか？

A.ハァ？

896 ：Name_Not_Found：04/08/06 09:45 ID:???

890とか892が輝いて見える

897 ：Name_Not_Found：04/08/06 10:16 ID:???

890とか892とかの頭が輝いて見える。

898 ：Name_Not_Found：04/08/06 10:17 ID:???

どーせ話題ないしいっつも出る話題より面白いから俺はURIの話題でいいと思ってしまったorz

899 ：Name_Not_Found：04/08/06 10:21 ID:???

まぁ、実際 scr="//hoge.com/" は valid なの? って話題自身は、
id="1" はvalidかどうか程度の話題としてスレの範疇に引っかかってるじゃねーの
とは思うけどな。strictではないが、html周辺の話題ではある。少なくともCSSよりは
(HTMLファイルに直接書き込まれるデータとして)近い希ガス。

なんてったって、最近禄な話題がない、ってのが一番の理由だけどな。

900 ：Name_Not_Found：04/08/06 11:12 ID:???

スレ違いかどうかはともかくたとえスレ違いであってもある程度それらしい話題でごにょごにょ言ってれば変な話が出てくるのを防げるからかなりマシ。

901 ：Name_Not_Found：04/08/06 13:10 ID:???

別に四六時中にぎわってる必要はないんだから、話題がなきゃ黙ってりゃいいのよ。
妙な輩が書き込んだとしてそれこそスルーすればいいわけであって。

902 ：Name_Not_Found：04/08/06 13:31 ID:???

概出の予感だが

論理的に意味を持たない<br>はstoricter的にどうなの？

903 ：Name_Not_Found：04/08/06 13:31 ID:???

storicterじゃねえstricterだすまん

904 ：871：04/08/06 13:34 ID:???

>> 887
よくわかりました。　ありがとうございました。

スレ違いでごめんなさい。

905 ：Name_Not_Found：04/08/06 13:41 ID:???

>>902
その限定条件では不可でしょ。
<br>が論理的な意味をもつか？なら議論になる。

906 ：Name_Not_Found：04/08/06 13:50 ID:???

>>903
strictor だろ。そもそも形容詞は（ｒ

907 ：Name_Not_Found：04/08/06 13:56 ID:???

とりあえず水に流そう。

俺が最近気になってるのは、CSSでの話し。一般的にStrictHTMLであればCSSで何をしても
当然Strictなわけだ。しかしそれっておかしいのよね。この話は半分CSSが絡むからスルーしてもいいけど、
例えばHTMLのソースの最後に書かれている
<div id="cm">～</div>
みたいなものをCSSで画面の一番上に持ってくる。

表示には意味がないものと考えられがちだが、読む順番というものには明らかに論理的な意味がある。
だから<h2>の前に<h3>が出てはおかしいという話があるわけで。

しかしCSSで<h3>を<h2>の前に持ってきても何の非難もない。
俺的にはCSSで読む順番を変えるという行為は場合によってはStrictではないと思うんだがどうだろうか？
広告をCSSで一番上に持ってくるんじゃなく、相手に一番初めに読ませたいのなら
ちゃんとHTMLの中で一番初めに記述するべきだと思う。

908 ：Name_Not_Found：04/08/06 13:58 ID:???

>>905
セリフ等は<BR>で別の人であると示すので論理的な意味がある。

909 ：Name_Not_Found：04/08/06 14:03 ID:???

俺が今気になってるのはサイバーノーガード戦法

910 ：Name_Not_Found：04/08/06 14:07 ID:???

>>907
やっぱCSSや既存の実装にとらわれずにスタイルシートについて語るスレが欲しいね。

911 ：Name_Not_Found：04/08/06 14:13 ID:???

>>908
「場合がある」の追記をキボンヌ。

ちなみに、brに意味がある場合の最もわかりやすい例は
プログラミング言語の記述かと思われ。

912 ：Name_Not_Found：04/08/06 14:15 ID:???

>>911
「場合がある」って誰が言ってるんだ？

913 ：Name_Not_Found：04/08/06 14:18 ID:???

>>911
プログラミング言語等の記述は<pre>要素でやりませう。

914 ：Name_Not_Found：04/08/06 14:23 ID:???

>>913
現行HTMLだとp内にcode書いたりする場合はpre使えないし。

915 ：Name_Not_Found：04/08/06 14:26 ID:???

>>913
コードは pre って、仕様だったっけ？

916 ：Name_Not_Found：04/08/06 14:26 ID:???

>>914
ならdivでやればいいでしょ。現行だとp内にはリスト要素も入れられないんだから、
そういうときにはdivでやる。

917 ：Name_Not_Found：04/08/06 14:27 ID:???

>>915
コードは br って、仕様だったっけ？

918 ：Name_Not_Found：04/08/06 14:30 ID:???

>>915
整形済みテキストには<pre>要素って仕様書に書いてある。
コードが整形済みテキストでないと言い張るなら知らないけどね。

919 ：Name_Not_Found：04/08/06 14:30 ID:???

>>916
えー

920 ：Name_Not_Found：04/08/06 14:53 ID:???

>>916
でも、code要素の親要素が明らかに段落であるにも関わらずpreがつかえないから
といってdivにしちゃうのは問題でしょ。
「そう言う時はHTMLの制約だと思ってあきらめて文書構造を変更しろ」なら
仕方ないな、とは思うけど。

>>918
いくつかのフリーフォーマットタイプの言語は明らかに整形済みではないね。
しかし、フリーフォーマットのくせに「// は以降の行末までをコメントとして扱う」
とかなってるから非整形済みで改行に意味のあるプログラミング言語は存在する。

921 ：Name_Not_Found：04/08/06 15:05 ID:???

>>920
javascriptなんかは//～をコメントとして扱っている。
表示のときには空白として表示できているのだから何も問題ない。

922 ：Name_Not_Found：04/08/06 15:06 ID:???

あれ…
& #xA;が上手く表示されない…

923 ：Name_Not_Found：04/08/06 15:20 ID:???

>>920
既存の要素で表せないものであればdivで括ってもStrict。
整形済みテキストを含む段落というのは、現行のHTMLには該当要素がない。
だから間違いではない。もちろん既存の要素で何とかしようっていうのもありだと思うけど。
変にdivを嫌ってもしょうがない。

整形済みテキストの意味を勘違いしているぽいね。もう一度仕様書を読み返すことを薦める。

924 ：Name_Not_Found：04/08/06 15:25 ID:???

>>921
JavaScriptの SingleLineComment に LineTerminator(CR, LF, LS, PS) は含まれない。
SingleLineComment の後の LineTerminator は構文として解釈され
JavaScriptの自動セミコロン挿入機構に影響を与える。

925 ：Name_Not_Found：04/08/06 15:31 ID:???

話ずれて申し訳ないんだけどプログラミングコード記述関連ってことで。

プログラミングの「行」を明示的にマークアップするにあたり、
ol - li - code 構造で記述するってのは、あり？
それとも li 要素ごとに code は分断された複数の要素と見なされる？

926 ：Name_Not_Found：04/08/06 15:34 ID:???

>>925
コードはリストか? 箇条書きか?

927 ：Name_Not_Found：04/08/06 15:38 ID:???

>>925
明確な規定はないかと思われ。

li がプログラムの各行をitemとして持つとも解釈出来るし、
li が複数のプログラム（たまたま全部１行）を順番に持っているとも
解釈出来ると思われ。

XHTML2.0になったら l 要素だとは思うが。

>>926
それらのコードを「コンピュータへの実行命令を順番に箇条書きしたもの」が
（文字通りに）プログラムなのだから、プログラムをolで書くのは
あながち間違いではないかと思われ。

928 ：Name_Not_Found：04/08/06 16:44 ID:???

>>927後半
>～がプログラムなのだから、
これよりも次のほうが宜しい。
>～であるプログラムもあるのだから、そういう種類の

929 ：Name_Not_Found：04/08/06 17:58 ID:???

改行に意味がある（コードのうち）のだからといいたいんだろうけど
<pre>でも改行になるんじゃないの？<pre>の中の改行にも意味があって、意味のある改行の連続が<pre>ってことでは？

そもそも音声ブラウザ等の表示のないUAにもわかるように、コードを書くには整形済みテキストで足りるのか、
本当に論理的かってことだけど、音声で<pre>はどう読まれるのかな？

<pre>
print <<EOF;
test
EOF

</pre>

perlのヒアドキュメントなんかの終端識別子なんかの後の改行は目には見えないけど絶対に必要なもの。
これを論理的にマークアップするのに上みたくpreを使うと、視覚系UA以外には意味が伝わらないかな？

930 ：Name_Not_Found：04/08/06 18:31 ID:???

brは「そこに改行がある」
preは「この範囲は改行、空白、tabなどで整形済みのtext（で、且つ、
そのレイアウトがHTML的にも保持されるべき）」

重なったり、代用がきいたりもするが、preがあればbrが一方的に要らなくなる
訳でもない。

931 ：Name_Not_Found：04/08/06 18:46 ID:???

>>929
pre要素についての MAY, MUST, not required がどうなっているか仕様書読み直せ。

表示されようがされなかろうが、コード記述は空白類の維持が求められる。
その点で HTML によるコード記述は基本的に無理
(preは空白類の維持を保証してくれない)。
伝達可能なUAも中にはありうるという程度に考えておいた方が無難かと。

XML系なら原則として内部の空白類を破棄しないので
レンダリングがどうなるかはともかくとして伝達可能だろうけどね。

932 ：Name_Not_Found：04/08/06 18:54 ID:???

HTMLはコードすら記述できないくらいショボイものってことで解決いたしますた！
ところでプログラミング言語の解説サイトをHTMLで作ってるサイトは間違いですか？

933 ：Name_Not_Found：04/08/06 18:57 ID:???

>>911
こいつの発言が気になるな。>>912が突っ込んだのに何故かスルーしてるんだよ

934 ：Name_Not_Found：04/08/06 19:04 ID:???

>>932
> ところでプログラミング言語の解説サイトをHTMLで作ってるサイトは間違いですか？
HTMLであるが故の不便な点は多いだろうが
それが間違いかどうかは誰が決めることでもない。

935 ：Name_Not_Found：04/08/06 19:12 ID:???

>>932
>>931 を受けての発言なら HTML はじゃなくて、preは、だろ。
数値文字参照(又は文字実体参照)を使えば、空白類はしっかり記述可能だし、
改行もbr要素で問題なし。

# ってこれじゃあ寧ろpreに頼るな br 使え、と言う結論になりそうだが果たして…。

936 ：Name_Not_Found：04/08/06 19:31 ID:???

>>935
  を使えば連続するスペース(0x20)が記述できるって？

937 ：Name_Not_Found：04/08/06 19:40 ID:???

<pre>で思ったのですが、掲示板とかで
<textarea>要素を使って入力欄をつくりますけど、その<textarea>要素内に相手が書いた
ものは<pre>で括るのと、<p>で改行を<br>に置換するのとどちらがstrictとして好ましいでしょうか？
どちらにしても改行コードの置換は必要ですが。

938 ：937：04/08/06 19:42 ID:???

>>937
ごめんなさい訂正です。

>どちらにしても改行コードの置換は必要ですが。
これは
$buffer =~ s/\r\n|\r/\n/g;
等は最低限必要という意味です；紛らわしいこと書いてすみません。

939 ：Name_Not_Found：04/08/06 20:14 ID:???

>>938
$value = qq|<p>$value</p>|;
$value =~ s/\n\r/</p><p>/g;
$value =~ s/\n/</p><p>/g;
$value =~ s/\r/</p><p>/g;
$value =~ s/<p></p>//g;
でもいーんじゃないかな？(^-^)
とりあえずは何も考えずに改行→１つの段落の終わりとしてみることもできるので。

940 ：Name_Not_Found：04/08/06 20:45 ID:???

>>937-939
<pre>...</pre>は勧められない。長～い行ができちゃうと
読めたもんじゃないから。一方、洩れみたいに自分で段落
内も改行して揃える奴は改行を <p></p> にされると悲惨。
とすると結局次善の策ということで <br> になるんだよね。

941 ：Name_Not_Found：04/08/06 20:57 ID:???

>>940
> 長～い行ができちゃうと
> 読めたもんじゃないから。
見栄え。

>一方、洩れみたいに自分で段落
> 内も改行して揃える奴は改行を <p></p> にされると悲惨。
見栄え。

> とすると結局次善の策ということで <br> になるんだよね。
見栄え。

お前、このスレの1から読んで来い。

942 ：Name_Not_Found：04/08/06 21:28 ID:???

>>937
入力を行うユーザが自動整形を前提にするか否かで話が変わってくるだろう。

943 ：Name_Not_Found：04/08/06 21:50 ID:???

他人の打ち込んだ文章ほどマークアップしづらいものはない。

944 ：Name_Not_Found：04/08/06 23:17 ID:???

夏の所為か「 HTML = レイアウト」厨が沸いてきている悪寒。。。

945 ：Name_Not_Found：04/08/06 23:30 ID:???

はとむる　むぎちゃ　ぷーあーるー

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

>>943
よく他人が書いた文章をマークアップするけど、引用なのかただの鍵括弧なのかの判断に迷う。
あと見出しを全部鍵括弧で括られると、
「これは装飾だから消して良いのだろうか、それとも彼(女)は論理的に鍵括弧をつけたのだろうか」と悩む。
で、消したら「勝手に変えるなよ」と。

947 ：Name_Not_Found：04/08/07 00:04 ID:???

>>945
まちがい。

はとむる　げんまい　つきみそう～
どきだみ　はぶちゃ　ぷ～あ～る～

948 ：Name_Not_Found：04/08/07 00:15 ID:???

>>946
多分書き手の頭の中では構造も見栄えもまとめて再現、
ってのが前提に話が進んでるんだろうな。意思疎通すれ。

>>947
はとむぎげんまいつきみそう
どくだみはぶちゃぷーある

あと続き
ちこりーりょくちゃおおむぎなんばんきび（うろ覚え）

949 ：Name_Not_Found：04/08/07 01:33 ID:???

>>948
> ちこりーりょくちゃおおむぎなんばんきび（うろ覚え）
この辺はかなり強引に歌ってた覚えが。

950 ：Name_Not_Found：04/08/07 03:10 ID:???

<ul>
<li>はとむる
<li>げんまい
<li>つきみそう～
<li>どきだみ
<li>はぶちゃ
<li>ぷ～あ～る～
</ul>

順不同でよいのかしらん？

951 ：Name_Not_Found：04/08/07 03:56 ID:???

>>950
よくねえだろアフォ

952 ：Name_Not_Found：04/08/07 08:02 ID:???

>>945あたりから
ttp://pc5.2ch.net/test/read.cgi/hp/1086686223/l13

953 ：Name_Not_Found：04/08/07 13:32 ID:???

>>948
それでCSSでやったらIEでみられｎ(ry

954 ：Name_Not_Found：04/08/07 16:28 ID:???

>>946
あなたを攻める訳じゃないけど、
結局、文章内容を考慮しないで、strictに関係ないとかスレ違いで中身の議論し
ないから、思考停止して、そういう事に成るんでしょうねぇ。
なんかイメトレばかりで、実践した事ないって感じだよ。
URIの話もそうだし、907の話もそうだし。

955 ：Name_Not_Found：04/08/07 17:02 ID:???

>>954
>なんかイメトレばかりで、実践した事ないって感じだよ。
そうか？もしかしておまいとんちんかんか？

956 ：Name_Not_Found：04/08/07 17:35 ID:???

サイトの左側（右側）にメニューを表示したいんだけど、

このサイトについて
メニュー1
メニュー2
メニュー3
・・・

という感じにしたい。
リストを使うべきか、<p>を使うべきか、他の方法か。
意見を聞かせてください。

957 ：Name_Not_Found：04/08/07 17:48 ID:???

>>956
当然のようにリストでしょう

958 ：Name_Not_Found：04/08/07 19:55 ID:???

そろそろ次スレか。最近、流れが速くなったよね。

959 ：Name_Not_Found：04/08/07 20:55 ID:???

>>958
一日平均30レスくらい。
流れが速いのはそれだけstrictに興味を持つ人が増えたのかもしれない。もちろん一概には言えないけど。

とりあえずサッカー見ようぜ。実況を論理的にマークアップしながら

960 ：Name_Not_Found：04/08/07 21:13 ID:???

実況マークアップ言語LiveML

961 ：Name_Not_Found：04/08/07 22:42 ID:???

どんなデータが…？

962 ：Name_Not_Found：04/08/07 23:11 ID:???

<kita- />

963 ：946：04/08/08 00:02 ID:???

>>954
まじいみわかんないんだけど。
ぜんぜんかんけいないじゃん。

964 ：Name_Not_Found：04/08/08 00:27 ID:???

どこを殺陣読み？

965 ：Name_Not_Found：04/08/08 09:31 ID:???

亀でスマソ
>>957
わざわざありがとう。リストにする。

966 ：Name_Not_Found：04/08/08 21:35 ID:QdXZk3Gv

966

967 ：Name_Not_Found：04/08/09 10:57 ID:???

967

968 ：Name_Not_Found：04/08/09 17:45 ID:???

↑なんだこいつら？１０００土地土地とまだ早いだろ？きっと今すぐほーほけ居。
hey！
１０００土地土地とまだ早いだろ！
　　　　　　　　　きっと今すぐほーほけ居！　　　
カモン！
１０００土地土地とまだ早いだろ！
　　　　　　　　　お前も今すぐほーほけ居！

969 ：Name_Not_Found：04/08/09 19:12 ID:wgWap7Hy

969

970 ：Name_Not_Found：04/08/09 19:22 ID:???

1000取りは禁止事項なんでブラックリストに入れられないように頑張ってね
削除屋さんとかにチェックされるかもよ

971 ：Name_Not_Found：04/08/09 19:23 ID:???

2get!

972 ：Name_Not_Found：04/08/09 19:31 ID:???

>>970
へぇ

973 ：Name_Not_Found：04/08/09 19:38 ID:???

>>968を限りなくstrictにマークアップして↓

974 ：Name_Not_Found：04/08/09 20:06 ID:???

埋める前に次スレ立てやがれ

975 ：Name_Not_Found：04/08/09 20:11 ID:???

次スレねぇ…また無駄に浪費されるんだろうなあ

976 ：Name_Not_Found：04/08/09 21:16 ID:???

次

Strict-HTML スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/

977 ：Name_Not_Found：04/08/09 22:04 ID:???

>>975
20代も続くと議論のループになるな。
無断リンクスレとかもそうだからなー。

978 ：Name_Not_Found：04/08/10 11:55 ID:???

>>975
何か問題でも？

979 ：Name_Not_Found：04/08/10 11:58 ID:???

無駄だと思ったら見なければ良いだけなのにね。
自分は無駄な閲覧をし続ける馬鹿ですよ、とでもアピールしたいんでしょーか。

980 ：Name_Not_Found：04/08/10 12:42 ID:???

見なくても無駄かどうか解るならそうしてるよ。

981 ：Name_Not_Found：04/08/10 19:16 ID:???

>>980=975?
で、何か問題があるの？それとも個人的にもうすこし内容があるほうがいいんだどなぁ
っていうぼやきなの？

まあなんでもいいけどさ。とりあえず新スレ立ってるから梅ようぜ！
おまいらうめんのも仕事だぞ！しっかりやれ。

確か前スレ１０００は渋い感じだったな。今回はどんなだ？

しかし１０００のために埋めるってのが一番無駄なことだよな。
２ｃｈ全スレの970～の30を集めたら膨大な量だよ。それが全部1000!とかの無意味レスってのもすごい話だな。
阿藤さんの出番がきそうでしょうがない。

982 ：Name_Not_Found：04/08/10 19:18 ID:???

980超えたら一定時間経過後にdat落ちするから無理に埋めなくてもいいよ。

983 ：Name_Not_Found：04/08/10 19:22 ID:???

やれやれ。

984 ：Name_Not_Found：04/08/10 19:59 ID:???

ふう。