Strict-HTML スレッド 38

1 ： ◆eUtysLtYW. ：2006/09/19(火) 20:35:39 ID:yyMcszw4

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 スレッド 37
http://pc8.2ch.net/test/read.cgi/hp/1154869185/

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

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

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

関連スレは>>2

2 ： ◆eUtysLtYW. ：2006/09/19(火) 20:36:35 ID:yyMcszw4

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

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

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

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

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

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

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

3 ：Name_Not_Found：2006/09/21(木) 12:10:55 ID:OXGKUuJP

前スレ落ちたか

4 ：Name_Not_Found：2006/09/21(木) 12:30:11 ID:???

みたい。
埋めときゃよかったな。

5 ：Name_Not_Found：2006/09/21(木) 12:41:50 ID:???

ちょっと間が空けば落ちてしまうな。

6 ：Name_Not_Found：2006/09/21(木) 19:18:34 ID:???

どういう条件で落ちるのかいつも忘れる。
板によって違うんだったかな。

7 ：Name_Not_Found：2006/09/21(木) 20:12:28 ID:???

XHTML2.0がいつ勧告されるか賭けようぜ

8 ：Name_Not_Found：2006/09/21(木) 21:51:25 ID:???

950超えて一定時間で落ちじゃなかったっけ？

9 ：Name_Not_Found：2006/09/22(金) 01:27:16 ID:???

>8
980のはず

10 ：Name_Not_Found：2006/09/22(金) 20:57:07 ID:???

スレ立て後即死判定

11 ：Name_Not_Found：2006/09/22(金) 22:31:28 ID:???

このスレは特にだが、話題がないとレスがなかなかつかない。
誰か話題投下キボン

12 ：Name_Not_Found：2006/09/22(金) 22:36:01 ID:???

HTMLを鳩丸と呼ぶのはどう考えても邪道な件

13 ：Name_Not_Found：2006/09/22(金) 23:08:13 ID:???

まあ、ばけらさんもあんまりStrictじゃないし。

14 ：Name_Not_Found：2006/09/22(金) 23:25:11 ID:???

これならいい？
<abbr title="Hyper Text Markup Language"><abbr title="HTML">鳩丸</abbr></abbr>

15 ：Name_Not_Found：2006/09/22(金) 23:52:45 ID:???

>>14みたいに、ありとあらゆる略語要素にtitle属性で原形を記すのは気持悪いと思うんだがな。
そりゃ、略語の原形を伝えたい場合はそれで良いと思うよ。

でもなかには「エアコン」とか「リモコン」という、略語で定着した語句まで、いちいち略さない形を記している奴も居るのに驚いた。
多くのユーザーエージェントは、要素にフォーカスするとツールチップで表示してくれるから気持悪くないかも知れないが
これって「エアコン (エア・コンディショナー)」とか「テレビ (テレビジョン)」とかいちいち記しているのに等しいぞ。気持悪くないのか。

もっとひどいのが「これをSEOのため」と騒いでいる奴だ。
HTMLをちゃんと理解していないのか。困ったものだ……。

16 ：Name_Not_Found：2006/09/23(土) 01:50:57 ID:???

誰も君の好みなんて聞いてませんぜ

17 ：Name_Not_Found：2006/09/23(土) 02:19:36 ID:???

要素に記述されたtitle属性は、どの程度、閲覧者に伝わるものと考えられますか？
例えば、ある小説の文章を引用して記述するときに

　　「<span title="ウォッシュ">波</span>の乱れを感知したんだ」
　　（中略）
　　「<span title="ウォッシュ">洗濯</span>って？」
　　「時空の<span title="ウォッシュ">波</span>だよ」

などのように、title属性が閲覧者に「必ず伝わるもの」とした書き方をしても大丈夫でしょうか。
それとも、「伝わらない事もある」と考えて、例えば上記の例の場合には「括弧書き」などをすべきでしょうか。

18 ：Name_Not_Found：2006/09/23(土) 02:55:36 ID:???

>>17
普通の文書と同じように考えて「括弧書き」がいいと思う。
つか、ユーザエージェントも括弧書きのような描画をしてほしい。

abbrのこともそうだけど。

19 ：Name_Not_Found：2006/09/23(土) 03:10:13 ID:???

そこはルビにしたいなあ。カッコだとやっぱテンポがね。

20 ：Name_Not_Found：2006/09/23(土) 04:29:35 ID:???

それは見栄えに関わる話

21 ：Name_Not_Found：2006/09/23(土) 05:55:58 ID:???

見栄えを考慮しちゃいけないわけではないよね。
どっちだって問題ないんだから。

22 ：Name_Not_Found：2006/09/23(土) 09:20:03 ID:???

本気と書いてマジと読ませる場合はruby！
波と書いてウォッシュと読ませる場合もruby！

23 ：Name_Not_Found：2006/09/23(土) 11:33:33 ID:???

ハトマルと読むなら、ACRONYMだろ。

24 ：Name_Not_Found：2006/09/24(日) 18:59:13 ID:???

<br>って置き換え要素じゃないんですか？

25 ：Name_Not_Found：2006/09/24(日) 21:03:01 ID:???

剣道の記録ってHTMLでマークアップできないですかねぇ。
剣道では1本目に取得した技を○で囲むんですが、そのままではマークアップできませんし、
画像にすれば代替文字列がかけません。

26 ：Name_Not_Found：2006/09/24(日) 21:22:15 ID:???

「丸で囲むこと」に意味があるの？他と区別が付けばいいだけなら強調とかすれば。
あとはスタイルシート側で背景画像を配置するとかボーダーをつけるとか。

27 ：Name_Not_Found：2006/09/24(日) 21:24:19 ID:???

☑

28 ：25：2006/09/24(日) 22:32:51 ID:???

>>26
どうもです。
普段鉛筆で記録しているときは○で囲むので、○じゃないといけないと思ってましたけど、
よく考えれば他のと区別できればなんでも良いかもしれませんね。
emにCSSでbackground付けることにします。

29 ：Name_Not_Found：2006/09/24(日) 22:58:35 ID:???

そういえば、中学のときに剣道をやっていたなぁ。

30 ：Name_Not_Found：2006/09/24(日) 23:59:23 ID:???

>>28

emの意味である強調にした所で、
それが取得した技と言う、一般的な認識になるの?

筆記とWEB上での見栄え的な表現方法が、そもそも違う、と思う。
マークアップ言語的に言えば、
その分野をRDF的に出来れば良いと考えるが。

31 ：Name_Not_Found：2006/09/25(月) 00:08:21 ID:???

紙に ○ したってそのルール知らない人から見ればわからんわけで「一般的な認識」じゃあないし。

>>27 のいうように <input type="checkbox" title="最初に取得した技"> や画像をその技の前か後につけても問題ないんじゃね。

32 ：Name_Not_Found：2006/09/25(月) 01:49:45 ID:???

KendoMLのスキーマ作って、HTMLへ変換するスクリプトorスタイルシート(XSL)だ。
HTMLは文書のためのマークアップ言語。

33 ：Name_Not_Found：2006/09/25(月) 02:12:33 ID:???

SVGでおｋ

34 ：Name_Not_Found：2006/09/25(月) 12:09:50 ID:???

>>31
> 紙に ○ したってそのルール知らない人から見ればわからんわけで「一般的な認識」じゃあないし。
紙に○ってのは元テキストレベルの話なんだから、emと比べるのは的外れだろ。
それを同一視するのは、数式で累乗を上付文字で書くのを「知らない人がいるなら一般的ではない」
って言い張るようなものだ。
(文書の主な閲覧者にその表記ルールを知らない相手も含みたい、というなら話は別だけど)

で、フォームの入力でもないのに
> <input type="checkbox" title="最初に取得した技">
ってのは論外だろ。よりによってStrictスレでよく言えるね。

>>28
それでもいいし、技の後に*印でもおいといて、注釈をつけといてもいいと思うよ。
元テキストで表現するかHTMLとかCSSで表現するかの違いだ。

35 ：Name_Not_Found：2006/09/25(月) 12:28:47 ID:???

>>34
言ってることめちゃくちゃ

36 ：Name_Not_Found：2006/09/25(月) 13:25:10 ID:???

好意的な解釈をすれば、
剣道の記録データは、少なくとも本人が、利用しやすい形で保存してあって、
それをHTMLに変換した時に、どうマーク付けをすれば好いのか、
を、聞いているだけじゃあないかな。

というか、好意的に解釈せずとも、そもそもここはHTMLスレだから、
HTMLのマーク付けの話に終始しておけば間違いないだろう。
だから、CSSでどう飾るかなんて話さえ、聞いちゃいねえよヴォケ、な話だろう。

37 ：Name_Not_Found：2006/09/25(月) 13:26:14 ID:???

<input type="checkbox" title="最初に取得した技">

これって視覚情報のためのマークアップじゃね？

38 ：Name_Not_Found：2006/09/25(月) 13:41:24 ID:???

<img src="maru.png" alt="最初に取得した技" /> ？

ってか「テストの○×ついた答案をマークアップする」ようなもんじゃないの、これは。

39 ：Name_Not_Found：2006/09/25(月) 14:21:29 ID:???

>>36
日本語でおｋ

40 ：Name_Not_Found：2006/09/25(月) 14:42:03 ID:???

>>38
> テストの○×ついた答案をマークアップ

<dl>

<dt>問1</dt>
<dd>1+1</dd>
<dd>3</dd>
<dd>不正解</dd>

<dt>問2</dt>
<dd>2*3</dd>
<dd>6</dd>
<dd>正解</dd>
　　：
とかどうでつか？

41 ：Name_Not_Found：2006/09/25(月) 16:22:18 ID:???

(´･ω･｀)

42 ：Name_Not_Found：2006/09/25(月) 16:36:43 ID:???

>>25
>剣道では1本目に取得した技を○で囲むんですが
メディア媒体が違うんだから同じようにするのは難しいだろ。
どうしてもっていうなら画像で表現するしかないと思う。

43 ：Name_Not_Found：2006/09/26(火) 03:09:43 ID:???

複数のサイトに組み込まれる予定のコンテンツをコーディングしてるのですが、
組み込まれるhtmlの文書構造が不明なので、見出しレベルを指定できません。
このような場合、どのようにマークアップすればよいでしょうか？

<p class="クラス名"><strong>見出し</strong></p>

くらいが無難ですかね？

44 ：Name_Not_Found：2006/09/26(火) 03:15:58 ID:???

せめてDIVにしようぜ(´･ω･)

45 ：Name_Not_Found：2006/09/26(火) 03:49:33 ID:???

>>44
アドバイスありがと。
たしかにdivの方がいいですね。pにする意味ないし。

46 ：Name_Not_Found：2006/09/26(火) 16:56:58 ID:???

>>43
レベルは組み込むほうが設定するべきものだから、
埋め込まれる側が気にしてはならない。

47 ：Name_Not_Found：2006/09/26(火) 19:33:20 ID:???

そこで<xhtml2:h>見出し</xhtml2:h>

48 ：Name_Not_Found：2006/09/30(土) 15:46:32 ID:???

%URI;って、書けるURIって１つだけ？

49 ：Name_Not_Found：2006/09/30(土) 23:25:47 ID:???

Strictにこだわる人は、何故日本語の文法にも五月蝿い人が多いのか。
そして旧かな遣ひを表記したがる。

やはり読みづらくて仕樣が無い。古い人間ならまだしも、世代を考えたら現代仮名遣ひ
に慣れてゐる人にとつては、旧仮名遣ひで表記された文章は読み難く感じると思ふ。
http://lan.rgr.jp/introduce/notation

50 ：Name_Not_Found：2006/10/01(日) 00:54:47 ID:???

>>49
日記で叩かれた人でつか？ｗ

51 ：Name_Not_Found：2006/10/01(日) 03:54:27 ID:???

>>49
自己満足の世界だとオモ。

52 ：Name_Not_Found：2006/10/01(日) 04:01:40 ID:???

ストリクタ自体が、基本的にただの自己満足の賜物だしな。
仕様より仕様に忠実なのを目指してる時点でそうとしか言えない。
だが、それもまた良いとは思うけどね。
色々と参考にはなる。
たまに居る他人を小馬鹿にしたような言い方や、
strictを強要するような馬鹿さえ居なければだけど。

53 ：Name_Not_Found：2006/10/01(日) 05:43:13 ID:???

>>49
そんな特殊な例を持ち出されても困るｗｗｗｗｗ

54 ：Name_Not_Found：2006/10/01(日) 05:54:29 ID:???

>>52
>たまに居る他人を小馬鹿にしたような言い方や、
>strictを強要するような馬鹿さえ居なければだけど。

そういう人間がいない世界を知っているなら、ぜひ教えてもらいたいねえ。
脳内以外で。

55 ：Name_Not_Found：2006/10/01(日) 06:01:46 ID:???

>>54とかが良い実例だな
人間性の問題

56 ：Name_Not_Found：2006/10/01(日) 06:07:47 ID:???

商売でやってるんなら小馬鹿にされてもしょうがないと思う

57 ：Name_Not_Found：2006/10/01(日) 19:14:54 ID:???

http://pc8.2ch.net/test/read.cgi/hp/1157971088/563
こちらのスレで質問したのですが、スレ違いなのでStricterにお聞きします。
コピペで申し訳ないのだが、

攻略の説明文で、コントローラー入力の部分のマークアップに、

<p>ここで<kbd>○</kbd>ボタンを押す。</p>

という記述はW3C的に変だと思う？

後、ゲーム中に出てくる本文を記述する時、

<p>ここで<q cite="ゲームの名前">さあ、ラスボスを倒そう！</q>を選択する。</p>

ってするべきなのだろうか？そうするとサイト内引用だらけになってしまうという
問題もでてくるんだが。。。

58 ：Name_Not_Found：2006/10/01(日) 19:59:57 ID:Ul54UxeZ

>>57
Another-HTMLで、確認したら？

59 ：Name_Not_Found：2006/10/01(日) 20:10:27 ID:???

？

60 ：Name_Not_Found：2006/10/01(日) 20:19:19 ID:???

>>57
<dfn>○ボタン</dfn> とか <code>さあ、ラスボスを倒そう！</code> とかでもありじゃね？

61 ：Name_Not_Found：2006/10/01(日) 20:26:04 ID:???

codeでなくsampが適切だろう。

62 ：Name_Not_Found：2006/10/01(日) 20:40:31 ID:???

どっちか迷ったんだけどね。

samp は「出力例 (sample output)」だから、
ユーザーに示したい、これと決まったコードを示すときは……
というか、たしかに「さあ、ラスボスを倒そう！」はプログラムの出力であるんだけれども、
ユーザーからしてみれば、それは出力というよりはコードなわけで、

たとえば、
「<samp>たたかう</samp>を押すと、たとえば、<samp>敵に10のダメージを与えた</samp>とでます」
これより
「<code>たたかう</code>を押すと、たとえば、<samp>敵に10のダメージを与えた</samp>とでます」
のが自分的にはしっくりきたので >>60 はそうしたのだった。
どっちが適切なのかはちょっとわからん。

63 ：Name_Not_Found：2006/10/01(日) 21:09:14 ID:???

入力コードだから<kbd>○</kbd>でいいと思う。
codeは何でそうなるのかわからん。ソース片じゃないだろ。

64 ：Name_Not_Found：2006/10/01(日) 21:48:16 ID:???

日本語の問題なのかも知れませんが、紙媒体の文書とHTML文書では
メディアが違うのでここで質問させてください。

皆さんは、「文書の最終更新日」をなんと表記していますか。
いろいろ見ていると「最終更新日」（一番多い）や「最終改訂日」としている人が多い様です。

それから、これはどのような要素になるのでせうか？
いまのところ私はP要素にしています。
<p>最終更新日: YYYY-mm-dd H:i:s</p>

65 ：Name_Not_Found：2006/10/01(日) 21:54:45 ID:???

<dl>
<dt>最終更新日</dt>
<dd><dc:modified>2006-10-01T21:54:00+09:00</dc:modified></dd>
</dl>

66 ：Name_Not_Found：2006/10/01(日) 22:06:27 ID:???

ul-liかな

67 ：Name_Not_Found：2006/10/01(日) 22:25:59 ID:???

こうしん【更新】（名・自他スル）
新しいものに改まること。また、改めること。
「記録を―する」「免許証の―」
かいてい【改訂】（名・他スル）
書物などの、誤りを正し不足を補うなど、内容をよりよく
改めること。―― 旺文社国語辞典より

さて、どちらを使うべきか……。

68 ：Name_Not_Found：2006/10/01(日) 22:44:22 ID:???

改訂ならinsやdelでマークアップして、日時はdatetimeに書くから無問題。

69 ：Name_Not_Found：2006/10/02(月) 03:08:51 ID:???

自分はdlかな。

70 ：Name_Not_Found：2006/10/02(月) 07:19:16 ID:???

dlだな。

71 ：Name_Not_Found：2006/10/02(月) 07:46:06 ID:???

ｄｌだなあ

並列の関係だし

72 ：Name_Not_Found：2006/10/02(月) 19:09:20 ID:???

もう面倒なので、サイトナビゲーションも更新情報も廃止しました！

73 ：Name_Not_Found：2006/10/02(月) 19:58:07 ID:???

敵前逃亡は銃殺刑だぞ。>>72三等兵。

74 ：Name_Not_Found：2006/10/02(月) 22:26:05 ID:???

検索窓はどんな感じにマークアップしたらいいだろう。
特にinput type="hidden"の扱いに困る。

75 ：Name_Not_Found：2006/10/02(月) 22:34:08 ID:???

なんで？

76 ：Name_Not_Found：2006/10/02(月) 22:45:00 ID:???

inputはインラインなんだから、他のと並べちゃえばいいじゃないか。
他のも別のddやらpやらで囲んであるんだろ。

77 ：Name_Not_Found：2006/10/02(月) 23:20:44 ID:???

検索語句入力欄や掲示板の書き込み・コメント投稿の入力欄は
dtにフォームコントロールが何かというものを書いて
ddにフォームコントロールを置く、ってのはやるけど
送信ボタンに対応するdtはあるのは変だから送信ボタン部分をpかul,liでやって
そこにtype属性値がhiddenのやつも置けばいいんでない？

78 ：Name_Not_Found：2006/10/03(火) 20:10:20 ID:???

57だけど、回答サンクス。
<kbd>って、プレイステーションなんかのゲーム機での入力でもいいんだね。
パソコンじゃないとだめだと思っていたので、これからガンガン活用します。
<samp><code>も<q>の変わりにいいね。参考になりました。

79 ：74：2006/10/03(火) 21:54:45 ID:???

例えば

<dl>
<dt>example.com内を検索</dt>
<dd><input type="text"></dd>
<dd><input type="submit"></dd>
<dd><input type="hidden"></dd>
<dd><input type="hidden"></dd>
<dd><input type="hidden"></dd>
</dl>

とかだとマズいのかな。hidden他のinputと並べちゃったほうがいい？
input type=hiddenのhtml的な位置づけがよくわからない。

80 ：Name_Not_Found：2006/10/03(火) 22:02:15 ID:???

Formに関する議論は過去ログになかった？

81 ：Name_Not_Found：2006/10/04(水) 01:15:42 ID:???

おれは >>77 のタイプかな

>>79 も dt要素と一組になってるならいいんじゃないか

ただ hidden は submit と同時に送信されるから
やっぱりセットにする >>77 のタイプ派だな　オレは

というか>>79 の例なら、キャプションは legend にして、
inputだけ p でまとめりゃいいんじゃね？

82 ：Name_Not_Found：2006/10/04(水) 22:53:36 ID:???

なんでわざわざP使うのかわからん。DIVでいいやん。

83 ：Name_Not_Found：2006/10/05(木) 00:37:38 ID:???

おやおや

84 ：Name_Not_Found：2006/10/05(木) 01:19:47 ID:???

>>82

おやおや

逆だろ

なんでわざわざDIV(とその中にP)使うのかわからん。Pでいいやん。

85 ：Name_Not_Found：2006/10/05(木) 01:33:38 ID:???

pは変。段落じゃないし。
divは変。他の要素で置き換えられるし。

86 ：Name_Not_Found：2006/10/05(木) 01:45:12 ID:???

他に使うもんないっしょ

dt ddでだいたいはできるけどね
送信ボタンとかは p 以外になんかある？

tableで、とかいう人もいるけどtableは明らかに違う気がするな

87 ：Name_Not_Found：2006/10/05(木) 02:02:07 ID:???

フォームが並んでるんだったらリストだろ。

88 ：Name_Not_Found：2006/10/05(木) 02:03:12 ID:???

>>86
テーブルでも縦横のセルの並びに意味があるんだったらテーブルだろう

89 ：Name_Not_Found：2006/10/05(木) 02:39:33 ID:???

>>79 はないでしょ

リストもテーブルもおかしいから
p でいいと思うけどな

90 ：Name_Not_Found：2006/10/05(木) 03:46:34 ID:???

>>89
「段落」辞書で引いてみろ。

91 ：Name_Not_Found：2006/10/05(木) 03:55:25 ID:???

そんなこといったら全部おかしいぞｗ

p しかないだろう

92 ：Name_Not_Found：2006/10/05(木) 03:57:42 ID:???

そろそろ釣りだと気づけ

93 ：Name_Not_Found：2006/10/05(木) 04:32:43 ID:???

釣りですますなら書くなよｗ

94 ：Name_Not_Found：2006/10/05(木) 05:34:27 ID:???

ってか <fieldset> でいくね。

95 ：Name_Not_Found：2006/10/05(木) 07:21:54 ID:???

<input type="hidden">って、ブロック要素の中に
他の要素や文字列は入れなくても問題ないの？
マークアップの為のマークアップになっちゃうけど。

96 ：Name_Not_Found：2006/10/05(木) 09:00:13 ID:???

>>94

は？
それこそ釣りだろｗ

>>95

だから、ほかの hidden と送信ボタンをひとまとめにする
っていう話だったんだよ

97 ：Name_Not_Found：2006/10/05(木) 20:48:22 ID:???

>>94
fieldset直下にインラインはdiv直下にインラインと同じようにストリクタには忌避される。

98 ：Name_Not_Found：2006/10/06(金) 01:07:52 ID:???

段落をp要素でマークアップする事について。
http://lan.rgr.jp/battle/diary/mass
15個の段落がp要素でマークアップされていない……何処がStrictなんだ……
他のStricterも同じ様な事をやっている。li要素内の段落とかdd要素内の段落をp要素でマークアップしなくても良いとか思い込むなよ。

99 ：Name_Not_Found：2006/10/06(金) 01:40:38 ID:???

つhttp://lan.rgr.jp/diary/2006/02a
ふたつ質問
・「liやddの中をp要素でマークアップしなければならない」ということの根拠は？
・>>98のリストは段落の一部を引用しただけで段落ではないと思うが、どうか？

真名垣氏は厳密なStricterではないと思う。

100 ：Name_Not_Found：2006/10/06(金) 02:32:00 ID:???

> 「liやddの中をp要素でマークアップしなければならない」ということの根拠は？
li要素内とか関係なく段落は全てp要素でマークアップするべきである。li要素内とかdd要素内だけ例外とするのは可笑しい。
> >>98のリストは段落の一部を引用しただけで段落ではないと思うが、どうか？
それはそうかも知れないが、li要素内が本当に段落だとしてもp要素でマークアップする人は少ない。
> 真名垣氏は厳密なStricterではないと思う。
本当に厳密なStricterって居るんですか？
一応、私の中での"厳密なStricter"の基準
・p要素省略禁止
・dl要素内はdt要素とdd要素が交互に出現する。
・lang属性の省略を禁止
・object要素を介してブロック要素を含めるのは禁止

---

2番目について補足
dd要素内が段落ならdd要素内にp要素を並べる事によってdd要素の連続を防ぐ事が可能。
それ以外のdd要素の連続はdd要素内に順不同リストを入れる事によって解決します。
dt要素の連続は原文の改変で防げるかと……

101 ：Name_Not_Found：2006/10/06(金) 02:37:01 ID:???

>dt要素の連続は原文の改変で防げる

お前全然Strictじゃないな。たかがマークアップ言語が原文改変してどうすんだ。

102 ：Name_Not_Found：2006/10/06(金) 02:44:08 ID:???

> お前全然Strictじゃないな。たかがマークアップ言語が原文改変してどうすんだ。
意味的にdt要素が連続する様な原文は文章自体が不自然な気がする。
其れを自然な文章に修正する。それだけ。

不自然な文章を修正するとマークアップした時にdt要素が連続することは無い。マークアップする時に修正するのではなく、不自然な文章を修正した後にマークアップする。

103 ：Name_Not_Found：2006/10/06(金) 03:00:27 ID:???

>>100
そんなことがDTDのどこに書いてあるか教えてくれ。
あるいは自分でSchemaを書いたのなら見せてくれ。

104 ：Name_Not_Found：2006/10/06(金) 05:30:09 ID:???

>意味的にdt要素が連続する様な原文は文章自体が不自然な気がする。
>其れを自然な文章に修正する。それだけ。

気がする、だけで原著者の意図から外れて構造いじっていいのか？

>不自然な文章を修正するとマークアップした時にdt要素が連続することは無い。

お前が「感覚的に」不自然だと感じた文書を自分の都合の良いようにいじるだけの話。
dt要素的な語句を意図的に操作するんだから連続しないのは当たり前。いじるのはお前だから。
それが正解（および妥当）だっていう保証も根拠もないだろ。

>マークアップする時に修正するのではなく、不自然な文章を修正した後にマークアップする。

言葉のあや。卵が先でも鶏が先でも「マークアップにあたって改変した」ことになる。

105 ：Name_Not_Found：2006/10/06(金) 05:42:52 ID:???

正しくない文章は正しいマークアップを出来ないんじゃね？
別に原文を校正するのは(勿論注意書きする必要は有るけど)必須な気がする。

106 ：Name_Not_Found：2006/10/06(金) 06:00:06 ID:???

改変と校正の差異に注意されたし

107 ：Name_Not_Found：2006/10/06(金) 06:40:03 ID:???

>100
そもそもリスト中に段落構造が出てくることはそうそうないと思う。
自分が見た限りでは5月上旬の無為徒食日記くらい。

>>105
上手くマークアップ出来ない文章はあるだろうけど、「正しくない」とは言い切れないと思う。

しかし、私は上記に加えて、
・水筒
・タオル
・ちり紙
・ビニールシート
・ビニール袋
・雨具
も、必需品ではないかと思うのだ。

なんてのがいい例。

108 ：Name_Not_Found：2006/10/06(金) 06:47:57 ID:???

Lists in HTML documents
ttp://www.w3.org/TR/1999/REC-html401-19991224/struct/lists.html

ここにある例はどれもliやddの中にpが書かれていないけど
短い箇条書きじゃなくて少し長めの文も例にある
html4.01だけど

109 ：Name_Not_Found：2006/10/06(金) 06:55:45 ID:???

>>107
それをリストにするのがおかしいんだってば。

110 ：Name_Not_Found：2006/10/06(金) 07:11:34 ID:???

>>107の「いい例」は

<p>しかし、私は上記に加えて、</p>
<ul>
<li>水筒</li>
<li>タオル</li>
<li>ちり紙</li>
<li>ビニールシート</li>
<li>ビニール袋</li>
<li>雨具</li>
</ul>
<p>も、必需品ではないかと思うのだ。</p>

ってマークアップするの？

漏れ、よくこういう途中で文が切れて間に別のものが入ってまた途中から文が続く…って書き方を
よくするんだけど、そういう今もそんな書き方なんだけど、
そういう場合は前半で切れている文（>>107の「いい例」は）と
後半から続く文（ってマークアップするの？）のそれぞれを<p></p>でくくっていいの？
それぞれだけだと文章として成り立たないっすよね…？

111 ：Name_Not_Found：2006/10/06(金) 07:15:52 ID:???

リストにしないよ。それだけのこと。

112 ：110：2006/10/06(金) 07:32:21 ID:???

>>111
え？>>110の場合はそもそもリストの話とは関係ないよね。>>110の場合はpreかな。

また場合によっては

<p>>>107は107で</p>
<blockquote><pre>
しかし、私は上記に加えて、
・水筒
・タオル
・ちり紙
・ビニールシート
・ビニール袋
・雨具
も、必需品ではないかと思うのだ。
</pre></blockquote>
<p>と言っている。</p>

といったケースもあるだろうし。

今回も、この二つに分断された「>>107は107で」「と言っている。」や
さらには「また場合によっては」「といったケースもあるだろうし。」を
どうマークアップすればいいのか…ということが先ほどから気になっています。
今までは前後それぞれをpでくくっていたけど個別に取り出すと文章になっていないし…。

113 ：Name_Not_Found：2006/10/06(金) 07:41:57 ID:???

小説などでも文の途中で会話文が入った場合は
句点（。）じゃなくて読点（、）のあとでも改行して
行頭にかぎ括弧（「）を持ってこないといけないルールだけど

　<p>沈む夕陽を見つめ、</p>
　<blockquote>（恥ずかしい言葉）</blockquote>
　<p>と彼は言った。</p>

こうなるのかなあ。会話文が短ければ

　<p>沈む夕陽を見つめ、<q>（恥ずかしい言葉）</q>と彼は言った。</p>

などとしてスタイルシートなどで<q></q>の前後に改行を入れてもいいのかもしれないけど。

（この文章も「マークアップの例」のせいで文章が分断されていますね。）

114 ：Name_Not_Found：2006/10/06(金) 07:44:32 ID:???

>>109
「おかしい」理由をもっと明確に。

>>110
p要素の中にブロックレベル要素（例えばul要素ね）を含む仕様が検討されてます。

>>113
小説は丸ごとpreか、span要素を発言に割り当てるのが妥協案でないかね。

115 ：Name_Not_Found：2006/10/06(金) 07:47:41 ID:???

日曜日にぼくとまさおくん、あきらくん、たかしくんの四人で動物園に行った。
まさおくんとあきらくんは待ち合わせに遅れて来た。
みんなでさるやきりんやぞうを見た。ほかにたぬき、きつね、ポニーなんかもいた。

どうする？

116 ：Name_Not_Found：2006/10/06(金) 07:47:45 ID:???

小説の引用じゃなくて自作小説もpre？自作ポエムはpreでもいいけど。

117 ：Name_Not_Found：2006/10/06(金) 07:48:47 ID:???

素の文ありき、じゃなくてマークアップありき、の人は”マークアップのための文”を作ります。

<p>彼は沈む夕陽を見つめた。</p>
<blockquote>（はずかしい言葉）</blockquote>
<p>そう彼は言った。</p>

<p>彼は沈む夕陽を見つめてこう言った。</p>
<blockquote>（はずかしい言葉）</blockquote>

このような具合です。

118 ：Name_Not_Found：2006/10/06(金) 07:51:26 ID:???

でしょ？

日曜日に動物園に四人で行った。メンバーは以下である。

119 ：Name_Not_Found：2006/10/06(金) 07:53:20 ID:???

マークアップ言語によって自然言語が縛られるこんな世の中じゃ

120 ：Name_Not_Found：2006/10/06(金) 07:55:58 ID:???

>>114
> p要素の中にブロックレベル要素（例えばul要素ね）を含む仕様が検討されてます。

この仕様が採用される前（今）はどうマークアップすればいいんですかー

>>119
ぽいずん

121 ：Name_Not_Found：2006/10/06(金) 07:57:28 ID:???

