Strict-HTML スレッド25

1 ：Name_Not_Found：04/11/21 22:32:38 ID:XpvSccK9

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

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

Strict-HTML スレッド24
http://pc5.2ch.net/test/read.cgi/hp/1096723178/

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

2 ：Name_Not_Found：04/11/21 22:33:07 ID:XpvSccK9

3 ：Name_Not_Found：04/11/21 22:34:33 ID:XpvSccK9

■関連スレ
/* CSS･スタイルシート質問スレッド【37】 */ http://pc5.2ch.net/test/read.cgi/hp/1098720757/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
ユーザビリティ専用スレ　その２ http://pc5.2ch.net/test/read.cgi/hp/1020575673/
【みらくる】XHTML 2.0 (その2)【ドリーム】 http://pc5.2ch.net/test/read.cgi/hp/1098711758/
XML使いのスレ 2.0 http://pc5.2ch.net/test/read.cgi/hp/1057198990/
XSL/XSLT http://pc5.2ch.net/test/read.cgi/php/999654569/
【W3C】Web標準仕様・技術系総合スレッドその1 http://pc5.2ch.net/test/read.cgi/hp/1093950965/

■勧告等
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/xhtml2
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/

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

4 ：4様が華麗に4get：04/11/21 22:46:20 ID:???

XHTML2.0正式韓国ﾆﾀﾞｰ?

あ、間違えた。

XHTML2.0正式韓国ﾏﾀﾞｰ?

5 ：4様が華麗に大失敗・・・鬱：04/11/21 22:47:02 ID:???

XHTML2.0正式勧告ﾏﾀﾞｰ?

6 ：Name_Not_Found：04/11/21 22:56:37 ID:???

XHTML2.0正日勧告ﾏﾀﾞｰ?

7 ：Name_Not_Found：04/11/21 23:03:18 ID:???

>>1
おつとめごくろう

8 ：Name_Not_Found：04/11/21 23:06:31 ID:???

いや、XHTML2.0はもうちょっと洗練してからの方がいいな。

9 ：Name_Not_Found：04/11/22 00:18:47 ID:???

そもそもそんなものいらん
俺はHTML4.01を貫くぞ。
ブラウザが進化してからだなXHTMLに移行するのは。

10 ：ChaosicSoul ◆/yaJbLAHGw ：04/11/22 11:39:28 ID:Ap9QTEtc

質問ですが、XHTML 1.1で、Content-Typeがapplication/xhtml+xmlのとき、
Content-Style-Typeはtext/cssでいいのですか？
Content-Script-Typeはtext/javascriptでいいのですか？
それと、もう一つ質問ですが、「XHTML 1.0をモジュール化した」とはどういうことでしょうか？

11 ：Name_Not_Found：04/11/22 13:02:01 ID:???

>>10
Content-Style-Type: デフォルトスタイルシート言語のメディアタイプ
Content-Script-Type: デフォルトスクリプト言語のメディアタイプ

>「XHTML 1.0をモジュール化した」
XHTML1.0という文書型を切り貼りしやすいように再構成した、ということ。

12 ：Name_Not_Found：04/11/22 18:02:21 ID:???

>>11
アフォかお前は。

13 ：Name_Not_Found：04/11/22 18:19:16 ID:???

具体的に示さないとどっちもアホだと思われるよ。

14 ：Name_Not_Found：04/11/22 20:21:57 ID:???

>>13=>>11
素直に「どこが？」といったほうがいいんでない？
余計にアホに見えるよ。

15 ：ChaosicSoul ◆/yaJbLAHGw ：04/11/22 22:19:40 ID:Ap9QTEtc

Re:>11
スクリプトはJavaScript,スタイルシートはCSSに限定するとして、
メディアタイプはtext/javascript,text/cssしかないのですか？

16 ：Name_Not_Found：04/11/22 22:32:19 ID:???

>>15
CSSのメディアタイプは text/css (RFC2318)。
JavaScriptのメディアタイプは正式登録されたものは存在しない。

17 ：Name_Not_Found：04/11/23 01:42:58 ID:???

はやく移動したいんだが、思いつきでスレ立てたくないしなぁ。

前スレ>>1000
漏れはまだ着手してないけど、styxっつー配布終了されたBBSは「>>」とか「>>>」とかをblockquote要素ネストさせてたな。
そこらへんのルーチンを参考にさせてもらって、とか考えてたけど。

18 ：Name_Not_Found：04/11/23 01:55:01 ID:???

取り敢えず、perlで作ってみる方針でやってみよう。
って思うんだけど、どう？

一応貼り。
ツリー式掲示板
http://pc5.2ch.net/test/read.cgi/php/984662679/
ｵﾏｴﾗＰＨＰで掲示板つくれませんか？
http://pc5.2ch.net/test/read.cgi/php/1026233119/

19 ：Name_Not_Found：04/11/23 01:58:04 ID:???

>>18
とりあえず、下の方で、スレのテンプレ案とか話そうか。
んじゃ、逝って来る。

20 ：Name_Not_Found：04/11/23 01:58:10 ID:???

とりあえず、各種Wikiの記法が参考になるんでない？

21 ：Name_Not_Found：04/11/23 02:01:02 ID:???

Wikiは方言激しいからびみょ。
個人的には(X)HTMLの一部の要素に似てる方が書きやすい。

22 ：Name_Not_Found：04/11/23 02:04:18 ID:???

<p/SGMLのNETもどき？/

23 ：Name_Not_Found：04/11/23 06:03:01 ID:???

最近のサイトはStrictである事が多いので、LINTやValidatorの他に
ブラウザの印刷プレビューも使うようになった。
いくらStrictでスタイルを凝ってあっても、印刷プレビューで
ハミ金になってたら糞サイト。

24 ：Name_Not_Found：04/11/23 06:07:37 ID:???

しかし、デザインが糞なのも多い。

25 ：Name_Not_Found：04/11/23 10:49:00 ID:???

>>24
和訳:　しかし、見た目が糞なのも多い。

26 ：Name_Not_Found：04/11/23 14:42:23 ID:???

>>23
印刷時にハミ金になるのは防げるけど
1,2行だけハミﾁｿになるのも防ぎたい

│　　　　　　 │
　　　　　　　　　１枚目

│ (C)hogehoge. │
└──────┘
　　　　　　　　　２枚目

27 ：Name_Not_Found：04/11/23 16:54:13 ID:???

>>23
印刷はstrictと無関係。アフォなことをいうな。

28 ：Name_Not_Found：04/11/23 18:19:24 ID:???

>>26
お前もか。なんでHTMLと関係ない話題をここでするかな・・・・・

29 ：Name_Not_Found：04/11/23 20:27:24 ID:???

>>27-28
どうも最近は「CSSを使ったレイアウト」のことをstrictと呼ぶのだと
思っている人たちがいるらしい。

30 ：23：04/11/23 20:32:06 ID:???

うるせえ

31 ：ChaosicSoul ◆/yaJbLAHGw ：04/11/23 20:38:13 ID:9T7Ky8OB

Re:>27 そうだけどさ、糞サイトかどうかは、文法が正しいかどうかじゃないでしょ？

32 ：Name_Not_Found：04/11/23 20:42:50 ID:???

>>31
なんでここでうんこするの？

33 ：Name_Not_Found：04/11/23 21:07:22 ID:???

ここが肥溜めだからサ！

34 ：Name_Not_Found：04/11/23 21:07:39 ID:???

>>31
・・・・だからスレ違いと言われてるのがわからないのか？
ここはクソサイトを語るスレではないのであしからず。

35 ：Name_Not_Found：04/11/23 23:54:32 ID:???

レスを「Re:>**」と書くやつはスルーすれ。
何度もコテとトリップ変えてるが真性厨房だから話にならん。
ソフ板のあちこちのスレで鬱陶しがられてる。

36 ：Name_Not_Found：04/11/24 00:17:31 ID:???

数学板だけだと思ってた。

37 ：Name_Not_Found：04/11/24 00:21:23 ID:???

KingOfMathでぐぐれ

38 ：Name_Not_Found：04/11/24 00:36:18 ID:???

俺も Re; を見たら数学板だと思うなあ

39 ：Name_Not_Found：04/11/24 00:54:45 ID:???

普通に数学板の荒らしだから無視しよう…
（前はまだマトモだったが）

なんかエミュスレにも昔沸いていた気がする。
ちょっと心病んでます。

40 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/24 11:39:53 ID:qA8fZg3q

Re:>35-39 変なのが現れたな。さっさと巣に帰れ。

41 ：Name_Not_Found：04/11/24 11:48:18 ID:???

スルーよろ

42 ：Name_Not_Found：04/11/24 18:41:46 ID:???

要素ってのは<body></body>みたいな開始タグと終了タグの集合なの?

43 ：Name_Not_Found：04/11/24 18:58:19 ID:???

要素：開始タグから終了タグ

44 ：42：04/11/24 19:18:48 ID:???

じゃあ開始タグと終了タグに囲まれた内容は含まれない?

45 ：Name_Not_Found：04/11/24 19:32:52 ID:???

なんでそうなる。含まれます。

46 ：42：04/11/24 19:34:49 ID:???

<body>内容</body>
これは全部body要素ってこと?

47 ：Name_Not_Found：04/11/24 19:36:05 ID:???

そうだよ。それ以上は自分で調べなさい。

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

48 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/24 19:54:10 ID:qA8fZg3q

Re:>43,47 少なくとも、XHTML1.0 Strict,XHTML1.1ではそうだな。HTML4.01 Strictなどではタグの無い要素というのもありうるが。

49 ：Name_Not_Found：04/11/24 19:56:18 ID:???

タグのない要素って存在するのか？
普通に思い浮かばないんだが。

50 ：Name_Not_Found：04/11/24 19:59:57 ID:???

>>49
俺も無いと思うが…。
まさかテキストノードのことをさすわけでもあるまいし。

>>48
`終了タグ'とでもいいたいの？
単なる空要素(br,hr,meta,link)か、省略可能な要素だろう？

51 ：Name_Not_Found：04/11/24 20:00:29 ID:???

>>49
そいつはアホだから相手にしないでいいよ

52 ：Name_Not_Found：04/11/24 20:52:20 ID:???

あの……html要素とかhead要素とかbody要素とかtbody要素とか開始タグも省略可能なんですけど……。

53 ：Name_Not_Found：04/11/24 20:56:17 ID:6OjxJqVO

49 ：Name_Not_Found[sage] ：04/11/24 19:56:18 ID:???
タグのない要素って存在するのか？
普通に思い浮かばないんだが。

50 ：Name_Not_Found[sage] ：04/11/24 19:59:57 ID:???
>>49
俺も無いと思うが…。
まさかテキストノードのことをさすわけでもあるまいし。

>>48
`終了タグ'とでもいいたいの？
単なる空要素(br,hr,meta,link)か、省略可能な要素だろう？

51 ：Name_Not_Found[sage 閉じタグがないといえボケ] ：04/11/24 20:00:29 ID:???
>>49
そいつはアホだから相手にしないでいいよ

54 ：Name_Not_Found：04/11/24 21:20:10 ID:???

「省略可能」は「無い」と同値じゃないぞ。
省略すると補完されるだけ。

55 ：Name_Not_Found：04/11/24 21:22:40 ID:???

なにか、得意げな所申し訳ないが……「tagがない要素」はないよ。

「tagを書かなくても良い要素」はあるが、それはパーサが自動的にtagを
補完してくれているだけ。

「そもそもtagが存在せず、特定条件が揃うとある要素と見なされる」ってのは
少なくともHTMLには存在しない。(SGMLだと、特定書式で特定要素と見なされる、
と言うのがあり得る。)

ちなみに、tagの記述を省略しても良い要素や、そのように書かれた要素のことを
「タグの無い要素」と言わないから。少なくとも日本語では。

56 ：55：04/11/24 21:23:50 ID:???

かぶった。だからあれほど書き込む前にリロードしろとorz

57 ：Name_Not_Found：04/11/24 22:09:54 ID:???

>>55
真性のアフォ相手に何熱弁してるんだ？

58 ：Name_Not_Found：04/11/24 22:16:45 ID:???

59 ：Name_Not_Found：04/11/24 22:22:08 ID:???

>>58
仕様書に思いっきり書いてあります。

60 ：Name_Not_Found：04/11/24 22:29:33 ID:???

>>58
過去スレで何度もされている質問の気はするが、
文字エンコーディングの名前は大文字小文字を区別しない。

それにしてもやっぱりFAQとか用意した方がいいのかなあ…。

61 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/24 22:33:05 ID:qA8fZg3q

Re:>58 私はeuc-jpをよく見る。[>59-60]のいうように、どっちでもいいようだけど。

62 ：Name_Not_Found：04/11/24 23:21:03 ID:???

>>61
とりあえずお前は消えろ

63 ：Name_Not_Found：04/11/24 23:56:20 ID:???

文字コードは一つに絞って、総体としての互換性を上げんとする努力。

64 ：Name_Not_Found：04/11/25 00:34:25 ID:???

>>61
よく恥ずかしげもなく書き込めますね。

65 ：Name_Not_Found：04/11/25 02:06:29 ID:???

>>54 >>55
タグを省略した場合は、タグが補完されるわけじゃないだろ？
要素の開始地点や終了地点をタグなしで決定できるということ。
決してタグが補完されるわけではない。

例: HTML4でtable要素に<tbody>タグを書かない場合、
<tbody>タグが補完されるわけではなく、tbody要素が補完される。

66 ：Name_Not_Found：04/11/25 02:23:30 ID:???

>>65
DTD嫁。

67 ：Name_Not_Found：04/11/25 02:46:23 ID:???

>>66
具体的にどこが違うのかを言って下さい

68 ：Name_Not_Found：04/11/25 03:17:59 ID:???

>>66
バカだなこいつｗ
DTDと仕様書の違いもわからないんだろうなｗｗｗ

69 ：Name_Not_Found：04/11/25 08:26:52 ID:???

何でここで質問してるわけ？
ここで質問してる時点で釣りケテーイな訳だが。
取り敢えず誘導。

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

70 ：Name_Not_Found：04/11/25 09:41:17 ID:???

>>65
> <tbody>タグが補完されるわけではなく、tbody要素が補完される。
その通り。
でも、tbody要素が補完される＝前後にtobody開始、終了タグが補完される、なわけで、
そういう意味で言ってる、ってことをあんたが補完するといいだけだと思うんだ。

71 ：70：04/11/25 09:42:03 ID:???

oが一個多いから、省いて読もう、と補完してほしいんだ。

72 ：Name_Not_Found：04/11/25 10:13:08 ID:???

それは補完じゃなくて脳内修正

73 ：Name_Not_Found：04/11/25 10:32:41 ID:???

>>70
だからDTD嫁って。

HTML4のtbodyは「省略可」ではなく、「出現しても、しなくても良い要素」。
だからtagが書かれなかった場合、親要素(になったかもしれない)tableは
「tbodyを持たないtable」として処理されねば成らず、勝手に補完してはいけない。

>>65 そこを付いた結構高度な釣り。

74 ：Name_Not_Found：04/11/25 10:49:35 ID:???

>>73
tbodyは "+"、"?" なのは thead と tfoot お前がDTD嫁

75 ：Name_Not_Found：04/11/25 11:53:22 ID:???

>>73
それはXHTMLの話。

76 ：Name_Not_Found：04/11/25 13:28:42 ID:???

DOMアクセスできちゃうじゃん、tbodyとか。

77 ：Name_Not_Found：04/11/25 15:07:56 ID:???

>>76
仕様を語るにあたり実装は根拠にならんですよ。

78 ：Name_Not_Found：04/11/25 17:11:51 ID:???

>>76
xhtmlだとアクセスできないけどね

79 ：Name_Not_Found：04/11/25 18:33:34 ID:???

省略して、あるかのように扱われるのって有るといえるんだろうか。
そもそもtagってのはテキストで書いたときのものであって文章木になったらもう関係ないと思う。
例えばDOMで生成した要素がtagを持つかというとなんとも言えない気がする。

あとtagが省略可能なのは要素型であって要素ではないと思う。

80 ：Name_Not_Found：04/11/25 18:39:52 ID:???

またもやSGMLの呪縛が。

81 ：Name_Not_Found：04/11/25 18:43:37 ID:???

