Strict-HTML スレッド17

前スレにあった、「テキストエリアに初期値。JSのオンフォーカスで消去」というのを気に入って使ってたんだけど、
致命的なことに今頃気付いた。
他のページを引用しようとしてコピー、貼り付けようとしたら「オンフォーカス」が利いてそれまでの書き込んでた文字が消える。
なんでこんな当たり前のことに気付かなかったんだろう。

じゃぁオンフォーカスで初期値だったら消去だな

>>60
どういう意味？
オンフォーカスすると初期値に戻るようにするの？
めちゃめちゃ無意味な気がするんだけど。

>>59
「オンフォーカスでテキストエリア内の文字列を全選択」にしたらどうだ？

>>61
onfocus="if(value==defaultValue)value='';onfocus=null"
とかってことでない？

>>63
なるほど。そういう意味か。
「初期値」ならば、か。つくづく読解力無いな。俺。>>60ｽﾏｿ
そのソースまるまるコピペで出来ますか？


>>62
JS質問スレで無理矢理聞きだしたやつをくっつけてただけなんで、そんなｓクリプト書けない……。

>>63
よく考えたら試してみたら済む話だよね。
できました。ありがとう。

無理に初期値入れてるとlintの満点対策に見えてしまう

おまいら初期値に何て入れてるの

「初期値」は「空文字列」です。Cで書けばchar* default = 0ではなくchar* default = ""です。

スレ違いだが、

>>68
キモイからポインタに 0 を代入するな。

>>69
0はﾇﾙﾎﾟｲﾝﾀと等価ですが、何か？

>>70
ｶﾞｯ

>>66
言えてるかも知れん。
最初の目的はそうだったけど、どうせ書かなきゃならないと思って書くならユーザビリティに優れた文字列を入れておきたいな、とは思う。

本文
と
本文欄
と
ここに本文を記入して下さい
だったらどれが一番優れてるんだろう、とか思うな。

あと、そういう系の文字列を入れてるのに、URL欄だけ「http://」が初期値ってのもおかしいような気がする。

URL欄にデフォルトで「http://」って入ってると邪魔くさいよな

>>73
自サイトURLはコピペだから、ドラッグ→Ctrl+vだしそれほど邪魔臭くは無いな。

つまりアレだ。

名前[　　　　　]
こんなBOXじゃなくて

[名前　　　　　]
こんなBOXにすればいいんだな？

>>75
違うだろ。

