Strict-HTML スレッド18

1 ：Name_Not_Found：04/02/14 02:25 ID:cYHTmnOH

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

過去ログ・関連スレ >>2
勧告等・その他 >>3

2 ：Name_Not_Found：04/02/14 02:27 ID:???

3 ：Name_Not_Found：04/02/14 02:30 ID:???

■勧告等
HTML 4.01 ttp://www.w3.org/TR/html401/
XHTML 1.0 ttp://www.w3.org/TR/xhtml1/
XHTML Basic ttp://www.w3.org/TR/xhtml-basic/
XHTML 1.1 ttp://www.w3.org/TR/xhtml11/
XHTML 2.0 W3C (Working Draft) ttp://www.w3.org/TR/2003/WD-xhtml2-20030506/
ISO/IEC 15445:2000(E) ISO-HTML ttp://www.purl.org/NET/ISO+IEC.15445/15445.html
JIS X 4156 (JIS-HTML) ttp://www.y-adagio.com/public/standards/jis_html/toc.htm
上記勧告の邦訳等 ttp://www.doraneko.org/webauth/

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

4 ：Name_Not_Found：04/02/14 03:38 ID:???

>1
乙

5 ：Name_Not_Found：04/02/14 09:14 ID:???

>1
乙彼

6 ：Name_Not_Found：04/02/14 10:03 ID:fNm3EIQd

994 名前：Name_Not_Found[sage] 投稿日：04/02/14 01:16 ID:???
cite要素は“引用の参照元”だろ
ただの“参照”ではない

995 名前：Name_Not_Found[sage] 投稿日：04/02/14 01:17 ID:???
>ほぼ全てのリンクはcite要素と共に用いなければ誤りということになってしまう。
a要素に関して語る前に、まずcite要素を調べたら?

7 ：Name_Not_Found：04/02/14 11:37 ID:???

>>6
そんで何が言いたいの？　前スレの流れからすると、落とし所としては
１：a要素が(引用などの)参照の意味も持っているので、a要素があればcite要素は
かならずしも必要ない。
２：a要素は(引用などの)参照の意味を一切持っていないので(引用などの)参照の
場合は必ずciteを使わねばならない。
３：a要素は(引用などの)参照の意味を一切持っていないが、citeも必ずしも
(引用などの)参照の場合は使わねばならないわけでもないので、a要素だけでもいい。
４：citeは引用などに限らず広義に参照の意味を持つので一般にa要素とペアになるべき。
５：citeは引用などに限らず広義に参照の意味を持つが、必ずしも必要でもないので
引用など参照の意味を強調したい場合のみつければよく、いちいちa要素につけなくてもよい。

こんな感じか？
＃ちなみにこの場合のa要素はハイパリンクの起点を指すものとする。

8 ： ◆FoxMX6a/hk ：04/02/14 11:37 ID:???

× 引用の参照元
○ 引用元、出典
……ではないのか。参照元は自ドキュメントになっちまわないか。
a 要素はハイパーリンクを用いた参照ではあるが、引用とは直接関係しない。
引用された箇所があって、その出典を明記する際に cite 要素を使う、で FA？

9 ：Name_Not_Found：04/02/14 11:48 ID:???

一連の文書群の中で、次の文書を参照するときには引用とは言わないんじゃない？

<a href="http://foo.com/bar.html">第二章「StrictなHTMLを記述するために」</a>
みたいな。
こういうのは cite 要素いらないと思うんだけど。

10 ：Name_Not_Found：04/02/14 11:50 ID:???

>>7-8
どうもcite要素を「引用の参照」限定だと勘違いしていた人間が
掻き回した感があるが、結論はそういうところじゃないかね。

11 ：Name_Not_Found：04/02/14 12:03 ID:???

そもそもanchor hyper referenceだし。

12 ：Name_Not_Found：04/02/14 13:33 ID:???

でも、引用なんかの出展の明示の意味での「参照」にはa要素は代理として
つかえないよね？（確認）

とむしかえしてみる本番

13 ：Name_Not_Found：04/02/14 13:55 ID:???

>>12
>>7-8

14 ：Name_Not_Found：04/02/14 15:22 ID:???

>>12
当店は本番禁止ですので。

15 ：Name_Not_Found：04/02/14 15:36 ID:???

>>6
ｹﾞﾗｹﾞﾗ

16 ：Name_Not_Found：04/02/14 16:02 ID:???

てst

17 ：Name_Not_Found：04/02/14 16:25 ID:???

a要素って物理要素でしょ？

18 ：Name_Not_Found：04/02/14 16:40 ID:???

その根拠は?

19 ：Name_Not_Found：04/02/14 17:31 ID:???

>>17
工エェ(´Д`)ェエ工

20 ：Name_Not_Found：04/02/15 02:49 ID:???

>>17
なるほどー。
確かにリンク部分が青くなって下線が引かれるから、物理要素だよねー。

というか、マジでそう思っていないだろうな、おい。

21 ：Name_Not_Found：04/02/15 06:15 ID:???

<abbr title="World Wide Web Consortium"><a href="../glossary/#w3c">w3c</a></abbr>
<em><font size="6">SUGEEEEEE!</font></em>

22 ：Name_Not_Found：04/02/15 11:39 ID:???

>>17
以後は、これ使っとくと良いよ。
<font color="blue"><u></u></font>

ネタに(ry

23 ：Name_Not_Found：04/02/15 12:19 ID:???

a要素って「繋がり」を示してるだけでそれがどんな「繋がり」かを表現できないんですけど、
これってb要素が「太い」を示してるだけで

24 ：Name_Not_Found：04/02/15 12:47 ID:???

a要素のないHTMLなんて、ガーリックの乗ってないステーキだよ。
HyperTextじゃなくなっちゃうし。

25 ：Name_Not_Found：04/02/15 12:50 ID:???

>>23
>どんな「繋がり」かを表現できない

relは？

26 ：Name_Not_Found：04/02/15 13:16 ID:???

revもあるな

27 ：Name_Not_Found：04/02/15 13:16 ID:???

ﾏﾄﾓに使ってるﾔｼは見たことないけどな

28 ：Name_Not_Found：04/02/15 16:30 ID:???

普通のレベル下がったねこのスレ。
仕様書読まないで思い込み語るのが増えた。

29 ：Name_Not_Found：04/02/15 16:31 ID:???

×普通の→○普通に

30 ：Name_Not_Found：04/02/15 16:56 ID:???

Valid-HTML

31 ：Name_Not_Found：04/02/15 17:48 ID:???

Valid な HTML について語るスレッド ver.18
W3C 信者もそうじゃない人も投稿歓迎。でもHTMLの基礎知識は欲しいね。
sage進行推奨。

32 ：Name_Not_Found：04/02/15 18:00 ID:???

>>28
ｽﾄﾘｸﾀｿの啓蒙活動の成果でしょう。
Strictが自分で仕様書を読めるユーザ層にしか知られていなかった以前に較べ
ｽﾄﾘｸﾀｿによる初心者向けの解説でStrictを知った
自分で仕様書を読めないユーザ層が増えてきているということだ。
Strictの普及が進めば、レベル低下を感じる場面は今後も増えると思われ。

33 ：Name_Not_Found：04/02/15 18:32 ID:???

CSS質問スレでも正しく使われてるCSSを「それはおかしい」と突っ込む奴がやたら増えた。
中途半端なレベルの解説サイトが増えたんだろうか？

34 ：Name_Not_Found：04/02/15 19:36 ID:???

>>33
解説サイト自体そんなに増えてはないと思われ
その半端な解説を読んだ香具師が増えただけかと

もしくは、そんな香具師が暴れてるか

35 ：Name_Not_Found：04/02/15 20:22 ID:???

解説を半端に読んだ香具師が
日記や掲示板等で伝言ゲームをやる場面は増えてるかもな。

36 ：Name_Not_Found：04/02/15 21:16 ID:???

URIかなんかで画像の一部分が指し示せるとイメージマップとかがきれいにかけそう。

37 ：Name_Not_Found：04/02/15 21:32 ID:???

迷惑な話だ

38 ：Name_Not_Found：04/02/15 21:40 ID:???

>>36
SVG とかなら ID 振ってできると思うけど。

39 ：38：04/02/15 21:40 ID:???

いや、ID 振るまでもなく XPointer 使えば可能か

40 ：Name_Not_Found：04/02/15 22:20 ID:???

IDNですら(ﾟ⊿ﾟ)ｲﾗﾈって声があるのにIRIなんて使われるんだろうか

41 ：Name_Not_Found：04/02/16 01:55 ID:???

>>40
まぁ Namespace Name としては使われるんでないの？
RDF とか OWL とかで語の定義したりする時には便利だと思うよ。

# HTML/XHTML の話題じゃないけど。

42 ：Name_Not_Found：04/02/16 11:46 ID:???

>>6
>>23
(　´,_ゝ`)ﾌﾟｯ

43 ：Name_Not_Found：04/02/17 02:37 ID:???

>>40
すでにいくつかのUAでは先取り実装してるやん

44 ：Name_Not_Found：04/02/18 22:33 ID:???

定義リスト DL以下DT、DD タグについてなのですが、
必ずしもDDタグの中身がDTタグの”説明”とは言えないような場合、
やはりマークアップと言う意味からは不適切になってしまうのでしょうか。

<DT>A</DT><DD>A'</DD><DD>A''</DD>
<DT>B</DT><DD>B'</DD>
<DT>C</DT><DD>C'</DD><DD>C''</DD>

のように、対になる要素として使うような場合です。

DL要素の意味合いがいまいち釈然としないのですが、
用語とその説明と言われると、HTMLタグの中ではどうも意味合いの狭い印象を持ってしまって。

45 ：Name_Not_Found：04/02/18 22:51 ID:???

>>44
＞DL要素の意味合いがいまいち釈然としないのですが、
発言者（ＤＴ）と台詞（ＤＤ）でつかってもいいとか実際仕様自体が
釈然としないので、一対になったリスト状のもので、他に適切な要素がなければ
DLをつかっても「直ちに間違いとはいえない」程度の認識で宜しいかと。
（DLで正しい、ともいえませんが）

ちなみに、DTとDDは１対１の方が好ましいので
＞<DT>A</DT><DD>A'</DD><DD>A''</DD>
これは
<DT>A</DT><DD><p>A'</p><p>A''</p></DD>
とか
<DT>A</DT><DD><ol><li>A'</li><li>A''</li></ol></DD>　←順番関係ないなら ul
のほうが「より」好ましいかとおもいます。

46 ：Name_Not_Found：04/02/18 23:13 ID:???

> DTとDDは１対１の方が好ましいので
知らなかった・・・仕様書読んでくる。

47 ：Name_Not_Found：04/02/18 23:21 ID:???

まあそんなことは書いてないがな。
むしろ DT → DD の順で出てこなければならない、とさえ書いていない。
（この辺については何度か議論されたけど。）

48 ：Name_Not_Found：04/02/18 23:49 ID:???

書いてなかった。
まあ、仕様書もオーサ任せなところあるからなあ。そこが面白いんだけど。
時間があるときに過去ログ漁ってみます。

49 ：Name_Not_Found：04/02/19 00:23 ID:???

まあしかし、1対1の方がわかりやすいことは確かだと思うけどな

50 ：44：04/02/19 08:08 ID:???

>>45-49
親切な解答ありがとうございます。
やはり結構グレーな部分なのですね・・・。

うーん、とりあえず、仕様書を自力で読めるように頑張らねば・・・

51 ：Name_Not_Found：04/02/19 08:16 ID:???

>>50
英語版読んでるのか？

52 ：Name_Not_Found：04/02/19 09:00 ID:???

>>51
おめーはロシア語版を読んでんのか？

53 ：Name_Not_Found：04/02/19 09:02 ID:???

>>52
いやいや、自力で、って言うから「日本語訳版もあるよ」と暗に言いたかっただけで。

54 ：Name_Not_Found：04/02/19 09:13 ID:???

時代はエスペラント語

55 ：45：04/02/19 09:55 ID:???

>>46
ごめん、仕様にはそんなこと書いてない。

ただ、書いてないが故に解釈がやたら曖昧になるのでノウハウとして
DTとDDは一対で書いた方が誤謬の余地が少ない、というようなことを
言いたかったのだが、俺の書き方だと仕様に書いてあるように読める。

正直、スマンかった。

56 ：46：04/02/19 11:46 ID:???

いえいえ。
最近、無意識にマークアップするようになっててさ。
仕様書読んだのもけっこう前のことだし、俺が忘れてんのかなと思って。

久々に自分の中でのマークアップルールを見直してみます。
一貫してないと、管理も面倒だしね。

57 ：44：04/02/19 12:13 ID:???

DTに対して複数のステータスがある場合に、
DDを複数用意してクラスで属性を分ける、というような使い方を見たことがあるので、
DDは複数あってかまわないものだと思ってました。

>>51
あー、いや、常々教授から「原文を読まないと何も分からん」と怒られてるので（英語読めないのに）、
ついその癖が・・・

58 ：Name_Not_Found：04/02/19 15:38 ID:???

こうやって伝言ゲームが広がって行くわけか。
俺も前の彼女が飯作るとか言って、いきなり出てきたのが皿の上のウンコてんこもりで、
「今まで隠したけど、私そっち系なの。食べて」
って言われた時は、瞬間的にマジでこいつとは違う星で生活したいと思ったよ。
つうか、嘘だと思いたいよ、今でも。
ぜんっぜん普通の女の子だと思っていたのに、前振りなしでウンコ食べてって言われてもさ。
「あのね、いつか話さなければいけないし、どうせわかる事なんだし、多分凄く驚いてると思うけど、
うん、冗談とかじゃなくて、私、好きな人には食べて欲しいの。勿論○○のも私食べるよ。全然嫌じゃないし。」
俺「……何言ってるの？」
「やっぱ、驚いた？私もね、黙っていようと…」
この辺りで速攻で玄関に行って外に出て走って帰った。
あの皿のウンコと臭いが目と鼻に焼き付いて、半年くらいの付き合いだったけれど
走馬灯のように思い出されて、俺がキスしたあの口でウンコなんてあいつ食っていたのかって
思うと、馬鹿みたいだけど涙が止まらなくて、駅から電車なんだけど車中でもずっと泣いていたよ。
周りのこととか全く気に出来なかった。
何度か電話してきたけど二度と話さなかったし、一度だけ部屋の前で帰ったらあいつが待っていたけど、
「もう二度と来るな」とだけ言って部屋に入った。それきり何も。
だから修羅場って言う感じではないが、俺には皿ウンコの存在が
それ以上考えられない修羅場といえば修羅場だった。

59 ：Name_Not_Found：04/02/19 16:11 ID:???

それ電2（現在は2箱？）経由で見たよ。
ちゃんと転載元スレを記しておくように。

60 ：Name_Not_Found：04/02/19 22:07 ID:???

HTML4.01の勧告書より

Here is an example with multiple terms and descriptions:

<DL>
<DT>Center
<DT>Centre
<DD> A point equidistant from all points
on the surface of a sphere.
<DD> In some field sports, the player who
holds the middle position on the field, court,
or forward line.
</DL>

61 ：Name_Not_Found：04/02/20 00:32 ID:???

仕様書の例を見たら、

・<DT>が連続する時は、同じ意味の語であるべき。
・<DD>が連続する時は、そのすべてが、直前の<DT>の語に
　対する説明であるべき。

とも読めるのだが。つまり、<DT>と<DD>は多対多の関係だが、
「連続する<DT>」と後続の「連続する<DD>」が1対1の関係と。

62 ： ◆FoxMX6a/hk ：04/02/20 01:05 ID:???

>>61
「同じ意味」と絞りきってしまえるのかなあ。
同音異義語を dt で複数示して、それを単一の dd で説明したりするのは、だめ？

63 ：Name_Not_Found：04/02/20 01:46 ID:???

>>61
漏れもそう解釈してるけど、
DD要素がブロックレベルを入れられるから、まったく無関係なら複数のDD要素、
それぞれに関連がある（同じものの説明だ、ってことじゃなくてね）と自分が思うならパラグラフ、ってやってるな。漏れの場合。

64 ：Name_Not_Found：04/02/20 21:18 ID:???