Gecko系UAとかだと、script で後から追加された要素も、
ソースを表示するとtagとして反映されてるし、
言葉遊びは置いておいて、書いても書かなくても等価の文書として処理されるからこそ
特定のtagが省略可能な訳で、仕様的に、文書構造的に「等価である」という
共通認識さえあれば、言葉尻はどうでもいい気がする。
(仕様に特定の用語として明言されているなら若干話はことなるが、
その場合も該当記述を確認するだけの話であって、論議のする対象にはならない）

82 ：Name_Not_Found：04/11/25 18:44:19 ID:???

どうでもいいがコメントは開始タグと終了タグの間にあっても要素の一部じゃないな。

83 ：Name_Not_Found：04/11/25 18:51:14 ID:???

>>82
「要素の一部」が「要素の内容」のことを指すなら、
XMLの場合は、コメントは要素の一部となりますね。
ttp://www.w3.org/TR/REC-xml/#dt-content

…SGMLの場合は知らないから勘弁。

84 ：Name_Not_Found：04/11/25 20:17:10 ID:???

>>81
Geckoの挙動を引き合いに出す意味が解らない。
「IEだと○○だし××である」ってのと同じ論理でいいのか？このスレで。

85 ：Name_Not_Found：04/11/25 20:24:11 ID:???

とりあえずGeckoやOperaではX(HT)MLモードとHTMLモードがあるって方向で

86 ：Name_Not_Found：04/11/25 20:51:52 ID:???

で結局タグがない要素もあるということでFA？

アフォが正しかったみたいだな。

87 ：Name_Not_Found：04/11/25 21:13:41 ID:???

推測の域を出てないんじゃ。

88 ：Name_Not_Found：04/11/25 21:22:35 ID:???

ちょっと話を切ってしまうんですが、
左にメニューを置いてあるサイトってよくありますよね。
例えば
--Contents--
・Diary
・BBS
・about
----Link----
・yahoo
・Google
・2ch
といった様に
メニュー内にもタイトル（Contents,Link）的な要素がある場合、
strict的にはどういうマークアップをすべきなんでしょうか？
<hn>だと右側のコンテンツによってはふさわしくないでしょうし
<p>辺りが無難？なのでしょうか・・・？

89 ：Name_Not_Found：04/11/25 21:24:39 ID:???

左、右を考えてしまっている時点でStrictなマークパップは難しい。
普通に考えればhnつかうな。
場合によってはdl-dtか。

90 ：Name_Not_Found：04/11/25 21:27:57 ID:???

マークパップ……名言誕生の予感

91 ：Name_Not_Found：04/11/25 21:30:22 ID:???

キーの打ち間違いとしてはありえそうな範囲だな。

92 ：Name_Not_Found：04/11/25 21:39:25 ID:???

>>70
「tbodyタグを補完したのと同じ挙動になる」なら正しいが、
「tbodyタグが補完される」は違うわけよ。
SGMLでは、要素にタグは必須ではないわけだし。

93 ：Name_Not_Found：04/11/25 21:50:45 ID:???

>>89
マークパップってどうやるんですか？

94 ：Name_Not_Found：04/11/25 21:54:52 ID:???

pap

pap1 /pæp/
[U]
1　（幼児・病人用の）パンがゆ.
2　《米略式》くだらない［子供だましの］考え［話，本，テレビ番組など］.
3　《米俗》政治家に図ってもらう便宜;（官公吏の）役得,特権.

pap2 /pæp/
[名]《主に方言》乳首（に似た物）.

95 ：Name_Not_Found：04/11/25 22:01:30 ID:???

>>94
で、どうやるんですか？
段落はどうすればいいんですか？見出しは？リストは？表は？

96 ：Name_Not_Found：04/11/25 22:45:43 ID:???

>>95
hn＋liでいいだろ
# 漏れはこういう構造にしてないから何とも言えないが・・・

<h2>めにゅー</h2>
<h3>contents</h3>
<ul>
<li>diary</li>
<li>bbs</li>
<li>about</li>
</ul>
（中略）
<h2>ほげほげ日記</h2>

97 ：Name_Not_Found：04/11/25 22:49:32 ID:???

その前にハイフンで装飾っぽくしているとことか、Contentは複数形なのにLinkが何故か複数形じゃないとかツッコミどころ満載。

98 ：Name_Not_Found：04/11/25 23:49:04 ID:???

そこでマークパップの出番ですよ。

99 ：Name_Not_Found：04/11/26 01:05:25 ID:???

rape oilを訳せ。

100 ：Name_Not_Found：04/11/26 02:23:40 ID:???

>>88
><hn>だと右側のコンテンツによってはふさわしくないでしょうし

なぜそう思うのだ？
hnはあくまで見出しレベルであって、厳密な意味でのsectionやchapterでは無いぞ。

101 ：Name_Not_Found：04/11/26 03:27:57 ID:???

>>100
そんなことを言っては論理性が失われる。

まあ普通に
<hn>ナビゲーション......ホゥ！ってBzのヨコチンでも浮かべてはしゃいだら？

102 ：Name_Not_Found：04/11/26 16:53:37 ID:hQx2pRJF

ていうかCSSの準拠がさー(-_~-)　ええ加減にして欲しい。　
ああもう、根幹が流動的でコロコロバージョン変わる上に、ブラウザごとに反応が違うとか、意味分からんから！
そもそもCSS自体がさー、TABLE多用やFONTタグより、機能的にも管理面でも優れてるってぇ、確かな確証は示せないのか？っていう話。　
ファイル作る際にいちいちタグや属性を触るのはイカン、
とか言うけど、どーせファイルなんて1個ずつテキストやら書き換えるんだから、それでタグも一緒にいじって何が悪いってのさ？
CSS好き好き派の主張見てると、大概、マークアップによって論理構造がどうのとか、本来HTMLの役目は云々とか、
そういう小理屈ばっかりで、そりゃ文章を論理立てて示したい、内容がきちんと読めればデザインがブラウザごとに違おうが構いやせんっていうサイトならいいかもしれんけど、
今のWebってのは、デザイナブルな雑誌やショーウィンドウを、そのままブラウザで見れるようにする、っていうのも揺るがしようのない主眼になってる訳じゃない。
ぶっちゃければ、私のようなデザイン業務が主体の人間からしてみれば、論理構造なんてどうでもいいのっ！
現場に居てみれば、制作第一段階で、どんな内容でどんなボリュームで、どんなレイアウトで、なんて決まらんっつーのよ。　んなもん、こっちの思考も、
そもそもクライアントの意思も論理立ってないんだから、論理立てたファイル作れってのが無理な相談ｗ

103 ：Name_Not_Found：04/11/26 16:54:33 ID:hQx2pRJF

いや、別にさ、CSS全否定はしないわよ。　複数項目にClassで統一デザインつけて一括で調整できるのは確かに楽よ。
でもさ、厳密に仕様書に従おうとすると、やれFONTタグ一切禁止だ、TABLEタグはレイアウト用じゃないし、
bgcolorもalignもnowrapもwidthも使っちゃいけないだ、なのにBLOCKQUOTEはレイアウト用に使っちゃいけない、DIVが多くてもいけない、
BRを連続させちゃいけないと、ごちゃごちゃうるさいねん！
じゃあなんで、それらのタグや属性があるのさ！ヽ(｀□´)ノ　widthつかわなきゃIEなんてぐっちゃぐちゃじゃあないかい。　
今まで、便利なアイテムとしてそれらを作りそして使わせてきたのに、いきなり使うなとか言われたって、理不尽でしかないじゃないかさ。
その辺の、納得できる説明できる輩が居ないのよねー、CSS派にはさ。
つーか、個人的には世間全てがそうカンタンには全CSSに移行はしないだろうし、私みたいに「お前らの言う事納得イカン」って思ってる人も少なくないと思うから、
いずれは妥協して、現行HTMLタグもありでしょう、っていう流れに戻ってくるんじゃないかと、密かに目論み中ｗ

http://www.myk-w.com/

104 ：Name_Not_Found：04/11/26 17:01:10 ID:???

宣伝ｳｾﾞｪ

105 ：Name_Not_Found：04/11/26 17:52:44 ID:???

>>102-103

W3C信者に怒られそうなことを書くスレ
http://pc5.2ch.net/test/read.cgi/hp/1071673655/

106 ：Name_Not_Found：04/11/26 17:57:25 ID:???

彼の憤りはもっともかもしれんが、書くところを間違えているよね…

…って、あれ？実装スレなくなっちゃった？

107 ：Name_Not_Found：04/11/26 18:11:42 ID:???

>>106
CSSに対する憤りはわからなくもないが、
嘘を書いている。さらに言うならばあれらはHTMLの役目じゃない。

役目という意味ではRSSは上手く言っている。
みんなRSSにはRSSの役目しか期待していないし、
RSSでデザイン考える人いないし。

108 ：Name_Not_Found：04/11/26 18:12:47 ID:???

ｽﾄﾘｸﾀ＝CSS好き
と思ってる人多いんだろうな。

109 ：Name_Not_Found：04/11/26 18:29:27 ID:???

>>107
そもそもお前はHTMLの役割を勝手に決め込んでいる。
>>102のアフォも勝手に決め込んでいる。

正しいという側面では両者にたいした差はない。

110 ：Name_Not_Found：04/11/26 18:31:26 ID:???

嘘つーか認識間違ってるよね。
fontとか作った人と使うなって言ってる人は違うわけだし
そもそもCSS1勧告はHTML3.2よりも先だし
HTML3.2と最初のHTML4の間も半年しか開いてないし。
# HTML3.2当時の策定経緯も実装先行型で今とは大分雰囲気が違うしね。

まあCSS(特にCSS2)が予想に反して
あまりに正確な実装の困難な仕様だったってことなんだろうなあ。

111 ：Name_Not_Found：04/11/26 18:41:16 ID:???

実装が困難というよりは過去の資産が使えない仕様だったってことでしょ

112 ：Name_Not_Found：04/11/26 19:12:20 ID:???

そりゃ過去の資産が不思議マークアップではどうにもこうにも。

113 ：Name_Not_Found：04/11/26 21:05:35 ID:???

<ol>
<li>
<dl>
<dt>tinko</dt>
<dd>eeee</dd>
</dl>
</li>
<li>
<dl>
<dt>manko</dt>
<dd>iiii</dd>
</dl>
</li>
</ol>

なんで駄目なんだ

114 ：Name_Not_Found：04/11/26 21:12:14 ID:???

人として駄目です。

115 ：Name_Not_Found：04/11/26 21:12:31 ID:???

>>111 >>112
たんに仕様書があいまいな書きかただったってだけでしょ。
>>113
なんだいきなり？dlは定義リストだぞ。意味わかるか？定義「リスト」だぞ。
読める？「リスト」なんだよ。わかんない？リストなんだよ。

116 ：Name_Not_Found：04/11/26 21:39:48 ID:???

<p>
なかなか面白いマークパップをしているサイトを見つけた。<br />
こんな風に段落の句点の都度、br要素で改行する。<br />
元の文章をある程度、句点ごとに区切り、推敲した感じを受ける。<br />
そしてこの記述法は部分的ではなくサイト全体に及んでいる。
</p>

ここまでくると段落と言う意味合いよりはむしろ整形済みテキストの方がしっくりする気がした。

117 ：Name_Not_Found：04/11/26 22:50:15 ID:???

ポップでビートなマークパップ！

118 ：Name_Not_Found：04/11/26 22:56:14 ID:???

>>116
改行と完全整形済みテキストでは違うだろ。しっかりしろよ。

119 ：Name_Not_Found：04/11/26 22:58:50 ID:???

何。マークパップって、不思議マークアップの事?

120 ：Name_Not_Found：04/11/26 23:22:39 ID:???

カウボーイなんとか？

121 ：Name_Not_Found：04/11/26 23:36:32 ID:???

それはビバップ

122 ：Name_Not_Found：04/11/27 00:51:47 ID:???

>>118
改行は見栄えなの？それとも意味なの？

久しぶりにお前らの馬鹿っぷりを発揮してくれ。

123 ：Name_Not_Found：04/11/27 00:54:59 ID:???

いい加減飽きた。

124 ：Name_Not_Found：04/11/27 00:56:01 ID:???

ネタ投下にマジレスすまんが、
> 今まで、便利なアイテムとしてそれらを作りそして使わせてきたのに、いきなり使うなとか言われたって、理不尽でしかないじゃないかさ。

こいつ3.2とか使ってたのかな。

125 ：Name_Not_Found：04/11/27 02:09:16 ID:???

というかストリクトとはテーブルレイアウトを否定することではなく、
セマンティックウェブのためのコーディングに移行していこうってもんだ。

つまりテーブルレイアウトの利点を否定などする馬鹿はストリクタンではないのだよ。
ストリクタンの目的はセマンティクウェブにある。
その実現には全員の協力が必要であって、相手を否定したりけなしたりすることは
ストリクタンとしてあるまじき行為。

126 ：Name_Not_Found：04/11/27 02:11:47 ID:???

>>125
というか、とかつまり、とか何にかかってるかわからんな。
strictな文章じゃあない。

127 ：Name_Not_Found：04/11/27 04:26:38 ID:???

>>126
お前はstrictの意味から勉強しなおして来い。
文章にstrictもくそもないんだよ。
strict＝論理的
みたいに使うな。
strict＝論理的なコーディング
なんだから。なんでもかんでもstrictって言葉を使えばいいってもんじゃない。

ば～か＾＾

128 ：Name_Not_Found：04/11/27 05:52:36 ID:???

>>127
厳密な文章じゃない、って読めないバカですか

129 ：Name_Not_Found：04/11/27 07:41:42 ID:???

>>128
厳密な文章？？？
何いってんだお前？

130 ：Name_Not_Found：04/11/27 07:46:50 ID:???

またstrictの意味がわからないアホが来てるのか・・・

なんでこう定期的に来るかな。

131 ：Name_Not_Found：04/11/27 07:51:08 ID:???

>>130
そう言うあんたも、同じことを飽きもせず…
いや、何でもない。

132 ：Name_Not_Found：04/11/27 08:52:00 ID:???

>>124
たぶん「blockquoteタグはインデント、emタグは斜体」の類のタグ講座を
長いこと信じてたのではないかと。
(当然tableが作られた目的はレイアウトだと思ってるとか)

133 ：Name_Not_Found：04/11/27 09:34:17 ID:???

>>132
んじゃ、
＞いきなり使うなとか言われたって、
ってのはなんだろうか。
ｽﾄﾘｸﾀﾝとの接触だろうか。

134 ：Name_Not_Found：04/11/27 10:36:47 ID:???

>>133
「使ってはいけません」と書いてあるサイトを見た
↓
自分に対して制限しているように脳内変換

こういう表現はよくある。

135 ：Name_Not_Found：04/11/27 10:50:09 ID:???

前スレの話題～>18-19が
このスレに移住する模様…？
http://pc5.2ch.net/test/read.cgi/php/1101518977/

136 ：Name_Not_Found：04/11/27 11:51:52 ID:???

>>134
「非推奨」って解説サイト等で見かけただけで
仕様書の原文で確認してないっぽい感じは確かに濃厚だよな。

137 ：Name_Not_Found：04/11/27 12:10:05 ID:???

>>135
いまさら
わしらとっくに移動して、こっちと行ったりきたりしとるぞ。随分前から。

138 ：Name_Not_Found：04/11/27 13:58:58 ID:???

>>135
ここより荒れてるやん・・・

139 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/27 22:35:36 ID:o9oScCly

インデントはスタイルシートでできるということを、どれだけの人が知っているのだろう？
text-indent

140 ：Name_Not_Found：04/11/27 22:49:36 ID:???

はー

141 ：Name_Not_Found：04/11/27 23:00:55 ID:???

ほー

142 ：Name_Not_Found：04/11/27 23:02:54 ID:???

（´-｀）.｡oO(>>139がスレ違いだということは皆知っているけどな・・・)

143 ：Name_Not_Found：04/11/27 23:05:22 ID:???

(　・∀・)つ〃∩ﾍｰﾍｰ

144 ：Name_Not_Found：04/11/28 01:20:50 ID:???

>>139
それ字下げ
普通インデントいうたら他のモン想像するで

145 ：Name_Not_Found：04/11/28 01:22:01 ID:???

うわ、やらしい

146 ：Name_Not_Found：04/11/28 01:34:46 ID:???

マジレスかっこいい

147 ：Name_Not_Found：04/11/28 12:06:40 ID:???

御免なさい･･･悪気は無かったんです。
ただ、英語が苦手なんでやってみたら少しは分かり易くなるかなとか思っただけなんです･･･

Google
http://translate.google.com/translate?hl=ja&sl=en&u=http://validator.w3.org/&prev=/search%3Fq%3D http://validator.w3.org/%26num%3D100%26hl%3Dja%26lr%3Dlang_ja%26oe%3DShift_JIS%26inlang%3Dja%26c2coff%3D1
Excite
http://www.excite.co.jp/world/english/web/?wb_url=http://validator.w3.org/&wb_lp=ENJA&wb_dis=2&wb_co=excitejapan

148 ：Name_Not_Found：04/11/28 14:48:31 ID:???

>>132 > 当然tableが作られた目的はレイアウトだと思ってるとか

人の目に対するレイアウト目的で作られた。
出来れば見やすいように表として整形した方がいいよ、とUAに伝えるための要素型。

149 ：Name_Not_Found：04/11/28 15:17:06 ID:???

印刷媒体に見られるレイアウトを実現するための要素型だったが、
WWWのエライ人たちも目だけじゃ駄目だろうと早々に気付いた。
耳や指の感覚のために、くどいほど冗長な属性がいくつも決められた。
これらの属性を適切に使わない場合、耳や指だけで情報を得ている人々を
無視していることになる。法律で罰則を決めて取り締まれば、と思う。
大変な額の罰金を徴収できそうに思われる。

150 ：Name_Not_Found：04/11/28 15:42:49 ID:???

>>148
言い回しが微妙なんでどういう意図なのかわからないけれど、
UAの挙動を仕様書で指示されている箇所はあるが、
「レイアウト目的で作られた。」わけではないでしょ。

恐らく仕様書の
＞別の表などのデータを、コマの行と列とに配置することができる。
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/tables.html#edef-TABLE
あたりのくだりを指してるんだろうけど。

151 ：Name_Not_Found：04/11/28 16:09:31 ID:???

>>150
HTML4の仕様書での話じゃなくて、「作られた」当初の話はどうなんだろ？
HTML3.2とかよりさらに前の頃のNetscape社の意図とか。
それなら「レイアウトのために作られた」はあながち間違ってないかも。

152 ：Name_Not_Found：04/11/28 17:10:59 ID:???

>>151
実装側の当初の主目的がレイアウトだったら
「スペーサーGIF」が必要になるようなレイアウトアルゴリズムはクソだよなぁ。

ちなみにHTML3.2のまえにRFC1942 "HTML Tables"(1996.5) なんてのがあるね。
Experimental だけど W3C の D. Raggett が書いてる。

153 ：Name_Not_Found：04/11/28 19:14:31 ID:???

>>152
Netscapeには <SPACER> という要素があったので、それとセットで使う
ことを想定していたのでは？

<P>test
<SPACER TYPE=VERTICAL SIZE=100>
<P>test<SPACER TYPE=HORIZONTAL SIZE=200>test

こんな感じ。まったく普及しなくて Netscape6 では削除されたが。

154 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/28 22:50:01 ID:iXoE9JXs

Re:>142 上の方でインデントの話をしていたからな。

155 ：Name_Not_Found：04/11/28 22:56:17 ID:???

(･∀･)ﾆﾔﾆﾔ

156 ：Name_Not_Found：04/11/28 22:58:52 ID:???

スレの流れには乗ってるが、その流れそのものがスレ違いだからな。

157 ：Name_Not_Found：04/11/29 00:35:35 ID:???

>>152
レイアウト、と言っても「表としての見栄えを提供する」って意味合いだと思うんだけどな。
視覚的に「表であることを明示できるように振舞う」は、見栄えだけれど、
コンテンツ配置のために使ってよいよ、って意味ではないだろうし。

＞「スペーサーGIF」が必要になるようなレイアウトアルゴリズムはクソだよなぁ。
ごめん。これの意味が分からない。なくてもなんら問題なくない？

158 ：Name_Not_Found：04/11/29 01:12:49 ID:???

>>157
その前の文章が前提になってないと理解できないと思われ

159 ：157：04/11/29 01:31:30 ID:???

>>158
間違えた。前文は>>151に、引用して返信してる部分が>>152に、だ。

160 ：158：04/11/29 01:44:07 ID:???

だから

>実装側の当初の主目的がレイアウトだったら

これが前提でないと理解できないんじゃないかと言っている

161 ：157：04/11/29 01:56:29 ID:???

>>160
いや、レイアウト目的だとしても、それが指すレイアウトってのは、「表のセルの配置」を意味してるんじゃないか、と言ってるんだ。
それでも充分に見栄え目的の要素だと言えるけど、
他のレイアウトにも使える、は拡大解釈だろうな、と。

162 ：Name_Not_Found：04/11/29 08:10:24 ID:???

今度は「レイアウト」の語義から擦れ違ってんのか。

163 ：Name_Not_Found：04/11/29 10:41:40 ID:???

と言う話をstrictスレで話して、何らかの結論が出して、それが一体何なのだ。

ネタもない閑散期だから別に困らないけど

164 ：Name_Not_Found：04/11/29 14:26:32 ID:???

と言う煽りをstrictスレに書き込んで、何らかの反応を待って、それが一体何なのだ。

乗る奴もいない閑散期だから別に困らないけど

165 ：Name_Not_Found：04/11/29 18:18:45 ID:???

>>163
ここはstrictに関係する半分雑談スレだぞ？
論議の果てをみるのではなく論議自体を楽しめ。人生と同じさ。
>>164
ハァ？
なんてなえ＾＾

そもそも表＝テーブルではないことを理解してない人がおおいよね。
表は思いっきり視覚整形だけど、テーブルは構造整形だからね。

166 ：Name_Not_Found：04/11/29 18:26:15 ID:???

言葉遊びは飽きた

167 ：Name_Not_Found：04/11/29 22:30:52 ID:???

MS-Officeに例えれば、本来ワードで書かれるべき文章をエクセルで書く人とか、
右寄せとか、均等配置があるのに、一々データにスペース入れて整形し、
マクロの表示結果がおかしいとマクロ作者に苦情言う人は少なくないからな。

一般に見栄えと文書の構造の区別なんか、付けなくても問題ない、って方が
大多数だろ。(理解する能力はある筈なんだ。必要性が全く理解できないだけで)

168 ：Name_Not_Found：04/11/30 00:29:04 ID:???

あれだな。
HTMLの仕様に沿っているっていう属性が欲しいな。

<html isHTML="yes" xmlns="..." />

これだと、純粋にHTMLとしての情報として価値があり、
無表記だとわからなくて、noだと価値が無いということにする。
仕様に沿って無いくせにisHTML="yes"って書いてあるサイトをこのスレッドで叩くとか。

169 ：Name_Not_Found：04/11/30 00:32:16 ID:???

こちらへ逝きなさい

【Not Valid】偽HTMLがW3Cアイコン貼るな！
http://pc5.2ch.net/test/read.cgi/hp/1065719058/

170 ：Name_Not_Found：04/11/30 00:44:29 ID:???

>>168
今のところDOCTYPE宣言で十分役割が果たせそうに思うが。

171 ：Name_Not_Found：04/11/30 00:46:00 ID:???

>>168
>170に禿同。仮にあっても>169みたいに詐称されるだけ。

172 ：Name_Not_Found：04/11/30 01:11:23 ID:???

>>171
市ね
>>170
何がぁ？
>>169
初めて知ったよ
>>168
いらないよ
>>167
馬鹿は馬鹿
>>166
チン故意尻は飽きないのにか？
>>165
これ俺。

173 ：Name_Not_Found：04/11/30 01:15:46 ID:???

>>172
分かった、分かったから、アンコール。

174 ：Name_Not_Found：04/11/30 05:44:41 ID:???

>>170,171
そういうわけでなくて、DOCTYPEだととりあえず書いておけという
風潮が出来てしまっているが、この属性の場合だと、
仕様にしたがっているということを明記していることになる。
この微妙な乙女心を理解できないやつは童貞確定。

175 ：Name_Not_Found：04/11/30 07:16:21 ID:???

とりあえずyesと書いておけって風潮が新しくできあがるだけだろ。意味無さすぎ。

176 ：Name_Not_Found：04/11/30 08:35:54 ID:???

変なHTMLに対してはブラウザがパーズエラー出すようにしちゃえばいいんだよ
そうすりゃブラウザの動作も軽くなるし一石二鳥だぜ

177 ：Name_Not_Found：04/11/30 08:51:00 ID:???

>>176
するとtext/htmlなXHTML1が空要素表記でエラーになったりするんだろうな。

178 ：Name_Not_Found：04/11/30 10:10:35 ID:???

>>168
その属性を書いて特をする、と言うかそう言う需要が有るのは誰？

site記述者が「俺は仕様に沿ったHTML書いてるんだぜ」と言う意思表示なら
>>169 みたいな詐称とか「とりあえず書いとけ」と言う風潮に勝てないので意味無いと思う。

閲覧者が2次利用する為に仕様に沿っているかどうかを知りたいなら、
検証サービスへのリンクを張るとか、application/xmlとしてXHTMLを
提供すればいい(単なるパースだと仕様に沿っているという保障には
ならないが、少なくとも整形済みとか、validで有ることは解る)

179 ：Name_Not_Found：04/11/30 11:32:04 ID:???

>>175-176,178
お前らも童貞か。私の処女を汚すなッ<｀д´>！！
選択肢にnoもあるんだよ。つまり、W3Cについていけない人も
考慮してんだよ。DOCTYPEなんか省略したら終わりじゃないか。

もういいよ！オイラが間違ってたださ！　ふん、ケツの穴はくれてやる。

180 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/30 13:10:26 ID:V0oFycd3

エンコード指定、タイトル、見出し、段落のみでドキュメントを構成するのってどう？
(これではマークアップ言語の存在意義が無くなるか？)
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=Shift_JIS" />
<title>タイトル</title>
<h1>見出し</h1>
<p>段落</p>

181 ：Name_Not_Found：04/11/30 13:55:50 ID:???

>>180
HTMLでは head, body のタグは省略可能だから、
そう書いても何も問題はないが。
まあ、text/html でなきゃならんが。

182 ：Name_Not_Found：04/11/30 14:41:26 ID:???

吸いません、掲示板のdl内のdtの部分をStrict化するためにhnに変更しました。

No.1 名前:Name_Not_Found メール:[email protected] 04/11/30 14:38:00 ID:???

とブラウザに表示してもらいたい時は
<hn>
<span title="No.">1</span>
<span title="名前">Name_Not_Found</span>
<span title="メール">[email protected]</span>
<span title="時刻">04/11/30 14:38:00</span>
<span title="ID">???</span>
</hn>
とマークアップして、他の部分(名前とかIDとか)はスタイルシートで追加するようにすれば
よりStrictになりますか？

183 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/30 14:45:48 ID:V0oFycd3

Re:>182
hnって何？h1,h2,h3,h4,h5,h6のこと？

ところで、XHTML1.1 では、aタグにtarget要素が使えないようですが、
これに代わる物はあるのでしょうか？

184 ：Name_Not_Found：04/11/30 14:46:34 ID:???

厳密にStrictにやりたんだったらTableでも使えば？

185 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/30 14:46:39 ID:V0oFycd3

ターゲット要素 → ターゲット属性

186 ：Name_Not_Found：04/11/30 14:47:07 ID:???

>>183
http://pc5.2ch.net/test/read.cgi/hp/1101583920/
http://pc5.2ch.net/test/read.cgi/hp/1092941001/

好きな方へ行け

187 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/30 14:48:06 ID:V0oFycd3

Re:>184
スタイルシートでセレクタをうまく指定する方法があったりもする。

188 ：Name_Not_Found：04/11/30 14:55:54 ID:???

>>182
hnでマークアップするならリテラルとして「ID:」の部分まで書くべきだと思う。
それか>>184の言うとおりTableか、dl-dt-ddで書くか。

189 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/30 15:02:16 ID:V0oFycd3

Re:>184,188
お前は、blockquoteでインデントしようとする人とどこが違うのだ？

190 ：Name_Not_Found：04/11/30 15:12:05 ID:???

>>182
吸えよ

191 ：Name_Not_Found：04/11/30 15:19:45 ID:???

>>189
意味がよく分からない。
スレッドのデータ構造としてTableを使用するのと視覚デザインとの繋がりが全くない。

Tableを使うのはSQLで
CREATE TABLE aThread (
　　no INTEGER UNIQUE,
　　name VARCHAR,
　　mail VARVHAR,
　　datetime TIMESTAMP,
　　id CHAR(8)
)
みたいにクエリ投げるのといっしょ。

192 ：184：04/11/30 15:41:56 ID:???

>>189
なんかCSSのセレクタがどうのと勘違い甚だしいようだが。
「ID」は「???」のデータに対するヘッダだからth要素に格納。
他の各データ（名前とか日付とかメールアドレスとか）も同様に処理。
これのどこがblockquoteでのインデントに相当するのか。

193 ：Name_Not_Found：04/11/30 15:44:21 ID:???

Strictスレって定期的にtable完全否定派が降臨するよ。
tableはデータを見栄えで配列したものだから極力使うな、とか。

194 ：Name_Not_Found：04/11/30 15:52:56 ID:???

それ以前に189はStrictを全く理解していないようだが。

195 ：Name_Not_Found：04/11/30 16:55:44 ID:???

>>182
そもそも、そのhnは「書き込み情報のヘッダ情報」だと思われる。
つまり真のtitleは「No」に相当する「１」であり、他の要素は書き込みのメタ情報。

従って「俺なら」１つの書き込みを以下の様に記述する。

<hn>1</hn>
<dl class="meta">
　<dt>名前</dt>
　<dd>Name_Not_Found</dd>
　<dt>メール</dt>
　<dd>[email protected]</dd>
　<dt>時刻</dt>
　<dd>04/11/30 14:38:00</dd>
　<dt>ID</dt>
　<dd>???</dd>
</dl>
<div class="body">
書き込みの内容……
</div>

196 ：Name_Not_Found：04/11/30 18:56:00 ID:???

>>193
ここ2年くらいは見てないような気が

197 ：Name_Not_Found：04/11/30 19:32:33 ID:???

前スレにいたような気もする

198 ：Name_Not_Found：04/11/30 20:54:33 ID:???

例え76年周期のハレー彗星でも定期的な出現な訳で、
前回の出現がいつであるかは何の意見にもなってない訳だが。

199 ：Name_Not_Found：04/11/30 20:56:02 ID:???

というか前スレは２年前じゃないし

200 ：Name_Not_Found：04/11/30 21:45:16 ID:???

むしろ不定期のような

201 ：BlackLightOfStar ◆ifsBJ/KedU ：04/11/30 21:55:57 ID:V0oFycd3

Re:>194 で、お前はh1を強調のために使おうとする人とどこが違うのかな？

202 ：Name_Not_Found：04/11/30 22:03:58 ID:???

というより常時居るような

203 ：Name_Not_Found：04/11/30 22:16:20 ID:???

そうか？

204 ：Name_Not_Found：04/11/30 22:17:26 ID:???

>>200
それは正解だな

205 ：Name_Not_Found：04/12/01 11:11:34 ID:R2N4nRck

htmlでホムペ作成しているのですが
カウンタの取り付け方がわからないので
誰か教えてください

206 ：Name_Not_Found：04/12/01 11:23:39 ID:???

>>205
誤爆？

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

207 ：Name_Not_Found：04/12/01 15:58:16 ID:???

XHTML 1.1でウェブサ作成しているのですが
人の殺し方がわからないので
誰か教えてください

208 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/01 16:15:39 ID:Wmt0qPiQ

Re:>205 Strict HTMLだけではどうにもならない。CGIを通せばできる。
Re:>207 Strict HTMLだけではどうにもならない。

209 ：182：04/12/01 18:14:44 ID:???

ありがとうございます。
>>183
キムチマザコンエロティカンはぬっぽろんでろ。
どさくさにまぎれて質問してんな。
>>184 >>188
tableかこの部分だけをdlで囲むんですか。tableはスタイルを付ける時に
ちょっと難有りみたい感じなのでdlを選ぶかな？
結局結論としては>>195のようになるのかな？
厳密に当てはめようとするとやはりどこかにボロが出そうなので、
とりあえず参考程度にしておいて微妙に妥協する事も考えてみます。

210 ：Name_Not_Found：04/12/01 20:36:02 ID:???

>>207
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<title>自殺支援サイト</title>
</head>
<body>
<h1>自殺支援サイト</h1>
<h2>自殺の動機</h2>
<h2>自殺の方法</h2>
</body>
</html>

211 ：Name_Not_Found：04/12/01 21:16:04 ID:???

>>210
それはUTF-8で全世界向けに自殺方法を教えろというわけですね？

212 ：Name_Not_Found：04/12/01 21:21:07 ID:???

utf8でも日本語という特殊な言語を読める人にしか伝わらないと思った。

213 ：Name_Not_Found：04/12/01 21:29:49 ID:???

NHKでイタリアンとコーリアとヂューィッシュを勉強しまする！！

214 ：Name_Not_Found：04/12/01 23:36:14 ID:???

>>209
<table summary="掲示板">
<tr><th>番号<th>名前<th>日時<th>ID
<tr><td>1<td>......
....</table>

ていうのがこのスレとしては一番のやり方。

215 ：Name_Not_Found：04/12/02 00:43:28 ID:???

<ol>
<li>
<h3>Strict-HTML スレッド25</h3>
<p>うんこなスレ</p>
<p>http://pc5.2ch.net/test/read.cgi/hp/1101043958/ </p>
</li>
<li>
<h3>xrea.com part８０</h3>
<p>ちんこなスレ</p>
<p>http://pc5.2ch.net/test/read.cgi/hosting/1101212011/ </p>
</li>
<li>
<h3>JaneStyle Part32</h3>
<p>あああああ</p>
<p>http://jane.s28.xrea.com/test/read.cgi/bbs/1101315920/ </p>
</li>
</ol>

これって駄目ですか?

216 ：Name_Not_Found：04/12/02 00:55:14 ID:???

>>209
> tableかこの部分だけをdlで囲むんですか。tableはスタイルを付ける時に
> ちょっと難有りみたい感じなのでdlを選ぶかな？
結局結論としてはstrict的な発想じゃない人物であるということだね。

217 ：Name_Not_Found：04/12/02 00:59:36 ID:???

>>215
ulじゃなくてolなのは意味があるの?
多分こっちの方が良いかと。

<dl>
<dt>Strict-HTML スレッド25</dt>
<dd>うんこなスレ</dd>
<dd>http://pc5.2ch.net/test/read.cgi/hp/1101043958/</dd>
...
</dl>

218 ：Name_Not_Found：04/12/02 01:00:44 ID:???

あと、別に215のでも悪くはないと思う。

219 ：Name_Not_Found：04/12/02 01:03:06 ID:???

>>215
hn要素をリストや表の中に入れるのは完全に非strict。
リストの中に入れたいならhnを使わずにdlのdtで、表の中に入れたいなら
根本からしてstrictでない。

>>217も間違い。

<dl>
<dt>Strict-HTML スレッド25</dt>
<dd>うんこなスレhttp://pc5.2ch.net/test/read.cgi/hp/1101043958/</dd>
...
</dl>

とするべき。

220 ：Name_Not_Found：04/12/02 01:06:26 ID:???

>>216
おまいさんはstrictを何か勘違いしてないか？

221 ：Name_Not_Found：04/12/02 01:13:00 ID:???

>>219
hnをリストや表の中に入れてはいけないというのは同意はできないが理解はできる。
しかしなぜ217のdlがだめなんだ?

あと、そもそも215は生のURIに意味がある文脈なんだろうか?
そうでなければ
<dl>
<dt><a href="http://...">Strict-HTMLスレッド25</a></dt>
<dd>うんこなスレ</dd>
...
</dl>
文脈によっては
<a href="http://..." title="うんこなスレ"/>Strict-HTML スレッド25</a>
となりそう。

222 ：Name_Not_Found：04/12/02 01:14:42 ID:???

>>220
216じゃないが「tableはスタイルを付ける時に」というのがstrictではないということでは。

223 ：Name_Not_Found：04/12/02 01:14:45 ID:???

>>220
おまいさんは>>216の意図を何か勘違いしてないか？

224 ：Name_Not_Found：04/12/02 01:23:42 ID:???

意図がわからないので説明していただけませんか。

225 ：Name_Not_Found：04/12/02 01:42:47 ID:???

>>224
「スタイルを付ける時にちょっと難有りみたい感じ」は厳密型を使う人の発想じゃない、って意味かと。

226 ：Name_Not_Found：04/12/02 01:46:27 ID:???

>>209
難があろうと無かろうと、その要素が必要ならばその要素を使う以外の
選択肢は無かろう。まずスタイルありきじゃない。まず論理構造があって
その次にスタイルだ。

227 ：Name_Not_Found：04/12/02 01:59:07 ID:???

>220　>224は納得してくれたのかな

228 ：219：04/12/02 03:25:10 ID:???

>>221
きっとこういうhnであると思う。
<hn>面白スレの紹介しちゃうぞバカヤロー</hn>
それで↓の何が悪いのか。

<dl>
<dt>スレタイ</dt>
<dd class="comment">それに対するコメント</dd>
<dd class="link">http:/...</dd>
...

それは定義リストのddはdtをヘッダとして持っている同列のリストなので
感覚的には
<hn>スレタイ</hn>
<ul>
<li>コメント
<li>URL

と同じようなもの。どうみてもコメントとURLは同列のリストではないでしょ？
<dl>はもともと辞書などを想定しているよね。辞書といえば、意味と使い方の例なんだけど

<dl>
<dt>アフォ
<dd>２ちゃんねるでのアホの意
<dd>アフォだなこいつｗｗｗ
...

↑これは駄目なのはわかるかしら？意味と例は同列のリストではないので同じddとすると
セマンティックではないのだ。

という多少無理っぽい私の意見をば披露させてもらいました。
気を悪くされないよう頼みます。

229 ：Name_Not_Found：04/12/02 14:11:42 ID:???

>>219
>hn要素をリストや表の中に入れるのは完全に非strict。

完全にと言えるほど非strictなんだろうか。そもそもHTML3.2までは
リスト内にhnを書けなかったところを、HTML4でわざわざ書けるように
したわけで、その目的は非strict？

230 ：182：04/12/02 17:28:07 ID:???

いろいろありがとうございます。
えーと、少々省略して書きますが、
<dl><dt>hoge1<dd>hogehoge1<dt>hoge2<dd>hogehoge2</dl>
と
<table><tbody>
<tr><th>hoge1</th><td>hogehoge1</td></tr>
<tr><th>hoge2</th><td>hogehoge2</td></tr>
</tbody></table>
というのは、意味的にほとんど等価という事でしょうか？

231 ：Name_Not_Found：04/12/02 18:25:21 ID:???

私見ではtableの方がより縦の繋がりに意味を見出しやすい気がするが、
ほぼ等価と思って良いのではないかと思われる。

著者が「これはリストだ」と思うか「これは表だ」と思うか、多分そう言う違い。

232 ：Name_Not_Found：04/12/02 18:37:55 ID:???

そのtableのヘッダが
<thead><tr><th>定義語</th><th>説明</th></tr></thead>
等であれば、まあ等価かな。

233 ：Name_Not_Found：04/12/02 21:59:46 ID:???

定義リストは
＞<thead><tr><th>定義語</th><th>説明</th></tr></thead>
に近い暗黙のヘッダを持ってるからなぁ。

まあセマンティックウェブを考えると実は定義リストはイマイチなんだよな。
定義リストの定義自体があいまいだからコンピュータもdlの暗黙のヘッダを決めかねるんだよな。

本当に定義リストなのかってことだな。
定義してこそのものだが、本当に定義目的で使う機会は少ない。

まあ彼らに文句を言ったところでどうしようもないけどね。

234 ：Name_Not_Found：04/12/02 22:09:33 ID:???

考えてみるとdlとtableが存在するのって視覚的な理由から棲み分けが為された感もあるよな。
必ずしも包含関係な訳じゃないから言い切るのは難しいけどね。

235 ：Name_Not_Found：04/12/02 22:36:33 ID:???

tableはthead次第で意味変わるよね。

236 ：Name_Not_Found：04/12/02 22:38:59 ID:???

>>234
tableはある種の複合リスト（二重リスト）と書き換えできなくもないからな。
その意味ではdlと被る。

237 ：Name_Not_Found：04/12/02 22:41:48 ID:???

>>233
>本当に定義リストなのかってことだな。
>定義してこそのものだが、本当に定義目的で使う機会は少ない。
そもそも仕様の例示が、定義以外で使えると明言しちゃってるからな。

仮に「単なる見出し付きリストとしては使うな」と明言されていれば、
我々も「仕様違反だ」と切って捨てられる訳だが。

238 ：Name_Not_Found：04/12/02 22:43:46 ID:???

dlについては定義にしか使うな、という声をたまに聞くがちょっと勘違いしているように思う。
むしろ「定義リスト」という名前が歴史的経緯によってつけられていると考えた方がよいのではないか。

239 ：Name_Not_Found：04/12/02 22:48:10 ID:???

> dlについては定義にしか使うな、という声をたまに聞くがちょっと勘違いしているように思う。
そりゃそうだ。仕様書にはそう書いていないのだから。

240 ：Name_Not_Found：04/12/02 22:55:46 ID:???

> 仮に「単なる見出し付きリストとしては使うな」と明言されていれば、
> 我々も「仕様違反だ」と切って捨てられる訳だが。
イレギュラーに出現するhnについては
仕様は単に「よくないと思う人もいる」という程度に言及してるだけなんだが
dlに比べるとはるかに手厳しく切って捨ててる気がするな。

> 「定義リスト」という名前
まあ実際のところ「用語集っぽく整形されるリスト」という命名なんだろうな。

241 ：Name_Not_Found：04/12/03 07:05:13 ID:???

>>236
リストだって2面で縛ってるよ。
リスト自体のヘッダがあるからね。特にdlは2次元だといえる。
olは順列があるので2次元。
唯一ulだけが1次元かもね。

テーブルは2次元以上などを構造的にわかりやすく表現するためにあるんだろうな。
dlでもできるが汚くてわかりづらい。

242 ：Name_Not_Found：04/12/03 07:55:52 ID:???

>>238-239
仕様に書いてないといってるが、わかってるだろうけど使われてる言葉も仕様のうちにはいるんだよな。
歴史的経緯とか言ってるがdlをいつまでも定義リストという名前にしておく必要性はないだろ。

確かに定義リストといってもHTML4.01などでの定義リストの「定義」という部分の意味は
日本語の「定義」という言葉とはずれている。

論理的でないネーミングでありながら論理的な仕様を求めてるのはw3cに非があるだろうな。
あきらかに混乱のもとだ。まあ他にもおかしな名前は結構あるけどね。

とりあえず彼らに論理的な仕様書と要素名の作成からやっていってもらいたいと、
何もしない俺が言ってみるテスト

243 ：Name_Not_Found：04/12/03 08:17:41 ID:???

> 論理的でないネーミングでありながら論理的な仕様を求めてるのはw3cに非があるだろうな。
HTML4当時は実装先行が激しく仕様は後追いだったからね。

そういやメニューリストやディレクトリリストなんてのもあったね。
これらがdeprecatedになって定義リストが生き残ったのって
実装例の有無の差でしかないと思う。

244 ：Name_Not_Found：04/12/03 12:36:23 ID:???

>>241
リスト自体のヘッダ？

245 ：Name_Not_Found：04/12/03 12:37:33 ID:???

>>242
＞dlをいつまでも定義リストという名前にしておく必要性はないだろ
後方互換性。

246 ：Name_Not_Found：04/12/03 12:38:45 ID:???

ついこの間もどこかで同じ話題が出ていたような。ここか？

247 ：Name_Not_Found：04/12/03 12:39:27 ID:???

>>245
後方互換ってなんか意味違わなくない？
呼び名が変わっても、使い道は現行どおりだし、
要素の記述方が変わるわけでもないし、実装も変わらない。

今言ってるのは「呼び方」でしょ。

248 ：Name_Not_Found：04/12/03 12:41:27 ID:???

だからそういういのを歴史的経緯と呼ぶんだろ？

249 ：Name_Not_Found：04/12/03 12:49:34 ID:???

>>248
だからなんだ？

250 ：Name_Not_Found：04/12/03 12:54:14 ID:???

>>247
既存の文書に手を入れる手間だとか、
新しいことを取り入れる隙間のない連中のための「後方互換」でもある。

251 ：Name_Not_Found：04/12/03 14:03:42 ID:???

>>250
それは「定義リスト」という言葉をサイトで使っている人のため、って意味かな？

252 ：Name_Not_Found：04/12/03 14:06:12 ID:???

dlって呼称を変えるわけにはいかんってことだろ。
それとも略字がdlになるような用語を捻り出せってことか？

253 ：Name_Not_Found：04/12/03 14:09:30 ID:???

ガンダムみたいだな

254 ：ｶﾞﾉﾀ：04/12/03 14:43:14 ID:???

General-purpose Utility Non Discontinuity Augmentation Maneuvering weapon system
全領域汎用連続強化型機動兵器機構
だった、昔は。
Non Discontinuity で「連続」とする当たりに結構無理が見受けられる。

255 ：Name_Not_Found：04/12/03 15:27:15 ID:???

>>252
divだって意味は汎用言語/スタイルコンテナってなってるし、
対記リスト　dl　とやったって問題ないんじゃないか、と。

えーと、言いたいことは、意味の略記じゃなくてもいいだろ、って。

256 ：Name_Not_Found：04/12/03 15:46:45 ID:???

余計な知識が身に付くのが2chの良いところ。

257 ：Name_Not_Found：04/12/03 15:51:10 ID:???

完全にstrict的な思考から離れてしまうが、

dl要素が良く使われる傾向、ってのはさ、
hn+pとかの隣接セレクタが実用に耐えうる状況じゃないから、
結果、似たような意味合いで使え、尚且つスタイルを指定しやすいdlを使っちゃう、という気もする。
hn+pでやろうとすると、divの数がそれだけ増えて、生理的に嫌だわ。

まあ、完全にstrict的な思考じゃないけど、人間だし。

258 ：Name_Not_Found：04/12/03 16:58:17 ID:???

結構前だけど、
hnから次のhnまでを一つのブロックとすることが将来的にできるようになるからdivはいらない、
って意見があったけど、よく考えたら破綻することがわかった。

259 ：Name_Not_Found：04/12/03 17:02:30 ID:???

>>258
残念ながらその論はISO-HTMLを検討すればすぐに導けるお話だ。

260 ：258：04/12/03 17:16:25 ID:???

すんません、セクションを包含するセクション、というモノはどのように…

261 ：Name_Not_Found：04/12/03 18:14:38 ID:???

>>245
なに言ってんだお前は。
本当の意味での後方互換を考えろよ。
仕様は書き換えていくのに要素の名前を変えないことのどこが後方互換だよ？
使い方についてはかわっていくのに、名前を変えないことのどこが後方互換だよ？

お前はアホか？

262 ：Name_Not_Found：04/12/03 18:17:42 ID:???

>>258-260
何が問題なん？hn～hn-1以上までをブロックとするって話でしょ。
一体どこで破綻するの？

まあしかしhnって実際いらないよね。divの属性にheaderが追加されればいいのにね。

263 ：Name_Not_Found：04/12/03 18:24:17 ID:???

>>261
お前みたいな考え方を後方互換性のない仕様変更という。

264 ：259：04/12/03 18:29:26 ID:???

>>262
<div class="s1">
<h1>～</h1>
<p>～</p>
<div class="s2">
<h2>～</h2>
<p>～</p>
</div>
<p>※</p>
</div>

※に補足みたいな文章を書こうとしたとする。
divで区切っていれば可能だが、ISO-HTMLなど、hnを自動的にブロックとみなす考え方では、
※はs2に含まれていると解釈されてしまう。そのため、改めて見出しを明示する必要が生じる。
要は、divを使わないなら、次の見出しの開始と同時にセクションが閉じている必要がある。

265 ：262：04/12/03 18:35:55 ID:???

>>264
divで区切ってたら
＞<p>※</p>
はh2とは無関係であるという論理的な証明であるという理屈は仕様書のどのへんを
読んで考えたの？

仮にそれが正しいとしてHTML4.01ではhnの省略はできるが、そのhnからブロックを推察するっていう
仕様変更をした場合は同時にhnの省略を禁止すればいいだけでしょ？

まあ人間的な利便性の面では君の例コードのようなことが可能だと楽だけど、
セマンティックとしてはあんまりよくないよね。

最後の※の部分は間違いなく結論や注記なんだからそれをそのまま見出しにしたほうが親切。
見た目はCSSで消せばいいし。

266 ：Name_Not_Found：04/12/03 18:39:01 ID:???

>>264
その文章（マークアップの部分）の組み立て自体論理的でないんだが・・・・・・

267 ：258：04/12/03 18:45:22 ID:???

>最後の※の部分は間違いなく結論や注記なんだから
そうとも限らないよ。
<div id="section1">
<h1>2ch.netについての考察</h1>
<p>2ch.netというサイトはひろゆきが云々かんぬん…</p>
    <div class="hoge">
    <h2>閑話休題</h2>
    <p>こないだ吉野家行ったんです、吉野家。そしたら…</p>
    </div>
<p>話を元に戻す。そもそも掲示板とは…</p>
</div>
みたいに全くとは行かなくとも、話題の違う節が文書のなかに差し込まれることは良くある、でしょう？

268 ：258：04/12/03 18:46:25 ID:???

あ、この考え方自体が間違っていたら、ごめんなさい。
できれば、正しい方向に導いて、エロイひと。

269 ：Name_Not_Found：04/12/03 19:01:51 ID:???

実際そこまでやるかどうかはべつとして

<h2>序論</h2>
<p>2ch.netという～</p>

<h2>余談</h2>
<p>…</p>

<h2>閑話休題</h2>
<p>話を元に～</p>

実際には自分はそこまで書かないけど難しくも何ともない
＃閑話休題の使い方が間違ってると思う

270 ：Name_Not_Found：04/12/03 19:12:31 ID:???

>最後の※の部分は間違いなく結論や注記なんだから
こういう固定観念が不便な文書型を作ってしまう元凶なんだろうと思う。

>見た目はCSSで消せばいいし。
構造上そこに見出しが存在しないと判断している場合はやっぱり想定外なのね。

271 ：258：04/12/03 19:26:20 ID:???

>>296
そう考えると、すべての段落に見出しが必要になりませんかね？

> ＃閑話休題の使い方が間違ってる
調べました。おしっこ漏れそうになるほどお恥ずかしい。

272 ：259：04/12/03 19:31:06 ID:???

>>265
>divで区切ってたら
>＞<p>※</p>
>はh2とは無関係であるという論理的な証明であるという理屈は仕様書のどのへんを
>読んで考えたの？

もう少し文章は考えて書けよ。
それはともかくdivがあれば機械的に解釈すると※がs1に属することは自明だ。

それと仕様によっては書けない文書構造が生じる場合があるが、
仕様によって記述できないものをすべて非論理的であると断じるのは早計だぞ。
別に俺は仕様を批判しているわけでなく、こういう仕様だとこうなるね、と言っているだけ。

273 ：259：04/12/03 19:33:44 ID:???

>>269
もちろんそれでもできる。ISO-HTML使いならそうするだろう。
しかしdivでセクションを区切る考え方なら>264でもできる。
それだけの話。

274 ：258：04/12/03 19:36:21 ID:???

>>272
> それと仕様によっては書けない文書構造が生じる場合がある

心、洗われました。

275 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/03 20:01:47 ID:vmXu2lrl

定義リストも、メニューリスト、ディレクトリリストと同様に過去のものにしてしまえばいいのだ。
リストはolとulだけでいいはずだ。

276 ：Name_Not_Found：04/12/03 20:07:21 ID:???

>>275
ネタにマジレスすると ol と ul を統合しろって話は何度か出た話題だな。

277 ： 269：04/12/03 20:21:40 ID:???

>273
そうそれだけの話
そして（示唆しているが）自分もそう（>264のように）書く

278 ：Name_Not_Found：04/12/04 00:58:54 ID:???

>>273
じゃあ、以下のh2「ふがふが」はどこからどこまでの範囲の見出しなんだ？

<h1>ほげほげ</h1>
<div>
<div>
<p>なんたら…
<h2>ふがふが</h2>
<p>かんたら…
</div>
<p>うんぬん…
</div>
<h2>ほげたら</h2>

div要素が見出しの範囲を表すと見なすと、範囲が複数に解釈できるように
なってしまうんだが…。hnからhnなら範囲は一意で決まる。

279 ：Name_Not_Found：04/12/04 01:06:31 ID:???

待てよ。
なんかdivで「同じグループですよ」が指定できる、みたいな話になってるが、
一括でスタイルを指定or一括で言語を指定する範囲を決めるコンテナでしかないだろ。

280 ：Name_Not_Found：04/12/04 01:23:36 ID:???

>>278
そのセクショニングには一貫性がないようにも思えるが。

>>279
超既出だがそれは誤読。

281 ：Name_Not_Found：04/12/04 01:26:52 ID:???

HTML4.01仕様書より
>7.5.4 要素のグループ化: DIV要素とSPAN要素

282 ：Name_Not_Found：04/12/04 01:33:03 ID:???

>>280
> 超既出だがそれは誤読。
>>279はちょっと端折りすぎた。
グループ化できない、と言ってるんではなくて、
divで括られてる部分がグループであるとは限らない、言いたいわけだ。

端折ってる、というよりも言葉の選び方がおかしいな。
なんせ「グループ化」だけの要素じゃないだろ、ってことで。

283 ：Name_Not_Found：04/12/04 01:37:43 ID:???

一括でスタイルを指定していようが一括で言語を指定していようが
要素をグループ化しているからできることだと思うが。

284 ：Name_Not_Found：04/12/04 01:41:49 ID:???

>>278
適切なdivの用い方かどうかはともかく、うんぬんにはかからないだろうね。
divが見出しを併合して閉じる以上、見出しの範囲は一意だよ。

285 ：Name_Not_Found：04/12/04 01:44:49 ID:???

>>283
うん。完全に俺の言葉足らずだ。
h2の範囲を構造付けるためにh2とそれ以下のpなどをdivで括る事もできる、
が、divで括っているからh2以下とそれ以外をわけている、と判断するのは早計だ、と。
例えば、h2のコンテントと、最初の二つの段落だけが英語なのかもしれない。
それ以降は違う言語なのかもしれない。しかし、違う言語はh2以下ではない、というわけではない、と。

286 ：Name_Not_Found：04/12/04 01:51:12 ID:???

>>285
いやそれは違うと思うよ。

ここで、hnが暗黙のセクションsを付属して、実は
<s1>
<h1>見出し</h1>
<p>～</p>
</s1>
が隠れているとしよう。

君の言うように、divの閉じタグが見出しの支配範囲の中におけるものとすると
<div>
<s1>
<h1>見出し</h1>
<p>～</p>
</div>
<p>※</p>
</s1>
のようにタグの入れ子関係の原則に反する部分※が生じることになる。
（ちなみにdivとh1の間に他の要素を入れることもありうるのでdivがs1とh1の間に割り込むことはない。）

287 ：Name_Not_Found：04/12/04 01:52:51 ID:???

>>286
<s1>
<div>
<h1>見出し</h1>
<p>～</p>
</div>
<p>※</p>
</s1>
こうだろ。

288 ：Name_Not_Found：04/12/04 01:56:02 ID:???

>>287
最後の一行読んだ？

289 ：Name_Not_Found：04/12/04 02:03:03 ID:???

>>286
> （ちなみにdivとh1の間に他の要素を入れることもありうるのでdivがs1とh1の間に割り込むことはない。）
ああ、なるほど。見落としてた。
まあ、そもそもs1っつー要素を仮定してるからそうなってるだけだ、って話だけどな。
閉じdivがあれば、そこでh1以下じゃなくなる、という理論はわかるが屁理屈だろ。

290 ：Name_Not_Found：04/12/04 02:05:37 ID:???

ああ、そっか。
例えばさ、

div
h1
p
p
p
/div
p

だったら、最後のp以外がh1以下、ってこと？

291 ：Name_Not_Found：04/12/04 02:07:49 ID:???

>>290
そうなるね。

292 ：285=287=289=290：04/12/04 02:08:50 ID:???

連投すまん。
煮詰めてから書けばよかった。
>>290で言いたかったのは、
> （ちなみにdivとh1の間に他の要素を入れることもありうるのでdivがs1とh1の間に割り込むことはない。）
div
ul
h3
p
p
p
/div
p

ulはh3以下なのか？　ってこと。

293 ：Name_Not_Found：04/12/04 02:10:30 ID:???

>>292
違うでしょう。

294 ：285=287=289=290：04/12/04 02:13:27 ID:???

>>293
じゃあ、「下位である事を示しているとは限らない」ってなるんじゃないの？

295 ：Name_Not_Found：04/12/04 02:17:24 ID:???

>>294
例えばbody以下の最初の要素がh1だとは限らないわけで。

そう考えると、すべての要素が
・見出しをもたない
・ある見出し（直前の閉じていないhn）の"支配下"にある
のいずれかであり、しかもそれを一意に決定できるってこと、

>>292で言えば、ulは大外のdivを含む見出しをもつ要素ということになる。
包含関係的に矛盾はないでしょ？

296 ：285=287=289=290：04/12/04 02:20:28 ID:???

>>295
最後のpがh3以下ではない、とする理屈が聞きたい。
直接インラインを書いたり出来るdivみたいなイレギュラーなもので、入れ子ミスを例にされてもな。

297 ：Name_Not_Found：04/12/04 02:22:37 ID:???

>>296
俺の理屈は>>286。仕様に沿った説明だと思うが？
どうしても納得できないなら最後のpがh3以下になるという君の理屈を聞かせてくれ。

298 ：285=287=289=290：04/12/04 02:28:30 ID:???

>>297
h3以下になる、と言い切ってるわけじゃないんだよ。
さっきも出てたみたいに、記述されていない見出しが存在するケースもありうるし。

ただ、div閉じたからhnの関係もそこで断ち切られる、ってのが腑に落ちん。
div閉じて終わるのは、divのグループであって、hnの内包関係じゃないだろう、と。

299 ：286とか297とか：04/12/04 02:31:55 ID:???

>>298
だから、>>286で言ったようにそうなると考えるしかないわけだけど…。
「記述されていない見出し」が>292のulのことなら、
これも>295で言ったけど、別にdivを使わなくても生じるわけで。

どうしてもそれが嫌ならISO-HTMLとか使えばいいだけの話なんだから。
（ISO-HTMLではdivでhnをくくることが禁止されている。）

300 ：Name_Not_Found：04/12/04 02:35:39 ID:???

>>284
じゃあ、

<div class="pankuzu">
<p>トップ＆gt; うんたら＆gt;</p>
<h1>ほげたらについて</h1>
</div>
<p>ほげたらとは、…

これだと h1 の指す範囲はなくなるのか？

301 ：285=287=289=290：04/12/04 02:35:57 ID:???

>>299
いや、そうじゃない。
最後のpが別の見出し以下の可能性はあると思ってる、と言った。
絶対にh3以下だと言ってるわけじゃない。

しかし、divが終わったから、hnの以下じゃなくなる、とは限らないだろう、と。
s1要素によって、否定されるのはわかるが、s1要素の仕組み自体仮定だし。

<div>
<p>あ</p>
<h3><s1>あああ</s1></h3>
<p><s1>あ</s1></p>
<p><s1>あ</s1></p>
</div>
<p><s1>あ</s1></p>

これなら問題ないし。

302 ：285=287=289=290：04/12/04 02:37:53 ID:???

>>300
それは例が悪くないか？

<div lang="en">
<p>abc...</p>
<h1>abc...</h1>
</div>
<p>ほげたらとは、…

303 ：Name_Not_Found：04/12/04 02:37:54 ID:???

>>300
そうだろ。それが何か？
普通にbodyの最後にhnを書いても見出しが指す範囲はなくなる。
それと同じ。

>>301
何の説明にもなっていないと思うけど？

304 ：285=287=289=290：04/12/04 02:38:25 ID:???

>>303
いや。s1の入れ子関係だけがそっちの言い分だから。

305 ：285=287=289=290：04/12/04 02:39:06 ID:???

>>303
<div lang="en">
<p>abc...</p>
<h1>abc...</h1>
</div>
<p>ほげたらとは、…

でも、divによってh1の範囲は終わらされますか？

306 ：Name_Not_Found：04/12/04 02:40:28 ID:???

>>304
だから反論したいなら論理的に頼む。
「それはお前の言い分だから」「屁理屈」とか言われても…。

>>305
そうだろ。>300と何の差があるの？

307 ：285=287=289=290：04/12/04 02:40:33 ID:???

ごめん。専ブラで自分で指定したNGにひっかかって自分の書き込みが見えてなかって、同じ事書いてしまった。

308 ：285=287=289=290：04/12/04 02:41:35 ID:???

>>306
論理的に言ってるじゃん。入れ子問題解消したらその言い分は通らないでしょ、って。

>>305のdivは
言語指定の範囲でしかないと思うんだけど。

309 ：Name_Not_Found：04/12/04 02:46:49 ID:???

>>308
>301は入れ子問題を解消したつもりだったの？
だけど「h3の支配下」が明示できなくなったら意味ないだろ。
「hnの支配下にある」っのはブロックレベルのグルーピングが存在するってことなんだから。
著者の意図を自動的に組んで「支配下」を解釈しなきゃならんのなら仕様の意味ないし。

310 ：Name_Not_Found：04/12/04 02:49:27 ID:???

とりあえず寝ます。

311 ：285=287=289=290：04/12/04 02:49:40 ID:???

>>309
<div>
<p>あ</p>
<h3 id="s1">あああ</h3>
<p><label for="s1">あ</label></p>
<p><label for="s1">あ</label></p>
</div>
<p><label for="s1">あ</label></p>

こういうことが言いたい、と汲んでくれると嬉しい。非常に嬉しい。

312 ：Name_Not_Found：04/12/04 02:53:15 ID:???

＞「hnの支配下にある」っのはブロックレベルのグルーピングが存在するってことなんだから。
そんな勝手な解釈されても。
dfn要素とかブロックレベルでグルーピングしてないぞ。
仕様書にないことで暴れるなよ。

313 ：262：04/12/04 04:22:39 ID:???

なんか凄い勢いだね。
元々はhn～hnをセクションと機会が理解するのは可能かみたいな話だったよね。
で、今はdivについてかな？

h1
p
div
h2
p
/div
h3
p

↑こういう使い方も仕様書を見る限りでは正しいんだよね。
h2の部分だけ一括でグルーピングしてるのね。

ここで問題。h3はh2の下位であるといえるかどうか。
俺としては言っても言わなくてもいいと思うんだよね。

何故か。divをセクションとして使うのもそうじゃないものとして使うのも
制作者の勝手ですから。IDの値と同じくらい他人に対しては意味を持てないものですよ。

divは汎用要素です。pやhnと同列にしないで下さい。divはpほど明確な構造をあらわせません。
divでグルーピングしてるからといって中身の価値は変わるとは限りません。
div-h2-p-/divとh2-pの存在位置が等価である場合も当然あります。

分割

314 ：262：04/12/04 04:29:34 ID:???

divは汎用要素なので入れ子したところで、「何故」入れ子してるのかを機械に
理解させることはできません。

グルーピングという意味においては期待にこたえることができますが、
階層構造などはあらわせません。
classと同じくあくまでもグルーピングです。

<h2 class="a">
<p class="a">
これと
<div class="a">
<h2>
<p>
</div>
これは、等価であると機械が判断してもおかしくはないでしょう。

現状ではdivを使ったところで機械に確実にグループであること以外は理解させられません。

315 ：Name_Not_Found：04/12/04 04:34:48 ID:???

つまり、人間が見たときの便宜上の理解にしか過ぎないと？

316 ：Name_Not_Found：04/12/04 05:27:46 ID:???

>>315
だね。

317 ：Name_Not_Found：04/12/04 05:29:35 ID:???

XHTML2.0のsection要素に期待だな。
おれはドキュメントフラグメントの観点から
div class="section"を今から使ってる。
ID振るのに

<h2 id="hoge">見だし</h2>
<p>内容</p>

よりも

<div id="hoge">
　　<h2>見だし</h2>
　　<p>内容</p>
<./div>

のほうがいい。

318 ：Name_Not_Found：04/12/04 05:31:04 ID:???

>>317
hn間の考え方は好かんか。

319 ：262：04/12/04 07:07:58 ID:???

>>317
section要素ができるにしてもdivにしても何か2度手間な気がするんだよね。
普通はさ、っていうか人間はさ、文章を読んだ時に見出しの使い方からセクションなんかを
推測するよね。
機械に対しても見出しの使い方でセクションを判断させたほうが
いいような気もするけど・・・そういうのは実装してくれなさそうだから
無意味って結論がでそうだなぁorz
セレクタも変えないといけないしね・・・やっぱsection要素に期待だなこりゃ。

320 ：317：04/12/04 07:41:14 ID:???

>>319
XHTML応用アプリなら「自動的セクションの読み取り」に対応できるかも知れないけど、
**XML**応用アプリにそれを期待するのは間違ってる。
スキーマの範囲も超えてるから、かなり無理が有ると思うよ。
Xpathで工夫すれば何とかなるかも知れないけど、
dd要素みたいに入れ子関係でグループを定義するのがXMLとして自然じゃないかな。
文脈的な曖昧さも拭えて一石二鳥だと思うよ。

321 ：Name_Not_Found：04/12/04 10:51:37 ID:???

>>311-314
それ言うんだったら「見出しは続く兄弟要素を暗黙的にグルーピングする」も
仕様書にはまったく書いていないことであって人間の恣意的解釈に過ぎないとも主張できるぞ。
（むしろ仕様書の例では現行ではdivを使うことによってのみ章節を明示することが可能、とも読める。）

322 ：Name_Not_Found：04/12/04 11:11:27 ID:???

つまり、
・hn～hnをセクションと機会が理解するのは可能か
・divによるグルーピングによってhn～hnのセクションは影響をうける
は表裏一体の問題であるってこと。

323 ：Name_Not_Found：04/12/04 13:07:42 ID:???

>>317
ttp://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-structural.html#sec_8.5.
8.5. The heading elements のところに出てるexampleを見て思うのは
・本文が見出しに先行してもいいらしい
・１セクション内に見出しが複数出現してもいいらしい
…ということ。漏れはsection/h要素も思ったほど期待できないかも…と思う。
sectionって漏れ達が思ってるような限定された概念として
作ろうとしている要素ではないのかもしれない。

324 ：Name_Not_Found：04/12/04 13:53:09 ID:???

>>323
そうなんだよね、結構微妙なところが有るのは事実だと思う。
hnでのマークアップも残されるみたいだし。

325 ：Name_Not_Found：04/12/04 14:57:56 ID:???

>>322
機械が理解可能かどうかという、実装の問題ではなく、仕様がどうなって
いるかの問題だろ？

で、仕様書を見ると、見出しは「the topic of the section it introduces」を
記述すると書かれているので、見出しがセクションを introduce することは
仕様書に明示されている。つまり、見出しだけでセクションを表せる。

一方、div は「generic mechanism for adding structure」とあるので、
あくまで汎用。セクションを表す場合もあるだろうし、それ以外のものを
表す場合もあるということ。

つまり、仕様書からわかることは、
・hnだけでセクションを表すことが出来る。
・セクション終了をdivで書いてもいいが、divが書かれているからと
　いって必ずしもセクション終了であるとは言えない。
といったところか。

326 ：Name_Not_Found：04/12/04 15:07:29 ID:???

>>325
だからさ、セクションを人間が理解するってのと、機械が自動的に判別するってのは別の話なんだよ。

見出しについては、
＞A heading element briefly describes the topic of the section it introduces.
＞（試訳）見出し要素は、続くセクションの話題を簡略に記述するものである。
と書いてあるだけで、セクションの範囲の規定については一言も書いていない。

>>314の例で言えば、
<h1 class="s1">見出し1</h1>
<h2 class="s2">見出し2</h2>
<p class="s2">内容2</p>
<p class="s1">残念！実は見出し1に付属！</p>
とかもできる。

まあ機械が自動的に判別できないときには、たいてい人間も誤解するときがあると思うけど。

327 ：326：04/12/04 15:09:27 ID:???

それで仕様書は例として、divならクション範囲の明示に利用できますね、と述べている。

328 ：326：04/12/04 15:11:30 ID:???

×クション→○セクション

329 ：286：04/12/04 16:27:39 ID:???

えー。>286の繰り返しになるんだけど、
セクション要素を新設するとしてどういう風にすればよいのか考えてみて欲しい。
どう定義しようが、それを包含するdivがあれば、それが閉じるまでにセクションもまた閉じなければならないと気付くはず。

んでね、divの使い方に関する誤解があるんじゃないかと思う。
何度か指摘されているように、divは色々なグループを現すわけで常にセクションと解釈されるものではない。
しかし、hn（とそれに暗黙的に付随するセクション）を包含するdivについては、
それはhn（とセクション）をも包含する意味的に大きな集合を現していなければならない。（それがStrictでしょ？）
したがって、hnを包含するdivが閉じるまでに、セクションは終了していると解釈されるべきじゃないかってこと。

330 ：286：04/12/04 16:34:27 ID:???

>>313
そういうわけでそのh3はh2の下位にはないと考えられる。（hnの階層スキップが生じているようだね。）
>>314
いずれにせよ、もしhnを含むなら、hnやセクションより大きな塊を示しているべきだと思う。

>>325
・hnを包含するdivについては、それはセクションか、もしくはセクションより大きなまとまりなので、
　divが閉じるまでにセクションは終了しているべきである。

>>321-322 >>326
HTMLの見出しと本文の仕様は「フラット」になってるからね。そこが問題か。

331 ：286：04/12/04 16:36:58 ID:???

>>319
>286みたいな暗黙的セクション要素を挿入すれば機械的に解釈できると思うけどどう？
（snはsn,sn-1…を包含できないとすれば閉じタグ省略ルールが適用できるはず。）
というか俺はこれまで（ある意味勝手に）そう解釈していた。（実はdiv使わない派。）

332 ：Name_Not_Found：04/12/04 17:03:53 ID:???

>>326-328
仕様書に書かれてあること
・見出しはセクションを introduce する。
　（つまり、見出しでセクションを開始出来る）
・div要素は、idやclassと共に使うことで汎用の構造を表す。
・以下の例のようにdivを使うと、見出しが表すセクションを明示できる。
　（<div class="section"> などと書かれている例）

仕様書に書かれてないこと
・見出しが introduce するセクションが具体的にどこで終わるか。
・任意のdiv要素が見出しセクションの区切りを表すかどうか。

ということで、セクションの区切りをdiv要素で書くことは可能だが、
div要素があるからと言ってセクション区切りとは限らないのでは？
つまり、仕様書の例は class="section" だからセクションを表しただけと。

333 ：262：04/12/04 18:51:16 ID:???

>>321-332
勘違いされてるぽいけど、俺は現行のHTML4.01の仕様でhnを使ってセクションをあらわすのは
不完全・又は不可能だと思ってる。もちろん機械に伝えるという意味でね。
一応話を元に戻すと、話の始まりは以前にあったそのうちhnだけでセクションが
明示できるような仕様になればいいねっていう辺りで、現行の仕様についての
話ではないので、hn問題は現行の仕様で可否を話すのはちょっと違うかなと＾＾；

334 ：Name_Not_Found：04/12/04 19:08:17 ID:???

>>329
>しかし、hn（とそれに暗黙的に付随するセクション）を包含するdivについては、
>それはhn（とセクション）をも包含する意味的に大きな集合を現していなければならない。（それがStrictでしょ？）

それはstrictってもんではありません。あなたの独自解釈にしか過ぎません。
そこにはセマンティックのかけらもありません。divでセクションを分断してはいけないとは
書いてありませんし、divがセクションを分断できるとも書いてありません。

divはあいまいな要素です。
段落を伝えるにはpを使いましょう。divを使うのはやめてください。
見出しを伝えるにはhnを使いましょう。divを使うのはやめてください......divで作る見出しは制作者の自己満足でしか
ありません。機械はきっというでしょう・・・・・「ハァ！？」

divは色々な使い方ができます。しかしそれぞれの要素にclassを振る代わり以上のことを機械に
理解させることは不可能です。機械はどれがセクションdivかを天地がひっくり返っても
理解できません。

「divでセクションを示せるよ」といっている仕様書の例文は、「divでセクション「も」示せるよ」
なのですが、機械にとっては「そんなあいまいなこと言われても、今回のdivは一体なんなのよ」ってところでしょうね。

335 ：Name_Not_Found：04/12/04 19:20:30 ID:???

ところでdivはセクションに使える派に聞きたいんだが
<h1>
<div>
<p>
<h2>
<p>
<ol>
</div>

↑この場合にdiv内の1個目のpは1個目のhnより上位とされるの？
あと、そのpはどのセクションに属するの？
h1？それとも見えないh2？それともdivのセクションのみ？
そうなると最後のpはh1-div-h2の三重のセクションの中ってことかな？

しかしここまで細かく考える必要ってあるのかな？
セクションが明示できるとセマンティックウェブの発展につながるかな？
たいした効果はない気がするんだけど・・・

336 ：Name_Not_Found：04/12/04 21:18:22 ID:???

>>286
仕様書を見ると、「見出しとそれが従えるセクションをdivで結びつける」と
いう例が示されているわけで、ということは暗黙のセクションは、

<h2>見出し</h2>
<s2>
<p>ああ</p>
<p>ああ</p>
</s2>
<h2>次の見出し</h2>

このように見出しを含まないんじゃないのか？　そして、このh2と暗黙の
s2をdivで結びつけるのでは？　だとすると、見出しを含むdivを次の見出しの
前に閉じてしまうと、

<div>
<h2>見出し</h2>
<s2>
<p>ああ</p>
</div>
<p>ああ</p>
</s2>
<h2>次の見出し</h2>

このように入れ子にならないのでダメと解釈することも出来てしまうんだが。

337 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/04 21:51:56 ID:VeStXT7z

form要素にフォーム部品などを入れる場合はpよりもdivを使ったほうがいいのかな？

338 ：Name_Not_Found：04/12/04 22:00:04 ID:???

>>337
名無しになれや

339 ：286：04/12/04 22:05:19 ID:???

あきらめた。
SGMLを理解せずに仕様書だけ読んでいる人がいるみたいだけど、
そういう人がセマンティックを語っても無駄だと思う。

340 ：Name_Not_Found：04/12/04 22:10:25 ID:???

Strictにこだわること自体が無駄だと思うけどね

341 ：Name_Not_Found：04/12/04 22:25:39 ID:???

>>339
前から思っていたんだが、そのセマンティックって言葉を
馬鹿の一つ覚えみたいに使うの止めてくれない？
そもそもsemanticは形容詞であって名詞ではない。

342 ：Name_Not_Found：04/12/04 22:35:17 ID:???

あーあーあー、そんなとどめを刺すようなこと言ったら・・・

343 ：336：04/12/05 00:02:07 ID:???

>>339
SGMLを理解していないって俺のことか？

要するに、暗黙のセクション要素みたいなのを考えるとすると、それは
ISO-HTML の Pre-HTML の DIV1～DIV6 のようなものになるのではないか
ということ。ただしHTML4の場合は、H2と暗黙のDIV2をまとめてdivに
入れられる。

すると、見出しを含むdivは次の見出しの直前まで続かなきゃならないことに
なると。何かSGML的に間違っているか？

344 ：Name_Not_Found：04/12/05 00:13:20 ID:???

>>341-342

se・man・tic

━━ a. 意味論的な; 意味に関する.
semantic differential　【心】意味微分（法）, SD法.
semantic error　意味上の誤り.
se・man・ti・cist
　━━ n.
semantic net　【コンピュータ】意味ネット（ワーク）.
se・man・tics　━━ n. 意味論.

これって形容詞なのか？

345 ：Name_Not_Found：04/12/05 00:16:56 ID:???

>>344
ad・jec・tive

━━ n., a. 形容詞; 形容詞（的）の.
ad・jec・ti・val
　━━ a., n. 形容詞（的）の; 形容詞相当語句.
ad・jec・ti・val・ly　ad. 形容詞として, 形容詞的に.

noun

━━ n., a. 【文法】名詞（の）.

346 ：Name_Not_Found：04/12/05 00:23:38 ID:???

>>344
semantic netって訳語が名詞なだけであって普通に形容詞じゃん。

347 ：Name_Not_Found：04/12/05 00:30:19 ID:???

スレ違い。

348 ：Name_Not_Found：04/12/05 00:43:56 ID:???

>329
> どう定義しようが、それを包含するdivがあれば、それが閉じるまでにセクションもまた閉じなければならないと気付くはず。
それは、開始タグと終了タグでセクションを括る、って前提でしょ？
>>311の記述法ならその問題も解決するわけで。

勝手な要素を作って、「ほら、破綻するからね」って理論の方が破綻してる。

349 ：Name_Not_Found：04/12/05 01:03:04 ID:???

けいよう-し 3 【形容詞】

(1)品詞の一。用言に属し、活用があり、終止形語尾が、口語では「い」、
文語では「し」であるもの。事物の性質・状態または心情・感情などを表
す。「早い」「楽しい」「あまねし」「うるわし」の類。活用は、口語では
一種類であるが、文語にはク活用・シク活用の二種類がある。
(2)そのものの性質・状態・属性などを表す言葉。形容辞。

まあ落ち着いて読んでくれ。

350 ：Name_Not_Found：04/12/05 01:18:17 ID:???

今日は辞書房の日でございます。

351 ：Name_Not_Found：04/12/05 01:25:25 ID:???

ぼう【房】

ぼう(バウ)【房】
Ⅰ　
1　へや。つぼね。特に堂のかたわらの小部屋など。
2　＝ぼう（坊）Ⅰ4
3　＝ぼうこ（房戸）
4　法体（ほったい）の武士。武装した僧侶。
5　「にょうぼう（女房）」の略。
Ⅱ　二十八宿の一つ。東方に位するもの。さそり座の頭部にある星宿。房宿（ぼうしゅく）。いぼし。

352 ：Name_Not_Found：04/12/05 01:32:21 ID:???

>>344
se・man・tic /smantk/ adj.
[usually before noun]
^^^＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾
(linguistics) connected with the meaning of words and sentences:
semantic theory / analysis

353 ：Name_Not_Found：04/12/05 01:36:15 ID:???

セマンティックウェブを省略したんだと思ってやれ

354 ：Name_Not_Found：04/12/05 01:55:20 ID:???

ところで結論は？
divは結局セクションdivとして使ってもいいが、話題のセマンティックウェブには
何も影響を与えることができないってことでいいのかな？

355 ：Name_Not_Found：04/12/05 02:07:06 ID:???

>>354
☆そうだぴょんぴょん☆
☆XHTML1.1でも工夫すればセクションのようなものを抽出できるが
　　正確でもないし自己満足だぴょんぴょん☆

356 ：Name_Not_Found：04/12/05 07:17:58 ID:???

HTML4策定時にはSemanthicWebなんて考え方まだないから。

357 ：Name_Not_Found：04/12/05 07:48:21 ID:???

>>356
だからなんだろう。

358 ：Name_Not_Found：04/12/05 11:46:36 ID:???

お前らSGML使うなら、tagの補完や短縮命令が使えるんだし、
XMLうなら、名前空間使ってXHTML1.xに文章単位を明示する要素を追加すれば
いいんだから、そもそもHTMLの内側だけでHTMLの仕様外の情報をUAに明示しよう
という事自体が非効率ですよ(全く無意味ではないが、何の為の上位仕様か)

359 ：Name_Not_Found：04/12/05 12:25:02 ID:???

このスレもレベル下がったな

360 ：Name_Not_Found：04/12/05 14:02:51 ID:???

その一言だけじゃ説得力も糞も無いね。

361 ：Name_Not_Found：04/12/05 14:24:10 ID:???

俺＞＞＞＞＞＞＞おまえら

362 ：Name_Not_Found：04/12/05 14:35:18 ID:???

>>358
的外れですよ

363 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/05 15:19:05 ID:LKw02l1r

SGMLを知らなくても、HTML 4.01 Strictは書ける。
(これから、XHTMLの時代になるだろうから、XHTMLもやっておく？)
というか、私はSGMLなんて殆ど知らない。
誰か教えてくれ。

364 ：Name_Not_Found：04/12/05 16:43:04 ID:???

>>359
過疎化しただけ。
だから少数の厨が暴れると目立つ。
あ、そういうのもレベル下がったと言うのか。

365 ：286：04/12/05 20:12:33 ID:???

真面目な人も一部いるみたいなのでそこだけレスしとく。

>>343
・hnを包含するdivについては、それはセクションか、もしくはセクションより大きなまとまりなので、
　divが閉じるまでにセクションは終了しているべきである。

これは次と等価と考えられる。

・hnを包含するdivについては、それはセクションか、もしくはセクションより大きなまとまりなので、
　そのdivが閉じるのは当然にセクションの（そしてdivでグルーピングした大きなまとまりの）終了後であるべきである。

>336では、もしs2に誤りがないなら、そのdivの使い方が間違っているということになると思う。
その解釈なら>>343の結論と同じになるのかな。
逆に、>>336のdivにもし誤りがないとすれば、divを閉じた直後のpはセクションとは関係のない内容と推測され、
逆にs2がそこまで含んでしまっているというところが間違えていることになると思う。

あと判断がつかないところに答えておく。
>>341
日本語でのカタカナ言葉の使い方には議論の余地があるが、
それ以前に「セマンティック」を使い始めたのは>>334の方。それを引いただけ。

366 ：Name_Not_Found：04/12/05 21:06:49 ID:???

>>365
>・hnを包含するdivについては、それはセクションか、もしくはセクションより大きなまとまりなので、
>　divが閉じるまでにセクションは終了しているべきである。

脳内妄想？いつからdivがセクションを分断するように使ってはいけないってことになったの？
なんか仕様書の「divでセクションをあらわすこともできる」の一文の意味を誤解してるだろ。
例えば
<h2 class="a">
<p class="a">
<p class="b">
これを面倒だから
<div class="a">
<h2>
<p>
</div>
<p class="b">
っていうのは等価であるとみなしてもおかしくはない。
２個目のpは１個目のpと同じセクションにあるかないかを
判断できるような仕様にはなってない。

って、妄想仕様の話でHTML4.01とかのdivの話をしてるわけではないのかな？

とりあえず、妄想仕様話はやめないか？何の話なのか混乱するから他のスレ言ってくれ。

367 ：Name_Not_Found：04/12/06 00:29:26 ID:???

一連の議論の前提がよくわからなくなってきた。
現在の仕様でセクションを明示的に表す術がないのは事実、どうしても
表したければdivを活用するしかないがその場合どのようにマークアップ
したらいいか、という話をしてるんじゃないの？
この場合、「セクションを表す」というのが目的であり前提なのだから
仕様的なvalidよりも縛りがきつくなるのはしょうがない。
だってそうしないとセクションを表せないんだから。

そうじゃなく、いかなる場合にもdivはセクションを表していると
主張してる人がいるわけ？

368 ：Name_Not_Found：04/12/06 00:53:59 ID:???

そもそもセクションがセクション要素の中身だとするから入れ子になってるだけだろ286の言い分は。

369 ：Name_Not_Found：04/12/06 00:55:13 ID:???

>>367
> そうじゃなく、いかなる場合にもdivはセクションを表していると
> 主張してる人がいるわけ？
そういうことになるね。>>286の理論ではdivを区切る前にセクションが必ず終了しなければならない、
と>>286で言ってるし。

370 ：Name_Not_Found：04/12/06 00:56:35 ID:???

>>369
>そういうことになるね。
ﾏｼﾞｶﾖ ('A`) ｸﾀﾞﾗﾈｰ

371 ：Name_Not_Found：04/12/06 01:11:26 ID:???

ん？何気に自演のニヲイがするレスがチラホラと。

372 ：Name_Not_Found：04/12/06 01:20:18 ID:???

>>370
マジだから下らないんだよ。
下らないやつに言え。

373 ：Name_Not_Found：04/12/06 01:20:39 ID:???

>>371は自演の意味を知らなかった。

374 ：Name_Not_Found：04/12/06 01:38:24 ID:???

>373

ヲマエがよくやっていることだよな？

375 ：Name_Not_Found：04/12/06 02:38:12 ID:???

>>374
尋ね方間違えてるよ。
「どういう意味でつか？教えてくだちい。おながいしまつ」だろ。うせろﾄﾞｼﾞｿ

376 ：Name_Not_Found：04/12/06 07:31:41 ID:???

自演だろうが何だろうがいいじゃないか。
有意で議論可能なレスであればいくらでも歓迎だ。
そうでないものは無視すればいい。

377 ：Name_Not_Found：04/12/06 09:15:12 ID:???

セマンティックだけでなくsectionの意味すら勘違いしてるなこりゃ・・・・
sectionが入れ子になるわけないだろ。sectionってのは文書構造の一定のブロックみたいな
もんなんだから入れ子してるのに「両方sectionです」なんてもうアホかと・・・・
見出しの入れ子と同じレベルだぞ。

１．セクションの中に見出しや段落がある
２．見出しから見出しがセクションであり、見出し自体はセクションに内包されてない
HTMLとかで考える前に１と２のどちらが正しいのかを考えてみろよ。

378 ：Name_Not_Found：04/12/06 10:12:45 ID:???

>>377
できたらどのレス番に対する反論なのか明示するようにしてくれると助かる。
横で見ているとちょっと話の流れを追いにくいので。

379 ：Name_Not_Found：04/12/06 10:26:02 ID:???

>>378
>横で見ているとちょっと話の流れを追いにくいので。
・・・・・++;

>横で
orz

何なんだコイツは・・・

380 ：Name_Not_Found：04/12/06 10:41:36 ID:???

>>377
> sectionが入れ子になるわけないだろ。
七誌で投稿しても誰だか分かる例。

381 ：378：04/12/06 10:55:00 ID:???

>379
議論してる本人だけ理解できればいいってか。邪魔して悪かったな。

382 ：Name_Not_Found：04/12/06 10:57:28 ID:???

>>381
ほっとけ。こいつは自論以外受け付けないタイプだから。
なんでセクション要素なんだ、ってのには反論しないし。

383 ：Name_Not_Found：04/12/06 11:15:02 ID:???

>>365
しかし、それは全て、「見出しが作る暗黙のセクションは擬似的な要素である」
という前提に立った話なんだよな。これがそうではなく、擬似的な属性である
とすると、

<h2 id="h2-1">見出し</h2>
<p for="h2-1">段落</p>
<p for="h2-1">段落</p>
<h2 id="h2-2">見出し</h2>

こんな感じになって、どのようにでも div で括れるし、どう div で括ろうと
見出しの作り出す暗黙のセクションは変えられないことになる。

で、暗黙のセクションがこのどちらであるかは仕様書に書いてないわけだ。
結論としてはどちらとも言えない。

384 ：Name_Not_Found：04/12/06 11:40:15 ID:???

わざと曲解しはじめてきた人も出てきたしもうダメポ

385 ：Name_Not_Found：04/12/06 11:56:49 ID:???

divでセクションを明示するのって、スタイルのためだけなんじゃないの？
で、hnで作られた範囲ってのはスタイルとは関係のない、文章としてのセクション。

386 ：Name_Not_Found：04/12/06 12:05:26 ID:???

>>381
＞横で
どこだよ？って突っ込んでるのにお前は・・・・

387 ：Name_Not_Found：04/12/06 12:07:32 ID:???

>>385
現状ではスタイルのためくらいだとしても、今後他にも使えるものが出てくるかもしれない。
だから論理的なマークアップをしてくれ。

388 ：Name_Not_Found：04/12/06 12:15:35 ID:???

スルーされただけだろ。粘着なヤツだね。

389 ：Name_Not_Found：04/12/06 12:18:13 ID:???

>>383
流れ読んでないかもしれんが、そうすると、

<h1 id="h1-1">見出し</h2>
<p for="h2-1">段落</p>
<h2 id="h2-1">見出し</h2>
<p for="h4-1">段落</p>
<p for="h1-1">段落</p>

とかやりたい放題にならない？

390 ：Name_Not_Found：04/12/06 12:37:25 ID:???

>>389

見出しが作る暗黙のセクション内の擬似的な属性だから…

<h1 id="h1-1">見出し</h2>
<p for="h1-1">段落</p>
<h2 id="h2-1">見出し</h2>
<p for="h2-1">段落</p>
<p for="h2-1">段落</p>

じゃねーの？

391 ：Name_Not_Found：04/12/06 12:43:59 ID:???

<h1 id="h1-1">見出し</h2>
<p for="h1-1">段落</p>
<h2 id="h2-1">見出し</h2>
<p for="h1-1 h2-1">段落</p>
<p for="h1-1 h2-1">段落</p>

こうかな？
ﾜｹﾜｶﾝﾈ

392 ：Name_Not_Found：04/12/06 12:53:16 ID:???

>>389
やりたい放題になると何か問題あるの？
現状だって段落をpでやるかどうかは制作者次第だよ。

あくまでも機械に自分の文書の構造を伝えるにはどういう仕様が好ましいかって
話だから、みんなが守るためにはとかじゃないんだよね。

393 ：Name_Not_Found：04/12/06 13:15:02 ID:???

>>392
うるせえ

394 ：258：04/12/06 13:19:33 ID:???

あわわあわわ。

395 ：Name_Not_Found：04/12/06 14:00:33 ID:???

＋＋；

396 ：Name_Not_Found：04/12/06 15:21:15 ID:???

いつのまにか仕様書に一字一句書いてあることだけしか認めないってのが増えているようだな

397 ：Name_Not_Found：04/12/06 15:34:56 ID:???

>>396
どれに対して言ってるかわからん。

398 ：Name_Not_Found：04/12/06 16:06:37 ID:???

やっぱここって脳内仕様スレなのね。

399 ：Name_Not_Found：04/12/06 16:26:20 ID:???

XHTMLは知らないんだが、XHTMLではdivをセクションとして使用して、機械に理解させることは
できるの？

400 ：Name_Not_Found：04/12/06 16:35:52 ID:???

>>399
制作側のローカルルールを不特定のUAに理解させるのはいくらなんでも無理。
XHTMLだったら期待する意味(ここではセクション)を示す語彙を持つ名前空間から
要素型を流用する方がはるかに現実的かと。

401 ：Name_Not_Found：04/12/06 19:20:43 ID:???

その「期待する意味を示す語彙を持つ名前空間から要素型を流用する」ために、
期待する意味を示す語彙を持つ名前空間はどれだろう、ってことを考えるんだが、
お前らそういう一般的な要素型の一覧表でも持ってるの？RDFにおけるDCみたいな。

402 ：Name_Not_Found：04/12/06 20:41:27 ID:???

別にDCってRDFのためにあるわけじゃないんだが。

403 ：Name_Not_Found：04/12/06 20:54:16 ID:???

で、結論としては、divをどう弄くったところでsectionを表現することはできない、でOK？

404 ：Name_Not_Found：04/12/06 21:30:15 ID:???

divにsectionという意味は含まれない。
但し(合意の取れた環境下で)sectionとして運用することを妨げもしない。

…くらいの感じでは。

405 ：401：04/12/06 21:40:46 ID:???

>>402
いや別にDCはRDF専用だなんて書いたつもりはないんだが……。

406 ：Name_Not_Found：04/12/06 22:39:04 ID:???

>>401
http://it.jeita.or.jp/eltech/XML/YP_LIST.html
こっから探してみるのはどうだろう。

407 ：Name_Not_Found：04/12/06 22:50:28 ID:???

HTMLではsectionの実体は定義されていない。以上。

408 ：Name_Not_Found：04/12/06 23:17:28 ID:???

おまえら仕様書のdivの例文を嫁。

409 ：Name_Not_Found：04/12/06 23:29:33 ID:???

>>408
何が言いたい？

410 ：Name_Not_Found：04/12/06 23:42:18 ID:???

>>404
というかこのスレに入ってからdiv=sectionなんて主張してた奴はいないようだが。
同じくdivをsectionとして運用することを全否定してた奴は……真上にいたか。

411 ：Name_Not_Found：04/12/07 00:36:29 ID:???

なんか誤読で話が続いてるな。

>>404
＞というかこのスレに入ってからdiv=sectionなんて主張してた奴はいないようだが。
そんな話じゃないよ。divでセクションが終了するからそれ以降はその見出し以下ではない、と言ってる香具師がいた、ってだけだ。

412 ：Name_Not_Found：04/12/07 00:46:30 ID:???

>>411
おまえも誤読しているようだな。

413 ：Name_Not_Found：04/12/07 00:55:04 ID:???

・divで制作者がセクションを明示する事ができる
・divがセクションを示しているとは限らない

>>377（>>365、>>286）は、section要素が入れ子違いになるから、セクションはdiv終了タグ前に終了している、と言い切っている。
俺（>>311）とか、>>383は「要素だとすればそうだが、要素じゃなければその理論は破綻する」と言ってる。

俺はこの辺りの話に対しての>>286の見解が聞きたい。

414 ：Name_Not_Found：04/12/07 00:56:41 ID:???

>>412
すまない。誤読してるつもりは無かったんだが、どういう話をしてるんだ？
教えて欲しい。

415 ：Name_Not_Found：04/12/07 00:59:44 ID:???

>>413
セクションをラベル（てか属性？）で表現しようっていうのか？
そんなセクション実装を想定しているとは正気とは思えんが。
これまでの議論で背景とかも論じていたなら教えて欲しい。

416 ：Name_Not_Found：04/12/07 01:05:27 ID:???

>>415
実装の話じゃないよ。

そもそもの発端は、
hn～hn間がその見出しが表す範囲か否か、で
みなす、という意見と、みなすことも出来るが補足として、その上位の以下である可能性もある、という意見があった。

そこで>>286がsection要素として考えればdiv要素が終了する以前にsection要素が終了してなければならない、
ゆえにdiv以前にそのセクションは終了する、と架空の要素でhn間セクションの考えを否定した。

いや、そんな要素ないし、って言っても聞き入れないから、「こういう構造だったらお前の理論は破綻するだろ？」と振り出しに戻した。

それだけだよ。

417 ：Name_Not_Found：04/12/07 01:07:23 ID:???

>>416
なんだそりゃ？
そんな話だったら、そもそも「見出しが表す範囲」自体が架空じゃん。意味わからん。

418 ：Name_Not_Found：04/12/07 01:13:08 ID:???

>>417
なんでそんな話になったか、も説明しなきゃならないか。
つか、わからないならスルーすりゃいいのにな。

見出し＋中身群でセクションってのを明示するためにいちいちdivでくくれ、っつーのかよ。って話から、
次の等価の見出しまでを範囲に、とできればいいのに、となってだな。

で、結局実現されてないから、dl要素が多用されるんだよな、って話だったわけ。
これならdd～ddがひとくくりだしな。

でも、「よく考えたら、hn間の考え方は論理的に破綻する」って話が出てきたから、
「なんで破綻するの？」となったわけ。以降>>286から続く。

419 ：414：04/12/07 01:15:08 ID:???

>>412
そろそろ説明をお願いしたいんだが。

420 ：Name_Not_Found：04/12/07 01:18:02 ID:???

仕様書に書いてある例は、「見出し」と「見出しが作り出すセクション」を
divでまとめることが出来るというものであって、divでセクションを作り出す
ことが出来る例にはなっていない点も要注意だな。

421 ：286：04/12/07 01:27:09 ID:???

むぅ。ROMるつもりだったんだが曲解されまくっとるな。

>286や>331を読めばわかるが、俺の考え方は、
(1) デフォルトは見出しから次の見出しまでがセクション
(2) しかしdivが挟まるとそうではなくなる
と解釈するのが最も合理的であろうってことだ。

まったく言っていないことに対して批判ぶつけられても困る。

セクションを要素としたのは確かに仮定だが、
そもそも仕様書にセクションの明示がないんだから、
「セクション」を話題にする限り何らかの想定が必要でしょう。

んで属性より要素と考えた方が遙かにしっくり来る。
それによって (1) も極めて自然に説明できる。（>331）
（これから実装されるであろうセクションも要素ということだから、
　いまの文章をけっこう近い形でコンバートできるし。）

属性にした場合、属性値の補完のルールなんかはどうなるの？って疑問があるし、
>>389で指摘されているような状況も許容してしまうから。
それに将来にわたって“公式サポート”もなさそうだし。

422 ：Name_Not_Found：04/12/07 01:28:19 ID:???

hnは次に続く文章の説明をする要素。
次に続く文章をセクションとして、セクションの見出しとして扱える。
この範囲はdivを使ってまとめてもいい。

これをどう曲解したのか、「hnによって暗黙のセクション要素が作られる」という
強引な解釈をした馬鹿に付き合った結果が今の状況。

さらに、divでセクションを明示できるという文章も曲解し、結果として
「hnによって作られる暗黙のセクション要素と自分で明示したセクション要素に矛盾ができるんだけど？」
とか言い出したから始末が負えない。

div単体でセクションを作ることはできないし、hnでセクション要素が作られるわけでもない。

423 ：Name_Not_Found：04/12/07 01:35:33 ID:???

>>421
> (2) しかしdivが挟まるとそうではなくなる
> と解釈するのが最も合理的であろうってことだ。
文字の言語を明示してるだけの可能性もあるのにそこで終了、ってのはな。

424 ：Name_Not_Found：04/12/07 01:36:47 ID:???

>>422
> これをどう曲解したのか、「hnによって暗黙のセクション要素が作られる」という
> 強引な解釈をした馬鹿に付き合った結果が今の状況。
違うよ。

425 ：Name_Not_Found：04/12/07 01:49:00 ID:???

>>422
おまえみたいなのがいるから始末が負えないんだよな。

426 ：286：04/12/07 01:50:41 ID:???

>>423
>>329

427 ：412：04/12/07 01:55:50 ID:???

>>419
レス番間違えているし、>>411は全然>>410の話を否定していない。

428 ：Name_Not_Found：04/12/07 01:56:14 ID:???

>>426
文字の言語を明示してるだけの可能性は無視ってことか

429 ：Name_Not_Found：04/12/07 01:57:47 ID:???

>>427
414=411
なにが誤読だ？って聞いてるんだよ。

430 ：Name_Not_Found：04/12/07 10:47:12 ID:???

ttp://yupotan.sppd.ne.jp/web/xhtml2-headings.html
ttp://yupotan.sppd.ne.jp/web/heading-tree.html

431 ：Name_Not_Found：04/12/07 10:54:44 ID:???

>>412
まーだー？

432 ：258：04/12/07 12:35:55 ID:???

あわわあわわ。

433 ：Name_Not_Found：04/12/07 12:39:36 ID:???

というか>>269-277で結論出たはずなのに蒸し返し続けている人がいるように思われ。

434 ：Name_Not_Found：04/12/07 13:02:54 ID:???

てことは、結局議論の中身は空だったわけね。
前々から認識されていたことが再認されただけと。

435 ：Name_Not_Found：04/12/07 13:45:27 ID:???

>>421
>それによって (1) も極めて自然に説明できる。（>331）

そう簡単には行かないと思うが…。要は、暗黙の要素ということで、
開始タグも終了タグも省略可能なセクション要素が仮想的に存在すると
仮定するわけだよね。
確かにこれなら一切divがない場合は見出しから次の見出しまでが
セクションになるし、見出しがdiv内に入っている場合はそのdivの
範囲内がセクションの範囲になる。しかし、例えば次の場合はどうか。

<h2>見出し</h2>
<div>
<p>段落</p>
</div>
<div>
<h2>見出し</h2>
<p>段落</p>
</div>

これは一つ目のセクションは、divとdivの間で閉じてほしいところだ。
ところが、セクション内にdivが書けるとするなら、2個目のdivまで
一つ目のセクションに含まれてしまう。

つづく。

436 ：Name_Not_Found：04/12/07 13:46:19 ID:???

>>435 のつづき。

SGMLでは構文解析は逐次に処理できなきゃならないので、<div>の開始タグを
読み込んだ時点でそれがセクション内かセクション外かが判断できなきゃ
ならない。中に見出しがあるかどうかを見てからというのは許されない。

結果、このSGMLの制限を考えると、暗黙のセクション要素を導入する
には、次のどちらかの選択が強いられることになる。
　・div内に見出しを書くことを禁止すること。
　・div内は必ず見出しで始まらないとならないよう限定すること。
こうして、ISO-HTMLでは前者が選択されたのだろう。（個人的には
後者を選択してほしかったが…）

それはともかく、要はこのSGMLの制限から言って、divがどこにでも書ける
HTML4で暗黙のセクション要素はあり得ないわけだ。つまり、暗黙の
セクションは、属性であるかどうかはともかく、少なくとも要素ではない。

437 ：Name_Not_Found：04/12/07 14:27:51 ID:???

ちょっと根本的な議論したいんだけどさ・・・・

セクション 1 [section]
(1)部分。仕切り。
(2)（文章などの）節。項。
(3)会社などの部課。
(4)建築で、断面図のこと。

せつ 1 【節】
(4)まとまったものをいくつかに分けた、そのひとまとまり。区切り。
助数詞的にも用いられることがある。
(ア)文章・詩歌・音曲などの一つの段階。
「三つの―から成る論文」「―を改めて書き継ぐ」「第三章第二―」

次回に各ね

438 ：437：04/12/07 14:31:54 ID:???

そもそもセクションってちょっと抽象的な部分あるでしょ。
広く言ってしまえばひとまとまりのグループになると思うのね。

XHTMLで今後セクションを明確にマークアップすることができるようになったとして、
その必要性はいかに？

単純にグループするには今までどおりDIVだろうし。逆にDIVでグループすることさえ
しておけばセクションなんて機械に伝えたところでメリットなんてないし。

またあとで・・・

439 ：Name_Not_Found：04/12/07 15:15:06 ID:???

>>435-436
セクションは HTML で明示されていないし、リニア志向なので、
問題はどうイメージしてどう記述するか、でしょ。
要素でも属性でもないとしたら SGML では表現不能なわけで、
それを前提に「この部分はこのセクションだ」とか
「セクションを明示するには」とか話すのは馬鹿馬鹿しい。

Strict スレは仕様よりさらに厳しくってことで、
>>436のような、じゃあどうするかっていう議論をする場であったはずだが。

440 ：Name_Not_Found：04/12/07 17:36:26 ID:???

>セクションなんて機械に伝えたところでメリットなんてないし。

特定のセクションを切り出すという作業が楽になる。
長いHTMLファイルの一部だけ参照用に手元に残しておきたいって事が
時々あるんだけど、手作業で切り出すのはけっこう面倒くさい。
現状でも見出しが規則的についていれば何とかなるけど、
書き手によってムラや癖があるからなあ。

441 ：Name_Not_Found：04/12/07 17:49:41 ID:???

セクションが明確になると、
それをヒトに伝達する機械にとってはメリットがあるかも。

442 ：Name_Not_Found：04/12/07 19:21:58 ID:???

セクションをセクションとして表現できることのストリクターの歓び。
セクション、ああ甘美なる調べ。
セクションか否か、それが問題なのだ。
世界は成立しているセクションの総体である。
とまれ、セクションはいかにも美しい。

443 ：Name_Not_Found：04/12/07 19:31:16 ID:???

>>435は「hn～hnをセクションであると SGML 的に自動解釈するするのは無理」ってことだな。
>>441 ｍ9(･∀･)ｿﾚﾀﾞ！

444 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/07 19:55:09 ID:PPdKG/TN

SGMLではコメントの中に--を入れることはできないというけれど、コメントに--を書きたい場合はどうするのだろう？

445 ：Name_Not_Found：04/12/07 20:22:37 ID:???

詳しいことはわからんが、エスケープシーケンスがあるんじゃないの？

446 ：Name_Not_Found：04/12/07 20:28:20 ID:M5ObfajS

掲示板記事内容の名前とかは何で定義すべき？

447 ：Name_Not_Found：04/12/07 20:30:00 ID:???

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

448 ：Name_Not_Found：04/12/07 20:34:17 ID:???

>>444
CDATA区間に]]>を書きたいときはどうすんの？ってのと一緒で
書けないものは書けないというか、書けば解釈の対象となる。どうしようもない。

