Strict-HTML スレッド23

1 ：Name_Not_Found：04/09/05 00:27 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

2 ：Name_Not_Found：04/09/05 00:27 ID:???

3 ：Name_Not_Found：04/09/05 00:27 ID:???

■関連スレ
/* CSS･スタイルシート質問スレッド【35】 */ http://pc5.2ch.net/test/read.cgi/hp/1093998766/
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/xhtml2
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/

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

4 ：Name_Not_Found：04/09/05 00:29 ID:???

ところで、MSがW3Cから抜けたって言ってたのはどこの誰だ？
ttp://www.w3.org/Consortium/Member/List

5 ：Name_Not_Found：04/09/05 00:30 ID:???

>>1
乙。

ところで、Another HTML-lint の結果ってどれくらい正確なんだろう？
いや、中の人を批難する意味でなく、なんとなく。

6 ：Name_Not_Found：04/09/05 00:30 ID:???

ところでCSS3の草案をMSの人間が中心になって作ったなんていうアフォなこと言ってるのは誰だ？
早くリソースだせ。

7 ：Name_Not_Found：04/09/05 00:32 ID:???

>>5
あれはStrictを調べるもんじゃないんだよ。DTDの合致と非推奨行為だけ警告出すから。
まあオプションしだいでどうにでもなるけどさ。

8 ：Name_Not_Found：04/09/05 00:33 ID:???

>>4
一度抜けて出戻りじゃないかな？

>>6
> リソースだせ。

えーと、ソースのことを言いたいのかな。

9 ：Name_Not_Found：04/09/05 00:34 ID:???

>>8
ごめん；恥ずかしいからあまり突っ込まないでくれ

10 ：Name_Not_Found：04/09/05 00:37 ID:???

「ソースだせ」と「リソースだせ」でぐぐってみると結構面白い

11 ：Name_Not_Found：04/09/05 00:38 ID:???

>>10
いいから出せボケ。どうせお前の妄想なんだろ

12 ：Name_Not_Found：04/09/05 00:51 ID:???

>>8
抜けたってのはW3Cメンバーから抜けたんじゃなくて
特定のWGから手を引いたってだけじゃないのか？
例えば: ttp://news.zdnet.co.uk/software/0,39020381,2132448,00.htm
なんにせよかつてメンバーから抜けたというソースは見当たらないが…

13 ：Name_Not_Found：04/09/05 01:00 ID:???