いや、だからリストにしたいがために
「と」や「や」や「、」を省くのも不自然だと。

122 ：Name_Not_Found：2006/10/06(金) 07:59:08 ID:???

リストじゃない例も出ているのになんでリストにこだわる

123 ：Name_Not_Found：2006/10/06(金) 08:00:23 ID:???

いや一緒だと。

124 ：Name_Not_Found：2006/10/06(金) 08:01:07 ID:???

>>115
それはそれでいいんじゃない？作文でしょ？

125 ：Name_Not_Found：2006/10/06(金) 08:03:22 ID:???

で、今は

>>114
> p要素の中にブロックレベル要素（例えばul要素ね）を含む仕様が検討されてます。

の部分はどうマークアップすればいいのよー！
採用前は地の文章を書き換えるの？んなわけないよね。

126 ：Name_Not_Found：2006/10/06(金) 08:04:28 ID:???

>>124
だから、それをむりやりリストにしたい人がいるんでしょ？
そしてリストにこだわらせないで下さい。

127 ：Name_Not_Found：2006/10/06(金) 08:08:05 ID:???

>>110,112,113
このあたりは今はどうマークアップすればいいんですか・・・？

<p>前半、</p>
<block>ブロック要素</block>
<p>後半。</p>

これで問題ないですか？

128 ：Name_Not_Found：2006/10/06(金) 08:14:56 ID:???

TeXなら万事解決

129 ：Name_Not_Found：2006/10/06(金) 08:18:11 ID:???

>>114
> p要素の中にブロックレベル要素（例えばul要素ね）を含む仕様が検討されてます。

検討されているってことは日本語だけじゃなく他の言語でもそういう文の書き方があって
そんな文をうまくアークアップする方法が求められているってことっすよね？
・・・で、今はそんな文をどうマークアップすればいいのー？？

130 ：Name_Not_Found：2006/10/06(金) 08:19:02 ID:???

>>127
自然言語として自然なら(なんだそれ？)無理やり分断しなくて良いんだよ。ひとつの段落なんだから。
あと前出のセリフはblockquoteじゃない。

131 ：Name_Not_Found：2006/10/06(金) 08:19:30 ID:???

>>122
　>>119
何でもかんでもマークアップ言語に添ったものが正しい文書構造ではないのだし、
マークアップできないから順序を入れ替える、なんて馬鹿げてる。
もちろん地の文書がある程度のレベルに達しているものに限って、の話だが。

>>125
XHTML拡張でもしたら？
仕様は適宜変更されるものだし、暫定的なものに頼って文書書き換えることはないよ。
現状のルールにそぐわないときのためにdiv要素やspan要素使うとか？
そのへんはどこまで自分に妥協を許すかによるけども。

>>126
文中からむりやりリストを省きたい人がいるんでしょ？

132 ：Name_Not_Found：2006/10/06(金) 08:35:44 ID:???

>>131
じゃあ文中の項目を全部リストでやれば良い。複数の可能性のある単数の項目も全部リストでやれば良い。
だからこだわらせんな。ほっとけ。

133 ：Name_Not_Found：2006/10/06(金) 08:39:42 ID:???

四の五の言わずに面倒な話題だと思ったらスルーすればいいのに。
スレ内の全話題に自分が参加しないと気が済まないのかい？

134 ：Name_Not_Found：2006/10/06(金) 08:45:09 ID:???

>>133
書かれたから返したんよ。そういうおまえさんもほっとけない参加したがり屋の同類じゃないか。
粘着するぞ。
うそ。
わかった。ごめんなさい。
じゃあね。

135 ：Name_Not_Found：2006/10/06(金) 08:51:10 ID:???

リストの中にpを入れなければならないとか何とかいう話はどうなったの？
言い出した人は根拠は無くただ気持ち悪いってだけ？

フォームのhidden属性値のあるinput要素の話は
送信ボタンと一緒にliやpの中に入れるってことでFA？

136 ：Name_Not_Found：2006/10/06(金) 10:08:08 ID:???

>>135

Paragraphならリスト内でも pで括る　
ただそれだけでしょ

箇条書きまで pで括るのは違うと思う

hiddenは送信ボタンとセットが無難だと思うな

137 ：Name_Not_Found：2006/10/06(金) 14:48:06 ID:???

無難なStrictってなんなんだぜ？

138 ：Name_Not_Found：2006/10/06(金) 16:22:34 ID:???

>箇条書きまで pで括るのは違うと思う
箇条書きはdd要素内に順不同リストを入れるのでは？

139 ：Name_Not_Found：2006/10/06(金) 16:31:35 ID:???

>>137
とりあえずDTDだけに従うStrict

140 ：Name_Not_Found：2006/10/06(金) 16:40:02 ID:???

質問です。

プログラムソースをolでマークアップするのは間違いでしょうか。
BASICではプログラムが行単位で評価され、その順序にも意味があるので。
行番号自体にも意味があるからtableで番号と内容に分けるのも健闘しているのですが。

昔、BASICをちょっとかじって以来コンピュータからしばらく離れ、
最近、趣味でHTMLを書くようになって、このスレをのぞいています。
「LIST」というコマンドを使ったのを思い出して質問しました。

141 ：Name_Not_Found：2006/10/06(金) 16:44:08 ID:???

<xhtml2:l>ライン</xhtml2:l>

142 ：Name_Not_Found：2006/10/06(金) 17:10:50 ID:???

preがそのための要素だからpre使えばいいんでね？

143 ：Name_Not_Found：2006/10/06(金) 17:33:18 ID:???

>>139
カエラ！ｷﾑﾗ

144 ：Name_Not_Found：2006/10/06(金) 17:58:06 ID:???

>>140
olは番号付きリストじゃないよ。UAが勝手に番号を付けているだけ。
preとcodeかな……

145 ：Name_Not_Found：2006/10/06(金) 18:10:02 ID:???

>>139
それはValid

146 ：Name_Not_Found：2006/10/06(金) 18:30:53 ID:???

<div>ああああ</div>
<div><p>あああ</p></div>

だと、前者はやっぱり良くないの？

147 ：Name_Not_Found：2006/10/06(金) 18:44:25 ID:???

そんな唐突に

148 ：Name_Not_Found：2006/10/06(金) 21:28:05 ID:???

>>145
Strict DTDに従えば一応はStrictじゃね？

149 ：Name_Not_Found：2006/10/06(金) 23:13:30 ID:???

>>146
正直このスレにいる人間のレベルではわからない気がする。
そういうレベルの高い質問は、ほかのスレで…
ここは、隔離スレなので…

150 ：Name_Not_Found：2006/10/06(金) 23:20:03 ID:???

バカらしくてスルーされたのにｗ

151 ：Name_Not_Found：2006/10/06(金) 23:42:10 ID:???

>>146,149
ﾜﾛﾀ

152 ：Name_Not_Found：2006/10/07(土) 00:19:10 ID:???

>>148
>>145は理想が高すぎて現実と乖離しちゃってるんだよ。

153 ：とあるpro：2006/10/07(土) 03:15:58 ID:???

>>146
前者だと本当のStrictにならない。

divはグループ化の要素であって、直にインライン要素などを含ませては行けない。
よって、前者はStrict違反になる。
この辺は難しいのか誰も答えられてなかったので、
私が変わりに答えました。

何かほかに聞きたいことが有ったら、とあるpro様へと本文に書いてもらえれば、
仕事の合間にレスします。

154 ：Name_Not_Found：2006/10/07(土) 03:38:21 ID:???

>>153
釣りにマ(r

155 ：Name_Not_Found：2006/10/07(土) 03:52:33 ID:???

>とあるpro様

頭が可哀想な人なんだな

156 ：Name_Not_Found：2006/10/07(土) 03:53:44 ID:???

＞Strict違反になる。
＞この辺は難しいのか誰も答えられてなかったので、
＞私が変わりに答えました。

ﾊｹﾞﾜﾛﾀ

157 ：Name_Not_Found：2006/10/07(土) 03:56:13 ID:???

＞divはグループ化の要素であって、直にインライン要素などを含ませては行けない。

え？どの仕様書にそんなことが？

158 ：Name_Not_Found：2006/10/07(土) 04:00:51 ID:???

>>157
ないよ。
ないけどそうなの。こだわりたいし、実際そうであるべきと本気で思ってるの。
俺達ヘンだから隔離されてるの。生暖かく見守ってね。

159 ：Name_Not_Found：2006/10/07(土) 04:16:29 ID:???

＾＾；

160 ：Name_Not_Found：2006/10/07(土) 04:16:58 ID:???

>>157
divは単なる枠だからかな。
つまり、div直下にインライン要素を入れた場合、
body直下にインライン要素を入れたのと同じ状態ということか。

＞各々、内容が行内であるか(SPAN)ブロックレベルであるか(DIV)は定めるが、他のプレゼンテーション的語彙を示すことはない。

ということが、そのことを示していると言えるのではないだろうか？

161 ：Name_Not_Found：2006/10/07(土) 04:26:38 ID:???

枠ｗ

162 ：Name_Not_Found：2006/10/07(土) 04:28:43 ID:???

じゃあ <object> とか <button> とか囲むときってみんな <DIV> 使わないで <P> 使ってるの？
「<P> は文章の段落」としてる人はその場合何使えばいいと？

163 ：Name_Not_Found：2006/10/07(土) 04:34:28 ID:???

>>162
p使ってる

164 ：Name_Not_Found：2006/10/07(土) 04:37:08 ID:???

>>162
文書の本体は文章じゃなくてもいいんだ。段落も文章じゃなくてもいい。
「文」の文字で錯覚してるんだ。p要素の段落は、作文や小説の段落や説や章とはちょっと違うと本気で思ってる。

165 ：Name_Not_Found：2006/10/07(土) 04:45:43 ID:???

>>162
pを勝手に文章の段落にしちゃってる奴はここにいないでしょ。

166 ：Name_Not_Found：2006/10/07(土) 04:50:31 ID:???

>>162
<button>ってすでに、ブロックレベル要素の<form>の中にないか？

167 ：Name_Not_Found：2006/10/07(土) 04:56:10 ID:???

えー、じゃあ「文章の段落」をマークアップするときはわざわざ <p class="文章"> みたいにやってるの？
<p class-"object"><object /></p> とかして？

ここでスタイルの話になるのは関係ないとは思うけど、利便性の問題として
もしそうじゃなかったら例えば「文章段落は字下げをする」ってスタイルも適用しにくくならないか？

文章に限らず、ある要素が、特にリストや他の要素にあたらないものならなんでもかんでも P 使うってのは、
なんでもかんでも DIV を使うのとどう違うんだろう。

たとえば、仕様に <object> を囲む要素は <container> 要素を使うとか
<button> を囲むときは <element> 要素を使うとかあったら <P> じゃなくそっちを使うわけでしょ。
自分としてはその役割が <P> じゃなく <DIV> だと思ってたわけなんだが。

>>166
<form> 直下にインライン置けないジャン。

168 ：Name_Not_Found：2006/10/07(土) 05:13:55 ID:???

>>167
あー、そこは意見が分かれるね。
段落の広義やら狭義やら独自解釈で「他に該当する要素がないからPにしているわけじゃない」と言い張るね。

あなたもヘンな人だから一緒に隔離されましょう。

169 ：Name_Not_Found：2006/10/07(土) 05:19:05 ID:???

divで括ったらおかしいやん

<div><input ～ /></div>

はおかしいだろう

<dt><label></label></dt>
<dd><input ～ /></dd>

ならわかる。

あるいは

<p><input ～ /></p>

やなあ。やっぱり。

170 ：Name_Not_Found：2006/10/07(土) 05:31:53 ID:???

隔離 orz
まあヘンだとは自覚してるｗ

> <div><input ～ /></div>
やるときは <div class="submit"><input type="submit" ～ /> ・・・ </div> とかだろうけど
残念ながらこれがおかしいとは感じないんだよなあ。
名前付き input だったら dl とか ul とか使うけど、submit はリストにする必要性を感じないので、
「他に該当する要素がないから仕方ない」と思っちゃう。

171 ：Name_Not_Found：2006/10/07(土) 07:24:16 ID:???

>>153
タクトはこんなスレに来るなよｗ

>>169
え？おかしいかね？って素で思った。

172 ：Name_Not_Found：2006/10/07(土) 08:58:49 ID:???

>>170
>>171

あら、おかしいと思うのオレだけ？

<div class="submit"><p><input type="submit" ～ /></p></div>

ならわかるんだけどねえ…

173 ：Name_Not_Found：2006/10/07(土) 09:14:14 ID:???

DIV厨の次はP厨がトレンドか。

だから、本当のstrictだか偽物だかしらんが、

1)どこの団体が出したSpec.に書いてあるんだか、出典を示せ。W3CなのかISOなのか、俺様脳内定義なのか
2)俺様定義なら、昔のフラット論争の時くらいの、DTD自作して配るくらいの気概はないのか

ないなら、そもそもそんなドメイン特有の用途には独自のスキーマで定義するしかない。この板の住人が使う程度なら、DocBookやらで十分だろうが。あるいはHTMLにこだわるにしても、microformatsなりDublin Coreで用が足せるだろ。

formだけは話が違うかも知れないが。

174 ：Name_Not_Found：2006/10/07(土) 15:06:46 ID:???

p厨ってｗ

不適切でないものとしてpは妥当だろう

175 ：Name_Not_Found：2006/10/07(土) 15:34:26 ID:???

divに必ずpやらブロック要素を入れたがる人を言ってるんじゃない？

176 ：Name_Not_Found：2006/10/07(土) 15:34:54 ID:???

P厨か。新しいな。

177 ：Name_Not_Found：2006/10/07(土) 15:44:34 ID:???

pでも食ってろdiv

178 ：Name_Not_Found：2006/10/07(土) 15:56:02 ID:???

>>172
DIVはコンテナだと思い込んでる人がやりそう。

179 ：Name_Not_Found：2006/10/07(土) 16:16:11 ID:???

>>172
＞<div class="submit"><p><input type="submit" ～ /></p></div>

これなら、

<p class="submit"><input type="submit" ～ /></p>

が、正しい記述。

180 ：Name_Not_Found：2006/10/07(土) 16:23:09 ID:???

>>177
ちょっとだけ噴いたｗｗ

181 ：Name_Not_Found：2006/10/07(土) 16:39:06 ID:???

>>179

いや、そうでしょ

それを

<div class="submit"><input type="submit" ～ /></div>

とかいうから <div ～><p>～　にしたまでだよ

182 ：Name_Not_Found：2006/10/07(土) 16:49:17 ID:???

個人的には

◎ <div class="submit"><input type="submit" ～ /></div>
○ <p class="submit"><input type="submit" ～ /></p>
× <div class="submit"><p><input type="submit" ～ /></p></div>

183 ：Name_Not_Found：2006/10/07(土) 16:51:33 ID:???

それだとさ、君は

◎ <div class="submit"><a href="～">～</a></div>
○ <p class="submit"><a href="～">～</a></p>

ってことかい？

div直下のインライン(またはインラインブロック)要素に拒否反応起こすんだが…

184 ：Name_Not_Found：2006/10/07(土) 16:56:10 ID:???

そんなのは <a> の内容によるし、一緒に考えるのはおかしい。

まあ、だいたいリンクのみのときはULリストになると思うのだが。文章の中に書くなら P だし。
そんなことわかってるでしょう？

185 ：Name_Not_Found：2006/10/07(土) 17:14:29 ID:???

p使うならdivは要らないってだけで、
div使ってる所にp使うのはおかしいだろって話でしょｗ

186 ：Name_Not_Found：2006/10/07(土) 17:19:17 ID:???

> div使ってる所にp使うのはおかしい
　div使ってる所にさらにp使うのはおかしい

でおｋ？

187 ：Name_Not_Found：2006/10/07(土) 17:22:03 ID:???

>>175
入れなきゃダメ

188 ：Name_Not_Found：2006/10/07(土) 19:29:29 ID:???

>>187
根拠は？DIVは汎用ブロック要素であってコンテナじゃないよ。

189 ：Name_Not_Found：2006/10/07(土) 19:41:08 ID:???

根拠はないけど入れなきゃダメ

190 ：Name_Not_Found：2006/10/07(土) 20:22:01 ID:???

なにこの意地の張り合い。

191 ：Name_Not_Found：2006/10/08(日) 00:23:20 ID:???

>そんなのは <a> の内容によるし、一緒に考えるのはおかしい。

いや aじゃなくてもまあいいんだが

とにかくdivで囲うんなら必要ないだろうって話

<input ～ />

だけでもいいんでしょ　そういう人は。

意味もたないdivで囲う意味がないやん

192 ：Name_Not_Found：2006/10/08(日) 01:05:27 ID:???

>>188
＞各々、内容が行内であるか(SPAN)ブロックレベルであるか(DIV)は定めるが、他のプレゼンテーション的語彙を示すことはない。

日本語と英語が理解できれば、その解釈はしないはずなのだが。

193 ：Name_Not_Found：2006/10/08(日) 02:24:56 ID:???

だいたいなんのために DIV は %flow になってると？
行内はインラインの中の「行内」に使えるだけでしょ。

>>191
その理論でいくとどこにもDIV使う意味がないよね。っていうかいらないよね。
現在のHTMLにある数少ない要素で全てがマークアップできると思うほうがどうかしてるよ。
それだったらダブリン・コアなんていらなかったでしょ。
相当する要素がないと思ってるから DIV 使うしかしょうがないんだよ。

194 ：Name_Not_Found：2006/10/08(日) 03:02:44 ID:???

無理矢理「相当する要素がない」と思おうとしているようにしかみえん。

195 ：Name_Not_Found：2006/10/08(日) 04:36:01 ID:???

>>193

>その理論でいくとどこにもDIV使う意味がないよね。っていうかいらないよね。

まったくその通り
勘違いしてると思われ

前にもでたが、divは何の意味もないんだって

196 ：Name_Not_Found：2006/10/08(日) 06:19:07 ID:???

何の意味もないわけではないと思うが、
使わないで済むのなら極力使わないほうがいいな。
div直下にインラインとか論外。

でもmap内にulのナビゲーションは
map自体はインライン要素だから何かブロック要素に入れなきゃならないけど、
これを入れるコンテナがdivしか思い付かない・・・・
他に何か考えつく識者、おられるか。

197 ：Name_Not_Found：2006/10/08(日) 06:27:18 ID:???

論争見て、
ddの中に必ずpを記述してる人を思い出した。

198 ：Name_Not_Found：2006/10/08(日) 06:31:53 ID:???

いや、

<div><p>～</p></div>

っていうのは皮肉だろう

div要素直下のinputインラインブロック要素に対してのな

199 ：Name_Not_Found：2006/10/08(日) 06:36:19 ID:???

>>196

mapなんて使うか？？？
いらないと思うんだが

200 ：Name_Not_Found：2006/10/08(日) 06:39:15 ID:???

>>196

つか map要素って
area要素を包括しない場合には　ブロックレベル要素　だろ

divで括る必要ないやん

201 ：Name_Not_Found：2006/10/08(日) 06:41:40 ID:???

map要素と言えば、クリッカブルマップでもないのに、

<map id="Navigation">
　<ul>
　　<li><a href="～">～</a></li>
　　<li><a href="～">～</a></li>
　　<li><a href="～">～</a></li>
　　<li><a href="～">～</a></li>
　</ul>
</map>

とかやってるやつもたまにいるな

おまえ、それ、普通のリストでいいやん　って思う

202 ：Name_Not_Found：2006/10/08(日) 07:46:16 ID:???

>>192
その文章を根拠にdiv=コンテナって判断してるの？
だとすると併記されているspanについてはどう判断しているの？
それから
ttp://www.w3.org/TR/html401/struct/global.html#h-7.5.4
> The DIV and SPAN elements, in conjunction with the id and class attributes,
> offer a generic mechanism for adding structure to documents.
この文をどう解釈しているの？
id・class属性と共に、のくだり。

203 ：Name_Not_Found：2006/10/08(日) 08:03:05 ID:???

DIV要素に必ず一つ以上のブロック要素を含めないと気がすまないって人は
(%flow;)*
について説明してください

204 ：Name_Not_Found：2006/10/08(日) 08:41:55 ID:???

>div直下にインラインとか論外。

え？？？

205 ：Name_Not_Found：2006/10/08(日) 09:07:39 ID:???

>div直下にインラインとか論外
自作DTDですか？

てーかけっこーそーゆーひと多いんかねｗ
なんか最近のレス見てたら半々な気がして怖い。重複してるんだろうけど……。

206 ：Name_Not_Found：2006/10/08(日) 09:19:47 ID:???

>>205

ほんとだね
ていうか、プロとか言ってるやつらでもやってるからね

>>203　とか >>204 とか見るとこっちが　え？？？　ってなる

207 ：Name_Not_Found：2006/10/08(日) 09:19:49 ID:???

自分でそういうルールを作るのはいいけど
押し付けようとするのはやむぇとぇ

208 ：Name_Not_Found：2006/10/08(日) 09:20:12 ID:???

このIDのない板でその手の俺理論を主張する奴は
何度もしつこく主張する傾向があるので、
その状況下で常識的な見解と半々ということは、
このスレに常識が十分残ってるということだから、
喜ばしいことだと思うよ。

しかし、こういう一般的ではないスレは専門性の高さとは
違う部分で一般的ではない人も何か勘違いして紛れ込むから、
どう解釈してもおかしい人っていう人が湧きやすいのはしょうがない。

209 ：Name_Not_Found：2006/10/08(日) 09:22:09 ID:???

間違えた
論外につっこんでるのか

論外でしょう
文法があってればいいと言うんなら

<bodY>
<div><a id="top" name="top"></a></div>

<div>なんたら<span style="font-weight: bold;">かんたら</span</div>
</body>

とかもなんでもありになっちゃうからね
極端な話

210 ：Name_Not_Found：2006/10/08(日) 09:23:15 ID:???

>>205に対する>>206のレス内容の意味がよくわからん・・・

211 ：Name_Not_Found：2006/10/08(日) 09:23:41 ID:???

たぶん >>209 のどこがいけないの？

っていうヤツがいっぱい紛れ込んでいるんだな・・・

レベル落ちたな・・・

212 ：Name_Not_Found：2006/10/08(日) 09:24:14 ID:???

>>209
どの書き込みが「間違えた」なんですか
レス番を名前欄などに書いてください

213 ：Name_Not_Found：2006/10/08(日) 09:24:48 ID:???

>>210

すまん　勘違い

プロでもdiv直下のインライン要素うやってるやつ多い

そして、それやってるやつは body直下のインライン要素というミスも
８割方やっちゃってる

214 ：Name_Not_Found：2006/10/08(日) 09:27:02 ID:???

だから>>209は>>203にある
DIV - - (%flow;)*
をどう解釈しているのか説明して

215 ：Name_Not_Found：2006/10/08(日) 09:29:00 ID:???

>>214

だからさあ

文法があってればいいと言うんなら

<body>
<div><a id="top" name="top"></a></div>

<div>なんたら<span style="font-weight: bold;">かんたら</span></div>
</body>

でもいいことになる
おかしいと思わないならいいんじゃないか

216 ：Name_Not_Found：2006/10/08(日) 09:29:17 ID:???

>>213
bodyは
O O (%block;|SCRIPT)+ +(INS|DEL)
だから「body直下のインライン要素」はだめだけど、
今はｓんなことをやっている人を例に持ち出されても。

divは
- - (%flow;)*
だよ？

217 ：Name_Not_Found：2006/10/08(日) 09:31:19 ID:???

>>215を参照

文法だけ合ってればいいっていってるんなら
ほんとにレベルが落ちたんだな
としか言えない…

>>215 も当たり前なんだろうな

218 ：Name_Not_Found：2006/10/08(日) 09:34:53 ID:???

>>215

>>202を見れ
divやspanはid属性やclass属性をつけて著者が意味づけをする。
コンテナとして意味づけをするならブロック要素を包括するのが望ましいが
それ以外の意味づけをした場合は他のブロックレベルの文書構造要素（pなど）
と同等の振る舞いをする

219 ：Name_Not_Found：2006/10/08(日) 09:42:01 ID:???

>>218

流れに合わせると

<bodY>
<div class="anchor"><a id="top" name="top"></a></div>

<div class="intro">なんたら<span class="attention">かんたら</span></div>
</body>

こんなとこか？

なら<div class="section">～</div>とかもあり、っていうことになるんだろうな
id, class付ければいい、ってやつはdiv/spanだけで足りると思うんだが　

220 ：Name_Not_Found：2006/10/08(日) 09:44:47 ID:???

<a id="top" name="top"></a> をカウンターに置き換えてみるテスト。

つまり
　　<body>
　　<div>10010</div>
　　</body>
これはダメで
　　<body>
　　<p>10010</p>
　　</body>
これはイイ、っていうのでしょ？

それがわからない。
明らかに P の中がそれだけ見れば「ただの意味のない数字でしかない」のに、
それを P で済ますのと、DIV で済ますのとどう違うのだ？

P って文章やテキストが入った段落を示すものでしょう？
ただの数字もテキストと言えようが、それでよしとするなら、P の意味が希薄にならないか？
私はもっと P の意味を尊重したい。
だから <div id="counter">10010</div> で使うしかないと思ってる。

221 ：Name_Not_Found：2006/10/08(日) 09:46:06 ID:???

>>215

ttp://www.w3.org/TR/html401/struct/global.html#h-7.5.4
> Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc.,
> we use DIV and SPAN to achieve the desired structural and presentational effects.

これをどう解釈したか説明してほしい

222 ：Name_Not_Found：2006/10/08(日) 09:50:31 ID:???

> id, class付ければいい、ってやつはdiv/spanだけで足りる
あなたは阿呆か？
既にある要素を使わないでどうする。

RSSだって、既存の要素で済めばそれが一番だけど、ない場合は仕方なくダブリン・コアなどのモジュールを使う。
HTMLではそれが簡単にできないから仕方なく DIV に id/class を付けて使うんじゃないか。

223 ：Name_Not_Found：2006/10/08(日) 09:50:48 ID:???

>>202
HTML 4.01の話なんだな
ならいいんじゃないのか…勧告自体がボロボロだしな…

>>220

<a id="top" name="top"></a>

はのa要素はさ、XHTMLじゃやるやつはいないとは思うが
まるっきり意味がない

カウンターとはだからちょっと違うと思われ

カウンターなら、

<body>
　<ul id="counter">
　　<li>10010</li>
　　<li>00540</li>
　　<li>00010</li>
　</ul>
</body>

とかでいんじゃないの
キャプションつけたいなら dlって手もある

224 ：Name_Not_Found：2006/10/08(日) 09:52:10 ID:???

既存の要素では望ましい構造やプレゼンテーション効果が得られない（適していない）ため
div+classでサイト制作者が適切な意味付けをしてその効果を得るんであって、
コンテナとしての意味付けをしたならそういった振る舞いをしてもいいけど
コンテナとしてしか使えないと理解してしまうのはどうかと。
自サイト内でそういう使い方しかしないようにするのは別に構わないけどさあ。

225 ：Name_Not_Found：2006/10/08(日) 09:52:31 ID:???

>>222

極端な例だけどね　それはね

もともとはさ　p要素でもいいと思われるものを
divで囲ってるところからそもそも始まってる

p要素だと言えない理由がないからね
じゃあdiv要素よりはp要素の方が適切だろう
って話

226 ：Name_Not_Found：2006/10/08(日) 09:58:32 ID:???

<p><a id="top" name="top"></a></p>
はよくて
<div class="nantoka"><a id="top" name="top"></a></div>
がダメな理由がわからない。

むしろリンクだけのテキストを P に含ますほうが気持ち悪いと感じるんだけどｗ

もしそうなら、
<ul>
　　<li><p><a href="">home</a></p></li>
　　<li><p><a href="">text</a></p></li>
　　<li><p><a href="">link</a></p></li>
</ul>
とかもおかしく感じないんだろうね？

227 ：Name_Not_Found：2006/10/08(日) 09:59:05 ID:???

>>224

自サイト内でやるのはいいと思うよ
そもそもこの話も好みもある話だしな

押しつけてるわけでもない
どういう理由でそうするのかって話

そっちがよければオレもそっちを採用するｗ

>既存の要素では望ましい構造やプレゼンテーション効果が得られない（適していない）ため

ただプレゼン云々はHTML・XHTMLの範疇じゃないでしょ

228 ：Name_Not_Found：2006/10/08(日) 09:59:25 ID:???

>>223
> HTML 4.01の話なんだな

じゃああなたはDIVについてどのバージョンの勧告を読んでるの？その箇所のリンクを示して。

229 ：Name_Not_Found：2006/10/08(日) 10:02:17 ID:???

>>226

極端な例。
XHTMLなら

<a id="top" name="top"></a>

なんて使わないっしょ。
リンクじゃないしな　よく見れ

後者のリストも中身によってはあり

でさ　そもそもが　p　か　div　かどっちで括ろうかな
っていう内容についての話だったわけでしょ

p　でだめな理由がなければ、divよりは適切なp要素にするのは当たり前

230 ：Name_Not_Found：2006/10/08(日) 10:02:41 ID:???

プレゼン云々はHTML・XHTMLの範疇じゃない、って、
http://www.w3.org/TR/html401/struct/global.html#h-7.5.4
に出てくる「presentational」を何のことだと思ってるの？

231 ：Name_Not_Found：2006/10/08(日) 10:04:41 ID:???

釣りだろｗ
試されてるんだよｗ
流せよｗｗｗ

232 ：Name_Not_Found：2006/10/08(日) 10:05:32 ID:???

なんかかみ合ってないようだが

p じゃないという理由があれば div　でいいんじゃないの

今回の話はそういうことじゃない
そこをなんかごっちゃにしてるからかみ合わない

p でもいいかもしれないと思われるものを、div で括っちゃってるから
それなら p でいいだろう　って話なんだ

233 ：Name_Not_Found：2006/10/08(日) 10:05:48 ID:???

何を試しているのかわからん
自分がバカかどうか試しているのか

234 ：Name_Not_Found：2006/10/08(日) 10:08:26 ID:???

>>232
> p でもいいかもしれないと思われるものを、div で括っちゃってるから
> それなら p でいいだろう　って話なんだ
そっちこそ、今回の話はそういうことじゃない、じゃない？
pや各種リストでいいものでも全てdivでするのは論外、ってのは共通の前提じゃないの？

235 ：Name_Not_Found：2006/10/08(日) 10:10:05 ID:???

お互いに違う論点を取り上げて話をしていたから話がかみ合っていなかった、
でFA？

236 ：Name_Not_Found：2006/10/08(日) 10:11:05 ID:???

>>234

どっから読んでるかわからんのだが
そもそもはさ

<input type="submit" ～　/>

をなにで囲むか、って話だったの

p要素でだめな理由があるんなら　オレもdiv要素でいいと思う
ただオレはp要素がダメとは言えないんじゃないかなって思ったわけ

237 ：Name_Not_Found：2006/10/08(日) 10:11:27 ID:???

>>217
> 文法だけ合ってればいいっていってるんなら
文法より厳しい制約にすれば正しいってもんでもないんだよ。
不要に厳しい制約もまた間違い。
「文法で許されているものはすべて正しい」んじゃなくて、
「文法で許されていないことを制約するんだから、ちゃんと理由を言いましょう」
という話だな。