XHTML 1.0のstyle要素・script要素で、CDATAセクションを使おうと
思ったが、IEなどではちゃんと解釈してくれないので、次のようにしてみた。
<style type="text/css">
/* <![CDATA[ */
...(CSSの中身)...
/* ]]> */
</style>
<script type="text/javascript">
<![CDATA[
...(JavaScript)...
// ]]>
</script>
WinIE5.5、Mozilla、NN4で問題なく閲覧できることを確認した。
Mozillaは、text/html, application/xhtml+xmlの両方で確認した。

ここで、3つの疑問がわいた。
1. 上記の例は、文法的に正しいか
2. 上記の書き方をして問題を起こすUAはないか
3. 検索エンジンで検索したとき、CDATAセクションの中身が表示されたり、
HTML本体が解釈されなかったりする問題はないか

誰か分かる人はいるでしょうか。

65 ：64：04/02/20 21:22 ID:???

>>64
外部ファイルにしるというツッコミは却下の方向で。
ある1文書のみに適用するスタイルシート・スクリプトを想定しています。

66 ：Name_Not_Found：04/02/20 21:29 ID:???

ストリクターなら黙ってIE捨て…というツッコミも却下？

67 ：Name_Not_Found：04/02/20 21:58 ID:???

ある一ファイルにのみ適用するのでも外部ファイルにした方が
いいと思うが。

68 ：Name_Not_Found：04/02/20 22:27 ID:???

>>64
少なくとも文法的には正しいよ。2. と 3. については知らん。
漏れは取り敢えず >>67 に一票。

69 ：Name_Not_Found：04/02/20 22:34 ID:???

>>64
おれも１には問題がないように思われる。
２に関しては個別のバグスレを参照してもらわないと、バグの網羅なんか
できないし、３に関しては、それこそ検索エンジンのコードを見るか、
あるいは、検索結果として問題が表面化するまで分からない話。

スレ違いとまでは言わないが、少なくともここの住民には
答えられない質問だと思う。

70 ：Name_Not_Found：04/02/20 22:39 ID:???

type="text/javascript"
が正しいとか正しくないとかは(ry

71 ：Name_Not_Found：04/02/20 22:51 ID:???

W3Cが例示としてそのtype="text/javascript"をつかってるからなぁ…。

application/x-javascript だと動かないUAもあるし。（IEとか）

72 ：Name_Not_Found：04/02/21 23:52 ID:???

Another HTML-lint使ってて思ったんだけど、
INS要素, DEL要素内にP要素を含めないってのは間違いじゃない？

73 ：Name_Not_Found：04/02/22 00:08 ID:???

>>72
<P><INS><P>…</P></INS></P>

こういうことしてない?

74 ：72：04/02/22 00:18 ID:???

ごめん、HTMLバージョンが強制的に「ISO/IEC 15445」になってた。
採点画面で気付くべきだった＿|￣|○

75 ：Name_Not_Found：04/02/22 12:33 ID:???

>>74
人を疑う前に自分を疑え。

76 ：Name_Not_Found：04/02/26 02:56 ID:???

自サイトを全部401strict+cssでリニューアル中。
レイアウトの関係でcss切って見ると目次→タイトルになっちゃう

77 ：76：04/02/26 03:14 ID:???

って、それってぜんぜんstrictじゃない事に気付いたんで
何とか修正します。
position:relativeの動きに納得いかねー。

78 ：Name_Not_Found：04/02/26 03:25 ID:???

「目次→タイトル」の意味がわからないとは言えるわけ無いよな。

79 ：Name_Not_Found：04/02/26 08:36 ID:???

画面最上部にパンくずリストみたいに目次つくったら、
要素の出現順として

<h2>目次<h2>
<ol>・・・</ol>

<h1>Web Site のタイトル</h1>

ってな感じになったから、ページ上部に目次を表示するために
構造変えてCSSを勉強中ってことだろ。

その発想や行為は間違ってないと思うのでがんばってつかぁさい >> 76

80 ：Name_Not_Found：04/02/26 15:24 ID:???

それなら定義リストで遣った方が良いような。

<dl>
<dt>目次</dt>
<dd>～</dd>
</dl>

81 ：79：04/02/26 16:17 ID:???

>>80
いや、おれ >>76 じゃないから、具体的などんなマークアップか、
またどんな目次なのかはしらないんだけどね。

ちなみに俺なら一般的な小説の目次なら hn - ol って構造にするし、
順序があまり関係ないエッセイなら　hn-ul。

周辺の見出しレベルと上記 hn がそろわない場合は dl をつかう。

82 ：Name_Not_Found：04/02/26 16:24 ID:???

>いや、おれ >>76 じゃないから

言われなくとも分かってます。
>>76の悩みが>>79のようなものだとすれば、
>>80で良いだろって感覚で書きました。

83 ：79：04/02/26 16:41 ID:???

>>82
ん～。仮に>>76の言っている「目次→タイトル」が >>79 に俺が書いた
ようなものなら、やっぱり dl が h1 より前に来る構造はどうだろう？

目次の内容が h1 に属さない、h1 を包括するような目次ならそれでも
いいかもしれないけど、一般的にはやっぱり h1 よりあとに目次はくるものじゃね？

とくに見栄えの為のレイアウトなら。

84 ：76：04/02/27 00:24 ID:???

自分の書き方が悪かったようでごめんなさい。

で、スタイルシートを生かすと下のように表示され、

────────────────────
　　　　　　　　　　　　　　　　　　　　　<p>注意</p>
　　背景　ヽ(･∀･)ノ　　　　　　　<p>カウンタ</p>
　　　　　　　　　　　　　　　　　　┌──────┐
　　　　　　　　　　　　　　　　　　│<h3>目次</h>│
. <h2>サブタイトル</h2> 　　 │　　　　　　 │
　　<h1>メインタイトル</h1>.　│　　　　　　 │
┌──────────┐..│　　　　　　 │
│<h3>更新情報</h3>. 　 │..│　　　　　　 │
│. 　　　　　　　　　　　　│..│　　　　　　 │
└──────────┘..│　　　　　　 │
┌──────────┐..│　　　　　　 │
│<h3>お知らせ</h3>..　　│..│　　　　　　 │
│. 　　　　　　　　　　　　│..│　　　　　　 │
└──────────┘..│　　　　　　 │
.[バナー]. [バナー]. [バナー].. └──────┘
　 ┌────────────────┐
　 │　　 <address>連絡先</address> 　　│
　 └────────────────┘
────────────────────

85 ：76：04/02/27 00:25 ID:???

スタイルシートを切ったりテキストブラウザ等で見ると

<h1>メインタイトル</h1>
<h2>サブタイトル</h2>
────────────────────
<p>注意</p>
<p>カウンタ</p>
────────────────────
<h3>更新情報</h3>
────────────────────
<h3>お知らせ</h3>
────────────────────
<h3>目次</h>
────────────────────
[バナー]
────────────────────
<address>連絡先</address>

となるよう、かつ、ユーザがフォントサイズを変えたり
ウインドサイズを変えたりしても、大きなレイアウト崩れを起こしたり
横スクロールバーが出るような事がないようにしました。
またh1～h3は画像ですが、スタイルシートを切った場合は文字が出るように
しました。

現行の自サイトはテーブルを使いまくりなんですが、
更新の度に文章以外に悩む部分が多すぎ、結果更新が滞って
このままじゃイカンという事でHTML4.01＋CSSで書き直す事にしました。

86 ：76：04/02/27 00:27 ID:???

× このままじゃイカンという事でHTML4.01＋CSSで書き直す事にしました。
○　このままじゃイカンという事でHTML4.01Strict＋CSSで書き直す事にしました。

87 ：Name_Not_Found：04/02/27 01:04 ID:???

誘導してみる
http://pc2.2ch.net/test/read.cgi/hp/1061741473/

88 ：Name_Not_Found：04/02/27 01:43 ID:???

<h1>メインタイトル</h1>
<h2>サブタイトル</h2>

これは良いのか？　何か違う気がするんだが。

89 ：Name_Not_Found：04/02/27 02:24 ID:???

>>88
違うな。

90 ：Name_Not_Found：04/02/27 02:51 ID:???

<h1>メインタイトル</h1>
<p id="subtitle">サブタイトル</p>

を提案。しとく。

91 ：Name_Not_Found：04/02/27 07:07 ID:???

<h1>メインタイトル
<em class="subtitle">サブタイトル</em></h1>

こうして、display:blockとかじゃダメ？

92 ：Name_Not_Found：04/02/27 07:09 ID:???

>>91
サブタイトルも含めてh1要素なんだ、という考え方ならあり。
そうじゃないのにそうするのはなし、と俺はそう考えたわけです。

93 ：Name_Not_Found：04/02/27 09:06 ID:???

機械的に解析するとこういう構造になるのかしら。

<h1>メインタイトル</h1>
<section>
<h2>サブタイトル</h2>
<p>注意</p>
<p>カウンタ</p>
<section>
<h3>更新情報</h3>
</section>
<section>
<h3>お知らせ</h3>
</section>
<section>
<h3>目次</h3>
</section>
</section>

94 ：Name_Not_Found：04/02/27 10:16 ID:???

>>91
なんで、メインタイトルよりサブタイトルの方が
強調されてるんだ

95 ：Name_Not_Found：04/02/27 10:40 ID:???

>>94
筆者が伝えたいから。

96 ：Name_Not_Found：04/02/27 12:03 ID:???

>>84 を見ると「メイン」の上に「サブ」を表示したい
ようだけど、この「メイン」と「サブ」はどういう関係
なんだろうか? 例えば、タイトル周りが、

世紀末救世主伝説
北　　斗　　の　　拳

こんな感じと考えると(例が変ですまん)、

<h1>北斗の拳</h1>
<h2>世紀末救世主伝説</h2>

とマークアップしてスタイルシートで上下逆転させるのは
違和感を感じる。

<h1>世紀末救世主伝説<em>北斗の拳</em></h1>

か、

<p>世紀末救世主伝説</p>
<h1>北斗の拳</h1>

のような気がする。

>>76 の書きたい「メイン」と「サブ」の関係が分からない
から何とも言えないけど。

97 ：Name_Not_Found：04/02/27 13:02 ID:???

<h1>甲子園</h1>
<h2>平成１６年度春季全国高校選抜野球大会</h2>

98 ：Name_Not_Found：04/02/27 14:10 ID:???

<h1>XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)</h1>

<h2>A Reformulation of HTML 4 in XML 1.0</h2>

<h2>W3C Recommendation 26 January 2000, revised 1 August 2002</h2>

99 ：76：04/02/27 17:42 ID:???

皆さん、色々とありがとうございます。

メインとサブの関係については私も悩み、違和感を感じつつもw3c.org等の
ソースを見て先の形にしたのですが、やはりStrict的ではないのですね。

実際のタイトル等を今ここでは晒せませんが、意味的な点も考慮して
例を上げるなら
<h1>Boeing 747/777 <em>整備マニュアル</em></h1>
といった感じなのですが、スタイルシートを切った場合を考慮すると
<p>Boeing 747/777</p>
<h1>整備マニュアル</h1>
の方がしっくりくるかも知れません。

<body>直下に<h1>を持ってくることを意識しすぎたようです。

100 ：Name_Not_Found：04/02/27 17:45 ID:???

<font size="7">100ｹﾞｯﾄｫ!!</font>

101 ：Name_Not_Found：04/02/28 01:12 ID:???

Transitional な100ゲットはご遠慮ください

102 ：Name_Not_Found：04/02/28 01:29 ID:???

hnを文字を大きくするために使わなくなっただけでも、>>100は成長したものですよ。

103 ：Name_Not_Found：04/02/28 11:14 ID:???

次はspanかstrongか

104 ：Name_Not_Found：04/02/28 15:10 ID:???

blockquoteかも知れないぞ

105 ：Name_Not_Found：04/02/28 15:28 ID:???

strongはいいんじゃねーの？

106 ：Name_Not_Found：04/02/28 15:45 ID:???

>>105
どう読むと良くない、とよめるのか？

107 ：Name_Not_Found：04/02/28 16:06 ID:???

blinkとかmarqueeとか

108 ：Name_Not_Found：04/02/28 16:28 ID:???

こんな話で少し盛り上がるすとりくたーさんたち

109 ：Name_Not_Found：04/02/28 16:38 ID:???

110 ：Name_Not_Found：04/02/28 17:13 ID:???

id="100%E3%82%B2%E3%83%83%E3%83%88"

111 ：Name_Not_Found：04/02/28 18:09 ID:???

id="GET100"

112 ：Name_Not_Found：04/02/28 20:32 ID:???

idは数字から始まっちゃダメよ

113 ：Name_Not_Found：04/02/28 21:29 ID:???

書き換えてしまえ
<!ENTITY % id.attrib "id NMTOKEN #IMPLIED">

114 ：Name_Not_Found：04/02/29 08:28 ID:???

>>113
ふははは、重複させてやる！
<p id="100">100ゲッツ</p>
<p id="100">100ゲッツ</p>

115 ： ◆FoxMX6a/hk ：04/02/29 08:58 ID:???

ﾜﾗﾀ
id の意味ねーよ！

116 ：Name_Not_Found：04/02/29 09:05 ID:???

117 ：Name_Not_Found：04/02/29 15:28 ID:???

118 ：Name_Not_Found：04/02/29 21:38 ID:???

>>114
これでどうだ
<dd>This attribute assigns a name to an element.
This name <del>must</del> <ins>doesn't have to</ins> be unique in a document.</dd>
ttp://www.w3.org/TR/html401/struct/global.html#adef-id

ちなみにNMTOKENなのでこの妥当性制約も無しだ
ttp://www.w3.org/TR/REC-xml#one-id-per-el

119 ：Name_Not_Found：04/02/29 22:19 ID:???

そんなくだらない事で語るお前らが大好きだ

120 ：Name_Not_Found：04/03/01 14:49 ID:???

<SpAn StYlE="font-size:100px;">ﾈﾀがないんだよ</sPaN>

121 ：Name_Not_Found：04/03/01 15:54 ID:???

↑とりあえずもまえはしね

122 ：Name_Not_Found：04/03/02 11:41 ID:???

LupAn

123 ：Name_Not_Found：04/03/02 15:41 ID:???

2ch{ display: none }

124 ：Name_Not_Found：04/03/02 20:43 ID:???

invalid

125 ：Name_Not_Found：04/03/02 22:35 ID:???

>123
微妙にスレ違いの気もしなくも無い

126 ：Name_Not_Found：04/03/03 02:27 ID:SH3RKH2r

pre要素ないにbig要素とかだめだよね
じゃあ
これは？

<pre>
古池や
<em>かわず</em>飛び込む
水の音
</pre>

pre em{font-size:300%;}

cssも絡むけど、いちおうpre要素内に文字の大きさがことなるような
挙動をさせていいのかstrictの概念からお知らせください。

127 ：Name_Not_Found：04/03/03 09:58 ID:???

>>126
ストリクト的には全然問題ない。

整形済み(pre)の「意味」の内容として大きい文字(big)と言う「意味」が
混入するのが問題なのであって、

整形済み(pre)の「意味」の内容として強調する(em)「意味」が在っても
かまわないし、「結果」として文字の大きさがどうなるか、というのは
HTML側の感知する所ではない。

128 ：Name_Not_Found：04/03/03 10:10 ID:???

>>126
とりあえず仕様は「好ましくない(discouraged)」としている。
まあ「してはならない」ではないので、構わないといえば構わない。
てか整形済みでないものを整形済みとしてマークしている、という意味でどうよ。

129 ：Name_Not_Found：04/03/03 10:52 ID:???

>>127
XHTML 1.1 で pre の内容に del, ins が記述できない件についての見解を求む。

>>128
ソースきぼぬ。

130 ：Name_Not_Found：04/03/03 11:12 ID:???

>>129
> *仕様*は「好ましくない
って言ってるんだからソースは仕様書でしょう。
ttp://www.w3.org/TR/html401/struct/text.html#edef-PRE

131 ：127：04/03/03 11:27 ID:???

「整形済み」の文章が「追加」「削除」されたら文字数も変われば、
改行位置も変わる。当然「整形済み」の意味が破壊されるから当然でしょう。

132 ：Name_Not_Found：04/03/03 11:36 ID:???

ねこめし日記
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/2003/04a.html#d05n02

133 ：Name_Not_Found：04/03/03 18:10 ID:???

>>129
<del><pre>元の整形済みテキスト</pre></del>
<ins><pre>訂正した整形済みテキスト</pre></del>
でいいのでは？

134 ：Name_Not_Found：04/03/03 18:47 ID:???

AAはどうしたらいい？
画像以外で。

135 ：Name_Not_Found：04/03/03 19:20 ID:???

俺は<pre class="AA" title="AAの代理になる文字列">…</pre>みたいにして
最低限の改行位置保証した後、CSS側でフォントの種類とかの指定をしてる。

とはいえ該当フォントが入ってなければ違って表示されるし、CSS無効なら
何やっても無駄なので、基本的にAAは（たとえば色情報が意味を持つ文書が
HTMLにそのまま移植するにはそぐわないみたいに）HTMLにそぐわないと
おもってる。

将来XHTMLへのSVGが一般的になったらSVGで埋め込むことになると思う、多分。

136 ：Name_Not_Found：04/03/03 21:42 ID:SH3RKH2r

ハトマルさんが
<pre><code>
を推奨してたのでpre内にcode入れてるけど
整形済みを整形しているのでこれはだめぽ？

137 ：Name_Not_Found：04/03/03 21:43 ID:???

>>136
>整形済みを整形
？

138 ：Name_Not_Found：04/03/03 21:45 ID:???

>>131
の意味です。
pre code{font-size:80%;}
とかしてるから
整形好きであるpreの中身をcode要素で整形し直してしまってます。

139 ：Name_Not_Found：04/03/03 21:48 ID:???

HTMLとCSSは担当分野が違うだろ

140 ：Name_Not_Found：04/03/03 22:02 ID:???

ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/text.html#h-9.3.4
のHTML仕様書に載っているのでHTMLでいいかと。
この文章はstyleを指定しないcode要素やpre code{font-weight:bold}はいいけど
pre code{font-size:larger;}は良くないですという意味ですかね？

141 ：Name_Not_Found：04/03/03 22:15 ID:???

>>140
たぶんそう。

行の高さやフォントのピッチが保持されていればたぶん大丈夫で、
破壊されちゃうとだめ、ということで。

逆に非常にまずいのが content やだろうな。なにせ、整形済みの文章の
文字が増えたり、改行しちゃったりするんだから。

…慌てて自分のサイトのCSSの pre q がどうなっているか調べている最中
ですが、何か？

142 ：Name_Not_Found：04/03/03 23:36 ID:???

あかんうちのサイトのpre strongはフォントサイズいじってた。
知らなかったぜそんなこと。

143 ：Name_Not_Found：04/03/04 00:21 ID:???

そう言えばqって勝手に引用符つかないか？
あと
<pre><big>松島や
ああ松島や
松島や
</big></pre>
もダメなら
<pre><em style="font-size:larger;">松島や
ああ松島や
松島や</em></pre>
もまずくね？pre要素が一旦計算した文字の大きさや文字間隔を中の要素で再計算させては
ダメな気がしないでもない。
仕様書にはそこまで書いてないようだけど。

144 ：Name_Not_Found：04/03/04 00:48 ID:???

>>143
書いとるようだが。

>また一定の行の高さと固定ピッチのフォントでレンダリングされたテキストの配置を保つことが意図されている。著者が、この挙動をスタイルシートによって変更することは、好ましくない。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/text.html#h-9.3.4

145 ：Name_Not_Found：04/03/04 00:50 ID:???

XHTML 2 なら blockcode があるけどねぇ。

146 ：Name_Not_Found：04/03/07 14:06 ID:???

右クリして「ソースの表示」で見てみると、
見事に文字化けしています。
何故でしょうか？

147 ：Name_Not_Found：04/03/07 14:17 ID:???

ソースを表示してるブツが悪い

148 ：Name_Not_Found：04/03/07 14:19 ID:???

>>147
他のサイトさんのは普通に表示されるのですが、
私のところだけは文字化けしてしまいます。
何か間違っているのでしょうか…

149 ：Name_Not_Found：04/03/07 14:20 ID:???

PC初心者板へ

150 ：Name_Not_Found：04/03/07 14:24 ID:???

>>149
わかりました。
すいませんでした

151 ：Name_Not_Found：04/03/07 15:16 ID:???

>>150
一応確認事項として、
HTMLファイルのコードと、meta要素にかかれたコードと、
browserで表示してるときのコードと、ソースを表示するソフトが
対応しているコードを調べてみることをおすすめする。

たとえば、HTMLファイルはEUCなのにmetaはJISになっていて、
browserはmetaを無視してEUCで表示してくれているが、
ソースを表示するツールはJISだとおもって化けてるとか、
HTMLファイルもmetaもEUCだが、ソースを表示するツールが
EUCに対応してなくて化けてるとかが考えられる。

この板の守備範囲はおおざっぱに
・HTTPで示されるコード
・HTMLのコード
・処理命令とかXML宣言で宣言してるコード
・meta要素で示されているコード
・各browser、オーサリングツール、ソース表示ソフトの相性、バグ
あたりなので、PC板の方で上記の問題となったらまたきてください。

152 ：Name_Not_Found：04/03/07 15:17 ID:???

つーかメモ帳が貧弱なだけでしょ？
確かUTF-8とかだと文字化けするよね。

153 ：Name_Not_Found：04/03/07 16:04 ID:???

>>152
NT 5.1 だけど文字化けしなかったよ

154 ：Name_Not_Found：04/03/07 16:47 ID:???

>>152
EUC-JPが化ける。

155 ：Name_Not_Found：04/03/07 18:19 ID:???

>>153
Win9x系だとメモ帳はShift_JISしか読めない

156 ：Name_Not_Found：04/03/07 18:26 ID:???

Win9x なんてもう存在しないよ

157 ：みー：04/03/07 22:20 ID:???

そんなこと言わないでくれよ

158 ：Windows3.1：04/03/07 23:15 ID:???

　　　／⌒ヽ
　　/　´_ゝ`）すいません、ちょっと通りますよ・・・
　　|　　　/
　　| /|　|
　 //　| |
　Ｕ　 .Ｕ

159 ：Name_Not_Found：04/03/08 00:33 ID:???

>>148
ジオで作ってると予想

160 ：Name_Not_Found：04/03/08 20:03 ID:???

A氏「・・・・」
B氏「・・・・」
A氏「・・・・」
B氏「・・・・」
といった感じの、淫タビューや会話形式はどのように書くとベター？

161 ：Name_Not_Found：04/03/08 20:07 ID:???

162 ：Name_Not_Found：04/03/08 20:15 ID:???

別にパラグラフでもいいだろうし。

163 ：Name_Not_Found：04/03/09 08:36 ID:???

>>160
<pre>A氏「・・・・」
B氏「・・・・」
A氏「・・・・」
B氏「・・・・」 </pre>

お前みたいな陳子の貸すにはこれが精一杯

164 ：Name_Not_Found：04/03/09 14:32 ID:???

(X)HTMLを正しく使っている方々に質問です。

フォームを使っての「入力画面」→「確認画面」→「完了画面」という３画面遷移のシステムで、
「確認画面」では、前の「入力画面」で入力した項目を表示する必要があります。

その「確認画面」での入力内容の表示に、どのようなタグ要素を用いればいいのか迷っています。
ここで表示される項目が、ゆくゆくは（システム内の他のページで）表示される内容になるので、

　　名前: <samp>山田太郎</samp>

とかでいいかな、と思ったんだけど、どう思いますか？
もっといいやり方、ありますか？

165 ：Name_Not_Found：04/03/09 14:45 ID:???

ttp://www.w3.org/TR/html401/struct/text.html#edef-SAMP
SAMP: Designates sample output from programs, scripts, etc.

166 ：Name_Not_Found：04/03/09 15:30 ID:???

>>164
特にmarkupしなくていいのでは？
俺なら dl-dt-ddで書くけど。

167 ：Name_Not_Found：04/03/09 15:40 ID:???

　吾輩は猫である。名前はまだ無い。
　どこで生れたかとんと見当がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。

↑のような文章を表示するとき、文頭のスペースの扱いってどうすればいい？
p{text-indent:1em;}
がスマートかな、とも思うんだけど、和文の文頭スペースって見栄えを整える為にあるんじゃないような気もするし。

168 ：Name_Not_Found：04/03/09 15:58 ID:???

検索しろ
過去ログ読め

169 ：Name_Not_Found：04/03/09 16:01 ID:???

>>167
それでいいです。

　段落の区切りに改行を入れて、開始時に１字字下げをおこなうのは、
日本の一般的な（たとえば原稿用紙などの）記述法であって、
HTMLの場合、段落を示す記号としてPタグを書く訳だから、改行したり、
字下げしたりする必要はない。

　よって、一般的な記述法とおなじ見栄えを求めるならHTML側ではなくCSSで
やるのが正解。

　たとえば朝日新聞の天声人語風に「我が輩は猫である」を書けば
＞▼吾輩は猫である。名前はまだ無い。▼どこで生れたかとんと見当
＞がつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた
＞事だけは記憶している。
となるが、これでも問題ないし、この切り替えはCSSの範疇、と言うことで。

170 ：Name_Not_Found：04/03/09 16:11 ID:???

>168
有難う。このスレ、長いし有用なのにまとめサイトないんだね。
作ろうかな。

>169
有難う。
段落の文頭は、スペースだけが来るわけじゃないんだね。
段落ごとに改行をしない書き方もあるわけだ。確かにCSSで切り替えた方がスマートだ。

171 ：Name_Not_Found：04/03/09 16:31 ID:???

まとめサイトが無いのは意見がまとまってないから

172 ：Name_Not_Found：04/03/09 17:37 ID:???

まあでも同じネタを繰り返し蒸し返すスレなので
既出ネタと話題の出たスレ・レス番号をまとめるだけでも有用な気はする。

173 ：Name_Not_Found：04/03/09 19:36 ID:???

そして、まとめサイトのマークアップに関して延々と議論することになるわけだ

174 ：Name_Not_Found：04/03/09 22:53 ID:???

原稿用紙の記述法って言葉が出ましたけど、
だったら lang="ja" なら数字やアルファベットは全角で書くもんですか？
「HTML」ではなくて「ＨＴＭＬ」、「3月9日」ではなく「３月９日」みたいに。
「THE BEATLES」なら「ザ・ビートルズ」とか。
あんま関係ないかな。

175 ：Name_Not_Found：04/03/09 22:54 ID:???

関係無い

176 ：Name_Not_Found：04/03/09 22:59 ID:???

>>175
ありゃ、そうでしたか。
あんま原稿用紙の使い方とか考えなくていいのかな。

177 ：Name_Not_Found：04/03/09 23:04 ID:???

本当、HTMLって文系に弱いねぇ。
理系はvarとかsampとか色々要素が用意されているのに。

178 ：Name_Not_Found：04/03/09 23:25 ID:???

文系理系とか言ってる時点で

179 ：Name_Not_Found：04/03/09 23:28 ID:???

>>174
XMLの場合は
http://www.y-adagio.com/public/standards/xml/tutr.htm

＞3.2 全角英数字及び半角片仮名
＞全角英数字(JIS X 0208のラテン文字用図形文字)及び
＞半角片仮名(JIS X 0201の片仮名用図形文字)については,
＞その使用を避ける。XMLの規定は，Unicode 2.0の互換性文字の
＞使用を避けることを薦めている。
と、ある。

180 ：Name_Not_Found：04/03/09 23:32 ID:???

>>174
全角/半角という概念自体が本来フォントやスタイルで制御することだと思われ。
現行のUnicodeでは互換用途にコードが残ってはいるけれどね。

>>177
想定外の用途で不都合があってもごくあたりまえのことかと。

181 ：Name_Not_Found：04/03/09 23:54 ID:???

つーか、ユニコードの、「日本語と中国語の似てる漢字を１つにしゃえ」とか
そういうのみるとHTMLは…というより、コンピュータ関連が一般的に
文系に対して「理解がない」。
弱いとか、強いじゃなくて、あんま気にしてない風。

これからコンピュータがより汎用的になって、理系の道具から、一般的な
道具になればそんなこともなくなるとおもうけど、まぁ過渡期の産物だから。

182 ：Name_Not_Found：04/03/10 00:32 ID:???

こういう書き方って別に良いですよね？

<ul>
　<li>
　　<h2>○△□</h2>
　　<p>～～～</p>
　</li>
　<li>
　　<h2>●▲■</h2>
　　<p>～～～</p>
　</li>
</ul>

183 ：Name_Not_Found：04/03/10 03:07 ID:???

>>181
単に、単純で扱いやすい性質の情報の処理から実現していき
その類の情報が理系分野が扱う情報に比較的多いというだけの話だ。
文系分野が扱う情報は複雑で取り扱いの困難なものが非常に多い。
そして、うまく扱えない未解決の問題があるということと
その問題に対して開発側の理解がないかどうかは全く別の話だ。
# 小数演算の丸め誤差と小数演算への関心の有無とは全く関係がない。

184 ：181：04/03/10 08:45 ID:???

>>183
理解と技術的困難がごっちゃになっている、指摘には同意。
確かにすべてそうであるかのように書いた俺が悪い。

が、一方で、ユニコード検討時に日本語と中国語の区別、というか
２バイトではなくて、まず制御コードで文字のバイト長を可変にして
その後可変バイトであらゆる文字を表す、という制御を行うのは
十分に技術的に可能であって、それをせず、今後の拡張性を
確保しないで「ひとまとめ」にしたのは単なる「無理解」。

たとえその時は（実用的なＣＰＵの速度などから）困難でも
拡張可能な形でコードの空間を予約し説けばいいものをしていなかったのは
技術的困難ではない。
（ただし、これは、理系が文系に無理解なんじゃなくて、アメリカ人が
漢字に無理解なのかもしれないが）

185 ：Name_Not_Found：04/03/10 09:49 ID:???

>>182
ISO-HTMLで不許可

186 ：Name_Not_Found：04/03/10 10:29 ID:???

そんなあなたはUCS-4をUTF-8で利用することで最大6オクテットの文字を体感できます！

187 ：Name_Not_Found：04/03/10 10:32 ID:???

html4.01で許可

188 ：Name_Not_Found：04/03/11 22:38 ID:???

>>186
UTF-8、最新の RFC (RFC 3629) で 5&6 オクテット表現は削られてしまいましたよ。
UTF-8 を使う時は 4 オクテット表現で表せる範囲 (2^21、U+0000～U+1FFFFF、0～31まで32面、
2097151 コードポイント) までにしろってさ。

189 ：Name_Not_Found：04/03/11 22:43 ID:???

残りはどーすんですか？

190 ：Name_Not_Found：04/03/11 22:52 ID:???

あら本当だ

191 ：Name_Not_Found：04/03/11 23:04 ID:???

>>189
32面以降の文字を使いたい時は UCS-4 で書けってことじゃない。

192 ：Name_Not_Found：04/03/11 23:34 ID:???

HTML4/XMLだったら文字集合に入ってさえいれば文字参照使えばまあ記述不能ではないし。

193 ：Name_Not_Found：04/03/11 23:44 ID:???

Extension Bの文字はUTF-8で書けないのね……。

194 ：Name_Not_Found：04/03/15 15:06 ID:???

著者の連絡先(メールアドレス)を記述するのって、どうやるのが一番なんだろ。

1)<address>を使って本文中に書く
2)<meta name="author" content="...">で書く
3)プロファイルを用意して<link rev="made" href="...">で書く
4)プロファイルは用意せずに<link rev="made" href="...">で書く

ぐらいが思いつくけど、みんなどうしてる？

195 ：Name_Not_Found：04/03/15 15:15 ID:???

>>194
それぞれの方法にそれぞれの用途が存在し、万能にして唯一の方法はない。
…というありがちな結論しか出ないと思うが。
用途と記述法の色々な事例を採取したい、ということ？

196 ：Name_Not_Found：04/03/15 16:56 ID:???

今まで何も書いてなくてやっぱり書いといた方がいいかなと思い始めたんで、
他の人は何を考えてどの方式を選んでるのか聞いてみたいなあ、と。
htmllintにかけたら<link rev="made">を書けって言われたけどmadeって
HTML4.01で規定されてないよなあ、などと思ったのもあってここで聞いてみました。

197 ：Name_Not_Found：04/03/15 17:06 ID:???

うちは1と2と4

198 ：Name_Not_Found：04/03/15 17:07 ID:???

3 ) の場合、プロファイルって何をどの様に書けばいいの？
特に書式とかは決まってないのかな？

199 ：Name_Not_Found：04/03/15 17:40 ID:???

200 ：Name_Not_Found：04/03/15 17:58 ID:???

<b>200ｹﾞｯﾄｫ!!</b>

201 ：Name_Not_Found：04/03/15 17:59 ID:???

（´・∀・｀）ﾍｰ

202 ：Name_Not_Found：04/03/15 18:03 ID:???

参考までに、プロファイルを自前で用意している人の例。
http://diary.noasobi.net/0311.html#diary_031112

203 ：Name_Not_Found：04/03/19 19:22 ID:???

信者ﾏﾀﾞｰ?

204 ：Name_Not_Found：04/03/19 20:26 ID:???

>>203
なんかStrict軽視する発言したり
間違ったマークアップの話をしてみ

205 ：Name_Not_Found：04/03/19 20:49 ID:???

img要素のwidth,height属性は、視覚型UAに限った用法を想定しているからStrictじゃない、と聞きました。
ISO-HTMLなどではwidth属性等を仕様しないようですし。

では、
・input要素のsize属性
・textarea要素のcols,rows属性
はどうでしょう？
昨日、picobbsのHTML出力部を書き換えながら考えたのですが、纏まりませんでした。

206 ：Name_Not_Found：04/03/19 20:55 ID:???

>サイトのHTML文法をチェックできます。
>ウチは82点でした（・∀・）
>
>…まあ、実際はビルダー様使ってるから高得点なんでしょうけどね。
>若干手書きで弄ってる分、悪くなっている悪寒（つД｀）

207 ：Name_Not_Found：04/03/19 22:43 ID:???

>>205
このスレの住人であれば、当然仕様書は読んでいるよね?

img要素について。
>13.7.1 幅と高さ
>属性定義
>width =length [CN]
> 画像・オブジェクトの幅を上書きする。
>height =length [CN]
> 画像・オブジェクトの高さを上書きする。
>指定されている場合、 width 属性と height 属性は、ユーザエージェントに
>対し、画像やオブジェクトの本来の幅や高さを指定値で上書きするよう指示
>する。
width属性やheight属性は、レンダリングに直接影響を与えるものではなく、
画像そのもののサイズ(CSSの用語で言うなら、内在寸法)を上書きするものだと
解釈している。そのため、width,heightはstrictとして問題ないと思われる。

この投稿には自信なし。反論歓迎。

208 ：Name_Not_Found：04/03/19 22:59 ID:???

>>207の続き。
input要素のsize属性。
>この幅はピクセル値だが、type属性がtextまたはpasswordの場合は文字数を
>示す整数を値とする。
type="text","password"の場合は、maxlength属性と同様、文字数を示す。
物理的な属性ではなく、論理的な属性と位置づけられる。

textarea要素のrows,cols属性。
>rows =number [CN]
> この属性は、【同時に】表示するテキスト行数を指定する。
>cols =number [CN]
> この属性は平均的文字幅【に基づく文字数】で、表示領域の幅を指定する。
これも、input要素のsize属性と同じく、文字数を表す論理的な属性。
仕様上も必須となっている。

209 ：Name_Not_Found：04/03/19 23:16 ID:???

>>205
君の中での「Strict」の定義をまとめればそれなりの答えが出るだろう。

まあそれらが物理的表現を示唆する属性であることは確かだ。

>>207
> オブジェクトが画像である場合、これは伸縮される。ユーザエージェントは
> オブジェクトあるいは画像を、著者が指定する幅や高さに合致するよう
> 伸縮させるのに最善を尽くす必要がある。ここで、大きさがパーセントで
> 指定されていた場合、これが、画像、オブジェクト、アプレットの元々の
> 大きさに対する比率ではなく、利用可能な垂直・水平方向の空間に対する
> 比率であることに、注意されたい。
とあるわけだが、それでもUAに対するレンダリング指示ではないのか？

フォームコントロールのサイズ指定にしても、
単位が文字数や行数だからといって論理属性にはならない。
その目的は視覚的レンダリングへの指示であり、物理表現に変わりない。

HTML4Strictはもう6年前の仕様だ。漏れはそのへんは
主な視覚UAがそういう指定を必要としていた時代の遺物だと考えている。
そういうものがあっていいとも思ってるけどね。

210 ：Name_Not_Found：04/03/22 13:24 ID:???

http://blog.livedoor.jp/jigokuhen00/archives/169129.html

211 ：Name_Not_Found：04/03/22 14:04 ID:???

>>210
構造化テキストの活用法がどれだけ普及していないかがよく解る文章だな。

212 ：Name_Not_Found：04/03/22 14:10 ID:???

>>210
妙に自信たっぷりなのが痛々しい…

213 ：Name_Not_Found：04/03/22 14:16 ID:???

(　ﾟдﾟ）ﾎﾟｶｰﾝ何か広がってるみたいだし

214 ：Name_Not_Found：04/03/22 14:20 ID:???

ネタだよな?
ねたダヨナ?

215 ：Name_Not_Found：04/03/22 14:51 ID:???

これでも見てもちつけ。
http://tonys.k-free.net/

216 ：Name_Not_Found：04/03/22 15:39 ID:???

W3Cさんのコメントへのレスでも書いたけど、
俺は単に見た目が好きだから使っているだけ。

W3CのHTML仕様書など全く気にもしていない。
自分のページの動作検証もWin版IE6以外では行っていない。

217 ：Name_Not_Found：04/03/22 15:41 ID:???

スレ違い。

218 ：Name_Not_Found：04/03/22 16:26 ID:???

>>216
本人？騙り？

219 ：Name_Not_Found：04/03/22 16:27 ID:???

>>218
>>210参照

220 ：Name_Not_Found：04/03/22 17:24 ID:???

210を見ただけでは本人かどうかは確認できない。

221 ：Name_Not_Found：04/03/22 17:28 ID:???

>>220
…>>216は>>210のサイトからの転載ってことだよ

222 ：Name_Not_Found：04/03/22 17:30 ID:???

http://blog.livedoor.jp/jigokuhen00/
↑こっち貼った方がよかったな

223 ：Name_Not_Found：04/03/22 17:32 ID:???

「使う際は各自の判断で」
http://blog.livedoor.jp/jigokuhen00/archives/266984.html

224 ：Name_Not_Found：04/03/22 17:42 ID:???

見出しにposition:relative;とか使えば、fieldsetに似たようなデザインも作れるんでないか。

225 ：Name_Not_Found：04/03/22 21:20 ID:???

citeって単なるblockquoteのインライン版じゃないの？
そうじゃなかったら今まで書いていたのが全部間違えていた予感

226 ：Name_Not_Found：04/03/22 21:36 ID:???

>>225
citeは出展。引用はq。

<p>以上、<cite>広辞苑</cite>より。</p>

みたいな？

227 ：Name_Not_Found：04/03/22 22:06 ID:???

blockquoteのインライン版はqだよな

228 ：Name_Not_Found：04/03/22 22:06 ID:???

あ、226と被ってるや。しかも226の方が詳しいし

229 ：Name_Not_Found：04/03/22 23:47 ID:???

blockquote{
color: #066;
background: #fff;
border: #399 1px solid;
padding: 0 15px 5px 15px;
}
.cite{
margin: 0;
position: relative;
top: -0.5em;
left: 0;
text-indent: 0;
}
.cite cite{
color: #066;
background: #fff;
font-style: normal;
padding: 0 0.5em;
font-weight: bold;
}

<blockquote cite="http://xxx.xx/" title="引用元">
<p class="cite"><cite>引用元</cite></p>
<p>引用文</p>
</blockquote>

230 ：Name_Not_Found：04/03/23 00:28 ID:???

>>229
<p class="cite"><cite>引用元</cite></p>

は、blockquoteの外に出したほうがいいと思うんだけど。

231 ：Name_Not_Found：04/03/23 00:50 ID:???

>230
外に出すべきだと言う人もいるし、中に入れるべきと言う人もいる
俺はどっちもアリだと思う

232 ：Name_Not_Found：04/03/23 01:06 ID:???

>>231
なんかエロい。

233 ：Name_Not_Found：04/03/23 01:07 ID:???

議論百出を見て余計わからなくなってみる。
ttp://mst.vis.ne.jp/cd/extra/www/cite_blockquote.htm

234 ：Name_Not_Found：04/03/23 02:14 ID:???

for属性みたいに関連付けできるとかならいいんだけどな。
それよりも、cite属性が表面に出る、ってのが解決に近いｷﾓ駿河。

235 ：Name_Not_Found：04/03/23 09:15 ID:???

<!ELEMENT blockquote (cite?, (%block;)*) >
こういう文書型だったらよかったのになぁ。

236 ：Name_Not_Found：04/03/23 11:05 ID:???

引用文が「内容として出典元を持っている」場合（要するに２重引用とかですな）、
引用文の出典と、引用の内容としての出典の区別が付かなくなるので、
俺は外出しにしてる。

で、ボーダーラインなど、引用文の表示エリアの中に出典元を表示したい場合はCSSで。

237 ：Name_Not_Found：04/03/23 14:27 ID:???

MTとかはエセストリクターを世にばら撒いたわけだな
テーブルレイアウトやってろよ

238 ：Name_Not_Found：04/03/23 20:36 ID:???

　　　　へ　　　　　　　　　へ|＼へ　　　　　√￣|　　　　　　　　へ
　　　（　レ⌒）　　|＼　　（　|＼)|　|/~|　　ノ ,__√　　　／７　∠､　＼　.　　丶＼　　　　　　_　__
|＼_／　　／へ＿＼)　　 |　| 　 |　|∠　　|　|＿＿　　　|　/　　　!　　|　　　　|　|＿～、　　ﾚ' ﾚ'
＼_.／|　|／　　　＼　　 .|　|(￣　　＿）　|　　　　）　　|　|　　　 i　　|　へ_,/　　　　ノ　　　,へ
　　／　　／￣~ヽ　ヽ.　　 |　| フ　　ヽ、　ﾉ　√|　|　　　!　レﾉ　　|　　!.　＼_　　ー￣＿,ー~'　　）
　/　／|　|　　　｜　|　　　|　|（ノ|　|`､)　i　ﾉ　|　|　　　＼_ノ　　ﾉ　/　　　　ﾌ　!　（~~＿,,,,／ﾉ/
　|　|　 |　|　　　/　/　　　|　| .　し'　　ノノ　 |　|　　　　　　　/　/　　　　　|　|　　￣
　＼＼ﾉ　|　　/　/　　　 |　|＿＿＿∠-".　　 |　|　　　　　　ﾉ　／　　　ﾉ　|　　/（
　　＼＿ノ_／／　　　　（＿＿＿＿）　　　　　し'　　　　　ノ／　　　　　　/　/　　|　～-,,,＿＿
　　　　　∠-''~　　　　　　　　　　　　　　　　　　　　　　　　ﾉ／　　　　（＿ﾉ　　　～ー､､＿＿）

239 ：Name_Not_Found：04/03/23 21:11 ID:???

AAなんて物理表現で断ることころがもっともらしいぞ。

240 ：Name_Not_Found：04/03/23 22:47 ID:???

241 ：Name_Not_Found：04/03/24 01:44 ID:???

cite要素はblockquoteの外。
そんで、まとめてdivに入れる、とか。

242 ：Name_Not_Found：04/03/24 08:11 ID:???

そこまでDIV連発させてまで、何がやりたいんだ

243 ：Name_Not_Found：04/03/24 10:06 ID:???

任意の複数要素のグルーピング。

で、そこまでDIVを嫌って、どんな反応をきたいしているの？

244 ：Name_Not_Found：04/03/24 20:12 ID:???

本当はdivで纏めていった方が良いかなあと思いつつも、
ソースが見づらくなるのでやめてます。

245 ：Name_Not_Found：04/03/24 23:55 ID:???

俺の場合プログラムの中括弧みたいにdivがあった方が見やすいなぁ

function hoge()
{
　a = 1;
}

が

<div class="hoge">
　<a>1</a>
</div>

こんなイメージね。飽くまで俺の脳内だけど。

246 ：Name_Not_Found：04/03/25 00:10 ID:???

>>245
良くワカランが中にインラインしか入らないのなら
spanの方が良くないか？なんかもにょもにょする。

247 ：Name_Not_Found：04/03/25 00:16 ID:???

div {
h1
p
div {
h2
p
}
}

こーゆーこと？

で、こう？

div {
cite
blockquote {
p
}
}

248 ：Name_Not_Found：04/03/25 06:46 ID:???

<img src="aaa.png" alt="図 1: ○△□の図" />
とかいう風に画像を指定しているんですが、
画像の下に、実際に“図 1: ○△□の図”と表示させたいと思います。
どのように Mark-Up したら良いですか？

249 ：Name_Not_Found：04/03/25 07:35 ID:???

>>248
スタイルシートでやるんじゃね？
display:inline-table と content:attr(title); とかを組み合わせてなんとか。

250 ：Name_Not_Found：04/03/25 07:35 ID:???

content:attr(title) じゃなくて content:attr(alt) だった・・

251 ：Name_Not_Found：04/03/25 07:46 ID:???

>>249-250
なるほど。有り難う御座いました。

つまり、html としては、
<img src="aaa.png" alt="図 1: ○△□の図" />
の時点で十分であり、これ以上記述のしようがないわけですね。

スタイルシートでやる具体的な方法について、
調べてみることにしました。有り難う御座いました。

252 ：Name_Not_Found：04/03/25 07:51 ID:???

てめえで指定したスタイルシートが反映されるとは限らないんだから、
スタイルシートでやるのは間違いです。

253 ：Name_Not_Found：04/03/25 08:17 ID:???

>>252
>>251は

> html としては、
> <img src="aaa.png" alt="図 1: ○△□の図" />
> の時点で十分であり、

と言ってる。html としてはこれ以上どうしようもないでしょ。
それとも、視覚的にこう見えて欲しいから、という理由でマークアップしていくのか？

254 ：Name_Not_Found：04/03/25 08:30 ID:???

見た目の話をここですることの方が間違いだと思うガナ。
ブラウザの実装のためにマークアップ自体を変えるというのは
Strictな考え方じゃないと思う。

255 ：Name_Not_Found：04/03/25 08:32 ID:???

http://www.akatsukinishisu.net/itazuragaki/2001_10.html#ruby_for_Mozilla_3
この辺が参考になるかもしれん。

256 ：Name_Not_Found：04/03/25 08:41 ID:???

>>253
alt は代替テキストなんだから、src が有効な場合は出力されない。
その場合に、どれが図１になのか判らないのは問題だから、
外にキャプションが必要なのは明らか。

257 ：Name_Not_Found：04/03/25 08:44 ID:???

これが視覚的な意味しかないと思うのは間違いですよ。

258 ：Name_Not_Found：04/03/25 08:57 ID:???

title 属性でもいいんじゃないか

259 ：Name_Not_Found：04/03/25 10:02 ID:???

図に直接 "図1" って入れられないの？

260 ：Name_Not_Found：04/03/25 10:27 ID:???

blockquoteの引用元はhtml的にはcite属性以外表現しようがない、
というのと同質の議論な感じ。

261 ：Name_Not_Found：04/03/25 11:04 ID:???

>>256
画像無しでも文意が通じるテキストなら、HTMLとしては次のようになって、
見栄えはCSSの出番じゃないかと思う。

　<img src="aaa.png" alt="" title="図 1: ○△□の図" />

画像無しだと文意が通じないテキストなら、やはり外に出すしかないと思う。
例えば次のようにして、見栄えはCSSを使うのはどうか？

<dt>図 1: ○△□の図</dt>
<dd><img src="aaa.png" alt="" /></dd>

262 ：Name_Not_Found：04/03/25 13:57 ID:???

>>261
alt="" とするのは、飾りなど、画像自体が重要でないものに
対してだけにすべきだと思う。テキストブラウザでalt=""な
画像を落とそうと思うと、アクセシビリティも悪いし…。
多少冗長でもこんな感じか。

<dt>図1: ○△□の図</dt>
<dd><img src="aaa.png" alt="図1の画像" /></dd>

>>241
これも<dl>でやる手があるね。

<dt><cite>引用元</cite></dt>
<dd><blockquote>
.....
</blockquote></dd>

263 ：Name_Not_Found：04/03/29 10:15 ID:???

pc2事件で抜けた文の差分おくぞ
━━━━━━━━━━━━━━━━━━━━
264 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 19:30 ID:???
>>262
おお、なるほど。

265 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 19:40 ID:???
alt="図一の画像" とやるのはなんか
<img src="banner" alt="私のサイトのバーナー" title="もえちゃうもえちゃう" />
みたいな感じで気持ち悪い
266 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 19:52 ID:???
たとえがわかりにくい
267 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 20:03 ID:???
こうか？
<img src="SuiheiSen.jpeg" alt="これは水平線です" />
268 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 20:22 ID:???
画像offにしたときこれは水平線ですなんて表示されても意味分からんし。

264 ：Name_Not_Found：04/03/29 10:15 ID:???

269 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 20:51 ID:???
たとえば数学なんかで水平線とかが意味を持っているなら、あるいは
そういう代理文があっても良いかもしれない。

ちなみにおれは、>>252-253 （もわるくないけど）ちょいと異議あり。

常に（画像の表示の有無にかかわらず）解説が見えているべき場合は、
それはpとかでかかれていればいいし、その解説文があれば事足りるなら
画像に代理文字は必要ない、と俺は考える。

>>262 も決して悪くはないけど、本人が言うとおり冗長すぎる気がする。
270 名前： Name_Not_Found ：sage 投稿日： 04/03/25 (木) 21:14 ID:???
俺は>>262が良いと思う。冗長とも思わん。

━━━━ここまで━━━━━━━━━━

265 ：Name_Not_Found：04/03/29 11:07 ID:???

290近くまでけっこうな議論があったけど飛んじまったなあ

266 ：Name_Not_Found：04/03/29 11:26 ID:???

------------------------ここから-------------------------

271 名前：Name_Not_Found 投稿日：04/03/25 23:57 ID:???
実際262の記述の状態で閲覧したとしてそれで何が伝わるの？
>図1: ○△□の図
>　図1の画像
当然実装によるが、期待される表示は概ねこんな物だろう。
これって図自体の解説をなんもしてないよね。
「ここには画像表示可能なブラウザでは（たぶん）画像が表示されます。」
程度の印象を閲覧者に与えておしまい。これは「情報」としては非常に価値が低い。

画像でしか表現できないもので、代理の説明を入れることがそもそも困難なら
その旨が伝わる情報が簡潔にalt属性に書いてあればいいし、代理の文章が
かけるならalt属性にはそれが書かれるべきだし、その場合「図１」という
表現はおかしい（何せ文字情報なのだから）。

「このページはフレーム対応のブラウザでご覧下さい」と同じくらい
配慮に欠けた変な物ができあがっていると思うのだが。
272 名前：Name_Not_Found 投稿日：04/03/26 00:48 ID:???
<dt>図 1: ○△□の図</dt>
<dd>
<object data="aaa.png" type="image/png">
<a href="aaa.png">aaa.png</a>
</object>
</dd>

267 ：Name_Not_Found：04/03/29 11:27 ID:???

273 名前：Name_Not_Found 投稿日：04/03/26 01:12 ID:???
「図自体の解説をしていない」とかで無く、
例えば、図が何かを説明する為のものである場合はどうなの？

理系でﾚﾎﾟｰﾄ書く場合、
図の下には必ず「図1: ○△□」と書く必要があるんだけど。
因みに表の場合には表の場合には表の上に「表1: ○△□」とか書く必要がある。

言葉で（上手く）説明出来ない（説明しきれない）部分を
図を使って説明しようとしているのに、
「図自体の解説をしていない」とか言われてもなあ・・・

274 名前：Name_Not_Found 投稿日：04/03/26 01:13 ID:???
>>273
> 例えば、図が何かを説明する為のものである場合はどうなの？
　いや、つまるところそれを言ってるんだろ。
図ありきの文書ってのがそもそも、って。

275 名前：Name_Not_Found 投稿日：04/03/26 01:24 ID:???
HTMLでは必ずしも色情報はユーザーに届かない。
だから「この帳簿では必ず○○は赤字、××は黒字なんです。それが常識です」
と言われても、それ自体がHTMLにそぐわないので何らかの補足をする必要がある。

図もこれに同様、と言うだけ。

図が失われることがあり得ない、そもそもそんなことを想定してない紙ベースの
レポートの書き方を基準しても良いHTMLはかけない。

268 ：Name_Not_Found：04/03/29 11:28 ID:???

276 名前：Name_Not_Found 投稿日：04/03/26 01:26 ID:???
つまり>>273は、図云々以前にstrictな考え方を身につけるべきだな。笑止。

277 名前：Name_Not_Found 投稿日：04/03/26 01:57 ID:???
>>273
alt属性の意味判ってる?

278 名前：Name_Not_Found 投稿日：04/03/26 02:00 ID:???
しかし>>276はMarkup云々以前にレポートの書き方を身につけるべきだな。

紙ベースなら図が失われることがあり得ないとか思うほうが有り得ない。

279 名前：276 投稿日：04/03/26 02:05 ID:???
>>278
それは>>275に言ってくれないか？

280 名前：275 投稿日：04/03/26 02:36 ID:???
学術的な文章は頻繁に一部分が引用や転載がされるからその為に
図１とか明記して文章と図表などの関連性が失われないようにしておく
必要がありまたそういう規則が厳格化している、と言う意味であるならば
HTMLのHTはなんの略だか調べることをおすすめする。

そうでなくて単なる俺の考慮不足なら、具体的にどのような状況に関する
突っ込みなのか指摘を願う。

269 ：Name_Not_Found：04/03/29 11:28 ID:???

281 名前：273 投稿日：04/03/26 02:42 ID:VGtXLTb7
>>274
図、ありきの文書では無くて、
まず文書があって、その文書だけでは伝わりきらない部分、
或いは文書だけでは相手に伝わりにくい部分を
図で説明しているわけで。

そんな図について、
図自体の解説をしようもんなら、
本文そのまんまになる。

>>275
じゃあ例えば、
ﾚﾎﾟｰﾄとして最低限の体裁を失わない範囲内で
どのように Mark-Up すれば良いのか。

この前提に立てば、
>>262 の方法でも問題ないと思われますか？

>>277
その図が表示されないときを想定して用意する、
代替文（章）のことだ・・・理解していますが・・・

282 名前：Name_Not_Found 投稿日：04/03/26 02:43 ID:???
>>281
> 図、ありきの文書では無くて、
> まず文書があって、その文書だけでは伝わりきらない部分、
> 或いは文書だけでは相手に伝わりにくい部分を
> 図で説明しているわけで。
　それをHTMLでやろうとするからこうなる。

270 ：Name_Not_Found：04/03/29 11:29 ID:???

283 名前：Name_Not_Found 投稿日：04/03/26 02:52 ID:???
>>282
なるほど・・・

じゃあ例えば、
ﾚﾎﾟｰﾄとして最低限の体裁を失わない範囲内で
どのように Mark-Up すれば良いのか。

この前提に立てば、
>>262 の方法でも問題ないと思われますか？

284 名前：Name_Not_Found 投稿日：04/03/26 03:18 ID:???
流れをざっと読んだだけで見当違いならすまんが、概ねこうじゃないか？

1.imgですべてをまかなう
<img src="aaa.png" title="図1：地域と雨量の相関図" alt="地域と雨量の相関図" />

2.意味リストを使う
<dl>
　<dt><img src="aaa.png" alt="人口と雨量の相関図" /></dt>
　<dd>図1：人口と雨量の相関図</dd>
</dl>

俺はどっちでもいいと思うんだけど。

285 名前：Name_Not_Found 投稿日：04/03/26 04:03 ID:???
<a href="aaa.html">図1</a>

……いや、なんでもない。

271 ：Name_Not_Found：04/03/29 11:29 ID:???

286 名前： ◆FoxMX6a/hk 投稿日：04/03/26 04:11 ID:???
<p id="rain">
<a href="#pic1">地域と雨量の相関図について、図1 に示した</a>。
この図は、この地域における年間の降水量が（ｒｙ
<p>
<div class="pict_descriptions">
<img src="rain.png" longdesc="#rain" alt="地域と雨量の相関図" title="図1" id="pic1" />
</div>

↑基本はこうなる希ガス。
・図の説明は longdesc 属性で本文の該当箇所を参照する。本文からは a 属性で参照して、相互リンクになる。
・「図1」は画像に与えられたタイトルなので、title 属性が適当。
これに >>262 提唱の dl を組み合わせたら、冗長ではあるが納得できる範囲だと思う。
あるいは、「図1」を見出しと考えて、以下のようなマークアップもできるかもしれない。

<div class="pict_descriptions">
<hn>図1</hn>
<p>
<img 各属性は上に同じ />
</p>
</div>

272 ：Name_Not_Found：04/03/29 11:30 ID:???

287 名前：Name_Not_Found 投稿日：04/03/26 04:20 ID:???
図を別ページに追い出す意味がわからん。
アンカー使って別ページにするよりは>>284みたいにでもして同一ページ内
に納めればいいと思うんだが？

>>275はそりゃ色情報と意味は関連づけるために補完する必要があるが、
それとこれとは同一に扱えないと思われ。
例：<em>強調</em>
強調という"意味"を記述してあるのであって赤だの黄色だのは関係ない。

あえてアンカー使うのであれば
<a id="#Graph1">図1</a>
<img id="Graph1" src="aaa.png" title="図1：なんとか" alt="なんとかの図" />
ってやりゃあいいんじゃないの？

288 名前：Name_Not_Found 投稿日：04/03/26 04:22 ID:???
おっと微妙にかぶった？ｽﾏｿ

289 名前： ◆FoxMX6a/hk 投稿日：04/03/26 05:22 ID:???
今気がついた。
>>286 a 属性って何だよ＞俺 orz

290 名前：Name_Not_Found 投稿日：04/03/26 08:27 ID:???
>>283
「図でなければならない」文書をHTML文書にするのが無理があると思う。
その図を噛み砕いて「文字」にできるなら、あるいは可能かもしれないが。

少なくとも、画像を大前提としている時点で、HTML文書としては成立しない、と考えるのが自然ではないかな。

273 ：Name_Not_Found：04/03/29 11:30 ID:???

291 名前：275 投稿日：04/03/26 08:36 ID:???
>>287
>例：<em>強調</em>
>強調という"意味"を記述してあるのであって赤だの黄色だのは関係ない。
図に関しても図で何を伝えたいかをaltに書くべきなんであって、
図1だの表2だのは関係ない。

292 名前：Name_Not_Found 投稿日：04/03/26 12:34 ID:???
画像を前提するという解ならobject。

少し冗長だと思うのだが>>272説。

293 名前：Name_Not_Found 投稿日：04/03/26 13:01 ID:???
>ﾚﾎﾟｰﾄとして最低限の体裁を失わない範囲内で
>どのように Mark-Up すれば良いのか。
HTMLの性質上、例えば「ページ」の概念は失われる。
逆にHyperLinkにより従来のレポートでは有り得なかった
文書間の関連づけの概念が登場する。

そもそも従来のレポートの体裁を別メディアであるHTMLで保とうとするのが
ナンセンス。

従来のレポートの体裁をそのままに電子文書化したければHTMLではなくpdfに
するのがいいとおもいます（皮肉ではなく、かなりマジレス）

274 ：Name_Not_Found：04/03/29 11:31 ID:???

294 名前：Name_Not_Found 投稿日：04/03/26 13:22 ID:???
読み上げ式ブラウザで読んだ場合、 >>262 は
「図1　○△□の図。図1の画像」
となる。場合によって
「図1　○△□の図。"画像の代理情報です" (声色を変えて) 図1の画像 (声色の変更終り)」
なんて実装もあるかも知れない。

一方 >>272 の場合、
「図 1: ○△□の図　(リンクの声色で) aaa.png(リンクの声色終り）」
ってな感じになるだろうし、こっちも当然
「図 1: ○△□の図　"png画像の代理情報です" (リンクの声色で) aaa.png(リンクの声色終り）」
何て実装もあり得ると思う。

この場合、どっちの方が盲人に対するユニバーサル性が高いかと言えば、どっちもどっちな訳で。

勿論「図じゃないと表現できないから図を使って居るんだよ！」と言う主張は大変ごもっともな訳で
（例えば自分のイラストを発表したい、なんて絵描きサイトは「画像ありき」が前提だから
どうしようもないわな）その場合は「これは画像じゃないと伝わらない情報です。このページは画像が
見られない環境の人には不親切です」ってな解説をしっかりしているかどうか、というのが重要。
（その都度altでも良いかもしれないし、site単位でページのトップに１回だけ書いておくので済むかも知れない）

所で、確かW3Cの正式な(少なくともnoteレベルで)文章で「alt属性には電話越しにHTML文書を説明するとき、
あなたがその画像に関して電話の向こうにしゃべるなような説明をいれとけ」って話がどっかにあった
とおもうんだけど、どこか知ってる人いませぬか？　一応HTML4.01の仕様と関連リンクはみてみたんだけど
それっぽいのが見あたらなくて。

295 名前：Name_Not_Found 投稿日：04/03/26 14:17 ID:???
alt属性にはこんな感じで画像であることを含めて説明のようなものを入れておけばいいんじゃないのか
http://www.w3.org/TR/REC-CSS2/syndata.html#img-pixel1

275 ：Name_Not_Found：04/03/29 11:32 ID:???

296 名前：292 投稿日：04/03/26 14:22 ID:???
>>293
>従来のレポートの体裁をそのままに電子文書化したければHTMLではなくpdfに
>>248や>>283はそれをHTMLで再現する場合という発言をしているのでいきなりpdfに持ち込むのは少々強引かと。
といことで、改めてobjectを用いた方法を提唱したい。
画像を前提とした文書をHTMLで表現をする場合、現状としてobjectは相応しいかと。

>>294
>読み上げ式ブラウザで読んだ場合
これはブラウザ側の仕様でHTML側の問題ではないんだけどなー。

297 名前：Name_Not_Found 投稿日：04/03/26 14:33 ID:???
> 電話の向こうにしゃべるなような説明を
…なんか、以前ラジオから聞こえてきた
「それでは皆さんにお送りいただいたお写真をご紹介しま～す」
という文句を思い出すなあ。
女の子が投稿された写真の内容を説明して誉めてたけど
いくらなんでもその企画はチャレンジャー過ぎるだろと思った。

298 名前：Name_Not_Found 投稿日：04/03/26 14:58 ID:???
>>294
> 確かW3Cの正式な(少なくともnoteレベルで)文章
http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/#text-equivalent
"Quicktest!" の部分。

276 ：Name_Not_Found：04/03/29 11:32 ID:???

299 名前：Name_Not_Found 投稿日：04/03/26 15:01 ID:???
>>296
HTMLは「音声ブラウザ『でも』読まれる事を想定した仕様」なんだから、
HTML側で「あり得るとしている実装」で問題が発生するHTML文書は
HTML文書側の問題。

HTMLが「想定していない実装の結果」ならバグったブラウザで表示すれば
結果もバグるにきまってるだろｺﾞﾙｧでかまわんけど、そうでないなら駄目。

仕様は有る程度理解してるみたいだけど、HTMLの理念の方を勉強すれ。

300 名前：294 投稿日：04/03/26 15:06 ID:???
>>298
WCAGでしたか。ありがとう。

------------------------ここまで---------------------------

277 ：Name_Not_Found：04/03/29 11:51 ID:???

で、蒸し返すんだが、思うに図ありきのHTML文書と思ってるような。
論文にある図はあくまで本文の補完である事を忘れちゃいかんと思う。
(文系の論文はしらね)

例：
<p>
　このように<a href="#Graph1">グラフ</a>は右上がりの2次関数を描く。
　<img id="Graph1" src="graph1.png" title="図1：関係図" alt="○における×は2次関数を描く" />
</p>

278 ：Name_Not_Found：04/03/29 12:38 ID:???

>>263-276
おつ

279 ：Name_Not_Found：04/03/29 12:46 ID:???

>>263-276
乙

論文やら記事などの図というのは本文に書いてあることを図として表現したものです。
例えば

昨日の気温は10度、今日の気温は11度です。

と書いてある本文があって、それを見やすくするためにグラフで描いたものです。
つまり図というのは本文の表現の1つであり、本来は適切にマークアップされた本文からスタイルシートによって生成されるべきものです。
もちろんCSSではそのようなスタイルシートを書くことはできません。しかし例えばXSLTを使ってSVGを出力するようなスタイルシートであれば可能です。
元となるデータがほかの文章など外部にある場合はそこにa要素を使ってリンクを張ることになります。その場合リンクされたデータをインラインで表示するのはUAおよびスタイルシートの仕事でありHTMLで関与することではありません。

しかし既存のブラウザとの互換性を考える場合にはimg要素のlongdesc属性にその本文のURIを書き、altにはそれを短く要約したものを書くこととなります。
この場合本文とaltおよび画像そのもので情報が重複してしまいますので既存のブラウザとの互換性を考える場合にのみ使われるべきです。

これは論文や記事などの場合についての話ですがイラストサイトなどの場合は事情が違ってきます。
イラストサイトなどで公開されている作品は言語で表すことができないものを絵として表しているものですからそれをHTMLとして書くことはできません。
ここでimg要素やobject要素はあくまでHTMLページの1部として画像を埋め込むものなので絵をimgで埋め込むことはできません。そこでa要素を使って画像ファイルへリンクを張ることとなります。
この場合でもa要素によって参照されている画像をインラインに表示することはUAおよびスタイルシートの仕事であってHTMLの関与するところではありません。

どちらにしろimg要素を使う必要はありません。

280 ：Name_Not_Found：04/03/29 12:57 ID:???

差分の人、乙。
しかし久しぶりだな。
今年もよろしくお願いしますだ

281 ：Name_Not_Found：04/03/29 13:06 ID:???

>>279
その理屈でいくと
引用なんかもリンクすりゃ事足りるし同一ページに表示させるかどうかは
UAおよびスタイルシートの仕事であってHTMLの関与するところではないから
q要素/blockquote要素は使う必要なさげだな。

282 ：Name_Not_Found：04/03/29 14:52 ID:???

論文や記事には図/img要素は必要ないってのはさすがに言いすぎだろ。
ケースバイケース。

283 ：Name_Not_Found：04/03/29 16:40 ID:???

まあ*埋め込みである*必要はないのかもしれない。
「この顔見たら110番！」とか「この実験では被験者に次の図を見せ…」とか
論文・記事に図が必要であることは沢山あるだろうが。

グラフはそれ自体が「データや数式を空間表現したもの」であるので
それを根拠に全ての図がテキストの視覚化であるような言い方をされても困る。

284 ：Name_Not_Found：04/03/29 17:10 ID:???

>>281
そうですね。ただqやblockquoteで引用するものにはURIで表せないリソースも多いのでqおよびblockquoteは必要でしょう。

285 ：Name_Not_Found：04/03/29 20:21 ID:???

>>284
リソースがURIを持たなければ与えるまで。
q/blockquoteは原則的には不可欠なものではない。

286 ：Name_Not_Found：04/03/29 20:23 ID:???

必要最低限の引用にはblockquote/qは必須だろ？
機能絞る話ばかりじゃなくていかにしたらドキュメントが作りやすいかも考えようよ。

287 ：Name_Not_Found：04/03/29 20:40 ID:???

漏れは「必要ない」とは思ってますが「無い方がいい」とは思ってません。
q要素もblockquote要素もimg要素も。

288 ：Name_Not_Found：04/03/30 03:24 ID:???

で？

289 ：Name_Not_Found：04/03/30 07:06 ID:???

<hn>が一切入らないストリクト系文章ってあり得るの？
<p>だけとか
たいがいタイトルと同じ<h1>が入ったりするようだけど

290 ：Name_Not_Found：04/03/30 12:10 ID:???

>>289
「見出しのない文章」がありうるなら、余裕でありうるでしょうな。
# むかーしどっかで「題名無いんですけどtitle要素どうしましょう？」て
# 話があったような。

291 ：Name_Not_Found：04/03/30 13:01 ID:???

<title>無題ドキュメント</title>

292 ：Name_Not_Found：04/03/30 13:01 ID:???

>>285
<p>彼は<q>その通りです</q>と言った。</p>
といった場合。
実際の発言なら「ある時にあるところである人がした発言」といった風にURIを割り当てられるだろうが小説などの場合はそれ自体が1次情報源なのでURIで参照することはできない。

293 ：Name_Not_Found：04/03/30 14:03 ID:???

>>292
テキスト形式で無いリソース(図版や立体物、音声等)の場合は
それ自体が一次情報源であっても、そこだけ別媒体に変換・複製して
別途URIを与えた二次情報を参照することが行われている。
単純に可否だけを問うなら、引用でも同様のことは可だ。
(そうすべきである、という話ではない)

294 ：Name_Not_Found：04/03/30 14:46 ID:???

<q>にしろ<img>にしろ、そりゃ使わずに済ますことは可能だけど
そうした方が便利な時だけそうするべきだろ。
使った方が便利な場合はガンガン使うべき。
表現やマークアップのやり方はケースによって変わるのが当たり前。
なんでそう無理に一般化しようとするのかわからん＞最近の流れ

295 ：Name_Not_Found：04/03/30 15:09 ID:???

>>294
そりゃ解らんだろう。
「qやimgを使わずに済ますべきである」なんて話は誰もしてない。

296 ：Name_Not_Found：04/03/30 15:28 ID:???

掲示板を製作中なんだけど

<dl>
　<dt title="投稿者">名無し</dt>
　<dd class="time" title="投稿時刻">2002/01/01</dd>
　<dd class="url"><a title="投稿者：名無しのサイトへ" href="http://hoge">HOME</a></dd>
</dl>

このマークアップはありかな。
投稿者がいつ書き込んだのか、そいつのサイトはどこかって言うことを修飾してると考えて。

297 ：Name_Not_Found：04/03/30 15:42 ID:???

>>296
定義リストも掲示板のマーク付けも
過去ログ掘り起こすと実に多様な見解が出てくるので見てみるのも一興かと。

298 ：Name_Not_Found：04/03/30 15:57 ID:???

>>295
>>287はしているような気がするが。
表現は異なるが、必要ないと思ってるのは使わずに済むと思ってるからだろ？

299 ：294：04/03/30 16:14 ID:???

>>295
あ、そうなの？
>>277とか>>279とか>>285は使わない方がベターと言っているように
見えたんだけど。まあ違うならいいけどさ。

300 ：Name_Not_Found：04/03/30 16:21 ID:???

>>298
お前の住んでる地域では「米を食べる必要はない」と言ったら
「米を食べるべきではない」なのか？

301 ：Name_Not_Found：04/03/30 16:36 ID:???

そもそも、「必要ない」発言を繰り返している人の意図がよくわからないのだが。

本当にただ不可欠ではないということだけが言いたかったの？
それなら、省略不可の必須要素以外はHTMLでは不可決でない、で終わる話だろ。
なのにimgやqについて繰り返し述べるからには何か意図があるのだろう、
必要ない→できるだけ使うべきではない、と言いたいのだろうと解釈されても
しょうがないと思う。

302 ：Name_Not_Found：04/03/30 16:36 ID:???

"すべきではない"ほどに強くはないけど、
"しないほうがベター"程度には聞こえるよね。

303 ：Name_Not_Found：04/03/30 16:49 ID:???

> 本当にただ不可欠ではないということだけ
これを表現するうまい日本語ないかなぁ。
「必要ない」は余計な解釈くっつける奴が多くて非常に使いにくい。

304 ：Name_Not_Found：04/03/30 17:08 ID:???

自然言語においては、文の意味なんて文脈によっていくらでも変わるものだ。
もっと表現の勉強した方がいいぞ。

305 ：Name_Not_Found：04/03/30 17:16 ID:???

例えば>>286-287あたり。
「必須」の反意語は「必要ない」だと思うがﾅｰ。

306 ：Name_Not_Found：04/03/30 17:17 ID:???

そっちの議論に踏み込むの…？

307 ：Name_Not_Found：04/03/30 17:26 ID:???

「必要ない」←反意→「必須だ」
「あるべきでない」←反意→「あってもよい」

blockquote/qが「あってもいいんじゃないの？」と言う人と
それが「必要ない」という人は対立関係にないが、

「必須だ」という言う人と「必要ない」という人は対立関係にある。

・・・のかな？

308 ：Name_Not_Found：04/03/30 17:28 ID:???

まあそういう理由でRFC2119みたいな文書があるんだろうね。

309 ：Name_Not_Found：04/03/30 17:28 ID:???

なーんかメタメタな議論だなー。
>>286の言う「必須」には、「よりわかりやすく機能的なマークアップの
ためには」という、HTML文書作りでの大前提が含まれているわけだろ？
それに対して>>287の言う「必要ない」は、「他の方法でも代替が不可能
というわけではない」という意味だろたぶん。全然噛み合ってねー。
論理言語使って話してるんじゃないんだから、文単体の意味だけ
解釈しようとしても答えなんか出ないっての。

310 ：Name_Not_Found：04/03/30 17:34 ID:???

>>309
そうだとすると>>301みたいな疑問が生じるわけだが。
そんなテクニックを語られてもあまり有意義でないような希ガス。
もしかしたら使える要素が限定されている場合があるのかもだけど。

311 ：Name_Not_Found：04/03/30 17:47 ID:???

確かに意図や意義についてはよくわからんな。
単なる思考実験のつもりだったんじゃなかろうか。
そうならそうと書いてほしかったけど。言葉が足りなすぎ。

312 ：Name_Not_Found：04/03/30 18:02 ID:???

で、必要なんですか？

313 ：Name_Not_Found：04/03/30 19:04 ID:???

言葉遊び終了

314 ：Name_Not_Found：04/03/30 19:30 ID:???

ごめんな。俺が悪かったよ。

315 ：Name_Not_Found：04/03/30 23:33 ID:???

　<dl>
　　<dt>○△□</dt>
　　<dd>～</dd>
　</dl>

の様に dt dd の順番に現れるのが普通と思いますが、
この順番が逆になっても良いんでしょうか？

316 ：Name_Not_Found：04/03/31 00:39 ID:???

>>315
辞書が「語句の説明～　【語句】」という風にかかれてたら読みにくくないか？

317 ： ◆FoxMX6a/hk ：04/03/31 00:40 ID:???

>>315
ナゾナゾとその答えとかはどうでしょう。
出題が定義文、解答が被定義文ということで。
CSS で操作しろという話もあるかもしれないが、これはこの順序が自然だという見方もできる。

318 ：Name_Not_Found：04/03/31 02:02 ID:???

そこまで気にしてちゃ禿げるよ

319 ： ◆FoxMX6a/hk ：04/03/31 02:21 ID:???

いや、納得いくまで煮詰めないとストレスでよけい禿げる。

320 ：Name_Not_Found：04/03/31 02:31 ID:???

dt と dd の出てくる順番が逆になったとしても、
別に問題はないと思うけど。

321 ：Name_Not_Found：04/03/31 04:23 ID:???

322 ：Name_Not_Found：04/03/31 04:38 ID:???

>>321
<!ELEMENT DL - - (DT|DD)+
ってことだから、dtとddの出現順は問わない。

323 ：Name_Not_Found：04/03/31 07:35 ID:???

dt/ddの出現順に意味があるかどうか、については
仕様は何も規定していない(隣接するdt/dd間の対応関係さえ怪しい)ので
気にしてみても始まらないと思う。

324 ：Name_Not_Found：04/03/31 08:45 ID:???

>>323
な。あれどうにかならんかね。

325 ：Name_Not_Found：04/03/31 09:54 ID:???

>>325
もしXML系のHTMLつかってるなら、自らdl-dt-ddと互換性がある(非対応UAに
HTML4.01のdl-dt-ddと誤認してもらえる)モジュール作って、そのモジュール
の仕様として「このdtとddは必ずこの順番で一対で現れて、このような
相関性がある」とさだめるのが現状ベターかと。

326 ： ◆FoxMX6a/hk ：04/03/31 12:02 ID:???

dt と dd の出現順は、valid かどうかという次元の話じゃないだろ。
仕様書が定義していないことまで論理的に解釈して理想を求めてこそ原理主義。
これぞ漢。

327 ：Name_Not_Found：04/03/31 12:18 ID:???

別に原理主義じゃないし。

328 ：Name_Not_Found：04/03/31 12:29 ID:???

別に漢じゃないし。

329 ：Name_Not_Found：04/03/31 12:55 ID:???

別に次元じゃないし。

330 ：Name_Not_Found：04/03/31 12:57 ID:???

別に解釈じゃないし。

331 ：Name_Not_Found：04/03/31 14:17 ID:???

別に禿じゃないし。

332 ：Name_Not_Found：04/03/31 14:36 ID:???

>>326
その結果「未定義」って結論しかでないのがdl-dt-ddのFA。

333 ： ◆FoxMX6a/hk ：04/03/31 15:06 ID:???

おめーらすでに禿げてしまった俺の頭をどうしてくれるヽ(`Д´)ﾉ
って俺も332支持だけどな。

334 ：Name_Not_Found：04/03/31 15:20 ID:???

しょうがないよね、
仕様が無いんだから。

335 ：Name_Not_Found：04/03/31 15:55 ID:???

おいだれかこいつを難民にでも放ってやれ

336 ：一休：04/03/31 16:26 ID:???

わかりました将軍さま。

私が難民板につれてきますので、PC板から追い出してください。

337 ：Name_Not_Found：04/03/31 16:35 ID:???

table で、空のｾﾙには何を入力すれば良いんでしょうか？
或いは空っぽのままでも OK ？

338 ：& ◆sQw2IvQ8pg ：04/03/31 17:00 ID:???

>>337
http://www.w3.org/TR/html4/struct/tables.html#h-11.2.6
>Cells may be empty (i.e., contain no data).
仕様でわざわざ「カラであってもよい」と明記されている。
問題ない。

あと、よけいなお世話だが、できれば先に仕様をよんでみる癖をつけると良い。
今回みたいにそのものズバリの答えが仕様に書いてある場合も少なくない。
英語が厳しいようなら邦訳もあるし。

339 ：Name_Not_Found：04/03/31 18:07 ID:???

>>338
有り難う御座いました。

後、余計な御世話だなんてとんでもありません。
今後は、まず仕様に目を通すことにします。

340 ：Name_Not_Found：04/03/31 20:12 ID:???

>>322
いや、そもそも出題と解答に定義文を使うべきかという意味で書いたわけだが。

341 ：Name_Not_Found：04/03/31 21:08 ID:???

私個人はqやimgはあって良いと思うが無くても良いとする主張にも一理有る。

まず、qやimgだけが特別扱いされているならaudioやnextなども無ければ不釣合だという主張。
次に少ない汎用的なもので表されていればそれを処理するのが簡単になるという主張。
例えばRelaxNGなんかではセマンティクスは一部の要素のみに割り当てられ、それ以外はシンタックスシュガーとして提供されている。
現在のHTMLでもimgやappletはobjectのシンタックスシュガーのような位置付けである。

このことから、あると便利なことを認識しつつもそれがどの程度本質的なものなのかどうかを議論するのは無意味なことではないと思う。

342 ：Name_Not_Found：04/03/31 21:09 ID:???

>>341
imgについては歴史的経緯を学べば、まあ考えるべきところは多いだろうな。
で、qに対応していると思われるnextって何？

343 ：Name_Not_Found：04/03/31 21:17 ID:???

ところで、Link Typesにあるnextとかprevとかって
(例えば)XHTML1の名前空間に所属する語彙なんでしょうか？
つまり http://www.w3.org/1999/xhtmlnext ?

344 ：Name_Not_Found：04/03/31 22:00 ID:???

ちょっとわからなくなったので質問です。
フレームページにてhn要素を使う場合、呼び出される各ページにおいてh1から使うべきなのでしょうか。
それとも、ブラウザの見た目のページにおいて使うべきなのでしょうか。（呼び出されるページ全てで1ページとみなすって事）
後者だと、場合によってはいきなりh4がでてきたりする可能性もあるので、やっぱおかしい気がするんですが。
どうなんでしょうか、教えて下さい。

345 ：Name_Not_Found：04/03/31 22:02 ID:???

>341
＞まず、qやimgだけが特別扱いされているならaudioやnextなども無ければ不釣合だという主張。
申し訳無いが、その主張を誰がどんな文脈で行っていたのかソースを教えてもらえないだろうか？

ちなみに俺はimgはobject要素に一本化、qはXHTML2.0みたいに、blockquoteと
一本化してほしいと思っているがaudioやnextってのは初耳。

>>343
HTML4.01によって、rel、rev属性の値として定義されていたはずなので、
そのLinkTypesなら、XHTML Basicの名前空間に属している解釈になるんではないかと。

346 ：Name_Not_Found：04/03/31 22:03 ID:???

>344
HTMLの１ファイル（文書）単位で１から始まります。つまり前者。

347 ：344：04/03/31 22:06 ID:???

>>346
ありがとございます！
やっぱり前者でしたか。謎が解けてすっきりした頭でまくあぷ出来そうです。

348 ：Name_Not_Found：04/03/31 22:11 ID:???

Strictスレで聞くようなことかと小

349 ：Name_Not_Found：04/03/31 23:12 ID:???

まぁまぁ、ここで聞くって事は Strict に少なくとも関心はあるはずで
そういう人たちが増えていくのは実にいいことではないか。

350 ：Name_Not_Found：04/03/31 23:40 ID:???

ま、下手に「表示されれば良いんだ」程度の認識のスレに行って
妙ちきりんな問答がやり取りされるよりはマシだな。

あと、strictをふきゅうさせたければ、自ら閾を高くする必要もないし。

「低レベル化した」と嘆く声もあるけどそれだけ「一部の一々使用を読むような
連中だけの物ではなくなった」と喜ぶことも出来るわけで。

351 ：Name_Not_Found：04/03/31 23:42 ID:???

普及を歓迎しない人もいるからね。
strictで書いた自分のサイトは凄いぞ、みたいな。

352 ：Name_Not_Found：04/04/01 00:00 ID:???

>>345
すいません言葉足らずでした。
qやimgだけを特別扱いするならaudioやnextなども無ければ不釣合だということになってしまうためqやimgを特別扱いするべきではないという主張。
というのが正しい表現です。
実際にaudioやnextの導入を要求している人は見たことがありません。

353 ：Name_Not_Found：04/04/01 00:10 ID:???

ちなみにnext要素ってどんなの？

imgときてaudioは何となく解る。でもq(引用)とnext(次)ってのがどう対応しているのか
わからん。

ついでに言えば、もしnextが次って意味ならばaやlink要素のrel,revのキィワードじゃ
だめなのか？

354 ：Name_Not_Found：04/04/01 19:18 ID:???

>>349-350

まぁ、そろそろ「Strict質問/初心者用スレ」があってもいいと思うけど。

355 ：351=341：04/04/01 22:03 ID:???

>>353

nextは<a rel="next">の意味です。
>>279氏の「imgはaの特別な場合だ」という主張を受けた>>281氏の「そんなこといったらqだってaの特別な形(<a rel="quotation">)ということになっちゃうじゃないか」という主張に基づいて私が例として出したものです。

>ついでに言えば、もしnextが次って意味ならばaやlink要素のrel,revのキィワードじゃだめなのか？
はい。ですからqやimg不要論にも一理あるという根拠の1つとして「qは<a rel="quotation">でいいじゃないか」と言ったのが341の趣旨でした。

356 ：Name_Not_Found：04/04/01 23:16 ID:???

>>355
＞qだってaの特別な形(<a rel="quotation">)ということになっちゃうじゃないか
ならないよ。

aはリンクで使われるアンカーを意味する要素であって、どういうリンクかを
示すのがrelとrev。

対してqは内容が引用であることを示す要素。

仮に<q>を<a rel="quote">で代用出来る仕様をXMLで作ったとしても
それは全く異なる二つの表現であって全く異なる物となる
(例えば引用元がリンク切れを起こした場合を想定すれば分かり易いはず）

もうちょっと自分の中で整理してから発言すれ。

357 ：Name_Not_Found：04/04/02 10:22 ID:???

いや、漏れの主張じゃなくて>>281氏、ひいては>>279氏の主張だし。
とりあえず>>281, >>279, >>284, >>285, >>292, >>293あたりの議論を読んでから発言すれ。

それにリンク切れは関係無い。
aというのはURIによって示されるリソースとアンカーテキストを関連付けるもので、
ある時刻のリソースを表すduriスキーマや永続性の保証されたurnスキーマなどのURIなどを使えばあるリソースを一意に指定できるわけだから、
それが実際にWebを通じて取得できるかどうかは関係無い。

358 ：Name_Not_Found：04/04/02 11:12 ID:???

> ある時刻のリソースを表すduriスキーマや永続性の保証されたurnスキーマなどの
これは余分ですね。
httpだってリソースを一意に指定できますし永続的です。
人がそれを（勝手な都合で）変えるだけです。

これでよいでしょう。
「aというのはURIによって示されるリソースとアンカーテキストを関連付けるもので、
URIはあるリソースを一意に指定できるわけだから、
それが実際にWebを通じて取得できるかどうかは関係無い。」

359 ：Name_Not_Found：04/04/02 21:14 ID:???

img がその昔最初に提案された時も、
<a rel="embed"> とかでどうよ？って話は出ていた。
だからどうだってことでもないしガイシュツだけど、当時の参考資料。
http://www.webhistory.org/www.lists/www-talk.1993q1/index.html#182

# imgにできてaに出来ないことって、「画像リンク」なのだろうかひょっとして。

360 ：Name_Not_Found：04/04/03 06:39 ID:???

>359
imgやobjectは他リソースの文書への埋め込みなのでそれは当然だろう。
qみたいに文書そのもののコンテンツとして「転載(ただし著作権法の
引用の要件を満たした運用が行われるだろうからこれが引用となる)」される
ことが期待されるqと、他のリソースへ結びつけるだけのaやimgやobjectとは
あきらかに付かれている技術が違う。

imgはaやXLinkで代用できるがqはできない。

361 ：Name_Not_Found：04/04/03 14:24 ID:???

>>360
q はメディア型が text/* である他リソースの埋め込み。
# おそらく「リソース」の概念も君と違っているのだと思う。

362 ：Name_Not_Found：04/04/03 15:50 ID:???

>>360 と >>361 は「埋め込み」の定義が違うと思う。
「文書ファイルへの埋め込み」と「文書ページへの埋め込み」
の違いかな。

<q> は内容をファイルに埋め込んでるが、
<img>, <object> はページへ埋め込んでいる
という意味で違いはある。それを有意の違いと見るかどうか。

363 ：Name_Not_Found：04/04/03 16:31 ID:???

>>360の埋め込みはHTMLの技術的にもあってると思うが。

364 ：Name_Not_Found：04/04/03 23:00 ID:???

>>362
文章量の多いリソース等で
章ごと(あるいは適当な長さ)でファイルを分割した場合としない場合とで
有意な差があるのだろうか。漏れ的にはその程度の違いなんだが。

365 ：Name_Not_Found：04/04/03 23:11 ID:???

ネットとディスコネクト状態で単独でファイルを扱う場合にちがうな。
(但しXML時代では本当に単独で運用されるケースは本当に少ないだろうけれども)

後、引用の場合(これはXPathで解決しそうだが)既存のURIの指定方法だと
「必要最低限のみの表示」というのが難しいと思われる。

366 ：Name_Not_Found：04/04/03 23:33 ID:???

>>365
結局「取得可能かどうか」なんですかね。

> 既存のURIの指定方法だと
>「必要最低限のみの表示」というのが難しいと思われる。
URI仕様(というかHTTPスキーム)の影響、ということ？

367 ：Name_Not_Found：04/04/03 23:50 ID:???

　あああ

と、

　<em>あああ</em>

とでは、別の文であると考えた方が良いんだろうか。
つまり、上手くは言えないんだけど、

　後者は「この部分は強調したい」という作者の意図を含んでいるから
　前者と後者とでは別の文である。

と考えるのが良いのか、或いは、

　後者は前者を Mark-Up してあるだけ。文としては同じ物。

と考えるのが良いのか・・・どっちなんでしょうか？

368 ：Name_Not_Found：04/04/04 00:07 ID:???

もし<em>あああ</em>を原稿用紙に書くとしたらおそらく傍点を打つと思うので
違うものとしてとらえるだろうな

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

そっかそっか！なるほど！

疑問が消えてすっきりしました、有り難う。

370 ：365：04/04/04 00:10 ID:???

>>366
本当に必要最低限のみを、となると
「4つめのdiv要素の3つめのp要素の4文字目から次のp要素の12文字目」
を埋め込み対象にする。

なんて方法が必要だよね、と言うことのつもり。

>>367
俺は同じ物として考えている。

例えば誤ったmarkupの結果段落がp tagでmarkupされていなくても、
(本来)そこがp要素であると言うことには変わりない。

文章があってmarkupがされる。markupにあわせて文章が変化する
（例えばemがあれば強調を意味する括弧はなくなる）ことはあっても、
文章の意味が変質することはないと思う(と言うかmarkupにより変質
しちゃったら、既にmarkupじゃないな)

ただし、markupの有無のより、読み手が結果として異なる解釈をする
(>>367 の例だと作者の強調の意図の有無)ことはあると思う。

371 ：Name_Not_Found：04/04/04 00:19 ID:???

　　あああ
と
　　<em>あああ</em>
は別物だけど、
　　あああ（傍点等、強調を意味する何か付き）
と
　　<em>あああ</em>
は同じだと考えれば良いのかな？

つまりmarkupにより文章の意味するところが変化することは無い、と。

372 ：370：04/04/04 00:33 ID:???

>>371
おれはそう解釈しているし、そういう風にしてます。

ただし、もともとペーパメディアの文章をapplication/xmlと言う異なる
メディアに変換する際に文章そのものがメディアに合わせて変質することは
あるよ、と言う注釈付きで。

373 ：Name_Not_Found：04/04/04 00:35 ID:???

>>367
正直、同じかどうかは立場次第かと。
処理系にとってはmarkupが全てだろうし、人間でも
作者にとっては自分の意図が全てだろうが
読者にとっては自分の読み取った解釈が全てだろう。

374 ：Name_Not_Found：04/04/04 00:44 ID:???

>>372
一般書籍と電子文書では
ページとか行とか挿絵とか外字とかって概念が全く別だよね。
一般書籍って視覚情報べったりって意味では画像の集合体と一緒だし。

375 ：Name_Not_Found：04/04/04 01:02 ID:???

紙メディアとhtmlは違うと言われてるけど
紙上の文章とhtmlのマークアップも違うものなんだろうな

376 ：Name_Not_Found：04/04/04 01:47 ID:???

例えば注釈なんかは、リンクもできるし、title属性で書いちゃうとかできるしね。

あと、HyperTextの場合、複数の次の文章へのリンクにより文章が非線形に
なる場合もあるし(紙でもゲームブックとかなくはないけど)。

377 ：Name_Not_Found：04/04/04 08:15 ID:???

傍点付き「あああ」を「<em>あああ</em>」とmarkupするなら
チェック欄付きリストは

　<ul>
　　<li>あ</li>
　　<li class="checked">い</li>
　　<li>う</li>
　</ul>

とかやっておけば良いんだろうか？

378 ：Name_Not_Found：04/04/04 09:30 ID:???

HTMLとCSSの違いを認識すれ。

ulは飽くまで順不同リストだ。結果として無いよう前部に印が現れるが
それは単なるリストを表現するための記号にすぎず、markupには影響
関係がない。

ちなみに、傍点付きに関しても同じことで一般的に傍点は強調の意味で
使われるので、emと言う話になっているが、例えば著者が「傍点部は引用」と
述べているなら当然q要素になることだろう。

379 ：Name_Not_Found：04/04/04 14:03 ID:???

>>377
フォームのチェックボックスを使うのがいいかな？

380 ：Name_Not_Found：04/04/04 16:25 ID:???

>>379が提案している方法は、果たしてどうなんだろう。
まさしくﾃﾞｻﾞｲﾝ目的のhtml利用てことになりそうな気がするけど。

ﾁｪｯｸ欄付きﾘｽﾄならtableでやる方が自然じゃない？
でもﾘｽﾄという意味合いは無くなってしまうのか。

381 ：Name_Not_Found：04/04/04 16:51 ID:???

>>380
「チェック欄のような見栄えのリスト」か
「チェック項目のリスト」かで違うような。
後者であるなら、checkboxのリストでも自然な気がする。

382 ：Name_Not_Found：04/04/04 19:02 ID:???

フォームのチェックボックスはあくまでユーザの入力を受け取るために使うべし

383 ：Name_Not_Found：04/04/04 19:09 ID:???

じゃあ、今回のような場合は、
どういう風にmarkupすりゃ良いんだよ。

384 ：Name_Not_Found：04/04/04 20:10 ID:???

お定まりの「HTMLでは記述不能」ではないかな。そんなリストはありませんと。

個人的にはチェック欄ってユーザによる入力を意図してるだろ、と思う。

385 ：Name_Not_Found：04/04/04 20:47 ID:???

<img src="~" alt="【チェック済】"> とかは？

386 ：Name_Not_Found：04/04/04 21:14 ID:???

>>378
ちゅーか、「チェック」リストかどうかは別に、リストはリストなんだから
順番があるリスト（項番１から作業してチェックするようなやつ）はolで、
順番が関係ないリストは(買い物のリストみたいなやつ)はulでいいんじゃないか？

>>380
その上でCGIとかでアンケートとかとるためのチェックリストなら
まさにフォームのチェックボックスとしか言いようがないと思うのだが。

結局先に「そのチェックリストはどんなチェックリストですか」と聞かないと
各人の脳内チェックリストのmarkup方が披露されて終わりと言うことで。

387 ：Name_Not_Found：04/04/04 21:21 ID:???

✓

388 ：Name_Not_Found：04/04/04 21:23 ID:???

じゃあさ、

　To Do List

なんかはどう？んで、

　この項目とこの項目はやり終えたから
　ﾁｪｯｸして置こう。

とか言う場合は、どう Mark-Up するのか。

389 ：351=341：04/04/04 21:57 ID:???

delかなぁ。
もはやTo Doではないという意味で。

390 ：Name_Not_Found：04/04/04 21:59 ID:???

なぜCGIなりJavascriptを利用しないんだ?
実行したときに<ul class="checked">と<ul class="uncheck">に
分けて出力すれば全く困らんと思うが
ﾁｪｯｸボタンをどうするかは適当にやってｸﾚ。
二つが混在しないものならmark-upも簡単だろ

391 ：Name_Not_Found：04/04/04 21:59 ID:???

>ﾁｪｯｸボタンをどうするかは適当にやってｸﾚ。
ここがまさに焦点なのではないか？

392 ：Name_Not_Found：04/04/04 22:22 ID:???

おそらくネタかと。

393 ：Name_Not_Found：04/04/06 01:46 ID:???

何で急に流れが止まったの？

394 ：Name_Not_Found：04/04/06 01:51 ID:???

そもそも流れなんてありませんが

395 ：Name_Not_Found：04/04/06 02:02 ID:???

あっそ

396 ：Name_Not_Found：04/04/06 09:58 ID:???

Pert9くらいまでで出尽くしているから殆ど既出なんだよ
だから>>394は正解。

397 ：Name_Not_Found：04/04/06 11:01 ID:???

今後のこのスレの存在意義？を考えてみた

１：初心者向けスレとして、仕様を読めない、読まないような人たちに
まとめスレやテンプレの充実により対応し、普及を目指す。
　また、仕様を読めない（読む習慣がない）人向けに仕様の読み方を
解説する。

２：さらなる高みを目指してXSLで生成する場合のStrictなテンプレートとか、
ダブリンコアをHTML4.01で使う為にはどうしたらいいかとか、そういう
マニアックな方向に話題を持って行く。

３：役割果たしたので閉鎖。

４：目的もなく、だらだら存続。

で、俺は４希望(ﾜﾗ

398 ：Name_Not_Found：04/04/06 11:09 ID:???

5: たまに入ってくる新しい話題の受け入れ場所。

というかここは、仕様書に書かれていないHTML4.01語彙セットの
セマンティクスを延々と議論（とループ）し続けるスレのような。

399 ：Name_Not_Found：04/04/06 11:10 ID:???

4と5だな。

400 ：Name_Not_Found：04/04/06 12:31 ID:???

401 ：Name_Not_Found：04/04/06 12:40 ID:???

たまに湧くおかしな主張の受け入れ場所。

402 ：Name_Not_Found：04/04/06 22:29 ID:???

完全なDTDでもみんなで作ったらどうだ?

403 ：Name_Not_Found：04/04/06 22:38 ID:???

そもそもDTD自体が駄目かと。

404 ：Name_Not_Found：04/04/06 23:09 ID:???

<!DOCTYPE HTML PUBLIC
"-//2CH//DTD Puritan HTML 1.0//JA"
"http://pc5.2ch.net/test/read.cgi/hp/1076693129/">

405 ：Name_Not_Found：04/04/06 23:16 ID:???

用途不明の使えんスキーマが出来上がる悪寒。

406 ：Name_Not_Found：04/04/06 23:19 ID:???

まぁまぁ、XHTML2.0とかが勧告されればまたXHTML2.0専用スレとは別の視点から話ができるでしょう。

407 ：Name_Not_Found：04/04/06 23:59 ID:???

その肝心の勧告はいつになるんでしょうか。

408 ：Name_Not_Found：04/04/07 00:02 ID:???

しかしよくよく考えてみると「勧告を楽しみにしている」ってのはどうなんだろう？

409 ：Name_Not_Found：04/04/07 00:40 ID:???

勧告になっても、IEが実装しなければ
HTML4Strictスレはきっと残り続けるんだろうなぁ...

410 ：Name_Not_Found：04/04/07 21:25 ID:sgYz2fqk

textareaの内容ってPCDATAだよね？
ならば
はコメントとして扱われるの？
うちのブラウザは全部コメント内もそのまま見えちゃうんだけど。

411 ：Name_Not_Found：04/04/07 21:26 ID:???

>>397
1の用途でOKと誤認した上でｶｷｺ

一般的にJavaScript多用するとｳｾﾞｰと言われますが
外部ファイルにまとめといてそれを呼ぶ分には、
いくつもJavaScriptが使われていてもStrictなんでしょうか。

412 ： ◆FoxMX6a/hk ：04/04/07 22:00 ID:???

>>410
鳩丸見てきたが、どうやら実装の方が間違ってるっぽいな。

>>411
JavaScript がマークアップを書き換える働きをするなら、
スクリプトが書き換えたあとのドキュメントが Strict でなきゃならない。
JavaScript 多用がうざいのと Strict か否かは直接関係ないんでわ？

413 ：Name_Not_Found：04/04/07 22:03 ID:???

>>410
> textareaの内容ってPCDATAだよね？
> ならば
> はコメントとして扱われるの？

その通り。

> うちのブラウザは全部コメント内もそのまま見えちゃうんだけど。

仕様つーかバグつーか。あんまり関係ないけど、以下参考まで。

http://altba.com/bakera/hatomaru.aspx/ebi/topic/213

414 ：411：04/04/07 22:42 ID:???

>>412
Thxです。
JavaScriptがちゃんとStrictなドキュメントを吐くなら平気つーことですね。
＞JavaScript 多用がうざいのと Strict か否かは直接関係ないんでわ？
無知晒しｽﾏｿ

415 ：410：04/04/07 23:34 ID:???

なるほど
ありがとうございます。まあしょうがないですね。

416 ：Name_Not_Found：04/04/08 04:54 ID:???

417 ：Name_Not_Found：04/04/09 09:06 ID:???

例えば名言とかことわざみたいなのはどうマークアップすべきでしょうか

「過ぎたるは及ばさるがごとし」

　　　　　　　　　-----孔子

みたいなやつで。名前と言葉が逆だったらdlでよかった気もしますが。。
御教授ください

418 ：Name_Not_Found：04/04/09 09:21 ID:???

<q>過ぎたるは及ばさるがごとし</q> <cite>孔子</cite>

419 ：Name_Not_Found：04/04/09 09:49 ID:???

dl使いたければ、
<dl>
<dt><q>過ぎたるは及ばさるがごとし</q></dt>
<dd><cite>孔子</cite>の言葉</dd>
</dl>
とかね。

こうすればdtに対してddがちゃんと解説してる。
「の言葉」部分が消したければ、CSSとかで工夫。

ただし、上記markupのままだと、CSS1or2のみで「の言葉」を消すのは
かなり困難だけど。
(ポジションでdd全体を画面外にとばして、更にciteだけ戻すとか
無駄に複雑な方法しか俺には思いつかんかった)

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

>>416
HTML1 の頃は TITLE の要素内容は RCDATA だったらしいから、
それはある意味適切な挙動かも。

その後方互換のためか、HTML 4.01 にもこんな記述がある。

> Titles may contain character entities (for accented
> characters, special characters, etc.), but may not contain
> other markup (including comments).

http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.2

421 ：Name_Not_Found：04/04/10 20:20 ID:???

特殊文字についてなんですが、
< , > , & , " , @ くらいを
http://www.kanzaki.com/docs/charset.html
を参考に置換して置けば良いんでしょうか？

それともまさか全てなんてことはないですよね？

422 ：Name_Not_Found：04/04/10 21:14 ID:???

>>421
通常のベタテキスト中に直接書けない(文字参照で表記する必要がある)のは
< と & だけ。
属性値を " で囲っている場合は属性値中の " も文字参照にする必要がある。
' で囲っている場合はその必要はないが、逆に ' を文字参照にする必要がある。
> は別にそのまま書いたって不正ではないけれど
属性値中に記述すると誤動作する処理系もあるらしい。
@ を文字参照にしている人の目的はロボットによるアドレス収集回避で
仕様上 @ を文字参照にする必要は全くない。
その他の文字については、
使用する符号化方法で表記できない場合だけ使えばよし。

423 ：Name_Not_Found：04/04/10 21:15 ID:???

全てってどういう意味？こうか？

424 ：Name_Not_Found：04/04/10 21:17 ID:???

>>422
なるほど。凄く分かり易くて助かりました。
詳しい説明有り難う御座いました。

425 ：Name_Not_Found：04/04/10 21:22 ID:???

>>419
dd { visibility:hidden; }
cite { visibility:visible; }

これで良いんじゃないか。

426 ：Name_Not_Found：04/04/10 21:31 ID:???

あと、スペースとタブも(処理により正しく)無視されることがあるから
必要に応じて文字実体参照か数字参照する必要がある。

改行コードの場合も一般に無視されるがこちらの場合はHTML的には
br要素を使うのが正しい。

ちなみに、将来XSLTとかやろうと思っている場合は文字参照より
数字参照にするのがおすすめ。全てのXMLで保証されている(DTDなしでつかえる)
文字参照は<>&'"の５種類だけなのに対して、数字参照は全てのXML1互換の
文書で(DTDがない状態でも)使えるから、と言うのがその理由。

>>423
全てってのはa-zあたりも乗ってるから、正しくはアルファベットや漢字まで?
っていみかと思われ。
で、>>422　が答えているとおり。まぁ、俺なら>も無条件に参照にしちゃうけどね

427 ：Name_Not_Found：04/04/10 21:41 ID:???

なるほど確かに全てですな。

428 ：Name_Not_Found：04/04/10 21:44 ID:???

> 文字参照より数字参照

例えば < を表すのに＆lt; では無く＆#60; とした方が良いと言うことですか？

429 ：Name_Not_Found：04/04/10 21:45 ID:???

ttp://antipop.zapto.org/

↑この人はメアドを全部・・・

430 ：Name_Not_Found：04/04/10 21:53 ID:???

>>426
Strictスレなんだから「数*値*文字参照」と書いてほしい。

431 ：Name_Not_Found：04/04/10 21:58 ID:???

つまり>>428ということ？

432 ：426：04/04/10 22:00 ID:???

>>428
<>&'"の５つはXML1互換なら問題ないです。

>>430
全く持ってその通りです。

>>426 の数字参照は全て数値参照に読み替えて下さい。
間違って憶えると私みたいに恥をさらします。

433 ：Name_Not_Found：04/04/10 22:22 ID:???

>>423
最初言っているいみがわからなかったが
かちゅ～しゃでレスポップアップさせてわかった

434 ：Name_Not_Found：04/04/10 22:58 ID:???

http://web1.tinet-i.ne.jp/cgi-bin/sjun/minibbs8.pl

435 ：Name_Not_Found：04/04/10 23:09 ID:???

>>423
文字コード US-ASCII で日本語の文章を書こうと思ったらそうならざるを得ないな。
まあ、そんなことはしないけど。

436 ：Name_Not_Found：04/04/11 00:53 ID:???

> 文字参照は<>&'"の５種類だけなのに対して、
何となく不安なので補足しとくが、
Á とか DTDで宣言されるものは文字参照ではなく実体参照。
SGML の場合文字参照はSGML宣言で宣言される(<>&"等)。
XML で文字参照(キャラクタ参照/character reference)と言ったら
数値文字参照を指し、<>&"'は定義済み実体(predefined entities)と言う。
蛇足だったら失礼。

437 ：Name_Not_Found：04/04/11 00:56 ID:???

>>436
> 蛇足だったら失礼。
　Strictスレなんだから蛇足余談は歓迎です。

438 ：Name_Not_Found：04/04/11 01:31 ID:???

更に蛇足。

' (') は HTML 4.01 以前では使えない。
XHTML 1.0 でも text/html では記述すべきでない。
これも ' とする方が確実。

439 ：Name_Not_Found：04/04/11 03:34 ID:???

さらに蛇足。

実体参照 ... ＆lt; 等
数値指定文字参照 ... ＆#64; 等
名前指定文字参照 ... ＆#SPACE; 等

名前指定文字参照に対応しているWebブラウザは少ない。

440 ：Name_Not_Found：04/04/12 12:09 ID:???

>>426
ｹﾞﾗｹﾞﾗ

441 ：Name_Not_Found：04/04/12 13:42 ID:???

勉強になりました>>蛇足

442 ：426(& ◆Di83K0DpQA ：04/04/12 15:05 ID:???

　　>>226 ﾆｵｼｴﾃﾔﾙｾﾞ
　　　ｶﾀｶﾀ　　　＿＿＿_　＿＿＿
　　　　　　　　　|｜＼　　 .＼　 |◎ |
　　　(　｀Д´)　.|｜　　|￣￣|　 |：[].|
　┌（　　ノ／￣l｜／￣￣/　 | ＝|
　 |└ ヽ　|二二二」二二二二二二二二」
　　￣］　＿　　|　||　　　　　　　 |　||
　　／￣　|　.／　|| 　　　　　／　 ||
　 ◎　　 ◎[＿___||　　　　 .［＿＿||
　　　　ｶﾀｶﾀ

　　|　　ｿﾚﾊ　数字ｼﾞｬﾅｸﾅ　数値ﾃﾞｽ
　　|　　DTDﾃﾞ宣言ｻﾚﾙﾓﾉﾊ文字参照ﾃﾞﾊﾅｸ実体参照
　　|　　<>&"' ﾊ定義済ﾐ実体(predefined entities)
　　￣￣￣￣￣Ｖ￣￣￣￣￣￣
　　　ｴｯ！ｴｯ！ｴｯ！
　　　从/　　　　　＿＿＿_　＿＿＿
　　　　　　　　　|｜＼　　 .＼　 |◎ |
　ヽ(　｀Д´)ﾉ　|｜　　|￣￣|　 |：[].|
　┌ （　　／￣l｜／￣￣/　 | ＝|
　 |└ ヽ　|二二二」二二二二二二二二」
　　￣］　＿　　|　||　　　　　　　 |　||
　　／￣　|　.／　|| 　　　　　／　 ||
　 ◎　　 ◎[＿___||　　　　 .［＿＿||
　　　　　　　　　　　　　　　　　　　　　　　　＿＿＿_　＿＿＿
　　ﾓｳｺﾈｴﾖ！　　　　　　　　　　　　　　　|｜＼　　 .＼　 |◎ |
　　　ｳﾜｧｧｧｧｧﾝ！　　　　　　　　　　　　　|｜　　|￣￣|　 |：[].|
　　　　　　　　　　　　　　　　┌ ---- ／￣l｜／￣￣/　 | ＝|
　　　　　　　　　　　　　　　　 |└ --|二二二」二二二二二二二二」
　　ヽ(｀Д´ )ﾉ　　　　　　　　￣］　＿　　|　||　　　　　　　 |　||
　　　 (　　)　　三　　　　　　／￣　|　.／　|| 　　　　　／　 ||
　　　　/　ヽ　　三　　　　　 ◎　　 ◎[＿___||　　　　 .［＿＿||

443 ：Name_Not_Found：04/04/12 15:07 ID:???

>>442

444 ：Name_Not_Found：04/04/12 15:37 ID:???

>>426
なんか、メチャメチャだが、強くイ㌔。

445 ：Name_Not_Found：04/04/12 15:42 ID:???

>>442

446 ：Name_Not_Found：04/04/12 19:21 ID:???

>>426

447 ：Name_Not_Found：04/04/16 19:14 ID:???

で…

448 ：Name_Not_Found：04/04/18 06:00 ID:kkdUTJlY

なあ、雑誌に俺のサイトの１コンテンツが紹介されたんだが
http://www.foo.ne.jp/hage/hogeが正しいのに
http://www.foo.ne.jp/hage/hoge/
になってた。
そりゃ最後に/をつけるのが正しいときもあるけどそりゃディレクトリの
ときだろーに。
やっぱ世間的には拡張子がないuriは広まってないのね・・
急いでディレクトリ作ったよ。

449 ：Name_Not_Found：04/04/18 06:06 ID:???

俺なんてエロサイトで年齢認証のページすっ飛ばして載せられたぜ。
もうね（ｒ

450 ：Name_Not_Found：04/04/18 06:25 ID:???

鳩丸なんかだとファイルに/つけるとnotfoundになるけど
うちは/つけても見えちゃうんだよ、cssとか使えなくなっちゃうし
中の相対urlもおかしくなっちゃうからありがた迷惑なんですよね
.htaccessかなんかでファイル名に/つけた場合、notfoundにする
方法ってあるのでしょうか？

451 ：Name_Not_Found：04/04/18 07:10 ID:???

>>450
http://pc5.2ch.net/test/read.cgi/hp/1065608009/

452 ：450：04/04/18 07:43 ID:???

>>451
すみません、そちら行きます。

453 ：Name_Not_Found：04/04/19 06:46 ID:jmYBMwHw

rowspan 属性って物理くさいんだけどcssでなんとかならないのでしょうか？
使ってもstrictですかね？dtd的にはstrictでしょうけども・・。

454 ：Name_Not_Found：04/04/19 07:04 ID:???

最終的に表としてレンダリングされると考えるのならば物理臭いかもな

455 ：Name_Not_Found：04/04/19 10:10 ID:???

必ずしも表は2行2列とかの表になってるとは限らないだろ？
<table>
　<tr><th>1行/1列</th><td>1行/2列</td></tr>
　<tr><th>2行/1列</th><td>2行/2列</td></tr>
</table>

次の表の場合は冗長じゃないか？
<table>
　<tr><th>1列</th><td>1行/2列</td></tr>
　<tr><th>1列</th><td>2行/2列</td></tr>
</table>

こういった場合
<table>
　<tr><th rowspan="2">1列</th><td>1行/2列</td></tr>
　<tr><td>2行/2列</td></tr>
</table>
とやってもいいと思うんだが(ていうか最近こんなtable書いてないから使い方
間違ってるかも)。

最終的にどうレンダリングされようが、その表がきちんと意味を持っていれば
別にrowspanもcolspanも段をぶっこ抜いてレンダリングしろという意味じゃ
ないし、ある種の関連づけの一種な気がする。

456 ：Name_Not_Found：04/04/19 11:02 ID:???

>>455
レスアンカーつけろ

457 ：Name_Not_Found：04/04/19 13:18 ID:???

<td></td>の間が空になる個所は何を入れるのが妥当なんですか？
今は何も考えずに＆nbsp;で埋めていますが・・・

<table>
<tr><th>日</th><th>予定</th></tr>
<tr><td>1</td><td>○○○</td></tr>
<tr><td>2</td><td>△△△</td></tr>
<tr><td>3</td><td></td></tr> 
<tr><td>4</td><td>□□□</td></tr>
<tr><td>5</td><td>●●●</td></tr>
　（中略）
</table>

458 ：Name_Not_Found：04/04/19 14:37 ID:???

「<br>」入れるか？
別に何も入れなくていい

459 ：Name_Not_Found：04/04/19 14:58 ID:???

ねえねえ

<table>
<tr><th scope="row" rowspan="2">男</th><td>タモリ</td></tr>
<tr>><td>タケシ</td></tr>
<tr><th scope="row" rowspan="2">女</th><td>ハナコ</td></tr>
<tr>><td>マサミ</td></tr>
</table>
の場合、scope="row"は２行めのタケシ、マサミにもかかってる？

460 ：Name_Not_Found：04/04/19 15:07 ID:???

>>457
無意味な改行やら   やら入れるくらいなら
何も入れない方がマシでは。空なんでしょ？

461 ：Name_Not_Found：04/04/19 15:21 ID:???

>>387-338
このスレくらい嫁

462 ：Name_Not_Found：04/04/19 15:21 ID:???

>>337-338
すまんorz

463 ：Name_Not_Found：04/04/19 15:33 ID:???

457です
<table border="1">とでも置き換えておいて下さい

＆nbsp;もしくは<br>を入れないと枠が表示されない
→予定表などに使う場合見栄えが悪い
# CSS云々の話は無しで

464 ：Name_Not_Found：04/04/19 15:43 ID:???

>>463
「無し」とか入れるのはどう？

465 ：Name_Not_Found：04/04/19 15:58 ID:???

>>463
見栄え気にする立場で「何を入れるのが妥当なんですか？」なんて聞かれてもねぇ。

466 ：Name_Not_Found：04/04/19 15:59 ID:???

「見栄えが悪い」といいつつ「CSS云々の話は無しで」とはこれ如何に。

467 ：Name_Not_Found：04/04/19 17:23 ID:???

図にcaptionをつけたいときは、どう書くのが一番美しいのでしょうか?
具体的には次のようにしたいときです。

┌──────
│
│グラフの画像
│
└──────
図3 二次曲線

すぐ思いつくのは
<div>
<img ... /><br />
<span>図3 二次曲線</span>
</div>
こんなのですが、美しくないですよね。うまい方法がありましたら
教えてください。

468 ：Name_Not_Found：04/04/19 17:31 ID:???

話の流れにあっているようであってない話題ですが、
tableでrowspan、colspanを多用したものがあるんですが、これを展開するようなソフトってないですか。
<td rowspan="2">aaa</td>
を
<td>aaa</td><td>aaa</td>
にするような感じで。
この前必要になったときはその場しのぎで適当なプログラム書いて済ませたんですがイマイチの出来だったので。

469 ：Name_Not_Found：04/04/19 18:05 ID:???

>>467
物によるとは思うが、この例で俺なら
<dl>
<dt><img ... /></dt>
<dd>図3 二次曲線</dd>
</dl>
「この絵は図3 二次曲線ですよ」と解説していると言える訳で、
strictスレ的にもこの程度のdtの汎用化は許容範囲ではないかと
思われる。

470 ：Name_Not_Found：04/04/19 18:30 ID:???

>>466
枠は既にCSSで装飾済みなので、<td></td>でも枠は入ります。
しかし、CSSをoffにした時に枠が消える → 見栄えが悪い → (´д`)ﾏｽﾞｰという状況でしたので、
このような場合に何で埋めれば良いのか・・・を伺いたく >457を書かせて頂きました。
# 説明不足で申し訳ありません。

どうでも良いことですが
<span style="display:none;">予定はありません</span>
に置き換えることにしました

471 ：467：04/04/19 18:40 ID:???

>>469
dl要素を使うことで意味がはっきりしますし、その方が良いですね。
でも、「ブロック要素のimgにはcaptionをつけられる」ようにしてくれたら
解決なんだけどなー。 > W3Cの人

472 ：Name_Not_Found：04/04/19 19:25 ID:???

>>470
＞CSSをoffにした時に枠が消える → 見栄えが悪い
んなもん、ブラウザベンダに、デフォルトスタイルの変更を要請する以外ないじゃないか。

少なくともstrictなHTMLにおいて、見栄え云々というのは完全なすれ違い。
デフォルトスタイルでの表示の工夫のノウハウは物理マークアッパーの方が
もってるので、今後はそれ系のスレにどうぞ。

全くお薦めできないが。

473 ：Name_Not_Found：04/04/19 19:27 ID:???

幻のHTML3.0にはFIG要素があったんだけどねぇ。

474 ：Name_Not_Found：04/04/20 04:38 ID:???

th要素さ、abbr=""
ってしていい？
もうtdの数が多くて眼の見えない人にとっても
なんどもなんどもうざいじゃないかなと思うくらいなんだよね。
しかしいい短縮語も思いつかないし。

475 ：Name_Not_Found：04/04/20 04:53 ID:???

>>474
お前lintの警告の内容読んでないだろ。

476 ：Name_Not_Found：04/04/20 19:40 ID:???

>>474
th要素のabbr属性は必須じゃないぞ。

477 ：Name_Not_Found：04/04/20 21:41 ID:???

いやでもabbrつけないと毎回読んでしまうのでしょ？
別にlintで１００点取るためにabbr=""とするのではなく
毎回読まれることを回避するためのabbrです。scope="col"としちゃったら
その列は毎回thの内容を読まれてしまうでしょ？

478 ：Name_Not_Found：04/04/20 21:59 ID:???

毎回読まれなきゃ困るから読み上げられるんだっつの
嫌だったら読み上げない設定にするなり何なりの対処がユーザ側でできるだろ
特定ブラウザの挙動に依存した記述をするな

479 ：Name_Not_Found：04/04/20 22:05 ID:???

>>477
> いやでもabbrつけないと毎回読んでしまうのでしょ？
つけたって毎回読むかもしれないさ。そんなのUA次第だから。
大体 abbr 属性は視覚系UAが利用することだってありうる。

480 ：Name_Not_Found：04/04/21 00:26 ID:???

>>477
W3C的には、

th { speak-header: once }

で解決するのが筋。対応しているUAは知らんが。

481 ：Name_Not_Found：04/04/21 21:35 ID:???

>>480
css2.1で標準から外され、非標準の参考情報に格下げされました。
css3speechの草案を見ると存在しないので廃止される物と思われます。

482 ：Name_Not_Found：04/04/21 23:28 ID:???

css2.1って勧告済みだっけ?
まだ、その見通しってだけだろ？

483 ：Name_Not_Found：04/04/21 23:50 ID:???

>>481
speak-header はCSS2仕様でも "19 Aural style sheets" の項には存在しないので
css3speechの草案中に存在しなくても廃止とかあまり関係ないような気がするけど。
表モデルなんだからその辺は CSS3 Tables じゃないの？
今はただ「CSS3の表モデルはCSS2と同じ」とあるだけのようだが。

484 ：Name_Not_Found：04/04/22 22:31 ID:???

2.1ではAural style sheetsの項。

485 ：Name_Not_Found：04/04/22 23:46 ID:???

CSS2.1って勧告になったら現在のCSS2をobsoleteしてCSS2と言う名前を乗っ取る予定なの？

486 ：Name_Not_Found：04/04/23 00:44 ID:???

予定では上書きです

487 ：Name_Not_Found：04/04/25 09:26 ID:???

http://www.akutokusos.com/sait/sa_5.htm

488 ：Name_Not_Found：04/04/25 09:32 ID:???

>>487
無断リンクスレに張れよ

489 ：Name_Not_Found：04/04/25 19:13 ID:ca2gJXkA

<h2>えび</h2>
<h3>くるまえび</h3>
<p>～</p>
<h3>イセエビ</h3>
<p>～</p>
<h3>ブラックタイガー</h3>
<p>～</p>
・・・

ブラックタイガーの下にえびの総括を記述した場合h3配下ってことになってしまいませんか？
また<h2>えび</h2>とかくのでしょうか？それとも見出し要素ごとにdivで囲むべきなのでしょうか？

490 ：Name_Not_Found：04/04/25 19:20 ID:???

>>489
そのための section/h です

491 ：Name_Not_Found：04/04/25 19:40 ID:???

では現状では無理ぽ？

492 ：Name_Not_Found：04/04/25 19:56 ID:???

>>489
<h3>総括</h3>

493 ：Name_Not_Found：04/04/25 19:58 ID:???

>>489
<h3>総括</h3>
<p>～</p>

494 ：Name_Not_Found：04/04/25 19:59 ID:???

あ、かぶった。

495 ：Name_Not_Found：04/04/25 22:59 ID:???

cssですけどstricかどうか判断お願いします。

[alt~="Win"]{border:red solid 2px;}

<img src="98.jpg" alt="Win 98">
<img src="NT.jpg" alt="Win NT">
<img src="MAC.jpg" alt="MacX">

でalt属性値、Win 98とWin NTにヒットさせます。
しかしrecには複数の属性値というふうい書かれていました
つまりclass属性とかrel属性とか、cssを適用できないけどprofile属性
みたいに複数の属性を空白で区切ってリストするタイプの属性に限るべきでしょうか？
あまりstrictって応用は好まれませんし。

496 ：Name_Not_Found：04/04/25 23:04 ID:???

スレ違い

497 ：Name_Not_Found：04/04/25 23:11 ID:???

でもmozilla専用cssを使用するのはstrictじゃないでそ？
cssの絡むstrictな話はどこですれば？
適用されるされないでは適用されるからcssスレで聞くまでもないし。

498 ：Name_Not_Found：04/04/25 23:15 ID:???

>>497
CSSが絡むんじゃなくてただのCSSの話じゃん

499 ：Name_Not_Found：04/04/25 23:17 ID:???

例えばh1をdisplay:inlineにしてよいかどうかはここでいい？

500 ：Name_Not_Found：04/04/25 23:21 ID:???

いいえ

501 ：Name_Not_Found：04/04/25 23:28 ID:???

じゃーじゃー
style要素使ってるけどstrict的によくないっすかね？
は？

502 ：Name_Not_Found：04/04/25 23:41 ID:???

>>501
Webサイト製作初心者用スレ vol.89
http://pc5.2ch.net/test/read.cgi/hp/1082203621/

503 ：Name_Not_Found：04/04/26 00:08 ID:???

>>495
Strictはあくまでマークアップの話であって
マークアップ済みの文書の扱いには関知しない。
どんなスタイルシートが使われようと文書構造は変わらない。
だから「Strict的に望ましい/望ましくないスタイルシート」なんてものは存在しない。
そんなのどこで聞いたって誰も満足な答えはくれないと思われ。

504 ：Name_Not_Found：04/04/26 00:17 ID:???

>>503
それすら理解できていないから、初心者スレに誘導されていると思われ

505 ：Name_Not_Found：04/04/26 01:02 ID:???

>>497
ところでどこにMozilla専用CSSがあるんだ？

506 ：Name_Not_Found：04/04/26 02:33 ID:???

>>497じゃないがcenter要素と同じ働きをするプロパティがなかったっけ？
>>495の中にそんなプロパティはないけども。

507 ：Name_Not_Found：04/04/26 07:13 ID:???

[attrib=val] を Moz 専用と思い込んでるんだろ

508 ：Name_Not_Found：04/04/26 07:28 ID:???

邦訳でも仕様書読めないんだろうなぁ。誤解多すぎ。或いは釣りか。

>>506
Mozillaが(XUL用に)独自拡張したプロパティやプロパティの値は沢山ある。

509 ：Name_Not_Found：04/04/26 07:46 ID:???

すみません。cssの識別子に数字を使ってはいけないそうです。しかしながら
cssで使わなければ（別にcss以外にもclass属性の使い道ありますよね？）
<p class="123456">
ってありですか？<p class="23456"と数値文字参照を使わなければいけませんか？

510 ：Name_Not_Found：04/04/26 07:47 ID:???

あ、<p class="123456"
です。

511 ：Name_Not_Found：04/04/26 07:59 ID:???

【オープンソース】Mozilla開発推進団体の日本支部設立へ
http://news5.2ch.net/test/read.cgi/newsplus/1082930981/

(ﾟ⊿ﾟ)ｲﾗﾈ

512 ：Name_Not_Found：04/04/26 09:06 ID:???

>>509
class属性はCDATAなので文書型としてはclass="123456"でも全然問題ない。

>>511
スレ違い。

513 ：Name_Not_Found：04/04/26 09:23 ID:???

引用符で囲まれたらRCDATAになるの？

514 ：Name_Not_Found：04/04/26 09:40 ID:???

>>513
CDATAの属性値は引用符で囲まれたらRCDATAになります。

515 ：Name_Not_Found：04/04/26 09:42 ID:???

>>513
いきなりDTDをよめとはいわんが、せめて仕様書は確認しようよ。
邦訳も充実してるし。

516 ：Name_Not_Found：04/04/26 21:11 ID:???

ま、京ぽんもOpera載ったし、

517 ：Name_Not_Found：04/04/27 12:59 ID:???

友達にXHTML使っているっていったら
なにそれって言われました。
HTML4.01でもいいですか？

518 ：Name_Not_Found：04/04/27 13:03 ID:???

dt dd一対一がいいっていうけど俺は

おれくらいstrictがきわまるとdlの中にdtとddが一対のみ出現。

519 ：Name_Not_Found：04/04/27 13:39 ID:???

>>517
つーか、自分でサイトを書かない奴はHTMLなんかそもそも知らなくて良いし、
しらなくてもOKなようにブラウザが仲立ちしてくれるんだから、そもそも
友達の知識なんかきにすんな、とマジレス。

520 ：Name_Not_Found：04/04/27 13:49 ID:???

友達に認めてもらえないと何も出来ない奴って滑稽

>>518
オレオレうるさい

521 ：Name_Not_Found：04/04/27 16:42 ID:???

俺はっ達観した
class名にきどった名前つけても意味がないならdivをそのまま使う
divには区切りっていみもあるらしいじゃねーか
それで十分だ。

522 ：Name_Not_Found：04/04/27 16:50 ID:???

>>520
それオレオレ

523 ：Name_Not_Found：04/04/27 17:01 ID:???

「らしい」とか言わずに仕様書嫁。
ttp://www.w3.org/TR/html4/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.

意味がないからいるとかいらないとかじゃなくて、識別子として id や class が
使えますよ、と言う話なんだから、（俺の文書では）divは一意で id や class は
いらない、っつーなら、勝手にすればいい。

524 ：Name_Not_Found：04/04/28 07:38 ID:???

class属性禁止、cssは隣接と子孫と子供で乗り切る。ＩＥ６はしらね。
とかいう狂信者いないの？

525 ：Name_Not_Found：04/04/28 10:15 ID:???

先日までそうですた。
XML宣言付きXHTML+隣接、子孫、子供でCSS。
でもIEの閲覧者が多すぎて折れた…orz

526 ：Name_Not_Found：04/04/28 10:41 ID:???

いたのか・・。
おつ。じきに世間、というかUAが君に追いつく。

527 ：Name_Not_Found：04/04/28 10:45 ID:???

もし class を CSS のためだけの
ものとでも思ってるなら信者失格。

528 ：Name_Not_Found：04/04/28 10:46 ID:???

乗り切るも乗り切らないも見栄えなんてデフォルトスタイルでいい派だけど
class属性はそれなりに使ってますが。

529 ：Name_Not_Found：04/04/28 13:25 ID:pIEfcXq+

classはたしかにcssの識別子だけではない。
しかしついついその目的で使ってしまう、で名称に苦しむ。
いくら論理的な名称を使用してもUAがなにかしてくれるわけじゃあるまいし。

530 ：525：04/04/28 13:32 ID:???

信者であろうとは思わないが一応普通に(？)classは使ったよ。
<span class="date">は使ったけど見栄えの為のclassは使わんかったというだけ。
今はIEの為にXML宣言抜いて<div class="section">とか使ってる。

XHTML2.0勧告ｷﾎﾞﾝﾇ…

531 ：Name_Not_Found：04/04/28 13:37 ID:???

勧告されても IE は対応しない罠

532 ：Name_Not_Found：04/04/28 13:38 ID:???

<table summary="武器と値段表。">
<thead>
<tr><th>破邪の剣</th><th>モーニングスター</th><th>鋼の剣</th></tr>
</thead>
<tbody>
<tr><td><img src="hajya.jpgl" alt="破邪の剣" /></td><td><img src="moon.jpg" alt="モーニングスター" /></td><td><img src="steel.jpg" alt="鋼の剣" /></td></tr>
<tr><td>4800</td><td>5000</td><td>9000</td></tr>
</tbody>
</table>

ここで気づいたのですが、thとaltが同じです。音声UAの方や画像を切っている方にはおなじこと何度もいわれてうざいっすかね？
どうすりゃいいですか？

533 ：Name_Not_Found：04/04/28 13:39 ID:???

>>531
いや、むしろMozillaの入り込む余地が出来るかも・・・

534 ：Name_Not_Found：04/04/28 13:40 ID:???

>>532
何の表？

535 ：Name_Not_Found：04/04/28 13:43 ID:???

例はドラゴンクエストの武器の表です。
他に、ネトゲのwebとかを作ってると、アイテムの画像を使用する機会が多いのですが
どうしたものかと思案に暮れております。

536 ：Name_Not_Found：04/04/28 13:51 ID:???

alt=""

537 ：Name_Not_Found：04/04/28 13:55 ID:???

やはりそれですか、結構前だけど
俺は空altは許さん！と言っていた信者様がこのスレにいたのでどうしようかと思ってました。

538 ：Name_Not_Found：04/04/28 14:01 ID:???

>>537
W3C自身が装飾的な画像にはalt=""を設定すべしと言っているので
そんな奴はきにしなくてもOK。

ttp://www.w3.org/TR/html4/struct/objects.html#alternate-text>Do not specify irrelevant alternate text when including images
> intended to format a page, for instance, alt="red ball" would be
> inappropriate for an image that adds a red ball for decorating a
> heading or paragraph. In such cases, the alternate text should be
> the empty string ("").

539 ：Name_Not_Found：04/04/28 14:18 ID:???

装飾というか、どちらかというと画像はメインっぽいんすけど。
例のドラクエはまあ武器の画像にそれほどの情報はないのでそれでもいいですけど
他のネトゲの表は画像もかなりの情報になるんです。
その表の画像を見て、同じ形のアイテムを探すといった目的もあるので。
他の例を出すと

<table summary="全国指名手配逃亡者の表">
<caption>あ！この顔だ。</caption>
<thead>
<tr><th>氏名</th><th>味噌田味噌男</th><th>麻原ショウコウ</th><th>ケンシロウ</th></tr>
</thead>
<tbody>
<tr><th>顔写真</th><td><img src="misoda.jpg" alt="味噌田味噌男" /></td>
<td><img src="asahara.jpg" alt="麻原ショウコウ" /></td><td><img src="kenshiro.jpg" alt="ケンシロウ" /></td></tr>
<tr><th>容疑</th><td>窃盗</td><td>大量殺人</td><td>大量殺人</td></tr>
</tbody>
</table>

お尋ね者の表ですが、thの名前もtdの写真もともに重要な情報になります。こうゆう場合のaltも""でいいですかね？

540 ：Name_Not_Found：04/04/28 14:19 ID:???

元のHTMLは以下の様にして画像に武器の名前を入れた方が良いんじゃないの？

<table summary="武器と値段表">
<thead>
　<tr>
　　<th>武器</th><th>値段</th>
　</tr>
</thead>
<tbody>
　<tr>
　　<td><img src="hajya.jpg" alt="破邪の剣" /></td><td>4800</td>
　</tr>
　<tr>
　　<td><img src="moon.jpg" alt="モーニングスター" /></td><td>5000</td>
　</tr>
　<tr>
　　<td><img src="steel.jpg" alt="鋼の剣" /></td><td>9000</td>
　</tr>
</tbody>
</table>

541 ：Name_Not_Found：04/04/28 14:27 ID:???

しかしそれでは武器の名前が分からないというか・・そのゲーム、形は同じで色違いの武器も多いし・・名前もどうしても読めるようにしたいのですよ。
すみません。
ただ、ゲームの表云々でなく、このようなときどう画像と題名をstrict的にマークアップするか興味あります。

542 ：Name_Not_Found：04/04/28 14:35 ID:???

>>541
画像が出なければ alt の代替テキストが表示されるし、>>540でいいんじゃ？
画像が出なかったら色もへったくれもないでしょ？
代替テキストで色形を詳しく説明しない限りは。

代替テキストの表示のされ方が気に入らないってんならしょうがないが。

543 ：Name_Not_Found：04/04/28 15:11 ID:???

表示の問題ならCSSだしね。

544 ：Name_Not_Found：04/04/28 16:23 ID:???

画像が無くなると意味の無い表なら
そもそも音声ブラウザを気にする必要は無いだろ。

545 ：sage：04/04/28 16:47 ID:eva6bDuA

最近Operaを Cached images only で使ってるんだが、
alt="" だと、そこに画像があることすらわからない。
代替テキストが表示されていれば、その画像だけ選択的に
ロードして、キャッシュにいれて見られるのだが、それも不可。
ページ全体の画像を一括ロードすれば見られるが、そうすると
装飾のための他の画像までロードさせられてしまう。

やっぱり、装飾ではなく、情報提供を目的とした画像には、
画像:破邪の剣とか味噌田味噌男(写真) みたいな
代替テキストが良いんじゃ…。

546 ：Name_Not_Found：04/04/28 16:49 ID:???

こういう場合のaltは「刀身が青い、大振りの両手剣」とか
電話口でその画像と同じことを相手に説明する時のような文章を書くべし。
武器の解説にそういうことを既に書いているなら、画像のaltは空でもいいと思うけど。

547 ：Name_Not_Found：04/04/28 17:29 ID:???

>>540 の最初のセルをこんな風に外だしすればいいんじゃないか？単純に。
<img src="hajya.jpg" alt="" />破邪の剣

画像が表示されようなされまいが武器の名前は表示されるし、
画像はないならないでぶっちゃけどうにかなるだろ、多分。

武器形状もデータとして伝えたいなら >>546 だけどな。

548 ：Name_Not_Found：04/04/28 17:53 ID:???

なるほど、参考になります。
546の案がいいと思ったのでやってみます。

549 ：Name_Not_Found：04/04/28 19:52 ID:???

メモ帳などにコピペして、等幅フォントで見てください。

┌―――――┬―
ト　原子番号｜
｜＼価電子数｜　　　（表の左上の部分を拡大したと思ってください）
｜　￣￣＼　｜
｜周期　　＼｜
├―――――┼―
｜　　01　　｜

こんな風に、「見出しセル」がいくつもあると、データも
「Sr 38 2」みたいに複雑になりますが、これを音声ブラウザなどを考慮した
マークアップをするとどんな感じになりますか？
今はセルを結合させていますが

550 ：Name_Not_Found：04/04/28 22:56 ID:???

>>549
そもそもHTML以前の（例えば紙の）段階で十分複雑な表は
HTMLにしてもやっぱり複雑なので、まず、複雑じゃない所まで
表を解体して、その状態をtable要素としてmarkupすることになる。

551 ： ◆FoxMX6a/hk ：04/04/29 01:08 ID:???

おまいら誰も img の title 属性の話をしないから、心配になって鳩丸見に行ったら書いてなくて、
ショック受けつつ仕様書邦訳見たらあったので、混乱しつつ原書見たらやっぱりあったじゃねぇかばかやろ。
というわけで、title 属性とか longdesc 属性とかも有効活用してやってくださいおながいします。
# ちなみに見たのは去年あたりにローカルに落とした版の鳩丸。

552 ：Name_Not_Found：04/04/29 02:03 ID:???

>>551
んなもん必要に応じて使えば良いだけで、必然性もなしに
あるからと言うだけで話題に出すな。ややこしくなるだけだから。

553 ：Name_Not_Found：04/04/29 10:10 ID:???

<h1><img src="http://img.2ch.net/img/hp_a.gif" alt="web製作板"></h1>

は異論なかろう。では

<p>web製作板のバナーを作りました、もらってやってください。</p>
<p><img src="http://img.2ch.net/img/hp_a.gif" alt="web製作板のバナー"></p>

はＯＫ？　俺はOKと思うんだが。　

554 ：Name_Not_Found：04/04/29 10:20 ID:???

<dl>
<dt>><img src="http://img.2ch.net/img/hp_a.gif" alt="web製作板のロゴ"></dt>
<dd>
web製作板の看板、バナーにしてもよし、勝手にもってけ。
</dd>

</dl>

555 ：Name_Not_Found：04/04/29 10:27 ID:???

<dl>
<dt><a href=http://img.2ch.net/img/hp_a.gif"><img src="http://img.2ch.net/img/hp_a.gif" alt="web製作板のロゴ"></a></dt>
<dd>web製作板の看板、バナーにしてもよし、勝手にもってけ。</dd>
</dl>
もらってけまで言うなからこうするのがよさそうだ。

556 ： ◆FoxMX6a/hk ：04/04/29 10:30 ID:???

<p>
<img src="http://img.2ch.net/img/hp_a.gif" alt="Web制作板のバナー"
longdesc="Web制作板のバナーを作りました。もらってやってくだしあ。">
</p>
いや、別に意地になってるわけではないんだけども（ｗ
なんか似たような話したよね、本文で触れるグラフを画像でどうとかって。

557 ：Name_Not_Found：04/04/29 10:35 ID:???

とりあえず、
・画像が見えようが見えまいが見えているべき文章（地の文章）
・画像が見えないときだけ見えているべき文章（いわゆる代理文字）
・画像が見えているときだけ見えているべき文章（画像が見えている前提での画像の解説とか）
とりあえず、この３パターンに分けて考えれば良いだけの話。

何でこの程度の話が定期的にpopするのか、そっちの方が不思議だ。

558 ： ◆AKA//SI/L. ：04/04/29 11:31 ID:???

>>556
longdescの内容はURIですよ。
http://www.w3.org/TR/html401/struct/objects.html#adef-longdesc-IMG

559 ：Name_Not_Found：04/04/29 11:36 ID:???

だってネタがないもん。

560 ：Name_Not_Found：04/04/29 17:11 ID:???

>>549
Strict 的には axis 属性じゃないかな?

561 ：Name_Not_Found：04/04/29 17:45 ID:???

うーん。画像の重要度ってのは、
1. 装飾 (桜の花びらを散らしてみました。うふ。)
2. 装飾付き文字 (会社ロゴとか。)
3. 画像情報そのもの。(証拠写真の類。)
の順に高くなって、
1.を alt=""、 2.を alt="会社名" ってのは全員同意でしょ。
で、3.を alt="" にするのは、明らかにまずいよね。
なんだか、そう主張してる人がいるように読めるので確認。

562 ：Name_Not_Found：04/04/29 19:39 ID:???

>>561
基本的に同意。

ただし、地のテキスト読めば画像がなくても良いような場合、
例えば図がグラフで、地のテキストに数式とその数式の解説として既に
「右肩上がりの曲線が…」など書かれている場合は、改めて
画像の代理テキストを出しても単にくどいだけなので、alt=""にしてる。

563 ：Name_Not_Found：04/04/30 00:24 ID:???

hoge
↓
hoge
<ins>hoge2</ins>
↓
hoge
<del><ins>hoge2</ins></del>
<ins>hoge3</ins>

追加に対しての修正って、こんな事しなくても良いよね？

564 ：Name_Not_Found：04/04/30 00:27 ID:???

altはつけるだけじゃなくて
http://w3j.org/articles/practicalaccessiblehtml/practicalaccessiblehtml01.html

565 ：Name_Not_Found：04/04/30 00:33 ID:???

>>563
母さん、したほうが良いと思うんだ。
思い出は残すべきだよ。

566 ：Name_Not_Found：04/04/30 00:53 ID:???

>>563
Strictスレ的にはせねばならない。
せねばならないが、別に罰則があるわけでも、DTD違反になるわけでもないので
頻繁に手が抜かれる。

567 ：Name_Not_Found：04/04/30 01:36 ID:???

hoge
↓
hoge
<ins>hoge2</ins>
↓
hoge
<del>hoge2</del>
<ins>hoge3</ins>

こうしてもいいか？って事ではないだろうか。

>>563のままがいいとは思うけど。

568 ：Name_Not_Found：04/04/30 01:40 ID:???

hoge
↓
hoge
hoge2
↓
hoge
hoge3

569 ：Name_Not_Found：04/04/30 01:48 ID:???

>>565-567
サンクス
>567の通りだけど、>563のようにする事にするよ。

570 ：Name_Not_Found：04/04/30 18:27 ID:???

>>561で思ったというか前から思ってたんだけど。

<p>妹はテスト前にまったく勉強しませんでした。
その証拠に、勉強していれば絶対に解ける問題を間違えています。</p>
<ul>

a) <li><a href="picture-1.jpg">証拠写真-1：妹の答案</a></li>
b) <li><img alt="" src="picture-1.jpg"></li>

</ul>

a)のa方式とb)のimg方式と、どっちにするか。liにするかどうかはともかくとして。
b)のaltはとりあえず空にしておいたけど、本当は画像が表示される環境と
できるだけ近い情報が得られないといけない。
そうすると、テキストで彼の答案を再現したり問題点を直接指摘したりすることになる。
でもそれはちょっと不自然だと思う。たぶんみんな思う。
ならb)はだめかというと――だめだということにするとa)になるわけだけど、
やっぱり画像が表示できるならそこに表示してもらいたい。
でも表示できない環境ではアンカーを表示してもらわないと困る。
altの値をマークアップしたくなる。
じゃあobjectじゃん、となるわけだ。

