Strict-HTML スレッド22
Strict な HTML について語るスレッド 22回目
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 スレッド21
http://pc5.2ch.net/test/read.cgi/hp/1090216329/
過去ログ・関連スレ >>2
勧告等・その他 >>3
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 スレッド21
http://pc5.2ch.net/test/read.cgi/hp/1090216329/
過去ログ・関連スレ >>2
勧告等・その他 >>3
|
|
|
2 ：Name_Not_Found：04/08/09 21:15 ID:???
■過去ログ
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc5.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc5.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc5.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc5.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc5.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc5.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/ (pc2サーバが消えたせいで消滅？)
Strict-HTML スレッド18 http://pc5.2ch.net/test/read.cgi/hp/1076693129/
Strict-HTML スレッド19 http://pc5.2ch.net/test/read.cgi/hp/1086000635/
Strict-HTML スレッド20 http://pc5.2ch.net/test/read.cgi/hp/1087826844/
Strict-HTML スレッド21 http://pc5.2ch.net/test/read.cgi/hp/1090216329/
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc5.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc5.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc5.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc5.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc5.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc5.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/ (pc2サーバが消えたせいで消滅？)
Strict-HTML スレッド18 http://pc5.2ch.net/test/read.cgi/hp/1076693129/
Strict-HTML スレッド19 http://pc5.2ch.net/test/read.cgi/hp/1086000635/
Strict-HTML スレッド20 http://pc5.2ch.net/test/read.cgi/hp/1087826844/
Strict-HTML スレッド21 http://pc5.2ch.net/test/read.cgi/hp/1090216329/
3 ：Name_Not_Found：04/08/09 21:15 ID:???
■関連スレ
/* CSS･スタイルシート質問スレッド【33】 */ http://pc5.2ch.net/test/read.cgi/hp/1089975931/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
ユーザビリティ専用スレ その２ http://pc5.2ch.net/test/read.cgi/hp/1020575673/
【野望の】XHTML 2.0【王国】 http://pc5.2ch.net/test/read.cgi/hp/1028659057/
XML使いのスレ 2.0 http://pc5.2ch.net/test/read.cgi/hp/1057198990/
XSL/XSLT http://pc5.2ch.net/test/read.cgi/php/999654569/
■勧告等
HTML 4.01 ttp://www.w3.org/TR/html401/
XHTML 1.0 ttp://www.w3.org/TR/xhtml1/
XHTML Basic ttp://www.w3.org/TR/xhtml-basic/
XHTML 1.1 ttp://www.w3.org/TR/xhtml11/
XHTML 2.0 W3C (Working Draft) ttp://www.w3.org/TR/2003/WD-xhtml2-20030506/
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/
■その他
W3C ttp://www.w3.org/
HTML Working Group Roadmap ttp://www.w3.org/MarkUp/xhtml-roadmap/
Another HTML-lint ttp://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service ttp://validator.w3.org/
ごく簡単なHTMLの説明 ttp://kanzaki.com/docs/htminfo.html
/* CSS･スタイルシート質問スレッド【33】 */ http://pc5.2ch.net/test/read.cgi/hp/1089975931/
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
ユーザビリティ専用スレ その２ http://pc5.2ch.net/test/read.cgi/hp/1020575673/
【野望の】XHTML 2.0【王国】 http://pc5.2ch.net/test/read.cgi/hp/1028659057/
XML使いのスレ 2.0 http://pc5.2ch.net/test/read.cgi/hp/1057198990/
XSL/XSLT http://pc5.2ch.net/test/read.cgi/php/999654569/
■勧告等
HTML 4.01 ttp://www.w3.org/TR/html401/
XHTML 1.0 ttp://www.w3.org/TR/xhtml1/
XHTML Basic ttp://www.w3.org/TR/xhtml-basic/
XHTML 1.1 ttp://www.w3.org/TR/xhtml11/
XHTML 2.0 W3C (Working Draft) ttp://www.w3.org/TR/2003/WD-xhtml2-20030506/
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/
■その他
W3C ttp://www.w3.org/
HTML Working Group Roadmap ttp://www.w3.org/MarkUp/xhtml-roadmap/
Another HTML-lint ttp://openlab.ring.gr.jp/k16/htmllint/htmllint.html
W3C HTML Validation Service ttp://validator.w3.org/
ごく簡単なHTMLの説明 ttp://kanzaki.com/docs/htminfo.html
4 ：Name_Not_Found：04/08/09 21:17 ID:???
酸素
5 ：Name_Not_Found：04/08/09 22:12 ID:???
Strict-HTML はメタル
6 ：Name_Not_Found：04/08/09 22:14 ID:???
7 ：Name_Not_Found：04/08/10 00:39 ID:???
法律施行
・URIがコロコロかわるサイトは死刑
・文法守れてないサイトは死刑
・フォントサイズ固定、幅固定しているサイトは死刑
・W3Cに足を向けて寝る奴死刑
・ティムで抜いたことのない奴死刑
・バーナーやバナーと聞いたらティムを思い出さない奴、二日間食事抜き
・URIがコロコロかわるサイトは死刑
・文法守れてないサイトは死刑
・フォントサイズ固定、幅固定しているサイトは死刑
・W3Cに足を向けて寝る奴死刑
・ティムで抜いたことのない奴死刑
・バーナーやバナーと聞いたらティムを思い出さない奴、二日間食事抜き
8 ：Name_Not_Found：04/08/10 00:54 ID:???
>>7
ごめんなさい
ごめんなさい
9 ：Name_Not_Found：04/08/10 02:19 ID:???
>>7
ごめんなさい
ごめんなさい
10 ：Name_Not_Found：04/08/10 07:32 ID:???
>>7
ごめんなさい
ごめんなさい
11 ：Name_Not_Found：04/08/10 08:24 ID:???
Another HTML-lint
ローカルで動かしたくて、
解説サイトいろいろ見たけど出来ないです。
ローカルで動かしたくて、
解説サイトいろいろ見たけど出来ないです。
12 ：Name_Not_Found：04/08/10 09:10 ID:???
じゃやめろ
お前には無理
お前には無理
13 ：Name_Not_Found：04/08/10 09:59 ID:???
解説サイト見てできないんだったらここで説明されても理解できんよ
14 ：Name_Not_Found：04/08/10 10:19 ID:???
なぜか
指定されたファイル を取得することができませんでした。
って出ちゃうんです。
指定されたファイル を取得することができませんでした。
って出ちゃうんです。
15 ：Name_Not_Found：04/08/10 10:21 ID:???
どっか設定が間違ってるだけ
16 ：Name_Not_Found：04/08/10 10:26 ID:???
「なぜか」ってのはほとんどの場合お前が原因。
どっちにしろ板違いだからPC初心者板でも行きなさい。
どっちにしろ板違いだからPC初心者板でも行きなさい。
17 ：Name_Not_Found：04/08/10 10:44 ID:???
ごめんなさい。
18 ：Name_Not_Found：04/08/10 10:46 ID:???
警察は要らない
19 ：Name_Not_Found：04/08/10 10:56 ID:???
で済んだら
20 ：Name_Not_Found：04/08/10 10:57 ID:???
21 ：Name_Not_Found：04/08/10 11:25 ID:???
漢文風マークアップｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!
22 ：Name_Not_Found：04/08/10 12:18 ID:???
レ点はやっぱ<sup>（or <sub>）なんかでマークアップするんですかね。
23 ：Name_Not_Found：04/08/10 12:21 ID:???
W3C信者に怒られそうなことを書くスレ
http://pc5.2ch.net/test/read.cgi/hp/1071673655/l50
↑
ここからマジレスが生まれたようなので誘導リンクを張りました。
ので、質問が来るかもしれません。
http://pc5.2ch.net/test/read.cgi/hp/1071673655/l50
↑
ここからマジレスが生まれたようなので誘導リンクを張りました。
ので、質問が来るかもしれません。
24 ：Name_Not_Found：04/08/10 12:48 ID:???
なんで誘導するんだよ。あそこのスレはW3C信者を装ったバカとアンチ信者を装ったバカのネタスレだろ
こっちへきても自演が増えるだけじゃないのか
こっちへきても自演が増えるだけじゃないのか
25 ：Name_Not_Found：04/08/10 13:27 ID:???
荒らしにはとにかくスルーすること
26 ：Name_Not_Found：04/08/10 13:33 ID:???
27 ：Name_Not_Found：04/08/10 14:45 ID:???
マジレスお願いします。
テーブルレイアウトがいけないのはなぜですか？
あくまでも技術的な好奇心からです。
マジレスお待ちしています。
荒らすつもりはありません。
テーブルレイアウトがいけないのはなぜですか？
あくまでも技術的な好奇心からです。
マジレスお待ちしています。
荒らすつもりはありません。
28 ：Name_Not_Found：04/08/10 14:48 ID:???
表と思って見てみたら表じゃなかった、じゃ不便だから
29 ：Name_Not_Found：04/08/10 15:04 ID:???
>>27
・仕様に沿って使ってもらった方がHTMLを解釈しやすい
・レイアウトについてはCSSで代替可能である
ことから、「テーブルレイアウトをする必要はない」って話かな。
むしろなぜテーブルレイアウトじゃなきゃいけないの？と聞きたいかも。
・仕様に沿って使ってもらった方がHTMLを解釈しやすい
・レイアウトについてはCSSで代替可能である
ことから、「テーブルレイアウトをする必要はない」って話かな。
むしろなぜテーブルレイアウトじゃなきゃいけないの？と聞きたいかも。
30 ：Name_Not_Found：04/08/10 15:16 ID:???
31 ：Name_Not_Found：04/08/10 16:04 ID:???
>>27
別に潔癖症で言ってるわけじゃないんだよ。
仕様の通りにしてれば再利用しやすいとかいろいろあるけど、
自分がやろうと思わない理由を挙げるなら、
>>29-30にもあるようにそもそもテーブルでやるメリットが無いっていうのが一番大きい。
逆にデメリットはいろいろある。
表示が遅いとか、編集するときわけが分からなくなるとか。
fontたぐとかをやめて論理マークアップにしたら編集が楽だっていうのは知ってる？
勿論ケースバイケースだとか程度にもよるとか、そういうのはあるけど。
Strictでせっかくシンプルになってるところにわざわざ複雑なテーブルレイアウトを入れるのは
馬鹿馬鹿しいっていうのがある。
デザインを壊したくないっていうのもある。
レイアウトだけテーブルでやって残りをCSSでやると、CSSだけ無効になる可能性があるでしょ。
逆もまた然り。
完全に無効になるのは仕方ない。
でも「少しでも自分のスタイルで」と欲張るとあっさり空中分解したりする。
それと、これはそう思わない人からすれば潔癖症なのかも知れないけど、
純粋な論理マークアップに適用できるようなスタイルシートはそれ自体がひとつの作品になる。
スタイルシートを80%くらいまで書いたら、普通あとの20%も書いて完成させようと思う。
テーブルでやるべき(？)部分も気づいた頃にはCSSで書いてる。
だからわざわざテーブルにするのは無意味。
別に潔癖症で言ってるわけじゃないんだよ。
仕様の通りにしてれば再利用しやすいとかいろいろあるけど、
自分がやろうと思わない理由を挙げるなら、
>>29-30にもあるようにそもそもテーブルでやるメリットが無いっていうのが一番大きい。
逆にデメリットはいろいろある。
表示が遅いとか、編集するときわけが分からなくなるとか。
fontたぐとかをやめて論理マークアップにしたら編集が楽だっていうのは知ってる？
勿論ケースバイケースだとか程度にもよるとか、そういうのはあるけど。
Strictでせっかくシンプルになってるところにわざわざ複雑なテーブルレイアウトを入れるのは
馬鹿馬鹿しいっていうのがある。
デザインを壊したくないっていうのもある。
レイアウトだけテーブルでやって残りをCSSでやると、CSSだけ無効になる可能性があるでしょ。
逆もまた然り。
完全に無効になるのは仕方ない。
でも「少しでも自分のスタイルで」と欲張るとあっさり空中分解したりする。
それと、これはそう思わない人からすれば潔癖症なのかも知れないけど、
純粋な論理マークアップに適用できるようなスタイルシートはそれ自体がひとつの作品になる。
スタイルシートを80%くらいまで書いたら、普通あとの20%も書いて完成させようと思う。
テーブルでやるべき(？)部分も気づいた頃にはCSSで書いてる。
だからわざわざテーブルにするのは無意味。
32 ：Name_Not_Found：04/08/10 16:12 ID:???
>>27
別にどうしてもやりたきゃやっていいよ。
ただ、論理要素はあんたにとっては意味が無くても
受け手にとっては意味があるので、誤用は即ち誤解を招く。
そうした弊害を無視できる状況でなければ、やめた方がいいのが基本。
別にどうしてもやりたきゃやっていいよ。
ただ、論理要素はあんたにとっては意味が無くても
受け手にとっては意味があるので、誤用は即ち誤解を招く。
そうした弊害を無視できる状況でなければ、やめた方がいいのが基本。
33 ：Name_Not_Found：04/08/10 16:24 ID:???
>>27
本題とはちょっと離れるけど、スタイルシートだとスタイルをいじりやすくなるから、自然とデザインが良くなるよ。
勉強なんか全然しなくても、いじりまわしてるうちにどういう配色が良いかとかが分かってくる。
floatやposition関係のことを考えてたら「こうすればこういうレイアウトもできるな」
なんて思いついて、それをそのまま採用してみたり。
テーブルだと直すのが大変で諦めちゃうけど、
スタイルシートなら自分が納得行くまで修正できる。
よく「CSSだとデザインがしょぼくなる」って言う人がいるけど、それは大嘘。
たしかにCSSは不十分なところも多いけど、HTMLで無理やりやるよりははるかに良い。
特別に勉強した人やセンスのある人ならなおさら、スタイルシートのほうがその「武器」を生かせる。
本題とはちょっと離れるけど、スタイルシートだとスタイルをいじりやすくなるから、自然とデザインが良くなるよ。
勉強なんか全然しなくても、いじりまわしてるうちにどういう配色が良いかとかが分かってくる。
floatやposition関係のことを考えてたら「こうすればこういうレイアウトもできるな」
なんて思いついて、それをそのまま採用してみたり。
テーブルだと直すのが大変で諦めちゃうけど、
スタイルシートなら自分が納得行くまで修正できる。
よく「CSSだとデザインがしょぼくなる」って言う人がいるけど、それは大嘘。
たしかにCSSは不十分なところも多いけど、HTMLで無理やりやるよりははるかに良い。
特別に勉強した人やセンスのある人ならなおさら、スタイルシートのほうがその「武器」を生かせる。
34 ：Name_Not_Found：04/08/10 16:45 ID:???
>>27
変なマークアップが多いとUAが新しい機能を装備するのが困難になるんだぜ。
今ちょっと思いついただけだけど、表って行や列が多いとごちゃごちゃして見にくくなりがちじゃん？
そこでこれ。
tbody{ background-color: #fff; }
tr:hover{ background-color: #ddd; }
列:hover{ background-color: #ddd; }
td:hover{ background-color: #bbb; }
ポイントするとその行と列の背景が #ddd になって、交点であるそのセルは #bbb になる。
列をどうやって指定したら良いかわからないけど、なんかそういう要素あったよな？
つーかこれ、3年くらい前に思いついたんだっけ……。
まぁいいや。とにかく、UAのほうでこういう機能を標準装備することもできるわけ。
別に色が変わるんじゃなくて枠線が太くなるんでも、何でも良いよ。
本当の表だったらかなり便利そうでじゃん。
でもみんながテーブルレイアウトなんかやってたらどうよ。
うっかりマウスカーソルをそのテーブルの上に持ってきちゃったらいきなり色が変わって変じゃないかい？
それでUAはいつまでもこういう機能を実装できない。
リンク一覧みたいなのだって、「ここをクリック」ばっかりじゃ役に立たないのよ。
わかる？ ごみのポイ捨てと同じく、一人一人が気をつけないと結局みんなが困るんだ。
だから>>32みたいな意見には全力で反対したいと思う。
変なマークアップが多いとUAが新しい機能を装備するのが困難になるんだぜ。
今ちょっと思いついただけだけど、表って行や列が多いとごちゃごちゃして見にくくなりがちじゃん？
そこでこれ。
tbody{ background-color: #fff; }
tr:hover{ background-color: #ddd; }
列:hover{ background-color: #ddd; }
td:hover{ background-color: #bbb; }
ポイントするとその行と列の背景が #ddd になって、交点であるそのセルは #bbb になる。
列をどうやって指定したら良いかわからないけど、なんかそういう要素あったよな？
つーかこれ、3年くらい前に思いついたんだっけ……。
まぁいいや。とにかく、UAのほうでこういう機能を標準装備することもできるわけ。
別に色が変わるんじゃなくて枠線が太くなるんでも、何でも良いよ。
本当の表だったらかなり便利そうでじゃん。
でもみんながテーブルレイアウトなんかやってたらどうよ。
うっかりマウスカーソルをそのテーブルの上に持ってきちゃったらいきなり色が変わって変じゃないかい？
それでUAはいつまでもこういう機能を実装できない。
リンク一覧みたいなのだって、「ここをクリック」ばっかりじゃ役に立たないのよ。
わかる？ ごみのポイ捨てと同じく、一人一人が気をつけないと結局みんなが困るんだ。
だから>>32みたいな意見には全力で反対したいと思う。
35 ：Name_Not_Found：04/08/10 16:53 ID:???
なんかみんなが一斉に一生懸命でちょっと笑った
36 ：Name_Not_Found：04/08/10 16:56 ID:???
>>35
言うなｗ
言うなｗ
37 ：Name_Not_Found：04/08/10 17:01 ID:???
38 ：Name_Not_Found：04/08/10 17:29 ID:???
>>35
生まれ変わる可能性のある人物を逃したくないからな。
生まれ変わる可能性のある人物を逃したくないからな。
39 ：Name_Not_Found：04/08/10 17:45 ID:???
40 ：Name_Not_Found：04/08/10 18:56 ID:???
多数項目がある入力フォームの整形はみなさんどうやっているんですか?
例)
項目name ：inputタグ：補助説明１
項目address ：inputタグ：補助説明２
項目zipcode ：inputタグ：補助説明３
項目telephone ：inputタグ：補助説明４
項目notes ：inputタグ：補助説明５
tableだと各列(縦)は並べ易いんですけど...
ひょっとして、divタグをfloat:leftで?
例)
項目name ：inputタグ：補助説明１
項目address ：inputタグ：補助説明２
項目zipcode ：inputタグ：補助説明３
項目telephone ：inputタグ：補助説明４
項目notes ：inputタグ：補助説明５
tableだと各列(縦)は並べ易いんですけど...
ひょっとして、divタグをfloat:leftで?
41 ：Name_Not_Found：04/08/10 19:02 ID:???
42 ：Name_Not_Found：04/08/10 19:05 ID:???
>>40
マークアップにもよるが基本路線は display : table-* 指定では。
マークアップにもよるが基本路線は display : table-* 指定では。
43 ：Name_Not_Found：04/08/10 19:41 ID:???
皆様ありがとうございます。
仕事中ちょっとのぞいてみました
後ほどレスします。
仕事中ちょっとのぞいてみました
後ほどレスします。
>>29
>・仕様に沿って使ってもらった方がHTMLを解釈しやすい
解釈しやすいとは、ブラウザがでしょうか？HTMLを読む人のこと
でしょうか？
>・レイアウトについてはCSSで代替可能である
なるほど。CSSについては深くは知らないのですが、レイヤーの
ことでしょうか？
>「テーブルレイアウトをする必要はない」って話かな。
「テーブルレイアウトをする必要はない」のはわかります。それは同意
します。ただ、友人の一部に「テーブルレイアウトは禁止」「テーブル
は重いから使わない」と言う人がいるのです。
>むしろなぜテーブルレイアウトじゃなきゃいけないの？と聞きたいかも。
>１番目が「テーブルレイアウトはしない方がよい」の理由。
>２番目が「テーブルレイアウトは必要ない」の理由。
>併せて「なぜテーブルレイアウトにしたいの？」と書くべきかも。
テーブルレイアウトについては、僕の意見では「テーブルかCSSのどちらか
使いたい方を好みに合わせて使えば良い」と思っています。個人としては
テーブルレイアウト派です。これは、気持ちとしては昔の職人みたいなも
のです。今ではどんな複雑なレイアウトでもテーブルのタグ打ちで表現で
きるまでなりました。せっかく身に付けた技術が否定されるのはちと辛い。
それから、CSS覚える気持ちがわかないってところです。
>・仕様に沿って使ってもらった方がHTMLを解釈しやすい
解釈しやすいとは、ブラウザがでしょうか？HTMLを読む人のこと
でしょうか？
>・レイアウトについてはCSSで代替可能である
なるほど。CSSについては深くは知らないのですが、レイヤーの
ことでしょうか？
>「テーブルレイアウトをする必要はない」って話かな。
「テーブルレイアウトをする必要はない」のはわかります。それは同意
します。ただ、友人の一部に「テーブルレイアウトは禁止」「テーブル
は重いから使わない」と言う人がいるのです。
>むしろなぜテーブルレイアウトじゃなきゃいけないの？と聞きたいかも。
>１番目が「テーブルレイアウトはしない方がよい」の理由。
>２番目が「テーブルレイアウトは必要ない」の理由。
>併せて「なぜテーブルレイアウトにしたいの？」と書くべきかも。
テーブルレイアウトについては、僕の意見では「テーブルかCSSのどちらか
使いたい方を好みに合わせて使えば良い」と思っています。個人としては
テーブルレイアウト派です。これは、気持ちとしては昔の職人みたいなも
のです。今ではどんな複雑なレイアウトでもテーブルのタグ打ちで表現で
きるまでなりました。せっかく身に付けた技術が否定されるのはちと辛い。
それから、CSS覚える気持ちがわかないってところです。
>>31
>>>29-30にもあるようにそもそもテーブルでやるメリットが無いっていうのが一番大きい。
>逆にデメリットはいろいろある。表示が遅いとか、編集するときわけが分からなくなるとか。
テーブルは重いと聞きますが、それはCPUが100MHz以前の話かなと言う気はします。
今のように500MHz、ギガヘルツの時代ではテーブルが重いと感じることはないような
気がします。ただし、HTMLのレンダリングの遅い旧MacOSとかだと不便かな。
編集するとき訳がわからない。確かにそうです。訳分からないです。ただ、それが
わかるほどテーブルレイアウトをやりこんだ人からするとそこに明快さを感じるのも
ありまして、不便と感じない人については使っても良いんじゃないかと思います。
共同作業では辛いところですね。自分だけわかればよいってもんじゃないですから。
>fontたぐとかをやめて論理マークアップにしたら編集が楽だっていうのは知ってる？
CSSについてはよく知りません。ちょっと興味本位で勉強した時は、スクロールバーの
色変えるのと、レイヤーってのやってみたくらいです。このレイヤーに痛く感動した
覚えがあるのですが、ある欠点によりやはり使うのやめてしまいました。
>>32
>別にどうしてもやりたきゃやっていいよ。
>ただ、論理要素はあんたにとっては意味が無くても
>受け手にとっては意味があるので、誤用は即ち誤解を招く。
>そうした弊害を無視できる状況でなければ、やめた方がいいのが基本。
ここについてはよくわからないです。具体的にどういう弊害でしょう？
受け手とは？
>>>29-30にもあるようにそもそもテーブルでやるメリットが無いっていうのが一番大きい。
>逆にデメリットはいろいろある。表示が遅いとか、編集するときわけが分からなくなるとか。
テーブルは重いと聞きますが、それはCPUが100MHz以前の話かなと言う気はします。
今のように500MHz、ギガヘルツの時代ではテーブルが重いと感じることはないような
気がします。ただし、HTMLのレンダリングの遅い旧MacOSとかだと不便かな。
編集するとき訳がわからない。確かにそうです。訳分からないです。ただ、それが
わかるほどテーブルレイアウトをやりこんだ人からするとそこに明快さを感じるのも
ありまして、不便と感じない人については使っても良いんじゃないかと思います。
共同作業では辛いところですね。自分だけわかればよいってもんじゃないですから。
>fontたぐとかをやめて論理マークアップにしたら編集が楽だっていうのは知ってる？
CSSについてはよく知りません。ちょっと興味本位で勉強した時は、スクロールバーの
色変えるのと、レイヤーってのやってみたくらいです。このレイヤーに痛く感動した
覚えがあるのですが、ある欠点によりやはり使うのやめてしまいました。
>>32
>別にどうしてもやりたきゃやっていいよ。
>ただ、論理要素はあんたにとっては意味が無くても
>受け手にとっては意味があるので、誤用は即ち誤解を招く。
>そうした弊害を無視できる状況でなければ、やめた方がいいのが基本。
ここについてはよくわからないです。具体的にどういう弊害でしょう？
受け手とは？
>>33
>本題とはちょっと離れるけど、スタイルシートだとスタイルをいじりやすくなるから、自然とデザインが良くなるよ。
>よく「CSSだとデザインがしょぼくなる」って言う人がいるけど、それは大嘘。
>たしかにCSSは不十分なところも多いけど、HTMLで無理やりやるよりははるかに良い。
>特別に勉強した人やセンスのある人ならなおさら、スタイルシートのほうがその「武器」を生かせる。
そうですね。テーブルは再構築が熟練していないと大変。それが悩みだったのですが、今ではまず完成図を書いて
その後、HTMLに落としていく作業方法をとっています。つまり変更がでないように最後にコーディングする。そし
て、不便は不便なりに数をこなしていくうちに自由自在にテーブルレイアウトできるようになってしまいました。
CSSではそれらが簡単に実現できるんですね？
>>34
>でもみんながテーブルレイアウトなんかやってたらどうよ。
>うっかりマウスカーソルをそのテーブルの上に持ってきちゃったらいきなり色が変わって変じゃないかい？
>それでUAはいつまでもこういう機能を実装できない。
>わかる？ ごみのポイ捨てと同じく、一人一人が気をつけないと結局みんなが困るんだ。
テーブルレイアウトしていると、OSの中にはそういう動作をすると言うことでしょうか？
自分はWindows＋IEなので、他の環境だとカーソルが変わるとかあるのかな。
今までをまとめてみると
・CSSの方がテーブルより使いやすいよ
・テーブルは表示に時間がかかる・第三者がコード見て難解
・テーブルの本来の機能ではないから
・カーソルが変わるからダメ
「テーブルレイアウト」が致命的にいけない理由と言うのはないようですね。
まとめるとCSSの方が解釈しやすい、編集しやすい、CSSの方が好き、CSSの方が
おすすめできるってところでしょうか。
ところで、僕はテーブルレイアウト派ですが、CSSの方がメリットがあるのなら
乗り換えするつもりです。CSSを覚えるメリットって端的にどんなものでしょうか？
49 ：Name_Not_Found：04/08/11 11:25 ID:???
なんていうか、君には読解力が足りない。
50 ：Name_Not_Found：04/08/11 11:40 ID:???
49よ、そういう厨房みたいなレスするなよ。
51 ：Name_Not_Found：04/08/11 11:41 ID:???
まとめが見事にまとまってないのにﾜﾛﾀ
52 ：Name_Not_Found：04/08/11 11:41 ID:???
> テーブルは重いと聞きますが、それはCPUが100MHz以前の話かなと言う気はします。
> 今のように500MHz、ギガヘルツの時代ではテーブルが重いと感じることはないような気がします。
PC のスペックで言えば問題ないだろうけど、回線が細いとどうにもこうにも。
やれ ADSL だ、やれ FTTH だとか言われているけど、ナローバンドの人が完全にいなくなったわけじゃない。
> 今のように500MHz、ギガヘルツの時代ではテーブルが重いと感じることはないような気がします。
PC のスペックで言えば問題ないだろうけど、回線が細いとどうにもこうにも。
やれ ADSL だ、やれ FTTH だとか言われているけど、ナローバンドの人が完全にいなくなったわけじゃない。
53 ：Name_Not_Found：04/08/11 11:51 ID:???
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
51さんがまとめてください
54 ：Name_Not_Found：04/08/11 11:54 ID:???
せっかく良い流れになっていたのをぶち壊す糞馬鹿＞４９
55 ：Name_Not_Found：04/08/11 11:55 ID:???
>>27は潜在的な荒らし
まとめの部分は長い分を一気に読んでまとめたので間違いが多いかも。
まとめは無視してください。では、端的にどういけないのでしょう？
これまでの中で「テーブルレイアウトが致命的にいけない」理由のような
ものはなかったと思います。
カーソルが変わるってところくらいですか？不都合のある部分と言うのは。
テーブルレイアウトよりCSSが好ましい理由ではなく、テーブルレイアウトが
いけない理由（禁止と言う人がいる理由）を知りたいんです。
CSSが使いやすいと言うのは好みの問題かと思います。
>>52
ナローバンドだとテーブルタグが乗っかる分重くなるということですか？
しかし、タグのデータ量はしれてると思いますが。画像などに比べれば。
まとめは無視してください。では、端的にどういけないのでしょう？
これまでの中で「テーブルレイアウトが致命的にいけない」理由のような
ものはなかったと思います。
カーソルが変わるってところくらいですか？不都合のある部分と言うのは。
テーブルレイアウトよりCSSが好ましい理由ではなく、テーブルレイアウトが
いけない理由（禁止と言う人がいる理由）を知りたいんです。
CSSが使いやすいと言うのは好みの問題かと思います。
>>52
ナローバンドだとテーブルタグが乗っかる分重くなるということですか？
しかし、タグのデータ量はしれてると思いますが。画像などに比べれば。
57 ：Name_Not_Found：04/08/11 12:06 ID:???
58 ：Name_Not_Found：04/08/11 12:07 ID:???
>56
カーソルが変わるってのが例だってことに気づかない27に萌え
あと、IEでは、tableは終了タグが来るまでレンダリング開始されない
ttp://www.ne.jp/asahi/minazuki/bakera/html/opinion/table に色々書いてあるので参照のこと
カーソルが変わるってのが例だってことに気づかない27に萌え
あと、IEでは、tableは終了タグが来るまでレンダリング開始されない
ttp://www.ne.jp/asahi/minazuki/bakera/html/opinion/table に色々書いてあるので参照のこと
>>58
いえいえ。知っています。確かに、それはテーブルレイアウトの欠点ですね。
自分はテーブルを複数に分割しているため、上から少しずつ表示されるように
するなど工夫をしていますが、それでもテーブルの欠点であることは間違い
ないように思います。
ただし、それも自分にとっては致命的な欠陥ではないんです。ここは個人の主観
によるところが大きいので、人によっては許せない部分もあるかもしれません。
いえいえ。知っています。確かに、それはテーブルレイアウトの欠点ですね。
自分はテーブルを複数に分割しているため、上から少しずつ表示されるように
するなど工夫をしていますが、それでもテーブルの欠点であることは間違い
ないように思います。
ただし、それも自分にとっては致命的な欠陥ではないんです。ここは個人の主観
によるところが大きいので、人によっては許せない部分もあるかもしれません。
テーブルの終了タグが来るまでレンダリングが開始されない・・
第三者から見て修正が困難
余計なタグが乗るからデータ量が多い(それでも画像に比べると微少)
ここらの欠点はテーブルレイアウトの便利さとトレードオフってところでしょうか。
ところで、CSSでレイアウトする場合はレイヤーを使えばよいのでしょうか？
レイヤーでは間違っていますか？
第三者から見て修正が困難
余計なタグが乗るからデータ量が多い(それでも画像に比べると微少)
ここらの欠点はテーブルレイアウトの便利さとトレードオフってところでしょうか。
ところで、CSSでレイアウトする場合はレイヤーを使えばよいのでしょうか？
レイヤーでは間違っていますか？
>>59
まず誤解のないように言っておくけど「テーブルレイアウトは不許可」と言いたい気持ちはあるけど
残念なことに世界に蔓延しているのでただちに廃絶することはできないと思ってる。
ただ、新しくサイトをデザインしようという人たちはできるだけCSSを使って欲しい。
前言ったように、テーブルレイアウトをやる必要はないし、メリットがあるとしたら、
あなたのように「これまで馴染んできたから今更やり方を変えたくない」くらいだと思うので。
（そういう人たちにもできるだけ乗り換えて欲しいけどね。）
W3C信者が「テーブルレイアウトを教えるHTML教室」を最も嫌うのはこの辺に理由があると思う。
で、CSSを使うデザイン的なメリットとしては、リニューアルがすごく簡単、CSSが独立しているので、
新しくコンテンツを追加するときに中身だけ作ればいい（テーブルタグをコピペする必要なし）といったことかな。
まず誤解のないように言っておくけど「テーブルレイアウトは不許可」と言いたい気持ちはあるけど
残念なことに世界に蔓延しているのでただちに廃絶することはできないと思ってる。
ただ、新しくサイトをデザインしようという人たちはできるだけCSSを使って欲しい。
前言ったように、テーブルレイアウトをやる必要はないし、メリットがあるとしたら、
あなたのように「これまで馴染んできたから今更やり方を変えたくない」くらいだと思うので。
（そういう人たちにもできるだけ乗り換えて欲しいけどね。）
W3C信者が「テーブルレイアウトを教えるHTML教室」を最も嫌うのはこの辺に理由があると思う。
で、CSSを使うデザイン的なメリットとしては、リニューアルがすごく簡単、CSSが独立しているので、
新しくコンテンツを追加するときに中身だけ作ればいい（テーブルタグをコピペする必要なし）といったことかな。
63 ：Name_Not_Found：04/08/11 12:16 ID:???
>>27たん
夏休みだから解説してやろう。
>>45
StrictなHTMLならそれを読むUAも人間も解釈しやすくなる。
端的に挙げれば、>>34にあるようなUAの機能の拡張にかかわってくる。
ユーザスタイルが便利なのはわかる？
CSSでの代替はケースバイケースで変わってくる。
やってみればわかるけど、レイアウトによっては何種類かの方法で実現させられることもある。
margin(余白)を巧みに使っても良いし、無難にfloat(align属性と少し似てる)でやっても良いし、
position(要素を好きな場所に配置できる)で精密に指定しても良い、とか。
レイヤーっていうのは良く知らないけど、Netscape 4.xの独自拡張のあれ？
>せっかく身に付けた技術が否定されるのはちと辛い。
ここの人なんかはそうだった人も少なくないと思う。でもみんな移行してる。
総合的には割と純粋培養だった人間としてはどうしても理解しきれないところもあるけど、
テーブルの経験がCSSで全く生きないことはないと思うよ。
とりあえず、Strict HTMLの楽さから入ってみるのがおすすめ。
夏休みだから解説してやろう。
>>45
StrictなHTMLならそれを読むUAも人間も解釈しやすくなる。
端的に挙げれば、>>34にあるようなUAの機能の拡張にかかわってくる。
ユーザスタイルが便利なのはわかる？
CSSでの代替はケースバイケースで変わってくる。
やってみればわかるけど、レイアウトによっては何種類かの方法で実現させられることもある。
margin(余白)を巧みに使っても良いし、無難にfloat(align属性と少し似てる)でやっても良いし、
position(要素を好きな場所に配置できる)で精密に指定しても良い、とか。
レイヤーっていうのは良く知らないけど、Netscape 4.xの独自拡張のあれ？
>せっかく身に付けた技術が否定されるのはちと辛い。
ここの人なんかはそうだった人も少なくないと思う。でもみんな移行してる。
総合的には割と純粋培養だった人間としてはどうしても理解しきれないところもあるけど、
テーブルの経験がCSSで全く生きないことはないと思うよ。
とりあえず、Strict HTMLの楽さから入ってみるのがおすすめ。
>で、CSSを使うデザイン的なメリットとしては、リニューアルがすごく簡単、CSSが独立しているので、
>新しくコンテンツを追加するときに中身だけ作ればいい（テーブルタグをコピペする必要なし）といったことかな。
ここは魅力的ですね。HTMLでフォントの色変えるのとか不便ですものね。すべてのHTMLファイルを開いて
bodyとfontの中変えて行くのが面倒くさいこと。
ところで、毛嫌いせずにCSS勉強しようと言う気持ちも少々あります。レイアウトについては
レイヤーみたい使えば良いのでしょうか？レイヤーって表現が良いのかわかりませんが。
それから、CSSのサイト、時々まともに表示されていないサイトみかけませんか？
65 ：Name_Not_Found：04/08/11 12:22 ID:???
なんつーか、これが致命的な欠陥！ってのは無いんだけど、
細かい(といってもそこそこ重大だが)欠陥が積もり積もって結局だめ、みたいな意味もあるな。
細かい(といってもそこそこ重大だが)欠陥が積もり積もって結局だめ、みたいな意味もあるな。
66 ：Name_Not_Found：04/08/11 12:26 ID:???
> それから、CSSのサイト、時々まともに表示されていないサイトみかけませんか？
UA による解釈の違いとか、UA のバグとかだな。
UA による解釈の違いとか、UA のバグとかだな。
67 ：Name_Not_Found：04/08/11 12:26 ID:???
>>64
一種の過激派みたいな人はWinIEを無視することがある。
WinIEのCSSは我々に言わせればだめだめなんだが。
今のところはそのへんに対応するのが「CSS職人の業」みたいな感じ？
何せアメリカ政府もおすすめしないっていうくらいのUAだから。
或いはJavaScriptのトリックで失敗してる可能性もある。
そうでなければそのCSSが一行抜けてて空中分解してるとか。
一種の過激派みたいな人はWinIEを無視することがある。
WinIEのCSSは我々に言わせればだめだめなんだが。
今のところはそのへんに対応するのが「CSS職人の業」みたいな感じ？
何せアメリカ政府もおすすめしないっていうくらいのUAだから。
或いはJavaScriptのトリックで失敗してる可能性もある。
そうでなければそのCSSが一行抜けてて空中分解してるとか。
68 ：Name_Not_Found：04/08/11 12:29 ID:???
>>65
> なんつーか、これが致命的な欠陥！ってのは無いんだけど、
> 細かい(といってもそこそこ重大だが)欠陥が積もり積もって結局だめ、みたいな意味もあるな。
逆に、ここまで意味とデザインの分離が出来ていないHTML文書が世に溢れている以上、
致命的な欠陥を生むような変更をしづらいというのがあると思う。HTMLの仕様然り、
UAの実装然り。
> なんつーか、これが致命的な欠陥！ってのは無いんだけど、
> 細かい(といってもそこそこ重大だが)欠陥が積もり積もって結局だめ、みたいな意味もあるな。
逆に、ここまで意味とデザインの分離が出来ていないHTML文書が世に溢れている以上、
致命的な欠陥を生むような変更をしづらいというのがあると思う。HTMLの仕様然り、
UAの実装然り。
補足。
それでもテーブルよりCSSのほうが楽。
スタイルシートは一回やったら半永久的に使い回しが利くから、面倒なのは一箇所だけ。
テーブルでやっても崩れる環境と崩れない環境とあるでしょ？
テーブルだと崩れる環境はどうにもならないけど、CSSならだめな環境はすっぱり諦めることもできる。
有名なところでNetscape 4.xはむちゃくちゃだって言われてるけど、
Netscape 4.xを(CSS的に)すっぱり排除することも簡単。
テーブルで崩れて見られないよりはデフォルトスタイルのほうがはるかにマシ。
それでもテーブルよりCSSのほうが楽。
スタイルシートは一回やったら半永久的に使い回しが利くから、面倒なのは一箇所だけ。
テーブルでやっても崩れる環境と崩れない環境とあるでしょ？
テーブルだと崩れる環境はどうにもならないけど、CSSならだめな環境はすっぱり諦めることもできる。
有名なところでNetscape 4.xはむちゃくちゃだって言われてるけど、
Netscape 4.xを(CSS的に)すっぱり排除することも簡単。
テーブルで崩れて見られないよりはデフォルトスタイルのほうがはるかにマシ。
70 ：Name_Not_Found：04/08/11 12:33 ID:???
>夏休みだから解説してやろう。
ありがとう。
>>63
>StrictなHTMLならそれを読むUAも人間も解釈しやすくなる。端的に挙げれば、>>34にあるようなUAの
>機能の拡張にかかわってくる。ユーザスタイルが便利なのはわかる？
ゆーざすたいる？？(煽りではありません。ごめん) 上の説明わかりません。
ただ、本来の仕様に沿ったコーディングが人間にもUAにも優しいと言うのは
理解できます。
この問題で思い出したのが、かつてNECのPCエンジンでNECの仕様通りにコーディングしていなかった
一部のソフトウェアがハンディータイプのPCエンジンGTで動作しないなんて話がありましたっけ。
ありがとう。
>>63
>StrictなHTMLならそれを読むUAも人間も解釈しやすくなる。端的に挙げれば、>>34にあるようなUAの
>機能の拡張にかかわってくる。ユーザスタイルが便利なのはわかる？
ゆーざすたいる？？(煽りではありません。ごめん) 上の説明わかりません。
ただ、本来の仕様に沿ったコーディングが人間にもUAにも優しいと言うのは
理解できます。
この問題で思い出したのが、かつてNECのPCエンジンでNECの仕様通りにコーディングしていなかった
一部のソフトウェアがハンディータイプのPCエンジンGTで動作しないなんて話がありましたっけ。
>margin(余白)を巧みに使っても良いし、無難にfloat(align属性と少し似てる)でやっても良いし、
>position(要素を好きな場所に配置できる)で精密に指定しても良い、とか。
>レイヤーっていうのは良く知らないけど、Netscape 4.xの独自拡張のあれ？
一度、CSSをコピーしてきて使ってみたことがあります
<DIV style=" position: absolute; z-index: 3; top: 0px; left: 0px; width: 200px; height: 2000px; visibility: visible" id="Layer1">
上のようなコードです。positionでいいのかな。レイヤーってのは、id="Layer1"の部分をなんとなくてPhotoshopやGimpなどの
レイヤーに似ているのでレイヤーと思い込んでいました。関係ないかも。
で、この上の部分、使ってみて便利さに驚きました。いいねえー！って。で、なぜ使わなくなったのか。
実はIEの[文字のサイズ]を変更すると、表示が全体的に崩れてしまったのです。だから使わなくなりました。
具体的には、Layer1 Layer2 Layer3を１ドット単位で動かして微調整しました。思い通りに配置できるCSSに
大満足！ところが、文字サイズ変更で各レイヤーが意図せずお互いを干渉してしまい表示崩れ。
実はCSSで決まり！って思っていたからこの崩れは残念でした。結局、テーブルに戻ってしまいました。
これを回避する方法があるのかもしれませんが、勉強不足ですみません。
＞せっかく身に付けた技術が否定されるのはちと辛い。
>ここの人なんかはそうだった人も少なくないと思う。でもみんな移行してる。
>テーブルの経験がCSSで全く生きないことはないと思うよ。
>とりあえず、Strict HTMLの楽さから入ってみるのがおすすめ。
これを機会にもう一度CSSやってみることにします。
>position(要素を好きな場所に配置できる)で精密に指定しても良い、とか。
>レイヤーっていうのは良く知らないけど、Netscape 4.xの独自拡張のあれ？
一度、CSSをコピーしてきて使ってみたことがあります
<DIV style=" position: absolute; z-index: 3; top: 0px; left: 0px; width: 200px; height: 2000px; visibility: visible" id="Layer1">
上のようなコードです。positionでいいのかな。レイヤーってのは、id="Layer1"の部分をなんとなくてPhotoshopやGimpなどの
レイヤーに似ているのでレイヤーと思い込んでいました。関係ないかも。
で、この上の部分、使ってみて便利さに驚きました。いいねえー！って。で、なぜ使わなくなったのか。
実はIEの[文字のサイズ]を変更すると、表示が全体的に崩れてしまったのです。だから使わなくなりました。
具体的には、Layer1 Layer2 Layer3を１ドット単位で動かして微調整しました。思い通りに配置できるCSSに
大満足！ところが、文字サイズ変更で各レイヤーが意図せずお互いを干渉してしまい表示崩れ。
実はCSSで決まり！って思っていたからこの崩れは残念でした。結局、テーブルに戻ってしまいました。
これを回避する方法があるのかもしれませんが、勉強不足ですみません。
＞せっかく身に付けた技術が否定されるのはちと辛い。
>ここの人なんかはそうだった人も少なくないと思う。でもみんな移行してる。
>テーブルの経験がCSSで全く生きないことはないと思うよ。
>とりあえず、Strict HTMLの楽さから入ってみるのがおすすめ。
これを機会にもう一度CSSやってみることにします。
73 ：Name_Not_Found：04/08/11 12:39 ID:???
「役不足」をみんなが誤用するもんだから
迂闊に正しい意味で使えなくなってしまったのと似てるな。
自分だけが使う書き捨て文書とか仲間内だけで利用する文書での
ローカルルールでテーブルレイアウトやるのは勝手にすりゃいいけど
一般公開する文書にそれを持ち込むのはやっぱ恥ずかしいと思う。
迂闊に正しい意味で使えなくなってしまったのと似てるな。
自分だけが使う書き捨て文書とか仲間内だけで利用する文書での
ローカルルールでテーブルレイアウトやるのは勝手にすりゃいいけど
一般公開する文書にそれを持ち込むのはやっぱ恥ずかしいと思う。
書き込みが多いため、すべてに的確なレスができていないかもしれないので、
先に謝罪しておきます。
実を言うと、うちの会社の馬鹿社長、平気で「機種依存文字を使え！」と言います。
社長は機種依存文字なんて言葉は知りませんが、「よそもやってるんだからうちも
使いたい」「ルールとかどうでもいい」「Unixなんて知らん！」「インターネット
のルールなんかより、自社の利益が大事なんだ。そんなルールに従う必要はない、
自社だけよければ良いんだ！」なんて言いやがります。そのときに感じた怒りみた
いなものかな。
>なんつーか、これが致命的な欠陥！ってのは無いんだけど、
>細かい(といってもそこそこ重大だが)欠陥が積もり積もって結局だめ、みたいな意味もあるな。
それは理解できます。致命的な欠陥はないけど、ちいさいホコリみたいなもんが
たくさんあるからダメ！ですね。
＞それから、CSSのサイト、時々まともに表示されていないサイトみかけませんか？
>UA による解釈の違いとか、UA のバグとかだな。
もしかすると、IEのCSS解釈はおかしいそうですから、その崩れているサイトの記述が
正しいのかもしれませんね。そういう部分でマイクロソフトの数の支配に物を言わせた
自社仕様の標準化の強引な押し付けみたいなものに問題は感じますが。
>一種の過激派みたいな人はWinIEを無視することがある。
>WinIEのCSSは我々に言わせればだめだめなんだが。
>今のところはそのへんに対応するのが「CSS職人の業」みたいな感じ？
なるほど。上記のマイクロソフトの強引な自社仕様の押し付けに対する
抗議みたいなものですね。
76 ：Name_Not_Found：04/08/11 13:02 ID:???
>>72
CSSスレじゃないから突っ込みは控えめにしとくけど、
とりあえず、そりゃそこをpxで指定したらたぶんまずいこと起こるでしょ、みたいな。
Strict HTMLを勉強するなら、「テキストが用意されててそれをマークアップする」っていう形が良い。
「はじめにテキストありき」とも呼ばれるやつ。
それがStrict的に「真理」かどうかはわからないけど、とりあえず入門としては間違いない方法。
原稿用紙に書いたのをマークアップしていくのはどうかっていう案も前にこのスレで出てたけど、原理は同じ。
盛り上がってきたところなのか何か知らないがみんな、27たんを手取り足取りすとりくたーに育ててみないか？
どうせ黙っててもろくなネタが出ないんだから、夏休み特別企画だ。
このスレに夏休みな人が>>63以外何人いるか知らないが。
CSSスレじゃないから突っ込みは控えめにしとくけど、
とりあえず、そりゃそこをpxで指定したらたぶんまずいこと起こるでしょ、みたいな。
Strict HTMLを勉強するなら、「テキストが用意されててそれをマークアップする」っていう形が良い。
「はじめにテキストありき」とも呼ばれるやつ。
それがStrict的に「真理」かどうかはわからないけど、とりあえず入門としては間違いない方法。
原稿用紙に書いたのをマークアップしていくのはどうかっていう案も前にこのスレで出てたけど、原理は同じ。
盛り上がってきたところなのか何か知らないがみんな、27たんを手取り足取りすとりくたーに育ててみないか？
どうせ黙っててもろくなネタが出ないんだから、夏休み特別企画だ。
このスレに夏休みな人が>>63以外何人いるか知らないが。
>逆に、ここまで意味とデザインの分離が出来ていないHTML文書が世に溢れている以上、
>致命的な欠陥を生むような変更をしづらいというのがあると思う。HTMLの仕様然り、UAの実装然り。
と
>「役不足」をみんなが誤用するもんだから
>迂闊に正しい意味で使えなくなってしまったのと似てるな。
>自分だけが使う書き捨て文書とか仲間内だけで利用する文書での
>ローカルルールでテーブルレイアウトやるのは勝手にすりゃいいけど
>一般公開する文書にそれを持ち込むのはやっぱ恥ずかしいと思う。
について
実は、テーブルレイアウトかCSSかって議論を見る・参加するたびに、そろそろHTMLを捨てて
新しい仕様やプロトコルを作る時代が来たのではないかと感じます。HTTP・HTMLはもともとは技術者
が情報交換するために作ったものだそうですから、デザイン畑の人の常識・理想・意見みたいなもの
は入っていませんしね。今のHTMLでは画像を使わない限り、思うようなページが作れないような気が
します。思うようなとは、雑誌を作るような感覚で気軽に線を引いたり、余白を指定したり、レイア
ウトを実現したりと言った。また、技術者はデザイナー、雑誌編集者、記者ではないため、業界の常
識の違いみたいなものが問題になることも多いと思います。例えば、下線付きの文字はデザインや編
集業界の方は通常は使わないものらしいです。PDFはどうかと言うとあれも問題ありな感じで。CSSに
ついては期待したいですが、マイクロソフトのわがまま、各社の思惑、標準化団体の力の影響力の弱
さなどいろいろな問題がありますよね。
>>69
>それでもテーブルよりCSSのほうが楽。
>スタイルシートは一回やったら半永久的に使い回しが利くから、面倒なのは一箇所だけ。
わかりました。CSSやってみます。やはり便利だとは思いますから。
>致命的な欠陥を生むような変更をしづらいというのがあると思う。HTMLの仕様然り、UAの実装然り。
と
>「役不足」をみんなが誤用するもんだから
>迂闊に正しい意味で使えなくなってしまったのと似てるな。
>自分だけが使う書き捨て文書とか仲間内だけで利用する文書での
>ローカルルールでテーブルレイアウトやるのは勝手にすりゃいいけど
>一般公開する文書にそれを持ち込むのはやっぱ恥ずかしいと思う。
について
実は、テーブルレイアウトかCSSかって議論を見る・参加するたびに、そろそろHTMLを捨てて
新しい仕様やプロトコルを作る時代が来たのではないかと感じます。HTTP・HTMLはもともとは技術者
が情報交換するために作ったものだそうですから、デザイン畑の人の常識・理想・意見みたいなもの
は入っていませんしね。今のHTMLでは画像を使わない限り、思うようなページが作れないような気が
します。思うようなとは、雑誌を作るような感覚で気軽に線を引いたり、余白を指定したり、レイア
ウトを実現したりと言った。また、技術者はデザイナー、雑誌編集者、記者ではないため、業界の常
識の違いみたいなものが問題になることも多いと思います。例えば、下線付きの文字はデザインや編
集業界の方は通常は使わないものらしいです。PDFはどうかと言うとあれも問題ありな感じで。CSSに
ついては期待したいですが、マイクロソフトのわがまま、各社の思惑、標準化団体の力の影響力の弱
さなどいろいろな問題がありますよね。
>>69
>それでもテーブルよりCSSのほうが楽。
>スタイルシートは一回やったら半永久的に使い回しが利くから、面倒なのは一箇所だけ。
わかりました。CSSやってみます。やはり便利だとは思いますから。
78 ：Name_Not_Found：04/08/11 13:05 ID:???
いやあの、27たんに時間と意思があればの話だが。
80 ：Name_Not_Found：04/08/11 13:07 ID:???
個人の質問にここまで丁寧にお付き合いいただき感謝しております。
そう言えば、ここはStrictHTMLのスレッド。CSSやテーブルレイアウトのための
スレッドではなかったようですので再び謝罪と感謝の意を。
>>76
>手取り足取りすとりくたーに育ててみないか？
ありがとうございます。これを機会にもう一度、考え直してみます。
まずはStrict-HTMLと言うものについて勉強してみたいと思います。
ROMの方もいるでしょうから、そういう方々のためにも。
ある程度は自力で勉強できると思いますから、まずはGoogleでStrict-HTMLで
検索して勉強してみます。もしくはお勧めサイトがあればぜひ。
お付き合いありがとうございました。また、覗きに着ます。
そう言えば、ここはStrictHTMLのスレッド。CSSやテーブルレイアウトのための
スレッドではなかったようですので再び謝罪と感謝の意を。
>>76
>手取り足取りすとりくたーに育ててみないか？
ありがとうございます。これを機会にもう一度、考え直してみます。
まずはStrict-HTMLと言うものについて勉強してみたいと思います。
ROMの方もいるでしょうから、そういう方々のためにも。
ある程度は自力で勉強できると思いますから、まずはGoogleでStrict-HTMLで
検索して勉強してみます。もしくはお勧めサイトがあればぜひ。
お付き合いありがとうございました。また、覗きに着ます。
82 ：Name_Not_Found：04/08/11 13:19 ID:???
>>80
このスレの人材は世間と比べればかなり優秀だろうから、
企画としては面白いと思ったけどな。
>>81
ttp://www.asahi-net.or.jp/~sd5a-ucd/www/index.html
これなんか、仕様書を邦訳してる人のだから読んどいて損は無い。
講座として良いかどうかはわからないけど。
ttp://members.jcom.home.ne.jp/pctips/
これは意見の分かれそうなところ。
「正字正かな」の人で、まあ要は戦前の国語表記のほうが良いんじゃないか、っていう主張なんだけど、
とりあえずそのへんのあれを気にしないで読めば参考にならないことはないと思う。
HTML関係の記事は「普通」にも見えるようにしてるところもある。
でも、これも講座として薦められるかいまいち自信が無い。
このスレの人材は世間と比べればかなり優秀だろうから、
企画としては面白いと思ったけどな。
>>81
ttp://www.asahi-net.or.jp/~sd5a-ucd/www/index.html
これなんか、仕様書を邦訳してる人のだから読んどいて損は無い。
講座として良いかどうかはわからないけど。
ttp://members.jcom.home.ne.jp/pctips/
これは意見の分かれそうなところ。
「正字正かな」の人で、まあ要は戦前の国語表記のほうが良いんじゃないか、っていう主張なんだけど、
とりあえずそのへんのあれを気にしないで読めば参考にならないことはないと思う。
HTML関係の記事は「普通」にも見えるようにしてるところもある。
でも、これも講座として薦められるかいまいち自信が無い。
83 ：Name_Not_Found：04/08/11 13:22 ID:???
>>81
お勧めサイトってことならこれかな。
ttp://www.asahi-net.or.jp/~jy3k-sm/css1/2003maki/index.html
"Strict-HTML" じゃ引っかからない予感。
お勧めサイトってことならこれかな。
ttp://www.asahi-net.or.jp/~jy3k-sm/css1/2003maki/index.html
"Strict-HTML" じゃ引っかからない予感。
84 ：Name_Not_Found：04/08/11 14:04 ID:???
終わっちゃったみたいだけど、>>27のいう通りにCSSでデザインしたら結局div使いまくりのテーブルレイアウトとなんらかわらんものしか出来ない気はするな。
strictスレ的には問題ないけど、なんだかな。
テーブルレイアウトの欠点、なんだけど、
漏れが実際に感じたのは、ページを参照しながらノートパッドなんかを使ってるときに、
横スクロールバーが出る、あるいは細い枠の中でひたすら改行された文章になる、ってのが読みづらくてかなわんかったな。
でも、この問題は、CSSでデザインしてもpxで固定してたり、positionでがちがちにしてたりすると同じ状況になる。
strictでvalidでcssでデザインしてて優れてるところはfloat多用でレイアウトしてるところが多いな。
カスイケで、目指したい方向性を見つけるのが早いかもしれん。
strictスレ的には問題ないけど、なんだかな。
テーブルレイアウトの欠点、なんだけど、
漏れが実際に感じたのは、ページを参照しながらノートパッドなんかを使ってるときに、
横スクロールバーが出る、あるいは細い枠の中でひたすら改行された文章になる、ってのが読みづらくてかなわんかったな。
でも、この問題は、CSSでデザインしてもpxで固定してたり、positionでがちがちにしてたりすると同じ状況になる。
strictでvalidでcssでデザインしてて優れてるところはfloat多用でレイアウトしてるところが多いな。
カスイケで、目指したい方向性を見つけるのが早いかもしれん。
85 ：Name_Not_Found：04/08/11 14:27 ID:???
86 ：Name_Not_Found：04/08/11 14:37 ID:???
87 ：Name_Not_Found：04/08/11 14:45 ID:???
「表じゃないから不可」で終わらないのかよ！
88 ：Name_Not_Found：04/08/11 14:47 ID:???
>>87
それじゃあ一般人の説得は難しい。W3C信者同士ならともかく。
それじゃあ一般人の説得は難しい。W3C信者同士ならともかく。
89 ：Name_Not_Found：04/08/11 15:05 ID:???
見た目が砂糖と同じだからって、コーヒーに塩は入れないだろ。
90 ：Name_Not_Found：04/08/11 15:12 ID:???
>>89
何か違うような気がしないでもないが、良しとしよう。
何か違うような気がしないでもないが、良しとしよう。
91 ：Name_Not_Found：04/08/11 18:17 ID:???
塩と砂糖の見た目は違うと思う。
92 ：Name_Not_Found：04/08/11 20:17 ID:???
終わっちゃったか
>>27はセマンティックウェブについて調べてみるといいかもな
>>27はセマンティックウェブについて調べてみるといいかもな
93 ：Name_Not_Found：04/08/11 20:38 ID:???
最近プログラム板ばっかで新スレになったのも気づかなかったがものすごいアフォが来てたんだな。
レスつけてたのも数人だけもしくは一人だけだろな。ここまでスレ違いな話に乗るやつなんてそういないだろ。
テーブルレイウアト。言葉の通りレイアウト方法についてだな。このスレとは無縁。
なぜにあのアフォはCSSスレに行かなかっただろな？一体なぜここを選んだんだろうな。
テーブルレイアウトの欠点なんてスレ違いもはなはだしい！
レスつけてたのも数人だけもしくは一人だけだろな。ここまでスレ違いな話に乗るやつなんてそういないだろ。
テーブルレイウアト。言葉の通りレイアウト方法についてだな。このスレとは無縁。
なぜにあのアフォはCSSスレに行かなかっただろな？一体なぜここを選んだんだろうな。
テーブルレイアウトの欠点なんてスレ違いもはなはだしい！
94 ：Name_Not_Found：04/08/11 20:40 ID:ZPlYKIDK
95 ：Name_Not_Found：04/08/11 20:40 ID:???
>ものすごいアフォが来てたんだな。
今また一人現れた様子
今また一人現れた様子
96 ：Name_Not_Found：04/08/11 20:40 ID:???
>>93
おまいみたいな自治厨は夏だからどっかいっちゃってるんだろ。今なら何でもありだろなこのスレ。
おまいみたいな自治厨は夏だからどっかいっちゃってるんだろ。今なら何でもありだろなこのスレ。
97 ：Name_Not_Found：04/08/11 20:41 ID:???
>>95
アフォ
アフォ
98 ：Name_Not_Found：04/08/11 21:48 ID:???
>>93みたいなのが一番の厨房だわ。キモオタ
99 ：Name_Not_Found：04/08/11 21:52 ID:???
93の部屋に入ったことがある
アニメのポスターがたくさんあった。
その他は普通だった。
アニメのポスターがたくさんあった。
その他は普通だった。
100 ：Name_Not_Found：04/08/11 21:55 ID:???
>>99
栗の花の臭いとかしなかったか？
栗の花の臭いとかしなかったか？
101 ：Name_Not_Found：04/08/11 21:56 ID:???
102 ：Name_Not_Found：04/08/11 21:56 ID:???
〜>>100からはまた平和になります。平和にならないとW3Cからミサイル発射です〜
103 ：Name_Not_Found：04/08/11 22:12 ID:???
ミサイル発射されてるよ or2
104 ：Name_Not_Found：04/08/12 00:04 ID:???
>>98-101
何でもいいから他で暴れてくれよ。
何でもいいから他で暴れてくれよ。
105 ：Name_Not_Found：04/08/12 00:31 ID:???
順序付きリストで
順序にアルファベットを使いたい場合に
スタイルシートでlist-style-typeを使ってますが
外部スタイル適用されないブラウザなどでは数字になってしまいます
アルファベット表示の順序が重要な場合
普通のリスト（ul）を使って、各リストの行頭にa. b. …とつける方が
良いのでしょうか？ Strictとは関係なかったらスマソ
順序にアルファベットを使いたい場合に
スタイルシートでlist-style-typeを使ってますが
外部スタイル適用されないブラウザなどでは数字になってしまいます
アルファベット表示の順序が重要な場合
普通のリスト（ul）を使って、各リストの行頭にa. b. …とつける方が
良いのでしょうか？ Strictとは関係なかったらスマソ
106 ：Name_Not_Found：04/08/12 00:37 ID:???
俺はそれでいいと思っているが
それじゃダメだと思ってる人もいると思う
きっと意見が割れるだろう
それじゃダメだと思ってる人もいると思う
きっと意見が割れるだろう
107 ：Name_Not_Found：04/08/12 00:40 ID:???
>>105
dlは？
dlは？
108 ：Name_Not_Found：04/08/12 00:41 ID:???
>>105
それで良いと思うけど、順序があるならあくまでOLで、と思う
それで良いと思うけど、順序があるならあくまでOLで、と思う
109 ：Name_Not_Found：04/08/12 00:42 ID:???
>>105
具体的にaとかbとかいう文字でその項目を参照しないならolでいいと思う。
具体的にaとかbとかいう文字でその項目を参照しないならolでいいと思う。
110 ：Name_Not_Found：04/08/12 00:48 ID:???
順序付きリストで行頭にa.b.c.…を書き加えて
そこだけ表示をnoneする。
そこだけ表示をnoneする。
111 ：Name_Not_Found：04/08/12 00:52 ID:???
>>105
>アルファベット表示の順序が重要な場合
スタイルシートの部分に本来HTMLに載せるべき情報を載せてしまっている。
アナルいじりの刑！
ul要素でいいと思う。どうせ中身比較して順序付けできるし。
（olでもいいと思うが）
>アルファベット表示の順序が重要な場合
スタイルシートの部分に本来HTMLに載せるべき情報を載せてしまっている。
アナルいじりの刑！
ul要素でいいと思う。どうせ中身比較して順序付けできるし。
（olでもいいと思うが）
みなさん、すばやいレスどうもです
>109
本文中で参照することがあります
olを使って数字で統一してもいいのですが、例えば
1.………
2.………
a.………
b.………
3.
という入れ子になったリストを数字だけにすると
1.………
2.………
1.………
2.………
3.………
という形になると思いますが
音声ブラウザでは3.がどちらの3.なのか判別しにくいので
入れ子になった部分の表記を変えたいという考えもあります
>109
本文中で参照することがあります
olを使って数字で統一してもいいのですが、例えば
1.………
2.………
a.………
b.………
3.
という入れ子になったリストを数字だけにすると
1.………
2.………
1.………
2.………
3.………
という形になると思いますが
音声ブラウザでは3.がどちらの3.なのか判別しにくいので
入れ子になった部分の表記を変えたいという考えもあります
113 ：Name_Not_Found：04/08/12 02:43 ID:???
114 ：Name_Not_Found：04/08/12 08:11 ID:???
>>112
> 音声ブラウザでは3.がどちらの3.なのか判別しにくいので
だったら入れ子部分は1.a.とかにした方がよくない？
アルファベット使うにしても1.aか2.a.か判別しにくかったりするのでは。
(本文中で参照するなら尚のこと)
>>113
じゃ、「前述のように」ってリンクはるかw
「bにこうあるように」が見栄え依存になるんだったら
「5章6節3項にこうあるように」も同様の見栄え依存表現だぞ。
> 音声ブラウザでは3.がどちらの3.なのか判別しにくいので
だったら入れ子部分は1.a.とかにした方がよくない？
アルファベット使うにしても1.aか2.a.か判別しにくかったりするのでは。
(本文中で参照するなら尚のこと)
>>113
じゃ、「前述のように」ってリンクはるかw
「bにこうあるように」が見栄え依存になるんだったら
「5章6節3項にこうあるように」も同様の見栄え依存表現だぞ。
115 ：Name_Not_Found：04/08/12 09:36 ID:???
>>112
>音声ブラウザでは3.がどちらの3.なのか判別しにくいので
strictと聞き栄えは関係ない。音声ブラウザがリストで作る階層構造をうまく
表現できなくても、それに考慮してHTMLを変えることはStrictHTMLの発想ではないね。
まあ音声ブラウザに配慮することはいいことだけど。
とりあえずユーザビリティとアクセシビリティについては他スレになるね。
>音声ブラウザでは3.がどちらの3.なのか判別しにくいので
strictと聞き栄えは関係ない。音声ブラウザがリストで作る階層構造をうまく
表現できなくても、それに考慮してHTMLを変えることはStrictHTMLの発想ではないね。
まあ音声ブラウザに配慮することはいいことだけど。
とりあえずユーザビリティとアクセシビリティについては他スレになるね。
>114
>112に記述したのリスト表記で
入れ子をolにして行頭にa.…と記述した場合に
1.……
2.……
1. a.…… ←2. a.にならない
2. b.……
3.……
となってしまうので、本文中では2.a.を参照と言えなくなってしまいます
となると、やはり入れ子はulにして
行頭に2.a.と記述するのが良さそうですね
>115
>strictと聞き栄えは関係ない
そのとおりですね
音声ブラウザへの配慮もまだまだ勉強中ですが
Strictにも興味があって、このような場合はどうなんだろうなと
みなさんどうもでした
>112に記述したのリスト表記で
入れ子をolにして行頭にa.…と記述した場合に
1.……
2.……
1. a.…… ←2. a.にならない
2. b.……
3.……
となってしまうので、本文中では2.a.を参照と言えなくなってしまいます
となると、やはり入れ子はulにして
行頭に2.a.と記述するのが良さそうですね
>115
>strictと聞き栄えは関係ない
そのとおりですね
音声ブラウザへの配慮もまだまだ勉強中ですが
Strictにも興味があって、このような場合はどうなんだろうなと
みなさんどうもでした
117 ：Name_Not_Found：04/08/12 10:27 ID:???
参照するんならdlでも良さそう。
>>114
あのさ、>>113じゃないけど、リストの頭にあるやつはCSSでやってるんだから見栄えなんだよ？
見出しに直接書いてあるなら見栄えじゃないんだよ？
ちゃんと読んだの？
>>114
あのさ、>>113じゃないけど、リストの頭にあるやつはCSSでやってるんだから見栄えなんだよ？
見出しに直接書いてあるなら見栄えじゃないんだよ？
ちゃんと読んだの？
118 ：Name_Not_Found：04/08/12 12:06 ID:???
>>117>>114
何をいわんとしてるのかはっきりと理解できないが、
とりあえず
１章１節１項を論理的にマークアップすると
<ol><li>hoge
<ol><li>hage
<ol><li>hige</li></ol>
</li></ol>
</li></ol>
だね。中に１−１−１とか書くのは間違い。olの入れ子でその１−１−１という論理的な
意味表現、構造表現は簡潔しているから、見栄えや聞き栄えについて考慮してHTMLがかわるというのはStrictらしくない。
まあ二人の意見を中途半端にしか読む時間がないので、どちらを否定するわけじゃなくて
一応具体的なマクアップ例を書いておいただけね。それじゃ
何をいわんとしてるのかはっきりと理解できないが、
とりあえず
１章１節１項を論理的にマークアップすると
<ol><li>hoge
<ol><li>hage
<ol><li>hige</li></ol>
</li></ol>
</li></ol>
だね。中に１−１−１とか書くのは間違い。olの入れ子でその１−１−１という論理的な
意味表現、構造表現は簡潔しているから、見栄えや聞き栄えについて考慮してHTMLがかわるというのはStrictらしくない。
まあ二人の意見を中途半端にしか読む時間がないので、どちらを否定するわけじゃなくて
一応具体的なマクアップ例を書いておいただけね。それじゃ
119 ：Name_Not_Found：04/08/12 12:48 ID:???
>>118
それで例えば他の項でこういう文書がある場合はどうするの？
「
higeの生え方について詳しくは1-1-a higeを参照してください。
」
この場合indexページの1-1-aっていうのはCSSでやっていたものだからCSSを切った環境では
↑の文書の意味がおかしなことになるよね？だってCSS切るとインデントがついて
1としか表示されてないで、文書の中でだけは1-1-aっていう風に呼び方が食い違ってしまうでしょ。
そもそもorderd listの頭に付くマーク等には意味があるのにCSSでいじれること自体がおかしい。
これはW3Cの手落ちだな。っていうのは言いすぎｗ？エロイ人説明おながいします。
それで例えば他の項でこういう文書がある場合はどうするの？
「
higeの生え方について詳しくは1-1-a higeを参照してください。
」
この場合indexページの1-1-aっていうのはCSSでやっていたものだからCSSを切った環境では
↑の文書の意味がおかしなことになるよね？だってCSS切るとインデントがついて
1としか表示されてないで、文書の中でだけは1-1-aっていう風に呼び方が食い違ってしまうでしょ。
そもそもorderd listの頭に付くマーク等には意味があるのにCSSでいじれること自体がおかしい。
これはW3Cの手落ちだな。っていうのは言いすぎｗ？エロイ人説明おながいします。
120 ：Name_Not_Found：04/08/12 12:49 ID:???
TeX のように相互参照を使えるように汁
121 ：Name_Not_Found：04/08/12 13:05 ID:???
そもそもHyperLink張れるHTMLで文章内容を人間がよんで判別する形の
関連付けって意味あるのか？
もちろん、「こちらをごらんください」みたいな話もある訳だがら、
HTMLの場合、関連付けだけしてればいい、と言うつもりはないが。
関連付けって意味あるのか？
もちろん、「こちらをごらんください」みたいな話もある訳だがら、
HTMLの場合、関連付けだけしてればいい、と言うつもりはないが。
122 ：Name_Not_Found：04/08/12 13:14 ID:???
>>121
貴方のような方を「here症候群」と呼びます。
貴方のような方を「here症候群」と呼びます。
123 ：Name_Not_Found：04/08/12 13:29 ID:???
>>120
もしかして1-1-a higeを文書の中で呼ぶ時も、
<p>うんたんらかんたら〜〜〜〜〜
higeの生え方について詳しくは
<ol><li>hoge
<ol><li>hage
<ol><li><strong><a>hige</a></strong></li></ol>
</li></ol>
</li></ol>
を参照してください。
〜〜〜〜〜〜〜〜〜〜かんたらうんたら</p>
で、CSSでstrocg以外は消して消してしまうとか？
もしかして1-1-a higeを文書の中で呼ぶ時も、
<p>うんたんらかんたら〜〜〜〜〜
higeの生え方について詳しくは
<ol><li>hoge
<ol><li>hage
<ol><li><strong><a>hige</a></strong></li></ol>
</li></ol>
</li></ol>
を参照してください。
〜〜〜〜〜〜〜〜〜〜かんたらうんたら</p>
で、CSSでstrocg以外は消して消してしまうとか？
124 ：Name_Not_Found：04/08/12 16:32 ID:???
<a href="#hige">hige</a>を参照してください。
と書いて適当なスタイルシートが「1-1-1higeを参照してください。」とレンダリングする。
#スタイルシートはCSSに限らんのよ。
pの最後の「。」は自動生成するべきか? qの引用符は自動生成するべきか? という問題と似ている。
olでliの中に1-1とか書いてスタイルシートでは自動生成をしないという設計も考えられた。
HTML4.01やXHTML2.0は1-1などは本文に書かないという設計でいいんだろうか?
>>116
http://www.w3.org/TR/CSS21/generate.html#counters
この辺を読め。
と書いて適当なスタイルシートが「1-1-1higeを参照してください。」とレンダリングする。
#スタイルシートはCSSに限らんのよ。
pの最後の「。」は自動生成するべきか? qの引用符は自動生成するべきか? という問題と似ている。
olでliの中に1-1とか書いてスタイルシートでは自動生成をしないという設計も考えられた。
HTML4.01やXHTML2.0は1-1などは本文に書かないという設計でいいんだろうか?
>>116
http://www.w3.org/TR/CSS21/generate.html#counters
この辺を読め。
125 ：Name_Not_Found：04/08/12 17:10 ID:???
>>124
><a href="#hige">hige</a>を参照してください。
>と書いて適当なスタイルシートが「1-1-1higeを参照してください。」とレンダリングする。
1-1-1はただの飾りなのか？ちょっと微妙だな。
HTMLで論理的な部分をやるってことは逆に言えばCSSで論理的なことはやるなってことだが。
ちなみに
pの最後の「。」は飾りではない。「。」に段落の終わりを示す意味はないので
pが終る=「。」とはならない。
引用符は確かに飾りであることは確かだが。
><a href="#hige">hige</a>を参照してください。
>と書いて適当なスタイルシートが「1-1-1higeを参照してください。」とレンダリングする。
1-1-1はただの飾りなのか？ちょっと微妙だな。
HTMLで論理的な部分をやるってことは逆に言えばCSSで論理的なことはやるなってことだが。
ちなみに
pの最後の「。」は飾りではない。「。」に段落の終わりを示す意味はないので
pが終る=「。」とはならない。
引用符は確かに飾りであることは確かだが。
126 ：Name_Not_Found：04/08/12 17:22 ID:???
例えば文章解析XMLみたいな物ができて、主語、述語…などなど、文中の
パーツをそれぞれ細分化してマークアップする言語の場合、
（当然第一に言語仕様による訳だが）句読点の類は飾りに成るかも知れない。
HTMLの場合、もっと大きな文書レベルでの構造化を目的としているので
そこまでぜず、句読点などはマークアップもしないし、だからそれらは
文書の内容となり一般的に飾りとは見なされない。
さて、リストのナンバの場合、HTMLでは、「リストであること」はマークアップの
対象となるが、「それが何番目であるか」は特にマークアップの対象とは
ならないし、単純なナンバリングは飾りとしてCSSなどが担当することに成っている。
もし、単純なナンバリングではなく、具体的な文中のポイントを表す
識別子であるというならそれはHTMLでは「ID」で表されるのが基本であるし、
（一般にはHyperlinkの対象になるが必ずしもIDはリンクアンカではない）
もし、UAのみならず人間向けに何らかの文中ポインタを識別子として渡したいなら
それらは「文中に文章として書かれるべき」。
リストのナンバリングが「識別として機能する」と言うことがそもそもレンダリングによる錯覚。
あるいみbタグにより「強調として機能する」と勘違いすることに等しい。
パーツをそれぞれ細分化してマークアップする言語の場合、
（当然第一に言語仕様による訳だが）句読点の類は飾りに成るかも知れない。
HTMLの場合、もっと大きな文書レベルでの構造化を目的としているので
そこまでぜず、句読点などはマークアップもしないし、だからそれらは
文書の内容となり一般的に飾りとは見なされない。
さて、リストのナンバの場合、HTMLでは、「リストであること」はマークアップの
対象となるが、「それが何番目であるか」は特にマークアップの対象とは
ならないし、単純なナンバリングは飾りとしてCSSなどが担当することに成っている。
もし、単純なナンバリングではなく、具体的な文中のポイントを表す
識別子であるというならそれはHTMLでは「ID」で表されるのが基本であるし、
（一般にはHyperlinkの対象になるが必ずしもIDはリンクアンカではない）
もし、UAのみならず人間向けに何らかの文中ポインタを識別子として渡したいなら
それらは「文中に文章として書かれるべき」。
リストのナンバリングが「識別として機能する」と言うことがそもそもレンダリングによる錯覚。
あるいみbタグにより「強調として機能する」と勘違いすることに等しい。
127 ：Name_Not_Found：04/08/12 17:43 ID:???
>>124の問題については考えたことがある。
pじゃなくて多分文のことを言いたかったんだろうと推定して話すけど。
qの引用符が勝手に生成されるっていうは最初から違和感があって、
あるとき引用符は飾りじゃなくて意味を持った記号だからHTMLに書かなきゃいけないんじゃないかって気づいた。
意味のある記号を自動生成するなら単語とかもそうしないと一貫性が無いんじゃないかと。
例えば<文><単語 品詞="名詞" 助詞="" 単語名="たぐ" />……</文>みたいに。
>>126の言ってるのはまあ大雑把に言えばだいたいこんな感じなんだろう。
でもね、疑問があるんです。
A「引用符は句読点と意味を持っていると思う。」
B「俺は意味を持っていないと思う。だからお前は自分の説を証明しろ。悪魔の証明だ。」
A「いや、この場合『意味を持っている』は『飾りではない』と等価だ。だから『飾りである』派のお前が証明しろ。」
どっちが正しいの？
悲しいけれど人は争いを忘れることなどできはしないの。
pじゃなくて多分文のことを言いたかったんだろうと推定して話すけど。
qの引用符が勝手に生成されるっていうは最初から違和感があって、
あるとき引用符は飾りじゃなくて意味を持った記号だからHTMLに書かなきゃいけないんじゃないかって気づいた。
意味のある記号を自動生成するなら単語とかもそうしないと一貫性が無いんじゃないかと。
例えば<文><単語 品詞="名詞" 助詞="" 単語名="たぐ" />……</文>みたいに。
>>126の言ってるのはまあ大雑把に言えばだいたいこんな感じなんだろう。
でもね、疑問があるんです。
A「引用符は句読点と意味を持っていると思う。」
B「俺は意味を持っていないと思う。だからお前は自分の説を証明しろ。悪魔の証明だ。」
A「いや、この場合『意味を持っている』は『飾りではない』と等価だ。だから『飾りである』派のお前が証明しろ。」
どっちが正しいの？
悲しいけれど人は争いを忘れることなどできはしないの。
128 ：Name_Not_Found：04/08/12 18:00 ID:???
フォームの入力欄をこんな感じでテーブルレイアウトしてるんですが、
こういう表現はテーブルレイアウトのままでいいんですかね？
どう変更すべきか、道を示してくだされ。
<table>
<tr>
<td>ID</td>
<td><input type="text" name="hogehoge" value=""></td>
</tr>
<tr>
<td>パス</td>
<td><input type="password" name="fuga" value=""></td>
</tr>
<tr>
<td colspan="2"><input type="submit" name="hoge1" value="aaa"></td>
</tr>
</table>
こういう表現はテーブルレイアウトのままでいいんですかね？
どう変更すべきか、道を示してくだされ。
<table>
<tr>
<td>ID</td>
<td><input type="text" name="hogehoge" value=""></td>
</tr>
<tr>
<td>パス</td>
<td><input type="password" name="fuga" value=""></td>
</tr>
<tr>
<td colspan="2"><input type="submit" name="hoge1" value="aaa"></td>
</tr>
</table>
129 ：Name_Not_Found：04/08/12 18:03 ID:???
130 ：Name_Not_Found：04/08/12 18:04 ID:???
>>127
回答：不要
理由：仕様にかいてあるから。
プロセスを逆順に言うと、
１：読者が引用箇所を、引用符、文字色の変化、読み上げの抑揚などにより
引用として認識する。
２：「１」の為に引用箇所に、引用符をつけたり、文字色の変化を行ったり、
読み上げの抑揚を付けたりという処理をUAが行う。
３−１：「２」の為にUAが引用箇所と認識する「ｑ」タグに対して引用符を付ける
３−２：「２」の為に本文に読者向けに引用符を記述する。
となる。この時、本来HTMLの仕様においては「手段：３−１」で講じられるように
UAベンダに向けて引用符の生成が求められ、文書記述者に対して引用符を
書かないように要求されているが、IEが守ってない/多くのHTML文書記述者は
仕様よりも実装ベースの表現を優先する為に「手段：３−２」がメジャーだったりする。
（っていうかそもそも一般的にはｑタグ自体が書かれてなかったりするが）
なお、ある文書（或いは文章）のどこまでをマークアップして、どこからは
文章に直接記述されるべきか、と言うレベル（或いはレイヤ）の切り分けは
全て仕様に依存する。これは「h1-6が見出しを意味する」というのと同じレベルの
お約束ごとなので、引用符に意味があろうが無かろうが、HTML4.01を採用する
以上は、不要（と言うか書いてはならない）。
というか、寧ろ仮に引用符に意味があっても「記述してはならない」。
# 「意味があるのに書くなとは、HTML4.01は腐った仕様だ」という批判は正当。
但し、その場合「じゃあその腐った仕様を使うなよ」という話になる。
回答：不要
理由：仕様にかいてあるから。
プロセスを逆順に言うと、
１：読者が引用箇所を、引用符、文字色の変化、読み上げの抑揚などにより
引用として認識する。
２：「１」の為に引用箇所に、引用符をつけたり、文字色の変化を行ったり、
読み上げの抑揚を付けたりという処理をUAが行う。
３−１：「２」の為にUAが引用箇所と認識する「ｑ」タグに対して引用符を付ける
３−２：「２」の為に本文に読者向けに引用符を記述する。
となる。この時、本来HTMLの仕様においては「手段：３−１」で講じられるように
UAベンダに向けて引用符の生成が求められ、文書記述者に対して引用符を
書かないように要求されているが、IEが守ってない/多くのHTML文書記述者は
仕様よりも実装ベースの表現を優先する為に「手段：３−２」がメジャーだったりする。
（っていうかそもそも一般的にはｑタグ自体が書かれてなかったりするが）
なお、ある文書（或いは文章）のどこまでをマークアップして、どこからは
文章に直接記述されるべきか、と言うレベル（或いはレイヤ）の切り分けは
全て仕様に依存する。これは「h1-6が見出しを意味する」というのと同じレベルの
お約束ごとなので、引用符に意味があろうが無かろうが、HTML4.01を採用する
以上は、不要（と言うか書いてはならない）。
というか、寧ろ仮に引用符に意味があっても「記述してはならない」。
# 「意味があるのに書くなとは、HTML4.01は腐った仕様だ」という批判は正当。
但し、その場合「じゃあその腐った仕様を使うなよ」という話になる。
131 ：Name_Not_Found：04/08/12 18:06 ID:???
ttp://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.2.2
>Visual user agents must ensure that the content of the Q element is
> rendered with delimiting quotation marks.
>Authors should not put quotation marks at the beginning and end of
> the content of a Q element.
意味が有ってもなくても関係ない。書くなと書いてあるんだから書いちゃだめ。
>Visual user agents must ensure that the content of the Q element is
> rendered with delimiting quotation marks.
>Authors should not put quotation marks at the beginning and end of
> the content of a Q element.
意味が有ってもなくても関係ない。書くなと書いてあるんだから書いちゃだめ。
132 ：Name_Not_Found：04/08/12 18:13 ID:???
自分で引用符を入れたい人はXHTML 2.0を使いましょう。
133 ：Name_Not_Found：04/08/12 18:26 ID:???
134 ：Name_Not_Found：04/08/12 18:35 ID:???
っていうか元々
>
は引用の意味があるなんてのは勘違い。そうゆう慣習なだけでぱんくずみたいなもの。
作者はここからここまでが引用ですよということをHTML内で表現できてればいい。
<q></q>
でそれはできているからそれ以上に何かするときはCSS等で。
>
は引用の意味があるなんてのは勘違い。そうゆう慣習なだけでぱんくずみたいなもの。
作者はここからここまでが引用ですよということをHTML内で表現できてればいい。
<q></q>
でそれはできているからそれ以上に何かするときはCSS等で。
135 ：Name_Not_Found：04/08/12 18:38 ID:???
>>127
本筋とはずれるが、お互いに相手が証明するべきだと発言した場合。
お互いが同時に自分の論証の根拠となることを示せば良い。
この場合『意味を持っている』は『飾りではない』と等価かも知れないけれど、
『意味を持っている』という「ある」状態であるのもまた事実であるわけで。
それならその意味を持っていることを証明すれば、それが *偶然* 飾りでないことを証明する。
もう一方の主張も同じように処理。
# どっちも納得いく結論出せないんならどっちも間違ってるとかね。
本筋とはずれるが、お互いに相手が証明するべきだと発言した場合。
お互いが同時に自分の論証の根拠となることを示せば良い。
この場合『意味を持っている』は『飾りではない』と等価かも知れないけれど、
『意味を持っている』という「ある」状態であるのもまた事実であるわけで。
それならその意味を持っていることを証明すれば、それが *偶然* 飾りでないことを証明する。
もう一方の主張も同じように処理。
# どっちも納得いく結論出せないんならどっちも間違ってるとかね。
136 ：Name_Not_Found：04/08/12 19:07 ID:???
137 ：Name_Not_Found：04/08/12 19:14 ID:???
>>126
>さて、リストのナンバの場合、HTMLでは、「リストであること」はマークアップの
>対象となるが、「それが何番目であるか」は特にマークアップの対象とは
>ならないし、単純なナンバリングは飾りとしてCSSなどが担当することに成っている。
>「それが何番目であるか」は特にマークアップの対象とはならないし
これっておかしくないか？例えば道順。
<hn>市民会館からコンビニまでの道順</hn>
<ol>
<li>北側入り口に立ち銀行を左に見れるように向きを変えてください
<li>１００メートル直進
<li>右に曲がり５０m直進
<li>左に曲がり10mの地点
</ol>
これは何番目ってのも重要だよ？例えば単にolが順番だけを表して何番目かは無関係であるならば
一個目の<li>要素が消えても↑は成り立たないといけないが、実際一番上が抜けるとおかしくなる。
だから何番目ってのもしっかりとマークアップするべき。ん？っていうかolのli要素には何番目っていう
意味も表してるってことね。
>さて、リストのナンバの場合、HTMLでは、「リストであること」はマークアップの
>対象となるが、「それが何番目であるか」は特にマークアップの対象とは
>ならないし、単純なナンバリングは飾りとしてCSSなどが担当することに成っている。
>「それが何番目であるか」は特にマークアップの対象とはならないし
これっておかしくないか？例えば道順。
<hn>市民会館からコンビニまでの道順</hn>
<ol>
<li>北側入り口に立ち銀行を左に見れるように向きを変えてください
<li>１００メートル直進
<li>右に曲がり５０m直進
<li>左に曲がり10mの地点
</ol>
これは何番目ってのも重要だよ？例えば単にolが順番だけを表して何番目かは無関係であるならば
一個目の<li>要素が消えても↑は成り立たないといけないが、実際一番上が抜けるとおかしくなる。
だから何番目ってのもしっかりとマークアップするべき。ん？っていうかolのli要素には何番目っていう
意味も表してるってことね。
いや、おかしくないよ。
HTML4.01の種類
<ul>
<li>Strict
<li>Transitional
<li>Frameset
</ul>
↑何番目かは無関係だが、どれかが消えたら成り立たない。当然でしょ。
内容の保持は当たり前の話。
olは、「子要素のliの順番には意味がある」という物であって、
単独にliを抜き出して「２番目」とか「３番目」という情報は一切持っていない
つまり、マークアップ対象ではない。
HTML4.01の種類
<ul>
<li>Strict
<li>Transitional
<li>Frameset
</ul>
↑何番目かは無関係だが、どれかが消えたら成り立たない。当然でしょ。
内容の保持は当たり前の話。
olは、「子要素のliの順番には意味がある」という物であって、
単独にliを抜き出して「２番目」とか「３番目」という情報は一切持っていない
つまり、マークアップ対象ではない。
139 ：Name_Not_Found：04/08/12 20:52 ID:???
olを前提に置く人とulを前提に置く人の行き違いでした
140 ：Name_Not_Found：04/08/12 20:58 ID:???
<ol>
<li>北側入り口に立ち銀行を左に見れるように向きを変えてください
<li>１００メートル直進
<li>右に曲がり５０m直進
<li>左に曲がり10mの地点
</ol>
<ol>
<li>北側入り口に立ち銀行を左に見れるように向きを変えてください
<li>これから長い旅がはじまります
<li>１００メートル直進
<li>大きな交差点につきます
<li>右に曲がり５０m直進
<li>タバコ屋の前の三叉路につきます
<li>左に曲がり10mの地点
<li>交番があるのでそこで道を訊きましょう
</ol>
<li>北側入り口に立ち銀行を左に見れるように向きを変えてください
<li>１００メートル直進
<li>右に曲がり５０m直進
<li>左に曲がり10mの地点
</ol>
<ol>
<li>北側入り口に立ち銀行を左に見れるように向きを変えてください
<li>これから長い旅がはじまります
<li>１００メートル直進
<li>大きな交差点につきます
<li>右に曲がり５０m直進
<li>タバコ屋の前の三叉路につきます
<li>左に曲がり10mの地点
<li>交番があるのでそこで道を訊きましょう
</ol>
141 ：Name_Not_Found：04/08/12 21:28 ID:???
142 ：Name_Not_Found：04/08/12 23:07 ID:???
んなこと言ったらぱんくずも変わってくるな。
まあ正しいといわれる記述方法が数種類あっていちいちいうのが面倒だからいいけど。
とりあえずこのスレの回答としてはolのliには順番はあるが番号的な意味はないってことで
いいか？
まあ正しいといわれる記述方法が数種類あっていちいちいうのが面倒だからいいけど。
とりあえずこのスレの回答としてはolのliには順番はあるが番号的な意味はないってことで
いいか？
143 ：Name_Not_Found：04/08/13 00:03 ID:???
>>137はおそらく、順番というのが「どれの次でどれの前」とかいう情報を含んでいるとは限らないと思ったんだ。
144 ：Name_Not_Found：04/08/13 00:31 ID:???
>>142
そうだね。複雑な番号付けになったら、ulに全て投げてしまっていいと思う。
そうだね。複雑な番号付けになったら、ulに全て投げてしまっていいと思う。
145 ：Name_Not_Found：04/08/13 01:12 ID:???
>>137
市民会館からコンビニまでの道順
2.１００メートル直進
3.右に曲がり５０m直進
4.左に曲がり10mの地点
これだっておかしいだろう。１番目が抜けた時点でこのリストは道順ではなく道順の一部を表していることになる。よってhnは「市民会館からコンビニまでの道順の一部」などに変わる。
すると1番目の要素を抜いたolでも問題なくなる。
>>128
まあ特に問題はない。
より良くするならばlabel要素を使うとか。
市民会館からコンビニまでの道順
2.１００メートル直進
3.右に曲がり５０m直進
4.左に曲がり10mの地点
これだっておかしいだろう。１番目が抜けた時点でこのリストは道順ではなく道順の一部を表していることになる。よってhnは「市民会館からコンビニまでの道順の一部」などに変わる。
すると1番目の要素を抜いたolでも問題なくなる。
>>128
まあ特に問題はない。
より良くするならばlabel要素を使うとか。
146 ：Name_Not_Found：04/08/13 01:31 ID:???
147 ：Name_Not_Found：04/08/13 05:08 ID:???
>>145
> すると1番目の要素を抜いたolでも問題なくなる。
違うだろ。「別のものを示すリストになる」「元にのリストの意味をもたない」ってこと。
あんたの理屈では、取ってのとれた急須は土瓶になる。取っ手がとれても「入れ物」となるから問題ない、ということ。
どちらも、入れ物（ol要素対象）であることは正しいが、
取っ手がとれた（リストの一部を削除した）ら、
土瓶（道順の一部を示したリスト）になってしまい、
急須（道順を示したol要素対象）ではなくなっている。
> すると1番目の要素を抜いたolでも問題なくなる。
違うだろ。「別のものを示すリストになる」「元にのリストの意味をもたない」ってこと。
あんたの理屈では、取ってのとれた急須は土瓶になる。取っ手がとれても「入れ物」となるから問題ない、ということ。
どちらも、入れ物（ol要素対象）であることは正しいが、
取っ手がとれた（リストの一部を削除した）ら、
土瓶（道順の一部を示したリスト）になってしまい、
急須（道順を示したol要素対象）ではなくなっている。
148 ：Name_Not_Found：04/08/13 05:09 ID:???
149 ：Name_Not_Found：04/08/13 07:53 ID:???
>>128
個人的には最後の行が「ああ、テーブルレイアウトなんだなぁ」という感じだ。
個人的には最後の行が「ああ、テーブルレイアウトなんだなぁ」という感じだ。
>>146
>>148
>>149
レスありがとう。
今まで、テーブルで入力フォームを作っていて、
これからは、テーブルレイアウトをやめたい・
もっとマークアップを重視したいと思って、
試行錯誤中なんです。
128の内容を>>146さんがおっしゃるように意味づけしてて↓を作ったんですが、
テーブルなのに、summaryがログインフォームとしてしまったら、
やはりtable本来の意味の「表」を表したものではなくなってしまいますよね。
<table summary="ログインフォーム">
<tr>
<th scope="col">ID</th>
<td><input type="text" name="hogehoge" value=""></td>
</tr>
<tr>
<th scope="col">パス</th>
<td><input type="password" name="fuga" value=""></td>
</tr>
</table>
<p><input type="submit" name="hoge1" value="aaa"></p>
>>148
>>149
レスありがとう。
今まで、テーブルで入力フォームを作っていて、
これからは、テーブルレイアウトをやめたい・
もっとマークアップを重視したいと思って、
試行錯誤中なんです。
128の内容を>>146さんがおっしゃるように意味づけしてて↓を作ったんですが、
テーブルなのに、summaryがログインフォームとしてしまったら、
やはりtable本来の意味の「表」を表したものではなくなってしまいますよね。
<table summary="ログインフォーム">
<tr>
<th scope="col">ID</th>
<td><input type="text" name="hogehoge" value=""></td>
</tr>
<tr>
<th scope="col">パス</th>
<td><input type="password" name="fuga" value=""></td>
</tr>
</table>
<p><input type="submit" name="hoge1" value="aaa"></p>
ここのリファレンスを参考にdlで定義してみました。
ttp://fls.moo.jp/xhtml_ref/dl.html
<dl>
<dt>ID</dt>
<dd><input type="text" name="hogehoge" value=""></dd>
<dt>パス</dt>
<dd><input type="password" name="fuga" value=""></dd>
</dl>
<p><input type="submit" name="hoge1" value="aaa"></p>
こういった入力フォームを作るのには、table・dlどちらを使うのが
正しい解釈になるんでしょうか？？
ながながと、長文すいません。
ttp://fls.moo.jp/xhtml_ref/dl.html
<dl>
<dt>ID</dt>
<dd><input type="text" name="hogehoge" value=""></dd>
<dt>パス</dt>
<dd><input type="password" name="fuga" value=""></dd>
</dl>
<p><input type="submit" name="hoge1" value="aaa"></p>
こういった入力フォームを作るのには、table・dlどちらを使うのが
正しい解釈になるんでしょうか？？
ながながと、長文すいません。
152 ：Name_Not_Found：04/08/13 10:29 ID:???
>>151
さっきと同じ質問のような気がするが。
表といえば表と解釈できる。
入力項目の列、入力部分の列、だから「ここに配置したいから使う」というテーブルレイアウトとは本質が違う。
dlでやってもいい。
それだけだろ。
>>150
フォームの内容を行と列とで表してるんだから表と言って差し支えないだろ。
さっきと同じ質問のような気がするが。
表といえば表と解釈できる。
入力項目の列、入力部分の列、だから「ここに配置したいから使う」というテーブルレイアウトとは本質が違う。
dlでやってもいい。
それだけだろ。
>>150
フォームの内容を行と列とで表してるんだから表と言って差し支えないだろ。
うお、激しく語弊があるな。
行と列で表せばいい、って意味じゃなくて、
表の様式に則って書かれてるわけだから、って言いたかった。
行と列で表せばいい、って意味じゃなくて、
表の様式に則って書かれてるわけだから、って言いたかった。
154 ：Name_Not_Found：04/08/13 13:29 ID:???
>>150
なんで scope="col" なんだ？
なんで scope="col" なんだ？
155 ：Name_Not_Found：04/08/13 16:38 ID:???
なあやっぱストリクタンはちょっとしたCGIをperlで書くときもきっちりオブジェクト指向なのか？
>>155
まあ、それなりに。
まあ、それなりに。
茎が残ってたotz
158 ：Name_Not_Found：04/08/13 19:08 ID:???
ストリクターはperlなんて使いません。
159 ：Name_Not_Found：04/08/13 19:19 ID:???
はいはい
160 ：Name_Not_Found：04/08/13 19:41 ID:???
>>158
PHPか？ｗ
PHPか？ｗ
161 ：Name_Not_Found：04/08/13 21:25 ID:???
162 ：Name_Not_Found：04/08/13 21:44 ID:???
XHTMLの中ではJavaScriptといえど&は&としないといけませんが、
逆に従来のHTMLとしてエージェントに解釈させると逆に&に文句を言いよります。
なるべく同じものをエージェントによってよろしく解釈させたいのですが、
こういう場合
* JavaScriptを外部に追い出す
* &&演算子を使うのをやめる
以外に上手い手はありませんかねえ?
逆に従来のHTMLとしてエージェントに解釈させると逆に&に文句を言いよります。
なるべく同じものをエージェントによってよろしく解釈させたいのですが、
こういう場合
* JavaScriptを外部に追い出す
* &&演算子を使うのをやめる
以外に上手い手はありませんかねえ?
163 ：Name_Not_Found：04/08/13 22:03 ID:???
おもしろいことになっているなあ…ｗ
&amp;
って入れるとヨロシ
&amp;
って入れるとヨロシ
164 ：Name_Not_Found：04/08/13 22:35 ID:???
>>162
JSを外部ファイルにするのがベター
JSを外部ファイルにするのがベター
165 ：Name_Not_Found：04/08/13 22:36 ID:???
166 ：Name_Not_Found：04/08/14 00:13 ID:???
function and(){
for(var i=0; i<argments.length; i++){
if(Boolean(argments[i]) === false){
return false;
}
}
return true;
}
こんな感じで&&を独自実装。
上記関数使うと今度は<で文句食らうので今度は <, >, <=, >= を独自実装。
まぁガンガレ。
for(var i=0; i<argments.length; i++){
if(Boolean(argments[i]) === false){
return false;
}
}
return true;
}
こんな感じで&&を独自実装。
上記関数使うと今度は<で文句食らうので今度は <, >, <=, >= を独自実装。
まぁガンガレ。
>>165
これでいけました! ありがとうございます。
そうか、CDATAと明示すればいいのか……。
昔<script><!--
// --></script>
とやったのと似た意味でやるようなものですねえ。
これでいけました! ありがとうございます。
そうか、CDATAと明示すればいいのか……。
昔<script><!--
// --></script>
とやったのと似た意味でやるようなものですねえ。
168 ：Name_Not_Found：04/08/14 00:23 ID:???
全然違うけどな
169 ：Name_Not_Found：04/08/14 00:26 ID:???
CDATA云々はそこらじゅうに書いてある気がしないでもない。
170 ：Name_Not_Found：04/08/14 00:44 ID:???
>>147
137は何番目の要素であるかという情報をもたないolでは1番目を削除したら成り立たなくなる、つまり急須でなくなるからだめだと主張している。
それに対して何番目の要素であるかという情報をもったリストでもそれは同様だと示した。
その上でそのようなリストを認めるならば見出しを変えなければならず、見出しを変えたならば１番目を削除したolでもいいじゃないかと主張した。
137は何番目の要素であるかという情報をもたないolでは1番目を削除したら成り立たなくなる、つまり急須でなくなるからだめだと主張している。
それに対して何番目の要素であるかという情報をもったリストでもそれは同様だと示した。
その上でそのようなリストを認めるならば見出しを変えなければならず、見出しを変えたならば１番目を削除したolでもいいじゃないかと主張した。
172 ：Name_Not_Found：04/08/14 01:55 ID:???
<!--
// -->
は信者になって全く使わなくなった呪文の一つ。
CSSにも使ってたよなあ…
// -->
は信者になって全く使わなくなった呪文の一つ。
CSSにも使ってたよなあ…
173 ：Name_Not_Found：04/08/14 02:08 ID:???
まさに呪文だな。不思議な仕様
174 ：Name_Not_Found：04/08/14 10:26 ID:???
>>172
おまえ意味わからずに使ってたんだな。
おまえ意味わからずに使ってたんだな。
175 ：Name_Not_Found：04/08/14 12:29 ID:/QsamjpT
なんでCSSに使うの？？？
176 ：Name_Not_Found：04/08/14 13:22 ID:???
Head内CSSをテキスト文と見なして表示する上に、
コメント化してもCSSとは見なす二重にバグったUA向け
コメント化してもCSSとは見なす二重にバグったUA向け
177 ：Name_Not_Found：04/08/14 14:05 ID:???
CSSの場合は // じゃないだろ、って突っ込みだろ。
178 ：Name_Not_Found：04/08/14 14:08 ID:???
独立ファイルを用意するのが前提になると使わなくなるね
179 ：Name_Not_Found：04/08/14 14:35 ID:???
180 ：Name_Not_Found：04/08/14 14:38 ID:???
>>176
いちろー言っとくと「コメント化してもCSSとはみなす」のはバグではないのでは？
いちろー言っとくと「コメント化してもCSSとはみなす」のはバグではないのでは？
181 ：Name_Not_Found：04/08/14 14:40 ID:???
HTMLだったらCDATAだから注釈扱いする方がバグだよね。
182 ：Name_Not_Found：04/08/14 14:45 ID:???
マジレス
・Head内CSSをテキスト文と見なして表示する
仕様では未知のタグはなかったことにするはず。
故に、中身をテキストとみなすのはバグではないと思われ。
・コメント化してもCSSとはみなす
上記のために付け加えられた（？）仕様でバグではないと思われ。
・Head内CSSをテキスト文と見なして表示する
仕様では未知のタグはなかったことにするはず。
故に、中身をテキストとみなすのはバグではないと思われ。
・コメント化してもCSSとはみなす
上記のために付け加えられた（？）仕様でバグではないと思われ。
style要素を既知の要素と見なすなら本文中に表示されるのはバグ。
style要素を未知の要素と見なすなら、CDATAとも解釈されないんだから
正しくSGMLとしてコメント化せなならん。
と言う訳で二重にバグっている。
style要素を未知の要素と見なすなら、CDATAとも解釈されないんだから
正しくSGMLとしてコメント化せなならん。
と言う訳で二重にバグっている。
184 ：Name_Not_Found：04/08/14 16:17 ID:???
なんか日本語が不自由な予感。
185 ：Name_Not_Found：04/08/14 16:28 ID:???
>>183
要素とタグは違います。
要素とタグは違います。
186 ：Name_Not_Found：04/08/14 16:39 ID:???
>>183
まず>>185。（つーかこれ理解できてないのはstrictスレとしては恥ずかしいことだと思う。）
それからスタイルデータのシンタクスは、スタイルシート言語に依存することになってる。
だからCSSが「<!--」なんかを無視してもHTMLの話とは関係ない話だから無問題。結論は>>182。
まず>>185。（つーかこれ理解できてないのはstrictスレとしては恥ずかしいことだと思う。）
それからスタイルデータのシンタクスは、スタイルシート言語に依存することになってる。
だからCSSが「<!--」なんかを無視してもHTMLの話とは関係ない話だから無問題。結論は>>182。
追記。
>style要素を未知の要素と見なすなら、CDATAとも解釈されないんだから
>正しくSGMLとしてコメント化せなならん。
だから <!-- --> でコメントしているわけ。正常。
>style要素を未知の要素と見なすなら、CDATAとも解釈されないんだから
>正しくSGMLとしてコメント化せなならん。
だから <!-- --> でコメントしているわけ。正常。
188 ：Name_Not_Found：04/08/14 16:50 ID:???
なんか議論がすれ違ってる予感。
189 ：Name_Not_Found：04/08/14 16:56 ID:???
>>176
意味わからないのだが…。
普通にstyleを用意するだけではテキストとして表示しちゃうけど、
コメント化すると正常にCSSと解釈しはじめるUAが存在するってこと？
あとstyleでhead内に書くよね？head内に生テキスト書くとどう解釈すべきなんだっけ？
意味わからないのだが…。
普通にstyleを用意するだけではテキストとして表示しちゃうけど、
コメント化すると正常にCSSと解釈しはじめるUAが存在するってこと？
あとstyleでhead内に書くよね？head内に生テキスト書くとどう解釈すべきなんだっけ？
190 ：Name_Not_Found：04/08/14 17:34 ID:???
gecko系ではhead{display:none}だったはず。
191 ：Name_Not_Found：04/08/14 17:39 ID:???
＞head内に生テキスト書くとどう解釈すべきなんだっけ？
仕様では
>User agents do not generally render elements that appear
> in the HEAD as content.
なので、一般的には表示されない
特にUA側が何らか特段の理由が有る訳でもなしにHEAD要素内の内容を表示したら
バグと言っていいかと思われ。
>>186
コメントならCSSとして機能したら変だろ。
つーか >>176 は単純な下位互換の話ではなくて、style要素内容が表示されるし
CSSとしても処理されるバグバグなUAがあったと言ってるんでないかい？
そんなUA俺は知らないが。
仕様では
>User agents do not generally render elements that appear
> in the HEAD as content.
なので、一般的には表示されない
特にUA側が何らか特段の理由が有る訳でもなしにHEAD要素内の内容を表示したら
バグと言っていいかと思われ。
>>186
コメントならCSSとして機能したら変だろ。
つーか >>176 は単純な下位互換の話ではなくて、style要素内容が表示されるし
CSSとしても処理されるバグバグなUAがあったと言ってるんでないかい？
そんなUA俺は知らないが。
192 ：Name_Not_Found：04/08/14 17:54 ID:???
＞head内に生テキスト書くとどう解釈すべきなんだっけ？
HTML4Transitionalの場合、テキストが出現した時点で
head要素終了/body要素開始と解釈するはず。
Strictの場合は単なる破損文書。
HTML4Transitionalの場合、テキストが出現した時点で
head要素終了/body要素開始と解釈するはず。
Strictの場合は単なる破損文書。
193 ：Name_Not_Found：04/08/14 17:57 ID:???
思うに >>176 は、言おうとしていることと実際に言っていることが
すでに食い違ってるのではないだろうか。意味解らん。
すでに食い違ってるのではないだろうか。意味解らん。
194 ：Name_Not_Found：04/08/14 20:05 ID:???
質問です。
例1
<p>〜ページの説明を兼ねたサブタイトル〜</p>
<h1>ページタイトル</h1>
例2
<h1>〜ページの説明を兼ねたサブタイトル〜</h1>
<h2>ページタイトル</h2>
例3
<h2>〜ページの説明を兼ねたサブタイトル〜</h2>
<h1>ページタイトル</h1>
例4
<h1><span style="font-size:50%;">〜ページの説明を兼ねたサブタイトル〜</span>
<br>ページタイトル</h1>
どれが適切でしょうか？あるいは、もっと別なやり方があるでしょうか？
例1
<p>〜ページの説明を兼ねたサブタイトル〜</p>
<h1>ページタイトル</h1>
例2
<h1>〜ページの説明を兼ねたサブタイトル〜</h1>
<h2>ページタイトル</h2>
例3
<h2>〜ページの説明を兼ねたサブタイトル〜</h2>
<h1>ページタイトル</h1>
例4
<h1><span style="font-size:50%;">〜ページの説明を兼ねたサブタイトル〜</span>
<br>ページタイトル</h1>
どれが適切でしょうか？あるいは、もっと別なやり方があるでしょうか？
195 ：Name_Not_Found：04/08/14 20:53 ID:???
例4でspanをclass="subtitile"にして、外部スタイルシートでスタイル付け
196 ：Name_Not_Found：04/08/14 20:55 ID:???
<h1>ページタイトル</h1>
<h2>ページの説明を兼ねたサブタイトル</h2>
あとはスタイルシートの仕事じゃん？
<h2>ページの説明を兼ねたサブタイトル</h2>
あとはスタイルシートの仕事じゃん？
197 ：Name_Not_Found：04/08/14 20:57 ID:???
>>194
その中では例4＞＞＞例1≧例2＞例3だと思う。
Strict風にしたいなら普通はだいたいこんな感じ。
<h1><span class="subtitle">〜サブタイトル〜</span> タイトル</h1>
h1 span.subtitle { display: block ; font-size: 50% ; }
br要素を突っ込むと、表示だけで考えても環境によっては馬鹿なことになるかもしれない。
逆に、サブタイトルを区切る記号(この場合は「〜」)があればHTMLやスタイルシートでの明示が効かなくても大丈夫。
おまけ。もっとやりたいならこういうのもアリかもしれない。
これならCSSで記号を変えられる。
<h1><span class="subtitle tag">〜</span><span class="subtitle content">サブタイトル</span><span class="subtitle tag">〜</span>
<span class="title">タイトル</span></h1>
h1 span.subtitle.tag { display: none ; }
h1 span.subtitle.content { display: block ; font-size: 50% ; }
h1 span.subtitle.content:before, h1 span.subtitle.content:after { content: "〜" ; }
その中では例4＞＞＞例1≧例2＞例3だと思う。
Strict風にしたいなら普通はだいたいこんな感じ。
<h1><span class="subtitle">〜サブタイトル〜</span> タイトル</h1>
h1 span.subtitle { display: block ; font-size: 50% ; }
br要素を突っ込むと、表示だけで考えても環境によっては馬鹿なことになるかもしれない。
逆に、サブタイトルを区切る記号(この場合は「〜」)があればHTMLやスタイルシートでの明示が効かなくても大丈夫。
おまけ。もっとやりたいならこういうのもアリかもしれない。
これならCSSで記号を変えられる。
<h1><span class="subtitle tag">〜</span><span class="subtitle content">サブタイトル</span><span class="subtitle tag">〜</span>
<span class="title">タイトル</span></h1>
h1 span.subtitle.tag { display: none ; }
h1 span.subtitle.content { display: block ; font-size: 50% ; }
h1 span.subtitle.content:before, h1 span.subtitle.content:after { content: "〜" ; }
レスありがとうございます。
>>195
文量を少なくするためあえてstyleを使いましたが、もちろん外部スタイルシートを使うつもりです。
>>196
たしかにそうやってからスタイルシートで順番をひっくり返すのが、見栄えと構造を切り離すという意味では
正解っぽいですね。ただ、上下をひっくり返すとなると、positionを使う事になるのかな…。
positionはあんまり好きじゃないんです。食わず嫌いみたいなものですが。
>>197
一応自分も実際は例4で作ってるのですが、<br>でおかしな事になったことがありますね。
ネスケで文字の一部が欠けてしまいました（汗）。
今回区切り記号をつけたのはただの気まぐれでしたが、なるほど、
>逆に、サブタイトルを区切る記号(この場合は「〜」)があればHTMLやスタイルシートでの明示が効かなくても大丈夫。
と言うのはその通りですね。
おまけの知識、参考になりました。ありがとうございます。
>>195
文量を少なくするためあえてstyleを使いましたが、もちろん外部スタイルシートを使うつもりです。
>>196
たしかにそうやってからスタイルシートで順番をひっくり返すのが、見栄えと構造を切り離すという意味では
正解っぽいですね。ただ、上下をひっくり返すとなると、positionを使う事になるのかな…。
positionはあんまり好きじゃないんです。食わず嫌いみたいなものですが。
>>197
一応自分も実際は例4で作ってるのですが、<br>でおかしな事になったことがありますね。
ネスケで文字の一部が欠けてしまいました（汗）。
今回区切り記号をつけたのはただの気まぐれでしたが、なるほど、
>逆に、サブタイトルを区切る記号(この場合は「〜」)があればHTMLやスタイルシートでの明示が効かなくても大丈夫。
と言うのはその通りですね。
おまけの知識、参考になりました。ありがとうございます。
199 ：Name_Not_Found：04/08/14 21:25 ID:???
>>197
tagクラスは物理的だから駄目
tagクラスは物理的だから駄目
200 ：Name_Not_Found：04/08/14 22:10 ID:???
>>191
いや、>>192 の言うように、Transitional の場合は、生テキストが
出てきた時点で、その位置にhead終了タグとbody開始タグが省略
されていると見なすべき。するとそこからはbody要素内なわけだから、
その内容を表示するのが正解。
だから、style要素を知らないUA（当然そんなUAはStrictも
知らない）は、style要素内容を本文として表示することになる。
それを防ぐためにコメントを付ける。コメント内部は無視される。
一方、style要素を知っているUAは、それがCDATA型要素だとも
知っている。CDATA型要素は内部にコメントが書かれていても、
それをコメントと解釈しない（そういう文字データだと解釈する）
仕様だからコメントにはならずに、CSSなどとして解釈される。
これでどちらのUAにも大丈夫という話なだけだが。
いや、>>192 の言うように、Transitional の場合は、生テキストが
出てきた時点で、その位置にhead終了タグとbody開始タグが省略
されていると見なすべき。するとそこからはbody要素内なわけだから、
その内容を表示するのが正解。
だから、style要素を知らないUA（当然そんなUAはStrictも
知らない）は、style要素内容を本文として表示することになる。
それを防ぐためにコメントを付ける。コメント内部は無視される。
一方、style要素を知っているUAは、それがCDATA型要素だとも
知っている。CDATA型要素は内部にコメントが書かれていても、
それをコメントと解釈しない（そういう文字データだと解釈する）
仕様だからコメントにはならずに、CSSなどとして解釈される。
これでどちらのUAにも大丈夫という話なだけだが。
201 ：Name_Not_Found：04/08/14 22:30 ID:???
>>200
どうでもいいが、style要素のなかったHTML2にも一応Strict DTDはある。
どうでもいいが、style要素のなかったHTML2にも一応Strict DTDはある。
202 ：Name_Not_Found：04/08/14 22:52 ID:???
203 ：Name_Not_Found：04/08/14 22:57 ID:???
>>199
「〜」がsubtitleを明示する区切りだからtagにしてみたんだけど、駄目？
「〜」がsubtitleを明示する区切りだからtagにしてみたんだけど、駄目？
204 ：Name_Not_Found：04/08/15 08:16 ID:???
形式だけStrictなページばっかりだ。
論理構造に全く関係のないデザインのためだけの<div>が
しょっちゅう見受けられる。
HTMLチェッカーに通したらStrictなんだろうが、
それはStrictにする意味があるのか全く持って不明。
論理構造に全く関係のないデザインのためだけの<div>が
しょっちゅう見受けられる。
HTMLチェッカーに通したらStrictなんだろうが、
それはStrictにする意味があるのか全く持って不明。
205 ：Name_Not_Found：04/08/15 08:18 ID:???
206 ：Name_Not_Found：04/08/15 09:48 ID:???
207 ：Name_Not_Found：04/08/15 11:23 ID:???
>>204
論理構造に関係のある div などない。
<div class="title">Strict-HTML スレッド22</div>
なら問題あるが、
<div class="title"><h1>Strict-HTML スレッド22</h1></div>
なら問題はない。
<div class="title1"><div class="title2"><h1>Strict-HTML スレッド22</h1></div></div>
でも構わないと思う。
俺は死んでもやらんが。
論理構造に関係のある div などない。
<div class="title">Strict-HTML スレッド22</div>
なら問題あるが、
<div class="title"><h1>Strict-HTML スレッド22</h1></div>
なら問題はない。
<div class="title1"><div class="title2"><h1>Strict-HTML スレッド22</h1></div></div>
でも構わないと思う。
俺は死んでもやらんが。
208 ： ◆LLLLLLLLL. ：04/08/15 11:31 ID:???
ほぇぇぇ
209 ：Name_Not_Found：04/08/15 11:40 ID:???
>>207
>論理構造に関係のある div などない。
面倒だからおまいの書き込みしか見てない。で、とりあえずあまりアフォなことは言うな。
まずは仕様書読め。divを使っての構造化が仕様書の中でどういうふうに書かれてるかを
自力で探して嫁。俺様ルールで
>論理構造に関係のある div などない。
とかいうアフォなことをこのスレで言うなよ。とりあえずお前はこっちのスレだ。
http://pc5.2ch.net/test/read.cgi/hp/1086686223/l50
ここの1を熟読しろ。
>論理構造に関係のある div などない。
面倒だからおまいの書き込みしか見てない。で、とりあえずあまりアフォなことは言うな。
まずは仕様書読め。divを使っての構造化が仕様書の中でどういうふうに書かれてるかを
自力で探して嫁。俺様ルールで
>論理構造に関係のある div などない。
とかいうアフォなことをこのスレで言うなよ。とりあえずお前はこっちのスレだ。
http://pc5.2ch.net/test/read.cgi/hp/1086686223/l50
ここの1を熟読しろ。
210 ：Name_Not_Found：04/08/15 11:54 ID:???
最近意味のわからない発言が増えてきた
211 ：Name_Not_Found：04/08/15 13:11 ID:???
地道な啓蒙活動の成果でしょ。人口増加になかなか質が伴わなくても仕方ない。
212 ：Name_Not_Found：04/08/15 21:52 ID:???
まあぶっちゃけdiv要素なんてサイトのオーサにとってだけの
セマンティックなわけで、他に利用者がいなければばんばん
デザインに使っても支障も糞もないわけですよ。おちんちん舐めたい。
セマンティックなわけで、他に利用者がいなければばんばん
デザインに使っても支障も糞もないわけですよ。おちんちん舐めたい。
213 ：Name_Not_Found：04/08/15 22:36 ID:???
魚が沢山
214 ：Name_Not_Found：04/08/16 14:58 ID:???
質問なんですが、掲示板なんかの投稿フォームを作る場合
1.<p>を使う
<form>
<p><label>名前</label><input type="text"></p>
<p><label>メッセージ</label><input type="text"></p>
</form>
2.<ul>を使う
<form>
<ul>
<li><label>名前</label><input type="text"></li>
<li><label>メッセージ</label><input type="text"></li>
</ul>
</form>
3.<dl>を使う
<form>
<dl>
<dt><label>名前</label></dt><dd><input type="text"></dd>
<dt><label>メッセージ</label></dt><dd><input type="text"></dd>
</dl>
</form>
どれが一番正しい書き方ですか？
もしくはもっとこうした方がいいとかありますかね。
1.<p>を使う
<form>
<p><label>名前</label><input type="text"></p>
<p><label>メッセージ</label><input type="text"></p>
</form>
2.<ul>を使う
<form>
<ul>
<li><label>名前</label><input type="text"></li>
<li><label>メッセージ</label><input type="text"></li>
</ul>
</form>
3.<dl>を使う
<form>
<dl>
<dt><label>名前</label></dt><dd><input type="text"></dd>
<dt><label>メッセージ</label></dt><dd><input type="text"></dd>
</dl>
</form>
どれが一番正しい書き方ですか？
もしくはもっとこうした方がいいとかありますかね。
215 ：Name_Not_Found：04/08/16 15:03 ID:???
StrictなHTMLは
文章
を書くための仕様なわけです。
文章
にはフォームなんて存在し得ない訳なんです。
ですから、
>>214
さんのばあいは、どれにするにせよ、Strictからは
はずれるでしょう。
文法的にはどれでもいいので
好きにしてください。
文章
を書くための仕様なわけです。
文章
にはフォームなんて存在し得ない訳なんです。
ですから、
>>214
さんのばあいは、どれにするにせよ、Strictからは
はずれるでしょう。
文法的にはどれでもいいので
好きにしてください。
216 ：Name_Not_Found：04/08/16 15:08 ID:???
217 ：Name_Not_Found：04/08/16 15:10 ID:???
>>214
というわけで<div>を使えばよろし。
というわけで<div>を使えばよろし。
218 ：Name_Not_Found：04/08/16 15:23 ID:???
>>214
fieldset と legend も使うといいかもよ。
fieldset と legend も使うといいかもよ。
219 ：Name_Not_Found：04/08/16 15:23 ID:???
例えばテストの解答用紙はフォームなのだが、あれはだめなのかね。
220 ：Name_Not_Found：04/08/16 15:24 ID:???
221 ：Name_Not_Found：04/08/16 15:29 ID:???
>>218
<form method="post" action="test.cgi">
<hn>第一問</hn>
<p>1個120円のリンゴを3つ買うには、いくら必要ですか？</p>
<dl>
<dt>答え</dt>
<dd><input type="text" name="hoge" size="7" value=""></dd>
</dl>
</form>
でよろし。
<form method="post" action="test.cgi">
<hn>第一問</hn>
<p>1個120円のリンゴを3つ買うには、いくら必要ですか？</p>
<dl>
<dt>答え</dt>
<dd><input type="text" name="hoge" size="7" value=""></dd>
</dl>
</form>
でよろし。
222 ：Name_Not_Found：04/08/16 15:42 ID:???
>>221
fieldset と legend は要らないって考え？確かに、見出しとセクションで済むんだが。
fieldset と legend は要らないって考え？確かに、見出しとセクションで済むんだが。
223 ：Name_Not_Found：04/08/16 18:03 ID:???
224 ：Name_Not_Found：04/08/16 18:42 ID:???
225 ：Name_Not_Found：04/08/16 22:52 ID:???
226 ：Name_Not_Found：04/08/16 23:05 ID:???
自称Strict信者の反感をかってるようだ。
227 ：Name_Not_Found：04/08/17 00:39 ID:???
>>226
どこに自称してるレスがあるの？
どこに自称してるレスがあるの？
228 ：Name_Not_Found：04/08/17 01:44 ID:???
行間じゃない？
229 ：Name_Not_Found：04/08/17 11:50 ID:???
line-height:自称Strict信者;
しかし line-height プロパティは行間を意味しなかった！
しかし line-height プロパティは行間を意味しなかった！
230 ：Name_Not_Found：04/08/17 12:21 ID:???
>>229
何がいいたいんだ？
何がいいたいんだ？
231 ：Name_Not_Found：04/08/17 12:51 ID:???
RPG風に喋りたかったんじゃないかな
232 ：Name_Not_Found：04/08/17 13:02 ID:???
<div>
∧＿∧<br>
（ ´∀｀） ＜ ぬるぽ<br>
</div>
∧＿∧<br>
（ ´∀｀） ＜ ぬるぽ<br>
</div>
233 ：Name_Not_Found：04/08/17 13:16 ID:???
>>231
他所でやればいいのにね。
他所でやればいいのにね。
234 ：Name_Not_Found：04/08/17 16:08 ID:???
本当最近はStrictを変に解釈してる人が多いね。
235 ：Name_Not_Found：04/08/17 17:11 ID:???
はじめにテキストありき説の人としてはsubmitボタンは悩ましいところだと思うんだけどどうよ。
236 ：Name_Not_Found：04/08/17 18:27 ID:???
>>235
具体的にどう悩ましいのかをコード例と共に示せ
具体的にどう悩ましいのかをコード例と共に示せ
237 ：Name_Not_Found：04/08/17 18:30 ID:???
いずれにせよこの規格、不完全なところが多いな。
まあ、ハイパーテキストやwebっていう新しい概念だから
しょうがないか。
長い目で見守ろう。
まあ、ハイパーテキストやwebっていう新しい概念だから
しょうがないか。
長い目で見守ろう。
238 ：Name_Not_Found：04/08/17 20:02 ID:???
ハイパーテキストって割と古かった記憶が。
239 ：Name_Not_Found：04/08/17 21:12 ID:???
240 ：Name_Not_Found：04/08/17 22:01 ID:???
241 ：Name_Not_Found：04/08/17 22:01 ID:???
>>238
「テキスト」がどのくらいの歴史をもってるかわかってる？
「テキスト」がどのくらいの歴史をもってるかわかってる？
242 ：Name_Not_Found：04/08/17 22:25 ID:???
（*´д｀*）またスレが面白い方向に…
243 ：Name_Not_Found：04/08/17 22:26 ID:???
Strict-HTML スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/
http://pc5.2ch.net/test/read.cgi/hp/1092053733/
244 ：Name_Not_Found：04/08/17 23:13 ID:???
>>237
またバカが来たよ
またバカが来たよ
245 ：Name_Not_Found：04/08/18 00:29 ID:???
そこを放置ですよ。
246 ：Name_Not_Found：04/08/18 01:13 ID:???
247 ：Name_Not_Found：04/08/18 09:36 ID:???
>>246
<hn>をうまく使えればdivはなくても事足りるが、divを使うともっと再利用性の高いHTMLにできるってことだ。
<hn>をうまく使えればdivはなくても事足りるが、divを使うともっと再利用性の高いHTMLにできるってことだ。
248 ：Name_Not_Found：04/08/18 11:11 ID:???
なんつーかなー
249 ：Name_Not_Found：04/08/18 18:34 ID:???
嫌DIV厨はいい加減氏んだほうがいい。
250 ：Name_Not_Found：04/08/18 18:38 ID:???
>>249
あいつらのせいでStrictの普及が遅れてるよな。
divのおかしな使い方でもとりあえずテーブルレイアウトからCSSれいあうとに移行しさえすれば
後はゆっくりStrictになってくはず。
だからdiv厨とテブル厨は五分！とか言ってるやつはテブルを支援しているに他ならない。
とりあえずCSSレイアウトさえできるようになれば、HTMLをStrictに書くときに弊害は少ないと思われ。
あいつらのせいでStrictの普及が遅れてるよな。
divのおかしな使い方でもとりあえずテーブルレイアウトからCSSれいあうとに移行しさえすれば
後はゆっくりStrictになってくはず。
だからdiv厨とテブル厨は五分！とか言ってるやつはテブルを支援しているに他ならない。
とりあえずCSSレイアウトさえできるようになれば、HTMLをStrictに書くときに弊害は少ないと思われ。
251 ：Name_Not_Found：04/08/18 18:49 ID:???
Strict普及してなんかいいことあるの？
自己満足サークル野中だけで発言しておいてよ。
自己満足サークル野中だけで発言しておいてよ。
252 ：Name_Not_Found：04/08/18 19:04 ID:???
自己満足サークル野中でそんなこと言われても…
253 ：Name_Not_Found：04/08/18 19:08 ID:???
野中・バーナーズリー
254 ：Name_Not_Found：04/08/18 21:13 ID:???
のなたん…
255 ：Name_Not_Found：04/08/18 23:15 ID:???
>>250
それは「div厨」の定義の問題でしょ。と敢えて言ってみる。
それは「div厨」の定義の問題でしょ。と敢えて言ってみる。
256 ：Name_Not_Found：04/08/19 00:04 ID:???
>>255
悪いdivはたしかにあるけど、それを放置することはCSSレイアウトの普及につながる。
いきなりStrictHTML+CSSレイアウトを叫んだところであほらしいから、とりあえずはCSSを推奨し、
悪いdivを放置しておけばいい。悪いdivでCSSに慣れたらStrictHTML自体は難しくないから
それほど苦もなく進めるってこと。
まあこのスレ的にはそんなこと関係ないからしょうがないけど、とりあえず
Strict+CSS ＞＞ クソdiv+CSS ＞＞ テーブルレイアウト
の順にしてあまりdiv厨を叩き過ぎないようにしとこう。
悪いdivはたしかにあるけど、それを放置することはCSSレイアウトの普及につながる。
いきなりStrictHTML+CSSレイアウトを叫んだところであほらしいから、とりあえずはCSSを推奨し、
悪いdivを放置しておけばいい。悪いdivでCSSに慣れたらStrictHTML自体は難しくないから
それほど苦もなく進めるってこと。
まあこのスレ的にはそんなこと関係ないからしょうがないけど、とりあえず
Strict+CSS ＞＞ クソdiv+CSS ＞＞ テーブルレイアウト
の順にしてあまりdiv厨を叩き過ぎないようにしとこう。
257 ：Name_Not_Found：04/08/19 00:05 ID:???
XSLT使ってるとdivが否定される理由があんまり関係なくなる
258 ：Name_Not_Found：04/08/19 00:16 ID:???
>>256
確かに、テーブルレイアウトやってるやつに「構造とプレゼンテーションの分離」とか言っても
理解しないだろうしね。
まずdivで弄って、それから、CSSの為のdivでは本質的にはテーブルレイアウトと変わらんと言うところに行き着けば良いと思う。
確かに、テーブルレイアウトやってるやつに「構造とプレゼンテーションの分離」とか言っても
理解しないだろうしね。
まずdivで弄って、それから、CSSの為のdivでは本質的にはテーブルレイアウトと変わらんと言うところに行き着けば良いと思う。
259 ：Name_Not_Found：04/08/19 00:51 ID:???
h1とかpとか、変に略してるから難しいように見えるんだよね。
教えるときには見出しとか段落とか、略さずにかつ日本語で書いてあるのから入れば良い。
って既出だが。
教えるときには見出しとか段落とか、略さずにかつ日本語で書いてあるのから入れば良い。
って既出だが。
260 ：Name_Not_Found：04/08/19 01:26 ID:???
結局は「HTMLなんて知らなくてもホムペ開設出来るよ！」てな商売が元凶だと思われ。
まぁ実際に開設できる訳で、そこから、なんでちゃんと表示できてるのにケチ付けるの？と言う疑問が生まれるのであって……。
敷居を下げすぎた（ように見せかけた）のがまずかったな。某WYSIWYGソフトを筆頭に。
勉強しなくても誰にでも簡単に扱えるもの、と言う意識が蔓延してる以上、なかなかどうして。
まぁ実際に開設できる訳で、そこから、なんでちゃんと表示できてるのにケチ付けるの？と言う疑問が生まれるのであって……。
敷居を下げすぎた（ように見せかけた）のがまずかったな。某WYSIWYGソフトを筆頭に。
勉強しなくても誰にでも簡単に扱えるもの、と言う意識が蔓延してる以上、なかなかどうして。
261 ：Name_Not_Found：04/08/19 02:22 ID:???
そのWYSIWYGソフトの作者達も禄すっぽHTMLを理解していなかったようで、
どう見ても左マージンを表すようなアイコンをクリックすると挿入される
コードはblockquoteとか昔はあったなぁ（最近のは知らない）。
Strictとか仕様上完璧とは言わないまでも、せめてvalidなHTMLを出力する
blogがメジャーになる事を祈ろう。
…せめてxslt可能な規則性のある整形済みxml文書にっっっ！！！（カイジ風）
どう見ても左マージンを表すようなアイコンをクリックすると挿入される
コードはblockquoteとか昔はあったなぁ（最近のは知らない）。
Strictとか仕様上完璧とは言わないまでも、せめてvalidなHTMLを出力する
blogがメジャーになる事を祈ろう。
…せめてxslt可能な規則性のある整形済みxml文書にっっっ！！！（カイジ風）
262 ：Name_Not_Found：04/08/19 02:27 ID:???
あの漢字三文字のお方もマージンにblockquoteを（ｒｙ
まあ、素人が作りやすくなった分、情報も増えたのはいいんだけどね…
かくいう俺も昔は間違ったマークアップやってたなあ…
最初からちゃんとマークアップできていた人っているのかなあ？
（純粋な疑問。）ちと、気になる。
まあ、素人が作りやすくなった分、情報も増えたのはいいんだけどね…
かくいう俺も昔は間違ったマークアップやってたなあ…
最初からちゃんとマークアップできていた人っているのかなあ？
（純粋な疑問。）ちと、気になる。
263 ：Name_Not_Found：04/08/19 03:02 ID:???
>>262
HTMLを書き始めて1ヶ月くらいでAHLに出逢って、それ以後Strict。
HTMLを書き始めて1ヶ月くらいでAHLに出逢って、それ以後Strict。
264 ：Name_Not_Found：04/08/19 04:53 ID:???
おまえらのオナニーを他人に強要するのはどうかとおもうぞ。
265 ：Name_Not_Found：04/08/19 09:00 ID:???
誰も強要していないが…？ エセ信者に騙されたのか？
266 ：Name_Not_Found：04/08/19 11:37 ID:???
ここはStrict被害者の会となりました。
267 ：Name_Not_Found：04/08/19 16:50 ID:???
>>266
バカじゃん
バカじゃん
268 ：Name_Not_Found：04/08/19 17:09 ID:???
バカに言われた。
269 ：Name_Not_Found：04/08/19 23:06 ID:???
馬鹿バッカ
270 ：Name_Not_Found：04/08/20 00:00 ID:???
Strictバカばっか
でもかわいいよStrict
でもかわいいよStrict
271 ：Name_Not_Found：04/08/20 01:59 ID:???
Strictたんﾊｧﾊｧ
272 ：Name_Not_Found：04/08/20 09:09 ID:???
俺たちは不器用だからな・・Ｓｔｒｉｃｔな生き方しか選べないんだ
273 ：Name_Not_Found：04/08/20 09:13 ID:???
>>272
お前と一緒にするなキモイ
お前と一緒にするなキモイ
274 ：Name_Not_Found：04/08/20 09:16 ID:???
275 ：Name_Not_Found：04/08/20 09:42 ID:???
俺の人生divだらけ
276 ：Name_Not_Found：04/08/20 10:37 ID:???
俺の人生には終了タグの省略は許されない
277 ：Name_Not_Found：04/08/20 12:07 ID:???
開始タグが省略されてしまった。
278 ：Name_Not_Found：04/08/20 12:39 ID:???
／￣￣＼
/ ┼ ヽ
│ |
│</LIFE> |.....
│ |::::::
│ |:::
└───..┘
279 ：Name_Not_Found：04/08/20 12:41 ID:???
独自拡張要素を使うな
280 ：Name_Not_Found：04/08/20 17:57 ID:???
だんだんヲタスレになってきたな
281 ：Name_Not_Found：04/08/20 18:02 ID:???
>>278-279
あ、ほら、html じゃないかもしれないし。
あ、ほら、html じゃないかもしれないし。
282 ：Name_Not_Found：04/08/20 18:19 ID:???
283 ：Name_Not_Found：04/08/20 19:46 ID:???
>>281
ここはStrict-HTMLスレだよボケ
ここはStrict-HTMLスレだよボケ
284 ：Name_Not_Found：04/08/20 21:07 ID:???
>>283
xml系のhtmlもある。
xml系のhtmlもある。
285 ：Name_Not_Found：04/08/21 01:05 ID:???
それではちょっと話題投下。
小説などで、日本語の書式にのっとって人物の台詞を改行したい場合。
例
<p>男はふりかえり、<span class="hatugenn">「おまえは！」</span>と叫んだ。</p>
.hatugen｛display:block;}
でいいよね？他スレでこの話題が出て、ちょっと気になってたんだ。
小説などで、日本語の書式にのっとって人物の台詞を改行したい場合。
例
<p>男はふりかえり、<span class="hatugenn">「おまえは！」</span>と叫んだ。</p>
.hatugen｛display:block;}
でいいよね？他スレでこの話題が出て、ちょっと気になってたんだ。
286 ：Name_Not_Found：04/08/21 01:10 ID:???
いいよ。
287 ：Name_Not_Found：04/08/21 01:11 ID:???
CSS込みで「いいよね？」ってのはスレの趣旨と微妙に違う気がするが。
単なる視覚効果ならそのマークアップでいいとは思うが、
日本語の小説で会話文前後改行は意味があるとする人もいるしなぁ。
単なる視覚効果ならそのマークアップでいいとは思うが、
日本語の小説で会話文前後改行は意味があるとする人もいるしなぁ。
288 ：Name_Not_Found：04/08/21 01:12 ID:???
289 ：Name_Not_Found：04/08/21 01:22 ID:???
そりゃひどいよストリクター
290 ：Name_Not_Found：04/08/21 01:23 ID:???
サイト作者が発言だと思ってんだったら
mankoでも良し
mankoでも良し
7分で３レスとはw
>>287
漏れは改行は視覚効果だと思うんだがなあ。意味があるとして、どういうマークアップにする？
台詞は段落の中にあるものなので、この改行は明らかに「段落」ではないよな？
>>288
…ウチマチガイデツ…or2
>>287
漏れは改行は視覚効果だと思うんだがなあ。意味があるとして、どういうマークアップにする？
台詞は段落の中にあるものなので、この改行は明らかに「段落」ではないよな？
>>288
…ウチマチガイデツ…or2
292 ：Name_Not_Found：04/08/21 01:25 ID:???
そしてhatsugenかhatugenかでこの後20レスほど続く予定です
293 ：Name_Not_Found：04/08/21 01:25 ID:???
こういう id や class の属性値を意味付けするための仕様かノートか何か出ないかしら。
294 ：Name_Not_Found：04/08/21 01:29 ID:???
むしろ
hatugeng
hatugeng
>>291
<p>
男はふりかえり、<br />
「おまえは！」<br />
と叫んだ。
</p>
改行が意味を持つものかどうか？は最終的には自分で判断すればいいんだが。
俺だったらこうする、程度。
<p>
しかし二人は
<span class="hatugeng">「まだ？」</span>
<span class="hatugeng">「まだだよ」</span>
<span class="hatugeng">「まだ？」</span>
<span class="hatugeng">「まだだって」</span>
という会話を繰り返すばかりだった。
</p>
これは違うと思うんだよなぁ。
<p>
男はふりかえり、<br />
「おまえは！」<br />
と叫んだ。
</p>
改行が意味を持つものかどうか？は最終的には自分で判断すればいいんだが。
俺だったらこうする、程度。
<p>
しかし二人は
<span class="hatugeng">「まだ？」</span>
<span class="hatugeng">「まだだよ」</span>
<span class="hatugeng">「まだ？」</span>
<span class="hatugeng">「まだだって」</span>
という会話を繰り返すばかりだった。
</p>
これは違うと思うんだよなぁ。
根拠が曖昧なことばかりで申し訳ないんだが、
そもそも文学を見栄えと構造に完全分離なんて無理だと思うんだよな。
例えば四十字詰め原稿用紙を対象に書かれた文章で、
行頭の文字だけつなげて読むと別の意味を含ませてあるとかさ。
紙媒体限定で生産されたから当然だとか pre 使えとかあるだろうけど、
書いた人にとっちゃどこで改行されるかも重要な要素かも知れないわけで。
アーティスティックな部分には足踏み入れても不毛になるだけかも知れん。
そもそも文学を見栄えと構造に完全分離なんて無理だと思うんだよな。
例えば四十字詰め原稿用紙を対象に書かれた文章で、
行頭の文字だけつなげて読むと別の意味を含ませてあるとかさ。
紙媒体限定で生産されたから当然だとか pre 使えとかあるだろうけど、
書いた人にとっちゃどこで改行されるかも重要な要素かも知れないわけで。
アーティスティックな部分には足踏み入れても不毛になるだけかも知れん。
297 ：Name_Not_Found：04/08/21 03:09 ID:???
>>296
ソッスネ
ソッスネ
298 ：Name_Not_Found：04/08/21 03:30 ID:???
>>296
FA
FA
299 ：Name_Not_Found：04/08/21 03:39 ID:???
>>296
本題とはちょっとずれたところに突っ込むことになるような気もするけど、
折り返し行の頭を読んでいくっていうのはつまりn文字飛ばしで読んでいくってことなんだよね。
原稿用紙の幅というか高さというか、あれがnの値のヒントになってるという。
普通の行の頭だったら、つまり改行文字の直後と同じ。
改行がヒントになるのは目立つからであって、例えば画数の多い漢字でも良い。
こけしやたぬきのあれみたいなやつ。
……結局何が言いたかったんだっけ。
しかも意味不明だし。orz
本題とはちょっとずれたところに突っ込むことになるような気もするけど、
折り返し行の頭を読んでいくっていうのはつまりn文字飛ばしで読んでいくってことなんだよね。
原稿用紙の幅というか高さというか、あれがnの値のヒントになってるという。
普通の行の頭だったら、つまり改行文字の直後と同じ。
改行がヒントになるのは目立つからであって、例えば画数の多い漢字でも良い。
こけしやたぬきのあれみたいなやつ。
……結局何が言いたかったんだっけ。
しかも意味不明だし。orz
>>299
>折り返し行の頭を読んでいくっていうのはつまりn文字飛ばしで読んでいくってことなんだよね。
いや、最大でも n 文字以内には次に読むべき文字が現れるけれど、
原稿用紙の幅による改行によって次の文字が現れるのか、
それとも意図的な改行によって次の文字が現れるのかはわからない、
という状況を想定した方がより（文学 → 構造化の困難さを）わかりやすいと思う。
要は縦読みとか想像してくれたらいいんだけども。
で、何の話題だこれ？
>折り返し行の頭を読んでいくっていうのはつまりn文字飛ばしで読んでいくってことなんだよね。
いや、最大でも n 文字以内には次に読むべき文字が現れるけれど、
原稿用紙の幅による改行によって次の文字が現れるのか、
それとも意図的な改行によって次の文字が現れるのかはわからない、
という状況を想定した方がより（文学 → 構造化の困難さを）わかりやすいと思う。
要は縦読みとか想像してくれたらいいんだけども。
で、何の話題だこれ？
301 ：Name_Not_Found：04/08/21 04:05 ID:???
>296
> 例えば四十字詰め原稿用紙を対象に書かれた文章で、
> 行頭の文字だけつなげて読むと別の意味を含ませてあるとかさ。
それって「整形済み」ってことじゃないのか？
> 例えば四十字詰め原稿用紙を対象に書かれた文章で、
> 行頭の文字だけつなげて読むと別の意味を含ませてあるとかさ。
それって「整形済み」ってことじゃないのか？
302 ：Name_Not_Found：04/08/21 04:07 ID:???
>>300
あー、それそれ。
ちょっと思い出したにょ：
要するに、何もマークアップ(広義の、原稿用紙における改行や字下げを含む)
によって明示する必要が必ずしもあるとは限らないんじゃないの、みたいな。
赤い字の次を読んでいくっていうのもありだろうけど、別に赤じゃなくても何でも良いじゃん、
という一見ストリクター風みたいな発想とかを連想してくれたらいぇぃ☆？
あー、それそれ。
ちょっと思い出したにょ：
要するに、何もマークアップ(広義の、原稿用紙における改行や字下げを含む)
によって明示する必要が必ずしもあるとは限らないんじゃないの、みたいな。
赤い字の次を読んでいくっていうのもありだろうけど、別に赤じゃなくても何でも良いじゃん、
という一見ストリクター風みたいな発想とかを連想してくれたらいぇぃ☆？
303 ：Name_Not_Found：04/08/21 04:10 ID:???
>>302
まず日本語を直せ
まず日本語を直せ
304 ：Name_Not_Found：04/08/21 04:32 ID:???
>>302
日本語以外の言葉で意味不明なことを言わないでくれ…。
>>295
これは自分の解釈だが、改行は改行として現時点ではマークアップするべきだと思う。
また、発言をhatugeng値を持ったspan要素でマークアップするという制作者の方針はかまわないが、
だからといって「改行のためのspan要素」は許容されない。
自分なら、発言をhatugeng値を持ったspan要素でマークアップする方針に従うとして、
次のようにマークアップすると思う。
<p>
しかし二人は<br />
<span class="hatugeng">「まだ？」</span><br />
<span class="hatugeng">「まだだよ」</span><br />
<span class="hatugeng">「まだ？」</span><br />
<span class="hatugeng">「まだだって」</span><br />
という会話を繰り返すばかりだった。
</p>
つーか、話の流れが読めないな。結局のところ、主題は何。
日本語以外の言葉で意味不明なことを言わないでくれ…。
>>295
これは自分の解釈だが、改行は改行として現時点ではマークアップするべきだと思う。
また、発言をhatugeng値を持ったspan要素でマークアップするという制作者の方針はかまわないが、
だからといって「改行のためのspan要素」は許容されない。
自分なら、発言をhatugeng値を持ったspan要素でマークアップする方針に従うとして、
次のようにマークアップすると思う。
<p>
しかし二人は<br />
<span class="hatugeng">「まだ？」</span><br />
<span class="hatugeng">「まだだよ」</span><br />
<span class="hatugeng">「まだ？」</span><br />
<span class="hatugeng">「まだだって」</span><br />
という会話を繰り返すばかりだった。
</p>
つーか、話の流れが読めないな。結局のところ、主題は何。
>>301
つうことは、世に溢れるポエムサイト（わらい）なんかの多くは
pre でマークアップされるべきってことになるのかね。
>>304
>結局のところ、主題は何。
>>285 が Strict なマークアップかどうか？ってことだけど、
暗に「br 要素で改行するべきか？」ってことかと。自己判断でいいんじゃねぇかと。
つうことは、世に溢れるポエムサイト（わらい）なんかの多くは
pre でマークアップされるべきってことになるのかね。
>>304
>結局のところ、主題は何。
>>285 が Strict なマークアップかどうか？ってことだけど、
暗に「br 要素で改行するべきか？」ってことかと。自己判断でいいんじゃねぇかと。
（故意にスルーしたんでなくて忘れてた）
>>302
>要するに、何もマークアップ(広義の、原稿用紙における改行や字下げを含む)
>によって明示する必要が必ずしもあるとは限らないんじゃないの、みたいな。
いや、じゃ何によって明示するんだって話になりますが。
（明示する対象が UA かソースを読む人間か、ってのはひとまず置いといて）
>赤い字の次を読んでいくっていうのもありだろうけど、別に赤じゃなくても何でも良いじゃん、
>という一見ストリクター風みたいな発想とかを連想してくれたらいぇぃ☆？
赤い字ってのは例えだよね？
つうか前提の発想がよくわからんし、「何でも良い」は Strict ではないと思われ。
n 番目の文字は n 番目の文字として明示すればそれで済むことだし、
赤い字かどうかは知ったこっちゃないが、n 番目の文字として明示しなければいけない。
相手する俺がアホか？
>>302
>要するに、何もマークアップ(広義の、原稿用紙における改行や字下げを含む)
>によって明示する必要が必ずしもあるとは限らないんじゃないの、みたいな。
いや、じゃ何によって明示するんだって話になりますが。
（明示する対象が UA かソースを読む人間か、ってのはひとまず置いといて）
>赤い字の次を読んでいくっていうのもありだろうけど、別に赤じゃなくても何でも良いじゃん、
>という一見ストリクター風みたいな発想とかを連想してくれたらいぇぃ☆？
赤い字ってのは例えだよね？
つうか前提の発想がよくわからんし、「何でも良い」は Strict ではないと思われ。
n 番目の文字は n 番目の文字として明示すればそれで済むことだし、
赤い字かどうかは知ったこっちゃないが、n 番目の文字として明示しなければいけない。
相手する俺がアホか？
307 ：Name_Not_Found：04/08/21 06:33 ID:???
>>304
＞だからといって「改行のためのspan要素」は許容されない。
じゃあ、著者が心底（改行とは全く無関係に）台詞箇所を明示したくて、
しかし、台詞用要素が無いのでspan+classでとりあえずmarkupして、
CSSにおいて原稿用紙ライクな見栄え（たまたま改行）を与えるのは
問題ない訳ね。
＞だからといって「改行のためのspan要素」は許容されない。
じゃあ、著者が心底（改行とは全く無関係に）台詞箇所を明示したくて、
しかし、台詞用要素が無いのでspan+classでとりあえずmarkupして、
CSSにおいて原稿用紙ライクな見栄え（たまたま改行）を与えるのは
問題ない訳ね。
308 ：Name_Not_Found：04/08/21 06:35 ID:???
＞相手する俺がアホか？
相手するのがアホかどうかは知らないが、
すくなくとも過去ログ読む能力がなかったり、スルーする能力が無い事は解った。
287 のみならず、この話題の参加者全員がな。俺を含めてな。
>>
相手するのがアホかどうかは知らないが、
すくなくとも過去ログ読む能力がなかったり、スルーする能力が無い事は解った。
287 のみならず、この話題の参加者全員がな。俺を含めてな。
>>
309 ：Name_Not_Found：04/08/21 06:43 ID:???
>>307
> しかし、台詞用要素が無いのでspan+classでとりあえずmarkupして、
> CSSにおいて原稿用紙ライクな見栄え（たまたま改行）を与えるのは
> 問題ない訳ね。
CSSの指定の仕方はここの範囲外だから、ここで聞くのもどうかと思うよ。
簡潔に「セリフと明示するためにspan使っていい訳ね」でいいだろ。
しかし、台詞用要素って言うけどさ、日本語における、「と」ってのは引用（誰か（自分含む）が言った言葉）なわけだから、
q要素だ、と言えばq要素だよな。
> しかし、台詞用要素が無いのでspan+classでとりあえずmarkupして、
> CSSにおいて原稿用紙ライクな見栄え（たまたま改行）を与えるのは
> 問題ない訳ね。
CSSの指定の仕方はここの範囲外だから、ここで聞くのもどうかと思うよ。
簡潔に「セリフと明示するためにspan使っていい訳ね」でいいだろ。
しかし、台詞用要素って言うけどさ、日本語における、「と」ってのは引用（誰か（自分含む）が言った言葉）なわけだから、
q要素だ、と言えばq要素だよな。
>>309
>CSSの指定の仕方はここの範囲外だから、ここで聞くのもどうかと思うよ。
自分の書き込みは
>だからといって「改行のためのspan要素」は許容されない。
に対する書き込みなのであってCSSの指定方法など話しては居ない。
>台詞用要素って言うけどさ、日本語における、「と」ってのは
>引用（誰か（自分含む）が言った言葉）なわけだから、
>q要素だ、と言えばq要素だよな。
自分が完全に創作した小説のキャラクタの台詞がq要素とはとても思えない。
引用であり台詞である要素の場合は当然q要素だが、引用ではない台詞もあり得る。
>CSSの指定の仕方はここの範囲外だから、ここで聞くのもどうかと思うよ。
自分の書き込みは
>だからといって「改行のためのspan要素」は許容されない。
に対する書き込みなのであってCSSの指定方法など話しては居ない。
>台詞用要素って言うけどさ、日本語における、「と」ってのは
>引用（誰か（自分含む）が言った言葉）なわけだから、
>q要素だ、と言えばq要素だよな。
自分が完全に創作した小説のキャラクタの台詞がq要素とはとても思えない。
引用であり台詞である要素の場合は当然q要素だが、引用ではない台詞もあり得る。
311 ：Name_Not_Found：04/08/21 06:55 ID:???
それがないと >>304 への返事にならないってはっきり言ったの。
313 ：Name_Not_Found：04/08/21 07:17 ID:???
スルーできないバカ発生注意報
314 ：Name_Not_Found：04/08/21 07:31 ID:???
>>312
言葉を置き換えれば解ると思うが、
＞だからといって「改行のためのspan要素」は許容されない。
だからといって「見栄えのためのspan要素」は許容されない。
>>307は「「見栄え」じゃないもの」を示してるんだから、「許容されない」と言った発言に掛かってない。
言葉を置き換えれば解ると思うが、
＞だからといって「改行のためのspan要素」は許容されない。
だからといって「見栄えのためのspan要素」は許容されない。
>>307は「「見栄え」じゃないもの」を示してるんだから、「許容されない」と言った発言に掛かってない。
315 ：Name_Not_Found：04/08/21 07:32 ID:???
>>313は理解できず参加できないバカ
316 ：Name_Not_Found：04/08/21 07:36 ID:???
お前ら朝から盛んですね
317 ：Name_Not_Found：04/08/21 07:37 ID:???
>>316
人によって生活サイクルが違う、とか想像できんわけだ。
人によって生活サイクルが違う、とか想像できんわけだ。
318 ：Name_Not_Found：04/08/21 07:59 ID:???
なんで無駄に噛み付くかな。良いとも悪いとも言ってないし、今が朝なのは事実だろ。
朝は一般的に一日の始まりとされるから「朝 *から*」という表現に不自然な点はないしな。
一般的な生活サイクル、夜寝て朝に起きる、とか想像できんわけだ。
朝は一般的に一日の始まりとされるから「朝 *から*」という表現に不自然な点はないしな。
一般的な生活サイクル、夜寝て朝に起きる、とか想像できんわけだ。
319 ：Name_Not_Found：04/08/21 08:01 ID:???
spanで囲むならカギ括弧はCSSで付けるべきだ。
q要素の例を考えても、範囲をHTMLで表現して、
視覚的区別はCSSで定義すべきだと考えられる。
q要素の例を考えても、範囲をHTMLで表現して、
視覚的区別はCSSで定義すべきだと考えられる。
320 ：Name_Not_Found：04/08/21 08:03 ID:???
前にも出てたような気がするが、究極突き詰めてマークアップするとなると
主語やら述語やらもタグで挟むことになるんかね。
主語やら述語やらもタグで挟むことになるんかね。
321 ：Name_Not_Found：04/08/21 08:12 ID:???
>>318
> なんで無駄に噛み付くかな。良いとも悪いとも言ってないし、
悪意のある発言、ってのがわからんのね。字面しか読めない。だから他人にも無神経な発言をする。
最悪なタイプの人間だよ。しかも手遅れ。
> なんで無駄に噛み付くかな。良いとも悪いとも言ってないし、
悪意のある発言、ってのがわからんのね。字面しか読めない。だから他人にも無神経な発言をする。
最悪なタイプの人間だよ。しかも手遅れ。
322 ：Name_Not_Found：04/08/21 08:15 ID:???
>>320
>究極突き詰めてマークアップするとなると
>主語やら述語やらもタグで挟むことになるんかね。
究極突き詰めたマークアップ言語ではそうなるが、
HTMLはもっと大ざっぱな文書構造をマークアップする言語なので
そうならない。HTMLにおいて究極突き詰めたい奴は汎用属性つかって
勝手にやればいいじゃない、程度におおらか。
>究極突き詰めてマークアップするとなると
>主語やら述語やらもタグで挟むことになるんかね。
究極突き詰めたマークアップ言語ではそうなるが、
HTMLはもっと大ざっぱな文書構造をマークアップする言語なので
そうならない。HTMLにおいて究極突き詰めたい奴は汎用属性つかって
勝手にやればいいじゃない、程度におおらか。
323 ：Name_Not_Found：04/08/21 08:19 ID:???
一瞬思ったのが「句読点」の変化に対応するために
文（フレーズ）ごとにHMTLで区切ったらどうなるか、だね。
横書きの文だと「、。」の代わりに「,.」を使うことがあるけど、
こう言うことを考えると文ごとに分けてマークアップすべきなのかも。
実際やってたら面倒でしょうがないからやんなかったけど、
最終的にはRDFみたいにXMLで文章構造を定義することになりそう。
文（フレーズ）ごとにHMTLで区切ったらどうなるか、だね。
横書きの文だと「、。」の代わりに「,.」を使うことがあるけど、
こう言うことを考えると文ごとに分けてマークアップすべきなのかも。
実際やってたら面倒でしょうがないからやんなかったけど、
最終的にはRDFみたいにXMLで文章構造を定義することになりそう。
324 ：Name_Not_Found：04/08/21 08:23 ID:???
まぁそこまで行くと言語学的な知識も必要になってくる気がするが。
# 日常会話こなせるくらいだったら十分だろ、とも思うが、
# 昨今の助詞の乱れっぷりを考えると……。
# 日常会話こなせるくらいだったら十分だろ、とも思うが、
# 昨今の助詞の乱れっぷりを考えると……。
325 ：Name_Not_Found：04/08/21 08:24 ID:???
３２１みたいのが仕様書に書いてないことで難癖つけるんだとｵﾓﾀ
326 ：Name_Not_Found：04/08/21 08:32 ID:???
>>325
ついに妄想炸裂か。
ついに妄想炸裂か。
327 ：Name_Not_Found：04/08/21 08:43 ID:???
馬鹿はスルーしろっての。
328 ：Name_Not_Found：04/08/21 08:45 ID:???
生活サイクルネタは生活板へ
329 ：Name_Not_Found：04/08/21 08:45 ID:???
>>324
主語やら述語を入力したら適切な助詞を使った文章吐き出すオーサリングツールが出るんでないの
主語やら述語を入力したら適切な助詞を使った文章吐き出すオーサリングツールが出るんでないの
330 ：Name_Not_Found：04/08/21 08:51 ID:???
お前ら朝から盛んですね
331 ：Name_Not_Found：04/08/21 08:53 ID:???
なんで生活習慣の違いにキレる阿呆が沸いてんの？
332 ：Name_Not_Found：04/08/21 09:05 ID:???
味噌汁に2種類以上の具を入れるやつは外道！
333 ：Name_Not_Found：04/08/21 09:06 ID:???
>>331
読解力が無いなら帰れ
読解力が無いなら帰れ
334 ：Name_Not_Found：04/08/21 09:07 ID:???
>>332
茄子と豚肉だけ入れるのはValidですか？
茄子と豚肉だけ入れるのはValidですか？
335 ：Name_Not_Found：04/08/21 09:09 ID:???
夜型生活を暗に指摘されたのがそんなに悔しいことなんだろうか。
336 ：Name_Not_Found：04/08/21 09:15 ID:???
>>335
読解力が無いなら帰れ
読解力が無いなら帰れ
337 ：Name_Not_Found：04/08/21 09:18 ID:???
お前らおはよう
夜型サイクルのことなんか想像したこともない俺だけど今日も一日よろしく
夜型サイクルのことなんか想像したこともない俺だけど今日も一日よろしく
338 ：Name_Not_Found：04/08/21 09:27 ID:???
>>337
できないとしないは別だよ。お前には同じに見えるだろうけど、日本語は難しいから気をつけてね。
できないとしないは別だよ。お前には同じに見えるだろうけど、日本語は難しいから気をつけてね。
339 ：Name_Not_Found：04/08/21 09:28 ID:???
340 ：Name_Not_Found：04/08/21 09:29 ID:???
ともかく>>316は必死だな。
341 ：Name_Not_Found：04/08/21 09:41 ID:???
>>338-340
相手がDQNなように見せたいのはわかるが、時間が……
相手がDQNなように見せたいのはわかるが、時間が……
342 ：Name_Not_Found：04/08/21 09:42 ID:???
343 ：Name_Not_Found：04/08/21 10:20 ID:???
なんでこの板強制IDじゃなくなったんだっけ？
344 ：Name_Not_Found：04/08/21 11:05 ID:???
345 ：Name_Not_Found：04/08/21 11:15 ID:???
>343
たしか強制ID反対派が自治スレ内で勢力持ってた頃にルール改変になったからかな
茶文字が居なくなったのもその頃だと思う
たしか強制ID反対派が自治スレ内で勢力持ってた頃にルール改変になったからかな
茶文字が居なくなったのもその頃だと思う
346 ：Name_Not_Found：04/08/21 11:28 ID:???
>>344
最初っていつのことだよ。
>>345
強制IDやめたところで何のメリットがあるんだろ。
厨房が余計に跋扈する状況しか思い浮かばないんだが。
っつか茶文字って懐かしいな。偽者が立てたスレ残ってんのかな。
最初っていつのことだよ。
>>345
強制IDやめたところで何のメリットがあるんだろ。
厨房が余計に跋扈する状況しか思い浮かばないんだが。
っつか茶文字って懐かしいな。偽者が立てたスレ残ってんのかな。
347 ：Name_Not_Found：04/08/21 11:30 ID:???
348 ：Name_Not_Found：04/08/21 12:23 ID:???
349 ：Name_Not_Found：04/08/21 22:14 ID:???
強制IDって便利なような不便なような感じじゃないか？
冗談が言えないなんて悲しいよ。
冗談が言えないなんて悲しいよ。
350 ：Name_Not_Found：04/08/21 22:29 ID:???
Strict な HTML について語るスレッドはどこですか？
351 ：Name_Not_Found：04/08/21 22:37 ID:???
352 ：Name_Not_Found：04/08/21 23:41 ID:9MGU008G
age進行にすりゃいいんだよ
353 ：Name_Not_Found：04/08/22 10:48 ID:???
354 ：Name_Not_Found：04/08/22 12:20 ID:k0Uijra1
>305
通常の詩の場合、連＝段落の解釈で大体良いはず。例を挙げれば
蛇が
眠っている
静寂の言葉に
待ちくたびれた
蛇は眠る
とあった場合、各行１つでは意味を為さないが、上記一連ではとりあえず内心世界
の展開が成立している。近代文学において世界構造と文章構造は近似できるので、
ゆえに連は最小のブロック要素（⇒段落）として解釈できると思う。ちなみに近代
詩は改行に含意が認められるが、preは含意を構造として表現しないから、敢えて
物理要素のbrを使うべきでは？
上記の理屈から、短歌、俳句等の分かち書きは作品１つで１段落だと思われ。
但し和歌（明治期以前）の場合、上の句と下の句で相互に応答の構造を持つ場合が
あるので、５・７・５・７・７形式は時代により文章構造を見極める必要がある。
ただ、世界構造＝文章構造と言えない近代以前の文学はどう解釈するか難しい。
……ここまでくると、Strictを極めるには文学理論と哲学をやらなきゃならんわけ
だが、HTMLがそこまでの構造記述に耐えるだけの枠なのかは疑問。
通常の詩の場合、連＝段落の解釈で大体良いはず。例を挙げれば
蛇が
眠っている
静寂の言葉に
待ちくたびれた
蛇は眠る
とあった場合、各行１つでは意味を為さないが、上記一連ではとりあえず内心世界
の展開が成立している。近代文学において世界構造と文章構造は近似できるので、
ゆえに連は最小のブロック要素（⇒段落）として解釈できると思う。ちなみに近代
詩は改行に含意が認められるが、preは含意を構造として表現しないから、敢えて
物理要素のbrを使うべきでは？
上記の理屈から、短歌、俳句等の分かち書きは作品１つで１段落だと思われ。
但し和歌（明治期以前）の場合、上の句と下の句で相互に応答の構造を持つ場合が
あるので、５・７・５・７・７形式は時代により文章構造を見極める必要がある。
ただ、世界構造＝文章構造と言えない近代以前の文学はどう解釈するか難しい。
……ここまでくると、Strictを極めるには文学理論と哲学をやらなきゃならんわけ
だが、HTMLがそこまでの構造記述に耐えるだけの枠なのかは疑問。
355 ：Name_Not_Found：04/08/22 12:53 ID:???
>HTMLがそこまでの構造記述に耐えるだけの枠なのかは疑問。
例えばこんな詩。
おれはジャイアン ガキ大将
お前のものは俺のもの
俺のものも俺のもの
おれはジャイアン ガキ大将
この空白はどう表現するべきか、とか考えると無理っぽい。
例えばこんな詩。
おれはジャイアン ガキ大将
お前のものは俺のもの
俺のものも俺のもの
おれはジャイアン ガキ大将
この空白はどう表現するべきか、とか考えると無理っぽい。
356 ：Name_Not_Found：04/08/22 13:47 ID:???
全部preにしちゃえ☆
357 ：Name_Not_Found：04/08/22 14:12 ID:???
詩だと改行を/で表すこともあるな。
358 ：Name_Not_Found：04/08/22 14:44 ID:???
359 ：Name_Not_Found：04/08/22 18:28 ID:???
360 ：Name_Not_Found：04/08/22 18:32 ID:???
hosyu
361 ：Name_Not_Found：04/08/22 18:34 ID:???
上げんなヴァカ
362 ：Name_Not_Found：04/08/22 18:35 ID:???
物理要素のBRをつかうのと、見栄えのためにspanとかでマークアップするの、
どうちがうんだ？
<div class="shi">
<span id="bungakuteki-kubun-a">おれはジャイアン ガキ大将</span>
<span id="bungakuteki-kubun-b">お前のものは俺のもの</span>
<span id="bungakuteki-kubun-c">俺のものも俺のもの</span></span>
<span id="bungakuteki-kubun-d">おれはジャイアン ガキ大将<span>
</div>
空白は、文学的意図をもった区分を表現したものだと言い張ってみる。
あるいは、空白は空白という意味を持った文字、として捉えれば、
空白文字をうめこむという手もあるが…。
どうちがうんだ？
<div class="shi">
<span id="bungakuteki-kubun-a">おれはジャイアン ガキ大将</span>
<span id="bungakuteki-kubun-b">お前のものは俺のもの</span>
<span id="bungakuteki-kubun-c">俺のものも俺のもの</span></span>
<span id="bungakuteki-kubun-d">おれはジャイアン ガキ大将<span>
</div>
空白は、文学的意図をもった区分を表現したものだと言い張ってみる。
あるいは、空白は空白という意味を持った文字、として捉えれば、
空白文字をうめこむという手もあるが…。
363 ：Name_Not_Found：04/08/22 18:43 ID:???
ol でマークしちゃダメかな
364 ：Name_Not_Found：04/08/22 18:44 ID:???
>空白は空白という意味を持った文字、として捉えれば、
>空白文字をうめこむという手もあるが…。
出発がデジタルデータで全角空白いくつ、とか定義されてりゃいいけど、
例えば戦前の詩人が書いた空白だらけ語句絶対位置指定状態だったら
そりゃもう目も当てられないことになると思われ。
まぁどんな環境でも同じように再現、ってのは既にHTMLの範疇じゃないけど。
>空白文字をうめこむという手もあるが…。
出発がデジタルデータで全角空白いくつ、とか定義されてりゃいいけど、
例えば戦前の詩人が書いた空白だらけ語句絶対位置指定状態だったら
そりゃもう目も当てられないことになると思われ。
まぁどんな環境でも同じように再現、ってのは既にHTMLの範疇じゃないけど。
365 ：Name_Not_Found：04/08/22 18:52 ID:???
366 ：Name_Not_Found：04/08/22 19:01 ID:2ynRfmGq
367 ：Name_Not_Found：04/08/22 19:05 ID:???
>>366
何で上げながら必死に吼えてるのかわかんないけど、
「整形済みなんだからpre」って答えが出てるのに、「spanで整形」とかいう方がおかしいよ。
100レスとか以前にstrictについて学んだ方がいい。
何で上げながら必死に吼えてるのかわかんないけど、
「整形済みなんだからpre」って答えが出てるのに、「spanで整形」とかいう方がおかしいよ。
100レスとか以前にstrictについて学んだ方がいい。
368 ：Name_Not_Found：04/08/22 19:17 ID:???
文学に絡む話題はループしがちだな
369 ：Name_Not_Found：04/08/22 20:09 ID:???
文学作品を100%生かすようなマークアップなんてできる設計じゃないしな
370 ：３５４：04/08/22 20:18 ID:k0Uijra1
>367
「整形済みなんだからpre」って答えが出てるのに
３５５の例はデザインでCSS対応の世界だろ。
だが、詩一般を「整形済み」と解釈する根拠が不明。たしかに仕様書のpreの
使用例として詩が挙げられているが、だからと言って詩＝整形済み、というの
は早計。
現代詩において、連内の改行が含意（ポエジー）を表現することは常識だろ。
そして含意は内心世界の展開に最も重要な意味を有する。内心世界は我々の世
界一般に敷衍され、その世界構造は文章構造と等価とされる。この辺は構造主
義文学理論の展開までいかなくてもわかるだろ。
以上を以って、文章の構造をpreで整理することは怠慢に過ぎないと考えるが
その辺どうよ？
ちなみに、詩＝pre とした場合、散文詩の取り扱いがヤバくないか？
または 韻文＝pre としても、近松門左衛門の作品はどうするんだ？
さらに 「見た目が整形されてるから」だったら、既にレイアウトと文章の構造が
ぐちゃぐちゃになっててstrictの否定になる。
「整形済みなんだからpre」って答えが出てるのに
３５５の例はデザインでCSS対応の世界だろ。
だが、詩一般を「整形済み」と解釈する根拠が不明。たしかに仕様書のpreの
使用例として詩が挙げられているが、だからと言って詩＝整形済み、というの
は早計。
現代詩において、連内の改行が含意（ポエジー）を表現することは常識だろ。
そして含意は内心世界の展開に最も重要な意味を有する。内心世界は我々の世
界一般に敷衍され、その世界構造は文章構造と等価とされる。この辺は構造主
義文学理論の展開までいかなくてもわかるだろ。
以上を以って、文章の構造をpreで整理することは怠慢に過ぎないと考えるが
その辺どうよ？
ちなみに、詩＝pre とした場合、散文詩の取り扱いがヤバくないか？
または 韻文＝pre としても、近松門左衛門の作品はどうするんだ？
さらに 「見た目が整形されてるから」だったら、既にレイアウトと文章の構造が
ぐちゃぐちゃになっててstrictの否定になる。
371 ：Name_Not_Found：04/08/22 20:27 ID:???
つーか、「詩=pre」じゃなくて「詩⊇pre」で良いじゃん。
HTMLはもともと論文用に作られた規格なんだから
どうあがいても表現できない部分はある。
困ったらSVGか画像を埋め込むべし。
HTMLはもともと論文用に作られた規格なんだから
どうあがいても表現できない部分はある。
困ったらSVGか画像を埋め込むべし。
追加。
とりあえず、芸術作品は作品自体の構造を明らかにしないとならんと思うぞ。
まあソシュールとか色々ツールはあるからさぁ。文学はテクスト論から入って
文章の構造を調べると考えやすいのかな？
でも、そこまでやるのめんどくせ。深く考えると、逆にHTML＝レイアウトの
方が楽しい気がしてきた。
気の迷いだよな……。
とりあえず、芸術作品は作品自体の構造を明らかにしないとならんと思うぞ。
まあソシュールとか色々ツールはあるからさぁ。文学はテクスト論から入って
文章の構造を調べると考えやすいのかな？
でも、そこまでやるのめんどくせ。深く考えると、逆にHTML＝レイアウトの
方が楽しい気がしてきた。
気の迷いだよな……。
>371
本気で「詩⊇pre」なんだな？散文詩含めるんだな？
本気で「詩⊇pre」なんだな？散文詩含めるんだな？
３７１の言うの真に受けると、マークアップに迷ったら全部画像に
なってしまうが、それってStrictな態度なのか？
なってしまうが、それってStrictな態度なのか？
部分集合なんだから「詩の中には形式が大事なのもあるよ」ってことね。
重要な情報の中に「見た目」が含まれているのならば、
それはXHMTLでは表現できないのは明白。
ある意味では、フォントいじり系も物理マークアップで無いと
完全に情報が伝わらないことがある。
シンプルなユーザーCSSでフォントいじり系を見てもつまらないだろう。
こういう、見た目が重要になるリソースに関してはXHTMLではなくて
SVGなり画像で表現するべきだと思う。
なんつーか、「超音波で会話しようぜ」っていわれても、
構造的に無理としか言いようが無い。
重要な情報の中に「見た目」が含まれているのならば、
それはXHMTLでは表現できないのは明白。
ある意味では、フォントいじり系も物理マークアップで無いと
完全に情報が伝わらないことがある。
シンプルなユーザーCSSでフォントいじり系を見てもつまらないだろう。
こういう、見た目が重要になるリソースに関してはXHTMLではなくて
SVGなり画像で表現するべきだと思う。
なんつーか、「超音波で会話しようぜ」っていわれても、
構造的に無理としか言いようが無い。
376 ：Name_Not_Found：04/08/22 21:26 ID:???
じゃあ ⊆ だろ
377 ：Name_Not_Found：04/08/22 21:27 ID:???
詩かどうかってのはどうでもいいような。
空白や改行の位置関係が重要なら定型詩や整形詩なんだから
pre以外のなにものでも無いと思うが。
たとえば五言律詩とかはどう考えても全体をpre要素で
マークアップするのが適切じゃない？
中の意味や韻に対してspanとかでガリガリ付加情報つけたり
とかするかも知れないけど、それは全体がpre要素であることに
なんら影響は与えないでしょ。
空白や改行の位置関係が重要なら定型詩や整形詩なんだから
pre以外のなにものでも無いと思うが。
たとえば五言律詩とかはどう考えても全体をpre要素で
マークアップするのが適切じゃない？
中の意味や韻に対してspanとかでガリガリ付加情報つけたり
とかするかも知れないけど、それは全体がpre要素であることに
なんら影響は与えないでしょ。
378 ：Name_Not_Found：04/08/22 21:28 ID:???
379 ：Name_Not_Found：04/08/22 21:28 ID:???
>>362
> 物理要素のBRをつかうのと、見栄えのためにspanとかでマークアップするの、
> どうちがうんだ？
HTMLの観点から言えば、
spanを見栄えのために使おうが使うまいが、それはただのspan要素でしかない。
brには改行という明確な意味がある。
つまりspanを使ったからといって、それを見栄えのためであると判断するのは、
少なくともHTMLの観点からは全く言えない。
> 物理要素のBRをつかうのと、見栄えのためにspanとかでマークアップするの、
> どうちがうんだ？
HTMLの観点から言えば、
spanを見栄えのために使おうが使うまいが、それはただのspan要素でしかない。
brには改行という明確な意味がある。
つまりspanを使ったからといって、それを見栄えのためであると判断するのは、
少なくともHTMLの観点からは全く言えない。
380 ：Name_Not_Found：04/08/22 21:29 ID:???
s/言えない/できない/;
記号間違えた。すまん。
ていうか、部分集合じゃないな、よく考えれば
ていうか、部分集合じゃないな、よく考えれば
382 ：Name_Not_Found：04/08/22 21:31 ID:???
383 ：Name_Not_Found：04/08/22 21:36 ID:???
384 ：Name_Not_Found：04/08/22 21:55 ID:???
<dl></dl>内に<dt>、もしくは<dd>に囲まれてない部分に
文字列を書くのはStrict的にまずいのでしょうか？
具体的には以下のような文法です。
<dl>
<dt>hoge</dt>
<dd>hogehoge</dd>：bar
<dd>hogehoge/dd>：bar
</dl>
よろしくお願いします。
文字列を書くのはStrict的にまずいのでしょうか？
具体的には以下のような文法です。
<dl>
<dt>hoge</dt>
<dd>hogehoge</dd>：bar
<dd>hogehoge/dd>：bar
</dl>
よろしくお願いします。
385 ：Name_Not_Found：04/08/22 21:58 ID:???
386 ：Name_Not_Found：04/08/22 21:58 ID:???
Strict以前にDLはDD、DTしか内容をもてません。
387 ：Name_Not_Found：04/08/22 21:58 ID:???
>382
文芸作品にとって重要なのは、物理的に改行されている事ではなく、
どういう意味に基づいて改行されているかではないか？
例えば、間を表現するため、リズムをとるため、あるいは視覚的効果のみを
目的としているだけかもしれない。
BRではそれを表現するのには不完全だと思うが。
文芸作品にとって重要なのは、物理的に改行されている事ではなく、
どういう意味に基づいて改行されているかではないか？
例えば、間を表現するため、リズムをとるため、あるいは視覚的効果のみを
目的としているだけかもしれない。
BRではそれを表現するのには不完全だと思うが。
388 ：Name_Not_Found：04/08/22 21:59 ID:???
invalidの世界だねぇ
389 ：Name_Not_Found：04/08/22 22:02 ID:???
単語ごとに
<span class="word">
で囲みましょう
<span class="word">
で囲みましょう
>375
詩の連内の改行は
蛇が/眠っている/静寂の言葉に/待ちくたびれた/蛇は眠る
など、表示は変えてオッケー。要は区切りが伝達されりゃいいわけ。
んで、そういう「見た目を変えていいが、改行（＝区切り表示による含意伝達）が必要」
ってことがなぜ「整形済み」という理解なのかわからん。
整形済みの表示を変えていいのか？それってpreなのか？
もしそういう要素だったのを誤解してたなら俺が馬鹿でつ。
387を含めて、spanがいいのかなー、とも思えてきた。
「詩の改行＝見た目」と言うのであれば、文学上、通常の段落すら見た目という解釈。
そうなるとHTML=見た目の制御、という変な話になるが……。
詩の連内の改行は
蛇が/眠っている/静寂の言葉に/待ちくたびれた/蛇は眠る
など、表示は変えてオッケー。要は区切りが伝達されりゃいいわけ。
んで、そういう「見た目を変えていいが、改行（＝区切り表示による含意伝達）が必要」
ってことがなぜ「整形済み」という理解なのかわからん。
整形済みの表示を変えていいのか？それってpreなのか？
もしそういう要素だったのを誤解してたなら俺が馬鹿でつ。
387を含めて、spanがいいのかなー、とも思えてきた。
「詩の改行＝見た目」と言うのであれば、文学上、通常の段落すら見た目という解釈。
そうなるとHTML=見た目の制御、という変な話になるが……。
391 ：Name_Not_Found：04/08/23 00:02 ID:???
>>390
> んで、そういう「見た目を変えていいが、改行（＝区切り表示による含意伝達）が必要」
> ってことがなぜ「整形済み」という理解なのかわからん。
表現方法を変えてもいい、ってのと、変えるべき、ってのは違うよな？
ちなみに、整形済みってのは、「空白、改行も込みで整形されてる」ってものを指すわけだから、
空白、改行が込みなのならばpreでマーク付けするのが順当なんじゃないの？
>>385
二行目は何を示してるの？
> んで、そういう「見た目を変えていいが、改行（＝区切り表示による含意伝達）が必要」
> ってことがなぜ「整形済み」という理解なのかわからん。
表現方法を変えてもいい、ってのと、変えるべき、ってのは違うよな？
ちなみに、整形済みってのは、「空白、改行も込みで整形されてる」ってものを指すわけだから、
空白、改行が込みなのならばpreでマーク付けするのが順当なんじゃないの？
>>385
二行目は何を示してるの？
392 ：Name_Not_Found：04/08/23 00:12 ID:???
議論が過熱してまいりました
誹謗中傷しあわないように願います
誹謗中傷しあわないように願います
393 ：Name_Not_Found：04/08/23 00:23 ID:???
>>392
煽るなヴァカめが
煽るなヴァカめが
394 ：Name_Not_Found：04/08/23 00:59 ID:???
さっそく一人誹謗中傷しました
大変心が痛いです
まるでテーブルレイアウトを強制させられているかのような心境です
大変心が痛いです
まるでテーブルレイアウトを強制させられているかのような心境です
395 ：Name_Not_Found：04/08/23 01:07 ID:???
テーブルレイアウトプレイですか
396 ：Name_Not_Found：04/08/23 01:18 ID:???
>>394
淋しいのはわかるがここに癒しを求めに来るなｷﾓｲ
淋しいのはわかるがここに癒しを求めに来るなｷﾓｲ
397 ：Name_Not_Found：04/08/23 01:38 ID:???
また酷いことを言わされました
まるで.htaccessを設定できない鯖で
lintにヘッダのContent-Typeに文句を付けられる心境です。
まるで.htaccessを設定できない鯖で
lintにヘッダのContent-Typeに文句を付けられる心境です。
398 ：Name_Not_Found：04/08/23 01:42 ID:???
>394
>397
いちいちつまらんのだけど。
>397
いちいちつまらんのだけど。
399 ：Name_Not_Found：04/08/23 01:43 ID:???
かえれ
400 ：Name_Not_Found：04/08/23 02:08 ID:???
> まるで.htaccessを設定できない鯖で
> lintにヘッダのContent-Typeに文句を付けられる心境です。
不覚にもちょっと笑ってしまった…
> lintにヘッダのContent-Typeに文句を付けられる心境です。
不覚にもちょっと笑ってしまった…
401 ：Name_Not_Found：04/08/23 07:10 ID:???
いや、漏れもちょと面白いと思ってしまった。
>391
「空白、改行も込みで整形されてる」
じゃなく、空白・改行で示しているだけ。
詩の連内の改行は、段落を改行で「見せる」のと同じ。段落が改行して見える
からってpreだと言ったら電波だろ（少なくともこの板では）。「これまでの
慣例で、意味内容上の区切りを改行としてレイアウトされていた」だけ。
まず、「詩の改行＝見た目」という概念は捨ててくれ。
ただし詩人の中で寺山修司と銀色夏生は例外な。
「空白、改行も込みで整形されてる」
じゃなく、空白・改行で示しているだけ。
詩の連内の改行は、段落を改行で「見せる」のと同じ。段落が改行して見える
からってpreだと言ったら電波だろ（少なくともこの板では）。「これまでの
慣例で、意味内容上の区切りを改行としてレイアウトされていた」だけ。
まず、「詩の改行＝見た目」という概念は捨ててくれ。
ただし詩人の中で寺山修司と銀色夏生は例外な。
403 ：Name_Not_Found：04/08/23 10:24 ID:???
とりあえずこれ、Web板だけに収めるのは難しいんでね？
ポエム板（あるか知らんが）住人の力でも借りるか。
ポエム板（あるか知らんが）住人の力でも借りるか。
404 ：Name_Not_Found：04/08/23 10:25 ID:???
>>402
> 詩の連内の改行は、段落を改行で「見せる」のと同じ。段落が改行して見える
> からってpreだと言ったら電波だろ（少なくともこの板では）。
仕様書読んでこい。
＞シェリーがヒバリを詠った整形済み詩句 To a Skylark のマーク付け例を示す。
少なくとも仕様書では詩句を「整形済み」であると認識しているぞ。
> 詩の連内の改行は、段落を改行で「見せる」のと同じ。段落が改行して見える
> からってpreだと言ったら電波だろ（少なくともこの板では）。
仕様書読んでこい。
＞シェリーがヒバリを詠った整形済み詩句 To a Skylark のマーク付け例を示す。
少なくとも仕様書では詩句を「整形済み」であると認識しているぞ。
405 ：Name_Not_Found：04/08/23 10:36 ID:???
>>404
お前はスレを一度読み返した方がいいと思う。
お前はスレを一度読み返した方がいいと思う。
406 ：Name_Not_Found：04/08/23 10:39 ID:???
407 ：Name_Not_Found：04/08/23 10:43 ID:???
次世代のHTMLが如何にあるべきか、に関して、現行のHTMLの仕様を批判するのは
建設的だが、現行HTMLでどのようなマークアップをすべきか、という話の中で
「仕様が正しいとは限らない」「仕様は電波」と言われましても。
建設的だが、現行HTMLでどのようなマークアップをすべきか、という話の中で
「仕様が正しいとは限らない」「仕様は電波」と言われましても。
408 ：Name_Not_Found：04/08/23 10:59 ID:???
409 ：Name_Not_Found：04/08/23 11:41 ID:???
>>408
じゃなくて。
文節の示し方を変えるとかそういうのは「見栄え」の問題であって、
「文節があることにイミガアル」ならpreだ、って言ってるの。
それを「/で区切ることもアル」だの真剣に言ってるから指摘してるんだよ。
そんなに難しいか？
じゃなくて。
文節の示し方を変えるとかそういうのは「見栄え」の問題であって、
「文節があることにイミガアル」ならpreだ、って言ってるの。
それを「/で区切ることもアル」だの真剣に言ってるから指摘してるんだよ。
そんなに難しいか？
410 ：Name_Not_Found：04/08/23 11:43 ID:???
仕様書が整形済みテキストの例としてし詩を挙げているからと言って、
詩をすべて整形済みテキストとしてマークアップしなければならないわけではない。
詩をすべて整形済みテキストとしてマークアップしなければならないわけではない。
411 ：Name_Not_Found：04/08/23 11:45 ID:???
制作者が「俺はこの空白が大切だ」と思うか思わないか
意外に明確な判断基準はないだろ。
意外に明確な判断基準はないだろ。
412 ：Name_Not_Found：04/08/23 11:48 ID:???
>>410
詩がすべて整形済みなのかどうかが問題なのではなくて、
「文章の区切り、位置に意味がある詩」を「整形済み」だとしている、ということ。
「文章の区切り、位置に意味がある詩」をspanでどうこう、というのは<div class="paragraph">ってのと変わらんのではないか？
詩がすべて整形済みなのかどうかが問題なのではなくて、
「文章の区切り、位置に意味がある詩」を「整形済み」だとしている、ということ。
「文章の区切り、位置に意味がある詩」をspanでどうこう、というのは<div class="paragraph">ってのと変わらんのではないか？
413 ：Name_Not_Found：04/08/23 12:49 ID:???
何よりも優先すべきは日本語の勉強だと思う。
おたがいに話が通じてません。
おたがいに話が通じてません。
414 ：Name_Not_Found：04/08/23 16:12 ID:???
>>412
>404 の
>少なくとも仕様書では詩句を「整形済み」であると認識しているぞ。
これは「仕様書は詩句を整形済みと解釈しているから詩句はpreでマークアップすべき」
と盲信気味であると取られても文句は言えない表現だと思われますが。
>404 の
>少なくとも仕様書では詩句を「整形済み」であると認識しているぞ。
これは「仕様書は詩句を整形済みと解釈しているから詩句はpreでマークアップすべき」
と盲信気味であると取られても文句は言えない表現だと思われますが。
415 ：Name_Not_Found：04/08/23 16:25 ID:???
>>414
言葉が足りなかったね。すまない。
少なくとも仕様書では詩句（の文節などの形式）を「整形済み」であると認識している（と思われる）ぞ。
か。
区切りの表現の仕方が他にもある、ということよりも、
「区切り」も込みで意味をなしてる、というのであれば、「整形済み」となるだろ、って言いたいわけで、
区切り子に固執するのは本末転倒だと思うわけなんだよ。
言葉が足りなかったね。すまない。
少なくとも仕様書では詩句（の文節などの形式）を「整形済み」であると認識している（と思われる）ぞ。
か。
区切りの表現の仕方が他にもある、ということよりも、
「区切り」も込みで意味をなしてる、というのであれば、「整形済み」となるだろ、って言いたいわけで、
区切り子に固執するのは本末転倒だと思うわけなんだよ。
416 ：Name_Not_Found：04/08/23 19:26 ID:???
詩なんて誰も初めから書かなかったら良かったのにな。
417 ：Name_Not_Found：04/08/23 19:34 ID:???
>>416
ｺﾗｯ!
ｺﾗｯ!
418 ：Name_Not_Found：04/08/24 00:03 ID:???
CSSスレで盛り上がってたけど、ちょっとおまいらの意見をば。
完全なるStrict志向ってちょっと効率悪いっていうか冗長っていう感じがする。
それより適度にStrictで、多少人間味のある柔軟なStrictのほうがいいと思うんだけどどう？
前者はクラスの振り方まで完璧で、現状Strict+CSSレイアウトでできないことは排除。
後者はブラウザの実装のせいでしょぼいCSSを知った上で、代替方法を使って多少完全なるStrictではなくなるときもある。
（<br style="clear:both">みたいなこと）
多分スレ内では極限的にStrictなマークアップを話してるけど実際は適度に妥協してると思うのよ。
そんなことない？
完全なるStrict志向ってちょっと効率悪いっていうか冗長っていう感じがする。
それより適度にStrictで、多少人間味のある柔軟なStrictのほうがいいと思うんだけどどう？
前者はクラスの振り方まで完璧で、現状Strict+CSSレイアウトでできないことは排除。
後者はブラウザの実装のせいでしょぼいCSSを知った上で、代替方法を使って多少完全なるStrictではなくなるときもある。
（<br style="clear:both">みたいなこと）
多分スレ内では極限的にStrictなマークアップを話してるけど実際は適度に妥協してると思うのよ。
そんなことない？
419 ：Name_Not_Found：04/08/24 00:21 ID:???
＞<br style="clear:both">
これなんだっけ？
これなんだっけ？
420 ：Name_Not_Found：04/08/24 00:23 ID:???
421 ：Name_Not_Found：04/08/24 00:27 ID:???
>>420
おそらくCSS質問スレ。
なにを持ってストリクトとするかが微妙なので答えは出ない希ガス。
W3C の validator がうんと言えばいい、っつー人もいるし、
ティムたんよりもストリクトな香具師らもこのスレにはゴロゴロいるしね。
おそらくCSS質問スレ。
なにを持ってストリクトとするかが微妙なので答えは出ない希ガス。
W3C の validator がうんと言えばいい、っつー人もいるし、
ティムたんよりもストリクトな香具師らもこのスレにはゴロゴロいるしね。
422 ：Name_Not_Found：04/08/24 00:30 ID:???
自分のサイトをビルドする前の過程で独自のXMLでセマンティックやって
その後、適当にpやspanに無理が無い程度に変換すればいい気がする
その後、適当にpやspanに無理が無い程度に変換すればいい気がする
423 ：Name_Not_Found：04/08/24 00:39 ID:???
>>419
自己レス
http://www.mozilla.gr.jp/standards/webtips0021.html
これか。
:after擬似要素にclear指定すればいいじゃん。それも回り込ませたいならだめだけど。
自己レス
http://www.mozilla.gr.jp/standards/webtips0021.html
これか。
:after擬似要素にclear指定すればいいじゃん。それも回り込ませたいならだめだけど。
424 ：Name_Not_Found：04/08/24 00:42 ID:???
425 ：Name_Not_Found：04/08/24 00:47 ID:???
>>424
IEは:after対応してないけど、バグで意図通りになるんだから問題ないでしょう？
IEは:after対応してないけど、バグで意図通りになるんだから問題ないでしょう？
426 ：Name_Not_Found：04/08/24 00:54 ID:???
を、マジ？
ためしてみまする。
ためしてみまする。
427 ：Name_Not_Found：04/08/24 01:18 ID:???
擬似要素ってなんだよ？擬似クラスじゃなかったけ？
428 ：Name_Not_Found：04/08/24 01:19 ID:???
429 ：Name_Not_Found：04/08/24 01:23 ID:???
疑似要素であってるよfirst-lineとかfirst-letterとかafter、beforeは疑似要素
疑似クラスは:linkとか:visitedとか。
疑似クラスは:linkとか:visitedとか。
430 ：Name_Not_Found：04/08/24 01:30 ID:???
:first-kiss
431 ：Name_Not_Found：04/08/24 03:02 ID:???
スレ違いやめぃ！
432 ：Name_Not_Found：04/08/24 04:25 ID:???
IEなんてアメリカ政府にＮＧくらってんだ 無視だ無視
433 ：Name_Not_Found：04/08/24 06:26 ID:???
でもmozillaってやたら固まるし…
434 ：Name_Not_Found：04/08/24 07:46 ID:???
そこでOperaですよ。
435 ：Name_Not_Found：04/08/24 09:41 ID:???
お前らってバカ。IEが標準になれば言いだけの話。IEがルールであればいい。
436 ：Name_Not_Found：04/08/24 09:52 ID:???
437 ：Name_Not_Found：04/08/24 10:07 ID:???
ところで、藻前ら自作のポエムとか公開している奴に限って
Strictとか絶対意識してないというか、下手に奨めるとキレられたり
しそうだな、と思うのは、俺だけですか？
スレ違いですね。失礼しました。
Strictとか絶対意識してないというか、下手に奨めるとキレられたり
しそうだな、と思うのは、俺だけですか？
スレ違いですね。失礼しました。
438 ：Name_Not_Found：04/08/24 10:30 ID:???
>433
初期の (1.0とか) Mozillaはやたら固まったけど、最近はあまり固まった記憶がないな
>435
んじゃ、IEの動作の詳細を隅から隅まで公開してくれ (バグ含め) 。
どう書けばどう動くかが明確になってないと書けん。
その仕様をW3Cの勧告と見比べて、いいと思った方を俺は使う。
初期の (1.0とか) Mozillaはやたら固まったけど、最近はあまり固まった記憶がないな
>435
んじゃ、IEの動作の詳細を隅から隅まで公開してくれ (バグ含め) 。
どう書けばどう動くかが明確になってないと書けん。
その仕様をW3Cの勧告と見比べて、いいと思った方を俺は使う。
439 ：Name_Not_Found：04/08/24 10:43 ID:???
440 ：Name_Not_Found：04/08/24 10:53 ID:???
アーチスト気取りな奴は何においても批判してもらえたり
自分のやっていることとは別のことを提案してもらえたりすると
何故か逆切れする傾向が強い。
自分のやっていることとは別のことを提案してもらえたりすると
何故か逆切れする傾向が強い。
441 ：Name_Not_Found：04/08/24 11:04 ID:???
442 ：Name_Not_Found：04/08/24 11:16 ID:???
>>438
>その仕様をW3Cの勧告と見比べて、いいと思った方を俺は使う。
お前バカだろ。何かを人に伝えるためにサイトやってるんだろ。
どっちの仕様が優れてるかじゃなくて、どっちが多くの人に伝わるかだアフォ。
目的の相手に、実際に伝えるのはブラウザであって仕様じゃねんだよ。
まあ趣味でやってるガキにはわからない話だろうけどな。どうせ日記でも公開して喜んでるレベルだろ？
>その仕様をW3Cの勧告と見比べて、いいと思った方を俺は使う。
お前バカだろ。何かを人に伝えるためにサイトやってるんだろ。
どっちの仕様が優れてるかじゃなくて、どっちが多くの人に伝わるかだアフォ。
目的の相手に、実際に伝えるのはブラウザであって仕様じゃねんだよ。
まあ趣味でやってるガキにはわからない話だろうけどな。どうせ日記でも公開して喜んでるレベルだろ？
443 ：Name_Not_Found：04/08/24 11:26 ID:???
だからIEの仕様の詳細出してよ
それ前提だからね
それ前提だからね
444 ：Name_Not_Found：04/08/24 11:34 ID:???
>>443
こいつバカじゃん。用意されないと何もできないマザコンがサイト製作か？
こいつバカじゃん。用意されないと何もできないマザコンがサイト製作か？
445 ：Name_Not_Found：04/08/24 11:38 ID:???
(・∀・)ﾆﾔﾆﾔ
446 ：Name_Not_Found：04/08/24 11:40 ID:???
>>444
そっすね
そっすね
447 ：Name_Not_Found：04/08/24 11:43 ID:P6gKACEL
>>442
(・∀・)ﾆﾔﾆﾔ
(・∀・)ﾆﾔﾆﾔ
448 ：Name_Not_Found：04/08/24 11:45 ID:???
>>443
一応M$サイトにあるけど、まあ仕様書っていうレベルではないからね。
だからお前の望むものは出せんな。
っていうか出せるか出せないかは全然関係ねんだよ。
>目的の相手に、実際に伝えるのはブラウザであって仕様じゃねんだよ。
これは間違いないことだからな。
一応M$サイトにあるけど、まあ仕様書っていうレベルではないからね。
だからお前の望むものは出せんな。
っていうか出せるか出せないかは全然関係ねんだよ。
>目的の相手に、実際に伝えるのはブラウザであって仕様じゃねんだよ。
これは間違いないことだからな。
449 ：Name_Not_Found：04/08/24 11:46 ID:???
>>447
ID(・∀・)ﾆﾔﾆﾔ
ID(・∀・)ﾆﾔﾆﾔ
450 ：Name_Not_Found：04/08/24 12:04 ID:???
傍観者ｯｽﾖ (・∀・)ﾆﾔﾆﾔ
451 ：Name_Not_Found：04/08/24 12:28 ID:???
IE利用者に伝えたいならIE向けに書けばいい。それだけだろ。
俺はもともと「一人でも多くの人に見て欲しい」なんてスタンスじゃなく
「自分が使うのに作ったものだけど、欲しい人いたらご自由にどうぞ」だから
IE向けなんてわざわざ考えないけど。
俺はもともと「一人でも多くの人に見て欲しい」なんてスタンスじゃなく
「自分が使うのに作ったものだけど、欲しい人いたらご自由にどうぞ」だから
IE向けなんてわざわざ考えないけど。
452 ：Name_Not_Found：04/08/24 13:23 ID:???
そろそろスレ違いですよ
おまえら
おまえら
453 ：Name_Not_Found：04/08/24 14:07 ID:???
いいんじゃない？ブラウザと仕様のどちらが優先されるべきか、という話題である限り。
ま、<q>どっちの仕様が優れてるかじゃなくて、どっちが多くの人に伝わるかだ</q>には笑えたけど。
ま、<q>どっちの仕様が優れてるかじゃなくて、どっちが多くの人に伝わるかだ</q>には笑えたけど。
454 ：Name_Not_Found：04/08/24 14:15 ID:???
現在のUA分布だけみれば、どっちの方が多くの人に伝わるかは明らか。
アーカイブされたWeb上のリソースが将来にわたってより多くの人にみられるか、
と言う場合も、どっちの方が多くの人に伝わるかは明らか。
政府の法令発布とかが環境依存じゃ問題有りまくりな訳だが、その一方で
1ヶ月で消すようなオナニー日記ならIE向けでも全然困らないのが実情。
アーカイブされたWeb上のリソースが将来にわたってより多くの人にみられるか、
と言う場合も、どっちの方が多くの人に伝わるかは明らか。
政府の法令発布とかが環境依存じゃ問題有りまくりな訳だが、その一方で
1ヶ月で消すようなオナニー日記ならIE向けでも全然困らないのが実情。
455 ：Name_Not_Found：04/08/24 14:24 ID:???
じゃあ、
価値のある文書だと自負するなら正しいコードで、
オナヌー文書はMSIE仕様で、
つーことでFA？
価値のある文書だと自負するなら正しいコードで、
オナヌー文書はMSIE仕様で、
つーことでFA？
456 ：Name_Not_Found：04/08/24 14:51 ID:???
作成・公開の方針に合った形式であるなら何でもよい。
457 ：Name_Not_Found：04/08/24 14:55 ID:???
つーかStrictで書いてもMSIEはバグらないわけだし
458 ：Name_Not_Found：04/08/24 15:00 ID:???
>>457
でもobjectつかったりするととたんに怪しくなるわけで。
でもobjectつかったりするととたんに怪しくなるわけで。
459 ：Name_Not_Found：04/08/24 15:04 ID:???
実質objectで画像を貼れないIE
あとは特に問題ないような
あとは特に問題ないような
460 ：Name_Not_Found：04/08/24 15:05 ID:???
461 ：Name_Not_Found：04/08/24 15:07 ID:???
462 ：Name_Not_Found：04/08/24 15:30 ID:???
463 ：Name_Not_Found：04/08/24 15:30 ID:???
464 ：Name_Not_Found：04/08/24 15:37 ID:???
465 ：Name_Not_Found：04/08/24 16:16 ID:???
IE向けに書くHTMLって何だよ。marqueeが必須な文章か?なんだそりゃ。
466 ：Name_Not_Found：04/08/24 16:24 ID:???
>>460
FlashもJavaも問題なくObjectで貼れますが何か
FlashもJavaも問題なくObjectで貼れますが何か
467 ：Name_Not_Found：04/08/24 16:35 ID:???
>>465
流れとはちと関係ないが。
>marquee
モジラでもOpera でもサポートしているんだよね、いつの間にか。
むしろサポートしなくていい気がすんだがなぁ。
動かないからと言って閲覧に支障ないし。
まぁ、現状JavaScript 使って動かすと無駄に負荷が高くなりかねんけど。
流れとはちと関係ないが。
>marquee
モジラでもOpera でもサポートしているんだよね、いつの間にか。
むしろサポートしなくていい気がすんだがなぁ。
動かないからと言って閲覧に支障ないし。
まぁ、現状JavaScript 使って動かすと無駄に負荷が高くなりかねんけど。
468 ：Name_Not_Found：04/08/24 16:39 ID:???
>>463
お前バカだろ？万人向けのサイトと視覚ユーザのみへのサイトが別だってことがわかってるだろ？
クラの誰々に伝えるという目的を果たせばいいんだよ。アフォ。
>>464
>だからIE対策で金もらう話しつけてるならIEべったりの文書を書けばいいと言ってるんだが。
なんだよ対策って。その仕様書絶対正義の観点を一度忘れてみろよ。
伝えるのはブラウザ。ただそれだけだよアフォ。
>>465
くだらないあげあしのような煽りは入れるな。
>>462
お互いにな。
お前バカだろ？万人向けのサイトと視覚ユーザのみへのサイトが別だってことがわかってるだろ？
クラの誰々に伝えるという目的を果たせばいいんだよ。アフォ。
>>464
>だからIE対策で金もらう話しつけてるならIEべったりの文書を書けばいいと言ってるんだが。
なんだよ対策って。その仕様書絶対正義の観点を一度忘れてみろよ。
伝えるのはブラウザ。ただそれだけだよアフォ。
>>465
くだらないあげあしのような煽りは入れるな。
>>462
お互いにな。
469 ：Name_Not_Found：04/08/24 16:45 ID:???
仕様書いいじゃん
いいじゃん仕様書
いいじゃん仕様書
470 ：Name_Not_Found：04/08/24 16:46 ID:???
なんでこんなに必死なんだ?
471 ：Name_Not_Found：04/08/24 16:51 ID:???
Strict を可能な範囲で守りつつIE でも表示が壊れないようにするとかならともかく、
Strict 無視でいいじゃんとか言うのは明らかにスレ違いだよなぁ。
Strict 無視でいいじゃんとか言うのは明らかにスレ違いだよなぁ。
472 ：Name_Not_Found：04/08/24 17:01 ID:???
>>470
お前が一番(ry
お前が一番(ry
473 ：Name_Not_Found：04/08/24 17:04 ID:???
474 ：Name_Not_Found：04/08/24 17:08 ID:???
＞Strict 無視でいいじゃんとか言うのは明らかにスレ違いだよなぁ。
そういう回答で構わない状況をこのスレで話そうとするのがスレ違いなんだが。
そういう回答で構わない状況をこのスレで話そうとするのがスレ違いなんだが。
475 ：Name_Not_Found：04/08/24 17:10 ID:???
はいはい。みなさん落ち着いて死にましょうね。
遺書はStrictに簡潔に御願いします。日付は
yyyy-mm-ddTHH:MM:SS+9:00
で御願いします。
遺書はStrictに簡潔に御願いします。日付は
yyyy-mm-ddTHH:MM:SS+9:00
で御願いします。
476 ：Name_Not_Found：04/08/24 17:10 ID:???
477 ：Name_Not_Found：04/08/24 17:16 ID:???
これじゃつまらんスレになるわけだよな。
478 ：Name_Not_Found：04/08/24 17:36 ID:???
479 ：Name_Not_Found：04/08/24 17:38 ID:???
日本語勉強しようね、ってよく見かけるけど諸刃の剣だよねこの言い回し。
480 ：Name_Not_Found：04/08/24 17:43 ID:???
クライアントが発言するならわかるが、言われて仕方なしに（非strict、invalidを）やってる人は、
ここで、そうしてる理由を説明しても意味がないような気がするよ。
それだったら、クラを説得する方法、とかスレたててやる方が有意義っぽい。
漏れは、お任せしますなクラしか当たったことないからstrictでやってるけど。
ここで、そうしてる理由を説明しても意味がないような気がするよ。
それだったら、クラを説得する方法、とかスレたててやる方が有意義っぽい。
漏れは、お任せしますなクラしか当たったことないからstrictでやってるけど。
481 ：Name_Not_Found：04/08/24 18:06 ID:???
>>480
まあ俺が言いたいのは、
>伝えるのはブラウザ。ただそれだけだよアフォ。
ってことだから。W3Cの仕様書が絶対正義的な視点しか持てないバカを罵倒したいだけ。
ちなみに俺の趣味サイトはHTML4.01Strict。標準準拠してないブラウザ対策はあまりしてない。
でも仕事ではIEが標準。W3Cはまだまだヲタだから。
まあ関西人が90%の地域に行って関西人向けの関西弁でのパンフを作るようなもんだな。
標準語が何かなんて、浮動なんだよ。
まあ俺が言いたいのは、
>伝えるのはブラウザ。ただそれだけだよアフォ。
ってことだから。W3Cの仕様書が絶対正義的な視点しか持てないバカを罵倒したいだけ。
ちなみに俺の趣味サイトはHTML4.01Strict。標準準拠してないブラウザ対策はあまりしてない。
でも仕事ではIEが標準。W3Cはまだまだヲタだから。
まあ関西人が90%の地域に行って関西人向けの関西弁でのパンフを作るようなもんだな。
標準語が何かなんて、浮動なんだよ。
482 ：Name_Not_Found：04/08/24 18:10 ID:???
つーかなんでそんなスレ違いな話し
483 ：Name_Not_Found：04/08/24 18:23 ID:???
このスレの住人にヘンな思い込みでもあるんだろうな。
W3C仕様が絶対だと思ってる、とかさ。
# まあそういう奴もいなくはないが。
W3C仕様が絶対だと思ってる、とかさ。
# まあそういう奴もいなくはないが。
484 ：Name_Not_Found：04/08/24 18:31 ID:???
>>481>>483
言いたいことはわかるんだけど、あんたがやってることは
「プラモデルをいかに美しく造詣できても飯は食えない」と、
プラモ愛好家たちの集会に乗り込んで叫んでるのと同じだよ。
漏れらがよそのやつらに強要してるなら、そういう主張をいいに来るのもわからんでもないが、
内輪でやってることに罵倒しに来るなんてのは、お節介でしかない。
大体、あんたの言ってることなんて充分承知の上で、それでstrictってのをやってるわけなんだよ。
それだってわかってるんだろ？
言いたいことはわかるんだけど、あんたがやってることは
「プラモデルをいかに美しく造詣できても飯は食えない」と、
プラモ愛好家たちの集会に乗り込んで叫んでるのと同じだよ。
漏れらがよそのやつらに強要してるなら、そういう主張をいいに来るのもわからんでもないが、
内輪でやってることに罵倒しに来るなんてのは、お節介でしかない。
大体、あんたの言ってることなんて充分承知の上で、それでstrictってのをやってるわけなんだよ。
それだってわかってるんだろ？
485 ：Name_Not_Found：04/08/24 18:32 ID:???
> 罵倒したいだけ。
聞く耳持たない独り言は自分の趣味のサイトでどうぞ。
聞く耳持たない独り言は自分の趣味のサイトでどうぞ。
486 ：Name_Not_Found：04/08/24 18:41 ID:???
>>485
罵倒って言葉の意味知ってるか？お前は人と話す前に自分がこれから使う言葉を辞書で引きなさい。
>>484
だから罵倒したいだけ！って行ってるじゃん。
>プラモ愛好家たちの集会に乗り込んで叫んでるのと同じだよ。
同じだよ。
>お節介でしかない。
違うって罵倒だって。俺のやってるのはおせっかいなんて品のいいものじゃないよ。
罵倒って言葉の意味知ってるか？お前は人と話す前に自分がこれから使う言葉を辞書で引きなさい。
>>484
だから罵倒したいだけ！って行ってるじゃん。
>プラモ愛好家たちの集会に乗り込んで叫んでるのと同じだよ。
同じだよ。
>お節介でしかない。
違うって罵倒だって。俺のやってるのはおせっかいなんて品のいいものじゃないよ。
487 ：Name_Not_Found：04/08/24 19:02 ID:???
また痛い荒らしが来たもんだなあ。
488 ：Name_Not_Found：04/08/24 19:18 ID:???
とりあえず罵倒させとくか。別に困らないし。
489 ：Name_Not_Found：04/08/24 19:20 ID:???
罵倒をマークアップするにはどうしたらいいんでしょう。
490 ：Name_Not_Found：04/08/24 19:21 ID:???
491 ：Name_Not_Found：04/08/24 19:23 ID:???
>>486
> 罵倒って言葉の意味知ってるか？お前は人と話す前に自分がこれから使う言葉を辞書で引きなさい。
strictに説明すると、
>>485の「聞く耳持たない独り言」は「罵倒したいだけ。」の「罵倒」に掛かってるのではなくて「したいだけ」に掛かっている。
読解力を身につけてから挑むように。
> 罵倒って言葉の意味知ってるか？お前は人と話す前に自分がこれから使う言葉を辞書で引きなさい。
strictに説明すると、
>>485の「聞く耳持たない独り言」は「罵倒したいだけ。」の「罵倒」に掛かってるのではなくて「したいだけ」に掛かっている。
読解力を身につけてから挑むように。
492 ：Name_Not_Found：04/08/24 19:26 ID:???
今まで寂れるかループするかの二者択一だったから
荒らされるくらいでちょうどいいな。
荒らされるくらいでちょうどいいな。
493 ：Name_Not_Found：04/08/24 20:21 ID:???
>>489
注釈宣言にでも入れたらどうか。
注釈宣言にでも入れたらどうか。
494 ：Name_Not_Found：04/08/24 20:26 ID:???
495 ：Name_Not_Found：04/08/24 20:55 ID:???
そもそも「罵倒したいだけ」という表現自体がかなり不自然であって、
それを何とか解釈してあげると>>491みたいな微妙な事態になってくるわけだが。
不思議マークアップの文書を読ませると昔のMozillaが落ちるような。
>>481
「関西人が90%の地域に行って関西人向けの関西弁でのパンフを作」れなんて言われたら絶望的だ。
この語の綴りはどうしようか、というところからして悩ましい。
つまり、規格が整備されていないようでは何も書きようが無いということ。
>>443とかの中の人ではないけれども、IEの仕様が分からない以上、IE向け文書なんて書きようが無いんだよ。
それを何とか解釈してあげると>>491みたいな微妙な事態になってくるわけだが。
不思議マークアップの文書を読ませると昔のMozillaが落ちるような。
>>481
「関西人が90%の地域に行って関西人向けの関西弁でのパンフを作」れなんて言われたら絶望的だ。
この語の綴りはどうしようか、というところからして悩ましい。
つまり、規格が整備されていないようでは何も書きようが無いということ。
>>443とかの中の人ではないけれども、IEの仕様が分からない以上、IE向け文書なんて書きようが無いんだよ。
496 ：Name_Not_Found：04/08/24 21:05 ID:???
ny騒動以来の喩え合戦
497 ：Name_Not_Found：04/08/24 21:09 ID:???
寂れる・ループする・荒れる の3択じゃあ世話ないな。
498 ：Name_Not_Found：04/08/24 21:39 ID:???
> ny騒動
なんだそれ？
なんだそれ？
499 ：Name_Not_Found：04/08/24 22:27 ID:???
>>491
>「聞く耳持たない独り言」は「罵倒したいだけ。」の「罵倒」に掛かってるのではなくて「したいだけ」に掛かっている。
「荒らししね」
とかに訂正したらいいのに、アフォ相手にムキになりゅなよ。
荒らしはどう解釈しても独り言ではないんだし、そもそも荒らし相手に変なレスつけるりゅなよ。
というかそもそも２ちゃんでマジになるってのにょもな。
>「聞く耳持たない独り言」は「罵倒したいだけ。」の「罵倒」に掛かってるのではなくて「したいだけ」に掛かっている。
「荒らししね」
とかに訂正したらいいのに、アフォ相手にムキになりゅなよ。
荒らしはどう解釈しても独り言ではないんだし、そもそも荒らし相手に変なレスつけるりゅなよ。
というかそもそも２ちゃんでマジになるってのにょもな。
500 ：Name_Not_Found：04/08/24 22:51 ID:???
>494
マカーは虐げられ慣れしてる？
マカーは虐げられ慣れしてる？
501 ：Name_Not_Found：04/08/24 22:53 ID:???
>>499
あほやなぁ。
個人の趣味でやってるサイトとかですらstrictに拘る漏れらに「そんなんムキにならんと物理要素でええやん」と言ってるのと同じやぞ。
だから「strictに説明すると」やねんで。わからんかなぁ。
あほやなぁ。
個人の趣味でやってるサイトとかですらstrictに拘る漏れらに「そんなんムキにならんと物理要素でええやん」と言ってるのと同じやぞ。
だから「strictに説明すると」やねんで。わからんかなぁ。
503 ：Name_Not_Found：04/08/24 23:45 ID:???
>>501
>わからんかなぁ。
多分おまい以外は誰も理解できてない
俺はこのスレ住人だけど、実際のコーディングはW3C程度に妥協をしてるよ。
おまいみたいな完璧主義的なのもありだけど、そこまでしてもたいした見返りがないよ。
あえて言うなら自己満足程度のものかな。オナニみたいなもんでしょ？
ここでの議論では完璧な回答を探そういう感じで、それはそれで面白いのは同意できるけど
実際のコーディングは完璧Strict志向でやるより少し妥協してCSSで遊ぶほうが面白いな。
だから俺のサイトは<hn>で完全に構造ができてるにも関わらず、さらにdivである意味CSS用に
構造をはっきりさせて、異なるCSSを何枚も書いて遊んでる。
チョットスレ違いか；失礼
>わからんかなぁ。
多分おまい以外は誰も理解できてない
俺はこのスレ住人だけど、実際のコーディングはW3C程度に妥協をしてるよ。
おまいみたいな完璧主義的なのもありだけど、そこまでしてもたいした見返りがないよ。
あえて言うなら自己満足程度のものかな。オナニみたいなもんでしょ？
ここでの議論では完璧な回答を探そういう感じで、それはそれで面白いのは同意できるけど
実際のコーディングは完璧Strict志向でやるより少し妥協してCSSで遊ぶほうが面白いな。
だから俺のサイトは<hn>で完全に構造ができてるにも関わらず、さらにdivである意味CSS用に
構造をはっきりさせて、異なるCSSを何枚も書いて遊んでる。
チョットスレ違いか；失礼
504 ：Name_Not_Found：04/08/24 23:55 ID:???
>>503
> 多分おまい以外は誰も理解できてない
いや、おまえだけが誤読してると思う。
>>501はｽﾄﾘｸﾀｿの姿勢を、荒らしに対するレスに掛けてるだけだ。
＞おまいみたいな完璧主義的なのもありだけど、そこまでしてもたいした見返りがないよ。
>>501は完ぺき主義じゃなくて、「このｽﾚ住人的な発想で言うなれば」って話だ。
もう一度冷静に読み返してみ。
> 多分おまい以外は誰も理解できてない
いや、おまえだけが誤読してると思う。
>>501はｽﾄﾘｸﾀｿの姿勢を、荒らしに対するレスに掛けてるだけだ。
＞おまいみたいな完璧主義的なのもありだけど、そこまでしてもたいした見返りがないよ。
>>501は完ぺき主義じゃなくて、「このｽﾚ住人的な発想で言うなれば」って話だ。
もう一度冷静に読み返してみ。
505 ：Name_Not_Found：04/08/24 23:56 ID:???
毎回同じドキュメントを書いているわけでも無かろうし、
可能ならばストリクトで書く。
ブラウザの都合とかでそうも行ってられないときはストリクト風味でガマン。
両極端になる必要は無いよ。
可能ならばストリクトで書く。
ブラウザの都合とかでそうも行ってられないときはストリクト風味でガマン。
両極端になる必要は無いよ。
506 ：Name_Not_Found：04/08/24 23:59 ID:???
CSSいじるよりXSLTいじったりするほうがおもろいな。
CSSがもうちょっとおもしろい仕様ならいじりがいもあるのだが。
CSSがもうちょっとおもしろい仕様ならいじりがいもあるのだが。
507 ：Name_Not_Found：04/08/25 00:01 ID:???
>505
いや、ここはその極端専用のスレだから。
牛丼専用スレで「牛ばっか話さないで、豚も食おうぜ」って言ってるようなもん。
>506
CSS要望スレでもたててそっちでやれ。
いや、ここはその極端専用のスレだから。
牛丼専用スレで「牛ばっか話さないで、豚も食おうぜ」って言ってるようなもん。
>506
CSS要望スレでもたててそっちでやれ。
510 ：Name_Not_Found：04/08/25 00:23 ID:???
>>509
CSSいじるよりXSLTいじったりするほうがおもろいなスレでもたててそっちでやれ。
CSSいじるよりXSLTいじったりするほうがおもろいなスレでもたててそっちでやれ。
511 ：Name_Not_Found：04/08/25 01:11 ID:???
>>506>>509
>ブラウザなんてUAの1つにしかすぎないからブラウザどう見えようがどうでもいい。
完全にオナニーだね。サイトを公開したいというよりは、規格を楽しんでるって感じが強いのかな？
住人ぽいね。
>>510
自治しすぎ。適度にな。
>ブラウザなんてUAの1つにしかすぎないからブラウザどう見えようがどうでもいい。
完全にオナニーだね。サイトを公開したいというよりは、規格を楽しんでるって感じが強いのかな？
住人ぽいね。
>>510
自治しすぎ。適度にな。
512 ：Name_Not_Found：04/08/25 01:15 ID:???
どっから流れ込んで来たのこいつら
513 ：Name_Not_Found：04/08/25 01:16 ID:???
>規格
ここはそういうスレッドです。
正しいHTMLを書けばUAが適当に解釈してくれるという
シナリオを想定しているスレッドです。
ということで、みなさん、スレ違いです。俺のチンコ舐めろ
ここはそういうスレッドです。
正しいHTMLを書けばUAが適当に解釈してくれるという
シナリオを想定しているスレッドです。
ということで、みなさん、スレ違いです。俺のチンコ舐めろ
514 ：Name_Not_Found：04/08/25 01:35 ID:???
いつのまにこのスレッドは実装を気にするようになったんだ？
こないだまで脳内レンダリングが標準だったはずなのだが。
こないだまで脳内レンダリングが標準だったはずなのだが。
515 ：Name_Not_Found：04/08/25 01:36 ID:???
CSSの実装の問題とHTMLの実装の問題をごっちゃにしていないか？
516 ：Name_Not_Found：04/08/25 01:41 ID:???
>>511なんかは極論を真に受けてしまうタイプだね
517 ：Name_Not_Found：04/08/25 02:06 ID:???
518 ：Name_Not_Found：04/08/25 06:30 ID:???
>>514
以前の住人がこのスレに寄り付かなくなってるんでしょうな。
以前の住人がこのスレに寄り付かなくなってるんでしょうな。
519 ：Name_Not_Found：04/08/25 10:22 ID:???
ヲタが減って普通のやつが増えたんだろ
520 ：Name_Not_Found：04/08/25 10:41 ID:???
夏休みの宿題も終わって暇になった厨房がやってきたのか？
「以前の住人」は今オフですｗ
「以前の住人」は今オフですｗ
521 ：Name_Not_Found：04/08/25 10:59 ID:???
ヲタ隔離スレとして機能しなくなったからね。
522 ：Name_Not_Found：04/08/25 12:35 ID:???
523 ：Name_Not_Found：04/08/25 13:24 ID:???
>>522
520は２ちゃんが仕事だと思ってるんだろうからほっといたれ
520は２ちゃんが仕事だと思ってるんだろうからほっといたれ
524 ：Name_Not_Found：04/08/25 13:36 ID:???
永久ループスレ
525 ：Name_Not_Found：04/08/25 18:00 ID:???
関係ないんだけどさ、
こことかCSSスレとかそういう系にたまに出没する自称ウェブデザイナってうそ臭いよな。
だって、このスレに来てるstrict派のウェブデザイナは
「仕事でやむなく汚いソース」は、仕事だから仕方ない、って割り切ってるわけで、
「仕事ではそんなオナニーなんてしてられないのよ」なんてわざわざ言うわけないし。
strictを知らない、学んでないウェブデザイナはそもそもこのスレに来ないだろうし。
結論としては、「脳内イメージのウェブデザイナ」を持ち出して
論破してるつもりになってる普通の厨房なんじゃないだろうか、って思うわけよ。
こことかCSSスレとかそういう系にたまに出没する自称ウェブデザイナってうそ臭いよな。
だって、このスレに来てるstrict派のウェブデザイナは
「仕事でやむなく汚いソース」は、仕事だから仕方ない、って割り切ってるわけで、
「仕事ではそんなオナニーなんてしてられないのよ」なんてわざわざ言うわけないし。
strictを知らない、学んでないウェブデザイナはそもそもこのスレに来ないだろうし。
結論としては、「脳内イメージのウェブデザイナ」を持ち出して
論破してるつもりになってる普通の厨房なんじゃないだろうか、って思うわけよ。
526 ：Name_Not_Found：04/08/25 18:07 ID:???
と脳内ウェブデザイナが仰っております
527 ：Name_Not_Found：04/08/25 18:10 ID:???
528 ：Name_Not_Found：04/08/25 18:50 ID:???
>>525
>「仕事ではそんなオナニーなんてしてられないのよ」なんてわざわざ言うわけないし。
それはお前の勝手の妄想。
>strictを知らない、学んでないウェブデザイナはそもそもこのスレに来ないだろうし。
これは同意。そもそも「ウェブデザイナ」はコーディングをしないやつが多い。
で、最後に一言。
お前がたまに見かけるという自称ウェブデザイナとはどれのことだ？俺は見かけないんだが？
もしかしてお前デザインとコーディングをごっちゃにしてるのか？
デザイン中にソースレベルの事を考えるデザイナなんてそうそういないんだから
コーディングで文句を言うやつは基本的にデザイナでない。というかデザイネもかねていても
その文句は、コーダーとしての文句であってデザイナ的な発想ではないから・・・・
簡単にまとめるとお前はアフォってこと。
>「仕事ではそんなオナニーなんてしてられないのよ」なんてわざわざ言うわけないし。
それはお前の勝手の妄想。
>strictを知らない、学んでないウェブデザイナはそもそもこのスレに来ないだろうし。
これは同意。そもそも「ウェブデザイナ」はコーディングをしないやつが多い。
で、最後に一言。
お前がたまに見かけるという自称ウェブデザイナとはどれのことだ？俺は見かけないんだが？
もしかしてお前デザインとコーディングをごっちゃにしてるのか？
デザイン中にソースレベルの事を考えるデザイナなんてそうそういないんだから
コーディングで文句を言うやつは基本的にデザイナでない。というかデザイネもかねていても
その文句は、コーダーとしての文句であってデザイナ的な発想ではないから・・・・
簡単にまとめるとお前はアフォってこと。
529 ：Name_Not_Found：04/08/25 18:52 ID:???
530 ：Name_Not_Found：04/08/25 18:53 ID:???
>>528
また「ぼくちんの考えるウェブデザイナ像」厨がきたか。
そもそもHTMLでコーダとデザイナが分離してる、なんてそんな非効率な方法採用してる会社なんてあるのか？
お前のイメージのそれなんてどうでもいいよ。
また「ぼくちんの考えるウェブデザイナ像」厨がきたか。
そもそもHTMLでコーダとデザイナが分離してる、なんてそんな非効率な方法採用してる会社なんてあるのか？
お前のイメージのそれなんてどうでもいいよ。
531 ：Name_Not_Found：04/08/25 18:54 ID:???
>>529
痛いところを突かれた、って反応してるね。わかりやすくてよいな。
痛いところを突かれた、って反応してるね。わかりやすくてよいな。
532 ：Name_Not_Found：04/08/25 19:01 ID:???
ループまんせー
533 ：Name_Not_Found：04/08/25 19:06 ID:???
534 ：Name_Not_Found：04/08/25 19:10 ID:???
むしろ細かい取り決めをしっかりしてれば能率的なんじゃないのかなぁと、
ド素人は思ったけど、実際のところどうなんだろう。
ド素人は思ったけど、実際のところどうなんだろう。
535 ：Name_Not_Found：04/08/25 19:43 ID:???
>>530
>そもそもHTMLでコーダとデザイナが分離してる、なんてそんな非効率な方法採用してる会社なんてあるのか？
閉じこもってたら何もわからないさ。イラレ等でデザイン案を客に出してOKがでたらそこからはコーダーの仕事。
まあオナニーしかしたことないお前にはわからないかもしれないがね。
>そもそもHTMLでコーダとデザイナが分離してる、なんてそんな非効率な方法採用してる会社なんてあるのか？
閉じこもってたら何もわからないさ。イラレ等でデザイン案を客に出してOKがでたらそこからはコーダーの仕事。
まあオナニーしかしたことないお前にはわからないかもしれないがね。
536 ：Name_Not_Found：04/08/25 19:44 ID:???
>>531
２分でレスって・・・・ずっと２ちゃんやってるの？ｗ
２分でレスって・・・・ずっと２ちゃんやってるの？ｗ
537 ：Name_Not_Found：04/08/25 19:47 ID:???
いつまでたっても利用者に優しい見易いサイト増えないわけだな
538 ：Name_Not_Found：04/08/25 19:48 ID:???
ちなみにカスイケスレの自称ウェブデザイナの自作サイトは是非見てみたいね。
なかなか見せようとしないんだよなー。
なかなか見せようとしないんだよなー。
539 ：Name_Not_Found：04/08/25 20:04 ID:???
>>537
っていうかネットばかりやってないで働けよ。働いてたら健常者にとっては現状で十分だって思えるから。
>>538
カスイケ最近みてないな。というかcssvaultだっけかは見るけどサイトの発言は読まないな。
自称君なんていたいやついるの？ちょっと痛さを見たいんだが誘導おながい。
っていうかネットばかりやってないで働けよ。働いてたら健常者にとっては現状で十分だって思えるから。
>>538
カスイケ最近みてないな。というかcssvaultだっけかは見るけどサイトの発言は読まないな。
自称君なんていたいやついるの？ちょっと痛さを見たいんだが誘導おながい。
540 ：Name_Not_Found：04/08/25 22:18 ID:???
>>1-540
ｱﾌｫ
ｱﾌｫ
541 ：Name_Not_Found：04/08/25 22:20 ID:???
>>541は天才
542 ：Name_Not_Found：04/08/25 22:30 ID:???
>>542はジーニアス
543 ：Name_Not_Found：04/08/25 23:52 ID:???
>>544は長嶋。
544 ：Name_Not_Found：04/08/25 23:57 ID:???
3
545 ：Name_Not_Found：04/08/26 01:20 ID:???
546 ：Name_Not_Found：04/08/26 03:10 ID:???
547 ：Name_Not_Found：04/08/26 07:16 ID:???
>>546
もう少しで夏も終わるさ、と現状の酷さにROMり続けてた物の発言
もう少しで夏も終わるさ、と現状の酷さにROMり続けてた物の発言
548 ：Name_Not_Found：04/08/26 10:30 ID:???
CSSレイアウトでテーブルレイアウトは再現できるから必要ないって人に
聞きたいんだけど、縦に常に画像かなんかを中央に表示させる方法って
あるの？どうやるの？
−−−−−−−
| |
| ■ ｜
| |
−−−−−−−
↑こんな感じ
常に画面の中央にFLASHが表示されるようにしたいんだけど。
聞きたいんだけど、縦に常に画像かなんかを中央に表示させる方法って
あるの？どうやるの？
−−−−−−−
| |
| ■ ｜
| |
−−−−−−−
↑こんな感じ
常に画面の中央にFLASHが表示されるようにしたいんだけど。
549 ：Name_Not_Found：04/08/26 10:34 ID:???
550 ：Name_Not_Found：04/08/26 10:43 ID:???
551 ：Name_Not_Found：04/08/26 10:46 ID:???
>>549
しかもそのページ全然違うし…
しかもそのページ全然違うし…
552 ：Name_Not_Found：04/08/26 11:11 ID:???
553 ：Name_Not_Found：04/08/26 15:05 ID:???
〜〜ここまで汚染されたスレ〜〜
〜〜 ここからキレイなスレ 〜〜
〜〜 ここからキレイなスレ 〜〜
554 ：Name_Not_Found：04/08/26 16:00 ID:???
2get
555 ：Name_Not_Found：04/08/26 16:20 ID:???
Strict な HTML について語るスレッド 23回目
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 スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/
過去ログ・関連スレ >>2
勧告等・その他 >>3
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 スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/
過去ログ・関連スレ >>2
勧告等・その他 >>3
556 ：Name_Not_Found：04/08/26 16:22 ID:???
>>550
黙っていけよ池沼が。
黙っていけよ池沼が。
557 ：Name_Not_Found：04/08/26 16:24 ID:???
>>556
>552の誘導先にいったようだよ。FAQだ返しされたけど。
>552の誘導先にいったようだよ。FAQだ返しされたけど。
558 ：Name_Not_Found：04/08/26 17:48 ID:???
>>556-558
いちいち突っ込み入れたり、顛末報告したり、更に突っ込みいれたりせんでよろしい。
いちいち突っ込み入れたり、顛末報告したり、更に突っ込みいれたりせんでよろしい。
559 ：Name_Not_Found：04/08/26 19:01 ID:???
>>558
お前自分にも言うなら初めから投稿するなよ。バカか？
お前自分にも言うなら初めから投稿するなよ。バカか？
釣れた
561 ：Name_Not_Found：04/08/26 22:40 ID:???
後釣りかっこｲｲ(･∀･д･)ｸﾅｲ!!
562 ：Name_Not_Found：04/08/26 23:11 ID:???
>>561
顔文字にﾜﾗﾀｗ
顔文字にﾜﾗﾀｗ
563 ：Name_Not_Found：04/08/27 12:19 ID:???
>>562
古典的顔文字。顔文字辞書入れようね。
古典的顔文字。顔文字辞書入れようね。
564 ：Name_Not_Found：04/08/27 12:25 ID:???
>>563
んなもん入れてる自分のｷﾓさに気づけ。
んなもん入れてる自分のｷﾓさに気づけ。
565 ：Name_Not_Found：04/08/27 14:51 ID:???
〜〜ここまで汚染されたスレ〜〜
〜〜 ここからキレイなスレ 〜〜
〜〜 ここからキレイなスレ 〜〜
566 ：Name_Not_Found：04/08/27 14:59 ID:???
Strict な HTML について語るスレッド 24回目
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 スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/
過去ログ・関連スレ >>2
勧告等・その他 >>3
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 スレッド22
http://pc5.2ch.net/test/read.cgi/hp/1092053733/
過去ログ・関連スレ >>2
勧告等・その他 >>3
567 ：Name_Not_Found：04/08/27 15:17 ID:???
■過去ログ
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc5.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc5.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc5.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc5.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc5.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc5.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/ (pc2サーバが消えたせいで消滅？)
Strict-HTML スレッド18 http://pc5.2ch.net/test/read.cgi/hp/1076693129/
Strict-HTML スレッド19 http://pc5.2ch.net/test/read.cgi/hp/1086000635/
Strict-HTML スレッド20 http://pc5.2ch.net/test/read.cgi/hp/1087826844/
Strict-HTML スレッド21 http://pc5.2ch.net/test/read.cgi/hp/1090216329/
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc5.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc5.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc5.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc5.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc5.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc5.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc5.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/ (pc2サーバが消えたせいで消滅？)
Strict-HTML スレッド18 http://pc5.2ch.net/test/read.cgi/hp/1076693129/
Strict-HTML スレッド19 http://pc5.2ch.net/test/read.cgi/hp/1086000635/
Strict-HTML スレッド20 http://pc5.2ch.net/test/read.cgi/hp/1087826844/
Strict-HTML スレッド21 http://pc5.2ch.net/test/read.cgi/hp/1090216329/
568 ：Name_Not_Found：04/08/27 17:07 ID:???
ここから---
例:
int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}
---ここまで
「例:」も含みます。
こんな感じのコードを残したいときはどうすれば良いですか？
例:
int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}
---ここまで
「例:」も含みます。
こんな感じのコードを残したいときはどうすれば良いですか？
569 ：Name_Not_Found：04/08/27 17:31 ID:???
<hn>例</hn>
<pre>
int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}
</pre>
こんなかんじでは？例の後ろのコロンはスタイルで。
つか、初心者スレで聞いた方が…
…よくないかも。
<pre>
int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}
</pre>
こんなかんじでは？例の後ろのコロンはスタイルで。
つか、初心者スレで聞いた方が…
…よくないかも。
570 ：Name_Not_Found：04/08/27 18:45 ID:???
見出しにするのは嫌だ。
<dl>
<dt>例</dt>
<dd>
<pre>
int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}
</pre>
</dd>
</dl>
例えばCSSで
dt:after { content:":"; }
<dl>
<dt>例</dt>
<dd>
<pre>
int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}
</pre>
</dd>
</dl>
例えばCSSで
dt:after { content:":"; }
571 ：Name_Not_Found：04/08/27 19:17 ID:???
pre の中の < は < に置換するか、pre の内容を丸ごと
<![CDATA[ と ]]> でくくるヨロシ。
あと明らかにプログラムのコードなので code 要素も使うべし。
ちゅー訳で pre の部分は
<pre><code>int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}</code></pre>
こんな感じに置き換えるヨロシ。
<![CDATA[ と ]]> でくくるヨロシ。
あと明らかにプログラムのコードなので code 要素も使うべし。
ちゅー訳で pre の部分は
<pre><code>int main(void)
{
int i;
for(i=0;i<10;i++) printf("hoge.%d\n",i);
}</code></pre>
こんな感じに置き換えるヨロシ。
572 ：Name_Not_Found：04/08/27 19:42 ID:???
< くらい入力できるようにしまちょうね
573 ：Name_Not_Found：04/08/27 21:41 ID:???
574 ：Name_Not_Found：04/08/27 21:44 ID:???
【ＩＥ放棄しろ】Web標準化団体がキャンペーン
http://news13.2ch.net/test/read.cgi/news/1093593848/
http://news13.2ch.net/test/read.cgi/news/1093593848/
575 ：Name_Not_Found：04/08/27 23:09 ID:???
お前らさ、転校生の色紙とかって<hn> && <ul> or <ol>でやる？
576 ：Name_Not_Found：04/08/27 23:17 ID:???
色紙は手書きだからこそ意味があるんじゃ
577 ：Name_Not_Found：04/08/27 23:22 ID:???
色紙の書き込みはどれが最初か特定できないため、
明らかにul要素を使うべきですよ
明らかにul要素を使うべきですよ
578 ：Name_Not_Found：04/08/27 23:35 ID:???
579 ：Name_Not_Found：04/08/27 23:51 ID:???
じゃあ転校生の最後のあいさつと、校歌は？
580 ：Name_Not_Found：04/08/27 23:56 ID:???
>>579
前者はdl要素、後者はpreかpか独自XML。表現したいレベルに依存する。
前者はdl要素、後者はpreかpか独自XML。表現したいレベルに依存する。
581 ：Name_Not_Found：04/08/28 00:18 ID:???
転校生最後の挨拶は内容依存。大抵は h と複数のpだろうが、
雅に「辞校の句」とか読んだならpreにもなり得る。
校歌（歌詞）の場合、preか…もし、歌詞の内容が日本語として
文章よりもフレーズを重視しているような物の場合 p より div の
方が良いかもしれない
（「ゆんゆん」あたりになると段落とは言い難い）
ttp://www.seiryojoho-h.ed.jp/webt/syoukai/kouka/kouka.htm
雅に「辞校の句」とか読んだならpreにもなり得る。
校歌（歌詞）の場合、preか…もし、歌詞の内容が日本語として
文章よりもフレーズを重視しているような物の場合 p より div の
方が良いかもしれない
（「ゆんゆん」あたりになると段落とは言い難い）
ttp://www.seiryojoho-h.ed.jp/webt/syoukai/kouka/kouka.htm
582 ：Name_Not_Found：04/08/28 00:40 ID:???
なんで「句」が<pre>なんだよアフォ
勝手に整形するな。
勝手に整形するな。
583 ：Name_Not_Found：04/08/28 00:41 ID:???
>>571
varも使おうよと思って書き込もうと思ったが、i全部にvar振るのめんどくさいのでやめた。
varも使おうよと思って書き込もうと思ったが、i全部にvar振るのめんどくさいのでやめた。
584 ：Name_Not_Found：04/08/28 00:44 ID:???
>>583
ハァ？バカだろおまえ。
ハァ？バカだろおまえ。
585 ：Name_Not_Found：04/08/28 00:48 ID:???
code要素内にvar要素はいらないと思う。それはただの冗長。
英語での文章中に、例えばvisibleなんて変数名が出てきた時に分かりやすくするための要素だろう。
だから日本語文だと意味が薄れる（strict的には必要だろうけど）。
英語での文章中に、例えばvisibleなんて変数名が出てきた時に分かりやすくするための要素だろう。
だから日本語文だと意味が薄れる（strict的には必要だろうけど）。
586 ：Name_Not_Found：04/08/28 00:58 ID:???
587 ：Name_Not_Found：04/08/28 01:33 ID:???
<var title="主語">S</var><var title="動詞">V</var><var title="目的語">O</var>
varってこういう風に使ってもいい？
varってこういう風に使ってもいい？
588 ：Name_Not_Found：04/08/28 01:38 ID:???
varももちろん知ってたけど、引数 void には流石にいらんだろうとおもってやめた。
ちなみに （英語から連想できるが）C 系言語では void は「空」とか「無し」の意味。
ちなみに （英語から連想できるが）C 系言語では void は「空」とか「無し」の意味。
590 ：Name_Not_Found：04/08/28 02:06 ID:???
そこで void* ですよ
591 ：Name_Not_Found：04/08/28 04:06 ID:???
え？糞壁？それなに？
592 ：Name_Not_Found：04/08/28 04:56 ID:???
>>587
同時にabbrでもあるぞ。
同時にabbrでもあるぞ。
593 ：Name_Not_Found：04/08/28 07:04 ID:XQIPfLT+
Strictでテーブルを上下左右の中央に置く方法ってどんなのがあるんでしょう？
CSSでtopとleftかrightを%で指定するっていう方法も考えたんですが、これでは少しずれてしまうんですよね……
CSSでtopとleftかrightを%で指定するっていう方法も考えたんですが、これでは少しずれてしまうんですよね……
594 ：Name_Not_Found：04/08/28 07:10 ID:???
>>593は何ですか？
595 ：Name_Not_Found：04/08/28 07:12 ID:???
596 ：Name_Not_Found：04/08/28 07:26 ID:XQIPfLT+
>>595
誘導サンクス。行ってみます
誘導サンクス。行ってみます
597 ：Name_Not_Found：04/08/28 09:29 ID:???
>>593ってどこかで見たような気がするんだが、どこだっけ。
テーブルで中央に配置できるというのがよくわからないのだが。それはともかく。
>>587みたいにやるとして、同時に>>592の言うようにabbrも明示するとしたら入れ子の順番はこれで良いのかな。
<var><abbr title="Subject">S</abbr></var>
それで今思い出したんだけど、たとえばこういうテキスト
HTMLとはHyperText Markup Languageの略です。
この "H"yper"T"ext "M"arkup "L"anguage が大文字になってるのは単なる強調のため？
それとも HTML が大文字にだからそれを参照する意味？
まぁどっちでもあってどっちでもないような雰囲気もあるけど、
前者だったら大文字化するのはスタイルシートでやるべきだよね。
テーブルで中央に配置できるというのがよくわからないのだが。それはともかく。
>>587みたいにやるとして、同時に>>592の言うようにabbrも明示するとしたら入れ子の順番はこれで良いのかな。
<var><abbr title="Subject">S</abbr></var>
それで今思い出したんだけど、たとえばこういうテキスト
HTMLとはHyperText Markup Languageの略です。
この "H"yper"T"ext "M"arkup "L"anguage が大文字になってるのは単なる強調のため？
それとも HTML が大文字にだからそれを参照する意味？
まぁどっちでもあってどっちでもないような雰囲気もあるけど、
前者だったら大文字化するのはスタイルシートでやるべきだよね。
598 ：Name_Not_Found：04/08/28 12:52 ID:???
>>597
自然言語レベルで大文字にしてるんだから、マークアップするからってわざわざ小文字化する必要はないだろ。
自然言語レベルで大文字にしてるんだから、マークアップするからってわざわざ小文字化する必要はないだろ。
599 ：Name_Not_Found：04/08/28 13:00 ID:???
>>597
HTMLとCSSの切り分けとしては、
「文書レベルで意味がある事」→HTML
「失われても文意は通じる、見栄えに関する物」→CSS
HTMLと言う表記が、大文字だろうが、小文字だろうだろうが、
関係ない、と言う場合にはCSSに任せればいいし、
どっちかじゃないと不都合という場合にはHTML。
どっちにしろ/(h|H)(t|T)(m|M)(l|L)/という文字列は
HTML内に記述する必要があるんだから、普通は一般的慣習に従って
「HTML」と大文字で記述した上でとくにCSSで変更していない、と言う
だけだとおもわれ。
HTMLとCSSの切り分けとしては、
「文書レベルで意味がある事」→HTML
「失われても文意は通じる、見栄えに関する物」→CSS
HTMLと言う表記が、大文字だろうが、小文字だろうだろうが、
関係ない、と言う場合にはCSSに任せればいいし、
どっちかじゃないと不都合という場合にはHTML。
どっちにしろ/(h|H)(t|T)(m|M)(l|L)/という文字列は
HTML内に記述する必要があるんだから、普通は一般的慣習に従って
「HTML」と大文字で記述した上でとくにCSSで変更していない、と言う
だけだとおもわれ。
600 ：Name_Not_Found：04/08/28 13:11 ID:???
601 ：Name_Not_Found：04/08/28 14:09 ID:???
>>599
「HTML」は強調のためじゃなくてルールとして大文字になってるわけだけど、
それじゃ「HyperText Markup Language」はどうなのよ？
「略語の元を示すときに拾われてる文字を大文字にする」っていうルールに基づいてるのか、
それとも「拾われてる文字がわかりやすくなるように強調する」っていう方針でやってるのか。
「HTML」は強調のためじゃなくてルールとして大文字になってるわけだけど、
それじゃ「HyperText Markup Language」はどうなのよ？
「略語の元を示すときに拾われてる文字を大文字にする」っていうルールに基づいてるのか、
それとも「拾われてる文字がわかりやすくなるように強調する」っていう方針でやってるのか。
602 ：Name_Not_Found：04/08/28 14:16 ID:???
>>601
どちでもいいだろ。くだらないことにこだわるなよ。
どちでもいいだろ。くだらないことにこだわるなよ。
603 ：Name_Not_Found：04/08/28 16:12 ID:???
>>602
そんなこのスレの存在意義を根底から覆すようなことは言わんでください…
そんなこのスレの存在意義を根底から覆すようなことは言わんでください…
604 ：Name_Not_Found：04/08/28 16:22 ID:???
自分がその言葉を書くときにどう意図してるかじゃないの
605 ：Name_Not_Found：04/08/28 16:23 ID:???
>>603
実際、このスレの質問には>>602のようなことを言いたくなるようなことがある。
もしくは「無理してマークアップしなくていいよ」とか、
「そんなにHTMLは万能じゃありませんよ」とかいいたくなる。
色んな意味をこめてマークアップしているが、そんなリソースに
アクセスしてそのこじつけなマークアップの意味を汲み取れるかといえば、
かなり難しいものがある。
実際、このスレの質問には>>602のようなことを言いたくなるようなことがある。
もしくは「無理してマークアップしなくていいよ」とか、
「そんなにHTMLは万能じゃありませんよ」とかいいたくなる。
色んな意味をこめてマークアップしているが、そんなリソースに
アクセスしてそのこじつけなマークアップの意味を汲み取れるかといえば、
かなり難しいものがある。
606 ：Name_Not_Found：04/08/28 16:55 ID:???
>>605
> もしくは「無理してマークアップしなくていいよ」とか、
> 「そんなにHTMLは万能じゃありませんよ」とかいいたくなる。
そう思うならloose.dtdでもなんでも使ってくれてればいい訳で。
> 色んな意味をこめてマークアップしているが、そんなリソースに
> アクセスしてそのこじつけなマークアップの意味を汲み取れるかといえば、
> かなり難しいものがある。
UAの解釈仕方とか、見てる人が理解できるレベルに到達してるかどうか、なんてのはこのスレの範疇じゃないしな。
実用性なら他所で語るべきかと。
> もしくは「無理してマークアップしなくていいよ」とか、
> 「そんなにHTMLは万能じゃありませんよ」とかいいたくなる。
そう思うならloose.dtdでもなんでも使ってくれてればいい訳で。
> 色んな意味をこめてマークアップしているが、そんなリソースに
> アクセスしてそのこじつけなマークアップの意味を汲み取れるかといえば、
> かなり難しいものがある。
UAの解釈仕方とか、見てる人が理解できるレベルに到達してるかどうか、なんてのはこのスレの範疇じゃないしな。
実用性なら他所で語るべきかと。
607 ：Name_Not_Found：04/08/28 18:05 ID:???
疑問があるんだが、pがリストを内包できない仕様にしたのはどういう意図だ？
608 ：Name_Not_Found：04/08/28 18:07 ID:???
609 ：Name_Not_Found：04/08/28 18:14 ID:???
じゃぁ
<em>h</em>yper<em>t</em>ext<em>m</em>arkup<em>l</em>anguage
で手を打とう。大文字化してるのは接頭部分を目立たせるため、ということで。
>>598
ちなみに、大文字小文字は必ずしも自然言語レベルでは規定できない。
「not」を強調するとき「「Do NOT enter」みたいにプレーンテキストでは表現するけど
これはHTMLならば
Do <em>not</em> enterにすべきだと思われる。ただ、
Do <em>NOT</em> enterとどちらが好ましいのかはわからない。
<em>h</em>yper<em>t</em>ext<em>m</em>arkup<em>l</em>anguage
で手を打とう。大文字化してるのは接頭部分を目立たせるため、ということで。
>>598
ちなみに、大文字小文字は必ずしも自然言語レベルでは規定できない。
「not」を強調するとき「「Do NOT enter」みたいにプレーンテキストでは表現するけど
これはHTMLならば
Do <em>not</em> enterにすべきだと思われる。ただ、
Do <em>NOT</em> enterとどちらが好ましいのかはわからない。
610 ：Name_Not_Found：04/08/28 18:16 ID:???
>>607
疑問に思う人が多いらしくてXHTML2.0では内包できるようになる予定。
疑問に思う人が多いらしくてXHTML2.0では内包できるようになる予定。
611 ：Name_Not_Found：04/08/28 18:20 ID:???
散々既出ではあるがトリッキーながらvalidにpにリストを内包させる方法はある
612 ：Name_Not_Found：04/08/28 18:25 ID:???
613 ：Name_Not_Found：04/08/28 18:33 ID:???
B-TRONのコードみたいなもん?
614 ：Name_Not_Found：04/08/28 18:35 ID:???
>>613
T-BORAN？
T-BORAN？
615 ：Name_Not_Found：04/08/28 18:48 ID:???
>>614
歳がばれますよ
歳がばれますよ
>>612
わかりにくい表現だった。
大文字と小文字のどちらを使うかは**必ずしも**
自然言語（この場合はプレーンテキストを意味する）
だけで解決できる問題ではない、ってこと。
従来のプレーンテキストでは大文字と小文字を
分けることで暗に示されていたメタデータ
（強調とか）はHTMLでは要素に置換される場合
があるからね。
例えば「文」を意味する要素が出てきたら文頭を
大文字にする必要すら無くなる場合もある。
わかりにくい表現だった。
大文字と小文字のどちらを使うかは**必ずしも**
自然言語（この場合はプレーンテキストを意味する）
だけで解決できる問題ではない、ってこと。
従来のプレーンテキストでは大文字と小文字を
分けることで暗に示されていたメタデータ
（強調とか）はHTMLでは要素に置換される場合
があるからね。
例えば「文」を意味する要素が出てきたら文頭を
大文字にする必要すら無くなる場合もある。
617 ：Name_Not_Found：04/08/28 19:12 ID:???
618 ：Name_Not_Found：04/08/28 19:29 ID:???
619 ：Name_Not_Found：04/08/28 19:35 ID:???
プログラムというか
文法説明するときにSVOはある意味変数的に使われるから、
それを変数として書くのはあり？ってことだと思う。
文法説明するときにSVOはある意味変数的に使われるから、
それを変数として書くのはあり？ってことだと思う。
620 ：Name_Not_Found：04/08/28 19:37 ID:???
>>619
「ここの値は変わります」って時に使うんじゃないの？
href="<var>http://www.foo.com/</var>"
とか。
href="<var>URI</var>"
でもあってるのかな。
漏れは理系じゃないからこういうのん疎いわ
「ここの値は変わります」って時に使うんじゃないの？
href="<var>http://www.foo.com/</var>"
とか。
href="<var>URI</var>"
でもあってるのかな。
漏れは理系じゃないからこういうのん疎いわ
621 ：Name_Not_Found：04/08/28 19:45 ID:???
文中に「この文のSは"The cat"、Vは"stay"であり……」とかあれば変数といっても良いような気はする。
がしかしどちらかというとSubject、Verbなどの省略と考えてabbrの方が妥当ではないかと。
>>620
varがマークアップするのは変数であって値ではないので、その例なら
<var>href</var>="URI"
がしかしどちらかというとSubject、Verbなどの省略と考えてabbrの方が妥当ではないかと。
>>620
varがマークアップするのは変数であって値ではないので、その例なら
<var>href</var>="URI"
622 ：Name_Not_Found：04/08/28 19:50 ID:???
624 ：Name_Not_Found：04/08/28 19:59 ID:???
625 ：Name_Not_Found：04/08/28 20:03 ID:???
>>616>>609
お前って英単語の発音時の強調ポイントは全てem|strongにしちまうやつ？
>じゃぁ
><em>h</em>yper<em>t</em>ext<em>m</em>arkup<em>l</em>anguage
>で手を打とう。大文字化してるのは接頭部分を目立たせるため、ということで。
単語を要素で区切るなよバカ！そこまで頭の固いことするとStrictの利便性が失われる。
ここはStrictスレ。何も完璧な論理コーディングを追い求めるスレではない。
Strict志向をもう一度勉強しろ。
お前って英単語の発音時の強調ポイントは全てem|strongにしちまうやつ？
>じゃぁ
><em>h</em>yper<em>t</em>ext<em>m</em>arkup<em>l</em>anguage
>で手を打とう。大文字化してるのは接頭部分を目立たせるため、ということで。
単語を要素で区切るなよバカ！そこまで頭の固いことするとStrictの利便性が失われる。
ここはStrictスレ。何も完璧な論理コーディングを追い求めるスレではない。
Strict志向をもう一度勉強しろ。
626 ：Name_Not_Found：04/08/28 20:06 ID:???
SVOってのが何かわからんので憶測で書くが、
SがSubjectの頭文字をとって出来た語句だとしても、「略語」じゃないならabbrいらないんじゃないか？
うまく説明できないけど、HTML文書、って場合はHTMLは略語ってことだけど、html要素、って場合はhtmlは略語じゃない、というか、なんというか。
SがSubjectの頭文字をとって出来た語句だとしても、「略語」じゃないならabbrいらないんじゃないか？
うまく説明できないけど、HTML文書、って場合はHTMLは略語ってことだけど、html要素、って場合はhtmlは略語じゃない、というか、なんというか。
627 ：Name_Not_Found：04/08/28 20:17 ID:???
>>626
もともと変数というのは何かの略を使うことが多いが、それはネーミングの経緯でしかない。
例えば日本人の名前
「勇気があってたくましい男」という意味で「勇雄」等とつける。
どんな経緯であれ「勇雄」は完成された名前であって何かの略語ではない。
略語と略語でないものの区別ができない↑の方の587あたり？のやつらはバカ。
もともと変数というのは何かの略を使うことが多いが、それはネーミングの経緯でしかない。
例えば日本人の名前
「勇気があってたくましい男」という意味で「勇雄」等とつける。
どんな経緯であれ「勇雄」は完成された名前であって何かの略語ではない。
略語と略語でないものの区別ができない↑の方の587あたり？のやつらはバカ。
>>627
俺は略語って言ってないけど。
俺は略語って言ってないけど。
629 ：Name_Not_Found：04/08/28 20:24 ID:???
627は変数（の名前）が略語でないと主張してる（それには賛成）が、
略語が変数にならないとは説明できてないわけだが。
略語が変数にならないとは説明できてないわけだが。
630 ：Name_Not_Found：04/08/28 20:30 ID:???
>>625
え？単語を要素で区切っちゃいけないなんて決まり有るのか？
たしかに利便性は失われそうだな。
分かち書きする言語では単語を要素で区切るのはマズい？
発音時の強調ポイントについてがよく分からないんだが、
説明をお願いしたい。
え？単語を要素で区切っちゃいけないなんて決まり有るのか？
たしかに利便性は失われそうだな。
分かち書きする言語では単語を要素で区切るのはマズい？
発音時の強調ポイントについてがよく分からないんだが、
説明をお願いしたい。
631 ：Name_Not_Found：04/08/28 21:08 ID:???
<em>Hyper Text Markup Language</em>でいいじゃん。
632 ：Name_Not_Found：04/08/28 21:26 ID:???
633 ：Name_Not_Found：04/08/28 21:32 ID:???
>>628
うん。俺も何の話かよくわからずに言ってるんだｗ
>>629
それは変数の値の話か？それとも変数名の花しか？
まあなんでもいいけど、後者なら変数名になった時点で略語ではなくて完成された変数名なんだよな。
だからその場合は略語でなくて、由来になるんだな。
前者の場合は値が略語とは限らないので適当に。まあ前者ではないだろうし。
>>630
>発音時の強調ポイントについてがよく分からない
単語内の強調箇所のこと。
英文の中の強調単語にem要素等を使うのはもちろん正しいが、単語内に使うのはよくない。
唯一単語内に使って許されるのは、英和辞書のようなものだけ。とりあえずStrictから利便性を奪ったら本末転倒。
うん。俺も何の話かよくわからずに言ってるんだｗ
>>629
それは変数の値の話か？それとも変数名の花しか？
まあなんでもいいけど、後者なら変数名になった時点で略語ではなくて完成された変数名なんだよな。
だからその場合は略語でなくて、由来になるんだな。
前者の場合は値が略語とは限らないので適当に。まあ前者ではないだろうし。
>>630
>発音時の強調ポイントについてがよく分からない
単語内の強調箇所のこと。
英文の中の強調単語にem要素等を使うのはもちろん正しいが、単語内に使うのはよくない。
唯一単語内に使って許されるのは、英和辞書のようなものだけ。とりあえずStrictから利便性を奪ったら本末転倒。
634 ：Name_Not_Found：04/08/28 21:36 ID:???
…どこのルール？
635 ：Name_Not_Found：04/08/28 21:37 ID:???
>>634
どれについて？
どれについて？
636 ：Name_Not_Found：04/08/28 21:37 ID:???
>>633
Strictから利便性奪ってるのはおまえじゃ？
Strictから利便性奪ってるのはおまえじゃ？
637 ：Name_Not_Found：04/08/28 21:46 ID:???
638 ：Name_Not_Found：04/08/28 21:48 ID:???
639 ：Name_Not_Found：04/08/28 21:56 ID:???
座sぇdCんrfvふｔｇｂｙるぱぁんｊみｋ、おｌ。ｐ；
640 ：Name_Not_Found：04/08/28 22:28 ID:???
ruby
641 ：Name_Not_Found：04/08/28 22:38 ID:???
strictの利便性って…
emやstrongには単語を区切ったり、単語単位でマークアップするって
ルールなんてあったっけ？
有りもしない意味を勝手に見いだして、だらか利便性が失われるとか
いってもなんにも意味なんじゃない?
たとえば、解析用のXSLやScriptを書いたとき、１つの単語をemやstrongが
分断していたとしてどのような不都合が発生してstrictの利便性が
うしなわれるのが全く理解できない。
emやstrongには単語を区切ったり、単語単位でマークアップするって
ルールなんてあったっけ？
有りもしない意味を勝手に見いだして、だらか利便性が失われるとか
いってもなんにも意味なんじゃない?
たとえば、解析用のXSLやScriptを書いたとき、１つの単語をemやstrongが
分断していたとしてどのような不都合が発生してstrictの利便性が
うしなわれるのが全く理解できない。
642 ：Name_Not_Found：04/08/28 22:42 ID:???
I <strong>have</strong> a pen.
としたときにstrongの開始タグの前と終了タグの後ろになぜスペースを置かなければならないのか。
としたときにstrongの開始タグの前と終了タグの後ろになぜスペースを置かなければならないのか。
643 ：Name_Not_Found：04/08/28 22:45 ID:???
別に誰も置かなければならないなんて言ってないよ。
英語のリーダーが要素またいでるからって上手く読めないとしたら
それは不良品だろう。
第一、「Strict=利便性」っていつの間に決まったんだよ。
この場合、HTMLの接頭辞を強調するという意味で単語内にEM要素が
あったとしても何ら不自然な点はないと思うぞ。
全単語のアクセントにEM付けるのは間違ってるが。
それは不良品だろう。
第一、「Strict=利便性」っていつの間に決まったんだよ。
この場合、HTMLの接頭辞を強調するという意味で単語内にEM要素が
あったとしても何ら不自然な点はないと思うぞ。
全単語のアクセントにEM付けるのは間違ってるが。
645 ：Name_Not_Found：04/08/28 23:04 ID:???
強調のつけ方ってそんなに重要なことなのか？
なんでもいいじゃん。好きにしろよ。
なんでもいいじゃん。好きにしろよ。
646 ：Name_Not_Found：04/08/28 23:37 ID:???
>英語のリーダーが要素またいでるからって上手く読めないとしたら
>それは不良品だろう。
じゃあテーブルレイアウトを理解できないUAも不良品だな。
>それは不良品だろう。
じゃあテーブルレイアウトを理解できないUAも不良品だな。
647 ：Name_Not_Found：04/08/28 23:39 ID:???
何でそうなるんだよ。EMはインライン要素だぞ。
テーブルはブロックな上にレイアウトで使うこと自体が間違ってるだろ。
テーブルはブロックな上にレイアウトで使うこと自体が間違ってるだろ。
648 ：Name_Not_Found：04/08/28 23:53 ID:???
>>647
テーブルとかブロックとかは関係なくて（特にリーダーUAの場合）、
単に「仕様で要求されているUAの要件を満たしているかどうか」という
問題かと思われ。
tableでレイアウトする事自体が間違っている、と言う結論には同意。
テーブルとかブロックとかは関係なくて（特にリーダーUAの場合）、
単に「仕様で要求されているUAの要件を満たしているかどうか」という
問題かと思われ。
tableでレイアウトする事自体が間違っている、と言う結論には同意。
649 ：Name_Not_Found：04/08/28 23:55 ID:???
なんか、最近このスレから得るものが少なくなってきた…
てか、気づけば何も得ていないことに気づいてしまった。さようなら
てか、気づけば何も得ていないことに気づいてしまった。さようなら
650 ：Name_Not_Found：04/08/29 00:03 ID:???
モウコネーヨの法則
651 ：Name_Not_Found：04/08/29 00:04 ID:???
来ない来ないと言いつつ結局来てるんだな( ´∀｀)
652 ：Name_Not_Found：04/08/29 00:20 ID:???
お前らStrictより２ちゃんの方がはまってるだろ？
653 ：Name_Not_Found：04/08/29 00:22 ID:???
>>652
意味がわかりません。
意味がわかりません。
654 ：Name_Not_Found：04/08/29 00:43 ID:???
>>644
お前はこういうのが好きなの？
<p>Hello boy</p>
これを
<p><eitango>Hello</eitango><eitango>boy</eitango></p>
これで単語間のスペースはCSS（デフォルトでこの要素の連続にはハンカクスペースあり）で。
ヲタってどうしてこうキモイ発想しかできないんだろうな。
お前はこういうのが好きなの？
<p>Hello boy</p>
これを
<p><eitango>Hello</eitango><eitango>boy</eitango></p>
これで単語間のスペースはCSS（デフォルトでこの要素の連続にはハンカクスペースあり）で。
ヲタってどうしてこうキモイ発想しかできないんだろうな。
655 ：Name_Not_Found：04/08/29 00:45 ID:???
同属が何を仰る。
656 ：Name_Not_Found：04/08/29 00:48 ID:???
その前にレス番間違えてない？
657 ：Name_Not_Found：04/08/29 00:48 ID:???
ｈｔｍｌ・CSSヲタ・・・
なんかすごな
なんかすごな
658 ：Name_Not_Found：04/08/29 00:49 ID:???
>>657
htmlとかcssとか全角で書く人久しぶりに見た。
htmlとかcssとか全角で書く人久しぶりに見た。
659 ：Name_Not_Found：04/08/29 00:53 ID:???
Strict にこだわってると，おまえらも訴えられちまうぞ
RBCNetwork
http://qb5.2ch.net/test/read.cgi/saku2ch/1093703757/
★グループウェア・ソフトで有望なのは？★
http://pc5.2ch.net/test/read.cgi/bsoft/997720936/738
RBCNetwork
http://qb5.2ch.net/test/read.cgi/saku2ch/1093703757/
★グループウェア・ソフトで有望なのは？★
http://pc5.2ch.net/test/read.cgi/bsoft/997720936/738
660 ：Name_Not_Found：04/08/29 00:54 ID:???
e?
661 ：Name_Not_Found：04/08/29 00:55 ID:???
和露田
>>654
おれに振られてもな。
個人的な考えを言えば、
HTMLは比較的手軽さを重視してるからそこまでやると不良品だが、
XMLで違う言語を作るなら、場合によっては有りだろう。
おれ的には、最近はRDFで文章を書きたいぐらいの勢いだ。
いろんな意味で現在の状況じゃ無理だけどね。
おれに振られてもな。
個人的な考えを言えば、
HTMLは比較的手軽さを重視してるからそこまでやると不良品だが、
XMLで違う言語を作るなら、場合によっては有りだろう。
おれ的には、最近はRDFで文章を書きたいぐらいの勢いだ。
いろんな意味で現在の状況じゃ無理だけどね。
663 ：Name_Not_Found：04/08/29 01:32 ID:???
>>654
strictスレ的には「そんな要素はない」で終わり。
XHTML2.0だってそんな方向への拡張の予定は微塵もないし。
ちなみに、単なるXML文書として評価するなら、たとえば人工知能（無能）に
文法解析させるようなフォーマットとしては十分あり得そうだ。
strictスレ的には「そんな要素はない」で終わり。
XHTML2.0だってそんな方向への拡張の予定は微塵もないし。
ちなみに、単なるXML文書として評価するなら、たとえば人工知能（無能）に
文法解析させるようなフォーマットとしては十分あり得そうだ。
664 ：Name_Not_Found：04/08/29 07:47 ID:???
665 ：Name_Not_Found：04/08/29 07:48 ID:???
あ、ごめん。書いてから気付いた。
642はこれを上の人らに遠回りに言ってたのかorz
642はこれを上の人らに遠回りに言ってたのかorz
666 ：Name_Not_Found：04/08/29 07:51 ID:???
（ ´,_ゝ｀）ﾌﾟｯ
667 ：Name_Not_Found：04/08/29 10:10 ID:???
ヽ(`Д´)ﾉ ｳﾜｧｧﾝ!!
668 ：Name_Not_Found：04/08/29 10:36 ID:???
669 ：Name_Not_Found：04/08/29 11:16 ID:???
>>663
馬鹿？今後ああいう仕様になってほしいのか？って話だよ。
>strictスレ的には「そんな要素はない」で終わり。
（ ´,_ゝ｀）ﾌﾟｯ
>>668
こっちはアフォか（ ´,_ゝ｀）ﾌﾟｯ
最近流れを読めないやつが増えたな。
馬鹿？今後ああいう仕様になってほしいのか？って話だよ。
>strictスレ的には「そんな要素はない」で終わり。
（ ´,_ゝ｀）ﾌﾟｯ
>>668
こっちはアフォか（ ´,_ゝ｀）ﾌﾟｯ
最近流れを読めないやつが増えたな。
671 ：Name_Not_Found：04/08/29 12:39 ID:???
煽るだけで理論的なレスしないヤツに言われてもなぁ。
理論的意味合いとテキストでの表記を完全に切り離すのは
無理なんだろうな。
テキスト自体が理論的意味合いを内包できるように有る程度
最適化されてきたわけだし。
理論的意味合いとテキストでの表記を完全に切り離すのは
無理なんだろうな。
テキスト自体が理論的意味合いを内包できるように有る程度
最適化されてきたわけだし。
672 ：Name_Not_Found：04/08/29 13:27 ID:???
マークアップと相性のいいリアル言語があればいい
673 ：Name_Not_Found：04/08/29 13:32 ID:???
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
674 ：Name_Not_Found：04/08/29 15:12 ID:???
なにこのスレ
675 ：Name_Not_Found：04/08/29 15:28 ID:???
676 ：Name_Not_Found：04/08/29 15:33 ID:???
>>664
ちゃんとスペース両側に入ってない? で、単語を表わすためにスペースがいるということは別にstrong自体で単語を表せるわけではなく(text fragmentsである)、strongは単語の一部を強調しうるということでは?
ちゃんとスペース両側に入ってない? で、単語を表わすためにスペースがいるということは別にstrong自体で単語を表せるわけではなく(text fragmentsである)、strongは単語の一部を強調しうるということでは?
677 ：Name_Not_Found：04/08/29 15:37 ID:???
この場合（w = word）
<p><w>I</w><w><strong>have</strong></w><w>a</w><w>pen</w></p>
なら問題ないな。strongに単語としての意味を持たせるのは無理がある。
逆にstrongで区切られたからといって単語の切れ目だと判断するのは
UAのミスだと思われる。
<p><w>I</w><w><strong>have</strong></w><w>a</w><w>pen</w></p>
なら問題ないな。strongに単語としての意味を持たせるのは無理がある。
逆にstrongで区切られたからといって単語の切れ目だと判断するのは
UAのミスだと思われる。
678 ：Name_Not_Found：04/08/29 16:04 ID:???
お前らの悪い癖。
１．脳内
２．拡大解釈
３．ゴミソース
論理的なマークアップの限度を知らないお前らって
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
だな。W3Cもかわいそうだな。こんな馬鹿なやつらを相手に標準化を推し進めていかなきゃいけないなんてな。
１．脳内
２．拡大解釈
３．ゴミソース
論理的なマークアップの限度を知らないお前らって
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
だな。W3Cもかわいそうだな。こんな馬鹿なやつらを相手に標準化を推し進めていかなきゃいけないなんてな。
679 ：Name_Not_Found：04/08/29 16:29 ID:???
>>678よ。
多分、真に受けてるのはお前だけだぞ。
多分、真に受けてるのはお前だけだぞ。
680 ：Name_Not_Found：04/08/29 16:44 ID:???
>>679
自分だけは違うとか思ってるやつの典型例
自分だけは違うとか思ってるやつの典型例
681 ：Name_Not_Found：04/08/29 16:49 ID:???
682 ：Name_Not_Found：04/08/29 18:43 ID:???
>>681
ずいぶん必死だなｗ
ずいぶん必死だなｗ
683 ：Name_Not_Found：04/08/29 18:49 ID:???
>>682
相手を必死だとすることで自分の誤読が消えると思ってるのかな。
相手を必死だとすることで自分の誤読が消えると思ってるのかな。
684 ：Name_Not_Found：04/08/29 19:39 ID:???
ageてるやつが必死なのは間違いない
685 ：Name_Not_Found：04/08/29 19:56 ID:grHnbWMa
盛り上がってる所質問スマソ。
画像ファイルって、どうやってる？やっぱり
<p><img src="???.jpg"></p>
とか？
しかし、画像って「段落」でいいのかな？？
画像ファイルって、どうやってる？やっぱり
<p><img src="???.jpg"></p>
とか？
しかし、画像って「段落」でいいのかな？？
686 ：Name_Not_Found：04/08/29 20:04 ID:???
>>685
インライン要素、として制定されてるってことは、まあ、「段落の中」とかにあればそれでいいんじゃない？
ブロックレベルの中に置けばインライン、外に置けばブロックレベルとして振舞ってくれてもいいと思うんだけどな。
リスト要素も。
インライン要素、として制定されてるってことは、まあ、「段落の中」とかにあればそれでいいんじゃない？
ブロックレベルの中に置けばインライン、外に置けばブロックレベルとして振舞ってくれてもいいと思うんだけどな。
リスト要素も。
687 ：Name_Not_Found：04/08/29 20:07 ID:???
レスサンクス。
アルバムみたいなページで、今まで
<div class="album">
<p><img src="???.jpg"></p>
<p>本文本文本文1</p>
<p>本文本文本文2</p>
</div>
みたいなやり方をしていたんだが、<p>に単体で写真を入れるのはおかしいという気がしてきた。
段落の中だと
<div class="album">
<p>
<img src="???.jpg">
本文本文本文1
</p>
<p>本文本文本文2</p>
</div>
となって、これも違う気がするし…。位置付けからいって、見出しでもないような…。
<dl>でも使えばいいのかな？
アルバムみたいなページで、今まで
<div class="album">
<p><img src="???.jpg"></p>
<p>本文本文本文1</p>
<p>本文本文本文2</p>
</div>
みたいなやり方をしていたんだが、<p>に単体で写真を入れるのはおかしいという気がしてきた。
段落の中だと
<div class="album">
<p>
<img src="???.jpg">
本文本文本文1
</p>
<p>本文本文本文2</p>
</div>
となって、これも違う気がするし…。位置付けからいって、見出しでもないような…。
<dl>でも使えばいいのかな？
689 ：Name_Not_Found：04/08/29 20:17 ID:???
690 ：Name_Not_Found：04/08/29 20:44 ID:???
691 ：Name_Not_Found：04/08/29 20:53 ID:???
680 ：Name_Not_Found ：04/08/29 16:44 ID:???
>>679
自分だけは違うとか思ってるやつの典型例
681 ：Name_Not_Found ：04/08/29 16:49 ID:???
>>680
文盲？
>>678だけは違うと思ってるやつなんだけど。
日本語がちゃんと理解できるようになったら噛み付きにおいで。
682 ：Name_Not_Found ：04/08/29 18:43 ID:???
>>681
ずいぶん必死だなｗ
683 ：Name_Not_Found ：04/08/29 18:49 ID:???
>>682
相手を必死だとすることで自分の誤読が消えると思ってるのかな。
5分と6分って・・・・・なんでそんなに必死なの？
>>679
自分だけは違うとか思ってるやつの典型例
681 ：Name_Not_Found ：04/08/29 16:49 ID:???
>>680
文盲？
>>678だけは違うと思ってるやつなんだけど。
日本語がちゃんと理解できるようになったら噛み付きにおいで。
682 ：Name_Not_Found ：04/08/29 18:43 ID:???
>>681
ずいぶん必死だなｗ
683 ：Name_Not_Found ：04/08/29 18:49 ID:???
>>682
相手を必死だとすることで自分の誤読が消えると思ってるのかな。
5分と6分って・・・・・なんでそんなに必死なの？
692 ：Name_Not_Found：04/08/29 21:00 ID:???
なんだかすごい痛い人がいるな
694 ：Name_Not_Found：04/08/29 21:08 ID:???
つまり参考にしたページが悪かったと言いたいのかと
695 ：Name_Not_Found：04/08/29 21:51 ID:???
お前ら画像を見出しにつかっちゃだめだよ。
見出しってのは本文の要約であり、決して参考にされる資料等ではない。
見出しは所詮は要約なのであって、そこに欠如不可能情報を入れてはならない。
見出しってのは本文の要約であり、決して参考にされる資料等ではない。
見出しは所詮は要約なのであって、そこに欠如不可能情報を入れてはならない。
696 ：Name_Not_Found：04/08/29 21:51 ID:???
何ですか突然
697 ：Name_Not_Found：04/08/29 22:01 ID:???
alt云々は言っちゃいけないんだよねこのシチュエーションでは。
698 ：Name_Not_Found：04/08/29 22:12 ID:???
つうか、見出しを画像にする必要があるのか？
単純な見出しなら普通に文字でいいと思うし、もしページタイトルを見出しにしたいなら、
スタイルシートで中身を見えなくして背景画像を入れればよいのではないか？
単純な見出しなら普通に文字でいいと思うし、もしページタイトルを見出しにしたいなら、
スタイルシートで中身を見えなくして背景画像を入れればよいのではないか？
699 ：Name_Not_Found：04/08/29 22:17 ID:???
>>697
確かにaltがどうとかとはまた別の話だね。
>>695
興味深い。
>A heading element briefly describes the topic of the section it introduces.
とあるしね。
でもサイトのタイトルを入れる場合もある。
またセクションがなんであるかを表す場合(「メニュー」「本文」「補足」など)もある。
これは本文の要約ではないし、別の意味で欠如不可能情報と言える。
どうなんだろう?
いっそのことRDFで記述したほうがすっきり記述できそうだな。
確かにaltがどうとかとはまた別の話だね。
>>695
興味深い。
>A heading element briefly describes the topic of the section it introduces.
とあるしね。
でもサイトのタイトルを入れる場合もある。
またセクションがなんであるかを表す場合(「メニュー」「本文」「補足」など)もある。
これは本文の要約ではないし、別の意味で欠如不可能情報と言える。
どうなんだろう?
いっそのことRDFで記述したほうがすっきり記述できそうだな。
700 ：Name_Not_Found：04/08/29 22:19 ID:???
>>698
それをすると、CSS有効、画像無効のUAでは何も見えない。
それをすると、CSS有効、画像無効のUAでは何も見えない。
701 ：Name_Not_Found：04/08/29 22:26 ID:???
>>700
なにか問題が?
なにか問題が?
702 ：Name_Not_Found：04/08/29 22:28 ID:???
>>700
CSSの機能は問題じゃないな
CSSの機能は問題じゃないな
703 ：Name_Not_Found：04/08/29 22:31 ID:???
>>699
＞でもサイトのタイトルを入れる場合もある。
＞またセクションがなんであるかを表す場合(「メニュー」「本文」「補足」など)もある。
何よりHTMLではちゃんと<hn>を使わないといけない時点で、HTMLにとっての見出しは欠如不可能であるのかもしれない。
HTMLでは見出しのない文章を非Strictとされる。仕様がそうなんだからしょうがないっかｗ
<div id="ここでsection等を">〜</div>
のようにdivで構造を作ることもできるけどね。
ということで見出しに欠如不可能情報を入れるのは、文法的には誤りだが
HTMLとしては問題ないということで。
＞でもサイトのタイトルを入れる場合もある。
＞またセクションがなんであるかを表す場合(「メニュー」「本文」「補足」など)もある。
何よりHTMLではちゃんと<hn>を使わないといけない時点で、HTMLにとっての見出しは欠如不可能であるのかもしれない。
HTMLでは見出しのない文章を非Strictとされる。仕様がそうなんだからしょうがないっかｗ
<div id="ここでsection等を">〜</div>
のようにdivで構造を作ることもできるけどね。
ということで見出しに欠如不可能情報を入れるのは、文法的には誤りだが
HTMLとしては問題ないということで。
>>703
しかし、hn要素そのものはセクションやその階層を表現するために存在しなければならないが、その内容は要約に限り、セクションがなんであるかはtitleやclassで表現する、というやり方も考えられる。
つまりhnの存在は欠如不可能だがその中身は欠如可能でなければならないという主張も考えられる。
ただ、それを実践している人は寡聞にして聞いたことがない。>>695がどうやっているか気になる。
しかし、hn要素そのものはセクションやその階層を表現するために存在しなければならないが、その内容は要約に限り、セクションがなんであるかはtitleやclassで表現する、というやり方も考えられる。
つまりhnの存在は欠如不可能だがその中身は欠如可能でなければならないという主張も考えられる。
ただ、それを実践している人は寡聞にして聞いたことがない。>>695がどうやっているか気になる。
705 ：Name_Not_Found：04/08/29 22:57 ID:???
>>704
>hn要素そのものはセクションやその階層を表現するために存在しなければならないが
そもそもhn要素はそんなものを表現しているの？拡大解釈じゃないか？
W3Cが規格を作る時にhn要素にそんな意味を込めていたのなら、当然CSSにもそういうセレクタがあるはず。
しかし実際にはない。だからこそdivでの構造明示が必要であるわけだ。
section等の構造はdivで。hn要素はそのdiv内の見出しをユーザに伝えるだけ。
<div id="section1" h="生態系について">などができないから、代替方法としてhnが存在するんじゃないか？
もちろん後方互換的な意味もあるだろうけど。
>hn要素そのものはセクションやその階層を表現するために存在しなければならないが
そもそもhn要素はそんなものを表現しているの？拡大解釈じゃないか？
W3Cが規格を作る時にhn要素にそんな意味を込めていたのなら、当然CSSにもそういうセレクタがあるはず。
しかし実際にはない。だからこそdivでの構造明示が必要であるわけだ。
section等の構造はdivで。hn要素はそのdiv内の見出しをユーザに伝えるだけ。
<div id="section1" h="生態系について">などができないから、代替方法としてhnが存在するんじゃないか？
もちろん後方互換的な意味もあるだろうけど。
706 ：Name_Not_Found：04/08/29 23:14 ID:???
>>700
その為のalt属性では？
その為のalt属性では？
707 ：Name_Not_Found：04/08/29 23:16 ID:???
>>706
>698よく読めばわかると思うけどalt属性は関係ない話だぞ
>698よく読めばわかると思うけどalt属性は関係ない話だぞ
708 ：Name_Not_Found：04/08/29 23:35 ID:???
><div id="section1" h="生態系について">
こんなのあったら便利だな＾＾
こんなのあったら便利だな＾＾
709 ：Name_Not_Found：04/08/29 23:39 ID:???
>>708
XHTML2.0じゃだめ?
>>705
>そもそもhn要素はそんなものを表現しているの？拡大解釈じゃないか？
HTML4.01やXHTMLでは規定してないですね。一方ISO-HTMLでははっきり規定されている。
XHTML2.0じゃだめ?
>>705
>そもそもhn要素はそんなものを表現しているの？拡大解釈じゃないか？
HTML4.01やXHTMLでは規定してないですね。一方ISO-HTMLでははっきり規定されている。
710 ：Name_Not_Found：04/08/30 00:12 ID:???
> HTML4.01やXHTMLでは規定してないですね。一方ISO-HTMLでははっきり規定されている。
異なる規格を十把一絡げに語るつもりではあるまいな？
異なる規格を十把一絡げに語るつもりではあるまいな？
711 ：Name_Not_Found：04/08/30 00:32 ID:???
>>710
むしろ逆でhtml401ではこう、iso-htmlではこうという風に分けて考えようよってことじゃない?
むしろ逆でhtml401ではこう、iso-htmlではこうという風に分けて考えようよってことじゃない?
712 ：Name_Not_Found：04/08/30 00:37 ID:???
ISO-HTMLの利点と欠点は？
誰か簡潔に
誰か簡潔に
713 ：Name_Not_Found：04/08/30 00:41 ID:???
714 ：Name_Not_Found：04/08/30 00:41 ID:???
まぁ、その辺りは<section></section>に期待ですよ。
715 ：Name_Not_Found：04/08/30 00:49 ID:???
>>713
>利点：仕様に沿って書けばほぼ自動的にValid=Strictになる
ISOにStrictなんてあるのか？それに仕様書に沿って書いたらそりゃ仕様の意向まで汲み取ったソースになるに決まってるだろ。
>>714
divで十分。head属性は星池ドナ。
>利点：仕様に沿って書けばほぼ自動的にValid=Strictになる
ISOにStrictなんてあるのか？それに仕様書に沿って書いたらそりゃ仕様の意向まで汲み取ったソースになるに決まってるだろ。
>>714
divで十分。head属性は星池ドナ。
716 ：Name_Not_Found：04/08/30 01:23 ID:???
>divで十分。head属性は星池ドナ。
さようならセマンティックウェブ
さようならセマンティックウェブ
717 ：Name_Not_Found：04/08/30 01:34 ID:???
>>717
>このスレで使われているStrictの意味を理解していないようだな
Strictの意味がいくつもあったら困るんだけど。馬鹿？
>しかもvalidとstrictの違いもわかっていないとは…
どこにそんなこと書いてあるの？イコールとしたのは712だし、そのイコールの意味は
validでついでにstrictにもなっちゃうぜって意味と汲み取れる。
読解力ないおまえは仕様書読むのも一苦労なんだろうな。
>このスレで使われているStrictの意味を理解していないようだな
Strictの意味がいくつもあったら困るんだけど。馬鹿？
>しかもvalidとstrictの違いもわかっていないとは…
どこにそんなこと書いてあるの？イコールとしたのは712だし、そのイコールの意味は
validでついでにstrictにもなっちゃうぜって意味と汲み取れる。
読解力ないおまえは仕様書読むのも一苦労なんだろうな。
719 ：Name_Not_Found：04/08/30 01:46 ID:???
どっちもみっともない
720 ：Name_Not_Found：04/08/30 01:54 ID:???
虫同志が何をやってんだか
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
721 ：Name_Not_Found：04/08/30 01:58 ID:???
722 ：Name_Not_Found：04/08/30 02:08 ID:???
>>720
新学期になったら漢字の勉強しろよ。
新学期になったら漢字の勉強しろよ。
>>721
>このスレでのStrictというのはStrictDTDのことではないよ。
そりゃそうだ。
Strict-HTML = 見栄え(CSS)と構造(HTML)の分離。W3Cの推し進めてるweb標準化での根底思想。（思想か？ｗ）
StrictDTD = DTDの種類。
valid = HTML文書冒頭で宣言したDTDで定義されている要素・属性・値のみを使用して作られたHTML文書。
>このスレでのStrictというのはStrictDTDのことではないよ。
そりゃそうだ。
Strict-HTML = 見栄え(CSS)と構造(HTML)の分離。W3Cの推し進めてるweb標準化での根底思想。（思想か？ｗ）
StrictDTD = DTDの種類。
valid = HTML文書冒頭で宣言したDTDで定義されている要素・属性・値のみを使用して作られたHTML文書。
724 ：Name_Not_Found：04/08/30 04:46 ID:???
725 ：Name_Not_Found：04/08/30 04:52 ID:???
はいはい，ら抜き言葉かっこ悪いよ
726 ：Name_Not_Found：04/08/30 04:58 ID:???
凄いなあこのスレは
Strictの話し合いをしているのに、いつのまにか罵りあってるｗ
Strictの話し合いをしているのに、いつのまにか罵りあってるｗ
727 ：Name_Not_Found：04/08/30 06:29 ID:???
万人の万人に対する闘争だ！
728 ：Name_Not_Found：04/08/30 08:33 ID:???
> Strict-HTML = 見栄え(CSS)と構造(HTML)の分離。W3Cの推し進めてるweb標準化での根底思想。（思想か？ｗ）
このローカルスラングやめない？
既存のDTD名と名前がかぶるので読んでいて大変紛らわしく
初心者・入門者やこのスレをはじめて読む人に与える誤解にも
相当なものがあると思う。
このローカルスラングやめない？
既存のDTD名と名前がかぶるので読んでいて大変紛らわしく
初心者・入門者やこのスレをはじめて読む人に与える誤解にも
相当なものがあると思う。
729 ：Name_Not_Found：04/08/30 09:02 ID:???
ああいう奴はかまわないで放置しといたほうがいいよ。
730 ：Name_Not_Found：04/08/30 09:55 ID:???
さて、で、結局hnの中身はどうしたらいい?
新聞の見出しでも「今日の天気」とか「書評」とか「川柳」とかいうのはあるね。それと同じで「メニュー」とか「本文」とか「補足」とかのhnがあってもいいんじゃない?
新聞の見出しでも「今日の天気」とか「書評」とか「川柳」とかいうのはあるね。それと同じで「メニュー」とか「本文」とか「補足」とかのhnがあってもいいんじゃない?
731 ：Name_Not_Found：04/08/30 10:26 ID:???
「今日の天気」とか「書評」とか「川柳」は
コーナータイトルであって見出しではないだろ
コーナータイトルであって見出しではないだろ
732 ：Name_Not_Found：04/08/30 10:46 ID:???
title
http://dictionary.goo.ne.jp/search.php?MT=title&ej.x=0&ej.y=0&ej=%B1%D1%CF%C2&kind=&mode=0
表題, 題名; 書名; （本の）題扉, 見出し;
コーナータイトル = コーナーの見出し
これは hn 要素以外の何で現すのが適当？
http://dictionary.goo.ne.jp/search.php?MT=title&ej.x=0&ej.y=0&ej=%B1%D1%CF%C2&kind=&mode=0
表題, 題名; 書名; （本の）題扉, 見出し;
コーナータイトル = コーナーの見出し
これは hn 要素以外の何で現すのが適当？
733 ：Name_Not_Found：04/08/30 10:47 ID:???
734 ：Name_Not_Found：04/08/30 10:53 ID:???
735 ：Name_Not_Found：04/08/30 10:58 ID:???
>>734
まぁ言い回しは何でもいいから、「hn 要素以外の以下略」に模範解答きぼん
まぁ言い回しは何でもいいから、「hn 要素以外の以下略」に模範解答きぼん
736 ：Name_Not_Found：04/08/30 11:00 ID:nQXY+JGt
>>734
同じだと思うが？
_________________________________________________________________________________________________________三省堂提供「大辞林 第二版」より
みだし 0 【見出し】
(1)新聞・雑誌などの記事の内容が一目でわかるようにつけた標題。ヘッドライン。
「大―」「小―」
(2)本や帳簿の内容がすぐわかるように書き出した目次・索引など。インデックス。
「ノートに―をつける」
(3)辞書で項目を示すために掲げる語。見やすいように太字などで示す。見出し語。
---
だいめい 0 【題名】
表題の名。
---
ひょうだい へう― 0 【表題/標題】
(1)本の表紙に書かれている本の名。
(2)講義・演説などの題目。
(3)演劇などの題目。
同じだと思うが？
_________________________________________________________________________________________________________三省堂提供「大辞林 第二版」より
みだし 0 【見出し】
(1)新聞・雑誌などの記事の内容が一目でわかるようにつけた標題。ヘッドライン。
「大―」「小―」
(2)本や帳簿の内容がすぐわかるように書き出した目次・索引など。インデックス。
「ノートに―をつける」
(3)辞書で項目を示すために掲げる語。見やすいように太字などで示す。見出し語。
---
だいめい 0 【題名】
表題の名。
---
ひょうだい へう― 0 【表題/標題】
(1)本の表紙に書かれている本の名。
(2)講義・演説などの題目。
(3)演劇などの題目。
737 ：Name_Not_Found：04/08/30 11:06 ID:???
「バカの壁」は見出しではないよな？
辞書持ち出してその内容通りの解釈しかできない所が厨くさいな
辞書持ち出してその内容通りの解釈しかできない所が厨くさいな
738 ：Name_Not_Found：04/08/30 11:12 ID:???
批判だけしておいて自分の意見は出せない所が厨くさいな
739 ：Name_Not_Found：04/08/30 11:20 ID:???
>>737のいってることはただ間違い（間違いかどーかしらねーが）を指摘しただけで意見はねーんじゃねーの
740 ：Name_Not_Found：04/08/30 11:22 ID:???
741 ：Name_Not_Found：04/08/30 11:24 ID:???
742 ：Name_Not_Found：04/08/30 11:28 ID:???
HTMLそのものが、文書として、本と共通の構造をしている部分と、
ハードを伴わないコンピュータ上のHyperTextとして異なる構造をしている部分がある。
マークアップに迷った時、本に置き換えて、どのような要素に該当するかを考えるのは
有効な場合が多いが、本のこの部分はHTMLだとなんだろう、と一々考える必要はない。
HTMLにはhead要素にtitleがあり、body要素にh1-h6の段階的な重みがつけられた
見出しがある。それ以上の所を無理して記述する必要はないし、記述しても
UAに解釈されることは期待出来ない。
で、回答としては
>これは hn 要素以外の何で現すのが適当？
基本的に hn 以外で表すのは不適当。
どうしても「見出し(h1-h6)」ではないと言うなら、既存のHTML要素にはないので
汎用属性divを使うことになるだろうが、適当ではない。
ハードを伴わないコンピュータ上のHyperTextとして異なる構造をしている部分がある。
マークアップに迷った時、本に置き換えて、どのような要素に該当するかを考えるのは
有効な場合が多いが、本のこの部分はHTMLだとなんだろう、と一々考える必要はない。
HTMLにはhead要素にtitleがあり、body要素にh1-h6の段階的な重みがつけられた
見出しがある。それ以上の所を無理して記述する必要はないし、記述しても
UAに解釈されることは期待出来ない。
で、回答としては
>これは hn 要素以外の何で現すのが適当？
基本的に hn 以外で表すのは不適当。
どうしても「見出し(h1-h6)」ではないと言うなら、既存のHTML要素にはないので
汎用属性divを使うことになるだろうが、適当ではない。
743 ：Name_Not_Found：04/08/30 11:28 ID:???
おまえらここがなんのスレか知ってるか？
>汎用属性divを使うことになるだろうが、
×汎用属性div ○汎用要素div
(´･ω･`)ｼｮﾎﾞｰﾝ
×汎用属性div ○汎用要素div
(´･ω･`)ｼｮﾎﾞｰﾝ
745 ：Name_Not_Found：04/08/30 11:30 ID:???
>>737じゃないんだけど。
>>741
> たとえばトップページでサイト名はh1でマークアップしない？
漏れも以前はそうしていたんだけど、
最近は、サイト名は<p title="このサイトのサイト名">とかして、
<h1>home</h1> とか <h1>トップページ※</h1> とかするのがいいのでは
ないかと思って、そうしている。
※日本語としてhomepageよりトップページの方がまかり通っているため
そう書きました。
>>741
> たとえばトップページでサイト名はh1でマークアップしない？
漏れも以前はそうしていたんだけど、
最近は、サイト名は<p title="このサイトのサイト名">とかして、
<h1>home</h1> とか <h1>トップページ※</h1> とかするのがいいのでは
ないかと思って、そうしている。
※日本語としてhomepageよりトップページの方がまかり通っているため
そう書きました。
746 ：Name_Not_Found：04/08/30 11:54 ID:???
>>745
トップページと、（所謂日本語の）ホームページと（原義の）Homepeagは
全部違いますが…。
トップページ
一連のサイト群の最上位（？）ページとか、入り口とか。
（所謂日本語の）ホームページ
Web Site の意味で使われている日本語。
HomePage
ブラウザがユーザーに起点として表示する画面（画面とは限らないか…?）
では？
トップページと、（所謂日本語の）ホームページと（原義の）Homepeagは
全部違いますが…。
トップページ
一連のサイト群の最上位（？）ページとか、入り口とか。
（所謂日本語の）ホームページ
Web Site の意味で使われている日本語。
HomePage
ブラウザがユーザーに起点として表示する画面（画面とは限らないか…?）
では？
747 ：Name_Not_Found：04/08/30 11:56 ID:???
>>746
スレ違いもいいとこだが、
海外ではHomePageの「ブラウザのスタートアップページ」が転じて、
サイトのいわゆるトップページの意味でも使われている。
TopPageが海外で何を意味するのか、とか、
745が何にこだわっているのかはよくわからんが。
スレ違いもいいとこだが、
海外ではHomePageの「ブラウザのスタートアップページ」が転じて、
サイトのいわゆるトップページの意味でも使われている。
TopPageが海外で何を意味するのか、とか、
745が何にこだわっているのかはよくわからんが。
日本語下手ですみません。
要はh1はサイト名じゃないんじゃないかな、っつー話です。
要はh1はサイト名じゃないんじゃないかな、っつー話です。
749 ：Name_Not_Found：04/08/30 13:43 ID:???
なんか自称strict理解してます君が痛い発言を繰り返すようになってきたな。
中途半端な知識は夏厨よりもタチが悪い。
中途半端な知識は夏厨よりもタチが悪い。
750 ：Name_Not_Found：04/08/30 14:12 ID:???
見出しは要約、題名は単なる識別子であって別物だとしても、
要約とかスローガンとかみたいな機能を果たせないのであれば、
識別子として機能することはするだろうけれども、そういう題名が宜しいとは思えない。
要約とかスローガンとかみたいな機能を果たせないのであれば、
識別子として機能することはするだろうけれども、そういう題名が宜しいとは思えない。
751 ：Name_Not_Found：04/08/30 14:12 ID:???
indexのh1にはサイトタイトル、その他各ページのh1には
ページの題（aboutとかbookmarkとか)を入れてるけど。
駄目なの…？
ページの題（aboutとかbookmarkとか)を入れてるけど。
駄目なの…？
752 ：Name_Not_Found：04/08/30 14:16 ID:???
>>751
そういう人のが多いと思う
そういう人のが多いと思う
753 ：Name_Not_Found：04/08/30 14:40 ID:???
754 ：Name_Not_Found：04/08/30 14:51 ID:???
>>751
<body>
<div id=header>サイト名</div>
<h1>そのページのおお見出し</h1>
〜〜〜
<div id="footer">copyrightから連絡先、注意事項云々</div>
の方が何かとよいぞ。
<body>
<div id=header>サイト名</div>
<h1>そのページのおお見出し</h1>
〜〜〜
<div id="footer">copyrightから連絡先、注意事項云々</div>
の方が何かとよいぞ。
755 ：Name_Not_Found：04/08/30 14:57 ID:???
そもそもドキュメント単位の記述の仕様のhtmlに、
サイト名、という概念があるのかどうか。
サイト名、という概念があるのかどうか。
756 ：Name_Not_Found：04/08/30 15:06 ID:???
757 ：Name_Not_Found：04/08/30 15:12 ID:???
>>756
で、サイト名はどこに？
で、サイト名はどこに？
758 ：Name_Not_Found：04/08/30 15:13 ID:???
じゃあ、bookmark属性で関連する他人の文書をmarkupしたら、
同じサイトになりますか？ そうですか…。
同じサイトになりますか？ そうですか…。
bookmark属性ってなんだヨウ!
link要素のrel,rev属性でbookmarkを指定したら、が正しいです。
っていうか、boolmarkに限らないけどさぁ。
link要素のrel,rev属性でbookmarkを指定したら、が正しいです。
っていうか、boolmarkに限らないけどさぁ。
760 ：Name_Not_Found：04/08/30 15:18 ID:???
天気予報の場合
<h1 title="天気予報">台風16号九州へ</h1>
とできるか。
メニューやリンク集とか要約が作りづらい場合はリストにしてXHTML2.0のラベルを使って、見出し無しのsectionとか。
ISO-HTMLの場合はどうしよう。
<h1 title="天気予報">台風16号九州へ</h1>
とできるか。
メニューやリンク集とか要約が作りづらい場合はリストにしてXHTML2.0のラベルを使って、見出し無しのsectionとか。
ISO-HTMLの場合はどうしよう。
761 ：Name_Not_Found：04/08/30 15:21 ID:???
A heading element briefly describes the topic of the section it introduces.
見出し要素には、そのセクションのトピックを簡潔に記載します。
ってあるじゃん。「今日の天気」とか「メニュー」とか「本文」とか「フッター」でもいいんじゃない?
見出し要素には、そのセクションのトピックを簡潔に記載します。
ってあるじゃん。「今日の天気」とか「メニュー」とか「本文」とか「フッター」でもいいんじゃない?
762 ：Name_Not_Found：04/08/30 15:23 ID:???
>>758-9
たぶん758はlinkを使えば他のサイトのものまでも同じ文書群にできるかボケ的なことをいいたいんだろうよ。
それに対しての答えは 「できる」 だね。
ただ勘違いしちゃいけないのは、link要素での関連付ってのはあくまでも制作者の主張をUAに伝えるものなのよね。
事実がどうであれ、世の中のサイト全てうちのサイトのchapterだっていうのは自由。
758これで納得した？
たぶん758はlinkを使えば他のサイトのものまでも同じ文書群にできるかボケ的なことをいいたいんだろうよ。
それに対しての答えは 「できる」 だね。
ただ勘違いしちゃいけないのは、link要素での関連付ってのはあくまでも制作者の主張をUAに伝えるものなのよね。
事実がどうであれ、世の中のサイト全てうちのサイトのchapterだっていうのは自由。
758これで納得した？
763 ：Name_Not_Found：04/08/30 15:28 ID:???
お前らなんか勘違いしてるけど、仕様書には見出しを書かなきゃいけないなんてどこにも
書いてないぞ。見出しのない文章はないとかアフォなやつもいるけど、正解は見出しを省略できない
文章などない。だからな。
書いてないぞ。見出しのない文章はないとかアフォなやつもいるけど、正解は見出しを省略できない
文章などない。だからな。
>>764
>そもそもドキュメント単位の記述の仕様のhtmlに、
>サイト名、という概念があるのかどうか。
この子のいうことを、
HTMLはドキュメントごとに違う文書なのだからそれを括る概念はないんじゃないか？
と受け止めて、 「あるよ」 というレスをしただけだが？
>そもそもドキュメント単位の記述の仕様のhtmlに、
>サイト名、という概念があるのかどうか。
この子のいうことを、
HTMLはドキュメントごとに違う文書なのだからそれを括る概念はないんじゃないか？
と受け止めて、 「あるよ」 というレスをしただけだが？
766 ：Name_Not_Found：04/08/30 16:15 ID:???
>>763
じゃあISO-HTMLではどうやって階層構造を表わしたらいいんだ。
じゃあISO-HTMLではどうやって階層構造を表わしたらいいんだ。
767 ：Name_Not_Found：04/08/30 16:19 ID:???
>>766
ISOでは見出しは省略できないだろ。
ISOでは見出しは省略できないだろ。
768 ：Name_Not_Found：04/08/30 16:32 ID:???
結局>>761とか英和辞書(新英和中辞典 第６版)でheadingが「(ページ･章などの)表題，見出し，項目」となっているのを見るとheadingを見出しと訳したのが誤訳だったということでFA?
769 ：Name_Not_Found：04/08/30 17:16 ID:???
見出しの訳は正しい。
見出しと言う訳をみて、見出し以外の意味がない、という思いこみが間違い。
見出しと言う訳をみて、見出し以外の意味がない、という思いこみが間違い。
link とか使って多のドキュメントの繋がりを示すことが
出来るのは全く持って同意です。
ただ、それの名前（サイト名）ってのは html にはないのではないのかと。
どう？
出来るのは全く持って同意です。
ただ、それの名前（サイト名）ってのは html にはないのではないのかと。
どう？
772 ：Name_Not_Found：04/08/30 19:14 ID:???
773 ：Name_Not_Found：04/08/30 19:36 ID:???
虫同志が何をやってんだか
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
774 ：Name_Not_Found：04/08/30 21:46 ID:???
最近この板のほとんどが罵倒スレに変わってきた気がする・・・・
むなしいなぁ
むなしいなぁ
775 ：( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼：04/08/31 02:11 ID:???
こいつら馬鹿だな
776 ：Name_Not_Found：04/08/31 03:54 ID:???
>>776
ほー、なるほど。
でもそこって「入口ページ」とか「インデックス」とか「table of contents」
とかが入るべきじゃない？
そのリンク要素の参照先にかんする補足みたいなもんでしょ？
ほー、なるほど。
でもそこって「入口ページ」とか「インデックス」とか「table of contents」
とかが入るべきじゃない？
そのリンク要素の参照先にかんする補足みたいなもんでしょ？
778 ：Name_Not_Found：04/08/31 04:07 ID:???
トップページってたいていの場合startかindexを兼ねてはいるな。
同じ著者による他の文書、程度のつながりならbookmarkか。
同じ著者による他の文書、程度のつながりならbookmarkか。
779 ：Name_Not_Found：04/08/31 09:46 ID:???
>>778
前から疑問に思ってたんだけど、その<link rel="bookmark" href="" />って
その文章に関係した内容を含んでいるページへのリンク集を指してるの？
一般的なサイトのリンクページのURIを入れてもいいのかな。
前から疑問に思ってたんだけど、その<link rel="bookmark" href="" />って
その文章に関係した内容を含んでいるページへのリンク集を指してるの？
一般的なサイトのリンクページのURIを入れてもいいのかな。
780 ：Name_Not_Found：04/08/31 10:03 ID:???
一般的な…というのがちょっとわからんけど、とりあえず「他人の管理下にあっても問題ない」って回答でＯＫ？
たとえば、このスレのHTMLなら >>3 の関連スレや勧告あたりはBookmark に成るかと思われ。
たとえば、このスレのHTMLなら >>3 の関連スレや勧告あたりはBookmark に成るかと思われ。
781 ：Name_Not_Found：04/08/31 10:08 ID:???
>>780
何となくわかった気がする。ｻﾝｸｽ
何となくわかった気がする。ｻﾝｸｽ
782 ：Name_Not_Found：04/08/31 10:11 ID:???
>>779
少なくとも「リンク集」という限定された意味ではない。
少なくとも「リンク集」という限定された意味ではない。
783 ：Name_Not_Found：04/08/31 10:23 ID:???
784 ：Name_Not_Found：04/08/31 10:43 ID:???
>>782
念のために確認。
bookmarkは「関連する文書」に「しおり（bookmark）」を挟んでおく為の
キーワードで、紙のレポートとかでいう「○○を参照」なんて場合の
「○○へのリンク」に適用される、でいいんだよね？
>>783
bookmark以外が文書全体を対象として、bookmarkのみが
文書の断片を対象とし得るってのは、しらんかった。
rel="start" href="index.html#first" とかやっちゃってるから、
仕様を確認してから後で修正しとこう…。
念のために確認。
bookmarkは「関連する文書」に「しおり（bookmark）」を挟んでおく為の
キーワードで、紙のレポートとかでいう「○○を参照」なんて場合の
「○○へのリンク」に適用される、でいいんだよね？
>>783
bookmark以外が文書全体を対象として、bookmarkのみが
文書の断片を対象とし得るってのは、しらんかった。
rel="start" href="index.html#first" とかやっちゃってるから、
仕様を確認してから後で修正しとこう…。
785 ：Name_Not_Found：04/08/31 12:32 ID:???
>a link to a key entry point within an extended document
の解釈次第じゃないかな。
例えばstartの中にcontentsに相当するセクションがあるのは
W3Cの仕様書にあるように珍しい事ではないわけで、
>rel="start" href="index.html#first"
でも間違ってはいないんじゃないの。
の解釈次第じゃないかな。
例えばstartの中にcontentsに相当するセクションがあるのは
W3Cの仕様書にあるように珍しい事ではないわけで、
>rel="start" href="index.html#first"
でも間違ってはいないんじゃないの。
786 ：Name_Not_Found：04/08/31 13:35 ID:???
XHTMLとHTMLどっち使ってるよ？
アンケートスタート！
↓
アンケートスタート！
↓
787 ：Name_Not_Found：04/08/31 13:46 ID:???
アンケート終了！
788 ：Name_Not_Found：04/08/31 14:04 ID:???
非常にためになりました、ご協力感謝します
789 ：Name_Not_Found：04/08/31 14:26 ID:???
新版の(X)HTMLが出ることもなく、ループばっかりで廃れ気味なので提案なんだけど、
次スレからXHTML2.0やXSL変換、その他のSGML/XML(例えばRSSとか)なんかもスレの
取り扱い範疇にしない?
HTML4.01に関しては有る程度語り尽くされて、新規の質問もFAQだったり、
過去幾度と無くループして結論が出ない物だったり、なんて状況だけど、
「RSSでサイトの更新情報を配布したいんですが〜」なんて需要に対しては
十分な需要と、語る余地があるとおもうんだが。
勿論、既にある関連スレとの競合問題なんかもあるとは思うけど、
どうだろう？
次スレからXHTML2.0やXSL変換、その他のSGML/XML(例えばRSSとか)なんかもスレの
取り扱い範疇にしない?
HTML4.01に関しては有る程度語り尽くされて、新規の質問もFAQだったり、
過去幾度と無くループして結論が出ない物だったり、なんて状況だけど、
「RSSでサイトの更新情報を配布したいんですが〜」なんて需要に対しては
十分な需要と、語る余地があるとおもうんだが。
勿論、既にある関連スレとの競合問題なんかもあるとは思うけど、
どうだろう？
790 ：Name_Not_Found：04/08/31 16:05 ID:???
>>789
スレタイ読め。
>XHTML2.0やXSL変換、その他のSGML/XML(例えばRSSとか)なんかも
Strictに関係している話題であれば誰も文句は言わない。
XHTML2.0はいいとしても、XSL変換は全く無関係だろ。CSSの話を持ち出すようなものだ。
ループうんざりだからってスレ違いのことはやめれ。
自分で、自分の飽きない、需要のあるスレでも立ててそっちでやれ。
お前がいつまでもこのスレにいつく必要はないのだよ。
スレタイ読め。
>XHTML2.0やXSL変換、その他のSGML/XML(例えばRSSとか)なんかも
Strictに関係している話題であれば誰も文句は言わない。
XHTML2.0はいいとしても、XSL変換は全く無関係だろ。CSSの話を持ち出すようなものだ。
ループうんざりだからってスレ違いのことはやめれ。
自分で、自分の飽きない、需要のあるスレでも立ててそっちでやれ。
お前がいつまでもこのスレにいつく必要はないのだよ。
791 ：Name_Not_Found：04/08/31 16:13 ID:???
>>789
このスレ(の名前)はtext/htmlだけでどうにかしたい人のためにとっておけって。
「その他のSGML/XML」なんて
これまでのスレの主旨とは関係ない目的の仕様だって沢山あるだろう。
そういうものまで扱えるようにしたいなら、
スレタイ変えて別途にスレ立てた方がいいと思うぞ。
このスレ(の名前)はtext/htmlだけでどうにかしたい人のためにとっておけって。
「その他のSGML/XML」なんて
これまでのスレの主旨とは関係ない目的の仕様だって沢山あるだろう。
そういうものまで扱えるようにしたいなら、
スレタイ変えて別途にスレ立てた方がいいと思うぞ。
792 ：Name_Not_Found：04/08/31 16:38 ID:???
スレの方向変えちゃおうぜ、というのもアレだが、
それに対してスレタイ読めって >>790 も相当にアレだな。
（読めるから、変えようっていってる訳で）
ま、このスレに閉塞感を感じるなら各人勝手に卒業ｗすりゃいいわけで、
そのごスレの内容に閉塞感が有ろうが、ループしようが、
ほっとけよって感じだな。俺としては。
そう言う意味では >>790 には同意。
それに対してスレタイ読めって >>790 も相当にアレだな。
（読めるから、変えようっていってる訳で）
ま、このスレに閉塞感を感じるなら各人勝手に卒業ｗすりゃいいわけで、
そのごスレの内容に閉塞感が有ろうが、ループしようが、
ほっとけよって感じだな。俺としては。
そう言う意味では >>790 には同意。
793 ：Name_Not_Found：04/08/31 16:56 ID:???
W3C標準スレでも作る？
794 ：Name_Not_Found：04/08/31 17:41 ID:???
795 ：Name_Not_Found：04/08/31 17:50 ID:???
web製作板ID強制表示にしてほしいな
796 ：Name_Not_Found：04/08/31 17:59 ID:???
797 ：Name_Not_Found：04/08/31 18:01 ID:???
>>793-4
サイト製作標準準拠スレ
Strictの一歩先へ
Strict-HTMLを修得した人が、標準化について語るスレ
【仕様書】web標準化議論スレ【嫁】
4つほど考えてみた。でも正直必要ないと思う・・・・お前ら２ちゃんに自分の居場所を求めるなよ。
２ちゃんを卒業することも考えれ。きっと仕事もはかどるぞ。業績アップで昇進だ＾＾
サイト製作標準準拠スレ
Strictの一歩先へ
Strict-HTMLを修得した人が、標準化について語るスレ
【仕様書】web標準化議論スレ【嫁】
4つほど考えてみた。でも正直必要ないと思う・・・・お前ら２ちゃんに自分の居場所を求めるなよ。
２ちゃんを卒業することも考えれ。きっと仕事もはかどるぞ。業績アップで昇進だ＾＾
798 ：Name_Not_Found：04/08/31 18:37 ID:???
>>797
私見だが、需要があるのはその手の議論より
必ずしもStrictや標準化とは関係のない質疑応答ではないかと。
半端に仕様書が読めたりすると
よく解らないところを聞きたくても初心者スレでは聞きにくかったり。
私見だが、需要があるのはその手の議論より
必ずしもStrictや標準化とは関係のない質疑応答ではないかと。
半端に仕様書が読めたりすると
よく解らないところを聞きたくても初心者スレでは聞きにくかったり。
799 ：Name_Not_Found：04/08/31 18:46 ID:???
800 ：Name_Not_Found：04/08/31 19:11 ID:???
Web標準化スレとかそんなんでいいじゃん
801 ：Name_Not_Found：04/08/31 19:11 ID:???
立てるのはいいが分離独立の形をとれよ
802 ：Name_Not_Found：04/08/31 19:14 ID:???
お前らそろそろスレ違いな話は控えろ
そうゆうのは雑談スレ等でやれ。お前らのスレタイ選考でこのスレを使うな。
そうゆうのは雑談スレ等でやれ。お前らのスレタイ選考でこのスレを使うな。
803 ：Name_Not_Found：04/08/31 20:00 ID:???
【XHTML】【CSS】【XSL】Web標準スレ01【RDF】【SOAP】【XML】
俺個人としてはW3CやIETF内部のドロドロとした関係とか
暗黒史を語るスレッドが欲しいところだ。
俺個人としてはW3CやIETF内部のドロドロとした関係とか
暗黒史を語るスレッドが欲しいところだ。
804 ：Name_Not_Found：04/08/31 20:01 ID:???
805 ：Name_Not_Found：04/08/31 20:16 ID:???
806 ：Name_Not_Found：04/08/31 21:54 ID:???
>>707
そもそも画像でしか表せないようなものを見出しにする
可能性がありやなしやって話？
それなら、例えば甲骨文字の論文とかでならありそうじゃない？
<H1>甲骨文字の解釈に関する論文</H1>
<H2>概要</H2>
：
：
<H2>個別の文字に見る派生</H2>
<H3><IMG src="hoge.jpg" alt="火の原型"></H3>
<P>・・・・
とか。
なんか文書にIMG要素は必要か否かとか、IMG要素だけの
P要素は在り得るかって話と似たような話に見えるな。
そもそも画像でしか表せないようなものを見出しにする
可能性がありやなしやって話？
それなら、例えば甲骨文字の論文とかでならありそうじゃない？
<H1>甲骨文字の解釈に関する論文</H1>
<H2>概要</H2>
：
：
<H2>個別の文字に見る派生</H2>
<H3><IMG src="hoge.jpg" alt="火の原型"></H3>
<P>・・・・
とか。
なんか文書にIMG要素は必要か否かとか、IMG要素だけの
P要素は在り得るかって話と似たような話に見えるな。
807 ：Name_Not_Found：04/08/31 22:39 ID:???
>>806
参照してもらう画像を本文の要約にしてどうするんだよ。
そういうときは本当に要約のために画像を使うんだよ。意味わかるか？
見出しを参照させたり、見出しについての説明とかするのは文法が間違ってるんだよ。
本文ありきの見出しってことを勉強しなおすといい。
現実にある論文等の文法が正しいと思って、それを教科書にしてると痛い間違いするよ。
参照してもらう画像を本文の要約にしてどうするんだよ。
そういうときは本当に要約のために画像を使うんだよ。意味わかるか？
見出しを参照させたり、見出しについての説明とかするのは文法が間違ってるんだよ。
本文ありきの見出しってことを勉強しなおすといい。
現実にある論文等の文法が正しいと思って、それを教科書にしてると痛い間違いするよ。
808 ：Name_Not_Found：04/08/31 23:27 ID:???
809 ：Name_Not_Found：04/08/31 23:59 ID:???
810 ：Name_Not_Found：04/09/01 00:05 ID:???
>>808
そもそも806はaltと実際の画像とのつじつまが合ってない時点で×
それゆえにソースを見ても>>808のような解釈はしにくいからやはり×
>>808>>806
が悩むことは、文字コードにない漢字を画像で表す時のaltをどうするかだね。
<img src="imposible.gif" alt="「ほげ」と読む変換できない漢字の画像">
で、結論としては見出しには変換不可能な文字を避けろ。
つじつまの合うaltは見出しでは、見出しとしてのつじつまが合わないから本文中に
参照すべき画像として出すしかない。（現状のwebでは）
そもそも806はaltと実際の画像とのつじつまが合ってない時点で×
それゆえにソースを見ても>>808のような解釈はしにくいからやはり×
>>808>>806
が悩むことは、文字コードにない漢字を画像で表す時のaltをどうするかだね。
<img src="imposible.gif" alt="「ほげ」と読む変換できない漢字の画像">
で、結論としては見出しには変換不可能な文字を避けろ。
つじつまの合うaltは見出しでは、見出しとしてのつじつまが合わないから本文中に
参照すべき画像として出すしかない。（現状のwebでは）
811 ：Name_Not_Found：04/09/01 00:07 ID:???
なんか破綻しかかった結論にたどりついちゃうのね。
812 ：Name_Not_Found：04/09/01 00:09 ID:???
813 ：Name_Not_Found：04/09/01 00:12 ID:???
>見出しには変換不可能な文字を避けろ。
この辺りがどうにもうまく納得できん。
例えばWebかUAかフォントのいずれかが物凄く未熟な存在で、
JISの基準も第一までしかクリアできない程度の漢字しか表現できないとしたら、
そこから漏れた字は見出しに使うべきじゃないから平仮名で表現するべき？
代替できないものを要約とするなってのはわからんでもないが、
現状使えるか使えないかでマークアップ云々に関わるのは微妙な心境。
この辺りがどうにもうまく納得できん。
例えばWebかUAかフォントのいずれかが物凄く未熟な存在で、
JISの基準も第一までしかクリアできない程度の漢字しか表現できないとしたら、
そこから漏れた字は見出しに使うべきじゃないから平仮名で表現するべき？
代替できないものを要約とするなってのはわからんでもないが、
現状使えるか使えないかでマークアップ云々に関わるのは微妙な心境。
814 ：Name_Not_Found：04/09/01 00:15 ID:???
815 ：Name_Not_Found：04/09/01 00:18 ID:???
>>813
<h1><img src="moji.jpg" alt="（読み）"></h1>
これならいけるわ。altをひらがなにすればね。
でも結局漢字でないと困るという場合は見出しにはつかっちゃやーよ。
<h1><img src="moji.jpg" alt="（読み）"></h1>
これならいけるわ。altをひらがなにすればね。
でも結局漢字でないと困るという場合は見出しにはつかっちゃやーよ。
816 ：Name_Not_Found：04/09/01 00:19 ID:???
>>814
ますます賛同できん。
俺のPCで変換できるけど彼のPCではどうやら上記の諸事情からか表示できない、
っていう理由から俺の書いた文書が非Strictになり得るってことにならんかそれは。
ルールではこう決まってるけど現状対応できないからそれは非Strict、とか。
# 画像化する是非でなくて変換可能・不可能な文字を見出しに、に話題は移ってるよね？
Unicodeでどこどこに割り当てますよ、でもまだ対応してるフォントはありませんよ、
ってな文字を見出しに含めることは強引でStrictでないのか？
ますます賛同できん。
俺のPCで変換できるけど彼のPCではどうやら上記の諸事情からか表示できない、
っていう理由から俺の書いた文書が非Strictになり得るってことにならんかそれは。
ルールではこう決まってるけど現状対応できないからそれは非Strict、とか。
# 画像化する是非でなくて変換可能・不可能な文字を見出しに、に話題は移ってるよね？
Unicodeでどこどこに割り当てますよ、でもまだ対応してるフォントはありませんよ、
ってな文字を見出しに含めることは強引でStrictでないのか？
818 ：Name_Not_Found：04/09/01 00:45 ID:???
A heading element briefly describes the topic of the section it introduces.
なんだから「……について」"Re:"を付ければなんでもOKな希ガス。
なんだから「……について」"Re:"を付ければなんでもOKな希ガス。
819 ：Name_Not_Found：04/09/01 00:52 ID:???
html及びxhtml等のファイルで文章の構造的に書くため
インデントをつけて記述してるやつが多いはずだが、その際に
半角スペースでインデントをとってるやつは頭悪いんだろ？
同じインデントの数でもtabでインデントをとった方がファイルが軽くなるんだから
あとタグのあとに無駄に半角スペースとってるやつも死ね
インデントなんてなくてもいいってやつはhtmlの文章構造理解しる
インデントをつけて記述してるやつが多いはずだが、その際に
半角スペースでインデントをとってるやつは頭悪いんだろ？
同じインデントの数でもtabでインデントをとった方がファイルが軽くなるんだから
あとタグのあとに無駄に半角スペースとってるやつも死ね
インデントなんてなくてもいいってやつはhtmlの文章構造理解しる
820 ：Name_Not_Found：04/09/01 00:58 ID:???
>>819
よくわかりません。
よくわかりません。
821 ：Name_Not_Found：04/09/01 01:01 ID:???
スレ違いはスルーよろ
822 ：Name_Not_Found：04/09/01 01:05 ID:???
HTTPのContent-Encodingとか使って圧縮して送れば問題なし
823 ：Name_Not_Found：04/09/01 01:10 ID:???
824 ：Name_Not_Found：04/09/01 01:11 ID:???
728 ：Name_Not_Found ：04/09/01 00:34 ID:???
タグの書き方なんですが、手打ちで書いてるんですが、最初のスペースって入れない方が見栄えいいんですか？
ソフトだと適度に空白ありますよね。
<table>
<tr>
とか。
きれいに書けるってどういうのなんでしょう？
729 ：Name_Not_Found ：04/09/01 00:35 ID:???
あ。スペースはいってない。
730 ：Name_Not_Found ：04/09/01 00:35 ID:???
自分の見やすいようにどうぞ。
731 ：Name_Not_Found ：04/09/01 00:37 ID:???
>>725
そこは俺ん家だ。
732 ：Name_Not_Found ：04/09/01 00:40 ID:???
>>728
貴方が見やすいようにすれば良い。
でも入れるなら、タブでインデントさせるがスマートだとおもう。
#####コピペ終わり######
多分ここら辺が絡んでるだろうよ。ちなみに初心者スレね。
タグの書き方なんですが、手打ちで書いてるんですが、最初のスペースって入れない方が見栄えいいんですか？
ソフトだと適度に空白ありますよね。
<table>
<tr>
とか。
きれいに書けるってどういうのなんでしょう？
729 ：Name_Not_Found ：04/09/01 00:35 ID:???
あ。スペースはいってない。
730 ：Name_Not_Found ：04/09/01 00:35 ID:???
自分の見やすいようにどうぞ。
731 ：Name_Not_Found ：04/09/01 00:37 ID:???
>>725
そこは俺ん家だ。
732 ：Name_Not_Found ：04/09/01 00:40 ID:???
>>728
貴方が見やすいようにすれば良い。
でも入れるなら、タブでインデントさせるがスマートだとおもう。
#####コピペ終わり######
多分ここら辺が絡んでるだろうよ。ちなみに初心者スレね。
825 ：Name_Not_Found：04/09/01 03:11 ID:???
で、headingの件だが、
要約がテキストではなく図でもいいと思うんだ。
それがセクションの内容を端的に表わしていれば。
要約がテキストではなく図でもいいと思うんだ。
それがセクションの内容を端的に表わしていれば。
826 ：Name_Not_Found：04/09/01 03:21 ID:???
仮にかまわないとしてもHTML4.01の場合、全ての画像は
代理となるテキストに置き換え可能なように
（或いは置き換え不可能である事を、画像が表示できない環境の人に伝わるように）
しておく事が前提なので、そこんところよろ。
あと、headingと要約は違うから。
代理となるテキストに置き換え可能なように
（或いは置き換え不可能である事を、画像が表示できない環境の人に伝わるように）
しておく事が前提なので、そこんところよろ。
あと、headingと要約は違うから。
827 ：Name_Not_Found：04/09/01 04:59 ID:???
とりあえず、strictな見出しのルールをまとめよう。
１．本文中に見出しを参照して話を進めない
２．画像はテキストに置き換え可能なもの
３．あくまでも本文の要約なので、見出しがなくなっても文章として破綻しない
くらいかな？で、thってどうなのかな？
仕様書和訳では「見出し情報を含むコマ」となってるけどこの場合は見出しといっても
要約とは違って、なんのデータなのかの説明的な役割を持っている。
って・・・・・ここまで書いて、thでは別に使う時に疑問なんてない気がしてきたからやめた；
１．本文中に見出しを参照して話を進めない
２．画像はテキストに置き換え可能なもの
３．あくまでも本文の要約なので、見出しがなくなっても文章として破綻しない
くらいかな？で、thってどうなのかな？
仕様書和訳では「見出し情報を含むコマ」となってるけどこの場合は見出しといっても
要約とは違って、なんのデータなのかの説明的な役割を持っている。
って・・・・・ここまで書いて、thでは別に使う時に疑問なんてない気がしてきたからやめた；
828 ：Name_Not_Found：04/09/01 05:30 ID:LNwphhA3
<p>のデフォルトの見栄えをあえてCSSであらわすとどうなりますか？
p{
margin-left:30px;
}
なんてことをやっちまったもんだから、
p.defaultで、元来のpの見栄えを表現したい・・・
p{
margin-left:30px;
}
なんてことをやっちまったもんだから、
p.defaultで、元来のpの見栄えを表現したい・・・
すいません、ごばくりました。
830 ：Name_Not_Found：04/09/01 07:18 ID:???
>>827
2はheadingに限らないので冗長では?
2はheadingに限らないので冗長では?
831 ：Name_Not_Found：04/09/01 07:30 ID:???
832 ：Name_Not_Found：04/09/01 07:51 ID:???
そうか、本文ありきの見出しか。
今までまず見出しでアウトライン書いてそれから本文書いてたから逆だと思ってた。
でもheadingはそのセクションのトピックを簡潔に記載していればいいんだからそれを参照していいかどうかは別の問題だと思う。
headingだけが抜き出されることはあっても本文だけが抜き出されることってあるんだろうか。
ニュー速とかだとあるか。でも見出しも本文に関係しているときは見出しも転載されてるな。
固い文章とかだと見出しと本文は分離されてなきゃいけないんだろうけどそうでもない文章なら本文がheadingに依存しててもいいんじゃないんだろうか。
今までまず見出しでアウトライン書いてそれから本文書いてたから逆だと思ってた。
でもheadingはそのセクションのトピックを簡潔に記載していればいいんだからそれを参照していいかどうかは別の問題だと思う。
headingだけが抜き出されることはあっても本文だけが抜き出されることってあるんだろうか。
ニュー速とかだとあるか。でも見出しも本文に関係しているときは見出しも転載されてるな。
固い文章とかだと見出しと本文は分離されてなきゃいけないんだろうけどそうでもない文章なら本文がheadingに依存しててもいいんじゃないんだろうか。
833 ：Name_Not_Found：04/09/01 08:59 ID:???
見出しを参照しない本文って、こういうレベルでもか？
h1 ２００４年９月の日記
h2 １日（水曜日）
p 「今日」は……
h2は上位の見出しのh1を参照してるよな？「１日」だけじゃ日記の
見出しとして意味不明だよな。
pの「今日は」という表現は更にそのh2を参照してるよな。例えばそこだけ
第三者が引用したりすると結局いつの事なのか理解できないしな。
でも、こういうレベルでの見出しの参照って、HTMLとか紙とかメディアに
関わらず一般的に「上位の見出しを参照する物だ」って共通認識が
すでにあるよな？ つまり、一般的に「そのように解釈されるべき」という
解釈が確立されているんだから問題ないんじゃないのか？
それともこれは今からでも改めるべき悪しき共通認識なのか？
h1 ２００４年９月の日記
h2 １日（水曜日）
p 「今日」は……
h2は上位の見出しのh1を参照してるよな？「１日」だけじゃ日記の
見出しとして意味不明だよな。
pの「今日は」という表現は更にそのh2を参照してるよな。例えばそこだけ
第三者が引用したりすると結局いつの事なのか理解できないしな。
でも、こういうレベルでの見出しの参照って、HTMLとか紙とかメディアに
関わらず一般的に「上位の見出しを参照する物だ」って共通認識が
すでにあるよな？ つまり、一般的に「そのように解釈されるべき」という
解釈が確立されているんだから問題ないんじゃないのか？
それともこれは今からでも改めるべき悪しき共通認識なのか？
834 ：Name_Not_Found：04/09/01 10:49 ID:???
流れと関係ないんだけど、日記にアンカーを用意する方法でちょっと気になって。
いろいろこのスレでも話が出てるけど、結構曖昧で終結してるものが多かったので。
<h2 id="DIARY2"><a href="#DIARY2">9/2</a> 牛鮭を食べ過ぎました</h2>
<h2 id="DIARY2"><a href="#DIARY2">9/2 牛鮭を食べ過ぎました</a></h2>
<h2><a href="#DIARY2"name="DIARY2">9/2</a> 牛鮭を食べ過ぎました</h2>
<h2><a href="#DIARY2"name="DIARY2">9/2 牛鮭を食べ過ぎました</a></h2>
4つほど考えて見たんだけど、
そもそもアンカーにリンクを用意しない方がいい、のかな。
いろいろこのスレでも話が出てるけど、結構曖昧で終結してるものが多かったので。
<h2 id="DIARY2"><a href="#DIARY2">9/2</a> 牛鮭を食べ過ぎました</h2>
<h2 id="DIARY2"><a href="#DIARY2">9/2 牛鮭を食べ過ぎました</a></h2>
<h2><a href="#DIARY2"name="DIARY2">9/2</a> 牛鮭を食べ過ぎました</h2>
<h2><a href="#DIARY2"name="DIARY2">9/2 牛鮭を食べ過ぎました</a></h2>
4つほど考えて見たんだけど、
そもそもアンカーにリンクを用意しない方がいい、のかな。
835 ：Name_Not_Found：04/09/01 10:51 ID:???
もれはこんな風にしているが。
<hｎ>日記</hn>
<dl><dt>9月1日</dt>
<dd><p>今日は朝起きて昼働いて夜略</p></dd>
ｄｌはこういうときに使うもんじゃないか、と思ってるのだが如何？
<hｎ>日記</hn>
<dl><dt>9月1日</dt>
<dd><p>今日は朝起きて昼働いて夜略</p></dd>
ｄｌはこういうときに使うもんじゃないか、と思ってるのだが如何？
836 ：Name_Not_Found：04/09/01 10:57 ID:???
>>835
あ、質問の内容はhn+pでもdt+ddでもどっちでもいいんです。
御伺いしたい部分は、
参照のためのアンカーを用意しても、明示しておかないとアンカーが用意されてるってわかりにくいですし、
慣例的に「そのタイトル自体に自身へのリンクを設ける」というのがありますが、
その話題が出るたびに「それはおかしい」説と、「それでいいんじゃない？」説が出て有耶無耶で終わってたので。
文書の下部に、「この文章への参照はhttp://〜」というのが一番なんですかね。
正直わかりかねる状態なので、ご意見いただけると幸いです。
あ、質問の内容はhn+pでもdt+ddでもどっちでもいいんです。
御伺いしたい部分は、
参照のためのアンカーを用意しても、明示しておかないとアンカーが用意されてるってわかりにくいですし、
慣例的に「そのタイトル自体に自身へのリンクを設ける」というのがありますが、
その話題が出るたびに「それはおかしい」説と、「それでいいんじゃない？」説が出て有耶無耶で終わってたので。
文書の下部に、「この文章への参照はhttp://〜」というのが一番なんですかね。
正直わかりかねる状態なので、ご意見いただけると幸いです。
>>835
誤解してました。私へのレスじゃなくて、hの話題へのレスだったんですねoTZ
誤解してました。私へのレスじゃなくて、hの話題へのレスだったんですねoTZ
838 ：Name_Not_Found：04/09/01 11:08 ID:???
そもそもアンカーをつけるのが非Strictとか。
>>838
id振るのもダメですか？
id振るのもダメですか？
840 ：Name_Not_Found：04/09/01 11:20 ID:???
<link rel="bookmark" とか
841 ：Name_Not_Found：04/09/01 11:23 ID:???
レスポンスアンカーなしでの書き込みはレスポンスアンカーありの書き込みを非strictだと思ってるからなのかな？
どれへのレスかわかりにくいんだけど。
どれへのレスかわかりにくいんだけど。
842 ：Name_Not_Found：04/09/01 11:32 ID:???
×Opera
○Mozilla
○Mozilla
844 ：Name_Not_Found：04/09/01 11:56 ID:???
>>843
デフォルトの実装はOperaとMozillaだけど、その他のブラウザも(IEも)
拡張入れれば大体使える。
ちなみに、bookmarkLetで利用している人なんかもいる（と言うか俺）から
デフォルト実装の有無とそのブラウザのシェアを考えても
余り意味がなかったりする。
デフォルトの実装はOperaとMozillaだけど、その他のブラウザも(IEも)
拡張入れれば大体使える。
ちなみに、bookmarkLetで利用している人なんかもいる（と言うか俺）から
デフォルト実装の有無とそのブラウザのシェアを考えても
余り意味がなかったりする。
845 ：Name_Not_Found：04/09/01 12:06 ID:???
>>844
完全にｽﾚ違い（ここでは実装は不問）なのに、お答えいただき感謝。
「実装してなかろうが関係ない」とは思うものの、
実用性がないと面倒だしなぁ、って気持が勝ってしまうなぁ。
600ほどファイルあるし……。
完全にｽﾚ違い（ここでは実装は不問）なのに、お答えいただき感謝。
「実装してなかろうが関係ない」とは思うものの、
実用性がないと面倒だしなぁ、って気持が勝ってしまうなぁ。
600ほどファイルあるし……。
846 ：Name_Not_Found：04/09/01 12:55 ID:???
847 ：Name_Not_Found：04/09/01 13:05 ID:???
>>846
CSSは関係ないと思う。
CSSは関係ないと思う。
848 ：Name_Not_Found：04/09/01 13:19 ID:???
>>845
こう言う話題こそ新スレの出番では？
こう言う話題こそ新スレの出番では？
849 ：Name_Not_Found：04/09/01 13:27 ID:???
850 ：Name_Not_Found：04/09/01 13:29 ID:???
851 ：Name_Not_Found：04/09/01 13:35 ID:???
>>850
口悪いけど優しいな
口悪いけど優しいな
852 ：Name_Not_Found：04/09/01 13:50 ID:???
>>833
というか俺は>827の2.が曖昧でちょっと気持ち悪いのだが。
テキストに置き換え不可能なものってどんな画像だ？
甲骨文字だって「〜〜の元になった文字で、あれがこうなってこれがこうなって」とか、
冗長な表現を嫌わなければテキスト化が不可能なことはないはずだ。
（それが理解できるものになるかどうかはテキスト化したやつの能力次第）
というか俺は>827の2.が曖昧でちょっと気持ち悪いのだが。
テキストに置き換え不可能なものってどんな画像だ？
甲骨文字だって「〜〜の元になった文字で、あれがこうなってこれがこうなって」とか、
冗長な表現を嫌わなければテキスト化が不可能なことはないはずだ。
（それが理解できるものになるかどうかはテキスト化したやつの能力次第）
853 ：Name_Not_Found：04/09/01 14:02 ID:???
>>852
例えば絵描きサイトなんかが、「自分の絵を見て欲しい」とおもって画像を
公開している場合、「○○というマンガの××というキャラクターを私が書いた絵」
とか、更に詳細にどんな立ち位置で、どんな服装で、と伝えても、
意味ない訳よ。それらは飽くまで絵の解説にしか成らず、
作者が真に伝えたいのは「絵という画像情報」であり、
作者の真の目的は「自分の絵に何らかの感想を持って欲しい」なのだから。
これはテキストを書く奴、読む奴の能力の問題ではなく
そもそも、テキストとイメージではメディアがちがうとしかいいようがないわけだから、
しょうがない。
もし、「そんなことはない」と思うなら、試しに生来全盲の奴に「赤」という
色を伝えるテキストを書いてみてくれ。色すら伝えられないならイメージ情報が
伝えられないのはなおのこと。
例えば絵描きサイトなんかが、「自分の絵を見て欲しい」とおもって画像を
公開している場合、「○○というマンガの××というキャラクターを私が書いた絵」
とか、更に詳細にどんな立ち位置で、どんな服装で、と伝えても、
意味ない訳よ。それらは飽くまで絵の解説にしか成らず、
作者が真に伝えたいのは「絵という画像情報」であり、
作者の真の目的は「自分の絵に何らかの感想を持って欲しい」なのだから。
これはテキストを書く奴、読む奴の能力の問題ではなく
そもそも、テキストとイメージではメディアがちがうとしかいいようがないわけだから、
しょうがない。
もし、「そんなことはない」と思うなら、試しに生来全盲の奴に「赤」という
色を伝えるテキストを書いてみてくれ。色すら伝えられないならイメージ情報が
伝えられないのはなおのこと。
854 ：Name_Not_Found：04/09/01 14:03 ID:???
855 ：Name_Not_Found：04/09/01 14:41 ID:???
856 ：Name_Not_Found：04/09/01 14:51 ID:???
> イラストは視覚的効果を大前提としているから全く別の問題のように思えるが。
というならば、まず、見出しとなり得る画像は「視覚的効果を大前提としてない」
と証明…とはいわないまでも、一般的にそうだ、という共通認識がないと話が続かない。
おまえさんの主張だと、「全ての見出しになり得る画像はテキストに代用可能だから
代用可能なのだ」というトートロジーにしかならない。
というならば、まず、見出しとなり得る画像は「視覚的効果を大前提としてない」
と証明…とはいわないまでも、一般的にそうだ、という共通認識がないと話が続かない。
おまえさんの主張だと、「全ての見出しになり得る画像はテキストに代用可能だから
代用可能なのだ」というトートロジーにしかならない。
857 ：Name_Not_Found：04/09/01 15:18 ID:???
むしろ「見出しになり得るがテキスト化不可能な画像」を出せと
858 ：Name_Not_Found：04/09/01 15:45 ID:???
おーい、話がずれてんぞー。
>>852 は >>827 が
>画像はテキストに置き換え可能なもの
と言ったのに対して、
> テキストに置き換え不可能なものってどんな画像だ？
と言った訳。
で、それに対して >>853 テキストに置き換え不可能な画像が存在することを示した訳。
これに対する反応は
「テキストに置き換え不可能な画像が存在することを認め、 >>827 の主張も認める」
「それでも全ての画像はテキストは置き換え可能であり、 >>827 の主張は冗長である」
と主張するかのどっちかなの。
もし本気で
> むしろ「見出しになり得るがテキスト化不可能な画像」を出せと
というなら、つまりそれは >>827 への遠回しな賛同に他ならないわけで、
>>827 とも >>852 とも競合しない意見な訳だが…。
大丈夫か？
>>852 は >>827 が
>画像はテキストに置き換え可能なもの
と言ったのに対して、
> テキストに置き換え不可能なものってどんな画像だ？
と言った訳。
で、それに対して >>853 テキストに置き換え不可能な画像が存在することを示した訳。
これに対する反応は
「テキストに置き換え不可能な画像が存在することを認め、 >>827 の主張も認める」
「それでも全ての画像はテキストは置き換え可能であり、 >>827 の主張は冗長である」
と主張するかのどっちかなの。
もし本気で
> むしろ「見出しになり得るがテキスト化不可能な画像」を出せと
というなら、つまりそれは >>827 への遠回しな賛同に他ならないわけで、
>>827 とも >>852 とも競合しない意見な訳だが…。
大丈夫か？
859 ：Name_Not_Found：04/09/01 16:18 ID:???
>>832-833
見出しには二つの使い方がある。
１．本文の要約としての見出し（本文ありきの見出し）
２．文章のヘッダとしての見出し（見出しありきの本文）
問題はhnを２として使うことをW3Cはどう考えているかだね。HTML4.01の仕様が
１、２共に使用可能であるならば両方strict。前者のみならば２は非strict。
通常１はhn、２は定義リスト or thでやるのがもっともstrictだと考えられる。
>>その他画像関連のレスの皆へ
画像を完璧にテキストで代替できないという意見が多いけど、それは同意。
しかしhn要素にテキストで代替できない画像を使うのはいかがか・・・・
俺はhnは前文の１の使い方のみがstrictであると考えている。だから要約に代替不可能、
しかし伝えなきゃいけないものを使うのはよくないと思う。定義リストの場合は
テキスト代替不可画像を使うのは問題ない。
見出しには二つの使い方がある。
１．本文の要約としての見出し（本文ありきの見出し）
２．文章のヘッダとしての見出し（見出しありきの本文）
問題はhnを２として使うことをW3Cはどう考えているかだね。HTML4.01の仕様が
１、２共に使用可能であるならば両方strict。前者のみならば２は非strict。
通常１はhn、２は定義リスト or thでやるのがもっともstrictだと考えられる。
>>その他画像関連のレスの皆へ
画像を完璧にテキストで代替できないという意見が多いけど、それは同意。
しかしhn要素にテキストで代替できない画像を使うのはいかがか・・・・
俺はhnは前文の１の使い方のみがstrictであると考えている。だから要約に代替不可能、
しかし伝えなきゃいけないものを使うのはよくないと思う。定義リストの場合は
テキスト代替不可画像を使うのは問題ない。
860 ：Name_Not_Found：04/09/01 17:01 ID:???
ページ内検索出来ないんで画像はやめてください
とStrictスレで言ってみる
とStrictスレで言ってみる
861 ：Name_Not_Found：04/09/01 17:09 ID:???
それは見出し論議に関係なくHTML文書全般に関して？
確かに検索などの時に（画像に限らず）テキスト以外のデータが
使い勝手が悪いことは確かだが、作り手がその点に十分留意していれば
マルチメディアの利便性をすててまでテキストに拘る必要は無いかと思われ。
っていうか、alt要素とか、仕様に沿って適切に使えば、
概ねベストとはいえなくてもベターなテキスト検索によるアクセス性は
得られるかと思われ。
確かに検索などの時に（画像に限らず）テキスト以外のデータが
使い勝手が悪いことは確かだが、作り手がその点に十分留意していれば
マルチメディアの利便性をすててまでテキストに拘る必要は無いかと思われ。
っていうか、alt要素とか、仕様に沿って適切に使えば、
概ねベストとはいえなくてもベターなテキスト検索によるアクセス性は
得られるかと思われ。
862 ：Name_Not_Found：04/09/01 17:10 ID:???
画像に頼りすぎるとハイパー*テキスト*ではなくなってしまうな。
863 ：Name_Not_Found：04/09/01 17:18 ID:???
そりゃまぁ、ハイパーなテキストなんだから、テキストじゃないよな。うん。
そもそも、シオドアネルソンの考えたハイパーテキストは、
既存のテキストの概念を打ち破って、様々なオブジェクトが相互に参照しあうから
ハイパーなテキストな訳で。
そもそも、シオドアネルソンの考えたハイパーテキストは、
既存のテキストの概念を打ち破って、様々なオブジェクトが相互に参照しあうから
ハイパーなテキストな訳で。
864 ：Name_Not_Found：04/09/01 17:34 ID:???
ハイパーではあるがテキストではない。
# 関係ないけど、「現実的Strictスレ」とかないのかな。
# 関係ないけど、「現実的Strictスレ」とかないのかな。
865 ：Name_Not_Found：04/09/01 18:21 ID:???
<META HTTP-EQUIV="CONTENT-TYPE"> は NN行目にもありました。 **
誤りではないのかも知れませんが、一度にしておいた方が無難でしょう。
HTTP-EQUIV="REFRESH" に対しても同様の警告が出ます。
Another HTML-lintでチェックしたらこのような警告が出ました。
CSSとJAVASCRIPTの両方を使いたいときには、
<META HTTP-EQUIV="CONTENT-TYPE">を二回書く必要があると思っていたのですが、
その辺はどうなっているのでしょうか？回答お願いします。
誤りではないのかも知れませんが、一度にしておいた方が無難でしょう。
HTTP-EQUIV="REFRESH" に対しても同様の警告が出ます。
Another HTML-lintでチェックしたらこのような警告が出ました。
CSSとJAVASCRIPTの両方を使いたいときには、
<META HTTP-EQUIV="CONTENT-TYPE">を二回書く必要があると思っていたのですが、
その辺はどうなっているのでしょうか？回答お願いします。
866 ：Name_Not_Found：04/09/01 18:24 ID:???
夏ですごく書き込みが盛んだね。わかりやすいｗｗ
867 ：Name_Not_Found：04/09/01 18:24 ID:???
>>865
Content-Style-Typeとか混同してるでしょ。解説嫁
Content-Style-Typeとか混同してるでしょ。解説嫁
868 ：Name_Not_Found：04/09/01 18:27 ID:???
何故 Content-Type を二回書く必要があるんだろう。
Content-Style-Type や Content-Script-Type と間違ってるのかな。
Content-Style-Type や Content-Script-Type と間違ってるのかな。
リロード忘れた。>>867 とハネムーンいってくる。
870 ：Name_Not_Found：04/09/01 20:55 ID:???
虫同志が何をやってんだか
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼ / ＼
871 ：Name_Not_Found：04/09/01 20:58 ID:???
They are honeymooning in 2ch
872 ：Name_Not_Found：04/09/01 23:14 ID:???
たとえば UA が html の heading を一覧とか列挙してくれたときに、
何が並べば便利か、って事が大事ではないのか？
意味云々というよりは、プラクティカルな面での利便性を考えればどうよ。
ま、これは内容がいわゆる「文書」だった時の話だが。
何が並べば便利か、って事が大事ではないのか？
意味云々というよりは、プラクティカルな面での利便性を考えればどうよ。
ま、これは内容がいわゆる「文書」だった時の話だが。
873 ：Name_Not_Found：04/09/02 01:18 ID:???
874 ：Name_Not_Found：04/09/02 01:19 ID:???
>>873
普通に誘導してやれよ
>>872
【W3C】Web標準仕様・技術系総合スレッド その1＠Web制作
ttp://pc5.2ch.net/test/read.cgi/hp/1093950965/l50
普通に誘導してやれよ
>>872
【W3C】Web標準仕様・技術系総合スレッド その1＠Web制作
ttp://pc5.2ch.net/test/read.cgi/hp/1093950965/l50
875 ：Name_Not_Found：04/09/02 01:55 ID:???
>>873
いやいや…こう書いとくと便利だろうなと考えた結果HTMLはStrictになったんだよ。
何となく思いつきでStrictってのを考えたらみんなでやってみましょう…なんて分けないじゃん。
ただ、誰にとって便利かどう便利か、と言うのが必ずしもHTML記述者だったり、
読者だったりしないと言うだけ。
いやいや…こう書いとくと便利だろうなと考えた結果HTMLはStrictになったんだよ。
何となく思いつきでStrictってのを考えたらみんなでやってみましょう…なんて分けないじゃん。
ただ、誰にとって便利かどう便利か、と言うのが必ずしもHTML記述者だったり、
読者だったりしないと言うだけ。
876 ：Name_Not_Found：04/09/02 01:56 ID:???
877 ：Name_Not_Found：04/09/02 02:01 ID:???
>>876
いや、ここは正当さのみ、で便利かどうか、は違う、って言いたいだけですよ。
いや、ここは正当さのみ、で便利かどうか、は違う、って言いたいだけですよ。
878 ：Name_Not_Found：04/09/02 02:01 ID:???
昔から話題は少ないよこのスレ
879 ：Name_Not_Found：04/09/02 02:04 ID:???
>>878
排除するから仕方ない。
排除するから仕方ない。
880 ：Name_Not_Found：04/09/02 02:24 ID:???
それで良いと思うよ
881 ：Name_Not_Found：04/09/02 02:29 ID:???
いつもの寂れ加減ではないか
882 ：Name_Not_Found：04/09/02 04:39 ID:???
>>872>>875
>いやいや…こう書いとくと便利だろうなと考えた結果HTMLはStrictになったんだよ。
構造と見栄えの分離というStrict志向は、便利さを求めた結果と捉えることもできるかもしれない。
しかし、Strictとは便利さを追求したコーディングではなく、構造と見栄えの分離のために論理的にマークアップすることである。
もしかしてお前馬鹿？このスレでアフォなこと言ってると叩くよ。
>いやいや…こう書いとくと便利だろうなと考えた結果HTMLはStrictになったんだよ。
構造と見栄えの分離というStrict志向は、便利さを求めた結果と捉えることもできるかもしれない。
しかし、Strictとは便利さを追求したコーディングではなく、構造と見栄えの分離のために論理的にマークアップすることである。
もしかしてお前馬鹿？このスレでアフォなこと言ってると叩くよ。
883 ：Name_Not_Found：04/09/02 05:13 ID:???
>>882
厨だなｵﾏｲ。
厨だなｵﾏｲ。
884 ：Name_Not_Found：04/09/02 10:53 ID:???
CSSの話を持ち込む香具師は消えてくれ
885 ：Name_Not_Found：04/09/02 11:22 ID:???
じゃあCCSで
886 ：Name_Not_Found：04/09/02 11:37 ID:???
経緯からすれば多少あるかも
887 ：Name_Not_Found：04/09/02 13:53 ID:???
888 ：Name_Not_Found：04/09/02 16:55 ID:???
889 ：Name_Not_Found：04/09/02 17:24 ID:???
藻前らネタはこっちでな。
ttp://pc5.2ch.net/test/read.cgi/hp/1071673655/l50
ttp://pc5.2ch.net/test/read.cgi/hp/1071673655/l50
890 ：Name_Not_Found：04/09/02 19:59 ID:???
>>888
混同していたものを分離して片方を「Strict」と呼んだのだから当たり前
混同していたものを分離して片方を「Strict」と呼んだのだから当たり前
891 ：Name_Not_Found：04/09/02 20:13 ID:???
ばーかばーか
892 ：Name_Not_Found：04/09/02 21:17 ID:???
>>888
>そもそもStrictに見栄えの概念は基本的に無いのだから分離も何も無い。
ここらへんはstrictとは何か？によるな。
１．論理的にマークアップすること strict-HTML
２．見栄えと構造の分離 strict-HTML+CSSレイアウト
strict志向ってのは１でも２でも間違いではないな。まあお前らレベル低すぎだな。
>そもそもStrictに見栄えの概念は基本的に無いのだから分離も何も無い。
ここらへんはstrictとは何か？によるな。
１．論理的にマークアップすること strict-HTML
２．見栄えと構造の分離 strict-HTML+CSSレイアウト
strict志向ってのは１でも２でも間違いではないな。まあお前らレベル低すぎだな。
893 ：Name_Not_Found：04/09/02 21:26 ID:???
>>888
strictDTDで<span class="red">（赤く表示したい）はvalidだけど、strict志向じゃない、とかそういうことじゃないの？
strictDTDで<span class="red">（赤く表示したい）はvalidだけど、strict志向じゃない、とかそういうことじゃないの？
894 ：Name_Not_Found：04/09/03 00:45 ID:???
class まで拒絶されたら、Strict-HTML + CSS ってなんだよｗ
そんなクマで俺様がエサー
896 ：Name_Not_Found：04/09/03 01:30 ID:???
>>894
やぁ、フィッシャーマン。
>893の例はclassがstrict志向じゃないといっているのではなくて、
class="red"と赤く表示したいという見栄えから来る属性値を与えることがstrict志向じゃないといってるんだよ
やぁ、フィッシャーマン。
>893の例はclassがstrict志向じゃないといっているのではなくて、
class="red"と赤く表示したいという見栄えから来る属性値を与えることがstrict志向じゃないといってるんだよ
897 ：Name_Not_Found：04/09/03 02:20 ID:???
898 ：Name_Not_Found：04/09/03 02:28 ID:???
899 ：Name_Not_Found：04/09/03 03:01 ID:???
大将、今日は何がおいしいかな
900 ：Name_Not_Found：04/09/03 03:08 ID:???
>>898
それすら依然として見栄えではない、とか。
つまり、class="red" は redという値を持つclass属性であって、それ以上の何者でもない。
HTMLが表現する構造はそれだけであり、それが一般に考えられるred (赤いもの) を表さない。
言ってみればHTML上にあるclass="red"はラングであり、パロールではない、とかなんとか。
それすら依然として見栄えではない、とか。
つまり、class="red" は redという値を持つclass属性であって、それ以上の何者でもない。
HTMLが表現する構造はそれだけであり、それが一般に考えられるred (赤いもの) を表さない。
言ってみればHTML上にあるclass="red"はラングであり、パロールではない、とかなんとか。
901 ：Name_Not_Found：04/09/03 03:23 ID:???
>>898
そして俺はstrict志向とはなんぞやを補足しておいたのさ＾＾ウヒョウヒョｈｙｏｈｙｏ
>>900
classの値が論理的な意味を成してなければ結局非strictだよん。
しかもパロールじゃなくてトロールの痛恨の一撃でゲームオーバーだよん＾＾＾＾＾＾＾＾＾
だって黄金のツメって装備するより売って、オオバサミとか買うほうが強く慣れるんだもん！
カンダタだって楽勝さ＾＾
そういえば
そして俺はstrict志向とはなんぞやを補足しておいたのさ＾＾ウヒョウヒョｈｙｏｈｙｏ
>>900
classの値が論理的な意味を成してなければ結局非strictだよん。
しかもパロールじゃなくてトロールの痛恨の一撃でゲームオーバーだよん＾＾＾＾＾＾＾＾＾
だって黄金のツメって装備するより売って、オオバサミとか買うほうが強く慣れるんだもん！
カンダタだって楽勝さ＾＾
そういえば
902 ：Name_Not_Found：04/09/03 03:30 ID:???
>>901
Strictか非Strictかに関係なく、見栄えの概念は存在しないという話ね。
Strictか非Strictかに関係なく、見栄えの概念は存在しないという話ね。
903 ：Name_Not_Found：04/09/03 03:38 ID:???
別にclassはサイト作成者のためにしか意味をもたないから
redだのつけまくっていいよ。その後のメンテナンスへの
支障は知らないが。
redだのつけまくっていいよ。その後のメンテナンスへの
支障は知らないが。
904 ：Name_Not_Found：04/09/03 03:56 ID:???
905 ：Name_Not_Found：04/09/03 03:57 ID:???
>>903
非Strict
非Strict
906 ：Name_Not_Found：04/09/03 05:52 ID:???
イデア的HTMLなら確かに見栄えの概念そのものが存在しないから、>900のような論も成り立つだろうけど、
ここで考えるべきはそんな哲学的な話じゃなくて、工学的な問題なんだよ。
現実問題として、ＨＴＭＬを記述するのは人間で、その記述過程においてclassの属性値に見栄えを意識して値を与えてしまえば、
その属性値は見栄えに汚染されていることになる。その結果、メンテナンスに支障がでるようになる。
それではいけないという話でしょ。
面白い考えだとは思ったけど、現実を見ようよ。
ここで考えるべきはそんな哲学的な話じゃなくて、工学的な問題なんだよ。
現実問題として、ＨＴＭＬを記述するのは人間で、その記述過程においてclassの属性値に見栄えを意識して値を与えてしまえば、
その属性値は見栄えに汚染されていることになる。その結果、メンテナンスに支障がでるようになる。
それではいけないという話でしょ。
面白い考えだとは思ったけど、現実を見ようよ。
908 ：Name_Not_Found：04/09/03 16:24 ID:???
909 ：Name_Not_Found：04/09/03 17:21 ID:???
一々罵りの言葉付け加えてるやつって絶対同一人物だよな。
つーか、見栄えを考えているならばStrictではないわけで、
即ちStrictであるならば見栄えを考えていないのだという話ですが……？
即ちStrictであるならば見栄えを考えていないのだという話ですが……？
911 ：Name_Not_Found：04/09/03 17:48 ID:???
構造と見栄えを分離したものがStrictである、に一票。
卵が先か鶏が先か、の話になるが、
もともと見栄えも構造も一緒くたになっていたものを分離させたのがStrict。
だからStrictに見栄えの概念がないのは当たり前。CSSに放り投げたからな。
分離していることが大前提。
>>882は経緯を含めてStrictを述べ、>>888は現状定義されているStrictを述べている。
卵が先か鶏が先か、の話になるが、
もともと見栄えも構造も一緒くたになっていたものを分離させたのがStrict。
だからStrictに見栄えの概念がないのは当たり前。CSSに放り投げたからな。
分離していることが大前提。
>>882は経緯を含めてStrictを述べ、>>888は現状定義されているStrictを述べている。
912 ：Name_Not_Found：04/09/03 18:15 ID:???
>>910
見栄えを考えていても、論理的であればstrictだよ。
例えば、class=redがCSSで与えるプロパティと値から来ては駄目だが、
<ol>
<li class=first>あ
<li>い
</ol>
のclass=firstは、CSSでfirst-childが使えないブラウザを考慮してのこと。
いわゆる見栄えを考えた結果だけど、論理的でもあるから問題ない。
だから見栄えを考えてもいいが、論理的にも意味が通じないといけないってことだね＾＾
見栄えを考えていても、論理的であればstrictだよ。
例えば、class=redがCSSで与えるプロパティと値から来ては駄目だが、
<ol>
<li class=first>あ
<li>い
</ol>
のclass=firstは、CSSでfirst-childが使えないブラウザを考慮してのこと。
いわゆる見栄えを考えた結果だけど、論理的でもあるから問題ない。
だから見栄えを考えてもいいが、論理的にも意味が通じないといけないってことだね＾＾
913 ：Name_Not_Found：04/09/03 18:57 ID:???
個人的にはclass属性は使わなくて済むようにしたいね。
XPointerなりなんなりでスタイルシート側から要素を特定したい。
まぁ、現状では無理があるが。
XPointerなりなんなりでスタイルシート側から要素を特定したい。
まぁ、現状では無理があるが。
914 ：Name_Not_Found：04/09/03 19:19 ID:???
>>913
以前は漏れもclassだのの属性を嫌っていたんだけど、
例えば>>912の例の場合、一つ目のliは他のliと違うわけで、
その違いという意味を伝達するためにはclassは不可欠なのでは、
と思い至った。
どう？
以前は漏れもclassだのの属性を嫌っていたんだけど、
例えば>>912の例の場合、一つ目のliは他のliと違うわけで、
その違いという意味を伝達するためにはclassは不可欠なのでは、
と思い至った。
どう？
915 ：Name_Not_Found：04/09/03 19:39 ID:???
際どい……と言うか現状では止むを得ない感じはあるが、
「見栄えのためにclass作ったけど、結果的にはまぁ論理的だから良いよね」
と言う思想は、結局div中毒やらとそれほど変わらない希ガス。
#勿論、div中毒と呼ばれる輩は、論理マークアップと言うもの事態を考えていないのだけれど。
>>914
一つ目のｌi要素と二つ目のli要素を区別しなければならない状況が思いつかないので、何とも言いがたい。
そもそも「class属性で違いを伝達する」と言うこと事態が不可能なのでは。
CSSでの視覚効果等に期待しても、それ切られたら終わりだし。class属性自体がユーザーに伝える情報は何も無いかと。
#まぁ早い話、UAがちゃんと実装すれば良いんだよね。
「見栄えのためにclass作ったけど、結果的にはまぁ論理的だから良いよね」
と言う思想は、結局div中毒やらとそれほど変わらない希ガス。
#勿論、div中毒と呼ばれる輩は、論理マークアップと言うもの事態を考えていないのだけれど。
>>914
一つ目のｌi要素と二つ目のli要素を区別しなければならない状況が思いつかないので、何とも言いがたい。
そもそも「class属性で違いを伝達する」と言うこと事態が不可能なのでは。
CSSでの視覚効果等に期待しても、それ切られたら終わりだし。class属性自体がユーザーに伝える情報は何も無いかと。
#まぁ早い話、UAがちゃんと実装すれば良いんだよね。
916 ：Name_Not_Found：04/09/03 19:46 ID:???
追記。
でもまぁ、どうしても汎用ブロックコンテナでなければマークアップ出来ないものがあったとして、
それが二個以上同一文書内に出現した場合は、<div class="hoge">とするしか無い……と言うことか。
確かに、そう考えるとclassは必要なのかも。
でもまぁ、どうしても汎用ブロックコンテナでなければマークアップ出来ないものがあったとして、
それが二個以上同一文書内に出現した場合は、<div class="hoge">とするしか無い……と言うことか。
確かに、そう考えるとclassは必要なのかも。
917 ：Name_Not_Found：04/09/03 19:58 ID:???
>>914-916
>例えば>>912の例の場合、一つ目のliは他のliと違うわけで、
>その違いという意味を伝達するためにはclassは不可欠なのでは、
>と思い至った。
俺が回答しよう。
「HTMLソースレベルでの１個目、２個目は論理的な意味を持っている（表している）」
これに付け足すと
「１個目２個目というclassの値（first,second.....）は、完全にCSSでの事を考えいるのでclass=redどclass=firstは同レベルの非strictである」
仮に１個目を強調という意味であればclass=firstではなく、強調という意味が伝わるクラス名にするのがstrictであるといえる。
それじゃ＾＾
>例えば>>912の例の場合、一つ目のliは他のliと違うわけで、
>その違いという意味を伝達するためにはclassは不可欠なのでは、
>と思い至った。
俺が回答しよう。
「HTMLソースレベルでの１個目、２個目は論理的な意味を持っている（表している）」
これに付け足すと
「１個目２個目というclassの値（first,second.....）は、完全にCSSでの事を考えいるのでclass=redどclass=firstは同レベルの非strictである」
仮に１個目を強調という意味であればclass=firstではなく、強調という意味が伝わるクラス名にするのがstrictであるといえる。
それじゃ＾＾
918 ：Name_Not_Found：04/09/03 20:02 ID:???
919 ：Name_Not_Found：04/09/03 20:02 ID:???
>>915
> 一つ目のｌi要素と二つ目のli要素を区別しなければならない状況
手品とかで、よく切ったカードのイチバン上を一枚だけとってください、
ってシチュエーション、あるじゃん？そういうのとか。
あと伝達する相手はユーザじゃなくてUAだと思うのですよ。
ただ、class属性を付けたからって、他のliと違う、って事は伝わっても
そのclass属性の値を定義することが出来ないから、それがどう違うのかは、
伝達できないけどね。
> 一つ目のｌi要素と二つ目のli要素を区別しなければならない状況
手品とかで、よく切ったカードのイチバン上を一枚だけとってください、
ってシチュエーション、あるじゃん？そういうのとか。
あと伝達する相手はユーザじゃなくてUAだと思うのですよ。
ただ、class属性を付けたからって、他のliと違う、って事は伝わっても
そのclass属性の値を定義することが出来ないから、それがどう違うのかは、
伝達できないけどね。
920 ：Name_Not_Found：04/09/03 20:04 ID:???
>>all
そもそもclass自体strictなのかね？
だってidはユニークだけど、classは集合でしょ。文書レベルの集合って何よ？
集合を少し言い方を変えてグループ付け。文章のグループをハッキリとする。
でもそれは文章のグループであって、CSS見地でのグループでは駄目。
sectionなら< div id="section1">...</div>で事足りる。なおさらclassて何よ...
そこらへんを考えるとstrictなclassなんてない気がするがみんなはどう思う？＾＾
そもそもclass自体strictなのかね？
だってidはユニークだけど、classは集合でしょ。文書レベルの集合って何よ？
集合を少し言い方を変えてグループ付け。文章のグループをハッキリとする。
でもそれは文章のグループであって、CSS見地でのグループでは駄目。
sectionなら< div id="section1">...</div>で事足りる。なおさらclassて何よ...
そこらへんを考えるとstrictなclassなんてない気がするがみんなはどう思う？＾＾
921 ：Name_Not_Found：04/09/03 20:05 ID:???
firstというクラスを付ける必要性がCSSがなければ存在しない
可能性が高い。クラスで宣言しなくても最初の要素だからだ。
強調という意味が伝わるクラス名、についても疑問がある。
本来意味づけは要素ですべきであって、クラス名での暗黙的な定義は
Strict的ではない気がする。
現状ではem要素でのマークアップが妥当ではないだろうか。
（blockemが存在しないので）
div要素に関してはclass意外には用途の判別方法がないので
どうしても必要になるかも知れない。
可能性が高い。クラスで宣言しなくても最初の要素だからだ。
強調という意味が伝わるクラス名、についても疑問がある。
本来意味づけは要素ですべきであって、クラス名での暗黙的な定義は
Strict的ではない気がする。
現状ではem要素でのマークアップが妥当ではないだろうか。
（blockemが存在しないので）
div要素に関してはclass意外には用途の判別方法がないので
どうしても必要になるかも知れない。
922 ：Name_Not_Found：04/09/03 20:06 ID:???
>>919
そうじゃなくて
<ol>
<li>
<li>
</ol>
これだけでUAには１個目と２個目のliが違うと伝えれてるの。なので
>「HTMLソースレベルでの１個目、２個目は論理的な意味を持っている（表している）」
ということ。だから１個目という意味を持つclassはstrictではない。だって既に伝えれてるものを
CSSのために２重に伝えるわけだから^^
そうじゃなくて
<ol>
<li>
<li>
</ol>
これだけでUAには１個目と２個目のliが違うと伝えれてるの。なので
>「HTMLソースレベルでの１個目、２個目は論理的な意味を持っている（表している）」
ということ。だから１個目という意味を持つclassはstrictではない。だって既に伝えれてるものを
CSSのために２重に伝えるわけだから^^
923 ：Name_Not_Found：04/09/03 20:09 ID:???
>>920
フラグメントの制作（class）とユニークなフラグメントの制作（id）
は必ずしも同じではない。
div class="section"はXHMTL2.0ではsectionに置換されるだろうが、
XHTML2.0ではsection1、section2などと要素を作りまくる訳もなく、
無駄にユニーク化することは汎用性を下げる結果に成りかねない。
フラグメントの制作（class）とユニークなフラグメントの制作（id）
は必ずしも同じではない。
div class="section"はXHMTL2.0ではsectionに置換されるだろうが、
XHTML2.0ではsection1、section2などと要素を作りまくる訳もなく、
無駄にユニーク化することは汎用性を下げる結果に成りかねない。
924 ：Name_Not_Found：04/09/03 20:12 ID:???
>>917
リロードしわすれていまいた。すまそ。
> 「１個目２個目というclassの値（first,second.....）は、完全にCSSでの事を考えいる
必ずしもそうなるとは限らないと思いますよ。CSSを全く知らない人でも
classは書くことがあるし。ただアプローチがどうあれ、目的は、
一つ目を識別することだよね。
クラス名（class属性の値）については、ちょっと最近悩むのだけれど、
例えば class="fhist" とかしても、HTML に英単語が全て定義されている
訳ではないので、そのコードを読んだ「人間（しかも英語がわかる）」には
伝達できるけど、UAには伝わっていないな、と。
どう？
リロードしわすれていまいた。すまそ。
> 「１個目２個目というclassの値（first,second.....）は、完全にCSSでの事を考えいる
必ずしもそうなるとは限らないと思いますよ。CSSを全く知らない人でも
classは書くことがあるし。ただアプローチがどうあれ、目的は、
一つ目を識別することだよね。
クラス名（class属性の値）については、ちょっと最近悩むのだけれど、
例えば class="fhist" とかしても、HTML に英単語が全て定義されている
訳ではないので、そのコードを読んだ「人間（しかも英語がわかる）」には
伝達できるけど、UAには伝わっていないな、と。
どう？
925 ：Name_Not_Found：04/09/03 20:13 ID:???
>>923
>div class="section"
これはstrictなclassのいい例だね^^
つまりstrict（文書レベルでの）なclass（グループ付け）は存在するってことだね。
idでそれぞれにsection1...とする方法もありだけど、classの方が利便性が高い場合は
classを使おうってことかな^^
>div class="section"
これはstrictなclassのいい例だね^^
つまりstrict（文書レベルでの）なclass（グループ付け）は存在するってことだね。
idでそれぞれにsection1...とする方法もありだけど、classの方が利便性が高い場合は
classを使おうってことかな^^
926 ：Name_Not_Found：04/09/03 20:15 ID:???
divはclass属性属性じゃなくてforとか、違う名前にすれば良かったんだろうな。
CSSでの使い勝手が悪くなること請け合いだが。
で、最強なのは属性値の中身をURIなりにして、OWLなりRDFなりと結びつけると・・・。
CSSでの使い勝手が悪くなること請け合いだが。
で、最強なのは属性値の中身をURIなりにして、OWLなりRDFなりと結びつけると・・・。
927 ：Name_Not_Found：04/09/03 20:15 ID:???
>>924
>「HTMLソースレベルでの１個目、２個目は論理的な意味を持っている（表している）」
もう一度この意味を再考あれ。UAはどれが何番目かというのはclassがなくてもソースの順番で理解しているよ。
>「HTMLソースレベルでの１個目、２個目は論理的な意味を持っている（表している）」
もう一度この意味を再考あれ。UAはどれが何番目かというのはclassがなくてもソースの順番で理解しているよ。
928 ：Name_Not_Found：04/09/03 20:18 ID:???
929 ：Name_Not_Found：04/09/03 20:22 ID:???
>>922
olの一番最初はolの一番最初であって、ulの一番最初は別だと思う。
ulだからといって順番が本当に全然関係無くて勝手に並べ替えて良いというわけではないはず。
個人的にはclass="first"は論理的であり得ると思ってる。
確かにclassで明示しなくてもfirstな要素であることは明らかだけど、
それを(さらに)明示しても怒られる筋合いはないはず。
>>928の例は、おかしくないことはないけど、間違いだとは思わない。
或いは、ソース的には1番目のliがもし一種の注釈か何かだったりした場合、
authorとしてはそれを数えたくないかも知れない。
<ul>
<li>(注釈か何か)</li>
<li class="first">(本題1つ目)</li>
<li>……
……
</ol>
olの一番最初はolの一番最初であって、ulの一番最初は別だと思う。
ulだからといって順番が本当に全然関係無くて勝手に並べ替えて良いというわけではないはず。
個人的にはclass="first"は論理的であり得ると思ってる。
確かにclassで明示しなくてもfirstな要素であることは明らかだけど、
それを(さらに)明示しても怒られる筋合いはないはず。
>>928の例は、おかしくないことはないけど、間違いだとは思わない。
或いは、ソース的には1番目のliがもし一種の注釈か何かだったりした場合、
authorとしてはそれを数えたくないかも知れない。
<ul>
<li>(注釈か何か)</li>
<li class="first">(本題1つ目)</li>
<li>……
……
</ol>
考え方をUAの表示に誤魔化されている気がするよ。
トランプに例えたのもおかしかった。
順列があるものは ol、順不同は ul で間違いかな？
ul（順不同） は麻雀で洗牌しおわって牌が卓上に散らばっている状態、
ol は拾ってきて手元に並んでいる状態（理牌まえでも）
みたいなイメージで理解していたのだけれど。
css や JavaScript が :first-child や .firstChild で一番目を
拾ってこれるのは、そうなるように出来ているからであって、
html とは関係ないことだよね？
トランプに例えたのもおかしかった。
順列があるものは ol、順不同は ul で間違いかな？
ul（順不同） は麻雀で洗牌しおわって牌が卓上に散らばっている状態、
ol は拾ってきて手元に並んでいる状態（理牌まえでも）
みたいなイメージで理解していたのだけれど。
css や JavaScript が :first-child や .firstChild で一番目を
拾ってこれるのは、そうなるように出来ているからであって、
html とは関係ないことだよね？
932 ：Name_Not_Found：04/09/03 20:26 ID:???
リロード忘れたorz
934 ：Name_Not_Found：04/09/03 20:29 ID:???
935 ：Name_Not_Found：04/09/03 20:58 ID:???
HTML 4.01 には、次のようにあるね。
10.2 Unordered lists (UL), ordered lists (OL), and list items (LI)
だから、>>931 で間違えないと思うよ。
ただ、そうならば、<OL>要素は、単純な <LI> にしないで、
例えば、
<ol>
<1st> hogehoge
<2nd> hogehoge
<3rd> hogehoge
</ol>
みたいな、規格になっていた方が、より厳密だったかもしれないけど。
10.2 Unordered lists (UL), ordered lists (OL), and list items (LI)
だから、>>931 で間違えないと思うよ。
ただ、そうならば、<OL>要素は、単純な <LI> にしないで、
例えば、
<ol>
<1st> hogehoge
<2nd> hogehoge
<3rd> hogehoge
</ol>
みたいな、規格になっていた方が、より厳密だったかもしれないけど。
936 ：Name_Not_Found：04/09/03 21:15 ID:???
>>935
多くなってきたら恐ろしく面倒くさそうだｗ
多くなってきたら恐ろしく面倒くさそうだｗ
937 ：Name_Not_Found：04/09/03 21:21 ID:???
21thとか書く奴が出てきてM$あたりが実装して……ってのはさすがに大丈夫かな。
DTDで定義するのが大変な悪寒。
DTDで定義するのが大変な悪寒。
まあ、あくまでも「厳密だったかも」の話だからｗ
それと、<1st>以下のタグが閉じてなかった…
Strictor (-er ?) 失格だ ＿|￣|○
それと、<1st>以下のタグが閉じてなかった…
Strictor (-er ?) 失格だ ＿|￣|○
939 ：Name_Not_Found：04/09/03 21:36 ID:???
何か適当に属性に番号放り込むんじゃいけないの？
<li num="100">hage</li> とか
<li num="100">hage</li> とか
940 ：Name_Not_Found：04/09/03 21:49 ID:???
>>939
<ol>
<li num="2">hage</li>
<li num="1">hege</li>
</ol>
こういうのはどうなんだろう、と思った。
ていうかこんなことするんだったらolもulも一緒にlistで良さそうだけど。
<ol>
<li num="2">hage</li>
<li num="1">hege</li>
</ol>
こういうのはどうなんだろう、と思った。
ていうかこんなことするんだったらolもulも一緒にlistで良さそうだけど。
941 ：Name_Not_Found：04/09/03 21:51 ID:???
その手のアイデアは、間に項目を挿入することになった場合に
手間が掛かるから好きじゃないなあ。
手間が掛かるから好きじゃないなあ。
942 ：Name_Not_Found：04/09/03 21:52 ID:???
まてまて、変な方向に話が逝ってるぜ。
943 ：Name_Not_Found：04/09/03 21:55 ID:???
基本は文章順でいいじゃないか。
振られる番号が意味を持つならばそれは内容としてテキストで書くべきだろ？
振られる番号が意味を持つならばそれは内容としてテキストで書くべきだろ？
944 ：Name_Not_Found：04/09/03 22:22 ID:???
>>929>>all
>、ソース的には1番目のliがもし一種の注釈か何かだったりした場合、
なんかみんな勘違いしてるよ。
<ol>
<li>
<li>
</ol>
２個目にclass=firstすること自体間違い。たとえば途中に注釈的なものが混ざってるなら
class=notesとでもすればいいだけ。classでfirstやったってソースレベルの順番から解釈できる
論理的な順番は覆せない。
そもそもolは書き順が論理的な意味を持ってるんだから、classでそれを覆そうとする時点で
初めの書き順が間違ってる。ついでにulにclass=firstは根本的にolを使う時にulを使っていると考えられる。
ulは順序なしリストなんだから、ぐちゃぐちゃになっても意味を損なってはいけないし、順序を整形しようとするのも間違い。
逆にolはぐちゃぐちゃにしてはいけない。
>、ソース的には1番目のliがもし一種の注釈か何かだったりした場合、
なんかみんな勘違いしてるよ。
<ol>
<li>
<li>
</ol>
２個目にclass=firstすること自体間違い。たとえば途中に注釈的なものが混ざってるなら
class=notesとでもすればいいだけ。classでfirstやったってソースレベルの順番から解釈できる
論理的な順番は覆せない。
そもそもolは書き順が論理的な意味を持ってるんだから、classでそれを覆そうとする時点で
初めの書き順が間違ってる。ついでにulにclass=firstは根本的にolを使う時にulを使っていると考えられる。
ulは順序なしリストなんだから、ぐちゃぐちゃになっても意味を損なってはいけないし、順序を整形しようとするのも間違い。
逆にolはぐちゃぐちゃにしてはいけない。
945 ：Name_Not_Found：04/09/03 22:28 ID:???
>>944
付加的意味を加える物がclass属性では?
付加的意味を加える物がclass属性では?
946 ：Name_Not_Found：04/09/03 22:29 ID:???
olとは
<hn>水泳100m平泳ぎ順位</hn>
<ol>
<li>北島
<li>ｆルプス
<li>のびた
</ol>
ulとは
<hn>水泳100m平泳ぎ参加者</hn>
<ul>
<li>のびた
<li>フェルプス
<li>北島
</ul>
<hn>水泳100m平泳ぎ順位</hn>
<ol>
<li>北島
<li>ｆルプス
<li>のびた
</ol>
ulとは
<hn>水泳100m平泳ぎ参加者</hn>
<ul>
<li>のびた
<li>フェルプス
<li>北島
</ul>
947 ：Name_Not_Found：04/09/03 22:31 ID:???
948 ：Name_Not_Found：04/09/03 22:32 ID:???
950 ：Name_Not_Found：04/09/03 22:56 ID:???
なんか、
HTMLの「論理構造の表現力不足」が原因な話と、
CSSの「セレクタの力不足」が原因な話がごちゃ混ぜになってる気がする…
…と、描いてみるテスツ。
HTMLの「論理構造の表現力不足」が原因な話と、
CSSの「セレクタの力不足」が原因な話がごちゃ混ぜになってる気がする…
…と、描いてみるテスツ。
951 ：Name_Not_Found：04/09/03 23:02 ID:???
>>949
<hn>水泳100m平泳ぎ順位</hn>
<ol>
<li>北島
<li>ｆルプス
<li>のびた
</ol>
<hn>各章受賞者</hn>
<dl>
<dt>敢闘賞
<dd>のびた
<dt>技能賞
<dd>フェルプス
<dt>最優秀賞
<dd>北島
</dl>
意味が違うものを同じリストの中に入れる必要性がない。順列から外れているものは
olの中からも外れている。そもそも順序ありリストとはヘッダが一つであるのが通常だ。
複数のヘッダがある場合はヘッダの分だけリストを増やせばいい。
<hn>水泳100m平泳ぎ順位</hn>
<ol>
<li>北島
<li>ｆルプス
<li>のびた
</ol>
<hn>各章受賞者</hn>
<dl>
<dt>敢闘賞
<dd>のびた
<dt>技能賞
<dd>フェルプス
<dt>最優秀賞
<dd>北島
</dl>
意味が違うものを同じリストの中に入れる必要性がない。順列から外れているものは
olの中からも外れている。そもそも順序ありリストとはヘッダが一つであるのが通常だ。
複数のヘッダがある場合はヘッダの分だけリストを増やせばいい。
952 ：Name_Not_Found：04/09/03 23:02 ID:???
olは要素が順序をもってるという意味はあるが、
ラベル付きであることは保証しないよ
ラベル付きであることは保証しないよ
953 ：Name_Not_Found：04/09/03 23:10 ID:???
>>952
ラベルの有無はUAでの実装やCSSの話でHTMLとは無関係。
ラベルの有無はUAでの実装やCSSの話でHTMLとは無関係。
954 ：Name_Not_Found：04/09/03 23:18 ID:???
955 ：Name_Not_Found：04/09/03 23:19 ID:???
>>953
だからこそ有意味なラベルはテキストに埋め込む必要がある。
だからこそ有意味なラベルはテキストに埋め込む必要がある。
956 ：Name_Not_Found：04/09/04 00:18 ID:???
まぁ、>>950 に行き着いてしまう部分もあるわけだが。
ただ、UA の実装上、
<hn>水泳100m平泳ぎ順位</hn>
<ol>
<li>北島</li>
<li>フェルプス</li>
<li>のびた</li>
</ol>
とした場合に、北島から順に１、２と番号が振られることが多いわけで、
意味のあるラベルをテキスト上に埋め込むと、ユーザーからは
（番号が重なるなどして）下手な記述方法だと思われることもあるだろうな。
そうだとしたら、<ol> は封印して、 <ul> の各 <li> について、
意味のあるラベルをテキスト上に埋め込む方に統一した方が
いいんでないの？
ただ、UA の実装上、
<hn>水泳100m平泳ぎ順位</hn>
<ol>
<li>北島</li>
<li>フェルプス</li>
<li>のびた</li>
</ol>
とした場合に、北島から順に１、２と番号が振られることが多いわけで、
意味のあるラベルをテキスト上に埋め込むと、ユーザーからは
（番号が重なるなどして）下手な記述方法だと思われることもあるだろうな。
そうだとしたら、<ol> は封印して、 <ul> の各 <li> について、
意味のあるラベルをテキスト上に埋め込む方に統一した方が
いいんでないの？
957 ：Name_Not_Found：04/09/04 00:34 ID:???
>>956
ちなみに3位はフランスのデュボスね。
ちなみに3位はフランスのデュボスね。
958 ：Name_Not_Found：04/09/04 00:39 ID:???
olで補償されてるのは「並び順があること」だけだぞ。
「順位」じたいはolでは規定されない。
一部を切り出そうが全体だろうが、順位が存在すればol、それだけだ。
順位を持たせたいならば内容にテキストとして書くべき。
「順位」じたいはolでは規定されない。
一部を切り出そうが全体だろうが、順位が存在すればol、それだけだ。
順位を持たせたいならば内容にテキストとして書くべき。
すまん、間違えた
並び順が存在すればol、ね
並び順が存在すればol、ね
960 ：Name_Not_Found：04/09/04 00:44 ID:???
なんか元の問題からずいぶんずれたね。戻すよ？
class=firstは是か非か。
class=firstは是か非か。
961 ：Name_Not_Found：04/09/04 00:53 ID:???
そういえば順位を表すときにN位タイがある場合はどうなるんだ？
olは使えない？
olは使えない？
962 ：Name_Not_Found：04/09/04 00:54 ID:???
963 ：Name_Not_Found：04/09/04 00:55 ID:???
<ol>
<li><ul><li>一位その1</li><li>一位その2</li></ul></li>
<li>三位</li>
</ol>
<li><ul><li>一位その1</li><li>一位その2</li></ul></li>
<li>三位</li>
</ol>
964 ：Name_Not_Found：04/09/04 00:56 ID:???
>>962
なるほど納得。では以後元の話題でどうぞ。
なるほど納得。では以後元の話題でどうぞ。
965 ：Name_Not_Found：04/09/04 00:57 ID:???
>>962
その構造って「推奨しない」じゃなかったっけ？
その構造って「推奨しない」じゃなかったっけ？
966 ：Name_Not_Found：04/09/04 00:58 ID:???
>>965
ソースと根拠は？
ソースと根拠は？
967 ：Name_Not_Found：04/09/04 01:01 ID:???
>>966
なんか、こういう構造はイカンよって書いてあるような気がした。
ttp://www.w3.org/TR/html401/struct/lists.html#edef-LI （原文）
ttp://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/lists.html#edef-LI （邦訳）
漏れの読み違いだったらスマン。
なんか、こういう構造はイカンよって書いてあるような気がした。
ttp://www.w3.org/TR/html401/struct/lists.html#edef-LI （原文）
ttp://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/lists.html#edef-LI （邦訳）
漏れの読み違いだったらスマン。
969 ：Name_Not_Found：04/09/04 01:09 ID:???
970 ：Name_Not_Found：04/09/04 01:45 ID:???
>>967
定義リストでやれよ。
定義リストでやれよ。
971 ：Name_Not_Found：04/09/04 01:47 ID:???
ボクシングの順位は
第一位：チャンピオン
第二位：ランキング１位
第三位： 〃 ２位
：
第n 位： 〃 n-1位
だな。
第一位：チャンピオン
第二位：ランキング１位
第三位： 〃 ２位
：
第n 位： 〃 n-1位
だな。
972 ：Name_Not_Found：04/09/04 01:56 ID:???
>>958
じゃあW3Cも非Strictなのかよｗ
仕様書のindexページでどうマークアップされてるか見てこいよ。
あいつら1個目は１であるとして参照する時なんかは思いっきりラベルの番号に頼ってるぞ。
じゃあW3Cも非Strictなのかよｗ
仕様書のindexページでどうマークアップされてるか見てこいよ。
あいつら1個目は１であるとして参照する時なんかは思いっきりラベルの番号に頼ってるぞ。
973 ：Name_Not_Found：04/09/04 01:57 ID:???
>>970
は？
は？
974 ：Name_Not_Found：04/09/04 02:06 ID:???
>>972
ティムたんのサイトにはテーブルレイアウトの前科が…
ティムたんのサイトにはテーブルレイアウトの前科が…
975 ：Name_Not_Found：04/09/04 02:12 ID:???
>>972]
残念だが、笑い事ではなく、彼らは余裕で非Strict的行いをする。
W3C-DTFなんて使わないし、AA的な目次は作るし、DIVは乱用するし。
Traditional DTDも使うしな。
とにかく、W3Cのサイト自体は全く信用できない。
残念だが、笑い事ではなく、彼らは余裕で非Strict的行いをする。
W3C-DTFなんて使わないし、AA的な目次は作るし、DIVは乱用するし。
Traditional DTDも使うしな。
とにかく、W3Cのサイト自体は全く信用できない。
>>974-976
じゃあ
W3Cの実際のマークアップ ＝ 仕様書の正しい解釈
というのは間違いなのかな？ちょっと微妙だよねそれって。
ところでW3Cも使わない完全なるStrict志向ってなんなんだろうねｗ
実は大筋strictであれば細かいとこにこだわるなって言うのも仕様だったりしてｗ
まあこのスレ的には>>958の言うことは正しい
というか>>958のものをこのスレとしての回答にするべきだけどさ。
じゃあ
W3Cの実際のマークアップ ＝ 仕様書の正しい解釈
というのは間違いなのかな？ちょっと微妙だよねそれって。
ところでW3Cも使わない完全なるStrict志向ってなんなんだろうねｗ
実は大筋strictであれば細かいとこにこだわるなって言うのも仕様だったりしてｗ
まあこのスレ的には>>958の言うことは正しい
というか>>958のものをこのスレとしての回答にするべきだけどさ。
>>977
まず、W3C自体が一枚岩ではない。
ページを作ってる人によって方針がバラバラだし、
全ての技術者がHTMLに詳しいわけではない。
現状だとStrict指向がもたらす結果は利便性以上に不都合な点が多いので、
（観覧者にとって。特にIEユーザーにとっては）
公的な組織であり訪問者の多いW3Cのようなサイトには必ずしも究極的な
Strict指向が最適な答えとは限らない。
このスレレベルのStrict指向は現状だと個人的な実験以上には使えない
部分が多い。
まず、W3C自体が一枚岩ではない。
ページを作ってる人によって方針がバラバラだし、
全ての技術者がHTMLに詳しいわけではない。
現状だとStrict指向がもたらす結果は利便性以上に不都合な点が多いので、
（観覧者にとって。特にIEユーザーにとっては）
公的な組織であり訪問者の多いW3Cのようなサイトには必ずしも究極的な
Strict指向が最適な答えとは限らない。
このスレレベルのStrict指向は現状だと個人的な実験以上には使えない
部分が多い。
979 ：Name_Not_Found：04/09/04 04:06 ID:???
980 ：Name_Not_Found：04/09/04 05:04 ID:???
何か面白いな、それ。
＞現状だとStrict指向がもたらす結果は利便性以上に不都合な点が多いので、
＞（観覧者にとって。特にIEユーザーにとっては）
またI（ry
＞現状だとStrict指向がもたらす結果は利便性以上に不都合な点が多いので、
＞（観覧者にとって。特にIEユーザーにとっては）
またI（ry
982 ：Name_Not_Found：04/09/04 20:55 ID:???
983 ：Name_Not_Found：04/09/04 21:10 ID:???
>>982
逆。W3CはMSの敵
逆。W3CはMSの敵
984 ：Name_Not_Found：04/09/04 21:16 ID:???
つーか勘違いしてる反W3C厨は多いが、Strict自体が有害になることって滅多にないぞ
985 ：Name_Not_Found：04/09/04 22:12 ID:???
>>984
UAしだいでいくらでも
UAしだいでいくらでも
986 ：Name_Not_Found：04/09/04 22:14 ID:???
>>985
ageてまで主張したいことなら具体例をあげてみては？
ageてまで主張したいことなら具体例をあげてみては？
987 ：Name_Not_Found：04/09/04 22:42 ID:???
たぶんCSS対応の問題と混同してるんだろうな
988 ：Name_Not_Found：04/09/04 23:00 ID:???
ちょっと勉強すりゃすぐ習得できる（まぁ人によっちゃ時間はかかるがな）もんなんだから、
無闇にW3Cの欠点探すよりStrictなHTML書けるように努力した方がいいよ。自己正当化に奔走してないでさ。
無闇にW3Cの欠点探すよりStrictなHTML書けるように努力した方がいいよ。自己正当化に奔走してないでさ。
989 ：Name_Not_Found：04/09/04 23:09 ID:???
990 ：Name_Not_Found：04/09/04 23:10 ID:???
abbrは？
991 ：Name_Not_Found：04/09/04 23:11 ID:???
992 ：Name_Not_Found：04/09/04 23:13 ID:???
993 ：Name_Not_Found：04/09/04 23:16 ID:???
あれ？MS抜けたのか。
リーがんばれ。超がんばれ。
リーがんばれ。超がんばれ。
994 ：Name_Not_Found：04/09/04 23:18 ID:???
>>987
Strict志向とは見栄えをCSS等でやることだってわかってる言ってるのか？
strictなHTMLで仕上げれば当然CSS問題も抱え込むだろう。
このスレではCSSはスレ違いだが、
>Strict自体が有害になることって滅多にないぞ
この場合現実にstrictで仕上げることでの害の有無だから当然CSS問題も関わる。
ていうか文章の意味もわからない人間に有害かどうかを判断できるとは思えないけどな。
Strict志向とは見栄えをCSS等でやることだってわかってる言ってるのか？
strictなHTMLで仕上げれば当然CSS問題も抱え込むだろう。
このスレではCSSはスレ違いだが、
>Strict自体が有害になることって滅多にないぞ
この場合現実にstrictで仕上げることでの害の有無だから当然CSS問題も関わる。
ていうか文章の意味もわからない人間に有害かどうかを判断できるとは思えないけどな。
995 ：Name_Not_Found：04/09/04 23:20 ID:???
>>992
CSS3Textなんて草案からずっとMSの人が書いてるわけだが何言ってんの？
CSS3Textなんて草案からずっとMSの人が書いてるわけだが何言ってんの？
>>995
どこで得た知識？情報元を出してね。
どこで得た知識？情報元を出してね。
997 ：Name_Not_Found：04/09/04 23:31 ID:???
スタイルなしで公開してもよかろう
998 ：Name_Not_Found：04/09/04 23:35 ID:???
お前らどうでもいからそんなこと。誰か新スレ立ててよ。
>>994
>Strict志向とは見栄えをCSS等でやること
CSSを使うのがStrictのための必要条件なのか？そんな定義は初めて聞いた。
俺の理解ではStrict志向＝「HTMLで見栄えを記述しない」だ。
StrictかどうかとCSSを使う使わないは関係ない。
>>984がわざわざ
>Strict自体が有害になることって滅多にない
で「自体」という言葉を使ったのは、CSSと話を切り離すためだろ？
なのに>>985みたいな返事が返ってきたから混同してるって書いたんだが。
>Strict志向とは見栄えをCSS等でやること
CSSを使うのがStrictのための必要条件なのか？そんな定義は初めて聞いた。
俺の理解ではStrict志向＝「HTMLで見栄えを記述しない」だ。
StrictかどうかとCSSを使う使わないは関係ない。
>>984がわざわざ
>Strict自体が有害になることって滅多にない
で「自体」という言葉を使ったのは、CSSと話を切り離すためだろ？
なのに>>985みたいな返事が返ってきたから混同してるって書いたんだが。
1000 ：Name_Not_Found：04/09/04 23:50 ID:???
イエーイ1000だぜ！
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。