名前[田中　　　　　　　　　　　　]
メール[　　　　　@hotmail.com]
URL[http://　　　　　　　　　　　]

こうだ。

>>75
その方法の駄目な点を教えて下さい。

この際

名前[ 名前 ]
メール[ メールアドレス ]
サイト[ URI ]

とかでも構わんのじゃないかとか。駄目か。

特に必要がなきゃ初期値なんて入れない。

>>75ｰ77
メール欄にｳﾝｺしてみた自作自演ですか？

名前[ Name_Not_Found ]
メール[ sage ]
サイト[ http://pc2.2ch.net/test/read.cgi/hp/1068907834/l50 ]

>>75
labelはどうすんの？

空文字であることに重要な意味がある場合でも初期値設定しなきゃならんのかなぁ・・・

つかそもそも初期値入れとけってのは
UA によってちゃんと処理出来ない場合があるから、だろ？
別に必須属性って訳じゃない。

http://www.zspc.com/documents/wcag10-tech/index.html#tech-place-holders

意味があったり不具合を持つ UA でのアクセス(具体的に何があるのかは知らんが)が
無視して良いレベルでしかないのならば
無理して設定せなならんもんでもないだろ。
あった方が親切ではあるんだろうけど。

>>83
本当は空文字列が初期値として相応しいのに
不具合の出るUAが存在するために初期値ではない文字列を無理矢理指定するのだとしたら
そっちの方が問題だと俺は思う。

そうしたUAへのアクセシビリティは高まるだろうし、
それが重要であったり軽視したくなかったりするのであれば好きにすればいいが、
そんなのABBRがIEでコケるからってACRONYMにするのと根は一緒。

Javaで対策してても、Java切ってる人間に対して
メールフォームなどのボックスに初期値が全て入っているのは
わざわざ削除する手間をかけて結果的に不親切なような

<input value=""> ならlintに怒られないのはなぜ？

そもそもUAは空の初期値を未だに正しく扱えないのだろうか？
漏れは現状は正しく扱えていると見なしていいと思うので
このチェック項目は既に過去のものなんだけど。

http://www.kanzaki.com/docs/html/htminfo31.html#input_text
> 古いタイプのブラウザでは何らかの初期値がないとフィールド
> の選択すらできないことがある

って、なんてブラウザかな

都市伝説か？
「古いブラウザ」という話はあっても具体名を聞いたためしがない。
仮にベータ版の話なら無視してもよいのでは？
ベータ版でなくても無視してよいレベルの古さだとは思うが。

Strictorというのは特定のUAに縛られずにHTMLの理念にだけ従うものじゃないんですか？

Strictorとしては初期値というのが文章のなかでどういう存在なのかとか、現在の仕様レベルではtypeがradioかcheckboxだったら必須だとか初期値がないとresetしたときの動作が不定だとか、XFormsはどうだとかそういう問題だと思うのですが。

まぁそうだよな

lintに惑わされるなってことですか

せっかくなんで専用スレに行ってみたテキストエリアの初期値の話
http://pc2.2ch.net/test/read.cgi/hp/1034270272/117-

lintはさー
xhtml1.1でname使ってもいいところで使ってても文句言われるからﾑｶﾂｸわけですよ

>>95
具体例きぼん

FORMの部品とか？

>>63
それ、気に入って使ってたんですが、掲示板で、「修正」ってやると「修正前の書き込み」が「初期値」になるのでオンフォーカスで消えてしまいますです。全くどうやれば満足するんだよlint。

>>98
onfocus="if(value=='ここに本文を入力してください。')value='';onfocus=null"

ならまずかぶることはなさそうだが。

>>99
なるほど。「デフォだったら」じゃなくて「○○だったら」と特定してやればいいんですね。
わあ、何焦ってるんだろう。テンパってて思いつきもし無かったです。有難うございました。

>>98
初期値に無関係な値を入れてるから自動消去機能が有用なのであって
初期値が初期値としてまともに機能するならそんなスクリプトは要らない。

という事例をまのあたりにした気がする。

>>101
そんなに詰らんといて下さい。

>>99
で、適応しようと思ってperlのソースみたら、修正用と書き込み用は別のフォームを使ってました。
修正用フォームのJS消せばよかったのか……。

噂のID問題って何？

ttp://www.satoshii.org/markup/notes/2003/11
ttp://kazmacky.cool.ne.jp/kinkyo/2003e.html
> ID屬性及びNAME屬性、さらに對應するHREF屬性の値に使ふ文字を次の
> 40字 ABCDEFGHIJKLMNOPQRSTUVWXYZ.-_:0123456789 に限る
Strict的にはめんどくさい事になりそうで。

うへぇ、小文字使えないのか・・・

正直、知らんかった。

XHTMLでは使えないってことは、
つまりHTMLのidでも、小文字をなるべく使わない方がいいって事か。
大量に修正しないといかんなぁ……。

この話の根が深いところは、単に「HTML で小文字の ID を
使ったら間違い」という話ではないところだな。

id="foo" は間違いではないが、そこにリンクするには、
href="hoge.html#foo" ではなく、href="hoge.html#FOO"
と書かなきゃならないというのが SGML 規格から導かれる
結論。でもそれでは大抵のブラウザが認識しないという罠。

つまり、小文字の ID 自体は間違いではないが、小文字の ID に
対して「#」以下小文字を使ってリンクを張ったら間違いに
なるので、ならば最初から ID に小文字を使わない方がいいと
いう話。

もちろん小文字 ID で自ページ内リンクを張ったら自分が
間違いになるけど、たとえ自分が Strict に書いていても、
リンクを張る相手の HTML が小文字の ID を使っていたら、
その ID にはアクセシブルに Strict なリンクは張れない。

>106
使えないんじゃなくて、たとえばHTML4.01文書中に<a name="section1">〜</a>とか
書いても、大文字に変換されて SECTION1 と解釈される…ということらしい。
HTML4.01文書同士でリンクするときは対応するname/id属性が両方とも大文字に変換されるから
いいけど、XHTMLからHTMLにリンクするときはXHTML側は大文字でリンクしなければいかんとか。

で、いま上の行に"しなければいかん"と書いたけど、英文ではrecommendと書いてあり強制力は
どの程度なのかがよく分からんと。

うわ被り…しかも俺のほうは間違ってる?ぽいし

＿|￣|○

SGMLの呪縛だね。

>>110
SGML 規格に「ID 型の属性値は、小文字で書かれていたらすべて
大文字に変換してから解釈しなければならない」とある問題。
XML 規格ではこの問題はない。

name や href 属性値は大文字変換されないので、href で <a name>
にリンクを張る場合は問題は起こらない。href で id にリンクを張る
場合は、id の方だけ大文字変換後に解釈する規格なので、問題に
なる。

まとめると、リンク先が XHTML なら小文字でも何の問題もなし。
リンク先が HTML でも <a name> だけを使っているページなら問題
なし。HTML で小文字の ID を使っているところにリンクを張る時だけ
問題が起こる。この時、リンク元が HTML か XHTML かは関係ない。

# 「XHTML 1.0 で初めて ID 属性が登場」とかだったら何の問題も
# 起こらなかったのにね。(w

これ、あれだよね・・・
document.getElementById()
も影響受けるってことだよね・・・

このスレはSGMLスレではありません
HTML4.01はSGMLサブセットっぽい言語です

>>115
1行目はその通りだから、あまりここでSGMLの話をするのは
良くないだろうけど、2行目は違うよ。

HTML4.01規格の最初に「SGML適合」だと書いてある。で、
SGML規格には、すべての要件を満たしたときだけ「適合」と
名乗れるとある。

最初から「SGMLサブセット」と言ってたのなら、「その部分の
規定はHTMLでは使いません」でも済んだだろうが、「適合」を
名乗ってしまった以上、SGMLのすべての制約を受ける。

SGMLスレでもXMLスレでもないが、
HTML、XHTMLの話をする以上
そういう話が出るのはやむを得まい

すいません。
各ページにコンテンツの主要リンクをつけたいとおもっているのですが、　
中身のあとにつければいいのか、中身がはじまるまえにつけたらいいのか迷っています。
どっちがよろしいでしょうか

>>118
それはHTMLとは無関係な話です。

ユーザビリティスレへ書くつもりが誤爆しました失礼

出題は○×の2択です。
などの文章で○や×は何でマークアップするべきでしょう？
そもそも○や×をそのまま書くのも駄目ですか？

>>121
例文などのある具体例を示せ。
話はそれからだ。

>>121
○と×なんだろ？そのままでいいよ。

>>121
「マル」と「バツ」を意図しているなら
○はともかく×はバツではなく乗算記号なので気をつけられたし。

>>124
えー、そうなん？「ばつ」で変換できるのに？

むしろ正しいか誤っているか

>>124
それを言うならカタカナの「へ」と平仮名の「へ」って、
同じ文字コードを使用しているんじゃなかったっけ？

ageちゃった。あと考えてみれば文字コード方式によるのかな？

>>127
まじですか。でも、F7、F6交互に押したら形が変わるのがわかるんですが、どういうことでしょう？

>>127
JIS X 0208系(shift_jis,euc-jp,iso-2022-jp)とUnicode系は
平仮名のへと片仮名のヘにはそれぞれ別のコードを当ててると思ったが。

結局HTML4やXMLでは、Unicodeにある文字は表現できるが、ない文字は表現できない。
少なくともJIS X 0208に「バツ」という文字はない。
Unicodeにそれがあるなら数値文字参照使う手があるけど、あるのかなあ？

☓
✗
✘
あたりは違う？

SALTIRE
BALLOT X
HEAVY BALLOT X
・・・☓でいいのか？

英語だとTrue/FalseとかO / Xで代用しているからなぁ。

所詮「代用」じゃないか

>>134
ちゃうやん。「代用でも構文に問題はない」という意味やん。

そうやんけ、そうやんけ

日本語だと「はい/いいえ」が問題少ないかね。

>>132
少なくとも BALLOT X と HEAVY BALLOT X は違うだろうな。

神が降臨しました。

/* CSS･スタイルシート質問スレッド【25】 */
http://pc2.2ch.net/test/read.cgi/hp/1069216458/461-

>>138
そういう気持ち悪いものを見せないでくれ。

XHTML 1.1でのxml-stylesheet命令ですけど、どこに書いたらいいかの
指針が書いてある資料などはないでしょうか。

W3Cだと、XHTMLのページ
http://www.w3.org/MarkUp/
ではXML宣言の直後(DOCTYPE宣言の前)に書いているのですが、

XHTML 1.1の勧告
http://www.w3.org/TR/xhtml11/
では、head要素内に書いています。

仕様上どちらでもいいということだとは思うのですが、Strictor的に
どちらがより適切かというのがありましたら教えていただきたいです。

既知かもしれませんが、WinIE6.0(SP1)でMIMEタイプをtext/htmlに
して表示テストをしてみたところ、xml-stylesheet文をDOCTYPE宣言の前に
書いたときには「XML ページを表示できません 」とエラーになるのです。
head要素内にxml-stylesheetを書いたケースでは大丈夫だったので、
それについて触れられている資料がないかWeb検索などをしてみたのですが、
見つかりませんでした。

>>140
XMLの仕様としてはどちらでも良いようだけど、

http://www.w3.org/TR/xml-stylesheet/
>The xml-stylesheet processing instruction is allowed only in the prolog of
> an XML document. The syntax of XML constrains where processing instructions
> are allowed in the prolog; the xml-stylesheet processing instruction is allowed
> anywhere in the prolog that meets these constraints.

を見る限りルート要素より前が良さそうな気がする。
ここで言うprologってのはXML仕様書にある [22] prolog を示唆しているんだろうね多分。

>>141
普通に考えれば prolog は XML 1.0 の prolog でしょ。
xml-stylesheet PI を要素の内容に書くことはできないっす。
XHTML 1.1 仕様書のソースが誤りだということです。

http://lists.w3.org/Archives/Public/www-html-editor/2001JulSep/0152.html

余談。
> XMLの仕様としてはどちらでも良いようだけど
XML 1.0 の仕様上、'xml' で始まる PITarget は予約されているので、
予約名を使用する以上は該当する仕様の構文には従わねばならないかと。

>>142
ご指摘ありがとう。

# やはり素人が口出しするものではなかったですな。

>>141-143
情報ありがとうございました。
W3CのValidationサービスでも両方ともValidですし、本家本元が
ああ書いているだけに、head内に書いても問題ないと思い込んでいました。

text/htmlだとWinIE6.0ではエラーになりますけどhtml開始タグの前に記述
する形で進めようと思います。どうせWWW上ではapplication/xhtml+xmlでしか
提供していませんし。

つーか。
いずれストリクトなんて意味無くなるよ。
意味無くなれば綺麗でもなんでもない。
表現の自由を縛るだけの糞規格だよ。

>>145
糞だろうと何だろうと規格がなければ電子媒体など成立しない。
制約があって当然の媒体に対して表現の自由とか言ってる方が見識不足。

それから、どんなに表現力の豊かな素晴らしい規格を作っても
適合実装が普及しなければやはり役に立たないということも覚えとけ。

>>146
ストリクトのみしか受け付けない媒体なんてありませんがｗ
それなのにストリクトを押し付つけるのはイスラム原理主義者の思想と同じだよ。
改めたまへ。

結局 XMLを使っても論理的にマークアップすることになるわけで
それがstrictであるんだから

>>145
糞規格だと思ってるならそんなデータ形式使わなきゃいい。
自由な表現がしたいんでしょ？
満足できる別な規格と実装を探すとか
なければ自分で規格も実装も作って普及させれば
どんな表現でも自由にできるし、誰も文句を言わないよ。
それは別にHTMLで実現しなくてもいいことだ。

クレクレ君でワガママ言ってれば聞き入れてくれると思ってて
HTMLや標準化団体が思った方向に流れていかないからｳﾝｺｰって罵ってるだけじゃん。

>>149
まずは標準規格の徹底性がなってないだけの話な訳で

徹底性？

>>147
誰かが *お前に* 押しつけたの?

このスレも結構食いつきが良いね

答えに窮した途端釣り宣言を始めるスレがあると聞いてやって来たのですが。

釣れたｗ

俺が荒らしと釣り師の違いを教えてやろう。
荒らしと言うのは、周囲を叩くことによって自分が偉くなったように錯覚する馬鹿だ。
釣り師と言うのは、自分が馬鹿をやって周囲に叩かれる事でほくそ笑む変態だ。
では、周囲に叩かれそうなキーワードを言って、数行後に釣れた！というのは何か。

残念ながらそいつは釣り師ではない。荒らしでもない。
そいつは、2chの最下層カースト。悲しい「かまってクン」だ。
真の釣り師は、決して自分が釣り師である事を告白しない。
なぜなら、釣れた！と告白することは、
逆に、自分が周囲の叩きに「釣られた」事を意味する敗北宣言でもあるからだ。
真の釣り師のスレは、ライブ中は周囲を巧みな話術で煙に巻き、引き付け、
熱中させる。そして、なにもかもが全て終わった後、
ようやく数人が「あれは釣りだったのでは？」と気付くのだ。
いま2chで釣り師を名乗っている奴は、大概が周囲のレスにまんまと釣られてしまった
滑稽な"釣られ師"なのだ

誰よりもお前が釣られてるのな！

つまり 153 や 155 は Strict な釣り死ではないという事ですな。
できれば Strict な HTML について語っていただきたいですが。

ｸ ｶ ｶ ｾ ｹ ﾒ ﾒ ﾃ ﾃ
ﾃ ﾙ ｻ ｶ ｽ ｲ ﾓ ｲ ｶ
ｸ ｽ ﾗ ﾁ ｶ ｷ ﾁ ｷ ｷ
ｲ ｽ ﾄ ﾙ ｿ ﾗ ﾓ ﾒ ﾋ
ﾆ ｼ ｲ ﾗ ﾒ ﾓ ﾗ ﾒ ﾓ
ﾆ ﾉ ﾗ_ﾌ ﾔ ﾙ ﾓ ｾ ｷ

ハードコアかよ

>>130
> 結局HTML4やXMLでは、Unicodeにある文字は表現できるが、ない文字は表現できない。
HTML4ではSDATAを使えば原理上は表現可能なのでは。
上にも書いてるがSGML適合をうたっている以上部分的に
採用しないことは許されない。
(対応している処理系があるかどうかはStrictスレなので問わない)

ついでに言うと規格票に書かれているのは同定のための
情報であって意味や使用法に関する規範ではない。
つまり「バツ」の意味で「×」を使うのが誤りであるとは必ずしも言えない。
類型異字の包摂に関する解説を参照

>>161
www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/appendix/notes.html#h-B.1
> 相互運用性を確保するため、HTML文書の著者は、利用可能な
> SGML機構を通じてDTDを拡張したり実体定義の追加セットを
> 作るなどしてHTMLを「拡張」してはならない。
つまり適合SGML応用でこういうのは許されないと？

それならHTMLだってXMLばりに拡張しまくりなのでは。

>>163
> 相互運用性を確保するため、
ってことでしょ。一行上の
> 以下の諸注意は参考情報であり、規範ではない。
にも注意(NormativeにしてしまうとSGML適合を名乗れなくなるわけだ)
> それならHTMLだってXMLばりに拡張しまくりなのでは。
できるけど実装がついていかないからするなということでしょうね
で、実装がついていきやすいように仕様のほうを簡略化したのがXML。

>>164
> できるけど実装がついていかないからするなということでしょうね
つまり拡張しまくりでも依然として適合HTML文書を名乗っていいわけだ。
仕様は非公式にやめとけと言ってるだけで。なるほどねぇ。

何に適合してるかって話だろ。

www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/conform.html#didx-HTML_document
> HTML文書とは、この仕様に記す制約を満たすようなSGML文書のことを指す。

SGML機構による拡張を禁止してないHTMLは適合SGML応用規格で
SGML的な拡張もHTML仕様の制約の範囲内である、ってことなんでしょ？

初めからHTML文書としてでなくSGML文書として宣言すれば問題無いってことか。

規格上HTML文書として問題ないでしょ？

>>165
「激しく非推奨」であって「禁止」ではないからね。例えば、

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" [
<!ENTITY % preformatted "PRE | MARQUEE">
<!ELEMENT MARQUEE - - (#PCDATA)*>
]>
<meta http-equiv="Content-Type"
content="text/html; charset=US-ASCII">
<title>test</title>
<MARQUEE>test</MARQUEE>

こんなのだって、HTML 4.01 Strict 適合だ。実際、W3C の
Validator だって、Valid だと言う。もちろん「激しく非推奨」
だけどね。

結局 Valid であることに意味があるのではなく、その先に意味が
あるんだと思う。

Validの向こう側……特攻の拓読みたくなったぜ

>>170
「HTML 4.01 Strict 適合」ではないでしょ。
DOCTYPE が「HTML 4.01 Strict」じゃないんだから。

バリュ駒等のタグを挿入したら、その部分だけlintでエラーが出るのですが、どうすればよいですか？

バリュ駒等のタグを挿入しても不正にならないようなDTDとSGML宣言を自分で書く。

広告とかは別ファイルにしてobjectで読み込む。

某所にて
「正しいHTMLを書くより、次善的にでもテーブルレイアウトで綺麗に見せた方が良い」
という記述を見ました。

…何でそうなるのか、理解出来ない。

>>176
とりあえず欽ちゃん呼んで来いや

>>176
理解した上でそういう選択をするなら止めないけどな。
正しく書く必要が無いものって実際ある。

>>176
アドレスきぼん

>>179
「CSS　言いたい放題」でぐぐると一番最初に出て来るサイトの、「御礼とお返事」の
ページに書かれてました。

個人的には、テキストメインのページで正しいHTMLを書いていれば、綺麗とまでは
行かなくとも、テーブルに頼らずに見易いレイアウトは可能だと思うんですが。

テーブルレイアウトって汚く見える。

完璧にstrictなマーク付けでスタイルシートを適用し
最後に <div> を <table><tr><td> に置き換えれば
美しいテーブルレイアウトの出来上がりだ。

XSLTを使ってXHTMLから テーブルレイアウトHTML へ変換すると（藁

例のサイトに 「Valid? なユーザーからの指摘がわけわからない」とあるが、
"真のstrictor"はそんな風に批判したり、strictを強制したりはしない。
"strictorのタマゴ"のときはそういうことをするだろうが、
"タマゴ"と"真のstrictor"を混同してもらっちゃこまる。

見栄えにこだわりたければPDFなりSVGなりFlashを使えばいいのに。

テーブルレイアウトのページを見るたびに、テーブルとかせいぜいそれにCSS2を加えたもんでよくデザインなんてできるな、と思ってしまう。

>>184
「真の」が頭につく場合って大抵自分のことを言ってるんだよな

>>184
「真の」とか「タマゴ」とかってより、厨房か否かってだけの話かと。

とりあえず>>184は厨房って事で

「分別を弁えた大人か、それとも厨房か」とも言える（ｗ

なんか「真の」にこだわってる人がいるみたいだけど、
確かに「とりあえず噛み付くエセｽﾄﾘｸﾀﾝ」がvalid+strict自体を悪印象にしてることはあるかもな。
こう、「○○ｦﾀは空気読まないからな」みたいなのと同じで。

>>190
暴れる厨房がその関わるもの全ての印象を悪くするのは
どこにでもある話だけどな。

「とりあえず噛み付くマジｽﾄﾘｸﾀｿ」についても触れて欲しいかも。
「噛み付くのはエセだから」とか宗教がかったこと信じてるのでないなら。

ところでbrは本当に存在価値がないのか？
俺は意味段落と形式段落の違いで使えるんじゃないかとも思う。

<div><p>ひろゆきは2chの管理人......</p><p>西は1chの管理人......</p></div>
<p>ひろゆきは2chの管理人......<br >西は1chの管理人</p>

上下で同じ意味として使えるときもあるのではないかと。

とりあえず過去ログ・関連サイト全部読んでいただけるとうれしいですはい。
後者は検索すれば出ますから。

文章を翻訳するときに
<p lang="en">This is an apple. Nancy lives near high school built in 123.</p>
<p lang="ja">これは林檎だ。ナンシーは123年に建てられた高校の近くに住んでいる。</p>
みたいに段落毎に訳していますが、見出しを訳す時はどれがベターですか。

甲　<h* lang="en">History</h*> <h* lang="ja">歴史</h*>
　　　　　　　　<p lang="en">English Paragraph</p> <p lang="ja">日本語の段落</p>

乙　<h* lang="en">History</h*> <p lang="en">English Paragraph</p>
　　　<h* lang="ja">歴史</h*> <p lang="ja">日本語の段落</p>

丙　<h*><span lang="en">History</span> <span lang="ja">歴史</span></h*>
　　　　　　　　<p lang="en">English Paragraph</p> <p lang="ja">日本語の段落</p>

甲は 交互に訳しているだけです。
乙は 段落毎に訳すのではなく、見出し毎に訳しているわけですが
　これをやると見出しのレベルを考えると結局h1でこれをすることになって
　それなら、英語と日本語を別ファイルにするほうがいいかも知れないと思います。
丙は 一番妥当かなとは思うのですが。

補足になりますが、 訳したい英文は他所のサイトのもので、
できたら 英文と訳を並列させておきたいのです
（私の拙訳だけだと不安なので他の人に修正してもらいやすくしたい）

<h* title="History">歴史</h*>

んで、見栄えはスタイルシートで。

>>196
対応するブロックを同じ行のセルに入れる2列のtableなんてのも
構造的には意外と悪くない感じが。

間違えた。 >>195 です。

<a href="">ほげ</a>と<a name="">ほげ</a>は、
皆さんはどう呼んでますか？

私は前者は「リンク」、後者は「アンカー」と呼んでるんですが、
A要素はそもそもAnchorだし、LINK要素はあるし、何か違和感があるのです。

>>192
このスレで重要なのは BR に論理的な意味があるかどうかだろう

ButsuRi 的な意味はあるが。

>>199
どちらも「A要素」と呼びますが、ダメですか？

>>200
むしろ「行」それ自身が論理的概念なのかどうか、かと。
行なんて視覚系媒体でしか通用しないようにも思うのだが。

CSSでwhite-space: pre;且つウィンドウ幅で折り返してくれれば
brもlも要らないんだけどな。

>>199
漏れはこの場合の「ほげ」を「アンカー」と呼んでいる。

>191
マジとかエセとかってのは「本当にstrictな文書を書いてるか」って意味じゃなくて、
「そういう文書を書こうと思ってる人」ってのと「単に知ってる知識を自慢したい嬉しがり」ってのを言ってるんだよな。
表現がふさわしくなかった。

Validバナー貼ってるサイト
ｳｻﾞ

>>206
根拠も言わずに吠えられてもな。
日記は自分のValidなサイトで書きなさいな。

素朴な質問なんですが、ある文章を引用するとして引用元のページの
タイトルを書くとしたら<blockquote>内に書くべきなのかな。

<blockquote>
<div><a href="hoge">引用元のタイトル</a></div>
<p>
内容〜
</p>
</blockquote>

みたいに。それとも<blockquote>内は内容をだけにして外側に別記するべき
なのかな。citeとtitle属性で記述すべきだと言うことは分かってるんだけど
IEだと勝手にリンク張ってくれたりしないし、引用元のサイトのことを考え
ると自分でリンクを張るしか現状では対応策がないような気がします。

>>208
ネタだね。

Validバナーはそれに興味を示して正しいHTMLというものが存在するとい
うことに気が付く人がいる点（というか、俺がそうだっただけかもしれんが）
で価値は有るかもしれない。
自分はサイト案内のページには張ってあるけど全部のページには張ってないな。
必要性が感じられないし。

>>208
<blockquote>内は引用された文集なんだから、引用元の情報は別に書くべきでは？

10.2 Image titles

Task:Do not use the title attribute on images.

While the title attribute can be used on most elements, it should not be used
on the img element. The semantics of title are too easily confused with alt and
longdesc (see Short text equivalents for img elements ("alt-text") and
Long descriptions of images ) and user agent support is extremely inconsistent.

>>211
Accessibility ≠ Strict

because noun ≠ adjective.

<img>代替テキスト</img> で最初から定義してりゃ何の問題もなかったのに・・・

あれ、imgは要らないんじゃなかったっけ？

12.2 Alt content for embed
Task: Provide alternative content for embed with noembed.

と言ってしまうような文書ですから。

>>208
引用元に関しては BLOCKQUOTE の外側に記述すべきだと思います。
引用元と引用部分とはまた別のものですし。

余談ですが、
スクリプト置き場 [QUIA] （http://www5d.biglobe.ne.jp/%7Equia/tech/script-store/）
の引用元表示スクリプトを利用して、自動的に表示させてやるのがいいんじゃないでしょうか。
これなら title と cite で示せますし。

誰？

>>210,>>217
やっぱり外にcite要素として書くべきなんですね。ありがとうございました。

サイト制作者は，正当にマークアップされたHTMLによるドキュメントを通じて行動し，
われらとわれらの子孫のために，DTDとの協和による成果と，
WWW全域にわたつてセマンティックのもたらす恵沢を確保し，とほほの行為によつて
再び不思議マークアップの惨禍が起ることのないやうにすることを決意し，
ここにDTDがW3Cに存することを宣言し，この仕様書を確定する。
そもそもWebは，閲覧者の厳粛な信託によるものであつて，その権威はW3Cに由来し，
その文法はサイトの制作者がこれを行使し，その福利は閲覧者がこれを享受する。
これは人類普遍の原理であり，この仕様書は，かかる原理に基くものである。
われらは，これに反する一切のUA，マークアップ及び独自拡張を排除する。
サイト制作者は，恒久のURIを念願し，リソース相互の関係を支配する崇高な理想を深く
自覚するのであつて，インターネットを愛する諸国民の公正と信義に信頼して，
われらの情報とリンクを保持しようと決意した。われらは，Lintで満点を維持し，
marqueeとblink，テーブルレイアウトとのけぞる本を地上から永遠に除去しようと努めてゐる国際社会において，
名誉ある地位を占めたいと思ふ。
われらは，全世界のユーザが，ひとしく物理的要素と非推奨属性から免かれ，あらゆる端末から
閲覧する権利を有することを確認する。
われらは，いづれのサイトも，特定UAのことのみに専念してLynxを無視してはならないのであつて，
マークアップの法則は，普遍的なものであり，この法則に従ふことは，自サイトの可読性を維持し，
他サイトと対等関係に立たうとする各サイトの責務であると信ずる。
Web制作者は，W3Cの名誉にかけ，全力をあげてこの崇高な理想と目的を達成することを誓ふ。

>>220
ISO-HTMLの立場は？

こんなのよく読んだな

>>220は社会で憲法前文を覚えさせられたリア厨と
言ってみるテスト

小泉が自衛隊イラク派遣で憲法前文を引用したから、それに引っ掛けただけだろ？
世の中の動きに無頓着な連中には関係ないだろうけど。

>>220
長い、長すぎるぞこの野郎。

す、すまねぇ。あんまりネタ枯れ気味だったから、ガイドライン板から改編してきただけだ。

ところでおまいら、blog は RDF なんかで XML を利用しているケースがあるわけだが、
XHTMLの普及などに与える影響があると思いますか。
# す、すまねぇ。真面目にやってもこの程度のネタしか思い浮かばねぇ。

>>226
話題を提供するのは良いことだ。

>>220を守らない不思議マークアッパーは違憲で罰金。

>>228
元ネタ自体が罰金対象の記述じゃないから、そのジョークはイマイチかな。

>>220に基づいた立法をしないことには、罰金はとれません。

【Valid HTML!表示事件】最大判平成15年12月13日
・概要
不思議HTML解説サイトを営む原告Xが自サイトに「Valid HTML!」のロゴを表示していたところ、
「文法エラーがないことだけではロゴを表示できる要件に足らない」と、
W3Cにより「Valid HTML!」ロゴの差し止め処分を受けた。
Xは「HTML-lintで100点であるのにも関わらず、ロゴの表示を差し止める右処分は憲法220条違反であり無効」
としてW3Cを相手に処分の取り消しを求めた事件。
・判決
破棄自判。
HTML-lintはあくまで参考に留めるべきであり、仕様書以上の何物でもない。
しかもXのサイトは見出しがh3から始まっていること、class="red"などのクラス名を使用するなど、
このような公序良俗に反したHTMLは看過できないものであり、これを差し止めたW3Cの判断は違憲とは言えない。

ちょっと面白いじゃん

【UA事件】最大判H.15.12.13
【事実の概要】
　B(被告)は、サイトを閲覧しようとしたA（原告）がHTTPリクエストにUser-Agentリクエストヘッダフィールドを含めなかったとして、Aのサイト閲覧を拒否した。
そこで、AはUAについてサーバーに報告しないことは、RFC2616により許されており、報告しなかったことを理由として閲覧させないのは、UAによる差別であり、憲法14条1項違反であると主張した。

【判旨】破棄差戻
　憲法の規定は、専らW3Cや標準化団体と個人との関係を規律するものであって、私人間を直接規律することを予定するものではない。
　私人間の対立の調整は、原則としてサイトポリシーにゆだねられる。
ただし、一方の他方に対する侵害の態様、程度がWeb的に許容する一定の限界を超える場合にのみ、サイトポリシーに対する一般的制限規定である民法１条や90条、不法行為に関する諸規定等によって適用される。
　そして、サイト製作者は、HTTPセッションの一環としてコンテンツネゴシエーションの自由を有し、コンテンツ提供のためいかなるものをいかなる条件で提供するかにつき、原則として自由に決定することができるのであって、
サイト製作者が特定のUAを有するものをそのゆえをもって閲覧することを拒んでも違法ではない。

#>>220
#Webの権威がW3Cに由来ってのはイマイチだ。

おもしろいけど、ネタスレたてた方がいいかな?

最近はXML+XSLも使い出したから思いついたんだけど、HTMLの簡単な
文法チェックなら拡張子をXMLにするといいよねw。これなら初心者もできるし。

糞スレやめれ。

<dd></dd>のなかに長文を入れるのは違和感がありますが
どうしたらいいですか

<dd></dd>のなかに長文が入ってる＝2ちゃんねる

>>236
2ちゃんねるをやめればいい

1段落1<dd>にするとか

<DL>
<DT>＊＊</DT>
<DD>
<P>＊＊</P>
<P>＊＊</P>
</DD>
</DL>

こんな感じでどうでしょうか。

糞固定の言いなりは嫌です

激しく既出だと思うのですが、
<body>中に
<a href="hoge_large">
　<img src="hoge_small" />
</a>
と直接書くとaがインライン要素なので文法的に×でlintにも減点されます。
（aが無くてもだめだが。）

<div class="image">
　<a>
　　<img />
　</a>
</div>
と書くのが論理的には正しいのでしょうが。
各画像を<p>とか<div>で囲むのもめんどくさいです。

皆さんはどうされていますか？

<div class="nekogazou">
　<a>
　　<img />
　</a>
・
・
・
</div>

<div class="inugazou">
　<a>
　　<img />
　</a>
・
・
・
</div>

みたいなかんじで<div>囲みにしてるけど場合によるな。

>>241
どうしてもめんどくさいならTransitionalにでもすれば？
そもそも、そのリンクや画像の意味を考えれば
<p>や<ul>（<li>）、<div class="hoge">などでマークアップせざるを得ないと思うのですが。

<P class="refe_img"><IMG src="a.gif" alt="hogehoge" width="hoge" height="hoge"></P>

もしくは

<UL>
<LI><IMG src="./a.png" alt="hogehoge" width="hoge" height="hoge"></LI>
<LI><IMG src="./b.png" alt="hogehage" width="hoge" height="hoge"></LI>
</UL>

としていることがほとんどです。
まぁ、画像の用途によって違ってくると思うので、あんまり参考にならないと思いますが…。

>>236
1. 入れない
2. 我慢する

>>244
質問はxhtmlだろ
大文字でタグ書いてる場合じゃない

大文字わろた

>>241
「めんどうくさい」と感じるのはStrictな思考をしていないから。
あとは>243の言うとおり。

>>238
ddにp入れればいいじゃん

>>236
語句の定義が長いのは違和感、ということか？

>>246
各画像を<p>とか<div>で囲むのもめんどくさいですが、
皆さんはどうされていますか？　ってことなので、特にXHTMLに限った話ではないと判断しましたが。

ｎｙユーザの貝は市ね

なら、<img> を %block; に入れてくれるようティムにお願いしろや。

この話題ってスレ違いじゃないのか？
激しく既出だとか、それ以前の問題だと思うんだが。

>>236
画面一杯になるほどの長文入れてますが何か。

>>255
「ウォシュレットじゃないと違和感があります。どうしたらいいですか？」
「俺は尻など拭いてもいませんけど？」

会話ができないバカは失せろ。

>>255 =
「<dd></dd>のなかに長文を入れるのに違和感はありませんが何か？」

>>257
どうしたらいいか聞かれてるのに前提を否定してどうするんだろうね。

>>236
それはあなたが感じているだけです。
仕様上は問題ありません

>>259
>>255よ。これがstrictな回答というものだ。

>>259
>>258よ。これがstrictな回答というものだ。

>>261
興味ありませんが何か？

それはあなたが感じているだけです。
仕様上は問題ありません

説明文、なんだから文章であってもおかしくはないよな。
辞書みたいな感じに、説明＋例文とかだったらブロックレベル要素になっちゃうし。

一件だけかかった。

http://www.w3.org%01@%77%77%77.%67%6f%6f%67%6c%65.%63%6f%6d/%73%65%61%72%63%68?q=%76%61%6c%69%64+%73%74%72%69%63%74+%89%F1%93%9A+%94n%8E%AD%82%CE%82%C1%82%A9

つーか、なんで <dt> の中身はインライン要素しか認められんのだ？
<th> の方はブロックレベルでもいいのに。

>>266
termの意味がわかればそんな愚問は出てこない

あのさーたまに「ここまで引用」とか「引用終わり」ってわざわざ書く香具師がいるけどどーよ？

CSSでやってるんじゃなくて？

>>251
定番の答えは「その画像がどういう意味を持っているかによる」。
飾りならCSSの背景画像にするか、divで囲うかだし、
文章の一部ならpなりなんなりでマークアップすればいい。

とりあえずaltの中身で置き替えてみて自分がどうマークアップするか考えてみるのがいいんじゃない？

引用と転載の区別をつけたいんだろ。放置しとけ。

>>270
せっかく回答していただいたのに申し訳ないですが、
>>251の文中の
＞各画像を<p>とか<div>で囲むのもめんどくさいですが、
＞皆さんはどうされていますか？
の部分は、>>241からの引用だったりします。

引用符等が無かったせいで混同させてしまって申し訳ありません(´Д⊂

>>272
一連の流れを見てればわかるが、確かに誤解を生む書き方だな。気をつけろ。あと、コテは荒れるからやめろ。

何か偉そうだね

確かにコテは荒れるよなぁ。
勘弁してほしい。

この板はコテとageに過剰な反応示すよね

>>265
2件だったよ（藁 実質1件だけど。
というか、もうIEの脆弱性を使ったﾈﾀですか。
そのリンクに実害はないものの、M$はパッチも出さないし……（略）


この板はまともなコテにすら反応するから
まともでないコテその他は気をつけなければならない板だ

>>237
センスねぇな、お前。3回氏ね

htmlのレンダリングを処理する為にhtmlブラウザがあるというところから、理想から離れている

JavaScriptとhtmlブラウザの親和性を目指そうとした時点で間違っている

html/xmlは只のデータベースで、それを（人の眼に）明示的に処理するのはアプリケーションの力
HTMLというのは、
<車>ｶｳﾝﾀｯｸ</車>
という定義づけに過ぎない。なので、
グラフィカルな表現を許している時点でもうすべては"おじゃん"なのだ。

-------------------
Hye own chajyuges Hitlor Jyugent

>>277
> この板はまともなコテにすら反応するから
まともなコテもクソも自己顕示欲の塊はこのスレにはいらねえんだよ。

<dd></dd>のなかに長文が入るのは無事慣れました。
あと悩んでます

<dd>
長い文章で〜〜す
<ul><li>リスト項目</li><li>リスト項目</li></ul>
</dd>

この場合「長い文章で〜〜す」は<p></p>で囲むべきですか？

>>281
えーと、ul要素は、インライン要素の中に含められないよね？
長い文章、ってのがテキストレベルであるなら、ul要素は出現できない。
つまり、dd要素の中身はブロックレベル要素であるはずだ。
ブロックレベル要素が内包されているのに生のテキストを書くことは出来ない。
つまり、長い文章、って部分はなんらかのブロックレベル要素でマーク付けしなければならない。

理詰めで考えれば答えは出ると思うんだが。

>>282

あなたの「理詰め」で行くと下記はおかしいということになるのか？

<ul>
<li>親リスト
<ul>
<li>子リスト</li>
</ul>
</li>
</ul>

>>282
> えーと、ul要素は、インライン要素の中に含められないよね？
この行だけはその通りだが、のこりは間違い。

>>281
過去スレを「匿名ブロック」あたりで検索して周辺のレス読んで、
あとは自分で考えればよいかと。

>>281
参考まで。
ttp://www.satoshii.org/markup/notes/2003/02#day25-1

>>282
> つまり、dd要素の中身はブロックレベル要素であるはずだ。
おいおい。漏れが今まで行ってきたマークアップはみんな間違いだったのかよ。

教訓: 念には念を入れてDTD読んでおくのが吉ってことね。

>>281が駄目で>>283はイイという理屈が理解出来ないっす
インラインとブロックの混在

インラインとかブロックレベルとか見掛けにこだわった話をしてる時点でアウト。

>>289
「インライン/ブロックレベル」を見かけの話だと思った時点でお前がアウト。

XMLで <hoge>...</hoge> という要素を自作したとき
hoge要素がインラインかブロックレベルかを「どこで何を使って」定義するのか考えれば
答えは明らかだろう。

この説明に沿って定義すればいいのね。
http://www.w3.org/TR/html401/struct/global.html#block-inline

　　　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｄ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 Ｄ ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 Ｔ　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 Ｔ　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 Ｄ 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 Ｄ　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　 ￣￣　　 |　　　　　　　　　　 ／　 　　　　￣

　Ｄ　／　　 　 ∩＿＿＿∩　　　　 ＼_WＷ／
　・　 ≪　　 　 | ノ　　　　　 ヽ　　　 ≫　Ｄ　≪
　T　≪　　　 /　　●　　　● |　　　≫　・　≪
　・　 ≪　 　 |　　///( _●_)//ミ　　≫　T　≪
　Ｄ　≪　　 彡､　　　|∪|　　､｀＼　 ≫　・　≪
　！ ≪　／ ＼　　　ヽノ　/_>　／　 ≫　Ｄ　≪
　　　≪　＼|-─●─●-/　／　　　≫　！　≪
MMM＼　　|　　　　　　 /￣　　　　　／MMM＼
　　　　　 　|　　／＼　＼
　　　　　 　|　/　　　 )　 )
　　　　　 　∪　　　 （　 ＼
　　　　　　　　　　　　＼＿)

