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

この質問は、こちらでいいのかな……。
表全体の幅は任意として、表のセル幅を各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スレッドの方ならご存じではないかと思って、
テーブルの幅計算の原理とそれへの対処法をお訊ねする次第です。

>>373
スレ違いもいいとこだが table-layout: fixed でどうよ。
次からはここで聞け
http://pc.2ch.net/test/read.cgi/hp/1015474859/l50

>>373
どの要素についてもそうだけど、 HTML4 では
「正しいレンダリング方法」というのを特に定めない。
表のレンダリングについて仕様で触れているのは CSS2。

>>374
table-layout: fixed;は意味がありません。
表全体のwidthが指定されてないと固定レイアウトでなく自動レイアウトになる筈ですから。

HTMLのことでもあるのでこちらでお訊ねしたのですが、「スレ違い」でしたか。
ではご推奨の「CSS、スタイルシート質問スレッド」にて訊くことにします。

>>316
0.4秒ほど速くなった気がしないでもありません。ｵﾂｶﾚｰｯｽ

strictなアダルトサイトってどうなの？

>378
ソースきぼーん

>>378
見てみたいな
けど、Strictだとしょぼいアダルトサイトになるのは明白

>>380
しょぼいかどうかはともかく、ノーマルなものではなさげだ。

…つーか、そんな印象を持ってしまうのも某方面の罪か？

エロ動画とかはアプレットだろう？
objectなんてだめだろうし
あとエロ画像のalt=""にはいる値は
見ると笑えそうだ

<img src="rori.jpeg" alt="ロリロリフェイスが乱れまくってる画像">
とか？（ワラ

>>382
w3mでも十分抜けるように。

<img src="image/sex1.gif" alt="腰使いが激しいセックス動画" width="400" height="450">

動画gifバージョン

えっと・・

会社の先輩（SE）
にホペのフォントにHG性楷書体-proを指定していたら
UNIXとか考えたらserifだけがいいとか言われたんだけど
そうなん？そういや鳩丸もむかしいぱーいフォントを指定してたのに
いまぜんぜんないし・・・やっぱだめなのかなあ・・・

>>385
「serifだけ」にするのはIEのバグなどもあるしあんまり宜しくないのでは。
CSSの仕様では「無いフォントは無視する」ことになってるから、
font-face: "HG性楷書体-pro" serif;
としておけばオールオッケーなはず。

>>384
むしろ PNG か SVG だな。