いつも同じように悩んでいつも同じ結論に辿り着くんだけど。
いやマジで。

571 ：Name_Not_Found：04/04/30 19:17 ID:???

>>570
＞じゃあobjectじゃん、となるわけだ。
ならobjectを使えばいいのでは。
そのケースで言えば、テキスト等による答案の再現にlongdesc属性を使ってもいいような気がする。

572 ：Name_Not_Found：04/04/30 19:53 ID:???

<p>妹はテスト前にまったく勉強しませんでした。
その証拠に、勉強していれば絶対に解ける問題を間違えています。</p>

<dl>
<dt>証拠写真-1</dt>
<dd><a href="picture-1.jpg"><img alt="妹の答案" src="picture-1.jpg"></a></dd>
</dl>

573 ：Name_Not_Found：04/04/30 21:12 ID:???

ins?del?
間違ってたらこっそり直すよ、それで終わり。

だめなん？

574 ：Name_Not_Found：04/04/30 21:31 ID:???

>>573
修正履歴が不要なら別にいい。

575 ：Name_Not_Found：04/04/30 21:53 ID:???

Web標準準拠サービスなんてのがあるんですね。
http://www.mitsue.co.jp/service/produce/standards.html

576 ：Name_Not_Found：04/04/30 22:35 ID:???