>>286
はい。間違いだったのです。

>>295
おいおい。

>>286は文盲、ということで。

>>297
( ﾟдﾟ)ﾎﾟｶｰﾝ

HTMLをプログラム言語だと宣う馬鹿がいるのがうぜえ。

ただのマークアップ言語だわな

「プログラム言語」の定義が違うんでしょうな。

「タグ」を「手打ち」する人たちはプログラマー気取りしてる訳だ

そう言えば「H1は文字を大きくする命令です」って解説してるサイトあったな。

>>302
意味不明

>>303
302じゃないけど、「根本的に間違ってる人に、正しい用語を使えというのは酷だろ」という皮肉では？

H1は見出しを作る命令だもんね。

命令じゃなくてエージェントへの愛だろ。

>>302
やっぱり意味不明。>>304の解釈でも原文の意味が通らん。

　HTMLをプログラム言語だと思っている勘違い野郎の中には
　タグを手打ちすることでプログラマーを気取る野郎もいる訳だ

・・・とかなら意味が分かるんだが。

>>307
そもそも「『タグ』を『手打ち』」という言葉使い自体を皮肉ってるのでは
なくって？

テキストエディタでHTMLを書くことを「『タグ』を『手打ち』する」なんて
言って粋がってる人たちは、HTMLのことをプログラム言語だと勘違いして
プログラマー気取りしているわけだ。

と言いたかったんじゃないかしら。

タグとか手打ちとかって言葉を使ってる時点で素人っぽいだろ。
それとHTMLをプログラム言語だと思ってる奴を皮肉って書いたんだと思うが。
てゆかお前の

>　タグを手打ちすることでプログラマーを気取る野郎もいる訳だ

この文が激しく痛いんだけど。

つまらなさすぎ

>>309
「手打ち」はともかく「タグ」は使う時もあるよな。
なんとなく『HTML4.0+CSS1リファレンス&作法』を思い出したり。

「タグ」と「要素」と「HTML文書」がごっちゃになってるのが多いな。
手打ちとか言ってる奴は「『ホームページビルダー』なしでも『ホームページ』つくれる俺偉い！」
とか思ってるんだろう。

「タグ」は普通の用語ですよ？

要素とタグを混同する奴がいるからおかしく見えるときがある。

何か俺さっきからレス被りまくり。＿|￣|○

>>313
>「タグ」は普通の用語ですよ？
それは百も承知。

>要素とタグを混同する奴がいるからおかしく見えるときがある。
これは309のことか？

>>315
> >要素とタグを混同する奴がいるからおかしく見えるときがある。
> これは309のことか？
いや？HTML入門講座みたいな感じのサイトのこと。

「正しいHTML」を覚えたてのころって、タグって言葉を使ったり、
tableでマークアップしたりするのに拒否反応を起こしがちだよな。

(1)要素とタグを混同（というか、曖昧に認識）
　　　多くの初心者、および「ほーむぺーじ作成講座」制作者
(2)(1)の誤りを指摘されて、「タグという言葉は間違い！」と早とちり
　　　『HTML4.0+CSS1リファレンス&作法』の筆者、および>>309

tableって使ったことないなぁ…
というか手持ちのリソースに表が出てこない…

年末年始に入っただけで、人、増えたな

>>317
> 「正しいHTML」を覚えたてのころって、タグって言葉を使ったり、
> tableでマークアップしたりするのに拒否反応を起こしがちだよな。
後者はわかる。表を使うべきときでもなぜか拒絶してしまう、って感じだよな。
ただ、前者の意味がわからない。
この板でよく槍玉に挙がるのは「○○するタグを教えてください」と言った、いわゆる「なんでもかんでもタグと言ってしまう現象」のことだと思うんだけど。

わあ、誤読。
「タグって言葉を使ったり、tableでマークアップしたりするのに」なんだね。
前者だけ区切って読んでたよ。

「正しいHTML」を覚えたてのころは、タグって言葉を使う。
「正しいHTML」を覚えたてのころは、tableでマークアップしたりするのに拒否反応を起こす。
と。

>>317ごめんなさい。

（要素ではなく）タグと言うべきところでもなぜか要素と言ってしまう。

あら、被った。

疾風伝説 特攻のタグ

>>322
大丈夫、私も同じように誤読したから。

「タグ」とtableはもともと使われる場面が限られてて
誤用の批判は沢山あるけれど正しい用例がそれほどないんだよね。
だから使っていい場面がうまく身につかなくて
変な刷り込みができちゃうんじゃないかな。
blockquoteなんかは頻繁に用例が見られるから
「インデントに使っちゃダメ」と言ったところでそういう拒否反応は起こらない。

タグと要素を混同してるやつって、
タグは省略できるが省略されない要素
ってのが理解できないだろうな。

blockquoteはインデントとして使うのも認めるだのなんだのなかったっけか

認めてはいないだろ。
表示上の後方互換性は持たせておけって話があるだけで。

>>329
たしかトホホだったかな

>>329
これか？
ttp://www.rju666.com/web/mistakable.html#indent_supplement

勧告書読んでも分からなかったんですが、XHTMLで

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="hoge.xsl" type="text/xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
・・・以下HTML文章

みたいにXSLTスタイルシートの宣言ってしても良いのでしょうか。
XMLとしては妥当だとおもうのですが、XHTMLの勧告書にはXML宣言を書いてある
例しかなかったのでいまいち分かりません。

>>333
構いません。

text/xslがかまわなくない気がする
application/xslt+xmlになったんじゃなかったっけ

IEで表示されないからね。
ああ、XHTML1.1ならどうせIE捨てるんだからいいじゃないかって？ ご尤も。

>>336
IEのためにHTML4を吐くXSLTかもしれないじゃないか!!

ゑゑゑゑゑゑゑゑゑゑゑゑ

>>335
application/xslt+xml も未登録です。
http://www.ietf.org/rfc/rfc3023.txt

ここに登録されるまでお待ちください。
http://www.iana.org/assignments/media-types/application/

ちなみにtext/xslも未登録。

現状は application/xml でよろしいか?

レスありがとうございました。
text/xslが未登録だとは知らなかった・・・。

お前ら聞いてくれ。S要素だけ使えることを発見。

＜s＞コイコイコイコイ＜/s＞

・・・タグを半角にすると・・・

↓

ヨ千ヨ千ヨ千ヨ千

ほら！！

はいはい、そうなの

皆さんにお尋ねします。

<p>チャットに参加しているのは<dfn>太郎</dfn>、<dfn>花子</dfn>、<dfn>マイケル</dfn>の三人です。</p>
(以下三人の会話)

こんな風に定義だけしっぱなしで人物について説明していない場合に dfn を使うのってアウトでしょうか。

だっふんだ！

>>346
別にいいんじゃないの？
<dd>なしの定義語リストも一応OKなわけだし。（好ましいかどうかは別にして）

strictとvalidは異なると

しかしstrictの定義は人によって異なると

そもそも>346みたいな例ってidやclassの無い<span>みたいで、
「無くても良いよね」という印象。
どういう場合にああいうマークアップするの？

>>351
XSLでdfnだけ拔出したデータベース作る場合とか。

>>351
CSSで単に色を変えたいとかｗ

>346
漏れはチャット自体文章では無い(HTMLには向かない)気がする。
ログ自体をxmlにして鞍xslを使う。

これならログも小さくなって鯖に易しくパーサでの編集もできるし。

>>346,354
HTML以前に、チャット用でないプロトコル(HTTP)でチャットをやるのが
Strict的でない。IRCでやれ

何がStrictなんだか。

<table>
<tr>
<td>あ</td>
<th>い</th>
<td>う</td>
</tr>
</table>

こういう書き方は問題ないでしょうか？

>>357
文法上問題はないんだけど、td th td の順で出てくる場面が思い浮かばない

>>357-358

相撲の番付表とか？

<thead>
　<tr>
　　<th scope="col">東</th>
　　<th scope="col">番付</th>
　　<th scope="col">西</th>
　</tr>
</thead>
<tbody>
　<tr>
　　<td>朝青龍</td>
　　<th scope="row">横綱</td>
　　<td>−</td>
　</tr>
　<tr>
　　<td>栃東</td>
　　<th scope="row">大関</td>
　　<td>千代大海</td>
　</tr>

>>355
BBS用でないプロトコル(HTTP)でBBSをやるのが
Strict的でない。NetNewsでやれ :-p

ほら、ここはhttpの大海原だ。
ストリクターはnntpに還れ。

とか言って本当にnntpで（以下略）。

>>357
<th>要素がどのセルに対する見出しかが分かりにくくなるので、
headers 属性を付けるべきだと思う。

>>359
scope="row" はその行全体に効くのではなく、その行の残りの
セルに対して効く。この場合、「朝青龍」などには効いてない。

<tr>
<td headers="YOKOZUNA">朝青龍</td>
<th id="YOKOZUNA">横綱</td>
<td headers="YOKOZUNA">−</td>
</tr>

と書かないと。

185 ：Name_Not_Found ：sage ：03/12/30 10:10 ID:???

　>>178
　>強制的に改行させていいのだろうかという迷いもあります。

　ならばこれでよかろ。悩むほどのことかい。
　<h1>タイトル <small>サブタイトル</small></h1>
　h1 small {display:block;}


187 ：Name_Not_Found ：sage ：03/12/30 10:38 ID:???

　>>185
　ソレってhtml的にも正しいと言えるの？

なにこれ。

>>363
サンクス。
headers属性ってどんなときに使うのかわかんなかったけど、参考になったよ。

Tim Berners-Lee氏が騎士になるようです。
http://www.w3.org/2003/12/timbl_knighted

JavaScriptに値を渡すために<meta>使ってもいいかな?

<meta name="height" content="100" />

そのためのプロファイルを用意すればね。

【授与】WWW生みの親ティム･バーナーズ･リーにナイトの称号
http://book.2ch.net/test/read.cgi/bizplus/1073293763/

可能か不可能なのか解らないので質問させて頂きます。
http://www.geocities.co.jp/Playtown-Domino/4598/HTML_11.html←ここのページ
にあるようなテーブル内のスクロールなのですが
これの応用でEXCELの枠固定みたいなことは出来ないのでしょうか？
（行、列のヘッダ部を固定）

>>371
誤爆？

Webサイト制作初心者用スレ vol.78
http://pc2.2ch.net/test/read.cgi/hp/1072860019/

HTMLエディタに関するアンケートです。
http://www.enquete.ne.jp/hundred/survey/20031217-6/
後で結果を公開します。

今日は珍しく3回も上がったよ。

mailto:[email protected]
を
mailto:test@example.com
とか実態参照を混ぜて書くのは不正ですか？
another htmllintではエラー扱いされたので

&#64とか自動で変換してくれないのかよヽ(`Д´)ﾉ

そんな変換掲示板側で勝手にされたら
キー入力できない文字を参照にして表現とか出来なくなると思われ。

何はともあれlintが間違い。
属性値表記については参照は解析・置換されなければならない。
# って属性値の話でいいんだよなぁ？

>>375
<a href="mailto:hoge＆#64;exsample.com">foo</a>
も
<link rev="made" href="mailto:hoge＆#64;exsample.com" />
もAnother HTML-lintではエラー扱いされないが。
(便宜上アンパサンドはいわゆる全角)

ローカルでlint使っていてスクリプトが古いとかじゃないよね。
>>377も実際調べたの？

例えば、
<a href="&#109;ailto:[email protected]">foo</a>
は「スキームがおかしい」とlintさんに怒られる。

>>378
<a href="m&#x61;ilto:[email protected]">hoge</a>
がエラーになる。

単にAnother HTML-lintが対応してないだけじゃない？
全能なわけじゃないんだから。

AHL、結構古いものなので、今読むとヘンだったり説明が食い足りない
ところも多々ある。
k16さんはもう直すつもりないそうだけど。

そーなの？時々修正されているような気がするけど。
HTML4.01でIDに小文字が混じっていると注意してきたりするようになったし。

現状のlintでは文字実体が含まれる属性値の型チェックは
ほぼ未対応(ごく一部のみ対応)、って感じだな。
id属性とかでも文字参照で表現すると解析されないままエラーになる。

どうしても修正して欲しかったらメーリングリストに投稿してみれば?
http://openlab.ring.gr.jp/k16/htmllint/mailinglist.html
k16 さんが対応してくれるかどうかは知らないが…。

俺は正直、そんなのどうでもいいだろと思った。
文法上正しいことが自分で分かってれば、
lint で100点を取る必要はないのでは?

＞文法上正しいことが自分で分かってれば、
自分で解らないと、>>375のように混乱してしまう。

別に修正されなくてもいいけど、エラーの可能性を検出するだけで
本当にエラーであるかどうかは別な場合のあることが
知られていてもいいかもとは思う。

>>378
&amp

>>385
http://openlab.ring.gr.jp/k16/htmllint/thanks.html
とか見てると、結構対応してくれているみたいなので、
ゴラァして損はないと思うぞ。

>388

(#ﾟДﾟ) ｺﾞﾙｧ
じゃなくて、

（;´Д｀） ｵﾈｶﾞｲｼﾏｽ
（　 八)
　　〉 〉
だと思うがな。

お願いしたらビールくらいおごってやれ。人として。

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!

【NAOｼﾌﾄ】アメリカでもポップアップ広告表示サイトは特許侵害？
http://book.2ch.net/test/read.cgi/bizplus/1073554184/

しかしあれだな、

>>386
>自分で解らないと、>>375のように混乱してしまう。

という奴まで現れるというのは、
Another HTML-lintがいかに信頼されているか、
そしていかに高品位であるかか、が伺えるな。

>>392
そりゃあ、ｽﾄﾘｸﾀｿが布教するときだって
「まずはlintで100点とれるように」とか言うし(同様に信頼の表れ)。

>>393
言うか？

>>392
「lintでチェックすると、エラーの箇所の指摘だけでなく、簡単な解説も
ついてくるので、勉強のきっかけになります」みたいなことは言うけど、
「100点とれ」とは言わないし、言う奴見たことないなぁ。
むしろ、「100点とれればいいというものでもない」というのは、多くの
人が言ってるよね。

>>395
漏れもそういう言い方するな。

>>394
多分、>>393もそういう意味合いかと。

まずは100点取って来い。話はそれからだ。

>>397
とったよ。で？

★★★★★★★★★★★★★★★★★★★★★★★★★
★　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
★　>>398は天才チンパンジー「アイちゃん」が　　　　　　　　　　　　
★　言語訓練のために書き込んだものです。　　　　　　　　　　　　　　　　　
★　アイと研究員とのやり取りに利用するので、　　　　　　　　
★　関係者以外は反応しないで下さい。　　　　　　　　　　　　　　　　
★　研究員以外でレスした人は、チンパンジーと　　　　　　　　　　　
★　認識されますので御注意下さい。　　　　　　　　　　　　　　　　　　
★　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
★　　　　　　　　　　　　　京都大学霊長類研究所　

そういや昔「内容の良し悪しは採点されません」を
コンテンツの出来のことだと勘違いしてたなぁ

>>400
俺はさっきまでそう思っていたよ。
「内容」というのは文書構造のことだったの？

>>397は逃げたか。つまらん。

まずは-1000点取って来い。話はそれからだ。

>>401
内容までは採点できないから、見栄え目的のマークアップや表使うべきとこに
定義リスト使ったりなんてのまでは判別できませんっていう意味だと思ったんですが。
で、そこから>>393や>>395のようなことが言われるんだと。

>>400-401 >>404
両方じゃねーの？

あくまでHTML文書の文法をチェックするものなんだから、
文書内容のチェックはそもそもできるはずがない様な。

>>406
だから
「１００点といってもコンテンツをほめているわけではないので
　文法だけでなく内容の充実にも注力しましょう」
の意味だと思っていた

とりあえず起点>>400

「lintでチェックすると、エラーで減点されて酷い点数になると思います。また、
エラーの解説を読んでも理解出来ないことがほとんどかもしれません。でも、
それらをひとつひとつ勉強して行って、理解出来るようになれば、その知識は
貴方にとって非常に助けになります」