body直下にインライン要素をおくことを隠蔽するためだけに
divを濫用するアホがいくらうざいからって、その反動でdiv直下の
インライン要素をなんでもかんでも禁止してしまおうと思うのは、
過剰反応か怠慢だよ。ちゃんと場合に応じて判断しましょう。
禁止すべき理由を考えずに「なんでもかんでも禁止すりゃいいや」
ってのは同レベルのアホだよ。

>>220
というか、p要素にすればいい、というのは>209が叩くような
「形式的に文法だけ守っていればよい」という発想だな。
その文法がW3Cルールから脳内ルールに替わっただけ。

それが、>172みたいに「とりあえず段落でもないのに無理やり
p要素だということにしてしまえばOK」という発想につながる。

div要素は、class属性を指定しようがしまいがp要素の「段落」
という意味のような意味付けはできない。しかし、当然まったく
意味がないわけではなく、構造を付加することが出来るというのは
仕様で明記されてることだな。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.5.4
　> DIV要素とSPAN要素は、id属性及び class属性と併用することで、
　> 文書に構造を付加するための一般機構を提供する。

238 ：Name_Not_Found：2006/10/08(日) 10:12:11 ID:???

>>229
おまえがよく見れｗわざわざコピペしてやったのに。だいたいそういう話じゃないだろｗ

> divよりは適切なp要素にするのは当たり前
何をもって「適切」としてるんだ？
DIV はコンテナだから、なんて話はお断りね。

239 ：Name_Not_Found：2006/10/08(日) 10:13:45 ID:???

>>236をul/liで囲む俺が登場

したら話がややこしくなる？

240 ：Name_Not_Found：2006/10/08(日) 10:15:25 ID:???

>>238

p要素でないと言える理由がないから
別に理由があるならオレはどっちでもいいんだ

なんか知らんが勝手にかみつくなよ

>>239

既出
それでいい場合もあると結論がでてる

241 ：239：2006/10/08(日) 10:20:47 ID:???

各入力欄を定義リストでやってんだから
送信ボタンもリストでいいじゃん

242 ：Name_Not_Found：2006/10/08(日) 10:21:10 ID:???

>>237

ほどほどいい具合にまとめてくれてると思う

ほんとにあまりわかってない人と
そこそこわかっている人の話だからかみ合ってない

243 ：Name_Not_Found：2006/10/08(日) 10:24:33 ID:???

お、おれも>>237みたいなことを言いたかったんだよ！

244 ：Name_Not_Found：2006/10/08(日) 10:25:08 ID:???

>>241

読むのがめんどくさいんだろうｗ
定義リストでもいいんだ

で、この場合のはさ、

<form ～>
<fieldset>
<legend>～</legend>
<dl class="input">
　<dt><label ～>ラベル</label></dt>
　<dd><input type="text" ～ /></dd>
　<dt><label ～>ラベル</label></dt>
　<dd><input type="text" ～ /></dd>
</dl>

<p class="submit">　　　←ここな
<input type="hidden" ～ />
<input type="submit" ～ />
</p>

</fieldset>
</form>

じゃだめなの？って話

245 ：Name_Not_Found：2006/10/08(日) 10:25:19 ID:???

>>236
うん、
だから P はテキストを入れるものだから <input> を入れるのはおかしい、って意見。

P は仕様書のどこにあるかっていうと、「テキスト」の項目にあるわけ。
「テキスト」の項には「フレーズ要素: EM、STRONG、DFN, CODE、SAMP、KBD、VAR」とかの各種インライン要素、
「BLOCKQUOTE要素とQ要素」などの引用文、
あと「上つきと下つき: SUB要素とSUP要素」と、「段落 P 」だけ。

ここから見てわかるように、P は本来「テキスト」つまり「文」をマークアップするものなんだよ。
「文」以外になんでも入れていいものなら、「HTML文書の全体構造」の項に P をいれればよかった。
わざわざそこにいれるってことは、「文」を入れるものだという前提なわけでしょ。

だから「<input> は文だ」と言わない限り、P でいれるのはおかしいと感じるわけ。

246 ：Name_Not_Found：2006/10/08(日) 10:26:21 ID:???

「送信」とか書かれたボタンが一個転がっているだけなのにpは変。
順不同リスト一択

247 ：Name_Not_Found：2006/10/08(日) 10:26:52 ID:???

>>237 わかりやすいｗ

248 ：Name_Not_Found：2006/10/08(日) 10:28:27 ID:???

心の中ではずっと237と同じことを主張していたんだ！ただうまく表現ができないだけなんだ・・・

249 ：Name_Not_Found：2006/10/08(日) 10:28:40 ID:???

>>245

>だから P はテキストを入れるものだから <input> を入れるのはおかしい、って意見。

それ言っちゃうとさ
単体の画像なんかはすべて div直下にいれないといけない
そうやってやってるの？

まあinputとかが特殊なのはわかるんだけどさ

250 ：Name_Not_Found：2006/10/08(日) 10:29:08 ID:???

画像も順不同リスト

251 ：Name_Not_Found：2006/10/08(日) 10:30:31 ID:???

リストにボタン入れるのはもちろんOK。
だってリストの意味は「リスト」でしかないから、ボタンのリストは何らヘンじゃない。

でも、もしそれで DIV に入れるのは変、というのになったら、それはそれでおかしい。
それだと「入れる要素がないからとりあえずリストに入れておきますね」って考え方でしかないように思う。

252 ：Name_Not_Found：2006/10/08(日) 10:31:51 ID:???

>>250
>>251

話そらすとややこしくなる

>単体画像

って書いてるよ

253 ：Name_Not_Found：2006/10/08(日) 10:33:57 ID:???

>単体画像

ulはli+
つまり一個以上のli。一個であってもよい。

254 ：Name_Not_Found：2006/10/08(日) 10:34:15 ID:???

>>240
> p要素でないと言える理由がないから
そもそも、p要素であると言える理由が出てないんだ。

「文章の段落ではない」と言うが、それはどこのソースに
よるのかさっぱり不明のまま。
p要素が「9.Text」の項にあるのを見ても、仕様上では
段落という言葉がテキストを主とした普通の意味の段落を
意図して使われているだろうということは容易に分かる。

255 ：Name_Not_Found：2006/10/08(日) 10:34:29 ID:???

>>253は>>252へのレスです・・・

256 ：Name_Not_Found：2006/10/08(日) 10:36:17 ID:???

>>249
俺はそうやってる、ときもある。
<img> は <object> (や <applet> や <iframe>) なんかと同じ。
もし <iframe> を P で囲うのをおかしいと感じるなら、それは DIV で囲うしかないわけで、
そうなら、単体の IMG を DIV で囲ってもおかしいことはない。

もちろん、P の中でも <img> がでてきたらそれでいいと思うし、リストで使うこともあるし、それはそれ、これはこれ。

257 ：Name_Not_Found：2006/10/08(日) 10:37:09 ID:???

>>253

テキストしかだめっていうなら

<p><img ～>の画像はアイコンです</p>

もおかしいということになるよ
実際にはテキスト以外も入るし　それはしょうがない

>>254

まあそうだよね
それが不明だからどうとでもとれる

テキストの項にあるのは分類上の一言で片付けられる

258 ：Name_Not_Found：2006/10/08(日) 10:37:54 ID:???

>>243,,247,248
こういう自演をすると途端に説得力が無くなるからやめたほうがいい。
自演でなくても同じことだが。

259 ：Name_Not_Found：2006/10/08(日) 10:39:08 ID:???

>>256

ならばinputがダメな理由はないでしょ？

iframeとかは代替手段がないからどうかと思うけどね
inputのボタンなんかは一応代替手段がある

260 ：Name_Not_Found：2006/10/08(日) 10:39:27 ID:???

>>249
> 単体の画像なんかはすべて div直下にいれないといけない
本当に画像がHTMLのように段落中に表示されている文章を
読んだことがないのか？よくあるぞ。

261 ：Name_Not_Found：2006/10/08(日) 10:40:18 ID:???

>>260

よくよめって

>>245の理由ならそうなっちゃうぞ　って話

262 ：Name_Not_Found：2006/10/08(日) 10:40:49 ID:???

じゃあなんでformの例にさんざんpが使われてるんだよｗ
都合の良いとこだけ仕様書からひっぱるなよｗ

263 ：Name_Not_Found：2006/10/08(日) 10:40:56 ID:???

>>258
> >>243,,247,248
> こういう自演をすると途端に説得力が無くなるからやめたほうがいい。
> 自演でなくても同じことだが。
と思わせるためのアンチの仕業でしょ

264 ：Name_Not_Found：2006/10/08(日) 10:41:46 ID:???

>>262

わかってないなら書き込まないように
まずよく嫁

265 ：Name_Not_Found：2006/10/08(日) 10:42:24 ID:???

frameはstrictではない

266 ：Name_Not_Found：2006/10/08(日) 10:44:43 ID:???

>>259
全然わかってないｗ

話の流れで
<p>これをみてください！</p>
<p><img src="" alt="" /></p>
<p>なんとかかんとか！</p>
ってときもあるだろう。
これらは「一連の文章」の中に画像が包括されてるわけ。

<p>このボタンを押してね → <input /></p>
ってこともあるでしょう。（まあやらないけど）

それらの場合はいいんじゃないの？
なんでもかんでも決められないとわからない子なんですか？
それはそれ、これはこれ、って言ったでしょう。

267 ：Name_Not_Found：2006/10/08(日) 10:47:56 ID:???

「単体の画像」とか特殊な状態をいってたのに、
その前提条件で交わした意見を全ての場面で持ち出すからわけわからなくなる。

268 ：Name_Not_Found：2006/10/08(日) 10:49:30 ID:???

>>266

「一連の文章」ってことなら
<input　～ />をpで括っても「一連の流れ」で済む

だめな理由にならないじゃない

ていうか、「一連の文章」だから、っていうのもちょっと違和感あるなあ

269 ：Name_Not_Found：2006/10/08(日) 10:49:57 ID:???

>>266
> <p>これをみてください！</p>
> <p><img src="" alt="" /></p>
> <p>なんとかかんとか！</p>

一連の文章なら
<p>これをみてください！<img src="" alt="" />なんとかかんとか！</p>

とすべきじゃない？
上の段落と下の段落に画像が置かれているのなら画像はul/liで

270 ：Name_Not_Found：2006/10/08(日) 10:50:59 ID:???

>>261
だから段落中に画像が出てくる文章を読んだことがないのか、と。
インライン画像が入ってる段落ってのは普通にあるわけで、
「画像が入っても段落なら、inputが入っても段落だ」なんて
成り立たんのよ。

>>257
> テキストの項にあるのは分類上の一言で片付けられる
分類は意味でなされてるんですが。段落という言葉に、
input要素をp要素のなかに含める派が主張するような
特段の意味がどこにあるのか明示されないかぎり、
>168の言う
　> 段落の広義やら狭義やら独自解釈で
　> 「他に該当する要素がないからPにしているわけじゃない」と言い張るね。
というような解釈は単なる屁理屈で筋が通りません。
(言葉の定義をいくらでも変えていいなら、仕様なんて
あってないようなものになってしまうからね。)

271 ：Name_Not_Found：2006/10/08(日) 10:51:22 ID:???

>>269

そう、その違和感があった
代弁サンキュー

でも>>266も悪いとはオレは思わない
だから、なんで input の場合はだめなんだ？って話

272 ：Name_Not_Found：2006/10/08(日) 10:52:04 ID:???

>>262
仕様書の例は必ずしも strict じゃないのは、あなたやみんなも知っていることでしょう。
仕様書の例が strict だと言うなら、いろいろな場面においてここの議論とはかみ合わないと思うのだがどうか？

だからといって、仕様書のDTDや説明はおかしくない、という立場なんだが。おかしいかな？

273 ：Name_Not_Found：2006/10/08(日) 10:52:25 ID:???

テキストの項目だからテキスト用ｗ
pの意味を大切にしたいからこそdiv ｗ
ロマンチストか！

274 ：Name_Not_Found：2006/10/08(日) 10:54:44 ID:???

別にdivに過剰反応してるわけでもないんだけど
"現状"ではpでダメな理由がない

むしろいきなりdivの方が変だなって思っちゃう

275 ：Name_Not_Found：2006/10/08(日) 10:55:13 ID:???

>>269
「例」だってばｗ短くしただけなんだから。
まあ誤解を生みそうだったのは謝る。

もちろんその前後にP段落は他にもあるだろうし、文章も長短あるだろうし、いろんな場合があると思うよ。

276 ：Name_Not_Found：2006/10/08(日) 10:55:23 ID:???

>>271
サブミットボタンの前後に意味がつながるような文章を置くのなら
まとめてpでくくってもいいと思うよ
そんな場面が思いつかないけど

277 ：Name_Not_Found：2006/10/08(日) 10:56:11 ID:???

そんな小さい囲みにdiv使ってたら自己矛盾だらけで禿げるぞｗ
文書全体で考えろよな。

278 ：Name_Not_Found：2006/10/08(日) 10:57:54 ID:???

>>276

ボタン自体にもテキストが設定されている
まあリストでいいと思うんだよ
type="hidden" がなければね

pで全部括るのもありだと思う

でさ、

<p class="submit">
<inpu type="hidden" />
<inpu type="submit" value="データを送信します" />
</p>

がなんでdivにしなくてはいけないのか、ってことでしょう
テキストいれるとわかりやすい。

279 ：Name_Not_Found：2006/10/08(日) 10:58:22 ID:???

>>277
じゃあ文章がなくフォームしかない文書の全体ではどうなの？

280 ：Name_Not_Found：2006/10/08(日) 10:59:11 ID:???

>>271
> だから、なんで input の場合はだめなんだ？って話
話は段落中のinputじゃなくて、フォーム中のinputを指して言われていて、
それをdivで括るのはおかしいがpで括るならいいと言う>169あたりの
主張がおかしいわけだ。

　> <p>このボタンを押してね → <input /></p>
　> ってこともあるでしょう。（まあやらないけど）
こういう例ならありうるだろうな。今回の話とは違うけど。

281 ：Name_Not_Found：2006/10/08(日) 10:59:24 ID:???

>>279

フォームしかなくても、

注意書きやラベルがあるだろう

まさかボタンだけのフォームなんて使わないだろう？

282 ：Name_Not_Found：2006/10/08(日) 11:01:01 ID:???

>>280

>話は段落中のinputじゃなくて、フォーム中のinputを指して言われていて、
>それをdivで括るのはおかしいがpで括るならいいと言う>169あたりの
>主張がおかしいわけだ。

じゃあ、dl等のリストもおかしいよ

リストからのつながりで p　があるわけ
確実にだめな理由がない

283 ：Name_Not_Found：2006/10/08(日) 11:01:44 ID:???

>>278
　>>251 ね

284 ：Name_Not_Found：2006/10/08(日) 11:01:45 ID:???

>>277
なんでもp要素にするやつが禿げないのは、
自己矛盾がないからではなくて、
自己矛盾がどうでもいいからです。

285 ：Name_Not_Found：2006/10/08(日) 11:01:55 ID:???

submitおよびhiddenはli！

<form>
　<dl>
　　<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
　　<dt><label for="hoge2">ほげ２</label></dt><dd><input id="hoge2" /></dd>
　　<dt><label for="hoge3">ほげ３</label></dt><dd><input id="hoge3" /></dd>
　</dl>
　<ul>
　　<li><input type="hidden" /><input type="submit" /></li>
　</ul>
</form>

うまくまとまってね・・・？

286 ：Name_Not_Found：2006/10/08(日) 11:02:59 ID:???

>>284
わろすｗｗｗ

287 ：Name_Not_Found：2006/10/08(日) 11:03:43 ID:???

>>285

いや、それでもおれはいいと思うよ
divにしなくてもそれでもいいのよ

で、なんでdivにする必要があるの？ってこと

おれはpの方がいいかなって思うからpの方にしてるだけ

288 ：Name_Not_Found：2006/10/08(日) 11:04:51 ID:???

>>285
hiddenは値を表示しないとはいえ項目のひとつなわけで、
それを他の入力項目と異なる、投稿承認ボタンに含めるのは
まとめかたがおかしいだろ。

289 ：Name_Not_Found：2006/10/08(日) 11:04:55 ID:???

>>285
だからリストにするのはもちろんいいんだけどね。
でもその理由が「入れる要素がないからとりあえずリストに入れておきますね」ってのじゃ、
DIV に input を入れるのは否定できないよ？

290 ：Name_Not_Found：2006/10/08(日) 11:04:59 ID:???

pがだめとなると>>285もだめということになるな

div派はやっぱり無理があるかもね

291 ：Name_Not_Found：2006/10/08(日) 11:05:35 ID:???

>>280
Pはテキストの項目にあって一目瞭然なんだから、認めちゃダメだよ。
Pの場合もあるなんて。
いかなる時も例外なく認めるなｗ

292 ：Name_Not_Found：2006/10/08(日) 11:06:22 ID:???

>>289

入れる要素がないから
ではないでしょう

divこそが入れる要素がないから入れておきますね
でしょう

293 ：Name_Not_Found：2006/10/08(日) 11:07:43 ID:???

>>290
駄目で何が困るんだろう。

p派はそもそも段落じゃないものを段落扱いしている
仕様違反だから論外なわけで、リストなりdivなり
他の手段を採らないといけないのは明らかなんだが。

294 ：Name_Not_Found：2006/10/08(日) 11:08:17 ID:???

>>293

段落じゃない理由がない
定義がないんだからさ

295 ：Name_Not_Found：2006/10/08(日) 11:08:22 ID:???

submit（やhidden？）をdivに入れている人はidかclassの属性値に何て振ってますか？

296 ：Name_Not_Found：2006/10/08(日) 11:08:23 ID:???

>>291
DIV派だけどそれはちょっとｗ

>>290
違う、問題は DIV の扱いじゃなくて、P の扱いなんだよね。

>>292
うん、最初から言ってるけど、他に入れる要素がないから DIV しかないの。

297 ：Name_Not_Found：2006/10/08(日) 11:08:54 ID:???

>>284
なんだもう禿げてるのか。すまなかったな。
submitはテキストじゃなくて属性値だよな。

298 ：Name_Not_Found：2006/10/08(日) 11:09:16 ID:???

>>291
で、お前は段落に画像が含まれる書籍を読んだことがないのか？

299 ：Name_Not_Found：2006/10/08(日) 11:10:05 ID:???

>>296

いや、入れる要素あるだろう

リストだってあり

300 ：Name_Not_Found：2006/10/08(日) 11:10:13 ID:???

>>295
それっぽいの。

301 ：Name_Not_Found：2006/10/08(日) 11:10:37 ID:???

>>300
参考までにぜひ

302 ：Name_Not_Found：2006/10/08(日) 11:10:43 ID:???

なんか盛り上がってきたところで、
オレ的には >>288 の意見がちょっと参考になった
つうか何人いるんだよ？

まとめるとだ、

<form>
　<dl>
　　<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
　　<dt><label for="hoge2">ほげ２</label></dt><dd><input id="hoge2" /></dd>
　　<dt><label for="hoge3">ほげ３</label></dt><dd><input id="hoge3" /></dd>
　</dl>
　<ul>
　　<li><input type="hidden" /></li>
　　<li><input type="submit" /></li>
　</ul>
</form>

これがスマートそう？

303 ：Name_Not_Found：2006/10/08(日) 11:12:08 ID:???

それとも、hiddenのにもラベルふって

<form>
　<dl>
　　<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
　　<dt><label for="hoge2">ほげ２</label></dt><dd><input id="hoge2" /></dd>
　　<dt><label for="hoge3">ほげ３</label></dt><dd><input id="hoge3" /></dd>
　　<dt><label for="hidden">ほげ４</label></dt><dd><input type="hidden" ～ /></dd>
　</dl>
　<ul>
　　<li><input type="submit" /></li>
　</ul>
</form>

こうか？
それともsubmitボタンまで全部ラベルふっちゃうか？
それでもいいな

304 ：Name_Not_Found：2006/10/08(日) 11:12:39 ID:???

>>296
そらしゃあないわ。わからないんだからdiv。
div厨はそうだもの。

305 ：Name_Not_Found：2006/10/08(日) 11:13:15 ID:???

>>294
一般に「ボタンがならんでるだけ」を段落とは言わない。
で、もし一般にボタンの羅列を段落と言うと主張するなら、
こちらに悪魔の証明を要求しないで、主張する側が
ちゃんと「ボタンの羅列やボタン単体だけでも段落と
認められる理由がありますよ」ということを示さなきゃ。

でないと、言葉の定義をいくらでも変えていいなら、
仕様なんてあってないようなものになってしまうからね。

306 ：Name_Not_Found：2006/10/08(日) 11:13:23 ID:???

>>299
だから、それだと無限ループだろがｗ
「入れる要素がないから」 DIV なり UL なり使うしかない。
だって P はおかしいから。
単体なのに UL 使うのもおかしいというかその必要もない気がするから、DIV を使う。
もしボタンが何個も並んでるなら UL 使うしね。

307 ：Name_Not_Found：2006/10/08(日) 11:14:30 ID:???

一般と同じならだれでもStrict+erだ

308 ：Name_Not_Found：2006/10/08(日) 11:15:13 ID:???

>>302
<li><input type="hidden" /></li>
これがレンダリングの際に気になるんだけど仕方がないのかなあ。
liにスタイルシートでdisplay:none;すればいいか。
hiddenってスタイル的な印象があってhtmlにはそぐわない気がしてるんだけど

>>303
submitボタンにラベルを振ったらラベルの文字列を押しただけで送信されてしまって

309 ：Name_Not_Found：2006/10/08(日) 11:15:50 ID:???

>>306

だから、最終的に意見を取り入れてまとめた

別にオレはオレルールを押しつけるつもりもない
ここにはそういうやつ多いがなｗ

だから意見を取り込んで、

>>302 や >>303はどうかな？って言ってる？
これじゃだめだから、やはりdivにする必要があると思う？

310 ：Name_Not_Found：2006/10/08(日) 11:17:17 ID:???

>>308

>これがレンダリングの際に気になるんだけど仕方がないのかなあ。
>liにスタイルシートでdisplay:none;すればいいか。

そうすると、見た目的にもよくなるね

>submitボタンにラベルを振ったらラベルの文字列を押しただけで送信されてしまって

え？そうだっけ？
どっちみちアクセスキーを設定する場合とかもあるし、
これならいいかなって気がしてきた

311 ：Name_Not_Found：2006/10/08(日) 11:18:45 ID:???

P派はボタン何個も並んでるとき
<p><input type="hidden"/> ・・・</p>
・・・
<p><input type="submit"/> ・・・</p>
とかするの？

<div class="hidden-elements"><input type="hidden"/> ・・・</div>
・・・
<div class="submit-elements"><input type="submit"/> ・・・</div>
って書いたりするんだが。
submit の中に hidden系入れることもあるけど、submit はひとつとは限らないし。

312 ：Name_Not_Found：2006/10/08(日) 11:19:03 ID:???

以前、submitを含め全てを定義リストでやってたけど
submitに文字列があるのにlabel側にも同じようなことを書いてて
なんだかなーって思ってやめた

そして今は難民。>>302-303みたいにもっと使えそうな案を出してください

313 ：Name_Not_Found：2006/10/08(日) 11:20:53 ID:???

>>309
あなたがそれでいいなら、いいんじゃないかな？？
とくに反対する理由もないよ。
DIVにする必要がある、なんて言ってないし。
方法のひとつだとは言ってるし、P はおかしい、って言ってるけど。

314 ：Name_Not_Found：2006/10/08(日) 11:24:16 ID:???

>>302
<form>
　<dl>
　　<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
　　<dt><label for="hoge2">ほげ２</label></dt><dd><input id="hoge2" /></dd>
　　<dt><label for="hoge3">ほげ３</label></dt><dd><input id="hoge3" /></dd>
　</dl>
　<div><input type="hidden" /></div>
　<div><input type="submit" /></div>
</form>

なんだが(divには適宜class指定するとして。)、
もしhiddenとする項目が複数ありうるものなら他の項目と同様にリストに
なると思う。その場合はdivより適切な要素があるから、divを使ったら濫用だろう。

同様のことはsubmitにも言えて、リストとして値を設定または保持するようなinputではなく、
フォームの使途の意思決定を意味するようなinputのリストになりうるものならばリスト
を意味する要素とするべきで、divを使うべきじゃないだろう。

意図による。俺は>302が不適切なグループ分けだと思っているが、
もし
　>　<ul>
　>　　<li><input type="hidden" /></li>
　>　　<li><input type="submit" /></li>
　>　</ul>
とする理由があれば、それが仕様に反しないならそのマークアップもOKだと思う。
だからどういう意図でリストに含めているのかききたいな。

315 ：Name_Not_Found：2006/10/08(日) 11:25:34 ID:???

>>311

そうしてる

>>312
>submitに文字列があるのにlabel側にも同じようなことを書いてて

そうだね。んだから、>>311みたいにすることもあったんだわ。

最初の質問を受けて、ここまでp派でやり出した本人はオレだが
pでダメな理由にはまだ納得はしていないんだ

でも、意見を反映して>>302-303みたいにまとめてみた
divも別に否定はしないけど、pがあやしいっていうヤツもいるわけだし、
今はこれもいいかな、って思ってる

でも、マークアップとスタイル指定が面倒だなｗ　しゃーないか

316 ：Name_Not_Found：2006/10/08(日) 11:26:04 ID:???

>>307
一般から外れればなんでもStrictと言うわけでもないよ。
それはただの勘違いさんだな。一般にもダメで、Strict的にも
ダメという、救いようのない脳内ルールの持ち主。

317 ：Name_Not_Found：2006/10/08(日) 11:27:13 ID:???

>>314

それもそうだな、と思ったわけで、
最終的には、これどう？　って感じなんだが

<form>
　<dl>
　　<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
　　<dt><label for="hoge2">ほげ２</label></dt><dd><input id="hoge2" /></dd>
　　<dt><label for="hoge3">ほげ３</label></dt><dd><input id="hoge3" /></dd>
　　<dt><label for="hidden">ほげ４</label></dt><dd><input type="hidden" ～ /></dd>
　　<dt><label for="submit">送信</label></dt><dd><input type="submit" ～ /></dd>
　</dl>
</form>

318 ：Name_Not_Found：2006/10/08(日) 11:27:22 ID:???

tableでした場合も、
<tr><th><label>フォームコントロールの役割</label></th><td>フォームコントロール</td></tr>
ってしてもtype="submit"やtype="hidden"はあぶれてくるね

319 ：Name_Not_Found：2006/10/08(日) 11:28:18 ID:???

誰かが「DIV はコンテナ」といってたけど、自分もそう思ってたのに気づいた。
ただし、その人が言う「ブロック要素しか含めないコンテナ」ではなく、
「インラインもブロックも含められる (%flow) コンテナ」だと思ってる。

だから、
<div class="nantoka">
　　<input type="hidden" />
　　<input type="hidden" />
　　<input type="hidden" />
</div>
とかやるし。

320 ：Name_Not_Found：2006/10/08(日) 11:30:45 ID:???

>>314 だなあ。

321 ：Name_Not_Found：2006/10/08(日) 11:30:49 ID:???

>>288の意見を取り入れるとそれはないなあ

たしかにhiddenだけでまとめるのもなんか違うな

つか、form要素が無くなってきりかわるまできついなほんと

322 ：Name_Not_Found：2006/10/08(日) 11:31:57 ID:???

>>317

これしかない
でも面倒くさいな・・・

323 ：Name_Not_Found：2006/10/08(日) 11:32:10 ID:???

>>317
hiddenのラベルに何を書くの？それは閲覧者に知らせないといけないもの？
submitはvalue属性値とlabelの文字列とが重複して冗長になってしまわない？

という疑問が生まれます

324 ：Name_Not_Found：2006/10/08(日) 11:33:52 ID:???

>>317
それはアリだと思う。フォーム部品としてすべてリストしてるわけだな。

ただ、この話は
>　　<dt><label for="hidden">ほげ４</label></dt><dd><input type="hidden" ～ /></dd>
>　　<dt><label for="submit">送信</label></dt><dd><input type="submit" ～ /></dd>
の「ほげ4」や「送信」のように、他の入力項目の内容説明と同様の説明は
付けないもののマークアップの問題じゃなかったんだろうか。
「マークアップのための原文改変(=意図変更)」をするんじゃない限り、
そもそも説明を付さないつもりだったんなら、その例だと解決できない。

317で意図どおりの文章なら別に問題ないと思うよ。

325 ：Name_Not_Found：2006/10/08(日) 11:34:05 ID:???

>>323

閲覧者に知らせなくてもいいものでも、いいと思うけど
submitは、kbd要素とかと合わせてラベルを付ければいいんじゃないかな

326 ：Name_Not_Found：2006/10/08(日) 11:36:16 ID:???

>>317だと余計な部分をスタイルシートで非表示にさせるために
各dt/ddに個別にidかclassを振らないといけなくなるからなあ

デザインを考慮するがために構造に制約をかけるのは間違っているんだけど
やっぱり面倒くさい・・・

327 ：Name_Not_Found：2006/10/08(日) 11:36:31 ID:???

>>324

そもそも内容説明がないことが問題なんだから、説明くっつけるのはいいんじゃないかな
見た目はCSSで変えればいい

ただhiddenはいいけど、たしかにsubmitはちょっときになるな・・・

<dt><label for="submit"><kbd>S</kbd></label></dt><dd><input type="submit" ～ /></dd>

じゃだめかな？

labelの使い方がちと問題な気もするがｗ

328 ：Name_Not_Found：2006/10/08(日) 11:38:20 ID:???

構造的には >>317　の反応悪くないね
p使ってたがオレもこれにするかな

つか　でもほんとに面倒くさいね　しゃーない

329 ：Name_Not_Found：2006/10/08(日) 11:38:37 ID:???

そもそも、ブロック要素の中に<input type="hidden" />だけを入れるのはいいの？
それはマークアップの為のマークアップになるんだけど。

330 ：Name_Not_Found：2006/10/08(日) 11:39:18 ID:???

submitだけ中身を逆転させて、
<dt><input type="submit" /></dt><dd><label>記入内容が送信されます。</label></dd>
とかは？

331 ：Name_Not_Found：2006/10/08(日) 11:40:11 ID:???

>>330

それってあり？

まあありか　ちょい気持ち悪いけどｗ

とりあえず定義リストでまとめるのが無難そうだね
面倒だけど

332 ：Name_Not_Found：2006/10/08(日) 11:40:24 ID:???

>>330
ラベルいらなくない・

333 ：330：2006/10/08(日) 11:41:11 ID:???

やっぱり気持ち悪いかあ
自分でも気持ち悪い

334 ：Name_Not_Found：2006/10/08(日) 11:41:50 ID:???

>>329

現状ではいいに決まってる　としか言えない
formが悪いだよな　ほんと

335 ：Name_Not_Found：2006/10/08(日) 11:45:04 ID:???

formが悪いのには同意だけど、やっぱ良いってのはおかしいと思うんだよなぁ。
デザインの為のマークアップとどう違うんだって。
他にどうしようもないから使われてるだけで、本来良いとは言えないだろって感じで。

336 ：Name_Not_Found：2006/10/08(日) 11:45:17 ID:???

ってか根本的解決になってないよｗ
P はどうした P はｗ

P じゃおかしいってことを理解して、
代案として模索するうちに DIV はどうしても気に入らないから >>317 にする、にいたったわけなのかな？