ごめんbloxkquoteのcite属性のciteってwebサイトのサイトだと思ってた。

577 ：Name_Not_Found：04/04/30 23:12 ID:xl4qlq+6

blockquoteな。英語は必須じゃないけどciteとsiteも違うし、
ちっとはしっといたほうが便利よ。

578 ：Name_Not_Found：04/05/01 00:47 ID:???

あなたのWebサイトをW3C準拠に
http://slashdot.jp/articles/04/04/30/1419213.shtml?topic=74

579 ：Name_Not_Found：04/05/01 00:51 ID:???

>>575 >>578
宣伝ウザイ

580 ：Name_Not_Found：04/05/01 00:55 ID:???

こんなストリクターしか覗かないスレで宣伝しても儲からないよなあ

581 ：Name_Not_Found：04/05/01 01:02 ID:???

div多いな

582 ：Name_Not_Found：04/05/01 01:04 ID:???

>>580
このスレ的にはダメダメサイトの見本だし。
それにmoz属性使いまくりのスタイルシート、久々に見たw

583 ：Name_Not_Found：04/05/01 02:14 ID:???

あー。しまった。
俺、DOMインスペクタでさらっと見てから
「結構まともじゃん。企業サイト的にはこの辺が落とし所かなー」
などとStrictオタらしからぬ考えを。

