Strict-HTML スレッド24
■ このスレッドは過去ログ倉庫に格納されています
0001Name_Not_Found
04/10/02 22:19:38ID:???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 スレッド23
http://pc5.2ch.net/test/read.cgi/hp/1094311630/
過去ログ・関連スレ >>2
勧告等・その他 >>3
0101Name_Not_Found
04/10/06 19:07:04ID:???どのような記述にするのが適切でしょうか？
------------------
例）カレーの製造工程
1．洗う （←ここが用語）
野菜を洗います。
2．切る
肉、野菜をそれぞれ一口大に切ります。
3．炒める
肉、野菜を炒めます。
（…以下同様に続く）
------------------
実際に、カレーの製造工程なら、
「1．野菜を洗います」
として、<ol>-<li>でいいと思うのですが、
製造工程を表す用語があり、その詳細を補足のように
記述する形でいきたい場合、olとdlを組み合わせて
書けば良いのでしょうか？
0102Name_Not_Found
04/10/06 19:55:28ID:???dlって順序ありなの？順序なしなの？
まあどっちに近いのかってことなんだけど、おまいらどう思う？
>>101みたいな時にわざわざ順列だってol野中にdlを入れるのは面倒じゃん。
というか普通にdlだけでいいケースなんだけどさ。
とにかくなんとなしに湧いた疑問。dlは順序ありかなしか。
0103Name_Not_Found
04/10/06 20:07:15ID:???0104Name_Not_Found
04/10/06 21:29:43ID:???こんな感じでどうよ。
<dl>
<dt><a><img alt="サイト名"></a></dt>
<dd>
<ul>
<li>サイト名</li>
<li>製作者</li>
</ul>
<p>コメント</p>
</dd>
</dl>
……もういっそリスト削って p で全て完結させるとか(笑
0105Name_Not_Found
04/10/06 22:40:25ID:???明言されていないが、少なくともdt-ddのペアの解釈をみれば
順番は保持されている。
まぁ、bodyの下のpに関しても順列の処理は明記されていなくても
段落が勝手に入れ替わったりしないのは自明な訳で、余り気にしなくても良いかと。
0106102
04/10/06 23:58:42ID:???？
そうじゃなくてdt-ddの組が3つあったとして、その3つの順番の性質は
olよりかulよりかってことなんだけど；
なんか勘違いしてるような、勘違いしてないような微妙な。
まあどっちでもいいか。
0107Name_Not_Found
04/10/07 00:06:11ID:???完全にテーブルだな。ヘッダが複数ある時点で気づけよ。って気づいてるみたいだけど
何でいやがってんだよ。
<table sumarry="相互リンク一覧表">
<tr>
<th>バナー
<th>サイト名
<th>管理人
<th>コメント
</tr>
...
</table>
0108105
04/10/07 00:23:07ID:???>olよりかulよりかってことなんだけど；
>なんか勘違いしてるような、勘違いしてないような微妙な。
勘違いしていないつもりだが、説明が悪かったな。
p要素がolよりかulよりか考えなくても良いのと同じくらい
dl要素がolよりかulよりか考えなくても良い。
っていうかHTMLのワーキンググループは多分そんな事(どっちよりか)なんて
考えてないので深読みしても無駄かと思われる。
0109Name_Not_Found
04/10/07 02:37:54ID:???今までのStrictなhtmlの流儀作法とは違う気がするし、でもこれはこれで良いのかもと思うし、意見を求む。
関連
http://www.mozilla.org/css/base/content.css
ttp://pbx.homeunix.org/tpj/jam_log/category.php?k=CSS
0110Name_Not_Found
04/10/07 03:13:12ID:???英語なんか読めないから、意見もくそもないorz
0111Name_Not_Found
04/10/07 03:15:56ID:???0112Name_Not_Found
04/10/07 04:17:12ID:???div class="para"はXHTML2.0の先行実装もどきだね。
個人的に気になったのは、
blockquote*内に*引用元をaddressとして書いてる点かな。
あとq要素の括りをdiv class="quote"にするならば、
はなからblockquote使えよ、とも思う。
qってp中に出るときにつかうものじゃないのかな。
Notes of All Sorts以降はなぁ・・・・。
状況にもよるけど、
理論的なクラス名を持ったdivで括るよりはpにクラス付けた方が良いような気も。
どちらにせよ、結構見た目重視に設計されてる気がする。。
0113Name_Not_Found
04/10/07 04:56:39ID:???0114Name_Not_Found
04/10/07 07:30:50ID:???<link rel="schema.moz" href="http://www.mozilla.org/contribute/writing/markup"/>
<div class="moz:para">...
みたいに擬似名前空間でもやるとか (区切り子は":"でなく"."という説もあり)。
0115Name_Not_Found
04/10/07 08:40:52ID:???まぁ、しょうがないといえばしょうがないのだけども。
0116Name_Not_Found
04/10/07 10:46:50ID:???必然性もなくなる (というか、少なくとも HTML のマークアップリファレンスでは
なくなるな)。
逆に言えば、HTML のマークアップリファレンスなら、無理して class で要素そのもの
を拡張するような真似はしないで、HTML の範疇で無難にやれ、と言いたい。
# 飽くまでリファレンスとしての話。実運用上HTMLでは力不足でclassにより
拡張したくなる、と言う動機は解るし、そう言う運用を即全否定する気もない。
0117Name_Not_Found
04/10/07 13:58:35ID:???0118Name_Not_Found
04/10/07 15:51:24ID:???スレタイ
0119Name_Not_Found
04/10/07 19:03:05ID:???は？
ここはHTMLにしがみつこうスレではないだろ？
strictとなんでもかんでもHTML形式にしてしまおうというののどこに共通点が？
0120Name_Not_Found
04/10/07 19:06:27ID:???> Strict な HTML について語るスレッド
0121Name_Not_Found
04/10/07 19:13:41ID:???「HTMLにしがみつきだから、そこまでやるなら他の言語でやれよ、ここはHTMLのスレだぞ。あっちいけ」
と言いたかったのだと想像。
ただ、普通に読むと
「HTMLの話題にしがみつきだよ。そこまでやるぐらいだったら、他の言語の話をここでしようぜ」
にも見える。>>118はどうやらそう判断したようだ。
ところで、ulとolって
「順不同リスト」と「順序付きリスト」であって
「番号無しりすと」と「番号付き」リストではないよね？
ユニバーサルXHTMLな人のページだと
http://www.kanzaki.com/docs/html/htminfo13.html
後者で解説されてるんだけど、いいのかな。
0122Name_Not_Found
04/10/07 20:42:27ID:???>「番号無しりすと」と「番号付き」リストではないよね？
御意。
ただし、HTMLの仕様にある、標準的なスタイルを採用すると
"結果として" 後者が表示される。
>後者で解説されてるんだけど、いいのかな。
良くない。
0123Name_Not_Found
04/10/07 20:45:00ID:???>>117 にいたる >>109 からの流れを読むと不自然。
もし、>>121 が真意なら >>117 は Mozilla のリファレンスに向けられるべき言葉で、
だとしたら >>119 の返しには成らない。
0124Name_Not_Found
04/10/07 23:48:12ID:???0125Name_Not_Found
04/10/08 03:13:05ID:???0126Name_Not_Found
04/10/08 03:35:17ID:???スレ違いであろうと何であろうと構わん。
0127Name_Not_Found
04/10/08 03:57:36ID:???0128Name_Not_Found
04/10/08 12:29:51ID:???0129Name_Not_Found
04/10/08 16:41:24ID:???0130Name_Not_Found
04/10/08 17:37:15ID:???0131Name_Not_Found
04/10/08 18:54:36ID:???0132Name_Not_Found
04/10/09 00:04:21ID:???0133Name_Not_Found
04/10/09 00:21:01ID:???CSSスレなのにストリクターは蚊帳の外
オッフェ(=ﾟωﾟ)ﾉ♪
0134Name_Not_Found
04/10/09 00:37:02ID:???>strictとなんでもかんでもHTML形式にしてしまおうというののどこに共通点が？
Strictの概念ってHTML以外のSGMLやXMLにも有るのか?
例えばSVGとかHTML-FOとかみれば、SGMLやXMLが見栄え情報を直接持つ事が
必ずしも相性が悪い訳じゃないのは一目瞭然。
>133
別にCSSはHTML専用じゃないし。例えばRSSや、HTMLによく似た要素を持つ
何かが対象でもかまわない訳で。
なんと言ってもCSSスレはCSSスレなのだから(このスレでCSSがスレ違いなくらい)
Strictな話題はスレ違いでしょ。
必要があればここにStrictを扱っているスレに誘導すればいいだけ。
0135Name_Not_Found
04/10/09 01:41:30ID:???このスレでも>>94-100,104,107で話題にのぼってるけど、
CSSスレの例だと、デザインを考慮に入れなかったら完全にテーブルですよね？
0136Name_Not_Found
04/10/09 03:33:42ID:???0137Name_Not_Found
04/10/09 04:19:37ID:???CSSスレのものをこのスレで例にあげるから、「デザインを考慮に入れなかったら」って言ってるんでない？
0138Name_Not_Found
04/10/09 04:28:42ID:???[photo] [date] [size] というデータがあったとして
・<p>[photo]は[date]に撮影したものでサイズは[size]</p>
・<p>[photo]</p>
<dl>
<dt>撮影日</dt><dd>[date]</dd>
<dt>サイズ</dt><dd>[size]</dd>
</dl>
・<table>
<thead><tr><th>画像</th><th>撮影日</th><th>サイズ</th></tr></thead>
<tbody><tr><td>[photo]</td><td>[date]</td><td>[size]</td></tr></tbody>
</table>
と，どれでも表現はできるけど，UAに縦と横の関係を伝える必要があるなら
tableでマークアップするしかない，ということでしょう．
そう（縦横を伝える必要があると）考えてtableでマークアップしたら，
その先どう表示されるかについては，CSSスレッドにあったようにCSSのお話．
でIEの状況とW3Cの考え方もCSSスレッドに書いたとおり．
「UAだけでなく，レンダリング結果を視覚的に捉える人に対しても
わかりやすくしとこうよ」ってことだよね．
（作者が想定しうるUAに対して）伝える必要がない（と作者が考える）なら
tableにこだわる必要はないと思う
（閲覧者や想定外のUAによる再利用性などは今は考えないことにして）．
＃その点，CSSスレでは「構造ではない」と書いてしまって良くないな．
＃そういう構造（関係）をUAに伝える意図を込めたマークアップ，かな．
＃構造を伝える意図がないならtableというマークアップ（データの表現方法）を
＃使わなくてもよい，だと思う．
0139Name_Not_Found
04/10/09 04:48:52ID:???煮込め、[photo]だけを<P>で囲むのは変じゃないの？よぐわがんねだども
0140Name_Not_Found
04/10/09 15:03:12ID:???＞Strictの概念ってHTML以外のSGMLやXMLにも有るのか?
何言ってるの？
ここは、論理的なマークアップを考えるスレであって、なんでもかんでもHTMLでやってしまおうという
スレではないでしょ？っていう意味だよ。
0141Name_Not_Found
04/10/09 15:18:32ID:???>UAに縦と横の関係を伝える必要があるなら
>tableでマークアップするしかない，ということでしょう．
縦と横を伝えるにはtableが楽だ、と言うのは確かだが、
別にdtと複数のddや、一つのddの中のulでも伝える事は可能。
例えばclass属性使うとか (classで意味付けは出来ない。しかし、
tableにおける列程度の「何かの共通グループである事」は伝えられる)。
0142Name_Not_Found
04/10/09 17:13:39ID:???縦と横は論理的構造ではないからね。
0143Name_Not_Found
04/10/09 17:18:34ID:???「表」においては論理的なんじゃないの？だって表は表だもん！
0144Name_Not_Found
04/10/09 17:29:52ID:???0145Name_Not_Found
04/10/09 17:40:17ID:???0146Name_Not_Found
04/10/09 17:42:36ID:???0147Name_Not_Found
04/10/09 18:02:38ID:???0148Name_Not_Found
04/10/09 18:17:18ID:???0149Name_Not_Found
04/10/09 18:22:49ID:???0150Name_Not_Found
04/10/09 19:00:00ID:???scope,headers,axis属性の存在理由が無い。
0151Name_Not_Found
04/10/09 19:10:19ID:???XHTML2.0かなんかでもっと汎用的にデータを表す要素型できないかな?
0152Name_Not_Found
04/10/09 19:47:20ID:???XTablesなんてなw でもSGML系のツリー構造がベースでは
結局は axis 属性のようなものに頼ることになるので
どうやってもあんまり綺麗にはならない気がする。
0153Name_Not_Found
04/10/09 22:23:00ID:???四次元以上のものは人間には理解・閲覧困難だな。
0154Name_Not_Found
04/10/09 23:22:39ID:???表という形じゃなきゃ表示できるけどね
0155Name_Not_Found
04/10/09 23:31:58ID:???表形式で表示できるんじゃないの。
0156Name_Not_Found
04/10/10 00:09:47ID:???どうしても複雑になってしまうのは避けられないな。
0157Name_Not_Found
04/10/10 00:12:20ID:???それはXMLがツリー構造をしているからではなくて、
そのツリーを表示するのが (通常は) 二次元のスクリーンだからだと思う。
0158157
04/10/10 00:14:03ID:???0159Name_Not_Found
04/10/10 00:20:39ID:???いや、違うよ、擬似的に次元落として表示するのは普段からしてるでしょ。
たとえば（Googleで適当にイメージ検索した）
http://www2d.biglobe.ne.jp/~chem_env/chem/fiber_3d.gif
とか、三次元だし。
単純な内包関係でデータが表せれば強いけど、Table要素自体
「th要素中で*同じ位置*にあるtd要素を同じ列とする」
って感じで、縦方向の「内包」関係は放棄してる。
内包関係で表現できてるのは「同じ行」っていう1次元のデータだけだからね。
これが5次元とかになったらもう最悪だろうね。
0160159
04/10/10 00:21:11ID:???0161Name_Not_Found
04/10/10 13:12:19ID:???ツリー構造の言語でも階層だけで三次元データは扱えるよ。
<table>
<x>
<y><z>ああ</z><z>いい</z></y>
<y><z>ああ</z><z>いい</z></y>
</x>
<x>
<y><z>ああ</z><z>いい</z></y>
<y><z>ああ</z><z>いい</z></y>
</x>
</table>
これで、2x2x2構造。四次元ならもう一つ入れ子にすればいい。
この方式なら、ある意味 li の内容モデルに (li)* を加えるだけで、
ul だけで何次元データでも表せるようにも出来る。
li の入れ子分の次元になる。
0162Name_Not_Found
04/10/10 13:16:40ID:???jaggedになってるだけかもしれんし
0163Name_Not_Found
04/10/10 13:25:31ID:???現在の仕様書でも、
<table>
<tr><td>あ</td><td>い</td></tr>
<tr><td>う</td></tr>
</table>
は許されてるよ。足りない部分は空セルが補われる。ギザギザでも問題なし。
0164Name_Not_Found
04/10/10 14:56:56ID:???liだと縦の関係が示せないとか
0165Name_Not_Found
04/10/10 15:01:31ID:???4次元になると並の人間には構造が理解できない罠
どっかの数学者は4次元空間を頭の中で構築できているらしいが
0166Name_Not_Found
04/10/10 15:33:26ID:???オッフェ(=ﾟωﾟ)ﾉ♪
0167Name_Not_Found
04/10/10 16:24:40ID:???>>141
classはCSS専用のグループ属性というわけではない。
(本当にグループ化されているという保証もないが)
0168Name_Not_Found
04/10/10 17:13:51ID:???>(本当にグループ化されているという保証もないが)
どういう意味だよ？
CSSで理解できるんだから当然グループ化に成功してると言えるだろ？
もちろん論理的な意味などは伝えられないけど、単純にグループするのはできてるよ。
0169167
04/10/10 17:51:48ID:???正にその意味で「保証がない」と述べた。
Strict-HTMLにおけるグループ化は必ず論理的な意味での
グループ化でなくては意味がないが、CSSのターゲットとしての
classによるグループ化はしばしば論理的ではない場合がある。
例えvalidなStrict-HTMLであっても。
0170156
04/10/10 19:32:40ID:???俺が言いたかったのは>>159の通りで、
純粋な内包関係で表現できないってことね。
純粋な内包関係ならXpathで言うところの
「述部」を使用しなくても表現できる。
Tableで言うと同一行は「table/tr[foo]/td」で選択可能。
それに対して、列は
「table/tr/td[position() = foo]」
みたいに、セルを表す要素に直接述部を書かないといけなくなる。
個人的には内包関係から外れた関係はどうにも気持ち悪いね。
0171Name_Not_Found
04/10/11 00:24:53ID:???>Strict-HTMLにおけるグループ化は必ず論理的な意味での
>グループ化でなくては意味がないが、
一体仕様書のどこをどう読んだらそんな解釈できるの？
classは「何の」グループかを伝えることはできないけど、
それが「ひとつの」グループであることを伝えることはできる。
っていうか正にそういうもののためのもの。構造を知らせてれば
意味などは伝える必要はない。
>CSSのターゲットとしての
>classによるグループ化はしばしば論理的ではない場合がある。
classはそれらがグループであることを伝えるためのもの。別にグループ自体の
論理性などは微塵も関係ない。例えば「赤」のグループに「青」が混じっていても
問題はない。作者がそれを同一グループだと主張しているのに、何故、否定
する必要がある。
0172Name_Not_Found
04/10/11 00:30:15ID:???オッフェ(=ﾟωﾟ)ﾉ♪
これをサイトで扱うことになった。
<h1>オッフェ(=ﾟωﾟ)ﾉ♪とは</h1>
<p>つまりオッフェ(=ﾟωﾟ)ﾉ♪とはあからさまに人を馬鹿にした顔文字である。
きみらはそんな大人にならないように気をつけてくれ。</p>
どうだい？
0173169
04/10/11 01:07:34ID:???正にその通り。だから >>167 の様に書いた。
俺が述べたのはStrict-HTMLでのclassは
「論理的な意味でのグループ化でなくては意味がない」
であって、
「論理的な意味を『伝える』グループ化」
ではない。
0174Name_Not_Found
04/10/11 01:08:27ID:???DFN要素が足りない。
0175Name_Not_Found
04/10/11 01:16:25ID:???う〜ん・・・
だから
＞「論理的な意味でのグループ化でなくては意味がない」
これが間違いなのよね。
どこにも「論理的なグルーピングでなくてはいけない」なんてことは書いてないのよね。
そもそもグループ付けに非論理的とか論理的とかないから。
0176Name_Not_Found
04/10/11 01:59:48ID:???「○○〜でなければ『意味がない』」を「○○〜でなければ『いけない』」に
読み替えて、その上で「そんなことん仕様に書いてない」って云うなら
そりゃそうだろうなぁ。
なんでStrict-HTMLでは「意味がない」のかと云えば「見栄えの為のclassを
用いるならそれは見栄えの為のマークアップであって、Strict-HTMLが
わざわざ見栄えの為の要素を無くした『意味がない』状態になるから」であり、
仕様のどこを読んでも「『論理的なグルーピングでなくてはいけない』なんてことは書いてない」
と言われれば全くその通りだし、そんな主張は誰もしてない。
0177Name_Not_Found
04/10/11 02:37:16ID:???>『意味がない』」を「○○〜でなければ『いけない』」に
>読み替えて
ほんとに読み替えてたよ＾＾；
しかし「意味がない」は言いすぎだよ。100点でなきゃ意味がないっていう学生くらい
極端だね。
それに「見栄えの為のclass」って例えば何？
俺は「見栄えの為のclass」なんて思いつかないな。だって視覚からだって論理性を
伝えられるから。
class=first
これは問題ない。
class=red
これは名前がイマイチなだけでグループとしては問題ない
...っていうか全然思いつかないわ；
0178173=176
04/10/11 03:44:45ID:???>しかし「意味がない」は言いすぎだよ。100点でなきゃ意味がないっていう
>学生くらい極端だね。
だから「Strict-HTML "では"『意味がない』」ってわざわざ条件つけとるやん。
しかもここはStrict-HTMLやで? しかも実運用上、理屈通りに行かない事は
>>169 でのべ、更に >>173 では >>171 を全肯定しとるやん。
>それに「見栄えの為のclass」って例えば何？
>class=first
>これは問題ない。
classがどんな目的で記述されたかと、どんな文字列か、は全く別でしょ?
そんな事指摘されるまでもなく、解ってるでしょ?
たとえredだろうが、blueだろうが、ちゃんとした文書構造を象徴していれば
Strict的に意味のあるグルーピングだし、firstだろうが、なんだろうが、
例えば font 要素の代用として見栄えの為に用いられていたら、
それは見栄えの為のclass。
例えば<font size="6">を<span class="first">に置換しても、
validなStrict-HTMLにはなれるかも知らんけど、Strict-HTMLとして
意味のあるclassとはいえない。そう言う事。
0179Name_Not_Found
04/10/11 03:54:16ID:???>俺は「見栄えの為のclass」なんて思いつかないな。だって視覚からだって論理性を
>伝えられるから。
流れを読まずにレスするが、例えばメニューをfloatさせるときに
class="right"とかやったら論理性の伝わらないクソなclassだってわかるよね？
0180Name_Not_Found
04/10/11 04:53:00ID:???0181Name_Not_Found
04/10/11 05:46:43ID:???>ちゃんとした文書構造を象徴していれば
だからその文章構造を象徴してないclassって何？ってことなんだけど。
＞例えば<font size="6">を<span class="first">に置換しても、〜〜
いや意味のあるclassだと思うよ。というか意味のあるグループ付けだと思うよ。
いや、これは例が悪いこれって強調っぽいからね。
なんていうかね、スタイルの時点で追加するclassでもほとんどは文書構造をあらわしているものが
ほとんどだよ。見栄えがそこだけ変わるなら、当然構造も違うんだといいたいんだろうから。
もう少しだめクラス例のいいのをきぼん
>>179
場合によるね。名前はどうせ関係ないから。
それにid=menuでやるものだからなぁ・・・
そしてもしもid=menuのかわりに名前をデタラメでclass=rightとしてるなら
グループとしては間違いではない。まあclass=menu-aとかのデタラメ版かな。
UAにとっては差のないことね。
やはりもう少しいい例があるといいな。
意外にないんだよ。ダメなクラスの振り方って。
ダメなクラスの振り方＝ダメなグループ付け＝だめな関連付け
だからね。hogeとhogeを関連付けちゃいけないってどんなのよ？って。
赤くしたいのにclass=redで、とにかく文字を赤くしたいhn,span等全部に
class=redでもCSSを頭からなくしたときに、それらが関連付けられてては
いけない理由が浮かばないのね。
0182Name_Not_Found
04/10/11 06:00:47ID:???>それらが関連付けられてては
>いけない理由が浮かばないのね。
関連付けられてていいのか悪いのかでなく、そのclassは文書構造を象徴してるものなのかだろ。
まあ作者が象徴してると言えばそれまでだがなｗ
どちらにしてもclassなんてどんな付けかたしててもいいと思う漏れは勝ち組だな。
0183Name_Not_Found
04/10/11 06:57:17ID:???0184Name_Not_Found
04/10/11 07:15:07ID:???>それにid=menuでやるものだからなぁ・・・
>そしてもしもid=menuのかわりに名前をデタラメでclass=rightとしてるなら
>グループとしては間違いではない。まあclass=menu-aとかのデタラメ版かな。
もしもid=menuのかわりに名前をデタラメ〜なら間違いない、ってんなら（中身には突っ込まん）
id=menuのかわりでなく名前が見栄え意識でclass=rightなら間違い、ってことだろ？
自分で仮定しといてその反例（の導き方）がわからんとはどういう構造しとるんだお前の頭は。
0185Name_Not_Found
04/10/11 07:23:19ID:???その意味では目的に見合った構造化化がされていれば、
「red」でも「inoki」でも問題ない。
良く推奨される、「理論的な名前付け」は
「文脈を推理できる人間」にしか通用しない、
よって、無意味、と考えるのが、
個人的には正しいStrictだと思が、
要素でのマークアップに理論性を求める面からすると
「どうせならクラス名にも理論的な名前付けようぜ」
と思うのなら、それはそれで有り。
ただし、DTD上に定義されていないので、
あくまでも自己満足だよね。
0186Name_Not_Found
04/10/11 10:25:13ID:???>もしもid=menuのかわりに名前をデタラメ〜なら間違いない、ってんなら（中身には突っ込まん）
>id=menuのかわりでなく名前が見栄え意識でclass=rightなら間違い、ってことだろ？
もしそうであればclass=rightでも間違いではないってこと。だから真逆。
名前などどうでもいいのよ。構造には無関係だから。
名前から構造を考えず、実際のグルーピングとして正否を。
0187Name_Not_Found
04/10/11 11:37:03ID:???>いや意味のあるclassだと思うよ。というか意味のあるグループ付けだと思うよ。
>いや、これは例が悪いこれって強調っぽいからね。
これって、そのまま読み替えると
font size="6"は「ある意味論理要素だと思うよ」「いや、これは例が悪いこれって強調っぽいからね。」
となる訳だが。
結局釣りだったか。
0188178
04/10/11 11:41:50ID:???相手して悪かった。ごめんな。
0189Name_Not_Found
04/10/11 11:44:17ID:???>となる訳だが。
ならないけどね。
font要素とグルーピングが同じなわけないだろ。
0190Name_Not_Found
04/10/11 11:49:43ID:???ほんとストリクトにこだわるやつってアフォだよな（ﾌﾟｯ
軽く池沼レベルだな（ﾌﾟｹﾞﾗｯﾁｮ
0191Name_Not_Found
04/10/11 11:57:17ID:???0192Name_Not_Found
04/10/11 19:49:57ID:???多いね。
自論を理解してもらえない→相手が馬鹿だからだ
っていう発想はやめようよ。
0193Name_Not_Found
04/10/11 20:30:20ID:???本当に聞くべき相手は聞く耳持たないからそういう発言は意味がない
0194Name_Not_Found
04/10/11 20:45:12ID:???相手が話にならない場合があって、
後者の場合、「相手が馬鹿だからだ」の流れはかなり昔から２chにあったし、
前者の場合、さらに昔から２chにあった。
つまり、その傾向は最近でもなんでもない。
ただ、そういう傾向を前面に出すバカが最近このスレに増えたのは確か←ほらね
0195Name_Not_Found
04/10/12 02:01:14ID:???0196Name_Not_Found
04/10/12 10:06:42ID:???うん。他のスレでは普通のことでもここではやめてほしいね。
0197Name_Not_Found
04/10/12 12:01:51ID:???だって>>189とか池沼レベルだから崇高な俺達の言うことを理解できるわけがない。
0198Name_Not_Found
04/10/12 13:12:23ID:???0199Name_Not_Found
04/10/12 14:37:03ID:???荒らしや天然が来てもスルーして話が流れるし、
そうなれば住民のレベルも上がるので、さらに荒らしは寄りつきにくくなり、
天然も「あ、俺違うかも」と気付く物ですよ。
要するに、慢性的に話題がないのが問題。いっそ XHTML2.0スレとでも合併して
次世代の XHTML に付いてでも話していた方が、いざ HTML 4.01 の話題になった
時でも高いレベルが維持出来るんではないかと思うくらいに。
0200Name_Not_Found
04/10/12 15:50:26ID:???つまり、このスレはもう役目を終えているわけですよ。
> いっそ XHTML2.0スレとでも合併して
話題がないからスレの主旨を拡大して、とかいう
いつか聞いた提案の再来ですか？
■ このスレッドは過去ログ倉庫に格納されています