>>395の前半を回りくどくしてみた。

全然関係ないけどlintで99点って見たことないんだけどどう？

>>410
アクセシビリティ系で-1点が出れば99点になる。
lintの限界で防げないのは無理に対応させない方がいい。

>>410
別のリンク先を、同じ文字列に張る（二箇所ね）

<a href="aaa.html">こちら</a>
<a href="bbb.html">こちら></a>

これで１点減点になんない？

>>412
細かいところをつっこむようだけど、それだと、アンカーに「こちら」という
文字列を使ってることによって減点されない？

確か、半角カタカナ1文字で1点減点。

lintは本文の長さ（要素数？）によって減点量が変わる。
エラー重要度が0〜9で表示されるが、あれは減点数ではない。
重要度1のエラーが1個だけ出たとしても、本文が短ければ
どかーんと減点されるはず。

UTF-8だと半角でも減点されないような

>>413
あ、そうだな。確か。ってかそうじゃなくてもさんざん言われてるしな、
こちらとかこことかヤメレって。

>>412
同じ文字列にリンクを張らざるを得ない時は
title属性で区別すると減点されないよ。

>412は１点減点の例を挙げただけでは？

・同じ文字列
・「こちら」などの意味の薄い言葉
・タグ外の">"は&gt;に

そろそろ切り上げろ! そんな下らん話。

>>421
ネタないもん。提供してよ。

<form>辺りって、どうやってマークアップしてる？

>>423
漠然としすぎてて何が聞きたいのか分からないんだけど。

とりあえず、主要な入力をする部分にはfieldsetを必ず使って、
dlリストで整形。

整形って言うのはよくなかったなStrictとしては。

Strict、<noscript>が使えないからイヤン。

>>426
使えるんじゃないの？

今掲示板つくってるんだけど、
ここの住人的にはHTML4.01よりもXHTML1.0・1.1のほうが好き?

標準準拠で表示させたいからCGI側でIEの時はXML宣言しないようにできるんだけど
最新ページをファイルに出力しておこうと思ったらXML宣言無しにしなきゃならいし。

ということで4.01に直そうかとなやんでる。

……ちゃうわ。
「Strict、<noscirpt>〜</noscript>の中に<img〜が書けないのがイヤン。」だ。

もう駄目だな＞漏れ

>>428
Unicodeにすればいいじゃん

>>429
念のために確認しておくが、
いったん div や p を挟めば書けることは知っているんだよね？
つまり、noscript がブロック要素しか包含できないことが嫌なわけだな？
・・・なんで？

>>431
恐らく理解してないと思われ

>>431
念を押すまでもないだろ。わかってないに1ﾋﾟｮｰｳ

はらたいらさんに残り全部

>>431
426じゃないけど、例えば、
<h1>
<script type="text/javascript" src="ランダムで画像表示するスクリプト.js"></script>
<noscript>
<img src="JS無効時に表示したい画像.png" alt="僕のページへようこそ！" />
</noscript>
</h1>
とかできないのがいやんってことではないかと推測。

>>435
だからpかdivで囲めば済む話

>>435
<h1>
<script type="text/javascript" src="ランダムで画像表示するスクリプト.js"></script>
<noscript>
<p><img src="JS無効時に表示したい画像.png" alt="僕のページへようこそ！" /> </p>
</noscript>
</h1>

確かにマヅイな

>>435
そもそもstrictDTDの文書でそんなH1を提供してること自体問題があるんじゃないか？

よく見たら、なんちゅうh1の遣い方だ

>>439
クライアントサイドで動的なテキストを書き出したい場合であれば
見出しだけでなく p や address 内でも同じ問題を抱える。
用法以前の問題としてDTD設計が変。
#「strictDTDの文書ではそんな p や address も提供すべきでない」とか？

<script type="text/javascript" src="xxx.js"></script>
<noscript>
<h1><img src="xxx.png" alt="僕のページへようこそ！" /></h1>
</noscript>

として、xxx.jsで、<h1><img /></h1>を差し込むようにすればよいのでは？

>>441
動的なaddress要素ってなんだ？そんなもんHTMLドキュメントでやろうとすることがおかしい気もするんだけど。

メタデータであってbodyに登場する必要のない情報を
ユーザの利便性のために書き出す場合とか。

>>436>>442
いやそれは勿論わかってるんだが、>>426程度のレベルの人間が言いそうだと推測してみた。
もう少し複雑な例になれば>>435のように書けたほうがメンテ性が高い場合があると思うし。
strictとは関係ないけどね。

>>445
まあ、わかっているとは思うが、そういう記述をしたいと思うこと自体がstrictな発想じゃない（動的な見出しってなんだ？と）ということもあるんじゃないかな。

>>446
ではこんなのはどう？
<h1>ブラウザによるCSS解釈の違い</h1>
<p>
現状ではブラウザによってCCSの解釈に差がある。
ちなみに現在あなたがこのページを閲覧しているブラウザは
<script type="text/javascript" src="UAを表示するスクリプト"></script>
<noscript>
JSが無効のためブラウザの情報が取得できなかったの
</noscript>
である。試しに違うブラウザでこのページを表示して欲しい。
</p>

>>447
<h1>ブラウザによるCSS解釈の違い</h1>
<p>
現状ではブラウザによってCCSの解釈に差がある。
ちなみに現在あなたがこのページを閲覧しているブラウザは </p>
<script type="text/javascript" src="UAを表示するスクリプト"></script>
<noscript>
<p>JSが無効のためブラウザの情報が取得できなかったの </p>
</noscript>
<p>である。試しに違うブラウザでこのページを表示して欲しい。
</p>

「動的な文書自体がStrictな発想でない(動的な文書って何だ？)」まで
最終的にはいきますかね？やれやれ。

>>449
やれやれっつーならstrictなHTMLドキュメントである理由を書いてもらえないかな。

＞W3C 信者もそうじゃない人も投稿歓迎。

ここは信者以外もいるんだよ。

>>449
あ、俺の書き方が悪かったのか。ごめん。
文意が変わっちゃうような、って意味。ランダムで見出しが変わる、ってのはおかしい、といいたかっただけ。
画像内の文字列が同じ、とかなら撤回するけど。

>>448
それだと明らかに一文の最中に段落分けされておかしい。
noscript要素直下にブロック要素以外がおけないというのは、
p要素の中にリストが置けないのと似ている問題のような。

>>452
日本語の文法がそういう仕組みだからやむをえないからな。

そもそも、
＞である。
の意味合いが違うのに、うまく合致してるだけ、ってのは問題ないの？

>>451
内容に合わせて見出しやaddressが変わっているのであれば
吐き出すテキストが動的でも文章的な整合性は保たれる。
仮に整合性の崩れる事例があったとしてもそれはスクリプト設計の問題であって
それを理由に一様におかしいというのもどうかと思う。

>>447-448
カードキャプターさくら？

>>451
スクリプトによって生成されるimg要素のalt属性の値と、noscript要素
の中に置かれたimg要素のそれが同じであれば問題ないのでは。

この場合は、同じ文字列のロゴを、色・飾り・書体などだけランダムに
変えたい、というような話だろうし。

あと、>>442のように書けば、
・スクリプトが有効なくせにnoscript要素の中身を表示してしまうブラウザ
・noscript要素を知らない上に、未知の要素を非表示にしてしまうブラウザ
などといったボンクラなUAでもない限り、アクセシビリティ的にも問題ない筈。
（実際にそういうボンクラなUAがあるのかどうかは知らない）

scriptはnoscriptを前提にbodyの中ではブロック要素のつもりで扱うのがいいかも。

cssの正しいマークアップについて解説してるサイトは無いのでしょうか？
見つからなくて、このままだとdiv厨に・・・｡･ﾟ･(つД`)･ﾟ･｡

>>458
CSSはマークアップ言語ではありません。
また、あなたの文章をみるかぎり、HTMLもきちんと理解していないよう
です。
まず、HTMLを正しく理解しましょう。
CSSはそれからです。
>>3のサイトで勉強してください。

ところで、head内にnoscriptを置けないのは何でだろう。。。

>>460
逆に訊くけど、head内にnoscript置きたいのってどんな場合？

>>448
じゃあこれは?

<h1>ブラウザによるCSS解釈の違い</h1>
<p>
現状ではブラウザによってCCSの解釈に差がある。
ちなみに現在あなたがこのページを閲覧しているブラウザは
<span id="hoge">JSが無効のためブラウザの情報が取得できなかったの </span></p>
である。試しに違うブラウザでこのページを表示して欲しい。
</p>
<script type="text/javascript">
document.getElementById("hoge").innerText = navigator.userAgent;
</script>

>>430
簡潔明瞭なレスﾏﾘｶﾞﾄ
それなら文字コードのこととか考慮しなくてすむので返って楽でよいのだけど、
XML宣言無しのXHTMLとHTML4.01sって、どっちが好感もたれるだろうか。

っていうか皆普段DTD何にしてる?

</p>が一個余計じゃネーか･ﾟ･(つД`)･ﾟ･

>>462
カードキャ（ｒｙ

>>462
お前は好感持たれるために文書型宣言してるのかと小一時間（ｒｙ

そうことじゃなくて、掲示板作って最終的には配布するわけで、
4.01とXHTMLだったらどっちの方が好かれるかと。

両方作ればって言うのは無しで。

>>462
<span id="hoge">不明</span>

>>466
4.01とXHTMLの両方というか
スイッチ可能に作るのが最も喜ばれるだろうね。
どっちでもそれなりの需要はあるだろうと思うが
他の条件がすべて同じなら俺はXHTMLの方を使いたい。

>>461
Scriptが有効か無効かで

metaを使って違うページに飛ばしたい時とか
違うCSS読み込ませたい時とか

script要素は置けるんだよね。

Strictな書き方覚えて、制限が掛けられるよりむしろ作りやすく管理もしやすくなる人って少ないのかな。
全体的に統一感のあるページが作れて(ﾟдﾟ)ｳﾏｰ

え、制限掛けられたほうが管理しやすくないか？

>>467
ウチは掲示板以外のページはほとんど1.1だから
KENTさんのとこのBBSを1.0か1.1に改造してくれたら喜んで使うよｗ

>>468
noscript要素は中身がblockだからmetaやlinkが置けないからじゃないか？

こう言う場合DTDではhead内、ブロックレベル、インラインで
それぞれ別の要素を用意する必要があるんだろうな。

>>471
そういや、KENTのとこのCGIって殆どHTML4.01 TransitionalでDOCTYPE宣言してあるけど、
たま〜に何も書いてない奴（Joyful Noteとか）あるよな。

何故なんだろ……。

KENTだから。

XHTMLベースの自作DTD

KENTのCGIはコード腐りすぎ
修正する気にもならん。

>>472
ins / del みたいに状況に応じて block / inline が切り替わる要素になってればよかったのにな。
ins も del も noscript も、タグをとっぱらっても valid であるように書くわけで。

KENTのcgiは、非推奨要素てんこ盛り。そして、<hn>等の使い方も変。ま、KENTに
限ったことじゃないが。で、それらを HTML4.01 strict に直して行く作業が楽しいん
だよなぁ。いい暇潰しになる（ｗ

一から書き直す方が楽。

>>473
Joyful NoteはHTML4.01 Transitionalじゃないとか。

W3Cの努力もあったのに

「IEは特許侵害」
http://book.2ch.net/test/read.cgi/bizplus/1074177571/

>>481
これ、どーなんの？

divタグ内にpタグを使ったり、
hタグ内にimgタグ・alt属性を記述しるのはヴァリッドと呼べるの？

>>483
無理矢理ageなくていいです

> divタグ内にpタグを使ったり、
<div <p/>/>

> hタグ内にimgタグ・alt属性を記述しる
<h <img/> alt=""/>

<div><p>云々</p></div>
<h1><img alt="云々" /></h1>
なら仕様書的には何ら問題ないかと

>>485
ﾜﾛﾀ でも素直に解釈するとそうなるよな

すんません。上記の通り、
<div class="bunsyou"><p>文章</p></div>
<h1><a href="http://URL"><img src="URL" alt="bana-"></a>Hタグ</h1>

これはOKかな？っと思ったのです。
thxですm(_ _)m

>>488
Webサイト制作初心者用スレ vol.79
http://pc2.2ch.net/test/read.cgi/hp/1074061533/

>>488
とりあえずとほほを見れ。
内容が良いかどうかはともかく、
> <div> 自身は特に何の意味も持たないタグです。
> p は Paragraph（段落）の略です。
意味はしっかりと書いてある。

厨房な質問ですんません
今まではHTML4.01Transitionalで作ってたんだけれど、これからはXHTML1.1でってんで
ソースを書き直してるんですが、うちのサイトにはアマゾンアソシエイトを取り付けていて
lintで診断してもらうと「XHTML1.1ではiframeは使えんのじゃ」と怒られてしまいます。
iframeに替わる別の方法はありませんか？教えて偉い人(つдT)

無いッ。

>>492
そうですか・・・諦めてHTML4.01Transitionalに戻ります(´;ω;`)

>>493
そこまでもどらんでも…
XHTML1.0 Transitional じゃだめなの？

xml って version 1.0 が再審？？

>>495
1.1はまだ正式規格じゃなかったよね

XML1.1はProposed Recommendation

まぁ、もう規格の内容は変わらないと思うけどね。

>>494
>XHTML1.0 Transitional じゃだめなの？

もう実際のところ殆どのページをXHTML1.1に変更してしまって、アソシエイトのためだけに
XHTML1.0 Transitionalに変えるのが何か生理的にいやーんな感じがしてしまうんですよ。
objectタグとかで無理矢理代用出来ないかなぁ。何て思ったりしてます・・・（無理そう

そういうのを用途に適さない文書型選択というのでは…。

>>491
object要素は使えないこともない。
が、IEでスクロールバーが消せないから俺は使ってないが。

そもそも>>491=>>493=>>499は、言動のはしばしから、HTMLの基本的
な考え方を理解していないことが伝わってくるので、>>3でお勉強し
なおすことを強く勧める。

いったん1.1にしたものを1.0とかに直すのは大変かも知れんな。
これから作るんだったら1.0にしてiframe以外はStrictに徹すればよい。
私もほとんど1.1だが、TOPだけは携帯やDCでも色がつくように敢えて1.0にしてる。

あと、アソシエイトがどういうのか知らんが、
何か埋め込むんだったら外部Scriptファイルと言う方法もある。

>>500
>そういうのを用途に適さない文書型選択というのでは…。

うぅ、やっぱそうですよね・・・そうじゃないと何の為のマークアップなのか
意味がなくなってしまいますね(´･ω･`)ｽﾝﾏｿﾝ

>>501
>object要素は使えないこともない。

一応やってやれない事はないんですね。でもIEで不具合が出るのでつか(;´Д`)

>>502
>そもそも>>491=>>493=>>499は、言動のはしばしから、HTMLの基本的
>な考え方を理解していないことが伝わってくるので、>>3でお勉強し
>なおすことを強く勧める。

なるほど、もう一度じっくり勉強し直してみます。(`･ω･´)ｶﾞﾝｶﾞｯﾃﾁｬﾝﾄｼﾀｽﾄﾘｸﾀｰﾆﾅﾙｿﾞ

>>503
>何か埋め込むんだったら外部Scriptファイルと言う方法もある。

あ、外部Scriptファイルを使う方法ですか。これだと意外とスマートにいきそうです。色々助言ありがとうです。

まさかscriptでiframeを出力するつもりじゃあるまいな。

scriptを処理する前ではvalidでもscript処理した後でnon validなら
javascriptを処理出来ないvalidatorとかlintを騙せるだけで実際はXHTML1.1として不当だと思うが。

http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.4

> HTML documents are constrained to conform to the HTML DTD
> both before and after processing any SCRIPT elements.

よくXHTML 1.1であれが使えないこれが使えないという人が多いけど、
http://www.w3.org/MarkUp/#xhtml11 によると

>This document type is essentially a reformulation of XHTML 1.0 Strict using XHTML Modules.
>This means that many facilities available in other XHTML Family document types (e.g., XHTML Frames) are not available in this document type.
>These other facilities are available through modules defined in Modularization of XHTML,
>and document authors are free to define document types based upon XHTML 1.1 that use these facilities (see Modularization of XHTML for information on creating new document types).
稚訳
この文章型は基本的にはXHTML Modulesを使ってXHTML 1.0 Strictを作り直したものである。
つまり他のXHTMLファミリーにある多くの便利なもの(例えばXHTML Frames)はこの文章型にはないということだ。
そういう他の便利なものはModularization of XHTMLで定義されたモジュールとしてあり、
文章を書く人は自由にXHTML 1.1を基にした文章型を定義することができる(文章型を新しく作る方法についてはModularization of XHTMLを見よ)。

ということなのでXHTML 1.1 + Framesモジュールを使うのがよいかと。

Modularization of XHTML
http://www.w3.org/TR/xhtml-modularization
日本語訳
http://www.y-adagio.com/public/standards/tr_xhtml_mod/Overview.html

特に
http://www.w3.org/TR/xhtml-modularization/dtd_developing.html#sec_E.4.3.
http://www.y-adagio.com/public/standards/tr_xhtml_mod/dtd_developing.html#sec_E.4.3. (UTF-8と宣言されているにもかかわらずShift_JISで書かれているので文字化けする可能性あり)
あたりが参考になりそう。

>>508
でもそれってXHTML1.1じゃないんだよね？

XHTMLは過去の資産とかUAとかをXMLに流用するための手段でしかないので
XHTMLにあわないから切り捨てるというのは本末転倒だと思う。

すると、その互換性を捨ててしまった XHTML2.0 には
もはや存在意義がない…と

自慰行為に存在意義があるかないか？と問われれば
俺は「ある」と答えるけどな

過去の資産じゃなくてこれから作っていく資産に適用すればよいわけで。

1.0と2.0をいっしょくたにすんなよ

＞ XHTMLは過去の資産とかUAとかをXMLに流用するための手段でしかない
この前提が1.0だけの話だよな。

http://www.yomiuri.co.jp/nyushi/center/04/exam/240/1.htm
アがHTMLなんだけど、HTMLで文字の色や大きさを指定するって言い切るのはどうよ

また抗議するんですか。

するの？

してよし

おまんら勃起しっ放しだな

挑み続ける人でありたい

>>516
言い切ってるのは「たけし」だけだから。
設問は別にたけしの知識の正確さを保証してない。

なんてな。

たけしの心情をいかにして汲み取るかがこの問題のポイントです

>>516
ウはOperaですか？

ウはUser Agentでしょうね。
エは…バイナリ埋め込むならBase64か…でもサイズ小さくならないし。

もまいら、次ページの解答群から選んでやれよ。

User Agent っていっても色々あると思うけど。

シネクドキーってことで。

lintで、formのname属性で5点減点されたんだけど、
これって現状ではid属性よりもname属性の方が
対応ブラウザ多いんだっけ？
互換性の為にname属性が作られたって聞いたから。
だとしたらフォームはトランジショナルにしておくべきか。。

>>529
id属性だけで困ったことはないが。

form, imgのname属性はJavaScriptのため、
input, select, textareaのname属性はCGIのためって感じで
使い分けてるんで、formのname属性は要らんと言えば要らん

糞なIEが悪い

すべての悪路は糞IEに通ず。

第三者を責めるのは簡単

じゃあ>>534が悪い

実は悪いのは全部俺

即ち>>534

それじゃあ全員>>534ってことで。

いえ一人

我らは全にして個、個にして全…

<br>って、ワープロの強制改行みたいに考えればいいのかなぁ？
それとも、改行=段落替えと定義して<p>使うべき？
文章的に改行したいけど段落は変えたくないっていう時とかあって、ちょっと困っちゃう。

作文とかだと、ほとんど改行は=段落替えよね。
でも「」使うときとか改行する人もいるし…。