584 ：Name_Not_Found：04/05/01 03:43 ID:???

blockquoteの出典をblockquote内にcite要素で書く人は、
qの出典もq内にcite要素で書くのかな。

<q>過ぎたるは及ばさるがごとし<cite>孔子</cite></q>

585 ：Name_Not_Found：04/05/01 08:26 ID:???

>>584
オレは書いてるよ。
同じ作品から3回くらい引用する場合、1回目のみcite要素に書いて、
2回目以降はcite属性にしてる。

あと、cite要素の内容は引用内容ではないのでq要素の子要素としてcite要素は
書いてない。

586 ：Name_Not_Found：04/05/01 10:46 ID:???

>>585
やり方はよくわかったが、cite要素ってq要素の中身になりえるか、の説明ははしょってるよな

587 ：585：04/05/01 15:29 ID:???

>>586
>cite要素の内容は引用内容ではないのでq要素の子要素としてcite要素は書いてない。
指摘を受けて追加の説明を書こうかと思ったが、これ以上の説明が思いつかん。

588 ：Name_Not_Found：04/05/01 21:05 ID:???

>>584
俺はそう。だってさ、引用部分との関連があることが分かりやすいだろ？

本当はこうしたいけどな
<引用情報>
<出展>俺</出展>
<引用部>こんにちは世界</引用部>
</引用情報>

589 ：Name_Not_Found：04/05/02 15:22 ID:???

引用内容でないものを引用内容としてマークアップするのは
どう考えても間違いだろ。
「本当はこうしたい」の部分は同意だけど。

590 ：Name_Not_Found：04/05/02 15:39 ID:???

<p><cite id="q1" href="http://pc5.2ch.net/test/read.cgi/hp/1076693129/589">Strict-HTML スレッド18 の 589</cite>が
　<quote cite="#q1">
　　<p>引用内容でないものを引用内容としてマークアップするのはどう考えても間違いだろ。</p>
　　<p>「本当はこうしたい」の部分は同意だけど。</p>
　</quote>
　と言っているが、俺はこんな感じのを望む。quote 要素内をマウスオーバーすると、cite 属性内の id に対応する cite 要素の内容がポップアップされ、さらに href 属性の値の URI に飛べる。フォームの label 要素と for 属性の関係とは真逆、かな</p>

591 ：Name_Not_Found：04/05/02 15:41 ID:???

</body>の直前における
<div id="hoge"><a href="#TOP">ページの先頭に戻る</a></div>

これって、"hoge"は何が適当かな？"navigation"は違うと思うし……。
そもそもそんなアンカーｲﾗﾈ、という突っ込みはナシの方向で、おまいらの意見を聞かせて下さい。

592 ：Name_Not_Found：04/05/02 15:59 ID:???

>>588
これならどっちを選ぶ？


<blockquote>
<cite>俺</cite>
<div>ここのdivは有無どちらでも。適当にクラスつけとくということで</div>
</blockquote>


<div>
<cite>俺</cite>
<blockquote>ここのdivは有るほうがいいかも。適当にクラスつけとくということで</blockquote>
</div>

593 ：Name_Not_Found：04/05/02 16:01 ID:???

>>591
漏れは[Home]キー一発だし、特につけていないが、
俺がつけるとしたら、navigationの中に一緒に入れる。
｜はじめへ｜前の章｜次の章｜おわりへ｜ページ先頭｜
みたいな感じで。markupはliな

594 ：Name_Not_Found：04/05/02 19:08 ID:???

>>592
あのさぁ、>>588は、既存のblockqouteとは別に、引用ブロックをもうけて
そこに出典元情報と引用内容を表示できるようにして欲しいと言っているだけ何じゃないか?

わざわざ要素名を日本語名にしているのはその為かと思われ。
既存の概念に引っ張られすぎ。

おそらく>>588のやり方をむりやりHTML4.01風にするとこうなる。
<div class="quote">
<cite>俺</cite>
<blockquote>こんにちは世界</blockquote>
</div>

595 ：Name_Not_Found：04/05/03 00:51 ID:???

>>594
パターンBがそれじゃないの？

596 ：Name_Not_Found：04/05/03 09:48 ID:???

>>595
解っているなら「どっちを選ぶ」とは成らない。

597 ：Name_Not_Found：04/05/03 10:52 ID:???

現状として<引用情報>となりえる要素が存在しないのだから>>590が理想かとおもた。

598 ：Name_Not_Found：04/05/03 12:40 ID:???

ポップアップするとか、しないとか言うのはブラウザ側の制御なので
HTMLと関係ない。やりたきゃスクリプトとかで勝手にやればいい。

後citeの情報を一括表示するとか言うのも、単に書き上がったHTMLを後で置換
処理すればいいだけの話で手書きのときに手抜きする手段もHTMLが気にすることじゃない。

要するに現状でcite要素とq、blockquote要素を結びつける手段さえあれば、
それ以上はイラネ。

599 ：590：04/05/03 13:10 ID:???

>>598
> ポップアップするとか、しないとか言うのはブラウザ側の制御なのでHTMLと関係ない。やりたきゃスクリプトとかで勝手にやればいい。
もちろんそうよ。ただ実装上の例・理想を言ったまで。(思いっきり言葉足らずだったが)

> 後citeの情報を一括表示するとか言うのも、単に書き上がったHTMLを後で置換
> 処理すればいいだけの話で手書きのときに手抜きする手段もHTMLが気にすることじゃない。
よく解らないのだが、要するに以下のようなものでも構わないということなのかな?

<p><cite id="q1" href="http://pc5.2ch.net/test/read.cgi/hp/1076693129/589">Strict-HTML スレッド18 の 589</cite>が
　<quote for="#q1" cite="http://pc5.2ch.net/test/read.cgi/hp/1076693129/589">
　　<p>引用内容で...</p>
　　<p>「本当は...</p>
　</quote>
　と言っているが...</p>

> 要するに現状でcite要素とq、blockquote要素を結びつける手段さえあれば、それ以上はイラネ。
cite と q/blockquote を結びつけた上でさらに URI を記述するのは冗長かと。

600 ：Name_Not_Found：04/05/03 13:19 ID:???

>>599
「Strict的には <quote> にtitleも入れるべし」となったらさらに冗長度が増すな。

<quote for="#q1" cite="http://pc5.2ch.net/test/read.cgi/hp/1076693129/589" title="Strict-HTML スレッド18 の 589">

601 ：Name_Not_Found：04/05/03 13:31 ID:???

それだと、もうCITE要素は要らないんじゃ？

引用元が文章内に一つならCITE要素で、複数ならCITE属性とTITLE属性でいいじゃん……。
つまらない意見でｺﾞﾒﾝﾖ。

602 ：Name_Not_Found：04/05/03 14:41 ID:???

>>599
>cite と q/blockquote を結びつけた上でさらに URI を記述するのは冗長かと。
だからURIたciteであれば、それで良いじゃん。

お前の意見はURIを毎回書くのがめんどくさいから手を抜きたい、と言ってるようにしか
オレには聞こえなくて、そんな物はあとで正規表現で置換でもしてろとオレは言いたい。

オレみたいに「今までの物」に固執する必要もないが、それなりのメリットがないと
新しい物に移行するのは単に混乱と誤用を増やすだけ。

603 ：Name_Not_Found：04/05/03 14:59 ID:???

そもそもcite要素とquoteをまとめる必要があるのか。
別にcite要素はquoteの為ではないし。

> 要するに現状でcite要素とq、blockquote要素を結びつける手段
が欲しいのなら>>594みたいなdiv。

604 ：Name_Not_Found：04/05/03 15:01 ID:???

>>603
それだと、現状のHTMLで関連性の意味付けの保証が出来てないってのが
問題だよな。だからXHTML2.0ではなんか欲しい、と言うことだと思う。

まぁ、それ以前に結びつけたきゃ、URIはcite属性で、文字列はtitleにかきゃ
十分なんだが。

605 ：Name_Not_Found：04/05/03 23:56 ID:???

というか、>>588みたいな構造は致命的な問題があって、
出典と引用部がくっついていたり>>590の例のように近かったりする保証がないから
わざわざ要素を定義した割にはあまり効果が無い。
要素として明示する以上はくっついてたり近かったりしないとひとまとめにしにくいから。
やるなら出典要素にfor属性、引用部要素にid属性かな。

606 ：Name_Not_Found：04/05/04 00:25 ID:???

じゃあ、くっつけたり、近くしたりすればいいじゃん。

元の文章構造をHTMLで無理して保つ必然性なんて全然ないし。

607 ：Name_Not_Found：04/05/04 00:46 ID:???

ぶっちゃけcite属性が表面的にレンダリングされないから、外にcite要素を置かなくちゃならない現状になってるんじゃないのか、と邪推。
ブラウザ側の仕様の問題だ、と言え折り合いつけようとした結果な気ガス

608 ：Name_Not_Found：04/05/04 00:56 ID:???

>レンダリングされないから、
それこそcssで勝手にすればいいだけの話であってHTMLは関係ない希ガス

609 ：Name_Not_Found：04/05/04 01:00 ID:???

>>608
違うんよ。
そうなのに、cite要素を使う理由、ってのを書いたんよ。
だって、cite属性だけでなんで不足だと思うの？
実際blockquote要素に出典情報書いてるのに。

他に理由が思いつかない。

