Strict-HTML スレッド 3.0 (W2C Recommendation)

1 ：Name_Not_Found：02/02/16 09:10 ID:ztcqhWxh

Strict な HTML(*) について語るスレッド Version 3.0
W3C 信者もそうじゃない人も投稿歓迎。関連スレ等は >>2-4 あたり

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

■過去ログ
1.0　http://pc.2ch.net/hp/kako/992/992708594.html
2.0　http://pc.2ch.net/test/read.cgi/hp/1008380243/-100

2 ：Name_Not_Found：02/02/16 09:12 ID:ztcqhWxh

■関連スレ
/* CSS、スタイルシート質問スレッド【6】 */ http://pc.2ch.net/test/read.cgi/hp/1011358982/l50
XML、XHTMLについて語り合うスレッド http://pc.2ch.net/hp/kako/1002/10024/1002461949.html
W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html

■勧告等
HTML 4.01 http://www.w3.org/TR/html401/
XHTML 1.0 http://www.w3.org/TR/xhtml1/
XHTML Basic http://www.w3.org/TR/xhtml-basic/
XHTML 1.1 http://www.w3.org/TR/xhtml11/
ISO/IEC 15445 (ISO-HTML) http://woodworm.cs.uml.edu/~rprice/15445/15445.html
JIS X 4156 (JIS-HTML) http://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳など http://www.doraneko.org/webauth/

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

3 ：Name_Not_Found：02/02/16 17:54 ID:FIyYhwGA

>>1
乙かれー。

4 ：悩み中：02/02/16 18:51 ID:+KQemnVb

text-aligm:-moz-center
つかってもstrictだって認めてくれる？

5 ：Name_Not_Found：02/02/16 19:09 ID:mABxwcbw

>>4
駄目

6 ：Name_Not_Found：02/02/16 19:21 ID:FIyYhwGA

>>4
CSSの仕組みがよく分からないので何とも。
というか、スタイルシートにStrictという概念はないのでは？

7 ：悩み中：02/02/16 19:45 ID:+KQemnVb

知り合いに
<table style="text-align:-moz-center;"

というふうにhtmlにいれるとstrictさのかけらもない。
とか言われたので・・。

8 ：198 ◆LwV2Z.QU ：02/02/16 19:49 ID:mJlUB0G1

>>4
mozillaだからね。
うーん、でも真ん中寄せって完璧に実装されてないんだよね。
今のところ。
margin-left:auto;
margin-right:auto;
も対応UA少ないし。
まぁ、CSSだから<div align="center">よりかはstrictよりじゃないでしょうか。

9 ：Name_Not_Found：02/02/16 20:33 ID:0VyQi/Cp

>>7
外部シートにしろってことでないの？
属性は1.1で非推奨だから。

10 ：Name_Not_Found：02/02/16 22:35 ID:mABxwcbw

*
* <body>
* <div align="center">
* <table width="575" border="0" cellpadding="0" cellspacing="0" SUMMARY="トップロゴ、カウンター">
* <tr>
* <td valign="top" colspan="2">　</td>
* </tr>
* <tr>
* <td valign="top" class="t1">
* <p>なんとかテーブル完成</p>
* <p>全てスタイルシートで定義…自由度がないっつーか、わけわからん</p>
* </td>
* <td valign="top" class="tx0">----------------------<br>
* Since 2002.02.16<br>
* カウンター<br>
* ---------------------- </td>
* </tr>
* </table>
* </div>
* </body>

DIVのALIGNが使えないんですが、テーブルをセンターに持っていくにはどうしたらいいでしょうか？
テーブルサイズ等はわけることが出来たんですが…わかりません

11 ：Name_Not_Found：02/02/16 23:06 ID:S/DJn/1C

>>10
テーブルは本来の意味である表以外に使わないようにしましょう。
ハイ解決。

12 ：Name_Not_Found：02/02/16 23:31 ID:FIyYhwGA

＞全てスタイルシートで定義…自由度がないっつーか、わけわからん

多分まだ HTML の使い方が理解できていないものと思われ(煽りじゃなく)。
ごく簡単なHTMLの説明 http://kanzaki.com/docs/htminfo.html あたりに
目を通すことをお薦めします。スタイルシートはそれから。

13 ：Name_Not_Found：02/02/16 23:31 ID:mABxwcbw

>>11
このようにやることを言ってるのですか？
私はW3Cの考え方なんて糞ほどにも思ってなく、ようするにより多くのブラウザに対応させたいだけです。ですから使えるなら使おうかと。
divをCSSで定義したら出来ました。こんなのに気づかないって事は馬鹿なんでしょうね

14 ：13：02/02/16 23:33 ID:mABxwcbw

＞このようにやることを言ってるのですか？
ttp://www.skipup.com/~l-_-l/web/
リンク貼り忘れた…

15 ：武蔵：02/02/16 23:39 ID:SFy1yiOW

>>13
＞私はW3Cの考え方なんて糞ほどにも思ってなく、ようするにより多くのブラウザに対応させたいだけです。ですから使えるなら使おうかと。

ならスレ違いだ。お門違いにもほどがある。

16 ：Name_Not_Found：02/02/16 23:42 ID:6S+nNYGR

>13

あなたのページは重くて読めません。また、携帯端末からも、
読み上げブラウザからもきちんと解釈されません。

17 ：12：02/02/17 00:08 ID:b/zZhvOp

＞私はW3Cの考え方なんて糞ほどにも思ってなく、
＞ようするにより多くのブラウザに対応させたいだけです。

だったらわざわざスタイルシートを使う必要はないと思われ。
何をしたいのか分からん。取り敢えずスレ違い。

>>16
別に必ずそうなる訳じゃないんだから、不要な煽りは入れない方が賢いよ。
>>13のページを見た訳でもないだろうに。

18 ：Name_Not_Found：02/02/17 00:38 ID:Ekg4nonQ

気に障ったようで…
スレ違いのようなのでCSSスレで聞いてきます。

19 ：Name_Not_Found：02/02/17 02:03 ID:a/9JICmK

>>18
ﾄｯﾄﾄ（・∀・）ｳｾﾛ!

20 ：Name_Not_Found：02/02/17 02:10 ID:a/9JICmK

＞私はW3Cの考え方なんて糞ほどにも思ってなく、ようするにより多くのブラウザに対応させたいだけです。ですから使えるなら使おうかと。
一番より多くのブラウザで表示出来るのが「W3Cの考え方」です。

つか別にTransitionalな人でもW3C信者でなくても関係ないが
なるたけStrictに近づけようと思ってる人じゃなきゃお門違いだと思われ。

21 ：12：02/02/17 03:11 ID:HkqpLasw

>>20
それは理想論であって、現状では実際に
「一番より多くのブラウザで表示出来る」わけではありません。(例えばCSS)
一応その辺りはシビアに自戒しておいた方が良いと思います。

W3Cの考え方を尊重すれば「一番より多くのブラウザで表示出来る」ように
なってしかるべきなのは勿論ですけどね。

22 ： ◆HTML/.Kg ：02/02/17 08:21 ID:KpuqvSdu

>>21
「一番より多くの『UAが期待通り拾うことが』出来る」と思います。
というか>>20が言っているのはHTML上の話なのでは・・・＞W3Cの考え方
そうなのであれば実際「一番より多くのブラウザで表示出来る」とも思う。

23 ：Name_Not_Found：02/02/17 10:45 ID:tYtVLNlk

XHTML2.0のどこが多くのブラウザで表示できるんだよ。
寝言は寝てから言え。

24 ：茶文字 ◆xELvisFU ：02/02/17 11:06 ID:Ii+E8nPY

>>23
新しい仕様ってのは現行のブラウザにとって努力目標だろ？
仕様を公開したからってすぐに対応した製品が出るとは限らないぢゃん。
X-BOXが発売と同時にPS2と同じだけのソフトをそろえられる保証があるのか？
寝言は起きる前に言え。

25 ：Name_Not_Found：02/02/17 11:27 ID:HkqpLasw

>>24
？　だから現状ではって話でしょ。
このスレの住人は否定的な意見が出ると過剰反応するきらいがある。
またーりしましょうよ。

26 ：Name_Not_Found：02/02/17 11:35 ID:TSxmOa5y

>XHTML2.0のどこが多くのブラウザで表示できるんだよ。

最近の勧告は後方互換性を置いてけぼりにしがちって意味では同意。

27 ：Name_Not_Found：02/02/17 11:40 ID:KpuqvSdu

現状の話ならXHTML1.1が勧告なのだから
それを基に話をすればいいのに
>>23が2.0とか言い出すからややこしく・・・。

28 ：Name_Not_Found：02/02/17 11:45 ID:HkqpLasw

>>26
そんなことないと思うけど。
寧ろ大きな変更は今のうちに済ませてしまう方が賢いと思うYO!

つーか最近の勧告で後方互換に問題があるのってどの辺よ？
ブラウザのバグは抜きにしてだぞ。
HTML 4.01 → XHTML 1.1 には殆ど問題はない。

・lang 属性が廃止されて xml:lang 属性になった。
・a 要素型の name 属性が廃止に。でも id は HTML 4.01 から使える。
・applet 要素型が廃止。これは比較的大きいかな。

こんなもんじゃないの？

29 ：茶文字 ◆xELvisFU ：02/02/17 11:52 ID:Ii+E8nPY

ムキになろうにもXHTML文書を書いたことがないんだが（ｗ

とりあえず>>27あたりが落としどころとして妥当だと思う。

30 ：Name_Not_Found：02/02/17 13:08 ID:V/T657qy

<h1><a name="2ch">２ちゃんねる</a></h1>

そういわれてみればこうゆうa要素はソースを汚すな。
<h1 id="two-ch">２ちゃんねる</h1>
のほうがいい。だから廃止？aのname。

31 ：名無しさん：02/02/17 13:59 ID:9U5cZuQQ

Strict だと何が嬉しいか、実例を伴った解説が少ないから
いけないんじゃないかな。

音声ブラウザのこと引合にだす記事も多いけど、
実際にその機能を実装してる UA はどこにあるの？
ってなると何も書いてなかったりするし。

それと、
理想がわからない人は使わなくていいです、
じゃ意味ないよね。

32 ：サ骨 ◆/IQ5000w ：02/02/17 14:45 ID:oLIMZgzP

>>31
掲示板のcgiが吐き出すHTMLがstrictならcssでデザイン弄り放題
とか

33 ： ◆HTML/.Kg ：02/02/17 16:20 ID:KpuqvSdu

>>31
自分がStrictにこだわるのは、
はマズイ事が少ないからだろうか。
フレーム未対応でも見られて、
音声読み上げもそれなりにできだろうし、
構造と内容さえ間違ってないなければ後で
書き直したりすることも無いし、
それによってCSSでのスタイルの
変更も容易にできる。

34 ：茶文字 ◆xELvisFU ：02/02/17 17:08 ID:Ii+E8nPY

StrictでなくてもCSSは使うんで、私の理由はCSSではないなぁ。
今HTML4.01のリファレンスを書いているので、自ソースから正しい記述にしたいと思うからかな。

これをやり始めたのにはまた理由があって、初心者にとって最初に学ぶべきなのは
もしかしたらStrictなのではないかと思い始めたから。
視覚的効果やレイアウトは後回しにして、まずは骨組みだけきちんと作れるようになること。
body内でいえば、pやhn、ol/ul/dlなどね。
そこだけ徹底してやれば、開始タグには対となる終了タグがあるってことや
見通しの持ちやすいソースの書き方も身につくと思うんだよね。

よりよいソースを書くためには、部分に着目しすぎて視野狭窄に陥らないこと。
これを知らない初心者が、いきなり細部にfontだのcenterだのをぶちこむから、
見通しの悪いソースになってHTMLいじりが楽しくなくなるんじゃないかと思ったわけ。

35 ：Name_Not_Found：02/02/17 17:08 ID:J5fWhlaa

>理想がわからない人は使わなくていいです、
じゃ意味ないよね。
こういう奴には一番使ってほしくないね。こういうのは理想と関係なく自然と使うもんだ。意識しすぎるとかえって不自然なサイトになっちまう。

36 ：名無しさん：02/02/17 18:13 ID:9U5cZuQQ

うーん、じゃあ質問を変えて、

デザインとコンテンツの分離をしてなにが嬉しいか？
を、具体例をあげて説明する方法でも考えましょうか。

デザインに凝りたがってる人が対象です。
果して css の非互換性やバグに立ち向かうだけのメリットを提示だろうか？
ってとこで。

>>32
個人的には、始めから吐き出す HTML 自体弄らせろやって感じもします :-)

>>33
見た目が先にきちゃう場合、
Strict + CSS だとマズイ事だらけになっちゃいますよね。
そこらへんの論点の相違があるんだと思います。

>>34
その、初心者は最初に Strict から学ぶべきである、
の理由をクリアに説明出来たらいいのかもしれないです。

あるいみ、Curl あたりが流行っちゃったほうが
分業出来ていいのかもとか思ってみたり。

37 ：名無しさん：02/02/17 18:15 ID:9U5cZuQQ

>提示だろうか？
提示出来るだろうか？

ですな。失礼。

38 ：茶文字 ◆xELvisFU ：02/02/17 19:08 ID:Ii+E8nPY

>>36
つまり34に書いたような理由を初心者に説明できるか？ってことかな。
今のところの方針としては、まず骨組みだけのStrictなソースを書けるようになってもらって、
能書きはそれからの方がいいかな、と。

とほほを熟読したからといってStrictに目覚めるとは限らない。
なぜなら、とほほ氏自身Strictにこだわりのない人だから。
そういう意味で氏を叩く人は多いが、とほほの値打ちは
　「他を圧倒するわかりやすさ」
にあると思う＜あくまでも初心者目線でね。
# もっとも、信頼の置ける古株としてのステータスが確立してしまったから、
# 単純に他サイトと比較するのも問題があると思うけど。

早い話が、Strictな書き方をとほほ以上のわかりやすさで説明できるかどうかだと思う。
初心者にとってはわかりやすさが最大のニーズだから。

……とか書きながら、いつも通り私のレスはちっとも「早い話」ぢゃないねぃ；

39 ：Name_Not_Found：02/02/17 19:44 ID:KInY5rQB

３１じゃないけどやっぱり答えになってない気がするよ

40 ：Name_Not_Found：02/02/17 20:51 ID:K3H3XjNT

>>39
Strictができた理由を知りたきゃ勉強しなよ
それを教えるスレじゃない
知ってる人間が参加するスレだろうが

41 ：Name_Not_Found：02/02/17 21:44 ID:D+UHPXoK

>>40
別に31や39が分かってない訳じゃなくて、その説明では入門者を啓蒙
できないだろう、ってことでしょ。
ちゃんとスレを読もうや。

42 ：Name_Not_Found：02/02/17 22:14 ID:LTsNS5hp

やっぱとほほにまさるStrict解説ページの作成か・・・。
概念の説明から入る辞典で敷居が高くて難しいYO!

43 ：Name_Not_Found：02/02/17 22:50 ID:yCaHNszP

>>42
内田さんの「はじめてのWebドキュメントづくり」じゃだめ？

自分にはNoz氏のサイトが分かりやすかった。
まず先に文章ありきで、文章はいくつかの要素から構成されるので、
それをUAにわかりやすいようにマークアップしていく、という説明。

44 ：名無しさん：02/02/17 23:01 ID:9U5cZuQQ

>>43
今見てみました。
>HTML は簡単だけどホームページは難しい
ってセリフがなんか好き。

最初に内容が来るってのが理想なんですよね。
でも初心者が HTML 始める動機って、
どっちかというとかっこいい見ためを表示するために中身を用意するって感じで。

で、私は Transitional な人を啓蒙するのに
代替スタイルシート使ってます。
目の前でパッパッパって切り替えたときはそれなりにインパクトありますし。

ただ、div-span 厨を生成しかねない両刃の剣。

45 ：Name_Not_Found：02/02/17 23:30 ID:4cigW97Y

サイト内の複数のページの見栄えを統一する（いっぺんに変える）のに便利、という
理由ではどうかな。

46 ：Name_Not_Found：02/02/17 23:44 ID:cGcU71Ea

パンくずリストのMarkupってリストでいいんでしょうかね？
それとも他にもっと最適なMarkupの仕方ってある？

47 ：Name_Not_Found：02/02/17 23:48 ID:unX7xUuX

olだろうなぁ・・・

48 ：Name_Not_Found：02/02/17 23:52 ID:2kymBeqJ

>47
漏れulなんすけど、ol要素にする利点を教えて下さい。

49 ：42：02/02/17 23:59 ID:2kymBeqJ

#sageてしまった

>45
ちいと本旨からはずれる気もするが、一般のサイト製作者を
釣るにはそこらへんが妥当なんだろうか？

でも、
>ただ、div-span 厨を生成しかねない両刃の剣。
で、論理不思議マークアップになれば元も子も。

内田さんのサイトを見ている途中。確かに説明がイイ。
ただこれは「ほーむぺーじ」を作りたい、といってる
連中(ex.gaiax系ページ）に読ませても(ﾟДﾟ)ﾊｧ? と言われるが
おちだろうなぁ。

# 某方面でも、そんな連中にまで啓蒙すな（むしろ作らすな）
# と言ってる過激な人が多いし

50 ：Name_Not_Found：02/02/18 00:03 ID:GSBPbvOI

>>48
パンくずリストは順番に意味があるから、
マーク付けするならolの方が適切だと思う。
ul（順不同リスト）じゃパンくずにならないよ。

51 ：42：02/02/18 00:07 ID:2m0xmRa4

>50
なるほど。ナビゲーションと混同してました。THX.
# 更に気付けば自分のサイトのbreadcrumbs。
# そんなにサイト構造を深くしていないからかえって邪魔だ鬱。

52 ：46：02/02/18 00:09 ID:8dlmutuj

>>47 >>50
ありがとございます。

>>48
私もulで書こうとしてました。
グッドタイミングなしつもんありがとう。

53 ：Name_Not_Found：02/02/18 00:14 ID:9E/SrdNB

>>46-48 >>50-51
パンくずリストって、
<Yahoo! より引用>
ホーム > コンピュータとインターネット > 情報、資料 > データ形式 > HTML >
</Yahoo! より引用>
みたいなものだよね。微妙にリストとは違うような。
自分の理解では、リストは同列のものを列挙するものなんだけど。

ちなみに自分は、<div class="navi"></div>で済ませてる。

54 ：Name_Not_Found：02/02/18 00:25 ID:MBikF9Nb

どうなんだろうなぁ。
カテゴリっていう意味では「情報、資料」も「HTML」も同じじゃない？
で、階層表すために順番付きリスト。ダメかな。

55 ： ◆HTML/.Kg ：02/02/18 00:33 ID:xfbVO3Zp

>>36
ごめんなさい。
＞見た目が先にきちゃう場合
というのが「自分には」理解不能なので
うまく回答できないのです。

というか、そもそも目的が違うんですよ。
単に「とりあえずややこしいこと抜きに作ってみたい」
とか「かっこいい、見てもらえるのがいい」
とかの理論もあるだろうから。＞初心者

いくらわかりやすく説明されてても、
WYSIWYGタイプの「楽」さには
ちょっとやそっとではかなわないかなと。
Strict界のカリスマサイトでもでてくれば・・・ね。

56 ： ◆HTML/.Kg ：02/02/18 00:39 ID:xfbVO3Zp

>>54
階層は階層であって順番ではないと思う。

>>55に付け足し。
HTML解説サイトのデザインがカスイケの
デザイン大賞上位ランクサイトの様に
見た目でも惹きつけることができれば、
そういうサイトが増えてくれば
今より少しは見る初心者も増えるかもね。
わりとベタで無難に、という感じを打破というか。

57 ：53：02/02/18 00:44 ID:9E/SrdNB

>>54
うむ。
感覚の違いなんだろうけど、この場合各項目は入れ子構造になってるわけで、
リストにするのは多少違和感を感じるな。否定はできないけど。

58 ：Name_Not_Found：02/02/18 00:53 ID:GSBPbvOI

>>56
デザインに凝ると（ゴテゴテでなくても）、反比例して1画面あたりのテキスト情報量はどんどん減っていきます・・・
上等な解説とCOOL（死語）なスタイルとはなかなか同居しづらいもので。

59 ：42：02/02/18 01:02 ID:2m0xmRa4

>56
とすると<table summary="breadcrumbs">か、それとも
<div title="breadcrumbs">でしょうか。ご教示下さい。

>58
同意。けど現状の解説サイトの中には“それ以前"のものが多数・・・
# お前が作れというツッコミはなし

60 ：Name_Not_Found：02/02/18 01:24 ID:C/odB82m

現在、XHTML1.1で拡張子をindex.htmlで運営してるんですけど、本来XHTMLの理想としている拡張子は.html、.xmlのどれでしょうか？
index.htmlの場合、トップがhttp://www.xxx.co.jp/だとして
次ページがhttp://www.xxx.co.jp/xxx/でアクセス出来るんです。
で、xmlにするとhttp://www.xxx.co.jp/index.xml
次ページがhttp://www.xxx.co.jp/xxx.xmlか http://www.xxx.co.jp/xxx/index.xmlになってしまいます。
アクセスの便利さから見ればhtmlの方が良いのかな？

61 ：茶文字 ◆xELvisFU ：02/02/18 01:26 ID:8TmZfmTG

はっきり言って大仕事になるわけだが、このスレ見てたら自分の考えてる方向性が
あながち間違いではないと思えるようになってきた。
どこまでできるかわかんないけど、せっかく作るんだからStrict界のカリスマを目指してみるか（ｗ

つか、カスイケの大家がStrictな解説サイトを作ってくれたら一番合理的な気が（ｗ

62 ： ◆HTML/.Kg ：02/02/18 01:26 ID:xfbVO3Zp

ん～、いや、>>56で、パンくずリストそのもののことを
言ったのではなくて、著者が階層として記述した内容なのなら
それはあくまでも階層ではないかと言ったまでです。

実は、パンくずリストについてよく知らなかったので調べたら、
あれは階層というより履歴としての意味が強いのじゃないかと。
履歴の意味が無ければ、例えばYAHOOの例なら
「情報、資料」と同じ階層の「WWW」や「雑誌@」なども
それこそul要素で全てマークアップしていくべきかと。

しかし、パンくずリストが一つづつしか記述しないのは
トップページから辿る時の期待される履歴だからなのであれば、
履歴という意味でolには出来ないことも無いだろうけれど、
似たようなことをlink要素ででもきる事をお忘れなく。
あぁ、でも階層としての内容を兼ね備えるならやっぱりリストかな。
ulをどんどんネストしていく、とかは無理やりっぽいな・・・。

63 ：茶文字 ◆xELvisFU ：02/02/18 01:34 ID:8TmZfmTG

>>60
そりは鯖の設定でどうにでもなるよ。
Apache鯖なら.htaccessでファイル名省略時の優先表示順を変更できる。
私は index.cgi -> index.shtml -> index.html の順で設定してる。
# 鯖によってはindex.htmでないと省略時に表示されないとこもあるのはこのため。

WebKANZAKIでは、拡張子のないファイルをtext/htmlで出力するよう設定することを勧めてる。
理由は、HTMLがいつまでも世界標準であるとは限らないから。
たとえば.xmlがデファクトスタンダードになったときに、
XMLで書いた同名ファイルで旧ファイルを上書きし、
鯖側で拡張子なしファイルをXMLとして出力するようにしてやればよい。

単にindex.html優先の設定をindex.xmlにするだけだと、ブックマークとかから
直接新しいファイルに飛べないという問題が生じるが、これを回避できるのがポイント。

64 ：茶文字 ◆xELvisFU ：02/02/18 01:39 ID:8TmZfmTG

>>62
パンくずリスト == 履歴というのは個人的にちと違和感があるかな。
アレはそれぞれの階層を相対的に示しているのであって、
たとえば検索エンジンから飛んできた人の場合、基準となる視点は現在閲覧虫のページだよね？
トップからたどられることを期待するのはかまわないけど、トップを基準に考えるのは
制作者側の視点だと思うわけ。
いきなり飛んできた人も迷子にならないようにするためのナビゲーションだとすると、
順序化されたolにはなじめないと思うんだけどいかが？

65 ：茶文字 ◆xELvisFU ：02/02/18 01:54 ID:8TmZfmTG

64を書いてから考え直してみたが、利用者は「今いる場所から2階層上のカテゴリーを
見てみよう」とか考えるわけかな。
だとすると、順序が存在するとも言えるか……。

dirをﾌｶｰﾂさせて階層構造をきちんとマークアップできるようにするってのはどうよ（ｗ

66 ：42：02/02/18 01:58 ID:2m0xmRa4

>64
語源的にみれば履歴だが、利用のされ方と見るとそういうのも
あるかもしれない。（けどトップからもぐったときの利用もある）

ナビとしてみるならむしろ>50的感覚でolなのかと思い始めた

67 ： ◆HTML/.Kg ：02/02/18 02:10 ID:xfbVO3Zp

>>64
ん。この辺の話になるとサイトナビゲーション全般の
話になるので地とややこしくなりそうですね・・・。

イコールに聞こえましたかね。（汗
ただ、全体の階層を示すだけであれば、どこか一つのページに
まとめれば済む話であって、一つ以上間の空いた階層を示すのは
難しいと思うのです。迷子の人も、それで対応できるかと。
某P氏が「link要素で表せるページごとの関係には限界がある」
と言っていたように、そこまで詳しく書くページごとに関係を記すのは
あまりスマートなやり方とは思えない。
# といったらパンくずリスト自体の否定みたいになったな・・・

そうではなく、もし、現在のページを基準にした
他ページへの相対的な関係を示したいのであれば、
やはりlink要素な気がします。head要素のprofile属性
も活用したりして。

68 ：42：02/02/18 02:10 ID:2m0xmRa4

>65
> 利用者は「今いる場所から2階層上のカテゴリーを
> 見てみよう」とか考えるわけかな。
ユーザビリティーテストかなんかで頻出ネタ
＜インデックスないし目次に戻る人

# >66の具体例と考えてくだされ

69 ：Name_Not_Found：02/02/18 02:45 ID:HWQJmOPj

Strict は分かるが、何で今更 HTML 4.01 かな…。
それが「XHTML は難しい」って誤解の元凶のような。

XHTML 1.1 の方が初心者にとっても簡単なんだから、
まず XHTML 1.1 を教えて、それから応用的に HTML 4.01 も…
って構成の方がいいと思うんだが。

70 ：Name_Not_Found：02/02/18 03:09 ID:6SaKBX8X

月ごとにスタイルを変えたいんですけど、
<p class="April">
今日から四月…
</p>
<p class="May">
もう五月…
</p>
とclassで月を振り分けるのはStrict的に見て正しいでしょうか？

71 ：名無しさん：02/02/18 03:12 ID:4tecrdx5

>>65
code とか var とかはあるくせに
dir とか menu が消えたのは結構納得いってないです。
意味部分を構造から切離したかった、とかいうんだったら
strong とかをブロック・インライン両方に使えるようにするべきだったんだ。

72 ：Name_Not_Found：02/02/18 04:03 ID:BpuhzvDo

>69
禿同。
最近、HTML 4.01 Strictで作ろうとして挫折したけどXHTML 1.1ならすんなり作れた。
あ！ここで言う挫折は見た目じゃなくHTML Lintの点数の事。XHTML 1.1なら100点だった。
これから初心者に普及させるのなら最新の方が良いと思う。将来的にフレームページが絶滅するってのが一番嬉しい。

73 ：Name_Not_Found：02/02/18 04:10 ID:Ica9cFir

XHTML 1.1の仕様書を日本語翻訳した、或いは解説しているサイトって
ありますか？

74 ：Name_Not_Found：02/02/18 04:15 ID:BpuhzvDo

>>73
ないよ
翻訳使って読むんだYO

75 ：73：02/02/18 04:21 ID:Ica9cFir

マジですか。きついなあ。

76 ：Name_Not_Found：02/02/18 04:44 ID:GW0VRuxN

>>75
つーかXHTML 1.1の仕様書ってほとんど読むとこないじゃん。
XHTML 1.0 StrictがどんなものかわかっていてただXHTML 1.1
の文書書くだけならsection 2.1と3、Appendix Aくらいを読んどけば
十分。それでもわかんなかったら神崎さんとこの解説でも見れ。

http://kanzaki.com/docs/html/xhtml11.html

77 ：Name_Not_Found：02/02/18 05:15 ID:BpuhzvDo

>>76
そだね。HTML1ヶ月の俺ですら簡単に出来たし。
CSSの段組はちと面倒だったけど

78 ：Name_Not_Found：02/02/18 05:20 ID:BpuhzvDo

>>75
既出だけどXHTML 1.0 Strictとの違いは
lang属性が廃止され、xml:lang属性のみを使用する
a要素タイプとmap要素タイプのname属性が廃止され、id属性のみを使用する
rubyモジュールの要素タイプを追加
ね。こんだけ。簡単でしょ？仕様書読むまっでもないかと。

79 ：Name_Not_Found：02/02/18 07:31 ID:AXuVlcw6

>>73, >>74
ついでに言っとくと仕様書の日本語訳もあるぞ。検索エンジンで
「"XHTML 1.1" 翻訳」程度のキーワードですぐ見つかる。

80 ：Name_Not_Found：02/02/18 07:38 ID:HWQJmOPj

>>73
http://www.alib.jp/html/xhtml.html
http://www.alib.jp/html/elements.html
この辺でどうだ？

81 ：Name_Not_Found：02/02/18 09:44 ID:CxqFZ0iP

>>60
RFC 3236によれば
XHTMLはapplication/xhtml+xmlあるいはtext/html
XMLとして扱いたければapplication/xmlかtext/xml
でXHTMLの拡張子は xhtml xht html

XMLだとして扱いたいのでなければhtmlのままでいくのがよろしいかと

82 ：46：02/02/18 10:09 ID:PUwuyuMG

>>70
いーんじゃない

83 ：Name_Not_Found：02/02/18 12:11 ID:7nLnahbv

>>63
>WebKANZAKIでは、拡張子のないファイルをtext/htmlで出力するよう設定することを勧めてる。
そりゃちょっと違うだろ。Tim Berners-Lee の書いた "Cool URIs don't change"
の翻訳の話なら、コンテント・ネゴシエーションを有効にした上で拡張子なしの
URI で常にリソースを参照しろ、と言ってるだけだと思うが。
http://kanzaki.com/docs/Style/URI#remove

84 ：茶文字 ◆xELvisFU ：02/02/18 13:04 ID:8TmZfmTG

>>83
ちと言い過ぎたかしら？
http://kanzaki.com/docs/Style/URI.html
これを読んでからそっちのドキュメントを見たので、
URIの永続性が発想の原点にあると思ったので。

85 ：73：02/02/18 20:01 ID:q+bukwBA

レスくれた人ありがとう。
参考になった。

86 ：Name_Not_Found：02/02/18 20:53 ID:AM03dQ3P

私は楽だからってだけの理由でHTML4.0+CSS使ってますね。
背景色とかを変えるときの手間がfontを使用していると数倍に増える。
あと、一回作れば次回以降ちょっと楽できるのとソースが結構軽く見やすくなる。

「eXtensive」だから難しそう、ってのはあるかもね＞xhtml
実際、HTMLよりXMLに近いものだと思ってる奴は結構いるし。

87 ：Name_Not_Found：02/02/18 20:59 ID:QcuEYtNV

>>84
それ、>>83 のと同じドキュメント（ｗ
でまぁその点はその通りで、永続性が保てるならサーバ上でどうリソースを
持ってようが構わないと思う。コンテント・ネゴシエーションってのもただの
一手段に過ぎないし。

ただApacheとかのサーバを前提にするなら、サーバ上でファイルそのものを
拡張子なしにして、フォーマットが変わったときにそれを上書きしてしまうのは
やり方としてうまくないと思う。>>63 の例でいくなら、XMLが主流になったと
してもある日突然全てXMLにすればOK、とはいかないだろうからどうしたって
過渡期の対策は必要になる。当面XMLとHTMLの両方を用意してコンテント・
ネゴシエーションで提供しようと思ったときに、ファイルを上書きしてしまったん
じゃうまくいかない。サーバ上で動的に生成するならいいけど静的にやるなら
foo.xmlとfoo.htmlを用意してそのリソースは常にfooで参照しとけ、ってのが
趣旨。

具体例としては、<http://www.w3.org/TR/REC-xml> を Accept: text/xml で
リクエスト送ればXMLで送ってくるし Accept: text/html ならXHTML 1.0で送って
くる。このスレで度々議論になる後方互換性ってのもネゴシエーションを考慮に
入れた方がいいと思う。だから新しいメディアタイプが必要になるんだし。

長くなってスマン。

88 ：茶文字 ◆xELvisFU ：02/02/18 21:16 ID:8TmZfmTG

>>87
なるほど　ものすごくよくわかったよ。
過渡期の問題を考えに入れてなかったわ。
禿感謝。

89 ：Name_Not_Found：02/02/18 21:28 ID:4DLONWYN

ちょっと話変えて悪いけど
板をStrictなHTMLを吐き出すようにしようと思うんだけど
ソースが自信無いです。

<div class="write-form">
<h2>$form_title</h2>
<p>$comment</p>
<form method="post" action="$script">
<ul>
<li id="subject"><input type="hidden" name="mode" value="write">タイトル：<input type="text" name="subject"></li>
<li id="name">名前：<input type="text" name="name" value="$cname"></li>
<li id="mail">メール：<input type="text" name="mail" value="$cmail"></li>
<li id="url">URL：<input type="text" name="url" value="$curl"></li>
<li id="message">コメント：<textarea name="message" cols="30" rows="3"></textarea></li>
<li id="password">パス：<input type="password" name="password" value="$cpass"></li>
<li id="submit"><input type="submit" value="書込む"></li>
</ul>
</form>
</div>

<div class="log">

<hr>

<div class="item">
<h3>subject</h3>
<dl>
<dt class="name">NAME</dt>
<dd class="name">name</dd>
<dt class="url">URL</dt>
<dd class="url">url</dd>
<dt class="date">DATE</dt>
<dd class="date">date</dd>
<dt class="comment">COMMENT</dt>
<dd class="comment"><p>comment</p></dd>
</dl>
</div>

</div>

こんな感じなんだけど、フォームってリスト要素でいいんですかね？

# 長くてごめんなさい。

90 ：Name_Not_Found：02/02/18 21:57 ID:q2MNB1CC

特に問題はありません。

あえて言えば、label要素を使えばより良い。

91 ：Name_Not_Found：02/02/18 21:58 ID:q+bukwBA

tableの方が意味的にいいんじゃないの？

92 ：89：02/02/18 22:19 ID:4DLONWYN

>90
label要素忘れてました（ｗ
付け足しときます。ご指摘ありがとうございます。

>91
う～ん、表って感じとは違うと思うんですが・・・。

93 ：Name_Not_Found：02/02/18 23:09 ID:lCsTIalI

formの中に、h2要素があった方が良い気もするんだけど、
その点どう？

どっちでも良いのは確かだろうけど。

94 ：Name_Not_Found：02/02/19 00:20 ID:ZW9m04vx

>>87
解りよい。

95 ：89：02/02/19 01:23 ID:gJj8g2Ar

>93
h2要素は２ちゃんねるでいう板の名前で
その下のp要素にローカルルールみたいな感じのを
書こうと思ってこんな感じにしたんです。

言われてみればフォームの中でも良さそうですね。
ちょっと検討します。

96 ：Name_Not_Found：02/02/19 13:55 ID:qNsnEBJP

>>86
「eXtensive」じゃなくて「Extensible」ね、一応。

>実際、HTMLよりXMLに近いものだと思ってる奴は結構いるし。
それはある意味間違ってないと思う。というか同じものをどちらの
側面から見るかで受ける印象が異なるんじゃないかな。

例えばXHTML 1.1を文書作成者の立場から見ればXHTML 1.0
Strictに毛が生えた程度で、HTML 4 Strictとたいして変わらない。
でもDTDの設計はXHTML 1.0と1.1では全くの別物で、XHTMLを
ベースに社内用文書フォーマットを設計するような文書型設計者
にとってはこの違いはとてつもなく大きい。そういう人にとっては
XHTML、特にモジュールベースのやつは明らかにHTMLよりXML
に近いだろう。Ｓchema使うようになればこの差はさらに顕著になる
と思う。

別にどっちが正しいっていうんじゃなくて、そういう二面性を持つのが
XHTMLの特徴。

97 ：名無しさん：02/02/19 14:18 ID:Lsqh1jvL

>>96
>XHTMLをベースに社内用文書フォーマットを設計するような文書型設計者
これってどういう所で行なわれてるのか未だに理解らないんですが...
普通の会社でやってるもんなんですか？

98 ：Name_Not_Found：02/02/19 17:10 ID:l3AkUvX/

>>97
「普通」の定義によるけど…社内文書はワード、みたいなとこじゃやってない
だろ。SGML使ってきたとかある程度XMLを使ってるとこならコストとメリットを
秤にかけて、場合によっては専用のXML DTD/Schmaを設計するし、お手軽
に済ませるならXHTMLをそのまま使うかちょっとだけ拡張して済ませることも
あるだろうし。ウチじゃXHTMLにエンティティをいろいろ追加して定型文書くとき
の省力化を図る程度は普通にやるけど。

むしろ大規模にやってる例の方が目立つよね。WAP ForumがXHTML Basic
をベースにしてWML 2.0作ったり (EZwebで採用) とか、アメリカのTV業界で
ATSC/DASEがXHTMLベースのXDMLを次世代デジタル放送用に作ってたり
とか。日本のBSデジタル放送で採用されてるBMLだっていろいろ言われてる
けど一応XHTMLベースだ。他にもXHTML-Printとか、でかい応用例ならいくら
でも出てくる。

99 ：Name_Not_Found：02/02/19 21:10 ID:CXXDFuTe

>>97
例えばこういう所で行われてる。
http://www.fxis.co.jp/DMS/sgml/cafe/saloon/jirei/jirei.html#jirei1
この例は1999年4月6日版の最初のModularization of XHTMLのドラフト
に基づいてるんでちょっと古いけど、まぁ基本的な考え方は同じ。

100 ：Name_Not_Found：02/02/21 18:56 ID:3EkVLTP/

上げとくよ

101 ：Name_Not_Found：02/02/21 22:55 ID:73dHahmv

NN4.xを斬る! (なんでネスケを使うのかね Part 2)
http://pc.2ch.net/test/read.cgi/hp/1011008092/
の、599を受けて。こっちのスレのが合致してるよなのでこっちに。

Strictの価値を一般に理解させるUA（というよりブラウザ）とは・・・
LINK要素ボタンが標準装着されてて（選択性だがMozillaはあるね）、
METAデータをサポートし（著作者や制作ツールの名前等がプロパティに）、
代替スタイルシート切り替えが簡単にできて、またブラウザそのものにも
代替スタイルシートが最初から装備されており、自由に交換できる。
Qなどの引用文で引用元へのジャンプも可能だし、TITLE等の属性で
様々な要素にポップアップ文を表示させる事だって可能。
次のパラグラフやHnあたりまでスクロール、というのもアリかも知れん。

楽しそうだ。だが、仕事にすると死ねそうだ。

102 ：Name_Not_Found：02/02/21 23:40 ID:4OKTlWkA

>>101
ってか似たようなことはすでにほとんどPiroさんの
"ContextMenu-Extensions for Netscape 6 & Mozilla"
で実現してる。
ttp://www.cc-net.or.jp/~piro/works/_moz-extensions.htm

103 ：Name_Not_Found：02/02/21 23:53 ID:ZjwGfckP

でもそれを普及させるにはゲイツの力が必要だなぁ。手っ取り早くするにはね。

104 ：Name_Not_Found：02/02/22 00:03 ID:SGZ4Q5d8

>>101
LINK ボタンや Q の引用元ジャンプなど
ブラウザが HTML の全ての要素の全ての属性に
何らかの反応をするようになったとしても
結局はそれに依存または誤用する HTML が横行するだけで
Strict への理解はそれほど広まらないと思うのだがどうか？
それでもまあ今よりはよい状態なのだろうけれど。
ブラウザが代替スタイルを標準添付するのは効果がありそうな気がするな。

105 ：Name_Not_Found：02/02/22 00:10 ID:FFTnLVz7

ブラウザよりオーサリング・ソフトが問題ですよ。
見るだけの人は抑もその効果がＣＳＳによるものか否かなんて気にしない。
制作ソフトがまともなタグを吐いて、スタイルシート適用がスムーズにできねば
いつになってもStrictなんて広まりっこない。

106 ：Name_Not_Found：02/02/22 00:26 ID:yzL08pKY

オーサリングソフト会社は、単にユーザーの欲しいものを出してるだけではないだろうか。多くのユーザーが求めるものを多くのユーザーに買わせ、利益を得るのが企業の主な活動だ。

107 ：Name_Not_Found：02/02/22 00:36 ID:fwrBEMMZ

>>106
ユーザーの大半は、例を出すなら、インデントを取るのに
blockquoteタグを挿入してるのかmarginやpaddingを指定してるのか
なんて気にすまい。見える結果が同じならどっちでもいい。
したがってユーザーはどちらを欲するものでもないわけではないか。
であれば、オーサリング・ソフトの方で見栄えに関する指定はCSSで対応することに
してくれれば、それだけでStrictなソースが増えるはず。

108 ：Name_Not_Found：02/02/22 00:38 ID:fRk4o32s

>>102　正直、知らんかった。ﾀﾞｳｿしてみる。
まぁ、やはりメジャーどころに対応してもらい、普及しないと意味がないのだが。

>>104　CSSとは違い、正式な要素の対応だから、一概に依存とは言えないだろ。
勿論、対応したての時はブラウザ専用タグでしかないが、それは仕方ない。
それから5年も経てば、立派に「使える」タグとなると思われ。
それまでの間は「あれば親切」程度でいいじゃないか。
現状の「あっても意味のない、制作者のための記述」よりははるかにマシだ。

引用元ジャンプ等の誤用については、まぁ予測できるがね。
「アンダーライン・色変更のないジャンプ・タグ」とどっかで紹介されるとか。
これは仕方ない。
「これより引用」などの解説を視覚ブラウザに入れるのは非現実的だし、
そもそも「ここが引用部分でパラグラフで」などと、最初から意識して
ページ制作を始める人はまずないだろう？
やはり、「グラフィカルに」「世界へ発信」できるのがWebの魅力だろうから。
HTMLの論理構造なんて、どうせ制作側に回り、かつ本気になって勉強した
人にしか付かないものだろうし、それは仕方ないと思われ。
「HTMLは論理構造がいいんだよね～」なんて、一般閲覧者が言う時代は
まず来ないさ。

まぁ、「このサイトの引用をすべて検索」のような機能が付けば別だがね。
そんなのが付けば、制作者側も意識せざるを得ないだろう。
しかし需要や有効利用の可能性等から言って、今は現実的ではないと見る。

109 ：茶文字 ◆xELvisFU ：02/02/22 00:49 ID:qstGGS04

参考までに。
今IE5Mac版なんだけど、q要素は以下のように表示されるっす。

ﾏｷｰｺ前大臣は<q>ふと振り返るとスカートを踏んでいる人がいた</q>と語った。
　↓
ﾏｷｰｺ大臣は"ふと振り返るとスカートを踏んでいる人がいた"と語った。

110 ：Name_Not_Found：02/02/22 01:40 ID:dkzSEwG+

>>108

> そもそも「ここが引用部分でパラグラフで」などと、最初から意識して
> ページ制作を始める人はまずないだろう？

strictに書いている人は普通そうだと思うけど。少なくとも漏れそうだけどね。

htmlというのは、人が見るもんじゃなくて、アプリケーションが使うもんだよ。
だから、正確に記述してあれば引用部分を抽出するとか、
引用部分の中の段落部分を抽出するとか、そんなのは、いたって簡単。
正規表現を使える人なら、今すぐにでも利用できるはずだーよ。

111 ：Name_Not_Found：02/02/22 01:42 ID:dkzSEwG+

>>109
「前」はどこへ行ったの? (w

112 ：Name_Not_Found：02/02/22 02:07 ID:fRk4o32s

>>109　WinのIE5.01SP2では、Q入れても変化まったくなし・・・。
しかし、""ってのもなんだか嫌だな、個人的に。
文字が付け足されるってのが。言ってもしょうがないが・・・。

>>110　いや、少し言葉が足りなかったな。

確かに、俺も書く時そういう構造を意識して書く。っていうか誤用は嫌だ。
しかし、「はじめてホームページ作ってみました」って時から意識する人が
何人いるか、というと大多数は「こんなページをこんなレイアウトで」
程度でしかないと思う、という訳さ。

俺は幸いにして、「Pはパラグラフ」から始める事ができた。
しかし、それが「ページ制作者なら常識」だとは思わん。
そうあるべきとは思うが、現実的には、な。

そしてこんな初心者層に引きずられて、ブラウザを始めとしたUAの進化は
遅れがちになる、と・・・。
その意味では、105の言うところも重要だろうな。
ただ、marginとかCSS使われ始めるととネスケ4対応が難しくなるが。
いや、そうなればネスケ4がとうとう消滅してくれるか？

113 ：Name_Not_Found：02/02/22 02:27 ID:1LFRzDoI

＞だから、正確に記述してあれば引用部分を抽出するとか、
＞引用部分の中の段落部分を抽出するとか、そんなのは、いたって簡単。

なんかこういう場合に例にだされるのが、それやってどうするのかというような
よくわかんない例なことが多いような気がするのだけどな。

114 ：Name_Not_Found：02/02/22 02:41 ID:3rwcC9Rx

>>112
＞しかし、""ってのもなんだか嫌だな、個人的に。
＞文字が付け足されるってのが。
同感。しかし既出。↓
「Ｑ要素：インライン引用文のマークアップについて」
http://pc.2ch.net/hp/kako/1002/10027/1002750163.html

115 ：Name_Not_Found：02/02/22 03:28 ID:X10/sQ56

>>113
実用的な例なら、
定義語や強調語句としてその言葉がマーク付けされている場合にロボット検索での順位に反映できるとか、
強調語句の部分は音声ブラウザでは音量を上げるとか（HPRはこれすらできないらしいけど）、
そんな感じでしょうか。

116 ：Name_Not_Found：02/02/22 03:50 ID:1LFRzDoI

うーん、前者はstrictとは必ずしも関係ないし、
後者みたいのは実は音声ブラウザ利用者の立場からするとそんなに有用でもないってのが
ずっと前のこのスレ（？）に書いてなかったかな。

それからこのスレでよく「Strict的に見て正しいか」みたいに議論してる個々の事柄が
「アプリケーションに読ませるため」っていう観点からどういう意味があるのかとか
いまいちはっきりしないことが多いと思うのよ。

117 ：115：02/02/22 04:05 ID:X10/sQ56

>>116
>後者みたいのは実は音声ブラウザ利用者の立場からするとそんなに有用でもないってのが
>ずっと前のこのスレ（？）に書いてなかったかな。
ちゃんと実装できていれば、それなりに有用だと思いますが。
現在の音声ブラウザは論理要素を何ら有効利用できていないという話なら、音声ブラウザにiCab/Opera的な存在が登場することを期待するほか無いです。

118 ：42：02/02/22 10:11 ID:dZCeijCl

>114
第一、quotesプロパティを使ってくれ、と言いたい。

>116
リソースを使うのが今の段階では所謂"Webブラウザ"
だけだった時代の話。これからは変わって(行く。|くれ。)

119 ：Name_Not_Found：02/02/22 12:11 ID:6cQaCk7o

>>118
quotesプロパティを使っても、MacIEでは引用符生成の制禦ができませんよ。
Mozillaみたいに引用符を消したり鍵括弧にしたりできるならその時はq要素も使用します。

120 ：茶文字 ◆xELvisFU ：02/02/22 13:29 ID:V0WIrRO+

qを明確に出力するなら、現状ではCSSだのみってとこかぁ。
引用元のURIが明示されている場合、何らかの参照手段を
デフォルトで持つべきだとは思うけど。

>>111
間違いなく書き写すように事務所の眼鏡をかけた男性に伝えたんですけどねぇ。
© Ｆ田官房長官

121 ：Name_Not_Found：02/02/22 13:54 ID:Uc7jatHG

>>120
DOM で引用符付けたり引用元表示したりやってる人はいるYO!

122 ：名無しさん：02/02/22 14:05 ID:DGUUMZAd

Strict な HTML から何かを抽出するって方向だと...
コンピュータに読ませる、って観点からすると悲しすぎる程に語彙が少なすぎる。

せめて、class 名の付けかたによって特定の意味を持たせるぐらいないと。

例)
class="update" で更新履歴
class="date" で日付情報
(どうでもいいけど、datetime はどの要素にも付けれるようにしてもいいような。)
class="last" で最新情報とか。

123 ：Name_Not_Found：02/02/22 14:29 ID:m9WqWwlJ

div要素乱用してxml気取りすんの可読性ねえしアホくさ

124 ：Name_Not_Found：02/02/22 15:02 ID:6xAHCqCS

>>122
XHTMLにしてRELAX NGパターンでも書け。RELAX NGならclass="date"
のときの要素内容は日付情報 (XML Schemaのデータ型で言えばdateTime)
だとか、class属性の値によって表のこのセルの要素内容は1以上の実数で
なければならないとかいった制約は簡単にかけるし検証もできる。ただ適当な
class名を付けただけではまともな機械処理はできないが、だからってXMLに
していちいちそれ用の要素/属性を定義しなきゃ機械処理できないわけでも
ない。

125 ：124：02/02/22 15:07 ID:PlqvL3NH

>>124
ゴメン、日付だけでいいならdateTimeじゃなくてdateで十分だった。

126 ：名無しさん：02/02/22 15:45 ID:DGUUMZAd

>>123
可読性っていわれても。
人にとっての可読性って必要なの？
HTML とか XML って機械がバカだから人が歩みよる方向にすすんでるんじゃないの？

>>124
そういうのの、グローバルなルールが欲しいなと。

127 ：Name_Not_Found：02/02/22 16:27 ID:SGZ4Q5d8

>>126
> 可読性
HTML や XML はなぜバイナリではなくテキストなのだと思う？

128 ：124：02/02/22 16:57 ID:E9Mm05h1

>>126
いや、気持ちはすごーく良くわかるんだけどさ。HTML 3.0が失敗したのって、
そうやってみんなであれも欲しい、これも欲しいって言い出して収拾がつかなく
なったからじゃない。人によって欲しい機能はまちまちだから、全部取り入れて
いくと際限なく仕様が肥大化していって誰もフル実装できなくなる。

だからXHTMLではモジュール化を進めてるんで、個人的にはText Moduleも
分割してemとかcodeとかはコアモジュールから外して欲しい。で、(X)HTML
じゃ語彙が少なすぎるとか言う人はTEIでも組み合わせて使えばいいじゃん。
そうすりゃ引用の仕方もいらんほどバリエーションがあるし、q要素だけとっても
type属性でもdirect属性でもwho属性でも好きなだけ使ってくれって感じ。TEI
自体もモジュール化されてるから欲しいとこだけ取ってくればいい。(X)HTML
だけで完結する時代はもう終わってると思う。

129 ：Name_Not_Found：02/02/22 20:51 ID:pVvTB2QI

しかし、どんどん難しい話になっていくな…。
これだったらC++の方がまだ分かりやすいよ。ｳﾜｧｧｧｧｧｧｧｧﾝ。

130 ：87=96=98=99=124=128：02/02/22 21:21 ID:I0ATIFfE

>>129
スマン、なんか話題を変な方向に持っていってしまってるかもしれない。
XHTMLに特化した話は他所に逝ってやることにするよ。邪魔して悪かった。
StrictなHTMLの話題に戻ってくれ。

131 ：名無しさん：02/02/23 02:35 ID:TR3bvSkj

>>127
別にテキストじゃなくても良かったと思うけど。
なんでテキストなの？

>>129
一般的なプログラム言語の方が筋が通ってて
よっぽど理解りやすいってのは同意。

132 ：Name_Not_Found：02/02/23 10:44 ID:mjb5Lvwh

>>131
たぶん、テキストにする事によって人間にも可読性を持たせたかった、と言いたいのでは？

133 ：StrictBBS：02/02/23 11:00 ID:mjb5Lvwh

えーっと、チョト質問。
今、Strictな掲示板のスクリプトを作ってるんですが、これって需要あります？
もともとStrictなサイトを作ってる人って、掲示板自体を設置しない人が多いので需要ないような気がするんですが…。
需要があるなら、あらゆるCGIスクリプトをStrictで作ってみようかな、と思ってるのですが。

134 ：Name_Not_Found：02/02/23 11:23 ID:7sfs6vaz

>>133
いやいや、ありますよ。需要。これまで修正大変でしたもん。
個人的には、あなたのような人を心から待ってました。
既にStrictなHTMLを吐き出すCGIを作ってる方はいらっしゃるみたいですが、
やっぱりまだまだ限られてくる。

それに、生意気な言い方ですが、例え需要が無くても、
将来性と考えたらなるべくStrictで作るべきだと思います。

仕上がりに期待してます。頑張ってください。

135 ：Name_Not_Found：02/02/23 11:25 ID:7sfs6vaz

>>134
> 将来性と考えたら
「将来性とか考えたら」の間違いでした。

136 ：Name_Not_Found：02/02/23 14:27 ID:xWqwvfbj

>>133
凄く欲しい。
綺麗なStrict吐き出すならシェアウェアでも構わないほどホスイ

137 ：Name_Not_Found：02/02/23 14:32 ID:StZFw192

shift_jisで吐き出すstrict掲示板希望ー

138 ：Name_Not_Found：02/02/23 14:38 ID:xWqwvfbj

携帯対応も希望
マルチスレッド機能も欲しいけど、携帯を無視せにゃならんのでStrictには程遠いか…

139 ：Name_Not_Found：02/02/23 15:05 ID:qZdO8O36

レンタルなら( ﾟдﾟ)ﾎｽｨ…かな。
いや、置けないんで。つーか引っ越すか…。

140 ：Name_Not_Found：02/02/23 15:16 ID:StZFw192

シェアでも買う
ただハトマルんとことちがって
設置方法もやさしく解説してねｗ

141 ：Name_Not_Found：02/02/23 15:50 ID:gAK3qvGY

http://fantasien.cup.com/perl5/
とか
http://say.vis.ne.jp/script/picobbs/
じゃダメなんか？

142 ：Name_Not_Found：02/02/23 16:18 ID:KkLjEY1q

レンタル( ﾟдﾟ)ﾎｽｨね。

143 ：茶文字 ◆xELvisFU ：02/02/23 16:28 ID:ONmb6FZx

とりあえづ、他スレの関係で設置したKENT氏のWebForumを
Strict化することに着手してみる。
あの掲示板使い勝手がよくて好きなんよねー。

チャットはフレームにしないとあんまりアピール性がないからしんどいな。

144 ：89：02/02/23 18:30 ID:3EoZ+y5l

>>133氏
うお！オイラも今作ってるのに（わ
今は一覧型を製作中。
上手くいけばｽﾚｯﾄﾞﾌﾛｰﾄ型も作ろうと思ってるのよ。

ちなみに「StrictBBS」って板は配布されてますから
名前変えたほうがいいかも。
ttp://haruno.fam.cx/~sawatari/cgiscript.html

オイラは「Strict Board」にする予定（わ

共に頑張りましょうね。

145 ：Name_Not_Found：02/02/23 18:58 ID:yaqQ8M4Y

Strict精神旺盛なCGI、楽しみに待ってます！頑張ってください！

世の中は少しずつ変わってるぞ。

146 ：Name_Not_Found：02/02/23 19:49 ID:LrGL0sGF

オレは
http://cgiroom.nu/list/bbs/karubbsr/index.htm
を改造してStrictなHTMLを吐く様にしたよ。
一応スレッドフロートだし、改造しやすいので
興味のある人は見てみては。

でも、これ以上の話はWebProg板のほうがいいのかな？

147 ：茶文字 ◆xELvisFU ：02/02/23 20:56 ID:ONmb6FZx

>>146
具体的なスクリプトの改造方法とかなら板違いなんだろうけど、
需要があるか？とか前例はどのくらいあるのか？とかの情報って
あんまり目にしたことがないから、このスレらしくてよいと思われ。
ずーっとこの話題ばかりだと飽きるけど（ｗ

同じことを嗜好しているひとはいるもんだなぁ。
このスレに来て勉強させてもらってよかった。

148 ：Name_Not_Found：02/02/23 21:17 ID:mjb5Lvwh

>>144で出てるStrictBBSって出来、良いですね。
改行を<p>に変換して、上手く処理してる。
うーん、それじゃ俺はツリー型でも作るか。
でも、ツリー型って…Strictに馴染むか？まぁ、やってみるか。

149 ：89：02/02/23 22:58 ID:eQJ8Kgi+

>>148
その<p>のアイデアも考えてたのにショックでした（わ
オイラは２ちゃん仕様にしようかと思います。
ﾄﾘｯﾌﾟとか。
スタイルを作れスレでツリーの板のテキストが
うｐされてるから参考にしてみては？

>>all
基本的なのが出来たらここで晒していいですか？

150 ：Name_Not_Found：02/02/23 23:01 ID:TffSKKmU

>>149
> >>all
> 基本的なのが出来たらここで晒していいですか？

是（が）非（でも）！

151 ：茶文字 ◆xELvisFU ：02/02/23 23:07 ID:ONmb6FZx

確かにツリーの表現が難しいところですなぁ。
liのネストでどうにかならんかと考えてますが。

152 ：Name_Not_Found：02/02/23 23:33 ID:2Zoo0RKF

>>151
http://www.remus.dti.ne.jp/~a-satomi/nikki/tmp/tree/tree_css.html

153 ：サ骨 ◆/IQ5000w ：02/02/24 00:01 ID:Mz9QFB0e

俺はお絵描き掲示板のBBSnoteを
strictに改造中。。
http://sakots.pekori.jp/oekakibbs/bbsnote.cgi

154 ：茶文字 ◆xELvisFU ：02/02/24 00:23 ID:ZRyy6bxU

>>152
ほぉぉぉっ　こりゃ巧いね！

155 ： ◆csohISSc ：02/02/24 17:09 ID:CiqXFsYf

>>153
おおサ骨さんだ。完成したら是非、配布してほしいです。

156 ：ちょこら ◆DmcC0DXc ：02/02/25 18:53 ID:/X54/MiJ

僕のサイト、strict掲示板です。
ついでにかちゅ～しゃみたいに「>>番号」で発言内容をポップアップさせてます。

157 ：89：02/02/25 23:59 ID:s8hDb2Ns

またオイラのアイデアが・・・

158 ：Name_Not_Found：02/02/26 00:09 ID:TPqc5eRe

ねえねえ
おれさ
<h1 id="top">はにゃん</h1>
として

#top{font-family:serif; font-size;130%; font-weight:normal;}
みたいにして、それを５ページくらいにつかってるのよ。
でもつまりページ内にはtopというidは一個だけど、
一つのサイトとしてはidが５個もあるのよ。これってだめかなあ？
<h1 class="top">はにゃ</h1>がいいかなあ？

159 ：Name_Not_Found：02/02/26 00:14 ID:sVCSfiYN

>>158
ページ内に一ヶなら別にいいんでないの？
idならページ内ジャンプのアンカーとしても応用できるし。

160 ：Name_Not_Found：02/02/26 00:14 ID:F/KC9kGr

＞これってだめかなあ？

別によいだろ。id はページ内のフラグになればいいわけだし。
同一ページ内でダブらなければいい。

例えば一つのサイトに index.html が複数あっても問題にならんでしょう。
これだって、同一ディレクトリ内でダブらなければ問題ないからでしょ。

161 ：Name_Not_Found：02/02/26 01:25 ID:FgvHajr6

俺は全てのページは一応おなじスタイルをきかせてあるが。
自背景色だけはかえてあるのだ。その場合。
<body id="index">
<body id="top">
などとidをbodyにふって
#index{background:#fof;}
#top{background:red;]
とするか、共通部分をひとつのスタイルにして、
つまり
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="index.css">(背景色のみ指定のスタイルシート)
背景色のみは背景用のスタイルでよみこませるという方法とどっちがいいだろうか？
bodyのように一個しかないに決まっている要素にidやらclassやらふるのに
抵抗があるのだが、考えすぎ？

162 ：Name_Not_Found：02/02/26 01:37 ID:sVCSfiYN

>>161
bodyにidを振る方法は、以前、piro君のTipsでも紹介されてましたね。
http://web.archive.org/web/20010603093743/http://www.cc-net.or.jp/~piro/tips/page/p0021.html
(↑ＩＥで見ると真っ白になるのはjavaScriptが悪さしてるのか？)

163 ：茶文字 ◆xELvisFU ：02/02/26 01:39 ID:0kJ7snFC

>>161
スタイルファイルを1枚で済ませようとすると、CSSファイルの中身が
冗長になる気がするのよ。
HTMLのソースの可読性とバーターでCSSの可読性が落ちるってのは
ちょっと違う気がして、CSSもできるだけスマートにしたい。

が、1枚にまとめた方が楽な面もあるのは事実だよなぁ。

164 ：Name_Not_Found：02/02/26 01:43 ID:9M79gqVk

>>161

私も<body id="index">って使ってるよ。
classは何となくいやだけどidならいいんじゃない？

165 ：茶文字 ◆xELvisFU ：02/02/26 02:17 ID:0kJ7snFC

できるのかどうか知らないが、別のところで得た情報から思いついた。

CSSファイルをCGIで動的に作っちゃう。
具体的には、ヒアドキュメントで

open OUT,"./style.css";
print OUT <<"EOH";
Content-type: text/css; charset=Shift_JIS

body{
background: $back;
}
・・・
EOH
close OUT;

と書いておき、リファラをとって呼び出し元によって$backの中身を入れ替える。
出力時のMIMEタイプをtext/cssにすれば可能かと。

これがスマートな解決かどうかは不明。
あーんど　微妙に板違いsage。

166 ：茶文字 ◆xELvisFU ：02/02/26 02:18 ID:0kJ7snFC

書き忘れ。
呼び出す側は
<link rel="stylesheet" href="xxx.cgi" type="text/css">
これね。

167 ：Name_Not_Found：02/02/26 02:46 ID:PxwO4WtM

>>165
リファを返さないブラウザだと困るとか。

168 ：Name_Not_Found：02/02/26 04:47 ID:KnIpABVc

bodyのように１ページに一個しかない要素にも
class名のほうがいい場合ってあります？

169 ：Name_Not_Found：02/02/26 07:40 ID:KMs9XJ7H

>>168
例えばコンテンツ毎にスタイルを変えるならクラスがいいんじゃないかな。
<body class="diary">
とか。
ただし、そのコンテンツが複数ページがある場合だけの方がいいと思うよ。

170 ：Name_Not_Found：02/02/26 10:18 ID:16UZcfG+

>>169
それならclass名じゃなくてシートを替えろという話もあるが

classはシートのためにあるわけじゃないけどね

171 ：Name_Not_Found：02/02/26 11:12 ID:g9vIz6Ou

>>168
そういう場合は、idでしょ。やっぱ。
もしかして増えそう、増えるかも、増えたらどうしよう、なら、classでもいいかも。
別にbodyが2つ3つあっても文句いいませんが。

172 ：Name_Not_Found：02/02/26 14:06 ID:7jOAvq08

>>171
ここは Strict スレです。

173 ：171：02/02/26 14:48 ID:g9vIz6Ou

もっとうまくつっこんでください。

174 ：Name_Not_Found：02/02/26 14:57 ID:DeQi1ohT

ここは<blink>Strict</blink>スレです。

175 ：Name_Not_Found：02/02/26 15:08 ID:f+cWtfip

XHTML使ってるんですけど、携帯で読み込んだら<?xml version="1.0" encoding="Shift_JIS"?>が表示されるんですよ。
これを回避する方法は無いでしょうか？
やはり携帯用にXHTMLは使えないのかな？
確認した携帯はP502iです。

176 ：Name_Not_Found：02/02/26 15:12 ID:DeQi1ohT

>>175
一応書いておくと、DoCoMoはXHTML未対応。
回避方は俺も探してるんだけど、XML宣言抜くとかしかないみたい。
ちなみに501シリーズではXML宣言があると何も表示されなかったりする
場合もあるようです。

177 ：Name_Not_Found：02/02/26 15:16 ID:pUsB+00U

>>175
XHTML勧告(2000-01-26)前の機種が対応して無いのは当然と言えば当然。

178 ：Name_Not_Found：02/02/26 15:23 ID:f+cWtfip

>>176
そうですか……
そうなるとできるだけ多くの携帯に対応させるならXHTMLは使えないということか…それかXML宣言を消すか、HTMLで新しいページを作るか…
携帯用のページとURL(/i/index.html)なんて使いたくないのに…

179 ：まとめたぞ：02/02/26 15:33 ID:tZZlnkZs

もうばれてるんで、普通に自サイト晒します。
Another-lint を突破する掲示板を apeboard で作って放置してるんだけど、
なんか放置プレイしてるんですよ。

Markup 見てなんだｺﾞﾙｧ!!て突っ込み欲しいんですけど。お願いします。
あと、配布する気持ちがあったので、<meta><link>あたりの記述は許してください。

完成したら、配布でもしてみようかと思ってます。
http://www.webcafe-prelude.com/cgi-bin/apeboard_plus.cgi

180 ：Name_Not_Found：02/02/26 15:39 ID:f+cWtfip

>>179
このスレはStrict主義な人しか興味持たないから、晒しても荒らされる事は無いと思う。
それはそうと
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
これを
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
このように改行したほうが良いと思う。いや、別にそんなに変わるわけじゃないんですけど…

181 ：サ骨 ◆/IQ5000w ：02/02/26 16:10 ID:dgawZ4H9

http://sakots.pekori.jp/oekakibbs/bbsnote.cgi
なんとかココまでは来たけど、
絵描き画面とカタログ表示のstrict化が絶望的で!DOCTYPEが書き換えられん…
カタログは削除してしまえばいいとして…
ムムム。

182 ：Name_Not_Found：02/02/26 16:34 ID:UNzMkZrJ

>>177
いや、でもさ、XML 宣言って単なる処理命令だから、
文法的には HTML 2.0 にだって書けるんだよ？

<?xml version="1.0" ?>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN" >
<html>
<head><title>samp</title></head>
<body><p>hoge</p></body>
</html>

これでも valid で、この処理命令を知らない UA は、
処理命令を単に無視するのが正しい挙動。

183 ：Name_Not_Found：02/02/26 16:34 ID:Bu3qLgfi

携帯のことも考えると、現状ではHTML 4.01 Strictの方がアクセシブルなのかな。

184 ：Name_Not_Found：02/02/26 16:41 ID:1aXUJf31

>>179
NEXTとかBACKだとかは、
<UL><LI>の方が良いと思うのですがどうでしょう？

185 ：177：02/02/26 16:44 ID:pUsB+00U

>>182
そか、XML宣言の話だからXHTMLの勧告うんぬんはズレてたか。

>>183
携帯っつーか、imodeな。少なくともJ-Phoneは普通に見れる。

186 ：184：02/02/26 16:45 ID:1aXUJf31

あ、それと、apeboardはCGIを弄くらないとStrictにはならんですよね。
この辺はどうするのですか？

187 ：まとめたぞ：02/02/26 17:08 ID:7kSGGl+3

そうですね。cgi は改造してあります。配布するならオリジナルと
「おまけ」で stirct バージョンを。と考えてるです。

ナヴィゲーションをリストにというのは、賛成（というか、今はそうなんですが
昔は、div か p を使っていたので）です。

188 ：Name_Not_Found：02/02/26 17:12 ID:siiukjc7

>>180

> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd">
> このように改行したほうが良いと思う。

(ﾟДﾟ)ﾊｧ?
何で?

189 ：Name_Not_Found：02/02/26 17:49 ID:Bu3qLgfi

>>188
おそらく個人的な好みだろう。見た目とファイルサイズ以外、
何も変わらないと思うよ。どっかのブラウザにバグでもあるのかな？

190 ：Name_Not_Found：02/02/26 18:07 ID:8ieEpQzF

つうか、SYSTEM識別子なんてわざわざ書かなくてもいいのでは……。
XHTMLでは必須だから書いてるけど、HTMLでは書いてないや。

191 ：Name_Not_Found：02/02/26 18:20 ID:UNzMkZrJ

>>190
Strict 的には書いた方が良いんだけども。

192 ：Name_Not_Found：02/02/26 18:42 ID:16UZcfG+

>>191
またまたご冗談を

193 ：茶文字 ◆xELvisFU ：02/02/26 18:43 ID:0kJ7snFC

>>まとめたぞ氏
乙カレー。
個人的な好みだけど、class名はあんまり省略しない方がいいかも。
使用者にある程度の再カスタマイズを認めるなら、その方が見通しがいいと思うの。

194 ：191：02/02/26 19:03 ID:UNzMkZrJ

>>192
いや、マジで。

本来なら、 DTD はパーザが読むものでしょ。
当然パーザは外部識別子から DTD の所在を判別できなきゃならない。
で、SGML 的にシステム識別子を省略してもよい場合ってのは、
「パーザが公開識別子からシステム識別子を生成できるとき」に限る。

ブラウザに SGML のオープンカタログ(*)読み込ませてる奴なんているのか？
*例えば http://www.w3.org/TR/html401/HTML4.cat

とは言え実際には SGML の DTD を読んでいるブラウザなんて皆無だろうけど。
だから「Strict 的には」って書いたわけで。

195 ：Name_Not_Found：02/02/26 19:44 ID:y4lwwd2f

>>194
W3Cのバリデータは外部のDTDも読むね。

196 ：Name_Not_Found：02/02/26 20:33 ID:G5r3hLu9

>>194
え？それとStrictに何か関係ありますか？

197 ：まとめたぞ ◆/Re6aTC. ：02/02/26 20:41 ID:v0ax42P4

>>茶文字氏
そですね。思い切って日本語classてのもありですか?(w

ところで、
投稿文を<p>で括っているわけだが、<br><be>が許せず<pre>にするという考えもあるか
もしれないけど、どうなんだろ。

あ、あと、form が <h2> で、Messages が <h3>ていうのは変かもなぁ。<h2>で同じ
レベルの見出しであるべきな気がしてきた。あと、ie3,\.css への相対パスの記述ミス
教えてくれた人ありがとうです。向こうでもレスしたけど。

激しくスレ違いだが、CSS リンク集は現在更新作業を進めていますんで、も少しお待ちを。

198 ：まとめたぞ ◆/Re6aTC. ：02/02/26 20:43 ID:v0ax42P4

激しいタイプミスだ。

逝ってきます。

199 ：Name_Not_Found：02/02/26 21:30 ID:quQ96n4z

CGIの方で、改行を<br>に変換するのではなく、
</p><p>にするってのはどうだい？

投稿者が何気なく改行すると、
激しくマークアップが
おかしくなる恐れがあるけど。
↑こんな感じに改行すると

200 ：Name_Not_Found：02/02/26 21:37 ID:quQ96n4z

マークアップがおかしくなるというのは段落としての意味な。

そういえば、どこかでやっていた、
改行1個は<br>で改行2個は</p><p>にするってのも良い方法かな。
そして行末の改行を削除するようにすればかなりイイカモ。

201 ：Name_Not_Found：02/02/26 21:39 ID:UNzMkZrJ

>>196
もっと言えば、未登録の公開識別子なんて殆ど意味を持たんのです。

例えば「ワーノレドワイドウェブ協会」を名乗る団体も
-//W3C//DTD HTML 4.01//EN (システム識別子 isoternet-html.dtd)
という DTD を公開しているかも知れない。(普通に有り得る)

その場合、

　OVERRIDE YES
　PUBLIC "-//W3C//DTD HTML 4.01//EN" isoternet-html.dtd

とかやっている人も当然いる訳です。
すると、この人のパーザでは

　<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">

な文書の DTD は、'strict.dtd' じゃなく 'isoternet-html.dtd' と
みなされることになってしまいます。

そういう紛らわしさを取り除くためにも
システム識別子は記述した方が宜しいのです。
そのために XML ではシステム識別子の省略が禁止されているわけですし。

# 「Strict 的には」というより「原理的には」と言った方がｲｲか？

202 ：190：02/02/26 22:14 ID:hMLdRlcn

>>201
むう、なるほど。解説ありがとうございます。

203 ：Name_Not_Found：02/02/26 22:48 ID:Uh7vew9A

>>199
ここのStrictBBSが、それやってます。
ttp://haruno.fam.cx/~sawatari/

204 ：Name_Not_Found：02/02/26 23:03 ID:TFmhxF6k

>>203
144でｶﾞｲｼｭﾂ

205 ：Name_Not_Found：02/02/27 14:48 ID:uAmuoWFp

既出かもしれませんが。

ABBRとACRONYMってどっち使えばよいですか？
この2つの意味が違うのはわかるんですけど、
IEだとABBRが意味なし状態じゃないですか。
それでもあえてABBRを使う方が良いのでしょうか？

206 ：Name_Not_Found：02/02/27 14:50 ID:HC0rMZGW

http://www5d.biglobe.ne.jp/~musume/

レッツゴー！！

207 ：Name_Not_Found：02/02/27 14:57 ID:d1blcvod

>>205
略語と頭文語の違い自体が日本語的になじみの無いものだし、
また abbr ⊃ acronym なので、自分は全部 abbr です。面倒だし。
IE はこの際放置の方向で。
むしろ「 IE が abbr に非対応で acronym にだけ対応してるから」という
理由で acronym のみ使う方がアレかと。

208 ：Name_Not_Found：02/02/27 15:03 ID:mVEx0MoM

W3C的にはabbrだけでいいらしい
acronymはIE4がすでに実装していたので、
Microsoftが仕様に加えろと主張して、、
という理由で仕様に加えられたらしい

よく略語と頭字語で使い分けると説明されてるけど
その説明もIEに配慮してこじつけた物らしい

IEもMacならabbr使えるんだけどね。
でもW3CのサイトもIEを意識してるのか、
それはabbrだろ、というものでもacronym使ってるし、
IEで意味無しになるのがいやならacronym使えば
いいんでないかな。

209 ：205：02/02/27 15:05 ID:uAmuoWFp

>>207
レスどうもです。
僕もとりあえずはABBRを使っていようと思います。
でも、IEを無視するのは初めて(w

参考：
http://www.htmlhelp.com/ja/reference/html40/phrase/abbr.html
http://www.hajimeteno.ne.jp/html40/a/abbr-e.html
http://www.kanzaki.com/docs/html/htminfo14.html#abbr-acr

210 ：Name_Not_Found：02/02/27 17:38 ID:c4eNdm+Z

>>208
近藤＠古代図書館氏のところで、それを見た時には愕然とした記憶が。

>>209
度胸有るなあ。
↓の様にやらないと気が済まないんだけど。

<abbr title="Japan Racing Association">
<span title="Japan Racing Association" class="abbr">JRA</span>
</abbr>

211 ：Name_Not_Found：02/02/27 18:04 ID:5hbaNirC

>>210
IEで略語のフルスペルが伝わらないことより、
秀丸での編集時に面倒が増える（冗長なタグが増える）ことの方が僕には問題です。

212 ：Name_Not_Found：02/02/27 18:11 ID:5sIuXFKO

>>208
そーだったのか！
勉強になたよ。ありが㌧。

オイラは秀和システムの本に書かれてる通りに
使い分けてるね、IE無視で。

213 ：Name_Not_Found：02/02/27 18:17 ID:jan7ucV+

>>210
それはちっともStrictじゃあないだろう。

214 ：Name_Not_Found：02/02/27 18:19 ID:nZAI9456

abbrが反映されなくても別に問題ないじゃん
ソースを汚すほうが問題

215 ：Name_Not_Found：02/02/27 18:22 ID:0tnjVsDc

> オイラは秀和システムの本に書かれてる通り

あれはどうも俗説らしい。
一応「辞書的」な意味では「頭文字をつないだのが acronym」で
「とにかく略語なら abbr」ということらしく。

とりあえず↓これを読めば全ての疑問は解決するかと。
ttp://www.alib.jp/diary/diary_200111.html#diary_20011129c

216 ：Name_Not_Found：02/02/27 18:36 ID:EbSgYDb4

て優香 acronym を IE4β 当時から実装していたのに
abbr を未だに実装*できない* IE って謎だ…。

217 ：Name_Not_Found：02/02/27 18:55 ID:F+hiclu/

abbrって、何回も同一ページ以内で使う物なんですか？
例えば
<abbr title="Internet Explorer">IE</abbr>はマイクロソフトの…（略）…
そして、IE6.0にはCSSの実装に置いて…云々…
って言うときに、IE6.0の方にもabbrを使うべきでしょうか？
やはり使うべきですよね？

218 ：Name_Not_Found：02/02/27 19:03 ID:KznI4Wku

需要がない（誰もabbr実装きぼんぬとメールを出さない）のでは＞abbr
いや、知らんけど。

219 ：Name_Not_Found：02/02/27 19:07 ID:uweDPFi/

弱気なあなたが好き

220 ：216：02/02/27 19:11 ID:EbSgYDb4

>>218
や、近藤＠古代図書館氏の
> IE4 βが acronym 要素しか対応してないんだってことでしょうがないから
ってのが素人目には凄く奇妙に見えるんだよ。
acronym と同じ挙動をする要素1個増やすのってそんな大変？って。
仕様側をいじるほどのことにはとても思えなくて。漏れが素人だからかな。

221 ：Name_Not_Found：02/02/27 19:17 ID:0tnjVsDc

>>220
M$ なりの W3C に対する抵抗なのでは(ﾜﾗ

222 ：j君：02/02/27 19:44 ID:nZAI9456

ＭＳの子供っぽい意地じゃないの？

aabrじゃなくてacronymつかってくれなきゃいやだーっていう

223 ：七死：02/02/27 19:45 ID:fskBhPTb

>>221
あんがいそうかもしれないね。
技術的にクリアな部分だけに、可能性は否定出来ない。

224 ：Name_Not_Found：02/02/27 20:00 ID:EbSgYDb4

IE6 の微妙にｲﾀｲところは作者が厨だからなのね...。

225 ：j君：02/02/27 20:07 ID:nZAI9456

226 ：Name_Not_Found：02/02/27 20:11 ID:KznI4Wku

>>220
技術的には簡単でも、誰もabbr実装きぼんぬと言わなきゃ実装しないでしょ。
あるいはMSの抵抗か、それともただ単に忘れているだけなのかもしれん。

# Macintosh Editionの方は実装してるんだよね。
チーム間の協力とかはないのか？

227 ：Name_Not_Found：02/02/27 20:33 ID:tER8dZy/

MacのIEとWinのIEは全く別のものとして考えた方が・・・
使い勝手も全然違うし。

228 ：茶文字 ◆xELvisFU ：02/02/27 21:07 ID:786aVNTU

嵜ﾀﾝが書いてたんだっけ？
どうやらWinIEはバージョンごとに開発陣が交替しているフシがあるって。
つまりVer6の開発陣≒Ver4の開発陣　Ver5の開発陣≒Ver3の開発陣。
これが真実なのか、だとしても人事交流くらいはあるだろとか疑問もあるけど。

MacIE開発陣がどういう位置づけかはさらに謎だね。
実装見てると完全に独立したチームとして動いてるような気がするけど。
MSの社風は知らんしMac用のMS製品はIEしか使ってないからよくわからんが。

229 ：Name_Not_Found：02/02/27 21:58 ID:0tnjVsDc

ちなみに MacIE のチームは解散させられたらしいという話を
一年くらい前に読んだ。激しく打つだ。

230 ：Name_Not_Found：02/02/27 22:13 ID:gByKj7xz

>>229
漏れなんか WinIE も ver6 で開発終了って話をどこかで読んだぞ。
さすがにネタだろうと思うんだが。

231 ：Name_Not_Found：02/02/27 23:26 ID:5sIuXFKO

>>215
∑(ﾟдﾟlll)ｶﾞｰﾝ
じゃぁ、<abbr title="Internet Explorer">IE</abbr>でなくて
<acronym title="Internet Explorer">IE</acronym>ってすべきなの？
全部書き換えなけりゃいけないじゃん・・・（ｳﾂ

232 ：Name_Not_Found：02/02/27 23:58 ID:0tnjVsDc

>>231
だから、W3C 的には abbr でいいんだってば。

233 ：Name_Not_Found：02/02/28 01:16 ID:d4YjxDRu

だいたい span 要素に title 属性をつけただけでも
ポップアップで表示してくれるのに、何故 abbr の
ときだけはきっちり無視しやがりますか。＞ IE

234 ：Name_Not_Found：02/02/28 01:20 ID:KU+PQOcB

>>233
abbr って要素を認識できないからでしょ。
Moz/N6 は適当な要素を捏造してもちゃんと反応するし
スタイルも適用されるけど。
IE は知らない要素→無視だから。

235 ：Name_Not_Found：02/02/28 01:22 ID:Gncyr8o2

>>233
知らない要素は完全無視してるだけでは。
<aho title="ahoaho">あほ</aho>
って書いて無視されるのと一緒かと。

つーかabbr無視するな＞IE

236 ：235：02/02/28 01:23 ID:Gncyr8o2

>>234 ｹｺｰﾝ

237 ：Name_Not_Found：02/02/28 03:28 ID:SmoVHGWE

<th>夏</th>

th要素にはabbr属性を入れましょう

lint厨なのはわかるが
気になってしゃーない・・
これさえなければ満点なのに・・。
夏なんて短縮しようがない

238 ：Name_Not_Found：02/02/28 03:46 ID:KDgjkE5n

短縮っていうか、ヘッダに即した値なら指定する必要はないだろ
そんなにソース肥やしたいのかと

239 ：Name_Not_Found：02/02/28 06:10 ID:ENDFFDPa

>>237
<th abbr="夏">夏</th> で良い。
何も指定しないよりは、色々な意味でこの方が親切だと思うよ。
「どんな言葉を読み上げさせるかの指定」というか、
img の alt のように考えるのが良いのではないかと。

240 ：Name_Not_Found：02/02/28 07:18 ID:sKH/ZJgY

>>239
abbr 属性がなかったら中身をそのまま使うって解釈するだろう、普通。
冗長すぎるのもどうかと思うよ。

241 ：Name_Not_Found：02/02/28 07:45 ID:j3/L0CGF

>>233-235
むしろ IE は知らない要素→空要素。
<abbr title="Internet Explorer">IE</abbr> を
<abbr title="Internet Explorer" />IE</abbr /> としているフシがある。
JavaScript とかで見ると innerHTML とかには ABBR 要素のタグが残るし、
getElementById で要素自身や title 属性を取得したりすることができる。

242 ：yuu ◆xo3ilszg ：02/02/28 10:15 ID:vdT+h+Q+

>>240
abbrの値を尊重するUAの可能性を想定すれば、<th abbr="夏">夏</th> でも
別に冗長ではないと思う。

243 ：Name_Not_Found：02/02/28 10:53 ID:rnFSEg6e

>>242
>>242
abbrがないときに内容を採らないのだとすれば、そんな糞仕様のUAが悪い。
それじゃー、AHLのためにabbrを書けと言ってるのと大差ないよ。

244 ：Name_Not_Found：02/02/28 12:14 ID:dtphLn9N

知らない要素を無視するのはWebブラウザの挙動として正しいんじゃない?
寧ろ知らない要素でも反応しちゃうMozillaの方が独自拡張じゃないかと
思ったりしてるんだが、そこらへんW3C的にはどう主張されてるんだろうか。

245 ：Name_Not_Found：02/02/28 13:48 ID:j3/L0CGF

>>244
> Webブラウザの挙動として正しいんじゃない?
それが HTML 文書なら、間違ってはいない。
HTML4 的には認識できない要素も内容のレンダリングを試みよ、となっているだけ。
(JavaScript/CSS等から利用するための)文書の木構造化への注意書きは特にない。

HTML4 対応 UA なら abbr は正しく扱われなきゃいけないハズだけど
認識できないなら、それはそれで要は不正文書の処理なわけで
どんな処理したって独自拡張だよ。規定がないんだから。

246 ：Name_Not_Found：02/02/28 15:12 ID:SmoVHGWE

<th>木</th><th abbr="ガ合金">ガンダリウム合金</th>

みたいに同一table内にabbrのあるやつとないやつがあった場合
どうよ？足並みそろってないと美しくない

247 ：Name_Not_Found：02/02/28 15:44 ID:5PSAThSs

>>246
足並みを揃えるって……。
略せない内容、ヘッダに即した内容なら無理してabbrを書く必要は無い。>>238と>>240に賛成。

248 ：Name_Not_Found：02/02/28 15:58 ID:SmoVHGWE

なら意味のないaltも書かないほうがいいかな？
一部、絶対altに何かいれやがれって派がいるみたいだが・・

249 ：Name_Not_Found：02/02/28 16:09 ID:jai9uHYG

>>248
alt=""がイヤなの？
Lynx とかだと

<img src="hoge.png">オマエモナー
が

[hoge.png]オマエモナー

みたいに表示されてうっとうしい。

<img src="hoge.png" alt="">オマエモナー
だったら

オマエモナー

になるので、ホントに意味のない画像だったら、
alt="" が一番嬉しいし、文法的にも正しい。

250 ：茶文字 ◆xELvisFU ：02/02/28 16:22 ID:eWwLuoK2

MS的には "abbrを処理しない" のではなくて "abbrはレンダリングしない" という
「処理」をしているのかもしれない、とちょっと思った。
２ちゃんでよくある「放置の方向で」ってやつ？（ｗ

251 ：Name_Not_Found：02/02/28 18:48 ID:0z8pLwsk

altは必須じゃ？
意味のない画像は249氏が言うように alt="" と書く。

252 ：Name_Not_Found：02/02/28 19:36 ID:sNSNCKOi

>252
ただ漏れはよほどの事がない限り alt="" は使わない。

代替するに値する内容がない≒意味のない画像を使おうとしない。
マーカーとして使うなら

hoge:before{content:url("hoge.png")}

にしてしまう。。

253 ：j君：02/02/28 19:42 ID:IA6iDwCW

altを書けないような画像なら最初からうｐするんじゃねえよ
という意味なんでは？

254 ：ちょこら ◆DmcC0DXc ：02/02/28 21:40 ID:3teETut8

http://www.alib.jp/diary/diary.html#diary_20020228b
シンプルに同意。

255 ：Name_Not_Found：02/03/01 17:37 ID:4ffCjQg2

alibっていつ行っても重い…

256 ：Name_Not_Found：02/03/01 18:00 ID:qi+UNfUC

>>255
同意っつーか多分>>255 MacIE 5.x ユーザでしょ。
MacIE 5.x は CSS の構成によって表示に滅茶苦茶時間が掛かるんだYO!
近藤さん対処してくれないかな…。

257 ：Name_Not_Found：02/03/01 20:35 ID:ST/+o9JV

>>256
@importがだめなの？

258 ：Name_Not_Found：02/03/01 21:07 ID:Z2mSoK3M

>>257
代替スタイルじゃないの？

259 ：Name_Not_Found：02/03/02 02:44 ID:EvTR69fq

>>255 >>256
申し訳ない、一応対処してみたけどどう?

# IRC で伝えてもらって初めて知りました > 遅い

260 ：Name_Not_Found：02/03/02 03:26 ID:C3WidJ1A

IDが微妙にW3C記念

261 ：Name_Not_Found：02/03/02 14:04 ID:SQRDnKFW

>>259
まだ重いのです。ローカルに保存すると爆速で表示されるので、
ファイルの転送に手間取っているのかも知れません。

昨日調べたときは block.css がさっぱり送られてきませんでした。
これは現在改善されていますが、alt_form.css と alt_anchor.css が依然
取得できないようです。

MacIE 5.x は代替スタイルシートも読み込んでいるようなので、
恐らく原因はこの辺りかと…。とりあえず対処に感謝 sage 。

262 ：Name_Not_Found：02/03/02 15:59 ID:ZuvMyEPa

一般的にはimg要素のwidthとheightって指定した方がｲｲって事になって
るけど、Strict的にはどうなの？
それともimg要素なんか使うな？

263 ：Name_Not_Found：02/03/02 16:07 ID:nHKzy8hK

>>262
Strict的には非推奨属性。理由は知らないけど。
指定した方がいいというのは、UAのレンダリング効率を助けて、
実感速度が速くなるので、親切だろうということ。
img要素なんか使うなと言うことはない。

264 ：Name_Not_Found：02/03/02 16:25 ID:SQRDnKFW

>>263
> Strict的には非推奨属性。

ソースｷﾎﾞﾇ。W3C 系の HTML では非推奨ではありませんが。
(ISO-HTML に存在しないというのはあまり関係ないし)

画像にとっての表示サイズっていうのは
論理的に必要なものの気がします。

文字サイズと違って、画像の縦横比なんかを
意図しないものに変えられるのは困ると思うし
(オーサ的にもユーザ的にも)。

265 ：255@Mac OS 9.2.2&IE5：02/03/02 16:32 ID:4pPc7mTX

>>259
朝方と今、行ってみました。
簡単に時間を計ってみたところ、当方の環境では表示に約40秒かかるようです。
待っている間は画面が真っ白ということも相まって、余計に遅く感じているかもしれません。

皆さん、スレ違い申し訳ありません。

266 ：Name_Not_Found：02/03/02 16:47 ID:nHKzy8hK

>>264
> >>263
> > Strict的には非推奨属性。
> ソースｷﾎﾞﾇ。W3C 系の HTML では非推奨ではありませんが。
> (ISO-HTML に存在しないというのはあまり関係ないし)
勘違いしてました…。指摘ありがとう。

267 ：262：02/03/02 16:56 ID:ZuvMyEPa

書いとくことにします。回答ありがとう。

関係無いけど、XHTML 1.1で書いててLintで100点なのに、レンタル
のアクセス解析とWEBリングで-98点まで下がってしまう…。

268 ：j君：02/03/02 17:39 ID:M96OdYs1

アクセス解析のimg要素にもちゃんとalt属性をつけよう

269 ：j君：02/03/02 17:41 ID:M96OdYs1

lintの点数には関係ナいけどね

270 ：Name_Not_Found：02/03/02 17:55 ID:elge25Um

strictでカスタマイズが容易(id, classを変えやすい)で、
フリーでナイスなCGIサイト作ろうかな。春休みだし。
完成は1年後くらいで。

271 ：Name_Not_Found：02/03/02 18:22 ID:Z/OJe9OV

>>270
そのカスタマイズが容易って部分が一番面倒くさい。
自分用に作るならチグハグで良いけど、配布用は分かりやすく仕様を決めなくちゃ
いけないからなぁ。でも、頑張って！
陰ながらPerl愛好者として見守ってるYO（Perlだよね？PHPじゃないよね、Rubyじゃないよね、Cじゃないよね、JAVAじゃないよね）

272 ：茶文字 ◆xELvisFU ：02/03/02 18:28 ID:HqLqNcG8

>>270
これから1年間春休みですか？(わら
Strictスレで似たような話になっていたのでちょっとずつスクリプトいじってます。
レイアウトの多くをCSSで外部からコントロールできるようにすれば、
喜ぶ人は多いと思いますよ。
おたがいがんばりませう。

# 本日スレ違いレスの多い私；

273 ：Name_Not_Found：02/03/02 18:33 ID:elge25Um

あいよー。がんばります。
春から社会人なんで、春休み中になんとか、、、

274 ：Name_Not_Found：02/03/02 18:35 ID:OreAbXkN

>>267
&を&にしなくてはならないのに、していないところ多いよね。

275 ：茶文字 ◆xELvisFU ：02/03/02 18:41 ID:HqLqNcG8

>>272自己レス
ｽﾏｿ
別スレに移動しようとしてフリーズしてから書いたので、
あたかもStrictスレがよそのスレであるような書き方をしてしまった。
ちっともスレ違いぢゃないぢゃん；

276 ：Name_Not_Found：02/03/02 18:41 ID:EAHTitGe

>>274
言いたいことは分かるんだけどね

277 ：Name_Not_Found：02/03/02 18:43 ID:vggno6Vw

>>274
& を & にってことだよね?
あれは見逃しがちだよね。
実は俺も初めてHTMLを書いてから4年間くらい知らなかった。

278 ：274：02/03/02 18:51 ID:OreAbXkN

>>277
その通りです。スマソ。

279 ：Name_Not_Found：02/03/02 20:35 ID:EvTR69fq

>>261

他にもないか、一応 *.css で確認してみて
alt_form.css と alt_anchor.css だけが同じ状態だったので、
こちらも同様に対処しました。

ご指摘感謝。

280 ：255：02/03/02 22:15 ID:4pPc7mTX

>>279
なんと！6秒で表示されるようになりました。
修正ありがとうございました。

281 ：Name_Not_Found：02/03/02 23:17 ID:FBGbeoJm

>>277
あと、noscript直下にインラインのimg要素は書けないので、
p要素かdiv要素を使ってみよう！

といってみるテスト。

282 ：Name_Not_Found：02/03/03 14:10 ID:aA8bISGS

img要素のwidth,height
input要素のsize
textarea要素のrows

これらは論理マークアップ的にOKと言えるのか？

283 ：Name_Not_Found：02/03/03 14:37 ID:RVU8q39+

>>282
> input要素のsize
> textarea要素のrows

これは俺も疑問。imodeに向いてないし。

284 ：Name_Not_Found：02/03/03 16:55 ID:X9E/JSbG

>>282
CSS でいう置換要素、ということになると思うが
「論理マークアップ」という観点で見て、これらは論理要素か？
論理要素であるならば、その理由は？
論理要素でないならば、物理的な属性の是非を問う意味は？

285 ：Name_Not_Found：02/03/03 20:30 ID:xpKcwZ6i

CSSで行うとすれば
input {width:12em;}
みたいになるのだろうか？
しかし、textareaのrows属性は必須だしなあ。

286 ：Name_Not_Found：02/03/03 20:55 ID:UrqVSZed

必須である限りは書くしか。後はいずれ
改善してもらえるように頼むのか。

必須属性がないファイルってことは壊れた画像ファイルや
音楽ファイルと同義だﾓﾝﾅｰ｡

287 ：89：02/03/04 23:53 ID:fRfrHo9H

すっごい基本しか出来てないけど晒していいすか？
今日は寝るけど・・・。

288 ：Name_Not_Found：02/03/05 02:00 ID:UjmHQNvT

>>286
XFormsではなくなる。

289 ：Name_Not_Found：02/03/05 07:56 ID:Ks0FstOR

ISO-HTMLを使っているだけあって、ﾉｼﾞﾀｿ的には付けなくて良いと思って
いるらしい
http://members.jcom.home.ne.jp/pctips/www/faq/ImgHW.html

290 ：Name_Not_Found：02/03/05 12:59 ID:pun6c7RL

>>289
あ～漢字気持ち悪い。

291 ：Name_Not_Found：02/03/05 13:45 ID:rGC9qJCp

> 新しめのブラウザでは、畫像が來ない時點では適當にレイアウトして、
> 後から調整する、と云ふ動作をします。

これがいかんのだと思うのだが。
ちっこいサムネイルをｲﾊﾟｰｲ貼ってる時なんか
これじゃ再レンダリングの嵐だろ。

292 ：Name_Not_Found：02/03/05 13:58 ID:pun6c7RL

状況によってはサイズを指定するようにしてる。基本的にはしない。
妙な仮名遣いもしない。人が読めない漢字も書かない。

293 ：Name_Not_Found：02/03/05 14:16 ID:FK0uxvKG

ﾉｼﾞﾀｿには是非<ruby>タグを使っていただきたい

294 ：Name_Not_Found：02/03/05 14:52 ID:pun6c7RL

>ウェブ制作者は、「美しい表示」に目が眩み、
>互換性を無視してメーカの戰略に進んで乘つからうとしてきました。
>その結果、當然の話ですが、ウェブには互換性の低い、
>汎用性のない文書が溢れかへることになりました。
- http://members.jcom.home.ne.jp/pctips/www/Compatibility.html より引用

こんな事を曰っておられるが、
<>の内側のことばかりにこだわりすぎて、
<>の外側については何にも考えてなさそうだな。
自己陶酔は困るよ。tableレイアウトしまくりのかっこつけサイトとある意味同類。
ホームページリーダーはこれ読めるのか？
一般的に読みやすい文を書くべきじゃないか？

295 ：茶文字 ◆xELvisFU ：02/03/05 15:17 ID:w6Da6yj5

>>294
ロジック(論旨)とビジュアル(漢字・かな使い)は分離すべきだよな。

/* nojitan.css */
body {
　text-transform : old-jp ;
}

296 ：Name_Not_Found：02/03/05 16:25 ID:Ks0FstOR

旧漢字使用の是非は兎も角、旧漢字が読めない義務教育修了者ってやだな

297 ：Name_Not_Found：02/03/05 16:47 ID:dkxKl48+

旧かなづかいなんて漢字悪いね

298 ：茶文字 ◆xELvisFU ：02/03/05 16:58 ID:w6Da6yj5

>>296
義務教育の学習指導要領に旧漢字の習得が入ってないから、
いやだと思うのは自由だが、読めることを期待して裏切られても
それわしかたがないのでは？

それを言い出せば、中学レベルの英語力で読める海外ドキュメントだって
まともに読む人は少ないわけで。
中学生は古文法の一部を習うけど、古文で書かれたコンテンツがあるとしたら、
資料性を自ら落としていることになる。

情報提供者は、それを必要としている人が読みやすい形で提供する努力をするべき。
たとえばとほほの内容はStrict的に評価すればたいしたことない部分もあるけど、
初心者に案内するにはやっぱりとほほになっちまう。
とほほの最大の功績は「わかりやすさ」にあると思うからね。
いくら鳩丸がよくできたコンテンツでも、読み手が初心者なら紹介してもつらい。

以前出てきた「Strictで初心者向けのサイトが欲しい」ってのは、
つまりそういうことだったと思うよ。

と、Strictの話に無理やり戻してみるテスト

299 ：Name_Not_Found：02/03/05 17:15 ID:gdtiHeG0

>>298を受けて。

見た目から入りがちな「ホームページ」初心者に向けた
「Strictで初心者向けのサイト」には何が必要だと思う？

俺はある種の規律と形から入ることだと思う。
厨房がやりたがることをすべて「初心者には無理」と決めつけて
基礎をみっちり叩きこむ。

言ってみれば「ホームページ道」だな。

と妄想してみたがどうだろう？

300 ：粘着モード：02/03/05 17:33 ID:pun6c7RL

※Sorry, unreasonable Japanese only.
※此のサイトを御覽になるにはIE5、またはNN4以上が必要です。
　といふ亊は無ひが、その代はり、旧漢字、旧仮名遣ひを讀む能力が必要です。

既出そうだしスレ汚しごめんなさいsage

301 ：茶文字 ◆xELvisFU ：02/03/05 17:37 ID:w6Da6yj5

>>299
それそれ、そんな感じ。
今リファレンスを作ってるんだけど、いわゆる「ホームページ道」みたいなのは
コラムにして同一サイト内の別ページという扱いにしてるのね。
本文に練り込めればいいんだけど、冗長になると読まれないからなぁ、ってのが悩み。

302 ：Name_Not_Found：02/03/05 17:47 ID:1WrVego9

神崎さんちにある30分HTML入門じゃだめなの？
アレくらいわかりやすいのはそうないと思うけど。

303 ：Name_Not_Found：02/03/05 17:55 ID:dU5OKpCM

>>302
複数あったほうが、読み手が選べて便利だとおもう。

>>301
できたらURLさらしてくださり。

304 ：Name_Not_Found：02/03/05 18:03 ID:LB4F/GJT

つか、このスレ住人で知らないやつがいたとは、あんたモグリだな。

http://kanzaki.com/docs/html/lesson1.html
個人的には、これ↑読んで理解できたら、
http://kanzaki.com/docs/htminfo.html
ここ↑読んで、
で、納得できるようなやつならいきなりばけらっても大丈夫だと思う。

305 ：43：02/03/05 18:08 ID:G5ASKod0

>>43で内田氏の「はじめての～」を勧めたんだけど、あれのいいところは、

・まずはじめに文章があって、そこに適切なマークアップを施す。

という基本を押さえている一方で、スタイルシートで色をつけてみようという
話題が前の方に出てきていたりして、カラフルな「ほーむぺーじ」を作りたい
初心者に対する配慮ができていることだと思うんだよね。

あと、レガシーマークアップとStrictの違いを意識させずに、自然にStrictな
マークアップに導いていると思う。

これから初心者向けのサイトを作るなら、その辺のことを意識してほしい。

306 ：299：02/03/05 18:11 ID:gdtiHeG0

>>302
厨房は30分HTML入門を読んでも、
「で、MIDIを鳴らすのはどうしたらいいの？」
とか言い出しかねないのが問題。
あと文章がリアル厨向けではない。

で、「道」とわざわざ言ったのは、
厳しい制限と正しい型(見本)こそが初心者には必要じゃないかってこと。

307 ：299：02/03/05 18:17 ID:gdtiHeG0

妄想続き。

「ホームページ道」を教えるサイトは当然「道場」で、lintで段位認定あり。

でW3C信者じゃなくてW3C門下生。

308 ：茶文字 ◆xELvisFU ：02/03/05 18:23 ID:w6Da6yj5

>>306に禿同。
普段リアル厨相手にしてるから、WebKANZAKIすら敷居が高いと思う。

そういう面では内田さんのは秀逸だね。
特に「違いを意識させずに、自然にStrictな」って部分がいいい。
# 305の表現はすごくいいまとめだと思う。

あとは分量の問題で、「BGMをならしたい」という要求にも対応する情報が
掲載されているか？という具体論になる。
非Strictならembedとか言い出すわけだが、こういう問いにStrictな入門サイトとして
どう切り返していくか。

方向性の違いはあれど、少なくともとほほには対応する情報があるわけだ。
初心者にとって「信頼できるけど、求める情報はないかも知れない」サイトと
「ときどき叩かれるけど、とりあえず全部揃ってる」サイトとどっちが身近かってことだな。

309 ：299：02/03/05 19:07 ID:gdtiHeG0

>>308
分量の問題はしょうがないので、
(とほほにしたって最初からあの量だったわけじゃ無し)
必要最低限が揃ってから考えるのは？

310 ：茶文字 ◆xELvisFU ：02/03/05 19:41 ID:w6Da6yj5

>>309
現実的にはそういうことになるでしょうね。
入門サイトのひとつの例として、匿名ユーザが前提の２ちゃんねらで
集団執筆っつーのは面白いと思う。
どうせ匿名だから、二次利用自由にして、ｲｲと思ったところは勝手に使ってね、と。
HTML～XHTMLが得意な人の多いスレだけど、他にも得意分野はあるだろうから
分担してけば項目は増やせるっしょ。

正直２ちゃんねるで自サイト晒すのは今のところ避けたいが、
自分の考えたノウハウを提供するのにやぶさかではないんだな。
そういう意味で上記のような形態を考えたんだけど、どうでせう。

311 ：Name_Not_Found：02/03/06 01:00 ID:fBFv4BVb

>>305-306
こんなこといっても何も始まらないのは解っているんだけど、
要するに吉野家コピペ状態というか、
「お前ら、MIDIっていいたいだけ～」なんだよね。

http://pc.2ch.net/test/read.cgi/hp/1014951588/
のスレが成立するのも、
要するに「作ることありき」で始まってるからであって、
本当に最初に文章が有るのかどうかが疑わしいのが
ネックになってくる気がする。

ゴメン、何か水を差したみたいで。

312 ：Name_Not_Found：02/03/06 03:06 ID:MUMKnXyT

>311
禿堂。
ただ、CGやMIDI配布サイトでもきちんとした配慮があるところ
もちろんもある。

サイトの目的がなくて、「とりあえずBGM｣と言うのが大問題。
おまえは本当にサイトを作りたかったのかと（以下略

313 ：：02/03/06 03:11 ID:oG608N/V

<pre>の中に<big>要素はだめといいます。では

em{font-size:larger;}
<pre><em>問い詰めたい</em>

はどう？だめ？

314 ： ◆HTML/.Kg ：02/03/06 03:25 ID:/97bq0UO

>>313
かまわないと思うけれど、何が問いたいの？

315 ：茶文字 ◆xELvisFU ：02/03/06 03:28 ID:IiUH4+u9

>>313
preが指定された範囲は全幅が決まるから、フォントサイズを変えるようなマークアップは
全幅を変更してしまう可能性があるために禁止、ってことでそ？
CSS使った結果全幅が変わったらあかんのでわ？

316 ：Name_Not_Found：02/03/06 05:34 ID:+ZbPosYv

>>280

標準スタイルを弄っている途中だったので、ついでに色々と変えてみた。

top を段組スタイルに戻したので代替スタイルの提供もやめ。
もうすこし速くなったと思うが、どうかな。

317 ：Name_Not_Found：02/03/06 08:13 ID:m1Ey1/7I

>>311-312
初心者向けって、そこまで面倒見なきゃいけないのかなあとか思った。
まず最初に、文章なりCGなりMIDIなりの、何か伝えたいことがある。
何の予備知識もない入門者にも、そのくらいは要求していいのでは。

もちろん、見栄え・BGM 等の装飾と伝えたいこととを
切り離して考えることは最初は難しいから、
そこは上手く誘導してやる必要があるけれど。

318 ：　：02/03/06 08:46 ID:DZfLcbLc

p{white-space:pre;}

<p><img src="moner.jpg" alt="逝ってヨシ">
もうね、アホカト（略）
</p>

ってok?preった要素に置換要素はめこんでいいかしら？

319 ：Name_Not_Found：02/03/06 08:53 ID:QlJFtZQS

>>318
2ch語連発はうざくないかしら？

素直に最初からpreで囲まないのは何故？
ちなみにpre内のimgは×らしい。

320 ：311：02/03/06 15:26 ID:fBFv4BVb

>>317

かなり鬱入ってたけど、あれで言いたかったのは
「文章なりCGなりMIDIなりの、何か伝えたいこと」すら無いのに、
作ろうとしてる初心者が多いってこと。

StrictなHTMLの基本は、まず「文章ありき」な訳だから、
その「伝えたいこと」が無いのに作ろうとしてたら、
そりゃ見た目やMIDIに走るのは当然で、
どうやってもStrictにはならないと思うんだ。

この認識のズレを解消しないと、そりゃ内田氏のだって、
CSS使う以上は<font color="">～</font>より直感的とは言い難いからね。

そうなってくると、Strictであることメリットというよりは、
むしろCSSを使うメリットを強調すべき
（例えばblockquoteでmargin取る以上に、CSSでmarginとった方が自在だとか）
じゃないかと。
その上で、LinkingStyleSheetsを使う様にして、
「Strictで無いと、後が面倒だね」という方向に持っていければ
良いのでは、と思う。

まあ、このスレの住人だって、最初は文書より、
「とりあえず作ってみよう」という思いも多少はあったと思うんだ。
そんな状態なのに、
UAデフォルトスタイルシートのモノクロ画面を眺めながら作るという作業が
面白いとはとても思えないってこと。

文句ばっかいっててもしょうがないので、解決例としては、
サイト内で数種類面白いCSSファイルを提供して、
「Strict＋CSSではこんなにカスタマイズが利きますよ。」
っていうのが良いかも。
http://www.officek.jp/skyg/wn/?20020213
ちょうどこんな感じで。

321 ：299：02/03/06 17:08 ID:y+HY5W73

>>320
＞むしろCSSを使うメリットを強調すべき
禿同。

コンテンツは自己紹介と日記とリンク(とindex)でいいと思う。
入門的には中身を決めつけたほうが構造の制御がしやすいので
とりあえずHTMLはこう書け、次にcssで大きさや位置をいじり倒す
とデザイン自由自在だぜ、と言う流れ。
HTMLはあまり弄るもんじゃないという感じで。

入門のデフォルトスタイルシートを用意して、
「とりあえず作業ディレクトリにこれ置いておけ」
としておくのも、UAデフォルトがつまらないから変な方向に走る
厨房対策にはいいかも。

322 ：　：02/03/06 18:03 ID:DZfLcbLc

preじゃなくてpを使うのがstrict信者
しかるにpreを効かせたp要素にpreに入れちゃだめな
img要素を入れてよいのかどうも分からないのです。
だめと書いてないし・・・いいのかな？

323 ：317：02/03/06 20:15 ID:m1Ey1/7I

>>320
漏れもｳﾄｩ入ってたかな。 317 では
目的のない者に Strict を教えることは無理だろうと言いたかったんだ。

CSS のメリットか…
valid なだけの div/span 厨が増えそうだけど
最初はそれでもいいのかなあ。
同じ意味のところが同じ見た目になっている(と読みやすい)ってところまで
持ってければ Best だよね。

このスレの住人が Strict に入っていったきっかけって、
どんなものがあるんだろう？

漏れの場合は、文責を address タグで囲むのってちょっとｶｺｲｲ、とかそんなだったけど。
当時 Strict 仕様を知ってはいたけど、むしろ否定的に考えてた。 CSS 実装寒かったし。
でも、どこのサイトか忘れたけどすんげー綺麗なソース見て、考え方変わった。
ｽﾊﾞﾗｼｲ!漏れもこんなの書きたい!! って現在に至ってる。

324 ：茶文字 ◆xELvisFU ：02/03/06 20:45 ID:IiUH4+u9

>>323
私の場合はタグに埋め込むCSSを知って、表現力にﾋﾞｸｰﾘ。
持ってた本とか参考にしてたサイト見て勉強してた。

最初はStrictって「なんでこんな便利なfontが使えなくなる？」だったけど、
CSSの能力を発揮しようと思ったら自然とvalidな方向に向いてきて、
Strictの精神にも抵抗なくなってきた……って感じかな。

閑話休題。

Strictな例のソースと一緒に、Obsoleteなソース(ただし見た目や機能はほぼ同じ)も
展示して比較できるようにしたらどうだろう。
「ほーら、こんなにきれいになりましたー(当社比)」つー感じで。

325 ：Name_Not_Found：02/03/06 20:51 ID:Jnpum7RL

サイト制作を始めてしばらく立ってからCSSを使ってるデザインテンプレートを落としたのがきっかけ。
それもdiv/spanばっかりのでStrictとは懸け離れたものだけど
それからCSSについて調べ始めたのでこれがきっかけ。
で、CSSを少し覚え始めた頃に2chでこのスレをﾊｹｰｿし、Strictを知ったよ。
茶文字さん、有難う。

326 ：茶文字 ◆xELvisFU ：02/03/06 21:37 ID:IiUH4+u9

そういえば私もこないだ正体を知ったところなんだけど、
CVS(Concurrent Version System)の出力をaddressに入れてる人が古株ユーザに多いっすね。
Strictとは関係ないかもだけど、ああいうのもｶｺｲｲと思った。

>>325
ななな　なぜそこで私が；

327 ：Name_Not_Found：02/03/06 21:50 ID:x88qXGMJ

オイラは、2chの存在を知ってこの板で質問して
Strictを薦められたのが主なきっかけです。
茶文字さん、有難う。

それと・・・・・、どうでしょう？

328 ：j君：02/03/06 21:54 ID:S1CjUQk6

ふと迷い込んだ鳩丸にカキコみしてたら
謎軍団にスコスコに洗礼を受けて、知らぬ間におぼえました。

329 ：ちょこら ◆DmcC0DXc ：02/03/06 21:58 ID:0bVQU9jW

>>328
……そ、壮絶だ。。恐ろしい。

330 ：サ骨 ◆/IQ5000w ：02/03/06 22:05 ID:qldEYnQK

>>323
俺はｶｺｲｲﾎｰﾑﾍﾟｰｼﾞを作りたい厨房と一緒の理論。
XHTML1.1+CSS(・∀・)ｶｺｲｲ!

>>324
展示して比較
…こんな感じか？　笑。
http://tiyu.to/
http://sakots.pekori.jp/ushi/

valid なだけかも

331 ：Name_Not_Found：02/03/06 22:28 ID:Os/g3k3Y

>>330
ushiのソース、美しすぎて、ちゆのがみらんない‥‥
class="w3c" にわらた

332 ：305：02/03/06 23:03 ID:4dkx7Dri

私は7年前から HTML を書いているけど、2年ほど前にたまたま訪れたサイトで
スタイルシートの存在を知り、すぐに Strict に移行した。

論文やレポートを TeX で書いていたりしたから、レガシーマークアップより
寧ろ Strict のほうが直感的に理解できた。
（この場合 TeX というより LaTeX というべきか。）
論文のようなものを公開するには Strict + CSS の方が便利だしね。

Strictに惹かれたのはこの利便性もあるし、なんといっても Strict の
ソースに美しさを感じたのが大きいかな。(w

333 ：Name_Not_Found：02/03/06 23:09 ID:Jnpum7RL

perlのことを見に行ったちゃいぱさんのとこでStrictを知った。
そのあと鳩丸に行って更に衝撃を受ける。
これでStrictに興味を持った。

ある日同じクラス（当時高３）の人と何気なく話していたらサイトの話になり意気投合。
その人が実は強烈なW3C信者で宗教勧誘のごとくStrictを勧められ半ば強制的にStrictで書かされた。
気がついたらいつの間にか・・・・

今に至ります。

334 ：ちょこら ◆DmcC0DXc ：02/03/06 23:41 ID:0bVQU9jW

>>333
若いね。

335 ：Name_Not_Found：02/03/07 00:06 ID:6yjnPV0p

初めて知った解説サイトがZSPC（リニュ前）、そして
次がThe Web KANZAKI、Tokimeki→さとみかんから
初めてとほほの存在を知る

漏れって幸運ﾀﾞﾀｰﾉｶ

336 ：こういう流れでいいんでしょうか…：02/03/07 00:15 ID:C+LOrryz

1. テーブルでちょこっとレイアウトした小さなページだった。
2. 新たにまとまったテキストを書くことにした。
3. レイアウトが決まらないまま仮の状態で書き始める。
4. そういえば CSS を使えば見栄えが後で指定できると思いだす。
5. 「とほほ」を参考に、ある程度 HTML 4.01 Transitional に適合した文書ができた。
6. CSS をいじりはじめる。同じ頃２ちゃんねるの関連スレを見始める（去年の8月）。
7. Strict も大差ないことを知り、Lint で確認しつつ Strict にする（今月）。
8. 初めて Strict スレに書き込む（今日）。茶文字さん、有難う。

「正しいHTMLがあればCSSを使える」というのは初心者（俺）にとっても魅力的だった。
ただ、上記の「2」の動機が無ければ、HTMLを意識したかどうかはわからない。
＞「Strictで初心者向けのサイト」には何が必要だと思う？
「ホームページ」を作ることだけではなく、
Web上に自ら編集したドキュメントを公開することをｲｲ!とする意識付け、かも。
そしたら、「インターネット」ってもっと面白くなるんじゃないかなぁ。

337 ：Name_Not_Found：02/03/07 00:30 ID:Ix3fR+HB

私はとほほから入った人。でも、そこにあったStrictやCSSに対する
やや懐疑的な文章を見てそんなに問題があるのかと思っていろいろ
調べてみたらそっちの方が自分に合ってると思った。
<font>とか<b>とか置いたりテーブルによるレイアウトとかして
文書内でタグが増殖するのが嫌になってたんだよね。
今はStrict＋CSSで見やすい＆わかりやすいソースになって満足。

テキストエディタ系のソフトでドキュメントを作ることでHTMLと
向かい合っていたから早くStrictに移行できたのかな？

338 ：茶文字 ◆xELvisFU ：02/03/07 02:40 ID:/pLgEXrD

「うし」拝見しまちた。
今まで自分のサイトをXHTMLで書いたことはなかったけど、
ぼちぼちやってみる気になってきたかも。

いつの日か「サ骨さん、ありがとう」と言えることを夢見て精進します。
======
みなさんいろんな経緯を踏んでこられているようで。
5年ほど前に作った私の最初のサイトはPageMillに任せきりだったっけ。
でも、あまりに起動が遅いので、待ちきれずにテキストエディタで編集しはじめた。
そのへんからとほほに通うようになったのかな。

しかぁし。
Strictにこだわるようになってきたのは、ほんの最近のことだったりする遅蒔き'Stricter'でつ。
良スレに出会ったことに感謝しつつ、今後とも勉強させてくだはい。

339 ：299：02/03/07 10:29 ID:nPcNxAVX

実際Strictで書くようになったのは１年くらい前かな。

Strictに出会うきっかけは、ふらりと立ち寄った闇黒日記(ﾜﾗ

340 ：サ骨 ◆/IQ5000w ：02/03/07 13:49 ID:y5F68Q5i

>>338
XML宣言を１行目に入れるとIE6がCSSを残念に解釈してしまいますので、
文字コードがUTF-8になってしまいます。

文字サイズを200%とかにしたら占いのあたりがかなりひどいことになります＞うし
中身を<dl>でブツ切りにすればなんとかなるような気もするんですが
ソレもどうかなァと思いました。

341 ：Name_Not_Found：02/03/07 14:51 ID:Hk1TJvOX

>>340
＞XML宣言を１行目に入れるとIE6がCSSを残念に解釈してしまいますので、
＞文字コードがUTF-8になってしまいます。

マジ？
ていうかCSSと文字コードと何の関係が？

342 ：Name_Not_Found：02/03/07 15:02 ID:oi3pJy+l

IE6 は先頭に XML 宣言があると互換モードになってしまう。
が、 XML 宣言を省略するなら文字コードは UTF-8 か UTF-16 に限定される。

343 ：Name_Not_Found：02/03/07 15:10 ID:1VCcqZcH

ってことは、Unicode(UTF-8 or UTF-16)で書けば、XML宣言省略してもStrict的には問題無いのかな？それならi-modeでもちゃんと表示されるから歓迎なんだが…

344 ：The鬼 ◆ZK/7506A ：02/03/07 15:19 ID:VyhAQ8Q2

>>343
そうなんですが、Unicodeが解釈できないUAがまだ多いので、
諸刃というか、現実的ではないってどこかで聞いた覚えがあります。
i-modeもUnicodeだめなんじゃないですか？確認してませんが。

345 ：Name_Not_Found：02/03/07 15:26 ID:nPcNxAVX

>>343
i-modeはShift_JIS限定じゃなかったっけ?

346 ：Name_Not_Found：02/03/07 15:30 ID:1VCcqZcH

>>344
今試してみたら見事に文字化けしました。＞i-mode

347 ：j君：02/03/07 15:45 ID:ha5F0DfR

xml宣言はUnicodeでもつけたほうがいいよ。
html4.01でbodyやhtmlは省略できるけどstrict的にしないでしょ？。
xml宣言も省略できるけどしないほうがヨイ。
おとなしくhtml4.01にするかIEは放置の方向か
それは個人の好みで決めるが吉

348 ：サ骨 ◆/IQ5000w ：02/03/07 15:46 ID:y5F68Q5i

困った。

349 ：Name_Not_Found：02/03/07 15:49 ID:hqVgiVI8

> XML 宣言と文字コード
"わかったよぅ、日本語なんか使うなってことだろう？"
としか思えなかった私は
日本人向けのなんちゃって英語で XHTML 書くことがあります(w
# 何でもそうだけど、 ascii 文化の連中だけ楽に移行できるってやっぱズルい。

350 ：Name_Not_Found：02/03/07 16:11 ID:1VCcqZcH

>>348
互換モードのIE6でもちゃんと見えるCSSを作ってJavascriptで切り替えるとかどうかなあ。

351 ：サ骨 ◆/IQ5000w ：02/03/07 16:40 ID:y5F68Q5i

>>350
やってみる。
mozillaとNN6、OperaあたりとIE5/6で分ければいいのかな。

関係ないけどprozomitronでIE6無理やり互換モードフィルタ
Name = "MURIYARI GOKAN MODE IE6"
Active = TRUE
Limit = 128
Match = "<start>"
Replace = ""

352 ：Name_Not_Found：02/03/07 16:51 ID:uRwirPQD

やっぱりxml宣言ははずしたくない
box-sizingでとりあえず我慢

353 ：Name_Not_Found：02/03/07 17:03 ID:1VCcqZcH

けど、IE6は既に正式版リリースされているから標準モード使うならやはりXML宣言省くかHTML 4.01になりますね。
おそらくIE6.5でもXML宣言入れると互換モードになるでしょうから待っても解決はされないかと…

354 ：サ骨 ◆/IQ5000w ：02/03/07 17:09 ID:y5F68Q5i

と思ったらそこまで表示変わらないや＞うし

355 ：Name_Not_Found：02/03/07 17:19 ID:xPyQFA9V

誰かXML宣言が入ってると互換モードになるってバグ報告した人いる?

356 ：Name_Not_Found：02/03/07 17:48 ID:Q/eouk/z

>>355
2001/12のWebDesigningって雑誌で解説されてたな。
多分、バグではないんだろう。

357 ：Name_Not_Found：02/03/07 18:28 ID:nCMTPoYs

> 多分、バグではないんだろう。

仕様か(藁

358 ：Name_Not_Found：02/03/07 19:04 ID:hqVgiVI8

http://www.webreference.com/dhtml/column60/5.html
XHTML に XML 宣言など不要、 UTF8 使えやｺﾞﾙｧと
思ってるようにしか見えない。

359 ：Name_Not_Found：02/03/07 19:38 ID:Ix3fR+HB

ttp://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp
The !DOCTYPE "Switch" の節

IE6はXHTML／XMLは常に標準モードになると書いているように見えるのだが…？
XML宣言のために!DOCTYPEが先頭にならないから 'No !DOCTYPE present' 扱い
（常に互換モード）されているのかも。やっぱバグじゃないの？
ASCIIはUTF-8のサブセットだから西欧圏はXML宣言をつける感覚が薄れてるのか？

360 ：Name_Not_Found：02/03/07 19:52 ID:M0Dpe6xG

>>358

DOCTYPEの説明をしているページがDOCTYPE使ってないのは
これいかがなものか？

361 ：Name_Not_Found：02/03/07 20:04 ID:y5F68Q5i

ていうか
先頭でXML宣言した拡張子.shtmlのファイルが
ローカルではIE6で開けないのは、いかがなものか。

362 ：Name_Not_Found：02/03/07 20:06 ID:hqVgiVI8

>>359
少なくとも IE6 の開発者連中が
XHTML を文書型が変わるだけだと誤解していたことは確実。

363 ：：02/03/07 21:22 ID:M0Dpe6xG

てかXML宣言なんだからSHIFT_JISだろうがUTF-だろうが
宣言せなあかんのでは？

364 ：Name_Not_Found：02/03/07 22:00 ID:kvqJePOr

>>327

365 ：Name_Not_Found：02/03/07 22:01 ID:+OkCdUam

>>363
普通はね。でもXMLパーサはUnicodeのみ理解できるようになっているから省略も許されている。
Shift_JISはそのままではXMLパーサが理解できないからエンコーディングの指定が必須になる。
そんなとこ。

366 ：　：02/03/08 00:12 ID:Hapkt1Pd

<?xml version="1.0" encoding="x-sjis"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">

367 ：89：02/03/08 01:24 ID:5ldNvJ12

裸だけど基本は出来ました。
http://www.age.jp/~giko/cgi-bin/strict/bbs.cgi

368 ：Name_Not_Found：02/03/08 01:33 ID:f4mJu82f

>>367
"

369 ：Name_Not_Found：02/03/08 01:33 ID:f4mJu82f

>>368
うお。
"

370 ：Name_Not_Found：02/03/08 02:03 ID:s+fGHX3c

妙な br が目に付いた。

371 ：Name_Not_Found：02/03/08 02:49 ID:8/P/oBr4

lintしてみたら７８点だった
あとちょっとだ
がんばれ

372 ：サ骨 ◆/IQ5000w ：02/03/08 08:22 ID:WwSNw4E3

(´-`)。ｏＯ（お絵描き掲示板は…　スキンレベルでなんとかできるものではなかった…）

373 ：Name_Not_Found：02/03/08 10:25 ID:DkmZtPnZ

この質問は、こちらでいいのかな……。
表全体の幅は任意として、表のセル幅を各100pxにしたいとします。
table,td {border:1px solid red;}
<table>
<tr>
<td width="100">100px</td><td width="100">100px</td>……以下10回繰り返す
</tr>
</table>
これだと、ウィンドウ幅が100px×10より狭かった場合には
table幅を100%とするのを優先して、各セル幅は100pxより狭く圧縮されます。
そこで<td width="100" nowrap>100px</td>とすると、WinIE6では狙った通りに
各セル幅は100%になり、且つ窓幅が狭いときは横スクロールが発生してくれます。
しかしOpera6やNetscape6.21ではやはり窓幅が狭いときにtdの幅も狭くなります。
ここで、よりStrictにすべく、各td要素からwidth属性・nowrap属性を取っ払って
スタイルシートで td {width:100px; white-space:nowrap;}と指定してみましたが、
こんどはWinIEでもtable全体の幅を100%にするのを優先してしまってダメ。
その代りにOperaでは意図した通りになってくれました。
しかし<td nowrap>100px</td>に対して適用させるとちゃんとIEでもセル幅100pxを
維持してくれます。nowrapをHTMLで指定してあればなぜか大丈夫なのです。
一応これでOperaとIEはなんとかなったわけですが、Netscape6/Mozillaのみ表示が一致しません。
HTML4.01仕様書邦訳を読んでみたものの、セル幅をどう表示するのが正しいのか、わかりません。
Strictスレッドの方ならご存じではないかと思って、
テーブルの幅計算の原理とそれへの対処法をお訊ねする次第です。

374 ：Name_Not_Found：02/03/08 10:40 ID:7lb4O4HN

>>373
スレ違いもいいとこだが table-layout: fixed でどうよ。
次からはここで聞け
http://pc.2ch.net/test/read.cgi/hp/1015474859/l50

375 ：Name_Not_Found：02/03/08 10:51 ID:UBMBGYkB

>>373
どの要素についてもそうだけど、 HTML4 では
「正しいレンダリング方法」というのを特に定めない。
表のレンダリングについて仕様で触れているのは CSS2。

376 ：373：02/03/08 10:52 ID:DkmZtPnZ

>>374
table-layout: fixed;は意味がありません。
表全体のwidthが指定されてないと固定レイアウトでなく自動レイアウトになる筈ですから。

HTMLのことでもあるのでこちらでお訊ねしたのですが、「スレ違い」でしたか。
ではご推奨の「CSS、スタイルシート質問スレッド」にて訊くことにします。

377 ：255：02/03/08 16:26 ID:0RBikuoe

>>316
0.4秒ほど速くなった気がしないでもありません。ｵﾂｶﾚｰｯｽ

378 ：Name_Not_Found：02/03/08 19:22 ID:O3/7bs3D

strictなアダルトサイトってどうなの？

379 ：Name_Not_Found：02/03/08 20:13 ID:BIbrNuaS

>378
ソースきぼーん

380 ：Name_Not_Found：02/03/08 20:15 ID:8E0CdIpY

>>378
見てみたいな
けど、Strictだとしょぼいアダルトサイトになるのは明白

381 ：Name_Not_Found：02/03/09 00:00 ID:k31eLKG1

>>380
しょぼいかどうかはともかく、ノーマルなものではなさげだ。

…つーか、そんな印象を持ってしまうのも某方面の罪か？

382 ：j君：02/03/09 00:09 ID:hWStkFcq

エロ動画とかはアプレットだろう？
objectなんてだめだろうし
あとエロ画像のalt=""にはいる値は
見ると笑えそうだ

<img src="rori.jpeg" alt="ロリロリフェイスが乱れまくってる画像">
とか？（ワラ

383 ：Name_Not_Found：02/03/09 01:11 ID:i1/tE4TK

>>382
w3mでも十分抜けるように。

384 ：Name_Not_Found：02/03/09 01:38 ID:C85yix6F

<img src="image/sex1.gif" alt="腰使いが激しいセックス動画" width="400" height="450">

動画gifバージョン

385 ：Name_Not_Found：02/03/09 01:52 ID:C85yix6F

えっと・・

会社の先輩（SE）
にホペのフォントにHG性楷書体-proを指定していたら
UNIXとか考えたらserifだけがいいとか言われたんだけど
そうなん？そういや鳩丸もむかしいぱーいフォントを指定してたのに
いまぜんぜんないし・・・やっぱだめなのかなあ・・・

386 ：Name_Not_Found：02/03/09 02:26 ID:zjxY6orb

>>385
「serifだけ」にするのはIEのバグなどもあるしあんまり宜しくないのでは。
CSSの仕様では「無いフォントは無視する」ことになってるから、
font-face: "HG性楷書体-pro" serif;
としておけばオールオッケーなはず。

387 ：Name_Not_Found：02/03/09 02:42 ID:k31eLKG1

>>384
むしろ PNG か SVG だな。

388 ： ◆HTML/.Kg ：02/03/09 05:12 ID:XBxAAe3t

>>378
萌え系エロアニ画像とかならだれかやりそう(とかいう

389 ：Name_Not_Found：02/03/09 07:16 ID:PV/ngaxp

validな掲示板ってどうよ？
プチボベースなんだけど。

390 ：Name_Not_Found：02/03/09 19:00 ID:IQSnGUUg

つーか、画像を大量に使う時点でStrictにする意義はないと思う。
UAがかなり限られるからね。

391 ：j君：02/03/09 19:20 ID:BS2JjHcx

文字だらけの2chこそとりあえずStrict化を推し進めねば

392 ：Name_Not_Found：02/03/09 20:44 ID:OZoeh1Uj

>>390
ハァ('Д')?

393 ：j君：02/03/09 20:57 ID:BS2JjHcx

どんなサイトでもStrict化することに
意義はあると僕も思うな

394 ：茶文字 ◆xELvisFU ：02/03/09 21:07 ID:6Ua86tW2

私にとって、Strictは目的じゃない。
目的が先にあってStrictにするだけ。
目的とは、情報の二次利用性をとかアクセシビリティーを高めるとか。
んで、どんなサイトもStrict化することによって何らかの恩恵はあるはずだと思う。
その意味で、393に禿同。

objectの実装がまだまだだとか無料鯖で広告が出るからとかの理由で
しかたなしにTransitionalを宣言することはあるだろうが、
極力Strictに近づけるような努力はあっていい。

395 ：Name_Not_Found：02/03/09 21:54 ID:HOfGdre5

>>395
無料鯖で広告がでるからDOCTYPE宣言をコメントアウトにしているサイトに
lintかけてよろこんでいるNozをみたことある。

396 ：Name_Not_Found：02/03/09 22:22 ID:OZoeh1Uj

そしてのぢたんは広告が挿入されて
invalidになってるにも関わらず
そういうページにDOCTYPE宣言をつけてよろこんでいる

397 ：Name_Not_Found：02/03/09 23:15 ID:I2+q6Nnx

>394
アダルトサイトなんて毎日目まぐるしく更新されて
そしてその殆どが交換バナー。

それでもそうすべきか？
# 実際誰もせんだろうが

398 ：Name_Not_Found：02/03/09 23:36 ID:BJGUwgIZ

>>392
テキスト系のUAは無視だろうがゴルア
となると、Strictにする意義はほとんどなくなるんじゃねーか？
てめーはどう答えるよ？
頭悪い?

399 ：Name_Not_Found：02/03/09 23:40 ID:yiH8ciyi

>>395
＞無料鯖で広告がでるからDOCTYPE宣言をコメントアウト

なんか意味あるの？

400 ：Name_Not_Found：02/03/09 23:42 ID:I2+q6Nnx

>399
ちくるとあぼーんされる

401 ：Name_Not_Found：02/03/09 23:43 ID:ONtdSSlt

>>398
つまり、Strictにする意義はテキスト系UA対応にしか無いと言う訳ね。

402 ：Name_Not_Found：02/03/09 23:58 ID:f6utVWWk

>>388
画像主体なら文字 UA 切り捨てはある意味必然。strict 云々は無関係。
文字の代替である画像と、画像としての画像では意味が違う。
strict なら前者は補える、というのは strict の数多ある利点の「一つ」。

>>399
DOCTYPE 書いても不正　書かなくても不正

>>400
コメントアウトは広告でなく DOCTYPE の方

403 ：obsolete：02/03/10 04:51 ID:29t3TEGv

obsolete

404 ：Name_Not_Found：02/03/10 04:52 ID:29t3TEGv

↑Strictなあぼーん

405 ：Name_Not_Found：02/03/10 07:15 ID:atW8R86l

<p>
<object
classid="clsid:5DB05CB8-7751-469D-A1DD-45C8C201C013"
id=Blender3DPlugin
width = 640
height = 480
codebase="http://plugin.blender.nl/
Blender3DPlugin.cab#Version=2,24,4,0">
<param name="blenderURL" value="http://www.yoursite.com/yourproduction.blend">
<param name="loadingURL"
value="http://www.yoursite.com/yourloadinganimation.blend">
<param name="ForeColor" value=65280>
<param name="BackColor" value=255>
<param name="useFileBackColor" value=1>
<param name="frameRate" value=20>
<EMBED
type="application/x-blender-plugin"
PLUGINSPAGE="http://plugin.blender.nl"
name="NPBlender"
WIDTH=640
HEIGHT=480
SRC="http://www.yoursite.com/yourproduction.blend"
loadingURL="http://www.yoursite.com/yourloadinganimation.blend"
ForeColor=65280
BackColor=255
useFileBackColor=1
frameRate=20>
</EMBED>
</object>
</p>

これってStrict的に改善するところがあるでしょうか？

406 ：Name_Not_Found：02/03/10 07:16 ID:atW8R86l

機能としては……

width: 横幅
height: 高さ。この二つは%での表記もできます。(Windowに対する比率)
blenderURL(game.blendと記述している部分): 呼び出すblendファイルのURL

loadingURL: ロード時に使用するblendファイルのURL。空白にするとload.blendが呼び出されるようです。
ForeColor: loadingURLで呼び出されるblendファイルがDownloadされた時に使用されます。
BackColor: blendファイルで設定された比率と、上記のwidth,heightで設定された比率が合わない場合に、空いた部分がこの色で塗りつぶされます。
上記二つは、赤青緑をそれぞれ0-255で表わし、(青×65536)＋(緑×256)＋赤で設定します。
useFileBackColor: 上記のBackColorを使うか、BlenderのRendering Button Window上で設定された色を使うかの指定。
もし、BackColorおよびuseFileBackColorの両方が指定されていない場合、HTMLのbgcolorが割り当てられます。

framerate: 毎秒の更新回数。そのblendファイルで必要な値を設定します。最大100。
もしそんなに必要でない場合、ここを小さくすることでOSの負荷が軽くなります。

407 ：Name_Not_Found：02/03/10 08:02 ID:+H3j72HN

>405-406
まずはlintでチェックしましょう。例えば
ttp://openlab.ring.gr.jp/k16/htmllint/index.html
の「ゲートウェイサーヴィス」

ちなみに、<EMBED>はStrictでは（というか、Transitionalでも）致命傷です。

408 ：Name_Not_Found：02/03/10 16:32 ID:THuyB4Vu

>>399
意味はないと思う。強いて挙げるならば広告が付かなくなったとこに
移転するときのための自分へのメモなんじゃないかと思われ。

409 ：Name_Not_Found：02/03/11 03:33 ID:0Qgv8X1g

のじって全然わかってないじゃん。

410 ：Name_Not_Found：02/03/11 03:36 ID:5u/ff7tt

>>409よりはわかってるだろうがな

411 ：Name_Not_Found：02/03/11 03:45 ID:Kj1BPCQw

>407
objectすかね

412 ：Name_Not_Found：02/03/11 10:47 ID:taig9ZgK

>>406
属性は""で囲め。

413 ：Name_Not_Found：02/03/11 15:43 ID:mtiU0KbS

Strictの考え方がわかりません。
Strictの考え方を勉強するにはどこへ行けばいいでしょう？

414 ：Name_Not_Found：02/03/11 15:50 ID:MoTvEHmX

自分はコミューンの日記を片っ端からブックマークして
毎日 ROM ってる。

415 ：Name_Not_Found：02/03/11 17:27 ID:ulAjGOUK

>>413
w3c でも逝っとけ、と言いたいところだが、
まぁいきなり英語を読むのもナンなので、
これでも全読すれば。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/cover.html

416 ：Name_Not_Found：02/03/11 18:09 ID:+VVg5OcJ

>>414
コミューンの日記読んでもStrictにはならん様な。

417 ：Name_Not_Found：02/03/12 04:30 ID:Ss9QI/pN

コミューンの日記読むとはにゃーんとなれる。

418 ：Name_Not_Found：02/03/12 07:15 ID:avCu5U7M

>>417
それは禿同

419 ：Name_Not_Found：02/03/12 10:12 ID:avCu5U7M

>>415
仕様書読みを奨めるのはいいことだが、

>Strictの考え方を勉強するにはどこへ
という趣旨で、

http://kanzaki.com/docs/html/htminfo10.html

420 ：Name_Not_Found：02/03/12 11:29 ID:joJao89a

Strictじゃないんだけど一応validではある掲示板
ショボくてごめん
http://yuuki.s8.xrea.com/cgi-bin/

421 ：Name_Not_Found：02/03/12 13:15 ID:096Ws2JN

参考リンク
ttp://www.hogehogehoge.com/

みたいなのはどんな感じでやれば良い？

422 ：Name_Not_Found：02/03/12 13:23 ID:0W6hWUhc

>>421 DL要素

423 ：Name_Not_Found：02/03/12 13:23 ID:bIym/g6n

>>421 意味わからん…。

424 ：421：02/03/12 13:27 ID:096Ws2JN

>>422

<dl>
<dt>参考リンク
<dd>ttp://www.hogehogehoge.com/</dd>
.
.
.
</dl>

ってことですか。サンクス

>>423
すみません。略しすぎました....
要するにリンクの説明をURLの上方に書いてその下にURLを....ってこ
とです

425 ：421：02/03/12 13:28 ID:096Ws2JN

あ、dtだけ省略してしまった

426 ：Name_Not_Found：02/03/13 02:16 ID:ZhDbMRwi

友人とアダルトサイト作成してますけど、私はStrict指向なので一応Strictで記述してます。まぁ、優良サイト目指しているので広告が少ないからこそ出来るんでしょうね。
でもやっぱりデザインに苦しむ、、、。(苦笑)CSSの勉強が足りないなぁ。

427 ：img alt="襞々"　とか？：02/03/13 02:37 ID:T30kXUZW

>>426
いいっすねぇ。その心意気。

> 広告が少ない
広告バナーより Valid アイコンの方が多い
アダルトサイトをきぼーん。

(・∀・)ｶﾞﾑﾊﾞﾚ!

428 ：Name_Not_Found：02/03/13 08:41 ID:nuTDmIp0

>>426
激しく応援。スポンサーもいっぱいつきますように。

・・・ま、validのバナーは貼らなくてもいいけどな。

429 ：Name_Not_Found：02/03/13 14:27 ID:SozodFdW

Validバナーは私も昔得意げな顔して張っていたけど
いまはずしたよ

430 ：Name_Not_Found：02/03/13 17:24 ID:p1syLuJt

validバナーは、過去の切片の正しさを保証してるだけで、
未来的によいとか、思想的によいとか関係ないしね。

431 ：うし ◆/IQ5000w ：02/03/13 19:15 ID:l8YJR+Vs

うちはソレもネタの一部だしなぁ（笑

432 ：428：02/03/13 22:38 ID:YIepqF24

>>431
いやいや、うしはOKっす（藁

・・・でもアダルトサイトにそれを見つけると萎えると思ったんだYO...

433 ：Name_Not_Found：02/03/14 03:17 ID:jYaoKa9C

Validバナ―はHTMLを教えているようなサイトならあってもいいとは思うが、通常のページだとStrictで書いたのを自慢してる気がして気持ち悪く感じる。＜俺の場合ね
謙虚でStrict即ちこれ最高

434 ：Name_Not_Found：02/03/14 03:18 ID:jYaoKa9C

なんで2が上がってるんだ？ってことであげ

435 ：The鬼 ◆ZK/7506A ：02/03/14 09:51 ID:q+aye3Em

理想論者風に言えば、Validなhtml書くのは当然といえば当然であって、
Validバナー付けるのは、アメリカ人が額に「英検一級」と書いて歩いてるようなものではないのか。
（ネイティブでも英検一級って難しいらしいけど、そこはここでは無視）
電卓に「割り算できます」と書いてるようなものではないのか。
と考えたんだけど、JISマークみたいに、利用する人が安心できるって言う面もあるかなとも考えてみたり。
啓蒙にもなると思うし。

でも個人的には何か照れくさいし「Validでっせ」は出来ないです。
もし設置するなら「about」とか「help」なページだけにすると思う。

436 ：Name_Not_Found：02/03/14 10:16 ID:lIfU5fUH

>>435
俺は啓蒙厨なのでTOPのみValidバナー貼りつけ。
アクセス数は6hot級(アクセス解析してないから詳細は不明)だけど(ﾜﾗ

437 ：Name_Not_Found：02/03/14 11:03 ID:1Uqb1/5U

ちょー遅レスだが前スレの854 "HTTP://WWW.2CH.NET/"は
別にまずくないだろ。DNSのRFCでドメイン名の大文字小文字を
区別しないことは規定されてる。これを区別するサーバはありえない。
まあ言いたいことは分かるけど例がまずいよ

438 ：Name_Not_Found：02/03/14 11:50 ID:wekRdTM8

>>437
スキーム部は小文字じゃないとまずいでしょ。
……まぁ、RFC2396（だったか？）に「大文字を小文字とみなすよう、融通を利かしてもよい」とは
書いてあるけどさ。

439 ：Name_Not_Found：02/03/14 16:55 ID:1supAoJG

validバナーって何ですか・・・？
最近Strictなどを調べ始めたんですが初めて聞きました。
厨な質問スマソ・・・でも教えてﾎｽｨ…

440 ：Name_Not_Found：02/03/14 17:00 ID:lIfU5fUH

>>439
http://validator.w3.org/images/vxhtml10
こういうの

441 ：439：02/03/14 17:37 ID:KiBQlALn

>>440
即レスサンクス。
これのことか～
433と同じく解説サイトでもないのに貼ってあるサイトは自慢くさくて萎える。

442 ：Name_Not_Found：02/03/14 18:49 ID:0YDzM0ub

・・・外そう（ｳﾂ

443 ：428：02/03/14 22:46 ID:cIUF4Vfo

>>442
いいんじゃﾈｰﾉ?少しは啓蒙になるだろ(w

444 ：Name_Not_Found：02/03/14 22:47 ID:E08D8NU4

「ほーむぺーじ論」より。
http://www5b.biglobe.ne.jp/~nitti/hp/concept/concept11.html
W3Cの宣伝広告を貼ると優越感と自己満足に浸ってしまい、
制約も増し、肝心の内容も薄くなるのでやめた方がいいそうです。

445 ：428：02/03/14 22:52 ID:cIUF4Vfo

>>444
煽るつもりはないけど、
> やめた方がいいそうです
という書き方に主体性のなさを見た。

その通り、自分のサイトで何がしたいかわからないﾔｼは
validバナーどころかサイトを作る必要なし。

446 ：Name_Not_Found：02/03/14 23:27 ID:ZB6tkPg7

>>444
「だいたいそういうサイトに限って、
コンテンツが薄かったりするのは気のせいでしょうか。」

なるほど．．．。
てゆうか、nozたんに斬って欲しい。

447 ：Name_Not_Found：02/03/14 23:36 ID:R3TSWHi3

>>446
すでに斬られ済みだったとｵﾓｰﾀよ。そのサイト。

448 ：444：02/03/14 23:43 ID:E08D8NU4

>>445
＞> やめた方がいいそうです
＞>という書き方に主体性のなさを見た。
うん。恥ずかしながら俺本人はとくに賛否の意見を持たないので。
一般的にはマイナスイメージで受け取られる可能性もあるのでは？という。

>>446
すでに対話済みのよう。そこの著者は現在加筆訂正中とのこと。
http://cgi.www5b.biglobe.ne.jp/%7Enitti/cgi/board/board.cgi

449 ：Name_Not_Found：02/03/14 23:46 ID:tUVVfk4p

バナーを貼っても意味が無いから止めろというなら「Copyright (C)（略」
等の表記も意味が無いのではないのか

450 ：Name_Not_Found：02/03/14 23:50 ID:Da4EVFXZ

>>444
「ほーむぺーじ論」、言いたいことは分かるんだけど、
ちょっとなんかどっかずれてるように思うのは僕だけかな。

Validバナーをつけることだけで満足するという問題は、
見た目のデザインに満足していることに同じであって、
特に取り立ててValidのみに限定する必要はないような。
Validバナーを批判するための後付けの論旨が見える。

ところで、なんでこんなにフォントサイズが半端なんだ……
文字にジャギーが出て、読みにくいったらありゃしないよ。

body { font-size: 93%}
.titleBG { background-image: url(../img/title_bg.gif); background-repeat: repeat-x; background-color: #CCCCFF}
.gyou { line-height: 130%}
.constantSize { font-size: 13px}
h1 { font-size: medium; font-weight: bold; width: 468px; color: #333333; border-style: solid; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 1px; border-left-width: 0px}
.moji-gyou { font-size: 93%; line-height: 140% }

451 ：Name_Not_Found：02/03/15 00:00 ID:5/KSY9Kd

>>449
意味が無いと云うか、いらないと思われ。
まぁ、別に書いても害は無いと思うけど。
http://white.sakura.ne.jp/~quia/tech/html/meta.html#copy

452 ：Name_Not_Found：02/03/15 00:02 ID:/FWOECid

>>451
Validバナーも同じようなものではないのか

453 ：Name_Not_Found：02/03/15 00:07 ID:VZZlfk4t

Validバナーを外して6hotバナーを付けよう

454 ：Name_Not_Found：02/03/15 02:18 ID:BphhZXQf

>>449
表記しないと認められない国への対策にはなるんちゃいまっか。

455 ：茶文字 ◆xELvisFU ：02/03/15 03:49 ID:GRAD2Z1X

>>Copyright ©
万国著作権条約に加盟していながらベルヌ条約には加盟してない国に対しては有効。
つっても4カ国しかないらしいけどね。
どっちにも加盟してない国が相手なら何を書いても無意味ではある。
そのへんわかった上で書いてる人は、「自分はこのコンテンツについて著作権を
主張するぞ」な意思表示という意味合いが強いみたい。
# ちなみに©は(c)で代用できるものではない。
# んで、制作者名と制作/加工年がセットになってはじめて有効。

validバナーは「それがあれば安心して閲覧できる」っつー保証になるかというと、
実際はブラウザの実装がタコでCSSが原因で落ちたりするケースもあるから
これまた頼りないことこの上ない。
ま、validバナーがあるHTML/XHTML、CSS、JavaScriptなんかの説明サイトは
その内容を信頼していいかなって気にはなるかもね。

456 ：Name_Not_Found：02/03/15 03:58 ID:1+D0LGv9

Validバﾅｰ云々、内容薄いとか意味ないとかのやりとり・・・。
どっかで見た流れだと思った
らFlash。

457 ：茶文字 ◆xELvisFU ：02/03/15 04:08 ID:GRAD2Z1X

そういや思い出したんだけど。
validバナーってHTMLとCSS並べたときに片方は透過されてて片方はされてなかったような。
自鯖使った一時的なコンテンツで貼ってみたことがあるけど、
デザイン的にももひとつなんで好んで使う気にはなれん。

458 ：Name_Not_Found：02/03/15 08:40 ID:IRx0t6ec

©と(c)はどう違うのだろう。

459 ：サ骨 ◆/IQ5000w ：02/03/15 08:49 ID:h7aY1w72

>>458
ソース見れ。

460 ：Name_Not_Found：02/03/15 16:30 ID:yscG0OO0

>>459
どう使い分けるのだろうっていう意味じゃないのかなあ。
©だと見られないブラウザがあるんだとかで、(c)にする人が。

461 ：茶文字 ◆xELvisFU ：02/03/15 16:41 ID:GRAD2Z1X

>>458,460
万国著作権条約で保護されているのが©だけなので、(c)は法的効力がないです。
国内法的にはあってもなくても作品が成立した時点で著作権が発生するんでいいんですが。

この論に立てば、ブラウザが©を表示できないからといって
(c)で代用するのはなんかずれてますな。

んで、仮に©をつけていたとして。
パクった側の環境がこれを表示できず知らず知らず権利を侵害していたとしたら、
司法的には「不知」つまり意図的な不法行為とは言えないわけで無罪放免になるかもですが、
それ以降はそういう言い訳が通用しなくなるわけですから(一旦司法判断が出た以上、
それ以降も被告が「不知」でありつづけるわけにはいかなくなる)
どのみちコンテンツの変更を余儀なくされるでしょう。

いずれにしてもStrictと直接関係のある話ぢゃないですな。

462 ：Name_Not_Found：02/03/15 18:04 ID:O2GnmJwq

>>460
alt="Copyright "でイメージという手はどうだろう。

463 ：Name_Not_Found：02/03/16 03:35 ID:U+pJEt/k

>>462
それいいと思う
よく見かけるし
Strict的にどうだろか？

464 ：Name_Not_Found：02/03/16 05:06 ID:/sLLUGvm

>>463
「Strict的に」というのは、「特定のUAへの対応をしない」というのと同義。
依って、©以外には無いのではないかと。

465 ：Name_Not_Found：02/03/16 05:13 ID:O5NGR2P1

©に対応しないUAってどんなのがあるの？
Strictサイトを管理してるので知っておきたい。
まぁ、対応しないからといって(C)に変更する気は無いけど。

466 ：Name_Not_Found：02/03/16 05:14 ID:GfMohLGU

ﾉｻﾞｷﾀｿが(C)を使っているとはこれいかに

467 ：Name_Not_Found：02/03/16 05:19 ID:O5NGR2P1

あと、とほほも使用してますよね。
国内なら(C)でも問題無いんでしょうね。
つか、うちゲームサイト……©すらいらないかも）ｗ

468 ：Name_Not_Found：02/03/16 05:26 ID:GfMohLGU

>>467
既出だが一部の国以外ならなら無くていいだろ

469 ：458：02/03/16 06:01 ID:oHQck+TP

>>459
すんません、言葉足らずでした。

>©は(c)で代用できるものではない。(>>455)
に引っ掛かって、どういう意味だろうと思ったんです。

>>461
解説ありがとうございます。全然知りませんでした。
自分は何となく©を使っていました。

470 ：Name_Not_Found：02/03/16 07:00 ID:0CS16gku

「ただしコンピュータ上に限っては(c)でも可」という話を聞いたことがあるんだけど。
デマだったのかな？

471 ：Name_Not_Found：02/03/16 09:10 ID:E0ffnsj1

>>465
対応状況ではないけれど、 © は HTML3.2 以降で使用可能。
http://www.w3.org/TR/REC-html32#latin1

> ©は(c)で代用できるものではない。
保護されているのが©だけ、というのが事実でも、
それ ASCII にないじゃん、という話はあるだろうね。
ブラウザで表示できないとかいうよりも、プレーンテキストを保護できない。
実際、 © をクリップボードに入れた時の内容や
ブラウザへの出力自体が (C), (c), c になる UA もあったりするわけで。

472 ：Name_Not_Found：02/03/16 09:50 ID:E0ffnsj1

ついでに。
© は HTML2.0 の文字実体参照には定義されていないけれども
文書文字集合には含まれているので
© とすれば HTML2.0 でも使用可能なはず。

473 ：サ骨 ◆/IQ5000w ：02/03/16 09:52 ID:MSfgiDxL

どう表示されるか、ではなく、
「ソースに"©"と書いてある」
ことに意味があるのではないかと思った。

474 ：サ骨 ◆/IQ5000w ：02/03/16 09:54 ID:MSfgiDxL

"©"も(w

475 ：Name_Not_Found：02/03/16 10:32 ID:E0ffnsj1

海外サイトの文字コード未指定になってる HTML で
デフォルトが Shift_JIS のブラウザで見たときに(あるいは自動判別でSJISとみなされて)
"Copyright ｩ" となってるのをｶﾅｰﾘよく見かけるんだが、
そういうのは効力あるんだろうか？

476 ：428：02/03/16 11:03 ID:UQ7ws31/

>>475
つまり表示上の問題なのであって（特定UA云々の話題といっしょ）、
>>471-474でいいんじゃないのか？

関係ないけど、少し前のバナーの話題で。神崎氏のリソースの
ステータスのとこにあるXHTML&CSSの表示、つい今さっきまで
画像ﾊﾞﾅｰだと思っていたよ。鬱・・・。漏れもこれ真似しようかな。

477 ：Name_Not_Found：02/03/16 11:58 ID:E0ffnsj1

>>476
© とか © の場合は表示上の問題だよ。
SGML 宣言で指定された文字集合から参照する文字だから。
でもｩの場合は表示上の問題じゃないよ。
文字コードが明示されているのでない限り、違う文字であることが充分に考えられる。
その時にｩが © として効力をもつかどうかってのを
文脈とか常識的な判断といった曖昧なものを基準にしちゃうんだろうかと
素朴に疑問を感じたんだよ。

478 ：Name_Not_Found：02/03/16 12:43 ID:UQ7ws31/

# ずっと名前欄に数字入りっぱなしﾀﾞﾀｰﾉｶ
>>477
検索したら日本のサイトにも＜ゥ

Content Negotiationでもって避けられるとは思うが、
実際に"ゥ"になっている場合の法的効力はわからん。
何かソースを探そうと思ったが・・・実際それが問題に
なったことはないだろうから、見つからないだろうなぁ、ｳﾄｩ。

479 ：Name_Not_Found：02/03/16 16:59 ID:mKRTNgdb

次のような法律や条約において、

第6条ジェノサイド
    本規程の目的に関して、ジェノサイドとは、･･･
        1. 集団の構成員を殺害すること
        2. 集団の構成員に対して、重大な身体的または精神的な害悪を加えること
･･･

各項の先頭にある数字はレイアウトではなくて文章の一部だと私は思うのですが、

<ol style="list-style-type: decimal;">
    <li>集団の構成員を殺害すること</li>
    <li>集団の構成員に対して、･･･</li>
･･･
と、するのが正しいのか、

<ol style="list-style-type: none;">
    <li>1. 集団の構成員を殺害すること</li>
    <li>2. 集団の構成員に対して、･･･</li>
･･･
と、したほうが良いのか、それとも

<dl>
    <dt>1</dt>
    <dd>集団の構成員を殺害すること</dd>
    <dt>2</dt>
    <dd>集団の構成員に対して、･･･</dd>
･･･
と、するべきなのか、
私は迷っています。

480 ：Name_Not_Found：02/03/16 17:10 ID:E0ffnsj1

>>479
漏れだったら dl 使うけど。
文章の一部だと思うなら、少なくとも
list-style-type: decimal; は無しじゃないかなあ。

481 ：Name_Not_Found：02/03/16 18:19 ID:/sLLUGvm

>>479
常にスタイルシートが無くても意味が伝わる様に考えないといけない訳で、
そうなるとol要素は有り得ないと思う。

ul要素がダメだというのならば、
>>480の通りにdl要素でマークアップすべきではないかと。
まあ、理想はul要素でマークアップ出来る様に、
文章を再構成する事じゃないかという気もするが。

482 ：Name_Not_Found：02/03/16 21:40 ID:lv1aou3C

>>479
スタイルシートオフ環境のことを考慮するなら、
私なら Transitional 宣言して <ol type="1"> とします。
DL というのはなんか違う気がする。
だって条文内の各項は"1"や"2"の定義内容ではないでしょう？

なお、例に挙げられている国際刑事裁判所規程のような国際法文書の場合、
表記のルールが明確に体系化されているので、
これをスタイルシートで表さないというのはもったいない気がします。

こんな感じか。

ol{list-style-type:decimal;}
ol ol{list-style-type:lower-alpha;}
ol ol ol{list-style-type:lower-roman;}

483 ：Name_Not_Found：02/03/16 22:21 ID:gBSpfbBJ

リストのマークアップの表示結果が
結局スタイルシートに依存してしまうから問題なんだよな。
俺も>>482と同じでdlはおかしいと思う。

どうしてもスタイルシートに依存しないで
第一項、第二項と表現したいならひょっとすると
tableも視野に入れて良いんじゃない？

484 ：479：02/03/16 23:54 ID:mKRTNgdb

>>480-483
皆さん、私をさらに混乱させてくれますね。
みんな意見バラバラで、頭痛い～
私も考えているんですが、まだ結論出ません。

485 ：479：02/03/16 23:55 ID:mKRTNgdb

みんなの意見、ありがとう

486 ：Name_Not_Found：02/03/17 00:54 ID:eEo6td7R

文書中に1.,2.が表れない点でolを蹴る。
1や2がdefinition termでない点でdlを蹴る。
ulを推したいが如何>>486

487 ：Name_Not_Found：02/03/17 10:16 ID:l+r3C/aH

最近のW3Cの勧告ってToCでulの中身に番号振ってるんだよね。
これって音声ブラウザの代わりのスクリーンリーダがolに対して
いまいちな読み上げしかしないからだけど。

488 ：Name_Not_Found：02/03/17 10:30 ID:D8hsqzCL

>>487
ol は入れ子になるとややこしいから、
ul にして生のテキストに番号を書け、
ってのが WAI にあったような。

489 ：487：02/03/17 11:45 ID:l+r3C/aH

>>488
うん、それ。
その「ややこしい」理由が>>487に書いたスクリーンリーダの話。

490 ：479：02/03/17 14:59 ID:48JE93fr

>>486-489
なるほど、ulですね。
もう一度、考え直してみます。
ありがとうございます。

491 ：Name_Not_Found：02/03/17 17:54 ID:FXiYAJjw

<p></p>は段落ですよね。
<blockquote></blockquote>は引用ですね。
blockquoteをpタグ（要素？）で囲むと間違いで、
pタグをblockquoteで囲むのが正しいみたいなのですが、
なぜですか？　<blockquote>aaaa</blockquote>この引用は
段落ですということで、pを外につけるのではないのですか？
あと、段落は、見出しにも付けた方がいいですか？
<h1>おかしの説明</h1>
  アップルパイ
  クリームパン
  ショートケーキ
このひとまとまりにこう家をつけない場合でも、<div></div>で
囲んだ方がいいのでしょうか？

492 ：Name_Not_Found：02/03/17 18:01 ID:IdSEtw+v

>>491
＞<blockquote>aaaa</blockquote>この引用は
＞段落ですということで、pを外につけるのではないのですか？

「この引用は段落です」ってアナタ、逆でしょう。
「この段落は引用です」ということを明示するためにblockquote要素を
使う。

＞あと、段落は、見出しにも付けた方がいいですか？
＞<h1>おかしの説明</h1>
＞アップルパイ
＞クリームパン
＞ショートケーキ
＞このひとまとまりにこう家をつけない場合でも、<div></div>で
＞囲んだ方がいいのでしょうか？

「こう家」って何？（ﾋﾟｭｱ
見出しは見出し。段落ではないからp要素で囲う必要はない。

ていうかdiv要素は段落を示すものではない。

493 ：　：02/03/17 18:02 ID:O1Z7qz12

　ＸＸＸＸＸネット様

　こちらはインターネット掲示板２ちゃんねると申します。
　○月Ｘ日▲時■分～△時□分のあいだ、当掲示板にて以下のリモートホスト（xxx.xxxx.xxx.ne.jp）より、同内容の繰り返し書き込みが執拗に行われました。
　このような行為は掲示板運営を妨げ、また当掲示板のサーバや回線に無用な負荷を強いるものであり大変迷惑しております。
　つきましては、ＸＸＸＸＸ様におかれまして、該当するユーザー様から二度と同様の行為が行われないよう、厳正なる処置をお願いしたいと思います。

　なお現在、当掲示板では荒し行為を排除するため、正規表現で.*xxx.ne.jpに相当するすべてのリモートホストからの書き込みを拒否しており、ＸＸＸＸＸ様より「同ユーザー様からの同様な行為がないことを保証していただけるまで」この規制を継続します。

　また、このメール及び、ＸＸＸＸＸ様よりの返信等、事態の経過に関しては、当掲示板サイトにて公表させていただきます。あしからずご了承ください。

　２ちゃんねる掲示板
　　http://www.2ch.net/
　　[email protected]

４　経過報告
　規制が行われた以降は、プロバイダの対応等について、随時経過を公開

494 ：あぼーん：あぼーん

あぼーん

495 ：Name_Not_Found：02/03/17 18:31 ID:MuBQYNH1

>>492
> 「この段落は引用です」ということを明示するためにblockquote要素を使う。

これも何か変。

引用するものが段落のようなブロックならblockquote要素を使い、
引用するものがインラインならq要素を使う。

<p><blockquote></blockquote></p> が許されないのは、
<p><ul><li /></ul></p> が許されないのと同様なHTMLの不備のひとつ。

496 ：Name_Not_Found：02/03/17 18:34 ID:ARrmdLsA

>>495
引用"される"ものが、だろ。

497 ：Name_Not_Found：02/03/17 18:34 ID:IdSEtw+v

>>495
＞> 「この段落は引用です」ということを明示するためにblockquote要素を使う。
＞
＞これも何か変。
＞
＞引用するものが段落のようなブロックならblockquote要素を使い、
＞引用するものがインラインならq要素を使う。

変か？

498 ：Name_Not_Found：02/03/17 18:40 ID:IdSEtw+v

ていうか今書いた長いXHTML文書をValidatorに掛けたら
エラーもケアレスミスも一個も無くてちょっと嬉しかった。
いや、それだけなんだけど。

499 ：Name_Not_Found：02/03/17 19:12 ID:OXJvdCNZ

<p>hogehogehogehoge</p>

これを引用する↓

<blockquote cite="http://www.foo.com/>
<p>hogehogehogehoge</p>
</blockquote>

500 ：Name_Not_Found：02/03/17 19:14 ID:iRK8B5Gk

>>488
すみませんが、WCAGドキュメントのどの部分ですか？
いま、関連する箇所に目を通してみたのですが、そのような記述を
見つけられなかったのだけど。
cf, http://www.w3.org/TR/WCAG10-HTML-TECHS/#lists

501 ：Name_Not_Found：02/03/17 19:24 ID:OXJvdCNZ

ここ？
http://www.w3.org/TR/WCAG10-HTML-TECHS/ より

----

For numbered lists, compound numbers are more informative than simple numbers. Thus, a list numbered "1, 1.1, 1.2, 1.2.1, 1.3, 2, 2.1," provides more context than the same list without compound numbers, which might be formatted as follows:

1.
1.
2.
1.
3.
2.
1.

and would be spoken as "1, 1, 2, 1, 2, 3, 2, 1", conveying no information about list depth.

[CSS1] and [CSS2] allow users to control number styles (for all lists, not just ordered) through user style sheets.

Example.

The following CSS2 style sheet shows how to specify compound numbers for nested lists created with either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1", etc.

<STYLE type="text/css">
UL, OL { counter-reset: item }
LI { display: block }
LI:before { content: counters(item, "."); counter-increment: item }
</STYLE>

End example.

----

長文引用ｽﾏｿ

502 ：Name_Not_Found：02/03/17 19:53 ID:D8hsqzCL

関係ないが、「要素を使う」って言い方はやめようYO!
「要素と見做す」か、せめて「タグを使う」にしてくれ。

503 ：Name_Not_Found：02/03/17 20:53 ID:38PO88y1

>>502
＞＞「要素と見做す」か
なんて読むの？

504 ：Name_Not_Found：02/03/17 20:59 ID:QiLyaE8Q

>>503
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%B8%AB%D0%F6%A4%B9&sw=2

505 ：Name_Not_Found：02/03/17 21:12 ID:cXT1qVL7

「見做す」っつーのは六法風の書き方だと思うｙｏ！
普通はカナ表記じゃない？

506 ：Name_Not_Found：02/03/17 21:14 ID:q0HhAD+v

要素を使うのに「タグを使う」のは当たり前
「タグを使う」の方が微妙

507 ：Name_Not_Found：02/03/17 21:25 ID:N7csPrnQ

俺的見解。

1. 引用部分に、q要素を使う。　・・・　○
2. 引用部分に、qタグを使う。　・・・　△
3. 引用部分に、q要素を適用する。　・・・　◎

508 ：Name_Not_Found：02/03/17 21:43 ID:cXT1qVL7

「q要素としてマークアップする」だと思われ。
要素というのは文章が書かれたときからそこにあるものであって、
使うとか使わないとかいう問題じゃないだろ。

たとえばbodyタグは省略可能だが、たとえbodyとして明示的に
マークアップされていなくても、body要素がなくなるわけではない。

509 ：Name_Not_Found：02/03/17 21:57 ID:F56ElBLs

>>501
そこに書いてあるのは、入れ子リストにはcompound numbersを使いなさいよ、
ということであって、Orderd List要素ではなくUnorderd List要素で
マークアップすべしとは書いてないんだけど。

510 ：Name_Not_Found：02/03/17 22:11 ID:OXJvdCNZ

>>509
あぁ。けどこれ以上突っ込んだことは書かれていないようなんで、
>>488がちょっと勘違いしていたってとこでは？

# 他のソースあたってないから強く断定できないｶﾞﾅｰ

511 ：Name_Not_Found：02/03/17 22:52 ID:Kx/qYLpr

>>496
日本語を知らない人ですか？
君みたいな人は、
「購入するものがない」の代わりに「購入されるものがない」と言ったり、
「利用するものは鋏」の代わりに「利用されるものは鋏」と言ったり、
するんでしょうね。気持ち悪いよ、それって。

512 ：491：02/03/17 23:14 ID:FXiYAJjw

>>492
ありがとうございました。
参考になりました。

513 ：あぼーん：あぼーん

あぼーん

514 ：Name_Not_Found：02/03/18 11:29 ID:m7jwQwBn

>496, >511
どっちも正しいだろうに．
頭に「私が」が省略されてると思えば「引用『する』もの」だし，そうじゃなきゃ「引用『される』もの」
つーか，どこがstrictの話なのよ．

515 ：Name_Not_Found：02/03/18 11:34 ID:F9e/09QZ

「正しい日本語を使える人でないと(StrictなHTMLを使うのは)難しい」
という話ですか

516 ：Name_Not_Found：02/03/18 11:48 ID:iYIR9kMP

Strictな日本語の話題は板違いかと。

517 ：Name_Not_Found：02/03/18 19:15 ID:Umfb4tbQ

引用の話が出てるのでちょと質問。

昨日、友人とこんな会話をした。
自分「そういえば、春だねぇ。」
友人「ああ、駄スレ多いよな。」

とかの会話も引用とするものなのでしょうか。
<q cite="リアル">の感じで。（実際はcite属性はかいてません。）

518 ：Name_Not_Found：02/03/18 19:47 ID:NQLPB2a1

>>517
titleに書くことにしてる。

519 ：茶文字 ◆xELvisFU ：02/03/18 20:24 ID:CmwgrilX

.htmlぢゃなくて.txtなら、カギ括弧が q だの blockquote だのの役割を果たしてるんだよね。
カギ括弧は他に、dfn の役割をすることもある。
こう考えると、:before :after 擬似要素がまともに使えるようになって欲しいな。

520 ：Name_Not_Found：02/03/19 11:35 ID:QsGOWof8

>>517
cite属性の値になるのってURIだけじゃなかったっけ？

521 ：Name_Not_Found：02/03/19 12:56 ID:l44tdaMU

>>520
その通り。

522 ：Name_Not_Found：02/03/19 18:15 ID:GJaoGv/2

ばけらさんは、メールアドレスの@を、@としているのですが、
これは、普通に@ではいけないのでしょうか？

523 ：Name_Not_Found：02/03/19 18:16 ID:GJaoGv/2

& #64のことです。

524 ：Name_Not_Found：02/03/19 18:21 ID:dVfi5Z8P

アドレスをソースから収集されないためだろ

525 ：517：02/03/19 18:30 ID:gAmMAzxZ

>>518
titleですか。
すみませんが何と書いてますか？
ポップアップされるのは嫌なんだけどなぁ。

>>520
いや、実際には書いてないですって。
<q>セリフ</q>としてるんですけど、なんか違和感があって。

会話は引用とは違うのかなぁ？

526 ：Name_Not_Found：02/03/19 19:22 ID:6eCnCzcA

>>525
　政治家の演説とかなら十分 q 要素の範囲では？
　知人との会話でも「引用」するなら q 要素かとは思うが、普通の会話って著作権が成立するとも思えん。
　ここら辺は markup ではなく、著作権法の適用範囲の問題になるんではないかな、と。

527 ：茶文字 ◆xELvisFU ：02/03/19 19:23 ID:i1SHtkUf

>>526
私も同じことを考えてた＜著作権法
たとえば小説なんかで登場人物のせりふに引用の要素を適用するのはﾁｮﾄ違うと思う。

528 ：Name_Not_Found：02/03/19 19:27 ID:2zzIc2iH

>>522
>>524 で解ったかな。下記参照。
ttp://www17.u-page.so-net.ne.jp/qb4/chiharu-/reject_virus.html

529 ：520：02/03/19 19:52 ID:QsGOWof8

>>525

その部分が、著者の記述ではなく、他者の発言の引用であることを
特に強調したい場合、または、その発言に表された発言者の思想なり
意見なりを紹介することを意図して引用した場合以外は、特にq要素
としてマークアップする必要はないのでは。

あと、q要素としてマークアップする場合でも、地の文にカギカッコは
つけた方がいいと思います。
カギカッコを外しちゃうと、CSSが無効な環境では、それが発言だって
ことがわかりにくくなってしまうので。

530 ：Name_Not_Found：02/03/19 20:00 ID:aJ4WUCHt

>>525
関連スレ:「Ｑ要素：インライン引用文のマークアップについて」
http://natto.2ch.net/hp/kako/1002/10027/1002750163.html

531 ：Name_Not_Found：02/03/19 21:09 ID:wFGZmKsb

>>522-524
ここ参照。↓
「ウイルスからサイト内のメールアドレスを隠す」
http://www17.u-page.so-net.ne.jp/qb4/chiharu-/reject_virus.html

532 ：Name_Not_Found：02/03/19 22:17 ID:Z8ntJrE3

>>529
>地の文にカギカッコ
"「引用文だよ～ん」"
って表示にならないかい？
ダブルクオートはNS6なら消せるけどMacIEじゃ消せないよ。

533 ：517：02/03/19 22:21 ID:gAmMAzxZ

>>526-527
なるほど。
著作権から考えると q要素で囲むのはオカシイですね。

>>529 （520氏）
ただ、発言を囲ってるだけですし無い方が良さげですね。
あと、鍵カッコはつけてます。言葉足らずｽﾏｿ。

>>530
親切にありが㌧。
そのスレで会話の引用にも触れてたので参考になりました。

結果として、会話には必要なさそうですので、外します。
みなさん、親切にありがとうございました。

ポッキーの甘味。

534 ：517：02/03/19 22:22 ID:gAmMAzxZ

>>532
ﾏｸは quotes :none; が効かないんですか？

535 ：Name_Not_Found：02/03/19 22:28 ID:sfl/RIxt

>>532
このスレ的には
q { quotes:none }
とでも指定するとか。

> ダブルクオートはNS6なら消せるけどMacIEじゃ消せないよ。
User-Agentを呪いませう。

# ってか、そもそも勧告の
「UAはQ要素の前後に引用符をレンダリングrしなければならず、書き手は引用符を書くべきではない」
がアレだったり……>>530で散々既出だけど。

536 ：Name_Not_Found：02/03/19 22:28 ID:x+qlaJiZ

>>534
うん、効かない。
ダブル・クオテーションマークも本来“”であって""になるのはイヤだな。
だから私は<q></q>でマークアップしない。必要性を感じないし
自然言語の鍵括弧（「」）によるマークアップがあれば十分。

537 ：Name_Not_Found：02/03/19 23:58 ID:ru2z/wiM

>>536
ﾀｼｶﾆﾅｰ。
でも、Strict的にはどうだい？やっぱqマークかい。
まぁ、堂々巡りな話になるから、とりあえずUAの実装を待とうと。（殆どそうだけどなー

538 ：Name_Not_Found：02/03/20 01:03 ID:F5WsSygj

表示依存でマークアップを変えるなYO!
段落内の引用はq要素。これは定説です。

539 ：Name_Not_Found：02/03/20 01:19 ID:9S4Stb0X

まず文章ありき、の立場からすれば、マークアップする時点で原文に手を入れなくては
いけない（カギ括弧 or quotation mark の削除）のは釈然としない。

540 ：Name_Not_Found：02/03/20 02:02 ID:+pgAc/WK

「<q>引用文</q>」でいいんじゃないの？
q { quotes:none } も指定しておいて。

541 ：Name_Not_Found：02/03/20 02:14 ID:OVyMZj19

>>540
>q { quotes:none } も指定しておいて。
だからそれ、Netscape6/Mozillaしか効かないって。

542 ：Name_Not_Found：02/03/20 02:20 ID:OVyMZj19

いや、Netscape6/Mozillaでもquotes:noneは無効。
Q:before, Q:after {content:"";}だね。

543 ：540：02/03/20 02:48 ID:+pgAc/WK

あ、そうです。そんなかんじ。

544 ：Name_Not_Found：02/03/20 09:42 ID:HLzJ7cko

だからMacIEでは
quotesもcontentも効かないってば。

545 ：Name_Not_Found：02/03/20 09:54 ID:GCtPQK1G

>>544
気にするな。

546 ：Name_Not_Found：02/03/20 12:11 ID:vwCgRGrM

>>539
地の文の引用符は、引用であることを示す「装飾」でしかない。
だから地の文に鉤括弧があっても削除してよい。

これはリストマークとしての中黒や数字を
(元のテキストから)削除するのと同じこと。

・<li>項目</li>
・<li>項目</li>

これじゃ違和感あるだろ。

「<q>引用</q>」

というのもこれと同類。地の文に引用符は要らない。

547 ：Name_Not_Found：02/03/20 13:49 ID:8XKFTVkE

q の話題で盛り上がってるところすみません。
KENT-WEB の Aska BBS を Strict な出力にするべく、
HTML 出力部分を修正中なのですが、
投稿フォームの入力部分のマークアップでなやんでいます。

<p><label accesskey="n">名前<input name="name"　略></label></p>

と、

<ul>
<li><label accesskey="n">名前<input name="name"　略></label></li>

と、

<dl>
<dt><label accesskey="n" for='name'>名前</label></dt>
<dd><input name="name" id='name'　略></dd>

と、３つほど候補が思いついたんですが、
Strict 的にはどれがいちばんふさわしいんでしょうか。

最初、dl でやってたんですけど、どうも違うような気がしてきて。

548 ：Name_Not_Found：02/03/20 15:25 ID:a/Hxh5+F

>>547
<address>が良いと思ひます。

549 ：Name_Not_Found：02/03/20 15:40 ID:GISBrzdi

>>547
いっそ table の方が自然かもとか思った。

550 ：547：02/03/20 16:38 ID:8XKFTVkE

>>549
<table>かあ。
個人的には投稿フォームって、表って感じもしないんだけど、
段落やリストよりは表のほうがよさげな気もしてきたなあ。

無邪気にテーブルのままでレイアウト組みなおせば
よかったのか。何か欝。

551 ：Name_Not_Found：02/03/20 16:47 ID:Iok210b2

おれは個人的にTABLEよりDLだと思います。
うちのサイトは全部そうしてる。

552 ：Name_Not_Found：02/03/20 16:56 ID:OlnrkCqe

>>547
自分もYYBBSをStrict化してみましたが、そこはdlにしてます。
dl要素=「2種類の部分を持ったリスト」という観点で。

553 ：Name_Not_Found：02/03/20 17:50 ID:4W3Di032

>>547
<dl>の方がいい気がする。
うちは<ul>でやっちゃってるけど。
もう一度組み直そう。

554 ：***：02/03/20 17:52 ID:qQbG5k42

私も<dl>。
>>552と同じく2種類の部分を持ったリスト」という観点より。
たまに<ul>も使うけど、<table>ではないと思う。

555 ：547：02/03/20 17:56 ID:8XKFTVkE

>>551-552
dl って、定義リストでしょう。

定義に入力して欲しいものの名称
内容に入力ボックス
って使い方がはたしていいのかどうか、と、悩み始めたらとまらなくなったです。

定義リストでマークアップした時に
クッキー保存するかしないかのラジオボタンの配置はどうしようとか…。

tableだろうが、ulだろうが、仕様書の書式をはずれなければ
文法チェックは通っちまう訳で、自己満足できるもので
マークアップすればそれまでといわれればおしまいですが。

とりあえず、悩まなくてもすむ部分を修正して煮詰まった頭を冷やします。

556 ：Name_Not_Found：02/03/20 18:20 ID:XNOi83Fr

dlは定義リスト以外に使ってはいけないわけではないんじゃなかったっけ

557 ：サ骨 ◆/IQ5000w ：02/03/20 18:35 ID:xKuVS3uO

とりあえず手元の本には、
「dl要素はその応用範囲が広く、対話を表現する場合など
他に利用できる適切な要素が無い場合には、
用語の定義に限定せず使用することが認められています。」
とある。

"会話"てのは

<dl>
<dt>東出</dt>
<dd>「こんにちは」</dd>
<dt>今岡</dt>
<dd>「こんにちは」</dd>
</dl>

てことか？

558 ：Name_Not_Found：02/03/20 18:39 ID:Iok210b2

例えばインタビューとか良い例だと思うな。

559 ：：02/03/20 19:09 ID:RxcfF4pN

>557
それ，秀和システムの岡蔵さんの本だよね．
で，その「認められます」ってのは別のどこかに記述があるのだろうか？
4.01 recomendation（日本語，英語）とか神崎さんのところとか見てみたけど書いてない．

560 ：：02/03/20 19:10 ID:RxcfF4pN

Recommendationだ．mが1個足らんかった．ぐぅ．

561 ：520：02/03/20 19:16 ID:ujjPJmXt

>>559

鳩丸には、

> 基本的には用語とその解説を示して用語集を作るのに用いますが、
> 日記の日付とその内容、会話の発言者とその発言内容、などなど、
> 一対一で対応するものを表現するのに広く使われているようです。

と、書いてある。

562 ：Name_Not_Found：02/03/20 19:26 ID:VYL0cT/G

というか、XMLじゃ有るまいし、要素の数は有限なんだから、
出来るだけそれに近いモノでカバーするしかないような。

563 ：Name_Not_Found：02/03/20 19:31 ID:GISBrzdi

>>559
http://www.w3.org/TR/html401/struct/lists.html#h-10.3
> Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.
「認められている」とまで言える記述かどうかは微妙だが。

564 ：Name_Not_Found：02/03/20 19:35 ID:Iok210b2

>>562
同意。認められてるか認められてないかなんて、俺にはどうでもいいです。本質はそこじゃないと思う。

565 ：：02/03/20 20:00 ID:RxcfF4pN

>564
じゃどこ？
<p>でなく<dl>でマークアップするほうが「適切」だと言える根拠は？
僕も別にどこかで認められてる必要性は感じないけど，
明確に書いてくれてるほうが安心して使える（マークアップできる）ってだけなんだが．

566 ：Name_Not_Found：02/03/20 20:10 ID:XNOi83Fr

なぜp要素が出てくるんだ

567 ：Name_Not_Found：02/03/20 20:46 ID:VYL0cT/G

>>565
だから、557氏が引用した岡倉氏の説明で良いんじゃないかと。

568 ：Name_Not_Found：02/03/20 21:14 ID:djB8AQNF

>>565
根拠といわれてもなぁ。根拠なんてたいそうな物はありません。>>547の場合、俺ならDLが一番しっくりくるって言うだけで、それでTABLEでもないだろう（未対応ブラウザとか考えると）と思うだけで、大間違いだとも思えないし、申し訳ないけどうまく説明は出来ないな。
っていうか、そんなに不安ですか？各自の性格もあるんだろうけど、俺的には、そこまで悩まなくていけないところなのか、疑問です。>>547さんも悩みすぎだと思う。（煽ってるわけではないです）

569 ：547：02/03/20 21:17 ID:qwJ2A6tq

うお、家に帰ってきたらﾚｽいっぱいついてる。

私が悩み始めたのは、label要素とinput要素は分けるものじゃなくて、
一緒の要素の中につっこんだほうがいいのかなあと思い始めたからです。

そうすると、dtとddに分けるのじゃなくて、
li か p でひとまとめにしたほうがいいのかなって気もして、
それで最初の書き込みになったわけですが。

入力して欲しいものを列挙してるんだから、p は論外で、
dt dd をつかうか、li を使うかは入力項目とそのラベルについての
考え方の違いかなという気もしてきました。

570 ：547：02/03/20 21:23 ID:qwJ2A6tq

>>568
いや、実際、余計なところで悩みすぎだとは自分でも思ってます。
気にしなくてもいいのかな。

571 ：Name_Not_Found：02/03/20 21:26 ID:djB8AQNF

>>569
> label要素とinput要素は分けるものじゃなくて、
> 一緒の要素の中につっこんだほうがいい

そんなことはないと思いますよ。for属性があるんだし、どっちでもいいと思う。

572 ：Name_Not_Found：02/03/20 21:29 ID:UTU8OhJd

<ul>
　<li>
　　<p>うんたら</p>
　　<p>かんたら</p>
　</li>
</ul>

の方が良さそうに思える。

573 ：Name_Not_Found：02/03/20 21:40 ID:djB8AQNF

>>570
俺も悩んでた時期があったんですよ。
でもそれで更新が滞ったりして、あんまり考えなくなった。
というか、満点じゃなくていいやと思うようになったんです。
人がまず見るのはマークアップの仕方じゃなくてタグに挟まれた部分だし。
DLが正解にしろPやULが正解にしろ点数つけたら2点差ぐらいじゃないかって思います。

>>572
少々冗長な感じがします。

574 ：　：02/03/20 22:06 ID:9IndTsUV

<ul>
　<li>うんたら</li>
　<li>かんたら</li>
</ul>
かな？

575 ：Name_Not_Found：02/03/20 23:11 ID:vLUO75hV

でも>>574はちょっと変な気もするが…。

576 ：Name_Not_Found：02/03/20 23:21 ID:7EKJR6nV

漏れはxhtml派だから、UAが処理しやすい形で、well-formedなら
いいと思ふ。
再利用しやすい形にマークアップすればいいんじゃないか。
誰が再利用するかは、知らんけどね。(w

577 ：Name_Not_Found：02/03/20 23:40 ID:KbFBT8sL

オイラは、
<ul>
<li><label>名前：</label><input type="text"></li>
</ul>
のようにしてる。（一部略）

578 ：Name_Not_Found：02/03/21 01:47 ID:ckGlQybz

small {font-size:90%;}
.small {font-size:90%;}

StrictなHTMLには、
<small>あいうえお</small>
か、
<p class="small">あいうえお</p>
どっちがいいのでしょうか？

579 ：520：02/03/21 01:57 ID:TDFSjlsl

>>578
class属性の値は"small"じゃなくて、
「なぜその字を小さくしたいのか」
を表すことばの方がよいのでは？
たとえば覚え書きだったらp class="memo"とか。

俺は、せっかく仕様で認められてるんだからいいや、
って感じで、small要素としてマークアップしちゃってますが。

580 ：茶文字 ◆xELvisFU ：02/03/21 01:57 ID:isnCxeCA

>>578
pってのは例だよね？
たまたま例ではpだけど、そこはいろんな要素を考えてるんだよね？

そうでないなら、ブロック要素とインライン要素を区別できてないことになっちまう。
例示するなら<span class="small">ぢゃないかい？

で、この手の話題はさんざｶﾞｲｼｭﾂじゃないかと思う。

581 ：j君：02/03/21 13:21 ID:msTTUuIC

>>578
小さくしたいだけなら
<small>でいいよ
strictでも認められているんだから
物理要素がいやだというならclass名も
それなりに579のいうように
<p class="note">alt属性は必須です</p>
とか
<p>彼女と別れました、ぜんぜん構いませんが<span class="本音">嘘</span></p>
とか

582 ：j君：02/03/21 13:28 ID:msTTUuIC

>>581補足
<p>彼女と別れました、ぜんぜん構いませんが<em class="本音">嘘</em></p>
という風に
一部W3C原理主義者【誰】はspanを嫌いemを使う場合もある。
フォントを小さくしてもそれはそれで強調であるとのこと。
わたしはp.noteとか段落全体の文字を小さくすることあるけど
文中で、一部だけ小さくするというのは避けてますけど。
まあこればっかりは好き好きかと。

583 ：Name_Not_Found：02/03/21 15:14 ID:k9IuMLvA

>>581-582
<em style="text-decoration:line-through;">嘘<em>
もアリかも。

584 ：Name_Not_Found：02/03/21 15:15 ID:iKPj2mbx

>>583
言いたいことは解るが、話がずれてる(w

585 ：520：02/03/21 20:36 ID:TDFSjlsl

装飾によって文章を強調する場合、その装飾が何を表しているのか
説明することは、書籍などではよくあることだと思います。
「下線部は原文ママ」とか「太字の部分は筆者による注釈」とか。
こういうのは、strict的にはどういう風に表現したらいいんでしょう。

1.非推奨ではない物理スタイル（BやIなど）を用いて、
　「太字の部分は筆者による注釈」とやる。
2.strongやemを用いて、
　「strongタグでマークアップされている部分は筆者による注釈」とやる。
3.title属性を用いて<strong title="筆者による注釈">とやる。
4.マークアップに頼らず、地の文でいちいち、
　「以下は、筆者による注釈である」などと明記する。

586 ：Name_Not_Found：02/03/21 20:47 ID:AGQp+jq5

原文ママ＝引用＝q要素
筆者による注釈＝<span class="note">～</span>

p{text-decoration:underline}
span.note{font-weight:bold}

587 ：Name_Not_Found：02/03/21 20:52 ID:iKPj2mbx

>>585
1.の方法だと、音声環境なんかで意味不明になるし、論理的でない。
2.だと冗長だし HTML を知らない人には意味不明。
3.4.はまあ一つの方法だろう。引用文を強調するときは漏れも title 使うし。

という訳で、普通は strong でマークして「強調部分は筆者による…」とする。
これなら環境に依存しないし。

そもそも「strong としてマークされている部分」っていうのは、
要するに強調部分でしょ。だったら「強調部分」と説明した方がわかりよい。

588 ：あぼーん：あぼーん

あぼーん

589 ：Name_Not_Found：02/03/21 22:55 ID:Wfhn2nO1

例えば、こういう試験問題があるとします。
「下線部 A ～ F のうち、誤りがあればその箇所を指摘し、理由を述べなさい」
これをHTML文書に書き直すとしたら、
「強調部 A ～ F のうち、誤りがあればその箇所を指摘し、理由を述べなさい」
と、なるのでしょうか。

これにはちょっとだけ問題が起きる可能性があると思ったのです。
プレーンテキストで表示するブラウザがあるとしたら、
強調部を「強調」してレンダリングしてくれる保証はあるのでしょうか…。
そうでなくても、ユーザスタイルシートで無効にしている装飾を
CSSでem要素などに適用していると、
地の文と区別がつかなくなってしまう可能性もある気がするのです。

# そもそも元々の文が物理マークアップに依存してるせいなのかも(w

590 ：Name_Not_Found：02/03/21 23:36 ID:ID+uXGGc

＞「強調部 A ～ F のうち、誤りがあればその箇所を指摘し、理由を述べなさい」
＞と、なるのでしょうか。

＞# そもそも元々の文が物理マークアップに依存してるせいなのかも(w

その通り。
じゃなきゃ、リストにした方がもともと分かりやすくないですか？

591 ：茶文字 ◆xELvisFU ：02/03/21 23:38 ID:isnCxeCA

Webは紙媒体のメタファーではないと思うんだな。
メディアが違うんだから、最適化できるなら最適化した形で提示すべき。

592 ：Name_Not_Found：02/03/21 23:57 ID:NIIuTAJG

>>591
メタファーって、どういう意味?

593 ：茶文字 ◆xELvisFU ：02/03/22 00:18 ID:ox9mwJ89

>>592
比喩

つまり、紙媒体の概念をそのままWebに持ち込むべきではないと思うんだよね。
Webは新しいメディアなんだから、紙媒体のイメージに束縛されるべきではない。
HTMLにはHTMLだからこそできる(紙媒体にはできない)ことがあるけど、
逆もまたしかりで、紙媒体にできてHTMLにできないことだってあるわけだから、
HTMLという形態を選んだ以上「紙媒体のスタイルをそのままトレースする」という
発想は制約を産むだけであんまりうまくないと思うんだ。

紙媒体の完璧な再現を目指すなら、それこそPDFの出番じゃないか？

594 ：Name_Not_Found：02/03/22 01:11 ID:0JK8Xamf

>>589
> プレーンテキストで表示するブラウザがあるとしたら、
> 強調部を「強調」してレンダリングしてくれる保証はあるのでしょうか…。

強調部を強調しないようなブラウザは、
そもそも HTML ブラウザとして不正だろ。

つーか、A-F というアルファベットが振られていれば、
極論「下線部」とか「強調部」という表現なしに「A-F の中から…」
だけでも通じるのでは?

破線/二重線/傍点などが混在しているような状況なら、
記号も A-F イ-ヘ 1-6 などで使い分けるべきだし。

595 ：Name_Not_Found：02/03/22 01:53 ID:0bRwYWVv

サ骨氏を受験板某スレでﾊｯｹｿ
先輩ﾖﾛｼｺ

オフトピsage

596 ：Name_Not_Found：02/03/22 01:58 ID:0bRwYWVv

>>595
と思ったら勘違いﾀﾞﾀｰﾖ
ｺﾞﾒｿ＞サ骨氏

597 ：520：02/03/22 02:49 ID:mvG4ClAe

>>587
だいたい俺自身の結論と一緒なんですが、ひとつだけ気になるのは、
文中に他の要素も混在してた場合、どれが強調なのかわかりにくい
ということ。
たとえば、文中にstrong要素とdfn要素が混在してたら、HTMLに
詳しくない人は、どっちが「強調」なのか分かりにくいだろうなあ、と。

やはり、こういった書き方自体が、Webでは避けるべきなんでしょうね。

598 ：Name_Not_Found：02/03/22 09:32 ID:0bRwYWVv

>>597
そこら辺は(auralにしろvisualにしろ)スタイルシートに任せる
しかないような気が。

あとは凡例でもつけるくらいしか思いつかんなぁ。。。

599 ：Name_Not_Found：02/03/22 10:24 ID:SbncSnZt

>>597
ブラウザは HTML 文書を利用しやすくするものであって
結果として HTML を知らなくても HTML 文書をそこそこ利用できるようにするけれど
そういう人に意味を伝えることは、最終的にはできない。
HTML で「意味」を伝えられるのは、結局のところ UA まで。
文書利用者まで意味が伝わるためには、利用者側の HTML 理解が必須。

HTML に疎い人に充分に意味が伝わらない(かもしれない)ことが問題になるなら、
プレーンテキストの状態で意味の通らない文章は避けるべき。
本当はそういう人に HTML 文書を利用させること自体に問題があるのだと思うけど。

600 ： ◆alib/Myc ：02/03/22 16:15 ID:n+bBMtky

>>594 レンダリングは UA 依存強調部分を強調表示しなくてもなんら問題はない

601 ：Name_Not_Found：02/03/22 17:10 ID:e1l0kuOi

strict的には、
<SPAN style="text-decoration: underline;.color: red">親<SPAN style="color: blue">子</SPAN>親</SPAN>
として、アンダーラインを赤にしてもいいですか？

602 ：Name_Not_Found：02/03/22 17:25 ID:Z+x7p2Kx

好きにしれ。
ただ、親が「下線つき赤」、子が「下線つき青」に表示されないと通じない文章を
書くのはNG。

603 ：Name_Not_Found：02/03/22 17:37 ID:5wGdK09Q

>>601
うん、CSS2の仕様書通りですよ。
http://www.w3.org/TR/REC-CSS2/text.html#lining-striking-props

参考までに、岡橋一輝氏訳を
>このプロパティは継承を行わない。
>しかし当該ブロックの子孫部に当たるボックスは、
>すべて同じ装飾を施されるべきである(たとえばすべて下線を施されるべきである)。
>またその時、子孫部の要素が'color'プロパティに異なる値を持っていても装飾の色は同じにすべきである。

604 ：あぼーん：あぼーん

あぼーん

605 ：Name_Not_Found：02/03/23 00:36 ID:beR0zcuj

>>601
Strict的にはそういう書き方自体が・・・

606 ：Name_Not_Found：02/03/23 01:26 ID:xYMk3Zvh

>>605
胴衣。validなだけでもなぁ。

スレタイ的にはいいのか。

607 ：ナナシ：02/03/23 09:07 ID:jYh6EORB

Strict的って
解釈が色々あるよね。いまさらだが・
W3C信者的って方がいいのかな？
XHTML1.1からStrictなくなっちゃうし。

608 ：Name_Not_Found：02/03/23 11:34 ID:zY7zFzRE

「内容に即したマークアップを心がける人達」

短く言うには、やはり頭文字。
"内即マ心人"

-- ボクのこと、忘れてください。--

609 ：Name_Not_Found：02/03/23 11:35 ID:PjPSLs1c

>>607
transitional がなくなったから、strict と名乗る必要が無くなっただけでは？
XHTML 1.1 が strict ではない、と言う事は無いはず。
相変わらず一部の表示用要素が存在するが、少なくとも HTML 4.01 strict と同じくらい strict。

610 ：Name_Not_Found：02/03/23 12:14 ID:xYMk3Zvh

>>609
煽るわけではないけど、HTML4.01よりうんと厳密。
ttp://niaou.alib.jp/columns/xhtml/1211.html

611 ：Name_Not_Found：02/03/23 15:38 ID:wgwh3BNK

Strictly Htmlized

612 ：Name_Not_Found：02/03/24 03:12 ID:uxpixGYI

つーか元々 HTML と言えば Strict なのであって、他の何でもありません。
HTML 4.01 / XHTML 1.0 でわざわざ 'Strict' と書いているのは
Transitional / Frameset という亜流があったため。

# まあ HTML 2.0 や HTML 3.0 にも Strict ってあるんだけどね。

613 ：601：02/03/24 03:25 ID:OHNzWW27

>>602
>>603
>>605
>>606
>>607
>>609
さんありがとうござました。

614 ：うし２歳 ◆Cow.owR. ：02/03/24 15:39 ID:qNFoN8WD

(´-`)。ｏＯ（飾り枠の実験。あまり、美しくない。。）
(´-`)。ｏＯ（mozillaでスタイルシート外したりしてみて下さい）
http://sakots.pekori.jp/ushi/jikken/mou.html

615 ：うし２歳 ◆Cow.owR. ：02/03/24 15:47 ID:qNFoN8WD

(´-`)。ｏＯ（たしかにbackground-imageの重ね張りができたら１発なんだよね）

616 ：Name_Not_Found：02/03/25 01:31 ID:EBVgXmSd

<dl>の中身って<dt>と<dd>以外は一切ダメなんでしたっけ？
例えば<dl>の中に<div>使ってクラス指定したいんですが。

617 ：Name_Not_Found：02/03/25 01:39 ID:VJFM/Bmv

>>616
ダメ。

618 ：Name_Not_Found：02/03/25 01:40 ID:1/AbcGCb

dl要素内に配置できるのは、dt・dl要素のみ。
dt要素内にはインラインレベルの要素。
dd要素には大抵いける。

619 ：Name_Not_Found：02/03/25 01:40 ID:1/AbcGCb

あ、遅かった。

620 ：Name_Not_Found：02/03/25 01:41 ID:1/AbcGCb

>>618の訂正
dl要素内に配置できるのは、dt・dd要素のみ。

621 ：616：02/03/25 01:48 ID:EBVgXmSd

>>617-620
やっぱりだめですか・・・
ありがとうございました。

622 ：Name_Not_Found：02/03/25 02:24 ID:QhFInta0

dt、dd要素にそれぞれclass属性指定すればいいじゃん？

623 ：616：02/03/25 03:41 ID:EBVgXmSd

>>622
dtとddをひとつのカタマリとしてfloatさせたかったのですが、
それぞれにclass指定でできますか？
＃いろいろ考えたけど思いつかなかった・・・

624 ：Name_Not_Found：02/03/25 04:20 ID:p7YK3mKC

<dl class="nanika">
じゃだめなの？

625 ：Name_Not_Found：02/03/25 06:34 ID:+9Pq4/wp

HTML 4.01 / ISO-HTML なら dl 直下に del/ins も書ける。

と言って混乱させてみるテスト。

626 ：Name_Not_Found：02/03/25 11:38 ID:xiQbMYZ2

627 ：Name_Not_Found：02/03/25 11:56 ID:pwyUd4/r

>>625
煽りにマジレス。それ使えば>>616の願いはかないそうだが
不思議マクアプだわな。

けど>>623を読んでいると、これはむしろtable？と思った。

628 ：Name_Not_Found：02/03/25 11:57 ID:pwyUd4/r

>>626
たしかbodyの周辺を参照

629 ：616：02/03/25 12:23 ID:Ae+EvCcx

>>624
現状それでやってますが、
ひとつのリストなのにhtml上はバラバラになってしまうのが
なんとなく気持ち悪かったので。

>>627
なんか「tableを使わずに」というのが頭にあったもので存在を忘れてました。(w
確かにこの場合はtableでもいいのかもしれないですね。

630 ：サ骨 ◆/IQ5000w ：02/03/25 18:56 ID:a4RyvW4m

pre.ascii_art {
    font-family: "ＭＳＰゴシック";
    text-align: left; font-size: 16px;
    line-height: 1.1;
}

631 ：Name_Not_Found：02/03/25 19:30 ID:uWz0Je1Q

http://mwave.sppd.ne.jp/diary/?date=20020320#c01
誰か解説してくれ･･･

632 ：Name_Not_Found：02/03/25 19:52 ID:Hf6SWrnI

>>631
何を？

633 ：茶文字 ◆xELvisFU ：02/03/25 20:22 ID:epk0/5Mh

>>631
極論同士のせめぎ合い。
Flashに頼ったサイトのアクセシビリティーの低さがとっかかりだったのに、
いつの間にか「正しいHTMLは難しいから普及しない」とかの話になってるし。

でもま、読んでて面白かったよ。
全部目を通したら薄っぺらい本一冊読んだくらいの満腹感だったけど（ｗ

634 ：Name_Not_Found：02/03/25 20:42 ID:/SGvXK1n

dl要素内でのdivはだめとのことですが、
dtやdd要素内ならよいのでしょうか。

635 ：茶文字 ◆xELvisFU ：02/03/25 20:49 ID:epk0/5Mh

>>634
dl直下に置けるのがdtとddだけなのであって、divが置けないのは当然。
dtはインライン要素しか内包できないから、やはりdivを置くことはできない。
ddならdivを内包できる。

間違ってたら指摘よろしゅ>ALL

636 ：Name_Not_Found：02/03/25 21:28 ID:Dm8oezyI

別に間違ってないと思う

637 ：Name_Not_Found：02/03/25 21:42 ID:a4RyvW4m

　　dl要素の内容モデルは、dt要素もしくはdd要素に限られます。
　　従って、dl要素の直接の子要素としてもう一つdl要素を持ってくることはできません。
　　
　　dt要素の内容はインライン要素に限られますが、
　　dd要素はインライン要素、ブロックレベル要素のどちらも内容とすることができます。
　　つまり、定義対象（dt要素）にできるのは単語やフレーズのみですが、
　　その説明（dd要素）は複数の段落や図を含んだものであっても良いというわけです。
　　事典でのそれぞれの役割を考えるとこの使い分けを理解しやすいと思います。

http://www.kanzaki.com/docs/html/htminfo13.html
の「定義型リストの内容モデル」より。

638 ：Name_Not_Found：02/03/25 22:01 ID:DinL+iWe

StrictはHTMLだけじゃなくCSSにも言われると思った今日この頃
HTMLだけ完璧でもCSSがエラーだらけじゃ意味ないか…

CSSチェッカー
http://www.htmlhelp.com/tools/csscheck/

639 ：Name_Not_Found：02/03/25 22:24 ID:DPb5Rm8Q

>>638
要するに仕様を読めるか読めないか、 DTD を読めるか読めないか、
DTD に違反する不思議マークアップを破損ファイルと捕らえているか否か、
みたいなところではないかと。

640 ：Name_Not_Found：02/03/25 23:33 ID:vFYI9ry4

css2完全対応じゃないのね

641 ：Name_Not_Found：02/03/25 23:33 ID:mphT//e9

>>638
background-colorよりbackgroundの方が
広くサポートされてるって言われても．．．。
色指定も、rgb(x,y,z)よりも#rrggbbの方が、と文句言われる。

なんだかなぁ。

642 ：Name_Not_Found：02/03/25 23:43 ID:Ae+EvCcx

これ使ってますが。
http://jigsaw.w3.org/css-validator/

643 ：Name_Not_Found：02/03/26 01:43 ID:K877APeb

>>641
backgroundと他はどっちが良いとされてるんだろう？
俺はbackground使ってるけど…

644 ：Name_Not_Found：02/03/26 01:50 ID:NKRWo2Xa

>>643
backgroundは、imageの方の値は必須なんすか？
validatorで>>641のように言われて以来、
背景色のみで背景画像のない部分を

.hoge{
background: #000 none;
}

のように記述していますが、冗長的ですか？

645 ：641：02/03/26 01:56 ID:wMaBd8Zq

fontプロパティと一緒で、
backgroundプロパティは

・background-color
・background-image
・background-rapeat
・background-position
・background-attachment

を一括指定出来るというだけの話で、それ以上でもそれ以下でも無い。
僅かでもファイルサイズを削りたければ、
backgroundで一括指定したら良いんだけど、
border辺りも含めて
一括指定は後から見た時に解り難いから、個人的には嫌い。

そういえば、IE3だったか（あやふや）が、
background-color等を認識しなくて、
border-bottom(topその他含む)はNN4が認識しないらしいけれど、
そんなのは今時知った事では無いよね。

646 ：Name_Not_Found：02/03/26 02:05 ID:tIm/lm2B

↑が今ネスケ４を裏切った発言をしました

647 ：Name_Not_Found：02/03/26 02:07 ID:NKRWo2Xa

>>645
なるほど。

# 自分が仕様をちゃんと読まなかったのが悪いので
# これから読んできますが、
つまり
> background-colorよりbackgroundの方が
> 広くサポートされてるって
いうあのvalidatorの指摘は、
２つの記述が全く等価であるからナンセンスなんですね。

ただ、UAの実装の面から見て、background-colorより
ショートハンドの記述の方が実際に広くサポートされてるんですか？

border関連なんかだと確かに似たようなことが多くありますが、
ZSPCなどを見る限り、background-colorとbackgroundは
IE3しか対応状況に違いがありません。

648 ：641：02/03/26 02:08 ID:wMaBd8Zq

>>644

http://www.ne.jp/asahi/minazuki/bakera/html/css/colors#background

今は仕様書まで見る気力が無いんだけど、
ぱけら氏が正しければ要らないみたいだね。
638のvalidatorがダメなんだと思う。

でも、644の例は何故background-colorでやらないんだろ、
という疑問の余地も。

649 ：Name_Not_Found：02/03/26 02:08 ID:NKRWo2Xa

てかすれ違いなので、css質問スレ行ってきます。

650 ：644=647=648：02/03/26 02:09 ID:NKRWo2Xa

>>648
ただひたすら、>>641のように言われたためです。
逝ってきます。。。仕様書読みに。

651 ：Name_Not_Found：02/03/26 02:10 ID:K877APeb

俺color指定だけでもbackground使ってる
全体的に統一したいし

652 ：Name_Not_Found：02/03/26 02:18 ID:K877APeb

>>余談ながら、何故か IE3 は background-image などを認識せずに、省略形の background のみを認識するようです。

これ見てbackgroundでいいやと考えてしまった。IE3はCSS無視させてるけど…

653 ：641：02/03/26 02:30 ID:wMaBd8Zq

>>651
スレ違いでも、あと一つだけ。
その辺の一括指定は、アンケート取ってみたら面白そうだね。
私の場合は、
border→border-bottom（topその他含む）
だけは一括指定を使ってて、
あとは、値が0でない限りは、
margin,padding→margin-bottom（topその他含む）
だとか、font,background辺りも個別に指定してる。

borderとかpaddingの「上右下左」を一瞬で判断出来るお方は、
個人的には尊敬してしまうのだけれど。

>>648
最後の2行は取り消し。validatorに弾かれたからだね。

>>647
Mac環境が存在しないので、iCab辺りは良く知らないんだけど、
それはIE3固有のバグっぽい。

654 ：644=647=648：02/03/26 02:36 ID:NKRWo2Xa

>>653
> borderとかpaddingの「上右下左」
それだけは値が何個の場合でも、「時計回り、上下別あり（3個）」
という覚え方でたちどころに覚えました。

オフトピに粘着レスｽﾏｿ

655 ：サ骨 ◆/IQ5000w ：02/03/26 04:28 ID:1x5hVuBp

> borderとかpaddingの「上右下左」
１コ、または４コ指定しかしないので、俺は混乱しないよ
覚え方は>>654のとおり時計回り。

656 ：Name_Not_Found：02/03/26 04:43 ID:iuCTae8j

2個指定もけっこう使う

657 ：Name_Not_Found：02/03/26 06:18 ID:MXuZX//m

>>652
IE3対策で、background を使用していました。
今では、@importで IE3対策してます。

658 ：Name_Not_Found：02/03/26 07:50 ID:0ZvpQKRO

> borderとかpaddingの「上右下左」
　俺は１～４こ指定全て使う。別に迷わない。単に慣れの問題かと。

　ちなみに、右と左が意味があって同じ場合は、２個又は３個指定をするが、たまたま一緒の場合は（右と左が同じ値でも）４個書く、という俺ルールがある（上下の場合も同じ）。

659 ：Name_Not_Found：02/03/26 08:10 ID:uJRXwUDy

(´-`).｡ｏＯ（この人こんなんで商売やってのか？）

660 ：Name_Not_Found：02/03/26 08:21 ID:R0RhF/kT

>>659
やってのか？
？？
誰の何のことを言ってるんだ。はっきり書けや。

661 ：：02/03/26 12:52 ID:KAj3gZHj

>>653
覚えることは、「時計回り」＆「指定しなかった場合、その反対側と同じになる」
ということだけ。(1つの場合は全て同じ)
難しくないでしょ？

662 ：641というか653：02/03/26 18:21 ID:wMaBd8Zq

>>645-661
いや、全てその通りで、アタマには入ってる。

ただ、慣れてないだけなんだろうけど、
絶対に直感的には判断出来ないので、
判断に掛かってしまうコンマ数秒がウザいというか、面倒というか、そんな感じ。

分かり易く具体的な例を挙げると、
border-left:1px #aaa solid　は
それぞれ値（というか単位）が全くバラバラだから一瞬で判断出来るけど、
margin:1% 2% 3% 4%　は
値（というか単位）が同じだからやっぱり多少考えてしまう。

これなら、少々文字数が増えようがmargin-leftとか個別にやった方が、
ストレスが少ないと、あくまで個人的な話ではあるけれど、そう思う。

じゃあなんで、
>>653で述べたfontとかbackgroundを個別に指定したがるのかと
突っ込まれても、それはそれで全くの【謎】としか言いようが無いんだけど。

663 ：Name_Not_Found：02/03/26 18:37 ID:c0RmdSGZ

一段落ついたっぽいので質問させて下さい。

日本語の略語も abbr要素とかでマークアップすべきでしょうか？
昨日、<abbr title="ドリームキャスト">ドリキャス</abbr>というのを見たので気になりました。

664 ：Name_Not_Found：02/03/26 18:52 ID:OXVBRHKK

スラングをマークアップすべきかどうか、だな。

"TGIF: Thank God, It's Friday"なんかはよく使われるけど、
USのStrict信者はどうマークアップしてるんだろ？

敢えて説明をしたい場合にだけやったら？
のべつまくなしにabbrがあるとかえってウザイし（特に音声ブラウザ）。

665 ：Name_Not_Found：02/03/26 19:04 ID:NS36c+MP

>>663
英語か日本語か、というのは無関係。
余り一般的でない略語を使う場合には、正式名称も書くのが慣例では。

666 ：Name_Not_Found：02/03/26 19:06 ID:NS36c+MP

>>664
title を読み上げる UA があるの? 詳細きぼん。

667 ：Name_Not_Found：02/03/26 19:16 ID:6pyq3SGF

>>665
＞英語か日本語か、というのは無関係。
　俺もそう思う。

　ただ、思いはするものの、日本語の場合、具体的にどちらを使えば良いのか、例えばドラクエ（ドラゴンクエスト）や、国連（国際連合）は acronym と abbr のどちらを使えば良いのか、と他人に聞かれると感覚的な話になってしまい、理論的に人に説明できない。
　strict-html では無くて国語の話になってしまうかも知れませんが、誰か教えてください。

668 ：Name_Not_Found：02/03/26 19:25 ID:7vBjfspa

>>667
>>205-236

669 ：Name_Not_Found：02/03/26 19:29 ID:wMaBd8Zq

>>667
というか、Strict的には acronymとabbr は同じモノだとみなされている。
W3C的にはabbrだけでOKで、MS様が勝手にacronym要素を作ったので、
止む無くHTML4.0に採用したらしい。
略語とか頭字語とか、あとの話は全てコジツケ。

．．．という話が、このスレの上の方にあったような。

670 ：669というか662：02/03/26 19:31 ID:wMaBd8Zq

被ってしまった。
しかも、>>668の方が親切っぽい。

671 ：Name_Not_Found：02/03/26 21:33 ID:trFKlHes

iモードとやらのサイトを作ろうと思ったんですが、調べたらW3Cが勧告してるCompact HTMLってのがあるんですね。
これってどうなんでしょう？現行のiモード機種でエラーなしで表示できるのでしょうか？
なんかDOCOMOが突っ走って（DOCOMOというより機種メーカか？）実装を変えているような気がするのですが。(;´Д`)
XHTML1.1 Basicとかは…どうなんでしょう。そこらへんモバイル向けの情報ありません？

672 ：663：02/03/26 21:35 ID:UPjXP/9H

ありがとう。書いた方がいいんだね。
英語にしか書いてなかったよ。

# よく考えたら確かに略語に言語なんて関係無いよね

673 ：663：02/03/26 21:38 ID:UPjXP/9H

>>671
神埼たんの
http://kanzaki.com/docs/html/xbasic.html
に、
http://www.zdnet.co.jp/mobile/news/0108/02/wap2.html
へのリンクがあったけど役立つかどうか。

674 ：Name_Not_Found：02/03/26 22:00 ID:NS36c+MP

>>671
Compact HTML は勧告じゃなくノート。
HTML 4.0 のサブセット扱いなので、
iモードでも問題なく表示できるとは思うが、
お薦めはできない(勧告じゃないから)

Compact HTML の理念を継承したのが XHTML Basic なので、
使うならそっちか WAP 2.0 辺りがよいような。
でも、XHTML は古い機種では XML 宣言が表示されたりするらしい。

つーか、はっきり言って HTML 4.01 や XHTML 1.1 の方が
問題が少ないので、敢えて C-HTML や XHTML Basic で作る必要はないよ。

675 ：Name_Not_Found：02/03/27 01:21 ID:XutsvNG4

>>674
iMODEに関しては、
古くなくてもXML宣言は表示される（少なくとも503iシリーズは）。
でも、XHTML的記述（<br />とか）は問題無し。

と、結構ここまでは共通認識としてあると思うんだけど、
FOMAはどうなんだろう？
あと、なぜかEZ-webに関しても、共通認識とは言い難いような。

FOMAに関しては、
>>673のzdnetの記事には、対応してると書いてあるっぽいんだけどなぁ。

676 ：667：02/03/27 01:28 ID:3uB+70jg

>668-670
　サンクス。＆　過去ログちゃんと読まずに質問してスマソ。

677 ：Name_Not_Found：02/03/27 06:58 ID:YdFLs1QX

>ばけらとは、「HTMLマニア」という意味である。
この一文が沢山の文章の中にあった場合。
ばけらとは、「<dfn>HTMLマニア</dfn>」という意味である。
ですか？　dl,dt,ddは文章の中には使えませんか？

678 ：677：02/03/27 07:16 ID:YdFLs1QX

あと、
「<dfn>HTMLマニア</dfn>」か、
<dfn>「HTMLマニア」</dfn>
のどちらなのでしょうか？　前者だと思うのですが。

679 ：Name_Not_Found：02/03/27 07:34 ID:MI4XI07Z

>677-678
文中に定義がある場合は、dfnを用いるべきだと思います。
定義がp要素内であれば必然的にdfnなんですけど…。

ところで、dfn要素は「定義される語」（定義リストにおけるdt要素）
を意味するはずだった気がします。そうすると、
『ばけら』の方がdfnでマークアップされるべきでは？

680 ：Name_Not_Found：02/03/27 08:08 ID:LRUCMwZA

>「<dfn>HTMLマニア</dfn>」か、<dfn>「HTMLマニア」</dfn>
　｢｣は、この場合定義語を強調するの為に存在するのでは？

　>>679 の言う通り、この場合「ばけら」方が dfn で　markup されるべき言葉なので

<dfn>ばけら</dfn>とは、<em>HTMLマニア</em>という意味である。

となるかと。

＃ちなみに、本来の質問の dfn を em（かっこ）がかぶる場合に関しては、
　俺は、定義語そのものを強調したい場合、<em><dfn>ばけら</dfn></em> としているし、定義語の一部を強調したい場合、<dfn><em>ば</em>けら</dfn> としている。

681 ：677：02/03/27 08:21 ID:YdFLs1QX

>>679
>>680
ありがとうございます。
おっしゃるように、dfnは定義語に付けるようです。
>>680
定義語の解説は、emで強調しないといけないのですか？

682 ：680：02/03/27 08:28 ID:LRUCMwZA

>定義語の解説は、emで強調しないといけないのですか？
　いや、んなこたないです。>>677 の例に沿って強調しただけ。

　強調が必要と感じられた場合に、通常の文章と同様に、em、strong を使って下さい。

683 ：677：02/03/27 08:42 ID:YdFLs1QX

>>679
>>680
ありがとうございます。
解決しました。

もう一つ質問をしても良いですか？
<div>
<p>なんとかかんとか、あいうえおか。<q><dfn>ばけら</dfn>とは、「<em>HTMLマニア</em>」という意味である。<cite>ばけらまにあ</cite></q>ああああああああああ</p>
</div>

引用の参照、参考本の<cite></cite>は、<q></q>の中か
外のどちらが良いですか？　どちらもパーサーでチェックすると
違反は出ませんでした。

684 ：Name_Not_Found：02/03/27 09:37 ID:t3M2+YAd

>>683
模範解答は無かった様な。

中に入れれば、それが引用先に記述されていたもの
であるような誤解を招くかも知れないし、
外に置けばその関連性がDOM的に明示出来ない。

俺は外に置いて関連性は文脈で判断してもらう事にしている。
HTML4 Spec.は外に置いた例を出していたしね。

685 ：茶文字 ◆xELvisFU ：02/03/27 10:12 ID:Urm/xg45

ふと思ったのだけど、このスレには厨な質問も回答も少ないね。
素直に勉強する気になれる、今時珍しい良スレだ（ｗ

686 ：Name_Not_Found：02/03/27 10:40 ID:dxAULNcL

ここではまともだけど他所のスレで厨してるﾔｼもいるんじゃないかな

687 ：Name_Not_Found：02/03/27 10:40 ID:SGbp1NcL

>>685
それだけStrictが敷居高いってことだろ。
良スレなのはいいことだが、敷居が高いのは歓迎すべきことじゃないなあ。
みんなが普通にStrictに書けるようになる時代が来ればいいな(妄

688 ：Name_Not_Found：02/03/27 10:57 ID:6rbmZeb5

>>687
何も考えていなくても使える上に簡単にデザインができ(もちろんCSS),
Strictなオーサリングツールが低価格で発売されて普及しない限り無理だろ。

689 ：茶文字 ◆xELvisFU ：02/03/27 11:02 ID:Urm/xg45

>>687
敷居は確かに高いな。

しかし実際のところ「よくわかんないからTransitionalでいいや」っぽいユーザが多いのはどもならんのか。
このスレに厨が寄りつかないのは敷居が高いんじゃなくて興味がないだけのような気がしてきたyo；

690 ：Name_Not_Found：02/03/27 11:28 ID:J6ZD65Dy

このスレでの議論までいくと敷居が高いのでROMしている者ですが、
仕様書に従う(この言い方はちょっと語弊がありますか？)こと自体は
知っていれば楽になることの方が多い気がします。
デザイン先行のオーサリングツールが出回るのは仕方のないことですが
知識としてだけでも、もっとStrictが理解される方法があればいいですね。

691 ：Name_Not_Found：02/03/27 13:02 ID:XCRzV33I

むしろ、文書型という概念の敷居の高さではないかと。
Transitional だって、正しく書くことの難易度は Strict と大差ない。

ほとんどのユーザは SGML 文書を作成しているという意識がない。
「よくわかんないからTransitional」の場合、
Transitional も理解できてない可能性が高い。
論理構造を記述すること自体はそう難しいことではないし、
装飾に用いる CSS の難しさはまた別件だと思うし。

692 ：Name_Not_Found：02/03/27 13:44 ID:SGbp1NcL

そもそも
「ホームページ」を作るときに論理構造を考える
ということが高い敷居になっているんだろうか。

693 ：Name_Not_Found：02/03/27 16:25 ID:guOVxTt8

見出しとか段落とか
意識して書いてる人がそもそも少ない。

694 ：520：02/03/27 16:47 ID:sVOguuCS

敷居が高い、とか、興味がないという以前に、W3CとかHTMLの仕様とか、
全然知らないで書いてる人の方が圧倒的多数では。
オーサリングツールを使わずにテキストエディタで書いてるという人も、
別に正しいHTMLを書くためではなくて、もっと個人的な嗜好でそうしてる
人が多そうな気がする。

695 ：茶文字 ◆xELvisFU ：02/03/27 16:50 ID:Urm/xg45

技術的というか仕様的な部分での敷居の高さとは別の問題なんだけど
(これはこれできちんと議論続行したい)
いわゆる信者の論調が初心者を遠ざけているジレンマを強く感じている。

正しいことを主張することは大事だが、主張だけすればいいわけじゃない。
相手が多数であれ少数であれ、理解してもらいたいと思うなら
理解してもらいやすい形で主張を掲げるべきだと思うのね。

極端な例でｽﾏｿが、かつての学生運動のようなスタイルではどれだけ論理的で高潔な政治思想でも
今の日本人が受け容れるとは思いにくいわけ。
そんなものは今日び流行んねぇんだよ、と。
「正しさ」と「流行」は本来無関係だが、無関係だけに矛盾もしない。

Strictに状況を置き換えるならば、方法論はふたつある。
ひとつは、Strictを徹底しつつ「とほほ」に比肩するわかりやすさを持つサイトを作ること。
これは以前私が主張したことを再掲しているに過ぎない。

もうひとつは、Strictを徹底した流行追随型サイトをつくること。
Strict派のサイトはしぶめのものが多いが、あえていわゆるギャル系などに魂を売る（ｗ
デザイン面でかなり奮闘しているサイトは増えてきてると思うんだけどね。
あるいはこのスレにも出てきた記憶があるが、Strictなエロサイト（ｗ

ま、マークアップがStrictでも原色バリバリのコントラスト全開なサイトが、
WAI的にどうなのかという話もありますが（ｗ
でも実際、そのあたりの「たくましい人たち」を取り込まないと、単純に多勢に無勢な状況は
変わらないと思うんだな。

696 ：Name_Not_Found：02/03/27 17:00 ID:XCRzV33I

３つめの方法論としては、広告塔。
キムタクとかイチローが「Strict っていいよね」って呟けば
それだけで信者の布教活動の100倍以上の効果が(w

697 ：Name_Not_Found：02/03/27 17:04 ID:XutsvNG4

>極端な例でｽﾏｿが、かつての学生運動のようなスタイルではどれだけ論理的で高潔な政治思想でも
>今の日本人が受け容れるとは思いにくいわけ。
>そんなものは今日び流行んねぇんだよ、と。
>「正しさ」と「流行」は本来無関係だが、無関係だけに矛盾もしない。

某こみゅーんが、そこら中で無駄な争いしてる現状だしなぁ。

698 ：サ骨 ◆/IQ5000w ：02/03/27 17:08 ID:3N7ydXub

2つ目と3つ目で頑張るぜ(w

699 ：Name_Not_Found：02/03/27 17:09 ID:t3M2+YAd

>Strict派のサイトはしぶめのものが多い
見た目はしぶめなのに中身はアレゲなモノが多数。

論理構造は一応伝わるだろうが、普通に見れば
「四角いホムペ」が多すぎる。
画像を使わなくって済むからって
ボーダーに頼り過ぎの感が。
（個人的に「ボーダーいじり系」と呼んでる）

700 ：Name_Not_Found：02/03/27 17:15 ID:lWBUtgLP

>>691
> むしろ、文書型という概念の敷居の高さではないかと。
> Transitional だって、正しく書くことの難易度は Strict と大差ない。

同意。漏れも Transiotional で書いてた時期ってないもん。
移行は直接「無印 → Strict」だったよ。

>>697
うん、耳痛い。

でも、技術的な裏付けもなしに HTML 解説してるような馬鹿見たら、
解ってる人間が腹立てるのも当然なんだよね…。

それでもぐっとこらえて大人の態度でいなきゃ駄目なんだけどさ。
そこまで人間できてないよ…。

701 ：Name_Not_Found：02/03/27 17:32 ID:YTsS+lqZ

Strictなギャルサイトを作ろうとして挫折した厨ならここにいます・・・

702 ：Name_Not_Found：02/03/27 17:46 ID:DJYDWEAe

>>695

胴囲。

97年か98年頃から「ちゃんとしたHTML&CSSなサイト」やってますが、当時は
あまり流行ってなかった。流行るとも思えなかった。
また>>699氏の言うようなのばっかだった。俺のとこもそうだった(w
それがCSS切り替えスクリプトをきっかけにかなり増えてきたし、レベルも向上した。

はじめはそういう「カタチから入る」でもいいんですよ。
それをきっかけに「CSSなどを効率よく活用するには、Strict系HTMLがいい」
というのに後からでも気づいてくれれば。

703 ：520：02/03/27 17:56 ID:sVOguuCS

>>696
そういうもんでもないような気が。
というのは、strictへの移行って、理解してないままスパッとできるような
もんじゃないでしょ？
たとえば、自分のサイトもってる有名人（中田みたいな）が、
「セキュリティホールの多いIEなんて使うのやめて、ネスケ使おうぜ！」
って言って、自分のサイトからネスケをダウンロードできるようにしたら、
ネスケの普及率はぐっと上がると思うけど、同じような感じで、
「不思議マークアップやめて、strictにしようぜ！」
って言われても、流行を折ってるだけの人は、まず何をしていいか、
わかんないだろうから、「なんか難しいこといってるなー」で、
終わっちゃうと思う。

ただ、695のいってるような、strict+cssの利点をふんだんに使った
派手なサイトを有名人がやったら、同じことを無名な人間がやるよりは
効果高いとは思う。

704 ：Name_Not_Found：02/03/27 19:03 ID:5Wu0EiwJ

HTMLに Strict、Transitional、Frameset の３つの宣言がある事を知り、
かつ Strict は厳格なHTMLだと知ると、
それだけで敷居が高く感じられるのでは。

オイラもそうだった。
それで、Transitional から始めて文書構造を
勉強していってから Strict へ移行した。

705 ：Name_Not_Found：02/03/27 19:11 ID:EA61YFxv

>>695
Strictを徹底しつつわかりやすい解説サイトを作るということに関してですが、
それをこのStrictスレの参加者ですることは不可能でしょうか？

というのは、Linux板には「2ch Linuxビギナーズ」
（http://member.nifty.ne.jp/exreal/linux/）
というのがあって、役立ちそうな発言がいくつかピックアップされている。
こういうのを、ここweb制作管理でも作れないかと前々から思ってたんです。

難しいことはいろいろあるでしょうが、
Strictスレによる解説だけでなく、
web制作管理にまつわるいろいろを、
有意的な情報にまとめることは、
有意義だと思います。

言いっ放しだと無責任なので、
もしそれを実行するとなれば、
自分もその一端は担う覚悟であることだけ
申しておきます。

> 論理的で高潔な政治思想
これは、
> 美しく怜悧な
のがよいと思った。

706 ：茶文字 ◆xELvisFU ：02/03/27 21:36 ID:Urm/xg45

>>705のような人を待っていたというかおそれていたというか（ｗ
賛同者がいるなら提供できるリソースは惜しみません。
垢も出せるしあぷろだも用意できます。

問題はどうやってコンテンツの見通しの良さを確保するか、でしょうね。
うまい方法がないか考えてみます。

# ちょっと私も走りすぎの感があるんで、ここんとこ話題が偏っちゃったかな。ｽﾏｿ＞ALL

707 ：Name_Not_Found：02/03/27 21:44 ID:x8VVx/tX

>>706
気にしないで論議を続けてくだされ。元々、このスレって一つの事について
皆で徹底して意見を出し合う的な流れがあるからね。

708 ：Name_Not_Found：02/03/28 09:22 ID:l4plnr6o

出版社の意識もいいかげん変わって欲しいな。
「blockquoteはブロック化インデントのためのタグ」説がまかり通ってるんだが、
こういうアホに本なんか書かせないで欲しい。

709 ：Name_Not_Found：02/03/28 10:47 ID:rtRFAKpf

w3c公認ウェブデザイナー検定試験みたいのがあれば。

710 ：_：02/03/28 11:49 ID:MAKadF7A

段落とかもきちんと分かってなかったことに気がついた。

711 ：Name_Not_Found：02/03/28 13:11 ID:ZgZp3b/h

>705-706
>Strictを徹底しつつわかりやすい解説サイトを作る

もし実現したら、すばらしいですね。
そういったサイトを作るとしたら、まず導入はどこからでしょう？
いきなり文書型がどうのW3Cがどうのと始めると拒否反応がでそう。
やはりCSSデザインの魅力を知ってもらうあたりから入るのが無難なのかな？

712 ：711：02/03/28 13:21 ID:ZgZp3b/h

あるいは、トラブル解決的なところから入るのが良いかも。
文字化けするのはなぜ？とか、ちゃんと表示されないのはどうして？といったところが入り口。
でもそれだと、初心者向けサイトと言うより脱初心者サイト、になってしまうか。

713 ：Name_Not_Found：02/03/28 13:26 ID:ZGUDDUgU

>>711
>>299-312

714 ：Name_Not_Found：02/03/28 13:56 ID:FhjK1tRI

Strict ではなく CSS の敷居が高いのではないかと思った。
Strict は Transitional より要素も属性も少なく、覚えるだけなら難しくないはずだ。
文書を装飾するために、全く別な言語 CSS を改めて覚えなければならない。
この一点が、初心者を遠ざけて HTML の知識で装飾を行える Transitional に向かわせるのでは。

解りやすい Strict 解説サイトは、解りやすい CSS 解説も用意しないと
受け入れられるのは難しいだろうと思った。

715 ：この文章は失敗しますた：02/03/28 15:00 ID:bSGDjMPi

言語の解説サイトみたいなのは、初心者向けならつらい
ＧＵＩで操作可能なツールを紹介しつつ、そのツールでＣＳＳの作成可能であって
もろもろの便利な利点を紹介しつつ、話を進めていけば

結局、初心者が作るＨＴＭＬは、おそらくすべて「ホームページ作成ツール」で
作成されていて、ソースなんか全く意識する事はなく、ホームページ＝ワープロ文書
ぐらいの感覚でしょうから

716 ：サ骨 ◆/IQ5000w ：02/03/28 15:10 ID:rtRFAKpf

>>714
同意。

717 ：サ骨 ◆/IQ5000w ：02/03/28 15:12 ID:rtRFAKpf

テーブルレイアウト/飾り枠の解説くらいに気合の入ったの
できませんかねぇ…

718 ：Name_Not_Found：02/03/28 15:16 ID:ZGUDDUgU

>>714
いや、むしろCSSではなく、他人の環境への配慮とか
スクローラブルメディアという概念の敷居が高いのかも。

だから、初心者(に限ったことではないが)は、
固定サイズのレイアウトをして、横スクロールバーを出したりたっぷり余白をつくったりして
平気な顔でいられるのでは。

719 ：Name_Not_Found：02/03/28 15:23 ID:ZGUDDUgU

でも、結局のところCSSの解説をきちんとやるにあたって
一番厄介なのは「各UAのバグ」なんだよな。

ここを「UAが悪いので気にするな」とか、
「各UAのバグに気をつけてあのプロパティは使わないようにしましょう」とか
やっちゃうと、素人にはお勧めできなくなっちゃう。

720 ：Name_Not_Found：02/03/28 16:29 ID:8i43/YOV

>>719
そう。
俺もStrict的なの作っててCSSでデザインはしてるけど、
未だにブラウザの解釈の違いに悩まされる。
と言うかわからないところだらけ。

正しいHTMLを書いてデザインはすべてCSSでやれと言うなら、
UAごとの違いについてもちゃんとした説明が必要だと思う。
例えばMacIEではどうこうだからwidth指定はちゃんとしとけ、とか。
そうじゃないとCSSでやるとこが自分にとってマイナスにしかならないと感じるのでは？
大変な思いまでしてやろうと思う人がはたして何人いるだろうか…。

721 ：Name_Not_Found：02/03/28 17:11 ID:4NDj2QJt

>>720
でも、いきなり float とか position なんて要るかなぁ。
こちらもイチから作る訳で、
やはり最初は少なくても仕方が無いと思うんだけど。

総論というか、全体的な方針としては
「CSS の解説を充実させる」ってことで、、
最終的にはそういうことも盛り込むべきだけれど、
あくまで本質は HTML な訳だし。

722 ：Name_Not_Found：02/03/28 18:11 ID:ZGUDDUgU

>>721
＞あくまで本質は HTML な訳だし。
禿同。

で、なんでスタイルは後回しなのか？と聞かれたら、

執筆(+編集)とレイアウトは別作業だよな。
別作業だからファイルを分けると楽なんだよ。
という説明なら初心者を誘導しやすいかな？

執筆：元の文章書き
編集：タグつけ
レイアウト：スタイルシート弄り
こんな感じで。JavaScriptの外部スクリプトはどう誘導しようか？ｗ

723 ：茶文字 ◆xELvisFU ：02/03/28 20:01 ID:zWJLcscY

CSSをどういうタイミングでどう出すか、ってのはかなり大事かも。
あまりもったいぶってあとから出しちゃうと逆効果だから、
html head title body p a img くらいまで学んだ時点で簡単なCSSを導入かな？
要素数が少ない段階で基本的なCSSの書式を知っておけば、応用が利きやすいと思うし。

文書型宣言は最初から「おまじない」として固定しちゃえばいいと思う。
Strictが前提だから、何種類も掲げる必要はないわけで。
metaのhttp-equiv属性なんかも「おまじない」にしてしまうべきなのか？

724 ：520：02/03/28 20:22 ID:buE05SFB

headやbodyなどの基本的な構造は「おまじない」にしない方がいいと
思うけど、文書型宣言やmetaのhttp-equiv属性などはとりあえず
「おまじない」でいいと思う。
解説をつけるとしても、書くのも読ますのも後回しで。
なんだったら、「くわしく勉強したい方は……」って感じで、他の解説
サイトの該当するページにリンク貼るだけでもよいのでは？

725 ：Name_Not_Found：02/03/28 20:28 ID:nQ4gJeXT

>>714
＞Strict は Transitional より要素も属性も少なく、覚えるだけなら難しくないはずだ。

確かに覚えるだけなら楽だろうが、
適切にマークアップ出来るかが問題。
例えばパンくずリスト。
以前に ol 要素か？という話し合いがあったような気がするが、
オイラはリストでは無いと思うし、 p 要素を使う。

>>722
＞執筆(+編集)とレイアウトは別作業だよな。
＞別作業だからファイルを分けると楽なんだよ。

それよりも、サイトで何を発信したいのかを考えさせるべきとも思う。
この場合、あなたはレイアウトを見せたいの？って感じかな。

>>723
＞html head title body p a img くらいまで学んだ時点で

hn 要素も(　ﾟдﾟ)ﾎｽｨ…

おまじないってのはいいね。
でも、最後の方のステップではちゃんと教えた方がいいと思う。

726 ：Name_Not_Found：02/03/28 21:00 ID:pmy9LOSc

>>725
俺はパンくずリストは段落じゃ無いと思うからdiv。
そう言う意見が割れるようなものは取り敢えず伏せておけば？

727 ：茶文字 ◆xELvisFU ：02/03/28 21:22 ID:zWJLcscY

>>726
伏せるというか、文脈がはっきりしていればマークアップは本来自然と成立するものだけど、
必ずしも一意に定まると限った話でもないと思うのね。

「Level1: Home ＞ Level2: Profile ＞ Level3: Hobby」
こういう認識でパンくずリストがあるならolだろうし、
「このコンテンツは [２ちゃんねる] の [Web制作板] に含まれる [Strict-HTMLスレッド] です」
と書いても同じ役割のものを置けるわけで、これだとpが妥当だろう。
# ちと強引ではあるが（ｗ

「○○の場合は××でなければならない」を強調しすぎると、やはり敷居が高いかなとも思う。
「マークアップに迷いが生じることはある、それでもかまわないからそのときどきで
『たぶん最適』なものを選べばいいのであって、間違ってたらあとから直せばいい」
というスタンスではいかんのだろうか。

いきなりvalidなソースを書けるようになるなんて期待してはいけない。
ただ、近いものはわりと簡単に書けるんだという感想を持ってもらいたい。
で、そこから「よりStrictなもの」を書こうとする意欲が出発すると思う。

>>725
hnを書き忘れてました。確かにﾎｽｨ。

728 ：Name_Not_Found：02/03/28 21:41 ID:Mpu+lN1G

　最初に HTML をやると、どうしても「レイアウト指定言語」だと思い込む人が居るので
（栄えと内容の分離概念が全く存在しない人がいて、HTML はレイアウト指定言語で、CSS はレイアウト拡張規格と勘違いする）
　最初に well-formed XML document で markup の基本ルールを教えて、直後に html head title body p hn + CSS を一気に畳み掛けるように教える、と言う方式を提案。

　あと、img 要素は最初に覚えると（特に width, height 属性のせいで）HTML は見栄えを制御しない点に関して理解を妨げる気がするので、CSS の後にする事も強く提案。

729 ：Name_Not_Found：02/03/28 21:47 ID:0KkRThYX

HTMLの要素の用例だけは充実させてほしいなぁ。
とほほさんの所に足りないものの代表格。

730 ：Name_Not_Found：02/03/28 22:17 ID:lqWezLp5

あと、まったく知らない人向けと、不思議まくあぷをかじった人向けで
切り口は違うような。

後者対策の方がむしろやっかいだと思う。

何か新鮮な体験を与えて、目から鱗を落としてからじゃないと話を進められない気が。
目に鱗を残したまま話をするとアレルギーを生むだけだと思われ。

731 ：Name_Not_Found：02/03/28 22:20 ID:bSGDjMPi

部分的にこうしたい！って欲求があるわけだが
たとえば、文章中の一部分を文字をでかくしたいとか、そういうのは
結構CSSだと面倒ですね。面倒というのもあるけど、そもそも難しいというのもあるかもしれない
もちろん、こつなどを理解すれば簡単なわけだけど

732 ：Name_Not_Found：02/03/28 22:22 ID:bSGDjMPi

その場合、「こっちの方が簡単じゃん」という疑問がわくわけだが
相殺できるぐらいの理由がないと、難しいな

733 ：Name_Not_Found：02/03/28 22:32 ID:Mpu+lN1G

>その場合、「こっちの方が簡単じゃん」という疑問がわくわけだが
>相殺できるぐらいの理由がないと、難しいな
　やっぱ CSS 切り替え機能か？
　一つの HTML に一つの CSS なら font tag で文字に色付けても何とかなるが、
複数の CSS だとそうはいかない、と言う点を強調するのはどうだろうか。

734 ：Name_Not_Found：02/03/28 22:33 ID:7TzUEmTt

説明にはブラウザ毎の画面付説明があったら嬉しいなぁ
IE5.x IE6 NN4.x N6 Mozilla Opera MacIE Cab Lynxとか
とてつもない手間だけど
ブラウザなんか意識するなと言われればそれまでだけど

735 ：Name_Not_Found：02/03/28 22:37 ID:4NDj2QJt

>>730
私としては、そうは思わないかも。
とにかく、最初に文章が存在するというのは大きいと思う。

というのは、Strictとはまでは行かなくても、
普通に構造化したマークアップさえしてもらえれば、
CSSのテンプレートを被せるだけで
見栄えが自由自在に変わる。

これだけで、CSSの良さは解るんじゃないかと。
そうすりゃ、不思議マークアップも自然と消えるような。

やはり、文章が無いのは、如何ともし難い。

736 ：520：02/03/28 22:41 ID:QEhaslZQ

やはり、まったくの初心者と不思議マークアップをかじった人とでは、
解説は別にした方がよさそうな気がする（導入の部分だけでも）。
たとえば、CSS切換機能についても、まったくの初心者に教えると、
かえって混乱したり面食らったりしないか心配。

737 ：Name_Not_Found：02/03/28 22:42 ID:2P8wRkYq

>>735
ただ現状の「ホームページ」は文章が存在していない気がする。
寧ろ、言葉を切り貼りしている感じ。

738 ：733：02/03/28 22:51 ID:Mpu+lN1G

>たとえば、CSS切換機能についても、まったくの初心者に教えると、
>かえって混乱したり面食らったりしないか心配。
　確かに。

で、 >>734 の意見に付加する形で再提案。
　幾つかのユーザースタイルシートを用意しておいてスタイルシートごとの画面を紹介すると言うのはどうか。その中に各 browser のデフォルトスタイルシートも混ぜる、と言う方向で。

　初心者利用率が圧倒的に多いと思われる win の internet explorer 向けなら、ユーザースタイルシートの適用法は結構簡単に教えられるし。

739 ：Name_Not_Found：02/03/28 23:23 ID:KU97pu5C

> たとえば、文章中の一部分を文字をでかくしたいとか、そういうのは
> 結構CSSだと面倒ですね。面倒というのもあるけど、そもそも難しい
> というのもあるかもしれない
・強調するという意味で拡大したいなら
strong要素(名前空間:http://www.w3.org/TR/xhtml)にCSSを適用すればよい。
・最新情報であるという意味で拡大したいなら
ins要素(名前空間:http://www.w3.org/TR/xhtml)にCSSを適用すればよい。
・ただなんとなく拡大したければ
font-face要素(名前空間:http://www.w3.org/2000/svg)を使用すればよい。(ie6未対応(泣)
(非推奨)font要素(名前空間:http://www.w3.org/TR/xhtml)を使用すればよい

740 ：Name_Not_Found：02/03/28 23:25 ID:KU97pu5C

名前空間http://www.w3.org/TR/xhtmlとあるのは
http://www.w3.org/1999/xhtmlの間違い

741 ：Name_Not_Found：02/03/28 23:40 ID:nQ4gJeXT

なんとなく拡大するなら big 要素でいいかと・・・。
ダメですか？そうですか・・・。

742 ：Name_Not_Found：02/03/28 23:42 ID:A7ek0RoS

>738
「作れスレ」でやってる掲示板のCSSはサンプルにならないか？
http://pc.2ch.net/test/read.cgi/hp/991906104/l50 スレッド
http://www32.tok2.com/home/css/clip/joyful.cgi 掲示板（つーかアプローダだけど）

もちろん、このサイトを教えちゃダメだけど、
ここのお題と、適当にいくつかのシートをピックアップして
例示してやればいい。

743 ：Name_Not_Found：02/03/28 23:57 ID:2JGWIukP

なにやら、DOS/V POWER REPORTという雑誌で6月号あたりにStrictな掲示板スクリプトの特集をやるらしい
（Strictなのだけじゃないだろうが…）
（しかも特集といっても2～3行の予定らしい）

744 ：Name_Not_Found：02/03/29 00:38 ID:k0c5KsqD

2～3行？

745 ：Name_Not_Found：02/03/29 01:43 ID:i+EwGdr2

特集なのか？（ｗ

746 ：Name_Not_Found：02/03/29 13:18 ID:IX7rlMan

どんなに「ホームページ」をなんか勘違いしてても
各コンテンツにはそれなりに文章があるものだと思うのだが。
文章にならなくてどうしようもないのって
ナビゲーションが関わる部分じゃないだろうか。

たとえばパンくずリストは、文章の時点では存在しない。
マークアップして、サイトの一コンテンツに加えた時点で、初めて必要になる。
初心者が気合を入れると思われる、サイトのトップページも同じ。
各コンテンツにとって、トップページは必要ない。
多くの場合、トップページに期待されるのはナビゲーション機能でしかない。

ナビゲーションは文章とは本来別のものだけど、他に現実的な手段がないから
HTML で無理矢理表現して埋め込まなきゃならない。
だから、不自然だったり、適切な要素がなかったり、人によって見解が分かれたりする。

解説の最後の最後でいいと思うけど、
HTML の限界というか、HTML に仕様外の機能が要求されている現状があって
*仕方なく* 適切とも思えない記述を選ばざるを得ない場合があることにも
触れてもいいんじゃないかな。
結果としてテーブルレイアウトに逝ってしまったとしても
本当は不適切だということさえ伝わっていれば、後は個人の価値観だと思うんだ。

747 ：Name_Not_Found：02/03/29 14:44 ID:MVRIyJoV

“Netscapeの復活”でWeb開発者は夜も眠れない？
http://www.zdnet.co.jp/news/0203/28/e_aol.html

色んなブラウザが出回れば
「あのブラウザだと表示が崩れる！どうしよう？」
「StrictなHTMLはブラウザに依存しません！」
みたいな流れに…ならんかな。

748 ：Name_Not_Found：02/03/29 14:58 ID:H69R+yb2

>>747
ならないだろうなあ。
「StrictなHTMLは表示が崩れません」じゃないから。

749 ：Name_Not_Found：02/03/29 15:08 ID:IX7rlMan

「どのブラウザでも同じ見ばえ＝(・∀・)ｲｲ!」
この流れに乗ってる限りダメだろう...(ｳﾄｩ

750 ：Name_Not_Found：02/03/29 15:19 ID:gd9TSya4

まずは「見た目より中身」という考えを徹底させないと。

…………無理だろうなぁ。

751 ：Name_Not_Found：02/03/29 15:34 ID:IX7rlMan

閲覧者である時に「見た目よりも中身」って思ってないと難しいよね...
制作者じゃなくて閲覧者を教育しないとダメなのかも(禿欝

752 ：Name_Not_Found：02/03/29 15:37 ID:ogbw5CDw

侍魂とか、要は中身だって事のいい例だろう。

753 ：Name_Not_Found：02/03/29 15:39 ID:H69R+yb2

>>750-751
見た目は見た目、文章は文章だ。
サイトの主眼が見た目にあるサイトは、見た目こそが中身なのだ。

CSSで見た目を作ってブラウザ間で表示差が出ない(ブラウザバグがない)
状況が望まれるだけかも。

754 ：Name_Not_Found：02/03/29 15:42 ID:H69R+yb2

>>752
侍魂は見た目不可欠でしょ。
ただ、実現方法がああなってるだけで。

755 ：Name_Not_Found：02/03/29 15:47 ID:AkEtlzYS

侍魂のようなサイトは見た目が不可欠なのだから、
そもそも HTML で書こうというのが間違い。
Transitional/Strict 関係なく。

756 ：Name_Not_Found：02/03/29 15:55 ID:gd9TSya4

HTMLぐらい簡単で,さらに高度なレイアウトができるマークアップ言語を作れって事か。

………Curlは簡単じゃないな。

757 ：520：02/03/29 15:58 ID:0hr/3DSs

以前から思っていたことなんだけど、「やたらとデカい字を多用する」
「行間をたくさん空けて1行ずつ読ませる」というのを「侍魂風」というなら、
CSSを使っても再現できるのでは？
字をデカくするのは「強調」だろうから、emやstorongにfont-sizeを指定して
やればいいだろうし、行間空けるのも、br要素をたくさんぶちこむより、
p要素にheight : 100%;とか指定してやった方が、画面の縦幅の小さいノート
パソコンとかでも読みやすいだろうし。
問題は、CSSが無効な環境でも、きちんと「面白い」文章になってるかどうかだけど。

758 ：茶文字 ◆xELvisFU ：02/03/29 15:58 ID:Zbx5RUXa

つまりStrictな「侍魂を超えるサイト」をヲレたちで(以下略)

望みは高く果てしなく……一休さんのとんちで何とかなりませんかね、さよちゃん。

759 ：Name_Not_Found：02/03/29 16:15 ID:gd9TSya4

>>757
できなくは無いだろうけどかなり再利用性の低いものになると思われ。

760 ：Name_Not_Found：02/03/29 16:15 ID:IX7rlMan

>>757
でもなんていうか、いわゆる <em class="red"> とか
<strong class="level7"> とかになりそうな気がしないでもないでも。
あの場合、 br も 1 個と 10 個じゃ意味違うし、
同じ 10 個でも意味は同じじゃないだろうし。
CSS で再現できなくはないだろうけど、 valid なだけにしかできないと思う。

761 ：752：02/03/29 16:20 ID:ogbw5CDw

ん？俺が言ったのは、侍魂はそんなに見た目のデザインかっこつけてないけど、
それでも十分人を引きつけてるって事です。
プレインテキストでも十分いけるというか。
強調マークアップのことは別の問題として。
って、何か空気読めてなかったみたいでごめんなさい。

762 ：Name_Not_Found：02/03/29 16:21 ID:IXp11koR

CSSでイケてるデザインサイトスレにあった
ISO-HTMLで侍魂風のやつ。
http://wangando.com/text/iso-ijiri.shtml

作者も「こうでもしないと無理」とか言ってたからなぁ。

763 ：茶文字 ◆xELvisFU ：02/03/29 16:41 ID:x7KmZduY

見た目の好みもさまざまだし、インパクトを与える手法も一様ではないんだから、
侍魂のクローンを作ることにこだわらなくてもいいと思うなぁ。
確かに物理マークアップは巧いんだが（ｗ
ウケた理由は更新が高頻度だったり語彙が平易だったり、いろいろあるんだし。

我々がやろうとしているマークアップやデザインの手法は彼とは別のものなので、
違う形でインパクトが与えられればそれでもいいと思ほゆ。

ちなみに私は侍魂よりも「それだけは聞かんとってくれ」のファン。

# つか、独自路線でいいからウケるものを作って、侍魂なりろじぱらなりに
# リンクされるくらいになるのが王道か？（ｗ

764 ：Name_Not_Found：02/03/29 16:46 ID:H69R+yb2

まあ、一発ネタは再利用できないよな。

話ズレるけど、ネタ文書の一発ネタスタイルをStrict的にやるなら
「ここが笑いどころ」とか、「オチ」とかをclassで指定して、
ページごとに別のスタイルシートを当てるとかかな？

765 ：Name_Not_Found：02/03/29 16:52 ID:IX7rlMan

>>763
> 我々がやろうとしているマークアップやデザインの手法は彼とは別のものなので、
解説として、彼のような手法をとりたい方は他所へどうぞ、ということ？
まあそれしかいいようないだろうと思うけど。

766 ：Name_Not_Found：02/03/29 16:52 ID:Y6LdipER

あの無料サーバでStrictなページ作りって無謀ですか？
やっぱり広告が入るから無理ですかねぇ。ってか無理ですね。
せめて、こっち側で広告のタグ等を弄れれば…苦労しないんですけど。
はぁ、なんか対応策あります？広告消すっていうゲスな方法以外で？

767 ：Name_Not_Found：02/03/29 17:03 ID:hSAxxbm2

>>766
ない

768 ：Name_Not_Found：02/03/29 17:14 ID:xRylPjVs

>>766
広告が入らない無料サーバを使う（ごく稀に存在します）

769 ：茶文字 ◆xELvisFU ：02/03/29 17:16 ID:cjCtC/cu

>>765
近いものはできるわけだし、別に排除する必要はないと思うんだけど。
うーん、実物を作ってみて検討するかな。
そうでもしないとこの胸のモヤモヤ感が消えない。

意味不明でｺﾞﾒｿ

770 ：Name_Not_Found：02/03/29 17:19 ID:dPAljt+H

>>766
かめぞーたんのところは？

771 ：Name_Not_Found：02/03/29 17:22 ID:Y6LdipER

うーん、頑張って広告はいらないアカウント取得してみます。
…無理だったら諦めて有料を借ります。はい。
ありがとーでした。(;´Д`)フゥ

772 ：Name_Not_Found：02/03/29 17:42 ID:AkEtlzYS

だれかがどこかに書いてたけど、XREA なら広告をいじれるよ。
でも「申し訳ありませんが、新規登録は準備中です。」だって。

まあレン鯖行って色々調べてみれ。

773 ：Name_Not_Found：02/03/29 18:12 ID:KKMx0zei

>919
是非頼む。

まだ不確かなんだけど、友達の家が襲撃されるかもしれない状況らしい。
しばらくメールチェックをさぼっていたら、襲撃予告のメールが届いてたとか・・・
しかも全く知らない人から。
とりあえず、間違いであることを祈ります・・・
やはり金曜日は危険なのか・・・

774 ：773：02/03/29 18:14 ID:KKMx0zei

・・・ｽﾏｿ。
誤爆しました・・・
よりによってStrictスレに書き込んでしまった。
逝ってきます。

775 ：Name_Not_Found：02/03/29 18:21 ID:UEyMKDOe

>>773
ていうか、すんげぇ気になるんだけど（ｗ

776 ：Name_Not_Found：02/03/29 19:21 ID:CJBIOSVN

XHTML(メイン)+CSS(サブ)がW3Cの考え方、スタイルがうまく適用されなくても内容が伝わればあきらめるべきでは？
スタイル・デザインを(内容よりも)重視するならXSL(XSLTではなく、XSL)、SVGがぴったりだと思うし、わざわざXHTML使って大変な思いをすることもない。PDFでもいいし。

777 ：Name_Not_Found：02/03/29 19:28 ID:GktIwSMV

>>773
そういや、そんなメール送ったなぁ。

778 ：ネオエクスリア：02/03/29 19:58 ID:XcNGf4OM

>>766
エクスリアならできる。で消して、広告挿入タグを自力で
入れる。XHTMLもオッケー。しかもエクスリア公認。

779 ：これは既出では？：02/03/29 20:35 ID:wX/+uc9I

>>766-770
もし意味が分かって使えるなら

Geocities で valid な HTML を
http://www.geocities.co.jp/Hollywood-Studio/8691/
isweb版もある。

780 ：Name_Not_Found：02/03/29 21:07 ID:Y6LdipER

>>779
それって大胆な発想ですね。面白い（ｗ

781 ：Name_Not_Found：02/03/29 21:48 ID:AkEtlzYS

>>779
まあ、それは valid にするだけなんで、strict なわけではないけど。

不思議マークアップはともかく、
無料のサービスだと valid になってるってだけでも珍しいのかな?

782 ：Name_Not_Found：02/03/29 23:51 ID:wX/+uc9I

>>781
御意。一応制作者サイドとしては Strict⊂Valid ということで
Y6LdipERの手伝いになればと思って。

> 無料のサービスだと valid になってるってだけでも珍しいのかな?
言うまでもないでしょう。Strict なソースで公開するのも
至難の技でしょうが、一応応援。

783 ：Name_Not_Found：02/03/30 12:13 ID:sK7mkY0i

広告はいつなんどきでも変えられる可能性があるから、追従作業は大変だ。それに追従作業中はInvaildになるのもちょっと。しかも、明らかにW3C非推奨のDTDでしょ？ちょっと無理があると思う。そのくらいやるなら拡張子.xmlにしたら？

784 ：Name_Not_Found：02/03/30 13:00 ID:+m3Bjr7z

携帯メディアなるものが、登場してきてXHTML basic

785 ：Name_Not_Found：02/03/30 13:14 ID:a3z5D1tQ

ブラウザごとに、要素の表現方法が違うので
* {martin-bottom:0px;margin-top:0px;margin-left:0px;margin-right:0px;font-style:normal;font-size:100%:}
にしているのですが、
こういうのはしないほうがいいのでしょうか？
bodyだと、addressの要素で囲まれた内容が、
イタリックになります。

あと、ブロック要素の中央寄せは、
marign-left:auot;margin-right:auto;
ですが、これでは、IE5.5では中央寄せにはなりません。
どうしてでしょうか？

786 ：Name_Not_Found：02/03/30 13:18 ID:a3z5D1tQ

port5.comは広告ないみたい。100MBの転送量制限あるけど。
http://pc.2ch.net/test/read.cgi/hp/1015663855/

787 ：Name_Not_Found：02/03/30 13:21 ID:1i/beOb3

>>785
えーっとね
http://www2u.biglobe.ne.jp/~zashiki/css-make/t-a/index.html
ここ読めばだいたいは分かると思うけど…。

あと
margin : 0 0 0 0;
で一つにまとめた方が良いと思うよ。
ってかあんまりStrictに関係なくない？

788 ：Name_Not_Found：02/03/30 13:41 ID:+ktUplIZ

HTMLもHEADもBODYも書かなかったら、広告が消えてしまうスペースが結構あるのはどうにかならんか。鳥とか。
titleに噛ませてくれればいいのに。

789 ：Name_Not_Found：02/03/30 13:42 ID:VOfssCai

>>785
UAのデフォルトの表示やユーザースタイルシートは大切だと思います。
変更したい個所を個別に変えることには賛成しますが、
一括して変更することは賛成できません。

# ただ、イタリック体って
# 正直、読みにくいと私も思います。

790 ：Name_Not_Found：02/03/30 14:37 ID:7MoFdLeA

>>789 >>785
勿論、文書構造が解る様に、更に色々足す必要は有るけれど、
とりあえずデフォルトスタイルシートを潰す為、と考えれば
全然問題無い。

＞ブロック要素の中央寄せ
基本的には、>>786の出したURIなんだけど、
IE5.5以下とIE6.0の互換モードでは、
text-align:centerで、ボックスがセンタリングされる形になってしまう。
widthやheightの解釈と並んで、IEが嫌われる理由の一つなんだけど、
ここらは、CSSバグ辞典スレの方が解り易いかも。

＞margin : 0 0 0 0;
ていうか、margin:0で良い様な。

791 ：サ骨 ◆/IQ5000w ：02/03/30 19:47 ID:yU47qoYU

＞ブロック要素の中央寄せ

左右のマージンと、ボックスの幅を足して100%になるようにすれば
大体上手くいったような気がする。
ボックスを入れ子にしていくとmozillaでヘンなことになるかも…

792 ：Name_Not_Found：02/03/30 20:17 ID:+m3Bjr7z

accesskeyはXHTML basicで使用しちゃいけないんですか？

793 ：Name_Not_Found：02/03/30 21:07 ID:zHpTi9sr

>>785
デフォルトスタイルシートを潰したいなら
ズボラしないで全要素全プロパティ書け。

というのは過激派の意見でしょうか?

794 ：Name_Not_Found：02/03/30 21:10 ID:aioMwpJ9

　話の流れを無視して申し訳ないが、今から（所謂）「ホームページ」教室を書くなら、
HTML ではなくXHTML の解説を行ったほうがよいの？

　W3C は明らかに HTML から XHTML に移行したがっている見たいだし、
これから Web browser は XML パーサになっていくみたいだし（私見）。

795 ：Name_Not_Found：02/03/30 21:11 ID:aioMwpJ9

>>793
全要素全プロパティの指定が * では？

796 ：793：02/03/30 21:16 ID:zHpTi9sr

>>795
全称セレクタは理解してるが、
Strictスレ的に全要素同じ指定はありえないと思われ。

797 ：Name_Not_Found：02/03/30 21:20 ID:h0iFelBU

>>794
流れからするとXHTMLかな。
今の状態だとXHTMLで「ホームページ講座」ってのは見かけないし。
個人的にもそーゆーページ見たいし。

>>773が気になる・・・その後の解説聞きたい・・・

798 ：ちょこら ◆DmcC0DXc ：02/03/30 21:27 ID:O36pzUSM

>>785,>>793
僕も最近全要素をまっさらにしようとして
* {hogehoge---}
という感じでやったんだけど、これだと
あとで指定した設定がまったくカスケードしなくなってしまうので
全然カスケーディングスタイルシートではなくなってしまいました。
継承するすばらしさをなくしてはじめて知りました。

まあれだ、全要素リセットしたかったら
ねぎま氏作のリセット用シートをありがたく使わせてもらうのが
手っ取り早いと思う。

799 ：ちょこら ◆DmcC0DXc ：02/03/30 21:28 ID:O36pzUSM

っていうかスレ違いだったかも。
ごめんなさい。

800 ：Name_Lots_Found：02/03/30 22:25 ID:vxr5zmft

全称セレクタ使わずにCSS2仕様のAppendix Aあたりの
サンプルシートを引っ張ってくるって言うのはダメですかね…
http://www.w3.org/TR/REC-CSS2/sample.html
っていうか、昔XHTML+CSSをtext/xmlな形でブラウザに食わせたら
全部インラインになって(当たり前)これを引っ張ってきて使ったことがある。

801 ：Name_Not_Found：02/03/30 22:50 ID:vEmNavcY

>>800
あれ使うと妙な表示になるUAもあるよ。
MacIEはフレームのページが閲覧不能になるし、
あとbrにdisplay:blockを指定するとtable周りが潰れる。
（バグ辞典スレ参照）

要素に対してスタイルシートを持つUAの為に指定を省くか、
スタイルシートを持たないUAの為に全部指定してやるか、
が難しい。例えばMozillaのabbr/acronymね。

UAの持つスタイルシートやユーザースタイルシートを参照したり、
それがある場合と無い場合を振り分けて指定出来る様になって欲しいね。

802 ：795：02/03/30 23:23 ID:E9VsS4+V

>>796
基本的に全要素指定しておいて、後で個別に設定をカスケードさせるのが、
カスケーディングスタイルシートであって、十分に strict な運用だと思われ。

>>798
inherit などを上手く使えば十分カスケードするはず。

* {font-weight:inherit;}
body {font-weight:normal;}
h1,h2,h3,h4,h5,h6,dt,th{font-weight:bold;}

　例えばこんな感じ。

803 ：Name_Not_Found：02/03/30 23:41 ID:X0cyVekY

CSS1 Specification の Appendix.A に HTML2.0 のサンプルスタイルシートが
載っていますが、現行UAの用意するスタイルシートはおおよそこれに準拠しているようです。
そこで指定されているセレクタ、プロパティについて値を上書きすれば、
デフォルトのスタイルはつぶせるのではないでしょうか？
http://www.w3.org/TR/REC-CSS1#appendix-a

804 ：Name_Not_Found：02/03/31 00:53 ID:8WrWQ+aM

>>802
transparentが黒くなるのは知っていたが
inheritが緑色になるので鬱@NS4.x

ｽﾚ違いsage

805 ：Name_Not_Found：02/03/31 03:30 ID:L4+qXMgn

ローマ数字の場合、
実体参照させる（Ⅰ～）のと、
アルファベットの組み合わせで代用する（I,II,III～）のとでは、
どちらがStrictなんでしょうか？

読み上げ的UAを思うと、実体参照させるべきだとは思うんだけど、
ただローマ数字がそもそもアルファベットの組み合わせだという説があるらしく、
それが正しければ、別にアルファベット表記でも問題無い気もします。

でも、CSSでupper-romanなんて値があるんだから、
実体参照が正しい様な気もするんですが．．．。

806 ：Name_Not_Found：02/03/31 09:35 ID:As9pLd6P

>>805
以前某方面でも話題になったことがあったような。

どちらが望ましいか、と言えば文字参照の方が好ましいだろうけども、
漏れは下記なんかを読んで、どっちでもいいかなあと思っている。
http://satsuki.sakura.ne.jp/~rockman/diary/200107.html#d25

# こまいことだが、この場合は ○文字参照 ×実体参照
実体参照というのは & などのような &名前; の形式のやつを言う。
&#数値; とか &#x数値; とかは文字参照と言う。

807 ：Name_Not_Found：02/03/31 11:58 ID:41UPApHf

>>806
「数値文字参照(Numeric Character Reference)」
「文字実体参照(Character Entity Reference)」

の方がベターでは。
まぁ、名前指定文字参照と誤解されたりはしないと思うけど。

808 ：Name_Not_Found：02/03/31 12:08 ID:8h5bif52

ところで、705の件はどなったの？

809 ：Name_Not_Found：02/03/31 12:18 ID:/nUFWMfd

>>808
まず誰か最初にリソース揃えたやつが晒して、
それに対して皆が突っ込む。でいいのでは？

一応俺も書いてないことはないが晒せるほど量が揃ってない。

810 ：Name_Not_Found：02/03/31 13:01 ID:kgaXn0Vl

ここにあるのが、草稿じゃないの？
http://pc.2ch.net/test/read.cgi/hp/1015303243/165-

811 ：Name_Not_Found：02/03/31 13:49 ID:J20YSk9W

>>705の企画の協力するのにやぶさかではないのだけれど、
>>810のスレの趣旨がよく分からない。

812 ：805：02/03/31 17:40 ID:L4+qXMgn

>>806-807
勝手に、（数値文字参照＋文字実体参照）＝実体参照
と思い込んでいたのですが、
良く考えると、ampやcopyが実体なんだから、
数値に対して実体というのは、矛盾してますね。

で、これらを総称する言葉が内田訳では、
「文字参照」になっている様に解釈出来るんですが、
これで問題無いんですよね？
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/charset.html#h-5.3

813 ：Name_Not_Found：02/03/31 19:03 ID:avKIgptA

>>812
ttp://8120.teacup.com/pastelsbadges/bbs

のログに参照の話が載ってますよ。

814 ：792：02/04/01 06:40 ID:lAKvgsy/

.....

815 ：Name_Not_Found：02/04/01 07:03 ID:B+HUo05G

>>728
まさにそういう感じの解説を書いてる最中だったけど、需要あるかな?

>>792
使えるよ。まず lint や validator でチェックするが吉。

>>812
SGML 的には

文字参照 ::=
　　数値指定文字参照(&) | 名前指定文字参照(&#TAB;)
　　| 十六進数文字参照( )

で、「文字参照」という語は他の意味を持つ「用語」として定義されている。
いわゆる実体参照は必ずしも「文字」を参照するとは限らないので、
文字参照と呼ぶのは本来余り適切でない。

例えば、<!ENTITY amp "<p>段落</p>" >　と宣言されていれば、
amp の置換テキストは「文字」ではなく「要素」になるわけだし。

でもまあ、HTML の場合には「一般実体参照=数値指定文字参照」なので、
両方ひっくるめて「文字参照」と呼ぶのもありかなあ。
…というのが >>813 のリンク先の内容ね。

816 ：茶文字 ◆xELvisFU ：02/04/01 07:31 ID:p+aXG6+8

ぼちぼち構想が固まってきたんで、Strictな解説サイトのたたき台を出しまふ。
今日中にとっかかりだけでも出せるかな？
余裕があればあぷろだも提供するかも新米。

関連する議論はこのスレで続行をきぼん。
ウエイトが大きくなってきてうざくなったら、その時に手を打てばいいかなと考えてまふ。

817 ：Name_Not_Found：02/04/02 01:16 ID:rF9x3dxZ

>>816
援護しますです。アプロダ出来たら、くだらないネタで提供します。
しかし…いつもながらに下がってるな。このスレ。（ｗ

818 ：じゃあ：02/04/02 07:34 ID:+xFl8oC3

age

819 ：Name_Not_Found：02/04/02 15:11 ID:V06KONJ8

悲しい体験…聞いてください。

うちのサイトトップページをStrictで作ってそこからFlashMXページとStrictページへのリンクを張っているのですが、FlashMXページのアクセスの方が多い。
まぁ、どっちも本気で作ったし画像中心サイトだから見栄えが良い方、UAが対応してるなら最適な方を選んだ方がいいのはわかるのですが…それでも1日1500アクセスの5%程度しかStrictページが需要がないのが悲しい…

以上、愚痴でした。すっきりしました。
スレッド汚してすみません。

820 ：?3?AE?Y´???n ◆R4.ALMK. ：02/04/02 16:18 ID:6ihqbKDw

>>819
FlashMX ページのほうがメインというかオススメです！
と言外に言ってるみたいな配置をしてるのでわ、とか。
たとえば FlashMX へのリンクが左で Strict が右にあるとか。
フレーム有り／無しをえらべるページでも、フレームはウザイなとか
思ってるのに、左側にある「有り」を選んでしまう。
サブ（のようにみえる）ほうは、なにか更新が澱んでそうな印象あるし。

821 ： ◆R4.ALMK. ：02/04/02 16:18 ID:6ihqbKDw

なんか名前にへんなのがはいった…。

822 ：Name_Not_Found：02/04/02 16:28 ID:D8zq/ezl

>>820
> サブ（のようにみえる）ほうは、なにか更新が澱んでそうな印象あるし。

あるね。確かに。

823 ：Name_Not_Found：02/04/02 16:39 ID:GFzcd8gL

Strictの方を見せたければ

快適なHTMLバージョン/ロードの長いFlashMXバージョン

とか書いて誘導しないとね。確かに。

824 ：Name_Not_Found：02/04/02 17:25 ID:nRGdP1eV

>>816
>たたき台
既存のサイトをいくつか上げて、
ここが良いから真似しようとか、ここが悪いから改善しようとか、
そこからはじめます?

まったくのゼロから始めるのって難しいでしょうし

825 ：Name_Not_Found：02/04/02 17:30 ID:YWlCZeE3

テーブルはデザインのために使わなければ使っても良いですか？
下のアドレスのように、テーブルを使って、和暦西暦一覧表を
http://www.city.suwa.nagano.jp/scm/dat/wareki2/wareki_004.htm
作ろうと思うのですが、これはデザインのためではないので
良いですか？

826 ：Name_Not_Found：02/04/02 17:35 ID:i2rVu8EB

>>825
こんな質問が出てくるのが少し嘆かわしくもあるけれど、
tableを表として使う分には全然構いません。そのためのものですから。

827 ：茶文字 ◆xELvisFU ：02/04/02 17:52 ID:SDZ7KVC+

>>824
既存サイトの研究は必要でしょうね。
作り始めたはいいものの、網羅性にこだわってしまいわかりにくくなったので
公開を見合わせてます。
うぅむ　どうしたものか。

828 ：Name_Not_Found：02/04/02 17:54 ID:GFzcd8gL

>>827
目次をうｐ

829 ：Name_Not_Found：02/04/02 17:54 ID:Bo5q+tK6

<TD> </TD>はいいの？

830 ：茶文字 ◆xELvisFU ：02/04/02 18:21 ID:9STjCw/m

>>828
お言葉に甘えて導入部分だけ。

　　【目　次(案)】
1.基礎となるHTMLの骨格を知る(ネストの理解)
　　DOCTYPE html head body title hn p
2.インライン要素の導入
　　srtrong/em a
3.ブロック要素とインライン要素の概念を確認
　　blockquote/q
4.初歩的なCSSを記述(headに内包)
　　color background-color
5.CSSのボックスの概念を知る
　　border-* margin padding
6.UAによってデフォルトのスタイルが異なることを知る
　　各種UAのデフォルトスタイルをスクリーンショットで提示
7.CSSの継承の概念を知る
　　div spanを導入、例示

このあとはできるだけ使用頻度の高い順にHTMLとCSSを適宜挙げていく……
という感じでイメージしてますが、いかがなもんでしょ。

831 ：825：02/04/02 18:49 ID:YWlCZeE3

>>826
ありがとうございます。
テーブルを使って、表を作ることにします。

832 ：Name_Not_Found：02/04/02 18:51 ID:GFzcd8gL

>>830
個人的にはもっとチュートリアルっぽくていいと思う。
初心者が作りがちな「ホームページ」をStrictに作らせる感じで。

で、2の前にol/ul/dlを紹介、CSSによるブロック要素のレイアウトの基礎(widthとfloatから)をある程度仕込む。
多分大雑把な方から説明していったほうが画面の変化が大きくて初心者の目を引きやすい。

と、思ったりした。

833 ：Name_Not_Found：02/04/02 19:21 ID:569H2ZsJ

>>830
やっぱ素人向けにはimgがないとダメでしょう。
実際漏れも img をどうやっていれようかいつも悩むし

<p><img></p> か、それとも
<div><img></div>

挿絵とか、写真とかいちおう見てもらいたい画像だという前提で。

834 ：Name_Not_Found：02/04/02 19:24 ID:GFzcd8gL

>>833
俺もimgは早いほうがいいと思うけど、
インラインとブロックの区別が出来るようになってからじゃないと
危なっかしくて教えてられない罠。

835 ：茶文字 ◆xELvisFU ：02/04/02 19:33 ID:9STjCw/m

>>832-834
確かにol/ul/dlは需要がありそうだから早めに欲しいですね。

imgに関しては早めに扱うと正負両面あって悩んでます。
【正】空要素の導入として適切
【負】画像に頼りすぎる傾向を招きかねない
　　　alt属性、width/height属性の記述が長くなり、導入としては冗長

836 ：520：02/04/02 19:42 ID:JWPy4fgI

>>824
既存のサイトのよいところに学ぶ、というのはいいと思うけど、
悪いところを挙げる、というのは注意が必要かも。
他者の欠点を批判する、というのは、たとえその批判が正当なものであっても、
善良な読者の反感を買いやすいので。
（野嵜氏のところの『斬るコーナ』や鳩丸の『のけぞる本』とかも、それで
損をしていそうな気がする）

837 ：520：02/04/02 19:48 ID:JWPy4fgI

>>835
「画像濫用のデメリット」についても、きちんと説明しておけば、後は結局、
読者の側の問題では？
それより、記述が冗長になることの方が問題だと思う。
（画像濫用についての説明を加えると、さらに記述が長くなるし……）

838 ：あぼーん：あぼーん

あぼーん

839 ：茶文字 ◆xELvisFU ：02/04/02 19:58 ID:9STjCw/m

>>836
これから提供しようとしているコンテンツの中で批判をする必要はないけれど、
グループで検討するなら既存サイトの短所を健全に批判することはむしろ有益でしょう。
初心者にはそれらの批判をアピールしない方がいいだけで。

常々思うのですが、正当な主張も受け容れられやすい形で提供されなければ
人々に広がりにくくなってしまいます。
>>836で示されているような鳩丸やPC Tipsの一面は、マーケティングの面で見ると
好ましいコンテンツではありません。
かく言う私たちもまた「既存サイトの欠点を指摘」していることになるわけですが、
初心者向けコンテンツとしてはそれらの検討の結果を提示すればいいのであって、
過程は隠しておいていいんじゃないか、ということです。

840 ：Name_Not_Found：02/04/02 21:03 ID:u4bQzmpN

「正当な批判」を認めないやつを「善良な読者」と言えるのか？
俺的には構わないと思うがなぁ。

841 ：茶文字 ◆xELvisFU ：02/04/02 22:19 ID:9STjCw/m

>>840
Web制作支援サイトの相互批判は有益な議論だと思いますが、
初心者にとっては「次のステップ」でいいんでは？
別に最初から目にしなければならない話題ではないと思うけど。

初心者に媚びる必要は全くないけども
たとえ健全であれ、批判コンテンツがStrictなマークアップの啓蒙を妨げるなら、
それらを同居させるべきではないと思うわけで。

健全な批判はこの板でもできるわけだし、あるいは同じように共同サイトとして
世に訴えるのもありだと思うんだけど、
コンテンツとしては「それはそれ、これはこれ」の方がいいんじゃないかな。

842 ：茶文字 ◆xELvisFU ：02/04/02 22:24 ID:9STjCw/m

て優香このあたりのことはすでに潜伏中のスレで書いてたりする。
http://pc.2ch.net/test/read.cgi/hp/1015303243/180n

843 ：Name_Not_Found：02/04/02 22:29 ID:FTuVO2ZX

>>840
ま、批判し出すと、キリがないというか、
某こみゅーんの論争にありがちな、やり過ぎてしまう危険もあるしなぁ。

＞インライン画像
alt属性辺りは、画像off時のlynxやMozilla辺りのスクリーンショットも
見せなきゃならんだろうし、
そうなってくると、また説明が泣けてくるというか。

>>830
＞6.UAによってデフォルトのスタイルが異なることを知る
＞各種UAのデフォルトスタイルをスクリーンショットで提示

この辺りメチャメチャ期待。
中々、デフォルトスタイルシートを潰し切れないというか、
つい手を抜いてしまうというか。

844 ：茶文字 ◆xELvisFU ：02/04/02 22:55 ID:9STjCw/m

>>843
私の手元にはWinIE5.5/NN6.2/NN4.7/Opera/Lynx on Cygwin、
MacIE5/NN6.2/Opera/iCab、TubroLinuxNN6/Conqueror?があるんで、
あとMacNN4.xでも入れればたいてい網羅できるかな。
TurboLinuxでスクリーンショットを撮る方法を知らんのだけど（ｗ

が、えらくめんどくさい作業であることは事実だ；

845 ：Name_Not_Found：02/04/02 23:01 ID:rF9x3dxZ

>>844
TurboLinuxでは、スクリーンショットを取るソフトがありますよ。
Turboに限らないけど。

846 ：Name_Not_Found：02/04/03 04:55 ID:Q34cdtW6

>>830
いくつかコメント。

まず、解説の導入としては、既存の文章をマークアップして
HTML文書に仕上げていく過程を提示すべきと考えます。
というのも、まず先に文章が無いと、要素の概念を理解することが
困難と考えられるためです。

具体的には、hn要素、p要素、ul要素（もしくはol要素）、em要素、
img要素を含む文章を例として提示することで、要素の概念、
要素とタグの関係、ブロックレベル要素とインライン要素の違いを
説明できます。

ここでは、em要素は、インライン要素の代表的な例として、img要素は、
インライン要素とブロックレベル要素の差異を強調する（div要素等で
括ることで両者の違いを強調する）手がかりとして挙げています。
要素の属性についてもimg要素を手がかりに説明できるでしょう。

以上のことを説明した上で、title要素、head/body/html要素、DOCTYPE
宣言の順に説明すれば、生の文章を相互運用性に配慮したvalidなHTML
文書に仕上げていく過程を理解できると思います。

847 ：Name_Not_Found：02/04/03 04:56 ID:Q34cdtW6

次にCSS関係ですが、4、5、7、についてはそのままでよいと思います。
ただし、CSSを見栄えの良い「ホームページ」を作るための補助的な
手段と誤解されないような配慮が求められるでしょう。

6.について、ビジュアルUAのスクリーンショットは特に必要ないと
思います。lynx、w3mなどのスクリーンショットはアクセシビリティ
との関連で提示した方がいいと思います。
ただ、各ブラウザのデフォルトスタイルシートを提示することは、
非常に良いアイデアだと思います。

848 ：Name_Not_Found：02/04/03 05:12 ID:Q34cdtW6

サイトのコンテンツについて提案。

HTML+CSSの解説が主要コンテンツになると思いますが、
webサイト作成の前提となる知識やツールの解説や、
faq的なものも必要になってくるでしょう。

前者は、ローカルとリモート（サーバ）の違い、FTPソフトの使い方、
エディタって何、というレベルの解説、faq集については、
初心者スレの冒頭に書かれているようなものを想定しています。

849 ：ただそれだけ：02/04/03 05:45 ID:t2FywfRt

て優香←これキモイ

850 ：846：02/04/03 05:56 ID:0MFpx64b

読み返すと厨房みたいな文章だ。申し訳ない。

851 ：j君：02/04/03 06:14 ID:wfJK0KWl

俺もSTRICT系のページを作っていたけど
挫折してたんだよねええ
再開してみよ

852 ：520：02/04/03 07:03 ID:3IxYm6x+

>>840
まあ、「善男善女」ぐらいのニュアンスで。

>>846
まず文章を用意することには賛成。ありがちな、
「なんでもいいから、とにかくホームページ作りたい」
ではなく、
「表現したいことがある。その手段としてのウェブサイト」
というのが大事だと思う。
それがどうしても受け入れられない初心者には、何をどう教えても
無駄のような気がするし。

853 ：520：02/04/03 07:12 ID:3IxYm6x+

あと、

> HTML+CSSの解説が主要コンテンツになると思いますが、
> webサイト作成の前提となる知識やツールの解説や、
> faq的なものも必要になってくるでしょう。

にも賛成。
「ほしい情報はここでぜんぶ手に入る」というのは喜ばれるだろうから、
たとえよそのサイトで必要な解説が手に入る場合でも、できるだけ網羅的に
やる（最初は無理でも、将来的には）方がいいのでは。

まあ、あまり親切すぎない方が、初心者に「学ぶ姿勢」を身につけてもらう
という、意味ではいいのかもしれないけど……

854 ：Name_Not_Found：02/04/03 08:51 ID:wQpJDPSI

おまえら初心者向けなのに、専門用語おおすぎ

855 ：Name_Not_Found：02/04/03 13:37 ID:GJx5PNih

今はまだ構成段階だからいいんじゃない？
文章が出来ていく中で「これには解説がいる」とか出てくるだろうし。
はじめから立派なのなんてできないんだから、とにかくどんどんやっていけばいいんじゃないかな。

856 ：Name_Not_Found：02/04/03 14:14 ID:+Ngke1mq

「とにかくホームページ」で作られたサイトの方が、
かえって変な気負いがなくって良いんだけどな。
適当な日記だけでも十分面白いし、
その人の趣味が前に出てくればそのうち路線変更するでしょ。

ただ、個人情報についてはちゃんと注意を喚起した方がいいね。

857 ：Name_Not_Found：02/04/03 15:01 ID:DF2AjvVv

そうだね、難しすぎる専門用語には気を付けた方が良いよね。

一番最後で良いから、"転載"や"引用"についても解説があると良いかも
あと、直リンについても

858 ：Name_Not_Found：02/04/03 15:25 ID:Np45NEzF

今、ワープロ専用機で作成されたデータのHTML化を、
死ぬ思いでやってる（プリントアウトで提供されたため、手打ちなのだよ……）んだけど、
HTMLの利点として、基本的に環境を選ばないという点を強調してやっておくれでないかい。

この点が知れ渡ると、IE5以上でないと駄目、とかいうページも減る、

と今は信じたい……

859 ：Name_Not_Found：02/04/03 16:37 ID:+wvInA6b

>>853
将来的には、StrictなとほほのWWW入門という感じになれればいいですね。

860 ：846：02/04/03 17:28 ID:V+mnNZXV

>>848のコンテンツに加えて、関連スレ、関連サイトへのリンクや、書籍の紹介を
加えると、web板のポータルサイト的なものができあがる。
それをこのスレで作ってしまうことに意義がある。

/* スレの話題がずれてきたので、新スレをたてるか、外部に専用の板を作った方がいいような。 */

861 ：Name_Not_Found：02/04/03 18:15 ID:XCG7lGfv

しかし、それだけ大きくなると管理（制作/立案/..etc）が大変だな。
数人でやるのがベストだろうが、それぞれStrictに対する（初心者に対する）考えを一本に絞った方が良いだろうし…。

/* しかしこのスレではStrictネタが既に枯渇してきているのも事実。誰かが質問すれば良いんだけどヽ(´ー`)ﾉ */

862 ：茶文字 ◆xELvisFU ：02/04/03 20:17 ID:Zpvtz82Z

以前書きかけていたリファレンスを元に作りかけてましたが、
やはりチュートリアルは書き下ろさないと整合性が取れないと思い
最初から書き直してます。
大幅に遅れましたが、日付が変わるまでに2枚くらいたたき台を出せるかな。

で、議論の続行はどういう形でやりましょかね。
選択肢としては、
<ol>
　<li>このスレで続行</li>
　<li>独立スレ立てる</li>
　<li>したらばを借りる</li>
　<li>2ch互換スクリプトを設置しる</li>
</ol>
こんなもんかしら。

せっかく広く建設的に意見交換する雰囲気ができてきてるんで、
できたらあまり議論の環境を変えたくないです、個人的には。
なので、上記選択肢の順番は上から順に私の希望順ですな。
# いちおう手元にはうなぎスクリプトがあってローカル動作確認済みだけど。

863 ：Name_Not_Found：02/04/03 21:13 ID:DF2AjvVv

今までの成果をまとめるわけですから、
このスレで続ける方が良いと思います。

864 ：Name_Not_Found：02/04/03 23:07 ID:CS4qr6Ak

>>862
このままでも構わないんですけど、他の話題が入ってきたときに、
同時進行になると文脈を読みわけるのがツライかな、と。
過去にあった「Ｑ要素：インライン引用文のマークアップについて」のように、
　http://natto.2ch.net/hp/kako/1002/10027/1002750163.html
別スレで徹底的に話し合うのもいいのでは？

#「HTML+CSS解説サイトを作ろう」が落ちてなければ再利用できたのに…
　http://pc.2ch.net/test/read.cgi/hp/1009094059/l50

865 ：Name_Not_Found：02/04/04 00:15 ID:WdpMVjZC

Strictスレ3.1でも立ててやるか？＞解説サイト話

866 ：Name_Not_Found：02/04/04 02:05 ID:9bA2O/uy

このスレ再利用出来ないかな？

ホームページの作り方
http://pc.2ch.net/test/read.cgi/hp/1011834614/

867 ：Name_Not_Found：02/04/04 13:04 ID:tnyNoCs7

どっちにせよあと少しで新スレ移行になるからねえ。
ここで続けるなら１に「現在Strict入門サイトについての議論が
中心になっていますが、それ以外の話題もどんどんどうぞ」とか
書いてみたらどうでしょう。

868 ：Name_Not_Found：02/04/04 13:36 ID:xhtNdQf1

そんなにスレの伸びが早い訳じゃないから、ここで一本に絞って良いんじゃないでしょうか？

869 ：：02/04/04 15:26 ID:hXJDhuSH

流れに乗っていない話題ができるかどうかのテストを兼ねて．
次の3つの書き方のうち，一番好ましい（strictに適っている）と思われるのはどれでしょうか？
正解はないかもしれないけど，皆様はどう書くのかな，と思ったので．
もちろん，日本語の文脈中での話．
1. <acronym title="Sprots and Music Assembled People, 運動と音楽を融合したグループ">SMAP</acronym>
2. <acronym title="Sprots and Music Assembled People"><span title="運動と音楽を融合したグループ">SMAP</span></acronym>
3. <span title="運動と音楽を融合したグループ"><acronym title="Sprots and Music Assembled People">SMAP</acronym></span>
あと，2や3のように書いた場合，titleの内容をどう表示するかはUAの実装依存？それとも内側の方が優先かな？
この点が不明なので僕は1のように書くようにしてるけど．

870 ：520：02/04/04 16:28 ID:TmTZKbzT

>>869
そもそも日本語訳は必要ないとして、

<acronym title="Sprots and Music Assembled People">SMAP</acronym>

とするか、日本語訳を解説の一部に盛り込んで、

<acronym title="Sprots and Music Assembled People"><dfn title="絶大な人気を博する男性芸能人5人組。名称は「運動と音楽を融合したグループ」の意。">SMAP</dfn></acronym>

かなあ。

871 ：Name_Not_Found：02/04/04 16:54 ID:TgKKh3xX

真のstrictはabbrダヨ！

あと、dfnは用法が違うんで無いかい？

872 ：Name_Not_Found：02/04/04 18:43 ID:5efULfvh

>>871
1行目が意味不明なんですけど…マジで。SMAPは頭字語だよ？

dfnは文脈の中で
…<dfn>SMAP</dfn>すなわち、絶大な人気を博する男性芸能人5人組。名称は「運動と音楽を融合したグループ」…
ってな感じで、定義語とその説明はDOM的には明確に
関連付けできず、文脈依存。…だったよね？

873 ：Name_Not_Found：02/04/04 18:54 ID:d2meYwxW

>>872
acronym要素とabbr要素については>>205-234あたりを参照されるとよろしいかと。

874 ：Name_Not_Found：02/04/04 18:54 ID:N58O4ys/

>>872
W3C的にはabbrを推してたんだけど（意味的にacronymも含むと言う事で）、
IEが先にacronymだけを実装しちゃっていたから仕方なく仕様に入れたんだと。
で、それからいつまで経ってもIEはabbrを実装してくれない、と。
でも、HTML4のサンプルを見るとそう言う使い分けなのかと思っちゃうよね。

どっちにしてもコンセンサスを維持しようとしなかった御蔭で
ユーザーに皺寄せが来ている訳だ。

875 ：Name_Not_Found：02/04/04 19:05 ID:N58O4ys/

WinIEならinnerHTMLからabbrを拾ってacronymに変換するJScript functionを
読み込み終了時に呼び出す様な拡張は出来るのかな？

876 ：Name_Not_Found：02/04/04 19:08 ID:d2meYwxW

>>875
>>241を見る限りでは、ちょっと面倒かも。
技術的には十分可能だと思うけど。

877 ：Name_Not_Found：02/04/04 19:25 ID:N58O4ys/

>>876
いやだから標準DOMじゃなくてinnerHTMLね。
WinIE以外で動く必要無いんだから。

878 ：876：02/04/04 20:50 ID:sWFzZpQY

>>877
ああ、innerHTML中の"</?abbr"を置換するって話か。それなら簡単だなあ。

879 ：876：02/04/04 21:03 ID:sWFzZpQY

こんな感じ。

document.body.innerHTML = document.body.innerHTML.replace(/(<\/?)abbr/ig, "$1acronym");

880 ：876：02/04/04 21:07 ID:sWFzZpQY

んで拡張のほうは、データを書き換えられるHTTP Proxyを使うかBHO使うかIEの起動を監視する常駐アプリを作ればオッケーと。

連続書き込みスマソ

881 ：874,875,877：02/04/04 21:46 ID:N58O4ys/

↑つー訳で誰かこう言うの作ってｸﾚ。俺まかーなんで何も出来ん（笑）。

882 ：j君：02/04/06 07:56 ID:f0NpJwtk

あげ

883 ：Strictの意義：02/04/06 10:46 ID:Yt/qd8CW

今、ふと思ったんだけど…俺ってStrictでサイト作ってるけど、Strictである意義を理解せぬまま、Strictでやってしまっている事に気が付いた。（汗）
Strictである意義、意味ってなんだ？身近な例で教えてくれると助かるんだが。ちょっと、自分でもそこらへん勉強してくるか。

884 ：Name_Not_Found：02/04/06 11:33 ID:R7BTYNcq

>>883
Strict == 仕様に厳格 == 当然の事を当然にする

885 ：520：02/04/06 14:31 ID:ld2kPdJx

>>883
>>884
つまり本来Strictであるのが当たり前で、
特別な意義だの意味だのを必要とするようなことじゃないと。
むしろ、Transitionalや不思議マークアップを選択することの方が、
なにか動機が必要ってことですかね。

886 ：Name_Not_Found：02/04/06 14:37 ID:Nt/o45eo

＞むしろ、Transitionalや不思議マークアップを選択することの方が、
＞なにか動機が必要ってことですかね。
「直感的に記述したいから」。むしろ、これは自然。
HTML＋CSSの2重構造より、旧来のフラットなHTMLの方が直感的なのは
明らかでしょ？
とは言え、普段使っているUAに限っての話だし、肯定はしないけど。

887 ：Name_Not_Found：02/04/06 23:32 ID:5ZypSzN5

不思議マークアップな解説書の類が氾濫してるし．
そんなのつかまされたらどうやっても不思議マークアップになってしまうというのも．

888 ：Name_Not_Found：02/04/07 01:10 ID:wKBvgGKG

>>887
そうそう、それそれ。
だからこそStrictな入門サイトを作ろうと言う話にもなるわけで。

889 ：887：02/04/07 01:40 ID:F/4Zz2Lr

>>883
このスレ読み返しつつ入門サイトが出来上がるのを待ちましょうってことで．

/* おまえもなんかせえよ＞自分 */

890 ：520：02/04/07 01:54 ID:a51xwmIo

ところで、今、図書の目録みたいなものをHTMLで記述しているんですが、
目録全体をdl要素とし、個々の書名をdt要素にするとして、
著者や発行所などのデータは、どのように記述したらいいでしょうか。

(1)
<dt>スタイルシートWebデザイン-CSS2完全解説-</dt>
<dd>すみけんたろう</dd>
<dd>技術評論社</dd>

(2)
<dt>スタイルシートWebデザイン-CSS2完全解説-</dt>
<dd>
<p>すみけんたろう</p>
<p>技術評論社</p>
</dd>

(3)
<dt>スタイルシートWebデザイン-CSS2完全解説-</dt>
<dd>
<ul>
<li>すみけんたろう</li>
<li>技術評論社</li>
</ul>
</dd>

(4)
<dt>スタイルシートWebデザイン-CSS2完全解説-</dt>
<dd>
<dl>
<dt>著者</dt>
<dd>すみけんたろう</dd>
<dt>発行所</dt>
<dd>技術評論社</dd>
</dl>
</dd>

いちおう現在は、いちばん記述がラクな(1)を選び、個々のddに
class="author" title="著者"
といった属性をつけているのですが、厳密には(4)がいいのかな……
などと、ちょっとだけ悩んでいます。

891 ：Name_Not_Found：02/04/07 02:02 ID:hqyzI4lr

>>890
自分がやるなら、

<dt class="書名">書名</dt>
<dd>
<ul>
<li class="著者">だれそれ</li>
<li class="出版社">どこそこ</li>
<li class="値段">いくら</li>
</ul>
</dd>

か

<dt class="書名">書名</dt>
<dd class="著者">だれそれ</dd>
<dd class="出版社">どこそこ</dd>
<dd class="値段">いくら</dd>

か、ですね。

892 ：Name_Not_Found：02/04/07 02:45 ID:V/iymNDO

項目が 2 つ以上あるのならば table で良いのでは。

893 ：Name_Not_Found：02/04/07 05:45 ID:i52dZHMZ

表じゃないだろ

894 ：Name_Not_Found：02/04/07 06:51 ID:48m/zMv7

目録じゃなけりゃ、表でも構わないのでは？まぁ、目録だから表ではないんだろうけど。

もくろく【目録】

（1）書物の目次。また、叢書の内容一覧。「文学全集の―」
（2）所蔵している、または出品されている品目を整理して書き並べたもの。カタログ。「展示品の―」「新刊書―」「財産―」
（3）贈り物の品目を書いたもの。実物の代わりに渡すことにより、その品を贈る意志表示をする。
（4）武術や芸道を弟子に伝授し終わったとき、その名目などを書いて与える文書。
（5）贈り物としての金。「いはぬ色なる山吹の花を包みし―も、明けては見ねど五十両/歌舞伎・天衣紛」

895 ：Name_Not_Found：02/04/07 09:35 ID:xvl5AyVl

>>890
(1) は DTD 的には OK だが、仕様には DT と DD は 1 対 1（または自明な DD を
省略して DT が連続で）使用されるとあるので、strict スレ的にはNG。
個人的には (4) がベストな表記で、(3) > (2) と思うが、ここら辺はリストか、段落かは書き手が決めるべき問題かと。

>>893-894
目録を表で表したいなら別に table でもいいと思う。
table 要素ではないものを table tag で markup するのは問題だが、
ある要素を table 要素として書き込むかどうかを決めるのは書き手が決める事。
で、目録の構造化に関しては table 要素化が間違った内容とも言い切れないと思う。
（table 要素に再構成したら、既に所謂目録じゃなくなっているのは>>894 の言う通りだが、
表現したいのは目録要素ではなく、その内容の筈な訳で）

896 ：Name_Not_Found：02/04/07 10:49 ID:0DHo/vDR

>>890
xml的に考えて再利用を考えたら(4)かな。
>891みたいな感じでもいいと思うが、
素直に(4)でいいのでわ

897 ：Name_Not_Found：02/04/07 13:05 ID:Ioh0vlPx

>>895
> (1) は DTD 的には OK だが、仕様には DT と DD は 1 対 1 (または自明な DD を
> 省略して DT が連続で) 使用されるとあるので、strict スレ的には NG。

(>>890 の) (1) は、その「自明な DD を省略して DT が連続で」
出現するパターンなので、このスレ的にも問題はないと思います
(DOM 的に扱いにくいと言うのは置いておいて)。

で、(4) が至れり尽くせりだと思うけど、
そこまでするなら table にしてしまった方が後々便利です。
目録はデータベースとして扱うものなのですから、
「作品名」「著者名」「出版社」などを列として扱えた方が
圧倒的に活用しやすい。

898 ：Name_Not_Found：02/04/07 15:58 ID:48m/zMv7

ということは、TABLEがどの方面から見ても良い感じ…と。
ただTABLEって難しいからなぁ…。きちんと並べていかないと。

899 ：Name_Not_Found：02/04/07 16:41 ID:SRLd2hAP

ふと思ったんだけど、「DOM的」と言うと
DOMって言う解析処理方法のうち一つに限定してしまう事になるから、
もうちょっと範囲を拡げて「XML Infomation Set的」
「XML InfoSet的」と言ったらどうでしょう。

長いね。「DOM的」の方が簡潔でいいや。

900 ：Name_Not_Found：02/04/07 18:00 ID:OUae3wZC

９００げっとぉ！

901 ：Name_Not_Found：02/04/07 18:16 ID:1UqG0Qx7

>>899
はぁ？
>>900
はぁ？

902 ：Name_Not_Found：02/04/07 18:20 ID:SGqBCalD

>>901、君はつまらん

903 ：Name_Not_Found：02/04/07 18:38 ID:1UqG0Qx7

独り言の邪魔して怒られちった。。。

904 ：Name_Not_Found：02/04/08 14:32 ID:Of542TBq

abbr要素って英語の略だけでなく日本語にも使用していいの？
例えば
<abbr title="Internet Protocol">IP</abbr>
とかはよくやるけど、
<abbr title="航空母艦">空母</abbr>
とかも良いのかな？

あと、abbr要素ってマメに付け過ぎない方がいいのかな？
例えばミリメートルの「mm」に一々
<abbr title="millimètre">mm</abbr>
なんてやってたらファイルサイズが膨大になってしまう気が。

905 ：Name_Not_Found：02/04/08 14:46 ID:1Q4it6a2

HTMLって日本語使っていいの？（藁

906 ：Name_Not_Found：02/04/08 14:55 ID:6bcrsLSh

>>904
前者は過去ログ参照。

＞abbr要素ってマメに付け過ぎない
あくまで補足説明なんだから、程々に。
少なくとも、単位につけるのは良くない。
まあ、対象と思われる読み手の何割か（ここは議論の余地アリ）が
解らないと思われる場合はつけるべきとか。

例としては、
<abbr title="Card Captor Sakura">CCS</abbr>は
このスレ的には微妙だけど、
某こみゅーん内では、ネタでない限り要らないとか。

基本的に、abbrとかkbd等、インライン要素の一部のマークアップの
やり過ぎは却って良くないと思う。

907 ：Name_Not_Found：02/04/08 15:40 ID:MgLLXy8C

一般的でない略語であって、
かつページ内で初出であるものについては
Acronym なり Abbr なりで明示的にマークアップする必要があると思われ。
それ以上にやると過剰感が漂う。

ルビ振りと似たところがあるかも。

908 ：Name_Not_Found：02/04/08 16:10 ID:SUJ7uS+U

title属性は付加情報を示すためにあるもので
すべてのabbr要素につける必要はない、
というのを他のスレで見て、なるほどと思ったことがあります。

略語にはすべてabbr要素を使う必要がありますが、
そのtitle属性は適時に用いれば良いと思います。

909 ：908：02/04/08 16:18 ID:SUJ7uS+U

後、"ミリメートル"についてですが、
U+339C(Square Mm)を使うのが、Strict的でしょうか

910 ：Name_Not_Found：02/04/08 16:35 ID:QkyC1hGo

>>905
4 以降なら使っていいですが何か。

911 ：Name_Not_Found：02/04/08 17:40 ID:vHSWnWoU

>>910
3.2 とか 2.0 でも画像とかローマ字使えば OK でしょ、「日本語」は。(w

>>909
もしかして Strict って Unicode なんすか？

912 ：Name_Not_Found：02/04/08 18:14 ID:E7+OdvDP

>>909
ズバリ「ミリメートル」を表す文字だから、
「mm」と書くより、意味は明確じゃないかな。
たとえ、表示できないUAがあったとしても
HTML4,XHTMLなら数値文字参照はUnicodeの番号と決まってるし。

913 ：Name_Not_Found：02/04/08 19:08 ID:vHSWnWoU

>>912
じゃあ、「0点」より「㍘」の方が、意味が明確で Strict なの?

914 ：Name_Not_Found：02/04/08 22:27 ID:QqxxaCkz

#x3358 は compatibility だから、また意味が違うと思うが。

915 ：Name_Not_Found：02/04/08 22:32 ID:vHSWnWoU

#x339C も compatibility じゃないの？

916 ：Name_Not_Found：02/04/08 23:49 ID:R1uAZuZJ

HTML Strict的には、
良く画像サイトにあるサムネイルとその情報はどのように記述したらイイですか？
<a href="http://www.2ch.net/" title="掲示板群「２ちゃんねる」へ行く"><img src="./2ch_logo.png" weight="10" height="10" alt="2ch logo" title="２ちゃんねるのロゴ"></a>
<ul>
<li>address:http://www.2ch.net/</li>
<li>manager:hiroyuki</li>
</ul>
か、
address:http://www.2ch.net/<br>
manager:hiroyuki
のどちらが正しいですか？

917 ：Name_Not_Found：02/04/08 23:52 ID:PHslDYJw

>>916
dl

918 ：914：02/04/09 00:14 ID:ps1L1t8R

>>915
あー、スマソ。「#x3300-#x33FF は compatibility だから」です。

"III" と "Ⅲ" だったら後者の方が、
っていうのには一理あると思うんだけど、っていう意味ね。

>>916
関係ないけど、weight ではなく width だと思われ。

919 ：520：02/04/09 01:37 ID:3WCG8zOQ

>>916

917を補足すると、

<dl>
<dt><a><img></a></dt>
<dd>画像の説明</dd>
</dl>

というのがよろしいのではないかと。

920 ：916：02/04/09 02:53 ID:GcpKzr7p

そうですか。定義ですか。
画像を定義するのですか？

921 ：Name_Not_Found：02/04/09 07:52 ID:bdJXHjUF

dlは定義だけじゃない。

922 ：Name_Not_Found：02/04/09 07:55 ID:C3Dxc5sY

XHTML2.0はどうなったage

923 ：904：02/04/09 13:29 ID:snbtl8na

レスくれた人達ありがとう。

>>922
2002年04月頃にワーキングドラフトとして公開される予定だったような
でもその気配無いね

924 ：Name_Not_Found：02/04/09 15:25 ID:a8S4a9Py

>>916
>alt="2ch logo"
は、不適切だと思われます。
このようにすれば良いかと…
alt="2ch"

925 ：Name_Not_Found：02/04/09 15:49 ID:e25z+LZN

>>923
去年の夏に公開される予定だったような。

926 ：Name_Not_Found：02/04/10 22:20 ID:H8vt5qU9

age

927 ：Name_Not_Found：02/04/11 01:57 ID:8pXCDCuA

ここにきて伸び悩んでますね

928 ：Name_Not_Found：02/04/11 03:16 ID:DikyTdX0

「ぷっ」スマのHP企画を見ての嘆きレスとかあるかと思って来たけどないね

929 ：Name_Not_Found：02/04/11 09:42 ID:NA6GLyDz

>>927
「ぷっ」スマとは一体何ぞや？
テレビは全く見ない者だからわからない・・

いつも使ってるテキストエディタがバージョンアップしたら微妙に使いづらくなった。
HTML-lintで採点のマクロがついたのは嬉しいんだが・・・
DOCタイプもuriまで入れてくれるようにメール出してみようかな（w
HTML4.01もしくはXHTML書くのに便利なテキストエディタって何かありますか？

と苦し紛れに話題を振ってみるテスト。

930 ：Name_Not_Found：02/04/11 09:42 ID:35rRujWE

そろそろ次スレの予感。

931 ：Name_Not_Found：02/04/11 09:43 ID:35rRujWE

>>929
秀丸がよろしい。
DOCTYPEの入力くらいならマクロの練習としてちょうどよかろ。

932 ：Name_Not_Found：02/04/11 10:07 ID:EQYdzx10

>>931
そうか、やはり秀丸か。
もーすぐWin自作するからそん時には秀丸かな（現在マカー）
テラパッドとかTTTエディタってどうなんでしょうか。
使ってる人います？

933 ：Name_Not_Found：02/04/11 10:51 ID:V2CJX+UG

テラパッドを使用しています。

934 ：Name_Not_Found：02/04/11 10:55 ID:Cv/LRH4L

（　´,_ゝ`）ﾌﾟｯスマ

935 ：：02/04/11 12:11 ID:ZhhmOKEb

効率良くHTMLを書けるテキストエディタってある？
ttp://pc.2ch.net/test/read.cgi/hp/1002383563/l50

936 ：Name_Not_Found：02/04/11 18:20 ID:PFx+MB85

ＴＴＴ使ってます。

937 ：Name_Not_Found：02/04/11 18:23 ID:rW5N8Yhy

StrictなHTML解説の話はどうなりました?
今はお休みで、ゴールデンウィークぐらいにヒートアップするつもりですか?
他に何か原因があるのでしょうか?

>>830
>1.基礎となるHTMLの骨格を知る(ネストの理解)
>　　DOCTYPE html head body title hn p
一番最初に解説する要素は、やはりp要素でしょうか
DOCTYPEやhtml要素は、形式的なものですから…

書いてる途中でも良いので、
HTMLファイルをUPしてください。

938 ：Name_Not_Found：02/04/11 19:02 ID:rD/IkUl9

>>937
＞StrictなHTML解説の話はどうなりました?
気になるなら自分で進めれ。俺はﾏﾀｰﾘやってるよ。

＞>1.基礎となるHTMLの骨格を知る(ネストの理解)
＞>　　DOCTYPE html head body title hn p
＞一番最初に解説する要素は、やはりp要素でしょうか
＞DOCTYPEやhtml要素は、形式的なものですから…

title要素が最重要と言う識者もいらっしゃいますなｗ

939 ：茶文字 ◆xELvisFU ：02/04/11 20:04 ID:PRWxIIf8

解説サイトの話が進展しないのは私の腰が重いのが大きいな。
ちょっと理想を追いすぎているのか、書いては消し書いては消ししてます。
乱雑な状態でもいいからうｐしちゃうかなぁ。

で、とりあえず他の話を振ってみる。
ttp://www.oosakaya.net/me/12.html
ここの記述ってどう感じますか？

940 ：Name_Not_Found：02/04/11 20:31 ID:hCi7GqTb

>>939
> www.oosakaya.net/me/12.html
漏れなんかは HTML は汎用的な文書フォーマットだと思ってるから、LINK 要素って
本文の流れを不自然にするナビゲーション目的のテキストを
body の外に出せる機構として洗練されてると思うんだけど
著者にとっての HTML は、ブラウザに表示させてなんぼで
それが全てなんだろうなあ…と、そんなことを思った。
ブラウザにとらわれすぎている感じがする。無理もないけど。

>うｐしちゃうかなぁ。
いいんじゃないかなあ。どっちにしろ書いては消し書いては消しするでしょ。

941 ：520：02/04/11 20:35 ID:nvv5Y+zm

>>939

> HTMLの仕様書が正しいのかどうか、現在の状況に即した仕様書であるかどうかは、だれも考慮していません。

とか、

> 日本人であること

とか、話の進め方に粗が多く、脇が甘い。
（いわゆる、ツッコミどころ満載というやつ）
まあ、言いたいことはわからないでもないけど。

ただ、将来LINK要素によるナビゲーションが使いやすい形で実装されたブラウザが
普及する可能性と、たかだか数十バイトの情報量を秤にかけたら、たとえ、
その可能性がどんなに低くても、俺は前者をとります。

942 ：Name_Not_Found：02/04/11 20:50 ID:dmU4caF4

Mozillaはどうした、と思ったら1年半前の文書だった

943 ：397：02/04/11 20:52 ID:rW5N8Yhy

>>298, >>399
皆さん、お忙しそうですね。
私も、皆さんの議論に参加できるようにものすごい勢いで勉強します。

944 ：Name_Not_Found：02/04/11 20:54 ID:vNoKX1Ck

>>939
>W3Cの策定した仕様書（勧告を含む）が絶対的正義なのか？
　絶対とも正義とも全く思わないが（というか、何処からそんな概念が出てくるか疑問）、
少なくとも同程度の対案がないなら W3C の規格を使用し、人に薦める事に何ら抵抗はない。
　それなりに考えがあって pdf 使うし薦める、と言うなら「違う道を歩む人」って事で認められるんだが。

>結局のところ、これらはLynx依存の属性値であるということができます。
　完璧な誤認。
　俺の場合、Mozilla は勿論、IE にも javascript を仕込んで link 要素から
ナビゲーションを生成し、ショートカットキーを割り当てているので、
（本来有るべき）link 要素が存在しない site は大変に不便。

>ただの特殊ブラウザに成り下がったLynx
　ナニをlynx に拘っているのか今ひとつ不明なんだが…。
　５年、１０年たてば、現在の IE や Mozilla だって「過去の特殊なブラウザ」
に成り下がる訳で（１０年で足りなければ別に２０年でも可）特定のブラウザを引き合いにする事自体ナンセンス。
　特定の概念は古い、というなら理解できるが、link 要素って実装レベルで言えば寧ろこれからの概念じゃないかと思うのだが。

>　こうしたごく限られた人の利便性を考えるくらいの心の広さがあったら、
>99％以上の人にとって無駄でしかない部分のソースを削るということも
>考えた方が有用だと思われるからです。
　lynx が滅ぶのと、無駄なソースが減って有用な環境が滅ぶのと、どっちの方が早いか疑問。
　PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。

945 ：Name_Not_Found：02/04/11 22:03 ID:KajNWHfG

>>939-944
> 執筆日：2000年 9月 8日
↑おまいらここを見てくださいおながいします

時代遅れのリソース

946 ：茶文字 ◆xELvisFU ：02/04/11 22:09 ID:PRWxIIf8

>>945
記事が古いことは承知の上なんだけど、現に閲覧できるリソースなわけで。
で、944までのレスを見て、特定UAの表現に基づいて論評するのは
できるだけ避けた方がよさげだな、と思った次第。
だって執筆辞典でHTML4.01は存在したわけだからね。

特定UAの表現について触れるなら、バージョンアップをきちんとフォローするのが
筋じゃないかと思いまひた。

947 ：944：02/04/11 22:13 ID:vNoKX1Ck

>>945
>PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。
の一文は不適切だったので取り消します。
　当時の移動体通信の速度と価格を思えば、数バイト削るのが意味がある時期は（過渡的だが）確かに有った。

＃しかし、strict という思想は勿論、XML も XHTML 1.0 勧告された後に
　しちゃナンセンスなので、全体的な批判の姿勢は維持。

948 ：Name_Not_Found：02/04/11 22:42 ID:hCi7GqTb

>>946
> 特定UAの表現に基づいて論評するのは
> できるだけ避けた方がよさげだな、と思った次第。
同意するとともに、そこが難しいところだとも思う。
いっそ XML+CSS とかだとデフォルトのスタイルとか振る舞いは無いも同然だけど
HTML は既成事実的なデフォルトスタイルがあるからねぇ。

949 ：Name_Not_Found：02/04/11 22:44 ID:j89rgHXY

数年前ですと、「将来賢いUAの登場に期待して」な論調だったのが、
最近は鳴かぬなら鳴かせて見せようホトトギス的に、今ある要素を
有効に使おうという風潮が少しずつ出てきてますよね。
（その典型がCSS切り替えスクリプトとか、そふぃあさんところで
いろいろやってる実験的なこととか。>>944氏もそうですか。）

そういう動きがあることをコラムのような形でいいので、触れることをきぼんぬ。

そうすると、>>939のサイトのような認識は減ると思うのねん。

950 ：Name_Not_Found：02/04/11 23:18 ID:eT5XPw6+

>>939
なーんか重箱の隅を突付きまくって自己満足してるだけのように見えるな。

951 ：Name_Not_Found：02/04/12 01:10 ID:2KgjBwiW

>>950
その参照は誤読を招くぞ。
次スレ立てる？

952 ：Name_Not_Found：02/04/12 01:29 ID:wkgJXmz8

>>951
おながいします。

953 ：Name_Not_Found：02/04/12 01:42 ID:CVdfclL8

>951
今の進行具合なら970-980くらいまで待ってもいいんじゃない？

954 ：950：02/04/12 03:55 ID:Bf/SYcF4

>>951
ああ確かに。>>950は>>939のリンク先の文書に対してね。
コテハン叩きの私怨厨と思われるのは勘弁です。言葉足らずｽﾏﾝ。
次スレはギリギリまで使い切って立てたほうがよろしいかと。

955 ：944：02/04/12 20:25 ID:M7F5Db7n

>>946
>特定UAの表現に基づいて論評するのは
>できるだけ避けた方がよさげだな、と思った次第。
　特定UAを前提にされると困るが、HTML を人間が閲覧する場合
UA が仲介する事は HTML の前提なので UA の話は是非とも
盛り込んでください。

　lynx なんて過去の特殊UAだ。だから lynx しか使わないような要素は要らない

ではなく、

　過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。

といって欲しいのです。

>>948
>HTML は既成事実的なデフォルトスタイルがあるからねぇ。
　実際の UA には UA のスタイルシートをユーザースタイルシートが上書きするので、
（例えすべてのUAのスタイルシートが統一されていたとしても）UAのスタイルシートに
頼った記述はするべきではないと思われる。
　勿論 CSS をこれから学ぼうって人に「すべて理解してから、UAのスタイルシートに
頼らない CSS を記述せよ」といっても無理なので、ここら辺は最初に設定のカスケード
に付いて説明するとき、コラムか何かで解説すべきではと思います。
「例え transparent でも color と一緒に background を設定した方が良い理由」
なんかを具体例に出すと解りやすいのでは。

＃蛇足だが、CSS のデフォルト値と明確に区別するため、今後デファクトスタンダードと
　言ったほうがより良いのでは？

…微妙にスレ違い。失礼。

956 ：Name_Not_Found：02/04/12 22:03 ID:IOzbhvFy

>>955
> 過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。
特殊 UA という発想はマズイのでは。
Mosaic 系の UA は多くの人に受け入れられたけれども、
それはHTMLブラウザの一形態であって、別に普通でも何でもないので。

ちなみに漏れの考えでは UA の仲介は HTML 閲覧の前提ではなかったりする。
プログラムに通すだけならテキストである必然性がないと思うので。
マークアップがテキストで行われ、要素名や属性名がその意味を表す単語の略記である理由は、
ソースをそのまま人間が閲覧することも想定しているからだと思う。
現にそうやって作成するわけだし。
その閲覧を補助するものとして UA があり、
要素ごとに規則的な整形を行ってそれが何の意味を持つのかを明示したり
ハイパーリンク指定でリンク先リソースを自動で GET したりする、と。

だから、特定 UA の挙動を前提にしたマークアップや
ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。

957 ：955：02/04/12 22:44 ID:M7F5Db7n

>>956
>特殊 UA という発想はマズイのでは。
　>>939 からの流れで特殊といってしまったが、たしかに今現在スタンダードでは
ないというだけで、「特殊」という言葉を使うべきでなかった。失礼。

>プログラムに通すだけならテキストである必然性がないと思うので。
　そうか？　じゃあ、javascript などのテキストのインタプリタ言語なんかは
人間”も”解釈する性質のものなのか？
>ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
>そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。
　これには激しく同意なんだが、テキストなんだから人間「も」読むちゅうことはない。
　HTML がテキストであるのは「書く時・編集する時」に特定エディタを必要としない
（つまり製作環境を限定しない）為であって、「読むとき」の都合ではないはず。

　確かに俺は必要に応じてソースも閲覧するがそれはUAが解釈できない間違ったHTMLを
仕方なく解釈したり、ヘタレ UA の機能不備やbugを補うものであって、
HTML（というか SGML）の規格そのものは閲覧時に何らかのプログラム処理を前提に
していると思うのだがどうだろうか。

958 ：Name_Not_Found：02/04/13 01:15 ID:E1tKQxbT

>>957
SGMLはどうだか知らんが、HTMLはハイパーテキストあってのものなのだから
ソース読ませようとして作ってはいないだろう。

959 ：茶文字 ◆xELvisFU ：02/04/13 01:40 ID:kPHIgrYX

ソースの可読性というと各要素を脳内変換してレンダリングしているような印象があるですな（ｗ

>>958の意見に概ね賛成なんだけど、ドキュメントがワープロの書類みたいに
バイナリではないということが重要なのかな。
UAだけでなく、人間が見てもそこそこ解釈が容易ですよ、と。

言い古された話だが、ファイルタイプがtextであるということはかなり恩恵がある。
さまざまなプラットフォームからの利用が容易だし。
表示結果だけでなくソースそのものに二次利用性が高まるし。
特別な環境がなくても開発が容易だし。
UAやオーサリングツールのI/Oも楽に作れるし。

人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
だから可読性の一面はあくまで副産物だと思うわけ。

960 ：Name_Not_Found：02/04/13 01:40 ID:fT68ffwZ

>>958
> HTMLはハイパーテキストあってのものなのだから
が激しく不可解だが、

これは別に企業サイト向けの(糞)Webデザイナー向けの
レファレンスを作る計画じゃないんだろ？
ならUAへの言及は必要なし。バグｽﾚに既にまとめてくれた方がいる。

961 ：Name_Not_Found：02/04/13 01:44 ID:fT68ffwZ

書いてる間に茶文字氏が・・・。
>>959
> 可読性の一面はあくまで副産物
に激しく同意。

・・・てか何で人間の読みやすさなんて事を言い出したﾔｼがいるんだろう。
某方面に触発された厨の影響か(w？textであることの利点は>>959の
第2段落に要約されてる。

962 ：961：02/04/13 01:47 ID:fT68ffwZ

s/第2段落/第3段落/g;

963 ：茶文字 ◆xELvisFU ：02/04/13 02:16 ID:kPHIgrYX

>>960
958は s/ハイパーテキスト/ハイパーリンク/g; だと思われ。
で、HTMLの最大の長所(のひとつ)であるハイパーリンクを有効活用するには
いわゆるブラウザを通した方が恩恵にあずかれるので、
HTMLはUAに食わせるためにあるのだ、という意見だと解釈しまひた。

UAの実装状況は詳細には必要ない気がするね。
わかりやすいリソースがあるならリンクさせてもらった方が早い。
が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。

964 ：958：02/04/13 02:34 ID:E1tKQxbT

>>963
その通り。
威張る所じゃないけど。誤記スマソ。

965 ：Name_Not_Found：02/04/13 11:40 ID:x9xVATi5

>>963
> が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
> UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。

激しく同意した上で．
初心者向けの解説と言うことであれば，
むしろそのような切り口の方がわかりやすいような気もします．
「論理マークアップ」とか言われても，初心者にはﾊｧ?でしょうし．

「Aというブラウザではh1要素はでかい字になるけど，Bではセンタリングされるんだよ．
　それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
　HTMLとはそういうもので，だから，<ここはでかい字にするよ>ではなくて
　<ここは見出しだよ>にするんだよ」

って持っていき方の方がわかりやすいんじゃないかと，個人的には思ってます．
激しくガイシュツの感ｽﾝﾏｾﾝ

966 ：Name_Not_Found：02/04/13 17:15 ID:hG4eFl4J

>>965
大筋は正しいと思うけど、
>それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
ってのはちょっと違うかなと。
フォントの大小とか除けば、要素に対してセンタリングとかまで見た目を
変えられるUAは余りない。余りというか、最近のWindows用視覚系UAで
は見たことない。
IEとかOperaでユーザーサイドのスタイルシート使えば別だけど、初心者
むけの解説でそんな事書いても仕方ないし。

「それぞれの環境で表示のされ方は違うので，どんな人にでも意味が伝わるように，
<ここはでかい字にするよ>ではなくて<ここは見出しだよ>にするんだよ」

位が適当かと。

967 ：956：02/04/13 18:11 ID:5RJkYSuH

>>959
> 人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
> だから可読性の一面はあくまで副産物だと思うわけ。
可読性があるからそれらのメリットが得られるのだと考えていた。
HTML が機械処理を想定してないと言うつもりは流石にない。
# 引っ張るつもりは無いのでレス不要っす。

>>966
過去のものなら、 Mosaic がフォント設定を要素群単位でやってたよね。
# で、設定しないと日本語表示できなかった(w

初心者向けの解説にこそユーザースタイルシートって必要なんじゃないかなあ。
自分が利用しやすいように HTML をカスタマイズする、という発想は
与えられた利用法しか考えたことがない初心者にとって有益ではないだろうか。

968 ：967：02/04/13 18:15 ID:5RJkYSuH

> HTML が機械処理を想定してないと言うつもりは流石にない。
誰もこんなこと言ってないね。この行あぼーんしてくださいな。

969 ：茶文字 ◆xELvisFU ：02/04/13 18:43 ID:UodJk+h0

初心者向け解説、アウトラインから書き直しつつがんがって執筆虫でございます。
脳味噌沸騰しそ……。

# HTMLってそれぞれの要素や属性が立体的に関係しあっているから
# 順序立てて語るのは難しいっすなぁ。

>>967
ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
卒業制作くらいの感じで位置づけてみようかと考えてますが、諸氏のご意見やいかに。

970 ： ◆R6s1MqxQ ：02/04/13 21:27 ID:kDEPqMf4

>ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
　テンプレート的 CSS を幾つかダウンロードできるようにしておき、
実際使ってみてもらう、というのはどうでしょう？
　中身は全く解らなくても、ユーザスタイルシート（ひいてはスタイルシート全般）を
使うメリットの大きさや、HTML からプレゼンテーション要素を追放する理由をとりあえず
実際に体験してもらうって事で。

971 ：520：02/04/13 21:46 ID:ZnrxT3eQ

>>970
で、そのテンプレート的スタイルシートの中に、
デザインが格好良いのとかだけでなく、やたら字が大きくてくて
眼にやさしいスタイルも用意しておいて、
「見栄えをCSSに分離しておくと、弱視者やお年寄りが、自分用にこういった
スタイルを適用したりもできるんですよ」
みたいな説明があるとアクセシビリティ的にもOKだと思うのですが、いかがか。

まあ、ユーザスタイルシートに関する具体的な説明は後の方でいいと思うけど。

972 ：520：02/04/13 21:49 ID:ZnrxT3eQ

>>971
大きくてくて……鬱だ。

さすがに残り20切ったんで、
そろそろ新しいスレ立てた方がいいと思うんですがどうでしょう。

973 ：茶文字 ◆xELvisFU ：02/04/13 21:55 ID:UodJk+h0

>>972
酸性
次は4.01とかになったりするのでせうか？

974 ：Name_Not_Found：02/04/13 22:00 ID:Ej7sv4yU

>>973
3.2 だべ。
では、 980 取った人が新スレ作成当番ということで。

975 ：茶文字 ◆xELvisFU ：02/04/13 22:01 ID:UodJk+h0

>>974
げ　それでは今スレの議論はあぼーん扱いになるのですか？（ｗ

976 ：Name_Not_Found：02/04/13 23:29 ID:QyHb4/6p

> テンプレート的 CSS を幾つかダウンロードできるようにしておき、
> 実際使ってみてもらう

これは面白いと思うね。百聞は一見にしかず。
「フォントいじりサイトスタイル」や「テキストブラウザスタイル」のユーザースタイルシートとか、
あれば面白く理解できそう。

977 ：520：02/04/13 23:39 ID:ZnrxT3eQ

>>976
興味をひいたり、いろいろなことができるのを知ってもらという意味では、
「有名サイト風スタイル」というのもいいかも。
ただ、HTML入門の最初の頃に提示する場合は、あまりclass属性やid属性に
たよった作りのスタイルだとマズかろうから、floatとか使いづらいのが難だけど。

978 ：Name_Not_Found：02/04/14 01:36 ID:jlaBYmNj

うん、letter-spacing や line-height が使えるのは、
CSS の強みだしね。

letter-spacing や line-height も全部同じ値なら良いかと言えば
そうではなくて、フォントに依って、特定の値の合う合わないが、
あるんだよね。

例としては、Strict 的ではないけれど、
MS UI Gothic に letter-spacing: 0 は合わないとか、
「有名サイト風スタイル」も良いけれど、
ここら辺の微妙な感性に訴えるのも面白いと思う。

979 ：520：02/04/14 02:37 ID:6L4e5UvJ

>>978

> MS UI Gothic に letter-spacing: 0 は合わないとか、

でもそういう設定をすると、MS UI Gothicを表示できない環境だと、
letter-spacingに設定した値だけが適用されて、イヤンな感じになりませんか？

って、Strict的ではない話を続けてすまん。

980 ：520：02/04/14 02:44 ID:6L4e5UvJ

つーわけで、新スレ立ててきました。

http://pc.2ch.net/test/read.cgi/hp/1018719800/

981 ：978：02/04/14 02:57 ID:jlaBYmNj

>>979
一般化して考えても、san-serifなフォントで、
letter-spacing: 0 は読み難い気もするんだけどね。

MS UI Gothic の場合は、letter-spacing: 0.3emがベストだと思うけれど、
通常のsan-serif、つまり Mac で一般的な Osaka や
WinなＭＳＰゴシックは、
letter-spacing: 0.1emで上手く行く気がするし。

まあ、でもここらは色でも違うかな。
そこら辺が微妙なんだね。だからこそ、面白いというか。

982 ：981：02/04/14 02:58 ID:jlaBYmNj

おお、新スレが建っていた。