文章に特別に間をあけたい時とか、CSS使って空の<p>とか<div>入れるのも気持ち悪いし、
かといって<br>入れて対処するのはどうかと思うし、スペーサー画像使うのはもっといただけない気がする…。

なんかいい方法ない？

>>541
当方小説サイトやってるんだが、仕方なく<br>使ってるよ。

<p>
地の文<br>
「会話文」<br>
地の文
</p>

<p>
地の文<br>
「会話文」<br>
地の文
</p>

理由としては……全部<p>でやると、スタイルシート切られたときに行間がスカスカになっちゃうってのと、
意味段落の判断も出来なくなるっていうことからかな。

普通に行間あけたいならCSSでやるべきだと思う。その為のmarginなわけだし。
"空の"という意味が良くわからないが……。

数式とか化学式を書く時とか<br>使ってる。

会話文とか、そういった特殊な時でない限り<br>は使わんわな

もっと言えば、<br>が空要素なのもSGML的にちと妙。
<l>を使いたいなぁ……

>>543
整形済み、と考えられるのでは？

>>541
＞文章に特別に間をあけたい時とか、CSS使って空の<p>とか<div>入れるのも気持ち悪いし、
間が空く直前のブロックレベル要素に「symptom」とかそんなクラス名与えて、margin-bottomが適切かと。
逆に間の後に注目するなら、そっちを採用してもいいと思うけど。

＃間、がそこにあるんじゃなくて、「これ」の後ろに間がある、とか、「これ」の前に間がある、ということ。
＃間、が単体で存在しているわけではない。

>>544
> もっと言えば、<br>が空要素なのもSGML的にちと妙。
ごめん、どういう意味か教えて欲しい。
一行をあらわすマーク付けがしたい、って意味じゃないよね？

>541
ストリクター的には <p> とすべきところだろうけど、
＞全部<p>でやると、スタイルシート切られたときに行間がスカスカになっちゃう
てのがねー…

ちなみに Word だと Enter = <p>、Shift+Enter = <br> だね。

XHTML2.0が出た後、l要素を濫用してしまいそうな自分が怖い。

>>547
いや、それ以前に「なんで強制改行がよくないと言われているのか」がわかってないレベルだから、それを前提に回答してあげて。

>>541
要はその改行 <br> が、その前後の文書に対して
"どんな意味を持つのか"が先決
CSSを無効にした時はあくまでブラウザの表示に依存されている
だけなので気にする必要は無い

>>541
「ブラウザの表示に依存されている」という説明がわかりにくいな。
あと、それだとなぜ「気にする必要は無い」のか、説明がないと
>>541にはわからないのでは？

すまん、>>551は、>>541じゃなくて>>550に対するレスね。

後段も、

「なぜ気にする必要が無いのか」まで説明してやらないと、>>541には
わからないのでは？

とした方が文意が通りやすいな。

>>552
・論知的構造（マークアップ）
・物理的l構造（視覚効果）

>>541
おおむね>>545に賛成なのだけど、「CSS無効な環境でも、そこに『間』
があるということを知らしめたい」と考えるのならば、"慣習的に"hr要素
を使ってもいいんじゃないかなー。
hr { visibility : hidden; height : 2em; }とか指定してやれば、CSSが有効
な環境では望みどおりに整形される筈だし。

個人的には、空のpやdiv等を使うよりは、たとえ物理要素ではあっても、
hrやbrを使った方がマシだと思う。

strictな文書で物理要素を使うことの是非については、ここが参考に
なるかも。

http://members.jcom.home.ne.jp/jintrick/Personal/css_small.html

要するに、論理構造とプレゼンテーションの分離は、目的ではなくて
手段にすぎないということ。

間に意味があるなら、「全角スペース」だろ。
これぞ日本人のわび・さびというものだ。
連続する white space を1つに収斂してしまう西洋人には
計り知れぬ世界だ。

空白が日本語表記に使用される文字であるならそうだろうね。

>>541です。
書いてる途中で言いたい事がごっちゃになって、
とっても曖昧な文章になってるのにレスどうもです。
例えば小説みたいに空間を空ける時や、詩みたいに韻を踏むときに大体できる方法、
あとそれ以外に<br>を入れるべきときがあれば、その扱いにって質問のはずだったんだ。

こんなにレスもらったの初めてだからちょっと嬉しいw

>>542
小説って微妙な間が重要だったりするから困っちゃうわよね。
意味段落も重要だから、安易に<p>使う訳にもいかないし。

>>550

ああ、送信ミスった（汗

>>550
ええと、段落替えでもないし、リストでもない、
整形するほどの文章の羅列ではないし…みたいな。
短文詩みたいな文章の使い方の時、他の手段が思いつかなくって。

>>554
それ(・∀・)ｲｲﾈ!!
<hr>を整形して使うって発想はなかった。
あとでリンク先も参考にしてみます。

>>556-557
うーん、空白は校正のときも「一字アケル」って指定があるくらいだから、文字として使う分には正しいのかもしれない。
でも、文字のレイアウトには使いたくないわね。

会話文に限って言えば、
<span class="kaiwa">「こんにちは」</span>
span.kaiwa{display:block}ってやってる。

A子「こんにちは」
とかいう文章ならdlになるし。

>>554
　賛成ｱﾘ

> おおむね>>545に賛成なのだけど、「CSS無効な環境でも、そこに『間』
> があるということを知らしめたい」と考えるのならば、"慣習的に"hr要素
> を使ってもいいんじゃないかなー。
　そういうのもありだとは思うけど、hr要素気持ち悪い派の人ってどのくらいいるんだろ。
hr要素気持ち悪い派の意見も、も慣習的派の意見もわかるだけに、比率だけが気になる。

#漏れは実際には慣習的派で、hr要素をつこてますが。

ところで、慣習とは何の慣習なんでしょうか。

あ、そういうことか。
それって慣習だったんだ…

W3C厨なりたての頃はhrは非常に使いにくいものだと思っていた。
んでもよーく考えて打つようになってからは普通に使うようになった。

<hr />は普通に使うねー。
<div class="section">みたいなのを複数使って
borderで区切るよりはスマートだと思うがな。

>>565
見栄え的なborder区切りとsectionを用いた論理構造の考えは別な

スマートってどんな判断基準だ？

>>567
空div使うかどうか、じゃないかな。多分。

>>565
(´ι _` 　) ...

間を表現する要素はHTML4.01には無い。だからHTML4.01の範囲では汎用要素で行うしか方法は無い。
その間が段落と段落の間の間であればdivだしそうでなければspanを使う。
で、cssでpause-afterなりmergin-bottomなりを使えばいい。
htmlにこだわらなければなにか他の別ネームスペースのxmlの要素を使えばいい。

製品情報
  ・製品1
    ・概要: ****
    ・価格: ****
  ・製品2
・・・
こんな感じの製品リストを書くときはどうする？
<dl>と<li>がものすごい入れ子になりそうな気がするんだが。
まぁこんなもの書くことなんて滅多にないと思うけどさ。

一連の話題で<pre>が話題に上ってないけど……。

小説とか詩で"間"が大切な時こそ<pre>の出番じゃないかと。

>>571
dlは入れ子になるけどliは出てこない、と。
ddを並べりゃ済むわけだからな。

>>571
こういうときこそtableの出番だと思われます。

>>572
それは、HTMLの要素の中に「詩などの間を表す要素」がないから、
次善の策としてpreなんだよね？

例えば「tableがないHTML」ってのを想像したときに
＞一連の話題で<pre>が話題に上ってないけど……。
＞表みたいに配置が大切な時こそ<pre>の出番じゃないかと。
っていってるようなもの。

あくまで次善の策と知った上でやったほうがイイ。

あと、もしその詩の改行に「意味がある」のならbr要素を使うのも手だ。
例えば水分子をあらわすときにこれはH₂とするようなもの。

意味がはっきりあるなら、整形もする要素を使うこと自体は間違いではない。
（もちろんpreを使うのもそうなので、全面否定する気は無い）
（整形を目的として要素を使うならtableもblockquoteも間違いだ）

>>575
それはどうかな。
改行位置に意味があるなら、「整形済み」とみなされるんじゃないか、と思うけどな。

brが必要な例。

国破山河在
城春草木深
感時花濺涙
恨別鳥驚心
烽火連三月
家書抵万金
白頭掻更短
渾欲不勝簪

行毎にPで囲むってのは和文における漢文の解釈ではありだけど
中国語の解釈だと大概の漢詩は通常の解釈と別の解釈を持ってるから
Pで囲むのはちょっとアレだ。
行毎にカンマを打って平文にしちゃうってのはアリだが、自分はBRの方が
好きだな。

>>577
それってbrが*必要*？
全体preよりもそっちの方が適している説明にはなってないよ。

>>571
この例の場合なら <table> にすると思うけど、一般的に
リストの入れ子がひどくなった場合は、

<h3>製品情報</h3>
<h4>製品1</h4>
<dl>
<dt>概要</dt><dd>***</dd>
<dt>価格</dt><dd>***</dd>
</dl>
<h4>製品2</h4>
...

みたいに、見出しでやってしまうこともあるな。

>>578
改行はしてほしいが行の折り返しもしてほしい場合、
preよりもbrの方がより適していると思われる

だからそれは具体的に何よ

逆にbrが「あってはならない」理由は何？

brは強制改行の要素として用意されているんだから
改行位置に意味があるんならbr使っても全然悪くないだろ。
preは改行や空白類、行の折り返しとか
文字通り整形全体に意味があるときに使うんじゃないの？
何か混同してない？

addressの中とかで使う人が多いと見た＞br

小説とか詩はpreでいいとおもう。
「原稿用紙で整形済みだから」。

ただ現実的じゃないからbr賛成派。

俺は「原稿用紙で整形済み」の文章を
どうやってマークアップするのかを悩んじゃうよ

原稿用紙は物理構造を記述するだけのフォーマットだからねぇ。

>>587
縦読みとか

CSSのwriting-modeとか？IE5.5限定だが…
別に（ﾟ�听)ｲﾗﾈと思うのは漏れだけ?

line breakであるbrやlineであるlよりもsub-paragraphみたいなものを表す要素が適切だと思われ。

>>583
禿胴、<br />は空要素なのでそれ自体意味は無いが
ただ、整形やレイアウトだけを目的した使用とか、
<br /><br />などのようにそれで行間を作ることはダメだってこと。
例えば。。。。
<address>
〒123-4567<br />
○○県○○市○○町1-2-3<br />
<address>
このように<address>要素の中であっても最低限の改行区切りは
必要だということになるのでこれを例に例えて使用する。
要は要素の中の文中であって特に意味を持たないモノでも作者の
意図的なものなら問題はない。又、<span>はあくまで視覚的効果
のみの目的なのでそれなら素直に<br />を使用するのが自然

だからpre使えヴぉけ

>>591
郵便番号の後のはいいけど、
1-2-3の後のは区切りとして意味を持ってないよ。

>>591
そりゃ言いすぎでしょ。
spanだって要素を区切るという構造的な役割を果たすことになるし、
それを認めないのであれば、brに視覚的効果以外の役割があると主張するのはおかしい。
どちらも自然ではない。
l要素（に相当するもの）がない故の妥協の産物なのだから。

>>592
(´ι _` 　) しゃべるなよ...
>>593
これは誤り（w
>>594
それも一理あるがそれのほとんどは何にしても視覚的な意図でしかない。
あるなら例をあげて欲しい。<div><span>の汎用の空要素だけど
<span>に対してCSSで視覚的効果を現しても、HTMLのマークアップ
のみ（論理的構造）で意図が把握できないだろ？

おまえの脳内で視覚的効果と論理的構造の切り分けが出来てないだけだろ

>>595
spanやdivに求める意図が視覚だと感じるのは、
結果としてそう見えてしまうだけだからだと思うよ。
ストリクターであれば、少なくともそれらを構造的な意図として、
それは大義名分にすぎないのかもしれないが、掲げているんじゃないかな。
UAがspanやdivに付加された意図を把握できないのは確かにそうだとしても、
それがbrの持つ区切りとしての役割を下回ることの理由にはならないでしょう。
何せ、論理的構造で意図を把握しようとするなら、
spanやdivに指定された意図がたとえ視覚的なものであってもそれは意味をなさず、
これらは区切りとしての役割だけを全うすることになるし、
そのときbrが担っている役割はspanやdivと等価でしょう。
また、あなたの意図がspanを見栄えのために使っている事例に対する警鐘であるならば、
その代わりにbrを使えといったら失笑を買われるでしょう。

ちなみにうちの場合、body内にメタデータを記述する手段として
<span class="DC.creator">などとやっているよ。
（ついでに見栄えは何も指定していない。）

http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4
The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents.

ちなみに、div・spanとbrを比べているように見える>>597は変だけど、
この場合は br vs span class="l" ( そしてCSSで span.l { display: block; } )
という構図があると思ってください。

>>596
さっさと寝た、寝た
>>597
だからね
<span><div>は空要素、HTMLでは全く定義が無い
<br>は空要素、HTMLでは強制改行という定義が存在している
つまり、StrictなHTML（CSS等視覚的部分を覗いた場合）では
<span><div>ってのはあくまで作者の任意の定義でしかなく、
逆に<br>を用いれば作者の任意の強制改行という定義になる
OK?

<span><div>は空要素で、HTMLでは全く定義が無かったのか・・・
このスレは勉強になる。

>>597
わかりやすく言えば、キミのあげている
<span class="DC.creator">
をHTMLのソースだけを見て class="DC.creator" の定義を
他人が把握できないだろう？

>>600
> <span><div>は空要素、HTMLでは全く定義が無い
　空要素だってさ。
汎用コンテナってどういう意味か説明してみて。

>>601
インライン、ブロックの違いぐらいわからない人は寝なさい

>>602
その場合は、
http://dublincore.org/documents/dcq-html/
のプロファイルを指定して、
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
をhead要素内に埋め込む。

>>604
インラインとかそんな話題は出てないよ。
指摘されてる箇所は、
「空要素」で「定義がない」と言ってる部分。

>>603
>汎用コンテナ
<p> = paragraph（段落）
例に従って自分で考えてみろ
<div> = ・・・・・・

550ってコワイわ！

>>607
<div>＝generic language/style container（汎用コンテナ）

だから、汎用コンテナって何かわかってんのか？って聞いてるんだけど。

>>608
久しぶりの大物素質もった人物なんだから丁寧に扱おうぜ。

>>610
ごめんなさい。

>>550
空要素、ってどういうものを指すかわかってる？

550は「ほうむぺえじ☆講座」で勉強してきました。

たしかに、釣師と一蹴するにはあまりにも惜しい人材だ。

550は今、空要素と汎用コンテナで検索しています。

>>614
釣り師ならせめて用語くらいは正しく使うと思う。
そうじゃなければ思った方向に持っていけないから。

きちんと知った上で、微妙にズラして突っ込みどころを作るのが釣り師。

>>617
釣り師にしてはこれだけ釣れてるのに次のキャストがないのがおかしいな。

550は今、空要素と汎用コンテナで検索し終えて、恥ずかしくなり、このスレをお気に入りから削除しました。

>>605
594に関していえばそれ以前の問題じゃないか？
>>609
それは 550 の答えになっていないのでは？
汎用コンテナとしてはわかるけどがその定義じゃないのか？

>>618
確かに。"w"という形状をした記号を文末に使うはずです。

>>620
なんで俺が質問して俺が答えるんだろうか。
つまり、「ここ」から「ここ」までを一括りである、と定義する、でしょ。
で、その一括りに意味を記述したりするわけで。

>>550
>>622で意味を説明したんだが、これでも「HTMLでは全く定義が無い」と言い張るつもりですか？

#多分、div厨が使うdiv要素の使い方しか見たことないんじゃないか、と。

>>609
キミの答え方だと
<p> = paragraph（段落）○
<p> = paragraph（パラグラフ）Ｘ
テストの時は問題を良く読むようにって先生に教わらなかったの（ﾌﾟ

今夜中に少なくともあと30レスは付くな

>>624
ああ、学校は中卒なんでね。そんなこと習ったことないや。
コンテナの意味が知りたいの?「容器」だよ。

550は名無しになって、揚げ足取りに移行しました。

>>624
　結局それに突っ込むのが精一杯か？
他にもいろいろ質問されてると思うんだが。何一つ答えられないみたいだな。

>>609,624
下記はブロック要素に定義を説明したものです。
例に従って??????????に定義の意味を入れなさい

例：<p> = paragraph（段落）○
　　<p> = paragraph（パラグラフ）Ｘ

　　<div>＝generic language/style container（??????????）○
　　<div>＝generic language/style container（汎用コンテナ）Ｘ

さあ、答えて下さい。

>>628
ああ、ついでに先生も>>629に答えてください

段落よりむしろパラグラフと言ったほうが的を射ているよな。

>>629
なんで答えなきゃならんのかわからんのだけど。

>629

>630

divが空要素なのか、に先に答えてからね。

>>598がわざわざ引用してくれてるのに
それが完全にスルーされてるのは
「読めない」し「読んだこともない」からだろう。
そして、引用元に行ったことすらないと。

やっぱり「ほうむぺえじ☆講座」なんかなぁ・・・
自分としては、W3C-HTML派 vs ISO-HTML派にありがちな
「高尚」な議論を期待していただけに残念だ。

そもそも意味が重要なのに直訳を要求してることがおかしいんだけどな。

>>633
ブロック要素だよ、誤レスしたかな？
だったら失礼
では答えて下さい、先生

>>634
> 「高尚」な議論を期待していただけに残念だ。
　多分他に誰も期待してなかったと思う。
div、span要素を「空要素」と言ってるんだから。

>>636
つまり、要素の分類として、
・空要素
・インライン要素
・ブロック要素
があるということか？

>>636
いや、空要素、といってなかったっけ？
あと、名前欄が消えたままになってる。

＞では答えて下さい、先生
>>635嫁。
汎用言語/スタイルコンテナで正しい。

>>638
もしかするとブロックレベルの空要素、と言いたいのかも。

とりあえず捨て台詞は止めてくださいね。

641はこのスレのどこかにいる誰かに向けて発せられたもの。

<p> ブロックレベル・段落を意味する要素
<div> ブロックレベル・何も意味しない要素

<span><div>は空要素、HTMLでは全く定義が無い

>>643
（　´,_ゝ｀）ﾌﾟｯ
オマエラさぁ、>>550に必死にレスしているけどよく読んだら
><div> ブロックレベル・何も意味しない要素
なのに
<div> ブロックレベル・コンテナ要素
だと言ってるのと同じことだよ

<span />
<div />

それで？

>>645
> オマエラさぁ、>>550に必死にレスしているけどよく読んだら
> ><div> ブロックレベル・何も意味しない要素
> なのに

><span><div>は空要素
と言ってる。捏造すんな。

勘違い君ってことなのか？
まあそのくらいにしとけや。

意味しない、という定義がされてるわけで。
＞<span><div>は空要素、HTMLでは全く定義が無い
は全面的に間違ってるな。

>>550は名乗って書き込んでくれよ。
どれが>>550かは見て分かるけど。

>553
>569
>591
>595
>600
>602
>604
>607
>624
>629
>630
>636
>645

とりあえずダイジェスト

スレが急に伸びたな

>>595 <div><span>の汎用の空要素
>>600 <span><div>は空要素、HTMLでは全く定義が無い
　　　┃この間に550の脳内で何が起こったんだろう┃
>>604 インライン、ブロックの違いぐらいわからない人は寝なさい

>>653
> 　　　┃この間に550の脳内で何が起こったんだろう┃
>>601が、「spanとdivを混同してる」と思ったのかも。

本人は「空要素」に相当思い入れがあるようだな。

＞　<br />は空要素なのでそれ自体意味は無い

とか言ってる割には、<br>にご執心のようだし。

みんな仲良く

　ちんちんシュッ！シュッ！シュッ！