610 ：Name_Not_Found：04/05/04 01:22 ID:???

>>609
えーっとまず、cite要素と属性はテキストとURIで格納する内容が違うよな。
まず、そこで対応させてるのがおかしい。

んで、テキストを格納する属性はciteじゃなくてtitle。
で、title属性が汎用属性になったのは4.0から。

なんでオレとしてはtitle属性があるのにcite要素が存在するのは
歴史的経緯だと思ってる。

611 ：Name_Not_Found：04/05/04 09:36 ID:???

>>606
それはなんか違わないか？
元になる文章があって、それに追加する形でHTML化するというのが
あくまでも基本だと思うんだけど。
HTML化するためにわざわざ元の文を書き直す必要があるのでは
マークアップ言語としては不便すぎる。

現状ではtitle属性を使えば一応の記述はできるけど、
それはq/blockquote側から見た解決にしかなっていないわけで、
cite要素側の高機能化としての>>590みたいな拡張があってもいいと思う。
文末に参照文献を並べたりする時に便利だし。

612 ：Name_Not_Found：04/05/04 09:51 ID:???

>>611
HTMLと言う新しいメディアに、既存のメディア（例えば紙とか）の文章を
移行するにあたり、ハイパーリンクとかそういう物を利用して文章を書き直すのは
当たり前の行為では?　例えば注釈の書き方とかが解るのは一般的だろ?

他の文章への言及という「引用」がハイパーリンクの存在を前提にした
HTMLにしたら、元の形式が変化することの方がむしろ普通では?

613 ：Name_Not_Found：04/05/04 15:50 ID:???

>>612
それがまさにhere症候群なのでわ。
「はじめにテキストありき」ならハイパーリンクも何も忘れて書かなければならないはず。

あるいは、本をそのままマークアップして不自然になるわけがないと思う。
括弧とか枠とかをつけてある注釈を切り取って脚注みたいにするとしても
それはハイパーリンクが無くても同じことはまったく同じようにできるし。
HTMLだからどうだとかメディアが変わったからどうだとか、そういうのは関係無い。

614 ：Name_Not_Found：04/05/04 19:39 ID:???

変更の程度による、としか言えないのでは。
>>606の例でなら、参照元と引用部が対応することによるメリットと、
意図した文章構造がとれないことによるデメリットのどちらが大きいかによる。

そんなのケースバイケースだから、588式よりも汎用性が高く
どっちにも対応できる599式の方が便利だと思う。
まあどっちにしろ空想の話だけど。

615 ：Name_Not_Found：04/05/05 00:01 ID:???

>>614
まぁそういうことだと思う。
ただ、空想の話って言っちゃうなら、理念としての「はじめにテキストありき」のほうが強そうだけど。

616 ：Name_Not_Found：04/05/05 00:50 ID:???

>>613
>「はじめにテキストありき」なら
つまりこの段階で合意が取れていない。

俺は、メディアによってテキストは変化すると主張している。

617 ：Name_Not_Found：04/05/05 11:01 ID:???

>>610
> なんでオレとしてはtitle属性があるのにcite要素が存在するのは
> 歴史的経緯だと思ってる。
...quoteを伴わない文献名のみの記述があり得るからだってば。

618 ：Name_Not_Found：04/05/05 12:06 ID:???

>>616
メディアの差異に起因する必然的な変更ならば確かにそういう面はある。
が、実現するとしたら>>588案と>>599案どっちが便利か、という架空の話を
している時に、599案を捨てて588案を採るべきという>>606での主張がそれと
どうつながるのかわからない。
588の方が599に比べて、よりHTML的な長所を生かせる手法だという主張？
特にそうは思えないんだが。

619 ：Name_Not_Found：04/05/05 15:22 ID:gsjTSV0X

>>612にちょっと賛成。
そもそも文書を書くための地の言語（日本語や英語など）自体が、マークアップによる明示的
な構造の導入にしたがって変化（改良）していくのもありではないかと思うんだけど。

だめ？

620 ：Name_Not_Found：04/05/05 16:08 ID:???

総論としてはあり。
でも、今現在の規格として588みたいなマークアップがないんだから、
「そういうのは不便だから拡張するとしたら別のやり方がいい」
という指摘があった時に持ち出す話じゃないと思う。

あるマークアップ規格を使って文章を書く時に、その規格に合わせて
構造を変化させるというのは確かにあり。
でも、だからと言ってその規格の持つ短所が無かったことになるわけではない。

621 ：Name_Not_Found：04/05/05 18:19 ID:???

メディアの影響をテキストがまったく受けないっていうのは確かにあり得ないけど、
その影響はなるべく抑えるべきだと思う。

622 ：Name_Not_Found：04/05/05 20:36 ID:???

>>621
＞その影響はなるべく抑えるべきだと思う。
嫌みとかじゃなくて、純粋に疑問。なんで？

たとえば、紙媒体では、どうしてもページという概念が発生したり、
あるいは、ハイパーリンクやtitle属性による情報の埋め込みが出来ないから、
仕方なく脚注ページが本の後ろにあったりする。

こういうのってのはHTML化するときには積極的にHTMLの利点を生かした方向に
どんどん変えていくべきだ、と俺は思う。
（じゃなきゃHTML化する意味がない。単に世界に公開するだけならプレーンな
テキストでも十分）

623 ：Name_Not_Found：04/05/05 21:30 ID:???

埋め込みやtitle属性、ハイパーリンク化に反対してる人は別にいないのでは。
意図があって特定の構造にした地の文の方を変えなきゃいけないなら
問題だってことでしょ。

624 ：Name_Not_Found：04/05/05 22:32 ID:???

非ハイパーリンクメディアの引用元表記の構造って、
ハイパーリンクが存在するwwwでわざわざ保持して残さなきゃいけない物なの?

625 ：Name_Not_Found：04/05/05 22:50 ID:???

>>622
紙媒体の「別紙参照」とHTMLの「ハイパーリンク」みたいに変更に統合性があればいいと思うんだけどな。

626 ：Name_Not_Found：04/05/05 22:57 ID:???

>>624
「地の文」というなんだかんだ言って視覚媒体の慣習に引きずられがちな概念
を大事にする人たちはそういう気持ちが強いかもな。

627 ：Name_Not_Found：04/05/05 23:25 ID:???

>>624 >>626
普通に文章を書いていて、文章中に引用元が出てくるのって
別に珍しいことではないと思うんだけど。

<p>先日、<cite>「○○○○」</cite>という本を読みました。
これがなかなか面白い。何と言っても(以下感想続く)
その中に、こんな一節がありました。</p>
<blockquote title="○○○○">
引用
</blockquote>

逆に、なんでそこまで文章中の引用元をなくしたがるのかわからん。

628 ：Name_Not_Found：04/05/05 23:36 ID:???

>>627
> 普通に文章を書いていて
そこからはじめる人と、そうでない人の違いだと思う。

629 ：Name_Not_Found：04/05/05 23:38 ID:???

>>628
てことは、「HTMLは「文章ありき」だ」かどうか、から話をせんと平行線だ、ってことだな。
まあ>>616が指摘してるけど。

630 ：Name_Not_Found：04/05/05 23:50 ID:???

ありきが正しい！って言ってるわけではなく、プレーンテキストと同じ感覚で
書かれたテキストにも対応できればそれに越した事はないって話。
それだけ自由度が上がるんだから。
そうまでして599式より588式を推す理由って何？>>618でも聞いたんだけどさ。
それなりのメリットがあるなら、文章構造の自由度が減るというデメリットも
受け入れられるけど、そうでないならやっぱりfor/id式の方が便利そうだと
思うがなあ。

631 ：Name_Not_Found：04/05/06 00:08 ID:???

>>628
いや、それは無理があるだろ。
HTMLでは引用元について何か述べたい時にはその名前を書くべきでないと？

632 ：621：04/05/06 00:21 ID:???

HTMLの規格が>>588式になったとして、
そうするとどうしてもHTMLのマークアップのためだけにテキストを変えたくなるじゃん、と。
非ありき説の人でも>>588式に合わない文章が書きにくくなったらそれは大きなマイナスなはず。
これは>>627とか>>630とかと、言ってることはたぶんだいたい同じだけど。

例えば会話のとき、やたらと身振り手振りに頼るのは良くないと思う。
そうすると意味不明になりがち。
小説を本 (もちろん紙の、そのへんの本屋にあるやつ) で出すとして、やたらと挿絵や図を入れるのは良くないと思う。
ただの絵本みたいになりそう。

言葉をベースした情報伝達なら、<em>まずは</em>言葉に最大限の負担を掛けるのが筋じゃないかな。
<em>その後で</em>メディアの特性を考えて言葉の負担をある程度分散するとか。
メディア (つまり伝達の手段、あるいは道具) から制限を受けるのは仕方ないにしても、
それに「使われる」のでは、世界に人間だけでも60億いる情報の送り手の一人として純粋面白くないと思う。
何を以て「使われる」とするかは難しいけど。
自分はそういう意味を含めてありき説を支持してる。

>>622
影響というのは言葉足らずでした。
言いたかったのは以上に述べた通り。

>>626
いわゆる「地の文」が視覚媒体だけのものになるのかが分からない。
言葉を使うなら会話だろうがテレパシーだろうが点字だろうが、いわゆる「地の文」は存在すると思う。

633 ：621,632：04/05/06 00:28 ID:???

>>632の補足。
第2段落みたいなところのはあくまで「やたらと」というのであって、
もちろん身振り手振りとか挿絵や図とかを入れること自体が悪いというのではないです。
それに依存するのは面白くない、という意味。

あと、脱字で「純粋＜に＞面白くないと思う」でした。

634 ：622：04/05/06 00:36 ID:???

俺は逆だな
＞例えば会話のとき、やたらと身振り手振りに頼るのは良くないと思う。
＞そうすると意味不明になりがち。
それは、たとえば録音した場合とかであって、身振り手振りを使うことは
対面で話すなら陶然のことと思っている。

HTMLのばあい、最低保証として色とかは保証されないから、色に頼った
情報伝達はいけない訳だけれども、最低保証として色が保証されている
規格ならおれは、色にたよるのは、ありだと思う。（その規格自体の
ユニバーサル性はまたべつな）

したがって、対面で話す場合、相手が目が見えていて、ボディーランゲージが
つうじるあいてなら、当然俺は「使える手段は最大限に使う」

＞言葉をベースした情報伝達なら、<em>まずは</em>言葉に最大限の負担を掛けるのが筋じゃないかな。
言葉「しか」保証されいなら、言葉に負担をかけるが、言葉以外に保証された
伝達手段があるなら、「まずは」の段階でおれは手段を駆使する。

身振り手振りと、言葉をくらべて、言葉の優先順位を高める理由は俺にない。

同様にHTMLでも、使える手段は全部使うテキストを最初にありき、とする
理由がやっぱり分からない。

635 ：Name_Not_Found：04/05/06 00:38 ID:???

>>627
新しい引用文と引用元の関連付けに関してどうこういってるんであって、
そのレベルで現状のHTMLの地の文から引用元表示のテキストをなくそうと言う
うごきは、いま、このスレにはないんでは？

たんに、新しい引用もとの表記法なんかいらねーというだけで。

636 ：627：04/05/06 02:42 ID:???

>>635
そうなの？じゃあ結局>>624が何を言いたかったのかがよくわからないなあ。
紙媒体での数字付き注釈のような構造に限定した話？
でも地の文の話をしていたわけだし、>>628では依然否定的な回答だったし…

あと、
>というか、>>>588みたいな構造は致命的な問題があって、
>出典と引用部がくっついていたり>>590の例のように近かったりする保証がないから
>わざわざ要素を定義した割にはあまり効果が無い。
に対する
>じゃあ、くっつけたり、近くしたりすればいいじゃん。
という反論は、「>>627のような書き方ができなくなってもしょうがない、
それとのトレードオフでも>>588のような構造を導入する意義がある」としか読めない。

637 ：Name_Not_Found：04/05/06 04:26 ID:???

>>632-634
どっちもありなんじゃないの？
会話では、身振り手振りを使うことでわかりやすくなる場合もあれば
敢えて使わないことで言葉のみに集中させるのが効果的な場合もあるだろう。
絵本と挿絵無しの小説、どちらが表現手段として上というわけでもない。
メディアの特性としてむしろ大切なのは、状況・目的・好みに応じて
好きな手段を選べるというフレキシビリティの方じゃないだろうか。
HTMLにおいても同じことで、プレーンテキストにはない表現手段を駆使するのも、
元々プレーンテキストとして書かれた文章を最大限に生かすのも、
どちらも選択として尊重されるべきだと思う。

だから、HTMLならではの表現がないと意味がないというのも、
プレーンテキストとしての成立を前提にすべきというのも、
俺にはどちらも同じくらい受け入れがたい。

638 ：Name_Not_Found：04/05/06 08:46 ID:???

そうですか。

639 ：Name_Not_Found：04/05/06 09:08 ID:???

いろんな人が再三言ってるけど、cite要素とblockquote要素が関連付けられれば無問題なんじゃない？
id属性とfor属性で。

640 ：Name_Not_Found：04/05/06 09:26 ID:???

>>639
それにたいして、いろんな人がそんな物いらない、といっているのが今の流れでは？

641 ：Name_Not_Found：04/05/06 09:29 ID:???

>>640
そうなん？
「新しい要素はいらん」じゃなかったっけ？
cite要素とblockquote要素を統括する要素、とか出てて、
必ずしも近いわけじゃない→近くすりゃいい→だって近くない場合もあるもん
と。
で、「じゃあ、文章自体いじっちまえ」と「文章ありきだ」がどうこうやってるから。
どっちみち、関連付けできれば、どことどこにあっても問題なくなるわけで、近づけなくてもいいし、統括しなくてもいいし、文章自体を改変しなくてもいい、という答えにならないか？

642 ：640：04/05/06 10:21 ID:???

>>641
>>602-609 あたりでは、新しい要素（HTMLのエレメントという意味ではなくて
新しい"何か"の意）はいらない、という意見が出てないか？

で、現状で結びつけるとか何とか、その場合の欠点がどうしたとか、
そんな欠点はテキストを変更しちまえば云々、テキストありきが…。

という流れだと思っていたんだが。

643 ：Name_Not_Found：04/05/06 13:48 ID:???

いらないという意見も出てるが、欲しいという意見もいろんな人から出てるだろ。

644 ：640：04/05/06 14:23 ID:???

>>643
いや、だから、提案とか、それに対する肯定意見が有って(>>639)それに対して
いらないって意見が有って(>>640, >>642)、なんかもめてんじゃねーの？
と言うのが >>639 に対する >>640 の内容な訳だが。

645 ：Name_Not_Found：04/05/06 22:32 ID:???

idとforで結びつけるのも、機械で抽出するには便利。

646 ：Name_Not_Found：04/05/07 00:00 ID:???

個人的にはもともとuliがいっちしていれば、べつにいいや、と。

いらないけど、増えても困らない。

647 ：600：04/05/07 15:16 ID:???

>>590 案のまとめ。
<p>
　 <cite href="http://hoge.com/" id="hoge">ほげドット<em>コム</em></cite>では
　 <quote for="#hoge">ほげほげー</quote>と言われているが、
　 <quote cite="http://hage.jp/" title="はげ.jp">はげはげー</quote>と言う意見もある。
</p>
<p>また、
　 <quote for="#hoge">ほげはまげ</quote>ということに対し、
　 <cite href="http://hoge.net/">ほげドット<em>ネット</em></cite>では反対意見が挙げられている。
</p>

for (仮) と id の関係で、引用部「ほげほげー (3)」と「ほげはまげ (5)」のステータスは 1 によって明らかにされる。よって cite 属性は逐一書いてもいいし、書かなくてもいいと思われる。(i.e. >>599-600)
また、title 属性にその地位を奪われかけている cite 要素の存在意義は、引用はしないが出展を表す場合 (5) と、出展を何かしらの要素でマークアップしたい場合 (1, 5) にある。

648 ：647：04/05/07 15:19 ID:???

>>647

s/引用部「ほげほげー (3)」と「ほげはまげ (5)」/引用部「ほげほげー (2)」と「ほげはまげ (4)」/; # orz

649 ：Name_Not_Found：04/05/07 15:54 ID:???

ところでなんでforなの？
idを使う以上は、最初のciteはターゲットとしてURIで指定可能な訳だから
href="#hoge" で十分じゃん。

まぁ、十分という意味では、じゃあ従来通り大元のURIをciteに書けば十分に成るのだが。

650 ：Name_Not_Found：04/05/07 17:25 ID:???

>>649
「URIなんだからhrefでいいじゃん」ってのもよく解らんが
実際に指定したいのはURIではなくIDREFではないかと思われる。
まあforってのは単に既存の類似用途と思われる属性名の流用でしょ。
まともに導入を検討するとしたらあまり相応しい名前とは思えない。

651 ：649：04/05/07 18:14 ID:???

forがなくても、
<quote href="#hoge">…</quote>
とすれば、該当citeへのリンクが形成され、これによりquoteとciteの関連づけ
が行われる訳だから、for属性というのを新設する必要もないんじゃないの、と言う意味。
（新設するとかしないとかは、現在策定中のXHTML2.0基準）

或いはいっそのこと
<quote cite="#hoge">…</quote>
として、quoteの元になっているのは、本文書のcite要素の内容（つまりciteで示された引用元）
でも良いかもしれない、とたった今おもた。

652 ：Name_Not_Found：04/05/07 22:18 ID:???

>>647
まぁどっちでも良いと言えばそうかもしれないしあんまり本質的なところじゃないけど、idとforが逆かも。
出典のために引用したんじゃなくて、引用した(する)から出典を示した(示す)はずだから。

653 ：Name_Not_Found：04/05/07 22:23 ID:???

>651

hrefも相応しいとは思えないな

654 ：Name_Not_Found：04/05/07 22:25 ID:???

何故？

655 ：Name_Not_Found：04/05/07 23:04 ID:???

StrictなHTMLを書きたいんですけど、
詳しい書き方が載ってる日本語のサイトは無いのでしょうか？
紙媒体で手に入れるしかないのでしょうか？

656 ：Name_Not_Found：04/05/07 23:20 ID:???

>>654
ハイパーリファレンスしてないだろ？

657 ：Name_Not_Found：04/05/07 23:23 ID:???

>>655
> 詳しい書き方
ていうか、基本的な書き方以上のものはないと思うんだけど。
あとは既定の文書型の範囲内で構造化するだけでしょ。

そのへん既に学んだ上で
「～をマークアップするには」みたいな個々の事例の定番を求めてるなら
恐らくWebでも紙でも殆ど資料はないと思う。

658 ：655：04/05/07 23:36 ID:???

すいません。
基本的な書き方の日本語のページをお願いします。
自分はほとんどStrict-HTMLを知らないので・・・。

659 ：Name_Not_Found：04/05/07 23:49 ID:???

>>658
>>3 でも紹介されているけれど

ごく簡単なHTMLの説明 ttp://kanzaki.com/docs/htminfo.html

もし何らかのHTMLもどきを既に知ってしまっているなら
逆に戸惑うこともあるかと思うので頭の中をまっさらにして読むこと。

660 ：Name_Not_Found：04/05/08 02:09 ID:???

>>656
ABBRのTITLEもTITLEじゃないけど略語の解説してるし、
要するに決めの問題。

まぁ決めの問題って言ったら、何だってそうな訳だが。

661 ：Name_Not_Found：04/05/08 09:25 ID:???

> ABBRのTITLEもTITLEじゃないけど略語の解説してるし
そういう例外は少ない方が一貫性があっていいと俺は思うわけだが。
abbrやlink rel=stylesheetのtitleの例外的用途も
できれば別の属性にしてもらいたいくらいで。

662 ：Name_Not_Found：04/05/08 11:25 ID:???

>>661
一貫性があると言い、と言う意味では上記で「いろんなやり方が容認される方が良い」
とあるが、出来るだけ単純に、文字通り機械的に判断できるようにならないかな。

例えば似たような用途の要素が2種類あるとXSLのコードが肥大化する
デメリットを、表現の自由（メリット）が上回るかどうか、と言うことで。

統一しろ!と言うのではなくて、良い所取りをして欲しい、と言う意味で。

663 ：Name_Not_Found：04/05/08 17:32 ID:???

>>658
ttp://www.asahi-net.or.jp/%7Esd5a-ucd/www/
HTML4.01の仕様邦訳を書いた人。内田といえばここ。神崎と並んで有名。

664 ：Name_Not_Found：04/05/08 18:06 ID:???

>>662
RelaxNGの様に基本的な要素とシンタックスシュガーを用意してシンタックスシュガーを使った形から基本的な形への変換方法をちゃんと決めておくのがいいなぁ。
書く方はいろんな書き方できて処理する方は基本的な方だけ処理すればいいって形で。

665 ：Name_Not_Found：04/05/10 23:18 ID:???

初心者スレから誘導されたので質問させて下さい。
<title>・<alt>属性内の文字列にも、文字参照を使うのでしょうか？
使うと思うのですが、わざと画像のリンクを間違えて見た時、特殊文字部分の
表記が変なので迷った次第です(IE5.5)。
宜しく。

666 ：Name_Not_Found：04/05/10 23:49 ID:???

回答じゃないんだけど。実装をあてにせず仕様書見てみれ

667 ：Name_Not_Found：04/05/10 23:55 ID:???

>>665
仕様に書いてある。
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/struct/global.html#h-7.4.3

ここからリンクをたどると↓に行き着くはず。

http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/types.html#type-cdata

668 ：Name_Not_Found：04/05/11 00:23 ID:???

> 宜しく。
　漏れが気が短すぎる所為か、異様にムカつく。

669 ：Name_Not_Found：04/05/11 07:25 ID:???

ええ、無礼だと思います。

670 ：Name_Not_Found：04/05/11 08:05 ID:???

700

671 ：Name_Not_Found：04/05/11 15:12 ID:???

気が早い。

672 ：Name_Not_Found：04/05/11 16:14 ID:???

2ｹﾞｯﾄ

673 ：Name_Not_Found：04/05/11 17:05 ID:???

XHTML3.0ﾏﾀﾞｰ?

674 ：Name_Not_Found：04/05/11 19:58 ID:???

時代はZHTML_

675 ：Name_Not_Found：04/05/11 20:39 ID:???

やっぱりMHTMLですよ

676 ：Name_Not_Found：04/05/11 21:23 ID:???

>>670-675
ワロタ。お前ら気が早すぎるんだよ

677 ：Name_Not_Found：04/05/11 22:30 ID:???

>>676
MHTMLは既に実在するぞ。RFC2557

678 ：Name_Not_Found：04/05/11 23:04 ID:???

OEがないと見れん規格なんて逝ってよし

679 ：Name_Not_Found：04/05/12 05:43 ID:???

日本語の文字コードはどれを使ったらいい？

680 ： ◆FoxMX6a/hk ：04/05/12 05:55 ID:???

>>679
あんまり Strict とは関係ないのでは。
鯖が HTTP Responce Header で指定してるならそれに合わせりゃいいし、
指定がないなら好きなの選んで meta で指定しれ。
それか、日本語は全部画像にしれ…… alt になんて書くのかという問題があるが（ｗ

半分忘れかけているのでちょっと曖昧だが、SGML 系では文字コードの指定がなければ ASCII に、
XML 系では UTF-16 か何かとして扱うことになってたと思う。

681 ：Name_Not_Found：04/05/12 07:34 ID:???

>>679
原則としては，IANAに登録されてるものならどれでもいい。
その上でベターを追求するならUTF-8がいいと思う。
http://www.w3.org/TR/japanese-xml/
これはXMLについてだが，XHTMLにも当然適用される。

Netscape2とか古いブラウザとの互換性を気にするなら
iso-2022-jpがいいんじゃないか。

682 ：Name_Not_Found：04/05/13 02:52 ID:mNNgjM2K

質問なのですがswfファイルのtype属性を

application/x-shockwave-flash

のように記述するのは正解でしょうか。
lintでチェックするとエラーになります。

683 ：682：04/05/13 03:16 ID:???

色々調べて出てきた答えが

「微妙」

でした。
<object>か、<embed>も微妙で
<a href="">使ってる人もいた。

684 ：Name_Not_Found：04/05/13 18:33 ID:???

>>683
embedとかいう要素はHTMLにないので、少なくともこのスレ的には不可。

swfだろうがhtmlだろうが、どれも平等にひとつの文書として捉えるんだ。
例えば一冊の本として考えてみよう。
そのときキミがしたいことはどういうことになるかな？
単に『abc.html』の中で「『xyz.swf』が面白いよ！」で言いたい？
『abc.html』っていう元の本の途中に『xyz.swf』っていう本を挟んで製本したい？
<a href="....">～</a>って書いたら、それは「～については....を参照せよ」ってこと。
「面白いよ！」って言いたいならそれは言及。つまり「参照せよ」だよね。
そうじゃなく挟んで製本したら、『xyz.swf』は『abc.html』の一部になる。つまり埋め込み。
そういうときはobjectを使おう。

これで良いですか。

685 ：Name_Not_Found：04/05/13 18:38 ID:???

文書というか、リソースだね。

686 ：Name_Not_Found：04/05/13 22:22 ID:???

http://www.tokyo-nazo.net/~tester/title.html#2004513
このネタはこのスレでいいのかな

687 ：Name_Not_Found：04/05/13 22:25 ID:???

>>686
ﾁｯｶﾞｰｳﾖｰ

688 ：682：04/05/14 02:37 ID:???

埋め込みと参照は理解しました。
で、自分は埋め込みでやってるんですがlintでチェックするとそこだけエラーになります。
｢TYPEは正しく書きましょう｣みたいな…
書いてるんですけどね…

689 ：Name_Not_Found：04/05/14 03:19 ID:???

>>688
日記書くなウザい。
どこがおかしいか聞きたいならソースだせ。

690 ：Name_Not_Found：04/05/14 04:41 ID:???

>>688-689
というか、どちらかというとこっち向きでは。
http://pc5.2ch.net/test/read.cgi/hp/1061741473/l50

691 ：Name_Not_Found：04/05/14 09:18 ID:???

>>682
「エラーになります」とか「…みたいな」じゃなくて、htmlのソースと
エラーの文面をそのまま書こうね。あとlintの種類も。
mime typeが悪いのか、lintが悪いのか、他の原因があるのか、
そもそもstrictスレ的な話題なのか、あなたの書き方では誰もわかりません。

692 ：Name_Not_Found：04/05/14 20:02 ID:???

application/x-www-form-urlencoded
のx-はいつ取れるんだろ

693 ：Name_Not_Found：04/05/14 20:14 ID:???

誰も登録しようとしてないんじゃないの？ text/javascript みたいに。

694 ：Name_Not_Found：04/05/14 20:19 ID:???

text/javascriptって登録されてるの?

695 ：Name_Not_Found：04/05/14 20:27 ID:???

IANAを見ればわかるが登録されていない。

696 ：Name_Not_Found：04/05/14 20:27 ID:???

>>困ってる人
ちょーばっさり言うと x- さえつければ何書いても良いよ。

697 ：Name_Not_Found：04/05/14 21:19 ID:???

>>696
一応そうだが建前上なんでも良いとはいえんだろ。
例えばx-javascriptとかなのると、（未定なんだから理論上衝突や侵害をしてる
わけではないのだが）十分に問題。それなりの配慮は必要かと。

698 ：Name_Not_Found：04/05/14 22:04 ID:???

>>697
それを言うなら、
建前上は何でもいいけど、現実的には問題、
ではないかと。

699 ：Name_Not_Found：04/05/14 22:59 ID:???

多くのサーバは
拡張子 .js に対して application/x-javascript を名乗るけど問題ないしね。

700 ：Name_Not_Found：04/05/14 23:09 ID:F98qP3VI

すんまそーん
ここSHTMLとは関係ないですよね？
shtmlやSSIのスレがココでもWebProgでも見つからないんですが
人気ないんですか？

701 ：Name_Not_Found：04/05/14 23:13 ID:???

>>700
SSIについて、なら初心者スレかな。
あっこは初心者、と銘打ってるけどサイト作成総合みたいなもんだから。

702 ：Name_Not_Found：04/05/14 23:56 ID:???

ああ、Strict-HTML略してSHTMLって事ね…

703 ：700：04/05/15 00:22 ID:???

>>701
ありがとう
専用スレないんですね・・・

704 ：Name_Not_Found：04/05/15 00:32 ID:???

>>703
SSIは専用スレ作るほど難しいもんじゃないだろ。

705 ：Name_Not_Found：04/05/15 01:08 ID:???

>>694
textじゃなくてapplicationじゃないの? とか、
javascriptってNetscape社のものじゃないの? とかで
もめたんじゃなかったっけ?

ここは application/ecmascript を登録という方向で動いて
いくべきなのかも?

706 ：Name_Not_Found：04/05/15 01:27 ID:???

>>705
何年か前に動いてたけど、結局却下されてなかったっけ？
text/javascript
text/ecmascript
application/javascript
application/ecmascript
4つとも。

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

ということは現状ではこうか。
<script type="text/x-javascript" src="..."></script>

708 ：Name_Not_Found：04/05/15 11:38 ID:???

>>706
これね。
http://www.websitedev.de/ietf/draft-hoehrmann-script-types-00.txt
これってまともに議論されてたの？
気がついたら期限切れになってたので、何となく
ロクな議論もなくシカトされて消えたようなイメージなんだけど。

709 ：Name_Not_Found：04/05/15 19:40 ID:???

>>708
やっぱり、application/ecmascript は話に挙ってないね。

710 ：Name_Not_Found：04/05/16 20:38 ID:???

では<hr>の意義についてどうぞ。

711 ：Name_Not_Found：04/05/16 20:59 ID:???

文章の区切り
罫線

712 ：Name_Not_Found：04/05/16 21:07 ID:???

文章の区切りなんて意味はない。
仕様嫁。
>horizontal rule
だからHRであって、和訳したら「横棒」とか「横罫線」であってそれ以外の意味はない。

横棒が引かれる＞人間には区切りとして見える＞区切りの意味がある
と言うなら B 要素だって
ボールドされる＞人間には強調して見える＞強調の意味がある
も認めなければならなくなるぞ。

713 ：Name_Not_Found：04/05/17 01:38 ID:???

>>712
つか人間以外のやつが見るのかよ？
地球外生命体だの未来から来ただのは無しで。

714 ：Name_Not_Found：04/05/17 01:42 ID:???

>>713
そう解釈しない人もいる、ってのが問題、ってことでしょ

715 ：Name_Not_Found：04/05/17 01:46 ID:???

>>713
人間以外のやつも見るだろ。

716 ：Name_Not_Found：04/05/17 01:52 ID:???

ていうか残りの人間はおまえだけだよ

717 ：Name_Not_Found：04/05/17 02:48 ID:???

>>712
UAがみる。

逆に普通の人間はソースを見ない。普通の人間はUAの解釈結果を見る。
だからHTMLの本質はUAが解釈出来るかどうかにかかっており、
その意味付けはHTMLの仕様に書かれている通り、杓子定規な意味しか持ち得ない。

718 ：717：04/05/17 02:50 ID:???

ごめ、>>717は>>713へのレス

719 ：Name_Not_Found：04/05/17 07:01 ID:???

>>718
UA は“見る”んですかそーですか。

720 ：Name_Not_Found：04/05/17 07:32 ID:???

http://pc5.2ch.net/test/read.cgi/hp/1081753565/

721 ：718：04/05/17 08:21 ID:???

>>719
揚げ足とったつもりかどうか知らんけど、頭は大丈夫か?

ttp://dictionary.goo.ne.jp/search.php?MT=%B8%AB%A4%EB&kind=jn

722 ：Name_Not_Found：04/05/17 08:30 ID:???

>>721
心配スンナ。
無知なのは>>719だとみんなわかってる。

723 ：Name_Not_Found：04/05/17 08:38 ID:???

うん

724 ：Name_Not_Found：04/05/17 17:54 ID:???

こ

725 ：Name_Not_Found：04/05/17 18:21 ID:???

まぁHTMLに見出し以外に「区切り」を表現できそうな要素が定められてない以上、
hrを「ちょっと区切りなような気がする何か」みたいに解釈するのもそう間違ってないわけではないこともないだろう。

ていうか1～2年前から<hn />みたいなのを考えてるんだけど、どう？
構造的に見出しはある(はずな)んだけど、たまたまそれが長さ0だったっていう解釈で。

726 ：Name_Not_Found：04/05/17 18:31 ID:???

＞みたいに解釈するのもそう間違ってないわけではないこともないだろう。
完璧に間違いな訳だが。

お前が個人的にそういうルールを決めてXSLTやscriptで処理するのは
問題ないが、Strictスレでそういう用法が一般に容認される様な発言は
明らかにＮＧ。

727 ：Name_Not_Found：04/05/17 18:36 ID:???

>>725
間違いも何も、仕様書に書いていない。
個人的な解釈ならご勝手に。

728 ：Name_Not_Found：04/05/17 18:37 ID:???

微妙にかぶった…

729 ： ◆osc/404/O. ：04/05/17 18:42 ID:???

hr 要素にはやられました。まぁ、自分の勘違いだったんだけど。

730 ：Name_Not_Found：04/05/17 20:03 ID:???

縦書き文章で水平な罫線が引かれてもあんまり意味がないのでhrはイラネ

#え、そういう意味じゃない？

731 ：Name_Not_Found：04/05/17 20:59 ID:???

そもそも縦書き文章などというものは

732 ：Name_Not_Found：04/05/17 21:20 ID:???

733 ：Name_Not_Found：04/05/17 22:22 ID:???

<rl />

734 ：Name_Not_Found：04/05/17 22:31 ID:???

735 ：Name_Not_Found：04/05/18 00:03 ID:???

<>>719 />

736 ：Name_Not_Found：04/05/18 00:07 ID:???

737 ：Name_Not_Found：04/05/18 10:24 ID:???

W3Cが各仕様につけてる「Recommendation」って、

WWW上で情報やりとりする時にこの仕様を使う事を推奨します。
が、別な規格を用いても構いません。