嘘を嘘と見抜けない人は(ry

14 ：Name_Not_Found：04/09/05 01:37 ID:???

>>1 乙

まぁ age る奴は大抵厨房。付き合ってた皆様も乙。

15 ：Name_Not_Found：04/09/05 01:39 ID:???

ソースとリソースの区別もつかないくらいだからなぁ……。

16 ：Name_Not_Found：04/09/05 02:38 ID:???

>>1
<abbr title="お疲れさまです">乙</abbr>

>>6
http://www.w3.org/TR/css3-text/
ついでに
http://www.w3.org/TR/2004/CR-css3-ui-20040511/
http://www.w3.org/TR/2004/WD-css3-hyperlinks-20040224/
http://www.w3.org/TR/2003/CR-css3-ruby-20030514/
http://www.w3.org/TR/2003/CR-css3-color-20030514/
http://www.w3.org/TR/2002/WD-css3-lists-20021107/
http://www.w3.org/TR/2002/WD-css3-webfonts-20020802/
http://www.w3.org/TR/2002/WD-css3-fonts-20020802/
http://www.w3.org/TR/1999/WD-becss-19990804

17 ：Name_Not_Found：04/09/05 02:39 ID:???

>>16
乙

18 ：Name_Not_Found：04/09/05 04:54 ID:???

なんだこれ？夏休みは終ったんでしょ？
とにかく厨同士で争うのは勝手だけど、完全にスレ違いだから他のスレでやってください。

本当は新スレの前に言うつもりだったんだけど、今後は1に以下を足してほしい。

「(このスレでの)言葉の意味」
strict-HTML　　論理的にマークアップされているHTML
strict　　　　　同上
strict志向　　　見栄えをスタイルシート、構造をHTMLで記述し、
　　　　　　　　見栄えと構造の分離をすること。
strictDTD　　　 DTDの1種。
valid　　　　　 DTDの合致。

とりあえずこのくらいかな？まあ単語と説明文はおかしかったらフォローよろしく。
あまりこのスレはくだらない言葉のあげあしとりとか、単語の勘違いからくるような
罵りあいは避けたいのでおながいしますm(_ _)m

19 ：Name_Not_Found：04/09/05 07:21 ID:???

>>前スレ999
>CSSを使うのがStrictのための必要条件なのか？そんな定義は初めて聞いた。
問題はそこではなくて、「視覚デザイン」を行うことが一般的なサイトには
必要条件になっている。
Strictなマークアップでは必然的にCSSの貧弱な視覚的表現力に制限されるため、
「視覚デザイン」の優先度が高い一般的なサイトでは、
事実上Strictなマークアップそれ自体が害の根源になりうると言える。

ということを、>>994は言いたかったんだと思うよ。

Strictなマークアップ（それこそclass属性の存在すら怪しむような）の場合、
現在のCSS（というかIEの実装）では要求されるレベルの表現が不可能、
もしくは無駄にコストがかかるのが原因だろうな。
視覚的なイメージも重要な戦略になる企業サイトとかは中々移行できないだろうね。

20 ：前スレ999：04/09/05 09:06 ID:???

>>19
>Strictなマークアップでは必然的にCSSの貧弱な視覚的表現力に制限されるため、

「必然的に制限される」というのには同意できないなあ。
CSSを使わないStrictページなんていくらでもあるし、
使っているページだってCSSを適用せずに閲覧することが可能なわけでしょ？
(CSSを適用しないとまともに意味が掴めないようなのはStrictと呼べない)

視覚デザインの優先度が高いサイトでCSSによるデザイン表現を第一義に
考えた場合にそれがうまく伝えられない、という話はわかるよ。
でも、それを普通「Strict自体が～」なんて言わないでしょ。
CSSの問題としてStrictとは切り離して議論することが可能なのに、>>994は

>strictなHTMLで仕上げれば当然CSS問題も抱え込む

という風に不可分な問題であるかのように書き、わざわざこのスレで
一緒に語ろうとする。だから混同していると思うわけ。
なんか、CSSのためにあるのがStrict、と言っているように見える。

21 ：Name_Not_Found：04/09/05 10:06 ID:???

>>20
阿呆を相手にすな

22 ：Name_Not_Found：04/09/05 10:37 ID:???

>>16
「顧客の望むまま、どんどん独自拡張して
それを標準勧告にするように圧力をかけるのが我々の使命！」
「(既に勧告されてる分で未対応分は)顧客が望んで無いから対応しない。
標準だからという理由だけでは対応しない！」

って宣言してたのは宣言どおり実行されているわけだ。さすがMS。

23 ：Name_Not_Found：04/09/05 12:51 ID:???

>>18
strict志向の説明を文章を構造化することをもう少し強調したようなものにした方がいいかと。

24 ：Name_Not_Found：04/09/05 13:45 ID:???

ttp://www.hatena.ne.jp/1094327484
一般の認識ってこんなもんだよね。
「先頭の空白は装飾なんだ」とか
「ブラウザのデフォルトスタイルが英文のマークアップに適したスタイルになってるだけ」とか
「変なところで改行を入れると文の意図を誤解されるかもしれないし、第一読みにくい」とか言っても
分かってくれなさそうだ。

25 ：Name_Not_Found：04/09/05 14:27 ID:???

>>24
あたりまえです。与えられた環境でリンクをクリックするだけの使い方しか知らないんだから。

26 ：Name_Not_Found：04/09/05 17:46 ID:???

>>6
>リソース

ﾌﾟﾌﾟﾌﾟ

27 ：Name_Not_Found：04/09/05 19:23 ID:???

984 Name_Not_Found 04/09/04 21:16 ID:???
つーか勘違いしてる反W3C厨は多いが、Strict自体が有害になることって滅多にないぞ

985 Name_Not_Found age 04/09/04 22:12 ID:???
>>984
UAしだいでいくらでも

986 Name_Not_Found 04/09/04 22:14 ID:???
>>985
ageてまで主張したいことなら具体例をあげてみては？

991 Name_Not_Found age 04/09/04 23:11 ID:???
>>986
html4.01strictDTDで書かれたHTMLファイルを読むとフリーズするようなUAを作ればって意味だよ。
勝手な妄想で無駄なレスをつけるなよ。

992 Name_Not_Found age 04/09/04 23:13 ID:???
>>989
MSはもう既にW3Cから抜けてるでしょ？それにW3C内でのMSから来た人間の地位が低ければ
W3CとMSの同調ができないのもしょうがない。

トップをMSの人間にすればいいのにね。

28 ：Name_Not_Found：04/09/05 19:46 ID:???

>>20
完全なるstrict-HTML　＝　一時的に再利用性の低いHTML。もしくは今は利用できないHTML。

これは現状のCSSのセレクタ、UAでの実装などからくるもので本来HTMLに非はないことだ。
しかし現状CSSがstrict-HTMLに対応できてないんだから、HTML側で対応するしかない。
それはCSSに限らないが、HTML側で再利用度の高いものにするほうが賢い。
もちろんstrictに書いても数年後？にはそれがもっとも再利用性の高い、息の長いソースになる。
しかし、現状に対応できるstrict崩れも、もちろんstrictを基にしてるから
何年後でも問題なく使える。駄文ごめんよ。

そもそも「Strict自体が～」この発言が非現実的なんだよね。見栄えと構造の分離は
ソースレベルでの話なのに、まるで実際のサイト作成・公開でも分離ができるみたいなね。

以前とは違い、strictは
strict-HTMLとスタイルシートでようやく1人前なのに、それを各社にうまく
伝えられなかったのね。そしてここにいるみんなもそれを理解できてない。
だからどちらが悪い的な発想が出てくる。

スタイルがなくてもサイトは見れる。だからHTMLだけでも1人前だと思い込むのは間違い。
公開者の意図の半分、見栄えに関する部分を伝えられないのでやはり半人前だね。

29 ：Name_Not_Found：04/09/05 19:50 ID:???

頼むからお前らこっちでやってくれ。スレの初めからずっとスレ違いなんだよ。
少しは他人の迷惑も考えてくれ。もう勘弁してくれ。

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50

30 ：Name_Not_Found：04/09/05 19:51 ID:???

>公開者の意図の半分、見栄えに関する部分

半分しか内容に力を入れないのか。

31 ：Name_Not_Found：04/09/05 19:52 ID:???

>>288
>見栄えに関する部分を伝えられないのでやはり半人前だね

見栄えに関する部分を伝えないのがStrictなんだから当たり前だろ。
自分で何言ってるのかわかってんのか？
そんなにCSSの話をしたいならCSSスレでどうぞ。

32 ：Name_Not_Found：04/09/05 19:53 ID:???

>>28
このスレで議論を続けたいなら君の主張を簡潔に述べてくれ。

33 ：28：04/09/05 19:57 ID:???

>>31
そういう意味でなく、情報公開手段としてのソフトとしての意味だよ。

34 ：Name_Not_Found：04/09/05 19:59 ID:???

役割が違うものをどうして同列に語ろうとするかなあ…
自動車板で「飛行機がなくても移動はできる。だから自動車だけでも1人前だと
思い込むのは間違い。外国へ行く旅程の半分、空港間の移動ができないのでや
はり半人前だね。」と言って飛行機の話をするようなもんだぞ。

飛行機の話は航空板で、CSSの話はCSS関連スレでやってくれ。

35 ：Name_Not_Found：04/09/05 19:59 ID:???

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50

スレ違いなので↑に行って下さいm(_ _)m

36 ：Name_Not_Found：04/09/05 20:00 ID:???

>>33
ここは「情報公開手段としてのソフトについて語るスレ」じゃねえよ。
スレタイ百回読み直せ。

37 ：28：04/09/05 20:02 ID:???

>>34
例えが全然違うよ。

38 ：28：04/09/05 20:03 ID:???

>36
まずは文章を読めるようになろうな。

39 ：Name_Not_Found：04/09/05 20:03 ID:???

>>28
>>32

釣りを続けるつもりなら去ってくれ

40 ：28：04/09/05 20:05 ID:???

>>39
>>28が読めないのかな？

41 ：Name_Not_Found：04/09/05 20:07 ID:???

>>40
おまえはあれで簡潔に書いたつもりか。

42 ：28：04/09/05 20:09 ID:???

>>41
文章が読めないの？もっと噛み砕いたほうがよかった？

43 ：Name_Not_Found：04/09/05 20:11 ID:???

>>28
>完全なるstrict-HTML　＝　一時的に再利用性の低いHTML。もしくは今は利用できないHTML
理由と具体例は？

>CSSがstrict-HTMLに対応できていない
？

>見栄えと構造の分離はソースレベルでの話なのに、
>まるで実際のサイト作成・公開でも分離ができるみたいなね。

この発言の意図は？

>見栄えに関する部分を伝えられないのでやはり半人前だね。

「半人前」の用法が不適切であることはともかくとして、それが何か？

44 ：Name_Not_Found：04/09/05 20:12 ID:???

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50

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

P.S.
最近、知ったかのアホアンチが多いのでスルーを覚えるように

45 ：28：04/09/05 20:17 ID:???

>>43
結局理解できてなかっただけかｗ
簡潔って言葉の意味知らずに使ってたんじゃないか？

なんか初歩的に経験不足だと思うよ。勉強を進めていくといずれわかるよ。
まず文章を理解できるようになれるといいね。後は↓のスレで聞くよ。
【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50

46 ：Name_Not_Found：04/09/05 20:18 ID:???

ついに逃走

47 ：Name_Not_Found：04/09/05 20:19 ID:???

>>44
いらんコメントをつけて荒れる原因を作るな。

48 ：Name_Not_Found：04/09/05 20:19 ID:???

>>46-48
荒れる原因を作るな。

49 ：Name_Not_Found：04/09/05 20:21 ID:???

>>48
こいつアフォ？

50 ：Name_Not_Found：04/09/05 20:21 ID:???

えーっと、

「単品で（実質論を切り離して）Strict-HTML だけについて語るスレ」
が、ここで、

「Strict-HTML に関する話も含めながら、Webページ全体の話をするスレ」
が向こう、

ってことでFA？

なんか、混乱してるようなので。

51 ：Name_Not_Found：04/09/05 20:23 ID:???

>>47
まぁ28はともかくとして>27で晒されている香具師とか相当なバカだぜ？

MSがW3Cから抜けてるとか…
たぶん→ttp://japan.cnet.com/news/ent/story/0,2000047623,20053103,00.htm
このニュースを聞きかじって誤解してたんだろうけど…

52 ：Name_Not_Found：04/09/05 20:23 ID:???

で、このスレで話すべき内容を簡潔にいうと…↓

53 ：Name_Not_Found：04/09/05 20:25 ID:???

>>51
CSS3は草案からMSの人がやっているっていう情報元知らない？
何かいろんなとこにコピペがあって、このスレが派生元らしいんだけど。

54 ：Name_Not_Found：04/09/05 20:28 ID:???

みなさん色々と思うことはあるでしょうが

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50

これ以上このスレが荒らされるのは我慢できないので、↑に移動してください。

55 ：Name_Not_Found：04/09/05 20:28 ID:???

>>53
http://www.w3.org/TR/2003/CR-css3-text-20030514/
↑
このEditorの欄見てみ。

それと「いろんなとこにコピペ」ってスレのアドレス明記してくれ。
「MSがW3Cから抜けてる」ってコピペしなきゃならんから。

56 ：Name_Not_Found：04/09/05 20:32 ID:???

>>55
サンキュ。

57 ：Name_Not_Found：04/09/05 20:34 ID:???

>「MSがW3Cから抜けてる」ってコピペしなきゃならんから。

なんか最近精神年齢の低いやつが増えたな

58 ：Name_Not_Found：04/09/05 20:36 ID:???

>>57
わざわざそんなこと言うおまえもな

59 ：Name_Not_Found：04/09/05 20:36 ID:???

>>58
必死だな。

60 ：Name_Not_Found：04/09/05 20:39 ID:???

>>59
あんたも前スレの消失と共に逃げときゃよかったのにね…
6とかで食い下がるから…

61 ：Name_Not_Found：04/09/05 20:44 ID:???

>>60
>あんたも
お前は
「逃げておけばよかったなあ」
と思うような発言をしたわけだ。どれ？

62 ：Name_Not_Found：04/09/05 20:48 ID:???

「谷亮子も金メダリストだからね」
↑
>>61によれば発言者は金メダリストでなければならないらしい
(　´,_ゝ`)ﾌﾟｯ

63 ：Name_Not_Found：04/09/05 20:56 ID:???

流れを切ってスマソ。

Strict-HTML は見栄えに関する部分を全て、CSS なんかに
任せるってことですけど、例えば、

<p style="margin-top:5em;">hogehoge</p>

みたいに、style="" を使うのも NG なんでしょうか？

64 ：Name_Not_Found：04/09/05 20:57 ID:???

>>62
まるで小学生並みの脳みそだね。
感想と事実をごっちゃにしてるね。もう少しがんばって考えてみよう。

社会に出た時に>>60のような言い方では、理解してもらえないよ。

65 ：Name_Not_Found：04/09/05 20:59 ID:???

>>63
すっげ。これで馬鹿を叩きのめせるね。多分アフォだから反論もできないよ。

66 ：Name_Not_Found：04/09/05 21:03 ID:???

>>62
谷亮子に野村が
「お前も金メダル？」
といえば
「野村さんも金メダルだったんですね！？」
と返ってくるな。少しはリアルの会話をしとけよ。

67 ：Name_Not_Found：04/09/05 21:05 ID:???

>>63
NGではないと思うよ。でも外部ファイルにした方が断然便利じゃない？
ってスレ違いかも。

68 ：Name_Not_Found：04/09/05 21:06 ID:???

>>67
CSSを外部ファイルに記述しないと非strictなのですか？

69 ：Name_Not_Found：04/09/05 21:07 ID:???

>>63
どっかに良い参考リソースがあった気がしたが、見つからなかった。
まぁNGだわな。二つ目はstrictの観点からはずれてるだろうが

・構造（HTML）に見栄えに関する記述があるのは非strict。
・その要素のみにしか適用されないので、CSSの利便性を生かせない。

結局は、「構造と見栄の分離が出来ていないのでNG」ってことかな。

70 ：Name_Not_Found：04/09/05 21:13 ID:???

>>69
見栄えと構造の分離の意味を勘違いしてるなこいつ。

71 ：Name_Not_Found：04/09/05 21:15 ID:???

>>70
いや、してないから。
文章が悪かったのかもしれんが、ここでも言われてたことだし、（見つからなかったが）それにまつわる文書も多く目にした。

じゃあ捜してくるよ。

72 ：Name_Not_Found：04/09/05 21:17 ID:???

HTMLは構造を論理的にマークアップする言語。
CSSはHTMLのレンダリングするための言語。

HTMLファイルの中にCSSを直接書いてもStrictには変わらないと思うけど・・・
言語を分けるのが見栄えと構造の分離の意味だったよね？
でも利便性を著しく落としてまでそんなことする必要はないかと；

73 ：Name_Not_Found：04/09/05 21:20 ID:???

>>71
勘違いどころか理解できてないのね。まあ俺も同じだ。いわゆるなんとなくってやつで
公式の場でちゃんとした説明を求められると困るんだよなｗ

74 ：Name_Not_Found：04/09/05 21:29 ID:???

HTML記述の参考資料（技術者向け）　-　スタイルシートの利用について
http://d-club.cside.ne.jp/html_css/note03.html#s3t8

from DFJ　-　CSSの読み込みとセレクタ　ページ内の『タグ内にインラインで書き込む』
http://www.fromdfj.net/html/howtohp03.html

75 ：Name_Not_Found：04/09/05 21:36 ID:???

>>74
W3Cの資料原文を出してほしいな。

76 ：Name_Not_Found：04/09/05 21:40 ID:???

なんとなく荒れ気味なので、前スレの興味深い話題を発掘。
ボクシングのチャンピオンリストだが、

<ol>
<li>ちゃんぴおん</li>
<li><ol>
<li>1位</li>
<li>2位</li>
ry
</ol></li>
</ol>
だろ。なんで入れ子にするかというと、チャンピオン自体にヘビーだのクルーザーだのの序列があるから。
最初だけが特別なリストは別にclassとかふらなくてもリストを入れ子にすることで
表現できるのでは？
チャンピオン以外にはどんなのがあるのかなあ…。

77 ：Name_Not_Found：04/09/05 21:47 ID:???

>>76
とりあえず見出しなしのリストはやめて。<hn>でヘッダをつけてよ。

78 ：Name_Not_Found：04/09/05 21:53 ID:???

>>77
別にいいじゃん。例えば本文中のリストだったりするかもしれんだろ。
もし見出しなしのリストが不可ならリスト自体にcaptionを定義すべき。

79 ：Name_Not_Found：04/09/05 21:57 ID:???

>>76
>チャンピオン自体にヘビーだのクルーザーだのの序列があるから。
別にチャンピオンに限ったことではないでしょ。olは順列を示すだけなんだから
普通にやりなよ。

80 ：Name_Not_Found：04/09/05 21:59 ID:???

>>76
>ボクシングのチャンピオンリスト
？なんでチャンピオンリストなのに1位とかがあるの？

81 ：Name_Not_Found：04/09/05 22:00 ID:???

正直、リストはolとulどっちか一つでいいような気もする。abbrとかと同じで。
結局、ol使うときってラベルに頼りたい場面が多いってだけなような…。

82 ：Name_Not_Found：04/09/05 22:02 ID:???

>>81
そもそもolのラベルに頼ってる時点でolの使い方を間違っているよ。
順列があるだけで、1個目が１位とは限らない。

83 ：Name_Not_Found：04/09/05 22:04 ID:???

>>82
だから順列を明示するだけじゃ「？」なんだよね。
テキストのマークアップとしてはあんま役に立たない。

84 ：Name_Not_Found：04/09/05 22:06 ID:???

>>83
1位ほげ
2位はげ
3位ひげ

ラベルに頼らずこれを書くならulでもいいだろっていう意味だよね？
でもラベルはないけど、順列を壊されては困るものもあるんじゃないか？

85 ：Name_Not_Found：04/09/05 22:09 ID:???

>>84
だがulにおいて「順列が壊される」ってことあるかなー、と。
するとolとulの実質的な差はどこに？って思うんだよね。
俺がどっちかというとマークアップ派だから思うのかもしれない。

86 ：Name_Not_Found：04/09/05 22:09 ID:???

順列があるものol
ないものul

ただそれだけ。いちいち仕様にケチをつける必要はない。

87 ：Name_Not_Found：04/09/05 22:09 ID:???

テーブルでいいのれすよ

88 ：Name_Not_Found：04/09/05 22:11 ID:???

>>85
人が書き写す時に。
相手に順列があるかないかを伝えるのが目的。

89 ：Name_Not_Found：04/09/05 22:14 ID:???

<hn>ボクシング大会・結果順位</hn>
<ol>
<li>勝優太郎</li>
<li>水隼優次郎</li>
・・・
</ol>
とかじゃいかんのか

90 ：Name_Not_Found：04/09/05 22:15 ID:???

>>89
<hn>ボクシング大会・結果順位(1位～？位)</hn>
とかならラベルなしでもいいよ。

91 ：Name_Not_Found：04/09/05 22:21 ID:???

>>80
ボクシングの順位は

第一位：チャンピオン
第二位：ランキング１位
第三位：　　〃　　２位
　　　：
第n 位：　　〃　　n-1位

ということらしい。

92 ：Name_Not_Found：04/09/05 22:33 ID:???

>>90
より適切な要素 (ol) があるならそれを使う。
ただそれだけ。

93 ：Name_Not_Found：04/09/05 22:53 ID:???

なんか話が変わってるみたいだけど結局style属性を使うのは非strictなの？
それともstrictには変わりないの？

94 ：Name_Not_Found：04/09/05 23:00 ID:???

仕様書で言及があるのはこれくらいか？
ttp://www.w3.org/TR/html401/present/styles.html#adef-style
> For optimal flexibility, authors should define styles in external style sheets.

95 ：Name_Not_Found：04/09/05 23:09 ID:???

「さらに柔軟性を得たい場合には、作者は外部のスタイルシートに定義したほうが良い」
だから、別に問題はないんだろうね。

ただ、Strict かどうかとは、別の話だろうけど。

96 ：Name_Not_Found：04/09/05 23:25 ID:???

「さらに」なんて意味の単語は入っていないが。
optimalは「最善の・最も望ましい」

97 ：Name_Not_Found：04/09/05 23:34 ID:???

Strictとの関係は？

98 ：95：04/09/05 23:36 ID:???

そうだな。ミスリードだ。

ところで、Strict との関係は。

99 ：Name_Not_Found：04/09/06 00:01 ID:???

問題はHTMLとCSSを結びつけるインターフェースだな。
style 属性の役割は本質的に link rel="stylesheet" と同じだから、
もしも style 属性が非 Strict なら、link 要素でスタイルシートを指定するのも非 Strict だな。
HTMLが究極的に論理構造を実現するためだけの言語であるならば、
そのための語彙以外をHTMLに含めるべきではないから、
style 属性も link rel="stylesheet" もどちらも非 Strict だな。

結論: このスレにおける、スタイルシートと関係するあらゆる言及は非 Strict。
よって>>63のような疑問はこのスレでは生じ得ない。つまりあれは幻だ。

100 ：Name_Not_Found：04/09/06 00:08 ID:???

「そんな非現実的なことを」と仰るあなたはこちらへ。

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

101 ：Name_Not_Found：04/09/06 00:08 ID:???

XHTML1.1ではDeprecated(非推奨)だが。
http://www.w3.org/TR/xhtml11/doctype.html

102 ：Name_Not_Found：04/09/06 00:15 ID:???

>>99
link rel="stylesheet"云々に関しては、
『この文書の見栄えに関する記述は、hoge.cssにありますよ』
と言う"構造"を表しているのでは。

まぁそれが構造と言い切れるかは難しいけど。

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

>>102
その論理を用いると、style属性について
『この要素の見栄えに関する記述は、当該属性値にありますよ』
と言う"構造"を表している、という弁明が成り立つ。

なんにせよ、論理構造を表現する文書が見栄えについての情報を保有する必然性は皆無。
もちろん>>102の言うように、構造は表しているだろうが、見栄えのための構造など不要。

しかしながらふと思うに、スタイルシートについての議論が非Strictであることを示すためには、
このスレでそのことに言及しなければならないので、自己言及のパラドクスに陥るな。

104 ：Name_Not_Found：04/09/06 00:26 ID:???

>>103 =~ s/見栄えについての/見栄えについてのあらゆる/;

105 ：Name_Not_Found：04/09/06 00:45 ID:???

＞しかしながらふと思うに、スタイルシートについての議論が非Strictであることを示すためには、
＞このスレでそのことに言及しなければならないので、自己言及のパラドクスに陥るな。

そもそも、現行の HTML なり XHTML の DOCTYPE の枠組みの中で、
「論理構造を表現する文書」という部分と「見栄え」の部分を明確に
峻別できるかどうかも難しいところだからな。

実際それができなければ、Strict-HTML という定義付け自体がゆらいでくる。

106 ：Name_Not_Found：04/09/06 00:47 ID:???

ついでにふと思うに、例え論理構造を表す文書の中で見栄えに関する構造を用いたとしても、
その構造が見栄えのためのものであると、
見栄えという概念を持ち得ない論理構造の世界においては、
それを知る由も見なす術もないため、それは本質的に見栄えなどではない、
その論理空間にとって有意な何らかの論理構造として表現されるに過ぎないのではないか。
だとしたらHTMLは、スキーマに対して妥当なあらゆる文書を、
例えそれが不思議マークアップであっても、受け入れなければならないのか。

107 ：Name_Not_Found：04/09/06 00:54 ID:???

なんじゃそりゃ

108 ：Name_Not_Found：04/09/06 00:58 ID:???

>>106
スキーマに教えるか（できるかどうかは知らないが）、
人間が判断すればいいだけだろ。

HTML自体は知らなくても周りの誰かが知っていればいい。

109 ：Name_Not_Found：04/09/06 01:03 ID:???

ここはヲタスレってことでFA？

110 ：Name_Not_Found：04/09/06 01:14 ID:???

ついてこれないなら無理してレスする必要ないんだぞ。

有る意味隔離スレで有ることはみとめるが。

111 ：Name_Not_Found：04/09/06 01:39 ID:???

とりあえずxml-stylesheet PIを使うか。

>>106
しかし、視覚的要素や属性は視覚的UIで見栄えを変える要素とはっきり仕様書で意味付けされているのでそれは見栄え以外のなにものでもない。
じゃあ仕様書の言い回しがどこまで抽象化されれば見栄えでなくなるかという議論は難しいな。

一方でDTDには書いてないが、仕様書で既定されているものは多くある。だから
>だとしたらHTMLは、スキーマに対して妥当なあらゆる文書を、
>例えそれが不思議マークアップであっても、受け入れなければならないのか。
というのは無いかと。

112 ：Name_Not_Found：04/09/06 02:32 ID:???

>>111
まあ、この話はほとんどお遊び的で欠陥の多い思考実験だと思っておくれ。

それと、PIは内部構造がXMLではないから (だったと思う) 駄目みたいなことを
timblが言っていたという話を聞いたことがある。
ソースは確かW3Cのメーリングリストのどこかだったと思うのだけれど思い出せない。
もしかしたらrdfig (swig) IRCのほうかもしれない。

なお、>>99 (>>103) の発言を真に受けるのであれば、
例えPIであろうと何であろうと見栄えのための構造は使えないことになる。
そんな非現実的なことを、と仰る方は以下略。

113 ：Name_Not_Found：04/09/06 02:40 ID:???

パンくずリストって英語でなんて言うの？

114 ：Name_Not_Found：04/09/06 02:41 ID:???

>>113
topic path
トピックパス

115 ：Name_Not_Found：04/09/06 02:43 ID:???

>>114
即レスサンクスです

116 ：Name_Not_Found：04/09/06 02:44 ID:???

>>113
crumbs listとかどう？検索するとそれっぽいものが。

117 ：Name_Not_Found：04/09/06 02:47 ID:???

>>112
HTMLには完全に論理構造だけを記述し、CSSへのリンクも含めない。
同様にCSSも完全に見栄えだけを記述する。
さらに別ファイルで、XLink を使って、それらを結びつける。

完全に実装を無視してますが。(w

118 ：Name_Not_Found：04/09/06 03:08 ID:???

>>116
えぇっ！もうパンくずリストを作るクラス名をCreateTopicPathにしちゃったよ

119 ：Name_Not_Found：04/09/06 03:12 ID:???

>>118
文字列を選択→右クリック→リファクタリング→名前変更

120 ：Name_Not_Found：04/09/06 03:12 ID:???

>>118
そもそもパンくずリストなどというクラス名は妥当なのか？

121 ：Name_Not_Found：04/09/06 03:34 ID:???

>>all
topic-pathにするといいよ。

122 ：Name_Not_Found：04/09/06 03:35 ID:???

>>118
そのクラス名って何の？なんとなくPerlとかのモジュールを作ってる木がするんだけど；

123 ：Name_Not_Found：04/09/06 08:08 ID:???

昔のHTTP1．1(RFC 2068)には Link: ヘッダなんてのがあって
ネスケなんかではスタイルシートリンクにも使えたんだけどねぇ。

124 ：Name_Not_Found：04/09/06 10:48 ID:???

>>123
何でなくなったの？
HTTPに依存する限りは便利だと思うんだけどなあ。
と思ったので見てみた。

urn:ietf:rfc:2616
> The Alternates, Content-Version, Derived-From, Link, URI, Public and
> Content-Base header fields were defined in previous versions of this
> specification, but not commonly implemented. See RFC 2068 [33].

……。

125 ：Name_Not_Found：04/09/06 12:58 ID:???

>>77-78を見て思ったのですが、
リストに見出しはつけたほうがいいのでしょうか。
テーブルのcaptionのようなものはリストにはないのでしょうか。

126 ：Name_Not_Found：04/09/06 13:28 ID:???

>>122
phpのクラスです

127 ：Name_Not_Found：04/09/06 14:14 ID:???

Bread Crumbs
じゃないの？

128 ：Name_Not_Found：04/09/06 14:16 ID:???

>>124
ＲＦＣらしい理由であるが・・・・・　またＩＥか( ﾟДﾟ)ｺﾞﾙｧ!!

129 ：Name_Not_Found：04/09/06 17:25 ID:???

>>127
どっちでもいいらしい。
http://e-words.jp/w/E38391E383B3E3818FE3819AE383AAE382B9E38388.html

どうでもいいけど、「eXtensible」ってやめて欲しいよな。
「X」は発音来てるから、勧告に書いて有るとおり「Extensible」が正解のはずなのに。

>>125
要望が多いらしく、XHTML2.0の草案で新しくできてる。
http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_label

130 ：129：04/09/06 17:29 ID:???

「X」は発音から
の間違い。

131 ：Name_Not_Found：04/09/06 20:52 ID:???

>>all
みんな>>>125みたいなのにレスをつけるのがこのスレ本来の姿だよ。

>>125
例えばsectionの途中でのリストならば
<ol id="論理的なネーミング">
でもいいけど、できるだけhn要素でわかりやすくリストのヘッダをつけたほうがわかりやすいね。

ただhn要素やidをリストにつけるのは必須ではないから、そこらへんはあなたのさじ加減でどうぞ。

132 ：Name_Not_Found：04/09/07 12:47 ID:???

>>131
title 属性でどうよ。

133 ：Name_Not_Found：04/09/07 23:18 ID:???

上の方で
「HTMLに見栄えという概念は存在しない」
って言ってる人が多いけど、<hr>要素は名前からして見栄えなんですがね・・・・

もちろん見栄えとして使うものではなく、区切り的な使用なわけだけど。
だから要素自体は論理的だけど、名前に完全に見栄えの概念があると思われるんですが
どうしますか？

134 ：Name_Not_Found：04/09/08 00:11 ID:???

...このスレのｽﾄﾘｸﾀｰはhr要素(他にb,small要素あたりも)を
レガシーマークアップの残骸程度に思ってるだろ。
DTDが許可していても使う奴はほとんどいないよ。

135 ：Name_Not_Found：04/09/08 00:36 ID:???

>>134
ほぼ同意ですが。

hr は音声メディアのような時系列が関連するようなメディアでは
意味を持ってくるのではなかろうか、と思う。

136 ：Name_Not_Found：04/09/08 00:40 ID:???

>>135
具体例をキボンヌ

137 ：Name_Not_Found：04/09/08 01:10 ID:???

>>135
間、とか。

138 ：Name_Not_Found：04/09/08 06:14 ID:???

<div>
<h2>hogehoge</h2>
<p>mogemoge</p>
<h3>higehige</ｈ3>
<p>hugahuga</p>
</div>

上の形より

<div>
<h2>hogehoge</h2>
<p>mogemoge</p>
</div>
<div>
<h3>higehige</ｈ3>
<p>hugahuga</p>
</div>

下の形のほうが推奨？

139 ：Name_Not_Found：04/09/08 06:48 ID:ppDLRhWE

>>138
それだけではどちらが推奨なんて判断できないから、divにつけるclass||id次第かな。
class=chapterとclass=sectionであるならば下。
id=論理的なまとまりを示す名前　であるならば上。

140 ：Name_Not_Found：04/09/08 08:49 ID:???

>>139
ありがとー

141 ：Name_Not_Found：04/09/08 08:51 ID:???

>>137
hr に勝手な意味を付して「意味がある」というのはどうかと。

142 ：Name_Not_Found：04/09/08 09:27 ID:???

<div>
　<h2>hogehoge</h2>
　<p>mogemoge</p>
　<div>
　　<h3>higehige</ｈ3>
　　<p>hugahuga</p>
　</div>
</div>

がXHTML2.0の事を考えるとスマートかもね。

143 ：Name_Not_Found：04/09/08 09:27 ID:???

>>137
hrに間を持たせるかはCSSの問題だとおもうよ。

144 ：135=137：04/09/08 17:49 ID:???

すんません。
なんで hr とかしぶとく残っているのかな、
なんか意味があるのかもしれないなー

って妄想しただけなので。
お騒がせすまそ。

145 ：Name_Not_Found：04/09/08 18:45 ID:???

bもiも含め旧時代の名残だよ。font要素なんてものも蔓延っていたわけだし。

146 ：Name_Not_Found：04/09/08 20:34 ID:???

bigとかと同類だしなぁ
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_presentationmodule

147 ：Name_Not_Found：04/09/08 20:57 ID:???

>>134
ウチは、いわゆるトークの書き起こしみたいなのをやってるが、
小声でボソボソいう部分は<small>使ってる。
<big>も大声で使ってるから無くなると困るなー
まあ、こんな意見は少数派なんだろうけど。

148 ：Name_Not_Found：04/09/08 21:00 ID:???

>>147
そういうのはこちらで。
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

149 ：Name_Not_Found：04/09/08 21:11 ID:???

>>147
<span class="small-voice">ボソボソ</span>
<span class="big-voice">ぎゃー！</span>
じゃダメなの？
これだと黄色い声とかも表現できるよ！キャー！

150 ：Name_Not_Found：04/09/08 21:20 ID:???

>>149
そのマークアップは非理論的だろ。
big-voiceはemに置き換えるべきだし、
smallは要素には置換できないとしても、
物理的なクラス名は避けた方が良いと思う。

151 ：Name_Not_Found：04/09/08 22:10 ID:???

hrは区切りなんだから論理的なんだけど・・・・・
あれ？俺の勘違いか？例えば本の右下にあるページ数なんてのはhrの後に書けばbody内にかける。

まあヘッダに書いてそれをCSSで表示って方がいいかもしれないがね。

152 ：Name_Not_Found：04/09/08 22:16 ID:???

>>151
論理的だけど、XMLのマークアップの特徴が入れ子構造なので推奨されない

153 ：Name_Not_Found：04/09/08 22:17 ID:???

>>151
hrは罫線を引くというだけであって、論理的な区切りの意味が発生するか定かではない、
…という人もいる。この事情はbrと同じ。

154 ：Name_Not_Found：04/09/08 22:26 ID:???

>>152
あぁ。俺はHTML4.01でのことしか考えてなかったよ。
>>153
俺としてはW3Cが残した要素はすべて論理的であると考えてるけどね。
ただこのスレでのstrictの潔癖性から行くと使わないで済ませるなら
済まそうってことになっちゃうのかな・・・・・

155 ：Name_Not_Found：04/09/08 22:34 ID:???

>>154
> W3Cが残した要素はすべて論理的
都合のいい解釈だな。
ただの歴史的経緯で残っているだけだが。

156 ：Name_Not_Found：04/09/08 22:41 ID:???

>>152
別に「区切りとしての空要素」を使う事が
XMLの仕様上非推奨な訳ではないでしょ。

DOMやXPathで「区切りとしての空要素」とか
「並んでいる特定の兄弟要素はグループ」とかを
扱うのが面倒ってだけで。

157 ：Name_Not_Found：04/09/08 22:48 ID:???

XHTML2.0でもseparatorとして残るしなぁ。

158 ：Name_Not_Found：04/09/08 23:26 ID:???

hrが物理要素だと主張している人は
ブロックレベル要素であっても、構造上論理的な意味を持たないと
主張しているの？

159 ：難しい・・：04/09/08 23:27 ID:x6Cj2khj

自分のホームページで音楽を流したいんですけど、よく再生とか停止とかついてる
バーを他のホームページで見かけるんですど、あれはどうやったらつけられるの
でしょうか？

160 ：Name_Not_Found：04/09/08 23:29 ID:???

>>159
スレ違い

161 ：Name_Not_Found：04/09/08 23:29 ID:???

>>159
http://pc5.2ch.net/test/read.cgi/hp/1094219908/

162 ：Name_Not_Found：04/09/08 23:34 ID:???

>>155
>ただの歴史的経緯で残っているだけだが。
それもおまいの都合のいい解釈では？

163 ：Name_Not_Found：04/09/08 23:35 ID:???

>>159
なんだコイツはｗ何故にこのスレに投稿したんだろうか？

164 ：Name_Not_Found：04/09/08 23:40 ID:???

>>162
お前は b 要素も i 要素も W3C が Strict DTD に残したものだから
構造上論理的な意味があると信じたいわけね。

165 ：Name_Not_Found：04/09/08 23:50 ID:???

>>157
いやまぁ、hrが『horizontal rule to be rendered by visual user agents』なのに対し、
separatorは『break in the document.』との説明があるから、一応進歩していると思われ。

brもlになり、一応『文書の意味的な区切りを表す』とされているし。

166 ：Name_Not_Found：04/09/08 23:52 ID:???

いや、要素lは
『represents a semantic line of text 』
なので
『テキストの意味に関する行を示す』
だな。
大体lはbrと違ってテキストを入れ子にするもんだしな。ごめそ（´・ω・｀）

167 ：?i¨?μ?￠?E?E：04/09/08 23:54 ID:x6Cj2khj

>>163
ふざけってっとぶっ放すぞコラ

168 ：Name_Not_Found：04/09/09 00:07 ID:???

>>164
だからおまいの都合のいい解釈だろ？bやiが残ってる理由とhrの理由が同じだなんてどこに
記述があるのよ？

169 ：Name_Not_Found：04/09/09 00:09 ID:???

>>159
>>163
>>167

初心者スレから記念まきこ

170 ：Name_Not_Found：04/09/09 00:11 ID:???

>>168
どうでもいいが、
どちらが都合のいい解釈であるかが未定義なわけで。
両者とも非論理的な罵り合いはやめにしようよ。

171 ：Name_Not_Found：04/09/09 00:13 ID:???

The HR element causes a horizontal rule to be rendered by visual user agents.

結局、仕様書のこの説明書きから論理的な意味が見出せないから、と言うことっしょ。

172 ：168 162：04/09/09 00:13 ID:???

っていうか俺は154じゃねえぞ。だから「どちら」、とか二極化するなよ。

173 ：Name_Not_Found：04/09/09 00:17 ID:???

>>みんな
そもそも「意味のある線」と「意味のない線」があって、前者はhr後者はボダでやるのが普通でしょ。

それのどこにも問題は感じられないんだが？

174 ：Name_Not_Found：04/09/09 00:22 ID:???

>>173
だから、仕様書には「論理的に意味がある線」と定義されていないんだよ。
「ヴィジュアルUAでは、水平線が引かれますよ」としか。

だから>>165にもあるように、XHTML2.0ではseparatorとし、「ドキュメントの区切りですよ」と言う定義に変わった。

175 ：Name_Not_Found：04/09/09 00:25 ID:???

>>171
Inherent in this structural distinction is the idea that block elements create "larger" structures than inline elements.

176 ：Name_Not_Found：04/09/09 00:33 ID:???

>>174
ほう。hrを論理的なものとし、>>173のように使うこと自体がHTML4.01では
独自拡張解釈になってしまうということか。納得。

177 ：Name_Not_Found：04/09/09 01:13 ID:???

Index of Elements
http://www.w3.org/TR/html401/index/elements.html

bなんぞは、「bold text "style"」とかモロに定義しちゃってる訳で、
やはり>>155の「歴史的経緯」と言う解釈が妥当なのでは。

当時のW3Cが「Transitional」と言う概念にに縛られすぎていたのだと思うよ。

178 ：Name_Not_Found：04/09/09 01:27 ID:???

>>171
でも実は、HTML2.0 の仕様書では、

The <HR> element is a divider between sections of text;

となっていて、HTML3.2 では、

Horizontal rules may be used to indicate a change in topic.

となっていた。つまり、どちらの仕様書でも <HR> は文書の区切りを
表す要素で、その表示例が横線を引くという定義だったんだよ。

それなのになぜ、HTML4.0x では、その論理的な定義部分をなくしたのか、
というところが問題だと思う。本来、論理的な要素のはずだったのに。

179 ：Name_Not_Found：04/09/09 01:38 ID:???

>>178
何らかの議論があって変更されたというだけでしょう。
なんにせよHTML4.01のhrは論理的な要素でないという事実は変わらない。
それに、separatorが出てきて論理的な定義が復活したのだし、問題ない。

180 ：Name_Not_Found：04/09/09 02:11 ID:???

>>179
しかし、Changes には物理要素に変わりましたというようなことは何も
触れられてないんだよな。
で、問題ないというが、互換性という非常に大きな問題があるぞ。

181 ：Name_Not_Found：04/09/09 06:12 ID:???

最近ふと思った

<hn>...</hn>
<p>...</p>
<ul>...</ul>
<p>...</p>
<hn-1>...</hn-1>
<p>...</p>

こういういかにもstrictっぽい構成って実は完全に非strictなんじゃないか？
そもそも見出し1個に段落複数のリスト1個ってありえないだろ。よ～く考えてみろよ・・・

段落やリストには必ずhnがあるんだよ。それを表示するか否かはCSSで好きにすればいい。
しかしブロック要素には必ず1対のhn要素が必要なんだよ。だってそうだろ？
いきなりリスト出されても意味不明だしな。

一つの見出しに複数の段落orリストがあってはいけない。つまるところそれは
「h1が1個ありそれ以外にhn要素を使ってないページ」と同じだ。必ずブロック要素には
小見出しがつくべきだ。

こんなアフォみたいなネタを考えてみた。さあおまいらかかって来い。

182 ：Name_Not_Found：04/09/09 07:57 ID:???

>>181
そういう主張はブロックごとに見出しを振ったテキストで書き込んでもらうと
説得力があるんじゃないかな。

183 ：Name_Not_Found：04/09/09 09:23 ID:???

>>182
どういうこと？住人なら
「ブロック要素には小見出しがつくべきだ。」
で理解してもらえるかと思ったけど・・・・・・

184 ：Name_Not_Found：04/09/09 09:29 ID:???

>>181
の書き込み自体が段落（おそらく1行あいた部分だろう）
ごとに見出しを付けてない。

見だしの必然性を叫ぶならば最初に実践してくれよ、ってことだろ。

>ブロック要素には小見出しが付くべきだ
こんなこと、どこで覚えてきたんだよ・・・。

185 ：Name_Not_Found：04/09/09 09:32 ID:???

起：
最近ふと思った

ソース：
（中略）

承：
こういういかにもstrictっぽい構成って実は完全に非strictなんじゃないか？
そもそも見出し1個に段落複数のリスト1個ってありえないだろ。よ～く考えてみろよ・・・

転：
段落やリストには必ずhnがあるんだよ。それを表示するか否かはCSSで好きにすればいい。
しかしブロック要素には必ず1対のhn要素が必要なんだよ。だってそうだろ？
いきなりリスト出されても意味不明だしな。

結：
一つの見出しに複数の段落orリストがあってはいけない。つまるところそれは
「h1が1個ありそれ以外にhn要素を使ってないページ」と同じだ。必ずブロック要素には
小見出しがつくべきだ。

おまけ：
こんなアフォみたいなネタを考えてみた。さあおまいらかかって来い。

186 ：Name_Not_Found：04/09/09 10:02 ID:???

ネタ投下としてはいまいち弱いなあ>181

必ずブロック要素にはtitle属性がつくべきだ。

ぐらいの方が盛り上がるんじゃ。

187 ：Name_Not_Found：04/09/09 10:46 ID:???

>>179
>HTML4.01のhrは論理的な要素でないという事実

またループの予感

188 ：Name_Not_Found：04/09/09 11:41 ID:???

>>182 >>184
それは無理だろ。だってここでは自分の発言にCSSを適用できないんだから
見易さを失ってしまうよ。こういうところでの空行は論理的なものではないから
しょうがない。

189 ：Name_Not_Found：04/09/09 11:47 ID:???

>>185
簡潔にまとめると…

ネタ：すべてのブロック要素は見出しを持つべき

答え：別にそうとは限らない

190 ：Name_Not_Found：04/09/09 11:57 ID:???

よしおまいらネタを変えよう！

　例えばAという文書があると仮定する。文書Aは論理的な文章だとは言えない。
話の途中にいきなりリストがでてきたり（話の流れを読むとなんとなく何のリストかは予想できるが）
段落とは思えないところに空行が入っていたり、見出しが皆無だったり、要は紙媒体に出力されている論理的でないAという文書。

　さて元々論理的ではない文書AをHTMLでstrictにマークアップした場合、そのHTMLファイルは
strictになっているだろうか？

　この問題点はただ一つ。元々文書Aには存在しなかった中身テキストをHTML化するとき
に勝手に付け足すのが是か非かという1点である。例えば見出しはないはずなのに見出しを
加えたり、その他もろもろ補正をしてからCSSで消して、元の状況を再現するということは果たして
正しいのだろうか？

　つまるところ非strictな文章をstrict-HTMLに仕上げることは可能なのかという問いかけである。

191 ：Name_Not_Found：04/09/09 12:14 ID:???

192 ：Name_Not_Found：04/09/09 12:16 ID:???

193 ：Name_Not_Found：04/09/09 12:22 ID:???

>>190
翻訳家の人は、例えば英語→日本語の翻訳の場合、
原文の章や段落、文の順序・区切りなどの構成を日本語の構造に合うように再構成したりするらしい。

194 ：Name_Not_Found：04/09/09 12:28 ID:???

１９０　は　＜ＰＲＥ＞　を　おぼえた！
かしこさ　が　１　あがった！

195 ：Name_Not_Found：04/09/09 14:05 ID:???

ブロックごとに見出し…激しく面倒だな。

<h>hogeについて</h>

<p>...hogeについて以下のようになる。</p>

<h>hogeの一覧</h>

<ul>
<li>...</li>
...
</ul>

おっと、見出し要素にも見出しをつけないといけないのか。となると（以下略）。

196 ：Name_Not_Found：04/09/09 15:41 ID:???

ドキュメントをマークアップするためのhtmlであって、
htmlに合わせたドキュメントを作らなければならないようでは、
本末転倒なのでは？

197 ：Name_Not_Found：04/09/09 16:05 ID:???

文書を論理的な構造にすることじゃないのか？

198 ：Name_Not_Found：04/09/09 16:54 ID:???

論理的な構造に変更するのも本末転倒でないの。

199 ：Name_Not_Found：04/09/09 17:44 ID:???

そう思う。
元の文章が論理的でないんなら、そのことをちゃんと読み手に伝えないと。
付け加えたいんなら注釈とわかる形で説明を加えりゃいい。
そもそも、見出しがある＝論理的、見出しがない＝非論理的という
発想が理解できないんだが。

200 ：Name_Not_Found：04/09/09 17:46 ID:???

そもそも論理的とはどういうことなんだ。

201 ：147：04/09/09 19:31 ID:???

1日でかなり流れたな（汗
>>149
ダメという事はないし、実際2.0に移行したらそうせざるを得ませんが、
<small>の方がシンプルでよいと思ってるので。
<small>とは別に<span class="～">を使うことはあります。
黄色い声はありませんが、エロボイス用クラス名は用意してますｗ

>>150
<em>は純粋に内容の強調部分で使っているので
小声だが重要な発言をあらわす時は
<small><em>なんだってーー！（AA略）</em></small>
とすることさえあります。

スレの流れを寸断してすいません。
それでは続きをどうぞ↓

202 ：Name_Not_Found：04/09/09 20:05 ID:???

>>201
smallってのは、純粋に文字の大きさだけを小さくする。飽く迄も"small text style"。
要するに、ヴィジュアルUAのみに存在する視覚効果であって、シンプルも何も、構造とは無縁。

あと、small-voiceやbig-voiceも良くない。
抑揚や音の大きさを決めるのはaural style sheetsの仕事だからね。

そもそも、声に関する概念があるのはaural style sheetsが有効なUA、つまりスクリーンリーダーだけでしょ。
声が大きかろうが小さかろうが、そのテキストが重要であるならem。
重要でないなら、どうにかして重要でないと言うことを示せ。

203 ：Name_Not_Found：04/09/09 21:07 ID:???

>>202
>重要でないなら、どうにかして重要でないと言うことを示せ。

<em>や<strong>は重要ということを示してるんじゃなくて比較しての差の大きさを表してるんだろ。
だから強調とは限らない。まあ裏を返せば「差」というのは+でも-でも強調であると。

204 ：201：04/09/09 21:32 ID:???

>>202
＞smallってのは（略）飽く迄も"small text style"。
きっと反論されるだろうと思ってましたし、正論だと思います。
ただ、現に<small>という便利な要素があるんだから
流用してしまおうという程度の感覚です（このスレではNGですかね）

＞small-voiceやbig-voiceも良くない
あくまで発言者が意図したもの（トークを構成するもの）なので
この際スタイルシートは無関係だと思います。

205 ：Name_Not_Found：04/09/09 21:34 ID:???

>>203
> 比較しての差の大きさを表してる
仕様書のどこにそんなことが書いてあるんだ？

206 ：Name_Not_Found：04/09/09 21:49 ID:???

>HTML4.01のhrは論理的な要素でないという事実

ということは論理的に文章構造へ影響を与えないということかいな？？

207 ：Name_Not_Found：04/09/09 21:54 ID:???

>>206
まあまあ。彼は

論理的であると書かれていない == 論理的でない

と主張しているだけで。
論理性を語るならまず、真偽と背反あたりから勉強してもらいたいものだね、と。

208 ：Name_Not_Found：04/09/09 22:01 ID:???

そんなこと言ったら論理的だと書かれている要素はない気がするぞ。

209 ：Name_Not_Found：04/09/09 22:08 ID:???

どうでもいい。

210 ：Name_Not_Found：04/09/09 22:13 ID:???

それをいっちゃあおしめえよ

211 ：Name_Not_Found：04/09/09 22:34 ID:???

もしもhrがインライン要素だったら179に同意するがな。

212 ：Name_Not_Found：04/09/09 23:01 ID:???

とろろか。

213 ：Name_Not_Found：04/09/09 23:12 ID:???

そういえば、style要素って XHTML 1.1 だと「推奨しない」なのに、2.0 でも
残ってるね。
何でだろ？

214 ：Name_Not_Found：04/09/09 23:13 ID:???

どうしても外部ファイルを使えない状況を考慮してるんじゃない？

215 ：Name_Not_Found：04/09/09 23:24 ID:???

>>213
＞XHTML 1.1 だと「推奨しない」
え？そうだっけ。style属性の方だと思ってた。

216 ：Name_Not_Found：04/09/09 23:31 ID:???

>>201,204 >>202
>201の場合、マークアップする対象が音声なんだから、
そこに意味合いとして声の大きい小さいが含まれているとはおもう。
で、それをクラス名に使うのは　スタイル　を表現するためではなくて、
ソースにあってテキストではあらわしきれないものを表現しているのだから、問題ないと思うな。
もちろん、大きい声のところが意味合いとして強調であるならspanなんぞ使わずemをつかって、
<em class="big-voice">Ｓｔｒｉｃｔマンセー</em>とすべきだと思うけど。

まぁ、ＨＴＭＬは話した内容を表現するためのものじゃないからな。

217 ：Name_Not_Found：04/09/10 00:14 ID:???

>>216
声の大きい小さいという意味は仕様書には定義されてないので、
そのような意味は含まれていない。

218 ：Name_Not_Found：04/09/10 02:03 ID:???

>>217
いや、含まれていないからclass値にするわけで。
class値に与えておけば、後々利用できるわけよ。
ＨＴＭＬとして意味があるとは言っていない。

219 ：216=218：04/09/10 02:11 ID:???

ああ、>216の
>そこに意味合いとして声の大きい小さいが含まれているとはおもう。
ってのは、ソースである音声にね。
ソースに含まれてる声の大小をどうＨＴＭＬに含ませるかが問題なわけで。

220 ：Name_Not_Found：04/09/10 06:12 ID:???

>論理的だと書かれている要素はない

このスレ的には論理的であると推測できるかって辺りが重要なんだよね？
例えばhn要素は見出しでしょ。で、見出しは論理的でしょ。で、hrはhtml4.01では
論理的であると推測できる説明がなされていない。なので論理的でない。

ところで
id=main
これって論理的だと思う？
class=main
とどちらが論理的かなと最近思うんだけどさ。
idの値ってそのページのみでユニークであればいいのかな？例えばid=mainなんて
全部の文書を１個にまとめた時にユニークでなくなる可能性があるけどどうなんだろ。
極端な話、HTMLって・・・というかサイトって通常１文書（１冊の本）のものを
ユーザビリティ的に複数の文書に分割してるんだと思う。だからidはすべてをまとめたときにも
ユニークさを失ってはいけないなんちゃて。ウヒョ！

221 ：Name_Not_Found：04/09/10 07:50 ID:???

>>200
論理構造の「論理」ってのは、
論理ドライブとか論理フォーマットとか言うときの「論理」と同じ。

何か勘違いしてる人も多そうだが。

222 ：Name_Not_Found：04/09/10 08:43 ID:???

>>221
こいつ......
もっと一般人にもわかりやすい例えを選べなくちゃ意味ないだろ。
これがヲタの感覚なのかね・・・

223 ：Name_Not_Found：04/09/10 09:05 ID:???

>>222
> 一般人にもわかりやすい例え
そういうのって、やっぱり一般人には解りにくいことが多いんだよ。
どこがどういう例えになっているのか、説明する側にしか解らなかったりする。
解ったつもりの誤解を広げるだけならヘンな例えはしない方がいい。

224 ：Name_Not_Found：04/09/10 09:46 ID:???

>>223
＞解ったつもりの誤解を広げるだけならヘンな例えはしない方がいい。
自分で自分に何をいってるんだい？

225 ：Name_Not_Found：04/09/10 10:35 ID:???

すまんが、大声や小声って非論理的なのか？
赤や黄色といったものが物理的だということは理解できるんだが、大声や
小声に関してはいまいち納得ができん…。
ビジュアルなUAなら大声はフォントサイズを大きくするだろうし、音声UAな
ら出力音声を大きくするだろうし。

ソース
<p>太郎は<span class="small-voice">どうなんだろう？</span>と言った。</p>
span.small-voice:before {
content:'(声を小さくして)';
}
出力例
太郎は(声を小さくして)どうなんだろう？と言った。

スレ違いだったら出直してきます。

226 ：Name_Not_Found：04/09/10 11:06 ID:???

>>225
＞class="small-voice"
これ、class="red-bigfont"等とどう違うの？

227 ：Name_Not_Found：04/09/10 11:09 ID:???

おいバカども、ショーもねえこと書こむな
オレのところでも見て修行しろ
次に立てる奴はちゃんとテンプレに入れとけよ

ttp://www.sal.tohoku.ac.jp/~gothit/gothitj.html

お前らがいいもん作れたら、ここで紹介してやるよ
ttp://www.rinku.zaq.ne.jp/bkcyq100/html_diary.htm

228 ：Name_Not_Found：04/09/10 11:11 ID:???

「弱調」って感じだったらsmallを使ってもよいんじゃないのか。
過去ログなんかではけっこう既出だけど。

229 ：Name_Not_Found：04/09/10 11:20 ID:???

だからemやstrongは他との差の大きさだって言ってるじゃん。
弱長なんていらいないよ。

230 ：Name_Not_Found：04/09/10 11:25 ID:???

>>229
それはあんたの自説にすぎないだろうが。

231 ：Name_Not_Found：04/09/10 11:52 ID:???

232 ：Name_Not_Found：04/09/10 11:57 ID:???

bとかsmallとかhrとかbrは、このスレ的にはNGと思ってたけど、そうでもないのか。
じゃあこうしよう。
上述した要素を非許容：硬派ストリクター
上述した要素を許容：軟派ストリクター

233 ：Name_Not_Found：04/09/10 12:28 ID:???

じゃあ、hrとbrだけ許容する私は普通のストリクターか

234 ：Name_Not_Found：04/09/10 13:03 ID:???

俺もだ

235 ：Name_Not_Found：04/09/10 13:04 ID:???

いえ、曖昧ストリクター

236 ：Name_Not_Found：04/09/10 13:15 ID:???

現状は"並"と"大"だけか
強調があるならその逆もあってもいいかもな

237 ：Name_Not_Found：04/09/10 13:25 ID:???

<p>自然数全体の集合を<b>N</b>とする。</p>

みたいなb要素の使い方は、個人的には許容したい。

238 ：Name_Not_Found：04/09/10 13:29 ID:???

emやstrongは強調だろ？

きょうちょう　きやうてう 0 【強調】

（名）スル
(1)ある部分を特に調子を強めていうこと。また、意見・内容を強く主張すること。
「軍縮の必要性を―する」
(2)音楽・絵画などで、ある一部分を目立つように表現すること。
(3)相場で、強含みのこと。

あと小声はclass="whispler"とかclass="low-voice"にしておけばいいんじゃな
いの？

239 ：Name_Not_Found：04/09/10 13:31 ID:???

>>237
dfn。

240 ：Name_Not_Found：04/09/10 13:33 ID:???

>>239
君は大学以上の数学ならったことないね。
ベクトルとか集合は太字で書く慣習があったりする場合もある。

241 ：225：04/09/10 13:37 ID:???

>>226
誘導されなかったのでここでレスつけます。

例えば、"幼児向けテキスト"なんかだとこれもアリではないのかと
思ったりしちゃうわけですがダメですかね。
<span class="yellow">ひまわり</span>
<span class="red">りんご</span>
ひまわりに黄色という意味づけ、りんごに赤という意味づけをしているわけで。
もちろん普通の文章で<span class="red">俺様最高！</span>なんてのは
許せませんが。

それを考えると、大声や小声も音声に対して強弱を意味づけるのであれば
使っていいんじゃないか？と思うのですが。

242 ：Name_Not_Found：04/09/10 13:38 ID:???

>>240
いや、dfn"も"。

243 ：Name_Not_Found：04/09/10 13:53 ID:???

>>241
じゃ、誘導。

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

244 ：Name_Not_Found：04/09/10 13:58 ID:???

>>240
君は過去スレ読んだこととないね。
その話題は何度も出ていたりする。
その各場所で議論されたことに異論があるなら、
アンカー示してなにがどう問題で、どういう立場を取るのか述べてくれ。

245 ：Name_Not_Found：04/09/10 14:02 ID:???

>>244
「あり」が大勢だったようだけど。
異論があるのは君の方だね。

246 ：Name_Not_Found：04/09/10 14:02 ID:???

なんじゃそりゃ

247 ：Name_Not_Found：04/09/10 14:13 ID:???

OK、b・small・hr・br要素とかの利用についてのまとめネタだ。

まず、4.01系統の仕様では利用が認められている。
よって、これについて何らかの自己規制を加えるかどうかは専ら宗教的な問題である。

仕様以上の厳格さを求める「ストリクター」という観点で考えると、
これらの要素は見栄えのための要素であり、利用は好ましくないとされている。

というわけで、
これらの要素を全て非許容：硬派ストリクター
これらの要素の一部を許容：曖昧ストリクター
これらの要素の全てを許容：軟派ストリクター or 大衆

248 ：Name_Not_Found：04/09/10 14:14 ID:???

>仕様以上の厳格さを求める「ストリクター」という観点で考えると、
>これらの要素は見栄えのための要素であり、利用は好ましくないとされている。

使うストリクターはそうは考えていないんだろ。散々ループしたじゃん。

249 ：Name_Not_Found：04/09/10 14:17 ID:???

「ベクトルとか集合は太字で書く慣習」ってのはスタイルの問題だろ。
慣習にせよ伝統にせよ、これは論理空間で扱う問題じゃない。
ベクトルや集合を組み込まれた文書を取り扱うUAが定義部位を太字にすればいいだけ。

250 ：Name_Not_Found：04/09/10 14:20 ID:???

太字であること自体に意味があるってことじゃね？

251 ：Name_Not_Found：04/09/10 14:23:15 ID:???

>>248
そうなのか？ストリクターの定義が最近良くわからん。

252 ：Name_Not_Found：04/09/10 14:25:25 ID:???

>>249
同じくそう思う。
太字であることとに意味があるのは紙上の話で、HTMLには当てはまらない。

253 ：Name_Not_Found：04/09/10 14:30:15 ID:???

>>251
そこの君、では、>>247のうち第三段落を削除して、
最後の段落をストリクターの定義にしないか。
ストリクターは実は一種類ではなく派閥があるのだ。

# ふと気づいたが、投稿時刻に秒数が記録されてるぞ。

254 ：Name_Not_Found：04/09/10 14:31:31 ID:???

例えば英文でセンテンスの先頭を大文字にするのはスタイルの問題だと言い張ることもできる。
そのあたりは言語の領域に踏み込むお話。

255 ：Name_Not_Found：04/09/10 14:42:43 ID:???

ストリクターの派閥は、
・テキストマークアップ派（はじめにテキストありきって人）
・論理空間構築派（テキストを前提としない人）
に別れているんだと思う。

256 ：Name_Not_Found：04/09/10 14:47:09 ID:???

>>254
HTMLに用意されていない機能は実現できない、ということでは。
用意されていなければ、
手持ちの機能を他の用途に用いるか、
汎用要素でマークアップするか、
用意されていないものは仕方ないとして諦めるか、
のどれかを選ぶことになるだろうし。

>>255
分かれているとなると、各人がスタンスを明確にして議論しないと泥沼になるね。

257 ：Name_Not_Found：04/09/10 14:55:37 ID:???

<h1>xxx</h1>
<h2>xxx</h2>
<h3>xxx</h3>
<h3>xxx</h3>
<h3>xxx</h3>
----------
<h2>xxx</h2>
<h3>xxx</h3>
<h3>xxx</h3>

たとえばこういう感じのドキュメントがあって、長すぎるので「----------」の部分から下は新しい
ファイルにした場合、その新しいファイルにも<h1>レベルは必要ですか？
あと、ファイルが違うので１つめの<h2>と２つめの<h2>に同じidをつけてもいいですか？

258 ：256：04/09/10 14:57:24 ID:???

<h1>xxx</h1>
　　<h2>xxx</h2>
　　　　<h3>xxx</h3>
　　　　<h3>xxx</h3>
　　　　<h3>xxx</h3>
----------
　　<h2>xxx</h2>
　　　　<h3>xxx</h3>
　　　　<h3>xxx</h3>

インデントしてみました・・・

259 ：Name_Not_Found：04/09/10 15:44:57 ID:???

>>252
数式の場合は同じじゃないと思うなぁ。
NとボールドNになんら関連性があるわけではないし。
まったく別の意味の字として使うよ。

よって、 ℕ(U+2115) って書いといて、フォントない人には諦めてもらえ（だめじゃん

260 ：Name_Not_Found：04/09/10 15:50:40 ID:???

>>257
h1要素よりも先にh2要素が登場するとStrict以前にNot Valid。h1要素は必要。

idは別文書なら良いでしょ。
どういう経緯があろうとも、別のファイルなら別のファイルとして考えれば良い。
関連性はlink要素などで示せるわけだから。

261 ：Name_Not_Found：04/09/10 15:55:17 ID:???

HTML4.01等では数式のマークアップは無理。
その為にMathematical Markup Languageがあると思うのだがどうよ。
ttp://www.w3.org/TR/2001/REC-MathML2-20010221/

262 ：Name_Not_Found：04/09/10 15:56:16 ID:???

w3cのチェックツールを使ってチェックしたら、
http://validator.w3.org/check

head に noscriptを使っていたら怒られた。
このheadにあるscriptではheadにcssへのリンクを記述するので、
bodyには持って行けない。

解決策としては、cssのオーバーライドを使って、
noscriptを使わないことを考えているんだけど、
headに置いたscriptでdocument.writeを使うのは違反になるのか？

263 ：Name_Not_Found：04/09/10 15:56:44 ID:???

>>260
細かい話だがNot Validではないんじゃなかったっけ？
ISO-HTMLとかではそうだが。

264 ：Name_Not_Found：04/09/10 15:57:49 ID:???

以下はチェックツールのコメント。

The element named above was found in a context where it is not allowed.
This could mean that you have incorrectly nested elements
-- such as a "style" element in the "body" section instead of inside "head"
-- or two elements that overlap (which is not allowed).

One common cause for this error is the use of XHTML syntax in HTML documents.
Due to HTML's rules of implicitly closed elements, this error can create cascading effects.
For instance, using XHTML's "self-closing" tags for "meta" and "link" in the "head" section
of a HTML document may cause the parser to infer the end of the "head" section and the beginning
of the "body" section (where "link" and "meta" are not allowed; hence the reported error).

265 ：257：04/09/10 15:59:19 ID:???

>>260
ページが変わっても、<h1>には同じことを書けば委員ですね。ありがとう。

IDについては、>>220を見て思いました。どうなんだろーうって。

266 ：Name_Not_Found：04/09/10 16:02:53 ID:???

ヘッダ内にメタ要素でcontent-style-typeとかcontent-script-typeとかを書くのは
そのhtmlファイル内にCSSとかJavascriptとかが書かれている場合？
それともリンク要素で呼び出されてる場合？
それともそれとも、どっちの場合も？

できればソースきぼんぬ。

267 ：Name_Not_Found：04/09/10 16:08:48 ID:???

どっちもじゃねーの?ソースはしらね

268 ：Name_Not_Found：04/09/10 16:18:54 ID:???

>>266
link要素には type を書くんだからいらない。
ソースに埋め込んだスタイルシートやスクリプトの種類を特定するためにかくもの。

じゃない？

269 ：Name_Not_Found：04/09/10 16:31:01 ID:???

>>268
そのはず。助長だしね。

270 ：266：04/09/10 16:35:07 ID:???

やっぱり不要そうなんですか？
なんとなくそんな気がしたりもしてたのですが、
不安なのでとりあえず書いてました。

271 ：Name_Not_Found：04/09/10 16:57:18 ID:???

xhtml1.1 だと <meta http-equiv=""> はないから、
外部リンクだといらないかも。

272 ：Name_Not_Found：04/09/10 17:21:37 ID:???

>>254
確かに言語学とか各国の文化とかに関わってくる話かも。
あちらの国の文におけるイタリックとかボールドって
日本語の文におけるフォント違いと比べるとちょっと異質で、
平仮名・片仮名・漢字の使い分けとかに近いものがある気がする。

273 ：Name_Not_Found：04/09/10 20:45:26 ID:???

>>272
憶測でものを言わないで欲しいな。

274 ：Name_Not_Found：04/09/11 01:42:35 ID:???

>>268
HTML4.01の仕様書に書かれているのは、

・<META http-equiv="Content-Style-Type"> または HTTPレスポンスヘッダの
　Content-Style-Type: 行で、デフォルト・スタイル言語を指定できる。
・著者はデフォルト・スタイル言語を指定することが望ましい。
・デフォルト・スタイル言語を指定せずにstyle属性を使うのは間違いである。

ということです。ということは、link要素だけでスタイルシートを使う場合、
デフォルト・スタイル言語の指定は必須ではないが、書いた方が望ましい
ということになります。不要ではありません。ないよりあった方がいいのです。
スクリプトに関しても同様。

>>271
必須ではないですが、HTTPレスポンスヘッダで指定するのが望ましいと
なるのではないでしょうか。

275 ：Name_Not_Found：04/09/11 01:55:10 ID:???

>>274
XHTML1.1でチェックした場合、
lintでこんなこと言われますた
5: line n: XHTML1.1 では <meta http-equiv> を記述すべきではありません。 → 解説 144

文書型宣言をXHTML1.0 Strictにした場合は何も言われません。

「解説 144」の内容
> メディアタイプ application/xhtml+xml には <meta http-equiv> を記述すべきではありません。 *4*
> XHTML Media Types(J) によると、メディアタイプが application/xhtml+xml である文書では <meta http-equiv> を記述すべきではないとされています。

276 ：Name_Not_Found：04/09/11 02:15:27 ID:???

>>275
うむ。MIMEもcharsetもレスポンスヘッダで指定するのが良い……って>>274がもう言ってたな。

277 ：Name_Not_Found：04/09/11 02:16:19 ID:???

>>275
ん？　だからこそ、HTTPレスポンスヘッダで指定するのでしょ？

<meta http-equiv> と HTTPレスポンスヘッダの違い、分かってますか？

278 ：Name_Not_Found：04/09/11 02:18:01 ID:???

text/htmlならキニスンナ

279 ：Name_Not_Found：04/09/11 03:14:34 ID:???

流れぶった切りスマソ。

<div>直下にテキストとかのインライン要素おいてもＯＫですか？
lintでチェックしたらとりあえずエラーにはなってないみたいですが。

もしそれでいいなら、例えば
<p class="copyright">copyright (C)　漏れ 2004</p>
みたいに、段落とはちょっと違いそうな文書はむしろ
<div class="copyright">copyright (C)　漏れ 2004</div>
のようにしたの方が適切そうな気が汁。

280 ：Name_Not_Found：04/09/11 04:50:32 ID:???

>>279
仕様書よめよ。
んで、pの意味するparagraphってのは日本語の「段落」ってのとはちがうぞ。既出だ。過去ログ読め

281 ：Name_Not_Found：04/09/11 05:13:57 ID:???

>>279
著作権表示にメールアドレスなども含めて address要素でという手もあるかも。
<address>copyright © 2004 漏れ ([email protected])</address>

282 ：Name_Not_Found：04/09/11 06:13:56 ID:???

仕様についての疑問
１．なんでimg要素はインラインなのかね。
２．なんで<form>直下にinputをおいてはいけないのかね。
３．なんで
　　　<table><form><tr></tr></form>><form><tr></tr></form></table>
　　みたいにレコードごとに別のformにできないのかね。

何のためにこういう仕様なのかおまいら説明できる？

283 ：Name_Not_Found：04/09/11 06:29:09 ID:???

空腹時

284 ：Name_Not_Found：04/09/11 10:12:02 ID:???

それより<pre>に<img>を書けないのが痛い

285 ：Name_Not_Found：04/09/11 12:41:45 ID:???

>>282
一番目のみ。imgはalt属性のテキストと同等とみなすことができる。故にインライン。

286 ：Name_Not_Found：04/09/11 12:58:16 ID:???

>>285
ならば、代替内容にブロック構造を持てる object 要素が
%inline; である理由を説明されたし。

287 ：Name_Not_Found：04/09/11 13:04:28 ID:???

objectはインラインも内包できるからやや特殊。

288 ：Name_Not_Found：04/09/11 13:43:29 ID:???

>>285
そもそもstrictとしては、画像はテキストで代替できない時に使うんであって、alt属性の存在自体おかしいんだよ。
テキストで代替できるならテキストで書けと。

代替可能な画像と不可能な画像用の要素を作ったほうがよほど論理的だ。
企画書などの図やグラフなどはテキストでは代替できないし、色などのイメージは
まったく代替できない。

ほんとw3cはバカだよな。

289 ：Name_Not_Found：04/09/11 13:46:18 ID:???

>>288
img要素がどういう経緯で取り入れられたかくらい勉強しておいた方がいいよ。
少なくともW3Cをバカにして釣りをしたいならね。

290 ：Name_Not_Found：04/09/11 13:55:37 ID:???

>>289
経緯なんて何の関係もないんだけど？
結果論理的にできない仕様にしておいて、論理的に書けと言ってるやつはバカ以外の何者でもない。
w3cを擁護したいんだろうけど、有名人は100点を求められるんだよ。

291 ：Name_Not_Found：04/09/11 13:58:59 ID:???

どうでもいいけどinline要素の<img>がなんで<pre>の中に書いちゃダメなの!?

292 ：Name_Not_Found：04/09/11 14:00:40 ID:???

>>291
w3cがバカだから。

293 ：Name_Not_Found：04/09/11 14:02:00 ID:???

>>290
めっちゃ関係あるじゃん。国際標準規格として制定しているんだから。

>>291
preが整形済み「テキスト」だからでしょ。

294 ：Name_Not_Found：04/09/11 14:02:43 ID:???

経緯があってこその結果

295 ：Name_Not_Found：04/09/11 14:03:42 ID:???

imgができたのってW3Cができるずーっと前だし

296 ：Name_Not_Found：04/09/11 14:05:07 ID:???

本当はimg廃止してobjectに一本化したかったんだろうけどね。

297 ：Name_Not_Found：04/09/11 14:14:13 ID:???

>>293
>preが整形済み「テキスト」だからでしょ。
altってもんがあるからテキストとみなすこともできるけどそこらへんは？

>>294-296
HTMLは論理的にマークアップする言語だと位置づけたのはw3cで、位置づけたはいいけど
論理的でない規格にしてしまっておいて、
「論理的にマークアップしてくれよ～～～～～～～～」
なんて叫ぶのはバカ丸出しだと思わないか？

違う言語でも作ればよかったのにな。相手にされないのは確実だけど。
まあ80点ってところだよな。だからおまいらw3c信者も20点分の批判は我慢しろよ。

298 ：Name_Not_Found：04/09/11 14:15:55 ID:???

>>297
だから経緯を勉強して来いよ。

あるいは
W3C信者に怒られそうなことを書くスレ
http://pc5.2ch.net/test/read.cgi/hp/1071673655/
こっちに投下するか。

299 ：Name_Not_Found：04/09/11 14:23:12 ID:???

>>298
経緯を知ってほしいなら自分で説明したら？まあ経緯がどうであれ結果が
100点にならなきゃ文句がでるのは当然。経緯で点数が変わると思ってるおまいは
とりあえず社会に出てからおいで。

300 ：Name_Not_Found：04/09/11 14:28:37 ID:???

>>299
社会に出てないのはおまえだな。
それまでの経緯を受けて規格が制定されるのは社会では当然のことだから。

301 ：Name_Not_Found：04/09/11 14:29:33 ID:???

何だ、経緯を知らないふりをした釣りだと思ったら本当に知らなかっただけなのか。

302 ：Name_Not_Found：04/09/11 14:46:01 ID:???

>>300
おまい...論点すらわかってないのか

303 ：Name_Not_Found：04/09/11 15:02:50 ID:???

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

はやく消えてくれ。

304 ：Name_Not_Found：04/09/11 15:22:20 ID:???

経緯を知れば納得できるんだったら、教えてあげたら？

305 ：Name_Not_Found：04/09/11 15:50:44 ID:???

>>303
ほっとけよ。どうせ過疎スレだ。ほっとけばそのうちいなくなる。

306 ：Name_Not_Found：04/09/11 16:46:07 ID:???

>>290
そんなあなたのために、logdesc属性があるじゃない。

そもそも、代替不可能な画像をわざわざマークアップ文書内で表示させようとするほうがおかしい。
それなら最初からそのイメージにリンクで参照する形をとるべき。

307 ：Name_Not_Found：04/09/11 18:39:21 ID:???

ドキュメントをマークアップするためのhtmlであって、
htmlにあわせてドキュメントを作るのは本末転倒。

308 ：Name_Not_Found：04/09/11 18:58:18 ID:???

規格がどのように成り立つか、を論じるスレじゃないだろ。
現状不満があるやつに対して「社会がそういう仕組みだから」は答えになってない。

309 ：Name_Not_Found：04/09/11 20:16:56 ID:???

>>307
論理的文章を作るのが(x)htmlであって、(x)htmlにあわせて作らないのならばその文章は作ったやつの脳内レタリングでしか再現できない。

310 ：Name_Not_Found：04/09/11 20:25:31 ID:???

>レタリング
って・・・。

かなり前にも「レタリングvsレンダリング」バトルがあったな。

311 ：Name_Not_Found：04/09/11 20:29:42 ID:???

やっぱ>>255みたいに別れているんだね

312 ：論理空間構築派：04/09/11 20:45:32 ID:???

というわけで名前欄にどちらの所属か書いて発言してね。

313 ：違法建築擁護派：04/09/11 21:05:47 ID:???

「所属」・・って、どういうのがあるの？

314 ：Name_Not_Found：04/09/11 21:07:50 ID:???

>>313
>>255

315 ：Name_Not_Found：04/09/11 21:40:36 ID:???

>>310
interfaceをインタフェースと書くかインターフェイスと書くかと同じ。
くだらない事でいちいち騒ぎたてるな。バカバカしい

316 ：Name_Not_Found：04/09/11 21:44:46 ID:???

>>315
細かいことだとは思うがそれは違うだろ。
「レタリング」という言葉が別にあるからな、この場合。

317 ：Name_Not_Found：04/09/11 21:50:59 ID:???

インターフェイスとインタフェイス・・・
インタフェイスってほとんど聞かない
それよりフォルダとフォルダーのほうがいいんじゃない？
つまり、カタカナ英語にしたときの表記の違いってことを言いたいんでしょ

でも、レタリングとレンダリングは元の言葉が違わない？

318 ：ぼすけて君：04/09/11 21:54:31 ID:???

IT用語辞典 e-Words
ttp://e-words.jp/p/i-kre.html

@nifty:デジタル用語辞典
ttp://www.nifty.com/webapp/digitalword/index/kana_ra_3.htm

レタリングが見つかりません！どういう意味ですか！教えてください！

319 ：Name_Not_Found：04/09/11 22:02:38 ID:???

>>318
レタリングでぐぐってみれ。やまほど引っかかる。

320 ：Name_Not_Found：04/09/11 22:02:50 ID:???

>>309は手書きの話をしてるんじゃね？

321 ：Name_Not_Found：04/09/11 22:07:32 ID:???

>>317
同じこと繰り返さなくていいよ。
だいたい「フェース」と「フェイス」の差について述べたかったんでしょ。

309=315はレタリング＝レンダリングだと思ってたってことでFAかな。
勉強になってよかったね。

322 ：Name_Not_Found：04/09/11 22:09:42 ID:???

等号だと思ってたんじゃなくて単に覚え間違いじゃないの。
Transitionalのアレみたいに。

323 ：Name_Not_Found：04/09/11 22:23:31 ID:???

<DL><DT><DD>って各ページの紹介に使ってもいいの？

<DL>
<DT><A HREF="bbs.cgi">掲示板</A></DT>
<DD>管理人からすごい早さで返事が来ます</DD>
<DT><A HREF="mail.html">メールフォーム</A></DT>
<DD>管理人からとてつもない長文で返事が届きます</DD>
</DL>

324 ：Name_Not_Found：04/09/11 22:33:25 ID:???

>>323
ここはものすごく頭の悪い発言してくださいスレなので質問はスレ違い

325 ：Name_Not_Found：04/09/11 22:36:30 ID:???

>>323
いいんじゃないの？

326 ：Name_Not_Found：04/09/12 01:13:15 ID:???

>>306
>そもそも、代替不可能な画像をわざわざマークアップ文書内で表示させようとするほうがおかしい。
じゃあHTMLでwebサイトを構築すること自体まぬけな行為ってこと？
でもW3CはHTMLをwebの標準にしていくつもりではないの？
PDFがweb標準なのかな？W3CってPDFを薦めるような運動してたっけ？

327 ：Name_Not_Found：04/09/12 01:16:26 ID:???

>>323
とりあえず「定義」の意味を勉強してみたらすっきりするかもよ？
dlは定義リストだからね。

328 ：Name_Not_Found：04/09/12 01:20:10 ID:???

>>326
俺としてはテキストだけしか表示させようとするべきでないというなら
.txt形式であげればいいと思うよ。>>306が何を思って
＞>そもそも、代替不可能な画像をわざわざマークアップ文書内で表示させようとするほうがおかしい。
なんて言ったのかにもよるけどね。まあ「表示」って言ってる時点でHTMLらしくないんだよね。
txtと違っていろんなUAに構造を解釈させることができるのが魅力の言語だから。

329 ：Name_Not_Found：04/09/12 02:26:54 ID:???

>>322
transitionalをトランショナルと発音しているやつがいた

330 ：Name_Not_Found：04/09/12 02:35:55 ID:???

最近真性のバカが増えたな。仕様書も読めないやつはここで発言するなよ。

331 ：Name_Not_Found：04/09/12 11:19:09 ID:???

306が言いたかったのは
「それなら最初からそのイメージにリンクで参照する形をとるべき。」
ということだろ。
imgが導入されたときにもそういう反対意見があって今でも根強いimg反対派がけっこういる。

これは表示うんぬんの話ではなくて、「言語化できるもののみが機械読み取り可能」という思想(それが真か偽かは別として)の問題。
リンクはリンクでしかないがimgは文章に埋め込んでその一部となるから機械読み取り可能な文章という思想とは合わないという主張。

332 ：Name_Not_Found：04/09/12 11:58:29 ID:???

代替不可能な画像は全部スタイルで指定するようにしてしまえばいい
:after{content:url("*.png");display:block;float:left;}

333 ：306：04/09/12 12:16:25 ID:???

>>328
「表示」という言い方は失敗だった。
>>331の言う通りで、UAによる機械的解釈行為、と考えてくれるとうれしい。

HTML内に文字代替不可能なイメージが存在したりしたら、その時点で、
代替不可部分だけが意味不明な、前後のつながらない文書になってしまう。
だから代替不可能なイメージはマークアップ文書内に含めるべきではないし、
必要であれば外部のデータをリンクによって参照する方法を取るべきだと思う。

代替不可能なデータを表す方法としてPDFを参照することは妥当だと思う。
少なくとも、無理にHTMLで全てを表現しようとするよりはずっといい。

334 ：Name_Not_Found：04/09/12 12:29:42 ID:???

>>332
釣りですか？
スタイル自体が代替可能なんだが。

335 ：Name_Not_Found：04/09/12 12:36:41 ID:???

むしろ334のほうが釣りですね

336 ：Name_Not_Found：04/09/12 12:49:38 ID:???

>>333
>HTML内に文字代替不可能なイメージが存在したりしたら、その時点で、
>代替不可部分だけが意味不明な、前後のつながらない文書になってしまう。
なってもいいのよHTMLは。そんなものじゃないからさ。
機械に論理構造を伝えはするけど内容まで伝える必要はない。

だから代替不可能な画像を使うことはHTMLとして間違った行為ではない。
いろんなUAに対応できるのがHTMLだけど、いろんなUAに常に対応していないといけないわけではない。
なるべく広いほうがいいが、だからといってそれにがんじがらめでは本末転倒。
もう少し柔軟に考えるべし。

視覚UA向けに特化させるのもいいし、全体にくまなく使えるHTMLに仕上げてもいいし、
PDFと違いこの幅の広さがweb標準となれたhogeだな。

337 ：Name_Not_Found：04/09/12 12:56:23 ID:???

>>333
機械的解釈行為、には賛同しますが、
文脈云々いうのならば文脈を解釈するための言語定義がいるのではないかと。
しかもlang属性で示される言語種全てに対しての。

あくまで文脈を解釈できるのは、そのコードを読む人間であって、
html をパースする機械ではないでしょ？例えば

<p>日本国民は…（憲法前文第一段落）</p>
<p><img src="ひろゆきの画像" alt="ウソをウソと見抜けない人に…"></p>
<p>そもそも国政は…（憲法前文第二段落）</p>

というのがあった場合、文脈的にはおかしいけど構造に不備はない。
文脈はおかしいけど、もしそれを不正とするならば html が日本語文章に
ついて定義しなければならなくなっちゃうでしょ。

なので、論理構造が保たれるべきなのはあくまで構造であって、
文脈が論理的である必要はないと思います。

338 ：337：04/09/12 12:57:11 ID:???

だから書き込み前にリロードしろとあれほど…

339 ：Name_Not_Found：04/09/12 14:13:11 ID:???

>>338
前から気になってたのだが
＞だから書き込み前にリロードしろとあれほど…
これって本気で落ち込んでるの？それともただの２ちゃんのお約束なの？
本気でPCの前で軽くうなだれてるならなんか可愛いよね＾＾愛しいぞ！おまい！

340 ：Name_Not_Found：04/09/12 14:16:55 ID:???

>>337-338
つまりおまいはその程度の文章を書くのに7分以上使ったわけだｗ
7分も使って>>336の
>機械に論理構造を伝えはするけど内容まで伝える必要はない。
の一言に撃沈かｗ

>なので、論理構造が保たれるべきなのはあくまで構造であって、
>文脈が論理的である必要はないと思います。
この結論だけ書けば1分で終ってたんじゃないか？どうせ結論は出ててうまく説明するために
ちょっと時間がかかっちゃったんだろ？

341 ：340：04/09/12 14:17:27 ID:???

だから書き込み前にリロードしろとあれほど…orz

342 ：Name_Not_Found：04/09/12 14:21:31 ID:???

343 ：Name_Not_Found：04/09/12 14:26:24 ID:???

上げんなバカ

344 ：338：04/09/12 15:08:49 ID:???

>>341
ハネムーンはモルディブがいいわｗ

>>341
いや、正確には2chブラウザで30位レスついているのに気がついて、
それを読んでからだから、もちっと短いはず。
まー、どうでもいいことなんですが。

345 ：338：04/09/12 15:09:17 ID:???

>>339
結構本気で。

346 ：Name_Not_Found：04/09/12 20:27:24 ID:???

文章ありきだから文章になっていないHTMLはだめなのでは。

347 ：Name_Not_Found：04/09/12 21:35:19 ID:???

>>346
文章ありきとは限らない。

348 ：306：04/09/12 23:05:54 ID:???

>>336
img要素におけるalt属性はあくまでも代替で、"完全に"元と同内容であるとは限らない。
むしろ、絵で表現された感覚的なものまで文字で表せ、などという方が非現実的。
これは個人的な解釈が入るけれども、longdesc属性の存在を考えれば、
たとえば冗長抑止のための省略であるとか、あるいは視覚的に依存することが"より"有効な場合に、
alt属性が事実上必須なimg要素の価値を見出せると思う。

そもそも「UAに対応させる」という感覚そのものが誤り。
HTMLは汎用的で、別にどのUAに対応させるかどうかなど考える必要のないもの。
もしもそんなことを考えながらHTMLを書いているのであれば、全くの無駄。
それはスタイルシートだとか、そういった部分でUAへの対応を考えればいいだけ。
柔軟にものを考えるのはいいけれども、弾力的の名の下に運用されたHTMLは最終的に、
特定のUAでしか使えない、汎用性を失ったものになってしまう。
UAへの対応など、HTMLの時点で考える必要などない。

>>337
自分の書き方が悪かっただけだと思うが、その意見に全く同感。
元々のテキストの文脈が良くても悪くてもどうでもいい。
ただ、自分が駄目だといいたいのは、

<p>本案件に関する詳細は次のようになります。</p>
<p><img src="./report.png" alt="案件内容" /></p>
<p>上記の各要項に関しまして…</p>

みたいなものだけで、別に内容の是非など問う必要は自分もないと思う。

349 ：Name_Not_Found：04/09/13 06:03:08 ID:???

>>348
>UAへの対応など、HTMLの時点で考える必要などない。
現実を見ろよ・・・・・くだらないヲタ発言を長々とまぁ・・・ったく

現実は「UAへの対応はHTMLの時点で考えなきゃ現状どうしようもない」だよ。
HTMLをリアルの仕事で利用しないやつのいうことはホントに役にたたんな。

350 ：Name_Not_Found：04/09/13 06:07:25 ID:???

>>349
まぁ分かるが、現状とか言う奴はもう一個のスレ行け。

351 ：Name_Not_Found：04/09/13 08:19:57 ID:???

>>349
言いたいことは分かるが、残念ながらスレ違いだ。

352 ：Name_Not_Found：04/09/13 08:25:58 ID:???

>HTMLをリアルの仕事で利用しないやつのいうことはホントに役にたたんな。

その理論でいくとほとんどの評論家はカスだということになるな

353 ：Name_Not_Found：04/09/13 08:31:26 ID:???

スレ違いがスレ違いを助長する。

354 ：Name_Not_Found：04/09/13 08:53:54 ID:???

>>352
おまいにとってカス＝いうことが役に立たないなのか？
評論家の言うことは役に立たない。なら普通によく聞くな。とりあえず日本語の脳内解釈は
やめておけ。

おまいらの聞きたいんだが、HTMLに特定UAへに向けての何かを書いてはいけないっていうのなら
<img>自体特定UAなんだがそこらへんは？
ついでにimgにはwidth height属性があり、しかも使用を推奨されている。そこらへんは？

355 ：Name_Not_Found：04/09/13 09:00:58 ID:???

img自体については懐疑派なので肯定はしないが、
img要素が視覚UA向けの要素である、と前提としているお前の発言に、
width height属性が視覚UA向けの仕様なのはどうよ、って発言が含まれてるのは滑稽。
視覚UA向けの要素に視覚UA向けの属性が含まれてることがそんなに不思議？

356 ：Name_Not_Found：04/09/13 09:10:17 ID:???

imgって確かXHTML 2.0では除外されたんだよね。

357 ：Name_Not_Found：04/09/13 10:06:42 ID:Ejjj77LL

もの凄く助けてほしい・・・・
<table>
<tr><th>商品名</th><th>価格</th><th>数量</th><th>購入</th></tr>
<tr><td>チューイングガム</td>
　　<td>100円</td>
　　<td><input type="text" name="商品番号"></td>
　　<td><input type="submit" value="購入"></td>
</tr>
........
</table>

１レコードごとに別々の<form>要素にしたいんだけどどうやらvalidですらないようでorz
でも明らかに表だから<table>要素でマークアップするしかない・・・・
でもtable要素でやるとレコードごとに違うform要素にはできない。

strictにこの状況を抜け出すにはどうすればいいの.......

358 ：Name_Not_Found：04/09/13 10:16:31 ID:???

そもそもそれtable要素か？
<th>購入</th>のあたりとか、input要素含んだtd要素とか限りなく怪しいが。

359 ：357：04/09/13 10:19:21 ID:???

>>358
え？表の中にinput要素は禁止なの？じゃあ上の場合は何でやるのが理想になるの？
定義リストだともの凄く冗長になっちゃうんだけど・・・・；もちろんCSSでdtをけすけど
一番上のdlのdt以外は消す時点で、明らかに表なんだと思うけど・・・・

360 ：Name_Not_Found：04/09/13 10:21:36 ID:???

<form>
<table>
...
</table>
</form>
じゃだめなん?

361 ：357：04/09/13 10:27:24 ID:???

>>360
getだから必要のない値まで渡すと場合によっては切り落とされておかしなことになるかもしれない。
postではブラウザの戻る・進むがスムーズにできなくなるのでorz

362 ：357：04/09/13 10:32:24 ID:???

そもそもtrごとに別のform要素であるみたいに区切るのがstrictじゃないのかな。
でもtrごとに意味的な区切りはあるのだからいいような気もするんだけどな。

363 ：Name_Not_Found：04/09/13 10:37:19 ID:???

>>357
【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

こっち行け。定義リストだと冗長だとかブラウザの実装だとか、
どうもこのスレで話す内容とは離れすぎてる希ガス。

364 ：Name_Not_Found：04/09/13 10:52:02 ID:???

>>354
ちなみにストリクターには結構imgのwidth height要素に懐疑的な
ヤツがいる。
一般的にこの二つの属性が推奨されるのは、ストリクトではなくて、
特定UAでのユーザービリティが理由になっている。

私はimgを参照の一部として考えてるからwidthもheightも
付けないようにしてる。
img要素は「画像そのもののがそこにある」ってだけで、
プレゼン的な意味をもつwidthとheightは
スタイルシートで指定するべきだと思う。

アクセシビリティ（ユーザビリティ）とストリクトは
場合によっては結構かけ離れてるよ。
JISのアクセシビリティの書類なんて
「本文へ」リンクを文章の先頭に置くことを推奨してるけど、
（ナビゲーションを飛ばすためね）
ストリクタとしてはそんなリンクが必要になる時点で
その文章はおかしい可能性が高い、と考える。

365 ：Name_Not_Found：04/09/13 11:07:06 ID:???

>>363
別にタグが冗長といっているわけじゃないんだ。

trはともかくtbodyごとに別のフォームにしたいとかはあるかも。

366 ：357：04/09/13 12:08:08 ID:???

じゃあ質問を変える。
<tr>ごとにform要素にするのは論理的か否か？
仕様上できないのはいいとして、その仕様自体論理的なものなのか。

とりあえずあきらめた。適当に代替方をさがすことにした。

367 ：Name_Not_Found：04/09/13 12:18:23 ID:???

<tr>ごとにform要素にするのは論理的だと思う。
とりあえずXFormsを使うしかないかな。

368 ：Name_Not_Found：04/09/13 12:23:43 ID:???

XFormとSVGに移行するとか。

個人的にはFormは既に用意されている文章ではなくて、
ユーザーがダイナミックに入力する、という点を除けば
普通のHTML文章と大きな違いはないと思う。

よく使う手は
<form>
<dl>
<dt>名前</dt>
<dd><input type="text"/></dd>
......
</form>
みたいな感じ。二次元データの場合はテーブルでも同様。

formはそれ自体をブロックと考えるのでtrによって分割
されるのは変な気がする。

369 ：Name_Not_Found：04/09/13 12:31:34 ID:???

そこでfieldsetですよ。

370 ：Name_Not_Found：04/09/13 12:39:31 ID:???

>>357
整形結果が得たいだけなら、技術的には CSS を用いて
form { display:table-row; }
あたりで解決する問題だと思う。

> その仕様自体論理的なものなのか。
合理的ではないかもしれない。
実際には単なるDTD記述上の限界(つまりSGML仕様の問題)だと思うが。

371 ：Name_Not_Found：04/09/13 13:14:05 ID:???

>>370
それ使えないよ。まあ実装なんて関係ないのがこのスレの趣旨かｗ
でも実装を無視しての会話って意味あるの？例えばXHTML3が出て実装してるUAが
ないのにXHTML3で書きましょう。実装なんて知りませんｗみたいな？

＞formはそれ自体をブロックと考えるのでtrによって分割
＞されるのは変な気がする。
例えばさ何故にformにしたのかね。

input groop=hoge
とかにして、
form groop=hoge ～
～の部分でhogeグループの部品のmethodやらなんやらを決める。なのでformはヘッダに記述。

そもそもform要素自体既存の文書にはない、web特有のものでしょ。だから極力既存の論理構造に
影響を与えない形で実装をすればよかったのにね。ブロック要素ってのが根本的に失敗だったんじゃ？いいすぎか；

372 ：Name_Not_Found：04/09/13 13:36:19 ID:???

>>371
既存の文書ってのは紙媒体のこと？
それなら、署名欄とか穴埋め問題がフォームだと思うが。
ただ紙媒体には送信っていう概念がないけど。

form要素つくったのw3cじゃないし、これからはXFormsに移行してくんだろうし、失敗だってわかってるんじゃない？

373 ：Name_Not_Found：04/09/13 13:47:50 ID:???

>>372
そうかformは申し込みハガキ的なものを想定してるんだな。

374 ：Name_Not_Found：04/09/13 13:50:36 ID:???

>>371
＞それ使えないよ。まあ実装なんて関係ないのがこのスレの趣旨かｗ
＞でも実装を無視しての会話って意味あるの？例えばXHTML3が出て実装してるUAが
＞ないのにXHTML3で書きましょう。実装なんて知りませんｗみたいな？

誰も特定のMLを推奨なんてしてないよ。使うか否かは自分で判断しろよ。
つか一行目で結論出してるやん。

実装の話がしたいなら
【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

375 ：Name_Not_Found：04/09/13 14:10:12 ID:???

>>364
＞アクセシビリティ（ユーザビリティ）とストリクトは
＞場合によっては結構かけ離れてるよ。
＞JISのアクセシビリティの書類なんて
＞「本文へ」リンクを文章の先頭に置くことを推奨してるけど、
＞（ナビゲーションを飛ばすためね）
＞ストリクタとしてはそんなリンクが必要になる時点で
＞その文章はおかしい可能性が高い、と考える。

これはアクセシビリティやらとストリクトが衝突しているのではなくて、ナビゲーションリストがあること自体の問題なのでは。
文書先頭にナビリストがなくてもアクセシビリティは損なわれないが、ユーザビリティが多少損なわれる、と言うのは感じるけどね。

要するに、ストリクト側からアプローチすると一定のアクセシビリティ及びユーザビリティを保てるが、ユーザビリティ側からアプローチすると、ストリクトではなくなる可能性が高いと言うことかな。

376 ：Name_Not_Found：04/09/13 14:16:27 ID:???

> form要素つくったのw3cじゃないし
table 要素も w3c ができる前からあったよね。

377 ：Name_Not_Found：04/09/13 14:21:41 ID:???

>>375
結局衝突しとるがな。

ちょっち話それるが、、UA側に「次のhn要素に飛ぶ」的な機能があれば良いんだよ。
本文の開始直前にはhn要素があるのであって、そうすればUA側でナビを飛ばすことが出来る。
しかし、現在世に蔓延っているHTML文書はそうでない場合が多い。その所為で実装する意味が希薄になっている。
腐れマークアップは本当に腐れだな。

378 ：Name_Not_Found：04/09/13 14:36:44 ID:???

>>377
腐れマークアップも今ではUAのせいだろ。結局つみはUAにいくんだよな。
まあ無料配布だから文句も言えないってかｗ

379 ：Name_Not_Found：04/09/13 14:39:55 ID:???

>>374
＞でも実装を無視しての会話って意味あるの？
これの例えとして続く文章だろ。

380 ：Name_Not_Found：04/09/13 16:18:46 ID:???

>>371
> それ使えないよ。まあ実装なんて関係ないのがこのスレの趣旨かｗ
確かに、整形結果を強制しにくいやり方だから
従来のテーブルレイアウトみたいには使えないだろうね。

現在のHTMLは構造の洗練よりも後方互換性を優先させて発展してきた結果だから
おかしな点は掃いて捨てるほどあるよ。

381 ：Name_Not_Found：04/09/13 20:35:18 ID:???

>>376
だいたい table 要素のデフォルトが border=0 というあたりを見ても、
元々 table はレイアウトのために作られたことを物語っているんだよな。
データの表なら枠線を付ける方をデフォルトにするだろうから。

382 ：Name_Not_Found：04/09/13 20:37:40 ID:???

>>381
船がないのはタイプライターの名残だよ。
Tabキー押して表作るときも線無いしな。

383 ：Name_Not_Found：04/09/13 21:00:06 ID:???

>>381はバカだからほっといてやれよ

384 ：Name_Not_Found：04/09/13 21:04:48 ID:???

>>377
tabindex が汎用要素になればいいのにねぇ。
さらに言えばデフォルトでリンクやフォームアイテムに移動しないようになれば…。

まぁ、無理な話だわな。

385 ：384：04/09/13 21:05:26 ID:???

汎用属性ﾀﾞﾀｰﾖ(；´Д｀)

386 ：Name_Not_Found：04/09/13 23:17:42 ID:???

流れぶった切りながら書き込みしてみる。
自動車学校教習所で習う運転方法がStrict、通常道路上で運転するのがValid、
深夜に妻が産気づいて病院へ（仕方なく）制限速度超過で飛ばすのがInvalid。
今日久しぶりに教習車のケツ眺めてて頭に浮かんだ。

387 ：Name_Not_Found：04/09/13 23:40:22 ID:???

>>386
全然違うぞ。
教習所で教えるのはstrict
実道路では大半がテーブル
深夜にryはtxtあげ

なめるのはinvalid
入れるのはintinpo

388 ：Name_Not_Found：04/09/14 00:02:41 ID:???

>>386
一段階ずつ、遠い方（ Strict から離れた方）にシフトした方が、
より実情に近い希ガス。

389 ：Name_Not_Found：04/09/14 00:34:08 ID:???

「StrictなHTMLで書こう」というのは実情を無視している
（実際の交通を教習車は乱している）と言われているみたいだ…。
Strict-HTMLはそんなことないんだけど、それでもね。

390 ：Name_Not_Found：04/09/14 00:43:38 ID:???

法定速度をきっちり遵守してると自分の後ろの車が詰まってクラクション鳴らしてくれたりします

391 ：Name_Not_Found：04/09/14 00:49:52 ID:???

縦書きの文章をそのまま表示するにはどうすればいいの？
<pre>でむりやり？
それともkagetakaとかUAに頼るの？

392 ：Name_Not_Found：04/09/14 00:54:29 ID:???

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

393 ：Name_Not_Found：04/09/14 01:00:40 ID:???

>>389
全部の車が教習車と同じ走り方をすれば何も問題が起こらないし最も安全。
一般車のほとんどが教習車と違う走り方をするから、
結果的に教習車の方が交通を乱しているかのような状態に見える。

と考えれば、Strict の実情に近くなるかな？
「教習車が交通を乱してる」と言い出す奴と
「Strict は現実に即してない」と言い出す奴が対応する。

394 ：Name_Not_Found：04/09/14 01:02:49 ID:???

車の運転を例にとった一連のレスの中では、>>393が一番うなづける気がする。

395 ：Name_Not_Found：04/09/14 01:11:18 ID:???

でもwebの実情と交通の実情では差がありすぎるな。
まあ交通ルールは何十年も大筋変わらずきてるが、HTMLはずいぶん変わって
しかも実際の現状とはUAのことがほとんどで、運転者ではないから。

いうなれば交通ルールに対応できていない車が蔓延してるといった感じか・・・・
それって怖い話だな；ブレーキを踏むと加速する時もある車・・・・・！？

396 ：Name_Not_Found：04/09/14 05:06:06 ID:???

ネタ投下

397 ：Name_Not_Found：04/09/14 06:01:08 ID:???

>>343

398 ：Name_Not_Found：04/09/14 06:20:55 ID:???

>>397
俺の勝手。バカじゃないのお前？

399 ：Name_Not_Found：04/09/14 06:43:24 ID:???

そうですか
ここはあなたのスレですか

400 ：Name_Not_Found：04/09/14 07:43:19 ID:???

>>399
メール欄に何を書こうがそいつの勝手。お前も好きでsageって書いてるんだろ。
そもそも真剣な話何でageはうざがられるんだ？俺としてはsageの方がうっとおしい。
ageはスレ違いではないが、
「あげるなボケ」
はあきらかにすれ違いだろ。お前の方が悪いと思うんだが？もちろんこのスレ違い話を続けてる
俺も悪いが、原因はほとんどお前だろ。お前がageを肯定すればこんなスレ違いな話は起こらない。
もちろん俺がageなくてもいいが、そもそも相手にage,sage強要すること自体スレ違い。
ここはそういうスレじゃないだろ？

401 ：Name_Not_Found：04/09/14 08:08:47 ID:???

>>399
スルーよろ

402 ：Name_Not_Found：04/09/14 08:11:32 ID:???

>>401
何で自分に言ってんのお前ｗ
まずお前がスルーを覚えろよ。
とりあえず会社に着いたぞ。

403 ：Name_Not_Found：04/09/14 10:10:41 ID:???

strictって、論文とかドキュメントを書くことを目的としてる感じがする。
いわばTeX。
論理的な構造をもった文書を作成することが目的だから､デザインは切り離して
あとで考えればいい。
でもそうじゃない文書もあるんだよね。デザインこそが重要で､論理構造とデザインを
そう簡単に切り離せないものが。
ポスター作るのにはドローソフトを使う。論理構造よりも見た目が重要だから。

strict→tex
そうじゃないもの→ドローソフト

一つのソフトで､TeX文書と各社のさまざまなドローソフト(互換性なし)のファイルが
読める超便利ソフト→各種UA
でもバグだらけ。

404 ：Name_Not_Found：04/09/14 12:14:48 ID:???

>>403
Webが拡大していく前に、そうしたデザイン用途に特化した
HTMLのように無料で容量も小さく手軽でリンクを扱える技術が用意されていれば
恐らく何も問題はなかったんだろうね。

405 ：Name_Not_Found：04/09/14 12:27:57 ID:???

>>403
そこでPDFですよ

406 ：Name_Not_Found：04/09/14 12:51:14 ID:???

将来的には SVG など各種 XML 規格やその周辺規格がそれらの隙間を
埋めてくれると思うが、最大手のWinIEの実装レベルが、何年も前に
勧告されたCSS2ですらバギーなので現状ではまだまだ…と言った感じか。

俺の場合どうしてもレイアウトが大事という場合、とりあえずHTMLで
文書を提供して代理文書としてPDFへのリンクを張ってる。

407 ：Name_Not_Found：04/09/14 13:24:37 ID:???

> 最大手のWinIEの実装レベル
WinIEねぇ…。個人的には高機能化を求めようと思わなくなってきたなあ。
OS添付の簡易HTMLビューアでしょあれ。
エディタで言う「メモ帳」程度の位置付けで考えた方がいい気がする。

408 ：Name_Not_Found：04/09/14 13:26:47 ID:???

高機能じゃなくていいので表示のバグをなくしてください。

409 ：Name_Not_Found：04/09/14 13:28:44 ID:???

>>406
レイアウト・デザイン関係が大事なサイトの最たるはwebｓSHOPだと思うんだけど、
PDFってform要素の代替はあるの？
そもそもPDFがうざがられる以上HTMLで視覚重視サイトも仕上げるしかないんだよね。

＞strictって、論文とかドキュメントを書くことを目的としてる感じがする。
＞いわばTeX。
というかstrictでも昔のHTMLでも目的は変わらないでしょ。それにただ相性がいいだけだと思う。
ある意味万能さが売りなんでしょ。

410 ：Name_Not_Found：04/09/14 13:34:37 ID:???

全然万能じゃないものが、ド素人に「万能さ」でウケてしまった結果がこの惨状。

411 ：Name_Not_Found：04/09/14 13:59:29 ID:???

NNとIEが3.x～4.xの頃の所謂ブラウザ戦争時代は実際独自にHTMLやCSSや
Scriptを拡張して万能さ具合をユーザにアピールしてたからなぁ。

あまりに汚れてしまった text/html から撤退して、新たに application/xhtml+xmlで
やり直したいが、これまたWinIEのお陰でやり直せないのが痛い所。

せめて XHTML1.1 の DTD はバグらずパースしてくれ…。

412 ：Name_Not_Found：04/09/14 14:59:24 ID:???

WinIEが application/xhtml+xml や XHTML1.1 の DTD にまともに対応したとしても
結局は大量の無理解なユーザに踏み汚されるだけだと思うけどな。
# IEがXHTML2対応とかしたらnl要素目当てでXHTML2使う奴が増えるんだろうな。

413 ：Name_Not_Found：04/09/14 15:01:57 ID:???

全く普及しないだけだったりして。

414 ：Name_Not_Found：04/09/14 15:53:22 ID:???

>>412
UAが対応さえしてくれれば俺たちゃ万々歳だろ？
正直デザイン案完成後のコーディングに1ページ1時間以上かけたくない。
UAがW3Cの規格通りに色々な実装をよくしていけば、アホみたいに複数ブラウザで表示確認する必要もなくなるかも。
まあスレ違いなのでこのへんで。

なんか最近話すことないね。やっぱり素人的な見地からの質問からのループ議論以外では
このスレ必要性がなくなってきてるね。

415 ：Name_Not_Found：04/09/14 16:00:11 ID:???

最近というか随分前から寂れてるけど…。

416 ：Name_Not_Found：04/09/14 16:22:00 ID:???

>>414
おまいがこのスレを必要としなくなったってことよ。バイバイ。

417 ：Name_Not_Found：04/09/14 16:29:24 ID:???

<dt>おれ</dt><dd>馬鹿</dd>
<dt>おまえ</dt><dd>間抜け</dd>

を

おれ　　｜馬鹿
おまえ　　｜間抜け

と表示したいんですけどどうすればOK?

418 ：Name_Not_Found：04/09/14 16:30:32 ID:???

>>417すれ違いにつき逝きます

419 ：Name_Not_Found：04/09/14 16:56:57 ID:???

>>417
表示はどうであれ、マークアップはValidだ。
dl要素を忘れないようにしろよ。

420 ：Name_Not_Found：04/09/14 19:03:06 ID:???

>>417
dt,dd{display:inline}
dt:after{content:"　　｜"}

421 ：Name_Not_Found：04/09/14 19:54:32 ID:???

>>420
それじゃあ、
<samp>
おれ　　｜馬鹿おまえ　　｜間抜け
</samp>
にならないか？

422 ：420：04/09/14 20:02:04 ID:???

すれ違いわかっていながらorz
確認してないけど是でいいかな

dt,dd{display:inline}
dt:after{content:"　　｜"}
dd:after{display:block;height:0;margin:0;padding:0;border-width:0;}

423 ：Name_Not_Found：04/09/14 20:27:18 ID:???

お前ら、落ち着いてください。
CSSスレで既に解決している上に、すれ違いもいいとこですよ。

424 ：Name_Not_Found：04/09/14 23:46:28 ID:???

>>423
まー別に話題ないんだし、そうピリピリしなくても良いジャマイカ。

425 ：Name_Not_Found：04/09/15 01:28:33 ID:???

>>423のことではない。

急に思ったが、過疎スレでムキになってる自治厨ってなんだろうな？
何故に２ちゃんの１スレにそこまで固執するんだろうな？
というか自治厨自体なんだろうな？
２ちゃんの１スレが、本来のスレ趣旨から外れたからといって何の問題があるのかね？
２ちゃんの１スレは、そいつの人生にとって大事なものなのかね？

まあ人気スレで自分が参加中に関係ない話されるなら自治もしたくなるだろうけど、
過疎スレなんかは正直何はなしたっていいだろ。そもそも過疎板でこんなにスレを乱立させてどうするんだろうな。
そのほうがよっぽど問題だよ。合計で１０スレほどあればいいってのに、何を血迷ってどんどん立てるんだろうな。

最近このスレから派生した技術関係総合スレが立ったことにしても、明らかに必要ないスレだろ。
自治厨がいなければこのスレでごちゃまぜにしてればよかったんだよ。
過疎板ってことわかってるのかね？

426 ：Name_Not_Found：04/09/15 01:31:09 ID:???

スレを趣旨で明確にわけていくと、結局少数の人間の目にしか触れず、少数の意見にしかならないよな。
２ちゃんなのにローカルってのももったいない。

427 ：Name_Not_Found：04/09/15 01:33:03 ID:???

>>425
IE以外のブラウザなんてみんな使ってないからIE専用でいいじゃんと言っているのと似ている。

428 ：Name_Not_Found：04/09/15 01:37:14 ID:???

>>425
自治房のオナニー文章読むのもだるいけど、無視すると
粘着されそうなのでだれか要約をヨロ。

……10文字以内で。

…………出来れば1byte文字換算で。

429 ：Name_Not_Found：04/09/15 01:50:05 ID:???

スルーしる

430 ：Name_Not_Found：04/09/15 01:52:58 ID:???

>>427
ぜんぜん違う。
>>428
10ｽﾚにしろ

これでokか？マザコンはよくないぞ。これからは自分の力でな。

431 ：Name_Not_Found：04/09/15 02:02:30 ID:???

急に思ったが、植民地でムキになってる独立厨ってなんだろうな？
何故に植民地の１部族にそこまで固執するんだろうな？
というか独立厨自体なんだろうな？
植民地の１部族が、本来の植民地の姿から外れたからといって何の問題があるのかね？
植民地の１部族は、そいつの人生にとって大事なものなのかね？

まあ大所帯部族で自分の家族が宗主国にゴミ扱いされるなら独立もしたくなるだろうけど、
過疎部族なんかは正直どう扱われたっていいだろ。そもそも植民地でそんなに部族を独立させてどうするんだろうな。
そのほうがよっぽど問題だよ。合計で１０国家ほどあればいいってのに、何を血迷ってどんどん独立するんだろうな。

植民地ってことわかってるのかね？

432 ：Name_Not_Found：04/09/15 02:03:08 ID:???

なんだ、コピペか

433 ：Name_Not_Found：04/09/15 02:11:37 ID:???

>>431
お前２ちゃんのスレ問題と人権問題が同じだと思ってるの？
お前にとっての２ちゃんの出来事、２ちゃんの過疎板の過疎スレの動向は
人権問題と同じレベルなのか？

少しは税金払って社会に貢献しろよ。

434 ：Name_Not_Found：04/09/15 02:13:24 ID:???

>>425が>>431の改変バージョン

435 ：Name_Not_Found：04/09/15 02:18:50 ID:???

>>434
ハァ？425書いたの俺なんだけど。

436 ：Name_Not_Found：04/09/15 02:21:31 ID:???

いや、>>425を書いたのは確か俺だ

437 ：Name_Not_Found：04/09/15 02:22:26 ID:???

漏れも書いた気がする。

438 ：Name_Not_Found：04/09/15 02:30:59 ID:???

急に思ったが、過疎スレでムキになってる自治厨ってなんだろうな？
何故に２ちゃんの１スレにそこまで固執するんだろうな？
というか自治厨自体なんだろうな？
２ちゃんの１スレが、本来のスレ趣旨から外れたからといって何の問題があるのかね？
２ちゃんの１スレは、そいつの人生にとって大事なものなのかね？

まあ人気スレで自分が参加中に関係ない話されるなら自治もしたくなるだろうけど、
過疎スレなんかは正直何はなしたっていいだろ。そもそも過疎板でこんなにスレを乱立させてどうするんだろうな。
そのほうがよっぽど問題だよ。合計で１０スレほどあればいいってのに、何を血迷ってどんどん立てるんだろうな。

最近このスレから派生した技術関係総合スレが立ったことにしても、明らかに必要ないスレだろ。
自治厨がいなければこのスレでごちゃまぜにしてればよかったんだよ。
過疎板ってことわかってるのかね？

439 ：Name_Not_Found：04/09/15 04:29:02 ID:???

>>425
改変でしか物事語れないんなら黙っとけ

440 ：Name_Not_Found：04/09/15 04:42:38 ID:???

>>439
勝手に改変だと思い込んでるみたいだけど、
　　　　　　425 ：Name_Not_Found ：04/09/15 01:28:33 ID:???
これ以前の日付で>>425のレスに酷似したレスがあるならもってこいよ。１００万円をやる。
まあ実際貯金は７０万弱しかないから、そのぶんしかやれないが本当にあったらやるよ。

レスをコピって持ってきてもダメな。実際のレスにへのリンクを貼ってくれればok。
それじゃ楽しみにしてる。

441 ：Name_Not_Found：04/09/15 07:21:17 ID:???

何この流れ(；´Д｀)

442 ：Name_Not_Found：04/09/15 07:46:31 ID:???

過疎スレ荒らしに来たよーん、ってことでしょ。

443 ：Name_Not_Found：04/09/15 08:27:09 ID:???

まぁ結果はどうあれ425の思惑通りになったわけだな。おめでとう！

444 ：Name_Not_Found：04/09/15 11:23:57 ID:???

全部425のｼﾞｻｸｼﾞｴﾝでしょ

445 ：Name_Not_Found：04/09/15 11:38:14 ID:???

>>444
よくもまあお前が言えるな

446 ：Name_Not_Found：04/09/15 11:57:55 ID:???

ageに完全一致ね

447 ：Name_Not_Found：04/09/15 12:21:12 ID:???

>>446
ageたら同一人物かｗめでてぇなそれ。

448 ：Name_Not_Found：04/09/15 12:55:25 ID:???

>>447
おうｗめでてえよ

449 ：Name_Not_Found：04/09/15 13:13:11 ID:???

ageに完全一致であぼーんね

450 ：Name_Not_Found：04/09/15 13:16:01 ID:???

>>449
？

451 ：Name_Not_Found：04/09/15 15:30:55 ID:???

スレをまとめろとかは自治スレ行ってやれ

452 ：Name_Not_Found：04/09/16 01:05:15 ID:???

完全な過疎になれば纏まるんだろうが、
定期的に粘着が荒らしに来てくれるので
書き込みもそれなりにあるし、仮想統合相手からは
隔離スレと見なして貰える。

嵐の人々はよっぽどこのスレの存続を望んでいるんだなぁ、
といつも感心する。

453 ：Name_Not_Found：04/09/16 01:20:04 ID:???

>>452
何その妄想

454 ：Name_Not_Found：04/09/16 01:37:04 ID:???

こらこら

455 ：Name_Not_Found：04/09/16 11:15:36 ID:???

久しぶりに思うことがあった。ただいま通販サイト製作中。問題は商品価格の「表示」について。

商品A 1,980円(税込) 数量：□　かごへ

↑こんなのがそこらじゅうにある。もちろん商品価格だから実際相当な量だ。
で、問題は,（カンマ）について。３桁ごとに入れるカンマは明らかに見栄えのもの。
なので入れるなら
<span class="price">1980円</span>
などとして後はCSSの仕事。まあ実際こんなことCSSではできないが、それはスレから外れるのでおいとく。

俺が思うのは
1,980円
これを

次につづけるわ

456 ：Name_Not_Found：04/09/16 11:20:24 ID:???

俺が思うのは
1,980円
これをカンマをHTML側で打っても全然Strictではあると思うんだよね。
strictって見栄えに関する要素を排除したStrcit-DTDを使って見出しなら見出し。のように
目的にあったものを使うことであって、ユーザビリティなどを考慮することではないよね。

1,980円
は明らかに見栄えを意識したものだけど、HTML自体が見栄えを意識してるわけではなく、
マークアップ対象が初めから見栄えを意識したものだったってだけなんだよね。

だから問題ナッシング！

457 ：Name_Not_Found：04/09/16 11:26:15 ID:???

スレ違いだが、4桁区切りの日本ではカンマを4桁ごとに打つべきだと思う。
3桁区切りじゃ中途半端だし、利便性も何も無いただの西洋かぶれだと思うんだ。

458 ：Name_Not_Found：04/09/16 11:29:22 ID:???

わざわざここで発言しないで心の中だけで思ってればいいのに。

459 ：Name_Not_Found：04/09/16 11:32:15 ID:rrRNrClK

1,980は英語圏では十分に意味があると思うが。
三桁ごとに構造が変わるわけだから。

460 ：Name_Not_Found：04/09/16 11:35:12 ID:???

>>459
ちなみにおまいは1,980をどうやってマークアップする？

461 ：Name_Not_Found：04/09/16 11:36:35 ID:???

<span>hogehge</span>

これは非strictですか？最近クラスのない<span>っておかしい気がしてきました。
でも<span>にはclassは必須ではないのでつけなくてもいいし、つける事を推奨されているような
ソースも知りませんし；どうなんでうｓか？

462 ：Name_Not_Found：04/09/16 11:36:50 ID:???

わざわざここで発言しないで世界の中心だけで叫んでいればいいのに。

463 ：Name_Not_Found：04/09/16 11:37:55 ID:???

>>461
何かしら理由をつけて正当化しつつ投稿するのが普通かと。

464 ：Name_Not_Found：04/09/16 11:38:32 ID:???

>>462
中心の位置によるが、ここではないから大丈夫だな。

465 ：Name_Not_Found：04/09/16 11:44:32 ID:???

>>457
見慣れてるひとには見やすい。ちなみに作ってる俺としては見た目がいいから入れてる。
1980円
1,980円

後者の方がしっかりとした印象を与えれ茶っタリス津

466 ：Name_Not_Found：04/09/16 11:47:28 ID:???

Excelみたいに、データ自体はコンマなしで、表示指定できると便利だな。

467 ：Name_Not_Found：04/09/16 11:51:38 ID:???

CSSはexcelよりもしょぼいってことでFA?

468 ：Name_Not_Found：04/09/16 11:54:00 ID:???

手入力する人にとっては、カンマ付きのほうがミスが減るとは思うけどね。

469 ：Name_Not_Found：04/09/16 11:57:34 ID:???

>>468
それは間違いないな。
>>459
おまいは1,980をどうやってマークアップするの？

470 ：Name_Not_Found：04/09/16 12:24:04 ID:???

459じゃないが

HTMLには数値をマークアップする適切な語彙がないから、カンマを付けても付けなくてもどっちでも良かろう
その辺は文書作成者に一任されていると考える。

どうしても分離したいなら、XMLにして、新しく語彙を作るしかないと思われ

471 ：Name_Not_Found：04/09/16 12:37:40 ID:???

俺なら HTML でマークアップするなら
<span class="money">1980</span>
だな。
んで、スタイルシートで1,980に整形。
CSSで無理なら（現状では多分無理だが）XSL や Script と言う手段もある。

カンマの位置や、或いは記号を使用言語で変更したいなら
該当クラスもしくはその親クラスの lang 属性の値をみて対応。
（カンマを小数点、ピリオドを桁取りに使っている国もあるし）

# XSL や DOM の具体的な実装に関してはスレ違いなので言及せず。

472 ：Name_Not_Found：04/09/16 12:45:22 ID:???

>>471
おまいは間違い。そもそもカンマには意味があるから困ってるって話だろ？

<span class="適宜">1</span><span class="適宜">980</span>円

↑これが理想的だな。カンマはcontentでも使えばいいよ。

473 ：Name_Not_Found：04/09/16 12:49:14 ID:???

くまー

474 ：Name_Not_Found：04/09/16 12:52:51 ID:???

ロンムってたら気になった毛で雄。
\
これはどうなるの？
\1980円
っていうのは
<span class="price">1980円</span>
で　\　記号はCSSでやるべき？

475 ：Name_Not_Found：04/09/16 12:53:28 ID:???

>>474
間違えた
\1980
ね。円は不要だった。

476 ：Name_Not_Found：04/09/16 12:59:41 ID:???

CSSってなんでｓｓレクタなんだろ？？？？？？

正規表現をサポして自由に要素、要素内の文字列を指定できればいいのにね。

477 ：Name_Not_Found：04/09/16 13:01:11 ID:???

>>476
アイデア練って提案よろ。

478 ：Name_Not_Found：04/09/16 13:02:07 ID:???

CSS＆HTMLの機能がしょぼすぎるので現状ではいかんともしがたいような気がする

479 ：Name_Not_Found：04/09/16 13:02:24 ID:???

そこでjavascriptでしょ。

480 ：Name_Not_Found：04/09/16 13:06:54 ID:???

>>472
そのマークアップで
1万9800円
を表現したいときはどうするんだ？

481 ：Name_Not_Found：04/09/16 13:23:46 ID:???

>>480
その直後のレスを見落とすな。

482 ：Name_Not_Found：04/09/16 13:25:09 ID:???

くまー？

483 ：Name_Not_Found：04/09/16 13:28:29 ID:???

>>480
<span>19</span><span>800</span>円

あくまでもこれは元々の資料が,付きだった場合にそれをHTML化するときには上気のような
マークアップがもっとも好ましいという話だ。

484 ：Name_Not_Found：04/09/16 13:29:42 ID:???

あほか

485 ：Name_Not_Found：04/09/16 13:32:29 ID:???

もしかして、MathML の範疇？

486 ：Name_Not_Found：04/09/16 13:32:32 ID:???

>>484
非建設的

なんか久しぶりに着たら住人の質が変わった？なんか初心者スレみたいなやつ多いな。
ここはもっと素直に議論する場なんだけどな。

487 ：Name_Not_Found：04/09/16 13:43:34 ID:???

確かに阿呆だな。議論する価値もない。

488 ：Name_Not_Found：04/09/16 13:49:56 ID:???

同じアホでも>>484みたいなレスより偏執的持論を展開するレスのほうが見てておもしろい

489 ：Name_Not_Found：04/09/16 14:01:37 ID:???

>>488
>>484はアホというかこのスレにふさわしくない冷めたやつなんだよ。
ここは「議論しねえ？」ってやつらが集まってある意味ネタみたいな誰かの
持論をそれぞれの自論で論破することに楽しみを覚えるスレだからな。

さようならてこった。484さんよ。

490 ：Name_Not_Found：04/09/16 14:09:15 ID:???

また誰か粘着してる?

491 ：Name_Not_Found：04/09/16 14:09:55 ID:???

>>490
おまえ

492 ：Name_Not_Found：04/09/16 14:29:32 ID:???

俺かよ!

493 ：Name_Not_Found：04/09/16 14:30:09 ID:???

ああ，お前だ

494 ：Name_Not_Found：04/09/16 14:54:23 ID:???

>>493
それはあれか？
「1,980」も「ああ、そうだね」での,も同じくマークアップする必要がないってことか？
1,980としてアクセシビリティが落ちてもstrictは落ちないってことか？

ｙほしじゃぁｋｈｆさ

495 ：Name_Not_Found：04/09/16 15:00:35 ID:???

>>494
アクセシビリティ、は微妙かも。
だって、1980 ってかいても、千九百八十ってかいても
間違いじゃないじゃん？

496 ：Name_Not_Found：04/09/16 15:04:16 ID:???

う
な
重

一
九
八
〇

497 ：Name_Not_Found：04/09/16 15:10:54 ID:???

>>495
,があるかないかでだよ？音声では
1,980
は
「イチテンキュウヒャクハチジュウ」
って読み上げるでしょ？多分；

498 ：Name_Not_Found：04/09/16 15:25:32 ID:???

ドイツやフランスでは、コンマの変わりにピリオドを使うらしい
手もとの国語辞典によると

499 ：Name_Not_Found：04/09/16 15:33:04 ID:???

去年なんか標準をどっちにするかってニュースになってたね。
小数点にカンマを使う国もあると。

500 ：Name_Not_Found：04/09/16 15:46:25 ID:???

>>497
識字のサポートみたいなものだよね、このカンマって。
だから、それをどう発音するかは UA の問題なんじゃないの？

123,456,789

って書いてある場合、
三桁ずつのカンマ区切りととるか、
一億二千三百四十五万六千七百八十九ととるか、
は、読み手の問題なんだし。

501 ：Name_Not_Found：04/09/16 15:50:40 ID:???

>>500
だからアクセシビリティを考えれば変なカンマを入れるべきでない。もちろんコノスレとは無縁だけどね。

502 ：Name_Not_Found：04/09/16 15:58:45 ID:???

ユーザビリティとアクセシビリティはバーターってこと？

503 ：Name_Not_Found：04/09/16 16:03:03 ID:???

そもそもコンマは必要不可欠なのか?

504 ：Name_Not_Found：04/09/16 16:15:53 ID:???

今までユーザビリティってアクセシビリティのちょっとゆるい版かと思ってたけど
なんか背反するの

505 ：Name_Not_Found：04/09/16 16:56:35 ID:???

>>504
とりあえず言葉の意味を調べてこいよ。

506 ：Name_Not_Found：04/09/16 17:30:11 ID:???

ゆーざびりてぃ・・・健常者の使い勝手
あくせさびりてぃ・・・障害者も含め万人の使い勝手
だと思てた

んで、コンマをつけると一般人には見やすくて使い勝手がいいけど
音声ブラウザなどを使っている視覚障害者などにはうまく音声化されず使い勝手が悪くなると思た

507 ：Name_Not_Found：04/09/16 17:31:29 ID:???

>>503
あると便利、な場合がある、くらいか。

9638527410 byte

だとピンと来なくても、

9,638,527,410 byte

だと、9.5GB くらい、ってすぐわかったりとか。

508 ：Name_Not_Found：04/09/16 17:43:13 ID:???

「アクセシブル」から「アクセサビリティ」はどうも違和感がある。

509 ：Name_Not_Found：04/09/16 17:57:34 ID:???

まあ ə だからね。

510 ：Name_Not_Found：04/09/16 17:59:46 ID:???

数字の表記に関するスタイルシートがあればいいのにね
数字付きリストにあるような、表示方法の指定とか
位取りのカンマをつけるつけないとか

511 ：Name_Not_Found：04/09/16 18:04:04 ID:???

あんまり細かくやるとマークアップが煩雑になるからなぁ

512 ：実は問題だらけだよなきっと。：04/09/16 18:05:30 ID:???

結局日本語が一番いいのさ。

１万１千１百円。
11,100円

前者なら問題なし。でもダサイ；

513 ：Name_Not_Found：04/09/16 18:33:00 ID:???

>>510
独自 XML + XSL or DOM を駆使すれば自動的にパラメータ指定した
フォーマットで HTML 文書を生成するのも不可能では無いかと思われる。

このスレからは離れちゃうので、実装レベルで話を進めるなら
XSL 系のスレや Script 系のスレに話題を移すべきだとは思うが。

514 ：Name_Not_Found：04/09/16 18:35:54 ID:???

>>507
>9.5GB くらい、ってすぐわかったりとか。

9638527410 / 1024^3 = 8.97657816298305988311767578125

だいぶ違うエサー。

515 ：Name_Not_Found：04/09/16 18:49:50 ID:???

>>514
正直すまんかった。

516 ：Name_Not_Found：04/09/16 21:41:49 ID:???

>>512
4桁ごとに漢字にすると読みやすい
96億3852万7410 byte

論文なんかではカンマではなく空白であらわすと聞いた希ガス（あやふや）
9 638 527 410 byte

何にしてもスレ違い？

517 ：Name_Not_Found：04/09/16 21:50:41 ID:???

つーか、制作者側に見やすい表記方法が、
ユーザー側にも見やすい表記方法とは限らない訳なのだから、
XMLか何かでUAに「どういう性質の値か」を伝えたら、
表示に関しては（少なくともHTMLレベルの部分では）制作者側が干渉しない方が
いい気がするので、おれは何も装飾しない付けない、足さない表記が
良いと思う。

そっから先のレイヤー、つまりHTMLレベルのデータ表記ではなく、
UAレンダリングレベルの表示方法の話題ならこのスレの範疇外という事で。

518 ：Name_Not_Found：04/09/16 21:56:24 ID:???

見栄えはCSSでやってくれ。
CSSにxslのnumbar-formatのようなのがあればいいだけの話しだろ?
CSSのスレで議論しれ

519 ：Name_Not_Found：04/09/16 21:59:05 ID:???

っていうかXSLもCSSと同様にStyleSheetsなんだからXSLで十分だよなぁ……。

520 ：Name_Not_Found：04/09/16 21:59:38 ID:???

論文はTeXだけがガチ。

521 ：Name_Not_Found：04/09/16 22:28:07 ID:???

>>519
IEがxsltで変換後にxsl:outputを無視してhtmlにならなければね

522 ：Name_Not_Found：04/09/16 22:40:13 ID:???

>>519
FOにした時点でXHTML特有の意味付けは消える。FOは表現の情報しか持って無い。

例えば、元がblockquoteだろうが、divだろうが、ただのブロックになる。
DOM等でcite属性を取得しようにもFOからは不可能。
つまりmozillaみたいにcite属性等をコンテキストメニューで出すのは不可能。
（不可能でないにしても通常のXSLT処理を超えている。）

もちろん、XSLTでcite属性をブロックの内容にしたり、脚注にまとめたり
とかは自由自在だけど。

523 ：519：04/09/16 22:49:13 ID:???

ええっと、それで何か?

XSLで変換すればいい、とはいったけど、一般的にXSLによる変換は
元ファイルを上書きしないし、元となったXMLを非公開にする理由は全くないし、
StyleSheetとしてUAが表示するときに利用できるように提供すれば
変換後のフォーマットがFOだろうが、SVGだろうが、プレーンなtextでも
関係ないんじゃない？

524 ：Name_Not_Found：04/09/17 00:08:02 ID:???

<h1>題名</h1>　　　　　　（図１）
　　<h2>もくじ</h2>
　　<ul>
　　　　<li>第一章</li>
　　　　<li>第二章</li>
　　</ul>
　　<h2>第一章</h2>
　　<p>なんだってー！！</p>

<h1>題名</h1>　　　　　　（図２）
<ul>
　　<li>第一章</li>
　　<li>第二章</li>
</ul>
　　<h2>第一章</h2>
　　<p>なんだってー！！</p>

525 ：Name_Not_Found：04/09/17 00:09:53 ID:???

不正な文字を発見しました。

526 ：524：04/09/17 00:12:00 ID:???

>>524のような文章構成の場合、もくじの書き方は（図１）とすべきなのでしょうか、それとも（図２）とすべきなのでしょうか。
また第二章に節がある場合も、
<h2>第二章</h2>
<ul>
　　<li>第一節</li>
　　<li>第二節</li>
</ul>
<h3>第一節</h3>
とすべきなのでしょうか、それとも
<h2>第二章</h2>
<h3>サブカテゴリ</h3>
<ul>
　　<li>第一節</li>
　　<li>第二節</li>
</ul>
<h3>第一節</h3>　　　みたいにすべきなのでしょうか。

527 ：524：04/09/17 00:13:55 ID:???

もくじには章立てしないのが一般的なのでしょうか。

このようなちゃんとした文章を書く機会なんてないので、
論理的なHTMLどころか論理的な文章構成すら知らない状態です。

528 ：Name_Not_Found：04/09/17 00:41:48 ID:???

どちらでも良い。

529 ：Name_Not_Found：04/09/17 01:44:24 ID:???

この場合、

題名
├ 第一章
│　├ 第一節
│　├ 第二節
├ 第二章
│　├ 第一節
│　├ 第二節
├ 第三章
│
（以下略…）

題名→章→節の関係があるから、それとは別の要素である
目次は切り離した方がいいんじゃないかな？

（余談）
あと、Strict とは少し離れるかもしれんけど、<hn>は、
これを集めてナビゲーションなんかをつくる UA もあるから
その意味でも分けた方がいいと思う。

530 ：Name_Not_Found：04/09/17 07:48:15 ID:???

>>518
お前は何か勘違いしてるが、今話してるのは1,980をそのままマークアップすることがstrictか否かってこと。
CSSではできないからHTML側でやるしかない。しかしHTML側でやることはstrictなのかってことだな。

数字の途中に入るカンマが論理的な意味を持つならHTML側。持たないならCSS等で。
で、どっち？

531 ：Name_Not_Found：04/09/17 07:51:13 ID:???

>>529
>あと、Strict とは少し離れるかもしれんけど、<hn>は、
>これを集めてナビゲーションなんかをつくる UA もあるから
>その意味でも分けた方がいいと思う。

離れすぎ。というかそれはCSS的な見地からのクラスを推奨するのと変わりない。
このスレではやめておくれやす。

532 ：Name_Not_Found：04/09/17 08:42:06 ID:???

>>530
> CSSではできないからHTML側でやるしかない
そりゃ本末転倒かと。
CSSで出来ない見栄えは諦める。これストリクター。

533 ：Name_Not_Found：04/09/17 08:46:51 ID:???

>>532

>数字の途中に入るカンマが論理的な意味を持つならHTML側。持たないならCSS等で。
>で、どっち？

ついでに言うとここはストリクターになるためのスレじゃなくて、strictについて研究・議論をするスレなのでよしなに。

534 ：Name_Not_Found：04/09/17 09:16:47 ID:???

そら各人のStrictの定義次第だわな。この手の議論が平行線になるのも。

535 ：Name_Not_Found：04/09/17 10:34:39 ID:???

こっち活用すれ。

【W3C】Web標準仕様・技術系総合スレッドその1
http://pc5.2ch.net/test/read.cgi/hp/1093950965/

536 ：Name_Not_Found：04/09/17 11:28:28 ID:???

>>535
別に話の途中でちょっと方向が違ってきたからってスレ移動する必要はないよ。
スレ分けってのは初期状態の話題を明確に分離してるだけ。お前頭堅いよ。
全ての話に首突っ込む必要ないンだから、黙って傍観してればいいんだよ。

537 ：Name_Not_Found：04/09/17 11:47:17 ID:???

>>536
>>536 の最終行

538 ：Name_Not_Found：04/09/17 12:54:17 ID:???

>>537
>>537の最終行

539 ：Name_Not_Found：04/09/17 13:08:32 ID:???

終了

540 ：Name_Not_Found：04/09/17 13:32:00 ID:???

>>539
独り言はチラシの裏にでも

541 ：Name_Not_Found：04/09/17 13:42:18 ID:???

<h1></h1>ってひとつのHTMLに何回も出てきていいの？

542 ：Name_Not_Found：04/09/17 13:47:12 ID:???

ご自由に

543 ：Name_Not_Found：04/09/17 16:21:13 ID:???

544 ：Name_Not_Found：04/09/17 19:46:55 ID:???

だまれハゲ

545 ：Name_Not_Found：04/09/18 01:41:56 ID:???

>>543
You're Valid.
だけど、非Strictだと言っておく。

546 ：Name_Not_Found：04/09/18 02:36:11 ID:???

「他と比べて意味（価値）がある」ことを論理的にマークアップする
要素には事欠かないけど、「他と比べて意味（価値）がない」ことを
マークアップする要素はないんだよな。

例えば、

　<p>ところで、Microsoft は本気で <abbr>IE7</abbr> を出すつもりがあるんだろうか？</p>
　<p>まぁ出したとしても、必殺 <em>独自路線</em> を行くんだろうけどな。</p>
　　　　・
　　　　・
　<p><sage>すれ違いスマソ</sage></p>

（ sage = 「他と比べて意味（価値）がない」論理的にマークアップする要素）
みたいな。

……不可欠ではないけど、あれば便利だと思うんだが。

547 ：Name_Not_Found：04/09/18 04:42:47 ID:???

↓価値のないものをネットに垂れ流すなという極論

548 ：Name_Not_Found：04/09/18 04:43:50 ID:???

>>546
それって文の作り方だけで表現できるんじゃない?

549 ：Name_Not_Found：04/09/18 08:54:12 ID:???

>>546
だから強調ってのは平均からの差なんだよ。だから<strong>でいいんだよ。

550 ：Name_Not_Found：04/09/18 10:13:50 ID:???

>>548
言いたい事は解るが、「文の作り方だけで表現できる」というなら
見出しとかも出来ちゃうからなぁ（プレーンなテキスト文でも、
ちゃんとかけば人間は見出しを見失う事がない）

>>546
HTMLは「UAに対して最低限これだけの文書構造をtagで明示しよう」
と言う規格であって、「全ての文書構造を明示しよう」という規格ではない。

そして「強調」は明示するtagに含まれ、「弱調(？)」はHTMLの規格には
選ばれなかった……それだけの事。

もしどうしてもやりたければ、HTMLの規格では「他の意味を持たないものを
マーク付けするときはdiv/spanを使う」事になっているのでdiv/spanを
使うヨロし。

551 ：Name_Not_Found：04/09/18 10:30:25 ID:???

>>550
>見出しとかも出来ちゃうからなぁ（プレーンなテキスト文でも、
>ちゃんとかけば人間は見出しを見失う事がない）

横槍すまんが、無理だ。txt形式の文書ではUAに構造を伝えれない。つまり音声でも伝えられない。
つまり表示からの推測しかできない。ほんとわかてることをイチチスマンね。

552 ：Name_Not_Found：04/09/18 10:58:16 ID:???

>>551
良く嫁
横槍にすら成ってない。

553 ：Name_Not_Found：04/09/18 11:43:53 ID:???

>>549
いつまで嘘を書きつづけるつもりだ？

554 ：Name_Not_Found：04/09/18 12:03:04 ID:???

>>552
横槍・・・・・・おっと；思いっきり勘違いだったんだな。
>>553
最後まで貫くよ。だって<span>なんか使いたくないしね。
なにせ弱調って結局強調なんだよね。目立つ以上強調になっちゃうのよ。
目立つ＝他とは違う。
他とは違う＝強調。
強調＝em|strong

弱長＝目立つ
以下強調時と同じ。

しかし弱長のCSSが半透明とかだったら・・・・完全に弱長だ！
しかしそんなもの「はみとｍなｊｈ！！！！！！！うｈがｈｌｄｊさｌｇｋｗｄｈｇぁｋ

555 ：Name_Not_Found：04/09/18 12:06:57 ID:???

すまん取り乱した。

しかし論理的に弱調ってそんざいするのかね？例えば論文のどこらへんが弱調にあたるのかな？

556 ：Name_Not_Found：04/09/18 12:11:21 ID:???

>>555
# コメントっぽくするとか
（かっこで囲むとか）
地の文――こんな表記とか――地の文

557 ：Name_Not_Found：04/09/18 12:12:58 ID:???

英文だとコロンより後ろの文が弱調？

558 ：Name_Not_Found：04/09/18 13:03:30 ID:???

>>555
まず、弱調なるものが存在するとして…

emとstrongをそれに使うのはマズイ。何故かというと仕様にそれらは「強調」
と明言されているからだ。明らかに「強」の意味が含まれており、
「地の文と文章の重みが違う部分」という意味合いではない。

従ってemとstrongを弱調を含めた「強調以外の意味で使ってはいけない」

また、>>554 の「目立つ、目立たない」は見栄えに重点が置かれているが、
例えば文章の要約を自動生成するプログラムを想定すれば
「弱調と強調を混同して良いはずがない」事は誰の目にも明らか。

嘘をついている自覚がないなら、嘘を付いている自覚を持て。

559 ：Name_Not_Found：04/09/18 13:48:02 ID:???

何でもかんでもDIV、SPANを使う奴も房だが、
何が何でもDIV、SPANを嫌がり、他の要素を拡大解釈したがる奴も房だな。

560 ：Name_Not_Found：04/09/18 14:07:58 ID:???

そもそも弱調の例を示せないのに、仮定からの結論を事実からの結論と混同してるのが間違い。
まずは強調の意味から再考すべき。

ちなみにコーディングでのコメントアウトは強調とも弱調ともとれる。
というかコメントアウト
<div class="うまい名前">...</div>
とするべきだ。

561 ：Name_Not_Found：04/09/18 14:08:50 ID:???

弱調の例ならたくさん示されているじゃん。

562 ：Name_Not_Found：04/09/18 14:08:57 ID:???

>>559
いいかげんお前もXHTMLに移行しろよ。

563 ：Name_Not_Found：04/09/18 14:11:48 ID:???

メール欄がageの人か…
前スレの最後の方とかこのスレの最初の方で暴れてた人が戻ってきたのかな？

564 ：Name_Not_Found：04/09/18 14:12:44 ID:???

>>561
どこに？

565 ：Name_Not_Found：04/09/18 14:15:19 ID:???

>>563
余計なこと言うな。本人が気付いていなかったみたいなのに潜伏しちゃうだろうが。

566 ：Name_Not_Found：04/09/18 14:21:43 ID:???

消防だらけでやる気をなくした・・・・

567 ：Name_Not_Found：04/09/18 16:41:16 ID:???

>>566
放火は重罪ですよ

568 ：Name_Not_Found：04/09/18 21:07:17 ID:???

スルーを学ばない我々はまさに放火ですな。いや、悟りの境地か？

569 ：Name_Not_Found：04/09/18 22:18:22 ID:???

>>550
違う。以下の言葉を使えばそれなりに表現出来る。

「それはさておき」
「さて」
「閑話休題」
「ちなみに」

570 ：Name_Not_Found：04/09/18 22:22:42 ID:???

それいったら引用も > で表現できちゃうだろうが、
読んで人間が理解できる用にする文章の構造と、
UAが自動処理できるようにするマーク付けは全然違うんだよ。

釣りのつもりかも知れんがそんなエサで俺がクマー
　　　　　　　　　　　＼　　　　　∩＿＿∩
　　　　　　　　　　　　＼　　/　　　　　ヽ
　　　　　　　　　　　　　　＼　|●　　●　 |
　　　　　　　　　　　　　　＼(_● _)　　　ミ￣￣￣ヽ＿＿_,-､　　　　　(´;;⌒　 (´⌒;;
　　　　　　　　　　　　　　　　　.. |∪|　　＿＿＿　　　───⌒ヽ(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　　ヽノ-､＿＿＿＿）───(´⌒(´⌒;;　　　　　ズサ────

571 ：Name_Not_Found：04/09/18 23:16:45 ID:???

>>569

「閑話休題」は横道にそれた話を本筋に戻す接続詞で
「ちなみに」はその逆で本筋から離れた事柄を参考までに言い添える接続詞

あなたが列挙している接続詞を使えば何がそれなりに表現出来るのですか？

572 ：Name_Not_Found：04/09/18 23:44:21 ID:???

> 何がそれなりに表現出来るのですか？
「くまー」が。

573 ：Name_Not_Found：04/09/19 06:27:06 ID:???

>>569
こいつアフォだな。

574 ：Name_Not_Found：04/09/19 14:10:49 ID:???

アフォいうやつがアフォ。
よって>>573はアフォ。

575 ：Name_Not_Found：04/09/19 15:19:56 ID:???

>>574は「アフォ」って３回言ったから３倍アフォ
漏れは２倍

576 ：Name_Not_Found：04/09/19 16:15:09 ID:???

サイトマップって普通はリストで書きますよね。でも、かくページの説明を入れたい場合は定義リストのほうがいいんですか？
定義リストって入れ子にできますか？

・はじめに　：　はじめのページ
　　・はじめに１　：　はじめの１ページめ
　　・はじめに２　：　はじめの。。
・一章　：　。。
　　・
<dl>
　　<dt>はじめに</dt><dd>はじめのページ</dd>
　　<dl>
　　　　<dt>はじめに１</dt><dd>はじめの１ページめ</dd>
　　</dl>
</dl>

577 ：Name_Not_Found：04/09/19 16:37:44 ID:???

>定義リストのほうがいいんですか
サイトマップの書き方によるが、>>576 の場合、定義リストでも問題ないように
思われる。

>定義リストって入れ子にできますか？
dl直下にdlは存在できないが、ddの下には存在可能。従って、
<dl>
　　<dt>はじめに</dt>
　　<dd>はじめのページ
　　　　<dl>
　　　　　　<dt>はじめに１</dt>
　　　　　　<dd>はじめの１ページめ</dd>
　　　　</dd>
　　</dl>
</dl>

こうなる。
もし、CSSで言う所の匿名ブロックを避けたいのなら4行目を
　　<dd><p>はじめのページ</p>
とする。(もちろん段落ではない、と思うならp以外の適切なブロック要素となる)

578 ：577：04/09/19 16:39:07 ID:???

あ、ごめん。7行目と8行目のddとdlの閉じる順番が逆。

579 ：Name_Not_Found：04/09/19 16:44:28 ID:???

>>576
一応いいよ。
ネストするならul | olを親要素としたネストの法がいいかもね。

ただ階層構造なんてやっても君にメリットは全くないどころか、
もしも吹く数人での開発であるならば冗長なコーディングは迷惑だな。
まあこのスレ的には冗長であることなんて関係ないけどね。
一般人の感覚として不要な構造の明示は薦めない。

580 ：Name_Not_Found：04/09/19 16:44:33 ID:???

rssで

581 ：Name_Not_Found：04/09/19 16:46:36 ID:???

>>577
ほんとだ。dl直下だね。

582 ：576：04/09/19 16:58:41 ID:???

>>577-581
サンクスです。

>>577
<dl>直下に<dl>はダメなんですかあ。
なんか難しくなりそうです。。

やっぱり>>579が指摘しているとおり、冗長になりそうなのでやめておこうかな。。

583 ：Name_Not_Found：04/09/19 17:12:20 ID:???

<ul>
　　<li>野菜</li>
　　<li>くだもの
　　　　<ul>
　　　　　　<li>りんご</li>
　　　　　　<li>みかん</li>
　　　　</ul>
　　</li>
</ul>

と

<ul>
　　<li>野菜</li>
　　<li>くだもの</li>
　　<li>
　　　　<ul>
　　　　　　<li>りんご</li>
　　　　　　<li>みかん</li>
　　　　</ul>
　　</li>
</ul>

だと、どちらがいいんですか?

584 ：576：04/09/19 17:14:29 ID:???

>>583
下みたいな表記の仕方もあるんですね。

585 ：Name_Not_Found：04/09/19 17:46:33 ID:???

>>583
上。

この例の場合、上だと
「『野菜』と『くだもの』」があって、「くだもの」の兄弟のulの下に
「『りんご』と『みかん』」が存在するが、

下の例だと
「『野菜』と『くだもの』と『りんごとみかん』」になってしまう。
つまり、りんごとみかんの集合が、野菜やくだものと同じ重みに成ってしまう。

586 ：Name_Not_Found：04/09/19 17:51:27 ID:???

>>579
そもそもマークアップ言語自体が冗長さを許容した規格なんだが。

冗長さがコーディングの的になると言うなら
データテーブルテーブルレイアウトをがっちり決めておいて
カンマ区切りとかで指定した方がマシ。

実際XMLつかってプログラミングを業務でやっているが、
ちゃんとマークアップが出来ている事が最も重要で
マークアップの冗長性は殆ど問題にならない。
(そこまでタイトな開発ならそもそもXMLは使わないか、
起動時に即別な内部形式に加工する)

587 ：Name_Not_Found：04/09/19 18:09:19 ID:???

野菜とか果物に<hn>を使ったほうが良いんでないかい
<ul>の前にも<hn>食べ物</hn>が欲しいと思うが

588 ：Name_Not_Found：04/09/19 18:33:04 ID:???

そもそもstrict HTMLに不備があるのでstrictなデータ/見栄えの分離をしようと思うと
strict HTMLを捨てざるを得ない。

589 ：Name_Not_Found：04/09/19 19:51:22 ID:???

<ul>
　　<li>野菜</li>
　　<li>
　　　　<label>果物</label>
　　　　<ul>
　　　　　　<li>りんご</li>
　　　　　　<li>みかん</li>
　　　　</ul>
　　</li>
</ul>

xhtml2の例

590 ：Name_Not_Found：04/09/19 22:28:20 ID:???

>>586
お前は何でも究極を求めたがるガキか？程度を知れよ。

591 ：Name_Not_Found：04/09/19 22:31:44 ID:???

>>590
その先のレスに究極的な何かは見当たらないが…

592 ：Name_Not_Found：04/09/19 22:34:19 ID:???

>>583-all
そもそもulにヘッダが付いてない時点でなんのリストかがハッキリとここのみんなに理解させることができない。
これは実際のUAについてもいえることだが、とりあえずこのスレのみんなに、それがなんのリストなのかを
明示してくれよ。っていうか少なくとも俺はわかんねえよ；

くだものとりんごが同レベルであってはいけないなんてのは、勝手な仮定に基づいた話だよね。
っていうか何故誰もなんのリストなのかを突っ込まない？自演か？
とりあえずみんな、何の話なのか定かでないまま話を進めるのはやめようよ。

593 ：Name_Not_Found：04/09/19 22:34:35 ID:???

程度を知る＝妥協する、であれば別にStrictにこだわる理由もないと思われるが

594 ：Name_Not_Found：04/09/19 22:37:06 ID:???

>>591

>冗長さがコーディングの的になると言うなら
>データテーブルテーブルレイアウトをがっちり決めておいて
>カンマ区切りとかで指定した方がマシ。

595 ：Name_Not_Found：04/09/19 22:41:47 ID:???

>>593
w3c程度のstrictは必要だが、このスレの妄想的なstrictを現実世界の仕事のコーディングに
持ち出してきたら迷惑だ。

理由は冗長だから。

そもそもstrictは見栄えと構造の分離が元になってるんだろ？見栄えを書くのは非推奨だが
構造明示の適度な省略は非推奨でもなんでもないだろ？そもそも作者が伝える必要ないと言ってるものを
頑固に「Strictだから！！！！！！！」なんていうやつとは仕事ができないよ。

596 ：Name_Not_Found：04/09/19 22:41:56 ID:???

>>594
それのどこが究極的なの？ 591でも586でもないが。

597 ：Name_Not_Found：04/09/19 22:44:05 ID:???

>>595
なんというか、このスレでそういう話をするのがスレ違いなんじゃないかと。

598 ：Name_Not_Found：04/09/19 22:44:48 ID:???

>>596
>冗長さがコーディングの的になると言うなら
>データテーブルテーブルレイアウトをがっちり決めておいて
>カンマ区切りとかで指定した方がマシ。

ここが

599 ：Name_Not_Found：04/09/19 22:46:19 ID:???

>>597
知ってるけど話の流れで説明している。

600 ：Name_Not_Found：04/09/19 22:50:19 ID:???

>>596
「究極」じゃなくて「極端」って言いたいのではないかと。

601 ：Name_Not_Found：04/09/19 22:56:53 ID:???

なんかこの23スレ目はやけに質が落ちたな。
正直ほとんどがスレ違いな話じゃん。

602 ：Name_Not_Found：04/09/19 22:59:44 ID:???

何を今更。

603 ：Name_Not_Found：04/09/19 23:32:17 ID:???

>>601 みたいな書き込みが多いのは確かだな。
まぁ、この5～6スレ既にそうだったと思うが。

604 ：Name_Not_Found：04/09/20 01:13:01 ID:???

>>586は
「HTMLには冗長性がある。究極的な定義は出来ない、やるなら他の形式がいいよ」
っていってるのに>>590は何を誤読してるんだ？

>>592
普通に考えて、果物、野菜、って「ジャンル」と物自体を表す
「リンゴ」「ミカン」は階層が違くないか？
この話だいぶ前にも有ったような気がする。

もちろん、文脈によって変わる可能性はあるけど、
そこまでうがった見方をしなくても良いような。

605 ：Name_Not_Found：04/09/20 01:22:35 ID:???

>>604
句読点の代わりにセミコロンを使う奴はスルーするのがよい予感。

606 ：Name_Not_Found：04/09/20 01:51:19 ID:???

　　 i＜´ 　 }＼　 ,　- 、
　　　ヽ.._＼./　 .ﾝく　r-兮、＿_
　　　 ∠｀ヽ.!　/ 　ヾﾆEｦぐ　,ゝ-＞　　
　　　/＿｀ｼ'Ｋ-───‐-､l∠ イ　　　さすがゴッグだ、
　　　l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤　　　冗長度が高くても
.　　 l'___|⌒ヾ''ｰ＝=､ｰr='ｲ　ｉ二| 　　なんともないぜ　
　　　/　.｣　　 i　　 /./7r‐く　 lー! 　　　　　
.　　ｆ.　　ヽ‐ｉ人.∠'＜　＿i. l,.-ゝ.
　　ﾄiﾍﾍ｢ﾄ〈　　　　｀X　　ﾄﾚi7__|
　　　〉ﾄ:ﾄﾊj｀! i.　　　 /　ﾄｰ┤lﾙj,ﾘ
　　/‐+----+‐l　　 iｰ--i---ヾ'〃
.　ｌ＿i＿＿__i__|　　 |＿__i,＿＿i_|

607 ：Name_Not_Found：04/09/20 02:24:07 ID:???

>>592はセミコロニスト。
語尾に「～セミコロヌ」を多用。
「さすがゴッグだ、冗長度が高くてもなんともないセミコロヌ」

608 ：Name_Not_Found：04/09/20 08:12:28 ID:???

>>604
>普通に考えて、果物、野菜、って「ジャンル」と物自体を表す
>「リンゴ」「ミカン」は階層が違くないか？

だからそれはヘッダを各自で勝手に予想してるんでしょ。
<hn>hoge家の家計図</hn>
っていう予想を立てた場合はおかしなことになるね。
<hn>私のあだ名の移り変わり</hn>
でももちろんみんなとずれる。

とりあえず勝手な妄想で話を進めるのはよそうよ。
仕様書に書いてもいないのに、独自の拡大解釈しちゃうのと同じでしょ。

609 ：Name_Not_Found：04/09/20 09:02:23 ID:???

だいたい傾向が見えてきたな。何を無視すべきか。

610 ：Name_Not_Found：04/09/20 10:15:12 ID:???

>>609
独り言をいちいち書きこむなよ。本当に今回はひどいやつらばっかだな。

611 ：Name_Not_Found：04/09/20 10:24:19 ID:???

>>610
今回<em>も</em>、だろ。

612 ：Name_Not_Found：04/09/20 11:15:14 ID:???

>>608
フレーム問題、っていうのがロボット工学分野（だったと思う）にあってな。
ウィキペディアに詳しく載ってるから読むといいよ。

613 ：Name_Not_Found：04/09/20 12:39:30 ID:???

>>611
前回は中身のあるスレだった。今回は何のぎろんもされてないじゃん。

ところでクリッカブルマップって使ってもいいの？
あれって非strictっぽい感じだよね？

614 ：Name_Not_Found：04/09/20 15:41:02 ID:???

>>612
フレーム問題って人工知能じゃない？

615 ：Name_Not_Found：04/09/20 15:47:37 ID:???

>>613 のレベルだと前スレには「内容があった」らしいことは解った。
けど、仕様を読んでる奴はそれより上のレベルじゃないかねぇ。

616 ：Name_Not_Found：04/09/20 16:15:47 ID:???

>>615
お前仕様書の前に、日本語を勉強しなおせよ。

617 ：Name_Not_Found：04/09/20 17:23:51 ID:???

>>616 はつまり、「内容的には敵いませんでした」と言いたい訳か。

618 ：Name_Not_Found：04/09/20 18:23:01 ID:???

「ムズかしくてよくワカンナイから、もっとカンタンに言って」と言いたいのだろう。

619 ：Name_Not_Found：04/09/20 19:17:39 ID:???

620 ：Name_Not_Found：04/09/20 21:27:06 ID:???

＞>>613 のレベルだと前スレには「内容があった」らしいことは解った。
＞けど、仕様を読んでる奴はそれより上のレベルじゃないかねぇ。

とりあえず消防の国語の教科書からでも読み直せって。お前さすがにやばいって。
煽りとかじゃなく、脳内国語はやめておけ。

621 ：Name_Not_Found：04/09/20 22:32:31 ID:???

613ではないが。

「日本語勉強し直せ」って、要は613読んで意味が解らなかったんだろ？
原因としては話し手の表現力不足と聞き手の読解力不足の両方が考えられるわけで。
自分が正しいと信じるのは結構だが、
616みたいな反応は618みたいな受け取られ方をしても仕方がないと思われ。

622 ：Name_Not_Found：04/09/20 23:06:52 ID:???

関係ないけど、体育の授業でキャッチボールするとき
ボールを落とすのは受ける側が悪いんじゃなくて
投げる側がちゃんと取りやすい球を投げてやらないからだ
って先生が言っていたなあ

623 ：Name_Not_Found：04/09/20 23:19:32 ID:???

ほんと関係ないね。

624 ：Name_Not_Found：04/09/20 23:29:12 ID:???

言葉のデッドボール

625 ：Name_Not_Found：04/09/20 23:34:08 ID:???

615 ：Name_Not_Found ：04/09/20 15:47:37 ID:???
>>613 のレベルだと前スレには「内容があった」らしいことは解った。
けど、仕様を読んでる奴はそれより上のレベルじゃないかねぇ。

626 ：Name_Not_Found：04/09/21 00:52:41 ID:???

ここのスレは目をつぶって球投げる香具師多し

627 ：Name_Not_Found：04/09/21 08:23:25 ID:???

>>626
今スレだけだよ。多分厨が２,３人居座っているのと、前スレ以前の住人は飽きて
いなくなったんだろう。

628 ：Name_Not_Found：04/09/21 13:58:14 ID:cpl0hFml

顔文字とかのアスキーアートにあてるタグって何だっけ？

629 ：Name_Not_Found：04/09/21 14:01:21 ID:???

630 ：Name_Not_Found：04/09/21 14:02:56 ID:???

ありがとう

631 ：Name_Not_Found：04/09/21 15:07:11 ID:???

物凄い独自拡張だな

632 ：Name_Not_Found：04/09/21 15:24:20 ID:???

>>628
顔文字に関しては abbr を使う例を W3C が提示しているが、
必ずしも略語として文脈に登場する訳ではないので、ベターな場合もあるが、
機械的に顔文字を abbr にしちゃうのは微妙。

W3C信者的には AA を SVG にして Object で埋め込むと
かなり良い感じになれるが、ブラウザの実装が全然追いついてない。

また、とりあえず整形済みなのでpreにすると言う手もあるが、
フォント依存（特にプロポーショナルフォントの場合）AAが崩れる
可能性が高く、現実的な選択肢ではない。

一番確実なのはキャプチャして img 要素を使うことだが、それって既にAAじゃない。

633 ：Name_Not_Found：04/09/21 15:46:01 ID:???

いわゆるJIS文字アートだとまた事情が違うからなぁ

634 ：Name_Not_Found：04/09/21 17:03:23 ID:???

>>632
そもそもPDFでやるべきことだろ。顔文字なんてのは。
HTMLで見栄えをがっちり固めようなんてすれば、どこかで無理がでる。
素直にPDFにするか、非stirctでいけよ。

635 ：Name_Not_Found：04/09/21 17:48:29 ID:???

>>632-634
なるほど、これが言葉のデッドボールか。

636 ：Name_Not_Found：04/09/21 20:19:53 ID:???

ここのやつは論理的にマークアップどころか、会話もまともにできないやつってことでFA?

637 ：Name_Not_Found：04/09/21 20:56:20 ID:???

日本語に対応していない。

638 ：Name_Not_Found：04/09/21 22:24:39 ID:???

くそ!!また実装の問題かよ。

639 ：Name_Not_Found：04/09/21 22:26:24 ID:???

PDFで顔文字ですか。すごい時代ですね。

640 ：Name_Not_Found：04/09/22 00:14:24 ID:???

画像ファイルで良くね？

641 ：Name_Not_Found：04/09/22 00:19:06 ID:???

object要素のdataで画像を指定して、中身を <![CDATA[ ]]> でAAテキスト、とか。

642 ：Name_Not_Found：04/09/22 00:27:03 ID:???

フォント依存の場合は、フォントを埋め込むか、画像にする以外無いね。
見栄えの有無とかもあるが、フォントの種類と文字コードだけ渡したのでは
100%の再現性は無理。

643 ：Name_Not_Found：04/09/22 00:45:26 ID:???

AAは<PRE>でいいじゃん。んでフォントにプロポーショナルフォントを指定

それより、掲示板の書き込みなんだけど
みんな好き勝手に書き込むんですよ
掲示板の書き込み部分も<PRE>にしたほうがいいと思う？
でもこれだと途中で折り返されないんだよね

644 ：Name_Not_Found：04/09/22 00:57:23 ID:???

過去に何度か議論されてなかったっけ？

645 ：Name_Not_Found：04/09/22 00:59:07 ID:???

>>643
white-space:normal

646 ：Name_Not_Found：04/09/22 01:33:29 ID:???

strictは『論理的な構造と見栄えが切り離せる』ドキュメントを記述するためのものだ。
つまりそうでないものを記述しようとすると必然的に破綻する。
これは仕様の穴というよりそもそも使い方が間違っている。

AAの場合､文字列そのものだけでなくその配置､フォントも重要なのだから
それらを一緒に文書内に埋め込むしかない。見栄えを切り離した瞬間意味がなくなる。
htmlを拡張して､そういうデザイン的要素も表現できるようになるまでは
非strictで我慢するのが一番合理的だと思うがどうか。

647 ：Name_Not_Found：04/09/22 05:04:03 ID:???

質問

<dt>Monthly Archives</dt>
<dd><ul>
<li><a href="">2004年9月</a></li>
<li><a href="">2004年8月</a></li>
<li><a href="">2004年7月</a></li>
</ul></dd>
</dl>
と書くのと

<hn>Monthly Archives</hn>
<ul>
<li><a href="">2004年9月</a></li>
<li><a href="">2004年8月</a></li>
<li><a href="">2004年7月</a></li>
</ul>
だと、どっちが良いのかな？

648 ：Name_Not_Found：04/09/22 05:14:45 ID:???

<dt>Monthly Archives</dt>
<dd><a href="">2004年9月</a></dd>
<dd><a href="">2004年8月</a></dd>
<dd><a href="">2004年7月</a></dd>
</dl>

なわけない

649 ：Name_Not_Found：04/09/22 08:59:37 ID:???

>>647
前後の文脈とかによる。

上は、何かの見出しのしたにそう言う構造がくる場合、
下は、独立した見出しを持つリストとして、
どちらも十分にあり得る。

650 ：Name_Not_Found：04/09/22 10:38:38 ID:???

DTに対応するDDっていっぱいあってもいいんだ
またひとつ勉強になりました

651 ：Name_Not_Found：04/09/22 10:45:47 ID:???

>650
よく読め、>648の最後を。
＞なわけない

とはいえ、実際DTに対応するDDの個数については、決着はついていないがな。
一応、一つずつで対にするのがベター、というのは総意っぽいが。

652 ：Name_Not_Found：04/09/22 11:26:26 ID:???

(DT | DD)* みたいな感じだよね？
DDが先に来ることさえありうる。

653 ：Name_Not_Found：04/09/22 12:49:16 ID:???

仕様書にも複数dt複数ddの例があるから良いんじゃないの?

654 ：Name_Not_Found：04/09/22 13:54:52 ID:???

っていうかお前らAAはpreだぞ。表示を考えてじゃないぞ。
整形済みテキストだからだ。

なので表示が崩れてもpre以外でやれば非strictだ。くそCSSでがんばるｂし。

655 ：Name_Not_Found：04/09/22 14:17:21 ID:???

>>654

「わーい(^ ^)やったー」

はどうやるの？

656 ：Name_Not_Found：04/09/22 14:28:12 ID:???

文中に紛れ込むAAって結構多いよな:)

657 ：Name_Not_Found：04/09/22 14:40:25 ID:???

AAと顔文字をわけて考えようよ

658 ：Name_Not_Found：04/09/22 14:42:59 ID:???

<p>文中に紛れ込むAAって結構多いよな</p><pre>:)</pre>

659 ：Name_Not_Found：04/09/22 14:44:20 ID:???

660 ：Name_Not_Found：04/09/22 15:58:43 ID:???

>>656
マ儀折れ込みはそのままpでよろしい。
短億のでかいやつんらpreで。

そもそもアスキアートは文ルいすえいて＠だが、そこまでは無ｙ理科もしｒな。
とりあえずpreがstrict。

<p>
くぃうえろえおぇ<pre>^^;</pre>
</p>

これがもっとも論理的。だが、仕様に従ってないからstrictではない。
いわばstrictよりも論理的にマークアップするために<p>にpreを内包させる。

まあ冗談さ。仕様に従わないかぎり、論理的なマークアップにはならない。
p要素を見出しだと勝手に解釈してマークアップするようなものだな。
正直ここまであついとやってらえれいあｓなｓなｓ＠ｓｈｌｄｆ：んｌｋｆんｄｓ

661 ：Name_Not_Found：04/09/22 16:07:52 ID:???

複数行にわたらない顔文字は

<p>「わーい<abbr title="スマイル">(^ ^)</abbr>やったー」</p>

でない？
で、複数行にわたる巨大AAは<PRE>で。

662 ：Name_Not_Found：04/09/22 16:19:36 ID:???

>>660
釣れますか？

663 ：Name_Not_Found：04/09/22 16:20:07 ID:???

ふとおもったが、
特に英語圏のネット上だと、（日本語でもそうだけど）

「I got it!」の「!」
「Are you kiddng? ;-)」
を比べると、「!」と「:)」って結構同じのりで使われてる気がふとした。

でもあくまで「strict」って考えると、
I got it !はそのままで
Are you kiddng? <abbr title="ha ha">;-)</abbr>
でいいのかな？

ちと混乱。

664 ：Name_Not_Found：04/09/22 17:21:10 ID:???

顔文字はしばしば言葉で代替不能なニュアンスを持つので、芳しくないかと。

665 ：Name_Not_Found：04/09/22 17:26:37 ID:???

お前ら・・・・・・何故こんなことで悩む・・・・・

そもそも顔文字って装飾だろ？CSSでやれよ。できなくてもこのスレとは無関係。

<p>あった！！！！！！！</p>
じゃなくて
<p><strong>あった</strong></p>

content:after"!!!!!!";
だろ。（CSSの書き方間違ってたらごめん。こｒつかったことない；）

んで、顔文字ってのはその前の文章もしくは単語に対するなにかしらの追加情報だよな。
それは強調だったり、何やら感情的なものだったり。それらは要素またclassでやるのさ。

<span class="cry">１０万を落としたよ</span>

んで又content使って見栄えのほうはね。ということだ。みんな納得した？

666 ：Name_Not_Found：04/09/22 17:31:52 ID:???

>>665
釣れますか？

667 ：Name_Not_Found：04/09/22 17:33:53 ID:???

>>666
ひきこもりですか？

668 ：Name_Not_Found：04/09/22 17:37:39 ID:???

釣堀じゃないぞ。

669 ：Name_Not_Found：04/09/22 17:40:37 ID:???

XHTML 2.0のdlって、diを使うとdt・ddの順序を束縛されるのに、
直下に置く場合は順不同なのね。後方互換性のため…？

670 ：Name_Not_Found：04/09/22 18:02:55 ID:???

<my:reply to="665"><my:hatena>。、?\はどうするのさ</my:hatena></my:reply>

reply:before{content:">>" attr(to)}

671 ：Name_Not_Found：04/09/22 18:33:58 ID:???

>>670
それは装飾じゃないだろ。そもそも顔文字と記号は違うよ。
!
これは強調とかね。だからstrong系。
?
これは該当要素なし。だからspan系。

顔文字は装飾なので完全にspan系。

AAもコメント以外は完全に装飾なのであしからず。

672 ：Name_Not_Found：04/09/22 18:35:21 ID:???

？を見栄えでしか意味を伝えれないと仮定するなら、
<span class="クエスチョン">とかしないといけないのかね。

673 ：Name_Not_Found：04/09/22 18:39:10 ID:???

顔文字が装飾でレス番前の">"二つが装飾でない意味がよくわからんのだが。
（サーバでアンカー貼るから必要、ってのはわかるが、HTMLとして出力されたら要らんだろ）
スタイルシートが有効でないと感嘆文か疑問文か区別が付かないってのはもう閉口。

674 ：Name_Not_Found：04/09/22 18:52:29 ID:???

<span class="assertion">taken care of, he got conceited</span>

675 ：Name_Not_Found：04/09/22 19:00:04 ID:???

だからAAをstrictでやるんじゃねえ！無理だ！
｢意味｣と｢見栄え｣が完全に分離できるドキュメントじゃなきゃ
strictにこだわるのは本末転倒！無意味！ふざけるな！

676 ：Name_Not_Found：04/09/22 19:03:36 ID:???

何をﾌｧﾋﾞｮｯているのか解説きぼん

677 ：Name_Not_Found：04/09/22 19:07:44 ID:???

AAをpreでやっても非Strict？

678 ：Name_Not_Found：04/09/22 19:16:26 ID:???

>>677
preでやってもずれない保証はないだろ？
AAってのはフォントや文字サイズの情報がなければ単なる意味不明な文字列。
見栄えと意味が切り離せない以上､

<font face="MS P ゴシック" size="10">
なんかAA
</font>

とやるしかないだろう。

679 ：Name_Not_Found：04/09/22 19:21:47 ID:???

>>678
それでもずれない保証はないけどね。

680 ：Name_Not_Found：04/09/22 19:27:46 ID:???

<span class="aa nanka"/>

nanka:before{
content:"何か\n何か\n何か";
font-family:"MS P ゴシック";
font-size:1em;
white-space:pre;
}

あれ、改行って\aだっけか

681 ：Name_Not_Found：04/09/22 19:29:34 ID:???

\nで合ってる。

682 ：680：04/09/22 19:31:05 ID:???

http://msugai.fc2web.com/web/CSS/generate.html

\aっぽいな

683 ：Name_Not_Found：04/09/22 19:43:26 ID:???

ttp://nazodane.hp.infoseek.co.jp/uploader/aa.xhtml

684 ：Name_Not_Found：04/09/22 19:49:00 ID:???

<span class="aa nanka"/> が文書内に存在する理由がないな。

685 ：Name_Not_Found：04/09/22 19:51:41 ID:???

>>684
画像と同じ扱い

686 ：Name_Not_Found：04/09/22 19:56:10 ID:???

>>680
フォントを小さくしたときに行間が悲惨なことになるorz

687 ：Name_Not_Found：04/09/22 20:01:52 ID:???

>>685
objectにして代替テキストが必要だな。

688 ：Name_Not_Found：04/09/22 20:02:48 ID:???

<Q>を使うとMozillaでは勝手に""がつくってことは、
地の文章の引用の前後には「」はつけちゃだめってことなの？

あと、註釈の（１）とかってのは、<SUP>や<SUB>ですか？

689 ：Name_Not_Found：04/09/22 20:05:13 ID:???

>>688
そういうこと (should not)。
なお、XHTML 2.0 のquoteでは、クォート記号は著者がつけることになる。

690 ：Name_Not_Found：04/09/22 20:06:43 ID:???

q{ quotes: '「' '」' }

691 ：680：04/09/22 20:16:31 ID:???

>>686
.nanka{
font-size:*em
}
とすれば大丈夫

692 ：688：04/09/22 20:26:51 ID:???

>>689
さんくすー。
ってことは、紙媒体やプレーンテキスト上では論理的な文章でも、
HTMLにするときにはタグの挿入だけではなく本文そのものも改変しないとだめなんですね。

Mozillaのクォートを消すのって、CSSでできたっけ。。
ちょい調べてきます

693 ：Name_Not_Found：04/09/22 20:29:33 ID:???

q{ quotes: "" "" }
か
q:after{content:""}
q:before{content:""}

694 ：Name_Not_Found：04/09/22 20:39:04 ID:???

>>693
さんくす。

ってか、>>690さんもこのことについて書いてたんですね。サンクスです。
現状では、IEとのかねあいから、クォートをかぎかっこに変えるのではなく、
消して地の文にかぎかっこを書いてしまったほうがよさげですか？

あと、<A>タグの中には他のタグはあまり書かないほうがいいですか？

たとえば
<a><cite>引用元</cite></a>
よりも
<cite><a>引用元</a></cite>
ですか？

695 ：Name_Not_Found：04/09/22 20:41:22 ID:???

>>673
>顔文字が装飾でレス番前の">"二つが装飾でない意味がよくわからんのだが。
>（サーバでアンカー貼るから必要、ってのはわかるが、HTMLとして出力されたら要らんだろ）
>スタイルシートが有効でないと感嘆文か疑問文か区別が付かないってのはもう閉口。

？？？HTMLを勘違いしてないか？
<span class="ここに論理的な名前">これで意味は伝わってるのよ。
見栄えとしてスタイルが効かなければ？が付かないから、視覚UAユーザには理解できないかもしえないが
それは実装が悪いだけで、HTMLとは無関係。

そもそもここはいかに相手に伝えるかスレではなくて、いかに論理的にマークアップできるかスレなのだから
あしからず。

696 ：Name_Not_Found：04/09/22 20:45:10 ID:???

>>678
ずれるとかずれないなんてのはスレ違いだよ。
とりあえず、HTML4.01の仕様では一体何でAAをマークアップすればいいの？

697 ：Name_Not_Found：04/09/22 20:47:31 ID:???

SVGが理想。
CSSでもOK.
だけど埋め込みはしないほうがいいということでは?

698 ：Name_Not_Found：04/09/22 20:49:02 ID:???

AAはHTMLと相容れない、と。

699 ：Name_Not_Found：04/09/22 20:50:58 ID:???

まぁSVGが普及するまでは>>683のようにすればいいと思う。

700 ：678：04/09/22 20:53:20 ID:???

4.01でどうやるのかは知らんが､論理的にはAAは画像として扱うべきだろうね。
objectで埋め込むとか。

701 ：Name_Not_Found：04/09/22 20:55:41 ID:???

>>695
class属性値にどんな論理的な値を書いても意味などありません。
spanはただのspanであって、それ以上の意味など持たない。
人間が推測できるだけの話。その推測が正しいかどうかも書いた本人にしかわからない。
rubyの仕様書によみがなにはclass="reading"とか付けろとか書いてあるが、ちゃんちゃらおかしい。

このスレかどっかで、はるか昔にも議論されてた話。

702 ：Name_Not_Found：04/09/22 21:03:24 ID:???

>>700
4.01でも>>683とやり方は同じ。(ただし、IEが:before/:afterに対応していない)
それと、objectでtxtを埋め込むのはよくないと思う。
AAはフォントの情報が必須だから。

703 ：Name_Not_Found：04/09/22 22:55:05 ID:???

>>696
そもそも、AAとHTMLは相性が悪いと言う前置きをしつつ、
とにかく、べたに書かれているAAを何でマークアップすれば良いのかと聞かれれば、preしかないと思う。
理由は「アスキーアート ⊂ 整形済みテキスト」だから。多分。

704 ：Name_Not_Found：04/09/22 23:33:07 ID:???

>>701
>rubyの仕様書によみがなにはclass="reading"とか付けろとか書いてあるが、ちゃんちゃらおかしい。
それはrubyの仕様なんだから良いんじゃないか?
例えば、個々のウェブマスターがdiv class=sectionと脳内仕様を作るのと同じ程度には。

万が一rubyがhtmlの仕様を上書きしようとしているなら噴飯物だが、アリエナイ

ちなみにその他部分には禿道。というか常識。

705 ：Name_Not_Found：04/09/23 00:02:28 ID:???

>>695
勘違いしてるのはおまいだと思うが。
視覚UAユーザに伝わらないのは実装云々はまだしも、
クラス名を人間が解釈しなきゃいけないHTMLってどうよ？

706 ：Name_Not_Found：04/09/23 00:40:47 ID:???

>>703
どうも納得いかんなあ。
AAの属性ははドキュメントじゃなくて画像に近い。
現行のHTML規格じゃそんなもの考慮されていない。したがってstrictな表現のしようがない。
まあ、現実に何を使うかっていえばやっぱり<pre>だろうけどね。でも本来は邪道な使い方

707 ：Name_Not_Found：04/09/23 01:07:57 ID:???

AAは画像に近いとか、HTMLと相性が悪い(と言うか再現出来ない)と言うのは
その通りだと思うがpreでの表現が邪道ってのは納得いかんなぁ。

たとえば、|+-　をつかってtableをtextでグラフを書くようなのとか
含めてpreはAAをその範疇とするとにんしきしているのだが。

708 ：Name_Not_Found：04/09/23 01:11:14 ID:???

\\
//
\\
//

709 ：Name_Not_Found：04/09/23 01:21:55 ID:???

<pre> ってのは、
「ここに書かれているものは“あるがまま”で、特に意味はないから、
あまり深く考えるなよｗ」
っていう程度の要素なんじゃないの？

仕様書を読む限り、「整形済みテキスト」ってのは、「テキスト」に
重点があるんじゃなくて、「整形済み」ってとこに重点があるように思う。

そうだとすると、<pre> の「中身」とか「範疇」とかってのは
方向性がズレてる希ガス。

710 ：706：04/09/23 01:23:53 ID:???

うーん、漏れのpreに対する理解が間違っているのかも知れん。

711 ：Name_Not_Found：04/09/23 02:44:19 ID:???

712 ：Name_Not_Found：04/09/23 09:01:11 ID:???

>>701 >>705
お前らなんかおかしくないか？
classに意味がないなら、classは完全に非strictだぞ。そこらへんは同思ってるの？

＞クラス名を人間が解釈しなきゃいけないHTMLってどうよ？
クラス名に限らないが、p要素やhn要素も人間に理解させるものではなくて
機械に理解させるもの。それが論理的なマークアップ。機械にさえ理解させたら後は
伝えられた機械がそれを人間にどう伝えるかの実装云々の話になる。

だからstrictとは人間に伝えることを考えることではなくて、機械に構造を理解させること。
機械に理解させた後の、人間への伝達を考えることはこのスレの範疇ではない。
とりあえずこれはこのスレの基本だから、現実的な話をするならもう１個のスレの方がいいよ。
ここはヲタ的にstrict-HTMLについて話すだけだから。

713 ：Name_Not_Found：04/09/23 09:15:23 ID:???

>>712
論理の飛躍。class属性の値の意味が有意でないと言っているのに、
なぜ勝手にclass自体が非Strictだと結論するかね。
というかこの話はほとんどコンセンサスを得られていたと記憶しているが、新参か？

714 ：Name_Not_Found：04/09/23 09:32:29 ID:???

>>712
classを理解するプログラムがあってもいい。
classは作った人がつけたのでプログラムは間違って理解するかもしれないので名前空間使って一意性を確保して欲しいが。
xhtmlでは別の名前空間で独自のタグが作って意味づけできるが、htmlでは他の意味づけができないのでclassができたと考えている。(後先逆だけど)

715 ：712：04/09/23 10:15:39 ID:???

>>713
>論理の飛躍。class属性の値の意味が有意でないと
要はクラスはたんなるグループ付けにすぎない。
IDは一意性の表現にしか過ぎない。

って言いたいんだと思う。でも値が無意味だとしたら
class=red
を批判するのはどうして？作者が赤っていうグループ付けをすることに何を不満がるってことにもなる。
いくらCSSからのネーミングでもCSSの観点からのグループ付けであって本いつのグループつけに関しては
変わらないから批判のしようもない。

716 ：713 (論理空間構築派)：04/09/23 10:34:33 ID:???

>>715
だから勝手に批判していると決め付けるな。俺は批判してないんだが。

717 ：Name_Not_Found：04/09/23 10:42:56 ID:???

>>715
ttp://www.w3.org/QA/Tips/goodclassnames

718 ：Name_Not_Found：04/09/23 10:44:59 ID:???

>>715
class=redに対する批判は論理的に文章をマークアップしろということ。気構えの問題と言ってもいい。

719 ：Name_Not_Found：04/09/23 10:50:38 ID:???

>>715
単に赤組ということにしたければ何の問題もない
作者が赤に表示色としての意味を持たせようとするとおかしくなる

720 ：Name_Not_Found：04/09/23 11:10:36 ID:???

>>715
よかったな。大漁だな。

721 ：712：04/09/23 11:42:19 ID:???

>>719
>作者が赤に表示色としての意味を持たせようとするとおかしくなる
なんでよ？ただのグループ付けで、値に有意はないなら問題ないでしょ。
言ってることが矛盾してるよ。

このスレでは今までclass=redのようなものは非strictとして回答を出してきた。
それに値に有意はあると言う話しですすめてきたよ。

まあ確かにIDやclassをフラグと考えて、何本もある旗と、１本しかない旗とでも
仕様書がそのつもりならそれでいいけどさ。でもそれならどうして
id="1"
がだめなんだろうね？まあ別の理由だろうけど。

まあなんていうか、今まではclassの名前は論理的なものでなくてはならないって
いってたのに急になんでもいいなんて言われると・・・・なんだかなぁ

じゃあHTMLレベルでのclassの利用価値って皆無に近しいの？
グループ付けなんてHTMLレベルではするカチがない。値に意味があるから
不可情報を付け足すいみで利用価値があると思ってたけど・・・

722 ：Name_Not_Found：04/09/23 11:53:31 ID:???

>>721
論理的に名前を付けなければならないけど、それに機械読み取り可能な意味を求めてはならない。

723 ：Name_Not_Found：04/09/23 11:58:52 ID:???

>>721
仕様上の問題の有無、と、strict思想的な問題の有無。の差。

仕様上はclass属性が持ちうる値であればどのような値あっても問題ない。

思想的には例えばcenter要素を廃止したいのにdiv class="center"として
cssなどでセンタリングを行うとcenterを廃止した意味が無くなるので大問題。

あと、全く別の話題として
>id="1"がだめなんだろうね？
idの1文字目に0-9は使えないから(これはstrict思想ではなく処理上の問題)。
単にStrictとして、或いはHTMLとして、ではなくDTD上の違反になり、
文書の解析が出来なくなる(かも知れない)のでかなり深刻な文法違反と言える。

"ichi" とか "one" なら少なくとも仕様上は問題ない。

724 ：Name_Not_Found：04/09/23 12:05:11 ID:???

>>721
> このスレでは今までclass=redのようなものは非strictとして回答を出してきた。
思考停止してとにかく駄目と言ってるんじゃないの。
役割付けではない、単なる見栄えを意図すべきではない、という心構えの話。
その要素に割り当てるスタイルに関わらず、
要素の役割がredでありつづけるなら (作者にとっての有意性しかないとはいえ) 問題ない。

> それに値に有意はあると言う話しですすめてきたよ。
そりゃお前の妄想か、もしくはお前の恣意的な前提。

> id="1"
Name生成規則は数値文字からは始められない。

> なんでもいいなんて
言っていない。

理解力というか、知性に欠ける気がするのは気のせいか。

725 ：712：04/09/23 12:07:52 ID:???

>>722 >>723
なんか言ってることがだんだん違ってきてない？

＞論理的に名前を付けなければならないけど
それは仕様書のどこに書いてあるの？

＞仕様上の問題の有無、と、strict思想的な問題の有無。の差。
DTDとstrict志向の差っていいたいのかな？俺としてはずっとstrict志向としての
ことを言ってるつもり。

＞思想的には例えばcenter要素を廃止したいのにdiv class="center"として
＞cssなどでセンタリングを行うとcenterを廃止した意味が無くなるので大問題。
つまりその思想が仕様書に基づいてるのか、拡大解釈してるのかを話してるんだと思うけど・・・

はっきりしてほしいな
　１．classの値が論理的な値でなくても非strictとはならない
　２．classの値は論理的でなければstrictではない
どっち？

726 ：712：04/09/23 12:12:20 ID:???

>>724
＞作者にとっての有意性しかないとはいえ
つまりclassの値を論理的にしなければならない、又それを薦めるようことは仕様のどこにも
明記されてないが、HTML利用者が勝手にそこに有意性を見出しているということかな？

つまりコメントと同じだといいたいのね？

727 ：Name_Not_Found：04/09/23 12:12:28 ID:???

>>717
> それは仕様書のどこに書いてあるの？
>>725
それとも、W3C直々のガイドラインを無視するかね？

> どっち？
2. redに論理的側面を見出せないのは、あんたが単純な二元論に陥っているからだよ。
ちゃんと学校で勉強してきなさい。

728 ：Name_Not_Found：04/09/23 12:13:56 ID:???

>>727 訂正
s/>>725/>>717/;

729 ：Name_Not_Found：04/09/23 12:14:56 ID:???

しかも>>727の一行目は>>725の誤り。

730 ：Name_Not_Found：04/09/23 12:21:40 ID:???

>HTML利用者が勝手にそこに有意性を見出している

少なくとも有意性がないよりあった方がいいわな

731 ：Name_Not_Found：04/09/23 12:29:08 ID:???

ここは釣り放題なインターネットですね

732 ：Name_Not_Found：04/09/23 12:33:19 ID:???

一回200円。

733 ：Name_Not_Found：04/09/23 12:37:47 ID:???

まあおまいら、これでも見て落ち着け。
ttp://fun.from.hell.pl/2004-09-17/Lotto.mpg

734 ：712：04/09/23 12:43:55 ID:???

>>727
>それとも、W3C直々のガイドラインを無視するかね？
英語読めないんだけど、実際なんて書いてあるの？

＞2. redに論理的側面を見出せないのは、あんたが単純な二元論に陥っているからだよ。
＞ちゃんと学校で勉強してきなさい。

redに論理的な側面があるかないかなんて話はしてないよ。classの値に論理的でない名前を
使うことで非strictになるかどうかの話だよ。争点を間違えないで。

>>731-732
お前らむなしくない？いちいちそんあくだらないこと書いて投稿するなんて、よほど暇なんだな。
無意味な煽りはスレ違いだから他イってよ。まともな話のできない人間はこのスレに必要ないんだから。

735 ：Name_Not_Found：04/09/23 12:49:23 ID:???

ずごー

736 ：Name_Not_Found：04/09/23 12:52:03 ID:???

おっと、重要な事実を確認しなくてはならない。
> まともな話のできない人間はこのスレに必要ないんだから。

737 ：Name_Not_Found：04/09/23 12:52:52 ID:???

>>734
> classの値に論理的でない名前を使うことで非strictになるかどうか

ならないよ。「論理的に名前を付けなければならないけど」は722の妄想。

738 ：712：04/09/23 13:17:06 ID:???

>>737
>ならないよ。「論理的に名前を付けなければならないけど」は722の妄想。

ちゃんと話してくれてる相手はずっと一人だと思ってたけど、違ったのか。
それにしてもclassの値がstrictとは関係しないっていうひとなんて初めて。
今まで、
「classの値は論理的でなければならない」
っていう発言が結構あって、だれもそこに反論しんかったから、そうなんだと思ってたよ。
まあどっちが正しいかはしょせん和訳しかよめない俺にはわからないけど。

739 ：Name_Not_Found：04/09/23 13:17:24 ID:???

>>737
非Strictにならないという根拠を提示してよ。それが出来なければその発言は妄想だ。

740 ：Name_Not_Found：04/09/23 13:20:11 ID:???

仕様書以上の何も語らないことがStrictか？それならそうだな。
W3Cのガイドラインに従うのであれば、論理的でない名前は使わないほうがいいんだけどな。
それについてどう考えているんだろうね。

741 ：Name_Not_Found：04/09/23 13:22:35 ID:???

論理的な名前を付けることが推奨とされているし、
論理的でなく見栄えを意識しただけの名前は本末転倒。
その本末転倒は非Strictにつながりかねないから、Strict徹底するなら避けるべき。
ただし論理的でないかも知れない名前がDTD違反を起こすことはもちろんないし、
論理的かどうかは究極のところHTMLを検証しないとわからん。

現実問題本末転倒を起こしてるやつが多いし検証も面倒だから、
非論理的な名前 = 非Strict、的な風潮がある（んだと思う）。

努力して論理的な名前を付けることが悪いことではないし俺もそうしてるし、
もし誰かに聞かれたりすりゃそうすることを薦める。

とりあえず、712は煽りと大して変わらないレベル（自分が知らないものを知る努力をしてないだろ？）。
そんな難しい英語でもないんだから原典読んでみれ。

742 ：Name_Not_Found：04/09/23 13:38:34 ID:???

翻訳サイトとかあるしな。
Firefox使ってるなら拡張で翻訳パネルもあるし
Operaでもサイドバーに翻訳サイトを埋め込みゃいいし

743 ：Name_Not_Found：04/09/23 14:49:46 ID:???

よくわからんけど、classにredってしてて、気分が変わって
青にしたくなったとき、cssをいじるだけでいいはずなのに、
classの値まで変更しなきゃならないからよくないんじゃないの？
スタイルを変更する際に、HTMLドキュメントにまで手を加えないといけない

744 ：Name_Not_Found：04/09/23 15:08:06 ID:???

>>743
怪しい哲学的な話に立ち入らなければそういうことだね。

745 ：Name_Not_Found：04/09/23 15:08:38 ID:???

>>743
前後関係逆だけどね
論理的にしたことによって得られる利点

746 ：Name_Not_Found：04/09/23 15:15:41 ID:???

「～の方が良い」 or 「～するのが望ましい」
と、
「～でなければならない」
を混同しているヤツが多くないか？

私的には >>741 の意見に同意だが。

747 ：Name_Not_Found：04/09/23 15:16:03 ID:???

>>743
更に言えば…

例えば、帳簿を付けているサイトで、
「購入した品目名」と「マイナスになった予算」を両方とも
赤いからclass="red"にしている場合とか。

「購入した品目名」だけを今度黒にしたい、なんて場合、
このredは「品目名かマイナスか」と悩む羽目になる。

だったら最初から、品目名とか、マイナスとかの意味で名前付けとけよ、と。

748 ：Name_Not_Found：04/09/23 17:37:55 ID:???

>>741
>論理的な名前を付けることが推奨とされているし、
どこで？そのソース部分をコピってきてよ。

749 ：Name_Not_Found：04/09/23 17:51:34 ID:???

>>748
>717
せめて30レス読み返せば関連レス見つかったのにな。

750 ：Name_Not_Found：04/09/23 21:01:06 ID:???

>>749
＞
こんなソース書いてるよこいつｗ
strictのかけらもないな。こいつはリニュごとにコメントを書き直すんだろうな。
だったらclassも書き直せばいいのにねｗ

751 ：Name_Not_Found：04/09/23 21:20:41 ID:???

こんなところで重箱の隅つついてないで、直接メールで言えばいいのに。

752 ：Name_Not_Found：04/09/23 21:31:00 ID:???

少なくとも http://www.w3.org/QA/Tips/goodclassnames には
「論理的な名前を付けることが推奨」なんてことは書かれてません
semantics に論理的なんて意味はありません
ちゃんとしたソースよこしなさい

753 ：Name_Not_Found：04/09/23 21:45:35 ID:???

どこの誰が semantics に論理的な意味があるなんて言ったんだ？
ちゃんとしたソースよこしなさい。

754 ：Name_Not_Found：04/09/23 21:52:19 ID:???

>>752
html4.01の仕様書の17.6に
The OPTGROUP element allows authors to group choices logically.
という記述がある。
一方で同2.3.2には
the ability to group SELECT options semantically
という記述がある。
つまりlogicallyとsemanticallyはここでは同義語として使われていることがわかる。

755 ：Name_Not_Found：04/09/23 21:57:03 ID:???

>>752
詭弁だなあ。当該リソースで示されていることは、
日本語で言うところの「論理的な名前をつけること」なわけ。
逐語訳しか出来ず、文意が理解できず、日本語さえ理解できないのかね君。

756 ：Name_Not_Found：04/09/23 22:12:14 ID:???

>>754-755
同義語として使われてると思うのは君らの先入感があるからでしょ
まず、semantically にグルーピングできるようになってないと
論理的に使うことはできませんが、だからといって、
semantically が論理的と同義なんて言い過ぎ。

757 ：Name_Not_Found：04/09/23 22:16:07 ID:???

>>756
分かった。じゃあ訂正するよ。
「semanticな名前を付けることを推奨」。
これで満足か？

758 ：Name_Not_Found：04/09/23 22:30:57 ID:???

で、semanticでない名前をclassに指定したがるのは誰ですか？

759 ：Name_Not_Found：04/09/23 22:36:57 ID:???

>>757
お前722？ただの粘着っぽいな

760 ：Name_Not_Found：04/09/23 22:39:28 ID:???

下らん言葉遊びだな。

761 ：Name_Not_Found：04/09/23 22:45:30 ID:???

「semanticな名前を付けることを推奨」じゃなくて
「semantically に名前を付けることを推奨」であるべきだな

762 ：Name_Not_Found：04/09/23 23:21:45 ID:???

こんなに釣れて>>665はさぞ喜んでることだろうな。

763 ：Name_Not_Found：04/09/23 23:23:06 ID:???

http://www.w3.org/QA/Tips/goodclassnames

よくわからないんですが、ここに書いてあることは仕様書の解釈の仕方ということですよね？
仕様書と同レベルの文書と捉えるべきですか？

764 ：Name_Not_Found：04/09/23 23:26:12 ID:???

>>763
その上位の文書に書いてあるよ。

765 ：Name_Not_Found：04/09/24 09:28:42 ID:???

<h1>第一節題名</h1>
<p>第一節本文</p>
<h1>第二節題名</h1>
<p>第二節本文</p>

と

<p><h1>第一節題名</h1>
第一節本文</p>
<p><h1>第二節題名</h1>
第二節本文</p>

はどっちの方が適当ですか？

766 ：Name_Not_Found：04/09/24 09:40:05 ID:???

>>765
どっちもだめなんじゃない？

767 ：Name_Not_Found：04/09/24 09:41:18 ID:???

>>711 とか >>765 みたいなのは釣りでしょうか？

768 ：Name_Not_Found：04/09/24 11:12:05 ID:???

DL,DT,DDの使い方として、

DT・・・投稿者名や投稿タイトル
DD・・・投稿本文

や

DT・・・日付けや日記タイトル
DD・・・日記本文

は問題ないですか？

769 ：Name_Not_Found：04/09/24 11:38:29 ID:???

>>767
釣りとまでは断定出来ないけど、>>1 が読めてないのは確か。
>>1
>でもHTMLの基礎知識は欲しいね。

そもそもここは質問スレじゃねぇので、論議の題材なら兎に角、
単なる教えて君はスルーで無問題。

770 ：Name_Not_Found：04/09/24 12:00:58 ID:???

>>768
定義リストだから。定義or説明をしてくれ。
上はいいが、下はhn+Pの仕事。

771 ：Name_Not_Found：04/09/24 13:35:01 ID:???

>>769
>釣りとまでは断定出来ないけど、>>1 が読めてないのは確か。
読んでもHTMLをしっかり勉強してから来る奇特なやつなんて・・・・

そもそもここはstrictを広める役割もあるんだから、おまいも住人ならくだらない
罵倒はやめれ。

スタンスとしては初心者にある程度手ほどきしつつ、ヲタ同士の議論をするみたいなかん時だな。

772 ：Name_Not_Found：04/09/24 13:54:27 ID:???

>ここはstrictを広める役割もある

いつから決まったんだこれ？

>読んでもHTMLをしっかり勉強してから来る奇特なやつなんて・・・・

Strictスレだろうが初心者スレだろうが回答のみ期待するやつはお断りでしょ。
せっかくテンプレに書いてあることも読めない教えて君は排除されて然るべき。

773 ：Name_Not_Found：04/09/24 13:55:19 ID:???

771は日本語が正しく使えていない時点で strict スレ住人じゃない希ガス

774 ：Name_Not_Found：04/09/24 13:56:17 ID:???

おまいら、せっかく収まったのに蒸し返すなよ…。

775 ：Name_Not_Found：04/09/24 13:56:39 ID:???

>そもそもここはstrictを広める役割もあるんだから、おまいも住人ならくだらない
>罵倒はやめれ。

>スタンスとしては初心者にある程度手ほどきしつつ、ヲタ同士の議論をするみたいなかん時だな。

とか言いつつ、結局他人を否定するだけして、
初心者への手ほどきは全くしない >>771 萌え。

776 ：Name_Not_Found：04/09/24 14:00:52 ID:???

定期的に面白い人が現れるなぁここは

777 ：771：04/09/24 15:07:47 ID:???

いやならこないでいいよ。
俺が立てつづけてるスレで、俺に文句を言うなら他のスレに行けよ。

778 ：Name_Not_Found：04/09/24 15:12:58 ID:???

>>771=777
>>772

広めたいならサイトでも作って勝手にやってくれ
そこでなら思う存分来るもの拒まずで納得いくまでやってくれていいから、な

779 ：Name_Not_Found：04/09/24 15:15:29 ID:???

>>777
刷れた手いつも乙です。
初心者の質問も議論を妨げなければかまわないと思うので次から初心者の質問もある程度OKということをテンプレで明文化お願いします。
逆にいうと俺がスレ立ててるんだから俺がルールブックだ見たいな言い方は萎え。

780 ：Name_Not_Found：04/09/24 15:18:01 ID:???

>>777
俺も立てたことあるがな。

781 ：Name_Not_Found：04/09/24 15:18:11 ID:???

お前が立てなきゃ他の誰かが立てるだけ。いち住人でしかない。

782 ：Name_Not_Found：04/09/24 15:18:18 ID:???

>>778-779
つーか、こちらじゃ駄目なんかい？

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

783 ：Name_Not_Found：04/09/24 15:20:01 ID:???

もうなんかね、言ってることの意味が全然わかんない

784 ：Name_Not_Found：04/09/24 15:41:56 ID:???

おれが幹事だ！おれの言うことに従え！

・・・次回から幹事を降ろされるどころか、誘ってさえもらえなくなるよ。

785 ：Name_Not_Found：04/09/24 16:06:31 ID:???

ま、IDもトリップもなしで「オレが立てた」と言われてもな。
「一スレ住民」を超えた個性をもちたきゃ次からトリップ付けて
発言するこった。

786 ：Name_Not_Found：04/09/24 17:45:47 ID:???

せめてトリップ付けてくれりゃ、こっちであぼーん設定できるしな

787 ：Name_Not_Found：04/09/24 17:57:49 ID:???

漏れも今ぎんぎんに立ててますが、何か？

788 ：771：04/09/24 18:19:12 ID:???

「ここはお前の場所じゃない！！！」なんて子供っぽいことはいわないだろ？
お前ら別にこのスレにしがみつく理由もないだろう。
俺はこのスレを立ててるんだからそれなりの義務があるのさ。

とにかく、ある程度初心者の質問にも答えること。
答えなくても煽りや必要以上の罵倒はやめること。
なによりこのスレになって極端に増えた、議論や回答になってないくだらない煽りレスを
するような人間は本気で他のスレで。ここを八つ当たり場所に使わないでくれ。

>>782
過疎板で細分化しすぎだよ。strictに関する話題は全てここで問題なし。
まあ実装云々はダメだけど。

789 ：Name_Not_Found：04/09/24 18:35:41 ID:???

変な流れだな。

個人的に疑問なんだが、preのインライン版て何で存在しないんだろうな。
xml:space="preserve"がデフォルトになっているインライン要素
が欲しいよ。

p要素内の文中にコードとか含めたいとき困るんだよな。

790 ：Name_Not_Found：04/09/24 18:39:14 ID:???

>>789
コードを書きたいのなら<CODE>がありますよ

791 ：789：04/09/24 18:51:11 ID:???

>>790
すまん、言い方が悪かった。
コード書く時って（言語にもよるけど）空白を保持するために
preも一緒に使うことが多いからさ。

<pre><code>hoge;
hoge hoge;</code></pre>

みたいな感じで。

XHTML2.0だとp要素にpreも含むことが出来るようになるのね。
ins要素みたいな感じの扱いになるのかな。

792 ：Name_Not_Found：04/09/24 18:56:32 ID:???

>>791
コード内に改行も含んで複数行になるのなら、
Pの中にそのコードを書くのは変でない？
普通にブロックのPREを使っておけばいいような。

793 ：789：04/09/24 19:31:02 ID:???

さらに説明の仕方が悪かったな・・・orz
上に挙げたのはブロックレベルで使うときの例ね。

コードに関する解説とか書こうと思うと
「5行目の$hoge = "strict stricter strictest"の部分は・・・」
とか書きたくなることがよくあるんだけど、
空白を正規化されると困るときがあるんだよね。

794 ：792：04/09/24 19:53:29 ID:???

>>793
空白の正規化・・・ってよくわかんないけど、なんか不具合があるんですね。
こちらこそ読解力がなくてごめんなさい。

795 ：Name_Not_Found：04/09/24 21:06:31 ID:???

つーか、「HTMLのフリーフォーマットのコードとしての空白」ではなく、
「本文として意味がある空白」を書きたいなら実体or数値参照つかえば？

796 ：Name_Not_Found：04/09/24 21:14:11 ID:???

プログラムコードの中の空白も、通常の（英）文章と同様に、
関数、変数、リテラルなどの区切り子でしかないような希ガス。
コンパイラ的観点から考えると。

797 ：Name_Not_Found：04/09/24 21:31:43 ID:???

インラインなコードで正規化されて困る空白というと、
リテラル中の空白くらいしか思いつかないな。
他にある？連続する空白が意味を持つ言語？
Pythonのインデントは、インラインで示すコードには要らないよね。

798 ：Name_Not_Found：04/09/24 22:18:19 ID:???

Fortranの行頭空白とか

799 ：Name_Not_Found：04/09/24 22:45:11 ID:???

>>797
C系のフリーフォーマット言語だけがHTMLで書かれる対象ではない。

800 ：Name_Not_Found：04/09/24 23:38:41 ID:???

>>799
じゃあなによ。具体例を頼む。

801 ：Name_Not_Found：04/09/24 23:58:10 ID:???

whitespace。

802 ：Name_Not_Found：04/09/25 14:56:49 ID:???

>>797
>Pythonのインデントは、インラインで示すコードには要らないよね。
文脈などによるが
「3行目には『……』を丸ごとコピーして下さい」
の……では必要になる気がする。

803 ：Name_Not_Found：04/09/25 16:31:30 ID:???

※全項目入力願います。

↑この場合の※ってHTMLに書いちゃダメ？CSSでやるべきなの？
なんか最近思ったのだけど、
：※>＞
とかの記号をHTMLに書かずにCSSでやるっていうのは変な気がするのよ。
だってCSSなしじゃ視覚UAユーザには伝えれないってことでしょ？

だから記号を使っても非strictにはならない気がするんだけどおかしい？
論理的には要素で示す。しかし記号をHTMLに書いて2重に示してもいいんじゃないの？

804 ：Name_Not_Found：04/09/25 16:36:04 ID:???

<OL>の数字がコピーできなくて頭に来たことのある漏れも、>>803に同意

805 ：Name_Not_Found：04/09/25 17:42:14 ID:???

>>804
それはUAの実装が悪い

806 ：Name_Not_Found：04/09/25 17:43:46 ID:???

>>803
場合によるけどstrongでいいじゃん。

807 ：Name_Not_Found：04/09/25 17:55:24 ID:???

>>803
場合による。

>だってCSSなしじゃ視覚UAユーザには伝えれないってことでしょ？
「※」を伝えたいなら、HTMLに※って書かなきゃ成らない。決してCSSに任せるべきではない。
一方で、「強調という意味を表したい」ならemかstrongでマークアップしておいて、
後はUAに任せる。もしUAが視覚系CSS対応なら「※」って表示できるかも知れない、と言う事。

例えばだが「※の付いている項目は必須項目になります」なんて場合は
※はHTMLに書かなきゃダメ。音声系UAにとって「単なる強調の意味での※」が
じゃまなのと同じか、それ以上に「必須項目が伝わらない」という困った状態になる。

808 ：Name_Not_Found：04/09/25 17:57:09 ID:???

>>805
そうなのか。IEめ！Mozillaめ！Operaめ！
・・・NN4.78ではコピーできますた。

809 ：Name_Not_Found：04/09/25 18:21:07 ID:???

>>807
>※の付いている項目は必須項目になります
これは"ここ"とかいう言葉からのリンク(?)と同じでだめだと思うのだが…

810 ：803：04/09/25 18:23:07 ID:???

>>807
強調というか注釈みたいな時にこの※って使うよね。
注釈ですって意味を視覚UAユーザに伝えるにはこれを使うしかない。
もちろんCSSが絶対に効くというならCSSでもいいんだけど。

結局CSSの実装問題になってこのスレとは無縁な方向に行くのかな；
まあでもCSSなしでも（CSSファイル自体つくらず）、視覚UAユーザに意味を理解させたい・・・

っていうか記号とかをCSSでやると結局、CSSありなしで、視覚UAユーザへの伝わり方
が変わるってのは問題なんじゃない？

装飾５：５論理みたいなときはHTMLに記号を入れてもありってのはだめかな・・・・？
完全に装飾だっていうものだけ排除すれば結構分離ができると思うんだよね。
まあそもそも見栄えと構造を分離させてしまったら、CSSもHTMLも単独では
成り立たないというか・・・・・いや成り立ってるんだけど・・・きっちりオブジェクト指向ぽくなるんだけど・・・

なんというか・・・・

811 ：Name_Not_Found：04/09/25 19:52:20 ID:???

>>808
mozillaは番号部分は選択出来ないけど、
liの内容をコピペすると番号も勝手のに付いてくる。

812 ：807：04/09/25 20:20:55 ID:???

>>809
全然違うと思うが?

もちろん、必須入力要素・属性があるならそれを使うのが大原則だが、そう言う要素はない。
すると、あとは内容レベルで記述者が工夫、と言う事になるが、その時、
「必須入力と書く」のと「※という記号にシンボライズして書く」のとでどう違うのか理解できない。

もちろん「ここ」の話みたいに、同ページ内で※が複数の意味を持たされたりすると
問題だと思うが、今回はそう言う話ではないと認識している。

813 ：Name_Not_Found：04/09/25 20:54:57 ID:???

>っていうか記号とかをCSSでやると結局、CSSありなしで、視覚UAユーザへの伝わり方
>が変わるってのは問題なんじゃない？

ユーザが視覚UAなのか、音声UAなのか、によって「片方で著しく不具合が生じる」
よりは、「表示形態が異なっても、『意味は通じる』」というのがHTMLのメリットなので、
その点に関しては、より大きいメリットのために大意(例えば見出しとか強調とか)が
伝わればそれでよい(そこは問題にしない)と言う事になってます。

少なくともHTMLの守備範囲ではないので無理してHTMLで記号を色々突っ込んで
表現しようとするよりも、PDF版などの規格を使った方が作者にも閲覧者にも
利益が大きい。

814 ：Name_Not_Found：04/09/25 21:09:42 ID:???

<input class="required" .../>
とやって
<a href="#xpointer(input[class = 'required'])>必須項目</a>は必ず入力してください。
とやるのか? うーん。

素直に(必須)と書いたほうがいいか。
それか<abbr title="(秘密)">(秘)</abbr>からの連想で<abbr title="(必須)">※</abbr>というのもありか?

815 ：Name_Not_Found：04/09/25 21:11:17 ID:???

<span class="required">(必須)</span>

.required{content:"※"}

これだとOperaしかだめだけど

816 ：Name_Not_Found：04/09/25 21:13:44 ID:???

>>815
beforeとか付けなくていいのか？
Firefoxとかその系統も有効だと思ったが…

817 ：Name_Not_Found：04/09/25 21:17:38 ID:???

そこまでして※を排除する必要は別にないと思うけど。
>>812に大筋同意。

818 ：Name_Not_Found：04/09/25 21:39:28 ID:???

必須項目の目印としての※ならいいと思うけど、
「※全項目入力云々」のメッセージは"※"使わずにemでいいと思う。

819 ：Name_Not_Found：04/09/25 22:11:14 ID:???

>>816
これだと(必須)の文字が※で上書きされる。
CSSで許されているかは確認してないけど

820 ：Name_Not_Found：04/09/25 22:13:43 ID:???

>>819
スレ違いだが、必須と書かずにbeforeで生成するか、
<span class="nostyle">※</span>とかやった方がいいと思われ。

821 ：Name_Not_Found：04/09/25 22:29:34 ID:???

> <span class="nostyle">※</span>
是は駄目だろ

822 ：Name_Not_Found：04/09/25 23:49:52 ID:???

>>810
その論理でいくとCSSのdisplayとcontentは非推奨だな

823 ：Name_Not_Found：04/09/26 00:06:26 ID:???

>少なくともHTMLの守備範囲ではないので無理してHTMLで記号を色々突っ込んで
>表現しようとするよりも、PDF版などの規格を使った方が作者にも閲覧者にも
>利益が大きい。

それはない。そもそもHTMlを本来の用途で使おうと思ってる人間なんて・・・本来の用途
を知らない人間が発注をしてくるのだよ；だから葛藤の毎日さ。
PDFてのがありますよなんて言っても、「他のサイトみたいに～」

結局間違ったものが多くて、それがスタンダードになってる現状だから
webサイトをホームページと呼ぶな！みたいな話になってしまうんだな。

824 ：Name_Not_Found：04/09/26 01:05:30 ID:???

また頭の弱そうなのが現れたな

825 ：Name_Not_Found：04/09/26 01:10:02 ID:???

えっ!? どこどこ?

826 ：Name_Not_Found：04/09/26 02:05:47 ID:???

発注する側は所詮見れればいいという考えでしかない

827 ：Name_Not_Found：04/09/26 02:40:20 ID:???

>>819
すれ違いとなるが一応。

contentプロパティはbefore、afterによる疑似要素生成時にのみ
有効となる指定で、そうでない場合本来「無視されねば成らない」

Operaが「疑似要素以外に指定した場合本来の内容と置き換える」
のはバグ。

828 ：Name_Not_Found：04/09/26 02:57:54 ID:???

>>824
読んでると文体に特徴があるから、以前と同じアフォ。スルー上等で。

829 ：Name_Not_Found：04/09/26 04:58:44 ID:???

>>827
css3で案として上がってなかったっけ？＞Operaのような動作

830 ：Name_Not_Found：04/09/26 05:26:38 ID:???

>>829
よく知らんけど、仮に有ろうが無かろうが、現行の仕様と区別が付かない形で
正式勧告前の仕様を実装してしまったら、(現行の仕様を基準に)バグなのでは?

このスレ的に言えば、XHTML1.0で(DTDを変更せずに)Ruby要素を
実装するような物ではないかと。
(エラー処理として行われるなら兎に角、そのまま受け入れたら
当然XMLとして不味いわけで)

831 ：Name_Not_Found：04/09/26 05:49:07 ID:???

>>830
スレ違いなのに疑問形で終わるな。

832 ：Name_Not_Found：04/09/26 10:36:44 ID:???

>>826
そんなことないでしょ。SEOについても口出してくる客だって一杯いるよ。
まあ企業になるとSEOはあまり言ってこないけど。
でもさすがにHTMLで仕上げることにはこだわるよ。

833 ：Name_Not_Found：04/09/26 10:45:47 ID:???

ま、そう言うときのためにTransitionalだな。
CSSレスで文字の色とか、大きさとか、センタリングとか
存分にやればいい。

ストリクタとしても、「それはレガシィですよ」とは内心思っても、
別段仕様そのものは現役バリバリだし、用途の違いを認識して
正しく使われているならケチを付ける場所だないし。

834 ：Name_Not_Found：04/09/26 12:05:09 ID:???

>>833

>ケチを付ける場所だないし。

だないし？＾＾

835 ：Name_Not_Found：04/09/26 21:19:31 ID:???

とりあえずStrictでないものは蚊帳の外ということで。

836 ：Name_Not_Found：04/09/26 22:36:54 ID:???

とりあえずこのままdat落ちしようよ。誰もageるなよ。

837 ：Name_Not_Found：04/09/26 22:46:47 ID:???

おや、未だにageないとdat落ちすると思っている(らしき)お方が。

838 ：Name_Not_Found：04/09/26 23:20:31 ID:???

sageたほうがレスは減るだろうけどね

839 ：Name_Not_Found：04/09/26 23:24:47 ID:???

VIPだと下げてるとdat落ちするけどね

840 ：Name_Not_Found：04/09/26 23:25:20 ID:???

この板じゃ数ヶ月放置しても落ちないけどね。

841 ：Name_Not_Found：04/09/26 23:27:06 ID:???

今度はスレ違いどもか。

842 ：Name_Not_Found：04/09/27 00:06:27 ID:???

>>841
じゃあネタ投下しろよボケ！

843 ：Name_Not_Found：04/09/27 00:07:53 ID:???

なんだとこのやろう

844 ：Name_Not_Found：04/09/27 00:47:23 ID:???

っていうかお前....
定期的にこのスレチェックしてるんだな。
俺もだが、特に話すこともないのに何故かここに期待をしてしまうよな。

やはりループでも議論は面白いんだよな。そうじゃなきゃこのスレ続かないもんな。
ところで1スレ目からずっと全レス見てきた人いるの？ちなみに俺は5スレ前くらいから見てる。

845 ：Name_Not_Found：04/09/27 00:48:43 ID:???

(・∀・)ｶｴﾚ!!!

846 ：Name_Not_Found：04/09/27 08:34:52 ID:???

> ちなみに俺は5スレ前くらいから見てる。
棄てられたスレになってからしか見てないのね。

847 ：Name_Not_Found：04/09/27 11:42:05 ID:???

>>846
まだこのスレから卒業できないんだね。

848 ：Name_Not_Found：04/09/27 12:38:01 ID:???

おまえもな…

849 ：Name_Not_Found：04/09/27 15:28:38 ID:???

>>847
そんなこと言ってるからレベルが下がり続けるのだよ。

850 ：Name_Not_Found：04/09/27 15:41:12 ID:???

掟破りage

851 ：Name_Not_Found：04/09/27 16:12:10 ID:???

>>849
どういう根拠だそれ？論理的な説明頼むぜ。

>>850
てめえ......

852 ：Name_Not_Found：04/09/27 16:19:42 ID:???

(･∀･)ﾆﾔﾆﾔ

853 ：Name_Not_Found：04/09/27 16:36:11 ID:???

この寂れこそもののあわれ。

854 ：Name_Not_Found：04/09/27 16:41:28 ID:???

(･∀･)ﾆﾔﾆﾔ

855 ：Name_Not_Found：04/09/27 18:57:58 ID:???

>>852 >>854
キモイ。

856 ：Name_Not_Found：04/09/27 21:06:48 ID:???

いとわろし

857 ：Name_Not_Found：04/09/28 21:44:59 ID:???

CSSスレとここと初心者スレを巡回して自分がどこにいるかさえわからなくなってしまうのである！

しかし待てよ、なぜこんな過疎スレを見てる？そうかわかたっぞ！

858 ：Name_Not_Found：04/09/28 23:25:11 ID:???

デリヘルドットネットスレを定期的に見てるよりましだよ

859 ：Name_Not_Found：04/09/28 23:29:48 ID:???

>>858
おー、忘れてた。
ageてこなきゃ。

860 ：Name_Not_Found：04/09/29 02:31:02 ID:???

>>858
よくわからんがそのスレはなんかいいのか？すごいのか？
どこの板？

861 ：Name_Not_Found：04/09/29 02:36:04 ID:???

雑談は雑談スレで…。

862 ：Name_Not_Found：04/09/29 02:54:11 ID:???

>>860
この板

863 ：Name_Not_Found：04/09/29 10:18:53 ID:???

>>861
ほう。ここまで過疎スレで自治をするか。おまいもやるな。

864 ：Name_Not_Found：04/09/29 12:55:16 ID:???

(´ﾟ c_,ﾟ`)

865 ：Name_Not_Found：04/09/29 16:10:28 ID:???

凄くスレ違いなのはわかってるが、初心者スレや・・・あっ、板違いなんだけどさ。
まあいつも話してるおまいらに聞きたいわけよ。

HTMLとかPerlとか色々な言語を学ぶのには正直ネット接続環境さえあれば、解説サイトや
仕様書を見に行けば誰でも簡単に習得できるよね。そこで思ったのだが、仕様書の和訳を
読むよりも英文をそのまま読みたい。

で、英語も言語とかと同じように勉強できるのかな？解説サイトとか単語辞書とかで
発音は無理でも意味は理解できるようになるの？

プログラム言語ってだいたい1月もあればそこそこ理解できて、あるていどの規模のプログラムを
構築できるようになるけど、英語も1月くらいでほとんどの文章を和訳できるようになるかな？
英語とプログラム言語ではレベルが違う？

866 ：Name_Not_Found：04/09/29 16:21:27 ID:???

外国語を独学で学ぶ人もいるんじゃない？
それとHTMLは言語の一種とはいえるが、プログラムではないとコメントしておく。

867 ：Name_Not_Found：04/09/29 16:22:45 ID:???

寂れたら困る同盟でもあるんかいな。

868 ：Name_Not_Found：04/09/29 16:35:51 ID:???

困りはしないけどな。

869 ：865：04/09/29 17:35:18 ID:???

>>866
やっぱりPerlとかの比ではないかな？
結局文法だよね？単語は何度も辞書を引くだけで段々といくけど、文法辞書みたいなのが
あるといんだよね。いまだに
is
すらわからないから；

870 ：Name_Not_Found：04/09/29 19:02:16 ID:???

>>869
スレ違い。
http://pc5.2ch.net/test/read.cgi/prog/1057409956/
こちらでどうぞ。

871 ：Name_Not_Found：04/09/30 14:04:18 ID:???

マジレスすると、自然言語とプログラミング言語を比較するのはナンセンス。
プログラミング言語は仕様に基づいて厳格に定められているけど、
自然言語はTPOに応じてやたらめったら増えてきたから「例外処理」も多い。

872 ：Name_Not_Found：04/09/30 14:43:43 ID:???

結局、括弧はどのように扱えばいいの？
括弧なしの文章を書いて、スタイルシートのビフォーアフターでつけるの？

その場合、スタイルを適用しなかったらレンダリングされたものの意味が通じなくなっても、
ソースを見ればマークアップされてるからもんだいないの？

873 ：Name_Not_Found：04/09/30 15:00:37 ID:???

>>872
そう

874 ：Name_Not_Found：04/09/30 15:10:22 ID:???

>>872
括弧は普通に書いていいよ。英文のスペースと同じレベル。
もともと過度なstrict志向は非strictになるから。
大まかな部分での分離がstrictであって細部にいたるまでこだわることがstrictというわけではない。
まあ完全に俺の脳内だから信じても意味ないけど。

ここからは脳内２ね。
＞スタイルを適用しなかったら
もともと1つのものを分離したのだから、片方がなくなれば完全なものを伝えられないのは
当然。

875 ：Name_Not_Found：04/09/30 16:11:32 ID:???

>>872
括弧がただの見栄えならば書いてはいけない。
見栄えでないのならば書かなければならない。

それよりもその括弧でなにを表現しようとしているのか考えるのが先だがな。

876 ：Name_Not_Found：04/09/30 16:19:59 ID:???

括弧を書かないといけない場合
　数式とか、プログラムとか
　→CSS無効時に意味が完璧に壊れる

括弧を書くとStrict志向じゃない場合
　強調の為の括弧付けとか、見出しであることの強調とか
　→HTMLのマークアップで既に意味が明示されているにも関わらず
　　それを目立たせる為の飾りとして用いる場合

どうでもいいや的なもの場合
　台詞を表す括弧とか
　→spanとclassなどを駆使してCSSでやってもいいし、HTMLの中に書き込んでもいい。
　　前者の場合、よりStrictになれるかもしれないがCSS無効時に配慮した記述である事が求められる。

877 ：Name_Not_Found：04/09/30 16:45:41 ID:???

HTMLだけで読んでみて「あーこれ意味通じてないな」ってなったらアウトだぞ、と。
ちなみに今のあーこれ意味通じてないなの前後のかぎカッコは装飾な。

878 ：Name_Not_Found：04/09/30 17:20:14 ID:???

>>877
>「あーこれ意味通じてないな」
これは装飾じゃないって。よく考えろ。かぎ括弧が装飾になる時はもっと違う時。
例えば

入力後「送信」ボタンを押してください。

↑とかな。セリフの場合は装飾にはならないよ。

879 ：877：04/09/30 17:36:54 ID:???

>>878
>セリフの場合は装飾にはならないよ。

台詞ではないから装飾。
台詞の際のかぎカッコは引用の意味合いも含まれて、ってのはどうでもいいか。

「あーこれ意味通じてないな」
（あーこれ意味通じてないな）

どっちも心の声として表現に使えるってことはカッコの形を限定しないってこと。
で、877の文章では実際誰かの発言を持ってきてるわけではないのでそう書いた。

HTMLだけで読んでみてあーこれ通じてないなってなったらアウトだぞ、と。

書く側の胸先三寸なところもあるけどね。
Strictは自分が納得できないと、って部分もあるように思ってるので。乱文失礼、出かけてくる。

880 ：Name_Not_Found：04/09/30 17:38:21 ID:???

>>878
>これは装飾じゃないって。
　なるかならないかは、微妙。
台詞の範囲を明示する括弧を装飾と解釈することを誤りだとするのは早計。

　例えば引用時に使われる "" や > は装飾? 意味のある text ?

881 ：Name_Not_Found：04/09/30 17:41:34 ID:???

どっちかの方が Strict 的にベターかも知れないけど、
どっちかがベストとか、どっちかじゃないと Strict ではない、
って程でもないかと。

一つ言えることは、どっちを採用するにしても一つの文書群では全体として
統一した記法にしないと XML 的に使い回しが面倒になる (文書の価値が下がる)
ってことだな。

882 ：878：04/09/30 18:02:12 ID:???

>>879
そうか心の声とすると装飾になるんだな。納得。

>>880
う～んそういうこというと英文のスペースも装飾ってことになりそうだな。
ところで装飾か否かはどう判断するのが理想なんだ？
形を変えたり？それともなくしてみたり？

でも表示上の伝達力を失うかどうかは、それが装飾なのかどうかを判断する基準にはならない気がするよ。
パンクズリストだって、表示から理解させるにはあの記号が必要だけど、マークアップ時にはいらないからね。

883 ：Name_Not_Found：04/09/30 18:20:10 ID:???

>英文のスペースも装飾ってことになりそうだな。

英文の半角スペースは単語を識別する点で必要
Iwanttogotomybedとか描いたら人間が識別するのに無駄な力を要するし、
組み合わせによっては意味の変わる単語・熟語もある。

>でも表示上の伝達力を失うかどうかは、それが装飾なのかどうかを判断する基準にはならない気がするよ。
>パンクズリストだって、表示から理解させるにはあの記号が必要だけど、マークアップ時にはいらないからね。

アホか。文書（文章）が伝達力失ったら本末転倒だろ。
パンくずリストのあの記号って何だ？俺に伝わらない時点でお前の言ってる何かは明らかに付加物。
olでマークアップしたら階層を表してはいる、とか過去ログ読めよ。

884 ：880：04/09/30 19:00:52 ID:???

>ところで装飾か否かはどう判断するのが理想なんだ？
　そのtextに「意味が有る」なら内容。無いなら装飾。
　理想とかじゃなくて、極めてシンプル。

とりあえず、「仕様に基づいて最低限の処理しかしない UA」というのを考えてみて、
その時に「取り除いたら文章の意味が変質してしまうならHTMLにtextとして残す」
「取り除いても文章の意味が変質しない場合は装飾として CSS などに任す」と言うのが
わかりやすい解釈かと。

ただし、強調の為の括弧、引用の為の > などは「強調ならemかstrong」「引用なら q か blockquote」
と「意味の付け方が HTML の仕様ではっきり決まっている」ので、逆に括弧が強調だったり、
> が引用符であることは「HTML的には有り得ない」ので、こういうものは全て即装飾と
判断される。

885 ：878：04/09/30 19:36:59 ID:???

>>883
なんかな・・・普通に会話できない人なの？なんかそういうのうんざりだよ。

英文については単語専用の要素がないだけでしょ。

>俺に伝わらない時点でお前の言ってる何かは明らかに付加物。
そんなこといったら伝わらなければ何でも付加物じゃん。

とりあえずもういいや。アホとかいう人と話してもいい気分しないし。

>>884
>　そのtextに「意味が有る」なら内容。無いなら装飾。
>　理想とかじゃなくて、極めてシンプル。

違うと思うよ。例えば２ちゃんでは「>」は引用としての意味を持ってるけど、
HTMLでは当然装飾物として分類されるからCSSでやることを推奨されるよね。
ってうか後の方の文で説明してるのね；

やっぱシンプルではないよね。
多分HTMLの仕様によって装飾となるかは変わるんだよね。おかしな話だけど。
２ちゃんでの「>」これも、もしもHTMLに引用を表す要素がなければ段落などの
中に直接「>」などの記号を書いてもおかしくはないと思う。

なんかややこしい。

886 ：883：04/09/30 19:50:06 ID:???

>>885
なんかな・・・普通に過去ログ読めない人なの？なんかそういうのうんざりだよ。

単語ひとつひとつをアホみたいにちまちまマークアップしろって？
そりゃ究極的な言語マークアップ言語（すげえ日本語）があればそうだろうが、
それはHTMLの役割じゃないな。というのも散々既出の話題だな。

> >俺に伝わらない時点でお前の言ってる何かは明らかに付加物。
> そんなこといったら伝わらなければ何でも付加物じゃん。

お前本当に頭悪いのな。
とりあえずパンくずリストに必要不可欠な記号があるんだったらそれを教えてくれ。

> ２ちゃんでの「>」これも、もしもHTMLに引用を表す要素がなければ段落などの
> 中に直接「>」などの記号を書いてもおかしくはないと思う。

HTMLには引用を表す要素がありますよね。あるから装飾扱いしてるわけですよね。
そういう要素があるから装飾扱いしてるのに「要素なかったら装飾じゃない」って本末転倒ですよね。
慣習と仕様と構造化をもうちょっと考えた方がいいと思うよ。
あと何の話してるか、とか、スレタイとかちゃんと読んだ方がいいと思うよ。

> なんかややこしい。

それはお前の（ry

887 ：883：04/09/30 19:54:52 ID:???

例えば以下のような構造をパンくずリストにすることを考える。
1. 2ch
2. ネット関係
3. Web制作

暫定的に「＞」をパンくずリストに必要不可欠な記号とすると、

2ch ＞ネット関係＞ Web制作

これが>>878の言う「表示から理解させる」パンくずリスト。
じゃ例えば以下のようにCSSなり何なりで表示させたら、それは全く意味を理解できないか？

2ch : ネット関係 : Web制作
2ch -> ネット関係 -> Web制作
2ch ◆ ネット関係 ◆ Web制作
2ch ネット関係 Web制作

わかりづらい例だが過去ログ嫁、とりあえず。

888 ：Name_Not_Found：04/09/30 20:25:39 ID:???

そうだ！過去ログが正しい！過去に結論の出たものは再検討してはならない！

889 ：Name_Not_Found：04/09/30 20:29:30 ID:???

>>888
釣れますか？

890 ：Name_Not_Found：04/09/30 20:30:11 ID:???

>>888
というか過去に出た物をまとめといて欲しい…

891 ：878：04/09/30 21:01:48 ID:???

>>887
ごめん論点ずれてるし。俺は過去にパンクズのマークアップ例を2,300レス使って議論したときの
当事者だし。とにかく君はもうレスをつけないでいいよ。

892 ：Name_Not_Found：04/09/30 21:11:36 ID:???

<p><単語>I</単語><単語>like</単語><単語>your</単語><単語>smile</単語>.</p>

<p>I like your smile.</p>

個人的には嫌いじゃないけれど、スペースが装飾だとか、ピリオドがどうだとかの論議はナンセンスだと思われ。
かぎかっこの話に付いては、興味深い。小説をHTMLに起こしている者としては。

893 ：Name_Not_Found：04/09/30 21:12:02 ID:???

>>887
＞それはHTMLの役割じゃないな。というのも散々既出の話題だな。
横槍すまんが、おまいが言うにはどっかに線が引いてあって、その線が見えてない人間には
適切な構造化はできないってことになるがそれでいいか？

記号などはどっから
＞HTMLの役割じゃないな
になるんだ？ずいぶんあいまいな話になってきたな。

>>891
よくわからんが一連の流れをみる限りお前は２ちゃんに向いていない。帰れ。
ここは相手を馬鹿にしてでしか自分を確立できないような幼稚なやつらの居場所だから
上品な会話をしたいなら他の掲示板でも探せ。

894 ：878：04/09/30 21:15:11 ID:???

>>892
>個人的には嫌いじゃないけれど、スペースが装飾だとか、ピリオドがどうだとかの論議はナンセンスだと思われ。
元々そういう話でなくて、論点はどこからが装飾なのかってこと。
その中の話でたまたま英文のスペースやパンクズの記号が出てきてるだけ。

とりあえずはっきりとここから装飾ですっていうのがないんだよね。

895 ：Name_Not_Found：04/09/30 21:15:47 ID:???

みんな帰れ！

896 ：Name_Not_Found：04/09/30 21:18:19 ID:???

正直お前らかなりの暇人だろ。
現実世界で何の役にも立たない話を延々しやがってｗ

軽く池沼だよなお前ら。
記号なんて直接書き込んだってデメリットは大してないのに、こうやって
ここで議論をして時間をつぶすこと方がよほどデメリットだってことには気づかないわけ？

まさにヲタクって言葉がぴったりだなお前らｗ
もう少しマシなことに時間を使えよｗ

897 ：Name_Not_Found：04/09/30 21:20:09 ID:???

みんな帰れ！

898 ：あがさクリスピー：04/09/30 21:22:47 ID:???

そして誰もいなくなっ

899 ：Name_Not_Found：04/09/30 21:24:54 ID:???

>>895 >>897
素朴な疑問なのだが、どうして自分が帰ることでの解決をしようとは思わないのだ？
２ちゃんしかやることないから？いや、別にこのスレにしがみつく理由はないだろう。
で、何故にお前は帰ろうとしないの？

900 ：Name_Not_Found：04/09/30 21:32:32 ID:???

>>896
そもそも2chって、暇な時にどーでもいいこと書いたり読んだりして
暇つぶすところだろ？

お前、パチンコ屋に入って、パチンコ打ってる客に向かって
「お前らかなりの暇人だろ。現実世界で何の役にも立たない事を延々しやがって」
って叫ぶタイプか？

901 ：Name_Not_Found：04/09/30 21:35:14 ID:???

まーだ帰っとらんのか　下校時間とっくに過ぎてるぞ

902 ：Name_Not_Found：04/09/30 21:47:44 ID:???

あ、あたし……、実は先生のこと……。

903 ：Name_Not_Found：04/09/30 23:08:42 ID:???

「やべっ、筆箱忘れちまった。」
ガラッ
「あっ・・・・。」

904 ：Name_Not_Found：04/09/30 23:16:23 ID:???

>>900
こういうやつを馬鹿って言うんだろうな。

905 ：883：04/10/01 00:59:35 ID:???

>>891
で、パンくずに必要な記号ってのはどれなんだよ。

>>893
線の有無の話なんてしたっけ？HTMLだけで意味が通じなかったらアウトとは出てるが。
クエスチョンマークがなけりゃ疑問文として成り立たない、という文法なら記号はHTMLに書くべき、
クエスチョンマークはそのような意味を持たず疑問の程度を強調するならstrongなりemなりで。
単語全部マークアップしたいやつは新しい言語作れってのは何度か出たように思うが。

>>894
英単語の半角スペースを付加してくれる親切なUAがないと読めないソースってのはどうかっていう。
スペースやぱんクズの記号が出てきてるだけ、ってのはお前の発言に拠るんだが……。

906 ：Name_Not_Found：04/10/01 01:03:07 ID:???

ここでもっとstrictな共通マークアップを作ればいい
xhtmlなら独自の名前空間も使えるし

907 ：Name_Not_Found：04/10/01 07:53:10 ID:???

まあ、(X)HTMLにない語彙を考えるなら、他の専用スレでやったほうがいいかもね。
しかし彼らは (何故だか) HTML語彙セットに執着するからこそ
ストリクターだったりするわけで…

908 ：Name_Not_Found：04/10/01 11:33:32 ID:???

HTMLは手で掛けることを念頭に設計されているからwordとかまで
区切ると本来の設計から外れるな。

RDF見たいに気合いを入れれば、適当だけど、
<s class="俺">
<v class="食べる">
<c class="ご飯">
<gohan:umasa>うまい</gohan:umasa>
</c>
</v>
</s>
見たいに書いて、UAが「俺はうまいご飯を食べる。」とか表示してくれれば楽だな。
ここまで構造化すると記号は必要なくなりそうだね。

つーかさ、XHTML2.0のquote要素まずくない？
ダブルクオーションを自分で書け、ってものすごく流れから外れてる気がする。

>>905
その理由付けだと「p要素で改行してくれる親切なUAがないと読めないソースは・・・」
になる。やりすぎだ、って言いたいんだろうけど。

909 ：Name_Not_Found：04/10/01 11:55:20 ID:???

XHTML 1.1 な人は
Content-type: application/xhtml+xml
にしてますか?

910 ：Name_Not_Found：04/10/01 11:59:37 ID:???

はい。

911 ：908：04/10/01 12:02:14 ID:???

どうでもいいけど、cじゃなくてoだった。

>>909
PHPで振り分けてる。

912 ：Name_Not_Found：04/10/01 12:04:53 ID:???

>>908
>HTMLは手で掛けることを念頭に設計されているから
HTML が text/html っていみならそうなんだろうな。
text/html の構造を保ちつつ noteで Application/xhtml-xml 推奨な
XHTML1.1 はそう言う意味では過渡的な存在と言えるかも知れない。

>ダブルクオーションを自分で書け、ってものすごく流れから外れてる気がする。
続きを良く読め。

少なくとも 2003年12月22日の草案では
>It is the responsibility of the document author to add any required quotation marks,
> either directly in the text, or via a stylesheet.

仕様はquote要素の引用符に関して、作者が直接記述するか、スタイルシートで
処理するから「UAはデフォルトで余計なことをすんな」と言ってるに過ぎない。

913 ：912：04/10/01 12:06:26 ID:???

>2003年12月22日の草案では
18日だよ……orz

914 ：908：04/10/01 12:11:26 ID:???

>>908
あー、ほんとだ。ちゃんと読んでなかったよ、すまん。
言語によって引用の表現方法って結構差があるから
下手にデフォルト決めない方がいいのかもね。

915 ：Name_Not_Found：04/10/01 15:09:15 ID:???

ちょっと質問。
ttp://hp.xrea.jp/m/link/15.html
にあるパス制限なんだが、普通に入力すると
ttp://hp.xrea.jp/m/link/15.html?pass=test
ってなるだけでページが変わらないのは俺だけ？
そして何故かtestをコピペでテキストボックスに貼り付けると移動できるんだが。
ﾊﾞｶな俺にｴﾛｲ人、理由を教えてくれ。

916 ：915：04/10/01 15:10:22 ID:???

言い忘れたがブラウザはIE6SP1。

917 ：Name_Not_Found：04/10/01 15:14:32 ID:???

>>915
http://pc5.2ch.net/test/read.cgi/hp/1096024561/

918 ：Name_Not_Found：04/10/01 19:03:22 ID:???

>>905

>線の有無の話なんてしたっけ？HTMLだけで意味が通じなかったらアウトとは出てるが。
>クエスチョンマークがなけりゃ疑問文として成り立たない、という文法なら記号はHTMLに書くべき、

?も装飾だとも考えられるよ。例えば<疑問文>こんな要素があればあきらかに？は装飾だよね。

ってその後の流れみたらもう話は終ってるのね；すまん。
結局
１．HTMLにある要素で伝えられる
２．その記号をなしでHTMLだけで読んでも伝わるかどうか
ん？なんかイマイチだな。誰か漏れのために簡単にまとめてよ。箇条書きで。

しかしあれだなぱんくずなんかは
<hn>ここまでの道順</hn>
<ol>
<li>home
<li>chapter
<li><strong>sction</strong>
</ol>

これをCSSで整形して
HOME > Chapter > Section
なんてのがstrictだけど、整形前は本当にパンクズリストだといえるのかね？
整形前はただの道順で、整形してやっとパンクズリストになるような肝するけどおかしい？

まあtopic pathなら別にいつでもtopic pathだけど、パンクズリストって見栄えありきだったりしない？

まあ読み返してみたらアホなこといってるねｗｗｗ
整形前後いつでもぱんくずだったわｗｗｗごめん。

919 ：Name_Not_Found：04/10/01 19:15:31 ID:???

疑問文の末尾に？をつけたり、命令文の末尾に！をつけるのは
英文法なわけで、装飾ではない罠。

920 ：Name_Not_Found：04/10/01 20:25:11 ID:???

本来のstrictは記号も装飾、助詞も装飾、もっともっと装飾にしていくといったい何が残るだろう…

921 ：Name_Not_Found：04/10/01 20:29:39 ID:???

物自体。

922 ：Name_Not_Found：04/10/01 22:03:02 ID:???

やったな哲学の世界に突入だ。

923 ：Name_Not_Found：04/10/01 22:07:46 ID:???

>>919
どこにも英文法での話とは書いてないわな

924 ：Name_Not_Found：04/10/01 22:12:33 ID:???

>>919
英語はよく知らないけど、?は明らかに表示のレベルだと思うよ。
読み上げる時には？なんて出てこないでしょ。語尾を上げるとか。それって
まさに<疑問>要素ってことで？は就職じゃん。

極論を言えば～要素にできないものが本体で、要素にできてしまうものは就職なんだよ。

925 ：Name_Not_Found：04/10/01 22:16:22 ID:???

いや、英文法では!や?は文章上意味のあるもので、装飾のために付けているものじゃないよって言ってるんじゃない？
日本では英語が入ってくる前は！や？はなかったけど、今では日本でも
感嘆符や疑問符として意味のあるものになっているから、えー・・
よくわからんけど、！や？を甘く見るな！ってこと？

926 ：925：04/10/01 22:17:31 ID:???

>>925の最後の！や？がなかったら、意味が通じないですよね
だから、重要なんすよー

927 ：Name_Not_Found：04/10/01 22:45:56 ID:???

>>925-926
だから<疑問>要素があれば？はなくても機械に対して疑問文であることを伝えられるだろ。
というか疑問要素がなければ機械に対して構造を伝えれるのは無理だろ。
字句解析などしないんだからUAは。

StrictってUAに構造を伝えて、UAはそれをユーザに伝えるんだけど、ユーザに伝えるのは
UAの仕事で、俺達StrictorはUAに構造を示すことが仕事なのさ。
そんなStrictorにとって?はHTMLでは修飾であるわけさ。しかし現状では疑問要素がないので
しかたなく？を直接書き込んでるさ。しかたないさ。

（）←もちろん括弧も構造的意味をあらわしている場合がある。しかしStrictorは本来これを
divやspanで表現することでUAに何か違うぜこのまとまりは！ってことをUAに伝える。
しかしCSSの実装などで、しかたなく直接書き込むのさ。

俺みたいに最高のstrictorになると、記号などはすべて修飾でしかないことを知ってるのさ。

928 ：925：04/10/01 22:49:33 ID:???

>>927
勉強になります。

929 ：Name_Not_Found：04/10/01 22:50:15 ID:???

>>927
散々既出だが、それを言うと助詞やら人称やらもすべて装飾になる。
行き過ぎると言語自体も装飾になる。
それを究極のStrictと言う人もいるだろうがね。

930 ：Name_Not_Found：04/10/01 22:51:31 ID:???

お前らさ、HTMLは究極構造マークアップ言語ではなくあいまいなレベルなんだから、
どこから修飾かなんてものがハッキリと線引きできるわけないだろ。

何しろどこまでがStrictかって話しにもなってくる。そもそもHTML自体究極的な
見栄えと構造の分離についていける規格ではないんだから、その「どこまでがStrict」
もやはりあいまいだ。

つまりStrictなんてあいまいなもので、それこそStrictDTDに従うことだけが
指標になってくるんだよ。StrictDTDに従って見栄えに関する要素・属性さえ
使わなければ、ある程度の分離ができる。そのある程度の分離で十分なのさ。
まあ段落はP要素とかの基本は守るべきだがね。

931 ：Name_Not_Found：04/10/01 22:56:01 ID:???

つまり結論的には

１．こういうものは何でマークアップするべき？
２．こういうのはStrict志向的にどうなのでしょう？

１についてかんがえるのはいいけど、２について考える必要はないってことかな？
Strict志向など存在しない虚像ってことで、明確なStrictDTDだけが僕らの灯台ってことか。

932 ：Name_Not_Found：04/10/01 22:59:58 ID:???

あと仕様書にも従いたいね。

933 ：Name_Not_Found：04/10/01 23:06:43 ID:???

>>932
そうなんだが、
仕様書が広く解釈できるようにできてたりするんだなこれが

結局あいまいなのさ。単純なとこだけ守ってれば合格点出るよ。

934 ：Name_Not_Found：04/10/02 00:33:51 ID:???

>だから<疑問>要素があれば？はなくても機械に対して疑問文であることを伝えられるだろ。
>というか疑問要素がなければ機械に対して構造を伝えれるのは無理だろ。

font 要素が有ればフォントの色や大きさをUAに伝える事が出来るが、
StrictはUAにそんな情報を伝えたりはしない。

この思考方法では今あるStrictを説明できるかも知れないが、
strictなHTMLを書く指標にはならない。

935 ：Name_Not_Found：04/10/02 00:44:46 ID:???

じゃ疑問文は<疑問文>要素で l 要素のようにマークアップするべきか。
UA に疑問文であることを伝えてどうするつもりかは知らんが。

936 ：Name_Not_Found：04/10/02 00:58:36 ID:???

疑問ってのは構造じゃなくて文の意味だろ。
そんなのはUAに伝えなくていい。だから?はじかに書いてOK。

937 ：Name_Not_Found：04/10/02 01:13:38 ID:???

>>934
疑問要素は構造で、font要素は見栄えの情報だから違うでしょ。
いまいち言いたいことがわからないんけど。

>>935
そうだな。伝える意味はない。しかしその発想は見栄えから来てるよな。
構造を伝えることをHTMLの規格が嫌がるのならstrictは本末転倒。

>>936
強調は構造か？意味か？

938 ：Name_Not_Found：04/10/02 01:17:14 ID:???

おまいら深夜までごくろうさん。
結局究極でない言語で究極を目指すこと自体ナンセンス。っていってる930辺りがFAかな？
しかし930は文章が下手なやつだな。

939 ：Name_Not_Found：04/10/02 01:26:27 ID:???

今知ったけど、
b,small,big
って4.01strictに残ってるんだね。後方互換だろうけど、別になくてもこまらないと思うんだけどな。

940 ：Name_Not_Found：04/10/02 01:27:32 ID:???

>>939
なにおいまさら

941 ：Name_Not_Found：04/10/02 01:28:31 ID:???

>>940
なぁんだとぉ！

942 ：Name_Not_Found：04/10/02 01:34:03 ID:???

芯でいいよ

943 ：Name_Not_Found：04/10/02 01:41:19 ID:???

くぉら！ケンカはやめんか！

944 ：Name_Not_Found：04/10/02 01:42:31 ID:???

あ、あたし……、実は先生のこと……。

945 ：Name_Not_Found：04/10/02 01:45:59 ID:???

>>936が結論。

946 ：Name_Not_Found：04/10/02 01:46:06 ID:???

>>937の
伝える意味はない。 → その発想は見栄えから来てるよな。

この発想がよくわからんのだが誰か解説きぼん

947 ：Name_Not_Found：04/10/02 02:13:34 ID:???

strictorってなんだよ(ﾌﾟ

948 ：Name_Not_Found：04/10/02 02:29:04 ID:???

日本語のような、近年になって疑問符や感嘆符が用いられるように
なった文体には、<疑問>や<感嘆>のような要素があった方が
意味を伝達できる、と思いがちだけど。

html は文書の論理的構造を伝達すべきもので、文脈の意味を伝達するもの
じゃない。文脈はその言語を理解できる人間が脳内パースすべきもの、
と思う。

<strong>また大阪か！</strong>

は文章の構造だけど、

<感嘆>また大阪か！</感嘆>

は文章の意味に他ならない。

949 ：Name_Not_Found：04/10/02 09:45:48 ID:???

「論理的」という語を「意味がある」と説明して済ましちゃう言葉足らずな解説が多いから
この手の誤解がいつまでたってもなくならないんだろうな。

950 ：Name_Not_Found：04/10/02 11:56:28 ID:???

お前ら説明ヘタ。
何故に強調と疑問文が違うかを簡単に言ってやろう。

強調文
疑問文

これなら両方、文の意味になるな。

強調
疑問

は無理なので

強調
疑問文

結局部位を強調することは、文を強調するわけではないので、文の意味にはならず、
疑問文はどこまで言っても疑問文と言う文脈である。

な、わかったか。おまえら疑問を持つならもっと他にあるだろう。

951 ：Name_Not_Found：04/10/02 11:57:54 ID:???

>>949
じゃあお前が説明してみたら？

952 ：Name_Not_Found：04/10/02 13:58:05 ID:???

>>948
＞<strong>また大阪か！</strong>
＞は文章の構造だけど、

そのビックリマークは修飾だろ？強調したいならstrong要素でやる。ビックリマークは
CSSでやりなさい。実装のことなど関係ない。

953 ：Name_Not_Found：04/10/02 14:26:32 ID:???

なに事件か、<strong>また大阪か</strong>

strong:after { content:"！" }
　実際の表示 → なに事件か、また大阪か！

それにしても、<strong>また大阪</strong>で事件か

strong:after { content:"！" }
　実際の表示 → それにしても、また大阪！で事件か

感嘆符や疑問符は（ほぼ）必ず文末に付属するから、
セレクタが成長するか無駄なクラス付けするかしないと不自然だな。

954 ：Name_Not_Found：04/10/02 14:33:35 ID:???

あと、スタイルシートを読み込まなければ句点のない文章になるので、
「！」は句点の代わりもしているという意味で、装飾ではなくない？

955 ：Name_Not_Found：04/10/02 15:03:30 ID:???

>>953
クラスの使い方から勉強しなおしてこい。
それは無駄なクラスとは言わないんだよ。

>>954
句読点のつもりの記号ならそうだけど、強調のつもりのであればダメだから、
句読点はしっかり書いて、CSSでそれをビックリマークに変えるのがいいんじゃないか？
もちろん実現性などはこのスレとは無縁だ。

956 ：Name_Not_Found：04/10/02 15:06:18 ID:???

１．マジかよ！？
２．本当ですか・・・・・・
３．そんなorz
４．そんな＾＾；
５．馬鹿な！！！！！！！！！！！！！！

上から順番にマークアップをして、それぞれの記号の必要性について話そうよ！
久しぶりにあげるけどごめんね。

957 ：Name_Not_Found：04/10/02 15:09:45 ID:???

>>956
正しいマークアップは正しい日本語から。

958 ：Name_Not_Found：04/10/02 15:12:03 ID:???

>>957
それは違うだろ。

959 ：Name_Not_Found：04/10/02 15:12:56 ID:???

>>957
三点リーダは二回繰り返したほうがいいんですか？「……」みたいに。
また、三点リーダのあとに句読点は必要ですか？

960 ：Name_Not_Found：04/10/02 15:14:25 ID:???

>>956
全部記号は必要なんじゃない？
1,5はstrongとかで強調ね。他はそのまま文の一部でいいんじゃない？

2は特に読む時にも
「hogehogeてんてんてん」
ってよむから必要だしね。

961 ：Name_Not_Found：04/10/02 15:15:55 ID:???

>>958
いや、まずは正しい日本語をベースにマークアップを考えたほうがいいと思う。
スラング等はそのあとで。
ちなみに>>956の「本当ですか・・・・・・」の「・」は中黒（なかぐろ）なので使い方が間違っている。

962 ：Name_Not_Found：04/10/02 15:16:53 ID:???

三点リーダも装飾か。つくづくHTMLは小説・テキスト媒体として向かないと思い知らされるな。

963 ：Name_Not_Found：04/10/02 15:17:41 ID:???

その前に次スレを立てたらどうだ？

964 ：Name_Not_Found：04/10/02 15:19:54 ID:???

Strict な日本語について語るスレッドはここですか？
ところで>>1の文をコピペしたときに思ったんですが、
日本語と半角の英単語が混在する場合、
HTML側で英単語の前後に半角スペースを入れるべきなんですか？

965 ：Name_Not_Found：04/10/02 15:20:02 ID:???

>>961
しかし正しい日本語をマークアップするより、多少崩れたものをマークアップすることの
方が圧倒的に多いから、ためになるのはおかしな日本語のマークアップのようなきもするよ。

中黒と３点リーダは別なんだね。じゃあorzなども当然間違った使い方だよね。
orzは文の意味を表しているんだけど、どうするべきかな？

966 ：Name_Not_Found：04/10/02 15:22:02 ID:???

>>965
or2
↑こうするといいと思うよ。だれかがつっこんでくれるから。

967 ：Name_Not_Found：04/10/02 15:22:17 ID:???

極端なストリクターの論理に矛盾が生じそうな流れ

968 ：Name_Not_Found：04/10/02 15:23:55 ID:???

>>966
プリッケツ！プリッケツ！

969 ：Name_Not_Found：04/10/02 15:24:40 ID:???

なあ最近出てきた、「文の意味はHTMLに直接書くべき」っていう話はかなり納得できるんだけど、
記号などは全て文の意味であって、記号を含めて強調にしたりするんじゃないか？

つまり文の意味でない記号はないのだから不要な記号はない。
ってこれは文章内に記号を含める時の話。

パンクズなどに代表される構造をあらわしている記号は、やはりCSSでだね。
で、
１.構造をあらわす記号
２．文の意味である記号
の２極化ができたわけだ。めでたしめでたし。

970 ：Name_Not_Found：04/10/02 15:27:24 ID:???

orzなどは明らかに見栄えから考え出されてるのだけど、直接かいていいの？
まあ文字だって同じか。ただ、orzをひとつの象形文字だと解釈するUAがないのが悪いだけで。

やはりorzは直接かいていいんだな。

971 ：Name_Not_Found：04/10/02 15:28:51 ID:???

orzの読み方が浸透してないだけで、文字と同列だってのは前にも言わなかったか？

972 ：Name_Not_Found：04/10/02 15:29:58 ID:???

orzは？とかと同じだろ。
？も昔はorzのような扱いを受けていたよ。

973 ：Name_Not_Found：04/10/02 15:31:48 ID:???

>>962
じゃあHTMLは一体何に向いてるのよｗ
テキスト媒体に向かないのにHTMLってどんな勢いだよ！

974 ：Name_Not_Found：04/10/02 15:32:10 ID:???

（笑）も、句読点の代わりに使ってるよね。
ときどき、
～（笑）。
とか
～。（笑）
とかいうのを見かけるけど。少数派だと思うので虫。

975 ：Name_Not_Found：04/10/02 15:32:53 ID:???

>>973
HTMLは論文専用！

976 ：Name_Not_Found：04/10/02 15:34:45 ID:???

議論にのめり込む前に次スレ立てろ

977 ：Name_Not_Found：04/10/02 15:50:30 ID:???

次スレがなければ>>976が立てればいいじゃない。（ダリーアントワネット）

978 ：Name_Not_Found：04/10/02 16:49:55 ID:???

HTMLは過渡期に必要な言語なのよ。
物自体というか、概念を自然言語の文字による文章に変換した時点で、
どうやっても見た目と概念の分離が難しくなる。
極端な話、日本語の文章は英語に変換できないし。

RDFみたいに文章の構造、意味を抽象化して記述していく技術が進歩すれば、
全て解決するんだろうけど、現状じゃ入力するのが大変で実用的じゃないんだよね。
脳みそで考えるだけで入力できる機械が出来ればそのうち・・・。

979 ：Name_Not_Found：04/10/02 17:13:14 ID:???

>>975
お前馬鹿だろ？
テキスト媒体に向かないのに論文ってどんな勢いだよ！

そもそも論文用じゃないからHTMLは。アホな解釈を披露するなよ。

980 ：Name_Not_Found：04/10/02 17:36:35 ID:???

>>978
>HTMLは過渡期に必要な言語なのよ。
なんの過渡期だよ？

981 ：Name_Not_Found：04/10/02 18:17:03 ID:???

画像にリンクを張った場合、
画像のaltに説明を書くのか、リンクのtitleに書くのかどっちがいいんですか。

982 ：Name_Not_Found：04/10/02 18:40:14 ID:???

>>980
文章後半へのだろ。

>>981
altは代替テキストだから書いちゃダメだよ。
imgのtitleかaのtitleか、だったら、ケースバイケース

<a href="hoge.png" title="スクリーンショットをフルサイズで表示">
　　<img src="hoge_small.png" alt="スクリーンショットその1" title="インストール中の画面はこんな感じ"/>
</a>

みたいな感じかなぁ。imgのaltとtitleの使い分けは
http://www.mozilla.gr.jp/standards/webtips0024.html
を参考にどうぞ。

983 ：Name_Not_Found：04/10/02 18:50:16 ID:???

やれやれ。
上の方に戻るけど、疑問や感嘆にマークアップがあれば読み上げUAはその様に読み上げてくれる。
orzも見栄え。
UAに落ち込んでるように読ませることができる。
#後は感情を理解するような謎プログラムとかそういうのに有効だと思われ。
意味付けとはそういうUAに意味を分からせる物なのに。

984 ：981：04/10/02 18:55:40 ID:???

>>982
ありがとうございます。すっきりしました。

985 ：Name_Not_Found：04/10/02 19:00:30 ID:???

つまり、全ての基準は「伺か」が自分の思い通りに
しゃべってくれるか、ということか。

986 ：Name_Not_Found：04/10/02 19:12:38 ID:???

>>982
あほだろお前

987 ：Name_Not_Found：04/10/02 19:17:43 ID:???

>>983
だから疑問文や感嘆文は構造じゃないって言ってるじゃない。
orzも疑問符や感嘆符と同じだから、当然HTMLに書くべきもの。

HTMLの脳内解釈はやめれよ。

988 ：Name_Not_Found：04/10/02 19:44:14 ID:???

文法に関する文章の構造と、文章の単位としての文書構造の違いだな。
HTMLが一切前者に関与しないとまでは言わないが、主たるマークアップの目的は後者の筈。

989 ：Name_Not_Found：04/10/02 20:31:50 ID:???

書き手の気持ちは意味ないといってるなら書き手の意見の部分とかはどうなるのさとか言ってみる。

990 ：Name_Not_Found：04/10/02 20:38:39 ID:???

フォントを赤くして強調とか、感嘆といった意味を込めるのと、
感嘆符をつかって意味を込めるのにどれだけ差があるのか。
自然言語の場合、何百年もプレーンテキストのみでの表現が普通であり
「！」という文字そのものにメタ的意味合いを含めて表現することを編み出したのだが、
近年は視覚的にリッチな表現が可能になったので「で赤くすること」によっても
表現が可能になった。

「機械でも分かる」という意味では感嘆符の使用は好まれないのかも知れないが、
そこまでやるならHTML以外の言語を作れという話。
（文脈を正確に解析できる機械があれば別だが、それだとHTML自体必要なくなるかも）

991 ：Name_Not_Found：04/10/02 21:12:00 ID:???

>フォントを赤くして強調とか、感嘆といった意味を込めるのと、
>感嘆符をつかって意味を込めるのにどれだけ差があるのか。
モノクロモニタなので赤い字は再現されないが、
フォントが表示できる場合、感嘆符の表示はほぼされるであろうといえる。

>近年は視覚的にリッチな表現が可能になったので「で赤くすること」によっても
>表現が可能になった。
HTMLはプアーな環境でも最低限の意味付けを失わず、リッチな環境では
CSS等によってリッチな環境を提供する規格

>「機械でも分かる」という意味では感嘆符の使用は好まれないのかも知れないが、
>そこまでやるならHTML以外の言語を作れという話。
結論には同意するが、なんか上下で文章の趣旨がずれてないか?

992 ：Name_Not_Found：04/10/02 21:23:17 ID:???

>>986
>>982の解説間違ってる？気になるんだけども。
否定するときは理由も書いてほしいな。

993 ：Name_Not_Found：04/10/02 21:23:45 ID:???

なんでoとrとzの羅列と、エクスクラメーションマークやクエスチョンマークが同列視されてるのかがかなり疑問。

994 ：Name_Not_Found：04/10/02 21:36:46 ID:???

orzをu(you)やplz(please)などのスラングや略語とみなすのは無理？

995 ：Name_Not_Found：04/10/02 21:53:25 ID:???

>>994
orzっておかしいだろ。
字間を広げてて o r z　とかなってたら視覚的にも全く意味わからないし
縦書きで表示された場合、
o
r
z
となってるだけで、無意味。

HTML上では「oの次にrがあり、その次にzがある」と言う情報しか存在しない（縦書きだろうが横書きだろうが、そんなものはUAの仕事）が、
「左から右に記述され、文字間隔がそれなりに狭い」と言う環境でしか意味をなさないものがテキストと呼べるはずがない。

996 ：Name_Not_Found：04/10/02 22:10:14 ID:???

>>995
なんで分解するのさ。だったら、pleaseも分解して逆から書いたら意味が通じないジャン
esaelp

ところで、文章の方向を明示的に表すのがHTMLの属性としてあるけど、
これはcssの役割じゃなくていいの？

997 ：Name_Not_Found：04/10/02 22:11:20 ID:???

>>996
文章データの解析方向を明示してるだけで、見た目をどうこうってわけじゃぁない

998 ：Name_Not_Found：04/10/02 22:14:40 ID:???

日本語での横書き左から右にした人は偉いと思う。
右から左のままだと色々面倒なことになってそうな予感。

999 ：Name_Not_Found：04/10/02 22:17:03 ID:???

むしろ縦書きが、右から左に行くってのがいやだった。
手が汚れるし、今まで書いた文章を確認するのに、手を止めてどかさないといけない。

このすれとまったく関係ないけど。

1000 ：999：04/10/02 22:20:11 ID:???

スレッド立てられなかったので、だれか新スレよろしくです。

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。