5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :Name_Not_Found:01/12/15 10:37 ID:It4Gmnsc
Strict な HTML(*) について語るスレッド Version 2.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) など。

2 :Name_Not_Found:01/12/15 10:38 ID:It4Gmnsc
関連スレ
 Strict-HTML スレッド(1.0) http://pc.2ch.net/test/read.cgi/hp/992708594/-100
 CSSコミュニティの功罪を評価するスレ その2 http://pc.2ch.net/test/read.cgi/hp/1003378794/-100
 XML、XHTMLについて語り合うスレッド http://pc.2ch.net/test/read.cgi/hp/1002461949/-100
 W3C信者と感じる瞬間 http://mentai.2ch.net/hp/kako/990/990175066.html
 W3C信者の方に質問 http://mentai.2ch.net/hp/kako/977/977621932.html
 CSSコミュニティの功罪を評価するスレ http://natto.2ch.net/hp/kako/993/993743434.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:01/12/15 10:39 ID:TLhPJy8p
( ・∀・)ノ 新スレだ!

4 :Name_Not_Found:01/12/15 10:40 ID:llwdvr9s
お疲れさまですた。

5 :Name_Not_Found:01/12/15 15:16 ID:EqykA2oR
>>1
新スレありがとう、そしてお疲れ様。

6 :Name_Not_Found:01/12/15 18:07 ID:prFPnVc0
>1
乙カレー

7 :Name_Not_Found:01/12/16 00:04 ID:2+bdy88A
>>1
お疲れさまっす。
すみけん氏スレッドまで入ってるのね。

ところで、CSSで擬似段組(?)しているサイトで、

<div class="col-left">〜</div> (註:左列)
のような記述をしているところってあるよね?あれってどうなんでしょ。

<span class="red">〜</span>
として赤い文字にしているのとあまり変わらないような気がするんだけど。
皆さんはいかが?

8 :Name_Not_Found:01/12/16 00:15 ID:7P+Uv7Q2
>>7
好ましくないとは思いますが
自分でもclass="header"とかやってるんで、
人のこと言えません。

9 : :01/12/16 00:52 ID:PFVhhhSG
>7
「2 段組というデザイン」のために存在するのならそういう名前でいいと思う.

10 :Name_Not_Found:01/12/16 02:21 ID:ki5lqvAh
>8
それとはちょっと違うんでない?
headerならタイトルとかコンテンツだなって感じだけど
col-leftって思いっきり左寄せって感じじゃん。

見当違いならスマソ。

11 :Name_Not_Found:01/12/16 02:23 ID:L1ai1pQM
>>10
俺もそう思う。
>>9の言い分だと、「赤い色というデザイン」のために
class="red"が通ってしまうし。

12 : 9:01/12/16 02:37 ID:PFVhhhSG
>11
例えばカラーチャートを作って(なぜ画像にしないのかとかいうのはこの際おいといて)
赤い色をデザインとして指定したい時は?

13 :8:01/12/16 03:05 ID:7P+Uv7Q2
>>10
「ヘッダ」ってことは既に視覚固定的なことを意識した名称かと思いまして。
「文書の先頭」と言う意味でヘッダだったら良いのかな。難しいですね。

>>12
例えばどのようにそのソースを記述されますか?

14 :Name_Not_Found:01/12/16 03:33 ID:OJaQ76/v
視覚系UAで見たときにはレイアウトの為のDIV+CSSで整形してある方が見やすいね。
トップページくらいはdivでレイアウトしないと見辛くなる気がする。

(;・∀・) まあ俺のマークアップやCSSが悪いだけなんだろうけど


>>13
head要素みたいな意味合いなら別にいいんじゃない?

15 :10:01/12/16 04:24 ID:ZcrvzhUG
>13
あー、なるほどね。
自分はtitle, contents, mainとマークアプしてるからなんとも言えんが
これも視覚的と言えば視覚的だなぁ・・・

16 :モラ野郎:01/12/16 04:57 ID:OJaQ76/v
( ・∀・)ノ そういえばテーブルで

<table><tr>
<td><img src="gazou.png"></td>
</tr><tr>
<td>画像の説明</td>
</tr></table>

というような使い方は正しいのかな?

17 :Name_Not_Found:01/12/16 05:02 ID:iezoh98R
>>16
「冗長だ」という事を除けば、良いとも悪いとも言えないような。

>>15
それって視覚情報?
立派な意味的マーク付けだと思うが。

18 :Name_Not_Found:01/12/16 05:04 ID:Va0Jf7Oz
>>16
どちらかといえば定義リストと思われ。

19 :モラ野郎:01/12/16 05:19 ID:OJaQ76/v
>>17-18
レスありがとう

やっぱりちょっと変な使い方か・・・・・・って (;・∀・)初心者スレでもよかったかな

20 :モラ野郎:01/12/16 14:49 ID:OJaQ76/v
自分のサイトをNN4で表示なんて殆どしてなかったけど、今興味本意でやって
みた。(;・∀・)なんか恐ろしい表示になってたよ

21 :Name_Not_Found:01/12/16 15:48 ID:Va0Jf7Oz
>>20
@importで弾いとけYO!

22 :Name_Not_Found:01/12/16 21:00 ID:3zov5+nl
>>20
@importを使うと N4.x(初期のもの)が落ちることがある、
という話を聞いたことがあるので、

<link rel="stylesheet" href="hoge.css" type="text/css"
 media="screen,tv,print" />

のように screen 以外に何か書くとか、media="all"として
N4.x を弾くのも一つの手だよ。
screen 用のシートしか書いてない場合にはあまりオススメできないけどね。

23 : :01/12/16 22:30 ID:7ShVopSx
>13
すっかり遅くなりまして.例えば
光の三原色は<span class="red">赤</span>,<span class="green">緑</span>,
<span class="blue">青</span>である.
とか.意味としての class と言えなくもないけど,デザインとしての class とも言える.

ま,でも,自分じゃやらないけどね.他人がやっていたらそういう意味なんだろうと思うだけで.

24 :Name_Not_Found:01/12/17 10:41 ID:2CsMaB8M
>>23
<div class="left">左!</div>
<div class="right">右!</div>

確かにこれなら許せるが。そんな奴見たことねえ。

25 : :01/12/17 13:35 ID:KyVBbERe
>24
あー確かに.意味合いが全然違うな.

えーと,では,雑誌などの 2 段組にはレイアウト以上の目的は
ないと思うけど,それを何らかの理由で HTML で実現しなきゃ
ならないとしたら?やっぱり class="left" とかにならない?
「HTML+CSS でやらない」というのはそのとおりだと思うし,僕も
個人的にはやらないけど,上からどうしてもやれと言われるとか.

あと,class="left" などが気持ち悪い,という話を一般化すると,
strict な立場としては「class 名や id 名にはレイアウト情報や
視覚(あるいは聴覚など)の効果を意味する名前をつけず,
あくまで文書中での論理構造を意味するものを付けるほうが良い」
ということでしょうか?

26 :モラ野郎:01/12/17 14:28 ID:rNMrkoGm
>>21-22
今までNN4でレイアウトが崩れるって言っても読めないほどじゃないだろ
うと思ってたけど、( ・∀・)ノ 全く読めないね。


>>25
>雑誌などの 2 段組にはレイアウト以上の目的は
>ないと思うけど,それを何らかの理由で HTML で実現しなきゃ
>ならないとしたら?

(;・∀・)HTML文書でやる事じゃない気が・・・・・・

27 :Name_Not_Found:01/12/17 15:22 ID:4uW3bTZH
>>25
>えーと,では,雑誌などの 2 段組にはレイアウト以上の目的は
>ないと思うけど,それを何らかの理由で HTML で実現しなきゃ
>ならないとしたら?

HTMLではそんなことでけん。CSS3の勧告を待て。
http://kanzaki.com/book/html/updates.html#css3-multicol

28 : :01/12/17 15:49 ID:KyVBbERe
>26-27
思考実験以上の意味を何も持たないので,もうやめます.
やったこともないことを想定して書くというのにそもそも無理があった.ごめん.

で,結局 >25 の最後についてはこういうまとめでいいの?
(まとめなくてもいい,ということかもしれないが.)

29 :Name_Not_Found:01/12/17 17:27 ID:N4vqGxjd
┏━━━━━━━━━━━━━━┓
┃←少ない           多い→┃
┗━━━━━━━━━━━━━━┛
↑見たいなテーブルの見出しをのを表現するために
<td>
<div class="left">←少ない</div>
<div class="right">多い→</div>
</td>
ってな感じで書きましたが,これってだめですか?

30 :Name_Not_Found:01/12/17 17:45 ID:kVj2HaRO
その場合は「 many 」と「 few 」とかのが良いんじゃないでしょうか。
例えば文字を全て縦書きで出力する UA があれば
左右ではなく上下に分かれるコトになるだろうし。

31 :Name_Not_Found:01/12/17 19:04 ID:dBWww2Zp
>例えば文字を全て縦書きで出力する UA があれば
IE5.5以降なら縱書きスタイルシートもありますしね。
だったらclass="left"/class="right"ではなく
id="column1"/id="column2"とでもしておけばいいのでは。
文書を読み通す順にcol1、col2……と番号を振る。

32 :Name_Not_Found:01/12/17 20:11 ID:Sa5tc6ya
http://www.yoshinoya-dc.com/dc/iso2/iso14001.html

の吉野家ってところ 吉って字の上の方が短いヨシが書けないのかどうか
知らんが画像を使っている。やっぱこうゆうのはよろしゅうないかな?
別にどうでもいいけどちと笑ったんで。

 吉野家ってみな字をまちがえてたんやね。

33 :Name_Not_Found:01/12/17 20:21 ID:ELcckRei
>>32
文字コードを定めたJIS X 0208の、1997年改訂で「同一の文字」だとして包摂(統合)されてしまいました。
高島屋の、所謂「はしご高」も同様。

Unicode(ISO/IEC 10646:2000)にはあるんだっけ?

34 : :01/12/17 20:33 ID:KyVBbERe
>33
「よし」にはなかった
「たかい」は髙

35 : :01/12/17 20:33 ID:KyVBbERe
>34
すまね,展開されちゃった.
「たかい」は&#39641;

36 :29:01/12/17 22:26 ID:OFaGHP+1
>>30-31
やっぱりleft,rightはまずかったんですね。
とても参考になりました。
ありがとうございます。

37 :Name_Not_Found:01/12/18 00:32 ID:yVQQR8l8
ここでも16進数値文字参照を使えるようになったのか。
ちょっと感動。

38 :Name_Not_Found:01/12/18 00:43 ID:JnAsQy2m
& (文字実体参照)
& (10進数による数値文字参照)
& (16進数による数値文字参照)

39 :Name_Not_Found:01/12/18 00:44 ID:wZzYjDH8
おおっ! 素晴らしい!

40 :チョトテスト:01/12/18 01:18 ID:NMf4rhWA
¿ A donde vas ?

41 :名無しさん:01/12/18 03:16 ID:+dzffjJl
&をエスケープしないのはStrict的にはすばらしいことではないだろ
俺は別に信者じゃないからどっちでもいいけど

42 :Name_Not_Found:01/12/18 03:30 ID:wsWq8aUS
>>41
エスケープしてますよ。
ソース見てみ。&amp;(文字実体参照)ってなってるんだよ。

43 :Name_Not_Found:01/12/18 03:48 ID:qsqPAzas
存在しない実体参照まで許可するようになってたら微妙にsage。
でも正しくチェックするのは面倒だよな。
テスト → &ahya;

44 :Name_Not_Found:01/12/18 03:50 ID:qsqPAzas
ソース上では &amp;ahya;にならなければならないのが
やはりエスケープされてないようっすね。


45 :Name_Not_Found:01/12/18 07:55 ID:NBjhkuGX
>>29
HTML内の位置情報を示そうとしている時点で間違い。
素直に「左が少なくて右が多い」と書けばいいじゃないか。
どうしても視覚的に表現したいならそれを画像で置き換えればいい。

と思う。

46 :Name_Not_Found:01/12/18 09:41 ID:7nbzjJ4J
<div class="dangumi"> </div>