と言うレベルの話であって、例えばHTMLから派生した新しい仕様を作って
それを使用するのは勝手だけど、W3CのHTMLを、DTDやDOCTYPEをそのままに
「"推奨"なんだから要素の意味づけは部分的に変更してもOK」って訳じゃ
ないんだよね？

738 ：Name_Not_Found：04/05/18 11:41 ID:???

HTMLとは違う仕様を使ってるのにHTMLのDOCTYPE使っちゃダメだろ。
で、違う仕様ならHTMLと同じ要素で違う意味づけというのもアリだと思うけど。
UAが解釈してくれるかは別問題だし。

739 ：Name_Not_Found：04/05/18 15:33 ID:???

>>737
DTDを用意できるんなら、別の仕様のHTMLを使ってもいいってことだと思ってた。
ケータイ用のHTMLとか。

740 ：Name_Not_Found：04/05/18 15:41 ID:???

>>738
実はSGMLレベルで非互換とか。

741 ：Name_Not_Found：04/05/18 15:47 ID:???

そうして作った別の仕様のHTMLに、text/html をつけるのはアリなの？
個人的には(W3Cの)HTMLの文書型宣言つけるのと同じくらいNGだと思うんだけど。
# ISO-HTMLみたいにHTML4のサブセットになってるならまあ許容範囲かと思うけどね。

742 ：Name_Not_Found：04/05/18 15:56 ID:???

>>741
既にHTMLではない、と言う場合、text/x-myhtml みたいになるかなぁ。

…どう考えてもxmlベースにして広義に application/xml としたほうが楽だな。

743 ：Name_Not_Found：04/05/18 16:59 ID:???

application/x-html

744 ：Name_Not_Found：04/05/18 17:27 ID:???

SGMLのメディアタイプってなんだっけ？
殆どの場合、SGML / XMLの何かになるんだろ？

745 ：Name_Not_Found：04/05/18 17:52 ID:???

text/sgmlヵapplication/sgmlヵ?

746 ：Name_Not_Found：04/05/18 20:40 ID:???

RFC 1874 - SGML Media Types

747 ：Name_Not_Found：04/05/19 20:30 ID:???

ここで聞いていいかどうか分からないんですが、
会話をマークアップするときは、定義リストを使って
<dl>
　<dt>発言者名</dt>
　<dd>発言の内容</dd>
</dl>
という形にすることが多い（普通？）と思うんですけど、
これに議題等が付いてる場合は、
Strict的にはどんなマークアップだと好ましいんでしょうか？

例えば、
------------------
議題1
　A氏　「A氏の発言」
　B氏　「B氏の発言」
議題2…（以下略）
------------------
こんな場合、発言者名と発言内容は、定義リストにするとして
議題は定義リストの外に出して、見出しなどにしておくのが
妥当なんでしょうか。
議題とそれに対する発言は関連があることが分かるような
マークアップの仕方にするべきでしょうか？

748 ：Name_Not_Found：04/05/19 20:35 ID:???

とりあえず<h2>で議題を挟んで
発言とかは製作者のデザインによりけりだな

749 ：Name_Not_Found：04/05/20 07:33 ID:???

>>747
>議題は定義リストの外に出して、見出しなどにしておくのが
>妥当なんでしょうか。
見出し or 定義リストを入れ子にする。

>>748
デザインは関係無いよ。

750 ：Name_Not_Found：04/05/20 08:21 ID:???

>>749
「デザイン」を辞書で引け。

751 ：Name_Not_Found：04/05/20 15:17 ID:???

最近、あえて釣っている香具師が多いな。

752 ：Name_Not_Found：04/05/20 15:57 ID:???

その内、レイアウトとかスタイルの意味の2ch語「でざいん」が誕生するんじゃないか？
本物のデザイン系の板住人にぶん殴られそうだが。

ぬるぽ

753 ：Name_Not_Found：04/05/20 16:41 ID:???

ｷﾓｲ

754 ：Name_Not_Found：04/05/20 18:58 ID:???

>>752
> 本物のデザイン系の板住人にぶん殴られそうだが。
同意。というか他のweb板住民にもぶん殴られそうだ。
カスイケ住人とか。

755 ：Name_Not_Found：04/05/20 20:03 ID:???

釣り

756 ：Name_Not_Found：04/05/20 20:25 ID:???

>>752
わざわざそんな発言しちゃって、ここ見るまで「デザイン」をレイアウトとか
スタイルだと思ってたのバレバレじゃないですか。

>>754
ああもう、「同意」なんて言っちゃってえ……

757 ：Name_Not_Found：04/05/20 20:36 ID:???

出ました、自演

758 ：Name_Not_Found：04/05/20 21:05 ID:???

構うな。

759 ：Name_Not_Found：04/05/20 21:39 ID:???

出ました、自演

760 ：Name_Not_Found：04/05/21 18:13 ID:???

参考までに。

【デザイン】
http://dictionary.goo.ne.jp/search.php?MT=%A5%C7%A5%B6%A5%A4%A5%F3&kind=&mode=0&jn.x=40&jn.y=11
【スタイル】
http://dictionary.goo.ne.jp/search.php?MT=%A5%B9%A5%BF%A5%A4%A5%EB&kind=ej&mode=0&jn.x=20&jn.y=8
【レイアウト】
http://dictionary.goo.ne.jp/search.php?MT=%A5%EC%A5%A4%A5%A2%A5%A6%A5%C8&kind=ej&mode=0&jn.x=40&jn.y=13

ついでに。

【スタイルシート】
http://dictionary.goo.ne.jp/search.php?MT=%A5%B9%A5%BF%A5%A4%A5%EB&kind=jn&mode=0&base=1&row=1
【CSS】
http://dictionary.goo.ne.jp/search.php?id=%A4%F1031919000000000000&kind=jn&mode=5

というか、「参考までに。」「ついでに。」とかいうふうな句点をつけるのは変だろうか。
マークアップしたときそこでp要素が終わるからという理由でつけないと落ち着かないのだろうか。
HTMLも何も知らない人はどうするのか、ちょっと気になった。

出ました、自演。

761 ：Name_Not_Found：04/05/21 20:36 ID:???

出ました、予防線。

762 ：Name_Not_Found：04/05/21 21:46 ID:???

763 ：Name_Not_Found：04/05/21 22:30 ID:???

>>761
まじれすで悪いんだけど、何がどう予防線なの？

764 ：Name_Not_Found：04/05/22 10:50 ID:???

初めてこの板でCSSコミュニティとやらを知った時
さぞやかっこいいCSS使いの集まりなんだろうなと思ってた。
いわゆる周辺サイトとやらを見て回ってあまりのダサさに愕然とした。

765 ：Name_Not_Found：04/05/22 11:48 ID:???

>>764
スレ違い

766 ：Name_Not_Found：04/05/22 12:34 ID:???

>>764
スレ違いながらわかる。
時々ダサいと文句がくるカスイケリンク集の中でもイケてない部類だからね。

767 ：Name_Not_Found：04/05/22 12:42 ID:???

>>766
他でやれ

768 ：Name_Not_Found：04/05/22 21:49 ID:???

ｲｹﾃﾙCSS書く連中の集まるところは
誰も2chには書かないからな。
いつかも前も見つけられるさ、がんがれ

769 ：Name_Not_Found：04/05/22 22:07 ID:???

770 ：Name_Not_Found：04/05/23 13:04 ID:???

質問なのですが、中古車の情報サイトを運営しています。
一覧画面で200px*150pxの画像を並べているのですが、
一応表だと思ったため今まではTABLEで作成していました。
しかし数が多いため、表示に時間がかかるのと、画面のリサイズに対応するためにfloatで並べたいのですが、
何でマークアップするのが適切でしょうか。strict を目指し始めたのは最近なのですが、画像の扱いに関する情報があまり見つからないのでアドバイスお願いします。

771 ：Name_Not_Found：04/05/23 13:28 ID:???

>>770
ul li

772 ：770：04/05/23 14:20 ID:???

ありがとうございます。やってみます。

773 ：Name_Not_Found：04/05/24 13:18 ID:???

車種名とか、一種の見出しみたいなのをつけるならdt・ddだね。

774 ：747：04/05/24 20:55 ID:???

>748、>749
遅くなりましたが、レスありがとうございました。
定義リスト入れ子でマークアップしていきます。

775 ：Name_Not_Found：04/05/24 22:54 ID:???

ここで発言している方はブログを作成しているひとが多いと思いますが、
ビジュアルコンテンツがメインのサイトを作ってる方はいるでしょうか？

swfの扱いで困っています。
ページのイメージを構成する部品として配置しているのですが、
適したマークアップが分からずとりあえずdivにしています。
w3cの仕様に従って埋め込みにした場合、NNで表示されなかったりと・・・
strict的にはswfはナシなんでしょうか？

776 ：Name_Not_Found：04/05/24 23:02 ID:???

＞ここで発言している方はブログを作成しているひとが多いと思います
なんで？

777 ：775：04/05/24 23:11 ID:???

＞なんで？

画像やswfに関するレスが少なかったのと、
個人的に「strict＝ブログ」もしくは文章がメインのサイト
という先入観があったもので。

ウェアショップの構築を仕事でやってるんですが、
文章はほとんど無く、目立つのは価格と商品名がほとんど。
仕事と割り切ってテーブルで作成してもよいのですが、
せっかくなのでstrict的なページにしようと思いまして。

参考になりそうなサイトなどありましたら教えて頂けないでしょうか。

778 ：Name_Not_Found：04/05/24 23:19 ID:???

>>777
カスイケスレで最近挙がってた
ttp://www.taiyakan.co.jp/
とか。ジャンルは全然違うけど。strictでもないけど。

MovableTypeとか、全然strictじゃねーよ。
気持ち悪くてテンプレ全部直したもの。（あ、やってんじゃん、ブログ）

779 ：Name_Not_Found：04/05/24 23:21 ID:???

>strict的にはswfはナシなんでしょうか？
strict的には当然object。

但し、メジャーなUA全てで問題なく動くstrictな記述を
少なくとも俺は知らない。

役立たずでスマ。

780 ：Name_Not_Found：04/05/24 23:27 ID:???

>>775
> ページのイメージを構成する部品として配置
これ自体が基本的にHTMLの領分ではないので
仕事と割り切ってそういうことするならdivでいいのでは。
ページで提示するデータとして重要な情報であるならば
それなりのマークアップが必要だろうけれど
そうでないならば、無茶な解釈による無茶な意味付けはむしろやらない方がいい。

781 ：Name_Not_Found：04/05/24 23:27 ID:???

embedの様な謎要素はJavaScriptで出力…

…しても、真のstrictじゃないよね…

782 ：Name_Not_Found：04/05/24 23:33 ID:???

UA側で実装していない機能は文書側ではどうしようもないよ。

783 ：775：04/05/24 23:50 ID:???

たくさんのレスありがとうございます。

>>778
見てきました。というかobjectでアクセシビリティ気にせず動いてくれると
話は早いんですけどね。

javascriptの方向でやってみます。
ありがとうございました。

784 ：Name_Not_Found：04/05/24 23:56 ID:???

>>781
それどころかinvalid

785 ：Name_Not_Found：04/05/25 00:29 ID:???

未対応環境に対してのみembed書き出す分には別にいいんじゃないの？
strictに対応していない実装にvalidなstrict食わせても
どうせきちんと解釈されないのでstrictである意味がないと思う。
クライアントサイドで分岐して書き出すようにしておけば
取得した文書をstrict対応環境で再利用するような場合でも不都合はない。

786 ：Name_Not_Found：04/05/25 01:00 ID:???

＞未対応環境に対してのみembed書き出す分には別にいいんじゃないの？
現実問題としては有りだと思うが、このスレ的には不可。

DTDを書き換えた方がマシ（すでにstrictとはよべないが）

787 ：Name_Not_Found：04/05/25 16:37 ID:???

じゃスクリプトでDTDを書き換えちゃおう。

788 ：Name_Not_Found：04/05/25 17:06 ID:???

狭い世界では有名なDTDだが
ttp://www.remus.dti.ne.jp/~a-satomi/nikki/tmp/bouhoumen_svg/embed_inrDTD.html

こういうembedを使用可能にしたDTDがあるので、これをつかわせてもらう(というか丸パクリする)
のもいい。

789 ：Name_Not_Found：04/05/25 18:45 ID:???

>>787
スクリプトでのDTD書き換えは無理よん。

>>788
これにtext/html付けるのは大目に見ますか？

790 ：Name_Not_Found：04/05/25 21:21 ID:???

>>789
サーバサイドスクリプト

791 ：Name_Not_Found：04/05/25 21:53 ID:???

>>781
スクリプトでの書き換え後もdtdに適合してなければ
ならない。

CSS切り替えなどでlink要素のdisabled=trueなんてやると
strictでもtransitionalでもない無印謎HTMLのできあがり。

792 ：Name_Not_Found：04/05/25 21:57 ID:???

>>791
だよね。謎要素使わなきゃならないときは、ガマンしてtransitionalって
書くんだよ。
涙をのんで。

793 ：Name_Not_Found：04/05/25 22:07 ID:???

百歩譲って

794 ：Name_Not_Found：04/05/25 22:24 ID:???

>>788
W3C にも同様の DTD がおいてあったりする。
ttp://www.w3.org/Graphics/xhtml1-transitional-plus-embed.dtd

というかどっちも embed を XHTML の名前空間で定義してる点で
不可な気がするのだが。
ttp://www.satoshii.org/markup/notes/2003/12#date18

795 ：Name_Not_Found：04/05/25 23:26 ID:???

>>791
誤解しているようにも読めるので一応突っ込んでおく。
linkElement.setAttribute('disabled','true'); ならば謎HTMLｹﾃｰｲだけど
linkElement.disabled = true; ならば無問題。
全てのプロパティが属性と対応関係にあるわけではない。
中には属性に対応するプロパティもあるというだけ。

796 ：Name_Not_Found：04/05/26 00:01 ID:???

そんな理屈が通るなら
HTMLDivElement.align="center"とかやりたい放題ぢゃないか

797 ：Name_Not_Found：04/05/26 00:29 ID:???

>>796
やりたい放題だよ？

そこでいじってるのはあくまでCSSと同じく見栄えの部分だから
HTMLコードは全く侵されていない。

798 ：Name_Not_Found：04/05/26 01:10 ID:???

CSSでめちゃくちゃにレンダリングされているとしてもCSSを切ったりテキストベースのUAで見れば無問題;-)

799 ：Name_Not_Found：04/05/26 01:11 ID:???

>>796-797
勘弁してよ。HTML以外の仕様書は読めないのか？

HTMLDivElement.alignはHTMLのalign属性を示すと規定されている。
その設定はtransitionalのalign属性の設定を意味し
strict文書中では使用できない。

HTMLLinkElement.disabledは単にリンクの有効/無効を示すとされている。
それはdisabledという名前の属性とは何の関係もなく
strict文書中で不整合なく使用できる。

まあどうせHTMLのDOMなんてstrict文書を扱うためのものではないけど。

800 ：Name_Not_Found：04/05/26 21:52 ID:???

HTML4(XHTML1.x)のlink要素に有効/無効などない。
StrictHTMLでは「できない」事をDOMでやってるという事が
謎要素や謎属性を追加するのと、どう違うと言うのか？

801 ：Name_Not_Found：04/05/26 22:23 ID:???

>>800
HTMLのStrictに、フォントの色指定などない。
StrictHTMLでは「できない」事をCSSでやっているという事が
謎要素や謎属性を追加するのと、どう違うと言うのか？

全然違う。

802 ：Name_Not_Found：04/05/26 23:24 ID:???

色だの何だのはcss等のスタイルシート使うべし
とHTML仕様書にもある。例えにになってない。

大体、無効なリンクならリンクとしてマークアップされる必然性も無いはず。
無効にしたければ削除すれば良いし。
有効にしたければ生成なり追加なりすればよい。

803 ：Name_Not_Found：04/05/26 23:34 ID:???

> HTML4(XHTML1.x)のlink要素に有効/無効などない。
> StrictHTMLでは「できない」事をDOMでやってるという事が
> 謎要素や謎属性を追加するのと、どう違うと言うのか？
仕様上invalidになるかならないかが違う。それだけ。

804 ：Name_Not_Found：04/05/27 00:00 ID:???

結局の所、このスレで確定出したければ、仕様を引用するなり、
URLを示すなりしないと、他の物に例えたり、「思う」「思わない」では
FAでない。

極論、他から類推して仕様上認められる／られないように思えても、
その仕様に「例外的にこれは認める／認めない」と書かれていたらそれまでの事。

805 ：Name_Not_Found：04/05/27 00:13 ID:???

>>802
スタイルシートリンクには有効/無効という状態が存在する。
disabledがreadOnlyだったら恐らくお前にも納得できるんだろうな。

お前の言い分だと HTMLInputElement.checked = true; あたりも謎属性認定だな。
checked属性ならdefaultCheckedだし、動的にチェックしたいなら
そういう要素を生成なり追加なりすればいいと。

806 ：Name_Not_Found：04/05/27 13:43 ID:???

要するに
・謎要素を生成したり謎属性をくっつけたりしたらinvalid
・要素自体に触らずUAの挙動を制御するだけならvalid
ってことで宜しい？

807 ：Name_Not_Found：04/05/27 17:46 ID:???

>HTML documents are constrained to conform to the HTML DTD both before and after processing any SCRIPT elements.
http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.4

結局はこれだろ。

808 ：Name_Not_Found：04/05/27 17:54 ID:???

>>807
それ前提。

その上で、「DOM による要素のプロパティの変更」が「HTMLのコードを変更」を
意味するのか（勿論プロパティによるだろう）、また、変更した場合、
変更後のHTMLがDTDに合致するかどうか、と言うのが今の流れ。

809 ：Name_Not_Found：04/05/28 06:10 ID:???

俺、全然正しくないHTMLでサイトを作っちゃったんだけど、tran??でもXHTML??
でもないわけだけど、一応winのIE|NN共に4以上なら見れるみたい。正直まだ勉強初めて
間もないんだけど、とりあえず見れてるなら当分はそのままでもいいと思う？

あと、今後のために教えて。一番古いブラウザまで対応できるDTD？ってなに？一応IE|NN4がクリアが基準として。

810 ：Name_Not_Found：04/05/28 06:21 ID:???

うぜー文体…

811 ：Name_Not_Found：04/05/28 08:00 ID:???

ウザイって言うか？頭悪い？みたいな？

812 ：Name_Not_Found：04/05/28 08:38 ID:???

みたいなー

813 ：Name_Not_Found：04/05/28 08:39 ID:???

だよねー

814 ：Name_Not_Found：04/05/28 09:10 ID:???

文体云々抜きにしても>>809の質問は糞

815 ：Name_Not_Found：04/05/28 09:57 ID:???

>>809
こっちの話題だと思うよ。
http://pc5.2ch.net/test/read.cgi/hp/1085032889/

816 ：Name_Not_Found：04/05/28 11:54 ID:???

>>809
マジレスすると、4.01 strict で、
NN4だって見られる。
mozaic でも lynx でもみられる。

817 ：809：04/05/28 13:04 ID:???

サクっと教えりゃいいのに。

おまいら大好きなW3Cの正しいHTMLを広めたいんだろ？

818 ：Name_Not_Found：04/05/28 13:11 ID:???

W3Cの正しいHTMLという表現は正しくない

819 ：809：04/05/28 13:15 ID:???

どうでもいい

820 ：Name_Not_Found：04/05/28 13:22 ID:???

夏休みはまだまだ先だぞ。
ちゃんと学校いけよ。

821 ：Name_Not_Found：04/05/28 13:26 ID:???

>>809
＞サクっと教えりゃいいのに。
サクっと教えられる物ならとっくにやっとるわ。
そんでStrictなHTMLが正しく普及して、俺たちも万々歳だ。

別に特別な能力とか、知識が必要な訳じゃないが、
本人にやる気がないととてもじゃないが覚えられる代物じゃない。
（逆に言えば本人にやる気が有るなら中学生でもできる）

で、だ。
>>809 はもしやる気があるならHTML4.01の仕様書よんでこい。
そんで、仕様書に解らない部分があったらそれをここで聞いてくれ。
そん時はちゃんと答えるから。

822 ：821：04/05/28 13:34 ID:???

あ、ちなみに HTML の Strict が覚えたい訳じゃなくて、>>809 の質問に答えろ、
ってレスが付きそうだから先にいっとく

＞とりあえず見れてるなら当分はそのままでもいいと思う？
これに対する回答は「駄目」だ。しかし、>>809 は「これでいっかなー」と思いつつ、
しかし、このスレ的には多分駄目だと予想して聞いてるんだろう。

となると、真の回答としては「なぜ駄目なのか」と言う話になる訳だが、これが長いんだよ。
どれくらい長いかというと、HTMLとはどんな物で、どこに向かいっているかを
理解しないと駄目。

で、「HTMLとはどんな物で、どこに向かいっているか」を理解するにはHTMLの仕様を
読むのが一番早いので「HTMLの仕様嫁」となる。

823 ：Name_Not_Found：04/05/28 13:37 ID:???

どこに向かいってるんだろうね

824 ：Name_Not_Found：04/05/28 14:01 ID:???

ティムたんに聞こう！

825 ：Name_Not_Found：04/05/28 14:35 ID:???

>>823
まぬけ時空

826 ：Name_Not_Found：04/05/28 15:06 ID:???

去年の11月の話からすると、
ティムたんは結構あさっての方向を見ている希ガス

827 ：Name_Not_Found：04/05/28 16:17 ID:???

むしろこのスレの連中がHTMLに夢見すぎという気もするがな。

828 ：Name_Not_Found：04/05/28 16:49 ID:???

どう言う意味なんだろう

829 ：Name_Not_Found：04/05/28 17:04 ID:???

犯罪が100%ない世の中を本気実現できると思ってたらそりゃ夢を見すぎだが、
犯罪がない世の中を目指したり、犯罪を一切許してはいけません、
というスローガンをたてるのはありなんじゃね？

830 ：Name_Not_Found：04/05/28 17:28 ID:???

ありおりはべりいまそがり

831 ：Name_Not_Found：04/05/28 17:31 ID:???

>>829
>827は、悪いと言ってるわけではないと思うよ

好きこそものの上手なれって言葉もあるし
夢見ながら勉強してんならいいでしょ

832 ：Name_Not_Found：04/05/28 17:49 ID:???

恋愛の歌あもーれべさめむちょ

>>821
>（逆に言えば本人にやる気が有るなら中学生でもできる）
やる気のあまりない小学生でも一応のものは十分できるような気がする。

前から思ってるんだけど、初心者に教えるとき一旦原稿用紙に書いたのをマークアップさせるってどう？
見出しとか段落とかもよく理解してもらえそうだし、
「ここをクリック」とか書いた奴には容赦なく病院行けって言える。
それを本にすることをイメージしてもらえばスタイルシートの概念も受け入れやすいと思う。
やたらと紙メディアっぽくならないように気をつける必要はあるかもしれないけど。

そういう方向のHTML入門サイトを作ろうかと思ったけど、何せ面倒で。

833 ：Name_Not_Found：04/05/28 17:57 ID:???

＞やる気のあまりない小学生でも一応のものは十分できるような気がする。
小６ならちょっと勘の良い奴ならできるだろうけど、小１だと一般的に無理だべ。

834 ：Name_Not_Found：04/05/28 18:02 ID:???

>>832
>初心者に教えるとき一旦原稿用紙に書いたのをマークアップさせるってどう？

初心者のためのホームページ作成講座 - Personal
http://members.jcom.home.ne.jp/jintrick/Personal/markup.html

Instant Etext -- HTMLの自動生成（The Web KANZAKI）
http://kanzaki.com/docs/etext/instant-etext.html

なんてのもある

835 ：Name_Not_Found：04/05/28 18:03 ID:???

>>832
漏れ、新人に教える（教え直す）とき、まず書かせるよ。
で、赤でインラインの部部に下線、ブロックを枠線で囲ませてみる。

836 ：Name_Not_Found：04/05/28 19:29 ID:???

>>832
> 前から思ってるんだけど、初心者に教えるとき一旦原稿用紙に書いたのをマークアップさせるってどう？
> 見出しとか段落とかもよく理解してもらえそうだし、
> 「ここをクリック」とか書いた奴には容赦なく病院行けって言える。

それいいね。
病院行けﾜﾗﾀ

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

偉そうにｶﾞｲｼｭﾂﾈﾀを宣っていないで過去ﾛｸﾞでも嫁

838 ：809：04/05/28 21:17 ID:???

>>821-822
良い説明だ。でもま、正直正しいHTMLなんてお金にならないから3ヶ月後くらいまでに
は正しい書き方に直そうかなと。

ところでさ、みんなは正しいHTMLって言うのがソース書くときの再優先なの？折れ的には
HTMLもPERLと同じくソースは見やすくわかりやすくいじりやすく、短く。がいいんだけど、
それをしようとすると,<center></center>とか<br>でのスペース調整とかCSSの中途半端
な使い方とかが増えるんだよね。

そこらへんで別に正しくなくてもよくね？みたいに思っちゃうんだよね。それでも3ヶ月以内には
書きなおすけど。

>837
？ここに文字読みにきてんじゃねし、ここにいるやつらと話にきてんだよ。

839 ：Name_Not_Found：04/05/28 21:25 ID:???

とりあえず過度なインデントはイラネ

840 ：Name_Not_Found：04/05/28 21:30 ID:???

>みんなは正しいHTMLって言うのがソース書くときの再優先なの？

おれの場合、手ぬきの方法。

文章をテキストエディタでべた打ち
改行を</p><p>に置換
見出しをつける
ヘッダをテンプレートから貼りつけ
微調整
そのままサーバに上げる

見ばえはスタイルシートに依存。おれにとってはこれが一番らくな方法。

841 ：809：04/05/28 21:43 ID:???

過度なインデントも装飾も必要ないよね。っていうか読めればいい。

そんでついでにバグらず表示されればそれ以上なにもいらない。

>>840
いいねそれ。痴漢いいね。俺は初めから終わりまでテキストエディタに直打ちしてるよ。

842 ：Name_Not_Found：04/05/28 21:50 ID:???

>>838
わかりやすくいじりやすく、汎用的に。
所定の仕様どおりに作るのが結局は一番カンタン。
centerとかbr連打とか、利用側として言えば
無駄な構造を混入させるのは除去が面倒で非常にいじりにくい。

843 ：Name_Not_Found：04/05/28 21:51 ID:???

844 ：Name_Not_Found：04/05/28 21:52 ID:???

漏れ的には構造化エディタの要領でStrict HTML作れたら最高なんだけどな。

845 ：Name_Not_Found：04/05/28 21:58 ID:???

>でもま、正直正しいHTMLなんてお金にならないから
商売になるかどうかと、正しいかどうかは、関係ない。
正しい事が価値があるとするこのスレ的には、ビジネスユースの人向けに
正しいHTMLが削減してくれるメンテナンスコストとか、将来に対する
ファイルフォーマットの保証とかの話も出来るが、ぶっちゃけ
金になろうが、成るまいが正しいし、その基準は仕様なのだから
仕様を守れ、としか言い様がない。

と言う石頭の回答としては
>みんなは正しいHTMLって言うのがソース書くときの再優先なの？
そもそもちがう。ただしくないとHTMLとは呼べない。

人間相手に読ませる文章ならある程度間違ってても認識出来る。
しかし、コンピュータ相手のフォーマットだと、「結果として人間が
読める表示」になっているかも知れないが、コンピュータは正しく
解釈できていないことになる。

このとき、「たまたまIEで上手く見える」とか「たまたまNN4で上手く見える」
と言うのは将来新規ブラウザが現れたり、IEがバージョンアップしたときも
正しく見えるという保証に一切成らない。

だから、標準に準拠したブラウザが推奨され、仕様を守ったHTMLじゃないと駄目、
と言う事になる。

846 ：Name_Not_Found：04/05/28 22:00 ID:???

847 ：809：04/05/28 22:02 ID:???

>>843
例えばさ、真中に画像があってその下にすこしのコメントをみたいなのだと。

<center>
<img ～～～>
文字列
</center>

これ仕様書とは違うけど、表示できるし、見やすくわかりやすくいじりやすい。
まあ仕様書とおりのほうがいいときもあるから、臨機応変に行きたいな。どっちのほうが
絶対いい！みたいに極端なのは微妙

848 ：Name_Not_Found：04/05/28 22:02 ID:???

849 ：Name_Not_Found：04/05/28 22:03 ID:???

>>846
どこを縦読みすれば良いんですか？

850 ：Name_Not_Found：04/05/28 22:45 ID:???

書き込みやたら重いが、
なんかここ数日流れが変わった？

851 ：Name_Not_Found：04/05/28 23:04 ID:???

>>849
なんか、鯖移転しようとしたら、ひろゆきがドメインとったときに
使ったメアドが使用停止になっていることに気付いて、
ゴニョゴニョしているらしい。

ドメイン切れるのは、29日だと。

852 ：Name_Not_Found：04/05/28 23:41 ID:???

>>847
いや、「仕様とは違うから」正しいブラウザが現れると、
お前の意図しない表示になるかも知れない。

ちなみに、仕事の話ならクライアントがＩＥでみられればそれで良い。
将来とかのことは関係ない、と言えば、その通り。但し、スレ違い。

853 ：Name_Not_Found：04/05/28 23:44 ID:???

>>847
例えばさ、真中に画像があってその下にすこしのコメントをみたいなのをフォーマットとしてのサイトデザインをしていて。
それをリニューアルしちゃおっかな、と思った場合、そのレイアウトの仕方をしてるページは全部書き換えなきゃなんないよね。
その点はどう考えてるの？

854 ：Name_Not_Found：04/05/28 23:48 ID:???

>>851
２９日以前に重いのはそれとは別の原因とか小耳に挟んだけど
というか全体に二重カキコが増えたよな

855 ：Name_Not_Found：04/05/28 23:50 ID:???

>でもま、正直正しいHTMLなんてお金にならないから

正しいHTMLはGoogleでの順位が上がりやすいよ

856 ：Name_Not_Found：04/05/29 00:00 ID:???

>>851
その件は既に解決しました。

857 ：Name_Not_Found：04/05/29 00:20 ID:???

>でもま、正直正しいHTMLなんてお金にならないから
　無能な自称Webデザイナが自己防衛のためによく言う言葉だけど、
こういうこと言うやつは先見の明もないし将来性もない。

「先見性」と書いたけど、すでに正しいHTMLは官公庁や一部企業から
求められているから先見でもない。

このスレのように宗教的なまでにStrictなのはともかく、
JISのアクセシビリティ規格を遵守するのが、「できる企業」
としての最低限のものとなっていくときに、正しいHTMLの知識は
間違いなく金になる。(というか基礎知識となるから絶対に必要)
生かすか殺すかはそいつ次第だが。

858 ：Name_Not_Found：04/05/29 00:41 ID:???

仕様を守る事の利点が理解出来ていない
->クライアントに仕様を守る事を説明出来ない
->仕様を守っても金にならない

まぁ、そうだろうね。

859 ：809：04/05/29 01:20 ID:???

>>857
>>でもま、正直正しいHTMLなんてお金にならないから
>　無能な自称Webデザイナが自己防衛のためによく言う言葉だけど、
>こういうこと言うやつは先見の明もないし将来性もない。

Webデザイナかｗうさんくさい響きだね。正直俺はWebサイトにデザインだとか云々が
必要だと思ってない。っていうかそんなこと思う程のレベルじゃないしね。

読めればいい。読みやすければもっといい。でもかっこがいい必要はない。とりあえず、読めればいい。

正しいHTMLなんて金にならないっていうのはね、正しいHTMLにこだわって低脳な俺が背伸びして
ここにいるみんなと同じレベルのものを作ろうとすると、時間がかかるのね。（通販サイト作ってる）

でも正しいHTMLにするために時間かけても、売上に大きな影響を与えるわけじゃないから、とりあえずはやく
完成させろと、自分に言い聞かせてる。正しいHTMLよりも堅牢で信頼できるサイトをつくることに
時間をかけたいから。だから俺の今の状況では、正しいHTMLは金にならない。将来的には役に立つのは理解してる

でもできるだけ早くここにいる人に追いつきたいね。

860 ：Name_Not_Found：04/05/29 01:23 ID:???

>>859
> 正直俺はWebサイトにデザインだとか云々が
> 必要だと思ってない。っていうかそんなこと思う程のレベルじゃないしね。
> 読めればいい。読みやすければもっといい。でもかっこがいい必要はない。とりあえず、読めればいい。

ならなおさら Valid な HTML を。
一度テーブルレイアウトだの何だのから入ってると戸惑う事も多いだろうけど
理解していくにつれこっちの方が分かりやすい事に気づくと思う。ｶﾞﾝｶﾞﾚ。

861 ：Name_Not_Found：04/05/29 01:27 ID:???

>>859
EC/販促サイトなら特に適切なマークアップが重要だ罠

> 読めればいい。読みやすければもっといい。でもかっこがいい必要はない。とりあえず、読めればいい。
ちうか、能書きが大杉で読む気にならんのだが

862 ：Name_Not_Found：04/05/29 01:38 ID:???

>>859
繰り返しかもしれないケド・・
正しいHTMLはこれからなおさら浸透していく、負の方向に向かうことはないでしょう。
もし、今あなたのサイトの閲覧者及びあなたがあなたのサイトを読むことが出来ても将来きちんと読めたり、
そのコンテンツを有効に再利用できたりする可能性は低い。
もし今時間や余裕がないのであれば無理にvalidを目指す必要はないと思う、短期的には確かに金にはならないから。
ただ、いつか見直しが迫られるとも思う、おそらくその時の使う労力は今以上かと。

863 ：Name_Not_Found：04/05/29 01:49 ID:???

>>854
bbs.cgiが重くて、書き込みできててもエラーはくから、
思わず何回も書き込みを押したくなっちゃうんだよね。

ところで、スレの流れも以前と変わって、
原理主義的だったのが軟化したような感じ

864 ：Name_Not_Found：04/05/29 02:48 ID:???