337 ：Name_Not_Found：2006/10/08(日) 11:46:59 ID:???

意味の持ちようもない hidden くらい form 直下、fieldset 直下に置けたらありがたいのだけどね。

338 ：Name_Not_Found：2006/10/08(日) 11:47:08 ID:???

本音をぶっちゃけると、>>317も気持ち悪かったりｗ

339 ：Name_Not_Found：2006/10/08(日) 11:47:46 ID:???

>>327
> そもそも内容説明がないことが問題なんだから、
マークアップ上の問題であって意味上の問題じゃなくないか？
マークアップの問題はマークアップで解決した方がいいと思うんだが。
「当てはまる要素がない」なら、「divを使う」というように。

もし内容説明がないことが原文の問題だと思って説明を加えたなら、
表示はCSSなりに任せりゃいいと思うよ。そのCSSでの表示とかは
HTMLとしては関係ないんだし。

340 ：Name_Not_Found：2006/10/08(日) 11:50:53 ID:???

>>336

おかしいとは納得してない
特に>>330 のような場合は p が良いと言える

divは気に入らないのじゃなくて、それもありだと言ってる

で、妥協も含めてもっとも適切そうなのが>>317という結論

>>339

それいったらラベルも必要なくなる
そもそもhidden自体も悪いよな
submitだけはたしかに、オレも微妙だと思うんだけどね

341 ：Name_Not_Found：2006/10/08(日) 11:52:12 ID:???

>>336
個人的には、pが違和感ありまくり。
それならまだdivの方がいいけど、divにも違和感有りなので
もっといい方法があればいいのにって感じだな。
ただ>>317も比較でマシなだけでなんか気持ち悪いｗ

342 ：Name_Not_Found：2006/10/08(日) 11:52:59 ID:???

>>341に補足。
違和感があるけど、pもdivもダメな訳ではないとは考えてる。

343 ：Name_Not_Found：2006/10/08(日) 11:54:01 ID:???

まあオレも含め、

p派もdiv派も >>317 ならまあいいかな

って感じか

もともとは誰かの質問だったんだが、
オレもいい方法があればと思って書いてた

まあhiddenとか必要な作りにするほうがダメってこと
っていうとまた反発されるかな？ｗ

344 ：Name_Not_Found：2006/10/08(日) 11:56:30 ID:???

>>317 よりだったら UL のがマシかなあ、って思ってるひとはいない？

345 ：Name_Not_Found：2006/10/08(日) 11:57:41 ID:???

>>344
なんで順序付きリスト・・・？

346 ：Name_Not_Found：2006/10/08(日) 11:58:27 ID:???

>>345

ええ？？よく見れ・・・

347 ：Name_Not_Found：2006/10/08(日) 11:58:43 ID:???

>>146 → >>153,160 → >>162 の流れでここまできたわけなのかな。

348 ：Name_Not_Found：2006/10/08(日) 11:59:16 ID:???

>>345
疲れてるの？ｗ

349 ：Name_Not_Found：2006/10/08(日) 11:59:17 ID:???

>>335
> 他にどうしようもないから使われてるだけで、本来良いとは言えないだろって感じで。
いや、仕様に書いてあるって。構造を付与するのには一般的にはdivとかspanを使えって。
本来の使い方だよ。
不必要な局面で使う(つまり濫用する)のはStrict的によろしくないけど、
本来使う局面でも拒絶反応を起こしてより不適切な方法を採るのはよろしくない。

ただ、本来の文章の意図を損なわずマークアップする他の適切な方法が
あるならそれを使うべきで(そんじゃないと「全部divとspanでいい」なんてことになる)、
他の方法を検討してみるのはまっとうなことだな。

350 ：Name_Not_Found：2006/10/08(日) 11:59:24 ID:???

hiddenは必要でしょｗ
セッションデータを見えるように表示させたら混乱を招くし、
クッキー使うとしたらバグやクロスサイトスクリプティングとかで悪用される可能性もある。
反発以前に流石にそれはありえないぞｗｗｗ
もちっと勉強して恋ｗ

351 ：Name_Not_Found：2006/10/08(日) 12:01:34 ID:???

>>350

見映えは関係ない
おまけにそういうのが必要ない作りにすればいいだけ
もちっと勉強するのはどっちだか・・・

ま、現状難しいからこういう議論になるわけ

352 ：Name_Not_Found：2006/10/08(日) 12:01:38 ID:???

>>340
> それいったらラベルも必要なくなる
いや、hiddenのとsubmitのにつけるラベルはいらんと言ってるんだが。
で、それはdtに含まれるものじゃないから別にする、という。

353 ：Name_Not_Found：2006/10/08(日) 12:02:23 ID:???

>>346,348
ごめんなさいm(_ _)m

354 ：Name_Not_Found：2006/10/08(日) 12:03:26 ID:???

>>352

>hiddenは値を表示しないとはいえ項目のひとつなわけで、

が適切だとすれば、hiddenにラベルが付くのはおかしくない

submitはちょっと気持ち悪いのはたしか

355 ：Name_Not_Found：2006/10/08(日) 12:04:22 ID:???

>>340
うん、>>330 なら充分 P もありだね。

356 ：Name_Not_Found：2006/10/08(日) 12:04:33 ID:???

つか、hiddenつかわないで、
全部、<input type="text" ～ />にしてさ、
CSSで消しちゃえばいいんじゃね？ｗ

357 ：Name_Not_Found：2006/10/08(日) 12:04:42 ID:???

hiddenを使わなくてもすむようなスクリプトを作れ・・・？スクリプトにまで言及っすか・・・

358 ：Name_Not_Found：2006/10/08(日) 12:05:09 ID:???

>>357

当然でしょう

359 ：Name_Not_Found：2006/10/08(日) 12:05:46 ID:???

>>356

ちょっっｗ
でもそれもありかもｗ

360 ：Name_Not_Found：2006/10/08(日) 12:06:15 ID:???

ねーよばかｗ

361 ：Name_Not_Found：2006/10/08(日) 12:06:52 ID:???

>>354
> が適切だとすれば、hiddenにラベルが付くのはおかしくない
うん。だからそれはそもそもの意図による。

　入力を要求する項目は項目名ラベルをつけて、
　入力を要求しない項目は項目名ラベルはつけない。
という意図ならhiddenにラベルはいらんし、
　項目なんだから入力の要求の有無にかかわらず、
　全部に項目名を記す。
という意図ならhiddenにラベルをつける。

362 ：Name_Not_Found：2006/10/08(日) 12:06:57 ID:???

ありだろ

そもそも hidden なんておかしいしね

363 ：Name_Not_Found：2006/10/08(日) 12:10:02 ID:???

結論

・全部　type="text" にする
・dl, dt label dd　のセットにする
・本来　hidden のやつはCSSで消せ

でFA？ｗ

でも、ありかもしれないなこれ
あ、XSS問題あるか…？

364 ：Name_Not_Found：2006/10/08(日) 12:10:24 ID:???

>>358
デザインありきの構造は当然ダメだけど
ロジックありきの構造もダメだと思うけど

365 ：Name_Not_Found：2006/10/08(日) 12:10:48 ID:???

それだったら
<dl class="hidden-elements">
<dt>mode</dt>
<dd><input type="hidden" name="mode" value="new" /></dd>
<dt>no</dt>
<dd><input type="hidden" name="no" value="123" /></dd>
・・・
</dl>
とかでいいやん。わざわざ text とかにして CSS 切ったら入力できちゃうものにする必要なんか全然ない。

366 ：Name_Not_Found：2006/10/08(日) 12:12:13 ID:???

うｎ
hiddenをtextに置き換えるなんて正気の沙汰とは

367 ：Name_Not_Found：2006/10/08(日) 12:13:22 ID:???

必要ない作りって現実的に考えて無理じゃね？
一体どんなのを想像してるんだろう。

368 ：Name_Not_Found：2006/10/08(日) 12:13:42 ID:???

>>363
いや、それは方法のひとつとしては認めるけど、
っていうか結論はないとおもうｗ
いくつか案でればいいかな、って思ってる。

369 ：Name_Not_Found：2006/10/08(日) 12:13:42 ID:???

hidden 自体がいらないもんだからね

とりあえずはdl dt label dd で全部セットにするだけのがよさそうか

はやくformなくなんねーかな・・・

370 ：Name_Not_Found：2006/10/08(日) 12:14:24 ID:???

>>357
157の基地外がいることを忘れるなよ。
かなり長期間、この板に限らず暴れてるのがいる。

371 ：Name_Not_Found：2006/10/08(日) 12:15:45 ID:???

CSS使えない環境は無視なの？
携帯とかｗ

372 ：Name_Not_Found：2006/10/08(日) 12:16:05 ID:???

>>367
必要ないのは無駄な脳内ルールだろ。
「divはなんか嫌だ」とか言わなければ、
濫用しないだけで話は終了。

373 ：Name_Not_Found：2006/10/08(日) 12:16:06 ID:???

>>371

それいったら Strict 無理やんｗ

374 ：Name_Not_Found：2006/10/08(日) 12:16:07 ID:???

157人の基地外がいるってこと？
>>157が基地外ってこと？

375 ：Name_Not_Found：2006/10/08(日) 12:16:10 ID:???

>>157 と >>357 にどんな因果関係が？

376 ：Name_Not_Found：2006/10/08(日) 12:16:50 ID:???

アンカーミスじゃない？

377 ：Name_Not_Found：2006/10/08(日) 12:16:55 ID:???

>>372

必要ないからなくなるんだよ
現状ではしょうがないがな
hiddenなんてのはHTMLには相応しくはないな

378 ：Name_Not_Found：2006/10/08(日) 12:18:06 ID:???

>>372
だが、hidden要らないって言ってる奴が現実に居るからね。
ここに。
WebProg板の住人が聞いたらなんて反応するやらｗ

379 ：Name_Not_Found：2006/10/08(日) 12:18:56 ID:???

要らないというか　なくていいもの
って感じだろう

WebProgrammerは糞みたいなHTML吐き出すの得意だからな・・・

380 ：Name_Not_Found：2006/10/08(日) 12:24:18 ID:???

hidden なしでどうやってやるんだよｗ
セッション値とくらい hidden にいれさせろよｗｗｗ
クッキーにいれろとかアホいうなよ？

381 ：Name_Not_Found：2006/10/08(日) 12:24:44 ID:???

個人的には>>317が候補に挙がっているんだけど
スタイルシートとかは適用させない状態で
冗長にならないようなhiddenとsubmitのラベル
何かいいものありますか？

って素の状態だとhiddenのところは用語（dtとlabelの部分）だけが表示されるんかあ

382 ：Name_Not_Found：2006/10/08(日) 12:25:12 ID:???

>>374,375,376
>153の間違いです。>157はホントごめんね。

383 ：Name_Not_Found：2006/10/08(日) 12:28:16 ID:???

153はさすがにネタっしょ。名前からしても。ネタというか騙そうとしているか。

384 ：Name_Not_Found：2006/10/08(日) 12:29:09 ID:???

>>380

type="text"でもいい
そもそも今後 hidden はなくなるわけだしさ

>>381

さっき上げたけどアクセスキーとかは？

<dt><label for="～"><kbd>S</kbd></label></dt>

他のヤツがなんもいわないからわからんけどｗ

385 ：Name_Not_Found：2006/10/08(日) 12:30:17 ID:???

>>378
> だが、hidden要らないって言ってる奴が現実に居るからね。
要らないという人間が出す代案が現実的じゃないんだから、
要らないってのが現実的じゃないんだろ。
現実的じゃないことを言う奴が現実にいることはよくあるけど、
せめて非現実的でもStrict的ならスレの範疇なのになあ。

386 ：Name_Not_Found：2006/10/08(日) 12:31:02 ID:???

>>385

要らないからなくなるんだってｗ

387 ：Name_Not_Found：2006/10/08(日) 12:31:59 ID:???

で？いつからなくなるの？

388 ：Name_Not_Found：2006/10/08(日) 12:33:02 ID:???

hidden はtype="text"でいいね　たしかに
構造と関係ないじゃん

CSSで非表示はありだと思う
現状はちょっとむずかしいだろうけどね

389 ：Name_Not_Found：2006/10/08(日) 12:34:03 ID:???

>>387

必要なくなるのはform自体だがな

390 ：Name_Not_Found：2006/10/08(日) 12:35:32 ID:???

type="text"って簡単に誰にでも改ざん去れちゃう時点でダメじゃない。

391 ：Name_Not_Found：2006/10/08(日) 12:35:43 ID:???

type=text にして css で隠してるんじゃ hidden とかわんねー、
っていうか css のきかない携帯ブラウザはどうするんですか。
IE6 が全然使われなくなるなら <button type="submit" value="nanka">submit</button> ができるからいけど。

392 ：Name_Not_Found：2006/10/08(日) 12:36:33 ID:???

>>389
だから逃避すんなってｗ
現在のHTMLについて考えなきゃ意味がない。

393 ：Name_Not_Found：2006/10/08(日) 12:39:05 ID:???

htmlだけで考えてるからこんなアホな思考回路になるんだよｗ
hiddenもだけど、CSS未対応ブラウザを考慮してなかったりとかも、ありえなすぎる。
htmlの仕様を考えるとしたって、他の状況を考慮するぐらい当たり前なのに。

394 ：Name_Not_Found：2006/10/08(日) 12:40:29 ID:???

>>388
なんでこのスレでスタイルシートを適用することが前提なんすか

395 ：Name_Not_Found：2006/10/08(日) 12:41:18 ID:???

>>390

hiddenでも改竄されるけどな

>>391

それって

<b> と <span style="font-weight: bold;"> が同じ

といってるのと同じ

type="text"にするのはStrict的じゃないか

携帯とかははっきりいって、他のも問題あるからな

396 ：Name_Not_Found：2006/10/08(日) 12:42:00 ID:???

>>393

考慮しててもありだろう
見えて困るのは制作者側の都合

397 ：Name_Not_Found：2006/10/08(日) 12:42:55 ID:???

なんか問題を斜め上にとらえるひとがいます。

398 ：Name_Not_Found：2006/10/08(日) 12:42:58 ID:???

だから現実問題としては難しいな
と始めからいってるわけだが？

オレは例を出しまくってるわけだが
他のやつはかみつくだけだな

それじゃ使えないよ

399 ：Name_Not_Found：2006/10/08(日) 12:43:50 ID:???

かみつくだけの能なしが多いのは同意

400 ：Name_Not_Found：2006/10/08(日) 12:45:17 ID:???

何このスピード？

401 ：Name_Not_Found：2006/10/08(日) 12:45:30 ID:???

よく伸びるな

402 ：Name_Not_Found：2006/10/08(日) 12:45:49 ID:???

>>393

おい　
そんなこと言うとこのスレの存在自体が無意味だぞｗ

403 ：Name_Not_Found：2006/10/08(日) 12:45:59 ID:???

もう収束してるけどねー

404 ：Name_Not_Found：2006/10/08(日) 12:46:11 ID:???

hiddenで改ざんって、reffer取ってるところだとそれの偽装までしてやらないとダメだよな。
textだとCSSをOFFにして普通に書き換えて出来ちゃう。
CSS非対応の携帯だと普通に表示されてるから、間違えて書き換えてしまう可能性も有る。
製作者側の都合じゃなくて、ユーザ側で起きる問題への対処でもあるんだけどなぁ。

何も知らず知ったかの知識で言い訳してるからこういう矛盾に繋がる訳で。

405 ：Name_Not_Found：2006/10/08(日) 12:48:31 ID:???

>>404

textの方がたしかに簡単だけど
hiddenも簡単にできるんだけど

ま、普通のやつはやんないだろうけどね

問題はCSS未対応の環境とか
それがあるから難しいな、と最初から言ってる

途中で誰かが変なこと言うからこうなる

406 ：Name_Not_Found：2006/10/08(日) 12:48:42 ID:???

>>402
厳格なStrictである事≠CSS等の対応状況を考慮しない

407 ：Name_Not_Found：2006/10/08(日) 12:51:39 ID:???

問題把握してやるぶんにはいいんじゃない
type="text"もね

とりあえずは、 dl dt label ddでセットにするのがまあまあよさげか？
ってのがひとまずの収束でしょう

で、>>201 はどうなのよ
あれ、オレも見たことある
おかしいよね

408 ：Name_Not_Found：2006/10/08(日) 12:52:36 ID:???

>>405
悪意を持ってやってる人が簡単かどうかではなく、
悪意も何もない無知な一般人が知らずにやってしまうかどうかが問題なんだよ。
だからその最初の段落の反論は意味が無い。
きつい言い方すると自己満足のための形だけの反論でしかない。
そういうレスを続けるからズレてくんだよ。

409 ：Name_Not_Found：2006/10/08(日) 12:53:37 ID:???

mapなんて使ったことないー

410 ：Name_Not_Found：2006/10/08(日) 12:55:22 ID:???

個人的な意見

hidden はある種の「機能」であって、文章構造の一部ではない。
だから他の input 要素と対等にマークアップする必要はない。
submit ボタンの手前に添えるくらいで問題ない。

411 ：Name_Not_Found：2006/10/08(日) 12:56:54 ID:???

mapの使い方を間違えてるというか、使いどころを間違えてるって感じだな。

412 ：Name_Not_Found：2006/10/08(日) 12:59:25 ID:???

そのmapの人はそっとしておいてあげればいいんじゃない？
ここで取り上げる内容でもないかと

413 ：Name_Not_Found：2006/10/08(日) 13:00:41 ID:???

>>408

いや、だから問題として捉えてるわけ
それをかみつかれてもなあ

414 ：Name_Not_Found：2006/10/08(日) 13:01:09 ID:???

>>410
それは言えてる。

415 ：Name_Not_Found：2006/10/08(日) 13:01:58 ID:???

>>410

ちょっｗ

また再燃か？

でも大概hiddenって type="text"でもいいもんもあるよな

416 ：Name_Not_Found：2006/10/08(日) 13:02:56 ID:???

>>285に戻るってこと？

417 ：Name_Not_Found：2006/10/08(日) 13:03:58 ID:???

>>415
例えばどんな状況？

418 ：Name_Not_Found：2006/10/08(日) 13:04:15 ID:???

じゃあhiddenなんてどうでもいいもんはどうでもいいもんの中にいれたら？

<form>
　<dl>
　　<dt><label for="hoge">ほげ</label></dt><dd><input id="hoge" /></dd>
　　<dt><label for="hoge2">ほげ２</label></dt><dd><input id="hoge2" /></dd>
　　<dt><label for="hoge3">ほげ３</label></dt><dd><input id="hoge3" /></dd>
　</dl>
　<ul>
　　<li><input type="submit" /></li>
　</ul>
　<div class=""><input type="hidden"/><input type="hidden"/>・・・</div>
</form>

419 ：Name_Not_Found：2006/10/08(日) 13:05:12 ID:???

<dt><label for="hoge3">ほげ３</label></dt>
<dd><input type="hidden" /><input type="submit" id="hoge3" ～ /></dd>

とか

dl dt dd はそのままでいいと思う

420 ：Name_Not_Found：2006/10/08(日) 13:07:08 ID:???

これだけ否定されてもtype="text"に拘る人が居るんだな
負けず嫌いと言うか

421 ：Name_Not_Found：2006/10/08(日) 13:07:43 ID:???

>>418
hidden のためにブロック要素をこしらえること自体に違和感を覚える

あと、無理にリストにせずにテーブルを使えばいいんじゃないかと思うんだが

422 ：Name_Not_Found：2006/10/08(日) 13:08:18 ID:???

>>417

textっていうか radio　とか select でもいいのとかあるよね
modeとかはそう

423 ：Name_Not_Found：2006/10/08(日) 13:08:23 ID:???

>>419
用語（dt）＝ラベル
が
定義（dd）の一部（type="submit"）としか呼応していないって変じゃない？

424 ：Name_Not_Found：2006/10/08(日) 13:08:47 ID:???

>>421

テーブルは明らかに違うと思われ

425 ：Name_Not_Found：2006/10/08(日) 13:10:12 ID:???

>>424
何で？

426 ：Name_Not_Found：2006/10/08(日) 13:10:47 ID:???

>>423

dt要素はdd要素と対応してる

submitに対応しているのはlabel要素だから
問題ないと思うんだけどどうかな

427 ：Name_Not_Found：2006/10/08(日) 13:11:35 ID:???

>>425

ユーザが入力されたものが表示されるだけで、
レンダリングされるものじゃないから

428 ：Name_Not_Found：2006/10/08(日) 13:11:57 ID:???

テーブルもいいと思うけど。

<th><label for="hoge">ほげ</label></th><td><input id="hoge" /></td>
<th><label for="hoge1">ほげ１</label></th><td><input id="hoge1" /></td>
<th><label for="hoge2">ほげ２</label></th><td><input id="hoge2" /></td>

ただ、結局tableにしてもhiddenとsubmitに関しては同じ問題にぶつかると思う

429 ：Name_Not_Found：2006/10/08(日) 13:12:02 ID:???

>>422
それだとユーザが変えちゃう場合もあるじゃない。
hiddenは通常の操作で勝手に弄れないようにって目的も有るでしょ。

430 ：Name_Not_Found：2006/10/08(日) 13:14:28 ID:???

>>427
意味がわからん

431 ：Name_Not_Found：2006/10/08(日) 13:14:29 ID:???

>>429

そうだね、だけど見えててもラベルくっつけてさ
checked="checked"にして引き継げば問題ないことも多い

まあ勝手にいじられないようにってのはあるんだけど

とか色々考えると、やはり最初の >>217 かって感じか

432 ：Name_Not_Found：2006/10/08(日) 13:16:32 ID:???

>>430

極論になるけど

<td><label for="～">～</label></td>
<td><span style="display: block;"></div></td>

と同じだと思う
inputにはレンダリングされるテキストがない

433 ：Name_Not_Found：2006/10/08(日) 13:18:28 ID:???

>>432
> <span style="display: block;"></div>
おちつけ

434 ：Name_Not_Found：2006/10/08(日) 13:18:31 ID:???

>>432

すまん

<td><label for="～">～</label></td>
<td><span id="～" style="display: block;"></span></td>

の間違い

そうでなくても、どこが表？って思っちゃうんだけど
どうなんだろうね

435 ：Name_Not_Found：2006/10/08(日) 13:18:36 ID:???

>>アンカーの下に1行空行を空けてる奴は
いくらなんでも必死杉だから少し落ち着いてはどうか

436 ：Name_Not_Found：2006/10/08(日) 13:19:35 ID:???

>>434
だったら定義リストもダメってこと？

437 ：Name_Not_Found：2006/10/08(日) 13:22:01 ID:???

>>433-434
入力欄があるじゃないか
何でもテキストじゃないと気が済まないのか？

438 ：Name_Not_Found：2006/10/08(日) 13:22:24 ID:???

>>436

うん　だからそれが最初のほうで出てた
けど現状では仕方ない

単純に表はどうなのって思っただけなんだけどね

439 ：Name_Not_Found：2006/10/08(日) 13:23:19 ID:???

hidden要らないって言ったりとか、渦中の発言してたのは一人なんだよな
普通の人なら一言レス貰えば納得できる事を、
これだけのレス費やしてやっとってどれだけやねん

440 ：Name_Not_Found：2006/10/08(日) 13:23:42 ID:???

>>428
テーブルは俺も実は違うと思ってる・・・

441 ：Name_Not_Found：2006/10/08(日) 13:23:56 ID:???

>>438
定義リストは現状では仕方がなくて表は明らかに違う
という根拠が>>434に書いた内容？

442 ：Name_Not_Found：2006/10/08(日) 13:25:21 ID:???

>>439
一言レスもらって終わりなら div で終わってたっしょ
dl なんて一つの方法論にはたどり着いてないと思う
俺には有益だった

443 ：Name_Not_Found：2006/10/08(日) 13:26:48 ID:???

dlは過去スレで何度も出てるけど。

444 ：Name_Not_Found：2006/10/08(日) 13:28:23 ID:???

>>442
渦中の人乙

445 ：Name_Not_Found：2006/10/08(日) 13:29:41 ID:???

>>443

hidden、submitを絡めたのは出てないんじゃないか？

>>441

すまん　混乱した
単純に表ではないと思っただけだ
th が dt td が dd に対応するからありなのか？

ただこれだと hidden の問題が解決できないね
ということで　たぶん dl のほうが適切

446 ：Name_Not_Found：2006/10/08(日) 13:30:15 ID:???

type="text" の要素にDLはいいんだけどねえ。
button や hidden になるとねえ・・・。

447 ：Name_Not_Found：2006/10/08(日) 13:32:27 ID:???

hiddenもlabel付けるってことで収束

buttonこそdivかな

448 ：Name_Not_Found：2006/10/08(日) 13:33:03 ID:???

TABLEのひとはsubmitはどこに組み込むのかね。
一般フォームなら表でもいいけどね。
というか表のが適したフォームのときもあるしね。それは場合によりけり。

449 ：Name_Not_Found：2006/10/08(日) 13:36:03 ID:???

こういう過去の議論とか妥協案とかさ
どっかにまとめないの？

450 ：Name_Not_Found：2006/10/08(日) 13:36:44 ID:???

tableにしろdlにしろsubmitとhiddenに無理が出る

451 ：Name_Not_Found：2006/10/08(日) 13:37:35 ID:???

いや、だからhiddenは無理でないって
submitも微妙だがおかしくはない　ってこと

tableだときびしい

452 ：Name_Not_Found：2006/10/08(日) 13:38:01 ID:???

buttonて

453 ：Name_Not_Found：2006/10/08(日) 13:38:56 ID:???

>>451
どうマークアップするとおかしくないの？
そしてその方法はテーブルには適用できないの？

454 ：Name_Not_Found：2006/10/08(日) 13:39:16 ID:???

button は submit とか reset とかボタン系の総称な。

じゃあDIV派の俺はでかけてきます。
帰ってきたらひとつの結論でてるのかな・・・。
興味深い議論ありがとでした（。。

455 ：Name_Not_Found：2006/10/08(日) 13:39:30 ID:???

>>217に出てるじゃん
tableだとセルで区切られちゃうので厳しい

456 ：Name_Not_Found：2006/10/08(日) 13:41:30 ID:???

ん？

457 ：Name_Not_Found：2006/10/08(日) 13:41:55 ID:???

面倒だからhiddenはheadの中に入れてしまえ。

458 ：Name_Not_Found：2006/10/08(日) 13:41:56 ID:???

>>454
いってら～

>>456
>>317の間違い

459 ：Name_Not_Found：2006/10/08(日) 13:43:54 ID:???

>>457
鬼才

460 ：Name_Not_Found：2006/10/08(日) 13:43:58 ID:???

>>458

<dt><label for="submit">送信</label></dt><dd><input type="submit" ～ /></dd>

この部分がこれでいいのなら、これを

<tr>
<th><label for="submit">送信</label></th><td><input type="submit" ～ /></td>
</tr>

と置き換えても別にいいんじゃないの？

461 ：Name_Not_Found：2006/10/08(日) 13:44:05 ID:???

>>457

どうやって入れるんだよ・・・ｗ

buttonも

<dt><label for="～">～</label></dt>
<dd><button><img ～ /></button></dd>

ならこれでいいと思う

462 ：Name_Not_Found：2006/10/08(日) 13:46:21 ID:???

<button><img ～ /></button> はできないわｗ

463 ：Name_Not_Found：2006/10/08(日) 13:46:22 ID:???

>>460

それでもいいんかな？って聞きたいとこだが
hiddenは

<tr>
<th><label for="hoge">ほげ</label></th><td><input type="hidden" ～ /></td>
<th><label for="submit">送信</label></th><td><input type="submit" ～ /></td>
</tr>

とかか？

扱いづらい上に、セル非表示にした場合にIEでバグなかったっけ・・・
補足たのむ

464 ：Name_Not_Found：2006/10/08(日) 13:47:20 ID:???

>>462
なんか問題あったっけ？

465 ：Name_Not_Found：2006/10/08(日) 13:47:47 ID:???

これがブレインストーミングってやつですか　すごいですね
人数が少ない感じもしますが

466 ：Name_Not_Found：2006/10/08(日) 13:51:21 ID:???

感動した！

467 ：Name_Not_Found：2006/10/08(日) 13:51:36 ID:???

>>410
レンダリングされないというHTML上での意味づけだと思うが。

当然レンダリングするように設定を変更しているユーザもいるので、
それにセキュリティを頼るのは完全に間違いだが、隠す意図を
HTML文書として表現することはHTMLとして意味があることだろう。

「他のinputと同様に項目だ」とみなすか、「他のinputと違って
入力を求めない項目だ」とみなすかは文書作成者の意図による。
基本的にはどちらも成り立つので、ホントに意図次第。

しかし、隠すという意図をHTMLで表現したいのにtextと指定するのは、
意図とマークアップが一致していない、仕様を無視したHTML文書だな。
そういう場合があるのにdivを無理に避けるからアホなことになるわけで、
現実的にはなんも難しいことはない。>>398は素直にdiv使えばいいだけ。

468 ：Name_Not_Found：2006/10/08(日) 13:52:04 ID:???

>>463
hiddenの</td>とsubmitの<th>の間に</tr><tr>がいると思う

469 ：Name_Not_Found：2006/10/08(日) 13:56:09 ID:???

>>467

他にレンダリングしない意図を持つ要素ってあったっけ？
まあformが特殊っちゃあそれまでだが

>>468

汲んでくれｗ
間違いだ

>>463は問題あったらよろしく

470 ：Name_Not_Found：2006/10/08(日) 13:58:58 ID:???

表については、
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/tables.html#h-11.1
　> HTML表モデルにより、著者は、テキスト、整形済みテキスト、画像、リンク、フォーム、
　> フォームのフィールド、別の表などのデータを、コマの行と列とに配置することができる。
とのことで、問題ないっぽい。

定義リストは、
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/lists.html#h-10.3
　> DL要素の応用として、例えば対話のマーク付けがある。 DT要素が話者を示し、
　> DD要素が話の内容を示す、というものである。
程度の広い解釈は認められる、というのが頻出だな。
だから特にinputについて否定する理由もない。pと違って。

471 ：Name_Not_Found：2006/10/08(日) 14:00:18 ID:???

うｎ

472 ：Name_Not_Found：2006/10/08(日) 14:01:47 ID:???

>>470

ﾄﾝｸｽ
じゃあtableでもいいわけね
ただhiddenを別セルにするのだけは困りそうだね

>>462はおっけいっしょ？

473 ：Name_Not_Found：2006/10/08(日) 14:12:26 ID:???

なにこれｗ

>>462は問題ないと思うぞ

ログ読んでくるわ

474 ：Name_Not_Found：2006/10/08(日) 14:55:55 ID:???

15分後に読む価値のないログを読んだ473が激昂する

475 ：Name_Not_Found：2006/10/08(日) 15:27:02 ID:???

途中いらんとこあったけど読む価値あったよ

476 ：Name_Not_Found：2006/10/08(日) 16:08:21 ID:???

ところでhiddenだからって上の要素をdisplay:noneにしちゃったら、
hiddenの値を送らなくならね？

477 ：Name_Not_Found：2006/10/08(日) 17:17:23 ID:???

なにこのアホアホカーニバル

478 ：Name_Not_Found：2006/10/08(日) 17:18:38 ID:???

>>476
馬鹿丸出し

479 ：Name_Not_Found：2006/10/08(日) 19:46:14 ID:???