449 ：446：04/12/07 20:48:50 ID:???

記事番号

eddress　URL

日付

タイトル
メッセージ

投稿者名
投稿者ＩＰ

上のような項目の場合、Strict-HTMLではどう記述すべきですか？
「記事番号が主キーなので見出しとして扱うべきなのか」など
悩み始めるとなかなか答えが見つからず・・・。
助言をいただけないでしょうか？

450 ：Name_Not_Found：04/12/07 20:50:19 ID:???

>>449
いままで色々な説があったけど、俺的には、
記事番号＋タイトルを見出しとしてよいのではないか、と。
第一章とかそういうのと同じようなもんだろうし。

451 ：Name_Not_Found：04/12/07 20:52:02 ID:???

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
この二つってどう違うの?

452 ：435=436：04/12/07 21:43:46 ID:???

>>436
>次のどちらかの選択が強いられることになる。
>　・div内に見出しを書くことを禁止すること。
>　・div内は必ず見出しで始まらないとならないよう限定すること。

本論には影響しないけど、よく考えたら後者の条件だけではだめだった。

<h2>見出し</h2>
<p>段落</p>
<div>
<h3>見出し</h3>
<p>段落</p>
</div>

この場合、<div>開始タグを読み込んだ時点ではそれが同位のセクションか
サブセクションかが区別できない。つまりSGMLの逐次処理では暗黙の
セクションが見つけられないわ。ということで訂正。

