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
0018Name_Not_Found
04/10/03 00:26:22ID:???0019Name_Not_Found
04/10/03 00:34:44ID:???OK、aa要素の内容は文字列であるが、それは経験に現れた現象としての物でなくて、
そうした現象と独立にそれ自体としてあると考えられた物としてインスタンス化される。
これは我々の感官を触発して、直観の形式の助けを借りてレンダリングを生じさせるが、
それ自体がどんなものであるかは我々には不可知であるとする。
Kokugo Dai Jiten Dictionary. Shinsou-ban (Revised edition) (C) Shogakukan 1988
国語大辞典（新装版）(C)小学館 1988
0020Name_Not_Found
04/10/03 00:40:06ID:???0021Name_Not_Found
04/10/03 01:17:16ID:???<abbr title="Ascii Art">AA</abbr>については画像と同じ扱いでいいだろ
<aa format="2ch" title="ジェンキン寿司">
l"ジェンキン寿司 l
,､_lー-―――――‐--、/l
i ﾄ､ﾐﾐ ,r‐- ､｀`'ニ=‐、.彡ﾘ.
ヾ,iﾊ゛.´ _,,､_ i.; _,. ｀ 彡'i)
｀､j,' `ﾟ''´:.ﾉ i::<･ゝ) .ﾊン
i, ｀ ,､/ i_ ｀` ,r'
,r〃'i ,r'ヽ、 _,〉 /.
/i:ﾄ､;;i, ﾐ=_‐_-, 'i /ヽ__
r-‐'´i::::ﾊ;;ヾ、‐‐-､ ノ´/i:::'i｀i‐- ､_
::i' .l:i 'i::::i ヾ;;`‐---‐'i':/ i､ 'i::! i::::i ｀
</aa>
外部への参照かドキュメントの内部に埋め込まれてるかの違いだけであって。
</p>
<p>
ただし、いわゆる顔文字は、機能としては感嘆符等と同じ
なので、そこんとこ配慮するべき<xxx comment="いいタグ名が思い浮かばない" value="ﾖﾛｼｸ"><aa style="2ch">ъ( ﾟｰ^)</aa></xxx>
</p>
0022Name_Not_Found
04/10/03 01:22:01ID:???Strictとして話をしたいならspanかdivかObject要素だろ。
0023Name_Not_Found
04/10/03 01:24:21ID:???それだったら
<![CDATA[ジェンキン寿司]]>
にしたほうがいい。
0024Name_Not_Found
04/10/03 01:24:50ID:???解析対象外にしないと半角スペースとか困るし。
0025Name_Not_Found
04/10/03 02:30:45ID:???よし俺が説明しよう。そもそもorzとは何なのかを考えてみよう。
orzは元々落ち込んでいる人のように見えるからという、まさに見栄えからできたものだ。
しかし、それだけか？
さて、ここで一度ビックリマークやクエスチョンマークについて考えてみよう。
これらは視覚的でないといえるか？答えはNOだ。これらは視覚的と意味的の２面性を
保有している。これらの記号も見栄えでしかないと言えばその通りであるが、
そもそも文字とは見栄えから作られたものだ。そしてその見栄えに意味を込めて、
視覚的装飾ではなくなっていくものだ。
つまり同列でないわけがないのだ。文字こそ見栄えの最たるものだからだ。
0026Name_Not_Found
04/10/03 02:35:29ID:???0027Name_Not_Found
04/10/03 02:42:00ID:???念頭にHTMLとCSSの境界線について考えてみよう。
というか結論を言おう。HTMLにある要素を使う。なければそのまま書き込む。
まさにこれにつきる。例えば定義リストで、
持論：常に持っている意見
などが合ったとする。この：コロンは装飾か？
これは前回の結論に照らし合わせればわかるとおり、２面性を持つ記号だ。
そしてここで重要なのはHTMLでここでの：コロンにあたる要素はあるかということ。
つまりDL要素そのものがコロンの持つ意味をより明確にUA伝えているので、
すでにコロンから意味を取り除いてるわけだ。この片面を取り除かれ
視覚的な面しか残っていないコロンを使うことは当然非strictだと言える。
つまりそういうことだ。
0028Name_Not_Found
04/10/03 02:42:56ID:???UAの挙動などで仕様の解釈を変えるわけにはいかない。
0029Name_Not_Found
04/10/03 02:46:32ID:???UAの挙動でなく言語的にそういう仕様。
言語を記述するのに「HTML外での挙動は気にかけない」って？
0030Name_Not_Found
04/10/03 02:52:50ID:???うん・・・そうだな・・・29が合ってる・・・・・しかしゴールが見えないな。
いずれorzも言語の仕様になればよしってことか？
しかしすでに２ちゃん言語の仕様ではあるな。
0031Name_Not_Found
04/10/03 03:29:06ID:???と言うレベルで日本語のスラングである2ch語に対応しているかどうか、と言う話だろ。
HTMLに対応しているか、と言うのは明らかに別のレイヤー。
0032Name_Not_Found
04/10/03 10:45:36ID:???AAをファイルに埋め込むならdataスキーマを使え。
形式はフォントの保存ができる形式でなければならない。(前のAAの議論より)
0033Name_Not_Found
04/10/03 11:09:05ID:???0034Name_Not_Found
04/10/03 13:26:07ID:???＞読み上げソフトが日本語を読めるか、英語を読めるか、
＞と言うレベルで日本語のスラングである2ch語に対応しているかどうか、と言う話だろ。
全然そんな話じゃないんだが・・・・；
>>32
画像でいいじゃない。
>>33
それいいかもね。しかし普通の顔文字＾＾こういうのはどうする？
こういうのを含めて広い総称がほしいな。
メールとか辺りから顔文字ってのは出てきたと思うがいいネーミングないか？
0035Name_Not_Found
04/10/03 14:08:20ID:???フォントが変わって位置がずれるのなら(X)HTMLには適さない。
#でも見た目が重要なリアル言語もあるから>>33もOKかもしれない…
0036Name_Not_Found
04/10/03 14:09:27ID:???0037Name_Not_Found
04/10/03 14:33:43ID:???MIMEみたいにx-接頭辞を付けるとかあったっけ?
0038Name_Not_Found
04/10/03 16:14:15ID:???いけないだろ。ただ顔文字は最近の言語の仕様だから直で書けばいいってことだ。
まあAAまでいくとどうなるのかわからんがな。なにせ
顔文字→文字
AA→アート
っていうくらいだからな。
とりあえず文章の一部に溶け込んでるならそれは視覚的装飾ではない。
0039Name_Not_Found
04/10/03 16:42:06ID:???http://www.ietf.org/rfc/rfc3066.txt
2.2 Language tag sources
- The value "x" is reserved for private use. Subtags of "x" shall
not be registered by the IANA.
0040Name_Not_Found
04/10/03 17:22:53ID:???どうした池沼君
日本語を勉強しような
0041Name_Not_Found
04/10/03 18:58:56ID:???>>37 への回答だろ? ネットの仕様に関する論議がでるスレなんだから
これくらいの英語は読めないと困らないか?
0042Name_Not_Found
04/10/03 19:01:49ID:???＞>>37 への回答だろ?
なんで自分の行動に対して「？」が付くんだ？もしかして馬鹿？
とりあえず日本語を勉強してこい。
0043Name_Not_Found
04/10/03 19:08:45ID:???0044Name_Not_Found
04/10/03 20:15:59ID:???0045Name_Not_Found
04/10/03 20:33:21ID:???あと>>37と>>41が同一人物だと思ったんだ。
バカでごめんよ。
0046Name_Not_Found
04/10/03 20:34:29ID:???0047Name_Not_Found
04/10/03 20:53:09ID:???そんなに悔しかったの？ｗ
0048Name_Not_Found
04/10/03 21:12:25ID:???0049Name_Not_Found
04/10/03 21:38:39ID:???0050Name_Not_Found
04/10/03 22:57:49ID:???0051Name_Not_Found
04/10/04 01:18:24ID:???正直お前ら子供すぎる。まあ現に消防とかが多いんだろうから仕方ないが、
実のないレスはがんばって無視してくれよ。一人が反応するといっせいに
流れが対荒らしになるから。
0052Name_Not_Found
04/10/04 05:28:52ID:???それができてたらこのスレこんなに続いてない。
0053Name_Not_Found
04/10/04 12:51:11ID:???0054Name_Not_Found
04/10/04 15:39:38ID:???そんなこのスレを見てるお前の人生はきっと実のない人生なんだね（プオオオオオオｗ
0055Name_Not_Found
04/10/04 15:58:52ID:???0056Name_Not_Found
04/10/04 16:22:21ID:???0057Name_Not_Found
04/10/04 16:35:42ID:???拡張子 gif なら image/gif、png なら image/png を返すサーバで、
さらに、hoge.gif へアクセスすると hoge.png に 301 リダイレクトされるとします。
この時、<object herf="hoge.gif">hoge画像の代理文字</a> の Data 属性は、
image/gif? image/png?
その昔 GIF 圧縮技術の特許問題の時に (全部の gif を png に変換 するまでの)
過渡的な措置として上記のような状況が発生たことが有ったんだが、
未だに、正解はなんだったのだろう、と考えたりします。
# そもそも異なるメディアのファイルにリダイレクトすること自体が
イレギュラーだとは思いますが。
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:???■ このスレッドは過去ログ倉庫に格納されています