俺の素朴な疑問が数日後にこんな議論に発展するとは思わんかった。

480 ：Name_Not_Found：2006/10/08(日) 19:56:01 ID:???

>>479
>>477
議論に値しないひどいものだった

481 ：Name_Not_Found：2006/10/08(日) 22:39:42 ID:???

いや、input を P にいれなくなっただけ実はあったと思うｗ

482 ：Name_Not_Found：2006/10/08(日) 22:49:00 ID:???

type="hidden"を要らないと言わなくなったのも大きな前進だなｗ

483 ：Name_Not_Found：2006/10/08(日) 23:20:11 ID:???

>>481
入れるべきですよ。

484 ：Name_Not_Found：2006/10/08(日) 23:21:58 ID:???

なんでもかんでもP要素にする奴を指すP厨という言葉も出来たしな。
>>483
P厨乙

485 ：Name_Not_Found：2006/10/08(日) 23:41:57 ID:???

>>484
div厨乙

486 ：Name_Not_Found：2006/10/08(日) 23:46:33 ID:???

>>484
ネタカーニバルを真に受けてるｗ

487 ：Name_Not_Found：2006/10/08(日) 23:56:56 ID:???

Strictスレが初心者スレ以下なのは昔から

488 ：Name_Not_Found：2006/10/09(月) 00:01:06 ID:???

hiddenを使わない場合、GETで値を渡すのが無難だと思うが、パスワードなどの値を渡すのには向いていないな。

ブラウザのアドレスバーで丸見えだし、アクセスログに記録されるし……。

489 ：Name_Not_Found：2006/10/09(月) 00:10:40 ID:???

>>488
WebProg板行ったら笑われるぞ

ま、hiddenの代用ならいくらでもあるが、だからといって無くさなくても
別にいいやな。

490 ：Name_Not_Found：2006/10/09(月) 00:26:19 ID:Op92HuIo

フォーム関連はXFormsで解決。

491 ：Name_Not_Found：2006/10/09(月) 00:50:10 ID:???

pでも食ってろdiv。

492 ：Name_Not_Found：2006/10/09(月) 02:05:04 ID:???

>>491
p厨乙

493 ：Name_Not_Found：2006/10/09(月) 05:02:21 ID:???

getじゃ文字量も決まってるのがきついな。
SSのアドレス欄でIDとかパスワードが漏れた例も実際に有った気がするｗ

>>489
どの辺りが？＞笑われる

494 ：Name_Not_Found：2006/10/09(月) 05:16:13 ID:???

HTTP POSTでも、サーバ側でセッション管理でも、その他お好みで。
HTTP GET併用でも、
> パスワードなどの値を渡すのには向いていない
わけがない。ま、普通はパスワードと無関係なセッションID使うだろうが。

495 ：Name_Not_Found：2006/10/09(月) 06:19:29 ID:???

>>493
根本的にわかってないでしょ？

496 ：Name_Not_Found：2006/10/09(月) 06:29:17 ID:???

いまどきパスワードをGETで渡すバカいるかよー。
っていうかなるべくパスワードは頻繁に行き来させたくないんで hidden にいれたりもしないけど。
いま作るならほとんどセッションじゃないかなあ。

「P厨」と >>491 のはおもしろかったなｗ

497 ：Name_Not_Found：2006/10/09(月) 07:06:16 ID:???

>>496
だから根本的にわかってないでしょ。

498 ：Name_Not_Found：2006/10/09(月) 07:09:41 ID:???

>>489,495,497
お前がな

499 ：Name_Not_Found：2006/10/09(月) 07:24:27 ID:???

>>498
get、postは流行りか？
バカめ。

500 ：Name_Not_Found：2006/10/09(月) 07:52:01 ID:???

ツマンネ(´･ω･)

501 ：Name_Not_Found：2006/10/09(月) 08:27:31 ID:???

>>496
おまえがおもしろかったよ

502 ：Name_Not_Found：2006/10/09(月) 09:00:15 ID:???

フォームは定義リスト使え　ってこったな

あとな、hiddenないとできないとかいう低嚢プログラマーは消えろｗ

503 ：Name_Not_Found：2006/10/09(月) 10:34:08 ID:???

はいはいわろすわろす

504 ：Name_Not_Found：2006/10/09(月) 11:31:02 ID:???

>>495
どこが？

>>499
流行以前の問題だろｗ
セッションIDで管理するのは当たり前。
そして、たまにそのままPASSとIDを放り込んでる例があったってだけ。

>>502
getでセッションIDを渡すの？

505 ：Name_Not_Found：2006/10/09(月) 11:31:52 ID:???

文章の置き所間違えたけどわかるからまあいいや。

506 ：Name_Not_Found：2006/10/09(月) 11:36:27 ID:???

>>504
はいはいわろす

507 ：Name_Not_Found：2006/10/09(月) 11:38:06 ID:???

そもそも送信ボタンをボタンだと思うから、P要素で違和感を感じるんじゃ
ないのか？　ボタンとしてレンダリングされるのは一つの表示例に過ぎないだろ？

音声ブラウザなどを考えれば、送信ボタンなんてただのリンク文字列だよ。
「この内容で送信しますか？」と読み上げるブラウザがあってもいいような
要素じゃないのか？　だったら、Pと考えても不自然ではない。いずれにせよ、
ボタンという見た目は排除して考えるべきだ。

508 ：Name_Not_Found：2006/10/09(月) 11:46:53 ID:???

type="hidden"とtype="text"を表示の違いと考えるのはおかしい。
閲覧者に入力（変更）を促すかどうかが根本的に違うぞ。

509 ：Name_Not_Found：2006/10/09(月) 11:47:31 ID:???

>>507
いや、機能だから。
音声ブラウザで機能を読み上げてるだけで、機能には変わりない訳だし。

510 ：Name_Not_Found：2006/10/09(月) 12:04:47 ID:???

内容と属性の値は違うだろ

511 ：Name_Not_Found：2006/10/09(月) 12:40:41 ID:???

>>509
A要素だってリンクを張るという機能があるが、段落の一部を構成出来る。
機能があるからと言って段落にならないという訳ではないだろ？

>>510
それは、その要素の設計によるはずだが。

<p>吾輩は<img src="cat.jpg" alt="猫">である。</p>
<p>吾輩は<a href="cat.jpg">猫</a>である。</p>

「画像と置き換える」「リンクを張る」などの機能が追加されていても、
根本的には段落の一部であって、内容か属性値かはその要素次第。
<input>はたまたま属性値を使うというだけだろ。

512 ：Name_Not_Found：2006/10/09(月) 12:53:22 ID:???

<p>記入事項に間違いがなければ内容を<input type="submit" value="送信" />してください。</p>

といったものならいいんじゃない。

<p><input type="submit" value="送信" /></p>

これは疑問。

513 ：Name_Not_Found：2006/10/09(月) 12:55:57 ID:???

<p><input type="submit" value="この内容で送信する。" /></p>

セフセフ

514 ：Name_Not_Found：2006/10/09(月) 13:01:26 ID:???

アンカーってaタグで範囲を指定された文字列があるからpなんじゃ？
文字列にアンカーを張るっていう機能だから、
それ自体が機能でしかないinput type="submit"とは違うと思うんだが。

515 ：Name_Not_Found：2006/10/09(月) 13:16:37 ID:???

>>514
aタグってなぁに？aタグって？

516 ：Name_Not_Found：2006/10/09(月) 13:26:13 ID:???

aタグの検索結果約 127,000 件中 1 - 10 件目 (0.06 秒)

517 ：Name_Not_Found：2006/10/09(月) 13:28:21 ID:???

>>514
aタグってなあに。
機能ってなあに。
ねぇねぇ。

518 ：Name_Not_Found：2006/10/09(月) 13:29:46 ID:???

機能の検索結果約 263,000,000 件中 1 - 10 件目 (0.14 秒)

519 ：Name_Not_Found：2006/10/09(月) 13:30:10 ID:???

hidden含めて　ラベルくっつけて定義リスト
これが最適

hiddenが機能とかいってるやつはあほだな

じゃあ blink や marquee も機能だｗ

520 ：Name_Not_Found：2006/10/09(月) 13:32:46 ID:???

>>516
aタグってなあに。
ねぇ。
機能ってなあに。
ねぇねぇ。

521 ：Name_Not_Found：2006/10/09(月) 13:33:08 ID:???

「aタグ」とか言う表現は言いたいことはわかるけど
「機能」は何を指し示しているのかわからん。

522 ：Name_Not_Found：2006/10/09(月) 13:34:16 ID:???

そしてマークアップの為のマークアップにならないか？という質問がきてループ

523 ：Name_Not_Found：2006/10/09(月) 13:35:04 ID:???

なにここ　

初心者が紛れ込んでるな

aタグは <a ～> とか </a> のことだろ

524 ：Name_Not_Found：2006/10/09(月) 13:36:38 ID:???

釣り上げようと必死な人が居ますね。

525 ：Name_Not_Found：2006/10/09(月) 13:37:35 ID:???

>>523

ttp://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1
> Elements are not tags.
> Some people refer to elements as tags (e.g., "the P tag").
> Remember that the element is one thing, and the tag (be it start or end tag) is another.
> For instance, the HEAD element is always present,
> even though both start and end HEAD tags may be missing in the markup.

526 ：Name_Not_Found：2006/10/09(月) 13:37:54 ID:???

よくわからんが、アンカータグだろって指摘してるって事？

527 ：Name_Not_Found：2006/10/09(月) 13:38:55 ID:???

>>525

アホだろ　タグと要素は違う

初心者しかいないみたいだな
まあ最初に言ったやつも区別ついてるかはしらんがな

aタグ <a ～>, </a>

開始タグ <a ～>

終了タグ </a>

a要素 <a ～>～</a>

528 ：Name_Not_Found：2006/10/09(月) 13:41:18 ID:???

>aタグで範囲を指定された

ってあるから、

>aタグ <a ～>, </a>

これの事を言ってるんじゃ？ｗ

529 ：Name_Not_Found：2006/10/09(月) 13:43:03 ID:???

>>528
たぶんそうだろ
まあ区別がついてなさそうな気はするがな

つっこんでるやつもわかってないようだしな

530 ：Name_Not_Found：2006/10/09(月) 13:43:22 ID:???