暗黙のセクション要素を導入する場合、次のどちらかの選択が強いられる。
　・div内に見出しを書くことを一切禁止とすること。
　・全てのdiv内は必ず見出しで始まり、かつ全ての見出しは必ずdivの
　　開始地点になければならないと限定すること。
ということですね。しかし、後者は結果として「div要素こそセクション要素」
となる訳で、セクションは暗黙でなくなることになりますが。

ってことは、ISO-HTMLこそがSGMLで暗黙のセクション要素を導入する唯一
の解ってことか…。

453 ：Name_Not_Found：04/12/07 21:51:54 ID:???

>>448
]]>]]><![CDATA[

454 ：Name_Not_Found：04/12/07 21:53:37 ID:???

しまった、2chは実体参照が効かないんだった。

]]>]]＆gt;<![CDATA[

な。

455 ：Name_Not_Found：04/12/07 21:56:13 ID:???

実体参照が効かないとはこれいかに。
]]>]]><![CDATA[

456 ：Name_Not_Found：04/12/07 22:01:52 ID:???

>>452
・ある一つの見出しを div の子要素にするなら、すべての見出しの直接の親要素が div であること
だけでよいのではないか、と。

>>430にも似たような話が書いてあった。
＞常に「終止一貫した」階層構造を作るように心がけることが、セマンティックウェブへの第一歩

457 ：Name_Not_Found：04/12/07 22:04:00 ID:???

そもそもの発端はセクションを明示できるかどうか、明示するにはどうすべきか、ではなくて、
「見出しと内容がセットだって解釈してくれりゃいちいちdiv要素で括らなくてもいいのにな」って話だったと思うんだが。

実際、これはstrict的な思惟じゃないんだけど、
hn+ulでメニュー作ったけど、それを囲う枠なんか作っちゃって、とか考えたらそれをdiv要素で括って、
でも、このdivって見栄えのためだしなぁ、ダメじゃないけどなんだかなぁ。div使いまくりだよなぁ。みたいな。

で、えー面倒臭ぇから、dlでいいや。とかなっちゃったり。
そんなもん見出しと内容はセットだろうが、わかってくれよ、と思ったり。

ホントstrictな考え方じゃないことは承知の上で。

458 ：Name_Not_Found：04/12/07 22:07:01 ID:???

こういう記述ができればなぁ。
<div level="3" title="foobar">
<p>～</p>
</div>

<div>
<h3>foobar</h3>
<p>～</p>
</div>
と等価。

459 ：Name_Not_Found：04/12/07 22:10:14 ID:???

>>458
なんとなく気に入らないな。
「foobar」が見出しと等価なら、属性じゃなくて内容として記述した方がよいかと。
table でいう caption みたいな位置づけにするべきじゃないかな。

460 ：458：04/12/07 22:20:59 ID:???

>>459
divにhnが必須要素、みたいにするなわけだね。
いやぁ、俺バカだからさぁ、
なんかたくさん書くのが面倒だな、って。
だから逆にtableのキャプションも属性にすりゃ楽なのに、とか考えてしまうわけ。
気に障った部分は申し訳ない。ごめんね。

461 ：Name_Not_Found：04/12/07 22:25:10 ID:???

> tableのキャプションも属性にすりゃ楽なのに
そうならなかった理由の一つには恐らく後方互換があるんだろうなぁ。

462 ：458：04/12/07 22:30:51 ID:???

>>461
だろうなぁ。
俺も「こんな風に変更して欲しい」と言ってるわけではなくて、
「最初からこうだったらなぁ」と夢見心地で書いただけなんだよね。
じゃあ、チラシの裏に書け、って話だけど。

ほんとごめん。なんか仕様に難癖つけたみたいになっちゃった。
そんなつもりじゃなかったんだけど。

463 ：459：04/12/07 22:36:15 ID:???

>>461
というか基本的に可視であるべきものは内容として書いて、
隠れていても構わないものは属性にするんじゃないの？
img が不完全だとよく言われる理由は alt が隠れているからだと思っていたが。

464 ：Name_Not_Found：04/12/07 22:39:41 ID:???

代替テキストが最初っから表に出てたら代替じゃないわけだが。

465 ：Name_Not_Found：04/12/07 22:42:18 ID:???

object

466 ：459：04/12/07 22:43:05 ID:???

>>464
>463のは例がよくなかったかもだけど、
むしろ、もし画像が表示できるならテキストの替わりにイメージで…
と考えておくくらいが…もともとテキストマークアップ言語だし。

467 ：Name_Not_Found：04/12/07 22:47:57 ID:???

TML？どこの仕様だそれ？

468 ：Name_Not_Found：04/12/07 23:05:14 ID:???

>>463
captionが属性でないもう一つの動機として
要素ならば値の構造化が可能、というのがあると漏れは思う。
imgのalt属性も値を構造化できない点で不便だなとか思うときあるし。

469 ：Name_Not_Found：04/12/07 23:34:29 ID:???

>>467
誤爆？

470 ：Name_Not_Found：04/12/07 23:42:52 ID:???

Text Markup Language

471 ：Name_Not_Found：04/12/07 23:42:57 ID:tzycjwjQ

>>469
＞もともとテキストマークアップ言語だし。
に対するレスでしょ。

もともとテキストマークアップ言語＝MTML

472 ：Name_Not_Found：04/12/07 23:44:40 ID:???

テキストマークアップ言語＝テキストをマークアップする言語じゃないの？

473 ：Name_Not_Found：04/12/07 23:48:49 ID:???

>>472
ハイパーだけなんで削るの？っていう揚げ足だからそんなに気にしなくてもいいでしょ。
HTMLと言ってたとしてもテキストをマーク付けする言語であることにかわりはないわけだし。

474 ：Name_Not_Found：04/12/07 23:51:06 ID:???

http://pc5.2ch.net/test/read.cgi/hp/1075994695/810-

475 ：Name_Not_Found：04/12/07 23:59:46 ID:???

>>471
最後ちょっとだけﾜﾛﾀ

476 ：Name_Not_Found：04/12/08 03:58:25 ID:d9ndexgf

authorとmadeとcopyrightの違いがいまいちつかめず。
複数で作っている場合、どうすればいいのだろう。
あなたはどう書いていますか？

477 ：Name_Not_Found：04/12/08 04:53:00 ID:???

object要素で代替部が内容になったのは嬉しいね。
XSLTするとき
<xsl:value-of select="p"/>
とかすると、img要素の場合はalt属性の中身が展開されないから
そこだけ文章が抜け落ちちゃうんだよね。

478 ：Name_Not_Found：04/12/08 07:16:06 ID:???

>>476
ttp://www.kanzaki.com/docs/sw/dublin-core.html

479 ：Name_Not_Found：04/12/08 07:40:25 ID:???

>>476
http://pc5.2ch.net/test/read.cgi/hp/1102337766/

480 ：Name_Not_Found：04/12/08 11:48:00 ID:???

hn+pと1dt+ddを使いわけるための境界はどこですか？

hn+pをli要素に突っ込む人もいますが、li要素は箇条書き程度のものではないのですか？
そもそもliの中にhn,pを入れてる時点で非strictだと思います。

pを十個ならべればliなどに入れなくてもUAには十個のpが伝わります。

僕の自論はおかしいでしょうか？

481 ：Name_Not_Found：04/12/08 12:08:56 ID:???

>そもそもliの中にhn,pを入れてる時点で非strictだと思います。

非 Strict とする根拠は？

>pを十個ならべればliなどに入れなくてもUAには十個のpが伝わります。

UA には十個の p が伝わるね。それと li と何の関係が？

482 ：Name_Not_Found：04/12/08 12:13:37 ID:???

>>480
同時に複数の質問をするなよ。

尚、まあ辞書での定義というのは一般的だから広義に取りやすくなるが、

> か‐じょう【個条・箇条】
> 記事を幾つかに分けて並べた時のそれぞれの事柄。条項。項目。

483 ：Name_Not_Found：04/12/08 12:17:48 ID:???

>>480-481
>そもそもliの中にhn,pを入れてる時点で非strictだと思います。

これはわりかしそう思うけどね。
でも改めて根拠を聞かれると困るかも。

484 ：Name_Not_Found：04/12/08 12:52:24 ID:???

個人的にはli要素の中にはインライン要素のみしか入れない縛りを採用してる。
ul要素は例外的に認めてるけど。
ブロックレベル要素とインライン要素が兄弟になるのはなんか気持ち悪いんだよね。
とはいえ、XHTML2.0だとp要素が同じような状況になるけど、あんまり違和感ないから、
やっぱりリスト内にブロックが有る、ってことがなんか嫌なんだろうな。

dlとhnの使い分けも内容によるな。
ブロック要素が普通に出るようだとdlよりhn系の方が良い気がする。

明確な根拠はないな。

485 ：480：04/12/08 13:38:48 ID:???

>そもそもliの中にhn,pを入れてる時点で非strictだと思います。

＜根拠＞
セマンティックウェブにおいてはli要素の中にhn+pを入れる必要性がないからです。
hn+pをli要素にいれたいのであればそれはdl要素で伝える方が効率が良いでしょう。
つまり根本から論理的なマークアップができてないという可能性が高くなり非strict
という結論が導き出されます。

また、ulなどの入れ子もそうであります。
<ul>
<li>home
<ul><li>chapter1<li>chapter2</li></ul>
</li>
</ul>

このようにマークアップしてもhomeと中のulは同等であり、表したいhomeの中にulがあるいうことは
伝え切れません。どちらかというと???フォルダのなかにhomeファイルとulフォルダがあるという
感じだと思います。homeディレクトリの中にulフォルダがあるとは機械は解釈できません。

486 ：Name_Not_Found：04/12/08 13:58:08 ID:???

セマンティックウェブにおいては、とか、
可能性が高くなる → 非 Strict、なんて表現方法じゃ納得できないと思

487 ：Name_Not_Found：04/12/08 14:57:37 ID:???

エンコードがUCS-2のときのcharsetって何ですか？

488 ：451：04/12/08 15:19:45 ID:???

ごめん、昨日も聞いたんだが
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
この二つは違いがない?

489 ：Name_Not_Found：04/12/08 15:36:09 ID:???

>>487-488
http://pc5.2ch.net/test/read.cgi/hp/1102337766/

490 ：480：04/12/08 15:52:37 ID:???

>>486
では、liの中にhn+pを入れてもstrictだといえる状況をあげてください。
そうすればもっと具体的な議論ができるかもしれません。

491 ：Name_Not_Found：04/12/08 16:11:37 ID:???

>>490
>>486は「非strict」というタームが引っかかってるだけだろ。

んー。、liの中にhn+pを入れてもstrictだといえる状況ね。

html文書のサンプル（hn+p）は以下のようなもの（等価なので、順不同で羅列）があります。
とかはどう？　俺の稚拙な脳ではこんなのしかでてこない。

492 ：Name_Not_Found：04/12/08 16:11:37 ID:???

「Strictでない」理由の存在を証明できなければ「Strictでない」理由はない。
悪魔の証明で、「Strictでない」理由がないことを証明することは不可能。

と、詭弁をふっかけてみるテスト。明確に誰もが納得できる根拠なんてあるのかね。

493 ：Name_Not_Found：04/12/08 16:13:31 ID:???

>>492
それは悪魔の証明を誤用してるよ。

494 ：Name_Not_Found：04/12/08 16:15:30 ID:???

>>492
「Strictである」理由の存在を証明できなければ「Strictである」理由はない。
悪魔の証明で、「Strictである」理由がないことを証明することは不可能。

と、切り返してみるテスト。

495 ：Name_Not_Found：04/12/08 16:22:20 ID:???

>>493-494
だから詭弁だってば。

DTD以上のことをやろうとしたら論理的な説明が可能である必要があるけど、
今回のケースに関しては実装上の不具合以上の理由が見当たらないんだよな（俺には）。
どうしてStrictでないのか、があやふやな感じで定義されたところで反論できないよ。

496 ：Name_Not_Found：04/12/08 16:22:35 ID:???

「Strictである」理由　「Strictでない」理由ってなんだよ。
悪魔の証明の使い方間違ってるぞ。

「このサイトを「strictではない」と言う人がいるかもしれない」とかなら完全に悪魔の証明だが、
strictである、ない、なんて「仕様書に照らして」でクリアされちまうだろうが。

497 ：bystander：04/12/08 16:23:02 ID:???

おー、これがStrictスレ名物の詭弁合戦か。

498 ：Name_Not_Found：04/12/08 16:23:58 ID:???

>>495
いや、だから詭弁にすらなりえてないんだってば。

499 ：Name_Not_Found：04/12/08 16:26:20 ID:???

>>496
このスレのStrictは仕様書を守っているだけでは達成されません。

500 ：495：04/12/08 16:26:23 ID:???

>495の説明はわかりづらかったな。

>>485が根拠として述べていることに反論してみると、

>dl要素で伝える方が効率が良い

この「効率」は何を指すのか（dt+ddのグループ化でUAの解釈が容易？）、
そこから導かれた効率の悪いマークアップが論理的でなく非Strictなのは何故か、
という点が俺にとって納得できるものではないです。

>このようにマークアップしてもhomeと中のulは同等であり

hnは見出しだけれど、見出しは本文の題名ではないと思うよ。
「homeディレクトリ」つまり要素全体の名前が決めたいならtitle属性でないかね。

という感じです。

501 ：Name_Not_Found：04/12/08 16:29:48 ID:???

>>499
そういうことじゃなくてだな、
「なんでstrictじゃないの？」は悪魔の証明だ、ってのは違うだろ、って。
納得させられなくても、そうだと主張する理論は挙げられるわけだ。
「違うことを証明するのは不可能」ではないだろ、って。

502 ：Name_Not_Found：04/12/08 16:35:40 ID:???

>>500
彼は、「なぜ効率がよいのか」の説明をしていない。
ないものに反論しようとするからそうなるのであって、
ないのであれば、彼が明示するのを待てばよい。

503 ：Name_Not_Found：04/12/08 16:36:11 ID:???

てか悪魔の証明って一般に否定の証明が難しいってことじゃなかった？

504 ：Name_Not_Found：04/12/08 16:38:16 ID:???

>>503
否定の証明が困難、というケースで使われるが、
それを根拠とされた場合に使う言葉なのよ。
「お前を不細工だと思う奴がいるかもしれないだろ。だからお前は不細工なんだよ」とか。
これを否定するために「全ての生き物が自分を不細工だと言わない」と立証するしかないわけだ。

505 ：Name_Not_Found：04/12/08 16:40:39 ID:???

「無い事の証明」は実行不可能である事の比喩表現。「有る事の証明」は証拠を提示するだけで終わるが、「無い事の証明」はそもそも『有る証拠が無い』という主張なので証拠の提示はできない。

故に、立証責任は「有る」と主張する側に科せられる。「有る事の証明」ができなければ無いものと見なされる。「無い」と主張する側は「有る」と主張する側の矛盾点を指摘するだけで良い。これに対し、「有る」と主張する側は証拠を提示しなければならない。

cite ttp://plaza.rakuten.co.jp/obiekt/diary/200408280000/

506 ：Name_Not_Found：04/12/08 16:41:53 ID:???

悪魔の証明
ttp://ja.wikipedia.org/wiki/%E6%82%AA%E9%AD%94%E3%81%AE%E8%A8%BC%E6%98%8E

507 ：Name_Not_Found：04/12/08 16:42:14 ID:???

>>505
「万引きをしたことがない」を証明しろ、とかだな。

508 ：Name_Not_Found：04/12/08 16:43:03 ID:???

>>505
まったくスレ違いもいいところだが背理法があるよね。＞実行不可能
例えば「無罪の証明」に使われるアリバイはその例といえる。

ちなみに「証明がなければ否定しておく」っていうのを閉世界仮説っていうんだっけ？

509 ：Name_Not_Found：04/12/08 16:44:06 ID:???

推定無罪？

510 ：Name_Not_Found：04/12/08 16:46:34 ID:???

まったくここは独特のそれ方をするね。
それがいいんだけどさ。

511 ：Name_Not_Found：04/12/08 16:48:19 ID:???

こうやって皆少しずつ賢くなっていくわけですよ

512 ：Name_Not_Found：04/12/08 16:49:00 ID:???

放置とスルーだけは決して学ばないとしても。

513 ：Name_Not_Found：04/12/08 16:49:11 ID:???

というか、492の用法は別に間違っていないように思えるのだが。
『「Strictでない」理由の存在』という表現がアレかどうかは別として。

514 ：Name_Not_Found：04/12/08 16:49:51 ID:???

Strict に興味をもつのは高校もしくは大学生以上だからか、
Web 制作板の中ではわりかし知識レベルが高い方かもしれない。
もちろん知識レベルと議論レベルは別だが。

515 ：Name_Not_Found：04/12/08 16:51:36 ID:???

馬鹿じゃないから、かえってタチが悪いんですよ。

516 ：Name_Not_Found：04/12/08 16:52:45 ID:???

>>513
逆でしょ。「strictな文書であるという証明」は、否定者がいるかもしれないためにできない。
「strictな文書ではないという証明」は、否定すれば成立する。
そういうことなので、逆に悪魔の証明の言葉を用いるのは無理かと。

517 ：516：04/12/08 16:55:05 ID:???

言葉足らずだな。俺。

「万人が認める正しい文書である」は証明できない。
「万人が認める正しい文書ではない」は証明できる。

要は「strictな文書」ってものの定義自体があやふや、と言いたいんでしょ？

518 ：Name_Not_Found：04/12/08 17:05:42 ID:???

>>517
その一歩手前でしょ。
（誰かが認める）正しい文書であるかどうかの理由で悪魔の証明云々なんだから、
正しい文書であることの証明は正しい文書でない理由がなければなされていることで、
逆に言えば正しい文書でないことの理由を説明する方が容易だってことで。

何の話をしてるんだ俺は。

519 ：Name_Not_Found：04/12/08 23:32:11 ID:???

liの中身をfloatにしたやつは誰だ。

520 ：Name_Not_Found：04/12/08 23:37:11 ID:???

俺だ。文句あっか？

521 ：Name_Not_Found：04/12/08 23:41:39 ID:???

個人情報もどこかへfloat。

522 ：Name_Not_Found：04/12/09 00:12:28 ID:???

まさしくflowだな

523 ：Name_Not_Found：04/12/09 00:24:21 ID:???

>>519
でもそうしないとリストの中にリスト入れることができないじゃんか。

524 ：Name_Not_Found：04/12/09 00:25:25 ID:???

definition termとheadingは違うからdlを使った方がよっぽど非Strictになる場合があると思う。

525 ：Name_Not_Found：04/12/09 00:35:31 ID:???

>>524
「違うから」は根拠にならんだろ。
何がどう違うからdlが非Strictになる場合が多いのかを説明すれ。

526 ：Name_Not_Found：04/12/09 00:38:10 ID:???

言語を無限に生成できる限り、どちらも非Strictになるケースは等しく無限大。とか。

527 ：480：04/12/09 00:58:25 ID:???

なんか話がそれてますね。僕の言葉選びの不正確さのせいでしたらすみません。
li+hn+pの具体的な状況を考えてみましたが思いつきませんでした＾＾；
きっとないでしょう。

ところでリストの入れ子はどうでしょう。>>485でもあげましたが
<ul><li>home<ul><li>chapter</ul></li></ul>
これはstrictではないです。homeの下位層にchapterがあるということを論理的にあらわせていません。
homeの下には何もありません。

home
<ul><li>c1<li>c2</ul>

↑こういうマークアップではhomeに続くリストとの関係性は明確ではありません。
仮にdivで括ってもそれはなんらかわりません。liの中だとて当然同じことです。

528 ：Name_Not_Found：04/12/09 01:00:47 ID:???

524じゃないが、
<dl>
<dt>2ちゃんねるイグノーベル賞受賞テロの可能性も</dt>
<dd>8日午後5時20分ひろゆきは2ちゃんねるがイグノーベル賞を受賞したと発表した。...</dd>
...
</dl>
これはあきらかにdefinition termじゃないと思う。

529 ：Name_Not_Found：04/12/09 01:02:09 ID:???

>>527
やはりlabelが欲しいね。

530 ：Name_Not_Found：04/12/09 01:03:12 ID:???

directory list が消滅して ul ol に統一されたことを考えると、
DOM Object や Explorer のファイルツリーのような木構造は
ul の入れ子で表現できるはず、と考えたいところだが。

XHTML2 だと label 要素との兼ね合いも難しいな。

531 ：480：04/12/09 01:38:11 ID:???

>>528
ですがdl要素で問題ないですよ。言葉と用語は違います。
後方互換など色々な要因があって用語は本来の言葉の意味から離れていくこともあります。

532 ：Name_Not_Found：04/12/09 01:40:42 ID:???

誰かわかりやすい翻訳きぼん

533 ：Name_Not_Found：04/12/09 02:05:24 ID:???

dtはdefinition termの略だけど、これは要素名の後方互換性を重視しているために
変更されていないだけで、実際には、dtはそれ以外の用途でも用いることが出来る。

ってことじゃない？

534 ：Name_Not_Found：04/12/09 02:17:23 ID:???

そんな周知の事実持ち出されてもなぁ。
そこんとこは疑いもなく信用しちゃうのに、liが内包したulとの上下関係を疑うのか？

535 ：Name_Not_Found：04/12/09 08:31:13 ID:???

>>527
> homeの下位層にchapterがあるということを論理的にあらわせていません。
だから何？
そのリストの示しているものは、親ulの一つの項目に文字列homeと子ulがあり、
子ul内の項目として文字列chapterがあるというだけの論理的構造であり、
構造が表明しているものとしての意図でリストのネストを使用する限りは
非Strict呼ばわりされる筋合いはない。

それとも、所与の構造が自分の意図した構造を表現できなければ、
所与の構造自体が非Strictだと言うつもりか？

536 ：Name_Not_Found：04/12/09 08:36:17 ID:???

そこでli > hn + ulですよ。
<h1>/</h1>
<ul>
<li>
<h2>home<h2>
<ul><li>chapter1</li><li>chapter2</li></ul>
</li>
</ul>

537 ：Name_Not_Found：04/12/09 09:14:15 ID:???

そのうち、dl+ulとか言い出しそうだな
<dl>
　<dt>/<dt>
　<dd>
　　<ul>
　　　<li>
　　　　<dl>
　　　　　<dt>home</dt>
　　　　　<dd>
　　　　　　<ul>
　　　　　　　<li>chapter1</li>
　　　　　　　<li>chapter2</li>
　　　　　　</ul>
　　　　　</dd>
　　　　</dl>
　　　</li>
　　</ul>
　</dd>
</dl>

538 ：Name_Not_Found：04/12/09 09:17:50 ID:???

label要素ができればこんなかんじか。

<ul>
　<label>/</label>
　<li>
　　<ul>
　　　<label>home</label>
　　　<li>chapter1</li>
　　　<li>chapter2</li>
　　</ul>
　</li>
</ul>

539 ：Name_Not_Found：04/12/09 10:55:08 ID:U0XD1lHu

正直１日２０人しか来ないのにアクセシビリティなんか考慮するの
虚しくなった。しかもサイト内容はゲームのバイナリいじり。
でも１ヶ月調べまくった労力を無駄にしたくないからまだ終わらんよ。(`･ω･´)

以上、愚痴でした。

540 ：480：04/12/09 11:12:58 ID:???

>>535
>それとも、所与の構造が自分の意図した構造を表現できなければ、
>所与の構造自体が非Strictだと言うつもりか？

homeの下位層にchapterがあるということを伝えるマークアップ例の話です。
段落をdivでやったら非stricであると同じレベルであのマークアップは非strictです。
もの凄い基本だと思うのですが・・・・なんで怒ってるのでしょうか＋＋

>>536
hnを使っても駄目ですよ。

541 ：Name_Not_Found：04/12/09 11:44:01 ID:???

>527

>>491を無視すんな。バカなりにかんがえたんだぞ。

542 ：Name_Not_Found：04/12/09 11:52:46 ID:???

480はHTML捨てた方がいいと思うよ。

543 ：480：04/12/09 13:10:30 ID:???

>>541
すみません。いまいち意味が理解できませんでしたm(_ _)m
HTMLのレンダリングのサンプルを紹介という時点で少し・・・・
そもそもHTML使って、HTMLの紹介ってどういうことでしょうか？

>>542
捨てる？XHTMLに移行しろということでしょうか？

544 ：Name_Not_Found：04/12/09 13:40:22 ID:???

まあ、>>538の方法がスマートだろうな。
そのためにXHTML2ではlabel要素が出来たわけだし。

XHTML1.1までなら、>>527の方法が一番スマートだろう。

545 ：Name_Not_Found：04/12/09 16:35:39 ID:???

スマートを基準にするなんてスレ違いにもほどがあるんだがなぁ・・・・・

546 ：Name_Not_Found：04/12/09 17:08:11 ID:???

このスレで、純粋な質問以外で丁寧語を使う奴に
何かしら共通点が見出せそうな気がしてきたな。

547 ：Name_Not_Found：04/12/09 17:10:49 ID:???

>>546
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ

548 ：Name_Not_Found：04/12/09 17:12:03 ID:???

>>547
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ2

549 ：Name_Not_Found：04/12/09 17:14:56 ID:???

>>548
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ3

550 ：Name_Not_Found：04/12/09 17:21:46 ID:???

>>549
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ4

551 ：Name_Not_Found：04/12/09 17:25:45 ID:???

>>550
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ4126

552 ：Name_Not_Found：04/12/09 17:27:22 ID:???

>>547-551
m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ535789801

553 ：Name_Not_Found：04/12/09 17:32:11 ID:MxbJ6Vcd

554 ：Name_Not_Found：04/12/09 17:33:54 ID:???

それで、480に賛同する奴は何人くらいいるんだ？

555 ：Name_Not_Found：04/12/09 19:49:54 ID:???

いくつか言っているから、是々非々だと思うけど。
少なくともリストに label 要素（キャプションでも同じ）が欲しいというのは前から言われていることだけど。

556 ：Name_Not_Found：04/12/09 23:26:42 ID:???

>>544
ディレクトリってラベルなのか？

少なくともUNIXではディレクトリもファイルの一種であって、
ディレクトリと通常ファイルは木構造の途中か末端かの違いだけ。
それが<label>と<li>で異なるマークアップになるのは違和感を
感じるんだが。

557 ：Name_Not_Found：04/12/09 23:31:30 ID:???

>>556
実装上の仕様と、ファイル階層という概念では異なるお話な気がする。
意味的な記述ならラベルにしても問題はないのでは？

558 ：Name_Not_Found：04/12/09 23:35:12 ID:???

例えlabelがあっても、ulのネストで表現されたものは
ただの順序なしリストのネストであって、ディレクトリリストを意図することはできないと。

559 ：Name_Not_Found：04/12/09 23:44:12 ID:???

なぜ？

560 ：Name_Not_Found：04/12/09 23:49:45 ID:???

なぜ、ulのネストを見ただけでディレクトリのリストだと (機械のUAが) 判別できるの？

561 ：Name_Not_Found：04/12/09 23:52:11 ID:???

それをいうなら、リストを見ただけで機械はそれがレシピかなんかわかるわけないです。
あるいは定義リストを見て、それが製品の宣伝だとわかるわけありません。
ディレクトリをどう記述するかと、その記述を機械が判別できるかどうかは別のお話でしょう。

562 ：Name_Not_Found：04/12/09 23:52:46 ID:???

つまりそういうことを言っているに過ぎないんじゃ。

563 ：Name_Not_Found：04/12/10 00:01:54 ID:???

XHTML1.1でディレクトリを記述するには、>>527しかないのか？

564 ：Name_Not_Found：04/12/10 00:19:25 ID:???

565 ：Name_Not_Found：04/12/10 01:14:57 ID:???

お、また新しい語彙が。誰かスキーマきぼん。

566 ：Name_Not_Found：04/12/10 01:50:12 ID:???

nodeとleafが別物で構成される木構造ばかりとは限らない。例えば
男系家系図を考える。（別に女系でもいいが）
父の名前に対してその息子の名前がつながる木構造になるが、これだと、
たまたま息子がいる人はnodeで、いなければleafになる。でも両者には
それ以外の違いがあるわけではない。単にこの木構造を表したいだけなら、
息子がいるかどうかで別の要素になるのは変な感じがする。

567 ：Name_Not_Found：04/12/10 07:06:56 ID:???

それは実装依存。
データ構造と視覚表現が一致する必要もないし。

568 ：Name_Not_Found：04/12/10 07:24:57 ID:???

leafをやめて全部nodeにするとか。

569 ：Name_Not_Found：04/12/10 08:56:09 ID:???

>>566
それぞれのnodeの終端をleafで示すことができる。

570 ：Name_Not_Found：04/12/10 14:25:21 ID:s/IPcwvb

カレンダーを作るのって画像にすべきでしょうか？
それともtable要素で作るべきでしょうか？
縦が曜日で横が第何週とかにすればいける気がしますが、意見聞かせてください。

571 ：Name_Not_Found：04/12/10 14:34:54 ID:???

>>570
tableでいいと思った。
空欄をどうするか、かも。

572 ：Name_Not_Found：04/12/10 16:56:35 ID:???

http://contest2004.thinkquest.jp/tqj2004/70416/
是にXSLT

573 ：Name_Not_Found：04/12/10 18:47:01 ID:???

>>571
空欄も空欄という情報が埋め込まれてるんだということでいいんじゃない？
第１週の日曜が空欄ってのは論理的であると思うよ。

574 ：Name_Not_Found：04/12/10 20:51:59 ID:???

前の月と次の月の日付を入れる。

575 ：572：04/12/10 21:25:56 ID:???

普通にurl間違えた
http://www.kanzaki.com/docs/sw/rdf-calendar.html

576 ：Name_Not_Found：04/12/10 21:34:12 ID:???

カレンダーの空欄って、前月・次月ぶんが非表示になっているだけ、
って解釈している漏れはまちがい？

577 ：576：04/12/10 21:34:35 ID:???

だからあれほどリロードしろと…orz

578 ：Name_Not_Found：04/12/11 07:09:37 ID:???

>>576
<hn>12月のカレンダー</hn>

579 ：Name_Not_Found：04/12/11 09:15:58 ID:???

しかしカレンダーとかで「色が濃いとこが祝日です」なんてのは思いっきり非strictなんだろうろう。

580 ：Name_Not_Found：04/12/11 09:51:09 ID:???

｢祝日はスタイルを変えています。｣とかも非strict?

581 ：Name_Not_Found：04/12/11 10:54:02 ID:???

強調部分が祝日です

582 ：Name_Not_Found：04/12/11 11:48:41 ID:???

583 ：Name_Not_Found：04/12/11 12:23:46 ID:???

>>580
当然
>>581-582
やっぱその程度しかHTMLではできないよな。
title使えばもう少しマシか？

584 ：Name_Not_Found：04/12/11 15:48:59 ID:???

class="saturday"は土曜です。
とか
<col id="saturday">
として
<a href="#saturday">土曜日</a>
とか。

585 ：Name_Not_Found：04/12/11 17:16:12 ID:???

お前らHTMLは意味をマークアップするわけではないぞ。
しっかりしてくれ。

586 ：Name_Not_Found：04/12/11 17:27:34 ID:???

？

587 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/11 18:27:47 ID:3zug8s7t

HTMLは文書のマークアップだ。そんなことも知らなかったか？

588 ：Name_Not_Found：04/12/11 18:35:35 ID:???

自演きました(*ﾟ∀ﾟ)=3

589 ：Name_Not_Found：04/12/11 18:40:46 ID:???

要は「Saturday」とかは個別の意味依存だから使うなってことでしょ？

590 ：Name_Not_Found：04/12/11 20:25:33 ID:???

classに意味のある文字列を使用するかどうかは著者に依存する

591 ：Name_Not_Found：04/12/12 03:50:00 ID:???

classに意味がある文字列を使用されているかどうかは著者に依存する

意味がある文字列かどうかは気分によって変わる

classに実質有意義な意味は無い

592 ：585：04/12/12 04:51:24 ID:???

お前ら本気で勘違いしてるのか？
HTMLは構造を表すだけで、文章の意味を機械に理解させるものではないぞ。
少しは仕様書を嫁よ。

593 ：Name_Not_Found：04/12/12 05:02:50 ID:???

新しいﾃﾞﾑﾊﾟが沸いてきた

594 ：Name_Not_Found：04/12/12 09:36:14 ID:???

>>592
>589で違うとしたら、誰がそんな勘違いをしているというのか。

595 ：585：04/12/12 10:49:23 ID:???

>>594
？？？
>>589は明らかに仕様書を読んでないだろ。

俺はカレンダー云々から始まった、文章の意味まで機械に理解させようと
議論してる人に対して、HTMLはそういうものではないといってるのだが？

596 ：Name_Not_Found：04/12/12 10:53:32 ID:???

？？？

597 ：Name_Not_Found：04/12/12 10:57:11 ID:???

>>595
>>589は「>>585が言いたい事はこういうことでしょ？　だからなに？」と言ってるだけだろ。
読解力身につけろようぜーな。

598 ：Name_Not_Found：04/12/12 10:58:17 ID:???

>>585
混乱が広がるだけだから、
具体的にレス番つけてどこがどう違くてどうすればいいのか指摘しろ。

599 ：Name_Not_Found：04/12/12 11:00:15 ID:???

>>598
できるわけないだろ。一人の意見＝スレ住人の総意と思い込むタイプなんだから。

600 ：Name_Not_Found：04/12/12 11:07:10 ID:???

>>570-591
>>585
>>589
>>595

601 ：Name_Not_Found：04/12/12 11:07:43 ID:???

>>597
>>595によれば>>589の指摘したことと>>585の言いたかったことは全然違うらしい。

602 ：Name_Not_Found：04/12/12 11:10:06 ID:???

>>595
> 文章の意味まで機械に理解させようと
> 議論してる人に対して、HTMLはそういうものではないといってるのだが？
そんなやつがどこにいるのか、と問われてる。
いないの人にツッコミを入れたから、「ひょっとして、これに突っ込んでるの？」と言われる。当然の流れ。

603 ：Name_Not_Found：04/12/12 11:12:18 ID:???

このスレに入ってから「機械に意味を理解させる」関連で引っ張るな…。

604 ：Name_Not_Found：04/12/12 11:16:04 ID:???

>>603
引っ張ってないって。>>585が「そういう話題だ」って勘違いしただけ。
セマンティックにするにはこれはマズイな、って話が出てただけ。
「人」に「認識」してもらうための「記述」について。

605 ：585：04/12/12 11:38:21 ID:???

凄いな。

>>597
不快にさせてすまん。

606 ：Name_Not_Found：04/12/12 11:42:14 ID:???

>>605
ちなみに、だ
仮に「機械に意味を理解させる」という話が出てたとしても、

「HTMLは意味をマークアップするわけではないぞ。」はおかしい。

607 ：585：04/12/12 11:59:41 ID:???

>>606
どうおかしいの？

608 ：Name_Not_Found：04/12/12 12:05:21 ID:???

>>607
意味をマークアップせずに何をするつもりだよ

609 ：Name_Not_Found：04/12/12 12:07:35 ID:???

また変なのが来たな・・・・

610 ：Name_Not_Found：04/12/12 12:28:13 ID:???

久しぶりにのぞいたら結構人がいるんだね。

少し趣旨が違うんだけど、このスレの住人はデザインとかも自分でやってるの？

611 ：Name_Not_Found：04/12/12 13:01:39 ID:???

少しどころか思いっきり趣旨が違うな

612 ：Name_Not_Found：04/12/12 13:08:00 ID:???

くそ腹立つ

613 ：Name_Not_Found：04/12/12 13:24:02 ID:???

>>607
多分、もまいの言いたいことは、「HTMLで意味づけを与えることはできない」とかそういうことだろうけどな。
しかし、それだったとしてもおかしい。

少しは仕様書を嫁よ。という言葉ははわが身に降りかかる、という寸法だな。

614 ：585：04/12/12 13:51:03 ID:???

>>613
どうおかしいのかはいつになったら答えてくれるのかな？

何か本域でHTMLの解釈が間違ってるみたいだけど、例えばstrong要素について言えば、
強調という文書構造をあらわすのであって、文章の意味自体を伝えるものではないんだよ。

615 ：Name_Not_Found：04/12/12 13:54:16 ID:???

>>614
おまえから答えろよ。>>598

616 ：Name_Not_Found：04/12/12 14:02:46 ID:???

>>614
は？
＞強調という文書構造をあらわすのであって、文章の意味自体を伝えるものではないんだよ。
と
＞HTMLは意味をマークアップするわけではないぞ。
は意味が違うだろ。摩り替えんなｳﾞｫｹが

617 ：Name_Not_Found：04/12/12 14:23:14 ID:???

文章の意味、ってなんだ？　勝手に定義して否定するってなんなんだろうね。
strong要素は585の言うように、強調という「文書構造をあらわす」のであって、
そのマーク付けされた文字列が強調であると「意味づける」んじゃねえの？

こいつの文章は飛躍しまくってるから、「こいつが何をどう勘違いしているのか」すらわかりにくいな。

618 ：585：04/12/12 14:30:55 ID:???

>>615
誰？
>>616
同じだよ。HTMLは意味をマークアップするわけではない。
>>617
屁理屈？

何か同じ人が暴れてるだけのような気がするが、とりあえずこれだけは勘違いしないほうがいいよ。
HTMLは意味をマークアップするものではない。

619 ：Name_Not_Found：04/12/12 14:36:32 ID:???

(･∀･)ﾆﾔﾆﾔ

620 ：Name_Not_Found：04/12/12 14:37:43 ID:???

(･∀･)ﾆﾔﾆﾔ

621 ：Name_Not_Found：04/12/12 14:39:29 ID:???

(･∀･)ﾆﾔﾆﾔ

622 ：Name_Not_Found：04/12/12 14:41:13 ID:???

(･∀･)ﾆﾔﾆﾔ

623 ：Name_Not_Found：04/12/12 16:22:37 ID:???

まじめに議論しているのに笑えるのはなぜか

624 ：Name_Not_Found：04/12/12 17:20:25 ID:???

>>623
ここはお前の日記じゃないんじゃボケ

625 ：Name_Not_Found：04/12/12 17:27:09 ID:???

>>624
お前の日記でもないわ

626 ：Name_Not_Found：04/12/12 17:29:52 ID:???

>>625
ハァ？俺のもんじゃボケェ

627 ：Name_Not_Found：04/12/12 17:30:48 ID:???

いや、まて。もしかしたら漏れのかもしれないぞ

628 ：Name_Not_Found：04/12/12 17:53:11 ID:DfZ9cpqs

困った。最終更新日には何のタグを使えばいいと思う？

629 ：Name_Not_Found：04/12/12 18:11:15 ID:???

>>628
dl or hn+p

630 ：Name_Not_Found：04/12/12 18:32:33 ID:???

address だろ。普通は。 p でも許す。

631 ：Name_Not_Found：04/12/12 18:34:41 ID:???

>>630
同じく！

632 ：Name_Not_Found：04/12/12 18:37:49 ID:???

>>617
相手にしない方がいいよ。>>598の質問から逃げまくってるし。

633 ：628：04/12/12 19:14:04 ID:DfZ9cpqs

ありがとん！

634 ：Name_Not_Found：04/12/12 19:34:08 ID:???

>>628
ins:before{content:"最終更新日:" attr(datetime)}

635 ：Name_Not_Found：04/12/12 22:10:35 ID:???

>>634
それもいいが、IE では使えんな

IE(ﾟ⊿ﾟ)ｲﾗﾈ

636 ：Name_Not_Found：04/12/12 22:14:08 ID:???

insが最終更新とは限らない罠。

637 ：Name_Not_Found：04/12/12 22:22:15 ID:???

最終更新日単独をaddressってありなのか？
問合せ先と一緒に最終更新日も入れてる例文は確かにあるから悪いとはいえないけど。

過去の更新履歴とかはどうなるんだ？

638 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/12 22:25:42 ID:c6pploPD

class="lastupdate"とか。クラス名をつけるのもありかと。

639 ：Name_Not_Found：04/12/12 22:28:21 ID:???

更新履歴と最終更新日は違うじゃん。
更新履歴はそれ自体が内容だが、
最終更新日は文書の付加情報だし。

640 ：Name_Not_Found：04/12/12 22:46:00 ID:???

ins.lastupdate:before{content:"最終更新日:" attr(datetime)}

641 ：Name_Not_Found：04/12/12 22:51:47 ID:???

いや、>>629-635 は適切な class をつけること前提だろ。

642 ：Name_Not_Found：04/12/12 23:02:31 ID:???

どの要素に入れるかが問題なんだから、
class付ける付けないは関係ないべさ

643 ：Name_Not_Found：04/12/12 23:11:04 ID:???

644 ：Name_Not_Found：04/12/12 23:11:53 ID:???

文書自体のステータスを本文内に入れてもいいという立場なら、結局>>629が穏当というか。

645 ：Name_Not_Found：04/12/12 23:11:55 ID:???

>>641
classに適切もくそもあるか。
ここは制作者の自己満足マークアップについて話すスレじゃないだろ？

646 ：Name_Not_Found：04/12/12 23:12:58 ID:???

>>645
流れ嫁

647 ：Name_Not_Found：04/12/12 23:14:43 ID:???

適当な要素のないところに無理やり当てはめるのと、
勝手なclass名で識別するのとは、同次元な気がする。

648 ：Name_Not_Found：04/12/12 23:21:53 ID:???

>>647
最終更新日の話してんならaddressが適当な要素だと思うが。

649 ：Name_Not_Found：04/12/12 23:30:12 ID:???

>>645の言い分は正しい。

650 ：Name_Not_Found：04/12/12 23:31:16 ID:???

641の補足は645の主張に何ら反していないと思うけど？

651 ：Name_Not_Found：04/12/12 23:31:53 ID:???

結局、address内部でspan class="modified"みたいなことをするしかないと。
もしくはdlやtableで文書のステータス一覧をやるみたいな。

652 ：Name_Not_Found：04/12/12 23:34:00 ID:???

>>650
classは作者だけの識別子

653 ：Name_Not_Found：04/12/12 23:37:08 ID:???

>>652
それが何か？
まさか、文書に登場し得るあらゆる内容に
漏れなくかつ一対一に対応するように要素を作れと？
XML……

654 ：Name_Not_Found：04/12/12 23:47:23 ID:???

<h2>この文章のステータス</h2>
<dl>
　<dt>最終更新日</dt>
　<dd>2004-12-12T23:46:21+09:00</dd>
　<dt>公開日</dt>
　<dd>2004-10-12T23:46:21+09:00</dd>
</dl>

addressの内容こそflowにするべきだな。

655 ：Name_Not_Found：04/12/12 23:48:01 ID:???

class使って拡張語彙が使えるような仕様をW3Cが作ってくれないかなあ…

656 ：Name_Not_Found：04/12/12 23:48:07 ID:???

普通にbrでいいやん。他に使い道ないし。

657 ：Name_Not_Found：04/12/12 23:49:00 ID:???

>>655
divかspan
あるいはXML→XSLT

658 ：Name_Not_Found：04/12/12 23:50:56 ID:???

>>655
なんでclassで語彙拡張するんだ。名前空間使えばいいじゃないか。
DTD捨てることから始めた方がよさげ。

659 ：Name_Not_Found：04/12/13 00:35:45 ID:???

>>657
> あるいはXML→XSLT
XHTMLに変換するんだったら同じだよなあ…。

>>658
色々と問題が。名前空間混合文書についての:
1. 困難な内容モデル作りと妥当性検証 (n個の名前空間につき、((n*n-1)/2)個の内容モデルが必要)
2. メディアタイプとフラグメント識別子 (application/xmlのfragidの役割は未定義)
3. 異なる名前空間にある要素間のセマンティクス (RDFを使えば楽できそうだが…どのように組み込むのか)
を解決・策定・定義しないといけない。

660 ：Name_Not_Found：04/12/13 00:42:42 ID:???

まあ、それを言ったらclass使っても同じ問題があったりするわけで。

661 ：Name_Not_Found：04/12/13 00:43:31 ID:???

>>660 += あるいは、そこまで問題視する必要のないことも。

662 ：Name_Not_Found：04/12/13 00:51:20 ID:???

>>656
> 普通にbrでいいやん。他に使い道ないし。
何が？

663 ：Name_Not_Found：04/12/13 00:54:56 ID:???

585にセマティックウェブの意味を説明してもらいたい。

664 ：628：04/12/13 01:00:57 ID:YV/N9Sjq

みんなサンキュー。
結局address使いますた。
他のは自分のレベルが低すぎて
何書いてるのかわからんかった。
（classはわかるけど何か違う気がする）

665 ：Name_Not_Found：04/12/13 01:46:44 ID:???

666 ：Name_Not_Found：04/12/13 01:56:43 ID:???

667 ：Name_Not_Found：04/12/13 10:28:52 ID:???

>>651
>結局、address内部でspan class="modified"みたいなことをするしかないと。

こういう書き方が変な突っ込みをしてくるやつを生む素になってるんじゃないかな？
spanまででやめて、classについては触れない方がいいと思う。
span class="modified"まで書くと、まるでclassの値で最終更新日ということを
伝えられるように聞こえる。

668 ：Name_Not_Found：04/12/13 10:31:41 ID:???

>>667
なるほど。
当人は「spanじゃ無理、と指摘された」と感じ、
指摘者は「classで与えれる、と固持されてる」と感じるわけだ。

669 ：Name_Not_Found：04/12/13 11:03:29 ID:???

じゃあどうすればよいかって言わない香具師はたいてい荒れる原因になってる

670 ：Name_Not_Found：04/12/13 11:09:40 ID:???

>>669
>>667はいってるみたいだけど

671 ：Name_Not_Found：04/12/13 12:01:53 ID:???

そもそも最終更新日の内容自体が機械に伝えるべきことであるなら、
addressでやっても無意味だろ。

機械に「このデータは最終更新日です」てことを伝えるにはずばりで示さなきゃね。
まあmetaだろうね。

672 ：Name_Not_Found：04/12/13 12:05:23 ID:???

そもそも？
何で最終更新日は人間に伝えるべきものでないと思うの？

673 ：Name_Not_Found：04/12/13 15:21:25 ID:???

「最終更新日は機械に伝えるべきことである」と
「最終更新日は人間に伝えるべきものではない」って
全然違うことを言ってる気がするんだけど……

674 ：Name_Not_Found：04/12/13 15:45:32 ID:???

>>673
もしそうなら「addressでやっても無意味」はおかしい

675 ：Name_Not_Found：04/12/13 16:04:10 ID:???

そもそも、最終更新日はHTTPヘッダから取得できるんじゃ……？
それを訂正するならmetaじゃないの？

あれ？

676 ：Name_Not_Found：04/12/13 16:10:35 ID:???

著者、コピーライト、ナビゲーション、最終更新日…
meta *でも* 書けるからといって本文に書いていけないわけじゃないだろ。
何か勘違いしてるんじゃないの？

677 ：Name_Not_Found：04/12/13 16:13:22 ID:???

パンくずリストにはどの要素を使えばいい?単にPだとどうかと思うんだけど

678 ：Name_Not_Found：04/12/13 16:14:23 ID:???

ひさびさにパンくず来たな。
p、ul、olが有力だな。

679 ：Name_Not_Found：04/12/13 16:18:13 ID:???

パンくずリストって、パンくず？ぱんくず？ぱんクズ？パン屑？ぱん屑？麺麭屑？

680 ：Name_Not_Found：04/12/13 16:54:19 ID:???

>>679
<ul>
<li>パンくず</li>
<li>ぱんくず</li>
<li>ぱんクズ</li>
<li>パン屑</li>
<li>ぱん屑</li>
<li>麺麭屑</li>
</ul>

681 ：Name_Not_Found：04/12/13 16:59:48 ID:???

>674
釣れますか？

682 ：Name_Not_Found：04/12/13 17:02:26 ID:???

本当に知りたいなら過去スレみるのが早いよ。
「パンクズ」とかで検索すれば一通りの考え方が出てくる。

ちなみに俺は

<ol>
<li>home
<li>chapter
<li>section
</ol>

でやってる。道順という意味でね。

683 ：Name_Not_Found：04/12/13 17:10:06 ID:???

>>676
最終更新日の機械への伝え方を議論していたわけではないのですね……。

失礼しました（＾＾；

684 ：Name_Not_Found：04/12/13 17:21:49 ID:???

ほんと失礼ね。

685 ：Name_Not_Found：04/12/13 17:43:10 ID:???

<p>
ぬるぽ
<div class="foo">ガッ</div>
ぬるぽぬるぽぬるぽ
<div class="foo">ガッx3</div>
</p>
って書くと、
ぬるぽ

ガッ
ぬるぽぬるぽぬるぽ
ガッx3
みたく表示されるんだけど、1個目のdivのとこだけスペースが無駄に開くのは何でかな?NNとFirefoxでこうなった

686 ：Name_Not_Found：04/12/13 17:48:28 ID:???

えー俺の記憶によれば p の中に div は書かない方がいいと思ったけど…

687 ：Name_Not_Found：04/12/13 17:49:09 ID:???

>>685
http://pc5.2ch.net/test/read.cgi/hp/1102926391/

688 ：Name_Not_Found：04/12/13 18:18:57 ID:???

なんか最近馬鹿が居ついてないか？

689 ：Name_Not_Found：04/12/13 18:20:22 ID:???

誤爆でしょう。

690 ：Name_Not_Found：04/12/13 19:34:48 ID:???

>>688が馬鹿

691 ：Name_Not_Found：04/12/14 01:03:56 ID:???

>>686
divに生テキストは「書かない方が」と言われるけど、pにdivは「書かない方が」じゃなくて、「書けない」では？

692 ：Name_Not_Found：04/12/14 02:10:36 ID:???

>>685とか見るともうなんかこのスレ面倒
みんな死ねよ
俺は生き残るからさ

693 ：Name_Not_Found：04/12/14 07:27:27 ID:???

何を子供みたいなことを。

694 ：Name_Not_Found：04/12/14 10:00:08 ID:???

>>692
明らかなスレ違いを真に受けるなよ。
っていうか別に面倒ならお前が消えろよ。粘着はうざい。

695 ：Name_Not_Found：04/12/14 11:21:14 ID:???

最近機械に伝える云々が流行ってるみたいだけど、HTML4.01策定時には
セマンティックウェブなんてのはまだないぞ。

お前ら何のためにstrictDTDがあるか本当にわかってる？

696 ：Name_Not_Found：04/12/14 11:22:51 ID:???

>>695
>最近機械に伝える云々が流行ってるみたいだけど
誤解。一人が吠えてるだけ。

＞HTML4.01策定時には
＞セマンティックウェブなんてのはまだないぞ。
日本人がこの世に誕生したときには
和服なんてのはまだないぞ。

697 ：Name_Not_Found：04/12/14 13:00:06 ID:???

>>695
機械に云々はどうでもいいけど、一応揚げ足。
RDFの旧仕様 (RDFMS) が勧告になったのはHTML4.01勧告より前。
当然、Semantic Web自体の研究はもっと前からあったということね。

698 ：Name_Not_Found：04/12/14 13:08:14 ID:???

>>695
またおまえか。

699 ：Name_Not_Found：04/12/14 16:05:57 ID:???

今更だが、585は構文論とか意味論とかを知っていて、
厳密な意味で構造とか意味とかいう単語を使う人ですね？
大概の人はどっちの単語ももっと大雑把に使うので、
用語の調整抜きで話が噛み合うわけないです。

というか、しょうもない話題のときは伸びるな、このスレ。嬉しい。

700 ：Name_Not_Found：04/12/14 16:31:19 ID:???

585=699
自演乙

701 ：Name_Not_Found：04/12/14 20:05:08 ID:???

>>696
だから何？セマンティックウェブはHTML4.01の服じゃないんだけど・・・
マジでお前らHTML4.01の本来の役割を理解できてないの？
もしかしてXHTMLと同じ感覚で考えてないか？

702 ：Name_Not_Found：04/12/14 21:59:58 ID:???

しつこいな。

703 ：Name_Not_Found：04/12/14 22:33:40 ID:???

>701
同じですが何か？

704 ：Name_Not_Found：04/12/15 01:05:31 ID:???

>699
的外れ
>700
おめでてーな
>701
ごめん、理解できてない

705 ：Name_Not_Found：04/12/15 10:31:35 ID:???

何のためのHTML4.01なのかすら理解できてないって、ここの住人のレベルも相当下がったんだな。
せめてセマンティックウェブとHTMLをごっちゃにするなよ。

ほんとアホばっかだな・・・・

706 ：Name_Not_Found：04/12/15 11:00:22 ID:???

で、セマンティックウェブが流行ってるのと（>>695の最初の文ね）、
それとHTML4.01が全然関係ないものだとして、それが何よ？

707 ：Name_Not_Found：04/12/15 11:14:43 ID:???

えー、まず、セマンテックウェブという構想は現在のインターネットが誕生した当初から、
研究者の頭の中にありました。Timに聞いてみてください。
リソースが互いに協調し、ウェブ自身が意味を自動的に作り出していくような構想です。

最近ではRSSの流行と、その土台となっているRDFなんかが注目されていますが、
必ずしもRDFのみがセマンテックウェブの構成要素ではありません。

HTMLもまた、セマンテックウェブを目指すための一つの部品です。
HTMLにおいては、良く構造的され、機械が理解しやすい文章がセマンテックウェブの
観点から望まれます。つまり、StrictなHTML文章はそれだけセマンテックウェブの
構成部品としては品質が高い、と言えそうです。

で、>>695は何がいいたかったんだろうな。

708 ：Name_Not_Found：04/12/15 11:26:18 ID:???

> Timに聞いてみてください。
ﾜﾛﾀ
去年、ティムたんが講演に来てから、もう一年も経つんだねえ。

709 ：Name_Not_Found：04/12/15 12:32:34 ID:???

だから、揚げ足とったり問いかけたりしながら、
他の解決策しめしたり自分の意見言わない香具師は荒らしなんだって。
ここしばらく居座ってちょっかい出しに来てるじゃん。

710 ：Name_Not_Found：04/12/15 12:55:06 ID:???

>>709
誰に言っているんだ？

711 ：Name_Not_Found：04/12/15 16:05:08 ID:???

「HTMLバージョン情報」と「ドキュメントタイプ宣言」言葉としてはどっちを使うべきかな?

712 ：Name_Not_Found：04/12/15 16:15:53 ID:???

>>710
705みたいなアホは相手にすんなってことだろ。
「HTML4.01は～のためのものだから、セマンティックウェブの～とは異なるため、～」
と自分の主張を明らかにしてレスしないと話にならない。

713 ：711：04/12/15 16:25:09 ID:8FrYgcjB

あげとく

714 ：Name_Not_Found：04/12/15 16:27:57 ID:???

よくわかんないけど、HTML4.01って何のためにあるの？
漏れはずっとセマンティックウェブの発展を後方互換しながらやっていくためのものだと思ってた。
だからHTML5がでないとか妄想してたんだけど＾＾；

715 ：Name_Not_Found：04/12/15 17:01:33 ID:???

セマンティックWeb、どこまで現実的なのかイマイチわからん。
以前、研究開発系の仕事でそれっぽい事やったがオントロジ(?)にあたる部分の記述が
本当に大変だった。

716 ：Name_Not_Found：04/12/15 17:10:23 ID:???

しかしセマンティックwebって実現したら本当に便利なのか？
ん？いや、そりゃ便利だろうけどさ。
あまり進むと情報規制も簡単にできちゃうんでしょ？

717 ：Name_Not_Found：04/12/15 17:34:38 ID:???

>>711
どっちでもいい。あと、ここは質問スレじゃないから回答待ちでageたりしなくてよいよ。

>>714
漏れもそう思ってる。今までのものも非推奨ながらフォローしつつ、の一応の完成形、と。

718 ：Name_Not_Found：04/12/15 18:03:59 ID:???

セマンティックWebは、インテリジェント・エージェントみたいな結末になる予感。

719 ：Name_Not_Found：04/12/15 18:32:09 ID:???

こういう技術はある種の宗教ですな（悪い意味じゃなくて）。
セマンティックWebは非常に限定されたロケーションでは使われると思う。
ただし、それは標準化そっちのけで方言を生み出す要因にもなるけど。

720 ：Name_Not_Found：04/12/15 19:08:19 ID:???

うーん、>>718-719みたいな誤解はやはり、
Semantic Webに対する過度な期待先行が原因なんだろうなあ。
実際にはそんな大したものじゃないんだけど。
とはいえそろそろスレ違いの感。

721 ：Name_Not_Found：04/12/15 19:09:59 ID:???

>Semantic Webに対する過度な期待先行が原因なんだろうなあ。

( ;ﾟдﾟ)

722 ：Name_Not_Found：04/12/15 19:17:54 ID:???

|・∀・)

723 ：Name_Not_Found：04/12/15 19:24:55 ID:???

セマンテックな方面については専用スレもあるからそっちもよろしく
http://pc5.2ch.net/test/read.cgi/hp/1057681807/
http://pc5.2ch.net/test/read.cgi/php/1078216600/

今のところ、FOAFとかRSSとかの関連づけが結構面白いね。

>>714
HTML5が出ないのはXHTML2.0が出る予定だからでしょ。
SGMLベースってことで今のところHTML4.01も残ってるけど、
HTML2.xみたいに、そのうち破棄されるんじゃないかな。
もっとも2.xとちがって莫大な量の文章があるから、
永遠に残る可能性も十分ありそうだが。

724 ：Name_Not_Found：04/12/15 20:26:01 ID:???

>>723
まあ、もともと仕様に準拠していない大半の遺産は、
仕様が破棄されても問題なく存在しつづけるよね。

725 ：BlackLightOfStar ◆ifsBJ/KedU ：04/12/15 20:36:17 ID:SOknZ/+H

この際、IEかNNに合った仕様書を作るというのはどうだろう？
とんでもない手間がかかりそうではあるが。

726 ：Name_Not_Found：04/12/15 22:31:08 ID:???

あんまり下らないんで欠伸と屁が同時に出たよ

727 ：Name_Not_Found：04/12/16 00:29:04 ID:???

>>725
King、現実を見ようよ。そしてもうちょっと勉強しようね。
お前、２ちゃんに入り浸りすぎなんだよ。数学もっと勉強汁。

728 ：Name_Not_Found：04/12/16 11:55:42 ID:???

>>727と>>725は友達同士か？

729 ：Name_Not_Found：04/12/16 11:59:39 ID:???

>>728
それはどうか知らんが、同じ匂いがするね。

730 ：Name_Not_Found：04/12/16 17:37:39 ID:???

>>727
>>725をうんざりするほど見てるお前に>>727

731 ：Name_Not_Found：04/12/16 17:43:09 ID:???

>>728-730
数学板逝ってみろよ
うんざりするほどいるよ

732 ：Name_Not_Found：04/12/16 18:56:06 ID:???

>>731
このスレ以外見ないことにしてる
ここなら一日に３回くらい覗くだけでいいし、仕事に悪影響が出ることはない。
他の人が多いスレにはまると仕事中にも見たくなって困るんだよな。

スレ違いでごめん＾＾；

733 ：Name_Not_Found：04/12/16 19:14:45 ID:???

＾＾；

734 ：Name_Not_Found：04/12/17 00:33:42 ID:???

>>732
随分不健康な趣味ですね…＾＾；

735 ：Name_Not_Found：04/12/17 11:13:30 ID:???

>>734
人の振り見て我が振りなおせ^^;

736 ：Name_Not_Found：04/12/17 16:12:29 ID:???

http://www.kanefuku.co.jp/shopmall/mentaitsu/list_item.php?cateid=4

このサイトの商品一覧表ってこのスレ的にはどうやってコーディングするべき？
「表」だけどtableではないっていうのはまあいいんだけど、dlやliの中でごちゃごちゃ
するのもtableと同じくらいピントがずれてる気がする。

一応俺としては
<table>
<tr><th>商品写真<th>商品名<th>商品番号<th>価格<th>備考
<tr>...
</table>

ってやってCSSで整形するのが最もstrictであると思う。もちろんIEでは不可能だけど、
それは無視としてね。

みんなはどうやる？

737 ：Name_Not_Found：04/12/17 16:22:26 ID:???

あまりに繰り返しすぎでレスする気にもならん

738 ：Name_Not_Found：04/12/17 20:17:14 ID:???

>>737
あまりに繰り返しってお前は・・・
適当に卒業しろよ。

739 ：Name_Not_Found：04/12/17 21:22:08 ID:???

なんでいつもこのサイトなのさ。

740 ：Name_Not_Found：04/12/17 22:53:54 ID:???

どうせコピペだろ

741 ：Name_Not_Found：04/12/18 11:10:11 ID:???

>736
誰も回答しないようなので暇な俺がしよう。

<table summary="商品一覧表">
<tr><th scope="row">明太子Ａ</th><th scope="row">明太子Ｂ</th><th scope="row">明太子Ｃ</th></tr>

これだけでわかるだろ。まあ初心者とかstrictに移行したての人間は勘違いしやすいところだが、
こういう明らかなる表は一応tableでも問題ない。

テーブルレイアウトという言葉は表でもないものをtableで整形する行為であって、
対称が表である限りtableを使っても非strictにはならず。

視覚整形をしたものが表であり、しかし視覚整形目的のみでtableを使ってはいけない。
ってことだ。

742 ：Name_Not_Found：04/12/18 11:19:37 ID:???

>>739
こいつ馬鹿

743 ：Name_Not_Found：04/12/18 13:05:26 ID:???

俺？

744 ：Name_Not_Found：04/12/18 13:21:07 ID:???

スレ違い、と誘導されました。アドバイスお願いします
ページ送り？なのですが、現在下記のようにしています
<dl>
<dt>Page</dt>
<dd>
<a href="">1</a>
<a href="">2</a>
<a href="">3</a>
</dd>
</dl>
で、display: inlineで「Page 　　　1 2 3」
のように表示させているのですが、上のように「Page」と「1」との間が開いてしまいます
この部分を埋めたいのですが、どのようにしたらよいでしょうか？(1)
それとも、Pageの部分を<h>か何かにして、<ul><li>でやったほうがよいのでしょうか？(2)
というか、ページ送りにはどちらもそんな風に使わないのでしょうか？(3)

745 ：Name_Not_Found：04/12/18 14:38:14 ID:???

>>744
たらい回しで悪いがCSSなら
http://pc5.2ch.net/test/read.cgi/hp/1101827958/
で質問すると良い。

HTMLな部分に関しては、link要素をつかうか、
dl-dt-ddが妥当じゃないかな。

746 ：Name_Not_Found：04/12/18 18:55:47 ID:???

>>745
普通にli要素だろ。いきなり何ボケてんだ？

747 ：745：04/12/18 19:03:12 ID:???

>>746
「Page」の部分はどうするんだ？
ナビゲーションにhnなんてつかうほどじゃないだろ。

・・・あ、ddの中身はul-liにしなきゃだめだな。

748 ：ぷー太郎：04/12/18 19:07:41 ID:???

HTML4.01 StrictのDTDでページを作っているのですが、
ファイル形式が「．php」だとしても、何か影響があると言う事はないのですか？

749 ：Name_Not_Found：04/12/18 19:13:59 ID:???

拡張子はHTMLには直接関係ない。
PHPならデフォルトで
header("Content-Type: text/html");
な感じだから大丈夫。

750 ：Name_Not_Found：04/12/18 21:52:12 ID:???

>>748
そこはもうちょっと頑張って、拡張子無しでやるべき！

751 ：Name_Not_Found：04/12/18 23:06:36 ID:???

>>741
あれは表じゃなくて、商品を横4列に並べるためのレイアウトテーブルだと思うが?
TH が存在しないことが何よりの証。

752 ：Name_Not_Found：04/12/18 23:18:17 ID:???

レイアウトを「表にしたくて」使ってんだから問題ないだろ。

753 ：Name_Not_Found：04/12/18 23:23:28 ID:???

>>752
そういう詭弁は他所でやっとくれ。

754 ：ぷー太郎：04/12/19 00:06:44 ID:???

>>750
拡張子無しとはどう言う事ですか？
実際にどうやるんですか？

755 ：Name_Not_Found：04/12/19 00:09:24 ID:???

>>754
それについてはこちらで。

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

756 ：Name_Not_Found：04/12/19 00:13:07 ID:???

>こういう明らかなる表は一応tableでも問題ない。
>対称が表である限りtableを使っても非strictにはならず。
「一応」とか「使っても」とかって。。。
「明らかな表」は「一応」じゃなくて「必ず」table。

757 ：Name_Not_Found：04/12/19 07:47:41 ID:???

一対一、ないし、一対多の対応のあるデータ群を羅列する場合は、
必ずtableでしょうか？

758 ：Name_Not_Found：04/12/19 08:56:22 ID:???

>>757
もしそれが真なら、DL なんかは存在意義を失うことになるわけだが。
TABLE 用途の基本は多対多じゃないか?

759 ：Name_Not_Found：04/12/19 09:08:25 ID:???

>>756
仕様書嫁。表＝tableじゃない。

760 ：Name_Not_Found：04/12/19 10:06:05 ID:???

>>759
w3cなんてクソ

761 ：Name_Not_Found：04/12/19 10:18:51 ID:???

>>757
心配するな「明らかな表」と言ってるのにtebleでもいい、と言った事にツッコミを入れてるだけだから。

762 ：Name_Not_Found：04/12/19 12:29:24 ID:???

>>759
またおまえか。

763 ：Name_Not_Found：04/12/19 13:16:29 ID:???

>>762
もしかしてお前マジで勘違いしてるのか？

764 ：Name_Not_Found：04/12/19 13:29:02 ID:???

揚げ足とったり問いかけたりしながら、
他の解決策しめしたり自分の意見言わない香具師は荒らし。

例）
　おまえは～をわかっていない。（じゃあ何なのかは決して語らない）
　仕様書嫁。（具体的に引用したりはできない。）

765 ：Name_Not_Found：04/12/19 13:42:56 ID:???

>>764
お前の論理だと1自体が荒らしってか？

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

とりあえず仕様書を一通り読んでから来いよ。
仕様書読んでないやつはこのスレにはいらない。
池沼はこの板には要らない。

766 ：Name_Not_Found：04/12/19 13:43:45 ID:???

>>765
むしろおまえが仕様書読んだ方がいいよ。

767 ：Name_Not_Found：04/12/19 13:46:20 ID:???

というか仕様書にtableと表の違いが書いてあると思っているとしたら、
相当なアホとしかいいようがないな。
結局、759の表の定義を聞いてみないことには議論になるはずもなく。
仕様書嫁って馬鹿の一つ覚えみたいに繰り返されてもな。

768 ：Name_Not_Found：04/12/19 14:00:58 ID:???

>>747
CSSのcontentでも使えば？

769 ：Name_Not_Found：04/12/19 14:17:26 ID:???

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/tables.html

非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、
単に文書内容を整形する目的だけで表を用いるべきでない。さらに、見た目
のために表が用いられると、その表が大きなディスプレイのあるシステムで
作られた場合、表を見るために水平スクロールを強いられることがある。こ
うした問題を最小限に押さえるため、著者は文書の整形には表ではなくスタ
イルシートを用いるべきである。

とりあえず仕様書を読もう。視覚的のみの整形は非推奨されてるのだ。
ちなみに日本語の「表」という言葉は視覚的に見やすくまとめたものである。

つまりtableは論理的に、もしくは構造的にわかりやすくまとめるためなどに
使うものである。見やすくするためにtableを使うのは間違いです。

table=表だと思ってる人はまだいますか？

770 ：Name_Not_Found：04/12/19 14:18:40 ID:???

>>769
こいつ釣られてマジレスしてやんのｗｗｗ

771 ：Name_Not_Found：04/12/19 14:22:30 ID:???

>>762=>>764=>>766=>>767=>>770

馬鹿が一人紛れてるだけだったか？

772 ：Name_Not_Found：04/12/19 14:23:44 ID:???

>771
煽るな。アホが暴れだしたら困る。

773 ：Name_Not_Found：04/12/19 14:25:32 ID:???

>>771
ハァ？
お前が初めからそうやって説明すればこんな荒れたりはしなかったんじゃボケェ

774 ：Name_Not_Found：04/12/19 14:26:51 ID:???

>>769
やっぱ前スレ話を蒸し返しているだけか。
前スレの過去ログで思いっきり否定されていただろ？
もう忘れたのか？

775 ：Name_Not_Found：04/12/19 14:29:37 ID:???

表＝視覚整形と勝手に定義されて仕様書読んでいないと断じられても困るわけだが。
tableを表と訳すのはコンセンサスだろうが。paragraphと意味段落・形式段落の違いならまだ論じる価値はあるけど。

776 ：Name_Not_Found：04/12/19 14:29:56 ID:???

>>774
>>764

自分で自分のレスを忘れたのか？

777 ：Name_Not_Found：04/12/19 14:30:34 ID:???

強制ID まだですか？

778 ：Name_Not_Found：04/12/19 14:31:14 ID:???

というかアホじゃないの？
>>769
＞ちなみに日本語の「表」という言葉は視覚的に見やすくまとめたものである。
これと>769の引用が自己矛盾していることに気付かないの？

779 ：Name_Not_Found：04/12/19 14:31:35 ID:???

横レスだが
tableも表も元々視覚的・論理的にデーターをまとめたもので、HTMLのtableではその内の視覚的な側面を否定しているというだけでは。
だから明かな表であっても視覚的なものならばHTMLのtableにはならない。

780 ：Name_Not_Found：04/12/19 14:32:56 ID:???

>>775
日本語の「表」の意味についての反論だよね？
大抵の辞書には「見やすくまとめたもの」という文言が入っているということは
知っているかな？

table要素は決して見やすくまとめたものではないのだよ。
レンダリングの結果から勘違いしてるんじゃないかな？

781 ：Name_Not_Found：04/12/19 14:33:24 ID:???

>>779
それは明らかな見出しであっても視覚的なものならばHTMLのhnにはならない、みたいな。

782 ：779：04/12/19 14:33:53 ID:???

書いてる段階ですごいレスが付いてた。
いっぱい釣れてよかったなw>769

783 ：769：04/12/19 14:34:42 ID:RNFdY6SE

レスが多いのでID出しておくね。

>>778
気付かないので説明をお願い。

784 ：Name_Not_Found：04/12/19 14:35:03 ID:???

>>780
>>778

785 ：769：04/12/19 14:36:47 ID:RNFdY6SE

>>784
どこがどう矛盾してる思ってるの？
聞いてあげるから言ってごらん。

786 ：Name_Not_Found：04/12/19 14:38:30 ID:???

http://pc5.2ch.net/test/read.cgi/hp/1096723178/568
↑
こいつだろ

787 ：769：04/12/19 14:39:20 ID:RNFdY6SE

>>786
見れないから、コピペしてくれると助かる。

788 ：Name_Not_Found：04/12/19 14:40:21 ID:???

>>785
別人だが
「非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、単に文書内容を整形する目的だけで表を用いるべきでない。」
と書いてある。
これはつまり表が文章内容を整形する目的以外で使えることを示していて、表が視覚的なものだけではないことを表しているだろ。

789 ：Name_Not_Found：04/12/19 14:41:06 ID:???

>>787
ttp://makimo.to/2ch/pc5_hp/1096/1096723178.html#568

790 ：Name_Not_Found：04/12/19 14:41:54 ID:???

>>785
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/tables.html

「表」＝視覚的に見やすくまとめたもの、としてみると…

> HTML視覚的に見やすくまとめたものモデルにより、著者は、テキスト、整形済みテキスト、画像、リンク、フォーム、
> フォームのフィールド、別の視覚的に見やすくまとめたものなどのデータを、コマの行と列とに配置することができる。
>
> 視覚的に見やすくまとめたものはそれぞれ、対応する視覚的に見やすくまとめたもの題(CAPTION要素参照)を1個持つことができる。
> これには視覚的に見やすくまとめたものの目的についての簡単な記述をする。
> 音声ブラウザや点字出力ユーザエージェントの利用者のために、長文の解説もsummary属性によって提供できる。

791 ：Name_Not_Found：04/12/19 14:45:11 ID:???

>>781
視覚的なだけの明かな見出しって想像できないな。

792 ：Name_Not_Found：04/12/19 14:45:54 ID:???

>>781
つまりID:RNFdY6SEによれば、

×明らかな見出しはhnでマークアップすべき
○明らかな見出しはhnでマークアップすべきだが、視覚的なものが目的の見出しをhnでやろうとするのは間違い

等と一々注釈をつける必要がある、と。
揚げ足取りじゃねーの？

793 ：769：04/12/19 14:47:12 ID:RNFdY6SE

>>788
なんとなく言いたいことはわかったかも。
いろんな表があるといいたいのよね？

表というものには視覚目的も含まれる場合がある、そうでない場合もある。
表という言葉にはtable要素よりも広い意味と使い方がある。
つまり表とtable要素は＝ではない。

「構造的にわかりやすくまとめた表」＝table
なら問題ないが、単に日本語の「表」という言葉とtable要素が＝にはならない。

794 ：Name_Not_Found：04/12/19 14:49:04 ID:???

HTML専用じゃない辞書の領域では、
「表」だけでなく、リストなんかも視覚的という意味を含むことになると思う。
レシピやら台本やらも視覚的云々は含まれるだろう。

通常の文書は見栄えと論理構造を渾然一体とする節があるが、
それを区別しようとするHTML+CSSで用語の説明に食い違いが出るのはやむを得ないかと。

795 ：Name_Not_Found：04/12/19 14:49:31 ID:???

>>793
それ言うなら英語のtableとHTMLのtableも違うよ。

796 ：769：04/12/19 14:51:36 ID:RNFdY6SE

>>792
hnに関しての使い方に仕様書に視覚的云々は書いてないよ。
tableの場合は視覚的云々を気にしないといけないと思いっきり書いてあるわけだ。

別の問題をごっちゃにしないほうがいい。

797 ：Name_Not_Found：04/12/19 14:52:57 ID:???

>>796
tableは特にテーブルレイアウトする人が多いから書いてあるけど、
視覚的云々だけで使ってはいけないのはどの要素も同じだと思うが？

798 ：769：04/12/19 14:53:46 ID:RNFdY6SE

>>795
そうだね・・・だから、なに？？？

799 ：Name_Not_Found：04/12/19 14:56:27 ID:???

>>798
少しは文脈で理解しろ、と。
仕様書に「なお、ここでいうtableは…」とか一々記述されてるか？
何でtable要素は英語のtableを記述するものとしてそのまま認めるのに、
tableを表に訳したとたん怒り出すの？

800 ：769：04/12/19 14:58:52 ID:RNFdY6SE

>>799
用語って知ってる？

801 ：Name_Not_Found：04/12/19 15:00:16 ID:???

>>799
>「構造的にわかりやすくまとめた表」＝table
>なら問題ないが、単に日本語の「表」という言葉とtable要素が＝にはならない。
というのの「日本語」というのは自然言語という程度の意味だったのでは。「table要素は英語のtableを記述するものとしてそのまま認める」なんて言ってないんじゃない?

802 ：Name_Not_Found：04/12/19 15:02:15 ID:???

だから>>792みたいなこと言いたかったんでしょ。

日本語の見出し≠hn
とか
段落≠pとか（これはある程度そうかも）
とか
強調≠strongとか
etc.

803 ：Name_Not_Found：04/12/19 15:05:43 ID:???

>>802
強調はemもあるでしょ

804 ：Name_Not_Found：04/12/19 15:06:43 ID:???

∧＿∧
( ´･ω･) みなさん、お茶が入りましたよ・・・・。
( つ旦O なにが論点なのかはっきりさせて、お互い煽り口調はやめようぜ。
と＿)＿) 旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦

805 ：769：04/12/19 15:07:34 ID:RNFdY6SE

>>801
何が言いたいのかさっぱり・・・m(_ _)m

ところで今レスしてくれてる人たちはみんな
表=table要素
だと解釈してるの？

単純に考えて表とtable要素がイコールである限り、テーブルレイアウトとまではいかないが、
視覚的な目的のみでのtable使用を否定できないと思うんだけどそこらへんはいつもどうやって
子供に教えてるの？

「これは表ですが、table要素でやるべきではありません。」
こういう説明する機会がよくあるのね。
で、もしも表＝table要素だと思いっきり論理破綻するよね。

で、とりあえず俺から質問。表＝table要素だと思っている人は答えてほしい。
「表＝table要素といっていたのに、どうしてtable要素には表とは違う制約があるのですか？
　その時点でイコールではないことが証明されていると思いますが、どういうことですか？」

806 ：Name_Not_Found：04/12/19 15:10:54 ID:???

昔、

759 Name_Not_Found 04/12/19 09:08:25 ID:???
>>756
仕様書嫁。表＝tableじゃない。

↓

今、

表＝table"要素" じゃない

ちゃっかり修正したりしてるし・・・

807 ：769：04/12/19 15:14:18 ID:RNFdY6SE

>>806
省略していた"要素"というのを付けたのが気に入りませんか？
言葉の問題に途中でなったので、要素とはっきりつけました。

そもそも
日本語の表と英語のtableがイコールであるかないかはスレ違いですし、
そんなことくらいわかってると思いましたが・・・

もしかして翻訳の論議だと思ってました？

808 ：801：04/12/19 15:14:28 ID:???

>>805
いや、おまいを擁護しているだけなのだが(より正確に言うとおまいを擁護しているというより799にツッコんでるだけだが)。

809 ：Name_Not_Found：04/12/19 15:18:00 ID:???

結局揚げ足取りしているようにしか見えないんだが。
何度か指摘してるけど、視覚的なものが混じることがあるのは表に限らないじゃん。

810 ：Name_Not_Found：04/12/19 15:25:35 ID:???

まあね。

811 ：769：04/12/19 15:26:20 ID:RNFdY6SE

>>808
理解できず申し訳ないですm(_ _)m

>>809
だからなんでしょうか？面倒だからいいじゃないかということですか？
本質を理解してる方はいいですが、上の方には本気で
table要素と表がイコールだと思ってる子がいたようなので。

ところで以前のスレでは私の今回言ってる理屈は否定されたとか言ってた方は
どこにいったのでしょうか？できれば否定できる根拠を聞いてみたいです。

812 ：Name_Not_Found：04/12/19 15:30:12 ID:???

仕様書には文書の整形（レイアウト）をtableでやってはいかん、と書いてあるが、
データの整形（いわゆる表）をtableでやってはいかん、とは書いていないな。

とさらに燃料投下をしてみるテスト。

813 ：769：04/12/19 15:33:37 ID:RNFdY6SE

>>812

＞「表＝table要素といっていたのに、どうしてtable要素には表とは違う制約があるのですか？
＞　その時点でイコールではないことが証明されていると思いますが、どういうことですか？」

回答よろしくおねがいします。

814 ：Name_Not_Found：04/12/19 15:33:39 ID:???

「視覚的なもの」って言葉を好んで使っている人がいるけど、
そもそも「視覚的なもの」って何？
情報が目から入ってくる以上、表というのはそもそもが視覚的なものでしょ？

そうでないとして、仮に「視覚的なもの」ってのが整形された後の形から判断されるとしたら、
それを決定して「視覚的」か否かを判断するのは誰？

現状において日本語の意味上の表＝ table であることを否定するのは難しいんじゃないかな？
ただ、
　table はレンダリング上の問題があるから、table 以外の要素を使用しても問題がないのであれば、
　table 以外の要素を使用すべきだよ
程度のことしか仕様書には書いてないように思えるんだけど。

815 ：769：04/12/19 15:34:33 ID:RNFdY6SE

>>814

>>813さんの回答おねがいします。

816 ：Name_Not_Found：04/12/19 15:34:42 ID:???

>>811
以前のスレってどのへん?

817 ：Name_Not_Found：04/12/19 15:36:09 ID:???

814ではないが
使えるけど使ってはいけないということだろ。

818 ：Name_Not_Found：04/12/19 15:38:12 ID:???

>>813
表とは違う制約、とは？
根本的にHTMLではある程度、仕様上の制約が入ることもあると思うけど…
リストを（普通は）パラグラフに含めてはいけない、とか…

819 ：Name_Not_Found：04/12/19 15:39:58 ID:???

>>814
逆に視覚的じゃないものを考えるとわかりやすい。
この表の各列にはこういう見出しが付いていて、かく行はこういうデータが入っていてetc……。

逆にこのセルの下(純粋に視覚的な意味で)にあのセルがあるとかはだめ。

820 ：Name_Not_Found：04/12/19 15:41:43 ID:???

>>816
前スレ568

>568 Name_Not_Found 04/11/02 18:47:58 ID:???
>>>567の補足
>
>おまいのいうどんな表でも表なのだからテーブルでマークアップする。
>というのは論理的ではあるんだけど、strictではないよね。
>一応仕様書には極力表を使わない事が明記されてるんだから。
>つまり作者がいくら表だと主張しても、それが表以外の方法でも内容を伝達するのに
>大差ないのなら表以外の方法をとれということだ。

のこと？

821 ：Name_Not_Found：04/12/19 15:43:56 ID:???

>>819
激しくわかりにくいのですが…
視覚的なものを言葉で説明するのは難しいのだろうが

822 ：Name_Not_Found：04/12/19 15:46:20 ID:???

>>820
よくわからんが、それは否定するレスじゃなくて769を擁護するレスじゃないのか。

823 ：769：04/12/19 15:47:56 ID:RNFdY6SE

>>816
>>756-767あたりですね。はじめは私の言うことを間違ってると言いたげな煽りが
一杯いました。今はほとんど皆無です。そう考えると理解してくれたのでしょう。

>>818
非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、
単に文書内容を整形する目的だけで表を用いるべきでない。さらに、見た目
のために表が用いられると、その表が大きなディスプレイのあるシステムで
作られた場合、表を見るために水平スクロールを強いられることがある。こ
うした問題を最小限に押さえるため、著者は文書の整形には表ではなくスタ
イルシートを用いるべきである。

824 ：814：04/12/19 15:49:24 ID:???

>>819
Thanks. 分かりやすかった

825 ：769：04/12/19 15:50:09 ID:RNFdY6SE

>>816
スレとレスを読み間違えました。
>>820
それが私を批判する過去ログですか？
批判できてないと思うのですが・・・

826 ：Name_Not_Found：04/12/19 15:50:36 ID:???

自然言語の表(table)とHTMLのtable要素型は同じ?

違う派∋RNFdY6SE

同じ派
├同じだけどHTMLのtableにはより強い制約があるよ派
│├制約があるのはどれも同じ派
│└tableは他と違うよ派
└普通に同じだ派

現在こんな感じ?

827 ：Name_Not_Found：04/12/19 15:51:32 ID:???

>>825
その過去ログに対して、という意味だろ。

828 ：Name_Not_Found：04/12/19 15:53:30 ID:???

>>823
それは「（前略）…文書内容を整形する目的だけでtable要素を用いるべきでない…（以下略）」の意味でしょ。
仕様書は「HTMLのtable」を解説しているわけであって、普通の意味の表にいちゃもんつけるものじゃないのだから。

そして「文書内容の整形＝HTML文書のレイアウト」と「データの整理」は異なると思う。（>812で述べたけど。）
てことで、「表」にtableを用いてよいと思うわけだが。あんまり拡大解釈されても困るが細かい話は言葉の問題になる。

829 ：769：04/12/19 15:54:29 ID:RNFdY6SE

>>827
あ～。すみませんでした。

>>826
>├同じだけどHTMLのtableにはより強い制約があるよ派
>│├制約があるのはどれも同じ派
>│└tableは他と違うよ派

「制約に差がある時点でイコールではないということの証明」という私の理屈を
否定しているのでしょうか？

830 ：827=816：04/12/19 15:56:31 ID:???

言葉たらずだった。
820は、その過去ログの568=RNFdY6SEであり、それに対する批判がRNFdY6SEに対する否定なんじゃないかと言っている、という意味じゃない?

831 ：828：04/12/19 15:56:42 ID:???

ちょっと落ちますので何かあればまた後ほど

832 ：Name_Not_Found：04/12/19 15:57:56 ID:???

動物＝人間
それとも
動物≠人間
さあ！どっちだｗ
これが今回の答えになるかもしれないｗｗｗ

833 ：827=816：04/12/19 16:00:15 ID:???

自然言語の表(table)とHTMLのtable要素型は同じ?

違う派∋RNFdY6SE

同じ派
├同じだけどHTMLのtableにはより強い制約があるよ派
│├制約があるのはどれも同じ派
│└tableは他と違うよ派
└普通に同じだ派
　├自然言語の表(table)は視覚的意味を持たないよ派
　└HTMLのtable要素型は視覚的意味を持つよ派(過激派/cellspacingがその証拠だ派)

834 ：769：04/12/19 16:03:29 ID:RNFdY6SE

>>830
過去ログの568は私ではありませんよ。568は結局どうなったのでしょう？

835 ：Name_Not_Found：04/12/19 16:05:29 ID:???

まあ、DBにそのまま突っ込んでも問題なさそうだったらTable要素使っても良いんじゃないか

836 ：Name_Not_Found：04/12/19 16:26:20 ID:???

流れを読まずに書くが、ID:RNFdY6SEの言う表とtable要素の違いについて提言。

既存の表とHTMLのtable要素で制約が違うから別物、とあるが、
既存の表が視覚メディア（紙媒体とかscreenとかね）のものに限るのなら（それに近いものなら）、
HTMLにおいてデータの整形なんぞに制約が加えられるのは当然。
なぜって視覚メディアでは視覚的に得られない情報は確認のしようがないし、
HTMLは視覚メディアに依存することを想定しているわけではないから。

今回の主張で押し通すならまず「表とは何か」から始めたらいいと思うよ。
（辞書がどうの、はナシね。視覚メディアを対象とした辞書で定義どうのこうのはナンセンス）

837 ：769：04/12/19 16:39:19 ID:RNFdY6SE

>>836
？？？
第２段落は表≠table要素であるといってるんですよね？

最終段落・・・・・

>（辞書がどうの、はナシね。視覚メディアを対象とした辞書で定義どうのこうのはナンセンス）
どういう意味ですか？

全体通して

対象メディアが違うことも表≠table要素の要因ですが？

838 ：Name_Not_Found：04/12/19 16:51:12 ID:???

>>837
table要素＝表を否定することにはならんよ。
対象メディアが違うってもHTMLは視覚メディアを対象に含まないわけではないから、
視覚メディアを対象にした整形というものが存在するわけで。
（しかしだからといって全てのtable要素が視覚メディアに依存することにはならんし、
　全てのtable要素が視覚メディア以外も対象にせにゃならんことにはならん）
対象メディアが違うから大元も違う、っていう積極的な否定にはならない。
既存の表はtable要素が視覚メディア用に特化されてると言い換えてもいいかな。

>どういう意味ですか？

既存の表のみを対象に言及した辞書を孫引きするのはナンセンス。
（そんな言及どこかになかったっけ？読み間違いかも）

839 ：769：04/12/19 17:29:35 ID:RNFdY6SE

>>838
対象メディアが多岐に渡る時点でイコールではないという意味を説明してくれてるのかと
思いました。

局所的なイコールにしかならないのにどうしてイコールにしたがるんですかね？
パチンコとかやられるかたですか？

840 ：Name_Not_Found：04/12/19 18:37:35 ID:???

HTMLのtable要素はワープロやDTPなんかで使う表の移植もターゲットにしている。
ワープロやDTPでの表は視覚的に整形したものだとも言える。
つまり、整形されたデータ(表)→tableは可能。

そもそも、「tableで整形するな」じゃなくて「tableで文章を整形するな」じゃない？
視覚的に整形した文章を「表」とは呼ばないよね？

呼ぶというのならスマンかった。

841 ：Name_Not_Found：04/12/19 18:52:31 ID:???

>828と同じ意見なわけね

842 ：Name_Not_Found：04/12/19 19:54:14 ID:???

仕様書嫁ってのは769ってことでFA？

843 ：756：04/12/19 20:10:37 ID:???

すごいことになってる。
>>769
あのさ、仕様書の言ってる「非視覚系メディアでのレンダリングに際して問題」ってのは、
テーブルレイアウトだと音声系メディアの場合、表表表とかいったり、
読み上げ順序をまちがったりすることを言ってるのよ。
嘘だと思うならW3Cに問い合わせてご覧。
明らかな表はtable要素。

それから、

844 ：769：04/12/19 20:18:22 ID:RNFdY6SE

>>842
まだ表＝table要素だと思ってるの？

>>843
それはテーブルレイアウトではなければ、いわゆる自然言語で「表」と呼ばれるものは
全てtableでやっていいっていうことですか？
よかったらあなたが過去に問い合わせたときの返信メールの本文をアップしてください。

845 ：Name_Not_Found：04/12/19 20:31:45 ID:???

>>828や>>840はｽﾙｰか

846 ：756：04/12/19 20:33:13 ID:???

>>844
ごめんよ。悪いけど付き合えないよ。

847 ：Name_Not_Found：04/12/19 20:34:18 ID:???

てか「これは表だ」「いや表じゃない」の水掛論にいきつくね

848 ：Name_Not_Found：04/12/19 20:34:45 ID:???

自然言語では表だけど構造的に表じゃないと思うものの例を挙げてみては？

849 ：Name_Not_Found：04/12/19 20:46:05 ID:???

猫跨ぎレス終了

850 ：Name_Not_Found：04/12/19 20:47:11 ID:???

>>847は>848の結果か。まあもとがそういうネタだけどな

851 ：769：04/12/19 20:50:37 ID:RNFdY6SE

>>845
？？？
表の種類をあげて特定の種類のものだけtableとイコールしたところで、
いわゆる表＝talbe要素ということにはならないよ。
スルーしたつもりはなかったけど、なんかごめんよ。

>>848
http://www.rakuten.co.jp/select-foods/476423/
ここの商品一覧表、横に四つで並んでるやつ。
こういう視覚整理第一で構造的な整理を後回しにしたような表は、
自然言語ではもちろんあきからかに表といえるものだが、
これをこのままtable要素でやると間違い。

852 ：Name_Not_Found：04/12/19 20:59:04 ID:???

>>851
> 自然言語ではもちろんあきからかに表といえるものだが
俺にとっては明らかじゃないから説明きぼん

853 ：Name_Not_Found：04/12/19 21:02:29 ID:???

これ、表と言い張られればそーですかと折れてもいいけど、
これを明らかな表と言う人はそうはいないんじゃないかと..

854 ：Name_Not_Found：04/12/19 21:20:44 ID:???

これは表なのか？
表だとしたら横にビローっと伸びたヤツじゃない？

855 ：Name_Not_Found：04/12/19 21:27:58 ID:???

>>851
仕様書嫁って言って独自解釈を持ち出してきたから解釈してあげたらそれか。
もう構ってられね。

856 ：Name_Not_Found：04/12/19 21:47:38 ID:???

そろそろ、>>769さんは、あほな人にもわかるレベルで、
tableでかける表と
tableでかけない表の
具体例を挙げたほうが早いんじゃないかな、
と思った。

857 ：Name_Not_Found：04/12/19 21:56:23 ID:???

>>856
>>847-848
および
>>851

858 ：Name_Not_Found：04/12/19 22:11:14 ID:???

おまえら釣られすぎ

859 ：769：04/12/20 00:31:21 ID:aykaAKXH

>>852-858
あれが表ではないと言ってるのかな？
ということはあのセクションの見出しは間違っても
<hn>商品一覧表</hn>
にはならないと思ってるの？

真剣にあれを表と呼ぶことが間違ってるとでも？

860 ：Name_Not_Found：04/12/20 00:55:26 ID:???

＞単に文書内容を整形する目的だけで表を用いるべきでない。
って、「テーブルレイアウトすんな」って意味じゃないの？

861 ：838：04/12/20 01:10:54 ID:???

>>839
ノットイコールにはならない、がどうしてイコールになる、になるかね……。

（要素同士が）局所的なイコールにしかならないのに、
どうしてイコールかノットイコールにしたがるんですかね？
パチンコとか（ry

862 ：Name_Not_Found：04/12/20 01:11:24 ID:???

>>859
じゃあ各行と各列に適切な TH をつけてみて。

863 ：Name_Not_Found：04/12/20 01:16:13 ID:???

>>859
あれはテーブルレイアウトでしょ。
列と行に意味がない。

864 ：Name_Not_Found：04/12/20 01:18:24 ID:???

「見た感じ表だから」と言ってるだけじゃん。
もっときちんと説明しろよ。

俺は、851のは段組された商品リストに見える。
商品名と画像と値段が１セットになったデータが等価で並んでるし。tableを使ってレイアウトしただけでしょ。

865 ：Name_Not_Found：04/12/20 11:30:12 ID:???

俺の感覚では>>851は表ではないが、表と言う人もまあいるかもしれない。
でもこうやって解釈が分かれるものは「明らかな表」とは言わんだろ。

866 ：Name_Not_Found：04/12/20 11:36:10 ID:???

だから何度もいってるだろ。
自然言語の用語とHTMLの用語がいちいち厳密に対応するわけないんだよ

867 ：Name_Not_Found：04/12/20 13:01:17 ID:???

今回のは、自然言語が示すもの自体にずれが生じてるケースだろ。

868 ：769：04/12/20 13:26:54 ID:aykaAKXH

<table>
<tr><th scope="col">商品名<th scope="row">コート<th scope="row">ジャンパー<th scope="row">マフラー</tr>
<tr><th scope="col">写真<td>コートの<td>ジャンパーの<td>マフラーの</tr>
<tr><th scope="col">コメント<td>あったかい<td>あつい<td>薄い</tr>
<tr><th scope="col">商品名<th scope="row">コート<th scope="row">ジャンパー<th scope="row">マフラー</tr>
<tr><th scope="col">写真<td>コートの<td>ジャンパーの<td>マフラーの</tr>
<tr><th scope="col">コメント<td>あったかい<td>あつい<td>薄い</tr>
</table>

>>862 >>863
もしかして自然言語の「表」の意味を勘違いしてない？
何かを見やすくまとめてさえいれば「表」と呼ぶことはできる。もちろんリストと呼ぶ場合もあるが
そもそも表の定義にはリストともあるわけで。
整理の仕方が極限までに効率の良い物だけが、「表」と呼べるわけではない。

っていうかtable要素と自然言語での「表」をごっちゃにしてるみたいだね。
table要素を知ってから「表」というものを学んだみたいな感じだよ君。

>>865
「明らかな表」ってあいまいな言葉だよね。
とりあえず俺が言ってるのは「表＝table要素ではない」っていうことだけだから。
「明らかな表」≠「表」だといいたいんでしょ？

>>864
自然言語の「表」ってのは見た感じで言って全く問題ないよ。

869 ：Name_Not_Found：04/12/20 13:34:22 ID:???

段組と表は

870 ：Name_Not_Found：04/12/20 13:41:07 ID:???

というかさ、769は何か勘違いしてると思う。
HTML用に特別に文書をつくるってのはもちろんあるけど、
本来は何らかの既存テキストをマークアップするためにあるわけで。
あるものが表であるかどうかは仕様書が判断する問題じゃないぞ。
仕様書の誤読もそこから来ていたのではないかな。

871 ：865：04/12/20 13:43:59 ID:???

>「明らかな表」≠「表」だといいたいんでしょ？

違う違う。「表」に限らず自然言語というのは厳密な定義や判別法なんて
存在しないのが普通で、人によって指し示す範囲が多少異なるのが当然。
どれが正しい意味だとか論じてもしょうがない。
だから議論においては、紛らわしかったら別の言い換えをするか
各自の最大公約数的な意味を使うべきで、「明らかな表」なんて表現は
誰もが表だと納得できるようなものを指す場合にのみ使うべきだってこと。

俺にとっての表≠君にとっての表

なのは事実として認めて、

俺にとっての表∋明らかな表
君にとっての表∋明らかな表

を満たすようなものを「明らかな表」と呼ぶべきだろうってことだ。

872 ：Name_Not_Found：04/12/20 13:44:26 ID:???

>>868
それは君に言わせると不適切なtableの例なのか？

873 ：Name_Not_Found：04/12/20 13:52:50 ID:???

>何かを見やすくまとめてさえいれば「表」と呼ぶことはできる。

>>851は見やすく並べてるだけで、別に何もまとめちゃいないと思うんだが。
まあ日本語の意味について議論してもしょうがないけど。
で、851が表であれ表でなかれ、table要素にはふさわしくないということで
意見は一致してるってことでいいのか？
だったらこのスレ的には話は終わりなわけだが。

874 ：Name_Not_Found：04/12/20 13:53:11 ID:???

結局あげあし取りじゃん。
最初は仕様書読めって言ってたけど誤読を指摘されてからは
仕様書についてまったく触れなくなったし。
「俺がいう表は表じゃないものも含むから表は表じゃないんだ！」
とわめているようにしか見えない。

875 ：Name_Not_Found：04/12/20 13:54:26 ID:???

>>847
>>847
>>847

876 ：769：04/12/20 13:55:58 ID:aykaAKXH

>>870
何の話でしょうか？
自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。

>>871
自然言語のあいまいさを理解していて何故にtable要素とイコールにしたがるのでしょうか？
それだけわかってればイコールが成り立たない派だと思うのですが・・・

>>872
table要素としては極限までに内部構造を整理して、見た目はCSSでやるべきでしょうね。
つまり
<table>
<tr><th>商品名<th>写真<th>コメント</tr>
<tr><td>コート<th>コートの<th>あったかい</tr>
...
</table>

などとするのがstrictですね。

877 ：Name_Not_Found：04/12/20 13:57:24 ID:???

自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。
自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。
自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。
自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。
自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。

878 ：Name_Not_Found：04/12/20 13:58:18 ID:???

>>876
結局tableかよ！表じゃないんじゃなかったのか？

879 ：769：04/12/20 13:59:03 ID:aykaAKXH

>>874
誤読？あなたが指摘したのですか？レス番お願いします。
状況に応じて論点が変わるのはごく普通ですが・・・頭が固いのでは？

880 ：Name_Not_Found：04/12/20 13:59:49 ID:???

>>876
行と列が逆だったってこと？　strictとは直接関係なくない？
データ処理の問題で普通にどっちもありだと思うが。

881 ：769：04/12/20 14:00:35 ID:aykaAKXH

>>878
ハ？何か間違ってません？

882 ：769：04/12/20 14:02:19 ID:aykaAKXH

>>880
よく見てください。縦とか横とかの問題ではありません。

883 ：Name_Not_Found：04/12/20 14:05:00 ID:???

もしかして>>868は２つの表を合体させたのがよくないってこと？
なるほど、不適切な構成の表と「表でない」を混同していたのね。

884 ：Name_Not_Found：04/12/20 14:10:14 ID:???

>>879

>759 Name_Not_Found 04/12/19 09:08:25 ID:???
>>>756
>仕様書嫁。表＝tableじゃない。

最初は仕様書に表≠tableが明記されていると考えていただろ。
>>769 >>823 >>828 >>840
みたいな流れの後、いつのまにか

>876 769 04/12/20 13:55:58 ID:aykaAKXH
>>>870
>何の話でしょうか？
>自然言語の「表」であるかとHTMLなんて全く関係ありませんよ。

と転身している。

885 ：Name_Not_Found：04/12/20 14:18:42 ID:???

おまえら不毛な言葉のあげあしとりはやめて↓でも考えてやれや。
http://pc5.2ch.net/test/read.cgi/hp/1061741473/661-
おっとここでも table が…

886 ：865：04/12/20 14:25:37 ID:???

>自然言語のあいまいさを理解していて何故にtable要素とイコールにしたがるのでしょうか？
>それだけわかってればイコールが成り立たない派だと思うのですが・・・

？誰と勘違いしてるのか知らないが、俺は別にイコールにしたがってなんかいない。
人によって表の指す範囲が違うんだから、イコールかどうかは人による。

887 ：Name_Not_Found：04/12/20 14:39:16 ID:???

というかさ、本人が「明らかな表」だと思って table 使ったらどうしようもない気が。
仮に「明らかな見出し」だからと hn が使われていて、それが傍目からは見出しじゃなさそうなとき、
（もちろん見出しにもいろいろな意味があるわけだが…）
1. おまえの言う見出しは hn とは違う。
2. 見出しでないものに hn を使うな！
3. それは見出しとして不適切では？
どの対処法が正しくてどれが間違ってるかなんて論じて何の価値があるの？

888 ：Name_Not_Found：04/12/20 15:43:34 ID:???

どうでもいい言い争いが多い。昔からだけど・・・

889 ：Name_Not_Found：04/12/20 16:24:17 ID:???

>>887
同じ例えで言うと、「見出しには必ずhnを使うのがStrict」と言った人に対して、
「自然言語で見出しと言ってもHTMLのhnとは異なる見出しもある。だから見出し＝hnではない」
と言っている人がいて揉めてるのでしょう。
その議論に価値があるかといえばまあ疑問ではありますが。

890 ：769：04/12/20 18:31:56 ID:aykaAKXH

>>884
>最初は仕様書に表≠tableが明記されていると考えていただろ。
考えていません。私は初めから仕様書を読めば表＝table要素でないことが明らかだと言ってます。
自然言語の表の定義にHTMLのtable要素の規格が影響を与えることはないことくらいわかってますよね？
HTMLのtable要素が今後どうなったとしても、自然言語の「表」の定義に影響を与えることはありません。
そういう意味の「無関係」です。

>>886
そうですか。あなたの意見は、自然言語の表の定義をtable要素と同じだと思ってる人がいれば
イコールになるだろってことですよね？
そもそも「表」というものについて勘違いされてる方が多いようですね。
table要素以前の問題のようです。

>>887
私は表＝table要素でないと言っているのです。
とりあえずその「明らかな表」というあいまい極まりない言葉を使わないでほしいです。

話がずれてますが、私としては表＝table要素ではないということだけです。
きっともうみなさん理解してくれてると思いますのでここらへんで失礼します。
これ以上は自然言語の「表」についての話にしかなりそうもありませんので、少し
スレ違いなので。

どうもありがとうございました。

891 ：Name_Not_Found：04/12/20 19:13:11 ID:???

<チラシの裏></チラシの裏> ってありますか？

892 ：Name_Not_Found：04/12/20 19:57:23 ID:???

<comment> ってのが

893 ：Name_Not_Found：04/12/20 19:58:51 ID:???

>>891
XHTML かい？

894 ：Name_Not_Found：04/12/20 20:26:07 ID:???

>>891
<my:handbill xmlns:my="http://pc5.2ch.net/test/read.cgi/hp/1101043958/894" field="reverse"></my:handbill>

895 ：Name_Not_Found：04/12/20 20:41:11 ID:???

>>890
これ以上はって最初から自然言語の表についての話しかしてないんだろ？意味不明。

896 ：Name_Not_Found：04/12/20 20:48:53 ID:???

>>890
それ散々おまえが指摘されてたことじゃん。

897 ：Name_Not_Found：04/12/20 20:54:09 ID:???

もういいよ。
↓次の話題ﾄﾞｿﾞｰ↓

898 ：Name_Not_Found：04/12/20 21:11:44 ID:???

んじゃ無理矢理にでも話題を振ってみる。

strong要素って使ってる？　emで済むことが多いと思うわけだが。

899 ：Name_Not_Found：04/12/20 21:50:30 ID:???

漏れはstrongしか使ってないがどちらにしろ2つも要らないというのは同意。

900 ：Name_Not_Found：04/12/20 21:51:18 ID:???

割と最近、盛んに議論されてたよ。
http://www.akatsukinishisu.net/wiki.cgi?em%CD%D7%C1%C7%A4%C8strong%CD%D7%C1%C7%A4%CB%B4%D8%A4%B9%A4%EB%B5%C4%CF%C0%A5%EA%A5%F3%A5%AF%BD%B8

901 ：Name_Not_Found：04/12/20 21:52:47 ID:???

>>898
明らかにより強い強調だと思うところに使っています。

902 ：863：04/12/21 00:55:02 ID:???

>868
> >>862 >>863
> もしかして自然言語の「表」の意味を勘違いしてない？
なんでそうなるんだ。　自然言語の話なんて俺はしてないぞ。
お前にレスしてる人間の意見がみんなのものだと思うな。

俺が言ってるのは「あれは表じゃない」じゃなくて、「あれはteble要素でマーク付けすべきものじゃない」だ。
頭おかしいのか？

903 ：Name_Not_Found：04/12/21 11:55:45 ID:???

>>890
>私は初めから仕様書を読めば表＝table要素でないことが明らかだと言ってます。
仕様書のどこを読めば明らかなの？
君が論拠としてあげた部分は誤読だったことが明らかになってるわけだが？

904 ：Name_Not_Found：04/12/21 12:57:10 ID:???

ま　だ　引　っ　張　る　つ　も　り　か　？

>>899
ちなみにstrongの方に統一したのはなぜ？

905 ：Name_Not_Found：04/12/21 13:00:56 ID:???

>>903
自然言語の表とやらはレイアウトに使っても問題ないんじゃない？とか言ってみるテスト。

それにしても凄い勢いだなおまいら。仕様書の解釈問題は微妙にスレ違いだと思うんだがどうよ？

906 ：Name_Not_Found：04/12/21 13:10:58 ID:???

>>890
>自然言語の「表」の定義に影響を与えることはありません。
自然言語の表ってどこに定義されてるの？
広辞苑に書いてあったとしても、それは岩波書店の私見に過ぎないと思うのだけれど..

907 ：Name_Not_Found：04/12/21 13:14:01 ID:???

767 Name_Not_Found 04/12/19 13:46:20 ID:???
というか仕様書にtableと表の違いが書いてあると思っているとしたら、
相当なアホとしかいいようがないな。
結局、759の表の定義を聞いてみないことには議論になるはずもなく。
仕様書嫁って馬鹿の一つ覚えみたいに繰り返されてもな。

769 Name_Not_Found 04/12/19 14:17:26 ID:???
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/tables.html

非視覚系メディアでのレンダリングに際して問題を起こすことがあるため、
単に文書内容を整形する目的だけで表を用いるべきでない。さらに、見た目
のために表が用いられると、その表が大きなディスプレイのあるシステムで
作られた場合、表を見るために水平スクロールを強いられることがある。こ
うした問題を最小限に押さえるため、著者は文書の整形には表ではなくスタ
イルシートを用いるべきである。

とりあえず仕様書を読もう。視覚的のみの整形は非推奨されてるのだ。
ちなみに日本語の「表」という言葉は視覚的に見やすくまとめたものである。

つまりtableは論理的に、もしくは構造的にわかりやすくまとめるためなどに
使うものである。見やすくするためにtableを使うのは間違いです。

table=表だと思ってる人はまだいますか？

828 Name_Not_Found 04/12/19 15:53:30 ID:???
>>823
それは「（前略）…文書内容を整形する目的だけでtable要素を用いるべきでない…（以下略）」の意味でしょ。
仕様書は「HTMLのtable」を解説しているわけであって、普通の意味の表にいちゃもんつけるものじゃないのだから。

そして「文書内容の整形＝HTML文書のレイアウト」と「データの整理」は異なると思う。（>812で述べたけど。）
てことで、「表」にtableを用いてよいと思うわけだが。あんまり拡大解釈されても困るが細かい話は言葉の問題になる。

908 ：Name_Not_Found：04/12/21 13:22:26 ID:???

もういいよ。好きなだけ煽りあえ。
でも議論になって次スレ立てるのを疎かにするのはやめてね。

909 ：Name_Not_Found：04/12/21 13:24:39 ID:???

>>907
というかむしろ仕様書は「レイアウト目的のものは表じゃないですから」と示唆しているように読めるな。

910 ：Name_Not_Found：04/12/21 14:13:36 ID:???

言葉遊びがしたいだけとしか思えない。

911 ：Name_Not_Found：04/12/21 14:19:10 ID:???

deja vu >>165-166

912 ：Name_Not_Found：04/12/21 14:32:20 ID:???

LOVEは厳密に言うと日本語の愛とは違うものだけど、
LOVEのことを愛と呼んで話をしてるときに、「LOVE≠愛」とか言い出すようなモンだろうな。

仕様書のtableを表と訳すのが一般的なんだから表と言ってたらtable要素のことを言ってることくらいわかるだろうに。
自然言語とかごちゃごちゃいうやつはこれからは机要素と呼んだらいいのにな。

913 ：Name_Not_Found：04/12/21 14:36:18 ID:???

>>912
厳密には、LOVE は愛って訳すべきだよって話をしているときに、
「いや LOVE は愛とは完全には一致しない。LOVE＝愛ではない。」と言い出すようなモン。
部分的には正しいが文脈を読めていない。

914 ：Name_Not_Found：04/12/21 14:43:28 ID:???

>>913
そうだな。
で、「あれは（LOVEの意味合いで）愛ではないよ」と言ってるところに、
「いやあれは明らかに（日本語的な意味合いで）愛だ」とやるから混乱を招いてるんだろうな。

915 ：Name_Not_Found：04/12/21 14:49:52 ID:???

さらに混乱させてみるテスト。

仮に人造言語STRICTISHをつくったとしよう。
"LOVE" に対応する言葉として "2CHLOVE" という語彙を用意した。
それで "LOVE" は "2CHLOVE" と訳すべきだね、って話をしたら、
自然言語の"LOVE"とSTRICTISHの"2CHLOVE"は異なる、
LOVE=2CHLOVEではない、それはSTRICTISHの仕様を読めば明らかだ、
と言っている。
背景として近年の若者がSTRICTISHの俗語表現として
"2CHLOVE"を異なる目的で使っていたことがある。

916 ：Name_Not_Found：04/12/21 14:55:24 ID:???

ファミコンだったらここでリセットボタン

917 ：Name_Not_Found：04/12/21 15:12:14 ID:???

>>916
残念。呪いの曲と共にセーブデータは飛びました。

918 ：Name_Not_Found：04/12/21 15:14:32 ID:???

>>917
そろそろ次スレだしある意味ﾀｲﾑﾘｰ

919 ：Name_Not_Found：04/12/21 15:59:07 ID:???

emとstrongの話ですが…

920 ：Name_Not_Found：04/12/21 16:18:18 ID:???

>>919
それだけに限らずなんで用意したのか微妙って要素は他にもあるよな。
tt要素なんか思いつきで「こういうのもいるよね」とやったようにしか思えないし。

921 ：Name_Not_Found：04/12/21 16:42:43 ID:???

他の部分とちょっと違うぞっていう程度のところはemで、
ここは重要だ！という気合が必要なところはstrongを使ってる。
でも日本語の文だと前者は「」で括るので大抵間に合っちゃうんだよなあ。

922 ：Name_Not_Found：04/12/21 18:23:26 ID:???

>912
仕様書に書いてあるtableは用語だろ？日本語の表とも英語のtableとも微妙に違う。
定義リストみたいなもんだ。用語はあくまで用語だろ。

769の言ってるのは結構どうでもいいことだと思うんだが、どうしてこんなに
盛り上がってたの？

「表＝table要素ではない」
↑このどうでもいい理屈に対する反発が異常だと思うんだけど。
もしかして>769の逆バージョンの馬鹿が粘着してるのか？
いつもは適当にほっておかれるタイプの>769のようなアホとは逆の自論でも持ってる
同じレベルのアホがいるってことでFA？

923 ：Name_Not_Found：04/12/21 18:24:29 ID:???

>>921
強調が「」で間に合う？
ハァ？

924 ：Name_Not_Found：04/12/21 19:19:04 ID:???

本当にセーブデータ消えた人が居るみたいだね

925 ：Name_Not_Found：04/12/21 19:26:03 ID:???

>>923
むしろ、「その役割にemだと？\nハァ？」と言うべきでは。

926 ：Name_Not_Found：04/12/21 21:07:48 ID:???

>>925
お前もアホか？
「」を強調だと言い張るアホだったらどうするつもりよ？

927 ：Name_Not_Found：04/12/21 21:10:24 ID:???

適当に煽って遊ぶ。

928 ：Name_Not_Found：04/12/21 21:15:21 ID:???

>>926
おまえ「も」って誰を引き合いに出してんのヨ。

929 ：Name_Not_Found：04/12/21 21:37:00 ID:???

>921以外にいないだろ
同一人物だから「も」が納得いかなかったのか？

930 ：Name_Not_Found：04/12/21 21:39:17 ID:???

出てきましたよ「自分以外は同じ人」君が。

931 ：Name_Not_Found：04/12/21 21:45:51 ID:???

はいはい放置しようね

932 ：Name_Not_Found：04/12/21 22:04:01 ID:???

em ってサイズにも使うからなんか気になるんだよね。
いやいいんだけど。使ってるしさ。

933 ：921：04/12/22 03:55:48 ID:???

すんません、アホなので皆さんが何を言いたいのかよくわかりません。
鉤括弧で強調を示すのが変ってこと？
HTML的には全然「間に合って」ないってこと？

934 ：Name_Not_Found：04/12/22 09:43:09 ID:???

その強調が機械に伝わるのだろうか

935 ：Name_Not_Found：04/12/22 11:19:27 ID:???

こんなときこそSGMLだな。

936 ：921：04/12/22 12:45:34 ID:???

>>934
もしかして鉤括弧がemやstrongの完全な代用品になると主張している電波に見えた？
そうじゃなくて、マークアップするのをサボりがちだと言いたかっただけです。

937 ：Name_Not_Found：04/12/22 12:53:07 ID:???

XHTML2.0って今どうなってんの？

938 ：Name_Not_Found：04/12/22 13:07:11 ID:???

939 ：Name_Not_Found：04/12/22 14:09:35 ID:???

>922
> いつもは適当にほっておかれるタイプの>769のようなアホ
いやいや。いつも徹底的に叩いて遊ぶのがこのスレだろ。

>>921を擁護する気はないが、強調したい箇所を鍵括弧で括る、って手抜きをしちゃって、って言いたかったんだろうな。
間に合う、とかこのスレでいうのがおかしいわけだ。

940 ：Name_Not_Found：04/12/22 16:02:46 ID:???

CSSで強調要素の前後にカギ括弧を生成するって手があるが、
その辺はけっこう日本語の問題に行き着くという説もあり。

941 ：Name_Not_Found：04/12/22 17:29:37 ID:???

まぁ、このスレ的には <em> なり <strong> なりを使ってマークアップしつつ、
必要があれば、 before / after 擬似クラスを使いなさいってところだろうなぁ。

実装？　そんなものは知りませんが、何か？

942 ：Name_Not_Found：04/12/22 17:59:23 ID:???

>実装？　そんなものは知りませんが、何か？

なんかキモイなこいつ。仕事何やってんの？

943 ：Name_Not_Found：04/12/22 20:22:10 ID:???

>>941
三年以上前のレタリングエンジンじゃなければ対応してますよ

944 ：Name_Not_Found：04/12/22 21:50:06 ID:???

>>943
2004年のIE6はbefore / after 擬似クラス対応してないけどな。

>>942
きょうび「何か？」はないよなぁ。

945 ：Name_Not_Found：04/12/22 22:15:35 ID:???

おまいら、一々そんなことに反応してたら禿げるぞ。

946 ：Name_Not_Found：04/12/22 22:19:31 ID:???

em, strong=強調だと思ってる人はまだいますか？

947 ：Name_Not_Found：04/12/22 22:26:44 ID:???

そろそろ次スレの季節だな。

948 ：Name_Not_Found：04/12/22 22:45:26 ID:???

一々そんなことに反応してたら禿げると思ってる人はまだいますか？

949 ：Name_Not_Found：04/12/22 23:11:24 ID:???

>>948
>>948

950 ：Name_Not_Found：04/12/23 00:29:01 ID:???

>>948
あなた自身か（笑）。

951 ：Name_Not_Found：04/12/23 00:31:23 ID:???

>>950
ｽﾄﾘｸﾀｿあるまじき読解力だな。
>>949は>>948に>>948の質問をぶつけてるだけだ。

952 ：Name_Not_Found：04/12/23 00:33:11 ID:???

>>950
次スレよろしく

953 ：Name_Not_Found：04/12/23 12:26:28 ID:???

>>944
IE?
んな3年前にレタリングエンジンの更新を停止したブラウザ知るか

954 ：Name_Not_Found：04/12/23 12:33:46 ID:???

まあまあ。

955 ：Name_Not_Found：04/12/23 13:07:45 ID:???

レンダリング

956 ：Name_Not_Found：04/12/23 13:26:03 ID:???

まあまあ。

957 ：Name_Not_Found：04/12/23 13:59:38 ID:???

lettering

958 ：Name_Not_Found：04/12/23 23:11:19 ID:???

次スレ立ってた
Strict-HTML スレッド 26
http://pc5.2ch.net/test/read.cgi/hp/1103795522/

959 ：950：04/12/23 23:48:44 ID:???

次スレ立てて報告するの忘れてた…… orz

960 ：Name_Not_Found：04/12/23 23:49:16 ID:???

>>959
いや、乙

961 ：Name_Not_Found：04/12/25 11:41:32 ID:???

このスレには関係ないけどこんな板が出来ましたよ

ウェブマスター
http://sakura03.bbspink.com/webmaster/

962 ：Name_Not_Found：04/12/25 11:54:43 ID:???

>>961
スレ違い

963 ：Name_Not_Found：04/12/25 12:33:27 ID:???

次のテンプレ「その他」の部分に良いと思ったんだけど、どう？

■HTMLクイックチェッカー
　ttp://www.tcp-ip.or.jp/~mt2knm/etc/tools.html

Lintをローカルで使わずに直接ぶち込んで試す香具師が増えてるのか知らんが、Lint重い

964 ：963：04/12/25 12:36:29 ID:???

( ﾟдﾟ)ﾊｯ!もう立ってた?!
次スレで載せてくる

965 ：Name_Not_Found：04/12/25 12:37:49 ID:???

>>963-964
俺も使ってるぜ。カスイケ系スレにも貼ってくる。

966 ：Name_Not_Found：04/12/25 12:52:31 ID:???

XHTML 1.1 に以降してからは使ってない。
ていうかあちこちに貼ってまわるのやめれ。
フリーサイトスレに貼れ。

967 ：963：04/12/25 13:15:24 ID:???

>966
まじか( ﾟдﾟ)
「見つけた」感があって嬉しくて貼ったんだけど、よく考えたらもう古いよね…。(´；ω；｀) ｺﾞﾒﾝ…

968 ：Name_Not_Found：04/12/29 16:37:12 ID:???

埋めようぜ…。

969 ：Name_Not_Found：04/12/29 17:16:16 ID:???

んでdivは小文字で書かなければいけないかどうかについて。

970 ：Name_Not_Found：04/12/29 17:29:44 ID:???

HTMLならどうでもいい
XHTMLなら小文字

971 ：Name_Not_Found：04/12/29 23:21:57 ID:???

全部小文字でいいよ。大文字だらけって何か作成ソフトでも使ったのかと小一時間…

はぁー作成ソフトって便利やなぁー。

972 ：Name_Not_Found：04/12/30 04:16:31 ID:???

>>971
自分の可読性のために要素を大文字にすることだってある、というのは想像できないか。

したり顔で何が「はぁー作成ソフトって便利やなぁー。」やねん貧乏人が。

973 ：Name_Not_Found：04/12/30 12:20:27 ID:???

>>971
昔は大文字で書く方が普通だったから、その時からの癖で、
普通のテキストエディタで大文字で書いてるよ。
<P> とか <UL> とか、シフトキーを押し続けたまま入力できるので、
むしろ大文字の方が入力が楽だ。

作成ソフトと言ってもピンキリだけど、例えばホームページビルダーで、
このスレで言ってるような Strict なHTMLを作成しようと思ったら、
実はかなり面倒だと思うが……。慣れもあるだろうが、手書きの方が楽。

974 ：Name_Not_Found：04/12/30 16:58:19 ID:???

大文字＝厨だと思う。正直な話

975 ：Name_Not_Found：04/12/30 16:59:59 ID:???

>>973
> <P> とか <UL> とか、シフトキーを押し続けたまま入力できるので、
それ非常にわかる。

>>974
無根拠な煽りは自らの無知を露呈するよ。正直な話。

976 ：Name_Not_Found：04/12/30 17:12:24 ID:???

いや、でも正直な話大文字は厨房だろ？感覚の違いか？
なぜわざわざ大文字にするのか理解できん。見た目の問題か？

977 ：Name_Not_Found：04/12/30 17:13:46 ID:???

久し振りに真性を見た気がする。

978 ：Name_Not_Found：04/12/30 17:16:22 ID:???

>>976
はぁ。
あのさ、大文字でもいいのに大文字じゃダメだ、なんていかにもXHTMLの仕様書読みたて！な匂いがするんだが。

俺は「可読性のために」全部小文字にしてる。
逆に、要素と属性の区別のために大文字にするのもありだとおもう。

＞なぜわざわざ大文字にするのか理解できん。
すぐ上に
「<P> とか <UL> とか、シフトキーを押し続けたまま入力できるので、」
「自分の可読性のために要素を大文字にすることだってある」
とあるのすら読めないやつが、小文字の要素が見分けられるのか？

979 ：Name_Not_Found：04/12/30 17:18:48 ID:???

はい。見分けられないのは厨房だけです

980 ：Name_Not_Found：04/12/30 17:24:38 ID:???

つまり976は厨房、と

981 ：Name_Not_Found：04/12/30 19:08:30 ID:???

>>979
なぜわざわざ大文字にするのかのレスが見分けられなかったことを示唆してるのか？

982 ：Name_Not_Found：04/12/30 19:14:04 ID:???

カスイケ自薦スレ（もう落ちたけど）の最後の方でこんなレスがありました。

959 Name_Not_Found 04/12/21 20:12:04 ID:???
今更ながら皆間違っているので
DIVは小文字で入れて下さい。

984 Name_Not_Found 04/12/26 15:51:14 ID:???
>>983
だからW3C行けよ
あそこ読んでこいバカ

988 Name_Not_Found 04/12/27 17:25:51 ID:???
>>987
ttp://www.w3.org/Consortium/Translation/Japanese
ここ嫁。それで、読み終わるまで
しばらく来るな。

983 ：Name_Not_Found：04/12/30 19:24:02 ID:???

>>982
>>969はそのネタを持ってきただけだろ。

984 ：Name_Not_Found：04/12/30 19:31:49 ID:???

HTML4.0が全盛期の頃は、
「要素名と属性を見分けやすくするように、要素名は大文字、属性は小文字で書きましょう」
みたいな傾向があったような気がするけど。

985 ：Name_Not_Found：04/12/30 19:37:10 ID:???

ああ、仕様書の例示の受け売りね。

986 ：Name_Not_Found：04/12/30 19:40:09 ID:???

仕様書の受け売りのどこが悪いん？

987 ：Name_Not_Found：04/12/30 19:41:16 ID:???

>>984
いや、あれは「この仕様書ではわかりやすくするためにそうしてるけど、それだけのためで他の意味はないよ」って言う意味だ。

＞HTMLでは要素名も属性名も大文字小文字に違いはないことに注意されたい。この記述法は読みやすくなるよう配慮したものである。

988 ：Name_Not_Found：04/12/30 21:29:14 ID:???

>>978
SGMLの規格に依れば、「大文字でもいい」ではなく
「小文字でもいい」だな。

「小文字はすべて大文字に変換してから解釈すること」とある。

989 ：Name_Not_Found：04/12/30 21:32:04 ID:???

そろそろ強制dat落ち判定か

990 ：Name_Not_Found：04/12/30 21:59:18 ID:???

大文字で書くのは厨という感覚はよく分からんな。
大文字で書くのはオサーンというのならまだ分かるが。

10年以上前のコンピュータ文化って基本的に大文字中心の文化が
あったんだよね。MS-DOSのコマンドにしろ、FORTRAN言語にしろ、
大文字小文字を区別しないといいつつ、皆んな大文字で書いていた。
HTMLもその時代の産物だからなぁ。

そういえば、25年ぐらい前のパソコンは、そのまま打ったら大文字で、
シフトキーを押しながらで小文字になるのが普通だったな。

991 ：Name_Not_Found：04/12/30 22:01:48 ID:???

BASICの命令も大文字で書いてたな。

992 ：Name_Not_Found：04/12/30 22:23:24 ID:???

>>990
最初に触れたプログラミング言語がCだったと予言してみる。