>>378
萌え系エロアニ画像とかならだれかやりそう(とかいう

validな掲示板ってどうよ？
プチボベースなんだけど。

つーか、画像を大量に使う時点でStrictにする意義はないと思う。
UAがかなり限られるからね。

文字だらけの2chこそとりあえずStrict化を推し進めねば

>>390
ハァ('Д')?

どんなサイトでもStrict化することに
意義はあると僕も思うな

私にとって、Strictは目的じゃない。
目的が先にあってStrictにするだけ。
目的とは、情報の二次利用性をとかアクセシビリティーを高めるとか。
んで、どんなサイトもStrict化することによって何らかの恩恵はあるはずだと思う。
その意味で、393に禿同。

objectの実装がまだまだだとか無料鯖で広告が出るからとかの理由で
しかたなしにTransitionalを宣言することはあるだろうが、
極力Strictに近づけるような努力はあっていい。

>>395
無料鯖で広告がでるからDOCTYPE宣言をコメントアウトにしているサイトに
lintかけてよろこんでいるNozをみたことある。

そしてのぢたんは広告が挿入されて
invalidになってるにも関わらず
そういうページにDOCTYPE宣言をつけてよろこんでいる

>394
アダルトサイトなんて毎日目まぐるしく更新されて
そしてその殆どが交換バナー。

それでもそうすべきか？
# 実際誰もせんだろうが

>>392
テキスト系のUAは無視だろうがゴルア
となると、Strictにする意義はほとんどなくなるんじゃねーか？
てめーはどう答えるよ？
頭悪い?

>>395
＞無料鯖で広告がでるからDOCTYPE宣言をコメントアウト

なんか意味あるの？

>399
ちくるとあぼーんされる

>>398
つまり、Strictにする意義はテキスト系UA対応にしか無いと言う訳ね。

>>388
画像主体なら文字 UA 切り捨てはある意味必然。strict 云々は無関係。
文字の代替である画像と、画像としての画像では意味が違う。
strict なら前者は補える、というのは strict の数多ある利点の「一つ」。

>>399
DOCTYPE 書いても不正　書かなくても不正

>>400
コメントアウトは広告でなく DOCTYPE の方

obsolete

↑Strictなあぼーん

<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的に改善するところがあるでしょうか？

機能としては……

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の負荷が軽くなります。

>405-406
まずはlintでチェックしましょう。例えば
ttp://openlab.ring.gr.jp/k16/htmllint/index.html
の「ゲートウェイサーヴィス」

ちなみに、<EMBED>はStrictでは（というか、Transitionalでも）致命傷です。

>>399
意味はないと思う。強いて挙げるならば広告が付かなくなったとこに
移転するときのための自分へのメモなんじゃないかと思われ。

のじって全然わかってないじゃん。

>>409よりはわかってるだろうがな

>407
objectすかね

>>406
属性は""で囲め。

Strictの考え方がわかりません。
Strictの考え方を勉強するにはどこへ行けばいいでしょう？

自分はコミューンの日記を片っ端からブックマークして
毎日 ROM ってる。

>>413
w3c でも逝っとけ、と言いたいところだが、
まぁいきなり英語を読むのもナンなので、
これでも全読すれば。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/cover.html

>>414
コミューンの日記読んでもStrictにはならん様な。

コミューンの日記読むとはにゃーんとなれる。

>>417
それは禿同

>>415
仕様書読みを奨めるのはいいことだが、

>Strictの考え方を勉強するにはどこへ
という趣旨で、

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

Strictじゃないんだけど一応validではある掲示板
ショボくてごめん
http://yuuki.s8.xrea.com/cgi-bin/

参考リンク
ttp://www.hogehogehoge.com/


みたいなのはどんな感じでやれば良い？

>>421 DL要素

>>421 意味わからん…。

>>422

<dl>
<dt>参考リンク
<dd>ttp://www.hogehogehoge.com/</dd>
.
.
.
</dl>

ってことですか。サンクス

>>423
すみません。略しすぎました....
要するにリンクの説明をURLの上方に書いてその下にURLを....ってこ
とです

あ、dtだけ省略してしまった

友人とアダルトサイト作成してますけど、私はStrict指向なので一応Strictで記述してます。まぁ、優良サイト目指しているので広告が少ないからこそ出来るんでしょうね。
でもやっぱりデザインに苦しむ、、、。(苦笑)CSSの勉強が足りないなぁ。

>>426
いいっすねぇ。その心意気。

> 広告が少ない
広告バナーより Valid アイコンの方が多い
アダルトサイトをきぼーん。

(・∀・)ｶﾞﾑﾊﾞﾚ!

>>426
激しく応援。スポンサーもいっぱいつきますように。

・・・ま、validのバナーは貼らなくてもいいけどな。

Validバナーは私も昔得意げな顔して張っていたけど
いまはずしたよ

validバナーは、過去の切片の正しさを保証してるだけで、
未来的によいとか、思想的によいとか関係ないしね。

うちはソレもネタの一部だしなぁ（笑

>>431
いやいや、うしはOKっす（藁

・・・でもアダルトサイトにそれを見つけると萎えると思ったんだYO...

Validバナ―はHTMLを教えているようなサイトならあってもいいとは思うが、通常のページだとStrictで書いたのを自慢してる気がして気持ち悪く感じる。＜俺の場合ね
謙虚でStrict即ちこれ最高

なんで2が上がってるんだ？ってことであげ

理想論者風に言えば、Validなhtml書くのは当然といえば当然であって、
Validバナー付けるのは、アメリカ人が額に「英検一級」と書いて歩いてるようなものではないのか。
（ネイティブでも英検一級って難しいらしいけど、そこはここでは無視）
電卓に「割り算できます」と書いてるようなものではないのか。
と考えたんだけど、JISマークみたいに、利用する人が安心できるって言う面もあるかなとも考えてみたり。
啓蒙にもなると思うし。

でも個人的には何か照れくさいし「Validでっせ」は出来ないです。
もし設置するなら「about」とか「help」なページだけにすると思う。

>>435
俺は啓蒙厨なのでTOPのみValidバナー貼りつけ。
アクセス数は6hot級(アクセス解析してないから詳細は不明)だけど(ﾜﾗ

ちょー遅レスだが前スレの854 "HTTP://WWW.2CH.NET/"は
別にまずくないだろ。DNSのRFCでドメイン名の大文字小文字を
区別しないことは規定されてる。これを区別するサーバはありえない。
まあ言いたいことは分かるけど例がまずいよ

>>437
スキーム部は小文字じゃないとまずいでしょ。
……まぁ、RFC2396（だったか？）に「大文字を小文字とみなすよう、融通を利かしてもよい」とは
書いてあるけどさ。

validバナーって何ですか・・・？
最近Strictなどを調べ始めたんですが初めて聞きました。
厨な質問スマソ・・・でも教えてﾎｽｨ…

>>439
http://validator.w3.org/images/vxhtml10
こういうの

>>440
即レスサンクス。
これのことか〜
433と同じく解説サイトでもないのに貼ってあるサイトは自慢くさくて萎える。

・・・外そう（ｳﾂ

>>442
いいんじゃﾈｰﾉ?少しは啓蒙になるだろ(w

「ほーむぺーじ論」より。
http://www5b.biglobe.ne.jp/~nitti/hp/concept/concept11.html
W3Cの宣伝広告を貼ると優越感と自己満足に浸ってしまい、
制約も増し、肝心の内容も薄くなるのでやめた方がいいそうです。

>>444
煽るつもりはないけど、
> やめた方がいいそうです
という書き方に主体性のなさを見た。

その通り、自分のサイトで何がしたいかわからないﾔｼは
validバナーどころかサイトを作る必要なし。

>>444
「だいたいそういうサイトに限って、
コンテンツが薄かったりするのは気のせいでしょうか。」

なるほど．．．。
てゆうか、nozたんに斬って欲しい。

>>446
すでに斬られ済みだったとｵﾓｰﾀよ。そのサイト。

>>445
＞> やめた方がいいそうです
＞>という書き方に主体性のなさを見た。
うん。恥ずかしながら俺本人はとくに賛否の意見を持たないので。
一般的にはマイナスイメージで受け取られる可能性もあるのでは？という。

>>446
すでに対話済みのよう。そこの著者は現在加筆訂正中とのこと。
http://cgi.www5b.biglobe.ne.jp/%7Enitti/cgi/board/board.cgi

バナーを貼っても意味が無いから止めろというなら「Copyright (C)（略」
等の表記も意味が無いのではないのか

>>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% }

>>449
意味が無いと云うか、いらないと思われ。
まぁ、別に書いても害は無いと思うけど。
http://white.sakura.ne.jp/~quia/tech/html/meta.html#copy

>>451
Validバナーも同じようなものではないのか

Validバナーを外して6hotバナーを付けよう

>>449
表記しないと認められない国への対策にはなるんちゃいまっか。

>>Copyright ©
万国著作権条約に加盟していながらベルヌ条約には加盟してない国に対しては有効。
つっても4カ国しかないらしいけどね。
どっちにも加盟してない国が相手なら何を書いても無意味ではある。
そのへんわかった上で書いてる人は、「自分はこのコンテンツについて著作権を
主張するぞ」な意思表示という意味合いが強いみたい。
# ちなみに©は(c)で代用できるものではない。
# んで、制作者名と制作/加工年がセットになってはじめて有効。

validバナーは「それがあれば安心して閲覧できる」っつー保証になるかというと、
実際はブラウザの実装がタコでCSSが原因で落ちたりするケースもあるから
これまた頼りないことこの上ない。
ま、validバナーがあるHTML/XHTML、CSS、JavaScriptなんかの説明サイトは
その内容を信頼していいかなって気にはなるかもね。

Validバﾅｰ云々、内容薄いとか意味ないとかのやりとり・・・。
どっかで見た流れだと思った
らFlash。

そういや思い出したんだけど。
validバナーってHTMLとCSS並べたときに片方は透過されてて片方はされてなかったような。
自鯖使った一時的なコンテンツで貼ってみたことがあるけど、
デザイン的にももひとつなんで好んで使う気にはなれん。

©と(c)はどう違うのだろう。

>>458
ソース見れ。

>>459
どう使い分けるのだろうっていう意味じゃないのかなあ。
©だと見られないブラウザがあるんだとかで、(c)にする人が。

>>458,460
万国著作権条約で保護されているのが©だけなので、(c)は法的効力がないです。
国内法的にはあってもなくても作品が成立した時点で著作権が発生するんでいいんですが。

この論に立てば、ブラウザが©を表示できないからといって
(c)で代用するのはなんかずれてますな。

んで、仮に©をつけていたとして。
パクった側の環境がこれを表示できず知らず知らず権利を侵害していたとしたら、
司法的には「不知」つまり意図的な不法行為とは言えないわけで無罪放免になるかもですが、
それ以降はそういう言い訳が通用しなくなるわけですから(一旦司法判断が出た以上、
それ以降も被告が「不知」でありつづけるわけにはいかなくなる)
どのみちコンテンツの変更を余儀なくされるでしょう。

いずれにしてもStrictと直接関係のある話ぢゃないですな。

>>460
alt="Copyright "でイメージという手はどうだろう。

>>462
それいいと思う
よく見かけるし
Strict的にどうだろか？

>>463
「Strict的に」というのは、「特定のUAへの対応をしない」というのと同義。
依って、&copy;以外には無いのではないかと。

©に対応しないUAってどんなのがあるの？
Strictサイトを管理してるので知っておきたい。
まぁ、対応しないからといって(C)に変更する気は無いけど。

ﾉｻﾞｷﾀｿが(C)を使っているとはこれいかに

あと、とほほも使用してますよね。
国内なら(C)でも問題無いんでしょうね。
つか、うちゲームサイト……©すらいらないかも）ｗ

>>467
既出だが一部の国以外ならなら無くていいだろ

>>459
すんません、言葉足らずでした。

>©は(c)で代用できるものではない。(>>455)
に引っ掛かって、どういう意味だろうと思ったんです。

>>461
解説ありがとうございます。全然知りませんでした。
自分は何となく©を使っていました。

「ただしコンピュータ上に限っては(c)でも可」という話を聞いたことがあるんだけど。
デマだったのかな？

>>465
対応状況ではないけれど、 &copy; は HTML3.2 以降で使用可能。
http://www.w3.org/TR/REC-html32#latin1

> ©は(c)で代用できるものではない。
保護されているのが©だけ、というのが事実でも、
それ ASCII にないじゃん、という話はあるだろうね。
ブラウザで表示できないとかいうよりも、プレーンテキストを保護できない。
実際、 © をクリップボードに入れた時の内容や
ブラウザへの出力自体が (C), (c), c になる UA もあったりするわけで。

ついでに。
© は HTML2.0 の文字実体参照には定義されていないけれども
文書文字集合には含まれているので
&#169; とすれば HTML2.0 でも使用可能なはず。

どう表示されるか、ではなく、
「ソースに"&copy;"と書いてある」
ことに意味があるのではないかと思った。

"&#169;"も(w

海外サイトの文字コード未指定になってる HTML で
デフォルトが Shift_JIS のブラウザで見たときに(あるいは自動判別でSJISとみなされて)
"Copyright ｩ" となってるのをｶﾅｰﾘよく見かけるんだが、
そういうのは効力あるんだろうか？

>>475
つまり表示上の問題なのであって（特定UA云々の話題といっしょ）、
>>471-474でいいんじゃないのか？

関係ないけど、少し前のバナーの話題で。神崎氏のリソースの
ステータスのとこにあるXHTML&CSSの表示、つい今さっきまで
画像ﾊﾞﾅｰだと思っていたよ。鬱・・・。漏れもこれ真似しようかな。

>>476
&copy; とか &#169; の場合は表示上の問題だよ。
SGML 宣言で指定された文字集合から参照する文字だから。
でも ｩ の場合は表示上の問題じゃないよ。
文字コードが明示されているのでない限り、違う文字であることが充分に考えられる。
その時に ｩ が &copy; として効力をもつかどうかってのを
文脈とか常識的な判断といった曖昧なものを基準にしちゃうんだろうかと
素朴に疑問を感じたんだよ。

# ずっと名前欄に数字入りっぱなしﾀﾞﾀｰﾉｶ
>>477
検索したら日本のサイトにも＜ゥ

Content Negotiationでもって避けられるとは思うが、
実際に"ゥ"になっている場合の法的効力はわからん。
何かソースを探そうと思ったが・・・実際それが問題に
なったことはないだろうから、見つからないだろうなぁ、ｳﾄｩ。

次のような法律や条約において、

第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>
･･･
と、するべきなのか、
私は迷っています。

>>479
漏れだったら dl 使うけど。
文章の一部だと思うなら、少なくとも
list-style-type: decimal; は無しじゃないかなあ。

>>479
常にスタイルシートが無くても意味が伝わる様に考えないといけない訳で、
そうなるとol要素は有り得ないと思う。

ul要素がダメだというのならば、
>>480の通りにdl要素でマークアップすべきではないかと。
まあ、理想はul要素でマークアップ出来る様に、
文章を再構成する事じゃないかという気もするが。

>>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;}

リストのマークアップの表示結果が
結局スタイルシートに依存してしまうから問題なんだよな。
俺も>>482と同じでdlはおかしいと思う。

どうしてもスタイルシートに依存しないで
第一項、第二項と表現したいならひょっとすると
tableも視野に入れて良いんじゃない？

>>480-483
皆さん、私をさらに混乱させてくれますね。
みんな意見バラバラで、頭痛い〜
私も考えているんですが、まだ結論出ません。

みんなの意見、ありがとう

文書中に1.,2.が表れない点でolを蹴る。
1や2がdefinition termでない点でdlを蹴る。
ulを推したいが如何>>486

最近のW3Cの勧告ってToCでulの中身に番号振ってるんだよね。
これって音声ブラウザの代わりのスクリーンリーダがolに対して
いまいちな読み上げしかしないからだけど。

>>487
ol は入れ子になるとややこしいから、
ul にして生のテキストに番号を書け、
ってのが WAI にあったような。

>>488
うん、それ。
その「ややこしい」理由が>>487に書いたスクリーンリーダの話。

>>486-489
なるほど、ulですね。
もう一度、考え直してみます。
ありがとうございます。

<p></p>は段落ですよね。
<blockquote></blockquote>は引用ですね。
blockquoteをpタグ（要素？）で囲むと間違いで、
pタグをblockquoteで囲むのが正しいみたいなのですが、
なぜですか？　<blockquote>aaaa</blockquote>この引用は
段落ですということで、pを外につけるのではないのですか？
あと、段落は、見出しにも付けた方がいいですか？
<h1>おかしの説明</h1>
  アップルパイ
  クリームパン
  ショートケーキ
このひとまとまりにこう家をつけない場合でも、<div></div>で
囲んだ方がいいのでしょうか？

>>491
＞<blockquote>aaaa</blockquote>この引用は
＞段落ですということで、pを外につけるのではないのですか？

「この引用は段落です」ってアナタ、逆でしょう。
「この段落は引用です」ということを明示するためにblockquote要素を
使う。

＞あと、段落は、見出しにも付けた方がいいですか？
＞<h1>おかしの説明</h1>
＞ アップルパイ
＞ クリームパン
＞ ショートケーキ
＞このひとまとまりにこう家をつけない場合でも、<div></div>で
＞囲んだ方がいいのでしょうか？

「こう家」って何？（ﾋﾟｭｱ
見出しは見出し。段落ではないからp要素で囲う必要はない。

ていうかdiv要素は段落を示すものではない。

　ＸＸＸＸＸネット様

　こちらはインターネット掲示板２ちゃんねると申します。
　○月Ｘ日▲時■分〜△時□分のあいだ、当掲示板にて以下のリモートホスト（xxx.xxxx.xxx.ne.jp）より、同内容の繰り返し書き込みが執拗に行われました。
　このような行為は掲示板運営を妨げ、また当掲示板のサーバや回線に無用な負荷を強いるものであり大変迷惑しております。
　つきましては、ＸＸＸＸＸ様におかれまして、該当するユーザー様から二度と同様の行為が行われないよう、厳正なる処置をお願いしたいと思います。

　なお現在、当掲示板では荒し行為を排除するため、正規表現で.*xxx.ne.jpに相当するすべてのリモートホストからの書き込みを拒否しており、ＸＸＸＸＸ様より「同ユーザー様からの同様な行為がないことを保証していただけるまで」この規制を継続します。

　また、このメール及び、ＸＸＸＸＸ様よりの返信等、事態の経過に関しては、当掲示板サイトにて公表させていただきます。あしからずご了承ください。

　２ちゃんねる掲示板
　　http://www.2ch.net/
　　[email protected]


４　経過報告
　規制が行われた以降は、プロバイダの対応等について、随時経過を公開

あぼーん

>>492
> 「この段落は引用です」ということを明示するためにblockquote要素を使う。

これも何か変。

引用するものが段落のようなブロックならblockquote要素を使い、
引用するものがインラインならq要素を使う。

<p><blockquote></blockquote></p> が許されないのは、
<p><ul><li /></ul></p> が許されないのと同様なHTMLの不備のひとつ。

>>495
引用"される"ものが、だろ。

>>495
＞> 「この段落は引用です」ということを明示するためにblockquote要素を使う。
＞
＞これも何か変。
＞
＞引用するものが段落のようなブロックならblockquote要素を使い、
＞引用するものがインラインならq要素を使う。

変か？

ていうか今書いた長いXHTML文書をValidatorに掛けたら
エラーもケアレスミスも一個も無くてちょっと嬉しかった。
いや、それだけなんだけど。

<p>hogehogehogehoge</p>

これを引用する↓

<blockquote cite="http://www.foo.com/>
<p>hogehogehogehoge</p>
</blockquote>

>>488
すみませんが、WCAGドキュメントのどの部分ですか？
いま、関連する箇所に目を通してみたのですが、そのような記述を
見つけられなかったのだけど。
cf, http://www.w3.org/TR/WCAG10-HTML-TECHS/#lists

ここ？
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.

----

長文引用ｽﾏｿ

関係ないが、「要素を使う」って言い方はやめようYO!
「要素と見做す」か、せめて「タグを使う」にしてくれ。

>>502
＞＞「要素と見做す」か
なんて読むの？

>>503
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%B8%AB%D0%F6%A4%B9&sw=2

「見做す」っつーのは六法風の書き方だと思うｙｏ！
普通はカナ表記じゃない？

要素を使うのに「タグを使う」のは当たり前
「タグを使う」の方が微妙

俺的見解。

1. 引用部分に、q要素を使う。　・・・　○
2. 引用部分に、qタグを使う。　・・・　△
3. 引用部分に、q要素を適用する。　・・・　◎

「q要素としてマークアップする」だと思われ。
要素というのは文章が書かれたときからそこにあるものであって、
使うとか使わないとかいう問題じゃないだろ。

たとえばbodyタグは省略可能だが、たとえbodyとして明示的に
マークアップされていなくても、body要素がなくなるわけではない。

>>501
そこに書いてあるのは、入れ子リストにはcompound numbersを使いなさいよ、
ということであって、Orderd List要素ではなくUnorderd List要素で
マークアップすべしとは書いてないんだけど。

>>509
あぁ。けどこれ以上突っ込んだことは書かれていないようなんで、
>>488がちょっと勘違いしていたってとこでは？

# 他のソースあたってないから強く断定できないｶﾞﾅｰ

>>496
日本語を知らない人ですか？
君みたいな人は、
「購入するものがない」の代わりに「購入されるものがない」と言ったり、
「利用するものは鋏」の代わりに「利用されるものは鋏」と言ったり、
するんでしょうね。気持ち悪いよ、それって。

>>492
ありがとうございました。
参考になりました。

あぼーん

>496, >511
どっちも正しいだろうに．
頭に「私が」が省略されてると思えば「引用『する』もの」だし，そうじゃなきゃ「引用『される』もの」
つーか，どこがstrictの話なのよ．

「正しい日本語を使える人でないと(StrictなHTMLを使うのは)難しい」
という話ですか

Strictな日本語の話題は板違いかと。

引用の話が出てるのでちょと質問。

昨日、友人とこんな会話をした。
自分「そういえば、春だねぇ。」
友人「ああ、駄スレ多いよな。」

とかの会話も引用とするものなのでしょうか。
<q cite="リアル">の感じで。（実際はcite属性はかいてません。）

>>517
titleに書くことにしてる。

.htmlぢゃなくて.txtなら、カギ括弧が q だの blockquote だのの役割を果たしてるんだよね。
カギ括弧は他に、dfn の役割をすることもある。
こう考えると、:before :after 擬似要素がまともに使えるようになって欲しいな。

>>517
cite属性の値になるのってURIだけじゃなかったっけ？

>>520
その通り。

ばけらさんは、メールアドレスの@を、@としているのですが、
これは、普通に@ではいけないのでしょうか？

& #64のことです。

アドレスをソースから収集されないためだろ

>>518
titleですか。
すみませんが何と書いてますか？
ポップアップされるのは嫌なんだけどなぁ。

>>520
いや、実際には書いてないですって。
<q>セリフ</q>としてるんですけど、なんか違和感があって。

会話は引用とは違うのかなぁ？

>>525
　政治家の演説とかなら十分 q 要素の範囲では？
　知人との会話でも「引用」するなら q 要素かとは思うが、普通の会話って著作権が成立するとも思えん。
　ここら辺は markup ではなく、著作権法の適用範囲の問題になるんではないかな、と。

>>526
私も同じことを考えてた＜著作権法
たとえば小説なんかで登場人物のせりふに引用の要素を適用するのはﾁｮﾄ違うと思う。

>>522
>>524 で解ったかな。下記参照。
ttp://www17.u-page.so-net.ne.jp/qb4/chiharu-/reject_virus.html

>>525

その部分が、著者の記述ではなく、他者の発言の引用であることを
特に強調したい場合、または、その発言に表された発言者の思想なり
意見なりを紹介することを意図して引用した場合以外は、特にq要素
としてマークアップする必要はないのでは。

あと、q要素としてマークアップする場合でも、地の文にカギカッコは
つけた方がいいと思います。
カギカッコを外しちゃうと、CSSが無効な環境では、それが発言だって
ことがわかりにくくなってしまうので。

>>525
関連スレ:「Ｑ要素：インライン引用文のマークアップについて」
http://natto.2ch.net/hp/kako/1002/10027/1002750163.html

>>522-524
ここ参照。↓
「ウイルスからサイト内のメールアドレスを隠す」
http://www17.u-page.so-net.ne.jp/qb4/chiharu-/reject_virus.html

>>529
>地の文にカギカッコ
"「引用文だよ〜ん」"
って表示にならないかい？
ダブルクオートはNS6なら消せるけどMacIEじゃ消せないよ。

>>526-527
なるほど。
著作権から考えると q要素で囲むのはオカシイですね。

>>529 （520氏）
ただ、発言を囲ってるだけですし無い方が良さげですね。
あと、鍵カッコはつけてます。言葉足らずｽﾏｿ。

>>530
親切にありが�d。
そのスレで会話の引用にも触れてたので参考になりました。

結果として、会話には必要なさそうですので、外します。
みなさん、親切にありがとうございました。

ポッキーの甘味。

>>532
ﾏｸは quotes :none; が効かないんですか？

>>532
このスレ的には
q { quotes:none }
とでも指定するとか。

> ダブルクオートはNS6なら消せるけどMacIEじゃ消せないよ。
User-Agentを呪いませう。

# ってか、そもそも勧告の
「UAはQ要素の前後に引用符をレンダリングrしなければならず、書き手は引用符を書くべきではない」
がアレだったり……>>530で散々既出だけど。

>>534
うん、効かない。
ダブル・クオテーションマークも本来“”であって""になるのはイヤだな。
だから私は<q></q>でマークアップしない。必要性を感じないし
自然言語の鍵括弧（「」）によるマークアップがあれば十分。

>>536
ﾀｼｶﾆﾅｰ。
でも、Strict的にはどうだい？やっぱqマークかい。
まぁ、堂々巡りな話になるから、とりあえずUAの実装を待とうと。（殆どそうだけどなー

表示依存でマークアップを変えるなYO!
段落内の引用はq要素。これは定説です。

まず文章ありき、の立場からすれば、マークアップする時点で原文に手を入れなくては
いけない（カギ括弧 or quotation mark の削除）のは釈然としない。

「<q>引用文</q>」でいいんじゃないの？
q { quotes:none } も指定しておいて。

>>540
>q { quotes:none } も指定しておいて。
だからそれ、Netscape6/Mozillaしか効かないって。

いや、Netscape6/Mozillaでもquotes:noneは無効。
Q:before, Q:after {content:"";}だね。

あ、そうです。そんなかんじ。

だからMacIEでは
quotesもcontentも効かないってば。

>>544
気にするな。

>>539
地の文の引用符は、引用であることを示す「装飾」でしかない。
だから地の文に鉤括弧があっても削除してよい。

これはリストマークとしての中黒や数字を
(元のテキストから)削除するのと同じこと。

・<li>項目</li>
・<li>項目</li>

これじゃ違和感あるだろ。

「<q>引用</q>」

というのもこれと同類。地の文に引用符は要らない。

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 でやってたんですけど、どうも違うような気がしてきて。

>>547
<address>が良いと思ひます。

>>547
いっそ table の方が自然かもとか思った。

>>549
<table>かあ。
個人的には投稿フォームって、表って感じもしないんだけど、
段落やリストよりは表のほうがよさげな気もしてきたなあ。

無邪気にテーブルのままでレイアウト組みなおせば
よかったのか。何か欝。

おれは個人的にTABLEよりDLだと思います。
うちのサイトは全部そうしてる。

>>547
自分もYYBBSをStrict化してみましたが、そこはdlにしてます。
dl要素=「2種類の部分を持ったリスト」という観点で。

>>547
<dl>の方がいい気がする。
うちは<ul>でやっちゃってるけど。
もう一度組み直そう。

私も<dl>。
>>552と同じく2種類の部分を持ったリスト」という観点より。
たまに<ul>も使うけど、<table>ではないと思う。

>>551-552
dl って、定義リストでしょう。

定義に入力して欲しいものの名称
内容に入力ボックス
って使い方がはたしていいのかどうか、と、悩み始めたらとまらなくなったです。

定義リストでマークアップした時に
クッキー保存するかしないかのラジオボタンの配置はどうしようとか…。

tableだろうが、ulだろうが、仕様書の書式をはずれなければ
文法チェックは通っちまう訳で、自己満足できるもので
マークアップすればそれまでといわれればおしまいですが。

とりあえず、悩まなくてもすむ部分を修正して煮詰まった頭を冷やします。

dlは定義リスト以外に使ってはいけないわけではないんじゃなかったっけ

とりあえず手元の本には、
「dl要素はその応用範囲が広く、対話を表現する場合など
他に利用できる適切な要素が無い場合には、
用語の定義に限定せず使用することが認められています。」
とある。

"会話"てのは

<dl>
<dt>東出</dt>
<dd>「こんにちは」</dd>
<dt>今岡</dt>
<dd>「こんにちは」</dd>
</dl>

てことか？

例えばインタビューとか良い例だと思うな。

>557
それ，秀和システムの岡蔵さんの本だよね．
で，その「認められます」ってのは別のどこかに記述があるのだろうか？
4.01 recomendation（日本語，英語）とか神崎さんのところとか見てみたけど書いてない．

Recommendationだ．mが1個足らんかった．ぐぅ．

>>559

鳩丸には、

> 基本的には用語とその解説を示して用語集を作るのに用いますが、
> 日記の日付とその内容、会話の発言者とその発言内容、などなど、
> 一対一で対応するものを表現するのに広く使われているようです。

と、書いてある。

というか、XMLじゃ有るまいし、要素の数は有限なんだから、
出来るだけそれに近いモノでカバーするしかないような。

>>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.
「認められている」とまで言える記述かどうかは微妙だが。

>>562
同意。認められてるか認められてないかなんて、俺にはどうでもいいです。本質はそこじゃないと思う。

>564
じゃどこ？
<p>でなく<dl>でマークアップするほうが「適切」だと言える根拠は？
僕も別にどこかで認められてる必要性は感じないけど，
明確に書いてくれてるほうが安心して使える（マークアップできる）ってだけなんだが．

なぜp要素が出てくるんだ

>>565
だから、557氏が引用した岡倉氏の説明で良いんじゃないかと。

>>565
根拠といわれてもなぁ。根拠なんてたいそうな物はありません。>>547の場合、俺ならDLが一番しっくりくるって言うだけで、それでTABLEでもないだろう（未対応ブラウザとか考えると）と思うだけで、大間違いだとも思えないし、申し訳ないけどうまく説明は出来ないな。
っていうか、そんなに不安ですか？各自の性格もあるんだろうけど、俺的には、そこまで悩まなくていけないところなのか、疑問です。>>547さんも悩みすぎだと思う。（煽ってるわけではないです）

うお、家に帰ってきたらﾚｽいっぱいついてる。

私が悩み始めたのは、label要素とinput要素は分けるものじゃなくて、
一緒の要素の中につっこんだほうがいいのかなあと思い始めたからです。

そうすると、dtとddに分けるのじゃなくて、
li か p でひとまとめにしたほうがいいのかなって気もして、
それで最初の書き込みになったわけですが。

入力して欲しいものを列挙してるんだから、p は論外で、
dt dd をつかうか、li を使うかは入力項目とそのラベルについての
考え方の違いかなという気もしてきました。

>>568
いや、実際、余計なところで悩みすぎだとは自分でも思ってます。
気にしなくてもいいのかな。

>>569
> label要素とinput要素は分けるものじゃなくて、
> 一緒の要素の中につっこんだほうがいい

そんなことはないと思いますよ。for属性があるんだし、どっちでもいいと思う。

<ul>
　<li>
　　<p>うんたら</p>
　　<p>かんたら</p>
　</li>
</ul>

の方が良さそうに思える。

>>570
俺も悩んでた時期があったんですよ。
でもそれで更新が滞ったりして、あんまり考えなくなった。
というか、満点じゃなくていいやと思うようになったんです。
人がまず見るのはマークアップの仕方じゃなくてタグに挟まれた部分だし。
DLが正解にしろPやULが正解にしろ点数つけたら2点差ぐらいじゃないかって思います。

>>572
少々冗長な感じがします。

<ul>
　<li>うんたら</li>
　<li>かんたら</li>
</ul>
かな？

でも>>574はちょっと変な気もするが…。

漏れはxhtml派だから、UAが処理しやすい形で、well-formedなら
いいと思ふ。
再利用しやすい形にマークアップすればいいんじゃないか。
誰が再利用するかは、知らんけどね。(w

オイラは、
<ul>
<li><label>名前：</label><input type="text"></li>
</ul>
のようにしてる。（一部略）

small {font-size:90%;}
.small {font-size:90%;}

StrictなHTMLには、
<small>あいうえお</small>
か、
<p class="small">あいうえお</p>
どっちがいいのでしょうか？

>>578
class属性の値は"small"じゃなくて、
「なぜその字を小さくしたいのか」
を表すことばの方がよいのでは？
たとえば覚え書きだったらp class="memo"とか。

俺は、せっかく仕様で認められてるんだからいいや、
って感じで、small要素としてマークアップしちゃってますが。

>>578
pってのは例だよね？
たまたま例ではpだけど、そこはいろんな要素を考えてるんだよね？

そうでないなら、ブロック要素とインライン要素を区別できてないことになっちまう。
例示するなら<span class="small">ぢゃないかい？

で、この手の話題はさんざｶﾞｲｼｭﾂじゃないかと思う。

>>578
小さくしたいだけなら
<small>でいいよ
strictでも認められているんだから
物理要素がいやだというならclass名も
それなりに579のいうように
<p class="note">alt属性は必須です</p>
とか
<p>彼女と別れました、ぜんぜん構いませんが<span class="本音">嘘</span></p>
とか

>>581補足
<p>彼女と別れました、ぜんぜん構いませんが<em class="本音">嘘</em></p>
という風に
一部W3C原理主義者【誰】はspanを嫌いemを使う場合もある。
フォントを小さくしてもそれはそれで強調であるとのこと。
わたしはp.noteとか段落全体の文字を小さくすることあるけど
文中で、一部だけ小さくするというのは避けてますけど。
まあこればっかりは好き好きかと。

>>581-582
<em style="text-decoration:line-through;">嘘<em>
もアリかも。

>>583
言いたいことは解るが、話がずれてる(w

装飾によって文章を強調する場合、その装飾が何を表しているのか
説明することは、書籍などではよくあることだと思います。
「下線部は原文ママ」とか「太字の部分は筆者による注釈」とか。
こういうのは、strict的にはどういう風に表現したらいいんでしょう。

1.非推奨ではない物理スタイル（BやIなど）を用いて、
　「太字の部分は筆者による注釈」とやる。
2.strongやemを用いて、
　「strongタグでマークアップされている部分は筆者による注釈」とやる。
3.title属性を用いて<strong title="筆者による注釈">とやる。
4.マークアップに頼らず、地の文でいちいち、
　「以下は、筆者による注釈である」などと明記する。

原文ママ＝引用＝q要素
筆者による注釈＝<span class="note">〜</span>

p{text-decoration:underline}
span.note{font-weight:bold}

>>585
1.の方法だと、音声環境なんかで意味不明になるし、論理的でない。
2.だと冗長だし HTML を知らない人には意味不明。
3.4.はまあ一つの方法だろう。引用文を強調するときは漏れも title 使うし。

という訳で、普通は strong でマークして「強調部分は筆者による…」とする。
これなら環境に依存しないし。

そもそも「strong としてマークされている部分」っていうのは、
要するに強調部分でしょ。だったら「強調部分」と説明した方がわかりよい。

あぼーん

例えば、こういう試験問題があるとします。
「下線部 A 〜 F のうち、誤りがあればその箇所を指摘し、理由を述べなさい」
これをHTML文書に書き直すとしたら、
「強調部 A 〜 F のうち、誤りがあればその箇所を指摘し、理由を述べなさい」
と、なるのでしょうか。

これにはちょっとだけ問題が起きる可能性があると思ったのです。
プレーンテキストで表示するブラウザがあるとしたら、
強調部を「強調」してレンダリングしてくれる保証はあるのでしょうか…。
そうでなくても、ユーザスタイルシートで無効にしている装飾を
CSSでem要素などに適用していると、
地の文と区別がつかなくなってしまう可能性もある気がするのです。

# そもそも元々の文が物理マークアップに依存してるせいなのかも(w

＞「強調部 A 〜 F のうち、誤りがあればその箇所を指摘し、理由を述べなさい」
＞と、なるのでしょうか。

＞# そもそも元々の文が物理マークアップに依存してるせいなのかも(w

その通り。
じゃなきゃ、リストにした方がもともと分かりやすくないですか？

Webは紙媒体のメタファーではないと思うんだな。
メディアが違うんだから、最適化できるなら最適化した形で提示すべき。

>>591
メタファーって、どういう意味?

>>592
比喩

つまり、紙媒体の概念をそのままWebに持ち込むべきではないと思うんだよね。
Webは新しいメディアなんだから、紙媒体のイメージに束縛されるべきではない。
HTMLにはHTMLだからこそできる(紙媒体にはできない)ことがあるけど、
逆もまたしかりで、紙媒体にできてHTMLにできないことだってあるわけだから、
HTMLという形態を選んだ以上「紙媒体のスタイルをそのままトレースする」という
発想は制約を産むだけであんまりうまくないと思うんだ。

紙媒体の完璧な再現を目指すなら、それこそPDFの出番じゃないか？

>>589
> プレーンテキストで表示するブラウザがあるとしたら、
> 強調部を「強調」してレンダリングしてくれる保証はあるのでしょうか…。

強調部を強調しないようなブラウザは、
そもそも HTML ブラウザとして不正だろ。

つーか、A-F というアルファベットが振られていれば、
極論「下線部」とか「強調部」という表現なしに「A-F の中から…」
だけでも通じるのでは?

破線/二重線/傍点などが混在しているような状況なら、
記号も A-F イ-ヘ 1-6 などで使い分けるべきだし。

サ骨氏を受験板某スレでﾊｯｹｿ
先輩ﾖﾛｼｺ

オフトピsage

>>595
と思ったら勘違いﾀﾞﾀｰﾖ
ｺﾞﾒｿ＞サ骨氏

>>587
だいたい俺自身の結論と一緒なんですが、ひとつだけ気になるのは、
文中に他の要素も混在してた場合、どれが強調なのかわかりにくい
ということ。
たとえば、文中にstrong要素とdfn要素が混在してたら、HTMLに
詳しくない人は、どっちが「強調」なのか分かりにくいだろうなあ、と。

やはり、こういった書き方自体が、Webでは避けるべきなんでしょうね。

>>597
そこら辺は(auralにしろvisualにしろ)スタイルシートに任せる
しかないような気が。

あとは凡例でもつけるくらいしか思いつかんなぁ。。。

>>597
ブラウザは HTML 文書を利用しやすくするものであって
結果として HTML を知らなくても HTML 文書をそこそこ利用できるようにするけれど
そういう人に意味を伝えることは、最終的にはできない。
HTML で「意味」を伝えられるのは、結局のところ UA まで。
文書利用者まで意味が伝わるためには、利用者側の HTML 理解が必須。

HTML に疎い人に充分に意味が伝わらない(かもしれない)ことが問題になるなら、
プレーンテキストの状態で意味の通らない文章は避けるべき。
本当はそういう人に HTML 文書を利用させること自体に問題があるのだと思うけど。

>>594 レンダリングは UA 依存 強調部分を強調表示しなくてもなんら問題はない

strict的には、
<SPAN style="text-decoration: underline;.color: red">親<SPAN style="color: blue">子</SPAN>親</SPAN>
として、アンダーラインを赤にしてもいいですか？

好きにしれ。
ただ、親が「下線つき赤」、子が「下線つき青」に表示されないと通じない文章を
書くのはNG。

>>601
うん、CSS2の仕様書通りですよ。
http://www.w3.org/TR/REC-CSS2/text.html#lining-striking-props

参考までに、岡橋一輝氏訳を
>このプロパティは継承を行わない。
>しかし当該ブロックの子孫部に当たるボックスは、
>すべて同じ装飾を施されるべきである(たとえばすべて下線を施されるべきである)。
>またその時、子孫部の要素が'color'プロパティに異なる値を持っていても装飾の色は同じにすべきである。

あぼーん

>>601
Strict的にはそういう書き方自体が・・・

>>605
胴衣。validなだけでもなぁ。


スレタイ的にはいいのか。

Strict的って
解釈が色々あるよね。いまさらだが・
W3C信者的って方がいいのかな？
XHTML1.1からStrictなくなっちゃうし。

「内容に即したマークアップを心がける人達」

短く言うには、やはり頭文字。
"内即マ心人"


-- ボクのこと、忘れてください。--

>>607
transitional がなくなったから、strict と名乗る必要が無くなっただけでは？
XHTML 1.1 が strict ではない、と言う事は無いはず。
相変わらず一部の表示用要素が存在するが、少なくとも HTML 4.01 strict と同じくらい strict。

>>609
煽るわけではないけど、HTML4.01よりうんと厳密。
ttp://niaou.alib.jp/columns/xhtml/1211.html

Strictly Htmlized

つーか元々 HTML と言えば Strict なのであって、他の何でもありません。
HTML 4.01 / XHTML 1.0 でわざわざ 'Strict' と書いているのは
Transitional / Frameset という亜流があったため。

# まあ HTML 2.0 や HTML 3.0 にも Strict ってあるんだけどね。

>>602
>>603
>>605
>>606
>>607
>>609
さんありがとうござました。

(´-`)。ｏＯ（飾り枠の実験。あまり、美しくない。。）
(´-`)。ｏＯ（mozillaでスタイルシート外したりしてみて下さい）
http://sakots.pekori.jp/ushi/jikken/mou.html

(´-`)。ｏＯ（たしかにbackground-imageの重ね張りができたら１発なんだよね）

<dl>の中身って<dt>と<dd>以外は一切ダメなんでしたっけ？
例えば<dl>の中に<div>使ってクラス指定したいんですが。

>>616
ダメ。

dl要素内に配置できるのは、dt・dl要素のみ。
dt要素内にはインラインレベルの要素。
dd要素には大抵いける。

あ、遅かった。

>>618の訂正
dl要素内に配置できるのは、dt・dd要素のみ。

>>617-620
やっぱりだめですか・・・
ありがとうございました。

dt、dd要素にそれぞれclass属性指定すればいいじゃん？

>>622
dtとddをひとつのカタマリとしてfloatさせたかったのですが、
それぞれにclass指定でできますか？
＃いろいろ考えたけど思いつかなかった・・・

<dl class="nanika">
じゃだめなの？

HTML 4.01 / ISO-HTML なら dl 直下に del/ins も書ける。

と言って混乱させてみるテスト。

>>625
HTML 4.01では
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
<!ELEMENT (INS|DEL) - - (%flow;)* -- inserted text, deleted text -->

ISO-HTMLでは
<!ELEMENT (DEL|INS) - - (%text;)+ >

両方ともdt/ddを含められないんですが……どこか間違っているのかな。

>>625
煽りにマジレス。それ使えば>>616の願いはかないそうだが
不思議マクアプだわな。

けど>>623を読んでいると、これはむしろtable？と思った。

>>626
たしかbodyの周辺を参照

>>624
現状それでやってますが、
ひとつのリストなのにhtml上はバラバラになってしまうのが
なんとなく気持ち悪かったので。

>>627
なんか「tableを使わずに」というのが頭にあったもので存在を忘れてました。(w
確かにこの場合はtableでもいいのかもしれないですね。

pre.ascii_art {
    font-family: "ＭＳ Ｐゴシック";
    text-align: left; font-size: 16px;
    line-height: 1.1;
}

http://mwave.sppd.ne.jp/diary/?date=20020320#c01
誰か解説してくれ･･･

>>631
何を？

>>631
極論同士のせめぎ合い。
Flashに頼ったサイトのアクセシビリティーの低さがとっかかりだったのに、
いつの間にか「正しいHTMLは難しいから普及しない」とかの話になってるし。

でもま、読んでて面白かったよ。
全部目を通したら薄っぺらい本一冊読んだくらいの満腹感だったけど（ｗ

dl要素内でのdivはだめとのことですが、
dtやdd要素内ならよいのでしょうか。

>>634
dl直下に置けるのがdtとddだけなのであって、divが置けないのは当然。
dtはインライン要素しか内包できないから、やはりdivを置くことはできない。
ddならdivを内包できる。

間違ってたら指摘よろしゅ>ALL

別に間違ってないと思う

　　dl要素の内容モデルは、dt要素もしくはdd要素に限られます。
　　従って、dl要素の直接の子要素としてもう一つdl要素を持ってくることはできません。
　　
　　dt要素の内容はインライン要素に限られますが、
　　dd要素はインライン要素、ブロックレベル要素のどちらも内容とすることができます。
　　つまり、定義対象（dt要素）にできるのは単語やフレーズのみですが、
　　その説明（dd要素）は複数の段落や図を含んだものであっても良いというわけです。
　　事典でのそれぞれの役割を考えるとこの使い分けを理解しやすいと思います。

http://www.kanzaki.com/docs/html/htminfo13.html
の「定義型リストの内容モデル」より。

StrictはHTMLだけじゃなくCSSにも言われると思った今日この頃
HTMLだけ完璧でもCSSがエラーだらけじゃ意味ないか…

CSSチェッカー
http://www.htmlhelp.com/tools/csscheck/

>>638
要するに仕様を読めるか読めないか、 DTD を読めるか読めないか、
DTD に違反する不思議マークアップを破損ファイルと捕らえているか否か、
みたいなところではないかと。

css2完全対応じゃないのね

>>638
background-colorよりbackgroundの方が
広くサポートされてるって言われても．．．。
色指定も、rgb(x,y,z)よりも#rrggbbの方が、と文句言われる。

なんだかなぁ。

これ使ってますが。
http://jigsaw.w3.org/css-validator/

>>641
backgroundと他はどっちが良いとされてるんだろう？
俺はbackground使ってるけど…

>>643
backgroundは、imageの方の値は必須なんすか？
validatorで>>641のように言われて以来、
背景色のみで背景画像のない部分を

.hoge{
background: #000 none;
}

のように記述していますが、冗長的ですか？

fontプロパティと一緒で、
backgroundプロパティは

・background-color
・background-image
・background-rapeat
・background-position
・background-attachment

を一括指定出来るというだけの話で、それ以上でもそれ以下でも無い。
僅かでもファイルサイズを削りたければ、
backgroundで一括指定したら良いんだけど、
border辺りも含めて
一括指定は後から見た時に解り難いから、個人的には嫌い。

そういえば、IE3だったか（あやふや）が、
background-color等を認識しなくて、
border-bottom(topその他含む)はNN4が認識しないらしいけれど、
そんなのは今時知った事では無いよね。

↑が今ネスケ４を裏切った発言をしました

>>645
なるほど。

# 自分が仕様をちゃんと読まなかったのが悪いので
# これから読んできますが、
つまり
> background-colorよりbackgroundの方が
> 広くサポートされてるって
いうあのvalidatorの指摘は、
２つの記述が全く等価であるからナンセンスなんですね。

ただ、UAの実装の面から見て、background-colorより
ショートハンドの記述の方が実際に広くサポートされてるんですか？

border関連なんかだと確かに似たようなことが多くありますが、
ZSPCなどを見る限り、background-colorとbackgroundは
IE3しか対応状況に違いがありません。

>>644

http://www.ne.jp/asahi/minazuki/bakera/html/css/colors#background

今は仕様書まで見る気力が無いんだけど、
ぱけら氏が正しければ要らないみたいだね。
638のvalidatorがダメなんだと思う。

でも、644の例は何故background-colorでやらないんだろ、
という疑問の余地も。

てかすれ違いなので、css質問スレ行ってきます。

>>648
ただひたすら、>>641のように言われたためです。
逝ってきます。。。仕様書読みに。

俺color指定だけでもbackground使ってる
全体的に統一したいし

>>余談ながら、何故か IE3 は background-image などを認識せずに、省略形の background のみを認識するようです。

これ見てbackgroundでいいやと考えてしまった。IE3はCSS無視させてるけど…

>>651
スレ違いでも、あと一つだけ。
その辺の一括指定は、アンケート取ってみたら面白そうだね。
私の場合は、
border→border-bottom（topその他含む）
だけは一括指定を使ってて、
あとは、値が0でない限りは、
margin,padding→margin-bottom（topその他含む）
だとか、font,background辺りも個別に指定してる。

borderとかpaddingの「上 右 下 左」を一瞬で判断出来るお方は、
個人的には尊敬してしまうのだけれど。

>>648
最後の2行は取り消し。validatorに弾かれたからだね。

>>647
Mac環境が存在しないので、iCab辺りは良く知らないんだけど、
それはIE3固有のバグっぽい。

>>653
> borderとかpaddingの「上 右 下 左」
それだけは値が何個の場合でも、「時計回り、上下別あり（3個）」
という覚え方でたちどころに覚えました。

オフトピに粘着レスｽﾏｿ

> borderとかpaddingの「上 右 下 左」
１コ、または４コ指定しかしないので、俺は混乱しないよ
覚え方は>>654のとおり時計回り。

2個指定もけっこう使う

>>652
IE3対策で、background を使用していました。
今では、@importで IE3対策してます。

> borderとかpaddingの「上 右 下 左」
　俺は１〜４こ指定全て使う。別に迷わない。単に慣れの問題かと。

　ちなみに、右と左が意味があって同じ場合は、２個又は３個指定をするが、たまたま一緒の場合は（右と左が同じ値でも）４個書く、という俺ルールがある（上下の場合も同じ）。

(´-`).｡ｏＯ（この人こんなんで商売やってのか？）

>>659
やってのか？
？？
誰の何のことを言ってるんだ。はっきり書けや。

>>653
覚えることは、「時計回り」＆「指定しなかった場合、その反対側と同じになる」
ということだけ。(1つの場合は全て同じ)
難しくないでしょ？

>>645-661
いや、全てその通りで、アタマには入ってる。

ただ、慣れてないだけなんだろうけど、
絶対に直感的には判断出来ないので、
判断に掛かってしまうコンマ数秒がウザいというか、面倒というか、そんな感じ。

分かり易く具体的な例を挙げると、
border-left:1px #aaa solid　は
それぞれ値（というか単位）が全くバラバラだから一瞬で判断出来るけど、
margin:1% 2% 3% 4%　は
値（というか単位）が同じだからやっぱり多少考えてしまう。

これなら、少々文字数が増えようがmargin-leftとか個別にやった方が、
ストレスが少ないと、あくまで個人的な話ではあるけれど、そう思う。

じゃあなんで、
>>653で述べたfontとかbackgroundを個別に指定したがるのかと
突っ込まれても、それはそれで全くの【謎】としか言いようが無いんだけど。

一段落ついたっぽいので質問させて下さい。

日本語の略語も abbr要素とかでマークアップすべきでしょうか？
昨日、<abbr title="ドリームキャスト">ドリキャス</abbr>というのを見たので気になりました。

スラングをマークアップすべきかどうか、だな。

"TGIF: Thank God, It's Friday"なんかはよく使われるけど、
USのStrict信者はどうマークアップしてるんだろ？

敢えて説明をしたい場合にだけやったら？
のべつまくなしにabbrがあるとかえってウザイし（特に音声ブラウザ）。

>>663
英語か日本語か、というのは無関係。
余り一般的でない略語を使う場合には、正式名称も書くのが慣例では。

>>664
title を読み上げる UA があるの? 詳細きぼん。

>>665
＞英語か日本語か、というのは無関係。
　俺もそう思う。

　ただ、思いはするものの、日本語の場合、具体的にどちらを使えば良いのか、例えばドラクエ（ドラゴンクエスト）や、国連（国際連合）は acronym と abbr のどちらを使えば良いのか、と他人に聞かれると感覚的な話になってしまい、理論的に人に説明できない。
　strict-html では無くて国語の話になってしまうかも知れませんが、誰か教えてください。

>>667
>>205-236

>>667
というか、Strict的には acronymとabbr は同じモノだとみなされている。
W3C的にはabbrだけでOKで、MS様が勝手にacronym要素を作ったので、
止む無くHTML4.0に採用したらしい。
略語とか頭字語とか、あとの話は全てコジツケ。

．．．という話が、このスレの上の方にあったような。

被ってしまった。
しかも、>>668の方が親切っぽい。

iモードとやらのサイトを作ろうと思ったんですが、調べたらW3Cが勧告してるCompact HTMLってのがあるんですね。
これってどうなんでしょう？現行のiモード機種でエラーなしで表示できるのでしょうか？
なんかDOCOMOが突っ走って（DOCOMOというより機種メーカか？）実装を変えているような気がするのですが。(;´Д`)
XHTML1.1 Basicとかは…どうなんでしょう。そこらへんモバイル向けの情報ありません？

ありがとう。書いた方がいいんだね。
英語にしか書いてなかったよ。

# よく考えたら確かに略語に言語なんて関係無いよね

>>671
神埼たんの
http://kanzaki.com/docs/html/xbasic.html
に、
http://www.zdnet.co.jp/mobile/news/0108/02/wap2.html
へのリンクがあったけど役立つかどうか。

>>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 で作る必要はないよ。

>>674
iMODEに関しては、
古くなくてもXML宣言は表示される（少なくとも503iシリーズは）。
でも、XHTML的記述（<br />とか）は問題無し。

と、結構ここまでは共通認識としてあると思うんだけど、
FOMAはどうなんだろう？
あと、なぜかEZ-webに関しても、共通認識とは言い難いような。

FOMAに関しては、
>>673のzdnetの記事には、対応してると書いてあるっぽいんだけどなぁ。

>668-670
　サンクス。＆　過去ログちゃんと読まずに質問してスマソ。

>ばけらとは、「HTMLマニア」という意味である。
この一文が沢山の文章の中にあった場合。
ばけらとは、「<dfn>HTMLマニア</dfn>」という意味である。
ですか？　dl,dt,ddは文章の中には使えませんか？

あと、
「<dfn>HTMLマニア</dfn>」か、
<dfn>「HTMLマニア」</dfn>
のどちらなのでしょうか？　前者だと思うのですが。

>677-678
文中に定義がある場合は、dfnを用いるべきだと思います。
定義がp要素内であれば必然的にdfnなんですけど…。

ところで、dfn要素は「定義される語」（定義リストにおけるdt要素）
を意味するはずだった気がします。そうすると、
『ばけら』の方がdfnでマークアップされるべきでは？

>「<dfn>HTMLマニア</dfn>」か、<dfn>「HTMLマニア」</dfn>
　｢｣は、この場合定義語を強調するの為に存在するのでは？

　>>679 の言う通り、この場合「ばけら」方が dfn で　markup されるべき言葉なので

<dfn>ばけら</dfn>とは、<em>HTMLマニア</em>という意味である。

となるかと。

＃ちなみに、本来の質問の dfn を em（かっこ）がかぶる場合に関しては、
　俺は、定義語そのものを強調したい場合、<em><dfn>ばけら</dfn></em> としているし、定義語の一部を強調したい場合、<dfn><em>ば</em>けら</dfn> としている。

>>679
>>680
ありがとうございます。
おっしゃるように、dfnは定義語に付けるようです。
>>680
定義語の解説は、emで強調しないといけないのですか？

>定義語の解説は、emで強調しないといけないのですか？
　いや、んなこたないです。>>677 の例に沿って強調しただけ。

　強調が必要と感じられた場合に、通常の文章と同様に、em、strong を使って下さい。

>>679
>>680
ありがとうございます。
解決しました。

もう一つ質問をしても良いですか？
<div>
<p>なんとかかんとか、あいうえおか。<q><dfn>ばけら</dfn>とは、「<em>HTMLマニア</em>」という意味である。<cite>ばけらまにあ</cite></q>ああああああああああ</p>
</div>

引用の参照、参考本の<cite></cite>は、<q></q>の中か
外のどちらが良いですか？　どちらもパーサーでチェックすると
違反は出ませんでした。

>>683
模範解答は無かった様な。

中に入れれば、それが引用先に記述されていたもの
であるような誤解を招くかも知れないし、
外に置けばその関連性がDOM的に明示出来ない。

俺は外に置いて関連性は文脈で判断してもらう事にしている。
HTML4 Spec.は外に置いた例を出していたしね。

ふと思ったのだけど、このスレには厨な質問も回答も少ないね。
素直に勉強する気になれる、今時珍しい良スレだ（ｗ

ここではまともだけど他所のスレで厨してるﾔｼもいるんじゃないかな

>>685
それだけStrictが敷居高いってことだろ。
良スレなのはいいことだが、敷居が高いのは歓迎すべきことじゃないなあ。
みんなが普通にStrictに書けるようになる時代が来ればいいな(妄

>>687
何も考えていなくても使える上に簡単にデザインができ(もちろんCSS),
Strictなオーサリングツールが低価格で発売されて普及しない限り無理だろ。

>>687
敷居は確かに高いな。

しかし実際のところ「よくわかんないからTransitionalでいいや」っぽいユーザが多いのはどもならんのか。
このスレに厨が寄りつかないのは敷居が高いんじゃなくて興味がないだけのような気がしてきたyo；

このスレでの議論までいくと敷居が高いのでROMしている者ですが、
仕様書に従う(この言い方はちょっと語弊がありますか？)こと自体は
知っていれば楽になることの方が多い気がします。
デザイン先行のオーサリングツールが出回るのは仕方のないことですが
知識としてだけでも、もっとStrictが理解される方法があればいいですね。

むしろ、文書型という概念の敷居の高さではないかと。
Transitional だって、正しく書くことの難易度は Strict と大差ない。

ほとんどのユーザは SGML 文書を作成しているという意識がない。
「よくわかんないからTransitional」の場合、
Transitional も理解できてない可能性が高い。
論理構造を記述すること自体はそう難しいことではないし、
装飾に用いる CSS の難しさはまた別件だと思うし。

そもそも
「ホームページ」を作るときに論理構造を考える
ということが高い敷居になっているんだろうか。

見出しとか段落とか
意識して書いてる人がそもそも少ない。

敷居が高い、とか、興味がないという以前に、W3CとかHTMLの仕様とか、
全然知らないで書いてる人の方が圧倒的多数では。
オーサリングツールを使わずにテキストエディタで書いてるという人も、
別に正しいHTMLを書くためではなくて、もっと個人的な嗜好でそうしてる
人が多そうな気がする。

技術的というか仕様的な部分での敷居の高さとは別の問題なんだけど
(これはこれできちんと議論続行したい)
いわゆる信者の論調が初心者を遠ざけているジレンマを強く感じている。

正しいことを主張することは大事だが、主張だけすればいいわけじゃない。
相手が多数であれ少数であれ、理解してもらいたいと思うなら
理解してもらいやすい形で主張を掲げるべきだと思うのね。

極端な例でｽﾏｿが、かつての学生運動のようなスタイルではどれだけ論理的で高潔な政治思想でも
今の日本人が受け容れるとは思いにくいわけ。
そんなものは今日び流行んねぇんだよ、と。
「正しさ」と「流行」は本来無関係だが、無関係だけに矛盾もしない。

Strictに状況を置き換えるならば、方法論はふたつある。
ひとつは、Strictを徹底しつつ「とほほ」に比肩するわかりやすさを持つサイトを作ること。
これは以前私が主張したことを再掲しているに過ぎない。

もうひとつは、Strictを徹底した流行追随型サイトをつくること。
Strict派のサイトはしぶめのものが多いが、あえていわゆるギャル系などに魂を売る（ｗ
デザイン面でかなり奮闘しているサイトは増えてきてると思うんだけどね。
あるいはこのスレにも出てきた記憶があるが、Strictなエロサイト（ｗ

ま、マークアップがStrictでも原色バリバリのコントラスト全開なサイトが、
WAI的にどうなのかという話もありますが（ｗ
でも実際、そのあたりの「たくましい人たち」を取り込まないと、単純に多勢に無勢な状況は
変わらないと思うんだな。

３つめの方法論としては、広告塔。
キムタクとかイチローが「Strict っていいよね」って呟けば
それだけで信者の布教活動の100倍以上の効果が(w

>極端な例でｽﾏｿが、かつての学生運動のようなスタイルではどれだけ論理的で高潔な政治思想でも
>今の日本人が受け容れるとは思いにくいわけ。
>そんなものは今日び流行んねぇんだよ、と。
>「正しさ」と「流行」は本来無関係だが、無関係だけに矛盾もしない。

某こみゅーんが、そこら中で無駄な争いしてる現状だしなぁ。

2つ目と3つ目で頑張るぜ(w

>Strict派のサイトはしぶめのものが多い
見た目はしぶめなのに中身はアレゲなモノが多数。


論理構造は一応伝わるだろうが、普通に見れば
「四角いホムペ」が多すぎる。
画像を使わなくって済むからって
ボーダーに頼り過ぎの感が。
（個人的に「ボーダーいじり系」と呼んでる）

>>691
> むしろ、文書型という概念の敷居の高さではないかと。
> Transitional だって、正しく書くことの難易度は Strict と大差ない。

同意。漏れも Transiotional で書いてた時期ってないもん。
移行は直接「無印 → Strict」だったよ。

>>697
うん、耳痛い。

でも、技術的な裏付けもなしに HTML 解説してるような馬鹿見たら、
解ってる人間が腹立てるのも当然なんだよね…。

それでもぐっとこらえて大人の態度でいなきゃ駄目なんだけどさ。
そこまで人間できてないよ…。

Strictなギャルサイトを作ろうとして挫折した厨ならここにいます・・・

>>695

胴囲。

97年か98年頃から「ちゃんとしたHTML&CSSなサイト」やってますが、当時は
あまり流行ってなかった。流行るとも思えなかった。
また>>699氏の言うようなのばっかだった。俺のとこもそうだった(w
それがCSS切り替えスクリプトをきっかけにかなり増えてきたし、レベルも向上した。

はじめはそういう「カタチから入る」でもいいんですよ。
それをきっかけに「CSSなどを効率よく活用するには、Strict系HTMLがいい」
というのに後からでも気づいてくれれば。

>>696
そういうもんでもないような気が。
というのは、strictへの移行って、理解してないままスパッとできるような
もんじゃないでしょ？
たとえば、自分のサイトもってる有名人（中田みたいな）が、
「セキュリティホールの多いIEなんて使うのやめて、ネスケ使おうぜ！」
って言って、自分のサイトからネスケをダウンロードできるようにしたら、
ネスケの普及率はぐっと上がると思うけど、同じような感じで、
「不思議マークアップやめて、strictにしようぜ！」
って言われても、流行を折ってるだけの人は、まず何をしていいか、
わかんないだろうから、「なんか難しいこといってるなー」で、
終わっちゃうと思う。

ただ、695のいってるような、strict+cssの利点をふんだんに使った
派手なサイトを有名人がやったら、同じことを無名な人間がやるよりは
効果高いとは思う。

HTMLに Strict、Transitional、Frameset の３つの宣言がある事を知り、
かつ Strict は厳格なHTMLだと知ると、
それだけで敷居が高く感じられるのでは。

オイラもそうだった。
それで、Transitional から始めて文書構造を
勉強していってから Strict へ移行した。

>>695
Strictを徹底しつつわかりやすい解説サイトを作るということに関してですが、
それをこのStrictスレの参加者ですることは不可能でしょうか？

というのは、Linux板には「2ch Linuxビギナーズ」
（http://member.nifty.ne.jp/exreal/linux/）
というのがあって、役立ちそうな発言がいくつかピックアップされている。
こういうのを、ここweb制作管理でも作れないかと前々から思ってたんです。

難しいことはいろいろあるでしょうが、
Strictスレによる解説だけでなく、
web制作管理にまつわるいろいろを、
有意的な情報にまとめることは、
有意義だと思います。

言いっ放しだと無責任なので、
もしそれを実行するとなれば、
自分もその一端は担う覚悟であることだけ
申しておきます。

> 論理的で高潔な政治思想
これは、
> 美しく怜悧な
のがよいと思った。

>>705のような人を待っていたというかおそれていたというか（ｗ
賛同者がいるなら提供できるリソースは惜しみません。
垢も出せるしあぷろだも用意できます。

問題はどうやってコンテンツの見通しの良さを確保するか、でしょうね。
うまい方法がないか考えてみます。

# ちょっと私も走りすぎの感があるんで、ここんとこ話題が偏っちゃったかな。ｽﾏｿ＞ALL

>>706
気にしないで論議を続けてくだされ。元々、このスレって一つの事について
皆で徹底して意見を出し合う的な流れがあるからね。

出版社の意識もいいかげん変わって欲しいな。
「blockquoteはブロック化インデントのためのタグ」説がまかり通ってるんだが、
こういうアホに本なんか書かせないで欲しい。

w3c公認ウェブデザイナー検定試験みたいのがあれば。

段落とかもきちんと分かってなかったことに気がついた。

>705-706
>Strictを徹底しつつわかりやすい解説サイトを作る

もし実現したら、すばらしいですね。
そういったサイトを作るとしたら、まず導入はどこからでしょう？
いきなり文書型がどうのW3Cがどうのと始めると拒否反応がでそう。
やはりCSSデザインの魅力を知ってもらうあたりから入るのが無難なのかな？

あるいは、トラブル解決的なところから入るのが良いかも。
文字化けするのはなぜ？とか、ちゃんと表示されないのはどうして？といったところが入り口。
でもそれだと、初心者向けサイトと言うより脱初心者サイト、になってしまうか。

>>711
>>299-312

Strict ではなく CSS の敷居が高いのではないかと思った。
Strict は Transitional より要素も属性も少なく、覚えるだけなら難しくないはずだ。
文書を装飾するために、全く別な言語 CSS を改めて覚えなければならない。
この一点が、初心者を遠ざけて HTML の知識で装飾を行える Transitional に向かわせるのでは。

解りやすい Strict 解説サイトは、解りやすい CSS 解説も用意しないと
受け入れられるのは難しいだろうと思った。

言語の解説サイトみたいなのは、初心者向けならつらい
ＧＵＩで操作可能なツールを紹介しつつ、そのツールでＣＳＳの作成可能であって
もろもろの便利な利点を紹介しつつ、話を進めていけば

結局、初心者が作るＨＴＭＬは、おそらくすべて「ホームページ作成ツール」で
作成されていて、ソースなんか全く意識する事はなく、ホームページ＝ワープロ文書
ぐらいの感覚でしょうから

>>714
同意。

テーブルレイアウト/飾り枠の解説くらいに気合の入ったの
できませんかねぇ…

>>714
いや、むしろCSSではなく、他人の環境への配慮とか
スクローラブルメディアという概念の敷居が高いのかも。

だから、初心者(に限ったことではないが)は、
固定サイズのレイアウトをして、横スクロールバーを出したりたっぷり余白をつくったりして
平気な顔でいられるのでは。

でも、結局のところCSSの解説をきちんとやるにあたって
一番厄介なのは「各UAのバグ」なんだよな。

ここを「UAが悪いので気にするな」とか、
「各UAのバグに気をつけてあのプロパティは使わないようにしましょう」とか
やっちゃうと、素人にはお勧めできなくなっちゃう。

>>719
そう。
俺もStrict的なの作っててCSSでデザインはしてるけど、
未だにブラウザの解釈の違いに悩まされる。
と言うかわからないところだらけ。

正しいHTMLを書いてデザインはすべてCSSでやれと言うなら、
UAごとの違いについてもちゃんとした説明が必要だと思う。
例えばMacIEではどうこうだからwidth指定はちゃんとしとけ、とか。
そうじゃないとCSSでやるとこが自分にとってマイナスにしかならないと感じるのでは？
大変な思いまでしてやろうと思う人がはたして何人いるだろうか…。

>>720
でも、いきなり float とか position なんて要るかなぁ。
こちらもイチから作る訳で、
やはり最初は少なくても仕方が無いと思うんだけど。

総論というか、全体的な方針としては
「CSS の解説を充実させる」ってことで、、
最終的にはそういうことも盛り込むべきだけれど、
あくまで本質は HTML な訳だし。

>>721
＞あくまで本質は HTML な訳だし。
禿同。

で、なんでスタイルは後回しなのか？と聞かれたら、

執筆(+編集)とレイアウトは別作業だよな。
別作業だからファイルを分けると楽なんだよ。
という説明なら初心者を誘導しやすいかな？

執筆：元の文章書き
編集：タグつけ
レイアウト：スタイルシート弄り
こんな感じで。JavaScriptの外部スクリプトはどう誘導しようか？ｗ

CSSをどういうタイミングでどう出すか、ってのはかなり大事かも。
あまりもったいぶってあとから出しちゃうと逆効果だから、
html head title body p a img くらいまで学んだ時点で簡単なCSSを導入かな？
要素数が少ない段階で基本的なCSSの書式を知っておけば、応用が利きやすいと思うし。

文書型宣言は最初から「おまじない」として固定しちゃえばいいと思う。
Strictが前提だから、何種類も掲げる必要はないわけで。
metaのhttp-equiv属性なんかも「おまじない」にしてしまうべきなのか？

headやbodyなどの基本的な構造は「おまじない」にしない方がいいと
思うけど、文書型宣言やmetaのhttp-equiv属性などはとりあえず
「おまじない」でいいと思う。
解説をつけるとしても、書くのも読ますのも後回しで。
なんだったら、「くわしく勉強したい方は……」って感じで、他の解説
サイトの該当するページにリンク貼るだけでもよいのでは？

>>714
＞Strict は Transitional より要素も属性も少なく、覚えるだけなら難しくないはずだ。

確かに覚えるだけなら楽だろうが、
適切にマークアップ出来るかが問題。
例えばパンくずリスト。
以前に ol 要素か？という話し合いがあったような気がするが、
オイラはリストでは無いと思うし、 p 要素を使う。

>>722
＞執筆(+編集)とレイアウトは別作業だよな。
＞別作業だからファイルを分けると楽なんだよ。

それよりも、サイトで何を発信したいのかを考えさせるべきとも思う。
この場合、あなたはレイアウトを見せたいの？って感じかな。

>>723
＞html head title body p a img くらいまで学んだ時点で

hn 要素も(　ﾟдﾟ)ﾎｽｨ…

おまじないってのはいいね。
でも、最後の方のステップではちゃんと教えた方がいいと思う。

>>725
俺はパンくずリストは段落じゃ無いと思うからdiv。
そう言う意見が割れるようなものは取り敢えず伏せておけば？

>>726
伏せるというか、文脈がはっきりしていればマークアップは本来自然と成立するものだけど、
必ずしも一意に定まると限った話でもないと思うのね。

「Level1: Home ＞ Level2: Profile ＞ Level3: Hobby」
こういう認識でパンくずリストがあるならolだろうし、
「このコンテンツは [２ちゃんねる] の [Web制作板] に含まれる [Strict-HTMLスレッド] です」
と書いても同じ役割のものを置けるわけで、これだとpが妥当だろう。
# ちと強引ではあるが（ｗ

「○○の場合は××でなければならない」を強調しすぎると、やはり敷居が高いかなとも思う。
「マークアップに迷いが生じることはある、それでもかまわないからそのときどきで
『たぶん最適』なものを選べばいいのであって、間違ってたらあとから直せばいい」
というスタンスではいかんのだろうか。

いきなりvalidなソースを書けるようになるなんて期待してはいけない。
ただ、近いものはわりと簡単に書けるんだという感想を持ってもらいたい。
で、そこから「よりStrictなもの」を書こうとする意欲が出発すると思う。

>>725
hnを書き忘れてました。確かにﾎｽｨ。

　最初に HTML をやると、どうしても「レイアウト指定言語」だと思い込む人が居るので
（栄えと内容の分離概念が全く存在しない人がいて、HTML はレイアウト指定言語で、CSS はレイアウト拡張規格と勘違いする）
　最初に well-formed XML document で markup の基本ルールを教えて、直後に html head title body p hn + CSS を一気に畳み掛けるように教える、と言う方式を提案。

　あと、img 要素は最初に覚えると（特に width, height 属性のせいで）HTML は見栄えを制御しない点に関して理解を妨げる気がするので、CSS の後にする事も強く提案。

HTMLの要素の用例だけは充実させてほしいなぁ。
とほほさんの所に足りないものの代表格。

あと、まったく知らない人向けと、不思議まくあぷをかじった人向けで
切り口は違うような。

後者対策の方がむしろやっかいだと思う。

何か新鮮な体験を与えて、目から鱗を落としてからじゃないと話を進められない気が。
目に鱗を残したまま話をするとアレルギーを生むだけだと思われ。

部分的にこうしたい！って欲求があるわけだが
たとえば、文章中の一部分を文字をでかくしたいとか、そういうのは
結構CSSだと面倒ですね。面倒というのもあるけど、そもそも難しいというのもあるかもしれない
もちろん、こつなどを理解すれば簡単なわけだけど

その場合、「こっちの方が簡単じゃん」という疑問がわくわけだが
相殺できるぐらいの理由がないと、難しいな

>その場合、「こっちの方が簡単じゃん」という疑問がわくわけだが
>相殺できるぐらいの理由がないと、難しいな
　やっぱ CSS 切り替え機能か？
　一つの HTML に一つの CSS なら font tag で文字に色付けても何とかなるが、
複数の CSS だとそうはいかない、と言う点を強調するのはどうだろうか。

説明にはブラウザ毎の画面付説明があったら嬉しいなぁ
IE5.x IE6 NN4.x N6 Mozilla Opera MacIE Cab Lynxとか
とてつもない手間だけど
ブラウザなんか意識するなと言われればそれまでだけど

>>730
私としては、そうは思わないかも。
とにかく、最初に文章が存在するというのは大きいと思う。

というのは、Strictとはまでは行かなくても、
普通に構造化したマークアップさえしてもらえれば、
CSSのテンプレートを被せるだけで
見栄えが自由自在に変わる。

これだけで、CSSの良さは解るんじゃないかと。
そうすりゃ、不思議マークアップも自然と消えるような。

やはり、文章が無いのは、如何ともし難い。

やはり、まったくの初心者と不思議マークアップをかじった人とでは、
解説は別にした方がよさそうな気がする（導入の部分だけでも）。
たとえば、CSS切換機能についても、まったくの初心者に教えると、
かえって混乱したり面食らったりしないか心配。

>>735
ただ現状の「ホームページ」は文章が存在していない気がする。
寧ろ、言葉を切り貼りしている感じ。

>たとえば、CSS切換機能についても、まったくの初心者に教えると、
>かえって混乱したり面食らったりしないか心配。
　確かに。

で、 >>734 の意見に付加する形で再提案。
　幾つかのユーザースタイルシートを用意しておいてスタイルシートごとの画面を紹介すると言うのはどうか。その中に各 browser のデフォルトスタイルシートも混ぜる、と言う方向で。

　初心者利用率が圧倒的に多いと思われる win の internet explorer 向けなら、ユーザースタイルシートの適用法は結構簡単に教えられるし。

> たとえば、文章中の一部分を文字をでかくしたいとか、そういうのは
> 結構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)を使用すればよい

名前空間http://www.w3.org/TR/xhtmlとあるのは
http://www.w3.org/1999/xhtmlの間違い

なんとなく拡大するなら big 要素でいいかと・・・。
ダメですか？そうですか・・・。

>738
「作れスレ」でやってる掲示板のCSSはサンプルにならないか？
http://pc.2ch.net/test/read.cgi/hp/991906104/l50 スレッド
http://www32.tok2.com/home/css/clip/joyful.cgi 掲示板（つーかアプローダだけど）

もちろん、このサイトを教えちゃダメだけど、
ここのお題と、適当にいくつかのシートをピックアップして
例示してやればいい。

なにやら、DOS/V POWER REPORTという雑誌で6月号あたりにStrictな掲示板スクリプトの特集をやるらしい
（Strictなのだけじゃないだろうが…）
（しかも特集といっても2〜3行の予定らしい）

2〜3行？

特集なのか？（ｗ

どんなに「ホームページ」をなんか勘違いしてても
各コンテンツにはそれなりに文章があるものだと思うのだが。
文章にならなくてどうしようもないのって
ナビゲーションが関わる部分じゃないだろうか。

たとえばパンくずリストは、文章の時点では存在しない。
マークアップして、サイトの一コンテンツに加えた時点で、初めて必要になる。
初心者が気合を入れると思われる、サイトのトップページも同じ。
各コンテンツにとって、トップページは必要ない。
多くの場合、トップページに期待されるのはナビゲーション機能でしかない。

ナビゲーションは文章とは本来別のものだけど、他に現実的な手段がないから
HTML で無理矢理表現して埋め込まなきゃならない。
だから、不自然だったり、適切な要素がなかったり、人によって見解が分かれたりする。

解説の最後の最後でいいと思うけど、
HTML の限界というか、HTML に仕様外の機能が要求されている現状があって
*仕方なく* 適切とも思えない記述を選ばざるを得ない場合があることにも
触れてもいいんじゃないかな。
結果としてテーブルレイアウトに逝ってしまったとしても
本当は不適切だということさえ伝わっていれば、後は個人の価値観だと思うんだ。

“Netscapeの復活”でWeb開発者は夜も眠れない？
http://www.zdnet.co.jp/news/0203/28/e_aol.html

色んなブラウザが出回れば
「あのブラウザだと表示が崩れる！どうしよう？」
「StrictなHTMLはブラウザに依存しません！」
みたいな流れに…ならんかな。

>>747
ならないだろうなあ。
「StrictなHTMLは表示が崩れません」じゃないから。

「どのブラウザでも同じ見ばえ＝(・∀・)ｲｲ!」
この流れに乗ってる限りダメだろう...(ｳﾄｩ

まずは「見た目より中身」という考えを徹底させないと。

…………無理だろうなぁ。

閲覧者である時に「見た目よりも中身」って思ってないと難しいよね...
制作者じゃなくて閲覧者を教育しないとダメなのかも(禿欝

侍魂とか、要は中身だって事のいい例だろう。

>>750-751
見た目は見た目、文章は文章だ。
サイトの主眼が見た目にあるサイトは、見た目こそが中身なのだ。

CSSで見た目を作ってブラウザ間で表示差が出ない(ブラウザバグがない)
状況が望まれるだけかも。

>>752
侍魂は見た目不可欠でしょ。
ただ、実現方法がああなってるだけで。

侍魂のようなサイトは見た目が不可欠なのだから、
そもそも HTML で書こうというのが間違い。
Transitional/Strict 関係なく。

HTMLぐらい簡単で,さらに高度なレイアウトができるマークアップ言語を作れって事か。


………Curlは簡単じゃないな。

以前から思っていたことなんだけど、「やたらとデカい字を多用する」
「行間をたくさん空けて1行ずつ読ませる」というのを「侍魂風」というなら、
CSSを使っても再現できるのでは？
字をデカくするのは「強調」だろうから、emやstorongにfont-sizeを指定して
やればいいだろうし、行間空けるのも、br要素をたくさんぶちこむより、
p要素にheight : 100%;とか指定してやった方が、画面の縦幅の小さいノート
パソコンとかでも読みやすいだろうし。
問題は、CSSが無効な環境でも、きちんと「面白い」文章になってるかどうかだけど。

つまりStrictな「侍魂を超えるサイト」をヲレたちで(以下略)

望みは高く果てしなく……一休さんのとんちで何とかなりませんかね、さよちゃん。

>>757
できなくは無いだろうけどかなり再利用性の低いものになると思われ。

>>757
でもなんていうか、いわゆる <em class="red"> とか
<strong class="level7"> とかになりそうな気がしないでもないでも。
あの場合、 br も 1 個と 10 個じゃ意味違うし、
同じ 10 個でも意味は同じじゃないだろうし。
CSS で再現できなくはないだろうけど、 valid なだけにしかできないと思う。

ん？俺が言ったのは、侍魂はそんなに見た目のデザインかっこつけてないけど、
それでも十分人を引きつけてるって事です。
プレインテキストでも十分いけるというか。
強調マークアップのことは別の問題として。
って、何か空気読めてなかったみたいでごめんなさい。

CSSでイケてるデザインサイトスレにあった
ISO-HTMLで侍魂風のやつ。
http://wangando.com/text/iso-ijiri.shtml

作者も「こうでもしないと無理」とか言ってたからなぁ。

見た目の好みもさまざまだし、インパクトを与える手法も一様ではないんだから、
侍魂のクローンを作ることにこだわらなくてもいいと思うなぁ。
確かに物理マークアップは巧いんだが（ｗ
ウケた理由は更新が高頻度だったり語彙が平易だったり、いろいろあるんだし。

我々がやろうとしているマークアップやデザインの手法は彼とは別のものなので、
違う形でインパクトが与えられればそれでもいいと思ほゆ。

ちなみに私は侍魂よりも「それだけは聞かんとってくれ」のファン。

# つか、独自路線でいいからウケるものを作って、侍魂なりろじぱらなりに
# リンクされるくらいになるのが王道か？（ｗ

まあ、一発ネタは再利用できないよな。

話ズレるけど、ネタ文書の一発ネタスタイルをStrict的にやるなら
「ここが笑いどころ」とか、「オチ」とかをclassで指定して、
ページごとに別のスタイルシートを当てるとかかな？

>>763
> 我々がやろうとしているマークアップやデザインの手法は彼とは別のものなので、
解説として、彼のような手法をとりたい方は他所へどうぞ、ということ？
まあそれしかいいようないだろうと思うけど。

あの無料サーバでStrictなページ作りって無謀ですか？
やっぱり広告が入るから無理ですかねぇ。ってか無理ですね。
せめて、こっち側で広告のタグ等を弄れれば…苦労しないんですけど。
はぁ、なんか対応策あります？広告消すっていうゲスな方法以外で？

>>766
ない

>>766
広告が入らない無料サーバを使う（ごく稀に存在します）

>>765
近いものはできるわけだし、別に排除する必要はないと思うんだけど。
うーん、実物を作ってみて検討するかな。
そうでもしないとこの胸のモヤモヤ感が消えない。

意味不明でｺﾞﾒｿ

>>766
かめぞーたんのところは？

うーん、頑張って広告はいらないアカウント取得してみます。
…無理だったら諦めて有料を借ります。はい。
ありがとーでした。(;´Д`)フゥ

だれかがどこかに書いてたけど、XREA なら広告をいじれるよ。
でも「申し訳ありませんが、新規登録は準備中です。」だって。

まあレン鯖行って色々調べてみれ。

>919
是非頼む。

まだ不確かなんだけど、友達の家が襲撃されるかもしれない状況らしい。
しばらくメールチェックをさぼっていたら、襲撃予告のメールが届いてたとか・・・
しかも全く知らない人から。
とりあえず、間違いであることを祈ります・・・
やはり金曜日は危険なのか・・・

・・・ｽﾏｿ。
誤爆しました・・・
よりによってStrictスレに書き込んでしまった。
逝ってきます。

>>773
ていうか、すんげぇ気になるんだけど（ｗ

XHTML(メイン)+CSS(サブ)がW3Cの考え方、スタイルがうまく適用されなくても内容が伝わればあきらめるべきでは？
スタイル・デザインを(内容よりも)重視するならXSL(XSLTではなく、XSL)、SVGがぴったりだと思うし、わざわざXHTML使って大変な思いをすることもない。PDFでもいいし。

>>773
そういや、そんなメール送ったなぁ。

>>766
エクスリアならできる。<!--nobanner-->で消して、広告挿入タグを自力で
入れる。XHTMLもオッケー。しかもエクスリア公認。

>>766-770
もし意味が分かって使えるなら

Geocities で valid な HTML を
http://www.geocities.co.jp/Hollywood-Studio/8691/
isweb版もある。

>>779
それって大胆な発想ですね。面白い（ｗ

>>779
まあ、それは valid にするだけなんで、strict なわけではないけど。

不思議マークアップはともかく、
無料のサービスだと valid になってるってだけでも珍しいのかな?

>>781
御意。一応制作者サイドとしては Strict⊂Valid ということで
Y6LdipERの手伝いになればと思って。

> 無料のサービスだと valid になってるってだけでも珍しいのかな?
言うまでもないでしょう。Strict なソースで公開するのも
至難の技でしょうが、一応応援。

広告はいつなんどきでも変えられる可能性があるから、追従作業は大変だ。それに追従作業中はInvaildになるのもちょっと。しかも、明らかにW3C非推奨のDTDでしょ？ちょっと無理があると思う。そのくらいやるなら拡張子.xmlにしたら？

携帯メディアなるものが、登場してきてXHTML basic

ブラウザごとに、要素の表現方法が違うので
* {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では中央寄せにはなりません。
どうしてでしょうか？

port5.comは広告ないみたい。100MBの転送量制限あるけど。
http://pc.2ch.net/test/read.cgi/hp/1015663855/

>>785
えーっとね
http://www2u.biglobe.ne.jp/~zashiki/css-make/t-a/index.html
ここ読めばだいたいは分かると思うけど…。

あと
margin : 0 0 0 0;
で一つにまとめた方が良いと思うよ。
ってかあんまりStrictに関係なくない？

HTMLもHEADもBODYも書かなかったら、広告が消えてしまうスペースが結構あるのはどうにかならんか。鳥とか。
titleに噛ませてくれればいいのに。

>>785
UAのデフォルトの表示やユーザースタイルシートは大切だと思います。
変更したい個所を個別に変えることには賛成しますが、
一括して変更することは賛成できません。

# ただ、イタリック体って
# 正直、読みにくいと私も思います。

>>789 >>785
勿論、文書構造が解る様に、更に色々足す必要は有るけれど、
とりあえずデフォルトスタイルシートを潰す為、と考えれば
全然問題無い。

＞ブロック要素の中央寄せ
基本的には、>>786の出したURIなんだけど、
IE5.5以下とIE6.0の互換モードでは、
text-align:centerで、ボックスがセンタリングされる形になってしまう。
widthやheightの解釈と並んで、IEが嫌われる理由の一つなんだけど、
ここらは、CSSバグ辞典スレの方が解り易いかも。

＞margin : 0 0 0 0;
ていうか、margin:0で良い様な。

＞ブロック要素の中央寄せ

左右のマージンと、ボックスの幅を足して100%になるようにすれば
大体上手くいったような気がする。
ボックスを入れ子にしていくとmozillaでヘンなことになるかも…

accesskeyはXHTML basicで使用しちゃいけないんですか？

>>785
デフォルトスタイルシートを潰したいなら
ズボラしないで全要素全プロパティ書け。

というのは過激派の意見でしょうか?

　話の流れを無視して申し訳ないが、今から（所謂）「ホームページ」教室を書くなら、
HTML ではなくXHTML の解説を行ったほうがよいの？

　W3C は明らかに HTML から XHTML に移行したがっている見たいだし、
これから Web browser は XML パーサになっていくみたいだし（私見）。

>>793
全要素全プロパティの指定が * では？

>>795
全称セレクタは理解してるが、
Strictスレ的に全要素同じ指定はありえないと思われ。

>>794
流れからするとXHTMLかな。
今の状態だとXHTMLで「ホームページ講座」ってのは見かけないし。
個人的にもそーゆーページ見たいし。

>>773が気になる・・・その後の解説聞きたい・・・

>>785,>>793
僕も最近全要素をまっさらにしようとして
* {hogehoge---}
という感じでやったんだけど、これだと
あとで指定した設定がまったくカスケードしなくなってしまうので
全然カスケーディングスタイルシートではなくなってしまいました。
継承するすばらしさをなくしてはじめて知りました。

まあれだ、全要素リセットしたかったら
ねぎま氏作のリセット用シートをありがたく使わせてもらうのが
手っ取り早いと思う。

っていうかスレ違いだったかも。
ごめんなさい。

全称セレクタ使わずにCSS2仕様のAppendix Aあたりの
サンプルシートを引っ張ってくるって言うのはダメですかね…
http://www.w3.org/TR/REC-CSS2/sample.html
っていうか、昔XHTML+CSSをtext/xmlな形でブラウザに食わせたら
全部インラインになって(当たり前)これを引っ張ってきて使ったことがある。

>>800
あれ使うと妙な表示になるUAもあるよ。
MacIEはフレームのページが閲覧不能になるし、
あとbrにdisplay:blockを指定するとtable周りが潰れる。
（バグ辞典スレ参照）

要素に対してスタイルシートを持つUAの為に指定を省くか、
スタイルシートを持たないUAの為に全部指定してやるか、
が難しい。例えばMozillaのabbr/acronymね。

UAの持つスタイルシートやユーザースタイルシートを参照したり、
それがある場合と無い場合を振り分けて指定出来る様になって欲しいね。

>>796
基本的に全要素指定しておいて、後で個別に設定をカスケードさせるのが、
カスケーディングスタイルシートであって、十分に strict な運用だと思われ。

>>798
inherit などを上手く使えば十分カスケードするはず。

* {font-weight:inherit;}
body {font-weight:normal;}
h1,h2,h3,h4,h5,h6,dt,th{font-weight:bold;}

　例えばこんな感じ。

CSS1 Specification の Appendix.A に HTML2.0 のサンプルスタイルシートが
載っていますが、現行UAの用意するスタイルシートはおおよそこれに準拠しているようです。
そこで指定されているセレクタ、プロパティについて値を上書きすれば、
デフォルトのスタイルはつぶせるのではないでしょうか？
http://www.w3.org/TR/REC-CSS1#appendix-a

>>802
transparentが黒くなるのは知っていたが
inheritが緑色になるので鬱@NS4.x

ｽﾚ違いsage

ローマ数字の場合、
実体参照させる（&#8544;〜）のと、
アルファベットの組み合わせで代用する（I,II,III〜）のとでは、
どちらがStrictなんでしょうか？

読み上げ的UAを思うと、実体参照させるべきだとは思うんだけど、
ただローマ数字がそもそもアルファベットの組み合わせだという説があるらしく、
それが正しければ、別にアルファベット表記でも問題無い気もします。

でも、CSSでupper-romanなんて値があるんだから、
実体参照が正しい様な気もするんですが．．．。

>>805
以前某方面でも話題になったことがあったような。

どちらが望ましいか、と言えば文字参照の方が好ましいだろうけども、
漏れは下記なんかを読んで、どっちでもいいかなあと思っている。
http://satsuki.sakura.ne.jp/~rockman/diary/200107.html#d25

# こまいことだが、この場合は ○文字参照 ×実体参照
実体参照というのは &amp; などのような &名前; の形式のやつを言う。
&#数値; とか &#x数値; とかは文字参照と言う。

>>806
「数値文字参照(Numeric Character Reference)」
「文字実体参照(Character Entity Reference)」

の方がベターでは。
まぁ、名前指定文字参照と誤解されたりはしないと思うけど。

ところで、705の件はどなったの？

>>808
まず誰か最初にリソース揃えたやつが晒して、
それに対して皆が突っ込む。でいいのでは？

一応俺も書いてないことはないが晒せるほど量が揃ってない。

ここにあるのが、草稿じゃないの？
http://pc.2ch.net/test/read.cgi/hp/1015303243/165-

>>705の企画の協力するのにやぶさかではないのだけれど、
>>810のスレの趣旨がよく分からない。

>>806-807
勝手に、（数値文字参照＋文字実体参照）＝実体参照
と思い込んでいたのですが、
良く考えると、ampやcopyが実体なんだから、
数値に対して実体というのは、矛盾してますね。

で、これらを総称する言葉が内田訳では、
「文字参照」になっている様に解釈出来るんですが、
これで問題無いんですよね？
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/charset.html#h-5.3

>>812
ttp://8120.teacup.com/pastelsbadges/bbs

のログに参照の話が載ってますよ。

.....

>>728
まさにそういう感じの解説を書いてる最中だったけど、需要あるかな?

>>792
使えるよ。まず lint や validator でチェックするが吉。

>>812
SGML 的には

文字参照 ::=
　　数値指定文字参照(&#38;) | 名前指定文字参照(&#TAB;)
　　| 十六進数文字参照(&#x20;)

で、「文字参照」という語は他の意味を持つ「用語」として定義されている。
いわゆる実体参照は必ずしも「文字」を参照するとは限らないので、
文字参照と呼ぶのは本来余り適切でない。

例えば、<!ENTITY amp "<p>段落</p>" >　と宣言されていれば、
amp の置換テキストは「文字」ではなく「要素」になるわけだし。

でもまあ、HTML の場合には「一般実体参照=数値指定文字参照」なので、
両方ひっくるめて「文字参照」と呼ぶのもありかなあ。
…というのが >>813 のリンク先の内容ね。

ぼちぼち構想が固まってきたんで、Strictな解説サイトのたたき台を出しまふ。
今日中にとっかかりだけでも出せるかな？
余裕があればあぷろだも提供するかも新米。

関連する議論はこのスレで続行をきぼん。
ウエイトが大きくなってきてうざくなったら、その時に手を打てばいいかなと考えてまふ。

>>816
援護しますです。アプロダ出来たら、くだらないネタで提供します。
しかし…いつもながらに下がってるな。このスレ。（ｗ

age

悲しい体験…聞いてください。

うちのサイトトップページをStrictで作ってそこからFlashMXページとStrictページへのリンクを張っているのですが、FlashMXページのアクセスの方が多い。
まぁ、どっちも本気で作ったし画像中心サイトだから見栄えが良い方、UAが対応してるなら最適な方を選んだ方がいいのはわかるのですが…それでも1日1500アクセスの5%程度しかStrictページが需要がないのが悲しい…

以上、愚痴でした。すっきりしました。
スレッド汚してすみません。

>>819
FlashMX ページのほうがメインというかオススメです！
と言外に言ってるみたいな配置をしてるのでわ、とか。
たとえば FlashMX へのリンクが左で Strict が右にあるとか。
フレーム有り／無しをえらべるページでも、フレームはウザイなとか
思ってるのに、左側にある「有り」を選んでしまう。
サブ（のようにみえる）ほうは、なにか更新が澱んでそうな印象あるし。

なんか名前にへんなのがはいった…。

>>820
> サブ（のようにみえる）ほうは、なにか更新が澱んでそうな印象あるし。

あるね。確かに。

Strictの方を見せたければ

快適なHTMLバージョン/ロードの長いFlashMXバージョン

とか書いて誘導しないとね。確かに。

>>816
>たたき台
既存のサイトをいくつか上げて、
ここが良いから真似しようとか、ここが悪いから改善しようとか、
そこからはじめます?

まったくのゼロから始めるのって難しいでしょうし

テーブルはデザインのために使わなければ使っても良いですか？
下のアドレスのように、テーブルを使って、和暦西暦一覧表を
http://www.city.suwa.nagano.jp/scm/dat/wareki2/wareki_004.htm
作ろうと思うのですが、これはデザインのためではないので
良いですか？

>>825
こんな質問が出てくるのが少し嘆かわしくもあるけれど、
tableを表として使う分には全然構いません。そのためのものですから。

>>824
既存サイトの研究は必要でしょうね。
作り始めたはいいものの、網羅性にこだわってしまいわかりにくくなったので
公開を見合わせてます。
うぅむ　どうしたものか。

>>827
目次をうｐ

<TD> </TD>はいいの？

>>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を適宜挙げていく……
という感じでイメージしてますが、いかがなもんでしょ。

>>826
ありがとうございます。
テーブルを使って、表を作ることにします。

>>830
個人的にはもっとチュートリアルっぽくていいと思う。
初心者が作りがちな「ホームページ」をStrictに作らせる感じで。

で、2の前にol/ul/dlを紹介、CSSによるブロック要素のレイアウトの基礎(widthとfloatから)をある程度仕込む。
多分大雑把な方から説明していったほうが画面の変化が大きくて初心者の目を引きやすい。

と、思ったりした。

>>830
やっぱ素人向けにはimgがないとダメでしょう。
実際漏れも img をどうやっていれようかいつも悩むし

<p><img></p> か、 それとも
<div><img></div>

挿絵とか、写真とかいちおう見てもらいたい画像だという前提で。

>>833
俺もimgは早いほうがいいと思うけど、
インラインとブロックの区別が出来るようになってからじゃないと
危なっかしくて教えてられない罠。

>>832-834
確かにol/ul/dlは需要がありそうだから早めに欲しいですね。

imgに関しては早めに扱うと正負両面あって悩んでます。
【正】空要素の導入として適切
【負】画像に頼りすぎる傾向を招きかねない
　　　alt属性、width/height属性の記述が長くなり、導入としては冗長

>>824
既存のサイトのよいところに学ぶ、というのはいいと思うけど、
悪いところを挙げる、というのは注意が必要かも。
他者の欠点を批判する、というのは、たとえその批判が正当なものであっても、
善良な読者の反感を買いやすいので。
（野嵜氏のところの『斬るコーナ』や鳩丸の『のけぞる本』とかも、それで
損をしていそうな気がする）

>>835
「画像濫用のデメリット」についても、きちんと説明しておけば、後は結局、
読者の側の問題では？
それより、記述が冗長になることの方が問題だと思う。
（画像濫用についての説明を加えると、さらに記述が長くなるし……）

あぼーん

>>836
これから提供しようとしているコンテンツの中で批判をする必要はないけれど、
グループで検討するなら既存サイトの短所を健全に批判することはむしろ有益でしょう。
初心者にはそれらの批判をアピールしない方がいいだけで。

常々思うのですが、正当な主張も受け容れられやすい形で提供されなければ
人々に広がりにくくなってしまいます。
>>836で示されているような鳩丸やPC Tipsの一面は、マーケティングの面で見ると
好ましいコンテンツではありません。
かく言う私たちもまた「既存サイトの欠点を指摘」していることになるわけですが、
初心者向けコンテンツとしてはそれらの検討の結果を提示すればいいのであって、
過程は隠しておいていいんじゃないか、ということです。

「正当な批判」を認めないやつを「善良な読者」と言えるのか？
俺的には構わないと思うがなぁ。

>>840
Web制作支援サイトの相互批判は有益な議論だと思いますが、
初心者にとっては「次のステップ」でいいんでは？
別に最初から目にしなければならない話題ではないと思うけど。

初心者に媚びる必要は全くないけども
たとえ健全であれ、批判コンテンツがStrictなマークアップの啓蒙を妨げるなら、
それらを同居させるべきではないと思うわけで。

健全な批判はこの板でもできるわけだし、あるいは同じように共同サイトとして
世に訴えるのもありだと思うんだけど、
コンテンツとしては「それはそれ、これはこれ」の方がいいんじゃないかな。

て優香このあたりのことはすでに潜伏中のスレで書いてたりする。
http://pc.2ch.net/test/read.cgi/hp/1015303243/180n

>>840
ま、批判し出すと、キリがないというか、
某こみゅーんの論争にありがちな、やり過ぎてしまう危険もあるしなぁ。

＞インライン画像
alt属性辺りは、画像off時のlynxやMozilla辺りのスクリーンショットも
見せなきゃならんだろうし、
そうなってくると、また説明が泣けてくるというか。

>>830
＞6.UAによってデフォルトのスタイルが異なることを知る
＞各種UAのデフォルトスタイルをスクリーンショットで提示

この辺りメチャメチャ期待。
中々、デフォルトスタイルシートを潰し切れないというか、
つい手を抜いてしまうというか。

>>843
私の手元にはWinIE5.5/NN6.2/NN4.7/Opera/Lynx on Cygwin、
MacIE5/NN6.2/Opera/iCab、TubroLinuxNN6/Conqueror?があるんで、
あとMacNN4.xでも入れればたいてい網羅できるかな。
TurboLinuxでスクリーンショットを撮る方法を知らんのだけど（ｗ

が、えらくめんどくさい作業であることは事実だ；

>>844
TurboLinuxでは、スクリーンショットを取るソフトがありますよ。
Turboに限らないけど。

>>830
いくつかコメント。

まず、解説の導入としては、既存の文章をマークアップして
HTML文書に仕上げていく過程を提示すべきと考えます。
というのも、まず先に文章が無いと、要素の概念を理解することが
困難と考えられるためです。

具体的には、hn要素、p要素、ul要素（もしくはol要素）、em要素、
img要素を含む文章を例として提示することで、要素の概念、
要素とタグの関係、ブロックレベル要素とインライン要素の違いを
説明できます。

ここでは、em要素は、インライン要素の代表的な例として、img要素は、
インライン要素とブロックレベル要素の差異を強調する（div要素等で
括ることで両者の違いを強調する）手がかりとして挙げています。
要素の属性についてもimg要素を手がかりに説明できるでしょう。

以上のことを説明した上で、title要素、head/body/html要素、DOCTYPE
宣言の順に説明すれば、生の文章を相互運用性に配慮したvalidなHTML
文書に仕上げていく過程を理解できると思います。

次にCSS関係ですが、4、5、7、についてはそのままでよいと思います。
ただし、CSSを見栄えの良い「ホームページ」を作るための補助的な
手段と誤解されないような配慮が求められるでしょう。

6.について、ビジュアルUAのスクリーンショットは特に必要ないと
思います。lynx、w3mなどのスクリーンショットはアクセシビリティ
との関連で提示した方がいいと思います。
ただ、各ブラウザのデフォルトスタイルシートを提示することは、
非常に良いアイデアだと思います。

サイトのコンテンツについて提案。

HTML+CSSの解説が主要コンテンツになると思いますが、
webサイト作成の前提となる知識やツールの解説や、
faq的なものも必要になってくるでしょう。

前者は、ローカルとリモート（サーバ）の違い、FTPソフトの使い方、
エディタって何、というレベルの解説、faq集については、
初心者スレの冒頭に書かれているようなものを想定しています。

て優香←これキモイ

読み返すと厨房みたいな文章だ。申し訳ない。

俺もSTRICT系のページを作っていたけど
挫折してたんだよねええ
再開してみよ

>>840
まあ、「善男善女」ぐらいのニュアンスで。

>>846
まず文章を用意することには賛成。ありがちな、
「なんでもいいから、とにかくホームページ作りたい」
ではなく、
「表現したいことがある。その手段としてのウェブサイト」
というのが大事だと思う。
それがどうしても受け入れられない初心者には、何をどう教えても
無駄のような気がするし。

あと、

> HTML+CSSの解説が主要コンテンツになると思いますが、
> webサイト作成の前提となる知識やツールの解説や、
> faq的なものも必要になってくるでしょう。

にも賛成。
「ほしい情報はここでぜんぶ手に入る」というのは喜ばれるだろうから、
たとえよそのサイトで必要な解説が手に入る場合でも、できるだけ網羅的に
やる（最初は無理でも、将来的には）方がいいのでは。

まあ、あまり親切すぎない方が、初心者に「学ぶ姿勢」を身につけてもらう
という、意味ではいいのかもしれないけど……

おまえら初心者向けなのに、専門用語おおすぎ

今はまだ構成段階だからいいんじゃない？
文章が出来ていく中で「これには解説がいる」とか出てくるだろうし。
はじめから立派なのなんてできないんだから、とにかくどんどんやっていけばいいんじゃないかな。

「とにかくホームページ」で作られたサイトの方が、
かえって変な気負いがなくって良いんだけどな。
適当な日記だけでも十分面白いし、
その人の趣味が前に出てくればそのうち路線変更するでしょ。

ただ、個人情報についてはちゃんと注意を喚起した方がいいね。

そうだね、難しすぎる専門用語には気を付けた方が良いよね。

一番最後で良いから、"転載"や"引用"についても解説があると良いかも
あと、直リンについても

今、ワープロ専用機で作成されたデータのHTML化を、
死ぬ思いでやってる（プリントアウトで提供されたため、手打ちなのだよ……）んだけど、
HTMLの利点として、基本的に環境を選ばないという点を強調してやっておくれでないかい。

この点が知れ渡ると、IE5以上でないと駄目、とかいうページも減る、

と今は信じたい……

>>853
将来的には、StrictなとほほのWWW入門という感じになれればいいですね。

>>848のコンテンツに加えて、関連スレ、関連サイトへのリンクや、書籍の紹介を
加えると、web板のポータルサイト的なものができあがる。
それをこのスレで作ってしまうことに意義がある。

/* スレの話題がずれてきたので、新スレをたてるか、外部に専用の板を作った方がいいような。 */

しかし、それだけ大きくなると管理（制作/立案/..etc）が大変だな。
数人でやるのがベストだろうが、それぞれStrictに対する（初心者に対する）考えを一本に絞った方が良いだろうし…。

/* しかしこのスレではStrictネタが既に枯渇してきているのも事実。誰かが質問すれば良いんだけどヽ(´ー`)ﾉ */

以前書きかけていたリファレンスを元に作りかけてましたが、
やはりチュートリアルは書き下ろさないと整合性が取れないと思い
最初から書き直してます。
大幅に遅れましたが、日付が変わるまでに2枚くらいたたき台を出せるかな。

で、議論の続行はどういう形でやりましょかね。
選択肢としては、
<ol>
　<li>このスレで続行</li>
　<li>独立スレ立てる</li>
　<li>したらばを借りる</li>
　<li>2ch互換スクリプトを設置しる</li>
</ol>
こんなもんかしら。

せっかく広く建設的に意見交換する雰囲気ができてきてるんで、
できたらあまり議論の環境を変えたくないです、個人的には。
なので、上記選択肢の順番は上から順に私の希望順ですな。
# いちおう手元にはうなぎスクリプトがあってローカル動作確認済みだけど。

今までの成果をまとめるわけですから、
このスレで続ける方が良いと思います。

>>862
このままでも構わないんですけど、他の話題が入ってきたときに、
同時進行になると文脈を読みわけるのがツライかな、と。
過去にあった「Ｑ要素：インライン引用文のマークアップについて」のように、
　http://natto.2ch.net/hp/kako/1002/10027/1002750163.html
別スレで徹底的に話し合うのもいいのでは？

#「HTML+CSS解説サイトを作ろう」が落ちてなければ再利用できたのに…
　http://pc.2ch.net/test/read.cgi/hp/1009094059/l50

Strictスレ3.1でも立ててやるか？＞解説サイト話

このスレ再利用出来ないかな？

ホームページの作り方
http://pc.2ch.net/test/read.cgi/hp/1011834614/

どっちにせよあと少しで新スレ移行になるからねえ。
ここで続けるなら１に「現在Strict入門サイトについての議論が
中心になっていますが、それ以外の話題もどんどんどうぞ」とか
書いてみたらどうでしょう。

そんなにスレの伸びが早い訳じゃないから、ここで一本に絞って良いんじゃないでしょうか？

流れに乗っていない話題ができるかどうかのテストを兼ねて．
次の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のように書くようにしてるけど．

>>869
そもそも日本語訳は必要ないとして、

<acronym title="Sprots and Music Assembled People">SMAP</acronym>

とするか、日本語訳を解説の一部に盛り込んで、

<acronym title="Sprots and Music Assembled People"><dfn title="絶大な人気を博する男性芸能人5人組。名称は「運動と音楽を融合したグループ」の意。">SMAP</dfn></acronym>

かなあ。

真のstrictはabbrダヨ！

あと、dfnは用法が違うんで無いかい？

>>871
1行目が意味不明なんですけど…マジで。SMAPは頭字語だよ？

dfnは文脈の中で
…<dfn>SMAP</dfn>すなわち、絶大な人気を博する男性芸能人5人組。名称は「運動と音楽を融合したグループ」…
ってな感じで、定義語とその説明はDOM的には明確に
関連付けできず、文脈依存。…だったよね？

>>872
acronym要素とabbr要素については>>205-234あたりを参照されるとよろしいかと。

>>872
W3C的にはabbrを推してたんだけど（意味的にacronymも含むと言う事で）、
IEが先にacronymだけを実装しちゃっていたから仕方なく仕様に入れたんだと。
で、それからいつまで経ってもIEはabbrを実装してくれない、と。
でも、HTML4のサンプルを見るとそう言う使い分けなのかと思っちゃうよね。

どっちにしてもコンセンサスを維持しようとしなかった御蔭で
ユーザーに皺寄せが来ている訳だ。

WinIEならinnerHTMLからabbrを拾ってacronymに変換するJScript functionを
読み込み終了時に呼び出す様な拡張は出来るのかな？

>>875
>>241を見る限りでは、ちょっと面倒かも。
技術的には十分可能だと思うけど。

>>876
いやだから標準DOMじゃなくてinnerHTMLね。
WinIE以外で動く必要無いんだから。

>>877
ああ、innerHTML中の"</?abbr"を置換するって話か。それなら簡単だなあ。

こんな感じ。

document.body.innerHTML = document.body.innerHTML.replace(/(<\/?)abbr/ig, "$1acronym");

んで拡張のほうは、データを書き換えられるHTTP Proxyを使うかBHO使うかIEの起動を監視する常駐アプリを作ればオッケーと。

連続書き込みスマソ

↑つー訳で誰かこう言うの作ってｸﾚ。俺まかーなんで何も出来ん（笑）。

あげ

今、ふと思ったんだけど…俺ってStrictでサイト作ってるけど、Strictである意義を理解せぬまま、Strictでやってしまっている事に気が付いた。（汗）
Strictである意義、意味ってなんだ？身近な例で教えてくれると助かるんだが。ちょっと、自分でもそこらへん勉強してくるか。

>>883
Strict == 仕様に厳格 == 当然の事を当然にする

>>883
>>884
つまり本来Strictであるのが当たり前で、
特別な意義だの意味だのを必要とするようなことじゃないと。
むしろ、Transitionalや不思議マークアップを選択することの方が、
なにか動機が必要ってことですかね。

＞むしろ、Transitionalや不思議マークアップを選択することの方が、
＞なにか動機が必要ってことですかね。
「直感的に記述したいから」。むしろ、これは自然。
HTML＋CSSの2重構造より、旧来のフラットなHTMLの方が直感的なのは
明らかでしょ？
とは言え、普段使っているUAに限っての話だし、肯定はしないけど。

不思議マークアップな解説書の類が氾濫してるし．
そんなのつかまされたらどうやっても不思議マークアップになってしまうというのも．

>>887
そうそう、それそれ。
だからこそStrictな入門サイトを作ろうと言う話にもなるわけで。

>>883
このスレ読み返しつつ入門サイトが出来上がるのを待ちましょうってことで．

/* おまえもなんかせえよ＞自分 */

ところで、今、図書の目録みたいなものを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)がいいのかな……
などと、ちょっとだけ悩んでいます。

>>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>

か、ですね。

項目が 2 つ以上あるのならば table で良いのでは。

表じゃないだろ

目録じゃなけりゃ、表でも構わないのでは？まぁ、目録だから表ではないんだろうけど。

もくろく 【目録】

（1）書物の目次。また、叢書の内容一覧。「文学全集の―」
（2）所蔵している、または出品されている品目を整理して書き並べたもの。カタログ。「展示品の―」「新刊書―」「財産―」
（3）贈り物の品目を書いたもの。実物の代わりに渡すことにより、その品を贈る意志表示をする。
（4）武術や芸道を弟子に伝授し終わったとき、その名目などを書いて与える文書。
（5）贈り物としての金。「いはぬ色なる山吹の花を包みし―も、明けては見ねど五十両/歌舞伎・天衣紛」

>>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 の言う通りだが、
表現したいのは目録要素ではなく、その内容の筈な訳で）

>>890
xml的に考えて再利用を考えたら(4)かな。
>891みたいな感じでもいいと思うが、
素直に(4)でいいのでわ

>>895
> (1) は DTD 的には OK だが、仕様には DT と DD は 1 対 1 (または自明な DD を
> 省略して DT が連続で) 使用されるとあるので、strict スレ的には NG。

(>>890 の) (1) は、その「自明な DD を省略して DT が連続で」
出現するパターンなので、このスレ的にも問題はないと思います
(DOM 的に扱いにくいと言うのは置いておいて)。

で、(4) が至れり尽くせりだと思うけど、
そこまでするなら table にしてしまった方が後々便利です。
目録はデータベースとして扱うものなのですから、
「作品名」「著者名」「出版社」などを列として扱えた方が
圧倒的に活用しやすい。

ということは、TABLEがどの方面から見ても良い感じ…と。
ただTABLEって難しいからなぁ…。きちんと並べていかないと。

ふと思ったんだけど、「DOM的」と言うと
DOMって言う解析処理方法のうち一つに限定してしまう事になるから、
もうちょっと範囲を拡げて「XML Infomation Set的」
「XML InfoSet的」と言ったらどうでしょう。

長いね。「DOM的」の方が簡潔でいいや。

９００げっとぉ！

>>899
はぁ？
>>900
はぁ？

>>901、君はつまらん

独り言の邪魔して怒られちった。。。

abbr要素って英語の略だけでなく日本語にも使用していいの？
例えば
<abbr title="Internet Protocol">IP</abbr>
とかはよくやるけど、
<abbr title="航空母艦">空母</abbr>
とかも良いのかな？

あと、abbr要素ってマメに付け過ぎない方がいいのかな？
例えばミリメートルの「mm」に一々
<abbr title="millimètre">mm</abbr>
なんてやってたらファイルサイズが膨大になってしまう気が。

HTMLって日本語使っていいの？（藁

>>904
前者は過去ログ参照。

＞abbr要素ってマメに付け過ぎない
あくまで補足説明なんだから、程々に。
少なくとも、単位につけるのは良くない。
まあ、対象と思われる読み手の何割か（ここは議論の余地アリ）が
解らないと思われる場合はつけるべきとか。

例としては、
<abbr title="Card Captor Sakura">CCS</abbr>は
このスレ的には微妙だけど、
某こみゅーん内では、ネタでない限り要らないとか。

基本的に、abbrとかkbd等、インライン要素の一部のマークアップの
やり過ぎは却って良くないと思う。

一般的でない略語であって、
かつページ内で初出であるものについては
Acronym なり Abbr なりで明示的にマークアップする必要があると思われ。
それ以上にやると過剰感が漂う。

ルビ振りと似たところがあるかも。

title属性は付加情報を示すためにあるもので
すべてのabbr要素につける必要はない、
というのを他のスレで見て、なるほどと思ったことがあります。

略語にはすべてabbr要素を使う必要がありますが、
そのtitle属性は適時に用いれば良いと思います。

後、"ミリメートル"についてですが、
U+339C(Square Mm)を使うのが、Strict的でしょうか

>>905
4 以降なら使っていいですが何か。

>>910
3.2 とか 2.0 でも画像とかローマ字使えば OK でしょ、「日本語」は。(w

>>909
もしかして Strict って Unicode なんすか？

>>909
ズバリ「ミリメートル」を表す文字だから、
「mm」と書くより、意味は明確じゃないかな。
たとえ、表示できないUAがあったとしても
HTML4,XHTMLなら数値文字参照はUnicodeの番号と決まってるし。

>>912
じゃあ、「0点」より「㍘」の方が、意味が明確で Strict なの?

#x3358 は compatibility だから、また意味が違うと思うが。

#x339C も compatibility じゃないの？

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
のどちらが正しいですか？

>>916
dl

>>915
あー、スマソ。「#x3300-#x33FF は compatibility だから」です。

"III" と "Ⅲ" だったら後者の方が、
っていうのには一理あると思うんだけど、っていう意味ね。

>>916
関係ないけど、weight ではなく width だと思われ。

>>916

917を補足すると、

<dl>
<dt><a><img></a></dt>
<dd>画像の説明</dd>
</dl>

というのがよろしいのではないかと。

そうですか。定義ですか。
画像を定義するのですか？

dlは定義だけじゃない。

XHTML2.0はどうなったage

レスくれた人達ありがとう。

>>922
2002年04月頃にワーキングドラフトとして公開される予定だったような
でもその気配無いね

>>916
>alt="2ch logo"
は、不適切だと思われます。
このようにすれば良いかと…
alt="2ch"

>>923
去年の夏に公開される予定だったような。

age

ここにきて伸び悩んでますね

「ぷっ」スマのHP企画を見ての嘆きレスとかあるかと思って来たけどないね

>>927
「ぷっ」スマとは一体何ぞや？
テレビは全く見ない者だからわからない・・

いつも使ってるテキストエディタがバージョンアップしたら微妙に使いづらくなった。
HTML-lintで採点のマクロがついたのは嬉しいんだが・・・
DOCタイプもuriまで入れてくれるようにメール出してみようかな（w
HTML4.01もしくはXHTML書くのに便利なテキストエディタって何かありますか？


と苦し紛れに話題を振ってみるテスト。

そろそろ次スレの予感。

>>929
秀丸がよろしい。
DOCTYPEの入力くらいならマクロの練習としてちょうどよかろ。

>>931
そうか、やはり秀丸か。
もーすぐWin自作するからそん時には秀丸かな（現在マカー）
テラパッドとかTTTエディタってどうなんでしょうか。
使ってる人います？

テラパッドを使用しています。

（　´,_ゝ`）ﾌﾟｯスマ

効率良くHTMLを書けるテキストエディタってある？
ttp://pc.2ch.net/test/read.cgi/hp/1002383563/l50

ＴＴＴ使ってます。

StrictなHTML解説の話はどうなりました?
今はお休みで、ゴールデンウィークぐらいにヒートアップするつもりですか?
他に何か原因があるのでしょうか?

>>830
>1.基礎となるHTMLの骨格を知る(ネストの理解)
>　　DOCTYPE html head body title hn p
一番最初に解説する要素は、やはりp要素でしょうか
DOCTYPEやhtml要素は、形式的なものですから…

書いてる途中でも良いので、
HTMLファイルをUPしてください。

>>937
＞StrictなHTML解説の話はどうなりました?
気になるなら自分で進めれ。俺はﾏﾀｰﾘやってるよ。

＞>1.基礎となるHTMLの骨格を知る(ネストの理解)
＞>　　DOCTYPE html head body title hn p
＞一番最初に解説する要素は、やはりp要素でしょうか
＞DOCTYPEやhtml要素は、形式的なものですから…

title要素が最重要と言う識者もいらっしゃいますなｗ

解説サイトの話が進展しないのは私の腰が重いのが大きいな。
ちょっと理想を追いすぎているのか、書いては消し書いては消ししてます。
乱雑な状態でもいいからうｐしちゃうかなぁ。

で、とりあえず他の話を振ってみる。
ttp://www.oosakaya.net/me/12.html
ここの記述ってどう感じますか？

>>939
> www.oosakaya.net/me/12.html
漏れなんかは HTML は汎用的な文書フォーマットだと思ってるから、LINK 要素って
本文の流れを不自然にするナビゲーション目的のテキストを
body の外に出せる機構として洗練されてると思うんだけど
著者にとっての HTML は、ブラウザに表示させてなんぼで
それが全てなんだろうなあ…と、そんなことを思った。
ブラウザにとらわれすぎている感じがする。無理もないけど。

>うｐしちゃうかなぁ。
いいんじゃないかなあ。どっちにしろ書いては消し書いては消しするでしょ。

>>939

> HTMLの仕様書が正しいのかどうか、現在の状況に即した仕様書であるかどうかは、だれも考慮していません。

とか、

> 日本人であること

とか、話の進め方に粗が多く、脇が甘い。
（いわゆる、ツッコミどころ満載というやつ）
まあ、言いたいことはわからないでもないけど。

ただ、将来LINK要素によるナビゲーションが使いやすい形で実装されたブラウザが
普及する可能性と、たかだか数十バイトの情報量を秤にかけたら、たとえ、
その可能性がどんなに低くても、俺は前者をとります。

Mozillaはどうした、と思ったら1年半前の文書だった

>>298, >>399
皆さん、お忙しそうですね。
私も、皆さんの議論に参加できるようにものすごい勢いで勉強します。

>>939
>W3Cの策定した仕様書（勧告を含む）が絶対的正義なのか？
　絶対とも正義とも全く思わないが（というか、何処からそんな概念が出てくるか疑問）、
少なくとも同程度の対案がないなら W3C の規格を使用し、人に薦める事に何ら抵抗はない。
　それなりに考えがあって pdf 使うし薦める、と言うなら「違う道を歩む人」って事で認められるんだが。

>結局のところ、これらはLynx依存の属性値であるということができます。
　完璧な誤認。
　俺の場合、Mozilla は勿論、IE にも javascript を仕込んで link 要素から
ナビゲーションを生成し、ショートカットキーを割り当てているので、
（本来有るべき）link 要素が存在しない site は大変に不便。

>ただの特殊ブラウザに成り下がったLynx
　ナニをlynx に拘っているのか今ひとつ不明なんだが…。
　５年、１０年たてば、現在の IE や Mozilla だって「過去の特殊なブラウザ」
に成り下がる訳で（１０年で足りなければ別に２０年でも可）特定のブラウザを引き合いにする事自体ナンセンス。
　特定の概念は古い、というなら理解できるが、link 要素って実装レベルで言えば寧ろこれからの概念じゃないかと思うのだが。

>　こうしたごく限られた人の利便性を考えるくらいの心の広さがあったら、
>99％以上の人にとって無駄でしかない部分のソースを削るということも
>考えた方が有用だと思われるからです。
　lynx が滅ぶのと、無駄なソースが減って有用な環境が滅ぶのと、どっちの方が早いか疑問。
　PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。

>>939-944
> 執筆日：2000年 9月 8日
↑おまいらここを見てくださいおながいします

時代遅れのリソース

>>945
記事が古いことは承知の上なんだけど、現に閲覧できるリソースなわけで。
で、944までのレスを見て、特定UAの表現に基づいて論評するのは
できるだけ避けた方がよさげだな、と思った次第。
だって執筆辞典でHTML4.01は存在したわけだからね。

特定UAの表現について触れるなら、バージョンアップをきちんとフォローするのが
筋じゃないかと思いまひた。

>>945
>PHS も定額制の時代に、数バイト削ってどうするのか小一時間（以下略）。
の一文は不適切だったので取り消します。
　当時の移動体通信の速度と価格を思えば、数バイト削るのが意味がある時期は（過渡的だが）確かに有った。

＃しかし、strict という思想は勿論、XML も XHTML 1.0 勧告された後に
　しちゃナンセンスなので、全体的な批判の姿勢は維持。

>>946
> 特定UAの表現に基づいて論評するのは
> できるだけ避けた方がよさげだな、と思った次第。
同意するとともに、そこが難しいところだとも思う。
いっそ XML+CSS とかだとデフォルトのスタイルとか振る舞いは無いも同然だけど
HTML は既成事実的なデフォルトスタイルがあるからねぇ。

数年前ですと、「将来賢いUAの登場に期待して」な論調だったのが、
最近は鳴かぬなら鳴かせて見せようホトトギス的に、今ある要素を
有効に使おうという風潮が少しずつ出てきてますよね。
（その典型がCSS切り替えスクリプトとか、そふぃあさんところで
いろいろやってる実験的なこととか。>>944氏もそうですか。）

そういう動きがあることをコラムのような形でいいので、触れることをきぼんぬ。

そうすると、>>939のサイトのような認識は減ると思うのねん。

>>939
なーんか重箱の隅を突付きまくって自己満足してるだけのように見えるな。

>>950
その参照は誤読を招くぞ。
次スレ立てる？

>>951
おながいします。

>951
今の進行具合なら970-980くらいまで待ってもいいんじゃない？

>>951
ああ確かに。>>950は>>939のリンク先の文書に対してね。
コテハン叩きの私怨厨と思われるのは勘弁です。言葉足らずｽﾏﾝ。
次スレはギリギリまで使い切って立てたほうがよろしいかと。

>>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 のデフォルト値と明確に区別するため、今後デファクトスタンダードと
　言ったほうがより良いのでは？

…微妙にスレ違い。失礼。

>>955
> 過去には lynx のような特殊UAも有った。だから、できるだけ汎用的な記述をしよう。
特殊 UA という発想はマズイのでは。
Mosaic 系の UA は多くの人に受け入れられたけれども、
それはHTMLブラウザの一形態であって、別に普通でも何でもないので。

ちなみに漏れの考えでは UA の仲介は HTML 閲覧の前提ではなかったりする。
プログラムに通すだけならテキストである必然性がないと思うので。
マークアップがテキストで行われ、要素名や属性名がその意味を表す単語の略記である理由は、
ソースをそのまま人間が閲覧することも想定しているからだと思う。
現にそうやって作成するわけだし。
その閲覧を補助するものとして UA があり、
要素ごとに規則的な整形を行ってそれが何の意味を持つのかを明示したり
ハイパーリンク指定でリンク先リソースを自動で GET したりする、と。

だから、特定 UA の挙動を前提にしたマークアップや
ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。

>>956
>特殊 UA という発想はマズイのでは。
　>>939 からの流れで特殊といってしまったが、たしかに今現在スタンダードでは
ないというだけで、「特殊」という言葉を使うべきでなかった。失礼。

>プログラムに通すだけならテキストである必然性がないと思うので。
　そうか？　じゃあ、javascript などのテキストのインタプリタ言語なんかは
人間”も”解釈する性質のものなのか？
>ある UA が無反応だからと言って有用なマークアップを削除してしまうことは
>そのリソースの総合的な利用価値を下げてしまう、ということだと思うんだが。
　これには激しく同意なんだが、テキストなんだから人間「も」読むちゅうことはない。
　HTML がテキストであるのは「書く時・編集する時」に特定エディタを必要としない
（つまり製作環境を限定しない）為であって、「読むとき」の都合ではないはず。

　確かに俺は必要に応じてソースも閲覧するがそれはUAが解釈できない間違ったHTMLを
仕方なく解釈したり、ヘタレ UA の機能不備やbugを補うものであって、
HTML（というか SGML）の規格そのものは閲覧時に何らかのプログラム処理を前提に
していると思うのだがどうだろうか。

>>957
SGMLはどうだか知らんが、HTMLはハイパーテキストあってのものなのだから
ソース読ませようとして作ってはいないだろう。

ソースの可読性というと各要素を脳内変換してレンダリングしているような印象があるですな（ｗ

>>958の意見に概ね賛成なんだけど、ドキュメントがワープロの書類みたいに
バイナリではないということが重要なのかな。
UAだけでなく、人間が見てもそこそこ解釈が容易ですよ、と。

言い古された話だが、ファイルタイプがtextであるということはかなり恩恵がある。
さまざまなプラットフォームからの利用が容易だし。
表示結果だけでなくソースそのものに二次利用性が高まるし。
特別な環境がなくても開発が容易だし。
UAやオーサリングツールのI/Oも楽に作れるし。

人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
だから可読性の一面はあくまで副産物だと思うわけ。

>>958
> HTMLはハイパーテキストあってのものなのだから
が激しく不可解だが、

これは別に企業サイト向けの(糞)Webデザイナー向けの
レファレンスを作る計画じゃないんだろ？
ならUAへの言及は必要なし。バグｽﾚに既にまとめてくれた方がいる。

書いてる間に茶文字氏が・・・。
>>959
> 可読性の一面はあくまで副産物
に激しく同意。

・・・てか何で人間の読みやすさなんて事を言い出したﾔｼがいるんだろう。
某方面に触発された厨の影響か(w？textであることの利点は>>959の
第2段落に要約されてる。

s/第2段落/第3段落/g;

>>960
958は s/ハイパーテキスト/ハイパーリンク/g; だと思われ。
で、HTMLの最大の長所(のひとつ)であるハイパーリンクを有効活用するには
いわゆるブラウザを通した方が恩恵にあずかれるので、
HTMLはUAに食わせるためにあるのだ、という意見だと解釈しまひた。

UAの実装状況は詳細には必要ない気がするね。
わかりやすいリソースがあるならリンクさせてもらった方が早い。
が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。

>>963
その通り。
威張る所じゃないけど。誤記スマソ。

>>963
> が、世の中「いんたぁねっと = Windows+IE」だと思いこんでいる人が多いので、
> UAの多様性を啓蒙することは値打ちがあるんじゃないかなと。

激しく同意した上で．
初心者向けの解説と言うことであれば，
むしろそのような切り口の方がわかりやすいような気もします．
「論理マークアップ」とか言われても，初心者にはﾊｧ?でしょうし．

「Aというブラウザではh1要素はでかい字になるけど，Bではセンタリングされるんだよ．
　それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
　HTMLとはそういうもので，だから，<ここはでかい字にするよ>ではなくて
　<ここは見出しだよ>にするんだよ」

って持っていき方の方がわかりやすいんじゃないかと，個人的には思ってます．
激しくガイシュツの感ｽﾝﾏｾﾝ

>>965
大筋は正しいと思うけど、
>それぞれの環境でそれぞれが使いやすいように見た目を変更できる．
ってのはちょっと違うかなと。
フォントの大小とか除けば、要素に対してセンタリングとかまで見た目を
変えられるUAは余りない。余りというか、最近のWindows用視覚系UAで
は見たことない。
IEとかOperaでユーザーサイドのスタイルシート使えば別だけど、初心者
むけの解説でそんな事書いても仕方ないし。

「それぞれの環境で表示のされ方は違うので，どんな人にでも意味が伝わるように，
<ここはでかい字にするよ>ではなくて<ここは見出しだよ>にするんだよ」

位が適当かと。

>>959
> 人間からみた可読性は、これらさまざまなメリットのひとつに過ぎないと思うんだよね。
> だから可読性の一面はあくまで副産物だと思うわけ。
可読性があるからそれらのメリットが得られるのだと考えていた。
HTML が機械処理を想定してないと言うつもりは流石にない。
# 引っ張るつもりは無いのでレス不要っす。

>>966
過去のものなら、 Mosaic がフォント設定を要素群単位でやってたよね。
# で、設定しないと日本語表示できなかった(w

初心者向けの解説にこそユーザースタイルシートって必要なんじゃないかなあ。
自分が利用しやすいように HTML をカスタマイズする、という発想は
与えられた利用法しか考えたことがない初心者にとって有益ではないだろうか。

> HTML が機械処理を想定してないと言うつもりは流石にない。
誰もこんなこと言ってないね。この行あぼーんしてくださいな。

初心者向け解説、アウトラインから書き直しつつがんがって執筆虫でございます。
脳味噌沸騰しそ……。

# HTMLってそれぞれの要素や属性が立体的に関係しあっているから
# 順序立てて語るのは難しいっすなぁ。

>>967
ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
卒業制作くらいの感じで位置づけてみようかと考えてますが、諸氏のご意見やいかに。

>ユーザスタイルシートはある程度自由にCSSを書けるようになってからだと思うんだけど。
　テンプレート的 CSS を幾つかダウンロードできるようにしておき、
実際使ってみてもらう、というのはどうでしょう？
　中身は全く解らなくても、ユーザスタイルシート（ひいてはスタイルシート全般）を
使うメリットの大きさや、HTML からプレゼンテーション要素を追放する理由をとりあえず
実際に体験してもらうって事で。

>>970
で、そのテンプレート的スタイルシートの中に、
デザインが格好良いのとかだけでなく、やたら字が大きくてくて
眼にやさしいスタイルも用意しておいて、
「見栄えをCSSに分離しておくと、弱視者やお年寄りが、自分用にこういった
スタイルを適用したりもできるんですよ」
みたいな説明があるとアクセシビリティ的にもOKだと思うのですが、いかがか。

まあ、ユーザスタイルシートに関する具体的な説明は後の方でいいと思うけど。

>>971
大きくてくて……鬱だ。

さすがに残り20切ったんで、
そろそろ新しいスレ立てた方がいいと思うんですがどうでしょう。

>>972
酸性
次は4.01とかになったりするのでせうか？

>>973
3.2 だべ。
では、 980 取った人が新スレ作成当番ということで。

>>974
げ　それでは今スレの議論はあぼーん扱いになるのですか？（ｗ

> テンプレート的 CSS を幾つかダウンロードできるようにしておき、
> 実際使ってみてもらう

これは面白いと思うね。百聞は一見にしかず。
「フォントいじりサイトスタイル」や「テキストブラウザスタイル」のユーザースタイルシートとか、
あれば面白く理解できそう。

>>976
興味をひいたり、いろいろなことができるのを知ってもらという意味では、
「有名サイト風スタイル」というのもいいかも。
ただ、HTML入門の最初の頃に提示する場合は、あまりclass属性やid属性に
たよった作りのスタイルだとマズかろうから、floatとか使いづらいのが難だけど。

うん、letter-spacing や line-height が使えるのは、
CSS の強みだしね。

letter-spacing や line-height も全部同じ値なら良いかと言えば
そうではなくて、フォントに依って、特定の値の合う合わないが、
あるんだよね。

例としては、Strict 的ではないけれど、
MS UI Gothic に letter-spacing: 0 は合わないとか、
「有名サイト風スタイル」も良いけれど、
ここら辺の微妙な感性に訴えるのも面白いと思う。

>>978

> MS UI Gothic に letter-spacing: 0 は合わないとか、

でもそういう設定をすると、MS UI Gothicを表示できない環境だと、
letter-spacingに設定した値だけが適用されて、イヤンな感じになりませんか？

って、Strict的ではない話を続けてすまん。

つーわけで、新スレ立ててきました。

http://pc.2ch.net/test/read.cgi/hp/1018719800/

>>979
一般化して考えても、san-serifなフォントで、
letter-spacing: 0 は読み難い気もするんだけどね。

MS UI Gothic の場合は、letter-spacing: 0.3emがベストだと思うけれど、
通常のsan-serif、つまり Mac で一般的な Osaka や
Winな ＭＳ Ｐゴシック は、
letter-spacing: 0.1emで上手く行く気がするし。

まあ、でもここらは色でも違うかな。
そこら辺が微妙なんだね。だからこそ、面白いというか。

おお、新スレが建っていた。