要するにあれ？
「タグ？(ﾌﾟﾌﾟﾌﾟﾌﾟ」
「それはタグじゃなくて要素って言うんだよｗｗｗｗｗｗｗｗｗｗｗ」
っていう、最近覚えた知識をひけらかしたいお年頃のお方がいたって事？

531 ：Name_Not_Found：2006/10/09(月) 13:43:49 ID:???

>>530
たぶん、そうだろう
なんか aタグって言葉自体につっこんでたしｗ

532 ：Name_Not_Found：2006/10/09(月) 13:45:04 ID:???

昨日からなんかひとり変なのがまじってるよなー。
web制作板にはいつになったらIDつくのかな。

533 ：Name_Not_Found：2006/10/09(月) 13:45:33 ID:???

>>532
初心者だらけだからだろう
まじで

534 ：Name_Not_Found：2006/10/09(月) 13:47:59 ID:???

と言う事を
>aタグってなあに。
って言ってる人が自演して言ってそうだから、IDが見えないのは困るｗ

535 ：Name_Not_Found：2006/10/09(月) 13:48:09 ID:???

>>530
>>531
初心者は君達ｗ

536 ：Name_Not_Found：2006/10/09(月) 13:48:51 ID:???

>>534
俺は違うｗ

>>535　←こいつだろ
勉強して出直してこい

537 ：Name_Not_Found：2006/10/09(月) 13:49:48 ID:???

>>536
すまんｗ

538 ：Name_Not_Found：2006/10/09(月) 13:51:27 ID:???

aタグでリンクという機能を貼っているのか？
本気で言ってるのか？
機能は、装備や実装やUAがうんにゃらかんにゃらした結果でしかないだろう。

539 ：Name_Not_Found：2006/10/09(月) 13:52:04 ID:???

ところでなんでこの板はID出ないんだ？

540 ：Name_Not_Found：2006/10/09(月) 13:56:23 ID:???

うんにゃらかんにゃらするようにしたものが機能なんじゃ？

541 ：Name_Not_Found：2006/10/09(月) 13:56:55 ID:???

>>538
だからお前の話は斜めだから話にならないんだって。
知識だけじゃなくて人間的にもっと成長しろ。

542 ：Name_Not_Found：2006/10/09(月) 14:00:33 ID:???

>>541
あーバカを見守れって事ね。わかった。じゃあタグは機能を貼るんだから命令です。それでどーぞどーぞｗｗｗ
はい張り切ってスタート！

543 ：Name_Not_Found：2006/10/09(月) 14:02:42 ID:???

>実装の話は10中8, 9スレ違い。
じゃなかったのかー

544 ：Name_Not_Found：2006/10/09(月) 14:40:54 ID:???

>>542は初心者スレでCGIはプログラムだってしつこく続けてた荒らしっぽいな。
やり口が全く同じ。

545 ：Name_Not_Found：2006/10/09(月) 14:43:53 ID:???

いまだに>>146の結論が出てない件について

546 ：Name_Not_Found：2006/10/09(月) 14:51:50 ID:???

>>545
どっちもダメ。divに意味付けがなされていないから。
適切な意味づけをすればどっちもおｋ

547 ：Name_Not_Found：2006/10/09(月) 14:54:23 ID:???

>>546
てことは

<div class="section">
<h2>見出し</h2>
<p>ほにゃららららららららら</p>
<p>ほにゃららららららららら</p>
<p>ほにゃららららららららら</p>
</div>

ってのはStrictスレ的にありなのか？

前聞いたらさ

人間にしかわかんねーからダメだ

って言われたぞｗ

548 ：Name_Not_Found：2006/10/09(月) 14:57:44 ID:???

じゃあセクションはdivでくくるっていう自分ルールを作っておけば

<div>
<h2>なんとか</h2>
<p>かんとか<p>
...
</div>

<div>
<h2>あれや</h2>
<p>これや<p>
...
</div>

はOK？

549 ：Name_Not_Found：2006/10/09(月) 14:58:46 ID:???

>>547
> って言われたぞｗ

って言われてもね・・・。

どう人間にしかわからないからダメかも聞いた？
classやidでの意味づけに意味がないって理由なら
divやspanの存在そのものが危ぶまれるよ！

550 ：Name_Not_Found：2006/10/09(月) 15:01:47 ID:???

＞危ぶまれるよ！

ﾜﾛﾀ

551 ：Name_Not_Found：2006/10/09(月) 15:07:05 ID:???

まず>>146に前者がダメで後者がダメじゃないという結論に至った経緯を説明してもらおう
問題提起をするならそれくらいしてもらわないと

552 ：Name_Not_Found：2006/10/09(月) 15:12:20 ID:???

form周りは難しいね
実装の話になるけど
各コントロールの描画についても
OSやブラウザによってばらばらすぎるし

553 ：Name_Not_Found：2006/10/09(月) 15:57:00 ID:???

>>549
おまえが危ういよ。

554 ：Name_Not_Found：2006/10/09(月) 16:28:36 ID:???

>>551
まず仕様書全部四で鯉

555 ：Name_Not_Found：2006/10/09(月) 16:30:30 ID:???

>>146が仕様書を全部読んでたらそもそも>>146は質問する必要ないね。
てことで

>>146
まず仕様書全部四で鯉

これで>>146の問題は解決か。

556 ：Name_Not_Found：2006/10/09(月) 16:35:57 ID:???

>>512-513
そうそう。段落かどうかなんて、前後の文脈とvalue属性値によるだろう。

<form>
<p>名前は<input>です。</p>
<p>メールアドレスは<input>です。</p>
<p><input type="hidden" value="上記、SessionID123456の内容を">
<input type="submit" value="送信します"></p>
</form>

こんなのなら、全部P要素でOK。

557 ：Name_Not_Found：2006/10/09(月) 16:47:59 ID:???

今までdl派だったけど、
>>512-513みたいに一連の文章の流れの中だったらpでもいいように思えてきた。
あと、div派の意見もわからんでもないように思えてきた・・・。

558 ：Name_Not_Found：2006/10/09(月) 17:25:50 ID:???

おお、そういうきっかけになればあの一見不毛に見えた議論も無駄じゃなかったな。

>>556 の <input type="hidden" value="上記、SessionID123456の内容を"> の部分だけはちょっとあれだと思うけどｗ

559 ：Name_Not_Found：2006/10/09(月) 17:36:24 ID:???

> <p><input type="hidden" value="上記、SessionID123456の内容を">
> <input type="submit" value="送信します"></p>

これは確かに違和感だな。
文章じゃなくてボタンだしｗ

560 ：Name_Not_Found：2006/10/09(月) 17:48:31 ID:???

どこまで加速するんだこいつらｗｗｗ

561 ：Name_Not_Found：2006/10/09(月) 18:01:13 ID:???

宇宙一周するまでかな

562 ：Name_Not_Found：2006/10/09(月) 18:04:06 ID:???

>>507
　<p>この内容で送信しますが、よろしいでしょうか？ [送信]</p>
がOKで
　<p>[送信]</p>
がNGなだけだ。
段落にオマケがついていても許されることはあるが、
段落じゃないものを段落として括るなという話だ。

あと、見た目がボタンか否かによらず、仕様としてあれはボタンだ。
実際テキストブラウザだとボタンじゃなくてアンカー付きテキストの
ように描画されるが、それでもなおHTMLとしてはボタンだ。

>>512,513,556
> value属性値によるだろう。
よらねーよ。仕様上、inputはフォームのコントロールで、valueは
コントロールの値の初期値だ。ユーザーエージェントが提出ボタンに
value属性値の値を表示するか否かでHTML上の意味が変わったりはしない。

で、inputはフォームのコントロールであって、imgのようにalt属性値が代替テキスト
として読者に示されるとされているような要素ではない。ボタンであると仕様に
明記されてるのを無視して、「valueの値が提出ボタンに表示される」なんて
実装に依存したものがHTMLとして意味を持つわけねーだろ。

value属性値に説明を書いても、それが文章としてなんて意味づけされない。
それが文章の一部として解釈されなければ段落として成立しない>512,513,556
なんてのは全部アウトだ。

563 ：Name_Not_Found：2006/10/09(月) 18:26:08 ID:???

>>560
天国に辿り着くまで

564 ：Name_Not_Found：2006/10/09(月) 18:29:03 ID:???

いつも俺ルールで考えてるから他人の指摘をまともに聞けないんだよ

565 ：Name_Not_Found：2006/10/09(月) 18:53:38 ID:???

独り言のような一行レスはスルーで（俺含む）

566 ：Name_Not_Found：2006/10/09(月) 18:56:58 ID:???

567 ：Name_Not_Found：2006/10/09(月) 18:58:36 ID:???

なんかテーブルみたいだなｗ

568 ：Name_Not_Found：2006/10/09(月) 19:20:15 ID:???

>>562
段落に「おまけ」とかいうのが付いて許されたり、「おまけ」だけだと許されなかったりするなら何かで区切らないとね。
ぼく。

569 ：Name_Not_Found：2006/10/09(月) 19:27:06 ID:???

なんか一部分だけを拾ってきて全否定するやつってはなから人の意見とか聞く気ないだろ。

570 ：Name_Not_Found：2006/10/09(月) 19:34:21 ID:???

個人的な許容範囲

○ <dt>名前</dt><dd><input/></dd>
△ <li>名前: <input/></li>
× <p>名前: <input/></p>
× <p><input value="ここに名前を入れてください"/></p>
○ <p>名前は右のフォームに入れてください。 <input/></p>

571 ：Name_Not_Found：2006/10/09(月) 19:35:18 ID:???

>>569
アホやろ。理屈こねるなら辻褄ぐらい合わせろや。

572 ：Name_Not_Found：2006/10/09(月) 19:44:23 ID:???

>>568
> 段落に「おまけ」とかいうのが付いて許されたり、「おまけ」だけだと許されなかったりするなら何かで区切らないとね。
すでにご自分で区別がついてるように見えますが。

573 ：Name_Not_Found：2006/10/09(月) 19:47:25 ID:???

divの人は各コントロール個別にdivで囲んでるの？
それともform以下のコントロール全てを一つのdivで囲んでる？

574 ：Name_Not_Found：2006/10/09(月) 19:54:45 ID:???

>>573
俺は>>314

575 ：Name_Not_Found：2006/10/09(月) 19:59:27 ID:???

段落についてもう一度考えてみたいが、じゃあ、

× <p><img alt="花"/></p>
○ <p><img alt="街の片隅にひっそりと小さな花が咲いていた。"/></p>

なのか？　しかし、文になっていなければ段落ではないというのは本当か。
例えば小説の一節で、

|　　　この送信ボタンを押せば、すべては終わる。永かった……。様々な
|　　思いが去来する中、震える手で俺は最後の動作を行った。
|　　　送信！

こんなのがあれば、この「送信！」はこれで一段落だ。それを考えれば、
<p><input type="submit" value="送信！"/></p>
もあり得るんじゃないか。

576 ：Name_Not_Found：2006/10/09(月) 20:02:49 ID:???

>>570
おまえのあたまが許容範囲外。

577 ：Name_Not_Found：2006/10/09(月) 20:13:36 ID:???

>>575
うん、だから、昨日のいつだか言ったけど、
前後の文脈によってならあり得るときはあるんじゃないか、って。
小説の一説とか日記の合間とかなら、画像だってそのときは P で囲むでしょう？
それは別におかしいとは感じない。

「単独」で出てきた場合は文脈もなにもないから、おかしいと感じる、っていうことだったと思うけど？

578 ：Name_Not_Found：2006/10/09(月) 20:16:15 ID:???

>>575
> <p><input type="submit" value="送信！"/></p>
> もあり得るんじゃないか。
value属性値については>>562読みなおせ。

> ○ <p><img alt="街の片隅にひっそりと小さな花が咲いていた。"/></p>
絵単体が段落になるわけねーだろ。
代替テキストにすぎないalt属性値が表示されないと段落として意味を
なさないのに、段落を構成すると思う理屈を教えてくれ。

579 ：Name_Not_Found：2006/10/09(月) 20:25:32 ID:???

>>578
じゃあ
<P>あああ</p>
<なにか><INPUT></なにか>
<P>。</p>
じゃないと認めない。

580 ：Name_Not_Found：2006/10/09(月) 20:27:49 ID:???

>>578
表示されないと段落として意味をなさない？
表示されないと？

581 ：Name_Not_Found：2006/10/09(月) 20:29:59 ID:???

>>562
HTML4.01 仕様書 17.4.1 より
>User agents should use the value of the value attribute as the button's label.

582 ：Name_Not_Found：2006/10/09(月) 20:37:23 ID:???

shouldだね

583 ：Name_Not_Found：2006/10/09(月) 20:51:42 ID:???

>>579
日本語でおｋ

>>581
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.4.1
> button
> Creates a push button. User agents should use the value of the value attribute as the button's label.
should以前に、それはtype="button"の説明ですよ。

同節のsubmitやresetの項や、17.2.1.Control typesのとこのbuttonsの項に
同様の説明は書いてないのに、どうやったらそれがすべてのボタンについての
言及と読めるんだろうなあ。

何についての文章かも分かってなかったとか？英語版をわざわざ引っ張って
くるんだから、それはないと思いたいけど……。

584 ：Name_Not_Found：2006/10/09(月) 20:58:52 ID:???

>>583
>should以前に、それはtype="button"の説明ですよ。

その下の例示を見よ

585 ：Name_Not_Found：2006/10/09(月) 21:16:10 ID:???

>>584
> This form might be rendered as follows:
見ましたが、結局value値が表示されるのはsubmitやresetの
仕様じゃないですよね。実装依存ですよね。

586 ：Name_Not_Found：2006/10/09(月) 21:33:53 ID:???

submit も reset も button もひとくくりでいいっしょ。
<button type=""> でそれら全部の種類あるしなあ。

587 ：Name_Not_Found：2006/10/09(月) 21:43:40 ID:???

Strict的にはアウト

588 ：Name_Not_Found：2006/10/09(月) 21:46:50 ID:???

行間の読み方は人によって異なる場合があるから
仕様書にはっきりと書いてあること以外は
mustやshouldどころかmay以下という認識・・・？ではない・・・？

589 ：Name_Not_Found：2006/10/09(月) 21:58:38 ID:???

>>588
> 行間の読み方は人によって異なる場合があるから
人によって読み方が異なって揉めることもあるんだけど、
>>581がtype="button"に限った言及だってことは単なる事実。

まあ、それが分かってるから具体的な主張をせず、
仕様の文章を引用するだけとか、「見よ」とだけ言うとかで、
具体的な主張は避けるんだろうけどね。

結局、>>575がアウトだってことは変わらない。

590 ：Name_Not_Found：2006/10/09(月) 22:03:39 ID:???

下を書くと書かないじゃ、デザインが変わるときがあるんだが、なぜだ？
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml 11.dtd">

591 ：Name_Not_Found：2006/10/09(月) 22:09:36 ID:???

仕様を読む限り、 submit も reset も value 属性の値をラベルにするのが自然に思えるなあ
仕様のエラーのような気がする

592 ：Name_Not_Found：2006/10/09(月) 22:09:37 ID:???

IE使ってるから。

593 ：Name_Not_Found：2006/10/09(月) 22:11:58 ID:???

なんか慇懃無礼な煽り口調の人が混ざってるね

594 ：Name_Not_Found：2006/10/09(月) 22:29:44 ID:???

>>593
自治ｲﾗﾈ

595 ：Name_Not_Found：2006/10/09(月) 22:31:01 ID:???

P要素も、段落以外のものを含むのが自然と思えるからといって、
仕様を無視して段落以外を含んだり、仕様を無視してブロック要素である
リストを含んだりしたら、それはValidでないHTML文書だよなあ。

仕様に不満があるからといっても、好き勝手にマークアップしちゃいけないよ。
やっぱり、divなりdtなり使いましょう。

596 ：Name_Not_Found：2006/10/09(月) 22:43:13 ID:???

>>595
文章以外のパラグラフも有り得るのではないか。
という話し。
段落、段落以外の話しとは違うよ。

597 ：Name_Not_Found：2006/10/09(月) 22:48:44 ID:???

そらありうるでしょ。

文章じゃない数式とかで証明とか書いたってパラグラフになりうるしなあ。

598 ：Name_Not_Found：2006/10/09(月) 22:54:00 ID:???

>>597
それに<input>や<img>は有り得ますか？
じゃないの？

599 ：Name_Not_Found：2006/10/09(月) 22:55:39 ID:???

>>596
段落とパラグラフは別とかいう話じゃないのは、
パラグラフという言葉がこのスレで出てなかったことから明らかだな。
段落云々もパラグラフ云々も問題にしてることは結局同じだ。

で、「ありうるかもしれない、ありうるとかん変えている」と言うばかりで、
ここまでの段落でないもの単独をP要素として括りうるという主張は
全滅したんだし、そんなん無しでしょ。

いくら仕様が自分の思い通りじゃなかったからって、曲解は無しだよ、やっぱり。

600 ：Name_Not_Found：2006/10/09(月) 22:59:09 ID:???

いや、文章の中に画像がある場合もある、ってのはかなり前からいわれてるけど？
なんでほどほどってのは知らないんだこいつら。

601 ：Name_Not_Found：2006/10/09(月) 23:03:18 ID:???

>>597
証明の文章中に数式が出てくるって形だろう。
文章中の数式単独で段落になったり、文中ですらない
単独の数式で段落になったりはしないんだから、
単独のinputをp要素とする話には関係ないよなあ。

602 ：Name_Not_Found：2006/10/09(月) 23:06:41 ID:???

>>600
誰と話してんの？

603 ：Name_Not_Found：2006/10/09(月) 23:07:08 ID:???

単独のinputをPにする話なんかいましてた？それは昨日終わったと思ったんだがｗ
いまは文章の流れの中の画像やinputとかも P にしちゃだめ、ってやつがでてきたんじゃないの？

604 ：Name_Not_Found：2006/10/09(月) 23:10:11 ID:???

img要素にalt属性で代替テキストを指定してる場合で、
それが文章になってるならpでもいいんでない？

605 ：Name_Not_Found：2006/10/09(月) 23:11:34 ID:???

インプット要素などの補足説明としてその要素の前後に文章を入れたりすることを考慮すると

<form>
<dl>

<dt><label for="a">メールアドレス</label></dt>
<dd>入力は半角英数</dd>
<dd><input type="text" id="a" /></dd>

<dt><label for="b">本文</label></dt>
<dd>最大文字数1000文字</dd>
<dd>800文字を超えると改行されなくなります</dd>
<dd><textarea id="b"></textarea></dd>

続く

</dl>
</form>

という具合に定義リストがスマートでないかい？
dlファンなので他の要素での表記方法は考えていないけど。

ってこの話はもう終わった？

606 ：Name_Not_Found：2006/10/09(月) 23:15:32 ID:???

>>603
value属性値として文章を書いてinput単独をp要素とするやつが出てきたの。

607 ：Name_Not_Found：2006/10/09(月) 23:19:13 ID:???

>>604
代替は代替でしかないと思う。
value に文章入れてたらいいとか、title に文章いれてたらいいとか、それはやっぱないな。
仕様書に間違って読んでそれらしいことかいてあるなら考える余地はあるけど。

たとえば object の子要素は代替だけど、それを文章で書く場合のこと考えると、
<object><param/><p>text</p></object>
って普通書くと思うんだけど（違う？）
<p><object><param/>text</object>
</p>

こうかかなきゃ、ってことになるような気がする。飛躍しすぎたかも。

608 ：Name_Not_Found：2006/10/09(月) 23:21:19 ID:???

>>606
ああ、おｋ、把握ｗ

609 ：Name_Not_Found：2006/10/09(月) 23:26:46 ID:???

>>604
画像そのものでも文章や文章の一部として意味が通るならOK。
説明のなかで数式が出てくるときに、数式の部分を画像にしたりな。

画像じゃ文章(の一部)として認識しようがないものを、
「altに文章を書いたからPで括れるよねー」とか言うのはNG。
そもそも絵と代替テキストで意味合いが変わる時点でなあ。

で、そもそも代替テキストですらないinputのvalue属性値を文章
(の一部)としてP要素とするのもNGだろう。

ただ、type="button"のvalue属性値に文章(の一部)を指定した場合は
どうなんだろうね。
「あくまでもボタンだから文章の構成要素とはならない」となるのか、
「value属性値は閲覧者に示されるんだから、ボタンとはいえ画像と
同様に文章の一部として扱えると考えるべき」となるのか。

俺は後者だと思うなあ。
ただそれでも、input単独の場合は、img単独の場合と同様、
段落になりえないよなあ。

610 ：Name_Not_Found：2006/10/09(月) 23:31:37 ID:???

>>607
まれな例として、
文字コードの存在しない言語の混在する文章(小説とか)
ってのが考えられる。

一段落別言語が混在する程度なら、その一段落をまるまる
画像として段落扱いし、altには訳語でも書いときゃいいや、
という場合はアリだと思う。
(頻繁にその別言語が登場するなら、表現媒体を考え直した
方がいいと思うけどな。)

611 ：Name_Not_Found：2006/10/09(月) 23:31:55 ID:???

>>609
「扱える場合がある」で充分じゃないかねえ。
画像にせよbuttonにせよオブジェクトにせよ、基本的にはないけど、
文章の一部で、それがないと一連の段落・構成としてなりたたないようなとき、かなー。

612 ：Name_Not_Found：2006/10/09(月) 23:35:59 ID:???

>>610
まあその例ならそうだろうけど、特殊なケースすぎるわー(笑)
身近に起こりそうな一般的ケースで話さないとちょっと議論しにくいね。何にだって例外はあるし。

613 ：Name_Not_Found：2006/10/09(月) 23:37:39 ID:???

>>607
画像が表示できない時に代替でテキストを表示するんだから、
画像と同じ意味というか説明になるテキストと同義って事にならないかなと。
そのテキストがpに当てはまるなら画像も当てはまるだろうしって感じで。

勿論、それゆえにtitleとかvalueは論外だと思うわ。

>>609
あくまで印象だけど、value属性値に文章(の一部)を指定する事自体が
違和感感じるなぁ。

614 ：Name_Not_Found：2006/10/10(火) 00:01:28 ID:???

>>613
逆かなあ。画像が当てはまるならテキストも当てはまる。
卵が先か鶏が先かじゃないけど、最初に代替テキストがあるのはおかしいかなと。
だって代替テキストなんて後付けで取り替え可能なものでしょ？

だいたい、画像と代替テキストは同じというかイコールとはなり得ないしなあ。
画像の持つ全ての情報を代替テキストで伝えられるなら別だけど。
普通こんな感じでしょ？
<img src="scene-a-15.png" alt="場面A-15の写真" />
こんな風にはそうそうかかないでしょ。
<img src="scene-a-15.png" alt="場面A-15の写真。止める女の言葉を無視し、男は剣を振りかぶり、無表情のままそれを振り下ろした。" />
書いたとして、「ALTが文章っぽくなたから P でいいね」、ってことだと変だなあ、って思うし。

615 ：Name_Not_Found：2006/10/10(火) 00:07:32 ID:???

>>612
要は、imgやinputであることが問題なんじゃなくて、
それが文章を構成しないのが問題なんだってこと。

で、結局「Pは段落以外に使うな」ということで話が一貫するわけね。
例外じゃなくて、もうちょっと基本に立ち返ってみよう、という話だな。

じゃないと、「imgがOKだからinputもOK」とか変な理屈が通っちゃう。
それのどこが変なのかをちゃんと説明すると、冒頭で言ったことに
なるってこと。

616 ：Name_Not_Found：2006/10/10(火) 00:12:17 ID:???

>>614
そういう場合もあるだろうけど、
画像がそれ自体で前後の段落を繋ぐ意味を持つときとかの話ね。

<p>そう、〇〇が△なんだ！</p>
<p><img src="nandatte.png" alt="な、なんだってー"></p>
<p>～略～</p>

みたいな感じで、MMRのなんだってーの画像を使って日記書いてる時とか。
要は使い方なんだけどね。
>>614の場合だとちょっと適切ではないとは思うし、
あくまで状況によっては使える場合もあるだろうって考えてクリ。

617 ：Name_Not_Found：2006/10/10(火) 00:20:46 ID:???

>>616
最初からそういってくれないと誤解する(´･ω･｀)

618 ：Name_Not_Found：2006/10/10(火) 00:21:51 ID:???

けっこう興味深い。
漏れは今まで、>>616の例を借りると

<p>そう、〇〇が△なんだ！<img src="nandatte.png" alt="な、なんだってー" /></p>

みたいな感じでやってたけど、この考え方だと漏れも
「<img>だけ<p></p>に入れることも容認」する派になるってことか。

619 ：Name_Not_Found：2006/10/10(火) 00:28:00 ID:???

>>617
すまんｗ
まあ、状況って色々あるじゃない？
一概には良いとも悪いともいえないと思うよって事なのよ。

620 ：Name_Not_Found：2006/10/10(火) 00:31:30 ID:???

>>599
全滅してないってｗ

621 ：Name_Not_Found：2006/10/10(火) 00:33:10 ID:???

>>615
＞文章を構成しない
文章＝段落＝パラグラフ
ですかね？

622 ：Name_Not_Found：2006/10/10(火) 00:36:41 ID:???

確かに文字というか文章を代替する画像って場合もあるんだよな
その発想はなかったぜｗ
なんとなくの思い込みで、画像の代替としてのテキストとしか
考えてなかったと白状してみる

623 ：Name_Not_Found：2006/10/10(火) 00:38:49 ID:???

じゃあ画像が無いと成り立たない段落のテキストなんか書くべきじゃないよ。

624 ：Name_Not_Found：2006/10/10(火) 00:45:12 ID:???

仕様書はformの下にpの例文があります。

625 ：Name_Not_Found：2006/10/10(火) 00:49:14 ID:???

>>623
日本語でおｋ

626 ：Name_Not_Found：2006/10/10(火) 00:52:47 ID:???

>>599
段落でないものをP要素として括りうるなんて主張してる奴はいないだろ。
単独の<img>や<input>でも段落になりうるという主張じゃないのか。
文になってなくても段落になりうるという話もあったし。

問題はP要素の意味範囲ではなく、段落の意味範囲なんだよ。

627 ：Name_Not_Found：2006/10/10(火) 00:56:50 ID:???

>>625
ばーか。
これならわかる？

628 ：Name_Not_Found：2006/10/10(火) 00:59:16 ID:???

>>599
段落とパラグラフの微妙な違いについてはさんざん出てます。

629 ：Name_Not_Found：2006/10/10(火) 01:00:27 ID:???

>>625
>>623の文章も読めないなら黙ってな。

630 ：Name_Not_Found：2006/10/10(火) 01:00:39 ID:???

>>621
paragraphが日本語の形式段落を指すか意味段落を指すか
どちらも指すか日本語の段落は指さない(無茶?)かは
議論の余地のあるところだけど、今回はそれとは別の話だよ。

それらですらないものをparagraph(段落)であると主張して、
p要素で括ろうとしてるのがいるわけ。

>>626
>305

631 ：Name_Not_Found：2006/10/10(火) 01:02:29 ID:???

>>627 >>629
必死な>>623乙ｗ

632 ：Name_Not_Found：2006/10/10(火) 01:02:41 ID:???

>>630
じゃあ
<form>
<p>
<input>
</p>
</form>
は間違いであると。

633 ：Name_Not_Found：2006/10/10(火) 01:04:06 ID:???

>>631
はいはい。馴れ合いは嫌いなんでね。

634 ：Name_Not_Found：2006/10/10(火) 01:06:26 ID:???

>>623
画像が閲覧できる環境で見られるならなおよいけど、
代替テキストしか閲覧されなくてもどうにかなるなら、
img要素がないと成り立たないテキストを書いても
とりあえずOK。
それ以上踏み込んだ判断は、具体的な状況によるなあ。

>>628
過去スレの話じゃないです。このスレで始まった議論中で
出てなかったんだから、今回はだれも問題にしてなかった、
というのは明らかですね、ということですよ。

635 ：Name_Not_Found：2006/10/10(火) 01:09:02 ID:???

>>632
とりあえず過去ログ読もうよ。
>>74あたりから始まるからしんどいだろうけど。

636 ：Name_Not_Found：2006/10/10(火) 01:09:48 ID:???

>>634
とりあえずOKなんてのはStrictではないです。
パラグラフは問題にしています。あなたが勝手に段落とパラグラフを別物に解釈しただけです。

637 ：Name_Not_Found：2006/10/10(火) 01:11:35 ID:???

>>632の説明をしていただきたい。

638 ：Name_Not_Found：2006/10/10(火) 01:15:32 ID:???

>>635
読みましたよ。
途中で何度も同じ事をマンセーを集めて馴れ合いでくりかえしているだけ。
パラグラフの解釈はもう少し広いです。

639 ：Name_Not_Found：2006/10/10(火) 01:17:59 ID:???

例文を否定するならdl、dt、ddで会話をマークアップするのもダメですね。

640 ：Name_Not_Found：2006/10/10(火) 01:18:34 ID:???

形式段落と何とか段落とは別だとか
日本語文章での段落は何とかで英語文章でのパラグラフは何とかでどうのこうの・・・で
よくもめてなかったっけ？

641 ：Name_Not_Found：2006/10/10(火) 01:28:19 ID:???

>>637
過去ログ読んでその説明を探して、それを踏まえてレスしてくださいね。

>>636
> あなたが勝手に段落とパラグラフを別物に解釈しただけです。
パラグラフと段落を別物に解釈したのは>>596ですよ。
>>596さんに対してレスしてあげてくださいね。

>>638
>305

642 ：Name_Not_Found：2006/10/10(火) 01:31:28 ID:???

>>570
一番最後の右と云う表現は視覚的な情報。
俺なら絶対にやらない。

643 ：Name_Not_Found：2006/10/10(火) 01:32:13 ID:???

>>641
それは俺仕様書の俺Strictですよ。
div厨p厨以下です。

644 ：Name_Not_Found：2006/10/10(火) 01:34:01 ID:???

>>640
その議論で「文章をなさないinput単独でもparagraphだ」なんて
主張が出てきた覚えはないんだよなあ。文章なのは前提だったと思う。

つーか普通は文章前提だしなあ。一般書籍や数学の証明のように
文中に図画や数式が入ってくる段落ってのはあるけど、ボタンが
ポツンとあって「これは段落です」というのはないと思うんだが。

あるなら具体的に示してみてくれって、何度か言ってるけど、
返答はないよなあ。そんなんまで一般だったら、辞書の
総書き換えが必要だよなあ。

645 ：Name_Not_Found：2006/10/10(火) 01:37:59 ID:???

じゃあ、<input>が段落に入らないという人は、これはどうなの？

<p><textarea>ここに文章を書いてください。</textarea></p>

646 ：Name_Not_Found：2006/10/10(火) 01:49:21 ID:???

＞段落は文章が大前提。
でましたｗｗｗ

647 ：Name_Not_Found：2006/10/10(火) 01:50:44 ID:???

>>644
紙の媒体とは違いますよ。

648 ：Name_Not_Found：2006/10/10(火) 02:06:10 ID:???

内容がimgだけのパラグラフもinputだけのパラグラフも仕様書にあるがな。

649 ：Name_Not_Found：2006/10/10(火) 02:09:36 ID:???

>>645
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/forms.html#h-17.7
> readonly属性を設定することで、著者は書き換えられないテキストを
> TEXTAREA要素に記すことができる。文書中の通常のマーク付け
> テキストとの違いは、TEXTAREAの値は他のフォームデータと共に
> 提出されるという点である。
だそうなので、そのデフォルト内容が段落を意図してるなら、
別に問題なさそうに見える。

650 ：Name_Not_Found：2006/10/10(火) 02:13:18 ID:???

>>648
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/forms.html#h-17.11.1
> <P>
> <INPUT tabindex="1" type="text" name="field1">
> <INPUT tabindex="2" type="text" name="field2">
> <INPUT tabindex="3" type="submit" name="submit">
> </P>
とかな。
仕様でOKなら別にいいんじゃないか？
Strict的ではないというのかも知らんが。

651 ：Name_Not_Found：2006/10/10(火) 02:15:38 ID:???

つーか>>262,272だな。Strict的にはダメらしい。

652 ：Name_Not_Found：2006/10/10(火) 02:22:47 ID:???

そもそも、英語の意味で、pタグは文章だけでなく図などの画像を含むから。
pタグで囲うべきだと思うよ。

653 ：Name_Not_Found：2006/10/10(火) 02:29:44 ID:???

つーか日本語の意味でも図画は入るし、
英語の意味でも650みたいのは含まんだろ。

で、>>651だ、というのがこの議論だろ？

654 ：Name_Not_Found：2006/10/10(火) 02:37:08 ID:???

>>650
で、結論だな。
仕様にあるとかじゃなくて、pタグは一つのくくりとして使うべき物だからね。
文章云々言ってる人はhtml知らない人だと思われる。

655 ：Name_Not_Found：2006/10/10(火) 02:40:31 ID:???

>>153、>>164で結論出てるのに、
何ごちゃごちゃやってんだよww

656 ：Name_Not_Found：2006/10/10(火) 02:48:13 ID:???

これからはもうdivは要らないな。
セクションdivもdivじゃなくてpを使うべきだろ。

657 ：Name_Not_Found：2006/10/10(火) 02:48:49 ID:???

>>656
pの中にp入れられないから、むりだべ

658 ：Name_Not_Found：2006/10/10(火) 02:50:08 ID:???

例えば、穴埋め文章問題のテストを、CGIで自動採点するようなページを
考えてみる。すると、フォーム内は、

<p>1192年、<input>が征夷大将軍となり、鎌倉幕府を開いた。彼は…</p>

このように、明らかにP要素内に<input>が入るだろう。そして、<input>の
現在値（ユーザーから入力された文字列）がその段落の文章の一部として
構成されることが分かる。

ところで、仕様書によれば、<input>はまず初期値（value属性値）を現在値
としてセットし、ユーザーの入力やスクリプトによって、その現在値が変更
されるとある。submitやhiddenも同様だが、これはユーザーの入力による
現在値の変更はないので、初期値がそのまま現在値となる。

ということは、これらをまとめると、submitボタンのvalue属性値なども
現在値として、文章の一部として構成されるので、文脈によっては、それ単独で
P要素に入る事もあり得るという事にならないか？

659 ：Name_Not_Found：2006/10/10(火) 02:52:28 ID:???

>>658
それで合ってますが、
すいません…だいぶ前に結論出てるんですよ…
今更蒸し返さなくても…

660 ：Name_Not_Found：2006/10/10(火) 03:00:04 ID:???

>>659
いやなに、>>630 や >>641 が未だに >>305 にリンクを張るので、
ボタンだけでも段落になる理由を示したんだ。

661 ：Name_Not_Found：2006/10/10(火) 03:00:16 ID:???

>>658
いや文脈じゃないんだ。そうやって一回テキストとして文章として文脈を探るから外れる。

662 ：Name_Not_Found：2006/10/10(火) 03:02:19 ID:???

>>657
pタグは一つのくくりとして使うべき物なのに、
なんでブロック要素を含めないんだろうな。
仕様がおかしいよな。

663 ：Name_Not_Found：2006/10/10(火) 03:04:07 ID:???

>>660
文章の一部にinputが入ってる例にしかなってないよ

664 ：Name_Not_Found：2006/10/10(火) 03:14:07 ID:???

>>663
<input>の現在値が段落内の文字列になるという例だよ。
なら、submitのvalueだって、段落内の文字列になるから、
submit単体でも段落になり得ると。

665 ：Name_Not_Found：2006/10/10(火) 03:18:44 ID:???

>>664
原文をそのまま理解しろ。または初心者スレに池

666 ：Name_Not_Found：2006/10/10(火) 03:20:12 ID:???

>>664
文字列の話ではないよ。

667 ：Name_Not_Found：2006/10/10(火) 03:24:58 ID:???

>>317 が適切

で結論でてる　

668 ：Name_Not_Found：2006/10/10(火) 07:37:50 ID:???

<form>
　<div class="">
　　<label for="hoge1"></label><input id="hoge1" /><br />
　　<label for="hoge2"></label><input id="hoge2" /><br />
　　<label for="hoge3"></label><input id="hoge3" /><br />
　　<input type="hidden" />
　　<input type="submit" />
　</div>
</form>

かんぺき！

669 ：Name_Not_Found：2006/10/10(火) 07:51:51 ID:???

このスレの住人が大好きなkanzakiでも、
メニューでdiv直下にspanとa置いてるよな。

670 ：Name_Not_Found：2006/10/10(火) 07:53:38 ID:???

>>662
それは一つのくくりとして使うべき物じゃないからじゃないか？

671 ：668：2006/10/10(火) 08:14:12 ID:???

input type="hidden"だけを別途ddやらpやらその他何やらでマークアップしようとするのは
変だと思う。input type="hidden"を個別にマークアップしないと成り立たなくなる方法は
採用できなくなーい？
やっぱりフォーム周りは特殊だから>>668っすね！うん！

672 ：Name_Not_Found：2006/10/10(火) 08:22:23 ID:???

>>671

ネタ乙ｗ

673 ：Name_Not_Found：2006/10/10(火) 08:26:41 ID:???

>>668
仕様書で P 使ってるから P でもいい、っていうひとは、これを拒否する理由はないだろうね。
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html
では P もつかってるし TABLE もつかってるし FIELDSET も使ってるから。
そういうひとは「FIELDSET 直下にインラインの input 置くのはナシ」とかも言えないな。

674 ：Name_Not_Found：2006/10/10(火) 09:52:48 ID:???

4.01時代の持ってきてもしょうがないね

XHTMLの仕様書手抜きだよなーｗ

675 ：Name_Not_Found：2006/10/10(火) 10:17:20 ID:???

>>674
しょうがないとかｗ
じゃあどこの仕様書の例を参考にして賛成反対言ってるわけなんだぜ？

676 ：Name_Not_Found：2006/10/10(火) 11:32:16 ID:???

>>675
時代遅れで内容も古いからな
全てが当てはまるわけでもなく
結構いいかげん

677 ：Name_Not_Found：2006/10/10(火) 13:40:21 ID:???

>>671
ひとつのフォームの中のinputはinputだもの。
段落をテキストだの文章だの言ってるやつらが勘違いしてる。

678 ：Name_Not_Found：2006/10/10(火) 13:42:59 ID:???

>>672
乙武くん乙

679 ：Name_Not_Found：2006/10/10(火) 15:13:25 ID:???

そもそも<input type="text" />や<input type="radio" />や<input type="checkbox" />ほか
input要素はそれだけだとパラグラフにもリストにも扱えないような。

<dl>
<dt>性別</dt>
<dd><label for="male">男</label><input type="radio" id="male" /></dd>
<dd><label for="female">女</label><input type="radio" id="female" /></dd>
<dd><label for="other">その他</label><input type="radio" id="other" /></dd>
～略～
</dl>

などと何らかの文字列とセットならありかも知れないけど

<dl>
<dt><label for="name">名前</label></dt>
<dd><input type="text" id="name" /></dd>
～略～
</dl>

とか空っぽの入力ボックスがあるだけなのに
用語の定義としてマークアップされるのは気に入らねえ！

いや、上記の例も「性別」という用語に対して「男」「女」「その他」が定義されているのは変か。

680 ：Name_Not_Found：2006/10/10(火) 16:20:06 ID:???

>>679
問題は文字列じゃないんだってば。低能。

681 ：Name_Not_Found：2006/10/10(火) 16:52:15 ID:???

>>679
いい加減もう消えてもらえないかな。
これ以上素人と話しても平行線だ

682 ：Name_Not_Found：2006/10/10(火) 17:05:46 ID:???

釣ろうと必死な人が2連続レスしています。

683 ：Name_Not_Found：2006/10/10(火) 17:09:27 ID:???

>>679
アホやろ。おまえ。

684 ：Name_Not_Found：2006/10/10(火) 17:16:43 ID:???

StrictなHTMLを書きたい奴必見のページ見つけたぞ！
ttp://sendai.cool.ne.jp/perhtml/

685 ：Name_Not_Found：2006/10/10(火) 17:17:50 ID:???

いろんな話題が混在してるから話がまとまらないんじゃない？
imgだけinputだけをpに入れるのはどうなのよ、て話と
form内はどうマークアップするのがいいの、て話と
inputってそもそもどういう位置づけなのよ、て話と
その他いろいろ入り混じってる
気がする

686 ：Name_Not_Found：2006/10/10(火) 17:24:00 ID:???

>HTMLはIEにページの表示結果を制御するためのプログラミング言語のことである。

いきなりのこれにお茶吹いたｗｗｗｗｗｗｗｗ

>>685
引っ掻き回したい人も混じってるから、そのせいもあるだろうな。

687 ：Name_Not_Found：2006/10/10(火) 17:26:28 ID:???

cool.ne.jpは見る気もしない

688 ：Name_Not_Found：2006/10/10(火) 17:40:04 ID:???

プログラミング連発ｗ

689 ：Name_Not_Found：2006/10/10(火) 17:40:14 ID:???

禿ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

690 ：Name_Not_Found：2006/10/10(火) 17:45:45 ID:???

今までの話を各テーマごとにまとめてください
後から読むと話がかみ合っていないように見えます

691 ：Name_Not_Found：2006/10/10(火) 17:51:43 ID:???

>>685
p要素はブロック要素を含まない限りなんでも入れていいと主張する人と、
一般に言う段落(パラグラフ)じゃないものを含むなよ、という人の二つに分かれるよ。

692 ：Name_Not_Found：2006/10/10(火) 17:55:11 ID:???

>>691
一般的には、図とかの画像も1つの段落に含むんだが
どうも中卒レベルで話してる奴がいてなぁ

693 ：Name_Not_Found：2006/10/10(火) 17:56:34 ID:???

うんこするよ、うんこしないよ、うんこするけどすぐに消え去るよ、うんこじゃない別の何かをするよ、
みたいな系図で表現して

694 ：Name_Not_Found：2006/10/10(火) 17:57:54 ID:???

一般的には、といった表現が問題なんだと思う。
仕様書などを指し示して、ここに書いてあるじゃろがー
って言わないと

695 ：Name_Not_Found：2006/10/10(火) 17:59:20 ID:???

それが書いてないんだわ

696 ：Name_Not_Found：2006/10/10(火) 18:00:59 ID:???

>>684
おもしれえええｗｗｗｗｗｗｗｗｗ

697 ：Name_Not_Found：2006/10/10(火) 18:07:36 ID:???

>>694
仕様の定義では、HTMLに限った特別な段落の定義をしてないから、
一般的な意味で考えるべきだよね、ということよ。

>>692の言うとおり、世の中には画像や図も段落中に含まれることが
よくある、というのはさんざん言われてきたことだな。

けど、そこから飛躍して、「単なる画像だけでも段落と言う」「単なるボタン
だけでも段落と言う」と一般にない主張する人がいるんだよね。

あと、「type="button"なinputに限らずvalue属性値は必ず閲覧者に示される」
という誤った認識の上で、「value属性値が文章ならinput単独でも文章になる」
と主張する人も涌いては消え涌いては消え。

698 ：Name_Not_Found：2006/10/10(火) 18:10:51 ID:???

>>697
＞「単なるボタンだけでも段落と言う」と一般にない主張する人がいるんだよね。

まぁ、HTMLだからww

699 ：Name_Not_Found：2006/10/10(火) 18:11:42 ID:???

> 一般的には、図とかの画像も1つの段落に含むんだが

例えば、
<body>
<p><img src="photo_sakura.png" alt="桜の木の写真" /></p>
</body>
ってのはアリ？

700 ：Name_Not_Found：2006/10/10(火) 18:11:47 ID:???

もう水掛け論は秋田

701 ：Name_Not_Found：2006/10/10(火) 18:13:08 ID:???

>>699
ありっていうか、仕様上そうしないとダメ。

702 ：Name_Not_Found：2006/10/10(火) 18:13:39 ID:???

>>700
というより過去ログ無視して意図的にループに持ち込みたい様子。

703 ：Name_Not_Found：2006/10/10(火) 18:13:42 ID:???

>>697
一般ってどの分野の一般？
HTMLに関することを「一般」を引用して語るんだからHTMLの一般じゃないよね。
「段落」や「画像」や「ボタン」が存在する分野ってほかに思いつかないんだけど。

704 ：Name_Not_Found：2006/10/10(火) 18:15:14 ID:???

仕様上そうしないとダメって誰が決めたのｗ
UL だって DIV だって許されてるでしょ。

705 ：Name_Not_Found：2006/10/10(火) 18:15:18 ID:???

「一般」「常識」「定説です」「最高ですか」は禁止。

706 ：Name_Not_Found：2006/10/10(火) 18:17:39 ID:???

>>703
お前は段落中に図や絵が出てくる書籍を読んだことがないのか？
というのが頻出。

そもそも、絵や図や段落やボタンなんて身近に存在するじゃないか。
絵や図は段落とともに現れることがあって、単なるボタンの出現は
段落と結びつくことがない、というのが一般でしょ？

707 ：Name_Not_Found：2006/10/10(火) 18:17:57 ID:???

>>704
どう考えても、DIVはだめだろww

708 ：Name_Not_Found：2006/10/10(火) 18:17:58 ID:???

>>705
「みんなも言ってる」「みんなも思ってる」「先生が言ってた」も禁止。

709 ：Name_Not_Found：2006/10/10(火) 18:19:16 ID:???

>>706
> 段落中に図や絵が出てくる書籍
画像をうｐして

710 ：Name_Not_Found：2006/10/10(火) 18:19:46 ID:???

>>684
よく読んだらそんなに面白くなかった(´･ω･｀)

711 ：Name_Not_Found：2006/10/10(火) 18:21:11 ID:???

>>706はフォーム周りはどうマークアップしてる？
後半の意見が参考になったんだけどそれを
フォームのマークアップに生かそうとすると違和感を感じて

712 ：711：2006/10/10(火) 18:22:24 ID:???

>フォームのマークアップに生かそうとすると違和感を感じて
というかどうすればいいのか思いつかないだけだけど・・・

713 ：Name_Not_Found：2006/10/10(火) 18:23:54 ID:???

>>707
なんで？ <div class="image"> とかでもだめ？

まあ >>699 がアリなら <p><input/></p> もアリかなと思ったわけなんだが。

714 ：Name_Not_Found：2006/10/10(火) 18:25:14 ID:???

どう考えてもだめなんです

715 ：Name_Not_Found：2006/10/10(火) 18:25:33 ID:???

例えばディスプレイの設定ボタンが並んでいたらそれはボタンのリストなの？
ボタンがあって、各ボタンにコントラスト、ブライトネス、って書いてあったら定義リスト？
・・・でいい？

716 ：Name_Not_Found：2006/10/10(火) 18:27:27 ID:???

>>713
ダメでＦＡ。しつこい。

717 ：Name_Not_Found：2006/10/10(火) 18:28:33 ID:???

>>715
文章や表示と構造は違いますよでＦＡ。しつこい。

718 ：Name_Not_Found：2006/10/10(火) 18:28:38 ID:???

>>715はどっちかというとチェックボックスに近いのかな・・・？
サブミットボタンは、ボタンそのものに何か文字や絵が描いてあるボタン？
だとしたらそれにさらに定義リストでマークアップそのボタンの定義を書くのは変っすよね・・・？

719 ：Name_Not_Found：2006/10/10(火) 18:29:57 ID:???

>>718
書いてある事は構造と違いますよでＦＡ。しつこい。

720 ：Name_Not_Found：2006/10/10(火) 18:30:23 ID:???

>>717
> 文章や表示と構造は違いますよでＦＡ。
formやinputあたりはずばりどうマークアップすればいいんですか・・・？

721 ：Name_Not_Found：2006/10/10(火) 18:30:44 ID:???

だから、考えてもだめなんです。しつこい。

722 ：Name_Not_Found：2006/10/10(火) 18:33:04 ID:???

一般の世界ではボタン上に文字や絵が書いてあるケースが多いと思う
一般の世界ではそれは段落ではないし段落の一部を構成するとも思えないけど、
じゃあそれをHTMLの世界に持ってきた場合は何に相当するのか、
そこが知りたい。
何にも相当しない場合はdivで？

723 ：Name_Not_Found：2006/10/10(火) 18:34:22 ID:???

あれもこれも違うけど、何が適切なのか言えない

724 ：Name_Not_Found：2006/10/10(火) 18:34:23 ID:???

>>722
それは初心者スレに行って下さい。

725 ：Name_Not_Found：2006/10/10(火) 18:34:46 ID:???

( ´,_ゝ｀)ﾌﾟｯ

726 ：Name_Not_Found：2006/10/10(火) 18:35:42 ID:???

>>714
>>716
>>717
>>719
>>721
>>724
これはひどい

727 ：Name_Not_Found：2006/10/10(火) 18:36:23 ID:???

スルーしとけ

728 ：711：2006/10/10(火) 18:38:04 ID:???

>>706さんはいなくなった？食事中？

729 ：Name_Not_Found：2006/10/10(火) 18:38:25 ID:???

空気嫁よ

730 ：Name_Not_Found：2006/10/10(火) 18:39:55 ID:???

否定はできるけど自分の意見は言えない人がいるね、今。

731 ：Name_Not_Found：2006/10/10(火) 18:40:58 ID:???

>>729
空気の押し売りはやめてください

732 ：Name_Not_Found：2006/10/10(火) 18:41:08 ID:???

>>730
紙とWebの違いから説明する気がしない。

733 ：Name_Not_Found：2006/10/10(火) 18:42:05 ID:???

紙とWEBが違うからこそ紙のルールを持ち込むことはできない

734 ：Name_Not_Found：2006/10/10(火) 18:43:50 ID:???

>>728
俺は>>314。

735 ：Name_Not_Found：2006/10/10(火) 18:45:10 ID:???

>>734
違います。

736 ：Name_Not_Found：2006/10/10(火) 18:46:14 ID:???

>>730
というか、「紙とは違う」とだけは言えても、
どう違うか説明して突っ込みどころ満載になるのは嫌なんだろ。

「違う」というだけでなんでも好き勝手できるなら仕様はいらんわな。

737 ：711：2006/10/10(火) 18:47:14 ID:???

>>734
どうもです。それいい感じですね。

738 ：Name_Not_Found：2006/10/10(火) 18:49:01 ID:???

>>736
さんざん説明してるのに理解出来ないのはあなたが低能だからですよ。

739 ：Name_Not_Found：2006/10/10(火) 18:50:35 ID:???

>>737
表示されるかされないかで定義リストの項目から外すというのは無い。

740 ：Name_Not_Found：2006/10/10(火) 18:50:46 ID:???

すべてにおいて紙とウェブが違うと言っているのか、
フォームコントロールに関してだけ紙とウェブが違うと言っているのか、
それすらわからん。

741 ：Name_Not_Found：2006/10/10(火) 18:51:18 ID:???

>>738
そのレス番号を指し示してください
熟読します

742 ：Name_Not_Found：2006/10/10(火) 18:52:26 ID:???

自分で探せよ低能。

743 ：Name_Not_Found：2006/10/10(火) 18:54:56 ID:???

>>741
>>717と>>719ではわかりませんか。

744 ：711：2006/10/10(火) 18:55:13 ID:???

>>739
嫌い・・・って、定義リストを使ってhiddenとsubmitをどうマークアップするんですか？
スタイルシートを使わないすっぴんの状態でも意味を伝えるとしたら
回りくどくなると言うか冗長になるというか、そんな感じになりそうな気がするんですが・・・

発想が乏しいので変なのしか思いついていないだけかもしれませんが

745 ：Name_Not_Found：2006/10/10(火) 18:56:20 ID:???

IDがないと引っ掻き回したいやつがどれだかわからなくてだるいな。

746 ：Name_Not_Found：2006/10/10(火) 18:56:38 ID:???

>>743
さんざん説明してる…って…さんざん？？

747 ：Name_Not_Found：2006/10/10(火) 18:57:15 ID:???

具体的なことを言わない奴はスルー汁
>>742
>>743
このあたり

748 ：Name_Not_Found：2006/10/10(火) 18:57:26 ID:???

>>744
dlの項目としてはhiddenもsubmitも構造上違いはありません。

749 ：Name_Not_Found：2006/10/10(火) 18:58:07 ID:???

一般的には中卒レベルで話してるいい加減もう消えてもらえない素人と話しても平行線あなたが低能

750 ：Name_Not_Found：2006/10/10(火) 19:03:16 ID:???

>>744
俺は>>361という結論に達した。

751 ：Name_Not_Found：2006/10/10(火) 19:11:08 ID:???

>>361
マークアップの方法というか話のまとめ方がうまいな

752 ：Name_Not_Found：2006/10/10(火) 19:22:16 ID:???

>>748
あたりまえだろう、属性なのだから。

753 ：Name_Not_Found：2006/10/10(火) 19:38:09 ID:???

>>752
つ>>314

754 ：Name_Not_Found：2006/10/10(火) 19:58:45 ID:???

なるほど、P厨はHTMLの構造しか見てないから
「構造さえ正しければなんでもあり」になるわけだな。

755 ：Name_Not_Found：2006/10/10(火) 20:14:46 ID:???

>>753
？

756 ：Name_Not_Found：2006/10/10(火) 20:17:22 ID:???

>>754
文字列文字列うるさい。ばーか。

757 ：Name_Not_Found：2006/10/10(火) 20:23:28 ID:???

>>753

>>748は>>314が正しいとか主張に対する人へのレス。
hidden属性は見えないから、submit属性は見えるからボタンだからという理由で別扱いするとかいうアホアホ理論の否定。

758 ：Name_Not_Found：2006/10/10(火) 20:32:55 ID:???

>>757
HTMLは構造のみ記述する言語じゃないのて
「構造上違いはないですよ」じゃ否定になってませんよ。

759 ：Name_Not_Found：2006/10/10(火) 20:44:07 ID:???

>>757
そもそも、マークアップの為のマークアップってどうなの？

760 ：Name_Not_Found：2006/10/10(火) 20:55:11 ID:???

>>757
見えるから、見えないから、ボタンの形をしているから、じゃなくて
labelをつける必要が無いから、じゃない？
ほかのinputにそろえるために不必要なものにまでlabelを付ける・・・てのは。
labelが不要だったらdtも不要で、となると定義リストである必要もない、と。

761 ：Name_Not_Found：2006/10/10(火) 20:57:18 ID:???

>>361
ってことだね
各項目に対して各人が個別に
項目名のラベルをつけるかつけないか判断する

762 ：Name_Not_Found：2006/10/10(火) 20:58:58 ID:???

>>758
それはおまえが文字列からしか構造をみないから。

763 ：Name_Not_Found：2006/10/10(火) 20:59:58 ID:???

>>759
それこそdivの事だ。

764 ：Name_Not_Found：2006/10/10(火) 21:04:39 ID:???

>>762
私のものの見方がなんであれ関係なく、
HTMLは構造のみ記述する言語じゃないので
「構造上違いはないですよ」じゃ否定になってませんよ。

765 ：Name_Not_Found：2006/10/10(火) 21:05:15 ID:???

つか
パラグラフ＝段落＝テキスト
なんて論外。

766 ：Name_Not_Found：2006/10/10(火) 21:06:17 ID:???

また論点が入り混じってる。わざとか

767 ：Name_Not_Found：2006/10/10(火) 21:09:47 ID:???

少なくとも<input type="submit" />には<label></label>は不要だね

ttp://www.w3.org/TR/html401/interact/forms.html#h-17.9
> Some form controls automatically have labels associated with them (press buttons)

だから

<dl>
　<dt><label for="hoge">（ここに何を書くのか知らないが）</label></dt>
　<dd><input type="submit" id="hoge" /></dd>
</dl>

これはない。

768 ：Name_Not_Found：2006/10/10(火) 21:13:58 ID:???

>>763
divはその意味でも役割は有る。
他の要素で同じ事をするのはどうなんだ？

769 ：Name_Not_Found：2006/10/10(火) 21:20:15 ID:???

>>767
文盲ｗｗｗｗｗｗｗｗｗｗｗ何言ってんだおまえｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

770 ：Name_Not_Found：2006/10/10(火) 21:23:45 ID:???

>>768
低能帰れ

771 ：Name_Not_Found：2006/10/10(火) 21:24:15 ID:???

>>769は具体的に反論できない。「ｗ」の数でわかる

772 ：Name_Not_Found：2006/10/10(火) 21:25:06 ID:???

バカを煽るな　レスすんな

773 ：Name_Not_Found：2006/10/10(火) 21:26:15 ID:???

田植えするので精一杯

774 ：Name_Not_Found：2006/10/10(火) 21:29:10 ID:???

>>770
4文字レスは具体的に突っ込まなくていいから楽ですねｗ

775 ：Name_Not_Found：2006/10/10(火) 21:32:11 ID:???

>>774
お薬飲んで寝なさい。

776 ：Name_Not_Found：2006/10/10(火) 21:33:42 ID:???

得意げに具体例だして間違えてるバカに具体例を出してもわからないだろｗｗｗｗｗ

777 ：Name_Not_Found：2006/10/10(火) 21:36:19 ID:???

>>767
http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1
> More than one LABEL may be associated with the same control
> by creating multiple references via the for attribute.
ということなので、ひとつのコントロールに複数のラペルを関連付けることは
別に構わないんだよ。必要か不要かはラベルの個数では判定できない。

俺にはわざわざ複数のラベルをつける積極的な理由が思いつかんけどな。

778 ：Name_Not_Found：2006/10/10(火) 21:36:24 ID:???

>>774

>>730,736

今もまだいる。
ばかとかばかじゃないとかじゃなくてただの構ってちゃんだろうからスルーで。

779 ：Name_Not_Found：2006/10/10(火) 21:37:54 ID:???

>>778
おまえが煽ってるのに気付けよ。いいかげんにしろ。

780 ：Name_Not_Found：2006/10/10(火) 21:38:46 ID:???

>>777
hiddenはラベルを持っていないけどラベルを付ける必要がない（つけてもいいけど）でFA？

781 ：Name_Not_Found：2006/10/10(火) 21:51:24 ID:???

>>780
ラベルは必要だって人もいるので、結局著者の意図次第だなあ。
少なくともP直下にFIELDSETとかいうレベルでの「意味なし」というわけではない。

782 ：Name_Not_Found：2006/10/10(火) 22:03:43 ID:???

361で話がまとまってたんですね

783 ：Name_Not_Found：2006/10/10(火) 22:07:12 ID:???

並行するほかの話はまだっぽいけどね。

784 ：Name_Not_Found：2006/10/10(火) 22:20:42 ID:???

>>779
かまってちゃん乙

785 ：Name_Not_Found：2006/10/11(水) 00:01:32 ID:???

>>697
> あと、「type="button"なinputに限らずvalue属性値は必ず閲覧者に示される」
> という誤った認識の上で、「value属性値が文章ならinput単独でも文章になる」
> と主張する人も涌いては消え涌いては消え。

表示されるかどうかは関係ないだろ。<img>だって、画像が表示されるときは
altは表示されないが、altの内容が段落として成り立つものなら<img>単独でも
段落になるわけだし。

786 ：Name_Not_Found：2006/10/11(水) 00:25:18 ID:???

>>785
> <img>だって、画像が表示されるときはaltは表示されないが、
> altの内容が段落として成り立つものなら<img>単独でも段落になるわけだし。
なあなあ、altは画像に対する説明であって、altで伝えるようなことは
画像でもちゃんと伝えないとダメだぞ？
つまり、「画像単体じゃ段落じゃないけどaltの値は段落だ」という前提
自体がHTMLとして不正だよ？

787 ：Name_Not_Found：2006/10/11(水) 00:32:07 ID:???

んでまたinputのhiddenの話しが始まるだろ・・・
あーあ

788 ：Name_Not_Found：2006/10/11(水) 00:49:41 ID:???

ん？altって画像が表示される環境でも表示されなかったっけ？
画像を読み込むまでの間とか。

789 ：Name_Not_Found：2006/10/11(水) 00:54:34 ID:???

>>788
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/objects.html#h-13.2
> ユーザエージェントは、画像をサポートしていないか、ある特定の画像形式を
> サポートしていないか、または画像を表示しないよう設定されているような場合にのみ、
> 代替テキストを表示するようにしなければならない。

790 ：Name_Not_Found：2006/10/11(水) 00:54:39 ID:???

>>788
そうだけどその見方は嫌い。

791 ：Name_Not_Found：2006/10/11(水) 01:01:05 ID:???

>>789-790
THX。なるほどね。
だけど、リファラとかの制限で画像が送られてこなかったりする場合や、
画像が壊れてる場合もあるから、その仕様のままだとちょっと不足だよなぁ。

画像が読み込まれる前の状態は、画像データを取得できなかったり
壊れてる状態とほぼ同じと言えるだろうから、その間表示されてるのは当然な気もするし。

792 ：Name_Not_Found：2006/10/11(水) 01:31:02 ID:???

>>791
ごめん、本家の仕様書見たら書いてあること違った。
http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.2
> User agents must render alternate text when they cannot support images,
> they cannot support a certain image type or when they are configured not to display images.
和訳に現れる「のみ」なんて言葉は入ってない。
単に「～という場合は、必ずaltを表示しなさいね」としか言ってない。

で、
http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.8
> Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors specify alternate text
> to serve as content when the element cannot be rendered normally
ということだから、「altは非テキスト要素が正常に描画されないときに描画されるように
書いておくものですよ」というものでOKだと思う。

793 ：Name_Not_Found：2006/10/11(水) 04:08:00 ID:???

とりあえず、まとめます

Excellent!! = <p>あああああ</p>
Poor = <div class="hoge">あああああ</div>

Excellent!! = <p><img src="" alt="hoge"></p>
Poor = <div class="hoge"><img src="" alt="hoge"></div>

これで、わかったと思います。

794 ：Name_Not_Found：2006/10/11(水) 07:40:03 ID:???

(゜Д゜)ﾎﾟｶｰﾝ

795 ：Name_Not_Found：2006/10/11(水) 07:44:52 ID:???

>>793

なるほど、分かりやすい。

796 ：Name_Not_Found：2006/10/11(水) 08:00:31 ID:???

Excellent!! = <p><input name="submit" value="submit"/></p>
Poor = <div class="hoge"><input name="submit" value="submit"/></div>

797 ：Name_Not_Found：2006/10/11(水) 10:53:33 ID:???

Excellent!! = <p><object type="text/html" data="hoge.html"/></p>
Poor = <div class="hoge"><object type="text/html" data="hoge.html"/></div>

> hoge.html
<body>
<p>ほげほげ</p>
<p>ふがふが</p>
</body>

なにか問題ある？

798 ：Name_Not_Found：2006/10/11(水) 11:38:53 ID:6F5qcgAN

ちょっと来てない間にこのスレ凄い伸びてるな。

799 ：Name_Not_Found：2006/10/11(水) 12:11:40 ID:???

>>797
その場合はむしろdivがいいんじゃ･･･
hoge.htmlの内容が何かわからないし、いろいろな場合が考えられる訳だし。

800 ：Name_Not_Found：2006/10/11(水) 20:55:02 ID:???

>>793,795,796,797
まとめる前に、770みたいな煽りで誤魔化したレス全部に
反論しなおしたら？

801 ：Name_Not_Found：2006/10/11(水) 21:41:16 ID:???

反論とかいいよ

その「とりあえず、まとめます」も誰も真に受けてないだろうし

802 ：Name_Not_Found：2006/10/12(木) 00:46:59 ID:???

まぁ、正し過ぎて反論できないなぁ

803 ：Name_Not_Found：2006/10/12(木) 01:14:25 ID:???

現に誰も反論も何も出来てない。
不毛なスレもピタっと止まった。

まとめGJです！

804 ：Name_Not_Found：2006/10/12(木) 01:50:43 ID:???

>>786
画像と全く関係ないaltを付けたとかでもない限り、「altは段落だけど
画像は段落ではない」なんていう事態は起こりえないと思うが。

情報量の多い画像（写真など）はいくらでも訴えてくるものがある（物語らせる
ことが出来る）から、そういう画像はそれ単体で段落としての意味を持っている
とも言えるわけで。

例えばこんなaltが付くような画像。↓
<img alt="その女の子はこちらを向いてまるで天使のように微笑みかけていた。肩まで伸びた髪は…(略)"/>

805 ：Name_Not_Found：2006/10/12(木) 02:11:39 ID:???

>>804
ただ、そういった情景を描いた画像は、その情景を説明する文章とイコールではないような気もする。

これが img ではなく object だったのなら
<ul>
　　<li><object data="hoge.png" type="image/png">
　　　　<a href="hoge.png">hoge.png</a>
　　</object></li>
</ul>
という風に（自分なら）書くのですが……。

806 ：Name_Not_Found：2006/10/12(木) 04:16:14 ID:???

>>804-805
> ただ、そういった情景を描いた画像は、その情景を説明する文章とイコールではないような気もする。
これに尽きると思うよ。

だって、同じ画像についての説明でも、
段落形式だったり箇条書き形式だったりしうるもんね。
画像と、それの説明文って、違うものでしょ？

逆を言うと、
　> そういう画像はそれ単体で段落としての意味を持っているとも言えるわけで。
というのが成り立つなら、段落形式の説明文を書けるなにもかもが
段落であることになるわけで。「じゃあ段落って何？段落って、そういう形式のこと
だけじゃなくて、段落で説明されるものすべてが段落なの？」ってことになっちゃう。

807 ：Name_Not_Found：2006/10/12(木) 06:03:04 ID:???

>>803
ループが不毛だからしないだけだろ。
この1スレ使ってでたそのひとの結論が >>793,796,797 じゃ、もう何も言うことないわ。

808 ：Name_Not_Found：2006/10/12(木) 08:18:48 ID:???

imgのみのpによるマークアップについての是非はまだ続いてるのね

809 ：Name_Not_Found：2006/10/12(木) 11:31:11 ID:???

>>806
イコールでないのは当然でしょう。あくまで代替文なんだから。

その画像が、ほとんど背景画像のように効果としてレイアウトされているだけ
なら、altは単純になるだろうし、ページ内の重要な意味があるのなら、それの
「代替」なんだから詳しくなるべきでしょ。

つまり、同じ単独画像でも、ページ内でどういう意味を持つのかによって、
リスト項目になったり段落になったりすべきなんだよ。常に段落にはならない
と考える方がおかしい。

810 ：Name_Not_Found：2006/10/12(木) 16:25:29 ID:???

誰かまとめサイトをつくって。

811 ：Name_Not_Found：2006/10/12(木) 16:49:21 ID:???

言い出しっぺの法則

と何度書かれたことか

812 ：Name_Not_Found：2006/10/12(木) 18:56:07 ID:???

>>809
> その画像が、ほとんど背景画像のように効果としてレイアウトされているだけ
> なら、altは単純になるだろうし、ページ内の重要な意味があるのなら、それの
> 「代替」なんだから詳しくなるべきでしょ。
altが単純か詳しいかと、altが段落か箇条書きかとは別の話だよね？
逆を言うと、altが段落形式で説明されるからって画像が段落形式としての
表現をしているかどうかとは別だよね？
>>806でも
　> 逆を言うと、
　> 　> そういう画像はそれ単体で段落としての意味を持っているとも言えるわけで。
　> というのが成り立つなら、段落形式の説明文を書けるなにもかもが
　> 段落であることになるわけで。「じゃあ段落って何？段落って、そういう形式のこと
　> だけじゃなくて、段落で説明されるものすべてが段落なの？」ってことになっちゃう。
と指摘したよ。

> つまり、同じ単独画像でも、ページ内でどういう意味を持つのかによって、
> リスト項目になったり段落になったりすべきなんだよ。
だよね。altに拠るんじゃなくて、画像それ自身について考えれらるべきだよね。
リスト形式にはリスト形式という意味づけを、画像には画像という意味づけを、
段落形式には段落形式という意味づけを。
ページ内、つまりページ上でのHTMLにおける意味付けをするべきなんだよ。

813 ：Name_Not_Found：2006/10/12(木) 19:44:31 ID:???

要約してください
↓

814 ：Name_Not_Found：2006/10/12(木) 20:23:41 ID:???

>>813
>>1-812

815 ：Name_Not_Found：2006/10/14(土) 04:39:29 ID:???

>>812
altが段落形式で説明されて、画像が段落形式としての表現をし、
説明と表現の内容が一致する場合がある。
　例：なんだってー！(MMRのワンシーン)
勿論、そうではない場合も有る。
これでいいじゃん。

しかも、結局そのhtmlの編集者の意図にそったものになるんだから、
画像の示す意味とaltの示す意味は一致させるのが当然と考えるよ。
altは本来は説明だけど、画像を選んだ人が説明を書くのであれば、
それは編集者がその画像を使った意図そのものが書いてあるって事だよね。
(勿論そうでない場合もあるけど)
だから一致しない状況ってのがそもそもの疑問だし、
意味や意図をわかってるんだから、pにするかしないか等の判断も出来て当然の状態。

なんか、考えがへんてこな状況設定になってないかね。
画像を選んだ人と、altの内容を考えた人と、マークアップの作業をした人が
全て別人の状態っていう、限定状況をベースにしてならその疑問が説明つくけど、
その場合は画像を選んだ人とaltの内容を考えた人の意図の不一致が問題なだけだし。

816 ：Name_Not_Found：2006/10/14(土) 05:06:03 ID:???

>>815
> 勿論、そうではない場合も有る。
> これでいいじゃん。
そんな限定的な結論はとっくに既出なのです。

> 画像の示す意味とaltの示す意味は一致させるのが当然と考えるよ。
表現の意味や意図だけでp要素となるわけではなく、
形式もp要素の意味付けとしては重要です。
段落としての形式でなければアウト。

画像の表現が段落形式ではないのに画像の説明が
段落形式である、というのはよくありますよね。

MMRの例では、台詞部分を考慮した全体が段落として
解釈できるかもしれないね、というような感じですね。

ただの花の絵は、どうみても段落形式ではないですよね。
「これは独自の言語で記述された文章で、この言語の
文法では段落である」とか主張するんでもなければ。

817 ：Name_Not_Found：2006/10/14(土) 11:31:40 ID:???

>>816
だから、作成者の意図どおりにすればいいんじゃない？
貴方にとってただの花の絵が段落形式に見えなかったとしても、
作成者にとってはその意味があるのかもしれないよ。
絵画や漫画のネタみたいに、ある程度の下地や知識がないと
理解できない類の場合もありえるからね。

ちなみに、MMRを例として出したけど、セリフは無くても全体が段落として
解釈できる場合も普通に考えられる。
のどの渇きに飢えている人の絵なりがあって、altで水をくれ･･･みたいな感じで使うとか。
ただ、これはたまたまわかりやすいだけであって、
これが何処までわかってもらえるかとは、また別の問題。

やっぱり製作者の意図を持って判断するしかない気がするな。
構成的にpでないとつながりがおかしい場合なら、必然としてaltもp形式にすればいいし、
どうにでもなる程度の融通の余地も有るんじゃないかね。
ちなみに、最初に文章があってそれの代替する表現として画像を使用するから、
pである必要があるって感じの状況の場合ね。

そういう前提無しにpである必要が･･･って考えるとドツボにはまるよ。
元々pでなくてもいい場合は、つながり的にも意味的にもpである必要は無いってだけだし。

818 ：Name_Not_Found：2006/10/14(土) 13:20:22 ID:???

>>817
> 貴方にとってただの花の絵が段落形式に見えなかったとしても、
> 作成者にとってはその意味があるのかもしれないよ。
それは仕様で使われる一般的な意味での段落ではないので
P要素とするには不適切なマークアップですね。
そもそも「段落形式の意味がある」という言葉が意味を成してないと
思いますが、「段落形式の意味」とはどういう意味の言葉ですか？

> やっぱり製作者の意図を持って判断するしかない気がするな。
意図によるとはいえ、段落の意味を製作者の脳内定義で捻じ曲げて
いいわけではないです。(それでは仕様の意味がないですからね。)
で、仕様書では段落について特段の定義はないので、一般的な
意味の範囲での段落と考えるべきです。(そうでなければ仕様の
意味がないですからね。)その範囲を越えるものはだめでしょう。

> どうにでもなる程度の融通の余地も有るんじゃないかね。
と言っているところからして、あなたと同じ論理で他のすべての要素を
DTD上正当であればどんな拡大解釈を適用してマークアップしようとも
問題ないということには気づいてないようですけど。

すくなくともその文書の言語として一般性に段落とみなせないものを
段落だと言い張ってP要素とするのはだめですね。
　> のどの渇きに飢えている人の絵なりがあって、altで水をくれ･･･みたいな感じで使うとか。
とか。仕様を無視したマークアップをするんじゃなくて、その独自定義の
段落もどきは素直にdivでマークアップしましょう。

819 ：Name_Not_Found：2006/10/14(土) 13:29:06 ID:???

>>818
> P要素とするには不適切なマークアップですね。
P要素とするのは不適切なマークアップですね。
> 問題ないということには気づいてないようですけど。
問題ないということになってしまうことには気づいてないようですけど。
> すくなくともその文書の言語として一般性に段落とみなせないものを
すくなくともその文書の言語としては一般的に段落とみなせないものを

さすがに誤字が多くて意味不明だった。

820 ：Name_Not_Found：2006/10/14(土) 22:44:14 ID:???

Strictという仕様はHTML 2.0の時からあった訳だけど、HTML 2.0 Strict でも
BODY直下にインライン要素を置いてはいけなかった。ただ、例外として
IMG要素だけは直下に置いても良いという仕様だったんだよな。当然、
このIMGは単独画像となる。

当時はまだDIV要素がなかった時代。BODY直下にすべてのインライン要素を
置いてはならないとすると、単独画像をP要素に入れなきゃならなくなって、
そういう仕様にするのは違和感があったからだろう。
「単独画像をP要素に入れるのは違和感がある」というのは、ある意味、HTMLの
歴史が示している見解でもあると思う。

まあ、しかし、だからといって、完全に全ての単独画像がP要素に入らないかと
言われれば、そんなの断言出来る訳がないが。

821 ：Name_Not_Found：2006/10/14(土) 22:59:57 ID:???

なんか否定の仕方が？？？って感じだね。
普通に文字の代替として画像を使う場合があるのに、
画像は一般的な段落ではないから否定されるってのがそもそもおかしい。

紙に書いた文書の途中に、後から別の紙に書き足した文をくっつけてもそれは段落だし、
それがコピーでも印画紙に焼き付けられた写植でも、段落な筈なんだけどなぁ。

822 ：Name_Not_Found：2006/10/14(土) 23:09:00 ID:???

>HTMLの歴史が示している
都合よすぎる妄言だな。

CSS勧告を見据えて作られたのが、DIVとSPAN。
これら要素型の、CSSを無視した有用性は、全て後付のアイデアである。

823 ：Name_Not_Found：2006/10/15(日) 00:59:10 ID:???

>>821
なんか肯定の仕方が？？？って感じだね。
　> 普通に文字の代替として画像を使う場合があるのに、
　> 画像は一般的な段落ではないから否定されるってのがそもそもおかしい。
という話はこの話の最中ですら否定されてないのに、そこから
「だから作者が段落だと言い張るだけでなんでもP要素として扱える」
という主張への飛躍を埋める説明は、結局できないんだもんな。

824 ：Name_Not_Found：2006/10/15(日) 09:41:52 ID:???

完全に電波スレだなこりゃｗ

825 ：Name_Not_Found：2006/10/15(日) 10:13:40 ID:???

「単独画像はP要素に入れる」派って、「DIV直下にインラインは入らない」派の人？

826 ：Name_Not_Found：2006/10/15(日) 10:19:51 ID:???

827 ：Name_Not_Found：2006/10/15(日) 10:43:12 ID:???

addressかul

828 ：Name_Not_Found：2006/10/15(日) 12:27:48 ID:???

829 ：Name_Not_Found：2006/10/15(日) 19:10:33 ID:???

>>823
鸚鵡返しって、イニシアチブを取りたい人が思わずやってしまうらしいよｗ
俺はさも余裕ってアピールする行為って感じ？

830 ：Name_Not_Found：2006/10/16(月) 11:37:02 ID:???

ストリクタ御用達
http://ameblo.jp/tagkouza/

831 ：Name_Not_Found：2006/10/16(月) 12:01:26 ID:???

自演乙

見るまでもなく間違いだらけで使えなそうだｗ

832 ：Name_Not_Found：2006/10/16(月) 13:02:28 ID:???

なんかXHTMLっぽいのでブログとか作ってる人ってけっこー全てのタグに id とか class とかつけてたりしてちょっと気持ち悪いよね(´･ω･｀)

833 ：Name_Not_Found：2006/10/16(月) 13:21:02 ID:???

それはスクリプト側で処理しやすいようにじゃないの？

834 ：Name_Not_Found：2006/10/16(月) 13:43:16 ID:???

Strictとは直接関係ないし、生理的にどうこうというネタでもないな。
データを再利用しやすくなる。ただし転送量が増える。それだけのこと。

835 ：Name_Not_Found：2006/10/16(月) 14:11:49 ID:???

「再利用しやすくなる」かどうかは分からないというか、場合による。
それ以前に、まずは、文書作者が利用しようとする意志があるのだろう。それだけのこと。

836 ：Name_Not_Found：2006/10/16(月) 14:49:03 ID:???

>>834はサイト制作者が再利用しやすいようにidやclassを振ってるんだろうって言ってるんじゃないの？

837 ：Name_Not_Found：2006/10/16(月) 22:33:54 ID:I1Rtr86B

「HTML の神髄を追求する」なんて言いながら
パラグラフが成立していない文章を書いてる奴は白痴。
つまりばげらのことなんだが、他のW3C信者にもあてはまる。

W3CのHTMLチェッカのバナー貼りつけていながら
全く構造的でない文章を書いている奴も馬鹿丸出しで痛すぎる。

なんとなく意味のまとまりで区切ってるだけで
パラグラフという概念がそもそもないんだろうな
そんな白痴がStrict-HTMLと宣っているこのくそったれな現状

838 ：Name_Not_Found：2006/10/16(月) 22:55:00 ID:???

何か嫌な事でもあったの？

839 ：Name_Not_Found：2006/10/16(月) 23:08:11 ID:???

あのステッカー貼ってる時点でstrict的にはおかしいわなぁ。
その画像がないと成り立たない文書なら貼るべきかもしれないがねぇ。ステッカー貼らないと成り立たない文書ってナンダそりゃ？！って話しだねぇ。
まあウザいこたウザいやねぇ。

840 ：Name_Not_Found：2006/10/16(月) 23:08:15 ID:I1Rtr86B

いやいや、Strict-HTMLを書くためにはパラグラフの概念が不可欠だと言いたかっただけ。

841 ：Name_Not_Found：2006/10/16(月) 23:19:16 ID:???

>>839
「作成環境」のとこに「XHTML1.0」とかって書いてて、CSS の background で画像指定してたりするのはおｋですか？

842 ：Name_Not_Found：2006/10/16(月) 23:29:51 ID:???

>>841
重箱で悪いが、作成環境ではないよ。

843 ：Name_Not_Found：2006/10/16(月) 23:35:23 ID:???

>>840
論文の類なら確かにその通りです。
ただ、小説やそれに近い文章では「パラグラフ」の概念自体が
存在しない（事もある）のですが、どうしたら良いのでしょう。

844 ：Name_Not_Found：2006/10/17(火) 00:18:26 ID:???

本当にそう思うなら全部preだ！

845 ：Name_Not_Found：2006/10/17(火) 00:33:05 ID:QyF7ITTf

>>843
Strictを貫くつもりなら、パラグラフの存在しない小説やエッセイの類はHTML文書にすべきではないwww

現実的には、いわゆる段落をパラグラフとみなしてマークアップするしかないでしょうが。

むしろ問題なのは戯曲や詩の類ですな。
Wikisourceではdl要素などを使っているようだが…
http://en.wikisource.org/wiki/The_Tragedy_of_Macbeth

846 ：Name_Not_Found：2006/10/17(火) 15:29:54 ID:???

つかね。
strict狂信者の基準に合わせろって方が現実的にありえないんですがｗ

strictの一般的な基準値と、狂信者の基準値は大きな乖離があるのに、
それを考慮に入れず他人に自分の価値観を押し付けるような事をするから、
ストリクタは嫌われるんだよ。

いい迷惑。

847 ：Name_Not_Found：2006/10/17(火) 15:41:02 ID:???

> パラグラフの存在しない小説やエッセイの類はHTML文書にすべきではない

えええええ。

848 ：Name_Not_Found：2006/10/17(火) 17:52:00 ID:???

>>846
strict狂信者の基準に合わせろなんて誰が誰に言ったんだ？

849 ：Name_Not_Found：2006/10/17(火) 18:33:27 ID:???

>パラグラフという概念がそもそもないんだろうな

W3CのHTMLチェッカのバナー相手にここまで要求してる時点でダメじゃね？

850 ：Name_Not_Found：2006/10/17(火) 18:55:41 ID:QyF7ITTf

チェッカではなく書き手の問題のつもりだったんですがね

851 ：Name_Not_Found：2006/10/17(火) 19:14:42 ID:???

同じっしょｗ
チェッカを通ったらOKレベルのやつにそこまで求めるのがおかしい

ここで要求されるようなレベルよりちょっと下までを考えてるのだとしても、
もっと厳密な審査ｗをしないといけないしな
そこまでやる訳が無いし、現実的に考えて不可能

852 ：Name_Not_Found：2006/10/17(火) 19:34:42 ID:???

特攻野郎Ａチームならやってくれる

853 ：Name_Not_Found：2006/10/17(火) 19:39:03 ID:???

>>851
なにそのアバウト認識

854 ：Name_Not_Found：2006/10/17(火) 19:47:12 ID:???

チェッカを通ったらOKレベルのやつにそこまで求めるのがおかしい

ことを求める>>851さん。

855 ：Name_Not_Found：2006/10/17(火) 19:57:00 ID:???

誰もまとめないのなら、テンプレ作るべ。

Lv.1) W3CやAHLのチェック100点
Lv.2) div, spanは必要最低限
Lv.3) paragraph != (日本語で言う形式)段落としてp要素を扱う
Lv.4) ...
...
Lv.100) TBL を超えたネ申の領域