>>863
元々本当の信者はそんな強硬派じゃないと思ってるんだけどなぁ。
むしろ入りたてっていうかいまいち分かってない人に限って
原理主義的というか排他的というか。

俺ですか？俺は態度だけは悪くならないように努めてるつもりのド素人ですよ。

865 ：Name_Not_Found：04/05/29 03:42 ID:???

>>847
HTML3.2使え。

866 ：Name_Not_Found：04/05/29 03:53 ID:???

>>859
多くの人に読ませるための標準だべさ。
標準で書かないとIEでしか読めなかったり
他のブラウザで不具合が出たりするかもだべ。

IE以外のブラウザを使う奴は少ないから
その分の顧客を得る機会を失っても構わないというんなら
良いんだろうが、商売として依頼する場合なら
「どんなブラウザからも理解できること」は期待してるんじゃ
ないのかな。＝標準という意識はエンドユーザには無いかもだが、
その条件を満たすには標準も満たすのが一番楽だべ。
標準ってのはその楽をするためにあるわけで。
別に海千山千のブラウザの動作検証をすべて行う気があるなら
アレだけれども、普通はそれやるより標準で書いた方が安く済むべ。

867 ：Name_Not_Found：04/05/29 08:31 ID:???

>>859
>>853スルーしないで

868 ：Name_Not_Found：04/05/29 09:07 ID:???

面白いことになってるｗ
ttp://www2.big.or.jp/%7Edasa/cgi-bin/bbs/test/read.cgi?bbs=1&key=1083340169&ls=50

869 ：809：04/05/29 09:57 ID:???

>>867
>例えばさ、真中に画像があってその下にすこしのコメントをみたいなのをフォーマットとしてのサイトデザインをしていて。
>それをリニューアルしちゃおっかな、と思った場合、そのレイアウトの仕方をしてるページは全部書き換えなきゃなんないよね。
>その点はどう考えてるの？

ごめん。とりあえず今の俺では、どんな書き方しても全部書き換えになっちゃうと思う。でも、リニューアルする頃には
正しいHTML書けるようになってるから、その頃なら後々のことを考えたソースにすると思う。

>>866
今はIE4NN4以上だけは動作確認してるけど、中途半端だよね。

870 ：Name_Not_Found：04/05/29 09:58 ID:???

>>869
> 今はIE4NN4以上だけは動作確認してるけど、中途半端だよね。
うん。二種類だけじゃあね。

871 ：Name_Not_Found：04/05/29 10:50 ID:???

IE4とNN4は窓から(ry

872 ：Name_Not_Found：04/05/29 11:22 ID:???

>>869
>今はIE4NN4以上だけは動作確認してるけど、中途半端だよね。
例えばユーザー側が自作しているＵＡとか（架空の話ではなくて
サーチエンジンのボットなどが多数実在する）、将来これから現れる
現在チェックしようのないＵＡもある訳で。

そうなると、仕様に従ういがいの保証など有りはしない。

873 ：Name_Not_Found：04/05/29 11:37 ID:???

NCは窓から投げ捨てなくてもいいんですか

874 ：Name_Not_Found：04/05/29 11:37 ID:???

>>869
あ、それと正しいHTMLはGooglebotに引っかかりやすいよ。

875 ：Name_Not_Found：04/05/29 14:10 ID:???

テーブルレイアウトｽﾚでは無いけど、
strict+CSSでもloose.dtdでもテンプレート作ってしまえば
再利用が利くから手間は同じ。
CSSのほうがデザインの変更が楽になる。
あとstrictだとSEO対策にもなる。

876 ：Name_Not_Found：04/05/29 14:23 ID:???

なにより、正しいというか妥当なマークアップは、時間の節約になる。

877 ：Name_Not_Found：04/05/29 14:25 ID:???

W3Cが廃止要素、非推奨要素は無視させろ、とブラウザ開発してる香具師に言ってくれればな。
現状では、「そうやってる人もいるから」「それは残しておいてね」みたいなことをちんたらやってるからいつまでもそれでいいと思ってるやつらがいなくならない。

878 ：Name_Not_Found：04/05/29 15:07 ID:???

>>877
漏れもそう思ってしまう。
T.B.L.の境地には辿り着かないよな。

879 ：Name_Not_Found：04/05/29 15:17 ID:???

DOCTYPE読んで3.2とかなら許容、
書いていない場合は無視とかね

880 ：Name_Not_Found：04/05/29 15:23 ID:???

>>879
その結果、「HTML☆講座」みたいなサイトも消えていくだろうから、validが広まるんじゃないか、

と、思ったけど、
「だから3.2ってここに書いてネ☆」
とやりだす「HTML☆講座」

881 ：Name_Not_Found：04/05/29 15:46 ID:???

なんだかなぁ。

元々TBLが気まぐれでSGMLっぽい書式を採用したのがHTMLの始まりな訳で、
それを無理矢理SGMLに適合させたHTML2からして既に過去との互換性重視なんだから
今更原理主義でやれと言う方に無理がある。

と言うか、だから互換性を考えない方向でXHTML2があるんだろう？

882 ：Name_Not_Found：04/05/29 18:41 ID:???

>>880
しまいに仕様にいちゃもんつけそうだなw

883 ：Name_Not_Found：04/05/29 19:25 ID:???

<h*>と<font size="*">で文字を大きくする時の数字が違うのは
（原理主義者たちの）嫌がらせかと思えますが、ﾀﾝﾀﾝと行きましょう。

と昨年夏のﾈﾀを使ってみるテスト

884 ：Name_Not_Found：04/05/29 19:29 ID:???

>>883
ﾏｼﾞﾚｽしたいけど我慢します

885 ：Name_Not_Found：04/05/29 19:35 ID:???

小見出し＜地の文

886 ：Name_Not_Found：04/05/29 19:51 ID:???

>>883
言われて思い出した。記憶の片隅に残ってたらしい。

887 ：Name_Not_Found：04/05/29 20:06 ID:???

>>874
今ならその点から企業に Valid なサイトを作る事を
勧められるんじゃないかとか思ったりするんだけど、
実際現場ではその点どういう認識なんだろ。

最近 blog がうざいって言われるくらい検索結果の上位に来るのも
完全ではないにしろ比較的validっぽいソースを吐くからなんだし。

888 ：Name_Not_Found：04/05/29 20:06 ID:???

あとやたらにリンクしあってるのも大きいけどね。

889 ：Name_Not_Found：04/05/29 20:22 ID:???

>>883
ああ、朝日ですか

890 ：Name_Not_Found：04/05/29 21:26 ID:???

顎アニメでぐぐれ

891 ：Name_Not_Found：04/05/29 22:03 ID:???

Strictな観点からいくと文章中の単語、文章を
強調するにはどのタグを使用したほうがいいの？
もちろん文字の大きさとかはcssに書くとして。

892 ：Name_Not_Found：04/05/29 22:22 ID:???

em
strong

893 ：Name_Not_Found：04/05/29 22:24 ID:???

>>891
このスレで聞くようなことじゃねー
レベル低すぎ

894 ：Name_Not_Found：04/05/30 00:07 ID:???

>>893
つまり、strictが昔みたいに自力でW3Cの仕様を読んで、パラノイアみたいに
仕様を準拠する奴らだけの象牙の塔じゃなくなったってだけだ。

ここで初心者に対して説明する事自体を放棄する事自体がstrictの普及を妨げる事になる。

895 ：Name_Not_Found：04/05/30 00:16 ID:???

>>894
×仕様を
○仕様に

896 ：Name_Not_Found：04/05/30 00:46 ID:???

>>894
胴衣

そして答は既に>>892に。

897 ：Name_Not_Found：04/05/30 00:47 ID:???

>>894
逆にstrictを初心者スレに持ち込めばいいじゃん。

898 ：Name_Not_Found：04/05/30 03:14 ID:???

とほほとlintで解決する内容だとは思うが

899 ：Name_Not_Found：04/05/30 03:32 ID:???

>>898
とほほをｓ（ｒｙ

900 ：Name_Not_Found：04/05/30 09:26 ID:???

とほほをリファレンスに使っているというだけで
程度がしれる罠。

901 ：Name_Not_Found：04/05/30 09:29 ID:???

>>900
のあﾀﾝはものを言うのに資格は要らないと申しておりました
ﾘﾌｧﾚﾝｽ自体が正しければ使って良いかと

包括可能要素はとまかく項目の要素自体が
インラインかブロックかがよくわからんので使ってないが

902 ：Name_Not_Found：04/05/30 10:41 ID:???

blockquoteって、勝手に翻訳してまとめたものを書くときに使って良いかな？

903 ：Name_Not_Found：04/05/30 11:01 ID:???

いいんじゃないの?
訳文と原文の対応を明確にﾏｸｱﾌﾟ出来ればなお良し。

904 ：Name_Not_Found：04/05/30 11:31 ID:???

>>902
翻訳しても他人の言葉なら引用だからいいんだけど、「まとめたもの」は
引用の範疇じゃないから駄目。blockquote使うなら、引用なんだから
元の文章改変しちゃ駄目。

もし、翻訳が過分に意訳的な物なら、まず、blockquoteで原文示してから
blockquoteじゃない要素として「引用者による翻訳文」を記述するよろし。

905 ：Name_Not_Found：04/05/30 14:49 ID:???

Stricterさんたちに聞きたいんだけど、
もしもそういった翻訳をマークアップする場合って、

1.新しくtranslation要素を拡張する
2.div要素にclass属性に値"translation"を与える

XHTMLの場合、どっちでやる？
もちろん、1を選択するとXHTMLではなくなるわけだが…

906 ：Name_Not_Found：04/05/30 15:19 ID:???

<a href="元文章" rev="alternate" hreflang="元文章の言語コード" lang="ja">翻訳文</a>
かな。
XHTML2.0だとブロック要素からでもリンクできるからよりよいかも。

まとめたといっても"(中略)"とかをいくつか入れた程度なら引用といっていい気がする。
ただ、著作権法第四十三条によると、引用する際は翻訳以外の改変は行ってはいけない、つまり要約もいけないらしい。
#ちなみに出典の明記も必要。
でも、普通引用するときに必ず全文引用するわけじゃないしどうなんでしょう>エライ人。

907 ：Name_Not_Found：04/05/30 15:40 ID:???

>1を選択するとXHTMLではなくなる
ExtensibleだからXHTMLな訳だが。

908 ：Name_Not_Found：04/05/30 16:21 ID:???

>>906
要約と引用は全然別物でしょ。
部分引用ならば部分引用とわかるように書けばよし。

909 ：Name_Not_Found：04/05/30 17:27 ID:???

意味のない画像の場合は
alt=""
と
alt=" "
どちらがいいですか？
下だと音声ブラウザで「スペース」とか発音されるのかなと思って悩んでます。

910 ：Name_Not_Found：04/05/30 17:31 ID:???

alt="" でよい。

911 ：Name_Not_Found：04/05/30 17:36 ID:???

意味のない画像を貼る事がStrictなのかと

912 ：Name_Not_Found：04/05/30 17:55 ID:???

strictな書き方について一番わかりやすく教えてるサイトおしえて。仕様書重いし、読みづらい。

913 ：Name_Not_Found：04/05/30 18:11 ID:???

w3cのサイト池。
英語は簡単なのしかないから訳せ。
訳が無理ならStrictなHTMLを書くのも無理だ。

914 ：Name_Not_Found：04/05/30 18:28 ID:34xKifnE

>>913
そーやって叩っ斬るから、「そもそも仕様を守る必要はない！」という過激派が幅を利かす。
yahooとかgooとかの無料サーバのサイト見てミロや。そこのヘルプ掲示板見てみろや。
マジヤバだから

915 ：Name_Not_Found：04/05/30 18:32 ID:???

教えてくれないからって怒るなよ。
どうすればいいかなんて調べればすぐ見つかるだろ。

916 ：912：04/05/30 18:37 ID:???

>>912
なんだ。ここにはみんながStrictになる方がいいと思ってる人が一杯だからStrictになりたい人
には優しいかと思ったけど、色んな人がいるのね。

なんかさ、結構適当に覚えた俺だけど、実はtransitionalではあるっぽい。というかtrnsitionalについて
今日やっと意味がわかった。

ところで自分の書いたソースがtransitionalかstrictかはたまたデタラメかを簡単に調べるには
どうすればいい？

人のサイトのチェッカにかけるのは嫌。勝手にDTD宣言をしてみて、宣言したDTDにそぐわないソース
だったら、エラーになるとか親切な仕組みではないの？

「やってみろ」ていうオチか・・・

917 ：Name_Not_Found：04/05/30 18:50 ID:???

>>916
他人の作ったチェッカが嫌なら
自分でチェッカ作れば？

918 ：912：04/05/30 18:54 ID:???

あのさ、<h1>～<h6>っていきなり<h3>とかを使うんじゃなくてちゃんと<h1>から順番に使う
べきなんだよね？

でもさ、実際難しい。一体どれが<h1>かわからない。例えばメニューバーがあるようなページ
のどこが大見出しなのか？だ。

とりあえずttp://yahoo.co.jpのトップページで説明してくれるStrict広めるの万歳な人いない？

ヤフーのトップは<h>要素なんて使ってないから、本当はこうするのが正しい！っていうかんじで。

919 ：912：04/05/30 18:55 ID:???

もちろんレイアウトとしては同じものを実現しながら。

920 ：Name_Not_Found：04/05/30 18:57 ID:???

>>918
スレ違い。
こっちでどうぞ。
http://pc5.2ch.net/test/read.cgi/hp/1081753565/

921 ：Name_Not_Found：04/05/30 19:08 ID:???

>>918

>あのさ、<h1>～<h6>っていきなり<h3>とかを使うんじゃなくてちゃんと<h1>から順番に使う
>べきなんだよね？

そうすべきだと主張する人もいる、としか仕様書には書かれていない。

922 ：Name_Not_Found：04/05/30 19:13 ID:???

>>914
それは違う。法を知らない人間が「法を守る必要は無い」と言ったら、
そいつに自分で読めといった人間の責任になるというのか？
んなアホな話があるか！

自分で知ろうとしないようなような愚物に情け容赦する必要など無い。
そんな奴は叩き斬られて当たり前。

923 ：912：04/05/30 19:35 ID:???

>>920
やっぱそんな面倒な事やだよね。

>>921
そうなの？

>>922
推奨と法律が同じですか。HTML4.01って勧告・推奨でしょ？っていうかW3Cの規格自体
守らないといけないわけじゃないでしょ。でもStrictを理解していて納得している人としては
もっと広まって欲しいわけでしょ？UAの実装が正しくなっていくためにも。

なら俺に教えておくれよ。と、都合の良いことを言ってみるテスト

924 ：Name_Not_Found：04/05/30 20:27 ID:???

>>912
内田や神崎ではダメか？初心者スレのテンプレにURLが貼ってある。

925 ：Name_Not_Found：04/05/30 20:39 ID:???

カンザキはW3C原理主義者だから偏りすぎ

926 ：912：04/05/30 20:50 ID:???

>>924
とりあえず見てるけど、なんかイマイチ。今の自分が書いてるソースが一体何なのか
良くわからないから、Strictとうまく比較できない・・・なんていうか、どこをどう変えれば
いいかが？で。

結構テーブル使っちゃってるから、それが問題かも。テーブル使わないとおなじレイアウトができない
し、変なテーブルの使い方のせいで、ちゃんとした見だし、段落、なんとかにわけられない。

多分初めにちゃんと文書として作らなかったのが問題かと。ゆっくり考えてみるよ。

927 ：Name_Not_Found：04/05/30 21:16 ID:???

>>918
ネタにマジレスすると、「メニューバー」はlink要素。
このスレ的にはこれがほとんど唯一の正解。

UAの実装の都合を考えて「メニューバー」をbodyに入れてやるとどうかというと、これはいろいろ考えられる。
自分が思うに、厳密に行くならこういう感じ。

<h1>文書のタイトル</h1>
<h2 id="head">奥付</h2>
ここに「メニューバー」や署名、日付など
<h2 id="body">本文</h2>
ここに本文

奥付と本文の順番は逆でも良さそう。

闇黒日記なんかは「メニューバー」がh1より上に置かれてるけど、head要素の続きのつもりかもしれない。
それも「アリ」だと思う。
他にも、この例からh2要素をそのまま削ったようなやり方の人もいる。
そのままとは言っても、間のところにhr要素を置いてみたりしてることが多い。
これも「アリ」だろう。
いずれにしても、UAの実装を考えた「妥協Strict」ではあるけど。

http://homepage1.nifty.com/VET06031/web/lint100.html
これも嫁。

ついでに念のため言っておくと、参考文献みたいなのを挙げるならそれは「メニューバー」ではない。

928 ：Name_Not_Found：04/05/30 21:21 ID:???

>>912
とりあえずサイトを晒せ
話はそれからだ

929 ：Name_Not_Found：04/05/30 21:22 ID:???

>>926
table関係のタグを全部削ってから順番を直せば良いじゃん？
業界人ならtable無しでCSSだけでもほとんど同じようにできるよ。

930 ：Name_Not_Found：04/05/30 21:29 ID:???

>>927
なんでそこって、そんなに豆字なんだろね。

931 ：912：04/05/30 22:00 ID:???

>>927
なんかよさげなサイトありがと！

>>929
前に一度テーブルなくしたい！って試したら、floatじゃあイマイチ代用にならなくて
だんだんイライラしてきて、「なんでテーブルでやれば5分で書けることを、こだわって
10時間も悩んでるんだ！」って感じで・・・

floatってさ、あくまで回り込みだからさ、なんか安心感がないというか、絶対的じゃないというか。

932 ：Name_Not_Found：04/05/30 22:07 ID:???

tableも似たようなものだけど。
つーか、tableでガチガチに固められてると、印刷しにくいんだよね。

933 ：Name_Not_Found：04/05/30 22:11 ID:???

表示される位置なんてどうでもいい

934 ：Name_Not_Found：04/05/30 22:26 ID:???

table書くのめどいです

935 ：Name_Not_Found：04/05/30 22:44 ID:???

としあき（ｒｙ

見栄えをよくしようとか考えた事無いからやたらとシンプルなHTMLを書いてるんだけど、
それで困ることって無いよね。殆ど。

936 ：Name_Not_Found：04/05/30 23:43 ID:???

>>912
まあ、何が言いたいのかと言うと、
メル欄の「ageまくっり」ってなんなんだ？って話。

937 ：Name_Not_Found：04/05/31 00:38 ID:???

>>931
> だんだんイライラしてきて、「なんでテーブルでやれば5分で書けることを、こだわって
> 10時間も悩んでるんだ！」って感じで・・・
同じデザインにこだわらなければいいんじゃないかな。まっさらに一からデザイン。

> floatってさ、あくまで回り込みだからさ、なんか安心感がないというか、絶対的じゃないというか。
それがいいんじゃないか。

938 ：Name_Not_Found：04/05/31 00:47 ID:???

>>937
> それがいいんじゃないか。

どっこいそれがよろしくない人もいるんだなぁ…
>>912は頑ななまでにそれに凝り固まるタイプではないみたいだけどね。

939 ：Name_Not_Found：04/05/31 00:52 ID:???

無知だったころと同じデザインにしようという考え方を
する香具師は、けっきょくこのスレでいうStrictな考え方を
理解していないということじゃないか。

940 ：Name_Not_Found：04/05/31 01:15 ID:???

俺はStrictで記述してから、
「さーてここからどうやって理想のデザインにちかづけるかなー」
ってのが楽しみだったりするんだけどなあ。

941 ：Name_Not_Found：04/05/31 03:18 ID:???

>>926
じゃあ百歩譲って↓
ttp://www.parkcity.ne.jp/~chaichan/src/htmlmain.htm

942 ：912：04/05/31 06:10 ID:???

>>937
HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。

>>939
まさにそれだね。

>>941
ありがと。またイイ感じだね。

943 ：Name_Not_Found：04/05/31 06:37 ID:???

ところでさ、<h1>って大見出しだけど、そもそも大見出しって何？

そのページの本当の大見出しは<title>で記述するでしょ？そのうえ<h1>で繰り返しても意味ないよね。
まあ<h1>がページ内に2個以上あるならいいけど、普通ページをわけるから1個しかないよね。

例えばこのページも<title>と<h1>で同じこと言ってるけど、どうして？

944 ：943=912：04/05/31 06:39 ID:???

>>943は取り下げます。もっと読んでからぐだぐだ言ってみる。

945 ：943=912：04/05/31 07:59 ID:???

<!ELEMENT UNKO - - (昨日食べたもの) -(UNKO)>
俺は新しくUNKOタグを定義した。
みんなも使ってくれ。

とりあえずStrictについてある程度理解したけど、実行するのは難しいね。ちなみに
ってSGMLの関係だったんだね。
<!がSGMLの宣言？なんか違うな。
<!の後にハイフンが二つ続くとそこからはもう一度ハイフンが連続するまではコメントってことね。
そんでStrictではハイフンを2個以上連続させるのは禁止と。

946 ：Name_Not_Found：04/05/31 08:01 ID:???

つぎの質問どうぞ

947 ：943=912：04/05/31 08:16 ID:???

ところで
<!ENTITY % test "a|b|c|d">っていうのはハッシュ変数testの中に4つ入れといて
エレメントの（内容モデル）のとこで参照するてのはわかったけど、

<!ENTITY % coreattrs
"id ID #IMPLIED -- document-wide unique id --
class CDATA #IMPLIED -- space-separated list of classes --
style %StyleSheet; #IMPLIED -- associated style info --
title %Text; #IMPLIED -- advisory title --"
>

これなんかはどういうこと？%coreattrsを内容モデルで指定すると、
<!ELEMENT TEST - - (%coreattrs;)>
<TEST　id="" class="" style="" title="">っていう属性が使えるってことかな？

948 ：Name_Not_Found：04/05/31 08:17 ID:???

( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

949 ：943=912：04/05/31 08:27 ID:???

わかった。
上のやつはあくまでパラメタ定義だから、<!ELEMENT>で使うか<!ATTLIST>で使うか
は別で、上の感じなら、<!ATTLIST>で使えよ、ということか。

950 ：Name_Not_Found：04/05/31 08:29 ID:???

>945,947
取りあえずstrictには関係ないので出直しておいで

951 ：Name_Not_Found：04/05/31 08:37 ID:???

>942
> HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。
いやならpdf使えバカ

952 ：943=912：04/05/31 09:11 ID:???

HTML lintにTransitionalとしてかけたら-109点だった。とりあえず今日一日で
全てのページをtransitionalで75点以上になるように書き換えてみる。

>>951
pdfはテーブルレイアウト以上にうざがられる。

953 ：Name_Not_Found：04/05/31 09:12 ID:???

>>952
だってHTMLの範疇外のことやりたがって、できないのが不満、ってのなんでしょ？

954 ：Name_Not_Found：04/05/31 09:27 ID:???

なんでstrictスレに居付かれたのかな・・

955 ：Name_Not_Found：04/05/31 09:55 ID:???

>>954
相手してもらえるからだろ。

スレに有ってれば、最低限その部分だけレスして、
スレ違いの内容は一切無視がよろしいかと。

956 ：Name_Not_Found：04/05/31 16:37 ID:???

>>943
h1要素は本文。
title要素はメタ情報。

本で言うなら、扉と奥付の関係かな。

HTML文書の元となる文書を書いたとして、
そこに大見出しがあるならh1要素としてマークアップ。
大見出しがあってもなくても、title要素は必須。

957 ：Name_Not_Found：04/05/31 17:35 ID:???

>HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。
それはHTMLではなくCSSの表現能力の問題です。

958 ：Name_Not_Found：04/05/31 18:05 ID:???

stricto厨って頭の固い奴ばっかりだな。
おまえら多角的に物を見たりするの苦手だろ。
もっと柔軟な考え方したほうがいいよ。

959 ：Name_Not_Found：04/05/31 18:09 ID:???

>>958
えー、そーかー？
アンタの方が硬くない？だって、ここstrictのスレだよ？
みんなその辺のことはわかってて、それでもstrictな道を選んでんだよ？

アンタみたいな人のためにtransitionalだってあるんだからさ。

960 ：Name_Not_Found：04/05/31 18:10 ID:???

>>958
だらしないことと柔軟なことってのは違うだろ。

961 ：Name_Not_Found：04/05/31 18:27 ID:???

どのレスを見て「頭が固い」と思ったのか。

962 ：Name_Not_Found：04/05/31 19:36 ID:???

>>940
楽しいよね。ヘタなジグソーパズルよりずっと良い。
ていうか、楽しいと思えるくらいになれば考えても最善の手段が見つからないことはほとんどなくなるけど。
もうちょっとCSS漬けになってたら何も考えないでも思い通りにできるんだろうか。

963 ：Name_Not_Found：04/05/31 19:51 ID:???

Strict-HTML スレッド19
http://pc5.2ch.net/test/read.cgi/hp/1086000635/

964 ：Name_Not_Found：04/05/31 20:24 ID:???

>HTMLではこのレイアウトはできないっていう制限みたいな感じがいや。

やりにくいレイアウトは見にくいレイアウトだと思えばいい

965 ：Name_Not_Found：04/05/31 21:55 ID:???

そもそもHTMLではレイアウトできないしなぁ。

966 ：Name_Not_Found：04/05/31 22:19 ID:???

はいまた燃料投下されました

967 ：Name_Not_Found：04/05/31 22:25 ID:???

so-demonai

968 ：Name_Not_Found：04/05/31 22:59 ID:???

「ジグソーパズル」とか「やりにくいレイアウトは見にくいレイアウト」というのは志低いなぁ。

CSSの仕様が(3でもまだ)不十分な上に現在の実装がそれすら実現できてないことは厳しい現実であり、我々はそれを認めなければならない。
その不備をレイアウトのせいにしたりパズルといって正当化しようとしていてはStrict-HTMLの思想を広めることはできない。
たとえば銃を知らない人に銃を見せて「なんだこの棍棒は。こんなものでおもいきり殴ったら折れてしまう」と言われたとしよう。
そこで「そんな殴り方は悪い殴り方だ」とか「折れないように上手く殴るのがおもしろいんだ」などと言っていては銃の有効性を広めることはできない。

現状ではブラウザ上で表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。
そのことを認めた上でHTMLというのはただデータを表現するためのもので画面に表示するのはあくまで利用方法の1つにすぎないこと、
そしてなぜtableレイアウトが良くなく、たとえ見栄えが劣ったとしてもStrict-HTMLを使うべきなのかを説くべきである。

#そしてPDFやSVG、XSLなどの仕様があるにも係らず、既存のHTMLブラウザと比べて良い実装を作れないプログラマ(私含む)はそれを恥じるべきである。
#また、銃は撃ってみればすぐその有効性を示すことができ、見た人は銃を導入するコストを惜しまないのに対し、Strict-HTMLに対してはそのようなものが少ない。
#Strcit-HTMLならではの利用方法を僅かしか見出せていない状況を我々は恥じるべきである。

969 ：Name_Not_Found：04/05/31 23:04 ID:???

>>968
既存のHTMLブラウザと比べて良い実装を頑張って作ってください。

970 ：Name_Not_Found：04/05/31 23:08 ID:???

HTMLで自分の足を撃つとどうなるんでしょうか。

971 ： ◆FoxMX6a/hk ：04/05/31 23:57 ID:???

>>968 を 3行以下で表現できない限り、Strict が広まることはないな。

972 ：Name_Not_Found：04/06/01 00:00 ID:???

あと、オーサリングツールも重要です。

973 ：Name_Not_Found：04/06/01 00:11 ID:???

>>971
ぬ
る
ぽ

974 ：Name_Not_Found：04/06/01 00:18 ID:???

なんで、有用性が無くちゃstrictにする意味がないの？
いいじゃん、特に意味なんか無くたって。
漏れ（達、っていったら迷惑かな）はきちっと書くのがすきなの！

975 ：Name_Not_Found：04/06/01 00:24 ID:???

>>974
いや、有用性がないと（個人の好みは兎に角）規格、仕様として駄目だろ。

strictには十分有用性はあるけど。っていうか、守らなくても
有用性が保持されるフォーマットなどあり得ないのだけれども。

976 ：Name_Not_Found：04/06/01 00:41 ID:???

>968
言いたいことはよくわかるんだけど、
> 現状ではブラウザ上で表示した場合Strict-HTMLの見栄えはtableレイアウトのHTMLのものと比べて良くない。
だけは承服しかねる。

977 ：Name_Not_Found：04/06/01 00:42 ID:???

>>973
ｶﾞｯ

978 ：Name_Not_Found：04/06/01 00:47 ID:???

>>968
「CSSの仕様及びUAの実装の隙間をくぐり抜け、スタイル指定する事を、
パズルと言う言葉で正当化しようとしている」人が何処かに居ますか。
「志低い」とまで言っていますが。

979 ：Name_Not_Found：04/06/01 00:49 ID:???

JIS規格のアクセシビリチって、草案からどれくらいズレてくるのかな。

漏れ製作会社なんだけど、こないだクラの広報部web部門の
主任（毒女、NN4+table大好き）に呼ばれて、
「変なhtml書かないで頂戴！キーッ！」
ってどやされて。漏れがJISの話をして、
「御社のような大きなサイトをお持ちなら、ぜひ今のうちから準備なさった
　ほうがよろしいかと存じます」
って言ったら、突然自分のノートでググりだして。漏れ、自分の鯖に
草案pdfのコピーもってたから、見せてやったら、
「こんな草案通るはずないざます！キーッ！」と。

確かに漏れも、あれが全部規格になるとは信じがたいが、どの変まで
浸透するのかなあ。

980 ：Name_Not_Found：04/06/01 01:06 ID:???

藤子漫画の人ですか。

981 ：Name_Not_Found：04/06/01 01:16 ID:???

制作側が高齢者や視覚障害者への配慮も必要だけど
むしろWebはこういうものだと教えてやる方が重要だと自分は思う
こういう人たちは結局Webのページの見方や活用法がわかってないから

982 ：Name_Not_Found：04/06/01 01:17 ID:???

誰 > 藤子漫画の人

983 ：Name_Not_Found：04/06/01 01:23 ID:???

>>982
スネオのお母さんとかそういうのんじゃねえの？

984 ：Name_Not_Found：04/06/01 01:32 ID:???

前に、CSS系のどこかのスレで見たのを、ちょっと脚色。

中の良かった外注クリエイタがstrictに走り、
代理店の営業氏は彼と仲たがいをして連絡をとらなくなった。

その営業氏がある日、目に失明級の障害負ったと聞き、クリエイタは、
ユニバーサルアクセスなセッティングのノートPCを贈った。
営業氏は喜び、二人は仲直りした。

その夜、氏は夫人と、過去に手がけたサイトを見る（聞く）ことにした。
しかし、氏が推進していたアンチCSS・tableﾏﾝｾｰなサイトは
どれも意味不明な単語の羅列を読み上げるばかり。

唯一、わかりやすかったのは、営業氏を散々罵倒するそのクリエイタの
サイトだけだった。

985 ：Name_Not_Found：04/06/01 01:34 ID:???

>>984
ﾂﾏﾝﾈ

986 ：Name_Not_Found：04/06/01 01:35 ID:???

>>984
なんか童話みたいな話だな。
原文のURIきぼんぬ。

987 ：Name_Not_Found：04/06/01 02:25 ID:???

>>984
イソップ童話でありそうだな。
俺もURIｷﾎﾞﾝ

988 ：Name_Not_Found：04/06/01 12:00 ID:???

>>978
968とは別人だけど、912が"strictなままだと思った通りのレイアウトができない"といっているのに対して>>940, >>962はそれを肯定しているように見える。

>>984
strict-htmlが広まるのとUAが賢くなってtableレイアウトでもちゃんと読み上げられるようになるのどっちが先だろう?
googleは構造化されてない文章でもけっこうちゃんと扱ってるし。もちろんstrictな文章の方がちゃんと扱えるけど。

989 ：Name_Not_Found：04/06/01 12:48 ID:???

>>988
そもそもレイアウトとStrictを関連づけて思考している段階で間違い。
>>940は一旦Strict（構造のみの表記）にしてからCSSでレイアウトをするのが
楽しいと言っているのであって、「Strictでレイアウトするとか、出来ないとか」
いう思考そのものを否定している事を認識しる。

990 ：Name_Not_Found：04/06/01 13:25 ID:???

>>988
それなりにtableレイアウトに対処する音声UAが出現したとしても
構造と表現が分離してある方が便利なことには違いないよ。
文脈の自動判定なんて誤差がつきものだし(精度が上がれば上がるほど
誤差は誤解・トラブルの温床となるだろう)
スクリーンメディアと音声メディアのためだけのStrictじゃないし。

991 ：Name_Not_Found：04/06/01 14:48 ID:???

>988
そのどちらよりも先に、ブログなどの文書格納DBのフォーマットとして
XMLが普及し、XML→XSLTによりHTML+CSSを生成という流れがメジャーになって
「XSLのテンプレいじるよりCSSいじった方が楽だ」という一般人が多数化。

かくて、CSSが普及するも、HTMLを理解出来ない奴が「とりあえずCSSの
セレクタにするだけなら」とXSLにdiv、spanによるclassとidを大量に
埋め込み、tableは淘汰され、div房、span房の天下がやってくる、

…希ガス。

992 ：978：04/06/01 15:13 ID:???

>>988
レス有難う。
>>940は、>>912の"strictなままだと思った通りのレイアウトができない"に対し、
＞Strictで記述して「から」、
＞楽しみだったりするん「だけど」なあ。
と言っていて、私はここから「そもそも、マークアップとスタイル指定は同時に行うべきではない」と言う主張を読んだ。
つまり、940は912の言葉に対して、肯定(「確かに出来ない」)でも否定(「いや、CSSを勉強すれば出来る」)でもなく、
根本的な考え方を指摘(「マークアップとスタイル指定は同時に行うべきではない」)したのだと思う。

>>962に関しても、確かにCSSでのスタイル指定にはパズル的要素があるから、批判される様な発言ではないと思う。
(パズル的要素 = 素のHTML文書のデザインを、自分の頭の中にある正解(理想のデザイン)に、限られたプロパティやその値を使って近付けていく部分)