47 :Name_Not_Found:01/12/18 11:05 ID:cNt0BFDB
>>44
&ahya;が&amp;ahyaに変換されないのは当然。
「UAは不明な参照を展開しない」ので、CGIサイドでもブラウザサイドでも
&ahya;を&ahya;として出力する。
一々CGIで「この実体は定義されているか」なんてチェックしていられないでしょ。
つーか、DOCTYPE宣言無いのに実体の定義もクソもないけど(w

48 :Name_Not_Found:01/12/18 14:08 ID:VXE+tMRP
鳩丸のとこでもやってたが &ontan; ってどうよ?
&ampontan; な

49 :Name_Not_Found:01/12/18 14:33 ID:FzzkRysr
MozillaもIEもOperaもLynxも&ontan;だな。

50 :Name_Not_Found:01/12/18 15:31 ID:E09j57f5
>>48-49
iCabは正しく挙動する。NN4.xも(w

51 :Name_Not_Found:01/12/19 10:18 ID:0Y9pBZGs
ちょいと相談。リンクページで

<dl>
  <dt><img src="【バナー】" alt="【サイト名】"></dt>
  <dd>【管理者名】</dd>
  <dd>【サイトの説明】</dd>
</dl>

みたいのってアリでしょうか。

52 :Name_Not_Found:01/12/19 11:26 ID:+seJNpDJ
>>51

アリかアリじゃないか、ということではなく、私ならこうする、というだけのことだけれど。

<dl>
 <dt>
  <ul>
   <li><img src="【バナー】" alt="【サイト名】"></li>
   <li>【管理者名】</li>
  </ul>
 </dt>
 <dd>
  <p>【サイトの説明】</p>
 </dd>
</dl>

53 :Name_Not_Found:01/12/19 11:31 ID:C0/6nhuf
>>52

dtの中身はインライン要素だけではなかったっけ?
http://www.ne.jp/asahi/minazuki/bakera/html/reference/list#dt

http://www.w3.org/TR/html401/struct/lists.html
<!ELEMENT DT - O (%inline;)* -- definition term -->
<!ELEMENT DD - O (%flow;)* -- definition description -->

54 :Name_Not_Found:01/12/19 14:00 ID:9t6rXFQ2
>>51
私なら貴方と同じようにする。

55 :Name_Not_Found:01/12/19 14:03 ID:hhUlirzJ
ddって2つ続けて使えたんだ。

56 :Name_Not_Found:01/12/19 14:05 ID:GcCG9H92
>>55
http://www.ne.jp/asahi/minazuki/bakera/html/book/book3
の「DD の連続は駄目だって?(p.71)」辺りを読むと吉。

57 :Name_Not_Found:01/12/19 14:09 ID:hhUlirzJ
>>56
サンクス

58 :52:01/12/19 16:23 ID:VKS6YHsi
>>53
あう。指摘感謝。

59 :Name_Not_Found:01/12/19 16:52 ID:7fnir/7u
☆ Webサイト制作初心者用スレッドver13 ☆
http://pc.2ch.net/test/read.cgi/hp/1007538322/l50

だれかいい「Strict入門サイト」知らないか?
とりあえず「とほほは良くないらしい」というのは定着しつつあるようなんだが、
不思議マークアップなサイトを代替案に挙げられてはかなわん。
知ってるところを書いてきてくれい。

>>52
やるなら

<dl>
 <dt><img src="【バナー】" alt="【サイト名】"></dt>
 <dt>【管理者名】</dt>
 <dd>
  <p>【サイトの説明】</p>
 </dd>
</dl>

こんな感じ。dtも連続して使えるから。前スレあたりで既出だったような。
仕様書の例は

dt-りんご
dt-apple
dd-赤い

だったっけ?

60 :Name_Not_Found:01/12/19 17:41 ID:/g1CweEM
>>59
今手元にある本で調べたけど、確かにDT,DD共に1組だけじゃなくて
入れられるって書いてあった。ずっと1組だけだと思ってたよ
鬱だ。。。

61 :Name_Not_Found:01/12/20 01:26 ID:aYbEWlaW
>60
漏れもだよ。
しかも、liやdt、ddも閉じてなかった・・・。
リニューアルうp前に知ってよかたー。

62 :Name_Not_Found:01/12/20 02:22 ID:waxNDCwA
HTML 4.01 ならli/dt/ddの終了タグは省略可能だけど??

63 :Name_Not_Found:01/12/20 03:04 ID:ehM8DIso
>>59
初心者にはfontとかの物理マークアップの方が分かりやすくていいだろう。
いきなり文書型宣言だの何だの言われたら混乱するだろうし。漏れもとほほから入ったクチだしな。
まあ、「自分のはどうやら本当はあまり薦められない書き方らしい」くらいは知ってて欲しいが。

ところで、赤い事そのものに意味のある文字(色見本とか)を表示させたいなら、いっそfont color="#ff0000"で構わない気がする。
strict的にはアレだがclass="red"よりよほどマシと感じるのは漏れだけか?
どうせカラー対応視覚UA以外には無意味だし、注意書きを加えておけばアクセシビリティ問題もないだろう。

64 :Name_Not_Found:01/12/20 04:36 ID:aYbEWlaW
>62
うん、正しくは省略可じゃなくて*閉じない*ものだと思ってたって事。
でも、閉じてた方が(・∀・)イイ!!と、
とあるサイトで見たので(入れ子とかにする際)

65 :モラ野郎:01/12/20 06:43 ID:eGQaCC2o
>>63
>初心者にはfontとかの物理マークアップの方が分かりやすくていいだろう

(;・∀・)それがとほほ氏の影響じゃ・・・・・・

66 :Name_Not_Found:01/12/20 07:23 ID:hYT0d2sh
はっきり言ってstrictのほうが明快で簡単です。
初心者はHTML4.01strictかXHTML1.1で書きましょう。

CSSが判らなくて大丈夫。
こっちで汎用ユーザシートを用意しますから。

67 :名無さん@お腹いっぱい:01/12/20 08:22 ID:oYXp5iK9
>>66
その汎用ユーザシートを公開してあげれば
みんな幸せになれるんじゃ。

68 :Name_Not_Found:01/12/20 08:22 ID:fNaxuBL5
初心者には神埼さんのところが一番わかりやすいと思う

69 :Name_Not_Found:01/12/20 10:01 ID:whKwmmpj
あとは、ちゃいぱ氏のサイトも
ttp://www.parkcity.ne.jp/~chaichan/
なかなか(・∀・)イイ!!

70 :Name_Not_Found:01/12/20 14:26 ID:/pErEqmM
初心者は「強調したい」と思うんじゃなくて「赤くしたい」と思うのではないか?
だとしたらStrict+CSSは一端概念を抽象化しなきゃいけない分
まわりくどくてわかりにくくて受け入れられないと思う。

71 :>69:01/12/20 15:15 ID:LJIjYq1U
でも、その人創価X会・・・・

72 :Name_Not_Found:01/12/20 17:09 ID:gjG3EnOy
あ、そうなんだ。知らんかったよ。
創価学会は、金さえ貢げば極楽浄土ってやつでしょ? 確か。
ちゃいぱさんも報われないなぁ。

73 :Name_Not_Found:01/12/20 17:51 ID:/Tee6j8e
ちゃいぱは創価じゃなくて
立正佼成会だか親鸞会だか
そっち方面じゃなかったっけ?

あの人の日記見てるとチョト怖い。

74 :Name_Not_Found:01/12/20 22:15 ID:YfjbnPQj
ちゃいぱ掲示板にW3C石川セソセイ降臨。すげぇ。

75 :Name_Not_Found:01/12/20 23:08 ID:RyVHKFMq
>>70
それは HTML の初心者?それとも文章を書くことの初心者?
文章を書くことに慣れているのであれば、強調するために赤くする
という考え方になる

文章を書くことの初心者であれば、まず先にそっちを勉強してこい。

76 :Name_Not_Found:01/12/20 23:50 ID:/pErEqmM
>>75
文章というか、論文形態の文章に馴染んでればそうなるだろうが
文章というのはそれだけではないと思われ

「ここは赤くしたいな」「ここは青くしたいな」って思ったのを
わざわざ「ここはなぜ赤くしなければならないのか?」と考え直さなきゃいけないのは
広く大衆に普及するとは思いがたい。

77 :Name_Not_Found:01/12/21 00:10 ID:c55+mQ+L
>>76
小学校の作文の時間に「ここの文字を赤くしたい」とか考えたことあるか?

作文では原稿用紙の使い方──段落の初めは一文字空白にするとか、名前は下から一文字開けて書くとか、そういう「論理マークアップ」を習うだけだと思う。

書体や文字サイズの設定などは、言ってみれば本の装幀に当たる部分で、ライターの考えるべき範疇ではない。HTMLはライターが使うための言語だ。

78 :Name_Not_Found:01/12/21 00:16 ID:VgAzEdDj
どうでもいいけどハリーポッター読んでみると楽しいかもよ。

79 :Name_Not_Found:01/12/21 00:42 ID:Tv9tLyHl
>>77
>作文では原稿用紙の使い方──段落の初めは一文字空白にするとか、名前は下から一文字開けて書くとか、そういう「論理マークアップ」を習うだけだと思う。
それは物理マークアップの方だと思われ。

タイトルはこういう「スタイルで」書きますよ、形式段落はこういう「スタイルで」書きますよ、というのは習ったけど、「こういう情報単位を段落といいますよ」といった事はサッパリ教えてもらわなかった気がする。

80 :Name_Not_Found:01/12/21 01:01 ID:SE/waZvG
>>79
p {text-indent:1EM;}
address {margin-bottom:1EM}
と置き換えられるんじゃないか?(この場合段落=形式段落だよな)
ちなみに漏れは上記に加え
h1 {margin-top:3EM;}
address {margin-left:1EM;}
だった。どうでもいいか。

で、「ホームページ作りたい!」とか言う奴は文章を書きたいとかそういった明確な目標を持たないでなんとなく作ってみるってのが多いと思うが。作文用紙じゃなくてむしろ「じゆうちょう」に近い気がする。
それに例えば日記ごときに論理構造を考えるのは未経験者には面倒だろう。
77のように「ライターのみの言語」と考えるならそれもアリだが。

81 :77:01/12/21 01:25 ID:c55+mQ+L
>>79
SGMLなら書式をタグと見做すこともできるけど、それは割愛して。
段落の表現は、

  英文なら一行開け
  和文なら行頭一文字開け
  HTMLなら前後を<p></p>で括る

ということになると思う。上の二つは自然言語としてのマーク付けだな。
q要素なんかも解りよい例だと思われ。

  「和文における[引用]」
  "英文における[引用]"
  <q>HTMLにおける[引用]</q>

って感じね。ruby要素なんかもそうかな。

# どうでもいいが、piroタソここ読んだ? 違うか?

82 :Name_Not_Found:01/12/21 01:52 ID:Dp57lFkG
>>77
>HTMLはライターが使うための言語だ。

本来そうあるべきなのかもしれんが
現実は全然そうじゃないだろ。

作文の例えはナンセンス。
>>80に同意。

83 :mimasa:01/12/21 02:30 ID:qvWIVy1M
>>74
呼んだ?

こっちも見てます、一応。

84 :Name_Not_Found:01/12/21 02:43 ID:c55+mQ+L
>>83
まじっすか? 質問があるのですが、
「XHTML 2.0 ではいくつかのブロック要素が p 要素内部に認められるらしい」
って本当なのでしょうか?

85 :mimasa:01/12/21 03:11 ID:qvWIVy1M
>>84
本当です。少なくともリストが入るのは確実。

でも「p のネストは禁止」とか言われて DTD 書かされる身としては
頭が痛いんですが。li や dd の中に p 入っちゃうし。

86 :Name_Not_Found:01/12/21 03:17 ID:c55+mQ+L
>>85
なんでpのネストを禁止しちゃうの?

<p>〜に曰く、
<blockquote>
 <p>段落1</p>
 <p>段落2</p>
</blockquote>
と。</p>

なんてのは不可? やっぱり何かしら聖域があるんですか?

87 :mimasa:01/12/21 04:04 ID:qvWIVy1M
>>86
>なんでpのネストを禁止しちゃうの?

文書構造として「段落」がネストするというのが気持ち悪いからでしょう。
実際のところ TREX でも使わない限り XML で exclusion 相当のことは
できないので、「直接のネストは禁止」あたりに落ち着くとは思いますが。
DocBook や XMLspec にしてもそんな感じですし。

ちなみに blockquote もおそらく入ります。div は今のところ入らない予定。

88 :Name_Not_Found:01/12/21 04:34 ID:c55+mQ+L
>>87
DocBookみたいにpを分裂させてしまうってことは流石にありませんよね(w
(というか、新しい要素型の追加はあるのかしらん?)

いずれにせよ、1/14には草案を出して欲しく思います。今度こそは(藁
待ち侘びておりますので、作業頑張って下さいませ。

# >>74のスレにエラッタじゃないかって質問が出ているようですが如何。
# ttp://www.parkcity.ne.jp/~chaichan/qanda/qa2342.htm?01-12-20-21-48

89 :mimasa:01/12/21 06:09 ID:qvWIVy1M
>>88
> DocBookみたいにpを分裂させてしまうってことは流石にありませんよね(w

それはないでしょう。

> (というか、新しい要素型の追加はあるのかしらん?)

このあたりは入るかも…。
http://www.w3.org/2001/09/21-orf/xhtml-family/slide24-0.html

> いずれにせよ、1/14には草案を出して欲しく思います。今度こそは(藁

9月にニューヨークでミーティング中に WTC に飛行機が突っ込んで
ミーティングどころでなくなってしまったのがボディブローのように
じわじわと効いているような気がする今日この頃…。

# >>74のスレにエラッタじゃないかって質問が出ているようですが如何。

後で時間があれば…。さすがに各地の掲示板なりニューズグループなりを
常時見て回って全ての質問に答える時間的余裕はないので仕様に関する
コメントは www-html-editor@w3.org へ、ということでひとつよしなに。

90 :Name_Not_Found:01/12/21 08:27 ID:c55+mQ+L
>>89
>9月にニューヨークでミーティング中に WTC に飛行機が突っ込んで
>ミーティングどころでなくなってしまった
笑えん(w そうか度重なる延期にはそんな背景があったのか。

しかしsection/hなんて要素型が定義されるのね…。
「HTMLはフラットな言語であり、階層構造を示さない」
(http://kanzaki.com/docs/html/htminfo-ex1.html#constraints)
っていう制限がやっと取っ払われるのか。
ていうか、pの中にブロックが認められる以上当然か。いずれにせよ万歳。

<div class="section">
 <h2>heading</h2>
 <p>paragraph</p>
</div>
にさよならだ。

これからは
<section>
 <h>heading</h>
 <p>paragraph</p>
</section>
の時代だ。(推測)

きっとDTD(一部展開後)はこんな感じ。
<!ENTITY % Block.mix "%List.class; | %Block.class; %Misc.class;" >
<!ELEMENT section ( (%heading.class;)?, (%Block.mix;)*, ( section | %Block.mix; )* ) >

heading.classがどうなるのかが謎だが。hのみ? h1-h6及びh?
それともlegacy-heading.classとか作って、
section/hかsection/h1-h6かの一方を選択する形式にするのか?
激しくわくわくするのは漏れだけですか? そうですか。

91 :Name_Not_Found:01/12/21 23:31 ID:G21RVq9u
>>90

<section>
<h>h1 相当</h>
<div>
<p>...</p>
</div>
<section>
<h>h2 相当</h>
<div>
<p>...</p>
</div>
</section>
</section>

とか

階層が自動的に見出しレベルを決めることになるから
何も考えなくても済みそうで良いな

CSS のカウンタ関係との絡みは、CSS3 で解決になるのか
section > section > h { ... }; なんて振り方になると鬱

92 :90:01/12/22 00:47 ID:rgyuqKsi
>>91
>section > section > h { ... }; なんて振り方になると鬱

別にそんなに打つには感じないけど(w
section:nest(3) > h {..}
みたいな疑似要素ができると便利かもね。
それよりも「特定の子要素を持つ親要素」を特定するセレクタが早く欲しい。
img < p みたいな感じの。

つーか、昨日訊くの忘れたのだが、quote要素の引用符付けをどうするのかが凄く気になる…。
できれば、引用符は生テキストには書かないという現状のq要素の方針を踏襲した上で、
UAにはデフォルトでは引用符を付けさせないようにして欲しい(多分そうなるだろうけど)。
引用符を付けたい場合は常にスタイルシートで指定っていうのが一番だと思う。

93 :Name_Not_Found:01/12/22 01:07 ID:X+4l2D3H
b,i, big, small辺りを取っ払ったりはしないのかな……いい加減要らないと思うんだが。

94 :mimasa:01/12/22 02:12 ID:ZNOeiGPe
>>93
順調に行けばなくなるはず。

95 :Name_Not_Found:01/12/22 02:51 ID:iWRG5khq
新仕様のブラウザ実装は何年後になりますか?

96 :Name_Not_Found:01/12/22 02:54 ID:Z4kLLykh
>>92
>img < p みたいな感じの。

それ禿げしく( ゚д゚)ホスィ…。

97 :Name_Not_Found:01/12/22 03:02 ID:5zVHZZEr
img < a{
background-color: transparent;
border: none;
}
とかできたらちょっと助かる。

98 :Name_Not_Found:01/12/22 03:29 ID:6+uLwzDE
>b,i, big, small辺りを取っ払ったりはしないのかな……いい加減要らないと思うんだが。

漏れは残ってて( ゚д゚)ホスィ…

99 :Strictじゃない人:01/12/22 08:43 ID:7lV+CDB0
>>93
smallは名前からすると論理要素にも見えないこともないと思うのだが…。
http://www.dictionary.com/cgi-bin/dict.pl?term=small
   1. Being below the average in size or magnitude.
   2. Limited in importance or significance; trivial: a small matter.
  (以下略)
強調の逆の意味として使えばいいんじゃん!
と思ってたら。
http://www.w3.org/TR/html401/present/graphics.html#edef-SMALL
   SMALL: Renders text in a "small" font.
そんなぁ……でも俺は使うぜ。人間がStrictじゃないから。(涙

100 :Name_Not_Found:01/12/22 11:03 ID:PFPaiXmm
>>99
それ、チョット前に
けいタンと野嵜が論争してたヨ

101 :モラ野郎:01/12/22 12:39 ID:E29fysoN
( ・∀・)ノ 確かにsmallじゃなくても強調の逆の意味を持つ要素は欲しいかも

102 :Name_Not_Found:01/12/22 12:53 ID:0bdPTy4p
>101
同意。

103 :Name_Not_Found:01/12/22 15:00 ID:qYm24TCz
<yawa>それはちょっと</yawa>みたいな?

104 :Name_Not_Found:01/12/22 15:37 ID:8mKkdJ9S
<h1>Strict-HTML スレッド 2.0 <weak>(W2C Recommendation)</weak></h1>

こんなんだったら、俺も欲しいな。

105 :Name_Not_Found:01/12/22 16:26 ID:qYm24TCz
FAQになりそうな予感。
Mozilla 0.9.7 リリースノートより。
---
厳格なドキュメントタイプ宣言(たとえば HTML 4.01 Strict)を使ったページが
外部スタイルシートに (<link>、@import、他を使って)リンクしていると Mozilla
は "text/css" という MIME タイプで公開され たスタイルシートだけを読み込
みます。text/plain、application/x-pointplus、そのほかの MIME タイプ で公開
されているスタイルシートは 読み込まれません。

106 :親切な人:01/12/22 16:29 ID:QAkwwSeA

ヤフーオークションで、幻の人気商品、発見!!!

今は無き「コピーガードキャンセラー」↓
http://page3.auctions.yahoo.co.jp/jp/auction/c14780984

ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

107 :mimasa:01/12/22 20:50 ID:ZNOeiGPe
>>95
ある意味すでにコアの部分は XML 対応のブラウザで動きます。
section, h, l あたりの実装には特別な処理は要らなくてただごく
基本的な CSS1 のサポートがあれば OK。半年くらい前に書いた
XLink を使ったプロトタイプは Mozilla / Netscape 6 あたりなら
xml:base 対応も含めて普通に動いてます。可能な限り XML の
標準的な機能を用いるのが XHTML 2.0 の基本コンセプトなので。

# 実際に XLink (の syntax) を用いるかどうかはいまだに検討中。

逆に言えばスタイルシートを使わないとまともな表示は期待できない
(サンプルスタイルシートは提供される予定) し、HTML ブラウザは
全く眼中にありません。素人にはお薦め出来ない。

108 :Name_Not_Found:01/12/23 00:29 ID:igdWWdE6
1/14にはDTD・追加になるモジュールも公開して( ゚д゚)ホスィ…。

109 :Name_Not_Found:01/12/23 05:56 ID:tQ1kxNsP
>>107
おお、期待 sage
HTML ブラウザ捨て捨ての方針は大歓迎

というか、話を聞けば聞くほど
W3C day の懇親会で直接話をしていたような気がする
今日この頃

110 :Name_Not_Found:01/12/23 06:10 ID:CfAi/JcU
>逆に言えばスタイルシートを使わないとまともな表示は期待できない
>(サンプルスタイルシートは提供される予定) し、HTML ブラウザは
>全く眼中にありません。素人にはお薦め出来ない。

非常に期待

111 :Name_Not_Found:01/12/23 19:26 ID:jiSPpaPA
>>85
ありみかたんはどーするんだろうね。

112 :Name_Not_Found:01/12/23 19:39 ID:SsOZ8R0F
別に常に最新の仕様を追っかけなくてもいいだろ。
普通のサイト制作なら、HTML4/Strictで十分だ。

113 :Name_Not_Found:01/12/23 19:46 ID:+If7NYds
>>110
引用文の通りだとすれば別にHTMLである必要性を感じないんだが……
XLink、CSS対応のXMLエンジンがターゲットならもっと汎用的な名前にすればいいのに。

114 :Name_Not_Found:01/12/24 03:09 ID:02TS26ph
>>113
だから XHTML
XHTML は元々 legacy な HTML は捨ての方針
XHTML/XHTML Basic/Modularization of XHTML のファミリからしたら、
XHTML 1.0 は異端

115 :名無さん@お腹いっぱい:01/12/24 03:11 ID:LuIsbl3y
>>112
そうだよね。
別にHTML2.0で書いてたって後指さされるいわれはないし。
大事なことでした。

116 :Name_Not_Found:01/12/24 04:31 ID:OJM0Vq8M
>>89

石川セソセイ、そこにアドレス書くのはSPAM呼び寄せてると思うんですが...

117 : ◆R4.ALMK. :01/12/24 05:52 ID:0jOI2eUm
>>111
そゆのが出来るならおっけーってことで、
pの中にul入れた書き方の方が読みやすい文章になりゲなら
使うっすよ。躊躇なっしんぐ。リンキオーヘン♪

118 :Name_Not_Found:01/12/24 07:21 ID:LuIsbl3y
実際、small的なのが必要なときってどうしてます?
<span class="small">hoge</span> とか?

119 :mimasa:01/12/24 08:54 ID:NE81t0X5
>>116
すでに死ぬほど来てるので今さら100や200 SPAM が増えたところでどうって
ことないです。仕様書や W3C の Web サイトのあちこちに書いてある以上
今さら隠しても無駄。www-html-editor の S/N 比に比べれば 2ch なんて
かわいいものです。

120 :名無し:01/12/24 12:26 ID:V7KbOwBN
>>118
どの意味のsmall的?

121 :Name_Not_Found:01/12/24 12:32 ID:LuIsbl3y
moderate 的 small。

122 :Name_Not_Found:01/12/24 14:03 ID:gf+aPYNa
<small>おれのチンコ</small>

123 :Bion:01/12/24 15:41 ID:6tMOnUBt
>>119
初めまして。
XHTML2.0に関して質問があります。
宜しければご教示くださいませ。宜しくなければ、いっそ氏ねと…。

【1】sectionの位置
hはsectionの子供として以外にも書ける様になるでしょうか?

例えば、
<body>
<h>h1相当</h>
<p>ほげ</p>

みたいな書式は可でしょうか?

【2】hは必須か

sectionの子供としてhは必須になりそうでしょうか?

【3】スタイルシートの指定

<?xml-stylesheet …

<link rel="stylesheet" …

どちらがより望ましい事になるのでしょうか? それとも、同等扱いでしょうか?

124 :Bion:01/12/24 15:50 ID:6tMOnUBt
念の為補足ですが、「いっそ氏ねと」の出典は『婦系図』です。(たしか。)

125 :Name_Not_Found:01/12/24 15:58 ID:rGmCYygo
>>123
漏れの予想では(聴きたくない?)

【1】body直下のみは可かもしれない。他は不可。
   body直下のみ可というのは、bodyを特別なsectionと見做す場合。
   (bodyの定義が面倒そうだ)

【2】恐らく必須にはならない。意味段落のような使い方もできないと困る。
   なので漏れは>>90のように予想した。
   でもそのあたりはdivでやれって感じもするな…。

【3】「望ましい」のは元々処理命令の方だと思うが。
   「処理命令を使うことにより、主たる文書構造を
    アプリケーション特有の処理情報で汚染することが避けられる。」
   というのがxml-stylesheet処理命令の存在意義なんだし。

126 :Name_Not_Found:01/12/24 23:04 ID:9mDqdbxE
>>119
石川先生カッコイイ( ・∀・)

127 :Name_Not_Found:01/12/25 15:18 ID:NnLGFvny
<strong>の逆の意味が使いたいときって何を使ってます?
<small>は<big>に対応するものですよね。

128 :Name_Not_Found:01/12/25 15:46 ID:KNmIeAlD
<strong>おれのチンコ</strong>

129 :Name_Not_Found:01/12/25 15:47 ID:s1P+yyur
強調の逆(弱調?)って論理的にあり得ないような…。
音楽じゃないんだから。
マークアップしなければ済む話じゃないのかしらん。
あるいは何も書かないか。

130 :Name_Not_Found:01/12/25 15:56 ID:wVEVnhyl
>>129
強調の逆というか
ちょっと注意書きを書きたいときに
そういう要素が欲しくなるなぁ。

俺はよく ul, ol, dl 要素の中に
caption 要素を入れたくなるんだが、
リスト要素の表題ってどうするのがいいんだろう?

131 : :01/12/25 15:58 ID:FHWHUQ1a
>127
<!-- -->

132 :Name_Not_Found:01/12/25 16:03 ID:lcxf0gQU
>>131
(・∀・)イイ!

133 :Name_Not_Found:01/12/25 16:09 ID:NnLGFvny
>>129
よくよく考えてみれば、なんで弱めたいのか意味を考えて、

<span class="whisper">もしもし?</span>

とかすればいいわけですしね。

>>130
たしかに...
h* 使ってるけどいいんだろうか。

134 :104:01/12/25 22:46 ID:cZOptJ/n
>>129
俺は、>>104でも書いたように、h1要素の中に
サブタイトルみたいなのを入れるのに欲しいな>強調の逆

<h1>スターウォーズ1<weak>ファントム・メナス</weak></h1>

<h1><weak>機動戦士</weak>ガンダム</h1>

こんな感じに使いたい。
で、次のようなCSSと組み合わせるんだ。

h1 weak{font-size:smaller;display:block;}

135 :Name_Not_Found:01/12/25 23:12 ID:lmWSnyiI
>>134
文字通り<subtitle>ファントム・メナス</subtitle>
が欲しい。

136 :Name_Not_Found:01/12/26 00:10 ID:XWUMSHs8
>>135
それはh*で表現できるんでは?

137 :Name_Not_Found:01/12/26 00:29 ID:gAV93SAo
>136
h1の一部としてのサブタイトルと
子項目の見出しのh*とでは、意味が違うでしょう。

138 :Name_Not_Found:01/12/26 01:17 ID:diZpF6re
b要素はヤメてemの方がいいっすかね?
それともstrongかなぁ?

でも、b要素もstrictだし・・・悩む・・・。

139 : :01/12/26 01:21 ID:gtVSxYSF
"h1の一部としての"サブタイトル≠<subtitle>

"h1の一部としての"がついてる時点で限定性があってダメ

140 :Name_Not_Found:01/12/26 01:22 ID:Yp60YZBm
>>130
HTML3.0にはlh要素(リスト見出し)があったが、草案で破棄された。
多分定義リストとしてマークアップするべきなのだと思う。

<ul>
 <lh>2ch</lh>
 <li>WEB管理制作</li>
 <li>ラウンジ</li>
 <li>ほのぼの</li>
</ul>

じゃなく、

<dl>
 <dt>2ch</dt>
 <dd>WEB管理制作</dd>
 <dd>ラウンジ</dd>
 <dd>ほのぼの</dd>
</dl>

ってこと。

141 :Name_Not_Found:01/12/26 01:32 ID:+Ki6cWpW
>>138
em は強調。
strong は「より強い」強調。
b は太字。

142 :138:01/12/26 01:32 ID:gAV93SAo
>>139

<h1>ウェブ・ユーザビリチ<subtitle>〜顧客を逃がさないほげほげ</subtitle></h1>
<h2>目次</h2>
<h2>第1章</h2>

こういう場合についての話をしているものとばかり思ってたのですが。
h*で代用するというのは

<h1>ウェブ・ユーザビリチ</h1>
<h2>〜顧客を逃がさないほげほげ</h2>
<h3>目次</h3>
<h3>第1章</h3>

こういう事だと思うのですが、これは、内容からするとおかしいでしょう。

143 :Name_Not_Found:01/12/26 01:33 ID:diZpF6re
>141
はう!(;´Д`)
そうでした・・・逝ってきます。

144 :138:01/12/26 01:34 ID:gAV93SAo
あ。別に<subtitle>限定でそういう要素が欲しいということではなく、
「強調の逆」の要素の使い方の一例ということです。

145 :138:01/12/26 01:35 ID:gAV93SAo
連続ですみません。

<h1>ウェブ・ユーザビリチ</h1>
<subtitle>〜顧客を逃がさないほげほげ</subtitle>

確かにこういうのもアリだと思います。
でもh*で代用はできないです。

146 :Name_Not_Found:01/12/26 01:40 ID:bG81IYby
>>133
classで意味付けするの?
その理屈だと、
<em>ゴルァ!!</em>
より
<span class="emphasis">ゴルァ!!</span>
ってことに。


ちなみに。
>>130 >>133
captionの存在の方がむしろ必然性を感じられない。
title属性じゃ、ダメなのだろうか・・・?

147 :146:01/12/26 01:48 ID:bG81IYby
ん〜。ちょっとおかしかった。
>>146のは、

<span class="angry">ゴルァ!!</span>
ってことに。

の間違い。


>>142
>>139が言いたかったのは、
「そんなもんh?の中でしか使えねぇじゃねぇか」
ってことでは?

148 :Name_Not_Found:01/12/26 03:14 ID:C8QFfTy8
もうちょっと説得力のある質問をしないと石川セソセイが降りてきてくれません。
みんなで頑張りましょう。

149 :Name_Not_Found:01/12/26 03:26 ID:Yp60YZBm
>>148
回答を期待しちゃ駄目だよ(w

150 :Name_Not_Found:01/12/26 04:48 ID:AIr8w2+r
<h1 title="〜ほげほげ〜">(・∀・∀・)ヌッヘッホー</h1>

h1:after{
content: attr(title);
}
 ↓

(・∀・∀・)ヌッヘッホー 〜ほげほげ〜

151 :Name_Not_Found:01/12/26 05:40 ID:Yp60YZBm
しかしなんだ、上から見てきて思うのは、
タイトルってのは見出しとは違うんじゃないかってことなんだが…。

152 :Name_Not_Found:01/12/26 10:53 ID:bYnUPKsM
<h*>の順番を一個飛ばすとlintに注意されるので、飛ばす場合は

<div class="none"><h*>飛ばされる</h*></div>
(.none{display: none;})

としているんだが、他の人はどうか。
見出しを飛ばせると結構自由なことが出来る(と思うのは漏れだけだろうか)

153 :Name_Not_Found:01/12/26 11:04 ID:k/8PDhlo
>>152
本末転倒甚だしすぎます。lintに注意されるので……
とか言ってるようではstrictを語る資格ないよ。

少なくともその「自由なこと」とは何なのか述べましょう。

154 :Name_Not_Found:01/12/26 11:20 ID:Gp15zg/4
見出しを属性としてマークアップってのは奇異な感じがするんだが。

155 :Name_Not_Found:01/12/26 11:22 ID:RbxAcdGI
>>152
笑える。見出しの意味を学んでこい。

156 :Name_Not_Found:01/12/26 12:12 ID:Yp60YZBm
>>152
激しくワラタ(w

「targetの代替は?」とか言い出す奴は良くいるが、
まさか見出しレベルの注意でごねるとは…。

157 :29:01/12/26 13:02 ID:PTxFAv6A
>>152
そもそも,見出しを飛ばす必要性がわからん。

158 :Name_Not_Found:01/12/26 13:27 ID:NQq8eJCZ
>>146
でも、正直現在存在する要素だけじゃ完全な意味付けは無理じゃない?
みんな <div class="section">...</div> 使ってるみたいに。

なんか、

物理マークアップ: b i
文章構造マークアップ: em strong h1 p
意味マークアップ: var code kbd

ってかんじに分かれて、
かつ、意味マークアップは圧倒的に表現力不足ってかんじ。

159 :Name_Not_Found:01/12/26 19:52 ID:OSZXA4ix
以前、どっかのサイトのソースみたら

<H1>ほげほげ<SUB>さぶほげ</SUB></H1>

って、してたよ。
これってどうよ?

160 :Name_Not_Found:01/12/26 19:53 ID:OSZXA4ix
ちなみに「さぶほげ」と書いたのは
サブタイトルってとこからきてる。
SUBとは関係なし。

ま、例文だからいいけど

161 :Name_Not_Found:01/12/26 20:30 ID:whd+YCdR
強調って言うのはある意味相対的なものだから、
逆に、メインタイトルの方をstrongにしたら?
普通の見出しとサブタイトル、って言う
文章構造から外れる感じがするけど。

162 :104:01/12/26 21:56 ID:NVRpKFyb
>逆に、メインタイトルの方をstrongにしたら?

今現在は、おっしゃる通りの方法を使ってます。

●理想(要望)
 <h1>スターウォーズ1<weak>ファントム・メナス</weak></h1>

●現状
 <h1><strong>スターウォーズ1</strong>ファントム・メナス</h1>

でも、メインタイトルとサブタイトルですよね?
サブタイトルの方が、下位というか、補助的な意味合いではありませんか?

始めにメインタイトルありきで、その補助的な意味でサブタイトルがあるのだと私は思います。

とすれば、最上位の見出し(h1)の一部を強調(strong または em)してメインタイトルとするよりも、
最上位の見出し(h1)の一部を弱めてサブタイトルとした方が理にかなっているのではないでしょうか?
考えすぎかなぁ……。

163 :123:01/12/26 22:12 ID:HOzJjfbt
>>162
突如思いつきましたが、
<h1><ruby><rb>スターウォーズ</rb><rp>〜</rp><rt>ファントム・メナス</rt><rp>〜</rp></ruby></h1>
というのはダメでしょうか?

ルビが必ずしも読み仮名でなければならない訳でも無いので、
まずまず良いのではなかろうか、と。

>>125
ありがとう(・∀・) 参考にナタヨ

164 :Name_Not_Found:01/12/26 22:34 ID:whd+YCdR
>>162
うん。だから自分も気持ち悪いと思うよ。

165 :152:01/12/26 23:04 ID:bYnUPKsM
飛ばす必要性の説明にかけていたようだ。

たとえば下のような構造の文章

タイトル
 (本文)
  サブタイトル
   段落
  サブタイトル
   段落
 関連リンク
  関連リンク1
  関連リンク2

の場合、「(本文)」がh2に相当するが、わざわざ本文と書くのはどうかと思ったので飛ばしている。
つまり、構造上は存在するが実際には書かないとき。

166 :Name_Not_Found:01/12/26 23:13 ID:JOFG6qbC
>>165
うーん?
いまひとつ理解りません。

167 :152:01/12/26 23:15 ID:bYnUPKsM
>>166
「構造上は存在するが実際には書かないとき。」だけ理解してもらえばいいです。

168 :Name_Not_Found:01/12/26 23:33 ID:whd+YCdR
なるほど、「(本文)」が無い状態で見出しレベルを飛ばさずやってしまうと
「サブタイトル」と「関連リンク」が同じレベルになってしまう、
或は「タイトル」と「関連リンク」が同じレベルになるのが困る訳か。
俺も似た様な事で困った経験があるよ。
もしレベルとして問題無いマークアップならその警告を無視してやるか、
(Another HTML-lintでも宗教的な問題に分類されてるでしょ?)
どうしても構造を明示したいならdivで括ってやるか。
そう言う意味ではXHTML2のsectionは早く使いたいな。

169 :152:01/12/27 11:17 ID:8jVLHVSn
>>168
理解してくれてありがとうございます。
これで名誉挽回だ。ふぅ。

170 :Name_Not_Found:01/12/27 11:45 ID:sJljWhhl
        -=-::.
  /       \:\
  .|          ミ:::|
 ミ|_≡=、´ `, ≡=_、 |;/
  ||..◎ .| ̄|. ◎ |─/ヽ
  |ヽ二/  \二/  ∂>  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 /.  ハ - −ハ   |_/ < StrictHTMLなんてキンマンコ!!
 |  ヽ/ヽ/\_ノ  / |   \________
. \、 ヽ二二/ヽ  / /
.   \i ___ /_/

171 :Name_Not_Found:01/12/27 11:51 ID:pznN81eZ
>>165
んーでも、そこまでこだわるなら「(本文)」に相当する見出しを
(display:none;でなく)きちんと書くべきだと思うけど。

172 :Name_Not_Found:01/12/27 12:12 ID:PFsbQLh3
>>171
ていうか、divで囲む理由にはなってないよね。
見せたくないなら、
<h2 class="main">本文</h2>
.main { display: none; }
でいいじゃんか。

173 :152:01/12/27 12:13 ID:8jVLHVSn
>>171
そうですかねえ…。
本文の前に「本文」と書いている前例を一度も見たことがないんで。
俺は小泉孝太郎じゃないので、前例がないと不安です。

174 :152:01/12/27 12:13 ID:8jVLHVSn
>>172
過去ログ読んでね

175 :152:01/12/27 12:15 ID:8jVLHVSn
>>172
失礼しました。
ちゃんと文を読んでいないのは漏れでした。
赤っ恥。

176 :Name_Not_Found:01/12/27 12:16 ID:PFsbQLh3
第一、CSSの話はこのスレには関係ないし。

177 :152:01/12/27 12:17 ID:8jVLHVSn
>>176
CSSじゃなくて、文章の構造を明記すべきかどうかという議論じゃないの…?

178 :Name_Not_Found:01/12/27 12:30 ID:yB6mytXV
>>177
こういう場合は、一般の書物などを見ると、
h1 とほぼ同内容のことが h2 にも書かれてる感じ。

179 :Name_Not_Found:01/12/27 12:43 ID:Gbm9kEqj
>>165
h2に相当するのが「本文」以外にあり得ないのか、
例えば「タイトル」を持ってくることはできないか、
h1として相応しい見出しが他にないかとか、考えられない?

何にしても消すことを前提に書くのはおかしいと思う。

180 :Name_Not_Found:01/12/27 13:22 ID:+ijtRjpM
>>179
その文書を自分の権利で改変できる場合はそれでもいいけど、
与えられた原文をマークアップするような場合だと、結構悩む…。

181 :Name_Not_Found:01/12/28 00:44 ID:iplaRrrL
.main { display: none; }

メインなのに見せないのかよ・・・

182 :Name_Not_Found:01/12/28 06:00 ID:TsYBWGWt
素朴にワラタ。

183 :152:01/12/28 11:22 ID:Y4dxJyl3
>>179
消すことが前提じゃなくて、後から考えたら消すのが自然だからそうしたまで。
あと、消すことはなぜおかしなことでしょう?

184 :Name_Not_Found:01/12/30 20:38 ID:MthO6aDs
>>183
単純な疑問

CSS が適用されていない場合にも、その表示は自然なの?

自然ではないのであれば、それはやはり構造がおかしいのだろうし、
自然なのであれば、それはそもそも消す必要がないと思われ

185 :Name_Not_Found:01/12/30 22:41 ID:aissWtfa
"戻る" リンクって構造的にどこに含めるべきでしょう?

186 :Name_Not_Found:01/12/30 23:06 ID:809ZojnI
単体ならdivかp
ってそういうことじゃないか。
折れは大体、h1の直後だけど。

187 :Name_Not_Found:01/12/30 23:11 ID:ss1AoSKI
>185
ページの上下にあれば(・∀・)イイ!!と思われ

188 :Name_Not_Found:01/12/31 00:46 ID:tNjavH1P
>>185

文書構造上は不要じゃないかね?
WWW UAが勝手にやれば良いこと。実際やってるし。

189 :Name_Not_Found:01/12/31 01:09 ID:/Jc/frTN
文書構造上、すべてを1ページで済ますべきだろうねえ

190 :Name_Not_Found:01/12/31 02:49 ID:4WaCvgpO
>>188
そういうのは、link 要素とかで済ませるべきってことでしょうね。

IE がちゃんと link 要素認識してくれりゃあなあ。
プラグインかなにかで認識できるようにならんかなぁ...

191 :Name_Not_Found:01/12/31 06:00 ID:WGWliNIS
http://ton.2ch.net/test/read.cgi/gline/1000370756/12

192 :146:01/12/31 14:54 ID:1LFFv1Na
>>158
>完全な意味付け
をする必要性、意味は?
そんなことをするならHTMLより、それこそXMLの方が。

>>185
JavaScriptでその文字を生成するなら、何処でもいいと思う。
<a href="JavaScript:〜">戻る</a>とHTML中に書くのは
既に環境依存だと(たぶん)思うし、構造として必要とも思えないので、
どことかいう問題ではないと思う。

193 :153:01/12/31 17:07 ID:fenxuxsA
>>184
構造としては正しいが、表示としてはおかしいことは認めます。
しかし、表示の仕方を決めるのがCSSの役目であって、「消す」ということもCSSの役割の一つでは?

194 :Name_Not_Found:01/12/31 17:53 ID:afQYkilf
>>192
うーん、code とか var って文章構造じゃなくて意味構造だと思うんだけど。
HTML の守備範囲って文章構造までだったら、code なんていらないような。

195 :Name_Not_Found:02/01/02 02:23 ID:5KAQHex1
>>185
そっから関連して。
サイトナビゲーションみたいなものはどこに置くべき?

| top | information | updatelog |

みたいなの。

こういうのも link 要素にまかせて body 以下には置くべきでない?

196 :Name_Not_Found:02/01/02 02:42 ID:BTXhcBWm
「戻る」って表現が良くないよな。

たとえば
<a href="contents.html">内容一覧</a>
みたいなリンクなら、文書としても不自然ではない。

ついでにCSSで↓のようにしておけば
印刷時の利用性も高まる。

@media print{
a:after{
content:"[" attr(href) "]";
}}

197 :Name_Not_Found:02/01/02 16:09 ID:Mh3aE+zN
>>195
文章の内容とは直接関係ないから
h1の前と、本文のあとに入れてる。
#個人的にはリストでマークアプした方がいいと思うけどね。

198 :Name_Not_Found:02/01/02 21:00 ID:6WF8PIUZ
>>196
>「戻る」って表現が良くないよな。
同意。
どっかの本に「戻る」「BACK」「TOP」などは紛らわしいので使うな、と書いてあった。

199 :Name_Not_Found:02/01/02 21:44 ID:GFsjgCfs
>>198
うーむ。そうなると、
サイトのトップはどう表現するべきでしょう...

back は単に戻るべき場所のタイトルでも入れとけばいいだろうけど。

200 :Name_Not_Found:02/01/02 22:50 ID:Mh3aE+zN
>>199
HTMLのリンクタイプを参考にしてみては。

201 :Name_Not_Found:02/01/02 23:57 ID:VRll/0Uc
野崎タンのサイトのようなナビゲーションはどうなの?

202 :Name_Not_Found:02/01/03 00:54 ID:gKIAkCyZ
>>201
ときどき見るんですけど、野崎タンのサイトはどこにあるんでしょう。

203 :Name_Not_Found:02/01/03 00:56 ID:8X8Uu7Ac
>>202
W3Cです。

204 :Name_Not_Found:02/01/03 13:16 ID:uR3RHLB/
>>199
サイトのTOPはHOME。これ最強。
TOPだけだと、ページの一番上と勘違いする人が多々いる。

205 :名無し:02/01/03 13:25 ID:T84/IVcZ
>>204
いわゆるHPですか。

link type から言えば、「スタート」じゃないの?

206 :Name_Not_Found:02/01/03 16:10 ID:LzKuRTcY
ページの一番上は「 PAGE TOP 」で
一番最初のページは「 TOP PAGE 」。

…ダメですか。

207 :初心者スレの531:02/01/03 16:22 ID:Lw0p8mD+
スレ違いかもしれませんが初心者スレで弾かれたのでここで聞きます。
XHTML1.1でFlashを表示させたいのですが
<embed>を使うとHTML-lintではMozilla用のタグでエラーになってしまいます。
しかし、それを削除するとIEでは表示できてもNN6(又はmozilla)では表示できません。

また<object>には等価な内容を記述する、とエラーがでましたが具体的にはなにを記述すれば良いのでしょう?
質問ばかりですいません。

208 :名無し:02/01/03 16:53 ID:gnZ7vkRO
>>207
で、今までに何と何を調べてきましたか?

209 :Name_Not_Found:02/01/03 17:38 ID:ZE16u1J6
>>202
「野嵜」「言葉言葉言葉」で検索しよう。

>>207
Flashが見れない環境への配慮。
Flashの代わりとなる情報を記述する。

210 :Name_Not_Found:02/01/03 21:28 ID:4WBQom+j
>>205
link type の start はプレゼンテーションの始点では
W3C の Spec. では cover.html がこれに相当

link type の top がサイトトップでは

211 :Name_Not_Found:02/01/03 22:02 ID:a9K5x5p7
>>210
Link typesにTopなんて無いんですが……Mozillaの独自拡張では?
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.12

212 :Name_Not_Found:02/01/03 22:37 ID:7JuRJd7e
>>211
Mozilla の対応は既存の文書への配慮かと。
HTML3.2 に top の記述があるようだし。
http://www.w3.org/TR/REC-html32.html#link

213 :211:02/01/03 23:20 ID:tfj3idJU
>>212
ありゃ、HTML 3.2が出典でしたか。スミマセン。

214 :Name_Not_Found:02/01/03 23:37 ID:wqI3Sm7Y
>>210
>link type の top がサイトトップでは
サイトトップという観念に囚われてる時点で既に間違いでは?
「トップ」を決めることにあまり意味は無い気がする。
文章群の最初のページならStartとか、
目次があるページなのならContentとか。
その、トップページの役割によるかと。

ま、意味が通じればいいと思うけどね。

215 :Name_Not_Found:02/01/04 13:30 ID:7qzr0jFH
Top of this pageとTop of this siteが一番誤解がないと思われ

216 :Name_Not_Found:02/01/05 20:11 ID:40O3uGcQ
うーん、link 要素って自分で勝手に作っちゃだめなんですか?

217 :Name_Not_Found:02/01/05 21:54 ID:JxIePMOj
>>216
存在している要素を新しく定義し直したいのか?
多分君が言いたいのはリンクタイプだろうな。仕様書を読め。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/types.html#type-links
リンクタイプを定義する標準的なプロファイルフォーマットは存在しないし、
何らかのプライベートなプロファイルを読む様なブラウザも存在しない。
事実上無法地帯だと思っていいよ。

218 :Name_Not_Found:02/01/05 22:08 ID:lmjS/365
ナビゲーションバーもどきを作るって意味ではなく?

219 :Name_Not_Found:02/01/06 22:33 ID:SQFSRmxn
質問です。
なぜscript要素はインラインなのに、noscriptはブロック要素なんですか?
Transitionalではnoscript直下の子要素はインラインでも包含可みたいですが。

例を出せば――

<p>このリファラーの取れるカウンター(
<script>
<!--
document.write("<img src='〜.cgi' width='50' height='10' alt=''>");
// -->
</script>
<noscript><img src='〜' width='50' height='10' alt=''></noscript>
)は○×さんの作品です。</p>

この場合、<noscript><p><img></p></noscript>にしなければいけないってのは
納得ゆかないんですが。

220 :Name_Not_Found:02/01/06 22:59 ID:+2G6TTGV
>>219
scriptはbody,blockquote, formの直下にも置けるよ。

221 :219:02/01/06 23:01 ID:SQFSRmxn
>>220
いえ、scriptでなくてnoscript(の中身)を問題にしてるんですが。

222 :Name_Not_Found:02/01/06 23:13 ID:1QcbgdXZ
>>220
scriptやnoscriptがちょっと特殊だからDTDで表現しきれていないんじゃないかな。
XHTMLでのinsやdelも妙な形になってるし、俺は未完成だからって事で我慢している。

223 :220:02/01/06 23:15 ID:+2G6TTGV
ああ、なるほど。スマソ
noscriptをインラインにすると、noscriptの中にブロック要素を
置けなくなってしまい、必ず<p><noscript></noscript></p>の
ように書かなきゃならなくなるから。
かな。

224 :Name_Not_Found:02/01/06 23:20 ID:SQFSRmxn
http://tohoho.wakusei.ne.jp/html/noscript.htm によれば――
<NOSCRIPT>
包含可能要素 ブロック要素 / インライン要素
(HTML4.01Strictの場合はブロック要素のみ)

StrictとTransitionalで異なる理由がよくわからない……。

225 :Name_Not_Found:02/01/06 23:30 ID:buEp8IQE
確かにimgのalt属性のような感覚では使えないね。

ところでnoscriptってブロックレベル?
内容モデルがインライン不可だから事実上はそうなるけど。

226 :219:02/01/06 23:35 ID:SQFSRmxn
>>225
>内容モデルがインライン不可
つまり、
<p>〜<noscript><img src="" alt=""></noscript>〜</p>
は不可で
<p>〜<noscript><p><img src="" alt=""></p></noscript>〜</p>
にせよってことですよね?
なんか変ではありませんか。
私がよく理解してないのかもしれませんが……。

227 :Name_Not_Found:02/01/06 23:42 ID:K0ScesTS
>>219
document.writeでpタグごと吐けば?

228 :Name_Not_Found:02/01/06 23:57 ID:buEp8IQE
>>226
代替として使うことを考えると確かに変かなと思う。

実際問題、p要素内にnoscriptは書けないから、
>>227の言うようにp要素ごと出力して、

<noscript>
<p>このリファラーの取れるカウンター(<img src〜>)は○×さんの作品です。</p>
</noscript>

とするのがベターではないかと。

229 :219:02/01/06 23:57 ID:SQFSRmxn
>>227
それは結局、HTML4.01Strictにおいては、script要素(とnoscript要素)をインラインで使ってはならないってことになりますか。
ブロック要素として記述せよ、と。
でもインライン要素だけでなくそれを含むブロックまでdocument.writeで
書き出すべしとなると、場合によってはスクリプト依存度が高過ぎて出力に
時間がかかりますよね。
どうも釈然としないので、TransitionalからStrictへの移行は見送っておきます。

230 :227:02/01/07 00:08 ID:F4Cx8HZa
>BODY直下は、ブロック要素またはSCRIPTが一つ以上
http://east.portland.ne.jp/~sigekazu/html/html401.htm

これって嘘? >>219は仕様書読んだ上の主張?

231 :219:02/01/07 00:15 ID:R8OOs+HQ
>>230
確かにscript要素はbody直下やインラインとしても書けるみたいですが、
その代替とするnoscript要素がブロックとしてしか利用できないので、
結局script要素もブロックとしての使用せざるを得なくなるってのが
>>229で述べたかったことです。
誤解があったらご指摘下さい。

232 :Name_Not_Found:02/01/07 00:19 ID:UyqgvFzB
べつに、scriptとnoscriptをセットで使わないかんということはないんだし。
もっと柔軟に考えましょうや。

233 :Name_Not_Found:02/01/07 00:43 ID:R8OOs+HQ
>>232
でもdocyment.writeを使ってる場合はやはりnoscriptが要るでしょ?
それに、そもそもStrict(厳格)である故に柔軟にはなれないわけです。

234 :意味不明:02/01/07 01:11 ID:yHZU+D5C
これのどこに問題があるわけ?

<body>

<script type="text/javascript">
document.write("<p>〜</p>");
</script>
<noscript><p>〜</p></noscript>

</body>

235 :220:02/01/07 01:14 ID:ZPHWYePB
えーとだな、そもそもHTMLのDTDにとっては、document.writeが吐き出すものは
何でもいいのである。HTMLとJavaScriptは、まったく別物だから。HTMLは
document.writeを定義しているわけではない。

次のような記述は、HTML的には正しいのである。
<span><script>document.write("<p></p>");</script></span>

document.writeが生成するものは、UAに依存するものであり、
HTMLの守備範囲ではない。UAと筆者の解釈にまかされる。

236 :Name_Not_Found:02/01/07 01:24 ID:R8OOs+HQ
>>234
一例として、パラグラフ中の一語句だけをブラウザ判別によって
異なる表示にしたい場合。

<p><dfn>ブラウザ</dfn>とは〜〜〜〜。<dfn><acronym>UA</acronym></dfn>とは〜〜〜〜。
<script><!-- 〜〜〜document.write("あなたがご覧のUAならば〜です。")//--></script>
つまり〜〜〜〜説明続く〜〜〜〜。</p>

JavaScriptによって表示を異ならせたいのは一部分に過ぎないのに、
パラグラフの前後を含めてdocument.writeで吐き出させねばならないってのは
非効率的です。パラグラフが長文ならば猶のこと。

237 :Name_Not_Found:02/01/07 01:33 ID:R37i66ow
>>236
でもそうしないとstrictでは書けないんだからしょうがない。
transitionalで我慢するしかないんじゃ。

関係ないけど「UA」はabbrじゃない?

238 :220:02/01/07 01:35 ID:ZPHWYePB
document.writeってのは、strictなHTMLなんて誰も気にしていなかった
時代に作られたもので、過去の遺物です。
DOMを使えば問題なし。

<p>
ああああ
<span id="hoge">いいいい</span>
うううう
</p>
<script>
o = document.getElementById("hoge");
o.childNodes[0].nodeValue = "ええええ";
</script>

239 :Name_Not_Found:02/01/07 01:39 ID:7K0C7LHL
>>238
DOMはよく知らないんだが、その場合、noscriptがどう記述すればいいんかね?

240 :ネットマフィア ◆4mrpMqxg :02/01/07 01:49 ID:zTUaA+9w
>>234
見つけたぜクソやろーーーーーーーーーーーーーー!!
ここで会ったが百年目!!死っねーーーーーーーーーーー!!!!
ぶっ殺ーーーーーーーーーーーーーーーーす!!!!

241 :Name_Not_Found:02/01/07 02:05 ID:li66Q3Ux
>>238-239
詮ずる所、scriptよりもnoscriptの融通の利かなさが問題なんだから、
DOMにしたっておんなじことではないのかな。
noscriptがdelやinsみたいにブロックにもインラインにもなればよかったのにね。

242 :Name_Not_Found:02/01/07 02:10 ID:yHZU+D5C
>>240
社会でちゃんと暮らせるようにお勉強してくれません?
駄レスしかできないならこちらへ
http://tmp.2ch.net/kitchen/

243 :Name_Not_Found:02/01/07 02:28 ID:/RHZvHaA
結局noscriptの中身が「ブロックもインラインも」じゃなくて
「ブロックだけしか許さん」な理由って何なんだよウワァァン!ヽ(`Д´)ノ

俺も>>236と似たような理由で前から不便に思いつつしぶしぶ
<noscript><div>インラインな中身</div></noscript>
ってしてた。

244 :Name_Not_Found:02/01/07 02:48 ID:jJGMRRh9
>>235(>>220)
仕様も読もう。
>HTML文書は、どのSCRIPT要素の処理前も処理後も、HTML DTDに適合するよう制約される。
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/interact/scripts.html#h-18.2.4

なので、
><span><script>document.write("<p></p>");</script></span>
はやはり不正です。

245 : ◆HTML/.Kg :02/01/07 20:35 ID:fRR2ke3D
>>219
一つ。scriptが吐くコードは本来存在しない。
スクリプトに対応さえしていれば処理後は存在するが、
HTMLの本質的(Strict的)には存在しないはず。
つまり、HTMLの守備範囲ではない。
例え外部ファイルでなく直接HTMLに書いても、
それは普通の文章的扱ではなく、%Scriptになる。
つまり、内容(文章)を含まないのでブロックレベルにはできない。
# 「内容を含んでない〜要素があります」ってlintで怒られたことありませんか?
よって、script自身はインラインレベルとなる。

二つ。noscript要素がインラインレベルを包含できてしまえば
そのnoscript要素を包含するp要素等が「絶対」に必要になる。
なぜかと言うと、noscriptはブロックレベルだが
段落等を示すものではないので必ずどこかに
p要素等(構造的に意味を成す要素)が
出現しなくてはならなくなってしまう。
分かりやすく言うと、noscriptは、構造的には
「スクリプトの替わりですよ」としか言わない。
つまり、「ここは段落ですよ」とは言ってくれないということ。
ところが、pはブロックを包含できない。
それに。>>244を考慮すると、noscript自体についてはブロックレベル
にしないと融通が利かなくなることがあるとも予想できる。
# 逆にp要素などをscript要素で吐き出し「たい」時もあるだろうし。

よって、strict的には必然。

・・・と勝手に予想してみる。

そして>>235 >>244
レンダリング後を考えればそれも必然な気がする。
結果だけ見れば構造的に(内容の)無い要素が
ひとつ存在してしまうことになるのだから。
内容の無い要素なら、その要素そのものをなくせと言う話になる。
# Strict的な思考回になってたら自然と違和感を感じると思う。

レンダリング前の元のHTMLとレンダリング後の、
(普通に)判読可能なHTMLの両方を気にしなければ
真のstrictではないということを暗に・・・(以下略

あと、strictは必ずしも機能性や効率性のために
存在しているのではないと思う。あくまでも自分的にはだが、
非環境依存を維持しつつ、その守備範囲を(今ならXMLの方に)
広げるのにstrictの意義みたいなものを感じますが何か?

246 :Name_Not_Found:02/01/08 00:35 ID:z9MBangt
>>245
失礼ながら、長文の割には一向に説得力が無いと感じます。
>それに。>>244を考慮すると、noscript自体についてはブロックレベル
>にしないと融通が利かなくなることがあるとも予想できる。
逆に、インラインにしないと融通が利かなくなることもあるわけです。
だから、noscriptをDELやINS要素みたいにブロックにもインラインにもなり得るものと
しておけば済む話ではありませんか。
実際、Transitionalではnoscript直下がインラインでも可です。
なぜStrictでは殊更にブロックのみとするのか? その必然性は?
……釈然としないままです。

247 :ネットマフィア ◆4mrpMqxg :02/01/08 02:40 ID:e0ZDeJMy
>>242
常軌を逸してんのはお前だ!!たーーーーーーこ!!
いちいちいちいちあんなうぜえ書き込みしやがってよーーー
なんであんなうざい書き込みすんのかさっぱり意味わかんねえよ!!
おまえみたいな意地悪なヤツはマジこの世から消えた方がいいぜ!!
じゃあな!!もう二度と来んなよ!!

248 :Name_Not_Found:02/01/08 02:40 ID:r/KLBuu8
>>219
XHTML 1.1 では script/noscript 要素の置ける位置の違いは
script 要素が head/pre 要素に含められるというだけで、
後は %Script.class; として同列で扱われている

%Script.class; は %Misc.class; に入っているし、
%Misc.class; は %Inline.mix;、%Block.mix;、%Flow.mix; などに含まれていて、
ほとんどどこにでも置ける

つまり、script/noscript 要素は、共に text/block level で利用可能

現行バージョンの Strict な HTML といったら XHTML 1.1 なのだから、
>>219 は XHTML 1.1 使ったら?

249 :Name_Not_Found:02/01/08 04:56 ID:31lH4Aa5
>>248
あのう。
問題になってるのはnoscriptがどーしてブロック要素しか包含できないのかという点なんですけど。

250 : ◆HTML/.Kg :02/01/08 06:25 ID:aywV7lOp
>>246
「融通」といったのはこういうこと。

例えば、<p><span>hoge</span>foo</p>というような感じの
構造の文章をscript, noscriptで表現しようとする。

noscriptがインラインを包含できてしまうと、
<noscript><span>hoge</span>foo</noscript>
と言うのが成立するが、コレだけは
構造的におかしい。段落がない。

というわけで、どこかにpを入れなければならない。
1.
<noscript><p><span>hoge</span>foo</p></noscript>
2.
<p><noscript><span>hoge</span>foo</noscript></p>
のどちらかを選ぶことになるが、
pはブロックレベルを包含できないので2.は却下。
必然。

じゃあ、noscriptをインラインレベルにすれば
いいじゃないかという意見もあるかもしれないが、
「スクリプト処理後」を考えると
<script type="text/javascript">
document.write("<p>〜</p>");
</script>
というようにscriptの出力にブロックレベルが
存在する場合もあり得るので「融通」と言ったまで。
この場合、
<noscript><p>〜</p></noscript>

勿論、Strict的にスクリプトで(特にブロックレベル)要素を
生成するのがよろしくないのならこの融通は無力だが、
どうなんだろう?

>なぜStrictでは殊更にブロックのみとするのか? その必然性は?
ということで、Transitionalでnoscriptがインラインレベルを
包含可なのはbody直下にも置けるからかと。

251 :Name_Not_Found:02/01/08 06:53 ID:r/KLBuu8
>>249
おっと失礼

だったら >>227 >>234 の意見で何の不満が?

XHTML 1.1 で xhtml-script-1.mod だけを overwrite して
%noscript.content; を ( %Flow.mix; )+ に書き換えてやるのも手

script 要素で気になるくらい重くなる程大量の text level 要素を
一括出力する必要があるとしたら、
ほぼ間違いなく大量の無駄があるか、文書構成に無理がある

多分文書設計をやり直した方がいい

>>238 が挙げているのはスクリプトが動作しなければ既に書かれている
元の文書が noscript の役目を果たしているので
script 要素自体 text level で書く必要もないし、noscript も要らない

私は script 要素自体が出現する必要性も認めないので
実行したいスクリプトは link 要素で読み込んでイベントで処理
>>238 の様な場合は onload で処理させる

もっとも、client side で処理させたくないから
SSI で処理させるだろうけどね

252 :Name_Not_Found:02/01/08 07:48 ID:Gw3NFtnd
例えば <h1> は見出し、 <p> は段落、のように定義されてるけど
ここでちょっとつっこんで
<h1 class="SiteTitle"> はサイトの名前、
<h1 class="ContentTitle"> はコンテンツの名前、
みたいな共通の規格を作っておいて、
この規格に準じたサイトの同盟みたいなのを作って、
さらにこれに対応したユーザースタイルシートとか作って
配布とかしてみたりするといろいろ楽しいんじゃないか、と
徹夜明けのアタマで考えてみたり。
どうだろう。

253 :Name_Not_Found:02/01/08 08:00 ID:J7JFfRRN
>>252
それは、素直に XML でやってみたいね。
DTD 作るの。

ところで、<div class="section">... みたいな、
普通の要素に昇格して欲しい! みたいな良く使うクラス名ってどんなのあります?

254 :Name_Not_Found:02/01/08 08:07 ID:Gw3NFtnd
強調の逆。
今はとりあえず small とか使ってるけど
なんか違うんだよなー、と思う日々。

255 :Name_Not_Found:02/01/08 08:21 ID:dQH+T8ok
日本人的なのかもな<強調の逆

256 :Name_Not_Found:02/01/08 08:43 ID:zaGgV/dl
>>255
<wabi>侘び</wabi>
<sabi>寂び</sabi>

257 :Name_Not_Found:02/01/08 08:48 ID:J7JFfRRN
>>255
日本人的なのを忘れちゃいかんと思うんだけど。
右とか左じゃないですよ。

258 :Name_Not_Found:02/01/08 14:27 ID:ujxbx8zG
>>253
鳩丸でやってるような、「良い例」「悪い例」の区別とか。

<bad-samp><pre>
(間違ったコードの例)
</pre></bad-samp>

みたいな感じね。

というか、「例」を示す要素があってもいいかなと思う。

# かつてのxmp要素の意味ではないよ。念のため。

259 :Name_Not_Found:02/01/08 15:29 ID:78GUqY1u
>>253
>>89 xhtml-family

260 :255:02/01/08 15:59 ID:xoWChAIw
いや、おれが言いたいのは
だから用意されてないんだろうってこと
否定はしないよ
sageだって日本人的かもしれん

261 :Name_Not_Found:02/01/08 20:17 ID:gjtyPxQS
>sageだって日本人的かもしれん
確かに(w 最近訳もなく下げてしまう気がする。

262 :Name_Not_Found:02/01/09 00:24 ID:5MVioI9w
技術系スレに限ってsage進行だよな。
雑談agaりまくり。

263 :Name_Not_Found:02/01/09 17:40 ID:LG5uHLYN
>>252
確か、div class="なんたら"をヘッドラインとして定義する
プロファイルがあったよ。
昔メタデータの勉強で検索して見つけたんだけど、今みつかんない(泣)

264 :Name_Not_Found:02/01/09 18:01 ID:Fe7mfZE1
しかし、鳩丸とか見てから普通のサイト見てると、
理想と現実の隔たりをぴこーんと感じるよ。

265 :Name_Not_Found:02/01/09 20:54 ID:Fe7mfZE1
ins/del 要素ってどういう基準で使ってます?
更新した部分全部に使ってる?
それと、一旦使ったら最後まで残してます?

普通だと明示的に更新したって部分だけに使うべきか。
typo 直しただけで ins/del するのもあほらしいよね...

<h1>最初のドキュソ</h1>
<p>それは始まった</p>
<ins datetime="2001-11-11T20:11:09+09:00">
<h1>次のドキュソ</h1>
<p>まだまだ続くぞ</p>
</ins>
<ins datetime="2001-12-02T09:00:29+09:00">
<h1>ドキュソ再び</h1>
<del datetime="2002-01-09T10:48:01+09:00"><p>そろそろ疲れた</p></del>
<ins datetime="2002-01-09T10:48:01+09:00"><p>まだまだがんばるなりー</p></ins>
</ins>

厳密にいくなら、最初の body 以下は全部 ins 要素の下に置くのだろうか...

間違った要素名を del するにはどうしたらいいんだろう。

<dvi class="note">ほげー</div>

<del><dvi class="note">ほげー</div></del>
<ins><div class="note">ほげー</div></ins>

変だ....

266 :Name_Not_Found:02/01/09 21:28 ID:EzFLNg3y
訳注とか脚注とか、注釈のための要素が欲しい…

267 :Name_Not_Found:02/01/10 03:40 ID:aR4zcYBe
>>265
うまく言えないんだけど、「更新」と「訂正」は違うんじゃないかな、とか。

自分はだから

<del>WinXP 導入のメリットなんざゼロだゼロ。</del>
<ins>なんか起動とかは速くなるみたいですね。よって訂正。</ins>

とかこーゆーカンジの使い方してる。

ところで del や ins ってブロックでもインラインでも可だから

<del>
<p>この段落は無かったことに。</p>
</del>

みたいなのも可ですよね。
ところがこれだと Opera のユーザーモードで打ち消し線が引かれないんですが、
(制作者モードだととくに CSS 設定しなくても引かれる。
 あと

 <p><del>この部分も無かったことに。</del>それはそれとして…</p>

 でもちゃんと引かれる)
これは Opera のバグで良いのでしょーか。
Opera スレに書き込むべきかな。

268 :Name_Not_Found:02/01/10 04:34 ID:nG1JXUvh
>>267
訂正の為に使っているってことですね。
成程。
更新情報を残すっていうより、訂正情報を残すって考えれば
なんとなく使いかたが掴めてきたかも。
cite 属性なんかが生きてきますな。

269 :Name_Not_Found:02/01/10 08:32 ID:PdzWlnQ8
>>267
><del>
><p>この段落は無かったことに。</p>
></del>

ISO-HTMLでは不可。

270 :Name_Not_Found:02/01/10 11:46 ID:NhWci3xx
>これでも、『2ちゃんねる』を誹謗中傷とゴミ情報しかない internet の掃き溜めといいます
か? と問われれば、僕は Yes と答えますねえ。その人が仮に正装で来ていても、その場
所は掃き溜めであることに変わりはないので。

もう一方の雄(何)のお言葉。

自分的には匿名性や速報性は(率は低くとも)有益な情報を収集・提供
するうえで大きな武器だと思うけど、読んでて誹謗中傷とゴミ情報「しか」
目に映らないんではそういう感想も致し方なしか。

271 :Name_Not_Found:02/01/10 12:55 ID:pb5eJM8Q
IEにCSS切り替えとLINK要素によるナビゲーション機能を追加する「ス切リボ」
ttp://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/
なんつーのがあるらしいYO

272 :Name_Not_Found:02/01/10 13:29 ID:0hj6bCUH
>270
9割とかじゃあなく、10割がゴミなんですよ。
そのゴミをいかにリサイクルするか。そういうことです。

273 :Name_Not_Found:02/01/10 14:35 ID:4JzTihfm
>>272
10割か?

274 :Name_Not_Found:02/01/10 15:18 ID:5APDBPpK
>>272はふしあなさん

275 :Name_Not_Found:02/01/10 17:27 ID:278Uzq7b
あの<kbd>の使い方って

<p>tar.gzファイルの展開は以下のコマンドを入力してください。(linux)</p>
<kbd>tar xzvf package-name.tar.gz</kbd>

って感じで良いんでしょうか?
それとも全くの勘違い?

276 :Name_Not_Found:02/01/10 17:47 ID:ZlssaCAR
>>275
思想はそれでいいけど、KBD要素はインラインだよ。

<p>tar.gzファイルの展開は以下のコマンドを入力してください。(linux)</p>
<p><kbd>tar xzvf package-name.tar.gz</kbd></p>

277 :Name_Not_Found:02/01/10 17:50 ID:278Uzq7b
あ、インライン…そうですね。
ありがとーです。

278 :Name_Not_Found:02/01/10 19:27 ID:Oh26nQ4m
StrictなHTML吐き出してくれる掲示板CGIを探しています。
自分で改変してやろうとしてるのですが、クソめんどうなので。

・・・スレ違い(いや、むしろ板違い)?

279 :Name_Not_Found:02/01/10 19:37 ID:aq+8D1re
http://fantasien.cup.com/perl5/
有名Strict掲示板。

あとはスキン対応の掲示板でも使えば?
ttp://www.2apes.com/
ttp://www.imaginet.ne.jp/~nobu/
ttp://www.azworks.org/~az/

280 :Name_Not_Found:02/01/10 19:47 ID:pb5eJM8Q
>>278
ttp://www.2apes.com/products/
にあるapeboardはHTMLテンプレートを元に出力するから
元となるHTMLをStrictで書けばいけると思う。

ちなみに俺自身も同じような仕組みで
StrictなHTMLを吐く掲示板スクリプトを作ってるのだが
完成度がイマイチなので公開してなかったりする。

281 :Name_Not_Found:02/01/10 19:49 ID:Oh26nQ4m
>>279
ありがとうございます。
前スレでpicoBBSというのも見つけました。以前に話題に出ていたのですね。失礼しました。

ところで、ElvenBBSにしろpicoBBSにしろ、なぜ投稿フォームはTABLEで組んであるのでしょう?
自分で改造しようとしたときは、

<dl>
 <dt>名前:</dt>
  <dd>ほげほげ</dd>
 <dt>メール:</dt>
  <dd>hoge@hoge.hoge</dd>
 <dt>タイトル</dt>
  <dd>こんにちは</dd>
 <dt>コメント:</dt>
  <dd>ごきげんいかが</dd>
</dl>

って感じで考えていたのですが。

282 :Name_Not_Found:02/01/10 19:52 ID:Oh26nQ4m
あ、>>280さんもありがとうございます。
確かにSkinを使う形式なら柔軟にできますね。
ただ、apeboardは1年位前に使ってはみたのですが、なんか重かったので
やめてしまいました。

いろいろ試行錯誤してみます。

283 :Name_Not_Found:02/01/10 20:06 ID:/QT0uD87
>>279
Elvenは形式的にはStrictだけど、思想的にはStrictっぽくないような……。
#<br>連打の箇所があったり、tableにsummaryが無かったりとか。

とか言いつつ、ElvenBBSをXHTML 1.1に改造している私がいる(爆)。
要素型名も属性名も大文字だから直すのが大変……何で小文字にしてくれなかったの(泣)。

284 :改行コード:02/01/10 22:28 ID:C609iUve
a href="mailto:2ch@2ch.ne.jp?subject=test&body=test1test2
ってのがあって、リンクをクリックしたらメールの題名と本文をあらかじめ
入力してある状態にしたいのですが、本文のところのtest1とtest2の間に
改行を入れることができないんです!メーラーが立ち上がって本文が

test1
test2

って言う風にするにはどうしたらいいですか?
いろいろ探したんですけど、無理なんですかねえ?
どなたかご存知ありませんか?

285 :Name_Not_Found:02/01/10 22:49 ID:wLisHDBw
>>284
%0A とかじゃなかったっけ?

286 :Name_Not_Found:02/01/11 00:08 ID:pn5IJRvp
>>284はマルチポスト。初心者スレで解決済み。

287 :dlの話:02/01/11 03:41 ID:pL5QbgPd
前スレ http://pc.2ch.net/test/read.cgi/hp/992708594/352-359
http://pc.2ch.net/test/read.cgi/hp/992708594/365
も引用してる仕様書の例は、
dt,ddは連続してるけど「複数の用語と記述とを組み合わせる」もので
やっぱりdt,ddは一つずつで組としてるものと思える。

288 :Name_Not_Found:02/01/11 04:14 ID:p6b+8NLN
>>271
linkをもっとみんな書いてくれれば便利なんだろうけどな。
現状で代替スタイルシートはMoz向けの作りの奴が多いし。

Opera使いとしてはOperaがlink辿りとか代替スタイルシートに対応してないのが鬱。

289 :Name_Not_Found:02/01/11 04:51 ID:pTAQTnAe
Moz向けなんじゃなくて、まともにCSSに対応してるのがMozくらいしかないということで。
そこはどうかご承知下さい。

290 :Name_Not_Found:02/01/11 16:04 ID:tjFiUpdq
>>248
近藤って人でしたか。
http://www.alib.jp/diary/diary_200201.html#diary_20020108b
>そういう矛盾は他にもあるけど、XHTML 1.1 使って script モジュールを上書き
>定義して %noscript.content; を %Flow.mix; にしたらいいだけだろうに。

あのね、近藤さんや。
「だけだろうに」って、みんながみんなあなたみたいな技術屋さんではないんですよ。
モジュールだのDTDだの素人がいちいちそんなもんいぢれるわけないでしょや。
なるべくいぢらんでも済む用に基本設定しといてくれんといけんのではないのかな。
だいたいXHTMLって次々バージョン・アップするから、逐一フォローしてられんのですよ。
素人としては、XHTMLがHTML4.01位に安定したら採用を検討してみますわ。

291 :Name_Not_Found:02/01/11 21:23 ID:Uq+0f2so
>>290
ま、でもここで愚痴っても何もならんわな。
仕様策定中に W3C に意見しろや。

292 :Name_Not_Found:02/01/11 22:54 ID:9/Zz6eGA
>>290

おのれの厨ぶりを八つ当たりでごまかすなYO!
近藤氏がいたMLでも似たようなことあったな。。。

>>291
禿同。

293 :Name_Not_Found:02/01/11 22:58 ID:8CaZxG9I
>>291
映画監督が気に入らない批評されたら「ならお前が映画作ってみろ」と開き直る如し。
一般観客の声を蔑ろにしてはいけませんな。

294 :Name_Not_Found:02/01/11 23:23 ID:9/Zz6eGA
>293
見てるだけで満足ならStrict極めようと考えるな。

>287
使いよう。

295 :Name_Not_Found:02/01/11 23:31 ID:Lexrn2RL
>>294
ん? 「見てるだけで満足」だったらそもそも批評は出てこないだろ。
やってみて不満だからこそ文句や愚痴も生じるわけで。
それともまさか、Strict志願の人はみなW3Cの策定に関与せなあかんのけ。

296 :292:02/01/11 23:36 ID:9/Zz6eGA
>295
ここの>1を見習え。
ttp://pc.2ch.net/test/read.cgi/hp/1006224399/
あとさとみかんをチェックすれ。

297 :222:02/01/11 23:44 ID:8+oi53Pa
そもそも>>219は、noscriptがブロックボックスしか持てないのが
何かStrictな思想に基づいてるんではなかろうかと思って
質問したんじゃないのかな?

何故かそれに答えるのが「こうすれば文法違反にはならない」って話ばっかり。
>>243でも>>249でも繰り返して聞いているのにさ。

唯一ちゃんと答えている感じの>>245=250も
言い訳臭い長文になってるから説得力無いし。

俺? 俺はだから、単に仕様書いた人のミスだと思ってるよ。
そもそもブロックレベルにもインラインレベルにもなるんだから
どちらかで内容も変わるのに、それを説明する様な記法が
DTDには無いからこんな矛盾も出て来るんじゃない?

298 :Name_Not_Found:02/01/12 01:16 ID:oYAPeTDm
>繰り返して聞いているのに
219が鈍いだけなんじゃ・・・
ここで正確な答えが得られるとも考えにくいし

299 :Name_Not_Found:02/01/12 01:29 ID:NNLBiW8T
>>298
こんばんは、>>219です。
>>243>>249は同意見ですが私の書き込みではありません。
ええ、一人が繰り返して尋ねたのではないんです。
(でも、私だけが疑問に思ってたんではないとわかってよかった。)

300 :Name_Not_Found:02/01/12 01:51 ID:l4AMhVzf
>>290
弄れる訳無いって、見てから言ってますか?
モジュールとか言うと面倒に聞こえますが、全部テキストファイルなので
適当にちょちょいと書き換えるだけです。

DTD なんてぼっと見てるだけで何となくわかる程度のものです。

そもそもなぜ内包可能な要素が block level なのかを
*本気で* 知りたいのなら www-html@w3.org などで聞いたらどうですか。

# noscript にどうしても頼る必要自体が理解不能だったりしますが。

XHTML って次々とバージョンアップしてますか?
PC 向け仕様は事実上 XHTML 1.1 が 1st release だと思います。

万人の要求を満たす拡張不要な仕様なんて誰にも作れません。
だから基本的に誰もが使いそうなものを用意し、拡張可能な形にして
必要に応じてモジュール構成の変更ができるような作りにしたのでしょう。

それが GUI ベースで簡単にできるようなツールが欲しいなら
オーサリングツールメーカに働き掛けたらどうですか。
要望がなければ需要はないものと思われても仕方がありません。

>>295 は、何か言うことが仕様策定に関わる事だと思ったのでしょうか。
HTML 仕様作成部門の人間は www-html@w3.org とかを見ているのだから
これって変じゃねーか? と言う声を上げるだけでも十分意味はあります。
それが >>291 の言う「意見しろ」でしょう。

301 :Name_Not_Found:02/01/12 02:03 ID:UwKh2o3e
>>300
「適当にちょちょいと書き換えるだけです」、か……。
簡単に言ってくれますがね。それには理解してすっかり呑み込んでることが前提でしょ。
デキル人ってデキナイ君の困難を察してあげられないんですよね。
www-html@w3.org ってのもどうせ英語でしょ?
仕様書のこなれない日本語訳をやっとこさ読み砕いてる人間にはムリムリ。
やはりXHTMLはHTMLよりもハードルが高い代物ですよ。

302 :Name_Not_Found:02/01/12 11:18 ID:OQYd4pSB
>>300
適当にちょいちょいと書き換えた例を見せてやって欲しい。
一つ例を得ることでそれを他に応用していける人もいるだろうし。
# 個人的にはそうして書き換えたものを XHTML1.1 と言ってもいいのかどうかを知りたい。

303 :accesskeyの1:02/01/12 19:04 ID:s/zTSKJx
>>296
ありがとう!
嬉しくて涙が出たよ……

304 :Name_Not_Found:02/01/12 19:09 ID:MbiW1tF2
>>293,295
W3C には今でも意見をいえるじゃん。
今の仕様がおかしいと思うなら言えよ。
今後に反映される可能性はあるんだから。

305 :sage:02/01/12 19:27 ID:uMGEtMx6
>>304
なんだかそれって、小泉首相を批判してたら、
「政治に不満があるなら、選挙に行って投票で示せよ。
政局に反映される可能性はあるんだから」とやり返すのと似てる。
でもW3Cが日本語で意見を受けつけるのかね?
ブッシュ大統領に文句を述べたくても英語をよう喋らん人はどうすればいい?

306 :Name_Not_Found:02/01/12 19:36 ID:OQYd4pSB
>>305
Bugzilla-jp 並みのことを誰かがやるしかないんだろうね。

307 :Name_Not_Found:02/01/12 19:41 ID:zhq5TZVI
>>306
慶應大学がやるべきことなのではないかと思ふ。

308 :Name_Not_Found:02/01/12 20:12 ID:MbiW1tF2
>>305
英語をしゃべれるやつに頼めよ。
ここで愚痴っても仕方ねーだろ?

309 :Name_Not_Found:02/01/12 20:20 ID:CTgDsDzP
>>308
ここに英語がしゃべれる有能な友人を持つ人はいません。

310 :Name_Not_Found:02/01/12 20:38 ID:Q5Idc/eL
みんな、喧嘩はやめようよ。
こんなのって不毛だよ。

ところで、おねがいがあります。
HTML講座という、
ちょっととんちきなスレッドがありまして。
http://pc.2ch.net/test/read.cgi/hp/1010398268/

HTMLを初心者にわかりやすく教えようという
方向にむかっているんだけれど、
なかなかそれが出来る人がいないみたい。

自分もStrictなHTMLを啓蒙したくて参加したんだけれど、
それが意外と難しくて、
手に余り気味。

どうしても参加してくれとはいえないけど、
できたら手伝って欲しい。
僕も、機会を見てできるだけのことはやってみたい。

311 :Name_Not_Found:02/01/12 22:45 ID:Z2WUoqPB
>>307

費用対効果の問題ではないかと。
具体的には何をすればいいと思う?

営利団体でもないけどボランティア組織でもないからな。W3C。

はっきしいって仕様策定みたいなもんにまともに参加したいんだったら、
英語できないと本当にどうしようもない。まともに議論に参加できる程度の技術力と語学力をもつ人間に、対ローカル通訳みたいなもんをやらせるのもどうかと思うでしょ。

312 :Name_Not_Found:02/01/13 01:17 ID:h/Pnur/Z
>>311
結局、英語の話せない奴は黙ってろ、ってことになるわけか。
そういう状況を問題視する人間が集結できないと難しいんだろうな。

313 :311:02/01/13 05:49 ID:CtV1aLl5
>312
まあいろんなところで同じ論議になるような気がするけど。

「黙ってろ」とは違うと思うけど。
別に要求出すぐらいなら対した英語力も要らないしさー。

個人個人がなけなしの英語力出すのってコスト低いけど、
それを集中してどうにかしようって言うのはコスト高いじゃん。
国連みたいに全会議に五か国語同時通訳つけようとか、
そんな事はとても無理でしょ。

まあ、もうちょっとローカルサービスがあってもいいとは思うけどさ。俺も。

とりあえず、国内ユーザグループみたいなものを組織してW3Cに参加するとか、
何か相互協力みたいなものを求めていくってのはあり得る方向性だとは思うけど。

314 :Name_Not_Found:02/01/13 09:54 ID:40S3hG+A
CSSコミュニティの中で英語が得意そうなやつに話を振ってみるとか

315 :Name_Not_Found:02/01/13 10:48 ID:zXhj6w13
黙ってろ、と言うか、「これっておかしくない?」と言う確認なのに
「嫌なら自分でDTD書けやヴォケ」とか
「ウルセー。W3Cに直接言え」って返されたのが問題だと思うが。

>>302
XHTMLとは言えるだろうし、名前空間は同じでいいだろうけど、
DTD宣言にXHTML1.1のURNを書いたりしたら駄目だろうな。

>>310
取り敢えず、そのスレの状態じゃどうにも手が付けられないな。
1が成果をどこかにまとめてくれるって言うんなら助言のしようもあるけど。

316 :Name_Not_Found:02/01/13 11:20 ID:aRthtJL3
>>301
はぁ?
最初から何でもできる様な人が居るとでも思っているのですか。

できる人は、それだけのコストを支払ったからできる人になったのであって、
最初は誰だってできない人です。

www-html@w3.org は英語ですよ。それが何か?
archive を見て、以前似たような議論がなかったかとか
探す程度の事もできませんか。

>>301 はデキナイ君ではなくシナイ君ではないの。

意見を言うのには資格も要らないし、法的規制もない。
英語ができないなら翻訳でも頼んだらいい。

時間的なコストに余裕がないのであれば、
費用的なコストをできる人に支払ってできる人の時間を買えばいい。

何のコストも消費せずに愚痴を言っているだけじゃ何も解決はしない。


>>302
以前 NiAOU 氏が自身の日記の中で書いていたかと。
目的は違った気がするけど、どういった事をしたらいいかの
参考にはなるでしょう。

317 :Name_Not_Found:02/01/13 13:47 ID:f0dYTBpD
つか、exciteの翻訳でも使え。
時間はかかるけど、英語かける。また、単語の勉強にもなるかもしれん。
英語が駄目な奴のためにあるのに、そういう奴らは使うことすら知らんのか…呆れるなあ

318 :Name_Not_Found:02/01/13 13:47 ID:umghksbf
>>315
>「これっておかしくない?」と言う確認なのに
>「嫌なら自分でDTD書けやヴォケ」とか
>「ウルセー。W3Cに直接言え」って返されたのが問題だと思うが。

全く同感。なんで>>316みたいにムキになって非難したがるのかな。
少々疑問を呈するのも排斥したがるのではホントに「信者」だよ。
(自分がコストをかけたからってそれを既得権益みたいに振り回すことはないよ)

319 :Name_Not_Found:02/01/13 14:19 ID:f0dYTBpD
つか、StrictならDreamweaverでそれ系のタグ使わずにちゃちゃっと作りながら修正すれば簡単に出来るような気もする。
DW4になってから無駄なタグさらに減ったし、CSSも一瞬で書いてくれる。また、デザインビューとコードビューあるのでタグに注意しながら書くことも出来る。
さらにタグは小文字だからXHTMLへの変換もたやすい。

みんな、DW使えば?

320 :Name_Not_Found:02/01/13 15:30 ID:OJW3SoMq
>>319
がんばれよ

321 :Name_Not_Found:02/01/13 16:04 ID:V+wtUtOy
DTDもベンキョウしたくありません。
エイゴもベンキョウしたくありません。
でも愚痴はコボシタイデース

322 :Name_Not_Found:02/01/13 16:37 ID:OJW3SoMq
だから、自分でDTD書けってそれを標準化してくれるなら書くけどそうじゃないでしょ

まぁ英語くらい使えるようになれよとは俺も思う

323 :Name_Not_Found:02/01/13 17:29 ID:0kaUkMvJ
>>321

DTDも書けるし英語の多少はできるけど
愚痴をコボシタイデース

まあ、2chだし。ここ。

324 :sage:02/01/13 17:52 ID:vTt/SYED
>>323
あはは、わかる気がする。

325 :Name_Not_Found:02/01/13 18:05 ID:gtww998L
>>323
>>324

自作自演ならもっと良かった(w

326 :┌|∵|┘:02/01/13 18:58 ID:Qo0zASn2
Scrictな話題はしないの?

327 :Name_Not_Found:02/01/13 19:01 ID:cKCiK31x
正直Transitional推進派

328 :Name_Not_Found:02/01/13 19:05 ID:CLn+nqlu
Traditional?
理路整然なフォーマットに限って汎用性は思ったより出ない。
C++のクラスが良い例だと思う。

329 :Name_Not_Found:02/01/13 19:05 ID:/NlrzNbp
>>326
ここはStrictについて質問すると、
W3Cに訊け(当然英語で)って怒る恐いお兄さん達が多いから……。

330 :┌|∵|┘:02/01/13 19:06 ID:Qo0zASn2
Transitionalなんて邪道だよぉ
Transitionalで書くタグはCSSで全部補えるよぉ

331 :Name_Not_Found:02/01/13 19:08 ID:/NlrzNbp
>>330
target属性は無理でしょ。

332 :Name_Not_Found:02/01/13 20:59 ID:7wKGrlgU
ちょっと質問
前スレ
http://pc.2ch.net/test/read.cgi/hp/992708594/273-274
でいってるんだけど…「まーくあっぷ」って何て略せばいいかな?
値上げとかなわけ無いし。
つーか HyperTextMarkupRanguage って何て日本語訳してる?

333 :Name_Not_Found:02/01/13 21:11 ID:fo7Ug/w2
>>332
Language??
JISでは「ハイパテキストマーク付け言語」だったかな。まんまじゃん(w

334 :Name_Not_Found:02/01/13 21:33 ID:7wKGrlgU
>>333
うぉ…なんつーミスを…鬱氏

ハイパーテキストマーク付け言語ってまんま過ぎて
意味がよく見えてこないとか言ってみる。

335 :Name_Not_Found:02/01/13 22:31 ID:1674Cvs9
作者名、サイト名、作成日、更新日、アクセス数なんかを
ページの一番下あたりに載せたいんだけど、
address でいいの?
それとも div class="property" ?
p class="property" ?

336 :Name_Not_Found:02/01/13 22:35 ID:DequuYlm
>>335
私は
<dl id="colophon">
<dt>管理人</dt>
<dd>名前</dd>
…略…
</dl>

337 :Name_Not_Found:02/01/13 23:34 ID:gzanQcHf
>>336
ありがd
ていうか colophon って単語初めて知ったよφ

338 :Name_Not_Found:02/01/14 01:43 ID:daRtzNtg
Iswebを使ってるから広告がつくんで、一番上から少し間を空けたいんだけど
<br><br>
って方法で間を空けるのはやっちゃっていいことなんですか?
質問スレじゃないのにスマソ。

339 :Name_Not_Found:02/01/14 01:46 ID:nshQtBjN
Strict的には、br等使わずにスタイルシートで
h1 { margin-top: 5% }
とでもして欲しい所。
#Canvasの一番上にある要素が分からないので、取り敢えずh1。

340 :Name_Not_Found:02/01/14 01:46 ID:S1RrxLaw
>>338
Strictならダメ。
スタイルシートでbody内の一番上に来る要素にmargin-top:2em;を指定しなさい。

341 :Name_Not_Found:02/01/14 02:42 ID:fjE6KuLK
>>338
Iswebの広告自体、strict的に結構微妙だから気にするな(w

342 :Name_Not_Found:02/01/14 10:15 ID:WW3YPOCZ
>>332
「しるし(印)付け」ではどう?

343 :Name_Not_Found:02/01/14 12:14 ID:D6/EJSn5
「装飾」ではどう? 微妙に意味が外れてるか…

344 :名無し募集中。。。:02/01/14 13:26 ID:77tb6jk/
>>343
そういう烈しく誤解のもとになる語は却下。

テキストの訳語を誰も発明できずに今に至ってる時点で
コンピュータ用語の訳語は考えるだけ無駄って感じ。

345 :Name_Not_Found:02/01/14 14:05 ID:OmwJv4Hs
「意味付け」じゃダメなの?

346 :名無し募集中。。。:02/01/14 14:22 ID:VAMwuQtA
「超典刻印言語」とか。

347 :Name_Not_Found:02/01/14 16:42 ID:Ll5vcPjk
「自然言語構成要素明示記号体系」

348 :Name_Not_Found:02/01/14 17:27 ID:Z5uGt9Qp
付標。

349 :Name_Not_Found:02/01/14 18:27 ID:j0CRvck/
マークアップ=値上げ

350 :Name_Not_Found:02/01/14 20:05 ID:W2G4ELKU

テキスト「白文」はどうか

351 :Name_Not_Found:02/01/15 01:42 ID:8n9sey4T
>>302
http://www.pcc.metro-u.ac.jp/~t0040238/xhtml-mod/sample/xhtml11-noscript-flow-samp.html
http://www.pcc.metro-u.ac.jp/~t0040238/ (↑リンク切れてる)

ついでにXHTML2.0 draft期待age

352 :Name_Not_Found:02/01/15 02:21 ID:bHIKaKUW
>XML文書に対するリンクの場合には、
>XPointer(XPathを含む)という機構が利用でき、
>「最初に出現するh2要素から次のh2要素まで」
>といった複雑な範囲を示すことができます。
>quote要素型というのは、この機構を利用して
>別ファイルからの部分的な引用を
>可能にするものではないかと思います。

いいなぁコレ

353 :Name_Not_Found:02/01/15 03:47 ID:XzIJHb9v
>>351
>ついでにXHTML2.0 draft期待age

おそらく今週は出ません。

>>352

残念ながらハズレ。なお似たようなことを実現するものとして
transquotation なんてのもあります。

http://www.sfc.keio.ac.jp/~ted/TPUB/TPUBsum

354 :Name_Not_Found:02/01/15 23:16 ID:BqViac3+
しかしながら、XPointer が IE とか Mozilla で使えるようになるのは
いつの日か...

355 : ◆UyLOLITA :02/01/16 05:59 ID:uygU1y2k
>>353

がーそ

356 :Name_Not_Found:02/01/16 08:16 ID:IL+LzUET
>>353
また延期か……。

357 :Name_Not_Found:02/01/17 02:40 ID:ONgPWpOb
<span class="red">***</span>
ってのは、REDな感じにしたいという、そういう意味なんだと思う。
色じゃなく。REDな感じにこだわりたい。それが大切。

358 :Name_Not_Found:02/01/17 04:25 ID:YY8q5iIb
>>357
「赤」以外の色になり得ないならいいと思うけどね。
<span class="red">〒</span>とか。

でも、単に「赤な感じにしたい」だけの強調だと、
「やっぱこれからは緑の時代だぜ」とか思ったときに
class名を変更しなきゃならないのでお薦めできない。

359 :Name_Not_Found:02/01/17 04:42 ID:hgEEGDqB
>>358
<span class="red">ガ○レッド</span>参上!
みたいな使い方なら別にかまわないんじゃない?
レッドの気持ちが沈んでて色がブルーになってもそれはそれでいいわけだし。

360 :Name_Not_Found:02/01/17 07:40 ID:mbLzcLio
>>358.359
その使い方もちょっと違うと思う。
言いたいことはわかるんだけどね。

361 :日下部圭子 ◆ib749tYo :02/01/17 09:33 ID:i3+JPISE
http://www.void.tako.org/mail/TextFile.html
このページの
[「山田太郎様」とすべきところを、わざわざ「山田太郎 様」]
この部分ですが、w3mで表示すると、下記のように様の前のスペースが
詰まってしまいます。

[「山田太郎様」とすべきところを、わざわざ「山田太郎様」]

これは、HTMLの仕様としては正しい動作なのでしょうか?

----------------------------------
||//
(@_@) Kusakabe Keiko
----------------------------------

362 :Name_Not_Found:02/01/17 14:11 ID:0YkJMcPa
>>358
<span class="red"></span>は例えば文書内で「赤いものを指す言葉」を示すため使うべきであって、「赤い文字で表示したい部分」を示す目的で使うのは駄目でしょ。
前者の用法なら別に赤色で表示させる必然性はないから、お好みとあらば緑色で表示させたって構わないことになる。


363 :Name_Not_Found:02/01/17 16:06 ID:IWtlWstE
>>361
正しくないと思います。

>>362
この問題、いつまで経っても終わらないですね。
後者でも別に赤く表示させる必然性はありません。
class名を言葉として解釈することは無意味。
red でも dre でも r03 でも同じこと。


364 :Name_Not_Found:02/01/17 16:16 ID:OkigqfsM
(XHTMLの)XML宣言で、最後の?>の前に空白を入れている方が
時々いるみたいですけど、どういう意味があるのでしょう?

<?xml version="1.0" encoding="ISO-2022-JP" standalone="no"?>

<?xml version="1.0" encoding="ISO-2022-JP" standalone="no" ?>
のように。

<br/>じゃなくて<br />にしておいた方がmore betterだと言う話なら
聞いたことあるんですけど。

365 :名無し募集中。。。:02/01/17 17:07 ID:xnco+H56
>>364
IEでXMLを開くと、詰めて書いてても、何故か空いて表示されるから、
それにつられてるんだと思う。


366 :363:02/01/17 18:12 ID:YPEfOyt7
>>363
> >>361
> 正しくないと思います。
は取り消します。

http://www.w3.org/TR/html4/struct/text.html#h-9.1
を読んで、ご自身で判断願います。



367 :Name_Not_Found:02/01/17 23:58 ID:mbLzcLio
>>364
<br/>じゃなくて<br />にしておいた方がmore betterだということと
同等の心理が働いているのだと思われ。


368 :Name_Not_Found:02/01/18 00:07 ID:ZLHv0cEu
>>361
(意図的にか結果的にかはともかく)英文を念頭に置いた仕様になっているので
そのあたりは各 UA の解釈に依存するものだと思います。
「山田太郎 様」にするとか、いわゆる全角スペースをいれるとか。


369 :Name_Not_Found:02/01/18 00:18 ID:09s3xbOP
>>364, 367
more better というのは最近流行の駄洒落ですか?

370 :Name_Not_Found:02/01/18 00:24 ID:H6lQNSBr
>>369
もう亡くなった某おばちゃまも使ってましたが?

371 :Name_Not_Found:02/01/18 00:33 ID:QvzfeDsl
>>370
ひきこもりのおばちゃまね。彼女が流行らせたんだろ。モアベター。

372 :Name_Not_Found:02/01/18 02:12 ID:Xuc0B3qS
>>369
2重強調です。

373 :Name_Not_Found:02/01/18 03:13 ID:ZJsWxP6D
>>364
XHTML1.1のDTD中では、マーク宣言閉じや処理命令閉じの前に
空白を入れている場合が多いので、漏れはそれに併せて
<?xml version="1.0" encoding="Shift_JIS" ?>
としています。

文書型宣言も外部パラメタ実体宣言の形式で。

374 :Name_Not_Found:02/01/21 08:17 ID:zSUhHlyJ
Another HTML Lintで久しぶりにチェックしたら、点数が激減してた。
ファイルはそんなに改訂してないのになぜだと思ったら、HTML4.01での
<ruby>タグ使用に対し、以前は減点1だったのが今は減点7になってたからだった。
どうして急に減点を大きくしたのでせう。

まあXHTML1.1にすればいいのかもしれないが、XHTMLが閲覧できないブラウザもあるし、
ルビのためだけにXHTMLを勉強して移行するのも面倒だし……。

375 :Name_Not_Found:02/01/21 11:26 ID:6qnx9Hs/
>>374
漢は黙って移行。単にXHTML文書にするだけなら勉強も要らん。

376 :Name_Not_Found:02/01/21 12:15 ID:ofiJ9dC7
>>374
DTDの仕組みを知れば、HTML4.01でrubyを使ふなんて無茶はしなくなると思ふ。
ルビりたいなら黙ってXHTML1.1に移行しませう。
もしくはHTML4.01続行ならrubyを外すか、どっちか。
N6/mozならspanだけでもルビに整形できるし。

377 :Name_Not_Found:02/01/21 12:48 ID:yfs3P/04
バグ辞典スレ向きかとも思ったんですが、取り敢えずこちらに……。

ruby内(rbやrt)で、HTML4.01で言う%inline;が使いたかったので、
DTDに記されていた例(xhtml11-flat.dtd・1042行目辺り)を使って

<?xml version="1.0" encoding="ISO-2022-JP-2" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | %InlNoRuby.class; %Misc.class; )*" >
]>
<html xmlns="http://www.w3.org/1999/xhtml" version="-//W3C//DTD XHTML 1.1//EN" xml:lang="ja-JP" dir="ltr">
(以下略)

と拡張したんですが、このファイルをMozilla(Mozilla {Build ID: 2002011403} (Windows))に食べさせたら
Mozillaが吹っ飛んでしまいました。

これは、私の記述ミスなのでしょうか? それとも単にMozillaのバグ?
一応、W3CのHTML Validatorでは問題なしと言われたんですが……。
#普通のXHTML 1.1に戻したらちゃんと食べてくれましたので、他に問題がある訳では無いみたいです。

378 :Name_Not_Found:02/01/21 12:49 ID:yfs3P/04
すみません、"encoding="ISO-2022-JP-2"は間違いです、ISO-2022-JPです。

379 :Name_Not_Found:02/01/21 14:08 ID:ofiJ9dC7
>>377
XHTML1.1ではデフォルトでrt/rb内にインライン要素を記述できるよ。
(ruby要素の入れ子を除く)

ruby.modじゃなくもっと上の方で上書き定義されているのでそれを見て下さい。
(ていうか同じ所でハマった経験がある…)

%NoRuby.content;の場合、フラットDTDでは2687行の記述ではなく
1046行の記述が適用されます。

380 :Name_Not_Found:02/01/21 14:18 ID:ofiJ9dC7
ちなみに。
<!DOCTYPE html 外部識別子 [内部サブセット]>
の記述の場合、パーザの解析は「内部サブセット→外部サブセット」の順で行われます。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | %InlNoRuby.class; %Misc.class; )*" >
]>
と記述してしまうと、パラメタ実体参照"%InlNoRuby.class;"や"%Misc.class;"の実体が
未定義であるため、ここでエラーになる訳です。

これを回避するためには
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | &#37;InlNoRuby.class; &#37;Misc.class; )*" >
]>
として、%がパラメタ実体参照の開始と見なされないようにして下さい。
(&を&amp;と書くのと一緒です)

381 :Name_Not_Found:02/01/21 14:26 ID:ofiJ9dC7
微妙に誤読したかも。

>>377
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd

http://www.w3.org/TR/xhtml11/DTD/xhtml11-flat.dtd
も定義は一緒です。(xhtml11-flat.dtdに一部ミスがあるっぽいけど)

xhtml11-flat.dtdはxhtml11.dtdを見易くしただけのものですよ…。

382 :Name_Not_Found:02/01/21 14:34 ID:ofiJ9dC7
更に誤読ハケーソ。連カキコすまそ。鬱。

>>377はちゃんと
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % NoRuby.content "( #PCDATA | &#37;InlNoRuby.class; &#37;Misc.class; )*" >
]>
って書いてたつもりだったのね(数値文字参照は展開されます…)。

それでmozがこけたとすれば、mozが悪いと思います。

383 :377:02/01/21 14:49 ID:yfs3P/04
>>379
あっ、そうか、先にある1044〜1048行の宣言の方が有効なんですよね。ありがとうございます。
#後に同じ宣言がある場合、そちらで上書きされるものだと勘違いしてました……。
#今まで、二日も掛けて何やってたんだ私は。
>>380
すみません、それは大丈夫です。どうやら、数値実体参照をそのまま書き込んだ為、
展開されてしまったみたいです。"&amp;#37;"と書けばいいのかな?
#って、上の実体参照を記すのにも実体参照を使ってるんですが……あぁ頭が混乱しそう。
>>381
御意。%Color.datatype;(でしたか)が無いのは有名なミスでしょうか?
>>382
はい、そうです。どうも、御丁寧にありがとうございます。

……ところで、382氏は、ひょっとしてsatoshii氏ですか?
#違っていたらごめんなさい。
いつも、興味深く拝見させて頂いております。件の拡張も、satoshii氏のサイトで勉強させて頂きました。
これからも頑張って下さい。一読者として、陰ながら応援しております。

384 :Name_Not_Found:02/01/21 23:11 ID:oIY8B++p
http://isedit.infoseek.co.jp/cgi-bin/tnote/bbs1/101161855311188.html

この回答者達、すごい認識だな。


385 :Name_Not_Found:02/01/22 00:57 ID:nWu8V8iS
>>375
>単にXHTML文書にするだけなら勉強も要らん
でも「モジュール」って何のことだか理解できてないのに
<ruby>タグを使ってしまってもいいんでせうか。
正直、XMLってのもよくわからないままXHTMLに移行してメリットはありますか。

386 :Name_Not_Found:02/01/22 01:59 ID:Mpt2Ya75
>>385
XHTMLを書くのにXMLを分かる必要はない。
分かってるとなお良いが。


387 :Name_Not_Found:02/01/22 14:24 ID:pQG/jMrj
>>385
>正直、XMLってのもよくわからないままXHTMLに移行してメリットはありますか。

HTML4.01はSGMLで、XHTML1.1はXMLで、それぞれ定義されているわけですが、
SGMLを理解した上でHTML4.01を使っている人なんてほとんどいないでしょう。
ばけらさんとかすみけんさんとか、そういう人達は例外。

XMLは知らないがSGMLは知っているってのならともかく、
どっちも知らないならXHTML1.1を使っておいた方が無難と思われ。
XMLの基本構文は割と簡単に理解できると思うけど、SGMLは大変しんどい。

HTML4.01やISO-HTMLなんてのはマニアックな人達が使うものであって、
初心者が覚えるべきものじゃない。

# 原理的なことを知らなくとも使えるってのもHTMLの重要な利点ではあるけど。
# あと、385を初心者だって言っているんじゃなく、一般論としての話なので。

388 :茶文字 ◆xELvisFU :02/01/22 14:33 ID:WCeyXYFJ
>>387
一部に反対。
HTML4.01はマークアップの原点に戻って、文書の各パーツにきちんと
意味づけをすれば混乱を防げるという趣旨で古い要素が統廃合されている。
<Hn>は見出しであって大きな文字を表示するタグではない、など、
体系的に理解するにはむしろ初心者向きではないかとさえ思う。

HTML3.2あたりなど、タグ乱立の様相を呈している。
結果、ひとつひとつのタグの用法を機械的に暗記していくことになりはしないだろうか?

もちろん初心者にいきなりStrict以外認めない、などと言うつもりはない。
でも、これから学び始めるなら、むしろStrictで基本的なマークアップができるように
なってからTransitionalや旧バージョンのHTMLでサポートされているタグを
習得していく、というメソッドも有効だと考えている。

389 :387:02/01/22 15:00 ID:pQG/jMrj
>>388
><Hn>は見出しであって大きな文字を表示するタグではない
と言ったStrict的な概念はXHTML1.1に継承されていますし、
別に反対意見ではないような。

「StrictなHTML」という(理念的な)意味では、HTML4.01StrictもXHTML1.1も同様です・。
HTMLとXHTMLとで差があるのは構文だけでしょう。

構文的にはXHTML(XML)よりHTML(SGML)の方が遥かに煩雑ですから、
XHTMLの方が楽ですよ、という話です。

390 :茶文字 ◆xELvisFU :02/01/22 15:15 ID:WCeyXYFJ
>>389
あ、了解。
部分に反応しちゃったね スマソ

391 :Name_Not_Found:02/01/22 20:29 ID:aTi0d6r0
<dl>
<dt>4/7</dt>
<dd>昨日久しぶりに吉野屋行ったんですよ吉野屋・・・</dd>
</dl>
みたいな書き方はokと聞きました。
でも定義文でないならこのような使い方はしたくありません。
しかし日記を書きたい場合はどうすればstrictでしょうか?


392 :Name_Not_Found:02/01/22 20:34 ID:RonyvK67
<hn>4/7</hn>
<p>昨日久しぶりに吉野家行ったんですよ</p>

普通にこうじゃない?

393 :Name_Not_Found:02/01/22 21:56 ID:1olSFsF1
オレは392のやり方だYO!

394 :391:02/01/22 22:14 ID:LcQwn8gL
なるほど。
しかし勧告によしとされる例を
定義文でないからダメだと勝手に思うのはstrict精神に
反してはいませんか?いませんよね?


395 :Name_Not_Found:02/01/22 22:22 ID:IVLY11nZ
>>350

中国語ならこんなかんじ。

文本:テキスト
文本文件:テキストファイル
超文本標記語言:HTML

396 :Name_Not_Found:02/01/22 23:12 ID:ZSv6hlvz
>>394
勧告で駄目とされてる例を良しとして使うのはどうかと思うけど、
良しとされてるものを駄目と思って使わないのは、別に問題ないと思う。


397 :Name_Not_Found:02/01/23 01:10 ID:UW0jutAf
みまさセソセイー。週が変わりましたよー。まだですかー。

398 :Name_Not_Found:02/01/23 08:05 ID:pTsNpW95
http://www.w3.org/2001/09/21-orf/xhtml-family/slide23-0.html

これ読んだら、XHTML2.0からMIMEタイプがapplication/xhtml+xmlになる
らしいけど。

試してみたら、IEはこのMIMEタイプをXHTMLとして表示できないんだよなぁ。

399 :Name_Not_Found:02/01/23 08:17 ID:ATpZZsNi
>>398
XMLアプリケーションに変わったからでしょうね。
SVGもapplication/svg+xmlですし。

> 試してみたら、IEはこのMIMEタイプをXHTMLとして表示できないんだよなぁ。
text/xmlで凌ぐとか(ダメ?)。

400 :Name_Not_Found:02/01/23 08:37 ID:Xc5VINHW
XHTML2.0が仕様上、新しいMIMEタイプでなければ
ならないのなら、そうするしかないな。
text/htmlでも可なら(たとえ非推奨であっても)、それで
凌ぐけど。

401 :Name_Not_Found:02/01/23 09:41 ID:KeIHY6H9
現在HTML4.01Strctでサイトを作成済みです。
XHTMLに移行するのには、タグを小文字にしたり、
空要素も全て「 />」で閉ぢたりしなくてはなりません。中々修正が面倒です。
これを効率的になすのに良いツールはありますか。よろしくご助言下さい。

あと、NN4による閲覧者があるので、ページ内リンクを<a name>でやってます。
同時にid属性も振ってあるものの、XHTMLではnameが廃止されてるんですよね。
JavaScriptか何かでNN4に対してもページ内リンクを有効にする手立てはありませんか。

402 :Name_Not_Found:02/01/23 09:54 ID:7YQZHd/Z
>>401
name が廃止されているのは XHTML1.1 。
XHTML1.0 なら name 属性も使えるよ。
それとも、 XHTML1.1 で書きたいの?

403 :401:02/01/23 10:00 ID:C1wXw5pc
>>402
1.1が最新規格なんでしょ? あ、2.0ってもう出たんですか?
あと、ルビも使用したいので。
それから、XHTMLにすると閲覧に支障が出るブラウザってありますか。
MacIEのver4.51未満が駄目ってのは知ってます。

404 :Name_Not_Found:02/01/23 12:06 ID:Lxr8+0PR
>>401
>これを効率的になすのに良いツールはありますか。
『 >』を『 />』に一括変換するといー。

>NN4に対してもページ内リンクを有効にする手立てはありませんか。
ならば、そのままヨンストでいーのでわ。

405 :404_Not_Found:02/01/23 12:08 ID:Lxr8+0PR
ジレス。
>ならば、そのままヨンストでいーのでわ。

すまソ、ルビか。

406 :Name_Not_Found:02/01/23 12:12 ID:RxeVEyt1
>>404
>『 >』を『 />』に一括変換する
それだと“</p>”も“</p/>”になってしまふ。
>ならば、そのままヨンストで
「ルビも使用したい」って言ってるからHTML4.01Strictでは宜しくない。

407 :名無しさん@XEmacs:02/01/23 12:39 ID:3tAZaD4N
googleで 「perl xhtml 変換」で調べればすぐにみつかるよ。
まあ、perlで変換が一番簡単じゃない?上から三番目のツールなんて便利そうだけど

408 :Name_Not_Found:02/01/23 12:42 ID:wKGWd/wR
MSXML4でもXSLTがtype="text/xsl"じゃないと効かないんだよな。
XSLT自体もXTransformとかに改名してほしい。


409 :404_Not_Found :02/01/23 12:48 ID:Lxr8+0PR
>>406
>それだと“</p>”も“</p/>”になってしまふ。

すまふ。<br>を<br />だ。<hr>を<hr />だ。imgは手打ちだ。headの中も手打ちだ。
首つって36回死んでくるわ。

410 :Name_Not_Found:02/01/23 13:08 ID:8NRPcRBa
正規表現使えや。
とりあえず秀丸でやる場合な。

<(br|hr|img|meta|link)[^>]*\f>:置換対象
\0 />:置換後

411 :Name_Not_Found:02/01/23 13:12 ID:KJDfgElm
>>410
あと、baseもね。

412 :Name_Not_Found:02/01/23 13:19 ID:pYjMO5vK
>>407
そのソフト、非公開。
>>410
秀丸って持ってない人も多いよ(フリーでないから)。
それに、正規表現が何だかわかる人間なら質問すまいよ。
name属性消すのは一つ一つ手作業だしな、どのみち。

413 :Name_Not_Found:02/01/23 13:24 ID:wnPzs5ym
>>411
あれ、base って 1.1 では無くなったんじゃなかったっけ。


414 :411:02/01/23 13:28 ID:KJDfgElm
>>413
あります。

#ISO-HTMLでは削られましたけど。

415 : ◆HTML/.Kg :02/01/23 13:50 ID:CxHOipjj
>>412
でも、正規表現が一番てっとり早いはず・・・。
xyzzyなどなら秀丸以外にも正規表現で置換できるし、
name属性にしても、少しややこしめだろうけど消せないことはない。
この機会に覚えるとか。損はしないと思うよ。

# 「んなめんどくせぇことやってられっか!」と言うなら別。

416 :Name_Not_Found:02/01/23 13:56 ID:wnPzs5ym
XHTML 2.0 絡みの文章って、他にどんなのがあります?

417 :Name_Not_Found:02/01/23 14:13 ID:HGHKgdlh
現時点でXHTMLに移行する価値ってあるの?

418 :Name_Not_Found:02/01/23 14:24 ID:wnPzs5ym
>>417
うーん、結構自己満足的な部分も多いかも。
XML を利用するツールが使えるってメリットもあるけど、
んじゃ XML を利用するツールってなんだ?っていったら
XML バリデータぐらい?ってなっちゃうような。
そりゃ XML 十把一絡にしてたらそうなるわなあ。

DOM とか SAX つかって要素を簡単に弄れるようになるから
遊ぶ分には楽しいかも。
サイトのサマリ作ったりとかリンクだけ抜きだしたりとかね。

別に HTML でも出来るけど....

よく判ってる人教えてくれー。

419 :Name_Not_Found:02/01/23 14:34 ID:QKnC9MB/
>>417
XHTML1.1にすると、大手を振ってルビ(<ruby>)が使用できます。
まあXHTMLを宣言しなくても使ってるとこは多かったけどさ。

420 :Name_Not_Found:02/01/23 15:01 ID:84/Z4mYx
>>398-399
なんだか、W3Cは本当に後方互換性を重視しているのかと問い詰めたくなるな。


421 :Name_Not_Found:02/01/23 15:21 ID:+vCKvcRO
画像ファイルは全部pngにしてるという方どれくらいいらっしゃいますか?
pngファイルだとGIFなどよりサイズがでかくなることが多いんですが、
その辺気にしないようにしてるんでしょうか?それともデータを小さくできる
ソフトか何かがあるんでしょうか?

スレ違いな気もするけど他のところで聞くと「GIF使えやヴォケ!」とか
言われそうなんで...

422 :Name_Not_Found:02/01/23 16:02 ID:8NRPcRBa
>>421
減色ちゃんとしてますか?
8bitのgifとフルカラーのpngだったら、サイズが違って当然なのだが。

423 :Name_Not_Found:02/01/23 16:09 ID:KJDfgElm
>>421
あと、インターレースにするとサイズが大きくなりがちなのでご注意。
PNGのは、GIFのインターレースとは違う方式なので。

424 :Name_Not_Found:02/01/23 16:20 ID:c1ntYgvG
初歩的な質問なんですけど打ち消し線のタグってのは物理的要素なんでしょうか?

425 :421:02/01/23 16:35 ID:RJ6JzfnD
きちんと減色すれば同程度のサイズになるんですね。

なんか、やり方間違ってたみたい...
逝ってきます。。。

426 :Name_Not_Found:02/01/23 16:37 ID:7YQZHd/Z
>>421
png の画像データは gzip とかと同じアルゴリズムを使った
zlib フォーマットで圧縮されてるてるから
画像ソフトによっては圧縮レベルが 1 だったり 9 だったりするよ。
# 大抵 6 だと思うけど、モノによっては設定できるソフトもある。

zlib は元々画像圧縮のために考案されたものではないから
画像の圧縮率を上げるためにフィルタリングという処理をして
これを補っている。5 種類のフィルタを混在させられるもんだから
それこそアプリによってクセがあったり無かったり、結果は様々。

あと 1x1 みたいな極端に小さい画像の場合は
ヘッダ情報の長さが短い分まず GIF の方が小さくなる。

427 :Name_Not_Found:02/01/23 17:15 ID:EklFC1wv
>>424
s,strikeは物理要素です。文字通り「打ち消し線」以外の意味は持ちません。

一方、delもIEやNNではデフォルトスタイルが打ち消し線ですが、
これは「削除済みの項目」という意味の論理要素です。

なお、delは必ず打ち消し線で表示されるとも限りません。
例えばLynxではデフォルトスタイルが

del:before {content:"[DEL:";}
del:after {content:":DEL]";}

みたいになっていたはず。

428 :Name_Not_Found:02/01/23 17:16 ID:G2d7xYrL
>>423
strictには打ち消し線のタグはありません。

429 :Name_Not_Found:02/01/23 18:48 ID:dxSXQ/tg
>>420
ものすごい勢いで同意。
本当にそうする必要があったんだろうか。
最近いいかげん呆れてきたッス。

430 :Name_Not_Found:02/01/23 20:59 ID:EklFC1wv
>>420
んー、でも、現在のWWWってのは、まだまだ初期段階の
不安定で未熟な技術だと思う。

後々面倒なことになるよりは、今のうちにどんどん「やりやすい」仕様に
変更して欲しい。これがもう三年経ったら、ちょっとしたことを変更するのが
物凄く大変になってしまう気がする。

431 :Name_Not_Found:02/01/23 21:04 ID:6CI7aFXK
>>401
http://www.tomato.sakura.ne.jp/~y-arena/atelier/textss/

432 :Name_Not_Found:02/01/23 21:31 ID:ek/ez1en
話、変えちゃって悪いけど
みなさん、W3CのHTMLチェックとかで得たバナーは
ローカル保存して使用してる?

HTML4.01のバナーをローカルに保存して
右の白いトコを透過にしたいんだけどいいのかな?

433 :Name_Not_Found:02/01/23 22:06 ID:EklFC1wv
>>432
使うときはローカルに保存しるけど、改変は宜しくないと思われ。
建前上というか、常識的にはな。

# もしかすると、みんながバラバラにローカルに保存するよりも
# W3Cから直リンしてた方がキャッシュで処理できたりして
# とらふぃくを減少できたりするかとか思ったが
# んなこたぁーないよな。

434 :432:02/01/23 22:40 ID:ek/ez1en
>>433
やっぱりダメですよね。
ありがとうございます。

# 直リンしてるんだけど
# たまに表示が遅いんでローカル保存について聞きました

435 :Name_Not_Found:02/01/23 23:50 ID:84/Z4mYx
>>421-423
421じゃないが、
PNGってGIFより小さくなることが多いけど
GIFより大きくなることも2〜3割の確率である。
1色ベタ塗りみたいな極端に小さくなるタイプの画像はGIFの方が小さくなったような。

ちなみにPNGは保存するソフトによって結構サイズが変わるよ。
ソフトによってフィルタリングの上手下手があるみたい。
俺はOPTPiXでやってる。
こいつだとPhotoshopとかでやるより2〜3割小さくなるかな。


436 :401:02/01/24 09:49 ID:z2PxxNxw
先に質問した者です。ご教示下さったみなさん、有り難うございました。
しかし折角ご助言いただいたのですが、
>JavaScriptか何かでNN4に対してもページ内リンクを有効にする手立てはありませんか。
これに対しては有効な手段が無いみたいですし、今から「正規表現」てのを覚えて
何とかXHTML1.1に変換しても、rubyが使用できるだけでは苦労の割にあまりメリットがありません。
ましてや2.0だとなんだか後方互換性に難があるみたいですし。
当分HTML4.01のままで、移行は見送ることにしました。

437 :Name_Not_Found:02/01/24 11:40 ID:bEBmSwSu
>>438
XHTML 2.0 はまだ草案も出ていない将来的な規格です。念のため。

438 :Name_Not_Found:02/01/24 16:57 ID:VYxKcYws
今XHTML2.0で書くメリットはありますか?

439 :Name_Not_Found:02/01/24 16:58 ID:VYxKcYws
なんつったりして

440 :Name_Not_Found:02/01/24 19:22 ID:yFUZlQzU
>>439
AAくらい貼れYO!

441 :Name_Not_Found:02/01/24 20:07 ID:sqGdiE4C
>>436
Kanzaki氏のとこのperlスクリプトで一発やん。あとは手書で修正。
まあ、わざわざperlをインストールせなあかんが。

442 :名無しさん:02/01/25 03:12 ID:n7jxrESH
>>436
perlスクリプトならここにもあるよ。
http://www.wig.nu/~ohtaki/soft/index.html

>>412
>>407 に書かれていたソフト、シェアウェアになってるみたい。3,000円。
http://www.w-frontier.com/printed/cnvxhtml.html
ちょっと変換してみた(試用ということで、お金は払ってない)んだけど、
なぜか <br> や <hr> が <br /> などになってくれない。バグ?

443 :Name_Not_Found:02/01/25 03:27 ID:clMmpasu
>>432

> If you like, you can download a copy of this image (in PNG or GIF format) to keep in your local web directory, and change the HTML fragment above to reference your local image rather than the one on this server.

なので、手元に置くのは自由だと思うが。
改変はまー、それぐらいならいいんじゃないの?


444 :Name_Not_Found:02/01/25 03:30 ID:clMmpasu
>> 436

tidy (http://tidy.sourceforge.net/)
の -xhtml オプションを使うなんて手もある。


445 :Name_Not_Found:02/01/26 01:01 ID:oR/cTJzb
>>444
Winの話題ですが、Tidy GUIを使うと、複数のファイルを一気に変換できないし、
DOSで使うと、文字コードを指定できないで、エライことになってしまいます。
こんなヘタレな俺に、アドバイスをくだされ。教えて君でスミマセン。

446 :Name_Not_Found:02/01/26 03:36 ID:XoF9itca
ガイシュツだったらすまないが、打ち消し線を使うギャグって結構見られるよな。
例えば、

>>432
著作権的に問題あり。<s>漏れはやってるが</s>

みたいなの。これにdelを使う奴をよく見かけるんだが(特に4.01準拠を謳うサイトに多い)、むしろsのがマシだと思う。
em.bokeみたいな打ち消し線付文字を示すクラスを指定するのがベストか?

447 :Name_Not_Found:02/01/26 08:44 ID:DiTP03hu
>>446
delもsも変だと思う。
かといって強調しているわけでもないから、emも変だと思う。
となればspanに打ち消し線のCSSを設定するのが一番妥当だと思われ。

・著作権的に問題あり。<span class="gag">漏れはやってるが</span>

ちょっと前に話題になった強調の逆(弱める)の要素が実在すれば、
そっちを使いたいところだけど。



448 :茶文字 ◆xELvisFU :02/01/26 10:46 ID:z5nd+ypK
うむ 言われてみれば<del>はおかしいな確かに。

>>446
ギャグにもいろいろな種類があるから、class="gag"では他の箇所で
困ったりせん?
むしろclass="strike"ってのはどうなのか?

日本語が許されるなら、class="ぼそ"あたりを使ってみたい(w
スタイルシート側でうち消し線、音声出力用にちょっと低くて小さな声。

449 :Name_Not_Found:02/01/26 10:53 ID:mV+YhBjE
打ち消し線でも良いけど、文字色を薄くするのも良いかも。
ユーザビリティー的に問題有りかも知れないが。

450 :Name_Not_Found:02/01/26 11:57 ID:z+7qEk20
>>447 強調してると思うけど。強調の「強」に拘りすぎ。

451 :Name_Not_Found:02/01/26 12:42 ID:282479MF
意味的にいったらgagとかjokeとかしなきゃいけないんだろうけど、なんか、無粋だなあ。
それに、CSS2非対応の音声ブラウザでそのまんま読み上げられてしまうと、文意が伝わらないどころか文章が変になることもあるし。
(ていうかdel/insをそのまま読み上げる仕様だったらどっちにしても意味ないか)


452 :Name_Not_Found:02/01/26 12:47 ID:LUmfTYsS
>>451
span class に対して「意味的」とか言うのは、いいかげんやめてほしいな。

453 :茶文字 ◆xELvisFU :02/01/26 12:57 ID:z5nd+ypK
>>451
ソースなんてコンピュータが読みとるものなんだから、無粋なのは当たり前と思われ。
CSSの利点のひとつはソースの視認性が上がることだが、これは管理上の話だし
classの値なんて任意なのだから、あなたがカコイイと思う値にしていいと思う。
ただ、class名からその部分の位置づけがわかるようにするという原則が尊重されてれば。

454 :Name_Not_Found:02/01/26 16:23 ID:Kj95GnhG
CSS 非対応でそれなりに意味が通るようにするんだったら
em.whisper とか strong.whisper かな。

ところで、em と strong の使いわけって結構悩むんだけど。

>>450
「弱めてる」ように見えても、よくよく考えると強調してるってとこは
結構多そうだね。

でもサブタイトルあたりはそれじゃ片づかないような....


455 :451:02/01/26 17:59 ID:yDb5FucI
>>452
どうして?

>>253
それは分かってるんだけどさ。


456 :451:02/01/26 18:00 ID:yDb5FucI
間違えた。
後半は>253じゃなく>>453ね。


457 :茶文字 ◆xELvisFU :02/01/26 18:19 ID:z5nd+ypK
>>455
絡む気はないんだけど、それがわかってたらなぜ>>451
文法上の議論に無粋も何もないような気が。
sageだから何となく感想を書き込んでみただけなのかしら。

# 末節なので特に強く返事を求めてはいませんし、責めるつもりもないです。


458 : ◆BFAcsz86 :02/01/26 19:31 ID:CfcJkyBb
>>454
強調したいなら em で、それよりも更に強調したいときは strong でしょう。


459 :Name_Not_Found:02/01/26 19:42 ID:Kj95GnhG
>>458
いや、そりゃわかるんですけど、
どういう部分で更に強調すべきかってのの判断がいまいち。

<p>
それじゃ恒例の。
「<em>1</em>、<em>2</em>、<em>3</em>、<strong>ダァー!</strong>」
</p>

みたいなのばっかりだと楽でいいんだけどもん。

460 :茶文字 ◆d38VidMY :02/01/26 20:24 ID:z5nd+ypK
>>458-459
<p>
今回のレッスンでは、相手の名前を尋ねるときの丁寧な表現について学びました。
</p>
<div class="example">
 <p>
それでは例文を示してみましょう。
 </p>
 <ul>
  <li><strong>May I ask your name, please?</strong></li>
  <li><em>お名前を伺ってもよろしいですか?</em></li>
 </ul>
</div>

↑とか↓とか。

<p>
私はウェイトレスに<em>アイスティー</em>を注文した。
だが、実際にやってきたのは<strong>アイスコーヒー</strong>だったのだ。
</p>

461 :茶文字 ◆d38VidMY :02/01/26 20:27 ID:z5nd+ypK
>>450と思ったが、英文の例は<dl>の方が適切な気がしてきた。
<ul>を使うとしたら

<ul>
 <li>英文
  <ul>
   <li>邦文</li>
  </ul>
 </li>
</ul>

を最小単位にしないと複数の例が挙げられないな。

462 :Name_Not_Found:02/01/26 20:42 ID:Kj95GnhG
>>460
<p>
私はウェイトレスに<em>アイスティー</em>を注文した。
だが、実際にやってきたのは<strong>アイスコーヒー</strong>だったのだ。
しかも、<stress>虫が入っている</stress>ではないか!
</p>

みたいに、さらに強調の段階が入る場合は?
それだったら、はなから em 一個か strong 一個でいいじゃんって思うんですが。


463 : ◆BFAcsz86 :02/01/26 21:06 ID:CfcJkyBb
>>462
(現状の) HTMLでは力不足ということで諦めるのも1つの手だと思うが。

仮に em あるいは strong 1つだったとして、それを入れ子にするのか?
>>462 はそんなに入れ子にしたいのかと問いたい。
強調レベル属性のようなものを用意する手段もあるだろうが、
>>462 は(以下略)


464 :Name_Not_Found:02/01/26 21:15 ID:Kj95GnhG
>>463
なんか、論点がずれてきたんで...
strong と em の使いわけはどんなふうにするべきかねーって話です。

>>462 の場合、

しかも、<strong>虫が入っている</strong>ではないか!

とすべきか、

だが、実際にやってきたのは<em>アイスコーヒー</em>だっのだ。
しかも、<strong>虫が入っている</strong>ではないか!

とすべきかって話です。


465 : ◆HTML/.Kg :02/01/26 21:17 ID:zEO5HEtW
>>460,>>462
そもそも、その例の二つ目の強調部分には
strongが必要なのだろうか。
個人的にはemでいいように思える。
まぁ、「んなこたぁ漏れの気分次第だろが!ゴルァ!」
といわれればそれまでだけど。

というか、>>462みたいな理屈が通ってしまうと、
いくらでも上限無く必要じゃないかという話になる。
だから、敢えて二段階まで、としているのじゃないだろうか。

# 現状でのHTML的理論構造上の限界がこの辺ってことだろうね。

466 :Name_Not_Found:02/01/26 21:31 ID:Kj95GnhG
>>465
h* が h6 までってのと同じような理由ってことで納得しときます。

そういや、XHTML 2.0 では h* は h に統一されるんでしたっけ?


467 :Name_Not_Found:02/01/26 21:34 ID:KhgyXycq
何となくemとstrongの関係はh1-h6の関係に似てるなーと思う。
XHTML2.0でsection-hという要素型が導入されるとすれば、
emとstrongも二種用意する必要なかったんじゃないかと思うのだが。
(実際あると楽ちんなんだけどさ)

あと、dfnとかaとかciteとかっていうのは、みんな「特殊な」強調だと思うわけで。
em.dfnを要素にしたものがdfnというか。
qのように単に文の状態を表すものは、span.qを要素にしたものみたいな。

# ひとりごとみたいな内容になってしまったけど(゚ε゚)キニシナイ!!

468 :Name_Not_Found:02/01/26 21:43 ID:Kj95GnhG
>>467
もし、強調を意味する要素が一つになったとして...

<em><em><em>重要!!</em></em></em>

ヤダァ....

dfn とか var とかって、他の html の要素とレイヤーがずれてる気がするよ。
中途半端な意味付けってかんじ。

469 :Name_Not_Found:02/01/27 01:13 ID:iFeG0JID
>>462
漏れは
<em>問いたい</em>
<strong>問い詰めたい</strong>
<em><strong>小一時間問い詰めたい</strong></em>
としてる。以前どこかで見かけたのの真似。

必要ならクラスを定義するくらいしか思いつかないが、
とりあえずこれ以上強調が欲しいと思ったことは無い。

470 :Name_Not_Found:02/01/27 01:19 ID:ljf5fLkV
なんかバカくせーやり方。そこまで行くとビョーキだね。

471 :Name_Not_Found:02/01/27 01:45 ID:BDzStLrg
>>470 至極単純明快だと思うぞ。それでこそ、strictって感じ。

472 :Name_Not_Found:02/01/27 01:50 ID:5VX/wZV7
>>469
んー、469氏の伝でいくと、em、strongの次は<em><strong>...なの?
俺は<em><em>...だと思っていたけど。

<em><strong>と<strong><em>は同レベルの強調? それとも分けてる?


#単なる質問なんで、気を悪くしたらスマン。

473 :Name_Not_Found:02/01/27 01:50 ID:HQfyyNhH
>>470のやり方
<font size="4">問いたい</font>
<font size="5">問い詰めたい</font>
<font size="6">小一時間問い詰めたい</font>

マジっぽくてアレだが。スレ汚しスマソ

474 :Name_Not_Found:02/01/27 02:34 ID:ljf5fLkV
いや、そんなとこまで逐一細かくタグつけなくてもって思ったの。
「もっと他にタグつけれる所はないかあぁぁ?」って光景が浮かんだ。
言葉が汚くなったのはごめん。

475 :Name_Not_Found:02/01/27 03:39 ID:qUCe4dJ4
質問。

<dl>
<dt>コーヒー牛乳<dt>
<dd>ミルクとコーヒーでできてる。</dd>
.
.
.
</dl>

とするのと

<dl>
<dt>コーヒー牛乳<dt>
<dd><p>ミルクとコーヒーでできてる。</p></dd>
.
.
.
</dl>

とするのとどっちがいいの?
要するに<dd>に直接コメント書いてもいいの?ってことです。

476 :451:02/01/27 03:49 ID:sdRbAEUc
>>457
>sageだから何となく感想を書き込んでみただけなのかしら。
そういうことです。


477 :Name_Not_Found:02/01/27 04:12 ID:1b2tTwJm
>>475
OKです。
前スレかどこかで既出だったと思うんだけど、見付からなかったので手短に言うと、
要するにddはliやtdと同様に考えて下さい。

直接<dl><dt>りんご</dt><dd>赤い</dd></dl>として構いません。

もっとも説明が「段落」を形成するならpとしてマークアップするべきだと思いますし、

<dt>なんとか</dt>
<dd>
 <p>これはこういうもので…</p>
 <p>かつこういうものでもある…</p>
</dd>

のような説明と並べるなら、

<dl>
 <dt>項目1</dt>
 <dd>
  <p>ほげほげ</p>
  <p>ふげふげ</p>
 </dd>
 <dt>項目2</dt>
 <dd>
  <p>ほげほげ</p>
 </dd>
</dl>

のように、統一感を持たせた方が良いと思いますが。

478 :Name_Not_Found:02/01/27 04:12 ID:Ro6bs2WL
>>475
<dl>
<dt>コーヒー牛乳<dt>
<dd>ミルクとコーヒーでできてる。</dd>
.
.
.
</dl>
とありますが、まず2行目のところから間違ってますよ。

479 :Name_Not_Found:02/01/27 04:33 ID:R73bzZLe
>>478
あげあしとるのは勘弁してあげようよ。

480 :475:02/01/27 04:41 ID:qUCe4dJ4
>>477
ありがとうございます。
わかりやすい説明で勉強になりました。
>>478
どうも。いや全くそのとおりです。

481 :Name_Not_Found:02/01/27 05:28 ID:wS5MZr2p
オレは
<dl>
 <dt>項目1</dt>
 <dd>
  <p>ほげほげ</p>
  <p>ふげふげ</p>
 </dd>
</dl>
ってのは
<dl>
 <dt>項目1</dt>
 <dd>ほげほげ</dd>
 <dd>ふげふげ</dd>
</dl>
としてる。

482 :Name_Not_Found:02/01/27 05:35 ID:1b2tTwJm
>>481

[がいしゅつ]
 意味:「既出」の意味。
 語源:とあるスレで「がいしゅつかもしれませんが…」と書いた>>1がいたことに起因。

↑これはdl>dt+dd+ddが良いと思う。

[がいしゅつ]
 「既出」の意味。とあるスレで「がいしゅつかもしれませんが…」と書いた>>1がいたことに起因。
 発祥元のスレはどこだったか忘れたが、「どこそこの女子大生が絞殺云々」というスレだったような。

↑これはdl>dt+dd>p+pの方がしっくりくるような。まあ好きずきだろうけどね。

483 :Name_Not_Found:02/01/27 09:01 ID:J4w9zsil
ちょっと質問なんだけど、1つの段落を丸ごと強調したい時って、
みんなどうしてる?

●段落内まるごと強調タグ
<p><strong>「既出」の意味。とあるスレで「がいしゅつかもしれませんが…」
と書いた>>1がいたことに起因。発祥元のスレはどこだったか忘れたが、「どこ
そこの女子大生が絞殺云々」というスレだったような。</strong></p>

●段落にクラス名
<p class="strong">「既出」の意味。とあるスレで「がいしゅつかもしれませ
んが…」と書いた>>1がいたことに起因。発祥元のスレはどこだったか忘れた
が、「どこそこの女子大生が絞殺云々」というスレだったような。</p>

後者の方がスマートな感じがするんだが、
スタイルシートを切った(or利かない)状態でも強調の意が伝わるのは
前者だと思うんだ。


484 :Name_Not_Found:02/01/27 09:09 ID:5VX/wZV7
>>483
前者かなぁ。
後者はクラスで強調の意を表してるけど、
いくらクラスを付けても所詮pはpだし。

485 :Name_Not_Found:02/01/27 09:34 ID:WBRJJTTu
うーん、class は意味付けのためにあるって解釈でいいのかな。
というか、<div class="...">..</div> なんかまさしくそんな感じで使ってるけど。


486 : ◆BFAcsz86 :02/01/27 10:19 ID:CidUvbWt
>>464
使いわけは >>458 に書いたとおり。
強調のレベルが3段階以上の場合は、(現状の)HTMLでは力不足。


>>483
もちろん前者。


487 :Name_Not_Found:02/01/27 11:09 ID:ySJggP4x
>>483
CSSを使って、
・強調段落の文字色を変えたい時→前者
・強調段落の背景色を変えて、蛍光ペンでなぞった感じにしたい時
(行間に通常の背景色が現れる場合)→前者
・強調段落の背景色を変えて、四角く塗りつぶした感じにしたい時
(行間も通常の背景色ではなくなる場合)→後者
・強調段落全体を四角く枠囲いしたい時→後者

あまりStrict的な考え方ではないかもしれないけど、俺はこうしてる。

488 :Name_Not_Found:02/01/27 11:50 ID:FhClVt7A
>引用にq要素とblockquote要素があるんだから
>例えば強調にもstrong要素とblockstrongがあってもいいだろう。

という意見なら分からんでもないが、
やっぱり<p class="strong">〜</p>だと違和感があるな。

489 : ◆HTML/.Kg :02/01/27 13:06 ID:8Cw6QoAf
いくつかの段落の中で特定の
「段落(群)」を強調させたいなら、
<div class="strong"><p>〜</p></div>
でいいんじゃないだろうか。

ただ、自分なら段落の内容がたまたま強調する
部分しかなかったと考えて前者にすると思う。
ins要素でその段落に文章を追加する時にも
その方が融通が利きそう。
それに、そもそも段落そのものを強調する
ということがstrictなのかどうかも疑問。
少なくとも、慣習的なやり方ではないと思う。

490 :Name_Not_Found:02/01/27 18:00 ID:1b2tTwJm
<p class="strong">ほげ</p>
のように、擬似的な要素を作るのは好ましくない。

しかも、段落全体を強調って言っても、

<p class="strong">これはこういうことだと思うんだYO!</p>

の場合は良いかも知れないが、この段落に文章を追加したくなったらどうするの?

<p><strong>これはこういうことだと思うんだYO!</strong> 何故かって? それは…</p>

結局、強調されているのは段落全体ではなく、あくまで段落の中のテキストだ、
ていうふうに考えてる方が何かと都合がよいと思われ。

491 :Name_Not_Found:02/01/27 18:46 ID:wS5MZr2p
<strong class="low">
<strong class="high">
こんな使い分けでいいんでないかい?

492 :Name_Not_Found:02/01/27 18:48 ID:HrRUrvGx
>>483
段落ごと強調などしない。
「結論」にあたる段落は頭に持ってきて、専用のクラスを定義してる。

>>489 の意見に近いのかもしれないが、文章中の特定の段落を強調するってのは
文章として間違ってると思うぞ漏れは。

493 :Name_Not_Found:02/01/27 21:04 ID:yHLkznnh
ホームページって言葉つかわせてくれよ
なんだよひゅーなんとかパッカード社って
そんなの知らねえよ。

494 :Name_Not_Found:02/01/27 21:30 ID:frgHibnG
なんでここで言うんだyp

495 :483:02/01/27 21:37 ID:sGIrBtoS
>>484-492
ありがとう。参考になったよ。

みんなの意見を聞くうちに、強調すること自体が重要なのではなく、
何故強調したいのかが大事なのかもしれないと思った。

俺がしたかったのは、小説みたいなページで、会話文だけを強調したかったんだよ。
で、今まで俺は、

 <p>彼は言った。</p>
 <p><strong>「逝ってよし!」</strong></p>
 <p>すると相手は即座に、</p>
 <p><strong>「オマエモナー」</strong></p>
 <p>と言い返した。</p>

とか、

 <p>彼は言った。</p>
 <p class="strong">「逝ってよし!」</p>
 <p>すると相手は即座に、</p>
 <p class="strong">「オマエモナー」</p>
 <p>と言い返した。</p>

みたくなるんだと思って(誤解して)た。
でも、みんなの意見からすると、

 <p>彼は言った。</p>
 <p><strong class="talk">「逝ってよし!」</strong></p>
 <p>すると相手は、</p>
 <p><strong class="talk">「オマエモナー」</strong></p>
 <p>と言い返した。</p>

とか、

 <p>彼は言った。</p>
 <p class="talk">「逝ってよし!」</p>
 <p>すると相手は、</p>
 <p class="talk">「オマエモナー」</p>
 <p>と言い返した。</p>

とかするべきなんだよね? きっと。


496 :Name_Not_Found:02/01/28 00:12 ID:kvIA7cT1
っていうか、p と strong が同じレイヤーに存在してるのが
そもそもの間違いの元だとおもうんだが。

p は構造で、strong は意味でしょ?
W3C にヴォケ茄子と言いたい。

497 :Name_Not_Found:02/01/28 00:26 ID:1rexiuIY
>>496
>っていうか、p と strong が同じレイヤーに存在してるのが
>そもそもの間違いの元だとおもうんだが。

そうか? この二つが密接に関係しているからこそHTMLはHTMLなんだと思うが。
少なくともW3Cに文句を言うのは筋違い。
元々SGMLがそういう言語なんだから、文句はISOにどうぞ。

498 :Name_Not_Found:02/01/28 01:05 ID:fLZh/EUV
>>496
意味をマークアップする要素が無いとして、

<p>それは<strong>絶対変だ</strong></p>

は、

<p>それは<span class="strong">絶対変だ</span></p>

としたほうがいいということでしょうか?

<span class="strong">みたいなのは、よく使いそうなので、
<strong>をあらかじめ用意してあるんじゃないかなぁ。




499 :Name_Not_Found:02/01/28 01:06 ID:kvIA7cT1
>>497
んじゃ。
ヴォケ茄子、季節外れなんじゃ>ISO

500 :Name_Not_Found:02/01/28 01:14 ID:kvIA7cT1
>>498
<p class="notice">
熊パケット網が流行中
</p>
<p>
某所からの報告です。
ただし、<span class="notice">北海道限定</span>とのこと。
</p>

意味と文章構造って交錯するものじゃないの?


501 :Name_Not_Found:02/01/28 01:22 ID:fLZh/EUV
>>500

御意。
だから、「レイヤーを別に」というのは、ちょっと違和感があるんです。


502 :Name_Not_Found:02/01/28 01:31 ID:kvIA7cT1
>>501
ええ、だから、交錯するからこそ
レイヤー別にするべきじゃん?ってことですが。

別にしとけば、strong な p はどうやったらいいの?
なんてこと悩む必要なかったんだと思うんだけど。
どうですか?

503 :Name_Not_Found:02/01/28 01:40 ID:fLZh/EUV
>>502
レイヤーを記述する別のメタ言語みたいなのが必要だってこと?


504 :Name_Not_Found:02/01/28 01:42 ID:kvIA7cT1
>>503
うーん、そうですね、
属性で記述するようにしとくべきだったとか。
class なんかうってつけじゃないですか?

なんか、もう、XML でいいじゃんって感じです。

505 :Name_Not_Found:02/01/28 01:46 ID:fLZh/EUV
>>504
結局面倒だからhtmlに、strongがあったりするし、
xhtmlがあるんじゃないかと思う今日この頃。
xmlでもいいけど、UAの実装とか考えたら、htmlの資産は、大きいですよ。


506 :Name_Not_Found:02/01/28 01:49 ID:kvIA7cT1
>>505
でもなんか、美しくないです。

507 :Name_Not_Found:02/01/28 01:59 ID:fLZh/EUV
>>506
美しさを求めるなら、xmlはより美しくないんじゃないかな。
それこそレイヤーもへったくれも無いような気がしますが。
業務的には(謎)、htmlのつもりでxhtml使っといて、いざとなったら、
名前空間で逃げればいいかと。
まぁ、美しくないのは確かです。


508 : ◆HTML/.Kg :02/01/28 03:03 ID:c4ZNRLCV
そりゃ、後方を気にしているうちは美しくはならないだろうね。

509 :Name_Not_Found:02/01/28 04:34 ID:3x4Lip4z
XHTML 2.0 て、後方互換を無視する仕様になるんでしたっけ?


510 :Name_Not_Found:02/01/28 04:50 ID:1rexiuIY
<a xlink:href="hoge.html">hogehoge</a>
とかになっちゃったら、後方互換的にはきついかも知れないが
(この辺未定って言ってたよね?)
でも対象がそもそもXMLパーザである以上、そのくらいは構わないと思うのだが。

511 :Name_Not_Found:02/01/28 05:45 ID:3x4Lip4z
XQuery とか XLink とか XPointer とか
ぜんぜん理解らないんですが、
双方向リンクを作ったり、ある"範囲"に対してリンクしたり
出来るようになるんですよね?

こういうのが使えるようになるんだったら
もう昔のしがらみなんてバッサリやっちゃってくれて結構です。

IE とか Mozilla とかで使えるようになるまで
たとえ五年とかかかろうとも、脳内で翻訳するから漏れは幸せになれます。

512 :Name_Not_Found:02/01/28 12:12 ID:+N8EIZOM
>>510
後方互換は各サイト運営者がxml版とhtml版を用意していくことで補完するしかないだろうな。
ただ、「普通の」ページ作成者がHTMLから離れるのはまだまだ先の話(そんな時代が来るのかは微妙だが)。

漏れはページ作成はずっとhtmlかxhtmlでやっていくと思う。
新たに得られる事と覚えなければならない事を考えると移行する気にならない。

513 :Name_Not_Found:02/01/28 19:23 ID:NKAGSLe1
ザンジバルのように後方は無視した実装で行くべし。
それが漢

514 :Name_Not_Found:02/01/28 19:32 ID:/pEO5aBs
後方を無視するサイトが増えないと、いつまでも古いブラウザを
使いつづけるアホどもが減らないからな。

Microsoftって、そのためにセキュリティーホール作ってるんでしょ?

515 :Name_Not_Found:02/01/28 19:39 ID:NKAGSLe1
class名って論理的じゃないとだめ?
おれのとこのBBSの色を変えるところを

.cool{color:blue}
.heat{color:red}
.moe{color:#f0f}
とかしてたけどバカらしくなって
.blue{color:blue}
.red{color:red}
.pink{color:#f0f}
に変えたよ。



516 :Name_Not_Found:02/01/28 19:55 ID:BmIr/Fet
色を変えるためにマークアップするべきじゃない

517 :Name_Not_Found:02/01/28 20:05 ID:Y68E/AuW
てゆーか、#FF00FFってピンクか?
元の.coolとか.heatっていうのもなんか違うと思うんだけど。
書き込む時に文字色を選べるようになってて、
青とか赤とか、そのまんま指定するのであれば、それでいいと思う。

518 :Name_Not_Found:02/01/28 20:33 ID:CGM9s4IB
恐れながら質問をさせていただいても構いませんでしょうか?
レベルの低い質問で申し訳ないのですが。
私、現在XHTML1.1でソースを書いておるのですが、W3Cにてチェックしたところ、
Error: element "input" not allowed here; possible cause is an inline element containing a block-level element
というエラーが出ました。
よろしければ直し方を教えて頂けないでしょうか?
あらましは、
<div id="bbsform"><form method="post" action="petit.cgi">
<input type="text" id="email" size="20" />



</form></div>
となっております。
検索はしてみたのですが良く分からなくて。
ここなら良い知恵を
授けてくださるかと思い。投稿しました。

519 :Name_Not_Found:02/01/28 20:46 ID:MICbsnm6
form直下にインライン要素は置けない。
fieldsetとかdivを入れとこう。

関係無いけど、inputにnameはいらんの?
idで値をcgiに渡せたっけ?

520 : :02/01/28 20:49 ID:gv61NdYh
>518
答えは >519 が示してくれているので,とりあえず日本語の lint の URL でも.
エラーメッセージも日本語のほうがわかりやすいのではないかと.
ttp://openlab.ring.gr.jp/k16/htmllint/htmllinte.html

521 :518:02/01/28 21:24 ID:CGM9s4IB
>>519さん
>>520さん
どうもありがとうございました。
無事解決致しました。
idはnameの写し間違いでした。
すみません。

522 :Name_Not_Found:02/01/28 22:50 ID:ypfAdjQK
>>509

上の方のリンクから飛んでくと読めるW3Cの記事でも
そんなことは書いてあった。

でも、section要素新設しながら、h1〜h6に加えて新設される
見出しクラスを限定されない見出し要素がhなんだよ・・・。
headingに何故しない?って感じ。

美しくしようという気はさらさらないらしいW3C

523 :Name_Not_Found:02/01/28 23:14 ID:XHclFiUW
1要素につき12バイト少なくて済むから

524 :Name_Not_Found:02/01/28 23:14 ID:54pabTGs
恐れながら質問させていただきます。

[サイトのロゴ]
ナビゲーションバー====================
ページのタイトル
本文(以下略)

このようなデザインですべてのページを作る場合に、
サイトのロゴをH1にするべきなのか
ページのタイトルをH1にするべきなのか迷ってます。

サイトの中の1ページであるからサイトのロゴがH1という考え方もできますし、
そのページの主な内容がタイトルであるわけだからタイトルがH1という
考え方もできるように思います。

そんな些細なことで悩むなといわれればそれまでですが、
信者的にはどっちでしょうか?

525 :Name_Not_Found:02/01/28 23:36 ID:Y68E/AuW
そのページのタイトルがh1にきまっとる。

526 :Name_Not_Found:02/01/28 23:37 ID:NdBbxin6
>>515
ほんとにバカらしい。
.a {color:blue}
.b {color:red}
.c {color:#f0f}
で十分だよ。論理的だし。

527 :Name_Not_Found:02/01/28 23:39 ID:rU4LmFaG
head があるのに heading 作ると紛らわしい

なんて理由かも

528 :Name_Not_Found:02/01/29 01:14 ID:6bJD+RWt
小説のHTML化についてなんですが
文章の区切り方が2通りあって
ひとつは空行、もうひとつは「*」とか記号を並べる場合があります。
意味は、前者は時間の進行、後者は視点の変換だと思っています。
どのようにマークアップするべきでしょうか。

529 :Name_Not_Found:02/01/29 01:44 ID:oHDXdOoq
空行は直前か直後のパラグラフにclassつけてマージン指定だろうね。
或いは時間ごとのまとまりをそれぞれdivで包括するか。

後者も<p class="視点の変換">*******</p>
とするかなあ。自分だったら。

530 :Name_Not_Found:02/01/29 01:45 ID:tv84PVWR
>>528
「*」とか記号を並べることに意味がある場合は
そのまま
<p>*******************</p>
にすればどうよ?





531 :Name_Not_Found:02/01/29 01:50 ID:zRg+yEN+
>>528
俺なら、<hr class="〜" /> で。 <object>*****</object> なんかもいい。

532 :茶文字 ◆d38VidMY :02/01/29 02:12 ID:6Tw7PI2j
******という表現が視覚的であることを考えると、<p>でマークアップしてよいものかどうか。
>>531が挙げている<hr>がもっとも近い気がする。

あとは、******を画像で用意してしまう手もあるかも。
たとえば * 1個分が 30px x 30px の透過GIFだとして、以下のようなスタイルを組み合わせては?

.view-change{
 padding-bottom: 50px; /* [*]の画像を表示するために十分なpadding */
 background: url(./astarisc.gif) bottom repeat-x;
}

<p class="view-change">
本文
</p>

アスタリスクがこのスペルでいいのか知らんが。

533 :Name_Not_Found:02/01/29 02:26 ID:zRg+yEN+
>>532
区切りが構造として入らないので、スタイルに頼るのは良くないと思う。
……というか、ここでは、なるべくスタイル化しない方向で考えましょう。

<hr /> が嫌でも、明示的にobjectの挿入の方向で、よろしく。

534 :茶文字 ◆d38VidMY :02/01/29 02:59 ID:6Tw7PI2j
>>533
ああそうか 区切りは視点が切り替わるポイントだから、直前の段落に入れたらあかんのね。
言われてみたらその通りだな。


535 :Name_Not_Found:02/01/29 07:44 ID:d6SG1OWR
<hr class="time">とか<hr class="view">とかで対応できないですかね?

hr.time {visibility: hidden }
hr.view {background-image: url("asterisk-line.gif") }

みたいにして。hr.viewの方は適当です。
hrのスタイルっていじったことがないので。

536 :Name_Not_Found:02/01/29 07:50 ID:d6SG1OWR
>>535です。>>531-534ですでに出ていましたね。
リロードするまで>>530までの記事しか読み込めてなかったようで。
すいません。

537 :Name_Not_Found:02/01/29 08:14 ID:M29Pf0uA
>>523

それだったらsection要素なんて新設しないで、
sc要素とかにすればいいんだ。

538 :Name_Not_Found:02/01/29 10:22 ID:x/14Ugjj
>>537
それだと"soft core"と勘違いされかねない。
W3Cは良く考えている。

539 :Name_Not_Found:02/01/29 23:40 ID:+6v0lfVi
HTML仕様書の11.2.6によれば、
th,td要素の属性のうちwidthにつき、
HTML4.0ではwidth = pixels [CN] ですが
HTML4.01ではwidth = length [CN] です。
これについては「附属書 A: 変更点」にも記載されてないみたいです。
いったい変更の理由はなんなのですか?
Web上のHTMLレファレンスでも両方の定義があって混乱させられます。

540 :Name_Not_Found:02/01/29 23:48 ID:3nQvp5ou
SVG 混在の XHTML 文章はどう思います?
ヘッダ文章を修飾するのに SVG を使ってるようなケース。

これはデザインとコンテンツ分離に失敗してるケースでしょうか。

541 :Name_Not_Found:02/01/30 12:22 ID:u2RvyOez
>>540
図である必然性があるなら何の問題もないと思うけど、
ただの飾りというのはどうなんだろね。



542 :Name_Not_Found:02/01/30 12:24 ID:g8HAFXaH
Wiki みたいなのを正しくマークアップするにはどうしたらいいんでしょう。
いや、違うな、どういう文章構造にしたらいいんでしょう?だ。


543 :Name_Not_Found:02/01/30 19:14 ID:DPLjPmLJ
W3C信者的にはXHTML1.1で<applet>タグをどう扱うのがベストなのでしょうか?

544 :Name_Not_Found:02/01/30 19:26 ID:MgcJn9Cw
>>543 <marquee> と同列に扱う。

545 :Name_Not_Found:02/01/30 19:44 ID:zi70PPI9
>>544
ワラタ

546 :Name_Not_Found:02/01/30 19:50 ID:jDAJd+VF
知り合いにW3C信者というのは初めて見るサイトはコンテンツを見ないで
いきなりソースを見て
「なんだよ、文章宣言もないじゃないか フ」
と鼻で笑う人種と聞きましたがそうなのですか?

547 :Name_Not_Found:02/01/30 20:11 ID:nR1jZRn3
>>546
そういうやつはきっと文章宣言を見つけても
即行W3C HTML ValidationにURL突っ込みそうだな。


548 :Name_Not_Found:02/01/30 20:11 ID:hdZsbUYM
>>546
そうです。基本でしょう。(w


549 :Name_Not_Found:02/01/30 20:12 ID:hdZsbUYM
>>547
チェッカーにかけなくても、点数がわかるくらいでないと信者とは言えません。


550 :Name_Not_Found:02/01/30 20:17 ID:MgcJn9Cw
文章宣言なんてものに出くわしたら腹抱えて笑って即刻晒すだろ。

551 :Name_Not_Found:02/01/30 20:17 ID:OxkiUpmJ
>>549
そいつが友人ならチェッカー要らずだ(w

552 :Name_Not_Found:02/01/30 22:12 ID:O0sP/xit
view-source:http://www.cc.rim.or.jp/~sho_h/takepod/
はちゃんと文章型宣言でてるよ。

553 :Name_Not_Found:02/01/30 22:18 ID:U5Ph+yes
誰かそろそろつっこもうぜー

554 :ブラウザの優しさには涙が出る:02/01/30 22:40 ID:gu1htgJK
>552
オイラの知らない宣言してる!(w

555 :Name_Not_Found:02/01/30 23:24 ID:O0sP/xit
<p>古池や</p>
<p>かわず飛び込む</p>
<p>水の音</p>

ってだめ?

556 :Name_Not_Found:02/01/30 23:28 ID:MgcJn9Cw
>>555
それぞれの P 要素の内容が段落だという強い信念があるならば許可。

557 :Name_Not_Found:02/01/30 23:37 ID:CBifZBUQ
Sentence Type Declaration
<!SNTTYPE SYSTEM "myown.std">

558 :Name_Not_Found:02/01/30 23:38 ID:Ix2Cf3vh
>>555
なんか過去レスにあった気がする。

559 :Name_Not_Found:02/01/30 23:51 ID:O0sP/xit
そもそも段落ってなんなんだ?

560 :Name_Not_Found:02/01/30 23:56 ID:8oJmmf3O
pは段落じゃないよ。パラグラフだーよ。


561 :Name_Not_Found:02/01/31 00:43 ID:fs9Uq0MC
パンダグラフ

562 :Name_Not_Found:02/01/31 01:09 ID:dQ/CWJ5j
パソピア7

563 :Name_Not_Found:02/01/31 01:27 ID:U1/XSn89
>>560
でも、パラグラフは段落だけどね。

564 :Name_Not_Found:02/01/31 01:39 ID:sm4NMsxZ
単に段落というと和文の「形式段落」のことのように受け取られがちな気が。
あえて「意味段落」と呼んだ方が良いように思う。誤解を避けるということで。


565 :Name_Not_Found:02/01/31 02:00 ID:U1/XSn89
>>564
形式段落に p 使っても、何の問題もない。
何故そんなことに拘るのか?

566 :564:02/01/31 02:06 ID:dd8qlhLD
>>565
形式段落と意味段落を同一視して何の問題もないということはないよ。
だからそんなことに拘るの。


567 :茶文字 ◆d38VidMY :02/01/31 02:12 ID:Fjd1Mj7k
>>566
<div>の使い方によっては両者をきちんと区別できる気がするが
Strict的にはそれではだめなん?

568 :Name_Not_Found:02/01/31 02:22 ID:ik5UGICH
葉と丸の
<p><a href="#top">先頭へ</a></p>
は段落?

569 :Name_Not_Found:02/01/31 02:26 ID:U1/XSn89
>>566
h* の使われ方のバラエティーに比べたら、そんなことはたいした問題ではないと思う。

570 :strictやらも:02/01/31 02:39 ID:cvfolCn5
所詮"程度"問題かい

571 :Name_Not_Found:02/01/31 02:42 ID:U1/XSn89
>>570
だって、HTMLだもん。なるべく要素の種類を削る方向で考えないと。

572 :564:02/01/31 02:53 ID:dd8qlhLD
>>567
それもアリとは思うけど、
p要素の意味はもともとparagraph(意味段落)なのだから、
UAには div(意味段落)>p(形式段落) ではなく
div(意味段落より大きな集合)>p(意味段落) と
解釈される可能性の方が高いのではないかと。
もしそういうUAがあれば、の話ですが。

それよりは、pの原意をそのまま使って
p(意味段落)>span(形式段落) とした方が
良いのではないか、と思うのです。


573 :茶文字 ◆d38VidMY :02/01/31 04:19 ID:Fjd1Mj7k
>>572
つまり、形式段落が邦文に独特の用法だから、欧文由来のHTMLでマークアップしきれないという指摘なのよね?
(現行の)HTMLはp内にブロック要素を持てないから、邦文のスタイルとなじまないってわけだ。

しかし。
>p要素の意味はもともとparagraph(意味段落)なのだから、
>UAには div(意味段落)>p(形式段落) ではなく
>div(意味段落より大きな集合)>p(意味段落) と
>解釈される可能性の方が高いのではないかと。
>もしそういうUAがあれば、の話ですが。

pはまさに段落だけど、UAはdivはブロック要素としての解釈しかしない。
DTDにブロック要素としての位置づけしかされてないんだから、それ以上の勝手な解釈はしてはならないはず。
意味段落をdivでまとめた場合、そうすることで「ああ、これは意味段落なんだな」と解釈するのは
閲覧者になるのではないかと思う。

そもそも欧文に「意味段落」「形式段落」の区分が存在しないなら、pの原意は「段落」であって
「意味段落」ではないのでは?
# ほんとに欧文に形式段落がないのかは知らんが。

ま、あくまでHTML4.01Strictまでの範囲でどこに落としどころをもっていくかの話で、
XHTMLでpがブロック要素を内包できるようになりゃそれに越したことはないと思うけど。

574 :Name_Not_Found:02/01/31 05:06 ID:loDL2R+m
英語に意味段落、形式段落の違いがないって本当?

575 :Name_Not_Found:02/01/31 06:43 ID:zmH7cAB7
なんにしても、全世界の全ての文章の表現に適用出来るような仕様とは
いいがたい部分もあるということで。
…既出ですね。

576 :Name_Not_Found:02/01/31 07:28 ID:ZsV0GHKi
素朴な疑問なんだけど paragraphって、本当に意味段落なのかなあ。

INやNNなどのUAで、スタイルシートを使わないデフォルトの状態では、
paragraph と paragraph の間って、必ず1行空くよね?

「1行空く」という形式が必ず適用されるってことは、
paragraph は形式段落なのかもしれないと思ったんだけど。

それとも paragraph って、日本語の形式段落と意味段落の中間の性質の
ものなのかな?

577 :Name_Not_Found:02/01/31 07:33 ID:GLZiOsXn
HTML ってそこまで階層構造な言語じゃないような。
もっと平面的な構造で
意味段落は h* とか hr とかで区切れということなんだと思ってた。


578 :Name_Not_Found:02/01/31 08:07 ID:zmH7cAB7
既出っぽいんですけど、
ul とか dl にキャプション付けるときって
どんな要素使ってます?
つか、caption 要素、リストにも使えてもいいと思うんだけどなあ。

title 属性でいいのかな...


579 :Name_Not_Found:02/01/31 08:08 ID:fqBxLMPn
>>576
1行空くのはMosaicからの慣習だろ。
英文が基準だからそうなってるだけで。
和文の感覚で考えても答えは出ないんじゃないか。

580 :Name_Not_Found:02/01/31 08:16 ID:GLZiOsXn
むしろメールの書き方とかの慣習だと思うけど。
印刷物だと欧文でも和文同様に字下げで段落表すこと多いよ。

581 :Name_Not_Found:02/01/31 08:27 ID:GLZiOsXn
>>578
>>140 に一つの案があるよ。でも俺もリストに caption 欲しい。

582 :Name_Not_Found:02/01/31 08:54 ID:zUmN6wx6
どなたか>>539の疑問を解いて下さる方はいらっしゃいませんか。

583 :Name_Not_Found:02/01/31 09:12 ID:GLZiOsXn
>>582
パーセント値も使えるように直したんだって。
http://www.w3.org/TR/html4/appendix/changes.html#h-A.1.3

584 :Name_Not_Found:02/01/31 09:40 ID:zUmN6wx6
>>583
あ、そこですか。成程。
すると、ばけらやとほほのHTMLレファレンスは
4.01ではなく4.0で記述してるんですね。

585 :Name_Not_Found:02/01/31 10:23 ID:3D1RwSTT
>>584 ばけらやとほほで聞けよ

586 :Name_Not_Found:02/01/31 10:25 ID:GLZiOsXn
>>584
ばけらは HTML4.0 の Transitional DTD を元にしてるって明記してるね。
とほほのは微妙だな。 HTML4.01 での変更に沿ってる部分もある。

587 :Name_Not_Found:02/01/31 13:03 ID:ovtXkFbv
>>584
HTML 4.01に修正した箇所もあるよ。
http://www.ne.jp/asahi/minazuki/bakera/html/updatelog

> 1999-8-29

> PR-HTML4.01 と言うものが出ておる。少々気が早いという噂もあるが、リファレンスをこれに対応させてみた。
> HTML4.0 からの仕様変更は、
(以下略)
と書いてあるし。TDに付いては書かれていない所を見ると、単なる見落としだと思われ。

588 :Name_Not_Found:02/01/31 13:05 ID:ovtXkFbv
付いては → 就いては

だな、スマン。

589 :Name_Not_Found:02/01/31 13:41 ID:woVwkgdb
うざいよ。ばけらのところでやれって。


590 :Name_Not_Found:02/01/31 13:58 ID:GLZiOsXn
>>587 PR-html401 の時点ではまだ pixels だよ。
http://www.w3.org/TR/1999/PR-html40-19990824/struct/tables.html#h-11.2.6

>>589 シツコクテスマソ

591 :587:02/01/31 14:03 ID:ovtXkFbv
>>589
シツコクテスマソ

>>590
しまった、RECでの修正か。御指摘Thanks。

592 :Name_Not_Found:02/01/31 15:02 ID:4URqOWQg
strictはbr、hr,span,div,物理タグ不可でよろ


593 :Name_Not_Found:02/01/31 15:14 ID:G1YINiYo
物理"タグ"(w

594 :Name_Not_Found:02/01/31 15:33 ID:V7wHe22B
>>592
うーん...
div とか span "要素"はなぁ。
なくなると意味付けに困る。

よくよく考えると"強調"だから strong に class 付けして...
ってのは、どっか違うと思うので。

br と hr は名前がアレだけど、
構造化するのにそんなに邪魔なものとは思えない。


595 :Name_Not_Found:02/01/31 16:36 ID:KkbHGFyW
brはソースを汚す
hrはみかけだけだー
と言ってみるテスト

596 :Name_Not_Found:02/01/31 17:00 ID:GSsBZYtu
brってあまり使いたくないんだけど。こういう場合はどうすれば良いんでしょう?
Perlのソースを表示する。
<p>
<code>
#!/usr/bin/perl<br />
$script = "./bbs.cgi";<br />
(以下略)
</code>
</p>
私はこんな感じの時にbrを使ってるんですが、もっと良い使い方ありますか?
preも考えたんですが、長い行の場合、横スクロールが出てしまうのです。

597 :Name_Not_Found:02/01/31 17:03 ID:KkbHGFyW
hr{width:1px; height:100px;}
は水平線でなく垂直線になるのでstrictじゃありませんか?

598 :茶文字 ◆xELvisFU :02/01/31 17:12 ID:Fjd1Mj7k
brの話が出てふと思ったのだが、昨日の意味段落/形式段落の違いを、
以下のように表現すれば?

br{ margin-bottom: 15px; }

<p>
意味段落のはじまりはじまり。昔々あるところに、モナーさんとギコさんが…
………………
………………
形式段落の終わり
<br>
形式段落の始まり
二人はモナ太郎を大切に育て、モナ太郎もすくすくと育って…………………
………………
………………
意味段落の終わり
</p>

それでもbr好きぢゃない人には抵抗はあるかもですが。

599 :Name_Not_Found:02/01/31 17:21 ID:GSsBZYtu
>>598
それだとインデントが表現できない…。

600 :Name_Not_Found:02/01/31 17:26 ID:HP0j+9OP
>>596
preでいいよ。長い行は自分で折り返せばいい。
ソースコードって、そういうものじゃん。


601 :どーでもいいことだが:02/01/31 17:27 ID:9qS1Z8HI
英語には意味段落と形式段落が無いのか?
英語の本でも意味段落を「*」や三行空きで示すことはあるぞ。

602 :Name_Not_Found:02/01/31 17:30 ID:HP0j+9OP
パラグラフと意味段落・形式段落の違いには拘るのに、
改行の事情の違いには拘ってないのかしら?
和文なら、<br />をたくさん使ってもいいことにすればいいじゃん。


603 :601:02/01/31 17:34 ID:9qS1Z8HI
>パラグラフと意味段落・形式段落の違い
そもそもそれがよくわからないな。何が異なるのか。
paragraphは段落。段落を種類に分ければ意味段落と形式段落がある(英語でも日本語でも)。
――これで何か問題がありますか?

604 :602:02/01/31 17:48 ID:DcAfCdK/
>>603
御意。俺はその辺まったく拘ってない。
拘ってる人は片手落ちなのかもしれない
と疑問を感じているのみ。

605 :602:02/01/31 17:51 ID:DcAfCdK/
>>600 に追記。
pre内の長い行、右端で折り返さないエディタでも
ブラウザと同じ表示になるよね?

606 :564:02/01/31 18:29 ID:deVHDNn2
私は、p要素の元になっている英語のパラグラフといえば、
最初や最後のセンテンスがそのパラグラフの主題、
トピックセンテンスになっているという種類のものだ、と
ずっと思っているのです。

で、個々の「段落」それぞれに主題と呼べるようなセンテンスがない、
というか見やすさや小気味の良さのためだけの「形式段落」までも
パラグラフと見なすことには抵抗を感じる。

上で挙げられていた例でいえば、
「ふるいけや」
「かわずとびこむ」
「みずのおと」
それぞれをぶつ切りにして、そこにそれぞれ
トピックセンテンスがあると言えるのかどうか。
私は、言えないと思う。

こういう理由で、私は形式段落とパラグラフの違いに
拘っているのです。
(よって、形式段落の方はspanなりbrなりで表すのが
ベターなのではないか、と)


607 :Name_Not_Found:02/01/31 18:41 ID:GLZiOsXn
参考資料:
http://dictionary.cambridge.org/define.asp?key=paragraph*1+0


608 : ◆HTML/.Kg :02/01/31 19:03 ID:qNr4pqcK
>>596
code{white-space:pre;}

>>597
CSS切った時にそれでもStrictなら。

>>602
>和文なら
根拠は?

>>605
そういう場合のためのoverflow:auto

609 :Name_Not_Found:02/01/31 19:12 ID:KkbHGFyW


(from Cambridge International Dictionary of English)

paragraph, abbreviation para
noun [C]
a short part of a text, consisting of one or more sentences and beginning on a new line. It usually deals with a single event, description, idea, etc.
You'll find the reference in book 2, paragraph 4, line 56.
The news rated only a few paragraphs in the local newspaper.

610 :Name_Not_Found:02/01/31 19:25 ID:KkbHGFyW
par・a・graph  
 
n. (文章の)節, 段落; 段落標, パラグラフ記号 ((¶)); (新聞の,見出しのない)短評. 
− vt. 文節に区切る; (ニュースなどを)短い(新聞)記事に書く. 


gooによると見出しのない 短評らしいけどhnつけちゃだめなん?


611 :Name_Not_Found:02/01/31 19:42 ID:V7wHe22B
なんか、pre の存在意義が疑わしくなってきた。

>>597
hr って horizontal だかそれに類似する言葉の略なんじゃなかったっけ。

break とかだったらまだよかったんだけど。

612 :Name_Not_Found:02/01/31 19:53 ID:UixUivM6
HR = Horizontal Ruleね。

613 :Name_Not_Found:02/01/31 19:55 ID:Co39AFBX
>>597
短い(長さが1pxしかない)水平線だからいいんじゃないの?

614 :Name_Not_Found:02/01/31 20:01 ID:gSVt7Gs5
p{white-space:pre;}

しかしIE6で閲覧すると、xhtmlだとxml宣言が不正になりpreにならない
結果html4.01で書かなければいけないワナ。

615 :Name_Not_Found:02/01/31 20:02 ID:UixUivM6
そう言えば、縦書きの時はやはりVertical Ruleになるんだろうか>Horizontal Rule

CSS3 module: text
http://www.w3.org/TR/2001/WD-css3-text-20010517
はまだ読んでないからよく分からん。

616 :596:02/01/31 20:11 ID:GSsBZYtu
>>600
確かに、そうですね。うーん。

>>608
とりあえず、それで凌ぎます。
ただ、対応してるブラウザが…(;´Д`)

>>614
がーん。だからIE6でやってもpreにならなかったのか…。
XHTMLウツ。

617 :Name_Not_Found:02/01/31 20:21 ID:V7wHe22B
>>613
前スレで既出な議論だけど、
Horizontal っていう見た目(?)が名前に入ってるのが評判悪いみたい。

618 :Name_Not_Found:02/01/31 20:28 ID:gSVt7Gs5
>>616
文章型宣言文の前に文字が入るとだめらしい
マイクロソフト逝ってヨシ

619 :Name_Not_Found:02/01/31 20:34 ID:GLZiOsXn
>>618 だからさぁ文章型宣言ってなんだよう〜
でも M$ 逝ってよしには禿同

620 :Name_Not_Found:02/01/31 21:10 ID:GLZiOsXn
それにしても標準モードでないと white-space:pre が効かないって
どういう理屈なんだろう? 理解できん。

621 :Name_Not_Found:02/01/31 22:38 ID:KIkZna7J
ソースコードにさえ pre を使わないなんて……。
そのうち、表にさえ table を使うなとか言いそう。
すぐCSSの話に持ち込もうとする人には、
このスレに来てほしくないよ。


622 :601:02/01/31 23:22 ID:ScX8/vHw
>>606
なんで段落と呼んでおけばよいものを「形式」段落とか呼び分けねばならないのか
まだ理解できません。
例に挙がった「ふるいけや」は短詩なのであって、詩であれば<pre>を使用して
整形すればよい。preの用例にはソースコードだけでなく詩もあったはず。
また一行で改行する短いパラグラフ=段落があっても別に変ではない。
英文でもそれはあることです。
英文


623 :Name_Not_Found:02/01/31 23:27 ID:GSsBZYtu
>>621
でもそれじゃあ、codeってなんのためにあるんですか?

624 :Name_Not_Found:02/01/31 23:30 ID:8/GSyzbz
オイラも聞きたい >>621

625 :Name_Not_Found:02/01/31 23:31 ID:SNhO/l2e
<pre><code>.禿同{font-size:150%;}</code></pre>
というように2個内包スレ

626 :Name_Not_Found:02/01/31 23:32 ID:V7wHe22B
>>623
違うでしょ。
pre はプログラムリストのためだけにあるわけじゃないよ。
逆に、プリフォーマットしないプログラムリストもあるし。

code と pre は競合するものではないと思うが。


627 :Name_Not_Found:02/01/31 23:32 ID:2e9WMfC0
>>623-624
621じゃないけど、622が言ってるようにpreの中身が詩のこともある。
あくまで「preは整形済みテキスト」「codeはソースコード」です。

628 :Name_Not_Found:02/01/31 23:34 ID:V7wHe22B
つーか、code とか var とかいらねえよ。
そんなん採用するなら date とかもっと一般的な要素採用しれ!

629 :Name_Not_Found:02/01/31 23:36 ID:SNhO/l2e
注釈要素キボン

630 :Name_Not_Found:02/01/31 23:37 ID:2e9WMfC0
>>628
データでない文字など存在するのだろうか

631 :Name_Not_Found:02/01/31 23:38 ID:QVih29/B
整形済みテキストは見栄えに関する要素だと思う漏れはDQNですか?

632 :Name_Not_Found:02/01/31 23:39 ID:GLZiOsXn
>>629
漏れもキボン

633 :Name_Not_Found:02/01/31 23:46 ID:V7wHe22B
>>630
よく見れ。

634 :Name_Not_Found:02/01/31 23:47 ID:GLZiOsXn
>>631
確かに pre は見栄えに関する要素に思えるけれど
改行に意味があるテキストというのが存在するんだから
しょうがないんじゃない?

635 : ◆HTML/.Kg :02/01/31 23:49 ID:HJJIuEd/
その整形に、マークアップするだけの意味があるのならpre
見た目を整えるのが主目的ならwhite-space:pre

日本独特の詩歌やなどは区切りの意味での改行が
在って然りと思うけれど、プログラムなどのコードの
整形に見た目以外の意味があるのかは疑問。
もっと言えば、詩歌さえなければ
pre自体がstrictなのかどうかさえ疑問。
brでも間に合うわけだし。

636 :Name_Not_Found:02/01/31 23:56 ID:V7wHe22B
br より、行であることを示す要素があればいいんではないかなと。

637 :Name_Not_Found:02/02/01 00:00 ID:T8prslZO
>>636
XHTML 2.0 で導入予定です

638 :Name_Not_Found:02/02/01 00:01 ID:12E1JA1k
>>635
詩歌の場合は br ではダメなの?

プログラムコードの場合、一続きの文字データを
br 要素で分断することへの抵抗感みたいなものはあるなあ、俺は。
文書の幅に合わせて勝手に折り返されては困る場合もあるだろうし。

639 :Name_Not_Found:02/02/01 00:06 ID:eDoxh0Ai
>>635
というか、preよりもbrこそstrictでないと思うのだが。

>>638
詩歌だって折り返されちゃ困るのけど。
というか折り返し云々はスタイルシートの問題かと思われ。

# つーか、このスレ異様に活気づいてない?
# 何かあったのか?

640 :Name_Not_Found:02/02/01 00:11 ID:smzAKGdp
折り返しだけでなくpreなら空白(スペース)の固定も考慮してよ。

641 :564:02/02/01 00:22 ID:xMSN5YBM
>>622
段落と名の付くものは全部p要素で良かろうという考えに立てば、
一行ごとにp要素でマークアップすることもアリになり、
そうしたことでデータ的な意味の分断がbrやspanによるものより強くなれば、
原文の意図が損なわれてしまうのではないか、と。
そこに拘っているんです。

そんなの作者の立場から見てもどうでもいい事だと
言われてしまえばそれまでの話なんですが。


642 :Name_Not_Found:02/02/01 00:25 ID:smzAKGdp
>>641
そのことで「原文の意図が損なわれてしまう」のであれば考慮すべきでせうね。
しかしそんな場合ってどんな例があり得るのかちょっと思ひ当りませんナ。

643 :Name_Not_Found:02/02/01 00:34 ID:eDoxh0Ai
>>640
ところで、xml:space属性とwhite-spaceプロパティ
XMLとCSSで別々に対応しているのはどうなのかな。

644 :564:02/02/01 00:41 ID:xMSN5YBM
詩歌とか。
まぁこれはpreで良しと既に上のほうで結論が出てますけど。
そういうことです。

645 :Name_Not_Found:02/02/01 00:47 ID:Z/yPBEph
>>639
段落の話が出ると、こうなりがち。


646 :Name_Not_Found:02/02/01 00:48 ID:YxNb0hBb
>>643
xml:space はどう表示するかは規定していないから、
white-space とは関係ないよね。


647 :Name_Not_Found:02/02/01 00:52 ID:YxNb0hBb
>>635
> 日本独特の詩歌やなどは区切りの意味での改行が
> 在って然りと思うけれど、プログラムなどのコードの
> 整形に見た目以外の意味があるのかは疑問。

あらら。perlやjavascriptでコメントを書いた経験がない人ですか。萎え。


648 :茶文字 ◆d38VidMY :02/02/01 01:45 ID:Hrm7mrnn
code samp kbd varなどは文書内の役割を明確にするから、Strict的だと思うけどな。
良心的なブラウザならcodeでマークアップされた範囲は等幅フォントで表示するはずだから
そのサンプルソースを参照する人には見やすいと思うんだが。
見た目上の問題ならスタイルシートでカバーできるが、要素そのものに位置づけが明示されている
code samp kbd varなら非視覚系UAにも情報提供が容易になる可能性が高い。

649 :Name_Not_Found:02/02/01 02:09 ID:qf4LqTjn
preのテスト。

<p>ウザい↓</p>
<blockquote>
<pre>
アイコラ画像のサイトなんだけど早く見ない
と話題に乗り遅れるよ。

http://www.lime-jp.com/02/
</pre>
</blockquote>

650 :Name_Not_Found:02/02/01 02:21 ID:Z/yPBEph
>>648
そりゃそうなんですけど、その定義されてる種類が中途半端かつ偏ってる
っていいたいんです。

例えば、単語として意味をなさない id 要素とか、
日付を表す date 要素とか、もっと作るべきものはいっぱいあると思うんですわ。

実際、音声ブラウザなんですけど、
2002/1/28 は "いちぶんのにせんに、にじゅうはち" って読んじゃいます。
文脈から判断するの不可能ですよ?
1/28 は 1分の28 かもしれんし。

だから、中途半端な意味付けなんていらない。
別レイヤで提供出来る仕組みにするべき。


651 :茶文字 ◆d38VidMY :02/02/01 03:03 ID:Hrm7mrnn
>>650
別レイヤで提供するとどうなるんだろ……規格上は単純化するが、素人に扱いにくくなったりせんかな。

ま、date要素なんかがあれば確かにありがたいとは思う。
反面、細かい話だが日付の表示法はバリエーションが多い点で難しさはあるかも。

2002/1/28
02/01/28
1.28.2002
01.28.02
Feb 28, 2002
2002年1月28日
壬午年睦月二十八日

これが全部同日を表すわけで……ってこのへんは非視覚系UAの実装の問題ではあるか。

652 :Name_Not_Found:02/02/01 03:05 ID:eDoxh0Ai
>>650
現状での対処は

<ruby class="date"><rb>2002/1/28</rb><rt>にせんにねんいちがつにじゅうはちにち</rt></ruby>
ruby.date rt {display:none;}

とか。

文脈から判断できないのは漢字なんかでもおなじことだし、
人間でも正しく判断できないこともある。

「国境の長いトンネルを抜けると…」は「こっきょう」なのか「くにざかい」なのか、とか。
判断できる人、いる?

653 :Name_Not_Found:02/02/01 03:30 ID:Z/yPBEph
>>652
別スレでは <span title="2002年1月1日">2002/1/1</span> で回避、
って回答がありました。

理想を言えば、すべての漢字にルビふってあったほうが
コンピュータ的には助かるんでしょうね。

入力するときは一意に読みが判ってるんだし、なんとか出来ないかなぁ。
どう読むかをユーザ任せにするっていうメタ情報を含ませてるんだとしたら
なおのことややこしくなりそうだ....

>>651
うーん、素人って code とか var とか使ってませんよ?
#少なくとも私の周りでは。
どこら変を素人と見るかによって変ると思うけど。

別レイヤにするっていっても、
タグによるマークアップを止めろといってるわけじゃないです。

XHTML にして、別ネームスペースで取りこむとか。
文章の内容によって取りこむ意味セットを変えるとかしたら面白そうじゃない?

小説特有の意味付けとか、プログラム特有の意味付けとか。

日付。
それこそ lang とか xml:lang 属性で回避出来そうじゃない?


654 :茶文字 ◆d38VidMY :02/02/01 04:59 ID:Hrm7mrnn
>>653
いや、あなたの発想は間違ってないと思います。
HTMLがコンピュータ由来であるがために、要素にも偏りがあるのではないかという
指摘も納得がいってます。
651まではあくまでHTMLの範囲で考えていたので、XHTMLに移行して新たにDTDを与えるとかなら
もちろんその方が無理がないでしょう。
# 特に、lang属性に着目する視点は鋭いと思う。

しかし、読み(≒ルビ)の情報までファイルに持たせると、データ量が著しく増えそうな気が。
現行のインフラでは少しきつい気がします。
ま、現行のHTMLの話ではないけれども。

つか、Excelで表を作ってHTML変換したときに、指示した覚えもないルビが大量に振られてて
大いに萎えた記憶があるのよね(´д`;)
どでかい表だったから楽をしようとしたんだが、あれはよけいつらかった。
読みの部分を別ファイルにして、閲覧者がそれを利用するか選択できるくらいのシステムでないと、
逆にソースの可読性を下げてしまうおそれがある。
# イメージとしては、ブラウザで画像をOFFったりできるのに近いかな?

655 :Name_Not_Found:02/02/01 08:29 ID:7+acVwZT
dateは同意。今はclass="date"で、スタイル適用させてる。
var や code や def って、知ってても面倒だから書かないことが多い。
数式は変数だらけなんだよ!

656 :Name_Not_Found:02/02/01 09:03 ID:zS9PhrdB
>>653
lang属性をどう使うってのか今ひとつ解らないのだが。

>>655
だからそれはMathMLだって。

657 :Name_Not_Found:02/02/01 11:01 ID:OwiJVwiA
<dl>
<dt><code>p{font-size:18px;
line-height:150%; }
em{font-size:20px;}</code></dt>
<dd><p>p要素直下のem要素の行間は30pxではなく27pxとなる</p></dd></dl>
みたにソースコードをdtにいれたい場合はpreをいれれないからwhite-space
しかあかんよな・・しかし実際はbrでやらんとブラウザによっては横続きになってしまう。


658 :Name_Not_Found:02/02/01 11:26 ID:mffpY+/Q
>>657
それは、dtに段落やブロック引用を入れられないとかいうのと同じで、
dl の使い方が間違っているのでは?


659 :Name_Not_Found:02/02/01 11:32 ID:mffpY+/Q
プログラムのソースコードは忠実に改行を再現する必要があるもので、
且つまた、再利用性を考えれば、余計な文字(<br />とか)を途中に
挟むことも許されないものであるので、pre を使うのが最適。


660 :Name_Not_Found:02/02/01 11:56 ID:7cBZjzlt
そうは言っても &, <, >, はそのまま書けないんだから、
<br /> や を使えばいいとも言えるが。



661 :Name_Not_Found:02/02/01 11:57 ID:7cBZjzlt
>>660 &#xA; が消えました。


662 :Name_Not_Found:02/02/01 13:01 ID:12E1JA1k
>>658
でもそういう 2 個の要素間の関連を記述できる要素とか属性とかホスィ。

663 :Name_Not_Found:02/02/01 13:10 ID:zS9PhrdB
>>662
現状では見出しと本文の関連すら記述できないしね。

664 :Name_Not_Found:02/02/01 18:09 ID:zbZVlMH+
W3Cのxhtmlにxml宣言ないじゃん。
よいの?


665 :Name_Not_Found:02/02/01 18:29 ID:/s0eB8Wn
必須ではないよん

666 :Name_Not_Found:02/02/01 20:40 ID:LDM1HBHL
>>664
W3Cのサイトに期待しても無駄でしょう(w

ソースコードは改行されちゃまずい。スタイルシートで横スクロールを出ないようにすると
($no,$name,$mail,改行
$uri,$msg) = split(/\s/,$valu);
こういう風に表示されちゃって、初心者さんは迷ってしまう。だから素直にpreを使うのが良いとは思う。
でも見た目は美しくないんだよねぇ。(;´Д`)

667 :Name_Not_Found:02/02/01 20:47 ID:12E1JA1k
>>664
文字コードが UTF-8 なら xml 宣言はなくても可。

>>666
Perl あたりはまだ改行の影響を受けにくい方かもとか思った。
シャレにならないのはセミコロン自動挿入を行う JavaScript かも。

668 :Name_Not_Found:02/02/01 21:18 ID:LDM1HBHL
あぁ、そういえば文字コードって何が一番良いんでしょうかね?
何にとって、という目的によって違うような気もしますが。

669 :Name_Not_Found:02/02/01 21:38 ID:NR1jPN5v
>>666
改行の影響をもろにうけるVBScriptなら、preホシー

670 :Name_Not_Found:02/02/01 21:52 ID:7lcf92Bx
日本語のファイルでutf-8は重いよ。
多言語でもないページでutf-8,16,32を使う意義はあるの?
shift_jis軽い。

671 :Name_Not_Found:02/02/01 22:17 ID:12E1JA1k
>>670
そのテキストを処理するプログラム側の事情で
Unicode 使わざるを得ない時はあるな。

672 :Name_Not_Found:02/02/01 22:41 ID:He0hmsvX
html4.01つかっていいよね?
だめ?

673 :Name_Not_Found:02/02/01 23:01 ID:/s0eB8Wn
いいよん

674 :Name_Not_Found:02/02/01 23:12 ID:f7b6P7Ef
>670
あなたの環境ではね。

>672
そのサイトの用途によりますね。

>666-669
コピー&ペーストでなら全く問題なし。>659に同意。
読んでもらうことだけが目的なら雑誌での記述のように
「ここは改行せず1行で記述」という意味の画像でも
置いておけば十分。

675 :Name_Not_Found:02/02/01 23:54 ID:YxveWPJ2
>>674
>「ここは改行せず1行で記述」という意味の画像でも
>置いておけば十分。
こういうのを CSS でやりたいよね。
:first-letter みたいな擬似要素で
:line-break なんてあってもいいと思う。



676 :Name_Not_Found:02/02/02 00:09 ID:OOBXU7oN
画像でいいんだよ。



677 :Name_Not_Found:02/02/02 00:19 ID:zCWnWGlb
いや、擬似要素でもつかわないと改行される場所特定出来ないだろっていってるんだが。
>>676 はどこに img 要素置くの?

pre:line-break { url('return.png'); }


678 :Name_Not_Found:02/02/02 00:34 ID:SAXr0415
>>675
昔 Bugzilla でそんな要望見たなあ。引用を表す ">" を
blockquote:each-line:before { content: ">" }
とかって指定したい、みたいな提案だった。ほったらかしになってるけど。


679 :Name_Not_Found:02/02/02 00:47 ID:OOBXU7oN
>>677
わかるとこならどこでもいいんじゃないの?例えば、

<p>TAB区切りで書いたテキストをdt,ddに変換するPerlスクリプトは以下の如し。</p>
<pre>
<code>
#!perl
while (<>) {
s/([^\n])\t/$1\n\t/g;
s/\t(.+)/\t<dd>$1<\/dd>/g;
s/^([^\t\n]+)/<dt>$1<\/dt>/g;
print;
}
</code>
</pre>
<p><img src="dt_dd.png" alt="" width="209" height="69"></p>

とかじゃ駄目?


680 :Name_Not_Found:02/02/02 03:13 ID:vFPqb6ln
heightがシックスナイン

681 :Name_Not_Found:02/02/02 03:48 ID:gf0OklCk
同じディレクトリへのリンクの場合

<link rel="stylesheet" href="./main.css">

<link rel="stylesheet" href="main.css">

どっちが美しい?


682 :Name_Not_Found:02/02/02 04:18 ID:zCWnWGlb
あ、にたようなので。

http://www.hoge.com/~hoge/ にリンクするのと
http://www.hoge.com/~hoge/index.html にリンクするの、どっちがいいかな?

そりゃ、両方が意味するものは違うんだけど。

あと、サイト内部でも。

index.html と hoge.html があって、hoge.html から index.html にリンク張る場合
<a href="./">index</a> と <a href="index.html">index</a> のどっちがいいか。

683 :Name_Not_Found:02/02/02 04:49 ID:DM2gkz/6
うちのサイトは

./ =./start
です

684 :Name_Not_Found:02/02/02 05:47 ID:o8fTDX8V
>>682
http://www.hoge.com/~hoge/ の方が自由度は高い。
例えばこれならトップページ(?)のファイル名が変わっても
リンク先を変更する必要がない。
XMLに移行してindex.xmlにしたいときとか便利。

(バーナーズ・リーは同様の理由から
「ウェブ上のリソースには拡張子を書かない方が望ましい」としているわけで)

685 :Name_Not_Found:02/02/02 06:26 ID:zCWnWGlb
あ、どっちかというとききたかったのは

<a href="./">..</a> と <a href="./index.html">..</a> なんですけど、
省いたほうがよさそうですね。


686 :Name_Not_Found:02/02/02 08:14 ID:bZZKv6aq
サーバ側からすれば、ファイル名まで指定するほうが嬉しい。
<a href="./">index</a>だと最初はカレントディレクトリにある(サーバが指定したファイル)RootDocumentを探しに入る。
だけど<a href="./index.html">index</a>の場合は最初からindex.htmlを探しに行くから負担が少ない。
同様の理由で、以下のような指定は負担が大きい。
http://www.yahoo.co.jp
↑最後のスラッシュがない。最近よく見るけど、最後のスラッシュなくして記述してる奴。
これだと、まずディレクトリの検索から始めるからね。
まぁ、負担っていってもそこまで大きくないんですけどね。htaccessを検索するのと同じで。

687 :Name_Not_Found:02/02/02 08:45 ID:o8fTDX8V
>>686
最後のスラッシュ、ルートディレクトリの場合は
(省略可能だから)関係ないと思うけど。

http://www.hoge.org/http://www.hoge.org は同じディレクトリを指す。
http://www.hoge.org/hoge はルートディレクトリにある"hoge"というリソースを指す。
http://www.hoge.org/hoge/ は"hoge"というディレクトリを指す。

688 :茶文字 ◆xELvisFU :02/02/02 08:53 ID:Mh9qj7wq
.htaccessで index.cgi -> index.shtml -> index.html の優先順位で走査させてる。
indexを自動作成するスクリプトを置いてるディレクトリもあるから。
で、それぞれのファイルに base urlをルートディレクトリの indexにしているので、
うちのサイトの場合は a href="./" == virtual="/"

689 :Name_Not_Found:02/02/02 08:59 ID:bZZKv6aq
>>687
すんません、書き込んでから気が付いたんですけど訂正するの面倒だったんで。(w

690 :670:02/02/02 10:00 ID:5H4JLW7+
>>674
いや、処理が重いのではなくて、
ファイルサイズが重いといいたかったのよ。

691 :Name_Not_Found:02/02/02 14:59 ID:VRXa1ihJ
htmlがまともなサイトは地味なとこ多くない?

692 :Name_Not_Found:02/02/02 15:08 ID:bZZKv6aq
>>691
たぶん、HTMLを勉強してる人は、厨房がやるようなデザインが嫌いなんだよ。
そうすると読みやすい(見やすい)デザインにしようとする。
まぁ、読みやすく・シンプルでカッコイイデザインが難しいというのもあるけどね。
文章系サイトだったら地味な方がいい。

693 :Name_Not_Found:02/02/02 15:22 ID:N2ZwjIcG
lint厨まるだしの
link要素が
<link rel="start" href="./">
のみある今の状況を打破していいですか?

694 :Name_Not_Found:02/02/02 15:43 ID:o8fTDX8V
>>693
もちろん<link rev="made" href="mailto:〜">もあるよな(w

695 :Name_Not_Found:02/02/02 15:49 ID:ColbPIpj
>>694
なんとなくコンテンツ内にメールアドレス晒すのがいやだからそうしてまつ。

696 :Name_Not_Found:02/02/02 16:01 ID:VV7+qecJ
>>695
いやそうでなくて、Lintで100点を取るためだけに
<link>要素を追加していることを言っているんだろう。

697 :693:02/02/02 16:14 ID:N2ZwjIcG
>>696
左様。
トップページと掲示板とリンクページしかないのにstartもnextも
あったもんじゃねえ。

698 :Name_Not_Found:02/02/02 17:04 ID:ARKsXPkc
トップページ→start くらいは書いててもいいんでないの?
検索で辿り着いた人がトップページに迷わず到達できるように、とか。

699 :Name_Not_Found:02/02/02 17:39 ID:v6p/TR4B
のの字がとほほのstartだけしかないlink要素をばかにするから
こうゆう悩みが出て来るんだよ。

700 :Name_Not_Found:02/02/02 17:47 ID:y0N0uh6u
「みんな、accesskeyってどうしてる? tabindexは?」
http://pc.2ch.net/test/read.cgi/hp/1006224399/
link要素についても若干触れられている。
論じているのもいいが行動するとさらにいい、と思った。良スレ。

701 :Name_Not_Found:02/02/02 18:03 ID:H8C3cWQS
>>699
それは馬鹿にする方が馬鹿じゃないの?
動機はどうあれ結果としてアクセシビリティ・ユーザビリティの足しになるのなら、それは評価して良い。


702 :Name_Not_Found:02/02/03 17:28 ID:bXu2cc0O
24時間無カキコ阻止&アゲ

703 :Name_Not_Found:02/02/03 18:28 ID:yzLd4uhg
なんかピタッとレスが止まったな(w

704 :茶文字 ◆xELvisFU :02/02/03 19:28 ID:wxyQ25TQ
1時間おきにageなのか?

705 :Name_Not_Found:02/02/04 02:04 ID:plhxdopb
現在のデザインとコンテンツを分ける仕組みは間違ってるんじゃないかって思
えてきた。

赤線の引いてある部分は... とか、上記の例では... とか。
そういう文章の書き方が悪いってか?あほらし。

デザインがコンテンツであった場合のうまい書き方ってないんじゃない?
ドキュメント自体にもメディアタイプ指定出来るようにすべきだと思う。


706 :Name_Not_Found:02/02/04 02:20 ID:vNecHJ5y
>>705
デザインがコンテンツなら画像を使うだろ。使わなきゃアホ。
HTMLで書く以上、UAによって表示が異なるのは必然。


707 :Name_Not_Found:02/02/04 02:30 ID:plhxdopb
>>706
そうか?
じゃあ赤い下線をひいた文章を書きたかったら全部画像にするの?
文章の出現順序保証したかったら全部画像にするの?


708 :Name_Not_Found:02/02/04 02:42 ID:WmMQt5h7
>Strict な HTML(*) について語るスレッド

StrictなってどんなHTMLのことをいうの?

709 :Name_Not_Found:02/02/04 02:48 ID:vNecHJ5y
>>708
>>1 に書いてあるじゃん。

710 :Name_Not_Found:02/02/04 02:52 ID:vNecHJ5y
>>707
赤い下線のほうはその通り。むしろ、そんな文書はHTMLで書くなと言いたい。

出現順序は気にしなくて良い。出現順序を変えるスタイルが
デフォルトになってるわけないから。

711 :茶文字 ◆xELvisFU :02/02/04 03:10 ID:+3X132Ka
赤い下線を引いた部分を別の場所で説明するなら……

<style type="text/css">
dfn a{background:url(./red_line.gif) bottom repeat-x;text-decoration:none;}
</style>
・・・・・・・・・・・
なお、<dfn><a href="./foo.html#bar">厨房</a></dfn>は相手にしないのでそのつもりで。
・・・・・・・・・・・
<p id="bar">ところで、視覚系UAでは赤線で示した部分だが、この言葉は実際の所・・・</p>

こんな感じでいいんでねーの?
出現順序の意味がわからんけど、順序が大事なら id="0" から使い方が沸いてこない?
tabindexとか使えない?

つか、707はHTMLに適さないドキュメントを無理やりHTMLにしようとしてないか?
HTMLはメディアのひとつであって、既存のすべてのメディアの代替ではないよ。

712 :茶文字 ◆xELvisFU :02/02/04 03:13 ID:+3X132Ka
と思ったらidは数字から始まっちゃいかんのだな。
id="num0"とか適当でいい気はするが。

713 :Name_Not_Found:02/02/04 03:21 ID:plhxdopb
>>711
デザイン的要素でもコンテンツに含まれる部分ってあるんじゃないかってこと。
強調文字が赤いのは機能的見地から分離可能だけど、
赤い文字に意味があるなら、"赤い"っていう情報は内容と不可分だよね。

>>710
では、HTML ってどういう文章を書くためのものなのか説明してくれると嬉し
い。煽りじゃないです。正直、HTML はどんな文章でも表現出来るようにする
方向に向ってると思ってたので。


714 :Name_Not_Found:02/02/04 03:23 ID:plhxdopb
>>711
上記、とか、下記のような文章と id とか tabindex が結びついてこないんですが....

715 :茶文字 ◆xELvisFU :02/02/04 03:57 ID:+3X132Ka
>>713
断言できる自信があるわけではないんだけど。
デザインそのものがコンテンツの重要な部分を占めるとしたら、
あえてStrictにこだわる方が無理があるんではないかな。

実は私は素材屋をやってたんだけど、画像を求めてくる人ばかりだから
あえてStrictを捨てて無理やりなデザインをしたし、テーブルを使ったレイアウトもやった。
それは見る人を視覚系UAに限定したからの話ですが。

赤いことに意味がある状況っていうのもこれと同じで、視覚系UAだけを対象にした
ドキュメントを書いているなら、視覚的な情報に依存したマークアップになり得る。
でも、これは必ずしもStrictから離れるわけではない。
なぜなら「Strictか否か」は文法の問題であって、視覚系UAのみを対象にすることの
是非はアクセシビリティーの問題だから、関連はしているが同一ではない。

705の「赤い線」は本文の記述であってマークアップではないから、あえて言うなら
「本文のアクセシビリティーが低い」のであって、マークアップやスタイルシートの
使い方によっていくらかのフォローは可能かと思う。

んー なんか要領を得ないレスになってしまった。
具体例が出せるなら出して欲しいかも。

# 「上記」「下記」は「前述」「後述」で書き換えればいいような気がするけど。

716 :Name_Not_Found:02/02/04 04:12 ID:3VR4UZ4w
>>709
HTML 4.01, XHTML 1.0, XHTML Basic 1.0
とかのことなんだよね。
(見たけどマジで分かんなかったんだよ。)

717 :Name_Not_Found:02/02/04 04:39 ID:dvUxE5Mg
>>708
深読みすると的を得た言葉かも。
StrictなHTML、っていう意味ならばTable使いまくりもStrict。
HTMLの古いバージョンはHTMLでレイアウトをする事を考えてたんだから。
少なくともtableもbも4.01trans.以前はvalidだった。

ここの住人の「Strict」は>>716のいう通りHTML4.01以降あたり、「文書の意味」を定義する事に主眼を置いた論理マークアップ。

>>715はそもそも画像を並べてるだけで「文書」を書いているわけではないのだから構造化文書の書き方を考えなくてもいいと思う。

ちなみに「赤いことに意味のある文字」の話はガイシュツと思ったが漏れの気のせいか?

718 :Name_Not_Found:02/02/04 05:16 ID:7uXjeKeB
bcokquoteのcite属性にいれるuriも

&は&にすべき?


719 :718:02/02/04 05:46 ID:E63rUQxZ
&は&amp;にすべき?
でした
あとhead属性のpriofile属性のuriは
相対uriでいいのでしょうか?


720 :Name_Not_Found:02/02/04 06:19 ID:RzvKw2qg
上記、下記ってのは構造上の前後関係を指し示すのにそのまま使えるかと。
必ずしも↑、↓って意味じゃないでしょう。縦書きの文章でも使うし。

721 :Name_Not_Found:02/02/04 06:28 ID:l7Gb+2RE
strictなページ作成を目指し、拡張子を消したのですが
.htaccessの設定がわからないっす・・
拡張子なしをhtmlファイルとして認識させるにはどうすればいいの?

722 :Name_Not_Found:02/02/04 07:17 ID:vo87KpQz
教えて君ですまないけど
AddType "text/html; charset=Shift_JIS" .html .htm

を拡張子なしにする場合はどうすればよいのでしょうか?
三毛猫とか見たけどちょっとわからなかったもので
どうか教えてくださいませ。


723 :Name_Not_Found:02/02/04 07:35 ID:plhxdopb
掲示板の "昔の10件" なんかを link 要素で書くときって
rel="prev"? それとも rel="next"?


724 :Name_Not_Found:02/02/04 07:41 ID:4WKc4VOs
>722
ディレクトリ示してるんだろ

725 :茶文字 ◆xELvisFU :02/02/04 08:24 ID:+3X132Ka
>>722
ForceType text/htmlぢゃないかしら?
ミケネコから拾ってきたんだけど。

726 :Name_Not_Found:02/02/04 08:33 ID:E31hZKdl
>>723
自分だったらNext。
分からなくなったらBookmarkに逃げる(ぉ

727 :Name_Not_Found:02/02/04 08:35 ID:plhxdopb
あ、bookmark の使いかたもよく理解らないんだった。
どう使うの?
まさにしおり的使いかた?

てか、しおりって読んでる人が使うもんだよね。
やっぱりよくわからないです。

728 : ◆HTML/.Kg :02/02/04 08:37 ID:4HxhsAC7
>>713
>正直、HTML はどんな文章でも表現出来るようにする
>方向に向ってると思ってたので。
方向としては全く違うことも無いだろうけど、
少なくとも現段階では無理だと思わざるを得ない。

>>717
ガイシュツだね。

>>718
HTMLのコード内では全てすべきかな、と。
>>719
特にかまわないと思う。

>>720
以前、「同じ行の直前で言っているのに、そのことを
上記と言っている文章」を見て違和感を覚えた。
前述後述のほうが安全な気はする。

>>723
revとrelの意味を知っておけばわかると思う。
ちなみにその場合はrel="prev"ね。

729 :Name_Not_Found:02/02/04 09:44 ID:4FtAaPUP
属性の構文について確認しておきましょうか。
HTML4.01での属性の書式は、大まかに三通りあります。

1. 属性名=属性値リテラル (例えば checked="checked")
2. 属性名=属性値 (例えば checked=checked)
3. 属性値 (例えば checked)

「属性値リテラル」というのは「置換可能文字データ」を引用符で括ったものです。
1.の書式の場合には、属性値リテラルから一般実体参照と文字参照を
展開した文字列が「属性値」としてアプリケーションに渡されます。

つまり、属性を「属性名=属性値リテラル」の書式で記述した場合、
リテラル内の"&"は一般実体参照の開始、"&#"は文字参照の開始
と見なされますから、文字データとしての"&"を記述したい場合には
"&amp;"などとしてやる必要があるわけです。

以下余談。属性値が名前文字以外のものを含む場合、
属性は常に属性値リテラルを用いて記述する必要があります。
"&"や";"は(HTMLでは)名前文字ではないので、
<a href=hoge.cgi&amp; >といった書式は禁じられています。

しかし、仮にSGML宣言をいじって"&"と";"を名前文字に含めたとすれば、
href=hoge.cgi&amp; の属性値は「hoge.cgi&amp;」(∵属性値として記述されている)
href="hoge.cgi&amp;" の属性値は「hoge.cgi&」(∵リテラルとして記述されている)
ということになるわけです。了。

730 :Name_Not_Found:02/02/04 11:03 ID:QZlARlMH
どうでもいいけど、2chは &amp;amp を &amp; に変換するから
&amp;amp; と入力すると ; が余分になるよ。

731 :Name_Not_Found:02/02/04 11:59 ID:4FtAaPUP
>>730
別に余分になってないけど。ブラウザがおかしいのでは?
ソース見てみれ。最近2chは基本的に&を全く変換していない。

"<"">"を変換してる以外は、"&ほげほげ"みたいな部分も
"&ほげほげ"のままで処理してる。

732 :Name_Not_Found:02/02/04 12:51 ID:TbjtC/kp
>>731
" くらいは処理して欲しいな。

733 :Name_Not_Found:02/02/04 13:06 ID:QZlARlMH
>731
IE他で見たら確かに変換してなかったわ。
かちゅ〜しゃが勝手にやってたのか…。

734 :Name_Not_Found:02/02/04 13:19 ID:4FtAaPUP
>>732
地の文でわざわざ&quot;にする必要はないと思われ。
というか、ほんとは">"もそのままで構わない。

735 :Name_Not_Found:02/02/04 14:17 ID:6Sg/jlDg
このスレ読んだ。勉強になった。

736 :722:02/02/04 15:00 ID:+Ml4wDi9
>>725
いや、それは拡張子なしのファイルをtext/htmlにするやつでしょ?
拡張子なしのファイルの文字コードをshift_jisにするには
どうしたらよいのかということなのです。
ForceType text/html; charset=shift_jis
でいいのかなあ

737 :茶文字 ◆xELvisFU :02/02/04 15:55 ID:+3X132Ka
>>736
HTTPヘッダをtext/htmlで出力するわけだから、それでいいような気がするんだけど。
人柱よろしく(w

738 :Name_Not_Found:02/02/04 17:15 ID:KCAZEIO7
>>734
いやいや、かちゅ〜しゃのスキンとかで
Javascriptを使いたい時にはそのほうが都合がいいものでして。

739 :Name_Not_Found:02/02/04 19:00 ID:X85riiXc
imgのheightとwidthってstrict?

740 :Name_Not_Found:02/02/04 19:03 ID:Q9wp7/mv
>>739
うん

741 :Name_Not_Found:02/02/04 19:07 ID:X85riiXc
ありがとう。

742 :Name_Not_Found:02/02/04 19:58 ID:M/KJtXtO
>>737
736でないけどやってみた。
文字化けはしない。でもさ。
どうせなくても文字化けしないんだから
あってるのかふぉうか不明。
ハトマルはどうやってるんだろ?

743 :Name_Not_Found:02/02/04 20:38 ID:+goe0A2j
>>739
精神的にはStrictでないかも。とりあえずISO-HTMLにwidth/heightはない。

>>742
utf-8とかの指定無しじゃまず化けるような(MacIE5だけか?)コードで試してみたら?
じゃなきゃmetaにわざと違うコードを指定して、生のヘッダの記述が優先されるか確認するとか。
的外れだったらスマソ。

744 :Name_Not_Found:02/02/04 20:49 ID:uA4PJcr6
>>742
単に拡張子じゃないの?

〜/html/hatomaru.html.ja.jis
〜/html/hatomaru.html.ja.sjis
〜/html/hatomaru.html.ja.utf-8

と云う風に。後はHTTPのAccept-Encodingヘッダで振り分ける。

745 :Name_Not_Found:02/02/04 20:51 ID:uA4PJcr6
Accept-EncodingじゃなくてAccept-Charsetだった、スマン。

746 :Name_Not_Found:02/02/04 20:59 ID:oj2U9BXa
>>742
Proxomitron 使ってれば Open Log Window で HTTP ヘッダ確認できるよ。

747 :Name_Not_Found:02/02/04 21:08 ID:foxq/7Xc
拡張子なしのファイルだとローカルの確認が面倒
html4.01ならいいけどxhtmlでかいたファイルは
ローカルで拡張子なしだとIEで見てもソースが見えるだけ
拡張子ありでいいよねえ。?


748 :Name_Not_Found:02/02/04 21:19 ID:fDbMIeMD
>>747
>>722はローカルでの確認なんか拘泥していないってことでしょ。
君には関係無いから別にそれでいいよ。

……つうか遡ってみると話がだんだんずれてるし。

749 :Name_Not_Found:02/02/04 21:21 ID:oj2U9BXa
>>742
あとネスケ 4.x (6.x ではダメ)で開いて
View - Page Info (表示−ページ情報だっけ?) とかやると、
文字セット指定がある場合はそれが表示される。


750 :サ骨 ◆/IQ5000w :02/02/04 21:25 ID:Mw3w/Asj
>>739
小さい画像にheightとwidth指定していると、
画像がロードされるまでAltが読めないというなかなか本末転倒な結果に。
今日久しぶりに体験した。

751 :Name_Not_Found:02/02/04 21:36 ID:g2GMjOlF
content negotiation を有効にしておけば、
.jis とか付いていたら charset=iso-2022-jp を付けたりする

しかし、.euc や .sjis はデフォルトでは提供されていないので
追加する必要があったような


752 :Name_Not_Found:02/02/04 21:37 ID:oj2U9BXa
>>750
画像ロード中に代替テキストが提供されてもいいような気は確かにするけど、
基本的に画像表示可能な環境に提供される必然性は無いような気がしないでもない。


753 :Name_Not_Found:02/02/04 21:52 ID:+goe0A2j
>>752
リンクが切れてることだってあるし、
ファイルが壊れてることだってあるじゃんよ。

754 :Name_Not_Found:02/02/04 22:09 ID:oj2U9BXa
>>753 なるほど。なんか解らなくなった。難しいね。

755 :726:02/02/04 23:20 ID:PEVCNk2R
>>728
古い方が必ずしも「前」とはいえないと思う。
掲示板のつくりにもよるけど、この場合は「次」だろうし。

756 : ◆HTML/.Kg :02/02/05 00:34 ID:ZTbv2MvE
>>755
掲示板がどう表示していようが、
時間の経過としてはほぼ間違いなく
「以前」に書いた文章だと思うので
「前述」かと思いますが、いかが。

>>753
代替テキストをどうレンダリングするかはブラウザの問題。
と言うより、その二つの例は著者のミスであって、
strictがどうこうという問題ではないと思う。

757 :Name_Not_Found:02/02/05 07:56 ID:OSru5rHT
>>756
時間としてじゃなく、全コンテンツをなめるように見せたいときの
リンクタイプはどういうのを指定したらいいでしょう?
うーむ。

758 :Name_Not_Found:02/02/05 12:24 ID:JJhfmVt+
そもそも掲示板にありがちな「次の10件」という書き方がおかしいと思うのだが。
普通に考えれば「前の10件」じゃないのかあれは。

759 :Name_Not_Found:02/02/05 12:41 ID:OSru5rHT
>>758
うんうん。
しかも時々"前の10件"が過去の10件を表わしてたりするサイトがあるからわかんなくなる。
"過去の10件" だと間違いないよね。

760 :Name_Not_Found:02/02/05 12:59 ID:JJhfmVt+
>"過去の10件" だと間違いないよね。

そうですね。これが一番。

>>755
ちなみに、リンクタイプはやはり時間順で「過去=prev」「未来=next」が良いと思います。
start/lastとの対応関係を考えたときにも矛盾がない。

761 : ◆HTML/.Kg :02/02/05 13:26 ID:ZTbv2MvE
>>757
あ、前述・後述の話か。スマソ。

でもどっちにしろ、「読む」順番ではない
基準にしないと、stricではなくなると思う。
「書き込み」順があるのだからそれに沿って
時間を基準にすればいいと思いますよ。(掲示板の場合)

>>759
前、だけだと何を基準にしてどちらに向いて
前なのかわからないしね。

762 : ◆HTML/.Kg :02/02/05 13:27 ID:ZTbv2MvE
>>761
×あ、前述・後述の話か。スマソ。
○あ、前述・後述の話じゃないのか。スマソ。

763 :茶文字 ◆xELvisFU :02/02/05 14:27 ID:O2g78Dy3
ツリー型の掲示板で新着レスがageになるやつだと、
必ずしも時系列でソートされているとは限らないのでは?

764 :Name_Not_Found:02/02/05 16:17 ID:JJhfmVt+
ツリー型のことを全く考えてませんでした。

ツリー型なら「次のページ=next」で良いか…。

765 :736:02/02/05 16:41 ID:UnJ95i8i
ForceType text/html; charset=shift_jis
でなく
ForceType "text/html; charset=shift_jis"
でした
"ぬけてました
お詫びして訂正いたします。

766 : ◆HTML/.Kg :02/02/05 19:29 ID:ZTbv2MvE
>>763
それでも各スレッドの最新の書き込み順
になっているのは変わりない。
2chみたいにスレッドに書き込みが
あるとが上がってくるという動作は、
その最新の書き込みの日時が基準だと思う。
それなら、その日時を基準にすべきかと。

767 :Name_Not_Found:02/02/05 21:06 ID:mmWy31m4
更新履歴の書き方について訊きたいんですけど。

02.05 なんたらかんたら
02.01 あんにゃもんにゃ
01.20 ちんたらまんたら
・・・

のように、日付と簡単な更新内容がペアになったものの場合、
どうマークアップすべきでしょう。
定義リストにしてしまっても良いのでしょうか。

768 :Name_Not_Found:02/02/05 21:13 ID:Fo4OwuJU
>>767
いいんじゃねーの。簡単な更新ない様(1行程度)ならulでもいいと思うな。
日付けと文章は:とかの記号で分ける。

769 :Name_Not_Found:02/02/05 21:45 ID:U870z6aS
dt {float:left;width:20%;}

<dl>
<dt>02.05</dt>
<dd>なんたらかんたら</dd>

<dt>02.01</dt>
<dd>あんにゃもんにゃ</dd>

<dt>01.20</dt>
<dd>ちんたらまんたら</dd>
</dl>



770 : :02/02/05 21:49 ID:mIlbF/Pc
>769
dt が 20% を超えたらみっともないことになりそうだが,
それ以上に dd が折り返したらもっとみっともないことになりそうな.

771 :769:02/02/05 21:53 ID:U870z6aS
>>770
いや、そこに突っ込まなくても...。
そこらは臨機応変にやってくれ。

772 :Name_Not_Found:02/02/05 22:12 ID:JJhfmVt+
ttp://www.remus.dti.ne.jp/~a-satomi/updatelog.html
こんな感じ?

773 :769:02/02/05 23:10 ID:QtoUhlnU
>>772
んで、
http://www.remus.dti.ne.jp/~a-satomi/nikki/2001/12b.html#d18n03
が、その説明。
とはいえ、%指定よりもemやexで指定しないとダメだね。

774 :Name_Not_Found:02/02/06 01:08 ID:zBeivlaZ
貼るの忘れてた。>>650辺り関連。ためになります。

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

775 :Name_Not_Found:02/02/06 05:18 ID:2/da8sY9
かんざきさんの日付の記事、反響大きいなあ。

776 :767:02/02/06 07:48 ID:3b/7yDoB
>>768-773
ありがとうございます。あの後ウトウトして、そのまま寝てしまいました。
マークアップはdlでいいとして、
floatで1行にする方法についてなんですが、
dtにclearも指定しといた方がいいですよね?
dtボックスの方が高くなるケースを考えると。

>>774
ためになりました。

777 :Name_Not_Found:02/02/06 09:33 ID:TQcnlWMq
>>769
これ追加しておいて。
dd {margin-left:21%;}

778 :Name_Not_Found:02/02/06 10:57 ID:l2Kk1jNH
dtが折り返されたら最悪なんで
white-space:nowrapもいるかも。

779 :Name_Not_Found:02/02/06 15:34 ID:Jg5ottqr
   dtにブロック入れたいよー

780 :769:02/02/06 15:40 ID:0q8RoBkp
>>777
あ、見逃してました。スマソ。

>>778
うーん、無理に踏ん張ると、
フォントサイズとかletter-spacingをユーザースタイルシートで弄られた時に
右のdd要素と重なる危険があるので、ちょっとビミョー。

んで、折り返される事を前提に考えると、
>>776の<q>dtにclearも指定</q>が要ると。

781 : :02/02/06 15:57 ID:1ttwLokD
strictっての最近知ったんですが画像のwidthやheight
なんかもCSSで指定するのですか?

782 :Name_Not_Found:02/02/06 17:04 ID:kBMwzF41
>>781
% 使ってる場合は CSS で代用出来ないよ。
属性の width="50%" と CSS の width: 50%; は意味が違う。

783 :Name_Not_Found:02/02/06 17:13 ID:BUpnUvD/
>>749
IE使ってる?
なら、詳細設定の「常にイメージの ALT テキストを展開する」にチェック。

784 :Name_Not_Found:02/02/06 18:53 ID:AbP2ur0Q
>781
別にHTMLでも桶

785 :Name_Not_Found:02/02/06 20:56 ID:D4yHlAxO
brいやだから
img{display:block}として強制改行しているが
これはダメ?strictでない?

786 :Name_Not_Found:02/02/06 21:01 ID:0q8RoBkp
>>785
<p><img src="foo.png" alt="bar"></p>
とすべきかと。

787 :Name_Not_Found:02/02/06 21:01 ID:C3A5L5qS
>>785
良い。displayの値はHTMLとは無関係というのは定説。
img表示されない時(altが表示されるとき)にも改行されるけどね。

788 :785:02/02/06 21:11 ID:D4yHlAxO
>>786
もちろん普通のところはそうしている
問題はhnだ

<h1><img src="hoge.png" alt="hoge">閃光のw3c信者</h1>
みたいな場合にpを入れれないから困っていたのです。

789 :786:02/02/06 21:22 ID:0q8RoBkp
>>788
ああ、なるほど。失礼しました。それならばその通りです。

790 :Name_Not_Found:02/02/06 21:27 ID:l2Kk1jNH
>>786
話はずれるんだけど、
何でもかんでもpにしちゃうのはやっぱりおかしいと思うけど。

特に、「挿し絵」に段落としての意味は無いし。

791 :Name_Not_Found:02/02/06 21:29 ID:AyLAOKSK
ちょっとみなさんのご意見を伺いたいのですが

現在XHTML1.1+CSSでサイト作ってます。
その中に詩のページ(1ページにひとつずつ)がいくつかあるんですが、
詩には特にタイトルつけていないので見出しをどうするか悩んでます。
#敢えてつけるとしたら番号くらい。

hn要素がなくていきなり<p>から始まるのってどうなんでしょう?

792 :Name_Not_Found:02/02/06 21:36 ID:toChxyfk
>>791
文法上は問題無いけれど、読み手としてはやはり見出しが欲しい。
<h2>作品番号:2</h2>とかそんなのでもいいからさ。

793 :Name_Not_Found:02/02/06 21:36 ID:koi2OCZD
>>791

例え話をしようか。アナタが持ってるCDとかの歌詞カード見てみろ。
果たしてタイトルの無い詩があるだろうか。

自分で書いた詩なら、タイトルくらいどうにかして付けてやれよ。
『無題』でも立派な見出しになるよ。信者ではなく、1ポエマーとして
忠告。

794 :ぷろぢゅ−さー:02/02/06 21:37 ID:e9IMCW13
ベンチャーの項目で一緒にベンチャー企業建てましょうという
スレッドたているものです
今回私主催でOFF会をすることとなりました 宣伝させてください
何かやってる人 これからやろうとしている方の会です
■■■告知■■■
2月10日日曜日緊急OFF
集合 PM6:00新宿アルタ口の広場(人の集まり具合によりいくところ決めます)
参加費 全額割り勘でやります 

参加希望の方は私まで●お名前●簡単な自己紹介など簡単なPRと連絡先下さい
参加状況はそのつど報告します。

以上です
よろしければ私のスレッドにも遊びにきてください
失礼致します





795 :Name_Not_Found:02/02/06 21:40 ID:C3A5L5qS
>>791
というか、title要素はどうしてるの?

796 :Name_Not_Found:02/02/06 21:48 ID:0q8RoBkp
>>790
挿し絵の種類にもよるだろうけれど、<p>で囲むとマズい様な挿し絵を
HTMLで表示して良いものかどうかが疑問。

従って、CSSのcontentプロパティで表示させるのが正しい様な。
ま、あまり現実的じゃないか。

797 :Name_Not_Found:02/02/06 22:11 ID:AyLAOKSK
>>792
やっぱり何かあったほうがいいですか。

>>793
>果たしてタイトルの無い詩があるだろうか。
確かにそうなんですけど、
タイトルつけちゃうと読む人が「そういう先入観」を持って読んでしまうのではないか
と思ってわざとつけなかったんです。
先入観のない状態で読んで欲しいな、と。

>>795
titleにはとりあえず番号を入れてます。
本文にも番号を表示するとくどいかな〜と。

798 :791:02/02/06 22:11 ID:AyLAOKSK
すみません。
797=791でした。

799 : ◆HTML/.Kg :02/02/06 22:32 ID:6iDnu1d/
>>797
どうしてもタイトルつけたくなければ、
作品を羅列するだけ、ということで、
<ul>
<li><p>作品1</p></li>
<li><p>作品2</p></li>

<li><p>作品10</p></li>
</ul>
ってな感じでどうだろう。
ただ、やっぱりhnをつけた方がいいとは思う。
# でないと、あなたが伝えたいメッセージが薄れる、
# という話はHTMLと関係ないのでやめときます・・・。

800 :gooによると:02/02/06 22:35 ID:tSTsjgfX
par・a・graph  
 
n. (文章の)節, 段落; 段落標, パラグラフ記号 ((¶)); (新聞の,見出しのない)短評. 
− vt. 文節に区切る; (ニュースなどを)短い(新聞)記事に書く. 
paragrapher 
n. 雑報記者. 
paragraphic 
a. 段落の; 段落を構成する; 小記事の. 
paragraph assembly 
【コンピユータ】 パラグラフアセンブリ. 
paragraph indention 
【コンピユータ】 段落インデント. 

なので、見出しの無いのにもpつかっていいのではなかろうかと。



801 :Name_Not_Found:02/02/06 22:39 ID:cwZWrF4D
>>797
見出し無くてもいいと思うぞ。
和歌とかは題名なんか無いし、クラシック音楽だって
「○○交響曲第×番」「練習曲△番」みたいなの多いじゃん。

どうしても、って場合は
俺だったら詩の一行目を見出しにするかな。

802 :Name_Not_Found:02/02/06 23:05 ID:uCaus3qa
>>801
それっておしゃれじゃん?<一行目見出し

803 :790:02/02/06 23:12 ID:l2Kk1jNH
>>796
それ言い出すとそもそもobject(のファミリー)
がある事自体がおかしいって話になると思う。
「表示環境に左右される挿し絵」

「表示環境に左右されない挿し絵」
ってのもあると思うし。

804 :796:02/02/06 23:50 ID:0q8RoBkp
>>803

というか、「表示環境に左右されない」 程、
重要な挿し絵だというのならば、
<p>で囲うか、リンクを貼るべきかと思うが…。

805 :791=797:02/02/07 00:32 ID:JtIcMUMI
まとめると
「文法上は間違いじゃないけど見出しがあったほうがわかりやすい」
ってことでしょうか。
文法上というか、HTMLとしてどうなのかちょっと心配だったので
間違いではないとわかっただけでもありがたいです。

>>801さんの「一行目を見出しに」も面白いですね。
これから見出しを入れる方向に行った場合は参考にさせて貰います。

>>799さん
># でないと、あなたが伝えたいメッセージが薄れる、
># という話はHTMLと関係ないのでやめときます・・・。
仰るとおりここではスレ違いですが、ありがたく受け取っておきます。

微妙にHTMLと関係ない方向にいってしまってすみません。
みなさんありがとうございました。

806 :Name_Not_Found:02/02/07 01:02 ID:dVOpUVzm
Strictスレ的には、無粋でも見出しを設定するのがスジなんだよね?
それがダサくて嫌なら、CSSでdisplay:noneしてしまえばいいんだし。


807 :Name_Not_Found:02/02/07 01:08 ID:ZI69+/fb
ぶっちゃけ、display:noneするくらいなら書かなくても良いと思う。

そもそも詩をHTMLでマークすること自体が若干あれなので、
見出しが無いなら無いでも構わないと思うよ。

808 :Name_Not_Found:02/02/07 01:34 ID:aoVfn5jX
そうそう某所書かれていたけど
hmlは学術的なことをかくんでしょ?
詩でもさ
     
 <h2>詩と歴史</h2>

みたいな硬い文章にはむいてるけど、詩を純粋に楽しむ
文章にはむいてないよね。

809 :茶文字 ◆xELvisFU :02/02/07 02:38 ID:ldspMp0s
>>808
別に楽しむ目的でなくても、学術的に詩を扱うことはありえるわけで。
たとえば批評であったり。
ただ、詩そのものをマークアップしにくいという面は同感だけど。

つか、なにげにこのスレってポエーマー多い?
いや、私がそうだといいたいわけではないんですが。
って違うともいいませんけど(w

810 :Name_Not_Found:02/02/07 03:44 ID:ZI69+/fb
詩人はポエーマーではなくpoetであると思われ。
言葉遣いもStrictにしてくれよママン!

などとマジレスしてみるテスト。

811 :Name_Not_Found:02/02/07 04:41 ID:GFuwxakq
質問です。
ストリクターになるための早道はどうしたらいいですか?
やはり英語の規格書を丹念に読むしかないのでしょうか。

812 :Name_Not_Found:02/02/07 05:11 ID:xCNPfJZO
>>811
lintで100点目指す。本末転倒であるが、てっとり早い。
あとはブロック要素とインライン要素の違いの理解を深めること。
そうすれば自然とCSSの理解も深まる。
あとは文章書くときに構造化を心がけること。
まあDTD読めるようになれば、あとは自分でなんでも解決できるけど。

とか偉そうなこと言いましたけど、突込み入れて下さい。有識者の方々。

813 :Name_Not_Found:02/02/07 05:16 ID:ZI69+/fb
>>811
論理マークアップの概念を理解できてるなら、lintで100点で良いと思う。
「こんな感じの要素無いかな?」と思ったら鳩丸あたりのリファレンスを眺める。

814 :Name_Not_Found:02/02/07 06:45 ID:twVBBt6W
blockquoteにuriでなく書籍からの引用の場合
どうすりゃいいんだい?
<blockquote cite="urn:isbn-0000-90000">でいいん?

815 :茶文字 ◆xELvisFU :02/02/07 07:01 ID:ldspMp0s
ISBNコードってURIとちゃうん?
URI = URL + URN と理解してたんですが。

816 :Name_Not_Found:02/02/07 07:10 ID:soVnGbyb
記述的にはどうすればいいでしょう?


817 :Name_Not_Found:02/02/07 07:21 ID:ZI69+/fb
cite="urn:ISBN:4-04-010801-9"って感じ。

818 :Name_Not_Found:02/02/07 07:31 ID:ZI69+/fb
便乗質問。RFCの例では"URN:ISBN:"って感じで、urnもisbnも大文字で書いてるんだけど、
スキーム名の大文字小文字って区別無いの?
某方面では"urn:isbn:"みたいに小文字で書いてる人が多かった気がするんだけど。

819 :Name_Not_Found:02/02/07 07:44 ID:RS08B2fM
>>818
RFC 3187ですよね。私も、その箇所は気になってました。

http://openlab.ring.gr.jp/k16/htmllint/explain.html#upper-protocol
によれば、スキーム名は小文字でないとダメとのこと。最も、大文字を小文字とみなすような融通を利かしてもよいとは
書いてありますけど。

http://www.kanzaki.com/docs/html/urn.html#rfc-urn
によれば、名前空間識別子(この場合はISBN)は“大小文字を区別しません”とのこと。

と云うことで、"urn:"は小文字、"isbn:"はどちらでも構わない……が正解かと思います。
私は、書くとするなら両方とも小文字ですね。ISBNだけ大文字と云うのも、今一つバランスが悪いように思いますので。

820 :Name_Not_Found:02/02/07 07:48 ID:OYAsUxRO
本をblockquoteするときはちとこまる
だってh1とかdlとかでマークアップせなあかんだろうし
あと一部抜粋でもblockquoteでいいのですか?


821 :Name_Not_Found:02/02/07 07:53 ID:OYAsUxRO
>>817
ありがとうございます。

822 :Name_Not_Found:02/02/07 08:04 ID:ZI69+/fb
>>819
おお、サンクス。

>スキーム名は小文字でないとダメとのこと。

そうそう、どこかでそう書いてあった気がしたからurnは小文字にしたんだけど、"ISBN"はどっちでもいいのか。
漏れも小文字だけの方が(見た目)好きだから、urn:ISBN:ってのはちょっとやだなと思ってた。
すっきりしました。

823 :Name_Not_Found:02/02/07 08:11 ID:ZI69+/fb
追記。RFC2141に

<URN> ::= "urn:" <NID> ":" <NSS>

と書いてあるので、小文字が正しいようですね。

824 :Name_Not_Found:02/02/07 09:35 ID:5c0EpT9R
>>820
ああ、いわれてみればそうだね。
引用部分は html のフルセットを包括出来ないと困るのか....

ところで、dl にも caption 要素欲しいと思いません?
以前 ul に caption は dl で代用すべしってのがあったけど、

<dl>
<dt>AA読み方辞典</dt>
<dd>
<dl>
<dt>(゚Д゚)ゴルァ</dt>
<dd>ゴルァ</dd>
<dt>(゚Д゚)ハァ?</dt>
<dd>ハァ?</dd>
....
</dl>
</dd>
</dl>

ってのはさすがに冗長すぎないかと。

825 :Name_Not_Found:02/02/07 11:32 ID:soVnGbyb
urn書いたら
lintで
こんなのないよーって言われた
どうするべ。

826 :825:02/02/07 11:36 ID:soVnGbyb
すいません
あってました・・。

827 :Name_Not_Found:02/02/07 12:14 ID:5c0EpT9R
class 属性で擬似的に意味付けしてる場合、

<div class="notice">
<div class="recruit">
<p>雪○乳業社員急募</p>
<p>来たれ将来のある若者達よ</p>
</div>
</div>

ってのと、

<div class="notice recruit">
<p>雪○乳業社員急募</p>
<p>来たれ将来のある若者達よ</p>
</div>

のどっちが美しいでしょうね。


828 : ◆HTML/.Kg :02/02/07 12:18 ID:VOXTlvKe
>>824
その場合、
<hn>AA読み方辞典</hn>
でいいのではないでしょうか。

829 : ◆HTML/.Kg :02/02/07 12:20 ID:VOXTlvKe
>>827
後者でいいような。
divで区分してからclassをつけるというようなつもりで。

830 :Name_Not_Found:02/02/07 12:23 ID:5c0EpT9R
>>828
うーん、例が悪かった。

現在の h* って結合度が薄いですよね。
だから、例えば css 使ってキャプションを下に持ってったりとか、
音声ブラウザに今読んでる定義リストのタイトルは?みたいに問いあわせるとき
不便かなと思って。

それと、キャプションとヘッダの意味するところって違くないですか?
キャプションは(写真・挿絵の)説明的見出しって位置付けで解釈してました。



831 :Name_Not_Found:02/02/07 12:30 ID:Swc35f4v
ISOならそんな心配もご無用

832 :Name_Not_Found:02/02/07 12:56 ID:5c0EpT9R
>>831
どのように御無用か教えてくれえ。
ISO はきっついってイメージしかないからよくわからんのです。

833 :Name_Not_Found:02/02/07 13:02 ID:FSPDsE/9
>>831
div*なんて使ってるヤツ見たこと無いぞ。

834 :Name_Not_Found:02/02/07 13:03 ID:o3fqlulb
>>833
ISO-HTMLを勘違いしているのでは?

835 :Name_Not_Found:02/02/07 13:09 ID:Kopy8Rm7
>>833
それは検証用のPreparation of ISO-HTMLでしょ。

836 :833:02/02/07 13:12 ID:FSPDsE/9
うむ、勘違い。
じゃあ、>>831はどう心配ご無用なのだろうか?

837 :Name_Not_Found:02/02/07 15:08 ID:NibJDQfq
>>824さんのに似た感じなんですが、こういう場合はどうすればもっと綺麗になるでしょう?

<dl>
<dt>会社名</dt>
<dd>雪○乳業</dd>
<dt>所在地</dt>
<dd>
<dl>
<dt>本社</dt>
<dd>札幌?</dd>
</dl>
</dd>
<dd>
<dl>
<dt>東京支社</dt>
<dd>東京のどっか</dd>
</dl>
</dd>
</dl>

838 :Name_Not_Found:02/02/07 15:16 ID:FSPDsE/9
>>837

<dl>
<dt>会社名</dt>
<dd>雪○乳業</dd>
<dt>所在地</dt>
<dd>
<dt>本社</dt>
<dd>札幌?</dd>
<dt>東京支社</dt>
<dd>東京のどっか</dd>
</dd>
</dl>

で、いいんじゃないの?

839 :838:02/02/07 15:18 ID:FSPDsE/9
あ、凡ミス。
<dl>
<dt>会社名</dt>
<dd>雪○乳業</dd>
<dt>所在地</dt>
<dd>
<dl>
<dt>本社</dt>
<dd>札幌?</dd>
<dt>東京支社</dt>
<dd>東京のどっか</dd>
</dl>
</dd>
</dl>
だな。

840 :Name_Not_Found:02/02/07 15:26 ID:UTOZutvK
>>838
dl でこういう省略許してくれたらどんなにいいだろうかと思った。

841 :Name_Not_Found:02/02/07 18:15 ID:NibJDQfq
>>839
あ、そうですね。こっちの方がすっきりしてますね。
ありがとうございます。
あぁ、入れ子にすると複雑になるから嫌なんだよなぁ。(;´Д`)

842 :823:02/02/07 22:55 ID:q0cmGqhM
スマソ。urn:は大文字でもいいみたい。

> スキームurn:は厳密には小文字で定義されているものですが、RFC 2396では、
>> "For resiliency, programs interpreting URI should treat upper case
>> letters as equivalent to lower case in scheme names"
> と、大小文字を区別せずに扱うよう定めています。
> RFC 2141ではもっとシンプルに、
>> "The leading "urn:" sequence is case-insensitive."
> としています。

とのこと。

843 :茶文字 ◆xELvisFU :02/02/07 23:27 ID:ldspMp0s
そういえばlink要素のrel/rev属性の値(indexとかalternateとか)の頭文字を
大文字にして説明している書籍やサイトが多いけど、あれはどうなん?

844 :Name_Not_Found:02/02/07 23:32 ID:q0cmGqhM
>>843
大文字小文字は区別しません。ちなみに仕様書では頭文字を大文字にしてる。
http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links

845 :Name_Not_Found:02/02/07 23:34 ID:q0cmGqhM
上の仕様書の

> These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".

の箇所ね。念のため。

846 : ◆HTML/.Kg :02/02/08 00:50 ID:ZtUJP/oT
>>837-839
なんとなくtableっぽい匂いがしないでもないような。

847 :茶文字 ◆xELvisFU :02/02/08 01:18 ID:G478W9oB
>>844-855
レスさんきぅ。
とりあえず総合的に考えて文書型宣言以外は全部小文字ってのが無難ぽいですなぁ。

848 :819:02/02/08 01:19 ID:9KblUHLO
>>842(>>823)
あらら、わざわざどうもすみません。
適当なこと書いて申し訳ない……。

849 :Name_Not_Found:02/02/08 03:20 ID:s1mkrYaZ
>>847
metaのcontentなんかは大文字小文字区別するし、
name="Robots"の時の"NOINDEX"とかは大文字じゃなきゃ多分駄目だったりする。
一々確認しなさいってこった。
http://openlab.ring.gr.jp/k16/htmllint/explain.html#robots-content

850 :842:02/02/08 03:24 ID:s1mkrYaZ
>>848
礼は神崎さんに(汁

851 :811:02/02/08 04:54 ID:FKOThF9l
>>812-813
ありがとうございます。これからはlint+鳩丸で勉強しながら
このスレについていけるようにやってみます。

852 :Name_Not_Found:02/02/08 08:15 ID:ruDRBZI2
>>849
ここで話題にしているのはcontent属性ではなく、rel/rev属性でしょ?

853 :837:02/02/08 08:27 ID:Wr98dv4Y
>>846
こういう場合は、tableの方が適してるんですかね。
うーんtableって手を出しにくいからなぁ。使いどころ難しいし。

854 :茶文字 ◆xELvisFU :02/02/08 09:18 ID:G478W9oB
>>849
contentの中身はCDATA(RCDATA?)だから、条件によるよね。
URLの大文字と小文字を区別するサーバに渡すのに、content="HTTP://WWW.2CH.NET/"では
たしかにまずい。

しかし、http-equivではなくmetaを指定した場合の扱いは原則UA任せのはずでは?
# つーか、UAからデータを受け取るサーバ任せか?

んで、HTML4以降はrobotのcontentについて、特に指定しなくなったと記憶しているのだが。
W3Cの記述もちょっと覗いたが、lower/upperという記述は発見できなかったし。

現実に小文字の[no]indexや[no]followをロボットが解釈するかは別にして、
そのへんどうなの?>>849およびall

# DTD的には大文字小文字を区別しなくてもロボットが区別するってのはあり得る話だが、
# それはロボットがStrictではないという結論にしかならない。

855 :Name_Not_Found:02/02/08 09:34 ID:/26iXuOV
>>854
はい、>>849のリンク先にもある通り、HTML 4.0 までは"case sensitive"って記述が
あるんですが、HTML 4.01 ではこの記述は消えています。この辺が"多分"と書いた理由。
まあ大文字にしておく方が無難ではあると思います。

># DTD的には大文字小文字を区別しなくてもロボットが区別するってのはあり得る話だが、
># それはロボットがStrictではないという結論にしかならない。

というか、DTDにはnamecaseを指定するような機構がないので、
(モジュールXHTMLみたいに記法宣言書けば別だけど、どのみちSGMLの範囲を超える)
勧告の記述にStrictな挙動をし得るのはDTDに忠実なパーザより
むしろ勧告に忠実なロボットの方と思われ。

856 :Name_Not_Found:02/02/08 10:13 ID:AWzJnY6j
>>855
まあ、区別されるかされないかどうかは
name/http-equiv 属性の値に依存するとかそんなところでしょうね。

ロボット的には区別しないことになってるような気がします。
http://www.robotstxt.org/wc/meta-user.html


857 :Name_Not_Found:02/02/08 11:02 ID:iKe2hUT9
そう言えば、何でmeta要素型のname属性はCase-Sensitiveなんだろう。
区別が必要な時ってあるのか?

858 :838:02/02/08 12:05 ID:0DOF9C2x
>>853

むしろ、
<h*>会社名</h*>
<ol>
<li><a href="snow.html">雪○乳業</a></li>
<li>他の会社</li>
</ol>
とでもして、
snow.htmlで
<h1>雪○乳業</h1>
<dl>
<dt>本社</dt>
<dd>札幌?</dd>
<dt>東京支社</dt>
<dd>東京のどっか</dd>
</dl>
とするのがいいかな、と。

859 :茶文字 ◆xELvisFU :02/02/08 17:32 ID:G478W9oB
>>855-856
なるほど、よくわかりました。
現状を考えると大文字でも小文字でもDTDに違反するわけではないから、
現状に見合う方を書いておけばStrictではあるわけですな。

860 :Name_Not_Found:02/02/09 04:55 ID:ou9/plBw
pがbr2個分だっていうサイト作成マニュアル本は本当にあったの?

861 :Name_Not_Found:02/02/09 10:14 ID:t5adNMFf
そりゃあもう雨後の竹の子のように。

862 :Name_Not_Found:02/02/09 11:20 ID:8BhScEBj
>>860
今更それ聞いてどうする気だ?

863 :860:02/02/09 15:38 ID:VDcBtnJY
>>862
最初に言い出だした先生をただ興味本位で知りたいだけっす。



864 : ◆kDDK6ugk :02/02/09 15:45 ID:QFzaSnyK
『アンク著 HTMLタグ辞典』がそんな記述をしてたよーな気もする。

865 :Name_Not_Found:02/02/09 17:04 ID:vM2BMRuO
>>864
<P>は「改行されて、さらに一行あきます」だそうです


866 :j君:02/02/09 17:04 ID:EEFTc9QZ
私の家にdt要素は単独で使うと改行が入る
というありがたい本があります。



867 :Name_Not_Found:02/02/09 17:24 ID:48Dtka+q
DDが単独ではインデントってのならある

868 :Name_Not_Found:02/02/09 18:36 ID:+crQiQ4H
>『アンク著 HTMLタグ辞典』
手元にある古いのを見たら、<P>を行末につけてるね(笑)。
けど今店頭にある最新版は、かなり仕様に忠実っぽかった気が。

869 :Name_Not_Found:02/02/09 18:42 ID:48Dtka+q
>>868
ここの板の住人の誰かが文句言ったのかな?

870 :Name_Not_Found:02/02/09 19:47 ID:WWuPYLfR
>>869
そりゃあもう雨後の竹の子のように。

871 :茶文字 ◆xELvisFU :02/02/09 20:14 ID:9FLbQn5q
アンクのスタイルシート辞典なるものが手元にあるけど、これは結構使える。
ただま、プロパティーの書式確認くらいにしか使ってないから、
Strictか否かは普段気にしてないので何とも言えないが。
つか、古い版だしなぁ。

872 :Name_Not_Found:02/02/10 01:26 ID:dbvKDX0o
>>820
遅レスだけど、見出しごと引用するようなケースは
著作権法で定められている正当な引用を逸脱してしまうと思われ。

念のため言っとくけど「転載」は引用とは違うYO!

873 :Name_Not_Found:02/02/10 02:14 ID:ZA2NHU33
>>872
話をそっちへ持っていくとスレ違い甚だしい。


874 :Name_Not_Found:02/02/10 02:43 ID:dbvKDX0o
>>873
転載ならblockquoteは違うだろというstrict的見解です

875 :Name_Not_Found:02/02/10 05:37 ID:rHRyFupf
>>872
ならq要素だけでいいじゃん

876 :Name_Not_Found:02/02/10 19:32 ID:vPYUOoBI
>>875
複数段落にわたる引用やリストごとの引用がある。

877 :Name_Not_Found:02/02/11 06:19 ID:uTZKHlgA
質問です。
<address>にはどこまで書いていいのか教えてください。
著作権表示と最終更新日以外に、トップページへの
リンクを含めても大丈夫なのでしょうか?

878 :Name_Not_Found:02/02/11 07:20 ID:JwifnF5R
>>877
好きずきだろうね。漏れは著作権しか書いてないけど。

トップページへのリンクを含めると
他のコンテンツへのリンクも書きたくなったときに困ることもあると思う。
(addressにはリストを入れられないから)

879 :茶文字 ◆xELvisFU :02/02/11 20:18 ID:abFaCIJ1
>>877
自作CGIの末尾に著作権表記とともにページトップへのリンクを書いてある。
その部分にトップへのリンクとmailto:が併記されているのはよいと思われ。
でも、まともにナビゲーションができてるページなら不必要な気もする。
それは「くどい」という次元の話で、Strictかどうかではなく、ね。

880 :Name_Not_Found:02/02/11 21:47 ID:Y0XL3qog
ちなみにOperaには、DD要素がaddress要素を直かに子要素とできないって
とんでもないバグがある。<dd><address>〜</address></dd>が消えてしまふ……
cf.http://sigekazu.vis.ne.jp/cgi/bbs/sylpheed.cgi?c=r&n=273

881 :00:02/02/12 23:00 ID:ggx0R3IU
そういやdtにメルアドいれたいんだが
どうすればいい?
addressなしでメアドいれてもいいかなあ?

882 :Name_Not_Found:02/02/12 23:09 ID:Pm/hSzms
ddには何を書くんだい?

883 :Name_Not_Found:02/02/12 23:11 ID:UF9B//fK
>>881
address 要素はその HTML 文書製作者への連絡先を記載する要素なので、
単にメアドを入れるだけなら address に入れる必要は全く無い。

仮に HTML 文書製作者以外のメアドなら寧ろ address にいれてはいけない。

884 :881:02/02/13 01:01 ID:9E/OjftO
<dt><a href="cgi-bin/read.cgi/">掲示板</a></dt>
<dd>なんか書いてにゃー</dd>
<dt><a href="mailto:hoge@foo.ne.jp">メール</a></dt>
<dd>メール入れてね♪</dd>
</dl>


・・知り合いのページを無理やりstrictにしているのだ
tableをdlにしたはいいが、どうもメールは変かなあ・・ここだけ
divるか。

これはよくジオとかで見かける

趣味
掲示板
メール
とかってとこのリンク集のソースね。

885 :9:02/02/13 01:10 ID:B2WXiksE

http://www.ktplan.ne.jp/rentcgi/freevote6/comvote.cgi?id=947323

886 :武蔵:02/02/13 01:10 ID:h076pBWO
>>884
趣味
掲示板
メール
って並べるのであれば、シンプルに<ul>でいいのでは。
それで、メールだけ<div>じゃ変でしょ。

887 :9:02/02/13 07:22 ID:B2WXiksE
ワールド・カップ優勝国は!
http://www.ktplan.ne.jp/rentcgi/freevote6/comvote.cgi?id=947323


888 :881:02/02/13 08:22 ID:EFw2z92/
ul liならaddressを突っ込めるか・・
そうしてみる。


889 :Name_Not_Found:02/02/13 09:38 ID:E1owB32g
>>884
てゆーか、テーブルが Strict じゃないと判断した理由が知りたい。

890 :Name_Not_Found:02/02/13 10:09 ID:IVp+zs8z
>>889に同意。
address要素としてマークアップしたいならtableの方が妥当。

891 :茶文字 ◆xELvisFU :02/02/13 10:14 ID:f31gA7v9
>>889
禿げ上がるほど同意。

たとえば
------+--------
製品名|国産牛肉
------+--------
生産者|逝印食品
------+--------
生産地|熊本阿蘇
------+--------
のようなものは表だから、ここでtableを使わずいつ使う?な感じ。
>>884もこれに類するものと考えられるので、tableを避ける理由がわからない。
ulならulでいいんだけれども。

892 :Name_Not_Found:02/02/13 12:44 ID:IVp+zs8z
>>891
いや、dt相当の要素がブロック要素を内包していなければ
定義リストで良いと思うけど。

------+--------
製品名|国産牛肉
------+--------
生産者|逝印食品
------+--------
生産地|熊本阿蘇
------+--------

も定義リストでも構わないだろう。
表の見た目が欲しいのなら、それこそ「見栄えはスタイルシートで」の世界。

893 :Name_Not_Found:02/02/13 12:57 ID:E1owB32g
>>891-892
えっと >>884 の場合
テーブルを使ってはならない理由も、
使わなければならない理由もないと思うんですけど。

どっちでも、まぁ妥当と言える(というか不当とは言い切れない)のに
わざわざtableをdlに書き換える理由、ってのを訊きたかったわけで。

まぁ、strict かぶれにありがちな
「レイアウトだけを目的とした、テーブルの使用はダメ」
って言うフレーズの後ろ半分しか目に入ってないだけ
なんだとは思いますが。

894 :Name_Not_Found:02/02/13 13:13 ID:4n+8yfqh
個人的には
縦横両方に見出しがあるケースならtable、
そうでなければdlって使い分けかな。

よって、>>891のケースはdlを使います。

あ、そうしろと言うわけじゃなくてよ。

895 :881:02/02/13 14:19 ID:m5aw4bNm
<tr><td><img src="icon.gif"></td><td><font size="+3">リンク</font>
<br>リンクだよー^^</td></tr>


てなのだもん・・・アイコン画像だけでtdいれるのはまずいやろ?

896 :881:02/02/13 14:26 ID:m5aw4bNm
こうゆうとこからstrict教を布教していくのだよ。
imgのborder消して、altいれて、centerタグけしてb要素をスタイルで太字にしたり
emやstrongにして、見出しの画像にh1入れて、br連打をmargin入れて。
ふと 俺って何しているの?と思うことあるけどね(ワラ

897 :Name_Not_Found:02/02/13 16:17 ID:EC9zuZ+q
>>895
全然現実的じゃないが、アイコン画像が全部違うような場合だったら
<thead><tr><th>アイコン</th><th>リンクと説明</th></tr></thead>
というアプローチもあったかも(w

898 :茶文字 ◆xELvisFU :02/02/13 18:54 ID:f31gA7v9
ぢゃ、次はStrictなtableの使い方・実践編でも議論します?

899 :Name_Not_Found:02/02/13 19:05 ID:IVp+zs8z
tableとは表である。表とは二次元の配列である。
HTMLでは、一次元の配列を ul または ol として、
二次元の配列を table または dl として表現する。
なお、三次元以上の配列を表現する要素型は、HTMLには存在しない。

ハイ次( ・∀・)ノ

900 : :02/02/13 19:13 ID:CA4ayerN
tableのaxis属性使えば3次元でも何とかなるような
使ったことないけど

901 :Name_Not_Found:02/02/13 19:24 ID:EC9zuZ+q
>>899
dl って 2 次元の配列かな?
table には行と列という概念が存在するけれど
dl にはそんな概念ないような気がする。

902 :Name_Not_Found:02/02/13 19:44 ID:EbGgTSBH
axisってなによ?ハトマル見たけど
理解できなかった。

903 : 900:02/02/13 19:56 ID:CA4ayerN
>902
まずaxisはtableの属性ではなくtdやthのだった.すまん.
で,神崎さんのところにいい説明があった(僕はそこを読んで何となく理解した).
ttp://www.kanzaki.com/docs/html/tbl-access.html

904 :899:02/02/13 20:09 ID:IVp+zs8z
>>900=903
うおお、そんなんあったのか。ビクーリ。
ttp://www.kanzaki.com/docs/html/tbl-access.html#axis ね。

>>901
それぞれのdtが「行」で、それぞれのddも「行」。
(dt+,dd+) というまとまりが「列」に相当すると思うけど。
dtとddの数が合わないときも、tableのセルの伸長と対応させて考えることができる。

905 :901:02/02/13 20:52 ID:EC9zuZ+q
>>904
table の td, th は、他の行の同じ列にある td, th と
それぞれ対応する明確な関係を持っている。
でも dl の dt, dd の場合は、
(dt+,dd+) でまとめられる dt と dd の間には対応関係があるけれども
他の dt, dd との関係は記述できないと思う。

906 :Name_Not_Found:02/02/13 21:01 ID:IVp+zs8z
>>905
全てのdtは「定義語」のグループで、全てのddは「説明」のグループ、とも見なせる。

<dl>
 <dt>もも</dt>
 <dd>果物。桃色。</dd>
 <dt>みかん</dt>
 <dd>果物。オレンジ色。</dd>
</dl>



<table>
 <tr><th>名前</th><th>説明</th></tr>
 <tr><td>もも</td><td>果物。桃色。</td></tr>
 <tr><td>みかん</td><td>果物。オレンジ色。</td></tr>
</table>

と大差ない。
もちろんtableにした場合には、「説明」の行が「名前」の行の説明になってる
なんてことは分からないが。

907 :905:02/02/13 21:24 ID:EC9zuZ+q
>>906
dt, dd が複数ある場合の例
3x3 以上の table と「大差ない」ような dl の例きぼんぬ。

908 :905:02/02/13 21:27 ID:EC9zuZ+q
dt,dd が複数って
<dl>
 <dt>もも</dt>
 <dt>peach</dt>
 <dd>果物。桃色。</dd>
 <dt>みかん</dt>
 <dd>ミカン科</dd>
 <dd>果物。オレンジ色。</dd>
</dl>
みたいな場合のことっす。

909 : :02/02/14 00:33 ID:eOkM1UoR
dt/ddが続くのって、>908だと
「peach」の定義は「果物。桃色。」だけど
「もも」の定義も「果物。桃色。」だとはいえないんじゃないか。
「もも」は「もも」で完結している。
 

910 :Name_Not_Found:02/02/14 00:49 ID:rLjmYJlc
お前ら<colgroup>をうまく使いましょうよ

911 :茶文字 ◆xELvisFU :02/02/14 02:37 ID:3Ups3hF3
dlの方が一般にtableよりもソースの可読性が高いように感じる。
たまたま今日、>>884のような例で初心者から相談を受けたのだが、
自分で修正するのが容易なように、tableではなくdlを使うよう助言した。
確かに多次元の参照が必要な場合はtableの優位性は確実なのだが、
考えてみると表である必然性って思いの外ないものがほとんどなのだねぇ。

>>910
colgroupを効果的に使った例を挙げてもらえると恐悦至極。
普段table自体あまり使わないんで、tableを使ってどこまでステキなソースが書けるか
非常に興味があるんだ。

あと、>>900で衝撃が走ったaxisとかheadersを使った魅力的な例もどなたかキボーン。
いいソース見せてくれたら、当分tableにはまるかも(・∀・)

912 :Name_Not_Found:02/02/14 07:33 ID:jrfiMLJR
>>909
908 の例は
http://www.w3.org/TR/html4/struct/lists.html#h-10.3
の 2 つ目の例と同じだと思う。

913 :Name_Not_Found:02/02/14 10:32 ID:jrfiMLJR
<tr><td>データ1-1 <td>データ1-2 <td>データ1-3
<tr><td>データ2-1 <td>データ2-2 <td>データ2-3

の「データ1-3」「データ2-3」は同じ列のデータだけれど

<dt>見出し1 <dd>説明1-1 <dd>説明1-2
<dt>見出し2 <dd>説明2-1 <dd>説明2-2

の「説明1-2」「説明2-2」は同じ列のデータである必然性がない。
逆に言えば、同じ列のデータであるということを示唆することが出来ない。

td は tr 内での出現順序が列の位置を表す重要性を持っているけど
dd の場合はそれが該当する dt の説明であるというだけで
出現順序は特別な意味を持たない。
そういう意味で、基本的に table と dl はデータ構造が違うだろ、と思う。

914 :Name_Not_Found:02/02/14 14:03 ID:S7QIJqte
>>907-908
>>904
>dtとddの数が合わないときも、tableのセルの伸長と対応させて考えることができる。
って書いたように、

<table border>
 <tr><td>もも</td><td>果物。桃色。</td><td>peach</td></tr>
 <tr><td>みかん</td><td colspan="2">果物。オレンジ色。</td></tr>
</table>

と対応させて考えられるでしょ。

>そういう意味で、基本的に table と dl はデータ構造が違うだろ、と思う。
それは勿論そうです。

915 :sage:02/02/14 14:34 ID:Agyd/OHJ
>>914
> <tr><td>みかん</td><td colspan="2">果物。オレンジ色。</td></tr>

<tr><td>みかん</td><td>果物。オレンジ色。</td><td></td></tr>
が正しいと思います。

916 :Name_Not_Found:02/02/14 14:58 ID:jrfiMLJR
>>914
なんか論点が噛み合ってない感触。

俺が言いたいのは
「 dl は各 dt, dd に順序の概念がないから、dl では2次元配列の表現はできない」
ということで、 >>899
> 二次元の配列を table または dl として表現する。
への反論なんだけど、 914 氏の主張って
「 dt, dd をテーブルのセルに対応させて dl で2次元配列を表現可能」
ってことなの?

うーん、そういう「対応」だったら div でも span でもできそうな気がするんだが。

917 :Name_Not_Found:02/02/14 15:03 ID:44CD172B
>「 dt, dd をテーブルのセルに対応させて dl で2次元配列を表現可能」
こうなってくると、Strict の意味を違えてきてるんじゃないかって気がしてくるよ。

918 :茶文字 ◆xELvisFU :02/02/14 15:54 ID:WMDi8WmR
<dl>
 <dt>定義語1</dt>
  <dd>データ1</dd>
  <dd>データ2</dd>
 <dt>定義語2</dt>
  <dd>データ3</dd>
  <dd>データ4</dd>
</dl>

上記のようなマークアップの場合、たとえばデータ1とデータ3、データ2とデータ4の
相関関係をマークアップとして見いだすことができない。
これは二次元配列と呼ぶべきではない。
つまり、たとえばデータ1とデータ2の順序が入れ替わってデータ3とデータ4がそのままでも
文脈上問題が生じない状態で用いられるべき。

919 :茶文字 ◆xELvisFU :02/02/14 16:05 ID:WMDi8WmR
連レススマソ。

tableにおいては、trやcolgroup、tbodyなどによって各tdの位置づけが明確化される。
たとえば複数のtbody、複数のtrがあってもtdがどれに属するかは自明である。
dlにおいては、各dtはddと対応しているように見受けられるが、
これはパーサが「ソースを左上から右下に向かって解釈する」からであって、
必ずしも対応しているとは限らない。

例)
<dl>
  <dd>データ0</dd>
 <dt>定義1</dt>
  <dd>データ1</dd>
 <dt>定義2</dt>
 <dt>定義3</dt>
</dl>
上記のマークアップはStrictである。

tableではtrを省略してもUAが補ってくれることがあるだろうが、それはあくまでバグ補正だと思う。
これに対して、上記の例はこのままでStrictだから補正されるわけではない。

これらの観点から、以下のように考えるのだけどどうだろう?
・tableは最初から多次元配列を目的にしている。
 # 単次元配列は目的にない。
・dlは最初から単次元配列を目的にしている。
 # 多次元配列は目的にない。

ご意見キボンヌ。

920 :Name_Not_Found:02/02/14 18:28 ID:bWnoqQOV
dtとddって対じゃなくていいの?

921 :Name_Not_Found:02/02/14 18:37 ID:jrfiMLJR
>>918
全面的に同意。

>>919
俺 dl には連想配列みたいなイメージを持っていたんだけど
919 の "データ0" を見たらなんか解らなくなった。
dl≒単次元配列という見方では、919 の
"定義1" と "データ1" はどういう関係になるの? ただ前後関係のみ?

922 :Name_Not_Found:02/02/14 18:42 ID:S7QIJqte
>>919

<dl>
  <dd>データ0</dd>
 <dt>定義1</dt>
  <dd>データ1</dd>
 <dt>定義2</dt>
 <dt>定義3</dt>
</dl>

これはDTD的に問題がないだけでStrictじゃないだろ。
どういう定義リストなのか小一時間問い詰めたい。
はっきり言って、dlの定義は <!ELEMENT dl (dt+, dd+)+ > であるべき。

923 :Name_Not_Found:02/02/14 18:49 ID:S7QIJqte
というか、茶文字氏は「valid = strict」という勘違いをしているフシがあるような。

924 :Name_Not_Found:02/02/14 19:25 ID:44CD172B
>>923
というか、valid = strict にならない DTD も悪いよね。
DTD でも表現可能な部分も結構あるだろうに。

925 :Name_Not_Found:02/02/14 19:46 ID:d6IpS+3S
>>924
激しく同意。

926 :サ骨 ◆/IQ5000w :02/02/14 21:26 ID:VwegbUcY
>>911
1日考えてCSSを絡ませる位しか思いつかなかった。><colgroup>

http://sakots.pekori.jp/2ch/sh.html

927 :Name_Not_Found:02/02/14 21:42 ID:jrfiMLJR
策定当時からそういう話があったみたいだ。
誰かこれ読んで概要だけでも教えてくれ...
http://lists.w3.org/Archives/Public/www-html/1997Jul/0451.html

928 :茶文字:02/02/15 04:53 ID:UK44AqPZ
うぅぅ MacのHDDを飛ばしてしまってる間にレスがようけついとる;

>>922
確かにDTD的に問題はない。
一般論としてdtとddが対でなければ文脈が通らない。
では、次のような場面ではどうだろう?

<h1>クイズの時間</h1>
<p>難問正解できるかな?</p>

<dl>
  <dd>今年の冬季五輪の開催地は?</dd>
 <dt>ソルトレイクシティー</dt>
  <dd>戦後初めて歴史的な訪中を果たした米大統領は?</dd>
 <dt>ニクソン</dt>
  <dd>日本最古と言われる日記文学「土佐日記」を著したのは?</dd>
 <dt>紀貫之</dt>
</dl>

dtとddが対ではあるが、定義される側がクイズの答えになるため
順序を逆転した。
視覚系UAではスタイルシートで回答の位置を右寄せにすることになるかな。
(dt+,dd+)+ではないけど。

>>926
そうなのよねぇ。私もCSSで区分を明確化するくらいしか思いつかない。
これだけでもtbodyを複数書いたりするのと組み合わせてかなりのものができそうだけど。
考えてくれてさんきぅ。

>>927
===以下何となく訳===

(dt|dd)+という子要素については、4.0に至っても修正がなされていない。
ドラフト段階では「dlは二つのパートから成る: ラベルとそれについての説明である」とされたが、
許可された(dt|dd)+とドラフトで求められた(dt+,dd+)+のどちらが推奨なのか
確かな説明はない。

このことは、「どんな順序で書かれても正しいのだ」ということなのだろうか?
それとも、仕様書策定段階で見落としがあったのか?
後者だとするなら、なぜ(dt+,dd)+と「するべきではない」と書かずに
「してはならない」と書かれるはずなのだろう?
(dt+,dd)+という規定は、ddがdlの第1要素になり得ないことを意味する。

===以上何となく訳===

つまりはいろいろな状況にたいして柔軟性をもたせたってことですかね?

929 :Name_Not_Found:02/02/15 07:54 ID:9o9CNQx6
柔軟性ばんざーい。というわけで、もっと柔軟な仕様にしてほしい。

930 :Name_Not_Found:02/02/15 08:36 ID:K6PMO0fg
>>928

<dl>
 <dt>今年の冬季五輪の開催地は?</dt>
 <dd>ソルトレイクシティー</dd>
 <dt>戦後初めて歴史的な訪中を果たした米大統領は?</dt>
 <dd>ニクソン</dd>
 <dt>日本最古と言われる日記文学「土佐日記」を著したのは?</dt>
 <dd>紀貫之</dd>
</dl>

漏れの感覚ではこれ以外有り得ない。

931 :Name_Not_Found:02/02/15 10:02 ID:pNY5OCO5
>>930
漏れの感覚だと dt の内容が語句でなく文章であることの方が
奇異に映る...ダメだとは思わんけど。
928 みたいな使い方今まで考えたこともなかったけど、なるほど、と思った。
>>919 で言ってる "単次元配列" の意味がやっと飲み込めたというか。

932 :Name_Not_Found:02/02/15 12:18 ID:K6PMO0fg
>>931
ddはあくまでdtの「説明」でなければ意味がない。
この場合「今年の冬季五輪の開催地は?」というのは「説明」にはなっていない。
「今年の冬季五輪の開催地は?」という語句(文)に対する説明が
「ソルトレイクシティー」なんだから、dt-ddの順にマークすべき。

というか、dd-dtのような構造を認めてしまったら、何のための定義リストか分からん。

933 :Name_Not_Found:02/02/15 12:28 ID:09gsurby
>>932
つうか、dd-dt のような構造は strict 的に OK なの?って
誰か W3C の偉い人に聞けば解決しないかな。

規格があやふやでも決めた人には一応のヴィジョンはあるだろし、
それを無視して勝手な想像で話しあってもらちあかない。

934 :Name_Not_Found:02/02/15 13:14 ID:K6PMO0fg
HTML 2.0 の改訂履歴にこんなのを見付けました。

| <!ELEMENT DL - - (DT | DD | %stext;)*>
| <!-- Content should match ((DT,(%htext;)+)+,(DD,(%stext;)+))
| But mixed content is messy. -Dan Connolly
| -->

元々混合内容を考えていたと思しく、何度も内容モデルが変更され、
その度に "Content should match ((DT,(%htext;)+)+,(DD,(%stext;)+))" という
一文が記されています。

今の定義が (dt | dd)+ なのは、もしかするとこの混合内容モデル時代の定義を
引き摺っているからなのかも知れません。(んなこた無いか)
HTML 2.0 の最終案で (DT | DD)+ になる直前までは、割と (DT*, DD?)+ が濃厚そうな
雰囲気を醸し出しているんですけどね。

ちなみに、一時期はそのものずばり
<!ELEMENT DL - - (DT+, DD+)+>
という案も考えられていたようです。($Id: html.dtd,v 1.7.2.2 1994/04/01)

まあ非常に古い話なので、余り参考にならないかも知れませんが。

935 :Name_Not_Found:02/02/15 13:49 ID:Gsr7Xsuk
>>934
> HTML 2.0 の最終案で (DT | DD)+ になる直前までは、割と (DT*, DD?)+ が濃厚そうな
> 雰囲気を醸し出しているんですけどね。

DTが0個以上、DDが0か1個出現の組を任意個……ってこと?
DTが無い(無くてもよい)定義リストって……? 誰かサンプルきぼんぬ。

936 :Name_Not_Found:02/02/15 14:18 ID:K6PMO0fg
>>935
それは多分、pやdivの内容が空でも良いっていう程度のものだと思うけど。
(DT*, DD?)+ だったら <dl/> でもvalidだし。

937 :Name_Not_Found:02/02/15 19:17 ID:WJhp0mZp
棒サイトに
<center>松井秀喜</center>

なら論理的だ

と書いてあった。

938 :Name_Not_Found:02/02/15 19:45 ID:K6PMO0fg
<p align="right">のじたん</p>

939 :Name_Not_Found:02/02/15 19:55 ID:x/KCugQU
<b>ひろゆきの唇</b>

940 :Name_Not_Found:02/02/15 22:42 ID:KU1P6yYJ
>>937
HTML の話で本気でそう思っているなら仕様書読めって逝っといてくれ。


941 :Name_Not_Found:02/02/15 22:54 ID:EegyYXyp
<right>日本愛国党</right>

942 :937:02/02/15 23:07 ID:WJhp0mZp
>>940
まあ、冗談でしょ。


943 :Name_Not_Found:02/02/15 23:18 ID:w3+Indy3
>>941
right要素はないよ!
<div align="right">日本愛国党</div>なら可。

944 :Name_Not_Found:02/02/15 23:24 ID:scFifUT5
>>943
idが惜しい
もうすぐでw3cだったのに

945 :固いの:02/02/15 23:25 ID:BvA6DAto
<strong>太くて...</strong>

946 :Name_Not_Found:02/02/15 23:30 ID:scFifUT5
>>945
もともと論理要素なので3点

っていつからネタスレに!
別にいいけど。

947 :Name_Not_Found:02/02/15 23:35 ID:WJhp0mZp
strict・・・・

valid・・・・

well-formed・・・・

 それぞれどうゆう意味なの?

948 : :02/02/16 00:15 ID:4HKUeDHa
>>943
Indyか。プログラム板逝ったらスゲェ自慢できるかも。

949 :勘で答える:02/02/16 01:24 ID:MLbXLR0w
strict・・・・厳格な

valid・・・・正当な

well-formed・・・・より(・∀・)イイ!!(マジ適当)


950 :Name_Not_Found:02/02/16 01:31 ID:ztcqhWxh
>947,>949
XMLでは
well-formd:開始・終了タグの関係やネスト関係等が適正なこと
valid:well-formdに加え、データ構造が適正なこと
大体こんな感じらしい。
 ttp://www.asahi-net.or.jp/~ps8a-okzk/xml/xml_1/two_type.html
このへんが参考になるかと。

951 :茶文字:02/02/16 04:10 ID:rKpQAsME
<button>中田</button>
<sub>北島</sub>
<ruby>寺尾聡</ruby>
<label for="sapporo">赤</label>

と出遅れてみるテスト
# 私だけ妙に年齢層高そうなネタだな;

952 :Name_Not_Found:02/02/16 04:52 ID:Q/fqLcMo
そろそろ次スレきぼんぬ>>950あたり

953 :Name_Not_Found:02/02/16 07:00 ID:d9UzEcv4
>>951
2行目ワラタ

954 :Name_Not_Found:02/02/16 07:21 ID:7hRjDSjW
テンプレはこのスレでいいのか?

955 :Name_Not_Found:02/02/16 08:13 ID:Q/fqLcMo
次スレの叩き台をageてみる。

Strict-HTML スレッド 3.0

1

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 http://pc.2ch.net/hp/kako/992/992708594.html
2 http://pc.2ch.net/test/read.cgi/hp/1008380243/-100

2

■関連スレ
/* 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

956 :Name_Not_Found:02/02/16 09:15 ID:ztcqhWxh
新スレです
http://pc.2ch.net/test/read.cgi/hp/1013818251/l50

957 :Name_Not_Found:02/02/16 18:02 ID:FIyYhwGA
Strict-HTML スレ 3.0 Draft (Exprired!)

 物理マークな HTML 3.2 勧告より、むしろ論理マークな HTML 3.0 草案たれ
                      ──ティム・バーナーズ・リー


…なんて新スレを立てようと思っていた私は逝ってよしですか?
>>950狙ってたのに、寝坊したよ。(今起きた)

>>947

Strict HTML document
 期待される用途に沿った記述がなされているHTML文書。

Valid HTML document
 妥当なHTML文書。妥当とは、DTDが文書インスタンスの特性を完全に表現していて、
 かつその文書インスタンスの記述が実際にDTDの定義に従っていること。

Well-formed HTML document
 整形式のHTML文書。整形式とは、文書インスタンスが完結記憶かつ完全タグ付きであること。
 文書がDTDの定義に従っていない場合、その文書は妥当ではないが、整形式では有り得る。

958 :j君:02/03/08 03:17 ID:8/P/oBr4
さてと
こそーり1000でもとるかな

959 :Name_Not_Found:02/03/08 09:53 ID:fqoFs5Tx
1000とった人は死刑となります。

960 :Name_Not_Found:02/03/08 14:46 ID:MJVu0CVt
999でも死刑ですか。

961 :Name_Not_Found:02/03/08 15:19 ID:NzyyTsex
999は無期懲役です。

962 :Name_Not_Found:02/03/08 22:08 ID:mr2MoF70
>>961
IDがsexだYO!!

963 :j君:02/03/09 00:11 ID:hWStkFcq
コソーリ

このスレはエロイな 

964 :Name_Not_Found:02/03/09 03:16 ID:k31eLKG1
何でみんなこんな廃スレを見てんだYO!(w

965 :Name_Not_Found:02/03/09 16:14 ID:0Q+sXHDf
>>964

2ch死語

おまえもなー

966 :Name_Not_Found:02/03/10 02:01 ID:3SGe4a7g
1000

967 :Name_Not_Found:02/03/10 04:49 ID:d4h5cyLJ
1001

968 :茶文字 ◆xELvisFU :02/03/10 08:53 ID:hUPdVuKM
1024

969 :Name_Not_Found:02/03/10 09:27 ID:+H3j72HN
1048576

970 :Name_Not_Found:02/03/10 16:40 ID:72MmZM6r
1073741824

971 :Name_Not_Found:02/03/10 21:06 ID:G9S+zoRg
1099511627776

972 :j君:02/03/10 22:22 ID:KDZkMY4n
バーストかけるか

973 :j君:02/03/10 22:22 ID:KDZkMY4n
でも2こまで

974 :Name_Not_Found:02/03/10 22:57 ID:hzPNewi3
ストイックな人、という表現があるが、
この "stoic" が変化して "strict" になった、
というのはみんな知っているのだろうか。

975 :Name_Not_Found:02/03/11 06:15 ID:C/5HGJ08
id check

976 :Name_Not_Found:02/03/11 20:55 ID:3MEjsqic
>>974
有名な話だYO!

977 :Name_Not_Found:02/03/11 22:55 ID:mQkNNPD7
ttp://ice.prohosting.com/aragaki/bunsyu.jpg

978 :Name_Not_Found:02/03/13 09:47 ID:IxyR1ADd
  ∧_∧
 ( ・∀・) ニヤニヤ
 ( 1000 )
 | | |
 (__)_)

979 :Name_Not_Found:02/03/13 11:43 ID:85x/0bIB
  ∧_∧
 ( ・∀・) ソローリ
 ( 979 )
 | | |
 (__)_)

980 :Name_Not_Found:02/03/13 13:58 ID:SozodFdW
そろーり

981 :Name_Not_Found:02/03/13 16:34 ID:Xwj2yNQg
986

982 :j君:02/03/14 15:53 ID:qT9LdpZt
そろそろー

983 :Name_Not_Found:02/03/14 18:05 ID:95myOG7K
nifty の鯖に繋がらなくて、謎ラウンジが見られないんだけど、
j訓はどうよ?見られますか?983

984 :Name_Not_Found:02/03/14 18:54 ID:0YDzM0ub
ウトーリ

985 :Name_Not_Found:02/03/14 20:58 ID:+d87p0fu
いい加減j君のホペを教えなさいよ。

986 :j君:02/03/15 04:21 ID:ZArdDLD6
だってまだ完成してないもん。
でもなんかgoogleとかで検索できるから
数箇所からリンク貼られてるけど♪
出来たら発表しますね。


>>983
おとついくらいはniftyがメンテしてましたね
今日は知らないや。


987 :Name_Not_Found:02/03/15 04:33 ID:EkWPs17Y
2-3日くらい前、NTT の ADSL が
突然3時間くらい使えなくなってむかついた。
復旧後も全くノーフォローなんすけど。

988 :j君:02/03/15 04:41 ID:ZArdDLD6
ブロードバンドがこのまま進めばjpegやgifにしなくて
そのまま
<img src="akamaru.bmp" alt="赤丸">
としてもいい風になるよね
劣化無しの画像が余裕で見えるように10年もあれば余裕かな?

989 :j君:02/03/15 04:44 ID:ZArdDLD6
idがzardだ
ちなみにマーカー代わりの画像じゃないからalt="赤丸"としました


990 :Name_Not_Found:02/03/15 11:08 ID:Sy4D8BGX
  ∧_∧
 ( ・∀・) アト スコシ・・・!
 ( 1000 )
 | | |
 (__)_)

991 :Name_Not_Found:02/03/15 12:00 ID:EkWPs17Y
<get number="991"/>

992 :Name_Not_Found:02/03/15 13:18 ID:w47RYZLJ
<tsukkomi rel=">>991" content="なんだよそのget要素ってのは" />

993 :Name_Not_Found:02/03/15 15:07 ID:Dc8Qbqdi
コソーリ

994 :Name_Not_Found:02/03/15 15:39 ID:Dc8Qbqdi
マターリ

995 :Name_Not_Found:02/03/15 15:47 ID:Dc8Qbqdi
ヒソーリ

996 :茶文字 ◆xELvisFU :02/03/15 15:47 ID:GRAD2Z1X
#Re995{
  voice-tone : "コソーリ" ;
}

997 :Name_Not_Found:02/03/15 15:47 ID:Dc8Qbqdi
(・∀・)アト4!!

998 :Name_Not_Found:02/03/15 15:47 ID:Dc8Qbqdi
∀・)アト4!!

999 :Name_Not_Found:02/03/15 15:47 ID:Dc8Qbqdi
・)アト2!!

1000 :1000 ◆h.gHK9LE :02/03/15 15:48 ID:Dc8Qbqdi
                / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
         Λ_Λ <  コソーリ
        (´∀` )  \__________
  ∧ ∧   (___,,)_     
 (.,゚Д゚)/ ̄ ̄ ̄ ̄ /|     
 │ /∧ ∧    //||
 (/___(   ,,) _//  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ||  ,,/  つ ||/   <  1000!!
 ||  (__丿  ||      \__________


1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

299 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)