てな感じでどんどん追加してって

856 ：Name_Not_Found：2006/10/17(火) 20:47:18 ID:???

>>854
日本語でおｋ

857 ：Name_Not_Found：2006/10/17(火) 20:50:10 ID:???

・div, spanは他にどうしようも無い時以外に使ってはいけない。
　というか、使ったら負けだと思っている。

このスレだと、これぐらいの要求してくるよなｗ

858 ：Name_Not_Found：2006/10/17(火) 21:01:04 ID:???

>>856
>>857
連投乙

859 ：Name_Not_Found：2006/10/17(火) 21:08:42 ID:???

>>858
>>854乙

860 ：Name_Not_Found：2006/10/17(火) 21:16:39 ID:???

>>859
妄想乙ｗ

861 ：Name_Not_Found：2006/10/17(火) 21:18:48 ID:???

>>857
まあそういう人は多いだろーね。上のレスとか読んでてもそう感じる。

P厨乙。

862 ：Name_Not_Found：2006/10/17(火) 21:23:28 ID:???

>>858
妄想乙ｗ

863 ：Name_Not_Found：2006/10/17(火) 21:24:07 ID:???

そして無限ループ

864 ：Name_Not_Found：2006/10/18(水) 00:54:08 ID:???

完璧に完璧を極めようとしたら、文章の方を合わせていくしかない
けれどそれだと実用的ではない→XMLでやれ
でもXMLでもレンダリングでどーせXSL変換する
（しなくてもいいけど、一般的にみればもっと実用的じゃなくなる）
体裁ばかり拘って意味解釈無視するならPDFとかにしちまえというなら同意だけれど、
意味的にみてあからさまにおかしくない解釈、用法はあるていど認められていいと思う

