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
005857
04/10/04 16:36:36ID:???005957
04/10/04 16:38:17ID:???誤：
この時、<object herf="hoge.gif">hoge画像の代理文字</a> の Data 属性は、
正：
この時、<object data="hoge.gif">hoge画像の代理文字</object> の type 属性は、
0060Name_Not_Found
04/10/04 16:38:40ID:???0061Name_Not_Found
04/10/04 16:43:09ID:???0062Name_Not_Found
04/10/04 16:44:22ID:???0063Name_Not_Found
04/10/04 16:45:43ID:???マニアックすぎて全く興味を持てない
すまんが帰ってくれ
0064Name_Not_Found
04/10/04 16:47:49ID:???すれ違い
strictと関係ない
0065Name_Not_Found
04/10/04 16:56:31ID:???カエレ！
0066Name_Not_Found
04/10/04 17:06:03ID:???Object要素でメディアタイプをtype属性に指定する、と言うのはstrict以外の
どんな話題なのか問いたい。
>>57 もぐでぐでだが、せめて帰れというなら、誘導ぐらいしてやれよ。
http://pc5.2ch.net/test/read.cgi/hp/1093950965/l50
0067Name_Not_Found
04/10/04 17:14:02ID:???0068Name_Not_Found
04/10/04 17:14:41ID:???さらに、hoge.gif へアクセスすると hoge.png に 301 リダイレクトされるとします。
>66
この時点でなぁ
0070Name_Not_Found
04/10/04 17:38:34ID:???0071Name_Not_Found
04/10/04 17:59:43ID:???つまり、そう言う時にHTMLでは、どうするの?って話題でしょ?
それに対して「HTML では想定外です」とか「そう言うサーバ上では
HTMLはtype属性は使わないでください」なら兎に角、
回答が「スレ違い、カエレ」では、「HTMLではどするの?」に対して「解らないで逆ギレ」
以外の何物でもない。
一言で言えばみっともない。
0072Name_Not_Found
04/10/04 18:12:23ID:???0073Name_Not_Found
04/10/04 18:12:57ID:???0074Name_Not_Found
04/10/04 18:23:06ID:???英単語の前後に半角スペースを入れるべきなの？
0075Name_Not_Found
04/10/04 18:49:19ID:???2単語以上入るときは前後にスペース入れてるけど
<span lang="en">english words</span>としてCSSでやるのがいいのかな
0076Name_Not_Found
04/10/04 19:14:54ID:???0077Name_Not_Found
04/10/04 19:29:44ID:???Redirect の際に Content-Type は送信されない (送信されるはずがない) 。
つまり、hoge.gif にはMIMEタイプがない。
だから少なくとも image/gif は間違い。
image/png で正しいかどうかは知らん。
っていうかコンテントネゴシエーション使え。
0078Name_Not_Found
04/10/04 19:57:48ID:???>その昔 GIF 圧縮技術の特許問題の時に (全部の gif を png に変換 するまでの)
>過渡的な措置として上記のような状況が発生たことが有ったんだが、
>未だに、正解はなんだったのだろう、と考えたりします。
dataの示すリソースがgifかpngか分からない段階では、type属性は
指定しようがない。gifからpngに置き換えた段階でソースを
<object data="hoge.png" type="image/png">hoge画像の代理文字</object>
に書き換えるしかないだろう。
だが、pngでgifと同じような悲劇が起こらないとは限らないので >>77 でFA。
0079Name_Not_Found
04/10/04 20:21:42ID:???組版のJISで字間を空けるというのがあるが、見栄えの問題。
CSS3が勧告されたらtext-autospace使えば
Wordみたいにスペース入れずに字間を空けてくれる。
0080Name_Not_Found
04/10/04 21:23:50ID:???まあゴミ規格になっちゃったんだけど
まあ「勧告」とかいって逃げてるからダメなんだよ
まあアホに多くを期待してもしょうがないか
0081Name_Not_Found
04/10/04 21:42:54ID:???> If the value of this attribute differs from the HTTP Content-Type returned by
> the server when the object is retrieved, the HTTP Content-Type takes precedence.
とのことなので、直ちに問題になるわけではないようね。
とはいえ気持ち悪いので、>>77の最終行と。
(結局type属性は指定しようがないわけだけど、img要素と同じだと思えばいいのか。)
0082Name_Not_Found
04/10/04 21:44:49ID:???0083Name_Not_Found
04/10/04 22:03:39ID:???仕様策定側としてはおそらく
あの頃のペースで各種技術開発が続くことを想定してたんだと思うよ。
不備は後の版の仕様と実装で直していけばいいや、みたいな。
その後仕様も実装も開発が停滞したことの方が計算外だったのでは。
>>82
無理が出てくるのは、理想と現実の間に溝があるからさ。
0084Name_Not_Found
04/10/04 22:04:44ID:???現実的には必要としても、究極的には不要な気がする。
リソースのメタ情報の事前取得が、DNSの名前解決と同じくらい一般的になってくれれば、
あるいは話も変わるかもしれない。
上手いことやれば、埋め込みリソースや参照リソースの表題の自動取得なんてことも…。
0085Name_Not_Found
04/10/04 22:50:37ID:???多言語をまたぐので変則的になるのは仕方ないと思うけど。
英文は単語・品詞のあいだに適宜空白を設ける事になっていて、
“this is a test message.”という文字列の中の半角スペースは、
単語・品詞の区切り子なのではないかと。
で、和文にもごく希な用法だけど、文節を空白で区切る記法があるので、
英文のルールの上方互換で、半角スペースを入れた方がいいのではないかと。
どう？
0086Name_Not_Found
04/10/04 22:52:16ID:???>it allows the user agent to avoid loading information for unsupported content types.
とあるのでimage/gifと書いてしまうと「あ、俺gifわかんねーや。パス」と判断するUAがありそう。
0087Name_Not_Found
04/10/04 23:09:28ID:???ごく希な用法から演繹するのは、ちょっとこじつけな気がする。
日本語の文書内に英語が登場する場合、おそらく(xml:)lang属性はjaだろうから、
アルファベットの部分が日本語的に処理されても文句は言えないような。
それならば、span lang="en"でも指定したほうが、言語境界も明らかになるし、
CSS指定によるスペース付けの恩恵も得られるので、こちらがよいのではないかと。
まあ、そうでありながらそれは煩雑なことなので、
lang指定なしでスペース付きのベタ書きでも、現実的にはよいと思うけどね。
0089Name_Not_Found
04/10/04 23:57:59ID:???日本語の文中に英単語が入るとき、
英単語の前後に半角スペースを入れるべきなの？
こいつのアホな一言からの流れに一言。
それは言語の仕様であって、HTMLの話ではない。ゆえに完全にスレ違い。
日本語という言語の中に英語を混ぜる時の記述の仕方を日本語の仕様書を読んで
勉強してこい。スレ違いすぎて不愉快だ！
0090Name_Not_Found
04/10/05 00:02:24ID:???んー、そうだねぇ。
実際問題として、長島一茂のお父さんの話言葉みたいな文章でない限り、
和文の中に英単語が出てくる場合は、大抵dfn/abbr/code/strong/emで
マークアップする局面が（漏れの場合）ほとんどなので、大抵cssで間隔
を空けているんだけどね。
html に染まる以前は、普通の理科系の人間だったので、何となく
英数の前後にはスペースを入れる習慣が付いていた。
ところで、LtRの横書きの中にアラビア文とか混ざると読みづらいんだろうなあ。
0091Name_Not_Found
04/10/05 00:57:25ID:???お前なめてんの？
他のスレでやれよ。
0092Name_Not_Found
04/10/05 11:55:08ID:???わりぃわりぃｗ
0093Name_Not_Found
04/10/06 14:06:39ID:???0094Name_Not_Found
04/10/06 15:32:35ID:???<dl>
<dt><img></dt>
<dd>撮影場所</dd>
</dl>
でいいんですか？さらに、各<dl>を<li>にはさんで、
<ul>
<li><dl><dt><img></dt><dd>撮影場所</dd></dl></li>
<li><dl><dt><img></dt><dd>撮影場所</dd></dl></li>
…
</ul>
みたいにすべきですか？
サムネイルを作る際にもっともよいと思われる方法を教えてください。
項目が多くなるとテーブルでもよさげですか？
0095Name_Not_Found
04/10/06 15:40:11ID:???0096Name_Not_Found
04/10/06 16:02:49ID:???0097Name_Not_Found
04/10/06 16:05:05ID:???dl は Definition Lists の略であり、dl の段階で既に list なので、
ulやol を更に使う理由は (少なくともサムネイル一覧をリスト化する場合には)
無いと思われる。
>項目が多くなるとテーブルでもよさげですか？
撮影場所だけでなく、日時とか、撮影者とか、その他のコメントなど
増え始めたら、十分にtable構造だとおもう。
大雑把な基準として、
1項目のみ(今回は画像のみ): ul か ol
2項目(今回は画像+撮影場所): dl
3項目以上: table
で問題ないかと思われ (ベストかどうかはまた別だが)
009895
04/10/06 16:23:16ID:???<DL
____<DT><A HREF=""><IMG SRC=""></A></DT>
____<DD>
________<UL>
________________<LI><A HREF="">サイト名</A></LI>
________________<LI>管理人名</LI>
________________<LI>コメント</LI>
________</UL>
____</DD>
</DL>
それともDDの部分を下記のように？
<DD><A HREF="">サイト名</A></DD>
<DD><A HREF="">管理人名</A></DD>
<DD><A HREF="">コメント</A></DD>
やっぱりテーブルかな・・
0099Name_Not_Found
04/10/06 16:26:09ID:???>>大雑把な基準
たしかにそれがしっくりくる
0100Name_Not_Found
04/10/06 16:29:59ID:???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がツリー構造をしているからではなくて、
そのツリーを表示するのが (通常は) 二次元のスクリーンだからだと思う。
■ このスレッドは過去ログ倉庫に格納されています