>>656
>>550（656）以外はみんな仲いいよ。

　　　　　　　　 ＿
　　　　　　　 /　　＼―。
　　　　　　（　　　　/　　＼＿
　　　　　　 /　　　　　　　/　　ヽ　　　／￣￣￣￣￣
　　 ...―/　　 　　　 　 　　　＿）　＜　ちんちんシュッ！シュッ！シュッ！
　　ノ:::へ＿　＿＿　 　　　/　　　　　 ＼＿＿＿＿＿
　　|／-=o=-　　　　　＼/_　 　　__,,,,,,
　/::::::ヽ―ヽ　-=o=-＿（::::::::.ヽ'"-─ `ー,--─'''''''''''i-､,,
｜○/　。　　/:::::::::　　（:::::::::::::）　　 　 /::::::::::::::::::::::!,,　　＼
｜::::人＿＿人:::::○　　　　ヽ/　 　 　 i:::::::::::::::::::::;ﾉ　ヽ-､,,/''ー'''"7
ヽ　　　＿＿　＼　　　　　　/ 　 　 　 |:::::::::::::::::::::}　　　　　｀`ー''"
　＼　 |　.::::/.|　　　　　　　/　　　　　'､:::::::::::::::::::i
　　＼lヽ::::ﾉ丿　　　　　 ／`-=''''フ'ー''ヽ、::::::::::/ヽ､-─-､,,-'''ヽ
　　　　しｗ/ﾉ＿＿_-イ　＼＿／　　　　 ヽ--く　　 _,,,..--┴-､ ヽ
　　　　　∪　　　　　　　　　　　　　　　　　　　　｀`"　　　　　　＼>

　　　　　　∧
　　　＿＿ | |＿　　>>657
　 ／　　　　　　＼
　/　　　　 ⌒　⌒ヽ　　　　 ／￣￣￣￣￣￣￣
　|　　　　　(ﾟ)　(｡)　|　　 ＜　ちんちんシュッ！シュッ！シュッ！
　|　　　　　） ●（ 　|　　　　＼＿＿＿＿＿＿＿
　|　　　　　ｌｰ-一ｌ　|
　＼　　　　ｔ_,─､ｊ ノ　　
　　 ヽ＿＿_ ｌ_|_ｊ／
　　　　　　　| |　
　　　　　　　| |　　　　　　 ＿/ ＼_
　　　　　　　| |　　　　　／::::::　　　 ＼
　　　　　　　| |　　　　/;;;;::::::::::　　 　 ::|　
　　　　　　　| |　　　　);;(O):::::::　 　　 ::|
　　　　　　(´｀0 　 　<.;;:::::::::.::::　　　　 :|　　
　　　　　　!､__ )　　　 に] )ヽ::　　 　 ::/ 　
　　　　　. (　 ｀ｉ｀ｰ-- >─--------<　　　　
　　　　　　!､;;, ｀ー‐┴―――ｰ'⌒ ::ヽ
　　　　　.　 | |｀ー―┬―――　　 　 ::|

マンコー！！＼（・∀・）／

発狂したか

　　　　　　　　　　　,､､､----‐‐‐‐‐--､,　
　　　　　　　　　　 ／　　　　　　　　　　　:ヽ
　　　　　　　　　／　　　　　　　　　 　　　　 ＼
　　　　　 　 　 /　　　　　　　　　　　　　　　　 ヽ
　　　 　 　 　 /　　,,,,;;:::::::::::::::　　　 :::::::::::::::,,,,;;: ヽ
　　　 　 　 　 |　　"　　　　　　　　　 　 　　 　"　|　
　　　　　　./"'|　　　>┬o┬､ｉ　　　iy┬o┬< 　. |".ヽ >>657よ、ちんちんシュッ！シュッ！じゃ。
　　 　 　　.| ﾊ| 　 　.`┴‐┴' { 　 　}`┴‐┴'′　.|ﾊ l　きびしい冬にちんちんを出し、
　　　 　 　.| {..ヽ　.　｀￣￣┌|　￣ |┐￣￣´. 　 |,,} |　しごいて　しごいて　強くまっすぐに勃って
　　　　　　 ヽ_ l..　　/////└`----'┘/////　　|._ﾉ　ピュっと出す　ちんちんシュッ！シュッ！じゃ。
　　　　 　　 　　|　　ヽ ヽ--―‐--―‐--/　　 　 |　　
　　　　　　　 　 ヽ　 　!　＼二二二二／　!　/　/　　
　　　　　　　　　 `i　 　　　　　――　　　　　　/　　　
　　　　　　　　　 　ヽ　 __　　　　　 　　 　　　/
　　　　　　　　　　 　 ヽ＿＿＿＿,i＿_＿＿/

ちんちんシュッ！シュッ！シュッ！のガイドライソ
http://that.2ch.net/test/read.cgi/gline/1052852485/

NGword設定とかも知らないんだろうな。

　　　　　　 　　＿＿＿＿
　　　　　　　 /　　　　　＿ ヽ
　　　　　　　/☆ 　 　 }十{. |　
　　　　　　　|_白濁＿_＿＿_|＿
　　　　　　　| 　 ヽ　／　ヽ　|
　　　　　　　|　o ｜ (ﾟ)　(ﾟ) │
　　　　　　　|_＿ノ　　)●( 　|　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　 　|　 　　 　▽ 　|　 ＜　ちんちんシュッ！シュッ！シュッ！
　　　　　 　 │ 　.＼＿∪／　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　 |　 　 　　￣ |ｎ　ｳﾞｨｼｯ！
　　　　　　　（⌒ 　　＼　.（ E）　　　　　。ρﾟ。
　　　　　　　　＼　 ＼＿／／　　 　／⌒ﾟ。ﾟ
　　　　　　　　//＼　 ＿／)　　　　ゝ　 .ノ
　　　　　　　 //　　＼　 　　) 　／　 ／　ﾄﾞｸﾄﾞｸｯ
　　　　　　　υ　　　（　　.　|／ 　.／
　　　　　　　　　　　　|　　　　　／　ﾋﾞｸﾝﾋﾞｸﾝ
　　　　　　　　　　.　ﾉ　　ﾉ●●
　　　　　　　　　　丿　丿|
　　　　　　　　　/　／| /
　　　　　　　　/／　　μ
　　　　　　　 ∪

550=656=657

>>666
657のせいにしようとしても無駄だよ。>>550くん

　　　／￣￣￣￣￣￣￣￣
　　　|　ちんちんシュッ！シュッ！シュッ！
　　　＼
　　　　 ￣￣￣|／￣￣￣￣　　　　　　　　 　　　　　　　　　　　　ヽヽ
　　　　　 ＿＿＿　　　　　　　　　　　　　　　　　　　 　　　　　──┐　|　　|
　　　　／　　　　 ＼　　　　　　､i,,　　　　　　　　　　 　　　　　　　　/ 　|　　|
　　　/　　 ／　＼ 　＼　､,.i,,.;:"'　　ﾞ`´ｰ,"､-.,,　、　　∬　　　　　ノ　　　　ノ　　┐
　　　|　　　 (ﾟ)　(ﾟ)　　 |"　　　　　　　　　　　 ﾞ　ヽ　　・〜　　　　　　　　ヽヽ 　 ┴
　　　|　　　　）●（　 　|　　　　　　 /　　　 　,ｲ　. ﾞi　　　　　　　　　──┐　|　　|
　　　＼　　　 ▽　 　 ﾉ　　　　　　（　　　　ノ,;(`;､ﾉ　∬　　〜∞　 　　 　/ 　|　　|
　 　　　＼＿＿∪_／　　ﾞi-､＿,v-ｰヽ、　く ；;ﾞ､;;;';）　　　　　　　　　 　ノ 　 　　ノ　　┐
　　　　　　 　￣￣|　　|　　　　　　　ヽ、　）．;!':;'.ﾉ　　∫　　　　　　　　　　ヽヽ　 　　 ┴
　　　　　　　　　 ,ノ　 ﾉ　　　　　　　 __ﾉ　ﾉ,;:（;,:;(　∬　　　　　　　　　──┐　|　　|　　|　　|
　　　　　　　　 (＿_,ノ　　　　　　　 (＿,ノ´,;";:・':;'ﾞ`ヾ　　　　　　　　　　　　/ .　|　　|　　|　　|
　　　　　　　　　　　　　　　　　　　　　　　　ﾞ;"''∵　' :"‘　　　　　　　　　 ノ　　　　ノ　　　 ノ

レス飛びまくってんな。

★★★★★★★★★★★★★★★★★★★★★★★★★
★　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
★　>>667は天才チンパンジー「アイちゃん」が　　　　　　　　　　　　
★　言語訓練のために書き込んだものです。　　　　　　　　　　　　　　　　　
★　アイと研究員とのやり取りに利用するので、　　　　　　　　
★　関係者以外は反応しないで下さい。　　　　　　　　　　　　　　　　
★　研究員以外でレスした人は、チンパンジーと　　　　　　　　　　　
★　認識されますので御注意下さい。　　　　　　　　　　　　　　　　　　
★　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
★　　　　　　　　　　　　　京都大学霊長類研究所　

　　　　　　　 　　 （⌒~~--,_
　　　　　　　　　/'|　　　　　ヽ、__
　　　　　　　　 /.ﾉ　　　　　　　　 ）
　　　　　　　 / /　　　　.'^─---'′
　　　　　　 ./　|　　　／
　　　　　 ／　 ｀'---'　
　　　　／　　　　　 /
　　　/　　　　　　 ﾉ
　　　|　　　　　　/
　　　|　　　　 r⌒ヽ
　　　|　,＿__ノ|　　|.
　　　｀7　　|　 l.　　|.
　　　 .|　　|.　　|. 　 |.
　　　 |　　|　　　|　　|
　　　 |　 .|　　　 |　　|
　　　 ヽ_ノ　　　 .|　　）
　　　　　　　　　　~--'ܷܵܶ

＞レス飛びまくってんな。
反応したくないからフィルタかけたんだろ（　´_ゝ｀）

勘違いしていたということはあるようだな・・・

だがbr擁護派として・・・
brとspan {display: block;}を比べると
CSS切ったときのことを考えればbrの方がより適切だと思うね。

>>672
いや、ここまで暴れるとは想像だにしなかった、ってこと。
>>550許してやるから落ち着け。

>>673
適切、の理由が抜けてる。

>>673
擁護、っていうけど
br要素はむやみに使うと気持ち悪い、ってだけで全否定はされてないと思うが。


＞brとspan {display: block;}を比べると
＞CSS切ったときのことを考えればbrの方がより適切だと思うね。
見栄えとして、セリフだけ行を変えたい、と考えてる著者ならCSS切ったときにインラインになってもかまわない、と考えてると思うので、どちらがより適切か、というのは不毛じゃないか？

>>675
>CSS切ったときのことを考えれば
じゃ不足？

>>676
>見栄えとして、セリフだけ行を変えたい、と考えてる著者なら
>CSS切ったときにインラインになってもかまわない、と考えてると思う

かまわないとは思えないんだよね。
同じ理由でtext-indentも使わないで全角空白を使ってる。
「！」や「？」も*原稿用紙の作法*かもしれないが直後に空白を入れてるし。
まあ、ここまでくると著者の感覚の話になってくるかもだけどさ。

>>677
改行に意味があればbr要素
改行が見栄えならspan〜

だからどっちが適切か、とはいえないだろ、って話。

>>678
> かまわないとは思えないんだよね。
> 同じ理由でtext-indentも使わないで全角空白を使ってる。
　そう考えるは自由だが、お前はこのスレに住むべきじゃあない、ってことだな。

>>678
＞「！」や「？」も*原稿用紙の作法*かもしれないが直後に空白を入れてるし。
ああ、連続で入れて、って意味じゃあないのか。
そういうのは慣習的にOKじゃない？

>>679
CSS切っても改行が欲しい場合って話。

>>680
何か全UAがCSSを解釈することを前提にしてない？
こっちが原稿用紙の慣習をある意味神聖視しているのかもしれんが。

>>682
>>681で訂正してるんだが。

＞CSS切っても改行が欲しい場合って話。
わかってるからこそ、「適切と言い切るのは無理がある」といってるんだが。

>>683
＞>>681で訂正してるんだが。
そうだったか。リロードしてから書き込むべきだったかな。
……しかし681はどこをどう訂正したいのかよくわからんぞ。

>>684
えっと、
　　　　　　　　　　こういうことだと勘違いしてた。
ってこと。

>>685
なるほど。

まあ俺はbr完全否定論（preで十分、とかdisplay:block;使え、とか）に反発しただけなので、
作者それぞれで*適切*が違うというのは確かにそうかもしれん。

>>686
preで十分、は「整形済み、と言えるなら」で。
display:block;使え、は「『見栄え』として行を変えたいのなら」で。
それぞれ前提があって、「br使うな」という意見じゃあないでしょ。

>>676でそれを言ったつもりだったんだけど。

なんかさ、Strict-HTML と DOM を勘違いしてないか？
視覚的構造（見栄えの部分）のことで Strict とは無関係
汎用コンテナにしろ、論理的構造からはブロック要素でしかなく
id class などの汎用属性で関連付けしないと意味をもたない
<pre> にしても整形済みという定義はあるんだけど、しいていえば
"見栄えの部分をどうのように処理させるのか？" の見栄えの意味合い
しかもたない。white-space プロパティを知るなら説明しなくても
わかると思うけどね
適切に <br> 使えばいいんだよ

>>688
お前の書き込みの最後の方に <br> が無駄に使われすぎ

ウィンドウ幅で折り返してくれるpre要素みたいのがあれば、brなんて要らないのになぁ…

<br /> の使用は適切に・・・・
>>689 が間違いの例です。

>>690
>>688

>>678
> 「！」や「？」も*原稿用紙の作法*かもしれないが直後に空白を入れてるし。

この空白って、原稿用紙の作法というからには、全角空白?

全角空白を入れると、たまたま「?」の直後(空白の直前)で
行が折り返されると、行頭に来た空白で行頭が一文字下がって、
見た目、改段落と区別が付かなくなるのが問題だと思う。
原稿用紙の作法は行長20文字に固定されているからこそ成り立つもの。
行長不定のHTMLには基本的に合わないと思う。

半角空白なら、行の折り返しの際には消えるし、英文を考えれば、
それらの記号の後ろに空白を入れるのは、ごく普通だと思うが。

>>693
つまり、もっと細かくマークアップすればいいんですね？

それで、550はもう帰ってこないのか？

>>695
名無しで

呼んだか？カスども

＞ウィンドウ幅で折り返してくれるpre要素
それこそCSSに期待する事だろ。

>>693
「！」や「？」の直後は「行内では後続の文字との間に隙間を空ける」という
スタイルがあるだけで、別に空白という文字があるわけではないだろう。
全角にせよ半角にせよ。

>>694
むしろ、CSSその他が日本語の印刷慣習をほとんどサポートしていないために
冗長なマーク付けや物理表現(空白や<br>等)に頼らなければ
それを実現できない、ということでは。
# markup＋現在のCSSだけでは、日本語の印刷慣習の再現は無理だと思う。

そもそも、SGMLと、XMLのDTDの区別を
できない香具師同士が論議してても同じことだ

>>693
その辺はレンダリングエンジンに期待したいところだ。
既存のUAは英語と比べて日本語の整形が一般に下手なような気がする。
半角空白なら・・・あたりが現在の規格が英文を念頭に作られていることを
物語っているように思う。

>>699
>日本語の印刷慣習の再現は無理だと思う
印刷は定まった用紙・文字サイズ等、レイアウトは比率でしかない。
一方、様々なメディアでの観覧を目的としたモノとは習慣というより
レイアウト自体の主旨が違う
>>701
>その辺はレンダリングエンジンに期待したいところだ。
そらそうだが、Web には英語と日本語だけではない訳で
その考慮の為に定義されている「モノ」を上の方で
ああだ、こうだ、と罵り合っているだけだよ

オマエら何も解ってないよ
全部うる覚え

>うる覚え
釣り？ それとも天然？ あるいは2ch標準語？

オマエ「ら」という言葉は、自分以外は全て徒党を組んでいると
思い込んでいる奴が使う言葉だよな。

>>703,704
ここは Strict-HTML スレッド
関連の無いことは書くな

>>703,704
雑魚

(´ι _` 　)←この顔文字多用して恥ずかしい勘違い炸裂してた人
前にもweb板で見たことがある気がするんだが……

>>707
そういうキミも

質問だけど
ttp://www.scollabo.com/banban/のソースみてて思ったんだけど
h1って何回も使っていいの？

原稿用紙の作法をwebでも通用させたいと思うことには、そもそも無理が
あると思うんだが。また、webは元を辿れば英語圏で生まれたものだから、
英文表記に有利に出来ていることも否めない。

結局は、各人がしっかり考えて、より良いと思われる形式で表現し、時間が
経って、更に良いと思われる形式が見付かれば、それに変えれば済むこと
だと思う。

>>703
「うる覚え」と書くのは、天然で間違っている場合がほとんどと思われ。
あえて突っ込まず、生暖かく見守っていてあげようよ（ｗ

>>709
多くの場合、１回に落ち着くと思うが
使っちゃいかんということはない

随分スレ伸びたなーと思ってきてみたら（´・ω・｀）

HTMLはあくまでマークアップ言語だから、
言語自体のもとの慣習を破壊してまでテキストを抽象化する必要はないと思うのだが。

【結論】
見栄張るよりゃビルダーのがマシ。

>>713
破壊して抽象化した結果がマークアップだと思うが。

抽象化しない方がよい/する必要がない、と著者が考えているなら
それでいいと俺は思っているけれど。

おまえらの日常が如何にしょうもないか理解できるよ。

ところで何で時々煽りが入るようになったん？

煽り耐性のない住人が増えたから

話題ないしもう煽りでもいいや…と一瞬でも思うのさ。

>>717
虐められた550が腹いせに。

>>716-720
オマエら暇なんだな（w

飢えてるんだよw

おい、雑魚ども>>629の宿題はできたのかい？（w

はいはい

>>723
あーまだいたの？ まあ別人が釣ってるだけなんだろうけど。
とりあえずHTMLの仕様見れ。
<address>
<span>○○ ××</span>
<span>△△ □□</span>
</address>
でも1つ目のspanと2つ目のspanが別のグループであることがマークアップされているのでbrによる分割と差はない。
ちなみにDTDのコメントはあくまでコメントなので仕様書の方が正式なものだからgeneric language/style containerにこだわらない方がいいよ。

で、肝心の質問にも触れないとうるさいだろうから触れとくけど、
sketchbookとかone pieceとかprogrammingとかテストで出たらどうするの？
それでも満足できないなら「汎用容器」でいい？

結局のところ、brとspanの使い分けは、
（CSSを切った場合の）現実への妥協点をどこに置くかによる、ということでOK？

>>725
汎用容器でいいんだけど
要はプラス汎用属性等を併用しないとブロック、インライン
以外は何の意味をも示さないってことだ
仕様云々よりStrict DTDはどんな背景があって存在するのか？
また、マークアップの真の必要性を再度認識されたし

>>727
> 要はプラス汎用属性等を併用しないとブロック、インライン
> 以外は何の意味をも示さないってことだ
意味を示さない、と定義がされてない、は違うだろ、っていうのは？
550は「定義されてない」といってるぞ。

>>726
乱暴な言い方をすると、fontとspanの使い分けと一緒。
# グラデーション文字とか、スタイル変更が意味を伴わないヤツね。

さっきLynxで2chを見ていたのですが、
いままで飾りのような存在だった▲と▼のボタンが
これほど便利だとは思わなかった……。

誤爆？

>>729
> # グラデーション文字とか、スタイル変更が意味を伴わないヤツね。
　おまえはこのスレに存在する価値すらないと思うのですけれど

なんかStrict覚えたての奴が多いの？
fontは非推奨と規格に明記されているが、brなどはそうではないのだが。
ま初心者にはなるべくbrは使わずにと教えた方がわかりやすいのか。

>>732
＞fontとspanの使い分けと一緒。
スタイルに意味を伴わせる場合にはこういうことを言うつもりはないってだけだ。

＞brなどはそうではないのだが。
でも、特定のメディア依存の整形を指示する物理要素だと思うのだよ、やっぱり。
CSS切った環境での妥協点とか言われると、
その妥協の延長上がTransitionalじゃん。
勿論必要なら使っていいと思うが(俺も使うし)
*乱暴な言い方すると*そのへんの使い分けって一緒だよなと思う。
# もとより厳密な意味で一緒だとは思ってないよ。

XHTML2.0ではbrが非推奨になるという話を聞いたことがあるような気はするんですが、
↓これってどういうことなんでしょうか？
http://www.w3.org/TR/xhtml2/mod-inline-text.html#s_inline-textmodule_issue_2
l要素とbr要素に棲み分ける余地があるんでしょうか…？

HTML 4.01 仕様書の邦訳
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/cover.html

>>733
一応、規格（standards）じゃなくて仕様（specifications）ね。

ここはStrict-HTMLスレです。妥協とか実在のブラウザのこととかは考えてはいけません。

Strict DTD だって後方互換を理由に数々の妥協をしている文書型だ。

>>733
> fontは非推奨と規格に明記されているが、brなどはそうではないのだが。
書かれてる通り、で済むならこのスレの存在意義ってないよな。
解釈に幅があるからこそ、話し合う要素が生まれるんだよ。

話し合って仕様で認められた要素を勝手に非推奨にするのもどうかと。
まあ「俺は使ってる」「俺はなるべく使ってない」という議論が中心で強硬派はごく一部のようだが。

まあ、そういう人はこのスレに来ても何もすることがないでしょう。

>>742
わかってるよ。
そうじゃなくて、「仕様書で非推奨となってねえんだから使ってもいい」という表現は暴論だっていいたいわけ。
その理屈だったらb要素とかも使っていいじゃん、で終わっちまうだろ？

b要素を使ってもいい
太字が必要な文脈で使うのなら。

br要素を使ってもいい
強制改行が必要な文脈で使うのなら。

で、終わっちまった。

もう随分前に枯れたスレですから。

そこで終わらせたくないやつらの宴ですよ。

>>745
p要素を使ってもいい
パラグラフが必要な文脈で使うのなら。

>>745
ほら、同じだろ？って言いたいのか
ほら、違うだろ？って言いたいのか

どっちにもとれる書き方だな。無意味。

>>750
てめーで考えろ、と言いたいのだと思われ。

>>751
自分で考えた結果、考察の余地あり、だったのでこのスレで話題に出たんだろう。
それを「なんかStrict覚えたての奴が多いの？」とか水差すやつがいるからダルいだけで。

考察もダルいんでしょうな。

そういう人はね。

「br要素は非推奨じゃない」というまとめ方はスレ的に見ても思考停止じゃないかな。

>>755
ハゲドウマ

ん？fontとbrが一緒だと思った香具師が悔しがってるの？

悔しい？

水差しましょうか。

ダルい

覚えたてなのです

ちなみに17もスレが違うと同じようなネタが定期的にサイクルするようになるよね

×違う
○続く

その道もいつかきた道です。

>>762のような発言自体が定期的にサイクルしてるし。

このスレはリサイクルで地球に優しいスレでつね。

>>757
> ん？fontとbrが一緒だと思った香具師が悔しがってるの？
そんなやつなんていなかったよ？架空の人物でっち上げてなにがしたいの？

リサイクル

飢えてると何でも食べ物に見えるんだよ。

だから、<div><span>は汎用属性がないと意味が無いんだよ

>>770
意味がない≠定義されていない

私は覚え立てです

>>772
お、IDがbr

意味が無いのでマークアップとして解釈されません。
SGML的な扱いで言うと<!-- -->などと同じ扱いとなります。

ん？

>>770
属性がなくてもかまわんのでは？
いくつかの p や blockquote、リストなんかが div に入ってたら、それでひとかたまりの
セクション的なものだと判断できるし、class だの id だの振らなくても css でそれらしくレイアウトできるべ。
span だって、それがひとつの用語だという意味づけができるわけで。
dfn やら strong やらの出番ではないけど、ひとつの語として位置づけていることはわかる。

って、もしかしてそういう意味じゃなくて？

さすが覚えたてでない方々は仰ることが違う。

>>774
釣りか？
釣りなら釣られるけどさ、釣った後の処置とかあるの？

＞マークアップとして解釈されません。
　コンテナ。

>>777
どれが正しいのか判別つかないからレスポンスアンカー付けられないんだろうね。君。

>>779
んなもんつけるだけの意味あるレスでもないでしょ？

>>780
おまえもな←おれもな

>>780
いやいや、「覚えたて」に固執してるｳﾞｧｶがうまりにも鬱陶しいから。
覚えたて側なのか自称上級なのかはわからんけど。

そろそろただの煽り合いになってきたので
↓の話題でもどうですか

709 Name_Not_Found 04/01/25 15:45 ID:???
質問だけど
ttp://www.scollabo.com/banban/のソースみてて思ったんだけど
h1って何回も使っていいの？

711 Name_Not_Found 04/01/25 16:05 ID:???
>>709
多くの場合、１回に落ち着くと思うが
使っちゃいかんということはない

あ、俺の意見を追記。
普通の文書なら１回が原則だけれど、
複数のページをまとめて１つの文書にしたとき
（一括印刷用とか）などはありかと思った。

>>783
新しい話題さんくすこ。

h1がもう一つくる、ってことは、別の項目なんだから別のドキュメントにすべき、かな。
いや、このページに包括されてるんです、ってことならh2にしてそれを括るh1を用意したほうがいい。

>>784
そういう場合ならそれぞれの文書のh1をh2に。サイトタイトルをh1

>>783
「複数のページをまとめた１つの文書」と「普通の文書」とは区別不能では。
漏れは>>711で終わってると思うんだが。

>>787
終わってるけどな。
より好ましいマーク付けはどうなんだ、って話すのがｽﾄﾘｸﾀｿじゃねえの？

>>783の例だとReferenceとかはh2だと思うんだがな。

あれ？もうh1問題は終わり？

掲示板で、
<dt>名前<dt>
<dd>本文</dd>
<dd>UserAgent</dd>

と

<dt>名前<dt>
<dd><p>本文</p>
<p>UserAgent<p></dd>

とどっちがいい？それか別の案を。

>>783のサイトなんだけど、

＞abbr要素 と同様の働きがあります。該当部分に下線がつき、カーソルを近づけると、title属性の内容がツールチップに表示されます。これに対して、略語を１つの発音で表現できない（アルファベットで読む）場合は、abbr要素 を使用します。
acronym要素の説明
「略語を１つの発音で表現できない」ってUSAは頭文字だけど読めないからabbr要素、という理屈になるよな？

<dt>名前<dt>
<dd>本文</dd>
<dt>UserAgent</dt>

>>792
http://www.parkcity.ne.jp/~chaichan/src/htmabbr.htm
によれば、それは単なるウワサとのことです。

>>791
ネタ的回答
<dt>名前</dt>
<dd><p>本文</p>
<small class="ua">UA</small></dd>

※書き込み日時とかレス番号なども入れるのか？

>>795
入れたいね。
入れて、どうstrictにやんの？ってのにはかなり興味がある。
人の個性、というかその人のstrictに対する姿勢と言うか考え方が垣間見えるし。

レス番、名前、日付、UA、あればメアド、URLかな。

>>795
> <dd><p>本文</p>
> <small class="ua">UA</small></dd>
ネタにマジレス。これだと、dd要素がブロックレベルを内包してるのに、smallを直接書いてる、ってことにならないか？

あれ？lintでは叱られないね。仕様として認められてるの？閉じpタグの後ろにインラインって。

匿名ブロックGO!

>>799
div要素の中に生テキスト書くようなもん？
あれ？ちゃんと仕様書読んだつもりだったんだけどな。
なんか読み飛ばしてたのかも。
よければ、その部分わかりやすく教えて欲しいです。

#匿名ブロックの文章はなんかごちゃごちゃしてたので読み飛ばした記憶がある。

とりあえず今から読んでこようとは思います。

> レス番、名前、日付、UA、あればメアド、URL
データ構造だけ考えたら table がかなりふさわしい感じだが。
まあ整形結果的or生理的にNGな人が多いだろうな。

>>801
漏れの場合はやっぱり「一括で表示する量」の都合でtableでは重過ぎる、という物理的なネックもあります。
確かにtableの方がしっくりくる、と思う局面ではあるのだが。

> レス番、名前、日付、UA、あればメアド、URL
うちはulでやってる。
フォームはdlだけど、これやると名前[　　　]みたいに横に並ばせるのが一苦労で困る。

>>800
dd の内容モデルは %flow だからブロック(p)でもインライン(small)でも書ける。
なのでlintには怒られないだろう。

>>804
どっちもおける、っというのはどっちかで統一するもんだと思ってました。
ブロックレベルにするならブロックレベル、インラインならインライン、と。

<p>あ</p>あ<ul><li>あ</li></ul>
も入れれるってことですね。

>>805
よく使う混在例（リストの入れ子）
<ul><li>hoge
<ul><li>hoge</li></ul>
</li></ul>

>>805
少なくともDTD的には問題ないかと。
それ以上のことは「正しい／正しくない」というより、「便利／不便」
（CSSでスタイル適用したり、DOMでデータ抽出するときに）という
感じの問題なんじゃないかと思う。

>>806
<ul><li>
  <dl><dt>hoge</dt>
    <dd><ul><li>hoge</li>
    </ul></dd>
  </dl>
</li></ul>

俺はこうしそうだ。

別の話題ですまんそん。

文章の中で特定の人には意味がわかるけど、
他の人にはわからないような言葉を使った時に、
その言葉に簡単な説明をつけようと思ってます。
別の場所に書いた説明文にリンクをはるほどでもないので、
インライン要素使って title 属性に説明文を書こうと。

例としてはこんな感じ↓
<p>
こないだ、<span title="ＮＴＴのこと">みかか</span>から
請求書を見たら電話代が減っていた。
Bフレッツ<span title="万歳">マンセー</span>！！
</p>

んで、上の例では span 使ってる部分に dfn 使うと変でしょうか。
いまいち、強調以外のフレーズ要素のつかいどころがわからない。
省略じゃないから abbr とかじゃないし。
XHTML じゃないから　ruby つかって振り仮名つうのはなしで。

>>776,778,779
(ﾟДﾟ)ﾊｧ?

>>808
ちょっと冗長だし、そしたら一番外側のul要らないやん

>>809
spanかdfnでいいんじゃないかなー。

セマンティックな情報共有という観点からすると（ここは笑うところ）、
内輪にしか通用しない言葉遣いはできるだけしない、するならきちんと
解説する、というのが正解だと思うけど。
本当に伝えたい情報ならば、title属性の値にではなく、地の文として
書いた方がいいと思う。

<p>こないだ、みかか（NTTのこと）からきた請求書を見たら電話代が
減っていた。Bフレッツ、マンセー（万歳）！！</p>

あるいは、

<p>こないだ、<a href="#N01">みかか</a>からきた請求書を見たら
電話代が減っていた。Bフレッツ、<a href="#N02">マンセー</a>！！</p>

<dl>
<dt id="N01">みかか</dt>
<dd>NTTのこと</dd>
<dt id="N02">マンセー</dt>
<dd>万歳の意</dd>
</dl>

のように書き直してみて、「これじゃ野暮だ」と思うような場合は、正しい
しいマークアップの結果というより、「title属性の値をツールチップで
表示する」というブラウザの機能に依存した遊びである可能性が高い
のでは。

>>811
リストの一部なんだろ？

>>806
<ul><li>hoge1
<ul><li>hoge1-1</li></ul></li>
<li>hoge2
<ul><li>hoge2-1</li></ul></li>
</ul>

>>808
<ul><li>
<dl><dt>hoge1</dt>
<dd><ul><li>hoge1-1</li>
</ul></dd>
</dl>
</li><li>
<dl><dt>hoge2</dt>
<dd><ul><li>hoge2-1</li>
</ul></dd>
</dl>
</li></ul>

>>811 >一番外側のul要らないやん
<dl>
<dt>hoge1</dt>
<dd><ul><li>hoge1-1</li>
</ul></dd>
<dt>hoge2</dt>
<dd><ul><li>hoge2-1</li>
</ul></dd>
</dl>

>>809
例えば、dfn要素とtitle属性の組み合わせでマークアップして、
あとでスクリプト走らせて用語集を作る、なんてこともできるよ。
そうすれば、要素内容と属性値が、
それぞれdtとddの内容である定義リストに早変わり。

>>812 >>815
809 の疑問は、多分身内しか読まないであろうWeb日記書いてて
ふと思っただけなので、内輪用語に title 属性でポップアップ、は、
確かに遊び気分でもあります。

ただ、dfn をこういう感じで使ってもいいのかなあ、本当は、
技術文書以外で使うもんじゃないのかなあ、なんてちょっと
気になったわけです。
正直、仕様書の dfn の項をみても、使用例が載ってなくて、
技術文書でもどういうふうに使うのかよく判ってないのですが。

>816
実際にdfnをそういう遊びっぽい使い方しているサイトは見たことある。
それが正しいかどうかは解らないけど、納得はできた。
結局>812みたいに定義（dl）で解説するような単語は
dfnが一番しっくり来ると思う。

>>816
別に技術文書に限る、と仕様書に書かれているわけではないし、
実際に技術用語以外の単語をdfnでマークアップしている文書も多い
から、気にする必要はないのでは？

内輪だけの符丁とかスラングでも、dfnでマークアップしておけば、
>>815のようにして、「身内用語集」みたいなものを作ることができる。
そんな用語集を実際に作る必要があるかどうかはおくとすると、形式
や論理構造といった点では間違った使い方ではない。
だから、dfnを使っても間違いじゃないんじゃないかな。

> 実際に技術用語以外の単語をdfnでマークアップしている文書も多いから
解らなくはないが、根拠としてそれは危険では。

>>809
同じような疑問持ったことがある。
<dfn>が単語一般に使えるかどうか自信がなかったので、結局無難に<span>を使うことに。

そのままだとヘルプの存在に気づかれない可能性があるので
<span class="help" title="説明">として、
span.help{border-bottom:1px dotted;cursor:help;}みたいな指定にしている。
IEがCSS2に対応してくれれば
span[title]{〜}で済むのでクラスは不要なんだけどね（話がずれて失礼）

ttp://www3.sppd.ne.jp/lena/map/index.htm
XHTML-Primaryって、どう思いますか？
なんとなく気になっただけなのですが。

dfnって近辺にその説明がある用語を差すんじゃないのか？

<p><dfn>みかか</dfn>とはNTTのことだ。

<dl>
<dt>みかか<dd>NTTのこと
</dl>

>>821
うまくやれば2.0への橋渡し役になるかも？
使いたいとは思わないが。

っていうか、IEがabbr対応してないせいで、
HTMLとかもdfn要素でマークアップしてるサイトって
結構見かける気がするんだが、
そのあたりはどう思う？
普及率ダントツのIEが対応していないから泣く泣く別の近い方法で代用すべきか、
そんなの無視してabbrでマークアップすべきか。
＃＃ちなみにうちはabbrを使うところはabbrでマークアップしてるんだが…

>>819
たしかにその通りなんだけど、その要素でマークアップする根拠がそれ
なりにあって、なおかつ、他の要素で代替できることが明らかな場合
（リストをdivでマークアップ等）や、明白な誤り（blockquoteでインデント
等）でさえなければ、「多くの文書でそのような使われ方をしている」という
ことは、とりあえず慣習として認めてもよいのでは？
（hr要素を「文書の区切り」として用いることを認める程度には）

ちなみに、仕様書には、emとstrong以外の「フレーズ要素は、技術文書に
おいて特別な重要性がある」と書かれているけれど、技術文書のみで
使用される、とは書かれていないし、技術文書らしからぬフレーズ要素の
用例も見られる（トルーマン、F.B.I.等）。

>>822
仕様書には「定義を行っている」としか書かれていないから、その定義の
説明は、必ずしも用語の近辺である必要はないのでは？
その用語が頻出する場合、そのすべての近辺に説明を置くというのは
現実的ではないし。

http://www.w3.org/TR/html401/struct/text.html#h-9.2.1
http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html401j/struct/text.html#h-9.2.1

>>824
俺もIEには構わずabbr使ってる派だけど、IE対策として略語をdfnで
マークアップするくらいなら、acronym使った方がいいと思う。
別に非推奨なわけではないし、将来的に非推奨になったとしても、簡単
にabbrに置換できるし（dfnだと、略語と略語以外の定義語の区別をする
のが困難）。
そうしてる人は、アンチ・マイクロソフトな人なのかな？

>>825

<p>
こないだ、みかかからの請求書を見たら電話代が減っていた。
</p>

ってのは「みかか」の定義を行っている文なのかと。

http://www.itmedia.co.jp/mobile/articles/0401/28/news063.html
既出だったらごめんなさい。
やっぱり携帯にCSSは重荷なんでしょうか。
なんだか時代を逆流する気がしてならないんですが。

というかメールだからCSSはムリなのか。
と自己レスです。

>>824
文脈次第なのでは？
HTMLを略語として示したければabbrで、
定義語句として示したければdfnでマークアップする、と。

>>827
ああ、誤読していました。すいません。

たしかに（邦訳の）「定義を行っている」という言葉は、そのように捉える
方が自然かもしれない。原文でも、「defining」（定義を行っている）とは
書かれているけれど、「defined」（定義された）とは書かれてないし。
英語は得意でないので、この「defining」が「その用語が、今まさに定義
を行っている」と解釈すべきなのかどうかはわからないけど、もしそう
だとしたら、dfnの使い方としてよく解説される、>>815のようなのは、
間違いということになるのかな……？

>>829
WAP2.0はCSS読むはず。

>>831
例えば、<dfn>Mikaka</dfn> があったとき、この表記(文の端切れ)の意図は、
文をマークアップする主体は作者ですから、
I define Mikaka (I give a definition of Mikaka) となり、
おそらく文章のどこかで Mikaka is ... となると思います。
このとき、dfn 要素の内容である Mikaka とは何か、を考えると、
それは Mikaka を主語にした受動態の文
Mikaka is defined by an author.
になると思います。
つまり、Mikaka は「定義される」語である、と捉えるのが妥当ではないでしょうか？

別の例として、strong要素の意図は、「作者は・その語を・強調する」であり、
「その語は・強調している」わけではないと思います。
これは日本語的な言い方なので一見自然に聞こえますが、
その語自体が強調の主体者ではないわけですね。

>>833
余談だが、「Mikaka」ではNTTとならないな。

別に離れたところに定義の解説があっても問題あんめぇ。
せっかくの Hypertext なんだから、
<a href="#definition"><dfn>みかか</dfn></a>
と書いておいて、章末に説明をまとめて書いておくとか。

ところで。
<dfn>みかか</dfn><a href="definition">*1</a>
ってのは、おまいら Strict 的にどう思いますか。

あ、>>835 の二例目は href="#difinition" のつもりでちた。
別に参照先が他のドキュメントでも、主旨としちゃ一緒だが。

>>835
どっちもいまいちかな。

dfnは一つしかないんだから、文脈によって定義語・被定義語を使い分けるってのは？
例えばXHTML2.0で、こんなことできないんかな。

<p><dfn href="#mikaka">みかか</dfn>とは<dfn id="mikaka">NTTのこと</dfn>だ。

>>838
> dfnは一つしかないんだから、
　なんで一個なん？

>>839
dt・dd（定義・被定義）のように二つないってことね。
定義ってのは定義するものとされるものがあって初めて成り立つのだから…

>>840
訂正。dt・dd（被定義・定義）の順でした。

…なんか変な気がしてきた。
RDFの仕様書で勉強してきます。

昨日 >>816 書いた後２ｃｈにアクセスしてなかったら、レスのびてる。
仕様書での dfn の定義があいまいなのが問題なのですかねぇ。
そうか、dt と dd とどっちにより近い意味なのかわからないと、
使えないですねえ。

>>820
私は、結局、dfn 使いたかった部分が、少々強調したい部分でも
あったので em に title つけて終わりにしました。
あと、スレ違いだけど、そのスタイルいいですねぇ。
パクっていいですか？

>>835
＞<dfn>みかか</dfn><a href="definition">*1</a>
リンクだけを抜き出して表にしたときに意味不明になりそう。

>>843
どうぞ。
このスタイル自体、昔見たどっかのサイトのパクリですのでｗ

>>844
うん、dfn を使わずに似たようなことをやってる文書はけっこう目にするが、前から違和感があった。
よく考えたら <a href="...">*1</a> って、<a href="...">ここをクリック</a> と大差ない記述だな。
どっちかというとアクセシビリティの話か。

<p>
<dfn><a href="#MIKAKA" title="*1">みかか</a></dfn>とか
<dfn><a href="#MOSEA" title="*2">もせあ</a></dfn>とかいう語がある。これらは……
</p>

<ol class="definition">
<li id="MIKAKA">NTT の隠語。</li>
<li id="MOSEA">MP3 の隠語。</li>
</ol>

あえて *1 *2... という表記にこだわると、こんなところか（ｗ
このへんの苦しさが「出版物っぽい見た目」にこだわることの限界のひとつなのかもな。

「出版物っぽい見た目」にこだわるのならtitleでリンクの説明を加えておくとか。

<dfn>みかか</dfn><a href="#definition" title="みかかの説明">*1</a>

>>846
むむ、それは Strict 的に可なのか？
あるいは、「ここをクリック」的な記述から脱しているのか？

や、折れ自身は出版物っぽさにこだわるつもりなんて毛頭ないんだわ。
ただ、時折見かける表現方法と Strict とを、どこかで折り合いをつけられないかってことを考えている。
# CSS の list-style みたいなもんだと思って、いっそ画像にしちまうか（ｗ

>>846
見た目ありきな時点でだめぽ

……と書いてから思ったが、この場合ハイパーリンクで結び付けられるべきなのは
<dfn>みかか</dfn> → NTTの隠語。
という二つの記述なのだから、そもそも *1 にだけアンカーを置くのはおかしい希ガス。
じゃ、以下のような記述ならどうなのかという疑問が発生。

<a href="#MIKAKA"><dfn>みかか</dfn>*1</a>

やっぱり違和感が消えないな。*1 って記述自体が邪魔者しかならんように感じる。
HTMLに id という仕組みが備わっているものを、わざわざ視覚的に明示するのは変だということなのだろうか。

Google 検索: dfn 例文
http://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dfn%20%E4%BE%8B%E6%96%87

朝っぱらからよく頭が回る事w

>>849
dfnがアンカーになれば問題ないのにね。

stricter的にはスタイルシートで

a:after { content : attr(title) ;}

として，

<dfn><a href="#MIKAKA" title="*1">みかか</a></dfn>

だろ．IEだめだけど．

titleが*1ねぇ・・・

<a href="#MIKAKA">注1</a>

じゃダメなん？

dfn って ins / del みたいに「なくてもマークアップに矛盾が生じない」ってのが理想な飢餓してきた。
<dfn><a href="#MIKAKA">みかか（*1）</a></dfn>
漏れ的にはこのへんが妥協線に思える。

>>850
俺はおまいみたいなﾋｷｰと違って早起きなのだ。
それはさておき、Google神への捧げものはなかなか(・∀・)ｲｲ!!
参考になった。�dｸｽ。

君たち、HTML4仕様書(別に他の仕様書でもいいが)のマーク付けにおいて
dfn要素がどのように使用されているかよくよく調べて見たまへ。

巽「ようやく俺と手四つで互角張れる男が現れたか
　　（力の入れ方とかそれなりにコツもあるけど
　　　人間ぶっ倒すにゃ関係無いけどな）」

すまん

？？？

最近、Strict DTDの意味も分からずに分かったように回答
している香具師が多いな

>>857
誤爆？
餓狼伝SS？

なにそれ

『餓狼伝』ってタイトルの小説（と漫画）。
グレート巽という名のプロレスラーが出てくる。
手四つってのは、プロレスの基本的な動作。
しかし、>>857のようなセリフは作中に登場しないため、SSと判断した次第。

成程

ヲタは所構わずだなぁ・・・

lintで
「HTTPレスポンスヘッダに指定されているメディアタイプ text/html は XHTML1.1 には指定しないようにしましょう。」
っていう警告がでるようになった

http://www.remus.dti.ne.jp/~a-satomi/
は警告出ない。どうしてだろう。

application/xml+xhtml指定してるんじゃ? たしかコンテントネゴシエーションをやってるとかって
そこの日記で書いてたような

>>868
そんなことより Strict なマークアップをマスターしなさい

>>867-869
下手な演劇を見ているようだ

>>868
× application/xml+xhtml
○ application/xhtml+xml

XML1.1が勧告になったっていうのに。

何が変わったのかを3行でまとめてくれ

1.0 third editionと1.1の違いもよろしく。

>873

>874

それが人に物を頼む態度か。

>>875
初心者は半年ROMってろ

>>876
じゃ、もまいが教えてやれよ(ｹﾞﾗｹﾞﾗ

「じゃ」とその後が繋がってない

>>878
バカか？初心者じゃねえやつなんだろ？
それとも、「漏れはXML1.1が従来のものとどう変わったのかも1.0 third editionと1.1の違いもわからないけど上級者だ」ってｋ？(ｹﾞﾗｹﾞﾗｹﾞﾗ

教えないよ

>>880
HTML初心者は５年ROMってろ

初心者って言葉を使いたがるのは自称・脱初心者。

もう放っとけ

>>882
言い出したのは>>876ばわけだが。

子供かお前は

今回の元凶は>>872でした。

早く教えてください

いろんな字が使えるようになった。
Namespaces in XMLが1.1に変ってURIの代りにIRIを使うようになって日本語が使えるようになったり、
一度宣言したネームスペースを取り消すことができるようになった。

ネームスペースの上書きってできなかったんだっけ？

>>889
上書きはできたが取り消しはできなかった。

>>890
無知な自分にサンクス。

或る画像に、キャプション（図1　○○に関する図）をつけたいんですが、
どんな風に記述したら良いですか？

後、ついでと言ったらなんですが、
htmlを書くとき、エディタは何を使ってらっしゃいますか？
気が向いたら教えてください。

>>892
>キャプション
とは、「表題」です。

大辞林 第二版 （三省堂）

　キャプション [caption]

　　(1)新聞・雑誌などで、見出し。また、写真・挿絵などにつける説明文。

　　(2)映画の字幕。

caption
1　（写真・さし絵の）説明（文）,キャプション.
2　（論説・章・節などの）見出し,表題;（映画の）字幕,スーパー,タイトル.
3　〔法〕（法律文書の）頭書:作成の日時・場所・権限などを示す.

Progressive English-Japanese Dictionary, Third edition © Shogakukan 1980,1987,1998
プログレッシブ英和中辞典 第3版 © 小学館 1980,1987,1998

なんでこんな展開に・・・

辞書房うざい

>>896
ｵﾏｴﾓﾅｰ

>>892
<img src="892face.jpg" alt="図1　892の顔写真" title="泣きそう">

notepad.exe

>>899
ダメダメじゃん。ネタ？

ネタ……だと思いたい。

>>894,895
htmlの定義と区別しなさい

そうやって噛み付くな。

<p class="caption">図X: hoge</p>
でいいんじゃないの？

HTML ソース上では
<img src="892face.jpg" alt="図1: 892の顔写真" title="図1: 892の顔写真">
で、DOM 使って >>904 みたいな p を直後に生成する。

というかimg要素にtitle属性は良くない
みたいな話がなかったっけ？

>>906
どこで読んだんだか知らないが、それを見て君はどう思ったのかを書いておくべきだ。

>>907
結局、title属性が良いのか悪いのか、
知ってるなら書いておくべきだろ？
書いてくれよ。

新手の教えて君だったか。

というかimg要素は良くない
みたいな話がなかったっけ？

>>907
オマエ馬鹿だろ。

>>911
やれやれ……俺の発言のどこで腹を立ててしまったんだ？

ﾌﾟ

構うだけ無駄

キャプションと図の関係を明示して(XHTML2.0だともうちょっと綺麗に書ける)
<p><img id="foo" .../>
<a rev="caption" href="#foo">図1 うんぬんかんぬん</a></p>

フォームコントロール以外にlabelを使うのはだめだけど
<p><img id="foo" .../>
<label for="foo">図1 うんぬんかんぬん</label></p>

longdesc(ただ、longdescはaltを補うものだからキャプションが常にlongdescで表現できるわけではない)
<p><img longdesc="foo_caption.html" .../></p>

定義その1
<dl>
<dt><img .../></dt>
<dd>図1 うんぬんかんぬん</dd>
</dl>

定義その2
<p><dfn><img .../></dfn>図1 うんぬんかんぬん</p>

ちなみにエディタはemacsでxml-lite-modeをつかってる。html直接書いたりxmlを書いてxsltで変換。

最後の1行ってどう考えても無関係な気が。

関係ないからこその「ちなみに」かと。
どっちにしろ不必要だと思うけどね。

>>916-917
>>892

へー、言ってるんだって。

>>919
何の話？

>>918

lintちゃんより。

＞現在HTMLとして受け付けられるメディアタイプは、text/html と application/xhtml+xml です。
HTTPレスポンスヘッダに指定されているメディアタイプと<meta>に指定されているそれが食い違っています。
しかし、そもそも application/xhtml+xml では、<meta http-equive> を記述すべきではありません


そうだったのか。知らなかったよ。。。＿|￣|○

>>922
おそっ！

lintちゃんが対応したのは最近だからな。＜おそ

metaは殆どつけてないから気付かなかった _no

>>907
超遅レスでもうしわけないが、ソース
www.kanzaki.com/docs/html/htminfo-alt.html#img-title

個人的にはなんとも思わなかった。
HTML Techniques for WCAG 2.0が勧告になってから考えればいいや、と。

>>926
要は、altとtitleの両方があったら、両者の区別が分かりにくく
なるという話でしょ?

でも、altは画像の代替情報であって並列する情報ではない。
titleは付加情報で並列する情報。

WinIEはaltをツールチップで表示するので、ここに並列する
付加情報を書く人が多いけど、これは本来間違いのはず。

結局は、WinIEの実装が悪いせいで、分かってない子ちゃんが
大量発生してるってだけで、title属性は悪くないだろ。
実際、この部分には反対意見が出ているようだが。

W3CもXHTML 2で
<img src="foo">baa</img>
みたいに仕様を変えればいいのにねえ

>>928
そんだったら object でも良いわけで

>>929
剥げ同。

しかし、object要素とtable要素は必須属性多いから面倒くさいなぁ。

img要素の代用としてのobject要素ならdataとtypeが入ってれば問題ないんじゃない？

フラッシュとかだと属性やparam要素が増えて面倒だけど、それはまぁ、
そういうものを埋め込む以上必然な訳で。

imgは廃止してもいいと思うけどな
なんでW3CはXHTML2で、中途はんぱに互換性ひきずってるんだろ

>>932
XHTML 2.0 に img はないぞ?

>>930
objectの必須属性って何？

IEで表示するのに最低限いる情報かな

objectに仕様上の必須属性はないな

>>935
言いたいことは分からんでもないが、「必須属性」はSGMLやらXMLでは
定義がはっきりした用語なんだから、すくなくともstrictスレで
その発言はまずいんじゃね？

「心の必須属性」と呼ぼう。

ちょっと意見を聞きたいんだけど、
<a href="hoge"> </a> と一緒に <cite> </cite> 使ってる人いる？

>>939
ノ

>>939
a要素だけで参照の意味だから必要ないんじゃないの？と思った。

そのaの内容が参照元を表すならciteを一緒に使うのがHTMLの"仕様"。
使うかどうかとか、そういう問題じゃない。

>>941
aは単にリンクを作ったり、或いはターゲットになったりするだけで
「参照」の意味なんか微塵もないよ。

>>940-943
レスありがとう。
これからは、きっちり書く様にします。

>>943
href属性は超参照なわけだが。

> a要素だけで参照の意味だから――
<a> </a>

> aは単にリンクを作ったり、或いはターゲットになったりするだけで「参照」の意味なんか――
<a> </a>

> href属性は超参照――
<a href="hoge"> </a>

>>946
何が言いたい？

>>947
上の二つは「属性なしのa要素を指してる」とか言いたいんじゃねえの？

こんなときは仕様書ですよ。
http://www.w3.org/TR/html401/struct/links.html

>>949
こっちじゃない？
ttp://www.w3.org/TR/html401/struct/text.html#edef-CITE

ふと思ったが、<cite>と<q>って、どう違うの?
見栄えや使える属性以外の本質的な違い。

>>951
（ﾟДﾟ）ﾊｧ?

なんで>951みたいな香具師がここにいるのですか

>>942-943
> W3Cについて、より詳しくは
> <A href="http://www.w3.org/">W3CのWebサイト</A>をご参照ください。
仕様書でこういう例が出てるけど？

>>951
マジレス
citeは「引用元」qは「引用内容」

>>951
いいからジオシティーズの助け合い広場とか行ってろよ

●●についてはこちらを参照

という文章（こちらにリンク）を参照するときは、
こちら、をspanで括ってもいいかなぁ。title属性いれて。

>>957
そもそも「こちら」はタブー

>>958
いや、だからさ、
そういうはちゃめちゃな文章を引用するときの話だ。

>>955
仕様書には、
<cite> contains a citation or a reference to other sources.
とあるので、<cite> には「引用元」だけじゃなく「引用文」も
書けそうに思ったんだけど、じゃあ<q>との区別は?...と思って。

>>960
はっきりと「to other sources.」と書いてあるだろ？出所、ってことじゃねえか。

>>960
おまえ「俺とお前の馬」といわれたら、馬がいるだけなのか、俺と馬がいるのか判断できないタイプだな。

href は hyper-text reffer to かな？

>>961
あれ? この文の「or」は、
[a citation] or [a reference] to other sources.
と解釈するのか?
[a citation] or [a reference to other sources].
という解釈かと思ってた。

>>964
おお、962の意味が伝わったみたいでよかった。

<a href="http://www.w3.org/" > <!-- ここでリソースの場所を表して -->
<cite>W3C</cite> <!-- 閲覧者が見る文字列は cite でmark up --> </a>

こうだと思っていたが、>>954の言うとおりでもある。むぅ。

>>962
その一文だけじゃ判断できんぞ＿|￣|○

>>967
うん。できない。
こういう文章と同じだ、と思ってるんだろうと、言いたかったんだが中途半端だったな。

tableを中央揃えにしようと思ったんですが、CSS1では無理のようですね。
結局 <div align="center">にしました。
糞糞

>>969
table {
margin-left:auto;
margin-right:auto;
}

釣られちゃった

>>966
954だけど今までURIを参照するときはa要素のhref属性で、
その他を参照するときはcite要素と使い分けてた。
>>942-943見て、解説書等を調べたら
「a要素はその部分をリンクのアンカーにする要素です」って解説が多く、
確かにa要素だけで参照の意味との解説はなかった。
けど仕様書で>>954のような使い方してるし、どっちなんだろう？

Strict な HTML について語るスレッド ver.18
W3C 信者もそうじゃない人も投稿歓迎。でもHTMLの基礎知識は欲しいね。
sage進行推奨。

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

Strict-HTML スレッド17
http://pc2.2ch.net/test/read.cgi/hp/1068907834/

過去ログ・関連スレ >>2
勧告等・その他 >>3

■過去ログ
HTML1.0 http://pc.2ch.net/hp/kako/992/992708594.html
HTML2.0 http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
HTML3.0 http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
HTML3.2 http://pc.2ch.net/hp/kako/1018/10187/1018719800.html
HTML4.0 http://pc3.2ch.net/hp/kako/1022/10227/1022751972.html
HTML4.01 http://pc3.2ch.net/hp/kako/1028/10289/1028963710.html
XHTML1.0 http://pc3.2ch.net/hp/kako/1033/10332/1033282702.html
XHTML1.0 SE http://pc3.2ch.net/hp/kako/1037/10375/1037577389.html
Strict-HTML スレッド ver.9 http://pc2.2ch.net/hp/kako/1039/10399/1039974316.html
Strict-HTML スレッド 10 http://pc2.2ch.net/hp/kako/1045/10454/1045493217.html
Strict-HTML スレッド11 http://pc2.2ch.net/hp/kako/1048/10485/1048570237.html
Strict-HTML スレッド12 http://pc2.2ch.net/hp/kako/1048/10488/1048867117.html
Strict-HTML スレッド13 http://pc2.2ch.net/hp/kako/1050/10505/1050581113.html
Strict-HTML スレッド14 http://pc2.2ch.net/hp/kako/1055/10551/1055148679.html
Strict-HTML スレッド15 http://pc2.2ch.net/hp/kako/1059/10594/1059401790.html
Strict-HTML スレッド16 http://pc2.2ch.net/hp/kako/1064/10640/1064061327.html
Strict-HTML スレッド17 http://pc2.2ch.net/test/read.cgi/hp/1068907834/

■関連スレ
/* CSS･スタイルシート質問スレッド【27】 */ http://pc2.2ch.net/test/read.cgi/hp/1074845459/
【野望の】XHTML 2.0【王国】 http://pc2.2ch.net/test/read.cgi/hp/1028659057/
W3C信者に怒られそうなことを書くスレ http://pc2.2ch.net/test/read.cgi/hp/1071673655/

■勧告等
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/
XHTML 2.0 W3C (Working Draft) http://www.w3.org/TR/2003/WD-xhtml2-20030506/
ISO/IEC 15445:2000(E) ISO-HTML http://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) http://www.y-adagio.com/public/standards/jis_html/toc.htm
Extensible Markup Language (XML) 1.1 http://www.w3.org/TR/xml11
Namespaces in XML 1.1 http://www.w3.org/TR/xml-names11
Extensible Markup Language (XML) 1.0 (Third Edition) http://www.w3.org/TR/REC-xml
上記勧告の邦訳等 http://www.doraneko.org/webauth/

■その他
W3C http://www.w3.org/
HTML Working Group Roadmap http://www.w3.org/MarkUp/xhtml-roadmap/
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

とりあえず>>942-943待ちか。

>>954
前後に引用がなく、「要約」や「解説」がかいてあって、
「詳しくは○○を」ならa要素だけで問題ないし、
もし、引用があってその「引用元を示す文字列」がcite要素に格納されていないなら
・a要素が引用の参照元を示す手段としてciteの代わりになるのか？
・cite要素は「あってもなくてもいい要素」なのか？
（例えば全ての略語がabbr/acrnymに格納されていなくても即座に仕様違反にはならない）
という事になる。

単に「くわしくは○○を」にciteが使われていないだけでは、aによりcite不要とはいえない。
また、本件の場合、「そもそもW3Cのソースに対してW3Cが解説を行っている場合、
引用ではなく単なる転載ではないか？」と言う疑問も残る。

というわけで、前後の文脈読まないとなんともいえないので具体的にどの
URLでその例が出ていたかおしえてください。

あと、a要素が（引用などによるciteの持つ意味の「参照」の代わりになる）
という主張ならa要素の定義からソースキボンヌ。

例えW3C自身がそういう使い方をしていても、aの定義なければそれは単なるcite抜け
ということもある。
（例えば以前W3Cは自身のトップページをテーブルレイアウトしていたのは有名な話だ）