865 ：Name_Not_Found：2006/10/18(水) 01:13:50 ID:???

>>864
> 完璧に完璧を極めようとしたら、文章の方を合わせていくしかない
パラグラフ云々はdivやspanを使えばOK。
divの乱用を嫌うあまりに、divを使わずに済む理屈を考え出そうと
するからおかしなことになるだけで、使えばいいのよ、divを。

divを使わんでいいところに使わない、というのは当然だけど、
divを使えばいいのに「文章を変えよう」となるのは立派なdiv厨だな。

866 ：Name_Not_Found：2006/10/18(水) 03:50:31 ID:???

まだあきらめないのか低能。

867 ：Name_Not_Found：2006/10/18(水) 04:46:43 ID:???

divから卒業しようぜ

868 ：Name_Not_Found：2006/10/18(水) 05:35:35 ID:???

おまえはまず入学しろ。

869 ：Name_Not_Found：2006/10/18(水) 13:32:22 ID:???

ｱﾝﾁDIV厨UZEEEEEEEE

こうですか？わかりません

870 ：Name_Not_Found：2006/10/18(水) 18:32:50 ID:???

アンチDiv厨は普通にうざくね？

871 ：Name_Not_Found：2006/10/18(水) 19:33:32 ID:???

div寄生虫うざす

872 ：Name_Not_Found：2006/10/18(水) 20:22:17 ID:???

○○厨と言うときは、それの信者とアンチをセットで厨として
扱ってることになるらしいよ。

873 ：Name_Not_Found：2006/10/18(水) 21:22:55 ID:???

そうですか

874 ：Name_Not_Found：2006/10/18(水) 21:24:11 ID:???

また、div中毒者が暴れてるのか

875 ：Name_Not_Found：2006/10/18(水) 23:34:15 ID:???

アンチdiv厨っていうと、なぜかdivをちょっとでも使う人
全部を批判するようなレスがくるよな

876 ：Name_Not_Found：2006/10/19(木) 00:00:56 ID:???

>>875
だって低能なんですもの

877 ：Name_Not_Found：2006/10/19(木) 00:48:23 ID:???

じゃー P厨って言えばいいんじゃね？じゃね？

878 ：Name_Not_Found：2006/10/19(木) 19:35:30 ID:???

人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。
人の脳を読む能力を悪用する奴を潰せ。

879 ：Name_Not_Found：2006/10/19(木) 20:18:42 ID:???

>>878
きめぇｗ

880 ：Name_Not_Found：2006/10/22(日) 04:04:34 ID:???

>>878の凄い念力でスレが止まった

881 ：Name_Not_Found：2006/10/22(日) 04:05:57 ID:???

例のキモイコテの発言だからな。
それぐらいの破壊力はある。

882 ：Name_Not_Found：2006/10/22(日) 04:12:56 ID:???

人の脳を読む能力を悪用する奴を潰せの検索結果約 2,380 件

883 ：Name_Not_Found：2006/10/22(日) 04:44:52 ID:???

サイコパスか

884 ：Name_Not_Found：2006/10/22(日) 12:18:46 ID:???

Kingだろ

885 ：Name_Not_Found：2006/10/23(月) 13:11:02 ID:???

今までStrictで書いてたんだけど、
自動で挿入される広告バナーが全然Strictじゃないことにさっき気づいた。
泣く泣く全頁をTransitionalに書き換えた。

886 ：Name_Not_Found：2006/10/23(月) 13:18:37 ID:???

>>885
それは見なかった事に城

887 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 17:46:28 ID:sMd94OyH

talk:>>878,>>882 人の脳を読む能力を悪用する奴を潰せ。
talk:>>884 私を呼んでないか？

XHTML 1.1 などでは <a href="a"><span><a href="b">c</a></span></a>のような書き方ができそうですが、
XHTML 1.1 などでは a要素のどの階層の子要素にもa要素を入れられないという規則はありますか？
また、 html 要素を一つだけ必ず入れる必要があるという決まりはありますか？

888 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 17:49:46 ID:sMd94OyH

talk:>>885 body部の先頭または末尾にdiv要素を使ってその中にobjectかimgでgif画像等で埋め込めばいいのだが、SSIをどうするかはサーバー管理者が決めることなんだよな。

889 ：Name_Not_Found：2006/10/25(水) 18:13:16 ID:???

お前はたいした知識もないのにでしゃばるな。
つか、うざいから消えろ。

890 ：Name_Not_Found：2006/10/25(水) 18:26:58 ID:???

infoseekは</HTML>の“後”に広告を挿入する。
しかも終了タグがあるのに開始タグがなかったりする。
酷すぎ。

891 ：Name_Not_Found：2006/10/25(水) 18:31:26 ID:???

</html>の後でも広告表示されるの？

892 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 18:34:21 ID:sMd94OyH

広告の表示自体は消すことも可能だが、問題なのは広告が表示されることではない。
talk:>>889 何考えてんだよ？

893 ：Name_Not_Found：2006/10/25(水) 18:37:09 ID:???

>>892
問題はわかっとるがな。Strictスレだもの。

894 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 18:46:51 ID:sMd94OyH

再掲。
XHTML 1.1 などでは <a href="a"><span><a href="b">c</a></span></a>のような書き方ができそうですが、
XHTML 1.1 などでは a要素のどの階層の子要素にもa要素を入れられないという規則はありますか？
また、 html 要素を一つだけ必ず入れる必要があるという決まりはありますか？

895 ：Name_Not_Found：2006/10/25(水) 19:09:26 ID:???

規則があるかどうかなんて仕様書読めば解るでしょ。

896 ：Name_Not_Found：2006/10/25(水) 19:15:01 ID:???

>>890
Stricterなあなたに、広告非表示オプションがあります。
もしかしたら、このためにわざとひどいコードだったりしてね。

897 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 19:33:48 ID:sMd94OyH

talk:>>684 どういう点においてperfectなのか？
talk:>>895 しかし、XHTML でもa要素のどの階層の子要素にもa要素を入れられないというような説明があるサイトがある。

898 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 19:39:55 ID:sMd94OyH

ttp://www.kanzaki.com/docs/html/read-dtd.html#note-excep

899 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 19:45:13 ID:sMd94OyH

そのサイトでは、「a要素タイプは結構複雑な内容モデルとして示されています。」と書いてあるだけのようだ。

900 ：Name_Not_Found：2006/10/25(水) 19:51:15 ID:???

A要素なんかなくなるんだぜ？おまえナニ言ってんだぜ？

901 ：Name_Not_Found：2006/10/25(水) 20:06:20 ID:???

Modularization of XHTML™の内容モデルだと
(PCDATA | Inline - a)*
となっている。

902 ：Name_Not_Found：2006/10/25(水) 20:22:13 ID:???

DTD上はa要素の入れ子はできるだろ

してはいけないのとできるのとは別

903 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 20:34:17 ID:sMd94OyH

talk:>>901 それでも、<a href="a"><span><a href="b">c</a></span></a>のようにはできるのではないか？

904 ：Name_Not_Found：2006/10/25(水) 20:39:26 ID:???

それが必要な具体例がまったく想像できない。

905 ：Name_Not_Found：2006/10/25(水) 20:49:12 ID:???

フィッシングとか

906 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 21:41:33 ID:sMd94OyH

talk:>>904 [>>901]に対しては、XHTML 1.1 のDTDではそのような記述ではないと答えるべきだったか。

907 ：Name_Not_Found：2006/10/25(水) 22:18:34 ID:???

痛い素人がいるなｗ

908 ：KingOfUniverse ◆667la1PjK2 ：2006/10/25(水) 23:35:47 ID:sMd94OyH

html要素が無い文書もXHTML 1.1 等のDTDには違反していない？

909 ：Name_Not_Found：2006/10/25(水) 23:43:54 ID:???

自分一人で調べればわかることをなぜ掲示板で問う？
機械的なインターフェースでない人間相手に二人分のカロリーを消費して誰が得をする？

910 ：Name_Not_Found：2006/10/26(木) 00:43:07 ID:???

してはいけないのとできるのとは別

うざいから初心者スレいけ

911 ：Name_Not_Found：2006/10/26(木) 03:53:30 ID:???

DTDで書けるからといってHTMLとして正しいとは限らないよ。
例えば、
The THEAD, TFOOT, and TBODY sections must contain the same number of columns.
とか、
Anchor names must be unique within a document.
とか。

912 ：Name_Not_Found：2006/10/26(木) 04:29:17 ID:???

相手すると居付くから放置汁。

913 ：KingOfUniverse ◆667la1PjK2 ：2006/10/26(木) 07:00:47 ID:Fw2H6e4E

talk:>>909 無いことを調べるにはどうすればよいのか？

914 ：Name_Not_Found：2006/10/26(木) 14:36:30 ID:???

そりゃ、仕様に存在しないなら仕様違反ってだけだろ。
いい加減うざいからどっか池。

915 ：KingOfUniverse ◆667la1PjK2 ：2006/10/26(木) 17:37:41 ID:Fw2H6e4E

それではxml宣言とDOCTYPE宣言だけを書いてXHTML 文書だと主張してもDTDには違反せず、
内容モデル、属性、属性値が正しい要素を html 要素を書くことなく書いても、
<a href="a"><span><a href="b">c</a></span></a>としても、DTDには違反しないということでいいのだな？
私が調べた限りではそうだった。

とにかく、XML の DTD は XHTML には合わないということでいいのだな？

916 ：Name_Not_Found：2006/10/26(木) 18:10:07 ID:???

しつこい

917 ：Name_Not_Found：2006/10/26(木) 18:18:43 ID:???

>>915
a要素の件は、XHTML 1.0がHTML 4.0(4.01?)のXMLベースの再構築版で、そっちの仕様書だかDTDだかで確か禁止だから多分禁止じゃなかったっけ？
そもそも、何故aを二重化するのにこだわるの？正当な「Valid XHTML」マーク付きのフィッシングサイトが作りたいなら分かるけど。
あと、合わないも何も、XHTMLはXMLベースだからXML DTDで定義するでしょう。
それにDTDに違反しないのを目的にXHTMLを使っているの？少なくとも自分は違う。大体DTDだけを取り上げるならdiv中毒もblockquoteのインデントもOKだろうし。
もしそれらが可能だとしても自分ならしないし、絶対正当な書き方で書いておけばいいんじゃない？
html要素省略するメリットも思い付かないし。
どうしても疑問ならW3Cの人にメールした方が「確実」な答えが返ってくると思うよ。きっとこのスレにHTML/XML/XHTMLの仕様策定に関わった人いないし。
それを踏まえて、現状に不満ならXML DTDの仕様変更の要望書を出したらいい。

要するに、
続きはW3CのMLでしたら？

他の人、長々とごめんね。

918 ：Name_Not_Found：2006/10/26(木) 18:38:19 ID:???

>>915
＞xml宣言とDOCTYPE宣言だけを書いてXHTML 文書だと主張してもDTDには違反せず
＞内容モデル、属性、属性値が正しい要素を html 要素を書くことなく書いても、
仕様書には"The root element of the document must be <html>."とあるが、
DTDには書いていないから確かに「DTDには違反しない」。

＞<a href="a"><span><a href="b">c</a></span></a>としても、DTDには違反しない
<!ENTITY % a.content
"( #PCDATA | %InlNoAnchor.mix; )*"
>

＞XML の DTD
そんなもの無い。

919 ：Name_Not_Found：2006/10/26(木) 18:49:07 ID:???

Extensible Markup Language (XML) 1.0 (Fourth Edition)
2.8 Prolog and Document Type Declaration

Validity constraint: Root Element Type
The Name in the document type declaration MUST match the element type of the root element.

920 ：Name_Not_Found：2006/10/26(木) 18:51:25 ID:xlVJb77r

inputでラジオボタン30個ぐらい並べてるんだけど
tabindexナンバー全部割り振らないといけないのでしょうか？

921 ：Name_Not_Found：2006/10/26(木) 18:58:54 ID:???

>>920
うん。
つか、根本的に

922 ：920：2006/10/26(木) 19:39:47 ID:xlVJb77r

先程割り振ったんですけど
タブ打っても順番にいかないのだけど。
ただの記述ミスなんですかね。

923 ：Name_Not_Found：2006/10/26(木) 20:30:03 ID:???

>>922
うん。たぶん。
でも、仕様と実装が違う事も多々あるし。
つか、根本的に

924 ：KingOfUniverse ◆667la1PjK2 ：2006/10/26(木) 20:55:54 ID:Fw2H6e4E

talk:>>918 それでは、%InlNoAnchor.mix; が何を参照しているか調べてみろ。XMLで認められるDTD.
talk:>>919 XMLの説明の方に、 XHTML 文書は必ず一つだけの html 要素を含まないといけないことがあるのか。

さて、残りはアンカー関係だ。

925 ：Name_Not_Found：2006/10/26(木) 21:15:04 ID:???

>>924
ここは『Valid』HTMLスレじゃなくて、『Strict』HTMLスレのような気がするんだけど、違うかな？

926 ：Name_Not_Found：2006/10/26(木) 21:39:36 ID:???

ttp://www.google.com/search?q=KingOfUniverse+%E2%97%86667la1PjK2

927 ：Name_Not_Found：2006/10/26(木) 22:19:39 ID:???

HTML4.01 では DTD Invalid な文書でも XHTML1.0 では DTD Valid になったり、
その逆になったりすることがあるというのは、何スレか前にも話題になった事。

<a href="a"><span><a href="b">c</a></span></a>
はHTMLではInvalidだが、XHTMLではValid。
逆に、
<ul><ins>a</ins><li>b</li></ul>
はHTMLではValidだが、XHTMLではInvalid。

添加要素と排除要素の問題だが、そもそもどちらもわざわざそんな書き方を
する必要がない。

928 ：918：2006/10/26(木) 22:26:16 ID:???

>>924
<!ENTITY % InlNoAnchor.mix
"%InlNoAnchor.class;
%Misc.class;"
>
再帰的に調べればよいので以下省略。
で、「XMLのDTD」ってどのファイル？「XMLで認められるDTD」ってどういうこと？

929 ：Name_Not_Found：2006/10/26(木) 23:25:31 ID:???

>>928
a要素の内容モデルは ( #PCDATA | %InlNoAnchor.mix; )* だから、
a要素を子要素とすることは出来ないが、
span要素は ( #PCDATA | %Inline.mix; )* だからa要素を子と出来る。

従って、
<a href="a"><a href="b">c</a></a>
は DTD InValid だが、
<a href="a"><span><a href="b">c</a><span></a>
とspan要素を噛ませば DTD Valid になる。

SGMLではDTDで「子孫すべてから排除する」という書き方が出来るが、
XMLではDTDは子しか指定してはならないからな。…って話だろ。

930 ：Name_Not_Found：2006/10/26(木) 23:39:58 ID:???

>>920
タブインデックスはブラウザ依存だから、やらない方が良いよ

931 ：Name_Not_Found：2006/10/26(木) 23:42:23 ID:???

Strictな具体例を示さないとさ。
Aの中にA。そして回避ではなく意味のあるSPAN。
なんですか？どんな場合ですか？

932 ：918：2006/10/26(木) 23:48:05 ID:???

>>929
ありがとう。

<p>しかし、私は上記に加えて、
<object>
<ul>
<li>水筒</li>
<li>タオル</li>
<li>ちり紙</li>
<li>ビニールシート</li>
<li>ビニール袋</li>
<li>雨具</li>
</ul>
</object>
も、必需品ではないかと思うのだ。</p>

が良いかどうかと同じ話か。

933 ：Name_Not_Found：2006/10/27(金) 00:43:11 ID:???

構造や手法は同じっちゃ同じだが、ある要素の中に回避要素かませて同じ要素を含む、ってのは
よっぽどレベルが低いか奇抜で画期的なアイデアか、のどっちかに思えるが。

934 ：Name_Not_Found：2006/10/27(金) 01:06:45 ID:???

奇策っていうか、仕様をむりやり回避してるだけのダメマークアップじゃんｗ
ここはStrict-HTMLスレだぞ。

935 ：Name_Not_Found：2006/10/27(金) 02:15:51 ID:???

むりやり例を考えてみた。w

<a href="law"><em><a href="newton">ニュートン</a></em>の法則</a>

936 ：Name_Not_Found：2006/10/27(金) 07:20:26 ID:???

普通にどっちかでよくね？

937 ：KingOfUniverse ◆667la1PjK2 ：2006/10/27(金) 19:33:11 ID:zf55ymDX

talk:>>931 ハイパーリンクの中にさらにハイパーリンクを埋めてみようと思う人はやはり居ないか？

私が知りたいのは、XHTML の DTD で a要素のどの階層の子要素にもa要素を入れられないのかどうか、だ。
どっちつかずの説明をしているサイトがあったから議論をした。

938 ：Name_Not_Found：2006/10/27(金) 19:42:53 ID:???

DTD対応のXMLパーサにかけたらいいって問題ではないの？よく知らないけど。

939 ：Name_Not_Found：2006/10/27(金) 19:51:15 ID:???

>>937
いれられないよ。常識的に考えて

940 ：Name_Not_Found：2006/10/27(金) 20:58:10 ID:???

>>937
>>929

941 ：Name_Not_Found：2006/10/27(金) 22:24:08 ID:???

>>937
結論は出たんだからもう来なくていいよ。

942 ：Name_Not_Found：2006/10/28(土) 01:38:46 ID:???

>>937
まずa要素の入れ子が必要な事例を挙げてくれないか？
想定され得る事例があれば議論も成り立つと思うのだが。

943 ：Name_Not_Found：2006/10/28(土) 02:12:55 ID:???

>>939
「常識的に」の中身が「DTDに沿う/沿わない」なのか「Strict思想に沿う/沿わない」なのか。

>>942
同意。

944 ：Name_Not_Found：2006/10/28(土) 05:59:19 ID:???

DTDに合致すればValidだけど、
仕様はDTDの他に仕様書によっても規定されていて、
仕様でaの入れ子は禁止されている。

解釈の余地の範疇の問題のStrict思想云々とは別で、
議論の余地なく単純な仕様違反。

945 ：Name_Not_Found：2006/10/28(土) 11:07:01 ID:???

【まとめ】
HTMLでは、
・DTDで、a要素内は子々孫々に渡ってa要素を入れる事を禁止している。
・仕様書本文でも、a要素内にa要素を含む事を禁止と書いてある。

XHTMLでは、
・DTDでは、子のa要素は禁止しているが、孫以下なら禁止されていない。
・仕様書本文(XHTML1.0)には、「XMLの制約上DTDに書けなかったが
　孫以下にもa要素を入れるのは禁止」と書いてある。

Strict思想的には、
・一応、>>935 は構造的にはあり得るかな。ニュートンに関する話と、
　その法則に関する話は別の話だから別リンクなのはあり得るし。

結論……構造的にあり得て、DTDが許していても、仕様として禁止。

946 ：Name_Not_Found：2006/10/28(土) 12:03:58 ID:???

>Strict思想的には、
>・一応、>>935 は構造的にはあり得るかな。ニュートンに関する話と、
>　その法則に関する話は別の話だから別リンクなのはあり得るし。

ここは同意できん。

947 ：Name_Not_Found：2006/10/28(土) 13:53:10 ID:???

Strict-HTMLを語る前に日本語を勉強してこいよ・・・

948 ：Name_Not_Found：2006/10/28(土) 15:43:43 ID:???

仕様書に書いていることでスレ消費するなや

あほか

949 ：Name_Not_Found：2006/10/28(土) 19:22:06 ID:???

XHTML2.0だとネストしたアンカーは普通に使えるっぽな。

950 ：Name_Not_Found：2006/10/28(土) 19:38:45 ID:???

ストリクタはとうとう仕様書に明言してある事も超越するようになったのか？ｗ

951 ：Name_Not_Found：2006/10/28(土) 19:50:09 ID:???

>>949

うざい
仕様書嫁

952 ：Name_Not_Found：2006/10/29(日) 00:09:53 ID:???

HTML4.01 や XHTML1.0 では、a要素のネストは仕様書で禁止されているが、
XHTML1.1 では言及がない。XHTML2.0 ではまだ議論中のようだが「ユーザー
エージェントはネストされたリンクを扱えるメカニズムを提供すべき」と
書いてあるのでネスト出来ると思われる。

というわけで、XHTML1.1 でネスト出来るかどうかは仕様書に言及がない以上
微妙な所だな。

953 ：Name_Not_Found：2006/10/29(日) 06:26:33 ID:???

1.1なんてapplication/xhtml+xmlの時点でIEで見れない時点でまだまだ先の話じゃない。
そもそも対応する気もないらしいけど。

954 ：Name_Not_Found：2006/10/29(日) 10:01:49 ID:???

>>953
まじかよ……MIMEタイプの対応ってそんなに難しい実装なのか？

955 ：Name_Not_Found：2006/10/29(日) 10:42:22 ID:???

難しいじゃなくて、対応する気が無いらしい。
XMLにあまり出てきて欲しくないのかもな。

956 ：Name_Not_Found：2006/10/29(日) 10:49:14 ID:???

MS曰く、「ユーザが望んでいるのは標準仕様への対応ではなく、多くのページを表示することだ」らしいよ。

application/xhtml+xmlに対応すればより多くのページを表示することができると思うんだけどな。

957 ：Name_Not_Found：2006/10/29(日) 13:04:59 ID:???

>>955
マイクロソフトほどXMLを積極的に利用してきたベンダーは他に無い。
>>956
「表示」に限れば、初期のtext/xmlにそれらを加えても、実質的な意義が無い。
HEADリクエストで調べるとかなら、意義があるが……。
まず、text/xml; type=xhtml みたいな書式にしなかった事がおかしい。
そして、IE6が世に出るのを待っていたかのように、直後にRFCを出した事もおかしい。
マイクロソフトからすれば、まるで梯子を外されたようなものだろう。

958 ：Name_Not_Found：2006/10/29(日) 14:01:23 ID:???

自社OSのXML環境が整うまでXHTMLの放置プレイは続く

959 ：Name_Not_Found：2006/10/30(月) 03:05:31 ID:???

>>952
XHTML1.1はModularization of XHTMLベースで、Modularization of XHTMLには(PCDATA | Inline - a)*と書いてあるからXHTMl1.1でもネストできない。

960 ：Name_Not_Found：2006/10/30(月) 11:31:44 ID:???

>>959
いや、Modularization of XHTMLのDTDを見ても、a要素の孫要素にa要素が
書けるようになっている。

それに「Inline - a」の意味は4.1章に書いてあって、単にInlineからa要素を
除いた部分という意味しかない。SGMLでの「- a」（子々孫々から除く）
とは意味が違う。という訳で、子からは除かれるが孫からは除かれない。

961 ：Name_Not_Found：2006/10/30(月) 21:32:42 ID:???

なるほど、奥深いな。

962 ：Name_Not_Found：2006/10/30(月) 21:33:31 ID:???

>>957
ふと思ったんだが、「type="text/xml; type=xhtml"」って少しカッコ悪いな。
というか、みんなそんなにリンクをネストしたいのかよ、わざわざspanとか挟んで姑息な回避策つかってまで。

963 ：Name_Not_Found：2006/10/30(月) 22:58:37 ID:???

いまさらだけど

<P><A>ニュートン</A>の<A>万有引力の法則</A></P>

だろ。

<P><A>ニュートン力学</A>における<A>万有引力の法則</A>。</P>

とか。(大文字と属性省略はわざと)

964 ：Name_Not_Found：2006/10/31(火) 00:04:06 ID:???

>>963
別にニュートンの法則でなくても、オームの法則でもボイルの法則でも
何でもいいんだが…。そしたら、そういう自然な言い換えも出来ないよな。
もちろん、

<a href="newton"><em>ニュートン</em></a>の<a href="law"
title="ニュートンの法則">法則</a>

みたいな書き方もありえるが、>>935 もStrict的構造として変な訳では
ないかなぁと。あとは仕様が許すかどうかの問題だけで。

965 ：Name_Not_Found：2006/10/31(火) 00:39:22 ID:???

>>964
なるほどね。
考え方として有り得るか有り得ないかなら、有り得るね。
やるかやらないかなら、やらないね。
出来るか出来ないかなら、当分出来ないだろうね。
そんなこんなしてるうちにa要素もhref属性も無くなるもんね。

966 ：Name_Not_Found：2006/10/31(火) 06:04:56 ID:???

英文とかで、

I like:
・apple,
・orange, and
・strawberry.

とか書くことがあるけど、これはul? ol?
意味的には順番は関係ないけど、文としては

I like:
・orange, and
・strawberry.
・apple,

みたいに順番を変えてしまったらおかしくなってしまう。

967 ：Name_Not_Found：2006/10/31(火) 06:20:50 ID:???

<p>I like: apple, orange, and strawberry.</p>

968 ：Name_Not_Found：2006/10/31(火) 11:46:49 ID:???

I like:
・apple
・orange
・strawberry

969 ：Name_Not_Found：2006/10/31(火) 16:26:55 ID:???

>>966
英文で、そういう単語や短いフレーズを列挙する場合、重要なのは、最後のリストのピリオドだけ。
リスト化した時点で、カンマまたはカンマ + " and" の役割は消失するから、余分な塵になる。
また、LIでマーク付けしているから、UAにとっても、カンマまたはカンマ + " and" は不要である。
結局、閲覧者に対してもUAに対しても、この時点で、カンマまたはカンマ + " and" が不要である。

次に、ULかOLでマーク付けしているから、UAにとっては、ピリオドさえも不要になる。
しかし、英文としては、ピリオドを書くのが普通である。

つまり、閲覧者に対してピリオドが必要であるならば、装飾として提供した方が良いのではないだろうか。

余談だが、そういう単語や短いフレーズを列挙する場合、実は、コロンを書かない方が好ましい。
センテンスや長いフレーズを列挙をする時に、各リスト文末にセミコロンを使う事があるが、そういう場合にこそコロンを使う。
個人的には、C言語のswitch文内に見られる、
case '0':
i++;
break;
のような、文を列挙する形式に見られる、コロンとセミコロンの使い方が、いかにも英語的だと思っている。

970 ：Name_Not_Found：2006/10/31(火) 18:33:49 ID:???

>>967だな。

971 ：Name_Not_Found：2006/11/01(水) 20:13:33 ID:???

「ulは入れ替えても意味が通るようなものに使う」というのは
言い方はわかりやすいものの若干ミスリーディングだと思う

ordered/unordered は形式的順序のことを指しているのではなくて、
リスト要素の内容の意味的な順序と理解した方がいいと個人的には思っている

>>966 の上の例は許容範囲としたい

972 ：Name_Not_Found：2006/11/05(日) 01:18:03 ID:???

【うざい】Strict 39【仕様書嫁】

973 ：Name_Not_Found：2006/11/05(日) 05:02:52 ID:???

>>967だな。

974 ：Name_Not_Found：2006/11/05(日) 06:20:08 ID:???

質問スレで以下の質問をしましたところこちらに誘導をされましたので参りました
http://pc8.2ch.net/test/read.cgi/hp/1160534021/76
liやddは%blockには含まれてませんがblock-level要素として扱うべきなのか、というお話です

無論仕様書のそれにあたる部分とDTDは読んでおります
もしよろしければ御答えいただきたいのですがこちらでよろしいでしょうか

975 ：Name_Not_Found：2006/11/05(日) 08:40:01 ID:???

振りっぱなしでは申し訳ないので
とりあえずHTML3.2の仕様書にLIがblock-levelであると書いてあること、
及びその用途、性質からしてLIはblock-levelであると自分を納得させて向こうは完結いたしました

もし邪魔でなければこちらの皆様のご意見も聞いてみたくはありますが、
お邪魔でしたらこれにて失礼させていただきます

976 ：KingOfUniverse ◆667la1PjK2 ：2006/11/05(日) 11:27:41 ID:R2e0JDcq

MS社が、ユーザーが望んでいるのはより多くのページを表示することだとするのなら、
MS社は Internet Explorer の仕様書を提供するべきだ。

977 ：KingOfUniverse ◆667la1PjK2 ：2006/11/05(日) 11:30:41 ID:R2e0JDcq

Internet Explorer の仕様書があってもよくなる訳ではないだろうな。
HTML文書を書く人が、綺麗にマークアップした方がよい。

978 ：Name_Not_Found：2006/11/05(日) 12:41:50 ID:???

いや、blockでもinlineでもないんだろう。
だから、LIは、ULやOLの直下にしか出現できないし、
DDは、DLの直下にしか出現できない。

979 ：Name_Not_Found：2006/11/05(日) 13:41:16 ID:???

>>975
次は、COL要素がblockかinlineかと気になってくると予測。w

仕様書には、BODY内の要素は certain がblockで others がinlineとあるが、
"the others" とは書いてないから、必ずどちらかに分類されるという話には
ならないだろう。

980 ：Name_Not_Found：2006/11/05(日) 15:29:33 ID:oAQX0A6U

>>953
IEは無視しておｋ

981 ：Name_Not_Found：2006/11/05(日) 15:29:42 ID:???

>>979
なるほど！ものすごく納得出来ました！
ということは%blockがblock-levelで%inlineがinlineとする3.3.2と7.5.3はそもそも矛盾していなかったということなのですね
英語力の無さを露呈してお恥ずかしい

これでやっと明日から安らかに眠れそうです
大変ありがとうございました

982 ：Name_Not_Found：2006/11/05(日) 15:37:37 ID:???

%block=ブロックレベルエレメント
なのか？
イコールなのか？

983 ：Name_Not_Found：2006/11/05(日) 18:37:58 ID:???

次スレ
http://pc8.2ch.net/test/read.cgi/hp/1162719363/

984 ：Name_Not_Found：2006/11/05(日) 19:24:11 ID:???

address要素を１ページに２個以上含めるのって別に問題ないですよね？

985 ：Name_Not_Found：2006/11/05(日) 21:08:42 ID:???

>>984
必要なら問題無いけど

986 ：Name_Not_Found：2006/11/05(日) 21:26:12 ID:???

>982
You will encounter two DTD entities frequently in the HTML DTD: "%block;" "%inline;".
They are used when the content model includes block-level and inline elements, respectively
(defined in the section on the global structure of an HTML document).
とあるからイコールでいいんじゃないの？

987 ：Name_Not_Found：2006/11/05(日) 22:27:35 ID:???

>>986
てあるからイコールじゃなくなくなくないなくない？

988 ：Name_Not_Found：2006/11/05(日) 23:11:56 ID:???

うん、そうだよ

989 ：Name_Not_Found：2006/11/05(日) 23:13:57 ID:???

どっちだよｗ

990 ：Name_Not_Found：2006/11/06(月) 08:42:48 ID:???

もうイコールでいいんじゃない？

991 ：Name_Not_Found：2006/11/06(月) 22:17:39 ID:???

そんないいかげんな

992 ：Name_Not_Found：2006/11/07(火) 01:07:12 ID:???

じゃあ、俺がイコールじゃないって事に決定した。

993 ：Name_Not_Found：2006/11/07(火) 02:25:20 ID:???

多数のサイレントマジョリティを考慮して「イコール」に決定させてもらいます。あたりまえの話だよね。

994 ：Name_Not_Found：2006/11/07(火) 05:01:22 ID:???

石田衣良乙